Data vs. data_template

Configuration
1

What is the correct way of using either “data” or “data_template” in automations?
I see both used in similar service calls when reading in the forums and docs.

Examples:

      - service: media_player.volume_up
        data:
          entity_id: media_player.bathroom

      - service: tts.google_translate_say
        entity_id: media_player.elias
        data:
          message: "Please come up."
          language: 'da'

      - service: media_player.volume_set
        data:
          entity_id: media_player.elias
          volume_level: 0.7

      - service: sonos.set_sleep_timer
        data_template:
          entity_id: media_player.kitchen
          sleep_time: 0

      - service: media_player.select_source
        data_template:
          entity_id: media_player.kitchen
          source: '{{ states.input_select.select_radio.state }}'
1 Like
2

Simple. Whenever an item under uses templates then you need to use data_template. Otherwise you can use data.

2 Likes
3

Data_template needs to be used when you are using a template to get one of the data parameters. A data_template will work even if you don’t use a template (example 4 in your examples), however data will not work if you use a template.

4

Thanks both :slight_smile:
I just wonderes about one other thing:
In my example 2 “data” is right after the service call and entity afterwards
In example 3 it is opposite.
Which is more correct?

5

Both are correct, when you specify the entity_id outside the data part, it will automatically be moved to the data part in the background when the service call is executed.

6

Thanks… again :slight_smile:
So I guess I will just place entity_id inside the data part. Then it doesn´t have to be moved in the background.

7

Doesn’t matter, you won’t notice a difference.

8

As @Burningstone said, a “shortcut” is provided which allows entity_id to be used “outside” data (i.e., at the same level as service.) But note that, even though in most cases, both work the same, there actually is a slight difference in the internal implementation, which can cause problems in rare cases. See Issue #28633 & Issue #30668 for examples.

I’m just mentioning this for “completeness.” Probably not something most people will need to worry about.

2 Likes
9

I’m not arguing with anything Phil or Burning said but …

I find it much easier to read and also to find things when the entity is first and the data (which pertains to that entity) comes second.

This is not the way that the automation editor does things but I find the code it produces takes appreciably longer for me to read.

Edit: read the two issues, never done anything like Phil discusses. But on the former (using almost exclusively z wave kit I’ve never had an issue with entity id comming first.
TBH I’m more concerned about the stated lack of consistency across different kit

10

Those reasons alone are why I always just recommend placing entity_id inside data/data_template. Also builds consistency for myself.

2 Likes
11

I am about to clean up my automations in general so I want to correct potential issues.
I see that it might be more readable if enity is first but stability etc. weighs more so I will place it inside data I think.

12

You can always place it in data as the first item. Order inside data does not matter.

13

:+1: I have always done that

14

Now I notice another thing in my automations :slight_smile:
The use or not of “-” in front of conditions, service calls and so on.
What are the “rules” of using “-”?

Example:

  - alias: Bathroom lights ON weekdays
    trigger:
      platform: time
      at: "05:01:00"
    condition:
      - condition: time
        weekday:
          - mon
          - tue
          - wed
          - thu
          - fri
    action:
      - service: input_boolean.turn_on
        entity_id: input_boolean.bathroon_constant_on
15

The dash character introduces a list item. trigger, condition and action all take lists. However, another “shortcut” is, if you just need one item, then it will automatically convert the one item to a list containing one item. So the following are equivalent:

trigger:
  platform: xyz
  ...

trigger:
- platform: xyz
  ...

EDIT:

Similar to the "to data" or "not to data" scenario with entity_id, just get in the habit of always using the dash. :slightly_smiling_face:

And before you ask, the following are equivalent, too. I’m starting to like the latter because it uses less space, but it’s just another personal preference…

trigger:
  - platform: xyz
    ...

trigger:
- platform: xyz
  ...
16

-So if you have multiple conditions, triggers and service calls the dash is mandatory, if only one not?
I want to have a red line in my automations so I will definetely add the dash where it is missing now :slight_smile:

-Indents are not mandatory anymore?

17

The dash isn’t mandatory. But, for these specific config parameters, to enter multiple items a list is mandatory. There are at least two ways to make a list in YAML (that I know of), but using the dash is probably easiest.

I don’t know what you mean by that.

Indentation is basic to YAML. (And both examples above do have indentation.) But it has some flexibility in how you can use it.

18

By red line I just mean getting some system and uniformity. I guess that phrase can only be used in danish :laughing:
In the examples it just seems that the 2 indents in front of “platform” are removed in 1,2 and 4

19

Do you mean here:

trigger:
- platform: xyz
  ...
  ^
  |
  It's indented. The dash is "in" the indention whitespace.

Don’t get started on all the possible indentation schemes supported by YAML. I’m no expert, but I know it’s fairly flexible. If you’re ever wondering, just use an online YAML parser to do a sanity check.

20

I was thinking of the space in front of the dash here

trigger:
  - platform: xyz

Not here

trigger:
- platform: xyz