Ikea tradfri bulbs/spots drop from network (1.6.0 / 20190608) #2032
Comments
sandervandegeijn
changed the title
|
Can you try coordinator version 20190619? |
|
Networkmap looks instantly better. Will monitor it. Thanks for the tip! |
|
One night later: same problems. Network is gone, Xiaomi stuff still works. |
Can you still control your non TRADFRI devices? |
|
The Xioami stuff are only sensors (door contact sensors, buttons, motion detection, temp sensors). Those seem to work. The source routing firmware did force some of them to go via a Tradfri bulb initially. Networkmap now: https://pastebin.com/Zd5HLvsr It does see the Tradfri bulbs as online but can't control them and the mesh network is gone. Yesterday evening before I went to sleep it was looking much better. |
|
Do you see anything in the zigbee2mqtt logging when power cycling the bulbs? |
|
Pluggin it in after the last
Those ID's in the lqi scan lines correspond with the Ikea Tradfri bulbs. Did it a second time with two GU10 spots that were lost in limbo: Same result. Xiaomi stuff still rock solid so clearly the radio is working OK. |
|
I looks that they are rejoining again; somehow they are kicked of the network. Do you have any other zigbee hubs running (e.g. TRADFRI gateway) To dive deeper into this issue, could you sniff the network, start at a point where you can still turn the bulbs on/off until the point where you can't (https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html). |
|
Hmm I do have an aqara gateway still on, but these networks should be able to Co exist right? My neighbors could also have Philips Hue or something else. Will try to sniff later this week.
|
|
Strangely enough unplugging the Aqara gateway did help (at least for now, will monitor the network). But I do not understand why, multiple networks should be able to co-exist right? |
|
Aqara gateway is not in use, but the lamps dropped of the zigbee network again. I'll try to do some sniffing. |
|
Hi, I'm having the same issue. I flashed with source_routing. It seems better initially, but overtime some lights become unresponsive. I have a lot of Tradfri gu10 spots with some e27s. All Tradfri, ~30 lights total. The misbehaving lights are always further away from the controller. I have no other zigbee hubs online. I have xiaomi switches and 4 temperature sensors. Other than pairing difficulties I have no issues with the switches. I'm also seeing this often: Sending the signal multiple times eventually works. I'll try to get a hold of another usb stick to capture some traffic |
|
Distance does not seem to affect it here. It is definitely better with this firmware but still not entirely stable. Will try to capture traffic this weekend. |
|
Lamps dropped of the network today again. Didn't have the sniffing stick ready, I did spot a crash of zigbee2mqtt however. See attached logfile @ time 18:50. It crashes and restarts itself. Don't know if this related 1:1 to my tradfri problem but it is not expected behaviour. @Koenkk Should I create a separate issue for this? |
|
@neographikal It seems that the stick crashes because all of the network scans. Could you disable the automatic network scan? (maybe this also solves this problem?) |
|
will try, thanks. Where can I find this option? https://www.zigbee2mqtt.io/configuration/configuration.html Doesn't mention it it seems. |
|
It's not done by zigbee2mqtt itself but done by some external application, do you e.g. have the zigbee2mqtt node red addon or home assistant zigbee2mqtt network map addon installed? |
|
Okay, thanks. I have zigbee2mqttAssistant running root@neo-server:/home/neo# docker stop zigbee2mqttassistant Let's see what that does :) |
|
Can you sniff your network? I just noticed that network address changes are not handled well. This is what I did to get my Osram device back to my network.
|
|
Will try to implement a fix for this tomorrow (#2017 (comment)) |
|
The problem might be in the light firmware itself. We have various reports for IKEA GU10 and E27 dimmable and white spectrum bulbs dropping off. They become only responsive again after a power-cycle. This happens even with the IKEA gateway itself dresden-elektronik/deconz-rest-plugin#1261 (comment) Firmware versions at least up to 1.2.214 seems to be affected. No reports yet for newer firmware 2.3.007 (white spectrum) lights and new hardware revisions. |
|
@manup dresden-elektronik/deconz-rest-plugin#1261 (comment) could it be that the lights change the networkAddress without announcing the new one? Otherwise it would be strange that group commands still work? A re-power would trigger a device announce resulting in the gateway receiving the new network address. |
|
It varies, a changed nwk address is handled in our controller on all incoming commands. We also send out NWK address request broadcasts for unresponsive devices which would detect the change. In my setup it happened only twice that a E27 dimmable lights got stuck, after it was running for months without issues. I fired up the sniffer to see if the light is doing at least something, but there was total silence, not even the regular NWK link status commands every 15 seconds. So it seems in this case the firmware was stuck or crashed all together. I think I've tried even Touchlink but it didn't respond. I haven't found a way to reproduce the error yet, perhaps bringing it in a large network with multiple hops and many broadcasts could trigger the fault. |
|
Just released a fix for #2017 in the dev branch, let me know if this also fixes this issue. |
|
Updated to latest docker version, will monitor for problems. Response times when issues multiple commands are much faster now. Disabling zigbee2mqtt-assistant didn't help btw. |
About the working group command in deCONZ: All of the times sooner of later also a group command failed and have to powercycle the light. |
|
Unfortunately last nights fix did not resolv the dropping of the Tradfri lamps from the network. Will try to sniff the traffic later this weekend. |
|
I've got the same issue starting from 1.6. I downgraded but looks like that something is crashed in the stick because the issue is still happening. Using latest source routing firmware. |
|
In my case it will also bring down the whole network after some time ,so other devices (like xiaomi) became not reachable until system reboot. |
|
@neographikal I've ran my production network a few months on CC2531 Z-Stack 3 and consider it stable. |
|
Thanks, I'll monitor the stability. Using the current daily build of zigbee2mqtt as well. First results are encouraging! Maybe update the docs so that people will start using zstack 3.0? |
|
@neographikal let's first see if it keeps working now. |
|
The answer is no. In the morning, everything was still fine. Got home from work, half of the lamps were not working anymore. Logs do not provide a lot of useful info: Oct 28 18:35:08 neo-server zigbee2mqtt[1302]: #33[31mzigbee2mqtt:error#033[39m 2019-10-28T17:35:08: Publish 'set' 'state' to 'Tradfri lamp bay window 2' failed: 'Error: Data request failed with error: 'No network route' (205)' Lamps just drop off the network again. What can I do to help debug this? |
|
Please try #2032 (comment). I first want to make sure this isnt a hardware issue of the bulbs. |
|
Already did that, no other hubs present, disconnected all the Ikea bulbs and paired them 1 by 1. No difference. |
|
Sorry I meant #2032 (comment) When the bulbs are paired to the ikea hub they also end up being uncontrollable? |
|
Haven't used the ikea hub extensively but can try. Can't imagine that won't work tbh, this stuff gets sold to the masses, if it was this shitty Ikea would get everything back :) But will try anyway. |
|
@neographikal it seems that some bulbs have a firmware bug and in that case it will even happen with the IKEA hub (see dresden-elektronik/deconz-rest-plugin#1261 (comment)). |
|
@neographikal while looking at your wireshark log I found an interesting thing. When things work: When things stop working: The strangest thing is that after the on/off command, which the bulb doesn't respond to, it still send a link status update, meaning that it is still in the network (and alive??). |
|
Pfoee so this is really a bug in the Tradfri bulbs? I've got the problem with the E14 non color / non WB version, E27 same version ánd the GU10's..... That would be really really shitty. I can do another capture with the 3.0 firmware now on the stick. Bulbs themselves are on the latest Ikea firmware. Pairing is way way better with this, but the network problems persist. |
|
The only way to find that out is to test them with the tradfri hub. |
|
I've experienced identical problems with bulbs falling out, in particular "GU10 WS" bulbs. I updated my GU10s and some "E14 WS" and "E27 WS" I have with the latest test build (2.3.007) a couple of weeks ago. Since then I've had one single GU10 drop out, which is a huge improvement. |
|
How do I get the test build on them? I got the Tradfri hub but I don't see an option to update (on latest version). |
|
Afaik tradfri bulbs with the 1.x firmware are not updated anymore (in case you have that) |
|
Great, I have those. Ok, time to return them I suppose.. This means I'll have to upgrade to the 50% more expensive Hue lights, too bad. On the other hand, this is a massive waste of time lol |
|
@neographikal are you able to post the models / IKEA IDs of the ones your bought? Might be useful for others. For reference, my GU10 400lm WS (White Spectrum) - 904.086.03 was difficult to pair and initially buggy. Since re-pairing (per earlier comment), has been stable for 10 days. |
|
I don't have WS numbers on them, I have a bunch of LED1623G12's and LED1649CS's and some GU10 spots. |
|
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. |
|
Just wanted to contribute my findings regarding these bulbs. I have similar problems with the Ikea Tradfri LED1650R5 bulbs. All these bulbs can suddenly stop responding to commands from zigbee2mqtt and at some point they usually start responding again. I'm running Hassio with the zigbee2mqtt addon installed. In total there are about 40-50 devices where the majority are routers. Recently I moved from CC2531 to CC26X2R1 (very good!) hoping it would also fix the problems with the IKEA bulbs. The IKEA bulbs are located outsize, approximately 15m from the coordinator, but no more than 5m from other routers in the network. In total I have 12 of these bulbs connected to zigbee2mqtt. I have configured 2 zigbee groups for these bulbs. One groups contains 4 bulbs and the other contains 8 bulbs. Controlling the groups has never been problematic, only when controlling individual bulbs problems occur. So for those still having problems with these bulbs. When configuring them as for a zigbee group they seem to always respond to commands |
|
I also have similar issues with the IKEA Tradfri GU10 bulbs. After a while some do not report and respond anymore this happens quite randomly. Even the bulbs that are near the coordinator might drop off. This started when I added the last eight bulbs. And I have more then more then 50 devices now and more then half of them are also routers. I use a CC2531 stick with source routing firmware and 2 additional sticks as router. Luckily the bulbs keep responding if you use them as groups so all my automations and remote still work with these grouped bulbs. I am also considering a CC26X2R1 as coordinator now. Please can you confirm if it is more stable with that device. Otherwise I might consider to split the mesh network into 2. But I am not sure yet if and how I can set that up on a single raspberry pi with Hassio. |
|
At first I used the Philips Hue hub for all my light bulbs. The network with the CC2531 stick only contained some Ikea and Xiaomi sensors. Then I moved all bulbs to the CC2531 network and found major stability issues (CC2531 was running 2018 firmware) where the CC2531 would crash about every day. I decided to move to CC26X2R1 immediately instead of experimenting with alternative CC2531 firmware due to the size of the network, which I expect to keep growing. The zigbee network is definitely more stable with the CC26X2R1, but the problems described in this issue have not improved. I agree with some other users in this topic who that the problem lies in the Ikea bulbs, not in zigbee2mqtt or zigbee stick/firmware. |
|
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. |
|
This is still an issue with CC2652R (firmware CC26X2R1_20201026): my IKEA Tradfri sockets suddenly stop responding. I'm running zigbee2mqtt 1.6.2. The situation here now seems to be that the Tradfri sockets won't even join the network after resetting them. Any ideas? |
Bug Report
What happened
After a while I can't turn on Ikea Tradfri lamps (two GU10 spots and four E27 bulbs). They seem to be offline from zigbee2mqtt's perpective. CC2531 stick is close by all the bulbs and on USB extension cable, Xiaomi sensors that are much farther away can reach the stick just fine and work fine.
https://pastebin.com/cKRKMrUj
Power cycling the lamps does not help:
After cycling power:
https://pastebin.com/darPm1HP
Watching the logs for a while, I see some errors that reference device id's that match the Ikea bulbs:
https://pastebin.com/U2nLZLc6
What did you expect to happen
Lamps keep working
How to reproduce it (minimal and precise)
Wait a few hours
Debug Info
zigbee2mqtt version: 1.6.0
Also tried latest-dev docker image from 24-09-2019: same behaviour ( https://pastebin.com/mqx5AdQ4 )
CC253X firmware version: 20190608
The text was updated successfully, but these errors were encountered: