Last month I walked a 12,000 m2 distribution center with the facilities lead. The gateway sat in the office at one end. At the far dock door, the Beacon read -92 dBm on the gateway — below the decode floor. His first instinct was to quote two more gateways at roughly $800 each. Before he signed, I dropped a single relay Beacon on a shelf halfway down the aisle. The gateway started seeing that corner again.
A relay Bluetooth Beacon is a boring Beacon with one extra habit: it listens. While a normal Beacon only shouts its own payload, a relay also catches nearby Beacons’ advertising packets and re-emits a copy. The gateway never learns the relay “found” anything — it just receives the far Beacon’s data from a closer mouth.
What you actually get
The win is simple coverage. Say a Beacon in the cold-storage room sits at -90 dBm at the gateway — barely readable, quietly dropping packets. Put a relay Beacon at -68 dBm to both that room and the gateway. The gateway now hears a clean -68 dBm copy of the room Beacon. One relay pulls a dead zone back into the network without running cable or buying a second gateway.
The cost is battery. A passive Beacon advertising at 1 Hz and -8 dBm sips about 15 to 20 microamps average and runs 18 months on a CR2032. A relay doing the same plus listening and rebroadcasting at 2 Hz typically draws 2.5 to 4 times that. On the identical cell you are looking at 5 to 7 months, not a year and a half. If the relay is somewhere you can plug it in — a dock door with a USB adapter, a powered sensor node — the math flips and the relay becomes nearly free.
The latency nobody mentions
Relaying is not instant. The relay has to hear the source Beacon’s packet before it can repeat it. At 1 Hz advertising that is an average 500 ms wait, though most firmware uses a shorter listen window and rebroadcasts within 20 to 80 ms once it catches a frame. For “where is this pallet” that delay is invisible. For a real-time anti-collision system on a forklift it is not. Know which one you are building.
How many hops
Two, maybe three. Every hop adds its own packet-loss chance and its own delay, and they multiply. At a clean 1 to 3 percent loss per hop, three relays in a chain already lose around 9 percent of frames. Past that you have built a system that fails quietly in the middle. I have seen daisy chains of five “temporary” relays that nobody documented and everybody feared. Treat two hops as the design limit and three as the exception you can actually troubleshoot.
When not to reach for one
A relay Beacon is a band-aid with a battery. If you can move the gateway ten meters, or add one more static Beacon, or run a second gateway where coverage is genuinely dense, do that first. Relays add a second device that can die, a second battery to track, and a failure mode where the relay quits and the far Beacon looks “gone” instead of “relay gone.” That confusion alone has cost more truck rolls than the hardware ever saved.
The storm you cause by accident
Here is the trap: if every Beacon relays every other Beacon, the air fills up. Ten Beacons each repeating nine neighbors turns into ninety extra transmissions per cycle, and the channel saturates. Any competent firmware caps it — relay only specific source IDs, or limit N relays per zone — but off-the-shelf modules in “just make it repeat” mode will happily melt your packet rate. Set the allow-list before you deploy, not after the support call.
Bottom line
A relay Bluetooth Beacon earns its place covering the one corner that is not worth a gateway: a stairwell, a far rack, a loading bay with no power. Used that way it is a $12 fix. Used as your coverage architecture it is a battery you will be replacing forever. Put the relay where it can see both ends, keep the chain short, and let the gateway do the listening.