ETM-Schurig/etm-powersync-energy-plugin-etm

Patrick Schurig 18e9c3abe4 docs: ouvrir le lot fuseau, et graver les deux masques empilés

LOT FUSEAU (docs/DESIGN_FUSEAU.md) — design avant code, comme pour le délestage
et le §10. Deux questions étaient posées ; les deux sont fermées par mesure.

1. Le fuseau vient-il de la box ou de nymea ? Des deux, et c'est le MÊME.
   `EnergyArbitrator::update()` prend `QDateTime::currentDateTime()`
   (energyarbitrator.cpp:329), `resolveDeadline()` hérite via `now.timeZone()`,
   et nymea ne fait que relayer `QTimeZone::systemTimeZoneId()`. Aucun réglage
   nymea ne peut dire autre chose que timedatectl : box et moteur ne peuvent pas
   diverger entre eux.

2. Mesuré dans le conteneur, avec un programme Qt6 pendant qu'on bascule
   /etc/localtime sous lui : un processus VIVANT suit le changement, sans
   redémarrage. Ce n'était pas acquis — la mise en cache du fuseau par processus
   est le comportement classique de la libc, et si Qt l'avait fait, corriger un
   fuseau n'aurait rien corrigé jusqu'au redéploiement suivant.

La vraie divergence est ailleurs, et elle est double. Entre l'INSTALLATION et le
CLIENT d'abord : `dailyDeadline` est une heure murale SANS fuseau, saisie sur un
téléphone qui a le sien, lue dans celui de la box — silencieuse des deux côtés,
chacun ayant raison dans son référentiel. Un fuseau implicite est une absence
qui signifie « le défaut s'applique », ce qu'on s'interdit partout ailleurs.

Et entre l'installation et le CALENDRIER RÉGLEMENTÉ, qui est le point neuf : une
plage d'heures creuses française est définie en Europe/Paris par le fournisseur,
pas « à l'heure locale de la box ». Deux natures d'heure murale, deux sources de
fuseau — l'habitude du client suit l'installation, le tarif suit le texte qui le
définit. Les confondre ne décale pas l'affichage : ça achète au mauvais moment.

DÉCISION : ni imposer, ni refuser — déclarer. Imposer serait affirmer un fuseau
qu'on ne sait pas vérifier. Refuser de fonctionner déplacerait un problème
d'affichage vers la sécurité, alors que L0..L4 raisonnent en durées et ne
dépendent d'aucun fuseau. Déclarer est la doctrine maison appliquée telle quelle.

DEUX MASQUES EMPILÉS (AGENTS.md, quatrième occurrence de la même famille). Le
mock plus homogène que la réalité avait une suite : l'environnement de
vérification plus indulgent que la réalité, deux fois dans la même chaîne de
build. Un artefact périmé couvrant un lien cassé, et le build vert couvrant les
deux. Un répertoire de travail accumule de l'état qui répond à la place du
dépôt — « est-ce que ça compile ? » n'a pas de valeur sans dire DEPUIS QUOI.
Seule la reconstruction dans un répertoire vierge les révèle, et le md5 identique
au binaire en service est la façon de fermer : il ne dit pas « ça compile », il
dit que le build reproductible produit exactement ce qui tourne.

2026-09-04 07:52:28 +02:00

7.6 KiB

Raw Blame History

Fuseau horaire — le silence d'une heure

Ouvert le 2026-09-04, après qu'une obligation éco déclarée à "12:00" se soit résolue à 13:00 sur l'horloge de l'atelier. Le moteur avait raison ; c'est la question qui n'avait jamais été posée.

1. Le constat

.75 tourne en Europe/London. Une obligation dailyDeadline: "12:00" s'y résout donc à 12:00 heure de Londres, soit 13:00 en France. Rien, nulle part, ne le dit.

L'écart est d'une heure et ressemble trait pour trait à un défaut d'heure d'été dans la résolution d'échéance — j'ai failli l'imputer au moteur avant de lire l'horloge de la box. C'est le premier coût du silence : il déplace le soupçon.

Le second coût est celui qui compte. Chez un client français, une box mal fuseau-horée décale toutes ses fenêtres temporelles. Une obligation « avant 7 h » se déclenche à 8 h. Et quand les heures creuses, Tempo et le marché de gros arriveront, elles se décaleront aussi — sauf que là, personne ne le verra avant de compter sa facture.

2. Fait établi — il n'y a qu'UN fuseau, et il vient du système

Vérifié, pas supposé :

EnergyArbitrator::update() prend QDateTime::currentDateTime() (energyplugin/etm/energyarbitrator.cpp:329), donc le fuseau du PROCESSUS nymead.
resolveDeadline() construit l'échéance avec now.timeZone() (energyplugin/etm/types/ecotarget.cpp). Elle n'introduit aucun fuseau à elle : elle hérite.
nymea n'a pas de fuseau propre. System.GetTime renvoie QTimeZone::systemTimeZoneId() (libnymea-core/jsonrpc/systemhandler.cpp), et System.SetTimeZone écrit le fuseau système via le SystemController de la plateforme. Configuration.SetTimeZone est déprécié au profit du premier.

Conséquence : la box et le moteur ne peuvent pas diverger entre eux. Il n'existe pas de réglage nymea qui dirait autre chose que timedatectl. C'était la première question — elle est fermée, et dans le sens rassurant.

3. Fait mesuré — un processus vivant SUIT le changement

Mesuré le 2026-09-04 dans le conteneur build-cross-arm64, avec un programme Qt6 qui lit QTimeZone::systemTimeZoneId() et QDateTime::currentDateTime() en boucle pendant qu'on bascule /etc/localtime sous lui :

  systemTimeZoneId=Europe/London  currentDateTime=06:48:50 BST   zone(now)=Europe/London
  --- /etc/localtime bascule vers Europe/Paris ---
  systemTimeZoneId=Europe/Paris   currentDateTime=07:48:53 CEST  zone(now)=Europe/Paris

Changer le fuseau ne demande donc PAS de redémarrer nymead. Ce n'est pas une évidence : la mise en cache du fuseau par processus est un comportement classique de la libc, et si Qt l'avait fait, une correction de fuseau serait restée sans effet jusqu'au prochain redéploiement — une correction qui ne corrige rien étant pire que pas de correction.

Corollaire à ne pas perdre : une échéance en cours de résolution peut donc changer d'heure sous le moteur, sans redémarrage et sans notification. Cf. §6, étape 3.

4. La vraie divergence n'est pas là où on la cherchait

Box et moteur s'accordent par construction. Ce qui peut diverger, c'est :

(a) L'installation et le client. dailyDeadline est une chaîne "HH:mm" sans fuseau. Le client saisit « 7:00 » dans l'app, sur un téléphone qui est dans SON fuseau, en pensant 7:00 chez lui. Le moteur la lit dans le fuseau de la box. Si les deux diffèrent, l'écart est silencieux des deux côtés — l'app affiche ce qu'elle a saisi, le moteur exécute autre chose, et les deux ont raison dans leur référentiel.

Un fuseau implicite est une absence qui signifie « le défaut s'applique ». C'est exactement ce qu'on s'interdit ailleurs (measurement.source, rankOrigin, progress.regime).

(b) L'installation et le CALENDRIER RÉGLEMENTÉ. Et c'est le point neuf.

5. La distinction qui décide : deux natures d'heure murale

Elles ne prennent pas leur fuseau au même endroit, et les confondre est le piège.

	nature	fuseau qui fait foi
`dailyDeadline`, « avant 7 h »	habitude du client	celui de l'installation
heures creuses, Tempo, EPEX	calendrier réglementé	celui où le tarif est DÉFINI

Une plage d'heures creuses française est définie en Europe/Paris par le fournisseur, pas « à l'heure locale de la box ». Une box française mal réglée ne décale pas seulement l'affichage : elle achète au mauvais moment, et le tarif, lui, ne s'est pas décalé.

Aujourd'hui les deux natures prendraient silencieusement le fuseau de la box. Pour la première c'est correct si la box est bien réglée ; pour la seconde c'est faux dès qu'elle ne l'est pas. Une grandeur réglementée ne doit donc pas hériter du fuseau système : elle doit porter le sien.

Le marché de gros amont travaille en instants ABSOLUS (les tests construisent leurs horodatages via EnergyTestBase::utcDateTime), donc il est déjà à l'abri. Le risque naît le jour où l'on écrira une plage tarifaire en heures murales — c'est-à-dire au prochain lot tarifaire, pas plus tard.

6. La décision : ni imposer, ni refuser — DÉCLARER

Ne pas imposer. Le moteur ne connaît pas le fuseau « vrai » de l'installation ; il ne connaît que celui de la box. Le forcer à Europe/Paris serait poser une affirmation qu'on ne sait pas vérifier, et serait faux par construction pour toute box vendue hors de France.

Ne pas refuser de fonctionner. Un HEMS qui s'arrête parce qu'un téléphone est en itinérance laisse un chauffe-eau sans pilotage et une protection de disjoncteur sans arbitre. Les couches L0 à L4 ne doivent dépendre d'aucun fuseau : elles raisonnent en durées, pas en heures murales. Le refus est disproportionné, et il déplacerait un problème d'affichage vers la sécurité.

Déclarer, donc — la seule réponse conforme à la doctrine maison : publier le régime, ne jamais le laisser déduire. Le moteur dit dans quel fuseau il résout les heures murales ; c'est au client de rapprocher cela de l'heure de son utilisateur, et de l'avertir.

Les étapes, à comportement constant d'abord

Documenter le contrat (aucun changement de code). dailyDeadline est une heure murale du fuseau de la box, tel que publié par System.GetTime.timeZone. Écrit dans INTERFACE.md, à côté du champ.
Publier le fuseau avec la configuration, en lecture seule, plutôt que d'exiger du client qu'il croise deux espaces de noms pour interpréter un de NOS champs. Un client qui doit appeler System.GetTime pour donner un sens à dailyDeadline finira par ne pas le faire.
Dire le changement. Le fuseau peut bouger sous le moteur sans redémarrage (§3). Une échéance résolue à 12:00 hier peut valoir 13:00 aujourd'hui sans qu'aucun champ n'ait changé. À traiter comme tout élément runtime : un Get* ET un *Changed.
Séparer les deux natures au moment d'écrire la première plage tarifaire : une plage réglementée porte le fuseau où elle est définie, elle n'hérite pas du système.
Côté app (lot séparé, à elle) : comparer le fuseau de la box à celui de l'appareil au moment de la SAISIE d'une échéance, et avertir. C'est l'écran de saisie qui doit parler, pas l'écran de résultat — au moment du résultat, l'heure est déjà passée.

Ce qui reste ouvert, et qu'on ne tranche pas ici

Le fuseau de .75 lui-même. Europe/London sur un banc français est une erreur de configuration, mais la corriger déplace d'une heure la lecture de tout l'historique d'énergie déjà enregistré. C'est une décision d'exploitation, pas de conception.

7.6 KiB Raw Blame History