76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[kask]

Man könnte ja bei Verdacht auch mal das device disablen.
Da es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.

Sicher das es kein HttpUtils Problem ist?
DNS ok? Serverdevice ethernet connection bescheiden oder gar via wifi angebunden?

Ich gehe davon aus das der server ansonsten nicht hängt?

[DS_Starter]

@TheTrumpeter, @all
ich habe die V 1.50.3 in mein contrib geladen.
Die Problematik der fehlenden Leistungsbegrenzung bei der Zuordnung von mehr als einem String auf einen Inverter sollte gelöst sein.

Bitte teste den Erfolg bei deiner Installation.
Weitere User sind natürlich auch eingeladen die V zu nutzen.

LG,
Heiko

[Gisbert]

Man könnte ja bei Verdacht auch mal das device disablen.
Da es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.

Sicher das es kein HttpUtils Problem ist?
DNS ok? Serverdevice ethernet connection bescheiden oder gar via wifi angebunden?

Ich gehe davon aus das der server ansonsten nicht hängt?

Sorry für den offtopic-Beitrag.
Ich hab jetzt alle Device, die mit pi-hole und SYSMON zu tun haben rausgeschmissen und Fhem neu gestartet. Das läuft ohne jetzt ohne Probleme. Damit ist klar, dass SolarForecast nicht der Verursacher ist, und ich bei pi-hole und SYSMON etc. weitersuchen muss.

Sicher das es kein HttpUtils Problem ist?

Dazu reichen meine Möglichkeiten nicht, um diese Frage zu beantworten.
DNS ist ok, die LAN-Anbindung ist unverdächtig, und der Server hat nicht viel zu tun.
Ich versuche das Problem weiter einzukreisen.

Viele Grüße Gisbert

[DS_Starter]

Da es aber auch viele HttpUtils aufgelistet sind und SF auch HttpUtils nutzt sehe ich so erst einmal dort das Problem.

Sicher das es kein HttpUtils Problem ist?

SF betreffend bin ich sicher. In dem Fall müssten andere Subs als Verursacher aufgelistet sein. Darüber hinaus nutzt SF nur das nicht blockierende HttpUtils_BlockingGet.
Die DNS Auflösung muß aber problemlos funktionieren. Die DNS Auflösung ist m.M. generell in FHEM blockierend, es sei denn man hat dnsServer im global Device gesetzt.

Für andere Module kann ich das natürlich nicht beurteilen.

[Gisbert]

Hallo Heiko,

ich hab folgendes in global definiert:

Code Auswählen Erweitern

dnsServer 1.1.1.1
Das funktioniert schon seit längerer Zeit (> 1 Jahr) so, vermutlich dürfte das nicht das Problem sein. Internetausfälle hab ich auch keine.

Viele Grüße Gisbert

[DS_Starter]

Naja, du fragst einen DNS Server im Inet ab. Ist der nicht zu erreichen, wird dein FHEM auch u.U. blockieren.
Ich habe einen lokalen DNS im eigenen Netz zugewiesen. Dieser holt externe Adressen auch von CloudFlare.
Also ich würde dir raten ebenfalls einen lokalen DNS anzugeben. Pi-Hole bietet sowas auch an.

Edit: Ich habe dir mal meine lokale DNS Architektur angehängt.

[kask]

Ähm pi-hole ist der "DNS-Server". Sonst funktioniert doch pi-hole nicht, das is doch die eigentliche Kernfunktion.
Vermutlich meinst du einen Resolver. Das kann aber meiner Meinung nach pi-hole nicht.
Und Pi-hole zu haben und dann einen anderen DNS server anzugeben ist auch "banane".

[DS_Starter]

Und Pi-hole zu haben und dann einen anderen DNS server anzugeben ist auch "banane".

Nein, das hat seinen Grund. So gut Pi-Hole auch ist, aber hat keine Master-Slave Funktion. Zumindest kenne ich keine. Deswegen gibt es bei mir mehre DNS-Server, wobei ich nur den Master pflegen muß. Deswegen ist es so wie es dargestellt ist.
Resolver ... jepp.

[kask]

Master-Slave (High Availability) ist schön für die Konfiguration da hast du vollkommen recht und mir ist da auch nichts bekannt bei pi-hole. Als DNS-Server aber so nicht wirklich nötig da man ja bestenfalls mehrere DNS-Server angibt um bei Ausfall eines und auch zum aufteilen beider (oder noch mehr) parallel nutzt.
Auch der pi-hole sollte mehr wie ein dns-server kontaktieren können.
Wenn dieser nicht geht dann funktioniert der oder die andere/n halt.
Und ein pi-hole macht schon Sinn da pi-hole nicht immer den Namen auflösen läst. Da wird auch gecached ausgegeben. Dann wird es auch schneller.
Zudem kommt das man ja eigentlich auch nicht möchte das ein Nameserver alle Anfragen bekommt. Der muss ja nicht alles wissen.

So jetzt genug off-topic.

[kask]

Ich hatte Vorgestern leider das debugging irgend wie falsch gesetzt.

Das debugging sagte nach dem der Fehler immer kam das wohl keine requests mehr gemacht werden. Sondern stur einfach die Meldung ausgegeben wird.

Code Auswählen Erweitern

2025.04.11 23:45:03 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:47:02 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:49:01 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:51:00 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:52:59 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.
2025.04.11 23:54:58 1: ForecastOpenMeteoEnsemble - ERROR - The limit of maximum 8000 daily API requests is reached or already exceeded. Process is exited.



Ich habe 5 Strings noch einmal zur Info.

Das nächste was mich stützig macht das Pro request 20 calls abgezählt werden. Warum ist das so?
Und wieso sind um 9:30 Morgens 3500 calls bereits geschehen bei einem Interval von ca. 16 minuten?

Code Auswählen Erweitern

025.04.12 00:00:04 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - the daily API requests -> limited to: 8000, done: 0
..
2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7980, Request equivalents p. call: 20, new call interval: 1081
..
..
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7900, Request equivalents p. call: 20, new call interval: 1092
..
..
..
2025.04.12 08:59:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4500, Request equivalents p. call: 20, new call interval: 1198
2025.04.12 09:16:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - the daily API requests -> limited to: 8000, done: 3500
..
2025.04.12 09:16:15 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4480, Request equivalents p. call: 20, new call interval: 1181
..
2025.04.12 09:16:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4460, Request equivalents p. call: 20, new call interval: 1186
..
2025.04.12 09:16:17 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4440, Request equivalents p. call: 20, new call interval: 1192
..
2025.04.12 09:16:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4420, Request equivalents p. call: 20, new call interval: 1197
..
2025.04.12 09:16:19 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 4400, Request equivalents p. call: 20, new call interval: 1202

Edit.:
 Ich habe mal alle Zeilen extrahiert. Bis jetzt gerade ist das alles im gleichen Intervall und nichts auffälliges.
Ich hänge mal die ersten 2,5h des Tages an um das hier nicht zu sprengen.

Code Auswählen Erweitern

2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7980, Request equivalents p. call: 20, new call interval: 1081
2025.04.12 00:00:06 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7960, Request equivalents p. call: 20, new call interval: 1084
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7940, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7920, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 00:00:07 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7900, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 00:16:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7880, Request equivalents p. call: 20, new call interval: 1082
2025.04.12 00:16:48 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7860, Request equivalents p. call: 20, new call interval: 1085
2025.04.12 00:16:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7840, Request equivalents p. call: 20, new call interval: 1088
2025.04.12 00:16:49 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7820, Request equivalents p. call: 20, new call interval: 1090
2025.04.12 00:16:50 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7800, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 00:32:39 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7780, Request equivalents p. call: 20, new call interval: 1084
2025.04.12 00:32:40 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7760, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 00:32:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7740, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 00:32:41 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7720, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 00:32:42 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7700, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 00:48:32 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7680, Request equivalents p. call: 20, new call interval: 1086
2025.04.12 00:48:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7660, Request equivalents p. call: 20, new call interval: 1088
2025.04.12 00:48:33 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7640, Request equivalents p. call: 20, new call interval: 1091
2025.04.12 00:48:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7620, Request equivalents p. call: 20, new call interval: 1094
2025.04.12 00:48:34 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7600, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 01:04:23 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7580, Request equivalents p. call: 20, new call interval: 1087
2025.04.12 01:04:24 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7560, Request equivalents p. call: 20, new call interval: 1090
2025.04.12 01:04:25 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7540, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 01:04:25 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7520, Request equivalents p. call: 20, new call interval: 1096
2025.04.12 01:04:26 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7500, Request equivalents p. call: 20, new call interval: 1099
2025.04.12 01:20:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7480, Request equivalents p. call: 20, new call interval: 1089
2025.04.12 01:20:16 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7460, Request equivalents p. call: 20, new call interval: 1092
2025.04.12 01:20:17 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7440, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 01:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7420, Request equivalents p. call: 20, new call interval: 1098
2025.04.12 01:20:18 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7400, Request equivalents p. call: 20, new call interval: 1101
2025.04.12 01:36:08 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7380, Request equivalents p. call: 20, new call interval: 1091
2025.04.12 01:36:09 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7360, Request equivalents p. call: 20, new call interval: 1094
2025.04.12 01:36:10 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7340, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 01:36:11 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7320, Request equivalents p. call: 20, new call interval: 1100
2025.04.12 01:36:12 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7300, Request equivalents p. call: 20, new call interval: 1103
2025.04.12 01:51:59 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7280, Request equivalents p. call: 20, new call interval: 1093
2025.04.12 01:52:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7260, Request equivalents p. call: 20, new call interval: 1096
2025.04.12 01:52:00 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7240, Request equivalents p. call: 20, new call interval: 1099
2025.04.12 01:52:01 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7220, Request equivalents p. call: 20, new call interval: 1102
2025.04.12 01:52:02 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7200, Request equivalents p. call: 20, new call interval: 1105
2025.04.12 02:07:51 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7180, Request equivalents p. call: 20, new call interval: 1095
2025.04.12 02:07:52 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7160, Request equivalents p. call: 20, new call interval: 1098
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7140, Request equivalents p. call: 20, new call interval: 1101
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7120, Request equivalents p. call: 20, new call interval: 1104
2025.04.12 02:07:53 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7100, Request equivalents p. call: 20, new call interval: 1107
2025.04.12 02:23:43 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7080, Request equivalents p. call: 20, new call interval: 1097
2025.04.12 02:23:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7060, Request equivalents p. call: 20, new call interval: 1100
2025.04.12 02:23:44 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7040, Request equivalents p. call: 20, new call interval: 1103
2025.04.12 02:23:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7020, Request equivalents p. call: 20, new call interval: 1106
2025.04.12 02:23:45 1: ForecastOpenMeteoEnsemble DEBUG> Open-Meteo API Call - remaining API Requests: 7000, Request equivalents p. call: 20, new call interval: 1109

[DS_Starter]

Morgen kask,

Das nächste was mich stützig macht das Pro request 20 calls abgezählt werden. Warum ist das so?

OpenMeteoEnsemble hat durch seine Funktionalität ein Requestäquivalent (nicht Calls) von 20 pro Request. Also ein Request an OpenMeteoEnsemble verbraucht 20 Requests des Tageslimit. Das sind bei 5 Strings 100 Credits pro Call. Das kann man auf der Open Meteo API Seite vergleichen.

Und wieso sind um 9:30 Morgens 3500 calls bereits geschehen bei einem Interval von ca. 16 minuten?

Request Equivalents nicht Calls. Siehe oben.

Aber ich denke die Bestimmung des Call Intervalls passt nicht 100%ig. Um 02:23:45 hast du nach 7000 Restequivalente. Bei 100 Verbrauch pro Call sind das 70 Calls. Das berechnete Intervall sind ca. 18 Minuten -> Sie würden demnach noch 70 x 18 / 60 = 21 Stunden (ca.) reichen. Das wäre rein rechnerisch bis kurz vor Mitternacht.
Beobachte es mal weiter.

[kask]

Calls, Requestäquivalent... Die Hauptsache ist das du weißt was ich meine. Was auch immer ein "Requestäquivalent" sein soll.

Selbst openai kennt den quatsch nicht.

Der Begriff ,,Requestäquivalent" ist kein standardisierter Begriff in der Informatik oder allgemeinen Fachsprache – es klingt so, als könnte er aus einem bestimmten Kontext stammen, z. B. Webentwicklung, Netzwerke, APIs oder vielleicht aus dem Bereich der Lasttests bzw. Systemauslastung.

Hier sind ein paar mögliche Interpretationen – je nach Zusammenhang:

blah, blah..blah

Ok, wie dem auch sei.

Wieso macht man Nachts den gleichen Interval? Da würde es doch rein technisch reichen wenn kurz vor Sonnenaufgang angefangen wird.
Es ist doch unerheblich wie die Vorhersage die 4h vorher variieren kann, ändert ja nichts an dem was gesagt wird wenn es wirklich los geht.
Oder habe ich da einen Denkfehler?

Ich beobachte weiter!
Wieso haben die anderen Openmeteo api's den Fehler nicht. Die Anzahl ist doch die selbe an Anfragen!

[DS_Starter]

Wieso macht man Nachts den gleichen Interval? Da würde es doch rein technisch reichen wenn kurz vor Sonnenaufgang angefangen wird.
Es ist doch unerheblich wie die Vorhersage die 4h vorher variieren kann, ändert ja nichts an dem was gesagt wird wenn es wirklich los geht.
Oder habe ich da einen Denkfehler?

Weil nicht nur Strahlungsdaten, sondern auch Wetterdaten geholt werden und wir froh sind eine Quelle zu haben die häufig aktualisiert.
Man kann natürlich Nachts weniger häufig aktualisieren. Soll ich deswegen noch mehr Logik einbauen die das auch noch berücksichtigt obwohl wir genügend Requests zur Verfügung haben? Lassen wir doch mal die Kirche im Dorf. Ich brauche hier vermutlich nur einen Sicherheitsaufschlag in das berechnete Intervall einzubauen. Das schaue ich mir nachher mal an.

Wieso haben die anderen Openmeteo api's den Fehler nicht. Die Anzahl ist doch die selbe an Anfragen!

Sorry, ich habe es versucht zu erläutern. Mehr Nerven habe ich jetzt nicht dazu. Wenn du dich intensiver einlesen willst, schau dir die API von OpenMeteo an.

LG

[DS_Starter]

Hallo kask,

ich habe in der Intervallfindung einen Puffer in das Coding eingebaut um die Intervallberechnung für OpenMeteo resilienter zu gestalten.
Die V 1.50.3 in meinem contrib ist upgedated. Lade sie dir bitte in dein System und poste dann wieder die Debug Ausgaben wie gehabt. Das "new call interval" sollte sich nun etwas erhöhen und rein rechnerisch bis nach Mitternacht ausreichen.

LG,
Heiko

[DS_Starter]

@all,

hier habe ich für einen besseren Überblick die Weiterentwicklungen der Versionen 1.50.1 - 1.50.3 zusammengefasst:

- Der Setter pvCorrectionFactor_Auto hat nun die auswählbare Option "on_complex_api_ai". "on_complex_ai"
  verwendet die API-Ergebnisse wobei bei einem KI Hit die KI Ergebnisse verwendet werden.
  Es ist allerdings nicht unbedingt gesagt, dass KI immer der bessere Wert ist. Diese neue Option verwendet
  sowohl den API und KI-Wert und bildet aus beiden Treffern den Durchschnitt als effektive Vorhersage.

- die Kapazität des Wechselrichters begrenzt die Leistung der Strings auch wenn keine explizite Zuordnung durch "strings=..." vorhanden ist.
  Es betrifft dann alle Strings, da ohne Zuordnung alle definierten Strings dem WR automatisch zugeordnet werden.

- das Attr ctrlSpecialReadings enthält die Option "tomorrowConsumptionForecast" um die stündliche Verbrauchsvorhersage für den kommenden Tag
  als Reading darzustellen

- im Anlagencheck wird die aktuell verwendete Modulversion im Header ausgegeben

- Behebung der fehlenden Begrenzung für Strings, wenn mehr als ein String einem Wechselrichter zugewiesen ist

- verbesserte Call Intervallberechnung im MODEL OpenMeteoDWDEnsembleAPI

- verbesserte String Prüfung im Anlagencheck

- kleinere Änderungen im Code und CommandRef

Wer noch nicht mindestens auf V1.50.0 ist, sollte am WE auf die V1.50.3 updaten die ich soeben eingecheckt habe.
Kommende Woche wird das Major Release 1.51.0 erscheinen in dem alle inzwischen obsolet gewordenen Attribute entfernt werden. Deshalb wäre es vorteilhaft vorher die automatische Umstellung vorgenommen zu haben.

LG,
Heiko