It looks like someone decided to change the tool that auto dls to grab them from github instead: Discover Inovelli firmware on GitHub by JamieMagee · Pull Request #1304 · Koenkk/zigbee-OTA · GitHub I would suggest that we get this reverted.
Is there a changelog available for 3.07? I’m curious if it has the fix for “improving the responsiveness of button presses”.
Wondering where I can get the hex or bin FW files. I just received the Jlink flasher and do not see them on Github.
Hey all, I managed to download this firmware (3.07 20260325) on 3 of my switches before it seems like it was delisted. Can someone advise me on reverting? Is it as simple as downloading this OTA from Github, and then in Z2M, selecting the switch, changing source to “Custom Firmware” and checking “downgrade,” and selecting that file?
The only downgrade path is through a USB programmer. I would continue to use 3.07 on the 3 switches and let us know if you discover any issues.
@fonzi03 the instructions with the files should have been given to you with the flasher. Please check the ticket or the PM where you shared your address. Or you can PM me if you can’t find them and I will share them with you.
I didn’t intentionally join the beta, but I don’t mind. I had no issues before 3.07, and I’ve had none since on 5 VZM31-SNs. I’m perfectly happy keeping 3.07 until something else gets marked as current.
I notice that my Blue switches on 0x01020212 accept notifications that are under 3 seconds in length, while switches on 3.04 simply DO NOT respond at all when I send a short notification.
Is that the reason for the update with “Fixed LED notification behavior that did not operate as expected.”?
Hi @inventor7777, for the VZM31-SN that issue is resolved in 3.08 but that version has not been released for beta testing yet. PM me if you are still interested or keep an eye on this thread for when it gets announced.
I have 60+ blue series switches and since updating to 3.04 every day about 3 of these switches become unresponsive and need their airgap pulled to reset them. Is this a known issue and has it been fixed?
Weirdly my ~30 switches (across Dimmer, mmWave, Fan, and On/Off) have also been frequently going unavailable recently—after almost a year of stability. But I suspect it might be network congestion? Could that be the case for you?
I have also had about 1.5 years of stability so this is new. Not sure if it’s network congestion, is there a tool in homeassistant to check?
Just as an anecdotal data point, but my network is pretty dang stable with 295 devices (73 Inovelli switches, 184 Philips Hue, and a smattering of others). I did disable energy reporting on all my Inovellis in order to reduce traffic, and I make aggressive use of groups and direct binding to said groups to further reduce individual messages – especially ones flowing through the coordinator.
I’m seeing the similar connectivity losses recently as well, and wanted to add data in case it helps @EricM_Inovelli narrow it down.
Setup:
- VZM31-SN on 3.04 (0x01020304), neutral wiring, mostly dimmer mode, mostly not smart bulb mode
- I keep my HA and ZHA very up to date (currently Home Assistant 2026.10 with zha 2.3.0), though I’ve been seeing this for a few weeks now.
- Nabu Casa ZBT-2 coordinator on channel 15
- Power/energy reporting at defaults (P18/P19 = 10, P20 = 3600)
Symptom:
- Several switches a day go “unavailable” in ZHA. Earlier today 6 were offline at once.
- The paddle and load keep working locally. Only the Zigbee side stops.
- Pulling the air gap brings the switch right back. It rejoins on its own with no re-pairing, so it’s not leaving the network. The Zigbee stack seems to hang.
What I’ve ruled out:
- RF/mesh: the hung switch had the coordinator as a direct neighbor at LQI 168 and ~14 neighbor routers. Another switch on 3.04 with an identical config, a few inches away (LQI 255 between them), stayed up.
- Firmware mismatch: the hung and working switches report the same version.
- Non-neutral: both report power type = neutral.
I have ZHA diagnostics from a hung switch and a working one and the same box and can share them. I’m also going to begin logging drop times to look for a pattern.
Is this a known issue on 3.04, and does 3.07 or 3.08 address it? I’d be happy to beta test on a few of the worst offenders.
Perfect, I have the same issue across all switches (blue series, latest version, 3.04). Seems to be a common issue now considering similar forums started to show up with similar issues.
Thanks everyone for the reports. We are currently investigating the issue. As far as I can tell it looks like a recent change to ZHA may be causing it, but we don’t have the root cause yet. I looked to see if there are similar cases that have popped up and I think this is a good guess:
I’m checking with our engineers to see if something similar could be happening with our device(s). Since the workaround is fairly simple, I created a patch that anyone can use as a test. I will have to write up a how to, but some of you guys are very talented and might know how to apply it. It just runs inside of the Home Assistant terminal:
inov.li/IRbxhx1646F/patch_inovelli_keepalive.py
You first run it with a check:
python3 patch_inovelli_keepalive.py --check
Then, run it without the check:
python3 patch_inovelli_keepalive.py
Then restart Home Assistant. We will keep digging but I think this is a good lead.
I installed the python script and so far it’s been running, but I will provide another update in the next few days
Unfortunately light switches are unavailable again ![]()
Can you confirm a few things for me?
- It is the VZM31-SN that is becoming unavailable?
- You restarted Home Assistant after applying the patch?
- If you try to run the patch again it should say something like “The patch is already applied”?
-
It is VZM31-SN and Firmware Version 0x01020304
-
Yes, after patch was installed, HA was restarted. BTW. I am using the latest HA Version
-
run the command and got back Already patched: /usr/local/lib/python3.14/site-packages/zhaquirks/inovelli/VZM31SN.py
Let me know if that helps