# Stations

## What is it?

A station (test station) is a workstation or measurement setup where test
cases are executed. Stations are assigned to test steps, taken into account
for scheduling, and automatically deliver measurements via their API key.
Every station has a type (with freely configurable properties) and a status
(available, in use, maintenance, out of service).

## How to use it

- **Overview / Live measurements:** The stations page has two tabs.
  "Overview" is the table of all stations. "Live measurements" shows the
  currently incoming measurements for one or more selected stations at once,
  side by side — handy for watching several test benches at a glance without
  switching to each detail page individually.
- **Creating one:** Stations → *New station*. Choose a type; the type's
  properties (Settings → Station Types) are offered for you to fill in.
- **Creating a new station type:** Settings → Station Types → *New type*.
  This opens a two-step dialog: first just the type's name, and only after
  "Next" does the second step follow, where custom properties (fields) can be
  defined, just like on existing types — a progress bar at the top of the
  dialog shows both steps.
- **Table columns:** Besides name, status, type, and location, the table
  automatically shows one column per global property
  (Settings → Station Types → Global properties). The "Columns" button lets
  you additionally show any type property — the selection only applies to
  your own account, missing values show "–".
- **API key:** On the detail page. It authenticates the station to
  measurement ingestion (see `messdaten`). The key is shown **once**
  in plaintext and can be **rotated** at any time — the old one becomes
  invalid immediately.
- **Assigning:** In a test sequence, each step is assigned a station; this
  drives scheduling and utilization.
- **CSV/Excel import and export:** "Export" at the top of the page delivers
  every station as CSV or Excel (.xlsx), including type (plain-text name) and
  every defined property (type and global properties, one `property_<key>`
  column each). "Import" reads the same layout back in; a type name that
  isn't found produces a warning after import, and the station is still
  created without a type. The API key is not part of the import — it is
  deliberately never assigned on import (see above). Rows without a name are
  skipped.
- **Import preview:** After selecting a file, a preview opens first — nothing
  is saved yet. It shows, per row, whether a new station will be created or
  an existing one updated (or the row skipped), plus any issues such as
  invalid status, unknown type, invalid property values, or an unknown ID.
  For an update, the preview additionally lists every field that will
  actually change, one by one (old value → new value, including properties)
  — fields with no change don't appear. For very large files, the preview
  shows only the first 200 rows in detail;
  the summary counts above still cover every row. Only clicking "Import
  entries" writes the data; "Cancel" discards the file without any changes.
- **Editing via export → import (no duplicates):** The exported file's first
  column is each station's ID. An edited export file (values changed, new
  rows appended with the ID column left blank) can be re-imported safely:
  rows with a known ID update the existing station instead of creating a
  second one, only rows with no (or an unknown) ID create a new station.
- **Properties:** The "Properties" section sits right at the top of the
  detail page (before bookings) and shows the station type's custom fields as
  well as the organization-wide global properties, with their values for this
  station — still edited via "Edit".
- **Photo:** Upload a photo of the station in the create/edit form — e.g. to
  recognize it in the lab. On the detail page it appears to the left of
  properties and live measurements once one is set; without a photo the view
  is unchanged. PNG and JPG are allowed, up to 2 MB; a new photo replaces
  the previous one, and "Remove" in the form clears it again.
- **Bookings:** Below the booking calendar, the same occupancy is a
  searchable, sortable table — one row per test case (not per sequence),
  plus reservations and the next maintenance date, with search (name/
  sequence/project or the reserving person), a sortable planned-date column,
  and up to 10 rows per page.
- **Capacity/maintenance:** The next maintenance date is shown in the
  "Service logs" section further down the detail page and can be set there
  directly — a note lets you record what the maintenance involves (e.g.
  "calibrate force sensor"). Maintenance dates and reservations appear in the
  lab calendar. The standalone "Maintenance" page (Plan → Maintenance)
  lists every test station with a scheduled date across the organization,
  including the note column, sorted by due date, and highlights overdue ones
  in red.
- **Logging maintenance:** Via "Log maintenance" — on the Maintenance page
  per station, and on the station detail page next to the maintenance date —
  you record the date performed, an optional protocol (file), and the new
  next due date in one step. The detail page's maintenance date updates
  automatically; if the station was set to *Maintenance*, its status
  automatically jumps back to *Available* afterwards. Every entry appears
  right below in the same "Service logs" section (maintenance history
  including protocol download).
- **Reserving:** The "Create reservation" button next to the booking calendar
  on the detail page locks the station for a period — e.g. for maintenance, a
  rebuild, or other downtime. A reason is required. Once start and end are
  set, the form shows an amber warning listing every test case and
  reservation that overlaps the chosen period — creating it anyway is still
  possible, the warning doesn't block anything, it just calls out the
  overlap. Existing reservations show as a list right below the calendar,
  each with an edit and a delete button — "Edit" opens the same form
  pre-filled with start, end, and reason, including the same conflict warning
  (the reservation being edited doesn't count as a conflict with itself). If
  the reservation overlaps test cases already
  scheduled on that station, after creating it, it shows up like any other
  double-booking as an overbooked window (see "Resolving double-bookings"
  below) — there the reservation itself can also be moved to a different
  station or time; anyone without permission to edit it just sees it for
  information only. Reservations also appear in the lab calendar, as well as
  their own (violet) bar in the occupancy calendar, on its own row whenever
  it overlaps a test case.
- **Quickly change/clear the maintenance date:** On the Maintenance page,
  two more buttons sit next to "Log maintenance" for each station: "Clear
  date" removes the planned date right away (with confirmation), "Adjust
  date" opens the calendar directly for a new date — no need to open the
  "Date" column first.
- **Files:** Protocols and station documents are not public — they are served
  only to signed-in members of your own organization, so a shared download link
  is useless to outsiders. The usual office and measurement formats are allowed
  (PDF, CSV, Excel, Word, ZIP, images, measurement files); active formats such
  as HTML or SVG are rejected on upload, because a browser would execute them.
- **Live measurements:** On the station detail page, the "Live measurements"
  section shows all measurements currently arriving at this station —
  regardless of which test case they belong to. Useful for checking whether a
  station is sending data at all, even without a running test case open.
  Pure read channel, no target limits (those depend on the respective test
  case and are evaluated on the test case detail page).
- **Customizing built-in fields:** Under Settings → Station Types, in the
  "Global properties" section, name and location can be renamed (e.g.,
  "Location" → "Hall/Area"). Location can additionally be hidden if it isn't
  needed in your lab. The name always stays visible since it identifies the
  station. The customization applies organization-wide across all station
  types and affects forms, lists, and detail pages.
- **Jumping to a test case's detail page:** In the occupancy calendar
  (station list and station detail page), each bar represents a single test
  case, not its whole sequence — clicking it takes you straight to that test
  case's detail page within its sequence. A sequence with several test cases
  on this station shows up as several bars accordingly.
- **Resolving double bookings:** If the time ranges of multiple bookings —
  test cases and/or reservations — overlap on a station, the station detail
  page shows this as *one* overbooked period, even if three or more bookings
  are involved. The overbooked-period notice in the occupancy calendar
  (station list and project schedule) links directly to the affected
  station. Via "Resolve conflict" there, a dialog opens:
  1. Choose which booking should yield — a single test case or a
     reservation. Anyone who can't edit one of the two kinds (test cases need
     the project edit permission, reservations the station edit permission)
     sees it there for information only, with no way to select it.
  2. Choose one of two options:
     - **Different station** — the list first shows available stations;
       occupied ones are marked "occupied until …" and can't be selected,
       as are stations under maintenance or out of service.
     - **Reschedule** — moves the booking to the same station but a
       different time. The earliest available slot is preselected; it can be
       changed.

## Common issues

- **"My station doesn't show up in scheduling."** It must be assigned to a
  sequence step and must not be *out of service*.
- **"The occupancy calendar on the station list doesn't show all
  projects."** With many projects, it shows the 50 most recent and notes
  that above the calendar. Dates come from the sequences' dependency graph,
  which requires the full sequence tree of a project to be loaded — hence the
  limit. **One** station's occupancy is always shown in full on its detail
  page: only the projects that actually use this station are considered
  there.
- **"The API key no longer works."** If it was rotated, the old key is
  invalid — use the current one from the detail page. The plaintext can't be
  shown again; if in doubt, rotate again.
- **"I can't see the API key."** For security reasons only a hash is stored;
  the plaintext appears once when generated/rotated.
- **"Station deleted — what happens to the data?"** Stations are soft-deleted;
  already recorded measurements and history remain, the station just becomes
  unselectable.
- **"Incoming measurements aren't evaluated as OK/NOK."** The limits for that
  live on the test case, not the station (see "Expected measurements" in
  `testsequenzen`). Check whether the test case even defines an expected
  measurement with limits for the channel name being sent.
- **"Live measurements stay empty."** Either the station isn't sending data
  yet (check the API key, see `messdaten`), or the values are older
  than the live view's display window — already recorded values still remain
  in the respective test case's history.
- **"Why does a station show as occupied when the conflict is elsewhere?"**
  The availability display in the resolve dialog checks the *time range of
  the sequence being moved* at this station — not just the overbooked period
  itself. A sequence can run longer than the conflict lasts; "occupied
  until …" then shows the end of the actual booking.
- **"I only moved some of the test cases — does the rest keep running on the
  old station?"** Yes. When rescheduling, only the checked test cases move;
  all other test cases in the same sequence remain unchanged on the previous
  station.
- **"Fewer stations were created than expected on import."** Rows without a
  name are skipped — the count is shown in the message after import.
- **"A property from my import file is missing on the imported station."**
  Either the value was invalid for the field type (reported as "invalid
  property values"), or the column isn't a known property of that type or a
  global property (reported as "unrecognized columns ignored").
- **"The file could not be read."** Either the file is corrupt or, despite
  the .xlsx extension, not a real Excel file, or it contains invalid
  characters — in both cases nothing is imported.
- **"After re-importing, the station exists twice."** Check whether the ID
  column survived in the edited file — if it was deleted or cleared, the
  import treats the row as a new station.

- **"A type with this name already exists."** Station type names are unique
  within the organization, regardless of capitalization. Two entries named
  "Climate chamber" would be indistinguishable in the selection lists. Either
  use the existing type or pick a distinguishing name ("Climate chamber large").

---

Source: https://www.testlabiq.com/en/help/stations