[DEPRECATED] Kasa Plug, Switch, and Bulb integration

djgutheinz · January 19, 2020, 5:38pm

you are correct. The issue is that the plug returns the message in two segments (I have seen the two messages on my node.js test system for this and the energy monitor plugs). The UDP (not sure of TCP) does not concatenate multiple return segments from a device.

New cloud version coming. I am in-process of creating a new version that will allow the user to select UDP (supports non-cloud processing) or the cloud version - with an option to switch without having to reinstall. It will take a week or so to finalize (I already have the stand-alone integrations complete). I hate having so many versions; but, as I learn the limitations of Hubitat and user preferences, I find it absolutely necessary.
Dave

My actions:

Open a support topic on fragmented UDP messages.
Beef up the error processing on truncated messages and try to update state based on truncated message.

RichCNJ · January 19, 2020, 5:59pm

I just want to thank @djgutheinz for his continued work on this solution. I'd acquired several TP-Link switches/plugs before I switched to HE and the fact that I could integrate them directly has been great (and saved some money along the way). I still monitor this thread but i can do everything I want. It's nice to be able to set a wake-up sequence that turns on and then brightens the bedroom light as well as activate the lights in the evening based on motion.

djgutheinz · January 19, 2020, 6:14pm

Fast Power Polling. It was a request from several users. I did not want it and do not recommend it. I added it since it is, after all, the user's hub.

Fast poling will look at power in watts at each poll and send an event if changed (which the system must then process). I recommend no shorter then 5 seconds.

How to use.

Set the polling interval in preferences (to 5 seconds or more please).
Using rules, you would set one to trigger when the power exceed (example) 10 watts (Set the start trigger watts based on your dryer on but not running, with the door open plus a buffer.)
The rule (once triggered) would monitor when the power fell below (example) 5 watts. (Otherwise, you will restart the rule when you go to remove your clothes.)
When the second trigger is detected, the rule would notify you.
Optional (but preferred) reset preferences to 0 when done with washing duties. This is generally not necessary for a switch if turned off and your Hubitat is running OK.

Issues:

Power changes a lot, even when a device is steady state. This causes the device to fire a lot of events, each of which the system has to process and promulgate. Therefore, I am checking on changing the power reporting to the nearest 5 watts when in power-polling mode.
A lot of users leave this on all the time. Not really ideal. Uses processor time without any purpose. Therefore, the adding of a user interface accessible from rule machines.

djgutheinz · January 19, 2020, 6:17pm

This brings about a general rule with anything, a saying I hear and used in my career to avoid unnecessary churn:

If it ain't broke, don't fix it.

If your integration is working for you, why update. It can only cause problems.

Thank you for your kind comment.
Dave

Aldo · January 19, 2020, 7:21pm

thanks for your explanation. What is the difference between fast power polling and Device Refresh Interval (minutes) ?? If I want to have a wattage refresh every 30 seconds should I put the fast power polling to 30 and what value to the device refresh interval (minutes)?

djgutheinz · January 19, 2020, 7:39pm

Fast polling for power does just that. It determines the power level in watts only. One minute polling determines switch on/off state, power, and energy (watt hours) consumed.

To update wattage every 30 seconds, you would need fast polling set to 30. I would place refresh interval at a minimum of 5 minutes (or more) in that case.

Dave

Aldo · January 20, 2020, 1:10am

if I use this configuration then the power will be updated every minute:

but if I use the one suggested, the power will just not be showing anything:

what is my error? I just want to get the power that the dryer is consuming every 15-30 seconds for my existing rule to work as should (the smartthings outlet reports the power consumption at every consumption change almost every 1 - 2 seconds but just migrated to this tp-link because it has higher amperage). Could you suggest the settings to achieve this?
thanks

djgutheinz · January 20, 2020, 5:49pm

Thanks for your patience. I found an error in the driver code precluding fast polling from starting. It has been fixed and updated on GitHub.

Hint: Open the driver in the editor and try using the import button at the top. It should update the code to version 4.6.03 (noted on about line 20). If that fails, you will have to go to GitHub.

Dave

Aldo · January 20, 2020, 6:22pm

thanks for all your help. I will give it a try tonight once back home

Aldo · January 21, 2020, 5:48am

I have tried the 4.6.03 but I am still not able to get the correct power report. I had to push the refresh button for the power to be shown

djgutheinz · January 21, 2020, 5:55pm

Sad you are having issues and thanks for your patience. I just tested my HS300 devices and the fast polling works. There was a difference in the parsing from Refresh and power polling, so (today) I changed power polling to be the exact same as refresh.

Try the update (using import). If that works, we are done.

Failure: if the update does not fix the issue, I need some logs to see if the data format has changed. See procedure below:

open the device's page in hubitat
enable debug logging and description text logging
Set fast power polling to 0
Save preferences.
Run refresh.
On the device's page set fast polling to 15 seconds
Run save preferences and wait 3 seconds.
Open live logging in a separate window or clear the open log window.
Copy the contents and paste the image in a return message.

Below is an example of my log on 4.6.03. I did this by (a) copying the log text, (b) paste it in the edit window, (c) select the text in the window, and (d) then using the </> button above. This pasting message is easier to read and can be copied for detailed analysis.

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:53.531 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse: Power set to 183 watts

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:53.524 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:38.417 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse: Power set to 180 watts

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:38.383 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:23.289 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse: Power set to 184 watts

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:23.283 am [debug](http://192.168.50.24/device/edit/3942)Video 4.6.03 powerPollResponse

[dev:3942](http://192.168.50.24/logs#dev3942)2020-01-21 10:45:08.177 am [info](http://192.168.50.24/device/edit/3942)Video 4.6.03 Status: [switch:on, power:2, energy:0]

Aldo · January 21, 2020, 6:10pm

thanks for your help, I will give it a try tonight and feedback to you my results

JimGT · January 22, 2020, 2:52am

@djgutheinz and community,

First off, thanks! This integration is great!

Question: when using Hubitat, what's the best way to get TP-Link Kasa smart devices to be controlled via Alexa? Do you expose the devices via the Hubitat skill or connect them through the Kasa skill for Alexa? Any recommendations or strong reasons for doing it one way or the other?

I have previously had the Kasa Alexa skill enabled and linked the devices directly through that. I have had no real issues or complaints doing things this way for the past year. I used the Hubitat Alexa skill for other, non-Kasa devices (some virtual), etc. However, I just had to reset my entire home wifi network and am in the process of reconnecting everything and this question popped into my mind.

What do you guys recommend and why?

Thanks!

Ken_Fraleigh · January 22, 2020, 3:00am

I am sharing mine through HE to Alexa and have disabled the TP-Link skill in Alexa and un-linked the bulbs from the TP-Link cloud. My reasoning was that HE is controlling them locally and reliably (much thanks to @djgutheinz for his hard work) whereas the TP-Link Alexa skill was not always reliable for me and most importantly it ticked off my wife when it didn't work.

Aldo · January 22, 2020, 6:28am

hey @djgutheinz, it looks like the problem is fixed thanks a lot for your help and support is really appreciated. What is the min polling interval you recommend to avoid slownless issues in the hub ? can I do 15 seconds?

djgutheinz · January 22, 2020, 3:32pm

JimGT. What Ken states is how I do it.

Unlinking from TP-Link cloud is not necessary, but it can be done using my KasaTools app. The Kasa tools can unbind (unlink), bind, or reboot a TP-Link device.. (Note, the Kasa App no longer can unbind the device, but still supports binding the device when on your LAN.)

aaron · January 22, 2020, 4:35pm

Yeah Dave is pretty darn awesome with these integrations and continued goal to advance his apps/drivers to better support the community and provide efficiency.

JimGT · January 23, 2020, 2:28am

Dave & Ken - Thanks for the input.

For what it's worth, I had a couple dozen Kasa devices linked up to Alexa for over a year without any noticeable issues. I added Hubitat to the mix about 3 months ago without changing how everything integrated. I just disabled the Alexa TP-Link Kasa skill and rerouted all my devices though the Hubitat skill as you guys suggested. All seems to work fine so far with no noticeable difference from before (wife and kids seem unaware that the change even happened).

Correct me if I'm wrong, but won't either method still require an internet connection when asking Alexa to control Kasa devices? In the case you recommend, it's Alexa communicating through the internet with Hubitat (which then locally controls the TP-Link Kasa devices). In the other method, it's Alexa communicating with the TP-Link Kasa servers to remotely control your devices, right?

As such, the only real changes I can think of are:

You're going through Hubitat's servers instead of TP-Link's
You have more direct control over which devices to share with Alexa (TP-Link shows Alexa everything while Hubitat lets you choose device by device)
It's probably easier to keep all the devices' names and controls in sync with things single-threaded (TP-Link to HE and then to Alexa) versus having TP-Link communicate with both HE and Alexa.

Anything else I'm missing here?

Thanks!

Ken_Fraleigh · January 23, 2020, 3:25am

I think it sounds like you have a handle on things. If you’ve been using the TP-Link Alexa skill and not had any issues then I would put the devices back on that. It gives you a backup way to control the devices. It has been over a year since I used it and at that time it wasn’t very reliable for me. I’ve not pursued adding more TP-Link devices as I don’t like putting unnecessary stress on the wifi, and soon realized that TP-Link devices come on one at a time, which is undesirable with mostly multi-light fixtures. I’ve added over 120 zigbee devices since, but must say that my original TP-Link bulbs are still going strong.

Aldo · January 23, 2020, 6:23pm

Hey @djgutheinz I found an error today because the power consumption was not being updated when I was using my dryer:

this is the error in the device events:

so when I found the error after that I enabled debug logging and by doing this it looks like automatically the error was changed from true to false (without doing anything else) then I went to the logs and this is what is shown:

those are device settings:

Is there something else could be added to the code to unlock the device from error in case it happen again?

And as well after all of above I checked again the device power and it should be showing around 14 watts (as the dryer was open then the dryer light was on and it consumes that power) but it was showing only 2 so I did your steps and here are the logs:

here in text:
dev:14742020-01-23 12:19:38.880 infoO-Secadora (Tp-link HS110) 4.6.04 Status: [switch:on, power:0, energy:0]

dev:14742020-01-23 12:19:38.731 debugO-Secadora (Tp-link HS110) 4.6.04 setEngrToday: [emeter:[get_monthstat:[month_list:[[month:1, year:2020, energy:1.342000]], err_code:0]]]

dev:14742020-01-23 12:19:38.452 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"emeter":{"get_monthstat":{"year": 2020}}} // device IP = 192.168.1.107, action = setEngrToday

dev:14742020-01-23 12:19:38.448 debugO-Secadora (Tp-link HS110) 4.6.04 powerResponse: cmdResponse = [emeter:[get_realtime:[current:0.017661, total:1.341000, err_code:0, power:0, voltage:122.093487]]]

dev:14742020-01-23 12:19:38.342 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"emeter":{"get_realtime":{}}} // device IP = 192.168.1.107, action = powerResponse

dev:14742020-01-23 12:19:38.339 debugO-Secadora (Tp-link HS110) 4.6.04 commandResponse: status = [dev_name:Wi-Fi Smart Plug With Energy Monitoring, hw_ver:1.0, rssi:-92, latitude:20.790755, err_code:0, type:IOT.SMARTPLUGSWITCH, deviceId:8006D78F999B1439FF84E10AE599B2861BCA2366, mac:98:DA:C4:EE:75:58, icon_hash:, active_mode:schedule, updating:0, led_off:0, on_time:70704, feature:TIM:ENE, relay_state:1, oemId:FFF22CFF774A0B89F7624BFC6F50D5DE, alias:o-TPlink secadora, model:HS110(US), hwId:60FF6B258734EA6880E186F8C96DDC61, fwId:00000000000000000000000000000000, sw_ver:1.2.5 Build 171206 Rel.085954, longitude:-103.435808]

dev:14742020-01-23 12:19:38.016 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:19:38.008 debugO-Secadora (Tp-link HS110) 4.6.04 repeatCommand: [action:commandResponse, command:{"system" :{"get_sysinfo" :{}}}]

dev:14742020-01-23 12:18:57.939 warnO-Secadora (Tp-link HS110) 4.6.04 setCommsError: Parent commanded to poll for devices to correct error.

dev:14742020-01-23 12:18:57.927 debugO-Secadora (Tp-link HS110) 4.6.04 setCommsError

dev:14742020-01-23 12:18:56.900 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:54.885 warnO-Secadora (Tp-link HS110) 4.6.04 Executing attempt 4 to recover communications

dev:14742020-01-23 12:18:54.853 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:18:54.849 debugO-Secadora (Tp-link HS110) 4.6.04 repeatCommand: [action:commandResponse, command:{"system" :{"get_sysinfo" :{}}}]

dev:14742020-01-23 12:18:54.844 debugO-Secadora (Tp-link HS110) 4.6.04 setCommsError

dev:14742020-01-23 12:18:53.856 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:51.828 warnO-Secadora (Tp-link HS110) 4.6.04 Executing attempt 3 to recover communications

dev:14742020-01-23 12:18:51.797 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:18:51.792 debugO-Secadora (Tp-link HS110) 4.6.04 repeatCommand: [action:commandResponse, command:{"system" :{"get_sysinfo" :{}}}]

dev:14742020-01-23 12:18:51.788 debugO-Secadora (Tp-link HS110) 4.6.04 setCommsError

dev:14742020-01-23 12:18:50.801 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:48.785 warnO-Secadora (Tp-link HS110) 4.6.04 Executing attempt 2 to recover communications

dev:14742020-01-23 12:18:48.735 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:18:48.729 debugO-Secadora (Tp-link HS110) 4.6.04 repeatCommand: [action:commandResponse, command:{"system" :{"get_sysinfo" :{}}}]

dev:14742020-01-23 12:18:48.725 debugO-Secadora (Tp-link HS110) 4.6.04 setCommsError

dev:14742020-01-23 12:18:47.733 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:45.725 warnO-Secadora (Tp-link HS110) 4.6.04 Executing attempt 1 to recover communications

dev:14742020-01-23 12:18:45.691 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:18:45.687 debugO-Secadora (Tp-link HS110) 4.6.04 repeatCommand: [action:commandResponse, command:{"system" :{"get_sysinfo" :{}}}]

dev:14742020-01-23 12:18:45.683 debugO-Secadora (Tp-link HS110) 4.6.04 setCommsError

dev:14742020-01-23 12:18:44.687 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:43.592 warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:14742020-01-23 12:18:42.641 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"system" :{"get_sysinfo" :{}}} // device IP = 192.168.1.107, action = commandResponse

dev:14742020-01-23 12:18:42.638 debugO-Secadora (Tp-link HS110) 4.6.04 refresh

dev:14742020-01-23 12:18:42.635 infoO-Secadora (Tp-link HS110) 4.6.04 Scheduled nightly energy statistics update.

dev:14742020-01-23 12:18:42.632 infoO-Secadora (Tp-link HS110) 4.6.04 ShortPoll set for 0

dev:14742020-01-23 12:18:42.629 infoO-Secadora (Tp-link HS110) 4.6.04 Refresh set for every 15 minute(s).

dev:14742020-01-23 12:18:42.626 infoO-Secadora (Tp-link HS110) 4.6.04 Description text logging is true.

dev:14742020-01-23 12:18:42.622 infoO-Secadora (Tp-link HS110) 4.6.04 Debug logging is: true.

dev:14742020-01-23 12:18:41.563 debugO-Secadora (Tp-link HS110) 4.6.04 sendCmd: command = {"emeter":{"get_monthstat":{"year": 2020}}} // device IP = 192.168.1.107, action = setThisMonth

dev:14742020-01-23 12:18:41.560 debugO-Secadora (Tp-link HS110) 4.6.04 updateStats

dev:14742020-01-23 12:18:41.477 infoUpdating ..

dev:14742020-01-23 12:18:19.363 warnO-Secadora (Tp-link HS110) 4.6.04 setCommsError : Your device is not reachable at IP 192.168.1.107. Corrective Action : Your action is required to re-enable the device. a. If the device was removed, disable the device in Hubitat. b. Check the device in the Kasa App and assure it works. c. If a manual installation, update your IP and Refresh Rate in the device preferences. d. For TP-Link Integration installation: 1. Assure the device is working in the Kasa App. 2. Run the TP-Link Integration app (this will update the IP address). 3. Execute any command except Refresh. This should reconnect the device.

would really appreciate your help

thanks