New TP-Link Smart Home binding with Bulb, Plug and Switch Support

I read the Binding Information on the OH2 bindings page but it does not mention the LB230 bulb. @w2vy seemed to suggest that the LB230 is supported but you asked him to read the readme and did not confirm or deny support for the LB230.
I see that @YOUTHOFSUBURBIA reported what looks like limited support for the LB230 so I am even more confused. :confused:

I have ordered some LB230 bulbs that have not yet been delivered so I am very interested in:

  1. Is the LB230 fully supported by your binding?
  2. If not do you have plans to fully support it?


Doh! It looks like tp-link quietly added 4 new bulbs and 1 socket to their
product line. I wasn’t aware of this (as I don’t checkup on their website
that regularly and these devices don’t even show up in my home country
website of tp-link :frowning: and incorrectly assumed it was a typo and he meant
LB130. So thanks for bringing this up.

To clarify things: The new bulbs LB200, LB230, KB130, KB100, and plug KP100
are not recognized by the binding. This means that autodiscovery will not
find these devices. However they might be supported if they use the same
protocol as other devices.

The following new devices are not autodiscovered but could be added
manually using supported devices.
LB230 -> LB130
LB200 -> LB100
KB130 -> LB130
KB100 -> LB100 (But dimmer isn’t supported on the KB100, so only switch
might work)
KP100 -> HS100

I have not tested if the above combinations works. So if people have these
new devices let me know if manually adding works (I’ll also will reread the

I’ll add these devices soon, initial assuming they work as the other
devices, and if new information emerges I’ll update it. The update will
first become available via the Eclipse Marketplace until available openHAB.
I’ll post here when this will be available.

Thanks for the clarification. The LB230 bulbs will be my first TP-Link devices but I will test them out as you suggest above and report back when they arrive and I get them setup.

I’ve updated the binding in the Eclipse marketplace with support for the new bulbs LB200, LB230, KB100, and KB130 and plug KP100. It’s derived from the already supported devices so it might not work. If you have any of the new devices you can try the his beta version of the binding, and please report if you have any problems.

Hi all,

What model did you test? - TP-Link HS-200 (US) (switch)

Does switching on/off work? - Yes

Does auto-discovery work? - No

Need to be added manually, using her IP address. You can find it on the router devices connected.


1 Like

My LB230 bulbs were finally delivered. After setting them up via the Kasa app I downloaded the (Beta) version of your binding via the marketplace, see image below:

With this binding installed I attempted an auto-discover via Paper UI but no bulbs were found.
I attempted to setup the things file manually guessing at the lb230 device type as below:
tplinksmarthome:lb230:myBulb "myBulb" [ ipAddress="192.168.x.x", refresh=60, transitionPeriod=1000 ]

But no matching things appeared in Paper UI.

I then updated my .things file to use lb130 instead and the thing appeared in Paper UI, I was able to add items and control the bulb.

Here is my items file, all functions tested and working:

Dimmer	myBulb__Dimmer							"Lights"                            		{ channel="tplinksmarthome:lb130:myBulb:color" }
Dimmer	myBulb__ColourTemperature				"Lights Colour Temperature [%d] K"			{ channel="tplinksmarthome:lb130:myBulb:colorTemperature" }
Color	myBulb__Colour							"Lights Colour"								{ channel="tplinksmarthome:lb130:myBulb:color" }
Number	myBulb__SignalStrength					"Lights Signal Strength"               		{ channel="tplinksmarthome:lb130:myBulb:rssi" }

So, as far as I can see the LB230 works exactly as the LB130 as far as the binding is concerned except auto discovery does not work for the LB230. This is not an issue for me as I like to use .things files anyway but it would be nice to use the ‘LB230’ correct device name in the things file vs the ‘LB130’ however this is only a very minor inconvenience.

@hilbrand A side question: I see in the Kasa app that there are energy usage statistics available for these bulbs. (Not sure if this is a difference from the LB130 or not).
Is it possible to access this data via the API and hence surface it as additional channels in OH?

The main items are:

  • Energy Usage Today (kWh)
  • Time (hrs)

Both of which are numbers with two decimal places of accuracy.
Since these are shown as totals per day I assume the bulb is measuring instantaneous usage and then calculating but I have no idea if this data feed is available.

Anyway, thank you for your efforts on this binding and your continued support!!

@hilbrand Sorry… the more I play with this the more questions I have… :smile:

The colorTemperature channel is working fine to adjust the colour temperature of the bulb but I personally find it confusing to work with.
Since the bulb can render colour temperatures 2500K to 9000K the dimmer (0-100%) is a bit confusing and imprecise without some additional mathematics to convert between the two values.

Would it be possible to add an additional, (to avoid a breaking change), channel called colorTemperature_Raw that would expose a NumberType and accepts values from 2500 to 9000 inclusive?

@yeisnier Sometimes it doesn’t directly discover, I don’t know why, but retrying discovery sometimes helps.

@mcqwerty: Are you able to add the lb230 manually in Paper UI using the LB230 device? Also if you run with debug log it should log any detected, but not supported devices during auto discovery. This might indicate incorrect detecting of the bulb. In that case can you post the message here? or run with log trace that gives you even more detailed information.


Energy Usage: I didn’t add this for bulbs as I don’t know what it actually returns and I don’t have these bulbs to test. However, I’ve build the binding in such a way that that it should return this information (but as it’s not tested it might not give the information). If you would run with trace log you should be able to see this in the logging. If you can post this json here I can use it to add this feature.

Time: For switches this is returned (but not used), but for bulbs I don’t have seen it in the default return response. It’s possible to get the information over several days, but this is more complex as it requires to send the date to the device (so that should be in sync) and can be a much larger data set (so limits need to be increased) Since measuring (up)time is also something that can be done using openHAB persistent service, I’m not sure if the added complexity is worth it to build into the binding.

Regading color temperature. There was actually such a channel, but I’ve removed it upon request during code reviews, to make the binding more in line with other light bindings :frowning: The assumption was that most people don’t use very specific kelvin values and thus it’s not necessary to have this kind of detail channel. But if you think this does add value, you could start a new topic about the need for kelvin values in color temperature light bindings.

Here’s how I added the HS200’s to the Items, Things and Sitemap in case that´s useful for someone.


//TP-Link HS200 Switches
Thing tplinksmarthome:hs200:X0X00X "Hallway Light" @ "Lights" [ipAddress="192.168.X.XX", refresh=60]

Thing tplinksmarthome:hs200:X0X00X "Kitchen Light" @ "Lights" [ipAddress="192.168.X.XX", refresh=60]


//TP-Link HS-200 Switch
Switch TPL1_Switch "Hallway Light" (LivingRoom, Lights) ["Switchable"] { channel="tplinksmarthome:hs200:X0X00X:switch" }
Number TPL1_RSSI "Signal [%d dBm]" (gChart2) { channel="tplinksmarthome:hs200:X0X00X:rssi" }

Switch TPL2_Switch "Kitchen Light" (LivingRoom, Lights) ["Switchable"] { channel="tplinksmarthome:hs200:X0X00X:switch" }
Number TPL2_RSSI "Signal [%d dBm]" (gChart2) { channel="tplinksmarthome:hs200:X0X00X:rssi" }


Frame label="Livingroom"
       	Switch item=TPL1_Switch label="Hallway Light" icon="Light"
        Text item=TPL1_RSSI label="Signal [%d dBm]" icon="network"
	Switch item=TPL2_Switch label="Kitchen Light" icon="Light"
        Text item=TPL2_RSSI label="Signal [%d dBm]" icon="network"

I used @fritzcm code and replace it with my stuff… :smiley: I hope it helps someone!

I went to Inbox -> Clicked ‘+’ -> TP-Link Smart Home Devices Binding -> Add Manually
But the LB230 bulb is not listed:


As mentioned previously I installed the (Beta) version of the TP-Link binding from the marketplace.
I checked the Karaf console and it reports that I have v2.3.0.201712262051 installed.

I guess this explains why my LB230 bulbs were not detected but why do they not show in the device list?

I’m guessing the information you are looking for from the trace is the format of the query response containing the energy details. This portion of my log is below:

28-Dec-2017 13:43:45.298 [TRACE] [penhab.binding.tplinksmarthome.internal.Connection] - Executing command: {"system":{"get_sysinfo":{}}, "smartlife.iot.common.emeter":{"get_realtime":{}}}
28-Dec-2017 13:43:45.339 [TRACE] [penhab.binding.tplinksmarthome.internal.Connection] - Command response: {"system":{"get_sysinfo":{"sw_ver":"1.6.0 Build 170703 Rel.141938","hw_ver":"1.0","model":"LB230(E26)","description":"Smart Wi-Fi LED Bulb with Color Changing","alias":"BathroomMaster_South","mic_type":"IOT.SMARTBULB","dev_state":"normal","mic_mac":"50C7BFEB704E","deviceId":"8012B08FE32574A938AA4DD652AB2E7718CA7D40","oemId":"39DF2F5A8EADED2A390EE4A14D12107B","hwId":"111E35908497A05512E259BB76801E10","is_factory":false,"disco_ver":"1.0","ctrl_protocols":{"name":"Linkie","version":"1.0"},"light_state":{"on_off":1,"mode":"normal","hue":0,"saturation":0,"color_temp":3800,"brightness":100},"is_dimmable":1,"is_color":1,"is_variable_color_temp":1,"preferred_state":[{"index":0,"hue":0,"saturation":0,"color_temp":2700,"brightness":50},{"index":1,"hue":0,"saturation":75,"color_temp":0,"brightness":100},{"index":2,"hue":120,"saturation":75,"color_temp":0,"brightness":100},{"index":3,"hue":240,"saturation":75,"color_temp":0,"brightness":100}],"rssi":-55,"active_mode":"none","heapsize":298924,"err_code":0}},"smartlife.iot.common.emeter":{"get_realtime":{"power_mw":11000,"err_code":0}}}

It reports this information approx every minute as I have my refresh rate set to 60 in my things file.
Does this give you enough information?

I agree. Since it appears the power_mw property is only non-zero when the bulb is illuminated and appears to be an instantaneous value then all the other metrics can be computed by the user outside of the binding.

:disappointed: I certainly do think it adds value and it’s a shame you were asked to remove it. One real strength of OpenHAB in my opinion is that very little is hidden from the user and one can get as detailed as one prefers. I don’t see the harm of having an additional channel that both reports and enables setting of the direct Kelvin value. If anything, this is a feature that is missing from other bindings (Lifx for example), rather than something that should be removed from yours.

I will see about creating another thread but it seems like the minds of the powers that be are made up. Would adding the additional channel cause issues in a future code review? Maybe there could be a marketplace binding including this channel for advanced users?


An other topic:

TP-Link announced their new cloudbased IP Camera "Kasa Cam KC120". Currently available in the US. It’s supported by KASA APP.

See here:

Will it be supported by the OpenHAB binding? Maybe in near future?


It looks like you got a incorrect version of the binding. For the eclipse market place I use the binding build by the openHAB pull request builder. When this binding was not yet part of openHAB this is worked fine as my pr was the only one that created this binding. But now that the binding is part of openHAB it can also be overridden by to other pr’s that only contain what is part of openHAB, (which is not any new code I added that is not part of openHAB). I should probably change this in the future and use another location to store the jar.

The good news is that the pr with new devices support has been merged already, you can use or an openHAB snapshot version of the jar or reinstall the eclipse market place jar.

I think I have enough info on the power_mw property. This looks like it shows power in milliwatt (value is 11000, which looks like 11 watt), I’ll probably will let it show in watt with 1 decimal: (11.0 W).

Regarding color temperature. I think there is still room for discussion. So it might be worth it. For example I was thinking if you have a lb120 and lb130 and want to show the same color temperature, this is almost impossible with percentages since they have both a different color temperature range. Setting the kelvin value in such a case would certainly make sense. I’ll still have the code available, so it would not be to much work to re-add it, in case it is requested. I don’t think a different binding in the marketplace would be a good idea, as it’s more effort to maintain and might create confusion.

To add support to the KASA Cam KC120 I would need to know how to communicate with the device. And at this moment I have no information about this. As I don’t have the device and can’t research this. So if someone is going to provide the necessary information (which will probably require some reverse engineering/network monitoring) I can add support for it.

Ok. Thanks for your reply. At the moment the cam is available only in the US. Maybe someone has it bought yet and has the knowhow to do a network monitoring?

Did this and tried again, auto-detection of my LB230 bulbs worked as did adding manually in the things file using the lb230 device type. Thanks! :smiley:

My thoughts exactly. Your plan sounds great to me, looking forward to the new functionality. Thanks!!!

Right, and I am planning on using various local factors to calculate the ideal colour temperature so I would like to set the K value directly and also have it be generic rather than tied to a particular percentage for a particular bulb implementation. (Lifx has a similar issue but I am guessing it will be even harder to get this functionality added to that binding). I will find some time to create a new post and add a link here.

Once again thanks for your work on this binding and continued support @hilbrand

New binding in eclipse marketplace available with channel to read power value of bulb devices. (It still points to the pull request build location, so it might be inadvertently be overridden if another build process is taking place)

@hilbrand Thanks! Installed and it is working great. Doesn’t look like the code was overwritten by another PR as the lb230 device type is still valid.
I added an item linked to the new thing channel and I am seeing power being reported.

One comment: I see that you named the channel powerMw but the value being reported looks to be Watts (W). So the implementation is as you proposed in an earlier post but the naming of the channel doesn’t seem to be consistent with this. Am I missing something?

Your right about the naming. I also was thinking about this and changed this. I changed the name to power. It’s currently being build so the update will be available once the build on the pr is finished.

Tested and working great. Thanks.

Hi hilbrand,

I received the LB120 Lightbulb as a gift over the holidays and new to OpenHAB in general, but a few things im noticing with the LB120 as I try to control it via the TP Link binding.

The switching on/off status in OpenHAB doesn’t sync all the way. I can turn the bulb on and off via OpenHAB just fine. If I turn the bulb off via the Kasa app though, the TP Link binding will not pick up on this change. If the bulb is off and I turn it on via the Kasa App, the TP Link binding does pick up on the change.

I can adjust Light Color via the TP Link binding, however, the value of the color never stays in sync. It always revert back to a reading of NaN and 0 on a slider. If I make changes to the Light Color via the Kasa App, the TP Link binding will not pick up on this change in any way either.

Brightness/Dimmer is fine though. Any change I make is reflected in both OpenHAB and Kasa.

Hopefully what I described makes sense and wondering if you had any ideas?