I've discovered a bug in the KL130 V2's that has recently revealed itself to me. I am a Power User with well over 100 TP-link devices and more than 60 of them are bulbs. I have a mixture of V1 and V2 KL130's. There is no problem with my KL130 V1's whatsoever.
A few days ago, I noticed my routines weren't firing for some of my bulbs. My routines are all built in WebCore via the Samsung Smartthings platform. I noticed that I only had limited control of the KL130 V2's from within Smartthings. It didn't indicate there was a problem with the connection but each of these bulbs had limited responsiveness. As a result, because my Alexa is configured to grab TP Link through Smartthings, Alexa was also not controlling these bulbs.
Control continued to work flawlessly within the TPlink app. A few days ago, I came to this forum where I saw some people discussing a pinging issue with the KL130's that ended with a beta firmware update. I spent the weekend running some network tests, rebooting my network and pinging the bulbs. While there was an occasional packet loss, the description of being pingable, then not for 30 seconds turned out to not be reflective of my symptoms. I have a rock solid Ubiquiti system with multiple WAPs and have no problems with the traffic/coverage. My network tests confirmed that this was not a connection/networking issue. My network has been running without issue for nearly two years with well over 200 devices.
I continued to have the problem for days. I played with the lights in the app every chance I got, trying different things to see if I could reproduce something. Finally I got something concrete. If I controlled the light from TP link, the next time I try to control it from Smartthings, it would allow me to turn the bulb on, dim, change huge, change color, but as soon as I turned the bulb off, I would not be able to push any more commands from Smartthings to the bulb. This turned out to be perfectly and consistently reproduced. I appreciate the fact that I understand what one of the issues is but doesn't bring me closer to an answer.
Tonight, again playing with the bulbs, I was hung up on the fact that all these bulbs were brand new V2 bulbs WITH the recommended firmware. I moved a bulb to a different lamp 2 floors away so it would connect to a different access point and I had the same result. I was stuck on the fact that these were all V2 with the problem but I had another V2 on a tree which doesn't follow the normal white/daylight programming I have for all the other lights. This bulb still worked fine and was the only other V2 bulb in the house. What could be different?
.....Circadian Rhythm. The bulb on my tree is set for "last on state". One by one I removed the Circadian Rhythm feature from all my V2 bulbs and they immediately started responding appropriately in Smartthings and Alexa.
The super weird thing about this is that all these bulbs have been installed with these settings for more than 2 months and the day it started, I lost power multiple times within a few minutes. It wasn't enough to reset the bulbs to factory but that seemed to be when the issue started (I know that makes zero sense).
So, I am here today reporting an issue with KL130 V2 is having issues executing commands via Smartthings only if Circadian Rhythm is enabled in the TP-LINK app. For now, I have a workaround by disabling Circadian Rythm in these 9 bulbs. Of course they are bedroom bulbs and that's not ideal but it's not the end of the world while I wait for a patch under normal dev timelines. While you're in there knocking around in the code for Circadian Rhythm, it sure would be swell if you copied the Circadian Rhythm code over into the KL430 strips . My scripting is having to do a lot of heavy lifting to recreate the functionality that'scurrently a feature gap.
I just want to go on record in saying that I'm super proud that I was able to get to the root cause of this issue. I work for a software company and I'm just a big smart home nerd. If you need me to test, send logs, etc. Let me know.