I can't see anything that tells me per product whether a Kasa/TPLink device requires an cloud connection or not. I had always assumed they all did, for direct control (automations stored on device run local)
Ok ignore this- partly. I looked on their site and my Kasa bulb is one that WILL run locally. How do I get it to do that since currently it's assigned to my Kasa account?
LAN/CLOUD. All of the devices except (I believe) the old HS100 can work over the LAN or cloud. The only device REQUIRING an Hubit to Kasa Cloud connection is the HS100! When Kasa changed the HS100 to cloud only, I modified this integration from LAN only to allow user selection of cloud or LAN.
Integration Cloud/Lan implementation. This integration allows you to choose whether you want to connect to the cloud and then how you use the cloud (vs LAN).
Device held schedules and scenes. I have not coded access to bulb-specific scenes and schedules stored in the devices. These can be controlled by Hubitat and integrate with other non-Kasa devices. The Hubitat user interface does not have the widgets to create these. Could probably activate these in some way - but this is redundant to Hubitat capabilities.
I just updated your driver and app - now I see the cloud binding settings 
Was I using it on lan all this time without knowing? I thought it was linked to my Kasa account.
What is the default polling frequency?
Same here and they all worked locally and cloud based. I JUST switched to local within the last month.
Polling. Default polling frequency is 30 Minutes. You can set this by the command "Set Poll Interval". The interval your device is using is listed under the State Variables as pollInterval.
LAN or CLOUD. LAN is the best solution. It will work if your external internet is out but you router is OK. I make LAN/CLOUD a user decision since (currently) one device model has had the firmware updated to cloud only by Kasa. It future-proofs from such changes to other models.
Ah I see it now. There was quite a lot going on on that page! 
@djgutheinz
Has anyone tried the KL125 color bulb? Does it work with the existing Kasa drivers?
Yes. Using it right now!
Dave
Excellent, thanks. Are you able to read the text on the bulb? Does it say "Not suitable for totally enclosed fixtures,"
it says "NOT SUITABLE FOR TOTALLY ENCLOSED OR RECESSED LUMINARIES"
Again thank you for your time. It is very hard to find that spec from the internet. For some reason companies do not want to advertise this fact.
Hello Dave,
Doing some architecture upgrades in webcore (in preparation to change all the KL430's over to the lightstrip driver).
While I'm in there knocking around, I'd like to address another issue that I've had since my migration to HE. I was convinced this could not possibly be a driver issue but another user pointed out, it absolutely could be related to the driver.
I was hoping to give a description of the behavior that was on my ST driver vs what I'm observing now and how I expect it to work to see if this sounds like normal behavior with this driver.
When I was on ST, I used webcore and Alexa without issue with controlling bulbs. If I changed the color of the bulb, the level would stay the same and the color would change. Same with CT. No problems/expected behavior.
Ever since I moved to HE, the bulbs are controlled differently and it causes an annoying behavior: let's say the bulb is 50% red, I change the color in HE, Webcore, or Alexa and yes the color changes but it always changes the brightness to 100%. CT changes react the same way (changing to 100%). All my bulbs exhibit this same behavior and it's only been since my move to HE.
Because Alexa routines are configured for switch, level, then color, no matter what I do, the bulbs will always end on 100% because of this behavior. Webcore triggers have their own sets of challenges with this behavior.
I feel like there must be a switch somewhere that tells HE in what order to do the color/level and I just can't find it. I've had to do a series of ugly workarounds to just get my house to not disco every time lights were triggered but I'm ready to pursue whatever the permanent solution is here.
Is this just how this driver works or do I have something set wrong?
The only place I can change the color or CT of any of my bulbs without it effecting the brightness is from the kasa app.
Color: There is NO independent color on color entry into Hubitat. It is on factor in the HSL(hue, saturation, level) entry.
Color Temperature. This is an artificial construct (the Light Strips DO NOT HAVE A NATIVE COLOR TEMPERATURE Capability. I could take my implementation out of the LIGHT STRIP, but.... The method has several steps:
I could artificially change the algorithm after the HSL calculation and replace the level with a the user-entered level - but that is all.
I will look at this weekend on the feasibility and effort required.
Dave
Its not specific to my KL430 light strips. My KL130s do it too. Neither behaved this way when I was on ST.
If I tell Alexa to change the color or color temp of any room, it will always change the brightness of all bulbs regardless of model. I'm assuming from what you said, this is because Alexa is not filling out the S and the L so they are defaulting to 100 and being sent/executed as such.
So while I've seen it mentioned several times the forums to use HSL for the best experience and I understand why, it doesn't help me downstream when I 'ask' for a color/CT change rather than sending a programmatic HSL command.
No, The bulb is receiving a SetColor Command from Alexa including Saturation and Level. It is not always Saturation 100 and Level 100, just mostly. I tested through the Alexa App on my phone. Format below: Color Command: Hue, Saturation, Level, Driver generated Name
Bottom line is the one size fits all Alexa color definitions do not meet your requirements. This can be fixed with rule machine.
Rule Machine Fix: You could fix this in rule machine. (below is concept not RM code):
The same can be done for Color Temperature sending a setCT command to the device instead.
This method will create two actions on the light:
If you find an unacceptable blooming effect, you could create a virtual driver then connect this to Alexa. When calling a color in Alexa, you will change it on this virtual device, It would then translate to your custom colors. Then Rule Machine would be used to read the HSL or CT /L from the virtual device and set your actual device to the custom colors. More complex than the rule-machine only method, but it would eliminate what might be an annoying quick color change after modifying.
Dave
You have given me a lot of information that's gonna take me some time to digest and figure out the best path forward. I really appreciate how informative you've been.
Let me take this information, do some research/testing and I'll circle back if I have any questions.
Hello Dave,
In my rule uplift for lighting today, I have discovered that I'm out of assignable IPs on the .24 segment.
Don't worry, I'm not asking you to solve that problem.
I knew this day was coming and I told myself "you just have to stop buying TP Link devices" at least 50 times after purchasing the last 75 devices.
I thought I was going to be alright but bringing holiday lighting back online from last year is driving my IPs over the edge.
The good news is, I have an idea. I have another HE with ZERO TP Link devices on it (nor the app). Can I install another instance on the kasa app on the other HE and configure it and all of it's TP LINK devices to the .25 subnet?
I would hate to start splitting up my lighting but I could easily buy myself 10-15 IPs on 24 if I move all my seasonal devices to another hub on .25.
Do you think this will work?
The problem may be your router not allowing more than X static IP addresses (period). Adding another segment may not help.
What is your router model and approximate year? I believe newer routers do not have the problem that earlier ones did in loosing resetting non-static IP address unless you reboot the router. After a reboot, you would have to run the Kasa App and add/update devices. That command will update all ip addresses to those within Hubitat.
Also, error handling will attempt to update the IP addresses when an LAN error is encountered (four consecutive failures). This will also automatically update ALL IP addresses,
So I am definitely not the expert of the intricacies of my network but this is the most basic info I can provide to describe why I have this problem:
Our network is a 255.255.254.0 or a /23 subnet we have addresses from 192.168.24.0 - 192.168.25.255 We do not have a problem with the number of assigned ips we can have. We are running a ubiquiti network that is business class. The hubitat does not expose the sunbet in the api so the drivers can not calculate what parts of a network are valid to scan. the last driver i looked at only scanned from .1-.254 of a network it did not take into account the subnet.
Gosh, I hope that made sense to you. If there's a simpler solution, I'm definitely game for learning something new but it was my understanding from previous attempts that this was just going to be a limitation with our unique situation.
UPDATE:
Best fix is to try opening the integration app, entering a new segment, and installing the new devices. The new devices should still be a child with the other devices. disadvantage is that current error handling that resets the IP address on error will not work as anticipated. If you are able to add a new segment, I will modify the error code to consider segment in polling for new device IPs.
Dave
Download the Hubitat app
