Incidents connus¶

Journal d'incidents réels rencontrés sur ce firmware précis, avec la cause racine confirmée et le correctif. À consulter avant de re-diagnostiquer quelque chose qui semble familier — plusieurs de ces cas ont demandé des heures de debug en direct avec l'appareil sur le bureau.

Format : Symptôme → Cause racine → Correctif.

Écran noir après un reboot logiciel (pas une coupure d'alimentation)¶

Symptôme : après un reboot (OTA, crash, api.reboot), l'écran reste noir. Un cycle d'alimentation (débranché/rebranché) corrige le problème ; un reboot logiciel seul non, ou pas de façon fiable.

Cause racine : le reset_pin de l'écran passe par l'expander GPIO I2C PI4IOE5V6408, pas un GPIO natif ESP32. Juste après le boot, l'expander a lui-même besoin d'un court délai de stabilisation avant de piloter ses sorties de façon fiable — actionner reset_pin trop tôt est un no-op du point de vue de l'écran.

Correctif : un delay(1000) bloquant a été ajouté dans on_boot: priority: 700 (tab5-hardware.yaml), juste avant la séquence de reset écran. Cause racine confirmée le 06/07/2026 après 5 tests de reboot en direct. Marqué [AI-WARNING] dans le fichier — ne pas retirer ce délai sans re-tester sur plusieurs reboots. Depuis le 17/10/2026, sa durée vient de la carte (carte_attente_ecran_ms, ADR-0005) : 1 s sur le Tab5, aucune sur la Waveshare 7B, dont le reset de l'écran est une broche du P4 lui-même.

Météo / planning / clim absents alors que l'appareil est en ligne¶

Symptôme : l'appareil affiche une connexion Wi-Fi/API saine, mais les cartes météo/planning/prévisions ne se mettent jamais à jour.

Cause racine : les automations de push côté HA sont toutes conditionnées par un flag booléen partagé (pertinent uniquement dans un setup à double instance HA). Ce flag était bloqué à off ; l'automation de garde-fou censée le reforcer à on à chaque boot HA était elle-même désactivée.

Correctif : réactiver le flag et l'automation de garde-fou, déclencher manuellement le push une fois. Si votre setup pousse conditionnellement sur un flag d'état partagé, vérifiez que l'automation censée le réarmer au boot est bien active.

Depuis la 3.8, le flag (input_boolean.is_primary_active), l'automatisation qui le réarmait et sa garde de santé sont retirés : plus aucune poussée ne dépend d'un flag partagé. Cet incident ne peut plus arriver avec les packages actuels ; si l'écran paraît encore figé, « MAJ Écran », puis vérifier que les automatisations de poussée sont actives.

STT/TTS cassé, dizaines de logs "entity already exists — ignoring"¶

Symptôme : pipeline vocal en échec malgré un service STT sain testé directement. Logs HA pleins d'avertissements de collision d'ID.

Cause racine : une intégration type remote_homeassistant dupliquait toute une seconde instance HA dans celle-ci — collisions d'ID masquant les vraies entités STT/TTS. Ne se reproduit que dans un setup à double instance HA.

Correctif : désactiver l'intégration de duplication, redémarrage HA complet.

Tactile "mort" alors que le contrôleur détecte bien les appuis¶

Symptôme : taper sur l'écran ne fait rien.

Cause racine : HA rejetait les appels de service de l'appareil (Service call ... rejected).

Correctif : cocher "Autoriser les appels de service" dans l'options flow de l'intégration ESPHome pour cet appareil.

Depuis l'ADR-0025 (après la 3.1), le firmware n'appelle plus aucune action : ce refus ne peut plus arriver, les commandes et demandes de l'écran sont des événements. Le même symptôme sur un firmware récent veut dire que leur consommateur manque — le blueprint « Tab5 — emplacements » pour les tuiles, packages/tab5_evenements.yaml pour le calendrier, les annonces et la console système.

Un push calendrier/météo casse silencieusement le reste de la même automation¶

Cause racine : calendar.get_events avec start_date_time: "{{ now() }}" (datetime brut avec microsecondes) — échec de validation silencieux qui interrompait toute la suite de l'automation.

Correctif : "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}", plus continue_on_error: true sur chaque action de push + gardes is defined.

Icônes météo des jours disparues, horaire intact, automation « réussie » (18/09/2026)¶

Symptôme : les 5 cartes journalières perdent leurs icônes (et gardent des données périmées après un reboot) alors que l'horaire se met à jour. HA a toutes les données, l'automation de push ne signale aucune erreur.

Cause racine : le template du payload tab5_maj_previsions_jours_bulk lisait fcasts[i].templow en accès direct sur 15 jours. Météo-France ne fournit plus templow pour j+14 : en Jinja, dict.cle_absente lève UndefinedError avant que | float(0) ne s'applique, le payload n'est jamais rendu et le service jamais appelé. continue_on_error: true masquait la panne (seul le journal HA disait « Error rendering data template »).

Correctif : accès protégé fcasts[i].get('templow') | float(0) (idem condition, temperature, precipitation), en prod le 18/09 et dans l'exemple public le 25/09. Pour repérer la suivante : la trace de l'automation (un appel …_bulk manquant saute aux yeux), la garde (d) de packages/tab5_health.yaml (exige system_log: fire_event: true). Pour forcer un push complet : bouton MAJ Écran de la console système ou Exécuter les actions dans HA — l'événement esphome.tab5_connected lancé à la main ne pousse plus rien depuis le 25/09 (réservé à une liaison API de moins de 3 min).

`pressed:` LVGL refusé dans un `style_definitions` partagé¶

Cause racine : limitation confirmée dans le code source du composant LVGL d'ESPHome — pressed: n'est valide que sur le widget lui-même.

Correctif : le partager sur le widget par pressed: { styles: style_x } (version anglaise ci-dessus ; l'ancien conseil « le répéter sur chaque bouton » était faux). Un bouton verre cliquable de rayon 18 n'a besoin de rien : apply_pressed_scale_to_tree() (tab5_anim.cpp) lui pose l'appui, et les pressed: qui le répétaient sont retirés depuis le 01/10/2026.

Connexions API ESPHome épuisées¶

Cause racine : l'API native n'autorise que 8 connexions simultanées ; des process esphome CLI orphelins (sessions de debug oubliées) en occupent chacun une indéfiniment.

Correctif : fermer les sessions CLI une fois terminées ; vérifier les process esphome orphelins avant de soupçonner l'appareil.

L'appareil redémarre tout seul toutes les ~15-20 min quand Home Assistant est injoignable¶

Symptôme : HA est tombé (ou met longtemps à démarrer), le Tab5 est toujours sur le WiFi et affiche son dernier état connu, mais il redémarre seul toutes les 15-20 minutes environ. Aucun plantage dans les logs : chaque boot est propre et safe_mode annonce Boot seems successful.

Cause racine : ce n'est pas un crash — c'est api: reboot_timeout: dans tab5-api-logic.yaml. ESPHome redémarre l'appareil quand aucun client API n'est connecté pendant cette durée, et le compteur repart à zéro à chaque connexion, même brève. Avec les 15 min d'origine, un serveur HA long à monter produit un cycle de reboots un peu plus long que le timeout lui-même (timeout + boot + tentatives de reconnexion). Le composant wifi: a son propre reboot_timeout, qui n'est pas en cause ici puisque le WiFi fonctionnait.

Correctif : porté à 60min le 01/08/2026 — une panne ou une maintenance HA d'une heure ne fait plus cycler la tablette, qui reste utile sans HA (horloge, arcade, console diag, dernière météo affichée), tout en gardant le filet anti-« zombie » de l'audit F-04. Ne pas mettre 0s sans relire cet audit : une pile API figée laisserait alors l'appareil en ligne mais muet jusqu'à une coupure d'alimentation manuelle.

Écran noir + appareil absent du réseau après une OTA — le co-processeur WiFi n'est pas remonté¶

Symptôme : une OTA annonce OTA successful, l'appareil redémarre, et ensuite : écran noir, aucune entité côté Home Assistant, pas d'API (esphome logs --device <ip> part en timeout sur le port 6053). Le rebooter à nouveau ne change rien. Trompeur : l'IP répond toujours au ping — c'est un autre appareil qui a récupéré le bail, exactement comme la confusion DHCP du 01/08/2026.

Cause racine : l'ESP32-P4 n'a pas de radio à lui ; le WiFi vient du co-processeur ESP32-C6 en SDIO (esp32_hosted). Ce lien n'est pas remonté après le reboot logiciel de l'OTA. Le P4 réinitialise pourtant le C6 par GPIO 15 (esp32_hosted · reset_pin) à chaque démarrage, redémarrage logiciel compris : c'est le réglage par défaut d'ESP-Hosted (CONFIG_ESP_HOSTED_SLAVE_RESET_ON_EVERY_HOST_BOOTUP=y, reset actif haut, 1 500 ms, lu le 07/10/2026 dans le sdkconfig d'un build ESPHome 2026.9). Cause revue le 07/10/2026 : cette page disait qu'un reboot logiciel ne réinitialise pas le C6, ce qui est très probablement faux pour le build du 05/08/2026 aussi. Il venait d'ESPHome 2026.7 (version exacte non notée) ; les versions 2026.7.0 à 2026.7.3 demandent esp_hosted 2.12.9 sans choisir quand réinitialiser le C6, et le réglage par défaut d'esp_hosted 2.12.9 est le même. reset_pin: GPIO15 est dans Tab5/paquets/tab5-hardware.yaml depuis le premier commit. Le reboot de l'OTA a donc très probablement envoyé son impulsion de reset au C6 sans effacer la panne ; seule la coupure d'alimentation l'a fait. La cause exacte est inconnue. La console série (USB, port COM) tranche en quelques secondes :

[I][esp-idf:000]: E (93883) H_API: ESP-Hosted link not yet up
[W][wifi_esp32:300]: esp_wifi_set_mode failed: ESP_FAIL
[I][wifi:852]: Starting fallback AP

Ces trois lignes se répètent ~50 fois par seconde. L'écran noir est une conséquence, pas la panne : cette boucle chaude de reconnexion affame le reste du firmware, LVGL compris. Ne pas partir fouiller la pile d'affichage.

Correctif : une vraie coupure d'alimentation — débrancher l'USB-C pendant ~15 s, puis le rebrancher : sans batterie, la tablette redémarre seule. Sur la tablette de l'auteur, qui n'a pas de batterie, débrancher a suffi : l'appui long n'était pas nécessaire. Avec une batterie montée, débrancher ne coupe pas l'alimentation : éteindre aussi la tablette par un appui long. Un reboot logiciel ne suffit pas. Confirmé le 05/08/2026 : même binaire, écran noir après le reboot d'OTA, puis WiFi + API + dalle tous sains après la coupure, safe_mode: Boot seems successful. Le firmware n'était pas en cause (cette OTA ne changeait que des réglages audio).

Fréquence : une seule occurrence documentée (05/08/2026). Depuis le 30/09/2026, début de l'historique gardé par Home Assistant, la tablette de l'auteur a redémarré une cinquantaine de fois, des OTA pour la plupart, et le WiFi est revenu à chaque fois (relevé du 07/10/2026). La ligne ESP-Hosted link not yet up apparaît une fois à chaque démarrage normal et est sans conséquence : à 9 984 ms sur une capture série du 07/10/2026 (WiFi connecté ~17 s après le reset), à +6,9 s et +11,9 s dans le journal de Home Assistant. La panne, c'était cette ligne répétée ~50 fois par seconde.

Changement du firmware depuis le 16/10/2026, pas essayé sur un Tab5 : la Waveshare 7B, reliée à son C6 de la même façon, a montré une panne de la même famille, qu'un reset des CPU n'effaçait pas et qu'un reset de tout le cœur numérique effaçait (plus bas). Tout redémarrage logiciel du Tab5 (OTA, bouton, Home Assistant, mode sans échec, ESP-Hosted) finit maintenant par ce reset lui aussi (esp_rom_software_reset_system(), Tab5/ecran/tab5_lien_c6.cpp, chargé par Tab5/paquets/tab5-hardware.yaml) : la ligne du démarrage dit rst:0x3 (SW_SYS_RESET) au lieu de rst:0xc (SW_CPU_RESET), et « Raison du redémarrage » ne change pas. On ne sait pas s'il aurait évité la panne du 05/08/2026 : seulement compilé, la tablette de l'auteur étant en réparation. Si elle revient, une coupure reste le remède.

Pas essayé (une supposition) : puisqu'une impulsion de reset n'a très probablement pas suffi, couper puis remettre l'alimentation du C6 par logiciel (wifi_power, PI4IOE 0x44, P0, que le firmware ne fait qu'allumer au démarrage) pourrait rattraper la panne sans débrancher le câble. Rien ne le prouve.

Piège de diagnostic, appris le même jour : ouvrir et refermer le port série USB pour lire les logs peut réinitialiser la puce. Un reboot inexpliqué pile à la fin d'une session esphome logs --device COM<n>, c'est la session de logs elle-même, pas une instabilité. Une fois l'appareil revenu sur le WiFi, le surveiller via ses entités de diagnostic Home Assistant.

Waveshare 7B : boucle de redémarrages après un redémarrage logiciel, lien Wi-Fi absent (16/10/2026)¶

Symptôme : après un redémarrage depuis Home Assistant (« Redémarrage Système »), une OTA ou tout redémarrage logiciel, la carte redémarre toutes les ~17 s, n'atteint jamais le Wi-Fi, et au bout de 10 démarrages ESPHome passe en mode sans échec (écran figé). La redémarrer encore n'y change rien.

Ce que montre la console série (port COM de la carte, tools/capture_serie.py --mac …, sans reset) : chaque démarrage passe ESP-Hosted link not yet up (sans conséquence, écrit à chaque démarrage), puis les lectures SDIO du C6 partent en timeout et le P4 redémarre de lui-même, rst:0xc (SW_CPU_RESET), sans panique :

[I][esp-idf:000]: E (2513) H_API: ESP-Hosted link not yet up
[I][esp-idf:000][sdio_read]: E (11640) sdmmc_req: sdmmc_host_wait_for_event returned 0x107
[I][esp-idf:000][sdio_read]: E (14146) H_SDIO_DRV: sdio_read_task: Failed to read data - -1 838860 838860
...
rst:0xc (SW_CPU_RESET),boot:0xf (SPI_FAST_FLASH_BOOT)

Cause : l'état fautif est côté P4 et survit à esp_restart(), qui sur l'ESP32-P4 ne remet à zéro que les deux CPU (rst:0xc) : GPIO, périphériques et leurs réglages gardent leur état. Reproduit le 16/10/2026 sur la carte de l'auteur : la boucle est revenue au 8e redémarrage d'une série par l'API (et au 3e d'une série précédente) ; un reset par l'USB, qui remet à zéro tout le cœur numérique (« USB peripheral ») sans toucher au C6, a rendu le Wi-Fi aussitôt ; une coupure de courant aussi. Le C6 ne semble pas en cause : il est réinitialisé par le GPIO 54 à chaque démarrage et la courbe de courant (wattmètre USB, 100 mesures/s) le montre redémarrer à chaque fois, et la carte ne peut pas couper son alimentation par logiciel (le C6 partage le 3,3 V du P4). Quelle partie du P4 garde le mauvais état : pas établi.

Correctif (firmware) : tout redémarrage logiciel de la 7B finit par un reset de tout le cœur numérique (esp_rom_software_reset_system(), le reset du chargeur d'amorçage d'ESP-IDF) au lieu d'un reset des CPU : Tab5/ecran/tab5_lien_c6.cpp. ESP-IDF le rapporte toujours comme un redémarrage logiciel : « Raison du redémarrage » et le journal des démarrages ne changent pas. Vérifié sur la carte de l'auteur le 16/10/2026 : 20 redémarrages d'affilée par l'API, tous en rst:0x3 (SW_SYS_RESET), API revenue en 13,0 à 13,1 s, aucune erreur SDIO, raison « Reboot request from api » ; la même série avait bouclé au 8e redémarrage avant le correctif. Le Tab5 a le même reset depuis le même jour, pas essayé sur lui (plus haut).

Si ça arrive quand même : un reset par l'USB depuis un PC (esptool --port COM<n> --before default-reset --after hard-reset chip-id), ou débrancher la carte quelques secondes.

`Tab5 Uptime` bloqué à `unavailable` après la mise à jour vers le firmware à heure de démarrage (26/09/2026)¶

Symptôme : après le flash d'un firmware du 26/09/2026 ou plus récent par-dessus un plus ancien, toutes les entités reviennent sauf Tab5 Uptime, qui reste unavailable. Le journal de Home Assistant montre ValueError: Sensor sensor.…_tab5_uptime has a unit of measurement and thus indicating it has a numeric value; however, it has the non-numeric device class: timestamp.

Cause racine : Home Assistant, pas le firmware. Tab5 Uptime est passé de secondes (s) à une heure de démarrage sans unité, sous le même nom, donc la même entité. À la reconnexion, l'intégration ESPHome de HA met à jour l'entité existante sur place et ne recopie l'unité que si la nouvelle n'est pas vide (homeassistant/components/esphome/sensor.py, _on_static_info_update) : l'ancien s reste, et HA refuse d'écrire un état horodaté qui porte une unité.

Correctif : recharger une fois l'intégration ESPHome de l'appareil (Paramètres → Appareils et services → ESPHome → l'appareil → ⋮ → Recharger), ou redémarrer Home Assistant. L'entité est reconstruite depuis la description de l'appareil, sans unité. Fait le 26/09/2026 à 21:39.

Alerte de plantage après un appui sur le bouton d'alimentation (06/10/2026)¶

Symptôme : un appui court sur le bouton d'alimentation redémarre la tablette en ~10 s, puis Home Assistant envoie « Tab5 : journal du démarrage (plantage (chien de garde)) » sur le téléphone. Le journal ne contient que les lignes habituelles du démarrage (ESP-Hosted « not yet up », tactile, Wi-Fi qui s'associe), aucune ligne esp32.crash. En même temps, Tab5 Raison du redémarrage affiche Reboot request from esphome.ota, alors que la dernière mise à jour date de plusieurs heures. Signalé dans la discussion #278 (tablette avec batterie, 3.7.0-rc.2), reproduit le même jour sur une tablette alimentée par l'USB.

Cause racine : pas un plantage. Le firmware ne gère pas le bouton d'alimentation : c'est le matériel qui réinitialise la puce, et esp_reset_reason() lit ESP_RST_WDT, une raison que le journal comptait comme un plantage. Pour cette raison, le composant debug d'ESPHome affiche la source enregistrée par le dernier redémarrage demandé (components/debug/debug_esp32.cpp), qu'il n'efface jamais : un texte périmé.

Correctif (firmware après la 3.7.0-rc.3, et packages/tab5_health.yaml) : un reset du chien de garde sans rapport de plantage est un démarrage normal : « bouton d'alimentation ou chien de garde RTC (rst 0x..) » dans le journal, aucun événement envoyé ; Power button or RTC watchdog (rst 0x..) dans l'entité, que la garde « reboot inattendu » laisse passer. Mettre à jour le firmware ET les fichiers HA : avec le nouveau firmware seul, l'ancienne garde alerterait sur le nouveau texte. Un chien de garde avec rapport de plantage alerte toujours. Détail dans debugging.md.

Ajout de Tab5 dans HACS : « Dépôt introuvable », ou une boîte vide (07/10/2026)¶

Symptôme : l'ajout du dépôt dans HACS, par le lien « Ouvrir Tab5 dans HACS » ou par Custom repositories, échoue avec « Dépôt introuvable » (« Repository not found » en anglais). Ou la boîte que HACS ouvre par le lien n'affiche qu'un titre (« Confirmer ? »), sans texte.

Cause racine : HACS vérifie un dépôt sur sa dernière release complète, même avec les versions bêta activées, et seules les releases depuis la 3.7.0 portent l'intégration : avant la publication de la 3.7.0 (7 octobre 2026), HACS refusait ce dépôt (essayé ce jour-là, avec la 3.6.0 comme dernière release complète). La boîte vide vient de HACS : au premier chargement par le lien, ses textes ne sont pas encore chargés (vu avec HACS 2.0.5).

Correctif : « Dépôt introuvable » : vérifier sur la page des releases que la release marquée Latest est la 3.7.0 ou plus récente et, pour un ajout à la main, que le type est Integration ; puis réessayer. Boîte vide : recharger la page, la boîte revient avec ses textes, Ajouter à droite. Sans HACS, l'archive copiée à la main marche comme avant (parties A à C).

Intégration Tab5 (HACS) : un message dans Corrections¶

Symptôme : après une mise à jour de l'intégration « Tab5 — fichiers HA · HA files » et un redémarrage, Paramètres → Système → Corrections montre un message dont le titre commence par « Tab5 ».

Cause racine : au démarrage, l'intégration pose les fichiers de sa version, vérifie la configuration, recharge le YAML, puis vérifie que le capteur « Tab5 · version des fichiers HA » donne la nouvelle version (mises à jour). Quand une étape ne finit pas comme prévu, elle le dit dans Corrections.

Correctif, selon le message :

« Tab5 : aucun fichier Home Assistant dans l'intégration » : l'intégration a été copiée depuis le dépôt, qui a son code mais pas les fichiers. Installez-la par HACS (avec HACS), qui télécharge tab5_hacs.zip de la release, puis redémarrez.
« Tab5 : Home Assistant ne charge pas les packages » : les fichiers sont dans config/packages/, mais configuration.yaml n'a pas de ligne packages:. Ajoutez-la (partie B), vérifiez la configuration, puis redémarrez.
« Tab5 : redémarrez Home Assistant pour finir » : les fichiers sont en place, mais un rechargement n'a pas suffi (une partie qui ne se charge qu'au démarrage, un rechargement qui a échoué, ou une configuration qui avait déjà une erreur). Ouvrez le message et validez : l'intégration vérifie la configuration, puis redémarre Home Assistant. Si elle répond que la configuration a une erreur, corrigez-la d'abord (Outils de développement → YAML → Vérifier la configuration). Avec « Mettre ensuite la tablette à jour » coché, le firmware de cette version part après ce redémarrage, dès que l'entité « Firmware » de la tablette le propose.
« Tab5 : les fichiers X n'ont pas été installés » : la vérification de la configuration a trouvé une nouvelle erreur ou un nouvel avertissement avec les nouveaux fichiers, ou leur écriture a échoué. Les fichiers précédents ont été remis : rien n'a changé, et le firmware de cette version n'est pas lancé. La raison est dans le journal (Paramètres → Système → Journaux, cherchez « tab5 »). Si elle est dans un de vos propres fichiers, corrigez-le ; sinon, merci de la signaler (issues). Après une erreur de configuration, les mêmes fichiers ne sont pas réessayés à chaque démarrage de Home Assistant (le message revient, rien d'autre ne se passe) : une fois la cause corrigée, Paramètres → Appareils et services → Tab5 → Configurer, « Réinstaller maintenant les fichiers de cette version ». Une écriture ratée (disque plein…) est réessayée au démarrage suivant.
« Tab5 : des fichiers déjà là ont été remplacés » : des fichiers du Tab5 étaient déjà dans config/ sans venir de l'intégration (copiés à la main depuis une archive, sans doute) et différaient de ceux de la release. Ils ont été remplacés quand même ; le message les liste et nomme le dossier de sauvegarde qui garde les anciens. Si vous en aviez modifié un exprès, recopiez votre changement depuis là, puis validez le message pour le fermer.
« Tab5 : la tablette n'est pas passée en X » : avec « Mettre ensuite la tablette à jour » coché, l'intégration a lancé la mise à jour du firmware 3 fois, à 15 minutes d'écart, et la tablette tourne toujours une autre version (mise à jour ratée sur la tablette, ou tablette éteinte ou déconnectée). Installez-la à la main : Paramètres → Mises à jour, ou l'entité « Firmware » de la tablette → Installer, tablette allumée et connectée. Le message disparaît dès que la tablette tourne cette version.

Pour revenir à la main à des fichiers plus anciens : remettre des fichiers plus anciens.

Home Assistant ne se reconnecte plus après une réinstallation avec effacement (19/10/2026)¶

Symptôme : une tablette ou une Waveshare 7B que Home Assistant connaissait déjà est réinstallée depuis la page d'installation avec effacement (« Erase device » coché après Install, ou « Erase User Data »). Elle démarre et rejoint le Wi-Fi une fois celui-ci redonné, mais reste indisponible dans Home Assistant, même après un redémarrage de la tablette. Paramètres → Appareils et services la montre en haut, sous « Découvertes », cadre rouge et bouton Reconfigurer ; Paramètres → Système → Corrections dit « L'authentification a expiré pour M5Stack Tab5 Home Assistant HMI ». Vu sur la 7B de l'auteur le 19/10/2026 (3.9.0-rc.6 installée depuis la page).

Cause racine : l'effacement vide la mémoire de la tablette (NVS) : la clé API que Home Assistant lui avait donnée, son Wi-Fi et les réglages de l'écran (thème, réveil, luminosité…). Home Assistant garde la clé et l'essaie ; la tablette, sans clé, la refuse. Home Assistant ouvre alors une réauthentification à l'étape reauth_encryption_removed_confirm (la tablette répond sans chiffrement alors que son entrée a une clé : homeassistant/components/esphome/config_flow.py, async_step_reauth) et ne se reconnecte plus tant qu'elle attend. La page d'installation propose l'effacement à toute Install : son manifeste porte new_install_prompt_erase: true, et ESP Web Tools 10.4.0 demande alors « Erase device » (case décochée) ; Update n'efface jamais. Le guide d'installation disait jusqu'ici qu'une tablette que Home Assistant connaît reçoit une nouvelle clé toute seule (un essai, le 28/09/2026) : le test d'installation à neuf montre que Home Assistant attend une confirmation, pareil avec Home Assistant 2026.8.3, 2026.9.4 et 2026.10.2.

Correctif, dans Home Assistant (ce que fait le test d'installation à neuf, tools/installation_ha/verifier_installation.py) :

Dans les 30 minutes qui suivent le démarrage de la tablette (sa fenêtre d'appairage) : Paramètres → Appareils et services, la carte de la tablette sous « Découvertes » → Reconfigurer. La boîte dit que l'appareil « a désactivé le chiffrement du transport » et demande de confirmer la suppression de « la clé de chiffrement » pour « autoriser les connexions non chiffrées » : Valider. Malgré ces mots, la tablette ne reste pas sans chiffrement. Fermer la boîte sans Valider ne change rien : la carte reste.
Home Assistant redonne à la tablette la clé qu'il gardait, la même, et se reconnecte avec, en quelques secondes (moins de 7 s dans le test). Entités, automatisations et historique ne changent pas ; la correction disparaît.
Remettez les réglages de l'écran depuis la page de l'appareil de la tablette (réglages) : leurs anciennes valeurs sont dans l'historique de chaque entité.

Plus de 30 minutes depuis le démarrage de la tablette : redémarrez-la d'abord (un appui court sur reset, ou débranchez-la), puis Reconfigurer.

Recharger (Paramètres → Appareils et services → ESPHome → la tablette → ⋮ → Recharger) abandonne la réauthentification qui attend, et Home Assistant en ouvre une nouvelle, à la même étape, tant que la fenêtre est ouverte (vérifié par le test). C'est le recours si la boîte demande une clé de chiffrement à la place, ce qui arrive, d'après le code de Home Assistant (pas essayé), quand il a ouvert la réauthentification pendant que la fenêtre de la tablette était fermée : redémarrez la tablette, puis Recharger, puis Reconfigurer.

Sans l'interface, depuis un PC qui voit le partage config de Home Assistant : dans la fenêtre, python tools/tab5_redonner_cle.py --host <IP de la tablette> --config-ha \\<IP de HA>\config redonne à la tablette la clé que garde Home Assistant (lue dans .storage/core.config_entries, jamais affichée) ; puis Recharger l'entrée ESPHome de la tablette, et Home Assistant se reconnecte (moins de 3 s dans le test). C'est ainsi que la 7B de l'auteur a été réparée le 19/10/2026.

Pour l'éviter : sur une tablette que Home Assistant connaît, Update ; si la page propose Install, laissez « Erase device » décoché.

Léger souffle continu, sur une tablette sans batterie (08/10/2026)¶

Symptôme : un très léger souffle, continu, sort de la tablette. Couper le micro ou baisser le volume n'y change rien. Entendu sur la tablette de l'auteur, qui n'a pas de batterie et tourne sur un port USB de PC.

Ce que ce n'est pas (essayé l'un après l'autre depuis Home Assistant, le 08/10/2026) :

l'ampli du haut-parleur : « Speaker Enable » coupé, souffle inchangé ;
le rétroéclairage : luminosité à 100 %, où sa PWM à 1 kHz ne hache plus, souffle inchangé (ce changement a coïncidé avec un redémarrage par sous-tension à 09:42, sur un port USB de PC ; cause non prouvée) ;
le micro : coupé, souffle inchangé.

Cause racine : le chargeur de la batterie. Depuis la 3.6.0 (PR #303, 04/10/2026), le firmware met CHG_EN (PI4IOE 0x44 P7) à 1 à chaque démarrage. Sans batterie, le chargeur charge dans le vide : la tension lue par l'INA226 oscille entre 4,2 et 8,39 V, ou reste vers 5,70-5,76 V, et « Tab5 Batterie en charge » dit oui. Avec un firmware d'essai qui exposait CHG_EN, couper le chargeur a fait disparaître le souffle ; l'INA226 lisait alors 1,83 à 1,94 V (quatre lectures, de 09:55 à 09:58) et l'état de charge est passé à « pas en charge ». Une observation de plus, une seule : pendant les 2 minutes où la tension lue était à 8,39 V, on n'entendait plus le souffle ; il est revenu avec les 5,70 V.

Correctif (prochaine version) : le firmware cherche la batterie chargeur coupé, et laisse le chargeur coupé quand il n'y en a pas : plus de souffle, plus de faux « en charge ». Depuis le 10/10/2026, il ne l'allume même plus pendant le démarrage quand le démarrage précédent n'a vu aucune batterie. Comment il décide : batterie.

Contournement de la 3.6.0 à la dernière version publiée : aucun de simple, désolé. Ces versions n'ont pas d'entité pour couper le chargeur, et le haut-parleur, le micro ou le volume n'y sont pour rien. Une batterie montée donne au chargeur quelque chose à charger (on n'a pas vérifié si une tablette avec batterie souffle aussi). Sinon, attendre la prochaine version.

La compilation échoue avec ESPHome 2026.10.0 : « was not declared in this scope » (21/10/2026)¶

Symptôme : vous compilez le firmware vous-même avec ESPHome 2026.10.0, et la compilation s'arrête sur main.cpp avec des erreurs comme 'journal_reset_reason' was not declared in this scope, 'tr' was not declared in this scope ou 'g_alarm_cfg' was not declared in this scope (13 erreurs sur main, le 21/10/2026). Le même commit compile avec la 2026.9.x. Le firmware publié n'est pas touché : il est compilé avec une version d'ESPHome figée (ESPHOME_PUBLICATION dans .github/workflows/publication.yml), pas avec la dernière.

Cause racine : un changement d'ESPHome 2026.10.0, signalé dans esphome/esphome#21303. Deux sortes de valeurs !lambda sont maintenant écrites dans main.cpp avant les #include des fichiers de esphome: includes:, et ne voient donc ni les fonctions, ni les constantes, ni les variables globales C++ du firmware :

les champs data: d'un homeassistant.event, rangés désormais dans une table en flash (esphome/esphome#20237) ;
la valeur d'une action ou d'une condition « apply » (select.set_index, rtttl.play, media_player.volume_set, globals.set…), devenue une fonction statique.

Une action lambda: ordinaire reste écrite dans setup(), après les inclusions, et n'est pas touchée. Preuve : le même main.cpp généré avec la 2026.9.0 et la 2026.10.0 (esphome compile --only-generate), sur ce firmware et sur une config minimale hors du dépôt.

Correctif (prochaine version, #535) : ces valeurs ne nomment plus que des paramètres, des id(…) et la bibliothèque standard. Le journal de démarrage et l'annonce « Volet arrêté. » envoient leur événement depuis un script à paramètres, appelé par une lambda: ; le réveil choisit sa mélodie, joue sa sonnerie et règle son volume depuis une lambda:. Mêmes événements, mêmes champs ; le firmware compile avec la 2026.9 et la 2026.10. tests/test_includes_esphome.py échoue si une telle valeur nomme de nouveau notre C++ (règle de code 10, Tab5/README.md).

Contournement avant cette version : compiler avec ESPHome 2026.9.x (pip install esphome==2026.9.1), ou avec le Device Builder en 2026.9.x.

Faux positifs à connaître (ne pas re-"corriger")¶

Pagination prévisions sans bouclage : intentionnel (0↔4), déjà "corrigé à tort" une fois par un audit LLM puis reverté. Voir docs/decisions/.
Entité cover à unknown côté HA : peut être réel côté HA sans affecter le firmware si la carte concernée pilote son propre état via des globals + un script plutôt que de lire cette entité.
Tab5 Uptime décalé d'environ une minute par rapport au vrai reboot : pas un problème d'horloge. L'état d'un capteur ESPHome est un float 32 bits, qui arrondit un horodatage Unix au multiple de 128 s le plus proche (±64 s). La garde de packages/tab5_health.yaml prévoit 5 min de marge pour cela.
"Chevauchement" tactile signalé par un audit statique : vérifier la géométrie pixel réelle avant de faire confiance au rapport — un cas signalé était décalé d'une douzaine de pixels, pas un vrai chevauchement.