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.

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

[schinagl]

Was machen auch die Keys psh, po und zfo?

@0xFEEDC0DE64 Kannst Du uns weiterhelfen?

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

[erxbout]

Mit einem Firmware update sollte dieser parameter da sein!

[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

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

[schinagl]

Danke für den Input aus dem Thread. Ich hab nun ein Python Script 'geschnitzt', das die Daten des SolarEdge Wechselrichter ausliest, und sie im 5 Sekunden Takt zur go-e schreibt.

Als Abfallprodukt werden die SolarEdge Daten auch nach PvOutput.org gepushed

Funktioniert bestens.

[Dengo91]

Hallo, was macht den der Wert: pgt / Grid Target den man in watt setzen kann?

[schinagl]

Hallo, was macht den der Wert: pgt / Grid Target den man in watt setzen kann?

Nach viel probieren und lesen hier denke ich gibt das die Leistung an, die ins Netz fließen soll, und daher nicht von der Go-e gezogen wird. Sozusagen ein Puffer der im Haus bleibt, ins Netz geht oder in den Akku.

@GruenerVeltliner hat mir das erklärt: Du kannst damit realisieren, dass Leistung zu verschiedenen Teilen ins Haus geht oder ins Auto: Stell Dir folgendes vor:

• Du schickst mit ids pgrid und pakku (ppv is wurscht). pgrid und akku werden addiert, und die go-e zieht dran bis die Summe beider 0 ist: Sie nimmt sich alles.
• Nun möchtest Du aber nicht alles in Auto tun, weil z.b. Dein Auto Akku so groß und leer ist, dass Du ihn nie voll kriegst in einem Tag
• Dann setzt Du pgt auf den Wert mit dem Du den Akku laden willst.
• die go-e nimmt sich dann weniger, pgrid geht zwar wieder gegen 0, aber dafür fliest die Leistung in den Akku. Weil aber auf die Summe von pgrid und pakku geregelt wird, teilst Du dann den Leistungsfluß zwischen Auto und Akku

Correct me if I am wrong

[schinagl]

Ich füttere den goe- brav mit ids. Alles gut. Geht

Ihr schreibts zwar, dass ppv und pAkku keinen Einfluß haben, aber ich vermute schon:

Sunday morning. Akku auf 57%. Sonne geht auf, 500W am Dach, 500W fließen in den Akku, nichts gehts in Grid. -> Auto wird nicht geladen. gut
Das geht so dahin, Leistung am Dach wird mehr, Akku wird mit mehr geladen. Nix ins Grid -> Auto wird nicht geladen
Alles gut.

Aber irgendwann fängt das Auto an zu laden, und es ist garantiert nix ins grid gegangen, weil ja der Akku damit geladen wird.

Daher stell ich frech in den Raum: Wenn am Dach e.g. 1.6kW (oder ein Schwellwert) anliegen, und dieser Wert in den Akku geht, beschließt die go-e, dass sie sich das nimmt und das Auto lädt

Irre Theorie? Ich kanns mir sonst nicht erklären, warum die goe- das Auto zu laden beginnt, wenn nix ins Grid geht.
Habts ihr Ideen?

[dosordie]

Hallo, hab schon weiter oben geschrieben, dass PAkku sehr wohl verwendet wird.
#110 (reply in thread)

Ich sende einfach als pAkku eine 0 wenn ich den Hausakku bevorzugen will, und den richtigen pAkku wert wenn ich das Auto bevorzugt laden will

Grüße
Dominik

[schinagl]

Hallo, hab schon weiter oben geschrieben, dass PAkku sehr wohl verwendet wird.

#110 (reply in thread)

Ich sende einfach als pAkku eine 0 wenn ich den Hausakku bevorzugen will, und den richtigen pAkku wert wenn ich das Auto bevorzugt laden will

Danke! Meine Beobachtung deckt sich mit deiner.

@0xFEEDC0DE64
Wenn ich mir die Mühe mach und in einem PR die api keys sortiere, übernimmst den PR?

I würd dann auch das pakku verhalten dokumentieren

Hm? Yes? No?

[schinagl]

Ich sende einfach als pAkku eine 0 wenn ich den Hausakku bevorzugen will, und den richtigen pAkku wert wenn ich das Auto bevorzugt laden

Ich muss nochmal weiter philosophieren:

Pakku = 0 schicken geht, wenn ein Fluss in den Akku existiert. Somit erhältst du den Fluss und die go-e krallt sich den dann nicht. Gut.

Aber stell dir folgendes Szenario vor:
Akku auf 50%. Battery im Auto fehlen 40kwh. Am Dach 10kWp.
Sonne geht auf go-e schnappt sich alles, der Fluss in den akku versiegt. Pgrid == 0 und pakku == 0.
Bei ein bissi schlechtem Wetter und ein paar Waschmaschinen hab ich vl 5kW Überschuss und ich lade nun 8 Stunden bis das Auto voll ist und dann kommt der Akku dran. Dann ist aber finster. Grmpf

Pakku = 0 setzen hilft dann aber mittags nimmer

Was tun? Ich denk mir ich schalt immer um eg 1200 mit alw=false ab und lad den Akku und dann wieder das Auto. Hintereinander

Lieber wär mir wenn ich aber ab 1200 die Hälfte in den Akku schicken kann und die andere Hälfte ins Auto. Gleichzeitig. Nur wie? Kann ich die Ladeleistung auf eg 3kW limitieren ab 1200?

[schinagl]

Oder du nimmst den pgt = pGridTarget in W. Hier kannst du Leistung für die Batterie/Netz reservieren (negativer Wert).

Super Danke!
Heißt aber auch dass pgrid und pakku vom ids api key immer addiert werden, darauf geregelt wird.
Nur so kann pgt einen Einfluss haben, denn sobald was ins Grid fließt, das nicht vom goe genommen wird geht es in die Batterie und pgrid geht wieder auf 0 aber pakku enthält dann Wert von pgt.

Passt. Muss ich probieren. Danke!

[GruenerVeltliner]

denn sobald was ins Grid fließt, das nicht vom goe genommen wird geht es in die Batterie und pgrid geht wieder auf 0 aber pakku enthält dann Wert von pgt.

Genau, so ist es. Die Batterie holt sich dann alles was ins Netz gehen würde, wenn nicht eine Ladesteuerung das Aufladen des Speichers unterbindet.

[HeikoG67]

Seit Update von 56.2 auf 57.1 Wird bei mir im ECO Modus sofort aufgrund von PV-Überschuss geladen.
Obwohl IDS mit PGrid 0, PAkku500, PPv=0 im 5 Sekundentakt gesendet wird.
Sobald ich kein IDS mehr sende wird nicht mehr geladen.
Nach Rückkehr zu Firmware 56.2 ist auch alles wieder OK.
Muss ich seit einem Update noch zusätzlich etwas senden oder was hat sich geändert?

[GruenerVeltliner]

Ich muss den go-e charger vereinzelt rebooten, da es ab und an vorkommt, dass er die Ladung nicht stoppt obwohl via IDS kein Überschuss gesendet wird. Läuft danach wieder problemlos.
Eventuell versuchst du mal, die 57.1 zu laden und dann den go-e charger via Reboot neu zu starten.
Ich bin aktuell auf der v56.9 und kann keine Probleme feststellen und werde daher so schnell auch kein Update vornehmen.

[HeikoG67]

Reboot tut meistens gut. Lädt auch mit 57.1 jetzt nicht mehr.

[mdecker77]

Ich habe begonnen, mit "ids" zu experimentieren. Ich sende alle 2 sekunden den PvGrid Wert. Beim einphasigen Laden scheint das ganz gut zu funktionieren. Beim Phasenwechsel auf 3 Phasig wird aber nicht mit 6A sondern mit 8A geladen und dann kommt es zu Bezugswerten von 3kW über längere Zeit. Ich würde erwarten, dass er recht flott von 8A auf 6A reduziert und wenn es immer noch zu Bezugswerten kommt, dass er dann wieder auf 1phasig zurückwechselt. Aktuell sieht es so aus, als würde er direkt von 8A 3phasig auf 1phasig wechseln.

Gibt es API keys, die mehr Licht in die Umschaltautomatik und die Überschuß-Logik bringen?

[dabbelju007]

Ich denke weil die umschaltgrenze im Standard bei 4,2 kW liegt. Das sind rein rechnerisch 6,08 A.

Du kannst ja zwei Genzen festlegen: Startleistung (Standrd 1,4 kW) und Umschaltung auf drei Phasen (Standard 4,2kW).

Wir erfassen für unsere Kunden in einem separaten System die Daten zu den Vorgängen. Da sieht man eindeutig, dass der Charger das sauber regelt.

[mdecker77]

In welcher Frequenz wird die Leistung dem Überschuss angepasst?

[dabbelju007]

Das weiß ich nicht genau. Laut Go-E sollen die Werte alle 5 Sekunden geschickt werden und der Charger scheint es jedes mal zu bewerten und die Leistung entsprechend anzupassen.

[erxbout]

Die Minimalleistung in A ist in mca

Bei Autos wie von Renault glaubt das Auto, dass nichts mehr wirklich kommt und geht nach einer gewissen Zeit auf Standby..
Evtl ist hier 7A oder 8A eingetragen

[mdecker77]

Danke, ich habe jetzt einfach mca von 8 auf 6 reduziert und werde es morgen nochmals beobachten.

[zinkst]

Ich habe PV Überschuß laden per ids api implementiert wie hier beschrieben.
Die Werte für pGrid,pPV werden von 2 tasmota IR Sensoren von meinem Stromzähler abgelesen und per Mqtt an homeassistant geschickt. Home assistant sendet dann alle 5 Sekunden die aktuellen Werte über die ids api an den go-e und der macht dann das Überschußladen über seine Firmware. Das funktioniert seit 2 Jahren wunderbar.

Ich will jetzt einen zweiten go-e installieren.
Habe versucht herauszufinden ich die beiden go-e's dann programmieren muss so daß weiterhin möglichst nur mit PV Überschuß geladen wird.
Die Lösung von go-e wäre wenn ich das richtig verstanden habe ein go-e Controller. Der misst den Energiefluß dann über Stromzangen.
Das bräuchte ich aber eigentlich nicht und der Controller hat auch noch den Nachteil daß man ihn im Hauptzählerschrank anschließen muß. (Elektriker hab ich leider nicht so leicht im Zugriff)

Die go-e können (statisches ?) Lastmanagement in dem man beide go-e in der App alle in eine Gruppe aufnimmt.
Folgende Möglichkeiten habe ich dann

• die beiden go-e in eine Lastmanagment Gruppe aufnehmen und nur den ersten per ids api programmieren
• die beiden go-e in eine Lastmanagment Gruppe aufnehmen und beide go-e per ids api programmieren

Die Frage ist dann was passiert. Hat das jemand so schon mal probiert ?

[mr-gosh]

Ich habe das so laufen - es kam aber nur selten vor dass beide gleichzeitig laden.
Also das 2. Szenario.
Beide bekommen die Überschussinfos von Homeassistant und sind in einer Lastgruppe.

[zinkst]

Danke für deine Antwort.
Dann werd ich das auch mal so probieren.
Interessant ist das Szenario wenn beide go-e angesteckt sind und beide Autos laden könnten. Wenn dann immer noch nur PV Überschuß geladen wird wäre das super. Wie die go-e's dann den vorhandenen PV Überschuß verteilen wäre mir eigentlich egal hauptsache es wird nur Überschuß verbraucht.

[hanshoss-leibnitz]

Ich habe versucht das PV Üverschussladen über ids zu implementieren.
Ich sende alle 4 Sekunden den folgenden http request an meine Wallbox mit Firmware 59.4 im gleichen WLAN wie der Sender:
http:///api/set?ids=%7B%22pGrid%22:-10000,%22pPv%22:11000.%7D und bekomme jedes mal brav ein {"ids":true} zurück.
Fup ist auf true und lmo auf 4 und über api/status kontrolliert.
Die read-only variablen pgrid, ppv sind aber immer null und die WB lädt nicht. Woran kann das liegen?

[hanshoss-leibnitz]

Bin jetzt schon einen Schritt weiter. Ich hatte Überschussladen (fup) und Flexibler Energietarif (awe) beides eingeschaltet. Dann werden die ids Werte offensichtlich ohne Fehler ignoriert. Dabei schliessen sich beide Optionen ja nicht aus, sondern ergänzen sich perfekt. Entweder lädt man mit dem vorhandenen PV Überschuss oder wenn die Preisgrenze erreicht ist mit gewünschter Geschwindigkeit günstigen Strom. Das das Einschalten vom Flextarif das PV Laden verhindert scheint mir ein Bug zu sein, der dringend behoben werden sollte.

[mr-gosh]

Ich habe bei mir den flex Tarif deaktiviert (weil ich keinen nutze), aber ich teste nachher mal ob das bei mir auch zu einem Fehler führt.

Das Überschussladen funktioniert bei mir sehr zuverlässig!