A long wireless range, a fast alert, or a sophisticated detector can sound impressive in isolation. But none of those specifications on its own tells you whether an alarm system holds together as a complete, working installation. Ajax’s real technical strength doesn’t come from any single feature — it comes from how devices communicate with the hub, how that communication is supervised, how faults and interference get reported, what communication paths the chosen hub provides, and whether every component in the system is actually compatible with the others. Strip away the marketing language, and what’s left is a system whose reliability depends on all of these layers working together, not on any one of them being impressive on its own.
It’s Not One Feature — It’s How the System Holds Together
An alarm system isn’t a single product; it’s a chain of functions, and each link does a different job. A detector can detect an event — that’s one function. Something has to verify what actually happened, notify the right people, and, if professional monitoring is involved, prompt a response. Detection, verification, notification, monitoring and response are related, but they aren’t the same thing, and a system’s real capability depends on how well they connect, not just on how good any one of them is in isolation. That’s the frame the rest of this article works through.
Communication: How Devices and the Hub Actually Talk to Each Other
Ajax’s wireless devices and hub communicate using Jeweller, the company’s proprietary radio protocol. A few things about how it works matter more than the headline range figure:
- It’s two-way. The hub doesn’t just receive signals from detectors — it sends commands and expects a response, which is what allows event delivery to be acknowledged rather than simply broadcast and hoped for.
- It’s fast once triggered. An alarm signal is delivered in 0.15 seconds from the moment a device is triggered — a genuinely quick figure, but one that measures something different from the supervision interval covered next.
- The rated range assumes ideal conditions. Jeweller is rated for up to 2,000 metres between hub and device in open-space, line-of-sight conditions. That’s a design ceiling, not a real-world guarantee — walls, floors and building materials all reduce the practical range at an actual property, which is why on-site radio testing during installation matters more than the headline number.
Supervision: How the System Knows When Communication Is Missing
This is where Ajax’s design does more than most people assume an alarm system does. Rather than only waiting for a triggered event, the system relies on devices communicating with the hub at regular intervals as part of normal operation, typically somewhere between 12 and 300 seconds depending on the specific device and how the system is configured. If a device’s expected communication doesn’t arrive within its interval, the hub can flag that something is off, rather than the system staying silently unaware.
This is a different process from the 0.15-second alarm delivery figure above, and it’s worth separating the two clearly: alarm delivery is how fast a triggered event reaches the hub. Supervision is a separate, ongoing background process that checks in on devices roughly every 12 to 300 seconds even when nothing has happened, which is what lets the system notice a device has gone quiet rather than only noticing when something goes wrong loudly.
What this supervision can reveal:
- that a device has stopped communicating within its expected interval;
- battery or power-related status reported by the device;
- a general communication or connectivity problem worth investigating.
What the 12–300 second interval is not:
- the speed at which a triggered alarm is delivered (that’s the separate 0.15-second figure above);
- a notification time;
- a monitoring response time;
- a guarantee that every possible fault is caught within a fixed universal period.
This interval doesn’t tell the hub why a device has gone quiet — only that expected communication is missing, which is flagged as a fault or status condition rather than left undetected.
Protection and Integrity: Detecting Problems, Not Guaranteeing Immunity
Beyond simply communicating, Ajax’s system includes several layers aimed at protecting the integrity of that communication. Devices authenticate with the hub at each contact, and communication is encrypted, intended to prevent device or signal forgery. The hub also monitors radio conditions and can report unusually high noise levels on the channel it uses — a signal that could indicate deliberate jamming, or something more mundane like a neighbouring device causing interference. Detecting interference is not the same as being immune to it. A system that reports a jamming attempt is giving useful information — it isn’t claiming the interference had no effect, and it isn’t a guarantee that communication can never be disrupted.
Why the Exact Ajax Configuration Matters
None of the above applies uniformly to every Ajax system, and the clearest illustration is the difference between standard Jeweller and Superior Jeweller. Superior Jeweller is an upgraded version of the protocol available only on specific hubs and Grade 3-rated devices; it adds advanced encryption and enhanced frequency hopping compared with the standard protocol. Saying simply that “Ajax supports advanced encryption” is misleading unless the specific hub and devices involved are known — these are capabilities of a particular configuration, not a blanket description of every Ajax installation.
There’s also a precise technical condition worth understanding: enhanced frequency hopping only operates at full capability when every device in the system supports Superior Jeweller. If a system that’s otherwise built from Superior/Grade 3 devices also includes a standard Jeweller device, enhanced frequency hopping does not operate at full capability, and the system does not receive the full Grade 3 configuration benefit. This isn’t a dramatic “one device breaks your security” scenario — it’s simply how the protocol is designed to work, and it’s a precise example of why Ajax’s real capability is a property of the whole configured system rather than something that follows automatically from the brand name.
Redundancy: Backup Paths Depend on the Configuration
Ajax hubs can connect to the Ajax Cloud server, and to a monitoring company where applicable, through more than one communication channel. What’s actually available depends on the specific hub and how it’s set up:
- Channel options — Ethernet, Wi-Fi and cellular are all possible, but the number and type of channels a given hub supports depends on the hub model. As one example, the Hub 2 Plus connects via Ethernet, Wi-Fi and two SIM cards at once — four channels in total; other hub models offer fewer, so this is a property of the specific hub, not a baseline every Ajax installation has.
- Automatic failover — if one channel loses connection, the hub switches to another available channel instantly.
- Fixed priority — when multiple channels are active, priority goes to the faster options (Ethernet and Wi-Fi first); cellular is used as a backup that consumes minimal data, and this priority order can’t be changed.
- Carrier-level redundancy — for properties relying on cellular as a genuine backup, using two SIM cards from different carriers is a documented way to avoid losing that channel if a single carrier has an outage.
- Backup power — hubs carry a backup battery for use during a mains power loss, with the option to extend runtime further using an external power supply; exact battery life varies significantly by hub model, so it’s worth checking the specific hub rather than assuming a standard figure applies.
The point isn’t that every Ajax hub has identical redundancy — it doesn’t. It’s that redundancy, where it exists, is a designed part of the architecture rather than an incidental benefit, and which channels and battery life are actually available depends on the hub chosen and how it’s configured on-site.
The App Layer: Status Awareness, Not Just Convenience
The Ajax app’s real function in this system isn’t convenience — it’s visibility. Through the app, users can see:
- events and alarms as they’re reported by the system;
- the current status of individual devices, including faults;
- relevant user permissions, where a system has more than one authorised user.
That visibility matters because it’s how the supervision and protection layers described above actually become useful to a person rather than staying internal to the hardware. But an app notification is not the same as professional monitoring, and receiving an event through the app doesn’t mean that event has been independently verified. Detection, notification, monitoring and response remain distinct functions — the app covers the notification layer, and whether monitoring or a response follows depends on whether those separate services are arranged and active.
What This Means When Choosing or Assessing an Ajax System
Put together, the useful question isn’t really “is Ajax powerful?” It’s closer to: does this specific Ajax configuration — this hub, these devices, this protocol generation — actually provide the communication, supervision and integrity functions the property needs? A standard Jeweller system and a Superior/Grade 3 system are not interchangeable on paper, and a hub with multiple independent communication paths has a different redundancy architecture from one with fewer available paths — the right answer depends on the property and what’s actually required, not on assuming every configuration performs identically because it carries the same brand name.
If you’re weighing up an Ajax system for a property, a properly configured Ajax installation is where hub selection, device compatibility and communication conditions actually get matched to the site, rather than assumed from a spec sheet.
Frequently Asked Questions
What makes Ajax alarm systems reliable?
Reliability comes from several layers working together — two-way communication between devices and the hub, regular supervision that flags missing communication, encryption and interference detection, and backup communication paths where the hub supports them — rather than from any single specification.
Does Ajax still work if internet access is lost?
It depends on the hub model and which communication channels are configured. Hubs that support multiple channels (such as Ethernet, Wi-Fi and cellular) can automatically switch to another available channel if one is lost; the specific channels available depend on the hub.
How far can Ajax wireless devices communicate?
Standard Jeweller devices are rated for up to 2,000 metres from the hub in open-space, line-of-sight conditions. Real-world range at a specific property is affected by walls, floors and building materials, which is why on-site radio testing matters more than the rated figure.
What is the difference between Jeweller and Superior Jeweller?
Superior Jeweller is an upgraded protocol available only on specific hubs and Grade 3-rated devices, adding advanced encryption and enhanced frequency hopping. These enhanced capabilities depend on every relevant device in the system supporting Superior Jeweller — they aren’t a general feature of all Ajax systems.
Sources
- Ajax Systems — Jeweller (technical specifications)
- Ajax Systems Support — Jeweller radio protocol: technology and capabilities
- Ajax Systems Support — Advanced encryption and frequency hopping in Superior Jeweller
- Ajax Systems — Devices supporting the Superior Jeweller protocol
- Ajax Systems Support — What communication channels are used for the Hub
- Ajax Systems Support — How to provide stable system operation if the hub loses connection with the Ajax Cloud server
- Ajax Systems — Ajax hubs (product overview)
- Ajax Systems — Hub 2 Plus (manual)


