Seminar Kuzzle IoT Dashboard Builder und individuelle Widgets

Das Seminar entwickelt rollen- und entscheidungsorientierte IoT-Dashboards aus Messwerten, Zuständen, Karten und Alerts. Neben Standardbausteinen werden Datenabfragen, Realtime-Aktualisierung, Fehlerzustände, Performance und ein eigenes Widget behandelt. Theorie, Demonstration und Laborarbeit wechseln in kurzen Zyklen. Jeder technische Schritt wird durch eine Kontrollabfrage, einen Negativtest oder eine nachvollziehbare Zustandsprüfung abgeschlossen.

Inhaltsübersicht

• Zielgruppe und Voraussetzungen
• Didaktischer Zuschnitt
• Informationsbedarf und Dashboard-Architektur
• Standardwidgets und interaktive Analyse
• Individuelles Widget entwickeln
• Realtime, Performance und Freigabe
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

• Adressierte Rollen
• Erforderliche Vorkenntnisse
• Labor- und Arbeitsmittel
• Einstiegskontrolle

Zielgruppe: IoT-Produktverantwortung, Fachbereichsanalyse, Frontend-Entwicklung, Plattformadministration und technische Visualisierung.

Voraussetzungen: Grundkenntnisse zu IoT-Messwerten, JSON und Weboberflächen; für Individualwidgets sind JavaScript- oder Vue-Kenntnisse hilfreich.

Zu Beginn werden Vorkenntnisse, Laborzugang, Namenskonventionen und Sicherheitsregeln geprüft. Fehlende Grundlagen werden als konkrete Vorbereitungspunkte dokumentiert; produktive Systeme und reale Zugangsdaten werden in den Übungen nicht verwendet.

Didaktischer Zuschnitt

Kapitelinhaltsverzeichnis

• Begründung der Dauer
• Arbeitsweise
• Dokumentationsstandard
• Qualitätssicherung

Begründung der Dauer: Zwei Tage sind notwendig, weil am ersten Tag Kennzahlen, Datenquellen und Standarddashboards aufgebaut werden. Der zweite Tag wird für individuelles Widget, Realtime-Verhalten, Berechtigungen, Lastprüfung und Freigabeprozess benötigt.

Die Lerneinheiten folgen dem Muster Analyse, Aufbau, Funktionsnachweis, Fehlerfall und Wiederholung. Konfigurationen und Testdaten werden versionierbar gehalten. Entscheidungen werden mit Annahme, Alternative, Risiko und Prüfmethode dokumentiert. Dadurch entsteht neben dem fachlichen Verständnis ein direkt nutzbares Arbeitsverfahren.

1. Informationsbedarf und Dashboard-Architektur

Kapitelinhaltsverzeichnis

• Zielgruppen und Entscheidungen
• Kennzahlen und Schwellen
• Datenquellen
• Seiten- und Navigationsmodell

Dieses Kapitel verbindet Zielgruppen und Entscheidungen, Kennzahlen und Schwellen, Datenquellen und Seiten- und Navigationsmodell. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Zielgruppen nach Entscheidung, Reaktionszeit und benötigter Detailtiefe trennen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Jede Kennzahl mit Definition, Einheit, Aktualität und Verantwortlichkeit beschreiben: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Datenquellen, Filter, Mandantenbezug und Zeitfenster eindeutig zuordnen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Übersicht, Analyse und Detailansicht in ein konsistentes Navigationsmodell bringen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Leere, verspätete und fehlerhafte Daten als eigene Darstellungszustände festlegen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Zielgruppen und Entscheidungen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Kennzahlen und Schwellen erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Seiten- und Navigationsmodell lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Für Leitstand und Technik entstehen getrennte Dashboard-Skizzen mit eindeutigem KPI-Katalog. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Standardwidgets und interaktive Analyse

Kapitelinhaltsverzeichnis

• Zeitreihen und Status
• Tabellen und Filter
• Karten und Geodaten
• Alerts und Drill-down

Dieses Kapitel verbindet Zeitreihen und Status, Tabellen und Filter, Karten und Geodaten und Alerts und Drill-down. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Ein Grundlayout mit wiederverwendbaren Filter- und Zeitbereichskomponenten anlegen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Zeitreihen, Statuskarten und Tabellen mit einheitlichen Einheiten konfigurieren: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Geodaten auf einer Karte darstellen und Clustering sowie Zoomverhalten prüfen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Alerts mit Priorität, Zustand und direktem Drill-down auf die Ursache verknüpfen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Dashboardzustände speichern und gegen unterschiedliche Rollen sowie Datenmengen testen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Zeitreihen und Status ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Tabellen und Filter erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Alerts und Drill-down lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein Betriebsdashboard kombiniert Live-Status, Historie, Karte, Alertliste und Detailnavigation. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Individuelles Widget entwickeln

Kapitelinhaltsverzeichnis

• Widgetvertrag
• Datenzugriff
• Zustandsmodell
• Konfiguration und Wiederverwendung

Dieses Kapitel verbindet Widgetvertrag, Datenzugriff, Zustandsmodell und Konfiguration und Wiederverwendung. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Den fachlichen Mehrwert und die Grenzen des eigenen Widgets definieren: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Eingabeparameter, Datenvertrag und erwartete Aktualisierungsfrequenz festlegen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Datenabfrage kapseln und Lade-, Leer-, Fehler- sowie Berechtigungszustand implementieren: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Darstellung für normale, grenzwertige und kritische Werte umsetzen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Widget konfigurierbar machen und mit mehreren Datensätzen sowie Dashboards prüfen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Widgetvertrag ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Datenzugriff erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Konfiguration und Wiederverwendung lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein eigenes Widget zeigt eine zusammengesetzte Betriebskennzahl und führt zu den zugrunde liegenden Messwerten. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Realtime, Performance und Freigabe

Kapitelinhaltsverzeichnis

• Aktualisierungsstrategie
• Abfragelast
• Rollen und Mandanten
• Abnahmekriterien

Dieses Kapitel verbindet Aktualisierungsstrategie, Abfragelast, Rollen und Mandanten und Abnahmekriterien. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Realtime nur für tatsächlich zeitkritische Anzeigen aktivieren und Historie getrennt laden: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Abfragen bündeln, Ergebnisgrößen begrenzen und unnötige Neuberechnungen vermeiden: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Dashboardzugriffe mit Rollen und Mandantengrenzen negativ testen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Messwerte für Ladezeit, Aktualisierung und Browserressourcen erfassen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Eine Freigabecheckliste für Inhalt, Rechte, Barrierearmut, Fehlerzustände und Betrieb anwenden: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Aktualisierungsstrategie ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Abfragelast erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Abnahmekriterien lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das Dashboard wird unter Last, bei Verbindungsabbruch und mit mehreren Rollen abgenommen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

Praxisprojekt und Lernerfolgskontrolle

Kapitelinhaltsverzeichnis

• Projektauftrag
• Zwischenprüfungen
• Fehler- und Sicherheitsnachweis
• Technische Abnahme

Das Praxisprojekt verbindet die Kapitel zu einer konsistenten Laborlösung. Vor jedem Inkrement werden Ausgangszustand, Ziel, Eingaben und Abnahmekriterien festgelegt. Nach der Umsetzung folgen Funktionsprüfung, Negativtest, kurze Dokumentationskontrolle und Rücksetzung auf einen bekannten Zustand.

1. Projektauftrag schneiden: Ein fachlich begrenzter Anwendungsfall wird in Daten, Akteure, Schnittstellen, Berechtigungen und Betriebsanforderungen zerlegt.
2. Inkremente umsetzen: Die Kapitelbausteine werden schrittweise integriert; nach jedem Inkrement bleibt die Laborlösung lauffähig.
3. Fehler nachweisen: Mindestens ein Berechtigungs-, Daten-, Verbindungs- oder Konfigurationsfehler wird kontrolliert ausgelöst und diagnostiziert.
4. Abnahme durchführen: Eine technische Checkliste prüft Funktion, Sicherheit, Wiederholbarkeit, Protokollierung und Rückfallfähigkeit.
5. Lernstand dokumentieren: Offene Vertiefungen werden als priorisierte Aufgaben mit benötigtem Nachweis festgehalten.

Die Lernerfolgskontrolle besteht aus kurzen Verständnisfragen, beobachteten Laboraufgaben, einer Fehlersuche und der technischen Abnahme des Praxisprojekts. Bewertet werden nicht nur funktionierende Ergebnisse, sondern auch Begründung, Nachweis, sichere Fehlerbehandlung und Reproduzierbarkeit.