Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Lutron Radio RA2
So, I got burnt out on the other stuff I was working on, so I took some time tonight to set up my little RA2 system and get the software installed and the modules setup and activated. I've got one issue to figure out (can't get the Visor receiver guy to work), but otherwise it's working and I should be able to start working on a driver for it.

Not sure if there's even anyone here to play with it, but we need to get a driver out there in case someone does come along I guess. I should be able to get the basics solid with the little setup I have.

Anyway, I'll keep this thread updated with the state of the state until it becomes official. This won't be a full time effort, just something I'll do between doing other things for a couple weeks until I have a basic driver done.


Note that, as of 4.2.915, there is no longer a client side driver. The configuration data is just in a text file. If you have the driver installed before you upgrade, it should move your existing (configuration server-based) configuration over to the new file based format. So, after the system comes up, you should see the new file show up. Let it do this conversion for you, i.e. don't create a file first. This way it'll clean up the old config out of the config server. After that you can edit the file.

Here is some documentation on how to edit it until the official docs are updated when this becomes the officially released version.

File Location

As is the standard, all driver created files are in [cqc]\CQCData\MacroFileRoot\Drivers\RadioRA2\, on the machine where the driver is loaded. The name of the file is [moniker].Cfg, so if there's more than one driver instance on the same machine they won't conflict with each other. If you change the driver moniker, you can just rename the file to match and it will pick it up under the new moniker.

It's a simple text file, so edit with Notepad or some other text editor. You should use one that creates a Windows style new line or the code that streams it into the driver may get confused.

File Format

The basic format of the file is a first line that indicates a version. Then, for each possible type of unit supported, there's a header line with a count of how many of those are two follow, then one line each for each of the units configured. You can't have any empty lines or comments or anything. Here is an example file.


In this sample the version is 2 (which is this new file based format). There's 1 button, 2 dimmers, 2 LEDs, and 1 occupancy sensor. Each of these sections starts with a header (e.g. DimmerCnt=2) followed the indicated number of units of that type. All of the lines start with a type indicator and equal sign. Then there's a name for the unit (used to create the field if a field is created), followed by a Lutron RA2/Homeworks address, which is an integration id, colon, then a component id.

You can't leave out any unit type sections, even if you don't have any to configure. Include the header line and set the count to zero, e.g. ButtonCnt=0. You can have space between the values on a line, or not.

Some of these unit types can send out event triggers. You can indicate on an individual basis if they should or not. Buttons and Occupancy Sensors are the only ones currently. On those, there is a trailing value which will be Trig or NoTrig (case sensitive) which indicates whether to send a trigger or not. If not there it defaults to Trig, but best to put them there explicitly. Buttons will send User Action triggers and Occupanancy Sensors will send Motion event triggers.

* Dimmers always have a component id of 0. Occupancy sensors always have a component id of 2, so be sure you use the right comp ids for those. For others, the ids are based on your Lutron configuration. You can see the component ids in the Lutron setup software and the integration ids supported by any particular unit is based on the specific model, documented in the Lutron documentation. I.e. a keypad will have so many LEDs and Buttons, and what component ids they will have will be dependent on the model of keypad, so you always have to look them up.

* Currently only buttons and occ. sensors support triggers. Since those really exist only cause triggers to be sent out, it's unlikely you use anything but Trig on those, since otherwise there's no reason to even tell CQC about them. However, in the future there may be some that both create fields and can send triggers, and then the trigger control mechanism will have more usefulness.

Changing the Config

To change the configuration, edit the file and save it. Then write to the ReloadCfg field of the driver. It will reload the file and reset itself to this new config setup. If there are errors, it will just go back to a default configuration with no anythings. You'll need to fix the error and try it again. If it comes back up with unit oriented fields, then it worked.

Note that occupancy sensors and buttons don't create any fields. They are there purely to tell the driver that you want it to send out event triggers for those buttons and sensors. The sensors are typically battery operated and can't be polled, so there's no use trying to have a field to show their current state. They would never have any value until the sensor was actually tripped.
Dean Roddey
Explorans limites defectum
That would be great. I'll be happy to test occassionally. As a reminder: I have the new Homeworks QS (the replacement for the classic Homeworks). The protocol for QS and RA2 are the same, but QS is a superset. Before you start, take a look at and do a quick compare of the QS to the RA2 (they are both in the same Lutron Integration Protocol doc). I'm not saying to implement every bit of QS functionality; rather, there may be some easy opportunities to kill two birds with one stone. Some of these are easy to implement and have a big impact (e.g., the ability to blink an LED on a Lutron kp instead of just turn it on/off)

Also, were you planning IP or rs232? (IP hopefully). While the RA2 has both the 232 and an ethernet port, the QS processor ONLY has ethernet port. The IP approach requires a validated (username/pwd) session to get into Lutron; whereas the 232 approach does not require validation (that is why it is not just a matter of buying a IP to 232 adaptor).

I have 42 keypads (6 button + raise/lower), a dozen or so shades, about 20 motion sensors, 100 or so switchlegs/loads (mostly dimmable, some on/off) and a few CCOs.

Please do not limit integration IDs to <256.

It can do both IP and serial easily enough. That's common done where the protocol is the same. The same driver, two different manifest files to point it at one type of connection or the other. I'll start with IP since that's how I have it connected right now.
Dean Roddey
Explorans limites defectum

I have a working RA2 system and am looking forward to testing this out!
I've gotten started on this guy. I had a slight distraction to do a Pentair Pool/Spa driver done, since it was paying gig and I always need the bucks. I'll finish that up and get back to this guy in the next day or so.
Dean Roddey
Explorans limites defectum
I made some more progress today on this guy. Lost a lot of time dealing with issues on the Pentair driver that look now to be on the device side. But I moved over to this guy and got a lot more of the driver infrastructure in place, with all the message parsing and building and validating.

I've got it dealing with dimmers now, using a little faked in driver configuration until the client side driver interface is done. I'm seeing the async notifications for changes and keeping in sync with the dimmer state.

Config will be similar to the old Homeworks driver. Define the buttons, LEDs, and dimmers you want the driver to know about, and provide the address. In the new world the addres is in the form 'integrationid:componentid'. Dimmers don't have a component id (the sub-thingie within the larger thingie), so just provide 0 for the component id on those. For buttons and LEDs it's the particular button or LED within the keypad or repeater.
Dean Roddey
Explorans limites defectum
I got the LEDs done, along with some improvements in the general structure of the driver after I realized I'd missed an important point.
Dean Roddey
Explorans limites defectum
I was burned out on the other thing I was working on, so I put in a long day on this guy today and basically finished it up, including the client side configuration driver. Sine it has a client side driver, so it has to be put out as part of a release. I'll do some more testing on it and put up a beta drop tomorrow of the next day so people can start playing with it.
Dean Roddey
Explorans limites defectum
I just posted a first version of this driver in the 4.2.900 beta I just posted (in the usual sticky thread at the top of the Beta discussions thread.) Though it's a RadioRA2 driver, it should work fine with the Homeworks QS system as well. This is just a first implementation to get it out there and see how it works for folks. We can add more stuff to it moving forward. But it should be pretty useful at this point.

I haven't got a documentation page for it yet, but here's the basic documentation if you want to give it a try:


It handles Buttons, Dimmers, and LEDs. As with the old Homeworks driver, you have to configure the buttons, dimmers and LEDs you want the driver to be aware of. Unlike that driver the 'address' of each configured thing is now just a combination of two numbers, the integration id and the component id.

The integration id is the overall number assigned to the thing itself. If it has any sub-bits, such as the LEDs or buttons in a keypad, those are numbered separately via a component id. So an address might 7:81, or something like that. Dimmers don't have any sub-components, so they don't have any component id. Therefore for dimmers it will be disabled while you configure one and will be forced to be zero.

You have to look up the component ids for the particular type of device, it depends on the type of pad or integration point. They each assign their own component ids, depending on what types of sub-addressable bits they have.

They also define what commands are available. The commands will often be accepted even if the module being targeted don't accept them, so you have to be sure if they do or not. For instance, you can send a flash LED command to an LED that doesn't support it. It will accept it and will actually go into flashing state as far as reported state, even though it doesn't support flashing.

Once you've run the Lutron software and assigned component ids to all the bits and transmitted all the configuration changes, you load the driver and then the client side driver, configure the stuff you want, then send the changes to the driver. A that point the fields should show up in the driver.

The fields have prefixes, Dim_xxx, LED_xxx, or Button_xxx, where xxx is the name you gave in the configuration. The name of the items are the xxx part, so anywhere you are supposed to provide the name of something, don't use the prefix part.

Configurable Stuff

Buttons - Buttons don't get any fields. They are configured for two purposes. One is so that button presses will send out User Action triggers. That will only happen for buttons that are configured. The other is so that they can be referred to in the InvokeCmd field in any commands that operate on buttons.

Dimmers - These get a 0 to 100 cardinal field to set/show the dimmer level.

LEDs - These get a boolean field to control whether they are off or on. They can also be sent commands via InvokeCmd to make them flash if the particular device the LEDs are in supports that.

The InvokeCmd Commands

More commands will be implemented as we go. This is just an intiial implementation to see how it's going to work for folks.

Quote:ButtonSim : buttonname, [Press|Release]
FlashLED : ledname, [Slow|Fast]
SetDimmer : dimmername, percentlevel, seconds (0 to 30)

Event Triggers

For any buttons you have configured, the driver will send out User Action events. The event type will be ButtonPress, and the event data will be the name of the button, a dash, and then the component id of the actual button, so something like:

Quote:ButtonPress, KitchenKP-3

Note that the driver will only see button press events for keypads that are set up for the single control style. If it's set up for scene type operation the Lutron doesn't send any button events, the driver only sees the results of any changes that the button press causes in other things.
Dean Roddey
Explorans limites defectum
Dean, did Lutron add percent dim state to dimmers for this? IIRC RA1 didn't support that.

Possibly Related Threads...
Thread Author Replies Views Last Post
  W800RF32 by WGL (32 bit radio receiver) driver by BPH bph 68 22,525 05-14-2016, 08:01 AM
Last Post: jkmonroe
  XM Radio Channel Information Driver Jonathan 168 42,186 09-16-2013, 04:20 PM
Last Post: DaveB
  Pandora Radio using Sproxy. pasha 59 18,125 09-07-2013, 09:38 AM
Last Post: batwater
  Lutron IP Driver pseigler 15 9,181 08-19-2007, 10:21 AM
Last Post: Dean Roddey
  XM Radio & Pandora 0 324 Less than 1 minute ago
Last Post:
  HD Radio 0 312 Less than 1 minute ago
Last Post:

Forum Jump:

Users browsing this thread: 2 Guest(s)