Use of ama for dynamic load balancing

[FransOv]

With a wallbox, a heat pump, an induction stove and a 3x25A grid connection some load balanciing is needed. I want to implement it "cloud free" and also manufacturer independent. I use Home Assistant in my home and will use that also for load balancing as nearly everything is connected to HA.
The ama key is the obvious key to tell the go-e charger how much current it may use, together with fsp (or should I use psm?) to set single or three phase charging.
Two questions:
The ama setting is preserved over a restart and even over an external power cycle. This means it is stored in non-volatile memory. Is there a danger of wearing out flash memory by frequently setting this key.
I presume that single phase charging always uses phase 1. Is this correct?

[povlhp]

The ama setting is preserved over a restart and even over an external power cycle. This means it is stored in non-volatile memory. Is there a danger of wearing out flash memory by frequently setting this key.

Just made my automation today and came here for the exact same question.

A related question is: will repeatedly setting AMA to its current value cause a flash write ? If so, please make sure that this does not happen.

Now clients will have to build logic to check before writing.

And I think I will add logic to my own code as well to not change ama before I am 0.5A past the optimal shift level to get fewer changes. If I can code it.

[FransOv]

I wrote a script that is executed every 5 seconds when the car status is not idle. It minimizes setting of the parameters and if necessary some extra hysteresis can be added. Just received the notice that my car delivery date has been shifted another 2 months due to components shortage, so I won't be able to test for quite some time. The script is based on a grid connection of 3x25A en the WB is limited to 16A. Extra functionality to be added for single phase <> three phase switching. I lose some formatting and indentation when pasting the script, sorry for that.
`alias: Load Balancing
variables:
go_e_mqtt: >
{% set go_e_mqtt = [] %}
{% set max_a = max([state_attr("sensor.smart_meter","amps_l1"),state_attr("sensor.smart_meter","amps_l2"),state_attr("sensor.smart_meter","amps_l3")]) %}
{% set available_a = 24 - max_a %}
{% set amps = states("number.go_echarger_205930_ama")|int %}
{% if available_a < 6 %}
{% set go_e_mqtt=go_e_mqtt+[["frc",1]] %}
{% set go_e_mqtt=go_e_mqtt+[["ama",6]] %}
{% else %}
{% if amps > available_a %}
{% set go_e_mqtt=go_e_mqtt+[["ama",available_a]] %}
{%elif amps < 16 and available_a > amps %}
{% if states("sensor.go_echarger_205930_frc")=="Don't charge" %}
{% set go_e_mqtt=go_e_mqtt+[["frc",0]] %}
{% endif %}
{% set go_e_mqtt=go_e_mqtt+[["ama",min([16,available_a])]] %}
{% endif %}
{% endif %}
{{ go_e_mqtt }}
sequence:

• repeat:
  for_each: "{{ go_e_mqtt }}"
  sequence:
  - service: goecharger_mqtt.set_config_key
  data:
  serial_number: "######"
  key: "{{ repeat.item[0] }}"
  value: "{{ repeat.item[1] }}"
  mode: single
  icon: mdi:scale-balance`

[povlhp]

I created most of my logic in Node Red. It is somewhat easier (JavaScript vs Jinja2) - and gives a nicer overview.

It the the FRC I need to set to pause charging.

I have made logic that only changes up to 7A if 7.1 available. And down when < 6.9A available. To avoid changing too often and wearing out flash.

[kalaws]

It seems like the appropriate way to implement load balancing may now be ids, rather than ama?

If so, we are still only pushing total grid consumption through pGrid, which is not optimal if the objective is to avoid blowing one of three fuses in a three phase system. Is it then possible that it would be better to push the highest load phase * 3 as pGrid instead? It's clearly not the best solution, but until the API allows pushing three phases instead of just the aggregate grid consumption, wouldn't this be better? At least during the night, perhaps, when PV is not in play anyway. The point is to avoid a situation where aggregate grid usage is 'medium', but one of the phases is near its limit, and go-eCharger still tries to do 3 phase charging, because aggregate usage seems to allow it.

Thoughts?

[0xFEEDC0DE64]

ids is related to PV charging, only using as much power with the car as there is available from the sun.
static load balancing works between go-eChargers (V3 and V4/Gemini) and does not consider your other loads like ovens or water heaters.
And for dynamic load balancing you have to use the go-eController smart meter at the grid entry point to measure the total current flowing and limiting the chargers so that the limit isnt exceeded.

[FransOv]

Setting ids will not do load balancing and will not prevent the main fuse being blown. It will make sure (if fup is set) that you only use surplus PV energy to charge your car. You are quite right that you need the highest phase load for load balancing. That is what my load balancing script above is doing.

[kalaws]

Ah, it was indicated on the page of the HA integration that ids was the better way of doing “dynamic charging”.

https://github.com/syssi/homeassistant-goecharger-mqtt

“ Only pGrid is used in calculations. Negative pGrid means power is exported, and thus available to the charger. Charger is then constantly calculating available power and adjusting charge power up and down multiple times per minute (on every update).

It is much better to do dynamic charging power this way over ama, as ama writes its value to flash, which can be worn out. And by feeding ids values, ECO charging can be controlled in the go-eCharger App. It is safe and expected to set this value often.”

[FransOv]

Load balancing is different from dynamic charging. The objective of load balancing is to keep the total load below the maximum that the home installation can handle. Ids gives the parameters to optimize the use of self generated electricity.

[povlhp]

You cam push any value you want to ids.
Even with no solar it can be used to send the negative of the amount you want charger to max use.

[kalaws]

True, that sounds like a good idea. I guess the advantage is that, this way, go-e does all the rest of the calculations, factoring in hysteresis etc. The only thing to make sure is that it stays in ECO mode at all times, I guess?

[FransOv]

Seems like it would work as long as you calculate the pgrid taking into account the max current per phase your installation can handle. As you are tricking the go-e, it might lead to undesirable side effects if future firmware versions use pgrid expecting it to be the actual power delivered to the grid.

[FransOv]

The ModBus API specification makes a distinction between AMPERE_VOLATILE (Amps Value for the PWM signaling in whole amps of 6-32A) that is not saved in EEPROM and AMPERE_EEPROM that is. So it is very likely that ama is cached in RAM and not every change is written directly to flash memory. I would like a confirmation from the developers on that.

[kalaws]

#138 (reply in thread)

Although it is not exactly what you are looking for, this comment seems to indicate it is not so problematic.

[FransOv]

I saw this in the issues: #112 (comment)

[makkie2002]

Hi ... I came here with exactly the same question and the fear to wear out the flash of the device. Is there a consensus that it is safe to use "ama" to do dynamic load balacing with potentially 1000's of writes per day?

Thanks!

[povlhp]

GO-e has replied it is safe.
But i would use the surplus solar charge instead and report available kW every 5s. I guess it is not written.

[makkie2002]

GO-e has replied it is safe. But i would use the surplus solar charge instead and report available kW every 5s. I guess it is not written.

Thanks for the reply! Do you mean you (mis)use the "ids"-key (to set pGrid, pPv, pAkku)?

Browsing the API-keys, I have found the "pgt" which has a descrition "pGridTarget in W". Does anybody use this key for dynamic load balancing?

[bruma59]

I've a 3f30A grid connection. I'm using single fase charging because it is regulating the charge in steps of 230W instead of 750W on 3f.
That means that the charging current is between 6-32A. But on that fase there is also the (dish)washing and shower heater of 2300W. This means that if the car takes too much current one of the fases shuts off the automatic fuse.
I've a heatpump heating on another fase that uses about 900W and some other electric equipment, about 1100W in total this period of the year.
In the PV surplus I've set pGridTarget on 8300W (keep in mind minus 1100W) and the current of the car is going down if more power is used in the building. Because I'm charging 1f the current also going down if the (microwave)oven or induction heating plates are used.
In your case with 3f it will going down when one of the fases are overloaded if you set it on 17kW I think
I don't use 3f bacause it always start at 3f charging and never switched back to 1f charging and we've a capacity fee to pay, what can be set by the pGridTarget

[FransOv]

I'm switching off the charger when the current on one of the phases gets too high, not throttling down. This because it would happen only under very rare circumstances. I have a 3 phase 35 amp grid connection, but the grid fuses are traditional ones that have to be replaced by a grid technician when they burn through. The grid company told me that their cable entering my house cannot support automatic fuses. I did limit the charger to 16 amps (16 A adapter used, adi key, in the app go to settings, digital input) because although it can handle 32, my car will only charge at 11kW, 3x16 Amps.This would also be possible in your case and would give you 11 kW instead of 7.4 kW for charging and still have 3x14 Amps available for other devices.