homeassistant_espscreen/docs/TEST_RESULTS_0289.md

Test results app 0.2.89 / firmware 0.2.75 (2026-09-19)

Max asked whether ESPHome's defaults leave room for faster builds and smaller firmware, and after the report (flash and build time, 2026-09-19) said: "ga het doen, maak het toekomstbestendig". This round implements it: ESPHome 2026.9.0 in the add-on, the add-on's build memory out of the ESPHome folder, and three settings that make the CYD's firmware smaller. Everything stays on ESPHome's and ESP-IDF's own options; no lwIP, Wi-Fi or LVGL settings.

What changed

	Before (0.2.88)	Now (0.2.89)
ESPHome in the add-on	2026.6.2 (PlatformIO)	2026.9.0 (ESP-IDF itself, ccache)
The packages' min_version	2026.6.2	2026.6.2, on purpose (below)
ESPHome's build memory (storage JSON, fetched packages)	/homeassistant/esphome/.esphome	/data/esphome
ESP-IDF, its tools, the compiler cache	PlatformIO in /data/platformio	/data/idf, ccache at most 1 GB
ESP-IDF assert messages	in the firmware	left out (assertion_level: SILENT, every board)
Log level of the screen	DEBUG	INFO
Timer and sun times	sscanf	clock_parts() in runtime_model.h
A running timer's countdown	could read one more than its duration	at most its duration

Three items of the report were left out or put off on purpose:

• min_version 2026.9.0, with the Guition's image: - platform: online_image and ota: encryption: for new screens. It was in the branch and on both bench screens; before the release Max asked whether everyone can update smoothly, and this is where they couldn't. Screens build from the packages on main whatever ESPHome builds them: an add-on not yet updated has 2026.6.2, Max's own ESPHome Device Builder had 2026.8.1. ESPHome 2026.6.2 knows neither the image: form of online_image nor ota: encryption: (checked in its source), so every such build, the nightly round included, would have failed until its owner updated. The packages now use nothing their min_version lacks; raising it is a release of its own, before ESPHome 2027.1 drops the top-level online_image:. CI builds both boards with the add-on's ESPHome and with min_version from now on.

• ESP-IDF's error names (CONFIG_ESP_ERR_TO_NAME_LOOKUP: n, 7.2 KB). The report said error codes would then be logged as a number. Checked in ESP-IDF 5.5.5 (esp_err_to_name.c): without the table esp_err_to_name() returns "UNKNOWN ERROR", and ESPHome's own error lines print only that name (30 of them in its Wi-Fi code, none with the number). A failing Wi-Fi start would then say nothing useful.

• esphome: build_flags instead of platformio_options: build_flags. The move made the CYD fail to compile: ESPHome 2026.9's LVGL reads only platformio_options when it writes lv_conf.h and wrote #define LV_USE_SWITCH 0 over the flag ('lv_switch_create' was not declared). The dev branch of ESPHome still does; no issue or pull request about it was found. The old form works until ESPHome 2026.12 and prints a deprecation warning.

A running timer read one second too many

Max, testing the Guition: the idle tile of timer.ok_nabu_timer (duration 0:00:03) read 0:03, but a tap started it at 0:04, and it never came below 0:02 before Home Assistant said it had finished. Not a change of this round (the countdown and ESPHome's time sync are the same in 0.2.74 and ESPHome 2026.6.2): the tile subtracts the screen's clock from Home Assistant's end time (finishes_at, whole seconds from the add-on), and the screen sets its clock from Home Assistant's epoch_seconds every minute, so it runs up to a second behind; a timer started early in a second then reads one more than it lasts, and Home Assistant's finish comes while the tile still shows 0:01 or 0:02. timer_left() (runtime_model.h) now caps the countdown at the timer's duration; the end stays up to a second early, since the screen gets no finer time from Home Assistant. tests/test_runtime_model.cpp holds the cases.

Firmware size

tools/check.sh --firmware --baseline 1678816 (ESPHome 2026.9.0, the check profiles: fallback hotspot, captive portal, OTA password):

	0.2.88 on 2026.6.2	0.2.89 on 2026.9.0
CYD image	1,678,816 B, 91.5 %	1,585,136 B, 86.4 %	−93,680 B
CYD, OTA with the api key (the next step)		1,584,208 B, 86.3 %	−912 B more
Guition image	2,055,280 B, 25.3 %	1,945,152 B, 23.9 %	−110,128 B

The firmware of this release with each ESPHome a screen may be built with (tools/check.sh --firmware per version, the same check profiles):

ESPHome	Who builds with it	CYD	Guition
2026.6.2 (min_version)	an ESP Screens not yet updated	1,609,856 B, 87.7 % (−68,960 B)	1,982,896 B, 24.4 %
2026.8.1	an ESPHome Device Builder like Max's	1,620,640 B, 88.3 % (−58,176 B)	1,998,432 B, 24.6 %
2026.9.0	ESP Screens 0.2.89	1,585,136 B, 86.4 % (−93,680 B)	1,945,152 B, 23.9 %

Of the CYD's 93.7 KB, the report's single measurements attribute 49.0 KB to the silent asserts, 8.9 KB to INFO and 9.5 KB to sscanf; ESPHome 2026.9 itself saves about 24 KB (its API encryption and the ESP-IDF parts it leaves out). The European letter set of the language plan (+65.8 KB) now fits at about 90 %.

Bench screens (over the air from the Mac)

Copies of the Device Builder YAMLs (guition-wallbox.yaml, cyd-2432s028.yaml: keys, Wi-Fi and the CYD's calibration unchanged, compared value by value with the root secrets.yaml) with the packages, components and fonts of this branch, built with ESPHome 2026.9.0:

	Guition Wallbox .136	CYD .134
Before	0.2.74, ESPHome 2026.6.2	0.2.71, ESPHome 2026.6.2
Build on the Mac	127 s	100 s
Image	1,945,088 B	1,489,216 B (its YAML has no hotspot)
OTA	13.0 s, password (plaintext fallback)	15.4 s, password (plaintext fallback)
device_info after	0.2.75, ESPHome 2026.9.0, 10:29:09	0.2.75, ESPHome 2026.9.0, 10:31:51
Home Assistant	Synced, online	Synced, online
Free heap 5 min after boot	86,940 B (fresh boots on 0.2.50: 85-86 KB)	114,724 B (was 101,712 B)
Largest free block	45,056 B	57,344 B (was 49,152 B)

This first flash had the Guition's image: form of online_image. The released firmware (the top-level form back, the timer cap added) went onto both the same way at 12:32 and 12:34, now over an encrypted connection with the api key, since their 2026.9 firmware offered it: Guition 1,945,152 B, CYD 1,489,232 B, both 0.2.75 on ESPHome 2026.9.0 in device_info and Synced in Home Assistant.

Max tested both screens by hand for half an hour on the first flash while their logs (over the API, INFO) and Home Assistant entities were watched from the Mac:

• 0 errors in about 450 log lines; one restart, Max's own from the settings page ("restart from the screen"), back in 9 s. No lost connection otherwise; both stayed Synced.
• 29 taps confirmed by Home Assistant in 256-486 ms (median 343 ms); the light effects page (select and number entities) changed them in Home Assistant; a docked robot's return to base had nothing to confirm.
• Sonos covers and 22 camera pictures in a row loaded without a failure; the first camera picture 5 s after the tap (EZVIZ snapshot included, 4.5 s in 0.2.87).
• Free heap steady: Guition about 80 KB (largest block about 34 KB), CYD 98-115 KB (51-56 KB), as before the update.
• ESPHome's "took a long time" warnings at boot, on opening a card (CYD LVGL 356 ms) and while pictures came in; one picture of the camera that took 4 s instead of 2 held the loop 0.3-1.2 s in online_image, whose read loop is the same as in 2026.6.2 (a slow download, not this release). A full redraw Max saw on the CYD was Back to page 1 after 120 s without a touch.

OTA paths, all on the Guition with the same 0.2.75 image:

• ESPHome 2026.9 CLI, profile with a password, device on 2026.6.2 firmware: "The device did not offer OTA encryption; continuing in plaintext", success.
• The same again, now that the device runs 2026.9 firmware: "Encrypted connection established" with the api key, success (14.5 s; the upload itself takes 14 s encrypted against 8 s in plaintext).
• ESPHome 2026.6.2's uploader (espota2) with the password, as the add-on before 0.2.89 and the Device Builder 2026.8 upload: success. A screen on 0.2.75 stays reachable for older tools that know its password.

On the Yellow (local add-on)

This branch's screen_manager/ as a local add-on (local_esp_screen_manager 0.2.89, SMB share local_apps and the Supervisor), next to the store add-on 0.2.85: its camera port set to none, no layouts, so it sent nothing to the screens. Its image built in 44 s from ghcr.io/esphome/esphome:2026.9.0 (aarch64). It built the Device Builder profiles through ESP Screens' own firmware jobs (build only, no upload), so with the packages on GitHub's main (firmware 0.2.74); the owner's ESPHome folder stays read-only, and this branch's packages were compiled on the Mac. Uninstalled afterwards, and the copy on the share removed.

Build on the Yellow	2026.6.2 with PlatformIO (before)	2026.9.0 in this add-on
Guition, first full build	920 s (2026-09-12)	1,379 s, of which the first ESP-IDF install into /data/idf
CYD, first full build	1,154 s (2026-09-18 23:35)	1,037 s, ESP-IDF already there
Guition again, nothing changed	not measured	41 s

• The build went where Firmware.build_env says: /data/build/guition-wallbox/guition-wallbox/build/, ESPHome's packages in /data/esphome/packages/, ESP-IDF 5.5.5 in /data/idf ("ccache will be used for faster recompilation"). The Download of the built firmware gave guition-wallbox.factory.bin, 2,083,728 B, starting with the ESP image byte 0xE9.
• A first build is about as long as before: a cold ccache saves nothing, and ESP-IDF builds more files than PlatformIO did (1,699 steps for the Guition). The gain is in what follows. The build folder and ESPHome's memory of it now survive a restart of the ESPHome Device Builder, which emptied /homeassistant/esphome/.esphome and made the next update of every screen a full build again (the CYD's 18-minute build of 2026-09-18 was one). A new firmware version still recompiles ESPHome's own sources and main.cpp, because the version is a define in defines.h: 59 s on the Mac against 46 s with PlatformIO (the report's measurement), so about ten minutes a screen on a Yellow, estimated with the Mac-to-Yellow ratio of these builds (107 s against 1,037 s for the CYD).
• The Supervisor showed the add-on at 94 % CPU and 1.2 GB of memory while it built, with ninja's default of cores + 2 compilers. The released add-on starts as many as the machine has cores (ESPHOME_DEFAULT_COMPILE_PROCESS_LIMIT), as PlatformIO did, so a small Raspberry Pi builds with about as much memory as before (not measured on one). The Yellow's disk: 60 GB used of 917 GB.
• ESP-IDF's GCC warns array subscript 6 is above array bounds of 'Key* [6]' in the Guition's climate card lambda (packages/boards/guition-4848s040.yaml, visible[room - 1] = visible[i]): on the Guition room is 6 and there are six keys, so that loop never runs. Left as it is.

Automated

• tools/check.sh (Python 3.13.14, .esphome/venv313): Python 478 tests OK (new: tests/test_build_env.py, the OTA line in test_portal, every board's assertion_level in test_easy_package), C++ 19/19 (new: clock texts in test_runtime_model.cpp), packages, icons, editor tests, types, build and bundle PASS.
• tools/check.sh --firmware --baseline 1678816 with ESPHome 2026.6.2, 2026.8.1 and 2026.9.0: PASS (table above).
• The Mac's ccache after this round and the report's builds: 27,986 compiler calls (about seventeen full builds of both boards), 0.6 GB. The add-on caps it at 1 GB (Firmware.CCACHE_SIZE); past that ccache drops the oldest entries.
• clock_parts(): identical answers to the sscanf forms for two million random strings of digits, colons, spaces, tabs, dots and letters.

Not tested

• Studio 1: not touched. It gets 0.2.75 with its next Update once its ESP Screens has 0.2.89.
• tools/render_topbar.py does not build, on ESPHome 2026.6.2 either: its host project lacks the roller the effects page (firmware 0.2.70) uses. Left for a separate round.