Proposal: Support digital signage style displays

[chrisbues]

How this would work in my head:

1. Support a generic display device, with a resolution of X by Y (HD, 4k, etc).
2. Build a dashboard targeting that device
3. Build a schedule that includes the device
4. Rendered dashboard images are available via https
5. Point any digital sign at the dashboard/schedule URL to retrieve the image.

[dmellok]

Most of this already works, so it's worth trying before we design anything.

1 and 2. Settings → Devices → Add device, choose REST as the transport and Custom for the panel size, then enter 1920x1080 or whatever the sign runs at. Build a page against it as normal.

3. Lineups already handle the scheduling, and they're per-device, so there's nothing extra to do there.

4 and 5. Two URLs already exist for this:

• /preview/<device_id>.png is a stable per-device URL that always serves the latest render. Point any sign that takes an image URL straight at it.
• /mirror/<device_id> is an HTML page that embeds the above and refreshes itself. It takes ?refresh=N in seconds, and ?rotate=90 if the screen is mounted sideways.

Both are reachable from any client on your private network without a credential. There's no separate schedule URL and there doesn't need to be: the lineup decides what the device is showing, so the per-device URL follows it automatically.

Two things to set up differently from an e-ink panel:

• Declare the gamut as rgb24, which skips quantisation and dithering entirely. The e-ink defaults will otherwise dither a full-colour screen.
• The image is only as fresh as the last push. The mirror page can poll every 5 seconds, but what's behind it changes on push cadence, which is tuned for panels that take seconds to repaint. If you want something closer to live, say what interval you're after.

Worth knowing too that a 4K render is 8x the pixels of 1080p through the headless browser on every push, and the widget layouts are sized around e-ink panels, so a 4K canvas will read as sparse until the content is scaled to match.

What's genuinely missing is auth for a sign that isn't on the same network. /preview/ is only credential-free on the LAN; from outside it sits behind the login, and most signage players can only fetch a plain URL with no headers. A per-device URL token would close that, and it's the piece I'd turn into an issue. What are you pointing at it? If the player can send a header there's already a per-device token you can use today; if it can only take a URL, the token has to live in the query string, which is a different design with different tradeoffs.

[chrisbues]

My current use case is this: https://anthias.screenly.io/, running on a Pi4. It can send headers as part of the request when adding an asset from a URL.

In 0.318 - running as the HA add-on, I am not seeing a way to add a REST device without going through the pairing process:

[dmellok]

Good catch, the REST branch only issued a pairing code, and the form with device id, kind and panel size sat in the MQTT branch. A signage player never calls /register, so pairing can't complete.

The REST branch now has an Add without pairing form with the same fields (v0.335.0, on edge now). It creates the device on the REST transport and mints its access token in one step, which is the shape your case needs: a display that fetches an image URL and never checks in.

For Anthias on a Pi4 on the same network, you don't need a credential at all. /preview/<device_id>.png and /mirror/<device_id> are reachable from any private-network client. Point Anthias at the preview URL and set the device's gamut to rgb24 so it skips e-ink quantisation.

One clarification on headers, since it changes what to try: the per-device token authenticates the /api/v1/device/... routes, not /preview or /mirror. Those two take a private-network client or an admin session, so from outside the LAN they return 403 whether the token arrives as a Bearer header, in the query string, or not at all. /api/v1/device/<id>/frame.bmp does accept the token both ways, but it's capped at 1 MiB and a 1080p full-colour frame is around 6 MB, so it errors rather than serving; that route is shaped for e-readers.

So remote signage still needs authenticated access to the image URLs, and I'll open an issue for it.

Is the Pi4 on the same network as your Tesserae install? If so this is working for you now; if not, that issue is your blocker rather than a side note.

[bablokb]

There is a Python-API available for all of this: https://github.com/bablokb/circuitpython-tesserae. Although the repo carries "circuitpython" in its name, it also works with CPython.

If you want the whole workflow, you could use the CircuitPython client from https://github.com/bablokb/tesserae-device-circuitpython. This client runs fine on all kind of platforms: MCUs, Pi, Linux, Mac, Windows (to be confirmed) with all kind of displays.