Premise [download] RadioRA2 Driver

Motorola Premise


File Name: RadioRA2 Driver
File Submitter: JimSpr
File Submitted: 26 Jan 2019
File Category: Premise
Author: Jim Springfield
Contact: [email protected]

I started working on this a while back, but I recently moved into a new house and put RadioRA2 stuff in it, so I was able to do some more testing and fleshed it out a bit.
  • Unzip spradiora2.dll to C:\Program Files (x86)\premise\sys\bin\Devices.
  • Restart the premise service and connect SYS to it. The RadioRA2 driver should show up in addins.
  • Add a "MainRepeater" under RadioRA2.
  • Add a "TelnetPort" under RadioRA2 if you want to connect to the repeater over the network, rather than a serial port.
  • Figure out the IP address of the repeater and enter it into the telnet port.
  • Enter the login and password information. You can configure multiple logins with the RadioRA2 software, but there may be a default of "lutron" as the login and "integration" for the password.
  • On the repeater object, select the network property and select the telnet object you created (or use a serial port if that is how you connect). It should connect.
  • Add switches, dimmers, and keypads. Specify the DeviceID for each. You should be able to get this from the integration report in the RA2 software.
  • For Radio Powr Savr devices, make sure to specify the RoomID. This is what is sent in the ~GROUP messages.
  • The VCRX (Visor Control Receiver) only exposes the "keypad" part of the device at this point.

Click here to download this file
the ONE thing that tempts me to try automation software is if it's got a Ra2 driver.  The one thing that drives me away from many is the lack of importing devices in bulk.

It's possible to pull an XML file with everything from the repeater.  The url is:  http://ip.of.main.repeater/DbXmlInfo.xml

It's, of course, totally undocumented by Lutron, and is rather convoluted.  I keep meaning to refresh my XSL skills to process this but never seem to get around to it.
Thanks, Jim!!!
Works beautifully!! Easy to install. Everything up and working...
Do you have thoughts on adding support for other RA2 devices? (Fans, Occupancy Sensors?)
chucklyons said:
Do you have thoughts on adding support for other RA2 devices? (Fans, Occupancy Sensors?)
I find it's nice to have use of the Timeclock events and LED states too.  In Homeseer 3 you can use those.  Both to detect if something on the repeater has changed an LED state (some keypad scenes are 'interesting' about this) as well as toggling occupancy/vacancy on/off state for sensors.  I have one that's disabled from an hour after sunrise until an hour before sunset.  I can re-enable it during the day if light level drops too far.  This provides a smoother and somewhat "more intelligent" experience than what the already smart motion sensors provide alone.

I do wish the native setup for the sensors allowed for triggering a scene instead of being sensor-specific.  It'd be fantastic if there was a timeclock-controllable (or 3rd party) way to change what scenes a sensor triggered.

Likewise changing from Normal, Away and Alternate timeclock modes is handy (and not just Home or Away).
I have the protocol info for everything so I should be able to add other devices. I don't have any of those to test with, but most of this stuff is pretty straightforward.
BTW - LED states on buttons should be reflected in the "Status" property, which is part of the "ButtonStatus" group.
Also, the "ButtonState" property updates according to press/release messages, but it appears some buttons don't result in release messages. I'm not sure why that is.
I didn't know about the XML file, but I like the idea of populating stuff from the device. I may take a look at doing that.
I'll apologize ahead of time for the headaches reading that XML will likely cause.
You can add whatever devices you like into a Ra2 repeater, even ones you don't own.  The repeater will include them as part of the integration and will let you read/set them. You can't get actions triggered by them, of course unless you use one of the Lutron apps.  I think triggering with the app will cause the Repeater to emit the same status commands you'd get if they'd been operated in real life.  I haven't tried that too often, so I may be incorrect.

You can add any of them, wall boxes, keypads, pico remotes, fan controls, VCRX garage door modules, appliance modules, etc.  That way you can at least see how they show up in the XML.  
And if you want a real world XML export I'd be glad to send you mine if it'd help test anything.
Chuck, I'm trying to understand the occupancy sensors. It seems like they can operate individually as well as be part of a group. Is this correct? Do they generate a ~DEVICE message when they are triggered? Or do they only generate a ~GROUP message? Some examples captured from port spy would be helpful.

Edit: I just ordered two of the occupancy sensors and should have them next week some time.
Mine appear to send individual DEVICE responses when triggered.  There's an occupancy and a vacancy scene set for each.  Occupancy can turn on entirely different devices than vacancy.  As in, turn on just the ceiling when occupancy is detected, but turn off that and several other lights when vacancy occurs.  Handy to 'clean up' any other lights that might have been manually operated independently of what the sensor activated.

Pressing the test button on one resulted in:

These ~DEVICE messages look like they are reporting LED states on a keypad (i.e. LEDs on buttons 1 and 2 are going off and button 6 is going on)
The integration ID of the sensor in mine is 227, and that's not appearing in the log view.  This may be due to whatever MONITORING mode is set (I didn't check). 
127 is ceiling cans
201 is a desk lamp
229-234 are the dimming assignments (several lights are set to 0% during vacancy)
158 is a keypad button for the office 'All off' scene

I'm guessing the 158 command is the main repeater noticing that the 127 and 201 lights are now off and that the 158 "All Off" single/multi-room scene has reached a "completed" state.  That is, "All Off" is a scene (of my own naming) with several other devices.  The room has 2 desk lamps, 2 overhead spots and a set of recessed cans, when they all reach the state configured for that button, the LED lights up.  If any one of them isn't in that state then the LED is off. The log of events came from me pressing the Test button on the motion sensor while it was in occupied mode. 127 and 201 were the only two lights lit, so those are the only two that got changed. Once they changed, the 'All Off' scene was complete.

office keypad all off scene.JPG

LED buttons on keypads are a complex animal.  They change their behavior depending on what kind of scene is attached to them.  I barely understand it myself.
No idea on the occupancy sensors - I was going to pick up a couple to put into the rental to make sure guests aren't leaving the a/c on when they aren't there. So I guess I'll pick them up now and see what they do...or don't do...
They're pretty slick and work quite reliably. The ones I've got in the house have been in regularly used rooms for 5 years now and have needed no battery changes. Including two under outside porches (protected from the elements, but not temp/humidity swings).
What I like most about them is vacancy and occupancy do not have to control the same devices. You can have occupancy turn on one set of lighting, but vacancy can control those and more. I use in in areas where someone might turn on additional lights. Vacancy being detected then 'cleans up' after them.
Also know there are rollbacks for zones. Where there's a turn-off timer that starts counting down when the last device in the zone is used. Which is a handy way to likewise 'clean up' an area without adding a sensor.

The DbXmlInfo.xml file reflects the presence of rollbacks in OccupancyGroup nodes.  But I've never looked to see how the protocol reflects their activity. 
From what I recall you can't have both a motion sensor and a rollback on the same zone. 

You can, however, get clever like have a motion sensor in one zone turn on a device in another and have a rollback separately on that device's zone.  I forget the scenario that helps, but it was pretty clever.  Oh yeah, I think it was to allow the vacancy for an area to turn on another light, which then had a rollback.  As in, nobody detected in the room (so turn everything off) but turn on an exit light.  That exit light (like a stairway or something) could be configured with a short rollback.  So you'd essentially be using the detection for one room to trigger something else... which in turn cleaned up after itself via timer.  Not quite conditional logic, but a clever way to cascade things.
123 said:
123, on 27 Jan 2019 - 00:20, said:
I don't know if this is of any help but Home Assistant's support for RadioRA2 is based on the pylutron library found here:

The source code is available and I see it has a load_xml_db method so it might shed some light on how to import the data.
On one hand, thanks! That's useful code. On the other hand, dang it, have to slog through someone else's python to see what might work for me...
OK, so here is what I found. When the occupancy sensor activates or deactivates I see a GROUP message. First parameter is the room ID, then "3", which is "occupancy group state", and then "3" or "4", which is occupied and unoccupied respectively.
It appears I have the monitoring for occupancy turned on, but I never see individual occupancy sensors, just the group (room) they are in. Also, pressing the test button on the sensor will trigger the action (which you see), but it won't actually generate the "group" command. Only actual tripping of the sensor will make the group messages appear.
I'm thinking I will create an occupancy sensor device that has its integration ID and the ID of the group (room) it is in. The integration ID won't actually be used for anything.