Zwave-JS-UI in place of OH Zwave binding

Update: Changed Title as not really a test anymore. Have run over 6 months on two systems this way (OH + ZUI)
This idea started as a “proof of concept” to use Zwave-JS-UI (ZUI) instead of the OH Zwave (OHZ) binding. ZUI is an application on top of a Zwave-JS server application. I was not having any problems with the OHZ binding, but ZUI application natively supports 700 series controllers, S2 security and OTA firmware updates among other things. It is the Zwave provider for Home Assistant and several other automations, and it is being actively developed for Zwave Alliance certification and 800 device support in the future. I thought it was worth a try.

I installed ZUI in a Docker container on my Rpi3 and Rpi4 2GB devices with the bare metal openhabian (Yes, I know what that means!) running OH4. The Rpi3 only used the OHZ binding with 25 nodes and the Rpi4 2 GB had 34 Zwave nodes plus the IP camera, Remote OH, Mail, Network, MQTT, FTP bindings, plus all the rules for both devices. It was also running the MQTT broker and MysqlDB server. After transition, I observed about a 5-10% increase in memory use from about 55% and about 0.5% increase in CPU, but still below 1%. Below is a chart of the Rpi4 memory after transition.
Rpi4 memory 2023-09-29 082305

The post transaction Rpi3 memory was running a little high for my liking, so after a week I made some changes. I flashed a new SD card with Debian Bookworm, added Docker and ZUI and used MQTT instead of the Remote OH binding to transfer all the Zwave measurements to the Rpi4. In this configuration I was using about 30% of the Rpi3 memory.
I did briefly spin up an empty new OH container (to see the current first time wizard) and the memory was running around 80%. Therefore, I think ZUI on top of OH4 (at least the way I did it with Docker) requires at least 2GB memory to be comfortable.

Outline of steps
I don’t expect this to be a popular hack for current OHZ users. I would assess the difficulty as advanced because the numbers used in Zwave transactions will need to be somewhat understood. Also all the channels need be setup as Generic MQTT things. My suggestions.

  • Use ZUI in a Docker container. This makes updating easy. It can be installed in other ways, but I settled on this way after trying some others. Second choice would be the zip package on bare metal.

  • Configure the ZUI gateway to just send values and just send the node number. Do NOT use the Home Assistant discovery options. These setting reduce the transformations required to a few simple MAP files. It also means you can name the devices in the ZUI application without changing the OH transformations

  • I used the following links for documentation;

  • To transition using the same Zstick I stopped the OHZ binding, spun up ZUI in Docker, configured ZUI as noted above and waited for all the nodes to be interviewed by ZUI (waking battery devices) and for MQTT to be populated with the retained topics.

  • Create duplicate channels to each existing item using generic MQTT things, leveraging MQTT Explorer to copy the relevant topics. This doesn’t have to be done all at once or even while ZUI is running. You can stop ZUI, restart the Zwave binding and link the topics at your leisure, although stale data during a long transition will be an issue.

    • In retrospect creating all the generic things and channels could be done in advance of starting ZUI for the first time, or at least with only one OHZ stop - start sequence.
    • After a few channels, it becomes repetitive, so I just used the “Code” tab to copy channels.
      * UPDATED: Generic Mqtt examples for UI "code" tab (now using Named topics, Just value & Ignore location in ZUI gateway)
      zwave-js-ui-channel-examples-new.txt (7.9 KB)
  • Once I decided to stick with ZUI, I deleted all the OHZ things and channels.

Update: Transition Troubleshooting Summarizing a few items from other posts. Will add as needed.

  1. If a device doesn’t work the same as in OH after the initial transition, use the Node, Advanced to Reinterview. There is a lot of Zwave traffic on the first transition and messages may have been dropped or cancelled (see controller statistics). A reinterview is a good first step. Note that a battery device will need to be woken.
  2. Unknown Device. This means the same as in OH. Although the Zwave-js DB is larger there could be devices in the OH ZW DB that are not in ZUI. You will need to open a configuration request ticket on the Zwave-JS github page. Note that configurations are changed in Zwave-js and not in ZUI
  3. Scenes are handled differently in ZUI than OH. The normal state of a scene is blank (or null or “”) and the scene number is briefly sent and then returns to blank. To get this to work in OH I changed my scene item to “string” from “number” and changed to rule to reflect a “string”. Also for multi-button scene controllers (I have a Fibaro key fob) each button is a separate Mqtt topic.
  4. The default battery device poll is every 6 days, not with every wakeup as in OH. This can be changed in the “General” section. General section polling applies to all devices with the same identifiers. I actually switched to using the lastActive Mqtt topic as I was mostly interested in making sure the device was working.
  5. For general questions on how things work in the apps I found the Discussion section of both the Zwave-JS and ZUI githubs site useful.
  6. Dimmers have a max level of 99, not 100. Rules and widgets may need adjusting.
  7. Refresh is via Mqtt action to the zwave-js API. The example below is from a DSL rule that refreshes the meter readings (50) on Node 3.
    getActions('mqtt', 'mqtt:broker:f06f8352c2').publishMQTT('zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui2/api/refreshCCValues/set', '{"args":[3,50]}', 'TRUE' === 'TRUE')

I’d like more details on this point. With HA discovery, wouldn’t you need no transformations? Can you elaborate more on the problem you encountered?

The main problem was Jinjava transform cannot handle numbers as “keys” in a HA config expression. I registered an issue here with an example. Also went upstream to the imported class here. Lastly I tried to modify a jar with the PR from the jinjava site, but couldn’t figure it out without help, so gave up.

Anyway except for the tedium, it actually went pretty fast as I just copied and pasted on the code tab.

1 Like

Installed using

sudo snap install zwave-js-ui

Have you noticed any performance increases?

Not sure what you mean? As noted above, I wasn’t having a particular performance problem with OH ZWave. However, I was using my unmerged 700 controller PR, so it was a 700 to 700 comparison. I did get improved routing with the 700 controller. Most nodes are in direct communication with the controller at 100KB. I like the network tab on zwave-js-ui as it shows actual routings, not just neighbors.
Rpi4 zui network 2023-10-21 143223

I found Snap to be problematic on Debian Rpi OS in finding the controller, so settled on Docker instead.

This is what I was hoping to see, not so much speed which I don’t expect. The few (battery operated) devices I have connected on the Zstick7 are as far from the controller as can be, and they work fine.

I did get better range with the 700 series. The nodes above that are two hops (green) are actually outside the house. Thanks for trying this and post any observations you think may help others.

Testing with a simple wall plug, but not getting mqtt right. You have:

      commandTopic: zwave1/5/37/0/targetValue/set
      stateTopic: zwave1/5/37/0/currentValue
      off: "false"
      on: "true"

as a template for a binary switch. I have:

      commandTopic: zwave/WallPlug/switch_binary/endpoint_0/targetValue
      stateTopic: zwave/WallPlug/switch_binary/endpoint_0/currentValue
      off: "false"
      on: "true"

In this config, the OpenHAB item responds to ON/OFF switch inside zwave-js-ui, but OpenHAB does not control the wall plug. I am stuck on the “*/set” part. Probably my lack of knowledge around MQTT, but in my config I get command to targetValue (obviously), but currentValue doesn’t change (from OH command).

My Gateway setting for reference:

How are you stuck? Need to add /set like the example or it won’t work.


Also I noticed I did not suggest using MQTT Explorer. Do you have that installed? Here is a switch that I turned on in OH

mqtt switch 2023-10-24 150541

I’ve been using MQTT and explorer for a while with connections to home assistant. Must be one of my settings. I tried the /set topic and didn’t have a positive result. Thought maybe I may have missed a minor detail, but apparently not. I’ll keep at it.

Assuming you can see the /set message work in Explorer using zwave-js-ui (and the current state reflected in OH, but not changed in Explorer with the OH switch, maybe putting OH-Mqtt binding in debug might show why the message is not published?

As OH is quite slow on ZWave support, wouldn’t it make sense to have a generic home assistant backend binding to integrate zwave-js-ui? We could then have any other home assistant backend.

Welcome to OH

Not sure I understand. There is a HA thing and channel discovery (via MQTT) in OH. It is just that several of the HA config profiles do not work with the jinjava transform, so I found it was better (for me anyway) to just use the generic MQTT things and channels.

What I have thought about is to have OH thing and channel discovery of Mqtt topics. The config profiles would need to created and be compliant with the OH model) then added to zwave-js-ui. However, I think that is beyond my ability. The current situation is similar to the zigbee Mqtt process in OH

I’ve done just a little bit of testing, but I can confirm that this method works with an 800 series controller (Zooz ZST39 LR) and 800 series device (Zooz ZEN04 800LR).

Other than a small snafu of my own making with my old mosquitto instance it was quite easy.


Do I need Home Assistant installed or would zwave-js-ui be enough? I might be able to fix the jinjava transformations.

I have only been using zwave-js-ui with OH. Not touching HA was kinda the idea. Although setting up the generic MQTT topics was a bit of work, besides the jinjava problem, the generic MQTT path sidestepped the HA limitations noted in the documentation. HomeAssistant MQTT Components - Bindings | openHAB

In case you missed them, my jinjava issues (in github and the forum) are linked in my Sept 29 post in this topic.

Based on my bad knowledge I am totally confused. Why does this tool work at all on Z-Wave side? Is it part of the “Z-Wave Alliance” with propper License?

Couldn’t someone transfer it to an new Binding so we get full Z-Wave support for 700 and 800 Chips?
Am I wrong that RazBerry7 will fully work with zwave-js-ui ?

Thanks for clarification!

zwave-js-ui (ZUI) is the same relationship to OH as zigbee2mqtt, except it is Zwave. There is both an OH Zigbee binding and Zigbee2Mqtt standalone application. Same for ZUI and OH Zwave binding.

Reading the ZUI docs they are trying to get certified by the Z-wave Alliance, but have no other connection AFAIK. It is written in typeScript/Javascript (I’m not sure of the difference), so is not really portable to OH where everything is java without a lot of work. Plus (IMO) ZUI is very active (many PRs a month), has 700 and some 800 support, S2 security and several developers versus only one for both OH Zwave and Zigbee. The only real drawback for an OH user is that generic mqtt things should be used. HA discovery is only a partial solution and has some issues (see this recent thread).

It should work IMO, but I’m using a Zooz 700 zstick.

Who has kind of moved on to other things

I see that this works with some adjustments, but wouldn’t it be great if you could use both HA and OH at the same time without adjusting ZUI? It makes it great for migrating either way OR allow both to operate at the same time depending on needs. Say maybe a locked down guest environment vs home owner, etc. Or just preference! Maybe my wife likes one vs the other. For my home I have 3 remote zwave devices due to interference and speed (have quite a few zwave devices and interference problems) and ZUI easily makes this work with HA, but I really would like to have OpenHAB for other things. Sure I could probably set up serial over IP but that locks me down to one or the other. ZUI helps extract that layer.