No, but then Ikea do not follow the standards 
What attribute is this for? Is this for the Image Id? If so, this is what I would expect since the standard states that this is the image Id of the current transfer and should be FFFF when no transfer is in progress.
This is why there is no solution here. I’m not sure why you can receive the data as you listed above, unless this was done during a transfer?
For me this is not a reliable approach - requesting this data “once in a while” in the hope that we find out what image type it might ask for is not reliable.
The only reliable approach, given there is no information available as far as I’m aware, is to annotate the database with this information. This is certainly the approach that we took with Qivicon / Deutsch Telekom. That was 2 years ago, but I don’t think the standards have changed since then.
yes.
Now this bulb follows the standard (after the upgrade).
To complicate things even more:
This bulb was upgraded from
10046695-1.1-TRADFRI-light-unified-w-2.3.086.ota.ota.signed
This indicate that this firmware may “fit” more than one bulb from Ikea.
Ok, I guess that’s good, but ultimately means we still have the “no solution”, solution.
Yes, because there is an abstraction between devices and images, this is always possible.
So where I got to yesterday is that a FirmwareProvider is not possible within the OH context. We could add this functionality to the binding so that it can access the firmware, and update devices - this would be simple and I’ve basically got this coded already. It’s not really overly nice as I do agree with you that it would be good to have the “user in the loop” here, but without annotating the database further, I don’t currently see any option.
Maybe annotating the database is the right thing to do. As eluded to above, if we fork the z2m version, and add extra info for OH, then we are also able to solve the issue with dongle firmware we discussed some time back.
Reading the specs I can see where chris is coming from. If I understand it correctly, zigbee OTA upgrade works the other way around than that FirmwareProvider in openHAB - server broadcasts Image Notify info about having OTA update available and devices then download it if it matches their manufacturer/image type. You can unicast that command to just one specific device, but the specs gives no way to actually check whether the device will accept it or not, or what images it does accept.
After reading this I agree that there’s no point in doing this in FirmwareProvider, especially since OH3 does not seem to have any UI for it. It would be nice to have some more user friendly way to do it though, especially since IKEA provides site where images can be downloaded from.
So what I could do is as above - add this to the binding, and provide a configuration option to allow a device to be upgraded if it asks for an upgrade.
I do think that adding extra information to the firmware database to allow this to be linked to a device would be useful. It wouldn’t have to be updated for all devices, but could be progressively added. However, given that OH UI doesn’t seem to support this it’s even less useful at the moment.
Wouldn’t it be possible to extract the Image Type from the Query Next Image Request all devices are supposed to send?
23364 The client device will send Query Next Image Request Command if the information in the Image Notify
23365 Command is of interest and after applying the jitter value. All devices SHALL send in a Query Next Image
> 23366 Request Command periodically regardless of whether an Image Notify was sent by the OTA server.
Yes, of course. This is the way it works when the device wants to be updated. However we don’t know this ahead of time - only AFTER the device requests an update. This is the way I propose to use it above - but it doesn’t allow the user to decide to initiate the update until after the device has already done so.
The user could initiate an OTA update if she/he would be able to send the Image Notify command with image type value of 0xffff:
For
23060 example, the OTA server MAY send Image Notify command with image type value of 0xffff to indicate to
23061 a group of client devices that it has all types of images for the clients.
If the device is cooperative, it shall reply with a Query Next Image Request.
Yes, but the point we discussed above is that we can’t manage this through the firmware provider as this doesn’t fit into the OH concept which provides a list of firmware to the user, and allows the user to select the appropriate one. All we could do is list all firmware, which is a long list and not so useful.
Maybe I didn’t express this issue properly - sorry. We can allow the firmware update directly in the binding - this is fine. But it just doesn’t make any sense to do it through the firmware provider.
Yes, it doesn’t make sense in the context of the firmware provider, but to make use of the openhab:zigbee - otaupgrade command, one has to know the Image Type - and this information should come from the device. OTA upgrading a device with a wrong firmware file could brick the device, couldn’t it? Of course, the Image Type is part of the firmware file, but do (all) devices check whether it matches the Image Type requested?
Would it make sense to add a new parameter INFO to openhab:zigbee - otaupgrade that returns the Image Type the device expects?
1 Like
They should. Image Type is not the only check that is done as there is a hash, and some devices will also perform an authentication to ensure it is a valid firmware for the device (ie a cryptographic authentication using a public/private key stored in the device).
What you tend to find is the OTA will fail almost immediately if the filetype or other information is wrong since the device normally checks that as soon as it receives the header (which is usually a couple of packets into the transfer).
Of course, all this is down to how well the device bootloader is implemented, so I can’t vouch that all devices are born equally, and that it’s impossible to brick a device by loading the wrong, or corrupted firmware.
When I originally wrote this for Deutsch Telekom a couple of years back, DT provided me a bunch of devices and firmware to test with. During testing, I did manage to brick a device (a Bitron Video plug) even though it was the correct firmware being loaded. Presumably something got corrupted along the way and it was game over.
Hi all,
my 5 cents to the topic: If you use zigbee2mqtt there is a build in command to update the firmware of all zigbee devices, including IKEA .
The question is if this can be re-used from the GitHub sources or if it is possible to connect the zigbee-controller with OH-Zigbee binding and the zigbee2mqtt service.
This functionality (ie to update firmware in zigbee devices) already exists in the zigbee libraries used in the binding. This is not the issue - the question we’re discussing here is how to hook this in so that it can be used with openHAB concepts.
Currently it can already be used in the openhab command line console.
I found two implementations that may validate OTA files produced by the Silabs SDK(?)/tools.
Ikea use the dev tools from Silabs.
zigpy (python):
https://github.com/zigpy/zigpy/blob/dev/zigpy/ota/validators.py
pedrolamas silabs-image-parser (TypeScript):
https://github.com/pedrolamas/silabs-image-parser
So, much of the hard work for OTA integrity check looks to be done by our neighbors.
I think this is important. Ikea did publish corrupted firmware blobs in the past.
And that triggered a lot of user requests like “My device will not update”.
https://github.com/Koenkk/zigbee2mqtt/issues/4361
And this was exactly the hole I stumbled into when I first attempted to extract OTA firmware and upgrade my Ikea on/off control outlet.
I know Ikea use Silabs chips and firmware etc - I’m very surprised that their firmware uses the Silabs tools as their firmware down’t follow the standards. Ikea embed the OTA file inside their own custom format. If the Silabs tools create non-standard firmware, I’d be surprised, but I’ve not used the OTA generator myself so maybe you’re right. It just seems strange others therefore aren’t using the “Ikea format” if it’s generated by Silabs…
Hi Nils, all,
I tried to do exactly what you did on one of my TRADFRI repeaters. I got exactly the same stuff as you, including the last
OTA File "10037603-3.1-TRADFRI-signal-repeater-2.3.086.ota.ota.signed.ota" set.
However, it appears it is not doing anything. So this is what it should give:
fw_binary_url : http://fw.ota.homesmart.ikea.net/global/GW1.0/01.17.019/bin/10037603-3.1-TRADFRI-signal-repeater-2.3.086.ota.ota.signed
fw_file_version_LSB : 26161
fw_file_version_MSB : 8968
fw_filesize : 197052
fw_image_type : 4354
fw_manufacturer_id : 4476
fw_type : 2
So I expect a FW of 0x23086631, but it appears to be still 0x22005631
So how to check if there was really an attempt to upload the FW? Does it actually try to upload it immediately?
Thanks,
Ramon
Set debug level in openhab console like this:
log:set debug com.zsmartsystems.zigbee.app.otaserver
I actually have the same problem when I tried updating lightbulbs. Update starts, bulb downloads firmware, then restarts but after that it reports the old version again.
There is something with the signal repeater and its existing firmware that do not want to upgrade. I do not remember the details, do a search on zigbee2mqtt or deconz.
This was told me on a Norwegian forum.
Edit: I do not think this is the issue you have, it was another firmware version.
See: Cannot OTAU Tradfri Signal Repeater from V-2.3.070 to V-2.3.086 - #13 by manup - General Support - deCONZ Community
One thing I have seen on my outdoor bulbs is that the routing and signal quality must be in good shape. The bulbs I tested here (outdoors) just do not accept the OTA chunks it get and ask for a resend multiple times before it gives up and cancel the OTA.
This can be seen in the debug logs. It get very obvius if that log is uploaded to