Enhanced Device ID Search and Friendly Naming in Developer Tools

[zigomatic]

In my automation YAML, I found a device_id: c5b52----blabla--dd13f, but I can’t search for device_id via Developer Tools, which is a bit inconvenient.

I would like to request a new feature which can be either in Developer Tools or in Automation flow

Developer tools: The ability to search by device_id and retrieve all relevant information attached to it. Just as we have various filtering options in the UI now, it would be fantastic to have similar functionality in Developer Tools.

Benefits:

1. Improved Troubleshooting: Quickly find devices and their associated information, making it easier to debug and manage automations.
2. Streamlined Workflow: Save time by having direct access to device details without needing to cross-reference multiple sources.
3. Enhanced User Experience: Simplify the process of managing devices, especially in complex setups with many devices.

Automation flow:
Additionally, I propose an alternative option to extend the automation flow with a friendly_name for each device_id in automation.yaml. This would provide a clearer and more readable YAML configuration.

Benefits of Friendly Naming:

1. Better Readability: Make YAML files more understandable at a glance, reducing the cognitive load when managing automations.
2. Easier Maintenance: Simplify the process of updating and maintaining automations by using human-readable names instead of cryptic device IDs.

I believe these enhancements would significantly improve the usability and efficiency for all users.

[Edwin_D]

While there are valid ises for device_ids, especially in automations you’d do best to avoid them whenever you can:

Why and how to avoid device_ids in automations and scripts

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. [image] It works… but it is certainly not a “great way to start” because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. 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 yo…

[Hellis81]

Devices are in Devices and services:

Make sure you click on devices

And there is the entities connected to the device:

[zigomatic]

@Edwin_D

While there are valid ises for device_ids, especially in automations you’d do best to avoid them

I know that but I’m speaking about dev tools
where when I see device_id: c5b52----blabla--dd13f in a yaml, then I can search for that.

[zigomatic]

My answer is Developer tools - device_id - #4 by zigomatic

[Hellis81]

@zigomatic

where when I see device_id: c5b52----blabla--dd13f in a yaml, then I can search for that.

You can’t.
Switch to GUI mode and get the device name instead

This:

Becomes this:

And that is searchable

[zigomatic]

The purpose of this PR is to avoid passing through UI every time you have a device_id.
device_id are in .storage , device core registry file.
It’s then possible to have the output of that file in dev tools based on device_id

cat automations.yaml | grep device_id | sort | uniq | wc -l
115

I know some reco to not use device_id but it’s fine for me to use them.
It may be good to have the info translation of the device_id into device text available in alias but that would be then a FR for automation

[Hellis81]

@zigomatic

The purpose of this PR is to avoid passing through UI every time you have a device_id

I mean… technically developer tools are also part of the UI.
Even if you did search for it in developer tools you would just get the exact same thing as devices as I showed above.
With the added benefit of devices having a logbook which makes it easier to see what has happened lately with this device.

It seems to me as if your FR is something that is less useful than what already exist.
But it could be that I just don’t see the benefits.

In my opinion then perhaps a better FR is to add the friendly name in the yaml code instead

[zigomatic]

Yep, both are good solution.
Edited the FR in that way

[Sir_Goodenough ((SG) WhatAreWeFixing.Today)]

Device_id’s were designed for use only with the UI. If you want to use device_id’s, you use the UI. They are people unfriendly and cryptic.
Otherwise just avoid them…