Update 02.10.2023: Mittlerweile habe ich eine funktionierende Software-Lösung für PV-Überschussladen mit dem go-e-Charger, siehe go-e-pvsd läuft bzw. gleich die GitLab-Projektseite von go-e-pvsd :-)
Demnächst werde ich E-Auto-Fahrer. Nach über 11 Jahren bekommt mein VW Up als Nachfolger einen Opel Corsa E. Außerdem gibt’s demnächst auch noch eine PV-Anlage aufs Dach. Zeit also, sich mit dem möglichst effektiven Nutzen des selbstgemachten Stroms auseinanderzusetzen. Denn die Anlage muss ganz schön lang laufen, und ganz schön viel Strom erzeugen, um sich zu armortisieren.
In Vorbereitung der hoffentlich baldigen Lieferung des E-Autos habe ich schonmal eine Ladestation installiert. Meine Wahl fiel auf den go-eCharger HOMEfix, der schon verschiedentlich Testsieger war, und nettwerweise auch vergleichsweise günstig zu haben ist. Außerdem wirbt die Firma mit „Photovoltaikanbindung über [die] offene API-Schnittstelle (Programmierung erforderlich)“.
„Programmierung erforderlich“ – alles klar. Das werde ich wohl hinbekommen. Also: Was braucht es denn?! Die Handy-App zum Einstellen der Ladestation hat zum einen einen „Mit PV-Überschuss laden“-Schalter für den „Eco-Modus“, als auch einige Einstellungen dafür, wie denn mit PV-Überschuss genau umgegangen werden soll:
Also kann es ja eigentlich nur noch darum gehen, der Wallbox mitzuteilen, was der Wechselrichter gerade macht, bzw. welche Leistung gerade von den Solarzellen kommt, was verbraucht wird und was gerade übrig ist (also ins Netz eingespeist wird). Oder?!
Wie geht denn nun PV-Überschussladen mit dem go-e-Charger?
Es gibt eine offen dokumentierte API, die man u. a. via HTTP ansprechen kann. Klingt doch gut! Dann muss man doch sicher nur die aktuellen Daten vom Wechselrichter bzw. Smart Meter holen, passend verpacken, und der Wallbox mitteilen. Das sollte ja nun kein Problem sein.
Die Dokumentation der API-Schlüssel (Stand heute) ist ein bisschen spärlich, aber es gibt welche, die so aussehen, als wären sie die richtigen bzw. hätten zumindest mit dem PV-Überschussladen zu tun:
lpsc
R
milliseconds
Status
last pv surplus calculation
inva
R
milliseconds
Status
age of inverter data
pgrid
R
optional<float>
Status
pGrid in W
ppv
R
optional<float>
Status
pPv in W
pakku
R
optional<float>
Status
pAkku in W
… aber die sind doch alle „R“! Sollten da nicht ein paar „R/W“ sein?! Wie soll ich denn bitte dem Ding sagen, was gerade übrig ist?! Fragen wir doch mal den Support. Die werden mir ja sagen können, wie man die PV-Überschuss-Anbindung implementieren muss.
Und tatsächlich kam auch eine Antwort:
Hallo Herr Leupold,
vielen Dank für Ihre Anfrage!
Im Grunde müssen dem go-eCharger in der Tat die Daten des Wechselrichters (oder einer anderen Messeinrichtung) verständlich weitergegeben werden.
In der Regel wird das ganz einfach und simpel mit den Parameter amp (Ladestrom in 1A-Schritten) und frc (Ladefreigabe Ja/Nein).
Die PV-Parameter gelten als Vorbereitung auf den bald kommenden go-eController und sind noch nicht vollständig implementiert.
Der go-eController wird unsere allgemeine Lösung zum Überschussladen sein: https://go-e.com/de-de/produkte/go-e-controller
Für weitere Frage und Anliegen stehe ich Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen
PV-Überschussladen mit dem go-e-Charger: Stand jetzt wohl eher Vaporware
Also kurz gesagt: Ich kann dem go-e-Charger via API sagen, mit wieviel Ampere er ausspucken soll, und ob oder ob nicht er laden soll. Und das war’s. Heißt: Die komplette Logik und Regelung muss extern implementiert werden, und das Ding macht selber überhaupt nichts im Puncto PV-Überschussladen.
Heißt: Will man das machen, was hier mit der Voraussetzung „Programmierung erforderlich“ beworben wird, dann ist die Ladestation nichts anderes als eine schaltbare Steckdose. Die Arbeit muss ich selbst machen. Und die Einstellmöglichkeiten in der App sind vollkommen funktionslos. Weil es keine Möglichkeit gibt, der Ladestation irgendwelche Parameter einer PV-Anlage zu übermitteln.
Das finde ich dann doch etwas befremdlich. Wieso enthält eine Steuer-App Optionen ohne Funktion?! Und warum veröffentlicht man API-Schlüssel, die man überhaupt nicht nutzen kann?!
Um das zu erreichen, was hier meiner Wahrnehmung nach beworben und auch in der App-Oberfläche angeboten wird, wird auf ein noch nicht verfügbares zusätzliches Produkt verwiesen und auf zukünftige Entwicklung der API. Ich muss sagen, dass ich mir das anders vorgestellt hatte.
Es geht wohl schon … aber
Um tatsächlich mit dem go-e-Charger PV-Überschussladen zu realisieren, bleibt einem Stand jetzt wohl nichts anderes übrig, als die komplette Steuerung und Logik selbst zu implementieren, oder auf bestehende Lösungen wie OpenWB oder evcc zurückzugreifen. Ausprobiert habe ich bisher noch gar nichts, es gibt ja bisher weder ein E-Auto, noch eine PV-Anlage.
Und die von evcc fordern für die Anbindung eines go-e-Chargers ein kostenpflichtiges GitHub-Sponsoring von mindestens 2 $ pro Monat (sofern ich das richtig verstanden habe). Bei aller Liebe: Dafür bin ich Open-Source-Entwickler zu viel. entweder mache ich Open Source, oder ich lasse es. Es ist vollkommen legitim, mit Open Source auch Geld zu verdienen. Aber da kann ich ja dann auch gleich ein kommerzielles Closed-Source-Produkt anbieten, wenn ich die Nutzung von einer fortlaufenden Zahlung abhängig mache. Und nein, ich mache mir nicht die Mühe, den entsprechenden Check aus dem Quellcode zu werfen, und den Kram dann ohne Zwangszahlung zu bauen.
Bleibt abzuwarten, was diesbezüglich seitens go-e noch kommt. Aber den momentanen Zustand finde ich ernüchternd.
I put all static content which rarely changes inside /static/, e.g. CSS and JavaScript files. A client requests such a file only once and caches it, until it expires. Next time, it's not fetched from the server, but simply loaded from the cache. This lowers traffic and CPU cycles, saving bandwidth and power consumption for both server and client.
Principally, this is a good idea and something everybody running a HTTP server should do, in some way.
The problem
The problem is that if something is changed, a client already having cached the file in question won't notice the change: As said, it won't request the file from the server but load it from it's cache. This could lead to a messed up layout or even an unfunctional page if relevant portions of e.g. the CSS style have been changed, in the worst case for a full month.
According to what I found, there's no way to directly work around it. If a browser did cache such a file with a defined time to live, it won't request it again during that time. There's no server-side way to tell a client it should reload such a file. No way to invalidate the cache or the expire date, no way to bypass this mechanism.
The client can possibly force-reload the page (e.g. by pressing CTRL+F5 or such, depending on the browser used), including all already cached files. But some people may not know this, and in some situations this might even not be possible at all: E.g. I'm using the Kiwi Browser on my phone, which does not seem to even have such a force-reload function.
The solution
If a file's name changes, it doesn't matter if the content is the same or almost the same. For the client, it's another file. So I simply introduced a revision number. E.g. instead of /static/css/style.css, it's now /static/css/style-1.css, after the next change, it would be /static/css/style-2.css and so on. Each client will request a file renamed like this after the change (of course again cache it) and display the changes correctly.
But all the HTML has to be changed then! Here, Jekyll, the lovely static web page generator, comes into play.
I simply created a YAML data file, which acts as a map for all the static content I want to handle like this. E.g. one could call it _data/static.yml, with entries like this:
This works as well for CSS or JavaScript files, as soon as a "front matter" is added. E.g. one would reference such a file inside a CSS file like that:
The parsed result delivered to _site/ is simply the CSS file like before (as we did not apply any layout), but with the stuff referenced by {{ ... }} replaced with the real thing.
This way, if some "static" file changes, one only has to bump the revision counter and update the _data/static.yml file. Which are two additional steps, but this does not happen too often. And the rest happens automagically :-) Still, the static stuff is cached as it should be, but when changes are done, everybody gets the new version.
Diesen Sommer haben wir die noch (gar nicht so) alte Brennkammer unseres Kachelofens durch eine wasserführende ausgetauscht, die nicht nur den Kachelofen, sondern auch unseren Pufferspeicher aufheizt (namentlich eine Leda Diamant H100 W). Netterweise wird, bedingt durch die günstige Konstruktion unserer Heizung, über den Pufferspeicher nicht nur unser Brauchwasser erhitzt; auch die Flächenheizung wird über den Speicher versorgt. Somit heizt jetzt die Brennkammer nicht mehr nur Wohn- und Esszimmer, sondern anteilig auch das ganze Haus.
Befeuert wird der Heizeinsatz ausschließlich mit Windbruch- und Käferholz aus dem schwiegerelterlichen Wald, der wenige Kilometer entfernt liegt. Von daher sehe ich das – Feinstaub hin oder her – als durchaus umweltfreundlich und vor allem (annähernd) CO2-neutral an.
Besonders interessant ist allerdings das Einsparpotenzial beim Gasverbrauch. Wir haben (wie viele andere auch) eine Gastherme. Dank des vcontrold-Projekts1 zeichne ich, seitdem die Heizung installiert wurde, u. a. die Betriebsstunden des Brenners mit einem Raspberry Pi 1 auf2.
Der Dezember ist noch lang nicht vorbei, aber wenn man die Brennerstunden linear extrapoliert, kommt man auf folgendes Ergebnis:
Nun kann man nicht direkt die Brennerstunden mit der Gaseinsparung gleichsetzen (der Brenner läuft ja nicht immer auf 100 %), aber eine erhebliche Einsparung gab und gibt es definitiv: Im Schnitt haben wir (mit den Werten der Extrapolation für Dezember) die Stunden, in denen unsere Gastherme lief, um beachtliche 84 % reduziert. Gut, einschüren muss man schon. Mit nichts läuft die Anlage nicht, man braucht schon ein bisschen Brennholz (bisher ca. 4 Ster) Aber das war klar.
Am Ende des Winters poste ich hier jedenfalls nochmal die tatsächlichen Zahlen! Aber es sieht ganz danach aus, als ob sich diese doch nicht unerhebliche Investition gelohnt hat!
… dem ich vor einiger Zeit mal mit der Umstellung des veralteten Buildsystems auf CMake und dem Aufräumen des Quellcodes mit zu einem Neustart verholfen habe
… mit einem selbstgebauten Optolink-Adapter, der „richtige“ Schaltplan und die Fotos aus dem Wiki-Eintrag darüber sind von mir
Am 26.01.2005 habe ich mich im Forum von Gentoo Linux angemeldet. Spätestens seit diesem Zeitpunkt bin ich ausschließlicher Linux-User (abgesehen von Fällen, wo man nicht um Windows herumkommt, etwa in der Arbeit oder zum Bauen der Windows-Version des Muckturnier-Programms).
Für alle, die es nicht kennen: Gentoo Linux hat eine gewisse Sonderstellung unter den Distributionen. Hier baut man (bis auf wenige Ausnahmen) alle Software, die man benutzt, selbst aus den Quelltexten. Man fängt nicht ganz bei Null an, aber mit wenig. Man baut sich sein ganzes System selbst, und hat volle Kontrolle – zu dem Preis, dass man sich vergleichsweise gut auskennen muss.
Das hatte damals einen sehr großen Reiz. Abgesehen vom unabstreitbaren „Geek-Faktor“ kann man alle Software auf die CPU und Maschine optimieren, auf der sie läuft; inwiefern das heutzutage noch sinnvoll oder nötig ist, oder einen fühlbaren Unterschied macht, sei dahingestellt. Was aber zweifelsohne auch heute spitze ist: Bedingt durch das USE-Flag-System kann man Software ganz nach den persönlichen Bedürfnissen bauen, und so auch Abhängigkeiten aussparen oder spezielle Funktionalität einbinden. Das kann keine Binärdistribution.
Gentoo ist echt cool. Ich habe es auch nach wie vor auf meinem Desktop-Rechner (was will ich auch sonst mit den 6 Kernen und 12 Threads meines Ryzen 5 3600 und den 32 GB RAM?!). Ich habe die Distribution über die Jahre wirklich lieben gelernt (manchmal war es wohl eher auch Hassliebe ;-), und die Community ist sehr freundlich und kompetent. Der Nerd-Anteil ist hoch, und der n00b-Anteil klein. Also gibt es wenig dumme Fragen, und wenig dumme Antworten.
Gentoo muss man wollen
Ich habe als IT-Beauftragter meiner Familie natürlich nicht nur auf meinem Desktop Gentoo installiert, sondern überall. Es war bis vor Kurzem auch auf dem Rechner meiner Frau, meiner Eltern, dem Wohnzimmer-Computer, meinem Raspberry Pi, meinem Notebook, dem alten Notebook meiner Frau und auf meinem ganz alten Netbook (ich habe tatsächlich einen noch funktionierenden Asus EEE PC 1000H) – und auf meinem kleinen Server, einem APU2-Board. Und die alle aktuell zu halten war immer recht zeitaufwändig (schließlich baut man ja alles aus den Quellen und installiert nicht einfach Binärpakete).
In den letzten Jahren ist es mühsam geworden. In Zeiten, wo HTML-Rendering-Engines komplexer als Betriebssysteme sind, und aus zehntausenden Quelltext-Dateien mit Millionen von Zeilen bestehen, sprechen wir z. B. bei einem Update, das die QtWebEngine und/oder NodeJS beinhaltet, nicht mehr von Stunden, die es dauert – wir sprechen von Tagen. Tage, in denen so ein Rechner mitunter nur eingeschränkt oder gar nicht nutzbar ist.
Lange ging es ganz gut, indem man distcc nutzte. Aber der Kompilieraufwand wurde größer und größer und ging mitunter so weit, dass manche Pakete auf alten Rechnern schlicht gar nicht mehr zu bauen waren – wegen zu wenig RAM und/oder zu wenig Platz auf der Festplatte.
An einem gewissen Punkt hat es mir einfach keinen Spaß mehr gemacht, tagelang in fünf oder sechs screen-Sessions emerge beim Arbeiten zuzuschauen. Den gcc auf einem Raspberry Pi 1 zu bauen nervt einfach nur noch.
Was kann man nehmen?
Das war die große Frage. Ernsthaft und dauerhaft hatte ich nur Gentoo benutzt. Keine der anderen großen Distributionen. Aber bedingt dadurch, dass ich seit einiger Zeit – mehr oder weniger notgedrungen – auf meinen Servern bei Hetzner „Feindkontakt“ mit Ubuntu habe, war mir eines klar: Kein Systemd. Nein. Warum Systemd eine Ausgeburt der Hölle ist, kann jeder im Internet nachlesen. Welcher Teufel die meisten großen Distributionen geritten hat, ihr Init-System auf Systemd umzustellen, ist mir nach wie vor schleierhaft. Von meiner Seite nur so viel: Was hat sich ein Init-System um DNS-Auflösung zu kümmern? Was sollen irgendwelche Timer, die mit Cronjobs konkurrieren? Was sollen irgendwelche binären(!) Logs, die mit Syslog konkurrieren?! Diese ganze Systemd-Sache ist einfach nur fürchterlich.
Was dazu führt, dass die Auswahl klein wird. Aber es gab (und gibt) Hoffnung: Nach einiger Recherche konnte ich drei potenzielle Aspiranten ausmachen, die da wären:
Void Linux, eine von Grund auf neu entworfene Distribution
Getestet habe ich zunächst einmal in einer virtuellen Maschine in QEMU.
Void Linux
Void Linux nutzt als Init-System runit. Es ließ sich sehr problemlos installieren, wenngleich man doch einiges dafür wissen muss (einen Installer gibt es, wie bei Gentoo, nicht). Aber wenn man von Gentoo kommt, dann ist man ja Kummer gewöhnt ;-) Alles in allem war der Eindruck nicht schlecht, aber für den Einsatz auf einem Endbenutzer-Bürorechner wie dem von meinen Eltern oder dem von meiner Frau war mir Void Linux dann doch ein bisschen zu „exotisch“.
Im Auge behalten sollte man die Distribution aber auf jeden Fall. Allein schon deswegen, weil sie kein Fork ist, und der Ansatz neu und frei von Altlasten daherkommt.
Devuan
Bei Devuan kann man aus mehreren Init-Systemen wählen: Dem traditionellen sysvinit, runit und Gentoos OpenRC. Als Gentoo-User nimmt man natürlich OpenRC.
Die Installation geht von selbst. Live-Medium booten, ein paar Auswahlen im Installer treffen. Kurz darauf hat man ein komplettes Desktop-System.
Das ist allerdings auch genau der Punkt, der mich immer gestört hat an all den Distributionen, die ich vor Gentoo ausprobiert habe: Man hat ein komplettes System. Und einen ganzen Haufen Kram, den man nicht braucht. Und als allererstes muss man sein System ausmisten nach der Installation.
Aber es läuft. Sieht etwas anders aus als Gentoo (es kommen sysvinit-Init-Scripts zum Einsatz, keine OpenRC-spezifischen), aber es geht. Das meiste Know-How, Wikis, Foren-Einträge etc. kann man direkt von Debian übernehmen. Wie gesagt: Läuft.
Artix Linux
Bei Artix Linux läuft die Installation im Prinzip wie bei Void Linux oder auch Gentoo, mit Konsolen-Tools und ohne Installer. Als Gentoo-User fühlt man sich hier gleich ziemlich zu Hause. Und wenn man OpenRC nutzt (auch hier gibt es verschiedene Init-Systeme zur Auswahl, u. A. auch OpenRC), dann sieht Artix genauso wie Gentoo aus (bei jedem Paket mit einem Init-Script wird ein zusätzliches mit dem eigentlichen Init-Script installiert, das zum Init-System passt).
Das Konzept der Installation ist das selbe wie bei Gentoo: Man startet mit einem Minimalsystem, und installiert, was man braucht. Natürlich kann man nicht optimieren (was sich aufgrund der heutzutage sehr leistungsfähigen Rechner aber auch irgendwo relativiert), und man kann aufgrund der Binärpakete auch keine Abhängigkeiten „einsparen“. Aber man hat volle Kontrolle. Artix ist wie Gentoo eine „Rolling Release“-Distribution, es gibt also keine Versionen, sondern die Pakete werden fortlaufend aktualisiert. Das hat zur Folge, dass bei jedem Update vergleichsweise viele Pakete aktualisiert werden müssen (bei Gentoo kann man ja Pakete einfach neu bauen, bei Binärpaketen muss man bei allen Abhängigkeiten ran). Aber die sind schnell installiert.
Alles in allem ist Artix Linux spitze. Im Grunde fühlt es sich so an wie Gentoo mit Binärpaketen. Selber Software bauen ist kein Problem, und auch eigene Pakete bauen ist erfreulich einfach. Und: Updates dauern Minuten. Nicht Stunden, und auch nicht Tage. Sondern Minuten. Die Paketauswahl ist zwar deutlich geringer als bei Gentoo, aber man findet, was man braucht (und kann ja auch notfalls selbst bauen). Nicht nur daran merkt man, dass Artix eine noch recht junge Distribution ist: Auch fehlt z. B. ein zentraler Bugtracker. Aber was nicht ist, kann ja noch werden.
Die Mischung macht’s
Der Stand der Dinge ist Stand jetzt folgender:
Auf meinem Desktoprechner bleibe ich bei Gentoo. Meine Hassliebe zu dieser Distribution ist einfach zu groß, um ihr kaltherzig den Rücken zu kehren ;-) Außerdem ist mein Desktop leistungsfähig genug, um die Kompilierorgien zu ertragen.
Mein APU2-Serverchen lasse ich auch erstmal auf Gentoo laufen. Vorerst.
Den Büro-Rechner meiner Frau und den meiner Eltern sowie mein Notebook und den Wohnzimmercomputer habe ich auf Artix Linux umgestellt. Der Wartungsaufwand ist – im Vergleich zu Gentoo – quasi nicht vorhanden (alle paar Wochen mal ein paar Minuten), und es läuft. Alles da, alles geht. Artix Linux ist wirklich eine coole Distribution!
Auf dem alten Notebook meiner Frau und meinem alten Netbook habe ich Devuan installiert. Beide sind noch 32-Bit-Systeme, und Artix gibt es schlicht nicht für 32 Bit. Außerdem halte ich die beiden Rechner eigentlich eh nur für den Einsatz auf Muckturnieren vor, und der Wartungsaufwand bei Devuan ist nochmal ein Stück weniger als bei Artix. Perfekt also, insbesondere, weil die beiden Rechner nicht so oft upgedatet werden.
Das selbe habe ich bei meinem Raspberry Pi gemacht. Da läuft Devuan auch problemlos (auch hier hätte es eine passende Artix-Version gar nicht gegeben).
Unterm Strich sollte man sich also einfach die passende Distribution für den passenden Einsatzzweck suchen. Gentoo ist nach wie vor super, aber mit Artix Linux und Devuan haben wir, wo es passt, gangbare Alternativen – ohne bei dem Systemd-Wahnsinn mitmachen zu müssen. Bleibt zu hoffen, dass diese Distribution (weiterhin) den Erfolg haben werden, den sie verdienen.
