Alarm deduplication should reduce repeated processing or notification without erasing distinct security events. The difficult cases occur after reconnects, retries and rapid state changes. Define event identity and state semantics first; a time window alone cannot tell a repeated message from a genuinely new occurrence.
Table of Contents
Is this a duplicate message or a new event?
A duplicate message is another delivery of information already handled. A new event represents a distinct occurrence or state transition. Two messages arriving close together can belong to either case.
A door-open event delivered twice should not automatically create two incidents. But open, close and open again may represent two separate occurrences even within a short interval. A rule that drops every similar message for one minute can hide the second opening.
Also separate correlation from deduplication. A camera observation and a door-contact transition may support the same incident while remaining different evidence. Grouping them in one operator view does not justify deleting one source record.
The security-platform integration checklist covers the wider interface contract. This article focuses on identity and repeated-delivery behavior inside that contract.
Define identity before choosing a suppression window
Ask each adapter what stable identity it receives from the source and what identity it creates. If an event ID exists, document its scope: device, channel, process lifetime, reboot or longer. Do not assume a number is globally unique because it is called an ID.
Where a source lacks an occurrence identifier, document the reconciliation rule and its limits. Device identity, topic, source channel, state, source time, sequence and connection generation may help, but no arbitrary tuple is guaranteed to distinguish every event.
Keep source-event time separate from receipt time. A late message can look new by arrival time while describing an old state. Conversely, clock corrections can make a new occurrence appear to have an earlier timestamp.
Specify the behavior when identity is uncertain. Preserve ambiguity or request state reconciliation rather than silently discarding potentially distinct evidence. The deduplication mechanism should explain which earlier record it matched.
Why does reconnecting produce old-looking alarms?
A state-oriented interface may report what is true now, not only what changed since the last message. A reconnect can therefore deliver a current condition that resembles a previous alarm.
The ONVIF Core Specification, version 26.06, distinguishes property operations including Initialized, Changed and Deleted. For property events, synchronization can produce Initialized notifications. Topic and source identify the property context, with optional key information extending identity.
An Initialized active state may require reconciliation or operator attention, but it is not necessarily evidence of a new transition at receipt time. Deleted indicates removal of the property in that lifecycle; it should not automatically be translated into “the physical condition is normal.”
Apply the exact semantics of the integration. Device and client behavior must match those semantics across normal operation, reconnects and replay.
A replay test matrix for the integration
The following is an editorial acceptance framework. Run it in an authorized test environment with expected results recorded before the exercise.
| Test sequence | Required distinction | Evidence to inspect |
|---|---|---|
| Same occurrence delivered twice | One occurrence, multiple receipts | Original identity, match reason and duplicate count |
| Open → close → open | New transition is not a retry | Ordered state history and separate occurrence records |
| Reconnect while condition remains active | Current-state reconciliation versus new activation | Subscription generation and initialization handling |
| Delayed old message after a newer state | Event order versus arrival order | Source time, sequence evidence and reconciliation decision |
| Device restart reuses an identifier | Old namespace versus new lifecycle | Restart/session context and collision handling |
| Two sensors report one incident | Correlation rather than deduplication | Both source records linked to the incident |
| Consumer restarts during delivery | Side effects are not unintentionally repeated | Persistent processing state and notification history |
Test acknowledgments and closure separately from source-state transitions. An operator acknowledging an incident does not necessarily clear the device condition. Likewise, a source becoming normal does not prove that every required follow-up action is complete.
When a suppression period is useful for notification management, record it as a presentation or escalation policy. Keep it distinct from the identity rule that decides whether data represents the same occurrence.
Keep the operator history explainable
A reviewer should be able to trace a visible incident to source messages, reconciliation decisions, correlated observations, notifications and operator actions. Preserve enough information to explain why a repeated message did not trigger another side effect.
Monitor both excessive repeats and unexpected silence. A broken adapter that drops new events can appear to have solved alert fatigue. Include replay behavior in security-system recovery tests and recheck it after adapter or firmware changes.
The identity contract and API mapping belong together in the integration specification. They let the receiving platform reduce redundant actions while preserving a complete incident history.
FAQs
How is deduplication different from event correlation?
Deduplication recognizes repeated representations of the same event or message. Correlation associates distinct observations with a broader incident. Correlated events should retain their individual identities and evidence rather than being discarded as duplicates.
Is an ONVIF Initialized notification always a new alarm?
No. For property events, Initialized can report the current property state during subscription or synchronization. The integration must interpret that state and its history instead of automatically treating every initialization as a fresh transition.
Should duplicate messages be deleted from the audit trail?
Not necessarily. The system can avoid repeated side effects while preserving receipt history, duplicate counts and links to the original event. Retention should follow the project's evidence and access requirements.
