I have a simple RM rule to set 5 lights in my living area (3 off, 1 on, 1 on at 20%). All the switches are zwave. I rebooted the hub, disabled the Zwave for 5+ minutes, then ran Zwave repair.
When I run the actions on the rule, the first couple of lights respond quickly, but the last couple are slow. It can be between 5 and 10 seconds for all 5 to respond. All 5 switches are within 25 feet of the hub, straight line of sight, no walls in the way. Am I being unreasonable to think that this shouldn't take more than a second or two? And logs sometimes show more than 1 "off" response from the last switch or two.
The speed (or lack thereof) is the same if I use a "scene" (Groups and Scenes app). In case it matters, the 4 switches are ZooZ ZEN26s and the dimmer is a ZooZ ZEN22, all with their Central Scene driver, I have a C-5 hub, and it is running the latest firmware (2.1.7.127)
Is Z-Wave slow? That depends on who you ask and what the scenario is and what the comparison is against.
My answer. No and Yes.
No Z-Wave is not slow in a controller to device scenario. A single command to a device is quite fast.
But... Z-Wave is serial so if you string a bunch of commands to multiple devices together... well then it's slow because each command must be sent AND acknowledged before it moves on to the next command. This visually is slow. Which is why I don't use Z-Wave for lighting groups.
So maybe I should be thinking of switching to zigbee for, well, pretty much everything. The zigbee motion sensors I got are certainly much quicker than the zwave ones I had. Or maybe take a look at lutron for my lights if I can swallow the cost.
Zigbee sensors in general are faster than Z-Wave. It's not a protocol speed it's a wakeup timing. Zigbee sensors generally don't "deep sleep" like Z-Wave so they respond MUCH faster and still have better battery life. I agree Zigbee for sensors is great.
Opinion alert....
Pecking order for lighting (switch/dimmer not lamp)
Lutron RadioRa2
Control4 (Custom Zigbee) most C4 installs use RA2 though
Insteon
Lutron Caseta
Some will say Caseta over Insteon again mostly opinion oriented. Insteon switches/dimmer/ballasts are far more configurable than the Caseta products but Caseta is cheaper and easier to work with.... I said opinion people!!! sheesh!
Notice I did not include Z-Wave or Zigbee in my list. Neither are actually a "lighting" technology but they have different "roots". Z-Wave is more of a "do everything" DIY technology and has lots and lots of devices and switches, dimmers, sensors, etc etc... do it all. Zigbee has a history of sensors and has became very popular with Lamps (light bulbs) and consumer sensors and now switches and other devices are more and more in the Home environment as ZHA has matured and is being adopted.
The big problem I see between choices of z-wave and zigbee is whatever you choose you need enough powered devices to create a "mesh" for your sensors to function properly. So if you go all in ZigBee for switches/dimmers/plugs etc that's great for the sensor network. Now do all of those devices play nicely together is another "issue" and sometimes they don't.....
Most end up with a mashup of z-wave and zigbee and different devices and types and trying to find what works well together and what doesn't.
Yes this is unreasonable. What everyone else said is interesting and all, but it does not take 5-10 to control a couple devices. I control a dozen lights in the house, and I have a simple group to shut them all off, and they're off in a couple seconds.
I would look at your RM rules and how it's working. A simple solution is to set what you want as a scene and just activate the scene and see how fast it takes.
I also agree that such response is not acceptable, and must be investigated.
Something is wrong...
My first stop would be to install the hub watchdog app (zwave flavor), and give it a day or two to see what the response time is.
My second stop would be to start looking closely at the logs (and to turn on the logging of several devices/apps/etc.)
It's frustrating that it takes time and effort to chase these things down. Unfortunately, I know of no other approach to get to the bottom of these issues.
Just a note, based on your subsequent note of preference for RadioRA 2: Lutron lights, RadioRA 2 or Caséta, also are serially controlled (at least transmit) in 3rd party control systems like Hubitat. Hubitat must issue individual device Telnet commands to the Main Repeater/Bridge that then issue individual commands to the lights. The sequential performance is probably faster than Z-Wave, but it's still frequently noticeable.
There is a use case where even Lutron devices can perform unacceptably (multiple second delays) - when controlled by a Pico that is programmed in a 3rd party system. The path is Pico→Main Repeater/Bridge→Hubitat→Main Repeater/Bridge→Dimmer/Switch. I'm not a radio communications expert, but Picos are transmit only devices and this path causes some blockages that can seriously degrade performance.
The fix for any of these performance issues to put the Lutron dimmers/switches in scenes on the Main Repeater/Bridge (or a RadioRA 2 keypad) and then call the Lutron scenes from Hubitat. (They're represented as buttons in Hubitat.) The button pushes can even be part of Hubitat scenes. Hubitat issues a single Telnet command and then the Lutron Main Repeater/Bridge controls the lights in parallel with no delays/popcorning.
This is valid that running even a Lutron RA2 system through a 3rd party can cause a delay but it is very dependent on the implementation of the 3rd party and how your RA2 system is defined and used. Your Pico example is a prime example of poor implementation/design and will result in poor performance.
The same implementation and design holds true for Insteon or other lighting where the technology has native remotes and actual real Scene or Group capabilities. Control the device, scene, groups directly and not through 3rd party.
The ability to use Pico or remotes within HE to control "other" devices is nice but mixing it for a lighting control will result in poor results.
This is questionable. It's not the Lutron system having the delay...
Well, not exactly. You can issue a bunch SET in a row, for instance, and it just blasts them out... The hub doesn't wait for the report response or anything like that. That's why I can turn on 5 zwave lights in my parlor in <1 second... But I don't have to guess based on light performance, you can see it with a zwave sniffer, too.
Sending commands is about the same be it zwave or zigbee (although slightly faster on zigbee due to it running a higher baud rate than zwave). As you pointed out earlier, there are differences in radio listen/wakeup time, but that is more applicable to battery operated devices. On mains powered devices, sending commands to the device is about the same (if sending serially, and not using something like zigbee groups - which is a different story altogether!),
True... however not many here are going to write their own driver to send a Basic SET directly to devices versus using the driver Probably about the same number that have a z-wave sniffer
But that should hold true for RM rules as well, As far as I can tell when you put a "turn off these 5 devices" in an RM rule action, it just looks through them and blasts the OFF out to them. It doesn't seem wait for an ack or readback.
I will say, though, that RM rules can be a little pokey at times (which is why simple lighting and motion lighting are almost always measurably faster than doing the exact same action in an RM rule).
I've also noticed that mixing ON/OFF with dim commands seems to make it take a little longer than I would expect as well - but I can't see the code, so could only guess as to why.
Interesting. Since my scene was slow, I tried RM. But in an effort to minimize Zwave traffic, I was testing each light to see if it was off first before sending the command. Of course for my test they were all on -- so the commands were serialized. I changed it to just 3 commands: set dimmer 20%, if(pendant lights are off) turn on pendant lights, then turn off the other 3 lights (whether they were on or not). That does seem much faster. The 3 lights I want off seem to be going off in very quick succession, which really was the part bothering me the most.
So it does seem that when sent as individual commands, RM may be waiting for each light to report success before sending the next command. I can see how in some situations this might be the right thing to do. I'll keep an eye on it, but this may be the insight I was looking for.
Are you having an issue with latency?
Is your simple lighting rule or RM rule too slow?
Are you working only on zwave switches?
Do you reboot your hub occasionally?
My question was, does RM wait for device command confirmation before it moves to the next action? If this is the case, then it would make sense why things appear to turn off sequentially.
yes, yes, yes, and yes! I'm sold! what is the solution? I'll pay almost anything. HE just is not able to process rules efficiently. I don't know what changed, by this what from the fast home automation system I have ever used, to so slow Alexa is faster than it.
Right now, at this moment, I downright hate HE. And the worst part is, after several attempts to get help, I think the devs don't care. They ignore my pleas for help.
I would happily pay $200-$300 for a hub with 16GB of RAM and triple the speed. I am convinced these things are over-powered. Or at least, everything going through RM is too darn slow to be useful. I can't stand that every button tap (which registers on the hub immediately) take 3-5 seconds for the rule to execute action, and the device to receive it. independently, everything seems fast, but tie them together in RM, and they crawl.
Probably about the same number that have a z-wave sniffer 
