[DEPRECATED] Kasa Plug, Switch, and Bulb integration

Its a configurable trigger, so you can do "gentle off" or set to a predetermined brightness, etc.

If the functionality is within the Kasa App, it is probably processing within that app. If it is at the wall switch, same thing. Not supported in the Hubitat DEVICE integration (which does not try to do all Kasa app functions).

In Hubitat, you would generally set up a virtual device with (for example) On, Off, and Level commmands. You could create rules (gentleOn, gentleOff, levelOn) that would execute these.

That being said, I currently handle the gentle on/off with the preference "Default Transition Time". I could add a preference "Default Level" that, if set, would set the level to the Default whenever On is commanded and the device is off. Interested in this feature?

Can you explain this a little more. Would this allow a sort of default brightness to be set, without having to turn the lights on? Like for instance it could be changed every time the mode changes so there will be a default brightness in every mode.

On another note, I am not super interested in the Gentle on/off, the reason I was asking for the double tap/long press functions was because I was hoping to get additional triggers out of the smart switch for more rules/automations.

Tap Interface: Unfortunately, the devices do not put taps out on the wifi interface. Additionally, Hubitat does NOT listen on the wifi for data from external devices. It opens the communications port, sends the command, gets the response, and closes the port.

Default Brightness. If implemented, there would be a single default brightness for all conditions. I think you need to learn how to work rule machine. With that, when you use Hubitat to turn on the device, rule-machine would set it to your default brightness based on the mode, time of day, sunrise-sunset, etc.

I can do a sample Rule (very simple, based on time of day) of this for you in Rule Machine using my bulbs as a test bed. It would be the same for your switch(es).

Tap Interface: No worries, I was just wondering/hoping.

Default Brightness: No I know how to use RM, and am currently using it to do as I said, I am just trying to find ways to cut down on the delay, since the fastest polling is 5 seconds. I am also trying to use the built-in Mode Lighting app to do this, but it is giving me a lot of issues and doesn't want to turn on my lights, but successfully turns them off which is very odd.

When looking at my HS220's Event log, shown below, and looking at the device event documentation, I noticed that the "Type" column is empty. Would it be possible to differentiate between a "Physical" type which would indicate a physical press of the switch versus a "Digital" type which would be a for example a tap on a dashboard? The reason I ask is because some apps, such as the built-in "Mode Lighting" app appears to need the "physical" designation in order to function properly, at least according the this thread and the staff member there.

Also is it possible to report the dimming state in the value/description columns?

Event Log:

The code for the HS220 only has been updated from Version 5.0.1 to 5.0.2. I tested on a HS200 switch (I do not have HS220) and the attribute adds the type: physical when added. To upgrade, use Import feature in the driver file.

switch off DEVICE 2020-04-05 03:46:09.059 PM CDT
switch on DEVICE physical 2020-04-05 03:45:22.974 PM CDT
1 Like

Thank you so much, it works perfectly. Is there a way to implement "Digital" type when it isn't a physical press. I'm not sure if it really matters, but that is just what the Device Event documentation says it should be, so it might be nice to avoid errors down the road.

I will add this and digital in a general release of all eight drivers. I have seen zero issues to date; however, apparently the app you are using uses this switching. (note that this applies only to the HS200, 210, and 220 implementation, so very limited.)

Thanks for helping.

1 Like

Couldn't it technically work with even the smart plugs because those have physical buttons as well?

Yes. The drivers will not limit smart plugs. The "physical" type will define that the switch command did not originate within Hubitat. So running from the Kasa App is the same as pressing the physical switch.

When looking at your driver code for the HS220 I found a potential issue, not a functional one, but more likely an oversight/lack of having a unit of your own to test. But in the quickPollResponse function it updates the "level" state with this:

else if (status.level != device.currentValue("level")) {
		sendEvent(name: "level", value: status.level)
		logInfo("quickPoll: level: ${status.level}")
	}

But when looking at the device the "Level" state simply does not exist as shown below:

Update: I think I fixed the issue, status.level is not a parameter, it seems to be stored in status.brightness so I changed all of those and now it seems to be working. Does that sound right? BTW, where can I find all of the parameters contained in status or device?

I have another feature request, a way to 'silently' adjust the brightness of the dimmer without turning the light/switch on. When i looked at the code this shouldn't be too difficult, just a simple modification of the normal setLevel function, here is what I have below:

def setLevelSilent(percentage, transition = null) {
	logDebug("setLevelSilent: level = ${percentage}")
	percentage = percentage.toInteger()
	if (percentage < 0) { percentage = 0 }
	if (percentage > 100) { percentage = 100 }
	percentage = percentage.toInteger()
	sendCmd("""{"smartlife.iot.dimmer":{"set_brightness":{"brightness":${percentage}}}}""", "commandResponse")
}

Also when messing with this, I'm not sure if that duration field is actually doing anything, IRL and I can't find it referenced in the code. I think it comes from the capability "Switch Level" but I am not sure and I don't think we have access to that right?

I'm having a weird issue with three different HS220s. Once I add an HS220 as a device using the app & device and then acutally use it to turn the switch on/off once, the switch only changes states with a 20 second latency. This then persists with other applications (Kasa/Alexa) even if you delete the device using the Hubitat app. The only way to restore the switches to immediate response is to completely reset them to factory. I've tried this at least twice on each of three switches.
Any insights?

TIA

Without error messages it is very hard to say anything. Not knowing your expertise level (so excuse me if I ask the obvious), some concerns:

  1. Did you install the devices into the Kasa Application? That is required. This step assigns local IP addresses to the devices.
  2. Did you assign Static IP addresses for the devices? This precludes the IP address changing and having to rediscover the devices (takes about 20 seconds).
  3. Do the devices work in the Kasa Application when the problem is occurring?
  4. What driver/app version are you using?
  5. If this is a recent installation, review the Wiki file at Home · DaveGut/Hubitat-TP-Link-Integration Wiki · GitHub

Level w/o On. Since I do not have a HS220, I can not test these parameters. If you change the command and it works, I will be happy to bring into baseline. (PS, other Kasa devices turn on when you change the level.)

Duration. I will check this today sometime. Replacing my Sensi Thermostat with a Z-Wave thermostat this AM.

I will look at later.

What is in status? Turn-on debug logging and press refresh. That returns the status part of the return message. Copy that and post here so I can fix status (if necessary).

Update. Fade Rate is not supported for this device driver. The transition in the input is for commonality with other dimmers (bulbs).

Thanks for getting back to me. My general expertise level is limited coding (a long time ago) and IT consulting for about 30 years. My specific expertise level for Hubitat is noob, but I'm studying. I turned on logs, but I couldn't find any error messages.

  1. Yes, I installed w/ Kasa. Works fine w/ Kasa until that first operation (on/off) via the device dashboard. That starts the delays.
  2. All devices have static IPs.
  3. The devices work with Kasa, but after the first toggle using Hubitat, the delays persist until I uninstall the device in Hubitat and then factory reset the switch(es). Then the response is immediate. I have replicated this at least six times. Uninstalling/reinstalling everything Hubitat related doesn't help.
  4. Most recent driver/app versions, having uninstalled/reinstalled twice in the last few weeks.
  5. It is a recent installation (see above). I have read the wiki and used its instructions to install the driver/app & devices.

Thanks,
Jim

Updated the driver on GitHub for:

  • change status.level to status.brightness
  • removed non-function parameter in setLevel input.
  • added type to all "switch" attributes.
  • Tested on a HS200, so dimming function not tested.
  • Silent Level. The intent is to have it work like the Kasa Bulbs which turn on when the level is set to ANY value (even current). I don't plan to update at this time since I can not see a use case for the Silent function. But....

Thanks,
Dave

So the code below is working perfectly for me as a silent brightness changer. The reason I wanted to add this is because I noticed that on the physical switch you can change the brightness using the buttons without turning it on.

Use case: Kind of circumvents the issues with polling, say for instance you want the brightness to be "reset" every mode to a default level, like Day/Evening/Night, but you don't necessary want them to come on. One way to do this is with the switch being a trigger triggering a rule to do the brightness, but this would have a delay due to polling. However, if you set the brightness silently at the change of a mode, the polling delay is eliminated.

def setLevelSilent(percentage) {
	logDebug("setLevelSilent: level = ${percentage}")
	percentage = percentage.toInteger()
	if (percentage < 0) { percentage = 0 }
	if (percentage > 100) { percentage = 100 }
	percentage = percentage.toInteger()
    sendCmd("""{"smartlife.iot.dimmer":{"set_brightness":{"brightness":${percentage}}}}""", "commandResponse")
}

P.S. I noticed that that quick polling delay limitation of 5 seconds is purely limited by the code. Is there any reason that you don't allow polling down to 1 second by default? I'm guessing its to eliminate as much uneccesary traffic on the network as possible, but I am not sure.

Alternatively is polling the only way to do this because the Yeelight app, which is built-in, supports their WiFi smart lights and the delay from physical on/off from the remote is almost immediately seen on the Hubitat logs. I wonder how they do it and if there is a way for the switch to "push" a change, versus Hubitat "pulling" to see an update.