Me too, been a bit random in how I have approached testing / resolving the issue, but I think resetting the Network speed on the C-7 seems to have fixed it for now... I hope. Thanks again for your help Dave. I'll report back if it stays stable. Like I said earlier, I don't expect it has been a problem with the Kasa drivers, just that they were impacted by some underlying, unrelated issue.
1 Like
Still grappling unfortunately, just rebooting my C-7 and shutting down my C-4..... Tried restoring yesterday morning's backups but that didn't help....
I think I need to setup a separate thread for my issue, although it appears for my Kasa devices, I don't expect it is related directly to the devices themselves....
I keep seeing this when I expect it is polling:
com.hubitat.app.exception.LimitExceededException: Event Queue is Full on line 799 (method parseUdp)
Do you have a device or app that is showing an abnormally high number of events?
Unfortunately it is this one, for each plug, although the number of events don't seem to be high when looking at them in the Device Edit page.
Device edit sets the number to retain at the hourly cleanup. Not knowing how this works, I might be tempted to disabble all of the devices and then reenble one at a time to see when the issue starts - thinking maybe a rogue device.
1 Like
Correction - the number of events is not high on these devices.... Been a bit of a blur....
Might add the number of events column to the stats
I should get some sleep, might just have to let them run hot for a few hours. Thanks for the advice, I'll take abother look later today...
1 Like
Yeah getting a little late in Oz...or early depending on your point of view.
1 Like
This is normal behavior if on LAN comms and four consecutive errors on one device. It will attempt to update the IP, assuming the IP may have changed. The message is throttled to run only every 15 minutes max. It does not impact the device performance (all processing is within the app except updating the IPs on the devices).
1 Like
Did a stress test on my development hub. Found no error that should cause the issues encountered.
Description of device error handling
- Sent command is timed and if no response is received, error processing is initiated.
- The command is retired 3 more times
- After the third try
- the app is requested to check for IP changes.
- This process is designed to be limited to once every 15 minutes for ALL devices.
- The attribute commsError is set to true (this is the only time this occurs. I use If loops to preclude sendEvent if an attribute has not changed.)
- Comms retries are disabled.
- the app is requested to check for IP changes.
- If ever a comms is successful, the count and attribute commsError are reset.
What I did (on my test C-7 Hub):
- Loaded 21 Kasa Devices
- Set each device up to 5 second poll (not a recommended configuration)
- Added log code to the sendLanCommand method.
- Tested each device.
- Modified code to use incorrect PORT number, effectively causing all devices to fail.
- Monitored Log and noted that devices tried again until the fourth error.
Results:
- Devices had high resource utilization (over 30% of total time each) while doing the initial error processing. With the 5 second polling, comms were quite severe.
- No errors nor warnings were noted on the device logs except when the comms error was finally declared (when setting the attribute). (Only saw the instrumentation trace logs and the log info from the app.)
- App IP recovery ran more than once (and should not have). But app utilization even then was only 12% of total.
- Once the attribute commsError was set, the device processor utilization went to normal as each communications try continued at the poll interval.
App Fix. Initial (single character fix) on GitHub. You can update using the HPM repair or replacing the app code.
2 Likes
When I do the repair in HPM, it says the EM Plug driver is deprecated, i.e. you appear to have included that in the name of the driver..... I also saw that, for some reason one of my plugs was detected as not being setup when I tried to "Install New Devices" in the Kasa App on my HE hub, but it didn't install, saying that the most common issue was the driver not being installed. Could this be part of the issue?
Manually installing the Plug Switch driver, doing a repair in HPM and running the Install Kasa Devices in the app, followed by a hub reboot appears to have calmed things down on both hubs.
I will slowly start to re-enable the devices.
Interestingly, it would appear that the scheduled jobs appear to keep running for disabled devices, at least it would appear that way according to that section of the Device Edit page.
1 Like
Well.... maybe.... Back at 70+ degrees and 1000% CPU....Turning on debug logging for one of the switches produces a flurry of logs getting the current months energy usage.
The elevated temperature / load did appear to coincide with the new year. Could it be a month 1 issue of some sort?
I don’t like coincidence, looks like you may have something there. Anyway to turn off that calculation?
I turned off the energy monitoring on one of the plugs and restarted the HE hub, seems to have calmed down again for now
I'm not seeing the exact same issues as you @sburke781, but I've also started seeing these warning messages in the logs today:
Maybe it doesn't like year 2022? 
Edit: It just affects my energy reporting HS110 plugs (and all of them), not the non-energy-reporting HS100's.
Yeah, I'm starting to think there is something causing the HE database (I assume) to enter exclusive access mode, which may not allow for the error count to be reset / adjusted like it needs to be. Would like to find out what is the root cause for the database issue, then go from there....
Another tidbit of information: This morning I was on HE version 2.3.0.121 and running version 6.4.3 of the Kasa drivers. At lunchtime I upgraded to HE version 2.3.0.124 and Kasa version 6.5.0. The issue was present in both configurations.
