Does device_id matter?

Where are you seeing these device_ids? None of my UI-created automations has a device_id. Could you paste an example?

Each UI-created automation has its own id, which is nothing more than a timestamp (it’s the number of milliseconds since 1 Jan 1970, obviously :smile: ) but I don’t believe these are critical to maintain.

If you use the automation editor, using device automation, it uses a device_id :

- id: '1571986271394'
  alias: Gang boven
  description: ''
  trigger:
  - device_id: f31d637f702643d389977c4e1dc5a6a3
    domain: binary_sensor
    entity_id: binary_sensor.ikeapirboven_occupancy
    platform: device
    type: motion

and they can change, so it is best to use a state trigger instead op a device trigger.

Yeah, I never got why they needed to add the device_id in for device automations.

It makes even less sense now that I know the device_id isn’t persistent based any hardware specific information.

That makes perfect sense.

  • Add a device and Home Assistant will assign it a unique device identifier.
  • Remove the device and Home Assistant will discard the device’s identifier.
  • Add the same device again and Home Assistant will assign it a unique identifier (i.e. it won’t be the same one).

I’m not sure why Device Automations include the device_id because the entity_id seems to be sufficient to identify what is being monitored for state-changes. Nevertheless that’s how it’s currently done (and makes it impractical to create one manually in YAML)

Expect to be using more Device Automations in the future. I recently learned that all new integrations can no longer generate events but must use device_triggers.

Whereas it is fairly easy to create an event trigger in YAML, it’s far more challenging to do that for a device trigger, mostly because it needs a device_id. The only way you can find this value is by looking in .storage/core.device_registry (or creating a Device Automation via the UI and examining the YAML it generates).

WTF?

That sounds suspiciously like the death knell for yaml automations, that we were continually promised would never happen.

Guidance to the developer of the upcoming UPB integration given here:

and reported by the developer here:

HANG ON A SEC!!

All this time I don’t even know about device_triggers???

Where are they documented because they aren’t here:

If being extra stupid here, be kind…

Like most things related to the UI the docs for it are virtually non existent:

They were introduced a long time ago but, if you’re like me and don’t create automations via the UI, they’re easy to overlook. The documentation is quite clear that they weren’t designed to be created manually:

Device automations are meant to be configured via the UI.

The principal is sound because the device reveals (via the UI) what are its triggers thereby simplifying the creation of automations. However, creating a YAML version of it manually, although not impossible, is challenging because of the cryptic nature of the device_id.

Should I then start using device triggers instead of event triggers? It seems event triggers are easier because I can just paste the automations.yaml into the file in the event that my system crashes and I have to redo my automations. If I were using device_triggers, then I have to figure out what the new device_id is.

If you create device automations and have to replace your device (faulty, stolen,etc…) do all the automations associated with that device get deleted with it?

The automation doesn’t get deleted but part of the automation that uses the device_id disappears.

So the automation won’t work?

It won’t work.

I would not do that. From what I understand, integrations that currently generate events will continue to do that (it won’t be removed). It’s only new integrations that are required to use device_triggers, not events.

However, if have a need to add/remove devices then automations that use event triggers are better suited to your situation. As you have already discovered, device_ automations, that rely on device_triggers, fail to work when the device is assigned a new device_id.

If you slowly gnaw away at the edges, eventually you get to the center, and then there’s nothing left.

FWIW, I think we both know that people are noticing this creeping change. Frankly, I don’t mind it if it introduces improvements (like eliminating the need for restarts or even reloads). However, it has been a mixed bag of wins and misses so far.

1 Like

I think I’ll slowly remove myself from providing support here, if they continue with what they are doing recently… I’ll continue to use Home Assistant, but providing help to newbies from screenshots of their UI automations, no thanks.

7 Likes

I know someone who was quite prolific already has.

2 Likes

I think I know who you mean.

I don’t even try to learn from code snippets posted here that are from that god-awful UI Automation Editor. Let alone try and help (stop sniggering at the back, it has been known).

It took me a while to even work out what a device_trigger was as the code that was presented here was from the UI editor.

https://community.home-assistant.io/t/yaml-being-put-to-death-by-a-thousand-cuts/194883

2 Likes