Systemübersicht

Yggio sitzt zwischen Geräten und Anwendungen und arbeitet als Data Broker. Geräte senden rohe Payloads über das Protokoll, das sie nun einmal nutzen; Yggio decodiert sie, speichert sie, gibt ihnen eine gemeinsame Form und liefert sie über offene APIs an Anwendungen. Um diesen Kern herum kommen Integration, Visualisierung und Anreicherung, sodass sich ein Anwendungsfall oft umsetzen lässt, ohne überhaupt eine Anwendung zu bauen.

Diese Seite fasst die gesamte Plattform zusammen und verweist weiter auf die Details. Dafür, was Yggio tut statt wie es gebaut ist, siehe die Einführung.

Das Frontend

Das Frontend ist auf moderner Webtechnologie gebaut und wird laufend aktuell gehalten, mit einem Fundament, das mit der Technik erneuert und nicht sich selbst überlassen wird. Das ist es, was das Entwicklungstempo sichert: weil der Boden aktuell bleibt, lässt sich heute eine neue Ansicht, ein neues Widget oder eine ganz neue Fähigkeit schnell liefern, und das wird auch in einem Jahr noch schnell gehen.

Dashboards

Widget-basierte Dashboards, per Drag-and-drop zusammengestellt, die KPIs, Diagramme und Karten über eingehende Daten zeigen. Siehe den Dashboard-Leitfaden.

Geräte, Karte und Ansichten

Die Oberfläche zur Geräteverwaltung. Ansichten werden aus Filtern mit FIWARE-Q-Queries gebaut, die auf Attributwerte statt auf Gerätenamen passen, sodass sich eine Ansicht als "alles, was gerade außerhalb des Bereichs liegt" definieren lässt statt als feste Liste. Dieselbe Query-Mechanik treibt die Karte, auf der Geräte an ihrer gemeldeten Position erscheinen und Geofences Ein- und Austritt erkennen, sowie die Alarmansichten unten. Ein Filterkonzept, drei Darstellungen.

Eine FIWARE-Q-Query, die auf eine Abweichung filtert.

Alarme und Logs

Alarme sind in Yggio vollwertige Betriebsereignisse, auf dem Niveau, das eine Bedienerin von einem SCADA-System erwartet.

Jeder Eintrag trägt:

• Priorität: severe, high, medium oder low
• Typ: error, warning, info, verbose oder debug
• Kategorie: update, command, status, access, analytics, rule oder system
• Quittierung: wer sie quittiert hat und wann, sodass klar ist, was erledigt ist und von wem. Einträge lassen sich auch im Bulk quittieren

Logs sind nicht auf Geräte beschränkt. Sie werden für Geräte, Connectoren, Benutzergruppen und Organisationen geführt, sodass eine Änderung der Zugriffsrechte an einer Organisation oder einer Benutzergruppe am selben Ort und im selben Format nachvollziehbar ist wie ein Sensor, der aus dem Bereich läuft. Verbose- und Debug-Einträge sind standardmäßig ausgeblendet und werden auf Wunsch gezeigt, was die Betriebsansicht lesbar hält.

Es gibt drei Wege, einen Alarm zu erzeugen, und sie lassen sich kombinieren:

• Einen Alarm-Translator zuweisen. Die fertigen überwachen ein Feld gegen Schwellen, die als Translator-Parameter gesetzt werden, mit Hysterese, damit ein Wert nahe einer Grenze den Alarm nicht wiederholt umschalten lässt. Siehe Alarm-Translatoren.
• Einen eigenen Translator schreiben und hochladen, wenn die Bedingung für Ihren Betrieb spezifisch ist. Siehe den Leitfaden zur Translator-Entwicklung.
• Die Regel-Engine nutzen, die Bedingung dort definieren und das Ergebnis mit der Aktion "Log" in das Log schreiben.

Die Alarmüberwachungsansicht ist eine auf Alarmfelder gefilterte Geräteansicht und zeigt den aktuellen Stand über den gesamten Bestand. Siehe Logs.

Apps und Werkzeuge fürs Feld

Die Seite Apps beherbergt Anwendungen von Sensative und von Dritten, die Informationen, Links und Zugriffsrechte speichern und mit Yggio-Daten arbeiten. Sie lassen sich mit oder ohne eigenes Backend bauen; siehe Erste Schritte mit Yggio-Apps.

Daneben stehen Werkzeuge für diejenigen, die den Bestand installieren und warten, etwa der Device Updater, gebaut für ein Mobiltelefon, damit ein Installateur ein Gerät aktualisieren kann, während er davorsteht.

Das Backend

Das Backend ist eine Menge zustandsloser Microservices, jeder für eine Aufgabe zuständig und jeder für sich skalierbar. Da sie zwischen Anfragen keinen Zustand halten, lassen sich Instanzen ohne Abstimmung hinzufügen, entfernen oder ersetzen, was die Plattform sowohl redundant als auch horizontal skalierbar macht. Die Dienste kommunizieren asynchron über einen Message Broker, und der Zustand liegt in replizierbaren Datenbanken statt in den Diensten selbst.

Der Datenpfad

Was zwischen dem Senden eines Geräts und dem Lesen des Ergebnisses durch eine Anwendung geschieht, entlang des Default Flow:

1. Ankunft. Der Netzwerkserver oder das Gateway des Geräts liefert die Payload an den für dieses Gerät konfigurierten Connector.
2. Eintritt über die Integrations-API. Integrationen übergeben Daten an die Integrations-API, statt selbst in den Speicher zu schreiben. Hier wird die Entität nachgeschlagen oder angelegt, und hier wird die Kalibrierung angewandt, sodass der rohe Messwert korrigiert wird und kein Konsument die unkorrigierte Zahl sieht.
3. Übersetzung. Der Translator-Dienst führt jeden Translator des Knotens aus, verkettet, wobei jeder die Ausgabe des vorherigen sieht.
4. Berechnungen. Abgeleitete Werte werden aus den übersetzten Feldern berechnet.
5. Location Service. Hat sich die Position des Geräts geändert, wird sie aktualisiert, und die Geofence-Zugehörigkeit wird ausgewertet, wo der Flow es vorsieht.
6. Verteilung. Das Ergebnis geht gemeinsam an die Kanäle, die Datenbank und die Regel-Engine, sodass Subscriptions auslösen, Historie geschrieben wird und Regeln auf derselben Aktualisierung auswerten.

Da jeder Schritt ein eigener Dienst ist, blockiert ein langsamer Translator die Aufnahme nicht, und Last in einem Teil des Pfads skaliert unabhängig vom Rest.

Flows

Der Pfad oben ist nicht fest. Ein Flow ist die Menge von Anweisungen, die entscheidet, welche Funktionalität eine Aktualisierung bearbeitet, und vier Standard-Flows liefert die Plattform mit: Default, General Timer, General Geo Query, und General Timer and Geo Query. Timer erlauben eine Verzögerung, bevor ein Alarm auslöst; Geo-Queries werten aus, ob ein Knoten innerhalb oder außerhalb eines Geofence liegt, was die meisten Tracking-Fälle brauchen.

Flows können auch Transformationsfunktionen tragen, eigenen Code, der auf die Plattform geladen und innerhalb des Flows in einer Sandbox ausgeführt wird, und sie können Funktionalität ganz umgehen, um hochfrequente Daten direkt in die Datenbank zu schreiben. Jeder Connector hat einen Standard-Flow, und der Flow lässt sich weiterhin je Gerät zuweisen. Siehe Datenflüsse, Timer und Geofences.

Integrations-API

Die Integrations-API, historisch auch Lens genannt, ist die Schicht direkt über der Datenbank. Alles andere in Yggio geht durch sie, statt selbst den Speicher zu lesen oder zu schreiben, weshalb sie die Komponente ist, die durchsetzt, wie eine Entität angelegt, kalibriert, übersetzt und aktualisiert wird, über welche Integration oder API die Daten auch hereinkamen.

Übersetzung und FIWARE-Datenmodelle

Gerätedaten kommen meist als undurchsichtiger Block von Bytes an. Ein Translator macht daraus eine vollständig geformte Entität nach FIWARE Smart Data Models, mit NGSI-LD-Benennung, sodass dieselbe Messung unabhängig vom Hersteller denselben Feldnamen trägt.

Details, die beim Schreiben eines Translators zählen:

• Translatoren laufen in einem Sandbox-Isolat, nicht im Prozess des Dienstes. Sie haben keinen Zugriff auf das Netzwerk, das Dateisystem oder den Host, ein hochgeladener Translator kann die Plattform also nicht kompromittieren.
• Jeder Translator deklariert eine Spec, und die Sandbox weist jedes ausgegebene Feld zurück, das nicht darin steht. Ein Translator kann kein Feld stillschweigend erfinden, was das Datenmodell davor bewahrt, auseinanderzudriften.
• Translatoren verketten sich und können auf mehr als einen Knoten schreiben, sodass die Daten eines Geräts mehrere logische Entitäten speisen können.
• Aktualisierungen sind atomar, eine teilweise angewandte Übersetzung ist also nie beobachtbar.

Siehe Translator-Entwicklung und die Translator-API.

Publisher und Subscriptions

Der Publisher schickt Ereignisse über Abonnentenkanäle hinaus, sobald sie geschehen, sodass ein integrierendes System von einer Änderung erfährt, statt danach zu fragen. Subscriptions sind eingegrenzt, was das ausgehende Volumen proportional zu dem hält, was den Empfänger tatsächlich interessiert. Siehe Publisher.

Geräteüberwachung

Yggio beobachtet die Geräte selbst, nicht nur ihre Messwerte. Ein Gerät, das vor einer Stunde hätte melden sollen und es nicht getan hat, ist ein Fehler, der es wert ist, sichtbar zu werden, Stille wird also als Signal behandelt und nicht als dessen Abwesenheit. Die Verbindungsqualität wird daneben überwacht.

Datenbanken, Zeitreihen und Aufbewahrung

Yggio hält den aktuellen Zustand und die Metadaten jedes Geräts und bewahrt die Historie daneben auf. Sowohl numerische als auch Zeichenkettenwerte werden in die Zeitreihendatenbank geschrieben, indiziert, sodass eine Bereichsabfrage über ein Gerät oder eine Gruppe schnell bleibt, während die Historie wächst. Die Aufbewahrung wird je Connector gesetzt, von mindestens zwei Tagen bis unbegrenzt. Siehe Zeitreihendaten.

Identität und Zugriff

Identitäts- und Zugriffsverwaltung übernimmt Keycloak, sodass Konten aus einem Verzeichnis kommen können, das Sie bereits betreiben, statt doppelt gepflegt zu werden. SAML 2.0, LDAP, Active Directory, OAuth 2.0 und OpenID werden alle unterstützt.

Darüber liegt Yggios eigenes Modell: Zugriffsrechte je Ressource mit einem ausdrücklichen Eigentümer, Rollen, die festlegen, was ein Benutzer tun darf (admin, editor, die Viewer-Stufen, installer, oder eine eigene Rolle), Benutzergruppen, um Berechtigungen für viele Benutzer zugleich zu ändern, und der Organisation Manager, um Konten über einen Betrieb hinweg zu strukturieren. Freigabe kann breit über Organisationsrichtlinien erfolgen oder eng, bis hinunter zu einem einzelnen Benutzer.

Integrationen und Connectoren

Eine Integration bringt Yggio ein Protokoll bei; ein Connector ist eine konfigurierte Instanz davon, die Anmeldedaten, Endpunkte und Subscription-Topics für ein bestimmtes externes System hält und an ein Konto und dessen Geräte gebunden ist. Diese Trennung ist der Grund, warum ein zweites LoRaWAN-Netz hinzuzufügen oder Geräte zwischen Netzen zu verschieben Konfiguration ist und keine Entwicklung. Jeder Connector setzt außerdem eine Aufbewahrungsrichtlinie und den Standard-Flow für darüber angelegte Geräte.

LoRaWAN. Actility / Netmore ThingPark, ChirpStack v3 und v4, Netmore, The Things Network, Loriot und Helium (die letzten beiden nur empfangend). Yggio kann auch selbst als LoRaWAN Join Server arbeiten, sodass Geräteschlüssel nicht bei Dritten liegen müssen.

Generisch, für NB-IoT, Cat-M, WLAN, BLE und Ethernet-Geräte. MQTT, entweder auf dem eigenen Broker der Plattform oder einem externen, dazu HTTP, CoAP und UDP.

Hubs, für Z-Wave, Zigbee, Matter und Thread. Ein Hubitat-Hub verbindet sich über MQTT und bringt alles, was er spricht, als gewöhnliche Geräte nach Yggio, einschließlich Lutron sowie LAN- und Cloud-Geräten, die über Hubitats eigene und Community-Treiber erreicht werden. Der Hub übernimmt das Funkprotokoll, und die Verbindung läuft in beide Richtungen, sodass eine Regel in Yggio ein Z-Wave-Relais schalten oder einen Dimmer auf einen Wert setzen kann und der neue Zustand direkt zurückkommt.

Gebäude- und Industriesysteme. BACnet IP und Modbus TCP für die direkte Kommunikation mit Gebäude- und Industrietechnik, Delta Controls über die EnteliWeb-REST-API, SIA-Connect-Edge-Gateways, die eine Reihe von BMS-Plattformen erreichen, und Siemens Desigo CC, das Yggio über dessen REST-API mit Sensordaten versorgen kann.

Hersteller- und dienstspezifisch. BLE-Gateways von Dusoniot, Celsiview, Elvaco CME, Klimator-Straßenwetterstationen und Open Weather Map für Wetter- und Prognosedaten.

Um die Connectoren herum steht ein Ökosystem aus Partnern, Dienstleistern und Plattformerweiterungen. Weitere Protokolle können auf Anfrage unterstützt werden. Siehe die Connector-Übersicht, oder wenden Sie sich an info@sensative.com.

Regeln, Zeitsteuerung und Automatisierung

Regeln werten Bedingungen gegen eingehende Daten aus und lösen Aktionen aus, vom Einschalten einer Lampe bei Sonnenuntergang bis zum Versand einer Nachricht, wenn ein Leck erkannt wird. Berechnungen leiten neue Werte aus bestehenden ab, und Geräte lassen sich im Bulk anlegen, aktualisieren und exportieren, auch über CSV, sodass ein Bestand von Tausenden als Menge und nicht einzeln verwaltet wird. Der Scheduler übernimmt alles Zeitbasierte, und Flow führt die entstehenden Aufgabenbäume aus, sodass ein Auslöser sich in mehrere geordnete Aktionen verzweigen kann.

Wo die Logik umfangreich ist, empfiehlt sich das Muster, sie in einem Translator zu berechnen und die Regel selbst ein einfacher Wahr-oder-Falsch-Test bleiben zu lassen. Das hält die Auswertung nahe an den Daten und die Regel lesbar. Siehe den Leitfaden zur Regel-Engine.

Analyse und KI

Anomalieüberwachung geschieht zuerst mit den Alarm-Translatoren, die einen Alarm auslösen, wenn ein decodiertes Feld eine Schwelle überschreitet. Lässt sich das normale Muster nicht als Schwelle ausdrücken, trainiert die Plattform zur Bereitstellung von KI-Modellen ein Modell auf der eigenen Historie eines Sensors und prüft jeden neuen Messwert dagegen. So oder so ist das Ergebnis ein gewöhnlicher Wert, es kann also dieselben Aktionen auslösen wie jeder andere Wert. Der AI-Connector verbindet einen LLM-Assistenten mit der Plattform. Sein Zusammenspiel mit Yggio läuft über die Dokumentation: er beantwortet Fragen dazu, wie die Plattform funktioniert und wie man sie nutzt, gestützt auf die Dokumentation und das Internet. Gerätedaten abzufragen und Automatisierungen über die API auszuführen ist für ein künftiges Release geplant.

Berichtswesen und Business Intelligence

Berichte decken wiederkehrende Bedarfe wie Zählerablesung, Auslastung und Abrechnungsdaten ab, von der Regel-Engine geplant und per E-Mail zugestellt. Ergebnisse lassen sich in Yggio lesen, exportieren, oder dort nutzen, wo die Organisation ohnehin arbeitet, über Power BI oder Grafana. Siehe Berichte.

APIs und Erweiterungspunkte

• Yggio REST API, die wichtigste programmatische Schnittstelle, die alles außerhalb des NGSI-Umfangs abdeckt, etwa Benutzerverwaltung und Regeln, mit interaktiver Swagger-Dokumentation.
• FIWARE NGSI, daneben bereitgestellt, sodass Entitäten mit FIWARE-Konventionen gelesen und geschrieben werden können.
• Befehle und Downlinks, um Anweisungen an Geräte zurückzusenden, einschließlich LoRaWAN-Downlinks und Z-Wave-Inklusion.
• Geofences, mit einer eigenen API.
• MQTT für Publish-and-Subscribe-Integration.
• Node.js SDK und Node-RED, um auf der Plattform zu bauen, ohne bei rohem HTTP anzufangen.
• Eine Integration bauen, wenn ein Protokoll oder System noch nicht unterstützt wird.

Datenmarktplatz

Der Datenmarktplatz ist der Ort, an dem Datensätze gefunden und geteilt werden, sei es, um Daten zu finden, auf denen man aufbaut, oder um eigene für andere beizusteuern.

Wohin als Nächstes

• Benutzerhandbuch für die tägliche Arbeit mit der Plattform.
• Entwicklerdokumentation, um dagegen zu entwickeln.
• Schulungsmaterial, der schnellste Weg, die Plattform von Anfang bis Ende zu sehen. Es läuft in drei Stufen:
  • Standard-Workflow: LoRaWAN-Geräte hinzufügen, Ansichten, Alarmansichten und Translatoren, CSV-Export und -Import, Kartenansichten, Dashboards, Datenfreigabe.
  • Erweiterter Workflow: die Regel-Engine, Berechnungen, generische Knoten, einfache und Excel-Berichte, Organisationen, Rollen, Connectoren, externe Datenfreigabe und Flows.
  • Fortgeschrittene Nutzung: Grafana, Power BI, Node-RED, MQTT Explorer, Postman, curl und Translator-Entwicklung.
• Release Notes dafür, was sich wann geändert hat.
• Sensative-Hardware: die Dokumentation der LoRaWAN- und Z-Wave-Sensoren.
• Rechtliche Vereinbarungen und Richtlinien.