Skip to content

Update naming of entities#193

Open
Getslow6 wants to merge 4 commits intoualex73:config_flowfrom
Getslow6:update_naming
Open

Update naming of entities#193
Getslow6 wants to merge 4 commits intoualex73:config_flowfrom
Getslow6:update_naming

Conversation

@Getslow6
Copy link

This update changes the naming of entities.

  • Devices are now capitalized
  • Entity ID's are of the form: sensor.{instance}{container name}{description}
  • Friendly names of the Entity ID's now don't mention the instance or the container name, resulting in a cleaner UI:

Old:
image
image

New:
image
image

@Getslow6 Getslow6 changed the base branch from master to config_flow April 18, 2025 12:40
@briodan
Copy link
Contributor

briodan commented Apr 20, 2025

I see why this was developed however it can break/affect configuration for folks monitoring multiple docker environments where some container duplication might be present

For example I use this to monitor a docker server and swarm cluster by monitoring each individual node. in some cases I'm running multiple copies of a container (especially on the swarm) for redundancy purposes, or compatibility (need to run different Elasticsearch containers for different services)

being able to see the node a container is associated with is very helpful.

@Getslow6
Copy link
Author

Getslow6 commented Apr 21, 2025

Thank you for the comment, I did not think of this.

The entity ID stays in the 'old' format, so unique entities are ensured - but I agree that it would be nice to (at least have an option to) tick a checkbox that prefixes the 'instance' name to the friendly name. Would you say that would solve your case? 😁

If so, I will try and give that a shot! I'm not too familiar with the config flow yet, so it would be a good little 'project' to start with!

@briodan
Copy link
Contributor

briodan commented Apr 21, 2025

I guess the question I have is what problem does this change fix? or what useful feature does it introduce?

From my seat and other can chime in:

  • There is no problem being solved, current implementation meets my needs, changing this potentially breaks my use case
  • There is no useful feature being introduced at best we're adding a work-around to get the old functionality back but now increasing code complexity

However I'm intrigued if some of this work/logic rework can help with swam entity/device names where we get random swarm identifiers in the entity id
image

currently working around that for some of my more permanent containers by specifying a rename pattern in the YAML, but that's not always easy to do with temporary containers since it requires an HA restart for the rename to apply.

@Getslow6
Copy link
Author

Getslow6 commented Apr 22, 2025

So to be clear (and my PR text might be confusing on that end): the naming of the entity ID's remains the same as how it is in the config_flow branch, so there is no breaking change on that end. What it does change is the friendly name of the entity, where it was previously prefixed with the instance (e.g. Docker) that was monitored.

You can see this clearly in the old screenshot in the PR; all the entity friendly names start with 'Docker Adguard'. For most users (including myself) that only run a single homelab with a single docker instance, this prefix to every friendly name makes the dashboard unreadable.

I appreciate you're monitoring multiple docker instances and it therefore is useful to you, hence my suggestion to make it useful for both of us by making this an option in the config flow 😄

Btw; it might also be that you're looking at a different version of the integration than I am, as renaming entities is currently not supported in the config_flow branch. Also, your screenshot suggests you don't have the 'Docker1' instance name prefixed to your friendly names.

Happy to hear your thoughts!!

@briodan
Copy link
Contributor

briodan commented Apr 22, 2025

Sorry I think I might have confused things as the second part of my post included a screenshot from the master branch instead of the config_flow branch because the rename is somewhat automatic in master but manual in config_flow.

Also appologze in advance for the wall of text :)

For the Friendly Name rename piece:
I understand that the entity ID stays the same the problem I have is that I don't see entity ID on a dashboard I see friendly name. Here is what currently I see with the conflig flow branch on a dashboard for a container running across all 3 of my docker nodes

image

with the proposed change the docker1/2/3 prefix goes away in the dashboard and I'm left with three by all means identical containers I can't differentiate.

This is not necessarily a docker swarm problem (since this integration does not support swarm) its a multi docker server environment problem, those three servers could be standalone and the issue could the same (barring naming the containers differently in docker)

Yes you can add that functionality to turn this back on via a switch, my question is if its worth the effort because its solving an actual problem or introducing a needed feature. Either case my point is I need to be able to keep the server identifier in the Friendly name to be able to tell where that container is running. And yes I know I could just rename the device manually but things are always much nicer when they are automated, especially when you have a dashboard that automatically pulls in entities like I do.

at the end of the day the worth the effort piece is not mine to answer, really all I'm asking is that the server identified portion of the Friendly Name sticks around as its a functionality i'm really looking forward to once config_flow becomes production.

Second part of my post above which is a separate requirement:

As you can see in the config flow branch and in the master branch (without renaming functionality) the full docker swarm identifiers come across into the Friendly name. This makes it hard to understand what the particular entity on a dashboard is.

In the master branch I get around that by using the rename function to strip out the random characters as you can see in the previous post screenshot. Of course that really only works for single containers not global services but its better than nothing, and the prefix in the config_flow branch actually helps the problem. In the config_flow branch as I can just rename the device manually in the GIU instead of adding a mapping in the YAML (though there seem to still be some bugs with it i.e. entities get renamed but device does not)

My point here is if you are looking at a function that changes the name structure of friendly name would it not be great to also strip the swarm identifiers in the name (the long random char strings), I realize that again I can manually rename the device but things are always nicer when they are automated. especially for something like a reboot button auto entities card that gets populated automatically, I can spin up a new container/service on the swarm and I can see its reboot button with full details on my HA dashboard without having to do anything in HA other then load the dashboard.

image

obviously this would go beyond the scope of the current PR and might not be as straight forward to implement and probably only applies to a small number of folks using this integration.

@Getslow6
Copy link
Author

Thanks for the lengthy answer - it shows you care and I take your point! I will update this PR to adjust the config flow so that the default behavior stays the same for your use case. For me the option to remove the prefix in the name is worth the effort, as it also helps me getting more familiar with python.

As mentioned in the other PR; I'm still pretty new to the Python world and now with the days getting longer and weather getting better it might take me some time to update the config flow. I'll also see if I can find where the swarm identifiers come from, but no promises there as I don't use Docker Swarm haha.

Thanks again for the comment and I hope you'll be open for testing the changes once I've committed them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants