Rules that fire on an event
Most rules watch a reading and fire when it crosses a threshold. Some of the things worth reacting to aren't readings at all: a job finishing, a device dropping offline, a gateway coming back. Those are events, and a rule can fire on one directly.
Creating one
- Open Rules → New rule.
- Under Fire this rule when…, choose Something happens.
- Pick the event.
- Add actions exactly as you would on any other rule.
There's no tag, operator or threshold on an event rule — there's no reading to compare. The actions simply run each time the event happens.
What you can trigger on
| Group | Events |
|---|---|
| Jobs | A job starts · A job finishes · A job is aborted |
| Devices | A device comes online · A device goes offline |
| Gateways | A gateway comes online · A gateway goes offline |
Job triggers appear only if jobs are enabled on your account.
Narrowing a job trigger
A job trigger fires for any job by default. If you only care about one kind of run — say you want to POST a report when a drilling job finishes, but not a maintenance one — pick a Job type and the rule ignores the rest.
What to do about it
Every action available to a threshold rule works here too: in-app, email, webhook, MQTT, a saved action, controlling an actuator, and starting or ending a job. A few combinations that come up often:
- A job finishes → webhook. The most common one. The webhook receives the job number, the job type and the machine, so your own system can pull the report and file it.
- A job finishes → control an actuator. Park a valve, kill a pump, sound a hooter.
- A gateway goes offline → email. You'll usually want a cooldown of an hour or so on this one; a gateway on a flaky link can flap.
Cooldown still applies
A cooldown stops a rule re-firing within the window you set, exactly as it does for a threshold rule. It's worth setting deliberately here: events can arrive in bursts, and a gateway reconnecting three times in a minute would otherwise send three emails.
One case is handled for you. If a machine loses power mid-job and re-announces that job when it boots, the rule won't fire a second time for the same run — you get one webhook per job, not one per restart.
Starting and stopping jobs from a rule
The reverse also works: Start a job and End a job are action types, so a threshold or an event can open or close a run. A job normally starts from a switch on the machine; this is the option when the signal is a reading instead.
Both are safe to fire repeatedly, which matters because a condition like "spindle current above 40 A" stays true for a long stretch:
- Start a job joins the run already open on that machine instead of starting a second one.
- End a job does nothing when no run is open.
Related: Create an alerting rule · Severity and cooldown · Webhook actions