Alarms worth hearing: ranges, thresholds and notices that do not tire
How to combine a range and a threshold so the screen warns first and the phone rings only on an overrange, why nobody is notified of their own action, and what to do about agents and connections that flicker.
An alarm that rings all day stops being an alarm. The manual says it plainly: too many alarms are worse than none, because the team grows numb and lets the important ones through. If everything is critical, nothing is.
This note is about the real time of an operation: what is measured, what fires, what is recorded and, above all, what reaches whose phone. It comes down to four decisions: which values the alarms sit on, which ones are seen and which ones ring, who receives what, and how long to wait before telling anyone.
Event, alarm and notification are not the same thing
Three things are usually treated as one, and it helps to pull them apart.
- An event is something that happened and was recorded: a device connected, someone set an output to manual, an automation was applied, a task was completed. All of it goes to Activity, a single chronological list of what it was, when, and who did it.
- An alarm watches a variable against a value. When the condition holds it fires, it is recorded, and it waits for someone to acknowledge it. Acknowledging leaves a record that someone read it; it does not fix the cause.
- A notification is the notice that leaves the platform towards a person, by e-mail, Telegram or push. Each user picks their channels and the events they want to hear about.
The usual mistake is to create an alarm and assume it has to ring. It does not. An alarm can exist only to be seen, and that distinction is what makes a notice system that does not wear people down.
The right values
An analog alarm comes in three types: above a threshold, below a threshold, or out of a range. For digital variables it is defined by the expected state: if the output should be On and shows Off, the alarm fires, or the other way round.
An alarm value is not the working value. An alarm set on the setpoint fires with every normal swing of the control, several times an hour, and within a week nobody looks at it. The right value comes from the history: the dynamics of the variable over a good week show how far it goes on its own, and the alarm sits outside that. Configured alarms are drawn on the variable’s charts at their trigger value, so a look at the curve tells how many times it would have crossed.
The manual adds two criteria: thresholds per environment rather than global ones, and few, well chosen alarms. And one diagnostic sign: acknowledging the same alarm again and again means the threshold is badly calibrated or the problem is structural.
Range plus threshold: the overrange
A single value forces a choice between hearing too late and hearing too much. The way out is two alarms on the same variable, one of each type, sent to different places.
- 01Range
Outside 22 – 27 °C. This is the band the variable should live in. Leaving it is a deviation: worth seeing, not worth waking anyone.
- 02Threshold
Above 30 °C, beyond the range. That is an overrange: the control is no longer enough and someone has to act.
- 03Notifications
In My account > Notifications, under Alarms, "out of range" is unchecked and the thresholds stay checked. The range still exists; it just stops ringing.
The result is two levels. Leaving the range is a visual alert: it shows in the panel’s alarms widget, on the indicator’s curve, in Activity and on the menu badge. The overrange is what makes the phone ring. And because it rings rarely, when it rings it gets answered.
When both ends are critical the scheme is the same with two thresholds: one above and one below, both outside the range.
The filter belongs to each user, not to the organization. Someone on the floor may want ranges on the phone as well; someone overseeing several plants, only overranges. The alarm is the same and each person decides how much to hear. With every channel off nothing arrives, but alarms keep being recorded in Activity.
Nobody is notified of what they did
Self-notifications are off by design. When someone sets an output to manual and turns it on, the rest of the team subscribed to that event gets the notice. That person does not: they just did it, they know, and a phone that rings for one’s own actions teaches its owner to ignore it.
The rule covers events that have an author: commanding an output, applying an automation, creating, editing or deleting an alarm, adding a device. Alarms and connection events have no author, so they reach everyone who has them checked.
| What happened | Who did it | Who is notified |
|---|---|---|
| An output went to manual, On | A person on the team | The rest of the team |
| An automation was applied | An assistant on that person’s account | The rest of the team; not that person |
| An automation was applied | An assistant on its own account | The whole team |
| An alarm fired | Nobody: it has no author | Everyone with that type checked |
| A device disconnected | Nobody: it has no author | Everyone, after each one’s delay |
Agents, on their own account
The second and third rows of the table are the reason for this section. Growcast exposes an MCP server, so an AI assistant can read what the app shows and also act: create tasks, create alarms, command outputs, apply automations. If that assistant connects with a person’s account, to the platform it is that person. Whatever it does on its own does not notify its owner, because nobody is notified of their own actions, and Activity cannot tell the two apart.
The manual recommends the opposite: give the assistant its own Growcast account and invite it to the organization. From then on everything it does is under that account’s name, in Activity, in tasks and in every record. And since it is another user, the whole team is notified when it acts, including whoever set it up. An agent that works alone has to be heard.
Its own account also settles permissions. The assistant works with its account’s role: if that account cannot create a lot, neither can the assistant, and it is best invited with the minimum role it needs. It deletes nothing and manages no users, and hardware actions are flagged so it asks for confirmation before running them. If something goes wrong, removing that account’s access is enough.
Connections that flicker
An unstable internet link makes the worst noise of all: disconnected, connected, disconnected, connected. Each flicker lasts seconds and affects nothing, because rules run on the device and keep working without internet, and yet each one can be a notice on the phone.
That is what the disconnection delay is for: in the connection notifications, each user sets how many minutes to wait before being told, from zero to fifteen. When the time is up the platform looks at the state again: if the device is back, nothing is sent. It only reports a disconnection that is still a disconnection.
The delay is chosen by how long the operation can go unseen, not by how annoying the notice is. Meanwhile the live state is not lost: the hardware status widget shows on its own when a device or a module disconnects.
Alarms, always in sight
All of the above takes noise off the phone and puts it on the screen. For that to work the screen has to show it: every panel, whatever question it answers, keeps the alarms in sight.
- The active alarms widget, filtered to the panel’s environment, with its acknowledge button. Its normal state is an empty card, which is why a card with text can be read from across the room.
- Hardware status next to it. If a module is down none of the numbers on the panel hold, and that has to be seen before the numbers.
- Analog indicators with the alarm line drawn on the curve. It shows how close the variable is to the trigger value before it triggers.
- The Activity badge in the menu, which adds up unacknowledged alarms and events, orders in progress and pending tasks. When it reaches zero, nothing is waiting.
Live values reach the browser over MQTT, with no polling: an indicator changes when the variable changes and an alarm shows on the panel when it fires. The visual alert is not a second-class notice: it is the first to arrive.
Closing
- Values taken from the history, outside the normal swing, per environment.
- Range to see, threshold to ring: the range stays out of notifications and the overrange reaches the phone.
- Nobody is notified of their own action; that is why each agent works on its own account, with the minimum role.
- A disconnection delay that fits the link, so a flicker is not news.
- Alarms and hardware status visible on every panel.
The screen warns first. The phone rings only when it has to, and that is why it gets answered.
Drawn from the Growcast platform user manual. Values in the figures are illustrative.