Deconz-rest-plugin: Xiaomi motion, not detected state, takes 5 min instead of 2

[pergolafabio]

Normally , my xiaomi motion sensors are in “not detected” state after 2 minutes of no movement… Now it takes 5 … Also in phoscon I see movement detected… What can be the cause? Battery failing? It’s only one sensor behaving like that, others are fine…
It’s still reporting 100% as battery state…

Thnx

[pergolafabio]

i have looked in debug, the duration is still set to default 90 , like all others
what could be the issue?

2020-03-02 12:18:08 DEBUG (MainThread) [pydeconz.deconzdevice] Xiaomi_Sensor_4 created as 
{'config': {'battery': 100,
            'duration': 90,
            'on': True,
            'reachable': True,
            'temperature': 2400},
 'ep': 1,
 'etag': '42d2933174e8db23e4251268ad96eb46',
 'manufacturername': 'LUMI',
 'modelid': 'lumi.sensor_motion.aq2',
 'name': 'Xiaomi_Sensor_4',
 'state': {'lastupdated': '2020-03-02T11:12:38', 'presence': False},
 'swversion': '20170627',
 'type': 'ZHAPresence',
 'uniqueid': '00:15:8d:00:03:66:78:fa-01-0406'}

[HerrHofrat]

I have the same issue with the docker image marthoc/deconz:armhf-2.05.74 - the timeout for the motion sensor with this version is 5 minutes. I rolled back to marthoc/deconz:armhf-2.05.73 and there the timeout is working fine with 90 seconds.

[pergolafabio]

And how is your duration configured? Mine is 90, like it should be...

Also my other same xiaomi work fine, it's just one...

[HerrHofrat]

Sorry - mine is also configured to 90 seconds.. so 2.05.73 is working as expected while 2.05.74 increased the timeout to 5 minutes without any config changes

[pergolafabio]

That's strange... Di you have multiple xiaomi?

[HerrHofrat]

Yes, 3 of them - all have the timeout falsely increased with 2.05.74

[pergolafabio]

Ok, seems a bug then...
I see now .74 also includes a new firmware for my conbee 1, gonna update later...
But strange that only 1 detector for me is impacted... Others not

[pergolafabio]

i tried overwriting the duration to another value, doenst help also , its stuck on that 5 min

[pergolafabio]

How do you roll back to an earlier edition? I am running deconz as add-on on HassOS

[HerrHofrat]

I use docker for home assistant and deconz, there I can specify the older image version. I'm not sure if rolling back is possible in hassio, sorry

[pergolafabio]

Ok, thx..
@manup , is this confirmed as an issue with .74 ?

[SwoopX]

Can you please try the following: In deconz gui, select the occupancy cluster and then double click on the first attribute (0x0000). Read the reporting values, most probably the max reporting intervall will be 300. Set it down to 120, write the config and check if the behaviour changes to what it was on .73.

[pergolafabio]

hi @SwoopX , is this the correct place? i always get reading failed... see screenshot

also for my other "working" sensors, is see reading failed
do i need to make a movement detection when i click on the "read" button maybe?

https://www.dropbox.com/s/so3gq6jc00lcbdw/occupancy.JPG?dl=0

[pergolafabio]

oh, i see was pressing the wrong "read" button, there is also below a "read config" button
but that also gives me a "reading config failed" message ...

[pergolafabio]

i can mayby try a "write config", allthough i want to know first what the (default) values were before like
min report interval, max report interval, reportable change...
@HerrHofrat , can you try it? does it work for you when you do a "read config"?

[SwoopX]

I'd say those lines might be responsible for the observed behavior. As a generic binding for Xiaomi devices has recently been introduced (to provide support for newer ZB3.0 devices), a default reporting value of 300 would apply which is greater than 90 or 120.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/c69b8323051a90dd78035025ffe174df7370f440/de_web_plugin.cpp#L6267-L6285

If that causes trouble or disturbance, we should revert that in terms of sharpening for individual devices.

@ebaauw What's your opinion on this. Do you maybe know from history, why the check "report.maxInterval > config.duration" has been introduced and reporting has been given precedence?

[pergolafabio]

Ok, thnx for feedback... But can you tell me what I do need to filling in those 3 boxes todo a write config? Wanna know the default before breaking things ;)

[SwoopX]

You cannot really break anything if you neither can't read nor write ;)

Code-wise, the defaults should be as follows when reporting is active and configured

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/c69b8323051a90dd78035025ffe174df7370f440/bindings.cpp#L867-L870

[pergolafabio]

Ok, min 1, max 90, and what about the box: reportable interval, should that be blank?

[SwoopX]

Indeed

[pergolafabio]

hmm : writing config failed :(

so i cant fix it?
but what i dont understand, i have 4 xiaomi motion sensor, only 1 is affected
if this is a global change since .74 , why are the other 3 not impacted?

[SwoopX]

Good question. That was the only change I personally could think of in this regard. Was the device freshly joined after the update to .74?

[pergolafabio]

no, all devices were already in place for some months

[L3H0]

@pergolafabio do you have HACS installed?

[pergolafabio]

yes, why ?

[L3H0]

@pergolafabio Which version? In version 0.22 was bug with Xiaomi sensors.

[pergolafabio]

yeah, but was that not only with xiaomi gateway instead of conbee?
i have already 22.1

[L3H0]

@pergolafabio Hmm i was thinking that not only with Xiaomi gateway. I have 5 Xiaomi motion sensor (modded) and i don`t have any problem with them on the latest docker image.

[pergolafabio]

because you have the hardware mod :)

is HACS responsibe for the interval update on a xiaomi sensor?

[L3H0]

@pergolafabio Did you see this - https://github.com/home-assistant/core/issues/32387

[pergolafabio]

yes, but thats not related
in my case the sensors are working as expected, i see state changes
only 1 sensor, the change to "not detected" is only changing after 5 min, instead of 2 min
my other 3 sensors are working as expected

[L3H0]

@pergolafabio Do you re add it again? And the problem still exist?

[pergolafabio]

do you mean deleting the device in phoscon and then pair it again?
no, didnt try that yet

[L3H0]

@pergolafabio Yes, delete it and add again.

[pergolafabio]

ok, will do when i am home :)
is it possible that Hacs 22.0 did "something" with a sensor? although it was not related to conbee? but to xiaomi gateway ?

[pergolafabio]

ok, fixed

deleted and readded, now its back on default timer
but i wonder what could be the root cause of this?

[HerrHofrat]

Can confirm, after rejoining all of my motion sensors it seems to work again

//edit
after a couple days of testing it still happens occasionally

[pergolafabio]

My problem is back, this time another sensor... What can be the cause of this? Cause of this issue, my lights are longer on... ;)

[ASNNetworks]

Same issue here with 2 out of 6 sensors. I re-paired them and they were 90 secs after two days they were 5min again. This really sucks and ruins any automation for me. Kinda frustrating as to why this happens..

[pergolafabio]

Yeah, ,what can cause this? The duration is still 90 secs, and why only some sensors impacted and not all? In my case it's 1 of 4 ,and totally different

[MunkeyBalls]

Take this with a grain of salt because I received my motion sensors after this bug was introduced.

Since even the 90s is too long for my tastes I started looking around if there's a way to decrease it and found this thread: https://community.smartthings.com/t/making-xiaomi-motion-sensor-a-super-motion-sensor/139806

Now this is obviously about 5s vs 60s, but I see people reporting that the sensor after pressing reset (which you probably did when you re-paired) goes into 5s mode for about a day and then falls back to 60s mode. Sounds like what you are experiencing but just with longer delays, maybe try and hit reset and see if it goes into short timeout mode again?

Btw, I'm planning on doing this hack, I'm wondering if anyone already tried this with Deconz?

[pergolafabio]

I can try that , will post feedback

[ASNNetworks]

I have and it works great, but will have to test a few days to make sure everything works properly. I applied the mod and the lux changed every 5s, but the state dit not turn off. Make sure you set an automation so the sensor turns off. Check the link below for the automation. Btw: I just used a 4B pencil and worked :)

https://community.home-assistant.io/t/xiaomi-human-body-motion-sensor-timeout/23398/391?u=asnnetworks

[HerrHofrat]

It did not work for me - I also changed the batteries in the meantime and pressed reset - for the first our or so the update interval is indeed 5sec - but after that it reverts back to 300sec

[ebaauw]

@ebaauw What's your opinion on this. Do you maybe know from history, why the check "report.maxInterval > config.duration" has been introduced and reporting has been given precedence?

Sorry, @SwoopX, I must have missed this question earlier. No, I don't know when this was introduced, nor why. de_web_plugin.cpp is too big for GitHub, so I cannot check the blame history for the file, to see which commit introduced it.

I don't understand the logic. I could understand checking the _minimum_ reporting interval here (that limits event-based reporting), but not the _maximum_ interval, that sets the periodic reporting interval. The comment suggests checking that the maxInterval is larger than config.duration, but I see no such check.

I don't know the Xioami motion sensor, but most Xiaomi devices do not support reporting configuration settings. Does it even have a _Occupancy Sensing_ or _Binary Input_ cluster (which has the same code)? Or is it an _IAS Zone_ device? I have no clue what the default val.maxInterval would be. There's also no check if the value is 0xFFFF, which would indicate periodic reports are disabled.

[pergolafabio]

Same here, took battery out and reset... Still set to 300 secs :(

[ebaauw]

Note that there’s two issues here:

• A hardware issue with the sensor that it will only fire the next “motion detected” event after 60-90 seconds. The hardware mod should reduce this to ~5 seconds.
• A software issue in the REST API plugin that it won’t honour config.duration and only clears state.presence after five minutes. Note that this sensor does not send “no more motion detected” messages, so clearing state.presence is handled autonomously by the plugin.

There might also still be the issue that, on startup, the plugin forces config.duration to be at least 90 for this sensor. While this makes sense for the sensor in original state, it doesn’t when you’ve modded the sensor. You can set `config.duration to a smaller value alright, but it gets reset when restarting deCONZ.

[pergolafabio]

Let's stick to the original issue here, that's the software one...

So setting the config.duration with an automation should help? Untill deconz restart? Ok I can try that, and maybe set the automation on HA startup....

Allthough I remember I already tried that

[ASNNetworks]

Let's stick to the original issue here, that's the software one...

So setting the config.duration with an automation should help? Untill deconz restart? Ok I can try that, and maybe set the automation on HA startup....

Allthough I remember I already tried that

No it won’t help by only using the automation. That’s what has been told multiple times, also on HA forum where you posted a few hours ago and in the past. In order for this to work right now you NEED the hardware mod AND the automation.

Or you have to wait till they update Deconz to fix this.

[pergolafabio]

Ok, then we will wait for deconz to fix it

[SwoopX]

Sorry, @SwoopX, I must have missed this question earlier. No, I don't know when this was introduced, nor why. de_web_plugin.cpp is too big for GitHub, so I cannot check the blame history for the file, to see which commit introduced it.

@ebaauw no worries, shit happens ;)

I don't understand the logic. I could understand checking the minimum reporting interval here (that limits event-based reporting), but not the maximum interval, that sets the periodic reporting interval. The comment suggests checking that the maxInterval is larger than config.duration, but I see no such check.

I don't know the Xioami motion sensor, but most Xiaomi devices do not support reporting configuration settings. Does it even have a Occupancy Sensing or Binary Input cluster (which has the same code)? Or is it an IAS Zone device? I have no clue what the default val.maxInterval would be. There's also no check if the value is 0xFFFF, which would indicate periodic reports are disabled.

I don't really get it either. I also don't have one of those here, so I cannot check that quickly. However, binding was allowed for all lumi devices earlier and it all seemed to start with that. Funny thing is that I've never seen a successful attribute reporting response from any Xiaomi sensor. Therefore, it shouldn't have caused any harm, but user experience tells a different story (binding will be reverted in the next release). At least the code passage I mentioned earlier was the only one I found which could potentially impact sensor behaviour, without digging too deep. A little bit too much of coincidence for my taste.

[pergolafabio]

For information, I have 4 xiaomi, 1 was impacted... They are all connected to a Ikea plug as router...

I was adding a new Ikea on/off , per mistake I paired the on/off switch directly to the Ikea power plug... So the power plug was gone from the deconz network.. ;)
So none of my xiaomis were working...
I added back the Ikea power plug... Connected all xiaomi again by short pressing the reset button...

They were all connected again, and also that one specific with 300 secs , is back at 90

[pergolafabio]

omg, now its another sensor thats imtpacted
this is so frustating

[alessandroceleste]

I have exactely the same problem.

[pergolafabio]

is there nothing we can do to test at this moment?

[falcon2k16]

The same problem was detected on my network. After one week or a little bit more some of my motion sensors are triggered and the timeout defaults to 5 minutes regardless of the config option for deCONZ to update the sensor after 15 seconds. From a total of 5 sensors, only 2 are affected and a battery change doesn't do any difference. All of my sensors are tweaked, so they update every 5 seconds. I'm using the ConBee II with the Home Assistant add-on. Is there a setting in the node config that we can update to resolve this or is our only option currently to remove and re-add the node?

[dasoho]

Same issue here! I would also highly appreciate a fix for this problem :-)

[dasoho]

The only observation I could add is that I didn't do any change in network configuration (no devices added/removed) neither I did a restart of deconz. It simply happened anytime between yesterday evening and today afternoon:

"2020-04-14 20:44:00"   "MotionHallwayBasement"          "HUEDEVICE"    "state: motion"
"2020-04-14 20:45:30"   "MotionHallwayBasement"          "HUEDEVICE"    "state: nomotion"
"2020-04-15 14:14:31"   "MotionHallwayBasement"          "HUEDEVICE"    "state: motion"
"2020-04-15 14:19:31"   "MotionHallwayBasement"          "HUEDEVICE"    "state: nomotion"

[pergolafabio]

Yeah, it's completely random, once it happens, I think it stays on that timeout

[MunkeyBalls]

For what it's worth, I did the hardware mod on all my aqara sensors (which takes about 5 minutes per sensor) and now my sensors are triggering every 5 seconds. I think even the 2 min timer is too much for my taste. The long delays makes it really hard to combine the aqara motion trigger with other triggers, like for example opening/closing a door and shutting of your lights if no motion is detected within 30 secs.

[pergolafabio]

Indeed, but this should be resolved without hardware mod.. we are aware of the 90-120 sec delay... I don't care... But 5 min is too much

[mbo18]

I have the same issue. Had to remove and repair the motion sensor to be back on 90s instead of 300

[ASNNetworks]

I have the same issue. Had to remove and repair the motion sensor to be back on 90s instead of 300

Most likely it will revert back to 300s after a while. So I would keep an eye on it.

[falcon2k16]

I have noticed that when the timeout is increased instead of un-pairing and pairing the motion sensors again a reboot of deConz docker container is sufficient. I'm using the Home Assistant add-on if that gives anyone any additional information, however, I can't find anything in the log itself that would explain the timeout increase and it happens randomly, so for some sensors, I don't notice it immediately

[pergolafabio]

Hmm, restarting docker doesn't help for me... Strange...

Only repairing

[pergolafabio]

is there some progress on this issue?

thnx in advance

[Willybits]

Same problem here, took a while before I found this. Thought it was a problem I caused in node-red first. Hope a fix is in the works!

[jdbrookes]

Hope this issued is identified and resolved soon. I've begun moving my xiaomi devices from the xiaomi hub over to deconz and whilst everything is generally working well, 5 minutes is hugely excessive and causes many issues with automations in Home Assistant.

[pergolafabio]

So the hub was not impacted? So this confirms it's a deconz issue?

[jdbrookes]

So the hub was not impacted? So this confirms it's a deconz issue?

Yes it's an issue specific to deconz as I still have two xiaomi aqara motion sensors on the xiaomi hub that reset after 2 minutes or less.

[pergolafabio]

I see a new release, V2_05_76

Will it fix it?

[Smanar]

Ha it's something related to deconz ?
Someone have tried to sniff the network to see if there is realy a request before the 5 mn ?

Because this bug is still random ?

[jdbrookes]

I see a new release, V2_05_76

Will it fix it?

Don't see any mention in the release notes.

This device definitely resets after 60 - 120 seconds or something like that, because when it was paired with the xiaomi hub and integrated with home assistant I would see the motion sensor trigger, remain active for about 60 - 120 seconds, then go inactive. Seconds after going inactive another movement could trigger it. My lights rely on this. This also used to be the behaviour in deconz until recent months.

[SwoopX]

It has reverted the only settig back to what it was in .74 which could potentially be responsible for that. However, I somehow doubz that it has or had any effect even before...

[Willybits]

For me the problem is fixed after updating to 2.05.76!

[pergolafabio]

So what was the setting that was reverted that was causing it?
I am going to try tomorrow

[SwoopX]

Binding and attribute reporting has been allowed for all Xiaomi devices. However, most of then, especially sensors, don't support it. That's also why there shouldn't have been any impact but regardless, after that change, this thread gained more tone. So the setting has been reverted as it was before.

[pergolafabio]

Confirmed as fixed, closing now ;)

Thx a lot!

[pergolafabio]

anyone upgraded to : 5.5.5 , and confirms the issue is back?

Downgrade deCONZ to 2.05.75, since it has been reported that 2.05.77, and possibly also 2.05.76, is causing issues for several users.

i am still on 5.3.4 , its stable here for me

[Willybits]

I had a rock solid experience again with 2.05.77, for me most problems were caused by issues with HassOS 4.8. I did update Deconz yesterday, not knowing it was a downgrade to 2.05.75.

This Xiaomi issue is indeed back again and should be re-opened

I restored a backup, now on 5.3.4 again as well

[pergolafabio]

Ok, ill reopen for now, but in my opinion it will be fixed soon, we will see probably a bugfix soon

[SwoopX]

I'd appreciate if we could keep that issue closed as it has been more or less confirmed being resolved with .77. The mentioned downgrade is a totally different issue #2875, so let's keep this one clean.

[pergolafabio]

ok, closing

[pergolafabio]

Hi @SwoopX is this fix still included in .78 release?

I am still running 77 on my HA, didn't downgrade yet, cause .77 was stable for me

Thnx

[SwoopX]

Why should it not?

[pergolafabio]

Not sure, maybe some things reverted... I don't see this xiaomi fix in the release notes, also not in 76 or 77, so not sure what fixed it

[SwoopX]

Was that commit cab5dac. Kinda to small to be mentioned and unclear if it would resolve the experienced behaviour. I still have my doubts that it was responsible, but I also got no device for testing.

[pergolafabio]

thats indeed real small =)