After updating to 2.20.1 , my xiaomi motion sensors stay in motion detection state

pergolafabio commented 1 year ago

Describe the bug

Hi, i'm using Home Assistant, today received a notification to update addon to 6.18.0 (deconz 2.20.1)... I have a few Xiamo Motion sensor, and now they are staying in motion detected state? Even restart the addon doesnt help...

1 additional note, those 3 sensors , i applied the pencil hack, so motion detection goes to false after 5 sec

Steps to reproduce the behavior

Reboot deconz, and notice motion detected state to true

Screenshots

Environment

Host system: HassOS
Running method: Assistent deCONZ Add-on
Firmware version: (26390500)
deCONZ version: (2.20.1)
Device: (ConBee I )
Do you use an USB extension cable: yes

KennethLavrsen commented 1 year ago

I do not use HA addon. I run Deconz on bare metal. And I use Philips Motion sensors. And also Aqara FP1. I have had same problem for a couple of Deconz versions.

Normally I can walk around the house and trigger the sensors and then they turn off after normal timeout.

It is random which sensors report motion after restart of Deconz

pergolafabio commented 1 year ago

yeah, i'm not at home right now, but updated remotely now after restart they detect motion

Maybe if i go home, if i do a real detection, they hopefully go to OFF state?

in your case? You need to detect real motion 1 time so they go to off state after a restart of deconz?

andys73 commented 1 year ago

I run HA OS and have Aqara motion sensors.. my environment looks ok. I have installed the update last night and I have not rebooted the pi 4 since then...

pergolafabio commented 1 year ago

have you already walked before them? as soon as i restart deconz, they are in motion detected state not at home, didnt got the the chance yet to walk before them, but never seen this behaviour before

do you also have the pencil hack applied to your sensors to trigger 5 sec instead of 1-2 min ?

ebaauw commented 1 year ago

Normally I can walk around the house and trigger the sensors and then they turn off after normal timeout.

Sensors don’t “turn off”; they simply report state.

Some motion sensors, like Hue, are stateful, sending a Zigbee message, when motion is detected, and a second one, when motion is no longer detected. Typically config/delay configures how long the sensor waits to send the second message when it no longer detects motion.

Other motion sensors are stateless, and only send a Zigbee message, when they detect motion (after a cool down period). For these, deCONZ resets state/presence after config/duration seconds. If you restart deCONZ before that time has expired, the sensors resource will continue to report state/presence, until deCONZ resets that, config/duration seconds after motion is next detected.

Yet other motion sensors, like the IKEA, technically aren’t sensors, but controllers: they send an On with Timed Off command to bound lights, which deCONZ uses to set state/presence and (read-only) config/delay. deCONZ resets state/presence after config/delay seconds, when config/duration is 0. Otherwise it uses config/duration.

pergolafabio commented 1 year ago

When i did the deconz Addon update, i was not home, all sensors were not reporting motion I did the update, restarted addon, and now 3 motion sensors are in motion state detected true , they still are

Never seen this behaviour before, already done a lots of updates

They cant normally report motion... since there is no one at home (i hope :-) )

Anyway, i report back when i'm home, hopefulle walking before them will turn then to no motion detected state after cooldown

andys73 commented 1 year ago

I do not understand why I am not impacted...

pergolafabio commented 1 year ago

well, my sensors are still in detected state, restarted deconz / ha 4 hours ago...

KennethLavrsen commented 1 year ago

Read this thread on Home Assistant forum. This issue has been a problem for many for several months. It is not related to the recent release. The problems started probably with the 2.19 series though I actually tried to downgrade to the last 2.18 release and I still have the problem.

The solution in HA land seems to be that more and more give up on Deconz and move to Zigbee2MQTT which does not have this problem. And I must admit I am getting there too.

pergolafabio commented 1 year ago

what thread? :-)

But never seen this issue before, i always keep my deconz addon up to date :-)

anyway, will report back later when i'm home i hope they go to "FALSE" once they detected real motion

KennethLavrsen commented 1 year ago

Sorry - forgot to paste the link to the HA thread

https://community.home-assistant.io/t/restarting-deconz-motion-sensors-are-always-detected/507607/2

I upgraded to 2.20.1 this morning and just tried a restart.

This time no motion sensors were activated but i saw several lights reported on - even if they are not. And they correct themselves within a minute. The problem is that the motion sensors do not correct themselves unless they are triggered and time out again @ebaauw explains above.

I think the issue is that there is a bug in deconz with the saved states. The database of the state is not read correctly or get corrupted maybe? I do not think it has anything to do with the physical sensors. It is deconz that goof up the states of anything at start and then depending on what kind of device you have, it is a small glitch like a light reported on for 10 seconds or a motion sensor that appears on until it gets triggered and times out and goes in sync.

it does not happen every time. I tried it one more time and all was well. It happends randomly

This is really annoying

pergolafabio commented 1 year ago

ah , ok thnx for posting the link, seems indeed the same issue still strange that i didnt see it before on previous release ...

i always have my deconz addon uptodate, and must be running 2.19.x too before

6.18.0
Bump deCONZ to 2.20.1
6.17.1
Bump deCONZ to 2.19.3
6.17.0
Bump deCONZ to 2.19.1
6.16.0

Lets hope they go to "off" again when i"m back home

my light didnt turn on, since i have my automation based on from "off" to "on"
and now it was more like from "unavaible" to "on"

so i can live with the issue, altough, still anoying, that means the first time , when deconz is restarted, the light will not work

andys73 commented 1 year ago

now I remember I had this situation some weeks ago with the motion sensors that were "blocked" on detected for hours. I had to re-pair them to get the status updated correctly. Did not happened since then.

I have a large network of over 150 devices and deconz served me well I do not really want to move, the addon consumes very little resources, is very fast, project is alive and kicking so maybe the employees from Germany need to step in a bit to work out the instability issue.

pergolafabio commented 1 year ago

I'home, it's back to normal, once they detected real detection, even after restart HA or Deconz....

ebaauw commented 1 year ago

I think the issue is that there is a bug in deconz with the saved states. The database of the state is not read correctly or get corrupted maybe? I do not think it has anything to do with the physical sensors. It is deconz that goof up the states of anything at start and then depending on what kind of device you have, it is a small glitch like a light reported on for 10 seconds or a motion sensor that appears on until it gets triggered and times out and goes in sync.

I'm not sure the issue is with saved states, or state not being saved in a timely matter. deCONZ should flush the database before shutting down, but if it's killed or crashes, the database might contain outdated info.

The problem with sensors, or rather battery-powered devices, or rather devices without Receiver On When Idle, is that they cannot be queried for their state, unlike lights. This means deCONZ can only correct the wrong state when the sensor wakes up and sends its current state. Stateful sensors do so periodically, while stateless sensors only do so when they next detect motion.

This is really annoying

My suggestion would be to buy a decent motion sensor, but, in all fairness, there's no way to get this info beforehand, as this behaviour typically isn't mentioned in any documentation of the sensor.

Also, I do think it would make sense to reset state/presence on startup, for stateless motion sensors (like how we reset the state for CLIPGenericFlag and CLIPGenericStatus sensors on startup). It would be a small change (3 lines?) in database.cpp, checking for config/duration on a ZHAPresence (or CLIPPresence) sensor.

Bloody Hell, that's been in the code for 4 years: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/a4b025419baf4fcda9cece2b3586b70d6663838f/database.cpp#L4216-L4220 But it doesn't work?! Closed deCONZ, patched the database to set state/presence to true, started deCONZ, and API reports true, until the next periodic event (Hue motion sensor). I would say, that's a bug alright.

Finne75 commented 1 year ago

Thanks! See also thread here.

KennethLavrsen commented 1 year ago

I am happy that we now have confirmed that there is a bug.

and on "decent motion sensors". Most of mine are Philips Hue. They should be the most decent there is. Also note that when I do the systemctl restart deconz none of them were detecting motion.

thogens commented 1 year ago

I'm having the same issue with some, but not all of my Aqara motion sensors after using 2.20.1. After rebooting, lights will be switched "on", as "presence" of these sensors is set to "true" and won't be set to "false" until I'll trigger the sensor once manually. I've not seen this issue with 2.19x or before.

pergolafabio commented 1 year ago

yeah, its indeed strange ... seems they need a real motion detection the first time

I now rebooted HA or Deconz several times, and dont notice anymore that they are back to True... Maybe i was just when updating ... or when rebooting HassOs completely ,...

rafuz commented 1 year ago

@ebaauw May it be the same for xiaomi contact sensor? I have noticed that some of my windows sensors default to "open" after a restart of Deconz. It will switch to the right status only after opening/closing the sensor at least once. It happens only on 3-4 sensors on 15 I have but it is quite annoying as one of the windows is in the ceiling. This is on Home Assistant deconz plugin and it happens from version 2.19 at least.

ebaauw commented 1 year ago

Does v2.20 expose the Aqara sensors through DDF or through legacy? And v2.19?

Smanar commented 1 year ago

There is DDF for lumi.sensor_motion.aq2, since 4 months (last edit on 2.18)

rafuz commented 1 year ago

I don't know how to check for contact sensors (lumi.sensor_magnet)

Found it: xiaomi_mccgq01lm_openclose_sensor

Smanar commented 1 year ago

I have issue on the contact sensor "lumi.sensor_magnet.aq2", but I thought was battery issue (because there was nothing in APS log), I m trying to found the issue.

Edit: Ok so I m not able to find it again, but to resume the problem, it's the same. If work on the 2/3 first open/close, then stay open, you will have new notification on next open, but never on close.

And there is no APS logs

when it work

13:12:49:328 APS-DATA.indication srcAddr: 0xd2e8, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -50
13:12:49:330    asdu: 18000a00001001
13:12:50:561 APS-DATA.indication srcAddr: 0xd2e8, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0006, lqi: 255, rssi: -50
13:12:50:563    asdu: 18010a00001000

Else absolutely nothing.

But like I have said on the issue, was an old device, just used for test, I can't be sure for the battery level (at 100% from the API, but can't be sure as I have issue with the device)

MrSolo570 commented 1 year ago

Read this thread on Home Assistant forum. This issue has been a problem for many for several months. It is not related to the recent release. The problems started probably with the 2.19 series though I actually tried to downgrade to the last 2.18 release and I still have the problem.

The solution in HA land seems to be that more and more give up on Deconz and move to Zigbee2MQTT which does not have this problem. And I must admit I am getting there too.

Can you recommend a way on how to migrate there? I am running deconz add-on with home assistant and I am always afraid of deconz updates. Quite regularly something breaks when updating deconz, just recently I figure illuminance detection for aqara motion sensors got worse...

andys73 commented 1 year ago

ok so I am not going crazy that the iluminance detection for aqara is not reporting correctly. I have some aqara motion sensors that are not reporting at all for a whole day and others that seems to work fine but they are not updating the values as it used to be. It was very reliable some releases ago. I suspect that ddfs are the cause of this as those devices were moved in ddf. Maybe it is a common problem with the ddf template and not the actual ddf. Who can debug the code?

MrSolo570 commented 1 year ago

ok so I am not going crazy that the iluminance detection for aqara is not reporting correctly. I have some aqara motion sensors that are not reporting at all for a whole day and others that seems to work fine but they are not updating the values as it used to be. It was very reliable some releases ago. I suspect that ddfs are the cause of this as those devices were moved in ddf. Maybe it is a common problem with the ddf template and not the actual ddf. Who can debug the code?

LoL this is exactly my problem too. I have an automation that would turn on the light only when motion is detected and illuminance is below a threshold value. But because of the sensor not reporting illuminance reliably anymore it works sometimes (mostly after motion is detected, cooled down and detected again) but other times just not. This used to work 99% of the time last year and got worse with deconz updates...

andys73 commented 1 year ago

ok so who is going to save us from this instability issue... can be escalated with dresden electronics?

pergolafabio commented 1 year ago

The easiest way is to revert back to previous version, it was done before

andys73 commented 1 year ago

I reverted to 6 months backup, the oldest I had and it is still 0 lux. more details in https://forum.phoscon.de/t/xiaomi-motion-sensors-stay-in-the-motion-triggered-state/3218/10

KennethLavrsen commented 1 year ago

andys73. You are highjacking this bug report for an unrelated problem. This bug report is about motion sensors occationally reporting motion after a restart. And this bug was confirmed. The motion sensors work fine after they detect motion once. This bug report addresses the issue with reporting wrong state after restart... sometimes, not always. And I confirmed that I also see it with Philips Hue.

it takes focus away from the original problem when unrelated issues get discussed and we end up with nothing getting fixed

andys73 commented 1 year ago

agreed, sorry. I leave this thread alone and I will log a separate issue. Thanks

ebaauw commented 1 year ago

Ok, deCONZ v2.20.1, mutilated the modelid in the DDF, forcing the Hue motion sensor to be exposed by legacy code. No config/sensitivity, etc (I did cleanup the legacy code after adding the DDF), but the ZHAPresence sensor is exposed alright. Shutdown, patch database, restart, and state/presence is false, as desired. I think the database.cpp code isn't executed for DDF-managed devices.

I still need to figure out where in the code the state is loaded from the database, but I think @manup would prefer to correct this in the DDFs instead. Simply adding "default": false to the state/presence item does the trick.

This is already done in the default state_presence_item.json, but the parse function there, assumes an IAS Zone sensor. For Occupancy Sensing sensors, the item is overwritten in the DDF. So I think it's fair to say it's a bug in each of the DDF files. Mea culpa for the Hue motion sensors; I don't know who did the Aqara and other sensors.

Linked PR fixes DDFs for Hue motion sensors; I daren't touch the DDFs for devices I don't own, but for convenience, here's an overview of the other DDFs containing state/presence. Some do contain "default": false, but definitely not all.

centralite/motion_sensor-a.json
develco/moszb-140_motion_sensor.json
develco/moszb-140_motion_sensor.json
develco/moszb-140_motion_sensor.json
develco/moszb-140_motion_sensor.json
develco/moszb-141_motion_sensor.json
develco/moszb-141_motion_sensor.json
develco/moszb-141_motion_sensor.json
develco/moszb-141_motion_sensor.json
frient/kepzb-110_keypad.json
frient/moszb-140_motion_sensor.json
frient/moszb-140_motion_sensor.json
frient/moszb-140_motion_sensor.json
frient/moszb-140_motion_sensor.json
nedis/nedis_zbsm10wt_motion_sensor.json
owon/PIR313-E_sensor_multi.json
third_reality/3RMS16BZ_motion_sensor.json
tuya/ZY-M100_human_breathing_presence.json
tuya/_TZE200_3towulqd_motion_lux_sensor.json
tuya/rh3040_motion_sensor.json
tuya/ts0202_presence_sensor.json
xiaomi/xiaomi_rtcgq14lm_p1_presence_sensor.json
xiaomi/xiaomi_rtcgqq11lm_presence_sensor.json
xiaomi/xiaomi_rtczcgq11lm_fp1_presence_sensor.json
xiaomi/xiaomi_rtczcgq11lm_fp1_presence_sensor.json

rafuz commented 1 year ago

@ebaauw If I understand correctly I think that this fix should be applied also to the DDF of the contact sensor. It displays the same behaviour at deconz reboot (it stays open until you trigger it) devices/xiaomi/xiaomi_mccgq01lm_openclose_sensor.json

ebaauw commented 1 year ago

Tricky. Contact sensors are stateful and it would be far more common to restart deCONZ while a door or window is open, than while a motion sensor detects motion. Also, contact sensors don't have config/duration, whose timeout could be missed due to restarting deCONZ. I think if you would reset state/open on startup, we'll get people complaining that deCONZ doesn't report the door as open, until it's next closed/opened, or the next periodic attribute report arrives (which might be an hour for Xiaomi sensor using the special attribute report; or never for IAS Zone sensors without Supervision Reports).

I'm afraid here, the only solution really would be "get a decent sensor" (i.e. one supporting periodic attribute reporting/supervision reports). I think the Samsumg multisensor is the only one I've seen that does, and it eats batteries like crazy.

BabaIsYou commented 1 year ago

tuya/ZY-M100_human_breathing_presence.json

I'did this one, I've checked it. It already has the "default": false on state/presence

rafuz commented 1 year ago

@ebaauw I understand the case in which you have a window open during restart and the default should be avoided.

I don't understand the "get a decent sensor" as it was working before and now deconz is not restoring correctly the state at the reboot. You are also saying that a "decent sensor" would eat batteries like crazy as it has to report state periodically. The xiaomi sensor runs on the same batteries from nearly 3 years.

The inteded behaviour for the entity is to restore the previous state from the DB if I understand correctly. Adding a default state in the DDF is a workaround that works only with presence sensors. Think what would happen with a Smoke or Flood sensor. If this issue shows on that class of devices it will render Deconz unusable.

I have multiple automations that rely on the state of contact sensors and from some months they trigger after a reboot of deconz even if the contact sensor has never moved. I only reboot deconz for maintenance so that can be managed but it is not an intended behaviour so it needs additional investigation.

KennethLavrsen commented 1 year ago

@ebaauw I agree 100% with your analysis on contact sensors like window/door sensors. You would never want to reset those to off after restart. And I never saw any of my aqara window/door sensors acting wrong after restart of deconz. It is only Motion sensors. And I believe I have seen occationally that light groups have been reported on for a second but they correct them selves to off (unless they are indeed on) before I have had a chance to think about it.

I have only had the problem with my Motion sensors. I only have two types in my Zigbee network. Philips Hue (both the indoor and outdoor version) and Aqara FP1 (the millimeter wave sensore which is super cool).

The problem comes and goes. I can reset 10 times and all OK and then suddenly it is not OK on random sensors. And this is in a house with noone home and he sensors all being in no motion state when I reset.

I cannot help thinking that either

There is rubbish in the database before we reset
The database is populated with rubbish during reset
The database is fine but the initial code never reads it and the result is the garbage that happen to be in RAM which in 99% of the time is a value that is picked up as meaning no motion detected.

Surely resetting all motion detectors at boot is a good defensive programming strategy and should be done no matter what because if you reset Deconz after motion is detected, risk is high that the sensors sends its off message while Deconz is resetting and the message will be lost and you end up in a false on state. Your strategy of always setting it to off is correct.

But why do we have garbage in rare cases? And maybe in some specific situation the probability is not 1 % false but 99% false. Maybe it depends on other data in the memory location. I would really look very critically at that init code if I were you.

Mimiix commented 1 year ago

But why do we have garbage in rare cases? And maybe in some specific situation the probability is not 1 % false but 99% false. Maybe it depends on other data in the memory location. I would really look very critically at that init code if I were you.

I agree. I have no clue why there's rare cases of this happening. Partly i believe might have to do with bad compatibility between device brands. Osram for example is known to sometime malform requests from devices. Still, we should be able to write something to catch this, right?

I think the additional factor here is that part of deCONZ is not open source (Core) and only visible for DE Employees. That part is (if i am correct) also handling requests so this is not helping either :( I believe there are plans to make it open source.

ebaauw commented 1 year ago

@rafuz

I don't understand the "get a decent sensor" as it was working before

The legacy code reset state/presence (for motion sensors) on startup. Today, this is suppose to be handled in the DDF. The fact that it wasn't (isn't) is a bug, and adding that is a fix, not a mere workaround.

The legacy code has never reset state.open, nor state.smoke not any other state attribute on startup. For other sensors, "it" was not working before.

The inteded behaviour for the entity is to restore the previous state from the DB if I understand correctly

The intended behaviour is for deCONZ to reflect the actual sensor state. The problem is that that's not always possible for all sensors. That problem is caused by the sensor, not by deCONZ.

As I explain above, some sensors cannot be queried for their actual state, because they turn off their radio to preserve battery power. Some "light sleepers" wake up every 5 seconds, and appear to be reachable, albeit with a little delay; "deep sleepers" effectively are unreachable, unless an (external) event (like detecting motion) causes them to wake up. Obviously, light sleepers are more battery hungry than deep sleepers. This has nothing to do with deCONZ; this is how Zigbee works for (battery-powered) devices without Receiver On When Idle.

To cope with this, deCONZ, or any other Zigbee gateway, needs to keep a cached copy of the sensor state, which is updated when the sensor sends state events. The API reports the "sensor state" from this cached copy.

"Decent" sensors don't just send events on state changes, but also periodically, so deCONZ, or any other gateway can re-synchronise the cached state in case of missed events (e.g. while the gateway was down). In addition to not sending periodic events, some problematic motion sensors don't even send a state change events when no longer detecting motion (hence the config/duration workaround to reset state/presence automatically). For IAS Zone devices, the Zone Status indicates where it sends events when the alarm no longer occurs (Restore Reports), and whether it sends periodic reports (Supervision Reports).

deCONZ persists the cached copy of the state in the database, but I suppose that's not always flushed immediately. Especially when deCONZ is killed or crashed, the latest cached state might not be stored correctly. On controlled shutdowns, the database is flushed, as far as I can tell.

I have multiple automations that rely on the state of contact sensors and from some months they trigger after a reboot of deconz even if the contact sensor has never moved.

Please open a separate issue/bug report for these. We would need to know the type of sensor (and what events it sends) and, if possible, the state in the database. I suspect there might be cases that deCONZ could handle better (e.g. force-querying light sleepers on startup), but these have been present for a long time, from before the move to DDF, and are not related to this issue particularly with motion sensors.

ebaauw commented 1 year ago

@KennethLavrsen

Philips Hue (both the indoor and outdoor version) and Aqara FP1 (the millimeter wave sensore which is super cool).

The Hue motion sensors are as decent as they get: they wake up every 5 seconds or so, and, in theory could be queries on startup. deCONZ configures them to report periodically evert 5 minutes (just like the Hue bridge), and they do send "no more motion" events. The FP1 actually has Receiver On When Idle, so is even better in that aspect.

I think when exposed through DDF, deCONZ will actually query the state on startup, unless the device is marked as Sleeper.

I cannot help thinking that either

There is rubbish in the database before we reset

I've never seen that, but it might be prudent to change the service starting deCONZ to make a copy of the database for analysis before starting deCONZ.

The database is populated with rubbish during reset

The only cases when I've seen that is a corrupted uSD card on the Raspberry Pi. In that case the copy of the database would also be corrupted, unfortunately. I think this is where I should remind everyone (including myself) to make (and verify) backups regularly.

The database is fine but the initial code never reads it and the result is the garbage that happen to be in RAM which in 99% of the time is a value that is picked up as meaning no motion detected.

The value of a ResourceItem is initialised (to null, "none", 0 or false) on creation. So if the database restore wouldn't happen, you would expect these default values for the attributes, not garbage.

@Mimiix

I think the additional factor here is that part of deCONZ is not open source (Core) and only visible for DE Employees. That part is (if i am correct) also handling requests so this is not helping either

The (closed source) deCONZ core (with the RaspBee/ConBee firmware) handles the low-level stuff of each incoming and outgoing Zigbee message. The cached state, database, and restore from database are all handled by the (open source) REST API plugin. I've never seen any ghost messages originating from the core, that weren't present on the Zigbee network. Even so, with the right debug settings (--dbg-aps=2), the REST API plugins logs every state message it receives from the core, so this would be visible in the log.

rafuz commented 1 year ago

Thank you for the clarifications, I have partial understanding on how the various sensors works so this is useful for me to try to figure out where could be the problem.

I see that seems that I am the only one experiencing this issue with contact sensors so for sure I will do additional investigation on the status of my sensors (batteries, communication). I have installed them 3 years ago and joined to deconz and never touched again.

I will open a new issue when I am sure that the problem is not on my devices.

SwoopX commented 1 year ago

I got quite some of the devices to be checked and will have a look.

SwoopX commented 1 year ago

@ebaauw Had a look into that as well and used the frient MOSZB-140 for that. While I absolutely agree that there is not automatic reset to false upon start, as the respective code in database.cpp is not used for DDF powered devices, I cannot confirm your mentioned workaround here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6692#issuecomment-1406339763. I would be very surprised if that works, as it contradicts my understanding of the associated code

Extremely simplified, it should work like this:

Load DDF
If no or an invalid value for the 3 functions, default, static or refresh interval is in the DDF, load it from the generic item
Get resource item value
When a saved resource item value wasn't found and therefore no timestamp was set for the item, then set the default value

state/presence has a default value of false in the generic item, which should be applicable regardless if IAS Zone or Occupancy Sensing cluster. For step 2 in the example above, the code finds your added default value in the DDF and therefore does not set or overwrite the default value from the generic item.

I fear we need a different approach to force the reset to false, probably when the resource item is loaded? That would kind of mimic the legacy approach.

Just for the records: Develco/frient motion sensors also have supervision and restore reports, so also some decent devices 😉

ebaauw commented 1 year ago

I would be very surprised if that works, as it contradicts my understanding of the associated code

It seemed to do the trick for the Hue motion sensor in my testing. I have seen some other DDF related weirdness that would disappear on restart, see https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6710. I think I tested only once or twice, maybe it was just the random restart that made it work? Will do some more rigorous testing…

1doubleDD1 commented 1 year ago

Just to add my few cents to the topic... I've been having the same problem lately, with my Osram motion senzor (CentraLite Motion Sensor-A is the official name with Firmware: 30.0.83.16), I also have Aqara and Philips Hue motion sensors and they don't appear to be affected with the issue. After Raspberry restarts Osram motion senzor stays in "detected" state until it's triggered. Since RasPi restarts in the middle of the night, previous state (prior to restart) was definitely "not detected". I haven't noticed this problem on deConz 2.18.2, not sure about 2.19.1, definitely present on 2.19.3 and now on 2.20.1 (I was on 2.19.1 for a relatively short period). Hopefully a solution will be found soon.

EDIT: I'm using HA Container, so no addons

pergolafabio commented 1 year ago

Indeed , in my case the issue only occures on cold boot, if I just restart addon, then there is no issue

thogens commented 1 year ago

confirmed on my end with multiple motion sensors. All show same behaviour. Only after cold boot, I see my Xiaomi motion sensors being switched to "presence". This causes my lights turn on and won't be switched off again until a new motion gets detected and the state is overwritten. Before my cold boot, I made sure that all detections were false. After booting, I see the correct (old) states being shown over the API (using ioBroker plugin). But after some time, this state gets a new timestamp and is being switched to true. Interestingly, some devices aren't even connected by that time, when presence is switched to true. At least reachable state was false. -> Using 2.20.1 with Conbee II, running on Synology NAS with docker.

pergolafabio commented 1 year ago

indeed, only after cold boot ...my open/door sensors is correct though, its only the presense sensors giving issues

ebaauw commented 1 year ago

After booting, I see the correct (old) states being shown over the API (using ioBroker plugin). But after some time, this state gets a new timestamp and is being switched to true.

Is this ioBroker taking some time to refresh its state after deCONZ restarts, or does the deCONZ API actually change its reported state? Does deCONZ send a web socket notification? Which timestamp gets updated? lastupdated? lastseen? lastannounced? Or a timestamp in ioBroker? Does it change to the current time (when the change occurs) or to a previous time?

dresden-elektronik / deconz-rest-plugin