Open jan666 opened 6 days ago
SwoopX
commented
6 days ago Was finally able to reproduce that in my production network (may it rest in pieces 🙂 ) with a full blown debug collection. I let it run for some additional minutes and then I'm super curious what is to be found.
SwoopX
commented
6 days ago So, what I can conclude from my debug log is the following:
Deconz is loading everything as it should on startup. It seems to be key to reproduce the issue that one pairs a device which is not yet known to deconz, meaning there is no cached DDF. When now searching for new devices, it gets paired as it should. When all necessary data is queried from that device, function &DeviceDescriptions::get(const Resource *resource, DDF_MatchControl match) is called and subsequently calling loadDDFAndBundlesFromDisc(resource).
With the latter call, things apparently go south when all DDFs are read again. The DDF for the newly added device is working, but everything else ceases working. As if the handles are destroyed or not appropriately refreshed. As the new device is known from then on, this also explains why a deconz restart brings everything back to life: everything is freshly loaded and only once.
I'm pretty sure I added the new device first with running GUI, but there the strange behavior did not show up. Afterwards, I tried in headless mode and had it reproduced. From an API perspective, all other devices just emit a lastseen upon any value change.
sch115
commented
3 days ago I am having the same issues on Raspberry with Deconz GUI and Conbee II, running latest versions. Sensors such as Temperature and Open/Close stop sending updates even after restarting "Unifi Protect" Child Bridge only. I can also confirm this behaviour after searching for lights as mentioned above.
ebaauw
commented
3 days ago Saw something similar last weekend (also on a Pi with GUI enabled). After a Hot Reload of a DDF (for a CO sensor), the light level and temperature reports (and read attribute responses) for my Hue motion sensors were ignored by the API. They would be reflected in the GUI. Oddly, the presence reports continued to be handled by the API?
sch115
commented
3 days ago Yes, everything is still visible and linked in GUI during this issue. And only full restart of the gateway brings it back to work. I also think Hue Wall Modules were impacted too but can't be really sure about this one since at that time I've had no idea the sensors aren't reporting.
mtressl
commented
17 hours ago following...
I see a similar bug /behaviour in my network. Some sensors (Xiaomi) stop reporting but not all of them.
Does the issue really belong here?
Is there already an existing issue for this?
Describe the bug
Produkt ConBee III Gateway Version 2.28.1 Firmware 26500900
I noticed this in the latest stable version before 2.28.1, too: when I search for lights (and add a light, have not tried without adding one) most(?) of the sensors stop sending updates via REST-API/WebSocket. This affects temperature sensors like SONOFFs, open/close sensors from Ikea and also the ZHAPower, ZHAConsomption etc from Ubisys Window Covering devices. So I guess this is more a problem updating the values and not related to zigbee communication? Controlling lights and window covering devices still work.
https://forum.phoscon.de/t/headless-deconz-no-more-sensor-updates-after-searching-for-lights/5120/1
Steps to reproduce the behavior
Search for lights
Expected behavior
Sensors should Update After searching for lights
Screenshots
No response
Environment
deCONZ Logs
No response
Additional context
No response