Receives
Mailboxes, alarm receivers, backend platforms and webhooks, on the protocols panels and CMS platforms already speak.
Signals in.
Signals out.
Your rules in between.
AlarmCommand is a signal broker for central monitoring stations. It takes signals from mailboxes, alarm receivers, platforms and webhooks, normalises them into one shape, applies your routing and translation rules, and delivers them onward in whatever protocol the destination speaks.
- One signal can reach several destinations, each tracked separately
- SIA DC-09 and Contact ID, in both directions
- Scripted test traffic built in, not a separate tool
SIA DC-09
Contact ID
IMAP & SMTP
REST webhooks
Image handling
Scenario testing
Overview
What it does
Most monitoring centres end up with a pile of one-off scripts: a mailbox parser here, a forwarder there, a script that rewrites account numbers for one customer. Each was written once, by someone who has since left, and none of them tell you what happened to a signal.
AlarmCommand replaces that with one pipeline you can inspect. Every signal keeps what arrived, what it was understood as, what it was translated to, and what each destination did with it.
Normalises
Whatever arrives becomes one envelope: account, area, zone or user, event code, timestamp, media.
Routes
Match rules decide where a signal goes. One signal can fan out to several destinations at once.
Delivers
Each destination gets its own delivery record, retried on its own, with the outcome kept.
Records
Received, understood as, translated, sent. Four stages you can read back for any signal.
Simulates
Scripted traffic runs through the same pipeline, so a test proves the real path works.
Sources
Where signals arrive from
A source is a way in. Each one is a transport plus a format: an IMAP mailbox that is polled, an SMTP address that receives directly, a TCP port listening for DC-09, or a platform pushing over HTTP.
Format templates do the extraction. A template says where the account, area, zone or user, port and event code sit in that particular upstream's messages, so a new provider is a template rather than code.
- IMAP polling and inbound SMTP for alarm mail
- DC-09 receiver on a dedicated port per instance
- Platform and webhook sources over HTTP
- Deduplication, blocklists and backpressure before anything is routed
- Unparsed messages are kept, not dropped, so a bad template is visible
Received
from Jesse Love <jesse@example.com> subject 1-98 Valley Road - Cam 1 : Intrusion Zone account 1-98 Valley Road zone_user Cam 1 : Intrusion Zone port 01 event_code Intrusion Zone area BASE parsed with Camera Integration Test
Rules
Translation and routing
Translations turn what the upstream said into what the destination expects. A site name becomes an account number, a camera name becomes a zone, a text description becomes an event code. Each translation records which rule fired, so an unexpected value is traceable rather than mysterious.
Routes decide where the signal goes. A route matches on the signal after normalisation and can fan out to several destinations, each of which gets its own delivery. Adding a second recipient does not disturb the first.
- Literal, pattern and default mappings per field
- The rule that produced each value is recorded
- One signal, many destinations, independent outcomes
- Unmatched values surface as unresolved instead of guessing
Translated
account 1-98 Valley Road -> 1234 literal, rule 1 zone_user Cam 1 : Intrusion -> 1 literal, rule 3 event_code Intrusion Zone -> 130 literal, rule 2 routed to Staging · attempt 1 · HTTP 200
Destinations
Where they go
A destination is a codec plus a transport. The same DC-09 implementation drives the outbound client and the inbound receiver, so a framing problem shows up in tests rather than in one direction only.
Every delivery is its own record: which destination, which attempt, what came back. Retries do not overwrite history, and a destination that is down does not hold up the others.
- SIA DC-09 client, SIA-DCS and ADM-CID formats
- Contact ID
- REST and webhook endpoints
- Email via SMTP
- Per-destination retry, with every attempt kept
Sent
POST /api/v3/signals/logFormattedSignal
{
"clientNo" : "1234BASE01",
"typeNo" : 130,
"zoneUser" : 1,
"moduleNo" : 0
}
delivery 1 of 2 · accepted
delivery 2 of 2 · DC-09 · ACK
Media
Pictures that arrive with a signal
Camera-triggered alarm mail carries snapshots. AlarmCommand stores them against the signal and, where the destination supports it, raises each one as its own picture event of a configured type, so the image reaches the operator rather than sitting in a mailbox.
Kept with the signal
Attachments are stored against the signal they arrived with, and shown alongside it.
Raised as events
Each picture can become its own event of a configured type, delivered through the same routes.
Boilerplate suppressed
Logos, signature graphics and tracking pixels repeat on every message. Repeats are identified and left out so they do not bury the real images.
Nothing dropped silently
When a file is not kept, the reason is recorded on the signal. "Why is there no picture" has an answer.
Held when unassigned
If a signal has no account to log against, the files are still stored rather than discarded.
Size aware
Large attachments are handled without stalling the signal they belong to.
Protocols
Conformance, not approximation
The DC-09 implementation is checked against the worked examples published in ANSI/SIA DC-09-2013, including the encrypted vector, rather than against whatever a particular receiver happened to accept.
Published test vectors
SIA-DCS with and without timestamp, ADM-CID, open and close, MAC extended data, and the encrypted example.
Encryption
DC-09 encryption per the specification, with keys held encrypted at rest.
Correct receiver behaviour
ACK only after the signal is committed, retransmissions acknowledged without duplicating, NAK carrying our time when a timestamp is out of window.
The event parameter
A parameter is a zone, a user or an area depending on the event. It is decoded as what it actually is, not assumed to be a zone.
Scenarios
Scripted traffic runs through the real pipeline, so commissioning a new customer is a rehearsal rather than a hope.
Isolated per customer
Each customer runs their own instance and database. One customer's load or misconfiguration cannot reach another's.
Contact
Tell us what you are wiring together
Which upstreams you receive from, which platforms you deliver to, and what the scripts in between are doing today. That is usually enough to say whether this fits.