[SOLVED] Template: array for lights in scripts?

prankousky · October 7, 2019, 9:13am

Hi everybody,

I am trying to control multiple lights via script; the script itself works fine when using just one light, so there must be something wrong with the way I am trying to add multiple lights. Can you please tell me what I am doing wrong?

script:
  sonnenaufgang:
    sequence:
      - service: homeassistant.turn_on
        data_template:
          entity_id: "{{ wecklicht }}"
          rgb_color: [164,0,0]
          brightness: 25
      - delay:
          seconds: 1.00
      - service: homeassistant.turn_on
        data_template:
          entity_id: "{{ wecklicht }}"
          rgb_color: [255,137,0]
          brightness: 80
          transition: 15
      - delay:
          seconds: 10.00
      - service: homeassistant.turn_on
        data_template:
          entity_id: "{{ wecklicht }}"
          rgb_color: [255,209,100]
          brightness: 250
          transition: 15

automation:
    trigger:
      platform: template
      value_template: >
        {{ states('sensor.time') == states('sensor.wochentag_alarm_time') }}
    condition:
      - condition: time
        weekday:
          - mon
          - tue
          - wed
          - thu
          - fri
      - condition: state
        entity_id: input_boolean.wecker_wochentag_ein
        state: 'on'
    action:
      - service: script.turn_on
        entity_id: script.sonnenaufgang
        data:
          wecklicht: [light.schlafzimmer_led_bett, light.sz_led_seite ]
      - service: script.turn_on
        entity_id: script.wecksong

Thank you for your input.

123 · October 7, 2019, 12:01pm

Change this:

        data:
          wecklicht: [light.schlafzimmer_led_bett, light.sz_led_seite ]

to this:

        data:
          wecklicht: "light.schlafzimmer_led_bett, light.sz_led_seite"

NOTE:
The smallest increment of time in Home Assistant is 1 second. Therefore there’s no need to indicate precision beyond a whole value. In other words, this:

      - delay:
          seconds: 1.00

is unnecessary because Home Assistant only handles whole values (integers) like this:

     - delay:
         seconds: 1

prankousky · October 7, 2019, 12:58pm

Thank you!

I get this error in my log still

2019-10-07 14:56:31 ERROR (MainThread) [homeassistant.components.automation] Error while executing automation automation.wecker_wochenende. Invalid data for call_service at pos 1: extra keys not allowed @ data['wecklicht']

The way I understood it, I could use any data when passing on to a script, as long as I then call that data (so if I used wecklicht as a variable, I’d have to call wecklicht from a script). However, that seems to be the problem here. I cannot use wecklicht, or my template is wrong so that it does not recognize it as a variable…?

petro · October 7, 2019, 1:02pm

not sure if that will work as a variable. I believe it would come across as a string. Only a few fields know how to take a comma separated string and turn it into a list. That’s dependent on the service and usually only for the entity_id field.

This

        data:
          wecklicht: [ 'light.schlafzimmer_led_bett', 'light.sz_led_seite' ]

or this should work.

        data:
          wecklicht:
          - light.schlafzimmer_led_bett
          - light.sz_led_seite]

If these don’t transfer objects into the script and they transfer comma separated strings, then go with @123’s config and then separate the entities out inside your variable

 {{ wecklicht.split(', ') }}

change your service to this:

- service: script.sonnenaufgang
  data:
    wecklicht:

You’re getting that error because the service script.turn_on does not accept random values. You have to call scripts directly to get around this. Or place wecklicht inside variables when using script.turn_on.

123 · October 7, 2019, 1:29pm

I used this to test and confirm it works:

automation:
- alias: test1
  trigger:
    platform: state
    entity_id: input_boolean.master
    from: 'off'
    to: 'on'
  action:
    service: script.test1
    data:
      lights: 'light.family, light.kitchen'

script:
  test1:
    sequence:
      - service: light.turn_on
        data_template:
          entity_id: '{{ lights }}'

The variable’s data is being passed to entity_id which, as you indicated, knows how to handle a comma-delimited string of entity_id’s.

What I overlooked in prankousky’s automation is how it calls the script. It should refer to it like you described, as a service name:

    action:
      - service: script.sonnenaufgang
        data:
          wecklicht: 'light.schlafzimmer_led_bett, light.sz_led_seite '

petro · October 7, 2019, 1:38pm

Yah, it’ll work in your case because light.turn_on allows comma separated for entity_id.

123 · October 7, 2019, 1:46pm

Good point! I had made that change in my version without considering how light.turn_on may differ from homeassistant.turn_on (assuming homeassistant was only a more comprehensive version).

I can confirm it does NOT work if the script uses homeassistant.turn_on. That service can’t handle a comma-delimited string of entity_id’s.

Mutt · October 7, 2019, 2:02pm

Would that level of inconsistency not be considered a bug - or would they prefer to call it a feature ?

prankousky · October 7, 2019, 2:22pm

Thank you so much! It works perfectly now
I don’t remember why I had used homeassistant.turn_on for this to begin with, but I remember something didn’t work back when I first created this script (a few version updates ago) when I used light.turn_on

Mutt · October 7, 2019, 2:58pm

Not at an HA instance at the moment, what does it do with switches ?

petro · October 7, 2019, 3:46pm

Which IMO is a bug.

silvio · December 5, 2019, 8:00am

I agree. I’ve been banging my head to get it working using homeassistant.turn_on or off and now I see this doesn’t work. I also had some issues using a template sensor holding a list of devices that needed interaction on. It appears if you use data_template in a script, this needs to be converted into a string. Lost a day sorting this out. Only way to get it working was to use {{states.sensor.something.state | string}}

petro · December 5, 2019, 12:55pm

states are always strings no matter what. Shouldn’t have to cast it as a string at all. Attributes on the other hand can be anything. But even in the end, casting it as a string isn’t really required because all jinja templates are strings when the template is finalized.

silvio · December 6, 2019, 7:11am

Maybe it’s because I created a template sensor with a tuple? The sensor presents the data as string in the FE, but without the conversion in my script it doesn’t work. It throws an error stating 'not a valid valid value for dictionary value @ data[‘entity_id’].

Furthermore in the same script I had to change the service homeassistant.turn_on (that switches lights and input_booleans into two different services, light.turn_on and input_boolean.turn_on). Homeassistant.turn_on threw an error. Very strange.

petro · December 6, 2019, 12:44pm

The () must from the tuple must be screwing with the template. if you change your sensor.something’s output from a tuple to a comma separated string {{ blah | join(', ') }}, then that would probably remove the need for the | string at the end. But that still doesn’t make sense because any .state is already a string.

klogg · December 6, 2019, 1:04pm

This fact has recently raised a question (to myself) which I’d like an informed answer to rather than my assumption (that HA just deals with it by hoping the string can be converted on the fly).

numeric_state triggers.
The state is always a string so how does it do the above or below comparison?

Surprisingly I have never used a numeric_state. It must have flown under the radar when I first started with HA and I only recently stumbled upon them! I’ve always used templates.

petro · December 6, 2019, 1:09pm

You can convert any string to a number by casting it and having fail safes when you cannot cast it. This is most likely built into the logic behind the trigger.

klogg · December 6, 2019, 1:11pm

Yeah as I thought, I just wanted it confirmed. Thanks.

petro · December 6, 2019, 1:13pm

triggers outside templates all handle the string states safely. It’s just template triggers where the user has to properly use filters to cast types. For example, the float filter has this safety built in. It will take any string and attempt to convert it to a number. If it fails, it converts it to zero. So the user will always have a number after it’s cast.

silvio · September 6, 2022, 7:54pm

@petro how the hell do you know all these things? I’ve learned so much from reading your posts. I really appreciate your help. Keep it up!