It appears that Z-Wave JS UI is becoming a stable, full-featured alternative to the native Z-Wave binding. As most users know, the Z-Wave binding has been a fantastic and essential binding, but it doesn’t include many of the utilities and features that are occasional needed, necessitating use of the SIlicon Labs Z-Wave PC Controller.
I’m wondering if there’s anything in the works for openhabian to make the addition of Z-Wave JS UI e.g. as an “Optional Component”
If not, I’d like to suggest it.
Not that I (openHABian maintainer) know of.
openHAB(ian) is a community effort.
Any contribution is welcome so lead the way and implement it yourself.
PRs are happily accepted, ‘please build me …’ 's are not so much.
@lsiepel Currently has a binding PR undergoing review slated for OH5. The binding will need the ZW JS UI application installed. The new binding will discover ZW things in OH using the ZUI websocket option (rather than the MQTT option with the HA configurations that is available today).
From the ZUI documentation, docker is the recommended installation. There is also this comment on other methods The most complex way to run Z-Wave JS UI is on bare metal. One issue that led me to use docker is that there are frequent updates and I found rebuilding with npm problematic. I don’t want to discourage contributions, but IMHO an openhabian option might not be the best approach.
Docker isn’t a reasonable option because only very very few people use it and it requires quite some prerequisite knowledge.
Other methods mentioned in those ZUI docs shouldn’t be too hard to implement with openHABian, nodejs already is on board.
Pinging @Larsen .
Thanks Bob.
That’s consistent with what I’ve read.
I don’t have much experience with docker. If you told me it was brilliant a brilliant idea to run docker on a Pi I’d probably nod because it sounds plausible. If you told me it was insane, I’d probably nod because it sounds plausible.
I suspect the reality is likely based in RAM-constraints and considerations related to running it on an SD-card, and/or ZRAM.
How is your OH built? Are you running OpenHab in a VM? Is your ZUI docker image running on the same system as OH? Are you running any parts of your setup on a Pi?
it’s quite a lot to learn and figure out: Docker, ZUI, MQTT, and likely the migration of the zwave controller stick (to something more modern 7/800 series). Then you get to start working on the OH side of things.
mstormi so you’re the one!
Thank you for your work on Openhabian. It really makes OH more accessible.
We’d all love enough time to become expert in everything, but your work makes OH accessible where it might not otherwise be. I know you already know this, but I say it again just in case you don’t hear it enough.
and it requires quite some prerequisite knowledge.
+1
Does anyone have knowldege of the resource cost of the environment, and/or the marginal resource cost of the container compared to bare-metal?
Prior to installing ZUI, I was on using openHABian images for OH. I installed docker on top of that for ZUI because it was the recommended approach. My original notes from Sep 2023 (somewhat dated now) are here. I’m not an expert but didn’t find it that hard.
Today I have completely moved over to docker based setup. My Zwave network is split. I have a OH-test/ZUI system on Rpi4 - 2gb and a production OH/ZUI system on Rpi5 - 4GB. Both were started with a Rpi ‘lite’ image on an SD card and then I installed docker using the apt repository. The OH docker documents are here and here. (the last site shows 31K pulls in the last week, so I don’t think it is that rare - if that is accurate). However, I agree it can be a little confusing since there are so many options. There is also at least one forum tutorial here.
On my systems the Rpi4 average 1-5% CPU and the programs (Docker, OH5.0M2 and ZUI) use .75 out of 1.8 GB. On the Rpi5 CPU runs between 1-10% (when the IP camera binding is recording). The programs (Docker, OH5.0M2, ZUI, MQTT and MySQL) use 1.7 GB out of 3.95. Unrelated to your questions, I did have to figure out Samba without the aid of openHABian and I used a RPi clone application to transfer the SD card contents to SSD’s.
Thanks for your kind words. A rarity to hear indeed.
There’s no exact figures but it uses quite a lot more RAM.
That’s dangerous on memory restrained systems like Raspberries and even some NUCs where RAM already is the #1 limiting factor and troublemaker for many users (forget about CPU usage, that’s negligible).
Docker adds additional layers of complexity, too, port mapping and such. And it sucks up RAM.
That’s unnecessary and may be acceptable in some VM setup but it does not make sense at all on a bare metal machine which is already dedicated to your openHAB home automation.
What’s the overwhelming benefit you get in exchange when you do that, particularly so as it means to also lose openHABian?
Reading the ZUI install docs, Docker is just one of several options and for sure not the one I’d recommend if I don’t already have a Docker setup going.
On my RPI4 with 8 GBytes of RAM running openhabian, I decided to install zwave-js-ui using snap. I am not sure this is optimal but I must say that I never had a problem with this installation. It works like a charm and the update is easy through the command “snap refresh”. Hope it helps.
Anyone to aim for an openHABian contribution should be using Debian standards (snap is Ubuntu). So as there’s already a nodejs install routine, the npm based method should be used.
Thus non optimal 
