Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
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
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
Zuletzt geändert von stefan_o am Mi Mär 13, 2024 12:43 am, insgesamt 1-mal geändert.
Re: Aktueller Guide zu Erstellung/Anpassung von Modulen
Guten Morgen Stefan,
den Beitrag im Wiki gesehen?
https://github.com/openWB/core/wiki/Neu ... grammieren
den Beitrag im Wiki gesehen?
https://github.com/openWB/core/wiki/Neu ... grammieren
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
Re: Aktueller Guide zu Erstellung/Anpassung von Modulen
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.
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.
Re: Aktueller Guide zu Erstellung/Anpassung von Modulen
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
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
Re: Aktueller Guide zu Erstellung/Anpassung von Modulen
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.
Re: Aktueller Guide zu Erstellung/Anpassung von Modulen
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.LutzB hat geschrieben: ↑Di Mär 12, 2024 5:57 pm 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.
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.
Re: Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
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:
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)
Re: Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
Was muss denn Deiner Ansicht nach noch bei der Batterie eingestellt werden?
Da hätte ich mich als nächstes dran gemacht. Ist ja in der Doku gut beschrieben. Kannst Du gerne übernehmen.
Wenn das eindeutig zugeordnet werden kann, ok.
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 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.
Re: Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
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.
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.
Das ist vielleicht sinnvoll, da envoy.local ja der Standard-Hostname des Gerätes ist.LutzB hat geschrieben: ↑Mi Mär 13, 2024 6:21 am 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.
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.LutzB hat geschrieben: ↑Mi Mär 13, 2024 6:21 am 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.
Ich würde mich sonst mit den Tokens beschäftigen, da ich mit dem Interface-System nicht wirklich vertraut bin
Re: Enphase Firmware ≥ 7.0 (war Aktueller Guide zu Erstellung/Anpassung von Modulen)
stefan_o hat geschrieben: ↑Mi Mär 13, 2024 4:11 pmZumindest 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.stefan_o hat geschrieben: ↑Mi Mär 13, 2024 4:11 pm 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.