I’ve updated the binding in the marketplace based on your feedback. If you uninstall the current binding and reinstall the binding from the eclipse market place you should have the new version. You can check this by seeing if the label correctly show hs220.
I hope the binding correctly read the status when changed via switch or kasa app. I’ve made a change here that hopefully fixes the issue.
It looks like it’s not allowed to send brightness 0. This would explain why you could not switch the device off. I’ve changed this. In this update it doesn’t switch the device on when brightness is set. It assumes when brightness is set the device will switch on. (I read on other forums this should work). Can you confirm this does work?
I’ve removed the switch channel. When you define a Switch item on the brightness channel it will only send a switch on/off command and not update the brightness. This is actually how it also works with bulbs. So you can create 2 items a Dimmer and Switch to the same brightness channel and this will give you independent switching and dimming.
I can confirm that the label in the binding config looks correct now.
I setup a hs220 thing like this:
Thing tplinksmarthome:hs220:fhdimmer [ipAddress=“192.168.1.196”, refresh=10, transitionPeriod=1000 ]
Then I setup Dimmer and Switch items like this:
Dimmer fronthall_dim “Front Hall Dimmer” (gInsideLight)
{channel=“tplinksmarthome:hs220:fhdimmer:brightness”}
Switch fronthall_sw “Front Hall” (gInsideLight)
{channel=“tplinksmarthome:hs220:fhdimmer:brightness”}
Switching and Dimmer level setting seem to work great.
I like that the dimmer seems to be independent of the switching.
The feedback loop is also working between kasa, the physical switch and openhab seems to be working for switching and dimmer level. There is some lag, but I don’t notice a big difference between kasa and openhab.
I’ll keep testing it, but this version seems to be a winner so far.
The state issue with the bulbs should be fixed in the binding that is available via the Eclipse Marketplace. The fix wil also be in the 2.3.0 release. (The HS220 didn’t make it in the 2.3.0 release, but will be in the 2.4.0 and is already in the Marketplace and 2.4.0-SNAPSHOT).
I am sorry to bring this old post alive, but trying to configure a TP-Link HS220 Dimmer this week, I stumbled across some issues with the binding still.
I tried the version shipped with 2.4-Stable and some snapshots: 2.4.0.201810291414 and 2.4.0.201812271133.
The Thing is added thru a Things file: tplinksmarthome:hs220:HO_FF_Kitchen_DimmerXXXX "Kitchen Suspended Lights" [ ipAddress="XX.XX.XX.XX", refresh=1 ]
The switch item: Switch HO_FF_Kitchen_SuspendedLights_OnOff "Kitchen Suspended Lights On Off" <switch> (Kitchen, Kitchen_Lights_AOOC) {channel="tplinksmarthome:hs220:HO_FF_Kitchen_DimmerXXXX:switch"}
The issues are:
When the Dimmer slider, thru PaperUI, is put to 0%, the item fails with Error (-3) 'tplinksmarthome:hs220:HO_FF_Kitchen_DimmerXXXX' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (-3): invalid argument
The item state does not update when turned ON or OFF, or when Brightness is changed using physical buttons.
Hmm that’s strange. It looks like some changes I made didn’t end up in the original pull request. Sorry for that. There is a jar that should contain the fix (I think, didn’t check) it’s here: edit: removed link, the updated binding is available in the eclipse market place
I’ve updated the binding in the Eclipse Market Place. It contains the fix as well as fixes made after the binding I referred too. (For example the ability to set id as identification instead of ipAddress to handle ip changes better).
Yes if you want to install the market place binding you need to uninstall the installed binding. It uses the same namespace i.e. it will not install.
Yes. if your things were created some time ago (prior to 2.4 release) you might have to recreate them to have property to set the device id (this to handle changing ip addresses of the devices)
I’m new to openHAB, so I’m at a complete loss of understanding in respect to back-end operations.
Can someone explain, or point me to a resources that explains, how I would go about setting up said rules and then incorporating that into a button in the Panel UI?
Hi Jacob, I see that no one has responded here, so I thought I’d follow up (I’ve been away from the OH community for a few months and only came back to it this week).
I’m unclear on what you’re asking. Do you want to have a button that triggers a fade on the dimmer switch, and a separate button to trigger an immediate off state? Or do you want a switch that enables you to toggle between the different modes available on the TP-Link dimmer?
Personally, I just set the gentleoff mode using the TP-Link app, and left it at that.
I’m fairly new to OpenHAB (previously was experimenting with Home Assistant, although a few things didn’t quite work how I wanted there, so I thought I’d give OpenHAB a go.)
I have invested into the TP-Link Ecosystem and have swapped all the light switches in my house with HS200, HS210 and HS220 switches, and love the capability the Kasa app gives, where you can schedule the HS220 lights to fade on/off at certain times, specifically by sunset/sunrise.
I would love to be able to move that automation to OpenHAB instead of the Kasa app for the slow dimming functionality. I already have the Astro Binding installed to take care of the Civil Dawn/Civil Dusk times.
Has the slow fade on/off been incorporated in the tp-link binding, and if so, could someone point me in the right direction for the command to do a 10-20 minute fade-on via a rule?
Much appreciated!
–Edit–
I stumbled across the universaldimmer function, and implemented it successfully, which makes me incredibly happy, as I was unable to get any kind of automations working in Hass.io in regards to slowly fading a light over a set period of time, but this works a treat. Progressive Dimmer Rules
My only issue is it doesn’t appear to work with my Magic Home Single-Color LED Controller, although it seems I can’t get the dimming function to work even manually with that through openHAB.
Will continue to tinker with it and see what I’m able to figure out.
You can configure a thing with the transitionPeriod. It’s not changeable dynamically, but maybe not needed. You can configure a thing specifically for this option, next to another thing with normal behavior:
Thk Hilbrand for the good support over this binding. I’m currently experiencing a strange behaviour with an HS220 Dimmer.
When controlling the dimmer item from openhab, the dimmer value always return to 0 and the physical light stay closed
When starting the light manually (app of physical wall dimmer) the Value gets updated in openhab and I can Slide around in openhab without any issue (except if I slide it back to 0)
If I close the light manually (app of physical wall dimmer) the Value gets updated to 0 and same behavior, can’t restart it in openhab.
I’ve been trying to search around in the forum but aside from this post nothing showed up
My event log is pretty much the same thing
2020-12-30 19:37:32.186 [ome.event.ItemCommandEvent] - Item ‘lt_ss_mur’ received command 35
2020-12-30 19:37:32.198 [nt.ItemStatePredictedEvent] - lt_ss_mur predicted to become 35
2020-12-30 19:37:32.201 [vent.ItemStateChangedEvent] - lt_ss_mur changed from 0 to 35
2020-12-30 19:37:32.338 [vent.ItemStateChangedEvent] - lt_ss_mur changed from 35 to 0
I did delete my thing in paper UI and Manually add it back
Details:
Binding:
TP-Link Smart Home Binding (Beta) market:binding-3614612 - 1.0
I’m missing what openHAB version you are using. Because only if you are on 2.4 there is a reason to use the marketplace version, and that version I’m not very actively updating. The 2.5 included binding contains all updates and also changes for hs220.
found this for others looking for a solution also.