Improve PV surplus charging examples about homeassistant-goecharger-mqtt HOT 80 OPEN

I guess due to "Service not found" that your MQTT broker is not running.
Are you sure you have correctly setup MQTT (mosquito broker)?

• https://github.com/home-assistant/addons/blob/master/mosquitto/DOCS.md

Then check if the broker is running correctly -> setting/add-ons/Mosquitto broker

from homeassistant-goecharger-mqtt.

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...

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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".

from homeassistant-goecharger-mqtt.

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) }}

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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,...

from homeassistant-goecharger-mqtt.

Oh nice, wasn't aware that ESPhome already supports SML ootb.

I do see similar issues all around, with either no access or limited access to smart meter, but in reality there are legal obligations for the grid operator to provide access and detailed information (incl different phases).
In AT this is stated in a law, also in DE, at least according to BNETZA and BMWK (https://www.bundesnetzagentur.de/DE/Vportal/Energie/Metering/start.html / https://www.bmwk.de/Redaktion/DE/Downloads/Gesetz/gesetz-zur-digitalisierung-der-energiewende.pdf?__blob=publicationFile&v=4 ).

If you want/need a smart meter that comes with more features and better interface I'd recommend to give a call to BNETZA and ask for advice. This worked for me in AT with consulting e-control ( regulatory instance like BNETZA), they're very nice and have explained all the legal background to me.
This also helped me with negotiating with the grid operator in order to get access to the smart meter interface which is legally obligated anyway.
However, beside that legal requirements, I noticed that the grid operators, mostly smaller ones, were unable to fulfil these legal obligations, it's a mix of cost saving, lack of technical knowledge and resources, but in the end they must fulfil the legal obligations.

from homeassistant-goecharger-mqtt.

I am using a SolaX inverter and a DTSU666 smart meter.
Currently I am sending the following payload:

payload: >-
        {"pGrid":{{ (states('sensor.solax_grid_export')|int * -1) + (states('sensor.solax_grid_import')|int) }}{{', "pPv":'}}{{states('sensor.solax_pv_power_total')|int}}{{', "pAkku":0}'}}

I have added sending positive values if I am currently importing power from grid (solax_grid_import) to signal go-e should power down.
It seems right after draining some power from grid go-e powers down, but it takes about 5 minutes:

from homeassistant-goecharger-mqtt.

It's wok very well with pAkku activacted here :

service: mqtt.publish data: qos: 0 topic: go-eCharger/092997/ids/set payload: >- {{'{"pGrid": '}}{{states('sensor.victron_grid_load_2')}}{{', "pPv":'}}{{states('sensor.puissance_pv_totale')}}{{', "pAkku":'}}{{states('sensor.victron_battery_power_system')}}} retain: false

Result before pAkku implemented here :

from homeassistant-goecharger-mqtt.

My Home with Photovoltaïc ESS (Energy Storage System with Victron Energy + Pylontech Lithium Battery + AC Coupling Fronius PV + Driving charges with internal Fronius Relay + Power Reducer Stand Alone from 4noks + Home Assistant : All explained in French in this file below attached

LE BRUYANT - Installation OSCARO POWER chez Alexandre PY BLOUCH maj 01092023.pdf

from homeassistant-goecharger-mqtt.

Does anyone know how the values of pAkku will be considered by the system? when pAkku has a positiv value I do have additional surplus energy available... But I do not know how if go-e has the same logic or if it would require the value as a negative value...

from homeassistant-goecharger-mqtt.

Does anyone know how the values of pAkku will be considered by the system? when pAkku has a positiv value I do have additional surplus energy available... But I do not know how if go-e has the same logic or if it would require the value as a negative value...

Very GOOD question ! I HAVE THE SAME INTERROGATION !
EV discharge my home Pylontech battery ... not good 🤔

from homeassistant-goecharger-mqtt.

Somewhere in here

goecharger/go-eCharger-API-v2#110 (reply in thread)
you find an information in german, which was posted by the developer of the go-E API

It says :
pAkku wird quasi von pGrid abgezogen, pPv hat gar keine bedeutung (ausser der anzeige in der App)

So my interpretation is, the following, they use it in the following example.

1. You are charging pvsurplus, your pgrid is -3000W an so your charger starts with 3000W to charge.
2. Because charger starts to charge with 3000W your pgrid will become 0, and the charger knows it is using the optimum
3. There is a cloud, and your PV Power decreases. In this case every hybrid inverter will see I have power consumption of 3000W, from the roof are only 2000W available, so I have to add 1000W from the battery.
4. Without pAkku consideration charger will still charge with 3000W, because pGrid remains 0.
5. With paKKu consideration charger will see, that there is 1000W from the battery, even if there is pGrid = 0 and decreases the charger power to 2000W so that pAkku can become 0 and pGrid still remains 0.

Normally the pAKKU value and pGrid is sent by the go-E Controller, where pAkku can only be measured by AC connected batteries. All users with DC connected battery to inverter and go-E Controller can not use this feature.
Only the guys with programming skills, who use the API can use it also with DC connected batteries.

from homeassistant-goecharger-mqtt.

The easy one I already have in place is the following sensor (I use sensor.yaml for the sensors). If you would like to use it please take care that a "surplus" must be a negative value for pGrid... My smart meter provide negative values when feeding in and my Victron battery system provides positive values when the battery is charged...

The sensor "pv_surplus" is then inserter for pGrid

• platform: template
  sensors:
  pv_surplus:
  friendly_name: "PV Surplus"
  unit_of_measurement: "W" # You can change the unit as needed
  value_template: "{{ states('sensor.<include_your_smart_meter>') | float - states('sensor.<include_your_battery_power>') | float }}"

from homeassistant-goecharger-mqtt.

The second logic I have currently implemented in Home Assistant (but not in the PV Surplus Sensor yet) is monitoring the Battery SOC based on a time dependent definition. I would like to have 20% at 8am and 100% at 4pm. In case this is not reached the new sensor should provide a value of +230, in case the current SOC is higher than the definition it should be -230. If it is more than 20% it should be -460. The values can be adapted... As soon as I am sure that the logic is working I will add this value to the PV surplus sensor and the pGrid will be influenced that it is allowed to have some additional power from the battery if it is at a good SOC or that it should be reduced accordingly that the battery will also receive some additional PV power... Basically also the logic can still be extended for further definitions...

The sensors are (for the second one you just need to define your predefined values - no sensors need to be added. for the first sensor you need to include your sensor for the battery SOC):

• platform: template
  sensors:
  battery_soc_status:
  friendly_name: "Battery SOC Status"
  unit_of_measurement: "W"
  value_template: >
  {% set soc_tolerance = 2 %}
  {% set soc_time_dependent = states('sensor.battery_soc_time_dependent') | float %}
  {% set soc_current = states('sensor.') | float %}

      {% if soc_time_dependent - soc_tolerance <= soc_current <= soc_time_dependent + soc_tolerance %}
        {{ 0 }}
      {% elif soc_current > soc_time_dependent %}
        {% if soc_current > soc_time_dependent + 20 %}
          {{ -460 }}
        {% else %}
          {{ -230 }}
        {% endif %}
      {% elif soc_current < soc_time_dependent %}
        {{ 230 }}
      {% endif %}
  

• platform: template
  sensors:
  battery_soc_time_dependent:
  friendly_name: "Battery SOC (Time Dependent)"
  unit_of_measurement: "%"
  value_template: >
  {% set soc_8am = 20 %}
  {% set soc_4pm = 100 %}
  {% set current_time = now().timestamp() %}

      {% if current_time < now().replace(hour=8, minute=0, second=0).timestamp() %}
        {{ soc_8am }}
      {% elif current_time >= now().replace(hour=16, minute=0, second=0).timestamp() %}
        {{ soc_4pm }}
      {% else %}
        {% set transition_duration = now().replace(hour=16, minute=0, second=0).timestamp() - now().replace(hour=8, minute=0, second=0).timestamp() %}
        {% set time_elapsed = current_time - now().replace(hour=8, minute=0, second=0).timestamp() %}
        {% set soc_value = soc_8am + (soc_4pm - soc_8am) * (time_elapsed / transition_duration) %}
        {{ soc_value }}
      {% endif %}
  

And this will need an automation.yaml entry:

• id: 'xxx'
  alias: "Update Battery SOC Status"
  trigger:
  • platform: time_pattern
    minutes: "/1" # Update every minute
    action:
  • service: homeassistant.update_entity
    entity_id: sensor.battery_soc_status

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

My driving is no worse....

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

from homeassistant-goecharger-mqtt.

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?

from homeassistant-goecharger-mqtt.

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 ;)

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

@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"

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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".

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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).

from homeassistant-goecharger-mqtt.

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?

from homeassistant-goecharger-mqtt.

Thx, will give it a try!

from homeassistant-goecharger-mqtt.

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 :)

from homeassistant-goecharger-mqtt.

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?

from homeassistant-goecharger-mqtt.

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"}'}}

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

@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)?

from homeassistant-goecharger-mqtt.

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

The device supports SML transmitted using infrared.

from homeassistant-goecharger-mqtt.

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).

from homeassistant-goecharger-mqtt.

I'm very happy with my smartmeter and hope it will last long / won't be replaced some day.

from homeassistant-goecharger-mqtt.

Hello.
I have a problem, my configuration looks like this:

`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"
  retain: false
  topic: go-eCharger/{{ 212417 }}/ids/set
  payload: '{{''{"pGrid": ''}}{{states(sensor.power_meter_active_power_1)}}{{'', "pPv": ''}}{{states(sensor.inverter_active_power_2)}}{{'', "pAkku": ''}}{{states(sensor.battery_charge_discharge_power_1)}}'`

I am getting errors like this:

2023-07-25 13:35:55.333 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'sensor' is undefined when rendering '{{'{"pGrid": '}}{{states(sensor.power_meter_active_power_1)}}{{', "pPv": '}}{{states(sensor.inverter_active_power_2)}}{{', "pAkku": '}}{{states(sensor.battery_charge_discharge_power_1)}}'
2023-07-25 13:35:55.335 ERROR (MainThread) [homeassistant.components.automation.go_e_surplus_charging] go-e Surplus Charging: Error executing script. Error for call_service at pos 1: Error rendering data template: UndefinedError: 'sensor' is undefined
2023-07-25 13:35:55.341 ERROR (MainThread) [homeassistant.components.automation.go_e_surplus_charging] Error while executing automation automation.go_e_surplus_charging: Error rendering data template: UndefinedError: 'sensor' is undefined

Entities that are in the configuration work normally, the values are updated all the time.
Can it be improved?

from homeassistant-goecharger-mqtt.

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 is used for calculations. and is only used for "display".pGrid``pAkku``pPv

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) }}

Hi.
I have a similar layout to yours.
I am currently testing a way to prevent the charger from draining the battery.
My assumption is that the positive pAkku value is subtracted from the pGrid in the go-e charger logic.
So I reverse the value of the sensor.battery_charge_discharge_power_1 entity first:

  - platform: template
    sensors:
      battery_charge_discharge_reverse:
        unit_of_measurement: W
        device_class: power
        value_template: "{{ -1 * states('sensor.battery_charge_discharge_power_1') | float(0) }}"

...then I make it send only a positive value when the battery is discharged, a negative value when the battery is charging shows only 0 so as not to contribute to the pGrid value:

  - platform: template
    sensors:
      battery_power_in:
        friendly_name: "Battery Power In"
        unit_of_measurement: "W"
        device_class: power
        value_template: >-
          {% set power = states('sensor.battery_charge_discharge_reverse' )|float(0) %}
          {% if power >= 0 %}
            {{ power|abs }}
          {% else %}
            0
          {% endif %}

.... and only this value I send to the charger as pAkku.:

{{'{"pGrid":'}}{{states('sensor.power_meter_active_power_reverse')}}{{', "pPv":'}}{{states('sensor.solargeneration')}}{{',"pAkku":'}}{{states('sensor.battery_power_in')}}}

I'll see over time if my understanding of how pAkku works is correct, as it's still not entirely clear how it works.

from homeassistant-goecharger-mqtt.

I have tried countless hours fixing the problem on my side and I am about to give up and bury HA. :'(

--- Update ---

This code works for me for those who need a different one than what we have already:
alias: pv_charging
description: ""
trigger:

• platform: time_pattern
  seconds: /5
  condition: []
  action:
• service: mqtt.publish
  data:
  qos: "0"
  retain: false
  topic: go-eCharger/XXXXXX/ids/set
  payload: >-
  {{'{"pGrid": '}}{{(states('sensor.active_power')| float *-1)}}{{',"pPv": '}}{{states('sensor.pv_power_combined')}}{{',"pAkku":0}'}}

from homeassistant-goecharger-mqtt.

I have now changed a bit my strategy in regards of the pAkku as it seems that it does not really changes the behavior of the go-e charger as I wanted. Instead I have now created a new sensor in HomeAssistant which will calculate the real surplus of my PV by calculating the power feed in and the power supplied to the battery. This sensor is now used to supply the values for pGrid. With this the go-e charger is currently perfectly able to use all of the surplus power. I have currently generated a second additional sensor which will compare my Battery SOC vs a predefined SOC value dependent on time. If the SOC value is above the predefined value this sensor will provide the value -230W or -460W depending on how the SOC value is. In case the SOC is below the predefined value it states +230W. I am now testing the output of the sensor for 1 day and will then add in the calculation for pGrid. This would also allow to use some extra power in the battery to charge the cars...

Btw - for all of you not familiar in creating the sensors I just can recommend ChatGPT ;-)

from homeassistant-goecharger-mqtt.

Very interesting how you are processing all sensors...
Let us know how it's work fine and will explain us how you do it 👍🙏☀️❤️

from homeassistant-goecharger-mqtt.

Very very very interesting 👍
I think I have the same PV system, Fronius Primo 6 in AC coupling on ESS Victron ENERGY Multiplus 2 5k+ Pylontech 😅

from homeassistant-goecharger-mqtt.

I have a Fronius Symo Gen 10 with a Fronius Smartmeter… but basically the Sensor could be adapted to any systems as long as the values are received by Home Assistant.

from homeassistant-goecharger-mqtt.

The easy one I already have in place is the following sensor (I use sensor.yaml for the sensors). If you would like to use it please take care that a "surplus" must be a negative value for pGrid... My smart meter provide negative values when feeding in and my Victron battery system provides positive values when the battery is charged...

The sensor "pv_surplus" is then inserter for pGrid

• platform: template
  sensors:
  pv_surplus:
  friendly_name: "PV Surplus"
  unit_of_measurement: "W" # You can change the unit as needed
  value_template: "{{ states('sensor.<include_your_smart_meter>') | float - states('sensor.<include_your_battery_power>') | float }}"

I try you code here

but I don't know if it's working, my level in Yaml is poor ...

from homeassistant-goecharger-mqtt.

Just add an entity at your Dashboard with the sensor name and you will see if you get any results… and do not forget to restart or at least reload the yaml files

from homeassistant-goecharger-mqtt.

And if it is not working I just can recommend to use ChatGPT and describe the problem in the chat and copy the content of your yaml files (also the configuration.yaml) in it. everything posted before from my end was written by ChatGPT - I am not able to do this ;-)... when you are in the chat with ChatGPT consider it as a usual communication. Whatever you have added in this chat is remembered by ChatGPT...

from homeassistant-goecharger-mqtt.

Just add an entity at your Dashboard with the sensor name and you will see if you get any results… and do not forget to restart or at least reload the yaml files

Wow.. Do you know if I must declare sensor.yaml file in my configuration.yaml ??

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

from homeassistant-goecharger-mqtt.

I put your modificated sensor Surplus Pv online

I must test it and let you know...

Thank you !!!

from homeassistant-goecharger-mqtt.

It should be great : curve in Grey

from homeassistant-goecharger-mqtt.

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...

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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)...

from homeassistant-goecharger-mqtt.

Tests are very goods !

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

from homeassistant-goecharger-mqtt.

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!

from homeassistant-goecharger-mqtt.

from homeassistant-goecharger-mqtt.

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 ;)

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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

from homeassistant-goecharger-mqtt.

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 ;-)

from homeassistant-goecharger-mqtt.

@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.

from homeassistant-goecharger-mqtt.

@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 :)

from homeassistant-goecharger-mqtt.

@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…

from homeassistant-goecharger-mqtt.

@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 ;-)

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.

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.

from homeassistant-goecharger-mqtt.