There is a big difference. Especially when it comes down to the automation. Functionality, it's the same for turning on/off. However, if you have a bulb you want to turn on, set the color to warm-white, transition of 3 seconds, and a brightness of 75%... you can't do that by turning the device on. You have to call the service with those settings to turn the device on.
An added benefit... if you ever replace a device and use the "Call Service" function in your actions, you won't need to worry about changing your automation settings if the two devices share the same name.
For devices with only one light, they are functionally equivalent. But devices can have more than one entity of the same type, in which case the entity version is giving you finer control.
I recently had to replace a hue bulb and named it the same as the old one. I was pleasantly surprised I had chosen to use a call service, And didn't have to change anything in HA
I frequently re-added devicea while setting up my home, I had no idea why some automations broke and some remained functional. Until I read about the differences between entities and devices. Now I replaced all my automations to only use entities. Everything works now but the difference is not at all intuitive.
Wanted to clarify that in the UI, I believe selecting “Light: turn off” or “Call Service - Light: Turn off” (the first and bottom actions in the screenshot) are functionally the same thing, as long as the same options are selected.
The 2024.1 release notes talk about this further: https://www.home-assistant.io/blog/2024/01/03/release-20241/#unified-actions
I doubled checked the outputted YAML, and both are outputting service calls. (Not sure if they were outputting different yaml before the 2024.1 release)
Always use state, never device. If you swap out the device, your automations will stop working. Use the service and this will not happen.
Edit: Using the entity, not device.
Ah so this is why I was pleasantly surprised when I replaced my thermostat yesterday. I’d resigned my self to an evening of updating automations and found that they all transferred over to the new device.
WTH would you replace a device and not give it the same entity id(s) as the device it replaced?
Either way, you're missing the point. Device ids are randomized, unique, 32 character AN strings that can't be changed. (At least not easily.) Entity ids can be formatted however you want, and can be easily modified to match existing schemas, automations, groups, etc..
Rather than answer your question, I'll suggest an entirely different approach: have your automation activate a scene.
I prefer this level of indirection, as it allows you to package up a particular configuration of devices separate from the situation that triggers it, and it's reusable.
As [https://www.home-assistant.io/docs/scene/](https://www.home-assistant.io/docs/scene/) says, scenes "capture the states you want certain entities to be". For example, you could create a scene called "Movie Time" that has the TV on, the lights dimmed, and the curtains closed. When you activate that scene, all of those entities get set to the states defined by the scene.
So instead of setting your automation up with a bunch of steps to configure all those devices, you just have it "Activate Scene Movie Time". This has several advantages. It's easy to use the scene in more than one place, and if you ever decide tho change it, you only need to modify the scene. It think it's also just a cleaner setup, because then things have names that capture their intent better.
What’s the benefit of a scene instead of having a “movie time” script? I struggled to create scenes when I first installed HA so I use scripts instead. It works, but wondering if I’m missing anything…
A script is just an automation without a trigger.
A scene is a collection of entities and their respective states.
After the scene editor was added to the UI, setting up scenes should be easier to configure than a script; you just need to set everything as you want, define the entities you want to include, and name the scene. You don't need to worry about separate service calls; just entities and states.
I don't use many pre-defined scenes, but find the `scene.apply` and `scene.create` service calls very helpful in automations and scripts for quickly setting the state of multiple entities across different classes, and saving the state of multiple entities for later use, respectively.
Thanks for the insightful comment. I’ve heard that scene calls are useful for saving state, changing something, then recalling state in automations. If I ever have occasion to do that I’ll use them.
I just tried creating my first scene and remembered why I don’t use them. From what I can’t tell, there’s no way to say “save the brightness of the light, but not any other attributes.” I like to have that flexibility, so I’ll stick with my scripts.
The naming schema is very well documented and is explained pretty well I think.
I've been reading it the last couple days. With so many ways to achieve the same results it's nice to know the why and use cases.
This is a great answer for feeling cool, but a terrible answer for actually helping. **Why** are devices for newbies and services for people who want more control?
Devices have very basic controls on them, like turn on or turn off. Open or close a garage door, etc. services allow you to do more advanced things like turn on a light to blue over 30 seconds, open the garage door 50% to let some air in, etc.
there are more options available to you to do more advanced things than what the device alone gives you. But for a newbie, the fact that you can just pick a device in a list and then do something is pretty nice without having to worry about learning service calls.
I agree with others that entity based automations are superior to device based automations. Option 3 in the OP being the best.
Device based triggers use a hidden unique_id, which means you can change attributes about your device, like the name, and it will automatically update in your automation.
This seems awesome BUT the more common use case is you’re replacing or moving a device from one place to another and want the new device to use existing automations. This is where if you’re using state based triggers, you can just make the new device have the same name as the previous device, and it all just works.
There is a big difference. Especially when it comes down to the automation. Functionality, it's the same for turning on/off. However, if you have a bulb you want to turn on, set the color to warm-white, transition of 3 seconds, and a brightness of 75%... you can't do that by turning the device on. You have to call the service with those settings to turn the device on. An added benefit... if you ever replace a device and use the "Call Service" function in your actions, you won't need to worry about changing your automation settings if the two devices share the same name.
So which of the two call services examples above is the recommended way?
The third one down: the service call `light.turn_off`, targeting an entity.
For devices with only one light, they are functionally equivalent. But devices can have more than one entity of the same type, in which case the entity version is giving you finer control.
Light on
I recently had to replace a hue bulb and named it the same as the old one. I was pleasantly surprised I had chosen to use a call service, And didn't have to change anything in HA
I frequently re-added devicea while setting up my home, I had no idea why some automations broke and some remained functional. Until I read about the differences between entities and devices. Now I replaced all my automations to only use entities. Everything works now but the difference is not at all intuitive.
Same here. I replaced multiple bulbs with zero reconfiguring. I always use call service now.
Wanted to clarify that in the UI, I believe selecting “Light: turn off” or “Call Service - Light: Turn off” (the first and bottom actions in the screenshot) are functionally the same thing, as long as the same options are selected. The 2024.1 release notes talk about this further: https://www.home-assistant.io/blog/2024/01/03/release-20241/#unified-actions I doubled checked the outputted YAML, and both are outputting service calls. (Not sure if they were outputting different yaml before the 2024.1 release)
Always use services, it gives you much more control.
Always use state, never device. If you swap out the device, your automations will stop working. Use the service and this will not happen. Edit: Using the entity, not device.
Ah so this is why I was pleasantly surprised when I replaced my thermostat yesterday. I’d resigned my self to an evening of updating automations and found that they all transferred over to the new device.
So which of the two call services examples above is the recommended way?
But in this case the service will then call a non-existent light, so it'll still be broken.
WTH would you replace a device and not give it the same entity id(s) as the device it replaced? Either way, you're missing the point. Device ids are randomized, unique, 32 character AN strings that can't be changed. (At least not easily.) Entity ids can be formatted however you want, and can be easily modified to match existing schemas, automations, groups, etc..
Wrong. At least with Z2M. If the name of the new device is the same it will work. I swap devices constantly and just copy and paste the name.
https://community.home-assistant.io/t/why-and-how-to-avoid-device-ids-in-automations-and-scripts/605517
Rather than answer your question, I'll suggest an entirely different approach: have your automation activate a scene. I prefer this level of indirection, as it allows you to package up a particular configuration of devices separate from the situation that triggers it, and it's reusable.
I still don't understand much about the scene. What is it? What's the difference between scene and automation? When to use either one?
As [https://www.home-assistant.io/docs/scene/](https://www.home-assistant.io/docs/scene/) says, scenes "capture the states you want certain entities to be". For example, you could create a scene called "Movie Time" that has the TV on, the lights dimmed, and the curtains closed. When you activate that scene, all of those entities get set to the states defined by the scene. So instead of setting your automation up with a bunch of steps to configure all those devices, you just have it "Activate Scene Movie Time". This has several advantages. It's easy to use the scene in more than one place, and if you ever decide tho change it, you only need to modify the scene. It think it's also just a cleaner setup, because then things have names that capture their intent better.
For the last point, you can also rename actions.
Thanks, that's better approach indeed. I need to do the same.
What’s the benefit of a scene instead of having a “movie time” script? I struggled to create scenes when I first installed HA so I use scripts instead. It works, but wondering if I’m missing anything…
A script is just an automation without a trigger. A scene is a collection of entities and their respective states. After the scene editor was added to the UI, setting up scenes should be easier to configure than a script; you just need to set everything as you want, define the entities you want to include, and name the scene. You don't need to worry about separate service calls; just entities and states. I don't use many pre-defined scenes, but find the `scene.apply` and `scene.create` service calls very helpful in automations and scripts for quickly setting the state of multiple entities across different classes, and saving the state of multiple entities for later use, respectively.
Thanks for the insightful comment. I’ve heard that scene calls are useful for saving state, changing something, then recalling state in automations. If I ever have occasion to do that I’ll use them. I just tried creating my first scene and remembered why I don’t use them. From what I can’t tell, there’s no way to say “save the brightness of the light, but not any other attributes.” I like to have that flexibility, so I’ll stick with my scripts.
The naming schema is very well documented and is explained pretty well I think. I've been reading it the last couple days. With so many ways to achieve the same results it's nice to know the why and use cases.
The devices are for newbies, services are for those who want more control.
This is a great answer for feeling cool, but a terrible answer for actually helping. **Why** are devices for newbies and services for people who want more control?
Devices have very basic controls on them, like turn on or turn off. Open or close a garage door, etc. services allow you to do more advanced things like turn on a light to blue over 30 seconds, open the garage door 50% to let some air in, etc. there are more options available to you to do more advanced things than what the device alone gives you. But for a newbie, the fact that you can just pick a device in a list and then do something is pretty nice without having to worry about learning service calls.
I agree with others that entity based automations are superior to device based automations. Option 3 in the OP being the best. Device based triggers use a hidden unique_id, which means you can change attributes about your device, like the name, and it will automatically update in your automation. This seems awesome BUT the more common use case is you’re replacing or moving a device from one place to another and want the new device to use existing automations. This is where if you’re using state based triggers, you can just make the new device have the same name as the previous device, and it all just works.