Shift patterns are where bell scheduling stops being a list of times. A weekly timetable repeats every seven days; a continental pattern does not. This page covers how to express the common patterns, and — more usefully — how to recognise the ones you should not try to express at all.
Every rota repeats on something, and identifying what it repeats on is the whole job: a weekday, a date in the month, an ISO week number, or a cycle length that matches none of those. The first three can be written as schedule rules directly. The fourth should be driven from outside. The options:
| Pattern | Repeats on | Encode as |
|---|---|---|
| Fixed days | The week | Ordinary weekday schedule |
| Three-shift, fixed crews | The week | One schedule, all shifts' times in it |
| Two-week alternating | Odd/even week | Two rules, one per week parity |
| Monthly rotation | Date of month | Date-filtered rules |
| Four-on-four-off | An 8-day cycle | ✗ Does not align to the calendar |
| Bespoke rota from workforce software | Nothing | ✗ Drive it externally |
The first four are a few lines of configuration. The last two are the interesting cases, and pretending otherwise is how sites end up with a schedule nobody dares touch.
A common mistake is to think of three shifts as three schedules. It is one schedule with more entries — the system fires times, and it does not need a concept of "shift":
<DateAndTimeData>*mon|06:00|10:00|10:15|13:45|14:00|18:00|18:15|21:45|22:00|02:00|02:15|05:45</DateAndTimeData>Shift starts at 06:00, 14:00 and 22:00; each shift's break start and break end sit between them. Distinct tones per meaning come from folders:
<AlarmPath>D:\Tones\ShiftStart|D:\Tones\BreakStart|D:\Tones\BreakEnd|D:\Tones\ShiftEnd</AlarmPath>
<AlarmIndexData>1|2|3|4|1|2|3|4|1|2|3|4</AlarmIndexData>Note the times that cross midnight. The 02:00 night break belongs to the shift that started the previous evening, but as far as the schedule is concerned it is simply a time on that day. Write the times as the clock shows them and the crossing takes care of itself.
Where crews swap between days and nights on a cycle, the tones usually do not change — the times do. The rule overlays handle this: each rule is a payload plus filters (weekday, date, month, last-day-of-month, slot number, or the source time), and the first matching rule wins.
A two-week alternation is two rules, not fourteen entries. A monthly rotation is a date-filtered rule. The important property is that the base schedule stays readable: you are describing exceptions to a normal week, not maintaining a hand-expanded calendar.
Four-on-four-off repeats on an eight-day cycle. Eight does not divide into seven, so there is no weekday rule that expresses it, and no month rule either — the pattern drifts through the calendar continuously. You can brute-force it by generating dated entries for a year, and every year somebody has to regenerate them, and eventually somebody won't.
Bespoke rotas from a workforce management system are worse: they are not a pattern at all, they are data, and they change when someone swaps a shift.
For both, the right answer is to stop duplicating the rota and let the system that owns it fire the bell. The External Trigger API accepts the same actions — play a specific file, play from a folder, stop, set volume — over three transports:
POST /api/trigger with a bearer token. A scheduled task, a PLC gateway or a line-side script can call it.The rota stays in one place, which is the actual goal. A bell schedule that disagrees with the rota is worse than no bell schedule, because people trust it for a while first.
A tone at 02:00 is not the same event as the same tone at 14:00, even though the schedule treats them identically. Two things are worth setting for night hours: a lower output level through a volume profile, and a shorter or softer tone, so the bell does the job without carrying across a car park into somebody bedroom window. Specifically:
Where a site is near housing, treat night-time levels as a neighbour-relations question before it becomes a complaint.
Whatever the pattern, the schedule should be checked against the rota once a quarter. Not because the software drifts — it does not — but because rotas change and the person who set the bells up has usually moved on. Every fire is written to a playlist log on disk, which makes "did the 22:00 actually ring last Tuesday" a question with an answer.
Try the live demo — a working schedule and dashboard in your browser.
Can it do a three-shift pattern?
Yes, and it is simpler than expected: all three shifts' times go in one day's entry, with folders providing distinct tones for shift start, break start, break end and shift end.
Can it do four-on-four-off?
Not as a calendar rule, because an eight-day cycle never aligns with the week or the month. Drive it from the system that owns the rota using the trigger API rather than regenerating a year of dated entries annually.
How do bells that cross midnight work?
Write them as the clock shows them. A 02:00 break belongs to the shift that started the previous evening, but the schedule simply treats it as a time on that day.
Can our workforce management system ring the bell?
Yes — that is the recommended approach for rotas that do not repeat on a calendar rule. It can call the device over LAN HTTP, publish to MQTT on your own broker, or call the cloud endpoint, all with per-integration tokens.
Can night-shift bells be quieter?
Yes. Time-based volume profiles override the master volume during a window, so night tones can run at a lower level without changing anything else.
Is there a record of what rang?
Yes. Every playback is written to a playlist log and an audit log on disk, and events are dispatched as outbound webhooks.
Part of the Multilarm factory break bell system guide.