wichtiges UPDATE für controller 7.2.2 im stable

[ticaki]

@sigi234
Ist soweit ich das sehe ein Schemafehler - im Adapter selber ist alles lt. Dokumentation.

[Nashra]

Vorhin kam eine Warnung rein...

Alexa sagt mir diese zwar an aber mit kleinem Fehler
"Es tritt leichter Frost zwischen 0 °C und 4 °C auf"
das es Minus 4 sind wird nicht gesagt.

[ticaki]

Bekanntes Alexa Problem, https://forum.iobroker.net/topic/81629/alexa-2-speak-kann-keine-negativen-temperaturen-mehr/64

[deta]

Hallo,
kann es sein, das der Adapter die Sommerzeit misachtet.
Alexa bringt immer die Meldung um eine Stunde nach hinten.
Also Sturm 18:15 gemeint ist aber 19:15

Wie kann ich das Problem beheben?

cu Deta

[ticaki]

ich gucks mir mal beim nächsten unwetter an - war eigentlich nicht so, kann sich aber immer ein rechenfehler einschleichen.

[DasBo1975]

@ticaki sagte:

ich gucks mir mal beim nächsten unwetter an - war eigentlich nicht so, kann sich aber immer ein rechenfehler einschleichen.

Tatsächlich habe ich das mit der "falschen" Uhrzeit aber auch. Vorhin mal drauf geachtet. um 21:33 Uhr wurde ich benachrichtigt, dass um 21:27 Uhr ein starkes Gewitter kommt.

[deta]

@DasBo1975

[ticaki]

Claude meint nachdem wir das hier durch getestet haben, das die Zeitberechnung nur dann kippt, wenn der Host auf der falschen Zeitzone steht.

@dasbo1975 Bei einer kurzfristigen Warnung - also 19:30 wird veröffentlicht das es ab 19:30 ein starkes Gewitter geben kann. Sieht es aus als wenn der Adapter die Zeit falsch berechnet vorallem wenn der Intervall erst um 19:42 die Warnung aktualisiert.

[DasBo1975]

@ticaki sagte:

@dasbo1975 Bei einer kurzfristigen Warnung - also 19:30 wird veröffentlicht das es ab 19:30 ein starkes Gewitter geben kann. Sieht es aus als wenn der Adapter die Zeit falsch berechnet vorallem wenn der Intervall erst um 19:42 die Warnung aktualisiert.

Ahh, ok. Danke fürs Überprüfen.

[deta]

@ticaki Ich habe auf meinen Servern alles geprüft und die richtige Zeit wird auch bei date angezeigt.
Zeitzone ist richtig.
Ich vermute es liegt an den Wechsel der Winter/Sommerzeit. Das hier im Adapter nur die Winterzeit genommen wird.

cu Deta

[ticaki]

Danke für die Rückmeldung ich gucke nochmal rein und dieses Mal mit Zeitzone auf dem Rechner stimmt. Ich eine linux Installation?

[deta]

@ticaki Ja iobroker läüft unter Linux. Und Alexa sagt ca. 1 Stunde es falsch an.

[ticaki]

claude will hier rauf ne antwort:

@deta Danke fürs Prüfen. Wichtig ist hier die Unterscheidung: dass date in der Shell die richtige Zeit zeigt, sagt leider noch nichts darüber aus, welche Zeitzone der Node-Prozess von ioBroker verwendet.
Der Adapter liest den UTC-Offset nämlich direkt aus dem laufenden Prozess (new Date().getTimezoneOffset()), und genau der kann „auf Winterzeit festhängen", obwohl die Shell korrekt ist — z. B. durch ein
gesetztes TZ=Etc/GMT-1, fehlendes/veraltetes tzdata-Paket oder eine abweichende Container-Zeitzone.

Kannst du mir bitte folgendes ausgeben lassen — am besten direkt im JavaScript-Adapter (dort läuft dieselbe Node-Umgebung wie der Adapter):

log('Offset: ' + new Date().getTimezoneOffset() + ' | Zone: ' + Intl.DateTimeFormat().resolvedOptions().timeZone);

Erwartung im Sommer (CEST): Offset: -120 und Zone: Europe/Berlin.
Wenn dort -60 steht oder als Zone etwas wie Etc/GMT-1 / UTC auftaucht, ist das die Ursache: der Adapter rechnet dann tatsächlich dauerhaft mit Winterzeit-Offset.

Alternativ auf der Konsole als der User, unter dem ioBroker läuft:

  node -e "console.log(new Date().getTimezoneOffset(), Intl.DateTimeFormat().resolvedOptions().timeZone)"

Sag mir, was rauskommt — dann wissen wir sicher, ob es an der Prozess-Zeitzone liegt. Unabhängig davon habe ich ohnehin vor, die Offset-Berechnung robuster zu machen, damit sie nicht mehr von der Host-Zeitzone abhängt.

---

Wohl gemerkt ich wurde nicht gefragt ob ich die robuster will * hust *

[deta]

@ticaki sagte:

node -e "console.log(new Date().getTimezoneOffset(), Intl.DateTimeFormat().resolvedOptions().timeZone)"

node -e "console.log(new Date().getTimezoneOffset(), Intl.DateTimeFormat().resolvedOptions().timeZone)"
-120 Europe/Berlin

[ticaki]

das übersteigt wohl claude - will dich jetzt fragen ob du den Fehler noch immer hast und natürlich das ganze robuster machen, was nix ändern aber robuster ist. Ich muß da am we selbst suchen.

aber lass mich noch was abchecken:

Kein Container
Kein Master-Slave system?

Im javascript adapter kommt dabei auch die richtige zeit raus?

[deta]

@ticaki sagte:

Kein Container
Kein Master-Slave system?

Nein, weder noch, reines Debian Linux.

Und ja der Fehler ist immer noch. Erst gestern wieder, Warnung, Gewitter um 18:54, dabei war es schon kurz nach 19 Uhr und das Gewitter war so gegem 19 :50 da.
Zeit ist ja immer so +-

cu Deta

[ticaki]

bitte beim nächsten Ereignis bitte die werte von

Beispielpfad: weatherwarnings.0.provider.dwd.812073000.warning.00.raw.ONSET

hier posten und was gesagt wurde

[Nashra]

Moin, leider immer noch falsche Ansagen bei Hitze Warnung
Bei Stufe 1 sagt Alexa gelb
Bei Stufe 3 sagt sie rot

[ticaki]

Claude meint dazu:
Hi Ralf,

um das sauber einzugrenzen, brauche ich bei der nächsten Hitzewarnung ein paar Werte direkt aus den Datenpunkten — magst du die posten?

1. Adapter-Version (Instanzen → weather-warnings → Version), damit ich weiß, ob der #220-Fix (ab 0.11.0) bei dir schon aktiv ist.
2. Aus dem aktiven Warn-Datenpunkt unter weatherwarnings.0.provider.dwd.<warncell>.warning.00.raw.:
   - SEVERITY
   - EC_AREA_COLOR
   - EC_II
3. Was Alexa wörtlich sagt vs. was VIS/E-Mail farblich anzeigen für dieselbe Warnung.
4. Wenn möglich: welchen Token deine Sprach-Vorlage für die Farbe nutzt (${warnlevelcolorname} oder etwas anderes).

Damit kann ich genau sehen, ob die gesprochene Stufe und die echte DWD-Warnfarbe auseinanderlaufen. Danke fürs Dranbleiben!

[Nashra]

@ticaki sagte:

Claude meint dazu:
Hi Ralf,

um das sauber einzugrenzen, brauche ich bei der nächsten Hitzewarnung ein paar Werte direkt aus den Datenpunkten — magst du die posten?

1. Adapter-Version (Instanzen → weather-warnings → Version), damit ich weiß, ob der #220-Fix (ab 0.11.0) bei dir schon aktiv ist.

v0.10.1

2. Aus dem aktiven Warn-Datenpunkt unter weatherwarnings.0.provider.dwd.<warncell>.warning.00.raw.:
   - SEVERITY

Minor

- EC_AREA_COLOR

204 153 255

- EC_II

247

3. Was Alexa wörtlich sagt vs. was VIS/E-Mail farblich anzeigen für dieselbe Warnung.

sagt wörtlich gelb bei Stufe 1 und rot bei Stufe 3, siehe Bild oben
in der eMail sind auch die Farben wie im obigen Bild

4. Wenn möglich: welchen Token deine Sprach-Vorlage für die Farbe nutzt (${warnlevelcolorname} oder etwas anderes).
   sieht so aus
   

neue Version 0.11.0 im Beta oder über github zu bekommen?