Modul: SolarEdge API Abruf

[pizmus]

Hallo Nobbi,

Danke für die Rückmeldung. Ich habe noch folgende Änderung aufgenommen:

Code Auswählen Erweitern


#           - Set the internal "STATE" and the reading "state" to:
#               - "error" if the last http request has shown an error condition
#               - "disabled" if the device is disabled
#               - "active" otherwise


Ich habe mich entschieden, diese Änderungen NICHT zu machen:

Code Auswählen Erweitern


#           - 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, ...


Dadurch sollten bei den meisten Bestandsnutzern keine Änderungen nötig sein, außer bisherige Default-Einstellungen durch Attribut-Einstellungen zu ersetzen, und ggf. den "interval" Parameter von define/defmod zu entfernen.

Hier die vollständige Beschreibung der Änderungen:

Code Auswählen Erweitern


# 2.0.0     changes which are not backward compatible:
#           - "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".
#           - 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.
#           - Set the internal "STATE" and the reading "state" to:
#               - "error" if the last http request has shown an error condition
#               - "disabled" if the device is disabled
#               - "active" otherwise


Die neue Beta-Version habe ich angefügt. Wenn es keine Einwände mehr gibt werde ich das in den nächsten Wochen submitten.

Viele Grüße,
pizmus

[cocojambo]

Hallo pizmus,

leider macht die jetzige Version ERROR. Wenn ich nur:

Code Auswählen Erweitern

define SE_API SolarEdgeAPI ###################### ###### auto
attr SE_API alias SolarEdge API Daten Auswertung
attr SE_API room System

eingebe, kommt folgende Meldung:

Code Auswählen Erweitern

ERROR:
incorrect number of parameters: define SolarEdgeAPI

MFG
Norbert

[pizmus]

Das ist die Änderung 'remove parameter "interval" of "define" function'. Lass das "auto" mal weg. Dann sollte es gehen.
Gruß,
pizmus

[cocojambo]

Ja habe es ausprobiert, es funktioniert ohne auto.
Naja, wer lesen kann ist klar im Vorteil.
Gruß
Nobbi

[cocojambo]

Aber im LOG tauchen bei jeder Aktuallisierung div. Meldungen auf, die die LOG Datei auf Dauer sicherlich sehr groß machen.

Code Auswählen Erweitern

2019.12.20 19:04:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:04:31 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:04:32 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:04:33 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:07:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:07:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:07:30 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:07:30 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:10:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:10:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:10:30 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:10:31 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:13:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:13:29 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:13:31 3: SolarEdgeAPI (SE_API) - new state: active
2019.12.20 19:13:33 3: SolarEdgeAPI (SE_API) - new state: active

Müssen diese Meldungen im LOG sein?
Gruß
Norbert

[pizmus]

Hi Norbert,
nein, die sollen nicht da sein. Das war wohl der falsche Log Level... Hier ist die nächste Version.
Danke fürs Testen!
pizmus

[pizmus]

Die neue Version 2.0.0 ist in Kürze online. Wie angekündigt hat sie ein anderes Default-Verhalten als die Vorgänger. Wer bislang das Modul verwendet hat, muss wahrscheinlich folgende Anpassungen machen:

• Der letzte Parameter von "define", mit dem man das Intervall angeben konnte, muss entfernt werden. Wer den Wert "auto" verwendet hat muss das Attribut intervalAtDayTime auf den Wert 300 setzen. Wer eine Zahl angegeben hat muss nun das Attribut entsprechend setzen.
• Wer bislang mit der Default-Auswahl von Readings gearbeitet hat, kann das mit folgenden Attributen wiederherstellen:
  enableStatusReadings 1
  enableAggregatesReadings 1
  enableOverviewReadings 0
  enableStorageReadings 0
  enableDailyDetailsReadings 0
  enableDailyStorageReadings 0
  enableDailyAggregatesReadings 0
  enableDailyOverviewReadings 0
  Ansonsten bitte entsprechend anpassen.

Eine vollständige Liste der Änderungen gibt es weiter oben.
Die Commandref ist aktuell...

Viel Erfolg!
pizmus

[cocojambo]

Hallo pizmus,

habe die Version 2.0.0. installiert. Läuft bis jetzt einwandfrei. Es kommt jedoch nach jeden Neustart im LOG diese Meldung.
Vielleicht hats ja nix zu sagen.

Code Auswählen Erweitern

2019.12.29 20:17:01 1 : PERL WARNING: Use of uninitialized value $value in addition (+) at ./FHEM/70_SolarEdgeAPI.pm line 972.

Grub
Norbert

[pizmus]

Hallo Norbert,
die Daten vom SolarEdge Server für die energyDetails Query scheinen bei Dir manchmal ein leeres Feld zu enthalten. Ich habe die Stelle aus Deiner Fehlermeldung so geändert, dass sie damit klar kommt, siehe Version 2.0.1 .
Viele Grüße,
pizmus

[cocojambo]

Hallo pizmus,

Wo und Wann kann ich die 2.01 runterladen und mal ausprobieren?

Gruß
Nobbi

[pizmus]

Die Version 2.0.1 habe ich schon "submitted", sie kommt also mit einem Update.
Viele Grüße,
pizmus

[Trefzy]

Hallo felixm, hallo Pizmus

vielen Dank für eure tolle Arbeit und das Modul. Ich habe seit kurzem einen SolarEdge SE5 Wechselrichter mit 2 Strings. Jedes Modul hat wegen 5 verschiedenen Ausrichtungen einen Optimierer. In der API hab ich gelesen dass jeder dieser Optimierer auch einzeln abgefragt werden kann. Müsste unter dem Punkt "Site Energy - Detailed" sein....Vorausgesetzt ich verstehe die API Beschreibung richtig.

Nach Installation des Moduls 2.0.0beta20dec2019 bekomme ich allerdings nur folgende Readings:
overview-energyDay
overview-energyLifetime
overview-energyMonth
overview-energyYear
overview-power
state

Da ich mit Programmierung nicht so viel am Hut habe daher die Frage an Euch Profis. Könnt ihr diese oben beschriebenen Readings umsetzen?

Wäre toll von Euch zu hören
vielen Dank schon mal

[pizmus]

Hallo Trefzy,

Daten aus dem "Site Energy - Detailed" API stellt das Modul bereit, wenn man die "aggregates" Readings einschaltet. Das geht mit dem Attribut "enableAggregatesReadings", siehe commandref.

Ich lese die API Doku zum Thema "Site Energy - Detailed" nicht so, dass man dort Werte pro Optimierer/Modul oder pro String auslesen kann. Es gibt Werte nur für "Meters", das sind "Production", "Consumption", "SelfConsumption", "FeedIn" und "Purchased", und auch nur wenn die Informationen bei dem PV System zur Verfügung stehen.
Gib mir vielleicht mal einen Tipp wo Du das mit den Daten pro Optimierer/Modul gesehen hast.

Die Overview Readings sind standardmäßig aktiviert, weil man damit für praktisch jedes System mit nur einer Server-Anfrage die wichtigsten Informationen bekommt. Man kann aber weitere Readings über Attribute einschalten. Die Gesamtzahl der Server-Anfragen pro Tag ist aber begrenzt. Siehe commandref.

Ich rate davon ab, Beta-Versionen aus dem Forum zu verwenden, wenn es dafür keinen bestimmten Grund gibt. Einfach einen FHEM Update machen und Du hast die aktuellste Version.

Viele Grüße,
pizmus

[Trefzy]

Hi Pizmus,

das mit dem Readings enablen hab ich gesehen. Kommen einige Readings mehr.

Du hast Recht. Unter "Site Energy - Detailed" gibt es das nicht. Hatte ich falsch interpretiert. Jedoch habe ich gesehen das man Inventory Daten auslesen kann.
(Seite 32 Punkt Inventory)

• Inverters – SolarEdge inverters
▪ name – the inverter name e.g. Inverter 1
▪ manufacturer – manufacturer name (SolarEdge)
▪ model name e.g. SE16K
▪ CPU Firmware version e.g. 2.52.311
▪ DSP 1 Firmware version
▪ DSP 2 Firmware version
▪ communicationMethod – the communication interface used to connect to server. E.g. Ethernet.
▪ serialNumber – the equipment serial number e.g. 7F123456-00
▪ connectedOptimizers – number of optimizers connected to the inverter

So wie es aussieht aber auch nur die Anzahl ggf noch die Seriennummer.

Dann muss ich wohl auf die Einzelsummen meiner 5 Ausrichtungen verzichten.

Danke für deine Antwort und schönes Wochenende.

[kingmathers]

Hallo,

ich habe bisher immer die täglichen Werte (z.B. aggregates-Consumption-cumToday) am Ende vom Tag in einer eigenen dummy gespeichert und dann den Wert vom folgenden Tag draufaddiert, sodass ich einen fortlaufenden Zähler für die einzelnen Werte (Consumption, FeedIn, Production etc.) habe. Ist so eine Funktion mit dem aktuellen Modul integriert oder können weiterhin nur die täglichen Werte angegeben werden?