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:
Wie kürzlich berichtet haben wir seit letzem Herbst eine wasserführende Kachelofen-Brennkammer. Die Wärme-Ausbeute für unseren Pufferspeicher sah schon nach kurzer Zeit ganz gut aus, aber der Winter war ja gerade einmal halb vorbei, als ich den besagten Zwischenbericht geschrieben habe. Jetzt haben wir belastbarere Zahlen!
Die Betriebsstunden des Brenners unserer Gastherme sehen von September 2022 bis April 2023, im Vergleich mit dem entsprechenden Vorjahreszeitraum folgendermaßen aus:
Summa summarum kamen wir im Winter 2021/22 auf 1 063 Brennerstunden, und im Winter 2022/23 waren es 220. Das sind gerade einmal gute 20 % davon. Das ist jetzt natürlich nicht 1:1 in die Gas-Einsparung umrechenbar, da ja der Brenner nicht immer auf 100 % Leistung läuft; aber die Differenz ist schon beeindruckend.
Es scheint sich also gelohnt zu haben – die Brennkammer funktioniert hervorragend :-)