Looks like it is testing 2.3.0 instead of 2.2.3.0...
Fixed. Give HPM a few minutes. Typo.
Dave
Installing now, thanks Dave! I guessed it was missing a digit.
Is there a way around the same-vlan requirement to add a device?
My HE is on a separate vlan to my IoT, so that it can talk with my Unifi controller for presence.
Can I add a Kasa device to my main vlan, then change the IP address once integrated with HE?
You might try a manual installation.
..of the app/drivers or of the devices?
I have the app/drivers installed and worked well to install previous devices, but as the network structure has changed, the integration doesn't see old or new devices. Although the old ones still work.
If you meant manually install the Kasa devices, then that would be awesome - how do I do that? Is there somewhere in the integration to add the IP location of the device?
Thanks 
It is in the instructions. You simply add a Virtual Device with the appropriate driver. When the device is created, there will be preferences to set the IP address and for multi-outlets, the number of the device. Then save preferences.
Thanks so much. I hadn't felt the need to read the instructions, as I already had the integration and most devices working already.
Need identification of the switch type. I assume HS200, but not sure.
Most of my switches are HS200 but these messages happen also with an HS100.
Hi @djgutheinz,
I was interested to see if you would consider an extra option for smart plugs when they have comm's issues, or whether you have any other suggestions....
I have 13 HS110's dotted around my house and have had issues with them all re-joining the Wi-Fi network if I restart my router. That is a problem that is completely unrelated to your Kasa HE app and something I need to work through in terms of my Wi-Fi setup. There's a good thread here on the HA forum that I plan to work through in terms of that issue.
The thing I noticed recently was that one plug continued to report comm's warnings in my HE logs even though it was successfully connected to my router and visible to TP-Link's Kasa mobile app on my phone. I decided to open up your HE Kasa app and chose to restart the plug. This seems to have solved the issue, at least the warnings are no longer appearing.
These are the warnings btw:
[dev:1478](http://192.168.0.8/logs/past#dev1478)2020-12-20 12:00:49.025 [warn](http://192.168.0.8/device/edit/1478)Error occured with UDP message: SocketTimeoutException: Receive timed out
[dev:1478](http://192.168.0.8/logs/past#dev1478)2020-12-20 11:59:50.069 [warn](http://192.168.0.8/device/edit/1478)Ventis L5.0.2 setCommsError
I was wondering whether including an option in the HE app to automatically restart a plug that reports these warnings for a period of time would be of any benefit? Perhaps limiting this to once per day.... I would expect it would need appropriate warnings about the power being temporarily disrupted as part of the restart, so it would need to be carefully considered by the user which plugs to apply this to.
Any thoughts?
Simon
Thanks for the note.
Anything is possible; however, I am reluctant to automatically restart on error any device. Has to do with reliability of service. Let me think on this for a few days to fully understand the implications.
PS. What version of the driver are you using? It would near the top of the driver file. Logs indicate it may be old. Below is the version 5.x change log (note 2nd to last entry).
02.28 New version 5.0. Deprecated with this version
04.20 5.1.0 Update for Hubitat Program Manager
05,17 5.2.0 UDP Comms Update. Deprecated with this version.
08.01 5.3.0 Major rewrite of LAN communications using rawSocket. Other edit improvements.
a. implemented rawSocket for communications to address UPD errors and
the issue that Hubitat UDP not supporting Kasa return lengths > 1024.
b. Use encrypted version of refresh / quickPoll commands
08.25 5.3.1 Update Error Process to check for IPs on comms error. Limited to once ever 15 min.
11/27 5.3.3 Fixed error handling to properly cancel quick polling and refresh after 10 errors.Thanks Dave. I was also reluctant to ask, could be problematic doing something like that automatically, so don't feel obligated...
Also, well spotted on the driver version, you were right. I'll update it and see how it goes.
I've updated the driver. It was weird that I was still on the old version, I have the Kasa App managed by Package Manager but the driver was still the old one.... I updated it manually and clicked Save Preferences on each plug, so hopefully that should bring them all up to date now.
Maybe use an error count within a certain time period and reinitialize?
The issue is that the reboot will cause the plug to power-off connected devices that are on. When power is restored, the device may (or may not) come back on. This could cause consternation among the users.
In @sburke781 's case, I would recommend monthly running the reboot utility that is part of the Application and see if that helps.
That sounds like a good compromise to me. I had similar concerns re the behaviour when restarting and the unknown around different uses people have for the plugs, so am happy to manage it manually. Potentially having upgraded to the more recent driver version and the change in the communication method you made recently may solve my problem without the need to reboot the plug.
Thanks Dave.
Out of interest, if I get to a point where feel I need some kind of alerting for loss of comm's, do you have any suggestions for how best to monitor that? I saw there are one or two attributes that may be useful....
I will add an attribute to the code (by early Jan) to report unresolved comms error. You should be able to use rule machine for notification.