An automatic school bell system rings period bells on a timetable without anyone pressing a button, and handles the exceptions that matter: different days, exam weeks, assemblies, manual rings and lockdown alerts. Multilarm does this from one Windows PC or Raspberry Pi driving the speakers a school already has, for a one-off licence fee rather than a subscription.
An automatic school bell system rings period, break and dismissal bells on a timetable without anyone pressing a button. Modern systems do more than ring: they handle term dates and exam weeks, split the site into zones, carry live announcements, and double as the lockdown alert. This guide covers what to look for, what each option costs, and a complete working configuration.
At minimum it fires a sound at a scheduled time. That part is easy — a £15 timer plug can do it. Everything that makes a school bell system worth buying is the exceptions:
A system that handles the first item and none of the rest is a timer, not a bell system. This is the single most useful question when comparing quotes: what happens on the first day of exams?
There are three routes, and they differ less in what they ring than in where the schedule lives and who can change it. A dedicated appliance keeps the programming inside the box. An IP paging system replaces the endpoints and manages them centrally. Scheduling software keeps the timetable as a file on hardware you already own.
A physical box wired into the amplifier rack, programmed by keypad or a Windows utility. Reliable, well understood by the site team, and completely self-contained.
The catch is that programming lives in the box. Exam weeks and term dates are typed in by hand each year, the manual is lost, and when the unit fails — they are frequently fifteen to twenty years old — the replacement is a capital purchase and the schedule is re-entered from scratch.
The modern commercial answer: networked speakers or amplifier endpoints, a server, and a management console. Genuinely excellent, with per-speaker zoning, intercom and emergency integration.
The catch is scope. It is a cabling project as much as a software one, priced accordingly, and it usually assumes you are replacing endpoints. If your speakers and amplifiers are fine, you are paying to solve a problem you do not have.
A PC, mini-PC or Raspberry Pi with its audio output wired into the existing amplifier input — very often a 3.5 mm jack or a phono pair on the back of a rack you already have. The software owns the schedule; the building's existing distribution does the rest.
The catch is that it is a computer, so it needs to be treated like one: left on, patched, and backed up. In exchange, the schedule is a text file you can copy, version and email.
Multilarm is the third kind, which is the bias you should read the rest of this page with. Where the other two are the better answer, this guide says so.
The short version: an appliance is the most self-contained and the least flexible, IP paging is the most capable and the most expensive, and software is the cheapest and the most demanding of whoever looks after it. The table below is the detail behind that sentence.
| Bell timer / appliance | IP paging system | Scheduling software (Multilarm) | |
|---|---|---|---|
| Typical outlay | Low hundreds for the unit | Four to five figures, plus install | £0–£395 software, plus a PC you may already have |
| Uses existing speakers | Yes | Usually replaced | Yes |
| Term dates / inset days | Manual, each year | Usually calendar-aware | Date-scoped rules; automatic |
| Exam-period overrides | Rarely | Zone mute, if specified | Rule-based, per slot and per date |
| Zones | Fixed at install | Per speaker | Up to 4 via relay board |
| Live announcements | Separate mic circuit | Built in | Browser or phone, plus push-to-talk |
| Remote control | At the panel | Console on the LAN | LAN dashboard + optional internet relay |
| Runs with no internet | Yes | Usually | Yes — fully offline |
| Audit trail | None | Varies | Playlist and audit logs on disk |
| Fails how? | Unit dies, schedule lost | Server or network | PC dies; config file restores in minutes |
| Fixed by | The vendor | The vendor | You, or the vendor |
Two honest caveats. If your school has no usable amplifier or speaker distribution at all, software cannot help you — that is a cabling job, and an IP paging vendor is the right call. And if your site team's policy is that nothing may be a PC, a hardware appliance is the right answer regardless of price.
An academic day is extremely repetitive once written down. In Multilarm the entire schedule is one XML file. Times go in DateAndTimeData, one entry per day, each with its bell times in order:
<DateAndTimeData>*mon|8:50|9:45|10:45|11:05|12:30|13:15|15:15*tue|8:50|9:45|10:45|11:05|12:30|13:15|15:15*wed|8:50|9:45|10:45|11:05|12:30|13:15|14:30*thu|8:50|9:45|10:45|11:05|12:30|13:15|15:15*fri|8:50|9:45|10:45|11:05|12:30|13:15|14:45</DateAndTimeData>
<RecurEveryWeek>True</RecurEveryWeek>Wednesday and Friday finish early, and the file says so. Saturday and Sunday are simply absent, so nothing rings at the weekend — there is no "disable at weekends" setting to forget.
Different bells for different moments come from folders, not files:
<AlarmPath>C:\Bells\Period|C:\Bells\Break|C:\Bells\Lunch|C:\Bells\Dismissal</AlarmPath>
<AlarmIndexData>1|1|1|2|3|1|4</AlarmIndexData>AlarmIndexData maps each time slot to a folder by position: the first three bells and the 13:15 use folder 1 (Period), 11:05 uses 2 (Break), 12:30 uses 3 (Lunch), and the last bell of the day uses 4 (Dismissal). Each folder can hold several tones and one is chosen at random — a small thing that matters when staff hear the same sound five times a day for a year.
Split sites usually have two or three amplifier racks. MirrorDevices sends the same audio out of several outputs from one decoded buffer, so the bells land together rather than echoing across the quad:
<PlaybackDevice>3</PlaybackDevice>
<MirrorDevices>4|5</MirrorDevices>Term dates are handled by swapping the whole configuration on a date rule, so a holiday file with an empty schedule rings nothing and reverts on its own. Exam periods are handled differently, with rule overlays that change individual bells on matching dates while leaving the rest of the timetable untouched.
Term dates and inset days are handled by swapping the whole configuration on a date rule. AlternateConfig takes pairs of filename and rule, evaluated at midnight:
<AlternateConfig>school-holiday.xml,20-07-2027|school-inset.xml,02-09-2026</AlternateConfig>On those dates the named file loads instead, and a holiday file with an empty schedule rings nothing. The dashboard shows which configuration is currently live, so anyone walking past the office screen can see school-termtime.xml or school-holiday.xml at a glance.
Exam periods are the harder case, because you usually do not want a different school day — you want this bell suppressed, that one moved, and the rest untouched. Three rule overlays do that, each matching on day, date, weekday, month, slot number or source time, first match winning:
AlarmIndexRules — change which sound a slot uses. Point the corridor bells at a silent folder for the exam fortnight and leave everything else alone.OffsetRules — move a slot's time. Push the lunch bell ten minutes later during exams so the hall clears first.TextDataRules — change what the spoken announcement says on matching days.A rule is a payload followed by filters. For example, a rule that only applies on weekdays in May and June, to the fourth bell of the day, is written with slot=, m= and w= filters. Because the rules sit on top of the ordinary schedule rather than replacing it, the normal timetable stays readable — you are never maintaining two parallel copies that drift apart.
This is the single biggest practical difference from a bell timer. On an appliance, exam weeks mean reprogramming the unit and then remembering to put it back.
Yes, but zoning needs hardware. It works by muting the parts of the amplifier distribution that should not hear a given announcement, using a USB relay board — four channels covers two zones plus a bell and an emergency light, eight channels covers four zones. ZoneRules tags an announcement with its target zone, and the system opens the mute relay of every other zone in use for the duration, then always releases them.
The practical version: a "lunch is moved to 12:45" announcement goes to the teaching block only, and the exam hall never hears it.
The same relay board can also ring a real bell. BellScheduleRules is a separate, audio-free schedule that just pulses the bell channel:
<BellScheduleRules>08:50,dur=1500;10:45,dur=1500;15:15,dur=3000,w=mo-th;14:45,dur=3000,w=fr</BellScheduleRules>If your school has an electric bell circuit it likes, keep it, and use the audio side purely for announcements.
Yes, and it is worth doing because bells and emergencies compete for the same speakers, so something has to decide priority. An emergency loops a designated message at top priority and suppresses every scheduled bell until an authorised reset — no lunch bell firing halfway through a lockdown.
A physical emergency button wires to a GPIO pin on a Raspberry Pi. Pressed, it loops a designated audio file at top priority and suppresses every scheduled bell until an authorised reset — because the last thing a lockdown needs is the 12:30 lunch bell firing halfway through. Reset is a three-second hold on the button or a control in the dashboard, and there is a hardware-debounce and confirm window so a spurious electrical edge cannot trigger it.
Remote triggering is a deliberate, separate decision: a RemoteEmergencyAllowed setting decides whether an emergency may be started from the cloud dashboard at all. Set it false and only the physical button can begin one — remote reset always works regardless. Schools that do not want a lockdown startable from a phone can have exactly that.
Every fire sends an event: bell.fired, emergency.triggered and emergency.reset are dispatched as outbound webhooks, so an existing alerting system, Teams channel or SMS gateway can be told without any integration work on the bell side.
For nurse-call panels, timetable software or a BMS, an External Trigger API accepts the same set of actions over LAN HTTP, MQTT or the cloud, authenticated with per-integration bearer tokens.
For the software route, between nothing and roughly £400 for a typical single-building secondary school, most of which is the one-off licence. The hardware is a small PC or Raspberry Pi you may already have, plus about £10 per amplifier for a USB audio adapter and £15–£40 for a relay board if you want zones or a physical bell.
| Item | Cost |
|---|---|
| Multilarm, personal / evaluation use | Free |
| Charity tier licence (1 device) | £99 one-off |
| Solo tier licence (1 device) | £195 one-off |
| Trio tier licence (up to 3 devices) | £295 one-off |
| Site tier licence (up to 6 devices) | £395 one-off |
| Campus tier licence (up to 15 devices) | £645 one-off |
| Fleet tier licence (up to 50 devices) | £945 one-off |
| Raspberry Pi 4/5 or refurbished mini-PC | £35–£150 |
| USB audio adapters (one per amplifier rack) | ~£10 each |
| USB relay board (zones / physical bell) | £15–£40 |
| Cloud relay (remote control over the internet) | Optional subscription |
Licences are one-off and perpetual for the device count they cover — not annual. A typical single-building secondary school ringing bells across two amplifier racks with a physical bell and two zones lands around £250–£400 all in, most of which is the licence.
The comparison that matters is not against the cheap end. It is against re-quoting a failed appliance, or against the part of an IP paging quote that replaces speakers which currently work.
Seven steps, and none of them need a specialist. The whole job is connecting a computer to the amplifier you already have, typing in the timetable, and testing it before you rely on it. Budget an afternoon for the first install, and rather less for any after that.
DateAndTimeData as above, or build it in the browser-based configuration generator, which validates as you go.AlarmIndexData.AlternateConfig, and exam rules when you need them.Try the live demo — the same dashboard, in your browser, with nothing to install.
Is there free school bell software?
Yes. Multilarm is free for personal and evaluation use, and runs on Windows, Linux and Raspberry Pi. A school running it as an institution needs a one-off licence, from £99 for the charity tier; there is no subscription and no per-bell cost.
Can it use our existing speakers and amplifiers?
Yes, and that is usually the point. Anything that can take an audio input — a 3.5 mm jack or phono pair on the amplifier rack — can be driven from a PC's sound output. No new cabling or ceiling speakers are needed.
How do we stop bells ringing during half term and inset days?
Date-scoped configuration switching. AlternateConfig loads a holiday configuration with an empty schedule on the dates you name, and reverts automatically. Nobody has to remember to switch it off on the Friday.
Can we silence bells near the hall during exams without changing the rest of the timetable?
Yes. Rule overlays (AlarmIndexRules, OffsetRules) change the sound or the time of individual slots on matching dates, leaving the normal timetable intact. Combined with zone relays, corridors near the exam hall can be muted while the rest of the site runs normally.
Does it need an internet connection?
No. Everything — schedule, bells, announcements, emergency audio — runs entirely offline. Internet is only needed for the optional cloud dashboard that lets you control the system from outside the school network.
Can the office make live announcements?
Yes, two ways. Voice Broadcast records a message, lets you preview it, and plays it out on confirmation. Push-to-talk streams the microphone live to the speakers and pre-empts anything else that is playing.
What happens if the computer fails?
The whole configuration is a single XML file. Restore it onto another machine, plug in the audio, and the schedule runs. That is the practical advantage over an appliance, where the schedule lives inside the failed unit.
Can it ring a real electric bell rather than a sound through speakers?
Yes. A USB relay board pulses the bell circuit on its own point-in-time schedule, independent of any audio. Many schools run both: the physical bell for periods, the speakers for announcements.
Will it work on a Raspberry Pi?
Yes — Raspberry Pi is a fully supported platform, including 32-bit and 64-bit ARM, and is the cheapest way to run it. A Pi with a USB audio adapter is a complete bell controller for well under £100.
Multilarm is scheduled-audio, announcement and emergency-alert software for schools, factories, mosques and other facilities. Free for personal use; one-off licences for institutions. See pricing or try the demo.