Configure a station

The station uses two YAML documents. Its local config.yaml holds MQTT transport, certificate paths, API endpoint, station identity, and hardware programmer definitions. The runtime YAML in HTF's Station configuration defines the stages that run for a DUT. The station pulls that runtime plan when it starts. Your first station run shows both complete files.

The local sample loads settings from YAML. Environment variables fill in deployment-specific values without putting credentials in source control.

station:
  org_id: ${HTF_ORG_ID}
  station_id: ${HTF_STATION_ID}

stages:
  - name: print testing
    kind: print
    message: testing
    wait_seconds: 5

stages run in the plan's order. Each stage has a name for the result view and a kind that selects its implementation.

To edit the server-owned plan after creating a station, open that station in HTF, select Station configuration, paste the runtime YAML, and select Save for station pull. Restart or reconnect the station to load the saved revision.

HTF validates YAML during setup and shows specific validation errors when saving configuration changes. An invalid existing plan displays Saved configuration needs correction. Run htf-station check-config against the local file and exported runtime YAML before changing a jig. See Validate configuration for the commands and stage limits.

Expand values at run time

Runtime v0.3.0 leaves ${...} strings literal by default. Enable expansion on each stage that needs values from the DUT or run context:

stages:
  - name: Print DUT ID
    kind: print
    interpolate: true
    message: 'Testing ${dut_id}'
    wait_seconds: 0

References resolve once just before a stage runs; a missing reference fails the stage. Nested string settings, such as HTTP JSON fields and headers, can also expand. Stage names, kinds, routing, variable lists, locks, and dependencies remain static; numeric settings must be literal numbers. Uppercase ${ENV_VAR} expansion happens when loading configuration and is separate from runtime interpolation.

Add a programmer

For hardware flashing, define a named programmer and refer to it from each stage. The following is based on the station's basic programming sample; replace the serial number, target, image ID, and image path with your own values.

programmers:
  - name: jlink_1
    kind: jlink
    serial_number: 823000667
    target_device: nrf54l15_xxca

stages:
  - name: Device Erase
    kind: nrfutil_device_recover
    programmer: jlink_1
  - name: Flash Firmware
    kind: firmware_flash
    programmer: jlink_1
    firmware_id: 12b0cbe8-71d9-43fa-97b3-02202cf7d593
    firmware_version: latest
    path: zephyr/zephyr.hex

The sample uses a J-Link programmer, device recovery, and a firmware flash stage. The image must exist in your project and contain the referenced path.

Report selected DUT values

Add a stage capture mapping to retain outputs as structured observations. Use Capture DUT values for mappings, custom-stage calls, verification, and durable delivery.

Keep configuration safe

Keep credentials in protected environment variables or the station's secret mechanism. Do not place a password or API token in YAML, logs, or command-line arguments. See Station credentials and secrets.