Improve PV surplus charging examples

[woopstar]

So I've been testing the PV charging today. Here are my findings for "logical" issues:

1. If you stop feeding pGrid on MQTT, it does NOT stop charging. You have to manually stop it again.
2. Example template does not work. The following seems to work:

action:
- service: mqtt.publish
  data:
    qos: "0"
    retain: false
    topic: go-eCharger/222819/ids/set
    payload: '{{''{"pGrid": ''}}{{states(''sensor.solar_power_available_for_charging'')}}{{'', "pPv": ''}}{{states(''sensor.inverter_input_power'')}}{{'',"pAkku":0}''}}'

3. For MQTT to correctly work, it is important that you remove the / in front of /go-eCharger/222819/ in the Prefix in the app. It is prefixed with / first but works incorrectly when I checked with MQTT Explorer on.

4. For MQTT to work correctly, you also need to remove / in the base topic name when adding the go-E integration in HA.

As per the screenshot from MQTT Explorer, MQTT topics now look correct:

[k3067e3]

Do I understand the feature correctly, when fup is set to true via API, then the go-E Charger is handling surplus charging on its own, as long via ids the available power is feeded? Reason for the question is, I can not find ids in API keys document from the manufacturer. So is the api documentation just outdated?

[syssi]

Correct! You can find some details about the new feature at the issues section.

[k3067e3]

Found it goecharger/go-eCharger-API-v2#110

[beebee]

I've been trying to set it up on my sisters Go-E and the HA in her home. According to the integration she has Firmware "055.0" and I cannot seem to set the ids. Payload on MQTT seems correct but the charger seems to answer: "unknown api key: ids" on the Last Set Config Key Result (sensor.go_echarger_XXXXXX_result in HA).

Could it be Firmware is too old? Cannot seem to upgrade from the Go-E app though: Upgrade is greyed out and there is a "Change to 054.11" Button and below a Release Note is shown noting "055.6" - which is strange App behaviour/UI issue? I don't want to accidentally downgrade ;)

[syssi]

055.6 is required. Please contact the go-e support If you are unable to update.

[beebee]

055.6 is required. Please contact the go-e support If you are unable to update.

Thanks, I had success updating it to 055.6 and now ids setting is working.

[woopstar]

@syssi Line 291 in Readme says: "This feature requires firmware 0.55 or newer." So it actually requires 055.6?

Other updates:

I've got my blueprint to work now, with the automation. Here's the MQTT call that seems to work for me:

- service: mqtt.publish
  data:
    qos: "0"
    retain: false
    topic: "go-eCharger/{{ entGoeID }}/ids/set"
    payload: '{{''{"pGrid": ''}}{{states(entMeanPowerAvailableForCharging)}}{{'', "pPv": ''}}{{states(entSolarPower)}}{{'',"pAkku":0}''}}'

entMeanPowerAvailableForCharging and entSolarPower are variables in my blueprint to the respective sensors for power available for charging and solar power from the inverter.

So far I've also had to do a switch in my automation to switch between Don't charge and Neutral as stopping sending the mqtt does NOT stop the charger. Sending 0 in pGrid does not seem to stop the charge either.

So I had to add this switch in the automation:

# Turn charger on or off based on available power
- if:
    - condition: template
      value_template: "{{ states(entMeanPowerAvailableForCharging) | int(0) < 10 }}"
  then:
    - service: select.select_option
      target:
        entity_id: select.go_echarger_222819_frc
      data:
        option: "Neutral"
  else:
    - service: select.select_option
      target:
        entity_id: select.go_echarger_222819_frc
      data:
        option: "Don't charge"

[beebee]

So far I've also had to do a switch in my automation to switch between Don't charge and Neutral as stopping sending the mqtt does NOT stop the charger. Sending 0 in pGrid does not seem to stop the charge either.

I would expect only positive pGrid values stop the charging as 0 would be the ideal condition of using all surplus power for the charging. Amount how much of positive power will stop is likely influenced on the fine tuning setting on PV Surplus app (prefer from net, standard, surplus).
I did not find any description of the Go-E logic used internally unfortunately. Can only speculate/test.

[woopstar]

So far I've also had to do a switch in my automation to switch between Don't charge and Neutral as stopping sending the mqtt does NOT stop the charger. Sending 0 in pGrid does not seem to stop the charge either.

I would expect only positive pGrid values stop the charging as 0 would be the ideal condition of using all surplus power for the charging. Amount how much of positive power will stop is likely influenced on the fine tuning setting on PV Surplus app (prefer from net, standard, surplus). I did not find any description of the Go-E logic used internally unfortunately. Can only speculate/test.

I've tried sending positive values also, though I fixed it at 1000W. Did not seem to stop the charger, but will try to investigate more.

[nilrog]

I've tried sending positive values also, though I fixed it at 1000W. Did not seem to stop the charger, but will try to investigate more.

That probably depends on how you have configured your charger. It has three levels of PV charging, "Prefer power from grid", "Standard" and "Prefer power to grid". The default setting is "Standard".

[woopstar]

Should pGrid constantly be sending negative values? The reason why I'm asking is:

Let's say you are using sensor sensor.solar_power_available_for_charging as a value for pGrid. The sensor holds the current amount of W exported to the grid. Example: -3412W

You'll then send the value -3412 as pGrid value to go-e. The charger will then begin to charge based on the value in pGrid.
As charging now occurs, the sensor that monitors the amount of power exported will decrease as consumption increases (You start to your power to charge the car hence you won't export so much).

Should the sensor take that into account, so pGrid is actually: power exported + power charged, hence when charging pGrid should constantly be near the -3412W and not decrease towards 0W as charging starts.

[nilrog]

No, you should just send what your meter, the one that monitors your grid connection, reports as passing through the grid connection as pGrid. The charger will take care of all the rest and when pGrid reaches 0, or becomes positive, it will adjust the power it uses. No need to add additional logic to this. I just take the value my inverter integration gives me and pass this on to the charger.

You can then, based on the PV surplus setting in the charger control how it will behave when available PV power decreases. See my comment above.

[woopstar]

So what you are saying is, that the charger will try, as much as possible to keep pGrid towards 0

I have a Huawei Solar system and my Power Meter is attached to my household's incoming power cords. The Power Meter reports the sensor sensor.power_meter_active_power which is the current amount of power either going in or out of the house.

Seems that should be the sensor to use then, but since exported power is a possible value in the sensor of sensor.power_meter_active_power, it should be inverted, as positive values equal export of power to the grid.

[woopstar]

You see the issue here. I'm sending a pGrid value of -2513W. Yet it starts to charge with 7.286W which is way too much. I wonder if they have started to use the pPv value in calculations also.

[nilrog]

Exactly. The charger has all the logic needed. We just need to supply it with the data it needs. Ofc, if you want to keep a buffer of excess PV power, you could have a sensor that modifies the value you send. E.g. if you want to always export 123 W, or something like that.

I have a Fronius inverter and I get the correct value to send to the charger. Positive when I import, and negative when I export.

I am also sending both pGrid and pPv to the charger.

[nilrog]

You see the issue here. I'm sending a pGrid value of -2513W. Yet it starts to charge with 7.286W which is way too much. I wonder if they have started to use the pPv value in calculations also.

Something is wrong, yes. If everything is correct, the charger will start charging slowly, making sure it does not exceed the PV surplus, and then it starts ramping up until there is no excess anymore. Depending on the setting in the charger, as I described above, it may use a small amount of power from the grid, or a lot, or try to always export. I don't know if this setting is exposed in the API, but it exists in the charger.

In your case, looking at that picture, the charger is using 7.2kW. But your system, that is providing pGrid, is still signalling that there is 2kW surplus being exported to the grid. So from the chargers PoV everything is fine using that amount of power since there is still surplus sent to the grid.

They are still not describing how the charger actually works in detail when it comes to PV surplus, and the potential for battery. There are some bits and pieces published in the github issue linked above.

And reading that issue it looks like there might be some flaw in the startup logic if the charger is set to automatic phase shift. I have it set to either 1-phase or 3-phase because my car sometimes trips the RCD, or leaks DC current, when 3-phase charging ends (a fault in the car, but the reseller refuses to believe it).

So you might have everything ok...and it is the charger that is not yet working as it should. v055.6 is, after all, still marked as beta

[moesizlag]

Does anyone know how and if the go-eCharger is dealing with the battery metrics?
I supplied mine (pAkku), it shows up correctly but the charger doesn't seem to use it for determing if it can charge the car from PV surplus. It instead discharges my battery (as long as the pGrid is negative).

[woopstar]

Does anyone know how and if the go-eCharger is dealing with the battery metrics?
I supplied mine (pAkku), it shows up correctly but the charger doesn't seem to use it for determing if it can charge the car from PV surplus. It instead discharges my battery (as long as the pGrid is negative).

only pGrid is used for calculations. pAkku and pPv is only used for "display".

[moesizlag]

Does anyone know how and if the go-eCharger is dealing with the battery metrics?
I supplied mine (pAkku), it shows up correctly but the charger doesn't seem to use it for determing if it can charge the car from PV surplus. It instead discharges my battery (as long as the pGrid is negative).

only pGrid is used for calculations. pAkku and pPv is only used for "display".

That would render that function completely useless to me (and probably to anyone with a local PV battery).
Do you happen to know if this is sth go-eCharger plans to change / allow for more configuration given they already have those keys in their API?

[woopstar]

Does anyone know how and if the go-eCharger is dealing with the battery metrics?
I supplied mine (pAkku), it shows up correctly but the charger doesn't seem to use it for determing if it can charge the car from PV surplus. It instead discharges my battery (as long as the pGrid is negative).

only pGrid is used for calculations. pAkku and pPv is only used for "display".

That would render that function completely useless to me (and probably to anyone with a local PV battery). Do you happen to know if this is sth go-eCharger plans to change / allow for more configuration given they already have those keys in their API?

Not yet. Only the issue linked in this topic is what there is of "public" information about this topic.

You can "alter" you pGrid sensor to take your battery into account. I have something like this sensor currently, that takes charging my battery into account:

- platform: template
  sensors:
    solar_power_available_for_charging:
      friendly_name: "Solar Power Available For Charging"
      unique_id: "solar_power_available_for_charging"
      unit_of_measurement: "W"
      device_class: power
      value_template: >-
        {%- set carCharger = states('sensor.go_echarger_222819_nrg_12') | int(0) %}
        {%- set carCharger = 0 %}
        {%- set powerMeter = states('sensor.power_meter_active_power') | int(0) %}
        {%- set batteryCharger = states('sensor.battery_charge_discharge_power') | int(0) %}
        {%- set batterySoC = states('sensor.battery_state_of_capacity') | int(5) %}
        {%- set batteryTargetSoC = states('number.battery_end_of_charge_soc') | int(100) %}
        {%- set powerAvailable = ( carCharger + powerMeter ) if (batterySoC < batteryTargetSoC) else ( carCharger + powerMeter + batteryCharger ) %}
        {{ ( powerAvailable * -1 ) | int(0) }}

[moesizlag]

Thx, will give it a try!

[nilrog]

only pGrid is used for calculations. pAkku and pPv is only used for "display".

That would render that function completely useless to me (and probably to anyone with a local PV battery). Do you happen to know if this is sth go-eCharger plans to change / allow for more configuration given they already have those keys in their API?

If you look at the specs for the go-e Controller you can get hints on what this charger will support. We are basically replacing their Controller with HA, since the have a local API that supports feeding the same thing that the Controller would do. There they mention that battery storage can be taken into account.
But since the charger FW is still in beta, I would expect this to be supported in the future. And by then we probably have more public info on how to use the API.

I have been waiting for what we have now to come to the go-eCharger for over a year now, and finally we have this. If Fronius had been able to ship their Wattpilot a year ago I would have bought that charger instead, since it promised seamless integration with Fronius inverters. The Wattpilot is a rebranded go-eCharger...so I took a bet on this one instead, and now it has payed off :)

[gschoenberger]

You see the issue here. I'm sending a pGrid value of -2513W. Yet it starts to charge with 7.286W which is way too much. I wonder if they have started to use the pPv value in calculations also.

Something is wrong, yes. If everything is correct, the charger will start charging slowly, making sure it does not exceed the PV surplus, and then it starts ramping up until there is no excess anymore. Depending on the setting in the charger, as I described above, it may use a small amount of power from the grid, or a lot, or try to always export. I don't know if this setting is exposed in the API, but it exists in the charger.

In your case, looking at that picture, the charger is using 7.2kW. But your system, that is providing pGrid, is still signalling that there is 2kW surplus being exported to the grid. So from the chargers PoV everything is fine using that amount of power since there is still surplus sent to the grid.

They are still not describing how the charger actually works in detail when it comes to PV surplus, and the potential for battery. There are some bits and pieces published in the github issue linked above.

And reading that issue it looks like there might be some flaw in the startup logic if the charger is set to automatic phase shift. I have it set to either 1-phase or 3-phase because my car sometimes trips the RCD, or leaks DC current, when 3-phase charging ends (a fault in the car, but the reseller refuses to believe it).

So you might have everything ok...and it is the charger that is not yet working as it should. v055.6 is, after all, still marked as beta

I can confirm some odd startup behavior with automatic phase switching on.
Today my go-e started charging with ~7kW even if only 4kW were reported by pGrid.

I switched to single phase mode to not exceed pGrid and that worked as expected, go-e was charging with max. 3kW on one phase and tried hold pGrid at 0.
Green: go-e current Power
Yellow: pGrid Power

Any hints on how to enhance the starting phase with automatic phase switching?

[nilrog]

Any hints on how to enhance the starting phase with automatic phase switching?

We cannot really control much, except continuously sending the available power since the logic is implemented in the charger itself.

That said, what are your settings in the go-eCharger app for the PV surplus limits for when to start 1-phase charging, and when to switch to 3-phase charging? I don't remember what the defaults were, but they looked low to me so I have increased them.
But since my car charger has an issue that it trips the RCD, or pushes DC leak current, sometimes when it stops charging on 3-phase, I have disabled automatic phase shifting so I do not really use that function anymore.

Other than playing with those settings, I don't think there is anything else we can do, except report the behavior to go-e support and see if they come back with some useful response, or firmware update.

[nean-and-i]

Most smartmeters and/or setups use dedicate separate values for power consumption (power from grid) and power return to grid , so I don't quite understand the design decision from go-e to a singe value for indicating grid status incl. negative value for power return to grid

Smartmeters provide power return to grid as positive value, else "0", this requires some changes in the template. please see below a payload template that works for the use case of 2 separate grid values eg. for Echelon/NES smartmeters using www.dabbler.dk board/integration.

payload: {{'{"pGrid":'}}"{{ (states('sensor.echelon_power')| float) if is_state('sensor.echelon_power_returned', '0') else (states('sensor.echelon_power_returned')| float *-1) }}"{{',"pPv":'}}"{{ (states('sensor.hoy_power')| float )}}"{{',"paAku":"0"}'}}

[syssi]

@nean-and-i My smartmeter indicates export to grid by negative values. IMO it's pretty common.

[nean-and-i]

@syssi , interesting, the MEP implementations I know (at least Austria, Denmark, Norwegian regions) all work with forward and reverse registers.
Might be dependent on the implementation of the P1 interface and configured/available registers/OBIS codes. What smartmeter is used in your area by the net operator and how do you get the values (MEP/MBUS)?

[syssi]

This is my smartmeter: https://www.easymeter.com/products/zaehler/q3a

The device supports SML transmitted using infrared.

[Indianagrenoble]

I really don't know how to take discussion with ChatGPT ;)

[MB1983k]

google it regarding ChatGPT... very easy....

and yes - you need to include in the configuration.yaml the following:
sensor: !include sensor.yaml

I am not sure if you then need to copy any sensors you have in configuration.yaml to sensor.yaml

[Indianagrenoble]

Hoooo F_CK !!!! I have just ask help to ChatGPT !!! IT's work

[Indianagrenoble]

Here below in file attached my discussion with TchatGPT for helping me (in french sorry) to include your sensor in my configuration.yaml !!!

FireShot Capture 103 - Bonjour, aide demandée - chat.openai.com.pdf

[Indianagrenoble]

[Indianagrenoble]

I put your modificated sensor Surplus Pv online

I must test it and let you know...

Thank you !!!

[Indianagrenoble]

It should be great : curve in Grey

[MB1983k]

Great to read - I am already testing my extended second logic and it looks fine.

If the additional sensors will be added the PV Surplus sensor calculation need to include also the sensor.battery_soc_status.

In this case the gGrid value will be influenced in a way to either allow to take some energy from to battery in case the SOC is higher than expected during the specific time of the day or it will be lowered to ensure that the battery will be charged to achieve a specific battery SOC depending on the time of the day... the logic can be adapted in the sensors as needed...

[Indianagrenoble]

I will test the GO-e charging this afternoon with my neighbor's MG4 car...

[Indianagrenoble]

Personally, I really don't prefer to use my Pylontech batteries (11kWh) to recharge a car battery... I want to charge an electric vehicle only and 100% solar (I have 10 kWp of photovoltaic panels for that)...

[Indianagrenoble]

Tests are very goods !

[Indianagrenoble]

As your code take care about Pakku naturally, I have removed Pakku from the MQQT automation

[Indianagrenoble]

[Indianagrenoble]

As you can see above, it oscillates too much around the PV Power available setpoint...
I've managed to smooth out this oscillation by increasing the refresh time of the MQTT sensors sent to the Terminal. And it works pretty well!

[Indianagrenoble]

[Indianagrenoble]

Yesterday I asked ChatGPT to make me a slider from 0 to 1500W in steps of 100W to make a power reservation output for my ESS Pylontech Battery because, indeed, it was still drawing a few hundred watts which is unacceptable ;)

[Indianagrenoble]

input_number: batterie_pylontech_charge_power: name: "Puissance de charge de la batterie Pylontech" initial: 0 min: 0 max: 1500 step: 100
push his code in my configuration.yaml as described by ChatGPT

[MB1983k]

Without having a detailed look into it I may expect that the oscillation is resulting due to an inappropriate update interval of the entities.

Basically the go-e charger is receiving the surplus value every few seconds and tries to adapt based on this numbers. But the entities used to calculate the surplus might not change every few seconds... so the go-e charger is finally not able to adjust the power used to the power available...

[Indianagrenoble]

My driving is no worse....

EV car (Zoe from neighbor's) still charging ...

[woopstar]

It's time to come back to this topic.

Using PV Surplus charging is great, but the real-world life scenarios differ a bit, and I think it's essential to take some use cases as an example:

When you set your car to stop charging at 100%, it will draw power from the charger if the SoC is below that. Most cars cannot put the target SoC through the API, so you often have to start and stop the power on the charger side, not the car side. The car says, "Oh, hey, there is power in the cable. Give it to me."

So, on a perfect day with an ideal setup, you have a household with a battery and an EV. Considering PV Surplus charging, I foresee the following use cases that should be solved.

In all cases, the car's SoC must be less than the target SoC, or we will not be able to deliver the power in general.

1. You want to charge the car between A and B hours calculated by some external tool like EV Smart Charging. It finds the cheapest time to charge the vehicle to X target SoC. It works by turning the charger On and Off. The way to do so currently with go-e is to set the Force State to either Charge or Don't Charge while setting the phases and requested current to 3 and 16A for an 11kW charger. You also want to put the Logic Mode to Default

The problem is that you cannot put the force state into Neutral because it will start charging!?

2. You want to charge the car using PV excess power. You are sending the MQTT with the pGrid information. To do so, you want to set the Force state to Neutral and Logic Mode to Eco. As suggested, I think this should work out of the box and charge the car with excess power.

3. You want to force charge the car even if there is PV surplus power. You must set the Logic mode to Default and Force state to Charge.

Now, how do you combine the use cases? You want to charge with Excess PV power during the day, but maybe the car only receives 60% SoC, and the target SoC is 100%. You'd like to finalize the charging during the night because it's the cheapest hour to do so.

The way to control this is to switch in the Logic Mode.

If exported power to the grid is > 0, set logic to Eco. Else, set it to Default.

Anyhow I will dig a bit more deeper into this and figure how to do this.

My current setup is:

Huawei 12kW solar panels
Huawei 10kW battery
go-e 11kw charger
Audi e-Tron 55

[MB1983k]

Agree - each individual case will have individual issues. But you are using Home Assistant and the first step is for sure identifying the issues you are facing…. then try to find a suitable approach…

Home Assistant is just used to send the PV Surplus value to the go-e charger. For all of my personal items to be controlled I am using the PV Surplus value. But I do not send the real PV surplus value - I have included several logics in HA which will trigger the PV Surplus.

E.g. the PV Surplus will be calculated in normal mode to ensure that my house battery will receive the required power to ensure it is fully charged 90min before sunset.
Then I do have an option to manually define the PV surplus value send to the go-e charger.
And I do have options to select how many % battery capacity should be added to which car (I do have 2 EV with 2 go-e Charger) - when selecting +20% HA will adapt the PV Surplus value (causing the max power setting for the go-e) until the required amount was added.

There would be endless possibilities available for this logic… e.g. defining max charging EV SoC and when reaching it PV Surplus could be set to 0 etc… And with this method the go-e Charger can remain in PV surplus logic ;-)

[woopstar]

@MB1983k That is a very interesting approach!

So you leave your go-e in Eco mode and keep the force state Neutral.

Then, you manipulate the PV surplus value based on what you want to do:

1. Force charge with full power based on a switch
2. Charge between a given time
3. Adapt it to solar power.

Does that mean you only send the pGrid value and keep away from pPv and pAkku ?

I understand that pGrid must always be negative, and the go-e charger will try to consume the same power as what you send into the pGrid value.

In my setup, the clamps are on my main power line, so when my charger begins, the household consumption increases. I believe you need to consider that, or pGrid will always go towards 0, then the charger will stop, and pGrid will be negative again.

Is that correctly understood? So if I have 3kW of excess power from PV, pGrid would then be -3000 all the time, including when the charger is on.

[nilrog]

@MB1983k Thanks for the tip about playing with "truth" about how much PV power is available to control if the charger will allow the car to charge or not. I haven't had time to think about how to be able to control the charger without any hands-on changes (basically using charging timer and ECO mode or not) due to "life". But this is a great tip. I like that you are thinking outside of the box :)

[MB1983k]

@woopstar - I try to catch the main items from your message:

The 3 examples are possible approaches, but my logics are more complex (you can constantly learn and improve it) - just start with simple options and then slowly improve based on your needs.

You can forward pPv and pAkku - but it does not influence the go-e Charger from my point of view. It is also fine to forward 0.

PV Surplus - the go-e charger need to know the real time PV Surplus… e.g if the PV Surplus before starting the go-e charger is 1500W and then the go-e charger starts charging with 1500W the PV surplus value will be 0 when perfectly balanced. If you would keep 1500W the go-e Charger constantly has the impression to be able to increase (and this will be done until reaching the maximum power allowed by the go-e charger).

In case you are measuring the PV Surplus and you do not have restrictions to consider (e.g. charging the house battery) you can simply forward this PV Surplus value. And then you could e.g. create manual switches and in case they are on there might be a manual value forwarded to the go-e charger (which anyway must have calculated values). In case you need some inputs use ChatGPT to find ideas how to implement it (but do it with small steps and test these small steps)

And yes - my go-e Charger is in the Eco Mode with PV surplus charging all the time. No need to change this…

[MB1983k]

@MB1983k Thanks for the tip about playing with "truth" about how much PV power is available to control if the charger will allow the car to charge or not. I haven't had time to think about how to be able to control the charger without any hands-on changes (basically using charging timer and ECO mode or not) due to "life". But this is a great tip. I like that you are thinking outside of the box :)

Basically you could fully automate it (e.g. by telling HA how many KM/miles you plan to drive within the next days)… you could even plan by using PV forecast inputs… So I would also have several ideas for the future to implement ;-)

[woopstar]

PV Surplus - the go-e charger need to know the real time PV Surplus… e.g if the PV Surplus before starting the go-e charger is 1500W and then the go-e charger starts charging with 1500W the PV surplus value will be 0 when perfectly balanced. If you would keep 1500W the go-e Charger constantly has the impression to be able to increase (and this will be done until reaching the maximum power allowed by the go-e charger).

Seems right! So, I'll try this out next week to manipulate the pGrid value. I like the idea!

Do you have any issues with automatically switching between 1 or 3 phases? I heard some had. So, I'm considering if I need automation rather than having Phase Selection set to Automatic.

[woopstar]

Update from here. Based on @MB1983k's suggestion to manipulate the PV Surplus value, I came up with the following two required elements in Home Assistant to make it work: an automation to send the pGrid value to the charger and a sensor with the available amount of power the charger can take.

Sensor:

- trigger:
    - platform: state
      entity_id:
        - input_boolean.audi_e_tron_force_charge
    - platform: state
      entity_id:
        - sensor.ev_smart_charging_charging
    - platform: state
      entity_id:
        - sensor.power_meter_active_power
    - platform: state
      entity_id:
        - sensor.battery_charge_discharge_power
    - platform: state
      entity_id:
        - sensor.battery_state_of_capacity
    - platform: state
      entity_id:
        - number.battery_end_of_charge_soc
  sensor:
    - name: "Go-E Power Available For Charging"
      unique_id: "go_e_power_available_for_charging"
      unit_of_measurement: "W"
      device_class: power
      state: >-
        {%- set maxCharge = ( 230 * 3 * 16 ) %}
        {%- set carCharger = states('sensor.go_echarger_222819_nrg_12') | int(0) %}
        {%- set powerMeter = states('sensor.power_meter_active_power') | int(0) %}
        {%- set batteryCharger = states('sensor.battery_charge_discharge_power') | int(0) %}
        {%- set batterySoC = states('sensor.battery_state_of_capacity') | int(5) %}
        {%- set batteryTargetSoC = states('number.battery_end_of_charge_soc') | int(100) %}
        {%- set powerAvailable = ( powerMeter ) if (batterySoC >= batteryTargetSoC) else ( powerMeter - batteryCharger ) %}
        {%- if is_state('input_boolean.audi_e_tron_force_charge', 'on') or is_state('sensor.ev_smart_charging_charging', 'on') %}
          {{ ( ( maxCharge * -1 ) + carCharger ) | int(0) }}
        {%- else %}
          {{ ( powerAvailable * -1 ) | int(0) }}
        {%- endif %}
      availability: >-
        {{ (
          states('sensor.go_echarger_222819_nrg_12') | is_number and
          states('sensor.power_meter_active_power') | is_number and
          states('sensor.battery_charge_discharge_power') | is_number and
          states('sensor.battery_state_of_capacity') | is_number and
          states('number.battery_end_of_charge_soc') | is_number
          )
        }}

Notes for the above sensor:
maxCharge is the maximum amount of power the charger can deliver. In my case, 11kW is 230V on 3 phases with 16A. This is used when you want to force charge with the charger on full power.
input_boolean.audi_e_tron_force_charge' is a Helper entity I have created. When this is set to On, the charger will use maxCharge, hence maximum power to charge my car without taking any house, battery, or vice versa consumption into account.
sensor.ev_smart_charging_charging is a sensor from the EV Smart Charging integration. This sensor will turn to On when the integration wants to charge the car using full power. This integration calculates the cheapest hours of charge when you want to reach Target SoC.
Remember to update the carCharger in the sensor to match your Go-E charger, as it contains your charger's serial number.
powerMeter, batteryCharger, batterySoC and batteryTargetSoC are all from the Huawei Solar integration and should be the default.

I have put the sensor in my templates to utilize the trigger functionality so it updates when any used entities update.

I also prefer to charge my home battery to the target battery SoC before it starts charging my car. This logic lies in powerAvailable.

Automation:

- alias: go-e Surplus Charging
  description: "Simple automation to update values needed for using solar surplus with go-e Chargers"
  trigger:
    - platform: time_pattern
      seconds: /1
  condition:
    - condition: template
      value_template: "{{ has_value('sensor.go_e_power_available_for_charging') }}"
  action:
    - service: mqtt.publish
      data:
        qos: "0"
        topic: go-eCharger/222819/ids/set
        payload: '{{''{"pGrid": ''}}{{ states(''sensor.go_e_power_available_for_charging'') }}{{'', "pPv": ''}}{{ states(''sensor.inverter_input_power'') }}{{'',"pAkku": 0}''}}'
        retain: false

Notes for the above automation:
I tried to first only run the automation when the sensor updates, but it seems the charger expects the pGrid value at a certain interval, or the App will report its missing data. The go-e controller sends power data every second, so I updated the automation to send data every second, while the pGrid value might not change anyway.

I'm also sending the pPv value with the sensor sensor.inverter_input_power from Huawei Integration. I have not yet tried sending pAkku to see if it has any effect.

Settings in the App:
The charger must also be set up to use PV Surplus for Charging. It must be in Eco mode, and Force State needs to be Neutral. See the above discussion in the thread.
Here are screenshots from the app showing how I have set up my charger for everything to work. Remember to setup the simulated unplugging also. This seems for me to work great.

Automatic phase shifting:
Switching between 1 and 3 phases works. One should note that the amount of power available to switch needs to be above 4200W for at least 5 minutes if I remember correctly. This is to prevent switching phases all the time.

[woopstar]

Update.

I talked with the team on support. In firmware 56.2 (beta) the house battery (pAkku) is now considered in the algorithm. They introduced pGridTarget (pgt) also.

pGrid: can have a positive and negative value. A negative value means we export power to the grid, and surplus is available for charging. A positive value means we are importing power from the grid, and we should not charge.

pPv: is the amount of solar power produced by the inverter. It cannot be negative. A positive value means solar power.

pAkku related answer:

The pAkku value can be positive and negative as you’ve already mentioned.
A negative value means, that the Battery is currently being charged by the inverter - the algorithm will try to prevent this and increase the charging power of the go-e Charger.
A positive value does the exact opposite, so the Battery is being discharged. The algorithm will also try to prevent this and decrease the charging power of the go-e Charger.

Theoretically you can forget about sending that value and only use the pgt (pGridTarget) with an negative value of e.g. -200W. This will have an impact on the charging algorithm as it will try to increase/decrease the power so there’s still ~200W of surplus left, that is going to the grid. This should prevent your battery from being discharged fully.

[karl1809]

Thank you a lot for your great work. I am a beginner with homeassistant and I need your help.
I tried your automation in homeassistant but I get the error: "Message malformed: must contain at least one of below, above."

alias: go-e Surplus Charging
description: "Simple automation to update values needed for using solar surplus with go-e Chargers"
trigger:
  - platform: time_pattern
    seconds: /5
condition: []
action:
  - service: mqtt.publish
    data:
      qos: "0"
      # Change to your charger ID here
      topic: go-eCharger/123456/ids/set
      # Please provide your own entities here, as described above
      payload: {{'{"pGrid": '}}{{states('sensor.tibber_pulse_leistung')}}{{', "pPv":'}}{{states('sensor.tibber_pulse_leistung')}}{{', "pAkku":0}'}}
      retain: false``

My goal is to use an automation for writing awp (Awattar maximum price threshold) in go-e-controller with minimumprice I get from the Tibber integration. Is there any example for the line payload:...... for that case?