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:
Did you install the devices into the Kasa Application? That is required. This step assigns local IP addresses to the devices.
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).
Do the devices work in the Kasa Application when the problem is occurring?
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.
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.
Yes, I installed w/ Kasa. Works fine w/ Kasa until that first operation (on/off) via the device dashboard. That starts the delays.
All devices have static IPs.
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.
Most recent driver/app versions, having uninstalled/reinstalled twice in the last few weeks.
It is a recent installation (see above). I have read the wiki and used its instructions to install the driver/app & devices.
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....
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.
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.
Polling limits. I use 5 seconds because of the high stress on most Hubs with a lower number. You can change the lower limit for yourself, but for general distribution, I do not encourage it. Note: Below three seconds will get into response problems within the hub and may impact error processing.
Thank you @djgutheinz for the amazing support. I'm new to this platform. I have 14 Kasa switches/plugs in my network. Followed your manual installation instructions with static IP address for all of them.
I further installed your Kasa tool app and removed cloud capability on all of them. Still, after a day or so, my hub becomes very slow until I reboot or disable all Kasa devices.
I still see frequent warnings of "L5.0.1 setCommsError" followed by timeouts.
Thank you for the suggestion Mark. There's no app to disable. I temporarily stopped tinycam pro server in addition to disabling couple of Kasa dimmers. So far, wifi traffic is stable and no errors/warnings in hub log. Will monitor...
Just a minor request... I have one HS110 (energy monitoring) plug that I only use at certain times, so I don;t always leave it plugged in. I keep seeing a comm's error in the logs, even though I turn off all the logging options in the app and device. Would it be possilbe to get this warning only appear when logging is enabled? BTW I have updated to the latest driver and app code.
I have the outdoor Kasa outlet (KP400) and version 5.0.1 of the app installed. I have control over my devices with two exceptions:
I can turn on/off each individual device and see the lights (plugged into the outlet) actually turn on/off, but the HE does not update the change (ie. If I turn the lights off, I see the lights go off but HE says they are still on); and
I find that one outlet turns on during the day for no apparent reason. The logs are somewhat useless because the logs do not accurately reflect the state of the device.
A few weeks ago I noticed that you'd implemented the polling changes we very briefly discussed. I wanted to let you know that I've been running the updates for a couple of weeks and thus far it all works perfectly!
Specifically, I use Rule Machine to adjust poll frequency up for just the period where the increased resolution is helpful/required. I'm not only able to capture the data I wanted, but it has eliminated all of the adverse issues for which I could never pin down an exact cause, but came to suspect hub load (of which I suspect frequent polling of devices was a major contributor).
The drivers and code have been updated to Version 5.1.1. The update requires Hub Version 2.2.0 (or later) and incorporates the parseLanMessage switch. Impact:
Operation: Improved stability.
Code:
Updated sendCmd method to add switch
Updated Error Processing to be event driven vice runIn command driven.
Updated app to eliminate the spewing of UDP errors on installation.
Now compatible with Hubitat Package Manager.
The code is now incorporated into Hubitat Package Manager. Link below is for that package. It makes installation and upgrade process more automated. Essentially:
Run package manager and select the Kasa App and Drivers
Run the Kasa Integration app to install devices.
(More explicit instructions to be developed in Wiki in next couple of weeks.)
Hi Dave. I seem to be having an issue with the quick polling on my HS110's. I thought I had it working before, but it may actually not have worked. I can set the poll frequency alright, the state variable changes and a powerPoll is scheduled accordingly. However, it seems that it only works once. After the powerPoll event has run, it doesn't schedule another one and the device is then back to only refreshing at the configured device refresh rate (not the quick polling). The state variable still states the quick poll has been configured.
I'm running version 5.0.1. I haven't upgraded to 5.1.1 because I'm not on HE ver 2.2.0 yet
Mattias,
Disregard the PM responses. I have updated the 5.1.0 driver that works with HE version 2.1.9 as well as the current version. To load the 5.1.0 version with the corrections please use the link below: