Blue Series 2-1 Firmware Changelog | VZM31-SN

Maybe check the ZHA Firmware Update Guide thread? Inovelli hasn’t made 2.15 available to ZHA yet (no idea why not); 2.08 is the latest available. So you have to manually download 2.15 to your /config/zigpy_ota directory, which that thread explains how to do.

1 Like

I did everything in that thread. No luck.

1 Like

You have a folder in this path “/config/zigpy_ota” with the 2.15 image in it?

If so, can you make sure zha has debug logging enabled (may want to restart again to make it easier to go through logs) and then run this via the developer tools -

service: zha.issue_zigbee_cluster_command
data:
  ieee: "6c:5c:b1:ff:fe:5d:f4:0d"
  endpoint_id: 1
  cluster_id: 25
  cluster_type: out
  command: 0
  command_type: client
  params:
    payload_type: 0x00
    query_jitter: 100
    manufacturer_code: 4655
    image_type: 257
    new_file_version: 16908815

If that doesn’t kick off the update, check the logs and share those here?

That kicked off the update! Thanks!

In the future, will I need to put new firmware in the /config/zigpy_ota folder? I thought the whole point of OTA is that ZHA would automatically download new firmware without me having to worry about it.

There are 2 pieces to OTA that you actually configured. The first (inovelli_provider: true) tells ZHA to look at the firmware-zha.json file that Inovelli has published and will remotely pull and automatically update your switches as new firmware is listed. Currently, Inovelli hasn’t updated that file with 2.15, which is why it won’t kick off an update. Note also, that leaving that parameter enabled means that you may randomly have switches update and lights turning off and back on as switches cycle, which may not be preferred?

The second piece (otau_directory: /config/zigpy_ota) tells ZHA that you have a directory locally that contains the firmware images you want to push to your devices. It’s still OTA (over the air) and not requiring you to connect up to pins on the device, etc, but it is more of a manual process. The upside there is that you also have more control around the timing and the firmware updates that you choose to push.

You really only need 1 of the 2 enabled in order to support OTA, and you can even disable both and just enable when you’re looking to do updates to help mitigate the first one auto-updating when it may not be convenient.

4 Likes

edit: This was all incorrect and a factory reset on 2.15 jogged another switch into working!

For visibility, because I do not know which thread is more appropriate:

I had an interesting side effect to flashing with the harness. I posted about it over in the enhancements/bugs thread, but will link to that here for visibility.

Short explanation: Light switches have never acted as routers (repeaters). Had to use the harness to update one out of seven switches. That switch now works as a router, with devices connecting through it, while the others do not.

I installed a Blue 2-1 from the original batch (not affected by the recall) yesterday. Everything went fine, but when I updated the firmware via hubitat it updated to 2.14. I didn’t realize 2.14 was even available anymore. I haven’t tried updating it again yet, but figured I would post here to see if anyone else had seen this.

I think Hubitat first checks your hub to see if you have a cached update file and updates to that version. If you update the same switch it should check the Hubitat firmware repository and see there is a version 2.15 and download that to your local hub cache. All updates after that should be to 2.15.

[/u]That worked. Thank you.

2 Likes

I was able to update 9 out of 10 installed switches from 2.14 to 2.15.
The stubborn one has been reset, removed from z2m, readded, air-gapped, and reset a bunch more times to force it into submission - yet no joy. It goes through the update process just fine but never shows 2.15 or the latest dateCode even after waiting and checking through the dev console. Needless to say, I have put it through the update process at least 5 times by now.

Not particularly sure what else to do at this point.

HA+Z2M+Sonoff ZBDongle-P.

1 Like

Having the update loop issue moving from 2.14 to 2.15 as well. Am willing to provide debug logs and perform troubleshooting if that is helpful. Using fully updated HA using SONOFF Zigbee 3.0 USB Dongle Plus-E Gateway.

The firmware downloads 100%, reports success, reboots, then downloads again. I have debug logging enabled. Here is the config:

logger:
  default: info
  logs:
    homeassistant.components.zha: debug
    zigpy: debug

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

Let me know if I can help figure this out for you all!

Edit: I have 3 blue series switches that I ordered right at launch. All of them have been updated with the newest firmware as soon as it was available. I initially tried updating a single switch, but eventually the other 2 switches picked up the new firmware and attempted to update. All 3 are in an update loop now. I sat and watched one through the entire process. It first starts flashing green with the progress bar. Then it reboots and flashes yellow. After a time it reboots again. Then after a couple minutes it starts updating itself again. I haven’t watched the other switches except via the debug logs, but I can do that if necessary.

Hi @EricM_Inovelli, any idea if/when 2.15 is going to be released for HA/ZHA (with inovelli_provider: true)?
Just trying to decide whether to wait or do the manual download. I’ve done manual before & it wasn’t hard. Conversely, 2.14’s working for me, so no urgent need to update.
Thanks

Anyone else have issue with Z2M after rebooting HA? Recently, Home Assistant is showing “Unavailable” for most of the switches after a reboot of HA. Stays like that forever.

Then if I restart Z2M itself, most everything shows as “Unknown” and eventually updates. Some devices still show “Unavailable”, and the only way to fix them is to change the name in Z2M + HA, and then change the name back again.

Since Z2M and MQTT seem to be working fine, no errors in logs I would guess it’s an HA problem. Just curious if anyone else has started to see this issue.

I see something very similar. Whenever I update HA, all z2m attached devices show as offline in HA. My z2m/MQTT run on separate hardware from my HA box, and the z2m interface shows all is fine. If I then restart z2m, all devices are again available in HA. Started a couple of months ago, and ive seen this happen on every single HA update since.

It happens on every HA reboot to me, not just every HA update.
Seems HA is broken or the startup order is the problem.

Mine may be the same… hard to say. The only time I reboot HA is when I update it.

It is a problem with the MQTT Broker Add-on in HA.
It only occurs with over 2000+ MQTT entities.
Not sure when it will be fixed. 2 versions ago it was working fine.

Do you happen to have a link to the bug for the MQTT addon for HA? Would love to see what has been filed for this and if it is an accepted bug.

Yes, messages are no longer retained with 2.0.16 (or 2.0.17) · Issue #2887 · eclipse/mosquitto · GitHub

That is the MQTT release. HA follows the MQTT release with their own release of the add-on.
HA should post an update that regresses the MQTT core back to the older version prior to the problems. They won’t take ownership of it, and the MQTT GitHub staff are aware of the problem but haven’t started looking into it yet. Likely won’t happen till next year.

2 Likes

Ah perfect, thank you. I run mosquitto and zigbee2mqtt in their own docker project and can just force mosquitto to run at 2.0.15 to remove the issue. Thank you so much for the link to the bug before I got deep into my Zigbee network at the new house. I should exceed that number and it would have been a big issue for me.