Rohdaten via Custom-MQTT-Server
So nutzen Sie Ihre benutzerdefinierte MQTT-Verbindung.
Last updated
So nutzen Sie Ihre benutzerdefinierte MQTT-Verbindung.
Last updated
Sobald Sie Ihren Anwendungsfall im Swarm Control Center konfiguriert haben, generiert unsere Software Events. Diese werden als Standard-JSON übertragen. Wenn Sie Data Analytics nicht nutzen und die Daten stattdessen lieber via API abrufen möchten, bieten wir Ihnen die Möglichkeit, einen benutzerdefinierten MQTT-Broker zu konfigurieren.
Die Swarm Perception Box sendet Events in Form eines JSON an einen von Ihnen konfigurierten MQTT-Broker. Für die Übertragung wird das QoS Level 1 verwendet. Falls Events nicht zugestellt werden können, z.B. aufgrund einer fehlenden Verbindung, werden Events bis zu 24.000 Messages gecacht.
Für noch höhere Sicherheit können Sie MQTT über SSL verwenden. Fügen Sie dafür einfach das Präfix ssl:// zur Broker-Konfiguration hinzu.
Wenn die Komprimierung konfiguriert ist, werden die Events mit zlib/inflate komprimiert:
Im unten verlinkten GitHub-Repository finden Sie das Event-Schema der verschiedenen Konfigurationstypen:
Es gibt mehrere Möglichkeiten, wie Sie ein JSON gegen ein Schema validieren können. Eine gute Übersicht bietet json-schema.org. Wir empfehlen außerdem jsonschemalint.com als Online-Tool zur manuellen Validierung eines JSON gegen unser Schema.
Der Header des JSON wird durch eine Version des verwendeten Formats definiert (Propertyversion). Das Format ist major.minor, wobei eine Änderung der Hauptversion eine Änderung mit Abwärtskompatibilität darstellt. Für eindeutige Identifikatoren verlassen wir uns auf UUID. Zeitstempel werden gemäß ISO8601 definiert.
Ein Counting-Line-Event wird ausgelöst, wenn ein Objekt besagte Counting Line überquert (identifiziert durch lineId). Diese Linie hat einen benutzerdefinierten Namen (lineName). Ein Zeitstempel (timestamp) wird gesetzt, wenn das Event auftritt. Das Objekt kann die Counting Line in zwei Richtungen überqueren (direction) und sich entweder hinein- (In) oder hinausbewegen (Out). Zusätzlich wird das Objekt, das die CL überquert, klassifiziert (class und subclass). Die Klassen hängen vom Anwendungsfall ab.
Wenn das ANPR-Feature aktiviert ist, werden die Kennzeichen (plateNumber) sowie das Herkunftsland des Kennzeichens (numberPlateOrigin) zum Event hinzugefügt.
ANPR wird benötigt, um Bilder der Kennzeichen bei Ein- und Ausfahrt zu machen. Die Kennzeichenbilder werden im JPG-Format an die MQTT-Message angehängt und mit BASE64 codiert.
Bitte kontaktieren Sie unseren Support, um Kennzeichenbilder via MQTT zu aktivieren.
Wenn Speed Estimation aktiviert sowie konfiguriert ist, gibt speedestimate die Ausgabe der Geschwindigkeitsschätzung in km/h an.
Das Region-of-Interest-Event hängt vom Typ der RoI ab. Beispiel: Eine Region of Interest mit dem Typ Parking generiert ein ParkingEvent, während der Typ Generic ein RegionOfInterestEvent generiert:
ParkingEvent:
Dieses Event wird in einem Zeitintervall von zehn Sekunden ausgelöst. Die Informationen aller konfigurierten Parking-RoI werden in einem einzelnen Event aggregiert. In parkingSummary werden alle RoI mit der konfigurierten capacity und der aktuellen Anzahl der vehicles in der RoI selbst angezeigt.
Als Gesamtübersicht haben Sie dann totalCapacity und totalVehicles, die einen vollständigen Überblick über alle konfigurierten RoI mit dem Typ Parking in diesem Kamerastream geben. Zusätzlich besteht die Möglichkeit, ANPR für Parking-RoI zu aktivieren. Dadurch werden das Kennzeichen (plateNumber) sowie das Herkunftsland des Kennzeichens (numberPlateOrigin) im String-Format bereitgestellt.
Ein RegionOfInterestEvent wird entweder durch eine Zustandsänderung oder ein bestimmtes Zeitintervall ausgelöst (triggerType). Der Zustand (state) kann von occupied to vacant oder umgekehrt wechseln. Occupied trifft zu, wenn die Anzahl der Objekte in der RoI mindestens so hoch ist wie zuvor als capacity konfiguriert.
Jedes Event enthält einen benutzerdefinierten Namen (roiName) und einen Zeitstempel (timestamp), wann das Event auftritt, bzw. aufgetreten ist. Erkannte Objekte und ihre zugeordneten Klassen sowie Verweilzeiten werden aufgelistet (objects). Die Klassen hängen vom Anwendungsfall ab.
Wenn eine Regel für ein bestimmtes Ereignis angelegt wurde, wird ein entsprechendes Rule-Event gesendet. Dieses wird entsprechend basierend auf der gewählten Logik in Kombination mit den definierten Bedingungen ausgelöst. Ein Zeitstempel (timestamp) wird gesetzt, wenn das Event auftritt. Das Rule-Event enthält allgemeine Informationen zum Namen, zum Gerät und zur Stream-UUID. Darüber hinaus ist die gewählte gewählte, standardmäßige Eventinformation Teil der Message und im gleichen Format wie andere Messages für diese Eventtrigger.
In diesem Modus werden Objekte getrackt, während sie sich im Sichtfeld bewegen. Sobald das Objekt das Sichtfeld wieder verlassen hat, wird entsprechend die vollständige Route des Objekts generiert.
Der Raw Track enthält die Klassifizierung () und die Spur des Objekts durch das Sichtfeld. Die Klassen hängen vom Anwendungsfall ab.
Die Spur ist als eine Abfolge von path-Elementen definiert, die einen Zeitstempel sowie die Koordinaten enthalten. Die Koordinaten basieren auf dem Punkt der oberen linken Ecke kombiniert mit Breite und Höhe des jeweiligen Objekts. Pro Event gibt es maximal zehn path-Elemente. Zum besseren Verständnis der Berechnung der Koordinaten dient folgende Aufschlüsselung:
Wie bereits erwähnt, enthält jedes Event eine Information zur Klasse/Klassifizierung des jeweiligen, erkannten Objekts. Zur besseren Übersicht haben wir in Klassen (class) und Unterklassen (sub class) aufgeteilt. Beispiele finden Sie hier:
ModelleBeispiel: Eine Counting Line erkennt einen Lieferwagen (van). Hinweis: Die class ist hier car, während die sub class van ist.
