Grouping entities for automation templates

Configuration
1

In my home I have motion sensors in every room that trigger hue light groups. In Home Assistant I’ve had to create one automation for every room to turn the lights on and off. I would like to eliminate the duplicate logic and create a single automation that is configured with motion sensor/light group parings.

For example: when the kitchen motion sensor triggers the “turn on” automation I want to look up which light group is associated with that motion sensor and then turn the lights on.

I’ve experimented with automation templates but I could only use the trigger entity; I have yet to figure out how I can group that with other entities and look them up in my automation.

2

You can use Hue groups with Home Assistant, which benefits in simplier handling and faster response. But I don’t think, that you can read the associated groups off the motion sensor in HA.

3

Post two examples of these separate, room-based automations and we will help you create a single automation that handles all rooms.

4

Below are two nearly identical automations. I would like to setup one automation that can trigger on both sensors then use trigger.entity_id to somehow look up a light group I have associated with that sensor.

I just found out about blueprints. They sound like a good solution but I am curious if there are other viable options. These are my ideas so far:

  • Use blueprints. Pass in a sensor and light group for each instance.
  • Use areas/groups. Find what area the sensor belongs to, look for light devices in it.
    • Can’t find many docs on areas
  • Tag the motion sensor entity with some extra data
  • Do string manipulation on the sensor name to guess the light name
  • Some sort of lookup table
    • Arbitrary key/value store (don’t know if that exists)
    • Giant if/else or case statement
- id: '1582940122860'
  alias: Boiler Motion On
  description: ''
  trigger:
  - device_id: 7173f5b43a5d4c46a7e95c2cfbcde832
    domain: binary_sensor
    entity_id: binary_sensor.boiler_motion
    platform: device
    type: turned_on
  condition:
  - condition: device
    device_id: 7173f5b43a5d4c46a7e95c2cfbcde832
    domain: binary_sensor
    entity_id: binary_sensor.boiler_motion
    type: is_on
  action:
  - data_template:
      brightness: "{% if state_attr('light.default_light', 'brightness') %}\n  {{\
        \ state_attr('light.default_light', 'brightness') | int }}\n{% else %}\n \
        \ 153\n{% endif %}\n"
      color_temp: "{% if state_attr('light.default_light', 'color_temp') %}\n  {{\
        \ state_attr('light.default_light', 'color_temp') | int }}\n{% else %}\n \
        \ 230\n{% endif %}\n"
    entity_id: light.boiler_room
    service: light.turn_on

- id: '1583193305796'
  alias: Closet Motion On
  description: ''
  trigger:
  - device_id: 39b8bb5378fd45f0bd2b04570c5e1c59
    domain: binary_sensor
    entity_id: binary_sensor.closet_motion
    platform: device
    type: turned_on
  condition:
  - condition: device
    device_id: 39b8bb5378fd45f0bd2b04570c5e1c59
    domain: binary_sensor
    entity_id: binary_sensor.closet_motion
    type: is_on
  action:
  - data_template:
      brightness: "{% if state_attr('light.default_light', 'brightness') %}\n  {{\
        \ state_attr('light.default_light', 'brightness') | int }}\n{% else %}\n \
        \ 153\n{% endif %}\n"
      color_temp: "{% if state_attr('light.default_light', 'color_temp') %}\n  {{\
        \ state_attr('light.default_light', 'color_temp') | int }}\n{% else %}\n \
        \ 230\n{% endif %}\n"
    entity_id: light.closet
    service: light.turn_on
5

The two automations do some peculiar things. Before I can combine them into a single automation, I need clarification for the peculiarities.

  1. Why is there a condition to check if the motion sensor is on? The motion sensor just turned in order to trigger the automation so why is there a need to confirm it’s on? Based on my understanding, this condition is unnecessary.

  2. The template for brightness checks if the light has a brightness value. The only time it won’t have one is when it’s off. Is the idea here to supply a value of 153 if the light is off otherwise to use its existing value? If so then this template can be simplified.

  3. What is light.default_light? Its brightness determines the brightness of light.closet and light.boiler. Why?

6

Thanks for taking a look at this. It’s easiest to answer the questions in reverse order:

3. I built my automation around the idea of having one virtual light that determines the default value of all the lights in the house. I landed on this method early in my foray into home automation (before I discovered Home Assistant.) Some benefits of this method:

  • Easily use other software for adjusting the default light throughout the day
  • The whole house doesn’t do a big, noticeable shift at once. Lights only get updated values when they turn on
  • Modifications made to the current setting of individual lights stick until they shut off again. For example: if I manually tell the living room lights to go full brightness they will stay that way until I leave the room.

2. This is a hack I added for Home Assistant. The automation was failing if the default light was off so I added this, plus an automation that forces it to always be on. It was only an issue during server restarts. I would happily try another solution.

1. That condition is necessary in the cases where I do want to force updates and make the whole house shift at once. I can blindly trigger all the “on” automations and then only the ones with active motion will update.

7

I am currently looking at this blueprint. My goal is to rip out the scenes and replace them with my logic to copy a default light.

8

In Home Assistant, that concept is a Light Group (not to be confused with a Group).

It requires no automations; changes made to the Light Group entity are automatically applied to all its members. Nevertheless it’s still permitted to change any member’s state independently.

The explanation you provided for the two ‘hacks’ appears to reflect an approach inherited from some other home automation software. Neither are necessary if you take advantage of what’s available in Home Assistant.

The original requirements you posted don’t require, or benefit from, a blueprint.

9

Light groups do look useful but I specifically want to avoid automatically applying changes to all members. Each member should only update during the motion on, then stay fixed until the next motion on event.

10

What’s the relationship between the two statements? On the surface, they seem contradictory.

EDIT

Also, how have you created this virtual light called light.default_light that contains default values for other lights?

11

Changes to lights are only applied when the lights turn on. For example: you never see a light shift from cool to warm, instead one time when you walk into a room it will turn on to warm instead of cool. I have it working with the code above, it’s just copied for every room in the house and updates to that logic is a pain. I just want to figure out how to deduplicate that logic.

Code for default light:

input_boolean:
  default_light:
    initial: on

input_number:
  default_light:
    min: 0
    max: 255
    initial: 60
  default_temp:
    initial: 325
    min: 154
    max: 500

light:
  - platform: template
    lights:
      default_light:
        friendly_name: "Default"
        turn_on:
          service: input_boolean.turn_on
          entity_id: input_boolean.default_light
        turn_off:
          service: input_boolean.turn_off
          entity_id: input_boolean.default_light
        set_level:
          service: input_number.set_value
          data_template:
            value: "{{ brightness }}"
            entity_id: input_number.default_light
        set_temperature:
          service: input_number.set_value
          data_template:
            value: "{{ color_temp }}"
            entity_id: input_number.default_temp
12

Can you explain how you do that? Specifically, how you “blindly trigger” the automations without employing their existing trigger.