Include yaml file into automation script

Feature Requests
,
1

Hi All,

Im using lots of variables in my automations. For some reasons:

  1. When a entity gets a new name or I want change it, I only change them on top of the automations. Not in the whole automation script

  2. For me a better readable way, I know what entities are used in the automation.

But… it would be so nice to create a yalm file that have all the variables on a list that are used by the user.

On top in every automation you can include this file so the variables will be available for that automation script. Something like this:

var.yaml

  variables:
    peter_early_up: switch.peter_early_up
    bedroom: binary_sensor.bedroom_detection
    door_bedroom: binary_sensor.bedroom_door_contact
    adaptive: "{{ states('sensor.adaptive_lighting_color_temperature') }}"

In the automation you add:

!include var.yaml

Now those variables are usable in that automation. You can use the var.yaml everywhere you want to use it.

Cheers,

2

Probably wise to vote for your own feature request?

1 Like
3

That are probably already possible, but you might need another include command.

Check this video out and see if that can help you.

4

Probably a good idea to correct your spelling - not yams or yalm.

6

This is only show how basics work and how you can split up… nothing that sow how include a file into a automation

7

There is alot about different include types, but maybe I did not understand correctly what you are trying to achieve.

9

The !include directive is used to assign a value to an option. For example, this will assign the contents of groups.yaml to the group option:

group: !include groups.yaml

If we apply that to your Feature Request, it would be:

  variables: !include var.yaml

However, currently !include is used for assigning values to domains in configuration.yaml (or packages). You want to extend it for use in automations. Effectively, your FR is requesting a means of creating global variables (because more than one automation can reference the same variables file).

I like the concept of global variables but I’m not sure this is the best way to implement them.

10

If you can add the variables into a section so they are always usable in every script you request them.

11

Out of curiosity, how many automations do you have that use the same variables?

12

I think around 21. Before HA I used domtoicz and had same way. 1 file with all variables into it so I can use them everywhere.

If I change a entity I only need change the variable file and all automations are use the new info. No more edit all automations

Better will be when you change a entity that HA automatically rename all entities inside the script.

Now you can see what scripts a entity is used so will be possible to change it when entity is renamed

13

What I see in your example is that your variables are simply aliases for existing entities or an entity’s state. Sometimes I do that in a single automation (if the automation refers to the same entity, or state, in multiple places) but I haven’t found much need to share the exact same variable in another automation.

Rather than importing an external file containing multiple global variables (which I may only need some but not all of them), I would prefer to reference the global variables individually and directly in the automation. For example, perhaps something like this:

alias: whatever
description: ''
mode: single
import_global:
  - bedroom
  - door_bedroom
trigger:
  - platform: template
    value_template: "{{ states(bedroom) == 'on' }}"
condition: []
action:
   ... etc ...

The global variables bedroom and door_bedroom would be defined elsewhere such as in configuration.yaml under a new global domain.

global:
  peter_early_up: switch.peter_early_up
  bedroom: binary_sensor.bedroom_detection
  door_bedroom: binary_sensor.bedroom_door_contact
  adaptive: "{{ states('sensor.adaptive_lighting_color_temperature') }}"

If you wanted to you could put the global variables into a file and then the global domain can be defined something like this:

global: !include globals.yaml

Anyway, just a thought.

14

the main problem around this req is the fact, that the WHOLE ha configuration is one big yaml document regardless split into several files. I mean configuration, automations, even themes - all is the single yaml document.
Separate files representing its parts are joined and then parsed without any soace for preprocessing

It causes several issues:

  1. if one part has some issues, likely whole yaml is rejected from liading. Recently I had some minor typo in a theme (btw copied from some foreign repo) which caused that HA didn’t recover after restart (even if it could fallback to default theme, but it didn’t)

  2. there is no space for any variables, preprocessing etc. there are techniques to create custom attributes to be used elsewhere (anchors), but those cannot be rewritten locally, not impacting their other appearances. it might be useful for some usecases while not for anothers.

To me whole HA config deserves overhaul.

edit: in contrary to taras’ example above I see no justify to create globals after sensors. making one identifier from another, adding new ones with new entities doesn’t make sense to me.
I would like to be able to have template of entity(s) which I can include after setting local variables. those variables would be resolved in the template. It would create tents of similar entities which differs only by their root name
I know I can achieve it with pre-generating yamls , but this is not the approach I accept (to have maintain one language which describes method to create configuration for another language is overkill imo)

15

I have this way already in couple of automations now for some testing.

Would be nicer when you can add the:

global: !include globals.yaml

into the configuration.yaml file. So they will load just 1 time and available for all scripts that request on or more of those global variables.

You also can put if statements to it when they repeat sometimes in your automations.
So the automation scripts become smaller en nice readable.

Change a if statement in globals they changes for all automations that use this global variable.

I think it can be a very nice implementation into HA for people who want use this!