Hosts, der Root-Flow und Profil-Root-Flows

Ein Host ist der Teil von Hermetry, der Flows einer Art ausführt. Der IoT-Host führt die Flows aus, die Gerätenachrichten empfangen; der General-Host führt Flows für Zeitpläne, Webhooks und Ereignisse aus. Auf dem IoT-Host geht jede Gerätenachricht an genau einen Root-Flow, der die Daten speichert. Diese Seite erklärt Hosts, Root-Flows und wie Sie diese sicher ändern.

Die beiden Hosts

	IoT	General
Nachrichtentypen	`telemetry`, `attributes`, `connect`, `disconnect`, `activity`, `inactivity`, `rpc_request`, `rpc_response`, `attributes_updated`, `alarm`; außerdem Zeitpläne, Injects, Webhooks, Timer und Ereignisse	Zeitpläne, Injects, Webhooks, Timer, Ereignisse und Nachrichten aus anderen Flows
Root-Flows	Ja: der mandantenweite Root und die Profil-Roots	Nein
Gerätebausteine	Device message, Save telemetry, Save attributes, Alarm rules, Send command, Raise alarm, Anreicherungsbausteine …	Nein
Monatliche Anzahl	Gerätenachrichten zählen als IoT-Nachrichten	Angenommene Einträge zählen als Automation-Nachrichten

Den Host wählen Sie beim Anlegen eines Flows; er lässt sich später nicht mehr ändern. Der Filter Host in der Flow-Liste zeigt die Flows eines Hosts.

Root-Flows

Ein Root-Flow ist der Einstiegspunkt für die Gerätenachrichten eines Hosts. Auf dem IoT-Host gibt es zwei Arten:

Root	Läuft für	Erforderlich
Mandantenweiter Root	Jedes Gerät, dessen Profil keinen eigenen Root hat	Ja: Es gibt immer einen. Er kann ersetzt, aber nie entfernt werden.
Profil-Root	Die Geräte eines Geräteprofils	Nein

Jede Gerätenachricht startet einen Root: den Root ihres Profils, falls vorhanden, sonst den mandantenweiten Root. Sie tritt am Baustein Flow input des Roots ein (im Standard-Root heißt er Device messages). Telemetrie kommt als eine Nachricht pro Datensatz an: Ein Gerät, das einen Stapel mit 10 zeitgestempelten Datensätzen sendet, startet 10 Nachrichten.

Root-Flows zeigen in der Flow-Liste ein Badge Root mit dem Bereich, für den sie laufen („Root · Tenant-wide“ bzw. der Name des Profils).

Der Standard-Root-Flow

Jede Organisation beginnt mit dem Default root flow, der mandantenweit gebunden ist. Er wird automatisch angelegt und bereitgestellt:

Device messages (Flow input)
  → Alarm rules
  → Message type (Switch on msg.metadata.msgType)
       telemetry   → Save telemetry
       attributes  → Save client attributes
       rpc_request → System log "RPC request from …"
       otherwise   → System log "Other device message"
Errors (Catch, uncaught only) → System log

„Jede Gerätenachricht des Bereichs dieses Roots tritt an seinem Flow input ein: Die Alarmregeln des Geräteprofils werden ausgewertet, Telemetrie und Client-Attribute werden gespeichert, RPC-Anfragen von Geräten und andere Nachrichten werden protokolliert. Entfernen Sie einen Speicherbaustein, werden diese Daten nicht mehr gespeichert.“

Sie können ihn wie jeden Flow bearbeiten: Werte ableiten, weiterleiten oder filtern. Lassen Sie Alarm rules, Save telemetry und Save client attributes auf ihren Pfaden, sonst hört diese Arbeit für jedes Gerät auf, das der Root bedient.

Einen Profil-Root anlegen

Verwenden Sie einen Profil-Root, wenn eine Gerätegruppe anders behandelt werden muss, zum Beispiel ein Decoder für ein Profil, das Binärdaten sendet, oder zusätzliche Schritte für eine Produktlinie.

Legen Sie einen Flow auf dem IoT-Host an, idealerweise aus der Vorlage Default root flow, damit der Speicherpfad von Anfang an vorhanden ist.
Fügen Sie Ihre Schritte hinzu. Lassen Sie Alarm rules, Save telemetry und Save client attributes bestehen.
Stellen Sie ihn eingeschaltet bereit. „Nur ein laufender Flow kann dort Root sein.“
Öffnen Sie in der Flow-Liste die Details des Flows und wählen Sie Set as root.
Wählen Sie unter Run it for das Geräteprofil aus und bestätigen Sie mit Set as root.

Hat das Profil bereits einen Root, sagt der Dialog „Es ersetzt flow, der hier jetzt läuft.“ und bittet Sie, den Namen des ersetzten Flows einzugeben.

Ein Root wird nie von einem anderen Flow ausgeführt. Wenn Sie einen Flow als Root setzen, werden die Run flow-Bausteine entfernt, die ihn aus anderen Flows heraus ausführen; jeder dieser Flows erhält eine neue Version, und der Dialog listet sie zuerst auf.

Root lösen oder löschen

Unbind einen Profil-Root über dessen Details: Geben Sie zur Bestätigung den Namen des Flows ein. Die Geräte des Profils gehen dann an den mandantenweiten Root.
Beim Löschen eines Root-Flows wird dasselbe abgefragt, mit Unbind and delete.
Der mandantenweite Root kann nicht gelöst oder gelöscht werden. Um ihn außer Betrieb zu nehmen, setzen Sie zuerst einen anderen laufenden Flow als mandantenweiten Root; danach kann der alte gelöscht werden.
Ein Root muss eingeschaltet bleiben und laufen. Nur der Notstopp hält einen Root an; der automatische Stopp tut das nie. Siehe Schutzmechanismen und fehlgeschlagene Nachrichten.

Flows, die keine Roots sind

Ein Flow, der kein Root ist, empfängt keine gewöhnlichen Gerätenachrichten. Er wird auf diesen Wegen erreicht:

Weg	Vorgehen
Von einem Root	Run flow (reicht die Nachricht weiter) oder Link out / Link call
Alarmänderungen und Attributaktualisierungen	Ein Device message-Auslöser mit dem Typ `alarm` oder `attributes_updated`, nach Name angehakt: Diese gehen an jeden Flow, der zuhört, Root oder nicht
Befehlsergebnisse	`rpc_response`-Nachrichten sind Gerätenachrichten: Sie erreichen den Root des Geräts. Reichen Sie sie von dort mit Run flow weiter.
Zeit, Webhooks, Ereignisse	Schedule-, Inject-, Webhook-, Event– und Named timer-Auslöser

Eine Nachricht, die mit Run flow weitergereicht wird, behält ihr Gerät, sodass Bausteine wie Save telemetry dort weiterhin funktionieren.

Reihenfolge der Nachrichten

Nachrichten desselben Geräts laufen nacheinander in der Reihenfolge ihres Eintreffens, bis zum ersten externen Aufruf (eine HTTP-Anfrage, eine E-Mail, eine Wartezeit oder ein Detach). Danach ist ihre Reihenfolge nicht garantiert. Nachrichten verschiedener Geräte laufen parallel.

Verspätete Nachrichten

Eine Gerätenachricht, die länger als ihre Time-to-live (standardmäßig 5 Minuten, nach einem Ausfall) gewartet hat, läuft trotzdem über ihren Root und wird als verspätet markiert gespeichert. Bausteine, die außerhalb der Plattform handeln, überspringen sie. Andere zuhörende Flows verwerfen sie. Siehe Zeitstempel, verspätete und doppelte Messwerte.

Online, aber nichts wird gespeichert

Ein Gerät kann als online erscheinen (seine Verbindung wird von der Plattform verfolgt), während seine Messwerte nicht gespeichert werden. Prüfen Sie:

Gibt es einen laufenden Root? Filtern Sie in Automation nach dem IoT-Host. Ein Root-Flow muss Running sein. Ein Banner „No worker is running the IoT host right now…“ bedeutet, dass die Verarbeitung der Plattform ausgefallen ist; wenden Sie sich an den Support.
Ist der Notstopp aktiv? Ein Banner „Emergency stop: n flows are paused…“ bedeutet, dass nichts läuft, bis Sie fortsetzen.
Hat das Geräteprofil einen eigenen Root? Dessen Root, nicht der mandantenweite, verarbeitet das Gerät. Prüfen Sie seinen Baustein Save telemetry.
Erreicht die Nachricht Save telemetry? Öffnen Sie das Panel Activity des Roots: die Tabs Debug und Errors sowie die Nachrichtenzähler an den Verbindungen.
Meldet Save telemetry Fehler? not_a_device, too_old, no_values, key_limit: siehe IoT-Datenbausteine.
Ist die IoT-Automation für Ihre Organisation verfügbar? Ohne sie werden keine Gerätedaten gespeichert. Wenden Sie sich an den Support.

Siehe auch Data does not arrive.