Schnittstellenbeschreibung SensorThings API (FROST‑Server)
Einleitung
Der FROST‑Server ist die Referenzimplementierung des OGC SensorThings API Standards (Version 1.1) und die Schnittstelle, über die die vom Adapter exportierten Daten gelesen werden. Diese Seite ist eine Kurzreferenz für den Zugriff darauf — der vollständige Standard und die vollständige Serverdokumentation stehen unter Weiterführende Referenzen.
|
Es gibt keine gemeinsame Basis‑URL. Jeder Mandant hat einen eigenen FROST‑Server, und dessen Service‑Root steht als |
Entitäten – Übersicht
Die SensorThings API modelliert IoT‑Daten anhand von sieben Kern‑Entitäten.
| Entität | Zweck | Endpunkt |
|---|---|---|
Thing |
Repräsentiert ein physisches oder virtuelles Objekt (z. B. eine Messstation). |
|
Location |
Geografischer Standort eines Things. |
|
Sensor |
Beschreibt das Messinstrument oder den Gerätetyp. |
|
ObservedProperty |
Die gemessene Eigenschaft (z. B. Temperatur, CO₂‑Konzentration). |
|
Datastream |
Verbindet Thing, Sensor und ObservedProperty zu einem Messdatenkanal. |
|
Observation |
Einzelner Messwert innerhalb eines Datastreams. |
|
FeatureOfInterest |
Räumliches Objekt, auf das sich eine Observation bezieht. |
|
Der Adapter legt sechs davon selbst an; FeaturesOfInterest erzeugt FROST bei Bedarf selbst. Womit der Adapter die Felder jeder Entität füllt, steht in Datenmodell.
Die Beziehungen zwischen den Entitäten folgen dem UML‑Modell des OGC SensorThings Standards:
Adressierung
Jeder Entitätstyp wird über einen eigenen Pfad angesprochen. Die folgende Konvention gilt durchgängig für alle sieben:
| Muster | Bedeutung |
|---|---|
|
Alle Entitäten dieses Typs abrufen (Collection). |
|
Eine einzelne Entität anhand ihrer ID abrufen. |
|
Verknüpfte Entitäten über eine Beziehung navigieren. |
curl -s "{frost_server_url}/Things"
curl -s "{frost_server_url}/Things(1)"
curl -s "{frost_server_url}/Things(1)/Datastreams"
curl -s "{frost_server_url}/Datastreams(1)/Observations"
Abfrageparameter und Filterung
Die SensorThings API unterstützt standardisierte Query‑Optionen, die als URL‑Parameter übergeben werden.
| Parameter | Beschreibung | Beispiel |
|---|---|---|
|
Begrenzt die Anzahl der zurückgegebenen Entitäten. |
|
|
Überspringt die angegebene Anzahl an Entitäten (für Pagination). |
|
|
Gibt die Gesamtzahl der Entitäten im Ergebnis mit zurück. |
|
|
Sortiert die Ergebnisse nach einem oder mehreren Feldern. |
|
|
Beschränkt die zurückgegebenen Eigenschaften auf die genannten Felder. |
|
|
Lädt verknüpfte Entitäten inline mit (reduziert Anzahl der Anfragen). |
|
|
Filtert Ergebnisse anhand logischer Ausdrücke. |
|
Pagination
Der FROST‑Server liefert standardmäßig eine begrenzte Anzahl von Entitäten pro Anfrage (serverseitige Pagination). Enthält die Antwort mehr Daten als das Limit erlaubt, wird im JSON ein Feld @iot.nextLink ausgegeben, das die URL für die nächste Seite enthält.
# Erste Seite mit 100 Einträgen
curl -s "{frost_server_url}/Observations?\$top=100&\$count=true"
# Nächste Seite manuell abrufen
curl -s "{frost_server_url}/Observations?\$top=100&\$skip=100"
Programmatische Clients sollten das @iot.nextLink‑Feld auswerten und iterativ abrufen, bis kein weiterer Link mehr vorhanden ist.
|
Filter‑Ausdrücke
| Operator | Bedeutung | Beispiel |
|---|---|---|
|
Gleichheit |
|
|
Ungleichheit |
|
|
Größer als / Größer oder gleich |
|
|
Kleiner als / Kleiner oder gleich |
|
|
Logische Verknüpfung |
|
|
Teilzeichenkette prüfen |
|
|
Anfangszeichenkette prüfen |
|
Expand mit verschachtelter Abfrage
$expand kann mit Unter‑Query‑Optionen kombiniert werden, um gezielt verknüpfte Daten einzugrenzen.
# Datastream mit den letzten 5 Observations
curl -s "{frost_server_url}/Datastreams(1)?\$expand=Observations(\$top=5;\$orderby=phenomenonTime desc)"
# Things mit expandierten Datastreams und deren ObservedProperty
curl -s "{frost_server_url}/Things?\$expand=Datastreams(\$expand=ObservedProperty)"
| Für komplexe und tief verschachtelte Abfragen konsultieren Sie die offizielle Dokumentation unter https://fraunhoferiosb.github.io/FROST-Server/settings/queryDefaults.html. |
Praxisbeispiele
# Alle Things mit ihren Standorten und der Anzahl
curl -s "{frost_server_url}/Things?\$expand=Locations&\$count=true"
# Observations eines Datastreams in einem Zeitfenster, absteigend, auf 50 begrenzt
curl -s "{frost_server_url}/Datastreams(1)/Observations?\$filter=phenomenonTime ge 2024-06-01T00:00:00Z and phenomenonTime le 2024-06-30T23:59:59Z&\$orderby=phenomenonTime desc&\$top=50&\$count=true"
# Nur Name und Beschreibung aller Sensors
curl -s "{frost_server_url}/Sensors?\$select=name,description"
# Things, deren Name mit 'KSPB' beginnt
curl -s "{frost_server_url}/Things?\$filter=startswith(name,'KSPB')"
# Die jüngste Observation überhaupt — dieselbe Abfrage, die die Erreichbarkeitsprüfung stellt
curl -s "{frost_server_url}/Observations?\$orderby=phenomenonTime desc&\$top=1"
System‑Endpunkte
Neben den Entity‑Endpunkten stellt der FROST‑Server System‑Endpunkte bereit, die für Betrieb und Monitoring relevant sind. Sie liegen unterhalb der Service‑Root, also nicht unter /v1.1.
| Endpunkt | Beschreibung |
|---|---|
|
Willkommensseite des FROST‑Servers (HTML). |
|
Service‑Root – listet alle verfügbaren Entity‑Sets auf (JSON). Dies ist der Endpunkt, den die Erreichbarkeitsprüfung des Adapters abfragt. |
|
Status der Datenbankverbindung. Zugleich die Admin‑Seite, über die eine neue Instanz ihr Schema initialisiert (FROST‑Instanz bereitstellen). |
In Kubernetes‑Umgebungen eignet sich /DatabaseStatus als Liveness‑ oder Readiness‑Probe für den FROST‑Server‑Pod.
|