Reference

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_addressconfig
Multicast group. Default 239.1.1.1.
station_discovery_portconfig
UDP port. Default 10000.
station_discovery_ttlconfig
Multicast TTL — 1 (default) stays on the local subnet.
station_server_portconfig
HTTP port of the station's UI. Default 0 (random). Set it so the dashboard's links are stable.
station_idconfig
Name shown in the dashboard and stored in every record. Default hostname.

Set them per station in a YAML file passed with --config-file — see Production deployment.

The dashboard server

Terminal
python -m openhtf.output.servers.dashboard_server --dashboard-server-port 12000 --no-local-only

Opens 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:

main.py
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_port with no authentication. Restrict with a firewall or reverse proxy if the network is shared.
  • --config-value station_id=EOL-03 on each launcher script keeps names unique when hostnames are generic.

Where the built-in tooling stops

NeedBuilt-inAlternative
List stations on the LANdashboard_server
See a station's live test remotelyStation UI over HTTP (no auth)TofuPilot Operator UI: HTTPS + accounts
History across stationsNo (per-station directory)Central database via an output callback
Yield / Cpk across stationsNoManufacturing Test Analytics
Run a different test per station from one placeNoConfig per station, or TofuPilot procedures
Multicast blockedDashboard emptyStatic bookmarks per station, or a hosted UI

On this page

First-pass yield
0%4.1
Track with TofuPilot