TP-Link/Kasa Bulbs and Plugs Control (Old, Unofficial Integration)

I see it very occasionally, but not in the last week. Usually means that the bulb did not handle the request. Possibly when it is busy or handling two commands simultaneously. The command that failed is executed at each command sent to the bulb. In this case, the command originated from the ST as a poll of status.
It should not affect ST operations (aside from occasional burps). The run file automatically restarts the node on failure.

Next update to the system may include improved error handling or increased command execution timing.

1 Like

Steve,

A further reply. The error is likely caused by a delay in receiving the response from the bulb. If it recurs, tell me. I can try increasing the command timing.

The updates on the server are not necessary for you (at this time).

Dave

Hi Dave - thanks for the update. I’m not seeing any negative effects due to the “status” checks, just a lot of output in the console, I can totally live with that. You’ve been a great help, I’m glad to have all my smart devices running from ST now!

Works great Dave! I’ll let you know if I run into any issues.
-Mike

Dave you are awesome. Thank you so much, this is a great project!

No issues to report with the updated files. I updated the groovy script and js files from your latest.

Dave, thanks for your work in adding these bulbs. My wife just got me an LB-110, and I know nothing of coding for these, but I followed your install instructions in the PDF, when I run start server .bat file, in the command window, whenever I try doing anything, but in this case, trying to turn off the bulb, I get the following error:

Tue 02/14/2017 10:13 PM The LB-1nn controller has started (This script is designed to work with the LB1nn.groovy device handler)

Tue Feb 14 2017 22:13:13 GMT-0500 (Eastern Standard Time):
Sent command: “on_off” // value: 0 // // bulb: 192.168.0.31
C:\TP-Link-LB1nn-Bulb-master\LB1nn.js:88
console.log(" Model: " + model + " / Status: Power: " + on_off + " / Mode: " + mode + " / Level: " + level)
^

ReferenceError: model is not defined
at Timeout.displayResults [as _onTimeout] (C:\TP-Link-LB1nn-Bulb-master\LB1nn.js:88:28)
at ontimeout (timers.js:365:14)
at tryOnTimeout (timers.js:237:5)
at Timer.listOnTimeout (timers.js:207:5)
Tue 02/14/2017
10:13 PM
The LB-1nn controller has started
(This script is designed to work with the LB1nn.groovy device handler)

Steve,
if you are still getting failures on the refresh, I suggest that you upgrade your bulb SW. See:
http://www.tp-link.com/us/faq-949.html

I have also updated to V1.1 and have updated the LB1nn.js file to accommodate graceful error handling. I have still not encountered the problem, so hard to work on here. *

SOME CRITICAL NOTES on timing due to the bulb.

Sometimes, the bulb will barf out a failure when turning off very shortly after sending another command (about 10 seconds). This caused the server to crash out.

HOWEVER, the batch file will automatically restart the server.

here is the output from test.bat:

Wed 02/15/2017
09:33 PM

********** Turning bulb ON **********
{ on_off: 1,
mode: ‘normal’,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 100 }

********** Setting Brightness to 010 **********
{ on_off: 1,
mode: ‘normal’,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 10 }

********** Setting Brightness to 100 **********
{ on_off: 1,
mode: ‘normal’,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 100 }

********** Turning bulb Off **********
{ on_off: 0,
dft_on_state:
{ mode: ‘normal’,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 100 } }


********** Get all System Info **********
{ sw_ver: ‘1.1.2 Build 160927 Rel.111100’,
hw_ver: ‘1.0’,
model: ‘LB110(US)’,
description: ‘Smart Wi-Fi LED Bulb with Dimmable Light’,
alias: ‘TPLink Bulb’,
mic_type: ‘IOT.SMARTBULB’,
dev_state: ‘normal’,
mic_mac: ‘50C7BF2D34DC’,
deviceId: ‘801295F2971B037133C8B151AE214E75180C279E’,
oemId: ‘1C3EE8B563FB24A74D815CE80582E03E’,
hwId: ‘111E35908497A05512E259BB76801E10’,
is_factory: false,
disco_ver: ‘1.0’,
ctrl_protocols: { name: ‘Linkie’, version: ‘1.0’ },
light_state:
{ on_off: 0,
dft_on_state:
{ mode: ‘normal’,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 100 } },
is_dimmable: 1,
is_color: 0,
is_variable_color_temp: 0,
preferred_state:
[ { index: 0,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 100 },
{ index: 1,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 75 },
{ index: 2,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 25 },
{ index: 3,
hue: 0,
saturation: 0,
color_temp: 2700,
brightness: 1 } ],
rssi: -54,
active_mode: ‘schedule’,
heapsize: 348784,
err_code: 0 }

oh, and yes, while running, it was able to turn on and off the bulb twice, as expected.

likewise, when running the standard ‘start server’ .bat file, your updated LB1nn.js works in controlling brightness and on/off state. Thank you!

This works very well, thank you for putting what is obviously a fair amount of time into the coding and the write up. I have successfully connected three hs100 bulbs and plan to try a few hs200 switches very soon. This was my very first custom device for Smartthings and I had it up and running in under 20 minutes using the instructions on your github. I will report back once I get all the components working individually. Again, your fantastic work is appreciated very much.

Your welcome. I enjoyed the effort.
Enjoy your SmartThings and enjoy your TP-Link devices. I love both.

For current users of the my TP-Link Bulbs Device Handlers. If you use Amazon Echo (Alexa) to control the bulb’s brightness, it is not working. A recent change to the Echo-ST integration has started sending decimal brightness values. The bulb’s read this and set the bulb to “0” brightness (lowest dim level). It does NOT impact ST control.

I have updated the Device Handlers to fix this problem. Go to your original site to see if I have fixed the issue.

For those using earlier versions, the update is simple (IF you are having problems). Open your device handler and go to the setLevel command. The input from ST is “percentage”. Add the line as the first line in the command:

percentage = percentage as int

Future. In the near future, I should have a Service Manager (smart app) that installs and manages the bulbs and switches. It will still require the bridge PC, but will NOT require static IP addresses. Devices install automatically with no required user input (other than selecting the devices to install from the app). I already have this running and am shaking out the system.

Just completed the install as described, and trying to connect it to a new LB100 bulb. The bulb is working via the Kasa app, and I’ve assigned a DHCP reservation so I’ve got the static address.

Likewise the server side is up and running and receives commands from ST and attempts to send them on… but then nothing.

I get the console log “Sending to IP … Command: deviceCommand” but that’s it.

Added a couple debug console.log commands and they show the connect event is firing, but no other events (including timeout)

The firmware on the bulb is 1.2.3 and HW version 1.0

Ideas?

1 Like

Geof,
Sorry for the problem. I have isolated the issue. Node.js is at version 6.10.3. I developed under 6.9.4. Something changed (I just installed 6.10.3 and get your results). I will work on fixing.

Update. I did a fresh install of node.js version 6.10.3. Results:

a. First test - same as yours!!!
b. Added three console.log lines for debugging. after following lines:
socket.on(‘connect’, () => {
—>> added here
socket.write(encrypt(command))
—>> added here
socket.on(‘data’, (data) => {
—>> added here

Result : worked! as expected.

c. I went back to the original server file - worked!!!

d. Tried another image folder - did not work. Added comments. Worked. Went back to original version. Worked.

e. Rebooted PC - worked fine.

I am at a loss; however, try:

stopping and restarting the node application (probably already done)
adding comments after the above lines.
rebooting the PC and retry. Maybe the node.js install needs to work-out or maybe I need to create a npm install file for the application? I will continue investigating.

Dave

Yes, I am at node.js 6.10.3

What’s interesting is that if I power cycle the light, then restart the server, then I get one timeout error on the first command… THEN an error about “WriteAfterEnd” because the connect event is fired after the timeout event (and therefore socket.end()). If I change to socket.destroy(), that error doesn’t happen but that doesn’t explain why the connect event is firing after timeout.

After that initial timeout error, then all connections after (even if the server is restarted) fire the connect event but then nothing, not even a timeout or an error. Not until the light is actually turned off (*and on again).

So it seems like something is happening on the light side as well, maybe hanging on to a connection that it should be abandoning?

I will try installing node.js 6.9.4 and try going from there. Hopefully the above is helpful.

Geof

Extremely helpful. Did you try changing the timeout to 0 in set.timeout. I ask you since I can not duplicate the problem since this AM.

Also, there is a newer version of the TP-Link firmware (full application to load). Although I was on 1.2.3 until last week, it may be helpful to your bulb. Current version is 1.4.1.
:
http://static.tp-link.com/iotUpgradeTool_V1.0.zip

I am reaching out for other help to augment my very limited skill level.

RED FACED DGutheinz Fix.

First - ouch. Configuration Control is everything.

New install? I think the “TP-LinkServer.js” file is incorrect. Somewhere the old file got into the new directory. UPDATED ON THE SERVER. Should read Version 2.1 at the top of the file.

All is working :slight_smile:

First I downgraded to v2.0, and it worked fine. Then I upgraded back to DH 2.3 + script 2.1 and it also works fine, including w/ Alexa.

Appreciate the help on a Sunday. Thanks for the work overall to make this interface possible!
(BTW, it will also work on node.js 4.8.3 as well in case someone else has an older server OS that can’t run v6.x)

Did you have any problems? Hopefully not.