Panels & integration
Panels to people, end to end
AlarmPulse reads fire alarm panels of any make and age through the interface they already have, carries their events safely to the Command Centre, and shares live state with your building systems.
The AlarmPulse network
From the panel to anywhere
1 · Fire alarm panels
- Any make, any ageAddressable or conventional
- Loop protocolSerial, two-way
- Printer / event portSerial or IP
- Modbus TCPPanel or gateway
- Relay contactsCommon fire, common fault
2 · Connection
- LocalSerial or LAN on the site network
- PanelTunnelDials out over SSH; nothing at the site listens
● ENCRYPTED - Site agentStore and forward over HTTPS or MQTT+TLS
● ENCRYPTED - VPNPanel on its private address
AlarmPulse Command Centre
- Fire alarms handled first
- Loop failures grouped as one incident
- Outages logged, resync tagged
- Maps, buildings, floor plans
- What to do, escalation, shifts
- Roles, two-step sign-in, sealed audit log
- Windows PC · Linux server · your cloud
3 · Anywhere
- Control roomAny browser, or installed as an app
● HTTPS - On-call staffEmail · Telegram · webhook / SMS gateway
- Building managementModbus TCP · BACnet/IP
- Data platformsMQTT · REST API v1 · Excel
Supported fire alarm panels
Any make · five interfaces
Each interface is checked against real panels or recorded panel output. Ask for the current list of panel models verified on site; a new event format is added as a driver without changing the rest of AlarmPulse.
| Interface | How it connects | What AlarmPulse receives |
|---|---|---|
| Addressable loop protocol | RS-232 / USB-serial at the panel | Two-way: every device's state and analogue value; panel commands where licensed |
| Printer / event port | Serial, or IP through a serial-to-Ethernet converter | Alarms, faults, restores and device text, with the panel's own clock tracked |
| Modbus TCP | LAN, VPN or site agent | Zones and loop devices by register polling |
| Fire alarm transmitter | GB/T 26875.3: the panel's transmitter connects over TCP | Full event decoding with acknowledgement |
| Relay contacts | Volt-free outputs through the site agent (serial control lines or a Modbus I/O module) | Common fire and common fault, for any panel at all |
Event handling
Every event, accounted for
- Three times on every event: the panel's clock, received, stored; a warning when a panel's clock drifts.
- A sequence number per panel; a resent event is stored once.
- A link loss is an event; what arrives after a reconnect is tagged "found on resync".
- Rules can re-class a driver's event (for example a site's own fault text), never lowering a fire.
Connection security
Connections that dial out
- Tunnel and agent dial out: no port is opened at the site.
- Each site agent has its own login and may publish only its own topics.
- A direct panel on a public address is flagged on the Panels page, so it is never left exposed.
- The site agent keeps events on its own disk until the server confirms them.
Building management and data
Open to your systems, closed to everyone else
| Modbus TCP | Server on port 502: status, analogue and flag registers, plus a command mailbox |
| BACnet/IP | Device on UDP 47808 with binary and analogue objects |
| MQTT | Events from every panel; TLS, one login per site |
| REST API | Versioned /api/v1 with an OpenAPI description, for your own dashboards |
| Notifications | Email (SMTP), Telegram, webhook (SMS / voice gateways) |
| Exports | Event report and alarm history as CSV or Excel |
| Monitoring | Prometheus metrics; service status page |
| BMS safety | Allow-listed client addresses, firewall commands generated for you; every command write audited |
Have a panel we haven't met?
Send us its interface and a sample of its output; a new format is added as a driver.