Display override API

The optional display override API lets another device on the private network request a screen for five minutes. The request is an ordinary arbiter claim: calendar alerts, nearby flights, ISS passes, or any other claim with a higher configured priority can replace it. When that claim ends, the requested screen returns for the remainder of its lease.

Enable the listener in the display’s untracked .env file:

display_override_api_enabled=true
display_override_api_host=<LAN_BIND_ADDRESS>
display_override_api_port=5003

The listener defaults to loopback. Set display_override_api_host explicitly to the device’s LAN interface, or to the all-interfaces bind address, only when another private-network device needs to connect. Requests are still limited to loopback and private-network client addresses. On a trusted private network, set display_override_api_token and send it as a Bearer token. Plain HTTP does not protect that token from interception on an untrusted network; use encrypted transport before exposing the listener there. The default lease is 300 seconds and the default priority is 30; both can be changed with display_override_duration_seconds and display_override_priority.

Request one of token, weather, transit, calendar, iss, flights, flight_stats_day, flight_stats_week, flight_stats_month, or flight_records (codex remains an accepted alias for token, and flight_stats selects the weekly view):

curl -X POST http://DISPLAY_HOST:5003/api/display/token
curl -X POST http://DISPLAY_HOST:5003/api/display/iss
curl -X POST http://DISPLAY_HOST:5003/api/display/flight_stats_month
curl -X POST http://DISPLAY_HOST:5003/api/display \
  -H 'Content-Type: application/json' \
  -d '{"module":"weather"}'

token bypasses the normal recent-activity condition, but still needs a configured, non-stale token usage source. calendar shows the current agenda. Weather, transit, and calendar similarly need their data sources configured. flights shows up to four of the most recently observed nearby flights, newest first, using only identifiers, origin/destination codes, and observation times that were actually available. The in-memory history starts empty after a restart and is populated by normal live flight monitoring; requesting it does not poll either flight service. Live nearby-flight claims retain their higher priority and can interrupt this history screen.

The statistics screens use a bounded local SQLite history populated by the normal nearby-flight monitor; requesting a screen never polls a flight API. Repeated polls during one nearby pass count as one flyby, while the same plane returning after the configured encounter gap counts again. Day, week, and month mean the current local calendar day, Monday-based week, and calendar month. Each period highlights the busiest routes and operators that have metadata, then falls back to aircraft type, repeat visitor, and busiest-hour facts when route data is sparse. flight_records uses all retained history for oldest and youngest known airframes, the most-seen aircraft, the closest flyby, and the fastest observed groundspeed in knots. Aircraft age appears only when the ADS-B source supplies a plausible manufacture year. Retention, encounter gap, write throttle, and the ignored database path are configurable with the flight_statistics_* settings in .env.example.

A successful request can therefore be accepted without immediately rendering when data is unavailable or a higher-priority owner controls the screen.

iss shows the next future overflight already known to the ISS tracker, including its start time, countdown, duration, and peak direction/elevation. It does not make a fresh prediction request on demand. If the tracker is disabled, still warming up, or has no future cached pass, the screen says that no prediction is available. A live overhead pass keeps its existing higher priority and replaces this prediction card until the pass ends.

Inspect or clear the lease with:

curl http://DISPLAY_HOST:5003/api/display
curl -X DELETE http://DISPLAY_HOST:5003/api/display