Signals in.
Signals out.

AlarmCommand is a signal broker that takes signals from mailboxes, alarm receivers, platforms and webhooks, normalises them, applies your routing and translation rules, and then delivers them onward to a destination in a chosen protocol.

  • 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
Signals arrive from IMAP, SMTP, a DC-09 receiver or a platform webhook, are parsed and normalised, translated, routed, then delivered to DC-09, Contact ID, REST or email destinations
SIA DC-09 Contact ID IMAP & SMTP REST webhooks Image handling
Overview

How it works

Most operations end up with a pile of one-off scripts: a mailbox parser here, a forwarder there, something that rewrites account numbers for one integration. 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.

Receives

Mailboxes, alarm receivers, backend platforms and webhooks, on the protocols panels and CMS platforms already speak.

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     alerts@site-gateway.example
subject  Site 214 - Camera 3 : Motion Detected

account     Site 214
zone_user   Camera 3 : Motion Detected
port        01
event_code  Motion Detected
area        BASE

parsed with  Camera Integration
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
NORMALISED
  account 1234   area BASE   port 01
  zone    1      event 130   media 1

DELIVERED
  DC-09 client    SIA-DCS frame     ACK
  Contact ID      ADM-CID frame     ACK
  REST webhook    JSON body         200
  Email           formatted text    sent

one signal · four destinations · four records
Media

Pictures that arrive with a signal

Images arrive with signals in several ways: attached to a camera-triggered email, referenced in a REST payload, or following an event from a receiver. However they arrive, 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 travels with the signal instead of stopping at the source.

Kept with the signal

Images are stored against the signal they arrived with, whatever source carried them, 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 from a source. 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.