Zwave-JS-UI in place of OH Zwave binding

Hello everyone,

I have also switched to Z-Wave JS UI because I have all the tools for e.g. backing up the controller, deleting dead nodes etc. in one tool.

Basically it is quite simple if you know how to do it. I switched to Docker (there are plenty of instructions here) and then created another Z-Wave JS UI stack.
The Docker Compose file can be found on the Z-Wave JS UI Github page (

At the beginning you have to read out the ID of the Z-Wave stick that goes

ls /dev/serial/by-id/

and enter it in the Docker Compose file

   # Do not use /dev/ttyUSBX serial devices, as those mappings can change over time.
   # Instead, use the /dev/serial/by-id/X serial device for your Z-Wave stick.
   # To find the ID use:  ls /dev/serial/by-id/
    - '/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_7-port0:/dev/zwave'

Now comes the part that is a little more complex. Extracting the correct information from the MQTT data and assigning it to the old items. I used the MQTT Explorer to do this.

I left the openHAB Z-Wave binding on for the time being because otherwise my original Z-Wave things would be empty.

Here is an example of a thermostat (See all my Z-Wave devices here
zwave-js-ui-channel.txt (5.2 KB)

First the information as I see it in the MQTT Explorer

To display the current temperature, I have to search for the Air_temerature entry and enter it in the corresponding channel in the thing.

UID: mqtt:topic:73089d4ec9:Wohnzimmer_Heizkoerperthermostat_Node_3
label: Wohnzimmer Heizkörperthermostat
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:73089d4ec9
  - id: sensor_temperature
    channelTypeUID: mqtt:number
    label: Current temperature
    description: Indicates the current temperature
      stateTopic: zwave/nodeID_3/sensor_multilevel/endpoint_0/Air_temperature
      transformationPattern: JSONPATH:$.value
      unit: °C

If I don’t know exactly where to find the current temperature value, I can also view this very nicely under Z-Wave JS UI


I became very familar with MQTT the last weeks and all Channels based on Generic MQTT Items work increadible perfect (Tasmota on the other side)

So know I am very interested on an experimental Z-Wave Setup (lets say with 3 Nodes) and the BackUp functionality of Zwave-JS-UI.
Not sure If I will also go the Docker way.

Can anyone explain me what I do need after a factory reset of all devices? How can I start recovery (lets say based on a broken Raspery or it SD-Card)

Thanks a lot and Happy New Year 2024!

Second choice IMO would be the package installation. I found SNAP doesn’t work well with Rpi Debian and using YARN to compile uses a lot of resources (worked on 2G Rpi4, but not on 1G Rpi3). Lastly Zwave-JS-UI does get updated frequently, so keep that in mind. Docker upgrade is easy.

Not quite sure what you are doing here. I just used the same Z-stick, no factory reset, no recovery. Network is on the Zstick, not in OH (or ZUI for that matter). Had both OH (ex-ZW binding) and ZUI running

If Rpi/SD card broken and no other apps running, reimage SD with Debian O/S, and follow one of the non-Docker Zwave-JS-UI instructions

Used Z-Wave Binding all the time with 3x OH Installation and was not able to restore 52/Nodes Z-Wave-Items. Its a nightmare to reconfigure such a Mesh and therefore I search for a masterplan of restoring before doing it the next time.

I had the Aeotec Z-Stick Gen5+ controller in the past. For Z-Wave JS UI, I swapped the Gen5+ for the Z-Stick 7. To do this, I first started Z-Wave JS UI with the Gen5+ stick and made an NVM BACKUP (Control Panel → Advanced Actions)

I then shut down the system, replaced the Gen5+ with the Z-Stick 7 and rebooted. I then used NVM RESTORE to restore the Gen5+ backup to the Z-Stick 7 and everything worked. In the the past I have used a tool to back up the Aeotec Gen 5+ stick, which can be found can be found on the Aeotec site.

Moved away from Zwave binding to Zwave-JS-UI.
The cut-over to Zwave-JS-UI was pretty straight-forward in my setup.
Running Openhab (now 4.1) in docker container on Synology NAS (on lastst DSM version) (since years) and Aeotec Z-Stick Gen5.

  • added Zwave-JS-UI docker container
  • stopped the Zwave binding in karaf (bundle:stop id)
  • started up the Zwave-JS-UI container and changed the configuration to use the same serial port as before. All Zwave nodes were visible immediately, and I was even able to easily remove dead nodes. I did not define the zwave device in docker configuration in Synology´s container manager.
  • Zwave-JS-UI Home Assistant settings are switched off
  • configured Zwave-JS-UI to use existing mqtt broker (running in dedicated docker container)
  • created Generic MQTT things for all my Zwave devices (sensors, rollershutters, switches)
  • created the required channels for each Generic MQTT things
  • linked to the channels to the existing items used before with Zwave Binding
  • all rules worked without any modifications

Running this setup for another week before finally removing Zwave Binding.

The main benefit and improvement for my setup is that the Fibraro RollerShutter in Venetian blinds mode are not fully supported by Zwave Binding (

The Zwave-JS-UI has full support and all my use-cases are finally covered, opening/closing/tilting blinds with physical switches is now reported back and both Homekit (via node-red in dedicated container) and all rules are picking up the correct and actual blinds position and tilt angle.
A small modification in node-red was required to get rid of the workarounds required to handle/translate the tilt angle, but this change was expected.

Basically followed the same procedure. Thanks for the summary version :smiley:

Still a little confused. Even if Rpi and SD crashed the 52 Zwave nodes should still be on the stick. You should be able to use that in either OH ZW or Z-Wave UI, if you have not factory reset it.

As to backup, as noted by @HolBaum5 I periodically backed up my zsticks using either the Aeotec tool or the Silabs Simplicity suite (depending on the SDK of the stick). Now I just use a Z-Wave UI’s weekly NVM and Store backup.

This worries me a bit (but I’m glad it worked for you). There are numerous warnings about incompatibility between Zsticks of different SDKs. What SDK was your Gen5+ Zstick?

I started on a guide (draft).
Transitioning a network from 500 chip.pdf (235.8 KB)

Why do it: “Zwave-JS-UI Home Assistant settings are switched off” ?
I was thinking that auto-discovery in OH would make the move easier since then all the channels appear automatically and are easier to link to items from both “.item” files and the UI.

2 reasons:

  • the jinjava transform issues called out earlier in the thread
  • I prefer to create the channels I require and not clutter my things with channels I am never going to use
1 Like

I found this description and tried it out.Moving from Z-Stick Gen5 to Z-stick 7 · zwave-js/node-zwave-js · Discussion #2927 · GitHub

The Gen5+ stick was running the latest firmware V1.02, according to the Aeotec homepage:
Updates Z-Wave device library to 6.07 (using Z-Wave SDK 6.81.06).

The Z-Stick 7 has FW: v7.17.2 and SDK: v7.17.2.

Thanks for sharing the link, that is good information and might help others with a simpler process. (I did suspect you were on the latest firmware on the Gen5+.)

Edit: Also glad to see yours is working on 7.17.2. There were some discussions about problems Problems with 700 series sticks ( prior to that version and most of my testing was on 7.18.3

I have updated the Aeotec Z-Stick 7 to version V7.20.2 (FW: v7.20.2, SDK: v7.20.2) and everything has been running for a few days without any problems.

Until today? Sounds a little bit scary. So please let us know when its seems to work “forever” :wink:

Short update:
Moved to Zwave-JS-UI 3 weeks ago - no issue what-so-ever and therefore removed Zwave binding 2 weeks ago.

Not regretting this change.

Should have done that way earlier, since finally all my use-cases are covered.
Additionally this issue Z-Wave Binding: Fibaro FGR-222 Rollershutter UP command not fully raising Blind is finally resolved as well.

Strongly recommending this change to anyone asking.


i am not familiar with nodjs sooo…installed zwavejs ui via

 npm install zwave-js-ui

How can i start it now?

What bout reading the zwave-js-ui documentation.


Other than the Fibraro RollerShutter not fully supported in OH zwave, what are the other use cases? It’s always good to understand differences of the OH zwave implementation compared to others.

I’ll let @Chri46 answer for himself, but throw in my 2 cents.

I started with OH several years ago because of the open-source ZW binding. I would not be using OH today without the ZW binding being available then. I’m personally grateful to the developer for that (and try to provide ZW support within my ability). Since the move to NZ the developer has been very busy with his real job and so the binding hasn’t changed much beyond incorporating new devices. That’s fine, this is a volunteer effort.

OTOH, Zwave-JS-UI (formerly Zwave2MQTT) has been able to leverage the HA connection to include new features and fund more active development. I wrote this post to highlight that OH users did not have to switch to HA to get the benefit. (similar to Zigbee2MQTT). The major drawback is generic MQTT things need to be used (at least in part - the HA discovery configs do not always work.)

Now, to answer your question; ZUI has (to name a few)

  1. Pretty much all the key features of Simplicity Studio (without removing the zstick from ZUI).
    a) NVM Backup
    b) Zombie node removal
    c) Node health check
    d) Set Priority and Return Routes
  2. Smart Start
  3. S2 security
  4. Better diagnostics (see the network routing map above (post 5)
  5. Larger user population (leads to more devices being available in their DB)
    a) adding a new device temporarily is easier, permanently is subject to a longer delay that OHZ.

As to the future, the ZUI team seems focused on certification by the ZW Alliance and true ZW Long Range support.

I think the OH ZW binding is great for new and OH users with only a few ZW devices (discovery is a snap), but for users with larger networks, comfortable with generic MQTT, and committed to ZW, ZUI is going to be an attractive alternate.