Is it completing and then still showing 2.14 with an update available, or is it giving an error
I’m using zha, so I don’t get a lot of feedback… It seems like it’s completing, but says it’s all 2.14, and will start updating again after a few minutes…
Same thing is happening to me as well. 10 out of the 22 switches I have keeps updating. Once complete checking the version still shows 2.14. After a few minutes it will then start the update process again. This is using ZHA in HA.
If you’re using ZHA, I would expect there to be some sort of logging in the HA logs showing what’s happening. You may have to set logging to debug. I’m a Z2M user so maybe a ZHA user could chime in about how it handles logs.
1 Like
Yea, I included a log in a post above as well, but there’s a lot there and I’m not totally sure what I’m looking for… I’m not home or I’d link to it again
Not yet ready with my house for switches, but was having similar issues with other zigbee devices. Moved to Z2M AND still has issues. Updates not completing or thought they completed and then they would restart updating. Then performed the updates via the Z2M UI and avoided HA for running the updates. Everything updated correctly and finalized. Just a data point. YMMV.
2 Likes
The OTA update does appear to be completing and showing file_version=16908815 which is definitely 2.15
2023-08-24 10:40:48.861 DEBUG (MainThread) [zigpy.zcl] [0x5EC7:1:0x0019] OTA image_block handler for 'Inovelli VZM31-SN': field_control=0, manufacturer_id=4655, image_type=257, file_version=16908815, file_offset=306760, max_data_size=63, request_node_addr=None, block_request_delay=None
2023-08-24 10:40:48.861 DEBUG (MainThread) [zigpy.zcl] [0x5EC7:1:0x0019] OTA upgrade progress: 100.0
2023-08-24 10:40:48.861 DEBUG (MainThread) [zigpy.zcl] [0x5EC7:1:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=79, command_id=5, *direction=<Direction.Client_to_Server: 1>)
2023-08-24 10:40:48.923 DEBUG (MainThread) [zigpy.zcl] [0x5EC7:1:0x0019] OTA upgrade_end handler for 'Inovelli VZM31-SN': status=Status.SUCCESS, manufacturer_id=4655, image_type=257, file_version=16908815
2023-08-24 10:40:48.924 DEBUG (MainThread) [zigpy.zcl] [0x5EC7:1:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=False, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=80, command_id=7, *direction=<Direction.Client_to_Server: 1>)
Is there a way to force ZHA to read the same cluster as what’s being done with Z2M?
What’s happening on Z2M is that the update completes, but then you have to manually pull the firmware version for Z2M to show the right number. If the same is happening in ZHA and it’s set to not only automatically update but also to force that update, it will just continue to loop.
On an unrelated note, you do have an error with an OTA file for a different device
Error Log
2023-08-24 10:28:17.123 DEBUG (MainThread) [zigpy.ota.provider] FileStore: ImageKey(manufacturer_id=4447, image_type=14976): Preferring '/config/zigpy_ota/20221009111923_OTA_lumi.curtain.acn002_0.0.0_1530_20221009_6C9C3D.ota' over '/config/zigpy_ota/20220728181102_OTA_lumi.curtain.acn002_0.0.0_1529_20220720_47B747.ota'
2023-08-24 10:28:17.125 DEBUG (SyncWorker_1) [zigpy.ota.provider] File '/config/zigpy_ota/20211228180917_OTA_lumi.switch.b1naus01_0.0.0_0031_20211228_5689C8.ota' doesn't appear to be a OTA image
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 272, in parse_ota_image
return HueSBLOTAImage.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 200, in deserialize
header, remaining_data = OTAImageHeader.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 112, in deserialize
raise ValueError(
ValueError: Wrong magic number for OTA Image: 168430090
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/provider.py", line 515, in scan_image
parsed_image, _ = parse_ota_image(f.read())
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 274, in parse_ota_image
return OTAImage.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 162, in deserialize
hdr, data = OTAImageHeader.deserialize(data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/zigpy/ota/image.py", line 112, in deserialize
raise ValueError(
ValueError: Wrong magic number for OTA Image: 168430090
For the people having issues, there’s a way to force an update, but it will have to be done via the wire harness method.
Not sure what’s happening but if you’re interested, we could loan you the wiring harness in good faith that you’ll return it and we can walk you through the update if you want?
What’s happening on Z2M is that the update completes, but then you have to manually pull the firmware version for Z2M to show the right number. If the same is happening in ZHA and it’s set to not only automatically update but also to force that update, it will just continue to loop.
By “manually pull” do you mean Dev Console > Endpoint 1 + Cluster genBasic + Attribute swBuildId > Read ?
I’ve tried that and its still showing 2.14 on two of my four switches
Correct, and then a re-configure to have the number update.
sWbuild will return the response in red which is reading the version directly from the switch itself. This should show 2.15
As mentioned by @ankushg, It is returning 2.14. I wonder if, since it’s apparently completing, if I should be writing 2.15?
re: the failing update of another device: thanks for catching that, I’ll have to look into it as well
I wouldn’t overwrite that value. On Z2M, reading this attribute returns 2.15 after the update is complete. So if it’s returning 2.14 I would say it’s likely correctly reporting 2.14. As for why that is after the logs clearly show it reaches 100% and reports completion, I have no idea.
I’d be willing to take a stab at it and see if that works, but I would definitely need to borrow the harness and instructions. I’m also not really in a hurry, as 2.14 has been working fine. It’s just a bit of a pain to have to move firmware files around and what not. I also have a spare switch, that I could swap in if it’s ever needed, or if having this one to dissect would be helpful?
Ok sounds good! I’ll defer to @EricM_Inovelli on the dissection of a switch, but thanks for the offer regardless 
Can you shoot us a PM when you’re ready and we can coordinate everything?
Edit: I can probably whip up some instructions too for our knowledge base so everyone can follow!
If you’re using Z2M you have to realize that the firmware update process is slightly different for Inovelli switches.
1.) Update OTA gets pushed to switch. (Green indicator goes up to 100%)
2.) Switch reboots for the first time, does CRC checks. (Reboot LED’s blink)
3.) Switch runs from bootloader, installs firmware. (Green indicator blinks at 1%)
4.) Switch reboots into application. (Reboot LED’s blink)
Until ALL of these have occurred you will see that the switch will return the previous SW version ID. This is normal, because the firmware wasn’t installed yet. I have yet to see a failure in updating any switches and I’ve updated 60 switches thus far, with even 25+ at the same time on the same network. No failures.
If a failure occurs, it would likely fail during file upload stage and since no changes occurred to the switch just yet, the switch is likely fine.
Make sure your switch load is turned OFF before starting firmware update. It seems they have a catchall in the firmware that auto-cancels the update if the load is pulling too much power. (ie. the light is ON)
That’s not a writable value anyway. It’s written by the embedded C code.
Very interesting observation. I wonder if such a simple thing could be causing the issues people are seeing here?
1 Like
A couple of my stubborn switches are controlling the load and they’ve been turned off during the update process, so that doesn’t seem to help unfortunately. Not a bad suggestion though.
Unfortunately, this is another thing I tried while troubleshooting, but didn’t know that unfortunately and didn’t think it was worth including.
My switch is connected to a single smart bulb, in smart bulb mode. I attempted it with that mode (and the load) off, as well as with the bulb removed from the socket entirely.
But, this is all good information that I was not aware of. Thanks!
Keep in mind that if you pull power to the switch while it’s running from bootloader or right after the first reboot, the firmware update will be cancelled or corrupted. If it was running from bootloader, it could likely get stuck in the bootloader and not boot up into application anymore. The only way to recover at that point is to pin flash the device. (CTAG, JTAG)