Max Gramser
306636434b
Live picture (issue #4): a camera or image tile on a Guition takes Display -> Live picture with a pace of 15 or 30 s. The camera tiles of a page share one download: the screen asks ESP Screens for them together (esphome.screen_camera with tiles, size and bg) and the app serves one BMP, a strip of squares with the corners rounded over each tile's own colour; every tile draws its square out of it with LVGL's image offset (LV_IMAGE_ALIGN_TOP_LEFT: the default centres a taller source). A third online_image on the Guition holds the strip; it loads after the alert's picture, a cover and the camera full screen, never under a card, in standby or under a finger. The strip is served whole every time: ESPHome's http_request logs a 304 as a failed request. Firmware 0.2.77. Alert button: esp_screens_show_alert takes action and data; the app performs the action once when the button's report (esphome.screen_alert, ok) comes from any screen. show_alert keeps its seven fields, so every firmware from 0.2.31 has it. Media card and full-page media tile: a title or artist line that is too wide rolls by (LV_LABEL_LONG_SCROLL_CIRCULAR) instead of ending in dots. Full-page tiles are white or their own pastel like every other tile; the tint in the state colour of firmware 0.2.62 to 0.2.76 is gone. Host harness (27 checks) and bench Guition + local add-on on the Yellow: docs/TEST_RESULTS_0291.md. CYD firmware 1,633,728 B, 89.0 %. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
70 lines
5.5 KiB
Markdown
70 lines
5.5 KiB
Markdown
# Test results app 0.2.91 / firmware 0.2.77 (2026-09-20)
|
||
|
||
Four asks in one round: a live picture on a camera tile (issue #4, "show a camera preview on the tile as an
|
||
option"), an action behind the alert's button, media titles that roll by, and full-page tiles without a colour of
|
||
their own. The live picture is the one with design in it; the rest is small.
|
||
|
||
## Live pictures: the design and why
|
||
|
||
- **One picture per page, not per tile.** The screen already has two `online_image`s and a rule that one picture
|
||
loads at a time (a download shares ESPHome's main loop with touch and drawing). Six tiles each loading their own
|
||
picture would mean six downloads and six buffers. Instead the screen asks for all the live tiles of the page at
|
||
once and the app serves one BMP: a strip of squares, top to bottom in slot order. Every tile draws its own square
|
||
out of that one image with LVGL's image offset. A page with six live tiles costs one download of about 50 KB.
|
||
- **The corners come from the app.** LVGL's image radius (`clip_radius`) rounds the whole source image, not each
|
||
square of it, and `clip_corner` would draw into a layer (`tests/test_layer_free.py`). So the app bakes the rounded
|
||
corners into each square over that tile's own colour, as it does for a media cover; the screen sends the colour of
|
||
every tile with the request (`bg`), so dark mode and pastel tiles come out right.
|
||
- **A third `online_image`** (`tile_image`) holds the strip: it lives beside a cover or a camera full screen instead
|
||
of sharing their buffer, and PSRAM has room. Loading still waits its turn: after the alert's picture, a cover or
|
||
the camera full screen, never under an open card, in standby or under a finger.
|
||
- **The pace is the tile's.** 15 or 30 s per tile; the page loads at the pace of its fastest tile, and the app fetches
|
||
a camera again only when that camera's own pace has passed. Nobody loading means nothing fetched.
|
||
- **The size is the icon's.** The square takes the icon circle's place and size (54 px on a Guition tile, 128 px on a
|
||
tile over the whole page), so the tile's text does not move.
|
||
|
||
## Host harness (Mac, host build of the Guition package, real add-on code)
|
||
|
||
`live_host.py` builds the Guition package as a host program with probe actions and drives it over the ESPHome API
|
||
against a demo home with five cameras (`live_demo_home.py`, the real `Manager.answer_camera` behind `/dev/camera`);
|
||
git-ignored tooling under `.esphome/readme-render/live/`. 27 checks, all passing:
|
||
|
||
- page 1 asks for its three live tiles (two single tiles and a wide one, one of them on a pastel) with size 54 and
|
||
the three colours; the strip loads and every tile shows its own square (offsets 0, −54, −108), the circle hidden
|
||
under it, the plain camera tile keeping its icon;
|
||
- the page loads again after 15 s; the 15 s camera is fetched again while the 30 s camera is not, and after 30 s
|
||
both are;
|
||
- the camera full screen pauses the strip (no load for 17 s) and it loads again once closed, the pictures back;
|
||
- a full-page live tile alone on page 2 asks at 128 px and shows its picture at 128;
|
||
- a page without live tiles wants nothing and holds no picture; a media tile over the whole page still asks for its
|
||
cover; a camera without a picture keeps its icon (the app answers with an empty entry and no link);
|
||
- back on page 1 the strip is asked for again; a card over the page pauses the loads and closing it resumes them;
|
||
dark mode asks again with the dark grounds (`1A1A1A,4A2422,1A1A1A`) and shows the dark strip.
|
||
|
||
Found on the host, fixed before the bench: LVGL's default inner alignment centres a source that is taller than its
|
||
object, so every tile showed the square of its neighbour (and the corners of the wrong colour); the picture now sets
|
||
`LV_IMAGE_ALIGN_TOP_LEFT`. The host's `http_request` fails a 304 outright where the ESP32's `online_image` takes it as
|
||
"unchanged"; the harness counts both as a load.
|
||
|
||
The rolling title was checked the same way: two renders of a full-page media tile 1.5 s apart differ only in the rows
|
||
of the title and the artist line.
|
||
|
||
## Bench Guition (192.168.146.136, firmware 0.2.77 from this tree over OTA, local add-on 0.2.91 on the Yellow)
|
||
|
||
- `camera.buienradar` live on page 1: the screen asked for the strip at once, the radar showed as a rounded square
|
||
in the icon's place on the dark tile (`capture_ui.py`), and every 15 s the screen loaded again. The radar changes
|
||
every five minutes, so the app answered 304 in between, and ESPHome's `http_request` logged every one of those as
|
||
`HTTP Request failed; Code: 304` and raised its error flag (`online_image` then said "Download skipped"). The app
|
||
now serves a live strip whole every time, never a 304 (about 9 KB for one tile, 50 KB for six, on the LAN), and
|
||
without the ETag `online_image` warned "No header with name etag found" and "... last-modified ..." at every load,
|
||
so every picture now carries both headers. No "took a long time" warning during the loads.
|
||
- The alert with `action: persistent_notification.create` reached both bench screens; the button's report
|
||
(`esphome.screen_alert`, `action: ok`, sent the way the screen sends it) made the notification once, and the add-on
|
||
logged `Alert button on guition-wallbox: persistent_notification.create performed`.
|
||
|
||
## Builds
|
||
|
||
`tools/check.sh`: Python 516 tests, C++ tests, packages, icons, translations (9 languages, 1431 texts), editor tests
|
||
(106), types and build. `tools/check.sh --firmware` with ESPHome 2026.9.0: CYD 1,633,728 B, 89.0 % of the update slot
|
||
(832 B more than 0.2.90); Guition 2,058,368 B.
|