# Testing & Verification This file tracks which milestones have been verified on hardware and how. Per-milestone entries below each list: - **Acceptance** β€” what "done" means (mirrors the impl guide). - **How to verify** β€” exact commands or actions. - **Status** β€” ⬜ not verified / 🟑 partial / βœ… verified, with a one-line note (date, board rev, anything weird). Hardware-required milestones can't be verified by a clean build alone β€” a checked-in build success counts as 🟑 (compiles, not yet run). --- ## M1 β€” Board Bring-Up **Acceptance**: device gets a DHCP lease over Ethernet and logs its IP. **How to verify** ```bash source ~/Dev/code/git/esp32/env.sh idf.py -p /dev/cu.usbmodem* flash monitor ``` Expected log within ~5–10s of boot: ``` I (xxx) viewport: Scrypted Viewport boot I (xxx) net_eth: ethernet driver started, waiting for link + DHCP I (xxx) net_eth: link up, mac xx:xx:xx:xx:xx:xx I (xxx) net_eth: got ip 192.168.x.x gw 192.168.x.1 netmask 255.255.255.0 I (xxx) viewport: online at 192.168.x.x ``` Cross-check from another host: ```bash ping 192.168.x.x ``` **Status**: 🟑 builds clean against ESP-IDF 5.4 (commit e2ac22e). Not yet flashed to hardware β€” awaiting first board run. > Combined hardware verification of M1+M2 is fine β€” they both run from the same flash session. --- ## M2 β€” HTTP + mDNS **Acceptance**: `GET /state` returns JSON; mDNS service is discoverable. **How to verify** After flash, from a host on the same LAN: ```bash # Direct call by IP (always works): curl http:///state | jq . # mDNS hostname (requires OS-level .local resolution: macOS Bonjour, Linux nss-mdns): curl http://viewport.local/state | jq . # Service discovery browse (preferred β€” what Scrypted will do, no OS .local resolver needed): dns-sd -B _scrypted-viewport._tcp local. # macOS avahi-browse -r _scrypted-viewport._tcp # Linux ``` Expected `/state` body on a fresh device (unconfigured): ```json { "name": null, "version": "0.1.0", "configured": false, "state": "unconfigured", "uptime_ms": 12345, "last_frame_ms_ago": null, "frames_received": 0, "decode_errors": 0, "state_post_failures": 0, "resolution": "480x800", "ip": "192.168.x.x", "free_heap": 200000, "free_psram": 30000000 } ``` Expected mDNS browse output should show a `_scrypted-viewport._tcp` instance with TXT records `version=`, `resolution=`, `orientation=`, `name=` (empty for `name`). **Status**: 🟑 builds clean against ESP-IDF 5.4 with espressif/mdns managed component. Awaiting first board run. --- ## M3 β€” Display Bring-Up **Acceptance**: panel powers on, MCU at I2C 0x45 responds, color-bar test pattern renders, brightness control works. **Wiring** (Hosyond 5" 800x480 panel ↔ Waveshare ESP32-P4-ETH): The DSI FPC adapter (15-pin Pi side β†’ 22-pin Waveshare side) carries the DSI data lanes and power. I2C and panel power are jumpered separately from the ESP32-P4 board to the Hosyond's auxiliary header (the same header Pi users normally connect to the Pi's 40-pin GPIO): | Hosyond panel pin | Wire to ESP32-P4 board | | --- | --- | | 5V | board 5V rail | | GND | board GND | | SDA | GPIO 7 | | SCL | GPIO 8 | GPIO 7/8 match Waveshare's BSP convention for touch I2C on their bundled-panel kit. If different pins are more convenient, change `PIN_I2C_SDA` / `PIN_I2C_SCL` in `display.c`. **Bring-up sequence** 1. Power the ESP32-P4 board over USB (don't plug DSI yet). 2. Connect 5V + GND jumpers to the panel. Panel LED (if present) should light. 3. Connect SDA + SCL jumpers. 4. Plug the DSI FPC cable. 5. Flash: ```bash idf.py -p /dev/cu.usbmodem* flash monitor ``` **Expected log** ``` I (xxx) display: panel MCU id 0xC3 β€” Pi 7" architecture ack'd I (xxx) display: panel powered on I (xxx) display: DSI up: 800x480 30 MHz, 2-lane 480 Mbps I (xxx) viewport: display up β€” test pattern on screen ``` **Visual check**: 8 vertical color bars (white, yellow, cyan, green, magenta, red, blue, black) across the panel. Brightness should look perceptually mid-range (default 80/100 with gamma). **Failure-mode signals** - `panel MCU @0x45 unreachable` β†’ jumper or pull-up problem on I2C, no need to suspect DSI yet. - I2C ack but no image β†’ DSI cable / FPC adapter orientation. Pi FPCs are easy to install upside-down. - Image but wrong colors β†’ check RGB565 byte order; flip `LCD_COLOR_PIXEL_FORMAT_RGB565` to a variant with swap. - Image but vertical/horizontal sync issues β†’ adjust the `PANEL_*SYNC_*` timings; Pi 7" canonical values used as defaults. **Status**: 🟑 builds clean against ESP-IDF 5.4. Driver ported from Linux `panel-raspberrypi-touchscreen.c`. Awaiting hardware bring-up with confirmed jumper wiring. --- ## M4 β€” Config Persistence **Acceptance**: `POST /config` persists across reboot; partial-update semantics work. **How to verify** ```bash # Full config: curl -X POST -H "Content-Type: application/json" \ -d '{"viewport":"mudroom","scrypted":"http://host/endpoint/scrypted-viewport","orientation":"landscape"}' \ http:///config # Read back: curl http:///config | jq . # Partial update (only brightness): curl -X POST -H "Content-Type: application/json" \ -d '{"brightness":50}' \ http:///config # Reboot, then re-read β€” values should survive: curl http:///config | jq . ``` Also verify validation: ```bash # idle_timeout_ms below 5000 (and non-zero) β€” expect 400: curl -i -X POST -H "Content-Type: application/json" \ -d '{"idle_timeout_ms":1000}' http:///config # bogus orientation β€” expect 400: curl -i -X POST -H "Content-Type: application/json" \ -d '{"orientation":"sideways"}' http:///config # brightness out of range β€” expect 400: curl -i -X POST -H "Content-Type: application/json" \ -d '{"brightness":150}' http:///config # scrypted without http:// β€” expect 400: curl -i -X POST -H "Content-Type: application/json" \ -d '{"scrypted":"scrypted.local"}' http:///config # Garbage JSON β€” expect 400: curl -i -X POST -H "Content-Type: application/json" \ -d 'not json' http:///config ``` Idle-timer disable (`idle_timeout_ms: 0`) is intentionally allowed. Side-effects to confirm: - After `POST /config` with `brightness`: panel brightness changes immediately (if display is up). - After `POST /config` with `viewport` or `orientation`: mDNS TXT records update; `viewport-.local` resolves; browse shows new TXT. - After `POST /config` with both `viewport` and `scrypted` (any order, on any subsequent call): `GET /state` shows `configured: true`, `state: "asleep"`. **Status**: 🟑 builds clean against ESP-IDF 5.4. Logic exercised in code but unverified on hardware. --- ## M5 β€” JPEG Frame Push **Acceptance**: `POST /frame` paints a 480x800 (portrait, default) or 800x480 (landscape) JPEG. Orientation determines the expected dimensions and the panel-side rotation. **How to verify** ```bash # Default orientation (portrait) β€” send 480x800: curl -X POST -H "Content-Type: image/jpeg" \ --data-binary @test-480x800.jpg \ http:///frame # Then switch to landscape and re-test with an 800x480 JPEG: curl -X POST -H "Content-Type: application/json" \ -d '{"orientation":"landscape"}' http:///config curl -X POST -H "Content-Type: image/jpeg" \ --data-binary @test-800x480.jpg \ http:///frame ``` Visual: image fills the panel correctly oriented. After paint, `GET /state` shows `frames_received` incremented and `last_frame_ms_ago` populated. Generate test JPEGs with ImageMagick: ```bash # 8 vertical color bars at 480x800 portrait: convert -size 60x800 gradient:white-black -duplicate 7 +append test-480x800.jpg # or just any 480x800 JPEG: convert -size 480x800 plasma: test-480x800.jpg convert -size 800x480 plasma: test-800x480.jpg ``` Negative tests: ```bash # Wrong Content-Type β€” expect 400: curl -i -X POST -H "Content-Type: image/png" --data-binary @anything \ http:///frame # Oversize β€” expect 413: dd if=/dev/urandom of=big.bin bs=1M count=2 curl -i -X POST -H "Content-Type: image/jpeg" --data-binary @big.bin \ http:///frame # Wrong dimensions β€” expect 400 with "expected WxH, got WxH": convert -size 640x480 plasma: test-640x480.jpg curl -i -X POST -H "Content-Type: image/jpeg" --data-binary @test-640x480.jpg \ http:///frame # Concurrent posts β€” second gets 503: curl -X POST -H "Content-Type: image/jpeg" --data-binary @test-480x800.jpg \ http:///frame & curl -i -X POST -H "Content-Type: image/jpeg" --data-binary @test-480x800.jpg \ http:///frame # expect 503 if first is still in flight # Garbage bytes claiming to be JPEG β€” expect 400: curl -i -X POST -H "Content-Type: image/jpeg" -d 'not a jpeg' \ http:///frame ``` After every error: `decode_errors` in `GET /state` should increment. **Known gap (M6 closes this)**: M5 paints regardless of wake/sleep state. The `/frame` β†’ `409` when asleep rule is added with `POST /state` in M6. Until then, a configured device boots ASLEEP per spec but `/frame` still paints because the state guard isn't wired yet. **Status**: 🟑 builds clean against ESP-IDF 5.4. Awaiting hardware verification (the test pattern from M3 confirms paint works; M5 adds the JPEG path). --- ## M6 β€” State + Idle Timer **Acceptance**: `POST /state` toggles wake/sleep; `/frame` is 409 when asleep; idle timer fires after `idle_timeout_ms`. **How to verify** ```bash curl -X POST -d '{"state":"sleep"}' http:///state # backlight off curl -X POST -d '{"state":"wake"}' http:///state # backlight on, loading # /frame while asleep: curl -X POST -d '{"state":"sleep"}' http:///state curl -i -X POST -H "Content-Type: image/jpeg" \ --data-binary @test-480x800.jpg \ http:///frame # expect: HTTP/1.1 409 Conflict # Idle timer (assuming default 60000ms): curl -X POST -d '{"state":"wake"}' http:///state # wait 65s without sending /frame curl http:///state | jq .state # expect: "asleep" ``` **Status**: ⬜ pending. --- ## M7 β€” Touch + Outbound `/state` POST **Acceptance**: tap toggles wake/sleep locally; device POSTs `{viewport,state}` to `/state`. **How to verify** Stand up a test HTTP receiver: ```bash # In a separate terminal on Scrypted host: python3 -m http.server 11080 # or a small flask app that logs body ``` Configure the device to point at it: ```bash curl -X POST -H "Content-Type: application/json" \ -d '{"viewport":"mudroom","scrypted":"http://:11080"}' \ http:///config ``` Then: - Tap while asleep β†’ device wakes, receiver logs `POST /state {"viewport":"mudroom","state":"wake"}`. - Tap while awake β†’ device sleeps, receiver logs `POST /state {"viewport":"mudroom","state":"sleep"}`. - Wait `idle_timeout_ms` with no `/frame` β†’ receiver logs same sleep POST. - Kill receiver, tap β†’ `/state` `state_post_failures` increments. **Status**: ⬜ pending. --- ## M8 β€” Local Screens + BOOT button **Acceptance**: IP screen on first boot; loading screen on every wake; BOOT button works. **How to verify** - Fresh flash β†’ screen shows `viewport.local` and the device IP centered. - `POST /config` β†’ IP screen clears; backlight off (device enters sleep). - Tap while asleep β†’ "Loading…" screen until next `/frame`. - BOOT short-press (any state) β†’ IP screen overlays for 15s, then prior state restored. - BOOT 5s-hold β†’ NVS clears, device reboots, IP screen reappears. **Status**: ⬜ pending. --- ## M9 β€” Live Stream (`POST /stream`) **Acceptance**: β‰₯ 10 fps multipart MJPEG over a single chunked POST. **How to verify**: ffmpeg-driven test stream from a host, measure fps from the device's frame counter. **Status**: ⬜ pending. --- ## Integration & system tests (post-M9) Run these once all milestones are implemented and individually verified. The point is to exercise races, edge cases, and longevity that single-milestone tests miss. ### A. End-to-end with Scrypted - Real Scrypted-side Script (M7's scope): doorbell-event β†’ `/state {wake}` β†’ frame stream β†’ idle timer fires β†’ `/state {sleep}` callback β†’ Scrypted stops. - Bound camera switching: change the binding in Scrypted, confirm next wake routes to the new camera. ### B. Race conditions - Concurrent tap-while-Scrypted-POSTs-`/state`: spam both, confirm the device converges (mutex serializes; last-write-wins). Use the wake/sleep counters in `/state` to track transitions. - Mid-stream tap-to-sleep: while Scrypted is streaming frames, tap to sleep. Inflight `/frame` should return 409. Confirm no half-painted frames, no re-wake. - Idle-timeout coincides with a fresh tap-wake: the second event wins. Verify by repeating with timing jitter. - Stale Scrypted sleep timer races a fresh wake callback: Scrypted-side `cancelPendingSleep` must work β€” if a stale sleep lands after a wake, viewport sleeps; user taps again; recovery in one extra tap. ### C. Failure modes - Cable pull mid-frame: device idle-sleeps after `idle_timeout_ms`. On reconnect, mDNS re-advertises; Scrypted re-finds and continues. - Scrypted unreachable on tap: device still toggles backlight, `state_post_failures` increments. Recovery: Scrypted comes back, next tap syncs. - DHCP lease change: device gets new IP, re-advertises via mDNS. Scrypted's periodic browse picks up the new address. - `/state_post_failures` count should be observable via `GET /state`. ### D. Longevity - 24h soak with a slow camera stream (~1 frame every 10s): verify no memory leaks (`free_heap` / `free_psram` stable in `/state`), no decode_errors growing. - Frame storm: 30 minutes at max sustainable fps. Verify watchdog never fires, no resets. ### E. Power & boot - PoE injector cycle: device boots clean, gets DHCP, re-registers via mDNS, no manual intervention needed. - Brown-out (PoE on edge of spec): device should reboot cleanly, not corrupt NVS. ### F. Negative protocol - Garbage JSON to `/config` β†’ 400. - `/frame` with `Content-Type: image/png` β†’ 400. - `/state` with `{"state":"middle"}` β†’ 400. - `/frame` with body > 1 MB β†’ 413. - Two concurrent `/frame` posts β†’ one wins, the other 503. ### G. Multi-viewport Once at least two physical units are configured: confirm each routes its callback to Scrypted with its own `viewport` name; confirm Scrypted's discovery map has both IPs; confirm a camera event on the wrong-named viewport is correctly ignored on the right one.