Modul: SolarEdge API Abruf

Begonnen von felixm, 03 August 2018, 18:49:41

Vorheriges Thema - Nächstes Thema

cocojambo

#60
Hi,
Das mit dem Namenskonfikt kann vielleicht sein, glaube ich aber nicht so wirklich. Ich habe mehrere Doppelnamen bei mir vergeben, ohne Probleme. Das API u. das Solaredge Modul laufen ja manchmal einige Tage und es passiert nichts, obwohl das SolarEdge Modul den Abschaltfehler mal zwischenduch macht ohne Reaktion des API Modul darauf. Es würde mich ja auch nicht stören wenn die beide Module für wenige Sek. ausfallen und wieder starten, aber das API Modul startet ja nicht mehr, auch nicht mit reload. Das API Modul scheint zwar zu starten, meldet auch im State ready, macht aber nichts. Selbst der Befehl "get SolarEdgeAPI aggregates" holt nur einmal die neuen Werte und und mehr nicht. Es läuft danach nicht weiter. Nur ein Neustart von FHEM startet das API Modul erst wieder. Das ist der Fehler an dem Modul. Alle anderen Module, die ich installiert habe, lassen sich mit reload einwandfrei starten, nur API will das nicht.

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

pizmus

Hallo CoolTux,

ich habe ein paar Fragen zur Implementierung des Moduls. Es geht um Dinge, die schon von TeslaPowerwall übernommen wurden:

Es wird an mehreren Stellen auf $modules zugegriffen: in _Define, _Undef und in _Initialize. Kannst Du mir erklären was die Absicht dabei ist? Was passiert da genau? Kann man auf diese Zugriffe verzichten?

cocojambo scheint ein Problem mit dem Re-Start des Moduls zu haben. Die periodischen Readings fangen nach einem _Undef und _Define manchmal nicht an. Nach meinem Verständnis wird der Start der periodischen Readings über die _Notify Funktion gemacht. Dort wird (im Fall von TeslaPowerwall...) das erste Mal TeslaPowerwall2AC_Timer_GetData gerufen. Danach ruft sich die Funktion mit Umweg über einen InternalTimer immer wieder selbst auf. Kann es sein, dass der Start nicht zuverlässig funktioniert, z.B. weil die in _Notify verwendeten Events in diesem Szenario nicht auftreten, oder weil es irgendeine Race Condition gibt?
Ich bin auch nicht sicher was mit dem InternalTimer passiert wenn die Modul-Instanz gelöscht und kurz darauf wieder erzeugt wird. In _Undef und _Define wird der InternalTimer für die periodischen Readings jedenfalls nicht explizit gelöscht. Verstehst Du was da passiert?

Ich denke darüber nach die periodischen Readings in _Define über einen InternalTimer zu starten statt über _Notify. Außerdem würde ich alle Timer in _Undef explizit löschen.

Gruß,
pizmus

CoolTux

Hallo,

Die $modules sind aktuell nicht mehr im Code. Ich habe sie früher genommen damit ich meine Versionsnummer nach einem reload automatisch aktualisieren konnte. Ist nicht mehr nötig.

Thema Notify. Hier wird im Grunde auf globale Events reagiert. Am wichtigsten das INITIALIZED welches nach einem kompletten FHEM-Start kommt.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

pizmus

Hier ist eine neue Beta-Version "1.2.0betaExtendedLog".
Neuigkeiten:

- Beginn von Tag und Nacht sind als Attribut einstellbar.
- Intervalle sind für Tag und Nacht separat einstellbar.
- Man kann auswählen welche Readings erzeugt werden sollen. Das hat Einfluss auf die Gesamtzahl der Server-Anfragen pro Tag.
- Es gibt optional Debug Readings mit denen man die Zahl der verschickten, erfolgreichen und erfolglosen http Requests aufzeichnen kann.
- Mit "set resetDebugCounters" kann man die Debug Zähler zurücksetzen.
- Mit "set restartTimer" kann man die periodischen Readings neu starten.
- Das Internal NUMBER_OF_REQUESTS_PER_DAY zeigt die rechnerische Zahl der Requests pro Tag an, basierend auf den Attribut-Werten.
- Der Parameter interval von Define ist nun optional. Ich beabsichtige ihn irgendwann später komplett zu entfernen, da man die Readings vollständig ueber Attribute konfigurieren kann.
- Der Start-Mechanismus für die periodischen Readings wurden umgestellt.
- Timer werden beim Stoppen und Starten des Moduls gelöscht um Zombie-Timer zu verhindern.
- Es gibt Log Messages für alle relevanten Aktivitäten. (Nach der Beta-Phase werde ich die Log Level der Nachrichten erhöhen.)
- Alle neuen Funktionen sind in der CommandRef beschrieben. Dort sind nun auch Debug-Features als solche markiert. Diese können sich in der Zukunft ohne Vorwarnung ändern.
 
Die Default-Werte aller neuen Attribute sind so gewählt, dass sich das Modul ohne gesetzte Attribute genauso verhält wie zuvor. Neue Features des Moduls sollen nicht das Verhalten der bestehenden Features ändern.
 
Ich werde noch mindestens eine Woche warten bis ich die Version submitte. Viel Spass beim Testen!

pizmus

Hi cocojambo,
bitte wechsle auf die neue Beta-Version und starte FHEM neu. Das Handlung der Timer für die periodischen Readings ist verbessert. Falls Du Dein Problem trotzdem wieder siehst schicke mir bitte ALLE Log Einträge für SolarEdgeAPI seit dem Umstieg auf diese Version. Außerdem kannst Du versuchen das Modul mit "set restartTimer" wiederzubeleben. Die Log Einträge dazu können ebenfalls
hilfreich sein.
Gruß,
pizmus

pizmus

Zitat von: CoolTux am 08 Oktober 2019, 13:53:59
Die $modules sind aktuell nicht mehr im Code. Ich habe sie früher genommen damit ich meine Versionsnummer nach einem reload automatisch aktualisieren konnte.

Das kann ich nicht nachvollziehen. Die aktuelle Version von 46_TeslaPowerwall2AC.pm verwendet noch in allen 3 genannten Funktionen $modules.

Außerdem hat das Modul ebenfalls Probleme mit Zombie-Timern. Jedenfalls werden in _Undef die Timer nicht gelöscht. Sie bestehen weiter und können nicht mehr einfach gelöscht werden, weil sich nach einem Define $hash geändert hat. Für den Fall dass "defmod" verwendet wird, sollte man nach meiner Meinung ein RemoveInternalTimer in Define haben, weil ja dann _Undef nicht gerufen wird.

Gruß,
pizmus

CoolTux

Dann muss ich noch mal schauen ob wir beide auf die selbe Version schauen. Da es bei Tesla einige Änderungen gab kann es sein das ich gerade die Beta mir angeschaut habe.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Hast Recht. In der Tat ist der alte Code noch aktuell im SVN. Wir testen bereits seit einigen Tagen die neue API und das umgeschriebene Modul.
Geändert wurde vor allem die API Anpassung und die Verwendung von packages.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

cocojambo

Ich habe auf pizmus Anraten die Definition des Modul bei mir in "SE_API" geändert und es ist bis jetzt nicht mehr hängen geblieben.
Heute habe die neue Betaversion mal installiert und auch die neuen Attribute gesetzt, so wie ich sie manuell bereits in der vorigen Version im Modul geändert hatte.

define SE_API SolarEdgeAPI ################### ###### auto
setuuid SE_API 5d5bcf95-f33f-6f9b-0bd3-fbeacbb1b06299e1
attr SE_API alias SolarEdge API Daten Auswertung
attr SE_API dayTimeStartHour 08
attr SE_API enableAggregatesReadings 1
attr SE_API enableOverviewReadings 1
attr SE_API enableStatusReadings 1
attr SE_API event-min-interval .*:60
attr SE_API group Systemkontrolle
attr SE_API interval 180
attr SE_API intervalAtNightTime 1200
attr SE_API nightTimeStartHour 22
attr SE_API room System,Test


Das hat bei meiner Berechnung 310 Abfragen pro Tag ergeben und es funktionierte auch mit diesen Einstellungen. Was mir gleich nach der Installation auffiel ist das der Abfrage Interval vom Modul mit 930 angegeben wird. Eine Attribut namens dayTimeStartHour habe ich nicht gefunden. Ich habe stattdessen das Interval Attribut mal auf 180 gesetzt.

FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

pizmus

Hallo cocojambo,
es kommt nicht nur auf auf Intervall an, sondern auch darauf wie viele http Requests pro Intervall geschickt werden. Du hast mit enableAggregatesReadings=1 und enableOverviewReadings=1 und enableStatusReadings=1 drei http Requests pro Intervall konfiguriert: 3 * 310 = 930.

Das Attribut dayTimeStartHour ist in Deiner Nachricht enthalten: "attr SE_API dayTimeStartHour 08"

Gruß,
pizmus

cocojambo

Ich meinte natürlich das Attribut intervalAtDayTime. Deshalb habe ich das Attr. Interval genommen.
Aber mal eine andere Frage. In der API Dokumentation von SolarEdge ist die Rede davon, das man auch sämtliche Daten zu "storage" (Batteriewerte- und Daten) abrufen kann. Es ist aufwendig diese Werte mit abzurufen? oder kann man im Modul einige Zeilen ersetzen oder ändern um diese Daten zu erhalten?

Gruß
Nobbi
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

pizmus

Ok, verstehe. intervalAtDayTime gibt es (noch) nicht, weil ich auf Rückswärtskompatibilität geachtet habe. Das Attribut "interval" gab es für diesen Zweck schon, also habe ich es weiter verwendet. Wenn ich mal eine Version mache, bei der ich bewusst Kompatibilität breche, könnte ich das aufräumen.

Wenn die aktuelle Runde von Änderungen durch ist, möchte ich an neuen Readings arbeiten. Das API bietet tatsächlich noch nützliche Informationen. Ich bin noch nicht entschieden was genau ausgelesen werden soll und wie es dargestellt werden soll. Kumulierte Werte für jeden Tag oder jeden Monat könnten helfen. Auch Störungen werden über das API gemeldet.
Vorschläge sind sehr willkommen, möglichst mit detaillierten Informationen:
- Welches API und welche Elemente daraus?
- Was ist die Anwendung dafür?
- Müssen die Daten aus dem API dafür noch irgendwie aufbereitet werden?
- In welchem Zeitraster soll das Reading erzeugt werden? Mit dem "normalen" Intervall? Einmal täglich? ...

Manche Dinge lassen sich mit sehr wenig Aufwand machen, andere könnten mehr Zeit brauchen. Sehen wir dann.

Wenn es speziell um "storage" geht bräuchte ich Hilfe beim Testen, da ich keinen Speicher habe. Oder jemand gibt mir vorübergehend einen API Key für sein System.

Gruß,
pizmus

cocojambo

Hei pizmus,
Hast du denn die API-Dokumentation von SolarEdge für die storage Daten per API Zugriff zu auszulesen?
Ich bin nämlich aus dieser Beschreibung, was man alles für Werte über den Batteriespeicher auslesen kann, nicht so richtig schlau geworden.
Das mit dem API Key und der UserNR. kriegen wir dann schon hin über deine priv.Emailadresse für den Zeitraum wo du Ihn brauchst.
Ebenfalls mit der dem API Benutzer Handbuch.

Gruß
Norbert
FHEM6.2 FB7490 FB7430 3xraspi2+3+4 2xHM-LAN-CFG 2xESP CUL868 CUNO868 HUE-Bridge Harmony-Hub 5xHM-LC-Sw-PI-2 3xHM-WDS30-T2-SN 1xHM-LC_Sw4-DR 3xHM-ES-PMSw1-PI 7xFS20SIG2 6xFS20KSE 2xHM-ES-PMSW1-PL 5xS300TH 1xASH2200 1xEM1000

pizmus

Die Doku gibt's im Internet beim Hersteller:
https://www.solaredge.com/sites/default/files/se_monitoring_api.pdf

Suche in dem Dokument nach "storageData". Das API liefert Informationen wie aktuelle Lade-/Entladeleistung, Ladezustand in Prozent, Kapazität, Batteriezustand und mehr.

Gruß,
pizmus

pizmus

Die Version 1.2.0 ist jetzt verfügbar.

Als nächstes muss ein Thema geklärt werden, über das ich beim Studium der API Doku gestolpert bin: SolarEdge verlangt die Darstellung des Firmenlogos wenn man Daten aus dem API darstellt.
https://forum.fhem.de/index.php/topic,104629.0.html