Splitting config for template:

[ardysusilo (Ardy)]

Just an update-

template:
  - sensor: !include_dir_list ../entities/templates/sensors
  - binary_sensor: !include_dir_list ../entities/templates/binary_sensors
  - !include_dir_list ../entities/templates/template_trigger

The above template.yaml passes config check. However, when inside `/config/entities/templates/template_trigger/justatest.yaml, I insert-

trigger:
  - platform: time_pattern
    # This will update every night
    hours: 0
    minutes: 0
sensor:
  # Keep track how many days have past since a date
  - name: This is just a test
    state: ""
    unit_of_measurement: "Days"

Resulting in-
Invalid config for [template]: expected a dictionary. Got [OrderedDict([('trigger', [OrderedDict([('platform', 'time_pattern'), ('hours', 0), ('minutes', 0)])]), ('sensor', [OrderedDict([('name', 'This is just a test'), ('state', ''), ('unit_of_measurement', 'Days')])])])]. (See ?, line ?).

I don’t know with yours, but it does not work with packages like mine.

Maybe because at the end it will turn out like-

template:
  - 
      - trigger:
          - platform: xx
            ...

[tom_l]

I have this working at the moment:

template:
  - sensor: !include template_sensors.yaml
  - binary_sensor: !include template_binary_sensors.yaml
#  - !include template_triggered_sensors.yaml
#  - !include template_triggered_binary_sensors.yaml

If I change it to:

template:
  - sensor: !include template_sensors.yaml
  - binary_sensor: !include template_binary_sensors.yaml
#  - !include template_triggered_sensors.yaml
  - !include template_triggered_binary_sensors.yaml

And include Taras’s triggered binary sensor from above, it passes the config check. fails config check.

Damn. back to square one.

Though as I said, in the unlikely case that I ever need a triggered sensor I can put it in my configuration.yaml file.

[finity]

I just tried the following and got no validation errors:

configuration.yaml:

template: !include template_sensors.yaml
template binary: !include template_binary_sensors.yaml
template triggered: !include template_triggered_sensors.yaml

template_sensors.yaml:

  - sensor:
      ##...

template_binary_sensors.yaml:

  - binary_sensor:
      #...

template_triggered_sensors.yaml:

  - trigger:
      ##...
    sensor:
      ##...
    binary_sensor:
      ##...

the only caveat is that those are exactly the way the files are written. They don’t have any actual sensor code in there at all, just the headings.

But it did pass the config check.

I assume it’s just like having multiple “automation:” or “script:” by adding another label after it to differentiate the two files/code. (“automation old:” or “script second:”)

[tom_l]

It seemed to pass the quick config check but a restart failed miserably.

[finity]

Hmmm…interesting…

it looks like the “template binary:” and “template triggered:” entries in configuration.yaml are completely ignored.

If I put any code in those files the files aren’t loaded. Nothing even in the logs about it

That seems like it should be an issue report to me.

It should work for the template integration just as it does for any other integration using the old “method 1” and “method 2” references. I can’t specifically find those references in the docs anymore but the concept is still discussed and should be valid. Or at least it should be made to work that way for consistency.

Splitting up the configuration

[CaptTom (Tom)]

@123

That message is vaguely familiar from long ago. I have a hazy recollection of having to do something goofy like putting at least one Trigger-based Template Sensor at the top so that Template Sensors and Template Binary Sensors don’t appear first.

@tom_l

I don’t actually use triggered sensors as I find automations that publish retained mqtt messages and mqtt sensors initialise better after a restart. So I might just skip them.

Sorry to dredge up this old thread, but this is exactly what I’m trying to do; migrate all my templates to the new format, and at the same time, split them off into a new templates.yaml file.

Without the workaround @123 suggested (adding his dummy triggered sensor to the beginning of the templates.yaml file) I get errors. Put that sensor back in and it passes the configuration test.

So, @tom_l, did you ever get it working without the triggered sensor, and if so, how?

This thread has already saved me a ton of time. This was driving me crazy until I found the trigger workaround. Thank you!!

[tom_l]

@CaptTom

did you ever get it working without the triggered sensor, and if so, how?

Yes. Like this:

template:
  - binary_sensor: !include template_binary_sensors.yaml
  - sensor: !include template_sensors.yaml

The template_sensors yaml file:

- name: 'Calculated Light Brightness'
  icon: "mdi:brightness-auto"
  unit_of_measurement: "Int"
  state: >
    {% if states('sensor.weatherflow_brightness') not in ['unknown', 'unavailable'] %}
      {% if now().hour >= 20 and now().hour < 23 and states('sensor.weatherflow_brightness')|float(0) <= 841 %}
        {{ ( -63.6667 * ( now().hour + now().minute / 60 ) + 1528.3333 )|int(0) }}
      {% elif now().hour == 23 or now().hour < 6 %}
        64
      {% else %}
        {{ ( [0, (-0.0428 * states('sensor.weatherflow_brightness')|float(0) + 291 )|int(0), 255]|sort )[1] }}
      {% endif %}
    {% else %}
        {{ states('sensor.calculated_light_brightness') }}
    {% endif %}

- name: 'Calculated Light Brightness No Late Dim'
  unit_of_measurement: "Int"
  state: >
    {{ ( [0, (-0.0428 * states('sensor.weatherflow_brightness')|float(0) + 291 )|int(0), 255]|sort )[1] }}

...etc

template_binary_sensors:

- name: "Everyone in Bed"
  icon: "mdi:sleep"
  state: >
    {% if is_state('input_select.automation_mode', 'Guest Away') %}
      {{ is_state('binary_sensor.spare_bed_occupied', 'on') }}
    {% elif is_state('input_select.automation_mode', 'Guest Home') %}
      {{ is_state('binary_sensor.master_bed_occupied', 'on') and is_state('binary_sensor.spare_bed_occupied', 'on') }}
    {% elif is_state('input_select.automation_mode', 'Normal') %}
      {{ is_state('binary_sensor.master_bed_occupied', 'on') }}
    {% else %}
      {{ false }}
    {% endif %}

- name: "Mstr Bed Sunrise Sim Active"
  icon: "mdi:weather-sunset-up"
  state: >
    {% set d = now().strftime("%Y-%m-%d ") %}
    {% set t = now().timestamp() %}
    {% set mbr_sun_sim_active = strptime(d + states('input_datetime.mstr_bed_sunrise_sim_time'), '%Y-%m-%d %H:%M:%S').timestamp() %}
    {{ mbr_sun_sim_active < t < ( mbr_sun_sim_active + 1800) }}

...etc

If I ever need to use triggered sensors they have to go in my configuration.yaml file listed under the includes.

[123 (Taras)]

I did something very similar but using a different YAML directive:

template: !include_dir_merge_list templates/

The templates sub-directory contains separate files:

• binary_sensor.yaml
• number.yaml
• select.yaml
• sensor.yaml
• trigger.yaml

[tom_l]

Yeah that was always an option but…

@tom_l

I have a flat file structure. I don’t like hunting through directories.

[CaptTom (Tom)]

Thanks, both of you, for the amazingly quick response!!!

I was going to use just one templates.yaml file, but two or more will work just as well.

Is this a bug? Should it be reported? There seem to be two workarounds now, so it’s not critical. I’m sure it will trip up other users going forward, as more people (hopefully) migrate to the new template method.

[123 (Taras)]

I wouldn’t characterize what tom_l and I have offered as being workarounds; they’re legitimate means of structuring the information in their own right. I don’t even know if what I suggested is immune to the reported glitch because I have not tried it without a trigger.yaml file (clearly tom_l’s suggestion isn’t affected by it).

However, to your point, it does feel like a bug because there should be no need to define at least one Trigger-based Template Sensor before others can be defined. If you know if still occurs in the latest release (I haven’t tested it), report it as an Issue in the GitHub Core repository.

[bachtron]

I have a way to split the templates to different folders. I know OP wanted flat files, but i like to nest and have multiple files.

Folder structure:

.
└── 
├──  configuration.yaml
└──  templates
       ├──  binary_sensor
       │    └──* place all template binary sensors in here *
       ├──  sensor
       │    └──* place all template sensors in here *
       └──  triggers
            ├──default_templates.yaml
            └──* place all template triggers in here *

configuration.yaml

template: !include_dir_merge_list templates/triggers/

config\templates\triggers\default_templates.yaml

  - binary_sensor: !include_dir_merge_list ../binary_sensor/
  - sensor: !include_dir_merge_list ../sensor/

[beerygaz (Gavin Hill)]

What about switches? I don’t see switches or covers listed here, do these still follow the same pattern with the new preferred format?

[petro]

nope, none of the complex template platforms have made the switch.

[Mr.ToR (Tonguç Endem)]

Is it possible to make an include file that will only hold all different kinds of templates?
can anyone provide an example if possible please?
thanks

[tom_l]

template: !include templates.yaml

[Mr.ToR (Tonguç Endem)]

thnx man,
yes, that’s exactly what I’ll do but would it be possible to have various kinds of templates in one file such as a custom media_player template, a fan template and a light template?
if possible, how should I change the relevant code?
Can I just put all the different templates in a single template.yaml without chaning anything?
This is how they are in my configuration.yaml file.

#--------------------------------------
# media_player.template by Sennevds
media_player:
  - platform: media_player_template
    media_players:
      receiver:
      .
      .
      .

light:
  - platform: template
    lights:
      livingroom_fan_light:
      .
      .
      .

fan:
  - platform: template
    fans:
      stupid_fan:
      .
      .
      .

[tom_l]

Packages

[Mr.ToR (Tonguç Endem)]

Great That’s exactly what I was looking for.

You see, the problem is that my configuration.yaml is not so big yet to split it into entities. But not-so-small that it needs some logical splitting.

Packages will exactly solve this until my configuration gets sufficiently big.

Thanks a lot.

[Ildar_Gabdullin]

My experience:

1. Add this into “configuration.yaml”:

  packages: !include_dir_named conf

2. Create a “conf” folder in the config dir.

3. Create ANY tree structure in the “conf” folder:
   
   where each subfolder may have other subfolders and so on.

4. Inside any folder (let it be “network/net/asus_ac68u”, for example) create as many yaml files as you want.

5. Every yaml file may have “sensor”, “template”, “input_boolean”, “automation”, “customize” etc sections (surely one same section per one file, i.e. one “sensor”, one “customize” etc).

The main idea is to structure a config by tasks (network devices, persons, weather, home climat, etc) - instead of piling all template sensors in one file.

Unfortunately, there is one limitation - you must use unique filenames.
I.e. you cannot have several “test.yaml” files in different folders - have to rename them to “test_router.yaml”, “test_waterpump.yaml” etc.
Created this issue, missed a moment when it was closed.

Also, if you want to exclude some functionality (like “got rid of this router”) - just remove the whole “router xxx” folder form the structure. Alternatively - rename all yaml files in this folder, replace “yaml” extension by something llike “disabled” (I use “dis”).
If you have several HA installation (apartment, country house, test setup, …) and some router is moved from one place to another - just move it’s particular folder into another installation.

Secrets may also be stored on several levels (local secrets, global secrets).

A similar approach may be used for Lovelace (dashboards, views, decluttering- (described here), button-card-templates & a brand new config-template-card global vars).