Conversation
|
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. |
|
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! |
|
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 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 Happy to hear your thoughts!! |
|
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: 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. 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. |
|
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. |
…iendly name for the entity.



This update changes the naming of entities.
Old:


New:

