Splitting Configuration.yaml

Hello,
I am trying to place some of my code in another yaml file and use the !include command, but, for whatever reason, even after all the guides and youtube videos I watched (even DrZz’s and frenck video), I still get an error each time…

I want to take this part and place it in another yaml file

My knowledge in coding is superficial

Please help

In your configuration.yaml-
template: !include templates.yaml

In your templates.yaml, the content must contain a list. Do not add template: again inside templates.yaml file.

- sensor:
    - name: xyz
      state: >-

    - name: xyz
      state: >-

- binary_sensor:
    - name:
      state: >-

    - name:
      state: >-

You just need one sensor: header inside your templates.yaml file. See the example above.

Thank you for the quick reply, I will try that.

1 more clarification, i"m trying to build a seperate yaml file for my sensibo’s sensors.
Just trying to understand how it should be:

Template:
Sensibo_sensor: !include sensibo_sensors.yaml

I keep get an error about not configured components…

here is mine

automation: !include automations.yaml
automation old: !include_dir_merge_list automations
sensor: !include_dir_merge_list sensor
#calendar: !include calendar.yaml
#cloud: !include Alexa.yaml
script: !include scripts.yaml
switch: !include switches.yaml
light: !include light.yaml
climate: !include climate.yaml
input_select: !include input_select.yaml
input_number: !include input_number.yaml
input_text: !include input_text.yaml
input_boolean: !include input_boolean.yaml
timer: !include timer.yaml
counter: !include counter.yaml
fan: !include fan.yaml
cover: !include covers.yaml
binary_sensor: !include binarysensor.yaml
notify: !include notify.yaml
media_player: !include media_player.yaml
input_datetime: !include input_datetime.yaml
utility_meter: !include utility_meter.yaml
alert: !include alert.yaml
# var: !include var.yaml
# scene: !include scene.yaml

and having

!include_dir_merge_list sensor

will load all yaml file in a folder

image

1 Like

What do your sensibo sensors look like? I don’t believe you can just create a new type and include it, if they’re created as sensor.[name] they would be pulled in as sensor: !include sensor.yaml, or climate.[name] then climate: include climate.yaml.

If you look at the doc’s that may help:

!include filename.yaml is the statement that tells Home Assistant to insert the contents of filename.yaml at that point. This is how we are going to break a monolithic and hard to read file (when it gets big) into more manageable chunks.

As per @ardysusilo if you’re using template then in configuration.yaml you’ll have:

template: !include [filename].yaml (would be sensible to name it template.yaml!)

Then within template.yaml

  - sensor:
    - name: blurb
      state: blurb

    - name: blurb
      state: blurb ....etc as per ardysusilo

The include is simply inserting the named file back into the main configuration.yaml at that point (e.g. template: then the file contents)

You may be looking for packages which does allow you to bundle different stuff together, but I’d advise getting your head around includes before attempting packages:

1 Like

Thank you all very much, I had a misunderstanding with what splitting the configuration.yaml means :slight_smile:

for the next beginners:

sensor:

  • sensor:
    • name: blurb
      state: blurb

turn into this:
sensor: !include file.yaml

file.yaml contain:

  • sensor:
    • name: blurb
      state: blurb

Please format you stuff

file does contain the sensor data but it does not have the heading sensor

in conf file has

sensor: !include sensor.yaml

then in that file you would have your sensor

#=======================================================================
#
#=======================================================================
- platform: mqtt
  name: "Lounge DIM"
  state_topic: "stat/Lounge/RESULT"
  value_template: "{{value_json['Dimmer'] }}"
#=======================================================================
#
#=======================================================================

- platform: mqtt
  name: "Room dim by"
  state_topic: "hasp/plate01/state/p[4].b[7].val"

#=======================================================================
#
#=======================================================================
1 Like

I only discovered this ‘packages’ recently and it fixes almost all of my challenges where I have quite a few “integrations” that are split over multiple sensors. Managing them in files by their type (binary/sensor/command_line) is making it a mess wrt to overview, a recent change supportig that is the move of command_line to the configuration.yaml (or a command_line yaml)
Is there anything against using yaml with combined types?

EDIT:
I have flight related info, requiring command_line, rest, sensor and binary sensor
I have energy related, which reuqires template, sensor, utility meter

If you’re talking about packages then no. You can combine these (including the command_line you mentioned). You just need the namespace in the package yaml file. One of my package files looks like this (truncated) and has template binary sensors, sensors and command line sensors in it:

# Required to support the Home Assistant dashboard page and reporting/automation

template:

  - binary_sensor:
    - name: Monitor Home Assistant  
      device_class: problem
      state: ...
    - name: Monitor Updates
      device_class: update
      state: ...

sensor:

  - platform: systemmonitor   
    scan_interval: 120             
    resources:
      - type: processor_use
      - type: memory_use_percent

command_line:

  - sensor:
      name: Processor Temperature
      command: …

Top, thanks… it will be a bit of work but I can already smell the benfits :slight_smile:

Hey all,
after all these mixed answers I want to add my opinion. Everyone should work with packages from the outset.

The concept provides higher flexibility and invites users to organize things in a way that makes sense. Most of the issues users have with a combined configuration.yaml are immediately solved by it. The approach shown by @myle is an anti-pattern and will not help to better structure and maintain a complex configuration (no offense!).

See here for more details: