Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[Thomas Braun]

@pk68 sagte:

Ist das vielleicht bei mir ein Einstellungsproblem?

Möglich, dass bei dir die USA als Datumsformat irgendwo hinterlegt sind.
Auf einem Linux:

locale 

anschauen.

[pk68]

@Thomas-Braun
Das komische ist, dass dies nicht alle Timestamps betrifft. Bei anderen Adaptern wie z.B. DasWetter habe ich die Probleme auch nicht.

pi@raspi4-sh:~ $ locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
pi@raspi4-sh:~ $

Hier die Konfig:

[H5N1]

@pk68 sagte:

Bei anderen Adaptern wie z.B. DasWetter habe ich die Probleme auch nicht.

Danke für die Info, das schaue ich mir an. Ich denke das ist ein Bug vom Adapter, ich glaube auch zu wissen woran es liegt, er holt das Datum als Text ab und durch die Rolle als Date wandelt er es um und schreibt es als 6. Oktober statt 10. Juni.

Werde ich mir die Tage anschauen und fixen.

[H5N1]

Neue Test Version 3.1.1.

Datum/Zeit Problem gefixt

Changelog:

• fix: info.lastUpdate_weather, info.lastUpdate_PV_Forecast und hourly.next_hours.hour*.date speichern nun einen Unix-Zeitstempel (value.time) anstelle einer formatierten Zeichenkette, um eine fehlerhafte Datumsanalyse durch ioBroker zu verhindern.
• Abhängigkeiten aktualisiert
• fix: [W5612] Nicht verwendete Konfigurationen für benutzerdefinierte Aktionen aus jsonConfig entfernt.
• fix : [W5063] Die JSON-Formatierung in "admin/jsonConfig.json" ist schwer lesbar (gemischte Einrückung).
• fix: Typzusicherung für Kanalnamen korrigieren
• Einige Fehler in der README.md-Datei behoben",

TO-DO und Änderungen: open-meteo-weather

[pk68]

@H5N1
Danke für's schnelle fixen. Die Timestamps zeigen nun die richtigen Werte an.

[H5N1]

Neue Test Version 3.1.2 3.1.3

--

Edit:

Leider hatte ich mit dem ersten Fix einen ungewollten weiteren BUG eingebaut durch eine Massenersetzung im Editor, dadurch wurden einige Datenpunkte wie z.B. die json Charts nicht mehr erstellt, es betraf die DP für PV-Forecast . Diesen habe ich behoben. Ganz großes SORRY.

--

mit dem neuesten Update habe ich ein Problem behoben, das vor allem bei Bestandsinstallationen nach Updates des Adapters vereinzelt zu Fehlern im Log führen konnte.

Das Problem

Wenn sich in einer neuen Version des Adapters der Datentyp (z. B. von String zu Number beim .date-Datenpunkt) oder die zugewiesene Rolle eines Datenpunkts geändert hat, bekamen das bestehende Installationen oft nicht mit.

Sobald der Adapter dann versucht hat, den neuen Datentyp (z. B. eine Zahl) in den alten Datenpunkt (der noch als Text definiert war) zu schreiben, hat ioBroker im Log berechtigt gemeckert (Typ-Mismatch).

BUG (GitHub)

Changelog 3.1.3:

• Problem bei der Objekterstellung behoben. Durch versehentliche änderung.

Changelog 3.1.2:

• (mcuiobroker) fix: Nach einem Adapter-Update werden Typ und Rolle automatisch angepasst, falls sie in neueren Versionen geändert wurden.
• Abhängigkeiten aktualisiert

TO-DO und Änderungen: open-meteo-weather

[oFbEQnpoLKKl6mbY5e13]

@H5N1

Ich habe noch die 3.1.2 installiert und erhalte hier noch die folgende Meldung:

State value to set for "open-meteo-weather.0.Haus.weather.forecast.day14.precipitation_probability_max" has to be type "string" but received type "number"

[H5N1]

@ofbeqnpolkkl6mby5e13
Ist es bei dir nur der eine Datenpunkt? Komisch, da ich daran gar nicht gearbeitet oder etwas geändert habe.

Ich hatte jetzt zum Testen bei mir einen DP (precipitation_probability_max) manuell auf string geändert. Nach einem Neustart vom Adapter korrigiert es das ordentlich.
logauszug:

info	[Weather] extendOrCreateState: Fixing type mismatch for Home.weather.forecast.day6.precipitation_probability_max (changing from string to number)

Das muss ich nun beobachten.

Edit:
Frage:
Bist du dir sicher das du die Version 3.1.2 meinst und nicht 3.1.1 die noch installiert ist?

[oFbEQnpoLKKl6mbY5e13]

@H5N1

Ja, das ist nach der Installation von 3.1.2 der einzige noch verbliebene Datenpunkt mit der Meldung.

[H5N1]

@ofbeqnpolkkl6mby5e13
Update bitte mal auf die 3.1.3
Was mich irritiert ist das es nur Tag 14 betrifft, da in den anderen Tagen davor bzw danach es dasselbe sein müsste. 🤔

[oFbEQnpoLKKl6mbY5e13]

@H5N1

info starting. Version 3.1.3 in /opt/iobroker/node_modules/iobroker.open-meteo-weather, node: v22.23.0, js-controller: 7.2.2
[Weather] extendOrCreateState: Fixing type mismatch for Haus.weather.forecast.day14.precipitation_probability_max (changing from string to number)

[H5N1]

@ofbeqnpolkkl6mby5e13
Top und danke für dein mitwirken.

[Peguschwein]

Hallo habe den Adapter vor ein paar Tagen installiert. Verwendet jemand PV forecast ? wie genau ist bei euch die Berechnung zum offizienne Ertrag ?
Habe Dachneigung, kwp, und azimut eingetragen. z.B heute 78 kwh berechnet 64.6 Produziert das sind ca 20% Abweichung. Wird da die Paneltemperatunr bei der Berechnung berücksichtigt ?

[H5N1]

@peguschwein
Die ungefähre Paneltemperatur wird im Adapter berechnet, die Daten zur Berechnung der Erträge kommen von Open Meteo selbst, ob das von den Daten dort berücksichtigt wird oder ob eine durchschnittliche Temperatur dafür benutzt wird weiss ich nicht, eine Berechnung vom Adapter aus findet nicht statt. Lediglich die ungefähren Paneltemperaturen berechnet der Adapter anhand von Sonne, Temperatur und Wind, was aber meist nicht auf die Minute genau wird. Um es wirklich genau zu machen bräuchte man die realen Temperaturen der Panels anhand von sensoren, man hat dann aber trotzdem keine Temperaturen für die Zukunft. Evtl. kann man aber aus den vorhandenen Daten ein extra Script schreiben was dann unter berücksichtigung der Temperaturen den Ertrag berechnet. Wobei ich davon ausgehe das daraus dann auch keine Punktlandungen werden.

Edit: Bedenke falls es so ist auch evtl. drosselungen deiner PV-Anlage durch den Netzbetreiber.

[pk68]

@H5N1

Hallo, mir ist eine kleine Unstimmigkeit aufgefallen. Heute schlug die Aktualisierung der Daten fehl.

open-meteo-weather.0
	2026-07-17 05:00:06.391	error	[Kueche] Error: PV API request failed: Request failed with status code 503 – Open-Meteo reason: "The service is overloaded"
open-meteo-weather.0
	2026-07-17 05:00:06.370	error	[Kueche] Open-Meteo Server error (503) – the service may be temporarily unavailable. – Open-Meteo reason: "The service is overloaded"

Gegen um 8 Uhr klappte die Abfrage wohl. Das sehe ich bei mir im Log nicht, da der Adapter auf Level Warn läuft. Aber die Zeitstempel der Wetter-Datenpunkte wurden gegen 8:03 Uhr aktualisiert.
Allerdings sind die Daten der PV-Datenpunkte noch von gestern. Wurden also nicht aktualisiert.

Der Datenpunkt lastUpdate_PV_Forecast im Info-Bereich hat einen Timestamp von heute 5 Uhr.

Vielleicht sollte man die Datenpunkte im Info-Bereich nur dann aktualisieren, wenn das Update erfolgreich war? Kann man die Aktualisierung der PV Daten im Fehlerfall, wie bei den Wetterdaten, wiederholen?

[H5N1]

@pk68
Das muss ich mir bei Gelegenheit anschauen, um zu wiederholen könntest du den Adapter neu starten und schauen ob er aktualisiert.

[pk68]

@H5N1 sagte:

@pk68
den Adapter neu starten und schauen ob er aktualisiert.

Ja, nach einem Neustart wird alles (Wetter + PV) aktualisiert.

[Peguschwein]

@H5N1 Danke für deine Infos. Neîn zur Zeit habe ich noch keine Drosselung durch den Netzbetreiber. dieser entgegne ich mit Peak Shaving. Speicher wird erst bei 68% Export geladen. Dafür wäre der PV Forcast noch gut nicht das es drosselt wenn es kaum Ertrag gibt.

[H5N1]

@pk68 Problem habe ich gefunden woran es liegt, werde ich beheben sobald ich Zeit habe. Danke für die Infos.

@peguschwein
Probiere doch einfach mal was rauskommt wenn du ein Script anfertigst mit den vorhersagen der Plattentemperaturen in Verbindung mit dem Wirkungsgrad deiner Platten, würde mich auch mal interessieren ob es das genauer macht.
Evtl. kann man es bei besseren vorhersagen als extra zum aktivieren mit einfügen, das müsste dann aber länger getestet werden.

[H5N1]

Neue Test Version 3.1.4.

Das durch @pk68 entdeckte Problem, das lastUpdate_PV_Forecast den Timestamp setzt ohne zu prüfen ob Daten gekommen sind oder die Server erreichbar waren, sollte behoben sein.

Ein weiteres Problem war, wer den Abruf der PV-Daten auf "Einmal vor Sonnenaufgang" eingestellt hat und die Open-Meteo Server gerade nicht erreichbar oder überlastet waren, bekam dann keine neuen Daten. Sollte jetzt ein Fehler beim Abruf der Daten auftreten und "Einmal vor Sonnenaufgang" eingestellt sein, versucht der Adapter jetzt alle 30 Minuten die Daten zu bekommen bis er sie hat, erst dann wird lastUpdate_PV_Forecast aktualisiert und die Zeit für den nächsten Abruf auf vor Sonnenaufgang gestellt.
Das betraf auch nur den PV-Forecast Bereich der Wetterbereich ist soweit Safe.

Changelog:

• (@GermanBluefox) Logo hochskaliert
• (@GermanBluefox) TS auf Version 6 aktualisiert
• (@GermanBluefox) Bild in JsonConfig korrigiert
• (H5N1v2) Logo-Größe auf 512x512 angepasst
• (pk68) fix: info.lastUpdate_PV_Forecast wird nicht mehr aktualisiert, wenn alle API-Aufrufe fehlgeschlagen sind oder keine Daten zurückgeliefert haben.
• (H5N1v2) fix: Der „Sonnenaufgangs-Modus“ der PV-Prognose versucht nun automatisch nach 30 Minuten einen erneuten Abruf, falls der API-Aufruf fehlschlägt (z. B. HTTP 500 bei Überlastung). Der Zeitplan für den nächsten Tag wird erst nach einer erfolgreichen Aktualisierung erstellt.
• (H5N1v2) Status-Link zu open-meteo in der Adapterbeschreibung und der README hinzugefügt.
• (H5N1v2) fix: OpenStreetMap-Link im Admin-Bereich anklickbar gemacht.
• (H5N1v2) Abhängigkeit aktualisiert.

TO-DO und Änderungen: open-meteo-weather