Lutron OH2 binding

Add-ons Bindings
,
142

Yes, that would help. I suspect it’s getting tripped up on a byte-order mark.

143

The “Thing” is optional - I’ve deleted it and get the same result. Keypad Thing seems non-functional.

144

Hello - I’m brand new to OH2. So please forgive my newness.

I’m in the same boat as others, my switches are working fine but I’m unable to get my keypads to function. I would like to set rules around key pad presses although it doesn’t seem to be working correctly. I’m guessing this is a function of my lack of understanding OH2.

Can someone please give me an example of how I would create a rule that would respond to a keypad press?

Thank you for the help!

145

Hi Allan - just wondering if you’d updated your fantastic QS binding, or ever got round to do a pull request? Unfortunately the old version you posted in January seems to have stopped working with the latest snapshot - I get a error:

[ERROR] [org.openhab.binding.lutron ] - [org.openhab.binding.lutron.internal.discovery.RadioRA2MainR| 20|epeaterDiscoveryService(267)] The activate method has thrown an exception

thank you!

Dan

146

No, sorry, haven’t had much time for OH. I think you were still having problems with keypads right? I guess if it was still useful to you, I could do a pull request, though maybe I should look at this error you’re getting now. Is there more to the error than what you posted above?

147

Thank you, Allan.

Yes, keypads don’t work, but that’s not a huge issue - it’s still very useful and much appreciated.

The errors go on and on - I’ve copied the log here

thanks,

Dan

149

I’ve finally gotten around to creating a pull request for the keypad enhancements that I mentioned here many months ago. It is currently making its way through the approval process, and I’m hopeful that it will be merged in to 2.4.0.

Here is a brief description of the changes (from github issue #3778):

  • Adds/enhances support for all models of Lutron seeTouch, Hybrid seeTouch, and seeTouch Tabletop keypads supported by Radio RA2. The proper button and LED channels are now dynamically configured for each keypad thing based on a “model” parameter. The configured channels allow you to monitor for key presses, send remote key presses, monitor LED states, and drive LED states. An auto-release configuration parameter has been added for compatibility with Lutron Home+ and other applications that may send a remote button press command without following it with a release. See the updated README.md for details.

  • Adds the same support for all Pico keypad models, again with per-model automatic channel creation based on a “model” parameter.

  • Adds the same support for the RA2 repeater virtual keypad (referred to by Lutron as Integration Buttons or Phantom Buttons).

  • Adds the same support for VCRX keypad buttons.

  • Adds support for VCRX contact closure inputs (CCI).

  • Adds support for both pulsed and maintained CCO outputs (e.g. on VCRX and LMJ-CC01-24-B)

  • Adds additional auto-discovery support for Lutron Tabletop Keypads, Phase-selectable dimmers, tabletop dimmers, plug-in dimming modules, VCRX, CCO modules, and the Softswitch relay RF module (LMJ-16R-DV-B).

If anyone would like to try out the new changes, I’d appreciate getting some feedback on them. I’d especially like to see someone test it on a Caseta system with Pico keypads. I have an updated version of the Lutron binding, incorporating the changes, built on top of a recent 2.4.0 snapshot. It’s available here:

I also have a separate update to the Lutron binding that adds support for Lutron shades (Issue #3845). I’ve tested it with Sivoia QS Wireless roller shades on a RadioRA 2 system. I believe it should also work with other Lutron shades on other systems that speak Lutron Integration Protocol over TCP, such as Serena shades on Caseta systems and Sivioia QS shades on Homeworks QS systems. I have no way to test this myself, though.

Once a few other people have tested out the new shade handler, I will create a PR for that as well. Right now a 2.4.0 version of the Lutron binding incorporating shade support is available here:

Lastly, if you would like to test BOTH the new enhanced keypad code AND the shade support, I’ve built a third version of the 2.4.0 Lutron binding with both changes merged in. That is available here:

You’ll just need to download the appropriate jar file and copy it to your openHAB addons directory. That is /usr/share/openhab2/addons on my apt-managed linux system, but may vary depending on your OS and installation method. Then restart openHAB. Newly supported devices should be auto-discovered on RA2 systems. On other systems, you’ll probably have to configure them manually. See the updated documentation file available here:

                  - Bob
150

Tim, I have the PRG-CI-RS232, which is obviously not IP based. I have had a quick look at your code, but wanted to check if your aware of anyone working on changing to the RS232 comms for this binding (I think homeworks used it). Just wanted to check before embarking - thanks

Jim

151

@nostromo20

I don’t know of anyone doing that. I think that the binding should be fairly compatible with it if you can implement the RS232 transport (rather than the socket one). Good luck and let me know if you have any questions …

Tim

152

Thanks Tim, Will have a go at it - hoping to lift some of the RS232 elements from the RadioRA binding (it actually connects ok with the GRX-CI-RS232). Worst case Im just going to buy the GRX-CI-PRG

Jim

153

I’ve created a new pull request (3911) for the shade support I mentioned here a few weeks ago. Since it was reasonably small, I also included in it a change to the login() method in IPBridgeHandler to recognize the “QNET>” prompt from HWQS. This should allow the binding to work with HWQS, although I have no way to test it myself.

A 2.4.0 SNAPSHOT build of the Lutron binding with PR 3787 and PR 3991 merged in (which includes the new keypad support, shade support, and HWQS login support) is available here:

I’d appreciate hearing back from anyone who can try it out. It will run under OH 2.4.0 SNAPSHOT, and I’ve been told that it also runs under 2.3. I doubt it will run under any versions prior to that.

Bob

154

@BobA, thanks for creating this PR and working to have your updates to the Lutron binding merged to master. Some time ago I had cloned your repo and created a patch set from your changes that I then used to create a local branch from what was then the HEAD of openhab2-addons master. As mainline OH2 development continued, I periodically rebased my local branch onto the latest master. That has worked flawlessly for me.

I removed my manually installed build from my system and replaced it with your jar. So far so good, no issues to report.

Thanks again!

155

Thanks Scott! I’m glad to hear that you’ve found the changes useful! I also appreciate your testing of the new code. Please let me know if you find any problems.

The PR containing the keypad enhancements, VCRX support, and CCO support was merged in yesterday, so now you can get it by just pulling down a 2.4.0 snapshot build. I made a bunch of fixes and improvements to the code as part of the PR review process, but most of them were style-related and/or fairly minor. Functionally, I don’t think you should see much difference between what is now in 2.4.0 and the recent RC jar files I had posted links to previously, or even the code from last year. The only change you probably need to be aware of is, if you are using a Pulsed CCO, the “defaultPulse” config parameter name has been renamed to “pulseLength”.

156

The pull request containing Lutron shade support and the HWQS login fix was merged in to 2.4.0 yesterday. You should now be able to get this functionality by downloading the latest 2.4.0 SNAPSHOT build.

I’d like to hear from anyone who is able to test the binding on a Homeworks QS system, or who can test the new shade handler on a Caseta system.

157

Over the past two weeks, two more updates to the Lutron binding for Radio RA2, Caseta, and Homeworks QS have been merged in to 2.4.0. These fix some longstanding issues with network connectivity and device state management.

The differences you might notice are:

  • The binding will now continue to retry indefinitely if it cannot connect to the Lutron bridge device (the repeater or hub) at startup.
  • The binding should now be able to properly recover in all cases after losing network connectivity to the Lutron bridge device.
  • Lutron things will no longer be marked as ONLINE until the device they control responds to the handler. If you see a Lutron thing with the status “UNKNOWN: Awaiting initial response” for more than a few seconds after startup or re-connection, it is likely that you have configured the wrong integration ID for it. The only exception to this is devices which cannot be queried, such as occupancy sensors and Pico keypads. They will always have the status ONLINE as long as the bridge device status is ONLINE.
  • Thing states (e.g. dimmer levels, shade levels, keypad LED states) should now always reflect the actual device states after recovering from a broken network connection.
  • Two optional configuration parameters, heartbeat and reconnect have been added to the ipbridge thing. These control the time (in minutes) between keep-alive heartbeat messages and reconnection attempts, respectively. They both default to 5 minutes, and should not normally need to be changed.

These changes should be available in all 2.4.0 snapshot and milestone builds going forward. I’d be interested to hear from people who are able to test them out.

158

Hi. Another update to the Radio RA2 binding that I submitted was recently merged in to 2.4.0. It adds support for Timeclock and Green Mode (a.k.a Green Button) controls.

The new greenmode thing allows you to get and set a RA2 system’s active green mode step. This is basically equivalent to pressing the “green buttons” defined on your system.

The new timeclock thing allows you to get and set the current timeclock mode, execute a timeclock event or be notified when one executes, enable or disable a timeclock event, and retrieve the current day’s sunrise and sunset times. In theory, this should also work for HWQS systems.

See the updated documentation for more details:

This functionality should now be available in all 2.4.0 snapshot and milestone builds going forward.

159

Hi,

I have a Lutron Caseta setup in my house with a Lutron P-BDGPRO-PKG1W, 20 dimmers and 15 Pico remotes

I had a working OH 2.3 Lutron setup with the dimmers manually added through the Paper UI

I wanted to try integrating the Picos so I tried to update my OH to 2.4 M6
The ubuntu upgrade would fail as OH would not start

To get OH to start, I had to
Revert back to 2.3
Remove all Lutron Items and Things
Uninstall the Binding

Then an upgraded OH 2.4 M6 would start

Trying to install the Lutron Binding in the Paper UI fails

==> /var/log/openhab2/openhab.log <==
2018-11-25 21:06:55.253 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-lutron': Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-lutron; type=karaf.feature; version="[2.4.0.M6,2.4.0.M6]"; filter:="(&(osgi.identity=openhab-binding-lutron)(type=karaf.feature)(version>=2.4.0.M6)(version<=2.4.0.M6))" [caused by: Unable to resolve openhab-binding-lutron/2.4.0.M6: missing requirement [openhab-binding-lutron/2.4.0.M6] osgi.identity; osgi.identity=org.openhab.binding.lutron; type=osgi.bundle; version="[2.4.0.M6,2.4.0.M6]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.lutron/2.4.0.M6: missing requirement [org.openhab.binding.lutron/2.4.0.M6] osgi.wiring.package; filter:="(osgi.wiring.package=gnu.io)"]]

Manually downloading the binding from your Github also fails to start with the same error

Any suggestions?

160
161

I’m running version 2.4 M6
From the binding docs

Discovery

Full discovery is supported for RadioRA 2 systems. Both the main repeaters themselves and the devices connected to them can be automatically discovered. Discovered RadioRA 2 main repeaters will be accessed using the default integration credentials. These can be changed in the main repeater thing configuration.

Note: Discovery of devices paired with a bridge may work on systems other than RadioRA 2 (e.g. HomeWorks QS). However, the bridge itself will need to be manually added as bridge discovery is only supported for RadioRA 2.

#

My hub is a Caseta Pro and I manually added it. using the paper UI

OH is not showing any auto discovered Things in the inbox.
Caseta Pro hub does not support Discovery?
I used the bridge user “lutron” and password “integration” in the bridge thing

162

I have Caseta Dimmers.
I can manually add a dimmer in paper ui and it works