[BUG] - All five kp115 smart plugs went offline according to Sense but are still really on

I have mesh but all APs wired as well.

Yes, I was wondering if wired or repeater, wondering if that would account for doubling (or tripling) your data to get you to a Gig of data a day to the Sense unit.

But that’s clearly not the case.

FWIW, my Sense is at ~1.58GB per day down, and ~350MB up.

Here’s the latest response from TP-Link just a few minutes ago. They are asking me to remove all of the Google devices from my network (vlan) and continue testing. I will do that and report back. Based on the poll I don’t think that Google alone is to blame here but if the TP-Link devices are communicating with other devices on the network it could be that they have some internal rate limiting and Sense is just getting the short end of the stick sometimes. This wouldn’t explain @Offthewall problem very well, but it appears based on the feedback I’m getting from TP-Link that this might be partially to blame.

I’ll be interested to hear the result of the isolation test. My plugs are partially isolated in a devices (washer/dryer, sense, plugs etc.) network. No Google devices in the net at all.

On Monday of last week, as I mentioned here:

And as a refresher I said this here:

I have removed all of my Google/Nest products from the house (if anyone wants 2 Nest Hello’s, 4 IQ Outdoor Cams, 2 Regular Outdoor Cams, 1 Indoor IQ, 2 Hub Maxes, 2 Homes, 3 Thermostats, or 6 brand new Home Hubs let me know :roll_eyes:) and I think the change is obvious by the screenshot below. I’ve been over a week now with no n/a’s and no drops in data.

I honestly don’t think Google is to blame, but I really don’t know. I have never had issues with any other products and I’m not sure how many other products will conflict with these plugs. I’m not throwing the towel in on this and I will continue to try and help @Offthewall and others. There’s a new poll to see if we can isolate the issues I’m experiencing vs @Offthewall.

  • My Kasa plugs go offline every 4-5 days and require a power pull to reset.
  • My Kasa plugs show sporatic data like the screenshot above (spikes and drops)
  • My Kasa plugs don’t have any issues
  • I don’t have Kasa plugs, but I want to participate!
0 voters
1 Like

Two more of my HS110s have gone “zombie” today. Symptoms:

  • They go n/a in Sense
  • They are visible in Kasa app, but when I ask for Energy, I get the spinning circle forever.
  • I get no response when pinging both of them from my laptop that is wired to a LAN port on my router (Unbiquiti UDM)
  • But they both respond to pings initiated from that same UDM (I’m ssh’ed into the UDM)
  • Both appear connected correctly to WiFi (green WiFi symbol constantly illuminated)
  • Power cycling HS110s do not fix

This is all with a single LAN / subnet, no VLANs. Trying to make everything as simple as possible. And no Google hardware on network.

Funny you should bring this up

Look at my Dell Ethernet switch that just started going off/on according to Sense/KASA this afternoon.

Kp115

It’s never turned off in actuality.


Furthermore, I started receiving these False Alerts once a day on various Devices.

Was there anything you could correlate in packet captures?

The only thing that I could see when they were attached was that the devices were communicating with the Google devices. At that time I didn’t really dig into why because I didn’t suspect it to be the issue. Now, when I look at the pcaps everything appears to be normal. The Kasa devices respond when they receive the boradcast.

Previously the Kasa devices only responded sometimes to the Sense broadcast. This is why I believe that it’s possible that the Kasa devices have an internal rate limiting. Is it possible that the Google devices just got the lion share of the rate limit, could be… I don’t know because I can’t tell you that part of the story from the pcaps. Could these plugs be susceptible to other vendors and the same issue, possibly.

All I can definitively say at this point is: removing the Google devices made them work correctly. I still have perfect reporting from all of my Kasa devices for 10 days now. This leads me to believe that there’s compatibility issues with the plugs (and other IOT devices) and not network issues (at least for the sporadic data issue).

Based on the polling it appears the complete offline issue that @Offthewall has is isolated to him or just a single voter if it wasn’t him.

Good to know, thanks. Btw, did you leave your Hubitat Kasa integration enabled, or did you disable that as well?

I haven’t had time to remove it, although I really want to. The device driver that runs the Kasa devices in Hubitat is terrible on runtime processing. I’m planning on moving them to home assistant, but that presents challenges of it’s own since the only way to remove orphaned devices from my Hubitat to HA integration is to modify the device registry (an issue with HA that the entire community has begged for a solution to for years). The other way is to remove the integration with HE completely then re-add, but that’s a terrible option because of all the automation’s tied to it go haywire.

1 Like

Awesome. I love being the ONLY one with a particular issue. :slight_smile: I’m still of the belief (with no actual proof) that “something” happens on my network at that regular interval that breaks Kasa/Sense communication. WHAT that is I have no idea. I have ordered one Belkin WeMo Insight plug to see if that’s any better.

I would tend to believe the same. These plugs appear to be temperamental and don’t play well with others. I wish I could spend a day hands on with your network to help. If you ever get pcaps pm me with them and I’ll see if there’s anything out of the ordinary.

@Offthewall, if it makes you feel any better, I’m starting to see some weird cases where some of of my Kasa smartplugs disappear from Sense and become unpingable from my MacBook that is wired directly into my UDM/router, while the router itself is able to ping the same smart plug.

Usually when I’ve seen something like that is when the target stops responding to arp requests.

1 Like

But the ARP table is held by the router, which he said he can still ping from. So I assume it’s not that.

1 Like

I think “router” in this case means layer 2.

1 Like

Thanks for the thoughts guys ! What I see happening with my Office HS110 is that my MacBook loses the entry for that IP address, and a ping doesn’t refresh the cache. It was working just fine earlier today with the entry in the MacBook cache, but a few hours later, it’s missing from cache, and I can’t ping it anymore.

Just trying again - looks like the ARP cache worked this time, sort of. My Office HS110 has an IP address that ends in 127 a MAC address that ends in f1:60. Once again, the Office HS110 entry in the ARP cache on my MacBook has been flushed. I invoke a ping and within a few ping tries, the cache gets refreshed and the entry is there again. I’m not sure how quickly that cache entry should disappear again, and I’m not really familiar with how fast refreshes should be. But I do know that I have several times where a ping does NOT cause a cache update.

kevin@imackevin ~ % sudo arp -a | grep 227
kevin@imackevin ~ % sudo arp -a | grep f1:60
kevin@imackevin ~ % sudo arp -a | grep f1:60

kevin@imackevin ~ % ping 192.168.1.227
PING 192.168.1.227 (192.168.1.227): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 192.168.1.227: icmp_seq=0 ttl=64 time=4024.004 ms
64 bytes from 192.168.1.227: icmp_seq=1 ttl=64 time=3020.923 ms
64 bytes from 192.168.1.227: icmp_seq=2 ttl=64 time=2017.903 ms
64 bytes from 192.168.1.227: icmp_seq=3 ttl=64 time=1015.173 ms
64 bytes from 192.168.1.227: icmp_seq=4 ttl=64 time=11.875 ms
...
64 bytes from 192.168.1.227: icmp_seq=5 ttl=64 time=3.898 ms
^C
--- 192.168.1.227 ping statistics ---
22 packets transmitted, 21 packets received, 4.5% packet loss
round-trip min/avg/max/stddev = 2.295/507.560/4024.004/1094.951 ms

kevin@imackevin ~ % sudo arp -a | grep f1:60
? (192.168.1.227) at f1:60 on en0 ifscope [ethernet]
kevin@imackevin ~ % sudo arp -a | grep 227  
? (192.168.1.227) at f1:60 on en0 ifscope [ethernet]

That makes sense. The arp entry expires on the host and the plug isn’t respond to requests. With no MAC address, the host cannot ping. If you take the address and manually insert it in the arp table I expect you will be able to ping. But doing that won’t really help with the broader issues… as @DevOpsTodd has noted the plug is already borked wrt broadcast.

1 Like