Platform Documentation

Alerts watch your device data and tell you when something needs attention. You define a condition, NEQTO.ai checks every reading against it, and when the condition is met it fires an alert and notifies the people you chose. Every alert that fires is recorded in Alert History so you can track and triage it.

The UI says Attribute and Endpoint; the API and support docs call these data type and data source. They are the same things, and this page uses the UI words.

Quick Start

If you already know NEQTO.ai, here is the short version.

• 1
  Open an application, go to Alerts, and click the + button to open the Set Alert dialog.
• 2
  Give the alert a title and a severity, then add a trigger condition: a device, one of its attributes, an operator, and a value. For example temperature Greater than 30.
• 3
  Leave Unlock by Timer on so one ongoing problem does not notify repeatedly. At the bottom, pick who to tell. Email and SMS both arrive switched on, so turn SMS off if this alert should only send mail.
• 4
  Click Create. The alert is checked against every reading from then on, and each time it fires the event appears in Alert History.

Alert Types

NEQTO.ai evaluates three kinds of alert. You build threshold alerts yourself in the Set Alert dialog. Connectivity and anomaly alerts are turned on per device — and, for anomalies, per sensor — from that device’s Connectivity Monitoring and Anomaly Detection Settings tabs. All three appear together in Alert History.

An older kind of alert compared an attribute against its own recent history. The platform still understands those, but the Set Alert dialog now creates threshold alerts, and an old history alert opens as one.

Creating a Threshold Alert

Open Alerts and click the + button (its tooltip reads Create Alert) to open the Set Alert dialog. The dialog has six parts, in this order: title and severity, trigger conditions, unlock conditions (optional), message details (optional), payload push (optional), and notifications.

Each row shows a Status switch with an Active or Inactive badge, a Severity badge, a lock icon while the alert is locked (paused), the devices it covers and the attributes it watches. The row’s actions menu (the ⋮ button) offers Edit and Delete, each shown only with the matching permission. There is no “lock” action: locking comes from the alert’s unlock settings, below.

1. Title and severity

• 1
  Enter an Alert Title (required, up to 100 characters; letters, numbers, spaces, and the basic punctuation - _ ( ) , . : are allowed).
• 2
  Pick a Severity: Info (blue), Warning (yellow, the default), or Critical (red). Severity is a label for triage and filtering; it does not change when the alert fires.

2. Trigger conditions

A condition is one row: a device, one of its attributes, an operator, and a value. Add up to 10 conditions.

The available operators depend on the attribute’s data type:

What the dialog offers for combining conditions depends on how many you have added. With two or more, a Condition logic control appears: AND (All) fires only when every condition is true at once, OR (Any) when at least one is, and NOR (None) only when none are. With exactly one condition there is nothing to combine, so you get a switch instead, Alert when this condition is not met. Turn it on and the alert fires when the condition is false. Either way, conditions are re-checked as each device’s readings arrive.

Each condition’s value field has a Compare to switch. Use a value, the default, compares against a fixed number — or a keyword, on a text attribute. Use a tag compares against one of your tags instead: click the braces icon, search, and pick one. Point several alerts at the same tag and a shared limit changes in one place instead of in every alert.

The picker only offers tags whose value type fits the attribute, and greys out the rest. Once you pick one, a preview shows what it resolves to right now, for example Resolves to 30. If the tag is later deleted, or stops fitting, the field flags it and blocks Save.

A condition can compare the result of a calculation instead of the number the device sent — a short formula built from that device’s own attributes, re-run on every reading. A sensor sending Fahrenheit can be watched in Celsius. Once a row names both a device and an attribute, a Σ marker and an Add calculation button appear beside it, and only numeric attributes accept one.

Writing the formula, what it changes about the condition, and what clears it are the same wherever this appears, so they are documented once under Calculated Conditions below.

3. Unlock conditions (optional)

Unlock conditions control how an alert re-arms after it fires. With either method on, the alert fires once, then locks and goes quiet until it is allowed to re-arm. So a timer’s length is the minimum gap between notifications about the same problem. Unlock by Timer is on by default at 60 minutes. Turn both methods off and the alert stays locked until you re-enable it by hand.

4. Message details (optional)

Message details adds context to the message sent to the people you notify, on whichever channels you switch on below. Everything here is off by default.

• Include application link — adds a link back to the application the alert belongs to.
• Include device tags — turning this on reveals a picker so you choose which of the device’s tags to include in the message.
• Include device endpoint — adds a link to the device’s endpoint.
• Custom message — a free-text note (up to 160 characters) added to the alert message.

5. Payload push (optional)

Email and SMS tell a person that something happened. Payload push tells a machine. When the alert fires it also sends a message of your own design to an integration or a device endpoint, separately from the notifications below it.

The section starts empty, reading “No payload push targets configured.” Click Add target, pick a destination, and optionally write a payload template. An alert may have up to five targets, and Add target greys out at five.

That is all of it inside this dialog. Destinations, templates, tokens, what blocks a save, and what each delivery outcome means are the same wherever payload push appears, so they are documented once under Payload Push below.

6. Notifications

The bottom of the dialog is where you say who to tell, and how. Email notifications and SMS notifications are independent and both are on by default, and they use the same recipient list. Turn off either channel if you do not want to use it.

A Notification Recipients block appears as soon as either switch is on. Turn both off and the individual users you picked are cleared, though external contacts and groups are left alone.

For an account user, turning SMS notifications on is only half of it. They also need a phone number on their profile and the SMS opt-in switched on there, and a user with neither is skipped quietly, by design. External contacts work the other way round: you set their email and SMS preferences yourself when you add them.

Payload push does not depend on either switch. An alert with both switches off still sends its payload. A failed push cannot cost anyone their email or text either: each destination records its own outcome, and none of them stops a notification going out.

Three kinds of recipient go into that one list:

• Users from your account or application, added with Add Recipient → Add User. Each is reached on the channels you switched on, as far as their own profile allows.
• External contacts, added with Add Recipient → Add External. Give an email address and/or a phone number, and toggle Email and SMS per contact. Phone numbers use E.164 format, for example +1234567890.
• Notification Groups, reusable recipient lists (see below).

Notify account owners & administrators sits below the recipients and is on by default, adding the account’s owners and administrators to whoever you picked. It only matters once at least one individual user is picked: with none, everyone is notified regardless.

Every alert that fires is written to Alert History whichever channels are on, so there is nothing to switch on for in-app activity.

Click Create to save. Editing an existing alert opens the same dialog (titled View Alert) with a Save button.

Calculated Conditions

A calculation lets an alert watch something the device never reports. A device sending a supply and a return temperature can be watched on the gap between them, and one sending Fahrenheit can be watched in Celsius. Nothing changes on the device; the alert does the arithmetic.

Adding a calculation

• 1
  Add calculation opens the editor with an empty formula and one variable already bound: a, the attribute the condition watches. It cannot be removed, because a formula ignoring it would be comparing something else. Writing the formula is still yours to do — insert a from its card, or type it — and Save stays greyed out until you do.
• 2
  Edit calculation reopens the saved formula, though you rarely need it just to read one: the formula is written out on the row.
• 3
  Remove calculation deletes the formula and returns the condition to the raw reading. Closing the editor with Cancel is not the same thing; that changes nothing.

How the alert editor differs

This is the same editor the dashboard widgets use. Widget Calculations documents it in full — the toolbar, the templates, the functions, and how the limits are counted — so read that page for the editor itself. Four things differ when you open it from an alert:

• Every variable comes from this condition’s device. There is no device picker, because an alert judges one device’s reading rather than a chart’s worth of data.
• The limits are much smaller: 5 variables, 25 building blocks, 8 levels of nesting and 4,096 characters, against a widget’s 20, 50, 12 and 32,768. An alert formula runs on every incoming reading rather than once when a chart is drawn. The counters show the alert’s limits, and the button that would add a sixth variable is greyed out.
• The preview is a single number, not a chart — the alert has no time range to draw, only the reading that just arrived.
• The result has no unit, since a formula’s output is no longer in the attribute’s unit.

The preview has three states, and they differ in whether you can save. An unfinished formula blocks Save; readings that have not arrived do not.

What changes on the condition

Only the six numeric operators are offered, because a formula’s result is a number. Compare to is marked calculated value (no unit) and the attribute’s unit disappears, as a reminder that your number is matched against the formula’s result. Both Use a value and Use a tag still work.

The sentence the alert writes about itself gains the word (calculated) — “Alert me when Boiler room temperature (calculated) is greater than 100” — so nobody goes looking for a reading of 100 the device never sent.

Rarely, a saved calculation cannot be read, which means this version of the app does not understand the stored formula. The row says so and offers Remove calculation but not Edit. Remove it and add the formula again.

A fired calculated condition records what the formula produced alongside what the device sent. See Alert History below.

Payload Push

Payload push sends a message of your own to another system when an alert fires. It appears in three places — the Set Alert dialog, a device’s Connectivity Monitoring card, and each anomaly sensor row — and the rules below are the same in all three. Only the alert tokens available to you differ, because they describe whatever fired.

Choosing a destination

There are two kinds of destination:

• An integration is a connection to an outside service. Use it to hand the event to software living outside NEQTO.ai.
• A device endpoint is the doorway your own equipment talks through, so pushing there sends a message back down to your devices. This is how an alert makes something happen in the physical world rather than only telling somebody about it.

The picker lists each destination with its kind and protocol, for example Endpoint — Test MQTT Broker (MQTT). Not everything you own appears: an integration has to be set up to send data out, and an endpoint has to be one the platform can push down. HTTP and HTTPS endpoints cannot receive a payload push at all. Manage integrations and Manage endpoints links open the pages where those are set up. A destination that stops being usable is not dropped — it stays in the list with — no longer available added to its name.

MQTT delivers to a named topic, the address the receiving side listens on. A Topic override (optional) field lets this alert publish somewhere other than the destination’s usual topic. It appears only where a topic exists to override — an integration speaking MQTTS, or an endpoint of type MQTT — so its absence elsewhere is not a fault. Topics may be 256 characters, and # and + are refused with “Topics must not contain # or + wildcards”: they mean “match anything” when listening, and nothing when sending.

The payload template

The template is the text of the message. Leave it blank and NEQTO.ai sends its own default description of the alert as JSON, which is enough for many receivers. Write one and you control the shape exactly, which matters because the system at the other end usually insists on a particular shape.

Each destination row shows the first two lines of its template. Click the pencil, or the preview itself, to open Edit payload template. A template may be up to 4,096 characters, and a counter beside the box keeps score.

Tokens

A token is a placeholder replaced with a real value when the alert fires. {{deviceName}} becomes the device’s name. There are three families:

Two buttons above the text box insert tokens for you: one searches your tags, the other your devices and then that device’s measurements. Use them rather than typing. A device name inside a token is escaped, so a space becomes %20 and Cold Room Sensor 1 has to be written Cold%20Room%20Sensor%201. Most real device names cannot be typed literally at all.

One alert may reference 25 device measurements. The count is of distinct measurements across every destination, so naming the same one in three templates costs one rather than three. A line above the destination rows keeps the running total: “Device attributes referenced across all targets: 3/25.”

The alert tokens on offer differ by alert type. A threshold alert knows the condition you wrote and the reading that tripped it. A connectivity alert knows the outage — which device, offline or back online, how long it was down, when it was last seen — and nothing about a threshold, because no reading is involved. An anomaly alert knows the sensor, the value that broke the rule and its unit, which detection layer caught it, and the mean and standard deviation at the time. So a template copied between alert types can name tokens that do not exist there, and saving will say so. The editor lists what it accepts beneath the template field; that list is the authority.

What blocks saving

A broken template does not reveal itself until the alert fires, so NEQTO.ai checks it first. What it finds is either a mistake, which blocks saving until you fix it, or a warning, which you accept by pressing Save again. A mistake is anything NEQTO.ai will not keep: invalid JSON, a token this alert type does not offer, a device the alert cannot see. A warning means the template is well formed but a value cannot be confirmed yet. That is legitimate: a device that has not reported is not a mistake. The exact messages are listed under Troubleshooting below.

Delivery outcomes

When the alert fires, each destination gets its own line in the event’s Payload push delivery block in Alert History — one line per row, even where two rows point at the same destination. The line names the kind and the destination’s identifier, gives one of three outcomes, and adds a reason where there is one.

Two size limits apply, and they measure different things. A template may be 4,096 characters as you type it. The finished message may be 64 KiB after every token has been replaced. A short template full of tokens that expand can pass the first and fail the second, which shows up as a failed line reading “Push payload exceeds the 64 KiB limit”.

Troubleshooting

These mistakes block saving until you fix them:

These warnings do not. Press Save again to accept them:

Notification Groups

A Notification Group is a reusable recipient list, so you do not re-pick the same people for every alert. Groups are scoped to an application: open an application and go to its Notification Groups page (alongside that application’s Alerts).

• 1
  Click Create Group, give it a Name and an optional Description.
• 2
  Add members: Add User for account users, or Add External for an email and/or phone number with per-member Email and SMS toggles.
• 3
  In any alert’s Notifications section, use Add Notification Group to attach the group. When the alert fires, everyone in the group is notified.

Connectivity Alerts

A connectivity alert tells you when a device stops sending data. You do not build these in the Alerts list: each device has its own Connectivity Monitoring tab, and NEQTO.ai creates the underlying alert automatically.

The card’s controls:

How “offline” is decided

A device counts as connected while data keeps arriving. If nothing is received within its Offline Timeout it is marked offline and the alert fires, and when it starts sending again a back online notification says how long it was down. NEQTO.ai re-checks for silent devices on a short, regular schedule, and a per-device cooldown limits how often one device can notify, so a flapping connection does not spam you.

Payload push on a connectivity alert

The same editor, so Payload Push above covers the rules. Destinations belong to the device, and what differs here is where Save lives. The card’s Save Changes button saves them along with the timeout and the two channel switches. So an incomplete destination row stops the timeout beside it being saved too. The whole card is also gated on the Connectivity alerts master switch: with it off, the editor is visible but greyed out. The alert tokens describe an outage rather than a reading.

Anomaly Detection

Anomaly detection flags a single reading that is abnormal, without you setting a fixed number. It learns each sensor’s normal range from its own history. Configure it per sensor on the device’s Anomaly Detection Settings tab — reached, like Connectivity Monitoring above, by opening the device from inside an application.

How it works

Detection has two layers:

• Absolute limits. Hard physical bounds per sensor type: temperature in Celsius is bounded at -40 to 85 °C (Fahrenheit -40 to 185 °F), humidity and battery at 0 to 100 %, and signal strength at -100 to -20 dBm. A reading outside these is always a critical anomaly. Unrecognized sensor types have no absolute limits.
• Statistical range. Once a sensor has collected enough readings to finish its warm-up, NEQTO.ai computes its mean and standard deviation and flags readings outside mean ± (sigma × standard deviation). A statistical anomaly is rated warning when the reading is more than 3 standard deviations from the mean, otherwise info.

What you configure

• Sigma Multiplier per sensor, from 1 to 5 in steps of 0.1, default 2. It is the width of the “normal” band, and 2 sigma is about a 95% confidence interval. A higher sigma means a wider band: fewer false alarms, but more chance of missing a real anomaly. Change it and click Save on that row.
• On / Off, Email and SMS per sensor. These appear only once the sensor has finished warm-up and its anomaly alert exists. Email and SMS are independent of each other and work only while the sensor’s alert is on; SMS also needs a phone number on your profile with SMS alerts enabled.
• Payload push per sensor — a button opening the same editor in a dialog. It sits alongside the On / Off, Email and SMS controls and needs the same two things they do.
• Notification interval per channel — Email every (min) and SMS every (min), each shown when that channel is on. They set how often a sensor re-notifies while it keeps reading anomalous, from 15 minutes to 7 days. Leave one blank for the default of 60 minutes; the value saves when you click away.

Setting names match the sensor’s attribute name exactly — the raw key, such as temperature_celsius — so they line up with what you see under Device Data.

Warm-up

Per-sensor statistics only appear after a device has been sending data for a while. Until then the row reads Warm-up in progress and the sensor cannot raise statistical anomalies. When warm-up finishes the row shows the sensor’s live mean, standard deviation and statistical range, and NEQTO.ai creates that sensor’s anomaly alert. The On / Off, Email, SMS and Payload push controls arrive with that alert; until it exists the row says so, though its wording mentions only the first two.

Payload push on an anomaly alert

Again the same editor, with Payload Push above covering the rules. Destinations belong to the sensor rather than the device. The button shows how many: a row reading Payload push (2) pushes to two places. Setting them on temperature does nothing to humidity. Save here is the dialog’s own and saves only the destinations, unlike the connectivity card. The button needs that sensor’s alert switched on, and a sensor’s alert arrives off, so a newly warmed-up sensor has to be turned on first. The alert tokens describe the sensor and the value that broke its rule.

Alert History

Every time an alert fires it creates an event. The Alert History page is where you review, triage, and clean up those events.

Event status

Each event carries a workflow status you can update as you handle it:

Status changes are recorded, so each event keeps a history of who moved it where.

Expand an event to see what each condition looked like when the alert fired. A condition that carried a calculation adds three lines. Formula is the formula it used. Calculated value is the number that formula produced. Raw value is the reading the device actually sent, kept because the first question about a surprising alert is always what the device reported.

On a calculated condition the Actual Value line above them holds the calculated number rather than the device’s reading, and neither is shown with a unit.

Two normal cases can look like missing data. An event recorded before calculations existed shows none of these three lines, exactly as it always did. And a condition the platform did not evaluate on that pass — routine when an alert covers several devices and only some of them reported — shows its formula with neither number beside it.

Filtering and cleanup

• Filter by Severity (All Severities, Info, Warning, Critical), by Status (All Statuses, New, In Progress, Completed, Pending, Dismissed), and by a Date Range picker.
• Use the select-all checkbox to pick events and Delete selected in bulk, or set a date range and Delete by date range. Both ask for a confirmation, and both need the alert-delete permission.

Where you are looking changes what a range delete covers. There are two Alert History screens: the account-wide one, and the one inside an application, reached from that application’s Alerts → Alert History in the sidebar. They look almost identical, and only one of them can be narrowed to a single alert.

That filter is not a dropdown — nothing on either screen lets you choose an alert. It arrives by following a link. On a dashboard, an Alert List widget shows one row per alert with its event count; clicking that count opens the application’s Alert History in a new tab, already narrowed to that alert. A small Alert: <name> chip appears above the filters, and clearing it widens the view — and the delete — back to every alert. The widget itself is covered on the Dashboards page.

The two confirmations are worded differently, and that wording is how you tell them apart:

• Not filtered to one alert — “Are you sure you want to delete all alert events from <start> to <end>? This action cannot be undone.”
• Filtered to one alert — “Are you sure you want to delete the events of “<alert>” from <start> to <end>? Other alerts are not affected. This action cannot be undone.”

Alerts shown across the app refresh on their own when the platform pushes an update, and immediately after you create or edit one, so lists and counts stay current without a manual reload.

Muting Your Own Alert Notifications

You can silence alert notifications to yourself across the whole platform. This is a personal preference on your own account, not a change to the rules other people see.

Open Settings and find the Alerts section. Turn on Disable all alerts to me to stop receiving alert notifications everywhere. While it is on, a Receive alerts from these applications list lets you tick the applications you still want to hear about.

Muting is per person, not per alert. The alert still fires, is still recorded in Alert History, and everyone else on the recipient list is notified as normal. To stop an alert firing for everyone, disable the alert itself or use its unlock settings.

Limits and Good to Know

Every number on this page, in one place.

What a push costs

A payload push to a device endpoint is an ordinary data push, so it spends your account’s Data Push allowance — the same budget and history as anything else you send to your devices. The limit is account-wide, not per endpoint, so alerts pushing to four endpoints draw on the same allowance as alerts pushing to one. If your plan carries no usable rate limit or retention, the platform substitutes 60 pushes per minute and 90 days of history rather than reading an unset value as “no pushes” or “expire immediately”. Integration destinations do not use this budget and do not appear in the endpoint Data Push history, so not finding one there is expected.

When a push is refused because the budget is spent, Alert History records that destination as failed, with the reason “usage limit exceeded” or “rate limit exceeded”. The Data Push allowance itself is covered on the Data Push page.