Could it be an issue with the USB driver in the VM having trouble communicating with the z stick ? Anyway, I’m just randomly thinking, so that’s probably not much help, sorry. Maybe post this in the zwave section, there are some zwave pros in there
Do you do your scripts as action type device or call service? Both turn a light off, but does it matter?
Well doesnt matter, tried it with action type as device and service, same random speed. Anywhere from 4 sec to 28 sec to turn 4 lights OFF and 1 light ON.
- Living room overhead lights off
- Kitchen overhead lights off
- Kitchen island lights off
- Kitchen table lights off
- Kitchen sink light on
And its not replicatable.
First time I do it, it may go 1,2,3…4,5.
Next time it may be 1…2,3,…4…5
Next time it may be 1,2,3,4,…5
Or if Im lucky, 1,2,3,4,5.
I got an old Pi 3 B laying around, I may have to set it up just to see if it is the VM thats causing issues. But i dont think it is, cause I can sit there and toggle a light on & off, and it never hesitates.
Because a video is worth a thousand words, here it is. https://youtu.be/ujUJ03qaYC4
See timeline below. Here is legend of the names.
This is on brand new install on a RPI 3. 5 inovelli dimmers, all updated to 1.48 firmware. Nortek Z wave stick.
00 sec: Turn on script
03 sec: Table, island, and living room ovehead turn on almost all at same time
16 sec: Kitchen overhead turn on
21 sec: Sink turns off
So 21 seconds to do 5 things. But i can wait a few minutes, try it again and it may be lighting quick!
There used to be a log for zwave. Does that still exist?
You can inspect it for devices spamming the network or repeatedly failed messages.
Also there are utilities available to map your zwave mesh that may be useful to spot any problems. Though looking at that picture everything seems to be in the one room so I doubt that is an issue.
Yeah, this is not normal. Have you tried including the device non-secure? That is usually faster …
@tom_l Yes there is a log and I’ve been checking it but cant find much in ways in anything that looks like an error. But the data all flashes so quick that I miss a lot of it. I dont know where openzwave saves the entire log, so I am not just limited to the last 20 lines that were transmitted.
@devastator Yes I tried adding all 5 dimmers as secure and then also tried non secure.
Unfortunately, the only Z wave devices I currently have are these dimmers, so I cant plug in 5 other Z wave devices and see if those take just as long to automate. But just as I am typing this, I am ordering 5 Zooz brand Z wave plus switches. Set to arrive Saturday.
Really weird. Even if everything is in one room (and probably close to the controller ?), you could still take a look at the zwave network map, as @tom_l suggested. Just to rule out a routing problem that forces all traffic over one single node or something similar.
Are you using transition effects with the dimmers or is it just a plain on / off ?
Might be unrelated, but I seem to recall that there was a problem with certain configurations of dimmers in OZW. Basically, OZW always issues a state ‘get’ command a fraction of a second after setting the state of a device. Depending on the network routing, load and timing, a node might still be busy and unable respond to the request right away. It then sends a ‘busy, try again’ response, which OZW did not handle correctly. I can’t find the issue on the OZW github anymore though.
In the old OZW integration the log used to be in OZW_Log.txt. Not sure where it is on the new integration.
Are these any mesh mappers available for openzwave beta? Everything I can find is couple years old which means it’s using the older z wave implementation.
I have no idea, sorry. I’m still using the old integration.
Well then it’s back to old z wave on the Pi! Lol
Do you mean a graphical mapper for viewing in a Dashboard? If so, then this one works with OpenZwave (beta):
So I was told that Home Assistant / OZW does not support multicast for Z wave and that could be my issue. I tried pairing the switches to Hubitat again, but following a specific way of pairing and right now I actually increased it to 6 switches ON, 1 OFF and its operating light years better than it was.
So is the core of my issue home assistant? I surely hope not as I really dont want to switch to Hubitat.
But heres a video with the switches paired to hubitat. And theres 3 more lights behind me that you dont see that also get turned on almost instantly.
That’s actually very interesting feedback. In fact, you may be right that the problem is somewhere in OpenZWave. Searching around the forums, it definitely looks like you’re far from alone with these problems. A lot more people than I thought seem to have issues with sometimes very long delays on their zwave switches and dimmers. A lot of people reported that the same devices worked flawlessly on hubs like Smartthings, Hubitat or Fibaro’s HC.
So it really looks like the culprit is OZW here.
I just paired those same switches back to Home Assistant (this time using the OZW beta). You can clearly tell the difference, no 2 lights turn off/on at same time, its all like chain reaction and same issue, sometimes its quick, sometimes its not.
I think IM at the point where I need to either choose Hub or HA (and hope they add multicasting at some point).
I just put in a feature request. Upvote it! Multicasting for Z wave
Soooooooo after more testing, more questions here and at inovelli forums, I found a few out a few more things that got me to the fastest automation I can do at this time. Not as fast as it was on Hubitat C7 (multicasting), but much better than it was.
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. None of those did the automation quicker than the node red flow below. And then below that is a video showing the speed.
I have the same issue as you where lights are turned on in a sequence.
I saw that zwave-js has multicasting :
Maybe this is an option in combination with zwavejs2mqtt
@Thoolman that kinda seems over my head (less than 6 months into this home automation stuff). I cant even see how I install it into HA.
Have you tried it?
No, I haven’t for the same reason as you that it’s also out of my league.
I came across it in another topic while doing some research on the slow Z-wave issue and hoped that maybe you could tie it together.
I’ll guess we’ll just have to wait until it gets fixed in the default integrations.
Looks like there are some developments: