Blue Series mmWave Firmware Changelog | VZM32-SN

EricM_Inovelli · January 27, 2026, 10:08pm

January 21, 2026 / v1.01 / 0x01030101

Beta Testing Available On Request

Changes:

Return to the “Previous Level” when the switch ramps to OFF (from presence timeout)
Fixed an issue where the OnOff Cluster OnWithTimedOff command was not working
Fixed an issue where meter energy continued to increase even when the load was set to OFF
Fixed an issue where the switch would stop functioning when P17 (Load Level Indicator) was not set to 11
Optimized the temperature acquisition algorithm and fixed cases where temperature was not reported correctly
Fixed an issue where LED notifications did not function as expected (could not be cleared by setting effect = 255)
Fixed an issue where the LED strip display of the mmWave module was incorrect in the auto-generated interference area

kevin_wilcox · February 8, 2026, 6:55pm

Wondering if maybe you could send this update to Hubitat? The LED notifications fix may be related to a problem I had. Also, does this switch have the update for low temperature reporting that was fixed in VZM31 v3.04? I’d like to put one of these in my garage.

dikartashev · February 8, 2026, 9:13pm

I believe this upgrade broke something for me. I’m on HA ZHA, and had automations attached to single and double taps, which stopped working last week. I can still control the switch from HA though, so the connection is fine.

EricM_Inovelli · February 9, 2026, 10:07pm

I did send it to Hubitat last week, but I haven’t heard back from them yet. I will update this thread once I do.

@dikartashev can you try to hit the “reconfigure” button in the device page. Maybe the binding for the double tap got messed up.

dak · February 9, 2026, 11:25pm

New owner of Inovelli blue series mmWave here, your documentation is a little lacking in the firmware update department, or at least difficult to navigate. Is it still correct that firmware updates are impossible with these devices connected to SmartThings hubs? Trying to decide if I need to buy a Hubitat or something else. They’re working great with SmartThings so I haven’t felt the need to change hubs.

dikartashev · February 10, 2026, 12:06am

Alas, no. Here’s an example config I set up just to debug this. Same setup worked a week or two ago, after I initially installed the switch. I also installed the ZHA quirk (wasn’t initially needed, didn’t help now).

alias: Dimmer debug
description: ""
triggers:
  - device_id: 182689c173a03f0bc5e5b16d09dd1640
    domain: zha
    type: remote_button_triple_press
    subtype: Down
    trigger: device
conditions: []
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: Light debug
mode: single

brassardv · February 10, 2026, 12:07am

As a dedicated SmartThings user, let me share the method I use for firmware updates. I run a vanilla Home Assistant instance virtualized in VirtualBox on my Windows laptop. I’ve added a Thread/Z-Wave dongle that I re‑flash whenever needed. When I have a one‑off need to update a device’s firmware, I start Home Assistant and temporarily add the device to HA if it’s Matter, or disconnect and reconnect it to HA if it’s Zigbee. This lets me perform firmware updates only when they’re truly necessary. I then remove the device from HA and rejoin it to SmartThings. This approach is also inexpensive — the only real cost is the dongle (sonoff mg24), which is about $50. Once the update is done, I shut down the virtual machine and unplug the dongle.

Bry · February 10, 2026, 1:21am

Yes. To determine if a device’s firmware in SmartThings, open the device page, 3-dot menu, Information. You will see one of two things under the device name. Either “The latest version is installed” or a prompt to update firmware. If you don’t see either of those, ST does not support an OTA upgrade.

I temporarily move devices into Hubitat to upgrade them. Quick and painless.

lyle · February 10, 2026, 11:10pm

I believe there is a issue with the firmware beta.

In Home assistant (ZigBee2MQTT), if you set the stay areas (in my case Area 1), and apply them, under STAY AREA, go back in and it swaps the Width min and Width max numbers. Changed 3 times, and it swaps the numbers when you go back in to the settings page. I cleared the stay areas, and tried again, same thing happens. I am unsure if the original 1.00 does this, as all the mmWave are running the beta.

It did fix the switch not working after changing the “LoadLevelIndicatorTimeout” from 1.00 however.

EricM_Inovelli · February 11, 2026, 12:20am

Is it possible that this is related to the new converter @rohan?

rohan · February 11, 2026, 3:03am

I tested it on a switch with the factory firmware (1.00) and I’m not able to reproduce this behavior. I have not tried the beta firmware yet, but I can upgrade a test switch and see what happens.’

To test this, I did the following:

I set the min to -123 and the max to +123 for the width in stay area 1.
I then clicked apply
I then clicked reconfigure on the same switch to request values for all of the parameters
I confirmed that the min was still -123 and the max was +123 for the width in stay area 1.

rohan · February 11, 2026, 4:51am

I just tested on a switch running 1.01 and was still not able to reproduce this problem.

lyle · February 11, 2026, 10:14pm

Odd.

Notice my stay settings below when I set them, and afterwards hit “APPLY” to save.

After applied, I go out all the way, back to ZIGBEE2MQTT, then back into the switch (Exposes), and they have swapped.

I checked to make sure my browser cache was empty, but yep.. Keeps switching

UPDATE: I tried your way, and clicking reconfigure AFTER I go out to get values.

Same thing happened, with swapped values between width min and max.

Tried different browser just in case of Safari, and used Firefox. Same thing.

Lyle

eliahu · February 12, 2026, 4:43pm

Are there instructions for triggering the firmware update in ZHA?

When I pull the attribute for sw_build_id, I get “1”.

I have the custom quirk installed.

No indication there are firmware updates available.

dikartashev · February 13, 2026, 8:13pm

Looks like it was actually this problem: After 2026.02 update ZHA not always pass zhe_event to automation engine · Issue #162482 · home-assistant/core · GitHub

rohan · February 14, 2026, 9:44pm

I confirm that I can see this happening with the specific values that you provided but it does not happen with the values that I was testing it with.

@EricM_Inovelli I don’t believe this is a bug in the converter since the same conversion logic is used for the stay, detection and interference areas and this problem only seems to occur for stay areas. I believe this a firmware bug that exists in both 1.0 and the current beta.

lyle · February 14, 2026, 10:02pm

Thank you for your time spent in confirming Rohan, I appreciate it, and all the work you guys do.

Lyle

morphd · February 15, 2026, 3:44pm

I’m having a similar issue where my automation triggered based upon the zha_events button_1_press command filtering on cluster 64561. What’s interesting is one of my switches is still passing this (thought not always) and another one of my switches isn’t passing anything via cluster 64561 at all - just cluster 6 and 8.

cluster_id: 64561
command: button_1_press

stefan814 · February 20, 2026, 1:23am

Also having issues with this update. Using Z2M and the update pushes, downloads but doesn’t “stick" - Z2M asks for the same device to be updated just a few moments later.