Allow scene.create to use device_id instead of entity_id

As topic suggests I think it will be great if scene creations can use device_id (more “persistent”) instead of entities.

Something like this:

- alias: "Window opened"
  - platform: state
    entity_id: binary_sensor.window
    from: "off"
    to: "on"
  condition: []
  - service: scene.create
      scene_id: before
      - xxxdeviceid1
  - service: light.turn_off
      device_id: xxxdeviceid1
  - service: climate.set_hvac_mode
      entity_id: climate.ecobee
      hvac_mode: "off"
- alias: "Window closed"
  - platform: state
    entity_id: binary_sensor.window
    from: "on"
    to: "off"
  condition: []
  - service: scene.turn_on
      entity_id: scene.before

Device IDs are the tool of the devil. Avoid them.

You cant change them like you can entity IDs.

So if you replace a device you have to go through all your automations and scripts and replace the device ID.

With entities you simply rename the new entity to match the old - in one place.

1 Like

I do understand your point but I think the teams in moving more to a db structure via gui. So I think in the future if you change a device maybe you’ll be able to replace it massively also in script and automation without using yaml.

The device registry is a file located in a hidden directory called .storage and its data is in JSON format.

Sounds like pure speculation.

Fact is, if they want to “replace it massively” they can implement that feature now using the existing device registry. However, the disincentive for creating it is that it permits anyone to very easily corrupt the device registry (a file that is purposely hidden to thwart deletion/modification).

A physical device’s identifier is automatically assigned when the device is discovered (by an integration). The identifier, a long string of randomly selected numbers and letters, remains assigned to that device like a VIN (Vehicle Identification Number) and it’s not meant to be modified.

In addition, it was designed for use by the Automation Editor and not by users writing YAML. The same is true for Device Triggers, Device Conditions, and Device Actions.

  1. Device Triggers/Conditions/actions are far more verbose than an equivalent State Trigger/Condition or service call. It makes no difference for the Automation Editor but it does for a user attempting to manually compose one in YAML.

  2. device_id is not revealed in Configuration > Devices (or any other obvious place). To get a device’s device_id you have to use the Automation Editor to create a Device Trigger/Condition/Action and then examine the YAML it generated.

Nothing about using device_id manually in YAML is convenient and that’s because it was meant to be used by the Automation Editor.


Totally agree.

Sorry for the ambiguity.

It was a speculation indeed, my humble speculation.

And maybe another humble speculation is that in the future there will be a way to massive change a target in a automation or a script (now I do replace of the entity id manually using vscode)

In 2021.8.x you can collect a device_id from a entity_id.

Which doesn’t really help much if you have a whole bunch of device triggers or conditions. You’d still have to replace all the device id’s as those keys are not templateable.