Multi-Station Dashboard and Station Discovery
Run OpenHTF on several test stations and see them from one place — the built-in dashboard_server, multicast station discovery, station_server history, configuration per station, and where the built-in tooling stops.
Last updated · Verified with OpenHTF 1.6.1
One OpenHTF process is one station running one test. A production line has several. This page covers what OpenHTF ships for that — a multicast-based dashboard listing stations on the LAN — and what it leaves to you.
How a station announces itself
station_server.StationServer (the process behind the Operator UI) joins a multicast group and answers discovery queries with its host, port and station ID. Defaults come from openhtf.util.multicast:
station_discovery_addressconfig239.1.1.1.station_discovery_portconfig10000.station_discovery_ttlconfig1 (default) stays on the local subnet.station_server_portconfig0 (random). Set it so the dashboard's links are stable.station_idconfigSet them per station in a YAML file passed with --config-file — see Production deployment.
The dashboard server
python -m openhtf.output.servers.dashboard_server --dashboard-server-port 12000 --no-local-onlyOpens http://localhost:12000: a list of every station discovered on the subnet, refreshed every --discovery-interval-s seconds (default 1), each linking to that station's own Operator UI. --no-local-only is required to list stations on other hosts; the default discovers only the local machine. All flags are on the CLI page.
The dashboard is a thin index. It does not aggregate results or history; clicking a station takes you to that station's UI, served by that station.
History per station
StationServer(history_path="/var/lib/openhtf/records") makes the station's UI list past runs from a directory of JSON records. Point OutputToJSON at the same directory:
RECORDS = "/var/lib/openhtf/records"
with station_server.StationServer(history_path=RECORDS) as server:
web_launcher.launch("http://localhost:4444")
while True:
test = htf.Test(*phases)
test.add_output_callbacks(
json_factory.OutputToJSON(f"{RECORDS}/{{dut_id}}.{{start_time_millis}}.json", indent=2),
server.publish_final_state,
)
test.execute(test_start=user_input.prompt_for_test_start())History is per station and per directory; two stations do not share it.
Network considerations
- Multicast discovery needs the stations and the dashboard host on the same L2 segment (TTL 1) or a router configured for the group. Many factory VLANs block multicast; if the dashboard stays empty, that is the first thing to check.
- Station UIs bind all interfaces on
station_server_portwith no authentication. Restrict with a firewall or reverse proxy if the network is shared. --config-value station_id=EOL-03on each launcher script keeps names unique when hostnames are generic.
Where the built-in tooling stops
| Need | Built-in | Alternative |
|---|---|---|
| List stations on the LAN | dashboard_server | — |
| See a station's live test remotely | Station UI over HTTP (no auth) | TofuPilot Operator UI: HTTPS + accounts |
| History across stations | No (per-station directory) | Central database via an output callback |
| Yield / Cpk across stations | No | Manufacturing Test Analytics |
| Run a different test per station from one place | No | Config per station, or TofuPilot procedures |
| Multicast blocked | Dashboard empty | Static bookmarks per station, or a hosted UI |
Related
Bundled plugs
The plugs that ship with OpenHTF — UserInput, ADB and Fastboot over USB (openhtf.plugs.usb), Cambrionix USB hubs, SerialCollectionPlug for serial logging, DeviceWrappingPlug — with install extras, configuration keys and usage.
Decorators
Learn how to use OpenHTF decorators to enhance your test phases with measurements, hardware plugins, and execution configuration.