wichtiges UPDATE für controller 7.2.2 im stable

[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

[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.