A flow is a chain of blocks on a canvas. A trigger starts it with a message; blocks then check, route, transform, store, wait and act. Flows are Hermetry’s most flexible automation tool: they store your device data, compute derived values, call outside systems, send notifications and commands, and react to schedules, webhooks and events.
You build flows under Automation. Each flow is edited as a draft and runs only after you Deploy it; every deploy is a numbered version you can roll back to.
What flows do in Hermetry
| Job | How |
|---|---|
| Store device data | The root flow receives every device message and saves telemetry and attributes. Only flows store data. |
| Evaluate alarm rules | The root flow’s Alarm rules block runs the device profile’s alarm rules. |
| Derive values | Blocks between the device message and Save telemetry compute new keys. |
| Integrate | HTTP request, MQTT out and Webhook blocks send data out; a Webhook trigger takes data in. |
| React | Triggers on schedules, alarms, attribute changes, named timers and events start work. |
| Tell people and devices | Notify, Raise alarm, Send command and Set shared attribute blocks. |
Hosts
Every flow belongs to one host, chosen when you create it and never changed:
| Host | Shown as | Receives | Typical flows |
|---|---|---|---|
| IoT | IoT | Device messages, alarms, attribute changes, plus schedules, webhooks and events | The root flow, profile root flows, alarm escalations, integrations of device data |
| General | General | Schedules, webhooks, events and other flows’ messages | Integrations and jobs that do not work on a device’s message |
The host decides which blocks you can use: the device blocks (Save telemetry, Send command, Raise alarm …) exist only on the IoT host. See Hosts, the root flow and profile root flows.
Flows, alarm rules and the Rules card
| Tool | Best for | Built where |
|---|---|---|
| Alarm rules | Thresholds and conditions on a device profile’s readings, with debounce, hysteresis and notifications | The device profile’s Alarm rules tab. Alarm rules on device profiles |
| Rules card | “When this happens, do that” for operators: commands, settings, notifications, Manual and Auto modes | A dashboard’s Rules card. The rules engine |
| Flows | Everything else: transforming and storing data, integrations, logic that the other two cannot express | Automation |
A Rules-card rule runs as a flow too. It appears in the flow list with a Built by badge and opens read-only; change it on the Rules card, or Detach into an ordinary flow to edit it here (this cannot be undone). See Flows in the alarms section.
Who may do what
| Permission | Default role | Allows |
|---|---|---|
| View flows and the node catalog | Admin | Open the flow list and the editor read-only |
| Create, edit and deploy flows | Admin | Everything to build and deploy flows, import and export |
| Deploy flows with control-level nodes | Admin | Deploy flows with blocks that control devices or other flows |
| Inject messages, see payloads and dead letters | Admin | See message contents, debug, test from live state, replay failed messages |
| Call session-auth webhooks of deployed flows | User | Start a flow from a dashboard control or app page through a session webhook |
Messages
Blocks pass messages. The fields you use most:
| Field | Holds |
|---|---|
msg.payload | The data: a device’s readings, a webhook’s body, a schedule’s tick |
msg.topic | A short label; many blocks key their memory on it |
msg.metadata | Facts about the message: deviceId, deviceName, profileName, msgType, ts (receive time), recordTs (reading time) and more. Never stored. |
msg.msgType | telemetry, attributes, connect, alarm … Read-only. |
msg.originator | Who the message is about: a device, the organisation or the flow. Read-only. |
Values in block settings can be fixed values, paths such as msg.payload.level, expressions, or {{ }} templates. See Condition blocks.
In this section
| Page | What it covers |
|---|---|
| The flow editor | Canvas, palette, wiring, block settings, saving and deploying |
| Hosts, the root flow and profile root flows | Where device messages go and how data is stored |
| Versions, testing and rollback | Drafts, versions, the test runner, rollback, import and export |
| Protections and failed messages | Automatic pauses, the emergency stop, failed messages and alerts |
| Flow templates | Ready flows to start from |
| Flow limits | Plan limits and fixed limits |
| Trigger blocks | What starts a flow |
| Condition blocks | Yes/no tests, and the expression language |
| Routing and timing blocks | Switch, gate, split, join, delay, rate limit … |
| Data transform blocks | Change, calculate, template, JSON, CSV, bytes … |
| Counters, statistics and watchdogs | Blocks that remember |
| The script block | JavaScript in a flow |
| Action blocks | HTTP, MQTT, webhooks, events, variables, timers, other flows, logging |
| IoT data blocks | Saving telemetry and attributes, alarm rules, enrichment |
| Alarm, command and notify blocks | Alarms, device commands, device requests, notifications |
| Connections and secrets | MQTT brokers and HTTP endpoints |
| Flow cookbook | Ready-to-build flows |
| Troubleshooting flows | Finding out what a flow did |