Device turn on vs call service

Configuration
1

When making automation is one better to use than other
here is an example of 2 different approaches to turn on light just wondering if I should be using one more than the other. especially for speed example when using it based on a trigger of motion detection
Just curious…

 action:
  - type: turn_on
    device_id: c602511ff41c472e82a008ef152b5088
    entity_id: light.basement_light
    domain: light

vs

 action:
  - service: light.turn_on
    data: {}
    entity_id: light.basement_light
2 Likes
2

Found this post as I have the same question. Does one work better than the other?

3

The traditional way of changing the value of an entity’s state is by using a service call.

  - service: light.turn_on
    entity_id: light.basement_light

It also lets you template the entity_id option for the situation where you need to compute which entity, or entities, will be used.

A recent addition is the Device Action. Device-oriented operations were introduced to allow a user to use the UI to explore a device’s entities and the actions that can be performed with those entities. To achieve all of that, the Device Trigger, Device Condition, and Device Action were developed. All were designed to be used via the UI as opposed to manually, in a text editor. For example, the device_id is not something easily found (it’s located in a hidden file) and even less convenient to type out manually. However, no one expects a user to do that; the UI finds it for them.

Although Device-oriented operations are created via the UI, they are stored as YAML. That’s what you see here:

  - type: turn_on
    device_id: c602511ff41c472e82a008ef152b5088
    entity_id: light.basement_light
    domain: light

However, you’re not supposed to modify a Device Trigger/Condition/Action manually. I’ve seen users attempt to add templates to it with predictable results (failure). If you find yourself editing it, you need to use something other than a Device-oriented operation.

As for performance, I doubt there is any meaningful difference.

FWIW, I never use the UI to compose automations or scripts so nothing I have employs Device Trigger/Condition/Action.

5 Likes
4

Old thread, I know, but a related question around this topic:

I have these 2 automation actions, and they seem do the same thing: to turn on a light switch. I read it somewhere that switching entities is recommended, but why?

service: switch.turn_on
data: {}
target:
  entity_id: switch.master_bath

service: switch.turn_on
data: {}
target:
  device_id: b176bf4397827c5d824fd9470b0d5b69
5

Because entities are predictable. If a device fails, you can replace the device and change the new device identity_id to the old one, and your automations, dashboards, history, … all remains unaffected. However, the new device will have a new device_id, and that is impossible to change.

2 Likes