"Dead" Dimmer/Switch? (in ZWave-JS)


We have a second home that has Inovelli switches/dimmers throughout, and the last time I was at the home everything was working correctly (including 3-way, etc).

When I got back into town, a few switches/dimmers weren’t working (I’m using HA w/ Zwave-JS).

This biggest issue is the dining room dimmers are not working at all (3-way and neither dimmer turns on the light).

I loaded up the z-wave-js console and it looks like the secondary dimmer is “dead”. I should add that the light bar on the dimmers do work, so they are showing some type of responsiveness

So a couple of questions:

  1. At this point, I’m not sure what to do. Do I re-interview the node and set things back up again? I noticed other options like “Heal” and “Failed Nodes”.
  2. What could have caused this? Is this going to be a recurring issue (my wife is already on my case about this).
  3. I also have some nodes whose status is “Unknown”…I’m not sure what this means. Any context would be helpful.


Rarely after not being used for a long period, mine would freeze too. A few recommendations:

  1. There is a small tab on the bottom that can be pulled out to “air gap” the switch. Try pulling that and turning the lights on/off. It should start reporting and get back into “Alive” state.

  2. Update the firmware on all of your devices. Choose either the latest and greatest (1.57/1.44) or latest stable (1.48/1.4?) from files.inovelli.com/firmware

  3. Heal your z-wave network once completed. This will get each device to find it’s most reliable path back to the hub. Sometimes adding a device and it not finding the best path can get the z-wave network confused.

  4. Check the z-wave JS logs. See if a specific device is “flooding” the network with log entries. Make sure you are watching on “silly” log level.

Edit: If they show as the proper device, then no need to re-interview UNLESS you update the firmware. As they add new features these become available via configuration once a new firmware version is detected.

Thanks for the tips.

#1 helps a lot and the “Dead nodes” are no longer dead and seem to be working (some of the 3-ways are wonky and cycle the lights on/off on press, so I have to debug that).

Some of the switches still say “Yes” in the “Failed” column.

Separately, the air gap didn’t solve the “Unknown” status. Those switches seem to be working fine, so not sure if it’s a real issue, but it’s killing the OCD in me :slight_smile:

#2 any tutorials on how best to do this? Is there any easy way to do this to all respective switches/dimmers?

#3 confirming that I can do this on any node and it does it for the entire network?

Also…for the firmware, it looks like I’m on 1.48 for dimmers and 1.21 for switches, which I believe is the latest stable version.

Re-interview probably best for this. Make sure the device is freshly used or air gapped before re-interview.

Healing an individual node repaths it only for that node. This, however, does NOT perform the heal on the entire network.

What are you using for ZJS server? ZJS2MQTT or ZJS Add-on? Documentation should have this.

Also, feel free to tag me for quicker response with “@” then my username.

Thanks @kreene1987 this is very helpful.

I’ll tackle the “Unknown” ones later.

I’m using zwavejs2mqtt.

I tried to debug the 3-way last night, but struggling. They were all working fine previously and I haven’t made any changes to configuration. Basically encountering two issues:

  1. Cycle On/Off: In this case (happening with multiple switches) I press Off on one switch, then the lights turn off, then on, then back off (all very quickly). The end result is correct (it turns off) but it shouldn’t cycle
  2. Unresponsive Switch: Only happening in one case. I have two dimmers, and one (which I think of as the master since the power to the light is wired to it) is completely unresponsive to touch. But the other (the slave) can operate the light. The interesting aspect is the led bar to the master properly reflects the current status. The master is listed as “Failed” so my guess is that I need to re-interview.

Interesting update.

So I updated HA and zwavejs2mqtt versions (I run docker instances of them) and suddenly I have a number of “Dead” nodes (similar ones to what I had before, but some new ones).

I tried the Heal Network and Check All Failed Nodes at the top level (which I believe handles the entire network), but it doesn’t seem to have changed anything. Although it’s really difficult for me to understand when the process has finished (I don’t know where to track the status).

Actually ignore my last comment. I know why they are all dead. Those switches are all exterior and the contractor had to install a photo cell (building code). I will see if they all reconnect tonight, and separately, I will remove that damn photocell!

Quick update…I was able to address the “unresponsive switch” (#2) above by removing it and re-adding it and then setting up the associations again. Bit of a bummer as I have no idea what happened, but it’s fixed.

#1 above is still an issue however…for reference:

  1. Cycle On/Off: In this case (happening with multiple switches) I press Off on one switch, then the lights turn off, then on, then back off (all very quickly). The end result is correct (it turns off) but it shouldn’t cycle

@kreene1987 any thoughts?

I have not experienced this at all. What do the zwave js logs show? HA logbook?

That sounds similar to a previous known issue where pressing ON would cause the lights to turn on then off very quickly. A temporary fix was to set the maximum level (parameter #6) to 80%. I believe a more permanent fix is included in one of the firmware releases after 1.48.

1.48 is actually quite old now (almost 2 years) There have been a lot of fixes/updates to the dimmer firmware which is now up to 1.57. Its still listed under the ‘beta’ folder, but its been very stable for a couple of months now. I’m running it on all my dimmers. I suggest updating the firmware. You can try it on just one or two ‘problem’ locations before updating all of them.

@mamber can correct me if I don’t recall correctly, but I THINK the problem he described which was temporarily fixed by adjusting the max level was attributable to certain LED bulbs. So if this is occurring for you with LEDs, you could also temporarily swap in incandescent bulbs (if that’s possible) to see if the problem stops. If it does, then you have the option of trying a different bulb or flashing to a newer firmware.

Thanks for the responses…two quick follow ups:

  1. Most all of our bulbs/lights are LED since this is new construction. The on/off/on (and the inverse) happens primarily with LED can lights. Gonna be a bit difficult to replace them with non-LED.
  2. For the firmware upgrade, you mentioned 1.48, which I believe is for the dimmers. This issue only happens with the switches. Is that worth upgrading as well?

I would start with swapping out the bulbs (these are cans, not wafers, right?) on the leg with the smallest number of bulbs on the a switch where this is occurring. If it’s not too difficult, it’s a quick check. Unfortunately, all LEDs are not the same, some are compatible and some cause issues.

I’d have to go out and buy non-led cans which is going to be a challenge in the area we’re are (remote, with a lot of active fires nearby). So it would have to wait.

Was hoping to explore more programattic ways in the short term.