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):
1 Like
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.
1 Like
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.
1 Like
Hi,
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:
Read that link you posted. Very interesting. Do you know can I install that now? I have an extra raspberry pi laying around. Would be nice to put that Z-Wave implementation on there just to play around and see what it’s like.
No I think it will still take some time before we can install it. It’s still in development.
I’m on the latest versions of both zwave-js and home assistant and seeing the exact issues described here with my new innoveli red dimmers. Individual zwave commands for all devices are instant, but activating a script that turns them all (6 total) on or off will cause delays as described here.
@piiot moving the placement of the z wave controller to a more central location solved the issue, mostly, for me.
Sometimes things are still slow though. Actually just last night, we have a smartbutton on table next to couch. Pressing it 5x will turn off all kitchen lights. Wife pressed it and the lights turned off 1 by 1, with about a 2 sec delay between each.
But overall, its much better than my videos had shown. I just hope they are planning to incorporate multicasting in ZwaveJS. As you can see from my Hubitat video, which has multicasting, how much faster it is.
1 Like
Ah so multicast is still not supported, and that seems to be the main issue. Gotcha. I’m passing my Aeotec usb hub through to a hyper-v VM in a server closet, so I think I’d rather just keep everything consolidated there for now. I do really appreciate all the leg work you’ve done here troubleshooting - as should Inovelli. You deserve some free switches from them imo 
Is this still an ongoing issue? I still run into the same issues, running the very latest version of HA:
Core: core-2021.12.9
Supervisor: supervisor-2021.12.2
OS: Home Assistant OS 7.1
Z-Wave JS: Current version: 0.1.52
Hardware:
-Fibaro Z-wave dimmer 2
-Aeotec Z-Stick Gen5
-Intel NUC i3 (running HA virualized on Proxmox)
I still experience the same issues as described in this post. Did anyone solve those issues yet? Already tried to heal my network, but when I switch 5 lights in my living room at once (light group), the last one can take up to 40 seconds, which is not accetpable.
Can this be resolved by switching to Zwave to MQTT? Can anyone confirm?
Is the multicast feature supported on a Zwave to MQTT platform?
I have a ubuntu server running VM. Z-wave js and 89 devices. I have an automation which turns on my bar in the basement via motion sensor. It activates 8 lights. It all happens within 500ms. It is as fast as the 100&40kbit communication will allow. This automation is my canary in the coal mine. If something is wrong (not very often) then it will be delayed. Usually it is a broken sensor or something I have done to the system. (I had a mimolite on garage door go out Sunday. Automation slowed to about 1-2 sec) I am on home assistant 2021.12.9, Home assistant OS 7.1, and the following addons - Terminal & SSH (9.3.0), Log Viewer (0.12.1), Z-Wave JS (0.1.52), AppDaemon 4 (0.8.0), Check Home Assistant configuration (3.9.0), Samba share (9.5.1). My server is a dual Xeon Supermicro with 32 gb memory and 93 gb virtual disk on 1TB hard drive. I have GE/Jasco and HomeSeer switches and dimmers. My switches and sensors are not added securely. Locks are added securely. I have surge control at main panel and subpanels. I have my USB z-wave dongle (ben 5) on a 15’ USB extension to get it away from my server rack.
Have you tried an automation without the group?
I activate all of my switches by a call service. I don’t know if this makes a difference.
- id: 'XXXXXXXXXXXXX'
alias: Bar Lights - Turn on and off based on stairwell light.
description: Turn on and off all the lights in the bar area
trigger:
- id: 'bar_on'
platform: state
entity_id: binary_sensor.bar_stairwell_motion_sensor_motion
from: 'off'
to: 'on'
- id: 'bar_on'
platform: state
entity_id: binary_sensor.bar_main_motion_sensor_motion
from: 'off'
to: 'on'
- id: 'bar_on'
platform: state
entity_id: switch.stairwell_light
from: 'off'
to: 'on'
- id: 'bar_off'
platform: state
entity_id: binary_sensor.bar_main_motion_sensor_motion
from: 'on'
to: 'off'
for: '00:01:30'
- id: 'bar_off'
platform: state
entity_id: switch.stairwell_light
from: 'on'
to: 'off'
- id: 'bar_off1'
platform: state
entity_id: binary_sensor.bar_stairwell_motion_sensor_motion
from: 'on'
to: 'off'
for: '00:01:30'
condition: []
action:
- choose:
- conditions:
- "{{ trigger.id == 'bar_on' }}"
sequence:
- service: switch.turn_on
target:
entity_id:
- switch.area_cans
- switch.bar_pool_table_light
- switch.rope_lights
- switch.bar_hall_to_media
- switch.bar_landing
- switch.stairwell_light
- service: light.turn_on
target:
entity_id:
- light.bar_pendant_light
- light.bar_back_bar_cans
data:
brightness_pct: 50
- conditions:
- "{{ trigger.id == 'bar_off' }}"
sequence:
- service: switch.turn_off
target:
entity_id:
- switch.area_cans
- switch.bar_pool_table_light
- switch.rope_lights
- switch.bar_hall_to_media
- switch.bar_landing
- switch.stairwell_light
- service: light.turn_off
target:
entity_id:
- light.bar_back_bar_cans
- light.bar_pendant_light
- conditions:
- "{{ trigger.id == 'bar_off1' }}"
- "{{ states('binary_sensor.bar_main_motion_sensor_motion') == 'off' }}"
sequence:
- service: switch.turn_off
target:
entity_id:
- switch.area_cans
- switch.bar_pool_table_light
- switch.rope_lights
- switch.bar_hall_to_media
- switch.bar_landing
- switch.stairwell_light
- service: light.turn_off
target:
entity_id:
- light.bar_back_bar_cans
- light.bar_pendant_light
default: []
mode: single
I did not try an automation, but I did try a script which changes the lights according to the luminance level of an outside sensor. With both (light group or script), I experience the same performance issues.
I also have Zigbee lightbulbs which are not having performance issues at all (I use those in de garden, even further away then the ZWAVE dimmers)
Could be that I’ve added them securely, can try to include them insecure indeed. I was planning to move to Zwave2mqtt anyway (ubuntu on a lxc container), so I’ll give that a try as well.
In the past I added all of my Z-Wave devices secure, when only S0 was supported. My devices do not support S2, so I’ve excluded them and included them again (insecure), and everything seems to be working fine so far with de Home assistand Zwave-JS add-on. Groups and scripts are now responing as fast as my Zigbee devices.