It’s a child device id (string) like so: 8006D6539AE4642F13E80F5CBA846C861D95310004. I’ve never dug into it to see how it is formed.
[BUG] - All five kp115 smart plugs went offline according to Sense but are still really on
So I’m off to an interesting start. I added 2 HS300s and an additional Hue light and it crashed my Sense… It’s still connected to the AP, but it’s not sending data out anymore. It will also respond to pings but shows offline in the web and mobile app. You can see the usage tank and go bye bye!
@DevOpsTodd btw: when I upgraded my Unifi AP’s to 5.x software, most of my IoT devices dropped off the wifi grid. I went back to 4.3.x firmware and things went back to “normal”
@dannyterhaar first of all I’m not a fan of UniFi, so I don’t work on it often. I normally convince our clients to switch away from Ubiquiti.
Nevertheless, sounds like an issue with protected management frames. If you update the firmware again look for PMF and disable it. This could also be listed as 802.11w. You could try with it enabled if it allows for mixed case or disabled if it doesn’t.
There’s so many things that can cause issues in a wireless network it’s not easy to diagnose in a forum like this. If anyone has general networking questions not related to Sense pm me, I’d be more than happy to help.
Sorry if this has been covered already in this thread, I tried to skim through but it’s a long one so totally possible I missed something.
From my experience working on SenseLink, during which I was absolutely hammering my Sense with garbage test data, I learned:
- The Sense meter doesn’t seem to care about the source IP or MAC address of the response packet. A single SenseLink instance (i.e. one computer) can report multiple “virtual” plugs and Sense has no problem with all of those being at the same IP and hardware MAC, and reports them all as discrete plugs. Having two plugs with the same name/description doesn’t even seem to matter!
- Sense DOES care about the virtual MAC address reported in the JSON field in the UDP response to the broadcast - essentially this line of the response code. I discovered that if you set two virtual plugs with the same value in the MAC field, it’ll basically flip back and forth reporting each value.
I never tried actively varying the IP of my testing device, but I kind of doubt it would matter much to Sense as long as the response kept the same value for the virtual MAC.
@Offthewall I wasn’t sure if you had any other Kasa plugs, but maybe you could try running an instance of SenseLink (on the same VLAN, Wifi SSID, etc. as your KP115s) on a RaspberryPi or computer, and see what happens to that when the KP115s all fail? I’d recommend just configuring a static plug reporting something small like 5W.
You can also set the debug flag when running SenseLink and record/monitor the log output. It will echo out all the broadcast requests from the Sense meter and the generated response JSON. That at least might help you put to rest whether the Sense broadcast requests are failing to get the plugs for some reason - though I agree with some of the latest discussion, my guess would be a KP115 issue.
Hope this helps!
I double checked and it was already off
thanks for the tip
@dannyterhaar I assume that on the 5x series firmware you’re still experiencing loss of all your IOT Devices?
@cbpowell The Sense using the MAC as the identifier is what I assumed. Thanks for clarifying that and I didn’t know that there was an available debug so thanks for that as well.
@Offthewall Yesterday I installed 2 HS300’s and those crashed my Sense as I reported earlier. I put in a tech ticket so that hopefully the Sense team can see what happened and diagnose that issue.
Today I installed a KP115 and immediately noticed that the device would go on and off (n/a). When analyzing the network traffic I see that as I suspected here:
For some reason the plug just isn’t responding to the broadcast from the sense. The HS300s respond as they should but the KP115 is not.
Additionally, the KP115 is being forced off of the network and denied association due to excessive frame loss rates and/or poor conditions on the current operating channel.
What’s even more strange is that the KP115 is communicating with all 10 of my Google Home Hubs that are requesting system info, not however requesting emeter data. Google is not configured with Kasa at all.
At this point I started doing testing such as forcing the devices to use the same AP and checking if the Kasa app was receiving data. I noticed that the KP115 in the Kasa app was locked up and after checking the network, I could see that the plug stopped checking in with the Kasa servers. It was however still responding to my Google devices and ARP requests.
As of right now my analysis is that the KP115 is solely to blame. From what I can see the issues are related to the plug being buggy. I would like to note that the KP115 and the HS300 do have different WiFi chips and different firmware versions.
After a number of resets the KP115 is accurately reporting data to Sense. I’ll keep an eye on it and report back with additional findings.
Exactly 4 days to the min all 5 KP115’s went n/a to Sense again. They continue to respond and work in the Kasa app (different from your experience). It seems it’s related to multiples of the one day lease time even though they are set to static IPs now.
So let me explain how that works. Your router is the DHCP server and the devices connecting to it ask for an IP address. When setting a reservation (which is slightly different that a static ip) the DHCP server blocks out that assignment unless the MAC matches the reservation. So the lease will still expire according to the lease schedule and it should just renew with the same IP.
Every DHCP lease life cycle will follow a specific pattern, it starts with the initial lease, a normal operation period, a renewal period and if the renewal fails a rebinding period. This is also why I originally asked if it was 1/2 of the lease time as that’s typically when the issues happen, but not necessarily always.
- At day 0 it will request a new lease
- During normal operation, the client can use the address
- Halfway through the lease time it will try to renew the lease so it can keep the same IP address.
- If renewing failed (DHCP server is offline for example), it will try to extend the current lease with any active DHCP Server, which in your case doesn’t exist (more than 1).
If you wanted to test this theory, that it might be the DHCP lease assignment, change the lease time to some odd number such as 1500 which is 26 hours. This would either prove or disprove the theory. If after 4 days and 4 hours or 5 days 5 hours etc they go offline then we know it’s something to do with the KP115 getting a lease. If this network has mostly static devices (meaning that you don’t have a lot of guests or devices that disconnect frequently) you could set it to an enterprise level of 8 days.
If for some reason the KP115 is defaulting to a link-local address instead of renewing we would be able to see this by changing the lease time or inspecting the network for any rogue ip addresses.
Just to help you diagnose…
1 - Is your phone connected to the same network as the KP115?
2 - If 1 is true, try going to cellular and see if you can still command them when they are offline to Sense?
3 - I assume doing packet captures is beyond the scope of what you want to do?
The Kasa App has local and cloud capabilities and I’m wondering if they both work.
I already reset them, so I’ll have to wait 4-5 days to try that.
Likely coincidental, or perhaps configuration oriented. I’m running 188.8.131.5227 without issue. Make sure you disable the Auto-Optimize network setting (in Site setting), and the Block LAN to WLAN Multicast and Broadcast Data (in individual Wireless Networks settings).
Just to see what effect it has, I took DHCP duties away from the FIOS router and am running DHCP on a server machine in the network. I rebooted everything and they all now have a new lease from the server’s DHCP. I did reserve the Sense and the KP115’s new addresses on the new DHCP server as well.
Both are/were off when I tested with 5.x firmware
Not only the tp-links but my nest thermostat, my openevse ess* wifi chip and even sense were kicked off the network with that firmware.
Sounds like you had some significant issues. By chance do you recall what specific version you were testing? There is a known issue surrounding use of Proxy ARP in 5.43.37, might be another one to check. FWIW, I moved from 184.108.40.20661 to 220.127.116.1127 (even though it’s not GA) last week on my UAP-AC-HDs without issue.
Due to the fact that my issues with the Kasa devices are wildly different than those of @Offthewall I’ve moved my issues to a new thread in order to keep this one relevant. I will continue to add any information that might help this thread if I notice similar issues. As of right now I’m not experiencing the same issues and while they might be related in some undetermined way, at this point I’m sure my issues are with the Sense Monitor as it fails to even attempt outside communication.
The new thread is: Sense Communication Crashing with Kasa Devices Connected
Well, 4 days, 6 hours after switching DHCP servers, all five KP115’s went n/a simultaneously. So I’m gonna say it has nothing to do with the FIOS’s DHCP server.
I’m just about ready to chuck all this in the trash.
Yes, the Kasa app can’t still control and monitor the plugs both locally and via cellular data when they are n/a to Sense.
Ok couple last few questions.
How many integrations do you have in total. I.e. hue, Kasa, ecobee, ifttt
Are your plugs on firmware 1.0.17?
TP Link is the only integration I have.
All KP115’s are on v 1.0.17
Welp… I don’t want to say much yet, because I’m still watching mine to see what happens in a couple days. But I have tried a number of things in an attempt to get them to fail on my network. This includes IP changes, WiFi channel changes etc. So far the only time I’ve seen the N/A appear on the plugs is when I first install them, which is cleared with a couple power pulls and when I forced a MAC address change, which was expected.
The issues that I experienced, documented in another thread, were because the unit was overloaded. In your case with a single integration of 5 plugs, that wouldnt be the case. I have well over 50 devices integrated.
I’ll continue to monitor mine and report back if I find something.