OhioIoT
Menu

Rules & Alerts

Watch a value. When it crosses a line you set, do something — text you, email you, message the dashboard, publish to a device, or fire a saved Command.

A rule is a sentence: when this field does this, take these actions. You build it in the dashboard from a field, a comparison, a threshold, and one or more actions. No code, no cron job.

The anatomy of a rule

Every rule has three parts:

  • A condition — a field to watch, a comparison operator, and a threshold. For example: freezer/temp is > -10.
  • A debounce window — how long the condition must hold, or how long to wait before the rule may fire again, so a value flickering across the line doesn't spam you.
  • One or more actions — what to do when it trips.

What a rule can do

A single rule can fire several actions at once. The full set:

SMSText message to your number on file.
WhatsAppMessage to your WhatsApp number.
EmailEmail to your account address.
In-app messageA note in your dashboard messages inbox.
MQTT publishSend a message to a topic — e.g. tell a device to shut a valve.
HTTP webhookCall an external URL.
Fire a CommandRun one of your saved Commands.

That last two are what turn alerting into automation: a rule can not only tell you something is wrong, it can act on it — close the valve, then text you that it did.

Why your phone doesn't melt

A naive threshold check fires on every reading above the line — once a second, forever, until the value drops. OhioIoT rules carry alert state: once a rule trips, it stays tripped and does not re-fire until it has cleared and the debounce window has passed. You get one text when the freezer warms up, not six hundred.

A tripped rule shows as alerting on the dashboard, and you can clear the alert by hand if you've dealt with the situation and want the rule armed again immediately.

Aliases make messages readable

Devices and fields are identified internally by IDs that are stable but not pleasant to read. Aliases let you attach friendly names so an alert says "Garage freezer is above -10°F" instead of a topic path full of hex. You set aliases once in the dashboard and every rule message, graph label, and device card uses them.

Write the alert text the way you'd want to read it at 2 a.m. The whole point of a rule is that it reaches you when you're not looking at the dashboard — the message should make sense on its own.

A worked example

Suppose you've got a sump pump and a water sensor publishing a level reading:

Watch:      basement/water_level
Condition:  >  20   (mm above the floor)
Debounce:   sustained 30s
Actions:    1) MQTT publish  ~/pump01/command/run  ->  on
            2) SMS:  "Basement water at {value}mm — pump started."

Water rises, holds above the line for thirty seconds, the pump kicks on, and you get one text. When the level falls back the rule re-arms itself for next time.