Looked again just now and the usage stats appear to be in sync - same in Kasa and ST. Maybe there was a blip moving over.
1 Like
Iâve been hitting the server every 5 minutes for weeks and they havenât
blocked me yetâŠ
2 Likes
Good news.
Final code will have a preference for 5, 10, 15, or 30 minute refresh. No action required by user on install (or updating code). Default will be 30 minute refresh.
It is in my baseline for testing.
Dave
Thank You! Excellent instructions and easy add of my one orphan HS100 switch, youâre the man! Iâm somewhat technically adept but far from a coderâŠworks flawlessly so far (cloud version)âŠThanks again for all your hard work!!
1 Like
Thank you for developing this integration. Impressive work!
Just installed the cloud based version and it is flawless so far.
1 Like
Cloud Based Version is now out of Beta Test and the version is at the GitHub Site!
New features:
a. Device preference to set refresh rate at 5, 10, 15, or 30 minutes. 30 minutes is default.
b. Improved (more comprehensive) handling of loss of token errors.
c. Weekly automatic token update (still subject to change).
Instructions are on GitHub Site.
1 Like
The Cloud-based TP-Link to SmartThing Integration (top of this thread) integrates the TP-Link devices directly. The integration is directly to the TP-LInk Cloud and does not require any external devices (besides SmartThings).
Hi, I didnât realise this was up and running. Thanks for pointing that out. I have just installed and all is good. A big thanks to all who made this possible.
1 Like
I enjoyed the challenge and appreciate all the people who have had faith to try my first project.
3 Likes
@Gutheinz Thanks for this great work. It works beautifully with my LB130.
One suggestion: The tpLinkModel list under addDevices() is missing all the âEnergy Monitorâ device handlers. Therefore it gave me an error when I was trying the â(Cloud)TPLinkLB130EM.groovyâ. I was able to fix this error by adding the âTP-LinkLB130 Emeterâ in that list.
I understand on the EM version. However, not everyone wanted the EM version, therefore, I made that a second install step. The written instructions say to install the non-EM version, then overwrite the DH with the EM version. It was a compromise I made in the design of the Service Manager. I will consider a note in the Service Manager on-screen information relative to this confusing item.
Thanks for the kind words.
Interface update
With the recent Android App update, The display interface for sliders is changed. Once stabilized, I plan on changing. Before and after are below. This would be done to both sets of Device Handlers.
COMMENTS are encouraged.
BEFORE:
AFTER:
Hi all, firstly, thank you to the developer @Gutheinz for creating this control and enabling me to finally integrate my TPLink plugs into my ecosystem.
I was just wondering if the âaway modeâ on and off functionality that exists in the Kasa app can be added into Smartthings? Or does the released API not allow this?
Many thanks again.
1 Like
Once youâve got the devices in SmartThings, you can make use of SmartThings automations to do what youâre after.
Go to Automation -> SmartApps and click + Add a SmartApp
Under Lights & Switches youâll find Vacation Lighting Director
That should do what you need.
NB You can then use Modes (Away, Home, etc) to preconfigure these so everything works in beautiful harmony
2 Likes
Thanks @Gutheinz for this awesome integration! Would it be possible to change the logic in the handler to only update the state of the device if it is different from the actual state of the device as gathered from TP-Link? Doing so would prevent a lot of extra activity on the switch:
Iâve searched this thread and did not see this question/topic, apologies if this has already been discussed/answered.
Thanks!
2 Likes
Good idea. I have thought about it; however, not implemented.
A lot of extra processor ticks on the SmartThings environment to do the if/then statement. And no extra comms with the switch itself. I will consider this; however, some have asked me to increase the number of state updates to talk to other apps. (sigh).
Hi Dave, I also thank you for this integration. If I may, here is something that Iâm testing to reduce the number of events.
1 - Removed the sendEvent for the âwaitingâ status on all places.
2 - Removed the " isStateChange: true" from all sendEvents
Note - If you use any SmartApp (like webCoRE) to trigger something when the switch IS ON then if will trigger everytime it receives an ON event. This was happening every time a refresh was called because the state was changing to âwaitingâ and then to âonâ.
3 - You can achieve the same UI status update with the following:
tileAttribute ("device.switch", key: "PRIMARY_CONTROL") {
attributeState "on", label:'${name}', action:"switch.off", icon:"st.switches.switch.on", backgroundColor:"#00a0dc", nextState:"waiting"
attributeState "off", label:'${name}', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#ffffff", nextState:"waiting"
attributeState "waiting", label:'${name}', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#15EE10"
attributeState "commsError", label:'Comms Error', action:"switch.on", icon:"st.switches.switch.off", backgroundColor:"#e86d13"
}
Thanks again and hope that this helps 
1 Like
Rudi,
Thanks for the hints and information. I will definitely look into the changes you suggest. I an thinking of getting rid of the waiting state completely. That state is a legacy from early development using a PC bridge. The cloud-based and my newer bridge based do not have the problems reporting back state and it is no longer important.
Will definitely remove the isStateChange: true. That is just my inexperience (This is my first sw project since 1968 in university. Yes, I am old, but decrepit.
Update should be in a couple of weeks. I have been doing a Device handler for my Samsung WiFi Soundbar that SmartThings does not support. It is in early beta and I am adding functions based on some comments.
Again, thanks.
Dave.