Hi folks,
I’m going to try to consolidate a summary of known Kasa smart plug (HS110, HS300, KP115 and KP125) issues plus all the associated specifics, including exact diagnosis and and workarounds, if available. Feel free to add details of your issues and discoveries in the comments below this posting. Please note that so far, most of the issues appear connected with bad behaviors on the part of the smart plugs, not the Sense integration.
5 Likes
@Offthewall , @wojo, @Beachcomber, @dennypage, @DevOpsTodd, @ccook, @Dcdyer, @alansanderson25 , @MikeekiM, @addohm, @nsmithson, @reeftank10, @chrisd253, @serovner86, @jefflayman - you have all commented on Kasa disconnect issues. Are there any more I should list in the summary here ? If there are links to the thread, please include.
It’s really hard for me to try to provide any meaningful input here as my home net work is just fairly sketchy. I do randomly get things dropping off the network including the Kasa devices. I do have 53! devices currently connected to my wifi across the 2.4g and 5g bands.
1 Like
From @Dcdyer
My Observations:
- I manually ran individual single ‘once-only’ pings to check all my connections – multiple times. What I saw was a very high ping response time on single pings. Maybe the smart device was slow to wake-up or maybe my internal LAN was slow to map the route. I’m not certain.
- I choose to run a .BAT program using 25 pings to each device and take the average value. 25 pings should be statistically enough data to give a valid average. I took that single average number and recorded it in a file. So each data point in my file is the average of 25 pings. All recorded values are in Milliseconds.
- I performed this over a 3-day period. Note: My test is still running and capturing more data. The scan rate is about every 5 minutes.
- What I did noticed is that my KASA HS110 products are failing to respond. (Timeouts at 2500 ms).
Failed to respond:
HS110 (downstairs) 74% and
HS110 (upstairs) 94% of the time.
I had already suspected that the upstairs unit was not responding to SENSE requests and moved the unit to another location to get a better connection to the WiFi signal. This unit is OFF most of the time and sees very little usage. I was surprised to see the HS110 downstairs unit having the same problem. I’m not sure how to gather data on failed responses. - My Smart phones are still dropping my WiFi connection. I suspected the problem was other smart devices creating ‘congestion’, but it might be the HS110 devices are beginning to fail.
- I probably took a more tedious approach to graphically displaying the data (EXCEL) than was necessary.
- All of my SENSE communications (to the mother ship and the smart device modules – KASA) occurs thru my Netgear Extender. That’s why I included it in my test. All my other internet devices are network hardwired (including my thermostats). I did not see the point in testing any hardwired connections, but I might reconsider that in future testing.
- I did download a free ping APP on my ANDROID phone and checked ping times against my .BAT program and got similar results. The phone APP doesn’t create a file, just a display.
- The Netgear 6100 extender has a static IP address. I assigned it. The other devices are dynamic.
2 Likes
@kevin1 has KASA/TP-Link support been of any help on any of these issues that we’re aware of?
I’m skeptical about bringing dev resources to look further into this because it, at first glance, still appears to be an issue with the plug interaction with the network (and thereby, Sense) and Sense is on the receiving end of things.
1 Like
Thanks for taking a look @JustinAtSense. I think @DevOpsTodd has had some correspondence with TP-Link on one of his issues, but I’m not sure they have responded. I think all these issues except for the first and the third (which was an issue Sense helped with - too many smart plugs) still require additional investigation, to catch the whatever device is causing it “in the act”. I’m guessing that we could go to TP-Link with the first issue, because that one is clearly on them.
I’ll be pulling folks together to try to use our collective experience to get to truly diagnose the root cause of the remaining items. I added a “Result” column to kind of guide what’s still needed.
From @Beachcomber
I really haven’t had disconnect issues with the KP115 and HS300 that you guys have. My real issue is around 5:25AM each and every morning is I get an off notification and then an on notification on a number of devices. It’s not like the never come back. Just disconnected.
Except for Air Handler turning on and water heater turning off, none of these events actually happened.
@kevin1 - Did I report a Kasa disconnect issue? If I did, I don’t recall doing so… I don’t recall ever having a Kasa disconnect issue… If my memory returns on this one, I will certainly come back and post it…
I am not an expert but i would like to give some feedback.
When a device is a DHCP client and initializes and there is no dhcp server available, the device tries and tries and then most of the time assumes an ip address.
For example with Windows OS:
A Windows-based computer that is configured to use DHCP can automatically assign itself an Internet Protocol (IP) address if a DHCP server is not available. For example, this could occur on a network without a DHCP server, or on a network if a DHCP server is temporarily down for maintenance.
The Internet Assigned Numbers Authority (IANA) has reserved 169.254.0.0-169.254.255.255 for Automatic Private IP Addressing. As a result, APIPA provides an address that is guaranteed not to conflict with routable addresses.
source: How to use automatic TCP/IP addressing without a DHCP server | Microsoft Learn
When a dhcp ip address needs to be renewed (TTL reached) if follows this procedure:
http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm
If for some reason the tp-link plug somehow is not able to get acknowledgement of the renewel it refers to point 11 on the above link:
- Lease Expires
If the client receives no response to its broadcast rebinding request, it will, as in the RENEWING state, re-transmit the request regularly. If no response is received by the time the lease expires, it transitions to the INIT state to get a new lease.
So I think that tp-link has chosen to not use the 169.254/16 but the 192.168.0/24 range to get the initial ip address.
In your table it says “becomes a DHCP server” and I am 100% sure that is not the case. A client can assume an ip address if it doesn’t receive acknowledgement of the renewal request.
I am on a full Ubiquiti network but with the edgerouter & edgeswitches & unifi AP’s and I have experienced none of the problems. It might be a problem related to the ubnt USG product.
Hope this helps
1 Like
I feel like @Dcdyer issues are within his local network. And that @Beachcomber is an issue within sense. His is showing in sense’s time line that every plug he has is turning off then back on 2 mins later.
What mine is doing is almost certainly from TP-link’s cloud commands. Right at 5 days (down to the second)
Here is a local ping test from an older cf-19 connected by 2.4ghz (802.11n) while in the same room as my Wi-Fi router. I ran this ping test for around 30 mins. 192.168.0.27 is my HS300 which is the farthest away device on this access point, the signal is going thru a cinder block wall and a floor. 192.168.0.21 is a KP115 which is also going thru a block wall. I also have 48 connected devices.
I have 0% loss and the closer KP115 has an average ping time of 5ms and a TTL of 64
The HS300 has an average 8ms and a TTL of 64.
1000ms is 1 second. 200ms is 1/5th of a second. 10ms is 1/100th of a second. I would expect an occasional ping at 200ms but I would personally like to see under 10ms of anything inside my house.
@MikeekiM , you might not have had an issue, but you were part of a thread on one of the issues.
@dannyterhaar, that’s an interesting thought. Do you have any links or direct experience that tells you that the self-assigned address is 192.168.0.1 vs. the standard 169 ? I may have to try.
No, I just don’t think the description (from ccook) which you summarized
“become its own DHCP server and assign itself a class C IP of 192.168.0.1”
is accurate.
If it would become a DHCP server it would imply other devices could start listening to it as well.
The software code to do that is so large, it would not be included in a smart switch.
Since ccook’s network is in a total different range than 192.168.0/24 someone might check with TP-link and ask them what range will be chosen if no communication with a DHCP server is possible.
Then we will know for sure.
At that point we might be able to trace why DHCP broadcasts fail (or something) and getting closer to a condition where that happens.
2 Likes
The network the plug it on is a 10.50.17.x/24… it was plugged in to that network after a full reset of the plug. There is no chance that my network assigned it as such since I have all IP’s blocked from 192-223 and no interface in that range in my firewall. The IP 192.168.0.1 was assigned by external commands from AWS
@ccook Do you have your LAN bridged with AWS somehow ?
Is it possible that broadcasts are relayed through a vpc/vpn somehow?
1 Like
No, I have a Sophos XG firewall at work. I have a KP125 that kept dropping here at the house (Netgear AX120 on 192.168.1.x/24)… it drops right at 5 days exactly (120:0:0). I set the plug as static, tried different DHCP lease times. Still drops right at 120:0:0. Strange thing is I have another KP125 that hasn’t dropped.
So I take it to work and put it on my default network. I wait 5 days… logs shows at 120:0:0. It IP address changed to 192.168.0.1, the Sophos changes it back to 10.50.17.x. I did a reset on the plug, added it back… again at 120.0.0 it pulls 192.168.0.1. If it can’t see a network it should fall back to a 169.254.x.x.
So I reset the plug again but made a different Kasa app (used a different email) I’m on day 4 and the IP is 10.50.17.28. Here are the logs, the majority of the ext IP belong to AWS according to arin.net
@dannyterhaar I just checked the fall back / auto dhcp. Made a non-valid vlan, tagged the port of the AP, rebooted the AP and the switch shows a 169.245.x.x
1 Like
I’m not sure I agree with this. I don’t have one of the newer TP Links to test, but having smart devices run their own DCHP servers is quite common. Many devices now opt for a bluetooth configuration method, but I think its still common for smart devices to broadcast an SSID and run a DHCP server. You connect to the SSID, and get an IP and the config is pushed down from the companion app or on some, you actually can configure them from a web browser.
The fact that the TP links are falling back to their own default IP (192.168.0.1) vs an APIPA address when they can’t get an IP lease (for whatever buggy reason their firm causes that) is odd, but also not abnormal. I’m not sure about the newer gear, but almost all of the original Edge and Air Max products from Ubiquiti default to a Class C IP (192.169.x.20 based on model) if they can’t get an IP.
Some network switches do this as well. HP printers offer this feature.
So what i’m really trying to get at here is that I don’t think much should be read into trying to find the source of the 192.168.0.1 address as its probably just the fallback IP of the device. Why the DHCP server starts back up and why these devices are losing their DHCP lease and choosing to go to the fallback IP, I can’t answer, but the DHCP server alerts and IP to me make sense.
3 Likes
Makes total sense.
Thanks for correcting me.
4 Likes
OK, I finally freed up my HS110 roamer and tried a little experiment - I did a soft reset and took a look at the details of the HS110 reconnection. Immediately after soft reset turns the HS110 into a DHCP server with IP 192.168.0.1, so it can assign a matching subnet address to my configuring device, an iPad.
I’ll have to try on a my roamer KP115 as soon as it frees up. I tried similar on a KP125, and suspect it works the same, but the pairing protocol is different there for me because iOS devices jump directly into HomeKit pairing with the KP125 as soon as they see the KP125-created network so I don’t get a snapshot of the localized subnet at that point in time.
So @ccook, you’re likely seeing a built in set-up mode in the KP115, triggered for some unknown reason.
3 Likes
KP115 works just the same. A soft reset (5 secs on button) turns it into a mini-DHCP server at 192.168.0.1 for pairing with the device running the Kasa app. In essence, the setup process turns the Kasa smartplug into a non-internet connected Access Point with a DCHP serve.
Now we just need to find out what triggers a soft reset behavior beyond a push on the button. I guess I could turn on DHCP guarding on my UDM to trap any such occurrences, but I’m not entirely sure if DHCP guarding works when you point to the UDM DHCP “server” as the trusted server.
UPDATE: A Kasa plug in setup mode does trigger “guarding” for me because it never attaches to any of my home networks. See below, they just look like additional neighborhood wifi SSIDs
2 Likes