Seit Längerem habe ich mal wieder die go-e-Charger-App geöffnet. Es wurde ein Firmware-Update angeboten. Im ChangeLog (schon für Version 0.55.6) stand unter anderem (incl. der falschen Leerzeichen):
pgrid Target für Laden mit PV Überschuss (api key "pgt")
Gibt es jetzt tatsächlich offizielle Schlüssel für das Übermitteln von PV-Überschuss-Daten?! Zumindest wurde mit dem Commit Add api key for pGridTarget schon letztes Jahr im April der Schlüssel pgt zur Dokumentation hinzugefügt, als „R/W“ und mit der geradezu überschwänglich umfassenden Beschreibung „pGridTarget in W“.
Laut einem Beitrag auf GitHub wird für die Steuerung des Überschussladens auch der Akku-Strom benutzt. Wie sieht es dokumentationsseitig mit den zugehörigen Schlüsseln aus? Stand heute unverändert alles „read-only“:
pgrid
R
optional<float>
Status
pGrid in W
ppv
R
optional<float>
Status
pPv in W
pakku
R
optional<float>
Status
pAkku in W
Der mehrfach auch von Maintainer-Seite genannte scheinbar zum Übertragen von PV-Daten nutzbare ids-Array-Key wird nach wie vor in der Dokumentation überhaupt nicht aufgeführt.
Weiterhin schreibt „dosordie“ (ich war so frei, die Orthographie behutsam zu redigieren):
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 eliminiert, die die unter 4 kW Überschuss manuell auf 1-phasiges Laden stellt.
Also gut. Man kann, wenn man denn weiß wie, dem go-e-Charger den momentanten PV-Überschuss mitteilen; vielleicht auch das, was gerade in den Akku geht oder aus dem Akku kommt. Ordentlich dokumentiert ist hier aber nach wie vor exakt überhaupt nichts.
Ganz ehrlich: Ein Daemon o. Ä., der sich um das Übermitteln der Daten kümmert, muss ja sowieso laufen. Und dann kann ich das bisschen Logik, dass es zum Steuern des Ladens braucht, auch gleich noch selbst machen. Weil sonst braucht es ja wieder diese App, der man dann sagen muss, dass man jetzt mit PV-Überschuss laden will etc. Weiterhin bleiben die Berechnungs-Internas ja eine Black Box. Dann lieber selber wissen und kontrollieren können, was da passiert.
go-e-pvsd läuft mittlerweile ganz passabel, also: Never change a running system ;-)
I have been a Desktop linux user at the latest since 2005 (I signed up for the Gentoo Forums on 2005-01-26). Almost 19 years now. But you never stop to learn ;-)
I recently adepted that you you could get KDE's native file dialogs using Firefox (instead of those GTK abominations) by using xdg-desktop-portal, along with KDE's backend implementation xdg-desktop-portal-kde. The only thing to do is having those packages installed and setting the environment variable GTK_USE_PORTAL to 1.
So … how do we achieve this?! For a console, I would put export GTK_USE_PORTAL=1 to ~/.bashrc. This will work for an opened terminal I type firefox in. But the KDE desktop won't care about this. I had been bugged for KRunner not respecting my custom $PATH since ever … Plasma won't adopt this export as well.
What do we do? Mess with Firefox's .desktop file? That will be overwritten by the next update. Create a custom startup script that does something like GTK_USE_PORTAL=1 firefox? That sucks. No! We set the environment variable for Plasma!
That is surprisingly easy. One only has to find the correct docs about this. TL;DR: Every script inside ~/.config/plasma-workspace/env/ will be executed at Plasma's startup. Thus, we simply export our GTK_USE_PORTAL there. I now use the following script, which lives in ~/.config/plasma-workspace/env/exports.sh:
Jetzt scheint es aber so zu sein, dass die go-e-Charger-API mehr hergibt, als go-e dokumentiert (oder zugeben will?). Kürzlich bekam ich eine E-Mail mit in etwa diesem Inhalt:
Hey, go-e-pvsd ist ein cooles Projekt, aber du hast dir viel zu viel Arbeit gemacht. Ich setze einfach ppv und pgrid, den Rest macht der go-e-Charger selber. Ich lade damit schon seit Monaten mein Auto mit PV-Überschuss.
Ja wie jetzt. Genau die API-Schlüssel (und noch pakku) hatte ich mir ja damals angeschaut. Alle sehr spärlich bis gar nicht dokumentiert (so lautet z. B. auch zum jetzigen Zeitpunkt die Beschreibung des Schlüssels pgrid – extrem vielsagend – „pGrid in W“), und alle „read-only“. Ich hatte ja damals sogar eine E-Mail an den go-e-Support wegen exakt dieser Schlüssel geschrieben. Und die Antwort war (ich zitiere):
Die PV-Parameter gelten als Vorbereitung auf den bald kommenden go-eController und sind noch nicht vollständig implementiert.
Also Finger weg davon.
Mittlerweile gibt es den go-e-Controller. Die „PV-Schlüssel“ sind aber Stand jetzt nach wie vor laut Dokumentation alle „read-only“. Ich habe auch schon daran gedacht, dass man ja eigentlich einfach mal per WireShark mitschneiden könnte, was der go-e-Controller dem go-e-Charger erzählt. Für den Fall, dass hier undokumentierte Wege beschritten werden. Aber mir deswegen diesen Controller zu kaufen, nur um rauszufinden, wie eine herstellerspezifische Hardware-Lösung exakt das tut, was ich mittlerweile auch selber hinbekommen habe, war und ist mir dann doch zu blöd – auch wenn ein bisschen Reverse Engineering schon reizvoll wäre ;-)
Egal wie: Scheinbar sind diese API-Schlüssel eben tatsächlich nicht „read-only“ (wäre ja auch irgendwie Schwachsinn), und der go-e-Controller nutzt vermutlich exakt diese vermuteten API-Schlüssel. Stellt sich nur die Frage, ob die von go-e einfach zu faul zum ordentlich dokumentieren sind, oder ob hier mit Absicht schlecht, unvollständig und auch einfach absichtlich falsch dokumentiert wird, damit das alles schwieriger aussieht, als es eigentlich ist. Damit man seine eigene Hardware-Lösung verkaufen kann, und nicht so viele Leute auf die Idee kommen, selber was zu machen.
Egal wie – go-e-pvsd funktioniert 1A und nutzt offiziell dokumentierte API-Schlüssel so, wie sie laut der offiziellen Dokumentation und dem technischen Support von go-e genutzt werden können bzw. sogar sollen. Und die komplette Logik ist in dem Daemon implementiert und kann entsprechend auch eingesehen und angepasst werden. Hier gibt es keine „Black Box“.
Weiterhin war das Implementieren der Logik eigentlich recht einfach. Viel schwieriger war das Schreiben eines ordentlichen Daemons, der brav das tut, was er soll – und den bräuchte man ja auch, wenn man die Logik dem go-e-Charger überlässt.
Ich würde sagen, wir lassen erstmal alles, wie es ist. Never change a running system. Aber sollte go-e die Dokumentation ändern, und die „PV-Schlüssel“ ganz offiziell zum Schreiben „freigeben“, dann könnte man darüber nachdenken, den Daemon dahingehend anzupassen, dass exakt die Werte geschrieben werden, die auch der go-e-Controller schreibt. Quasi als „Software-go-e-Controller“.
Wie kürzlich geschrieben konnte ich mich jetzt endlich mal dranmachen, eine Steuerung für PV-Überschussladen mit dem go-e-Charger zu schreiben.
Ganz trivial war das nicht (weniger die Steuerung selber, mehr das Erstellen eines „well-behaved“-Daemons), aber schwer war es auch nicht. Nach einigen Tagen erfolgreichen PV-Überschuss-Ladens damit habe ich nun ein bisschen Dokumentation online gestellt, wie das alles funktioniert, und wie man das Programm konfigurieren und benutzen kann.
Und wenn es noch ein bisschen länger brav das tut, was es soll, dann tagge ich mal Version 1.0.0 :-) Bis dahin: Viel Spaß damit für alle Interessieren!