Nice, thanks a lot!
Seems like zigbee_datecode is the best indicator for the installed firmware. Looking at a Busch-Jaeger RM01, zigbee_datecode is 20161209, which corresponds with the OTA file of the installed firmware: 112E_0001_1.2.0_20161209_RockerMains.zigbee.
Some of my devices also have a firmwareVersion attribute, which doesn’t make much sense to me (eg. 0x11040002, 0x11115720). Seems to be too high a value for a build number.
The best one is firmwareVersion this is the one I mentioned that PaperUI displays, and this is the one that is used within OH to compare versions (it’s a system property). It’s also the one that comes from the OTA cluster and is therefore used during the OTA Upgrade process to check if it worked.
The OTA command is as follows -:
ota endpoint file
Where endpoint is the endpoint with the OTA server. The file MUST be a standard ZigBee file format.
Then, once that’s complete -:
ota endpoint complete
This will execute the software on the node.
I will try and add this to the openHAB console at some stage in future.
Which the files provided by IKEA are not unfortunately. I tried them and got the following error:
Error executing command: java.lang.IllegalArgumentException: ZigBee OTA file is not a valid format
Did a little digging and found the following info on github:
“The firmware files of IKEA are raw data, not packet into an standard OTA file format. So in order to use them the .zigbee format binary header must be put before the data payload as described in the spec.”
If someone has a valid OTA zigbee file and wants to give this a try, here are some details of the process:
sudo java -jar ZigBeeConsole.jar -dongle EMBER -port /dev/ttyEM3588 -baud 115200 -flow hardware -c 21nodes commandYou’ll get a list of devices with entries like this one:
Network Addr IEEE Address Logical Type EP Profile Device Type
16972 424C 000B57FFFEB1BAB5 ROUTER 1 ZIGBEE_HOME_AUTOMATION COLOR_TEMPERATURE_LIGHT
Then you should be able to update the firmware like this:
ota 16972/1 filename.zigbee
ota 16972/1 complete
@chris an unrelated question: is it possible to stop all the debug output of the ZigbeeConsole? It’s quite difficult to follow command execution with all the debug output that is generated.
Yes, you can put a log4j.xml file into the folder and use this to adjust the debug output (basically the same as in OH).
The following is what I use - it will print debug to the console so you’d need to disable this.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="null" threshold="null">
<appender class="org.apache.log4j.ConsoleAppender" name="StdOut">
<param name="Threshold" value="debug" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss.SSS} %-5p %m%n"/>
</layout>
</appender>
<appender class="org.apache.log4j.DailyRollingFileAppender" name="RollingFile">
<param name="File" value="logs/debug.log" />
<param name="DatePattern" value="'.'yyyy-MM-dd" />
<param name="Threshold" value="debug" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss.SSS} %-5p %m%n"/>
</layout>
</appender>
<appender class="org.apache.log4j.DailyRollingFileAppender" name="EzspFile">
<param name="File" value="logs/ezsp.log" />
<param name="DatePattern" value="'.'yyyy-MM-dd" />
<param name="Threshold" value="debug" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{HH:mm:ss.SSS} %-5p %m%n"/>
</layout>
</appender>
<logger additivity="true" name="com.zsmartsystems.zigbee">
<level value="debug"/>
<appender-ref ref="StdOut" />
</logger>
<logger additivity="true" name="com.zsmartsystems.zigbee.dongle.ember.ash">
<level value="debug"/>
<appender-ref ref="EzspFile" />
</logger>
<!-- Set the commons logging that the XML parser uses to WARN -->
<logger name="org.apache.commons">
<level value="off"/>
</logger>
<root>
<priority value ="debug" />
<appender-ref ref="RollingFile" />
</root>
</log4j:configuration>
Thanks @chris, I’ve set log level to info now.
Also I found that the IKEA files can be converted to regular OTA files with deconz.
So I did that and executed the commands:
> ota 16972/1 10035514-TRADFRI-bulb-ws-1.2.221.ota
OTA File: ZigBeeOtaFile [headerVersion=256, manufacturerCode=4476, imageType=2201, fileVersion=12221572, stackVersion=ZIGBEE_PRO, headerString=EBL tradfri_light , imageSize=172734]
> ota 16972/1 complete
Doesn’t look like anything happened though. I know the update takes a long time, like 20 minutes. Is there some kind of feedback to be expected or can I somehow check the progress of the update?
You can enable debug logging 
You can try the command otaupgrade - it should print some state information, although probably not the progress.
All the OTA stuff was written a couple of years back for Deutsche Telekom and I’ve not used it a lot myself in recent times.
I did re-enable debug and tried again, but the transaction gets canceled for whatever reason:
14:43:06.000 DEBUG Reading OTA image tag UPGRADE_IMAGE[0000] (172672 bytes long)
OTA File: ZigBeeOtaFile [headerVersion=256, manufacturerCode=4476, imageType=2201, fileVersion=12221572, stackVersion=ZIGBEE_PRO, headerString=EBL tradfri_light , imageSize=172734]
14:43:06.001 DEBUG 16972/1 OTA status updated to OTA_WAITING.
14:43:06.001 DEBUG Sending transaction: ImageNotifyCommand [OTA Upgrade: null -> 16972/1, cluster=0019, TID=NULL, payloadType=0, queryJitter=35, manufacturerCode=4476, imageType=8705, newFileVersion=304223602] ==== com.zsmartsystems.zigbee.zcl.ZclTransactionMatcher@f232c4
14:43:06.002 DEBUG TX CMD: ImageNotifyCommand [OTA Upgrade: 0/0 -> 16972/1, cluster=0019, TID=85, payloadType=0, queryJitter=35, manufacturerCode=4476, imageType=8705, newFileVersion=304223602]
Followed a few seconds later by:
14:43:12.178 DEBUG RX APS: ZigBeeApsFrame [sourceAddress=16972/0, destinationAddress=0/0, profile=0000, cluster=0001, addressMode=null, radius=0, apsSecurity=false, apsCounter=58, payload=84 FD FF 00 00]
14:43:12.178 DEBUG RX CMD: IeeeAddressRequest [16972/0 -> 0/0, cluster=0001, TID=NULL, nwkAddrOfInterest=65533, requestType=0, startIndex=0]
14:43:12.179 DEBUG --> TX ASH frame: AshFrameAck [ackNum=0, notRdy=false]
14:43:13.157 DEBUG ASH: TX EZSP queue size: 1
14:43:13.157 DEBUG --> TX ASH frame: AshFrameData [frmNum=0, ackNum=0, reTx=false, data=09 00 FF 00 18]
14:43:13.162 DEBUG <-- RX ASH frame: AshFrameData [frmNum=0, ackNum=1, reTx=false, data=09 80 FF 00 18 02]
14:43:13.162 DEBUG ASH: Frame acked and removed AshFrameData [frmNum=0, ackNum=0, reTx=false, data=09 00 FF 00 18]
14:43:13.163 DEBUG --> TX ASH frame: AshFrameAck [ackNum=1, notRdy=false]
14:43:14.088 DEBUG Transaction cancelled: ImageNotifyCommand [OTA Upgrade: 0/0 -> 16972/1, cluster=0019, TID=85, payloadType=0, queryJitter=35, manufacturerCode=4476, imageType=8705, newFileVersion=304223602]
It’s not that important as you can’t get OTA files for most devices anyway afaik.
It means the device didn’t respond to the request. It might be something that has been introduced recently (although that’s unlikely as you’re using quite an old console) or it could be that the endpoint doesn’t exist or can’t be contacted.
I think it’s a lot more common that with ZWave - I’ve certainly got a lot of them here, although I’m not 100% sure if they are publicly available.
Ok, thanks for the explanation. The console is indeed quite old, but I guess it won’t make much difference since you said the ota code is quite old either?
I think the endpoint is ok, looks like the device is sending stuff if I’m not mistaken:
14:45:53.019 DEBUG RX EZSP: EzspIncomingRouteRecordHandler [source=16972, sourceEui=000B57FFFEB1BAB5, lastHopLqi=254, lastHopRssi=-40, relayList=ECEF]
But I don’t want to waste even more of your time, it was mostly curiosity to try it out and see how/if it works…
Yes, there have’t been any changes in it for a long time, but I know it is being used by DT so I believe it should work still.
This isn’t coming from the device - this is a notification from the coordinator.
Ok, but it would be good to get going in OH. If you like, please open an issue on GH and I will look at it when I get time (maybe over Christmas). I will only implement it as a console option in OH though since getting it working though PaperUI is a lot more hassle (although it is possible - I’d need to create more software to handle file system issues as per OH interfaces and it’s not worth the effort).
Done: OTA firmware update via OH console · Issue #523 · openhab/org.openhab.binding.zigbee · GitHub
I see.
Ok, I’ll give it another try then. I’ll make sure to send some commands to the device first to see if it is responding correctly.
I tried again with a recent version of the ZigbeeConsole, but the result is the same.
I made sure the endpoint is responding. I can turn it on/off and info works as well:
Node Info Value
APPVERSION 17
DATE 20160927
HWVERSION 1
MANUFACTURER IKEA of Sweden
MODEL TRADFRI bulb E27 WS�opal 980lm
STKVERSION 87
ZCLVERSION 1
> off 16972/1
Success response received.
> on 16972/1
Success response received.
09:38:46.121 DEBUG Transaction cancelled: ImageNotifyCommand [OTA Upgrade: 0/0 -> 16972/1, cluster=0019, TID=18, payloadType=0, queryJitter=67, manufacturerCode=4476, imageType=8705, newFileVersion=304223602]
Unfortunately the only other devices I have OTA files for, are all on the most recent version already. I think I have another Ikea 600lm bulb somewhere, I’ll try with that one too, but I expect the result to be the same.
What “recent version” do you mean? Are you compiling it yourself? If not then it will likely be the same version.
I don’t really have time to look over this at the moment. I have a lot of Osram bulbs that have been used for OTA testing in the past, and some Bitron devices, but at the moment I need to focus on other issues.
The error simply looks like the device is not responding to the request. Can you also provide me the XML for this device? Also, can you provide the full log from the sending of the command to the reception of this error.
I just re-downloaded it from your website and expected it to be a newer version, so it’s probably the same.
No problem. I just wanted to make sure the device is responding to commands to rule out a general communication problem.
Sure:
ota_tradfri_debug_log_20191125.txt (545.7 KB) 000B57FFFEB1BAB5.xml (73.9 KB)
Yes - I’ve not updated it for a long time.
I’ll take a look at the log… Thanks.
Can you also try the cmdsupported command - I think it should be cmdsupported endpoint 25 to get the list of commands that this bulb supports in the OTA cluster. Even if something isn’t supported, the device should really still respond, but who knows…
This is with info level, let me know if I should run it with debug:
Supported generated commands for client cluster OTA Upgrade (0019)
CommandId Command
1 QueryNextImageCommand
3 ImageBlockCommand
6 UpgradeEndCommand
Supported received commands for client cluster OTA Upgrade (0019)
CommandId Command
Also, do you think the device will respond with an error message if the firmware is for another device?
Looking at the code I’ve seen there’s a constant INVALID_IMAGE(0x0096), so I expected to get an error response if the firmware is not the right one.
The reason I’m asking is that IKEA has a few firmware images for bulbs and I’m not 100% certain I’m using the right one.
I’m using 10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed, but there are others:
10035515-TRADFRI-bulb-cws-1.3.009.ota.ota.signed10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed could also be the right firmware for this bulb. It’s hard to tell just by the name.
Interesting - it doesn’t seem to support any received commands. Strange. If it doesn’t support the notify received command that might explain things, although it is meant to respond with a “command not supported” response, and not just ignore it.
Yes, it should do - I’ve tested this with other devices. It won’t know this until the transfer starts though, and the transfer doesn’t start in your log.
I think somewhere I have a Tradfri bulb so when I get a chance I will try this.
Great, thanks. Let me know if you need some firmware files. The files from the IKEA feed are somehow packaged but can be converted to regular zigbee files with deconz.