nasauber.de

Blog: Aktuelle Einträge

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 …


go-e-pvsd läuft

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.

Zu finden ist das Projekt auf GitLab unter https://gitlab.com/l3u/go-e-pvsd.

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!


go-e-Charger und PV-Überschussladen: go-e-pvsd

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

Schauen wir mal, was draus wird :-)