Red Series VZW31-SN Disconnect Every Few Days

Product Support
, , ,
1

Hi, I’m having issues still with our VZW31-SN Red Series Switches. There are about 35 switches. They will work fine for 3-5 days, then suddenly one or two switches (seems to be random) will show as disconnected (Dead) in Home Assistant/zwave JS UI and in turn I notice zwave automations have not run because they are stopping at this particular switch.

Annoying workaround: If I go to the switch an push a button on it, it seems to wake it up, and it will resume connection to HomeAssistant/zwave.

I have a Aeotec Zwave Z-Stick 7. Recently I updated the Z-Stick 7 firmware to V7.21.6 in hopes this would improve but the issue still occurs. The firmware on the VZW31-SN is 1.02. I see there is beta version 1.04 available but I’m hesitant to test that.

2

Do you have other devices in the Z-Wave mesh or is it only VZW31s? The reason I ask is that there’s a known firmware issue with 700 series Z-Wave adapters where they have a bunch of mesh stability issues. I think upgrading to 800 series is the only way to fix that if that’s the problem you are running into. And if you do do that, the Nabu Casa made ZWA-2 adapter works exceptionally well.

3

Ok. I didn’t realize there were ongoing issues with the 700 series z-wave adapters. Yes. I do have a variety of z-wave devices on the network. Like zooz power switches, locks, etc… Thank you for pointing that out. I could try ordering the Nabu Casa made ZWA-2 adapter although not sure if I can get it in Canada.

4

Are you only seeing problems with the Inovelli devices? And all of the other ones are fine? Any other 800 series devices on your network?

5

Yes. Only problems with VZW31-SN. Other devices have not had issues with connection. I don’t think I have any 800 series devices. Just 700 series or older. I just ordered the Nabu Casa made ZWA-2 adapter so hopefully that works. I’m also upgrading the firmware to 1.04 beta to see if that helps.

6

Fingers crossed that it fixes it for you. I’ve personally not had any issues since switching to the Nabu Casa adapter myself. Though I used to have issues with all sorts of devices freezing up like you described, not just the Inovelli ones.

7

Unfortunately after upgrading to the Nabu Casa made ZWA-2 adapter the issue persists. Also upgrading to the 1.04 beta firmware did not help.

8

@EricM_Inovelli might have to look at this.

9

If you can test fw 1.04 that would be great. We have updated the SDK on that version and that was one of the bug fixes.

Related, did you change any of the energy and reporting settings on the switches?

10

I have been running 1.04 FW for about 2 weeks now and the issue has happened again.

The energy and power and reporting settings are the default.

11

Here is what it looks like when it occurs in zwave js UI. It just shows “Dead”. Then if I go just press a button on the inovelli switch, it starts responding to ping in zwave JS ui. It definitely seems like a inovelli bug because I don’t have issues with other zwave devices disconnecting ever.

image
image2193×407 30.6 KB

Here are the logs from controller around time it seems to have gone into Dead state:

2025-12-17 16:24:24.968 INFO Z-WAVE: [Node 043] Value updated: 50-0-value-65537 39.44 => 39.44

2025-12-17 16:24:32.280 CNTRLR   [Node 043] failed to decode the message, retrying with SPAN extension...

2025-12-17 16:24:32.442 DRIVER   Dropping message with invalid payload

2025-12-17 16:24:42.339 INFO APP: ::ffff:127.0.0.1 GET /health/zwave 301 162 - 0.384 ms

2025-12-17 16:24:44.394 INFO Z-WAVE: [Node 010] Metadata updated: 50-0-value-66049

2025-12-17 16:24:44.394 INFO Z-WAVE: [Node 010] Value updated: 50-0-value-66049 2.3 => 2.9

2025-12-17 16:24:48.181 CNTRLR   [Node 002] The node did not respond after 3 attempts, it is presumed dead

2025-12-17 16:24:48.181 CNTRLR   [Node 002] The node is now dead.

2025-12-17 16:24:48.182 INFO Z-WAVE: [Node 002] Is now dead

2025-12-17 16:24:48.184 ERROR Z-WAVE-SERVER: The node did not acknowledge the command (ZW0204)

ZWaveError: The node did not acknowledge the command (ZW0204)

    at Driver.sendMessage (file:///opt/node_modules/zwave-js/src/lib/driver/Driver.ts:7174:23)

    at Driver.sendCommandInternal (file:///opt/node_modules/zwave-js/src/lib/driver/Driver.ts:7370:28)

    at Driver.sendSupervisedCommand (file:///opt/node_modules/zwave-js/src/lib/driver/Driver.ts:7416:27)

    at Driver.sendCommand (file:///opt/node_modules/zwave-js/src/lib/driver/Driver.ts:7471:30)

    at Proxy.set (file:///opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:757:20)

    at Proxy.set (file:///opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC._validateArgs.ts:38:30)

    at Proxy.<anonymous> (file:///opt/node_modules/@zwave-js/cc/src/cc/ConfigurationCC.ts:512:30)

    at ZWaveNode.setValue (file:///opt/node_modules/zwave-js/src/lib/node/Node.ts:562:39)

    at NodeMessageHandler.handle (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/node/message_handler.js:23:43)

    at Client.receiveMessage (file:///opt/node_modules/@zwave-js/server/dist-esm/lib/server.js:134:100)

2025-12-17 16:24:48.429 INFO Z-WAVE: [Node 003] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:48.670 INFO Z-WAVE: [Node 005] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:48.914 INFO Z-WAVE: [Node 006] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:49.159 INFO Z-WAVE: [Node 007] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:49.400 INFO Z-WAVE: [Node 021] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:49.647 INFO Z-WAVE: [Node 019] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:49.889 INFO Z-WAVE: [Node 018] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:50.131 INFO Z-WAVE: [Node 020] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:50.379 INFO Z-WAVE: [Node 012] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:50.627 INFO Z-WAVE: [Node 013] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:50.961 INFO Z-WAVE: [Node 038] Value updated: 112-0-13 80 => 35

2025-12-17 16:24:51.205 INFO Z-WAVE: [Node 008] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:51.448 INFO Z-WAVE: [Node 011] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:51.780 INFO Z-WAVE: [Node 015] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:52.172 INFO Z-WAVE: [Node 014] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:52.414 INFO Z-WAVE: [Node 009] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:52.662 INFO Z-WAVE: [Node 010] Value updated: 112-0-14 80 => 35

2025-12-17 16:24:52.907 INFO Z-WAVE: [Node 017] Value updated: 112-0-14 80 => 35

Then after I press the switch it comes back online with this:
2025-12-17 20:36:14.569 INFO Z-WAVE: [Node 002] Has returned from the dead

12

Help! I have exactly this same problem!

I have 31 VZW31-SN that all have good signal. All have neutral. A few have Aux Switches. Running Home Assistant via Z-Wave-JS-UI. VZW31-SN dimmers will randomly go dead and then recover only after physically pressing the paddle. I also switched to the ZWA-2 (which improved signal), and upgraded to the 1.4 firmware. I’ve turned off all energy reporting, and moved all of the switches to Long Range.

I have other devices on the network: Honeywell T6 Pro thermostats, Decora ZW15S and ZW15HD, Minoston MR40Z, Zooz Zen37 and Zen14 and ZSE50. Everything is very reliable except the Inovellis.

I also find that large Home Assistant scenes can be unreliable on the Inovellis. For example turning off all of the Inovellis in the house doesn’t always turn all of them off. I can work around that by staggering the commands instead of using HA scenes, but as a ZWave newbie I’ve been surprised about how limited ZWave seems to be.

I like the look of the Inovellis enough that I’m thinking of switching to the Zigbee version if this can’t be sorted, but feeling pretty bummed about the time and $$ investment I’ve already made on these things.

Happy to help someone diagnose the issue if it will save me replacing all the dimmers!

13

Mine seems to be working now. I’ve been running for about 3 weeks with no disconnects so it finally seems rock solid. Inovelli support helped me. Here is what I did:

  • Removed all switches with zwave exclusion
  • Re-added all switches using Zwave Long Range using the Smart Start provisioning in Zwave JS UI.
  • After moving to Zwave LR I had to move the zwave antenna so it had more direct line of sight to my shop/garage as it is about 120 feet away. In the past I also moved it to middle floor where before it was in basement. This largely improved connection especially to top floor and reduce the amount of random dead switches

I know what you mean about scenes. I find they work ok but has to be like 6 lights or less. I think otherwise the controllers get instantly to congested, and that seemed to be leading to switches going into dead status on the controller. For doing any thing with the switches in large batches (like 6 or more lights), I use automations with added a delay between actions for about 200 or 500 ms. So for example to dim all lights at sunset or turn off all 35 lights in the house I use an automation template that loops through with a delay. I’ll share example below. I also have an automation that pings all Inovelli switches on a random interval (below). This was recommended by support although I think it was switching to Long Range that really made the different in the disconnect issue.

In general it’s been somewhat frustrating and buggy using zwave over the past 5 years. I’m curious of the thread/matter stuff is more reliable and less buggy to configure. Although after spending all this money on zwave I feel I am committed and hoping it continues being supported.

alias: Inovelli - Ping Nodes
description: ""
triggers:
  - trigger: time_pattern
    minutes: /30
conditions: []
actions:
  - delay:
      minutes: "{{ range(1, 31) | random }}"
  - repeat:
      count: "{{ lights | count }}"
      sequence:
        - variables:
            light: light.{{ lights[repeat.index - 1 ] }}
        - action: zwave_js.refresh_value
          metadata: {}
          target:
            entity_id: "{{ light }}"
          data:
            refresh_all_values: false
        - delay:
            hours: 0
            minutes: 0
            seconds: 1
            milliseconds: 0
mode: queued
variables:
  lights:
    - kitchen_ceiling
    - kitchen_pendant
    - kitchen_pots
    - kitchen_table
    - kitchen_tracks
    - and the list goes on....

alias: Lights - Turn All Off
description: ""
triggers: []
conditions: []
actions:
  - repeat:
      count: "{{ lights | count }}"
      sequence:
        - variables:
            light: light.{{ lights[repeat.index - 1 ] }}
        - choose:
            - conditions:
                - condition: template
                  value_template: |
                    {{ is_state(light, 'on') }}
              sequence:
                - target:
                    entity_id: "{{ light }}"
                  action: light.turn_off
                - delay:
                    hours: 0
                    minutes: 0
                    seconds: 0
                    milliseconds: 200
mode: single
variables:
  lights:
    - kitchen_ceiling
    - kitchen_pendant
    - kitchen_pots
    - kitchen_table
    - kitchen_tracks
    - and the list goes on....
14

Have you tried Z-Wave multicast for those types of broad commands? You should be able to use those for things like turning off all switches with a single network command that should not cause delays. I use it like this to enable and disable all of my Ring glass break sensors when the alarm is armed for example.

15

I have tried zwave multicast in the past and only lead to more problems and disconnects/dead lights. It’s possible maybe now it works better in newer versions.