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.
Awesome. I love being the ONLY one with a particular issue. 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.
But the ARP table is held by the router, which he said he can still ping from. So I assume it’s not that.
I think “router” in this case means layer 2.
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.
OK - A pattern is getting clearer for me. The only HS110s getting borked are the ones connected to my lone U6-LR access point. And the HS300 attached to that access point stays in the game, even when the HS110 disappear. I didn’t have any of these issues with the the simple Apple Airport Extreme based network I had for 10 years previous. Gonna try a restart of just that access point to see if they com back.
OK - longer story here. It looks like all Kasa smartplugs are running fine after I updated firmware to all the Ubiquiti access points about 3 days ago. I’m not continually pinging them, but if I look at one of the problem HS110s, it now looks good, after a afoul of stretches of going “zombie” on me.
Of course I’m not going to declare victory until after @Offthewall 's 5 day threshold
I was away for a couple of weeks so I just left the plugs after the last reset on July 23. Five days later they all went off again. All plugs remained NA for 4-five day “cycles”. Yesterday two came back on by themselves (19 days NA - one was in local only mode, the other in remote), the other three were still NA. Tonight, I’m back home and set up a new WEMO plug and reset the five Kasa’s. I’ll let you know how that goes…
Interesting that a some came back. What was the DHCP renewal interval during this time?
It doesn’t seem to be so. DHCP lease is currently set to 30 days now with all the KASA plugs set to reserved. The off/on’s have never seem to be tied to DHCP lease time which has been experimented with ad nauseam.
I couldn’t think of anything else that would have brought those two back after several weeks, particularly the one in local only mode.
Wanted to follow up with a minor update:
I mentioned that I replaced all my Google devices that were causing issues. Well, I couldn’t live long without them. I attempted to go to Alexa Show’s and they are just absolute garbage, filled with problems, firmware bugs, non-stop spam etc. I purchased new Nest Hubs (Gen 2 vs my old Gen 1) and put them all back.
The first thing I did was check the PCAPs for communication between Kasa and Google and sure enough, even with the Gen 2 on Fuchsia they want to communicate with the plugs non-stop. Since I knew this was problematic I created a Layer 7 firewall rule that only allows the Kasa plugs to talk to Sense and HA. This has isolated the chatter to those 2 devices only.
I’ll report back if there’s anything that looks out of the ordinary with the Level 7 rules in place, but based on my current PCAPs there’s no communication between Google devices and Kasa.
Like clockwork, the 5 Kasa plugs went NA right on schedule, at a perfect five day and a few min interval from the last NA event. The WEMO plug stayed on. If this pattern continues, the solution is obvious. Trash the Kasa plugs and replace them all with WEMOs.
I’m gonna go out on a limb here and say it’s a device on your network causing an issue. I think that ultimately, it’s Kasa at fault, but something else causes the erratic behavior. I have no idea what that device would be for you, and only a bunch of investigating and looking at network traffic will tell you. I know you said you have Google devices on your network. It may very well be those causing the issue as it was for me.
I removed everything Google and only put back the hubs, but the doorbells, cameras etc are all staying with enterprise grade (non-google) equipment from here on.
I wish you luck.
I will keep this thread informed on the success (or failure) of the Wemo plugs in my environment. I ordered two more but it seems their availability is very limited and may have been discontinued.
I will also keep a couple of the Kasa plugs online just for comparison.
I agree that the Kasa plugs are likely reacting to some regular event on my network. But since ALL else performs flawlessly, it seems like a fools errand to try to locate and eliminate whatever that may be.