[IDEAS/FUTURE/ROADMAP] Investigate custom added entity-prefix (using config-flow)

[Mariusthvdb]

Edited creators notes - removing template hints

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

I cant find all related entities in /developer-tools/state belonging to 1 integration. Plugwise now creates many entities with names that aren't always very obvious.

Describe the solution you'd like

Adding the possibility of a prefix (preferably by choice) would solve this, just like entity_namespace did for integration we configure in yaml. If approved, please dont make it prefix with 'anna_' since that would be opposed to the manual override we can name the climate entity, and is not always followed correctly in the App itself. If anything, and you want it to be fixed, use 'plugwise_'

Describe alternatives you've considered

Home Assistant (please complete the following information):

• Version: 109.6
• Deployment: hassio
• Installed plugwise version: beta
• Installed through manual

Smile (please complete the following information):

• Sort of Smile: Anna
• Firmware: 4.0.15
• Setup:

Additional context
Add any other context or screenshots about the feature request here.

please see community discussion: https://community.home-assistant.io/t/plugwise-smile-custom-component-beta/183560/32?u=mariusthvdb
thanks for considering.

[CoMPaTech]

As you already mentioned in community - we should look for something 'better'. I'm aware of the challenges in finding things, believe me - sometimes still searching within my zwave network. Hue isn't that much better, but at least it only has light.something - The integrations page at least alleviates this, checking myself there isn't much else - /developer-tools/state doesn't provide filtering options, but then again /config/entities does and shows everything right beside eachother (partially solving my zwave issues, mostly (fully?) solving hue and plugwise?)

Sometime when breaking everyone's device IDs a couple of releases ago we also opted (by large demand from the community) the length of devicenames. Inserting plugwise_ increases again and just pl_ is not feasible imho (most likely would be shot down anyway when upstreaming - and let me be clear, -beta will continue it's presence but always as just that, an interlude towards the core integration).

Having said that, it's open source, MIT licensed and if there is a community wider desire for it we could look for a custom way to hinge this from - as far as I'm aware now there isn't much room in config-flow for 'click to open advanced options' and devicenames (not the discovered name, the light.living_room like descriptions) are set on that time (so you can't really change them later).

So please see if /config/entities doesn't provide what you are looking for, my guess is it will - be it so as a lookup-table in a second tab when creating automations or scripts.
In the meantime I will create a new feature issue referencing back here to investigate options on config_flow (different use-case though). If that sorts out (and the above still isn't functional for the community) we can take that route for custom prefixing.

[CoMPaTech]

Summary - please check your `http(s)://(...)/config/entities' page, it should provide what is sought after (and/or can be used as a lookup-table).

As this is stale for two weeks marking wontfix and closing - feel free to (re)open and unlabel when there is feedback.

[Mariusthvdb]

well, this is not what I was seeking, sorry to say.
I can of course manually edit all entities, as I have done in the beta version, but it is a far cry from using the yaml entity_namespace setting.

btw, this was stale, because nothing changed on the dev side....
dont blame me fo that ;-)

I understand we are leaving Yaml, but having a single integration creating entities with so many different names is somewhat underwhelming. Maybe set an option in the config flow to do so?

[CoMPaTech]

Not blaming anyone, I proposed/asked a question and there was no response.

As indicated in that response, prefixing everything will make others upset. Part of community and decisions is creating the optimal choice between demands.

As for creating something that can be set using config flow that could be part of future developments, although I'm not entirely sure what HA's point of view is (and while we could deviate with plugwise-beta we are still aiming to have this around, but purely as pre-lude to whatever is in core.