Reorder entity_id and Entity names

Describe the feature

I know it's in the FAQ, and I know I'm not the only one complaining about this. So I won't ask for shortening them (which really it would be ideal). Just reorder them! Leave the Serial number and MPAN at the end of the names. No one uses them. I doubt anyone has more than 1 meter per home. I know we can adjust the names and entities, but that's not a proper solution. I must have done that like 10 times. This is an integration that causes many problems and log errors, so I have been forced to delete it and reset it plenty of times. Every time that happens, it means renaming the 30 names AND entities to make it usable. It's so frustrating.

It makes the entities unrecognizable, you don't know what you're looking at: https://i.imgur.com/LXJAqEv.png And when searching for entities is the same: https://i.imgur.com/VrQsg5z.png

Expected behaviour

If numbers show at the end of the names, at least we can read the actual name of the entity more often and choose the right one in our templates etc. There's plenty of other abbreviations that would be useful:

energy: removed
electricity: elec
current: curr
consumption: consump
accumulative: acc
standing: stand
previous: prev

Some might be worth debating over, but some are no brainers.

Use Case

Just be able to find the right entity everywhere in dashboards, suggestion tooltips in templating, etc.

Confirmation

[X] By submitting this feature request, you agree that you have read the documentation and confirmed it does not already exist
[X] I am willing/able to help contribute to the solution of this feature

Just reorder them! Some might be worth debating over, but some are no brainers. I know we can adjust the names and entities, but that's not a proper solution

I have found the tone of this issue unnecessarily hostile and it hasn't really encouraged me to want to assist you, hense the late response.

This is an integration that I have spent hundreds of hours on in my spare time, and available for free, when I could be working on something else. I only personally use about 10-20% of the features available in this integration. It is a hobby and not my day job, and having to receive messages like this with an entitled tone makes me want to not bother.

I know it's in the FAQ, and I know I'm not the only one complaining about this.

It's in the FAQ, because yes there have been a few people who have requested different naming structures, but a handful in comparison to the number of people who have installed the integration. Those requests were different again to the ones you suggested. Unfortunately, naming things is difficult (I hate abbreviations for instance) and what might be right for you, may not be right for some.

The reason for the long entity ids are simple

The domain is present as I didn't want to potentially clash with other integrations that provide similar sensors for meters, as a lot of people in the community use things like the glow device to get their readings. Hindsight, I probably wouldn't include this, but we're here now.
The serial number and mpan/mprn is present because the data that comes back from OE is in an array of arrays. I am only on an import tariff, so couldn't guarantee that any of these were unique and didn't want to assume anything. Turns out one of these is duplicated between import/export meters so if I had picked one of these I would have been wrong and had a clash.
The account id is present in other sensors because it is on the roadmap to support multiple accounts (which the serial number/mpan/mprn also play apart in).

The long names exist because I like consistency with the entity id, which have been abbreviated in the past.

I doubt anyone has more than 1 meter per home.

As mentioned, the OE API provide an array of arrays for the meters, so nothing was assumed. I've had people who have had multiple meters (for legacy reasons), along with people who are on import/export tariffs (and therefore multiple meters) or who have had their meters replaced.

I know we can adjust the names and entities, but that's not a proper solution

I think it is. It's why the feature exists in HA and solves the issue of everyone having their own way of naming things that make sense to them.

If numbers show at the end of the names, at least we can read the actual name of the entity more often and choose the right one

This is something I'll consider, but only for the names of the entities. For example Electricity XXX YYY Current Accumulative Consumption would become something like Current Accumulative Consumption (Electricity XXX/YYY)

I have absolutely no intention of changing the entity ids, not only for the reasons above, but also because I have a barrel of complaints when I change one or two entities (which I have done in the past to support new features). If I change 50+ sensors for over 3300 known users based on the naming convention of one person I will be slaughtered.

This is an integration that causes many problems and log errors, so I have been forced to delete it and reset it plenty of times

To me, this is the main thing I would like to help fix. You shouldn't need to reset the integration.

However I have not found any issues raised by you to indicate any of these issues. If you don't raise it, I can't fix it.

Raised warnings (which people commonly treat as errors) are informative of things that may degrade behaviour, but aren't things that are unrecoverable from. These can be suppressed by changing the log level for the integration to error or above.

The errors raised by the integration are usually unforeseen things and should be raised as an issue if they haven't been already.

If it's issues communicating with the OE APIs, there's unfortunately very little I can do with this, but happy to try and diagnose any issues. I've made improvements to how data is requested/retried to try and overcome these API issues. OE have stated that ~90% of their traffic comes from 5% of their users, for which they have calculated most of that 5% come from people using this integration, so I have to be careful on the frequency of requests.

I have found the tone of this issue unnecessarily hostile and it hasn't really encouraged me to want to assist you, hense the late response.

This is an integration that I have spent hundreds of hours on in my spare time, and available for free, when I could be working on something else. I only personally use about 10-20% of the features available in this integration. It is a hobby and not my day job, and having to receive messages like this with an entitled tone makes me want to not bother.

You are... completely right... :( I can only apologise after reading my submission again. I've grown really frustrated with the issue and when I posted I did it out of spite I guess. I completely understand your point and I'm really sorry if I made you feel that way. After all I'm thankful and using the integration, even if it's not perfect to my preferences.

With this said, thank you anyway for tackling my concerns respectfully. That showed me.

I understand all the points you make really. It might be useful to add all these detail into the FAQ to make your life easier so you avoid other people like me in the future.

It still annoys me, really, but I understand the reasoning.

Thanks for considering the reorder of names. It would only solve half the issue though, so maybe don't bother for the consistency. I think I'll raise a feat request on HA core to make the entities suggestion box wider and responsive with our screen, which honestly shares the blame here (same when writing yaml).

I'm glad you're willing to tackle the log errors. It's something that also bothers me greatly, and if I'm honest I'm not one to raise many issues as I feel bad to bother devs with things that are not deal breakers. But being honest, this is the integration that I deal with the most. To give you an idea, here's my logger yaml:

logger:
  default: warning
  logs:
    custom_components.octopus_energy: error
  filters:
    custom_components.wiser.coordinator:
      - "^Connection timeout.*" # Ignore errors starting with this regex
      - "payload"
      - "Connection error trying to communicate"
      - "Server disconnected"
      - "Connection reset by peer"
    pychromecast.socket_client:
      - "Heartbeat"
      - "Failed to connect"
    homeassistant.components.recorder.db_schema:
      - "current_rate exceed maximum size of"
      - "Attributes will not be stored"
    homeassistant.helpers.entity:
      - "Update of sensor.octopus_energy.*is taking over 10 seconds"
    custom_components.octopus_energy.coordinators.current_consumption:
      - "Try again"
    custom_components.octopus_energy.coordinators.past_consumption:
      - "Try again"
    custom_components.octopus_energy.coordinators.gas_rates:
      - "Try again"
    custom_components.octopus_energy.coordinators.gas_standing_charges:
      - "Try again"
    custom_components.octopus_energy.coordinators.electricity_rates:
      - "Try again"
    custom_components.octopus_energy.coordinators.saving_sessions:
      - "Try again"
    custom_components.octopus_energy.coordinators.electricity_standing_charges:
      - "Try again"`

I keep adding new ones daily. It's been a while I elevated the log to error for the integration. It's true I live better now, but still dealing with a few errors. Will do my work and report them properly from now on so you can work on them if needed.

Thanks again, feel free to close the issue now, and sorry again for my manners.

Thank you for the appology.

I'll update the FAQ with the information I provided. I'll still have a look at the names of the entities to see if I can make them structured in a way that's a bit more useful, as HA can be slow to respond to certain requests, and this doesn't tackle issues on mobile.

Regarding your logger, it looks like you're ommitting the messages regarding server errors as I can't find any other reference in the code with "Try again". If it is, unfortunately as mentioned there is very little I can do as that is on OE side, but I believe as more people upgrade their integrations this should hopefully get better. I have also raised it with them. If it it something else, it would be good to get the full error.

In regards to the Update of sensor.octopus_energy.*is taking over 10 seconds, again this is on either network contention with HA or the OE API. The only thing I could do is move the update to a background task instead of the entity itself, however only a handful of entities actually update themselves.

Yep, I'm aware most errors are still from the API connection, that's also why I didn't bother reporting, as I found that conclusion after some searching. It's just annoying really when you're trying to keep a clean log. 😆

For now that's all I have. Maybe (if it's not already there) it'd be nice for newcomers to prompt them to do these few changes to their logger settings as part of the initial setup as optional (if they want to avoid getting bombarded by warnings and timeout errors). Otherwise people might get a bad impression of the integration, when as you said there's really nothing you can do about it.

Cleaned mine up in case you or others like to use it. Haven't found a way myself of cleaning up and merging all the "Try again" ones for any "custom_components.octopus_energy.*" domain. Probably there is a way. Also I might be missing some as well, as different ones still keep showing up.

logger:
  logs:
    custom_components.octopus_energy: error
  filters:
    homeassistant.components.recorder.db_schema:
      - "current_rate exceed maximum size of"
    homeassistant.helpers.entity:
      - "Update of sensor.octopus_energy.*is taking over 10 seconds"
    custom_components.octopus_energy.coordinators.current_consumption:
      - "Try again"
    custom_components.octopus_energy.coordinators.past_consumption:
      - "Try again"
    custom_components.octopus_energy.coordinators.gas_rates:
      - "Try again"
    custom_components.octopus_energy.coordinators.gas_standing_charges:
      - "Try again"
    custom_components.octopus_energy.coordinators.electricity_rates:
      - "Try again"
    custom_components.octopus_energy.coordinators.saving_sessions:
      - "Try again"
    custom_components.octopus_energy.coordinators.electricity_standing_charges:
      - "Try again"`

Curious, what do you mean it will get better as more people update the integration? How does that affect the responses from OE API?

The way data was retrieved before 9.2.0 was inefficient at scale and causes spikes in the API load on the 30 minute or hour mark. According to HA analytics, there's still ~400 users who are on a version older than this. At some point, OE might decide to block these people, but in doing so could effect other people using their API.

Due to the current default naming it seems impossible to pick the right sensor when configuring the energy because the essential information is at the end of the name. The proposal to put XXX/YYY at the end sounds as a very good one.

Sadly the HA dropdowns have a fixed width that does not increase regardless how wide your browser is and at this moment I only see numbers.

Renaming 37 identities is a PITA. The irony is that the entity IDs are so long that is not possible to see them even on the table browsing the entities! I made the mistake of trying to update the IDs too and now I have the impression that this may have broken it and I do not see a way to reset them. -- yep, I am new to HA.

BTW, thanks for the effort of maintaining this, I know the feeling...

The naming of entities (but not the entity ids for the reasons specified) has been revised in v11.0.0.

BottlecapDave / HomeAssistant-OctopusEnergy