Just thought I'd ask to see if there were any significant performances/code improvements above functionality
Some, but not significant. The next revision may include some improvements. Hubitat is implementing a new switch in the comms code that may improve error processing.
Dave
1 Like
Does this support or are there plans to support any of the advanced in wall switch configurations like "double tap" or "long press" as a trigger for rules?
Also what is the best method for adjusting fade on/Off speeds when it comes to dimming switches, should that still be handled in the Kasa app or are there plans or is it even possible to make that configuration local?
This specific set only supports TP-Link devices. These devices do not currently have tap/double tap capability.
Dimming. Look on the Device's HE Page and see if it has a default fade speed. If so, then you can set a default for the device. Additionally, when sending a level command to any device, you can specify a fade speed (in seconds). In text format, the command would be level(55,6) where 55 is the level and 6 is the fade speed in seconds.
I have the Kasa HS220 Dimmer and that has double tap/long press functionality within the Kasa app. So do you mean they do not have the double tap/long press functionality at all or just using this driver/app?
This Hubitat Integration does not emulate the Kasa App. It provides for ON / OFF / and DIM (level and fade speed) for the HS220.
For my information, what does the double tap / long press function do within the Kasa App? In mine, it does not work for any of the devices (I do not have a HS220.)
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
