"Random" irresponsive lights (tradfri) #2256
Comments
|
Not sure if I can draw any conclusions, since I do not have a deep knowledge of the protocol nor the real impact of the WiFi network interference. However, I get more lights that gets "offline" or irresponsible and when making a WiFi analyse I see that one neighbour have selected ch 13 with a max signal strength towards my property (and devices) of 33%. My zigbee ch is 25. Very close in Mhz if I undersand correctly. Anyone that has seen this before and found a good way of solving it? Thanks, |
|
As you mentioned very similar to my problem. In my case the problem is affecting nodes that not have the gateway in it's neighbour table. So it's affecting nodes where the commands need to be routed through another node. In short. Nodes that have a direct link when you look in deconz are working. Nodes that don't have have a direct link is becoming unresponsive. |
|
Do you have a multi vendor network? |
I am almost certain that this is a deCONZ problem. Last night a SPZB0001 became unresponsive (although it still sent status update). From the logs I could see that deCONZ did not even try to send data to the node. One deCONZ restart later everything was working again. |
Yes, I've both bulbs from IKEA and Innr and other devices from Xiaomi (but those do not route, though). I've not made similar analyse as you, but it does sound as an potential "issue" that if one is affected the rest behave badly in that chain. Will make further checks. What I can tell is that this setup has been working for a long time and it did start after the fw and software update that I did in the same time as I extended the amount of bulbs. |
|
I thought I got a solution, to update to .73 version of deconz. But that did not help. The update, power cycle, removal of Xiaomi Hub, and restart of deconz made my zigbee network better, but the main issue was not solved. Yesterday the 0x000B3CFFFEFFFDDE device was the one that did not respond and thankful (perhaps) I recreated deconz container (when updated) with the debug flags set to 1 so I got some more info as of below. To me it does not say anything clearly, but perhaps for someone that knows the protocol it might be useful? The issue was "self healed" i.e. the device/bulb went into unknown state and then to fully responsive and working. At this time I started to force the device to been put into unknown state, i.e. trigged on/off and dimming the bulb Here the device to started to work again... |
|
I seem to have the same problem in my network! Randomly some lights don't turn on/off. |
|
What type of IKEA bulbs do you have? My GU10 bulbs seems to be equal to trouble. |
|
Using deconz 2.05.69 at the moment and ok with ikea E27, E14 and the power sockets. I was using the 2.05.71 and all the ikea stuff kept dropping out. |
I’m using some E27 opal 1000lm, few E14 opal 400lm and a bunch of GU10 ww 400lm. Couple of Innr RB148T. I thought the .71 worked better than .70. Not sure if you can go further below than .70 since I made a fw upgrade with this release. |
|
What I can also observe is that devices that connect through a TRADFRI light as router become very unreliable to reach, especially the SPZB0001. The issues vanish as soon as the affected devices connect directly to the ConBee II (which I can hardly influence or force, though). |
|
Same experience here with Tradfri bulbs, mainly issue with GU10, but also less so with an e27 bulb. I’ve only recently started using Deconz with a raspberrypi and raspbee, but so far I must say it’s frustrating. Has anyone had ikea bulbs work reliably? |
|
Until half a year ago, it was rock solid. Everything worked as expected. But then something happen and I cannot say what since I changed a number of things, including adding a decent number of bulbs. |
|
Have for a number of days, been running 2.05.67 version. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Have an issue that has been for a while and identified after I updated my install with several new lights to my zigbee network.
I've Conbee 1, Deconz in docker container (running at synology) version 2.05.17 and fw 26330500.
I've changed the WiFi channel to opposite frequency (ch 1) and set Conbee for ch 25. No other neighbours are in the same spectrum (either 1 or 6 with very low signal and far distance). Have put the stick on a extension cord for a better reception.
With random, I refer to a group of lights that within that group random stops to react to commands by either automations (home-assistant) or via Phoscon. It is not the same type of Tradfri model, it is different and both new and old ones that has been for a long period within the network (and worked for that time).
Below is the log that I recently captured when I discovered one faulty light. The light that did not work is the 0x14B457FFFE7B1011. For simplicity, I've cut out some repeating lines, but kept the number of them that repeated if that is needed. Let me know what I can do for identify the issue
Filtered out the last lines which mention the keyword "0x14B457FFFE7B1011"
16:54:29:175 max transmit errors for node 0x14B457FFFE7B1011, last seen by neighbors 53 s
17:07:59:854 ZCL attribute report 0x14B457FFFE7B1011 for cluster 0x0000, ep 0x01
17:07:59:879 ZCL attribute report 0x14B457FFFE7B1011 for cluster 0x0000, ep 0x01
17:07:59:981 ZCL attribute report 0x14B457FFFE7B1011 for cluster 0x0000, ep 0x01
17:12:27:663 binding for cluster 0x0000 of 0x14B457FFFE7B1011 exists (verified by reporting)
17:12:27:664 binding for cluster 0x0006 of 0x14B457FFFE7B1011 exists (verified by reporting)
17:12:27:664 binding for cluster 0x0008 of 0x14B457FFFE7B1011 exists (verified by reporting)
17:12:38:727 max transmit errors for node 0x14B457FFFE7B1011, last seen by neighbors 13 s
17:12:38:987 0x14B457FFFE7B1011 error APSDE-DATA.confirm: 0xA7 on task
17:12:38:988 max transmit errors for node 0x14B457FFFE7B1011, last seen by neighbors 13 s
17:16:46:039 max transmit errors for node 0x14B457FFFE7B1011, last seen by neighbors 86 s
The text was updated successfully, but these errors were encountered: