VZM31-SN Firmware upgrade failures going from 2.18 to 3.04

Product Support Hardware & Firmware Help
, , ,
1

Two out of 10 of my Blue Smart Dimmers are failing when trying to upgrade in similar but different ways. I’m running ZHA and the common log errors after the 100% of the firmware is downloaded:

2026-02-05 23:28:57.590 DEBUG (MainThread) [zigpy.zcl] [0x93EF:1:0xfc57] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x1D>(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=1, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4631, tsn=79, command_id=1, *direction=<Direction.Server_to_Client: 1>)2026-02-05 23:28:57.590 DEBUG (MainThread) [zigpy.zcl] [0x93EF:1:0xfc57] Unknown cluster command 1 ‘07 17 12 00’2026-02-05 23:28:57.590 DEBUG (MainThread) [zigpy.listeners] Matcher checkin() and command ZCLHeader(frame_control=FrameControl<0x1D>(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=1, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4631, tsn=79, command_id=1, *direction=<Direction.Server_to_Client: 1>) b’\x07\x17\x12\x00’ are incompatibleTraceback (most recent call last):File “/usr/local/lib/python3.13/logging/handlers.py”, line 1509, in emitself.enqueue(self.prepare(record))~~~~~~~~~~~~^^^^^^^^

………..

The other throws this error before throwing the above “Unknown cluster command 1” error:

2026-02-06 00:09:36.593 DEBUG (MainThread) [zigpy.zcl] [0x4BE7:1:0x0019] Sending reply header: ZCLHeader(frame_control=FrameControl<0x19>(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=112, command_id=7, *direction=<Direction.Server_to_Client: 1>)
2026-02-06 00:09:36.594 DEBUG (MainThread) [zigpy.zcl] [0x4BE7:1:0x0019] Sending reply: upgrade_end_response(manufacturer_code=4655, image_type=257, file_version=16909060, current_time=0, upgrade_time=0)
--- Logging error ---
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/logging/handlers.py", line 1509, in emit
    self.enqueue(self.prepare(record))
                 ~~~~~~~~~~~~^^^^^^^^
  File "/usr/local/lib/python3.13/logging/handlers.py", line 1491, in prepare
    msg = self.format(record)
  File "/usr/local/lib/python3.13/logging/__init__.py", line 999, in format
    return fmt.format(record)
           ~~~~~~~~~~^^^^^^^^
  File "/usr/local/lib/python3.13/logging/__init__.py", line 712, in format
    record.message = record.getMessage()
                     ~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/logging/__init__.py", line 400, in getMessage
    msg = msg % self.args
          ~~~~^~~~~~~~~~~
  File "/usr/local/lib/python3.13/site-packages/zigpy/types/struct.py", line 387, in __repr__
    for f, v in self.assigned_fields():
                ~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/zigpy/types/struct.py", line 194, in assigned_fields
    if field.requires is not None and not field.requires(self):
                                          ~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/site-packages/zigpy/zcl/clusters/general.py", line 1929, in <lambda>
    lambda s: s.field_control
              ~~~~~~~~~~~~~~~
    & QueryNextImageCommandFieldControl.HardwareVersion
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TypeError: unsupported operand type(s) for &: 'NoneType' and 'QueryNextImageCommandFieldControl'
Call stack:
2026-02-06 00:09:36.740 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2026, 2, 6, 6, 9, 36, 740872, tzinfo=datetime.timezone.utc), priority=None, src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x4BE7), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=0, profile_id=260, cluster_id=64599, data=Serialized[b'\x1d\x17\x12q\x01\x07\x17\x12\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=200, rssi=-50)
2026-02-06 00:09:36.742 DEBUG (MainThread) [zigpy.zcl] [0x4BE7:1:0xfc57] Received ZCL frame: '1d 17 12 71 01 07 17 12 00'
  File "<frozen runpy>", line 198, in _run_module_as_main
2026-02-06 00:09:36.742 DEBUG (MainThread) [zigpy.zcl] [0x4BE7:1:0xfc57] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x1D>(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=1, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4631, tsn=113, command_id=1, *direction=<Direction.Server_to_Client: 1>)
  File "<frozen runpy>", line 88, in _run_code
  File "/usr/src/homeassistant/homeassistant/__main__.py", line 229, in <module>
    sys.exit(main())

I’ve tried factory reset, air gap and removing from ZHA & then adding back. I do see in the zigpy logs that it is stating it had previously looked up the latest firmware so it is using a cached response.

One is a one-way and the other is part of 3-way with its partner successfully updated to 3.04. I’m at a lost on how to move further.

VZM31-SN Firmware Issue
2

Same issue here. 2 of the 3 that I’ve tried have the error.

3

Oof! I’m not alone but no good because from the errors, I’m not seeing a way to resolve it. The Unknown command seems to be the killer Maybe its related to the hardware of our problem dimmers? Hopefully Inovelli can help us out. Maybe we can save other the pain. Turn on ZHA debug logging before resetting, air gaping, cutting power and hopelessly keep trying.

4

See:

2 Likes
5

Definitely 4. Rare Issue With Early VZM31-SN Production Batches issue for mine two. It states contact Support but no link or email address. Any clue on how to contact support?

Thanks

6

[email protected]

1 Like
7

Same problem. None of my VZM31-SN’s will update. They just reboot back to the same version. I deployed one out of a box that had 2.08, and it kept staying on 2.08. I manually upgraded to 2.18 and it worked fine, but now it’s stuck on 2.18. Any ideas?

8

Not rare. Not a single one of mine will update to 3.XX release.

9

It’s related to the locked bootloader.

10

Chiming in: nearly all of mine are failing to update. The couple switches I bought later worked okay after a couple tries, but the ones I pre-ordered at initial release fail, sometimes throwing an “ABORT” error after ~70% (I’m not watching every exact %). Most are on 2.18, a couple were stuck on 2.15 and I haven’t had time to pull them yet.

Really frustrating how many firmware update issues I’ve had with these switches.

12

I also saw the ABORT message pop up on several of my switches. Turned out it was combo of the firmware and the Zigbee2MQTT OTA settings that I had. I updated the firmware on my Zigbee radio and it solved the ABORT issue but I also have the issue with the early production releases.

13

Same here, all of my switches, half with the resistor shunt “fix” and half are replaced models are on 2.18 and cannot be upgraded to 3.04.

14

Mine claim to update but then a day later they’re all showing the old version again and showing up as needing to update (z2m).

15

Mine claim to update but then a day later they’re all showing the old version again and showing up as needing to update (z2m).

I am seeing this behavior as well. Only a small handful of my switches have actually updated and stayed that way. Some still won’t even reach 100%, despite updating my sonoff dongle’s firmware (-P)

16

I’ve got about 5/50 that seem to be stuck on 2.18. Haven’t had a chance to sit and dig into what’s failing

17

I think I have 40 switches with this issue. Mine claim to update but then a day later they’re all showing the old version again and showing up as needing to update (z2m). The App and Build number show the new number when the update completes. But the Firmware version stays the same. Then later, it goes back to the old App and Build, and offers to update again. I just emailed support. I was part of the very first production batches in 2022. I ordered May 2022.

I appear to be stuck on updates from 2.18 to 3.04 for all of my switches. All switches are on 2.18, when I tried to update about 10+ so far, have this issue on all of them. I am using home assistant and only updated to 2.18 in the last 30 days. So it was a bit of a surprise to see a new firmware so soon.

https://help.inovelli.com/en/articles/13566202-blue-series-switch-troubleshooting-ota-over-the-air-updates

What do I need to do to update these switches to 3.04?

What ever happened to the matter update that was suggested by Erick in 2022?

I was part of the very first production batches in 2022. I ordered May 2022.

Order #19632 && Order #18731
Blue Series Smart 2-1 Switch (10pk)
VZM31-SN-10
Expected release date is Jul 15th 2022
$400.00 USD

18

I have the same behavior on my 2022 ~20 switches. I had some put aside with 2.08 firmware, and I can confirm 2.08 to 3.04 doesn’t work too, but 2.08 to 2.18 with a manually selected .ota file via Z2M update works just fine. So looks like it is something in 3.04, as an update to 2.18 is working.

2 Likes
19

From what I can see it’s due to 3.04 trying to modify the bootloader. Early switches were locked from factory. Using a debugger with the 5-pin debug connector, you can flash the bootloader and application which will unlock the bootloader. Flashing to 3.04 then works fine. It appears to be a permanent fix as the bootloader will remain unlocked unless you lock it manually.

This is not a bug, it’s working as these standards were designed. The problem is that early switches had a locked bootloader from the manufacturer.

Now I could be wrong about this, but in my testing I manually locked the bootloader then tried to upgrade to 3.04 and it failed. Reflashed bootloader & application with unlocked bootloader and was able to flash to 3.04.

1 Like
20

Is there a procedure published for updating over the debug connector?

21

[email protected] will help you. The procedure is intentionally not linked publicly at Inovelli’s request.

1 Like