"No selection" is not selected.
The settings in the picture below are also arbitrarily changed.
"No selection" is not selected.
"2022/07/29 5:19 PM"
The "Approach distance" is randomly changed.
"No selection" of Monitoring mode is not selected.
Will automation be available when it is modified? Automation doesn't work now.
"2022/07/29 6:07 PM" - monitoring_mode bug fix; approachDistance bug fix
"No selection" means that the parameter from a drop-down menu does not have any value, this is the initial setting when the actual parameter is unknown. As soon as the current value of the monitoring mode is received from the device, this value is synchronized with the preference. Once set, you can't set it back to 'no selection', except an explicit code is not written, but I think there is no need for that.
The standard automation use the 'motion' attribute, I will add it later tonight (will be your morning time probably).
So the 'motion' events will be simulated this way:
- presence_type event: 'enter', 'left_enter, 'right_enter'' -> motion active
- presence event: 'present' -> motion active (the event will be sent just in case the previous 'enter' was missed. If the motion state was already 'active' - no event is sent to HE applications actually.)
- presence_type event: 'leave, 'left_leave', 'right_leave' -> motion not active
- presence event: 'not present' -> motion not active. (the event will be sent just in case the previous 'leave' was missed. If the motion state was already 'not active' - no event is sent to HE applications actually.)
My FP1 test program :
Looking at the contents, there is a door sensor. Motion sensor and door sensor into one category...I'm curious.
"2022/07/29 8:39 PM" - setMotion command for tests/tuning of automations; added motion active/inactive simulation for FP1
This will be all for today
On the door sensor - it is just a test code for the new Aqara E1 door sensors, which do not work with HE and ST, because they expect the Zigbee hub to return a response 'Í am an Aqara hub'. Works with HomeAssistant / DeConz only, where the Zigbee coordinator firmware is modified to return Aqara manufacturer code for these sensors. I will remove it in the next days after one more final attempt.
I did the first simple test.
It's very satisfying, and it's wonderful. I appreciate your efforts.
I wonder what program you tested with.
The above simple RM 5.1 rule just controls a color bulb - turnes on or off depending on the FP1 sensor motion active/inactive status and changes the bulb color depending on FP1 'presence type' events - blue when entering from the right side relative to the sensor, violet when entering from the left, , green when staying close ('approach'), other color when staying far away from the sensor, etc...
BTW, the transitioning states (left_enter, right_leave, etc..) don't last long enough to notice the color change... Later I modified the RM5.1 rule to add some delays before switching off the bulb, just to see the color change when leaving...
But the above simple automation is just for tests, we still need to think of a real use of the 'enter', 'away', 'leave', ..etc events for real home automation purposes.
You can try using the new 'Room Lighting' built-in App in HE. It is very powerful, although because of the many options available needs time to learn and experiment
My head gets very complicated.
The link below is an article that continuously updates the sensing speed and characteristics of the sensors I have.
You can see it through translation.
I have added three of my sensors to my living room, dining room, and kitchen.
I have modified my rules to turn off the lights when the FP1s motion changes to inactive so the lights are turning off a lot faster. It truly feels like a home from the future now with lights turning on instantly using PIR sensors above doorways and off within 10-30 seconds of leaving a room knowing 100% there isn't someone in that room. I have one more to fit in the bedroom and will be purchasing at least another three, Having the lights turn off in under 30 seconds instead of a 5-minute timeout delay in case someone is sitting or standing still will save some energy bill money.
I'm very happy just need to find FP1s for the price I paid a month ago which was a bargain price of £37 each
Congratulations on getting what you want.
Maybe FP1 is an extension of the promotion in Korea.
At that time, I also purchased 2 units (32/35 dollars) with an additional discount of 5 dollars.
It won't be this price, but a big event is scheduled for the end of August at AliExpress. Promotion + card discount / I hope it's helpful information.
And there are other tuya presence sensors that "kkossev" has made available.
Its performance outperforms FP1. It can be used alone without having to use other sensors.
The only issue is the tuya needs to be installed into the ceiling
Sensor works great with the last driver version.
NB: in the logging I still see two "unknown parameter" entry's:
Thank you for the feedback!
I still have to do some code cleanup and suppress some debug logs that should not be shown when the debug option is turned off, will do it in the next update.
Tuya Multi Sensor 4 in 1 also has the �C issue.
At the risk of piling on it would be fantastic if you could look into supporting the Tuya contact sensor. The generic Zigbee driver works but has no heartbeat. I use as a window contact on a window that may not be opened or closed for many days. The problem is you don't know if the contact has dropped off in the mean time.
I tested FP1 with other sensors.
Under similar conditions, only fp1 has unique data.
While other sensors show similar speeds regularly,
fp1 shows too many deviations, even up to two seconds.
I have an additional question.
Other Tuya sensors move the specified setting value HE and move from He to Tuya, but fp1 doesn't seem to be the case. Why is that?
Do you mean that the 'motion active' event is sent with a delay that varies randomly?
I am not sure that I understand your second question, can you please clarify it?