After relocating some zigbee outlets, changing back to the generic z-wave drivers wherever I didn't use double tap, and doing zigbee and z-wave repairs, my times have improved quite a bit and more importantly my automations are noticeably faster.
This is 20 runs of each, and the zigbee is split between an upstairs and downstairs Samsung plug.
1 Like
In the interest of, you know, science, I cleared out my data points and ran a z-wave repair, even though I haven't added anything or moved anything around. And, surprise surprise, my Z-Wave numbers -- which had been all over the place from .4 to 1.4 -- not only improved noticeably, but also stabilized. This is around 20 data points. It will be interesting to see if this continues.
Z-Wave
Mean Delay: 0.471
Median Delay: 0.472
Minimum Delay: 0.436
Maximum Delay: 0.515
Zigbee
Mean Delay: 0.235
Median Delay: 0.215
Minimum Delay: 0.196
Maximum Delay: 0.302
Virtual
Mean Delay: 0.1
Median Delay: 0.081
Minimum Delay: 0.065
Maximum Delay: 0.129
Please explain, I'm interested in anything that will help speed up my hub. Is this a known issue with certain z-wave drivers?
Ideally I would love a way to automatically reboot the hub once a slowdown crossed a specified threshold. I didn't see any way of rebooting the hub from RM, so I'm guessing this is not a possibility, but thoughts??
Could you not use RM to send a HTTP request using:
hub_ip/hub/reboot
1 Like
Here’s an example in RM
1 Like
Perfect, thx!
Well, I discovered that when I ran the tests on a couple GE Z-wave plus dimmers that the times were hovering right around the 1-second mark. I then tried just changing to the generic z-wave smart dimmer driver without hitting configure to see if it would make a difference, and it cut about 500ms off. I say I didn't hit configure, this is important because I was able to keep the group 2 and 3 associations that I added when I was using the GE dimmer (or switch) driver with double-tap capabilities from @JasonJoel. I kept his driver on dimmers I used the double-tap feature on, and just left the others with the generic driver. It's doesn't seem like a big difference, but if you have rules to set the dimmer to a certain level when it comes on, it makes it so you don't notice the level being changed after the fact, like coming on to 100% and then dropping down to 10 because it's nighttime.
With the Zigbee devices, I shut down the hub for 30 minutes, and while it was off I moved my Samsung plugs closer to the hub, and moved the Peanut plugs to the farther places. I have noticed that the Samsung plugs are very reliable repeaters and never ever need rejoined, and figure there is going to be more traffic through repeaters that are closer to the hub, and I have 105 Zigbee devices so I need the repeaters to work well. I have had to rejoin any one of the peanut plugs about once a week and had trouble with dropped messages prior to getting the Samsungs, which I haven't had issues with since. Also the Peanuts act like they have gone to sleep if I haven't used one in a while, and are slow to respond the first time I turn one on. They also were overall much slower in this test than the Samsungs, which cost 2-3 times more btw.
Today, after the mesh has had time to settle, the Samsung plugs are all averaging around 200ms response.
1 Like
For the record, that is because the in-box driver cheats and reports on/off before the dimming is complete... Which is technically incorrect as it isn't OFF until it is actually OFF... 
The in-box is no faster than mine in "actual" on/off speed.
I would highly recommend not using dimmers with this app as the fade times can skew results. Switches/outlets would be the most consistent device to use, and more representative of actual speed.
3 Likes
No shame, I love your drivers and still use them. If there's a way to make it report "on" faster that would be awesome, because I would love to have a smoother transition with a couple of the dimmers I use double-tap with.
1 Like
That is the fun in comparing drivers. 
Some do reporting based on when the digital command is issued (shows up faster), and some do it on the on/off report that the device sends back after state change (shows up slower). Both physically turn the light on/off at the exact same speed though - it is a purely cosmetic difference in reporting.
Neither way is right or wrong. But as you see, it makes comparing event timestamps between drivers impossible without knowing which method they are using to generate the events.
I prefer using the report back, in general, as it is always correct. If you do it on command issuance, and the device misses it for some reason, your status is wrong on the hub... Rarely happens these days, but still. Of course if the hub misses the device report, the hub status is still wrong. So whatever, I guess.
1 Like
I must apologize. I reran a few tests on the switch I started with yesterday and see no difference now between drivers so it must have just been a fluke. But, with the dimmers, is there a way to make the device report on to the hub faster when physically switched on. This must be why the dimming level changes are smoother when using the generic driver and RM4 to set dimming per mode?
I edited out the switch reference and appreciate your explanation of the difference in behavior.
Cool, thanks for the info guys and I think the dimmer delay explains why my zwave and zigbee times were so slow. I was using 2 dimmers in the tests.
I think just using a virtual switch to monitor is the way forward for me. That seems to be closer to the actual hub delay and I also don't like having lights going on and off at 15 min intervals lol
No worries. Not a big deal at all. The in box one could actually be faster (although I can't think of why it would be). I just thought it would be a good opportunity to explain a few reasons why sometimes drivers with the same functions may not report the same. I think it is interesting to see how different driver authors approach things like reporting and digital vs physical events.
I appreciate the explanation. I have a light that’s about 1 foot away from the hub and of course responds immediately to commands, but was showing 1.7 second response times in the app. It has a transition time of 1.5 seconds, so it must not report until it’s all the way on.
From a coding standpoint I find it easier to do all zwave device reporting in the reporting event that comes back from the device. Otherwise you have to sprinkle event coding a number of different places.
But I know a few other authors that strongly prefer doing the digital events (ones that originate from the hub) in the on/off/level/whatever sections directly and not wait for the device to report back.
Can you elaborate on how you solved this? I have this exact issue. Sorry its off-topic.
Hi @bptworld
I'm loving this app. It gives a fantastic indication on how the hubs are running and for me is showing some interesting results on my 2 hubs.
I've noticed that I'm seeing an error in my logs. I don't think it is causing any issues but just thought I would mention it.
I'm running V1.0.5 of the driver.
Is there any more information you need?
Thanks again.
This is what I am seeing on my 2nd hub.
Update your driver and child app.
Thanks
Child is at.
V1.0.7 - 09/26/19 - Added a 'push all' option
Driver is at.
V1.0.5 - 09/26/19 - More color choices, rounded Med to 3
I believe these are the latest but I'm afraid I'm still getting this error.
Like I say its working OK but just thought I'd mention it.
