Ok, I know I will say “but of course” when I get the answer, but …
I have a Firbar FGPB-101 (AKA “The Button”). I can see it works, but I need the Device ID when I make automation. The is one under the “Z-wave JS” when I expand the info on the item, but my automation doesn’t react to that. So …
Is that the right Device ID when using a zwave_js.value_updated event? In the documentation the example is
Use the Event viewer and watch for an event from the device
Use the Device picker in the Dev Tools to get the device ID (select via UI, switch to YAML)
Get it from the Template dev tools with {{ device_id("sensor.my_sensor") }}
You can also write an automation using Device trigger.
Z-Wave JS devices do not have device IDs in the format “xxx-xxxx-xxxx”.
You can also avoid device_ids by adding a conditional to the automation that checks if the ID matches the event, using the template code above. Entities are stable, however if you replace a device with another one, the device ID will change, rendering device id based automations broken.
hi,
I’m also new!
Is it possible to change the Device id number device_id: 45d7d3230dbb7441473ec883dab294d4
with a meaning full name? Reading the automation would me much easier.
Sorry for reviving such an old topic, but it directly relevant to my case, so bear with me…
Given that device_id’s can’t be changed to something human readable, but will forever remain a hexadecimal string, doesn’t this effectively render use of device_id in most YAML context fairly risky?
First of all, it’s impossible to read, remember and/or debug in search of errors.
secondly it makes replacing devices (when they die) almost impossible, because the replacement device will have a new and different device_id so all automations referencing it will break - and has to be manually updated. That’s a maintenance havoc.
Still, it’s perfectly valid to choose device_id’s when building automations. Wouldn’t a warning of caution be in order, encouraging users to avoid choosing device when building automations - i.e. as a popup message; “Do you really want to do this?”
I believe that this design has lead to much frustration among users as they (like me) realize this after spendig years trying to learn HA and build automations, and this fact dawn on us when the first devices begin to break or need to be replaced with new devices coming out from the suppliers.
As I said; maintenance becomes impossible.
After all, the word device is a common everyday word that most people can relate to. While the word entity on the other hand, is strange to most non-programmers. Thus when I have a choice, I choose device over entity in the UI simply because it sounds more familiar - not knowing that this leads to maintenance disaster.
So what’s a better solution?
Obviously to allow for the use of human readable (but still unique) names.
Am I right? Or have I missed something vital?
There’s no reason to use any device trigger, condition, or action if you’re using yaml. So this is a moot point. If you want to use device’s, use the UI, which will show you the names instead of the ids.
As for replacing devices, yes it’s painful, but you also have to understand that devices may not have the same functionality. So you’ll most likely be completely replacing that action anyways, which is just a few clicks. And a repair will show up on the repair page.
I have thousands of entities and hundreds of automations and have never used a device_id. Even when triggering from zwavejs event or sending command cc, the service/trigger has an option to specify an entitiy_id (and then the integration figures out what device to listen to)
I think the only reason people start using them is because the automation editor has it as the second choice - and hence most people would say - yes I’m trying to trigger from a device. Where as the “state” option is much lower in the menu - and not obvious what it does - but it is the one that should be used.
I can see that @petro (as usual) has a point - but all too often, rationalizing things - even though theoretically and technically correct, doesn’t always give the best result - as pointed out so elegantly by @PeteRage. We are just human.
And I like @NathanCu proposal
