Lutrons RadioRA2 - Page 5

I'm still waiting on my RA2 equipment but I'm pretty sure your not going to see a 2 second delay pushing a button and the lights reacting.

I installed a Ra Chronos a month ago in a house and the lights reacted much faster then that.

Yes, the delay i'm talking about is through integration. RA2 by itself should be instant.

edit:
My installer is here installing my keypads now! I will report back with an update on the delay soon.

If you have a 2 second delay between C4 and Lutron, look to C4.

Indeed, The RA2 feedback is INSTANT coming directly off the telnet port.

The delay might be in the C4 driver or as the result of an early beta. I will report back when I get some C4 gear to test with later this week.

There are a couple of gotchas in our few Ra2 installs with Crestron control systems. And this is DEFINITELY one of them is not the fault of the control system as Lutron has admitted the problem - to us at least.

A control system can only send a single command at a time to the Ra2 processor. That is fine except that the command has to be acknowledged before the next command will be executed. So when you press a global scene from a Crestron panel there is a delay, yet not when using a Ra2 keypad.

Along the same lines this is the other big gotcha we found:

Dimming individual loads from a third party controller is cumbersome.
As it has been explained by Lutron, the RS232/IP protocol sends a raise command and then a stop command after the button is released. It takes a noticeable amount of time for this stop command to be received. What the user experiences when the raise or lower button is released is about a 20% jump in light level (up or down) before the action stops. This prevents the ability to finely tune your lights to the level you would like.

How is it that a company like Lutron is still building systems with such a bad control interface? Clearly the idea of a lighting system like this is to incorporate it into a larger automation system. I would bet that the vast majority of installers are going to be doing just this. Yet Lutron combines a great hardware system with a really bad software system! That isn't exactly a receipe for success.

Looks like I will be looking at the Centralite Jetstream system instead.

@sic

Lutron does what they do very well and that's it. They make really expensive lighting solutions that work. Also, those systems can be outfitted in ridiculous colors that designers eat boogers over. So, don't hate.

Regarding Centralite, they make good systems as well for a different price point. To each his own. (Some like five dollar pots and some like fifteen dollar pots. They both hold stuff.)

Wow. I've been installing Lutron systems for a while and generally, Lutron is the most solid part of the install. It's the other stuff that doesn't work right.

Centralite? I've had a tiny bit of experience, and based on that I would run far and fast. To each his own though.

Sorry if my comments sounded like Lutron hating....

But my point is that Lutron had an opportunity to create as close to the "perfect" non-hardwired lighting solution as we have seen yet (obviously this is argueable). Instead, they seemed to have released something with the great hardware design that we expect from Lutron, but with a really poorly designed control protocol.

Everyone that has dealt with automation has seen and dealt with poor control protocols before and we'll continue to deal with them in the future. But it is frustrating to see a great hardware solution only to find out that the integration potential is severely limited because the company didn't put any time/effort/money into developing the control protocol.

It's one thing to deal with this with hardware like TVs. Most TVs are not going to be hooked up to an automation system, so while it is frustrating, I can understand why a TV manufacturer may not spend a lot of time developing a control protocol.

On the other hand, a very large percentage of these types of lighting systems are going to be installed in combination with a larger control system. So I personally think it is inexcusable for a company to create a lighting system with a lacking control protocol. Lutron isn't the first, not will it be the last, but that doesn't make it any less frustrating.

The RA2 Main Repeater has a mystery mini USB connector on it. Maybe this will allow the opportunity for firmware upgrades at a later date to correct any timing issues with third party integration?

I would say around 80-85% of the homes we install a Lutron lighting system in don't feature any third party home automation.
While they will include fairly advanced structured wiring, it won't be integrated other than RF remotes or similar.
I'm not trying to excuse Lutron for this lack of control protocol, but maybe they don't see the development profitable.

I tried connecting to the mini-USB port but the driver failed to install. I checked the RRA2 web site and there is no separate software driver to download, so I would assume that the driver is included with the Essentials software package. Maybe this USB port is for future use?

While we are on the topic of connecting to the main repeater, is there some unusual step to do this? I connected the repeater up to the LAN but it isn't recognized by the network and I can't access it from a browser or from the Essentials software. According to the interface guide, the factory default is to DHCP, so there shouldn't be any IP address issues. What am I missing?

I don't believe you have all the facts at hand.

I agree, but you know Dennis, you don't always have to be so verbose . For instance, you could explain the issue to him. Which I will do. The first issue in Premierht's post is relevant only to the most extreme control freaks. The second issue is a bug and will I am sure be fixed with a future firmware upgrade.

OK, but let's explain to people what this means in practicality (apart from the delay issue). Since a Lutron scene can contain every single light in the system, one command coming from the control system can in fact adjust every light in the house. So the only time the limitation you mention would be an issue is if someone wants to select multiple lights or scenes one by one to create an "on the fly group/scene" so to speak, and then raise or lower that group/group scene. I've never even once had anyone ask me to be able to do that, and personally it's not something even I as an uber geek have the slightest in interest in doing (now is when you tell me how all your customers cannot live without it ).

And to clarify for people, the above limitation does not in any way stop someone from raising or lowering every single light in the house simultaneously, or any scene for that matter. It just means the system won't allow ad hoc grouping of lights and scenes and then raising and lowering that ad hoc group.

The second issue you mention that I did not quote is significant and obviously needs to be fixed with a firmware upgrade.

True but, when one knows "stuff" covered under an NDA, the explanation must be compromised by the threat of dire action contained within that NDA.

It's my understanding that the RA2 Main Repeater cannot be 'integrated' without the programming software.

It's nice to control scenes from a third party controller, but I would think that, the majority of the time, it's done from a scene keypad. Which, reportedly, is instantaneous.

I bet the 2 sec delay from C4 is a bug, but that's just an educated guess.

True fact.

Dennis or anyone,
A new URC remote compatible with Ra2 is projected to be released in April. Will this new remote be able to control lighting without the "overshoot" issue from 3rd party controllers that premierht refers to?

Honest question here - does RadioRA2's protocol allow for a switch's dimmer level to be queried by a third party device? I believe the original RadioRA protocol did not allow for this. The system would only indicate if a dimmer switch was on or off, but not the dimmer level.

From everyone else's replies, it seems that the bug is in the Lutron firmware. So if/when Lutron updates the firmware, the "overshoot" issue should go away. It isn't a problem with the third party devices - so no change should need to be made to the URC device.

Yes, it can report dimmer level, QS shade position, contact-closure output state, etc. The integration protocol is much more extensive than the original RadioRA.

Protocol Guide: http://radiora2.lutron.com/pdf/Integ...20Protocol.pdf

-Sean

Any additional word on RA2 integration with HW4? Specifically, I want to use a few QS components in my current HW4 build

Nice job on the emails





But color me excited

It will never happen. QS will be a completely seperate platform and old HW will eventually fade away

I heard, though, that the old HW would be supported forever. Of course, that was a Lutron rep, FWIW.

The RA2 'buy in' (Main Repeater) is cheap enough that one could use 2 separate systems. The dimmers look the same.

I don't know how well the 2 systems could be integrated - perhaps with a 3rd party controller?

What component are you interested in, Hyperite? HW4 does wireless pretty handily, from what I understand.

It will be supported forever, just as the Original Homeworks system is still supported, but eventually they will stop manufacturing hardware, providing software updates, etc. for the older platforms. It is both excessively complicated and cost-prohibitive to make every product infinitely backward-compatible, though to Lutron's credit they are better than most at doing so.

I just started installing my RA2 system (5 keypad, 14 dimmer/switches). I started a telnet session and issued a few light change commands. I'm not seeing any delay

It does, but I would love to have a few GrafikEye QS, and there is one place in my house that I can't run cable for a Sivoia QED, but a QS shade would work perfectly.