Yup, upgraded yesterday - no changes, sadly.
I have a Sense energy monitor and it integrates directly with the energy monitoring TP-Link Kasa plugs. So I have a few of those as well. The Sense sends out a UDP broadcast every 2 seconds requesting the current wattage of every Kasa device on the network. This has never been a problem for Sense and I rarely, if ever, have missing data. So I seriously doubt the polling rate you choose in Hubitat will be a problem.
I wish it was as easy as a poor wifi connection! I have a UniFi setup and I watch wifi signal quality and interference like a hawk 
Zero packet loss, pings are stable.
4564 packets transmitted, 4564 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.256/4.677/25.548/4.357 ms
Also, when I had HomeAssistant running, I even plugged its network cable into the same port on the switch where Hubitat normally sits, to rule out the rest of the network, it was running for over 24 hours polling every device every 5 seconds, and not a single one of them took more than 150ms. So when HA is plugged into the network switch, there are zero delays; but when HE is connected to the same port on the switch (using the same cable), I see those delays. Based on that, I don't see how can the problem be on the wifi side.
A compatibility issue with an integration seems to be way more likely, my #1 suspect at this moment is Envisalink, which is a very chatty integration. Trying to figure out a way to test it without causing much disruption.
1 Like
Always had a separate SSID and VLAN for all IoT devices 
Article to read on Unify support. May or may not be relevant:
So I did "an experiment to end all experiments": set all Kasa devices to poll every 10 seconds, disabled polling for all the non-Kasa devices where possible, and turned off all cloud integrations.
As a result, in this "cleaner" environment, 99% of the errors were clustered at every 30 minute mark, exactly on the hour and half past the hour. And the only scheduled job that runs every 30 minutes is ZWaveNodeStatisticsJob, which is a bit too much to be just a coincidence.
To be completely fair, it doesn't look like Kasa integration is the only one affected. I've noticed that response times in Envisalink integration (for the alarm system) got much worse overall. Previously it would take about 150ms for the "door opened" signal to be reflected in HE, now it takes 1-2s.
My working theory is that relatively recently HE started treating IP-based protocols with much lower priority, probably to improve ZWave/Zigbee reliability?
1 Like
What platform version were you running for this test, out of curiosity?
Anecdotally when I was having Zigbee reboot issues resetting the Kasa polling interval to default (30 min) was one of the changes that seemed to make a difference.
Latest as of today, 2.3.7.145
Would have been curious to know if the experiment gave different results on 2.3.6 latest. My Zigbee reboot issues seemed to vanish on 2.3.7.x; your theory might explain it. Or it might be a pirates/global warming situation.
