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

[pergolafabio]

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

[thogens]

I did another experiment: Just rebooted the Deconz container. Outcome: In phoscon all motion sensors were set to "presence detected", but "last updated tag still shows old timestamp". ioBroker Deconz plugin showed old "not present" data with correct timestamp. -> After rebooting the Deconz plugin within ioBroker, all states were set to "presence=true". "lastupdated" has the "real last update" entry (2h ago for example), but in that datapoint there is a new "lastupdated" timestamp stored. (rebooting time). Does that help, or is it too confusing?

[ebaauw]

So upon restart, deCONZ reports presence with the lastupdated value of when motion was last detected. It would seem that the database doesn’t get updated when deCONZ resets presence because of config/duration. That’s probably a bug in its own right, but went unnoticed due the reset in the legacy code upon load from the database.

And, I understand, the ioBroker plugin maintains its own timestamp when it refreshes its state from deCONZ.

[thogens]

Correct! Upon restart, it takes 5mins or so until (all of a sudden) all motion sensors are set to presence = true. It really takes a while. Like some sort of timeout?! - Before, they are shown as "not reachable". The timestamp is indeed showing the timestamp from the last detection = true, not the timestamp of the detection = false. So basically "lastupdated" is overwritten by an old value. Just tried it again.

[ebaauw]

It would seem that the database doesn’t get updated when deCONZ resets presence because of config/duration.

Indeed, checking the code a call to sensor->setNeedSaveDatabase(true); is missing from checkSensorStateTimerFired(). Not just for state/presence for ZHAPresence sensors, but also for state.vibration for the lumi.vibration ZHAVibration sensor and when generating fake x001 hold events for lumi.sensor_switch and Friends of Hue switches.

That would explain why the issue occurs so much more than one would expect for just missing a config.duration timeout during a restart.

[francescopeloi]

Hi,

sorry to add more noise but after reading this thread I am not sure if the problem described here applies to me too.

I've got 13 Hue motion sensors in my setup and 3 of them recently started not detecting motion anymore, they say always "Motion: none" on the webapp, even though they show a refreshed timestamp of not to long ago (seconds).

Restarts do not help.

Could this be the same issue described in this thread?

[SwoopX]

@ebaauw Nice catch! Unfortunately, however, I do not believe that solely that change resolves the observed behavior. Based on the tests over here, I've seen quite some presence sensors loading into a true state directly after deconz start (while they had a default of false, verified with some extended logging).

We should probably discuss with manup when he's back if we want to mimic the force to false also in the DDF related code. Shouldn't be too hard after all.

@francescopeloi No, that is something different not belonging here.

[rafuz]

So, I have some fresh information about this same issue on magnet contact sensor from xiaomi. This is the situation before reboot:

Sensors are closed. This is after:

The most interesting part is that the sensors that are reading "open" have a last updated timestamp referring to the last time it was opened (yesterday).

[SwoopX]

With regard to the timestamp, I guess there's some room for improvement. What happens when a device value is updated is, simplified, that its value will be saved to DB (certain conditions apply to have some throttling). However, the resource item lastupdated is not saved in that course of action. That can leas to such a "nonsense" timestamp like you have it here.

For my taste, your issue with the open state is something different that presence, as the mechanism behind it is considerably different. Weird though, no doubt about it.

I had a more closer look on the DB save actions the last days. In my opinion, things work a bit unfortunate regarding order and what's saved. I also feel the save action supposed to kick in upon closure of deconz is not working anymore. I'd have some comparably easy fixes in mind for some issues here, but we need to have manup involved here as well to support spotting the places where stuff goes wrong...

[ghost]

Conbee II Version 2.20.01 Firmware 26780700

I have a problem with RTCGQ14LM (lumi.motion.ac02)

I put e.g. duration to 120

{
"duration": 120,
}

or sensitivity to 1

{
"sensitivity": 1,
}

Shortly afterwards, these values are reset to the standard "duration": 30 and "sensitivity": 3, the same applies to ledindication

{
    "config": {
        "battery": 100,
        "duration": 30,
        "ledindication": false,
        "on": true,
        "reachable": true,
        "sensitivity": 3
    },
    "ep": 1,
    "etag": "a996cf7fa7d89b88ab9ec03b120823fc",
    "lastannounced": null,
    "lastseen": "2023-03-04T11:38Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.motion.ac02",
    "name": "Motion 1",
    "state": {
        "lastupdated": "2023-03-04T11:39:20.044",
        "presence": true
    },
    "swversion": "0.0.0_0006",
    "type": "ZHAPresence",
    "uniqueid": "54:ef:44:10:00:52:c4:d2-01-0406"
}

[SwoopX]

@JanLp Please do not hijack the issue with something which doesn't belong here. You're welcome to ask your question in the forum. Thanks!

[ghost]

I thought it was related to 😊 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/6692#issuecomment-1410886917

[thogens]

I thought there was a fix planned for 2.21.0-beta. But after updating to that version, it still shows same behaviour with Aqara/Xiaomi motion sensors. Any update?

[ghost]

I thought there was a fix planned for 2.21.0-beta. But after updating to that version, it still shows same behaviour with Aqara/Xiaomi motion sensors. Any update?

Same wonder here

[francescopeloi]

and here

[manup]

There were a bunch of fixes related to motion sensors. Does the problem still occur with current version?

[ghost]

There were a bunch of fixes related to motion sensors. Does the problem still occur with current version?

Yes

There were a bunch of fixes related to motion sensors.

What correction of the many do you refer to when you ask if the problem is resolved? I ask because one and more are going more into rules than solving problems ...

[francescopeloi]

Nothing changed for me, both my 2 Xiaomi vibration sensors are always showing as status "vibration detected", even after the upgrade to the latest deconz version and a reboot

[manup]

I've linked the respective PRs to this issue. Guess we need more debugging, I have the lumi.sensor_motion.aq2 in my setup which doesn't show the problems. @SwoopX maybe there are some relevant differences between the DDFs?

[thogens]

Update: I updated from 2.21.0-beta zu latest 2.21.2 and it seems that the problem with motion sensors is gone. Will do several more tests, but first look seems promising. Thomas

[manup]

@thogens thanks for testing, if the problems are settled feel free to close the issue.

[thogens]

Just double checked. Problem fixed. How can I close this bug?

[pergolafabio]

There :-)

[djsomi]

Hi all,

Today I had the same issue with 2.25.00. Restarted it, and after I get a tons of sensors reported ON state. Mostly it was window/door sensors, and the more painful 5-6 leak sensor, I had to pick every piece to stop alerting. :(