Home Assistant YAML is a maintenance surface

Most of my Home Assistant setup lives in the interface now, which is fine. The UI is good for a lot of everyday configuration, and I do not need every lamp in the house to become a little act of file management.

But I still keep coming back to configuration.yaml and the files around it.

Not because YAML is more virtuous. It is not. YAML is whitespace with consequences.

I come back to it because some parts of a smart home need to be readable, searchable, repeatable, and easy to repair when future-me has forgotten why the hallway behaves like that after 10 pm.

These are the three Home Assistant YAML habits I would keep, even in a mostly UI-driven setup.

            configuration.yaml
          
            automation:
          
            !include automations.yaml
          
            script:
          
            !include scripts.yaml
          
            template:
          
            !include templates.yaml
          
            check, reload, repeat
          

Reload what can be reloaded

The first useful habit is learning the difference between a full restart and a reload.

Home Assistant’s current docs describe the YAML tab in Developer Tools as the place to check and reload configuration changes. The important detail is that reload support depends on the area you changed. If it appears in the YAML reload list, reload it there. If it does not, restart Home Assistant.

That sounds small, but it changes the way you work.

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template: !include templates.yaml

With that shape in place, small edits to automations, scripts, scenes, and template entities can often be tested without turning the whole house off and on again.

I still check the configuration before reloading. A fast loop is useful. A fast loop that confidently loads broken indentation is less charming.

The practical rule is simple:

• use reloads for the areas Home Assistant lists as reloadable
• restart when the docs or the interface say that is required
• keep risky changes small enough that you can tell what broke

That is not glamorous. It is just a better feedback loop.

Make template sensors say what you mean

The second habit is using template sensors for states that should have a human meaning.

Raw entities are usually too literal. A motion sensor says motion. A plug says watts. A door says open. Useful, but not always the shape you want when you are building automations around real behaviour.

A template sensor lets you turn several technical signals into one readable state.

template:
  - sensor:
      - name: "House activity"
        state: >
          {% if is_state('binary_sensor.kitchen_motion', 'on') %}
            Active
          {% elif is_state('binary_sensor.living_room_motion', 'on') %}
            Settled
          {% else %}
            Quiet
          {% endif %}

That is not artificial intelligence. It is a named opinion.

And named opinions are useful.

They give automations something clearer to depend on. Instead of scattering the same motion checks across five different places, you can define the meaning once, then use it consistently.

The Home Assistant template docs also point to a small but important safety habit: use helpers like states() and is_state() when reading entity state. They behave more predictably when something is unavailable during startup.

That matters because smart homes are not clean software demos. Devices disappear. Batteries die. Integrations start before every entity is ready. A good template should expect a little mess.

Split the files before the file becomes folklore

The third habit is boring and probably the most important one: split the configuration before it becomes a private archaeological site.

A single configuration.yaml starts out harmless. Then one integration becomes five. A quick test becomes a permanent fixture. A comment says “temporary”. The year changes. Nobody laughs.

Basic includes help:

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
template: !include templates.yaml

Packages are useful when a feature needs multiple Home Assistant domains to live together. The official package shape sits under homeassistant:.

homeassistant:
  packages: !include_dir_named packages

Then a feature can keep its helpers, sensors, automations, and other related pieces in one package file.

That is the part I like. Organisation should match how you think about the home, not just how Home Assistant happens to categorise entities.

For me, that usually means grouping by purpose:

• heating
• rubbish-day reminders
• presence
• exterior lights
• low-battery checks

When something breaks, I want to open the file that matches the problem in my head. I do not want to scroll through a giant file hoping the relevant section has a comment from 2022.

YAML is not the goal

The point is not to move everything out of the Home Assistant UI. Plenty of integrations belong in the UI now, and Home Assistant’s own developer guidance is clear that device and service integrations generally use config flows rather than new YAML configuration.

That is a good thing.

YAML is useful where it gives you structure, reviewability, and a better maintenance loop. It is less useful when it turns the house into a puzzle that only one person can solve.

The standard I trust is simple:

• can I read this later?
• can I reload or test it safely?
• can I explain why this state exists?
• can I find the related pieces when something fails?

If the answer is yes, YAML is doing its job.

Not as a badge of power-user purity. Just as a quiet maintenance surface for a system that has to keep working after the novelty has worn off.