Alerts That Act, Not Just Notify
An IoT alert is a rule that watches incoming readings and does something when a condition is met. In ioX-Pulse that rule is a workflow: a trigger, the conditions it has to pass, and the actions that follow. Write one against a device profile and every device of that type is covered, including the ones you deploy next month.
The actions are not limited to telling somebody. A workflow can mark the device so its state is visible everywhere it appears, send a command back to the device, fire a multicast group, or post the event to your own system. Noticing and responding are the same rule rather than two separate jobs with a person in between.
- Write a rule once against a device type instead of once per device
- Acknowledge an alarm and it stops telling you, without stopping the automated response
- A per-device hourly ceiling means one failing sensor cannot swamp everybody's inbox
- Alerts recover when the condition actually clears, not when a timer expires
- Rules shipped with a device profile arrive switched off, so a new deployment does not alarm on day one
- Send to a named list rather than a pile of addresses copied between rules
Trusted by teams monitoring critical infrastructure
Write it once for a product line
Where a Workflow Applies
Every workflow has a scope, and the scope is what decides whether you are writing one rule or four hundred.
Device profile THE ONE THAT MATTERS
Every device of that type. Say once that every thermometer in a product line alerts above a threshold, and it applies to the ones you have not shipped yet.
Sub-account
Every device inside one customer's account, whatever type they are.
Device
One specific device, for the cases that genuinely do not generalize.
On a profile-scoped workflow the field picker offers that profile's fields, so you are choosing from the named readings the decoder produces rather than typing identifiers and hoping.
The part nobody writes about
What Happens When a Sensor Goes Haywire
A sensor sitting exactly on a threshold will cross it hundreds of times in a night. A gateway going down takes a whole site with it. A fleet that has just been deployed alarms on everything at once. Anyone who has run monitoring has been woken by one of these, and it is the reason people stop trusting alerts. Four things stand between that and your team.
Acknowledge the alarm
An operator saying they have seen it. Emails, texts and in-app rows pause for that rule on that device while the condition stays true, but downlinks and multicasts keep running. Acknowledging silences the telling, not the doing.
Recovery on the condition
An alarm closes when the reading actually recovers, not when a timer runs out. The next trip is a new alarm, and notifications resume in full, so acknowledging today does not blind you tomorrow.
A per-device hourly ceiling
Once a device has fired a set number of times within a rolling hour, further notifications stop while the device's alert state and its automated actions carry on. One broken sensor cannot fill an inbox.
Templates that ship disabled
Rules shipped with a device profile arrive switched off. Somebody has to clone, review and enable them, which is what stops a freshly onboarded fleet alarming on everything the moment it comes online.
More than an email
What a Workflow Can Do
Telling somebody is one option among several, and often the least useful one at three in the morning.
Send email
To a named notification group, to individual addresses, or both.
Set the device's alert state
Marks the device as information, warning or alert. The state shows on the device list, on dashboards and in the device header, so anybody who looks sees it without having received the email.
Send a downlink
Acts on the device. Close the valve, change the reporting interval, move the threshold.
Trigger a multicast group
Sends a command to a group of devices at once rather than one at a time.
Post to a webhook
Sends the event to a URL you provide, so it lands in your own system rather than only in ours.
The honest version
Alerting Bolted On Against Alerting Built In
Most teams already have alerting of some kind, usually a script watching an export or a threshold in a chart tool. Here is the same work, done both ways.
| The job | A script or a chart tool alert | With ioX-Pulse |
|---|---|---|
| Covering a new device of an existing type | Add it to the rule, if somebody remembers | Already covered, because the rule is on the profile |
| A sensor flapping on the threshold | Everybody's inbox, until somebody mutes the rule for good | Acknowledge it, and the automated actions keep running |
| Knowing an alert cleared | Another alert, or nothing | The alarm closes when the reading recovers |
| Acting on the device | A person, a laptop and a second system | A downlink in the same rule |
| Getting the event into your own system | Build the integration | Point the webhook at your endpoint |
| A new deployment going live | Silence the rules, then remember to turn them back on | Templates arrive disabled and are enabled deliberately |
| Changing who is on call | Edit every rule | Edit the group |
