Include this to avoid updates during the night:
conditions:
- condition: and
conditions:- condition: sun
after: sunrise - condition: sun
before: sunset
- condition: sun
1 Like
I just have added that to the repo readme - thanks!
3 Likes
Hello,
I’m trying to get PV surplus charging working with my go-e Gemini charger.
I’ve installed the ha-goecharger-api2 integration in Home Assistant and enabled APIv2. The charger is reachable locally and responds to /api/status.
Here’s what I get from:
http://[IP]/api/status?filter=lmo,fup,acp,pgrid,ppv
{
"lmo": 4,
"fup": true,
"acp": true,
"pgrid": -7.22,
"ppv": 7250.47
}
That should be correct:
- Logic mode (lmo) is set to Eco (Awattar)
- PV surplus mode (fup) is enabled
- Charge pausing (acp) is enabled
- pgrid is negative → I’m feeding ~7.2 kW into the grid
- The charger works perfectly in normal (non-surplus) mode
However, it doesn’t start charging automatically in surplus mode.
I’m sending data to the wallbox every 5 seconds using this Home Assistant automation:
alias: PV surplus charging
triggers:
- seconds: /5
trigger: time_pattern
conditions:
- condition: and
conditions:
- condition: sun
after: sunrise
- condition: sun
before: sunset
- condition: not
conditions:
- condition: state
entity_id: sensor.goe_266304_car_value
state: Inaktiv/Frei
actions:
- data:
pgrid: "{{ states('sensor.shellypro3em_08f9e0e95ddc_total_active_power')}}"
ppv: "{{ states('sensor.shellypro3em_08f9e0e95ddc_total_apparent_power')}}"
action: goecharger_api2.set_pv_data
mode: single
I see that pgrid and ppv arrive at the wallbox via the /api/status endpoint, but still no charging starts.
Is there something I’m missing?
Thanks a lot in advance!
Hi,
I did the same mistake 
Your pgrid value is “-7.22” in KW, but this value needs to be “-7220” in Watt. So just multiple the value with 1000 → " *1000 " and the problem is solved.
1 Like
Hi, first of all thank you for the integration. I have it up and running, my next step would be to make an automation. On the Github page is a link to a Blueprint, when I want do download it, I get an error. Is something wrong, or is the Blueprint discontinued? Thanks for the feedback.
Hi all,
maybe a stupid question… I have just installed the API to my Home Assistant, but I am not able to see any entities on my Dashboard. It is the first time this happend but no clue why.
What I did: I configured the the extension, and added the extension to “Bereich” I think it is Area to Wallbox. Next I created a Dashboard to show only Wallbox, but it is always blank.
I checked the Bereich again and it says no entities connected but looking to the entitiy list directly it says it is connected to the area… Any Idea?
enable the debug log and check what output is generated during the startup
The Blueprint was just added few days ago… I fixed the links… Thanks for letting me know
Hello Matthias, thank you for the update on the blueprint!
First of all, @marq24 thank you for great integration. It has been game changer for optimizing the cost of charging.
I’ve built small automation that updates the awattar max threshold price to charge on cheapest hours/15 mins when I connect the charger to my car. Automation calculates time needed to charge my car to 80% and which is the minimum price to set awattar price limit to get needed hours for charging and charge on the cheapest hours/15 mins.
The API works flawlessly for full cent prices. With prices including desimals (i.e. 2.32) the full price is imported to HA if updated in go-e app. But if I set price on HA the desimals are dropped off before appearing on go-e app (2.32 → 2).
According the eco price sensor (goe_wan_xxxxxx_awp ”[go-e] Awattar maximum price threshold”) it should work with 2 decimals. Prices updated on go-e app actually land with 9 decimals to HA.
Is there a way to push desimals to awattar max price threshold via this API?
It’s not a major issue, but with my driving kilometers the savings from desimal prices could be 75e / year. More nice to have, than critical feature, but would make 15min charging optimization even more optimal.
Thank you in advance.
(I have the new go-e Core charger with SIM and max 22kWh capped to 11kWh)
it’s always smart to raise issues directly @ github… since then I will be notified… so please excuse the late reply…
So you have a certain sensor where the set-value will be always casted to an INT… Changing that to a float is no big deal, as long as you can give me the API key - or the name of the sensor in HA… [Again the best is to open a Feature request with this information here: GitHub · Where software is built
and also have in mind, that awp is considered as configuration data, which will not automatically be updated with every refresh - you either need to push the sync config button or you need to wait +30min till the integration will refresh the value you specified in the go-eApp…
I just have checked the integration here - and everything works as expected… ?!
Hi,
thank you so much for this intergration!
Iḿ realy satisfied with it, it works great for pv-charging.
I created a automation to start an stop charging via grid in winter time.
Start charging works great with “Ändere die Option go-eCharger Laden freigeben” to “1”.
To Stop charging I tried to change same Option to 0, but it does not work.
So I’m wondering how I can easily stop the charging process.
I haven’t found any other option for this.
force stop charging? see here:
This was rubbish.
Hi, this issue (decimals in economy price when pushing prices to api) was fixed few days later I posted the question here, the float option was added and decimals started to work perfectly. So this is all good. I thought that you or some of the contributors picked the question and fixed in straight away. Thank you for your the great work.
Hi @marq24 again,
I encountered an issue with the latest version of goecharger-api2. (Same message posted to GitHub. Adding it here if there are people reading only this thread and not GitHub.)
Charger setup:
I’m using go-e Core charger with latest available firmware (59.5). The 60.0 is not yet available for the Core Charger. At least I cannot update to it via go-e app. Charger is connected via this integreation cloud option to Home Assistant.
The issue:
For some reason go-e has named the current firmware “59.5-dirty” in Core Charger. At least this is what I’m interpreted from the attached error log. This non numerical naming causes issues with the version logic part of the code. Could the version logic be updated so that it counts 59.5-dirty same as 59.5 since previous versions of the integration worked perfectly.
Thank you in advance.
The error log:
Logger: homeassistant.config_entries
Source: config_entries.py:761
First occurred: 22 November 2025 at 01:00:09 (1 occurrence)
Last logged: 22 November 2025 at 01:00:09
Error setting up entry go-eCharger API v2 [xxxxxx] Cloud for goecharger_api2
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 761, in __async_setup_with_context
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/goecharger_api2/__init__.py", line 75, in async_setup_entry
await coordinator.read_versions()
File "/config/custom_components/goecharger_api2/__init__.py", line 323, in read_versions
await self.bridge.read_versions()
File "/config/custom_components/goecharger_api2/pygoecharger_ha/__init__.py", line 119, in read_versions
if Version(fwv) >= Version("60.0"):
~~~~~~~^^^^^
File "/usr/local/lib/python3.13/site-packages/packaging/version.py", line 202, in __init__
raise InvalidVersion(f"Invalid version: {version!r}")
packaging.version.InvalidVersion: Invalid version: '59.5-dirty'
best option to report issues is always via GitHub - simply cause there will be instant notifications for new issues…
The GitHub issue with -dirty is fixed already