Rethinking the Pager: Smarter Alerts with SDR and Context-Aware Automations

In an era of smart everything, from homes to watches to fridges, it’s strange that one of the most critical tools in emergency services and on-call rotations remains fundamentally unchanged.

Pagers are about as close to fail-proof as equipment gets. They chirp and buzz indiscriminately, day or night, regardless of whether the person wearing it is asleep, off-duty, or already en route. That single-mindedness is exactly the point: no smart features, no software updates, no failure modes to worry about, just the alert getting through, every time. It’s precisely why pagers are still standard-issue kit for emergency response decades after everything else in your pocket has been replaced twice over.

But being fail-proof at the moment of alert doesn’t help with what comes next. This project isn’t about replacing the pager. It’s too reliable and too battle-tested for that. It’s about building a layer of intelligence around it, so that everything that has to happen in the seconds after it goes off doesn’t have to happen manually.

The Problem

Most of Australia’s emergency response, especially once you’re outside the capital cities, runs on volunteers. Nationwide there are something like 195,000 bushfire volunteers, and out in regional and rural areas that’s close to 4.5% of the population.¹ These aren’t people sitting in a station waiting for the phone to ring. They’re tradies, farmers, teachers and parents who drop what they’re doing at home, at work, or in the paddock, and race to the station the second a call comes in. For a volunteer brigade like CFS, the target is simple but critical: get a truck rolling out the door within minutes of the call. Every second counts, and the difference between making the truck and being left behind can come down to how quickly you get the alert.

That’s exactly why pagers haven’t gone away out here. Volunteers are scattered across homes and workplaces rather than sitting in a station, so most states run their own dedicated, statewide paging network to reach them: simple, low-power, and reliable in the regional and remote areas where mobile coverage often isn’t. South Australia runs its own version of this, the SA Government Radio Network (SAGRN), built across roughly 240 sites statewide, purpose-built to carry paging traffic for public safety agencies right across the state, from the Adelaide metro area out to the Eyre Peninsula and the Riverland.² And it’s not just a volunteer network. The same SAGRN paging service carries dispatch traffic for the Metropolitan Fire Service (MFS) and SA Ambulance Service (SAAS), both career, professional outfits, right alongside CFS and SES volunteers, all on the same paging service.³

Here’s the part the pager can’t help with. It’s the middle of the night, you’re fast asleep, and the pager goes off in the pitch black. You’ve got to find the pager to read it, find your phone, find your keys, get dressed, and find a light switch without waking the house or tripping over the dog. The pager did its job the second it buzzed. Everything after that is manual.

That’s where home automation can help. If a page at 3am also lit a path from bed to front door, with details sent to your phone, and skipped all of that for administrative pages that don’t need you out of bed, those fumbled seconds come back. I wanted to build that layer, not to replace the pager, but to give it a smart companion.

How a Pager Works

Before diving into the solution, it’s worth understanding what we’re actually intercepting. A pager is essentially a one-way radio receiver tuned to a specific frequency, but not every pager reacts to every broadcast. Paging systems use protocols like POCSAG or FLEX, which structure each transmission into an address (capcode) and a message payload.

Each pager is programmed with one or more unique capcodes, like an address on an envelope. When a broadcast goes out, every pager on that frequency hears the signal, but only those matching the capcode actually alert the user. This prevents an entire station or shift from being woken up for messages not intended for them.

The FLEX protocol supports transmission at 1600, 3200, or 6400 bits per second using FSK (Frequency Shift Keying) modulation. The payload itself is tiny compared to modern messaging. Typically anywhere from a few characters up to a couple hundred, depending on the protocol and data rate. This efficiency allows large numbers of messages to be sent quickly over a narrow frequency, which is why paging remains so reliable decades after its invention.

How The South Australian Emergency Paging Network Works

In South Australia, emergency services still rely on these old-school pagers to alert members to incidents. The system is tried and tested. Old, but extremely reliable. After a bit of research, I discovered something useful:

“All CFS brigades and SES units rely on the SAGRN paging network for response and general information messages. Samsung and Apollo pagers are utilised by volunteers and staff state-wide. The SAGRN paging service transmits on 148.8125MHz using the Flex 1600 protocol and has transmission sites at the same location as most of the GRN voice transmitters, this provides exceptional coverage throughout the settled areas of South Australia.”⁴

Perfect. Now I had a target frequency and protocol.

The Solution: Software Defined Radio

As a bit of a tinkerer, I happened to have an R820T RTL-SDR (Software Defined Radio) dongle lying about from previous RF experiments. These affordable USB dongles can tune from about 24 MHz to 1.75 GHz, making them more than capable of picking up our 148.8125MHz pager transmissions.

Importantly, transmitted data over FLEX is not encrypted, which meant I could legally monitor these broadcasts. Though I’d encourage anyone attempting this to check their local regulations regarding monitoring emergency service frequencies first.

Building the Docker Container

I spun up a quick and dirty Docker container based on Alpine Linux, installing only the bare minimum required software: rtl_fm for receiving the signal, and multimon-ng, an open-source decoder that supports FLEX and POCSAG paging protocols.

Here’s the Dockerfile:

# Use Alpine as a base image
FROM alpine:latest

# Install dependencies and tools
RUN apk add --no-cache build-base cmake git unzip rtl-sdr mosquitto-clients

# Clone and build multimon-ng
RUN git clone https://github.com/EliasOenal/multimon-ng.git /opt/multimon-ng && \
    cd /opt/multimon-ng && \
    mkdir build && cd build && \
    cmake .. && \
    make && \
    make install

# Remove build dependencies to reduce image size
RUN apk del build-base cmake git unzip && \
    rm -rf /var/cache/apk/*

# Copy entrypoint script
COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh

# Set entrypoint
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

The entrypoint script does the heavy lifting:

#!/bin/sh

# Initialize RTL-SDR receiver and decode FLEX pager messages
rtl_fm -f 148.8125M -M fm -s 22050 -r 22050 | multimon-ng -a FLEX -t raw /dev/stdin | while read -r line
do
    # Log each decoded message to console for debugging
    echo "Raw message: $line"
    
    # Forward each message to MQTT broker
    mosquitto_pub -h 192.168.1.100 -t pager/messages -m "$line"
done

Breaking this down:

• rtl_fm tunes the SDR dongle to the pager frequency (148.8125 MHz) and demodulates the FM signal into raw audio at 22050 Hz
• multimon-ng takes that raw audio stream and decodes it using the FLEX protocol, outputting each decoded message as a line of text
• Each decoded line is published to an MQTT topic (pager/messages) for downstream processing

Each received pager message was printed to the console via the shell script. Great for debugging, but not exactly useful for alerts. That’s where MQTT comes in.

Here’s what that raw console output actually looks like. This particular capture happens to be from a day when routine pager testing was underway across the network, which works out nicely, it lets me show what a live feed looks like without publishing a wall of real incident traffic:

Live decode output during routine pager testing

Anatomy of a Page Message

Before we get into the automation, it’s worth understanding what these messages actually look like when they come through. Here are some fictional examples based on what I have observed:

Fire callout: FLEX|2024-12-25 03:14:15|1600/2/K/A|10.069|001234567|ALN|MFS: *CFSRES INC0069 25/12/24 12:44 RESPOND STRUCTURE FIRE, ALARM LEVEL: 1, : @MCCALLISTER RESIDENCE 671 LINCOLN AVE WINNETKA,MAP:ADL 50 J12,TG C39 T669, :CUCK34 HPPYPUMP :

Ambulance callout: FLEX|2025-04-20 16:20:00|1600/2/K/A|04.020|001234567|ALN|E420 PR: 1 - ADELAIDE 4 M 4 D00420 Disp: 16:20 Overdose /

These messages look dense at first glance, but they follow a consistent structure that makes them straightforward to parse.

Common FLEX Header

Every page starts with the same set of header fields, regardless of the sending agency:

Field	Example	Description
Protocol	FLEX	The paging protocol used for this transmission
Timestamp	2024-12-25 03:14:15	Date and time the message was received by the decoder
Speed/Phase/Frame	1600/2/K/A	Transmission speed (1600 bps), phase (2), and frame information (K/A) used for signal decoding
Cycle	10.069	The FLEX cycle and frame number, used internally for synchronisation
Capcode	001234567	The pager’s unique address. This is how the system targets specific pagers or groups
Message Type	ALN	The encoding type. ALN (alphanumeric) means the payload contains readable text

Everything after the message type field is the actual payload content, and its structure depends on which agency sent it.

CFS/MFS Payload

Fire service messages follow a structured format that packs a surprising amount of information into a short string:

Field	Example	Description
Agency	MFS: *CFSRES	The originating service (MFS = Metropolitan Fire Service) and response type (*CFSRES indicates a CFS Response dispatch)
Incident Number	INC0069	Unique incident identifier used to track the event
Date/Time	25/12/24 12:44	Date and time the incident was logged by dispatch
Action	RESPOND	The directive issued to responding units, typically RESPOND for active callouts
Incident Type	STRUCTURE FIRE	Classification of the incident, such as Fire Alarm, Structure Fire, Vehicle Accident, or Hazmat
Alarm Level	ALARM LEVEL: 1	Indicates the scale of response. A 1st alarm is the standard initial dispatch for the incident type, typically multiple appliances. Higher alarm levels mean additional resources have been requested as the situation escalates
Place Name	@MCCALLISTER RESIDENCE	An optional common name for the location, usually a business, landmark, or registered property name
Address	671 LINCOLN AVE WINNETKA	Street address of the incident
Map Reference	MAP:ADL 50 J12	Grid reference from the Adelaide street directory. ADL denotes the directory, 50 is the page number, and J12 is the grid coordinate
Talk Group	TG C39 T669	The radio talk group assigned to the incident, referencing SA’s Government Radio Network (GRN) channel plan. Responding crews switch to this channel for operational communications. C39 here is the MFS Training channel, one of two dedicated MFS training talkgroups on the network5
Appliance	:CUCK34 HPPYPUMP :	The callsign of the appliances (vehicles) assigned to the incident, enclosed in colons. CUCK34 identifies a specific truck at a specific station (more information on vehicles can be found here)

SAAS (Ambulance) Payload

Ambulance messages use a more compact format based on the Medical Priority Dispatch System (MPDS):

Field	Example	Description
Unit	E420	The ambulance unit callsign assigned to the job (made up in this case as I couldn’t find any funny units)
Priority	PR: 1	MPDS priority level from 1 (highest, life-threatening) to 5 (lowest). Priority 1 and 2 are lights-and-sirens responses
Suburb	ADELAIDE	Suburb or locality of the incident
Map Reference	4 M 4	Grid reference from the Adelaide street directory. 4 is the page, M4 is the grid coordinate
Dispatch Reference	D00420	Unique dispatch case number used for tracking the job through the ambulance system
Dispatch Time	Disp: 16:20	Time the unit was dispatched, in 24-hour format
Call Type	Overdose /	Abbreviated MPDS call type describing the nature of the medical emergency. Often truncated due to message length limits

This structured format makes it perfect for parsing and filtering in Node-RED. You can extract specific fields like the capcode to filter for relevant appliances, or parse the message content to trigger different automations based on incident type or priority.

Integrating with Node-RED and Home Assistant

Here’s where things get interesting. I could have processed the pager messages directly in the container with shell scripts, but I chose to use Node-RED for several reasons:

1. It’s already running 24/7 in my smart home setup
2. It can be modified live without rebuilding containers
3. It’s easy to use. Flows can be modified as needed easily.

The complete flow looks like this:

Pager Monitor Container
      ↓
MQTT Topic (all messages)
      ↓
Node-RED (filters + routes messages)
      ↓
Sub-topics for relevant appliances
      ↓
Home Assistant (notifications + automation)

Node-RED: The Intelligence Layer

Node-RED acts as the brains of the operation. When a message arrives on the pager/messages topic, a flow processes it through several stages.

Message Parsing

I created a set of extraction functions to pull out all the relevant data from each page. Here’s one that extracts the incident number:

function extractINC(message) {
    let inc = message.match(/\bINC\d{4,}\b/);
    return inc ? inc[0] : null;
}

This uses regex to find patterns like INC0069 in the message. For fire callouts, I also extract the alarm level, which tells you how serious the incident is:

function extractAlarmLevel(message) {
    let match = message.match(/ALARM LEVEL:\s*(\d+)/);
    return match ? parseInt(match[1], 10) : null;
}

The map details are particularly useful because they give you the location using the Adelaide street directory grid reference (worth noting the difference between SAAS and CFS formats):

function extractMapDetails(message) {
    // CFS: Extracts the Map details (type, page, grid)
    let cfsMatch = message.match(/MAP:([A-Z]+)\s+(\d{1,3})\s*([A-Z])(\d+)/);

    if (cfsMatch) {
        return {
            type: cfsMatch[1],
            page: parseInt(cfsMatch[2], 10),
            grid: [cfsMatch[3], parseInt(cfsMatch[4], 10)]
        };
    }
    
    // SAAS: Extract page and grid for locations
    let saasMatch = message.match(/(?:@[\w]+ )?([\w\s]+?)\s+(\d{1,3})\s*([A-Z])\s*(\d+)/);

    if (saasMatch) {
        return {
            type: "SAAS",
            page: parseInt(saasMatch[2], 10),
            grid: [saasMatch[3], parseInt(saasMatch[4], 10)]
        };
    }

    return null;
}

For ambulance callouts, the Medical Priority Dispatch System codes give you a lot of information. The priority level (1-9) tells you how urgent the call is:

function saas_extractPriority(message) {
    let match = message.match(/PR:\s*(\d+)/);
    return match ? parseInt(match[1], 10) : null;
}

All these functions get stored in Node-RED’s global context so they can be reused across different flows:

function storeFunctions() {
    global.set("extractINC", extractINC);
    global.set("extractAlarmLevel", extractAlarmLevel);
    global.set("extractDateTime", extractDateTime);
    global.set("extractTalkGroup", extractTalkGroup);
    global.set("extractMapDetails", extractMapDetails);
    global.set("extractIncidentType", extractIncidentType);
    global.set("extractAddress", extractAddress);
    
    global.set("saas_extractCallType", saas_extractCallType);
    global.set("saas_extractLocation", saas_extractLocation);
    global.set("saas_extractPriority", saas_extractPriority);
    global.set("saas_extractAmboUnit", saas_extractAmboUnit);
}

storeFunctions();

Capcode Filtering

Once we’ve parsed the message, we check if the capcode matches any of our monitored appliances. This is where the magic happens. Instead of relying solely on a single pager to receive the message, we can watch for specific appliance codes across ANY message on the network:

// List of monitored appliance capcodes
let myCodes = ['001234567'. '007654321'];

if (myCodes.includes(msg.capcode)) {
    return msg;  // Pass through relevant messages
}
return null;  // Drop irrelevant ones

You’ll want to replace these capcodes with the ones relevant to your brigade or unit. You can identify them by cross-referencing decoded messages with known callouts, or by asking your brigade for the capcodes assigned to your station’s appliances.

Smart Filtering

Here’s where we add context-awareness. A function node can check time of day, day of week, calendar events, and location to decide how to handle an alert:

let now = new Date();
let hour = now.getHours();
let alarmLevel = extractAlarmLevel(msg.content);

// Only alert between 6am and 11pm unless it's a second alarm

if (hour >= 6 && hour <= 23 || alarmLevel > 1) {
    return msg;
}
return null;

Multi-Channel Output

Once a message passes the filters, Node-RED routes it to multiple destinations. Push notification to phones via Home Assistant. MQTT topic to trigger LED automations. Log to a database for historical records.

The beauty of this approach is flexibility. When availability changes, we just tweak the Node-RED flow. No need to rebuild containers or restart services. If you want to add a new notification method, it’s a few drag-and-drop nodes.

Context-Aware Automations

Node-RED also allows us to build more sophisticated logic that the pager itself could never handle.

Priority-Based Routing:

With this automation setup different incidents could be used to warrant different responses. A priority 1 ambulance call or a structure fire should wake the dead, but an administrative page probably shouldn’t. And not every page is even an incident. Plenty of what comes through is just a general broadcast to everyone on the network, with no callout in it at all:

FLEX|2025-04-21 03:04:06|1600/2/K/A|01.003|001234567|ALN|Happy Easter. No training tonight.

The physical pager still chirps for that one, capcode matched and all, but there’s no PR: or ALARM LEVEL: in it for saas_extractPriority or extractAlarmLevel to find. Treat that as “not urgent” and it happens to fall through to the low-priority branch anyway, but that’s an accident of both extractors returning null, not something the code actually checked for. It’s worth testing for explicitly, so a genuine low-priority incident and “no incident at all” don’t get muddled together further down the flow:

let priority = saas_extractPriority(msg.content);
let alarmLevel = extractAlarmLevel(msg.content);
let isCallout = priority !== null || alarmLevel !== null;

if (!isCallout) {
    // General broadcast, e.g. "Happy Easter. No training tonight." -- no PR or alarm
    // level to key off, so it's not an incident. Log it, don't run callout automations.
    msg.topic = 'pager/info';
    msg.sound = 'none';
} else if (alarmLevel >= 3) {
    msg.topic = 'pager/critical';
    msg.sound = 'urgent.mp3';
    msg.override_dnd = true;
} else if (alarmLevel >= 1) {
    msg.topic = 'pager/standard';
    msg.sound = 'normal.mp3';
    msg.override_dnd = false;
} else {
    msg.topic = 'pager/info';
    msg.sound = 'none';
}
return msg;

Incident Deduplication:

The paging network often sends the same incident to multiple capcodes in sequence. Without deduplication, you’d get hammered with repeated notifications for the same event:

let incidentNumber = extractINC(msg.content);
let recentIncidents = flow.get('recentIncidents') || {};
let now = Date.now();

// Clean up incidents older than 30 minutes
for (let key in recentIncidents) {
    if (now - recentIncidents[key] > 1800000) {
        delete recentIncidents[key];
    }
}

if (incidentNumber && recentIncidents[incidentNumber]) {
    return null; // Already alerted for this incident
}

if (incidentNumber) {
    recentIncidents[incidentNumber] = now;
    flow.set('recentIncidents', recentIncidents);
}
return msg;

Incident Type Detection:

Different incident types can trigger different home automations. A fire callout at night might light up the whole house, while a daytime call just needs a notification:

let hour = new Date().getHours();
let isNight = hour < 6 || hour >= 22;

if (isNight) {
    // Light up a path: bedroom → hallway → front door
    msg.automation = 'fire_response_night';
} else {
    msg.automation = 'fire_response_day';
}

return msg;

Location-Based Filtering:

Home Assistant tracks presence through device trackers, so we can adapt the response based on whether anyone is actually home to respond:

let location = global.get('location');

if (location === 'home') {
    return msg;  // Trigger lights, sounds, and home automations
} else {
    // Just send push notification, skip home automation
    msg.homeAutomation = false;
    return msg;
}

Shift-Aware Filtering:

If you maintain a roster or on-call schedule in Home Assistant, you can suppress non-critical alerts when you’re off-duty:

let onCall = global.get('on_call');
let alarmLevel = extractAlarmLevel(msg.content);

if (onCall) {
    return msg; // On call, pass everything through
}

// Off duty: only pass through critical incidents
if (alarmLevel >= 2) {
    msg.topic = 'pager/critical';
    return msg;
}
return null;

The flow-based programming in Node-RED makes all of this intuitive. You can see the logic visually, test changes in real-time, and debug issues by watching messages flow through the nodes. It’s perfect for iterative development where requirements change based on real-world use.

The Unexpected Advantage

After building this system, I noticed something surprising. The DIY system was consistently faster than the physical pager.

Why? Emergency service pages are sent in a sequence, and the intended appliance isn’t always paged first. Sometimes another brigade or agency gets the first notification in the sequence.

Here’s the kicker: all pages contain the same content. Location, description, and appliance codes. By monitoring all pages on the network, our system can detect relevant appliance codes in any message, even before the target brigade’s capcodes are paged directly. The physical pager only activates when its own capcode is broadcast, but our system is already watching everything.

Smart Home Integration

This early detection unlocks some genuinely useful automation. Here are some of the things we’ve wired up.

Push Notifications arrive on phones before the physical pager even chirps. If the pager is on the nightstand and the phone is in the kitchen, you still get the alert immediately.

Pathway Lighting is the automation that gets the most use. When a relevant page comes through at night, Home Assistant triggers LED strips to light a path from the bedroom to the front door. No fumbling for light switches at 3am.

Escalation can be handled by the priority system. A priority call can override Do Not Disturb on phones, cranks the notification intensity, and turns on all the lights. A low-priority administrative page just logs silently.

Here’s the Home Assistant automation that handles the CFS alert notification and pathway lighting:

alias: "[CFS] Volunteer Alert"
description: ""
triggers:
  - topic: pager/alert
    trigger: mqtt
conditions: []
actions:
  - metadata: {}
    data:
      title: "CFS: {{trigger.payload_json.type}} @ {{trigger.payload_json.map}}"
      message: |-
        {{trigger.payload_json.address}}

        {{trigger.payload_json.message}}
      data:
        clickAction: "{{trigger.payload_json.gmap}}"
        sticky: "true"
        vibrationPattern: 100, 1000, 100, 500, 100, 1000, 100
        channel: Response
        color: "#cf352e"
        importance: high
        visibility: public
    action: notify.mobile_app_pixel_9_pro
  - type: turn_on
    device_id: ad515d086507921fd05dea4e871d8ba5
    entity_id: 03f0b1b68f18cdd73af6e2d4351414aa
    domain: switch
mode: single

The clickAction field is worth noting. By building a Google Maps URL from the parsed address, tapping the notification opens navigation directly to the incident. One tap from alert to directions.

A word of warning for anyone considering a similar automation flow. While a relay style smart plug to control LED strips is very easy and convenient, it will have the unintended effect of giving you an adrenaline rush whenever you hear a relay click. Consider a solid-state relay for your sanity.

Results

The system consistently delivers notifications before the physical pager activates. Those extra seconds provide an edge in response. Whether it’s making the truck or just being prepared a bit earlier, that time makes a real difference.

But the real value isn’t just speed. It’s the context. The pager tells you there’s a call. The smart home system tells you there’s a call, lights your path, sends the address to your phone, and adapts its behaviour based on the time, the priority, and whether you’re even home to respond.

Technical Considerations

For those looking to implement a similar system, here are some things worth noting.

Legality: Pager protocols like FLEX are unencrypted, but always check your local regulations regarding monitoring emergency service frequencies. In most Australian states, listening is legal but retransmitting or acting on the information for non-authorised purposes is not.

Hardware: If you’re the kind of person who tinkers with RF gear, there’s a decent chance you’ve already got an RTL-SDR dongle sitting in a drawer somewhere from a previous project. If not, they’re cheap enough (around $20 AUD) that it’s an easy investment to justify. The whole setup can run on a Raspberry Pi, so you don’t need much beyond the dongle itself if you’ve already got one spare.

Antenna: If you’re using a cheap, basic SDR dongle, positioning matters more than you’d expect. I initially had mine tucked in a corner surrounded by other electronics, and the RF noise was enough that pager messages were coming through broken, with only part of the message decoded. Moving it to a clearer spot away from other gear fixed it.

Broken decode caused by poor antenna placement, several messages are missing their payload entirely

Software: Docker containerisation makes this solution portable and easy to deploy. MQTT provides a lightweight but powerful messaging system for IoT applications. Node-RED offers the perfect balance between power and ease-of-use for automation logic. The software is all open-source.

Reliability: This system is a companion to the pager, not a replacement. The pager has decades of proven reliability with no internet dependency, no software updates, and no single point of failure. Keep the pager. Let the smart home system enhance it.

This project demonstrates how relatively inexpensive hardware combined with open-source software can solve real-world problems and sometimes outperform official systems. By intercepting emergency service pages and integrating them into a smart home with intelligent filtering through Node-RED, we’ve created a layer of intelligence that the pager was never designed to have, without compromising the reliability it was always built for.

References

1. Value beyond money: Australia’s special dependence on volunteer firefighters — The Conversation. ↩︎

2. SA Government Radio Network Information — Sascan. ↩︎

3. South Australian Government Radio Network (SA-GRN) — RadioReference. ↩︎

4. SA Scan - Country Fire Service Information — Sascan. ↩︎

5. GRN Talkgroups — Sascan. ↩︎