IKEA lights occasionally lost connection #1261
Comments
|
Same here with 2.05.58. One Tradfri GU10 seems to be unresponsible atm: |
The REST API plugin marks a light as unreachable, when it doesn't receive a response for a couple of times when polling the light for its state. The cause of not receiving a response is, in order of likelihood:
In a) and c): no. In b): yes. The REST API plugin marks the light as reachable, when it receives a message from it. Powering up the light causes it to send a Device Announcement message. In b), typically, the light comes back spontaneously, when the next poll succeeds. You can also select the node in the deCONZ GUI and press |
|
Same problem also in version 2.05.59. |
|
I also have this problem, even after upgrading to 2.05.59. Today was one of my three outdoor-lights "gone". |
|
@ebaauw Thanks for your explanation.
No wall switches available for these lights, so I am not able to accidentally disconnect power.
The lights doesn't react on group commands when connection is lost (the lights are assigned to a Hue Dimmer in the Phoscon app and doesn't respond on the Hue Dimmer when connection is lost).
Firmware 1.2.214 is installed on all my IKEA GU10 spots. Got 20+ of them and a random light goes offline, let's say one in the 2-3 weeks. |
|
You might try the latest deCONZ version with 48d2c39. |
|
I had the same experience two times the last months with two different E14 IKEA bulbs (IKEA fw 1.2.214) . |
When the lights don't react to even group commands it seems to looks like a firmware crash. 2.05.59 has adapted the IKEA gateway parameters to configure light state reporting. Mainly in the hope to not trigger any bugs by using configuration which IKEA itself doesn't test. Side note the change will cause no timers are used for reporting on the device anymore. The new configuration will be applied once a light is power-cycled. We still send some maintenance requests like group membership and neighbor table queries to the lights, and might restrict these further if stability doesn't improve with 2.05.59. Keep in mind there might also be the possibility that a bug is in the light firmware which is not related to any requests the gateway sends. |
+1 on "not necessarily related to deconz but rather the Zigbee network or manufacturer FW" in correlation with Zigbee standard interpretation in manufacturers FW. |
|
I just updated to 2.05.59 and after restarting deconz the same light is not reachable again. Pressing 0 in gui doesn't bring it back. Any other light works. In my case this might as well be an issue with the light itself. |
|
@peer69 @thomas70 Did you power-cycled the light as this is needed mentioned by @manup in #1261 (comment) ?
|
|
Good hint, haven't done that. For now I had to go back to .58 for another reason (high cpu load turning the gateway unrepsonsive), will try this later today with .59 again and powercycle all ikea lights. |
|
I'm also having this issue, it happened twice for the same GU 10 light. Currently running 2.05.59, and I did power cycle the lights after the update. |
|
Forgot to add that it sometimes seems like it's the same bulb that keeps failing. A while ago I did have issues with another bulb, and it would always be that one to stop reacting. |
|
After power cycle my IKEA bulbs came back. But my IKEA FLOALT panel WS is still offline |
|
I'm experiencing this same issue and have been doing so for quite a while, and I'd say that .59 actually made things worse for me. I have 80 nodes of which 32 are Trådfri lights and switches, 5 are Hue lights and the rest are different Xiaomi battery powered devices like temperature, motion, smoke detector etc. Every single type of device has been unresponsive at least once so in my case it's not just the Trådfri lights, but at the time I'm just having issues with the Trådfri and Hue lights. The thing is that I ran all the lights through a Hue bridge and the Xiaomi sensors through the Xiaomi gateway earlier and then they were all rock solid, so I don't think it's the device firmware that's the culprit in my case unless it's caused by the change in circumstances. I have six Trådfri GU10 lights in one location that worked perfectly before, but after the upgrade to .59 and several power cycles later they are now almost completely unresponsive and I will probably have to reset them. What's strange is that this unresponsiveness also seems to be "moving" from different lights depending on which lights that have power. If I cut the power to some of the unresponsive lights it may take a while and then it's suddenly some other light that doesn't want to work properly. Perhaps there's some offset somewhere that's breaking things? |
Interesting, did you also have all 32 Ikea lights on the Hue network? I'm asking because Hue bridge uses polling only and doesn't configure attribute reporting. Did you also have router devices like the Hue or Ikea lights on the Xiaomi network?
Hmm that's pretty bad I really wonder how this happens, 2.05.59 is way "familiar" to Ikea lights than prior versions. The configuration is now happening like the Ikea gateway does it. When a light becomes unresponsive can you please select the node in deCONZ and press By the way the usual questions:
|
|
It took a while longer than expected but now everything actually appears to be working fine again. At least for now from what I can tell. I rebooted the server and also power cycled every single mains powered light in the network to make sure that they fetched the latest configuration, but despite this it took a couple of hours before the issue went away so I was a bit premature in my assumption that the issue remained as it did not work right away.
Yes, sort of. I had 31 Ikea lights on the Hue network as well as the Hue lights. The 32nd Ikea device is the switch outlet which I hadn't bought back then.
No, just battery powered sensors
I did try this multiple times earlier with no effect. And as for the hardware and setup, I'm using a ConBee with USB extension cable and 262F0500. Since everything seems to be working fine for me now this info may not be of any use at the moment but I'll try not to jump to any conclusions and let the network run for a few days to make sure that the issue doesn't return. |
|
I have been running .59 since last week-end and I still lose random Ikea lights. (16 E27 bulbs on house facade.) |
I have kind of the same situation here, 16 IKEA lights, 2 IKEA control outlets, a Heiman plug and an innr plug and some Xiaomi sensors (cube/door sensors/motion sensor). Never had problems with the non-IKEA devices. However I currently have almost daily issues where a IKEA light drops out of the network I use a Conbee with a USB extension cable on firmware 0x26300500 and deCONZ .59 |
|
My lights have been working fine for a while now but a couple of days ago my Trådfri E14 bulb suddenly became unresponsive. One power cycle later it came back to life. Today it was time for one of the GU10's to drop out. It's physically very close to the previously mentioned E14 so I'm not sure if it's a coincidence or not. The GU10 may very well have been routed via the E14 even though all my lights are within ConBee range. Selecting the nodes and pressing 0 in deCONZ does not do anything. I have also tried rebooting the deCONZ container and while reroutes the network on startup it does not connect any route to that specific bulb. What would be the best approach here to proceed with the troubleshooting? |
|
12 days later, another GU10 become unreachable and will not connect again without a power cycle. Happy to share whatever info is needed to get into this issue. |
|
Same here, yesterday after 6 days flawless connection, I lost one of my Tradfri bulbs.. power on/off and reset didn't help. Its still yellow in deConz but cant connect or control it.
|
|
Same here. After some days without any issue today two of my GU10 Tradfri lamps stopped responding. I was able to bring one of them back to life by pressing 0 in GUI, but I had to Powercycle the other one. |
|
The issue has continued for me as well. I have now experienced 3-4 more GU10 bulbs losing connection as well as one of my Hue E27's and a Xiaomi door sensor (magnet). Some lights have started working again after a power cycle, others have not. Pressing 0 does nothing. It's also noteworthy that the Xiaomi sensor started working again after I power cycled an adjacent and unresponsive GU10 so I suppose that the sensor was routing through that light, but shouldn't it automatically reroute if there are any connection issues? |
|
Same issue here. Yesterday I updated to the latest version .59 now a couple of Ikea lights are unresponsive |
|
Hi can you give more insights of the total network, like network size and other mains powered devices in there? I've rearranged my home network a few days ago, now including:
deCONZ 2.05.59; ConBee firmware 0x26300500 (but 0x262f0500 is fine too). I have 4x FLS-PP lp but these are powered off now for testing, since they act as very strong signal repeaters. With sensors and switches the total network size is 55. |
|
Here are some more detailed specifications of my network if it can be of any help. I’m still running 2.05.59 with 262F0500 and an extension cord to the ConBee. As mentioned above, after first updating to 2.05.59 and power cycling every mains powered device and waiting for a couple of hours the network was flawless for almost a week, so it seems to take a while until the issues start to appear. Unfortunately the issue reappeared and a full power cycle of all mains powered devices as well as a deCONZ reboot does not resolve the issue anymore. It also seems that the issue is wandering from device to device because sometimes a light may be unresponsive for a while and then it fixes itself. Earlier today I had an issue where the Trådfri E14 was unresponsive as well as one Hue E27. After a power cycle of the E27 the E14 came back to life as well without me even touching it. The same goes for the unresponsive GU10's that seem to be trading places now and then, so there are at least two unresponsive GU10's every day but it's not always the same lights so some start working while others break and vice versa. My network currently consists of the following 80 devices including ConBee and the mains powered devices are powered 24/7. Mains powered
Battery powered
|
|
Last week deconz seemed to run mostly fine, but yesterday I had another IKEA bulb (white spectrum) losing connection to deconz. Even turning it off and on again didn't help. Had to restart deconz for it to work again somehow. I've got a network with mostly IKEA bulbs, a Heiman outlet and quite some Xiaomi sensors. |
|
Some specifications of my zigbee network: Conbee firmware 262F0500 with extension cable on a NUC. Powered (24/7)
Battery powered
|
|
Hello @manup ! Thanks for the info on the "Source routing" feature. I will now activate it on my 62 node system consisting mainly of IKEA stuff. Ive been experiencing quite a lot of unresponsive devices for a very long time. I truly hope that this would solve this issue once and for all. :) Is there a way to make the source routing feature to persist (remain activated) when the (in my case restapi docker container) deconz system restarts? (Not to store the routes, but to save the enable feature) |
|
I've implemented the ZDP leave and rejoin command to try to help mitigate the Parent Announce bug as well, currently testing with sending the command once daily. Initial results were disappointing, as I lost several IKEA devices each of the first few days, but since then (8 o 9 days now) I haven't lost a single device. I'll keep testing and post back with any further results. Also of note, I know several have emailed some of the IKEA smart home embedded engineering team and also made various social media posts asking for them to provide update firmware for these devices based on Silicon Labs Emberznet 6.7.8 which has fixes for these issues. |
Fantastic news! I have updated a few of my IKEA devices via OTA. Mainly outlets and led drivers. Thanks for the information and update! |
|
Anyone checked the EmberZnet version on the latest Ikea firmware's just made available? |
|
@ptrrkssn Yes, versions are listed here --- still not new enough unfornately: |
Naturally after writing such a post, something is bound to go wrong. Yesterday one of my lights in the kitchen stopped playing along. In the zigbee log, the usual sudden silence was visible. I did notice (a number of occasions in the log) that an issue I reported earlier in this context is still there. Not always the Default Response is sent after a attribute report that does request it. That also happened right before the light went offline. In the case below, seq. 113 is never getting a default response. @manup , Is there a mechanism in place which guarantees these things are delivered? Second thing I noticed is that sometimes the source routing is not used, although a packet before/after are source routed. I saw it with an APS ACK packet, not source routed, but level control and on/off commands are. |
|
Somehow i missed your response @djwlindenaar. Asked @manup To reply :). |
|
I can confirm that the new "source routing" fix works magic to my IKEA heavy system here at home. No hickups or unresponsive lights for the last weeks. I am currently running the latest FW for all devices OTAU capable devices as well as the latest beta version of deconz. |
|
Although I can confirm network stability has improved, I am still losing devices from time to time (mostly IKEA lights but this also occurs for OSRAM Plugs and Paulmann Lights in my network). They still react to group commands most of the time but I can't reach sensors routed by these devices anymore and lights are greyed out in Phoscon UI. Can be resolved by a power cycle. |
|
@peer69 Yes, can also confirm same behavior. This is still due to the root cause of the Silicon Labs bug and will be an issue (with no complete viable workaround) until IKEA updates their firmware to EmberZNet 6.7.8 or later. |
|
Something you might want to try out when your devices are limitedly available, is selecting it in deconz GUI and then press L. Helped me to revive socket outlets without popping the fuse. |
@Mimiix , didn't work out, it seems... |
|
@djwlindenaar Forwarded again :/ |
Usually the default response is delivered as long as sending queue is not filled up. Does this happen often? Note it could be as well the sniffer didn't process/forward the frame this can happen from time to time. |
|
IKEA has released a new firmware for some older bulbs. I've been running it since a few weeks now without any issue – but I'm not sure if the issue is solved because in my setup the bug occurs only after some weeks even months. Might be worth a try though. |
|
IKEA is still on early Emberznet 6.x stack releases (even with latest test-fw) so most likely root cause bug is still there. Hopefully they will eventually get to 6.7.8 or higher. |
@manup, thanks for the response. It's happening a lot. Also, since the default response is also relayed through a intermediate bulb, which the sniffer also picks up, I think it's unlikely that this is caused by the sniffer not picking up a packet. How likely is it an send queue issue? E.g. how big is that queue? |
I dusted off my old IKEA W, WS, and CWS E27 bulbs and paired them to my dev network. Indeed, new firmwares for all three of them. The W is now also ZB3 with an additional ZGP endpoint; the CWS is still ZLL and without ZGP proxy. The CW and CWS still exhibit the transition bug. |
|
Running the OTAU Script and powercycling the bulb is still enough to trigger an update? Haven't had much issues for some time but I'll try the new firmware anyways. |
|
I am wondering for which specific bulbs there is a firmware update available? Also the v1 GU10 (the non-glass ones)? |
You need to restart deCONZ after running the OTAU script. After that, the update of mains-powered devices starts automagically. A power cycle of the bulb might expedite this, as would pressing the Query button in the OTAU panel in the GUI. I dusted off the bulbs in another (feeble) attempt at cracking the special scene commands that the round remote sends on the left and right buttons. I only noticed the update had started, when I saw the corresponding packets in the sniffer. |
Run the script, restart deCONZ and check which new |
|
@manup Can you provide a update? |
|
In my setup I haven't seen the issue with lights going offline anymore. My GU10 and E27 lights are powered on for more than two months now with the latest firmware version. I can't tell if this is luck or or the firmware has indeed fixes in this regard. I'm running firmware versions:
Since this issue here has grown so large I'm closing it for now and suggest when the problem happens again we create new issues for specific lights. For example: "IKEA GU10 WS 400lm, firmware x.y.z loses connection" so we can better pin point and track the problem without mixing too much separate things. |
and others
Occasionally a light (mostly a Tradfri GU10) gets unavailable in the Phoscon app and can not be switched off/on via Phoscon (or HASS). Using deCONZ 2.05.55 and firmware 262F0500 on the Conbee now, but got same problem with older versions of deCONZ and Conbee firmware.
(Not always this light)
The text was updated successfully, but these errors were encountered: