wodurch äußert sich die Instabilität bei der aktuellen Implementierung?
Ich steuere schon seit mehr als einen halben Jahr die Ladestation mit Openems an und abgesehen von sporadischen Verbindungsproblemen läuft das bei mir problemlos.
Die Verbindungsprobleme lagen ausschließlich an der schlechten WLAN-Antenne der Ladestation, welche ehrlich gesagt unterirdisch sind, aber nicht an der Implementierung der Software.
Übersehe ich ein Problem oder ist das aufgrund anderer Randbedingung bei mir schlicht und ergreifend einfach noch nicht aufgetreten?
Da ich an dem Code mitgearbeitet habe, würde ich gerne wissen was hier schief gelaufen ist für die nächste Implentierung.
danke für deine Rückfrage. Um einen gemeinsamen Kontext zu schaffen, bitte ich dich vorab kurz diese Beschreibung dieser Kategorie durchzulesen. Ich versuche dort die Idee hinter dem OpenEMSReady-Unterforum zu erklären.
Bei dem aktuellen goE-Treiber ist aus meiner Sicht daher nichts “schief gelaufen” und es wundert mich nicht, dass das System bei dir gut läuft.
Da wir mit dem Treiber in kommerziellen Produkten arbeiten wollen, stellen wir andere Anforderungen an die Zuverlässigkeit. Das Problem des Treibers versteckt sich im Event-Handling. OpenEMS ruft die Methode handleEvent() aller aktiven Componenten auf welche das EventHandler-Interface implementieren. Damit wird auch der Eventhandler der goE Implementierung aufgerufen, sobald das Bundle aktiviert wird. OpenEMS ruft die Eventhandler streng sequentiell und zyklisch auf. Das ist einer der großen Vorteile von OpenEMS, da dadurch im Allgemeinen die Synchronisierung der Komponenten enorm vereinfacht wird. Erkauft wird dieser Vorteil durch die Konvention, dass alle Komponenten, welche das EventHandler Interface implementieren, niemals die Methode handleEvent() blockieren. Denn wird die Methode von einer Komponente blockiert bleibt mehr oder weniger das ganze OpenEMS-System stehen.
Genau dieses Verhalten haben wir nun in der Methode GoeChargerHomeImpl.java:handleEvent(). Dort wird this.goeapi.getStatus() aufgerufen. Dieser Aufruf wartet so lange bis die Antwort von der Ladesäule gekommen ist. Die Wartezeit fällt im Normalfall nicht auf. Gerade bei z.B. einer WLAN Verbindung zur Ladesäule kann es aber gelegentlich zu Störungen im ein/zweistelligen Sekundenbereich kommen. In dieser Zeit kann OpenEMS nicht auf Veränderungen im Stromnetz reagieren, da andere Controller ebenfalls so lange “einfrieren”.
OpenEMS bietet hierfür eine einfache Lösung. Die blockierende Funktionalität in der handleEvent() Methode kann über einen sogenannten Worker-Thread ausgelagert werden. Das ist die Idee hinter dem Pull Request. Dort gibt es einen neuen WorkerThread GoeChargerWorker. Dieser Worker-Thread wird im bisherigen Eventhandler in der handleEvent() Methode nun in jedem Zyklus angestoßen und kann dann in aller Ruhe die Informationen von der Ladesäule abholen.
Leider habe ich meinen PullRequest falsch eingereicht. Daher ist die Änderung noch nicht im offiziellen Repository integriert. Ich hoffe in den nächsten Tagen etwas Zeit zu finden um den Pull Request zu schließen und einen neuen sauberen PullRequest zu stellen.
vielen Dank für die ausführliche und verständliche Beschreibung!
Ich hatte also bisher nur Glück und für den breiten Einsatz ist das so natürlich nicht geeignet.
Moin Moin!
Danke für den Blick ‘unter die Haube’ zu den Herausforderungen bei der Implementierung für die go-e Wallboxen. Meinem Verständnis nach steht der backport noch aus, richtig?
Derzeit (04/2023) ist für die Umsetzung von PV-Überschussladen mit einer go-e entweder eine ‘Huckepack-/Bastellösung’ oder der angekündigte (aber noch nicht lieferbare) go-e controller notwendig … genial wäre natürlich eine direkte Lösung in openEMS (und dann irgendwann in FEMS) - die grundsätzlichen Systemvoraussetzungen sind ja vorhanden.
Besteht im Rahmen der verfügbaren Kapazitäten die Möglichkeit zum Fortsetzen der Implementierung?
Hallo zusammen,
gerne wollte ich erfragen, inwieweit hier noch Interesse der Weiterentwicklung besteht.
Aktuell habe ich einen PR auf Github laufen (#2098). Auf Basis dieses GenericHttpWorkers habe ich die Go-E Ladestation (Go-E API v1 & Go-E API v2) komplett neu implementiert.
Getestet habe ich dies an einem Go-E Home Fix Charger (11kW).
Auch habe ich die allgemeine Implementierung aufgewertet und einige Fehler bzw. “komisches Verhalten” behoben.
Durch die neue Implementierung über den GenericHttpWorker wird durch die Go-E “App” die handleEvent() nicht mehr blockiert. Auch wurde ein Komponenten-Spezifisches Timeout (über normale Konfig einstellbar in ms) von mir hinzugefügt.
Da die Go-E API v2 (kompatibel ab Hardware-Version V3) auch noch andere Spielereien mit sich bringt, habe ich diese auch noch implementiert.
Somit nimmt die Go-E nun eine automatische Phasenumschaltung vor, wenn dies konfiguriert ist (eben möglich ab API v2 bzw. Hardware Version V3 oder höher). Somit ist ein PV-Überschussladen von 230V6A (1380W) bis 230V16/32A*3 (11kW bzw. 22kW) möglich.
Zudem wird auch noch der “Norway Mode” abgefragt und falls aktiviert eine entsprechende Info-Meldung in der OpenEMS-Komponente angezeigt (Details zum Norway Mode siehe Go-E Doku).
Gerne kann ich bei Interesse einen PR auf Github eröffnen. Dieser macht meiner Meinung nach aber erst Sinn, wenn der eigentliche PR für den GenericHttpWorker (#2098) freigegeben wurde.
danke für dein Engagement. Leider entspricht deine Implementierung noch nicht den Coding Guidelines, so dass wir den Code so nicht übernehmen können. Unser CI-Build würde sofort einen Fehler bringen.
Kannst du bitte mal deinen Code auf den aktuellen develop-Stand aktualisieren und dann tools/prepare-commit.sh ausführen? Damit sollten die offensichtlichsten Probleme aufgelistet werden.
Hey Stefan,
ja, die Probleme bzw. Fehler bei #2098 sind mir bekannt/bewusst
Aktuell hangle ich mich gerade durch die Coding Guidelines und verbessere meinen Code dahingehend.
Der obige Beitrag sollte tatsächlich gar nicht weiter auf den PR #2098 abzielen. Wie oben am Rande erwähnt wollte ich hier den aktuellen Status zur Go-E Impl. erfragen & meinen aktuellen Status kundtun. Einen PR meines Standes werde ich jedoch nicht starten (außer das wäre gewollt), da hierzu natürlich erst die Basis fertig sein muss. Die Überarbeitungspflicht für den PR 2098 hätte ich hier generell bei mir gesehen und daher ist es für mich absolut verständlich, dass ohne weiteres zu tun durch mich auch nichts passieren kann!
Leider bin ich hierzu noch nicht richtig gekommen, aber jetzt sollte es demnächst klappen
Danke für den Tipp mit tools/prepare-commit.sh → dies hatte ich gar nicht auf meinem Radar (wer lesen kann … )
gibt es hier schon etwas neues an der go-eCharger-Front? Ich wäre sehr interessiert an der Möglichkeit meinen V3 go-e über OpenEMS zu steuern und die Phasenumschaltung entsprechend nutzen zu können. Daher wollte ich mal fragen, wie der Stand dazu ist und ob es noch geplant ist, dass die Entwicklung von @nicoketzer finalisiert wird und in einen offiziellen Release kommt?
das ist leider noch die alte API für die Hardware V2. Die konnte noch keine Phasenumschaltung. Daher hatte ich auf die Umsetzung von Nico gehofft, der wohl bereits für sich die API der V3 implementiert hat welche von 1 auf 3-Phasen umschalten kann.
gibt es irgendwie die Möglichkeit, dass du mir eventuell per PN VPN Zugriff auf NUR die Wallbox gibst, um da eventuell einen Controller für die V3 schreiben zu können?
Wenn jemand will, kann er gerne mal die v2 mit dem Code testen
Ist eine “Dry-Impl” ohne Hardware aktuell quasi nicht getestet - auch die “Tests” wurden noch nicht geschrieben, aber für einen ersten Hardware Test sollte es reichen
)