Be sure you updated both the child app and the driver
had just done all 3
Just an observation and request.
Is it at all possible to set the meanD to only have 3 decimal places.
At the moment it is displaying 10 decimal places.
Just looks a bit neater in the tiles.
JUST realized with your switch/rule integration you could turn on a switch that's connected to another hub to tell it to reboot the problem hub....plus alert you.
Man that's going to be nice moving forward...no more blanket just reboot every night....AND will help tell when things start going downhill.
Going to need more of the log to see when it's popping up with this error
Please unformat the log, just paste it in
yea didn't realize till I posted, sorry
New driver on Github..
V1.0.5 - 09/26/19 - More color choices, rounded Med to 3
Be sure to fill in the new fields and hit save before running a test or a report.
I was thinking same but if slowdown problem is caused by badly written app or driver
is safe to think that slowdown will happen depending on circumstances, maybe those unknown circumstances happen 10 seconds after reboot and then again and you got endless reboot loop effectively killing automation even more than a slow hub.
I that way is night reboot safer more efficient way. Sometimes a dumb solution is safer than sophisticated.
I guess my hub is a snail.
this is about 15 minutes after reboot
virtual is switch not connected to anything
Zigbee and Z_wave are devices located farthest from hub.
160 devices on this hub, mostly zigbee
23apps with combined of 90 automations
Saw the same thing yesterday:
And the solution was:
(It's really an amazing app... I've been calling for an objective, scientific approach to measuring "slowdown" for some time - Bryan has been great in translating that into an app that everyone can use!)
Yes, I would call that slow. 3-4x slower than my hub main zigbee/zwave hub. But I have 3 hubs, so my rules and some of my devices are spread out more than yours / fewer total devices. So I would hope mine is faster.
I can understand that zigbee and zwave responses can vary substantially between setups. But I would hope the virtual switch should be pretty similar. Anyway, currently for my devices, I'm seeing the following:
Mean Delay: 0.1046
Median Delay: 0.0885
Minimum Delay: 0.068
Maximum Delay: 0.19
Mean Delay: 0.2732333333
Median Delay: 0.2695
Minimum Delay: 0.17
Maximum Delay: 1.882
Mean Delay: 0.4863833333
Median Delay: 0.4515
Minimum Delay: 0.371
Maximum Delay: 1.54
Mean Delay: 0.1369
Median Delay: 0.1225
Minimum Delay: 0.081
Maximum Delay: 0.68
Mean Delay: 0.24925
Median Delay: 0.246
Minimum Delay: 0.192
Maximum Delay: 0.351
Mean Delay: 0.5281666667
Median Delay: 0.5495
Minimum Delay: 0.454
Maximum Delay: 0.944
I haven't run this quite 24 hours yet, but there are 60 data points. There is one reboot in here for the latest update.
Edited to add:
Over Max Threshold: 1
Over Warning Threshold: 29
Over Max Threshold: 1
Over Warning Threshold: 1
Over Max Threshold: 16
Over Warning Threshold: 14
All have .400 for warning delay and .500 for max delay. Not sure what to think about so many virtual device warnings? Z-wave could be a device issue, or a mesh issue, but virtual shouldn't have this many high numbers, right?
Mean Delay: 0.17
Median Delay: 0.119
Minimum Delay: 0.087
Maximum Delay: 0.829
Mean Delay: 0.285
Median Delay: 0.266
Minimum Delay: 0.23
Maximum Delay: 0.384
Mean Delay: 0.541
Median Delay: 0.494
Minimum Delay: 0.468
Maximum Delay: 0.805
Pretty sure the max on the wave and virtual must have been at the tail end of a reboot or something. I installed v2.1.5, then rolled back to 2.1.4, then reinstalled 2.1.5 to check something out, then rolled back again. So there was a lot of craziness going on this afternoon. When I look at my data points, those maxes are definitely outliers.
It's interesting to me that we're all sort of in the same ballpark.
Yup. And I'm replacing zwave sensors with zigbee ones when the new zigbee 3.0 compliant Aqara ones come out.
That is one takeaway here. Zwave seems to be consistently slower than Zigbee.