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.
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;
- Docker repository
- Post-installation Docker
- Nodejs repository EDIT: This is not necessary for Docker install - included in package
- ZUI- Docker-compose file* ZUI- Docker-compose file
*EDIT: Links to ZUI quick start
Quick Start
Other Methods (besides Docker)
-
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.
- 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.
- 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
- 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.
- 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.
- 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.
- Dimmers have a max level of 99, not 100. Rules and widgets may need adjusting.
- 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.
then
getActions('mqtt', 'mqtt:broker:f06f8352c2').publishMQTT('zwave/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui2/api/refreshCCValues/set', '{"args":[3,50]}', 'TRUE' === 'TRUE')
