Updating available current for each phase

[Gyran]

Currently we have a number entity for updating the available current for the installation. The previous implementation has a service call for updating the available current for each phase. What do we think is a good way forward in the new refactor?

• create number entities for each phase might be weird to have both a general and three for each phase
• have a service call like before
• don't support it
• have some config to decided if we should show one or three available current entities?

I would say option one is the easiest and then sync them. So setting all phases we update the general to the lowest (or just get the updated value from zaptec)

What do you think?

[sveinse]

Thank you for the issue @Gyran

I have attempted option one by adding 3 number entities. However it didn't work out as planned for a couple of reasons as explained below. It is not as trivial as it seems. After spending quite a bit of time trying to work it out, I have concluded that a service call as before for the 3 phase adjustment is probably best. The adjustment for setting all 3 phases to the same value is implemented as a regular number entity.

An alternative solution would be to have 3 number entities, but only use them for keeping the value. A button "Set 3 phase input current" will submit the 3 values from the number entities in one atomic request to zaptec cloud. This too is not without "yes, but...".

Why number entities for 3 phases are hard in HA

Zaptec cloud requires the 3 phases to be set atomically, otherwise the other values will be null. One cannot send phase1 in one request, phase 2 in another. Entities in HA are independent of each other, so we'd need to have some kind of caching that remembers the settings for the other phases and send all three values as one. That's doable.

This introduces the second problem: Partial updates by the user. Say we have 3 input entities and the user wants to configure the input currents. First the user adjusts phase 1, which make zaptec send the request with updated phase 1 and old cached values in phase 2 and 3. Then the user (at some unknown interval) adjusts phase 2, and now the integration sends a second request with updated value for phase 1, 2, but old cached value for phase 3. And finally the the 3rd phase is adjusted and all three values are correct and the 3rd and final request are sent to zaptec.

The sending of up to 3 requests to zaptec, where 2 are partial updates, are at best noisy. The Zaptec docs sais clearly that current adjustments more frequent than 15 minutes when an EV is charging must be avoided, as the EV might interpret this as an error condition. 2 of the updates are partial and interrim updates which makes this worse.

[Gyran]

I'll see if I can add the service call,and we can always see if we can find a suitable entity in the future

[sveinse]

@Gyran Are we done with the issue/proposal and can close it?

[Gyran]

Yes, I think so. Unless we want to keep it until it's implemented.

[sveinse]

Technically it is already implemented in the limit_current service call. Since this is not a trivial problem to solve with entities and that the root cause is how HA is designed, I don't have this on my todo list. Thus I'm closing the issue.

[Gyran]

Currently the service calls are not registered with hass so it can not be called. But I'll try to get to it this week

[sveinse]

@Gyran oops. Not intentional that the service calls are missing. Created issue #24 to fix it.