Mandanten verwalten
Die Seite Tenants der Verwaltungsoberfläche führt die Mandanten des Adapters. Jeder Mandant exportiert in seinen eigenen FROST‑Server; das Löschen eines Mandanten entfernt nur die Registry‑Zeile — seine FROST‑Instanz und jede bereits exportierte Observation bleiben unberührt.
| Diese Seite beschreibt, was die Oberfläche tut und was sie ablehnt. Alles, was einen Shell‑Zugang voraussetzt — eine FROST‑Instanz samt Datenbank und Keycloak‑Client bereitstellen, die Rule Chain je Mandant verteilen, Wiederherstellung nach Fehlbedienung — steht in den Betriebsanleitungen und wird von hier aus an der passenden Stelle verlinkt. |
Aufbau der Seite
Über der Tabelle stehen zwei Buttons:
-
Save überträgt alle Änderungen (Anlegen, Bearbeiten, Löschen) an das Backend.
-
Check all connections prüft alle Mandanten auf einmal.
Die Tabelle selbst hat folgende Spalten:
| Spalte | Bedeutung |
|---|---|
Slug |
Die unveränderliche Kennung des Mandanten. Sie steht in der Rule‑Chain‑URL seines ThingsBoard, deshalb lässt sie sich nachträglich nicht ändern. |
Display Name |
Der Anzeigename des Mandanten. Frei änderbar. |
FROST Server URL |
Der Service‑Root des FROST‑Servers dieses Mandanten. Eindeutig — ein FROST‑Server gehört zu genau einem Mandanten. |
Keycloak Client ID |
Der Keycloak‑Client, mit dem sich der Adapter gegenüber diesem FROST‑Server authentifiziert. |
ThingsBoard API Key |
Der Zugang zum ThingsBoard des Mandanten. Wird nie zurückgeliefert; die Spalte ist beim Rendern immer leer. Leer lassen bedeutet „den gespeicherten Key behalten“, eine Eingabe ersetzt ihn. Für einen neuen Mandanten ist er Pflicht. |
ThingsBoard Username |
Der ThingsBoard‑Benutzer, als der die Geräte dieses Mandanten gelesen werden. Kein Geheimnis, wird deshalb angezeigt und lässt sich wie jedes andere Feld ändern. |
ThingsBoard Password |
Das Passwort dieses Benutzers. Verhält sich wie der API Key: nie zurückgeliefert, beim Rendern leer, leer lassen behält das gespeicherte, eine Eingabe ersetzt es. |
Connection Status |
Das Ergebnis der letzten Prüfung. Nicht editierbar. |
Test connection |
Ein Button je Zeile: prüft diesen einen Mandanten. |
Sync observed properties |
Ein Button je Zeile: überträgt die Observed Properties in den FROST‑Server dieses Mandanten. |
Unterhalb der Tabelle erscheinen Fehlermeldungen und Warnungen zu einzelnen Zeilen — der Grund eines fehlgeschlagenen Checks steht dort, nicht in der Tabellenzelle.
|
Welche ThingsBoard‑Felder die Tabelle zeigt, hängt davon ab, gegen welche ThingsBoard‑Edition der Adapter konfiguriert ist: Die Professional Edition meldet sich mit einem API Key an, die Community Edition mit Benutzername und Passwort — sie kennt keine API‑Key‑Anmeldung. Die Seite fragt den Adapter danach; einstellen lässt sich das hier nicht (siehe Wechsel der ThingsBoard‑Edition). Zugangsdaten der jeweils anderen Edition weist der Adapter mit einer Fehlermeldung ab, statt sie zu speichern — sie könnten nie funktionieren. |
Einen Mandanten aufnehmen
Voraussetzung ist, dass sein FROST‑Server samt Datenbank und Keycloak‑Client bereitsteht (siehe Betriebsanleitungen) und sein ThingsBoard‑Mandant angelegt ist.
-
Eine neue Zeile am Ende der Tabelle ausfüllen. Alle angezeigten Eingabefelder sind Pflicht; fehlt eines, nennt eine Meldung die fehlenden Felder und die Zeile wird nicht angelegt.
-
Save klicken.
-
Danach die Rule Chain im ThingsBoard des Mandanten einrichten und den Slug in ihren vier REST‑Knoten eintragen — siehe Rule Chain je Mandant verteilen.
Ein Neustart des Adapters ist an keiner Stelle nötig. Die Rule Chain legt der Betreiber selbst an — der Adapter schreibt nie nach ThingsBoard.
Was beim Speichern geschieht
Zuerst prüft das Backend, ob die eingetragenen Angaben tatsächlich funktionieren: Keycloak‑Token, FROST‑Service‑Root und ThingsBoard‑Login. Schlägt eine der Prüfungen fehl, wird die Zeile nicht angelegt bzw. nicht geändert, und die fehlgeschlagene Prüfung wird benannt. Ein Mandant lässt sich daher nicht registrieren, solange sein FROST gerade nicht erreichbar ist.
Ist die Prüfung bestanden, folgt die Übertragung der Observed Properties in den neuen FROST‑Server. Scheitert sie, bleibt die Zeile trotzdem bestehen und es erscheint ein Hinweis: Die fehlenden Einträge entstehen spätestens bei der ersten Telemetrie des Mandanten, und Sync observed properties holt sie sofort nach.
Wird bei einem bestehenden Mandanten die FROST Server URL geändert, läuft dieselbe Übertragung automatisch für den neuen Server; jede andere Änderung löst sie nicht aus.
Der Slug lässt sich nicht ändern
Der Slug steht in der Rule‑Chain‑URL des jeweiligen ThingsBoard. Eine Umbenennung würde dort jede Telemetrie‑Nachricht ins Leere laufen lassen, deshalb lehnen sowohl die Oberfläche als auch die API sie ab. Umbenennen heißt löschen und neu anlegen; siehe Einen Mandanten umbenennen.
Einen Mandanten prüfen
Jede Zeile hat einen Button Test connection, über der Tabelle steht Check all connections für alle Zeilen auf einmal. Beide führen dieselbe Prüfung aus und schreiben ihr Ergebnis in die Spalte Connection Status:
| Anzeige | Bedeutung |
|---|---|
|
Für diesen Mandanten wurde in dieser Sitzung noch nichts geprüft. |
|
Alle drei Verbindungen stehen, und der genannte Zeitpunkt ist der neueste |
|
Die Verbindungen stehen, aber im FROST‑Server dieses Mandanten liegt noch keine einzige Observation. |
ein |
Diese Verbindung steht nicht. Der Grund erscheint als Fehlermeldung unterhalb der Tabelle. |
Geprüft wird ausschließlich auf Klick: Die Liste selbst lädt ohne einen einzigen Aufruf an ein Fremdsystem und bleibt damit auch dann schnell, wenn eines davon ausgefallen ist.
Observed Properties abgleichen
Der Button Sync observed properties überträgt die Seite Observed Properties in den FROST‑Server dieser Zeile: fehlende Einträge werden angelegt, vorhandene auf den aktuellen Stand gebracht. Gelöscht wird dort nichts — auch Einträge nicht, die der Adapter nicht kennt.
Der Abgleich ist beliebig oft wiederholbar. Er ist zugleich der Einrichtungsschritt für einen neuen Mandanten und die Wiederholung, wenn eine Änderung einen Mandanten nicht erreicht hat.
Gelingt der Abgleich, erscheint kurz eine Bestätigung. Ist der FROST‑Server nicht erreichbar, erscheint eine Fehlermeldung mit dem betroffenen Mandanten; der Abgleich lässt sich dann einfach erneut anstoßen.
Warnung „unknown to the adapter but in use“
Findet der Abgleich im FROST‑Server einen Eintrag, den der Adapter nicht kennt, an dem aber Datastreams hängen, bleibt unter der Tabelle eine Warnung mit dessen Namen stehen. Das bedeutet, dass diese Observed Property dort doppelt vorliegt: einmal unter der Verwaltung des Adapters, einmal daneben mit älteren Messdaten.
Der Adapter greift hier bewusst nicht ein — ein Löschen würde in SensorThings auch die Datastreams und alle Observations mitnehmen. Was mit dem Eintrag geschehen soll, entscheidet die Administration von Hand im FROST‑Server.
Einen Mandanten stilllegen
Ein Mandant lässt sich erst löschen, wenn in seinem FROST‑Server kein Gerät mehr steht. Die Reihenfolge ist deshalb verbindlich:
-
Die Geräte des Mandanten in ThingsBoard aus der Gruppe
publish-to-frostentfernen. Der Adapter räumt daraufhin die zugehörigen Things im FROST‑Server ab, samt ihrer Datastreams und Observations. -
Die Zeile auf dieser Seite auswählen und mit Save löschen. Steht dort noch ein Gerät, oder ist der FROST‑Server nicht erreichbar, wird das Löschen mit einer Meldung abgelehnt — auch „nicht erreichbar“ verhindert es, denn es ist kein Beleg dafür, dass dort nichts mehr steht. Ein Erzwingen ist nicht vorgesehen.
-
Erst danach die FROST‑Instanz, ihre Datenbank und ihren Keycloak‑Client abbauen. Dieser Schritt findet außerhalb der Oberfläche statt; siehe Mandant stilllegen.
|
Wird Schritt 3 vor Schritt 2 ausgeführt, lässt sich der Mandant über die Oberfläche nie mehr löschen: Die Löschprüfung fragt seinen FROST‑Server und bekommt keine Antwort mehr. Das trifft nicht nur diesen Mandanten — die tote Zeile lässt danach auch jedes Löschen einer Observed Property, einer Unit of Measurement und eines Telemetry Keys dauerhaft scheitern, weil auch diese Prüfungen über alle Mandanten laufen. Die Wiederherstellung erfordert einen Eingriff in die Datenbank des Adapters; siehe Wiederherstellung nach falscher Reihenfolge. |
| Ein Mandant, der nur vorübergehend nichts exportieren soll, muss nicht gelöscht werden. Eine Zeile ohne Telemetrieverkehr kostet nichts. |
Einen Mandanten umbenennen
Gemeint ist der Slug; der Display Name ist jederzeit frei änderbar. Ein Slug wird nicht umbenannt, sondern der Mandant gelöscht und neu angelegt:
-
Die Schritte 1 und 2 aus Einen Mandanten stilllegen ausführen — ohne Schritt 3, die FROST‑Instanz bleibt stehen.
-
Eine neue Zeile mit dem neuen Slug und derselben FROST Server URL anlegen.
-
Den neuen Slug in den vier REST‑Knoten der Rule Chain dieses ThingsBoard eintragen.
|
Dabei bleiben die Observed‑Property‑Kopien des alten Slugs im FROST‑Server liegen: Der Adapter legt beim Neuanlegen eigene Kopien an und löscht nie etwas. Sie stören nichts, tauchen aber in der öffentlichen SensorThings‑Sammlung doppelt auf, und mit jedem weiteren Umbenennen wächst der Stapel. Sie sollten deshalb von Hand im FROST‑Server entfernt werden, solange noch klar ist, welcher Satz der aktuelle ist — zu entfernen sind nur Einträge, an denen keine Datastreams hängen. Das Vorgehen samt der Abfrage, die den aktuellen Satz von den verwaisten unterscheidet, steht unter Umbenennen in den Betriebsanleitungen. |