How to Troubleshoot Alarms Not Triggering or Delivering

The Alarm Delivery Path

A complete alarm path consists of:

1. Data source (SCADA tag, OPC item, iFIX alarm event)
2. Gateway (collects data from source)
3. FPAM Server (evaluates conditions, applies rules)
4. Notification rule (routes alarm to endpoint)
5. Endpoint (receives and displays notification)

If alarms fail at any point, the entire flow breaks. Start by identifying where the failure occurs.

Step 1: Verify the Data Source

Does the underlying data change?

For Data-type gateways (OPC DA, FactoryTalk RSLinx-class), open the SeQent gateway admin on the gateway machine and browse the configured data items, confirming the item is reachable from the source. For A&E-type gateways (FactoryTalk View SE A&E, iFIX AlarmCast, CIMPLICITY), browse is not exposed at the gateway. Confirm in FPAMS that the configured tag or event still exists on the source.

For OPC: open the GW Server log on the FPAMGWOPC machine and confirm the tag update is recorded there. The Server log is the authoritative view of OPC tag activity; there is no real-time “gateway view” panel.

For FactoryTalk: Check the FactoryTalk historian. Verify alarms are actually being generated by your SCADA logic.

For iFIX: the iFIX alarm queue is not directly viewable through the SeQent gateway. Verify the missing alarm against the iFIX Alarm Summary in iFIX itself.

Common issues:

• Data source offline or disconnected from gateway
• Network firewall blocking SCADA server communication
• DCOM permissions (OPC DA) not allowing gateway access
• Wrong tag/alarm name configured in SeQent

Step 2: Verify the Gateway Connection

On the gateway machine, open the gateway admin application (FPAMGWOPC Administrator, FPAMGWFTSEAE Administrator, etc.) and read the live status from the status bar. The Windows Service for the gateway must also be Running. There is no centralized “Web Admin > Gateways” page.

If the gateway shows Disconnected:

• Check network connectivity between SeQent server and SCADA server
• Verify firewall rules allow communication on required ports
• Confirm SCADA server is running and accessible
• Check gateway logs for specific error messages

Verify the FPAMS to Gateway connection (most common root cause):

• Data-type: in the FPAM agent, open the Connection tab and verify the Gateway Settings (host and port) match the FPAMGWyy machine.
• A&E-type: open the FPAM agent, verify the Connection tab settings, then on the Details tab confirm the Source Host matches the gateway.

View gateway logs:

On the gateway machine, open the gateway admin and choose View > View Logs > Server Log (for source-side activity) or Admin Log (for config changes). The Windows Event Viewer is not where SeQent writes its gateway logs.

Step 3: Verify the Alarm Condition

In FPAM Administrator, open your alarm configuration.

Confirm the rule exists and is enabled (not disabled or archived).

Review the condition logic:

• If using tag comparison: “Tag > 100” – verify the tag name matches exactly what is published on the source side. The gateway only relays what the source exposes.
• If using state change: “Tag changes to 1” – confirm the logic is correct
• If using range: “Temperature between 50-80” – verify the range boundaries

Test the condition manually (if safe):

• Force the SCADA tag to the value that should trigger the alarm
• Within 5-10 seconds, the alarm should appear in the SeQent alarm log
• If it doesn’t appear, the condition or gateway connection has failed

Step 4: Verify the Notification Endpoint

Once an alarm triggers in SeQent, it must route to an endpoint (email, SMS, radio, etc.).

Navigate to FirstPAGE Admin > Devices > Providers > Destination. Endpoints are configured per Provider; the correct path is the FirstPAGE Administrator, not a web admin UI.

For Email:

• Verify SMTP server, port, and credentials on the SMTP provider’s Connection tab in FirstPAGE Admin
• Use the Test Message option (toolbar green-arrow icon) to send a test from the provider
• Confirm the test email arrives in your inbox
• Check spam and junk folders

For SMS:

• SMS delivery is configured on the ATMS provider, not a generic SMS gateway. Verify modem credentials on the ATMS provider’s Connection tab
• In FirstPAGE Admin, select the destination and use the Test Message option on the toolbar (green-arrow icon) to send a test SMS
• Confirm delivery on the recipient device

For Motorola Radios:

• For MOTOTRBO, the link service is FPLNKTDIRECT (FirstPAGE Link for TRBODirect), not a generic “radio gateway”
• Verify SUID and Talk Group IDs are configured in FPLNKTDIRECT
• Right-click DDMS/Donor connection in the status bar to view DDMS/Donor Status; both must show Connected
• For WAVE PTX, the link service is FPLNKWAVEPTX

For WFMC (Wi-Fi Messenger Client):

• Verify the user is logged into the WFMC mobile app or desktop client
• Confirm the device has connectivity to the SignalSwift server (Wi-Fi or external network)
• For push delivery, the device must have internet connectivity at the moment of notification

Step 5: Verify the Notification Rule Routing

In FPAM Administrator, open the Escalation Schemes and notification routes.

Confirm:

1. The rule is enabled (not disabled)
2. The alarm condition matches your triggered alarm (correct rule is selected for your alarm)
3. The endpoint is assigned (email, SMS, radio selected and valid)
4. Escalation is configured correctly (if escalation is enabled, verify timing and escalation targets)

Create a test rule if you’re unsure:

• Create a simple test alarm condition
• Create a simple test notification rule
• Assign the test endpoint
• Trigger the test condition and observe if notification arrives

If the test works, the issue is in your production rule configuration. Review the rule logic.

1. Isolating Data Source vs. Rule vs. Endpoint Issues

After following the above steps, you should have narrowed down the issue:

Data source problem: Condition never fires, data not flowing through gateway → Fix gateway connectivity or data source configuration.

Rule configuration problem: Condition fires in test but not in production → Review rule logic, condition syntax, and alarm matching.

Endpoint problem: Alarm triggers, but notification doesn’t arrive → Test endpoint independently; verify credentials and configuration.

Common Pitfalls

Case sensitivity in tag names – OPC and many SCADA systems are case-sensitive. “Temperature” ≠ “temperature”.

Whitespace in tag names – Leading or trailing spaces break matching. Verify tag names exactly.

Network firewall – Outbound access to SMTP, SMS gateways, or Motorola infrastructure may be blocked. Check firewall rules.

Endpoint service down – Email server, SMS gateway, or radio infrastructure may be temporarily unavailable. Verify external service status.

Escalation suppressing notifications – If escalation is configured and the first recipient is marked “required to acknowledge”, alarms may not be retried if acknowledgment fails.

Next Steps

If you’ve verified all components and alarms still don’t deliver, contact SeQent Support with:

• Gateway connection status
• Alarm rule configuration
• Endpoint test results
• Relevant logs from the gateway admin application or Windows Event Viewer