Dear Matthias, I would like to thank you for the great work you have done. I had tested another integration for a long time, but it was very unstable and did not deliver all the values correctly. This evening I installed this integration and it works straight away and everything is clear and clearly named, I am delighted, thank you very much. One question: is there also an integration for the goe-controller? I’m not sure if I’m changing anything there, it’s set up once and does its job.
1 Like
Hi Peter…
the controller is also part of this integration…
Hi Matthias, at first I thank you very much for all the great work you put into this!
For now I managed to install and configure your integration for my new Gemini flex. However, charging triggered by PV excess power does NOT work at all.
I followed all your instructions on github and my first attempts to initiate charging by executing the following acion (using the dev tool section in HA) fails:
action: goecharger_api2.set_pv_data
data:
pgrid: -1500
In my browser the api status reply (within 5 seconds after action firing) looks like this:
{"lmo":4,"modelStatus":17,"fup":true,"awe":false,"fst":400,"acp":true,"pgrid":-1500}
Folllowing the API docs this means “Not Charging Because Fallback Awattar”.
The detailed settings for Eco > “Flexibler Energietarif” are chosen randomly (DE, tado, hourly) in the App - although awe key is false.
Update
When holding down the pgrid value to -1.500 by a 5 sec. time_pattern automation, charging starts after a minute, BUT charging current stays at 5,xx A forever even when pgrid is constantly at -1.5kW. I expect a regulation to a achieve pgrid == 0.
So, still “what am I missing”?
Thanks a lot in advance,
Martin
Update 2
For a “full range” PV surplus regulation you have to set the well known amp key to its maximum value. In ECO mode this parameter is apparently used as the upper limit for the Awattar logic.
Hi @marq24,
I do use the MQTT go-e integration for a bit more than a year now. Getting a good setup which does not empty the home battery, is to set the power to grid which the charger shall not use for its charging power calculation to 500 W. So you waste some PV power by sending it to the grid. And do not give the go-e device any other power infos. That pragmatic setup runs stable. My assumption is the speed of regulation is limited. If you go below minimum 500 W and once some power flows from the home batt to the car batt, e.g. when the PV power goes down, the home batt will kick in, and the go-e sensors are not fast enough to counter that. I have seen highest rate home batt discharge to the car bat with any value lower that 500W.
maybe simple question - but is the go-e controller needed?
I only want to start and stop charging with home assistant - maybe provide PV Power and the controlling part of 1-to-3-phase should do the go-e charge by itself.
Is there something i have to look for? I don’t have bought a charger yet but i want to replace my huawei charger…because of the controlling limitations.
No, you can ‘feed’ the wallbox with your own values for pv surplus using this module.
No need for additional hardware.
I have been wanting to implement some complex logic to steer my two go-e chargers, and this integration has helped me a lot.
In case my use might inspire others, I wanted to have four different modes:
- solar only: use surplus as it it intended
- solar: as long as there is surplus ‘left’ give at least the surplus or the minimum useable amount of power to the wallboxes
- limit: keep imported power below a fixed value (we pay ‘penalties’ for exceeding peaks in Luxembourg since 2025)
- full speed: just give the wallboxes whatever they can take.
Option ‘Solar only’ is the intended use case documented here; for the other modes, my automations ‘lie’ to the wallboxes and give them values computed from different power sensors I had set up already.
I just need a way to determine if the car is really done charging (so my automations can stop sending values to the go-e every 5 seconds). Unfortunately the go-e report that charging is complete when charging is interrupted due to ‘no surplus available’.
Anyway thanks for this integration, as it really got me going letting the wallboxes handle the complex stuff themselves.
Frank
First off, thanks for the excellent work on the API2 integration for the go-eCharger – it’s impressive and very promising.
I’m currently exploring whether this integration could be used to intelligently manage charging to avoid increasing my electricity tariff due to peak grid loads. I do not have solar panels or battery storage – my setup is entirely grid-powered.
I already have a working power metering solution in place, using the P1 interface via the HAN port to get real-time grid consumption data into Home Assistant. The idea is to use this data to dynamically regulate charging through the go-eCharger, ensuring that total household consumption stays below a certain threshold, which is important to avoid stepping into a higher tariff bracket from my energy supplier.
Would this kind of use case be achievable with the current API2 integration and Home Assistant? Has anyone implemented something similar or can point out any potential limitations?
Doing some research before placing an possible order on an go-e gemini.
Thanks in advance for your insights!
The go-e charger doesn’t know the state of charge of your car but there an api key “ocppcs” that can tell you if the car is no more accepting charging power. The value is then 4 meaning “SuspendedEV”. You can learn more about the OCPP protocol here: Understanding OCPP statuses | Flipturn Blog.
If you succeed to read this value in HA, you can do what you want.
What are the advantages/differences of this integration compared to GitHub - syssi/homeassistant-goecharger-mqtt: go-eCharger integration for Home Assistant using the MQTT API ?
well - the difference is for sure, the one works via MQTT (require an additional MQTT-Server) - the other one using directly the API available from the charger… What’s better? Well it depends from your needs…
Thanks for the effort! However, I have an issue. When I disconnecting and reconnecting the go-e, the IP changes, despite reserving the IP. Upon closer inspection, it seems that the MAC address of the charger changed as well.
Additionally, sometimes after reconnecting, the router has a notification “temporary MAC address registered”. Is this a problem in my network (TP-Link Deco X10) or the charger?
I have a question regarding pv surplus charging.
Since last week we have PV - but we cannot export energy yet (waiting for Wiener Netze and / or OeMag). Nevertheless I already try it as sometime there is a small peak for export.
How is the amount controlled to charge the car via wallbox? Is there some calculation behind? I can change both ampere and phases. It seems somethime the phases are set automatically, sometimes not.
I currently specify grid, pv and battery to the automation.
Thx for some clarification.
IMHO that’s network related - using the integration requires fore sure a stable IP…
it’s ‘unknown’ what the charger actually does (after the integration provide the constant data stream)…
Interesting: today evening it just charged with getting half from the battery, the other half from the grid right after connecting the car even though it was set to charge only with PV surplus.
Pgrid was positive and afaik all settings were fine.
First of all - thanks for the great work.
To add to the PV surplus charging: My setup is PV + battery, and of course I only want to charge when the battery is full with the surplus.
First try was to feed pgrid, pakku, ppv with the values read from my sensors.
… sometimes this works for a short while but then goes bonkers, empyting the battery.
I then tried to only use pgrid, calculating the value like this (sending a negative value if PV power above 2000kW, battery % above 85% and a fake 50 border for my power meter)
alias: go-e PV surplus charging brigde
description: >-
Simple automation to provide your go-eChargers with the required data so that
the wallbox can support PV surplus charging.
triggers:
- seconds: /5
trigger: time_pattern
conditions: []
actions:
- data:
pgrid: >-
{% if states('sensor.tibber_pulse_xxx_power')|float <= 50 and
states('sensor.enpal_battery_percent')|float > 85 and
states('sensor.enpal_solar_production_power')|float > 2000 %}
{{ states('sensor.enpal_solar_production_power')|float*-1 + states('sensor.enpal_battery_power')|float}}
{% else %}
{{ 0 }}
{% endif %}
action: goecharger_api2.set_pv_data
mode: single
Same procedure. Sometimes it works, sometimes not, draining the battery.
As people in this thread have already said, sometime when plugging in, even in the middle of the night, PV charging just starts.
How does sensor.goe_xxx_pvopt_averagepgrid get calculated? · marq24/ha-goecharger-api2 · Discussion #3 · GitHub is packed with more information, but not on the problem of battery drain and not stopping charging when the sun is down.
Would be so easy, if the go-e people could just document properly and publish their code 
well - one very simple approach (IMHO) would be to make use of the sun-down/up sensor in HA and make sure, that after sun-down the automation is OFF (sending no data to the wallbox)…
1 Like
That’s a good idea indeed.
The last days it is working quite good. But deactivating the whole animation during night might a good approach.