Why do components implement Device Actions and Service Calls -- one seems more useful than the other?

I’m looking through the core architecture a bit to eventually build something myself, and I can’t find anything on the difference between services and actions . For example , the light platform has [turn_on, turn_off, toggle] services, but also flash and increase/decrease_brightness actions. Services seem more useful, as I can explore them through REST…so what’s up with actions, and when should I use one or another in a component?

Device actions were only added relatively recently. The aim was to make it easier for beginners to write automations. They have a couple of drawbacks though.

  1. You can’t easily replace a device without changing the device id everywhere it has been used. If however you have only used service calls you can just change the new entity id to match the old one in one place.

  2. Once beginners start doing more advanced automation they find that device actions do not support templating. This is a constant support question.

2 Likes

Thank you! I’ll see if I can port the two light-actions over to services; that should be a nice warmup-exercise (famous last words…).

-Volker

1 Like

That’s going rather well; gonna consider the other two operations next:

Configuring the build-environment (or rather realising that I should just run everything manually the good old fashioned way) was the largest time-sink.

-Volker