Sommer/Winterzeit - Umstellung wirkt sich auf Objekteerstellung aus

[ralpha1983]

Hallo, seit Sonntag, 27.03.2022 werden die Objekte nicht mehr aktualisiert. Alle Forcast unter "day" haben das selbe Datum. Ist etwas dahingehend bekannt? Vielen Dank

[baerengraben]

Hi @ralpha1983

Aufgefallen ist mir bis jetzt nichts. Habe es aber jetzt noch genau geprüft. Die Forecasts

• forecast/60minutes
• forecast/current_hour
• forecast/day

sind bei mir korrekt.

Aber nach forecast/hour/dayx/xxxx/local_date_time werden tatsächlich sonderbare Daten abgefüllt:

0100/local_date_time = 2022-03-27T01:00:00+01:00 0200/local_date_time = 2022-04-05T02:00:00+02:00 <--- 0400/local_date_time = 2022-03-26T04:00:00+01:00 0500/local_date_time = 2022-04-05T05:00:00+02:00 <-- 0700/local_date_time = 2022-03-26T07:00:00+01:00 0800/local_date_time = 2022-04-05T08:00:00+02:00 <-- 1000/local_date_time = 2022-03-26T10:00:00+01:00 1100/local_date_time = 2022-04-05T11:00:00+02:00 <-- 1300/local_date_time = 2022-03-26T13:00:00+01:00 1400/local_date_time = 2022-04-05T14:00:00+02:00 <-- 1600/local_date_time = 2022-03-26T16:00:00+01:00 1700/local_date_time = 2022-04-05T17:00:00+02:00 <-- 1900/local_date_time = 2022-03-26T19:00:00+01:00 2000/local_date_time = 2022-04-05T20:00:00+02:00 <-- 2200/local_date_time = 2022-03-26T22:00:00+01:00 2300/local_date_time = 2022-04-05T23:00:00+02:00 <--

Eigentlich dürften hier nur 3-Stunden intervalle aufgelistet sein (Pfeile). Die anderen Werte gehören da eigentlich nicht rein.

Mache bitte mal folgendes:

• Stoppe Adapter
• Lösche alle Objekte unter swiss-weather-api/0
• Starte Adapter neu

Nun sollten die Werte wieder korrekt sein.

Kannst du das mal ausführen und prüfen ob die Werte wieder ok sind?

[ralpha1983]

Hallo

Ich habe am Adapter selber nichts geupdatet. Bin auf der Version 1.0.3.

Ich denke, dass dies seit der Sommerzeit-Umstellung auftritt. Was mir auffällt, das z.B. bei forecast/day/day0 ein Ordner 2200 und 2300 existiert.

Bei 2200 ist das Datum korrekt, bei 2300 blieb es auf 27.03.2022 stehen. Somit denke ich, dass im Sommerhalbjahr die Daten in 2200 abgefüllt und im Winterhalbjahr die Daten in 2300 abgefüllt werden.

Freundliche Grüsse

Ralph Ammann

Von: baerengraben @.> Gesendet: Dienstag, 5. April 2022 21:10 An: baerengraben/ioBroker.swiss-weather-api @.> Cc: ralpha1983 @.>; Mention @.> Betreff: Re: [baerengraben/ioBroker.swiss-weather-api] Seit 27.03.2022 werden die Objekte nicht mehr aktualisiert (Issue #78)

Hi @ralpha1983 https://github.com/ralpha1983

Aufgefallen ist mir bis jetzt nichts. Habe es aber jetzt noch genau geprüft. Die Forecasts

• forecast/60minutes
• forecast/current_hour
• forecast/day

sind bei mir korrekt.

Aber nach forecast/hour/dayx/xxxx/local_date_time werden tatsächlich sonderbare Daten abgefüllt:

0100/local_date_time = 2022-03-27T01:00:00+01:00 0200/local_date_time = 2022-04-05T02:00:00+02:00 0400/local_date_time = 2022-03-26T04:00:00+01:00 0500/local_date_time = 2022-04-05T05:00:00+02:00 0700/local_date_time = 2022-03-26T07:00:00+01:00 0800/local_date_time = 2022-04-05T08:00:00+02:00 1000/local_date_time = 2022-03-26T10:00:00+01:00 1100/local_date_time = 2022-04-05T11:00:00+02:00 1300/local_date_time = 2022-03-26T13:00:00+01:00 1400/local_date_time = 2022-04-05T14:00:00+02:00 1600/local_date_time = 2022-03-26T16:00:00+01:00 1700/local_date_time = 2022-04-05T17:00:00+02:00 1900/local_date_time = 2022-03-26T19:00:00+01:00 2000/local_date_time = 2022-04-05T20:00:00+02:00 2200/local_date_time = 2022-03-26T22:00:00+01:00 2300/local_date_time = 2022-04-05T23:00:00+02:00

Kann es sein, dass du am Sonntag den Adapter auf eine neue Version aktualisiert hast?

— Reply to this email directly, view it on GitHub https://github.com/baerengraben/ioBroker.swiss-weather-api/issues/78#issuecomment-1089209244 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AULT3PNKM2WIGTMOXEMNSEDVDSFZJANCNFSM5SQPVZEQ . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AULT3PLANHAI5KEC6XWRX63VDSFZJA5CNFSM5SQPVZE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIDWAHHA.gif Message ID: @. @.> >

[baerengraben]

Das kann tatsächlich sein. In diesem Falle wäre das naütrlich ein Bug. Ich werde dem noch weiter nachgehen.

Fix für die Zwischenzeit:

• Stoppe Adapter
• Lösche alle Objekte unter swiss-weather-api/0
• Starte Adapter neu

[baerengraben]

Neu kann die Zeitzone im SRF-Developer Portal gesetzt werden (unter Profile):

Mal schauen ob damit das Problem bei der nächsten Zeitumstellung gelöst ist.

[baerengraben]

Die Sommerzeit hat Einzug gehalten. Leider besteht das Problem weiterhin:

Die Vorhersagen unter forecast/hour halten nach der Zeitumstellung einerseits noch alte Objekte aus der Winterzeit und andererseits neue Objekte aus der Sommerzeit. Hier liefert die SRF-API je nach Winter- oder Sommerzeit andere Zeiten (Stunden). Entsprechend liegen dann im Adapter noch alte Objekte rum.

Alle anderen Forcasts (60minutes, current_hour, day) sind nicht betroffen. Diese sind auch nach der Zeitumstellung korrekt. Hier liefert die SRF-API (interessanterweise) nicht je nach Sommer-/Winterzeit unterschiedliche Stunden.

Workaround:

• Löschen der Objekte forecast/hour (ganzer Objektbaum). Der Adapter wird die Einträge beim nächsten Update korrekt erstellen.

Umsetzung An folgenden Tagen ergibt sich die Problematik:

• am letzten Sonntag im März wird auf Sommerzeit vorgestellt (von 2 auf 3 Uhr) und
• am letzten Sonntag im Oktober wird zurück auf die Normal- bzw. Winterzeit gestellt ( von 3 auf 2 Uhr).

Pragmatische Lösung:

• Eruieren, wann für das laufende Jahr die Umstellungsdaten sind
• An diesen beiden Tagen soll in jedem Run ab 4:00 Uhr die Objekte forecast/hour gelöscht werden.
• Damit stimmen die Zeiten anschliessend (ab 4:00 Uhr) wieder.

<label for="year">Jahr:</label>
<input type="text" id="year" placeholder="Jahr eingeben">
<button id="calculate-btn">Berechnen</button>
<p id="result"></p>

$(document).ready(function() {
  $('#calculate-btn').click(function() {
    var year = $('#year').val();
    var dst_start = new Date(year, 2, (14 - new Date(year, 2, 1).getDay() + 7) % 7 + 1, 2);
    var dst_end = new Date(year, 10, (7 - new Date(year, 10, 1).getDay() + 7) % 7 + 1, 3);

    var dst_start_str = dst_start.toLocaleString('de-DE', { timeZoneName: 'short' });
    var dst_end_str = dst_end.toLocaleString('de-DE', { timeZoneName: 'short' });

    var result = "Die Sommerzeit beginnt am " + dst_start_str + " und endet am " + dst_end_str + ".";

    $('#result').html(result);
  });
});

[baerengraben]

Es besteht eine kleine Wahrscheinlichkeit, dass SRF diese Problem mit der neuen API Version 2 gelöst hat. Neu sind die betroffenen Objekte in swiss-weather-api.0.forecast.three_hours.* abgelegt.

Die Korrektur, was eher ein unschöner "Hack" ist, soll entfernt werden und dann die nächste Zeitumstellung abgewartet werden.

Wenn es immer noch nicht funktioniert, muss ich mir evtl. Gedanken darüber machen, anstelle der Zeit "swiss-weather-api.0.forecast.three_hours.day0..*" eine fortlaufende Nummer zu wählen.

[baerengraben]

Das Problem besteht weiterhin.

Das Problem kann wohl so nicht behoben werden:

• Bei jeder Abfrage swiss-weather-api.0.forecast.three_hours.* löschen
• Bei jeder Iteration von three_hours die konkrete Stunde aus swiss-weather-api..forecast.three_hours..*.date_time lesen und Objekte entsprechend erstellen.

Dies, weil der ioBroker Object-Tree fix sein muss. Sonst kann man die Werte gar nicht in Scripten und Visu verweden. Darum muss ich wohl oder übel für "three_hours" neu eine fortlaufende Nummer wählen (swiss-weather-api.0.forecast.three_hours.day0.*).

[baerengraben]

Grundsätzlich schreibt der Adapter einfach 1:1 die Werte, welche SRG sendet in ioBroker Objekte. Damit man die Objekte besser in Visu etc. integrieren kann, strukturiere ich die angelieferten Daten. Für three_hours z.b. nach "swiss-weather-api.0.forecast.three_hours.day1.0100". Wobei 0100 der effektiv von SRF gelieferten Stunde entspricht. Hier wird also z.B. "02.11.2024 01:00:00" von SRG angeliefert.

Aus irgend einem Grunde liefert SRG in der Sommerzeit "02.11.2024 02:00:00" und in der Winterzeit "02.11.2024 01:00:00".

Daraus resultiert, dass im ioBroker Objekt-Tree dann in der Sommerzeit die 0100 Objekte aktualisiert werden und in der Winterzeit die 0200 Objekte. Damit kann natürlich dann keine anständige Visu erstellt werden.

Ich habe mich nun entschieden für die three_hours Objekte eine Laufnummer zu vergeben:

• Für 0100 oder 0200 wird 1
• Für 0400 oder 0500 wird 2
• usw.

Falls jemand die three_hours Objekte integriert hat, muss dies nun neu berücksichtigt werden.

[baerengraben]

Fixed in https://github.com/baerengraben/ioBroker.swiss-weather-api/releases/tag/v2.2.1