Governed community feed
Shows approved featured, upcoming, and Community content from GFAVIP. Cards include a section, type, title, summary, and timing label.
Field-tested pilot · July 2026
GFAVIP Community Display
A small, secure community screen with a path to CasaNode.
The current ESP32 pilot turns approved GFAVIP announcements, featured content, and upcoming items into a touch-friendly desk display. It pairs as its own restricted device, manages Wi-Fi locally, validates HTTPS, and keeps useful content visible when the network disappears.
320×240 landscape 60 sec refresh 12 cards maximum 32 KB feed ceiling
Node status is ready
GFAVIP content today. CasaNode signals next.
1 / 2
ONLINE R42
ESP32-2432S028 · 2.8-inch resistive touch
Available today
What the ESP32 already does
This is running firmware, not a concept mockup. The behaviors below were built and exercised on physical devices. Anything planned for Raspberry Pi is marked separately.
Touch navigation
Previous and Next move through as many as 12 cards. Details opens a bounded, scrollable description with explicit Close and X controls.
Resilient operation
Refreshes every 60 seconds, retries failures every 15 seconds, reconnects Wi-Fi, and keeps the last validated feed available offline.
Self-service Wi-Fi
A local, temporary setup network lets an operator scan or enter a 2.4 GHz network. New credentials are tested before the known-good profile is replaced.
Current live path
GFAVIP remains the authority.
Administrators publish content for the display surface. The service applies audience and publication rules before the device receives anything. The display cannot see an administrator session, member token, Wallet credential, payment credential, or private key.
1 · PublishCommunity AdminApproves display content
→ 2 · GovernGFAVIP Display APIFilters surface + audience
→ 3 · RenderESP32 displayPolls, validates, and caches
Connection and identity
Wi-Fi stays local. Device access stays restricted.
Local Wi-Fi setup
Settings starts a temporary WPA2 network named GFAVIP-Setup-XXXX. A random one-time code appears only on the TFT. The phone opens http://192.168.4.1 to scan, select, or manually enter a 2.4 GHz SSID.
Transactional credentials
The candidate network runs from RAM first. Only a successful connection replaces the previous profile with one checksummed NVS record. Failure, Cancel, or the ten-minute timeout preserves the known-good network.
Administrator pairing
The device requests a short-lived code. A GFAVIP administrator approves it in Display Fleet, and the device redeems the claim for its own individually revocable gfd_ bearer credential.
Verified HTTPS
Requests use the ISRG Root X1 trust anchor with certificate and hostname verification enabled. There is no insecure TLS fallback.
Software and architecture
A bounded Arduino firmware with explicit recovery states.
The build targets a generic ESP32 board and pins all important toolchain and library versions for reproducibility.
Arduino on ESP32
Arduino CLI 1.5.1 with Espressif Arduino-ESP32 3.3.0. The pilot is not an ESP-IDF or PlatformIO project, although it uses selected ESP-IDF Wi-Fi functions through Arduino.
TFT_eSPIXPT2046ArduinoJsonLittleFSPreferences
community_feed.ino
Rendering, touch input, feed parsing, HTTPS polling, cache states, diagnostics, Wi-Fi recovery, and the temporary setup portal.
display_pairing.ino
Creates and polls the one-time claim, validates the returned restricted credential, and stores it without logging it.
Probe, calibrate, verify
Separate serial, TFT, touch, calibration, and HTTPS probes keep risky assumptions out of the production sketch.
USB flash only
The partition table has two application slots, but signed download, authenticated OTA, rollback policy, and remote firmware management are not implemented.
1,189,632-byte app
Each 1,310,720-byte application slot leaves about 121 KB—or 9.2%—of conservative firmware headroom.
Current network contract
Endpoints used by the device
POST
/api/display/pairings Creates a short-lived display pairing request and one-time claim.
GET
/api/display/pairings/status Polls the claim until an administrator pairs the device or the claim expires.
GET
/api/display/feed Returns the governed, audience-filtered display feed for the paired device.
POST
/api/display/check-in Reports minimized operational metadata after a successful refresh.
Base URL: https://webchat.gfavip.com. Feed responses are capped at 32 KB, parsed into at most 12 bounded cards, and cached only after successful validation.
Hardware reference
The exact pilot board and measured pin map
These values describe the yellow dual-USB ESP32-2432S028 units used in the pilot. Production batches must be verified rather than assumed identical.
Board inventory
- Board
- ESP32-2432S028, yellow dual-USB revision
- MCU
- ESP32-D0WD-V3 rev. 3.1 · 240 MHz · 4 MB flash · no PSRAM
- Display
- 2.8-inch TFT · 240×320 native · 320×240 landscape
- Display driver
- ILI9341-compatible via TFT_eSPI ILI9341_2_DRIVER
- Touch
- XPT2046 resistive controller on a separate SPI bus
- USB serial
- CH340C · Micro-USB data connection
- Power
- Regulated 5 V over Micro-USB; measured current is not yet documented
- On-board extras
- microSD socket, RGB LED, LDR, amplified speaker connector
Confirmed pins
- TFT SPI
- MISO 12 · MOSI 13 · CLK 14 · CS 15 · DC 2
- Backlight
- GPIO 21 · active high
- Touch SPI
- MISO 39 · MOSI 32 · CLK 25 · CS 33 · IRQ 36
- RGB LED
- GPIO 4 / 16 / 17 · active low
- microSD
- MISO 19 · MOSI 23 · CLK 18 · CS 5
- Speaker / LDR
- Speaker 26 · LDR 34
Untested extras
The microSD slot, speaker path, and LDR are inventoried but not accepted as working product features.
Known limits
What remains rough or incomplete
2.4 GHz only
Hotel captive portals, enterprise authentication, unsupported channels, and some setup-AP clients remain problematic. Manual SSID entry cannot solve an incompatible radio or authentication mode.
No flash encryption
A physical attacker could extract NVS on this development board. The display token is deliberately restricted and revocable, but a production revision needs secure provisioning and flash encryption.
Calibration is unit-sensitive
The accepted affine calibration works on the tested unit. A manufacturing batch needs controlled sampling or per-device calibration.
Recovery gates remain
Deliberate factory reset, complete revocation/replacement, ten-minute setup timeout, and all publish/update/expiry transitions still need full physical acceptance.
Little flash headroom
The current binary consumes about 90.8% of an application slot. New device-side features must stay small and be remeasured for both flash and runtime heap.
Supervised pilot only
Attendee distribution needs a controlled BOM, enclosure and strain relief, certified power guidance, thermal/ESD tests, signed updates, support, and decommissioning.
Proposed integration · not implemented
How a Raspberry Pi running CasaNode OS could fit
The ESP32 and Pi can communicate over the same local 2.4 GHz network, but they do not talk to each other today. The cleanest first slice is a read-only status path—not a general remote shell and not a second large application on the ESP32.
ESP32 polls a tiny Pi status endpoint
CasaNode exposes a versioned, bounded JSON document on the LAN. The ESP32 polls it every 10–30 seconds, renders a compact node card, and falls back to the normal GFAVIP feed if the Pi is absent.
- Read-only endpoint such as
/api/casanode/display/v1/status - Small payload, fixed schema, strict string and array limits
- Per-display local token or HMAC—not an administrator credential
- No inbound listener required on the ESP32 during normal operation
CasaNode publishes through GFAVIP
A future approved server integration can convert Pi status into governed display content. The ESP32 keeps using /api/display/feed, while GFAVIP remains the remote authority and audit surface.
- Works beyond the local network
- Reuses targeting, expiry, and Display Fleet
- Requires a server-side CasaNode publisher integration
- Not suitable for rapid local telemetry
Suggested phase-one schema
Small enough to reason about.
Start with status only: identity label, health state, one headline, one detail line, and an update time. Add metrics only after measuring memory and screen value.
{
"schema": "casanode.display.v1",
"node": "home-node",
"state": "healthy",
"headline": "CasaNode is online",
"detail": "Backups complete · 3 services active",
"updatedAt": "2026-07-31T09:30:00Z"
}Control surface comes later.
The touchscreen could eventually trigger explicit actions such as “run backup” or “restart one service,” but only through allowlisted action IDs, confirmation UI, replay protection, timeouts, and a dedicated local credential. Arbitrary commands, SSH keys, and Pi administrator tokens should never live on the display.
Evidence and handoff
What other agents should treat as authoritative
Display + touch
Landscape color, touch calibration, buttons, and scrolling details were confirmed on physical hardware.
Network + TLS
Saved Wi-Fi, trusted time, certificate and hostname validation, and an HTTPS 200 response were confirmed.
Pairing + feed
Two devices received separate restricted credentials and rendered governed public content.
Soak + reboot
Ten consecutive power cycles passed; an eight-hour run reached refresh R514 with zero recorded failures.
Distribution readiness
Suitable for a supervised pilot—not yet a finished gift or unattended consumer appliance.
Recovery + lifecycle
Signed OTA, destructive reset, flash encryption, production calibration, and complete revocation testing remain open.
Source of truth
Firmware and hardware documentation
The implementation lives inside the private GFAVIP Chat repository. Authorized collaborators should start with the README, then use the hardware, build, security/recovery, and acceptance documents for measured detail.
firmware/gfavip-esp32-tft-pilot/ ├── README.md ├── HARDWARE.md ├── BUILD.md ├── SECURITY-RECOVERY.md ├── ACCEPTANCE.md ├── community_feed/community_feed.ino ├── display_pairing/display_pairing.ino └── host_tests/ Design principle
Keep the display small. Keep CasaNode capable.
The ESP32 should remain a bounded screen and touch surface. CasaNode should own local services, richer state, policy, and execution. GFAVIP should continue to own remote identity, governance, and fleet visibility.