Update RA3/HWQSX naming to be consistent with Caseta naming

[danaues]

This update changes the naming of RA3 devices and keypads to match the Caseta naming convention.

"_" character only appears between area and the rest of the name, so the integration can parse out the area from the names, but the names will not contain underscores, just spaces. Not implemented for Processor or Occupancy Group, as these are handled differently by the integration for now. This is consistent with Caseta.

Keypads and Picos were adding the full DeviceType to the name, where in Caseta we just add the word Pico. Now all Keypads will say just "Keypad" and Picos will say "Pico", instead of the full DeviceType (SunnataKeypad).

[danaues]

Hi @mdonoughe,

Would love to get this final change merged and released so we can bump prior to the HA October Beta. This has been nagging me that the naming doesn't match my caseta system.

Thanks,

[mdonoughe]

"_" character only appears between area and the rest of the name, so the integration can parse out the area from the names, but the names will not contain underscores, just spaces.

The integration should not be doing that. Is there no other way to get the device_name? Can you add a new property to the device object? Making the names have a consistent format is good, but we shouldn't be packing values into strings that other code needs to parse back out of those strings.

[danaues]

I agree, but this is the way it's currently being done for caseta. I just wanted to be consistent.

[danaues]

There is an initiative in HA to change the way entities are named: https://developers.home-assistant.io/blog/2022/07/10/entity_naming

Perhaps we can address the naming for the whole integration, Caseta/RA3/HWQSX in a future change that will align with this.

[danaues]

This is where the _ between area name and device name comes from in caseta

https://github.com/gurumitts/pylutron-caseta/blob/ddeba080d9f4e8d6574e9205bc685426b33bba17/pylutron_caseta/smartbridge.py#L770

[danaues]

I see 2 gaps with the device_name and area id fields.

I think we need to add support for nested areas for RA3/HWQSX.
Some of my switches show as area ID 1205 "Hallway". But this area is nested inside another area "Main Floor". I should be able to parse out the full area as "Main Floor Hallway" within the integration. Perhaps we can just add a parent_id field to the areas dictionary. Return None if it is top level.

RA3/HWQSX Button Device naming. The device_name currently returned is "Positiion 1" or "Position 2", (Which gang it is for a control station location). These names are not editable in the Lutron Designer. The control_station_name field still incorporates the "area_name" strategy.

I'm gong to switch this to a draft PR until I've sorted it out.

[danaues]

Changes:

1. added parent_device field to buttons and LEDs
2. removed area field for buttons, will use the parent device to look up the area in the integration
3. added parent_id field to areas, and imported all areas, not just IsLeaf=True areas for RA3/HWQSX
4. added area field for occupancy sensors for consistency of field names. The integration won't have to care what type of entity it's loading, it can use the same code for all types if the fields are consistent.

I can use the parent_device field within the integration to associate the buttons and LEDs with the appropriate keypad/pico. I'll be able to re-build our current naming using the new fields within the integration, not having to parse out area etc. This will also allow us to have HA entities listed inside a single HA device per keypad, instead of each entity getting it's own device, plus the keypad device.

No breaking changes, everything continues to work as-is for my Caseta and RA3 installs.

I'll work on the lutron_caseta integration for when we're ready to release these changes.

[danaues]

Thanks!

[mdonoughe]

https://pypi.org/project/pylutron-caseta/0.16.0/

[danaues]

PR to bump in HA created https://github.com/home-assistant/core/pull/79243