I think @chris is the one to comment on the logs 
I suspect that you have a upgraded device as it now reports applicationversion 33.
You can test for what firmware it wants (as in the orginal post).
If it reports 65535 (FFFF in hex) we can be fairly certain that firmware has been updated.
Forget about the link i posted above pointing to a bug at deconz. This is not what you are seeing.
As for the security stuff they are talking about there; we have to wait and see what it is about.
This logging only shows that the transfer failed (ie OTA_UPGRADE_FAILED) - it’s really pretty much impossible to provide a lot more comment from just this since status - sorry. I’d need to see what was happening with the transfer to saw why it failed.
This log has nothing to do with OTA. This is related to the XML files that are saved by the binding as part of the device database so that it doesn’t need to request all the device data again. I can’t really say why it failed without seeing the XML itself.
It gave a “failed” message because at that exact time I started a new “zigbee otaupgrade start” the curious part is that it then got stuck in the “OTA_WAITING” then nothing happens.
I do not fully get where I can see that
Thx
Again though, I’m unable to help without seeing the logs as there’s just no information that allows me to help. Sorry.
If I remember correctly, application version is shown in the thing properties.
Ok so I actually managed to update some of my bulbs. Looks like updating straight to the latest version does not work - bulb downloads the firmware but after restart keeps the old one. I had to first upgrade to 2.0.022, then 2.0.023, now waiting for update to the latest 2.0.029.
This happens to me as well, seems like sometimes the device does not start ota update right away, you have to wait until it starts the download by itself.
How long before it starts in your case? Do you think I may need to get an older version first as well?
One started like 5 minutes later, in logs I saw one update after several hours. You can try power cycling them or running the otaupgrade command again.
Thanks all for the suggestions and help
Where did you find the old versions?
I have some trouble updating the 1000 lumens bulbs, but I am not sure what is going on.
I have to set up a test system so I can Isolate the upgrades from all the noise that is on my production system.
I used internet archive to get older version of that ikea updates json, all the old files still exist - https://web.archive.org/web/*/http://fw.ota.homesmart.ikea.net/feed/version_info.json
Btw seems like I’ve been too optimistic, because I still can’t get any of my bulbs to update to the 2.0.029. They must have changed something between 23 and 29 because all the bulbs just won’t install the new version no matter how many times I try it. I also tried updating my Fyrtur blinds but I can’t get it to start download.
I have all mine all updated to latest version. What may help is reboot, then immediately queue the FW update in the console. I did update 2 signal repeaters first. Also what I saw sometimes is that it tries to start but then just keeps asking for the first 60 bytes but never succeeds (switch on the debug logging to check this). The only way to tell if it actually was updated is to reboot, apparently the UI will not update the FW version unles you restart.
The wireless rollershutter button took some more patience to update, like 1 day before it finally decided to start. Note that the binding does not support the commands that it sends, so that kind of pointless now, but I hope that in the future support will be added! (@chris if you have time I would really appreciate it!)
Hi all,
Seems my issue is a bit off-topic, but since I searched the forums and nobody seems to have the problem I am experiencing (except for 2 people maybe), thought I’d ask here.
Is there any reason openhab says my tradfri outlets turn on when in fact they do not? Openhab says the outlets and gateway are online and reachable, and I find all the expected stuff in the logs. The only thing that does not happen is: switching the darn outlets! Normally I would expect openhab to throw an error, so I could debug. But it’s hard to debug when the software thinks everything is fine.
Documented my problem thoroughly here (Tradfri Binding: cannot create working gateway (bridge) - #3 by dikkedimi), hope anyone can offer a clue as to what is the issue.
When the device is offline and do not reply to the command, openHAB assumes the device is at its previous state. This is visible in events.log.
It can be some time ( 20-30 minutes) after openHAB is started before the real online/offline state is detected.
I suspect you have bad radio connection in the mesh.
These outlets have been surprisingly good for its price.
However , old software cause these to fall out of the mesh and they must be reincluded if they have old firmware.
He’s using Tradfri binding (which seems to be calling API on tradfri gateway), not zigbee, I don’t thing this thread is relevant to that.
Right, I found out the blinds actually updated a few days later at like 4am, so that works. Still can’t get any bulbs to update to 2.0.029 though. Not sure that I care since they seem to work fine (except one that has probably some hardware failure and keeps changing color to default).
@NilsOF I’ve now implemented this, but can’t fully test it end to end as I don’t have a device with firmware that is in this database. I’ve tested that I can download the firmware from where-ever it is hosted, and have tested that when the device asks for a firmware that we can do a lookup, and tested the download and hash checks, so I think this is mostly ok, but I can’t string it together through the OH console (since I think the UI doesn’t currently support firmware updates @ysc can you confirm this?).
Is this something you could test if you a devices that’s in this database? As we discussed above, it’s impossible to know what devices are provided since there’s no information that links the firmware to a device 
Nope, it doesn’t unfortunately. I’m very unfamiliar with that API.
Indeed.
I bought a number av Trådfri E27/GU10/Floalt WS devices when they were first released and have since day 1 had trouble with them randomly dying off. Stuck OFFLINE in either ON or OFF state. Had to be power-cycled. Amongst the 30+ devices, 1-2 died off each week. This was on FW 1.something
After update to 2.3.087 (through deconz) all have been rock solid for more than 3 weeks now.
Time to revisit the Ikea firmware…
I am not happy with how some of my bulbs behave after firmware upgrade.
(They do not accept my Philips Hue motion/lux/temperature sensors as children)
But my work schedule is crazy right now…
IIRC it is reasonably simple - you can just get a list of firmwares that are provided for a device, and then allow the user to select a firmware and send that back to the core. However I’ve also not looked at it for a long time (other than within the binding which of course is a bit different).
I’ll raise this as an issue as it would be good to have it implemented at some stage since it is a core feature of OH and was available previously.
Looks like new versions are available again: https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html
But when i try e.g. zigbee read 2231/1 25 8
I get:
Attribute 8 Image Type ID UNSIGNED_16_BIT_INTEGER 65535
That does not seem right. I can maybe guess which image to take but id rather make sure.
Any ideas?
Thanks,
Ramon