wichtiges UPDATE für controller 7.2.2 im stable

[H5N1]

@mcm1957
der von dir verlinkte Adapter ist nicht von mir. Bitte noch mal nachprüfen.

EDIT:
Dieser ist mein Adapter:
https://github.com/ioBroker/ioBroker.repositories/pull/5732 für Stable
https://github.com/ioBroker/ioBroker.repositories/pull/5552 für latest

@homoran

[wendy2702]

Merkwürdig,

Bei mir ist der Ordner nicht vorhanden oder nicht sichtbar. Nicht nach Upload, nicht nach downgrade auf die letzte Stable Version.

EDIT: Auch nach einem Upload all wird mir der Ordner nicht angezeigt. Morgen mal auf Ursachen Forschung gehen

[mcm1957]

@H5N1 sagte:

@mcm1957
der von dir verlinkte Adapter ist nicht von mir. Bitte noch mal nachprüfen.

EDIT:
Dieser ist mein Adapter:
https://github.com/ioBroker/ioBroker.repositories/pull/5732 für Stable
https://github.com/ioBroker/ioBroker.repositories/pull/5552 für latest

@homoran

SORRY für den Fehler.

[H5N1]

Neue Test Version 3.0.1.

Ein paar Optimierungen und einen Bug beim Intervall Abruf für "einmal vor Sonnenaufgang" behoben, Abhängigkeiten aktualisiert.

Changelog:
open-meteo-weather

Danke an alle fürs Testen.

[H5N1]

Neue Test Version 3.1.0.

Trotz des schönen Wetters, habe ich Zeit gefunden wieder ein bisschen am Wetter zu arbeiten :-)

Übersicht der Wichtigsten Änderungen:

Mit der neuen Version ist es nun möglich das, dass Widget ohne Umwege im Admin erstellt werden kann.
Es kann direkt in der Standort-Tabelle aktiviert/Deaktiviert werden und liegt dann unter "open-meteo-weather.0.STANDORT.weather.htmlWidget". Die Einstellungen habe ich absolut Basic gelassen und beschränken sich auf die Schriftgröße, Vorhersage Tage und Stunden. Wer es weiter Personalisieren möchte benutzt das externe HTMLWidget weiter.
Zurzeit nur im Adapter Widget werden jetzt Gefahren farblich dargestellt z. B. Gewitter, starker Regen usw. wenn ich Zeit finde werde ich das auch im externen Widget auf GitHub einfügen.

Des Weiteren habe ich die Update-Routine angepasst, es wird jetzt je nach Einstellung immer kurz nach der vollen, viertel oder halben Stunde abgerufen. Vorher war es so das nach einem Adapter Neustart z.b. um 11:40 Uhr und Intervall 60 Minuten erst wieder um 12:40 Uhr abgerufen wird, das ergab meiner Meinung nach keinen Sinn, wenn man die Daten der aktuellen Stunde möchte.

Changelog:

• Die Update-Routine für Wetter- und PV-Prognosen wurde auf feste Abrufzeiten umgestellt.
• Ein anpassbares HTML-Wetter-Widget im Admin-Bereich wurde hinzugefügt.
• Anpassung für Versionssprünge von älteren Konfigurationen.
• Internes Adapter-Widget angepasst, Gefahren werden farblich hervorgehoben (derzeit nur im internen Adapter-Widget).
• Der Adapter benötigt nun node.js >= 22.
• Update von axios auf v.1.16.0.

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

EDIT 09.05.2026: Auch die externen Widget Scripte auf GitHub habe ich nun mit den farblichen Wetter Events angepasst. Zusätzlich habe ich eine Prüfung eingebaut die Anzeigt ob es neue Versionen auf GitHub gibt.

Danke an alle fürs Testen.

[H5N1]

Info

Aktuell gibt es mit der free API von Open Meteo Probleme und ist down.

Open Meteo Status

Dazugehöriges GitHub issues

[pk68]

@H5N1

Hallo, habe deinen Apadter gestern installiert. Danke für deine Mühe.
Bei mir stimmen einige Datumswerte nicht. Sieht so aus, als würde Tag und Monat vertauscht. Heute ist der 10. Juni und nicht der 6. Oktober.
Dies betrifft die stündlichen Daten bei der Wettervorhersage bzw. die Timesstamps im Infobereich.

Die Timesstamps der stündlichen Daten der PV-Vorhersage sind wiederum korrekt.

Bei Screenshots von anderen Usern hier im Thread waren die Timesstamps korrekt. Ist das vielleicht bei mir ein Einstellungsproblem?
Ich hatte auch schon mal den Adapter gestoppt, alle Datenpunkte gelöscht und wieder neu gestartet.

[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