-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZclOtaUpgradeServer should not enforce querying the current file version after update #1087
Comments
One additional "bug" that I just found in there is the reason for
Apparently AFTER the |
Thanks Stefan. Can I suggest we address these two issues separately... Let's address the querying of the attribute here - that should be simple. The change in endpoints is another question - that seems a bit more difficult as we probably need to effectively remove all current endpoints and rediscover the device. I suggest to open a new issue for this. |
Agreed, I have opened #1088 for the endpoint change. Regarding the unsupported attribute: Do you have an idea on what to ask the device in order to determine its working with the new firmware? I mean if the attribute is not supported, I guess we could only try to send a command to see if it is back alive, but not compare the firmware versions... |
Ideally, we should still get a response even if it's unsupported, but the API won't return this directly through the attribute read API. It should be possible instead to use the In the event that the attribute is unsupported, you should expect a |
The problem is that I cannot try this out unfortunately. It only happened in some cases fro some devices with some firmwares. And unfortunately our framework has tons of restrictions of firmware files, distributed over various systems, that its not as easy as "downgrading the a-forementioned plug and upgrading it again". So I fear I cannot directly test it... However, the approach sounds plausible to me. So you suggest to use
to query the attribute and only take it as a failure if no response at all is received? |
Yep - that's exactly what I was thinking of :) I think you can test this in two ways.
|
One question about:
the Since you already said that we are somehow working around the general attributes API anyway, I am wondering how to solve this without offering an API that encourages people to work around the original API. |
Hmmm - I had in the back of my mind we might hit something like this... I guess one option could be to add a method |
Fixes zsmartsystems#1087 Signed-off-by: Stefan Triller <[email protected]>
Fixes zsmartsystems#1087 Signed-off-by: Stefan Triller <[email protected]>
Fixes zsmartsystems#1087 Signed-off-by: Stefan Triller <[email protected]>
Fixes zsmartsystems#1087 Signed-off-by: Stefan Triller <[email protected]>
…1091) Fixes #1087 Signed-off-by: Stefan Triller <[email protected]>
The
ZclOtaUpgradeServer
attempts to read the current file version from a device 10 times (in the logs there are even further attempts after the failure...):com.zsmartsystems.zigbee/com.zsmartsystems.zigbee/src/main/java/com/zsmartsystems/zigbee/app/otaserver/ZclOtaUpgradeServer.java
Lines 462 to 478 in 6a2bf25
if it cannot retrieve it, it marks the upgrade as failed.
According to the zigbee specifiactions the
CurrentFileVersion
(0x2) attribute from theOTA Upgrade Cluster
(0x19) is optional, so the device must not support it.Not having the option to always compare the firmware versions after an update makes me wonder whether there is another feature where one can determine that the upgrade was successful. I see the
DeviceAnnounce
in the logs, so the device has certainly rebooted. It also runs on the new firmware now.Here is the log from an attempt for an update. it starts at the beginning of
ZclOtaUpgradeServer#completeUpgrade()
where it queries theZclOtaUpgradeCluster.ATTR_IMAGEUPGRADESTATUS
:The text was updated successfully, but these errors were encountered: