Background
When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list.
It works... but it is not a the best way to start because it is storing up problems for the future. Far better to use an entity, with state or numeric_state.
This topic is part of the community-driven cookbook where you can find other topics you might be interested in or might like to contribute to.
Device_id problems
-
The yaml will be longer and harder to follow, which may make maintenance difficult, especially a few months down the line when you have forgotten the details. For the same reason, sharing code (on this forum, for example) is harder. Since you can't add comments to automations each step needs to be as clear as possible. Why have this:
trigger: - type: battery_level platform: device device_id: 16fbcd84302f4606819c58559aa90c82 entity_id: 6c2e634686ebe58e571fefcdd6474f22 domain: sensor below: 20When you could have this:
trigger: - platform: numeric_state entity_id: sensor.mobile_battery_level below: "20" -
If you replace a device you will have to go through every automation it appears in, changing the device_id. If you only ever use entity_ids in your triggers, conditions and actions, then when you have to replace a device you can change the new entity_id to match the old one in one place, and all your automations keep working. Your long-stats will also remain intact.
-
Automations using device_id report as unavailable if they depend on missing devices.
-
Using entity states you can exclude "unavailable" and "unknown" from your triggers:
trigger: - platform: state entity_id: button.EXAMPLE not_to: - unavailable - unknown not_from: - unavailable - unknown -
Device actions, triggers and conditions do not support more advanced features like templating.
Devices and entities
So entity ids are preferable to device ids. What's the difference?
Essentially devices, often physical objects, are containers for a group of related entities. The entities are the functions or services the device provides.
For example, a Philips Hue motion sensor is a device which acts as a container for seven entities.
-
Three of the entities are sensors (temperature, light and motion). The temperature and light sensors have a numeric state; the motion sensor is binary - its state will be either "on" or "off".
-
Two are switches allowing light and motion sensors to be switched on and off; these are also binary.
-
Two are diagnostic (battery level and zigbee connectivity). The battery level sensor will have a numeric state; the zigbee sensor will have a state such as "connected".
While all devices have associated entities, an entity does not have to belong to a device. For example, you might want to have a binary sensor that was "on" when your phone was connected to your home wi-fi and otherwise "off", even if it was connected elsewhere. In this case you could create a template sensor, derived from, but not part of the device:
template:
- binary_sensor:
- name: "phone on wifi"
state: >
{{ is_state('sensor.mobile_wifi_connection', 'MyNetwork') }}
In addition a great many entities are created by integrations that have nothing to do with any device:
A few entities are not part of a device or service. Examples of standalone entities are automation, script, scene entities, and helper entities.
States
Numeric state triggers are for anything you can count. Both binary sensors and non-numeric sensors use State triggers and conditions (binary sensors will just be "on" or "off").
Unfortunately, in an effort to make the UI more friendly, some developers have introduced substitutions. In the Philips Hue example above, for example, the motion sensor will show as either "Clear" or "Detected" in the UI.
But it's a binary sensor, and if you look at the yaml it will always be "on" or "off":
trigger:
- platform: state
entity_id:
- binary_sensor.yard_motion_sensor_motion
from: "off"
to: "on"
If you write in yaml, "on" and "off" are the states you have to use. Note too that in the UI all the states have an initial capital letter; in yaml they should be lower case. If you need to check which states you should be using, go to Developer Tools | States:
Buttons
Having said all that, buttons are an oddity. They do not have a state. A button press is an event - it doesn't remain on or off. The entity does, however, retain a timestamp showing the last time it was pressed and this becomes its state, allowing it to be used as an automation trigger when it changes.
Then do...
To avoid device ids in the "Then do" section of an automation, choose other actions and perform action from the dropdown lists.
Most action names begin with the device class - light, switch, media_player etc. - followed by the action - turn on, turn off, play, pause, etc.
You will then be invited to select one or more target entities.
Changing the entity name on a new device
If you replace one of your devices, say the motion sensor mentioned above, you can change the names of the entities associated with it to the names you have already used in your automations, saving yourself a lot of work. Go to Devices & Services | Devices and select the device. For each of the entities in turn, click on the name, then on the cogwheeel "settings" icon top right.
You can edit the Entity ID field to match the entity ID from the old device.
Consider Using Groups
Even if you currently have only a single sensor, it can be worth creating a group from the start. While it may seem unnecessary at first, the group acts as an abstraction layer that allows you to add, remove, or replace sensors later without needing to modify any automations that depend on it.
For example, you might initially have a single motion sensor covering a room. If you later discover a blind spot and add a second sensor, you can simply add it to the existing group. The automation continues to reference the same group entity and requires no changes.
The group will show up as an entity, so if you only access sensors (in automations) through groups, they will be accessed as entities.
Groups can also be used for other device types (lights, fans, etc) so you may want to consider grouping them as well, however in practice (in a given room), I typically only have multiple sensors and lights, I use scenes for managing lights, so only my sensors are grouped.
. Guide updated, thanks…
