Does device_id matter?

[czrabode]

Hello. I noticed that when creating automations using the web interface that each device is assigned a device_id that is separate from entity_id. What is this number for?

I noticed that when I remove my devices from Home Assistant and then add them again and create automation, a different device_id is assigned. The entity_id stays the same. Why is this? Is this going to be a problem?

I am asking because I wan’t to back-up my automations by just saving the YAML file. Then if I ever need to restore my automations, I can just paste the YAML file back. But I’m concerned that for the same sensor, the device_id will be different between automations written before the restore and automations written after the restore.

[Troon]

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 ) but I don’t believe these are critical to maintain.

[francisp (Francis)]

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.

[finity]

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.

[123 (Taras)]

@czrabode

when I remove my devices from Home Assistant and then add them again and create automation, a different device_id is assigned .

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).

[tom_l]

@123

I recently learned that all new integrations can no longer generate events but must use device_triggers.

WTF?

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

[123 (Taras)]

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

bdraco

and reported by the developer here:

UPB lighting

Update here… The pull request to put the lights into hass should be approved today. Since pull requests are to be broken up, scenes are next up. There is a breaking change for lights (perhaps more than one, I can remember one). That is update_status is removed. It is replaced with homeassistant.update_entity. There will be breaking changes for scenes. upb.activate is removed in favour of scene.activate. The second breaking change, so far, is that event will no longer be used. They are not all…

[klogg]

HANG ON A SEC!!

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

Where are they documented because they aren’t here:

Automation Trigger

If being extra stupid here, be kind…

[tom_l]

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

Device Automation

[123 (Taras)]

@klogg

I don’t even know about device_triggers???

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.

[czrabode]

@123

I recently learned that all new integrations can no longer generate events but must use device_triggers.

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.

[tom_l]

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?

[czrabode]

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

[tom_l]

So the automation won’t work?

[czrabode]

It won’t work.

[123 (Taras)]

@czrabode

Should I then start using device triggers instead of event triggers?

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.

[123 (Taras)]

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.

[Burningstone]

@tom_l

So YAML really is being removed then.

Just bit by bit so they think we won’t notice.

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.

[tom_l]

I know someone who was quite prolific already has.

[klogg]

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.