Légende de preuve

Une case OTA ne garantit pas que toute future variante de la famille a été validée : elle prouve seulement le client OTA et la combinaison qui a réellement traversé le canari.

Vocabulaire : le montage physique n'est pas le firmware

Un montage (ce qu'on branche) et un profil (le firmware qui le pilote) ne sont pas la même chose. Ce qui compte pour mettre à jour une carte à distance, c'est le profil installé : sa famille OTA, sa version, sa séquence.

Conséquence pratique : une mise à jour à distance de la carte de dev_T46HBXG1 est une release de la famille esp8266-eink29bwr, ciblée sur cet appareil, sans OLED tant que la mémoire n'est pas récupérée ; elle ne peut pas être une release multiscreen.

Profils ESP8266

Contraintes ESP8266 à ne jamais contourner

• Une option activée est une variante de build ; la version et la séquence OTA doivent identifier cette variante.
• Les paires écran + capteur doivent conserver les invariants mémoire : buffers d'image libérés avant TLS, aucun envoi capteur pendant un vote ou une OTA, garde sur le plus grand bloc libre.
• D3/GPIO0 est le seul pin encore libre dans les profils TFT et multiscreen recensés ; un DHT22 sur cette broche doit rester débranché pendant un téléversement USB, car GPIO0 participe au mode de flash.
• Mesuré le 24/10/2026 : l'OLED sur le BWR coûte ≈ 2,7 Ko de tas et empêche le téléchargement de frame ; seule la variante sans OLED est exploitable. Les plans image (2 × 4 736 o) sont alloués avant le TLS : il faut ≥ ≈ 24 Ko contigus restants.
• OLED « d'état » du BWR hybride n'est pas un second écran du réseau : il ne reçoit pas de frames PoD. Le multiscreen, lui, a deux écrans réseau.

Profils UNO R4 WiFi

Les essais OTA R4 de laboratoire (OTA-3, 16/10) ont prouvé le mécanisme de reprogrammation Wi-Fi et la conservation de l'état sur une R4 de canari. Les 26 et 27/10/2026, un client applicatif OTA R4-B (manifeste signé Ed25519, binaire brut, staging, relecture, ticket, séquence en data flash) a mis à jour sur UNE carte : la station `r4env` de A vers B (2 réussites sur 3 essais), puis le produit complet `r4tft18` (1 réussite sur 1, 149 Ko ; staging de 245 Ko relu à l'identique), avec un serveur de banc en HTTP clair et des clés de test. 40 cas négatifs refusés. TLS : un 404 de production, et 10 Ko téléchargés par TLS (chaîne du site) avec écriture du staging. Ce n'est pas un client OTA distribué : aucune publication, pas de retour arrière automatique, pas de coupure d'alimentation essayée, un seul module Wi-Fi. Détails et réserves : OTA_R4_CLIENT_ET_PUBLICATION_2026_10_26.md.

Chantiers connus (non commencés, à ne pas présenter comme disponibles)

Ordre de travail convenu (25/10/2026) : 0. BWR 2,9″ + DHT22 sans OLED : clos ; 1. optimisation OLED (frames, animations, température) sur le plus gros montage ESP8266 ; 2. ensuite le TFT 1,8″ + DHT22.

Le e-ink 2,7″ BW + DHT22 n'est pas une simple extension du BWR (constat du 25/10/2026) : le firmware esp_eink_2.7BW (sans OLED) n'a ni portail, ni OTA, ni frame par morceaux, ni DHT22, ni textes en flash, et aucune preuve matérielle (C seulement) ; le BW avec capteur passe donc d'abord par le multiscreen (2,7″ BW + OLED), qui possède portail et OTA mais pas la surimpression T/H. Il rejoint le chantier OLED.

• BWR 2,9″ + OLED en second écran du réseau (comme le multiscreen) : aujourd'hui l'OLED du BWR n'affiche que l'état (Wi-Fi, mesure) et il est désactivé parce qu'il empêche le téléchargement des frames. Pistes : récupérer au moins 3 Ko de tas (pilote OLED minimal sans bibliothèque Adafruit, un seul tampon de page ; libération avant chaque TLS). Un OLED qui reçoit des frames serait un nouveau profil (famille OTA propre, préfixe de vote, page Installer), pas une option.
• Mise à jour à distance du TFT + DHT22 : release tft18-2.10-ota7 publiée, installation non aboutie ; cause à établir (journaux serveur d'observabilité, puis essai sur place).

Qui vote en V2, qui peut être mis à jour à distance (par famille de firmware)

Le serveur reconnaît une famille par le préfixe de la version déclarée à l'enregistrement. Une carte dont la version est plus ancienne que le minimum ne compte pas dans le quorum, ne reçoit pas de candidat et ne peut pas voter (403) ; les capteurs seuls ne votent jamais. La colonne « a voté » ne dit que ce qui a été observé sur une vraie carte.

Les valeurs « dès » viennent de lib/voteCapability.ts (VOTE_V2_FIRMWARE) et lib/otaDistribution.ts (OTA_CLIENT_FIRMWARE) ; un test compare ce tableau au code.

• Affichages récurrents choisis par l'utilisateur (température, temps de trajet TomTom, etc.) : étude chiffrée (durée de vie de l'e-ink, quota TomTom de 2 500 requêtes/jour, budget Redis) et conception dans docs/AFFICHAGE_RECURRENT_EINK_DUREE_DE_VIE_ET_TOMTOM_2026_10_25.md. Rien n'est construit ; la température gravée du BWR en est le premier cas.
• Marge mémoire TLS des ESP8266 : cause du plantage OOM et corrections en cours (textes en flash, frame par morceaux) dans docs/MARGE_MEMOIRE_ESP8266_TLS_2026_10_24.md.

Règle de composition : éviter l'explosion combinatoire

Un firmware public est défini par :

famille MCU + profil de câblage/écran + modules explicitement compatibles

Exemple : ESP8266 4 Mo + BWR 2,9 + OLED d'état + DHT22 est un profil. Deux appareils qui partagent ce profil reçoivent la même release, mais chaque release peut être ciblée par deviceId pendant le canari.

On ne crée donc ni un code par personne, ni une promesse de compatibilité pour tout assemblage. Les choix utilisateur futurs devront être limités au catalogue de profils déclarés, avec vérification automatique des conflits de pins, du rôle d'écran et du budget mémoire.

Politique de publication

La page publique ne doit jamais présenter une option DHT22, OLED ou trafic comme « compatible » avant que sa ligne passe au minimum à M pour le matériel concerné.

Contrat de maintenance obligatoire

À chaque nouveau profil, build, flash ou test, la personne qui réalise le lot met à jour dans le même commit ou le même compte rendu :

1. cette matrice ;
2. la version, la séquence OTA, les pins et les modules activés ;
3. le niveau de preuve réel (C, M, P, V2, OTA) et le lien vers le journal/procédure ;
4. la décision de diffusion : expérimental, canari ciblé, stable ou interdit ;
5. la page Installer/README seulement lorsque le profil devient publiable.
6. La page « Apprendre → Compatibilité matérielle » est le rendu direct de ce fichier (aucune copie) ; tests/hardwareMatrix.test.ts doit passer : il vérifie que les profils d'installation (testedOnHardware), les avertissements de /api/esp-firmware, la table de la synthèse technique et les firmwares téléchargeables (options capteur/OLED à 0, version compatible avec le client OTA) restent cohérents avec cette matrice. Un test qui échoue signale qu'une moitié n'a pas été mise à jour dans le même lot.

Interdit de faire passer une case de C à M, V2 ou OTA sans journal matériel archivé. Interdit aussi de déduire qu'une variante capteur est sûre parce que le firmware sans capteur a réussi une OTA.

Sources principales

• docs/DISTRIBUTION_TFT_BWR_2026_10_23.md
• docs/PROCEDURE_OTA_BWR_2026_10_23.md
• docs/MULTISCREEN_PORTAIL_OTA_2026_10_23.md
• docs/CAPTEUR_DHT22_MULTISCREEN_ESP8266_2026_10_23.md
• docs/CAPTEUR_TEMPERATURE_R4_DHT22.md
• docs/SYNTHESE_VOTE_REEL_ET_PRODUCTION_DIRECTE_2026_10_14.md
• PR #7 (9fa5701) : 3c3f5b2 (hybride BWR), 482d738 (ACK, plans libérés), 394e64a (TFT + DHT22), b64964c/a7adc12 (preuves) ; docs docs/BWR_HYBRIDE_OLED_DHT22_ONBOARD_2026_10_24.md, docs/TFT18_DHT22_MESURES_2026_10_24.md, docs/BWR_MESURES_SUR_AFFICHAGE_2026_10_24.md (branche de laboratoire) ;
• premiers OTA : 3f9b72c (BWR), 61b33ee (multiscreen) — ces deux hashes sont des commits de la branche de laboratoire locale ; la preuve publique est dans docs/PROCEDURE_OTA_BWR_2026_10_23.md et docs/MULTISCREEN_PORTAIL_OTA_2026_10_23.md.

Corrections apportées à la première version (24/10/2026, relecture)

1. BWR + OLED + DHT22 : passé de « C, correctif ACK non essayé » à `M` + INCOMPATIBLE (échec mesuré du téléchargement de frame).
2. Ajout du profil BWR + DHT22 sans OLED (V2 : bloc #114, ACK 200) et du profil surimpression T/H (C).
3. TFT + DHT22 : « release préparée » → publiée, annoncée, installation non aboutie.
4. TFT 2.9 : affichage + ACK observés à distance (relevé serveur).
5. Références de commits : remplacées par des commits présents sur GitHub (les hashes 21ba48c, 023687f, c0f7f08, f2d2075 n'existent que dans la branche de laboratoire locale).
6. Menu « Mesures » : déclaration firmware ≠ capteur branché (note multiscreen).

Mises à jour du 28/10/2026 (Claude)

• Ligne `r4tft18-2.3` remise à jour (ancienne ligne r4tft18-2.0 : « jamais reçu de frame ni voté » est devenu : vote refus « blank » observé, aucune acceptation).
• Électorat réel du 27/10 (lecture seule de Redis) : 8 appareils connus, un seul compté, les autres inactifs (ping de 12 heures à 21 jours) ou, pour le multiscreen actif, exclu après des candidats d'animation impossibles à voter depuis le 14/10. Le « réseau de 1 validateur » était donc réel, pas un plancher. Détail : PLAN_RESEAU_VALIDATEURS_ET_STATION_R4_2026_10_28.md.
• Règle visée : toute carte disposant de la capacité de validation vote sur tout dessin, quel que soit son écran. État actuel : les profils capteurs seuls sont exclus du quorum. Cible décidée : validateurs sans écran via une capacité explicite et déclarée, non implémentée.
• Corrections locales non flashées (lots 1 à 3) : verdict « blank » R4 aligné sur l'ESP (écran couleur = pixels tous identiques) ; candidat conservé quand une image arrive ; tampon de validation pris à la demande (BWR : plus 4 736 o systématiques) ; quorum à trois manques consécutifs ; électorat figé dans le candidat. Niveaux : C (compilés) + H (hôte) ; aucun M ni V2 tant qu'elles ne sont pas flashées.
• ANIM_V1_VOTE (vote v1 « écho » admis pour les animations seulement) est transitoire et ne valide pas le contenu du clip.

• 29/10/2026 — station `r4tft18-2.6` (compilée, non flashée) : échelle de temps sur les courbes de l'écran (trait par heure, 00/06/12/18, heure locale France). Le vote reste celui des lignes r4tft18-2.4/2.5 ; l'écran avec échelle n'a pas été vu sur la carte. OTA : POD_OTA_R4 = 0 sur la carte, donc câble. Détail : docs/CAPTEUR_TEMPERATURE_R4_DHT22.md.

• 29/10/2026 — BWR téléchargeable remis au profil de distribution : le code proposé au téléchargement était resté en eink29bwr-2.3 (OTA et portail Wi-Fi éteints, Wi-Fi dans le binaire), donc sans mise à jour à distance. Il porte désormais eink29bwr-2.13 avec POD_WIFI_FROM_RECORD, POD_WIFI_PORTAL, POD_OTA, POD_OTA_CLIENT et POD_FRAME_CHUNK à 1 par défaut ; capteur DHT22, OLED et affichage capteur restent à 0. Compilé (cœur 3.1.2, nodemcuv2 4M2M) : 529 424 o, RAM statique 34 176 o, deux clés publiques de publication présentes, aucun identifiant Wi-Fi. Jamais flashé tel quel : seule la combinaison avec capteur/OLED a traversé un canari.

• 29/10/2026 — téléchargements remis à jour : le BWR 2,9″ passe à eink29bwr-2.13 (portail Wi-Fi + OTA, voir plus haut) ; le profil UNO R4 + TFT 1,8″ ne propose plus l'ancien port pod_uno_r4_tft18 (1.1, jamais essayé) mais le produit pod_uno_r4_tft18_env (r4tft18-2.6), compilé depuis les seuls fichiers suivis par git (52 % flash, 49 % RAM, options capteur / station / OTA à 0). Reste en retard : le téléchargement UNO R4 + TFT 2,8″ est r4tft28-2.5 alors que la carte tourne en r4tft28-2.6 (portail Wi-Fi, branche claude/r4-tft28-portail-vote, non fusionnée) ; les ports e-ink 2,7″ (ESP8266 seul, UNO R4 seul et + OLED) n'ont jamais été essayés et n'ont pas d'OTA ; aucun firmware UNO R4 téléchargeable ne reçoit de mise à jour à distance.