Initial Support for RA3

[johninaustin]

These changes add initial support for RA3 processors.

RA3 pairing requires the device SSL certificate chain. The command-line pairing tool has been updated to include the full chain.

The existing Caseta Bridge implementation was generally left unchanged.

RA3 returns an empty body upon /device query. This is used as a flag to stop processing Caseta queries, and instead attempt RA3 (and possibly QSX) interrogation.

At this time there is no identified API to match Devices with Zones. Zones are masquerading as devices.

To support device type queries, the Zone's DeviceType was included in LEAP_DEVICE_TYPES so devices can be properly identified.

This does not yet support scenes, occupancy sensors, or LEDs. Those should all be included at a later date.

[danaues]

OK so I looked a bit closer, and this is just mapping device types to identify the button IDs to use, and SunnataKeypad just isn't defined in the list at all.

I'll take a stab at figuring that out and submit a patch for it.

@daytonturner, we could let the SunnataKeypad masquerade as a Pico device type to keep compatibility with the existing HA integration. Then we only have to modify the code in this project. Which keypad do you have?

[daytonturner]

Mine are all RRST-W4B-WH

My only concern in treating them like Picos is that the Sunnata Keypads have status LEDs that turn on/off and Pico's don't. Maybe it doesn't matter initially, but it would certainly be great for HA to know the state of those lights (turning the lights on in the scene that button controls separately will turn the LED on/off)

[bdraco]

@daytonturner, we could let the SunnataKeypad masquerade as a Pico device type to keep compatibility with the existing HA integration.

Please don't do that. We can change the HA integration to support the new device type.

Adding the mappings here should allow it to work as expected: https://github.com/home-assistant/core/blob/52808562ab236ada838b94e4f17cad420ffc55aa/homeassistant/components/lutron_caseta/device_trigger.py#L283

[daytonturner]

Was just coming back to this to try and clean it up now that 2022.6 is out, and was going to take a stab at occupancy sensors. As it usually seems to happen, I spend a day or two hacking away at it, and right as I'm about to post here, someone mentions they've just finished the same work :)

Is anyone already working on getting occupancy sensors or scene keypads implemented?

[MouseRatt]

@daytonturner having the same issue of physical sunnata keypad button presses crashing the integration. Have you figured out any workaround (even if a temporary fix) trying to avoid reloading the integration multiple times per day

[danaues]

@daytonturner , I haven't done any work on the occupancy sensors yet. I just ordered some 3 and 4 button keypads, and an occupancy sensor. So I can work with you on it once they arrive. Hopefully this week.

[danaues]

@daytonturner, we could let the SunnataKeypad masquerade as a Pico device type to keep compatibility with the existing HA integration.

Please don't do that. We can change the HA integration to support the new device type.

Adding the mappings here should allow it to work as expected: https://github.com/home-assistant/core/blob/52808562ab236ada838b94e4f17cad420ffc55aa/homeassistant/components/lutron_caseta/device_trigger.py#L283

@bdraco , understood. I'll have a look at adding the mappings as you suggested. Thx

[danaues]

@bdraco, Thanks for the suggestion.

I've got it working and tested by modifying the the files you indicated.
Support has been added for SunnataKeypad_2Button SunnataKeypad_3ButtonRaiseLower SunnataKeypad_4Button

How do I get these changes submitted to you for inclusion? Contributing to the main ha github source seems a bit out of my league.

[bdraco]

How do I get these changes submitted to you for inclusion? Contributing to the main ha github source seems a bit out of my league.

Open a PR and we can work though it. Don't worry if the first iteration is a bit messy, we can get it to where it needs to be.

[danaues]

@bdraco , ok I'll give it a shot. Have to figure out how to make a commit to my ha core. realizing I didn't create a new branch, so might have to re-do that. Stay tuned. Thx

[danaues]

@daytonturner I've just got some initial occupancy sensing working, check out this branch: https://github.com/danaues/pylutron-caseta/tree/ra3-occupancy

The gotcha so far is that all area's show up as occupancy sensors, but only areas that actually have a sensor will ever change state.

I've been able to create a subscription to /area/status, which triggers whenever there is an occupancy status change in one of the areas. So far I haven't found a way to check to see if there is an actual sensor in the area. My only idea so far is to query /device?where=IsThisDevice:false, and find any occupancy sensors by using a list of sensor ModelNumbers, and only import the associated areas into the occupancy entity listing.

Let me know if you are able to test.

[mrmichaeladavis]

I just deployed a RA3 All in One, with a variety of components (Serena Shades, RA3 lighting, etc) and am offering to test etc to help support this work.

[dcode]

The gotcha so far is that all area's show up as occupancy sensors, but only areas that actually have a sensor will ever change state.

@danaues the reason is that in RA3, you can now set timeouts for an area. If you activate a control in that area and you have, say a 15 minute timeout, then the vacancy actions will happen after the 15 minutes. I currently use this to turn off an exhaust fan in the bathroom after 15 minutes. In that case, the area state changes.

[bmkeller]

Is it possible to get subscriber events when a RA3 light dimmer value changes? I seem to be getting the keypad button presses ok, but I don't see anything from the dimmers. Our use cases is having the dimmers also sync some hue lights.

I'm technical so if anyone has pointers I can help implement. Or happy to do an Amazon wish list if someone else has/will implement this

[mdonoughe]

Is it possible to get subscriber events when a RA3 light dimmer value changes? I seem to be getting the keypad button presses ok, but I don't see anything from the dimmers. Our use cases is having the dimmers also sync some hue lights.

I'm technical so if anyone has pointers I can help implement. Or happy to do an Amazon wish list if someone else has/will implement this

I doubt you can get button press events for the dimmers or switches. However, as with Caseta, if you use add_subscriber you should be notified whenever the reported light level changes.

[chrisdrackett]

is there a current state of this issue or anything someone can do to help move it forward, more than happy to lend a hand!

[cbw]

@chrisdrackett work is in progress – @danaues has a fork with RA3 support (https://github.com/danaues/pylutron-caseta/tree/ra3) that I believe he's working on getting merged. I have a fork of his that adds HomeWorks QSX support (https://github.com/cbw/pylutron-caseta) that I'll merge after his.

[daytonturner]

@danaues I'm trying your ra3 occupancy tree and ran into one issue - I had my own workaround in place for not having the SunnataKeypad mappings defined yet, and although you have done it in pylutron-caseta now, the mappings in custom_components/lutron-caseta/device_trigger.py dont exist. I took a look at your github but you don't appear to have a fork of that repo available.

Would you mind sharing the changes you made to the custom component as well, so I can test that out?

Thanks!

[mdonoughe]

Superseded by #101 .