Zigbee OTA Firmware Provider

izzy84075 · July 16, 2019, 1:01am

I’ve got a handful of devices that I have firmware files for, and would like to update the devices with them.

As far as I understand, the zigbee binding itself supports firmware updates (here), but the firmware provider to actually link device types to firmware files is missing (here).

I’m curious where I would start looking to learn how to implement this firmware provider. I’ve skimmed through the documentation I’ve been able to find, but I haven’t managed to find a good starting place for this.

Alternatively, if this is something that somebody’s working on already, point me towards it and I’ll see if I can help by offering some test subjects.

Bruce_Osborne · July 16, 2019, 7:30am

@chris owns the zigbee binding.

chris · July 16, 2019, 8:55am

This isn’t really anything to do with the ZigBee binding. The firmware provider is completely independent, and the OTA protocol itself is already supported in the binding.

I believe in the past the plan was to have such a provider, but that was in ESH so I’m not sure what the status is now. I’m also not sure where the documentation is - I think there was an issue raised to add documentation as there was/is none in ESH, but I’m not sure.

I have implemented a provider, but unfortunately I can’t provide that publicly at the moment - maybe in future I will find some time to sort it out.

izzy84075 · July 16, 2019, 6:53pm

Alright. Well, it doesn’t look like any of the other bindings implement firmware updating, so I think I’m kinda stuck. I’m not familiar enough with the project’s architecture to start from just the comments on the generic FirmwareProvider. I guess I’ll see if I can update these some other way for now.

giuseppeiannello · December 9, 2019, 1:10pm

@chris is there any update on the topic?
A few companies (IKEA, Osram) offer download links for their firmware files, would be great to have at least a manual way to trigger an update - maybe directly via the karaf console.

chris · December 9, 2019, 2:26pm

No - there’s n real update. I do plan to look at this over Christmas - and by this I would provide a manual (command line) way to load firmware.

giuseppeiannello · December 11, 2019, 1:12pm

I missed that issue - was only looking at the core repository.
Great to hear, can’t wait to test it

TheNON · January 24, 2020, 7:19pm

Hi @giuseppeiannello,

Would you be so kind to share the firmware links? I couldn’t find any for Osram.
Others like IKEA or Philips did not try yet, but would appreciate if you would share the valuable information you’ve collected so far.

Thanks

chris · January 24, 2020, 9:47pm

I will shortly be able to provide a way to update ZigBee devices via the binding - either using the console, or using PaperUI. So, if we actually have the OTA files, in the official ZigBee format, then it should be possible to load these soon (I really just need to do some final testing with the binding).

giuseppeiannello · January 26, 2020, 7:56pm

https://update.ledvance.com/firmware-overview

@TheNON there you go!

@chris great job, thank you!

TheNON · January 27, 2020, 6:41am

Thanks for the help!

giuseppeiannello · February 10, 2020, 8:03pm

@chris I’m trying to get the “image type” attribute for my bulbs, but there doesn’t seem to be a way to get it via karaf or via the zigbee java console. Any change you could make it available at some point?

NoneWhereTo · February 11, 2020, 9:57am

FYI, zigbee2mqtt are currently also implementing this feature: https://github.com/Koenkk/zigbee2mqtt/issues/2921

But getting the firmwares for all manufacturers seems to be hard as they are not published openly (besides of course, getting the update process to work)

chris · February 11, 2020, 10:26am

What do you mean exactly - you want to know what image type the bulb expects, or you want to know what image type a file is for?

Normally this isn’t available to the user - it’s stored in the files, and the device will request the image type when it starts the OTA. But first you need to get the files from the manufacturer and that can be difficult - most of the ones I have here are only available under a non-disclosure agreement so I can’t provide them.

The ZigBee binding has had OTA updates for the past few years - it was implemented for Deutche Telekom some time back.

giuseppeiannello · February 11, 2020, 10:53am

What do you mean exactly - you want to know what image type the bulb expects, or you want to know what image type a file is for?

I want to know what image type the bulb expects - I see that deconz/phoscon has a way to check for this (Technical support) and it’s used to provide guidance on which file to download from the firmware archives

Normally this isn’t available to the user - it’s stored in the files, and the device will request the image type when it starts the OTA.

That’s what I was missing as far as I understand, the OTA process is started by the bulb itself, I’ll try to inspect the traffic and find out what’s requested. Caching this in the zigbee binding and showing the attribute would be very useful

chris · February 11, 2020, 11:32am

Normally you don’t need to worry about this - just get the right firmware. If you want to read it though, it is attribute id 8 so you can read this from the CLI.

Correct. The binding will notify a device that there is a file available, the device then starts the upgrade and one of the first parts of this is to check the file types etc and the transfer will stop if it’s not consistent.

Why? I don’t really understand why this is useful. This is a protocol issue - if you get the files from the manufacturer for your model of bulb, then you should not care. Some devices will also require multiple file types, so it’s not 100% straight forward.

giuseppeiannello · February 11, 2020, 11:46am

Normally you don’t need to worry about this - just get the right firmware.

That’s exactly the point: I can’t figure out which firmware is the right one, I tried multiple ones and I can’t get the binding to start the upload process, so I want to double-check what the bulb says and make sure I am using the right file. I’m starting to suspect the manufacturer_id is not correct, even if the Ledvance download page has OSRAM-specific files.

If you want to read it though, it is attribute id 8 so you can read this from the CLI.

Will give this a try today
Thanks for your help

Bruce_Osborne · February 11, 2020, 12:20pm

They have customer support, right? Ask them!

giuseppeiannello · February 12, 2020, 9:19pm

They have customer support, right? Ask them!

404: nerds not found.

If you want to read it though, it is attribute id 8 so you can read this from the CLI.

openhab> zigbee read 47975/3 25 7
Reading endpoint BB67/3, cluster client cluster Ota Upgrade (0019), attributes Manufacturer ID
Response for cluster 0x0019
Attribute 7, type UNSIGNED_16_BIT_INTEGER, value: 4364

openhab> zigbee read 47975/3 25 8
Reading endpoint BB67/3, cluster client cluster Ota Upgrade (0019), attributes Image Type ID
Response for cluster 0x0019
Attribute 8, type UNSIGNED_16_BIT_INTEGER, value: 65535

The manufacturer id is what I expected (0x110c), but the image type ID seems to be wrong, and that’s the case for all my Osram bulbs.

giuseppeiannello · February 21, 2020, 7:24pm

Success!
After rebuilding the binding using ZSS 1.3.1 (with the CC2531 serial fixes), I finally managed to update all my bulbs with the newest firmware.

The debug log has been very useful to find the image type ID:

9:21:04.000 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - TX CMD: ImageBlockResponse [Ota Upgrade: 0000/0 -> 544F/3, cluster=0019, TID=1C, status=SUCCESS, manufacturerCode=4364, imageType=8, fileVersion=16909577, fileOffset=600

Reading the image type id attribute works fine when the bulb is being updated:

openhab> zigbee read 21583/3  25 8
Reading endpoint 544F/3, cluster client cluster Ota Upgrade (0019), attributes Image Type ID
Response for cluster 0x0019
Attribute 8, type UNSIGNED_16_BIT_INTEGER, value: 8

For all the others, it always returns 65535.