Troubleshooting — incidents already diagnosed¶

This is a log of real symptoms hit on this exact device/firmware, with the confirmed root cause and fix. Check here before re-diagnosing something that looks familiar — several of these took hours of live debugging with the device on a desk. If you're an AI agent auditing this code, several of these look like bugs at first glance; they are documented here precisely because they were already investigated and closed.

Format: Symptom → Root cause → Fix. Entries are chronological, most recent last within each topic isn't guaranteed — read the whole thing, it's short.

Black screen after a software reboot (not a power cycle)¶

Symptom: device reboots (OTA, crash, api.reboot), display stays black afterward. A power cycle (unplug/replug) fixes it; a soft reboot alone does not, or does so unreliably.

Root cause: the display's reset_pin is wired through the PI4IOE5V6408 I2C GPIO expander, not a native ESP32 GPIO. Right after boot, the expander itself needs a short settle time before it reliably drives its output pins — toggling reset_pin too early is a no-op from the display's point of view.

Fix: a blocking delay(1000) was added in on_boot: priority: 700 in tab5-hardware.yaml, right before the display reset sequence. Confirmed root cause on 2026-07-06 after 5 live reboot tests with the developer watching the screen. This is marked [AI-WARNING] in the file — do not remove this delay to "optimize boot time" without re-testing across several reboots; a previous permissive logger: level: VERY_VERBOSE workaround (kept for weeks as a correlation-only mitigation) was replaced by this confirmed fix. Since 2026-10-17 the length comes from the board (carte_attente_ecran_ms, ADR-0005): 1 s on the Tab5, none on the Waveshare 7B, whose display reset is a pin of the P4 itself.

Weather / planning / climate data missing, but the device is online¶

Symptom: the device shows a healthy Wi-Fi/API connection (diagnostics entities look fine, uptime climbing), but the weather, planning, and forecast cards never update — while the clock and a couple of directly-mirrored sensors keep working, which makes the failure look partial and confusing.

Root cause: the push automations on the Home Assistant side are all gated behind one shared condition: state on a boolean helper (a "which HA instance is the active one" flag, relevant only in a dual-instance setup). That helper was stuck off; a guard automation meant to force it back on at every HA boot was itself disabled, so even a full HA restart didn't self-heal.

Fix: turn the helper back on, re-enable the guard automation, manually trigger the push automation once. If your setup pushes conditionally on a shared state flag, make sure the automation that's supposed to re-arm it on boot is actually enabled — an automation that silently no-ops because its own guard is off is easy to miss for a long time (in this case, ~3 hours before being noticed).

Since 3.8 the flag (input_boolean.is_primary_active), the automation that re-armed it and its health guard are gone: no push depends on a shared flag any more. This incident can no longer happen with the current packages; if the screen still looks frozen, use « MAJ Écran » and check that the push automations are on.

STT/TTS broken, dozens of "entity already exists — ignoring" log lines¶

Symptom: voice pipeline reports a missing/broken speech-to-text provider despite the underlying service responding correctly when tested directly. Home Assistant logs show many does not generate unique IDs ... already exists - ignoring warnings across automation/sensor/climate/calendar entities.

Root cause: a remote_homeassistant-style integration was mirroring an entire second Home Assistant instance's entities into this one. ID collisions silently shadowed the real STT/TTS entities the voice pipeline depended on. This only reproduces in a dual Home Assistant instance setup — not relevant if you run a single HA instance.

Fix: disable the mirroring integration, full HA restart. If you don't run two HA instances feeding into each other, this can't happen to you.

Touch "not working" but the touchscreen is actually detecting presses fine¶

Symptom: tapping the screen does nothing; looks like a dead touch controller.

Root cause: Home Assistant was rejecting the device's service calls (Service call ... rejected; ... enable this functionality in the options flow) — the touch events were reaching HA, HA just refused to act on them.

Fix: enable "Allow service calls" in the ESPHome integration's options flow for this device in Home Assistant. Check this before assuming a hardware/firmware touch bug.

Since ADR-0025 (after 3.1) the firmware calls no action at all, so this rejection cannot happen any more: the screen's commands and requests are events. The same symptom on a recent firmware means their consumer is missing — the blueprint « Tab5 — emplacements » for the tiles, packages/tab5_evenements.yaml for the calendar, announcements and system console.

A calendar/weather push silently breaks the rest of the same automation¶

Symptom: after fixing the two issues above, planning/weather/climate were still not showing up on screen — a distinct bug from the ones above.

Root cause: the automation called calendar.get_events with start_date_time: "{{ now() }}" — a raw Jinja now() datetime object including microseconds, which Home Assistant's schema silently rejected. Because the calendar call was one step among several sequential actions in the same automation, the validation failure aborted everything after it — including unrelated weather and forecast pushes further down the same automation.

Fix: format the datetime explicitly: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}". More broadly: add continue_on_error: true on individual push actions (calendar, each weather.get_forecasts call, each screen-push service call) so one bad payload doesn't take down unrelated pushes later in the same automation, plus is defined guards on any template variable consumed downstream.

Daily weather icons gone, hourly forecast fine, automation reports success (2026-09-18)¶

Symptom: the five daily forecast cards lost their weather icons (and kept stale data after a reboot) while the hourly cards kept updating. Home Assistant had all the data: the weather entity was fine and weather.get_forecasts returned 15 daily and 67 hourly entries. The push automation showed no error.

Root cause: the tab5_maj_previsions_jours_bulk payload template looped over range(15) and read fcasts[i].templow directly. Météo-France stopped sending templow for the 15th day (D+14): the key is simply absent from that dict. In Jinja, dict.missing_key raises UndefinedError before | float(0) can apply, so the payload was never rendered and the service never called. The hourly cards use another call (previsions_heures_bulk), which is why they kept working. continue_on_error: true on the action is what hid it: HA only logged Error rendering data template: UndefinedError: 'dict object' has no attribute 'templow'.

Fix: guarded access everywhere a forecast attribute is read: fcasts[i].get('templow') | float(0), same for condition, temperature and (hourly) precipitation. Applied to production on 2026-09-18 and mirrored into the public example on 2026-09-25 (now packages/tab5_push.yaml, the single source since 2026-09-26).

How to spot the next one: - Read the automation trace and compare the list of services actually called with the expected ones. A missing …_bulk call stands out even though the run is "successful". - Guard (d) of HomeAssistant_Config/packages/tab5_health.yaml (tab5_health_template_error) raises an alert on Error rendering data template. It needs system_log: fire_event: true in configuration.yaml, otherwise it loads but never fires. - To force a full push after a fix, use the MAJ Écran button of the device's system console (automation.trigger skips the conditions) or Run actions in HA. Firing esphome.tab5_connected by hand no longer works since 2026-09-25: that trigger only pushes when the API link came up less than 3 min ago.

ESPHome `pressed:` style rejected when placed in a shared `style_definitions`¶

Symptom: esphome compile fails with [pressed] is an invalid option for [style_definitions] after trying to centralize a button's pressed-state styling.

Root cause: confirmed by reading ESPHome's own LVGL component source (defines.py / widgets/__init__.py / styles.py) rather than guessing — the pressed: state key is only valid on the widget itself, not inside a reusable style_definitions: block.

Fix: keep the pressed properties out of style_definitions, but share them anyway: put them in a normal style and reference it from the widget with pressed: { styles: style_x }. ESPHome accepts that form on a widget and generates lv_obj_add_style(obj, style_x, LV_STATE_PRESSED) (verified in schemas.py / widgets/__init__.py of ESPHome 2026.9, 2026-09-26). The earlier advice "repeat the block on every button, it cannot be shared" was wrong.

Related: press/release no longer animate. The default LVGL theme used to fade every button over 80 ms, plus a 70 ms delay on release. -DLV_THEME_DEFAULT_TRANSITION_TIME=0 (build_flags in tab5-ha-hmi.yaml) removes those transitions (a CONFIG_LV_* line in the sdkconfig has no effect: ESPHome builds LVGL with LV_KCONFIG_IGNORE; the first attempt, on 2026-09-26, went there and never applied), and the project's own pressed style (tab5_anim.cpp, 94 % scale) is applied instantly.

ESPHome API connections exhausted (device drops connections under otherwise normal use)¶

Symptom: device intermittently fails to accept new API connections (from HA, from esphome logs, from OTA) for no obvious reason.

Root cause: the ESPHome native API only allows a small, fixed number of simultaneous connections (8). Leftover esphome CLI processes from earlier debugging sessions (e.g. esphome logs left running in a forgotten terminal) each hold one connection open indefinitely.

Fix: close CLI sessions when you're done with them; if connections seem exhausted, check for and kill orphaned local esphome processes before assuming a device-side bug.

Device reboots on its own every ~15–20 min while Home Assistant is unreachable¶

Symptom: Home Assistant is down (or slow to start), the Tab5 is still on Wi-Fi and shows its last known state, yet it reboots by itself roughly every 15–20 minutes. Nothing in the logs looks like a crash: each boot is clean and safe_mode reports Boot seems successful.

Root cause: not a crash — api: reboot_timeout: in tab5-api-logic.yaml. ESPHome reboots the device when no API client has been connected for that long, and the counter restarts on every connection, even a brief one. With the original 15 min, an HA server that takes a while to come up produces a reboot cycle slightly longer than the timeout itself (timeout + boot + reconnection attempts). The wifi: component has its own separate reboot_timeout, which is not involved here since Wi-Fi was fine.

Fix: raised to 60min on 2026-08-01 — an hour-long HA outage or maintenance window no longer cycles the tablet, which stays useful without HA (clock, arcade, diagnostics console, last known weather), while the anti-"zombie" safety net from audit F-04 is kept. Do not set it to 0s without re-reading that audit: a frozen API stack would then leave the device online but mute until someone power-cycles it.

Black screen + device off the network after an OTA — the Wi-Fi co-processor never came up¶

Symptom: an OTA reports OTA successful, the device reboots, and then: black screen, no Home Assistant entities, no API (esphome logs --device <ip> times out on port 6053). Rebooting it again changes nothing. Confusingly, the IP still answers ping — that is a different device that picked up the lease, exactly like the 2026-08-01 DHCP mix-up.

Root cause: the ESP32-P4 has no radio of its own; Wi-Fi comes from the ESP32-C6 co-processor over SDIO (esp32_hosted). That link failed to come up after the OTA's software reboot. The P4 does reset the C6 through GPIO 15 (esp32_hosted · reset_pin) on every boot, software reboots included: that is ESP-Hosted's default setting (CONFIG_ESP_HOSTED_SLAVE_RESET_ON_EVERY_HOST_BOOTUP=y, active-high reset, 1,500 ms, read on 2026-10-07 in the sdkconfig of an ESPHome 2026.9 build). Cause reviewed on 2026-10-07: this page used to say that a software reboot does not reset the C6, which is very probably wrong for the 2026-08-05 build too. That build came from ESPHome 2026.7 (exact release not recorded); releases 2026.7.0 to 2026.7.3 ask for esp_hosted 2.12.9 without choosing when to reset the C6, and esp_hosted 2.12.9 has the same default. reset_pin: GPIO15 has been in Tab5/paquets/tab5-hardware.yaml since the first commit. So the OTA reboot very probably did send its reset pulse to the C6, and that did not clear the fault; only cutting the power did. The exact cause is unknown. Serial console (USB, COM port) makes it unambiguous in seconds:

[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

Those three lines repeat ~50 times per second. The black screen is a consequence, not the fault: that hot retry loop starves the rest of the firmware, LVGL included. Do not go looking at the display stack.

Fix: a full power cycle — unplug USB-C for ~15 s, then plug it back in: without a battery, the tablet starts again by itself. On the author's tablet, which has no battery, unplugging was enough: the long-press was not needed. With a battery fitted, unplugging does not cut the power: also switch the tablet off with a long-press. A soft reboot will not do it. Confirmed on 2026-08-05: same binary, black screen after the OTA reboot, then Wi-Fi + API + display all healthy after the power cycle, safe_mode: Boot seems successful. The firmware was not at fault (that OTA only changed audio settings).

How often: a single documented occurrence (2026-08-05). Since 2026-09-30, when the history kept by Home Assistant begins, the author's tablet has restarted about fifty times, most of them OTAs, and Wi-Fi came back every time (count of 2026-10-07). The line ESP-Hosted link not yet up shows up once on every normal boot and is harmless: at 9,984 ms in a serial capture of 2026-10-07 (Wi-Fi connected ~17 s after the reset), at +6.9 s and +11.9 s in Home Assistant's log. The fault was that line repeated ~50 times per second.

Firmware change since 2026-10-16, not tested on a Tab5: the Waveshare 7B, wired to its C6 the same way, showed a fault of the same family that a reset of the CPU cores did not clear and a reset of the whole digital core did (below). Every software reboot of the Tab5 (OTA, button, Home Assistant, safe mode, ESP-Hosted) now ends with that reset too (esp_rom_software_reset_system(), Tab5/ecran/tab5_lien_c6.cpp, loaded by Tab5/paquets/tab5-hardware.yaml): the boot line reads rst:0x3 (SW_SYS_RESET) instead of rst:0xc (SW_CPU_RESET), and « Raison du redémarrage » does not change. Whether it would have avoided the 2026-08-05 outage is not known: built only, the author's tablet being away for repair. If it happens again, a power cut is still the fix.

Not tried (a guess): since a reset pulse was very probably not enough, cutting the C6's power in software and restoring it (wifi_power, PI4IOE 0x44, P0, which the firmware only switches on at boot) might recover from the fault without pulling the cable. Nothing proves it.

Diagnostic trap, learned the same day: opening and closing the USB serial port to read logs can reset the chip. An unexplained reboot right at the end of an esphome logs --device COM<n> session is the log session itself, not an instability. Once the device is back on Wi-Fi, watch it through its Home Assistant diagnostic entities instead.

Waveshare 7B: boot loop after a software reboot, Wi-Fi link down (2026-10-16)¶

Symptom: after a reboot from Home Assistant (« Redémarrage Système »), an OTA or any software reboot, the board restarts every ~17 s, never reaches Wi-Fi, and after 10 boots ESPHome enters safe mode (frozen screen). Rebooting again does not help.

What the serial console shows (COM port of the board, tools/capture_serie.py --mac …, no reset): each boot gets past ESP-Hosted link not yet up (harmless, printed on every boot), then the SDIO reads from the C6 time out and the P4 restarts by itself, rst:0xc (SW_CPU_RESET), with no panic:

[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: the faulty state is on the P4 side and survives esp_restart(), which on the ESP32-P4 only resets the two CPU cores (rst:0xc): GPIO, peripherals and their configuration keep their state. Reproduced on 2026-10-16 on the author's board: the loop came back on the 8th reboot of a series through the API (and on the 3rd of an earlier series); a reset over USB, which is a reset of the whole digital core (« USB peripheral ») and does not touch the C6, brought Wi-Fi back at once; so does a power cut. The C6 does not look at fault: it is reset by GPIO 54 on every boot and the current curve (USB meter, 100 samples/s) shows it restarting each time, and the board cannot cut its power in software (the C6 shares the 3.3 V rail of the P4). Which part of the P4 keeps the bad state is not established.

Fix (firmware): every software reboot of the 7B ends with a reset of the whole digital core (esp_rom_software_reset_system(), the reset ESP-IDF's bootloader uses) instead of a CPU reset: Tab5/ecran/tab5_lien_c6.cpp. ESP-IDF still reports it as a software reboot, so « Raison du redémarrage » and the boot journal do not change. Checked on the author's board on 2026-10-16: 20 reboots in a row through the API, every one rst:0x3 (SW_SYS_RESET), API back in 13.0 to 13.1 s, no SDIO error, reported as « Reboot request from api »; the same series had looped on the 8th reboot before the fix. The Tab5 gets the same reset since the same day, not tested there (above).

If it happens anyway: a reset over USB from a PC (esptool --port COM<n> --before default-reset --after hard-reset chip-id), or unplugging the board for a few seconds.

`Tab5 Uptime` stuck at `unavailable` after the update to the boot-time firmware (2026-09-26)¶

Symptom: after flashing a firmware from 2026-09-26 or later over an older one, every entity comes back except Tab5 Uptime, which stays unavailable. The Home Assistant log shows 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.

Root cause: Home Assistant, not the firmware. Tab5 Uptime changed from seconds (s) to a boot timestamp without a unit, under the same name, so the same entity. On reconnection, HA's ESPHome integration updates the existing entity in place and only copies the unit when the new one is not empty (homeassistant/components/esphome/sensor.py, _on_static_info_update): the old s sticks, and HA refuses to write a timestamp state that carries a unit.

Fix: reload the ESPHome integration of the device once (Settings → Devices & services → ESPHome → the device → ⋮ → Reload), or restart Home Assistant. The entity is rebuilt from the device's description, without a unit. Done on 2026-09-26 at 21:39.

Crash alert after a press on the power button (2026-10-06)¶

Symptom: a short press on the power button reboots the tablet in about 10 s, then Home Assistant sends « Tab5 : journal du démarrage (plantage (chien de garde)) » to the phone. The journal has only the usual boot lines (ESP-Hosted « not yet up », touch polling, Wi-Fi associating), no esp32.crash line. Meanwhile Tab5 Raison du redémarrage shows Reboot request from esphome.ota, although the last update was hours earlier. Reported in discussion #278 (tablet with a battery, 3.7.0-rc.2), reproduced the same day on a tablet powered by USB.

Root cause: not a crash. The firmware does not handle the power button: the hardware resets the chip, and esp_reset_reason() reads ESP_RST_WDT, a reason the journal counted as a crash. ESPHome's debug component, for that reason, shows the source stored by the last requested reboot (components/debug/debug_esp32.cpp), which it never clears: a stale text.

Fix (firmware after 3.7.0-rc.3, and packages/tab5_health.yaml): a watchdog reset with no crash report is now a normal boot: « bouton d'alimentation ou chien de garde RTC (rst 0x..) » in the journal, no event sent; Power button or RTC watchdog (rst 0x..) in the entity, which the « reboot inattendu » guard lets through. Update both the firmware and the HA files: with only the new firmware, the old guard would alert on the new text. A watchdog reset with a crash report still alerts. Details in debugging.md.

Adding Tab5 to HACS: « Repository not found », or an empty box (2026-10-07)¶

Symptom: adding the repository to HACS, by the « Open Tab5 in HACS » link or by Custom repositories, fails with « Repository not found » (« Dépôt introuvable » in French). Or the box that HACS opens through the link shows a title only (« Confirm? »), with no text.

Root cause: HACS checks a repository on its latest full release, even with beta versions switched on, and only the releases from 3.7.0 on carry the integration: before 3.7.0 was published (7 October 2026), HACS refused this repository (tried that day with 3.6.0 as the latest full release). The empty box comes from HACS: on a first load through the link, its texts are not loaded yet (seen with HACS 2.0.5).

Fix: « Repository not found »: check on the releases page that the release marked Latest is 3.7.0 or later, and, when adding it by hand, that the type is Integration; then try again. Empty box: reload the page, the box comes back with its texts, Add on the right. Without HACS, the archive copied by hand works as before (parts A to C).

Tab5 integration (HACS): a message in Repairs¶

Symptom: after an update of the « Tab5 — fichiers HA · HA files » integration and a restart, Settings → System → Repairs shows a message whose title starts with « Tab5 ».

Root cause: at start, the integration puts the files of its version in place, checks the configuration, reloads the YAML, then checks that the sensor « Tab5 · version des fichiers HA » shows the new version (updates). When a step does not end as expected, it says so in Repairs.

Fix, by message:

« Tab5: no Home Assistant files in the integration »: the integration was copied from the repository, which holds its code but not the files. Install it through HACS (with HACS), which downloads tab5_hacs.zip from the release, then restart.
« Tab5: Home Assistant does not load the packages »: the files are in config/packages/, but configuration.yaml has no packages: line. Add it (part B), check the configuration, then restart.
« Tab5: restart Home Assistant to finish »: the files are in place, but a reload was not enough (a part that only loads at start, a reload that failed, or a configuration that already had an error). Open the message and submit: the integration checks the configuration, then restarts Home Assistant. If it answers that the configuration has an error, fix it first (Developer tools → YAML → Check configuration). With « Then update the tablet » ticked, the firmware of this version starts after this restart, once the tablet's « Firmware » entity offers it.
« Tab5: the files X were not installed »: the configuration check found a new error or warning with the new files, or writing them failed. The previous files were put back: nothing changed, and the firmware of this version is not started. The reason is in the log (Settings → System → Logs, search « tab5 »). If it is in one of your own files, fix it; otherwise please report it (issues). After a configuration error, the same files are not tried again at each start of Home Assistant (the message comes back, nothing else happens): once the cause is fixed, Settings → Devices & services → Tab5 → Configure, « Install the files of this version again now ». A write failure (disk full…) is tried again at the next start.
« Tab5: files already there were replaced »: some Tab5 files were already in config/ without coming from the integration (copied by hand from an archive, most likely) and differed from those of the release. They were replaced anyway; the message lists them and names the backup folder that holds the old ones. If you had changed one on purpose, copy your change back from there, then submit the message to close it.
« Tab5: the tablet did not update to X »: with « Then update the tablet » ticked, the integration started the firmware update 3 times, 15 minutes apart, and the tablet still runs another version (an update that failed on the tablet, or a tablet off or disconnected). Install it by hand: Settings → Updates, or the tablet's « Firmware » entity → Install, tablet on and connected. The message goes away once the tablet runs that version.

To go back to older files by hand: putting older files back.

Home Assistant no longer connects after a reinstall with erase (2026-10-19)¶

Symptom: a tablet or a Waveshare 7B that Home Assistant already knew is installed again from the install page with an erase (« Erase device » ticked after Install, or « Erase User Data »). It starts and joins the Wi-Fi once you set it again, but stays unavailable in Home Assistant, even after a restart of the tablet. Settings → Devices & services shows it at the top, under « Discovered », with a red border and a Reconfigure button; Settings → System → Repairs says « Authentication expired for M5Stack Tab5 Home Assistant HMI ». Seen on the author's 7B on 2026-10-19 (3.9.0-rc.6 installed from the page).

Root cause: the erase empties the tablet's memory (NVS): the API key Home Assistant gave it, its Wi-Fi and its screen settings (theme, alarm clock, brightness…). Home Assistant still holds the key and tries it; the tablet, without a key, refuses it. Home Assistant then opens a re-authentication at the step reauth_encryption_removed_confirm (the tablet answers without encryption while its entry has a key: homeassistant/components/esphome/config_flow.py, async_step_reauth) and stops reconnecting while it waits. The install page offers the erase on every Install: its manifest sets new_install_prompt_erase: true, and ESP Web Tools 10.4.0 then asks « Erase device » (box unticked); Update never erases. Until now, the installation guide said that a tablet Home Assistant knows gets a new key by itself (one try, on 2026-09-28): the fresh-install test shows that Home Assistant waits for a confirmation, the same with Home Assistant 2026.8.3, 2026.9.4 and 2026.10.2.

Fix, in Home Assistant (what the fresh-install test does, tools/installation_ha/verifier_installation.py):

Within 30 minutes of the tablet's start (its pairing window): Settings → Devices & services, the tablet's card under « Discovered » → Reconfigure. The box says the device « disabled transport encryption » and asks to confirm that you want to « remove the encryption key and allow unencrypted connections »: Submit. Despite these words, the tablet does not stay unencrypted. Closing the box without Submit changes nothing: the card stays.
Home Assistant gives the tablet back the key it kept, the same one, and reconnects with it, in a few seconds (under 7 s in the test). Entities, automations and history do not change; the repair goes away.
Put the screen settings back from the tablet's device page (settings): their former values are in the history of each entity.

More than 30 minutes since the tablet's start: restart it first (a short press on reset, or unplug it), then Reconfigure.

Reload (Settings → Devices & services → ESPHome → the tablet → ⋮ → Reload) drops the waiting re-authentication, and Home Assistant opens a new one, at the same step, while the window is open (checked by the test). It is the way out if the box asks for an encryption key instead, which happens, from Home Assistant's code (not tried), when Home Assistant opened the re-authentication while the tablet's window was closed: restart the tablet, then Reload, then Reconfigure.

Without the interface, from a PC that reaches Home Assistant's config share: within the window, python tools/tab5_redonner_cle.py --host <tablet IP> --config-ha \\<HA IP>\config gives the tablet the key Home Assistant keeps (read in .storage/core.config_entries, never printed); then Reload the tablet's ESPHome entry, and Home Assistant reconnects (under 3 s in the test). That is how the author's 7B was repaired on 2026-10-19.

To avoid it: on a tablet Home Assistant knows, Update; if the page offers Install, leave « Erase device » unticked.

Faint continuous hiss, on a tablet without a battery (2026-10-08)¶

Symptom: a very faint, continuous hiss from the tablet. Muting the microphone or turning the volume down changes nothing. Heard on the author's tablet, which has no battery and runs on a PC's USB port.

What it is not (tried one after the other from Home Assistant, on 2026-10-08):

the speaker amplifier: « Speaker Enable » off, hiss unchanged;
the backlight: brightness at 100 %, where its 1 kHz PWM no longer chops, hiss unchanged (that change coincided with a brownout reboot at 09:42, on a PC's USB port; cause not proven);
the microphone: muted, hiss unchanged.

Root cause: the battery charger. Since 3.6.0 (PR #303, 2026-10-04), the firmware sets CHG_EN (PI4IOE 0x44 P7) to 1 at every boot. Without a battery, the charger charges into nothing: the voltage read by the INA226 swings between 4.2 and 8.39 V, or stays around 5.70–5.76 V, and « Tab5 Batterie en charge » says yes. With a trial firmware that exposed CHG_EN, switching the charger off made the hiss go away; the INA226 then read 1.83 to 1.94 V (four readings, 09:55 to 09:58) and the charging status went to « not charging ». One more observation, a single one: during the 2 minutes when the voltage read 8.39 V, the hiss could not be heard; it came back with 5.70 V.

Fix (next version): the firmware looks for a battery with the charger switched off, and leaves the charger off when there is none: no more hiss, no more false « charging ». Since 2026-10-10 it does not even switch the charger on while it boots when the previous boot saw no battery. How it decides: battery.

Workaround from 3.6.0 to the latest published version: none simple, sorry. These versions have no entity to switch the charger off, and the speaker, the microphone and the volume have nothing to do with it. A fitted battery gives the charger something to charge (whether a tablet with a battery hisses too has not been checked). Otherwise, wait for the next version.

The build fails with ESPHome 2026.10.0: « was not declared in this scope » (2026-10-21)¶

Symptom: you compile the firmware yourself with ESPHome 2026.10.0 and the build stops on main.cpp with errors such as 'journal_reset_reason' was not declared in this scope, 'tr' was not declared in this scope or 'g_alarm_cfg' was not declared in this scope (13 errors on main, 2026-10-21). The same commit builds with 2026.9.x. The published firmware is not affected: it is built with a fixed ESPHome version (ESPHOME_PUBLICATION in .github/workflows/publication.yml), not with the latest one.

Root cause: an ESPHome 2026.10.0 change, reported as esphome/esphome#21303. Two kinds of !lambda values are now written into main.cpp before the #include lines of the files listed under esphome: includes:, so they cannot see this firmware's C++ functions, constants and globals:

the data: fields of a homeassistant.event, now kept in a table in flash (esphome/esphome#20237);
the value of an "apply" action or condition (select.set_index, rtttl.play, media_player.volume_set, globals.set…), now a static function.

A plain lambda: action is still written inside setup(), after the includes, and is not affected. Proof: the same main.cpp generated with 2026.9.0 and 2026.10.0 (esphome compile --only-generate), on this firmware and on a minimal config outside the repository.

Fix (next version, #535): those values only name parameters, id(…) and the standard library. The startup journal and the « Volet arrêté. » announcement send their event from a script with parameters, called from a lambda:; the alarm clock picks its melody, plays its ringtone and sets its volume from a lambda:. Same events, same fields; the firmware builds with 2026.9 and 2026.10. tests/test_includes_esphome.py fails if such a value names our C++ again (code rule 10, Tab5/README.md).

Workaround before that version: compile with ESPHome 2026.9.x (pip install esphome==2026.9.1), or with the Device Builder on 2026.9.x.

False positives worth knowing about (don't "fix" these again)¶

Forecast pagination "wrap-around": the 5 forecast pages (indices 0–4) intentionally do not wrap from 4 back to 0 on a further right-swipe. This was already "corrected" once by an LLM audit that assumed non-wrapping was a bug, then reverted. See docs/decisions/.
A cover entity showing unknown in Home Assistant: this can be real on the HA side while being irrelevant to the Tab5 firmware, if the corresponding UI card drives its own internal state via globals + a script rather than reading that entity's state directly. Check what the specific ui_components/*.yaml card actually binds to before assuming the firmware is affected.
Tab5 Uptime about a minute away from the actual reboot: not a clock problem. An ESPHome sensor state is a 32-bit float, which rounds a Unix timestamp to the nearest multiple of 128 s (±64 s). The health guard in packages/tab5_health.yaml allows 5 min for it.
Touch "overlap" between two adjacent buttons flagged by a static audit: verify the actual pixel geometry (x/y/width/height) before trusting a reported overlap — a past report was off by roughly a dozen pixels and wasn't a real overlap.