You’ll need to put the binding jar in the addons/ directory.
Because I am newbie, I thanks you very much.
Looks like a Lutron Smart Bridge PRO is “very unhappy” with commands being sent while a button is down. I’ve seen “hangs” of a fraction of a second up to tens of seconds when either a set-level of begin-fade command is sent. It doesn’t look like an openHAB issue as I’m seeing the same thing with my Python code.
As a related observation, it appears that the Smart Bridge generally takes action on key-up, not key-down.
Hi Allan Tong,
I tried to use binding lutron HomeWorks QS v2( org.openhab.binding.lutron-2.1.0-SNAPSHOT.jar), I saw in log, it get error with reconnect, and 5 minutes it still not reconnect again.
My version openHab of me is 2.0.0. Can you help me to solve this problem.
This is my log:
2017-03-30 01:33:11.351 [ERROR] [nding.lutron.handler.IPBridgeHandler] - Communication error, will try to reconnect
java.io.IOException: Could not write to stream
at org.openhab.binding.lutron.internal.net.TelnetSession.writeLine(TelnetSession.java:234)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.sendCommands(IPBridgeHandler.java:206)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.access$2(IPBridgeHandler.java:198)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler$4.run(IPBridgeHandler.java:184)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_65]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
2017-03-30 01:33:11.373 [ERROR] [nding.lutron.handler.IPBridgeHandler] - Error disconnecting
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:116)[:1.8.0_65]
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)[:1.8.0_65]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)[:1.8.0_65]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)[:1.8.0_65]
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)[:1.8.0_65]
at org.apache.commons.net.telnet.TelnetClient._closeOutputStream(TelnetClient.java:86)[175:org.apache.commons.net:3.2.0]
at org.apache.commons.net.telnet.TelnetOutputStream.close(TelnetOutputStream.java:155)[175:org.apache.commons.net:3.2.0]
at org.apache.commons.net.telnet.TelnetClient.disconnect(TelnetClient.java:127)[175:org.apache.commons.net:3.2.0]
at org.openhab.binding.lutron.internal.net.TelnetSession.close(TelnetSession.java:118)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.disconnect(IPBridgeHandler.java:243)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.reconnect(IPBridgeHandler.java:253)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.sendCommands(IPBridgeHandler.java:214)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler.access$2(IPBridgeHandler.java:198)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at org.openhab.binding.lutron.handler.IPBridgeHandler$4.run(IPBridgeHandler.java:184)[283:org.openhab.binding.lutron:2.1.0.201702112004]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_65]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_65]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_65]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_65]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_65]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_65]
Thanks you !
Could someone just post a clear straightforward walk through on getting the Caseta lights to work with this binding? A very clear, concise example?
First, for openHAB, you need a Smart Bridge Pro and not the Smart Bridge that you can pick up at your local big box store. The Pro model is an “installer” version that you’ll need to obtain elsewhere. They are available through other sellers.
There are three protocols that the Smart Bridge Pro “talks”:
- Lutron Integration Protocol (LIP) over telnet
- LEAP over ssh
- Secure MQTT
The first is the only one available without a reverse-engineered or NDA-encumbered “secure” key as well as with a Lutron-published, public protocol spec. I don’t think anyone would sign-off on allowing that into openHAB.
Only LIP over telnet is fast enough to be considered “real time”. If you have a Smart Bridge Pro, you will need to enable it using the Advanced settings in your smart-phone app.
The following appear to be limitations of the Smart Bridge Pro itself:
- Events or actions while a button is down can slow response to the 10-15 second range
- Makes use of the increase/decrease function “impossible” through external control
- Can result in, for example, a two-second physical press being reported as 1.5 seconds
- Scenes are not reported as “matching” the way that they are in the smart-phone app
- The buttons on the dimmers are not reported at all
- The Pico remotes don’t (natively) report multi-tap, long-press, or multiple press actions
- Access to the integration report is not possible through LIP
The following are limitations of openHAB that you should be aware of:
- The scenes are not available
- The increase/decrease functions are not available
- You can’t, from what I can tell, change the fade time on an event-by-event basis
- You can’t, from what I can tell, set the fade delay at all
Once enabled, you’ll need a Thing for the bridge, each dimmer, and each keypad.
Get the integration IDs by generating an “integration report” using the smart-phone app.
Bridge (the angle brackets are notation, not part of the Thing declaration):
lutron:ipbridge:SmartBridgePro "Smart Bridge Pro" @ "Home" [ ipAddress="<IP or hostname>", user="lutron", password="integration" ]
Dimmer:
lutron:dimmer:Bedroom_East_Cans "Bedroom East Cans" (lutron:ipbridge:SmartBridgePro) @ "Bedroom" [ integrationId=2 ]
Pico:
lutron:keypad:Bedroom_One "Bedroom One" (lutron:ipbridge:SmartBridgePro) @ "Bedroom" [ integrationId=3 ]
Each dimmer will need an Item for the level. I’ve included the notation for assigning the dimmer to a couple groups here. The group assignment is optional, but very useful since you can’t control the scenes with openHAB at this time. The notation for creating groups is documented beneath the dimmer.
Dimmer caseta_dimmer_Bedroom_East_Cans
"Dimmer Bedroom East Cans [%.0f]" <dimmablelight>
(
group_all_dimmers,
group_Bedroom_dimmers
)
{ channel="lutron:dimmer:Bedroom_East_Cans:lightlevel" }
Creating groups (MAX or another “combinator” is required, contrary to documentation. Issue filed):
Group:Dimmer:MAX group_all_dimmers
Group:Dimmer:MAX group_Bedroom_dimmers
For each Pico you need an Item for each of the five buttons available. Again, I group these for convenience.
Group:Switch:AND(OFF, ON) group_all_picos
Group:Switch:AND(OFF, ON) group_pico_Bedroom_One
Switch pico_Bedroom_One_on
"Pico Bedroom One On" <switch>
(
group_all_picos,
group_pico_Bedroom_One
)
{ channel="lutron:keypad:Bedroom_One:button2" }
Switch pico_Bedroom_One_preset
"Pico Bedroom One Preset" <switch>
(
group_all_picos,
group_pico_Bedroom_One
)
{ channel="lutron:keypad:Bedroom_One:button3" }
Switch pico_Bedroom_One_off
"Pico Bedroom One Off" <switch>
(
group_all_picos,
group_pico_Bedroom_One
)
{ channel="lutron:keypad:Bedroom_One:button4" }
Switch pico_Bedroom_One_up
"Pico Bedroom One Up" <switch>
(
group_all_picos,
group_pico_Bedroom_One
)
{ channel="lutron:keypad:Bedroom_One:button5" }
Switch pico_Bedroom_One_down
"Pico Bedroom One Down" <switch>
(
group_all_picos,
group_pico_Bedroom_One
)
{ channel="lutron:keypad:Bedroom_One:button6" }
I’ve gotten to the point where the limitations and bugs of openHAB have driven me to manage my Lutron through Python. If openHAB provides access to the scenes, I might come back once the JSR233 rule extension lets me write rules in a meaningful, documented, stable, language. Managing scenes through a set of 20+ Items with both a level and a Boolean for if the dimmer is in the scene, for each scene, isn’t a “design pattern”, it’s a design flaw. My approach, in general is:
- Use the Lutron app to assign the Picos to the devices they “directly” control for dim-up/down
- Use scripts to add additional dimmers that should be controlled beyond those groupings, typically by activating a scene
- Use scripts to detect and take action on long-press and multi-tap events
3 Likes
Thanks for consolidating this information to one place. Really helpful!
Thanks for putting this together. Really helped me out!
So today I picked up a hub pro with a dimmer and one Pico remote.
What’s great and unexpected is that I now can use feedback from the buttons on Pico remote to control the volume of my Marantz receiver over the gc-100.
This has become a pleasant surprise, as now I have an option for customizable tactile remote control for my integrated equipment around the house. Not just an app on the smartphone.
Looking to start a smarthome from scratch, but everything is either expensive or doesn’t work [well] with OH(2). My father works for a building automation firm that now has a partnership with Lutron, so we’re thinking he should be able to pick up Lutron modules as needed through work, and we can use openHAB to control them somehow since there’s a Lutron binding listed… So I told him to order the Lutron starter kit, which comes with the latest hub.
Obviously I jumped the gun. Reading this tread has made me realize I probably should NOT order that kit, as it doesn’t say “Pro” for the bridge. Further, I’m confused over this whole Caseta and “Ra” thing, which is looking like I should be getting a different bridge entirely if I want to support all/more Lutron devices (who knows what version/protocol they’ll be when he orders them through work)? And even then, it sounds like the pico switches aren’t fully supported, and other basic features are still missing at this point (which is fine, of course, thanks for your work!) so maybe I should not dive into full Lutron mode after all.
Do I have any of this wrong? More importantly, can I control this stuff with some other hub? It looks like, for example, the Wink hub, which has a binding now, “Supports Lutron Clear Connect”. Does this mean I can just use Lutron gear with that for now, and have it all Just Work on openHAB through the hub?
Thanks in advance!
50/50
If you ordered a Caseta (non-Pro) starter kit, then you might want to return it. It will not work.
You need to find a local Luron distributor and get a pro kit from them. Only “Pro” hub has option to open up the unencrypted telnet communication which is used by the openhab.
However, Caseta is not meant for any large building. The Caseta hub is rated for 30 ft of coverage. So you should put all the wireless caseta dimmers and switchers within this distance from the hub. You can make a one-time extension using a plug-in dimmer which can be converted to the wireless extender, giving you additional 30 ft coverage within the extender.
So if your dimmers and switches are going to be spaced out more than that, Caseta system will not work.
For any large-scale project you need to use radio RA2.
So far as I tried to use pico remotes with open hab, they are working OK. The response time is longer than just using them for the light because they have to jump one extra step between the caseta hub and openhab. I also noticed that after some idle time the pico remote need an extra press of the button to wake up if integrated in openhab as AV remotes.
Complete openHAB NEWB here, I’m well versed in Lutron and decide to try the openHAB with my own Radio Ra 2 system. I loaded it on a PI2 and did the binding, it found about 1/2 of my devices. I am able to occasionally get an device to respond through the PAPER GUI but not consistently and no response at all from my keypads that were auto discovered. I literally Wrote the Image, installed on the PI, did the binding and discovery and that’s it. Am I missing something here?
Just curious if most of you are running on the PI or PC?
I run it on a PC. All the Lutron integration protocol messages the binding sends and receives should be logged. Do you see those?
Hi all. I’m new to the forum and relatively new to OH2. I’ve been using the Lutron binding with my RadioRA2 sytem for a little while now, and it has worked well. However, it didn’t support all of my devices. I have a large-ish system that includes a few uncommon components. I felt like doing a bit of Java coding, so I’ve been experimenting with making some additions. So far I’ve added support for the following:
- seeTouch Tabletop keypads, with the proper channels dynamically created for each model based on a “model” parameter
- Specific Pico keypad support, again with with per-model automatic channel creation based on a “model” parameter
- VCRX
- Pulsed CCO outputs (e.g. on VCRX and CCO modules)
- RA2 & HWQS Timeclock(s)
- RA2 “Green Mode Steps”
- Additional auto-discovery support for Timeclock(s), Green Mode, Tabletop Keypads, Phase-selectable dimmers, tabletop dimmers, plug-in dimming modules, VCRX, CCO modules, and the Softswitch relay RF module (LMJ-16R-DV-B).
Notes:
-
These changes are not quite fully baked and certainly not fully tested yet. I’d characterize them as approximately alpha quality at this point. In particular, I have only tested with RA2 as that is the only system I have access to.
-
I’m still trying to decide how best to define the channels and channel types. I’m using the new trigger channels in some places, which work well for some things but not so well for others.
-
The handlers for seeTouch Tabletop Keypads, Pico keypads, and VCRX, extend the new abstract class BaseKeypadHandler. This scheme allows support for new keypad types to be more easily added by again extending that class, defining a new enum of button, LED, and CCI (in the case of VCRX) components, and providing a new configureComponents() method.
-
The keypad handler code allows you to drive LED states on the keypad(s). I believe you need to be running version 11.6 or higher of the RA2 software in order for the main repeater to not override your settings on unbound buttons.
-
RA2 has a single timeclock. I’ve heard that HWQS may in some cases support multiple timeclocks. If so, the code should generally support that, although maybe not for querying scheduled events (which isn’t fully suppored on RA2 yet either).
Anyone interested, please fell free to take a look at my fork on github (branch: updatelutron) at:
- BobHas anyone found a way to make the binding work with Homeworks QS?
Dan
+1 For this, I had it working but that was earlier this year… can’t remember what I did now, and my openhab install SD card just gave up the ghost, now I’m trying to retrace my footsteps as I didn’t back it up!
Any easy way to do openhab backups? I’m off to google…
Both versions say they work with home kit, I ended up having to buy the pro hub after making that mistake
The work on the additions to the Lutron binding for RA2 which I mentioned here a few weeks ago has been slowly progressing. I have handlers for seeTouch tabletop keypads, VCRX, and Pico keypads working well, and with auto-discovery support. These allow you to monitor for key presses, send remote key presses, monitor LED states, and drive LED states. They also automatically create the proper channels for each keypad model based on a “model” parameter. The VCRX handler also supports the CCI inputs, although that still needs some testing
On the output side, I’ve added support for pulsed and maintained CCO modules (in VCRX and stand-alone), and added auto-discovery support for several additional dimmer and switch models.
Finally, I have handlers for the Lutron RA2 timeclock and “Green mode” working. However, those are still experimental and require a bit of tweaking, so I’ll probably pull that code out into a separate branch before I try to generate an initial pull request.
If anyone is interested in helping to test these additions and/or providing feedback please let me know.
- Bob
Hi Bob, I’m glad to see you are working on this. I’m experimenting with OH mostly to support some more advanced conditional logic that isn’t available with RA2. I have also noticed some of the limitations and am really glad to see your list. I’d be happy to do some testing. I think I have all the models except the relay modules. I’d love to test VCRX and driving keypad LED’s.
-Erik
Did anyone ever get this to work with the Homeworks QS? I have the telnet IP/Login/Password, but the prompt is QNET instead of the GNET that the normal binding seems to look for. I don’t have the SmartBridge Pro or anything, but the Homeworks QS itself allows telnet.
1 Like
unfortunately I’m in the same position, and don’t have a solution (other than using openhab to run expect scripts that telnet in and turn lights on/off).