What is Multilarm?

Multilarm is a lightweight console application that plays specified audio files at specified times — recurring every day, week, month or across the whole year — and gives you live remote control of the whole thing from your phone, your office, or anywhere on the internet.

It was born to solve one stubborn problem: a mosque wanting a single, reliable device that calls the Adhan at the correct prayer time every day of the year, with no subscription, no cloud dependency, and no monitor or keyboard plugged in. From that root it grew into a general-purpose institutional audio engine — the same scheduling brain happily runs school bells, factory shift sirens, care-home activity announcements, hotel and gym background music with timed messages, and hospital paging.

Install it on a Raspberry Pi tucked behind an amplifier, point it at your audio folders, set your times, and walk away. It will keep working through reboots, power cuts and years of seasons — and when you do want to change something, you never need to touch the box again.

Who is this guide for?

Built for places that cannot afford to miss a cue.

A missed prayer call, a bell that rings a minute late, an evacuation tone that doesn't sound — in real institutions these are not bugs, they are incidents. Multilarm is engineered to be the dependable, set-and-forget audio brain those places need.

What makes it different

Who runs Multilarm

🕌 Mosques & prayer rooms

The original use case. Load a full-year prayer-time calendar, drop in your favourite Adhan recordings, and let Multilarm call each prayer at the exact local time — with automatic DST, Friday Jumu'ah overrides, Ramadan Sehri/Iftar messages, gentle fade-in for Fajr, and a live mic so the imam can speak through the same speakers. Sample Bangladesh and UK (Sheffield) calendars are included.

🏫 Schools & colleges

Period bells, assembly calls and break tones on a weekly timetable, with different schedules for exam weeks or term breaks via date-scoped config switching. A bundled weekly school PA sample shows the pattern.

🏭 Factories & warehouses

Shift-start, break and shift-end sirens around the clock, mirrored to amplifiers across the floor, with quieter night-shift volume profiles. Trigger ad-hoc evacuation or all-clear tones from a wall panel over the LAN trigger API.

🏥 Care homes & hospitals

Timed medication reminders, mealtime and activity announcements spoken in a natural neural voice, ambient music between events to keep speakers warm, and a remote dashboard so staff manage everything without touching the device. A bundled daily care-home PA sample is included.

🏨 Hotels, gyms & retail

A fully automated virtual radio station that shuffles your music library during opening hours, with timed spoken messages, closing-time announcements and per-zone volume. A bundled monthly gymnasium PA sample demonstrates monthly recurrence.

Everything Multilarm can do, at a glance.

A complete inventory of the engine. Each item links to its detailed documentation.

Scheduling & playback

Voice & speech

Audio & output

Connecting speakers (wiring)

Multilarm plays through whatever audio output the device already has — you don't need special hardware. Pick whichever of these fits what you've got:

Multiple zones? Send the same audio to several outputs at once with multi-speaker mirroring. To pick a specific output, press Ctrl+O at the console to list device indices, then set PlaybackDevice. If you can hear a scheduled alarm or the setup wizard's test sound, your wiring is good.

Remote control & integration

{
  "id": "evac-urdu",
  "name": "Evacuation announcements (Urdu)",
  "language": "ur",
  "languageName": "Urdu",
  "speaker": "A parent volunteer",
  "licence": "Given to the school",
  "phrases": [
    { "id": "evacuate", "text": "…",
      "english": "Leave the building now",
      "file": "evacuate.wav" }
  ]
}

Operations & reliability

Scenes, automations and listening

Scenes — one button, several actions

A scene is a named list of steps that run in order: play a sound, speak a line, wait, set the volume, pulse a relay, stop. It is what sits behind a single button in the console, and it can be run from the command line or by an automation.

Scenes live in their own file next to your config — <config name>.scenes.json — for one simple reason: nothing in the config file can express “play this, then say that, then ring the bell”. Your existing schedule, alarms, speech and background audio are untouched. A site with no scenes file behaves exactly as it always did.

Create and edit scenes on the Scenes tab of the console at /app. Renaming a scene deliberately does not change its id, so anything already referring to it keeps working.

Ready-made sets

If you are starting from nothing, pick a use-case pack at the top of the Scenes tab: Home, Shop or cafe, Gym or studio, Office or workshop, School, or Place of worship. Its scenes are added to your device.

A pack never replaces anything. If a scene with the same name already exists it is skipped and named in the confirmation, and applying the same pack twice adds nothing the second time. The Place of worship pack adds hall announcements only — it leaves your prayer-time schedule exactly as it is.

Automations — when this, do that

On the Automations tab you build rules in plain English:

• When — a smoke alarm is heard, the room is louder or quieter than a level you choose, the clock reaches a time, or Multilarm starts.
• If — optionally not between two times (quiet hours), and a minimum wait between one firing and the next.
• Then — run a scene, or announce some text.

A rule can only start things. There is deliberately no rule that can stop audio, mute the device or disable your schedule, so no automation — however it was written or edited — can be the reason your building goes quiet.

Listening to the room

Turn on Listen to the room in Settings and the device measures the room every twenty seconds. That gives you two things: a live measure of how loud the room is, and recognition of the standard smoke-alarm sound — the three-beep pattern every smoke alarm sounds. You can then use either as the When of an automation.

What happens to the audio. This matters, so it is worth being exact:

• It is off until you turn it on.
• A short clip is recorded to one temporary file, measured, and deleted immediately — before it is even analysed. There is no rolling buffer and no archive.
• Only a number (how loud) and a label (alarm or no alarm) ever leave the device. No audio is stored, transmitted, or sent to the cloud — not to us, not to anyone.
• Every detection is written to the audit log.
• Listening always gives way to you. If someone is using push-to-talk, recording a voice broadcast or recording speech, listening simply skips that turn.

Detection requires both the right pitch and the right rhythm, so a kettle, a buzzer or a reversing vehicle will not set it off. It reports what it heard — what your building does about it is up to the automation you write.

Matching announcements to the room

With Match announcements to the room switched on, a scene raises its volume in a noisy room and lowers it in a quiet one, then puts your volume back afterwards. It applies to scenes only, and it is firmly limited — it can never make a scheduled alarm or an emergency announcement quieter, and it never drops to silence.

Working from the command line

Every verb below drives the running device, so Multilarm must already be going. They are useful in a script, in cron or Task Scheduler, or over SSH.

multilarm --say "The hall closes in ten minutes"
multilarm --scene closing
multilarm --stop-scene
multilarm --list-scenes
multilarm --list-packs
multilarm --apply-pack retail

Two more read a file instead and need no running device:

multilarm --analyse recording.wav      measure loudness
multilarm --detect-alarm clip.wav      check for a smoke alarm
multilarm --normalise ./sounds         even out a folder

--normalise writes <name>.normalised.wav beside each file and never modifies your originals. It refuses to push a file into distortion, and skips anything that is silent.

For scripting, the exit code tells you what happened: 0 success, 1 you got the arguments wrong, 2 the device could not be reached, 3 the device refused.

5-Minute Quick Start

From download to scheduled sound in five steps. This walks the simplest path — a single Windows machine playing the default prayer calendar.

Step 1 — Install

Run the Windows MSI installer (it bundles .NET, the audio engine and the default Adhan/ambience/quote audio). On Linux/Pi, use the one-line installer. Full detail per platform on the Installation page.

# Linux / Raspberry Pi — one line:
sudo curl -s -L https://bit.ly/multilarm-linux | bash

Step 2 — Launch it

Double-click Multilarm.exe (Windows) or run $HOME/Multilarm (Linux). On first run it writes a default Multilarm.config.xml next to itself, pre-loaded with the UK (Sheffield) prayer calendar and sensible ambience settings. You'll see a colour-coded console and the next-alarm countdown in the title bar.

Step 3 — Point it at your audio

Drop your Adhan/bell/announcement files into the alarm folders, or change AlarmPath to your own folders. You can edit the config three ways:

• Open Multilarm.config.xml in any text editor (it's plain XML).
• Use the visual Configuration Generator — load, edit with per-field help, save.
• Enable the Web Remote and edit from your browser.

Step 4 — Set your times

The DateAndTimeData field holds your calendar. For a mosque, paste your annual prayer timetable; for a school, list your bell times. See Scheduling & Recurrence for the exact format, or just start from one of the bundled samples.

Step 5 — Control it remotely (optional)

Set WebRemoteEnabled=True, then open http://<device-ip>:6580/ from your phone on the same Wi-Fi. For control over the internet, connect a free Cloud account instead — no router setup needed.

Where things live

Installing Multilarm

Multilarm is self-contained — the required .NET runtime, the native audio engine and the bundled audio all ship inside the package. Choose your platform below.

Windows

Use the MSI installer (64-bit). It includes the .NET runtime and all dependencies, plus the Adhan, bleep, ambient and text-to-speech audio — which is why the package is larger than the program itself. Administrator privileges are requested so the installer can place files correctly.

Alternatively, download the standalone executable and the resource ZIP from the Binaries folder. Extract the resources into the program's root directory. The native audio library multilarm_audio.dll already ships alongside Multilarm.exe, so no system-folder copy is needed.

Run as a Windows Service

Multilarm can run as a Windows Service (LocalSystem, auto-start at boot — ideal for a headless install). Run the bundled batch files as administrator:

install-service.bat      :: install & start the service
uninstall-service.bat    :: stop & remove the service

Linux / Raspberry Pi

Option A — Flash the ready-made SD-card image (easiest)

A complete Raspberry Pi OS Lite (64-bit) image with Multilarm pre-installed is available from the download centre (multilarm-pi.img.xz). No Linux commands are needed:

1. Download the .img.xz file and flash it onto an 8 GB (or larger) microSD card with Raspberry Pi Imager (choose “Use custom”) or balenaEtcher — do not unzip it first; both tools flash .img.xz directly.
2. Insert the card into a Raspberry Pi 3 / 4 / 400 / 5 or Zero 2 W, connect a screen and keyboard (needed once, for the wizard), and power on.
3. The first-boot wizard appears on the screen and walks you through: Wi-Fi (skip if using Ethernet), linking to the cloud (choose Get a setup code — it shows a short code you enter at multilarm.com/setup; pasting a token is offered as an alternative), and audio output — a DAC HAT (IQaudIO / HiFiBerry) or a Bluetooth speaker.
4. Multilarm then starts as a systemd service and auto-starts on every boot. The screen and keyboard can be removed.

Option B — APT package (recommended on Raspberry Pi OS / Debian)

Add the Multilarm repository once, then install and update with the same apt commands you use for everything else. Packages are signed; both ARM 64-bit (arm64) and ARM 32-bit (armhf) are provided, and one repository serves Debian 12 (bookworm) and 13 (trixie).

# 1. Add the signing key:
curl -fsSL https://multilarm.com/apt/multilarm.gpg | sudo gpg --dearmor -o /usr/share/keyrings/multilarm.gpg

# 2. Add the repository:
echo "deb [signed-by=/usr/share/keyrings/multilarm.gpg] https://multilarm.com/apt stable main" | sudo tee /etc/apt/sources.list.d/multilarm.list

# 3. Install:
sudo apt update && sudo apt install multilarm

# 4. Start it for your user (per-user service, so it can reach your sound device):
systemctl --user enable --now multilarm

Later updates are just sudo apt update && sudo apt upgrade. Config and logs live in ~/.local/share/multilarm, so removing the package never deletes your settings.

Option C — Install script onto an existing Linux system

Tested on Raspberry Pi (Debian-based). The installer auto-detects architecture — installing 64-bit audio drivers on ARM64 systems and 32-bit drivers otherwise.

# Automatic install:
sudo curl -s -L https://bit.ly/multilarm-linux | bash

# Launch:
$HOME/Multilarm

Boot at startup (systemd user service)

# Create the service:
sudo curl -s -L https://bit.ly/multilarm-service | bash

# Check status:
systemctl --user status multilarm.service --no-pager --full

# Stop:
systemctl --user stop multilarm.service
systemctl --user daemon-reload

Removing the service / uninstalling

# Remove just the service:
systemctl --user disable multilarm.service
rm ~/.config/systemd/user/multilarm.service
systemctl --user daemon-reload

# Remove core files (keeps .NET, Adhan, config, audio lib, etc.):
sudo curl -sL https://bit.ly/multilarm-uninstall | bash

# Remove everything, non-interactive:
sudo curl -sL https://bit.ly/multilarm-uninstall | bash -s -- --yes

# Bind a Bluetooth speaker at boot (replace with its MAC):
sudo curl -sL https://bit.ly/RPiConfig-BTAudio | bash -s AA:BB:CC:DD:EE:FF

# Install IQAudio DAC Pro HAT drivers:
sudo curl -sL https://bit.ly/RPiConfig-DACProHAT | bash

System requirements

How Multilarm thinks

A few ideas underpin everything. Understand these and the rest of the configuration falls into place.

The priority audio engine

All audio flows through one engine that arbitrates between competing sounds using three priority tiers plus a background layer. You never have to time things manually to avoid overlap — the engine does it.

When an Adhan fires, the radio fades down, the alarm plays at full priority, and the radio fades back up — seamlessly. After an alarm, any queued TTS announcement speaks, then normal life resumes.

The scheduling model

Multilarm separates when from what:

• DateAndTimeData — the calendar: which times fire on which dates.
• DateAndTimeDataFormatInEffect — reshapes those raw times per day (add/subtract minutes, reorder, duplicate slots).
• AlarmIndexData — which audio folder each fired slot draws from.
• TextData — the on-screen / spoken text for each slot.

On top of all four sits a powerful, optional rules & per-day scope system so Fridays, Ramadan, weekends and seasons behave differently — without rewriting the whole year. See Scheduling & Recurrence for the full mechanics.

Path tags

Any file/folder setting accepts path tags that expand to the right system folder on each platform — so one config works across Windows and Linux.

Example: {app}\Adhan|{app}\Bleep resolves to the Adhan and Bleep folders next to the executable, on any OS.

Config hot-reload

Multilarm watches its config file. When you save a change — by hand, via the Config Generator, or through any remote interface — it re-applies most settings within about 1.5 seconds, no restart needed. Four settings are the exception (they bind hardware/ports at startup):

The audio engine under the hood

Playback and recording are powered by MultilarmAudio, an in-house native engine built on miniaudio (MIT-0) and libFLAC (BSD-3). It decodes each sound once and can fan it out to many output devices, frame-aligned. There is zero GPL code anywhere in Multilarm — relevant if you need to audit licensing for a commercial deployment.

The configuration file

All settings live in Multilarm.config.xml in the program's root directory. This page explains the file; the sub-pages document every field grouped by purpose.

How the file works

• Tags are case-sensitive, in <Tag>Value</Tag> format.
• Settings load at boot. A missing tag, or an invalid True/False value, is rewritten with the default — so the program needs write access to its folder.
• If the file is missing entirely, Multilarm creates a fresh one with default settings (UK Sheffield prayer calendar, ambience every 3 minutes). To reset to defaults, just delete the file.
• Avoid using line feeds as delimiters within fields (except TextData) — they parse differently across OSes.

Three ways to edit

Field groups

The reference is split for readability — jump to any group:

Scheduling & Recurrence

These fields define your calendar: which times fire on which days, and how the raw times are reshaped per day.

Recurrence mode

Pick one recurrence mode. If more than one is True, the priority is Month → Week → Day. If none are True, DateAndTimeData is treated as a full-year calendar with date+month markers.

Date & time format markers

The calendar itself

*1-1|6:26|8:20|12:11|1:44|4:00|5:48*2-1|6:26|8:20|12:11|1:45|4:01|5:49*…

Worked example

Day times 6:26|8:20|12:11|1:44|4:00|5:48 + default FormatInEffect produce the effective day:

6:21 | 6:26 | 8:20 | 8:30 | 12:01 | 12:11 | 1:44 | 3:53 | 4:00 | 5:48

— ten alarm slots derived from six prayer times, each mappable to its own audio folder and announcement text.

Alarms & Playback

What plays when a scheduled time fires, from which folder, and how.

2|1|2|2|2|1|1|2|1|1
*fr|3|1|2|2|2|1|1|2|1|1

Playing several different files per alarm

You do not add a list of files anywhere. You write it into the path you already have. Every AlarmPath entry — and TTSChimePath too — accepts:

<path>[>mode][*count]

<path> can be a folder (as always), a single file, or a folder with a filename pattern such as bell*.mp3. >mode decides how many files that path contributes:

• >one — one file at random. This is the default, so a plain folder path behaves exactly as it always has and existing configs need no changes.
• >all — every file in the folder, in filename order. Name them 1-intro.mp3, 2-adhan.mp3, 3-outro.mp3 to fix the order.
• >shuffle — every file, in a fresh random order each time.
• >seq — one file per alarm, stepping through the folder and wrapping at the end. This is how you play a different recitation each day. Multilarm remembers where it got to across restarts, and starts cleanly from the top if you add or remove files.

*count caps how many files come from that path: >shuffle*2 is two different random files, >seq*3 is the next three in the rotation.

Chain several sources with a plus sign surrounded by spaces:

{app}\Adhan\Bleep\intro.mp3 + {app}\Adhan + {app}\Adhan\Bleep\outro.mp3

That plays the intro bleep, then a random adhan, then the outro bleep — one uninterrupted announcement, with the radio suppressed throughout and the spoken text (if any) following at the end. The spaces matter, because + is a legal character in filenames: Rock+Roll is a folder name, a + b is a chain. Write \+ if a path genuinely contains a spaced plus.

A typo in a mode (>shufle) is reported as an error at startup and in the audio health check — it never quietly falls back to a random pick. The ambience file and zero-length files are excluded from a folder's contents, as they always were.

Rules & Per-Day Scopes

The system that makes Fridays, Ramadan, weekends and seasons behave differently — without duplicating your whole calendar. This applies to DateAndTimeDataFormatInEffect, AlarmIndexData, TextData and their rule overlays.

Two mechanisms, one resolution order

Three positional fields (DateAndTimeDataFormatInEffect, AlarmIndexData, TextData) each support per-day scope lines. Three of them also have a matching rules overlay (OffsetRules, AlarmIndexRules, TextDataRules). They resolve in this order:

rules overlay  →  per-day scope line  →  unscoped default line

Per-day scope lines

Any of the positional fields may hold several newline-separated lines. A line with no prefix is the default. A line starting with *<scope>| overrides the default when today matches that scope. Most-specific match wins.

Example — Tuesdays get an extra output slot:

1-5|1|2|2+10|3-10|3|4|5-7|5|6
*tu|1-5|1|2|2+10|3-10|3|4|5-7|5|6|7

Rules overlays

For cross-cutting, condition-based overrides, use a rules overlay. Each rule is <payload>;<filter>,<filter>…. Rules are tried top-to-bottom; first match wins; if none match, the per-day/default value is used.

The filter vocabulary (shared by all three rule fields)

The three rule fields

3+15;slot=3,w=fr

Jumu'ah Mubarak! Khutbah begins at #ALARM+1#.;slot=7,w=fr
Ramadan Kareem. Iftar at #ALARM+1#.;m=3-4,slot=4

Text-to-Speech

Multilarm can speak your announcement text aloud — either with a built-in neural voice or by stitching together your own recorded words. It also displays the text on the console, colour-coded.

The two engines

The announcement text

Word library settings (Builtin engine)

Speak Text (ad-hoc)

Beyond scheduled announcements, you can push arbitrary text to a device for immediate speech — from the dashboard's Speak Text card, the LAN endpoint POST /api/speak, or the cloud speak-text command. An optional per-message engine override (Builtin/Kokoro) applies just for that message. Playback queues at Priority 3, so a live alarm still wins.

Fixing a word's pronunciation

If the neural voice says a word wrong — a person's name, a place, a product, or a tricky term — you can correct it yourself, with no phonetic knowledge. The editor is called Pronunciations and appears in three places: the device's own Web Remote dashboard, the cloud dashboard, and the Android app (a tile on the device screen).

It works by ear — you respell the word and listen:

1. Word — type the word as it's actually written (e.g. Zayeed).
2. Sounds like — type how it should sound, in plain letters (e.g. zah yeed).
3. Preview — hear it. On the device dashboard it plays in your browser; on the cloud and app it plays on the device's speakers. Nudge the spelling and preview again until it's right.
4. Save — from then on every announcement says the word your way.

Use Test a sentence to hear the fixed word inside a full sentence, and Your fixes to review, replay or remove any correction. There's nothing to record and no file to edit.

The Pronunciation Workbench — reviewing every word

Fixing a word you have already caught is one thing; finding the ones you haven't is another. The Pronunciation Workbench lists every unique word this device can say — gathered from your announcement text, your schedule templates and, unless you turn it off, the ad-hoc announcements people type — and tells you where each pronunciation came from. Open it on the device's own network at http://<device>:<port>/pronunciations, or from the Pronunciations card on the Web Remote dashboard.

Each word carries a badge saying how it is being pronounced today:

• Guessed — the word is not in the dictionary and the voice is sounding it out from the spelling. These are the ones worth your time, and the page puts them first.
• From a related word — worked out from a word that is known (the plural, the possessive, a common ending).
• Dictionary — a known English word. Usually right, occasionally not: place names and surnames that look like ordinary words are the classic trap.
• Corrected by you — one of your own fixes.

Click a word to hear it, correct it the same way as above, and move on. The list is searchable and filterable, so “show me only the guessed ones” is one click.

Teaching a word by voice

Some words are easier to say than to respell. In the Workbench you can press Record, say the word once or twice into your phone or laptop microphone, and let the device work out the pronunciation for you.

It is worth being clear about what this does and does not do:

1. Record — press it, say the word, press it again. Two or three takes of the same word are better than one; the device averages what your deliveries agree on.
2. Work it out — the device thinks for a few seconds (longer on a Raspberry Pi) and offers a short list of candidates.
3. Hear each candidate in the announcement voice, then Use this on the one that is right. That saves it exactly as a typed correction would.
4. Forget recordings removes the takes for that word. The saved pronunciation stays.

If the browser will not offer a microphone — it only shares one over HTTPS or on localhost — use Suggest from spelling instead, which offers the same kind of candidate list worked out from the letters alone.

After you change the voice

A pronunciation you taught by voice is not a fact about the word. It is the reading that made the voice you had at the time sound closest to your recording — the candidates were synthesised in that voice and ranked against your delivery. Change KokoroVoice and every word you taught this way stays exactly as it was, now tuned to a voice the device no longer uses. Nothing breaks and nothing warns you; the words are simply said with someone else’s vowels.

At the bottom of the Workbench, Re-check my recordings works every recording you still have stored through the voice that is loaded now, and lists only the words the new voice disagrees with. It is worth pressing once after any voice change.

Audio Devices & Mirroring

Choose which sound card plays, which records, and how to fan one stream out to many speakers at once.

Finding device indices — Ctrl+O

Press Ctrl+O in the running console to print every audio device, one table for playback and one for recording:

Playback (PlaybackDevice=-1, MirrorDevices=1|3):
  0: Speakers (Realtek)          [default] [init]
  1: USB Audio DAC               [init]
  3: HDMI Output

Recording (RecordDevice=-1):
  0: Microphone (USB)            [default]

The first number is the index to enter in your config. Flags: [default] = OS default · [disabled] = present but unavailable (don't use) · [init] = currently in use by Multilarm. Ctrl+O is read-only.

Multi-speaker mirroring

Virtual Radio

A fully automated background music station: shuffle your library with no repeats, crossfade between tracks, and have it on air only during the hours you choose. Or play a live internet stream.

# Mornings, lunch, evenings on weekdays:
07:00-09:00|12:00-14:00|17:00-21:00,w=mo-fr

# Weekday office hours + Saturday mornings, except August:
08:00-20:00,w=mo-fr;09:00-17:00,w=sa,!m=8

Quote & Ambient Audio

Two gentle background layers (Priority 2): random spoken excerpts from a long recording, and ambient sound to keep speakers awake between events.

Quote playback

Plays a random complete spoken segment from a long audio file — detecting natural silence boundaries so excerpts start and end cleanly. Great for rotating reminders, hadith, safety messages or station idents.

00:00-06:00;06:30-12:00;12:30-16:00;16:30-18:00;18:30-00:00

Ambient audio

Plays a short slice of an ambient file at intervals — mainly to stop amplifiers/speakers entering sleep or producing a pop when the next real sound starts.

Volume & Transitions

Master level, smooth crossfades, and time-of-day volume overrides.

# Quiet nights at 30%:
22:00-07:00,volume=0.3

# Quiet night + weekday lunchtime dip:
22:00-07:00,volume=0.3;12:00-14:00,volume=0.6,w=mo-fr

# December cap at 50%, otherwise quiet nights at 20%:
00:00-00:00,volume=0.5,m=12;22:00-06:00,volume=0.2

Remote Control Settings

The config fields that enable and secure the remote interfaces. For how to use each interface, see the dedicated pages linked below.

Web Remote

Cloud Relay

External Triggers & MQTT

Instance & config switching

Recording your TTS word library

A guided console mode (Ctrl+R) for recording the individual words the word-library engine stitches into announcements — in any voice you like.

What it records

On entry, all scheduled audio pauses (and restores on exit). Multilarm works out which words it needs from your TextData (placeholders stripped) merged with the number words Zero–Twenty plus Thirty/Forty/Fifty, de-duplicated. Words you've already recorded are skipped — only missing ones are prompted.

Step by step

1. Press Ctrl+R.
2. Choose a format (asked once): 0 WAV · 4 FLAC (lossless). (Press Ctrl+M to leave without recording.)
3. For each word: press any key to start, any key to stop. Then:
   • P — play back the take (loops until a key press)
   • R — re-record
   • S — save and move to the next word
   • any other key — discard and move on
   • Ctrl+M — discard and return to the console

Saves go to TTSPath as <word>.<ext>. Re-running later picks up only new/missing words; existing recordings are preserved.

Voice Broadcast

Record a short clip, preview it privately, and — after explicit confirmation — broadcast it through the PA at top priority, just like an alarm.

From the console

Press Ctrl+B to enter Voice Broadcast mode:

• R — toggle recording on/off
• P — preview locally
• T — transmit (prompts Y/N, then plays through PlaybackDevice + mirrors at P1)
• D — discard
• Ctrl+M — exit

The clip is stored as voicememo.wav next to the program, overwritten by each new recording.

From the browser (dashboard)

The Voice Broadcast card on the Web Remote and Cloud dashboards has Record / Preview / Transmit / Discard buttons plus an upload control. When you click Record on a secure page (HTTPS or localhost), the dashboard captures from your browser's microphone, builds a WAV, and uploads it — so you can speak from your phone or laptop, not just the device's mic. On plain HTTP it falls back to recording from the device's RecordDevice.

Upload formats: WAV, MP3, OGG, FLAC/AIFF. Size limit 16 MB (LAN) / 5 MB (cloud upload). The upload endpoint is rate-limited and honours Basic Auth if configured.

Push-to-Talk (live mic)

Speak through the speakers in real time. The imam, the head teacher or the floor manager picks up a mic and the live audio passes straight through the PA — over every mirrored speaker at once.

How it behaves

• Routes the live input from RecordDevice to PlaybackDevice + every MirrorDevices index.
• Always pre-empts an in-flight alarm — whoever holds the mic owns the speakers.
• Auto-stops after 30 s without a keepalive, and a hard 5-minute session cap, so a forgotten open mic can't run forever.
• Latency is auto-tuned per platform (tighter on desktop, slightly relaxed on Raspberry Pi). No configuration needed — PTT is always available.

Two ways in

PTT fires ptt.started / ptt.stopped webhooks and audits each session. Acoustic feedback cancellation is intentionally not provided — position the mic away from the speakers.

Talkback (call-in)

Push-to-Talk with the arrows reversed. Instead of the office speaking to the building, somebody in the building rings the office — a caretaker at the panel, a teacher at the front desk, a warden during a drill — and the operator can answer and hear the room.

Who can start a call

Only somebody at the device. There are exactly two ways to ring:

• The device's own /talkback page, on the local network — open the Web Remote and click Talkback, or go to http://<device>:<port>/talkback. Type who you are and, optionally, one line about what it is about.
• Ctrl+W at the running console — rings the operator from the device itself; press again to hang up.

What happens on a call

• The call rings for up to 60 s unanswered, then gives up on its own.
• When the operator answers, the device plays an audible chime in the room. Nobody is listened to silently.
• A live call runs for at most 5 minutes, and ends early if the listener stops sending keepalives (a closed browser tab, a dropped link).
• Audio is buffered for seconds at a time and swept when the call ends. Nothing is recorded and nothing is stored — there is no file to find afterwards, on the device or in the cloud.
• Every request, answer, decline and hang-up is written to the audit log.

One microphone, one user

Talkback shares the device's single RecordDevice with everything else that needs an input, arbitrated by priority:

So a live PA announcement wins over a talkback call, and a talkback call wins over passive listening. If the mic is busy with something above it, answering is refused with a reason rather than silently failing.

Endpoints

Over the cloud the same call is answered from the dashboard's Talkback (call-in) card; the device then streams raw PCM up to the relay and the operator's browser plays it back. Talkback state rides the ordinary status push, so a ringing call appears on the dashboard without any extra polling.

Console Keyboard Reference

Every shortcut available at the running console. Most are single Ctrl+key combinations at the main screen; a couple are scoped to sub-modes.

Playback & testing

Voice modes

Diagnostics & devices

Hub & exit

Multilarm Box Hardware

Turn a Raspberry Pi into the complete brain of an institutional audio chain: PA announcements, a physical school/mosque bell via a USB relay board, a wired emergency broadcast button on GPIO, and zone-targeted announcements that mute the other zone's amplifier while they play. Everything ships disabled — a config without these fields behaves exactly as before.

What you need

• Relay board — a cheap CH340 USB relay (~£12, "LCTECH/SainSmart/ELEGOO USB relay"). A 4-channel board drives the bell circuit, two zone amp mutes, and an emergency indicator light; step up to an 8-channel board to run three or four zones (two extra zone mutes on channels 5 and 6).
• Emergency button — any momentary normally-open button wired between a GPIO pin (default GPIO 17, physical pin 11) and GND. Multilarm enables the Pi's internal pull-up itself — no resistor required.
• Audio out — the Pi's existing output, a USB DAC, or a HiFiBerry HAT (Pi 4/5 only — the HAT cannot seat on a Pi 400). Pick the device index with Ctrl+O as usual.

Enable it (config Group 16 — Hardware I/O, just six fields)

The hardware contract is fixed in code so there's almost nothing to configure: 9600 baud, channels 1=Bell, 2=ZoneMuteA, 3=ZoneMuteB, 4=EmergencyLed (plus 5=ZoneMuteC, 6=ZoneMuteD on an 8-channel board for four zones — wire the board to match), 500 ms button debounce and a 3 s hold-to-reset.

1. Plug in the relay board and set RelayPort (usually /dev/ttyUSB0) — the port is the on/off switch; leave it empty and the relay feature is completely off.
2. Confirm the board's byte protocol on a test config first: set the port, press Ctrl+G — each channel should click. No clicks? Switch RelayProtocol between A0 and FF and retry. Wrong protocol is harmless but the bell won't ring.
3. Bell times go in BellScheduleRules: 08:45,dur=1500,w=mo-fr;09:00,dur=1500,w=mo-fr; — 24-hour time, pulse length in ms, and the same date filters as radio rules. Bells are relay pulses only; they never interrupt announcements.
4. For the button, set EmergencyGpioPin (-1 = off, 17 = the documented wiring) and point EmergencyAudioFile at a short WAV/MP3 (record one with Voice Broadcast, or synthesise with the TTS engine). It plays on loop at top priority and every scheduled alarm, announcement, bell, quote and ambience is suppressed until reset — hold the button for 3 seconds, or press Reset on the web panel.

Field reference

The web Hardware panel

When either feature is enabled, the Web Remote dashboard grows a Hardware card: live channel states (refreshes every 5 s), per-channel Open/Close/Pulse, a Ring Bell button with duration, and the emergency status — shown in red with a single Reset button while active. Test Emergency runs the complete chain (audio override, schedule suppression, LED) with no button wired, so you can drill the whole path before any hardware arrives. If the board is unplugged the panel shows "Not connected" within one refresh and everything else keeps running.

Emergency Scenarios & automatic CAP alerts

Beyond the single built-in emergency, you can define named scenarios — e.g. Lockdown, Evacuate, All-clear test — each with its own looped audio and its own set of relay channels (a beacon, a strobe, the LED). Drop a scenarios.json file next to the device's config (same folder and base name, e.g. Multilarm.scenarios.json):

{
  "scenarios": [
    { "name": "Lockdown", "audioFile": "{app}\Adhan\lockdown.wav",
      "relayChannels": ["EmergencyLed", "2"], "suppressSchedule": true }
  ],
  "cap": { "enabled": false, "feedUrl": "https://…/alerts.atom",
           "pollSeconds": 120, "minSeverity": "Severe",
           "eventFilter": "Tornado,Fire", "scenario": "Lockdown" }
}

The built-in Emergency scenario always exists and reproduces the standard chain exactly. Fire any scenario from the cloud dashboard's Multilarm Box card (Emergency Scenarios section, owner-only, obeys RemoteEmergencyAllowed) or on the LAN via POST /api/scenario/fire with {"name":"Lockdown"}; POST /api/scenario/reset clears it.

CAP / IPAWS auto-fire. The cap block (off by default) polls a Common Alerting Protocol feed — national weather service, government or IPAWS — and automatically fires the mapped scenario when a real alert arrives at or above your chosen severity (and matching the optional event filter); a cancellation clears it. Multilarm only ever fires your own local, pre-defined scenario — it never plays anything the feed links to. Polling is outbound-only and capped. Leave enabled:false until you've tested your scenario with the dashboard Fire button.

Which feed do I point it at? Two are supported out of the box and were checked against the live services on 17 August 2026. Paste one into feedUrl:

If you use MeteoAlarm you must display an attribution. Its data is licensed CC BY 4.0, which permits redistribution but requires credit — so wherever you show these alerts (a notice board, a display screen, a printed sign) include a line such as “Weather warnings © MeteoAlarm (meteoalarm.org), CC BY 4.0”. The NWS feed carries no such condition. This is a licence term, not a courtesy.

A quiet feed looks identical to a broken one — an area with no active warnings returns a valid but empty feed. To confirm your setup really works, temporarily point feedUrl at a country that currently has warnings, watch the console log the match, then switch back.

Zone-targeted announcements

Wire each zone's amplifier mute input to its relay channel — ZoneMuteA = ch2, ZoneMuteB = ch3, and (8-channel board) ZoneMuteC = ch5, ZoneMuteD = ch6. To play an announcement in one zone, Multilarm opens the mute relay of every other zone you use, so only the chosen zone is heard. ZoneRules decides which announcements are targeted, using the same overlay grammar as TextDataRules with the zone name as payload: ZoneA;slot=7 sends the Dhuhr announcement to Zone A only. Two zones run on a 4-channel board; three or four need an 8-channel board. A site that only uses ZoneA and ZoneB never touches the ZoneC/ZoneD relays. The mutes engage just before the announcement and always release afterwards — even if playback fails. Announcements matching no rule play everywhere with zero relay activity, and bells always ring everywhere.

Status, logs & events

• Ctrl+I shows two extra lines: relay board state (port, protocol, channel count, or the failure reason) and emergency button state (armed pin / active flag).
• Ctrl+G runs the relay bring-up test: pulses the bell and a zone mute, holds the LED for a second, prints every channel state.
• GET /api/status carries a hardware block (relay/emergency enabled, available, emergencyActive) — so the cloud dashboard's status push sees emergencies too. GET /api/hardware/status has the full detail; see the API reference.
• Webhook events: bell.fired, emergency.triggered, emergency.reset — see Outbound Webhooks.
• Every relay action, bell fire, emergency trigger and reset is written to Multilarm.audit.log with its source (GPIO button, WEB panel, scheduled).

Provisioning a fresh Pi

The repo's scripts/ folder has the appliance tooling: build-multilarm-image.sh (one-shot idempotent setup of a fresh Pi OS Lite 64-bit (bookworm or trixie) — install dir, system service, relay udev rule, HiFiBerry overlay, CPU governor, log rotation), update-multilarm.sh (push new binaries, keep config), and multilarm-hardware-test.sh (on-site smoke test: relay click test for both protocols, audio, GPIO, service health). Run the smoke test before every go-live.

Web Remote

A built-in web dashboard and REST API served straight from the device — control and monitor Multilarm from any browser on the same network. Ideal for a headless Raspberry Pi: run it from your phone, no SSH, no monitor.

Enabling it

1. Set WebRemoteEnabled=True (and optionally change WebRemotePort, default 6580).
2. Restart Multilarm (these two fields bind at startup).
3. Browse to http://<device-ip>:<port>/ — e.g. http://192.168.1.50:6580/.

netsh http add urlacl url=http://+:6580/ user=Everyone

The dashboard

• Status — uptime, current audio, radio state, volume & profile, next alarm (auto-refresh 15s).
• Controls — volume slider, Skip Track, Test Radio, Test Alarm (with a folder dropdown).
• Today's Schedule — remaining prayer/bell times with live countdowns.
• Console Log — the rolling buffer, for remote diagnostics.
• Config Editor — view/edit every field and Save & Reload (the full Config Generator is embedded at /config).
• Voice Broadcast, Speak Text, Push-to-Talk and File Manager cards.
• Hardware — appears automatically when the Multilarm Box relay board or emergency button is enabled: live relay channel states (5 s refresh), per-channel Open/Close/Pulse, a Ring Bell button with duration, and the emergency status with Test/Reset (shown in red while an emergency is active).

REST API

All endpoints return JSON; base URL http://<ip>:<port>/api/.

# Examples
curl http://192.168.1.50:6580/api/status
curl -X POST http://192.168.1.50:6580/api/volume \
  -H "Content-Type: application/json" -d '{"volume":0.6}'

0 22 * * * curl -s -X POST http://localhost:6580/api/volume -H "Content-Type: application/json" -d '{"volume":0.3}'
0 6  * * * curl -s -X POST http://localhost:6580/api/volume -H "Content-Type: application/json" -d '{"volume":1.0}'

For security, firewall and internet-access details, see Web Remote Security.

Web Remote Security & Networking

How to protect the Web Remote, configure the firewall, and reach it over the internet safely.

Built-in protections (automatic)

1. Loopback-only when credentials are blank. If WebRemoteUsername or WebRemotePassword is empty, the server binds to localhost only — unreachable from other devices. Set both to expose it on the LAN.
2. Failed-auth lockout. 5 consecutive bad logins from an IP → 15-minute lockout. Address families (IPv4/IPv6 loopback) are normalised so the limit can't be bypassed.
3. Rate limiting. Each IP may make at most 30 state-changing POSTs per 60s; excess returns HTTP 429. GET polling is unaffected.
4. Constant-time credential comparison to defeat timing side-channels.

Authentication

Set both WebRemoteUsername and WebRemotePassword to require HTTP Basic Auth. Browsers prompt automatically; for API calls send the header or use curl -u user:pass.

Firewall

Multilarm auto-creates a firewall rule on startup (Windows Firewall inbound rule "Multilarm Web Remote"; ufw allow on Linux if active). If running unelevated and the rule fails, the server falls back to localhost-only. To open it manually:

# Windows:
netsh advfirewall firewall add rule name="Multilarm Web Remote" dir=in action=allow protocol=tcp localport=6580
# Linux:
sudo ufw allow 6580/tcp

Most Raspberry Pi setups have no firewall by default — nothing to do.

Access over the internet

Two options:

• Recommended: use the Cloud Relay — no port forwarding, no inbound connections, works behind any NAT, fully HTTPS.
• Port forwarding: forward an external port to the device, always enable auth first, use dynamic DNS for a stable hostname, and ideally front it with an HTTPS reverse proxy (Nginx/Caddy).

Cloud Relay

Control your devices from anywhere in the world — no port forwarding, no inbound connections to your network. The device reaches out; you drive it from a web dashboard.

How it works

Your browser  ⇄  Cloud dashboard  ⇄  Multilarm device (your PC / Pi)

The device polls the cloud over HTTPS every 5 seconds for pending commands, runs them locally, and pushes status back. Because every connection is outbound, it works behind any NAT/firewall with zero router setup. If the network drops, it retries with exponential backoff (5s → 60s) and resumes automatically.

Setup — link with a setup code (easiest)

No config files and no long token to copy. The device shows a short code; you type it into the dashboard.

1. Get an account — set up personally after a quick payment conversation (see Plans & subscription below); your temporary password arrives by email and you set your own at first sign-in at https://multilarm.com/cloud. Forgot it later? Use “Forgot your password?” on the sign-in page to reset it yourself by email — no need to contact us.
2. On the device, get a setup code:
   • Raspberry Pi — the first-boot wizard offers "Get a setup code and link online"; it shows the code on screen and links automatically.
   • Windows / any console — run Multilarm --claim (or press Ctrl+K and choose Claim online). A code like ABC-123 appears.
3. In the dashboard, open My Devices → Enter code, type the code, and press Link device. (Shortcut: multilarm.com/setup.)
4. A short guided setup wizard opens — name the device, pick what it's for (mosque, school, care home, office/factory), and play a test sound. The device is now ONLINE. The code expires after 15 minutes; if it lapses, get a fresh one.

Install it as an app

The dashboard can be installed like an app — its own icon, its own window, no address bar — on iPhone and iPad, Android, Windows, macOS and Linux. It is the same dashboard, so there is nothing new to learn and nothing extra to keep updated.

• Android / Windows / macOS / Linux — click Install app in the dashboard's top bar (it appears only when the browser supports it), or use the install icon in the address bar.
• iPhone / iPad — open the dashboard in Safari, tap Share, then Add to Home Screen. On iOS only Safari can install.

Step-by-step instructions per platform live at multilarm.com/cloud/app/.

Setup — advanced: paste a token

For offline installs or scripting, you can still link with a device token instead of a code. In the dashboard's Advanced: token tab, click + Add Device, name it, and copy the 64-character token, then hand it to the device by any of:

• Console — press Ctrl+K, choose Paste a token, and paste it. It's validated, written into the config for you, and the relay connects immediately — no restart, no file editing.
• Command line (headless / scripted installs) — run Multilarm --cloud-token <token>. It writes the token into the config file and exits; a running instance on the same config picks the change up within ~2 seconds, so this works over SSH on a Pi without stopping the service. Pass clear to disable Cloud Relay; add --config to target a specific zone's file. The dashboard's token reveal has Windows command / Linux command buttons that copy the complete ready-to-run line.
• Config file — set CloudDeviceToken to the token directly.

Either way, watch for "Cloud relay started" then "Cloud: Connected…" in the console; the device shows ONLINE on the dashboard.

Keeping devices up to date is one click: when a newer Multilarm release is available the device's status card shows an Update button. The device downloads the new version, checks it, switches to it and confirms it came back online — and if anything goes wrong it automatically rolls back to the version it was running, so a remote device can never be left broken. By default nothing updates on its own — you're always in control. If you'd rather not think about it, the same Software row has an optional Auto-update switch: turn it on and that device checks for a newer release about once a day and installs it by itself, using the exact same verified download and automatic roll-back — and a release that has just failed is left alone for two days, so a bad build can never get stuck retrying. Leave Auto-update off to keep updates strictly one-click. It's per device, so you can switch it on for one machine first and enable the rest once you're happy.

The cloud dashboard also has two self-service shortcuts in its header: Get help (describe a problem — if a device is selected it attaches its status and asks the device to send a sanitised diagnostics bundle automatically, so you never have to dig out logs; secrets are stripped on the device first) and My account (your plan, cloud-access date, device usage and invoice history with downloadable PDFs). New accounts also get an offline email alert switched on by default so you're told if a device goes quiet.

The Configuration card also keeps a Config history: a rolling set of daily snapshots of each device's settings. If an edit doesn't work out, you can view a previous configuration and restore it in one click — your device's cloud token and LAN passwords are always kept as they are, never overwritten.

Plans & subscription

Cloud Relay is a subscription service set up personally — there is no self-service signup or card payment. Getting started: (1) contact hello@multilarm.com (or the website contact form) with how many devices you run; (2) pay by bank transfer or invoice; (3) your account is created and a temporary password is emailed to you (valid 7 days); (4) sign in at https://multilarm.com/cloud — you'll be asked to set your own password immediately, then the dashboard unlocks. Plans are device-count tiers — one price per tier covers a set number of devices (1, up to 3, up to 6, up to 15 or up to 50) plus an escalating support level, billed monthly or yearly; each account has a device limit matching its tier. Current prices are at https://multilarm.com/pricing.html, a calculator that totals a whole site over three, five or ten years — licence, hardware, commissioning, optional cloud and optional maintenance — is at https://multilarm.com/cost-calculator.html, and the licence agreement those prices are sold under — including what personal and sole-operator use covers — is published in full at https://multilarm.com/terms.html. Renewals work the same way — arrange the next payment and your access date is extended — and you never need to watch the calendar yourself: about a month before your access date a renewal invoice (PDF) is emailed automatically, with polite reminders as the date approaches, and every confirmed payment is answered with an emailed receipt. If a payment is late you get a clear grace-period notice well before anything pauses. If a subscription lapses, the device keeps running all of its local schedules, bells and emergency triggers unchanged — only remote control, app push and email alerts pause; the dashboard shows a renewal banner (with a grace window after the end date), and the device's poll responses carry "subscription":"expired". Accounts created before the subscription system launched stay free.

What the dashboard offers

Roles: Admin vs Operator

Admins own devices and manage everything. Operators are invited by an admin (via a one-time setup link) to perform granted tasks — transmit audio, test alarms — but cannot add/remove/rename devices, edit configs or manage alerts. Operators only see their own actions in the audit log.

Security

• All traffic is HTTPS; device tokens are 64-char cryptographically-random hex.
• Passwords hashed with bcrypt (cost 12); login rate-limiting; CSRF protection; prepared SQL; httponly/secure/SameSite=Strict cookies.
• Commands expire after 60 seconds if the device is offline.

Android app

A native Android app gives you the whole cloud dashboard on your phone — built for big, clear buttons and large readable text, so you can run an alarm, speak an announcement or go live on the PA one-handed.

Installing & signing in

• Install it from the Google Play link the operator gives you (it ships on a private internal track), then open Multilarm.
• Sign in with the same username and password you use on the cloud dashboard. Turn on Keep me signed in to skip the login next time.
• Your devices appear on the home screen with an online dot. Tap one to control it. Admin logins see everything; operator logins see only the day-to-day controls on the devices shared with them.

What you can do

Owner-only: the full Configuration editor, TTS word-library fill, External Triggers, Batch actions across devices, Email alerts, Operator management, Audit log, and adding, renaming, removing and revealing the pairing token of devices.

Handy extras

• Push notifications — get a notification on your phone within seconds when a device has a problem: it goes offline, misses an alarm, is missing an audio file, runs low on disk, or has a speaker/audio-device fault. Turn it on under Email alerts → Phone notifications (owners): tick which events should push, switch on Notify this phone, allow notifications when prompted, then use Send test notification to confirm. It works even when the app is closed, and tapping a notification opens that device. Runs alongside email/webhook alerts. A lightweight on-device offline check still runs as a fallback on phones without Google Play services.
• Telegram alerts (free) — get the same offline / missed-alarm / missing-audio / disk / audio-device alerts in a Telegram chat, with no SMS provider or extra cost. Under Email alerts → Telegram (owners): create a bot with @BotFather in Telegram to get a bot token, send your new bot any message, then get your numeric chat ID from @userinfobot. Paste both in, tick Send alerts to Telegram, and press Test Telegram to confirm. Add several chat IDs (comma-separated) to alert a whole team; group and channel IDs are negative. Fires alongside email, webhook and phone push for any enabled event.
• Slack, Microsoft Teams or Discord (free) — the same alerts can land in a chat channel your team already watches. Create an incoming webhook in your own workspace and paste the URL under Email alerts → Slack / Microsoft Teams / Discord (owners); tick Post alerts to a chat channel and press Test chat to confirm. Slack: Apps → Incoming Webhooks → Add to Workspace. Teams: the channel’s Workflows → Post to a channel when a webhook request is received, or a classic connector. Discord: Edit Channel → Integrations → New Webhook. Multilarm installs no app and holds no workspace token — just the URL, stored encrypted and never shown again, because anyone holding it can post into your channel. The platform is detected from the URL rather than a dropdown, so a Teams URL can never be sent a Slack-shaped message (which Teams accepts with a success code and then displays as nothing). Fires alongside email, webhook, push and Telegram for any enabled event.
• Visual display (wall/TV) — turn any cheap TV, tablet or Pi-with-monitor into a full-screen display for a device: a big clock, the next prayer or bell with a live countdown, the Hijri date (mosque mode), an optional scrolling notice, and an automatic full-screen emergency takeover when the device's emergency is active. Set it up under Dashboard → Display (owners): pick the device, choose Mosque / School / Factory mode and a theme, optionally add a notice ticker, then open the public link on the screen (bookmark it full-screen / kiosk). The link is read-only — it can show status but never control the device — and you can rotate it any time to revoke old screens.
• Digital signage you already own — if the building already runs signage (Xibo, Yodeck, ScreenCloud, Rise Vision, OptiSigns and anything else with an RSS or ticker widget), it can carry Multilarm without a second screen or a second player. The Dashboard → Display card shows a signage feed URL beside the display link: paste it into the player’s RSS/ticker widget and it shows an active emergency first, then your notice text, a warning if the device has stopped reporting, and the next scheduled event. Add &format=json or &format=txt for players that prefer those. It uses the same read-only token as the display link, so Rotate link revokes both at once. A player that can show a web page does not need the feed — give it the display link instead and it gets the full screen.
• Notify people (mass notification) — alert a whole list of people at once across email, phone push and Telegram, with an “I’m safe” acknowledgement link so you can see who has responded. Under Dashboard → Notify People (owners): add recipients (email and/or Telegram chat ID, optional group tags), then compose a message, pick the channels and send. A live board shows sent / failed / acknowledged counts. Email uses your Email Alerts SMTP settings, Telegram uses the bot token there, and push goes to your own registered phones — no SMS provider needed.
• Big text everywhere — increase your phone's system font size and the whole app scales with it.
• In-app help — a plain-language guide to every screen lives under the Help icon.

Multilarm Hub

Running several zones on one machine? Promote any instance to a Hub and get a single dashboard that controls every other instance on the host.

Turning it on

• At launch: Multilarm.exe --hub (or -H).
• At runtime: Ctrl+H to promote, Ctrl+Shift+H to step down. While off, the /hub route returns 404.

How instances find each other

Every instance writes a heartbeat file every 15 seconds to %LOCALAPPDATA%\Multilarm\instances\<id>.json (id, name, port, host, credentials, active config, timestamps). The Hub enumerates that folder, keeps entries seen within the last 60 seconds, and renders one card per live peer. Files are removed on clean shutdown.

What the Hub dashboard does

• Lists every live peer with status (playing / radio / volume / uptime / active config).
• Per-peer controls: volume slider, Skip, Test Alarm, Test Radio, an Active Config dropdown (rewrites that peer's AlternateConfig so its midnight evaluator picks the chosen file), and an "Open" shortcut to that peer's own dashboard.
• All peer calls go through the Hub as a reverse proxy, which injects each peer's Basic Auth server-side — so credentials never reach the browser.

See also the System Tray companion, which uses the same heartbeat folder to surface running instances on Windows.

External Trigger API

Let other systems fire Multilarm: a nurse-call button, a school timetable engine, a building-management system, a factory line controller. Three transports converge on the same action set.

The action set

All transports can request: play-random, play-file, stop, volume, and transmit-upload (stage an audio clip then broadcast it at Priority 1).

Three transports

Tokens & profiles

The LAN/MQTT surfaces are governed by a local <configBaseName>.triggers.json file (override with TriggerConfigPath): trigger profiles, bearer tokens, a per-token key allowlist and a per-minute rate limit. The cloud surface is backed by dashboard-managed tokens. Every fire is audited.

Outbound Webhooks

The mirror image of triggers: Multilarm pushes events to your systems as they happen, so dashboards, logs and automations stay in sync.

Events

Multilarm fires HTTP webhooks for key events, including:

• tts.spoken — an announcement was spoken
• alarm-fired events
• ptt.started / ptt.stopped — live-mic sessions
• radio.stream-fallback — an online stream dropped and the device fell back to the local library
• bell.fired — a Multilarm Box bell pulsed the relay (payload: time + duration)
• emergency.triggered / emergency.reset — the emergency broadcast started or cleared (payload: source — GPIO button or WEB panel)

Point these at your logging stack, a chat channel, a home-automation hub or a monitoring dashboard. Webhook dispatch runs before the engine-specific TTS path, so receivers learn about a spoken event regardless of which TTS engine produced it.

Configuration

[{"Url":"https://hooks.example.com/multilarm","Secret":"s3cr3t","Events":["alarm.fired","tts.spoken"]}]

SIP Paging

Pick up any desk phone, dial an extension, and speak through the PA. SIP paging connects Multilarm to the phone system you already have, so making an announcement takes no special hardware, no app and no training.

How it behaves

A page is treated as an announcement like any other, which means it obeys the same priorities you already rely on:

• The virtual radio ducks for the duration and resumes afterwards.
• An alarm or emergency broadcast still wins. If one is already playing, the call is answered but the caller is not heard until it finishes — a phone call never cuts off an adhan or an evacuation message.
• Only one live source at a time. If someone is already using Push-to-Talk from the dashboard, an incoming page is refused as busy, and vice versa.
• Zone routing applies as configured, so a page reaches the same speakers your announcements do.

Setting it up

1. Ask whoever runs your phone system to create an ordinary extension for Multilarm — it needs no special privileges, only the ability to receive calls. Give it an obviously non-human name such as multilarm-pa.
2. Download the Multilarm SIP companion for your platform from My Account in the cloud dashboard, and install it on the device that should answer the extension.
3. Fill in settings 76–83 in the Configuration Generator (section “SIP paging”), or in the cloud config editor.
4. Dial the extension from a handset and speak. If nothing is heard, run the companion with --check: it prints the configuration, whether it can reach Multilarm, whether the account is entitled, and who is on the allow-list.

Who is allowed to page

SipAllowedCallers (80) decides which extensions may make an announcement — 201|202, a wildcard like 30*, or * for anyone.

Remember that caller ID comes from your phone system, and a PBX that accepts calls from outside can be made to present any number at all. If external calls can reach this extension, keep the list tight and ask your phone provider to block inbound calls to it.

Firewalls and ports

The companion listens on UDP port 5060 by default (setting 83, SipLocalPort). Keep it fixed unless something else on the device already uses that port — your firewall rule needs an address that stays valid, and some phone systems send calls to a set address and port rather than to whatever contact the device last registered from. Setting it to 0 lets the operating system pick any free port, which changes on every restart and quietly invalidates the rule you wrote.

Field reference

If the internet goes down

Paging keeps working. The companion confirms your subscription when it starts and roughly twice a day after that, and if it cannot reach the cloud it carries on for a fortnight on the last confirmed answer. Only a definite “this account no longer has SIP” stops it. An outage at our end must never become an outage in your building — the same principle as the rest of Multilarm, which runs its whole schedule with no internet at all.

What it does not do (yet)

Paging is one-way: the caller speaks, the building listens. Multilarm never sends audio back down the call, so the paging extension cannot be used to listen in on a room. Two-way intercom is a separate feature and is not part of this.

Room Listening & Recording

Four settings (84–87) that let the device hear the room as well as speak to it. They cover two genuinely separate things, and you can use either without the other.

The two things, and why they are not the same

Listening measures. Every twenty seconds it captures a few seconds of room audio, works out how loud it is, checks whether it matches the standard fire-alarm pattern, and deletes the clip before analysing it. What survives is a handful of numbers. Nothing is written to disk, nothing is sent to the cloud, and there is no control anywhere that plays any of it back — not because playback is disabled, but because the audio no longer exists.

Recording keeps. It writes WAV files to disk that persist, can be copied, and can be listened to by anyone with access to the device. That is a different thing with different consequences, so it is a separate setting you have to turn on separately. Turning on listening does not start recording, and vice versa.

The settings

What listening is actually for

• Matching announcements to the room — the measurement feeds AdaptiveGainEnabled, so a message set for an empty hall stays audible once it fills up, and does not startle anyone at six in the morning.
• Automations — the room is louder than / quieter than triggers become available, so you can act on a room going quiet or getting noisy.
• Hearing a smoke alarm nobody else is there to hear — an unstaffed site, out of hours. This is pattern matching on the ISO 8201 / NFPA 72 “T3” temporal code, not a general sound classifier: it wants three short bursts and a pause, so a continuous tone at the same pitch does not trigger it, and neither does the same rhythm at a very different pitch.

Adaptive gain, and the line it will not cross

Adaptive gain moves the volume of scheduled announcements, the virtual radio and ambience within a bounded range around your configured Volume, and returns to it as the room settles. The bound is why a single slammed door cannot drive the PA to maximum.

With ListenEnabled off, adaptive gain has no measurement to work from and changes nothing at all. It does not warn about this, so if volumes are not moving, check 84 first.

Scheduled recording

RecordScheduleRules uses exactly the same grammar as the radio and quote schedules — nothing new to learn:

Files land in a Recordings folder beside your config, named by start time (rec-20260824-090000.wav), and are reachable through the Audio File Manager like any other audio.

• Recording never interrupts playback. It only reads the microphone; announcements, alarms and emergency broadcasts use the output and are untouched by it.
• It does yield the microphone. There is one capture device and four things want it, ranked by whether a person is waiting: Push-to-Talk, then Voice Broadcast, then scheduled recording, then room listening. If an operator starts talking mid-recording, the recording stops and the part already captured is kept — a truncated recording is more use than none. Recording in turn takes the microphone from listening.

Retention, and the one setting that can fill a disk

The tidy-up runs whenever nothing is being recorded, so a device left alone keeps its own disk in order. RecordRetentionDays = 0 means keep everything for ever, and it is honoured exactly — which is worth doing the arithmetic on before you choose it. Continuous recording at the default quality is roughly 0.3 GB a day, so a year is over 100 GB. On an SD card that ends in a full disk, and a full disk is a device that cannot write logs, cannot update, and may not start. If you need indefinite retention, copy the files somewhere else on a schedule instead.

Before you turn listening on

A device that listens to a room is something the people in that room are generally entitled to know about — in a workplace, in many places, something you are required to tell them. That it keeps no audio is a good answer to give them, not a reason to skip the conversation. Recording raises the bar again, because the files persist. Where you are and who is in the room decide what is permitted; the software cannot make that judgement for you, and does not try.

Setting it up

1. Plug in a microphone and set RecordDevice (44) to its index — press Ctrl+O at the console to list the inputs.
2. Turn on Listen to the room (84) in Settings, or field 84 in the Configuration Generator, section Room listening & recording.
3. Leave it a few minutes, then check the reported room level looks plausible before relying on it.
4. Only then turn on adaptive gain (85), so you can tell the two apart if something looks wrong.
5. Recording is independent: set 86 when you want it, and set 87 to a retention you can actually store.

Audio File Manager

Upload, browse and delete the audio that drives your schedules — from the browser, over LAN or cloud — with no SSH or RDP. Built for commercial operators who can't (and shouldn't) log into the box.

What you can manage

The File Manager exposes named roots derived live from your config: each AlarmPath folder, plus TTS, Radio, Ambience, TTSChime and Quote. You can list a root (and its subfolders), upload new files, and delete existing ones.

Where it lives

• Web Remote: a File Manager card, backed by GET /api/files/roots, GET /api/files, POST /api/files/upload, POST /api/files/delete.
• Cloud: the same operations via the files-roots / files-list / files-upload / files-delete commands; uploads stage on the cloud and the device fetches them on its next poll.

Rules & safety

• Allowed extensions: .mp3 .wav .ogg .flac .aif .aiff. Upload cap 16 MB.
• Deleting a TTS word requires an explicit confirmTts:true — removing word audio breaks announcements, so it can't happen by accident.
• Path safety rejects directory traversal and any symlink/junction segment.
• Every action is written to two ledgers: cloud audit_log (intent) and the device's Multilarm.audit.log (execution).
• Roots are addressed by stable label, read live per request — so config changes are picked up instantly.

System Tray Companion (Windows)

A small Windows tray app that auto-discovers every running Multilarm instance on the machine and gives you a right-click menu to each one — handy when you run several zones.

• Discovers live instances via the same %LOCALAPPDATA%\Multilarm\instances\*.json heartbeat folder the Hub uses.
• A per-instance submenu talks to each device's loopback Web Remote.
• Single-instance guarded — only one tray app runs at a time.

It's a standalone binary; install it on the host machine where your instances run.

Multi-Zone Deployments

Run two or more independent Multilarm instances on one machine, each driving its own zone — room, speaker set or output device — with its own calendar, volume and audio chain.

The building block: --config

Each instance loads its own config file via --config <path>. Give every zone:

• Its own config file (--config).
• A distinct PlaybackDevice (and RecordDevice if it uses voice features).
• A distinct WebRemotePort (two servers can't share a port).
• A distinct CloudDeviceToken (each zone is its own device in the cloud).
• A meaningful InstanceName (e.g. "Main Hall PA") so the Hub grid is readable.
• Optionally its own MirrorDevices to fan that zone across several speakers.

"C:\Program Files\Multilarm\Multilarm.exe" --config zones\livingroom.xml
"C:\Program Files\Multilarm\Multilarm.exe" --config zones\bedroom.xml
"C:\Program Files\Multilarm\Multilarm.exe" --config zones\kitchen.xml

The processes run independently — they don't share state and don't need to know about each other. The only cross-instance coordination is making sure ports and devices don't clash.

Multi-Room Audio

Several Multilarms, one sound, played at the same moment. One device is the sending device; the others are rooms that follow it while keeping their own schedule, their own emergency button and their own settings.

What gets sent

Everything the sending device plays: scheduled items, spoken announcements, the Virtual Radio, quote and ambient audio, a live microphone. It is a copy of that device's finished output, taken after mixing and after volume, so what a room plays is exactly what the sending device is playing — no second schedule to keep in agreement.

Turning it on

Six settings, config Group 21 — Multi-room audio (fields 88–93), all of them off out of the box. A device that has never been told about multi-room opens no port and behaves exactly as it always has.

You need exactly one sending device. Two on one network is not something the software can detect for you: each room joins whichever it finds first, and the building ends up playing two things. Changing the role takes effect on restart, because switching it live would mean taking the audio path apart underneath whatever is playing.

A room keeps its own life

Joining a group adds a source of sound; it never takes the local one away. A room still runs its own schedule, still answers its own emergency button, still serves its own Web Remote. If it loses the network it goes quiet rather than guessing — two ends of a building announcing different things is worse than one end announcing nothing — and rejoins by itself when the network comes back.

What “in step” honestly means

Rooms are matched to each other. Each room measures the round trip to the sending device, corrects its own clock against it, and plays each chunk at the moment the sender stamped it. Two rooms therefore agree to within roughly the sum of their clock errors, and each error is bounded by half a round trip — a few milliseconds on an ordinary wired or good wireless network.

What is not corrected is the delay your own sound card or amplifier adds after Multilarm hands the audio over, which differs from one piece of hardware to the next. Identical hardware in every room gives the tightest result. We publish no single figure because the number belongs to your network, not to ours — so the software measures it for you:

Multilarm --rooms-probe            # find the sender, measure, print JSON
Multilarm --rooms-probe 192.168.1.50:7451 30   # that sender, for 30 seconds

It joins as a silent observer — it deliberately plays nothing, because a measurement that broadcasts into a building is one nobody runs twice — and prints one line: clockOffsetUs, bestRttUs, arrivalJitterUs, how many chunks arrived after their play moment at the current buffer, and roomToRoomBoundUs, the honest bound on how far two rooms can be apart. Exit code 0 measured, 2 could not reach the sender, 3 refused.

Choosing the buffer

• 400 ms (default) — comfortable on wired or good wireless, unnoticeable for scheduled sounds, announcements and music.
• Raise towards 800–1500 if a room stutters or drops out. That is almost always a weak or busy wireless link, and a bigger buffer is the correct fix.
• Lower towards 150–250 only on wired networks and only where the delay genuinely matters, such as a live microphone whose operator can hear a distant speaker while talking.

Set the same value everywhere: two rooms with different buffers are, by definition, out of step by the difference.

Checking it is working

Press Ctrl+I on either device for a one-line summary, or read rooms in GET /api/status on the Web Remote — the sending device reports how many rooms are following, a room reports which device it follows, its clock offset, round trip, and how many corrections and gaps it has seen.

Output Tuning — EQ, Delay and Limiter

Per-output tone correction, speaker time-alignment and peak limiting, built in. This is the work a separate rack DSP is normally bought and wired in for, and it is the difference between announcements that are merely loud and announcements a room can actually understand.

It is off, and off means untouched

Everything here is off out of the box, and when it is off the audio is bypassed sample for sample — not passed through a chain set to neutral. An install that never opens this section sounds bit-identical to one built before the feature existed, and costs nothing per sample. That is deliberate: nobody should discover new processing on a working system they did not ask to change.

The chain, in order

Signal passes through in this order, per output: pre-gain → up to eight tone filters → delay → limiter → hard ceiling. The ceiling is always there, whatever the limiter is set to, and when it has to act it is counted rather than hidden.

One ordering detail worth knowing: the processing runs after the multi-room tap. A room listening over a Multilarm link therefore hears the programme audio, not this device's amplifier correction and speaker delay — which would otherwise be corrections for a building it is not in.

# A starting point for speech through ceiling speakers:
highpass,120,0,0.707;peak,3150,4,1.2;highshelf,8000,-6,0.707

# main output on time, second held 35 ms, third held 70 ms
0|35|70

Checking it is working

The diagnostics report, per output, the worst gain reduction the limiter actually applied and how many periods hit the hard ceiling, since the last read. That distinguishes a threshold doing its job occasionally from one fighting the material all day — and a non-zero clip count means something upstream is too hot, whatever the limiter is doing about it.

Every rejected EQ spec and every failed setting is written to Multilarm.error.log with the prefix MaOutputDsp:.

Play to This Device

Turn a Multilarm into something a phone, tablet or PC on the same network can send sound to — a playlist, a recorded message, a radio app — without anyone touching the Multilarm itself. It appears in the “play to” or “cast” list of any app that speaks DLNA.

What it is, exactly

Multilarm advertises itself on the local network as a UPnP AV / DLNA MediaRenderer (a DMR). Anything that can send to one — Android's built-in cast picker in many media apps, VLC, BubbleUPnP, foobar2000, Windows' “Cast to Device”, Kodi, Plex, most NAS media servers — will see it by name and can start, pause, resume, stop and set the volume.

What it deliberately is not

Those are honest answers rather than a roadmap. Where a phone must reach the speakers over Bluetooth, pair it with the operating system on the machine running Multilarm and let the paired audio arrive on the sound card's line input — Multilarm then treats it as an ordinary input, and nothing in it needs a Bluetooth stack of its own.

Turning it on

Four settings, config Group 22 — Play to this device, all off out of the box. A device that has never been told about this opens no port and advertises nothing.

Where cast audio sits

What a phone sends becomes the background sound, in exactly the place the Virtual Radio occupies. Everything that already governs background audio therefore governs this too, with no new rules to learn: scheduled items and announcements duck it, P1/P2/P3 priority interrupts it, the volume profile shapes it, and an emergency overrides it outright. A phone can never make the building quieter than the schedule intends.

Casting and the Virtual Radio want the same channel, so whoever asked most recently wins: starting a cast stops the radio, and when the cast stops the radio resumes at its next tick.

Checking it is working

Press Ctrl+I for a one-line summary, or read cast in GET /api/status on the Web Remote — the name being advertised, the port, whether anything is playing, and how many sessions have been served since start-up. Every start, stop and refusal is written to the log with the line prefix Play to this device:.

If a phone cannot see it: discovery is a multicast message, and many wireless networks block multicast between clients or put phones on a guest network that cannot reach the server. That is a network setting rather than a Multilarm one, and it is the cause in nearly every case.

Date-Scoped Config Switching

When a day is wholly different — Ramadan, weekends, a winter timetable — swap the entire config file automatically at midnight, rather than overloading one file with rules.

# Ramadan config all of March; weekend config on Sat/Sun otherwise:
multilarm.ramadan.xml,00:00-23:59,m=3|multilarm.weekend.xml,00:00-23:59,w=sa,su

# Friday config from a subfolder; winter config from AppData:
{app}\configs\multilarm.friday.xml,00:00-23:59,w=fr|{data}\Multilarm\multilarm.winter.xml,00:00-23:59,m=12-2

Important behaviours

• Because evaluation is daily, use the date filters (m=, d=, w=, nw=, ld) to pick days; time ranges other than full-day rarely matter.
• The AlternateConfig field is never overwritten by a switched-in file — this prevents switch loops.
• Missing/unreadable files log a warning and fall back to default; the process never crashes.
• Live edits while an alternate file is active are saved back to that file — so changes made on a Ramadan day update the Ramadan config, not the default.
• The active file shows on the Ctrl+I status and in /api/status as activeConfig.

Monitoring, Logs & Diagnostics

How to see what Multilarm is doing — live and after the fact.

Live status

Press Ctrl+I for a runtime summary: uptime, current audio, radio state, volume & profile, active config, Web Remote (port/firewall/auth/URL), Hub state & peer count, Cloud Relay (connection + recent log), and the next alarm. The console title bar shows a live countdown to the next alarm, and output is colour-coded — alarms red, radio cyan, speech yellow.

Log files

A rolling in-memory buffer (up to 500 entries) is viewable with Ctrl+D or via GET /api/logs.

Startup health check

On boot, Multilarm validates every configured audio path and reports per-folder file counts (e.g. AlarmPath [C:\Adhan]: 42 file(s) found), flagging missing or empty paths as warnings. At midnight it logs the new day's schedule load.

Built-in diagnostics (check-up battery)

Multilarm can test itself and tell you what is working and what is not — designed for commissioning a new site and for checking a deployment after changes. Around 30 checks run in sections (Deployment · Clock & schedule · Audio · Cloud & network · Hardware) and each result is PASS / WARN / FAIL / SKIP with a plain-language "what to do" hint on every problem. The standard battery is silent and safe — it decodes audio files without playing them and never moves a relay.

• On a phone or laptop (recommended for site visits): open http://<device-ip>:6580/diagnostics (also linked from the device dashboard). Press Run checks for the silent battery, or Guided commissioning mode to also step through the audible tests one at a time — test tone on every output, alarm sample, live spoken announcement, microphone loopback (you record 3 s and hear it back), relay pulse and bell — answering Heard/seen it? Yes/No after each. Then Download report (JSON) or Print report for the commissioning record.
• At the device console: press Ctrl+Y for the silent battery inline.
• From a script / after deployment: run Multilarm --diagnose (add --json for machine-readable output, --section <name> to limit it). The exit code is the number of failed checks, so installers and deploy pipelines can gate on it. If the program is already running, the command automatically tests the live instance.
• Remotely, before a site visit: the cloud dashboard's Diagnostics card runs the silent battery on the device and shows the same report (owners only).

Commissioning engineers can then import the downloaded report into a job in the Commissioning Portal — machine-verified checks pre-fill the checklist (your own answers are never overwritten) and the customer's certificate gains a "Device self-test" summary line.

Automatic fault detection

Between check-ups the device watches itself continuously — no setup needed. A background sweep (every 5 minutes) plus live error monitoring detect problems in the program (repeated errors, speech engine not ready, duplicate processes), peripherals (output device unplugged or shuffled, relay board unresponsive, emergency button unarmed, disk low, missing audio files) and the network (cloud connection failing, device token rejected, MQTT broker unreachable). Detected faults:

• appear as an Attention row on the cloud dashboard and a red banner at the top of the /diagnostics page (with first-seen time and occurrence count);
• are included in every status update, diagnostics report and support bundle;
• trigger an alert email for serious (FAIL-severity) faults when Email Alerts are enabled;
• clear themselves automatically when the problem goes away — each raise/clear is also logged as a [diag] line in Multilarm.error.log.

Auditing

Remote actions are recorded in two ledgers: the cloud database audit_log (intent — who asked) and the device's Multilarm.audit.log (execution — what actually ran). Together they give a tamper-evident trail across the boundary.

Reporting a bug

Multilarm Network

The companion that watches the network your device sits on — and tells you whose fault it is when a site stops working.

What it is for

When a site goes quiet, the expensive question is not what broke but whose problem is it. Multilarm Network answers that: it separates a fault in Multilarm from a fault in your network from a fault at your internet provider, and says so in plain English rather than leaving you to interpret a graph.

It does nothing until the device is paired

With no CloudDeviceToken, the monitor logs one line and sleeps: no scanning, no network traffic, no cloud calls. That is precisely why it can be installed everywhere by default. On an unpaired machine it costs you an idle background process and nothing else, and it starts working by itself the moment the device is paired — there is nothing to go back and switch on.

What it reports

Every device it finds is listed with its address, manufacturer, published network name where there is one, and a best guess at what kind of thing it is. Manufacturer names come from a copy of the official IEEE hardware registry (about 53,000 manufacturers) built into the program, so naming works with no internet at all and nothing about your equipment is sent anywhere to identify it.

Where to see it and what to tune

Everything appears in the cloud dashboard under the device's Network view, and anything serious reaches you through the alerting you already use — email, Telegram and phone notifications — with nothing extra to configure. From the same place you can turn monitoring off, change the scan and speed-test intervals, set quiet hours so the speed test avoids your busiest period, enter the speeds your plan promises, and choose which devices go on the watch list.

Limits, deliberately

• Read-only. It cannot change, block or disconnect anything on your network. There is no remote-control surface at all.
• It does not read your traffic — only which devices are present and whether they answer.
• Unprivileged on Linux and the Raspberry Pi, and it opens no port for anything to connect to.
• No AI. Every verdict comes from a fixed rule set, so the same situation always gives the same answer, and nothing about your network goes to any AI service.
• It can never interfere with an announcement. It is a separate process from the audio engine on purpose — a scan that stalls cannot delay a prayer time, a bell or an emergency broadcast.

Turning it off

Switching monitoring off in the dashboard stops the scanning while leaving it installed, which is almost always what you want. To stop the background service too: on Windows set the Multilarm Network service to Disabled in Services; on Linux or a Pi run systemctl --user disable --now multilarm-netmon, or sudo systemctl disable --now multilarm-netmon on an appliance-style install. The main Multilarm service is unaffected either way.

Incidents & Drills

The response plan you write once, calmly — and fire in one tap when there is no time to think.

Where it lives

In the cloud dashboard, under Incidents in the top bar. It sits alongside the existing Notify People card, which is unchanged — a one-off message to everybody still works exactly as it did. An incident is the structured version for the situations where the order people are told in, and the proof of what happened, both matter.

What a template holds

• The message — subject and body, written in advance instead of typed under pressure.
• An escalation ladder — who is told first, and which group is added after how many seconds if nobody has acknowledged. Wardens immediately, duty managers after two minutes, everyone after five. Nobody who has already acknowledged is contacted again.
• Which devices react — a scenario to play on the speakers and a line of text for any connected display. The display's previous message is restored when the incident closes.
• When to stop — how many acknowledgements end the escalation, whether to re-send the current stage on a timer, and how long before the incident closes itself.

Starting one

Each template offers three buttons. Start runs it for real. Drill runs the whole chain but prefixes every message and display line with DRILL — THIS IS A TEST. Silent drill notifies people but plays nothing and changes no display, so the human chain can be tested during business hours. The Android app can start the same incident, which makes a phone in a pocket a panic button.

Recipients acknowledge with one tap on a link in the message — no login. The Incidents page shows the current stage and the running acknowledgement count.

The after-action report

Every incident, drill included, produces a printable report: when it started and who started it, every stage that fired, everyone contacted on every channel, who acknowledged and when, what played and where, your closing note, and a full time-stamped ledger. Each incident keeps its own copy of the plan it ran, so editing or deleting a template later never rewrites history.

Desktop Alerts

The same warning the speakers give, on every screen you point at the device — and a way for whoever is sitting there to say “seen it”.

Speakers reach people who can hear them. A machine room, a call centre in headsets, a deaf colleague, a night shift with the volume down — those people need the message somewhere else. Every Multilarm device publishes a small notice board of what is happening right now, and three different things can read it.

Any screen with a browser

Open http://<device>:6580/alert on a spare monitor, a tablet, a signage player or a kiosk browser. It stays quiet and dark until something happens, then fills the screen. Nothing to install, no cloud account, no internet — it talks only to the device on your own network. An Acknowledge button appears when the alert asks for one.

Windows: the tray companion

The Multilarm tray app watches every instance on the machine and now watches their alerts too. A live alert takes the screen over; when the device says it is finished, the takeover closes itself. It never steals your keyboard, so a half-typed message survives it.

• Take the screen over during an alert — on by default; turn it off and the tray goes back to a balloon tip only.
• Show a banner instead of full screen — a strip across the top, for a till or a control room that must stay usable.
• Play a tone on a new alert — off by default. The building's speakers are the alarm; a room of chirping PCs helps nobody.

Linux: the alert agent

multilarm-alert-agent.sh does the same job with whatever the machine already has — a kiosk browser on a desktop, a notification if there is no browser, and a message to every terminal on a headless box. It needs only sh and curl, and runs happily as a systemd --user service.

What sets an alert off

• The device — the emergency button, or an emergency started from the web panel. No cloud account is involved at any point.
• A cloud incident or drill — including a silent drill: silent means make no sound, not say nothing.

Acknowledging

An acknowledgement from a screen counts towards the incident's target exactly like a tap on an emailed link, and it is listed in the after-action report with the machine it came from. Raised while the internet is down, it waits on the device and is delivered when the line comes back.

Sample Deployments

Multilarm ships with four worked example configurations plus two ready prayer calendars. Copy a sample's Multilarm.config.xml into your program root (and extract its audio folders) to start from a real-world setup.

Prayer calendars

• Default — UK (Sheffield): a full-year prayer-time calendar, used out of the box.
• Bangladesh: drop-in replacement config with Bangladesh prayer times against the default Adhan audio.

The Configuration Generator

A visual editor for Multilarm.config.xml — every one of the 97 settings with its own reference text and validation, plus a set of sub-tools that build the hard values for you: a whole year of prayer times from your coordinates, a calendar import, a visual schedule grid, and point-and-click builders for every rule field. You never have to hand-edit XML, and you never have to memorise a rule grammar.

Which tool for which job

Four ways to open it

• On the web — multilarm.com/multilarmconfiggenerator.html, nothing to install.
• Offline file — MultilarmConfigGenerator.html ships with Multilarm; open it in any browser with no internet at all. (Opened straight from disk, browsers block location auto-detect — type your coordinates instead.)
• On the device — the Web Remote serves the same page at /config, so you edit against the running instance.
• In the cloud dashboard — the same editor and the same guided wizard when you claim or configure a device.

Getting a config in and out

• 📂 Load Config XML — open an existing Multilarm.config.xml and every field, list and rule editor fills itself in.
• 💾 Save Config XML — writes the file. Every tag is always written, whether you touched it or not, so a saved file is always complete and never half-migrated.
• ↺ Reset to Defaults — back to the shipped defaults.
• Live Connection — type the device address (e.g. http://192.168.1.50:6580) plus the Web Remote username and password if you set them, then ⬇ Load from Multilarm to pull its current settings, and ⬆ Save to Multilarm to push your changes back. The device notices the change and applies it in about two seconds — no restart, except for the four restart-required fields.

A sticky bar at the bottom of the page keeps Save, Reset, Localhost and Import .ics in reach however far you have scrolled.

Working the form

• 20 collapsible sections covering all 97 settings, with Expand All / Collapse All. Fields are numbered, and the numbers match this manual’s configuration reference.
• Every field has a Help button opening its full reference — what the value means, its type, range and default, worked examples, and the console shortcuts that test it.
• Validation as you type — out-of-range numbers are called out with the allowed range rather than silently saved.
• Path-tag buttons on every path field insert {app}, {home}, {docs}, {data}, {local} and {temp}, which resolve at runtime — the way to write one config that works on Windows, Linux and a Pi.
• List editors for multi-value fields: alarm folders as rows, file formats as tags, mirror devices as removable pills (with a raw pipe-delimited box underneath for bulk paste).

The schedule (field 9) — five ways to fill it

DateAndTimeData is the one field that carries a whole year, so it has a toolkit of its own. A Mode badge above the box always shows which format is in force — Full Year, or the day/week/month recurrence you picked in section 1 — and every tool below writes in that format, reading your DateIdentifier, DateDelimiter and TimeDelimiter live so custom delimiters are respected.

1. Raw Text

The string itself, editable. Paste a timetable straight in. A panel underneath watches for duplicate dates and turns red if a date appears twice, with a Merge & dedupe duplicates button that folds them into one entry and drops repeated times. Format Help opens the full grammar for every recurrence mode with examples.

2. Visual Builder

The same data as a grid: one row per date, one column per alarm slot. Navigate month by month, set how many time columns you want, and fill a whole column down the month in one go. + Fill Month and ▶▶ Fill Year create the empty rows for you; 🗑 Clear Month empties one. ↶ Undo and ↷ Redo cover every edit (with a counter, so you can see how far back you can go), and ↓ Sync to Raw / ↑ Re-parse Raw move between the two views whenever you want.

3. Quick Entry Builder

Build one entry at a time: pick the date (or day-of-month, or weekday — it follows your recurrence mode), add times one by one, and ✓ Insert Entry. Also here:

• Bulk Add — paste comma-separated times and they all join the list.
• ⇅ Sort All — put every entry in order.
• ± Apply to All — shift every time in the whole field by ±N minutes. Times wrap correctly past midnight. This is the one-click fix for a clock correction or a seasonal adjustment.

4. Calendar Quick Add

The same times across many days at once. Choose the scope — whole year, a single month, or a custom date range — then narrow it by weekday with one click (All, Mon–Fri, Weekend, Clear). Add the times (or paste them), choose Merge (keep what is there, add these) or Replace (clear the matched days first), and ✓ Apply to Matched Days. This is how a school year of bells, or a Ramadan-only pattern, goes in without typing 300 lines.

5. Generate or import it

The Salat Calendar Generator (below) computes a year of prayer times from your coordinates, and Import .ics (below) reads a calendar file you already have. Both write straight into this field.

Prayer times — the Salat Calendar Generator

You do not need a prayer timetable from anywhere else. The generator works your times out from your own location, in the browser, with the calculation library built into the page — nothing is fetched from any prayer-time website, so it works with no internet connection at all.

1. Enter your latitude and longitude, or tap 📍 Detect Location. (Auto-detect needs the page served over HTTPS or localhost; opened straight from disk, browsers block it — type the coordinates instead. Sheffield, UK is 53.3833 / -1.4667.)
2. Choose the year.
3. Choose your calculation method — MWL (Muslim World League), ISNA (North America), Egypt, Makkah (Umm al-Qura) or Karachi — your Asr madhab (Shafi or Hanafi, Hanafi giving the later Asr) and your high-latitude rule.
4. Press Generate Calendar, then ✓ Insert → Replace Field 9 to write the year into DateAndTimeData, or + Append to Field 9 to add it after existing entries.

You get all six daily times — Fajr, Sunrise, Dhuhr, Asr, Maghrib and Isha — in the same *D-M|HH:MM|… format the shipped configs use. Before you insert anything you can ▶ Show/Hide Calendar Preview to read the generated year month by month, and there are three ways to take it away with you:

• 📋 Copy Raw — the raw string to the clipboard.
• ↓ Download .txt — the same as a file.
• 🖶 Print Calendar PDF — a clean printable timetable, ready for the notice board.

Import .ics — a calendar you already have

If your schedule already exists as a calendar — a school term timetable, a shift rota, a booking calendar exported from Outlook, Google Calendar or Apple Calendar — you do not need to retype it. 📅 Import .ics reads the file and turns the events into alarm times.

1. Choose the .ics file. Repeating events are fully expanded, so “every Monday during term” becomes each actual date.
2. Pick the years to import. If the file spans several, you get a year list (with Select earliest, Select all and Clear). Nothing is ticked by default — you choose deliberately.
3. Set a default time for all-day events. Events with no time of their own (and each day of a multi-day event) use this.
4. Choose how it merges with what is already in field 9: Replace (clear and write), Append (keep existing dates, add new ones, skip duplicates), or Merge (for a date that exists in both, combine the times).

You can also let the import set up the fields around the schedule — each one optional, each one a tick box:

• Auto-set the Recur mode (day / week / month / year) to match the shape of what you imported.
• Set announcement text (20) from the event summaries, so each event announces itself.
• Append TextDataRules (22) so dates that do not fit the usual pattern still get their own wording.
• Set FormatInEffect (10) to match the largest number of times any day needs.
• Append OffsetRules (11) for time variants.
• Append AlarmIndexRules (15) so different event categories play from different audio folders.

Rule builders — compose, preview, add

Multilarm’s rule fields are compact, which makes them powerful and easy to mistype. Every one of them has a builder: you pick the parts from dropdowns, watch the generated rule string appear live underneath, and only then add it to the list. You can always still type the raw value if you prefer.

All of them share the same filter vocabulary, so learning it once covers everything: m= months, w= weekdays, d= day of month, nw= the Nth weekday of a month, ld the last day, t= a time or time range, slot= which alarm slot — and a leading ! negates any of them. The full grammar is in Rules & scoping.

Announcement text placeholders

The announcement text field (20) has insert buttons for the placeholders Multilarm fills in when it speaks: #ALARM+1# and #ALARM+2# (the time of the next alarm and the one after), #TIMETOALARM+1# and #TIMETOALARM+2# (how long until them), and #NOW# (the current time). Click rather than remember.

Audio sequences — several files for one announcement

The last section documents the source-spec grammar, which is what lets one alarm play more than one file — a bleep before the adhan, a three-tone motif, a different recitation each day. There is no list to fill in: the grammar lives inside the alarm-folder and chime-path fields themselves.

• A path can be a folder, a single file, or a folder plus a filename pattern (bell*.mp3).
• >one picks one at random (the default, so nothing changes for existing configs), >all plays every file in filename order, >shuffle plays them all in a fresh random order, and >seq plays the next one each time and remembers its place across restarts — a different recitation every day.
• *count caps how many files come from that path.
• Chain sources with a plus sign surrounded by spaces: {app}\Adhan\Bleep\intro.mp3 + {app}\Adhan plays the bleep, then a random adhan, as one announcement.

Two safety settings sit with it: SequenceGapMs (74) is the silence between the different files inside one announcement — not to be confused with AlarmRepeatGap, which is the silence between repeats of the whole thing — and SequenceMaxSeconds (75) is a hard ceiling on one announcement, ten minutes by default, so pointing >all at a folder of 400 tracks cannot hold the speakers for hours.

Guided setup wizard

New to Multilarm, or setting up a device for a common use case? Pick a use case from the “Start from a preset” bar at the top of the generator (or click ⚙ Guided setup…) and the guided wizard opens straight away — it’s the same wizard the Cloud dashboard runs when you claim a device. Instead of facing every field at once, the wizard asks a short series of plain-English questions and fills the form in for you:

1. Pick what the device is for — Mosque / Masjid, School / College, Care home, or Office / Factory.
2. Answer a few common settings, grouped into a handful of steps — for example the device name and announcement voice, master volume, bell / signal times (add each time and choose which days they ring), how many zones you have, quiet overnight hours, and whether an emergency broadcast can be started remotely.
3. Set day preferences per rule — every schedule the wizard builds (bells, background audio, quiet hours) has its own independent day choice: Every day, Only these days (e.g. Mon–Fri), or Every day except (e.g. dim the volume overnight except at weekends). So different rules can run on different days. Each zone gets its own day choice too, so one wing can be addressable only on weekdays while another is every day.
4. Go further when you need to (all optional, off by default): give each bell its own pulse length (e.g. a longer assembly bell), add a second quiet-hours tier (e.g. evening 60% then overnight 30%), and choose background audio from a local folder or an online stream URL.
5. Review & apply — the wizard shows exactly which fields it will set (everything else stays at its default), then fills them into the form.

Behind the scenes the wizard turns your answers into the right values automatically — a list of bell times plus a weekday choice becomes a Bell Schedule, a quiet-hours window becomes a Volume Profile rule, and a zone count seeds the zone targeting rules and tells you which relay board you need (a 4-channel board covers 2 zones; 3–4 zones need an 8-channel board). It is a starting point, not a mode: once applied, every field is ordinary and fully editable, and you can still use the quick Apply preset button if you just want the defaults with no questions.

The ten presets

Each use case in the “Start from a preset” bar is a complete, sensible starting configuration, and each tells you what it expects you to do next:

Fill defaults only next to the wizard button drops the preset’s raw values into the form without asking any questions — for when you intend to hand-tune everything anyway.

Two names for everything

Every setting has two correct names: the one the configuration file, this manual and the support runbook use (“48. VolumeProfileRules”), and the one you would use if you had just plugged in a Raspberry Pi (“Quiet hours”). The generator shows one at a time. The 💬 Plain English button at the top switches to 🔧 Expert, which puts the field numbers and internal names back exactly as they were — hover any plain label to see its number without switching. The choice is remembered on that computer.

It is a display setting and nothing more. It changes no field, no value and no saved file: a configuration written in plain-English mode is byte for byte the same file as one written in expert mode. Help panels always keep the numbers, because that is what support and the documentation quote back to you.

The same plain vocabulary is used across the rest of the product:

Things worth knowing

• It preserves your advanced rules. The visual editors edit the default line of scoped fields and keep your per-day scope lines intact in the raw value, so a config that uses advanced rules round-trips safely.
• Every tag is always written. A saved file is complete, so a config saved here can never be missing a setting a newer build expects.
• Location auto-detect needs HTTPS. Opened as a local file, browsers refuse the location request and report it as denied. That is normal — type your coordinates.
• February should have 29 days in a full-year schedule, so leap years are covered.
• Apply daylight-saving shifts after the changeover dates — or turn on UK Daylight Savings (8) and let Multilarm do it.
• Cleaning a pasted timetable is easiest in a text editor or Word before it comes anywhere near the tool (use ^p for a line break in Word’s Find/Replace).
• Four fields need a restart to take effect, whichever way you save: Web Remote enabled, Web Remote port, playback device and record device. Everything else hot-reloads in about two seconds.

Music Library, Playlists & Rotation

The library

Point Multilarm at one or more folders and it reads what is already in your files — title, artist, album, genre, year, BPM — along with the length, sample rate and channel count. WAV files are also measured for peak and average level, clipping, and silence at the start and end, so you can find the one track that is twice as loud as everything else before a room does.

Your files are never modified. When you correct a title or set a cue point, that correction is stored in Multilarm's own index, not written back into your audio. If another program manages the same library, nothing Multilarm does can damage it. Reset on any track throws the correction away and goes back to whatever the file itself says.

Scanning is incremental: a file whose size and timestamp have not changed is skipped, so a second scan of a large library is quick. You can cancel a scan at any time, and a cancelled scan never removes anything from the index.

Cover art is found, not copied. When a track carries an embedded picture, the scan records where in the file it sits rather than pulling the image out — so a five-thousand file scan is not spent decoding pictures nobody has asked to see, and there is no thumbnail cache to go stale when you re-tag your library. The dashboard fetches a cover straight from the audio file the moment it needs one. MP3, FLAC and MP4 art is served this way; Ogg Vorbis art is detected but not served, because it is stored encoded inside a comment. A track with no reachable picture simply shows a placeholder.

Four reports worth running

• Unreadable — files that could not be decoded. Usually a corrupt download or a format nothing supports.
• Missing metadata — no title or no artist. These are the tracks that make a now-playing display look broken.
• Clipped — recorded too hot. On a PA these are what people describe as “harsh”.
• Duplicates — the same track in two places, which is why it seems to come round too often.

Playlists

A static playlist is a running order: these tracks, in this sequence. A smart playlist is a description — “genre is Ambient, and it has not played in the last fourteen days, longest first, limit thirty” — that Multilarm works out fresh every time it is asked. You can match on genre, artist, album, title, comment, track type, path, year, BPM, duration, play count and days since last played.

Playlists can contain other playlists, up to six levels deep, so a “Daytime” list can be built out of “Morning”, “Lunch” and “Afternoon”. A playlist that would end up containing itself is refused when you save it, rather than accepted and then looped over forever — and a refused save leaves the playlist exactly as it was, so nothing is half-changed behind the refusal. A smart rule that names a field or an operator Multilarm does not have is refused the same way, with the valid ones listed, instead of being quietly turned into a rule that matches something else.

Two limits can be set on any playlist, and either may be left at zero. A count limit keeps the first N tracks; a duration limit keeps as many as fit inside N minutes. Set both and whichever bites first wins. A track whose length has not been measured yet counts as zero rather than being dropped — a slightly short hour is recoverable, a missing track is confusing.

An entry can also be marked play once. It plays, and is then taken out of the playlist and the file saved. The removal happens after it has gone out, never before, so if the machine loses power between the two you get a repeat rather than a gap. Use it for the one-off notice that should not still be in the list next week.

Freezing a smart playlist pins what it resolves to right now. Use it before an event that has to be identical every time it is rehearsed — a freeze means the running order cannot change under the people rehearsing it. Unfreeze to let it move with the library again.

Rotation

The rotation picks what plays next across several playlists at once, each with a weight, so you can say “mostly this, occasionally that” without maintaining one giant list. Three separation rules keep it from sounding repetitive:

• Do not play the same track within N minutes (default 180).
• Do not play the same artist within N minutes (default 45).
• Do not repeat anything within the last N tracks (default 20).
• Do not play the same album within the last N tracks (default 0, meaning off). Six to ten is the useful range — that is roughly where a record stops announcing itself. It is off by default so that a rotation already running on your device behaves after an update exactly as it did before.

An interrupting playlist fires on a count or a clock — every 20 tracks, or every 30 minutes, optionally only between certain hours. That is the jingle, the station ident, the hourly safety reminder.

Underneath all of that sits a safety folder. It is used only when the rotation has nothing at all to apply a rule to — no playlists, none enabled, or nothing in them that still resolves to a file, which is what a wiped index or an unmounted music share looks like. Multilarm then reads that one folder directly, without the library index, and plays something from it. The reason is written to the log every time, so the fault is visible rather than merely survived. Leave it blank and nothing changes.

Slots: different music at different times of day

A rotation on its own plays the same programme at eight in the morning and at five in the afternoon. A slot says: between these clock times, on these days, the rotation draws from these playlists — and hands back to the ordinary rotation the moment it ends. Slots may run across midnight, and where two overlap the one with the higher priority wins; on a tie the narrower window wins, because a two-hour exception inside an all-day slot is always meant to be the exception.

• Intro and outro playlists — an ident as the slot opens and another as it closes, without those lists sitting in the rotation for the rest of the day. Each fires once. If there is nothing playable in it the ident is missed rather than retried, because an ident that retries becomes a loop.
• Autoload — the slot works out its content a set number of seconds before it goes on air (a minute, by default), so the first track starts on time instead of after a library query. On a small machine with a cold index that is the difference between a clean handover and a couple of seconds of nothing.
• Linked slots — give two slots the same link key and they share one running order and one position in it, so “the nine o’clock hour, repeated at three” genuinely repeats instead of rolling the dice again.
• Overrun — on by default, meaning the last track of a slot is allowed to finish past the end. Turn it off and the slot will not start a track that cannot finish in time. If nothing is short enough it starts one anyway and runs long: a slot boundary never outranks the rule about silence.

What is on air

Whatever starts playing is announced in one place, so the log, the outbound webhooks, the dashboard and the public page can never disagree. Open /onair on the device for a plain page showing the current track and how far through it is — suitable for a screen in a foyer. That page and its /api/nowplaying feed carry the track details only: never a file path, a folder, or anything else about the installation.

The play log

Every track that goes out is written to a CSV, one file per month, under a PlayLog folder beside your config. You can export a date range in a plain format, or in the shape that PRS, PPL or SoundExchange returns ask for. Announcements are left out of the music totals so a return is never overstated, and fields Multilarm genuinely does not know — ISRC, label, service name — are left blank rather than guessed.

Podcasts, in and out

In: subscribe to an RSS feed and new episodes are downloaded and indexed automatically, so a daily bulletin or a weekly talk can go straight into a playlist without anybody copying files. Downloads are size-capped, must be audio, and are checked before they are used. Nothing downloaded plays by itself — a playlist or a schedule still has to ask for it.

Out: turn on publishing and whatever scheduled recording has captured is offered at /podcast.xml as an ordinary podcast feed, so an assembly or a talk can be handed to whoever missed it, in any podcast app.

Listening on the LAN

You can optionally let somebody on the same network hear what the PA is playing, in a browser, with nothing to install: turn the listen endpoint on, set a listen key, and open /listen on that port.

Two refusals are deliberate. It will not open itself to the network without a listen key — it checks and refuses rather than hoping the connection fails. And it will not start while multi-room is sending, because both need the same single audio tap inside the engine; stop one to use the other.

Three streams, so a phone on a weak signal is not stuck with the full one. Alongside /listen.wav there is a mono stream at half the bandwidth, and a low-bandwidth one at a quarter. They carry the same audio; a listener picks whichever their connection can hold, and a stream nobody is on costs the device nothing.

Quiet does not have to sound like a dead line. Point the listen endpoint at a short WAV and any gap in the programme carries that instead of silence, on a loop. It is heard only by listeners — the building itself stays quiet, which is the whole point of a hold loop on a PA. The file has to match the engine's sample rate and channel count exactly, and be 16-bit WAV and under a minute; anything else is refused with a note rather than quietly resampled into something that sounds wrong. To find out what to match, read the listen status before you start it — it reports the engine’s own sample rate and channel count whether the endpoint is running or not, so the file you build from those two numbers is accepted first time.

You can see how many people listened, without knowing who. Connections, peak, listening time and a “unique today” figure are kept per hour and per day. No address is ever written to disk, nothing is sent anywhere, and the play log is deliberately not joined to it. The “unique” count uses a salted fingerprint held in memory for the day only — enough to stop one listener counting five times, and not built to identify anybody.

Putting it on your own site. /player.html is the player on its own, sized to drop into an iframe. /schedule.html shows the week exactly as your music slots already describe it — it is derived, so it can never disagree with what actually plays. If you point the endpoint at a stylesheet, both pages pick it up, so an embed can be made to match the site around it.

Listen again

Anything scheduled recording has captured can be listed and played back in a browser, and so can any track in the library — served from where the file already sits, with nothing copied or converted. Seeking works, so somebody can jump to the part of an assembly they wanted rather than sitting through it.

Where everything is kept

All of these sit beside your config file, and all of them are optional. A device that has none of them behaves exactly as it did before this feature existed — nothing here changes how alarms, announcements or the existing radio folder work.

Command-Line Arguments

Behaviour

• A relative --config path resolves against the program folder; a missing parent directory is created.
• With no --config, the default Multilarm.config.xml is used.
• A non-default config shows in the console title: Multilarm <version> [<config-name>].
• The chosen file is what hot-reload watches, what config POSTs write to, and what AlternateConfig switches sit on top of.
• Unknown flags print help and exit non-zero.

Tips & Troubleshooting

Everyday tips

• The Multilarm website (docs, Cloud dashboard and Configuration Generator) has a Light / Dark toggle in the bottom-right corner — switch to Light mode if a screen is hard to read in bright sunlight. Your choice is remembered per device/browser.
• The website also has a site-wide Search — the button in the bottom-right of any page, the Search link in the navigation, or the / key. It searches every page (titles, headings and text) and works offline.
• Alarms always win — they interrupt radio, quotes, ambience and TTS instantly, and everything resumes after. No timing config needed.
• Volume is app-level; set the OS volume to a comfortable max first, then trim with Volume.
• CrossfadeMs of 1000–2000 ms gives the nicest radio transitions; 0 switches instantly.
• Hot-reload lets you tune Volume, CrossfadeMs, AlarmFadeInMs, profiles and quote/ambience settings live.
• For phone control on the LAN, ensure phone and device share Wi-Fi, find the device IP (ipconfig / hostname -I), and browse to http://<ip>:6580/.
• On a Pi, the Web Remote means you never need SSH or a keyboard — manage everything from your phone.
• The /api/schedule endpoint feeds prayer-countdown displays and home-automation dashboards.
• In the cloud, use Push Config to sync prayer times across many devices, and Config Compare to find drift between two devices.

Troubleshooting

Frequently Asked Questions

Does Multilarm need an internet connection?

No. Every core function — scheduling, playback, even neural text-to-speech — runs fully offline on the device. The cloud is an optional convenience for remote control, never a requirement.

Can it run on a Raspberry Pi?

Yes — that's a primary target. It runs headless on ARM 32/64-bit, auto-starts at boot via systemd, and is controlled entirely from your phone through the Web Remote.

Is it only for the Adhan?

No. The same engine runs school bells, factory shift sirens, care-home announcements, hotel/gym background music and hospital paging. See Use Cases.

How many speakers / zones can it drive?

Mirror one schedule to any number of output devices (frame-aligned), and run any number of independent zones side-by-side with --config. See Mirroring and Multi-Zone.

Can the imam / a member of staff speak live over the PA?

Yes — Push-to-Talk passes a live mic straight through the speakers, and Voice Broadcast records-then-broadcasts with confirmation.

Do I have to record words for text-to-speech?

No — use the built-in Kokoro neural voice. Or record only the words you want in a specific human voice and let KokoroFillsWords cover the rest.

How do I handle Fridays / Ramadan / holidays?

Small differences: use per-day rules & scopes. Whole different days: use config switching. Both are automatic.

Is it free?

It's free for individual, non-commercial personal use. Any business, institutional or commercial use requires a commercial licence. See Licensing.

What audio formats are supported?

MP3 (and MP1/MP2), WAV, OGG, FLAC, AIFF, and M4A for radio — plus online streams for the virtual radio.

Is any of it GPL-licensed?

No. The audio engine (miniaudio + libFLAC) and the neural TTS (Kokoro + dictionary G2P) are all permissively licensed — relevant for commercial-deployment audits.

Licensing, Contact & Credits

Licence summary

Multilarm is proprietary software © 2026 Ali Muhammad (multilarm.com). You get a free, non-exclusive licence for personal, non-commercial use — private projects, personal productivity and learning, with no commercial benefit and no redistribution.

The source code is proprietary and confidential; reverse-engineering and redistribution are prohibited. The software is provided "as is" without warranty. The plain-language summary above is for convenience only — the full agreement below is the operative text.

Full licence agreement

Contact

• Author: Ali Muhammad
• Email: hello@multilarm.com
• Web: multilarm.com/multilarm
• Cloud dashboard: multilarm.com/cloud

When reporting bugs, please include Multilarm.error.log and Multilarm.config.xml.

Support the project

Multilarm is built and maintained by one person. If it serves your community, a donation helps keep it going — PayPal @AliMuhammadK62.

Acknowledgements

With thanks to my wife and children, to the sites hosting the Adhan and bleep recordings, and to the open-source projects behind the engine — miniaudio, libFLAC, Kokoro and OpenPhonemizer.

This help file documents Multilarm v1.2026. It is generated from the current source and supersedes earlier Multilarm_Documentation revisions. © 2026 Ali Muhammad · multilarm.com.

Downloads

Where to get Multilarm, its resources and its tools. The official home for all downloads is multilarm.com/multilarm.

Application binaries

Installer

• Windows (MSI): the recommended Windows install — bundles the .NET runtime, the audio engine and the default audio library. See Installation.
• Linux / Raspberry Pi: the one-line installer sudo curl -s -L https://bit.ly/multilarm-linux | bash.

Configuration & samples

• Configuration Generator — MultilarmConfigGenerator.html, the visual editor (see Configuration Generator).
• Default config — Multilarm.config.xml with the UK (Sheffield) prayer calendar, for the application root.
• Bangladesh prayer times — drop-in Multilarm.config.xml for the application root.
• Sample applications — the daily / weekly / monthly worked deployments (see Sample Deployments).

Checking that a download is genuine

Multilarm is only ever distributed from multilarm.com, winget and Chocolatey. A copy from anywhere else is not ours, whatever it is called.

Every release file is listed with its SHA-256 fingerprint at multilarm.com/multilarm/SHA256SUMS. That list carries a digital signature of its own, made with a key kept off the web server — so even someone who broke into the website could not publish matching fingerprints for a tampered file.

To check a file you have downloaded:

• Windows: certutil -hashfile Multilarm.exe SHA256
• Linux / Raspberry Pi: sha256sum -c SHA256SUMS

“The Multilarm program file has changed”

Multilarm checks its own program file every time it starts. If the file has changed and it was not one of our updates, it records a fault, shows it on the Diagnostics page (check D-A12) and in the Cloud Relay dashboard, and emails the account owner.

Multilarm keeps running when this happens. A public address system that refused to start because a file changed would leave a building without its announcements, and that is the worse outcome — the message exists so that somebody looks, not to stop the system.

If you did not replace the program yourself, treat that device as untrusted: reinstall from multilarm.com (checking the fingerprint as above), change the device's login password, and rotate its Cloud Device Token from the dashboard.

Two-factor authentication on your Cloud account

Your Cloud Relay account can play audio in your building, so anyone who learns its password can too. Two-step verification removes almost all of that risk and takes about a minute to set up.

In the dashboard, click 2FA in the top bar, then Start setup. You will need an authenticator app — Google Authenticator, Microsoft Authenticator, Aegis, 1Password and Bitwarden all work. Choose “enter a setup key” in the app, type in the key shown, then enter the 6-digit code the app produces. Nothing is switched on until that code is accepted, so a mistyped key cannot lock you out.

You are then shown ten recovery codes. Write them down and keep them somewhere other than your phone; each works once, and they are the way back in if the phone is lost. Only hashes are stored, so they genuinely cannot be recovered for you.

Rotating a device token

A device token is the credential that lets the Cloud Relay control that device. If it has been shared too widely, an installer has moved on, or you suspect a device has been tampered with, replace it: in the dashboard, find the device and click 🔄 Rotate token.

The old token stops working straight away. The device shows as offline until you set the new token on it — press Ctrl+K at its console, or use the ready-made --cloud-token command the dashboard offers.

API & Command Reference

The complete request/response reference for the LAN Web Remote REST API, the Cloud Relay command set, and the cloud batch API. All responses are JSON (UTF-8).

Web Remote REST API

Base URL: http://<multilarm-ip>:<port>/api/ (default port 6580). Endpoints honour Basic Auth and the rate limit when configured — see Web Remote Security.

GET /api/status

Current status.

curl http://192.168.1.50:6580/api/status

{
  "uptime": "0.03:22:15",
  "playing": "0103.mp3",
  "radio": "ON - playing",
  "volume": "75%",
  "volumeRaw": 0.75,
  "volumeProfile": "ACTIVE (30%)",
  "activeConfig": "Multilarm.config.xml",
  "cloudRelay": "ON - connected",
  "firewall": "auto",
  "webRemoteAuth": "basic",
  "alarmInfo": "Next: Dhuhr at 12:11",
  "hardware": { "relayEnabled": false, "relayAvailable": false,
                "emergencyEnabled": false, "emergencyArmed": false,
                "emergencyActive": false }
}

GET /api/config

All configuration fields as key/value pairs.

curl http://192.168.1.50:6580/api/config

{ "AlarmFadeInMs": "0", "CrossfadeMs": "1500", "PlayRadio": "Local",
  "Volume": "0.75", "WebRemoteEnabled": "True", "WebRemotePort": "6580", ... }

POST /api/config

Update one or more fields (send only the ones you change). Persisted to the active config file and applied immediately (except restart-required fields).

curl -X POST http://192.168.1.50:6580/api/config \
  -H "Content-Type: application/json" \
  -d '{"Volume":"0.5","VolumeProfileRules":"22:00-07:00,volume=0.3"}'

{ "ok": true, "updated": 2 }

POST /api/skip

Skip the current radio track. { "ok": true }

POST /api/test-alarm

Play a random alarm at full priority. Optional body {"folder":"…"} to choose a specific alarm folder.

curl -X POST http://192.168.1.50:6580/api/test-alarm \
  -H "Content-Type: application/json" -d '{"folder":"C:\\Multilarm\\Adhan"}'

{ "ok": true }

POST /api/test-radio

Play a random radio file for 10 seconds. { "ok": true }

POST /api/volume

Set master volume (decimal 0.0–1.0).

curl -X POST http://192.168.1.50:6580/api/volume \
  -H "Content-Type: application/json" -d '{"volume":0.6}'

{ "ok": true, "volume": 0.60 }

GET /api/logs

The console log buffer (up to 500 timestamped strings).

[ "[08:00:01] Loading schedule for 10/04/2026",
  "[08:00:01] AlarmPath [C:\\Adhan]: 42 file(s) found",
  "[08:15:30] Radio: Now playing Track01.mp3", ... ]

GET /api/schedule

Today's remaining schedule — time, label (from TextData) and minutes until each alarm. Useful for external countdown displays and home-automation dashboards.

[ {"time":"12:11","label":"Zuhr","minutesUntil":45},
  {"time":"15:44","label":"Asr","minutesUntil":258},
  {"time":"18:30","label":"Maghrib","minutesUntil":423} ]

GET /api/alarm-folders

Configured alarm folders (from AlarmPath).

[ "C:\\Multilarm\\Adhan", "C:\\Multilarm\\Bleep" ]

POST /api/speak

Speak arbitrary text immediately (queued at Priority 3). Body {text, engine?} where engine is "Builtin", "Kokoro" or empty (device default). Returns HTTP 400 if text is empty. See Text-to-Speech.

POST /api/voice/upload

Accept a complete audio file (e.g. from the browser-mic path) and store it as voicememo.wav. Accepted content types: audio/wav, audio/mpeg, audio/ogg, audio/aiff. Max body 16 MB.

curl -X POST http://192.168.1.50:6580/api/voice/upload \
  -H "Content-Type: audio/wav" --data-binary @memo.wav

{ "ok": true, "size": 283964 }

Errors — 400: empty body, unrecognised format, or > 16 MB · 429: rate limit (30 POSTs / 60 s / IP) · 401: Basic Auth required/incorrect.

GET /api/hardware/status

Live Multilarm Box hardware state — relay availability, per-channel open/closed, emergency state. Channel rows reflect the fixed map even while the board is unplugged.

curl http://192.168.1.50:6580/api/hardware/status

{ "relay": { "enabled": true, "available": true, "port": "/dev/ttyUSB0",
             "protocol": "A0", "lastError": "",
             "channels": [ {"id":1,"name":"Bell","open":false},
                           {"id":2,"name":"ZoneMuteA","open":false},
                           {"id":3,"name":"ZoneMuteB","open":false},
                           {"id":4,"name":"EmergencyLed","open":false} ] },
  "emergency": { "enabled": true, "available": true, "gpioPin": 17,
                 "active": false, "lastTriggeredUtc": null },
  "audio": { "playbackDevice": -1 } }

POST /api/hardware/relay/pulse · /open · /close

Manual relay control. Body {"channel": 1-4}; pulse also accepts "durationMs" (default 1000, clamped 100–60000). Returns {"ok":true}, or {"ok":false,"reason":"relay board not connected"} when the board is absent — never an error page.

curl -X POST http://192.168.1.50:6580/api/hardware/relay/pulse \
  -H "Content-Type: application/json" -d '{"channel":1,"durationMs":1500}'

POST /api/hardware/bell

Ring the bell manually — same code path as a scheduled BellScheduleRules fire (so it proves the production chain). Optional body {"durationMs":1500}.

POST /api/hardware/emergency/test · /reset

test triggers a full emergency broadcast (looped audio at top priority, schedule suppressed, LED on) with no hardware needed; reset clears it. No body required. Both are audit-logged. Warn anyone in earshot before testing.

Other endpoint families

Cloud Relay commands

Each device polls GET /api/poll.php every 5 s with its X-Device-Token header; the server returns zero or more pending commands. After any state-changing command the device immediately pushes a status update (in addition to the 30-second heartbeat). On error it backs off exponentially (5s → 10s → 20s → 40s → 60s cap). Recognised actions:

Cloud batch command API

POST /api/batch-command.php — send one command to several devices at once. Requires a logged-in session; all target devices must belong to the authenticated user (ownership is verified before anything runs — all-or-nothing).

// request
{ "device_ids": [1, 3, 5], "action": "volume", "payload": "0.5" }

// response
{ "ok": true, "command_ids": { "1": 42, "3": 43, "5": 44 } }

Allowed batch actions: skip, test-alarm, test-radio, volume, update-config. Errors — 405: not POST · 400: missing/invalid device_ids or action · 403: a device isn't owned by the user.

Cloud console log lines

The relay logs to the console (cyan) and Multilarm.error.log: "Cloud relay started", "Cloud: Connected to …", "Cloud: Disconnected — …", "Cloud: Received N command(s)", "Cloud: Command [action] completed", "Cloud: Status pushed". Use Ctrl+I for the live relay status.