Headless deCONZ - no more sensor updates after searching for lights

[jan666]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

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

• Host system: (Raspberry Pi / PC / NAS / MAC)
• Running method: (Raspbian / Ubuntu / Home Assistent deCONZ Add-on / deconz-docker container / Windows / Virtual Machine)
• Firmware version: (26xxyy00)
• deCONZ version (not Home assistant Addon version!): (2.xx.yy)
• Device: (ConBee I / ConBee II / ConBee III / RaspBee I / RaspBee II)
• Do you use an USB extension cable: (yes / no) -- only relevant for ConBee I/II/III
• Is there any other USB or serial devices connected to the host system? If so: Which?

deCONZ Logs

No response

Additional context

No response

[SwoopX]

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]

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]

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]

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]

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]

following...

I see a similar bug /behaviour in my network. Some sensors (Xiaomi) stop reporting but not all of them.

[RneeJ]

I can confirm the same behavior in my previous install (headless), same application versions.
For days there was nothing wrong and sensors updated regulary.
Reporting stopped for some sensors then all stopped.

Now i have a new install with desktop environment on a RPi 5.
Also i added 3 extra (mains powered) routers to keep a strong all covering signal.
I keep the deCONZ application up for now.
Maybe this helps.

Will report back in some days.

[ThePhiMuc]

I think, I've the same issue :-(
Whenever I add any new device to my deCONZ network, all my Philips Dimmers/Switches stop working (and yes, I had some "stopping" window-sensors, too, but I didn't focus on that).
The switches are configured using NodeRed - I've set a debug node and can see: the switches don't send any recordable signals (I think they do, but those seems to be "lost" within deConz so they don't arrive at NodeRed).

Ass soon I delete the new device and restart deConz (GUI here), everything is running fine again.

What I've seen at the GUI:
As soon a new device is found, it's listed with an ID first. After a while the correct name is shown. THIS is the moment, the Switches stop working.
If I do a restart of deConz now (without deleting the new device via GUI or Phoscon), the new device still appears within the GUI after the restart - but with it's ID (not the Name!) again. And it doesn't appear in Phoscon. A while later, the device seems to be discovered again - name is shown in the GUI, device appears within Phoscon (and my switches stop working) - they work well as long the device name is NOT shown within the GUI.
If I do another restart (systemctl restart deconz-gui), the "loop" starts again. ID instead of Name within the GUI, device not listed at Phoscon for a while. Switches work until the name of the device appears within the GUI.

This stops, as soon I delete the device from the GUI.

I'm able to reproduce this with any new device which is added.
Means: as long I don't add any new device everything is working flawlessly. But as soon any device is added (I tested with some plugs and a IKEA badring water sensor) the mystery starts :-(

Im running deConz 2.28.1-beta on a RasPI.

[jan666]

Ass soon I delete the new device and restart deConz (GUI here), everything is running fine again.

I dont think you have to delete the new device. Just restart deCONZ. For me just restarting deCONZ fixes this al he time.

[ebaauw]

You might want to wait some time, for deCONZ to save the resources for the newly paired device to the database, so on deCONZ restart, the DDF can be assigned on startup. If you restart too soon, the values needed to match the DDF are not known on startup, and the DDFs are reloaded once they're read, causing the issue to reoccur.

[ThePhiMuc]

Thanks guys! I will give that a try and do some more investigations this evening.
Maybe I did the restart to soon yesterday. I'll come back to this as soon I got some new insights...

[olemr]

I don't think waiting is gonna cut it.
When I added a switch during the day, I only noticed when it got dark several hours later that my outdoor lights didn't come on.
HUE outdoor sensor. (My HUE indoor sensor still updated the light level)
After deCONZ restart, update was received 3-5min later.

But realized now you were probably talking about something else.
Yes, I was restarting rapidly when fighting this and a few other issues with my Namron switches, and all of a sudden all Trådfri Open/Close switches were gone. Had to restore a backup ...

[vigggen]

I am having the same issues on Raspberry with Deconz GUI and Conbee II, running latest versions. Sensors such as Temperature and humidity .

I can also confirm this behaviour after searching for lights as mentioned above.

[hyper2910]

Any Solution? A restart works for me, but a SW Solution Sound be Fine

[eknirk]

Any Solution? A restart works for me, but a SW Solution Sound be Fine

Try downgrading to 2.26.3. Every later version had the same problem.

[fapoo]

Absolutely the same issue here. I ordered an aquaria wate leak sensor and as soon I include it, every other sensor (contact, movement, temperature) stops working but the new one. Lights keep working fine though. The first time I didn't notice until two days later so I don't think that waiting will solve the problem. Restart won't solve it neither. I always have to import a backup to make it work again.
Using 2.28.1. Unfortunately on Home Assistant and I don't know how to downgrade there again. Are the Deconz guys aware of this bug?

[bluemoehre]

I want to point out:
This is a really critical issue.

A week ago I noticed lights outside not turning off correctly (which I actually didn't bother so much). But since a few days I also had lights not turning on.

Imagine someone slips in a winter night …
Even worse if he gets badly hurt …
On top, it is proven there was no light at your house: You may face a legal case.

Also my logs state that some door locks didn't act at night, because daylight was reported for multiple days. This makes me feel very uncomfortable now.

As this bug is hard to see, but at the same time may seriously affect many people without them knowing it,
I would like to see this as a top priority.