@xpanmanx thanks for the detailed info. My network is a mishmash of old hardware running different services. Everything routes through a Netgear R6700, but it doesn't handle anything else except a couple static routes. I'm gonna take my network back to basic bare bones, see if I can get it working, and then start turning stuff back on. After the work I did last night, I'm starting to think this is a network configuration or some sort of network conflict issue. I'll let you know what I come up with, if anything. For now, I have the bulb behind a double NAT on DMZ.  

@xpanmanx One hopes that TP-Link is watching this conversation. We're giving this problem the good ol' college try ... maybe it will be of benefit to them.

@xpanmanx Are you running homebridge?  I narroed it down to my main server.  WHen I disable the homebridge service, the bulb reacts fine to the Kasa app.  as soon as I re-enable the homebridge service, it stops working.  

@jlboggsCO Nope, no Homebridge here. All Amazon/Alexa controlling Kasa, Hue, and August devices.

We have some Apple devices, but we don't use HomeKit. I don't even mention it to Siri.

@xpanmanx so something with homebridge is definitely my issue.  I'm going to try updating everything (a couple plugins are out of date) and see if that corrects the issue.  Unfortunately it sounds like you and I do in fact have 2 separate issues.  Might be worth looking to see if something is DDOSing the bulb.  I believe that is what was happening with homebridge.

@xpanmanx I'm calling this fixed on my end.  A while back homebridge started requiring a newer version of node.js.  I've been putting this off for a while and finally decided to take the plunge and get this updated.  Well magically everything is working again.  My guess is there was a problem with the TPLink plugin and the previous version of Node.js and this was causing some sort of DDOS on the bulb.  Good luck to you getting everything fixed.  I would start looking for something hammering the bulb with requests.

@xpanmanx 

An issue that I have seen so far is bulbs or other smart devices rebooting due to APs with the same SSID, but like you mentioned the device has a dedicated SSID. 

If that may be causing the momentary lapse in ping response then you can try this beta firmware to see if it may help (KL130 v2): link

Instructions are inside of the archive.

@Tony, thanks, I've since returned the two most recent KL130s and tried a KL125, which is working fine.

@xpanmanx what is the DTIM Period set to on your access point?

I don't have Ubiquiti, but my understanding is that they used to default to DTIM period of 1, but they've since changed it to 3 in newer firmware, but that the change only affects new deployments (i.e. it won't change existing settings).

I have a TP-Link EAP225 and it also used a default of 1, but the KL130 bulbs play up and wouldn't hold a connection. After changing DTIM to 3 they're rock solid.

@CX23882, that's a quality response. Thank you.

Ubiquiti's default DTIM setting has been "3" for a good while now. When they made the change, customer-configured DTIM settings were maintained, but default settings were changed to "3". This is true of every software upgrade since.

All of my SSIDs are set to DTIM "3":