Sending a nak is quite different than ignoring the request. I haven’t used Aironet for a few years, but I’m pretty sure that a nak would not be logged as “no response” by the AP. And a nak would certainly elicit different behavior from the DHCP client (returning to discovery).
So in the specific case that you observed, I would expect that either the renew was dropped between the AP and the DHCP server, or the ack/nak response was dropped coming back from the DHCP server. Of course it also could be that the DHCP server is defective and didn’t send any response, but I think that least likely.
Ok I’m not sure why you’re attempting to split hairs here for something that doesn’t really matter at this stage. I explained why I said what I said, and if we really want to get technical its a DHCPNak. Second, if a DHCPNak is returned the client would be forced to reauth with the server which would be a response as you correcly mentioned and not a “no reponse”. Also, as I said earlier that one DHCP issue could have been an issue in the backhaul as it is a repeater. I don’t have any evidence that any of this matters. I documented in writing my early findings when I was at the beginning stages of looking at everything. Maybe that’s my fault for putting my thoughts out there for people to digest and maybe for the sake of not splitting hairs I should use the technical terminology at every turn.
After everything I’ve seen I don’t think it’s a DHCP issue within the network, while earlier that was on my radar. The devices, although they act strangely with DHCP, do get leases and there might be a DHCP issue with the KP115 firmware, but I can’t prove that because I have no way of seeing what the firmware is doing. No one here has been able to provide PCAPs with any information indicating a DHCP issue. On the contrary there’s ample evidence that the KP115s are getting leases from everyone who has chimed in and the work @Offthewall has done with switching DHCP servers and lease times. Therefore, I’m moving beyond that and looking at the PCAPs that I have showing no reply from the KP115s. I think that there’s much more value in the evidence that I have over the evidence that I don’t have.
Let’s keep in mind that many many many posts back most everyone was looking at this as an infastructure issue. I’m 99% confident that it’s not so I’m trying to get the conversation moving in a direction away from infastructure.
When they go offline (n/a) I get no data in the Sense app at all until I manually reset. When they are working, they work fine with no gaps.
Here is a good example of the KP115 that is on my server rack which has a pretty constant 300+ watt draw. You can see the two gaps where it went N/A along with the other 4 KP115’s.
@Offthewall thank you for that information. We might be seeing different issues, but I think there’s something wrong with the KP115s. I’m going to gracefully bow out of this thread and work with the Kasa/TP-Link people since I’m confident that it’s on their end. Hopefully, if I can get them to look into it, it will fix your issues and my issues.
I’m not splitting hairs, I’m doing basic protocol analysis. Generally the most difficult issue in network protocol design is dropped packets. Unless one is specifically designing and testing a reliable protocol, packet loss is often not adequately tested for. In the field, when faced with situations in networks where it works for the majority, but occasionally fails for others, it is usually the result of multiple time correlated events. Most often, one of the events is a dropped packet.
As you note, enterprise grade equipment provides a higher level of information and analysis. That your AP is logging that a DHCP request was made through the AP but no response came back through the AP is a clear indication of dropped packet in the network. [Yes, it could be that the DHCP server was offline at the time, but I expect that you would have identified that. Of course the DHCP server could be defective in a simple way, but that doesn’t get though basic QA.]
As I speculated above, I’m exploring issues that could be triggered by packet drop(s).
@DevOpsTodd@dennypage@Offthewall I want to thank all of you for the incredibly enlightening and thorough troubleshooting you’ve done here. I’m crossing my fingers that a fix can be issued on TP-Link’s end and solve a lot of the issues from the thread above.
While you await a resolution from TP-Link, you might try the suggestion above. While it would not actually resolve the problem, if the the issue is associated with an address renew or change, using a high lease time should decrease the interval between occurrences for you. Recommend something like 14400 or 28800 (20 days). Also, if you do that and the issue still occurs in 4/5 days then that would rule out a DHCP issue.
After my TP-LINK experience today I’m sending all my KASA Units back to Amazon tomorrow. 4.5 hours with techs unable to offer anything except repeating the same questions over and over, most of which had nothing to do with the issue gives me no confidence.
Adding a device should not blow out your entire KASA device network and all devices in your KASA as well as making the “offline” when their diagnostic lights and my Routers show they are online and transmitting data to their cloud servers.
Unfortunately they are flooding the Sense Device with bad info and so it’s not usable. Unable to turn off KASA data in Sense App either as a result.
Give me info for the HA KASA emulation and where can I get it as this isn’t ready for prime time.
@Beachcomber if you’re interested in knowing more you can PM me. I don’t want to take this thread any more off topic than it already is. Home Assistant, Hubitat, Zwave switches, plugs etc have nothing to do with Sense so its not really appropriate to fill their forum with that. It’s not an easy thing to get going but I would be more than happy to explain. That goes for anyone who might want help. My inbox is open.
As @DevOpsTodd mentioned, this is a fairly complex project for those who might not be familiar. I’d recommend starting with the Home Assistant guide above, rather than trying to outsource this to someone @Beachcomber. It’s definitely something you’d want to be able to tinker with along the way.
Just paid a quick look on all my Kasa smartplugs to see how they have been doing since I moved my home network from Apple to Ubiquiti. So far, so good. The two devices that fluctuate between above 0.5W and below, still show as dropping offline (no hourly data) when the Kasa power is below 0.5W for more than an hour. My lone KP115 is hanging in there. But once again, I still have it back on 1.0.7 firmware - not going to mess with it, if it keeps producing correctly.
In general these plugs are just crazy. I have 4 of the KP115s and only two are bugged out. Both of the ones that work share the same APs as the two that fail. One interesting thing is that the two that bugged out are connected to always on devices that consume moderate and stable power. The two that work are always on as well, but consume sporadic amounts of power.
I’m going to try reverting firmware today and also seeing if I can send reboot commands every 2 days to keep them working.
Take the context of this link however you want but in my humble opinion it looks like TP-Link might be moving away from local access all together. The Sense team might want to look at better integration partners or transitioning to the cloud api if it can pull historical data as I’m sure the API is not going to provide 2 second polling abilities. I was referred to this link by support indicating that they might not be willing to look into local access issues but will return to me with more information. @RyanAtSense have you guys been able to confirm or deny future sun-setting of the local access on Kasa devices?
Thanks for sharing. This came up a while back on here when local API access was originally disabled for UK plug models. Unfortunately, I don’t have much to share, but we’re keeping our eyes open for any news and are always looking for new integration partners that meet our requirements.
As an update to this saga… today I forced the KP115s off of the cloud and attempted to see if local control only would cause the issue to resolve. It did not. So then I attempted to do a command initiated reboot, which worked, but it didn’t resolve the issue either. It appears that a hard reboot is needed in order to clear the issue which can only be accomplished by a power pull as noted previously.
