When I googled "tp link kp125" I get link to below item about 8 items down the page.
see
https://www.kasasmart.com/us/products/smart-plugs/product-kp125
It has the same specs as the KP-115 EM plug (which I have, used today, and works as an EM plug. Experience says the TP-Link Kasa line works with this integration. I would buy the 115 unless the 125 was cheaper. Exact same specs for amps, voltage, and size.
I had a gift card for BB and they did not have any outlet with EM except this new KP125. I have two of them. I could test them if possible.
Would be good. They should detect automatically with the Kasa Integration App. Driver is the Kasa EM Plug.
Dave
Looks like the new KP125 EM plug works with the Kasa EM Plug driver! I have only tested it with the device edit screen. Are there suggestions on any other tests?
John
Just on and off. If those work, then the api has not changed.
Dave
Yes, On and Off worked and during the on time the current power reading was >0.
John
@djgutheinz turns out that my issue has not changed. Devices work but their state attribute does not change unless I do a refresh.
Need data. Turn on debug logging. The open a log window. Do a on/off cycle on ONE of the devices and send me the data.
Also, look in the events page and see if there are events for the on / off.
Also, try rebooting the hub. That sometimes clears up issues. (Note, I could not replicate - so ouch.)
Dave
I migrated from a C5 to a C7 hub yesterday through the hub protect service, and ever since I keep getting this warning in the logs for all my Kasa devices.
It doesn't seem to be affecting anything. I only have a few of these plugs and they are used mainly for energy monitoring to tell when certain devices turn on or off. I am still getting notifications when the laundry finishes, which is the most important thing!
I went into the app to make sure to update the IP addresses, but this still shows up in my logs.
The LAN_TYPE_UDP_CLIENT_ERROR means the comms are timing out and not getting back to the code (sometimes). The current timeout is 5 seconds - but I may need to increase that in the next version. This all started with the Hub Version 2.2.8 and I have already increased the timeout from 3 seconds.
Question: Is the device controlled OK (without delay)? This would indicate the timeout needs to be increased.
Some troubleshooting steps all on the new Hub.
- Check operation using the Kasa Phone App
- Reboot the hub and try again.
- Load the driver for Hubitat Ping (https://raw.githubusercontent.com/thebearmay/hubitat/main/hubPing.groovy), install a virtual device, and enter the IPs one at a time and test. If these fail, then the issue is with your Hub - router chain.
- Simplify the Hub installation to minimal complexity - preferably direct connect to the router (or main mesh system).
- Retest.
- Let me know results.
- You could also convert to Cloud Control without reinstalling.
- In app, select Use Kasa Cloud
- In app, get a token by entering your username and password.
- On the device's edit page, bind the device if not already bound. Save Preferences.
- On the device's edit page, select "Use Kasa Cloud" and Save preferences.
- You should see in Current States the attribute "connection" is CLOUD.
Well, out of my 5 Kasa devices, only 1 of them is actually for controlling something. It's a lamp plugged into an HS100. I used Google Assistant to turn the lamp on and off several times and there was no delay. The other 4 devices are for energy monitoring only and not controlling a device.
The only devices that seem to be generating the warning I posted are the ones on my HS300. So 2 separate devices connected to the same power strip. The only automation I use this for is monitoring power usage so that when the TV turns on, the air purifier turns off, and so far that has worked 100% of the time too after the hub migration.
It was just a little weird to me that I wasn't seeing this on my C5 and now I see it on the C7. But, I also let the logs run for hours and currently only see 3 warnings between the two devices. I'm not really concerned with it, but thought I'd post about it since it was new to me.
I just added HS300 to my HE. Driver is installed. I used Hubitat Package Manager to add Kasa device. I can see the plug names. But I don't see anything in "Devices". There are no Device pages for the strip.or plugs. What am I doing wrong?
First off, I started seeing slow downs (causing timeouts) with Hubitat version 2.2.8. It got worse with 2.2.9; however, I can not find data to "prove" this. When I get time, I am going to write a test driver that will measure turn-around between send cmd and cmd response. Will test on the C-5 and C-7 and use that data for determining if I should create a problem report to Hubitat.
2 Likes
Hi Dave,
I just noticed something that I've never noticed and wanted to run it by you. I've been doing various work with TPLink devices and webcore today and I had the device page for an HS200 open.
In the lastlancmd state variable it says {"cnCloud":{"username***password"}cnCloud":{get_info":{}}}}
First, I thought I was off cloud connection but I'm sure there's more nuance than that.
Second, it was a bit jarring to just see my username and password out on the device page. I'm not sure if it's something I did to cause this as a "last lan command sent" but I wanted to bring it to your attention and it made me feel icky.
Perhaps this is just the cost of doing things the way we're doing? I don't know, but to see it like that on the device page was very surprising.
1 Like
This command get the bound state of your device (bound/unbound). It does not go to the cloud. That being said, state.lastCommand and state.lastLanCmd (old) copy the current command so that I can retry the LAN command if it fails. Next version (shortly) will eliminate setting that state for the CN Command by looking for the username as a key to NOT set the state.
The next version big change will be the APP.
- More control over the search process
- select LAN, CLOUD, or BOTH search
- define a host range on the segment for LAN discovery to reduce search time
- Tools: Add a Ping IP tool to determine if a device is reachable by Hubitat (for troubleshooting).
Dave
2 Likes
Just a quick note, in case someone runs into it as well.
I use a /23 network for my Hubitat hub and Kasa devices. As a result, not all device IP addresses have the same third octet.
This caused the devices that had a different third octet than the hub not to be detected by the Kasa Integration app.
You can still discover using the Kasa Cloud connection then control via the hubitat????
I didn't try, I just re-IP'd the few devices that had a different third octet.
Due to the number of comms issues in the last month and some requests from users for some tools, I offer an update to Version 6.4.2. Additionally, the documentation (linked from app) has been updated.
As usual, if your installation is not having issues and you are not interested in the application tools, consider delaying update for now.
Version 6.4.2 Updates.
App Updates:
- Refined UI to combine former areas under switches
- Cloud, Lan, and device control setup
- Added ability to select discovery methods between LAN, CLOUD, and BOTH
- Added ability to limit host address range on the segment(s)
- Application Utilities
- Added IP Comms Test Tool. Completes a ping then a system information command to verify that Hubitat and the LAN communications methods can connect to a device.
- Added Reset the Device Database. Zeros the database, then rediscovers devices and updates the device IPs on the installed devices (if changed).
- Cloud, Lan, and device control setup
- Adjusted method of finding devices
- DB not updated for a found device unless the data has changed.
- No longer update the database on "Remove Devices" and the "List Devices" tools.
Device Update: Increased timeout to possibly account for recent issues with devices.
4 Likes
