Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)

[stefan_o]

Hallo,
ich hatte das Enphase-Modul geschrieben und es unterstützt bis jetzt nur ältere Firmware-Versionen der Enphase-Geräte (der Zugriff auf die API geht in neueren Versionen nur noch verschlüsselt mit Zugangstoken).
Da ich demnächst die PV-Anlage erweitere und in dem Zuge neue Modul-Wechselrichter und eine neue Firmware für das Hauptgerät kommt wollte ich jetzt schon mal anfangen das Modul weiterzuentwickeln. Ich habe aber festgestellt, dass sich in zwei Jahren doch einiges in openWB getan hat:

Ich habe mir einfach ein Image runtergeladen und auf einen Raspi gezogen, wollte in das openWB-Verzeichnis gehen und darin rumbasteln, aber das scheint nicht mehr so einfach zu gehen: In /var/www/html/openWB liegt jetzt was anderes, als direkt auf GitHub, z.B. jede Menge automatisch generierter JavaScript-Dateien für die Einrichtung der Module. Woraus werden die erzeugt und wie? Ich bin mir auch nicht sicher, ob das Version 1.9 oder 2.1 ist auf GitHub, oder ob das ein Repository ist, aus dem beide Versionen gebaut werden. Gibt es irgendwo eine Dokumentation wie man jetzt Module erstellt/anpasst? Ich stehe etwas auf dem Schlauch.
Ich wollte eigentlich anfangen, dass bei der Einrichtung des PV-Moduls erkannt wird, welche Firmware-Version vorliegt (kann/darf man das in openWB mit xmlhttprequest und JavaScript lösen? Gibt es seitens openWB eine vorgesehene Möglichkeit vom Web-Interface aus eine Python-Funktion aufzurufen (damit man Dinge nicht zweimal in Python und in PHP/JavaScript implementieren muss)?)

Es wäre nett, wenn man mir da ein paar Hinweise/Tipps geben könnte.

Vielen Dank
Stefan

[openWB]

Guten Morgen Stefan,

den Beitrag im Wiki gesehen?
https://github.com/openWB/core/wiki/Neu ... grammieren

[LutzB]

Ich hatte bereits angefangen, das Modul zu erweitern. Meine Schwester hat ein Gateway mit Version D7.6 und auch einen Speicher. Das läuft gerade im Testbetrieb.

Den aktuellen Stand kannst Du in diesen beiden Feature-Branches sehen:
Backend: https://github.com/openWB/core/tree/feature-enphase
Frontend: https://github.com/openWB/openwb-ui-set ... re-enphase

Wenn Du mit entwickeln möchtest, kannst Du gerne PRs zu diesem Branch einstellen. Gerade die Kompatibilität mit der älteren Version ist ungetestet.

Und dann habe ich die Daten des Speichers nur in den Live-Daten gefunden. Die muss man aber anscheinend aktiv anfragen. Immer wenn ich mich mit der App verbunden habe, kommen welche. Das schläft dann aber mit der Zeit wieder ein. Wenn Du also eine andere Möglichkeit für die Werte findest, wäre das klasse.

[stefan_o]

Hallo Lutz,

das sieht auf den ersten Blick so aus, als ob du da schon alles fertig hast. Ich werde deine Version nochmal bei mir installieren und schauen ob das mit der alten Firmware noch alles klappt.

Was für die Einrichtung vielleicht auch ganz interessant ist: Wenn die EIDs für PV/EVU automatisch ausgelesen werden könnten, erleichtert die Einrichtung des Moduls.

Ich hatte auch etwas recherchiert, die Speicherdaten scheinen tatsächlich nur in ivp/livedata/status zu stehen (bei meiner Firmware-Version existiert diese Datei noch nicht), aber was spricht dagegen, die alle 10 Sekunden mit abzufragen wie die readings auch? Oder ist das ein Datenstrom der kontinuierlich neue Elemente übermittelt?

Viele Grüße
Stefan

[LutzB]

Die Daten werden ja nach der Anpassung bereits im normalen Regelintervall abgerufen. Nach einiger Zeit (vielleicht die 15 Minuten, die auch in der App angezeigt werden?) kommen keine aktuellen Werte mehr. Wird dann die Ansicht in der App wieder geöffnet, kommen auch in der openWB wieder Daten an.

[stefan_o]

Die Daten werden ja nach der Anpassung bereits im normalen Regelintervall abgerufen. Nach einiger Zeit (vielleicht die 15 Minuten, die auch in der App angezeigt werden?) kommen keine aktuellen Werte mehr. Wird dann die Ansicht in der App wieder geöffnet, kommen auch in der openWB wieder Daten an.

Du meinst die Enphase-App, welche die Daten aus der Cloud holt? Vielleicht bereitet der Envoy die Daten nur auf, wenn die Cloud die Daten anfragt. Ein sehr hässlicher Work-Around wäre mit den Zugangsdaten regelmäßig die Webseite aufzurufen.

Das Problem scheinen auch andere zu haben:
https://support.enphase.com/s/question/ ... -local-api
https://support.enphase.com/s/question/ ... on-and-soc

Da die Fragen erst wenige Tage alt sind, habe ich noch die Hoffnung, das jemand von Enphase darauf eine brauchbare Antwort schreibt.

[stefan_o]

Ich hab es eben getestet: Mit der Anpassung läuft Firmware < 7.0 noch immer problemlos.

Ich habe mir das jetzt mal im Detail angeschaut, was fehlt im Moment ist:

• Web-Interface Einstellungen Batterie
• Automatisches Beziehen von Tokens
• Erkennung wenn Token ungültig
• Automatische Erkennung Firmware-Version
• Automatische Erkennung von PV/EVU Zähler EID
• Default-Wert für Hostname: envoy.local (hatte ich damals drin, weiß nicht warum das rausgeflogen ist)

Weiß nicht, woran du im Moment arbeitest, aber ich würde sonst mal schauen ob ich das mit den Tokens hinbekomme. Vielleicht habe ich eine Chance kurzlebige Tokens zu bekommen, dann könnte ich die automatische Aktualisierung prüfen.

[LutzB]

Web-Interface Einstellungen Batterie

Was muss denn Deiner Ansicht nach noch bei der Batterie eingestellt werden?

Automatisches Beziehen von Tokens
Erkennung wenn Token ungültig

Da hätte ich mich als nächstes dran gemacht. Ist ja in der Doku gut beschrieben. Kannst Du gerne übernehmen.

Automatische Erkennung Firmware-Version
Automatische Erkennung von PV/EVU Zähler EID

Wenn das eindeutig zugeordnet werden kann, ok.

Default-Wert für Hostname: envoy.local (hatte ich damals drin, weiß nicht warum das rausgeflogen ist)

Hostnamen/IPs sind in der Konfiguration im Standard bei openWB immer leer. In der 1.9 wurde es mit fiktiven Standardwerten definitiv übertrieben, daher haben wir uns bei software2 für diesen Weg entschieden. "envoy.local" kann aber gerne im Hilfetext zum Hostnamen genannt werden.

Weiß nicht, woran du im Moment arbeitest, aber ich würde sonst mal schauen ob ich das mit den Tokens hinbekomme. Vielleicht habe ich eine Chance kurzlebige Tokens zu bekommen, dann könnte ich die automatische Aktualisierung prüfen.

Das wäre gut. Wenn der Abruf eines Tokens mit Benutzer/Kennwort funktioniert, ist die Aktualisierung ebenfalls schon fertig. Im Gegensatz zu anderen OAuth Implementierungen gibt es hier kein "Refresh Token", mit dem ein neues abgerufen werden kann. Es wird immer zwingend Benutzer/Kennwort benötigt. Du kannst also entweder den Zeitstempel des Abrufen mit dem Token speichern oder das JWT decodieren und die Gültigkeit auslesen.

[stefan_o]

Was muss denn Deiner Ansicht nach noch bei der Batterie eingestellt werden?

Zumindest ob eine vorhanden ist und dann gibt es verschiedene Typen, die an unterschiedlichen Stellen ausgelesen werden (wobei die Batterie 1. Generation in Deutschland vermutlich extrem selten ist und die 3. Generation noch nicht auf dem Markt in D). Im Moment wird bei V2 ja auch immer probiert /ivp/livedata/status zu lesen, auch ohne Speicher, bei mir gibt es die gar nicht, weiß nicht ob es an der alten Firmware liegt oder daran, das kein Speicher vorhanden ist.

Wenn das eindeutig zugeordnet werden kann, ok.

Das kann man in der /ivp/meters auslesen. Die Frage ist, ob das Webinterface das über xmlhttprequest macht oder das Web-Interface das backend irgendwie abfragt und das in Python gemacht wird. Meine Idee wäre da einen Button zu haben "automatische Erkennung" oder so, der das ausführt.

Hostnamen/IPs sind in der Konfiguration im Standard bei openWB immer leer. In der 1.9 wurde es mit fiktiven Standardwerten definitiv übertrieben, daher haben wir uns bei software2 für diesen Weg entschieden. "envoy.local" kann aber gerne im Hilfetext zum Hostnamen genannt werden.

Das ist vielleicht sinnvoll, da envoy.local ja der Standard-Hostname des Gerätes ist.

Das wäre gut. Wenn der Abruf eines Tokens mit Benutzer/Kennwort funktioniert, ist die Aktualisierung ebenfalls schon fertig. Im Gegensatz zu anderen OAuth Implementierungen gibt es hier kein "Refresh Token", mit dem ein neues abgerufen werden kann. Es wird immer zwingend Benutzer/Kennwort benötigt. Du kannst also entweder den Zeitstempel des Abrufen mit dem Token speichern oder das JWT decodieren und die Gültigkeit auslesen.

Jein, die Aktualisierung kommt ja nur wenn kein Token vorhanden ist so wie ich den Code lese, wenn der Token ungültig ist, passiert erstmal nichts. Es wäre wohl auch sinnvoll den Token rechtzeitig zu aktualisieren (also z.B. 24 Stunden vor Ablauf) und nicht darauf zu warten bis er nicht mehr funktioniert. Und einen counter zu haben, das falls die Zugangsdaten zu Enphase nicht mehr passen, das er nicht alle 10 Sekunden wieder probiert ein Token zu erstellen, sondern irgendwann aufgibt.

Ich würde mich sonst mit den Tokens beschäftigen, da ich mit dem Interface-System nicht wirklich vertraut bin

[LutzB]

Was muss denn Deiner Ansicht nach noch bei der Batterie eingestellt werden?

Zumindest ob eine vorhanden ist und dann gibt es verschiedene Typen, die an unterschiedlichen Stellen ausgelesen werden (wobei die Batterie 1. Generation in Deutschland vermutlich extrem selten ist und die 3. Generation noch nicht auf dem Markt in D). Im Moment wird bei V2 ja auch immer probiert /ivp/livedata/status zu lesen, auch ohne Speicher, bei mir gibt es die gar nicht, weiß nicht ob es an der alten Firmware liegt oder daran, das kein Speicher vorhanden ist.

Ob eine Batterie vorhanden ist, wird dem System ja mitgeteilt, indem eine entsprechende Komponente angelegt wird.
Die Abfrage von "livedata" kann dann wirklich in die Komponente wandern bzw. nur ausgeführt werden, wenn ein Speicher konfiguriert wurde, da hast Du Recht.

Das kann man in der /ivp/meters auslesen. Die Frage ist, ob das Webinterface das über xmlhttprequest macht oder das Web-Interface das backend irgendwie abfragt und das in Python gemacht wird. Meine Idee wäre da einen Button zu haben "automatische Erkennung" oder so, der das ausführt.