wichtiges UPDATE für controller 7.2.2 im stable

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

[ticaki]

Claude meint jetzt das du nicht die richtige version installiert hast du hast gelb geschrieben was falsch ist, 0.11 würde grün anzeigen, was auch falsch ist :D ... da hängt er sich jetzt aber richtig dran auf. Ich guckmal das ein update kommt.

❯ ja aber wenn 11 so oder so falsch ist, ist es dann nciht irrelevant?                                                                                                                                         

● Ja, völlig richtig — egal ob „gelb" oder „grün", 204 153 255 ist auf 0.11.0 so oder so falsch klassifiziert. Die gelb/grün-Frage ändert nichts am Fix. Ich wende ihn an.

[ticaki]

update ist am laufen 10 Minuten dann ist es wohl auf npm

[Nashra]

Gerade über npm 0.11.1 installiert. Jetzt sagt Alexa violett aber bei beiden, obwohl hellviolett und einmal dunkel

[ticaki]

habs mir jetzt mal genau angeguckt - und wie immer wenn man das fußvolk was machen lässt, fangen die an Schrauben mit dem hammer einzuschrauben...

Der macht da per hand r ist größer als b kleiner als das muß xyz sein...

[ticaki]

Update soll jetzt da sein - farben sind die offiziellen bezeichnungen

[Nashra]

@ticaki sagte:

Update soll jetzt da sein - farben sind die offiziellen bezeichnungen

Gerade die 0.11.2 installiert und tada hellviolett und violett
aber einen habe ich noch...wenn die Ansage kommt, sagt Alexa die Lautstärke an
die im Adapter eingetragen ist
Also so: 40 Amtlich Warnung vor Hitze usw.

[ticaki]

Ja das ist mir bei was anderem auch aufgefallen - das gucke ich mir mal an - da muß ich aber selbst gucken wieso - claude konnte das bei was anderem nicht lösen und ich hatte da kein bock und hab sonos genommen :D