Max Gramser
b58f0cde25
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>
85 lines
5.3 KiB
Markdown
85 lines
5.3 KiB
Markdown
## Easy Setup and releases
|
||
|
||
The preferred route for new users is docs/EASY_SETUP.md: ESP Screen Manager
|
||
plus remote ESPHome packages. No token or blueprint needed. Tiles live in the
|
||
persistent add-on data; Wi-Fi/API/OTA stay in the device's own ESPHome YAML. Read
|
||
docs/RELEASING.md before publishing updates. Main distributes both boards.
|
||
Every push to GitHub is a release: always also bump the add-on version in
|
||
screen_manager/config.yaml (with a CHANGELOG line), otherwise HA won't see an update.
|
||
Generate packages with tools/generate_packages.py; don't edit them by hand.
|
||
A screen gets its tiles from the add-on while it runs: every card works in all
|
||
twenty positions, and no Home Assistant entity belongs in a board profile.
|
||
Preserve the data schema, protocol compatibility, unique keys, and CYD preferences.
|
||
Test updates against existing data. Don't publish an unknown storage version without
|
||
a migration. Production Ingress needs no long-lived token or public port.
|
||
|
||
## Guition board
|
||
|
||
The Guition 4848S040 has a separate profile `guition-4848s040.yaml` with
|
||
480×480, ST7701S RGB, and GT911. Read docs/GUITION.md. Don't carry over the CYD
|
||
layout or the XPT2046 calibration.
|
||
Verify touch with tools/verify_gt911.py and keep the CYD regressions green.
|
||
Don't configure wallbox relays as part of display support.
|
||
|
||
# Working instructions for LLMs and developers
|
||
|
||
This project drives an ESP32-2432S028 with ILI9341 + XPT2046 (320×240,
|
||
LVGL 90°). Read README.md and docs/ before installing. The owner can
|
||
physically tap; an agent cannot replace that with software coordinates.
|
||
|
||
## Installing a new screen
|
||
|
||
1. Install it from ESP Screens (docs/EASY_SETUP.md): the add-on writes the screen's
|
||
own ESPHome YAML with its name, Wi-Fi reference and unique keys, and flashes it
|
||
over USB. Identify the USB port and board variant first, and check whether a
|
||
profile for this screen already exists; never overwrite a working one.
|
||
Use ESPHome 2026.6.2 with Python 3.11-3.14. Don't show keys in logs or chat.
|
||
2. CYD: the screen shows its calibration on first boot; the owner taps the
|
||
crosshairs. `tools/calibrate.py` with docs/CALIBRATING.md is the USB route for a
|
||
panel that needs measuring; ask for physical taps per target, and wait for
|
||
confirmation that the measurement screen is visible. A successful build is not a flash.
|
||
Guition: GT911 reports pixels; verify with tools/verify_gt911.py, no ADC calibration.
|
||
3. Pair with the owner's own Home Assistant through the ESPHome integration.
|
||
Read real entity IDs and supported attributes; don't make up entities.
|
||
4. Choose the tiles in ESP Screens. Don't test real device actions without the
|
||
owner's permission, and report which checks were actually carried out,
|
||
the limitations, and how long the screen stayed up.
|
||
|
||
## Code and regressions
|
||
|
||
- Keep base hardware and UI in `home-like-2432s028.yaml`; personal data belongs
|
||
in the gitignored local profiles.
|
||
- Screen settings live in one table: `components/smart_display/settings_screen.h` draws the
|
||
page on the screen, `SETTING_RULES` in the add-on validates the same keys. Firmware 0.2.49+
|
||
owns them: every writer (the page, the entities in both profiles) goes through
|
||
`settings_screen::set()`, and the add-on changes them through the entities in
|
||
`SETTING_ENTITIES`, never through the layout message. docs/SETTINGS.md is the end-to-end
|
||
recipe for adding one; never widen the eleven-key `settings` block older firmware insists on.
|
||
- Preserve fixed pages, hidden navigation at six tiles or fewer, and a
|
||
minimum default standby of 600 seconds. Don't reintroduce free scrolling
|
||
without physically testing for touch/navigation regressions.
|
||
- Preserve the touch filter and event guard before actions; calibration processes
|
||
filtered physical ADC values. Don't apply the affine correction twice, in both the driver and the UI.
|
||
- The calibration wizard assumes swap_xy=false, mirror_x=true, mirror_y=false,
|
||
and LVGL 90°. A changed orientation also requires a new projection/tests.
|
||
- Run the Python tests, both C++ test suites, and ESPHome validation/build on code changes.
|
||
Firmware tests and hardware acceptance are different checks.
|
||
- `diagnostics/run_ui_test.py` renders without HA actions; don't touch the screen
|
||
during that test. Use `--name` for the expected device identity.
|
||
`diagnostics/send_layout.py` pushes a demo layout with every card type to a
|
||
screen via the API inbox (no HA actions); the manager restores the real
|
||
layout within ~25 s. Guition: `capture_ui.py` saves the LVGL render as a PNG.
|
||
Without a screen: `tools/render_topbar.py` renders the real top-bar code for both
|
||
boards via the ESPHome host + SDL2 to `.esphome/render-topbar/out/sheet.png`.
|
||
- Share through Git. Don't stage secrets, measurements, binaries, logs, build
|
||
caches, or local device profiles.
|
||
- No automatic firmware upload to an arbitrary connected port.
|
||
With multiple boards, first determine the intended port.
|
||
- Profiles with the same `DEVICE_NAME` share `.esphome/build/<name>`.
|
||
Never compile or upload them concurrently; check
|
||
the `firmware.bin` path in the upload log, and then the compile time via
|
||
`device_info`. A wrong profile knocks the screen out of ESP Screen Manager.
|
||
|
||
Historical diagnostics are background context, not proof that a new panel
|
||
works correctly. During onboarding, don't make claims about physical tests that weren't actually performed.
|