Lutron QSX and Radio RA3

Would love to see Lutron QSX integration as well. The QSX system also uses the LEAP protocol like the Smartbridge pro and the RA2 Select hubs, but the integration does not seem to work due to differences in implementation. I would be more than willing to work with someone on testing and developing this integration as i expect the Lutron RA3 that will soon be available to use the similar methods as QSX. I have a bunch of ways of testing AND programming the lutron systems since i am a dealer. I also have the Crestron modules with all the compiled code to integrate those systems together as well. Would love to help contribute in some form or another on this, but im still so new to Home assistant that there is no way i could tackle this on my own.

Same here, quite a few customers having Lutron/QSX processors so would be great to get a working integration :wink:

3 Likes

I just pulled the trigger on an RA3 processor (not yet arrived) for a second home, but suspecting it to be very similar to QSX as well. The lack of integration with Home Assistant or any consumer automation platform has me a little nervous, but I’m hopeful the community will eventually shake this out.

I believe the HA integration is based extensively on the pylutron (for telnet integrations) and pylutron-caesta (for LEAP integrations), so that would be a good place to start. The pylutron-caseta LEAP connection evidently works with QSX, but only the connection, the actual REST API is totally different between caesta and QSX. My guess is RA3 will be more like QSX. And of course totally unhelpful that Lutron doesn’t have any public API docs…

I am also looking at purchasing a RadioRA3 processor. Hoping an integration can be figured out.

I want to believe.

Have a RA3 processor, and second this

Would upgrade to RA3 if lutron made the api specs available to the community.

3 Likes

Any update on the QSX integration ?

Best to follow this pull request at pylutron-caseta, as that library seems to be the farthest along at supporting RA3 and QSX. Once that gets merged, HA should pick up the updated library.

1 Like

I’ve been trying to get this working via the HomeKit side of things, but that’s also currently a dead end:

the pylutron PR seems to function well enough to pull data back from the RA3 processor. The stumbling block for me at the moment appears to be the lutron_caseta module in HA. Something about the difference in how the RA3 stuff behaves now makes it never finish starting up properly. I’m currently trying to figure out where its going sideways, and will hopefully be able to contribute a patch. Seems as though the pylutron_caseta PR didn’t necessarily have HA in mind, and the author wasnt testing it inside an HA environment, perhaps?

1 Like

Alright so I’ve tracked down the issue with using the new ra3 PR in pylutron with HA’s lutron_caseta here, but I guess I’m left with a couple questions that I’d love some guidance on.

High-level question: I believe its true that adding support for RA3 should go into the HA core module lutron_caseta and not lutron (as it lacks any support for LEAP) and not lutron_caseta_pro (which afaik is now deprecated as lutron_caseta has caught up to it). Looking at git commits, it seems like @bdraco and @epenet are heavy contributors. Unless I just dont know where to find it, what’s the best way to figure out who maintains these modules and coordinate the effort with them?

Now, on to the meat and potatoes of why lutron_caseta doesnt work with the RA3 functionality in pylutron yet:

  • Within init.py and config_flow.py, some presumptions are made about how Caseta responds to queries, where RA3 differs.
    ** e.g. core/config_flow.py at b049ffca23f33907561d1af4b34f4590708530b9 · home-assistant/core · GitHub
  • The code above expects to get the bridge’s own information (serial number, etc) by retrieving an entire list of devices, then looking for device id 1 (defined as BRIDGE_DEVICE_ID).
  • The RA3 processor does not return the bridge in the list of “all devices” any more, and even if you forcefully query for device id “1” it doesn’t return bridge info.
  • A community member @dcode has provided his notes about how to query RA3’s LEAP API (ra3_notes.md · GitHub) and in here we can see a special query to query the processor itself here: (ra3_notes.md · GitHub) - I note that he outlined a different way of doing this, simply querying device ID 128 - this didn’t work for me, it returned unknown device, and my bridge reports as device id ‘96’ when doing it the first way (Get information about the Connected Device).
  • Nonetheless – The way RA3 needs to be queried to return info about the processor is different (from lutron_caseta’s perspective, anyways) and even after that, the Response Payload is in a different format than just a single device, so some other changes will need to be made to accommodate this.

I’m happy to take a stab at creating a PR that allows lutron_caseta to make these queries properly, but its going to be yet another “detect the kind of bridge we’re connecting to and behave completely differently” which already exists for RA2 and Caseta.

Is this okay? Do we have a preferred way to deal with this? I’ll bulldoze my way through at first and share my findings, I just wanted to raise my findings and ask these questions before I put a bunch of time in to a proper PR.

Thanks for all your hard work everyone!

2 Likes

First open PRs to pylutron_caseta to add support for the bits that are different

Once those are merged open PRs against the Home Assistant integration to add support for the new parts. The bot will let the right people know when a PR is opened.

Thanks

1 Like

We can address how to make that work in the code review process. Ideally as much as possible is abstracted away into pylutron_caseta. The less Home Assistant knows about the protocol details the better

I was contemplating just having pylutron_caseta handle requests for device ID “1” (when it has determined we’re dealing with RA3) and adapting that request to behave like it does for caseta, such that HomeAssistant’s lutron_caseta module doesnt need much/any modification, but wasn’t sure how folks felt about that.

I would abstract it away by hiding the implementation details behind a function in pylutron_caseta that returns the bridge device.
This way home assistant doesn’t have to know or care what the id of the bridge device is.

Also we are currently missing functionality to retrieve the firmware version it would be nice to add that as well to the bridge device since sometimes users have trouble with getting the firmware updates and it’s not obvious what is wrong when some of the newer functionality doesn’t work right

2 Likes

I would expect RA3 and QSX to be nearly identical in many ways. I have a Crestron System and Control4 controller in my house that can talk to my Lutron QSX system. If me using wireshark would help move this along, we could capture the process of the Crestron and Control4 polling my QSX processor. I have shades, dimmers/hybrid keypads and occupancy sensors in my Lutron system so we should be able to see the different device types. I could make time one evening or on a weekend to help out with this. message me if you want to set up a time.

I’m another person looking to deploy RA3 if supported by HA. I can offer mother more than encouragement though.

I’ve been digging into QSX’s LEAP implementation this weekend, and have made a little bit of progress by turning on debug logging on a Control4 system that is talking to QSX.

The area/zone/keypad discovery process looks like:

  • ReadRequest against /area/rootarea which will give you the href to the root area of the system, let’s call that X
  • ReadRequest against /area/X/childarea/summary will give you all the direct children of that area. Any of those children with IsLeaf as false, call childarea/summary recursively on each of those to traverse the tree
  • once you’ve built out the area tree, for each area Y, make a ReadRequest on /area/Y/associatedzone to get all of the zones for each
  • to get keypads, iterate through the areas again, making a ReadRequest on /area/Y/associatedcontrolstation

I’ve also discovered in watching events coming back to Control4 that there are /button/X and /buttongroup/X children of the keypad devices. You can see the parent relationship from them (button > buttongroup > device) but I haven’t yet figured out how to go from a device to its children (which would be really useful to figure out the engraving on the buttons).

There is a PR open to pylutron_caseta to add support

and an older stale one

The PR to add support for the new device types to HA has already been merged