Hardware Reference¶

Hardware revisions¶

M5Stack has shipped the Tab5 with three different display controllers (M5Stack change log). Each one needs its own ESPHome display model, and they are not interchangeable (ESPHome mipi_dsi documentation):

Display chip	Units made	ESPHome model	`tab5_ecran:`	Status in this project
ILI9881C + separate GT911 touch	9 May 2025 → 14 October 2025	`M5STACK-TAB5`	`ili9881c`	🧪 Compiles, untested — built by the CI, never run on a device
ST7123 (display and touch in one chip)	14 October 2025 → 28 April 2026	`M5STACK-TAB5-ST7123` (named `M5STACK-TAB5-V2` before ESPHome 2026.7)	`st7123` (default)	✅ Supported — the author's device, in daily use
ST7121 (display and touch in one chip)	from 28 April 2026	`M5STACK-TAB5-ST7121`	`st7121`	✅ Runs on a user's unit — built by the CI; another user has run this firmware since October 2026: display, touch and wake word (Discussion #278). The author has no ST7121

How to tell which one you have: the display chip is printed on the sticker on the back, just above the Espressif logo. ESPHome warns that a unit labelled "ST7123" may carry either an ST7123 or an ST7121: the only way to know is to try both.

Choosing your revision: add one line to Tab5/user_entities.yaml, for example tab5_ecran: st7121. Without it, the firmware is built for the ST7123. What differs between revisions (display model, touch chip) lives in Tab5/paquets/ecran-<revision>.yaml; pins, calibration and behaviour are shared in Tab5/paquets/tab5-hardware.yaml.

What "untested" means: the CI compiles the ILI9881C and ST7121 files whenever the display configuration changes, so they cannot silently break, but nobody has run this firmware on an ILI9881C yet.

ILI9881C: display model and GT911 touch taken from the ESPHome device page for the original revision, with the same pins as the ST7123.
ST7121: ESPHome has an official display model, but no ST7121 touch driver. According to comments in ESPHome's model code, M5Stack's factory firmware tells the two chips apart by reading the touch controller's firmware version, so they very likely share the same protocol: this project uses the st7123 touch platform. In July 2026, while testing the ESPHome pull request that added the ST7121 model, another user reported that this same pairing (M5STACK-TAB5-ST7121 display, st7123 touch) works on a real ST7121: display and touch, accurate across the whole screen, in landscape. Since October 2026, this firmware itself runs on another user's ST7121 (Discussion #278): display, touch and wake word work. If the screen works but touch does not on your unit, the touch driver is the first suspect.

Good to know: most Tab5 examples published so far target the original ILI9881C revision. In September 2026, the ESPHome device page still says only that one is supported, and M5Stack's own Home Assistant HMI example does not support units made after 14 October 2025. This project runs on the ST7123 (the author's unit) and on the ST7121 (a user's unit), and builds for the ILI9881C.

On an ST7121, two things are worth checking: touch in all four corners in landscape, and opening then closing the Neon Apron pinball game, which switches the screen to portrait and back. The user quoted above rotated the image in the display: block; this firmware rotates it in LVGL (rotation: 270, changed on the fly by Neon Apron), a path nobody has reported running on an ST7121 yet. One report mentions a boot crash with LVGL rotation on an ST7121, but on a unit later returned for a display defect, so the link is uncertain. The same report shows that display/touch mirroring corrupts the image on an ST7121: this firmware does not use it.

Own an ST7121 or ILI9881C unit and willing to try? Say how it went in Discussions → Hardware compatibility.

Waveshare ESP32-P4 7B (experimental)¶

🧪 Runs on the author's board since 2026-10-14. The firmware can also be built for the Waveshare ESP32-P4-WIFI6-Touch-LCD-7B (7-inch, 1024×600, the same ESP32-P4 and ESP32-C6 as the Tab5): add tab5_carte: waveshare-7b to Tab5/user_entities.yaml and build with ESPHome 2026.9.1 or newer (ADR-0061). The home screen and the popups follow its screen size; it has no motion sensor, no clock chip and no battery gauge (a battery connector, which this firmware does not use yet). Its hardware, pins, install steps and the problems met when it arrived have their own page: Waveshare ESP32-P4 7B. The rest of this page is about the Tab5.

M5Stack Tab5 V2¶

The Tab5 is a 5-inch touch-screen panel from M5Stack. It uses an ESP32-P4 as the main application processor, with a separate ESP32-C6 co-processor handling Wi-Fi and Bluetooth connectivity. This project runs on the ST7123 revision, which this repository calls "Tab5 V2" (see Hardware revisions).

ESP32-P4 (main processor)¶

Spec	Value
Architecture	RISC-V, dual-core, 360 MHz on the Tab5 (chip revision v1.3, read at boot; 400 MHz needs a revision v3.x chip)
Internal SRAM	768 KB
External PSRAM	32 MB (hex mode, 16 data lines, 200 MHz) — measured on the device on 2026-09-26: `esp_psram_get_size()` = 32 768 KB, 29 567 KB available to the heap
Flash	16 MB
Display interface	MIPI-DSI, 16-bit RGB565
Touch controller	I2C (ST7123)

The PSRAM is critical for this project. LVGL requires a framebuffer sized to the display resolution — at 1280 × 720 px in RGB565, that's ~1.8 MB just for the framebuffer. The ESP32-P4's internal SRAM alone would not be enough. With 32 MB of PSRAM, the framebuffer stays entirely in external memory.

ESP32-C6 (co-processor)¶

Handles all radio communication: Wi-Fi 6 (802.11ax) and BLE 5. The main ESP32-P4 communicates with it over an SDIO bus (esp32_hosted: component, 20 MHz). From the ESPHome/LVGL code perspective, this is transparent — standard ESPHome Wi-Fi and BLE components work normally.

The C6 has its own RAM (512 KB) and runs Espressif's ESP-Hosted firmware, not ours: our firmware, including the TCP/IP stack (lwIP), runs on the P4. ESPHome builds the P4 side of ESP-Hosted (2.12.12 with ESPHome 2026.9) but does not update the C6, which keeps its factory firmware unless someone reflashes it. The diagnostic sensor Tab5 C6 Version reports that version once per boot. The P4 resets the C6 through GPIO 15 on every boot, software reboots included (ESP-Hosted's default setting, CONFIG_ESP_HOSTED_SLAVE_RESET_ON_EVERY_HOST_BOOTUP); the one time the C6 did not come back after an OTA: Troubleshooting.

Notes from another Tab5 project (discussion #369, thanks to Jiuhai, who builds Tab5 devices on ESP-IDF without ESPHome). They come from reading the schematic and the source code, not from measurements, and the author has not checked the schematic:

On the schematic, the C6 reset net RF_C6_RST goes through R4 to SOC_EXTRF_RST, which is GPIO 15 of the P4.
Firmware built with ESP-IDF, without ESPHome: in ESP-Hosted's Kconfig (checked in 2.12.12), the reset pin ESP_HOSTED_SDIO_GPIO_RESET_SLAVE defaults to 15 only when the board preset ESP32P4_TAB5_C6_BOARD is selected, and to 54 on any other ESP32-P4: the reset pulse then goes to the wrong pin and the C6 is never actually reset (it happened in that project's first build). grep GPIO_RESET_SLAVE sdkconfig tells. ESPHome takes the pin from reset_pin (15 here). That preset also switches the reset to active-low, with a comment saying that otherwise the C6 never leaves reset on a Tab5; this firmware uses active_high: true and the C6 has come up on every boot of the author's tablet (about fifty since 2026-09-30). The two do not agree, and the author does not know why.
At start-up, ESP-Hosted on the P4 compares its version with the C6's and warns Version mismatch: Host […] > Co-proc […] ==> Upgrade co-proc to avoid RPC timeouts (compare_fw_version()). That warning is not in an ESPHome firmware: ESP-IDF warnings are compiled out (see Debugging). On the author's tablet (2.12.12 on the P4, 1.4.1 on the C6), no RPC timeout has been seen: none in the device journal since 2026-09-30, none in three boots read on the serial port on 2026-10-07.
Updating the C6 is not simple: one Tab5 project finds that the factory C6 firmware offers no update path over SDIO and plans a one-time wired reflash first (sslivins/arctic-controller#276, open); on another P4 + C6 board, after an update of the hosted firmware to 2.12.8, the SDIO link failed and the C6 boot-looped, even after going back to 2.12.1 (esphome/esphome#16692). Neither project updates the C6.

Real-time clock (RX8130CE)¶

Address 0x32 on the internal I2C bus (bsp_bus, GPIO31/32), backed by a 70 000 µF supercapacitor (M5Stack specification). The firmware reads it once at boot, so the clock and the alarm have the time before the network is up, and writes it back after every NTP sync. It stores UTC. The same bus also carries the INA226 battery monitor (0x41, see Power).

Display¶

Size: 5 inches
Resolution: 1280 × 720 px (M5Stack Tab5 V2 batch used in this project)
Interface: MIPI-DSI 16-bit RGB565 (ESP32-P4 LCD peripheral)
Touch: Capacitive multi-touch via ESPHome's official st7123 I2C touchscreen platform on the ST7123 revision (since ESPHome 2026.7.0; the former custom my_components/st7123 was removed on 2026-07-06) — gt911 on the original ILI9881C revision, see Hardware revisions

Pin map¶

Every pin the firmware configures, as written in its YAML. The pins are the same on the three revisions. "PI4IOE 0x43, P1" means pin 1 of the PI4IOE5V6408 I/O expander at address 0x43 on the internal I2C bus; there are two of them (0x43 and 0x44). The MIPI-DSI link itself has no pin in the YAML: the display model of Tab5/paquets/ecran-<revision>.yaml takes care of it. The last column names the component (its id, or the block that has none) and the key: tests/test_doc_broches.py checks every row, in both languages, against the YAML, and fails if a pin of the YAML is missing here.

Function	Pin	In the YAML
Internal I2C bus, SDA (400 kHz)	GPIO 31	`bsp_bus` · `sda`
Internal I2C bus, SCL	GPIO 32	`bsp_bus` · `scl`
Display reset	PI4IOE 0x43, P4	`tab5_display` · `reset_pin`
Touch interrupt	GPIO 23	`touch` · `interrupt_pin`
Touch reset	PI4IOE 0x43, P5	`touch` · `reset_pin`
Backlight PWM (LEDC, 1 kHz)	GPIO 22	`backlight_pwm` · `pin`
I2S bit clock (microphone and speaker)	GPIO 27	`mic_bus` · `i2s_bclk_pin`
I2S word select (microphone and speaker)	GPIO 29	`mic_bus` · `i2s_lrclk_pin`
I2S master clock (microphone and speaker)	GPIO 30	`mic_bus` · `i2s_mclk_pin`
I2S data in, from the ES7210 (microphone)	GPIO 28	`tab5_microphone` · `i2s_din_pin`
I2S data out, to the ES8388 (speaker)	GPIO 26	`tab5_speaker` · `i2s_dout_pin`
Speaker amplifier enable	PI4IOE 0x43, P1	`speaker_enable` · `pin`
Headphone jack detect	PI4IOE 0x43, P7	`headphone_detect` · `pin`
Wi-Fi antenna, internal or external	PI4IOE 0x43, P0	`wifi_antenna_int_ext` · `pin`
External 5 V power	PI4IOE 0x43, P2	`external_5v_power` · `pin`
Wi-Fi power	PI4IOE 0x44, P0	`wifi_power` · `pin`
USB power	PI4IOE 0x44, P3	`usb_5v_power` · `pin`
Battery quick charge (active low, kept off)	PI4IOE 0x44, P5	`quick_charge` · `pin`
Battery charging status	PI4IOE 0x44, P6	`batterie_en_charge` · `pin`
Battery charge enable	PI4IOE 0x44, P7	`charge_enable` · `pin`
ESP32-C6 link (SDIO), clock	GPIO 12	`esp32_hosted` · `clk_pin`
ESP32-C6 link (SDIO), command	GPIO 13	`esp32_hosted` · `cmd_pin`
ESP32-C6 link (SDIO), data 0	GPIO 11	`esp32_hosted` · `d0_pin`
ESP32-C6 link (SDIO), data 1	GPIO 10	`esp32_hosted` · `d1_pin`
ESP32-C6 link (SDIO), data 2	GPIO 9	`esp32_hosted` · `d2_pin`
ESP32-C6 link (SDIO), data 3	GPIO 8	`esp32_hosted` · `d3_pin`
ESP32-C6 reset	GPIO 15	`esp32_hosted` · `reset_pin`

The firmware declares a single I2C bus (bsp_bus), so every I2C chip it drives is on it: the two I/O expanders, the touch controller, the ES8388 and the ES7210, the BMI270 motion sensor (0x68, Tab5/paquets/tab5-imu.yaml), the RX8130CE clock (0x32) and the INA226 battery monitor (0x41; ESPHome's default address for it, 0x40, is the ES7210's).

Audio — ES8388 DAC¶

The Tab5 integrates an ES8388 audio codec chip, used here for the DAC path (speaker output) via ESPHome's native audio_dac: es8388 platform. The microphone input goes through a separate ES7210 ADC chip (audio_adc: es7210, 16 kHz / 16-bit), whose output the ESP32-P4 reads over I2S.

Connections¶

Both chips are set up over the internal I2C bus and share one I2S bus (mic_bus): the three clocks are common, each direction has its own data line. Only one of the two can hold that bus at a time (ADR-0010). The speaker amplifier is switched by the first I/O expander (speaker_enable). Pins: Pin map.

Boot sequence issue¶

The ES8388 requires a specific initialization sequence over I2C to come out of reset and route audio correctly. If the amplifier enable line fires before the I2S clock is stable, a loud pop occurs through the speaker.

The ESPHome on_boot block addresses this by sequencing (tab5-ha-hmi.yaml, priority 600): 1. Turn on the backlight, wait 1 s 2. Set the media player volume 3. Only then enable the amplifier switch (speaker_enable) 4. Then wait for the HA API connection

This order ensures the I2S clock is stable before the amplifier opens the speaker path. Register-level initialization is handled by ESPHome's es8388 platform itself — there are no manual i2c.write_bytes calls in the configuration anymore.

Microphone — ES7210 ADC over I2S¶

The onboard microphone is captured by the ES7210 ADC chip (audio_adc: es7210), which streams to the ESP32-P4 over I2S (adc_type: external), on the bus it shares with the speaker (pins: Pin map).

Capture parameters: 16 kHz, 16-bit mono. This matches the input format expected by the micro_wake_word component and by Home Assistant's voice pipeline.

Power¶

The Tab5 is USB-C powered. Measured on a tablet with its battery on 2026-10-10: 2.6 W with the screen at 100 %, 1.7 W at 50 %, 1.2 W with the screen off (power consumption); the 1.5 A figure given here before had no source. The author's tablet runs without a battery on a PC's USB port; the history kept by Home Assistant (since 2026-09-30) shows a single brownout reset, on 2026-10-06 right after an OTA, cause unknown. A charger of 5 V / 2 A or more leaves some margin: advice, no longer a requirement. Without a battery, the tablet starts again by itself when USB-C power comes back, after a cable pulled while it runs as after a long-press power-off.

Power path, as read on the schematic (Jiuhai's notes in discussion #369, page 5 of the schematic, not checked by the author). Without a battery, the 5 V comes from USB-C or from the HVIN pin of the Ext.Port (pin 2): HVIN → D7 → FU4 (1 A polyfuse) → MP4560 buck converter (5.04 V) → MAX40200 ideal diode (1 A absolute maximum) → SYS_5VBUS; USB-C joins SYS_5VBUS through a second MAX40200; LPW5209 load switches then feed the screen, the P4, the C6, the speaker, the camera and the EXT 5V output. As far as that reading goes, every 5 V load shares one 1 A ideal diode: at peak load (full brightness, loud audio, camera, external sensors), a brownout seems more likely than damage. Whether it explains the brownouts above (on a PC's USB port) is not known. Jiuhai's devices run on 9 V through HVIN; the author has never powered the tablet that way. The measurements announced in the discussion (power-on from HVIN after a cut, input power at idle, at peak load and during an OTA, EXT 5V under load, twenty reboots and OTAs in a row, RTC drift) will be added here when they are published.

Backlight brightness is software-controlled via PWM (LEDC output on GPIO 22, light: monochromatic) and can be dimmed from Home Assistant to reduce power draw. Touching the screen while the backlight is off turns it back on (touchscreen: on_release). There is no ambient light sensor in this configuration.

Battery. The Tab5 takes an optional two-cell (2S) lithium battery. Before 3.6.0 the firmware never enabled its charger, and a user reported that the battery did not charge (discussion #278). From 3.6.0 (2026-10-04) up to the latest published version, it enables the charger at every boot (charge_enable, PI4IOE 0x44 P7), like M5Stack's M5Unified library, battery or not; the next version switches it on only when it finds a battery (below). Quick charge (P5) is kept off by default: the tablet stays plugged in, and standard charge asks less current from the USB charger (the « Rapide » charging mode below switches it on). Three diagnostic entities reach Home Assistant: Tab5 Batterie en charge (charging status, P6, read every 10 s, a change published once it has lasted 30 s), Tab5 Tension batterie (voltage measured by the INA226, published on a 50 mV change or every 15 min) and Tab5 Batterie (level estimated from the voltage; it reads too high while charging; "unknown" while no battery is detected). Since the next version the level follows a discharge curve measured on a Tab5: 6.6 V = 0 %, 7.0 V = 2 %, 7.4 V = 7 %, 7.6 V = 18 %, 7.8 V = 47 %, 8.0 V = 62 %, 8.2 V = 97 %, 8.35 V = 100 %. It was measured on the original battery of a user's tablet (husyildiz, discussion #278, 2026-10-15): two full discharges at a constant load, screen off (about 0.17 A, 1.2 W), read from Home Assistant's history; the remaining capacity is the time left until the battery's protection cut off (13 h 23 min). The second night crossed every voltage within 5 minutes of the first one. Up to the latest published version it was a straight line, 6.0 V = 0 %, 8.23 V = 100 % (ESPHome's reference configuration): a lithium battery stays long on a plateau and then collapses, so the level dropped from 100 to about 65 % in 11 hours, then to 0 % in about one hour; 3.9.0-rc.2 used the open-circuit table of another battery (Samsung EB535151VU, from the Linux kernel), better but still flat for hours, then 58 → 7 % in two hours. Limits: one battery measured; with the screen on, the voltage sags a little more and the level reads a little low; on the plateau from 8.00 to 8.05 V (62 → 81 %), the voltage published to the nearest 50 mV can make the level jump by about 20 %. They are disabled by default in Home Assistant: with the battery fitted, enable them on the device page.

Without a battery, with the charger on (3.6.0 up to the latest published version), the charger charges into nothing. It says "charging", and the INA226 reads the charger or the USB, never a battery: 4.2 V on the tablet of a user whose fitted original battery reads about 7.2 V, with a charging status that follows reality (2026-10-05); on the author's tablet, which has none, 4.2 V and 8.39 V alternating every 1 to 3 minutes (evening of 2026-10-03), then a steady 5.71 V (2026-10-04), around 5.70 to 5.76 V on 2026-10-08. 8.39 V is therefore one of the values read without a battery, not a full battery. It also makes a faint continuous hiss, which stops when the charger is switched off (troubleshooting). Until the next version, "no battery" means a reading below 6.0 V in the last 10 minutes (since 2026-10-05, discussion #278): the alternating case climbs back above 6 V between two low readings, and the steady 5.7 V case stays below.

Battery detection with the charger off (next version). With the charger off, the INA226 reads the battery itself, or almost nothing: on the author's tablet, without a battery, 1.83 to 1.94 V (four readings, 2026-10-08), with the charging status at "not charging". A 2S battery, even an empty one, reads more than 5 V. So, charger off, 5.5 V or more means a battery, less means none (3.0 V up to 3.8.0: a residual 3.29 V read without a battery on 2026-10-11 passed it, and the charger then charged into nothing; a 2S battery never drops below about 6 V, its protection cuts off first). When the tablet looks:

at boot (next version), the charger stays off until a probe has read the voltage with the charger off (about 8 s after the end of setup()); it is switched on only if that reading sees a battery (5.5 V or more). The 30 s wake-up of a battery in protection only follows a probe that saw nothing, when the previous boot had seen a battery (kept in flash, tab5_batterie_memoire: unknown, none, seen), and never after an abnormal restart (crash, brownout). Up to the latest published version, that wake-up came first, at every boot until something was decided: 30 s of charging into nothing on the first boot of a tablet without a battery (the C145 model is sold without one), and at every turn of a restart loop. With the INA226 silent (presence unknown), the charger stays off. Risk: a new or completely flat battery reads below 5.5 V, is seen as absent and is not woken up: switch Tab5 Batterie montée on, which wakes it up at once (30 s), then once an hour while it is not seen;
charger on, with a battery: a probe every 10 minutes, and right after a reading below 6 V, to see whether the battery was taken out;
charger off: every reading (every 60 s) decides, so a battery slid in while the tablet runs is seen within a minute;
no battery found while the Tab5 Batterie montée switch says there is one: the charger is switched on for 30 s once an hour (and at once when the switch is turned on, since 2026-10-10), then probed, in case the battery was so empty that its protection had cut it off. With the switch off (no battery declared), the charger is never switched on again.

Without a battery, the charger stays off: no more hiss, no more false "charging". A fourth diagnostic entity, Tab5 Batterie détectée, enabled by default, publishes the decision (unknown before the first reading). Measured so far: only the reading without a battery, on the author's tablet; with a battery, not measured yet.

Charger safety locks. The author's Tab5 died on 2026-10-11, most likely from charging into nothing (charger on without a battery, 7.7 V read, the P4 going from 61 to 70 °C in 4 minutes; not confirmed, it is at M5Stack's repair service). The firmware cuts the charger off by itself:

thermal (3.8.1): CPU at 55 °C or more, or +4 °C within 60 s above 48 °C → charger off at least 15 minutes, then until a temperature read at 44 °C or less. Since the next version it is kept in flash (a restart, caused by the heat or not, finds it set) and an unreadable temperature no longer lifts it;
electrical (next version), charger on: a voltage above 8.45 V (more than a full 2S battery) or no charging current (below 20 mA either way) for 30 s → charger off and a probe at once (before: up to 10 minutes until the next probe). No current while the probe reads a full battery (95 % or more) means charging has finished: nothing wrong, the current check stays quiet until the level drops below 90 %. Two cut-offs within an hour lock the charger until the next restart. Not measured with a battery: the voltage read at the end of a charge, and the current of a full battery;
each lock is visible: the diagnostic entity Tab5 Sécurité chargeur (a problem, on while a lock is set) and the esphome.tab5_securite_chargeur event (cause: thermique, tension or courant; mesure; verrouille: oui when locked until restart), which the « sécurité du chargeur » guard of the tab5_health package turns into a persistent notification and a phone notification.

What the firmware cannot do for you. Fit only the 2S battery made for the Tab5 (NP-F550 type, 7.4 V nominal), never a single-cell (1S) battery. Prefer a 5 V / 2 A charger to a PC's USB port: a brownout was seen on a PC's port right after the brightness went to 100 % (2026-10-08). HVIN: 6 to 24 V only. M5Stack gives 0 to 40 °C ambient for the Tab5: not in the sun nor against a heat source.

On the screen, an icon closes the status bar (top left, after the alarm bell) once the device switch Tab5 Batterie montée is on; it is off by default and survives reboots. With no battery detected the icon is a plug, in the theme's text colour; with a battery its glyph follows the level (full above 80 %, half, low, "!" below 20 %, a bolt while charging) and its colour is the phone's scale (get_battery_color(): green, blue, amber, red); "?" in grey before the first reading. The icon reads the sensors on the tablet itself: it works even with the battery entities left disabled in Home Assistant.

Charge limit (next version). The device setting Tab5 Limite de charge: « 100 % » (the default) or « 80 % »: charging stops at 80 % and starts again at 70 %, after at least 10 minutes stopped. It is meant for a tablet that stays plugged in: a lithium battery kept below full lasts longer. The level comes from the voltage (the discharge curve above), and the voltage is higher while charging than at rest, so charging stops a little before a real 80 %: with the measured curve, it stops at about 8.05 V read while charging and starts again at about 8.02 V read with the charger off (7.78 V and 7.56 V with the former straight line); both are on the plateau, and the 10-minute minimum pause keeps it from going back and forth (not measured on a tablet). Not measured yet: with the charger stopped and USB plugged in, does the tablet run from USB or from its battery? If it runs from its battery, the 80 % mode makes it go back and forth between 80 and 70 % instead of resting it.

Charging mode (next version, ADR-0045). The device setting Tab5 Mode de charge: « Classique » (the default, quick charge off as before) or « Rapide »: the charger's quick-charge input (nCHG_QC_EN, P5) is switched on, only while the charger itself is on — never without a battery, during a probe or in the 80 % pause. M5Stack's M5Unified library calls these two states 500 mA and 1000 mA (setChargeCurrent); neither current was measured on this tablet, nor the heat or the load on the USB charger.

Eco Wi-Fi (next version, ADR-0045). The device setting Tab5 Wi-Fi éco: « Jamais » (the default: the radio always listens, power_save_mode: NONE), « Sur batterie » or « Toujours », with the same « on battery » as energy saving. On, the Wi-Fi uses the light power save (WIFI_PS_MIN_MODEM), sent to the C6 through ESP-Hosted, and goes back to full listening during voice, sound and updates. Not measured: the current saved, and the added latency of a push or a ping (up to one DTIM interval of the router). Whether the C6 software (1.4.1 on the author's tablet) honours the request is not verified either; the tab5.wifi log line says whether it was accepted.

Power drawn (next version). Tab5 Consommation (W) is the battery voltage × the battery current, while the battery is discharging; it is unknown on mains, since the USB current is not measured. On the tablet, the « Battery » line of the system console shows the level and that power on battery (for example « 78% · 2.4 W »), otherwise the level and the voltage. Measured on a tablet on 2026-10-10 (power consumption). To measure it case by case (screen, microphone, speaker, theme, energy saving), the Home Assistant script « Tab5 — consumption test » (packages/tab5_mesure_conso.yaml, described here) switches on Tab5 Mesure de consommation (next version), which reads the battery every 2 s instead of every minute, for 2 h at most.

Low battery alert (next version). On battery, when the level drops below 20 %, then below 10 %, the tablet sends the esphome.tab5_batterie_faible event (level, threshold), once per threshold, re-armed at 30 % or when charging resumes. The « batterie faible » guard of the tab5_health package turns it into a persistent notification (the 10 % one replaces the 20 % one) and a phone notification.

Battery current and energy saving (2026-10-06). The INA226 also gives the battery current, published as Tab5 Courant batterie (diagnostic, disabled by default like the voltage): positive while the battery is discharging, that is while the tablet runs on it, negative while it charges. That sign comes from M5Stack's M5Unified library (getBatteryCurrent: the shunt is wired so that charging reads negative; ESPHome publishes the register as it is), and a user's tablet with its battery confirmed it on 2026-10-07 (discussion #278). Each reading (every 60 s) decides Tab5 Sur batterie: above 50 mA of discharge, on battery; below 20 mA, plugged in; never while charging (it switches back as soon as charging resumes) nor without a detected battery. The device setting Tab5 Économie d'énergie (« Sur batterie » by default) uses it: on battery, the brightness is capped at 50 % at the backlight output (Home Assistant keeps the brightness you chose), drops to the minimum (10 %) after 30 s without a touch and at 35 % of battery or less (until the level climbs back to 60 %; 40 % up to the latest published version, only 23 mV above 35 % on the measured discharge curve, against 0.26 V for 60 %), the animations stop (whatever the « Tab5 Animations » setting) and LVGL redraws at most 30 times a second outside games. Thresholds: Tab5/socle/tab5_economie.h, tested on a PC by tools/test_alarm_clock.cpp; settings: settings.