New: the AI firewall watches every module and explains each incident in plain words. See how it works

Hosts, the root flow and profile root flows

The IoT and General hosts, how each device message reaches one root flow, the default root, profile roots, and what to check when nothing is stored.

A host is the part of Hermetry that runs flows of one kind. The IoT host runs the flows that receive device messages; the General host runs flows for schedules, webhooks and events. On the IoT host, every device message goes to exactly one root flow, which stores the data. This page explains hosts, root flows and how to change them safely.

The two hosts

IoTGeneral
Message typestelemetry, attributes, connect, disconnect, activity, inactivity, rpc_request, rpc_response, attributes_updated, alarm; also schedules, injects, webhooks, timers and eventsSchedules, injects, webhooks, timers, events, and messages from other flows
Root flowsYes: the tenant-wide root and profile rootsNo
Device blocksDevice message, Save telemetry, Save attributes, Alarm rules, Send command, Raise alarm, enrichment blocks …No
Monthly countDevice messages count as IoT messagesAccepted entries count as Automation messages

You choose the host when you create a flow; it cannot change later. The flow list’s Host filter shows one host’s flows.

Root flows

A root flow is the entry of a host’s device messages. On the IoT host there are two kinds:

RootRuns forRequired
Tenant-wide rootEvery device whose profile has no root of its ownYes: there is always one. It can be replaced, never removed.
Profile rootThe devices of one device profileNo

Each device message starts one root: its profile’s root if there is one, else the tenant-wide root. It enters at the root’s Flow input block (named Device messages in the default root). Telemetry arrives one message per record: a device that sends a batch of 10 timestamped records starts 10 messages.

Root flows show a Root badge in the flow list, with what they run for (“Root · Tenant-wide”, or the profile’s name).

The default root flow

Every organisation starts with the Default root flow, bound tenant-wide. It is created and deployed automatically:

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

“Every device message of this root’s scope enters at its Flow input: the device profile’s alarm rules are evaluated, telemetry and client attributes are saved, RPC requests from devices and other messages are logged. Remove a save node and that data is no longer stored.”

You can edit it like any flow: add derived values, forwarding or filters. Keep Alarm rules, Save telemetry and Save client attributes on their paths, or that work stops for every device the root serves.

Make a profile root

Use a profile root when one group of devices needs different handling, for example a decoder for a profile that sends binary data, or extra steps for one product line.

  1. Create a flow on the IoT host, ideally from the Default root flow template so the storage path is there from the start.
  2. Add your steps. Keep Alarm rules, Save telemetry and Save client attributes.
  3. Deploy it switched on. “Only a flow that runs can be a root there.”
  4. In the flow list, open the flow’s Details and select Set as root.
  5. Under Run it for, pick the device profile and confirm with Set as root.

If the profile already has a root, the dialog says “It replaces flow, which runs here now.” and asks you to type the replaced flow’s name.

A root is never run by another flow. Setting a flow as root removes the Run flow blocks that run it from other flows; each of those flows gets a new version, and the dialog lists them first.

Unbind or delete a root

  • Unbind a profile root from its Details: type the flow’s name to confirm. The profile’s devices then go to the tenant-wide root.
  • Deleting a root flow asks the same, with Unbind and delete.
  • The tenant-wide root cannot be unbound or deleted. To retire it, set another running flow as the tenant-wide root first; then the old one can be deleted.
  • A root must stay switched on and running. Only the emergency stop pauses a root; the automatic pause never does. See Protections and failed messages.

Flows that are not roots

A flow that is not a root does not hear ordinary device messages. It is reached in these ways:

WayHow
From a rootRun flow (hands the message on) or Link out / Link call
Alarm changes and attribute updatesA Device message trigger with the type alarm or attributes_updated ticked by name: these go to every flow that listens, root or not
Command resultsrpc_response messages are device messages: they reach the device’s root. Hand them on from there with Run flow.
Time, webhooks, eventsSchedule, Inject, Webhook, Event, Named timer triggers

A message handed on with Run flow keeps its device, so blocks such as Save telemetry still work there.

Order of messages

Messages of the same device run one after another, in the order they arrived, until the first external call (an HTTP request, a mail, a wait or a Detach). After that point their order is not guaranteed. Messages of different devices run side by side.

Late messages

A device message that waited longer than its time-to-live (5 minutes by default, after an outage) still runs through its root and is stored, marked late. Blocks that act outside the platform skip it. Other flows that listen drop it. See Timestamps, late and duplicate readings.

Online, but nothing is stored

A device can show as online (its connection is tracked by the platform) while its readings are not stored. Check:

  1. Is there a running root? In Automation, filter by the IoT host. A root flow must be Running. A banner “No worker is running the IoT host right now…” means the platform’s processing is down; contact support.
  2. Is the emergency stop on? A banner “Emergency stop: n flows are paused…” means nothing runs until you resume.
  3. Does the device’s profile have its own root? Its root, not the tenant-wide one, handles the device. Check its Save telemetry block.
  4. Does the message reach Save telemetry? Open the root’s Activity panel: the Debug and Errors tabs, and the message counts on the wires.
  5. Does Save telemetry report errors? not_a_device, too_old, no_values, key_limit: see IoT data blocks.
  6. Is the IoT automation available to your organisation? Without it, no device data is stored. Contact support.

See also Data does not arrive.