How to define AREA in "configuration.yaml"?

Configuration
1

I prefer to define zones, persons, integrations (if possible) in the configuration.yaml instead of GUI.
There is no info about declaring “areas” (like “Kitchen”, “Bathroom” etc) in the config file.
Am I missing something or is it kind of “What the heck” issue?

1 Like
2

It can only be done via the UI.

In addition, currently, there’s very little you can do with an Area (besides assign entities to it).

1 Like
3

Oh, thank you, Taras !
I am a beginner, just wanted to have everything in the config file.

1 Like
4

You should be aware that there’s a trend to move the configuration of various things (notably integrations) from configuration.yaml to the UI (where it stores the data in JSON format in hidden files with the hidden .storage directory). Given that Areas are currently defined exclusively via the UI, I suspect they may never be configurable any other way (but that’s just my guess).

5

For me the main purpose of “keeping everything in config files” is to provide:

  • a quick migration from one PC/RPi/etc to another one (because of damage/upgrade/etc or for testing);
  • a quick restoration in case of crash.

I am using HA in Docker so I do not have Supervisor with snapshots functionality.
So currently I have to backup yaml files & Lovelace cards’ declarations (copy-paste from yaml editor) periodically.

1 Like
6

In that case, some of what you configure may exist in those hidden JSON files I mentioned. For example, if you use the UI to create an input_boolean, or an input_select, or other "Helper, it will be stored as JSON data within the hidden .storage directory. Similarly, if you configure the default Lovelace UI and/or create additional Lovelace dashboards, they will be stored as JSON data in .storage. The backups you are creating should take that directory into consideration.

7

Thank you very much for advices.
What I usually do is:

  1. Copy whole HA folder with subdirs.
  2. Open every Lovelace dashboard in an internal editor (as yaml file), select-all + copy + paste into txt-files. These txt-files then can be easily used for recreating dashboards.
    May be I am doing stupid things, but I am just a beginner)).
8

Just back up the entire config directory including hidden files and you’ll have everything you need. No need to back up the Lovelace config separately.

1 Like
9

Please vote here:

1 Like
10

Really annoying that you can’t do it through the YAML. I have switch and sensor entities for specific purposes in my yaml, and if I try to edit through the GUI it won’t let me edit (so I can’t add an area)

1 Like
11

You can edit it in the gui if you add a unique_id. For template sensors, make sure you use the new template format. The old won’t allow you to set the unique_id.

1 Like
12

Thank you; this helps!

13

Hi,

I have a lot of sensors which I want to assign to an area. But they are configured through yaml without a unique_id. So I can not edit them in GUI.

So there is no chance to add these sensors to an area?

What do your mean with “new template format”?

/KNEBB

14

Hey @knebb some integrations out there create entities with no unique_id and you can’t do anything about that.

However! For most yaml-defined entities you can in fact set a unique_id. I got used to this format (for no specific reason):

template:
  - sensor:
      - name: ABC Temperature
        unique_id: uniqueid__abc_temperature
        unit_of_measurement: "°C"
        device_class: temperature
        state_class: measurement
        state: "{{ state_attr('climate.heater', 'current_temperature') | int(0) }}"
15

Yeah, I figured this out for my MQTT devices. But I prefer to configure it in .yaml because I have a load of such sensors. I can edit a single entity and assign it to an area. But not multiple ones.

In .yaml it’ll be easier. therefore.

/KNEBB

16

The first question is answered, but not the one about the new template format. The new format is when you define them under template: and the old one is defined unser sensor or binary sensor, with platform template. Those are the old way, and do not have a possibility to add a unique id. But you can rewrite the old ones in the new format.