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 …