Is it possible to upgrade Tradfri or Hue hardware firmware without their hubs?

Hardware Home Automation
1

I have a working test setup using OpenHab, a Zigbee controller and a combination of several hardware vendors devices (Hue, Tradfri, etc.).
Is it possible to upgrade such hardware firmware without their respective hubs ?

1 Like
2

I am not sure if you can, but if working what would be the need?

1 Like
3

well… ever time I log into the Hue app, it updates something, if not everything. They are obviously developing the software. Should I just ignore this development ?

1 Like
4

I think the ZigbeeConsole included in @Chris’ Zigbee framework supports OTA firmware updates.

However, I don’t know the details or if the command is documented in detail anywhere.

5

Yes, the console supports OTA. It’s relatively simple to use so I can provide the information if needed and if the OTA files are available.

1 Like
6

@Andrew_Rowe I struggled with this also for a long time. I actually still have a tradfri buld connected to the hub and all other to decomz.

I have come to realize though that if the system is functioning to your needs then don’t worry about it. This may be a foolish belief but in my mind the way I use a light I can’t come up with anything they could do to make a dimming light better.

I do agree with one thing though. It is nice to keep things current just in case in the future you do want it, but I have left this thought behind for lights.

7

Thanks for confirming this.

For IKEA it seems all the information required to integrate such updates is available. Here’s what I’ve found so far:

Sources:

If there is some development to support this for IKEA devices, I’d be interested in testing and documenting it.

I haven’t researched such resources for Hue or other products.

8

If this uses the standard ZigBee OTA file format, as specified by ZigBee, then it should work. If it uses different file formats, then it won’t be possible unless someone creates a program to convert to the standard format.

9

@MagicFab To get you started, you’ll need the ZigBeeConsole.jar, which you can download from @chris’ website here.

Depending on your dongle you can then start it like this:
sudo java -jar ZigBeeConsole.jar -dongle <dongle> -port /dev/<port> -baud <baudrate> -flow <hardware|software> -c <channel>

@chris I’d also be interested in how to actually use the ota command, you never know when information like this might become handy.

Also, is it possible to get the current firmware version of a device? Doesn’t look like it’s included in the thing properties in PaperUI/HABmin.

2 Likes
10

I will document this later - it’s pretty simple.

Yes, this should be in the properties of the device if the device provides it. There are 2 or 3 different properties and they aren’t always the same. Some are provided in the BASIC cluster (I think there’s an application version and datecode), but there’s also one that comes from the OTA cluster - this is the one that PaperUI displays (if it doesn’t know it, it shows UNKNOWN).

1 Like
11

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.

12

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.

13

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.

14

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:

  • put the OTA file in the same folder as ZigbeeConsole.jar
  • stop openhab
  • start ZigbeeConsole.jar (example for my network/coordintaor: sudo java -jar ZigBeeConsole.jar -dongle EMBER -port /dev/ttyEM3588 -baud 115200 -flow hardware -c 21
  • wait for startup and discovery to finish and execute the nodes command

You’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.

1 Like
15

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>
1 Like
16

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?

17

You can enable debug logging :slight_smile:

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.

18

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.

19

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.

20

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…