That was helpful, for me at least, in understanding how that works.
And in turn it has me appreciate the Watchman integration even more, and thought the integration deserved a mention in for those even greener than I am with HA, in this regard.
Watchman is a great help in there.
Also there other benefits to use device_id as this will be used by HA in some parts of the code like in logbook apparently (I’m just repeating info that I got from the forum).
Check my Feature request if you are interested:
1 Like
When you onboard a new device you should first give it a sensible name. If you’re renaming after you’ve started using it, that’s a different matter, but you likely will only have to do the search and replace once ever (assuming it gets a proper name the second time around). If you replace a device you will have to rename the usages every time you replace a device, as opposed to renaming device entities.
1 Like
Renaming entities is a choice, if you do not, automations will work, if you do change them, it is exactly the same amount of work as changing device IDs.
The biggest dealbreakers using device ids for me are:
- I had integrations suddenly changing all device id’s, breaking all automations. Then there’s no help what changed to what, because old id’s no longer exist. Automations using entity ids did not break.
- If a device breaks that is used in a trigger, the whole automation is disabled, even if there are more triggers that could have still worked perfectly. Entities don’t have that problem.
- Device conditions/triggers are hard to get support on from others here, because the behavior and actions are specific to the device.
- When a device breaks or is replaced by something else: entity - no problem, with device ids: always needs fixing everywhere. It is not even a given that just search/replace the device id will work across different brands/integrations.
5 Likes
How to avoid device_id for scene controller?
I have a Z-Wave button, or really a “scene controller”, that I use to turn on a pump. If I use the UI to create an automation for scene 002:
The resulting action looks like this, which does trigger:
trigger:
- platform: device
device_id: f381791969ec48f1a1405bfe1f9f39b0
domain: zwave_js
type: event.value_notification.central_scene
property: scene
property_key: "002"
endpoint: 0
command_class: 91
subtype: Endpoint 0 Scene 002
Here’s the entity for that scene:
I can test state like this, but that only triggers on the attribute changing – yes, it will trigger if I first press the button 2x times to set KeyPressed2x, but if it is already KeyPressed it won’t trigger since it’s not changing.
trigger:
- platform: state
entity_id:
- event.recirc_pump_remote_switch_scene_002
attribute: event_type
to: KeyPressed
I tried using an event trigger like this, but it’s not triggering. Plus, I’m wondering if triggering on such a frequent event is a bad idea.
trigger:
- platform: event
event_type: state_changed
event_data:
new_state:
entity_id: event.recirc_pump_remote_switch_scene_002
attributes:
event_type: KeyPressed
Is there another approach?
Here’s what the event looks like:
event_type: state_changed
data:
entity_id: event.recirc_pump_remote_switch_scene_002
old_state:
entity_id: event.recirc_pump_remote_switch_scene_002
state: "2024-06-09T17:39:03.528+00:00"
attributes:
event_types:
- KeyHeldDown
- KeyPressed
- KeyPressed2x
- KeyPressed3x
- KeyPressed4x
- KeyPressed5x
- KeyReleased
event_type: KeyPressed
value: 0
friendly_name: Recirc Pump Remote Switch Scene 002
last_changed: "2024-06-09T17:39:03.528460+00:00"
last_reported: "2024-06-09T17:39:03.528460+00:00"
last_updated: "2024-06-09T17:39:03.528460+00:00"
context:
id: 01HZZ1A3784S14M58679N86CM9
parent_id: null
user_id: null
new_state:
entity_id: event.recirc_pump_remote_switch_scene_002
state: "2024-06-09T17:47:41.061+00:00"
attributes:
event_types:
- KeyHeldDown
- KeyPressed
- KeyPressed2x
- KeyPressed3x
- KeyPressed4x
- KeyPressed5x
- KeyReleased
event_type: KeyPressed
value: 0
friendly_name: Recirc Pump Remote Switch Scene 002
last_changed: "2024-06-09T17:47:41.061750+00:00"
last_reported: "2024-06-09T17:47:41.061750+00:00"
last_updated: "2024-06-09T17:47:41.061750+00:00"
context:
id: 01HZZ1SWM57FP2QKQH328A7YWF
parent_id: null
user_id: null
origin: LOCAL
time_fired: "2024-06-09T17:47:41.061750+00:00"
context:
id: 01HZZ1SWM57FP2QKQH328A7YWF
parent_id: null
user_id: null
trigger:
- platform: state
entity_id: event.recirc_pump_remote_switch_scene_002
to: null
condition:
- condition: state
entity_id: event.recirc_pump_remote_switch_scene_002
attribute: event_type
state: KeyPressed
this would be a solution.
But I would combine all actions for each event type in one automation using choose
The most usual reason for me to change a name is that I am repurposing the device, so I actually find it useful that it breaks stuff noticeably when I rename - as of course I need to edit those to accept the replacement device. I tried leaving the entity names as they were but I find it impossible to recognise which one to use unless they bear the name of their parent device - as it has become.
1 Like
I think this post should not be pinned. It’s a good post, but not important enough for all users to follow.
Disclaimer: I’m not saying anything in the guide is wrong (since the author obviously knows his stuff). I’m only challenging the relevance. Maybe this discussion will lead to firther improvements to the article or at worst, I learn that my assumptions are wring. I’ll take a bit of an oppositie opinion here and there with the expectation to end up in the middle.
Why this post should not be pinned (opinions)
- I think beginning users should use devices more often. This posts scares them down a more difficult path.
- The guide hides other pinned posts from the front page which are more relevant to a larger number of users.
- It deserves a prominent place in the cook book, but it’s not the first thing every users should read.
Let’s go through the arguments:
-
The yaml will be longer and harder to follow…
This is only relevant if you use yaml primarily. For UI users, using a device is often easier to use and follow.
Looking at the majority of users, +1 for “using devices”. -
If you replace a device you will have to go through every automation it appears in…
True, but the same can be said in favor of devices to avoid updating when renaming an entity (which I do more often than replacing devices)
I can’t say which scenario is more common in general, so let’s call it a tie. -
Automations using device_id report as unavailable if they depend on missing devices.
This could be an important argument, but the impact is not explained. Will the automation not work?
It’s inconclusive for now, but could be a + for “not using devices”. -
Using entity states you can exclude “unavailable” and “unknown” from your triggers:
This is a good suggestion to make automations more robust, but how many people actually use it? Beginners should know when to use it, but in a lot of cases, it won’t be relevant.
+1 for knowing “when to use devices and when to use entities”. -
Device actions, triggers and conditions do not support more advanced features like templating.
As.abive, it’s not a reason not to use devices, but it might be a reason to know “when to use devices and when to use entities”.
To summarize:
- Devices are great, especially for beginners
- Entities are great for advanced users
The way the article is currently positioned, it discourages beginning users from using devices. It would be better to change some of the working to emphasis when to use entities instead of devices and targeting the moderate users through a prominent place in the cookbook instead of the top pinned article in community guides.
Until it breaks down and needs to be replaced by a new one…
7 Likes
I disagree. It’s worth the pin.
You need to consider the other side of the coin too: Reading YAML and helping people using device IDs are harder — and I say this as an experienced user.
“Help us help you.”
It really isn’t that hard to grasp the concept of entities being the core concept and that devices are basically a grouping of entities.
It’s such a foundational cencept that it is unlikely to change ever, I think. It’s better to make the shift earlier before having to rewrite lots of things later.
8 Likes
Very much worth the pin.
Almost all of the problems I’ve had with automations has stemmed from using devices early on in my HASS experience. Things stopped working without any notification. All because I changed batteries on a few sensors and the new devices (obviously) got new device_ids.
2 Likes
How did changing batteries cause issues with automations exactly?
Perhaps an issue with the specific integration creating new device IDs?
Either way, this is a real problem when people do replace devices, say a blown smart bulb with a new one: It will be a new device, compared to just renaming and entity and you’re done.
2 Likes
This is all fine and good, until you use Zigbee switches (buttons, not relays) in ZHA. They don’t have entities except battery etc. So you are stuck on using event triggers and you have the choice of either device_id, unique_id or device_ieee.
That type of issue will likely be addressed by the use of event entities if/when they get added into ZHA. Like a lot of new features in HA, it was discussed and implemented; but it takes time and resources to add those features to each of the 2000+ core integrations as needed.
IIRC, ZHA has already been undergoing some significant updates, so it likely the case that those are taking priority over adding event entities.
1 Like
I see that was merged in July '23, I must have been on vacation then or so. Anyway, I don’t think any of my devices use event entities yet, I haven’t encountered them yet
So, with current move of Z2M to abandon button and switch action states a lot of people got forced to switch over to triggers.
Fun part is that triggers use device_id and when switching from one coordinator to another ALL DEVICES get different device_id … isn’t that great ? Not only one has to disconnect their devices from old coordinator to a new one, but also go through all the automations and node-red graphs and make sure that everything is updated.
HOW GREAT IS THAT ?!
Sorry guys, but it looks like hass decided to take all the seasoned users and take them behind the shed …
THANKS.
In version 2.0, the Z2M project has aligned itself with the Home Assistant project’s preference for modeling a remote-control.
Instead of using a sensor entity to report button events, the preference is to model the remote-control as a device, so that the device’s button events are self-documented and can be referenced directly by an MQTT Device Trigger.
In addition, the button events can be optionally modeled as event entities (which also document all available button events). Z2M also supports event entities and they can be used in a State Trigger. Here’s an extensive explanation of how to use event entities.
Lastly, one can use an MQTT Trigger to subscribe directly to a button’s MQTT topic. However, one loses some of the additional functionality provided by MQTT Device Trigger and event entities (for example, the button’s previous event).
2 Likes