Files

T

Max Gramser b58f0cde25 Let the screen own its settings, answer its pings, and show them as cards (0.2.57)

A code check found that a setting changed on a screen could jump back.
ESP Screen Manager kept its own copy and sent it with every full update:
after a restart of the app or Home Assistant, every hour and after every
save. A change it missed while it or Home Assistant restarted came back
to the old value, a reported setting was lost when save() refused a
layout with a removed entity, and every step of a held - or + on the
screen resent the whole screen.

Firmware 0.2.49 offers every setting as an entity over the existing
preference records (no migration): Night mode, Night starts/ends,
24-hour clock, Back to page 1 and after how long, Back to page 1 on
standby, Swipe between pages and, on the Guition, Rotation, next to the
four numbers and Auto standby. The settings page and every entity write
through settings_screen::set(), which clamps like the page and stores,
applies and reports only a real change. screen_message answers a caller
that asks with its status and layout revision (api.respond). The
settings tile opens without Home Assistant.

The app reads and changes the settings of such a screen through its
entities and leaves them out of the layout message. Older firmware keeps
them with the layout; a setting it reports is stored without the tile
check and not sent back. Pings to screens that can answer learn at once
whether a tile is missing and resend after 30 s instead of 120 s. Layout
sensors come back after a Home Assistant restart, and weather tiles only
ask for the forecasts the entity supports. The editor's settings form is
now three cards with the rows of the screen's own page; a change applies
at once, and an offline screen shows its values as unknown.

Checked with 245 Python and 14 C++ tests, generate_packages --check,
ESP32 builds of both profiles, host-build API tests on both boards, and
a live run against Home Assistant 2026.9.1 with a temporary host device.
Firmware 0.2.49.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-16 15:50:41 +02:00

6.6 KiB

Raw Permalink Blame History

Test results app 0.2.57 / firmware 0.2.49 (2026-09-16)

A code check (2026-09-16) found that settings changed on a screen could jump back: ESP Screens sent its own copy with every full update, missed changes while it or Home Assistant restarted, refused to store a reported setting when a tile's entity was gone, and resent the whole screen for every step of a held − or +. This release makes the screen the owner of its settings (entities in Home Assistant), lets the screen answer the add-on's pings, fixes the settings tile without Home Assistant, the layout sensors after a Home Assistant restart and the hourly forecast request, and replaces the editor's settings form with cards. See CHANGELOG 0.2.57 and the compatibility note in docs/RELEASING.md.

Automated

Python (.venv-portal): 245 tests OK. New: tests/test_screen_owned_settings.py (entities in both profiles and packages, SETTING_ENTITIES against the entity names, the editor view and calls for a screen that owns its settings, unknown values while offline or without an entity, the layout message without settings, answers and their retries, the Refused fallback, forecast kinds, layout sensors after a restart, the settings tile before fresh(), the editor panel against settings_screen.h). tests/test_quiet_resync.py now expects a reported change to be kept without a resend and with the held revision; tests/test_settings_page.py checks every row writes through set().
C++ (clang++ -std=c++17 -Wall -Wextra -Werror -I. -I components/smart_display): 14/14 PASS. test_settings_screen adds set(): an unchanged value stores nothing, every key clamps like the page, brightness pulls both dim levels down, rotation is refused where the board cannot turn.
generate_packages.py --check green.
Caught by these tests before release: with a reported setting stored without a resend (new in this version), sync_one would have recorded the new layout's revision although the screen still held the old one, and the next ping would have caused a full resend after all. sync_one now keeps the held revision when the layout message is not sent.

Builds (ESPHome 2026.6.2)

Check profiles with the generated packages and local components (same substitutions, API and Wi-Fi blocks for both versions of the CYD).

Profile	RAM	Flash	vs 0.2.56
CYD	23.4% (76,540 B)	76.6% (1,406,227 B)	+1,056 B RAM, +9,492 B flash (same check profile at `93fa7e2`)
Guition	24.4% (79,916 B)	18.6% (1,510,555 B)	about +1.2 KB RAM, +13.7 KB flash (against the 0.2.56 Easy build)

Eight new entities on the CYD, nine on the Guition, each a component object on the heap at boot. Free heap on real hardware was not measured.

Firmware on the Mac (host builds, driven over the ESPHome API)

Settings, Guition 25/25 and CYD 24/24: every setting entity offered in the config category, Rotation only on the Guition, the defaults on a fresh screen, numbers, times and switches publish; a number from Home Assistant lands through set() and is reported once, the same value again reports nothing, standby brightness clamps to the brightness, a lower brightness pulls both dim levels down; switches, time, number and select land and Home Assistant sees them back; an open settings page shows a change from Home Assistant; screen_message answers a ping and a layout with status and revision, answers nothing to a caller without a call id and logs no warning; the settings tile opens while a tile never got its state; a restart keeps what Home Assistant set.
Wake and Sleep regression (the 0.2.53 host test), Guition 35/35 and CYD 35/35.

Editor

The real server on a demo home (fake Home Assistant), in a browser: a change sends one PUT and applies, several quick changes go out in one request, a held + repeats, a screen with firmware 0.2.48 shows the note about firmware 0.2.49 and still saves with the layout, the top bar's clock format is the same setting, Save sends no settings, and the cards stack on a phone-sized window.

Live with Home Assistant 2026.9.1

The Guition firmware ran on the Mac and was added to the owner's Home Assistant through the ESPHome config flow for the test, then removed. The add-on's own HomeAssistant and Manager classes ran against it, with the registry narrowed to the test device so no real screen was touched.

34/34 checks: Home Assistant lists esphome.<node>_screen_message with response: {optional: true}, all 14 setting entities with the ids the Claude skill names, all in the config category; the editor view reads the defaults; a sent layout is confirmed by an answered ping (Synced and the revision, 16 ms); a stale ping answers Resend needed and schedules one retry within 30 s; the keepalive ping is answered; a ping without an answer logs no warning; Home Assistant refuses return_response for an action without answers with "An action which does not return responses can't be called with return_response=True", which the fallback recognizes; brightness, the dim-level pull-down and eleven settings at once (switches, times, numbers, the select) reach the screen and come back as states; the same values again call nothing; invalid values are refused; − and + on the screen's own page reach Home Assistant, the editor view and one esphome.screen_setting event; no errors in the screen's log.
The editor against this Home Assistant: a switch and a step in the panel reached the screen in one PUT; two presses of − on the screen's page showed in the open panel without a reload; with the screen stopped the panel said offline and disabled every control; back online it showed the kept values again.
Found and fixed during this check: the panel showed default values for an offline screen. It now shows them as unknown (— and a switch between on and off).
Restart: with the Home Assistant time source of the real profiles, every number, time and the select had its value at the moment Home Assistant reconnected, before the next minute. The host test profile, which takes its time from the Mac, showed them as unknown until that minute; that is the host build only.

Not tested / for the owner

Real hardware. Nothing was flashed; Studio 1 updates through Home Assistant. After updating the add-on and the screen: the settings page and the new entities agree, a change in ESP Screens shows on the screen and one made on the screen shows in ESP Screens, the Settings tile opens, and the screen's settings survive the firmware update itself.
A CYD on firmware 0.2.49 (compiled and host-tested only), including its free heap after boot.

6.6 KiB Raw Permalink Blame History Unescape Escape