Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MQTT] Apply config parameter names as 'Friendly name' in HA #4110

Open
richardstone opened this issue Jan 31, 2025 · 12 comments
Open

[MQTT] Apply config parameter names as 'Friendly name' in HA #4110

richardstone opened this issue Jan 31, 2025 · 12 comments
Assignees
Labels
enhancement New feature or request

Comments

@richardstone
Copy link

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

I'd like to see the name of the config parameter of the device when it has been set to be discovered through MQTT in HA. The entity ID must be the same as it is, holding the actual config parameter number.

Describe alternatives you've considered

Additional context

@richardstone richardstone added the enhancement New feature or request label Jan 31, 2025
@robertsLando
Copy link
Member

By looking at this again I just remember that actually you can already do this by setting a custom entity name template from MQTT discovery settings :) If you want label to be included you can use %l in the template. Under the input there is a helper to help you doing this. The default template is %ln_%o that means the node name + object id

@richardstone
Copy link
Author

richardstone commented Feb 5, 2025

Thing is that I’m already using “ _%o” as the template to not break previous functionality of using for example “relay_switch_3” as entityID in automations. With setting this “ _%o”, I’m getting the exact same behaviour as before, so I don’t have to revisit all of my automations. At some point HA discovery have been changed, and since then, only “_switch_3” was discovered as the entityID as HA omits the “%ln” part of the default discovery template.

@robertsLando
Copy link
Member

robertsLando commented Feb 6, 2025

All names are generated by this function so what could be the solution here? I mean I cannot make it work differently only for configuration CC values otherwise that would be a breaking change

@richardstone
Copy link
Author

richardstone commented Feb 13, 2025

As far as I know, currently no "Friendly Name" is set during MQTT Discovery, only the entity_id gets populated. So this should be a new field, or?

@robertsLando
Copy link
Member

@richardstone Oh ok I didn't know about that, I thought you were asking for a change in current discovery payload not adding a new property :) Does setting a friendly name in payload overrides an existing friendly name you give to them? Also can I set this from discovery payload?

@richardstone
Copy link
Author

Currently I have no clue on how this works in code, unfortunately.
Since we are talking about setting this at discovery time, it should only address the name at the initial discovery of each entity.

@robertsLando
Copy link
Member

@richardstone the discovery payload is sent on each app restart or every time home assistant restart, there is no way to know if that entity already exists or not this is why I'm asking. I'm scared that adding this could force change all the entities friendly names of other users

@richardstone
Copy link
Author

Can this be done then the same way you enabled the configuration of the config entities?

@robertsLando
Copy link
Member

you mean throught gateway values table?

@richardstone
Copy link
Author

Yes, this could be another checkbox as well, if one would like to propogate the actual parameter name as friendly name.

@robertsLando
Copy link
Member

I don't see mentions of "frendly name" in discovery payload, not sure if it's possible to set it, IMO it's something that only user can change

@richardstone
Copy link
Author

So this is basically not working: Friendly name setting for values? Or am I misunderstanding something? (sorry for my weak TS knowledge :D )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants