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 https://github.com/goecharger/go-eCharger-API-v2/discussions/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.

[nean-and-i]

Ohh, I see, SML (vzlogger, I guess?), but looks like older one, however according to the manual it is capable to provide separate 1.8.0 forward power and 2.8.0 reverse power values?

Normally nowadays smart meter with MEP/MBUS P1 interface being rolled out, where you have a dedicated customer interface, the optical interface is usually exclusively reserved for grid operators (configuration/provisioning).

This of course depends on region and grid operator, overall its a bit of a mess and odd to see that there is no common technical standardisation and regulation across EU. I almost had to go through conciliation procedure with Austrian regulatory e-control against the grid operator in order to get digital access to the smart meter,...

[syssi]

ESPHome is able to decode SML frames using the SML component: https://esphome.io/components/sml.html

I use a ESP32 (+Ethernet+PoE) board plus a IR receiver LED and a resistor to receive the SML messages. The smartmeter is provisioned by my grid operator and publishes just a small set of the supported measurements. It provides two optical interfaces (a sealed one reserved for the grid operator and a second one for the customer. The resolution is pretty limitted here and I haven't access to the measurements of the different phases).