My Experience Implementing Z-Wave JS

I decided to just write this up for other folks who are on the fence about making the move. I am not a home automation novice in any way, I’ve been geeking my stuff out for decades through multiple home automation platforms (I even still have a couple X10 devices hanging around). And, while this worked, it is not cut-and-dried. Fortunately my home is a mix of a bunch of technologies, with Insteon still reigning supreme on my light switches, so being without Z-Wave for a day or two isn’t the end of the world (but it’s a bit annoying). The entire process just feels BETA to me, honestly.

So, I decided to pull the trigger since I had some free time today to finally make this migration happen. I was going to wait on a migration assistant but it doesn’t seem that is a very high priority and I might be waiting a while. Since I knew I could always just restore HA to before I migrated I figured no harm, no foul. The worst part is renaming a few hundred devices (or at least I thought it would be until I wrestled with the MQTT system all day long).

I followed Petro’s instructions to the letter and opted to use ZwaveJS2MQTT version because part of what I wanted to have is the ability to have greater control over my Z-Wave devices and that capability is more limited in the baked-in ZwaveJS. Perhaps the process is less frustrating by skipping this and just installing the ZWaveJS, I don’t know.

Before diving in I checked on ZwaveJS device support by looking up my devices (especially my most crucial devices) at the ZwaveJS Office Device DB.

Some notes about my experience:

  • I suppose it goes without saying, as the instructions do not mention it and it is kind of common sense, get a full snapshot before you touch a thing. In my case I also went the extra step of SSH’ing into HA to “ha core stop” the system so I could get a clean backup of my database (because if you have ever restored you likely know that 99% of the time your database corrupts and you have to delete it and lose your history)
  • The instructions state to remove the Zwave config entries or the lines in configuration.yaml. In my case I had both from my initial attempts to get Zwave working when I first installed HA. So make sure you check for a “zwave:” section in the yaml even if you have the integration installed, just to be safe.
  • While not in the instructions, you cannot simply paste your network key into the MQTT configuration, you have to convert it back from hex by removing the 0x from each value and the ", " (comma + space). The control panel isn’t clear on this in the least, you paste in your key and it tells you it’s invalid and then you make a change and instinct is to click the little refresh button, which I did, and then it all looks good - but that refresh button is actually a button to generate a new key entirely. I thought when I hit that and everything was good and the changes I made took (because you assume that button deciphered the hex into whatever it needed), but they didn’t and I had to re-discover my locks once I figured that out. A minor inconvenience, but worth knowing in advance.
  • The timeouts can be infuriating. My device list would populate, then disappear, then partially populate, then disappear and when I checked the logs I got almost continuous errors of “Ingress error: 400, message='Invalid response status" and I attribute this communication error with the glitchiness of the control panel. My theory is that the Z-Stick is so busy discovering and cataloging the network that it just times out. This is where it might be nice to have an option to limit how many workers the process can use so you can try to curb this issue as it is extremely annoying and accounts for my having to babysit this discovery all day long. After talking with the developer, the belief is that perhaps my network needs optimized and the Z-Wave devices need to be healed so they can find more optimal hops. So, in light of this, I would add to optimize your network before you begin this journey because this was super painful!
  • Battery operated devices are quite stubborn, it will take a very long time (even when waking them up constantly) to get the system to finally recognize them. The worst of the bunch is any Aeotec Wallmotes, they just won’t ever “wake up” enough for the MQTT broker to discover them and you have to put them into keep-awake mode (pressing the button on the back for 2 seconds and all lights blink orange) for it to work at all. The same goes for First Alert CO2 detectors, they will never wake enough to recognize (so pull out the battery tray and press and hold the test button, insert the battery tray, count to 3 seconds and let go of the button. You will have to do this multiple times until you see MQTT discovered the device). Another popular motion sensor, the Fibaro, was 50/50 hit and miss, about half of my two dozen Fibaros went OK, the others I had to pull them down, open them up and quickly hit the button 3 times to put it wake mode and then they configured within a minute or two. These aren’t problems with ZWaveJS per se, more of just devices that conserve battery aggressively.

So for me this is a bit of a trade off (and my willingness to do so is yet to be determined - I may yet return to OZW 1.4 until JS gets further along) of gaining a bit better Z-Wave network performance (and my experience is that it is only a bit better, not the significantly better that was implied) and the ability to tweak settings in exchange for losing quite a bit of function on my Z-Wave devices.

In all I’ve lost about 1/3 of my Z-Wave entities, many of which were used in various automations. None of them critical, but now they are gone. Aeon Power Strips should have FIVE switches, one for the entire power strip and four for the four controllable outlets, now I have just the outlets (again, why not add that extra switch?). The power strip becomes more of “quality of life” since I can just turn off all four switches to effectively turn off the entire strip, but I had that with the antiquated OZW 1.4, how could this not be a part of ZwaveJS? Those are just two of about 200 or so missing entities, some more useful than others. Once again, discussions with the developer shed some light on the fact that some of the functionality that was available to me in OZW 1.4 may have been “hacked in” so that it existed in the first place, rather than being part of the core Z-Wave definitions. I understand that can be hard to track down. Without looking at the definitions of the power strip itself, though, it seems like this switch should be there.

In conclusion, the ZWaveJS with the MQTT seems to work OK but it a decent hassle to get it working. I’m a pretty technical guy and this was a struggle. It’s not like I had to constantly tweak things, but the instructions are not the ABC’s of migrating, it’s the Cliff Notes that point out the most important bits. One thing that I do know is that once I got all my devices recognized things settled in and worked fine for the most part. I think that if your network is very basic, has no battery operated Z-Wave and doesn’t use anything more than basic switches and lamp controllers then this is a piece of cake, but the more advanced your Z-Wave network the more advanced your headache of implementing ZwaveJS is (and be ready to potentially sacrifice some device capabilities - which is more compounded by how much you rely on those for your advanced home automation).

ZwaveJS has tremendous potential, and it certainly works, I think as it matures it will become even better than it is now. While there is some loss in functionality, it’s not critical functionality (even for me who does a lot with those extra entities), so the benefits of ZWaveJS over OZW 1.4 weighed against the detriments of OZW 1.4 alone make it a bit of a wash, but it’s a wash that promises future development and improvement where there is and never will be any for OZW.

Thanks @blhoward2, this is a bright future of Z-Wave for HA. Like all things, it will take time to be fully dialed in but it seems like all things are moving in the right direction.


It sounds like you have some bad routes causing your discovery delays. That issue isn’t normal, nor is your experience. Your mesh is far from healthy. Try healing the nodes one by one starting at the ones closest to the hub and working out.

There should be no capability loss as we support all of the ozw CCs plus some. If you’re having a problem open an issue on the project so we can fix them.

Perhaps, but since it always worked without any issues whatsoever in OZW 1.4 I don’t think it’s that messed up. I’m sure it could benefit from being optimized, but honestly my experience was more sullied by the loss of function of so many devices than spending an entire day fussing with the control panel.

I’ll open a ticket on the Wallmote, it is 100% useless in ZwaveJS as-is. And I have quite a few of them, so it’ll be lots of coding to read Z-Wave traffic to figure out what button was pressed and how.

Scratch that, I can’t open the ticket on Wallmotes. You have a general post on February 4th of the list of devices to be supported “in the next few weeks” and the Wallmote Quad is one of them, and to “not open a ticket on these”. Of course, it’s been more than a few weeks but I’ll respect the request not to open a ticket anyway.

You also mention “help needed”, I’m quite capable and willing to assist. I am a developer and quite experienced in home automation.

I think I already have a pending PR for the wallmotes. Or most of them anyway. There may be a newer one or two I’m missing. But a missing file shouldn’t affect functionality so if it’s not working you should report that.

1 Like

RE the help I’ve had a few people start helping but I think only one person has finished templating an entire folder.

Are you using HomeAssistant?
If yes, please open your issue at Issues · home-assistant/core · GitHub
UNLESS a developer told you to come here.

So which do you want me to open that ticket on?

It depends on the issue. Generally we send people to HA first and they send up to us if upstream, but what’s the issue?

The Wallmotes only functionality in HA is to report various power parameters, zero entities for the various ways to actually use the Wallmote. It’s four buttons as the core, but they support long presses and swipes as well (swipes I understand, they are more complex, but even OZW 1.4 could deal with them after tweaking the config file in HA).

As for helping, I’m ready and able to help I just need guidance on what I need to do and the proper procedure to do it. Just say the word :slight_smile:.

That’s because it sends stateless scene commands. Have you tried watching for an event?

That’s what I’m planning to do to get them working. Regardless, even on non-Wallmotes, I’m willing to throw my hat in if you need it.

Well, that’s not a loss of functionality it’s how they’re meant to work. OZW didn’t follow the spec and created entities for them with a hack to reset the state.

Noted, thank you. I’ve updated my post to reflect that.

RE helping, if you message me on slack we can talk about how you can help.

Join channel

Oh, on it working on ozw. It working doesn’t mean the routes are good paradoxically. If the controller doesn’t respond the device sends a NIF message that finds a way back to the hub. But it doesn’t update the route so it has to do that every time. That slows it way down and increases network congestion.

1 Like

I will heal the network and see if it makes any difference in performance since the cat is already out of the bag on the discovery phase :slight_smile: .

This is the reason why I stopped trying. I do appreciate the effort people put into the whole z-wave items and it is getting better and better. But to keep the wife happy it needs to work 99.89% of the time. Get yourself a Fibaro Lite. Costs around 99 euro here and you can hook up all your devices, heck you can even firmware upgrade your fibaro devices. It connects just fine with home assistant via the api and delays are non noticeable. To top it off (this is my best thing) you can make a backup in the cloud of the fibaro (this includes the zwave stick) so if for some reason your fibaro device dies. You buy a new one and restore a backup and all is working again. Since it restores the zwave data too! Fibaro is the only one that i know that can actually restore zwave config to the stick.