If the bulb restarts it should be a good sign. That is if the whole OTA has been received.
At least the OTA is not outright rejected. One question is if the bulb asks for the same image type/id again or wants another image.
I can repeat the update again, the bulb behaves the same way as before update (reports the same image type, unlike the socket I also updated which now reports 0xffff according to spec). The ota server even checks the version at the end of update and then reports failure since the bulb does not return version from ota file.
@m0rgoth then I have no clue…
@domofl I see the repeater reports as applicationversion 33.
It is not clear to me when those fields is updated in the UI.
Repower the repeater and maybe delete it and then reinclude.
@chris
Would it make sense to add the firmware version to the zigbee info command?
openhab> zigbee info 49940/1
Requesting ZCL Version
Requesting Application Version
Requesting Stack Version
Requesting HW Version
Requesting Manufacturer Name
Requesting Model Identifier
Requesting Date Code
Requesting Power Source
Requesting Generic Device Class
Requesting Generic Device Type
Requesting Product Code
Requesting Product URL
Requesting Location Description
Requesting Physical Environment
Requesting Device Enabled
Requesting Alarm Mask
Requesting Disable Local Config
Requesting SW Build ID
Device information for endpoint C314/1
Node Info Value
Application Version 1
Date Code
HW Version 1
Manufacturer Name MLI
Model Identifier tint-ExtendedColor
Power Source 1
SW Build ID TDU50D01
Stack Version 1
ZCL Version 2
I do not trust the up-to-dateness of the values in the GUI.
I’ll have to think about this. The info command requests all the supported attributes in the BASIC cluster - this includes things like the Application Version and many other versions. It was meant to just cover information from this one cluster and extending it to other clusters might be a pain in some applications (remember these console commands are not just used in openHAB).
Another option might be to extend the OTAUPGRADE command to provide a little more information on each client. Let me have a thing about this…
I would also need to check if the GUI is updated after the OTA completes - possibly not. But also you need to be careful with the CLI - this information is not updated unless you add the refresh parameter on the end of the command. Otherwise it will return the last value received as again this information is not normally updated.
1 Like
I just checked and the firmware version in the binding properties is only updated if the firmware update is completed through the UI - ie using the standard OH firmware upgrade system. If it’s done through the OTA CLI command, then it won’t be updated.
I’m not sure if this can easily be kept in sync - I could synchronise on startup, but also need to be careful about causing a load of unnecessary traffic…
@NilsOF: Ok I enabled logging for the ota with this as result:
2022-01-24 17:46:40.504 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 90D7/1 OTA status updated to OTA_UPGRADE_FAILED.
2022-01-24 17:46:56.082 [DEBUG] [s.zigbee.app.otaserver.ZigBeeOtaFile] - Reading OTA image tag UPGRADE_IMAGE[0000] (185744 bytes long)
2022-01-24 17:46:56.090 [DEBUG] [s.zigbee.app.otaserver.ZigBeeOtaFile] - Reading OTA image tag UNKNOWN[FFBF] (64 bytes long)
2022-01-24 17:46:56.092 [DEBUG] [s.zigbee.app.otaserver.ZigBeeOtaFile] - Reading OTA image tag UNKNOWN[FFBE] (11170 bytes long)
2022-01-24 17:46:56.093 [DEBUG] [ee.app.otaserver.ZclOtaUpgradeServer] - 90D7/1 OTA status updated to OTA_WAITING.
So not sure if it is the same as this: https://forum.phoscon.de/t/cannot-otau-tradfri-signal-repeater-from-v-2-3-070-to-v-2-3-086/1193 ?
I guess it depends on how the “higher security” is implemented. Is it based on a security key embeded in the OTA or on the location where the OTA is coming from?
some more log info…
2022-01-24 18:42:54.560 [WARN ] [e.ember.internal.ash.AshFrameHandler] - ASH: ERROR received (code 81). Disconnecting.
2022-01-24 18:42:55.603 [INFO ] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee dongle inactivity timer. Reinitializing ZigBee
2022-01-24 18:42:58.400 [ERROR] [ding.zigbee.internal.ZigBeeDataStore] - 804B50FFFE40A298: Error reading network state:
com.thoughtworks.xstream.converters.ConversionException:
---- Debugging information ----
cause-exception : com.thoughtworks.xstream.io.StreamException
cause-message :
class : java.lang.String
required-type : java.lang.String
converter-type : com.thoughtworks.xstream.converters.SingleValueConverterWrapper
wrapped-converter : com.thoughtworks.xstream.converters.basic.StringConverter
path : /ZigBeeNode/endpoints/ZigBeeEndpoint/inputClusters/ZclCluster/attributes/entry[6]/ZclAttribute/lastValue
line number : 163
class[1] : com.zsmartsystems.zigbee.database.ZclAttributeDao
required-type[1] : com.zsmartsystems.zigbee.database.ZclAttributeDao
converter-type[1] : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
class[2] : java.util.HashMap
required-type[2] : java.util.HashMap
converter-type[2] : com.thoughtworks.xstream.converters.collections.MapConverter
class[3] : com.zsmartsystems.zigbee.database.ZclClusterDao
required-type[3] : com.zsmartsystems.zigbee.database.ZclClusterDao
class[4] : java.util.ArrayList
required-type[4] : java.util.ArrayList
converter-type[3] : com.thoughtworks.xstream.converters.collections.CollectionConverter
class[5] : com.zsmartsystems.zigbee.database.ZigBeeEndpointDao
required-type[5] : com.zsmartsystems.zigbee.database.ZigBeeEndpointDao
class[6] : com.zsmartsystems.zigbee.database.ZigBeeNodeDao
required-type[6] : com.zsmartsystems.zigbee.database.ZigBeeNodeDao
version : 1.4.18
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:77) ~[?:?]
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:66) ~[?:?]
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) ~[?:?]
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:499) ~[?:?]
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:425) ~[?:?]
at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:277) ~[?:?]
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) ~[?:?]
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:72) ~[?:?]
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) ~[?:?]
at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) ~[?:?]
I think @chris is the one to comment on the logs 
I suspect that you have a upgraded device as it now reports applicationversion 33.
You can test for what firmware it wants (as in the orginal post).
If it reports 65535 (FFFF in hex) we can be fairly certain that firmware has been updated.
Forget about the link i posted above pointing to a bug at deconz. This is not what you are seeing.
As for the security stuff they are talking about there; we have to wait and see what it is about.
This logging only shows that the transfer failed (ie OTA_UPGRADE_FAILED) - it’s really pretty much impossible to provide a lot more comment from just this since status - sorry. I’d need to see what was happening with the transfer to saw why it failed.
This log has nothing to do with OTA. This is related to the XML files that are saved by the binding as part of the device database so that it doesn’t need to request all the device data again. I can’t really say why it failed without seeing the XML itself.
It gave a “failed” message because at that exact time I started a new “zigbee otaupgrade start” the curious part is that it then got stuck in the “OTA_WAITING” then nothing happens.
I do not fully get where I can see that
Thx
Again though, I’m unable to help without seeing the logs as there’s just no information that allows me to help. Sorry.
If I remember correctly, application version is shown in the thing properties.
Ok so I actually managed to update some of my bulbs. Looks like updating straight to the latest version does not work - bulb downloads the firmware but after restart keeps the old one. I had to first upgrade to 2.0.022, then 2.0.023, now waiting for update to the latest 2.0.029.
This happens to me as well, seems like sometimes the device does not start ota update right away, you have to wait until it starts the download by itself.
How long before it starts in your case? Do you think I may need to get an older version first as well?
One started like 5 minutes later, in logs I saw one update after several hours. You can try power cycling them or running the otaupgrade command again.
It appears in the UI that the FW version got updated. Not sure when that happened, the log is showing nothing, maybe it updated before I actually turned on debug logging. But seems it worked!
Thanks all for the suggestions and help
Where did you find the old versions?
I have some trouble updating the 1000 lumens bulbs, but I am not sure what is going on.
I have to set up a test system so I can Isolate the upgrades from all the noise that is on my production system.
I used internet archive to get older version of that ikea updates json, all the old files still exist - https://web.archive.org/web/*/http://fw.ota.homesmart.ikea.net/feed/version_info.json
Btw seems like I’ve been too optimistic, because I still can’t get any of my bulbs to update to the 2.0.029. They must have changed something between 23 and 29 because all the bulbs just won’t install the new version no matter how many times I try it. I also tried updating my Fyrtur blinds but I can’t get it to start download.
1 Like
I have all mine all updated to latest version. What may help is reboot, then immediately queue the FW update in the console. I did update 2 signal repeaters first. Also what I saw sometimes is that it tries to start but then just keeps asking for the first 60 bytes but never succeeds (switch on the debug logging to check this). The only way to tell if it actually was updated is to reboot, apparently the UI will not update the FW version unles you restart.
The wireless rollershutter button took some more patience to update, like 1 day before it finally decided to start. Note that the binding does not support the commands that it sends, so that kind of pointless now, but I hope that in the future support will be added! (@chris if you have time I would really appreciate it!)
1 Like
Hi all,
Seems my issue is a bit off-topic, but since I searched the forums and nobody seems to have the problem I am experiencing (except for 2 people maybe), thought I’d ask here.
Is there any reason openhab says my tradfri outlets turn on when in fact they do not? Openhab says the outlets and gateway are online and reachable, and I find all the expected stuff in the logs. The only thing that does not happen is: switching the darn outlets! Normally I would expect openhab to throw an error, so I could debug. But it’s hard to debug when the software thinks everything is fine.
Documented my problem thoroughly here (Tradfri Binding: cannot create working gateway (bridge) - #3 by dikkedimi), hope anyone can offer a clue as to what is the issue.