The language underneath every alarm

When an alarm panel reports a break-in, it rarely sends a sentence. It sends a short coded message, and almost every panel on the market speaks one of two families of codes: Contact ID (formally SIA DC-05) or SIA's own event codes. Over IP, those messages are usually carried inside SIA DC-09.

Operators seldom see the raw codes, but everything they see depends on them being read correctly. At CleverCam we receive signals from many panel brands and communicators, including IDS HYYP, Olarm, Onyyx, Ajax and FSK and RDC receivers, and we convert every one of them into a single event format. Here is how the protocols work, and what we have learned doing it.

Anatomy of a Contact ID event

A Contact ID event carries four things that matter:

• Account: which panel sent it.
• Qualifier: whether this is a new event or a restore. We write it as E (new event, or an opening) or R (restore, or a closing).
• Event code: three digits that say what happened.
• Partition and zone: where it happened. For open and close events the zone field holds the user number instead.

So E130 01 005 reads as new burglary alarm, partition 1, zone 5, and R130 01 005 is the matching restore when that zone returns to normal.

The event codes are grouped by their first digit:

What SIA DC-09 adds

SIA DC-09 is the standard for carrying alarm messages over IP networks. It wraps each message in a frame with a checksum, a length, a sequence number and the account. It can optionally encrypt the content, typically with a key per account. It can also carry extra blocks of information, such as a zone name, a partition label or links to verification pictures. The receiver acknowledges each message so the panel knows it arrived.

DC-09 can carry Contact ID codes or SIA's two-letter codes (BA for burglary alarm, BR for burglary restore, OP and CL for opening and closing). Converting between the two is straightforward. What follows is where it gets less straightforward.

Nine lessons from normalising many panel brands

1. Do not trust the textbook on open and close

By the standard table, the direction of the 400-series codes is clear. In the field it is not. We have seen panel families where arming away arrives as a restore of 401 and disarming arrives as a new 401, which is the reverse of what many receivers assume. Get it wrong and a customer's house shows as disarmed while it is armed. The only safe approach is to test each panel family against commands with known outcomes, and write down what it actually sends.

2. Sub-codes are there for a reason

It is tempting to fold related codes into a parent: treat anything in the 14x range as "general alarm", or anything in the 13x range as "burglary". But 146 is a silent burglary, which should never be presented to an operator as an ordinary audible one. 147 is a sensor supervision failure, a maintenance fault, not an intrusion. 162 is carbon monoxide. The 141 to 145 codes are mostly wiring and module faults. Folding them together puts faults in front of operators as red intrusion alarms and hides the alarms that matter most. Keep every code distinct all the way to the screen.

3. The same code can come from two different places

A "communication failure" code sent by a cloud communicator about itself is not the same event as the same code sent by the panel about its own dialler. They look identical until you check the zone, the partition and the source. Store them as different events, or operators will chase the wrong fault.

4. Zone zero is the panel

Partition 0 or zone 0 does not mean "the first zone". It means the panel itself. Showing it as "Zone 0" on an operator screen invites confusion.

5. Account numbers are not globally unique

Account 0001 exists at many control rooms. Two receivers can easily deliver the same account number for two completely different sites. Account lookups must be scoped to the receiver or protocol that delivered the signal. Never match on the number alone.

6. A receiver can acknowledge a signal and still lose it

A receiver that acknowledges a message has told the panel "got it". If the message is then rejected because a field was in an unexpected format, or because the encryption key is wrong, the panel will not resend, and the alarm is silently lost. Monitor your parse and decryption errors, not just whether the connection is up.

7. Replayed signals carry old news

When a communicator reconnects after an outage, it often delivers a backlog of old signals. If those are applied blindly to the current state, an armed site can suddenly show as disarmed because of a disarm that happened hours ago. Apply state changes forwards in time only, based on when each event happened, not when it arrived.

8. Check the clock settings

Panels and communicators that report in UTC while the receiver assumes local time will shift every event by two hours in South Africa. It sounds trivial until an operator is reconstructing an incident timeline for a police case.

9. Capture unknown codes, never guess

Sooner or later a panel sends a code your receiver does not know. The right response is to record it, flag it and add a proper definition, not to map it to the nearest familiar code. A guess that turns an unknown fault into an intrusion (or the reverse) is worse than an honest "unknown".

Why this matters for cameras

Once every signal speaks one language, camera events and panel events can sit on the same timeline. A burglary signal from the panel and a photo of a person at the boundary from the camera reach the control room together, instead of as two unrelated alarms on two different screens. That is when visual verification starts to pay for itself, and it only works if the unglamorous protocol layer underneath is right.

If you run a control room and want to know how your receivers and communicators would connect, talk to us.