Automation actions, calling service vs triggering a device. Which is better?

Configuration
1

Like the title says, calling a service vs triggering device action, which is a better choice for automations and why.

Example


  - service: cover.close_cover
    data: {}
    target:
      area_id: garage
  - device_id: 0afe055f30c08e29a7bc92de5bc592ec
    domain: cover
    entity_id: cover.left_garage_door
    type: close
2

Service and entity_id over device every time.

Consider the case where you have a physical device fail and have to replace it.

It will have a new device_id, which you cant change. All your previous automations, scripts and scenes that used the old device_id no longer function. You need to do a “find and replace” in the yaml configuration for all instances where the old device_id was used and replace it with the new one.

If you only ever used entity_ids in your automations, scripts and scenes then all you have to do is change the new entity_id to match the old one. In one place. The entities list, or device page.

Also you can use templates in service calls but not device actions.

2 Likes
3

So actually this changed a bit. I also used this argument against device actions for a long time but it turns out ha did something about it at some point.

At some point Ha started keeping track of recently removed devices and if the same integration tries to create a device with the same identifier and connection info HA gives it the exact same device id. Give it a shot, it’s pretty easy to test with Mqtt for example. Discover a device, capture it’s id, delete it then rediscover. You’ll find you have the same guid.

I still lean towards services though for a couple reasons:

  1. it’s a lot easier to use services then device actions when writing yaml. You basically have to configure device actions in the UI and copy and paste.
  2. device_id doesn’t accept a template. Makes it difficult to use in a number of places, like loops for example.
  3. I don’t know when the device id can and cannot be restored since it depends a bit on the integration (like in your use case for example). So that makes me a bit wary of relying on it without additional research.

So I’m not disagreeing with you but did want to note that one of the strongest arguments against device actions did actually get worked on at some point (device IDs being quite transient). Which makes me a bit more open to them.

1 Like
4

I can see that working for deleting and replacing the same device.

Will a new device have the same identifier though?

What if you were an early adopter and had V1 of some device that has developed a fault (or was stolen) but only V3 type devices are available now?

5

Probably not but that was kinda my point #3 - it depends on the integration. If it uses identifiers that remain the same then you should get the same id.

But there’s not really a way to know that without digging into integration internals. And the fact that you’d have to do that then becomes a knock against device actions because that’s not necessary for services and entity IDs.

So yea it’s a good question. And in the end I think the answer is unchanged - entities and services are better if you’re looking for long term stability. But at least now users of device actions can take some comfort in knowing that not all device changes require a major refactor.

1 Like
6

Service calls. :white_check_mark:

Device Action (and Device Trigger and Device Condition) were invented for use with the UI (for Device oriented operations). They weren’t meant to be composed manually. In fact, at the time they were implemented you couldn’t find a device’s device_id unless you searched the contents of a hidden registry file or created a Device Action first and inspected its YAML configuration.

7

I don’t even know what a device is… :wink:

service/entity_id’s all the way down.

8

Eh. I like the ability to individually reload an integration device instance if things aren’t working as expected.

9

Sorry for the bump but I just wanted to add that from an effectiveness perspective when on mobile I have noticed, after reading this thread and testing, that using services is way easier for my Z-Wave devices.

Instead of first finding and selecting the device and then scrolling through endless of Z-Wave options to find the “turn on” action you just select the appropriate service and when searching for the entity you will only be presented with the entities that you can actually “turn on” and not your PIR sensor or whatever.