Possible Indentation Issue?

Configuration
,
1

I’ve managed to do a lot with YAML, but I’m stuck when I need to use an integration more than once. Here I’m simply trying to duplicate brightness between two lights. I copied the code directly from someone’s who says it works great (with my own entity ID in place of his) but it’s not working for me. What am I missing?

trigger:
  - platform: state
    entity_id: light.master_hall_light
action:
  service: light.turn_on
  entity_id: light.master_overhead_lights
  data_template:
    brightness: >
      {{ state_attr('light.master_hall_light', 'brightness') | default(0, true) }}

  - platform: state
    entity_id: light.master_overhead_lights
action:
  service: light.turn_on
  entity_id: light.master_hall_light
  data_template:
    brightness: >
      {{ state_attr('light.master_overhead_lights', 'brightness') | default(0, true) }}
2

You should use a light group for this, not an automation.

3

If a light is manually adjusted (wall dimmer) the other light won’t automatically follow that brightness setting with a light group through right?

I agree from a UI/Automation perspective, it solves the solution, however, I didn’t think light groups solved the issue for manual control and then syncing the other light.

4

You use wall switches? How delightfully 20th century.

5

If you still live in the 20th century :roll_eyes: and have wall switches, you need to have two automations. This can be done with a single automation and some fancy template work, but that is above my paygrade.

Note the addition of the alias for each and the complete trigger and action sections for each.

  - alias: automation 1
    trigger:
      - platform: state
        entity_id: light.master_hall_light
    action:
      service: light.turn_on
      entity_id: light.master_overhead_lights
      data_template:
        brightness: >
          {{ state_attr('light.master_hall_light', 'brightness') | default(0, true) }}

  - alias: automation 2
    trigger:
      - platform: state
        entity_id: light.master_overhead_lights
    action:
      service: light.turn_on
      entity_id: light.master_hall_light
      data_template:
        brightness: >
          {{ state_attr('light.master_overhead_lights', 'brightness') | default(0, true) }}
7

I have several light groups and can confirm groups are not capable of mirroring a switch.

Also, I think a dashboard capable of controlling my vehicles negates ‘antiquated’ light switches. Is there an alternative to light switches I’m not aware of? Because I feel like 1 smart light switch trumps 6 smart light bulbs.

IMG_0845
IMG_08454032×3024 1.77 MB

IMG_0846
IMG_08464032×3024 1.56 MB

8

Hi, Zach - not sure why everyone is giving you a hard time about wall switches… The rest of my family members would revolt if I eliminated what they are comfortable with…

But to the point of your question, this should do the job:

- alias: Sync up lights
  trigger:
  - platform: state
    entity_id: 
    - light.master_hall_light
    - light.master_overhead_lights
    from: 'off'
    to: 'on'
  condition: []
  action:
  - service: light.turn_on
    data:
      entity_id: >
        {% if   "master_hall_light"  in trigger.entity_id %} light.master_overhead_lights
        {% else %}                                           light.master_hall_light
        {% endif %}
      brightness: >
        {% if   "master_hall_light"  in trigger.entity_id %} {{state_attr('light.master_hall_light','brightness') }}
        {% else %}                                           {{state_attr('light.master_overhead_lights','brightness') }}
        {% endif %}

It will only trigger when one of the lights goes from off to on. The template checks to see which light turned on. If it’s the light.master_hall_light, then the service turns on light.master_overhead_lights. If master_hall_light is not the triggering entity, then it turns on light.master_hall_light. It pulls the brightness from the triggering light entity (I think that’s what you’re after).

Hope this helps!! Let me know if it doesn’t do what you intend. Or if it for some reason it throws an error in the logs…

Coming clean: I checked this with the configuration checker, but have not tested it with my own lights.

1 Like
9

That’s so cool looking! Nice job! I’m thinking it’s time to update my dashboard :wink:

Yep…

1 Like
10

I was actually able to get it working using @silvrr’s suggestion. Much appreciated (despite living in the 20th century).

1 Like
11

1 - make the switch talk to homeassistant instead of directly to the bulbs, ergo control the homeassistant light group instead of a single light.

2 - intelligent automation, the light group is on and off (appropriately themed) when it should be automatically without any requirement for a switch.

3 - motion sensors, the light group is on (appropriately themed) when there is movement without any requirement for a switch.

4 - occupancy detection, the light group is on (appropriately themed) based on whether the room is occupied.

5 - wasp in a box, a combination of factors such as motion, contact, presence sensors that define whether a light group should be on or off and appropriately themed based on the certainty or uncertainty of the occupancy a room.

You could always strive to have both car control and intelligent lighting.

12

As a more general reply to the thread, there is a huge difference between smart switches and the old ‘manual’ style wall switches. My comment about the 20th century referred to the latter which was inferred by silvrr.

But anyway, if it’s working for you that’s great, but this should be a light group controlled by a smart switch, as per my suggestion number 1 above (with a view to moving onwards to not requiring any actual interaction with the switch in the first place).

13

All true, however, you still need a switch to make this happen - the physical switch on the wall - which is what I was referring to. And while I do have lights grouped into a single switch on my dashboard, as far as I can tell groups cannot manage attributes beyond simple on/off commands.

14

Well, you don’t ‘need’ a switch, that’s a choice.

But yeah, I have two light groups in my house both of which can be controlled by smart switches if required without issue, because the switch speaks to homeassistant rather than directly to only one of the bulbs. The difference is what the switch controls.

If your switch directly controls one bulb and you change its brightness, then the other bulbs in the group won’t be affected, so your current approach employs an automation to monitor the change and duplicate it.

However, the downside of your current approach is that you can now only control the lights individually in the future if you disable this automation, which adds complexity.

But if your switch controlled the light group in homeassistant instead, then changing the brightness via the switch will automatically apply to all bulbs in the group, but if you want to individually control the bulbs (low powered occupancy simulation whilst you are away, for example) then you can without having to activate and deactivate other parts of the system.

I see it as like a 4 stage fallback system here.

Stage 1 - fully automatic, lights are on when they should be, nobody really needs to touch any switches and 99.99% of the time they never do.

Stage 2 - the 0.01% of the time that the automation system doesn’t suit the situation, simple voice controls to change what you need.

Stage 3 - if you really must use a switch (maybe the internet goes wonky - we use Alexa for voice control), then the smart switch is there, ergonomically positioned so that it’s easy to find and use, controls all the lights you would expect it to.

Stage 4 - total system failure, emergency fall back, revert to the old, hidden hardwired direct switches.

This also applies to my heating system too.

Stage 4 has only happened once in the last 3 years due to hard disk failure, so we spent a couple of hours of an evening in November reverting back to the caveman days, then the next day when the new hard disk arrived popped it in and back to stage 1.

Works well.

15

Thanks so much for your help so far! I’ve finally had more time to work on this automation and although it works great and checking configuration doesn’t return any errors, I do get the following error when I Reload Automation:

Invalid config for [script]: expected a dictionary. Got OrderedDict([(‘automation’, [OrderedDict([(‘alias’, ‘Master Bedroom = Master Hall’), (‘trigger’, [OrderedDict([(‘platform’, ‘state’), (‘entity_id’, ‘light.master_bedroom’)])]), (‘action’, [OrderedDict([(‘delay’, 4)]), OrderedDict([(‘service’, ‘light.turn_on’), (‘entity_id’, ‘light.master_hall’), (‘data_template’, OrderedDict([(‘brightness’, “{{ state_attr(‘light.master_bedroom’, ‘brightness’) }}\n”)]))])])]), OrderedDict([(‘alias’, ‘Master Hall = Master Bedroom’), (‘trigger’, [OrderedDict([('… (See /config/configuration.yaml, line 8).

This is my code:

- alias: Master Bedroom = Master Hall
  trigger:
    - platform: state
      entity_id: light.master_bedroom
  action:
    - delay: 4
    - service: light.turn_on
      entity_id: light.master_hall
      data_template:
        brightness: >
          {{ state_attr('light.master_bedroom', 'brightness') }}

It’s infuriating playing trial and error with indentation and dashes because every code is different, and like I imagine most of us on here are, I’m incredibly OCD so even though it works, this error is killing me inside.

Thoughts?

16

The error says you’ve tried to put your automation code under a script: key.

17

I’ve tried multiple other ways with entirely different indentation in some places (mimicking parts of code from Home Assistant examples and simplified the ids) but still receive the exact same error.

Here’s my last attempt:

- id: 'mstrbedtohall'
  alias: Master Bedroom = Master Hall
  trigger:
  - platform: state
    entity_id: light.master_bedroom
  action:
  - delay: 4
  - service: light.turn_on
    entity_id: light.master_hall
    data_template:
      brightness: >
        {{ state_attr('light.master_bedroom', 'brightness') }}

What am I doing wrong?

18

If it’s in the same place as before, then you’re doing the same thing wrong as before and putting it under the wrong key.