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

Add-ons Bindings
62

Finally I figured out how to setup a trace :blush:

18:52:55.086 [TRACE] [inksmarthome.handler.SmartHomeHandler] - Update Channels for:tplinksmarthome:re270:833c3ec8
18:52:55.086 [TRACE] [g.tplinksmarthome.internal.Connection] - Executing command: {"system":{"get_sysinfo":{}}}
18:52:55.185 [TRACE] [g.tplinksmarthome.internal.Connection] - Command response: {"system":{"get_sysinfo":{"plug":{"feature":"TIM","relay_status":"ON","on_time":2880,"next_action":{"type":-1}},"err_code":0,"rangeextender.wireless":{"w5g_client_count":0,"w2g_uplink_time":983,"w5g_uplink_enabled":false,"w5g_rssi":-256,"w5g_uplink_time":0,"w2g_mac":"50:C7:BF:C7:B2:1A","w2g_uplink_enabled":true,"w2g_downlink_enabled":true,"w5g_downlink_enabled":true,"w2g_client_count":0,"w5g_uplink_connected":false,"w2g_rssi":-70,"w5g_mac":"50:C7:BF:C7:B2:19","w2g_uplink_connected":true},"system":{"ethernet_mac":"50:C7:BF:C7:B2:1A","type":"IOT.RANGEEXTENDER.SMARTPLUG","oemId":"A4551BD7CF274B28C532A79E87B9FFB5","icon_hash":"","system_time":1518198773,"updating":false,"deviceId":"8017FBF7F3023E3F35879C07EDD6BFB418C58C13","sw_ver":"1.1.10 Build 20170920 rel.41527","hwId":"5AC4CF9E3183C16825EB28BC3C27059C","longitude":0,"led_status":"ON","model":"RE270K(EU)","hw_ver":"1.0.0","latitude":0,"alias":"My Wi-Fi Extender+","dev_name":"AC750 Wi-Fi Range Extender with Smart Plug"}}}}
´´´
63

That looks great :smile: Turns out the data structure is completely different then the other devices. So it will not work with the current binding. I’ll work on a fix. However, I’m not sure if I get switching the plug on/off to work because this requires to know what command to send. To find it out it would require some network traffic monitoring between the kasa app and the device. I also didn’t find anyone else who already has figured this out…

64

Thx hilbrand. Are we allowed to discuss - how this is done - in this forum?

Searched a bit about reversed lalala:
duckduck spit out this https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/

I am assuming this is the path I have to go to find *commands.
As always noob-questions: but you have to start somewhere :slight_smile:

65

They looked in the firmware. However it can also be done by monitoring network traffic between de KASA app and the device. With wireshark this is possible (you need to set up a wifi access point that can log network traffic, for example with a raspberry pi this is fairly simple. There is even a plugin in wireshark to show tp-link commands.

I found one other case on the internet about the re270k. What they tried is to create a mock device and see what commands the KASA app sends. However. It first sends the ‘normal’ status command and then asks to login. Because the person had no real device it stopped there with the configuration in the KASA app and thus the person was not able to monitor the actual commands to switch the device on/off. I’m assuming the login is required to configure the range extender that is login protected I would assume. However it might be the controlling of the device on/off works like the other smart devices and thus can be monitored. So once the device is added in the KASA app it might be possible to get the on/off commands.

66

Hello there. I recently received a TP-LINK LB130 light bulb. 3rd TP link device, I have two smart plugs and those both work great. The LB130 is working well with the exception of a power switch. Some of the earlier posts suggest this was corrected. Did something change? Running the regular version of the binding installed via PaperUI. Thanks!

67

There is an updated version of the binding that can also be installed via
paper UI if you have eclipse marketplace installed.

68

Perhaps after working the past week on migrating from OH1 to OH2 and only working in the ridiculously over-complicated exec binding I am overlooking something simple here, but I cannot get this to work for some reason. Not seeing any errors, looks as though it should be working, but it just isn’t.

I have the most updated version of the binding as I just installed it last night.

I have a TP-Link HS105 - all I care about is ON/OFF

extras.things
tplinksmarthome:hs105:noise "Bedroom Noise" [ ipaddress="192.168.10.119", refresh=60 ]

extras.items
// TP-Link

Switch  tp_link_bedroom "Bedroom Noise" { channel="tplinksmarthome:hs105:noise:switch" }

home.sitemap (only relevant part to TP_Link)
Switch item=tp_link_bedroom label="Bedroom Noise"

Logs look what I would expect, I guess. Again since working with exec is a totally different beast altogether and I have never used a “regular” binding, I may be missing something:

13:48:48.821 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'tp_link_bedroom' received command ON
13:48:48.838 [INFO ] [smarthome.event.ItemStateChangedEvent] - tp_link_bedroom changed from NULL to ON
13:49:38.195 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'tp_link_bedroom' received command OFF
13:49:38.208 [INFO ] [smarthome.event.ItemStateChangedEvent] - tp_link_bedroom changed from ON to OFF

I added all of this manually since that is what I prefer. While I didn’t actually add it from PaperUI, I did see that it was listed in AutoDiscovery (but with a different thing_id at the end, of course)

Thanks for the work on this by the way!

69

The property of the thing for ip address must be: ipAddress. With uppercase A.

btw I agree with you on the exec binding. People want to use it for something it’s not designed for. I started a topic to get feedback to start improving the exec binding, but got little (useful) feedback: Proposing Improvements to the exec binding

70

I knew it was something so simple! Changed it to capital A and of course it worked perfectly.

I’ll be honest and say, yes I agree the exec binding can be improved, though in fairness as great as OH2 is, it is still quite young I’d say and there is room for improvement nearly everywhere.

The learning curve, especially when coming from exec1 in OH1, is quite steep. However, now that I have a better understanding of it, I actually prefer it over the exec1 implementation and glad I stuck it out to get all of my system migrated over to it. I think that it is almost too flexible, which causes people to try to use it outside of what it is intended for. I’d gladly not use it if I had bindings available. For my Zigbee’s, I could get a Hue or OSRAM bridge and eliminate the need for one aspect of my system, but that would still leave my 433 RF outlets.

That being said (and yeah, getting totally off topic now :slight_smile: ) , I’d say spending the time to build some sort of 433/codesend binding would be more of a worthwhile endeavor. For that matter, I could probably work on a binding for my rooted WinkHub 1, but I think so few people use that it would primarily be for my own benefit most likely. But, a lot of people use 433 outlets and while there are different methods of implementation, I think it could be make into something more uniform, you know - cover the 80-90%. I say this all without ever having looked to see if this has already been started or not, but either way it would be good thing to have.

Though, as I say that, I like the 433’s because they are cheap and have worked well for me thus far, but sometimes I get some signal issues and I am not sure where the problem lies. I really like the simplicity of the TP-Link devices and may end up replacing my more troublesome 433’s with them. Thanks again for the work on this and pointing out the “A”!

Mike

71

Hi all,

is anyone facing problems with the HS110 SmartPlug too?
It seems like the Thing is online, but power measurements are not updated after some point of time.
I then have to restart the binding and everything works fine again.

This is reoccuring in my environment for several weeks now.
I didn’t want to post anything unless i made some debug logs, but unfortunately i don’t have enough toime to investigate this now from scratch.

So mayber there’s someone with similar problems and can provide some logs.
I will attach them as soon as i got some spare time for a deeper research.

(I am using the current OH stable and the oh binding version)

72

There was an firmware update for HS110 which changed the reading of the power values. If you are running openHAB 2.3.0 you should not have this problem. Otherwise you can install the tplink binding available in the Eclipse Market place (This can be done via PaperUI with Eclipse Market enabled)

73

Thanks for the quick info.
I will wait and check it after updating to 2.3.0 when i have found time for that.

74

Hallo,
how often power and energy usage readings can be refreshed for the HS110 plug?
Is the refresh rate configurable to , say, 5 seconds ?
Would that work and be reliable ?

thanks
massi

75

The refresh rate can be set to a minimal of 1 second. I think this should work reliable. In the tp-link binding switch devices use a 1 second refresh rate.

76

It’s all working ok here EXCEPT for some reason i can’t persist any of the items, they update ok in basicui but nothing ends up in my influxdb and i have been trying to figure it out for 5 hours now, tried restarting everything, rebooted, been skimming logs for hours, it’s as if my persistance entries don’t exist in the config. I also just switched from 2.4.0 to the marketplace version, no luck so far

influxdb.persist:
i tried single items:

TPLinkPlug1_Signal, TPLinkPlug1_Power, TPLinkPlug1_EnergyUsage, TPLinkPlug1_Current, TPLinkPlug1_Voltage : strategy = everyChange

and via group:

    gTPLinkPlugs* : strategy = everyMinute, restoreOnStartup

things:

tplinksmarthome:hs110:plug1 "TPLink Plug 1"        [ ipAddress="192.168.178.46", refresh=30 ]
tplinksmarthome:hs110:plug2 "TPLink Plug 2"        [ ipAddress="192.168.178.47", refresh=30 ]

items:

Group gTPLinkPlugs

Number TPLinkPlug1_Signal         "[%d]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug1:rssi" }
Number TPLinkPlug1_Power          "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug1:power" }
Number TPLinkPlug1_EnergyUsage    "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug1:energyUsage" }
Number TPLinkPlug1_Current        "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug1:current" }
Number TPLinkPlug1_Voltage        "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug1:voltage" }
Number TPLinkPlug2_Signal         "[%d]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug2:rssi" }
Number TPLinkPlug2_Power          "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug2:power" }
Number TPLinkPlug2_EnergyUsage    "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug2:energyUsage" }
Number TPLinkPlug2_Current        "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug2:current" }
Number TPLinkPlug2_Voltage        "[%.2f]"        (gTPLinkPlugs) { channel="tplinksmarthome:hs110:plug2:voltage" }

whoever figures this out, i’ll buy you a beer!

EDIT:

Nevermind i guess i’ll drink my beer alone. Grafana was the culprit, the tables are ok in the db but for some reason grafana didn’t list them… WTF. Thanks anyways!

77

Hi there,

I am using the HS110 running OH 2.3.

Discovery works fine and added via PaperUI.

When editing the power item, I am unable to add a Parent Group entry. The option is greyed out as are all items in this view.

HS110PowerGroup
HS110PowerGroup.png1389×969 18.9 KB

Has anyone else experienced this problem?

Regards
Mark

78

Hi there,

I’m just wondering why my HS110 doesn’t show values for energy monitoring.
All I get is signal strenght and I’m able to switch the socket and the led.

The logfile also shows 0.0 although the socked is switched on and powers a 7W LED bulb (Kasa app indicates 6,55 W current power usage).

out_tp1_switch changed from NULL to ON
out_tp1_power changed from NULL to 0.0
out_tp1_energyusage changed from NULL to 0.0
out_tp1_voltage changed from NULL to 0.0
out_tp1_current changed from NULL to 0.0
out_tp1_rssi changed from NULL to -44
out_tp1_led changed from NULL to ON
out_tp1_rssi changed from -44 to -40

I’m running oH2.2 on a Raspi3 - binding installed via PaperUI and auto discovery.

What model did you test? - TP-Link HS-110
Does switching on/off work? - Yes
Does auto-discovery work? - Yes
Does RSSI work? - Yes (shown in dBm)

TP-Link HS-110 with Energy Monitoring (Specific features):
Does Power usage work? - No
Does Energy usage work? - No
Does Current work? - No
Does Voltage work? - No

79
1 Like
80

I’m using this binding from PaperUI OpenHAB2.3 and just discovered this issue with a LB120 myself.

The state change for color temperature from any UI is transferred to the bulb correctly:

Item ‘tplinksmarthome_lb120_XXXXXX_colorTemperature’ received command 28
Executing command: {“smartlife.iot.smartbulb.lightingservice”:{“transition_light_state”:{“color_temp”:3764,“hue”:0,“saturation”:0,“on_off”:1,“ignore_default”:1,“mode”:“normal”,“transition_period”:0}}}
tplinksmarthome_lb120_XXXXXX_colorTemperature changed from UNDEF to 28
Command response: {“smartlife.iot.smartbulb.lightingservice”:{“transition_light_state”:{“on_off”:1,“mode”:“normal”,“hue”:0,“saturation”:0,“color_temp”:3764,“brightness”:22,“err_code”:0}}}

But during periodic state update this gets lost:

Update Channels for:tplinksmarthome:lb120:XXXXXX
Executing command: {“system”:{“get_sysinfo”:{}}, “smartlife.iot.common.emeter”:{“get_realtime”:{}}}
2018-09-02 21:36:54.467 [TRACE] [.tplinksmarthome.internal.Connection] - Command response: {“system”:{“get_sysinfo”:{“sw_ver”:“1.2.3 Build 170123 Rel.100146”,“hw_ver”:“1.0”,“model”:“LB120(EU)”,“description”:“Smart Wi-Fi LED Bulb with Tunable White Light”,“alias”:“Glühbirne”,“mic_type”:“IOT.SMARTBULB”,“dev_state”:“normal”,“mic_mac”:"…",“deviceId”:"…",“oemId”:"…",“hwId”:"…",“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”:3764,“brightness”:22},“is_dimmable”:1,“is_color”:0,“is_variable_color_temp”:1,}
tplinksmarthome_lb120_XXXXXX_colorTemperature changed from 28 to UNDEF

Of course you only really recognise this, if you not only use a sitemap but interpret values internally or use th Kasa app in parallel.

In the codes I was reading to be able to interpret the trace log, the BulbDevice’s updateChannel method does not deal with color temperatures producing the UNDEF value, if I’m not mislead.

81

Your analyzes is correct. For some undefined reason this channel is not updated.

I’ve created a fix. This is available through the tp-link marketplace binding (it’s a 2.4.0-snapshot version)