Radio RA2 /Hubitat best practices form the start

I've got 180 RA2 devices, 20+ Zigbee, and 12 Z-Wave. Mix and match all you want, just be aware of the mesh density/layout for Zigbee and Z-Wave. I've got a dozen Picos, and some SeeTouch keypads. You can use modes combined with the keypads so that lights come on to time-of-day appropriate levels.

To your general question, I can confirm that Hubitat does a great job of blending devices across networks. Latency is generally low, and the hub is stable as long as you don’t load it down with a ton of plugins. The Luton integration is especially snappy.

For your specific case of antique switches, a few companies make relays which are designed to mounted in box. I’ve used and recommended aeotec micro and nano switches dozens of times.

One thing I’ve been wondering about in the essentials software is the “green button.”

Does anyone use it?

Thanks for the positive encouragement. I think having the ability to adjust what the various keypads do based on time, and mode, and using phantom buttons in radio ra2 will be great. And thanks for the positive view on using various zig bee and zwave devices. Did I read somewhere that some users are using multiple repeaters to stabilize their system with habitat?

And as someone who has gone full into radio ra2 yourself, do you have any tips or lessons learned, or anything you’d do differently if you could start again?

Sounds like you’re on the right track. A few things:

  1. take the Level 2 training. It’s 2.5 days and $650, but you get a lot of equipment for that price including a main repeater.
  2. Do as much of the scene programming in Lutron software and call the scenes from Hubitat. I think that is where you were going with your phantom buttons comment.
  3. Depending on one’s interest on being part of the bleeding edge, if I were building a new house I’d investigate POE lighting. It’s mostly commercial now, but it’s starting to make its way to residential. One of the downsides is that the controls are not very attractive despite their relative simplicity.

As of July of 2019, when I took it, there was no equipment included in the $650. Still very worth it.

There is a 1 second delay issue with the use of Picos, keypads, and motion sensors when they control a Lutron device via the hub as an intermediary. This is a Lutron main repeater lockout function evidently having to do with RF channel occupancy. As a side note, in a Caséta system this problem is much worse than 1 second.

I lived with this 1 second delay for a few years before becoming aware of it, so I can't say that it's a super big deal. BUT, I did want to get rid of it. Recently I added a second main repeater (you have to take the L2 training to get the Inclusive software to do this). The second main repeater uses a different RF channel than the first one. Consequently, a keypad on one main repeater does not incur the delay when controlling a load on the other main repeater. (Side note, a main repeater can do this same trick with Caséta, by using a manually set different RF channel.)

As a result of the above discovery, I put all of my sensors and keypads on one main repeater, and most of my lighting loads on the other. So, there are not any extra delays when the hub is an intermediary. None of this applies when the keypad/pico is directly controlling a load within the Lutron system, programmed to do so in the Essentials software. But, this does limit the utility of picos, so I don't do that for picos.

With respect to SeeTouch keypads I use an obscure app that is part of the Lutron Integration called RA2 Button Integrator. (This app can be done now by other means.) What it does is use phantom buttons for different mode light levels for each button. The button itself is programmed in the Lutron system to turn on the lowest light level -- night mode. The event of the button being pressed launches the app, which in turn pushes the phantom button appropriate for the current mode. Given the ramp time of Lutron loads, this results in a seamless brightening of the light to the correct level when the button is pushed.

I heartily agree with @bill.d's recommendation to do as much as possible on the Lutron side with scenes, with the exception of Picos. Be a bit careful, because a main repeater can't handle multiple (more than 2) phantom button presses in quick succession. If you find yourself wanting to do that, you need to create a new phantom button that includes the multiplicity of loads to control.

I purchased a Lutron Connect Bridge so that I could use the Lutron Connect mobile app with the RA2 system. This is a very over-priced device that only provides this connectivity option. I basically never use the Lutron Connect app itself, and have gone many months with the Lutron Connect unplugged. I don't recommend that, because getting it reconnected recently was a major pain requiring help from Lutron technical support.

Be sure to give the main repeater, and Lutron ConnectBridge if you have one, static IP addresses.


There are a couple reasons to have a Connect Bridge.

  1. allows direct connection to Alexa/Google/HomeKit and Lutron phone app without going through Hubitat. As @bravenel states, none of these are necessary for Hubitat control/automation. But I like to have them available as redundant controls
  2. eliminates any clock drift on the Main Repeater. Again, not necessary for Hubitat integration. But it would be if you were using any Lutron time-based functionality.

In any case, a Connect Bridge is included in the Level 2 training bundle.

Thank you for all this great advice. @bravenel, out of curiosity - if one uses two Main repeaters, how does that work in the software? Do the two systems coexist seamlessly on the Lutron side? (Ie. in my current house with Caseta, I have two hubs, which are only connected through Apple Home Kit - on the lutron side, they are two seperate "houses").

In RA2 Inclusive, the two main repeaters co-exist in a single system. Individual rooms or devices are joined to each, up to 100 per repeater. On the Hubitat side, only a single telnet connection is made from a single instance of the Lutron Integration app, as the two repeaters communicate with each other over the LAN. Each device in the combined system has a unique Integration ID, including the second main repeater (the first one has ID = 1).

Hi there - -I’m reviving this thread for another conceptual question: our household is used to using Apple’s HomeKit as one of our ways of controlling our home from the iPhone side of things. What have people found as the best way to handle Lutron Scenes (and ra2 keypads) in HomeKit? From what @bravenel and @bill.d have said, keeping most of the scenes on the Lutron side is a good way to go, and makes sense - especially since we’ll be using and controlling most of our loads through Lutron. But what might be the best practice for accessing those scenes in HomeKit?

Duplicating the Lutron scenes with a Homekit scene seems tedious, and wouldn’t let Lutron necessarily know that the ‘scene’ had been activated, right? Would one create homebridge ‘buttons’ that appear in HomeKit that trigger Lutron keypad presses? I.e. have a control “room” in Homekit with some phantom HomeBridge buttons that I program to be called with Homekit scenes, which would, through Hubitat, trigger the related scenes and phantom buttons on the Lutron side, as if we had pressed the related button on a Lutron keypad or pico.

And a larger related question: do people find using HomeKit to aggregate multiple systems better than Hubitat in some situations? (I.e. combining Radio RA2 with a Caseta system- which in Homekit can all appear as one system, OR in Hubitat with HomeBridge, or both?)

Curious to know if people have been using HomeKit with Hubitat through HomeBridge using the Radio Ra2 system and what people have found most useful.

Thanks in advance.

I can't speak to the HomeKit side of things. You can combine multiple Lutron systems in Hubitat, thus creating "one" system. As for Lutron scenes, the Lutron main repeater or SmartBridge can be included in Hubitat as a keypad, making all of those scenes usable with the push of a (phantom) button from apps. There are specific actions available such as Push Button Per Mode, allowing time of day sensitive scene activation, where the scene is defined in the Lutron system. Or Lutron scenes can be combined with Hubitat Scenes (from Groups and Scenes), and Scene Per Mode functionality is available. A Hubitat Scene has the ability to push a button as part of activating the Scene, where that button could be a Lutron phantom button.

If the HomeKit scene is exactly the same (devices and levels) as the Lutron scene, the Lutron system will see the scene as active. And yes, it is tedious to recreate the scene in the Home app. Note that you can also activate a Lutron scene on an iPhone with the the Lutron Connect app.

As Bruce said, there are multiple ways to call a Lutron scene in Hubitat that can then be passed to Homebridge. I personally use switches that are created by the Hubitat Scene app.

I personally choose to integrate systems with native HomeKit integrations directly. That includes Lutron RadioRA 2, Caséta and Philips Hue. I also integrate those systems with Hubitat. But, as discussed in the Scene scenario above you do need to follow the indirect Lutron→Hubitat→Homebridge path to get Lutron scenes into Home.

Thank you for these great answers. I really appreciate the help and advice. I’m sure I’ll be back for more!

Bravenel, I was just saw this post from over a year back on Lutron RA2 delay/latency. I am L2 (and beyond) certified with Lutron RA2/3 and QS. I am looking to get more info on the 1 second delay you mentioned when the hub is an intermediary. I have also noticed this delay. More specifically when a motion sensor turns on a light switch load (via RA2 programming) on the same primary main repeater. Are you saying that if the motion sensor and the light switch are on different main repeaters that this delay of turning on the light goes away? That would be amazing. I will have to try that.

For what it's worth, I believe this delay (and other latency) actually started between v6.3 and v7.x of when Lutron made significant changes to the RA2 software/firmware. I had been always told by Lutron these delays with the side affect of various safeguards that were put in place to protect the operation of the main repeater.

I have working on optimizing and reducing latency in mine (and several other RA2 systems) as I have done rather advanced integration with both Hubitat and some custom python scripts. I had never heard that this delay had to do with any type of RF channel occupancy blocking but it makes good sense that it would. Did you find this in any of the clear connect documentation or were you just told this word of mouth? I have been really focused on improving RA2 system performance since now it is a mature product and Lutron is not doing any real further development.

Yes, it goes away. I have 2 main repeaters. When I added the second, I redid the system to place sensors on one, and the controlled loads on the other.

Haha, yeah sure! Safeguards because they blew it somewhere the best fix was to slow things down.

It's just my guess as to what could cause it. There is nothing about the radio technology that would mandate it, as the main repeater certainly handles commands and responses in near real time in every other circumstance. So it has to be software induced in the main repeater, and I found the 1 second latency to be consistent, and fairly conspicuous. Can't you picture some engineer saying "hey, if we just put a 1 second pause for this all will be ok" (as opposed to say 650 msecs). Who knows? Lutron does lots of silly things driven by their view of markets, and has lots of arbitrary limitations imposed here and there. They are pretty hidebound.

@HubiRaFan Just be sure to use a different a radio frequency/channel on each main repeater.

1 Like

I completely agree. I spent days and weeks working with Lutron's 'systems support engineers' only to reach the conclusion that Lutron induced the latency and it is what it is. Some of my fellow Lutron programming experts actually think Lutron introduced it to purposely cripple the speed of the RA2 product. I think that could be a factor but between v6 and v7 and higher in 2014-16 Lutron rolled out many more timer dependent functions that requires count downs (ie Rollback, ect). Here's a link to the Lutron forums discussing the same:

But for the conspiracy theorists, we had some very large RA2 installations that had lots of wired shades and it wasn't practical to switch to Homeworks (or AMX, Crestron, Savant, ect) so we wrote some Python scrips and software that essentially emulated what Homeworks QS did with a NWK control interface. I think it got Lutron's attention when they realized we had integrated upwards of $1M worth of shades (combined on several RA2 installs) and didn't buy RA2 dongles (which don't scale well) nor Homeworks.

@mike.maxwell has good documentation of the procedure to address the issue. Personally I have both Caséta (for lamps, outdoor plugs, and Picos) and RadioRA 2 (most of my lighting). It's an effective solution to the issue.

I don't think this is true. I think it was done to fix a bug, and was a simple way out of some problem they had. They don't really engineer much for us outside integrators -- seems we're tolerated but that's about it. So this lag only shows up through an integration. Lutron would just have you link the motion sensor directly to the load in the setup. They don't get / don't care about, the sorts of things we do with a RA2 system.

1 Like