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”.
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.
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.
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.
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
Does anyone know if the latest binding works for Homeworks QS? As of six months ago it didn’t, so I’m currently using some rather hacky nodejs code… but a binding would be much better…
In theory, the 2.4.0 M6 build should work with Homeworks QS. I included a fix for it in PR 3911. I have no way to test it myself, though, so I’d be interested to hear from anyone who can.
Yeah, unfortunately there does not seem to be a way to auto-discover Caseta devices using the public APIs, so you have to configure them manually. Auto-discovery works with RA2, and possibly with Homeworks QS.
I’m very interested in integrating a Caseta Pro hub with OH2, and am interested in using Pico remotes to control other things managed by OH2, esp. lights connected to a Hue bridge. How well have you gotten this to work? Can you dim other non Caseta lights on your OH2 system with the Picos? If so, is there alot of lag?
Hi, @dstjohn. I have been testing a mix of RadioiRA 2, Caseta (Pico remotes), Zigbee and Z-Wave devices controlled by RadioRA 2 wireless keypads and Pico remotes. For the bridge I am not using a Caseta Pro, rather a RadioRA 2 master repeater for the interface with the Lutron devices, but it is all working very well for me, and IMO, the system is very responsive.
I really like that with the Pico and RR2 keypads, I don’t have to configure keypresses with the Lutron configuration software. I have configured OH2 items for individual keys and corresponding OH2 rules to handle keypresses.
Hi, Scott. This seems very much like what I’m trying to do. Do you dim lights this way? If so, is it easy/ergonomic to do (i.e., no frustrating delays or missed key presses)? Seems like OH2 would have to be able to see the key-down and key-up events separately for this to work really well. Is that how it works?
Key-up and key-down are each unique events. In the configuration of keypads for the Lutron binding, there is a parameter, autorelease, that defaults to true. When a keypad is configured with autorelease=true, the release (key-up) event is assumed, i.e., a switch item linked to a key thing will automatically return to the OFF state. It is certainly possible to configure a keypad with autorelease=false, in which case the release event will have to be fielded by a rule to return the corresponding switch item’s state to OFF.
With the Pico keypads, if a key is held for a longer time, a third event code is returned, which effectively indicates that the key was held longer than some built-in interval. If the key is released some time after the “long keypress” event has been emitted by the Lutron system, no additional event is emitted until the key is pressed again.
There are Pico keypads with UP and DOWN buttons that are typically dedicated to dimmer control, but I haven’t tried any of them. The RadioRA 2 keypads also have dedicated UP/DOWN dimmer controls.
Great! If you don’t mind the somewhat higher prices for Lutron devices, I highly recommend them. It sounds to me like you have already done some research on the Caseta possibilities and are aware that you should to get the Caseta Pro Hub rather than the plain vanilla Caseta Hub.
I am glad that Scott was able to answer your questions. I do not have any other smart dimmer lights to control, so I cannot speak to that aspect. Thanks for tagging me, it reminds me that I need to configure more things in my system (I haven’t added much to my system in the past two years).
First, thank you for the work on this. I have deployed this very successfully across my house (2x Caseta Pro bridges and an RA2 bridge with north of 100 devices) and it all ties to OH very well. I am seeing one intermittent issue which I’ve not been successful on pinning down. I have a Serena Shade attached to one of the bridges. Commands work flawlessly and updates work with no issues when they come from OH. I have a Pico remote tied to the shade through the hub and for whatever reason when I use the Pico to raise/lower the shade it does not update the value on the OH side. The shade, pico, and bridge are all within 10 feet of each other in the same room so I don’t believe this is any kind of signal/range issue or anything like that.
