I wonder if there are still some firmware bugs that need to be worked out.
Yeah, I think there are still issues.
What device? I had some of the honeywell switches they sell at Costco. Those are S2 and I had no trouble adding them at all. (I got rid of them because their definition of "instant status" was "5 second delay".)
What was that all about? Kinda interested, since I have a ton of the GE variants.
Not really true. I have two of them on my dev system, and I assure you they update much, much faster than 5s.
Wish I knew. But I noticed my automations were taking 2-5 seconds to trigger. I cross referenced with the event history and found that the switch events were about 2-5 seconds after I pressed the paddle.
I had a few of the Leviton switches and those report their events within 500ms, usually faster. Now I don't have anything but Leviton.
I had 3. Couldn't get faster than 2s out of any of them.
2s isn't 5s.
And even then it depends on WHAT reporting you are talking about. If you are talking about ON/OFF they don't report until the fade time is complete (because it isn't REALLY off/on until it gets to its final brightness).
I will say, though, that all of the new Jasco devices report on/off slower (like 1s) as they wait a tick to make sure you are doing a single tap instead of a double or triple tap.
Most other commands should be faster.
@JasonJoel Any thoughts on response times (taking actions from the hub or reporting back) and how those are affected by the S2 security settings?
Thanks
It's not 200-500ms either, which is what I get out of all my other devices.
I am, and they weren't dimmers, so fade time wasn't the issue. I was surprised because people on these forums seem to love those devices. I just didn't have the same experience.
I've tested both ways. Same (within repeatability of the data anyway) non-secure or S2.
Not devices that support multiple presses on the same button / scene controllers... They all have to wait some period of time to figure out if you are doing single or multi taps.
I will say that all scene controller based devices are slower to report physical button presses than non-scene controller devices though. That is just the nature of the beast.
There are separate events for on/off and double tap. I timed the delay from when the light turned on until the hub got the event, specifically to rule that out.
If it can figure out to turn the light on, then it can send the "on" event when it does. It didn't.
Hmm. Dang, then. So much for my thoughts there.
I really seem to have a LOT of very sluggish behavior. I spread my "all on/all off" events over 1-2 minutes (40-50 devices) with refreshes to try to make things work--and they still don't.
I was running the "Hub Watchdog" during one of those and it reported 5-25 second delays (and lost events).
This morning, my "mostly all on" event left 2 lights out--and only 2 of my 7 LED strips on my Inovelli dimmers got updated properly.
Something really seems to be hosing things up somehow.
I know exactly what they do/don't do. So I'm not trying to argue with you.
What I'm saying is it is ~1s for a button press on a scene controller, then jasco doesn't send a report back until dimming on/off is complete. So 2s for on/off seems about right.
I get that is not how you wanted them to work though. And that's cool. 
No idea there. I don't have anywhere near that number of devices in any of my scenes.
I have found lots of other "interesting" info sniffing the traffic to the C-7, but I haven't seen any appreciable/repeatable amount of missing commands/events.
That said... It only takes a few bad devices or routes to create a pretty healthy zwave mesh storm.
Any easy way to detect that? (without extra gizmos)?
Nope. Have to sniff the traffic.
Now, Hubitat could expose more of the underlying performance parameters from the hub side to prove it is not the hub dropping the data. But realistically that data isn't meant for, or useful to, non-radio engineers anyway so I appreciate why they don't expose that.
I will say there are other Zwave 700 hubs in the works I've seen that are having pretty interesting issues too... (more issues than Hubitat is seeing - so kudos to Mike & Bryan). Seems like there is a firmware update or two from SiLabs that still needs to happen.
That said, it can and does work as-is for most. My C-7 hub is running quite well right now. It can just be unpredictable/temperamental in some situations.
Some "diagnostic add-ins" would be nice on the Hubitat. 
That's super interesting to hear. And promising?? I mean--SiLabs will hopefully have to address that kinda stuff.
I just wish I knew what was going on. I may have to get a sniffer of some sort--but, dang, that's getting in way deeper that I was hoping. Reading SiLabs standards is not for the faint of heart.
Sniffers aren't hard to set up... But the real trick is that if you are trying to troubleshoot hub traffic, the sniffer needs to physically be by the hub too. That isn't always very convenient.
But, yeah, I expect that SiLabs will keep improving things (although they are slow to release firmware updates in general). And I'm sure the Hubitat team will keep identifying ways to work around some of the SiLabs quirks, too.
Unfortunately, that is what end manufacturers have to do - work around quirks, as they will never ship a product if they wait for the manufacturer to fix their API/SDK/firmware.
Download the Hubitat app
