Messdaten

Prüfstände mit MQTT? Siehe MQTT-Anbindung — gleiches Payload-Format, gleicher API-Key, nur der Transportweg ist ein anderer.

Was ist das?

Der Abschnitt „Messdaten" auf der Testfall-Detailseite zeigt alle Messwerte eines Testfalls in einer einzigen Ansicht — als Kacheln (letzter Wert je Kanal, Min/Max) oder als Diagramm mit Grenzwertvergleich. Das gilt unabhängig davon, wie die Werte hereingekommen sind: automatisch per REST/MQTT während der Prüfung, per CSV-Upload während der Durchführung, oder nachträglich per CSV-Upload, nachdem der Testfall schon abgeschlossen ist. Es gibt nur diese eine Quelle — keinen separaten „Live"-Bereich und keinen getrennten „Anhang mit Diagramm-Vorschau" mehr.

Solange der Testfall läuft, aktualisiert sich die Ansicht laufend (grüner Punkt „Live"). Nach Abschluss (Bestanden, Fehlgeschlagen, Übersprungen, Abgebrochen) zeigt derselbe Abschnitt schreibgeschützt den vollständigen Verlauf — inklusive aller Werte, die erst danach nachträglich hochgeladen wurden.

Über die Schaltfläche „Diagramm" lässt sich die Darstellung anpassen (Diagrammtyp, Trendlinie, Legende, Achsen …). Bei nur einem Messkanal ist die Legende standardmäßig ausgeblendet, da sie dann nichts unterscheidet — sie lässt sich über dieselbe Schaltfläche jederzeit einschalten.

So kommen Messwerte rein

REST-API: POST /api/v1/measurements mit dem API-Key des Prüfstands im Header x-api-key (alternativ Authorization: Bearer <key>):
```
{
  "sequenceItemId": "<uuid>",
  "measurements": [
    { "timestamp": "2026-06-30T08:00:00Z", "channelName": "U_in",
      "value": 12.1, "unit": "V", "quality": 100, "metadata": {} }
  ]
}
```
sequenceItemId steht auf der Testfall-Detailseite im Abschnitt „Messdaten" (Kopieren-Button neben der ID). quality (0–100) und metadata sind optional. Ohne sequenceItemId werden Werte nur dem Prüfstand zugeordnet (z. B. beim Aufwärmen/Kalibrieren, bevor ein Testfall läuft) und erscheinen nur auf dessen Prüfstand-Seite.
MQTT — siehe MQTT-Anbindung.
CSV-Upload während der Durchführung: im Dialog „Testfall wurde durchgeführt" oder direkt im Messdaten-Bereich über „Hochladen" — landet wie REST/MQTT sofort in der Live-Ansicht und fließt in die automatische Grenzwert-Auswertung ein. Pflichtspalten: timestamp, channelName, value, unit (optional quality), maximal 10.000 Zeilen je Datei.
CSV-Upload nach Abschluss: derselbe „Hochladen"-Button im Messdaten-Bereich, jetzt aber gegen einen bereits terminal gewordenen Testfall — die Werte werden direkt der dauerhaften Ablage dieses Testfalls hinzugefügt (siehe unten) und erscheinen unmittelbar im Diagramm. Kein Zeilenlimit wie beim laufenden Testfall, nur die allgemeine Dateigrößengrenze von 50 MB.
Status startet automatisch: Ein noch ausstehender Testfall wechselt beim Eintreffen der ersten Messwerte automatisch auf „In Bearbeitung".

Wie lange bleiben Messdaten gespeichert?

Aktuelle Werte liegen in der schnellen Live-Datenbank, aber nur für ein rollierendes Zeitfenster von rund 24 Stunden. Ältere Werte werden automatisch (stündlich, im Hintergrund) in eine dauerhafte CSV-Ablage je Testfall überführt — nichts geht dabei verloren, das ist für die Anzeige unsichtbar: die Messdaten-Ansicht zeigt jederzeit den vollständigen, korrekten Verlauf, egal ob ein Wert gerade eben live eintraf oder schon vor Wochen archiviert wurde. Das gilt auch für Testfälle, die länger laufen als das rollierende Fenster (z. B. mehrtägige Klimatests) — der Export läuft unabhängig vom Testfall-Status weiter, nicht erst beim Abschluss.

Beim Abschluss eines Testfalls werden alle noch verbleibenden Werte sofort archiviert; ab dann gibt es für diesen Testfall genau eine dauerhafte Messdaten-Datei, die auch aus Rückverfolgbarkeitsgründen (ISO 17025) erhalten bleibt.

Prüfstandsstatus per API setzen

Zusätzlich zu Messwerten kann ein Prüfstand über denselben API-Key auch seinen eigenen Status setzen:

PATCH /api/v1/stations/me/status mit demselben Header und Body { "status": "IN_USE" }. Gültige Werte: AVAILABLE, IN_USE, MAINTENANCE, OUT_OF_SERVICE. Es gibt bewusst keine id im Body — der API-Key legt den Prüfstand fest, ein Prüfstand kann nur sich selbst ändern.

Der Testfallstatus selbst muss dafür nicht separat gesetzt werden: er springt beim Eintreffen der ersten Messwerte automatisch auf „In Bearbeitung". Das eigentliche Prüfergebnis (Bestanden/Fehlgeschlagen) bleibt bewusst ein manueller Schritt in der Oberfläche („Testfall wurde durchgeführt").

Typische Probleme

Antwortformat bei Fehlern. { "error": { "code": "...", "message": "..." } } — der code (PERMISSION_DENIED, VALIDATION, NOT_FOUND, LIMIT_EXCEEDED) ist stabil und lässt sich programmatisch auswerten.
401 — API-Key fehlt / ungültig. Aktuellen Key von der Prüfstandsseite holen.
404 — Sequenz-Item nicht gefunden. Die sequenceItemId gehört nicht zur Organisation dieses Prüfstands.
413 — Payload zu groß. Ein Request darf maximal 5 MB groß sein; große Mengen in mehrere Requests aufteilen.
Doppelte Werte werden übersprungen — kein Fehler, schützt vor Doppel-Sendungen (Antwort weist sie unter duplicates aus).
„Dieser Weg ist nur für abgeschlossene Testfälle". Der Upload-Button im Messdaten-Bereich unterscheidet automatisch: läuft der Testfall noch, bitte den Live-Upload nutzen (kein Prüfstand zugewiesen? Dann zuerst einen Prüfstand am Testfall hinterlegen).
CSV-Zeilenfehler. Die Meldung nennt Zeile und Grund (nicht lesbares Datum, nicht-numerischer Wert, fehlende Pflichtspalte). Semikolon/ Dezimalkomma wird automatisch erkannt.
Nachträglich prüfen, was ankam: Jede Zustellung (REST, MQTT oder CSV-Upload während der Durchführung) steht im Zustell-Log — abrufbar über GET /api/v1/ingestion/deliveries (siehe REST-API) oder per Frage an den Support-Assistenten. Ein nachträglicher Upload nach Abschluss läuft nicht über dieses Log (er schreibt nie in die Live-Tabelle), sondern ist über das normale Audit-Protokoll nachvollziehbar.