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.
I have ordered some LB230 bulbs that have not yet been delivered so I am very interested in:
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 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
feedab.
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.
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ā¦
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.
Regarding:
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 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.
carloszacu
(Carlos Andres Zapata Cuervo (El Loco))
30
Hereās how I added the HS200ās to the Items, Things and Sitemap in case thatĀ“s useful for 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.
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?
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!
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.
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?