If your remote monitoring system operators are drowning in noise, they're not solving problems. Nuisance alarms bury the real incidents, inflate mean-time-to-respond (MTTR), and burn O&M budgets with needless truck rollouts. When an alarm screen reads like some kind of confusing slot machine, your best people start to ignore it - because they have to in order to actually accomplish something.

That's why, at DPS Factory Training, I teach teams to attack nuisance alarms from two sides at once:

1. Show only what matters, to the right people, right now (grouping + filtering).
2. Don't post the alarm unless the fault actually persists (qualification timers - and sometimes counters).

Do this well and you keep eyes on the true threats, slash false positives, and make every alarm actionable.

The problem you're really solving (the "why")

• Attention is your scarcest resource. Every flicker, flutter, or door jiggle consumes operator cycles that should go to service-affecting events.
• False positives drive false dispatches. "Windshield time" is expensive and risky during storms and after-hours.
• Unclear alarms create hesitation. Operators pause when they don't know what to do next, driving up MTTA/MTTR and delaying restores.

I often summarize the first move this way during training classes: "The real answer is: click Standing Alarms until you see what's still standing - that's why we built the Standing screen." T/Mon is designed for this: COS (what just changed) vs. Standing (what's still broken) are complementary views that help you figure out the actual problem and resolve it quickly.

You can't keep ignoring this problem

Sure, you know this deep down, but here are a few specific issues to help inspire you to take care of this:

• "Just ignore it." That's not a strategy. It trains your team to miss the one alarm that mattered.
• Permanent silencing of a "noisy" alarm point. If you turn any alarm off completely, you lose forensics. You may (depending on your system config) also lose the chance to spot trends later.
• Overly broad filters. Filters are powerful, but if you hide too much, you'll miss something during real incidents.

As I told my class: "Filtering is a great idea in one form or another to see just the alarms that are important."

The good news is that T/Mon supports nuisance filtering without losing your audit trail. You can keep alarms out of operator screens and still record them for later analysis (compliance and trend work).

What your "good monitoring system" looks like

• Role-based windows. Power folks see power alarms. Security sees security. Dispatch sees only what they need.
• Standing vs. COS discipline. Start in Standing to burn down active faults, pivot to COS when needed.
• Every alarm includes "what to do next." T/Mon's text message window puts response instructions right on the alarm.

As I showed live in T/Mon's web interface: "Response instructions are associated with the alarm point. Create the message once and assign it wherever it's needed."

Here's your two-part solution for nuisance alarms

1) Grouping + Filtering: cut the noise (without losing data)

How we do it in T/Mon:

• Group by severity, site, and function
  • Critical/Major/Minor/Status
  • "Wolf Creek", "Tower Site #392", "Main CO" (this will vary based on your site naming system)
  • Fire/Security/Power/etc.
• Use Standing Alarms screen to see what's still broken, COS Alarms screen to see what just changed.
• Apply targeted filters so each operator sees a short list they can actually manage.

During the session, I walked through live filtering when the view started to clutter: "We're getting a cluttered window... let's set a filter... so you can see just the alarms that are important."

And because we keep alarm history in T/Mon even when we filter, you retain forensics and can mine patterns later.

Why this beats "silence everything": You preserve your data for audits and trend analysis, but you stop wasting operator attention in real time. That combination is a strong ROI lever for you.

2) Qualification Timers (and when to use Counters): eliminate "flutter"

Qualification Timers suppress the setting of an alarm unless the condition stays bad for X time (seconds/minutes/hours). This is the perfect tool for rattling doors, brief fades, or momentary AC blips.

I framed it to the class like this:
"If a door is open during business hours, I don't care. But if it's open for more than 30 seconds, we need to respond."

One client (high-security at a nuclear power plant) even saw the effect operationally when holding the door open during a brief conversation with a coworker:
"...about 31 seconds later, an armed security guard shows up to see what's going on."

Field-proven recipes from training:

• Door rattle debounce: "Train going by... the door sensor trips... about four times a day. By putting in a qualification timer - this alarm has to exist for at least this long - or we don't care. For this, ~2 seconds is fine for a Qualification Timer."
• Prop/open door threshold: 30 seconds before posting.
• Runaway heater (block heater) runtime: Alert if it runs > 1 hour straight.

A word of caution I shared in class:
"Be careful setting qualification timers. They can hide information if you go too aggressive. You want them long enough to stop the noise - but not so long that you miss something important."

Persistent Alarm Counters (less common) require N occurrences within a period before posting.

Colin (from DPS Engineering & Support) put it simply: "We don't have a lot of people who use them, but they're useful in the right situation. It's basically how many times it has to occur before it's counted as an alarm."

I explained to the class the scenario that led us to develop Persistent Alarm Counters in the first place: a client wanted to count lightning strikes so a maintenance visit could be scheduled after a few strikes had occurred.

Step-by-step implementation plan

Step 1 - Map your noise.

Export last 30 days of COS and Standing Alarms. Identify top recurring offenders (door rattles, short-lived link flaps, momentary fades). Tag each as a filter candidate or a persistence (Qual Timer) candidate. (T/Mon's COS/Standing model is built for this.)

Step 2 - Build role-based windows + filters.

Create groups by site/region/function and apply filters so each operator sees only their responsibility slice. Keep history logging on filtered alarms for trend analysis and audits.

Step 3 - Add qualification timers (and counters where it helps).

Use the recipes above as a starting point. Adjust after one week of live data. (T/Mon natively supports Qualification Times; it's a standard nuisance-alarm control.)

Step 4 - Attach response instructions.

Write clear, reusable instructions ("what to check, who to call") and assign them to the relevant points. "Create the message once and assign it wherever it's needed."
T/Mon's Text Message window was built for this exact function.

How you can measure the ROI from eliminating your distracting nuisance alarms

Track before/after for:

• COS volume per shift (should drop as nuisance is filtered/qualified).
• Time-to-first-action (operators act faster on a shorter, clearer list).
• False-positive rate (percentage of auto-clearing alarms).
• Truck rolls avoided (convert to $ and fractional-event risk avoided).

Also track secondary benefits:

• Operator focus and morale (qualitative, but real when it comes to staff churn - you can just talk to your team or conduct a formal survey).
• Audit readiness (you filtered noise from displays but kept history).

Common pitfalls (and how to avoid them)

• Over-silencing: Don't delete visibility. Filter displays and qualify persistence, but keep history.
• Too-tight timers: If you miss valid events, shorten the Qual Time incrementally.
• Ignoring Standing/COS discipline: Start with Standing (what's truly broken), then COS (what changed). That's the intended workflow.

Pro tip from Colin (DPS Engineering & Support): If you've just edited groups/filters and don't see updates in Monitor immediately, a quick disable --> re-enable of the Polling Group forces a refresh. "You don't have to do this - it would catch up anyway - but this speeds it along when you're modifying your T/Mon configuration."

Why DPS (and T/Mon) can help you suppress nuisance alarms

• Built-in nuisance controls: Qualification times, display filtering, COS/Standing views, plus integrated response instructions.
• Keep the data, cut the noise: Filter out distractions while preserving logs for compliance and trend analysis.
• Simple operator UX: Plain-English displays and role-based windows mean faster, surer action.

I've said it before in class and I'll say it here for you now: "Just click Standing to see what's still broken - then filter and fix it. Repeat until all alarms are resolved."

Your next step

Get your free Nuisance Alarm Audit

Give me a call now. I'll work with your team to:

• Identify your top 10 "chatter points" from the past 30 days.
• Recommend specific filters and qualification timers (with proposed thresholds).
• Draft response-instruction text blocks you can assign by alarm class.
• Provide a one-page before/after dashboard report you can show to stakeholders for T/Mon budget justification.

If alarm noise is slowing your crews, let's fix it. We'll map your nuisance points to T/Mon filters and qualification timers, attach clear instructions, and measure the results.

Call 1‑800‑693‑0351 or email sales@dpstele.com to schedule your audit.