Upgrading/migrating HA

Configuration
1

I’ve been using HA for quite a long time - since way back in the 0.xx days, and I’ve gotten fairly adept in navigating the yaml world, and have gotten fairly used to it. Of course now the newer versions turn that on its head. I’m currently on 2021.10.0, which I believe is the newest version that’ll work without migrating off the ‘legacy’ Open ZWave setup. I’ve been looking to try to migrate over to the ZWave JS, but I keep coming up dry. My current setup is a Ras-Pi running an implementation of USP-IP, which my Home Assistant VM (running in a VMWare VM) connects to. This works quite well, except for the rather rare instances where there’s some sort of communication hiccup, in which case everything goes off into the weeds and basically requires that everything be restarted, the RPi hosting the ZWave stick first, in order to get everything working again. There is no seamless, graceful reconnect, unfortunately. Truth be told, I don’t want any of the ‘cloud gaga nonsense’ - I just want HA to run my ZWave devices and THAT’S IT. No Alexa junk. No ‘Hey Google’ junk. None of the ‘cloud’ junk. That’s why I ditched Plex - they got so ‘cloud gaga’ that it was a hard nope out. I have ZERO need, want, desire or interest in ‘cloud’ junk. Honestly, I’d LOVE to see a branch offered that didn’t even include the ‘Home Assistant Cloud’ option. Frankly, I don’t even like it just being there. It seems to me that, like Plex, that started out AWESOME, but then spiraled down the toilet with the cloud junk, I fear that Home-assistant is doing the same thing. Bringing in the cloud junk that some people want no part of, and not giving an option to have a branch that doesn’t include any of that junk at all.

The ‘Zwave JS UI’ seems to be a more robust way of doing it, BUT… no matter where I go, I haven’t been able to get things working.

It seems to me that documentation in general has gone WAY downhill. In the past, I’ve had no issues following documentation to get things working, but this has been an epic fail. Honestly, docker sucks. It would have had a place like 20-25 years ago before virtualization was what it is today, but now, it’s unnecessary additional complexity. The few docker installs I’ve put out have been more of a pain than any install I’ve done on a base linux install.

Anyway, I haven’t been able to get ‘Z-Wave JS UI’ working on its own on a RPi to act as a bridge between a home Assistant VM and the USB stick… Which kind of brings me to a concerning point…

In my experimentation, I imaged an SD card with the latest Home Assistant image, it went through it’s ‘up to 20 minutes’ bit, after which I fiddled with it, and was able to install the ‘Z-Wave JS UI’ add-on and get it to work with my USB stick. Now here’s the problem. The first time I did it, when it wanted me to select the device, I was given the option of ‘/dev/ttyAMA0’ or ‘/dev/ttyACM0’. My USB stick being /dev/ttyACM0. After doing that and rebooting, the Z-Wave JS, it still came up and in the ‘Z-Wave JS’ Info, I had an option to launch the WebUI - and that worked. Now the problem is I re-imaged the card to tinker with some other things, and when they failed, I decided to re-image it with the same HASS image I had used an hour or so prior. I did the re-image, it did its ‘20 minute thing’, and then I went to add the ZWave JS compoment. This time, it installed, but when I went to configure, I got ‘/dev/tty/AMA0’ and ‘/dev/serial/by-id/usb-0658_0200-if00’, instead of ‘/dev/ttyACM0’, so I select the ‘/dev’serial’by-id/blahblahblah’ knowing that’s the proper device, but now, there’s no web UI option presented… so why did doing the same thing two times result in two different results??

The fact that I haven’t been able to get ‘ZWave JS’ working as a standalone server on a RPi aside, and the insanity of doing the same thing twice with different results aside, it doesn’t appear there’s a way to specify a remote ZWave JS IP to use - it seems like the only way to configure it is with a local device.

Truth be told, I’m happy where I am, except for the sensitivity of the USB-IP connectivity - it doesn’t take a lot to make that go off in the weeds and break everything until it’s rebooted. The ZWave JS seems to be a more robust solution, but I’d prefer to keep my HASS on a VM, not a RPi. In addition, there doesn’t seem to be a good way to migrate from the ‘old school’ way to the new ‘HA OS’ way… the new way does seem to have some possible benefits, but I’m not keen on being locked out of the base OS…

Even if I’m not sold on ‘upgrading’ to the latest version, I think moving from the uber-sensitive USB-IP implementation I’m running now to a ZWave JS based implementation seems like a good idea - if it can be made to work.

That being said, does anyone have any suggestions on how to get ZWave JS UI working on a Raspberry Pi (preferably on a base Rasbian install, no Docker nonsense - docker sucks…), and then linking HomeAssistant to it?

Edit: after some sleep and a fresh look, I discovered why the Web UI was available the first time around and not the second - apparently, the first time, I installed ZWave JS UI, which is all the way at the bottom of the addons page, not the ZWave JS that’s at the top of the page. The second time I installed the ZWave JS that’s at the top of the page.

2

so…is this now resolved?

3

No, the main issue is getting ZWave JS UI working on a standalone Raspberry Pi running Rasbian, and then getting HA running in a VMWare VM to talk to it. From looking at the documentation for HA, there is mention of pointing HA at an IP, usually ws://127.0.0.1 if it’s running on the same device, but in a situation like I’m looking to do, then it would be ws://1.2.3.4, where 1.2.3.4 is the IP of the RPi running ZWave JS, but I’m not seeing anything in the HA config that seems to allow for that.

4

When you go to add the integration in HA (at the settings->devices & services → integrations tab) at that point it should ask what the IP:port you want to look for your zwavejs server to be running on.

Do you not see that?

I run my HA on Docker so I don’t use “localhost” and instead use the IP of the docker host.

5

Thanks - I found that, and after some tinkering, I managed to get it to work more or less on my test install. But unfortunately, unless I’m missing something (which is possible), it doesn’t seem possible to change the ‘Server URL’, probably due to this being a ‘Home Assistant OS’ install (I assume). In addition to that, it seems like ZWave JS and ZWave JS UI conflict with each other. When both were installed, there were issues with HA communicating with it, with just ZWave JS UI installed, HA failed to configure it, with just ZWave JS installed, HA had no issues configuring it. After configuring HA with only ZWave JS installed, and then installing ZWave JS UI, ZWave JS UI refused to connect to the ZWave device, I’d assume because ZWave JS was running and attached. This assumption is backed up by the fact that when I stop ZWave JS and restart ZWave JS UI, UI can now see the stick, but then HA is broken. It is interesting to note that the ZWave JS uses the ‘by ID’ reference, but ZWave JS UI uses the actual serial port.

Now, in my use case, if I can ever get ZWave JS UI working on a RPi running Rasbian, no Home Assistant, and pointing HA to it, that may not matter, but it seems like ZWave JS UI simply doesn’t work as installed on a HA OS installation - only the ZWave JS seems to work right.

I had also had the thought of maybe I could point my existing HA install to the temp one using the ws://IP_of_device:3000, so the ‘temp’ one could act as a bridge until I figure out how to get ZWave JS UI working on a regular Debian install, if I ever do, but it seems that it’s containerized as I saw a message about a 172.30.33.x address, which is not one of my networks, so it must be something internal to the HA install.

6

There’s a lot there so I’ll try to help at least a bit…

Pretty much everything you are seeing is completely dependent on the install method.

Where is this “server URL” you are trying to change? I don’t see that anywhere.

Yes, your guess is correct.

you can have only one zwavejs server communicating with the stick at a time. Whichever server connects to it first that’s the one that locks it out of the others.

I’m not exactly sure what you mean by “configure it” but Zwavejs UI is different that Zwavejs in that the former is a third party add-on and the latter is the official add-on so the Supervisor has more control over that one. On the former you need to do the configuration yourself either in the zwavejs UI that the add-on provides or maybe thru the add-on configuration page in HA itself.

You can (likely) also set zwavejs UI to use the by-id as well.

I personally set up udev rules to persist the dev id of my stick. But I don’t think you have that availability in HA OS.

It’s ironic that you railed so strongly against using Docker for running HA because every install method of HA besides the HA Core install uses Docker. Either explicitly in the case of HA Container or in the background in the case of HA OS or HA Supervised.

So even if you don’t know it you are using Docker in all of those instances.

And HA itself, the Supervisor, all of the supporting stuff (DNS, Audio, etc) and all add-ons are literally just individual docker containers maintained and controlled via the Supervisor.

In order to do that the easiest and most maintainable way would be to just abandon your refusal to use Docker and set up the Zwavejs-UI (formerly known as zwavejs2mqtt) stand-alone docker container.

It’s what I use but it just so happens to reside on the same host as my HA Container. But you can install it on any Docker host on any machine on your network.

The only alernative is to run your own Zwavejs Server install on your bare metal machine. It’s doable if you have good Linux knowledge but most don’t recommend it. Docker is just so much easier.

7

Thanks, I’ll take this and see where I can go. Right now the RPi that I have the test instance running on is powered off and I’m not home, so I can’t grab a clip of the ‘Server URL’, but it was something like ws://zwave-js-core:3000 I believe, with no way to change it that I could find.

Like I said, personally, I don’t like Docker. I’ve found it more of a pain to work with than installing things on a base linux install, and it doesn’t seem to me like it really provides a massive benefit. I’m FAR from a linux expert, but I’ve gotten a number of things working on base linux installs with less head scratching and headaches than docker has given me. Unfortunately, I’m probably going to be forced to navigate that quagmire if I’m going to get ZWave JS or ZWave JS UI installed and working on a RPi. I’d rather have it running on a base linux install, but ‘how-tos’ for that are slim - I haven’t found something that I’ve been able to get working. The thing is Docker is the ‘new hotness bandwagon’ that EVERYONE is jumping on, and ‘old school’ ways of doing things are becoming more difficult to find. The thing about the HA OS using docker is I don’t have to navigate that mess - It’s all done behind the scenes and it just works.

I don’t know where I’m going to go with HA. Right now my main goal is migrating to ZWaveJS or ZWaveJS UI on a RPi in the place of the USB-IP setup I have as the ZWaveJS seems like it would be FAR more robust and error tolerant than the USB-IP - USB-IP is so sensitive, before I added a second power supply to my switch, any time my UPS kicked over to battery, even though the switch never went down, the RPi flaked and HA’s communication to it was broken until I rebooted the Pi and the HA VM. If I do choose to migrate to the HA OS or one of the other newer methods, the problem is there doesn’t seem to be a way to migrate easily from my old install that has been in use for YEARS and upgraded time after time to the ‘new way’. In the past, when I moved to a newer OS, I could just back up all the YAML files and after installing HA on the new system with all the prerequisites, shut down HA and upload the backed up files to the new machine and I was back in business with not much trouble. Migrating from the ‘old way’ to the ‘new way’ doesn’t seem to be as easy. But I’ll cross that bridge when I get to it. Right now, I want to focus on migrating from OpenZWave and the USB-IP setup to ZWave JS.