Dass eine IoT-Plattform gute Visualisierung braucht, bestreitet niemand. Sensordaten, die keiner ansieht, sind nur eine Speicherrechnung. Jeder Interessent, mit dem wir sprechen, setzt “individuelle Dashboards” weit oben auf die Anforderungsliste. Und jeder Anbieter, wir eingeschlossen, antwortet mit einer Demo: ein Gauge, ein Liniendiagramm, eine Karte mit Pins, ein paar Widgets auf einem Raster. ThingsBoard und Grafana kommen im selben Gespräch auf, und beide liefern eine genauso überzeugende Demo.
Die Demo ist das Problem. Ein Dashboard für ein einzelnes Device auf einem großen Bildschirm sagt nichts darüber, was bei 400 Devices passiert. Nichts darüber, was Sie einem Kunden antworten, der einen Diagrammtyp will, den das Produkt nicht mitbringt. Und nichts darüber, wie die Daten zu Technikern kommen, die nie einen Laptop aufklappen. Diese drei Punkte entscheiden, ob Visualisierung skaliert. Keiner davon taucht in einer Demo auf.
Dieser Beitrag zeigt, wie wir Visualisierung in TagoIO für eine Flotte aufbauen und an welchen Stellen Sie trotzdem Code schreiben müssen.
Ein Dashboard für Hunderte von Devices
Das Erste, was nach der Demo aus dem Ruder läuft, ist die Anzahl der Dashboards. Bekommt jedes Device sein eigenes Dashboard, dann heißt Device 400 auch Dashboard 400, und eine Layout-Änderung bedeutet 400 Bearbeitungen. Bei zehn Devices geht Klonen noch durch, bei fünfzig ist es nicht mehr zu beherrschen.
Ein Blueprint Dashboard verbindet Widgets stattdessen erst zur Laufzeit mit Devices. Sie bauen ein Layout. Jedes Widget zeigt auf einen Blueprint-Slot statt auf ein festes Device, und jeder Slot hat einen Tag-Filter (zum Beispiel type=pump), der bestimmt, welche Devices in seinem Dropdown erscheinen. Der Nutzer wählt oben im Dashboard ein Device, jedes an diesen Slot gebundene Widget lädt neu, und dasselbe Dashboard bedient jede Pumpe, die Sie getaggt haben. Ein Dashboard fasst bis zu 20 Slots, eine Ansicht zeigt also Pumpe und Tank nebeneinander. Filterbedingungen lassen sich verketten: Wählt jemand einen Kunden, schrumpft das Device-Dropdown auf die Sensoren dieses Kunden.
Der Haken ist Disziplin, keine Funktion. Blueprint funktioniert nur, wenn Devices, die einen Slot teilen, dieselben Variablennamen verwenden. Ein Widget, das pressure liest, bleibt bei dem Device leer, das pump_pressure sendet. Legen Sie Variablennamen und Tag-Schema im Payload Parser oder Connector fest, bevor das erste Dashboard existiert. Variablen später über 400 Devices hinweg umzubenennen kostet eine Woche, die niemand eingeplant hat. Blueprint steuert außerdem nicht, wer was sieht. Das übernehmen Access Management Policies, die TagoRUN-Nutzer per Tag den Devices zuordnen.
Wenn das Widget, das Sie brauchen, nicht existiert
Die eingebauten Widgets decken die üblichen Fälle ab: Diagramme, Gauges, Karten, Tabellen, Device- und Nutzerlisten, Formulare zum Zurücksenden von Daten. Früher oder später will ein Kunde etwas, das das Produkt nicht mitbringt: eine Hexbin-Heatmap einer Lagerhalle, ein Ring-Gauge nach seinem Brand Guide, eine Diagrammform, die es nur in einer einzigen Bibliothek gibt.
Das Custom Widget ist der Notausgang. Es ist eine Kachel auf einem normalen oder einem Blueprint Dashboard, die Ihr eigenes HTML, CSS und JavaScript von einer URL lädt, die Sie hosten (TagoIO Files reicht dafür). Jede Web-Bibliothek für Diagramme passt, und das ECharts-Tutorial zeigt den Ablauf am schnellsten: die TagoIO Custom-Widget-Bibliothek einbinden, die konfigurierten Device-Variablen empfangen, zeichnen. Custom Widgets bekommen das vollständige Datenmodell, samt Echtzeit-Updates, dem Zurücksenden von Daten und dem Auslösen einer Analysis, und sie laufen in TagoRUN wie jedes andere Widget.
Ehrlich gesagt: Das ist Code. Jemand in Ihrem Team schreibt und hostet JavaScript. Für ein Diagramm, das die Plattform nicht hat, ist das ein fairer Preis. Wenn ein eingebautes Widget den Großteil der Arbeit erledigt, ist es ein schlechter Tausch.
Es gibt außerdem das experimentelle Custom Dashboard, bei dem die ganze Seite Ihre HTML-Datei ist, gehostet und versioniert von TagoIO, mit Daten aus gespeicherten TagoSQL-Abfragen. Es läuft in Admin und steht nicht in TagoRUN, im öffentlichen Share oder beim Verteilen zur Verfügung. Behandeln Sie es als internes Reporting-Werkzeug. Das experimentelle AI Dashboard baut aus einem Prompt in natürlicher Sprache ein ganzseitiges Admin-Layout und verfeinert es per Chat. Praktisch, um eine Ansicht auszuprobieren, bevor Sie sich auf ein Widget-Raster festlegen, und ebenfalls nicht in TagoRUN verfügbar.
Dieselben Ansichten aufs Handy, in Ihrem Branding
Das Dritte, was die Demo verdeckt, ist das Publikum. Die Leute, die Visualisierung am meisten brauchen, sitzen nicht im Büro: Facility Manager, Techniker im Außendienst, der Betriebsleiter des Kunden. Sie melden sich nicht an einer Admin-Konsole an und akzeptieren kein Dashboard, das auf dem Handy unlesbar ist.
In TagoRUN sehen Endnutzer die Dashboards, die Sie gebaut haben: ein Web-Portal unter Ihrer Domain und Ihrer Marke, mit eigener Nutzerverwaltung und Zugriffsregeln pro Nutzer. Dasselbe Blueprint Dashboard wird darin gerendert, aufgelöst auf die Devices, die jeder Nutzer sehen darf. Die TagoRUN Mobile App liefert denselben Nutzern dieselben Dashboards auf iOS und Android, ohne zusätzliche Entwicklungsarbeit.
Push-Benachrichtigungen prüft in einer Demo fast niemand, und sie machen die Hälfte des Nutzens von Mobile aus. Eine Action, die einen Schwellwert überwacht, oder eine Analysis mit einer aufwendigeren Prüfung schickt eine Benachrichtigung direkt auf die Handys der registrierten TagoRUN-Nutzer. Benachrichtigungen aus einer Analysis können Buttons tragen, damit ein Techniker einen Alarm quittiert, ohne ein Dashboard zu öffnen.
Wenn im Store Ihr Name stehen soll und nicht unserer: Das Add-on Custom Mobile App veröffentlicht eine White-Label-Version der App im App Store und bei Google Play unter Ihrer Marke. Für Paketierung und Auslieferung fällt eine Einmalgebühr an. Die Preise stehen auf der Profile-Seite in Admin.
Das Limit, an das ein stark genutztes Dashboard stößt
Jeder Dashboard-Aufruf kostet Data Output. Jedes Mal, wenn jemand ein Dashboard in Admin oder TagoRUN öffnet, zählt TagoIO einen Output pro angezeigtem Register. Ein Dashboard, das 3.000 Datenpunkte rendert, zählt also 3.000. Der Zähler ist vom Data Output Service getrennt und wird nicht berechnet, hat aber pro Plan eine harte Monatsobergrenze, die Sie nicht selbst anheben können:
| Plan | Dashboard-Register pro Monat |
|---|---|
| Free | 3.000.000 |
| Starter | 15.000.000 |
| Scale | 50.000.000 |
Ist die Grenze erreicht, melden Dashboards Fehler, bis der Monat neu beginnt.
Rechnen Sie beim Entwurf damit. Ein Diagramm, das einen Monat Minutenwerte zeichnet, lädt bei jedem Blick eines Technikers rund 43.000 Register. Aggregieren Sie in einer Analysis, speichern Sie die Zusammenfassung in einer Variablen und zeichnen Sie diese. Setzen Sie kurze Standard-Zeiträume. Beobachten Sie die Zeile “Dashboard Output” unter Hard Limits in Admin, bevor es ein Kunde tut, und prüfen Sie die aktuellen Obergrenzen unter Data Output für Dashboards.
Eine Checkliste, bevor Sie sich festlegen
- Kann ein Dashboard jedes Device eines Typs bedienen, zur Laufzeit ausgewählt, ohne Klonen?
- Stehen Variablennamen und Tag-Schema fest, bevor das erste Dashboard existiert?
- Wenn ein Kunde ein Diagramm verlangt, das dem Produkt fehlt: Können Sie es mit einer Web-Bibliothek ergänzen, und funktioniert es dann noch im Endnutzer-Portal?
- Bekommen Endnutzer dieselben Dashboards im Web und auf dem Handy in Ihrem Branding, mit Push-Benachrichtigungen aus denselben Regeln?
- Wissen Sie, was ein stark genutztes Dashboard an Data Output kostet und wo die Obergrenze liegt?
Eine Demo beantwortet keine dieser Fragen. Eine Woche mit einer getaggten Flotte, einem Blueprint Dashboard, einem Custom Widget und der Mobile App auf dem Handy eines Technikers beantwortet alle.
