Deprecate "Device" actions (and triggers)

Feature Requests
1

When building an automation you can turn on a light using either a Call service → Light: Turn on action or a Device → Turn on action. The Device action however has severe drawbacks:

  • Because of its fitting name, one might think that Device → Turn on is the correct action to turn on a light, but in reality it doesn’t support most of the parameters like light color, brightness, transition and so on. This severely hurts the discoverability of those features.
  • Generally in Home Assistant the Entity ID is the rendezvous point by which the state core, the Lovelace UI, recorder, MQTT etc. meet. If you create a card or an automation with an Entity ID that currently doesn’t exist and you then add a device that Entity ID, the card or automation will pick up that entity. Regardless of whether that is a good thing or not, it is how it is and it is implemented consistently except for those Device actions (and triggers) which use some kind of opaque device_id and discovery_id. It is undocumented what happens if those two don’t match. It also makes copy&paste more difficult.

In an attempt to make the creation of automations much less confusing I propose to deprecate the Device actions and triggers and to remove them from the dropdown lists.

2

I respectfully disagree. There are plenty of times when a simple Device action is sufficient. Also, it can be easier and clearer to read the automation that way than with a Call Service.

3

But why is it better to have fewer options? All it does is make you wonder why the heck you can’t set the color right now.

I agree that it would be even better if the Device action could do all the things like setting color and changing brightness and then to remove the slightly strange Call service → light.turn_on syntax, but that’s a much more difficult change than to simply remove the confusing extra action type.

Why is it confusing? Because in order to understand what they do you first have to understand what the difference is between the two. And as you can see I haven’t understood what the different use cases are.

This can’t be true.

If you’re talking about the YAML the Device one is currently longer and less clear because of those weird IDs I mentioned.

If you’re talking about the GUI, well…

image

1 Like