Maybe you should provide the full path name as it can’t find the file.
1 Like
@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)
2 Likes
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.
5 Likes
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.
1 Like
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.
2 Likes
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.
Oki, my zigbee stick is still in transit/customs/whatever.
It will take some time before I am able to produce a log.
following this thread because it is a feature I see good use for 
It seems a bit old. Is this json the last one? what is the best practices to find the new one?
I have some ikea and some hue lamps. To update the hues I have to remove it and readd to hue bridge and than back to OH… for Ikea I don’t have the bridge…
Ask the manufacturer. That is not an openHAB question.