With the latest openHAB release, a new Z-Wave JS binding is now available. This addition offers an alternative approach to integrating Z-Wave networks into openHAB, particularly for those with advanced needs or multi-platform environments. It is important to emphasize that this binding does not replace the existing native Z-Wave binding. Both are fully supported, and users are free to choose the option that best fits their requirements.
Below are some key advantages that Z-Wave JS can offer:
Cross-platform compatibility – Running Z-Wave JS outside of openHAB allows for greater flexibility, especially when migrating to or from other platforms. Devices do not need to be re-included, and multiple platforms can share access to the Z-Wave network.
Support for newer Z-Wave hardware – Includes full support for 700 and 800 series Z-Wave chipsets.
Advanced protocol features – Enables S2 security, Smart Start provisioning, and over-the-air (OTA) firmware updates for supported devices.
Improved network management – Provides reliable removal and replacement of failed nodes, and includes a functional, visual network map—particularly useful for larger installations.
Detailed routing information – Allows viewing and assigning priority routes, which can significantly improve the reliability and responsiveness of the Z-Wave network.
Clear controller state feedback – Inclusion and exclusion modes provide explicit status information, including duration.
Faster restarts – When openHAB is restarted, the Z-Wave network does not need to be re-interviewed from scratch, reducing startup time and avoiding network congestion.
On-demand re-interviewing – Nodes can be re-interviewed selectively when needed, rather than globally.
Independent release cycle – Z-Wave JS evolves on its own schedule, often delivering faster support for new devices compared to the openHAB release cycle.
Low-level command support – Enables more advanced functionality such as multicast messaging to multiple nodes.
Backup and restore capabilities – Offers full backup and restore of the Z-Wave controller’s non-volatile memory (NVM).
note: the binding does not (yet) natively support all features, for some you can use Z-Wave JS directly (e.g. NVM backups etc.)
This binding is especially useful for those managing larger Z-Wave networks, experimenting with advanced device features, or maintaining interoperability across multiple home automation platforms. For users with simpler setups or who prefer tighter integration within openHAB itself, the native Z-Wave binding continues to be a solid, reliable option.
If you’ve tried the Z-Wave JS binding, or are considering it, feel free to share your experiences or questions below.
Does this replace the existing openHAB Z-Wave binding?
No. The Z-Wave JS binding is an alternative, not a replacement. The original native Z-Wave binding continues to be fully supported. Users can choose the one that best suits their setup and preferences.
Can I run both bindings at the same time?
No, not on the same Z-Wave controller. Only one application can access the Z-Wave hardware at a time. You must choose either the native Z-Wave binding or Z-Wave JS (running externally), but not both on the same stick.
Can I migrate from the native Z-Wave binding?
Yes, though it requires some setup:
Set up and start the Z-Wave JS server with the same controller hardware.
The controller retains the network configuration, so devices do not need to be re-included.
You’ll need to recreate or import the Things in openHAB using the new binding.
Any existing channel links need to be revised as the naming convention is a little different
Be sure to disable or uninstall the native Z-Wave binding before switching.
Can I use this binding if I already use Z-Wave JS with Home Assistant?
Yes. In fact, this is a common use case. Both openHAB and Home Assistant can communicate with the same Z-Wave JS server, as long as both are configured to use the appropriate WebSocket API. This enables advanced interoperability between platforms.
Question regarding the configurationChannels setting. When activated, many useful channels are exposed, however the standard channels disappear. At that point items linked to standard channels now have invalid links (orphaned). Deactivating the setting returns everything back to normal and the items are linked again. Is this intended use? A use case is on the Zooz Zen32 scene controller where the LED colors can be changed to represent active scenes. These channels only appear when configurationChannels is active.
I have seen this once durin gdevelopment and could not reproduce this. I’ll need to look at it again. Could you try to set it up as expected and disable and enable the thing? It might be some timing issue.
Disabling and enabling the thing resets the channels back to original as you might have predicted. However the configuration channels are not present. So it’s either the regular channels or the configuration channels, but not both. On a side note, a restart of OH sets the channels back to configuration, which then requires a disable/enable cycle to get back original channels. I see nothing in the logs. Here is what I am seeing on a GE Enbrighten Dimmer:
Thanks for this binding. I have been using zwave-js-ui via MQTT for some time, and converted the devices to this binding instead (15 devices of many kinds). I’ve noticed a couple of minor issues:
My Ecolink flood sensor does not show any channels in the channel list. It is shown as Online, and is otherwise operational in the zwave-js-ui web interface.
Door sensors are exposed as switch channels. For a door sensor, I prefer to use Contact item type, but this doesn’t seem to work anymore. I can probably work around it with a transform.
Can you create an issue at GitHub? If you put the binding logger in trace the entire store is logged. If you add that to the GH issue I’ll fix this shortly.
Regarding the switch vs contact. I’m thinking of detecting this with some fuzzy logic. Unfortunately we fully rely on the available documentation and data from ZUI and up until now, no clear data item is available.
On latest snapshot this seems to fixed, mostly. If you add bridge then add a thing prior to enabling config channels, the behavior is the same. If you add things after enabling config channels, it works as expected. Might be a minor issue.
Hi, I’m looking forward to this binding as I have had to use some other ways to make my OH communicate with HA. However, I have my Z-Wave JS as an addon with HAOS and I get connection refused when I set it to the ip and port. Am I missing a step?
This sounds interessting as I’m using many Zwave devices.
Is it mandatory to run Z-Wave JS externally or can I run it on the same Raspi (if I have enough ressources available)
You have to enable the ZUI server if not already.
There might also be network issues between your openhab host and HA? Need a little more detaisl to help troubleshoot, but to me it seems like regular networking, nothing fancy.
I figured it out thanks. I found out needed to expose the port in the addon configurations. Restarted the bridge and it came up. Now I can control them directly instead of the janky way I had it before lol.
I was trying to add a Rollershutter item and encountered an issue. I have no idea which channel to link the rollershutter item to. I can’t see a channel like “blind_control” of type Rollershutter — only a Dimmer channel is available. Screenshot below.
Has anyone managed to solve this issue? Thanks!
Thanks, it works. However, I ultimately need to get a rollershutter item, so I don’t have to make changes at the interface level. Therefore, I need to figure out some kind of transformation or rule.
The current binding indeed does not have support for Rollershutters as they are modelled to dimmer.
An obvious flaw. I’ll look into it and (no promise) will try to get it in the next Patch release.
Could you create a GitHub issue and include a trace log of the binding startup? The startup (disable/enable the bridge) logs the zwave store in json (one huge single line) it will make it easy for me to determine what properties of the device I need to check to detect rollershutter
