Modul: SolarEdge API Abruf

[pizmus]

Version 1.3.0 mit SolarEdge Logo ist jetzt verfügbar.

Die nächste Version soll neue Readings bereitstellen. Weitere Vorschläge sind willkommen.

[cocojambo]

Hallo pizmus,

habe die neue Version 1.30 mal installiert. Ich denke bis auf das Logo hat sich ja nichts geändert. Die Storage Information auf Seite 26/27 des Handbuchs habe ich mir mal durchgelesen. Die würden mich schon interessieren. Meinst du es ist mit zu viel Arbeit verbunden diese noch ins Modul zu integrieren?
Ich könnte die auf jeden Fall brauchen.

Gruß aus "KÖLLE"
Nobbi

[pizmus]

Danke für die Rückmeldung. Das storageData API werde ich auf jeden Fall berücksichtigen.
Außerdem interessant finde ich:
- alertSeverity aus dem siteDetails API -> Damit kann man Events erzeugen wenn die Anlage eine Betriebsstellung feststellt. Ich denke es reicht wenn man das einmal täglich abfragt.
- lifeTimeData aus dem dem overview API -> Falls sich jemand für den Gesamtertrag einer Anlage interessiert. Diese Information kommt kostenlos wenn man das Overview API ohnehin für die "aktuelle" Leistung ausliest.
- Aufaddierte Energie-Werte für den aktuellen Tag, den aktuellen Monat und für das aktuelle Jahr basierend auf dem energyDetails API, einmal am Tag ausgegeben.

[pizmus]

Hier ist nun eine Beta-Version mit neuen Readings. Ich werde das noch eine Weile bei mir testen.

- Es gibt mehr Readings aus dem Overview-API. Wenn man "nur" an der produzierten Energie interessiert ist, kann man damit sehr einfach die Erträge pro Tag, Monat, Jahr und über die Lebensdauer auslesen. Das Aufaddieren übernimmt der SolarEdge Server. Das API liefert auch die "aktuelle" Leistung.
- Die "alertSeverity" Information liefert der Server entgegen der Doku nicht. Das dailyDetails-status Reading könnte auch geeignet sein, um einen Ausfall zu erkennen. Ich habe das aber noch nicht ausprobiert.
- Man kann viele Readings zusätzlich nur einmal am Tag erzeugen lassen. Die Readings-Namen beginnen dann mit "daily". Summierte Monatswerte können einmal im Monat, am Abend des letzten Tages erzeugt werden.
- Es gibt Readings aus dem Storage API, aber ich habe nur mit Fake-Daten getestet. @cocojambo, es wäre klasse wenn Du tagsüber mal für ein paar Ausleseintervalle den Loglevel auf 5 Stellen könntest, und mir alle Logeinträge für Dein SolarEdgeAPI per PM schicken könntest.
- Es sollte weiterhin alles rückwärtskompatibel sein, d.h. um die neuen Readings zu nutzen muss man sie per Attribute anschalten.
- Weitere Infos in der CommandRef.

[cocojambo]

@pizmus
Habe gerade bemerkt das du eine neue beta-version reingestellt hast. Habe sie bereits runtergeladen und werde sie mal bei mir in Ruhe testen und dir berichten.
Gruß
Norbert

[cocojambo]

@pizmus

Ist es richtig das sich die daily und overview Readings nicht von selbst aktuallisieren? Seit gestriger Installation des Moduls stehen immer noch die gleichen Werte drin.
Erst wenn ich die get..... Funktion für diese Readings anklicke aktuallisieren sich diese. Die müßten sich doch im Intervall Zeitraum, so wie auch alle anderen Werte, mit aktuallisieren, denn die sind ja nach manueller Abfrage in aktuallisierter Form auf dem Server vorhanden, oder liege ich da falsch?

Man kann zwar mit dem get-Befehl daily Aggregates und daily Overview anfordern aber in den Readings tauchen diese Werte nicht auf.

Ich muß mir sowieso die daily und overview Werte mal genau angucken und mit anderen ausgelesenen Werten vergleichen um mal dahinter zu kommen, was für Berechnungen und Angaben das sind.
Ansonsten funktioniert das Modul einwandfrei. Die "verbose5" Auslesewerte für dich habe ich nicht vergessen, mache ich noch.

Gruß
Norbert

[pizmus]

Hallo Norbert,
die overview Readings sollten sich selbstständig aktualisieren, mit dem normalen Intervall, sofern enableOverviewReadings=1 gesetzt ist.

Die daily* Readings werden tatsächlich nur einmal am Tag erzeugt (wenn sie überhaupt "enabled" sind), nämlich um 22:00 Uhr. Das sind die gleichen Werte wie bei den Readings ohne "daily" im Namen. Der einzige Unterschied ist, dass sie nur einmal am Tag erzeugt sind und einen anderen Namen haben. Ich habe das bei mir so eingerichtet, dass ich alle "daily*" Readings in ein LogFile für das ganze Jahr schreibe. Damit erstelle ich Diagramme, die ein ganzes Jahr zeigen.

Ich finde das Overview API recht geschickt. Für meine einfache Konfiguration (ohne Storage, ohne Energieflüsse zwischen verschiedenen Komponenten) reicht das Overview API aus, um alle interessanten Werte direkt vom Server zu bekommen: "aktuelle" Leistung, aufaddierte Erträge für Tag, Monat, Jahr und Lifetime. Das Modul muss dafür nichts selber zusammenzählen, weil der Server das macht. Wenn mal ein Reading ausfällt, liefert der Server bei der nächsten Anfrage trotzdem die richtigen addierten Werte.
Die "aggregates" Readings haben den Vorteil, dass man ggf. weitere "meters" auslesen kann (z.B. Verbrauch), dafür muss man aber im FHEM Modul zusammenzählen.
Wenn Du bislang die "aggregates" Readings verwendest hast, kannst manchen davon nun "overview" Readings gegenüberstellen. Nach meiner Beobachtung sind die Werte konsistent.

Gruß,
pizmus

[pizmus]

@uxtuner, danke für die Log-Daten zum Debuggen. Hier ist eine neue Version (1.4.0betaNewReadings20191117).

Die Info zum Batterieladezustand heißt anders als im API Handbuch dokumentiert. Das Reading sollte jetzt funktionieren.

Die Log-Ausgaben sind nun deutlich reduziert. Zum einen weil ich Debug Outputs wieder reduziert habe. Zum anderen weil ich den http Request für storageData korrigiert habe.

@uxtuner, achte bitte mal auf das Reading storage-*-batteryState . Ich vermute, dass der Text nicht zum Wert passt. Auch hier habe ich mich auf das API Handbuch verlassen, bin aber nicht sicher ob die Doku stimmt.

Gruß,
pizmus

[cocojambo]

Beim Auslesen des Batt_State direkt aus dem Inverter habe ich folgende Klartexte definiert:

Code Auswählen Erweitern

Batt_State { my $val = ReadingsVal("SolarEdge", "Batt_State", "Err");; my %rets = ("Err"  => "Error","0" => "ist aus","1" => "Standby","2" => "initialisiert","3" => "wird geladen","4" => "wird entladen","5" => "Fehler","6"  => "Leerlauf","7"  => "Leerlauf",);; $rets{$val}}

Vielleicht hilfts.

Aber was noch sehr komisch ist, und nur manchmal da ist und in den anderen Versionen, so meine ich, funktionierte, ist, das unter State jetzt ein Zahl steht "429" oder "fetch data - 3 entries in the Queue"
da hätte ich lieber wirklich den State stehen, der da ja auch eigendlich hin gehört, weil ich diesen auch auswerte. (z.B.=active,opened,Initialized,Connected oder absent.

Gruß
Norbert

[pizmus]

Hi Nobert,

zu "Batt_State": Wo hast Du denn die Zuordnung her? In meiner API Doku aus dem Internet steht etwas anderes, aber Deine Informationen scheinen zu stimmen. Aus der Doku: "batteryState-number -can be one of the following: 0 (Invalid), 1 (Standby), 2 (Thermal Mgmt.), 3 (Enabled), 4 (Fault)"

zu "state": Das war tatsächlich von Anfang an drin. Ich habe es aus Gründen der Kompatibilität bislang drin gelassen. Im Source Code findest Du ein paar Stellen, die mit "TODO ... (INCOMPATIBLE CHANGE)" markiert sind. Ein paar davon haben mit der Verwendung von "state" zu tun. Vorschlag: Wenn wir mit der aktuellen Runde von Änderungen durch sind, schlage ich einen Satz von nicht-kompatiblen Änderungen vor. Da wird das dann dabei sein.

Gruß,
pizmus

[cocojambo]

Hei pizmus,

Diese Angaben habe ich mal als ich die Anlage installiert habe mit der Anleitung zum Auslesen des Inverters bekommen.
Und da habe ich mir das "rauskopiert" und notiert und in FHEM eingebaut.

Code Auswählen Erweitern

 Battery Status – Battery operating state: 0 – Off; 1 – Standby; 2 – Init; 3 – Charge; 4 – Discharge; 5 – Fault; 7 - Idle

Gruß
Norbert

[pizmus]

Die Decodings für den Batteriezustand habe ich übernommen.

Die neue Version 1.4.0 ist jetzt im FHEM SVN.

Viele Grüße,
pizmus

[cocojambo]

Hallo pizmus,

deine 1.4.0 Version scheint ohne Probleme und fehlerfrei zu laufen. wonderfull.
Schön wäre noch, wenn du mal an mein Anliegen mit dem "State" denken könntest.

.........schlage ich einen Satz von nicht-kompatiblen Änderungen vor. Da wird das dann dabei sein.

Gruß
Nobbi

[pizmus]

Hallo Nobert und alle,
hier sind meine Vorschläge für Version 2.0.0. Die vorgeschlagenen Änderungen führen dazu, dass man ggf. Device-Definitionen ändern muss, zusätzliche Attribute setzen muss oder sich an geänderte Reading-Namen anpassen muss. Für alle die das Modul schon nutzen lohnt es sich also, die Liste anzusehen und ggf. Rückmeldung zu geben.

Code Auswählen Erweitern


#           - "define" does not assign attribute room="Photovoltaik" anymore
#             reason: different users organize rooms differently, it is not the business of the FHEM module
#             impact: attribute room has to be assigned by user for new devices
#           - remove parameter "interval" of "define" function
#             reason: The interval and other related settings are configured via attributes.
#             Attributes are easy to change while the device is alive. Making the same setting
#             via define is redundant and increases complexity.
#             impact: existing devices will fail after update/restart if the optional parameter
#             was used. The device definition has to be changed by removing the last parameter.
#           - rename attribute "interval" to "intervalAtDayTime"
#             reason: make names consistent (intervalAtDayTime/intervalAtNightTime)
#             impact: All users who have specified attribute "interval" must change it to "intervalAtDayTime".
#           - Rename reading group so that they match the SolarEdge API name:
#             Rename "aggregates" to "energyDetails".
#             Rename "status" to "currentPowerFlow".
#             Rename readings and related attributes.
#             Reason: Consistent naming between FHEM module and SolarEdge API.
#             Impact: All users that rely on "aggreates" readings and/or "status" readings
#             need to update related diagrams, notify, ...
#           - default values of attributes:
#             "enableStatusReadings" -> change from 1 to 0
#             "enableAggregatesReadings" -> change from 1 to 0
#             "enableOverviewReadings" -> change from 0 to 1
#             "enableDailyDetailsReadings" -> change from 0 to 1
#             "enableDailyOverviewReadings" -> change from 0 to 1
#             "dayTimeStartHour" -> change from 7 to 6
#             "intervalAtDayTime" -> change from 300 to 215
#             reason: provide a simple default configuration that works as a good starting point for new users
#             impact: Users that have started with older versions, and who rely on default values, have to set attributes.
#           - do not show number of queue entries in readings "state" and "actionQueue".
#             example of state value (old behavior): "fetch data - 2 entries in the Queue"
#             reason: not a good value of "state" to trigger on
#             impact: Most likely none.
#           - Do not show http errors in readings "state" and "lastRequestError", write error message to log file instead.
#             reason: not a good value of "state" to trigger on. Information should be in the log file.
#             impact: Most likely none. From now on look at log file for error messages.
#           - Do not show JSON errors in readings "JSON Error" and "state", write error message to log file instead.
#             reason: not a good value of "state" to trigger on. Information should be in the log file.
#             impact: Most likely none. From now on look at log file for error messages.
#           - Do not report "aggregates response is not a Hash" via reading "error".
#             Do not report "API currentPowerFlow is not supported by site." via reading "error".
#             reason: Information should be in the log file.
#             impact: Most likely none.
#           - Do not assign text messages to *_status readings of "status" readings group.
#             Use "-" instead if no data is available.
#             reason: Simplify automatic processing of readings.
#             impact: User needs to change e.g. "notify" definitions, if any.



Gruß,
pizmus

[cocojambo]

Hallo pizmus,

habe mir deine Änderungsvorschläge mal angesehen. Sind ja keine "weltbewegenden" Änderungen drin, aber einige davon sind schon sinnvoll. Ob die Änderungen der default Werte der Attribute wichtig sind,weiß ich nicht, ist vielleicht Geschmacksache. Ich setzte sowieso alle Attribute manuell. Die Änderung von 7 to 6 /300 to 215 bräuchten nicht zu sein.
Mein Blick fiel natürlich direkt auf das state value. Die Änderung finde ich gut, das jetzt endlich ein aussagekräfiger state herauskommt, sowas wie: ERROR und READY wäre mein Vorschlag.

Ansonsten, tolles Modul, funktioniert einwandfrei und läßt bei mir im Moment keine Wünsche mehr offen.

Gruß
Nobbi