Lutron RadioRa2 Entity Prefix Gone

[BWilky]

The problem

The core Ra2 integration used to include the zone in the entity naming ie: light.exterior_potlights

I've reinitialized my system since adding more devices and it's since changed to light.potlights etc. This makes things confusing if you have a setup with hundreds of lights.

What version of Home Assistant Core has the issue?

core-2024.2.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Lutron

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[mib1185]

• #110038

[wilburCforce]

I looked into this issue and I don't see a way to restore the old naming context. As of 2024.2 we create devices for each entity. The device has the name of the actual end Lutron device and then stores the area in a separate attribute. The setup will attempt to auto sort those for you too. The entity name follows the device name and the general guidance is the integration should not set an entity name but instead inherit the name from the device.

I mocked up the code for restoring the naming and it results in both names being combined. This has to do with how the friendly name was architected I believe. So in your specific case instead of light.exterior_potlights you end up with light.potlights_exterior_potlights because it takes the device name and appends the name specified in the entity.

I know it is a pain, but you can rename the entity. I think this is just the way HA is designed to work now with the device architecture.

[home-assistant[bot]]

Hey there @cdheiser, mind taking a look at this issue as it has been labeled with an integration (lutron) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of lutron can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign lutron Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

lutron documentation lutron source _{^{(message by IssueLinks)}}

[wilburCforce]

Changing the device name does return the entity naming to the previous state. The question is, do we want to do that for ALL devices or just some? For example, outputs (lights, shades, etc) this adds a lot of context and value to. But a keypad is likely already named distinctly and previously had no HA presence so I think area name probably doesn't make sense.

A scene (keypad button) might need this depending on your setup or maybe it is pretty distinct.

Occupancy Groups aka binary sensors are also tricky. pylutron already names these as occ_[area]_occupancy so you end up with entries like: binary_sensor.kitchen_occ_kitchen_occupancy currently.

Please share your thoughts on various entities, especially ones outside the basic ones.

[joshuamckay]

Maybe related, the full_id I have a lot of code automations based on expects keypads to have "_keypad_" and that has gone missing entirely.

[RyanGWU82]

I'm having the same issue as Josh: My events went from having full_id master_bedroom_fan_remote_on to just master_bedroom_on. This is affecting my RadioRA 2 events, including events triggered by Pico remotes and SeeTouch keypads.

This is a problem for my setup because in the bedroom I have a wall keypad with a button labeled "All Off", and a tabletop keypad with a different "All Off" button. The two should have different behavior and different automations. But now both trigger an event called master_bedroom_all_off, and ~~there's no way to differentiate between them~~.

Update: I figured out that I can disambiguate the two kinds of master_bedroom_all_off events by using the uuid field, which includes a different unique identifier for each button. Still, it would be nice if the keypad name was still included in the event ID.

[AlexandreUSA]

Similar case for me... all my automation looking for full_id are broken. I did not recall reading anything in the breaking changes. Thanks for the suggestion on using the UUID. I will try this out.

[andyf101]

It is also a problem if in a single room you have multiple pico controls that cannot be labeled for engraving (2-button picos for example). You end up with names such as "office_on" and "office_off" with no way to distinguish which pico. Previously the pico name was included, so "office_fan_on" was different than "office_shades_on", now both are just "office_on" as "on" is the default button name and cannot be changed since the 2-button remote cannot be engraved.