Modul: SolarEdge API Abruf

[pizmus]

Das FHEM Modul akkumuliert nicht, aber SolarEdge akkumuliert viele Werte auf dem Server. Es gibt Readings um auf diese akkumulierten Werte zuzugreifen. Schau Dir mal die commandref zu den Readings an. Da Du z.B. nach aggregates-Consumption-cumToday fragst, könnten die Readings dailyAggregates-<meterType>-cum* (setzte enableDailyAggregatesReadings) die Lösung sein.
Gruß,
pizmus

[satprofi]

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

hallo. welches ist jetzt die aktuelle version? hsbe update 70_SolarEdgeAPI.pm durchgeführt, aber immer noch die beta2019



Gesendet mit Tapatalk

[pizmus]

Hallo satprofi,
die aktuelle Version ist die "2.0.1". Ich vermute mal Du meinst die Version "2.0.0beta20dec2019". Wenn "update" und "shutdown restart" eine von Hand installierte Version nicht ersetzt dann lösche die Datei und führe "update" und "shutdown restart" nochmals aus.
Gruß,
pizmus

[satprofi]

heute hats geklappt.
Danke

[cocojambo]

Hallo pizmus,

Modul läuft immer noch zufriedenstellend. Was mir aber jetzt bei einer Auswertung der "daily" readings aufgefallen ist, das diese immer um 22.00 Uhr aufhören. Die Startzeit für Daily kann ich leider nicht sehen.
Daily müßte aber um 00:00 Uhr beginnen und um 23.59 Uhr enden. Wahrscheinlich liegt das daran, das du Daily Start- und Enduhrzeiten von der Intervall Berechnug dafür genommen hast.
Kann das sein?
Ich habe dir mal ein Screenprint angehangen.

Gruß
Norbert

Nachtrag 05.05.2020: Mir ist aufgefallen, das alle Werte die einen Auflauf beinhalten nicht um 23.59 Uhr enden sondern auch zu früh um 22.00 Uhr.

[pizmus]

Hi cocojambo,
der Endzeitpunkt ist wohl nicht ganz perfekt gewählt. Für meine Anwendung reicht 22:00 Uhr. Ich habe keinen Speicher, und daher keine Energieflüsse wenn die Sonne "weg" ist. Ich werde mir demnächst mal anschauen, ob ich das einfach auf 23:59 ändern kann.
Gruß,
pizmus

[cocojambo]

Hallo prizmus,

schon mal Vielen Dank im Voraus für deine Meldung. Mir ist das nur aufgefallen weil die Lade- und Entladewerte der Batterie nicht stimmen konnten. Ich brauche wie zum Beispiel auch im Statistics Modul, was ich dazu auch nutze, als Start-und Stopzeit den Tagesbeginn und das Tagesende. ( 00.00 Uhr bis 23.59 Uhr) weil alle Werte wie daily, month, year wie auch die momentan Werte ab 00.00 bis 23.59 Uhr  life angezeigt werden bzw.als Summe berechnet sind. Das Modul müßte nicht nur bis 23.59 rechnen sondern auch mit 00.00 beginnen. Sonst kann ich zb. die Verbrauchswerte, den Lade-und Entladezustand, den Wirkungsgrad, etc. nicht miteinander vergleichen, berechnen und auswerten.
Ich hoffe das macht dir nicht allzugroße Mühe, aber leider kann ich dir nicht dabei helfen, dazu habe ich viel zu wenig Ahnung davon.

Mit freundlichem Gruß aus "Kölle"
Norbert

[pizmus]

Hallo Norbert,
hier findest Du eine Version 2.1.0beta, bei der die "daily" Readings um 23:59 erzeugt werden. Die Werte, die der SolarEdge Server zu dem Zeitpunkt als summierte Werte liefert, werden verwendet. Das FHEM Modul summiert nicht.
Probier die Version mal aus und sag mir Bescheid ob das für Dich funktioniert.
Gruß,
pizmus

[cocojambo]

Hallo pizmus,

Vielen Dank, habe die Datei installiert und gucke mal ob es funktioniert.
Melde mich dann mit einem Feedback dazu.

Es sind aber auch Daily Abfragen darunter die laufend von 00.00 Uhr bis 23.59 Uhr auf dem Server aktuallisiert werden.
Werden diese Abfragen auch weiterhin über den ganzen Tag abgefragt ?

Gruß
Nobbi

[cocojambo]

Hallo pizmus,

ich habe jetzt mal eine Woche die laufenden Daten aufgezeichnet und ausgewertet.
Das mit dem Zeitpunkt 23.59 funktioniert gut, aber die Werte werden nicht fortlaufend bis 23.59 aktuallisiert. Alle Day, Month und year-Werte müßten fortlaufend abgefragt werden bis 23.59 und dann könnte man die "Once" Werte vom API Server "abholen", wobei die MonthOnce Werte ja schon als Reading drin stehen. In der Device Spezial Help werden die DayOnce Werte z.B. für DailyAggregates auch schon aufgeführt, tauchen aber in den Readings nicht auf. Es ist sonst nicht möglich eine grafische aktuelle Darstellung über den Tag als Day, Month Diagramm darzustellen. Bei den Storage Werten funktioniert das wunderbar. Es lassen sich Lade-und Entladekurven darstellen, sogar Lade und Entladeverluste fortlaufend über den ganzen Tag, und in den daily-storage stehen auch die Tages-Endwerte drin.
Es müßten also alle daily-Werte bis 23.59 mit dem normalen Intervall abgerufen werden und anschließend um 23.59 die entsprechenden Once-Werte vom API Server geholt werden.
Ich weiß nicht in wie weit diese Werte vorhanden sind, aber wenn ich auf die Monitoring App gehe, sind diese Werte alle fortlaufend und als Summe zu jedem Abfrage Intervall vorhanden. Die API-Doku kann ich leider nicht interpretieren um versuchsweise mal eine "Probeabfrage" zu starten.
Deshalb weiß ich auch nicht welcher Datenumfang überhaupt zur Verfügung steht.

Wenn das ein zu großer Aufwand ist, dann würde es auch ausreichen die vom Server bereitgestellen Daten einfach fortlaufend abzurufen, wie in der letzten Version, dann nur ohne Zeitbegrenzung. Und wenn die Once Werte auch auf dem Server vorhanden sind, diese mit abzurufen.

Gruß aus Köln
Norbert

[pizmus]

Hallo Norbert,

ich fürchte wir reden noch komplett aneinander vorbei. Aber wir sortieren das schon noch aus.

,,Das mit dem Zeitpunkt 23.59 funktioniert gut, aber die Werte werden nicht fortlaufend bis 23.59 aktuallisiert."

Es ging bei der Änderung doch um ,,daily" Werte, die jetzt nicht mehr um 22:00 Uhr, sondern um 23:59 als Reading ausgegeben. ,,daily" Readings werden per Definition nur einmal täglich erzeugt. In der Hilfe steht das auch so: ,,Other readings are generated once per day only. Reading groups which are updated once per day have a name starting with "daily"."
Daher verstehe ich nicht was Du an dieser Stelle mit ,,fortlaufend" meinst.

Alle Day, Month und year-Werte müßten fortlaufend abgefragt werden bis 23.59 und dann könnte man die "Once" Werte vom API Server "abholen", wobei die MonthOnce Werte ja schon als Reading drin stehen.

Ich verstehe leider überhaupt nicht was Du sagen willst.

In der Device Spezial Help werden die DayOnce Werte z.B. für DailyAggregates auch schon aufgeführt, tauchen aber in den Readings nicht auf.

Welches Reading meinst Du genau mit dem Beispiel? Meinst Du ,,dailyAggregates-<meterType>-cumDayOnce"? Was meinst Du mit ,,tauchen aber in den Readings nicht auf."?

Es ist sonst nicht möglich eine grafische aktuelle Darstellung über den Tag als Day, Month Diagramm darzustellen. Bei den Storage Werten funktioniert das wunderbar. Es lassen sich Lade-und Entladekurven darstellen, sogar Lade und Entladeverluste fortlaufend über den ganzen Tag, und in den daily-storage stehen auch die Tages-Endwerte drin.

Prima, in diesem Fall scheinst Du die erwarteten Daten zu bekommen. Welches Reading verwendest Du für die Lade- und Entladekurven? storage-<serial>-lifetimeEnergyCharged und storage-<serial>-lifetimeEnergyDischarged?

Es müßten also alle daily-Werte bis 23.59 mit dem normalen Intervall abgerufen werden und anschließend um 23.59 die entsprechenden Once-Werte vom API Server geholt werden.

Wie gesagt, dies ist ein falsches Verständnis der ,,daily" Werte. Du suchst eigentlich etwas anderes. Ist es vielleicht das Reading aggregates-<meterType>-cumToday für die periodische Abfrage während des Tages und das Reading ,,dailyAggregates-<meterType>-cumDayOnce" für die Tagessumme um 23:59?

Wenn das ein zu großer Aufwand ist, ...

Ob es Aufwand ist weiß ich noch nicht, weil ich noch nicht weiß welche Werte Dir genau fehlen.

..,dann würde es auch ausreichen die vom Server bereitgestellen Daten einfach fortlaufend abzurufen, wie in der letzten Version, dann nur ohne Zeitbegrenzung.

Keine Ahnung was Du meinst. Das einzige was ich verändert hatte war der Zeitpunkt der ,,daily..." Readings.

Wahrscheinlich ist es am einfachsten wenn Du eindeutig spezifizierst welche Datenreihen Du brauchst, unabhängig von den bestehenden Readings und deren Namen. Einfach die technische Größe mit Einheit und Zeitpunkt/Intervall.

Gruß,
pizmus

[derkosta]

Hallo Leute, habe das letzte Modul, auch die Beta bei mir installiert.

Leider aktualisieren sich nicht die Status Werte im Modul. Nur die Overview Werte.

[pizmus]

Hallo zusammen,
hat noch jemand das gleiche Problem wie derkosta? Oder funktionieren die "status" Readings für andere? Meine Anlage unterstützt das "status" API leider nicht.

Hallo derkosta,
gibt es einen eindeutigen zeitlichen Zusammenhang mit der Version, d.h. hat es vor dem Update fehlerfrei funktioniert?
Was liefert "get numberOfRequests"?
Was liefert "get status"?
Was steht im Logfile? Was steht dort mit verbose=5?
Setze außerdem mal das Attribut "enableDebugReadings" = 1. Wie sehen die "debug..." Readings nach 1 oder 2 Tagen aus?

Gruß,
pizmus

[derkosta]

Hallo pizmus, ich hatte vorher die "normale" Version da ging es schon nicht.

Ich hatte aber auch vor ca. 6 Monaten schon einmal eine Version installiert, da hat die Aktualisierung der Status Werte funktioniert.

Mit get status bekomme ich die Werte. Aber eben nicht automatisch im eingestellten Intverall.

Debug probier ich morgen mal aus.

Danke

[pizmus]

Hallo derkosta,

Dein Problem ist, dass die Status Readings per Default ab Version 2.0.0 nicht aktiviert sind. Das wurde hier im Forum besprochen.
Setze das Attribut "enableStatusReadings" auf 1. Ich empfehle Dir auch die commandref nochmal zu lesen, sowie den Post vom 14.12.2019.

Gruß,
pizmus