core: Inconsistent usage of `entity_id` in automations/scripts depending on `data`

Home Assistant release with the issue: 0.101.1

Last working Home Assistant release (if known): unknown

Operating environment (Hass.io/Docker/Windows/etc.): venv on raspbian buster

Integration: Automation, lights, manual_control_panel, others?

Description of problem: Automation actions have an entity_id key. For some types of actions, adding a data block requires the entity_id key to move inside data. Others do not require this. This leads to confusion on what we are supposed to do during configuration. There seem to be conflicting requirements across integrations.

This could be a documentation issue, but the conflicting requirements even within a single component like light, I would argue, suggests enforcing a universal behavior.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

This one was reported to not work for someone usig a zwave light, but moving it inside data works

action:
  - service: light.turn_on
    entity_id: light.led_salon
    data:
        brightness: 50

But, this one is reported to work using presumably the lifx integration.

action:
  - service: light.turn_off
    entity_id: light.lifx_bottom_of_stairs
    data:
      transition: 1

This one doesn’t work for manual alarm control panel, but again moving it inside data works.

action:
  - service: alarm_control_panel.alarm_disarm
    entity_id: alarm_control_panel.house_alarm
    data:
      code: !secret alarm_code

This one works for a custom component alarm:

action:
  - service: alarm_control_panel.alarm_disarm
    entity_id: alarm_control_panel.house
    data:
      code: !secret alarm_code

Traceback (if applicable): There are a lot of debug messages from an automation firing with my alarm code in them in plain text, I can scrub them if this is thought to be extra useful

Additional information:. These examples were taken from https://community.home-assistant.io/t/disarming-a-manual-alarm-control-panel-in-automation-with-a-code/146605

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 2
Comments: 16 (8 by maintainers)

Most upvoted comments

This is not an issue, there are just multiple options.

Well, this is a valid issue as it reports that some of those multiple ways do not work. However, things seem to have changed since 2019 so I think it is fine to close now.

If you find other service calls that fail please report each one separately. This is not a problem in general so each of them must be fixed individually.

amelchio on Jan 28, 2021

This is not an issue, there are just multiple options. As for the project itself, we will be moving everything towards the newer (and more flexible) target option of service calls.

So this will be slowly migrated to in the documentation:

action:
  - service: light.turn_on
    target:
      entity_id: light.living_room_table
    data:
      transition: 5
      brightness: 100

target also provide mean to target the same service call against an area ID or device ID:

action:
  - service: light.turn_on
    target:
      area_id: living_room
    data:
      transition: 5
      brightness: 100

Targets also provide a new UI (as seen in the selectors for Blueprint).

All other options will (for now) stay in order to keep backward compatible. I’ll go ahead and close up this issue, as it is not a bug.

frenck on Jan 28, 2021

Sill an issue in 2021.1.5

tomlut on Jan 26, 2021