Problem upgrading Blue 2-1 firmware

Switches Firmware Discussion
, ,
#1

I got tired of waiting for the Blue 2-1 2.15 firmware to show up in ZHA’s update catalog (still no response to my question about it after several months, which is kinda weird), so I went ahead and manually downloaded it.

Like the last few firmware upgrades, it takes several tries before an update takes–I watched a switch show the blinking green progress bar, then flash red three times, then go through an update again with the progress bar, etc… It did eventually get upgraded though. But it’s been almost 40 hours, and 6 out of 15 switches have been upgraded to 2.15. Eight are on 2.14, and one is on 2.08.

And I watched another switch attempt to go through its upgrade, and it didn’t do the three red flashes. The LEDs flashed green for several minutes, then went off, then the connected load turned off, then the LEDs cycled green, blue, yellow (I think), then the load turned back on. However, it did not get upgraded (still on 2.14), and it’s now showing the flashing green progress bar again. Also, about two or three minutes after that, the connected lights flashed on and off rapidly (which I’ve seen during both successful and failed upgrades).

I’m on Home Assistant 2023.11.2, most switches are the original batch, some of which were in the bad OUI range, and I had to do the antenna fix on. Five are from the replacement batch–the one that’s still on 2.08 is definitely from that batch. I’m fine with 2.14, actually, but I do want that 2.08 to get upgraded. I don’t know whether the 2.08 one flashes red after failing to update.

Anyways, I was wondering exactly what the above LED patterns mean. I’m assuming red flashes means error, but what sort of error? (Switch got corrupt/incomplete firmware? Or firmware was OK, but it had problem flashing it? Or it could be either?) And what about green/blue/yellow? I was thinking that might mean success, although I haven’t watched a success flash to see what it looks like. But as mentioned, in this case, it wasn’t actually successful.

#2

I seem to be having a similar issue. I just installed around 15 blue 2-1 and fan switches this week. Yesterday I turned on Homeassistant’s ZHA built in OTA updater. Within a few hours, I noticed all the switches blinking green. They would do this for 15-20 minutes, then I noticed a few blink red and go back to normal color. I also noticed the load would flicker on occasion.

Looking in ZHA logs for one of the devices, it looks like every hour it is applying settings to various attributes. I’m assuming that’s part of the update process. I don’t see anything specific in the default ZHA logs that say it’s attempting or failed an update.

Here are the firmware versions reported in HA for the 2 different models -

VZM31-SN
Firmware: 0x01020200

VZM35-SN
Firmware: 0x02020104

Anyone know if this is an issue with ZHA’s OTA updater or the switches themselves?

#3

Can you confirm what version of HA you’re on? And when you say you turned on the OTA updater, could you clarify what you did? (ideally if you’ve got a screenshot of the config file, that’d help too)

The version you’re on for the VZM35-SN is the latest, but the VZM31-SNs will need to go from 2.00 to 2.15.

#4

I filed a support ticket for this since I hadn’t received a response from anyone here. But I’ll reply here with any updates in case it helps anyone else.

I am on HA 2024.1.

To turn on the OTA updater, I added a zha section to my configuration.yaml like so -

zha:
  zigpy_config:
    ota:
      otau_directory: /config/zigpy_ota
      inovelli_provider: false

I tried it without otau_directory and inovelli_provider: true, to pull updates directly from the internet first. That had the same effect. (Although it was only trying to pull down 2.08 since that seems to be the latest reported in that repo.)

I did find that manually triggering the update on a single switch seems to work, per the instructions here - ZHA Firmware Update Guide - #10 by jtbandes

However, the automatic attempts from HA continue to fail every time.

I’m wondering if ZHA is just trying to update too many at once, overwhelming the network? I did turn on debug logging and grabbed what I think are some relevant lines from one of the failures. Maybe someone who understands the protocol can decipher what is happening here -

2024-01-09 11:11:27.528 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame received incomingMessageHandler: [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=25, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_RETRY: 64>, groupId=0, sequence=214), 255, -75, 0xd235, 255, 255, b'\x11T\x06\x95/\x12\x01\x01\x0f\x02\x02\x01']
2024-01-09 11:11:27.528 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=25, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_RETRY: 64>, groupId=0, sequence=214), 255, -75, 0xd235, 255, 255, b'\x11T\x06\x95/\x12\x01\x01\x0f\x02\x02\x01']
2024-01-09 11:11:27.528 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 1, 9, 16, 11, 27, 528748, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xD235), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=214, profile_id=260, cluster_id=25, data=Serialized[b'\x11T\x06\x95/\x12\x01\x01\x0f\x02\x02\x01'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=255, rssi=-75)
2024-01-09 11:11:27.529 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] Received ZCL frame: b'\x11T\x06\x95/\x12\x01\x01\x0f\x02\x02\x01'
2024-01-09 11:11:27.529 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 0>, disable_default_response=1, reserved=0, *is_cluster=True, *is_general=False), tsn=84, command_id=6, *direction=<Direction.Server_to_Client: 0>)
2024-01-09 11:11:27.530 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] Decoded ZCL frame: Ota:upgrade_end(status=<Status.ABORT: 149>, manufacturer_code=4655, image_type=257, file_version=16908815)
2024-01-09 11:11:27.530 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] Received command 0x06 (TSN 84): upgrade_end(status=<Status.ABORT: 149>, manufacturer_code=4655, image_type=257, file_version=16908815)
2024-01-09 11:11:27.531 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] OTA upgrade_end handler for 'Inovelli VZM31-SN': status=Status.ABORT, manufacturer_id=4655, image_type=257, file_version=16908815
2024-01-09 11:11:27.532 DEBUG (MainThread) [zigpy.zcl] [0xD235: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=84, command_id=7, *direction=<Direction.Client_to_Server: 1>)
2024-01-09 11:11:27.532 DEBUG (MainThread) [zigpy.zcl] [0xD235:1:0x0019] Sending reply: upgrade_end_response(manufacturer_code=4655, image_type=257, file_version=16908815, current_time=0, upgrade_time=0)
2024-01-09 11:11:27.533 DEBUG (MainThread) [bellows.zigbee.application] Sending packet ZigbeePacket(timestamp=datetime.datetime(2024, 1, 9, 16, 11, 27, 533088, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xD235), dst_ep=1, source_route=None, extended_timeout=False, tsn=84, profile_id=260, cluster_id=25, data=Serialized[b'\x19T\x07/\x12\x01\x01\x0f\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00'], tx_options=<TransmitOptions.ACK: 1>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2024-01-09 11:11:27.533 DEBUG (MainThread) [zigpy.application] Max concurrency (8) reached, delaying request (94 enqueued)
#5

Perfect re the update info. I see what you’re saying, it does look like the 2.08 is still what’s listed via the firmware json file that ZHA points to. In that case going the manual route of just putting 2.15 in the zigpy_ota folder and kicking them off manually a couple at a time is probably the way to go.

It’s hard to tell specifically why those OTA upgrades are getting aborted without more detail/larger log snippets, but that’s definitely being ended before completing. I’d be curious if maybe it is just too many trying to go at once. ZHA will check 2x a day if I remember correctly, or if you manually kick it off using the cluster command or zha-toolkit as you shared.

#6

How many switches do you have, and do you have many other zigbee devices on your network? I struggled for a long time with failing firmware updates too. What eventually worked for me was to move the zigbee dongle physically closer to the switches, and pull out the air gap in all but one switch at a time while doing the firmware update so that there was less interference. I had thought more zigbee routers was supposed to make the network stronger, but I think it was hindering the firmware update process :anguished: Anyhow, with enough babysitting, I eventually got all of them upgraded.

(I also believe that there was some kind of timeout / retry limit in place which was causing the updates to be aborted. I think if there were a way to configure this, the update probably would’ve succeeded eventually because I always saw it make at least some progress before failing. But I was not aware of a way to adjust that, so the only option I found was to reduce interference.)

Also just wondering: does anyone else see their lights flicker horribly for about half a second the moment the firmware upgrade process starts? It’s quite jarring :grimacing:

#7

I was going to dig into this more, but this weekend I had 2 breakers off for a good amount of time. I’d say about half my zigbee switches are on those 2 breakers. Anyway, last night I checked HA and all of my switches are now on 2.15. Unfortunately, that means I can no longer debug the issue to find a proper resolution.

FWIW - I have 18 devices on our zigbee network. 13 VZM31, 4 VZM35, and one generic LED strip that shows as Light A11. I had manually upgraded a few of them, so there were like 10 switches trying to update at once each time it was triggered. I did try pulling the air gap on 5 of them once, then letting the other 5 attempt the update. But that still failed.

So yeah, I think it was too many devices trying to update at once just overwhelming the network. Then when I killed those breakers, it must have taken just enough of them offline to work. Probably would be worth it to request a configuration option in ZHA to set a limit for concurrent firmware updates. After all, I think we will all run into this with the next update again since our zigbee networks will be at least as complex, if not more, by that time.

And yes, @jtbandes, mine flicker during the update. Scared me to death the first time it happened, as I thought the switch was shorting out until I saw the green led.

#8

I’ve upgraded to Home Assistant 2024.3.3, and am still using ZHA. The new version now lets me pick a switch to upgrade the firmware on, rather than trying to do them all at once, bogging down the network. However, I’m still having the same problem that I originally had. That one 2.08 switch did eventually update successfully back in December, but it seems that the 8 that are on 2.14 are stuck and won’t upgrade to 2.15.

As before, the switch shows the blinking green progress bar. And with the new HA/ZHA, the web UI also shows a progress bar. After it reaches 100%, the switch LEDs stay off for a few seconds, then cycle cyan, blue, yellow. The switch remains on version 2.14. I’ve tried doing a factory reset (hold up and config buttons until the LEDs turn red) and re-adding the switch to HA, but that didn’t help.

I have two VZM35-SN switches that I was able to upgrade to 2.07 without any issues. It seems to just be these 8 VZM31-SNs that won’t flash :frowning: Am I gonna need a cable to flash them?