Automations sometimes not working, how to use the entity_id string instead of number

[0verEngineer (Julian)]

Hey, i have quite a few automations that looks like the one below, time based on and off, quite simple right?

My Problem is sometimes the automations do not work, i need do delete and recreate them from the same yaml and then it works.

I checked the yaml for these automations and it seems odd to me, it uses a number for device_id and entity_id, i thought this was the old logic / old syntax and we should use something like: entity: switch.ss9_aquariumlicht

1. Can i use this newer syntax in automations and how?

2. I heard devices are quite error prone, will this new syntax help there?

Automation code:

alias: Turn off Aquarium 09 Luft
description: ""
trigger:
  - platform: time
    at: "08:00:00"
condition: []
action:
  - type: turn_off
    device_id: 64b49a666ee54b4ff38cff71a39358b4
    entity_id: 2c863d5011fda2bb85f16cd4016bb716
    domain: switch
mode: single

Thanks a lot for your help

[finity]

@0verEngineer

i thought this was the old logic / old syntax

actually using device id’s is the NEW way of doing things.

@0verEngineer

I heard devices are quite error prone, will this new syntax help there?

the device structure in automations isn’t any more or less error prone than using entities/services (as far as I know unless something new has popped up).

the issue with using devices is that if/when you replace a device (device breaks, you update a device, etc) you have to go thru and manually change all of the scripts and automations to use the new device info. And it has to be done via the UI since you can’t use devices via yaml. So it will get tedious if you use that device in many automations.

@0verEngineer

Can i use this newer syntax in automations and how?

yes (even tho it’s technically the old way) but I’m not sure why you are finding your automations breaking in the first place. So it’s hard to know if it will help.

if you want to test it then (I’m assuming you use the UI to write automations since you use devices) using the example above you just need to select “call service” from the “action” drop down. Then select the “switch.turn_off” service. Then select the correct entity (switch.ss9_aquariumlicht).

for triggers or conditions use (for example) “state”, “numeric_state”, etc to use entities instead of devices.

[Stiltjack]

If a device is not available for any reason, automations depending on it will be disabled.

Why and how to avoid device_ids in automations and scripts

Don’t forget that the first post in a community guide is a wiki - feel free to add to it or correct it. This guide was written with reference to: Home Assistant 2023.8.3 Supervisor 2023.08.1 Operating System 10.5 Frontend 20230802.1 - latest Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [image] It works… but it is certainly not a “great way to start” because it …

[aceindy]

You are mixing up a few things…
Try to avoid using device actions (which use device and entity id’s), use service calls instead:

  - service: switch.turn_off
    data: {}
    target:
      entity_id: switch.ss9_aquariumlicht

This will also male it easier to maintain your automation in case you need to replace it.
Just remove the device, put in a new device and give it the same name again.
Devices can be renamed, device_id’s and entity_id’s are uniquely generated and cannot be re-used ever….

(which is basically the same as what @finity said; @Stiltjack also has a good point😉)

[finity]

I didn’t think about that (since I never use devices )

just one more reason to not use them.

But a question it brings up tho is if an unavailable entity will also disable an automation that uses it? If so then it’s a wash for either method just based on that.

[finity]

@aceindy

and entity_id’s are uniquely generated and cannot be re-used ever

that’s not correct.

it’s true that they are uniquely generated but I can re-use the old entity_id on a new device as long as I remove the old entity_id (by removing the old device) first. I just need to go to the device configuration and select the entity and change it to match the old one there.

that’s the reason it’s better to use entity_id’s instead of devices since entity_id’s can be reused where device_id’s can’t.

[Stiltjack]

@finity

But a question it brings up tho is if an unavailable entity will also disable an automation that uses it? If so then it’s a wash for either method just based on that.

I don’t think it’s the same. An automation that depends on a device id will be disabled if the device is unavailable. If an entity is unavailable the automation will still be enabled, and the outcome will depend on the function of the entity in it. It may never run, for example, if the state of the entity is the trigger. If the state of the entity is part of a condition, it may stop or take the wrong path. Unavailable (and unknown) are valid states.

Edit: But actually, the OP was asking about automations that stop working - so this is probably a red herring. My fault, sorry.

[finity]

yeah, so much changes so fast it’s hard to keep up with how things break or not. Even for us seasoned users. I can’t imagine trying to be a new user who doesn’t have their sea legs with HA and trying to deal with the constant barrage of (sometimes undocumented) breaking changes.

it just seems that no matter how much things are changed to try to “make it easy” for new users it still just makes things more confusing to the point that even seasoned users have a hard time figuring things out sometimes.

[0verEngineer (Julian)]

Thanks a lot, thats exactly what i needed, the named entity_id is the best way to do things because stuff can be renamed.

For the people saying if a device goes offline the automation will be disabled, my devices were not offline and the automation was still enabled but it did not work (i had this multiple times and only with devices). When i delete and recreate the exact same automation it did work again.