The light at the end of the corridor occasionally fails to respond, so you enable the relay function on a few nearby lights.
It seems to help. You decide to enable it on every light that supports relaying and increase the retransmission count: “If it sends a few more times, surely the message won’t be missed?”
But when you dim the whole group, the lights become sluggish again. Some react first, others later, and the status on your phone is still updating.
The problem may have shifted from “the message can’t get through” to “too much is being transmitted over the same shared radio channel.”
Relays can add communication paths, but every forwarding transmission also consumes wireless resources. To decide whether to add more or use fewer, first determine what you lack: coverage, an alternate path, or relief from excessive duplicate traffic.
The scenario above is hypothetical, not a record of measured results. This article discusses SIG Mesh networks that primarily use the advertising bearer and Managed Flooding; it does not represent every Bluetooth product implementation. No latency, capacity, or success rate has been measured for specific devices. The troubleshooting sequence is engineering guidance.
AI-generated illustration. Radio arcs do not represent measured coverage, signal strength or actual routes.
1. A Relay Rebroadcasts a Message from Another Location; It Does Not “Max Out” the Signal
Consider a simple path:
Wall switch → corridor relay → distant light.
The switch cannot reach the distant light directly, but a node in the corridor can receive the message and transmit it onward. That is where a relay helps: it carries a message across a segment it otherwise could not cross.
It does not increase the switch’s transmit power or reserve a dedicated channel for the control command.
If many nodes in the same room have Relay enabled, they may all receive a message that meets the forwarding conditions and each take part in forwarding it. Multiple paths can improve the chance of delivery, but they also mean more wireless transmissions.
Both a Bluetooth SIG article on network design and Silicon Labs’ optimization documentation emphasize the same point: relays should have a deliberate location and purpose, rather than being enabled on every device that supports them.[1][2]
So before “adding one more relay,” ask:
- Which previously unreliable link segment will it bridge?
- Will it provide an alternate path distinct from the existing nodes?
- Could it lose power along with the wall switch?
If you cannot answer those questions, you may mainly be adding duplicate transmissions rather than useful coverage.
2. If Duplicate Packets Are Filtered, Why Does the Network Still Get Busy?
A common misconception is: “Mesh filters duplicate packets, so having more relays doesn’t matter, right?”
Filtering can stop a node from repeatedly processing a packet it has already seen, but it cannot undo radio transmissions other nodes have already made.
Suppose relays B and C both receive a message from A. On receiving it for the first time, each may meet the conditions for forwarding. D can later recognize the copies from B and C as duplicates, but both transmissions have already occurred.
Two things must also be distinguished:
- Receiving duplicate copies from other nodes should not cause a relay to start forwarding them indefinitely.
- A sender or relay may be configured to transmit multiple copies to improve reliability.
Mechanisms such as caches constrain the former; the latter is configured retransmission. There is no contradiction between them. The SIG primer identifies TTL and the message cache as mechanisms that constrain Managed Flooding; Silicon Labs’ documentation separately explains Network Transmit and Relay Retransmit settings.[2][3]
What should you check first? Do not rely solely on an application log showing that it “received one command.” A single application-layer delivery does not prove there was only one radio transmission. Use protocol-stack counters, transmit-queue records, and available packet-capture tools together to identify where the duplication occurs. A capture from one location may also miss packets and cannot be treated as a complete record of traffic across the network.
3. Do Not Call Four Different Controls “Boosting the Signal”
When adjusting parameters on site, it is easy to lose track of cause and effect by adding relays, raising TTL, increasing retransmissions, and having the application retry more often all at once.
These changes do different things:
| Adjustment | What it primarily changes | What to confirm first |
|---|---|---|
| Relay enablement and placement | Which nodes participate in forwarding and where communication paths exist | Is this filling a coverage gap or adding duplicate forwarding in an area already covered? |
| TTL | How many hops a message is allowed to traverse | Where are the target devices, and how far must the necessary alternate paths reach? |
| Network Transmit / Relay Retransmit | The number and spacing of network-layer copies sent by a source node or relay | Does the current SDK field mean the number of retransmissions or the total number of transmissions? |
| Model publishing, queries, and application retries | How many business-layer messages are generated and when they are sent again | Are there frequent reports, concentrated queries, or duplicate submissions? |
TTL is particularly easy to misuse. It limits how far a message propagates; it is neither RF power nor a reliability percentage. A message with a TTL of 0 will not be relayed, so it cannot reach a device that requires a relay hop.[3]
But that does not mean TTL should always be set high. “The message can travel farther” does not mean “this particular light is more likely to receive it.” Unnecessary propagation can also add load in other areas.[1]
A “3” in a configuration interface may mean three transmissions or three retransmissions. Whether the initial transmission is counted separately depends on the SDK interface and parameter encoding. Check the field’s meaning before copying someone else’s number.
4. How Can You Tell Whether Coverage Is Insufficient or There Are Too Many Messages?
Do not draw a conclusion from a single instance of “it worked just now.” Use the same devices, positions, and control actions for two sets of comparisons.
First: Does the problem still occur consistently at distant devices under low load?
In a test environment, retain the necessary control traffic while reducing background queries and reports that you can control. If distant devices remain repeatedly unreachable, and a targeted change to a relay’s position produces a clear improvement, coverage or path problems deserve priority.
That is still not a diagnosis: antenna installation, obstructions, power supply, configuration errors, and other factors may also affect the result.
Second: With device positions unchanged, does the problem appear as traffic increases?
A single on/off command works acceptably, but delays appear when frequent dimming, batch queries, or periodic reports begin. If reducing one category of traffic improves the behavior, investigate radio-channel load, protocol-stack queues, and gateway processing capacity before immediately adding another relay.
Silicon Labs explicitly warns that publishing model messages too frequently increases network traffic and can slow responses.[2] But improvement after reducing the frequency only narrows the investigation; it does not, by itself, prove that every problem was caused by wireless collisions.
There is another often-overlooked check: Is the light reacting slowly, or is its status returning slowly?
The previous article distinguishes between acceptance by the sender, device model status, and the light actually turning on. Record them separately during optimization, or you may adjust a lighting control path that works fine because the interface refreshes slowly.
5. If You Do Tune the Network, Follow a Sequence That Preserves the Evidence
The following is a practical integration-testing sequence, not a standard test prescribed by the protocol.
First, save a baseline. Record firmware and SDK versions, device positions, relay settings, TTL, network-layer retransmission settings, model publishing intervals, and the controller’s query and retry policies. Hide keys when exporting configurations. Without a baseline, it is hard to tell which change made things “better.”
Next, assign a purpose to each relay. Mark on a floor plan which nodes bridge rooms, which cover corridors, and which provide alternate coverage. Keep the nodes serving those purposes first, then evaluate relays with heavily overlapping coverage in batches. Do not turn off a large group at once, and do not use remote configuration to sever the only management path; arrange a way to restore service on site before testing.
Then change only one category of variables at a time. Hold business traffic constant while comparing relay configurations; then hold the relay layout constant while comparing retransmission or publishing frequency. That makes the effects of each change assessable. There is no need to remove all reliability redundancy just to minimize transmissions.
Finally, test during busy periods and failures. Being able to control the lights when the network is idle is only half the job. Also test under dimming, reporting, and query loads that reflect product requirements, and deliberately take a relay node offline and restore it.
Keep at least these records for each round:
| Record | How to make it useful for comparison |
|---|---|
| Test conditions | Use the same positions, actions, load, and observation window; state exactly what changed this round |
| Control results | Record results by “target device × control action”; list unknown status separately rather than counting it as confirmed success |
| Response time | Specify the start and end points: request sent, model status returned, or actual change in illumination |
| Slow responses and anomalies | Keep the sample count, slower samples, and failure locations; do not report only the average |
| Alternate paths | Record which devices are affected when a key relay goes offline and whether they return to normal after it is restored |
Comparing the time at which lights actually change requires suitable on-site observation or measurement. Application logs cannot substitute for the physical result.
The goal of this round is not to find the smallest-looking TTL or the fewest relays. The goal is to retain sufficiently reliable paths under normal load and agreed failure conditions while reducing unnecessary transmissions.
6. Would Switching to Directed Forwarding Make These Concerns Go Away?
Bluetooth Mesh also has an optional mechanism called Directed Forwarding. It allows nodes on a particular forwarding path to forward relevant messages, instead of involving every relay that meets the Managed Flooding conditions, thereby reducing unnecessary wireless transmissions.[3]
But availability in the protocol does not mean the devices, SDK, and configuration tools you have support or enable it. Nor does it replace business-layer traffic design: if the application keeps generating new control messages, queries, and retries, you still need to check whether those messages are necessary.
For an existing project, a more practical first step is to list the features and parameters actually in use, then decide whether introducing a new mechanism is worthwhile. Do not treat a protocol-version upgrade as the answer before identifying the bottleneck.
The next time a distant device occasionally fails to respond, do not enable every relay right away.
First answer one question: Which part of the path will this additional relay bridge?
If the problem appears only when the network is busy, ask another: Which messages on this network do not need to be sent so many times?
Further reading: What It Takes to Move from Broadcasting to Multiple Hops · Why Battery-Powered Nodes Wait for Downlink Messages
References and Scope
- Bluetooth SIG: How Bluetooth Mesh Networking puts the ‘large’ in large-scale wireless networks, 2018-06-26. This article draws on the design principles in its Relays, TTL, and Network retransmissions sections; it does not use their example network sizes, retransmission intervals, or traffic multipliers as product metrics.
- Silicon Labs: Bluetooth Mesh Networking Principles, 11.0.2. Used to check relay density, publishing frequency, and network-layer transmission settings; consult the target SDK for specific interfaces and parameter values.
- Bluetooth SIG: The Bluetooth Mesh Networking primer. Sections 4.18.1, 4.19.2, and 4.19.3 are particularly relevant to TTL, caching, Managed Flooding, and Directed Forwarding.
Sources checked: 2026-11-06. No hardware testing was performed for this article. It provides no universal best settings, fixed node-capacity figure, or promise of performance improvement.
Originally published at ay3s.com.
Top comments (0)