Best practices setting up big z-wave network

Currently I’m running all my z-wave devices on a HomeCenter 2. I’ve been using it for quite some year’s but never loved it. Next to it I run home-assistant (which I do like) but I never connected the two.

In about 2 months I will move to a new house, so it will mean I have to start from scratch (or at least regarding home automation). All devices will be moved to the new house but probably will get new roles.

My setup:
65+ z-wave devices
hass.io running in docker (in a VM on proxmox, SSD, i5, 32GB ram)
A lot of other “smart stuff”

Ideally home assistant is setup as light weight as possible just doing overall orchestration, basically all sub-systems work autonomous. For example light switches should still work if HA is down, schedule of lawn mower is still running…,.

For the Z-wave part I see a couple of options:

  • Running Z-wave on HA “master”
    (+) simple setup
    (-) slow starts of home assistant
    (-) doesn’t feel stable in big z-wave networks (gut feeling based on forum topics)
  • Introduce a HA “slave” publishing over MQTT
    (+) offload HA, faster starts
    (+) ability of bringing z-wave dongle closer to devices (server is in basement)
    (+) possiblity to use events in a “development” HA environment
    (-) more complex setup
    (-) haven’t read a succes story yet.
  • Keep using HomeCenter 2.0 and the “new” integration with HA
    (+) HomeCenter’s z-wave network did appear to be “stable”
    (+) offload HA, faster starts
    (+) ability of bringing z-wave dongle closer to devices (server is in basement)
    (+) possibility to use events in a “development” HA environment
    (-) additional device in network
    (-) fairly new addition to HA
  • buy another Z-wave controller (VeraPlus)
    (+) It seems to work stable according to some forum topics (only the VeraPlus)
    (+) offload HA
    (+) ability of bringing z-wave dongle closer to devices (server is in basement)
    (+) possibility to use events in a “development” HA environment
    (-) buy new device (which isn’t a big problem)

Requirements:

  • fast config reloads, I will do quite active development (especially in the beginning) so I don’t want to be annoyed with really slow reboots.
  • z-wave network shouldn’t influence the performance of HA (bringing down’t other smart devices)
  • stable

So I’m curious about your advice / experience regarding bigger Z-wave networks.

As a data point, I have a 50+ device z-wave network running under home Assistant for about a year now (moved from SmartThings). It’s been perfectly stable and I have had no issues with it. I run HA in docker on an Intel NUC running Ubuntu. That server also runs mu Plex media server and a few other server-y things. I have about 10 containers running in total. I use the HUSBZB-1 z-wave/zigbee combo stick, although I don’t use the zigbee portion for anything at the moment.

I’m not sure why you think “offloading HA” is a plus in any of your assessments - HA takes almost no computational power (it’s made to run on a Raspberry Pi). The slow starts for z-wave is just the z-wave network - not HA itself. HA restarts for me in about 10-15s. It’s just that it’s about 3-4 min until the z-wave network is ready (you can still do other stuff in HA, it’s just that z-wave devices will be unresponsive until the network is ready). So unless you are doing active development where you’re requiring the z-wave network it’s not annoying.

BTW, if you watch the logs for z-wave during startup, it’s actually polling each device and asking for the neighbors lists, etc. It seems to do this with each device serially and hence even if it only is a few seconds for each device, with a 50+ device network, it takes a few min to get through it. This might be a quirk of the Open Z-Wave platform. It would be neat if it could remember the network across restarts and assume it’s all still there.

Good news: you should also be aware that it’s possible to have HA reload your automations without needing a reboot - that helps a lot when trying to get those working.

Also as to your second bullet - when I was transitioning my stuff from SmartThings to HA, I ran a SmartThings-MQTT bridge. So I would add the devices as MQTT devices to HA and then as I moved them over I would remove the MQTT device from HA and use the Z-Wave device. As you pointed out here the major con is that now you have to maintain essentially two copies of every device - one in the original system and one as an MQTT device in HA. Since you have the ability to start fresh, I’d just switch.

1 Like

Hi,

[Caveat: all the below assumes no devices that need to be polled. That significantly limits the zwave network performance if you want reasonable polling intervals. Only a few old devices still require this so if you are starting new just make sure to avoid such devices. Typically if zwave-plus you are ok. Also zwave; with a lot of devices you WILL notice better performance on a faster machine. This seems counter-intuitive with what I say below; but it was a drastic difference between rPI3 and a NUC for me.]

Above about 100 devices it gets challenging if you have a “busy” z-wave network. What I mean by busy is a lot of complex automations that tend to occur at the same time; for example when people come home you have zwave door sensors, pir sensors, locks, and want lights to come on. You can notice a definite lag.

Remember all the commands to/from the zwave network need to be serialized and with the low bandwidth of Zwave it can add latency.

For this reason at around 120 devices in my case Zwave became unusable. I had challenges with instant status updates being slow/missed, commands being delayed, sensors not updating promptly, etc, etc.

As HA doesn’t support multiple zwave networks at this time I decided it was time to get a second network running to get more capacity.

To achieve this I moved all my light switches from Zwave+ to Lutron Caseta. This worked really well; as using the Caseta PRO or RA2 Select hub with local telnet access it is instantaneous. It also freed up Zwave network capacity for my sensors and locks; which is about 50 devices in total.

That change has really dramatically transformed how HA responsiveness. Going from an rPI3 to NUC was a big change; and this was equally as big.

So what I would STRONGLY suggest is plan multiple networks to spread the communications around to get more capacity; as on a big busy system it’s critical. Maybe with the planned zwave changes we will get multiple networks supported in the future which would achieve the same.

Hope this helps.

3 Likes

Before moving anything, I suggest you take a look at what devices you have and if they are supported by OpenZwave. http://www.openzwave.com/device-database

Cheers

Thanks for your input, it addresses most of my concerns.

Based on this my plan is:

  • Move everything to HA (“master”)

  • figure out which devices require polling, and try to avoid them in my network.

  • check if I can stick to z-wave plus devices (probably will require me to replace a couple devices which could be costly).

  • setup group (so for lights “turn on lights” command only has to be send once).

  • Do HA development on a separate HA environment without all Z-wave devices.

Questions:
Is polling something you enable explicitly?
The impact of mixing z-wave and z-wave plus device still isn’t really clear to me. Someone has a good read on this?

I’d not replace Zwave devices unless they require polling; and then you need to decide if polling is ok. If you set polling to 60 seconds or something it is not a huge load for a few devices; but the downside is updates are slow. If on the other hand you can deal with slow updates on those devices no need to replace them.

But for any new purchases for Zwave Plus.