WTH Can we not assign "area" to all entities/devices in configurationyaml?

Archive Month of "What the heck?!" 2022
1

Hello,
I know that some integrations like MQTT sensors now offer “suggested_area” but why can we not just use a configuration file to assign all devices/entities to areas without being reliant on implementation in an integration?

Area is a global assignment that can be made via UI to everything. Yet it cannot be assigned via configuration.yaml or a package.

I am happy to elaborate more but maybe something like

area:
  living_room:
    - device: shelly_1
    - device: shelly_2
    - entitiy: shelly_3_today
  dining_room:
    - 
.
.

Ideally even allowing for wildcards :wink:

Thank you
Alex

2

This is also a problem for entities that do not have a unique id. Unique id is a pleonasm anyway. If it’s not unique, it isn’t an ID. But that is another matter.

3 Likes
3

I just had this issue again today. I had to delete my MQTT entities because of changes at source (firmware) and since suggested_area is only allowed for very limited use, I had to manually re-assign each entity an area via UI.

Maybe one solution would be to add area to the MQTT options, if a global area.yaml is not possible.

4

This only would happen if your unique_id changes for the discovery topic, which you have control over with MQTT.

5

Or when, because you do not want to delete your yamls and each entity one by one, you simply delete MQTT integration and tasmota integration :slight_smile:

And upon restart, everything is loaded freshly. But the area information is lost since you cannot define it in any yaml file :frowning:

1 Like
6

Because you deleted the integration… Why would you do that? That’s what stores your configurations.

If you need to edit your yaml, just edit your yaml and reload.

7

Changes were made to topics etc. at source, aliases defined, firmware changed which causes new device names etc. etc. Firmware changes which changed the names. All kinds of playing around.
In addition, I was playing with broker etc.
I could have deleted the yamls, deleted all entities and then restarted. Then uploaded the yamls again and restarted.
But it is much faster to delete the integration and restart.

Anyhow, that is just an example. If you restore your config etc. you have the same issue.
If you add new sensors etc. you also have to enter the area manually.

Basically, everthing you do that is not in the config already forces you to manually assign areas via the UI. This is quite redundant given that you define everything else about the mqtt climate or sensor in the yaml already. So why not be able to define the area?

8

No it doesn’t force you to redo the area. You can literally change anything, as long as the unique id being sent from the mqtt discovery is the same, that information will be retained. Your preferred workflow is causing the problem. Don’t delete the integration, just change your yaml and it will just work.

9

Again, that was an example.
I quite frequently add new devices or redo my setup.
And this also includes changing the unqiue id (because I use the name for the unique id. So this messes up area.

And the one pain I have is that I have to manually define the area via UI instead of having a simple oneliner in the mqtt yaml.

So, why not make this available? Obviously if you never change anything, never add anything new, never redo your setup, you will only ever have to setup everything once. But let’s be honest, we don’t enjoy that :smiley:

So why not make it easy and simple and add one more option to mqtt? So simple. area:

1 Like
10

Don’t do that. You don’t need to care about unique_id, just make it unique. You can use this website, make it like 20 characters:

It would require you to add a unique_id so integrations that don’t have unique_id’s wouldn’t get it, and a system would need to be developed to manage a yaml area that can be overridden by the UI. It’s not a simple “just do this”.

11

I use unique id like that because my names are also always unique and it makes it easier to specify unique id if I ever need to refer to it (like in my scripts before switching to service call).

I did not quite understand why it is a problem to define the area in mqtt climate, mqtt sensor etc. That integration is part of core and you can define everything else just not area.
I did not understand what you meant and why area defined in mqtt cannot be passed to the same destination as the area defined via UI.

Could the mqtt integration not write that information (assuming you define a unique id, which I do) to the config?

Of course you can make unique_id mandatory. No problem. As long as the option is then available. Defining another option in yaml is fast and simple and one time job.

12

It cannot. The only way to use an area is if you have a config entry. The only way a config entry is created is when you have a unique_id. The only way a config entry remains static is if you do not delete the integration and you keep the exact same unique_id.

13

But mqtt allows you to enter unique id. So you can pass area to the config together with the unique id.

14

circles, going in circles

15

But the problem with unique ids potentially being used by others already exists.

So let’s limit the discussion to adding area to mqtt. So the “only” thing needed would be for mqtt to write area to config on load (boot or manual reload). If it writes to the same file as UI, then they would simply overwrite each other. Since unique id is defined, both will write to the same entry. So if a user defines in yaml and then in UI and overwrites himself->his problem.

But on an integration basis (here mqtt), only writing to config file is needed using the unique id

P.S.: I don’t mind changing thread to MQTT atea option if a global solution is too complicated.

16

No, integrations append a unique integration identifier to user added unique_id’s so that it’s truely unique on the entire system.

No. Because as soon as you add a unique_id, it creates a config entry. And if you adjust the area via the UI, every restart the area would be wiped out. Anything that is added via yaml needs to have a mechanism built to over ride it via the UI. There’s no way around this.

17

Okay, then I guess I would like to request that this process is added for area, please :slight_smile:

18

No outcome :joy: well facing same issue. Why can we not just Add manually the area like name or any other config option for an Integration… I know Its always easier but I think due to the area option in home assistant we should be able to add no matter what entity to areas …even if only manually…but better via UI of course

19

A post was split to a new topic: Assign “area” to entities in configuration.yaml

20

My strong impression that Devs wish to move everything to UI and get rid of yaml one day. And yes, I heard promises like “yaml will be never deprecated”. So, no expectations that “area” will be available to define in yaml.