Feature request: Allow customization of entity id's

[sfstar]

Currently some of the entity id's given by this component conflict with another integration I've configured to provide me with all-in hour prices from an energy provider. Next to that I have the need to monitor 2 different country's hour prices. Therefore, it would be nice if this component has an prepend option during configuration. So that users might customize their entity id's (and possibly in the future create multiple instances of this integration).

[JaccoR]

This is indeed a good request. We could configure it in such a way that the entity ids contain the country name in it. Then also change the integration friendly name to a country. That would allow you to add multiple instances of the integration. Would that solve it?

[Mariusthvdb]

Please allow me to jump in here: I had that same experience after installing the FrankEnergy component. Identically named entities... I then renamed all entities with the prefix sensor.frank_* and sensor.entsoe_*

[JaccoR]

There was also a request to add different instances of the integration with different templates. Thus, I think I am gonna ask the user for a name in the config flow and add this name to the entity name. Similar to how Forecast.Solar handles this.

[sfstar]

My issues also resulted from the frankenergy and entsoe integrations using the same name. In order to prevent historical data from becoming harder to correlate to new data after this update I would highly recommend having the user choose what/whether a prefix is used. That way this won't be a breaking change and it will (as mentioned by @JaccoR) allow not only multiple country's from being tracked but also multiple instances with different templates. It will also allow any currently unforeseen use cases for multiple entsoe integration instances, since the prefix won't be (partially) statically determined.

[sfstar]

I got multiple instances working in my PR #42 It does break the integration due to unique id's having to be differently composed (otherwise setting up a 2nd integration instance won't work due to the same key being used as the entity unique ID). However removing the integration and re-adding it resolves this issue without destroying historic values. You could program the unique id to be set to the original description.key value if prefix is not defined. This doesn't have my preference since it would introduce more complexity / code to maintain for something that (with a simple user action) can be easily corrected.

[JaccoR]

Thanks to @sfstar this issue is resolved. The user is asked for a name when configuring the integration. This name is added to the end of the entity id in this format: sensor.current_electricity_market_price_<name>. This way multiple instances of the integration can be added.

[sfstar]

@JaccoR Thank you for merging. My change entailed the following sensor format: sensor.<prefix>current_electricity_market_price_ Also note (for anyone reading this) that this is a breaking change. In case of upgrading from a previous version you have to re-add the integration without an prefix to create the original sensors entity names (which allows for historical continuity in graphs etc) with the new unique_id creation format.

[JaccoR]

My change entailed the following sensor format: sensor.<prefix>current_electricity_market_price_

I made some small changes. The prefix has been called name and the format is sensor.current_electricity_market_price_<name>. Also the name of the integration instance is changed from " ENTSO-e Transparency Platform" to just "". This to follow HA guidelines.

[sfstar]

Ah ok, Just two small remarks: Having the _ pre-defined between the optional name variable and the original description.name causes users to not be able to create sensor.current_electricity_market_price anymore. Thereby causing them to loose their historic data gathered by the integration. (for example I store the data in influx for long term statistics) If at all possible it would be better to have the integration be able to generate the original entity id's.

Futhermore, I chose the user configureable part of the name in front of the description.name in order to make searching for the entity easier. Since not all places you can search for the entity display the entire name and from my experience people usually search by a domain like entsoenl before checking for current, next hour etc.

Of course the 2nd remark is also partially based on preference and both implementations will work.

[JaccoR]

Ah yes, should've taken a bit more time for this. I quickly fixed it by deleting the _ when no name is given. Next to that I put the name in front now. So sensor._current_electricity_marketprice. I deemed the necessary for a clarity. Hope i thought of everything now and this didn't cause too much of a disturbance. Thanks!

[JaccoR]

There is an issue with the current commit, when configuring an existing instance of the integration it doubles all sensors with an extra _2 added. When changing the name all sensors also get doubled. This due to using generate_entity_id, which ensures a unique id by adding a suffix.

EDIT: fixed it by using self.entity_id = f"{DOMAIN}.{name}_{description.key}"