Using multiple Z-Wave sticks to extend coverage

Configuration Z-Wave
1

As I posted many times in the past, my Z-wave struggle mightily due to the very large home and building materials. Most edge devices depend on 3 or 4 hops, and are just unreliable, especially battery-powered devices.

I experimented with ser2net and a Raspberry Pi 3B+ on Wifi, to move my ZST39 stick to a more central location. This helped somewhat, but did not fully resolve the reliability problem.

I believe I can only resolve it with multiple Z-Wave sticks simultaneously, on separate networks.

I believe I could setup my ZST10 with Z-Wave JS, and leave my ZST39 on Z-Wave JS UI, as I currently do. And have either one be remote with ser2net.

However, I’m planning on adding perhaps 50-60 Z-wave nodes to the existing 70, if I can fix the reliability and coverage issue. Most of the new devices would be 800 series with SmartStart support.

As far as I can tell, you can only use SmartStart in Z-Wave JS UI, but not in standalone Z-Wave JS.

And if I understand correctly, Z-Wave JS UI currently only supports only a single Z-Wave stick.

Are there any plans to add support for multiple sticks in Z-Wave JS UI, so I could use SmartStart with both ?

The other alternative would be for me to give up on Z-Wave altogether, and replace the existing 70 nodes.

I have Yolink too, and it has been much more reliable than both Z-Wave and Z-Wave LR in my home.

The main downside with Yolink has been the app & cloud dependency, for both initial setup and operation.

I received a Yolink local hub today, to replace my existing one. I have not set it up yet. My understanding is that it still requires a cloud account and app for the initial device setup, but afterwards, it should function with HA in local mode. I will certainly test that by blocking the local Yolink hub from Internet in pfSense. But it still won’t be as good as Z-Wave, which has no app or cloud dependency for setup. The app & cloud requirement for setup are still a built-in time bomb, same as for most IOT devices, like the Wemo announcement today.

Yolink also has a much smaller subset of devices than Z-Wave, as there is only one manufacturer for them. But their motion sensor works great in my metal, and on my kitchen counter that don’t have light switches on every side. Whereas the Z-Wave battery devices I have tried just don’t work at all in the mailbox, or reliably on the counter.

The Yolink door sensors range is a bit too short. I have not yet experimented with alternate magnets yet. Perhaps it’s possible to improve.

The batteries for the Yolink temperature sensors and door sensors also don’t last long in enough the fridge & freezers. If the door sensors had longer range, I could put them on the outside rather than inside. Not sure if anyone makes battery powered temperature sensors that will last in freezers, and with which battery chemistry. The Yolink take AAAs, which gives a choice. Alkalines basically don’t work in freezers. Eneloops work somewhat, for a few weeks or months. But not years.

2

I’m using Z-Wave-JS UI running directly on multiple RPi 3+ devices. This works well as the Z-Wave Integration supports multiple instances. There are several guides on this forum on how to install Z-Wave-JS UI on the Pi.

You lose the notifications of Z-Wave-JS UI updates and simple one-click upgrades, but it’s a simple docker compose command on the Pi to update the container as new versions are released.

YMMV.

3

I didn’t read your entire post, but just FYI, I use one of these for a secondary z-wave hub:

https://tubeszb.com/

The POE makes it quite handy to power.

That’s true. But you can run another instance of it.

The three ways I know to run multiple hubs with zui are:

  1. Run a completely separate container somewhere.
  2. Run a second zui add-on using a local add-on config. This is what I do with HAOS.
  3. I haven’t tried it, but adding a new add-on repository and spoof the the URL (e.g. add a trailing slash) to make HA think it’s a different add-on.
4

Two separate controllers is the complicated way to extend coverage — usually adding routing nodes is easier. But maybe we’re talking about a very large dead area where no coverage is necessary, so a second “island” of zwave makes sense. Problem then is that, over longer distances, ser2net can be unpredictable if latency or jitter increase, and you’ll keep dropping your fragile “serial” connection to the stick.

Your scenario might be a good case for using a Raspberry Pi Zero 2 with the Zooz ZAC93 controller hat — it just sits right on the top pins and the total cost is under $40. You install Ubuntu and Docker on it, and run ZUI container so that all the comms between it and HA are less latency-sensitive websockets (as opposed to highly latency-sensitive ser2net).

Or if your IP network is very reliable (i.e. wired) then ser2net should work ok, and the tubeszb controller (or WT32-ETH01 with ZAC93 running esphome you can DIY!) is a good fit. Unfortunately HAOS isn’t amenable to running a second add-on, so unless you use one of the workarounds above, a docker HA + 2xZUI install would be a more flexible approach. I’ve run two ZUI containers for years, with one usb connected and the other ser2net connected, with no issues (I only use the ser2net instance for testing though).

1 Like
5

Thanks. I like the idea of PoE, but since I have no Ethernet between rooms, it is not applicable, unfortunately.

Thank you.

Can you please explain how I could do option #2 ?

My goal would be to run 2 or 3 instances of the ZUI add-on, with one local stick, and one or two remote sticks on Pis using ser2net.

6

No, there is no large dead area with no coverage required. The 70 nodes are roughly evenly distributed between 16 rooms across 2.5 floors. All devices are indoor.
The HAOS VM runs on a desktop in my home office, with a ZST39 stick. The home office is in an edge location, on the first floor by the front door. There is ethernet only to one adjacent room, the home theater.

Thanks. I will consider that. Is there any reason it has to be the Pi Zero 2 to install the ZAC93 board ? I am asking because I already have two spare Raspberry Pi 3B+ . Zooz does not list which Pi boards the ZAC93 is compatible with.

One secondary problem is the look of the devices. Installing GPIO boards generally means you can’t put the Pi board inside a case. It would also get in the way of the Z-wave signal even if you could. I already have industrial cases for my two Pi 3B+, and they don’t allow for install GPIO. Thus, my preference for using plug-in USB sticks instead, especially the ZST10 I already own.

There is no Ethernet except in two adjacent rooms, unfortunately. Even the Wifi APs are meshed, and they have to use 3 mesh hops as well in order to provide full coverage with acceptable signal strength. This is the mesh topology. Office and Home theater are the wired ones - all other AP links are mesh.

image
image1493Ă—788 39.5 KB

“reliable” is not the first word that comes to mind to describe this network. The main problem is that clients keep roaming between APs, often going to distant ones. That would continue, even if all APs were wired. The latency is obviously higher when going through 3 mesh hops, but still normally remains under 10ms from wired systems to any of the APs regardless of mesh count. The main problems is what happens when some APs reboot, update firmware, or if there is a power loss. It can take a good 5-10 minutes for the mesh network to fully stabilize and honor the configured mesh priorities, and also for the 300+ clients to stop overwhelming one the two wired APs that come online before the mesh APs. If all 9 APs were wired, they would all come online at approximately the same time, in under 3 minutes, without a need for a specific order, and this would be much less of a problem. The cost to fully wire all APs runs in the high 4 to low 5 figures. I would like to improve the Z-wave coverage for a little bit less than that. I know it won’t be perfect, as any remote Raspberry Pi will have to run on Wifi, not Ethernet. But the main use case for Z-wave in my home is lighting. I use the ZEN76 switches in smart bulb mode, with the relay always on. And I use them as scene controllers. HA then turns the bulbs on or off, or dims them, or a different color, in response to Z-wave commands. If the Wifi is down, the bulbs won’t operate, even if Z-wave was 100% reliable from the one stick currently connected directly to the VM hosted on a wired system. Relying on Wifi for Z-wave itself means there is an additional dependency. But ultimately, both the Wifi and Z-wave need to work. If either fails, the lights aren’t going to turn on or off when the switches / scene controllers are pressed. It appears that the Z-wave is the weak point, currently. I sometimes have to press the switch 5-10 times and wait 30 seconds before a single lightbulb turns on. Other times, one Wifi bulb in a group will come on right after pressing the switch, and the others will follow later. Ie, the so-called “popcorn” effect. The popcorn can last anywhere from 5 seconds to a full minute. Most of this unreliability with the bulbs seems to be related to Wifi bulbs roaming randomly to the wrong AP over time. Even wiring all APs would not solve that.

7

Oh, I’m not sure running a second controller helps that much in that case.

Are you planning on using Wifi mesh or an extender? What I was saying would be good if you have, say, a separate building that has wifi but is too far for z-wave. I use mine for a few outdoor long-range z-wave devices where the controller is away from my main house controller.

Seems like z-wave mesh is your best option on a single controller.

I’m running HAOS which is why I went the extra add-on approach. If you are running HA in a VM I’d probably run a separate container.

Here’s how I set mine up:

8

Only one controller can be connected to a Z-Wave addon at a time. If you want to have multiple Z-Wave networks you will need to setup multiple instances of Z-Wave JS UI. This is very easy to do especially if you use the standalone version of Z-Wave JS UI. The standalone version can run on Windows or Linux. You simply download the zip file from the github page, extract the contents of the zip file, then double click on the zwave-js-ui file to run the program. This works for Windows and Linux.

9

I looked at one of those - using the snapd install version.

Didn’t work. Like - snapd’s core supported devices completely failed to find /dev/ttyS0 or even /dev/ttyAMA0 (if I turned of bluetooth for fun) – took me hours to realize it wasn’t going to work easily/quickly.

I found the easiest way to get zwave-js-ui running on pi (3B and 4) was to just download the compiled binary and put in a folder of choice and then write a systemd support file for starting/stopping it. Took all of 15minutes. Mostly to write the systemd file.

I also ended up using screen to detach the process to keep the colorizing control chars out of /var/log/daemon.log. But that was optional.

I’ll have to write a post here describing what I did w/systemd file I wrote.

10

docker would be much easier

11

I’m looking at the instructions now.

Nope. Not if you don’t already have docker installed and setup.

Downloading the binary zip to a folder unzipping and then making the systemd config file is the easiest and fastest way.