Has anyone tried the Lutron binding with a RadioRA 3 repeater? I was considering a RA 2 system when I saw the announcement for RA 3. I see the binding supports RA 2 over LIP and other Lutron systems over LEAP. RA 3 seems to support only LEAP now as far as I can tell, and I figure it would be naive to expect it to “just work”.
Thanks in advance!
Nobody that I know of has tried it yet. The binding currently supports HomeWorks QS, RadioRA2, RA2 Select, and Caseta with the Pro hub via LIP. Probably Athena, too, although that hasn’t been tested. It supports Caseta and RA2 Select via LEAP using leapbridge, but not every function is available via LEAP. In particular, keypad button press notifications aren’t available.
It would be unfortunate if RadioRA 3 just supported LEAP, because LIP is easier to work with, not to mention actually documented. They do seem to be moving away from LIP, though, especially in the lower-end products.
Thanks. I eagerly await a report from someone who’s tried it out. If I end up going that route, I’ll try it myself (but it will be a while.)
It looks like the RadioRA 3 processor won’t be shipping until at least the end of January. From what I’ve seen in their docs and training materials, it does only support LEAP. I’m not sure why they’ve done that since I’ve heard that the new HomeWorks and Athena processors also support LIP. Seems like a terrible idea.
I really like that RA3 supports nearly all of the RadioRA 2 devices (although notably not GRAFIK T and GRAFIK Eye) plus the newer Sunnata devices. I also like the look of the new Sunnata controls, although I question the need for the new “ClearConnect X” 2.4GHz mesh network that Sunnata uses. I’ve had zero issues with the 431 MHz ClearConnect devices, so I suspect the “X” mesh network may create more problems than it solves. Especially if they don’t add support for a second processor or a new repeater to get past the 75 foot limit on it. Lutron has other new high-end devices that use X, though, so maybe they’ll eventually add support for some of those to RA3 as well.
Ah, I didn’t realize they weren’t shipping yet. (That could explain why nobody’s tried it! 
I’m a little nervous about usage of the 2.4 GHz band. Everyone says RA2 is rock solid. There are a lot of wifi hot spots in my area such that I need two access points just to drown the 2.4 GHz interference at each end of my small house. I like what they’ve done with the Sunnata dimmers, but I’m wondering if it will be a reliable system.
Hey Bob - I was playing around with a non-Pro Caseta and figured out how to subscribe to Pico button press / release events. Presumably this will work for RadioRA3 as well…
A ReadRequest to /device will have some Pico devices. Each Pico will have a ButtonGroups tag with a buttongroup href and ID.
A ReadRequest to /button will return a series of Buttons tag linked to the above button group. Each of these is a button on the Pico.
As an example, a Pico device will have buttongroup 2, and that buttongroup will have buttons 103-108. (you can dig deeper into the programmingmodels, presets, levels, loads, etc - but if you just want the event this is as far as you need to go - particularly if a pico has no assighments).
The last step is to send a SubscribeRequest for each button ID. For 103, for example, you’d send the SubscribeRequest with the URL /button/103/status/event
Now whenever you press or release that Pico button, you’ll get a ButtonStatus body with a ButtonEvent, and the EventType of “Press” or “Release”.
I’ve been playing around with some simple examples and it seems responsive and consistent.
Hi John. Thanks! That’s fantastic! The binding already understands the buttons and button groups, but I couldn’t figure out how to subscribe to button events. I wasn’t sure if it was even possible for Caseta. I’ll work on updating the binding to support that as soon as I have a bit of time.
I’ve built a test version of the binding that supports LEAP button events. Please try it out and let me know how it works for you! I’d call this an alpha version at the moment since there were a lot of code changes and it’s had only minimal testing.
This should mainly be of interest to Caseta and RA2 Select users, but it should also eventually help with RadioRA 3 support.
Bumping this thread. Is there any update on possible support? I don’t want to drop a few thousand dollars on switches that I can’t control with openhab.
Same here.
It shows up in the logs but there is no way to authenticate it:
2022-08-17 17:05:15.337 [INFO ] [ery.LutronMdnsBridgeDiscoveryService] - Lutron device with unknown DEVCLASS discovered via mDNS: 081B0101. Configure device manually.
2022-08-17 17:05:15.410 [INFO ] [ery.LutronMdnsBridgeDiscoveryService] - Lutron device with unknown DEVCLASS discovered via mDNS: 081B0101. Configure device manually.
2022-08-17 17:05:15.413 [INFO ] [ery.LutronMdnsBridgeDiscoveryService] - Lutron device with unknown DEVCLASS discovered via mDNS: 081B0101. Configure device manually.
Is that the discovery message from a Radio RA3 processor? I can start by adding that devclass ID in to the discovery code. I also have some improved LEAP code that should help with RA3 support, but it’s definitely not supported yet. Have you tried configuring leapbridge to point to it as if it were a Caseta Smart Bridge?
Yup, I got a Processor, a single Sunnata Dimmer and a single Sunnata Keypad to experiment with. We’re are in the process of building a new house and I didn’t want to use Radiora2 with the assumption it’s going the way of the dodo. Worst case, it all goes to eBay and I will look for something else.
If there is something I can do to help you sort it out, please let me know.
Hi. I’ve created PR #13329 ([lutron] Add mDNS discovery for RadioRA 3 processor by bobadair · Pull Request #13299 · openhab/openhab-addons · GitHub) to update mDNS discovery so that it will recognize the RA 3 Processor. You can try out the new discovery code update in this test build:
That’s just a first step toward RA 3 support, though. I’d be interested to know if you can use leapbridge to connect to the RA 3 processor as if it were a Caseta Smart Bridge. It should be able to at least connect and discover devices, whereupon it will probably complain about devices types it doesn’t recognize.
Thanks! It will be a couple of weeks before I get around this though. I’m out of the country and I need to setup a staging server to run a build with that PR, which is something not easily done remotely.
You shouldn’t need to build it. You can just download the test binding jar file from the release link above.
Sorry, yesterday I did not even look at the GitHub link. I’m running 3.3. To test it I would need to add your commit to a local 3.3 fork and build the jar bundle locally. Or setup a 3.4 staging server and use your jar bundle. Neither of those are simple to do remotely. I will handle it when I get back.
With all that said, I wonder how the authentication will work out. I remember toying with it a couple of months back and none of the tools I had found at that time worked with it. For instance, the official docs regarding Configuring LEAP Authentication points to a dead link. The tools found under pylutron-caseta don’t seem to work either. But… I didn’t spend a great deal of time trying either. I figure this will get sorted out eventually. More when I get back…
Thanks!
Hi.Usually bindings will work with an earlier version of OH unless there has been some breaking change to the interface. I’m not aware of one in 3.4, but I haven’t tested it either. I’d just try it and see if it works.
In any case, it’s more important to see if you can get authentication working with leapbridge. It looks like new versions of the pylutron-caseta tools should work with RA 3.
Yup, that was the first thing I did:
==> openhab.log <==
2022-08-22 01:49:26.229 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.lutron-3.4.0-SNAPSHOT-ra3-1.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.lutron [233]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:445) ~[org.eclipse.osgi-3.17.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.7.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.7.4]
Sometimes that error just means that the serial transport module wasn’t loaded. Try running the following from the console:
feature:install openhab-transport-serial