Add support for integrations to define and place devices in areas

[cdheiser]

Context

Systems like Lutron RadioRA2 and Homeworks have the concept of areas and assigning those devices to areas. It is incredibly tedious to copy/duplicate all that configuration in Home Assistant and then to keep it up to date if you're someone who's building out and modifying your system over time.

Proposal

https://github.com/home-assistant/core/pull/38945

• Make it easier to find and create areas in the area_registry
• Allow device_info to assert which area it belongs in.

Consequences

Integrations can add support to automatically import the areas and device assignments from their systems into Home Assistant.

[balloob]

I think that we should add a suggested_area to the device_info property. That way when we set up an integration, we can help the user place them.

It would also be useful for systems like Philips Hue where groups = areas.

[michaelarnauts]

I think that we should add a suggested_area to the device_info property. That way when we set up an integration, we can help the user place them.

It would also be useful for systems like Philips Hue where groups = areas.

Just for completion, there are also Hue groups dat aren't an area, but a group of lights (like 3 LEDs on the ceiling that are controlled as one).

[eavanvalkenburg]

Building on top of this, we could make it dynamic as well, rather than a one-time import, which would be a good first thing. But what if a component that get's moved around in it's app auto updates the area and then when calling a service on that area it auto applies to that as well.

In other words, moving a lamp from one room to another through the Hue app, the integration updates that lamps area in HA, an automation calling light.turn_off on the 'new' area also turns off that lamp, would make things extremely powerful. Devices that can detect where in the house they are would be even more powerful!

[balloob]

We should not complicate it by trying to support devices moving suggested areas. It's not a common occurrence.

[chrisaljoudi]

I think that we should add a suggested_area to the device_info property. That way when we set up an integration, we can help the user place them.

👍 this also has the advantage of an analogous metaphor to name/name_by_user (the user-interaction semantic where 'clearing' the name override restores the 'default name' seems like it would translate well to areas).

That said, though, given home-assistant/core#43804, it seems like clarifying exactly where "area matching" (based on name, presumably) happens in the flow is probably important.

Given that, it humbly seems to me that:

• The Area Registry should provide a helper that enables (potentially fuzzy) searching/matching of areas given a human-friendly name string
• Integrations should be able to provide a foreign_area_name that gets stored in device_info ('foreign' may not be the right word here—'external'?)
• foreign_area_name does not represent any true association of a device with an area—instead, it's used by other pieces to find matches in the Area Registry in relevant scenarios—the most obvious one being:
  • the create_entry flow step currently presents a UI with a list of devices with an area picker (right around here), and would be able to prepopulate/pre-select the best-matching area (if any), and otherwise offer creating a new area named foreign_area_name
  • this also makes life easier for potential future improvements to device/area management—if users already have a bunch of devices setup, then the process of organizing them into areas can surface suggestions based on foreign_area_name matches in Area Registry

All-in-all, this makes it so that there's no additional API "surface area" for creating areas, but simply an added property to device_info and a helper method for matching in Area Registry.

Sorry for the verbosity, and also apologies if any of the above is missing something/not helpful. More than happy to hear thoughts/comments/corrections.

[bdraco]

I wasn't sure if the matching should be implemented on frontend side or core via an api:

On the UI side:

We should be able to match names by stripping white space, casefolding https://www.npmjs.com/package/casefold and then reorder the area selector in the UI based on the levenshtein distance using https://www.npmjs.com/package/fast-levenshtein if its a 0 distance we can just skip the form and select the area.

Or we could implement the matching in core:

Normalizing the area name in a similar name with casefold, https://pypi.org/project/pylev/, and stripping white space.

[bdraco]

https://github.com/home-assistant/developers.home-assistant/pull/815 has the updated docs