Entity Relationships or Entity Metadata

Configuration
, ,
1

Greetings!

I am writing an automation that will turn on a light when a binary_sensor turns on, whether it is a motion detector or door/window sensor, or really whatever. In my automation, I have a list of binary_sensors in a state trigger:

 alias: Turn On Lights with Motion Seosor
  trigger:
    - platform: state
      entity_id:
        # Upstairs
        - binary_sensor.master_closet_motion

And in the action section of the automation, I have a choose block with a number of conditions, based on which entity triggers the automation, using trigger.entity_id == 'binary_sensor.XXXXXXX'

    - choose:
      - conditions: "{{ trigger.entity_id == 'binary_sensor.master_closet_motion' }}"
        sequence:
        - service: light.turn_on
          data:
            entity_id: light.master_closet_light_2

In stead of adding a new conditions block for each new binary_sensor/light association I have, I would love to simply find a way to associate a binary_sensor with a light, and have the light.turn_on call use the value of an attribute. I’m not sure this is possible, but it would greatly simplify the automation.

Alternatively, would it be possible to map these relations at the beginning of the automation or script like an associative array?

Thanks,
Jonesie

2

Yes, you can create a variable containing a dictionary that maps the binary_sensor’s object_id to the light’s object_id. An entity’s object_id is the right half of its entity_id (the “kitchen” in binary_sensor.kitchen).

The following example does that plus it adds a condition that ensures the automation doesn’t needlessly turn on a light that’s already on.

alias: example
variables:
  entity: >
    light.{{
      { 'kitchen': 'sink',
        'dining': 'sconces',
        'bedroom': 'tablelamp',
        'bathroom': 'vanity' }.get(trigger.to_state.object_id, 'unknown') }}
trigger:
- platform: state
  entity_id:
  - binary_sensor.kitchen
  - binary_sensor.dining
  - binary_sensor.bedroom
  - binary_sensor.bathroom
  to: 'on'
condition: "{{ is_state(entity, 'off') }}"
action:
- service: light.turn_on
  target:
    entity_id: '{{ entity }}'

How it works

This is the dictionary part:

 { 'kitchen': 'sink', 'dining': 'sconces', 'bedroom': 'tablelamp', 'bathroom': 'vanity' }

We use a dictionary’s get method to search the dictionary for the key containing trigger.to_state.object_id (that is the object_id of whichever binary_sensor triggered the State Trigger). If it finds a match, it returns the key’s associated value which is the object_id of the light. If it fails to find a match it returns unknown.

The whole thing is within a Jinja2 template so whatever is retrieved from the dictionary is appended to the “light.” in order to form an entity_id that is assigned to the variable called entity. For example, if the trigger was caused by binary_sensor.dining then the result of the template will be light.sconces.

The condition checks if the state of entity_id within the entity variable is off. If it is then it proceeds otherwise it exits.

The action simply turns off the entity_id within the entity variable.

3 Likes
3

WOW! This is outstanding! Thank you so much for the thorough and comprehensive help!

Jonesie

1 Like
4

Is there a reference for the language used somewhere, other than broken up into the Scripting, Script Syntax, Automation Triggers/Conditions articles in the Docs? Is there a programming language that this is built off of? It doesn’t look familiar, but I’m not a professional programmer, just a weekend warrior.

I would love to do some more advanced scripting and automation, but I don’t want to ask to have my hand held for each step. :slight_smile:

Thanks - Jonesie

5

Underneath the hood, it’s python. However, rather than oblige everyone to learn python in order to create automation logic, Home Assistant employs a simplified abstraction of it. This simplied version employs a trigger/condition/action pattern. Think of it like a form with fields you must complete. To provide a bit more flexibility, some fields support Jinja2 templating (and that’s where its association with python is most evident).