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.
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?
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:
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.
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.
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
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’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).
Looks like this has come a very long way. Thank you to all the talented devs.
I am looking at upgrading my RA2 controller to RA3. Any feature gaps between the Lutron integration with RA2 and the Lutron Caseta integration using a RA3 controller?
Hello, just wanted to share my recent experience with getting the QSX processor integrated. I was reading through this discussion as well as many others, and things were not looking promising. I did originally try leveraging the HomeKit integration, but only a single “identify processor” entity appeared. However, switching HomeKit connection over to an iPhone, configuring it via the Lutron app on the iPhone, and then switching it back did the trick. All of my lights and shades are now controllable, and external updates are reflected instantly. Though keypads are not available (I think I will live without that).
Here’s a summary of the steps that I took (from memory; I’m too afraid to try to reproduce them and risk breaking the integration):
Add processor as a bridge to Apple’s Home app by scanning code on processor
Open Lutron app and add every device (this was quite time consuming)
Confirmed devices worked via Home app
Removed Lutron bridge from Home app
Add processor as discovered HomeKit integration in Home Assistant by typing code on processor
The selected devices from previous HomeKit configuration on the iPhone appeared to have been persisted and now appear as entities in Home Assistant
I am a home owner using HomeWorks QSX with Palladiom keypads and the Lutron Caseta integration works well. I have noticed that scenes configured in the Lutron app are not getting populated in the Apple Home app which is a bit unfortunate. Is this a limitation of the current Lutron Caseta integration version?
Can you clarify what you’re doing/the expected behavior?
I suspect this is a limitation of what’s exposed in LEAP. Without any public documentation, it’s tough to figure out what you can learn from the processor.
My approach is to use homeowner keypads with area scenes applied to the buttons, then I do virtual button presses from Home Assistant to trigger those.