ESP8266 0.5.89 tickMidnight beachtet nicht den Zeitzonen offset

[fsck-block]

tickMidnight wird nach UTC Mitternacht aufgerufen und nicht nach local time Mitternacht.

Zusätzlich wird noch eine (1) Sekunde dazugegeben. Damit liegt das Zurücksetzten der Yield Werte immer im nächsten Tag.
Dies führt bei meinen weiteren Auswertungen zu Problemen.

Liegt meiner Meinung nach an:
tickNtpUpdate web.h@196

uint32_t midTrig = mTimestamp - ((mTimestamp - 1) % 86400) + 86400; // next midnight

und tickMidnight web.h@307

uint32_t nxtTrig = mTimestamp - ((mTimestamp - 1) % 86400) + 86400; // next midnight

Bin mir nicht sicher wie das rücksetzen der Yield Werte gedacht war. Aber für mich ist wichtig dass der nächste Tag (00:00:00) mit zurückgesetzten Werten beginnt.
Daher würde ich folgende Berechnung vorschlagen:

= mTimestamp - ((mTimestamp + mCalculatedTimezoneOffset + 1) % 86400) + 86400; // 1 second before midnight (acc. timezone)

Vielleicht auch mehr offset als eine Sekunde falls die Timer verzögert werden können.

[jimknopf63]

Wenn die Werte vor Mitternacht zurückgesetzt werden dann würden bei mir im IoBroker ScourceAnalytics die Daten für den endenden Tag gelöscht. Da ist eine Sekunde nach Mitternacht doch eher die richtige Einstellung. Ich kann mir nicht vorstellen das das Ergebnis deiner Berechnung stark abweicht wenn es um 0:00:01 statt um 0:00:00 zurück gesetzt wird. Zumal das BKW ja zur der Zeit nicht produziert.

[fsck-block]

Hatte mir schon gedacht, dass es Gründe gibt auf den nächsten Tag zu warten.
Bei mir ist es gerade andersrum. Ich frage nach dem Maximum pro Tag ab.
Und wenn dann der Wert um 00:00:01 höher ist als der Ertrag des laufenden Tages dann passt das nicht.

Oh je, wenn wir für das zurücksetzen der Werte nochmals einen Schalter für vor oder nach Mitternacht brauchen.
Irgendwie inflationär diese Einstellmöglichkeiten. 😁

@jimknopf63 : brauchst du UTC Mitternacht oder Local Time Mitternacht

[jimknopf63]

@jimknopf63 : brauchst du UTC Mitternacht oder Local Time Mitternacht

Ups, da bin ich jetzt überfragt, habe bei der Einrichtung damals Berlin ausgewählt (Proxmox) und dahinter stand UTC+1

[knickohr]

„Genullt“ wird um 0:00UTC, also bei uns um 1 Uhr bzw. 2 Uhr (Sommerzeit).

[fsck-block]

„Genullt“ wird um 0:00UTC, also bei uns um 1 Uhr bzw. 2 Uhr (Sommerzeit).

Hört sich an wie ein "ist alternativlos, wird nie anders sein".

Gut, kann ich nachvollziehen da wohl die Mehrheit mit MQTT arbeitet. Aber vielleicht finden wir eine Möglichkeit für die anders denkenden. Wenn's nicht per super duper config parameter mit web-gui geht, dann vielleicht auf Quellcodeebene.
Könnte man ja in config_override.h unterbringen.
Wenn das zustimmungsfähig wäre würde ich da mal etwas implementieren.
BTW: Wer entscheidet denn über solche Dinge?

[knickohr]

Das müssen die Programmierer entscheiden.

Aber hast ja schon einen PR aufgemacht 👍

[beegee3]

hier werden 2 Dinge diskutiert

1. Zeitpunkt für das Zurücksetzen der Yield Werte
2. local time statt UTC

zu 1.: sollte der Zeitpunkt nicht eigentlich genau Mitternacht sein? Weder 1 sec davor, noch 1 sec danach.
Müsste doch eigentlich jeden zufriedenstellen!
zu 2.: local time ist sicher besser. UTC ist zu spät, s. @knickohr's Bemerkung oben.
local time lässt sich mit der genial einfachen Methode realisieren, die schon in MonochromeDisplay benutzt wird, um auf den Displays local time anzuzeigen.
Verlegt man die dortigen Definitionen TimeChangeRule CEST, CET und Timezone mCE nach helper.h, so steht überall local time zur Verfügung, also:
die Definitionen in MonochromeDisplay.h löschen und in helper.h einfügen

...
//#include <TimeLib.h>
#include <Timezone.h>

static TimeChangeRule CEST = {"CEST", Last, Sun, Mar, 2, 120};     // Central European Summer Time
static TimeChangeRule CET = {"CET ", Last, Sun, Oct, 3, 60};       // Central European Standard Time
static Timezone mCE(CEST, CET);
...

In MonochromeDisplay.h ist sowieso helper.h eingebunden, so dass die mCE Aufrufe weiterhin funktionieren.

Nun noch in app.h tickNtpUpdate und tickMidnight anpassen (hier mit Zeitpunkt genau Mitternacht):

void app::tickNtpUpdate(void) {
        ...
            if(mConfig->inst.rstYieldMidNight) {
                uint32_t localTime = mCE.toLocal(mTimestamp);
                uint32_t midTrig = mCE.toUTC(localTime - (localTime % 86400) + 86400); // next midnight local time
                onceAt(std::bind(&app::tickMidnight, this), midTrig, "midNi");
            }
        }
        ...
}

void app::tickMidnight(void) {
    // only triggered if 'reset values at midnight is enabled'
    uint32_t localTime = mCE.toLocal(mTimestamp);
    uint32_t nxtTrig = mCE.toUTC(localTime - (localTime % 86400) + 86400); // next midnight local time
    onceAt(std::bind(&app::tickMidnight, this), nxtTrig, "mid2");
    ...
}

[fsck-block]

Zu 1)
Pünktlich um Mitternacht müsste (theoretisch) passen. Aber irgendwie haben beide Ansätze angst, dass die entscheidende Sekunde fehlt. Will es aber gerne versuchen.
Zu 2)
Local Time ist für mich in Ordnung.
Allerdings hatte @knickohr für UTC Mitternacht gesprochen. Da ich keinen IO-Broker und MQTT benutze kann ich nicht sagen welche Voraussetzungen dabei notwendig sind, damit keine Daten verloren gehen oder nicht ausgewertet werden können.

[beegee3]

local time oder UTC hängt für MQTT sicher davon ab, auf welcher Zeitbasis die Analysen gemacht werden.
UTC hat halt den Nachteil, dass das Löschen der Yield Werte theoretisch mitten am Tag passiert (z.B. in Australien).
OK, local time wäre momentan fest auf CEST eingestellt, aber das könnte man ja irgendwann über ein Setting variabel gestalten.