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.
.
