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.
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âŚ
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).
