SONOFF SNZB-03 Strange Behavior

[soloam]

What happened

I don't know if ths is a problem in the hardware, or the code, but this motion sensor presents some strange behavior when reporting motion:

• It does not respect the "occupancy_timeout: 0", I still receive the "occupancy":false message, even with occupancy_timeout set to zero
• From what I can tell the device make a report every 60 seconds. If I make motion, and hold still, and move again 60 seconds after, I get the 2 messages, the first one, and the second one when I move 60 seconds after. But if I make a movement and never stop moving, I get the first message, and never get the second message, not even the 60 seconds after. Only after I stop for 60 seconds I get the second message

What did you expect to happen

• If the "occupancy_timeout: 0" I should never receive the "occupancy":false
• It should report the message in movement, but if I keep moving it should report the second message with true when the device is again able to make the report.

How to reproduce it (minimal and precise)

• Configure a SONOFF SNZB-03 with "occupancy_timeout: 0" and it should keep sending the false message, the expected behavior is to not to.
• Configure a SONOFF SNZB-03 and trigger a motion and keep moving... as long as we are moving no message arrive, it should send a new message 60 seconds later.

Debug info

Zigbee2MQTT version: 1.16.0 (9ed84e1) Adapter hardware: CC1352P-2 Adapter firmware version: 20200805

[soloam]

I did some more tests, and if I keep moving I get:

Test 1:

• Start Moving: Message true
• Keep Moving 60s after: Message false
• Keep Moving 120s after: No message
• Stop Moving 10s and then move: Message true

Test 2:

• Start Moving: Message true
• Stop Moving and 60s after: Message false
• Resume Moving: Message true

So from what I can see if I stop the movement, I'm able to get the next report 60 seconds past the first message... but if I keep moving I get a message false and then I don't get any message until I stop for some seconds and move again.

From what I can tell it should:

• Never send the Message false if the movement is occurring or if "occupancy_timeout: 0".
• It should send a second Message true if the 60 seconds pass and a third one past other 60s

Thank You

[Koenkk]

Since this device generates the occupancy false events itself, occupancy_timeout is not supported for this device. (that's why you also don't see it here: https://www.zigbee2mqtt.io/devices/SNZB-03.html).

[soloam]

Thank you @Koenkk !

And regarding the lack of reports, unless the motion is stopped after the first 60s?

Thank You

[Koenkk]

@soloam that's up to the device (since the occupancy values come from the device). But I don't have this device myself to confirm if this is expected behaviour. Tagging some people who have this device, can you check this: @oh2ftu @dedors @Gertjuh

[dedors]

I can confirm test 1, if you move and keep moving, it sets to false after 60 seconds and never sets it back to true until you stop moving for a short time.

Test 2 is expected and I can also confirm.

Now the very interesting one: If I do test 1 with 10 second breaks between moving, it NEVER turns false. That means: the sensor only turns to false a) after 60 seconds no movement and b) after 60 seconds of nonstop movement.

[soloam]

And this is a problem in the hardware it self correct @dedors? So basically this make this sensor unusable if the intention is to keep a light on with movement. I don't what to remind myself that I need to stop moving to retrigger the sensor. What a disappointment with this! I had vey high hopes for this sensor, afther scratching from my list the aqara because of random disconnects that I was never able to solve (even following to tutorials that should solve this)

Thank You

[dedors]

I did open a ticket at itead to ask about this behavior and if it may get fixed with a firmware update.

[soloam]

Thank you @dedors, please keep us posted on the replay!

[trevorbenyack]

Hi, I've been experiencing what I perceived as "erratic" behavior with these sensors too. Have them routed into Home Assistant via deconz and they've been driving me crazy. Hoping you get a response from Sonoff!

[soloam]

I had very high hopes for this sensors, at the moment I can't recommend them! Hope that some firmware updates can solve this!

[aofc]

Just migrated from deCONZ where this device had a occupancy timeout setting. So the device should support it, no?

[Jaxon77]

Great to see, that this issue is already being addressed. I bought 4 of these devices and was wondering what is going on until i made some tests. I also came to the conclusion that the device wont react while moving. i hope this is getting fixed by SONOFF

[arturdobo]

Unfortunately, I struggle with this sensor as well. Has it ever updated the tamper flag in your cases?

[soloam]

I tested the new Silvercrest HG06335 (TY0202) that is still in dev and it haves the same problem... It only reports motion if the motions stops... Are they both the same device under the shell? Or can this be any problem in zigbee2mqtt @Koenkk ?

[Jaxon77]

I tried to sniff the device. I never did that before on zigbee devices and i hope i did not make any mistake. The result is that the device did not send any further data while i was moving. So it sems to be a problem of the device itself.

I started moving at Point 1 which sets "occupancy": true. After 80 seconds while still moving it sends "occupancy": false (Point 2). After that it stops sending data until i stopped moving and started over again after a while (Point 3). Its the same behavior as seen in the zigbee2mqtt log.

[arturdobo]

Do you know any other motion sensor that sends out state updates more often?

[giejay]

Also bought this one, did someone already contact sonoff regarding this issue? As soon as I get it and I'm seeing this issue, I will also sent them a mail.

[dedors]

My communication with Sonoff is kinda stuck. Maybe someone else has to try it. I don't know if it's my non-native English or something else that they don't get it. They keep asking for a video for something that is easy reproducable without. I gave them this conversation as reference but I think they never looked at it.

[giejay]

A video of you moving while pointing the camera to the logs? 😂 That seems ridiculous, maybe I will cancel my order if that's the kind of response they are giving.

[giejay]

I'm using zigbee2mqtt together with Openhab. Won't setting a timer in Openhab of let's say 30 seconds after an "off command" fix this issue? So, don't immediately turn off the light when motion==off but set a timer. If there is motion again within those 30 seconds, cancel the timer.

Of course this will increase the light-on time but I'm not too bothered about that.

[dedors]

Won't setting a timer in Openhab of let's say 30 seconds after an "off command" fix this issue? So, don't immediately turn off the light when motion==off but set a timer. If there is motion again within those 30 seconds, cancel the timer.

I don't think that works. If there is no break in movement, it sents a "off" after 60 seconds of movement and never turns back on until there is a break in movement.

[afrostewie]

Hi, I also use SNZB-03 motion sensor and unfortunatelly have experienced the same. I can confirm both tests.

The sensors does NOT send an occupancy=true again until the movement has stopped.

I will also report it to ITEAD as this makes the sensor basically unusable in home automation systems.

[masseman69]

I got the exact same problem :(. Sent a mail to ITEAD as well, let's hope they will listen to us and find a solution.

[Jaxon77]

Now it's getting weird. After working in the garage for a while, i noticed that the SNZB-03 placed over there indicated motion for a longer time-period in homeassistant. So i took a look at the logs and started some tests. What can i say... the sensor works as expected! It sends "occupancy":true when motion is detected. after that it stops sending and sends "occupancy":false when no more motion (for xx seconds.. did not measure it yet) is detected. Fun fact: I did not change anything on my setup since then. can anybody confirm this new behavior?

2020-12-20 16:23:23: ... '{"battery":80,"battery_low":false,"linkquality":75,"occupancy":true,"tamper":false...}' 2020-12-20 16:42:01: ... '{"battery":80,"battery_low":false,"linkquality":33,"occupancy":false,"tamper":false...}'

[soloam]

That's not the problem! The sensor sends occupancy true on motion, and false when no motion! That works OK! The problem is that it never sends multiple occupancy true, even if the motion continues, and only sends the occupation false if no motion is detected after some minutes!

On Sun, Dec 20, 2020, 23:01 Jaxon77 notifications@github.com wrote:

Now it's getting weird. After working in the garage for a while, i noticed that the SNZB-03 placed over there indicated motion for a longer time-period in homeassistant. So i took a look at the logs and started some tests. What can i say... the sensor works as expected! It sends "occupancy":true when motion is detected. after that it stops sending and sends "occupancy":false when no more motion (for xx seconds.. did not measure it yet) is detected. Fun fact: I did not change anything on my setup since then. can anybody confirm this new behavior?

[image: image] https://user-images.githubusercontent.com/30999568/102726364-7c64e900-431e-11eb-9832-87e456abfb56.png

2020-12-20 16:23:23: ... '{"battery":80,"battery_low":false,"linkquality":75,"occupancy":true,"tamper":false...}' 2020-12-20 16:42:01: ... '{"battery":80,"battery_low":false,"linkquality":33,"occupancy":false,"tamper":false...}'

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/4874#issuecomment-748683403, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3FPIYFMMODZEDE3AUHZCTSVZ63XANCNFSM4TKALG2A .

[Jaxon77]

nevermind. the sensor did not send the occupancy false after 60 secondy anymore, but i might have been caught by what dedors found out (having some short breaks in movement). whith simulated real non stop moving it still sends occupancy: false after 60 seconds. so problem is still there

[afrostewie]

Hi, so I got a reply from ITEAD basically confirming what we experienced: "Due to power consumption and power-saving considerations, there have some restrictions on the trigger That is: when SNZB-03 detects the movement, it will send a signal to ZBBridge If the device does not detect any movement for one minute, once the device triggered, it will send a signal to ZBBridge If any movement is detected within one minute, the device will not send a trigger to ZBBridge. And effective detection and trigger signals to ZBBridge will be delayed for one minute. It means the motion sensor works with one-minute intervals."

This confirms that: If movement has started and does not stop, then the device will NOT send any trigger (not occupancy=true nor occupancy=false) until movement has stopped.

The other problem of occupancy=false being sent after 60sec althought there is still movement must be another (probably independent) issue. I encountered it too, but only occasionally.

[dedors]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

[afrostewie]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

You are right, it does send the FALSE even if there is constant movement... This must be a bug in the device's firmware.

[3bbing]

I experience the exact same problem and also contacted support. Apparently they don't see it as a bug, but rather as battery saving feature. (Which seems a bit odd, their temperature & humidity sensor sends regular updates just fine regardless of the 'battery'..). Still, with this explanation I don't expect a (soon) fix/change. Same answer like you received @afrostewie

Due to power consumption and power-saving considerations, there have some restrictions on the trigger That is: when SNZB-03 detects the movement, it will send a signal to ZBBridge If the device does not detect any movement for one minute, once the device triggered, it will send a signal to ZBBridge If any movement is detected within one minute, the device will not send a trigger to ZBBridge. And effective detection and trigger signals to ZBBridge will be delayed for one minute. It means the motion sensor works with one-minute intervals.

Support suggests that there is another (different?) signal sent after 60 seconds without movement. Instead of assuming that there is no movement when there is no further signal from the device (which I guess is what we do?), the Sonoff bridge seems to maintain the occupancy state as set and is waiting for a "switch off" signal to change it again. Pretty much like a light-switch if you ask me. Unfortunately I am very new to this and can't investigate further adhoc. Anyone who can check in on this? Is there such a second signal and if yes, can we teach our bridge to somehow interpret it like a "Switch Off" signal (or keep occupancy up until it comes)? That is: Signal Movement -> Switch on .... stay on until next signal .. Signal for "No Movement" -> Switch off Rather than Signal Movement -> Timer delay if no further "Signal Movement" incoming -> Switch off

Too bad they have this unconventional logic. The sensors are very nice otherwise, compact and well priced..

P.S.: Can somebody hint me to a tutorial in how to read all raw sensor messages? ZShark seems to be depreciated for ConBee II. How do we do it? As @Koenkk wrote, in https://www.zigbee2mqtt.io/devices/SNZB-03.html there is no indication of such an 'off' signal in the (open) documentation. That is contrary to what the support indicated, so my hope is that there is another message that is not picked up - possible?

[afrostewie]

I experience the exact same problem and also contacted support. Apparently they don't see it as a bug, but rather as battery saving feature. (Which seems a bit odd, their temperature & humidity sensor sends regular updates just fine regardless of the 'battery'..). Still, with this explanation I don't expect a (soon) fix/change. Same answer like you received @afrostewie

Due to power consumption and power-saving considerations, there have some restrictions on the trigger That is: when SNZB-03 detects the movement, it will send a signal to ZBBridge If the device does not detect any movement for one minute, once the device triggered, it will send a signal to ZBBridge If any movement is detected within one minute, the device will not send a trigger to ZBBridge. And effective detection and trigger signals to ZBBridge will be delayed for one minute. It means the motion sensor works with one-minute intervals.

Support suggests that there is another (different?) signal sent after 60 seconds without movement. Instead of assuming that there is no movement when there is no further signal from the device (which I guess is what we do?), the Sonoff bridge seems to maintain the occupancy state as set and is waiting for a "switch off" signal to change it again. Pretty much like a light-switch if you ask me. Unfortunately I am very new to this and can't investigate further adhoc. Anyone who can check in on this? Is there such a second signal and if yes, can we teach our bridge to somehow interpret it like a "Switch Off" signal (or keep occupancy up until it comes)? That is: Signal Movement -> Switch on .... stay on until next signal .. Signal for "No Movement" -> Switch off Rather than Signal Movement -> Timer delay if no further "Signal Movement" incoming -> Switch off

Too bad they have this unconventional logic. The sensors are very nice otherwise, compact and well priced..

P.S.: Can somebody hint me to a tutorial in how to read all raw sensor messages? ZShark seems to be depreciated for ConBee II. How do we do it? As @Koenkk wrote, in https://www.zigbee2mqtt.io/devices/SNZB-03.html there is no indication of such an 'off' signal in the (open) documentation. That is contrary to what the support indicated, so my hope is that there is another message that is not picked up - possible?

Hi! There are two different signals:

• occupancy=true: this is the signal ON
• occupancy=false: this is the signal OFF

The sensor does send the signal OFF after 60 seconds. This is ok.

The problem is that it sends the signal OFF even if there is movement. I have now tested 2 sensors and no matter what I do, it sends a signal OFF (occupancy=false) even if I constantly move in front of the sensor.

[3bbing]

Ah I see, thanks for the clarification and summary. I got confused along the thread. Well that is bad. I replied the support. Fingers crossed.

[NovalisVonHardenberg]

Same issue here...

[webgear88]

Same issue here, anyone can advise how to fix it?

the sensor will sent false when there is movement after triggered

[SaulGoodman1337]

Same here... Is there any Chance to fix that ?

[cree8]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

[SaulGoodman1337]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

[afrostewie]

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducable.

[cree8]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

Yes, Phoscon.

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducible.

Might you try the battery test? That would go a long way towards fingering what is happening...because it really makes no sense that they would design these sensors with such illogical logic. There should be no reason to send an OFF signal when motion still occurs. I feel like there is a driver issue within the Zigbee layer that causes a timeout, but I am still not well versed in the overall stack.

[Jaxon77]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

Yes, Phoscon.

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducible.

Might you try the battery test? That would go a long way towards fingering what is happening...because it really makes no sense that they would design these sensors with such illogical logic. There should be no reason to send an OFF signal when motion still occurs. I feel like there is a driver issue within the Zigbee layer that causes a timeout, but I am still not well versed in the overall stack.

Take a look at my sniffing analysis some posts ago. The "occupancy": false even if there is motion comes from the device itself

[SaulGoodman1337]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

Yes, Phoscon.

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducible.

Might you try the battery test? That would go a long way towards fingering what is happening...because it really makes no sense that they would design these sensors with such illogical logic. There should be no reason to send an OFF signal when motion still occurs. I feel like there is a driver issue within the Zigbee layer that causes a timeout, but I am still not well versed in the overall stack.

Take a look at my sniffing analysis some posts ago. The "occupancy": false even if there is motion comes from the device itself

So the device ist just Junk ?

[cree8]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

Yes, Phoscon.

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducible.

Might you try the battery test? That would go a long way towards fingering what is happening...because it really makes no sense that they would design these sensors with such illogical logic. There should be no reason to send an OFF signal when motion still occurs. I feel like there is a driver issue within the Zigbee layer that causes a timeout, but I am still not well versed in the overall stack.

Take a look at my sniffing analysis some posts ago. The "occupancy": false even if there is motion comes from the device itself

So the device ist just Junk ?

Its looking that way. I'm about to return 8 of them, don't feel like waiting around for them to fix it properly. They also have a bad phantom activation issue.

[ASNNetworks]

I experience occasionally false triggers on 2 of the 7 sensors. And 2 sensors that occasionally don’t send the ‘false’ command. Being out of a room for over 10min to see the light is still on sucks. Waking by the sensor then flashes the light and internally sends a ‘true’ command, after one minute it then goes ‘false’ which finally turns off the light.

Even though it doesn’t happen a lot, it kinda ruins the whole point of home automation. Seeing this thread I’m convinced nothing will change and it’s a hardware thing. Having tried Aqara, Blitzwolf, Konke and now Sonoff: all of them have some kind of issue with either not triggering sometimes, dropping connections randomly or phantom triggers. It’s kinda hit or miss even between sensors of the same brand. I now have 2 per room to have one as a fallback...

I ordered 2 Hue motion sensors to test out. Untill now: they’re well worth the premium price. They are extremely sensitive, very fast and have a 10s cooldown that keeps extending when you’re moving. Might just replace all my motion sensors with Hue, if they show no weird issues.

[arturdobo]

@ASNNetworks keep us know your result

[SaulGoodman1337]

I can reproduce this problem 100% of the time. After 60 seconds of non-stop movement (I just take the sensor in my hands and move it around) it ALWAYS sends occupancy=false, I did not had one exception.

I tested this behavior today to determine if the 60 seconds "clear" status was happening regardless of input from the sensor. It seems that this is the case. I triggered the sensor then removed the battery, and the sensor in Home assistant still went to 'clear' status. What this tells me is that the sensor does not necessarily send out another update until a full 60s passes with no motion, which is fine by me. What I need to stop from happening is whatever is causing the sensor entity to show as clear when it actually did not send clear status..

Which Gateway are you using ? Phoscon ?

Yes, Phoscon.

There might be other top layer application logic in HomeAssistant which alters the overall behavior (e.g. timeouts). I do not use HomeAssistant, but directly get the signals form the device. And the problematic behavior (sending occupancy=false even if there is motion) is reproducible.

Might you try the battery test? That would go a long way towards fingering what is happening...because it really makes no sense that they would design these sensors with such illogical logic. There should be no reason to send an OFF signal when motion still occurs. I feel like there is a driver issue within the Zigbee layer that causes a timeout, but I am still not well versed in the overall stack.

Take a look at my sniffing analysis some posts ago. The "occupancy": false even if there is motion comes from the device itself

So the device ist just Junk ?

Its looking that way. I'm about to return 8 of them, don't feel like waiting around for them to fix it properly. They also have a bad phantom activation issue.

yep this shit is crap. dont buy it !

[EpicMount]

Just found this issue through Google. I bought 5 of these sensors. All but 1 of them are exhibiting this problem. After reading through this thread, I am going to be sending all 5 of them back and will look for another option. Such a shame, the size and price are great but the performance for Home Automation is terrible.

[almostlunatic]

I bought them 4. I've had hard times to get them to work with a blockly script for my bathroom. Today I did it!. My goal was to achieve the situation when the movement in the room is over, the sensor starts to count 60 sec to give out "occupancy:false", then to decrease the lihght to some value to warn the person in the bathroom to make a move for the further light, and after some time to double warn with blinking light, on a case if he/she had slumbered on the bowl not to let him/her into the total darkness. The time slots at the beginning are temporary, as I don't have any light sensor yet but wanted to have a smooth light when going to toilet at night time. So, only problem for me is that in some situations the 60 seconds are much too lot.

I don't know yet how this will work in weeks or months. But to send it back to China from France would be killing the money.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[Milithor]

I also just bought one of these, thought I was very happy with such a compact thing. Connected it through Phoscon with conbee II, unfortunately I haven't been able to figure out the logic behind the sensor.

It goes off sometimes, but then it stays idle for minutes on end when there's still movement ongoing. I also notice getting a false state back when still there's movement.

Thinking of returning it. Anyone got good replacements?

[afrostewie]

I also just bought one of these, thought I was very happy with such a compact thing. Connected it through Phoscon with conbee II, unfortunately I haven't been able to figure out the logic behind the sensor.

It goes off sometimes, but then it stays idle for minutes on end when there's still movement ongoing. I also notice getting a false state back when still there's movement.

Thinking of returning it. Anyone got good replacements?

I went with IKEA: https://www.ikea.com/gb/en/p/tradfri-wireless-motion-sensor-white-70429913/ Works perfectly since several months.