Why and how to avoid device_ids in automations and scripts

[tom_l]

@Stiltjack

Automations using device_id are only visible if all the devices they depend upon are available. If one of them is not, they may “disappear” from the GUI.

That should have been fixed. The automations should now report as unavailable if they depend on missing devices. However that change may have made things worse:

Missing devices used in automations cause Home Assistant to fail to load automations

[Stiltjack]

Damn. I got that from one of your posts . Guide updated, thanks…

[sebby (sebastian)]

Excellent advice! Just went through and updated all my automations to not use device IDs in the actions, but some of the automations use device_id’s in the conditions. is there a way to fix that? Most of my conditions are simple “is it on”, for example:

      - condition: device
        device_id: 5f3f155a7995b74b6a36ec9555cfc217
        domain: media_player
        entity_id: media_player.big_tv
        type: is_on

[Didgeridrew]

Use a State condition (or whatever the appropriate condition is for other cases)…

- condition: state
  entity_id: media_player.big_tv
  state: 'on'

[jtbandes]

How does one apply this advice to a manufacturer-specific ZHA command? Example: I have an Inovelli switch and the Device action gives me this “Issue effect for individual LED” option which then enables various fields (defined here in ZHA):

The YAML for this action looks like:

type: issue_individual_led_effect
domain: zha
device_id: ccd62cc4a251872fa2edef785bdf798e
led_number: 4
effect_type: Clear
color: 150
level: 100
duration: 255

However, there does not appear to be a service named zha.issue_individual_led_effect and when I try to use that name in a “Call service” action I don’t see the fields anymore:

Further, I was hoping to be able to set the device id (or entity id) of this action using a template, so that I can fill in a script input there. Is that possible?

[123 (Taras)]

The service call is zha.issue_zigbee_cluster_command.

Here’s a script blueprint:

ZHA - Inovelli Blue Series 2-1 Switch LED Notification Script

A script blueprint to control the LED notification bar on the Inovelli VZM31-SN or VZM35-SN Blue Series 2-1 Switch via ZHA. This script is based on the Z2M-equivalent script and templates shared on Inovelli’s forums. Features: Only need to create one script using the blueprint All variables, including target switch, are passed when calling the script rather than when configuring it, allowing you to reuse the same script for any Inovelli switch Select from different preset animations + off …

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Here’s a current Jan-2024 output from the UI editor.

Which of these 2 conditions would you rather troubleshoot?
2 - 32 character random hex strings or an entity_id?

action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - dirty
        sequence:
          - type: turn_on
            device_id: a98db942fb9411339403edc7c7f9e3de
            entity_id: fa492ac875bdb706179edac181b3297a
            domain: fan
      - conditions:
          - condition: trigger
            id:
              - clean
        sequence:
          - service: fan.turn_off
            target:
              entity_id: fan.r2d2
            data: {}

I rest my case.

[Mar-85]

So how does using Entities affect automations say for instance i have a motion sensor that turns on a led strip if all the upstairs lights are off. If these are smart bulbs and someone flicks the (not smart) switch and the bulb becomes unavailable will this cancel the automation or will it count “unavailable” as off?

[tom_l]

The state will be unavailable. If you want to trigger from on to off or from on to unavailable or unknown do this:

trigger:
  - platform: state
    entity_id: light.my_smart_light
    from: 'on'

if you only want to trigger from on to off do:

trigger:
  - platform: state
    entity_id: light.my_smart_light
    from: 'on'
    to: 'off'

[k8gg]

Correct. Unavailable is unavailable, unknown is unknown, neither would be considered as off.

Off is off.

[Mariusthvdb (Marius)]

I had 1 of those, mainly as an experiment in the UI editor for automations (I have them all in yaml.), and it was even more cryptical than most above:

  - type: moist
    platform: device
    device_id: afa7a35223f4392eaaf6c1b88ab072db
    entity_id: 2adfe81af765e65dad7ce32ca8bdf1e9
    domain: binary_sensor

I mean, we can deduce its about a sensor detecting moist, but it doesnt even contain a to state? only a type?

  - platform: state
    entity_id: binary_sensor.waterlek_sensor
    to: 'on'
    # from: 'off' # if you require so

yep definitely agree on the easier choice here…

funny thing is that the automation fires a notification, during the period the device is ‘on’, and that actually does:

        while:
          - condition: state
            entity_id: binary_sensor.waterlek_sensor
            state: 'on'

so even the UI thinks its better to use that entity_id

[zigomatic]

If you want to rename the device and all the entities below are modified, then you have to go to all the automation to modifying those.
Using device_id will not be impacted by this. There are some pro and cons.

[bob.t (Bob)]

@zigomatic

If you want to rename the device and all the entities below are modified, . . .

That was helpful, for me at least, in understanding how that works.

And in turn it has me appreciate the Watchman integration even more, and thought the integration deserved a mention in for those even greener than I am with HA, in this regard.

[zigomatic]

Watchman is a great help in there.

Also there other benefits to use device_id as this will be used by HA in some parts of the code like in logbook apparently (I’m just repeating info that I got from the forum).

Check my Feature request if you are interested:

Enhanced Device ID Search and Friendly Naming in Developer Tools

In my automation YAML, I found a device_id: c5b52----blabla--dd13f, but I can’t search for device_id via Developer Tools, which is a bit inconvenient. I would like to request a new feature which can be either in Developer Tools or in Automation flow Developer tools: The ability to search by device_id and retrieve all relevant information attached to it. Just as we have various filtering options in the UI now, it would be fantastic to have similar functionality in Developer Tools. Benefits: I…

[parautenbach (Pieter Rautenbach)]

When you onboard a new device you should first give it a sensible name. If you’re renaming after you’ve started using it, that’s a different matter, but you likely will only have to do the search and replace once ever (assuming it gets a proper name the second time around). If you replace a device you will have to rename the usages every time you replace a device, as opposed to renaming device entities.

[Edwin_D]

@zigomatic

If you want to rename the device and all the entities below are modified, then you have to go to all the automation to modifying those.
Using device_id will not be impacted by this. There are some pro and cons.

Renaming entities is a choice, if you do not, automations will work, if you do change them, it is exactly the same amount of work as changing device IDs.

The biggest dealbreakers using device ids for me are:

• I had integrations suddenly changing all device id’s, breaking all automations. Then there’s no help what changed to what, because old id’s no longer exist. Automations using entity ids did not break.
• If a device breaks that is used in a trigger, the whole automation is disabled, even if there are more triggers that could have still worked perfectly. Entities don’t have that problem.
• Device conditions/triggers are hard to get support on from others here, because the behavior and actions are specific to the device.
• When a device breaks or is replaced by something else: entity - no problem, with device ids: always needs fixing everywhere. It is not even a given that just search/replace the device id will work across different brands/integrations.

[busman]

How to avoid device_id for scene controller?

I have a Z-Wave button, or really a “scene controller”, that I use to turn on a pump. If I use the UI to create an automation for scene 002:

The resulting action looks like this, which does trigger:

trigger:
  - platform: device
    device_id: f381791969ec48f1a1405bfe1f9f39b0
    domain: zwave_js
    type: event.value_notification.central_scene
    property: scene
    property_key: "002"
    endpoint: 0
    command_class: 91
    subtype: Endpoint 0 Scene 002

Here’s the entity for that scene:

I can test state like this, but that only triggers on the attribute changing – yes, it will trigger if I first press the button 2x times to set KeyPressed2x, but if it is already KeyPressed it won’t trigger since it’s not changing.

trigger:
  - platform: state
    entity_id:
      - event.recirc_pump_remote_switch_scene_002
    attribute: event_type
    to: KeyPressed

I tried using an event trigger like this, but it’s not triggering. Plus, I’m wondering if triggering on such a frequent event is a bad idea.

trigger:
  - platform: event
    event_type: state_changed
    event_data:
      new_state:
        entity_id: event.recirc_pump_remote_switch_scene_002
        attributes:
          event_type: KeyPressed

Is there another approach?

Here’s what the event looks like:

event_type: state_changed
data:
  entity_id: event.recirc_pump_remote_switch_scene_002
  old_state:
    entity_id: event.recirc_pump_remote_switch_scene_002
    state: "2024-06-09T17:39:03.528+00:00"
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed
      value: 0
      friendly_name: Recirc Pump Remote Switch Scene 002
    last_changed: "2024-06-09T17:39:03.528460+00:00"
    last_reported: "2024-06-09T17:39:03.528460+00:00"
    last_updated: "2024-06-09T17:39:03.528460+00:00"
    context:
      id: 01HZZ1A3784S14M58679N86CM9
      parent_id: null
      user_id: null
  new_state:
    entity_id: event.recirc_pump_remote_switch_scene_002
    state: "2024-06-09T17:47:41.061+00:00"
    attributes:
      event_types:
        - KeyHeldDown
        - KeyPressed
        - KeyPressed2x
        - KeyPressed3x
        - KeyPressed4x
        - KeyPressed5x
        - KeyReleased
      event_type: KeyPressed
      value: 0
      friendly_name: Recirc Pump Remote Switch Scene 002
    last_changed: "2024-06-09T17:47:41.061750+00:00"
    last_reported: "2024-06-09T17:47:41.061750+00:00"
    last_updated: "2024-06-09T17:47:41.061750+00:00"
    context:
      id: 01HZZ1SWM57FP2QKQH328A7YWF
      parent_id: null
      user_id: null
origin: LOCAL
time_fired: "2024-06-09T17:47:41.061750+00:00"
context:
  id: 01HZZ1SWM57FP2QKQH328A7YWF
  parent_id: null
  user_id: null

[TheFes]

trigger:
  - platform: state
    entity_id: event.recirc_pump_remote_switch_scene_002
    to: null
condition: 
  - condition: state 
    entity_id: event.recirc_pump_remote_switch_scene_002
    attribute: event_type
    state: KeyPressed

this would be a solution.
But I would combine all actions for each event type in one automation using choose

[IngeJones]

The most usual reason for me to change a name is that I am repurposing the device, so I actually find it useful that it breaks stuff noticeably when I rename - as of course I need to edit those to accept the replacement device. I tried leaving the entity names as they were but I find it impossible to recognise which one to use unless they bear the name of their parent device - as it has become.