If a building already has speakers for bells and announcements, it already has most of an emergency alert system. What is usually missing is the three things that make it trustworthy: a trigger anyone can reach, a guarantee that nothing else will fire over the top, and a clear answer to who is allowed to start one.
Three things decide whether an emergency alert can be relied on: a trigger somebody can reach without a computer, a guarantee that nothing scheduled will play over the top of it, and a clear answer to who is allowed to start one. Each is expanded below.
A dashboard button is useful and insufficient. The primary trigger should be physical: a button wired to a GPIO pin on a Raspberry Pi, mounted where staff actually are.
Two details separate a button that works from one that cries wolf. There is an arming grace period after startup, and a confirmation window after the edge is detected, because a spurious electrical edge at power-on is a real phenomenon on Pi-class hardware and an emergency system that occasionally starts by itself will be unplugged within a week.
This is the part people underestimate. Once an emergency starts, the designated audio loops at top priority and every scheduled fire is suppressed until reset. No lunch bell halfway through a lockdown, no scheduled announcement, no background music resuming when the loop pauses.
Suppression persists until an explicit reset — a three-second hold on the physical button, or a control in the dashboard. It does not time out on its own, because an emergency ending is a human decision.
If the file is missing or misconfigured, the emergency still happens: schedules are still suppressed and the emergency lamp relay still lights. A silent emergency is bad; an emergency that silently does not engage is far worse.
Remote triggering is a genuine policy question, so it is a setting rather than an assumption. RemoteEmergencyAllowed decides whether an emergency may be started from the cloud dashboard at all:
Remote reset is always honoured regardless of the setting. The asymmetry is deliberate: being unable to stop an alert remotely is itself a hazard, while being able to start one remotely is a decision each site should make for itself.
Wiring an emergency button takes four steps: choose the GPIO pin, wire the button between that pin and ground, set the audio file that should loop, and test the whole path at low volume. The glitch filters matter — a spurious edge at startup is normal on a Pi and is why the arm-grace exists.
EmergencyGpioPin to the BCM pin number; -1 (the default) means the button is off entirely.EmergencyAudioFile. Keep it short — it loops.RemoteEmergencyAllowed.An alert people can act on beats a siren every time. A usable message names the building or zone, says what to do rather than what has happened, uses the same words as the drill, is short enough to loop without becoming noise, and is recorded by a voice that will still be understood at volume. What holds up in practice:
Emergencies get reviewed afterwards. Every fire is written to the on-disk logs, and emergency.triggered and emergency.reset are dispatched as outbound webhooks the moment they happen — so an existing alerting channel, ticket system or SMS gateway can be told without any integration work at the audio end.
The practical value is the timeline: who triggered it, from where, when it was reset, and what audio actually played.
A system nobody tests is a system nobody should trust, but a full-volume unannounced lockdown tone is not a test — it is an incident.
Try the live demo — including the hardware panel with the emergency controls.
Does this replace our fire alarm?
No. This is voice alerting over a PA system and is not certified fire detection and alarm equipment. It complements a fire alarm by telling people what to do; it does not replace the system that detects and signals a fire.
What stops the normal bell ringing during a lockdown?
An active emergency suppresses every scheduled fire until it is explicitly reset. Nothing scheduled can play over the top.
How is an emergency reset?
By holding the physical button for three seconds, or from the dashboard. It never resets on a timer, because ending an emergency is a human decision.
Can somebody trigger a lockdown from their phone by accident?
Only if you allow it. RemoteEmergencyAllowed set to false refuses all remote starts, leaving the physical button as the only way to begin one. Remote reset always works.
What if the emergency audio file is missing?
The emergency still engages: schedules are suppressed and the emergency lamp lights, but no audio plays. Failing loud about the wrong thing is safer than failing silent about everything.
Does the alert go to every zone?
Yes. Emergency audio deliberately ignores zone targeting and plays everywhere at top priority.
Is there a record for the post-incident review?
Yes — on-disk audit and playlist logs, plus emergency.triggered and emergency.reset webhooks pushed to whatever you already monitor.
The documents below are worth reading before specifying anything in this area. Multilarm is not certified to any of them and does not claim to be — they are here because a building's emergency audio is a regulated subject and the distinction between voice alerting and a certified alarm system is the whole point of the warning at the top of this page.
Part of the Multilarm automatic school bell system guide. For mosques, see mosque emergency alert systems.