Soooooooo after more testing, I found a few more things
Location REALLY matters (and network heal works): after moving the pi to the office again, healing network and re-running scenes using various methods (HA script, HA scene, node red logic), the delays were pretty bad again. So it must be when in office, the direct connections to the hub drop so everything is being funneled through 1 node. When I moved Pi back to kitchen and ran network heal, and then re-ran same tests, everything was noticeably faster.
The fastest way to complete my scene (turning OFF 1 light, turning ON 4 lights) was using the following node red logic below. Since HA cant multicast, having those waits in there really make a difference and actually perform the scene faster than if I take those wait nodes out. Also tried one service call node turning on all the lights and one more to turn off the 1 light. Tried same as below but removed the waits. Tried running a HA script. Tried running a HA scene.
Heres video off the ‘OFF’ scene and the ‘ON’ scene. The lights that turn off last in the OFF scene are 2 wyze smart bulbs that must go through cloud, so that was the slightly longer delay there.
Just another suggestion that could add small confounding factors. I had a similar issue with slow zwave (mine was solved by adding non secure as was already talked about here). However, I also noticed there was a LOT of traffic still happening after the scene, so sometimes I would test something, then if I didn’t wait a full minute or so, the next time I ran whatever command I was running, it would be slower due to HA still doing some zwave status updating. So make sure when troubleshooting to give enough time in between test cases for everything to really reset.
If you are using the OpenZwave beta component (or OZW 1.6), you could try adding the following lines to your lzw31-sn.xml config file to see if it helps:
Once updated, you would need to refresh node info on each of your switches. This should cut the amount of zwave traffic significantly by preventing OZW from requesting an update every time it sends a command.
@jtronicus i had to go back to OZW 1.4. With 1.6, if I had to restart the add on for any reason, it was a crapshoot as to whether it would load or not. Apparently its some known issue with how much data the USB transfers or something?? I dunno, over my head.
Went back to 1.4 and will deal with the service restarting everytime I restart home assistant; until 1.6 comes out of beta stages.
I have 29 zwave devices (mostly inovelli gen1) and don’t see the issues you are talking about.
I am running 1.6 beta with zwave.me dongle via USB pass through on a NAS based VM.
Now zwave.me is basically an oem silicon labs usb stick so they run much newer zwave fw than the Aeotec does.
You could try checking under 1.6 in the ozw admin to see what you packet stats are etc. to get a feel of issues or not. As for secure pairing, shouldn’t that depend on the dongle used more than HA? You might also want to hit the JA discord zwave sub forum. They have big zwave brains there too.
@stu1811 I have a Ryzen based QNAP NAS which runs a “branded” version of basically Libvirt/QEMU. I am then running USB pass-through for the Z-Wave dongle “into” the VM so it is visible to HA.
The only thing I had to “tweak” was making sure to use the USB Serial device ID (Supervisor > HW) as the OZW Add-on Serial address. That way if the host VM’s USB port changes, HA has a stable configuration.
Thanks for the info. I have experience with virtual box and xen. HA isn’t that demanding, right? Some people run it on a RPI. I have an older i5 I’d like to use.
I ran HA off a 4yr old i5 in virtualbox without issues as far as processing, etc. But switched to the RPI as mentioned above because of z wave placement.
the i5 virtualbox was definitely faster than the RPI4.
I think as for as demanding goes, it all depends on what other add ons, integrations you have running.
How much data logging are you going to do/keep and are you looking to keep that on the HA deployment itself or in a separate influxdb/etc?
Do you want HASSOS (and the great add-on store) or just basic HA (i.e. Docker deployment)?
If you want HASSOS, then you are either going with one of the RPi’s, NUCs, etc. deployments that have prebuilt images OR a VM. There are other ways to deploy but those are the easiest.
Now the RPI flavors can have the issue around wearing out the SD card. I don’t recall if they have enabled leveraging say USB SSD on the new RPI4’s builds etc. for data storage. Another option the RPI builds is pointing to an externally hosted DB (MariaDB, InfluxDB, etc.) which will help minimize SD wear out as well. The downside is there are some x86 specific HASS Addons that you won’t be able to run.
If you go with say Intel NUC then you can work around most of those limitations and still leverage a USB dongle.
I went the VM route on my NAS (Virtualbox works well too). I am probably the worst-case deployment example for z-wave placement. I have my NAS in a server rack (with door) sitting in my utility room (with HVAC venting/furnace in the basement of my 2 story house.
I did put my USB z-wave dongle on a long USB cable so it is sitting outside of the rack (laying on top of it). I still get very good z-wave response times. That will partly depend on who’s z-wave dongle you are using.
As for resources, I have a 2x4GB VM w/32GB (might be 64GB) storage. Go over-sized on the storage as it is a PIA to try and re-size after deployment for HASSOS version. During initial HASSOS deployment, it will resize the image to use all the storage available, but ONLY during the initial install. If you outgrow, you are doing the full config backup, new VM, restore/etc. dance.
@PaulT I currently have a ST v3 with a zwave.me stick for updating. I have a ubtuntu server in my utlity closet running zoneminder for my security cameras. I believe the server is 2x4GB RAM with a 500GB boot and 14TB data drive. With ST I don’t use any logging really. I only enable temporarily enable logging when adding new features.
I was thinking HASSOS. I heard about the RPI and SD card issue and that’s why I was leaning towards a VM. I have 20-25 zwave devices spread out around the house and most of the them are powered (meaning they are repeaters too). My ST hub is on the 1st floor above the server and I don’t have any out of range issues right now.
Good to know about the potential storage resize issues. I have plenty of capacity to allocate to the VM, so I could give it 100GB and call it a day.
I’ll just throw out that I did a full conversion of my zwave from ST to HASS.IO as a Linux VM on my unraid server (no docker for hassio, only HASS core to the best of my understanding). I have Node-Red, OZW (beta) among other items working FLAWLESSLY. My USB stick is behind my Dell R510 server in a basement encased with concrete, but I have mains powered devices above it within 15-20ft. It works great.
Only thing I haven’t figured out is Z-Wave Associations within OZW. Otherwise I am at parity in features and significantly improved performance over ST.
I believe I dedicated 30G, 4GB RAM, and 2 cores (4 with HT) on my xeons. I’m sure it could do with less, but I had it to spare. Boots in about 1:30 with over 200 devices (lots of integrations+ zigbee still on ST which works really quickly now), ~30 z-wave.
I need to figure out associations before making the jump. I have a bunch of switch outlets where both plugs are switched instead of just one. Use the association to turn the light on/off and keep constant power to the outlet. It was easier to setup the association than run an extra wire to the outlet.
What exactly do you mean by figure out associations? Do you mean you need more information on how to know what to associate to what? Or are you just saying you don’t know how to configure the associations in home assistant?
As an example, I have two light switches that both control different lights in the basement. I was able to set up associations so that if I press either switch both sets of lights turn on or both sets of lights turn off. Is that kind of what you’re looking to do too?
Agreed, I have not broached nor do I know how to associate components in HA via OZW (beta) and Mosquitto. Right now everything goes back to the hub which is plenty quick (not even truly noticeable, like 270ms) but I’m sure direct association would be even better/faster.
