Feature Request: Change Load Shedding Zone

[phinor]

Two parts: (1) Request a way to change zone without reinstalling.

(2) Request a way to change load-shedding zones without breaking existing automations.

SA being what it is, we have dodgy infrastructure. Our area has changed LS zones twice in the last 12 months as they reroute our feed to different substations when conducting repairs or waiting for parts. Our last switch lasted 6 months, but now we are "back" (for now?) on our "original" zone. This time around, however, I have many more integrations which are now based on a sensor that is named after the zone.

[wernerhp]

1. It's been requested before. It's inconvenient to reinstall. It's a lot of work to implement editing the area only so you don't have to reinstall. It's on the to do list, but I'm lacking motivation to work on this in my spare time.

2. Automations break, because the Entity ID is unique per area and based off of the Area ID.

Home Assistant allows you to rename Entity IDs to whatever you want as long a they are unique.

To make this change for the integration will be a breaking change for everyone and will break everyone's automations and dashboards. Will keep it in mind for a v2 one day when I'm motivated as I get that this is annoying and inconvenient.

What you can try for now is to

• after removing and adding the integration with a new area
• Edit the Area Entity
• rename the Entity ID to what the previous one was or to whatever you want to call it
• reference that in automations and dashboards.

Then you only need to rename one thing every time it changes.

[tinuva]

@wernerhp technically you can make a change without breaking the existing user's automations etc. It will only break if the user remove and re-add the integration and a new name is then different.

The integration suggest the initial entitiy id right. So, in the future, the integration should rather suggest a generic zone name that is not based on the area id. Users will still have the option to rename it to an area id if they want, but I think a generic name is better, more re-usable and will fix the problems you describe and allow the feature request to go ahead.

And lets say you do change the name it suggests in the current version, all it takes, is for me to go rename the entity id back to what I have in all my automations. and this will only happen IF I remove and re-add the integration after such a change.

[wernerhp]

Yeah, that's true. Thanks for pointing it out. Will keep that in mind. It will make debugging the Area ID in use for the Entiry a bit harder, so will have to add it to the attributes or something, but it could work.

[tinuva]

The current way, if someone rename the entity id to fix their automations, you wouldn't know and in fact it will make debugging even harder if not impossible. I call this unreliable information. More reliable is having it as an attribute and part of the logging if you need it for debugging purposes.

[glibg10b]

[wernerhp]

Yup, @glibg10b I received the same email. Not sure how straightforward it will be to update a HA config entry when handling a 404, but will see what can be done.

[phinor]

I do want to say that my original problem was easier to solve than I had imagined - thank you for your comments and suggestions. It turns out that while lots happens in my automations during loadshedding, most are based on my inverter reporting having electricity or not (we have regular infrastructure outages unrelated to Load Shedding where we live). So, whether it's load shedding or not, many extraneous loads are turned off during power outages. I have tried to "future proof" my automations by using intermediate helper sensors which can be updated to refer to different sensor names and provide a consistent interface for the rest of HA.

However, it is inevitable that zones will change, be added and dropped, and I would still like to see a "minimal effort" solution managed by the integration to at least allow searching for a new zone. And if nothing else has to be updated, that would be first prize!

[wernerhp]

Please help with testing the new beta https://github.com/wernerhp/ha.integration.load_shedding/releases/tag/v1.4.0

[glibg10b]

Please help with testing the new beta https://github.com/wernerhp/ha.integration.load_shedding/releases/tag/v1.4.0

I got an error the first time I clicked "Submit" for both the API key and the search. It could just be instability on my end, though, so I won't do any further testing unless someone else has the same issue.

As for adding and removing areas, that works perfectly fine :)

Could you trigger an integration reload after an area is added?

[wernerhp]

Please help with testing the new beta https://github.com/wernerhp/ha.integration.load_shedding/releases/tag/v1.4.0

I got an error the first time I clicked "Submit" for both the API key and the search. It could just be instability on my end, though, so I won't do any further testing unless someone else has the same issue.

As for adding and removing areas, that works perfectly fine :)

Could you trigger an integration reload after an area is added?

Please provide more info on the error. There should be details in the logs.
Are you on the free API? If so, how many of the 50 calls have you made at the timw you got the error?

[glibg10b]

@wernerhp Here's my logfile: home-assistant.log. The errors are from automations and entities that rely on the custom names I had set for load_shedding's entities. I don't see any log entries related to the errors I got.

I lost my old API key when I switched to the manual installation method, so I had to get a new one. It's working fine now, though, so I don't think that's the problem. The new key's request count is currently at 10.

[wernerhp]

Using a new key within 24h of your old key will get both banned for 24h.