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.
New driver...
V1.0.6 - 09/28/19 - Fixed the '60' error.
Thanks Bryan. 
New versions on Github...
Parent:
V1.0.1 - 09/29/19 - Added second type of child device - Hub Watchdog Watchdog Examiner 
Child:
no change
Child - Examiner: *** This is new and needs to be installed ***
V1.0.0 - 09/29/19 - Initial release.
Driver:
V1.0.7 - 09/29/19 - Added support for 'Examiner' child app
- Be sure to go into each device to update the fields and hit 'save'
- Go into each child app and update the settings
- THEN go back to the parent and create a new child app for the examiner
Keep in mind that the formatting of the data has changed. So you can either wait for the new data to bump the old data out or hit the clear data button (in each device) to start fresh.
1 Like
Looks like you didn't go into the device you created and fill out all the fields. Like it says in the post right before yours. 
1 Like
This process is not working for me. I have tried the following:
Send POST to: https://X.X.X.X/hub/reboot -->(json) body: https://X.X.X.X/hub/reboot
AND
http://X.X.X.X/hub/reboot -->(json) body: http://X.X.X.X/hub/reboot
AND
http://X.X.X.X:8080/hub/reboot -->(json) body: http://X.X.X.X:8080/hub/reboot
I see the rule action run in the log and then nothing else and hub does not reboot.
I have hub login security turned on. Does this affect anything?
Yes, the hub security needs to be disabled if you're going to try doing this within Rule Machine, IIRC.
1 Like
