A connected product that only displays numbers is a gauge. One that tells you something has gone wrong before you would have noticed is worth paying for, often monthly. The gap between them is a rules engine: the layer that watches incoming data, decides when a condition matters, and does something about it.
It is also the layer most often built badly. The first version is three hard-coded thresholds. The tenth customer wants different ones. The twentieth wants alerts only during business hours. Then someone gets forty notifications in an hour from a flapping sensor and turns notifications off permanently — and once a user has done that, your alerts have no value at all, however correct they become later.
Anatomy of a rule
Every workable rules engine, from a simple one to an industrial platform, decomposes into the same five parts. Naming them explicitly keeps the design from turning into a pile of conditionals.
- Scope. Which devices the rule applies to — one unit, a tagged group, an entire account, or every device of a model.
- Trigger. What causes evaluation: a new measurement, a schedule, a state change, or a period of silence from the device.
- Condition. The test. Thresholds, ranges, rate of change, comparison against a baseline, or a combination joined by AND/OR.
- Qualifier. The part that separates a usable alert from noise: how long the condition must persist, how many consecutive samples, what time window, and what suppression applies.
- Action. Push notification, email, SMS, webhook, ticket creation, or a command back to the device.
Store rules as data, not as code. A rule that lives in a database row can be edited by a support agent, versioned, disabled during an incident, and exposed to customers later. A rule compiled into the backend requires a deployment and cannot ever be given to a user.
Conditions that survive real data
Naive threshold tests fail in predictable ways once real sensors are involved, because real signals are noisy and real devices drop offline.
Hysteresis
A single threshold at 75 °F produces an alert storm when the actual value hovers at 74.9 and 75.1. Use two thresholds: trigger at 75, clear at 73. The gap should be at least two to three times the sensor's noise band. This one change eliminates the majority of duplicate alerts in most products.
Debounce and persistence
Require the condition to hold. "Above threshold for 5 consecutive readings" or "above threshold continuously for 10 minutes" turns a spike into a non-event while still catching a genuine excursion. Choose the window from the physics: a freezer that opens for thirty seconds is normal, one that is warm for twenty minutes is a problem.
Rate of change
Often more informative than absolute value. A battery that drops 8% in an hour is a fault even at 90% charge. A pressure that climbs steadily toward a limit is a warning you can act on before the limit is reached, which is the entry point to predictive maintenance from product data.
Absence of data
The most valuable rule in almost every fleet, and the one most often forgotten: alert when a device has reported nothing for longer than expected. Silence means power loss, connectivity loss, or a crash — failures no threshold rule will ever catch.
Baselines instead of fixed numbers
When every installation is different, a fixed threshold is wrong everywhere. Learn a per-device baseline over the first days of operation and alert on deviation from it. It costs complexity and storage — you need the query patterns a time-series database provides — but it is often the difference between a product that works in one building and one that works in a thousand.
Where the rule runs: device, gateway, or cloud
Rules can be evaluated at three places, and most mature products use all three.
| On the device | On a gateway | In the cloud | |
|---|---|---|---|
| Latency | Milliseconds | Tens of milliseconds | Seconds |
| Works offline | Yes | Locally, yes | No |
| Data cost | Lowest — send only events | Low | Highest — send everything |
| Changeable | Needs a firmware update | Config push | Instantly |
| Cross-device logic | No | Within the site | Yes |
| Complexity possible | Simple comparisons | Moderate | Anything |
The sensible split: safety-critical and time-critical rules run on the device, because they must work when the network does not — the same reasoning behind local control versus cloud control. Everything analytical, cross-device, or customer-configurable runs in the cloud. Sending only events rather than raw streams also has a direct effect on what your cloud infrastructure costs per month, since ingest and storage volume are the dominant line items.
Alert fatigue is the real failure mode
A false alarm is not a minor annoyance. It is a withdrawal from a trust account, and once the account is empty the user ignores the alert that mattered. Design against it deliberately:
- Deduplicate. One alert per condition per device until it clears, not one per sample.
- Cool down — a minimum interval between repeat notifications, typically 15 to 60 minutes.
- Group. When forty devices at one site go offline together, send one alert about the site.
- Send a clear notice. Telling someone the problem resolved is what keeps them from ignoring the next one.
- Respect quiet hours. Only genuine emergencies should wake anyone; the rest waits for a morning digest.
- Let people snooze and mute, or they will mute your app at the OS level, which you cannot undo.
- Measure it. An alert type with a 5% action rate is noise and should be demoted or deleted.
Delivery mechanics matter as much as logic. Push notifications are cheap and easily ignored; SMS costs roughly a cent per message and interrupts; email suits digests and fails at urgency; a webhook into the customer's own system is often what a business customer actually wants — see push notifications from a connected device.
Severity and escalation
Three levels is usually right: informational, warning, and critical. Escalation chains — notify the technician, then after fifteen minutes the supervisor, then the account owner — are a strong differentiator in B2B products and a common reason a customer picks a paid tier. They require acknowledgment tracking, which means alerts need identity and state, not just delivery.
Automations: when the rule acts on the product
Once rules can trigger commands back to the device, an alert system becomes an automation system: shut the valve, throttle the motor, switch to the backup pump. That is a large step up in risk, and it needs guardrails.
- Confirm state before acting — never act on stale data.
- Make actions idempotent. The same command sent twice must not produce two effects.
- Rate limit hard, so a flapping sensor cannot cycle a compressor a hundred times.
- Require a manual override that is obvious and always available.
- Log everything immutably — which rule fired, on what data, what the device did, and who could have stopped it. When an automation causes damage, this log is the whole investigation, and it belongs alongside the device's own diagnostic logging.
- Never automate a safety function in the cloud. If the consequence of not acting is injury or property damage, the logic lives in firmware behind a hardware interlock.
Letting customers write their own rules
Eventually a customer wants a rule you did not anticipate. The usual progression runs from fixed rules, to adjustable thresholds, to a template builder with pickers for device, metric, comparison, and action, to a full expression language. Most products should stop at the template builder: it covers the overwhelming majority of requests at a fraction of the cost, without a support burden of debugging customers' expressions.
Whatever the level, give users a way to test a rule against historical data before enabling it. "This rule would have fired 47 times in the last 30 days" prevents most misconfigured alerts before they ever reach a phone. Surface rule status and recent firings in the management console, and for business deployments expect to push alerts into the customer's existing systems through ERP and CRM integration rather than expecting their staff to log into yours.
Build, buy, and what it costs
Cloud IoT platforms all ship rules functionality, and for simple threshold-and-notify products they are a reasonable start. A purpose-built engine makes sense when you need stateful conditions across many devices, per-customer configurability, or escalation semantics the platform lacks; budget roughly $40,000 to $120,000 of engineering for rule storage, evaluation, deduplication, escalation, delivery, and an admin UI. Then monitor the engine itself: a rules service that silently stops evaluating is worse than no alerts at all, which is exactly the argument for monitoring your backend before customers notice.
Projects House builds connected products end to end, including the backend logic that turns raw measurements into alerts people act on and automations that are safe to trust. If you have a product producing data and want to know what it should be telling your customers, describe it through our contact form.