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!
Lang satt hat’s gedauert, aber endlich ist unsere PV-Anlage am Netz. Den eingespeisten Strom verschenken wir mangels Zwei-Wege-Zähler zwar momentan noch, aber es geht ja eh hauptsächlich um die Eigennutzung.
Letztlich hatten noch zwölf PV-Module von IBC Solar mit einer Gesamtleistung von 5,1 kWp neben den Solarthermiekollektoren Platz. Dazu ein Fronius Symo GEN24 10.0 Plus als Wechslerichter (der kann zwar mit maximal 10 kWp fast doppelt so viel, als er können müsste – aber der war, im Gegensatz zu seinen kleineren Geschwistern, tatsächlich verfügar) und dazu noch ein Batteriespeicher (B-Box Premium HVS 5.1 von BYD).
PV-Überschuss soll im Auto landen, nicht im Netz
In der vermutlich nur noch kurzen Zeit, bis die dunkle Jahreszeit losgeht, kann theoretisch noch einiger PV-Überschuss in unseren Corsa-E fließen. Nur ist das mit dem PV-Überschussladen mit dem go-e-Charger ja doch nicht so einfach, wie ich ursprünglich gedacht hatte.
Tatsächlich ist mittlerweile der damals noch gar nicht verfügbare go-e-Controller auf dem Markt. Ein Smart Meter, was (vermutlich) selber den PV-Überschuss, also die momentane Einspeisung, misst, und sich dann mit dem go-e-Charger vernetzt, um PV-Überschussladen zu realisieren.
Aber das muss ja wohl auch ohne gehen. Sowohl der go-e-Charger, als auch der Fronius-Wechselrichter haben eine HTTP/JSON-API. Das macht das Auslesen von Daten ziemlich einfach. Und ein Smart Meter braucht der Wechselrichter ja eh. Also wozu ein zweites?
Dann braucht es ja nur noch ein bisschen Steuerung ;-)
go-e-pvsd
Wer hätt’s gedacht, ganz trivial ist es nicht. Aber ich habe zumindest schonmal was prinzipiell Funktionierendes zusammengebracht, getestet bis dato sage und schreibe einen ganzen Nachmittag (heute ;-).
Und zwar: Den go-e-pvsd, den „go-e (Charger charge) PV Surplus Daemon“. Ein großer Name, bisher allerdings wohl noch nicht einmal Alpha-Status. Mehr ein „Prove of Concept“. Den Quellcode habe ich trotzdem schonmal auf GitLab hochgeladen.
Die momentanen Eckpunkte sind:
Das Programm ist in Python geschrieben und unter der GPLv3 veröffentlicht. Außer der Standardbibliothek nutzt es python-daemon und requests.
Wenn man das Script in der Konsole startet, dann bleibt es im Vordergrund und loggt auf die Konsole. -v sorgt für mehr Ausgabe („verbose“). Mit -d gestartet wird aus dem Programm ein Daemon („daemonize“). Dann wird via Syslog geloggt. Starten sollte man es dann allerdings über ein Init-System. Ein Init-Script für OpenRC liegt bei.
Zu Testzwecken (und das wird evtl. noch lange der Fall sein) sollte man erstmal ./go-e-pvsd -v nutzen, dann sieht man alles, was passiert, und man kann das Programm mittels STRG+C beenden.
Die Kommunikation mit dem go-e-Charger passiert über die HTTP-API. Manipuliert werden die Schlüssel frc (Ladefreigabe), psm (Phasenumschaltung) und amp (zugelassener Ladestrom). Gelesen wird noch nrg (Informationen über den momentanen Energieverbrauch).
Beim Starten cachet der Daemon die Werte, die verändert werden, und verbietet erstmal das Laden.
Periodisch ruft er dann den aktuellen PV-Überschuss ab. Das Backend dazu habe ich abstrahiert, damit jeder einfach ein passendes für seinen Wechselrichter schreiben kann. Dabei ist momentan ein Backend namens FroniusGen24, was sich mit unserem Wechselrichter unterhalten kann (über die Fronius-HTTP/JSON-API).
Ist nun genug Überschuss vorhanden, entscheidet der Daemon, ob ein- oder sogar dreiphasig geladen werden kann, berechnet die passende Stromstärke und gibt das Laden frei, solang es geht. Per Voreinstellung muss der entsprechende Level mindestens eine Minute über- oder unterschritten werden, um das Laden zu erlauben oder zu verbieten oder eine Phasenumschaltung auszulösen. Eine Stromstärkeänderung kann nach 15 Sekunden passieren (kann aber alles auch individuell konfiguriert werden).
Wird der Daemon beendet (via SIGINT, also STRG+C, oder SIGTERM, via Init-System), stellt er vor dem Schließen die am Anfang gecacheten Werte wieder her.
Die Konfiguration geht über INI-Dateien. Zunächst wird nach /etc/go-e-pvsd.ini gesucht, dann nach ~/.config/go-e-pvsd.ini und dann nach go-e-pvsd.ini im aktutellen Arbeitsverzeichnis. Die später gefunden Dateien überschreiben die Werte in vorher gefundenen. Es gibt eine Section namens main für den go-e-pvsd selber, und eine für das jeweilige Wechselrichter-Backend (im Fall des momentan einzug verfügbaren heißt diese FroniusGen24).
Das Ziel ist eine funktionierende echte Open-Source-Lösung für PV-Überschussladen mit einem go-e-Charger – und zwar ohne zusätzliche Hardware, und ohne kommerzielle Software. Und auch ohne Pseudo-„Open Source“-Software, die dann aber trotzdem Geld kosten soll, oder von der der Quellcode dann doch irgendwie nicht so richtig verfügbar ist. Einfach ein ganz normales Open-Source-Projekt halt.
I've been connecting to a machine in my practise for years now using x11vnc, using an ssh tunnel. All of a sudden, it would not start up anymore, and said XOpenDisplay(":0") failed. caused by Invalid MIT-MAGIC-COOKIE-1 key.
After going through quite some headache, I now know why this happens and how to work around it.
My original command to remotely start the x11vnc server was:
The problem is that x11vnc can't find the "MIT magic cookie" anymore, which contains auth information needed to talk to the X server. This information has been stored in ~/.Xauthority since ever. And I suppose this is where x11vnc looks for the auth info if $XAUTHORITY isn't set and/or xauth info doesn't reveal the location of the auth info.
This is caused by SDDM not storing the auth info in ~/.Xauthority anymore (for whatever reason). Actually, it can be found in /tmp/xauth_....
The problem that arises is that, on a local session when starting x11vnc, we both have $XAUTHORITY set, and xauth info also contains the location of the cookie. But not on a remote session. Thus, we're lost with our ssh call.
Giving x11vnc the explicit auth info
My workaround for this is to find the cookie and provide it explicitely to x11vnc. The cookie is a file starting with xauth in /tmp, owned by the user to start the x11vnc server. We can find it like this:
find /tmp -name xauth\* -user $(whoami) -type f
So, we can extend the above x11vnc call with the explicit auth info like this to make it work again: