Lutron RS485 between devices?

[wkearney99]

Hey, anyone out there hacked the protocols Lutron uses between their devices?  The 'QS link' protocol on their MUX ports?
 
I don't 'need to' use it but I've been hacking away at an interface to the RS232 ports on the repeaters.  That protocol is pretty straightforward and documented (but not entirely). 
 
Where my curiosity gets piqued is their lack of certain devices across different product lines.  Specifically their daylight sensors.  Those won't work directly with RA2.  I'd like to find a way to make use of them.
 
That and all of their RF gear really appears to be "the same" except they're whitelisting only certain devices on certain product lines.  As in, gouging more for HWQS gizmos only because it's firmware has the magic hex bytes, as opposed to exactly the same box-store-sold Maestro units for a fraction of the price.
 
So I'm futzing around with some QS link gizmos and sensors.  I'm wondering if I can cobble up enough of a working interface to get them integrated effectively with my RA2 lighting.  
 
Thus far I've run across a PDF indicating use of 31.25k as a port speed.  Hmmm, 31250 seems to actually work, there appears to be a fairly stable set of hex bytes being sent during regular activities.  As in, one repeater telling another there are actions taking place.
 
I'm thinking I could start with an RS485 interface into a QSM2 receiver.  The DCRB daylight sensors can only be paired with one of those, a Maestro dimmer or a non-RA2 variant of a Grafik Eye dimmer. That'd let me at least get the sensor data.  But I'd wonder if it might be possible to then 'fake it' directly back into a MUX port to appear as a legit RA2 device.
 
They do have an app note that suggests using a VCRX for a contact closure input from one of their GRC-LC8 controllers and a separate light sensor.  Talk about both overkill and missing the mark.  I don't want just a binary on/off from the light levels.  Especially not when I know the sensors and dimmers can do so much more.
 
With variations in seasons I'm finding it'd be convenient to automate my shades and lighting in a more nuanced fashion that just time of day.  I've got some shades next to my desk that during winter are best left closed at the bottom to add some insulating against the cold. But during warmer temps it'd be nice to leave them open.  In either case there also factors involving the amount of sun and where it's positioned.  I'd like to adjust the shades based on glare or overcast, while taking temp into account.  Likewise I have a family room that'd be convenient to shade it with similar requirements.  Can't do that in RA2 directly and I'm not about to rip-and-replace for HWQS.
 
I've not yet set up the QSM2 and DCRB, but I have all the pieces.  If I can get a handle on the MUX protocol then I can more readily interpret what the QSM2 sends.

 

[Neurorad]

Interesting project.
 
I thought the 4-wire to the repeaters was RS485.
 
I can contribute enthusiasm, but little else.

 

[wkearney99]

Oh it's RS485 signalling, that much seems clear.  And it's not 4-wire for communication, it's just a 2-wire differential.  The other two lines are ground and power.  But what baud rate and encoding is unclear.  From what I've gleaned from various Lutron documentation it's likely using the same baud rate as MIDI.  This seems plausible given the Motorola Coldfire processor being used (and reading up on what kind of crystals are involved with creating baud rates).  In looking at the various products it seems quite a lot of them might actually be using the same hardware, likely just with different firmware.  A few have additional LEDs, but the solder pads are already present inside a Main Repeater.
 
I wouldn't be poking around with this were it not for Lutron's failure to deliver across their platforms.  I'll say this, though, Lutron has a helluva lot more going on that most folks might realize. Their commercial lighting stuff is pretty interesting (EcoSystem, Hyperion, etc).  But at the same time they've completely missed the boat on a wider array of sensors.  The tech to support them is there, they've just not gone after those markets.  

 

[cobra]

Looks like you already have hardware, but a Lumina or OmniPro can talk to RA2 and QS shades, as I understand it.  And it is supposed to be able to do 0-100% shade closing (looking like a dimming setting.)  Not sure about a light sensor, I could use one of those.  It does have built in sunrise/sunset calculation for location and season built in.

 

[vc1234]

Oh it's RS485 signalling, that much seems clear.  And it's not 4-wire for communication, it's just a 2-wire differential. 

You would need an RS485 tap to capture the bus communication.  An RS232 tap plus an RS485-232 converter may be a cheaper option but less reliable.
 
I just bought an RS232 tap to figure out where a breakdown in communication between Elk and VRC0P happens.  More from sheer curiosity rather than hoping to achieve a resolution.
 
To discover the baud rate, you'd also need an oscilloscope to measure the shortest pulse width in seconds and then convert it to the baud rate by taking the inverse and rounding to the closest standard rate.  The baud rate may be non-standard, though.

 

[wkearney99]

I'm well on my way toward amassing one of damn near everything when it comes to automation gizmos.  Oy, what a pile.

Having fiddled around with a lot of gear I still come back to using Lutron lighting and motion sensors.  They "just work" and stay that way.  Especially the wireless ones using batteries.  The response time, the lack of fiddly-ness, etc, all stand out much better than other brands & technologies.  Anything can be "made to work" but then there's the challenge of keeping it working through various foolishness.  The Lutron stuff has been just set-and-forget and utterly reliable.  Anyway, I'm not arguing one brand/tech vs another in this thread.

 

[wkearney99]

I'm well on my way toward amassing one of damn near everything when it comes to automation gizmos.  Oy, what a pile.

Having fiddled around with a lot of gear I still come back to using Lutron lighting and wireless motion sensors.  They "just work" and stay that way.  Especially the wireless ones using batteries.  The response time, the lack of fiddly-ness, etc, all stand out much better than other brands & technologies.  Anything can be "made to work" but then there's the challenge of keeping it working through various foolishness.  The Lutron stuff has been just set-and-forget and utterly reliable.  Anyway, I'm not arguing one brand/tech vs another in this thread.
 
I don't currently have a oscilloscope and don't see getting one just for this task.  But it's been on my list of things, for ages.  I don't need to debug this bad enough to have the wife give me THAT look when a beast like an HP or Tek 'scope shows up...
 

 

[wkearney99]

You would need an RS485 tap to capture the bus communication.  An RS232 tap plus an RS485-232 converter may be a cheaper option but less reliable.
 
I just bought an RS232 tap to figure out where a breakdown in communication between Elk and VRC0P happens.  More from sheer curiosity rather than hoping to achieve a resolution.
 
To discover the baud rate, you'd also need an oscilloscope to measure the shortest pulse width in seconds and then convert it to the baud rate by taking the inverse and rounding to the closest standard rate.  The baud rate may be non-standard, though.

 
I made one of those tap cables a while ago for RS-232, and it's definitely handy.  Can't recall what gizmo I was debugging... could have been a Russound unit (before they released docs).
 
The good part of Lutron's MUX port is they use parallel connections between the devices. So I don't need to use an in-between tap.  I don't currently have anything else on the MUX port so I'm not seeing inter-device traffic.  It appears to squawk data even if there's nothing listening.  I may pick up an Aux Repeater just to see.
 
Meanwhile, little annoyances like discovering my COM ports being numbered above 16 presents a problem for some programs (232analyzer) so then I'm off digging through a plethora of 'left behind' configurations hidden in the Device Manager.  Culminating in requiring a reboot, ugh.

 

[vc1234]

The good part of Lutron's MUX port is they use parallel connections between the devices.

 
Actually, you are right. 
 
I used to use an an industrial RS485 tap to preserve precise timing back in the day, but you do not need an industrial quality one most likely.  Hardware to monitor RS485 in fact is cheaper than that for RS232 because you do not need to get in-between, so a cheap $15-20 485-232 converter may suffice unless you want be careful and get an opto-isolated one which woud cost you about $50-100.

 

[wkearney99]

I picked up this USB-RS485 widget:
http://www.amazon.com/gp/product/B005CPI0JQ
 
It works pretty well, but of course doesn't immediately determine what kind of baud rate and timing is being used. I searched the web and ran across some Lutron docs mentioning 31.25k, that and the ROM boot indicates it's using a Moto Coldfire setup.  A little more searching and some trial-and-error and it looks to be hex data at 31250.  Not positive though, but the data appears to be stable and somewhat repeatable.  Haven't dug in much further.

 

[vc1234]

I picked up this USB-RS485 widget:
http://www.amazon.com/gp/product/B005CPI0JQ

Just bought the same for my RadioRA2 experiments
 
They claim it's opto-isolated...

 

[wkearney99]

I don't think that one's much different than any of the others listed on Amazon, but at $30 it's not a huge gamble.  

 

[vc1234]

I don't think that one's much different than any of the others listed on Amazon, but at $30 it's not a huge gamble.  

Maybe not, but at least I know what's inside (ftdi 232 rl).
 
Re. decoding the serial stream. 
 
For various reasons, I've not been doing EE related stuff for more than two decades, although I could still figure out serial bits from the signal on the screen if I had an oscilloscope which I don't any more. Just talked to a friend of mine who is still in the business.  According to him, the easiest way to decode an unknown serial sequence today would be to use a serial decoder available in some modern DSOs. The least expensive gadget would be a USB Pico scope series 2200 (about $160) that has a serial decoder included.  However, he does not recommend a Pico, or any USB scope for that matter, for any more or less serious analog signal work and claims that an ancient Tek would still be a much better option in that regard than any USB device. The lowest cost decent benchtop DSO is a Rigol (about $300) with an optional decoder (another $200).

 

[picta]

I totally understand the thrill of reverse engineering, but if I just wanted to control/monitor some devices I would probably go the easier rout and got a QS or GrafikEye network interface (granted, those are not cheap, but what is at Lutron?) Then I would have the option to integrate with many devices by using simple ASCII protocol. But that is just lazy me

 

[wkearney99]

Indeed, the Lutron gear isn't cheap but it's definitely provided quality results.  If I go with a Grafik Eye I'm sort of jumping out of one frying pan into another.  That and I'm after some 'behind the scenes' insight as to what their devices are doing to differentiate between lines.  
 
Also consider that the RA2 variant of the Grafik Eye does not support the same range of options as the ones intended for standalone or QS integration.