Added fix for #212 and #213. A minor issue is that this creates new entities with _2 for the charging mode sensor and switch. Should we try to handle this automatically somehow?

This issue is deeper than that. I've found some usage of "charger_mode" and "charge_mode", which I need to figure out. I'm also about to write a new issue for avoiding the usage "info" attributes, but rather use "state".

If you are talking about entity names, *_charger_mode is the snake_case resulting from the name of the sensor/operating_mode entry in en.json. Different languages get different entity_ids (ref #179 and svenakela/ha#9)

If you are talking about entity names, *_charger_mode is the snake_case resulting from the name of the sensor/operating_mode entry in en.json. Different languages get different entity_ids (ref #179 and svenakela/ha#9)

Yes, with the latest fix in PR #216 the log now prints the Zaptec attribute name used in the entity, so that the mapping from Zaptec attribute to entity name is clearer.

Added fix for #212 and #213. A minor issue is that this creates new entities with _2 for the charging mode sensor and switch. Should we try to handle this automatically somehow?

We could "find" the old entity in the end of async_setup_entry() in main.py and delete it. If we happen to do that before the new entity is added, do they get the same name? Haven't tested it, and it is possibly somewhat hacky. I'm not sure when its ok to go about and delete entities and when its not.

We could "find" the old entity in the end of async_setup_entry() in main.py and delete it. If we happen to do that before the new entity is added, do they get the same name? Haven't tested it, and it is possibly somewhat hacky. I'm not sure when its ok to go about and delete entities and when its not.

If we can delete it before the new entity is added, I believe it will get the same name (as long as the user has not manually edited the entity_id), but will require some digging and testing. Considering it's really the same entity, just reading from a different key, I would argue that this is one of the most ok cases for this.

What are your thoughts on keeping the native zaptec values for the charger_mode-sensor? I know it's going to break my own sun charging automation (until I fix it), but I still think it would be good to stick with the native values for less confusion in developing the integration (it was part of why the increased polling rate wasn't working).

There is another option:

Today we use the EntityDescription.key as both the entity creation key (which HA handles) and the Zaptec lookup key. What if we separate them? Make an optional field zaptec_key which those few entities that needs it can use. This would allow us to change the underlying Zaptec reference without affecting the HA entity show.

If we go this route, we need a dedicated issue and PR, as this is a new "feature".

Entities do get the same name/entity_id when the old entity is deleted before we add the new ones. I think there is already enough confusion with all the different ids and keys without adding yet another one, so I think I prefer the removal option.

(We have to deal with that problem when we swap api.py to use ZaptecPascalCase unless we are to break every entity we have.)

Are we dealing with that problem as part of 0.8?

No, we are not. Pushing this ahead of us is ok.

The computation part of my automation works fine in a minimal test (once I changed Waiting to Connected_Requestingand Charging to Connected_Charging as expected). Haven't run the automation closed loop, both because I couldn't install the tibber-integration in the dev-container (dependency issue I'll leave for another day in favor of hiking in the nice weather), and because I rely on adjusting available_current on the Installation so I need #220 resolved for it to work properly.

I consider this ready for review/testing

The computation part of my automation works fine in a minimal test (once I changed Waiting to Connected_Requestingand Charging to Connected_Charging as expected). Haven't run the automation closed loop, both because I couldn't install the tibber-integration in the dev-container (dependency issue I'll leave for another day in favor of hiking in the nice weather), and because I rely on adjusting available_current on the Installation so I need #220 resolved for it to work properly.

PS! I was hoping to get some time to replicate and document the HA dev setup I'm using before this "release sprint" ends. I can install anything into it

PPS! I have until the end of this week to keep up this high activity level. I won't be able to keep the same tempo in the weeks to follow.

PPS! I have until the end of this week to keep up this high activity level. I won't be able to keep the same tempo in the weeks to follow.

Same here, so hopefully we can wrap up most of the topics this week 🤞