PV-Überschuss in Firmware einbauen?

[gyroslav]

Die CFOS-Box kann es schon, warum also nicht auch die Go-E?
Die FW so aufbauen, dass die Go-E sich die PV-Daten selber vom Wechselrichter/SmartMeter holt und dann die Ladung steuert.

Man muss die IP vom Wechselrichter oder SmartMeter eingeben und per Modbus holt sich die Go-E die benötigten Werte: PV-Generatorleistung, Einspeisung, Netzbezug.
Zusammen mit der eigenen Ladeleistung lässt sich alles benötigte ausrechnen.

Wenn die Registeradressen nicht standardisiert sind, kann der Nutzer die auch selber eintragen.
Wenn es einen Speicher gibt, sollte es ein eigenes Feld dazu geben mit IP/Modbus/Register und Prioritätsoption.

[0xFEEDC0DE64]

Die Firmware kanns schon seit 2 Jahren, wir haben Jahre an Entwicklung in die Perfektion der Regelschleife gesteckt, mit automatischer 1/3 Phasenumschaltung, Kompatibilität mit praktisch jedem Auto-Lader, automatischem simulate-unplugging usw. es fehlt nur ein Interface für "Bastler", mit dem man die pPv, pGrid, pAkku Werte setzen kann. Ich kümmere mich drum.

[gyroslav]

Moin, EVCC kann das. Nutze ich seit einem halben Jahr. Läuft super.

EVCC kann den Trigger zum Umschalten geben - bildet also die Logik ab.
Dafür wollte EVCC dann aber auch Geld haben.
Und seit der Version 1.7 will EVCC Geld für den generellen Support der GO-E Wallbox. Anscheinend ist der Programmierfaufwand für genau das Modell sehr groß, oder die Wallbox ist sehr beliebt.

[JochenFriedrich]

Vermutlich Aufwand wegen den häufigen API Änderungen.

Im Prinzip braucht es ja nur eine Methode, per API die aktuellen Werte für pGrid, pAkku falls vorhanden und pPV falls verfügbar zu schreiben. Und ausserdem eine Möglichkeit, die aktuelle Strategie zu wählen (z.B. keine Einspeisung im Winter oder kein Bezug im Sommer oder halt maximales Laden).

Eine API Wandlung (z.B. OBIS seriall auf MQTT oder API Schnittstelle) kann eigentlich jede Hausautomation wie Home Assistant, FHEM, OpenHAB. Oft ist die ja auch bei EVCC noch notwendig. Da muss man dann nur mit 2 Apps jonglieren (Freigabe per eChanger APP, Strategiewahl per EVCC). Alles mit einer APP oder direkt am Gerät wäre perfekt.

[chk2902]

Ich kann nachvollziehen, dass die dafür etwas Gegenleistung wollen. Auch für den Support, man ist als Sekundäranbieter oft erste Anlaufstelle bei Problemen. Meine App ist auch nicht kostenlos - es ist zwar Hobby, aber kostenlos das anbieten? Dann hat man auch viel mehr Kunden, die etwas "einfach so" probieren und eine Menge Support verursachen. Aber das ist off-topic.

[gyroslav]

Ich kann nachvollziehen, dass die dafür etwas Gegenleistung wollen. Auch für den Support, man ist als Sekundäranbieter oft erste Anlaufstelle bei Problemen. Meine App ist auch nicht kostenlos - es ist zwar Hobby, aber kostenlos das anbieten? Dann hat man auch viel mehr Kunden, die etwas "einfach so" probieren und eine Menge Support verursachen. Aber das ist off-topic.

Sicher, das ist euer recht. Wer was schafft/erstellt, darf dafür verlangen was er möchte.

[JochenFriedrich]

Die Gegenleistung kann ich nachvollziehen, beschwere mich darüber auch nicht. Bei der eCharger Unterstützung kam die Änderung nur quasi über Nacht mit einem Update, was dann auch zu Aufwänden geführt hat (Rekonfiguration des K8S Yamls)

Die EVCC bietet ja auch weitere Feature, wie z.b. die automatische Zuordnung der Ladevorgänge auf Fahrzeuge und Begrenzung des Ladevorgangs auf einen bestimmten Prozentsatz.

[chk2902]

Meine Android-App "WallboxSteuerung" kann das auch.

Aber ganz ehrlich: das ist nicht einfach, nicht mal, wenn man nicht nur stumpfsinnig PV-Regelung machen will oder gar kann. Dann wird der Aufwand größer: nicht jede PV-Anlage kann modbus, nicht jeder Nutzer kann die Tabellen anlegen (modbus ist nur halbwegs standardisiert, Byte-Order, Scales, ...), was machst Du bei Vorhandensein von einem Heimspeicher, ...

Fazit: so einfach ist das nicht.

[gyroslav]

Ich hab mir in den letzten Wochen ein Blockly-Script für IOBROKER geschrieben... also so groß ist der Aufwand nicht.

Man benötigt die Werte:

• Einspeisung am Übergabepunkt (tatsächlicher PV-Überschuss, kennt der Smartmeter bzw. WR)
• Bezug (was zieht das Haus gerade am Übergabepunkt, kennt der Smartmeter bzw. WR)
• aktuelle Ladeleistung der Wallbox (kennt die Wallbox selber)
• Puffer für den Haus-Akku (kennt der Akku-WR)
• Angst-Puffer (frei wählbare Zahl, kann sogar negativ sein wenn man Bezug zulassen will)

Die maximale zur Verfüfgung stehende Ladeleistung errechnet sich dann:
Einspeisung + Wallboxleistung_aktuell - Bezug - Haus_Akku_Puffer - Angst_Puffer

Die Logik für das einfache Überschussladen ist simpel. Kompliziert wird es, wenn man ganz spezielle Szenarien abbilden will.
Aber hier geht es ja nur um das einfache Überschussladen.

Also der User braucht für alle Werte von Außerhalb zwei Felder: IP-Adresse und Registeradresse.
Dann Timer für die unterschiedlichen Umstellungen:

• Laden/Phasenumschaltung erst wenn Überschuss mindestens X Minuten vorhanden war
• Laden beenden/Phasenumschaltung wenn Bezug mindestens X Minuten vorhanden war

Alle 10 Sekunden die Werte abfragen, die maximale Ladelsitung berechnen, durch Volt der Phasen teilen = Ampere.

[gyroslav]

Das Intervall noch als User-Feld wäre auch gut, weil nicht alle Geräte können immer gleich schnell antworten. Da sollte der User dann selber anhand der Modbus Dokumentation seiner Geräte einstellen können.
Die SHM2.0 feuert jede Sekunde sein ganzes Wissen per Broadcast ins Netzwerk.

Mögliche Standardszenarien wären:

• kein Bezug (also wirklich nur das laden, was sonst eingespeist worden wäre)
• Min + PV (Mindestens 1ph + 6A, und dann was noch vorhaden ist)
• Schnellladen (3ph 16A, egal was PV sagt)

Wann stopp ist, wird dann das Auto schon selber sagen, oder halt der User per App.

[chk2902]

Jepp, das sollte grob reichen.

PS: Wolkenüberbrückung (zur Verminderung der Schaltzyklen), dafür Heimspeicherpriorisierung (damit der die Überbrückung "finanziert") nicht vergessen.

[gyroslav]

Für die Überbrückung sind die Timer-Felder, die der User frei wählen kann. Sollte also eine Wolke kommen, regelt die WB auf MIN runter,
bei 3ph setzt dann der Timer fürs Umschalten auf 1ph ein. Bei 1ph setzt der Timer für das Stoppen ein. Geht die Wolke in der Zeit weg, wird der Timer unterbrochen, die Regelung läuft normal weiter.
In meinem Fall sind das 5 Minuten jeweils z.B.

Während der Bezugszeit würde der Heimspeicher ja sowieso unterstützen, weil der WR am Hausübergabepunkt einen Bezug feststellt.

[0xFEEDC0DE64]

Der neue api key heißt "ids" und ich beschreibe den bald auf unserer api docs

bsp. value: {"pGrid": 1000., "pPv": 1000., "pAkku": 1000.}, jeder key kann optional weggelassen werden, nur pGrid zu senden wäre zb legitim.

[0xFEEDC0DE64]

der api key ist set-only, in älteren firmwares gab es schon die read-only api keys pgrid ppv und pakku. Ich wollte explizit nicht das setzen der einzelnen keys implementieren, da es für alle 3 leistungswerte einen gemeinsamen zeitstempel gibt, wie alt der wert ist. und wenn jemand immer wieder ppv setzt und pgrid dann vergisst, würde pgrid "am leben bleiben", obwohl es nicht mehr gesetzt wird. daher jetzt der unified api key "ids", wo man gleich alle drei setzen kann oder eben einzelne weg lässt, und das gesamt-paket erhält dann einen zeitstempel.

auslesen von set-only api keys sollte eh nicht gehen :D

schau einfach, ob er beim setzen sagt "unknown api key ids" oder ob ers frisst

[ICarryTheDustOfAJourney]

er frisst es.

Hatte nicht auf dem schirm, dass es write-only werte gibt 🙄

[gyroslav]

Welcher KEY ist denn dieser Schalter?

[ICarryTheDustOfAJourney]

Ich habe es so verstanden, dass der ECO-Modus bedeutet, ökonomisch zu laden.
Das kann sein mit PV Überschüssen und/oder mit günstigen Strompreisen.

Unter Einstellungen -> ECO-Modus konfiguriert man es, unter Laden -> Modus aktiviert man es.

Die Werte im ids API kann man aber nicht in der App setzen, die müssen laufend von irgendwo (aus meiner Anwendung z.B.) der Box eingeflüstert werden. Erst das aktiviert das Überschussladen schlussendlich.

[0xFEEDC0DE64]

@gyroslav lmo: 3 bedeutet default, keiner angehakt, 4 bedeutet nur ECO Modus angehakt, 5 bedeutet Next Trip modus angehakt, beide gleichzeitig geht nicht)

[JochenFriedrich]

Interessant wäre dann noch zu wissen, wie man PV Laden bzw. das Szenarium aktiviert.

[0xFEEDC0DE64]

Die App hat es inzwischen rausgeführt, sonst über die API:
lmo auf 4 setzen (Auf ECO Modus setzen)
fup auf true setzen (usePvSurplus aktivieren)

und alle 5 sek ids setzen.

[kxmm]

Was ist das Minimum wie oft man die werte setzen muss. Aktuell bekomme ich von der PV und vom Smartmeter jede Minute einen Wert. Ich kann auch öfter einen Wert senden, dann ist es aber immer der gleiche...

[k3067e3]

#110 (reply in thread)

[0xFEEDC0DE64]

mit dem nächsten app update wird "PV Überschuss" bei den ECO Einstellungen sichtbar,
der api key "fup" muss auf true sein (ist eh schon dokumentiert), dieser aktiviert nämlich das pv überschuss laden.

[0xFEEDC0DE64]

ist im playstore verfügbar

[ICarryTheDustOfAJourney]

Wenn lpsc der Timestamp der letzten Surplus-Berechnung ist, was ist dann eigentlich lps?

[ange12lo]

Ich habe die neuen Funktionen probiert.
Mir ist nach wie vor unklar wie und bei welchem KEY ich die Werte

Egal was ich setzen will bekomme ich diesen Fehler. Zudem habe ich auch nicht verstand ob dieser werte überhaupt gesetzt werden müssen oder wie ich dem go-e diese mitgebe.

Der KEY "FUP" ist bereits auf true.

{ "pgrid": "pgrid: tried to set api key without setter (1200)" }

[0xFEEDC0DE64]

Wie löst ihr die Sache mit dem ZIEL-SOC? Also dass das Auto z.B. nur bis 80% geladen wird?

Bei mir steckt ein OBD2 Bluetooth dongle immer im Ioniq und ein Raspberry Pi hängt direkt vorm Auto in der Garage mit Display (für simple Ladestatistiken), den SOC auszulesen und den Charger zu stoppen solle damit leicht umsetzbar sein.

[flba]

Hallo,

irgendwie scheint die Sache (zumindest bei mir :-) auch noch ein paar Haken zu haben. Ich habe eine Go-E Gemini Flex Charger V4 und bin auf der FW 055.5 bzw 055.6 . Vermutlich mache ich irgendetwas Banales falsch, aber nach Tagen des Herumprobierens bin ich dann doch etwas ratlos.
Nach vielen merkwürdigen Effekten habe ich mir ein einfaches Testsetup gebaut. Ein Script schickt alle 3 Sekunden ids= ... an die Box und ich kann einfach ändern, was als pGrid gemeldet wird. Die anderen Parameter scheinen ja keinen Einfluss auf die Berechnung der Ladeleistung zu haben.

Das Absetzen der Werte selber ist problemlos ... api/set?ids={"pGrid": -2000.0} -> {'ids': True} Ausserdem ist bei mir lmo 4, fup ist true und ich habe simulated unplug enabled. Der Rest sind einfach die Werkseinstellungen ...

Die Sache sieht überschaubar aus, aber leider funktioniert bei mir das mit der Anpassung der Ladeleistung über ids= im besten Fall erratisch. Hier ein paar Effekte, die bei mir auftreten:

• manchmal steigt die Ladeleistung nach einem Wechsel von 1 auf 3 Phasen auf das Maximum (11kw) an, obwohl mit pGrid (z.B. -5000) deutlich weniger verfügbare PV Leisung signalisiert wird. Die App reported dabei brav 11kw Ladeleistung aufgrund von PV Überschuss (gemeldet werden via ids pGrid -5000) . An pGrid zu schrauben, bringt keine Änderungen ...

• manchmal findet ein Phasenwechsel von 1 auf 3 Phasen statt, obwohl der über pGrid gemeldete verfügbare Wert (-3000) deutlich unter den konfigurierten 4200 Watt für einen Phasenwechsel liegt.

• manchmal klappt das Anpassen der Ladeleistung nicht oder schlecht. So wird bei pGrid -2000 nur mit 1Phase 6A (1.3 kw) geladen. Bei -3000 dafür dann mit 3Ph und 6A (4kw).

Irgendwie komme ich im Moment nicht wirklich weiter und habe deshalb ein paar Fragen:

• Wenn ich ein pGrid von -2000 sende. Heisst das, dass die Go-E insgesamt 2000 Watt verbrauchen darf oder heisst das, dass die Go-E zusätzliche 2000 Watt verbrauchen darf ? Ein Beispiel: Die Go-E lädt mit 9kw, pGrid ist -2000. Heisst das, dass die Go-E nun mit 11kw laden soll, oder heisst das, dass die Go-E mit 2kw laden soll ?

• findet die Anpassung der Ladeleistung in 1 Ampere Schritten statt oder sind nur die konfigurierten 5 Stufen erlaubt ?

• wie schnell passt die Go-E die Ladeleistung an ? Die geforderten Sekundenintervalle für ids deutet darauf hin, dass das sehr schnell passiert, aber bei mir tut sich da irgendwie nicht so viel :-(

ich hoffe mir kann jemand weiterhelfen ...

[povlhp]

PGrid is data from your meter. Total house import/export including charger.

So when charger starts an effect on pgrid is expected.

If you keep sending -2000 it should go to 11kW as you keep saying it can use 2000W more than it currently uses.

[gyroslav]

Du musst dein -pGrid zumindest um die Leistung der WB reduzieren, sonst denkt die WB, dass es immer noch 2KW Überschuss gibt.

[flba]

PGrid is data from your meter. Total house import/export including charger.

So when charger starts an effect on pgrid is expected.

If you keep sending -2000 it should go to 11kW as you keep saying it can use 2000W more than it currently uses.

Thanks for the help ! I haven't been aware of that. This is exactly what happens, my Go-E ramps up to the max :-D Now I know what to fix

regards

[gyroslav]

Meine Intention war eigentlich, dass der Charger sich die Daten selber über Modbus holt.
Ich ihm also nur die Adresse der jeweiligen Felder nenne, und die Kommunikation zwischen Charger und Wechselrichter läuft von allein.
Aber OK, das ist jetzt schonmal wesentlich einfacher, als vorher.

[0xFEEDC0DE64]

Mit modbus habe ich eigentlich nur schlechte Erfahrungen gemacht, oft werden mehr-registerige Werte in der falschen Register-Reihenfolge implementiert, oft wird die byte-Reihenfolge innerhalb eines Registers falsch herum implementiert, oft sind komische Faktoren und Bit-Shiftings notwendig, oft werden obskure Datentypen gewählt (16bit float schon mal gesehen?), ... das alles einstellbar gestalten ist eine Herausforderung 👍

[FransOv]

Ich bekomme "unknown api key: ids" wenn ich diese key über mqtt setzen will. Wen ich es versuche über die http api bekomm ich "null". Wie soll dass url exact aussehen um ids zu setzen.

[rsulzenbacher]

MQTT hab ich nicht probiert, aber über HTTP sieht das bei mir folgendermaßen aus:
http://192.168.x.x/api/set?ids={"pGrid":741,"pAkku":0,"pPv":18}
als Antwort kommt dann:
{"ids":true}
Meine Firmware Version ist 055.5 Beta.

[FransOv]

Ich hatte Firmware 0.55.0 dan gibt es "null". Mit 0.55.0 Beta bekomme ich auch {"ids":true}

[0xFEEDC0DE64]

ja inexistente api keys werden noch schlecht reported, ab 0.55.0 Beta ist der key eben mit dabei.

[FransOv]

Mit MQTT geht's jetzt auch.

[FransOv]

Ich habe Home Assistant so eingerichtet dass jeder 5 Sekunden über MQTT die ids Parameter eingegeben wirdt. Jetzt kann ich die Werte abfragen: {"pgrid":-727,"ppv":1424,"pakku":0}, weiss aber nicht was die Go-e charger damit macht. Ich kann es nicht weiter testen denn das Auto ist nocht nicht da, dauert leider noch einige Monaten. Gibt es eine Beschreibung wie die G0-e charger mit diese Parameters wirkt.

[ICarryTheDustOfAJourney]

Habe eine E3DC S10 und eine go-e gemini flex. Habe auch damit herumexperiementiert. Habe kein Home Assistant, aber in meiner selbst geschriebenen Anwendung wirkt sich das so aus:

Man kann in der go-e Handy-App die gewünschten Parameter setzen und den ECO-Modus aktivieren. Habe aber mangels gutem Wetter und fehlendem Auto (ist bei der Arbeit) noch wenig Erfahrung damit. Mein Updateintervall an die e-go war 3 Sekunden, das Abtastintervall der Grafik 1 Sekunde.

Man kann aber schon ein paar Dinge erkennen:

• die Ladeleistung (blau) folgt mit etwas Totzeit quantisiert der zur Verfügung stehenden Leistung.
• beim Umschalten der Phasen (für niedrigere Leistung) gibt es kurze Ladepausen
• hier nicht sichtbar: wenn der PV-Akku geladen wird (grün), hat das keinen Vorrang. Bei einem leeren PV-Akku wird trotzdem nur das Auto geladen, sobald die PV-Leistung dafür ausreicht.
• wenn es kurzfristig zu höheren Ladeleistungen kommt als die PV-Leistung (gelb) hergibt, holt sich die S10 die Differenz aus dem Akku (16:20 ist die WP angesprungen)
• das Auto selbst kann die Leistung entsprechend dem SOC zusätzlich herunter regeln, was dann zu mehr Einspeisung führt (rot, negativ)

Der Hausverbrauch (weiß) enthält die Ladeleistung der Wallbox, denn aus Sicht der S10 ist sie ein gewöhnlicher Verbraucher.

Edit:
Ungenauigkeiten korrigiert
Edit2:
Korrektur

[dabbelju007]

Hallo zusammen,

ich würde mich gerne hier dran hängen, weil ich grade auch mit einem goe das Überschussladen hinbekommen möchte. Ich habe mir die Diskussion in Ruhe durchgelesen aber es klappt noch nicht. Ich habe probiert die Keys über MQTT oder die HTTP API zu schicken. Ein goe zum testen mit Auto dran ist vorhanden.

In der APP habe ich das PV Überschussladen eingeschaltet und den Wert "Leistungsniveau beim Start" auf 1,4 kWh belassen. Den Key ppv schicke ich alle 5 Sekunden per HTTP API an den goe. http://x.x.x.x/api/set?ids={"pPv":1500}.

Den Key fup habe ich über den gleichen Weg auf true gesetzt. http://x.x.x.x/api/set?ids={"fup":true}

Alle request über die HTTP API bekomme ich auch mit {"ids":true} quittiert.

In der APP sage ich dann "Start Ladevorgang" und das Auto fängt an zu laden. Aber eben nicht mit den 1,5 kWh sondern mit dem, was in der APP hinterlegt. Bei meinem Test 10 Ampere also ca. 2,3 kWh und das auf allen drei Phasen. Also lädt das Auto mit ca. 6,8 kWh.

Wenn ich mir den Status über die HTTP API angucke sehe ich auf die Werte. Also ppv bei 1500 und fup auf true. pgrid und pakku habe ich erst mal verbachlässigt. Die stehen auf null.

Die FW version auf dem goe ist die 055.5 Beta.

Kann mir jemand bitte einen Hinweis geben was ich eventuell falsch mache?

Danke euch im Voraus!
Christian

[0xFEEDC0DE64]

seriennummer und genauen zeitpunkt? ich würd nachschauen, was der charger in dem moment gedacht hat

[dabbelju007]

@0xFEEDC0DE64 Seriennummer ist 209339. Den genauen Zeitpunkt kann ich nicht sagen. Es war am 30. März Vormittags. Ich kann das aber gerne mal reprudizieren und den genauen Zeiptunkt nennen. Alternativ: Gibt es eine Möglichkeit zu sehen, was der charger denkt zur Verfügung zu haben?

[0xFEEDC0DE64]

pPv ist korrekt angekommen, aber fup bitte ihne ids und json object drum rum schicken. Ausserdem verwenden wir pPv eigenltich nur um in der App die Quelle des Stroms anzuzeigen. Die Regelschleife regelt eigentlich nach pGrid (sodass am Einspeispunkt nichts bezogen oder eingespeist wird.)

Initiales setup:
http://x.x.x.x/api/set?fup=true
http://x.x.x.x/api/set?lmo=4

Dann immer wieder
http://x.x.x.x/api/set?ids={"pPv":1500,"pGrid":1500}

[FransOv]

Ich weiss nicht wie dass Go-e alles berechnet, aber pv Überschuss ist Sonnestrom die nicht sebst gebraucht wird aber ins Netz geht. Dass macht man an das Apparat bekannt mit eine negatieve wert von pGrid. Allerdings sollte man die nicht gebrauchte Werte bestens auf 0 einstellen und nicht die lere Wert "null".

[dabbelju007]

Danke.

Jetzt wo ich es lese: logisch. Wenn ich den pgrid setze und die anderen beiden 0 fängt er an zu laden mit dem Hinweis "Laden mit XY KW des PV-Überschusses".

Allerdings ist mir überhaupt noch nicht klar wie die Ampere oder Leistung berechnet wird, die dan nauch gelacne wird.

@0xFEEDC0DE64: Gibt es die Möglichkeit das Ergebnis der letzten Berechnung auszulesen? oder kannst Du mir einen Tipp geben, wie das berechnet wird? Ich habe zu Beispiel pgrid auf -1200 gesetzt und er hat angefangen zu laden. Und das mit 3kW.

Danke und Gruß
Christian

[ICarryTheDustOfAJourney]

Das Angenehme an der "ids-Lösung" ist, dass man das nicht selbst berechnen muss. Die Box nimmt die angebenen Leistungen und berechnet sich die zum Laden zur Verfügung stehende Leistung und damit Stromstärke selbst. In meiner Grafik oben kannst Du das sehen. Es kann ein paar Sekunden dauern, bis die Parameter angepasst werden.

Die Randbedingungen für diese Berechnung kannst Du in der go-e App unter Einstellungen-> Eco-Modus -> PV-Überschuss vorgeben (z.B. wann Phasenwechsel, Minimalleistung, Optimierungsstrategie). Vermutlich kann man die auch über das API setzen, wenn man möchte.

Edit: Und immer daran denken, dass das Auto je nach SOC die Leistung auch selbst runtreregeln kann.

[dabbelju007]

Das habe ich auch so verstanden und finde es großartig! Ich habe mir das auch heute noch angeschaut bis das Auto "leider" zu 100% geladen war. Und danke für den Hinweis mit dem Auto. Da hatte ich beim ersten mal drüber gestolpert. Seit den Tests gestern war da nix mehr runtergeregelt.

Aber dennoch würde ich nach den Beobachtungen heute Morgen sehr gerne verstehen, warum da ein Unterschied zwischen pgrid und der tatsächlichen Ladeleistung von ca. 700 Watt pro Phase ist.

In meinem getesteten Fall: pgrid -1500 (W) und geladen hat der goe mit ca. 2,2 kW. Als ich das testhalber erhöht habe auf pgrid -4500 srpingt er auch nach einer gewissen Zeit auf drei Phasen um lädt dann aber mit 6,6 kW.

In der APP stehe die Werte wie folgt:
Leistungsniveau beuim Start (fst): 1,4 kW
3-Phasen-Leistungsniveau (spl3): 4,2 kW
"Phasen-Handling" (psm): auto
"Strommengen Handling" (frm): Standard

[FransOv]

Die Text im App bei eco-mode - ppv überschuss sagt dass das Auto nur stufenweise geladen werden kan. 1500W=>6.5A. dass ist mehr als Stufe 1. Ist Stufe 2 vielleicht 10A. Dass könnte etwa stimmen mitt 2200W. Was geht wenn frm ist 2: PreferPowerToGrid. Dan sollte der Go-e 6 statt 10 wählen müssen.

[ICarryTheDustOfAJourney]

Das ist ein Beispiel von mir von gerade eben. Blau go-e, rot Netz, grün Akku, weiß Hausverbrauch incl WB, gelb PV

Man sieht gut, wie die WB die Überschüsse dynamisch weglädt. Ab und zu kostet es etwas PV-Akku, ab und zu lädt der Akku nach. Um 18:01 gibt die WB ganz auf, weil die Wärmepumpe angesprungen ist und keine Überschüsse mehr da sind. Das Netz zappelt um den Nullpunkt.

Nur alle 5 Sekunden ein ids.

[dabbelju007]

Hi @ICarryTheDustOfAJourney,

das sieht wirklich gut aus. Ich konnte es heute leider nicht testen, da das Auto unterwegs war. hattest Du da eine Phasen Wechsel drin? Und wie war das beim "ausschalten"? Welche Werte hat der goe da bekommen?

Danke und Gruß
Dabbelju

[ICarryTheDustOfAJourney]

• vermutlich kein Phasenwechsel, denn das hätte zu einer sichtbaren Unterbrechung des Ladens geführt
• die Akkuleistung dürfte den Ausschlag für den Abbruch des Ladens gegeben haben
• die per ids übertragenen Werte sind die, die in dieser Grafik angezeigt werden

[kxmm]

pPV und pGrid sind mir klar. eine Frage zu pAkku: Sind negative Werte eine Entladen / oder Laden des Akkus?

[k3067e3]

#110 (reply in thread)

[FransOv]

Hier aber Phase Wish Mode denke ich.

[gyroslav]

Ja das ist unglücklich irreführend.

[dabbelju007]

Das bringt mich zu dem Thema der Timer. Dazu hatte ich auch was gesehen.

mptwt min phase toggle wait time (in milliseconds) steht bei mir bei 600 Sekunden. Also 10 Minuten. Das wird die Logik sein, dass man nicht alle paar Sekunden von ein auf dreiphasig oder umgekehrt wechselt, weil das keiner WB gut tun würde.

Ich würde gerne sehen können, wie lange die letzte Umschaltung her ist.

Und wie der dazu passt ist mir auch noch nicht klar. mpwst min phase wish switch time (in milliseconds).

Zum pwm steht in der Doku: phase wish mode for debugging / only for pv optimizing / used for timers later (Force_3=0, Wish_1=1, Wish_3=2). Da würde ich glaube ich gar nicht dran schrauben wollen. Das macht der goe schon mit etwas versatz (Timer?!?) selber.

Auf jeden Fall freue ich mich sehr über den regen Austausch hier. ;-) Danke dafür.

[gyroslav]

mpwst ist wahrscheinlich der Punkt Einstellungen -> Fahrzeug -> Phasenumschaltung Dauer, sprich wie lange lässt die WB dem Auto Zeit sich an die neuen Phasen anzupassen.

[gyroslav]

Was machen auch die Keys psh, po und zfo?

[chk2902]

"pwm" ist korrekt: "Pulse Width Mode"

"Die Pulsweite (der duty cycle) des Rechtecksignals gibt die entnehmbare Stromstärke an"

[kxmm]

I just initialize the FUP the rest is set by the App :-)

//pGrid negativ heißt einspeisen, pGrid positiv heißt beziehen
//pAkku negativ heißt aufladen, pAkku positiv heißt entladen
//pPv negativ heißt standby, pPv positiv ist PV-Produktion

$query="http://".$go_e_IP."/api/status?filter=fup";
log_schreiben($query,"",4);
$ch = curl_init($query);
$rc = curlGo_e( $ch );
log_schreiben( "- RC Result Set IDS Result ".$rc["result"],"", 3 );
if ($rc["result"]!='{"fup":true}'){
    log_schreiben( "- FUP Setzen ","", 3 );
    $query="http://".$go_e_IP."/api/set?fup=true";
	log_schreiben($query,"",4);
	$ch = curl_init($query);
	$rc = curlGo_e( $ch );
	log_schreiben( "- RC Result Set IDS Result ".$rc["result"],"", 3 );   
}
............
	   $query="http://".$go_e_IP."/api/set?Ids={pPv:".$PV_Power.",pGrid:".$Grid_Power.",pAkku:".$Batt_Power1."}";

I realized that it is important to use on command to send the data.

[mr-gosh]

How do you trigger this stuff in Homeassistant?

[Nils1966]

Das mit dem Überschussladen funktioniert nicht so richtig. Zumindest das Laden beenden, wenn nicht mehr ausreichend Überschuss zur Verfügung steht, klappt meiner Meinung nach nicht.
Aktuell liefert mein PV-Kraftwerk ca 600W:

Wie man auf diesem Bild schon sieht, werden 3,9 kW verbraucht, wobei 3,4 kW aus der Batterie gezogen werden.
Von den 3,9kW Verbrauch werden 3,5kW von der go-e Wallbox in das Auto geschoben.
In meiner HA Karte stellt sich das so dar:

wobei "current power" der variablen nrg_12 entspricht.

Ich hätte eigentlich erwartet, dass der go-e charger selbstständig das Laden beendet, wenn nicht mehr genügend PV-Überschuss vorhanden ist, und dann nicht den Haus-Akku leerzieht.
Oder sind meine Ansprüche an die Überschuss-Lade-Funktion des go-e chargers hier zu hoch, und ich muss das von außen steuern?
Dann aber wäre die Frage: wie kann man denn das Laden beenden - so dass es, wenn wieder genügend PV-Überschuss vorhanden ist, wieder alleine startet?

[GruenerVeltliner]

Ich habe auch einen Kostal WR mit BYD Speicher und go-e charger.
Bei mir funktioniert es, ohne den Speicher zu entladen. Ich sende alle 5sec. die Werte Power from grid, Power from solar panels und Power from battery an den go-e charger.

In der go-e app kann unter dem Menüpunkt Eco->PV-Überschuss ein Offsetwert (Netzbezug oder Einspeisung) eingestellt werden. Wenn der BYD Speicher noch nicht voll ist, wird mit dem Offsetwert dieser geladen und wenn der Hausspeicher voll ist, wird dieser Wert in das Stromnetz eingespeist.
Hatte bisher auch schon 3x das Problem, dass die Ladung bei Netzbezug bzw. Speicherentladung nicht mehr stoppte. Hier hat jeweils ein Reboot der WB geholfen.

[gyroslav]

  Wenn ich die Kommentare/Diskussion bisher richtig verstanden habe, nutzt die Go-E nur den p-grid als Wert zum Rechnen. p-PV und p-Akku dienen nur der Anzeige in der App, woher die Energie kommt.   Wenn du nicht willst, dass der Akku entladen wird, musst du p-Grid um den Akku-Wert bereinigen. Und je nachdem welche Prio die Wallbox oder der Akku haben, dann entsprechend anders Rechnen.   Nehmen wir an, die Wallbox hat Prio1: "HAUS" > 0 = Bezug aus Netz, "HAUS" < 0 = Einspeisung ins Netz. "AKKU" > 0 = Akku lädt auf mit Überschuss, "AKKU" < 0 = Akku entlädt ins Haus.   dann ist p_Grid =  HAUS - AKKU   Beispiel:  HAUS = -2000, AKKU = +1000   --> p_Grid = -2000 - 1000 = -3000  --> Lädt mit 3KW ins Auto. Beispiel: HAUS = 0, Akku = -3000 --> p_Grid = 0 - (-3000) = + 3000 --> kein Überschuss, keine Ladung.     Gesendet: Sonntag, 10. März 2024 um 15:50 Uhr Von: "Nils1966" ***@***.***> An: "goecharger/go-eCharger-API-v2" ***@***.***> Cc: "gyroslav" ***@***.***>, "Mention" ***@***.***> Betreff: Re: [goecharger/go-eCharger-API-v2] PV-Überschuss in Firmware einbauen? (Discussion #110)   Das mit dem Überschussladen funktioniert nicht so richtig. Zumindest das Laden beenden, wenn nicht mehr ausreichend Überschuss zur Verfügung steht, klappt meiner Meinung nach nicht. Aktuell liefert mein PV-Kraftwerk ca 600W: grafik.png (view on web) Wie man auf diesem Bild schon sieht, werden 3,9 kW verbraucht, wobei 3,4 kW aus der Batterie gezogen werden. Von den 3,9kW Verbrauch werden 3,5kW von der go-e Wallbox in das Auto geschoben. In meiner HA Karte stellt sich das so dar: grafik.png (view on web) wobei "current power" der variablen nrg_12 entspricht. Ich hätte eigentlich erwartet, dass der go-e charger selbstständig das Laden beendet, wenn nicht mehr genügend PV-Überschuss vorhanden ist, und dann nicht den Haus-Akku leerzieht. Oder sind meine Ansprüche an die Überschuss-Lade-Funktion des go-e chargers hier zu hoch, und ich muss das von außen steuern? Dann aber wäre die Frage: wie kann man denn das Laden beenden - so dass es, wenn wieder genügend PV-Überschuss vorhanden ist, wieder alleine startet? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[povlhp]

Nur pGrid wird verwendet. Die andere sind für display-only gedacht,.

[Nils1966]

Das ist mir alles klar, steht hier auch mehrfach erwähnt. Das Laden an sich klappt ja auch ganz gut. Das Problem tritt dann auf, wenn der PV Überschuss gegen Nachmittag abnimmt, bzw. irgendwann keiner mehr da ist.
Da diese Funktion (auch in der go-e APP) "Mit PV Überschuss laden" heißt, würde ich erwarten, dass genau das auch gemacht wird: wenn PV Überschuss vorhanden ist wird geladen, ansonsten nicht.
Und genau das funktioniert meiner Meinung nach nicht: wenn kein PV-Überschuss (mehr) zur Verfügung steht, wird trotzdem weiter geladen, und nicht das Laden automatisch beendet.
Aber vielleicht habe ich ja auch nur einen der unzähligen Parameter in der APP falsch eingestellt.

Wie ist das denn bei euch so - funktioniert das bei euch? Beendet die WB das Laden von alleine, wenn kein PV Überschuss mehr da ist? Oder habt ihr das von "außen" selbst angesteuert (z.B. durch "manipulieren" von pGrid, wie oben von @gyroslav vorgeschlagen)

[povlhp]

Works fine for me. And I can combine with low electricity price as well. Then it will charge @ 11kW even when no sun.

I do all control in the app, just feeding it the import/export values.

[ICarryTheDustOfAJourney]

Bei mir funktioniert es wie erwartet, manchmal mit etwas Totzeit von ein paar Minuten. Jedenfalls wird die Ladung beendet, wenn nichts mehr vom Dach kommt.

Allerdings ist es so, dass die Überschussladung übersteuert wird, wenn man den Button an der WB 2x drückt. Dann beendet das Auto die Ladung. Vermutlich machst Du das aber nicht.

Falls Du ein E3DC "Hauskraftwerk" hast, kann ich Dir meine Windows/MacOS-App zur Verfügung stellen.
Es braucht keinen Server, installiert keine Dienste und ist portabel.

[HeikoG67]

Bei mir funktioniert es recht gut.
Lediglich die Phasenumschaltung dauert halt, was bei schnell wechselnder Bewölkung lästig werden kann. In dem Fall hilft bei mir die manuelle Umschaltung auf 1 Phase sehr gut. Hängt aber natürlich von der installierten Leistung ab.
Ich sende PVGrid im Sekundentakt über ein kleines Script auf einem Raspberry Pico, welches den Wert vom WR liest und diesen dann an GOE sendet.

[l3u]

Nur um das hier mal erwähnt zu haben: Meine Lösung für PV-Überschuss-Laden mit dem go-e-Charger ist https://gitlab.com/l3u/go-e-pvsd ;-)

[gyroslav]

Ja, ich hätte eigentlich auch erwartet, dass die Felder AKKU und PV irgendwie in die Rechnung einfließen. Wäre ja nur logisch. JETZT schaut die Go-E nur auf den Netz-Übergabe-Punkt (p_grid) und solange der nicht negativ wird, ändert sich aus seiner perspektive nichts.   Für Leute ohne Akku funktioniert es halbwegs gut. Für mich dauert die Umschaltung zwischen den Phasen oder die Regulierung der Ladeleistung zu Beginn einfach zu lange. Z.B. beginnt die Ladung immer mit voller Leistung 3Phasig, obwohl nur genug für 1 Phase da wäre. Die Anpassung an den aktuellen Überschuss dauert mir auch zu lange, so habe ich permanent leichten Bezug.   Ich kenne aktuell keine perfekte Lösung für die Go-E. Am ehesten vielleicht EVCC, aber mein letzter Stand ist, dass die Geld für den Support der Go-E haben wollen. Und selbst wenn, auch EVCC hat meine Usecases nicht alle abgedeckt, und so musste ich da auch selber Logik und externe zusatzsteuerung selber schreiben.   Letztendlich habe ich mir jetzt im IOBROKER ein Blockly Script zusammengeklickt, das meine Anforderungen zu 99% erfüllt.       Gesendet: Donnerstag, 14. März 2024 um 21:07 Uhr Von: "Nils1966" ***@***.***> An: "goecharger/go-eCharger-API-v2" ***@***.***> Cc: "gyroslav" ***@***.***>, "Mention" ***@***.***> Betreff: Re: [goecharger/go-eCharger-API-v2] PV-Überschuss in Firmware einbauen? (Discussion #110)   Das ist mir alles klar, steht hier auch mehrfach erwähnt. Das Laden an sich klappt ja auch ganz gut. Das Problem tritt dann auf, wenn der PV Überschuss gegen Nachmittag abnimmt, bzw. irgendwann keiner mehr da ist. Da diese Funktion (auch in der go-e APP) "Mit PV Überschuss laden" heißt, würde ich erwarten, dass genau das auch gemacht wird: wenn PV Überschuss vorhanden ist wird geladen, ansonsten nicht. Und genau das funktioniert meiner Meinung nach nicht: wenn kein PV-Überschuss (mehr) zur Verfügung steht, wird trotzdem weiter geladen, und nicht das Laden automatisch beendet. Aber vielleicht habe ich ja auch nur einen der unzähligen Parameter in der APP falsch eingestellt. Wie ist das denn bei euch so - funktioniert das bei euch? Beendet die WB das Laden von alleine, wenn kein PV Überschuss mehr da ist? Oder habt ihr das von "außen" selbst angesteuert (z.B. durch "manipulieren" von pGrid, wie oben von @gyroslav vorgeschlagen) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosordie]

Hallo,

wollt nur kurz meine Erfahrungen dazu berichten.
pAkku wird sehr wohl in der Berechnung verwendet. Ob das dann so funktioniert wie man sich das vorstellt steht auf einem anderen Blatt ;)
pPV ist tatsächlich nur zur Anzeige (wenn man einen Controller hat. Es währe cool wenn man dem GO-E einen echten Controller vorgaukeln könnte per NodeRed ect. ;) )
Wichtig ist bei pAkku: der Laden wert muss negativ sein, der entladen Wert positiv.
Wird also z.B das Auto mit 2kW geladen und in den Akku geht auch gerade ein 1 KW rein wird der GO-E die Ladeleistung auf 3 KW erhöhen.
Was er beim entladen des Akkus macht weiß ich gerade nicht mehr, da ich meistens pAkku mit 0 sende (somit kann ich besser den Akku und das Auto gleichzeitig laden)
Wenn ich das Auto schneller laden will schicke pAkku mit.

Bei mir schaltet der GO-E aber auch sauber ab, wenn weniger als 1,4 kW zur Verfügung stehen. (man muss geduld haben, glaube DeltaP wird nur alle paar minuten berechnet, damit nicht zu oft hin und her geschalten wird)

Einzig das Start Problem ist nervig. Bei Überschuss größer 1,4 kW startet er erst 3 Phasig und stellt dann fest dass ihm die Leistung nicht reicht. Das hab ich mit einer Logik eleminiert die die unter 4 kW überschuss manuell auf 1 Phasiges laden stellt.

Grüße
Dominik

[ICarryTheDustOfAJourney]

Wenn die Anwendung keine ids mehr sendet, lädt die WB bei Überschussladen trotzdem unverändert weiter.

Könnt ihr das bestätigen?

Wünschenswert wäre imho, dass nach einer gewissen Totzeit < 2 Minuten die Ladung eingestellt wird.
Sonst geht mein meine mühsam erkämpfte Autarkie in den Keller, wenn mal was bei der Übertragung der PV-Leistung klemmt.

[GruenerVeltliner]

Hatte ich bisher 3x, dass mit 1,4kW weiter geladen wurde, obwohl kein Überschuss mehr vorhanden war. Hier hat jeweils ein Reboot des go-e charger geholfen, dass wieder alles läuft.

[gyroslav]

#1: ja das sollte so sein, die WB richtet sich nach dem letzten bekannten p,_grid wert. #2: von Autarkie kann man sich nichts, kaufen. Sei froh, dass der Ladevorgang mit der Hälfte vom Land üne benommen wird. Q1

…

Gesendet: Freitag, den 22.03.2024 um 12:01 Uhr Von: Volki ***@***.***> An: goecharger/go-eCharger-API-v2 ***@***.***> Cc: gyroslav ***@***.***>, Mention ***@***.***> Betreff: Re: [goecharger/go-eCharger-API-v2] PV-Überschuss in Firmware einbauen? (Discussion #110) Wenn die Anwendung keine ids mehr sendet, lädt die WB bei Überschussladen trotzdem unverändert weiter. Könnt ihr das bestätigen? Wünschenswert wäre imho, dass nach einer gewissen Totzeit < 2 Minuten die Ladung eingestellt wird. Sonst geht mein meine mühsam erkämpfte Autarkie in den Keller, wenn mal was bei der Übertragung der PV-Leistung klemmt. -- Reply to this email directly or view it on GitHub: #110 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[ICarryTheDustOfAJourney]

#1 Genau das ist das Problem

Es kann dazu führen, dass man auch nach Mitternacht noch Überschussladen macht. Es wäre imho konsistenter, das Überschussladen einzustellen, wenn man länger keine Überschüsse mehr gemeldet bekommt.

[l3u]

Einzig das Start Problem ist nervig. Bei Überschuss größer 1,4 kW startet er erst 3 Phasig und stellt dann fest dass ihm die Leistung nicht reicht. Das hab ich mit einer Logik eleminiert die die unter 4 kW überschuss manuell auf 1 Phasiges laden stellt.

Das nervt ja total. Dann kann ich ja auch gleich die Logik selber machen.

Ich hab mir ernsthaft überlegt, ob ich meinen Daemon dahingehend vereinfache, dass ich die ganze Berechnungslogik rauswerfe, und mich drauf beschränke, dass ich die aktuellen Werte an die Ladestation übermittle. Aber scheinbar ist es doch besser, die volle Kontrolle zu haben, dann ist es zumindest keine Black Box, man weiß, was passiert – und man kann machen, was man will. Weil laufen muss ein irgendwie geartetes Programm ja eh, das die Daten übertägt. Dann kann man ja wirklich das bisschen Berechnung gleich auch selber machen.

[ICarryTheDustOfAJourney]

Kann ich so nicht bestätigen. Meine Anwendung startet die Überschussladung auch unter 2kW (also 1-phasig), siehe screenshot. Ich sende ausschließlich ids zur WB, den Rest stelle ich per App ein:

• "Automatische Phasenumschaltung"
• "Leistungsniveau bei Start 1 kW"
• "3-Phasen-Leistungsniveau 2 kW"

Ich hatte Deine Überlegung anfangs auch, aber das ist imho unnötiger Aufwand.

[martiko70]

Hallo zusammen,
ich habe meinen go-e (2.0) ganz neu (Firmware 56.5) und möchte das mit dem Überschussladen gerne schon mal vorbereiten (das BKW kommt in ein paar Wochen).
Doch obowhl ich die Tipps hier im Thread gelesen habe, funktioniert es irgendwie nicht...

Über Web-API konnte ich verfolgreich einige genannte Key setzen:
pgrid=2000&pakku=0&ppv=18
Da bekomme ich ein succeeded-Array zurückn in dem alle Keys mit den genannten Werten aufgeführt sind.

Doch schon wenn ich direkt danach die gleichen Keys per Status abfrage, sind alle drei Werte "null"...

EDIT: Wie ich jetzt in der API-Dokumentation gesehen habe, sind diese Keys auch eigentlich als nur lesend ("R") aufgeführt... Da frage ich mich, wie man über API das Überschussladen konfigurieren soll???

Und das hier häufig genannte "ids" wird egal ob beim Schreiben oder lesen mit
ids: "No such apikey on charger"
beantwortet.

Prinzipiell finde ich das umfassende API der go-e Charger super, aber eine zusätzliche Anleitung, welche Werte wie zu setzen sind um das Überschussladen (ohne Controller) zum Laufen zu bekommen.

Letztendlich sollten es ja nur ein paar Werte sein, die der Charger braucht, um das Ganze berechnen zu können und noch irgendwelche Schwellwerte.

Da das vom Hersteller nicht kommt, vielleicht kann sich ja jemand, bei dem es schon geklappt hat, die Mühe machen und das Ganze stichpunktartig zusammenschreiben?

Danke und Gruß
Martin

PS: Ist es eigentlich nochmal, dass man in der App keinerlei Konfigurationen zum Überschussladen machen kann, wenn kein Controller angeschlossen ist? Ich bekomme da nur die Anzeige, dass keine Daten verfügbar sind und kann nichts einstellen.

[k3067e3]

Also ich setze z.b folgenden Inhalt {"pGrid": -7909,"pAkku": -11,"pPv": 8676} via http API, das sende ich wegen den entsprechenden Zeichen die man "codieren" muss, auf folgende Art und Weise.

http://192.168.0.150/api/set?ids=%7B%22pGrid%22%3A%20-7909%2C%22pAkku%22%3A%20-11%2C%22pPv%22%3A%208676%7D

Als Ergebnis gibt es http_result {"ids":true}

Kannst ja einfach mal durch dein IP Adresse ersetzen und probieren.

Ich hoffe das hilft

[martiko70]

Hi,
erstmal danke für die Rückmeldung. Da ich meinen go-e leider nicht mit dem WLAN verbinden kann nutze ich nur Mobilfunk (ich habe auf den v2.0 mit eingebauter SIM gewartet) und kann daher nur per cloud-api darau zugreifen.
Da ist die Syntax eine andere, aber ich setzte ja prinzipiell die gleichen Parameter (das mit dem ids={ scheint aber meiner Meinung nach nur ein Syntax zu sein, um mehrere Paramter zu setzen".
Konkret sieht mein Aufruf so aus:
https://#SN#>.api.v3.go-e.io/api/set?token=#token#&pgrid=2000&pakku=-10&ppv=-18&ids=1&fup=true

Und als Antwort kommt dann:
"{"succeeded":[{"pgrid":2000},{"pakku":-10},{"ppv":-18},{"fup":true}],"failed":[]}"

ABER, wenn ich dann den Status über das API wieder abfrage kommt:
"{"pgrid":null,"pakku":null,"ppv":null,"fup":true}"

Was mich generell wundert ist, dass diese Parameter also pgrid etc. in der API-Dokumentation als Read-Only definiert sind (das R in der 2. Spalte):
pgrid R optional Status pGrid in W
ppv R optional Status pPv in W
pakku R optional Status pAkku in W

Ich habe go-e jetzt mal angeschrieben. Dass es so umfangreiches API gibt, finde ich super. Aber die Dokumentation ist grottig, zum einen steht bei vielen Parametern überhaupt nichts erläutert, was der beinhaltet/bewirkt und zum anderen fehlen eben so allgemeine Prinzipielen was man für bestimmte Aktionen setzen sollte (wenn man das Laden starten möchte, oder eben das Überschussladen konfigurieren möchte).

[FransOv]

Die API-Key "ids" ist nicht mehr aufgeführt, aber sie funktioniert immer noch über das LAN. Allerdings müssen die ids( oder pgrid,pakku,ppv )parameter alle 5 Sekunden eingegeben werden, da diese Parameter sonst zurückgesetzt werden.

[martiko70]

@FransOv
Ah ok… ich habe leider keinen LAN-Zugang zu meinem Go-e und muss daher das Cloud-API nutzen. Sehe ich es richtig, dass ich diese Werte dann wirklich nicht schreiben und somit keine PV-Überschussladung nutzen kann? :-(

[0xFEEDC0DE64]

Hallo, leider hat die Cloud-Api einen Bug, dass sie ein OK zurück gibt, obwohl der charger den api key gar nicht angenommen hat (zb wenn man versucht pgrid= zu setzen, geht ja lokal im LAN auch nicht zum setzen!)
und wenn man dann den korrekten setter verwenden möchte, ids, dann gibts aktuell einen bug, dass die Cloud im fullStatus vom charger nachschaut, ob der api key überhaupt existiert, und falls nicht, wird der apikey gar nicht erst an den charger übermittelt und direkt die Fehlermeldung ausgespuckt.
ids ist "setter-only", sprich der wird nie im fullStatus inkludiert sein und daher trifft uns hier der bug.

Wir arbeiten an einer verbesserten cloud-api, die dann immer alle api keys dem charger zukommen lässt und keine eigenen prüfungen mehr macht und die tatsächlichen fehler und erfolgsmeldungen des chargers zusammen wartet und präsentiert (sind dann mehrere websocket messages bei unserem internen cloud websocket).

Sobald die neue cloud-api live geht, können wir uns gerne hier nochmal bei euch melden.

Bis dahin geht's leider nur mit einem go-eController über die cloud mit den external category powers oder ids direkt am charger im heimnetzwerk (http-api oder MQTT)

[martiko70]

@0xFEEDC0DE64
Danke die die Erläuterung! Da mein Charger wie erwähnt nicht über WLAN erreichbar ist, bleibt mir nur der Weg übers Cloud-API.
Deine Erklärung bestätigt meine Erfahrung und es freut mich, dass Ihr es auch als Bug einstuft, dass ids zukünftig auch an über Cloud-API and den Charger gesendet werden kann.
Daher: ja bitte direkt Bescheid geben, sobald das korrigierte Cloud-API zur Verfügung steht!

Danke und Gruß
Martin

PS: Ich fände es toll, wenn ids offiziell unterstützt würde und auch in der API-Doku beschrieben wäre…

[FransOv]

Kann doch, Sie haben es getan via Cloud Api und das Resultat war "Succeeded". Aber die Werten sollen jeder 5 Sekunden eingegeben werden denn sie werden in weinige Sekunden wieder gelöscht.Frans OverkleeftDiessenseweg 245081AJ HilvarenbeekTel. 013-5051841Mob. 06-53223860

[martiko70]

Ich bekomme zwar ein "Suceeded" zurück, aber ich kann die Werte später nicht auslesen, danach sind sie immer "null".
Ich habe sie jetzt per Trigger sogar alle 3 Sekunden schreiben lassen, das ändert nichts.
Der andere Parameter (fup) kann beschrieben werden, da kann ich später auslesen was ich vorher geschrieben habe (true / false).
Meiner Meinung nach gibt es da jetzt zwei Möglichkeiten: Entweder, go-e will diese Funktion nicht über das Cloud-API zulassen (das wäre sehr ärgerlich, damit würde dann die eingebaute eSIM wenig Sinn machen), oder es ist vielleicht noch ein Bug im Cloud-API und wird (hoffentlich) mit einer kommenden Firmware korrigiert. Die Charger 2.0 mit dem eingebauten Mobilfunk sind ja noch ganz neu, vielleicht hatte man daran noch nicht gedacht oder es nicht rechtzeitig fertig bekommen.
Na mal sehen, das wird mir go-e ja sicher als Antwort auf meine Mail schreiben...

[k3067e3]

Hallo wie oben angeführt funktioniert es bei mir am Gemini - noch die Version ohne SIM lokal - wenn ich folgendes aufrufe.

http://192.168.0.150/api/set?ids=%7B%22pGrid%22%3A%20-7909%2C%22pAkku%22%3A%20-11%2C%22pPv%22%3A%208676%7D

Als Ergebnis gibt es http_result {"ids":true}

Nehme ich jetzt meinen Aufruf und baue ihn auf den Cloud Aufruf um und ich sende folgendes

https://Seriennummer.api.v3.go-e.io/api/set?token=MEINTOKEN&ids=%7B%22pGrid%22%3A%20-1316%2C%22pAkku%22%3A%201%2C%22pPv%22%3A%201979%7D

Kommt als Ergebnis

{"succeeded":[],"failed":[{"ids":"No such apikey on charger"}]}

Scheint so, als ob das nicht über die Cloud nicht aktiv ist, so nach dem Motto lokale Daten, müssen auch lokal geschrieben werden
Und ich denke es wird ohne ids nicht funktionieren.

[martiko70]

Genau das ist auch aktuell meine befürchtung. Vielleicht/hoffentlich ist das aber ja nur nur aktuell noch so und wird sich in einer kommenden Firmware ändern.
Denn wenn das dauerhaft nicht funktioniert, hätte ich mir den erheblichen Aufpreis für die neue Version mit Mobilfunkt auch schenken können. Also mal abwarten, was der Support dazu sagt.

[martiko70]

Die Antwort von go-e war leider nicht sehr hilfreich (siehe unten). Ich habe da jetzt noch mal nachgehakt, weil ich keine Lust habe, die ganze Logik und Steuerung selbst zu programmieren (oder einen der bestehenden, teilweise kostenpflichtigen Dienste zu nutzen). Ich hoffe sehr, da tut sich noch was, mit der aktuellen Firmware wird es aber vermutlich über Mobilfunk (bzw. Cloud-API) leider nicht funktionieren... Und das mit dem ids ist eben generell nicht dokumentiert und könnte daher jederzeit auch über lokalen Zugriff nicht mehr klappen.. Echt blöd.

vielen Dank für Ihre Anfrage!

Es gibt in der Tat Parameter, welche nicht weiter beschrieben sind, da diese teils nur von der im go-e Charger enthaltenen Logik genutzt werden.

Hier noch die Mail-Antwort:

Zum Überschussladen verwenden die meisten Integratoren die Parameter amp (Ladestrom einstellen), frc (Ladevorgang starten/beenden) und psm (Phasenumschaltung).

Der Parameter um eine Ladung per RFID-Konto freizugeben ist trx und tatsächlich auch dokumentiert:
https://github.com/goecharger/go-eCharger-API-v2/blob/main/apikeys-de.md#:~:text=trx,2%3A%201.%20card%2C%20...)

Die drei Parameter pgrid, ppv und pakku sind Parameter für die Werte, welche der go-e Controller an den go-e Charger übermittelt.
Dabei handelt es sich um Werte für den Hausanschluss, die PV-Anlage und den Akku sofern vorhanden und gemessen.

Der Parameter ids ist allerdings nicht offiziell dokumentiert und freigegeben.

Für weitere Fragen und Anliegen stehe ich Ihnen gerne zur Verfügung.

[l3u]

Die Antwort von go-e war leider nicht sehr hilfreich (siehe unten).

Ging mir letztes Jahr auch so

Ich habe da jetzt noch mal nachgehakt, weil ich keine Lust habe, die ganze Logik und Steuerung selbst zu programmieren (oder einen der bestehenden, teilweise kostenpflichtigen Dienste zu nutzen).

Vielleicht willst du ja mal meine Lösung go-e-pvsd ausprobieren? Funktioniert mittlerweile ganz ordentlich und ist – im Gegensatz zu einigem da draußen – „richtig“ Open Source und komplett kostenlos zu nutzen. Außerdem recht übersichtlich.

Der Parameter ids ist allerdings nicht offiziell dokumentiert und freigegeben.

Und exakt aus diesem Grund hab ich mir bisher nicht die Mühe gemacht, das go-e-eigene PV-Überschussladen zu nutzen. Theoretisch muss man ja nur eine Schnittstelle schreiben, die alle paar Sekunden die momentanen PV-Parameter an die Ladestation übermittelt. Aber dafür braucht es halt dann doch einen vernünftigen Daemon. Und der kann dann das bisschen Logik auch gleich noch selber machen. Weil sonst ändern die irgendwas (ist ja alles Stand jetzt noch inoffiziell), und dann war's für die Katz. Lieber gleich selber machen.

[martiko70]

Danke für die Rückmeldung. Ich schaue mir Deine Lösung mal an, aber eher um mir "abzuschauen", wie Du das gemacht hast, da ich selbst schon einige Dinge in NodeRed etc. am Laufen habe und nichts zusätzlichen machen möchte...

Hier übrigens die erneute Antwort von go-e, die vielleicht etwas Mut macht, aber letztendlich doch nichts neus beinhaltet:

vielen Dank für Ihre Nachricht!

Wir haben diese Parameter, da wir Sie ja eben selbst für die Regelung durch unseren go-e Controller benötigen. Zusätzlich können User:innen die Werte eben auch direkt auslesen, sofern dies für relevant ist.

Weshalb wir die Optionen in der App nicht einstellbar gemacht haben ist im Grunde ganz einfach zu erklären:
Wir haben in der vorherigen App-Version sehr oft die Erfahrung gemacht, dass User:innen die Option PV-Überschussladen aktiviert haben ohne einen go-e Controller zu besitzen. Es gab zwar einen Hinweis, welcher in roter Schrift zu sehen war, dass es dafür einen go-e Controller benötigt, allerdings wurde dies offenbar ignoriert und das Ergebnis waren zahlreiche Anfragen weshalb es denn nun nicht funktioniert.
In der neuen App haben wir uns dann dazu entschieden, dies vorerst nicht auswählbar zu machen. Allerdings reagieren wir auch hier auf Kundenfeedback und werden die Option mit einem der kommenden Updates wieder zur Verfügung stellen und es erneut mit einem Hinweis versuchen.
Bis dahin sind aber auch diese Einstellungen alle per API einstellbar (Parameter fup und lmo).

Der API-key ids ist auch derzeit nur für die lokale API verfügbar, d.h. eine Nutzung des Keys über die Cloud-API ist derzeit auch nicht möglich.
Ich gebe das aber gerne mal an die Entwicklung weiter.

Bis dahin muss ich Sie leider auf die Nutzung der Parameter amp, psm und frc verweisen, welche auch über die Cloud-API genutzt werden können.

Für weitere Fragen und Anliegen stehe ich Ihnen gerne zur Verfügung.