I get these warning from time to time in my log for different tp-link switches. This particular one took 30 sec to turn on this morning.
All my kasa stuff are on fix ip.
Edit: uploaded a longer log screenshot and revised time to turn on.
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?
1 Like
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.
1 Like
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.
2 Likes
Hi @djgutheinz,
First let me thank you for all your hard work, I have been using your Kasa integration for about 2 years now and it has been extremely useful to me, thanks so much!
As my post history shows I'm a bit of a security freak, I keep my IoT devices in a separate subnet with no access to my internal network and thus since I first installed your integration I had to figure out a way to make it work. Adding the devices manually is an option but instead what I do is that every time I install a new version I do 2 small modifications to the code and everything works just fine, no issues at all for me.
So, based on the latest code this is what I change:
In Line 104 resp does not contain the Device's MAC Address as its on a different subnet, so I get it from cmdResp instead removing the colons.
def dni = cmdResp.mac.replace(/:/, "")
In Line 800 I put the subnet where my devices are located in the networkPrefix variable instead of getting it from the hub's IP:
def networkPrefix = '192.168.25'
Reading the latest posts on this thread I realized I'm not the only one, other people have asked for this (@kbo5000, @alex2 , etc.), it would be really great if you could add a setting to the application to specify a custom subnet, if empty do nothing special, if set to something use the modified code above. Or perhaps if the custom subnet is defined then also check that one after the local one? either way it would greatly help us weirdos every time install / upgrade the app / add new devices 
...
1 Like
Thanks. On my research list for the next revision.
Since you have security concerns, I assume you are aware of the bind/unbind functions in the APP. This removes Kasa cloud access to the device while still allowing local access via Hubitat and the Kasa App.
Dave
1 Like
Thank you!
Correct, that was a welcome addition to the app, the subnet I put my IoTs on is considered insecure but still, that is useful.
Actually, now that I play with the tools they did not work for me because all the response functions use the MAC (DNI) from the response lan message to identify the device the response comes from, but for devices that are not local this is always null.
In order to get the tools page you need to open the app and the first thing this does is update all devices and their IPs plus commands are sent to devices using its IP, so I think it is pretty safe to identify the device the response belongs to by IP and not by MAC/DNI.
I did similar small tweaks to all response functions and they are now working fine for me as well but of course this would be a bigger change, are you open to code contribution? I can fork and send a pull request so you can see the changes I did and decide if you want to use them... its all small changes but given the amount I think this will be a lot better...
1 Like
New Version 5.3.4 available.
Changes:
- Added KL430 as a color bulb.
- Added capability to enter segment other than segment Hubit hub is on.
2 Likes
Thanks for adding the setting for a custom subnet!
I just sent you a pull request with all the tweaks necessary for everything to work well when using a custom subnet, nothing mayor, I also tested these changes with local devices as well so it should be safe for regular users.
I will look at it. It will take a while.
@djgutheinz Thanks for this awesome driver! I'm confirming it works great with the KP115. I've been running it for a few hours, outputting to InfluxDB and I can see it measuring power over time in Grafana.
2 Likes
