Rules and actions
A rule watches for an event, evaluates its conditions, and runs its actions. Use a rule when the same response should happen automatically whenever a known condition occurs—for example, send a command when a temperature crosses a limit.
What works today
The current runtime supports this complete path:
- Trigger: new device measurement
- Conditions: equals, does not equal, greater/less than, inclusive comparisons, contains, and exists
- Logic: all conditions must match, or any condition may match
- Action: a single-device MQTT downlink, sent either to the triggering device or to a specific device
The action builder also shows email, SMS, push notification, webhook, multi-device downlink, and set-value actions. These configurations can be saved, but the current worker does not execute them yet. Device/gateway status and scheduler templates are also visible but do not currently run. Do not use those options for production automation until their runtime support is deployed.
Build a measurement rule
Before starting, create and manually test the MQTT downlink you want the rule to run. See Send a downlink.
Choose the event
Open Rules, select Create rule, then choose New measurement recorded. Give the rule a clear name and description.
Add conditions
Select a device and one of its measurement inputs, then choose an operator and comparison value. Add more conditions if needed and choose whether all or any must match.
A rule is evaluated only when the incoming measurement updates at least one field used by its conditions. For conditions that reference another device, HERAIOT uses that device’s latest stored reading.
Add the downlink action
Choose Single Device Downlink. Select either the triggering device or a specific target, then select that device’s saved MQTT downlink.
Automatic rule execution currently supports MQTT downlinks. An HTTP downlink can be run manually from the device page, but cannot be the action for a measurement rule yet.
Save with the rule disabled
Review the event, conditions, target device, and downlink. Save the rule while disabled so it cannot act before the final checks are complete.
Test, then enable
Run the selected downlink manually with safe values. Confirm the MQTT topic, payload, and device-reported state. Return to Rules and enable the rule only after the manual path is proven.
Condition behavior
| Operator | Match behavior |
|---|---|
| Equals / does not equal | Compares as numbers when both values are numeric; otherwise compares text |
| Greater/less than | Requires numeric values |
| Contains | Searches text without case sensitivity, or checks membership in an array |
| Exists | Matches when the field is neither missing nor null |
An unrelated measurement does not fire a rule based only on previously stored values. This prevents a true but stale condition from running again every time another device reports.
Avoid repeated or unsafe actions
Each measurement event has an idempotency key, so the same rule action is not sent twice for that event. A later measurement is a new event and may match again. Design the receiving device command to be safe if the condition remains true across several reports.
The rule’s advanced repeat and time-restriction settings are saved by the editor, but the current worker does not enforce them. Treat every matching new measurement as eligible to run the configured MQTT action.
Verify the result
Rule execution stores an overall status and the result of each action. The in-app Logs tab may require an upgraded plan and currently displays its availability notice. You can always verify the target device’s next state report; a successful MQTT publish confirms broker acceptance, not physical execution.
If a rule does not run, check in this order:
- The rule is enabled and uses New measurement recorded.
- The new payload includes a field used by at least one condition.
- The condition value and operator match the incoming data type.
- The selected action is Single Device Downlink.
- The selected downlink is MQTT, belongs to the target device, and works manually.
- The target device has a broker and subscribes to the generated topic.
For multi-stage transformations or integrations, use a workflow instead.