Advanced Automations in Home Assistant

Configuration
41

Damn, there’s a nice thread (or a tutorial) here on template sensors and I just failed at finding it. I’ll keep looking.

They end up working like little special-purpose automations. They trigger either on a state change or on an explicit trigger (or triggers), and do what an automation does but saves the result in the new sensor’s state (and/or also in attributes).

For example you could trigger on the time of day and set the sensor the the color level you are discussing. Then in another automation use that new template sensor for the light level. It simpifies the automations that use the sensors.

You can get much more sophisticated, of course.

1 Like
42

And then you create a bunch together for a function. Put it in a single yaml file as a package…

One file, the controls and scripts and automations and triggers.

(see why VS Code?)

43

Something other than vim?

1 Like
44

Nano works.

45

I am only beginning to understand the power of trigger based templates, my current understanding (which may be totally wrong) is that:

  • For the most part they are an advanced way of managing state.
  • Normally it’s not possible to run actions from trigger based templates.
  • The exception is when they are simulating UI controls.
    • However in this case the actions are only executed as a result of user action - not as a result of other templates changing state.
  • It is possible to share variables, hence you can do calculations once and update multiple target sensors.

However you can add automations on both sides of them:

  • To update them / push in new state.
  • To read their state / trigger on state changes

Hence the automations can then run actions.

46

They create a sensor (of some type) where you set the state and optionally attributes. They “run” either implicitly when a watched state changes or explicitly (just like in an automation) using one or more triggers.

So a very simple example might be a temp sensor that reads 5 degrees low. When the source sensor state changes you add 5 to its value and save that state.

You can run actions from a triggered template and use the results from those actions.

There’s no sharing of variables, if I read that right. They typically update their own state but there’s actions so you can update something else (although those should probably just trigger on the state change of the source).

I wouldn’t say there’s automations on each side of them. You can run actions and use data returned by actions do update state and do all the stuff you can do with templates to figure out what state to set.

The Templating docs are really good now.

1 Like
47

Checkout this thread:

48

You said:

I probably didn’t understand that comment as I’m sure you weren’t saying that you can create some kind of global variables to use in multiple sensors.

49

Totally doable. This is the basis for my cabinet system in the Friday’s Party project.

Once you setup a trigger text sensor it basically is a memory location you can dump attr data in - a global variable

I just use a var block at the top of the script or automation to read the right things into vars at the top…

50

Yes, exactly. That’s the clear wording.

51

Templates have been a part of HA since v. 0.12… they are, arguably, more “native” than the majority of the UI.

1 Like
52

I believe that is what David is saying… though the variables are only global in the local sense…

When using the trigger-based schema, there are multiple places where you can define variables that will be available to all entities configured in that block:

  • Attached to the trigger(s)
  • In variables at the entry level
  • In a variables action
Example 
template:
  - triggers:
      - trigger: state
        to: foo
        entity_id: sensor.spam
        variables: 
          var_1: "{{ now().day }}"
    variables:
      var_2: "{{ now().month }}"
    actions:
      - variables:
          var_3: "{{ now().year }}"
    sensor:
      - name: Year-Month-Day
        state: "{{ var_3 - var_2 - var_1 }}"
      - name: Month-Day-Year
        state: "{{ var_2 - var_1 - var_3 }}"
    binary_sensor:
      - name: Date Mod Silliness
        state: "{{ var_3 % var_2 > var_1 }}"
2 Likes
53

When I said:

  • It is possible to share variables, hence you can do calculations once and update multiple target sensors.

I was envisioning the var_2 from your example, I hadn’t considered the other variable use cases in your example.

However it should be noted that there is nothing stopping someone from creating sensors that simply return the value of one of these variables. I wouldn’t describe such sensors as “global variables” as that implies that one could update them directly, however I would say such sensors are “global state” since they remember their value and only update when the relevant triggers fire.

Which is a more verbose way of saying my first point:

  • For the most part they are an advanced way of managing state.