so you had ONE custom app and got slowdowns? (I'm not able to distinguish "my test app" and "last custom app" -- same app? or two?)
What app? I'm curious because I've been following "slowdown threads" and have a fistfull of hypothesis.. one of which is 'asyncHTTP' related.
OMG! How DARE you make a joke about our warranties! 
LOL
I edited the post to add a little more info.
What about custom drivers?
OK, sorry for the confusion. The test app was actually a RM4 rule. Wasn't thinking when I called it an app. The custom app was as I said my own that did a asynchttpget every 30 minutes. Actually it did 2 such calls each time, wonder if that is part of the issue. I can get by without it for now so I disabled it.
The only custom drivers I have are the Logitech Harmony by ogiewon. And an Inovelli 2 channel smart plug driver by Inovelli. I could probably get by without the Harmony one for awhile, but the Inovelli plug would put a real hardship on things.
Okay, check out the new Hub Watchdog! Remember this is a first run through and things can change. I still need to create a new driver to to save the data points to on each run.
But, I think it works. Let me know what you think over on the Hub Watchdog thread.
Thanks
If it helps in your troubleshooting, I use both of those and haven't had any issues.
I think you are right... It's why i just moved most of the Echo Speaks calls back to Sync calls...
Something is definitely not right in Async... It's like it doesn't close the session if the response fails and they just pile up.
Would be interesting if you could write an app or driver that could be used to test this hypothesis. I am sure the Hubitat engineers would fix it if we could reproduce it.
ugghh...I just rewrote some code to USE async because of the recommendation.....
I wouldnt rush to change anything at this point, not enough data exists in my opinion to start wholesale refactoring of code...
@tonesto7, I created virtual, z-wave, and zigbee Hubwatchdog child apps and ran each a few times to get a baseline measurement. Then I installed Echo Speaks with one Echo dot to start with. I waited about 15 minutes and ran each test again 8 times. My runs are very consistent, within 100ms within each category (zigbee, z-wave, virtual) and I see no difference between the before and after runs. I also don’t subjectively see any difference in speed at this time. I have 105 zigbee devices, 16 z-wave, and 20 Hue on the bridge connected to the 1 Hubitat. I have all logging enabled, including debug for ES. I haven’t rebooted the hub since Saturday and no issues so far.
Do me a favor and turn off the debug and detailed logging in ES. It just fills the logs with unnecessary entries.
Done
Thank goodness, because that was a crazy amount of logging.
I looked at work @bptworld did, and it was too complicated for me and when looking at latency I don't like complicated, and I like visuals better. Like this:
So I put a very simple driver together than you can use for really simple timing of anything. You send it an On, and then later send it an off and it records the time between the two events. It reports a "pressure" event in kPA of the number of milliseconds between the two. Why pressure? I was fixing up the InfluxDB app*, and it naturally exports pressure sensors well, and I figured it was something I could overload without messing up to much other data, and it's unlikely that most people have lots of pressure sensors around. So shrug I'm open for ideas for a more appropriate sensor value type.
There's also an auto more where it sets a default 50ms runIn, where you can see how accurately the hub manages to run the off in 50ms.
For example to time an RM4 rule you could do: (ok it's a stupid example, but you get the idea):
Or this slightly complicated option, which surely could be better:
**) I've updated the InfluxDB-Logger thread with a link to a version that does write combining to avoid 20-50 async https calls/sec, and keeps stats to see if there are issues.
There's some other issue here.
My 3rd hub is solely a backup replacement hub that only purpose serves as a readily available hub in the event I have one of my two hubs go down and normally is powered off and not accessed daily.
Knowing that a release would be coming soon and with that release they would be retiring Rule 3.0 rules and Button Controller. I powered it up and installed the Rule Machine and Button Controller app and created "master" 3.0 rules that in the later event needed I could have the ability to clone them before the Retirement of this ability comes about.
This hub has Zero devices on it, Zero 3rd party apps and drivers, and the only built in apps are as follows.
After 2 days of this hub being up and running the UI takes approximately 5 - 35 seconds to switch between UI "devices" "apps" "settings"
My other two hubs with all the varying devices, apps built-in and few custom, both at which get automatically rebooted twice every day, don't experience this lag.
Sheesh. Is this is a C-3, C-4, or C-5 hub? And what platform version?
What router is this connected to?
Sure it is 
You never asked me to check the network issue on your Backup hub, and sure enough it has the network switch issue. Please reboot your hub and then let me know if you notice a difference
Download the Hubitat app
