I was thinking the same thing - that this was a cloud based solution so no actual hub was required. I have a Honeywell Lyric T5 that I can access and manage through SmartThings and ActionPanels without having a hub at all.
Interesting issue. And if this was touched on earlier please tell me. I’ve been using the classic app with the tp plugs since i set everything up in January this year. I just turned a plug off the other night. Now I’m getting a comm error showing in the app. Did they just push out an update which breaks the old configuration as well? Do we have a working solution for the new app?
Errors from IDE below.
eb52ac53-857e-4649-bb96-9401ada5f207 8:51:22 PM: error HS105(US) Plug 1: Token expired
6c70ca11-ae38-4d76-b09f-499289cca87b 8:51:22 PM: error Error in sendDeviceCmd: [error_code:-20651, msg:Token expired]
TP-LInk Token. My system still works and I have not seen a loud shout of failures. So I am guessing yours is a point problem. Try the following
a. Go to the Kasa App and see if you can control your device, after ensuring the device is not in Local Only mode. If you can, then
b. Try controlling in SmartThings. If not, then
c. Open the Service Manager (the smart app). One of the options is update token. This is a if automatic fails. Reasons for this to fail would include changing the password in the Kasa App.
Classic vs New SmartThings. According to SmartThings’ provided data, Classic integrations will work in the New SmartThings - eventually. Just not yet.
By the way - I was able to take Dave’s code and, with a few minor changes, get the server to work without having an actual Smartthings hub in my home.
I have an HS105 plug that previously worked using an older beta version of the DTH and SmartApp. I’ve deleted those old versions and installed the latest versions of both - (Cloud) TP-Link Plug-Switch and TP-Link Cloud Connect. I can see the plug in the Kasa app and renamed it from (“Christmas Tree” to “Fan”) - I can control it and it has remote control enabled. If I log out of Kasa and back in, the plug is still named “Fan” and I can still control it.
When I install the new SmartApp, I enter my credentials and hit “Initial Install” it apparently logs me in, since it sees the plug, but it shows it with the old name (“Christmas Tree”) and installing the device shows a comms error.
Any idea what might be going on? Seems like the old device data is being cached somewhere.
Not previously encountered.
Did you completely uninstall the previous Device, Device Handler, and SmartApp prior to trying the re-install?
Try this, turn on logging, and reinstall - noting errors so I can know what is going on.
This is all that popped up while live logging during the smartapp install:
b987a203-5f54-4c45-9265-62e8de7439ca 10:38:33 AM: info Device Christmas Tree added to devices array
b987a203-5f54-4c45-9265-62e8de7439ca 10:38:33 AM: info TpLinkToken updated to 74bee7bd-A4hwHm9Yvk8IAYX8JgVRXl0
Is there another logging option I should be using?
Assuming you uninstalled everything TP-Link (devices, device handlers, smart app) and started from scrarch,…
The fact that the device is still named “christmas tree” indicates something with the Kasa App and cloud. Do not know what - but that identifier is coming from the Kasa cloud.
Are you seeing errors on the phone app pages?
you may have two Kasa accounts? Make sure the login and password are exact to the current.
Only one account. I had logged out of the Kasa app and back in to verify that the right device was showing up. No errors on the phone when I add the SmartApp, enter my credentials and choose initial install. I’ve attached some screenshort showing what I see in the Kasa and SmartThings apps
Something is not right (I know, you know that).
If you have deleted the TP-Link devices, the TP-Link Device Handlers, and then removed and delete the TP-Link Smart App, then we should not be seeing Christmas Tree on re-install. If you did this (and I believe you did), then the name is coming from the TP-Link cloud (and therefore the question on two accounts).
This appears external to the SmartThings platform (in the cloud) where somehow your login is hooking to an incorrect server OR is hooking to the incorrect data. When you do the initial setup, my smart app pulls the server id from a global site. Then it goes to the server (identified by the global site) with the token and gets the device list. This device list is where the Smart App gets the device name (“Christmas Tree”).
Controlling the devices goes to the server with specific commands. So, if you are somehow hooking to an incorrect server, then it would give the symptoms (wrong device name and communications errors.
Two items, with me scratching my grey hair.
1… Log out of and back onto smartthings. DO NOT SELECT A location. Go to the My SmartAps section and see if an app appears there. If it does, it may be interfering in some way.)
2. ReVerify that the HS-105 is in remote mode (just in case).
So this is weird. I logged back into the Kasa app and under settings for the “Fan” device saw that there was a firmware update available (this had never displayed before). I did the update and went into SmartThings to reinstall the SmartApp. Wouldn’t you know it, the device name had updated to “Fan” and it works perfectly once I installed it.
I’m not sure how/why a firmware update would fix this, but it definitely jiggled something on the TP-Link side that fixed my problem. Thanks for your help on this and for your work on the app!
Good. Glad it is working.
Hi - thanks for sharing this. I was looking for a cloud integration example and this is perfect. In my case I don’t need the multistep process outlined in the api documentation. The backend cloud I want to link to doesn’t return a code or do logins - it just takes a secret key and a client ID and then returns two tokens. So I was wondering if I can safely skip the callback stuff. Based on your example it appears that it can indeed be skipped. I just need to store the token and then create the child devices using the token - with a refresh when needed. Am I missing anything?
I do not think so.
I have several tp-link switches and a smart bulb set up and all have been working fine. I had to reinstall the bulb - I think it lost it’s wifi connection. since then it works manually with Kasa but gives the following errors:
65aac2f4-29c9-4ac8-a815-3706d5b38fea 7:00:57 AM: error LB100(US) Bedroom Light: Account is not binded to the device
b97cccb1-66f8-4fcb-ac61-5b9ba693abd1 7:00:57 AM: error Error in sendDeviceCmd: [error_code:-20580, msg:Account is not binded to the device]
What are the steps to correct this - the service manager and everything was working just fine, I think I just need to “reauthorize”?
If your other devices are working, then the problem is with the Kasa app.
In the Kasa App, assure that the device has Remote Control enabled.
If that fails, I would try removing the bulb from Kasa, doing a reset (5 power cycles) and then readding. - BUT again, not an expert!!!
That was simple - in the process of resetting up the bulb, Kasa reset the remote control enable. Flipping that switch did the trick. Feeling a little dumb. Error messages made it seem like something big - actually something little.
Hi, I’m installing following the PDF instructions, running into this error:
No signature of method: script_app_metadata_7a62a7b7_95fe_4f3e_a128_f62269e6d2f5.metadata() is applicable for argument types: (script_app_metadata_7a62a7b7_95fe_4f3e_a128_f62269e6d2f5$_run_closure1) values: [script_app_metadata_7a62a7b7_95fe_4f3e_a128_f62269e6d2f5$_run_closure1@38fc273] Possible solutions: getMetadata(), getState(), setState(java.lang.Object), metaClass(groovy.lang.Closure)
This is for the cloud integration to smartthings. Couldn’t create new app.
I have not seen this error before in any installation. It indicates a metadata error.
At what point in the installation did this occur?
What other messages were generated by the system for the Smart App (need all)?
Things to try:
a. Assure that the file copied fully and that it published successfully.
b. Assure the Device Handler(s) were also copied fully.
c. Assure that the Device Handlers and ServiceManager are stored in the proper device (must be associated with your device).