Can you tell me @Touch-of-Ink what automation you have create with fp1? Is worth to buy because is expensive
@b16b I got them on sale, so the price was in line (about $40 US) with some other devices Iâd bought. Iâm using them strictly to keep lights on in areas where they would unexpectedly turn off. I use a normal motion detector to turn on the lights, because these are slow to turn on.
However, in almost all my set ups, I use one device to turn on, and a different one to turn off. (For example, I turn on my bedroom lights when I walk into the room with a motion detector, but turn it off with either my sleep mat under the bed or with a vibration sensor when I sit down in the living room chair.)
I just installed them yesterday, so I canât tell about false negatives yet. Also, I have cats, so Iâm playing around with the sensor detection level (high, medium, or low) to see when it will detect me and not the cats. Plus, Lewis over at Everything Smart Home on YouTube just announced heâs coming out with his own version of this presence sensor. I donât know the price yet, but I think it will be better than the Aqara one 
Do you see a slow response only for
presence sensor or also for presence detection status?
Perhaps I can trigger presence once the status shows approaching or enter
1 Like
Hi @Trakker2
Just in case you are planning something similar to improve detection, please allow me to share my findings.
- Status is usually sent faster, presence is sent with a delay of 3-5 seconds
- Sometimes, presence is not sent at all (if passing and exiting sufficiently fast)
- Usually, the first status is enter, then approaching, but it depends on configuration
Therefore, my current plan is to send presence event in case status is enter, enter left or right or approaching.
Then cancel a previous timer (if any) and schedule a timer event that would trigger read attribute for presence. This is to ensure that presence is cleared if after enter only leave status is sent (without presence)
Cheers
1 Like
Hi @ygerlovin ,
Your observations above are absolutely correct. I have implemented a very similar logic ( see here ).
The presence (it is the âmotionâ attribute in my platform) is switched to active on âenterâ, âleft_enter, âright_enterââ events and switched back to inactive when any of the following events are detected: 'leave, âleft_leaveâ, âright_leaveâ or presence event: ânot presentâ. There was no need to start a timer and poll for the presence attribute.
This way Aqara FP1 sensor triggers âmotion detectedâ pretty fast. I still use FP1 in combination with Aqara PIR sensors to speed up the light automation even faster when a person enters from the room open door, because a single sensor can not cover all the places in a large room. But FP1 can be used even without an additional PIR sensor!
The only problem I encountered was that FP1 presence in one room didnât clear because of a left-right rotating floor standing fan. I had to switch off the horizontal movement and everything is OK now.
1 Like
@ygerlovin To be honest, I never checked. Every review I saw or read said the FP1 took 3 to 5 seconds to turn on lights. When I plugged it in, my totally unscientific test agreed with that. Since itâs already part of my process to use two sensors for light management (turning on is easy, but turning off neither too late nor too early can be a little finagley) I never checked to see how it would work in my real world situations.
does it mean that the Presence detection status comes from the device, but the Presence sensor is calculated from the status?
Because I had a couple of glitches when the sensor stayed in âpresentâ even after everyone left. So I switched my routines to âApproachingâ and âLeaveâ.
I also noticed a delay between a PIR and Ultrasound sensors - usually, PIR is 1-2 seconds faster. ~ time while I am closing the bathroom door, it was enough time for PIR to turn on lights, but with Ultrasound, I am ending up in the darkness for a moment
For Aqara FP1 this is not the case. The sensor reports both and the currently published driver converts device reports without any additional logic.
So, both presence status and presence sensor are shown exactly as reported by the device
1 Like
@Trakker2 ,
Many thanks for your input.
I was trying to avoid timers, however, I noticed that *leave events are not always sent. Thus, presence sensor could falsely show presence (when passing by sufficiently fast).
I couldnât make it work reliably without timers.
1 Like
have you changed anything in the driver, my family reported that the device is working for an hour. Donât have the access to the logs at this moment
@veonua
The last version is 1.8.0, published on 2022-08-03T20:09:47.547709570Z.
No changes since then.
What seems to be a problem?
for some reason only your 1.8.0 driver is stuck with no logs at all. Hub restart helped.
Any chance to add the xiaomi/aquara temp/humidity sensor?
Data
- application: 02
- endpointId: 01
- manufacturer: LUMI
- model: lumi.sens
- zigbeeNodeType: SLEEPY_END_DEVICE
Raw Description 01 0104 5F01 01 05 0000 0003 0019
2 Likes
Iâm using your driver, but Iâm having troubles with the settings. I canât change them. If I want to change detection interval or sensitivty mode I get a pop-up saying network or server error, try again later.
LQI 172 and RSSI -57
Already deleted it and rejoined it.
Any thoughts?
Hi @Roy_R ,
I assume you are talking about P1, not FP1.
Sleeping devices need to be waken up during configuration.
Try pressing button with 1 second or so interval before and during changing configuration.
This is because the device does not listen to commands during sleeping to save the battery.
1 Like
Correct, the P1.
Sensitivty is now on high.
Dectection interval doesnât go lower then 30 seconds?
But no motion in the device setting (3 dots) is 5 seconds. Do you know the difference?
Hi @johnconstantelo and @d3fung,
Iâm not familiar with your devices and it would require some research to understand their protocol.
Iâm currently fully occupied with support of already released integrations and another projects, so unfortunately I have no plans adding new devices, unless it is very similar to already released ones.
Sleepy motion detectors are not checking motion constantly. Instead, they check motion, report if it was detected and go to sleep. If the motion is no longer detected, they do not report anything, they just go to sleep.
Detection interval for RTCGQ14LM and RTCGQ13LM is configured on the device itself. This is the time period the device waits before retrying to detect motion. The minimal value depends on sensorâs firmware. The driver allows 0-255, but the device might reject the setting.
To clear motion, the driver schedules a timer, once motion is detected. It will fire after âno motionâ interval, unless another motion is detected during this period. This setting is also sometimes called cool down period.
ST currently processes timers in 30 seconds intervals, so there is little point to define it less than 20 sec or so. However, please note, that in the worst case it might take no motion + 30 seconds to cool down if the timer expires immediately before ST starts processing timers.
1 Like
