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.
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
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 from my cheat sheet (see attached). zwave-js-ui-channel-examples.txt (6.4 KB)
Once I decided to stick with ZUI, I deleted all the OHZ things and channels.
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.
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.
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).
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.
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.
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 ?
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.
