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").