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

@Beachcomber not to get too technical but I have a wired mesh network. Mesh can be wired or wireless. But I think what you are asking me is if I have wireless mesh repeaters. I do not. They are all wired. Also the bandwidth I’m showing is network bandwidth not necessarily WAN bandwidth to/from the monitor. I have traffic analysis disabled on my network, because I believe in the privacy of my family, and frankly don’t want to know where they go on the internet, so therefore I couldn’t give you a number for WAN usage.

1 Like

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.


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
PING ( 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 icmp_seq=0 ttl=64 time=4024.004 ms
64 bytes from icmp_seq=1 ttl=64 time=3020.923 ms
64 bytes from icmp_seq=2 ttl=64 time=2017.903 ms
64 bytes from icmp_seq=3 ttl=64 time=1015.173 ms
64 bytes from icmp_seq=4 ttl=64 time=11.875 ms
64 bytes from icmp_seq=5 ttl=64 time=3.898 ms
--- 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
? ( at f1:60 on en0 ifscope [ethernet]
kevin@imackevin ~ % sudo arp -a | grep 227  
? ( at f1:60 on en0 ifscope [ethernet]