Conbee III (3) latest Firmware wrong states after a restart of deconz with Xiaomi (vibration,door sensors)

cracyfloyd commented 6 months ago

Does the issue really belong here?

[X] I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

[X] I have searched the existing issues and there is none for the bug at hand

Describe the bug

i use now a conbee 3 stick with the latest firmware (08.12.2023). Before i use the conbee 2 without this problems. When i restart my computer (deconz-docker) there are some (not from all sensors same type) states are wrong (open/close/vibration). this is only gone when i use activate manual the sensor some times. (open-close windows or make vibration). i use the latest deconz version 2.24.2 (i try also 2.5 beta)

its not the same sensor every time, its changed, sometime there and other reboot a another sensor with wrong states.

Steps to reproduce the behavior

restart docker container and wait.

Expected behavior

manual change of the states sometimes.

Screenshots

deconz

Actual are no vibration and no windows are open !!!!!

Environment

Host system: PC Debian12 Docker
Running method: Marthoc Docker container
Firmware version: (264E0900)
deCONZ version (2.25.0 beta)
Device: ConBee III
Do you use an USB extension cable: yes
Is there any other USB or serial devices connected to the host system? No

deCONZ Logs

No response

Additional context

No response

Smanar commented 6 months ago

I think just need to update the defaut state ? When you reboot, deconz take a defaut state, waiting for the first device report (that can take 1 hour), you haven't this problem before ?

his is only gone when i use activate manual the sensor some times

"Some" ?, only one is not enought ?

cracyfloyd commented 6 months ago

Yes i dont have this Problem with my older Conbee 2 Stick. Never. I use it for around 2 Years. I tried again with the conbee 2 and this problem is gone. I switch back to conbee 3 and the problem is there.

Mostly 1 time. Hehe

SwoopX commented 6 months ago

Tbh, I have high doubts that the Conbee plays any role here. That fact that we only see Xiaomi devices in the screenshot adds to that a lot. Upon restart, deconz loads the previous device states stored in the database. If you shut down when a vibration sensor reports vibration, than that state will be restored. Given that Xiaomi devices are all deep sleepers, the device states cannot even be ready at will, so the loaded states could not be overwritten. Assuming Conbee does anything in this context would mean it receives/adds ghost traffic, which I consider extremely unlikely.

Changing any default states doesn't make any sense at all, as this would only work for new devices/sensors, which do not yet hold any stored item values.

A deconz startup log could give clarity on the loaded values and the exposed states.

wvuyk commented 6 months ago

Looks a lot like this one, which fails to get attention? https://forum.phoscon.de/t/aqara-door-sensors-show-open-on-restart-of-deconz/3686

cracyfloyd commented 6 months ago

There seems to be there is a bigger problem between xiaomi and the conbee 3. i now make a clean install with a clean conbee 3 stick. (reset). now i try to learn only one vibrationsensor. it seems to bee that the device are found but it dont use the ddf file, its only works in straight mode. the setting are that the software can use the gold ddf files. so iam completly confused. See picture and log file:

Bildschirmfreigabe Bild 30 Dezember 2023 um 10 36 59 MEZ

_deconzcon3-stacks_logs.txt

cracyfloyd commented 6 months ago

Looks a lot like this one, which fails to get attention? https://forum.phoscon.de/t/aqara-door-sensors-show-open-on-restart-of-deconz/3686

ah thats interesting. iam not alone.

Mimiix commented 6 months ago

Looks a lot like this one, which fails to get attention? https://forum.phoscon.de/t/aqara-door-sensors-show-open-on-restart-of-deconz/3686

This was answered somewhere before. @SwoopX can you help me find it?

wvuyk commented 6 months ago

@Mimiix It was solved before indeed, several releases before DDF development started. I have been searching for it several times, but could not find it back somehow.

It was working fine until around April this year, that is where the issue resurfaced after a larger DDF rollout. I am guessing the solution that was originally implemented was removed with code cleaning maybe?

manup commented 6 months ago

I guess we need a declarative approach to define in a DDF how the state of specific items should be restored or reset after startup :thinking: and perhaps finer control of if/when things need to be written to the database.

For the values themself it shouldn't make any difference if ConBee II or III. Except if the device behaves differently when paired via classic Zigbee join (ConBee II) or Zigbee R22 join (ConBee III), I think we've already seen weird differences here in the past even so far that Xiaomi devices behave differently if they think to join to a Xiaomi gateway vs a 3rd party one — here we applied some nasty stuff for ConBee II to fake being a Xiaomi gateway. The next deCONZ release contains the code to do the same for ConBee III but also needs a small update in the firmware which should arrive in < 2 weeks.

Luigi-01 commented 6 months ago

It is not only with xiaomi device, I am back to my Conbee II stick. To many strange things, Osram device have issues with the Conbee III. Even going back to the Conbee II has not solve all issues, but now thing works again. My setup was running stable for 2 years, but after the Conbee III experiment, things became instable. The firmware for the Conbee III is not yet 100%.

jamieshaw commented 6 months ago

Apologies if I'm tacking myself onto this as a similar, but different issue — but I've been having this issue since upgrading to 2.24.2 back in November on a ConBee II stick. Since upgrading, it seems that no writes to the DB are being made for a subset of Aqara devices. All but three Aqara devices show the lastseen and other similar timestamps as the time of the upgrade.

Rebooting the host VM causes the state to revert to "open" (they weren't open at the time, it was 5am in the morning), and manually triggering an update using the Aqara sensor's button correctly updates the state, until the VM is restarted.

This seemingly wasn't an issue before 2.24.2 (having upgraded from 2.23.2).

I can confirm that zll.db is being updated as evident by the OS, and a lone Aqara vibration sensor that is receiving updated timestamps. Most sensors recorded in deCONZ are Aqara's door/window sensors, and are largely the culprit here.

MSL-DA commented 6 months ago

Apologies if I'm tacking myself onto this as a similar, but different issue — but I've been having this issue since upgrading to 2.24.2 back in November on a ConBee II stick. Since upgrading, it seems that no writes to the DB are being made for a subset of Aqara devices. All but three Aqara devices show the lastseen and other similar timestamps as the time of the upgrade.

This seemingly wasn't an issue before 2.24.2 (having upgraded from 2.23.2).

I can confirm that zll.db is being updated as evident by the OS, and a lone Aqara vibration sensor that is receiving updated timestamps. Most sensors recorded in deCONZ are Aqara's door/window sensors, and are largely the culprit here.

Same here.

francescopeloi commented 6 months ago

and here

subatomike commented 5 months ago

Same behavior right after upgrading from 2.23 to 2.24.2. Five out of ten Aqara door/window sensors were shown with wrong status at the first restart of deconz after upgrade. Using Conbee II and windows.

cracyfloyd commented 5 months ago

I hope that will be fixed fast, because i must go on every deconz restart and aktivate manual all door/window and vibration sensors that they get the right state. please please please fixed this problem. i have this problem with conbee 2 and conbee 3. i test both.