nasauber.de

Blog: Aktuelle Einträge

Energiewende muss man schon wollen

Heute ist die Schlussrechnung für unsere PV-Anlage gekommen. Ganz billig war sie nicht. Wir haben mit der Firma Rietec einen rennomierten lokalen Betrieb mit der Installation beauftragt, und es wurde zweifelsohne auch gute Arbeit geleistet. Wir haben auch hochwertige Komponenten verbauen lassen: 425-W-Kollektoren von IBC Solar, einen 10-kW-Wechselrichter von Fronius (die Größenordnung hätten wir nicht gebraucht, aber der passende kleinere hätte eine unbestimmte Lieferzeit gehabt …) und einen 5-kWh-Batteriespeicher von BYD. Dummerweise war auch das Gerüst (wie auch schon beim Hausbau von der Firma Wimmer Gerüstbau, ehemals Steinhäußer, gestellt) recht aufwändig. Und das alles gibt es nicht umsonst.

Unterm Strich ist die Anlage jetzt jedenfalls mit ziemlich genau 21 000 € zu Buche geschlagen. Das ist schon eine Hausnummer. Wenn man mal eine kleine Abschätzung zur Wirtschaftlichkeit machen will:

Wir haben in den letzten Jahren einen jährlichen Stromverbrauch von ungefähr 3 700 kWh gehabt. Geht man beim Stromverbrauch unseres Opel Corsa F e von übers Jahr gemittelten 16,5 kWh pro 100 km und einer Fahrleistung von 10 000 km pro Jahr aus, kommen nochmal gut 1 600 kWh oben drauf. Sind wir also bei ca. 5 300 kWh Stromverbrauch pro Jahr.

Bei dem Strompreis, den wir momentan in unserm Vertrag mit E.ON zahlen (33,68 ¢/kWh) müssten wir also knapp zwölf Jahre lang komplett den Stromverbrauch von Haus und Auto allein mit Eigenproduktion decken, damit sich die Anlage amortisiert. Die lächerlichen 8,2 ¢ pro kWh für’s Einspeisen lassen wir in dieser Rechnung mal außen vor. Selbstverständlich wird das aber leider sogar deutlich länger als zwölf Jahre dauern. In unserem ersten Winter waren wir – erwartungsgemäß – meilenweit von Autarkie entfernt. Weiterhin muss man davon ausgehen, dass der Wechselrichter und der Batteriespeicher irgendwann ausfallen oder zumindest repariert werden müssen. Die Kosten dafür sind noch gar nicht berücksichtigt.

Bei diesen Zeiträumen frage ich mich schon fast, ob ich den Break-Even-Point überhaupt noch erleben werde …

Quintessenz: Es gehört schon ein ordentliches Maß an Idealismus dazu, bei der Nummer mitzumachen. Aber zumindest leisten wir unseren Beitrag.


go-e-Charger und PV-Überschussladen – Update 2

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“:

pgridRoptional<float>StatuspGrid in W
ppvRoptional<float>StatuspPv in W
pakkuRoptional<float>StatuspAkku 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 ;-)


Setting environment variables for KDE's Plasma

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:

#!/bin/bash
export PATH="/home/tobias/bin:/home/tobias/.local/bin:$PATH"
export GTK_USE_PORTAL=1

This does not only make Firefox show native file dialogs, it also adds my custom $PATH to e.g. KRunner.

Now you know ;-)


go-e-Charger und PV-Überschussladen – Update

Damit, wie man mit einem go-eCharger PV-Überschussladen realisieren kann, habe ich mich ja nun schon intensiver beschäftigt; u. A. musste ich feststellen, dass go-e das zwar als offen und einfach anpreist, es aber nicht ganz so einfach zu sein scheint. Letztlich habe ich dann ja kurzerhand meine eigene Software-Lösung zum PV-Überschussladen mit dem go-e-Charger geschrieben.

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“.

Es bleibt spannend …