Homeworks QSX gives 204 No Content errors once logged in

[cyphers]

I realize this is somewhat out of scope. But it gets so far that one would think it is may be trivial to complete the picture. Using this tool with Lutron Homeworks QSX gets all the way past auth and past login, but then requests for data like /device and /area all fail with 204 No Content. It feels like this is one tweak away from QSX support, but not sure what it would be. Am I doing something wrong or presumably this is expected?

[swails]

The difference between this project and the pylutron project really comes down to the protocol being used (not the systems per se). This library uses LEAP (Lutron Extensible Application Protocol) while the latter uses LIP (Lutron Integration Protocol). LEAP is much newer than LIP and is better-suited for modern applications (it is RESTful, permits exploration, secured/securable, and is trivially extensible in a backwards-compatible manner).

As such, LEAP is the protocol that will be used moving forward as LIP is (very gradually) phased out. QSX is the next-generation HWQS built upon the LEAP protocol. From a 3rd-party integration perspective, newer Lutron systems will behave more like Caseta than like RA2/HWQS of the past decade or so.

That said, the QSX REST structure is likely to be different than Caseta in order to accommodate more complex systems. Until the LEAP spec is opened and published for 3rd-party integrations like the LIP integration is, the only way to figure out the precise REST requests that need to be sent is to watch what the app does.

[cyphers]

The issue is that this library implements LEAP but there is some remaining aspect of LEAP in the context of QSX that does not work. It might be certificate related, but it is not obvious because the entire process of cert gen, auth, etc has no errors and looks like it's working great until you finally go to retrieve /devices. The procedure for watching the app is unclear as the connection goes over SSL.

[swails]

That's what I meant by

the QSX REST structure is likely to be different than Caseta in order to accommodate more complex systems.

It may be that /devices only returns those devices unaffiliated with an area (none of them) and that you need to fetch from /area/<area_id>/devices. Honestly I'm not sure as I've never interacted with the "new" system (HWQSX).

The app will have the "correct" communication pattern.

What happens when you try to retrieve /area? Do you still get a 204? (which is a successful error code, but means "No Content") Maybe /project?

LEAP is RESTful, so you can do some basic exploration as you would any other HTTP-based REST API.

[swamplynx]

@cyphers any further progress with QSX. I’m looking to upgrade to RA3, and guessing I’ll encounter the same challenges.

[cyphers]

I eventually discovered there are numerous additional URLs on QSX. The authentication is identical. But on QSX, after calling /area, you then would need to call /area/xxx/associatedzone. Another URL new to QSX seems to be /area/xxx/associatedcontrolstation. I don't have a complete list, but those are the most important. The most fundamental difference is there seems to be no call to get all zone status. You need to query each area you're interested in and then watch for updates. It's a much more manual system that obviously needs a lot of documentation, but perhaps someone could take this information and upgrade this library with it. OTOH Maybe RA3 will be more similar to the Caséta API. We really have no idea.

[mdonoughe]

I worry that if this library is to cover both, due to differences in the devices, the implementation here could become complicated and the API could become confusing to use. It sounds like the LeapProtocol code from pylutron_caseta works correctly with QSX, but it's unlikely that the SmartBridge code which sits on top and turns the raw LEAP API calls into a more easily consumable Python API can be trivially made to work with QSX.

[daytonturner]

Not to thread hijack here, but I'm also exploring adding RA3 support to pylutron - but this means adding LEAP support in the first place. Perhaps an opportunity to merge the two is in front of us here, and could be used to extend to a single project that supports LEAP and LIP for Caseta Pro, RA2, RA3, and QSX?

[johninaustin]

I have the RA3 controller. It behaves more like QSX in that several of the bulk operations return No Content. I suppose with higher device counts, Lutron decided to disable these and opt for discovery / granular interrogation. I don't have my system up & running - I'm waiting on parts & on the house they'll go into. But I have been performing some tests on virtual devices. I can get the device tree easily enough, and even found a way to get the Pico button IDs, so I expect we can get everything working with RA3. When querying the areas, it provides associated zones directly in the response - but you can also query them using cyphers' URLs above.

We can update the library to fall back to the more manual queries if the bulk queries fail (I.e., /device and /button and /buttongroup don't work, we just extract all that data by querying each area & building up the device list).

Alternately, I'd guess even Caseta responds to the manual queries just as well, so it's possible we could also have a single implementation & not use the /device, /button, etc. It would be harder to test, since I don't have access to many of the devices (like certain shades or sensors) in Caseta.

I need to spend a bit more time testing how Caseta behaves compared to RA, but will be working on writing up some code for RA3. Unfortunately I don't have any access to QSX, but I do expect it to behave like RA3.

[johninaustin]

I'm assuming QSX behaves as RA3... if that assumption isn't okay, we can start a new thread.

I've played a little with RA3 & Caseta.

The two are pretty different.

• The bulk operations are missing from RA3 - you have to interrogate everything
• Caseta auto-subscribes to single zone status updates upon login
• RA3 has a way to subscribe to MultiZone status updates, but not single zone (that I've found) - so one message can contain multiple zones (such as setting a scene with 3 light zones. it's worth noting you can subscribe Caseta to MultiZone as well, but then you'll get multiple updates if you turn on a light - the single zone update & the multi-zone update)
• Caseta switch/dimmer devices have a Local Zone - you can think of controllable things as a device, and this project revolves around this concept
• RA3 has Areas (a room) - each Area has a list of zones (pendant lighting/recessed lighting/ceiling fan/shade/etc) & a list of devices (switches/dimmers/keypads/etc). But there is no API to correlate devices and zones (that I've found). However, Zones are really what you care about - you perform your operations on these. So the whole model should probably revolve around the Zone and not the Device (or we shoehorn zones into the device model)
• I'm able to subscribe to keypad & pico events w/ no issue
• There is no /virtualbutton that i've found in RA3 - Scenes work differently - even in the Lutron app. It seems to be related to keypads/picos, but even then the details are sparse so far
• I've found Occupancy sensors in the device tree, but they show as "Unknown" type - I haven't yet found a way to subscribe to events or query status from these
• RA3 requires the full certificate chain in the caseta-bridge.pem file, not just the returned certificate (I extracted this chain using openssl)

Given all this, I'm not sure how to proceed... Do we want to add a new ra3/qsx processor file to run alongside the smartbridge.py? Do we want to augment smartbridge.py & attempt to make it work with everything? Or have a generic interface that figures out the correct lower level implementation? Or do we want to create a whole new project (with lots of duplicated code) that's solely for RA3/QSX?

[johninaustin]

I have a version of this working for RA3 now. I ended up using the current object model & keeping the code as is almost entirely. Only population of objects differs.

If /devices fails to load due to No Content, it can just skip Caseta object population & use RA3 population (and presumably/hopefully QSX) using the same areas, devices, and buttons objects.

Since IDs don't overlap in RA3, I treat zones as devices, using the zone_id in place of the device_id in the devices object. I also put any devices with buttons in the devices object. I didn't bother putting in other devices (the actual switches, dimmers, etc) since they don't do anything and I have no way to match the device to the zone.

So far I have light/switch/fan/cover/sensor all working, including pico buttons, tabletop keypads, and sunnata keypads, and query by domain.

I haven't started working on scenes or occupancy sensors. Occupancy sensors are harder to work with since I don't have any of that equipment yet.

The pairing code needs updating too, to add the certificate chain. And test cases still need to be written... but it's progress.

[swamplynx]

@johninaustin you are a legend. I took a LEAP of faith (garbage pun intended) going with RA3 for a new build and up until this post was terrified I wasn’t going to be able to get it integrated with Home Assistant any time soon. Thank you, thank you for your efforts. Oh, and when you are done saving the world if you could all give a go at being able to control keypad status LEDs through this integration it would be much appreciated.

[dcode]

I upgraded my RA2 install to RA3 today and started poking at the TLS handshake. I've got a good variety of devices that I can explore the data for: VCRX, RF modules, and a few occupancy sensors (and the normal variety of dimmers and switches). @johninaustin, do you have a branch that you're working out of? I'd be happy to contribute (I'm about an hour out of Austin, too :). I was able to get through the TLS handshake by adding the PEM certchain taken from 8081 to the validation step. Unfortunately, ran out of time tonight to go any further.

[johninaustin]

Hey @dcode - there's a PR #90 on this project w/ the changes. I've been working off a fork here

[cbw]

I've been digging into LEAP on QSX this weekend, and here's what I've found so far for discovery of areas/zones/controls:

• you first make a call to /area/rootarea to discover the root of the area tree, lets say it returns an area with ID X
• from there, call /area/X/childarea/summary to discover X's children
• for each of those child areas that have IsLeaf set to false, repeat that process to recursively discover the tree out to the leaves
• now that you have a tree of all areas, for each area Y, call /area/Y/associatedzone to get a list of zones in each area
• to get controls, again go through all areas, calling /area/Y/associatedcontrolstation for keypads in each area
• for each of those keypad devices Z, call /device/Z/buttongroup/expanded to get the button config and engraving

I haven't started working on how shades are discovered yet. Has anyone figured out how that's done on RA3?

[cbw]

106 was just submitted for review to add HomeWorks QSX support! This covers most the use cases I can think of, and much of it will work out of the box with the current version of HomeAssistant. Buttons need a bit of love on the HA side because they don't have serial numbers, will work on that next.

[thenewwazoo]

Congrats! I’m still unlikely to add this support myself and am not really sure it would belong in a plug-in named “-caseta-“, but would probably not turn it down if offered (hint, hint 😉)

[cbw]

Yeah, the name of this module as well as the lutron_caseta integration in HomeAssistant could probably use a revisit :)

[cbw]

@cyphers QSX support has been merged!