@chris: Could you just give an update or instructions how to use this?
I can get the files for my Osram Smart+ plugs here: https://update.ledvance.com/firmware-overview
This will give me *.ota files.
Should I simply copy the files somewhere? Any editing or renaming required? And this will trigger the Zigbee binding to flash the plugs?
Thanks for your help 
Connect to the Karaf console:
Increase the log level, helps understanding if the upgrade process is working
openhab> log:set debug com.zsmartsystems.zigbee.app.otaserver.ZclOtaUpgradeServer
Download the right firmware and save it in /var/lib/openhab2/
Get a list of your zigbee devices, and identify which one you want to update
openhab> zigbee nodes
Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model
0 0000 00124B0009EF006A COORDINATOR UNKNOWN
21583 544F 841826000000ECE1 ROUTER UNKNOWN 3 ZIGBEE_LIGHT_LINK POINT_OF_SALE OSRAM Classic A60 TW
45231 B0AF 841826000000EC95 ROUTER UNKNOWN 3 ZIGBEE_LIGHT_LINK POINT_OF_SALE OSRAM Classic A60 TW
48139 BC0B 841826000000EEBD ROUTER UNKNOWN 3 ZIGBEE_LIGHT_LINK POINT_OF_SALE OSRAM Classic A60 TW
50188 C40C 841826000001687F ROUTER UNKNOWN 3 ZIGBEE_LIGHT_LINK POINT_OF_SALE OSRAM PAR16 50 TW
57754 E19A 8418260000CA12E2 ROUTER UNKNOWN 3 ZIGBEE_LIGHT_LINK 0210 OSRAM Classic A60 RGBW
Start the update with
openhab> zigbee otaupgrade start [Network Address]/[Endpoint] [filename.ota]
# EXAMPLE
# openhab> zigbee otaupgrade start 45231/3 ZLL_MK_0x01020509_CLA60_TW.ota
Check the logs
openhab> log:tail
2020-02-21 20:30:39.136 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA status updated to OTA_WAITING.
2020-02-21 20:30:39.502 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA status updated to OTA_TRANSFER_IN_PROGRESS.
2020-02-21 20:30:40.366 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 60 bytes at offset 0
2020-02-21 20:30:40.873 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 60 bytes at offset 60
2020-02-21 20:30:40.975 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 60 bytes at offset 120
[snip]
2020-02-21 20:38:27.498 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 60 bytes at offset 133320
2020-02-21 20:38:27.603 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 60 bytes at offset 133380
2020-02-21 20:38:27.691 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA Data: Sending 4 bytes at offset 133440
2020-02-21 20:38:28.076 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA status updated to OTA_TRANSFER_COMPLETE.
2020-02-21 20:38:28.416 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA status updated to OTA_UPGRADE_FIRMWARE_RESTARTING.
2020-02-21 20:38:51.236 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - B0AF/3 OTA status updated to OTA_UPGRADE_COMPLETE.
Restore the original log level
openhab> log:set info com.zsmartsystems.zigbee.app.otaserver.ZclOtaUpgradeServer
Keep in mind that with the current Openhab version (2.5.2) and CC2531, the update process is not working reliably. The next release should include a fix.
i tried to follow your guide but did not succeed
copied the osram plug01 related ota file to /var/lib/openhab2/
identified the device via the console (network/endpoint)
setting the log to debug (Which then later shown no relevant activity)
started the upgrade
openhab>zigbee otaupgrade start 20320/3 ZLL_Plug01_OnOff_MK_0x01020509.ota
upgrade failed:
Error: Exception during command execution (IllegalArgumentException): Error reading OTA File "ZLL_Plug01_OnOff_MK_0x01020509.ota"
Do you have any hint?
Ps I am on rpi3b with bitronvideo dongle and latest oh 2.5.3
Maybe you should provide the full path name as it can’t find the file.
@TheNON file permissions? OpenHAB by default runs as openhab - make sure the file is owned by that user or has at least read permissions for all the users (chmod a+r /var/lib/openhab2/ZLL_Plug01_OnOff_MK_0x01020509.ota)
I use the following howto here to update my Osram devices with the latest Ledvance firmware.
Regarding the URL for the official Osram firmware (which seamed to be older then the Ledvance) this can be found here: http://s3-eu-west-1.amazonaws.com/lightify-osram-firmware/
However it seamed they use there own format so I could´t find a way to flash those version via deCONZ.
Note that this discussion is on the ZigBee binding rather than deCONZ binding.
The Osram bulbs should use the standard format for the OTA files - I’ve used them a lot here, but I think the link you provide here the files are encrypted. Unfortunately many suppliers often don’t provide their firmware updates except via their authorised suppliers.
I’m hoping to try and write up how to use OTA firmware provider in the next few days…
I finally got around to writing this up this afternoon. The following shows how to use the OTA Firmware Provider - this is for ZigBee, but ought to work for other bindings supporting the OTA features as well.
The first thing you need to do is to install the Firmware Provider. This is a simple provider that allows users to drop firmware files into the userdata folder along with the required metadata. The firmware provider can be downloaded here, and should be installed into the addons folder as with any other extension.
To create a firmware file for use with the provider, you first need the firmware itself. For ZigBee, this must be the standard ZigBee OTA file format from the device manufacturer. In the example below, I will upgrade an OSRAM RGBW A60 bulb - the firmware was downloaded from here.
You need to create a file called directory.xml with the following format -:
<Directory>
<DirectoryEntry>
<filename>ZLL_MK_0x01020510_CLA60_RGBW_OSRAM.ota</filename>
<thingTypeUid>zigbee:device</thingTypeUid>
<version>0x01020510</version>
<vendor>OSRAM</vendor>
<model>CLA60 RGBW OSRAM</model>
<description></description>
<hash></hash>
<prerequisiteVersion></prerequisiteVersion>
</DirectoryEntry>
</Directory>
The values here are obviously important. The filename is the name of the OTA file, the vendor and model are values the bulb reports - you can see these in the properties -:
These MUST be the same values for the firmware provider to match the firmware. Note that the thingTypeUid will normally be zigbee:device for ZigBee - unless there is a specific device type (but there are only a few of these which are required to work around manufacturer specific features).
The version is binding dependant, but for ZigBee will be a hexadecimal number (so starting with 0x). If you don’t know the file version, you can find it from the console with the command -:
> otaupgrade file ZLL_MK_0x01020510_CLA60_RGBW_OSRAM.ota
OTA File: ZigBeeOtaFile [headerVersion=256, manufacturerCode=4364, imageType=0062, fileVersion=01020510, stackVersion=ZIGBEE_PRO, headerString=NULL, imageSize=142972]
This shows the version is 01020510, so we use 0x01020510 in the XML file.
You must then ZIP up the OTA file along with the directory.xml file. You can call the resulting file whatever you like, but it must have the extension fwp. This file must be placed into a folder called userdata\firmware.
It’s worth noting that you can add multiple OTA files into a single FWP file simply by adding more <Directory> entries in the XML and ZIPing up all the OTA files. This allows (for example) all OSRAM firmware files to be distributed in a single FWP file.
Now to update the firmware…
In PaperUI, go to the Thing Configuration. If the firmware file is not in the firmware folder, or the firmware provider isn’t running, or there is no match with the device information, then the firmware state will be UNKNOWN -:
If new firmware is available, you will have the option to install it -:
Click the install button and grab a coffee (well, maybe just an expresso - it doesn’t take too long) -:
Once the transfer completes, the bulb will restart (it will normally flash) and after maybe 30 to 60 seconds the bulb should come back online in PaperUI -:
You bulbs firmware is now Up to date.
Does that mean this is only for Windows users?
All other Operating Systems would use something like userdata/firmware 
Attempting to update some of my IKEA bulbs with this… I stripped off IKEA’s weird header, and put together the directory.xml and .fwp archive, and I can see it offering to install updates in Paper UI. I click Install, and it starts the update, and watching the log, it seems to go fairly smoothly up until the end, where I get the following:
2020-03-29 21:34:51.733 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 9062/1 OTA Data: Sending 60 bytes at offset 208980
2020-03-29 21:34:51.873 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 9062/1 OTA Data: Sending 46 bytes at offset 209040
2020-03-29 21:34:51.963 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 9062/1 OTA status updated to OTA_TRANSFER_COMPLETE.
2020-03-29 21:34:52.072 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 9062/1 OTA status updated to OTA_WAITING.
2020-03-29 21:34:52.075 [WARN ] [zsmartsystems.zigbee.ZigBeeExecutors] - Uncaught exception in thread NotificationService-thread-36
java.lang.IllegalStateException: There is no further progress step to be executed.
at org.eclipse.smarthome.core.thing.internal.firmware.ProgressCallbackImpl.next(ProgressCallbackImpl.java:112) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$4.otaStatusUpdate(ZigBeeThingHandler.java:957) ~[?:?]
at com.zsmartsystems.zigbee.app.otaserver.ZclOtaUpgradeServer$2.run(ZclOtaUpgradeServer.java:517) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_212]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_212]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
2020-03-29 21:34:54.958 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 9062/1 OTA Error: Invalid server state OTA_WAITING when handling UpgradeEndCommand.
I’m running OH 2.5.3, and the version of the firmware provider in your documentation post.
The bulbs never leave the “offline - firmware_updating” state in Paper UI until I restart OH.
Any suggestions?
What bulb is this? Can you provide the firmware file you’re using - I have a few Ikea bulbs so maybe I can try this.
Is there something on the web on what the format is from Ikea? Maybe I can make the binding do this before it sends the data to the ZigBee library.
I’m not sure it’s really documented, but I looked for the OTA header marker and worked backwards. IKEA ships their firmwares as .OTA.ota.signed files, and the first four bytes are NGIS (SIGN backwards). The fourth four-byte little-endian word(so 0xC to 0xF) in the file contains an offset from that point to the start of the OTA segment.
I don’t know what the part number on these bulbs is, but they’re the 1000lm adjustable temperature white bulbs.
I can post files in the morning.
Folder of firmware I’m working with
Here’s the files I’ve been trying to work with. The .ota.ota.signed is the original file from IKEA, the .ota.ota.signed.ota is with the NGIS header removed, and the .ota.ota.signed.stripped.ota has the NGIS header and what appears to be an extra 0x200 bytes at the end removed, if I’m understanding the OTA header correctly.
The directory.xml and .fwp files are included too, for completeness.
And as for which bulb these are, IKEA seems to have two different listing for this type of bulb. Listing #1, and Listing #2. I’m not sure if those are actually different, or which one I have. They’re even using the same pictures on them.
Also, possibly of concern and/or interest… I seem to be getting the option to install that firmware on several other devices, as well. I have an in-wall Zigbee dimmer switch made by Jasco Products, and it’s offering to install the IKEA firmware on it. Hopefully it wouldn’t actually take, but I’m not going to try it and find out.
What does PaperUI say in the properties - that’s what’s important.
I guess the directory is not correctly defined. I will take a look at your file.
Also, I’m starting to think my install may have deeper issues… One of my other bulbs that has previously worked just fine is now showing it’s status as “offline - handler_initializing_error”, and another is showing “offline - handler_missing_error”… Something strange is afoot.
Unfortunately I don’t have the same bulb as you and can’t find the firmware for the Ikea bulb I have. Please can you perform the upgrade again but with debug enabled as per the binding docs so I can try to see what is happening.
Hope this is relevant:
For Ikea firmware it is possible to get a json file from http://fw.ota.homesmart.ikea.net/feed/version_info.json
URLs for firmware inside.
Thanks, I am aware of this, but as I mentioned, it doesn’t include the firmware for bulb I have. I’m not personally worried about updating my bulb so all I need is the log I requested so I can see what is happening.