The Ikea Tradfri devices always seem to get rather positive feedback from deconz users… My own experience is, however, rather mixed: The devices seem to get dropped from the network after most power losses and have to be re-paired. And it’s always all of this devices all at once which misbehave.
Setup: 4x control outlets E1603, 2x LED driver (unknow device number) in different positions, bought at different times during the last 3 years, deconz on Linux as container, constantly updated, host computer switched from RPi4 to Odroid H3, USB stick on USB 2.0 and positioned away from other emitters.
Since the beginning of my Zigbee installation the Ikea devices were always a gamble. Each power loss could kick them off the network. (Interestingly, Ikea battery powered switches seem to work flawlessly all the time.) I have lots of different devices of different manufacturers on the network, but the Ikea devices are the most notorious misbehavers.
Are there any hints how to deal with those Ikea devices?
Sometimes having the USB stick on a plain extension cable is not enough. I use a powered USB HUB on all my 4 installations.
I have never had trouble with devices needing to be re paired, only that they become unreachable and then a power cycle was always the medicine in that case.
I said ‘was’ because after I FW updated my 1 Gen Ikea bulbs and panels (using the ikea-ota-download.py found on GitHub), they behave so much better, maybe just 1-2 dropouts a year from a total of 30-40 devices.
According to this page:
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/OTA-Image-Types—Firmware-versions
I am on the current firmware already at least for the on/off control outlets E 1603 (2.0.024). The LED drivers 10W are at firmware version 2.3.086, I cannot find this device on the firmware page. So I’ll look into the script you pointed out, maybe this helps.
I also often (too often) have cases where I have to restart the software or to replug the USB stick because of unreachable devices. This helps in many cases, but unfortunately the Ikea devices are resistent to this solution.
EDIT: The page linked above seems not to be current, OK… so I ran the script which downloaded the firmwares, enabled OTAU in the web ui, and now do I have to trigger something to perform updates, if available?
If you have the GUI, a sample with osram Technical support
And no for me it’s not normal, I never have this issue and I have 5 years olds firmwares, only a freeze one time but solved with a power cycle.
You are making the reset procedure too or just set phoscon in permit join ?
If you do nothing, it will start updating devices on its sweet time, can take several days.
Unexpected flicker of a light can be due to a device restart after FW loading.
Also the Old Web App will notify with a top banner if FW loading is currently ongoing, as network response might be slower.
I opted for using the OTA in the GUI and manually asking 1-3 nodes at a time to check for updates.
It has a progress indication as well.
I don’t have any LED drivers, but on/off are at this version:
Thanks for your replies. After running the Ikea update python script, after a day now my Ikea devices seem indeed to have updated themselves to the new version. We will see if that fixes the problems.
I’m just wondering why this update script is hidden in the deconz container, IMHO it should be run as a cron job. I was not really aware that there are more manual steps besides enable “OTA Updates” in the web ui…
You are welcome.
Yes, you must provide you own binaries 
If you still get problems, have you tried the powered USB HUB option?
I had 2 installations that worked fine for weeks, then suddenly started acting up.
After I used a powered USB HUB, they have been going for years. Even the Pi4 with an SSD on the same powered HUB as the Conbee (Classic, aka I)
Well, if there is a script available to provide the binary one wonders why this script isn’t run automatically or at least launchable from the ui.
Concerning the powered hub: I tried a powered hub while running the stick with my RPi, but somehow I had the feeling that this only added one more potential point of failure (might be a question of hardware quality). As I now run the stick with an Odroid, I hope that this device has a stable enough power supply. But I’ll reconsider this after the next Zigbee hickup…
The FW binaries are not officially released or endorsed by the vendors. Some are somewhat hacked from the devices and deCONZ will not officially be associated with them. Guess that is the reason.
No, you can have it run automatically (i believe if you have the toggle on in Phoscon, it does ocasionally).
For me, i wouldn’t want to have auto updates. Some updates add stuff but some of them remove functionality. For example, one of the later versions of the Ikea On Off shutter switch removes group casts from the firmware and thus breaks automations / group bindings.
I think he was referring to the actual fetching of the device FW binaries into the otau folder?
Is that automated?
I too have switched off auto update, for the reasons you mentioned, but also because I experienced an update loop where devices were repeatedly loaded with the same FW already on them and hence blinking at irregular intervals.
That i don’t know. I have seen it in the past, perhaps on restarts?
Best to ask this in a new forum post.
No need. I’m 99.9% sure nothing is downloaded until the ikea-ota-download.py script is run and HUE binaries manually put in the otau folder.
Hue ones are never auto downloaded as they aren’t opensource afaik.
Indeed, (as I stated above )
In my situation, I had problems with the Ikea stuff. So I wanted to update (sop when something misbehaves ;-). I enabled ota in the web ui and checked an (outdated) web page for the firmware. At this point I would have considered that everything went OK and I have the latest firmware. Which was wrong, because - undiscernible from the web ui - I had to run a python script.
This inconsistency is just what I meant as counter-intuitive. Not really a problem, but inconvenient.
Concernig the legal stuff, wouldn’t it be just the same if the web ui can trigger the script or if I have to run it myself…
So it has happened again. Without a power loss and nothing else discernible happening, all Ikea devices have become unavailable all at once. Only the Ikea devices!
I also noticed that two devices called “3A Smart Home DE LXN56-DS27LX1.3” were suddenly turned on at the same time, I think I noticed that the last times, too. However, these devices were still controllable, while the Ikea devices were “lost”.
What is happening here?!
EDIT:
In Home Assistent, I see that the “3A Smart Home” devices were turned on out of the blue at 6:21 this morning, and exactly at 7:11 all Ikea devices were reported as unavailable (in reality they were also turned on). System logs do not show anything special at all in this time.
Looking back in this thread, I cannot find you ever stated which version of deCONZ you are currently running?
Just to recap, when you lose control do you have to re-pair or is a power cycle of the devices enough?
Are you controlling them with unicast ot multicast (group) commands?
Also, a screenshot of your network toplogy from the GUI could prove helpful.
I always use the current version (stable) of the community container, see screenshot. As the problem has happened several times during the last three years, it seems not to be restricted to a special version.
IMHO the mesh looks good, see screenshot. Top left you see one of the Ikea devices, source routes are still present.
I have to re-pair the devices to get them working again. Power cycle is not sufficient.
I don’t know how I control them - I simply pair the devices from Deconz and then use them in Home Assistant.
EDIT: The Ikea devices are in completely different positions, e.g. one is 3m away from the stick with no wall in between, another is in the opposite direction, about 10m and walls in between Both fail all the same.
