Every alarm has three separate pipeline bindings: one for when it goes active, one for when it clears, and one for when it is acknowledged. To text a group on acknowledgement, point the alarm's Ack Pipeline at a pipeline that sends SMS, and uncheck the Acknowledge dropout condition in that pipeline's properties. If that box stays checked, the acknowledged event leaves the pipeline the moment it enters and nothing is sent. For state messages on non-alarm tags such as "Pump 1 is running", a tag value-change script can send email but not SMS, so configure an alarm on the run-status point and route it through a pipeline.
Symptom Signatures and Where to Read Them
SMS acknowledgement replies already working means the SMS gateway, the notification profile, and the roster phone numbers are good. A missing acknowledgement text is therefore a pipeline configuration problem, not a transport problem. The number that matters is how many pipeline blocks the ack event executes. If that count is zero, the event dropped out at the start block.
| Observed symptom | Cause | Where to read it |
|---|---|---|
| Active texts arrive, acknowledgement produces nothing, Ack Pipeline field is blank | No pipeline bound to the acknowledge transition | Alarm properties on the tag or UDT definition |
| Ack Pipeline is set but still no text |
Acknowledge dropout checked, so the event exits on entry |
Pipeline properties, dropout conditions |
| Ack text arrives only when the alarm is still active, and never after the alarm has cleared | Cleared dropout checked on the ack pipeline | Pipeline properties, dropout conditions |
| Ack text reaches one person, not the group | Wrong roster, or a notification block set to escalate or send sequentially | Notification block roster and settings |
| Tag value-change script runs but no text is sent | Scripted notification is limited to email | Tag event script; switch to an alarm on the point |
Alarm Event Transitions and Pipeline Dropout
An alarm event is a single object that moves through states: active, then acknowledged and/or cleared, in either order. Each transition is a separate trigger. If a pipeline is bound to that transition, the event enters at the start block and works through the blocks in sequence. The pipeline checks its dropout conditions continuously. As soon as the event's state matches a checked condition, the event is removed, even if it has not run a single block.
Pipelines built for active-alarm paging usually have the acknowledge dropout checked. That is correct for escalation, because paging should stop once someone owns the alarm. If you reuse the same pipeline for the acknowledge transition, the event arrives already acknowledged, the dropout is true on entry, and no notification block runs. The same logic applies to the cleared dropout. An operator often acknowledges an alarm after it has returned to normal, so the event enters the ack pipeline already cleared.
| Transition | Alarm property | Event state on entry | Dropout that suppresses it |
|---|---|---|---|
| Goes active | Active Pipeline | Active, unacknowledged | None on entry; Acknowledge and Cleared stop escalation later |
| Clears | Clear Pipeline | Cleared, acknowledged or unacknowledged | Cleared, and Acknowledge if already acknowledged |
| Acknowledged | Ack Pipeline | Acknowledged, active or cleared | Acknowledge always; Cleared if the alarm returned to normal first |
Ack Pipeline Build Procedure
- Create a dedicated pipeline for acknowledgement notices. Keep it separate from the active-alarm escalation pipeline so each one's dropout settings stay correct for its purpose.
- Open the pipeline properties and uncheck
Acknowledgeunder dropout conditions. Also uncheck Cleared, so acknowledgements made after the alarm has cleared still send. - Add a Notification block. Select the SMS notification profile already used for active alarms and assign the roster for the group that should be told.
- Write the message using the alarm's display path and event state so it reads like "Pump 1 Fail alarm has been acknowledged". Include the acknowledging user if the group needs to know who owns the alarm.
- Wire Start to Notification to End. Leave out delay and escalation blocks, because a confirmation is a single send.
- On each alarm, set the Ack Pipeline property to the new pipeline. Set it on the UDT definition's alarm so every instance inherits it, rather than editing instances one at a time.
- Save the project and confirm the gateway has loaded the pipeline before you test.
SMS on Non-Alarm State Changes
A tag event script responds to value changes but can only send email. To text a state change, add an alarm on the underlying point. For a run-status bit, configure an alarm that goes active when the value indicates running. Bind its Active Pipeline to a state-message pipeline, which gives "Pump 1 is running". Optionally bind the Clear Pipeline for "Pump 1 stopped". Set these alarms to auto-acknowledge so they do not accumulate as unacknowledged events.
The cost is that these alarms count toward the system's total alarm count and appear in alarm status displays. Give them a low priority and filter them out of operator alarm views by priority. If dashboards or KPIs depend on alarm totals, maintain your own alarm counters in a gateway event script that excludes the state-message alarms.
Verification Sequence
- Force the alarm active and confirm the active text arrives, as a baseline.
- Acknowledge by SMS reply while the alarm is still active. Confirm the ack text reaches every roster member.
- Force the alarm active, return it to normal, then acknowledge. Confirm the ack text still sends. This tests the Cleared dropout setting.
- Acknowledge from a client screen instead of by SMS. The acknowledge transition fires regardless of where the acknowledgement came from.
- Open the gateway's alarm pipeline status page. Watch events enter the ack pipeline and pass through the Notification block, rather than exiting at the start block.
- Toggle a run-status point and confirm one text per transition, not a burst.
Recurring Configuration Faults
- Reused escalation pipeline: binding the active-alarm pipeline to Ack Pipeline sends nothing, because its acknowledge dropout is correct for paging and fatal for confirmation.
- Cleared dropout left checked: ack texts work during testing, when alarms are held active, then fail in service, where most acknowledgements happen after the alarm has cleared.
- Chattering run-status alarms: every transition is a text. A contact that bounces floods the roster and runs up carrier cost. Add an on-delay or deadband to the alarm before routing it to SMS.
- UDT overrides: instances with an overridden Ack Pipeline do not pick up changes to the definition. Check overridden instances after editing the UDT.
- Acknowledger in the roster: the person who replied to acknowledge also receives the confirmation. Build a separate roster if that is unwanted.
- Shelved alarms: with the shelved dropout checked, shelved alarms send nothing on any transition. This is expected behaviour, but it looks like a failure during testing.
FAQ
What happens if the Ack Pipeline uses the same pipeline as the active alarm?
The acknowledged event enters, matches the pipeline's Acknowledge dropout condition straight away, and exits without running the Notification block. Build a separate pipeline with that dropout unchecked.
What happens if an alarm is acknowledged after it has already cleared?
The event enters the ack pipeline in the cleared state. If the Cleared dropout is checked, it drops out and no text is sent. Uncheck Cleared on the ack pipeline so late acknowledgements still notify the group.
Can a tag value change script send an SMS in Ignition?
No. A tag event script can respond to the value change and send email, but it cannot send a text. Put an alarm on the point and route it through an SMS pipeline instead.
What happens if the ack pipeline still sends nothing after the dropout boxes are cleared?
Check the gateway's pipeline status page to see whether events reach the Notification block, and repeat the clear-then-acknowledge test. If events pass through the block but no SMS arrives, while active-alarm texts on the same profile still work, collect the gateway logs and pipeline configuration and open a case with Inductive Automation support.