Décalage de l'heure (+1h)

[brenard]

Je viens de me rendre compte que mon minuteur d'appoint nocturne ne fonctionnait plus (certainement depuis mon upgrade en 20240308). J'ai l'impression que les ordres envoyés par le routeur sont acceptés pendant les heures du minuteur. Après un upgrade du firmware (20240316), ce problème semble corrigé.

En outre, je contaste que l'heure affichée sur la page du minuteur est décalé d'une heure (+1). J'avais souvenir que l'heure était également affichée sur la page d'accueil mais je ne la vois pas. En outre, suite à un reboot, dans les logs, l'heure de fin de démarrage est également décalé de +1 heure.

Note : ça a probablement un lien avec #46 où le problème corrigé était un décalage de -1h. Il y aura t-il un problème de gestion des heures d'hiver / été ?

[xlyric]

c'est fort probable, la gestion été/hiver est une vrai galère à gérer comme les serveurs de temps ne prennent pas en compte cette élément. et effectivement, il y a à 2 endroits l'heure d'affiché, sur la page d'acceuil c'est ton système qui affiche l'heure, sur la page minuteur, c'est l'ESP qui remonte l'heure qu'il a récupéré

le problème vient aussi que bientôt c'est le changement d'heure et donc ça colle un peu au fait que ça collait en gros à la règle.

[brenard]

OK, je viens de voir ta méthode pour calculer le jour de début/fin de passage à l'heure d'été et bien qu'elle semble fonctionner pour les années bissextiles (comme cette année), c'est pas forcément le cas pour les années non-bissextiles du fait qu'elle ne gère pas les arrondis (mais je sais pas comment les ESP32 gère les floats) :

29.0/03/2020 - 25.0/10/2020 => OK
27.75/03/2021 - 30.75/10/2021 => ? 28/03 - 31/10
26.5/03/2022 - 29.5/10/2022 => ? 27/03 - 30/10
25.25/03/2023 - 28.25/10/2023 => ? 26/03 - 29/10
31.0/03/2024 - 27.0/10/2024 => OK

J'ai trouvé cette autre formule qui semble fonctionnelle (en python) :

date_debut = lambda year: 25 + ( 7002 - year - math.floor(year / 4) ) % 7
date_fin = lambda year: 25 + ( 7005 - year - math.floor(year / 4) ) % 7
for year in range(2020, 2025):
     print(f"{date_debut(year)}/03/{year} - {date_fin(year)}/10/{year}")

Résultat:

29/03/2020 - 25/10/2020
28/03/2021 - 31/10/2021
27/03/2022 - 30/10/2022
26/03/2023 - 29/10/2023
31/03/2024 - 27/10/2024

[brenard]

Et donc au final, ça n'explique pas pourquoi on a un décalage cette année. Ça pourrait être utile de loguer en console l'offset calculé et l'heure courante à chaque mise à jour de l'heure via NTP ?

[mathieucarbou]

Le changement d'heure est géré en principe en utilisant les fonctionnalités de timezone inclues dans les ESP (voir ma lib: https://github.com/mathieucarbou/MycilaNTP).

Pour Europe/Paris, la spec est CET-1CEST,M3.5.0,M10.5.0/3.

Il n'y a pas de BD de fuseaux dans l'ESP mais ma lib en inclue une en flash (PROGMEM).

  configTime(0, 0, "pool.ntp.org");
  setenv("TZ", "CET-1CEST,M3.5.0,M10.5.0/3", 1);
  tzset();

ensuite, pour ne pas être bloquant faire des appels avec getLocalTime(&timeInfo, 5); afin d'éviter la boucle interne.

on peut aussi mettre en place un Ticker qui va forcer le sync et prévenir de sa fin:

  if (!_synced) {
    _ticker.attach(
      retryInterval, +[](NTPClass* instance) {
        if (!instance->_synced) {
          struct tm timeInfo;
          if (getLocalTime(&timeInfo, 5)) {
            instance->_synced = true;
            instance->_ticker.detach();
          }
        } else {
          instance->_ticker.detach();
        }
      },
      this);
  }

[xlyric]

la modification sera appliquée sur les mises à jour du 1er Mai