[RELEASE] TP-Link Plug, Switch, and Bulb integration


I see, thanks for the explanation. By the way, the UDP driver is working with my HE with HS100, thanks!


So I actually did look at this. As @djgutheinz mentioned to port the api elements into the driver is not trivial. Well beyond anything i would be able to do.

Though I do think it is possible.


Hi, thank you for answering

You @djgutheinz and @cwwilson08 should team up!

Happy New Year!


I would not mind. However I think @djgutheinz has better things to do than spoon feed me information. The project was out of my league to begin with. It is a small miracle I got it working for me. I was really hoping I wold spur the interest of people with more skills than myself.


Dave - this is working brilliantly! Love it!

So two questions:

  1. Do we need the TP-Link HE app anymore?
  2. What is recommended refresh time from your initial experience?

  1. App is not necessary if you have set up "static" IPs for the devices through your router.
  2. The default 10 minute is great for normal operations. Faster would be desirable if you have (a) a rule machine that reacts to changes and (b) a lot of activity that does not go through Environment. These activities include google and amazon linked to the Kasa app instead of Hubitat integration, direct use of the Kasa App to change state.

The old smart app has code that will delete the child devices if you delete the smart app (do not delete). A new smart app will come out today or tomorrow (in final testing) with update instructions. It can be deleted after update w/o deleting child devices.


Version 4.0 (UDP Version) Update Announcement

The full Version 4.0 UDP version with drivers and application have been completed. Installation files and Install/Update instructions can be found at:



Dave - I am absolutely AMAZED! So not only did you improve local execution using UDP but you also made to installation/upgrade SO easy. I didn't have to input IP addresses or anything. This is truly a work of art. Kudos to you for this incredible integration!


It was actually fun. I really enjoy trying new things (UDP) and actually getting them to work.


Hi @djgutheinz

I have been wanting to integrate my TP-Link plugs for a long time now but never got the time to setup the pi with node.js for it, this is awesome!!

That said, I'm unable to discover my devices (5x HS105). Looking at the code I realized that the discovery checks for every IP on the same subnet as the Hub and I have the plugs in a separate subnet for non-trusted IoT devices, so I hardcoded the networkPrefix to my IoT subnet but still, nothing gets discovered...

Do you know if these devices have some kind of restriction where they only accept UDP connections or commands from the same subnet or something like that?


The bulbs have no restrictions.
a. Try a manual installation for one device and see if it works.

b. Separate segment for untrusted devices. Not even sure if Hubitat supports separate subnets for devices??? I do know (in my router) you have to set up the router to allow cross access.

c. For the HS-105, if you move them to your trusted segment and then place them in Local only mode through the Kasa App, then they will no longer be accessible to the Kasa App. (Note, if you use Amazon, you can use the Hubitat integration to control.)

d Debug code. In the App and Driver are the following two lines:

def debugLog() { return false }

// def debugLog() { return true }

Reverse these to get full debugging.


Ahh! I found the problem, when the device is not in the local subnet, resp.mac will be null, and this is your first check in the response when discovering the device and then you use it for the device DNI.

I think maybe checking for IP is null instead and then getting the MAC from cmdResp.mac for the DNI would solve this, plus it is in human readable format instead of hex (easier to match a device from the devices page)... do you know if you can use ":" in a DNI? maybe replace them with "-"...

I'll give this a try and send you my changes if I can make it all work...

BTW, thanks for those tips!


I updated the code as follows:

a. Stop polling at device 254, avoiding a duplicate response from the global address.

b. Do not use the udp returned mac for a filter if null.

c. Parse the get_sysinfo return mac or mic_mac field (different based on device type) to generate the dni in format of MAC less colons.

I did no change the polling range. Could not figure out a way to do that w/o user interface. Would require a significant design change. You will have to hard-code that area.



This is Awesome Dave! got home from work ready try my coding skills but you were faster! :grinning:

Discovery worked with the new code and I was able to add the devices and they work perfectly!

I don't have any problem with hardcoding my subnet. Thanks so much for this integration!



Errors in logs:


Tried each of my bulbs, no problem (bulbs are where line 274 is in refreshResponse). Exactly what bulb was it? Is it repeatable?

FYI - the code is JSON parsing the return from decrypt. It indicates a truncated string was received (therefore only 12 characters long). Looks like a spurious comms glitch - but....

Turn on 'traceLog' (line 30-31 of the driver) and capture one cycle. If it continues, I will have to create a test driver with even more data.



These are the 230 color bulbs. Will turn on trace logging and get back to you. And this happens on both 230 and 130 bulbs.


After line 270, insert the below code. It will tell me what the "raw" data return is.

log.error parseLanMessage(response)

Also, what version are you using? (line 33 of driver)

I have run 100 cycles w/o an error. Still confused.


Version: 4.0.01

Added the log.error info...information below

[dev:271]( 08:53:29.191 pm [info]( Room - Couch: Power: on / Brightness: 100% / Circadian State: normal / Color Temp: 4000K / Color: [hue:0, saturation:0]

[dev:271]( 08:53:29.189 pm [info]( Room - Couch Color Mode is CT. Color is Moonlight.


[dev:271]( 08:52:29.081 pm [info]( Room - Couch: Power: on / Brightness: 100% / Circadian State: normal / Color Temp: 4000K / Color: [hue:0, saturation:0]

[dev:271]( 08:52:29.081 pm [info]( Room - Couch Color Mode is CT. Color is Moonlight.

[dev:271]( 08:51:29.069 pm [info]( Room - Couch: Power: on / Brightness: 100% / Circadian State: normal / Color Temp: 4000K / Color: [hue:0, saturation:0]

[dev:271]( 08:51:29.068 pm [info]( Room - Couch Color Mode is CT. Color is Moonlight.

[dev:271]( 08:51:20.634 pm [info]( Room - Couch: Power: on / Brightness: 100% / Circadian State: normal / Color Temp: 4000K / Color: [hue:0, saturation:0]

[dev:271]( 08:51:20.633 pm [info]( Room - Couch Color Mode is CT. Color is Moonlight.

[dev:271]( 08:51:20.516 pm [info]( Room - Couch: Power: on / Brightness: 100% / Circadian State: normal / Color Temp: 4000K / Color: [hue:0, saturation:0]

[dev:271]( 08:51:20.515 pm [info]( Room - Couch Color Mode is CT. Color is Moonlight.


No errors. I will look at later. Have potential work-arounds. Tell me if it happens again and try to get data when it happens.

What I believe is happening: The return from the bulb is being split by the bulb into two messages. I have seen this in the Node.js for energy monitor responses - but only on extremely long energy stat messages and when the bulb was very busy (i.e., just received an set color command).