dmellok/tesserae

Background Every ESP32-shaped SKU currently ships as its own hardware-catalog manifest under hardware//.json with fixed panel.w, panel.h, and panel.gamut. That's clean for known-shape SKUs (E1001, E1002, E1004, PhotoPainter 7.3, EE02, etc.), but it forces a manifest add + release per new panel. For CircuitPython clients (e.g. Bernhard's forthcoming CP driver), the client itself already knows its panel dimensions and colour depth. Requiring a per-board Tesserae release to add a matching manifest is unnecessary friction. Existing infrastructure that's already close: /api/v1/device/discover accepts panel_w and panel_h in the payload (see docs/dev/client-protocol.md). devices/circuitpython_generic/ folder-defined kind exists. Auto-provision flow in app/rest_api.py already reads the discover payload before creating the instance. What's missing: the dims / gamut from /discover don't get stored on the instance's manifest, so the kind's own default panel wins, which means the same generic ki

Context The existing docs/compatibility.md covers the renderer × panel matrix (which renderer drives which panel, status badges). What's missing is a single page that captures host hardware recommendations and empirically-tested performance for both halves of a Tesserae deployment: Server side: which boards run the Tesserae server well, with real-world performance data (RAM headroom, render time, supported panel count). Client side: which microcontroller boards work as clients for which panels, with memory-floor notes (framebuffer size vs available SRAM/PSRAM). Community testing already surfaces real data points that have no permanent home today, including a Pi 3B server confirmation from discussion #30 and PSRAM-equipped board recommendations from discussion #24. Both currently live only as discussion comments. Proposed approach A new page docs/install/hardware-recommendations.md (or similar) structured as two tables: Server hardware table Board RAM Status Rendering performance

Context Currently we ship two separate cloud-init yamls: scripts/cloud-init.yaml: installs the Tesserae server only (typical: LXC container, Docker host, dedicated server box). scripts/pi-client-cloud-init.yaml: installs only the pi-bin client (assumes Tesserae server is on another machine on the LAN). For a new user with a single Raspberry Pi + a Pimoroni Inky who wants the simplest possible path, neither yaml is ideal: the server one doesn't drive the panel, the client one assumes a server elsewhere. The natural fit is a single bundled cloud-init that installs BOTH on the same Pi with server_url = http://localhost:8765 baked in. One SD card, one boot, one device. Suggested in discussion #30. Proposed approach A new scripts/pi-bundled-cloud-init.yaml that's the union of the two existing yamls with localhost wiring: flowchart LR A[Pi 4/5 + Inky panel] -->|one SD card<br/>one cloud-init| B[Boot] B --> C[Tesserae server<br/>+ pi-bin client<br/>both as systemd]

Context OpenDisplay is an open standard and open firmware for e-paper displays. It's philosophically aligned with Tesserae: Sender-side rendering (sender does the dithering, palette mapping, etc.) Receivers are cheap, low-power, battery-friendly No cloud in the middle, open spec Their canonical wire transport is BLE GATT (service 0x2446), with optional Wi-Fi LAN on reference firmware. Reference firmware runs on ESP32-S3/C3/C6, nRF52840, and Silicon Labs BG22. A clean Python library exists: py-opendisplay. Adding support to Tesserae means bridging Tesserae's IP transport to OpenDisplay's BLE transport. Tesserae's host process shouldn't grow a Bluetooth dependency; the bridge lives in its own repo. Proposed approach A separate bridge process (tesserae-device-opendisplay-bridge) that looks like a Tesserae REST client on one side and an OpenDisplay BLE sender on the other. ┌──────────────┐ REST / SSE ┌──────────────