zigbee2mqtt
zigbee2mqtt copied to clipboard
Koenkk
OTA check for new firmware does not check
What happened?
Having two Bosch BTH II thermostats. I tried to update one, which failed telling about an issue in OTA communication. The other one worked. As you can see in the image, it shows that the firmware was updated on the second one but the first one still hast the old FW. Clicking on Check for new updates does not change the situation. Also tried to trigger via MQTT with zigbee2mqtt/bridge/request/device/ota_update/check, but the response is the same:
{
"data": {
"id": "Wohnzimmer/KF-BTH-RA-LG",
"updateAvailable": false
},
"status": "ok",
"transaction": "wiqry-1"
}
I have checked if the device is able to communicate to change requests and this works without issues.
It just seems that there was a "glitch" in the update communication. But whyever, the code does not respect the FW difference on manual check request. From an outer perspective, something is preventing this check.
Note that the battery is full (95%) on both thermostats.
Trying to update via MQTT returns:
{
"data": {
"id": "Wohnzimmer/KF-BTH-RA-LG"
},
"error": "Update of 'Wohnzimmer/KF-BTH-RA-LG' failed (No new image available)",
"status": "error"
}
What did you expect to happen?
When pressing the manual check button or run a MQTT recheck and there is a FW differernce in installed vs available, the check must succeed.
How to reproduce it (minimal and precise)
Click check for new FW or via MQTT publish and it should tell that there is a newer FW available if the device shows a lower FW.
Zigbee2MQTT version
1.30.4 commit: b2dd21e
Adapter firmware version
20221226
Adapter
Sonoff_Zigbee_3.0_USB_Dongle_Plus
Debug log
No response
My guess is that the update worked and just the displayed build id and build date is wrong as it's cached. Could you check the response in the dev console with the following settings?
hmmm, I tried, but...
- When reading the two settings, there is no response at all ! Double checked on both thermostats.
- Retested communication on both devices, changed settings get transmitted.
- Selecting another value to read like:
genOnOff(["onOff"]returned:Zigbee2MQTT:error 2023-05-21 13:24:15: Publish 'set' 'read' to 'Wohnzimmer/KF-BTH-RA-LG' failed: 'Error: Read 0x18fc26000006735b/1 genOnOff(["onOff"], {"sendWhen":"active","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 56555 - 1 - 135 - 6 - 1 after 10000ms)' - Testing with other sensors like the
Aqara door & window contact sensor(Xiaomi), I get:Zigbee2MQTT:error 2023-05-21 14:43:35: Publish 'set' 'read' to 'Wohnzimmer/KF-Links' failed: 'Error: Read 0x00158d0008d964e4/1 genBasic(["manufacturerName"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'MAC transaction expired' (240))'
I am confused and run out of ideas...
While playing around to get the requested infos, "something has happened" (tm), see the images:
The FW now shows the correct one, though the Update button shows up.
Then, clicking on update, it does nothing and changes to blue and funnily (without image posted) the other BTH shows now whyever that you can update the FW. This finally, and only goes away when clicking on Check all...
Seems that the code for the OTA handling needs some intense love.
Hmm, that's strange. How does the information in the state tab of the top thermostat look like? Did you remove the batteries of the BTH-RA for a few seconds after the update?
I had the same 'issue', updated 5 thermostats - 3 of them updated without any issue, displayed version is 3.05.05, but for remaining 2 it stayed 3.04.04. I've restarted the devices by taking the battery off for a few seconds, but it didn't help - in z2m's OTA it was still 3.04.04. After reading those 2 attributes mentioned above from a dev console, it somehow refreshed the data and already version is displayed correctly. Seems that FW update works fine, it's just some issue with refreshing the version id.
I had the same 'issue', updated 5 thermostats - 3 of them updated without any issue, displayed version is 3.05.05, but for remaining 2 it stayed 3.04.04. I've restarted the devices by taking the battery off for a few seconds, but it didn't help - in z2m's OTA it was still 3.04.04. After reading those 2 attributes mentioned above from a dev console, it somehow refreshed the data and already version is displayed correctly. Seems that FW update works fine, it's just some issue with refreshing the version id.
Yeah, same thing happened with some of my Inovelli blue switches. The firmware update occurs successfully behind the scenes but for some reason Z2M is caching something which makes it appear to be on the old firmware. The swBuildId trick mentioned above fixed the cached details and the firmware info displayed correctly for me.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Yeah agreed, this should remain open. It doesn't seem like a show stopper kind of bug because a work around exists, but annoying nonetheless.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days
Keep open as all other related tickets mentioned above appear closed without a resolution.
Today I had the same problem while updating a brand-new BTH-RA form 3.02.05 to 3.05.05. dev console (see above) reported 3.05.05, while MQTT said "installed_version": 839193876 (= 3.02.05).
The solution was the orange button "reconfigure" ("Neu konfigurieren") in the Devices ("Geräte") view. Afterwards MQTT said "installed_version": 889525524 (= 3.05.05)
UPDATE: Immidiately after the OTA transfer of the update the "About" tab of the BTH-RA reported 3.02.05 even after a battery removal. About 2 hours later it reported 3.05.05 without further invention from my side during this time. I think the BTH-RA waits until there is some time of inactivity until the actual firmware update is performed.
z2m version 1.34.0-1. After OTA update 3.02.05 -> 3.05.05 the valve started having lots of communication issues - essentially climate.set service wasnt working reliably. Had to restart the valve (remove battery a few secs). Comms working again after that - however, still wrong firmware version displayed. Dev Console trick mentioned above didnt work for me. Restarted the z2m add-on and now proper firmware is displayed. All good again :)
@mmattel : Did you got any errors during the update? Or did anything with the device at the end except maybe pushing the button when the calibration is requested? I look at the code right now and try to understand why this happens.
@DerDreschner what happened is the following:
- I needed multiple attempts for the update. Three in total on each thermostat. For an unknown reason, the thermostats consecutively reported that an upgrade is not possible just during uploading the data. There is good signal strength and upgrades ran ony by another and not in parallel.
- After upgrading, the thermostats requested pressing the gray button to recalibrate and all was fine.
Many thanks for providing the upgrade capture 🎄
@mmattel : Mhm, I see. It would be great to have a debug log from when this occurs. I also had a "invalid image" at the end of the firmware update once. After a reset by removing the batteries, the update went through flawlessly. Guess it would be the easiest to recommend that in the docs before each update (although I would hate to do that in larger installations personally).
@fishi0x01 @hmaiss @ThatTallGuy21 @mbak77 : In case anyone of you still has to do an update to the latest 3.05.09 from last week: Please enable debug logging before doing the update and - in case something goes wrong - paste the log file here. You can find more informations about how that works under this link: https://www.zigbee2mqtt.io/guide/usage/debug.html
Thanks!
@DerDreschner : I am somewhat behind with 1.33.1. I will use the current Z2M container when I update the 5 remainig BTH-RA after some time of testing.
@DerDreschner : Today I have updated the Z2M container from 1.33.1 to 1.35.1, wherein two BTH-RA where updated afterwards with debug logging enabled (https://www.dl3hm.de/log.zip).
The first BTH-RA was brand new. The update was from 3.02.05 to 3.05.09. At the end of the udate process some error messages showed up in the GUI. I was not able to directly read the swBuildId via the Developer Console. After removing and reinserting the battery everything was fine and the correct firmware version 3.05.09 showed up in the GUI. No GUI -> Devices -> reconfigure was necessary as in the past.
The second BTH-RA was updated from 3.05.05 to 3.05.09. At the end of a first run the transferred update was refused. Even after removing and reinserting the battery the old firmware version showed up in the GUI. The second run went fine. No battery removal or other steps where necessary to bring up the correct firmware version in the GUI. No error message showed up.
UPDATE: During the night I have seen a malfunction of the second BTH-RA (does not react to regular settings of pi_heating_demand). I have removed and reinserted the battery to solve this problem.
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days