76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Wie mache ich diesen Wechsel und wo bekomme ich die Informationen dazu, wie ich mein SolarForecast Device dann umstellen muss?

Das ist sehr einfach.
Du wählst eine der angebotenen openMeteo API's im Attribut "ctrlWeatherDev1" als Wetteranbieter aus.
Was die API machen ist im Hilfetext erläutert.
Technisch bedingt wird diese API automatisch auch als "currentRadiationAPI" eingesetzt.
Das wars auch schon.

Edit: Danach sicherheitshalber einen Anlagencheck ausführen (die Zahnräder in der Grafik).

LG,
Heiko

[kask]

Code Auswählen Erweitern

ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 9500 daily API requests is reached or already exceeded. Process is exited.
was ist denn da los heute?

[DS_Starter]

Das ist der Daily Request-Zähler im Modul. Er ist begrenzt auf etwas unter 10000. Was hast du gemacht?

Mein Zähler für die Ensemble steht auf

        ?All => lastretrieval_time: 2024-04-05 10:29:21
                lastretrieval_timestamp: 1712305761
                response_message: success
                todayDoneAPIcalls: 42
                todayDoneAPIrequests: 1680

(sieht man mit "get ... solApiData")

Ich habe 2 Strings. Du?

[DS_Starter]

In meinem contrib liegt die Vorabversion 1.17.5.

Was ist drin:

- currentInverterDev: Syntax Check für Schlüssel "capacity" falls er gesetzt ist

- eine Berechnung des minimalen Open-Meteo Abrufintervalls. Im Normalfall ohne Bedeutung, allerdings
  könnte bei mehreren/vielen Strings und der Benutzung von Ensamble-Abrufen das Tageskontingent von 10000
  Requests erreicht werden. Um der Regelung bzgl. der kostenfreien Nutzung Rechnung zu tragen, wird das
  Kontingent und das Abrufintervall überwacht/reguliert.

- currentMeterDev: die Schlüssel conprice und feedprice können auf verschiedene Weise definiert werden:

Code Auswählen Erweitern

[conprice=<Feld>] [feedprice=<Feld>]

conprice Preis für den Bezug einer kWh (optional). Die Angabe <Feld> ist in einer der folgenden Varianten möglich:
<Preis>:<Währung> - Preis als numerischer Wert und dessen Währung
<Reading>:<Währung> - Reading des Meter Device das den Preis enthält : Währung
<Device>:<Reading>:<Währung> - beliebiges Device und Reading welches den Preis enthält : Währung

feedprice Vergütung für die Einspeisung einer kWh (optional). Die Angabe <Feld> ist in einer der folgenden Varianten möglich:
<Vergütung>:<Währung> - Vergütung als numerischer Wert und dessen Währung
<Reading>:<Währung> - Reading des Meter Device das die Vergütung enthält : Währung
<Device>:<Reading>:<Währung> - beliebiges Device und Reading welches die Vergütung enthält : Währung

Ihr könnt die V schon ausprobieren. Restart nach Download nicht vergessen.

Grüße,
Heiko

[kask]

Ich hab 5 Strings. Aber irgend wie ist da was richtig faul.
Ensemble habe ich disabled wegen den requests.

[kask]

Da scheint was mit dem Inverterdummy nicht zu passen..sind aber alles die selben Werte/Devices beim füttern.

Anbei die Devs der Forecasts..beides DWD. Einmal DWD-api einmal OpenMeteoDWD.
Übersehe ich da was?

EDit:

Code Auswählen Erweitern

?All => lastretrieval_time: 2024-04-05 09:50:13
                lastretrieval_timestamp: 1712303413
                response_message: success
                todayDoneAPIcalls: 95
                todayDoneAPIrequests: 9500

[DS_Starter]

Sieht mir so aus, als wäre dein FHEM mal abgestürzt und als es wieder startete war etotal des Inverterdummy zumindest für einen kurzen Moment mal 0. Danach wieder mit dem normalen Startwert. Dadurch kam es zu dem starken Sprung. Morgen nach der Mitternachtsbereinigung wird es wieder gut aussehen.

Bzgl. der todayDoneAPIrequests ... die Ensemble Calls haben ein Requestäquivalent von 20, d.h. ein Call führt 5 (Strings) x 20 Requests = 100 Requests aus. Ich rufe per default 4 x pro Stunde ab, macht bei dir 400 Requests pro Stunde. Nach 10 Stunden sind 4000 Requests verbraucht.
Das sind zwar noch keine 9600 wie in deinem Problem, nur zur Erläuterung. In der neuen Version werte ich diese Kennzahlen aus und passe bei Bedarf das API-Abrufintervall an... hätte nicht gedacht bei 10000 Requests darauf achten zu müssen. 
Die Zähler werden kurz nach Mitternacht zurückgesetzt. Aber nur wenn dein Device nicht disabled ist.Du solltest es also wieder enablen wenn du magst.

[kask]

Ja, Maschine ist heute nacht abgesemmlt. Grund konnte ich nicht finden.
Es wurde ein Restart ausgeführt und nach 17min war danach ende. Ich tippe auf einen hardware defekt.
Mal beobachten.

[DS_Starter]

Wenn es zu einer ungünstigen Zeit passierte, konnten vielleicht die Mitternachtsaktivitäten (diverse Zählerresets etc.) nicht ausgeführt werden und deswegen kamen die API-Requests bei dir in diese Regionen.

[kask]

Jepp, heute sieht es wieder normal aus.

Nur die History hat es mir (hoffentlich nicht so schlimm) versemmelt.

Code Auswählen Erweitern

Sieht mir so aus, als wäre dein FHEM mal abgestürzt und als es wieder startete war etotal des Inverterdummy zumindest für einen kurzen Moment mal 0Könntest du das nicht auf plausibilität prüfen? Sowas wie der Wert (Ist ja ein Totawert) kann nicht kleiner sein wie der vorherige?
Damit sowas nicht passieren kann.

[kask]

Mir ist auch aufgefallen das der etotal nicht angeglichen wurde. Also der "pvrl" wert wurde neu gesetzt mit den hohen Werten. Der "etotal" ist aber auf dem Stand vom letzten Monat.
Verwirrt mich etwas.

[DS_Starter]

Könntest du das nicht auf plausibilität prüfen? Sowas wie der Wert (Ist ja ein Totawert) kann nicht kleiner sein wie der vorherige?

Das passiert bereits.
Der Sachverhalt liegt etwas anders. Der Vorwert ist(könnte) 0 sein und der darauf folgende gemeldete Wert des etotal der WR ist sein wahres aktuelles etotal. Daraus ergibt sich evtl. eine große Differenz.
Das aktuelle etotal wird jede! Stunde initial gespeichert um daraus die Stundendifferenzen der Erzeugung ableiten zu können. (pvHistory -> Tag -> Stunde -> etotal: ...)
Ich überlege mal was man da evtl. machen kann. 0 muß jedenfalls auch als Meldewert erlaubt sein und mit einer festen Differenz kann man auch nicht arbeiten. Ein Rückblick auf die History geht auch nicht denn es könnte der WR/Dummy ja ausgetauscht sein und ganz andere Werte als in der History vorhanden melden.

Mir ist auch aufgefallen das der etotal nicht angeglichen wurde. Also der "pvrl" wert wurde neu gesetzt mit den hohen Werten. Der "etotal" ist aber auf dem Stand vom letzten Monat.
Verwirrt mich etwas.

Auch das wird eine Folge deines Crash sein. Die pvHistory ist ein Ringspeicher. Zu Beginn des Tages wenige Sekunden nach 00:00 wird der aktuelle Tag aus der History gelöscht, d.h. z.B. heute das Datum 06. Der bisherige Inhalt von 06 ist der Tag 06 des Vormonats.
Wenn die Nachtverarbeitung nicht laufen konnte, dann wurde der alte Tag 06 nicht gelöscht. 

[kask]

OK,Danke. Dann wird es klarer für mich.

[DS_Starter]

Ich habe evtl. eine Lösung für dieses Etotal-Schwellenwert Problem gefunden.
Morgen muss sich aber noch zeigen dass keine negativen Side-Effekte zu bemerken sind.
Das Ganze funktioniert nur wenn der Schlüssel capacity in currentInverterDev gesetzt ist.
Dieser Schlüssel ist bekanntermaßen optional.

Das Update liegt in meinem contrib.

LG,
Heiko

[DS_Starter]

Ich konnte bisher keine negativen Seiteeffekte der letzten Änderung erkennen.
Heute Abend schaue ich nochmal. Sollte nichts aufgetreten sein, übernehme ich die Änderung mit ins Repo.