For installations with multiple circuits (not sure how common those are), we could reduce the number of api-calls by only polling the hierarchy api once per installation rather than once per circuit.

The alternatives I see are:

1. Perform the call in Installation.state and do nothing in the Circuit.state-function (seems a bit dirty, not sure how these functions are used and if this can create any unintended consequences)
2. Build some kind of caching into the Account class (seems veeeeeery easy to mess up).
3. Leave it suboptimized like this until all undocumented and/or deprecated api-calls have been dealt with.

What are your thoughts on this @sveinse?

Let's take one step back: Should we rather remove the Circuit object altogether? The only entity provided by the circuit device is Max current, and I'm not sure if anyone actually uses this value for anything. If Zaptec is moving away from the circuit API, then I think we should follow suit?

The only time Circuit.MaxCurrent is different than Installation.MaxCurrent is for those users that have multiple circuits. As you point out, I'm uncertain how common they are (for the use case when used with HA).

Hmmm... That does sound tempting.

We haven't received any indication that they will be removing the Circuit-level from their system hierarchy, have we? Just that we shouldn't use the direct circuit API? Otherwise that would break the Installation.build function (and probably some other stuff) as well.

I'll do a little bit of testing of what it would look like to remove it.

If circuit doesn't provide us with any useful value, then I don't think we need to include it. It's not like we have to model this equal to Zaptecs data model.

installation/{id}/hiearchy will still show the circuits and is used to detect the chargers connected to them. I think I would collect all chargers in a list in the installation object instead. Then we can remove the Charger class and the updates of it. Possibly store the circuit ID in the charger class. Charger.circuit would need to be changed to Charger.installation or some such.

Looking forward to your testing

I ended up adding a diagnostic sensor with the circuit name for each charger, so in a way the hierarchy is still included.

The main issue right now is that the old Circuit device is still included in the list of devices connected to the integration. Don't know if this is something we can fix from the backend, or if we need to include some user instructions to fix this.

Added a PoC for automatically removing the Circuit device(s). It's definitely in the "it aint pretty but it works" category, but I figured I'll leave it like this until we can discuss how automatic/drastic we want to make the removal and what loglevel we want the feedback on.

Deleting a device requires first deleting all the associated entities. If, for whatever reason, someone has attached a template entity to the Circuit device, that template entity would also get deleted by the automatic routine. I don't see any rational reason to attach anything to the Circuit device, but it's possible.

A more manual/gentler approach would be to instruct the users to manually delete each of the entities in the circuit device. Once the device has no entities, it will be automatically removed on the next HA restart (this works without the latest commit as well).

I'm leaning towards the fully automatic approach, but maybe with a warning along the lines of the warning for upgrading from pre-0.7-versions in the current readme.

@feliciaan: As a user with multiple chargers, it would be nice to get some feedback from you as well on this.

Does the Circuit-device(s) and its associated entities provide any kind of value to you in your setup? Or do you agree that it makes sense to simplify the HA architecture down to just Installation- and Charger-devices?

@steinmn FYI: I posted the question (among several others) on the Facebook groups for Home Assistant and Home Assistant Norge to get some data around this. I got quite many responses, but no responses that said that they were using "Circuit" for anything. Rather, most said actively they did not.

We have an Installation with 4 Circuits. 63A per Circuit and 125A per Installation. Actually we have 10 Chargers (1x3, 1x3, 1x1, 1x3). For Automation, the Information about Circuits isn't important for us. We do not use anything from Circuit. I can confirm the conclusion in #186 (comment). We do not have any value, about Ciruits.

@steinmn A little heads-up: I've started working on the bigger topics and will have a few PRs with quite extensive changes in them. The first one up is #191. This means we will be getting some merge work ahead, either here or there depending on the order the PRs gets merged.

Ok @sveinse, I have some time this evening. Do you think it makes more sense to clean this one up and get it merged first, or should I stack it onto the other one, and then they can be merged in order?

@steinmn I usually prefer first-come-first-serve for merges, and this one is first in line. I will be working on this integration today, so we can aim on getting it merged tonight. I'll take a deeper look at it. I hope its ok if I commit a few improvements to your PR.

@steinmn I can see a use case for the circuits, when you have certain limits per circuit because it has some other loads as well, so that the circuits can be throttled, but I think that this is out-of-scope for this integration. We don't use them for the moment as most of our circuits are directly connected to the grid.

@feliciaan We can make that the data from the circuit available in other objects, like the charger object. Just not as a dedicated device and its entities for circuit like we have now. I think we can make it possible to create automations with this data still. I'll look into that for this PR. 👍

@steinmn I can see a use case for the circuits, when you have certain limits per circuit because it has some other loads as well, so that the circuits can be throttled.

I don't think this is needed. In this case Zaptec Cloud would automatically throttle on base of all the chargers to the max of the Installation. If we have for example 5 cars on circuit 1 and 5 cars on circuit two - they can have each 12.6A per car. When we now have two other cars on circuit 3 and 2 more on circuit 4, the share 125A divided by 14 cars, what should be 8.9A. So we have 44.5A Load on Circuit 1 & 2 and 17.8A on Circuit 3 & 4.

I think I've addressed all your comments + added some updates to the readme to reflect the new handling of circuits. Let me know if there is something else that needs changes.

I'm going to have a look now. In the meantime, would you be so kind to take a look at #193 for me, please?

Thanks a lot!