Imagine pressing “all lights on” in a meeting room. Most lights come on, but one in the corner does nothing. Your phone nevertheless says “sent successfully.”
You press it again. Everything lights up this time—but will someone have to look up and check after every group operation?
The obvious solution is to make every light say “received” and resend whenever a reply is missing. That provides more feedback, but simultaneous replies and repeated questions can themselves become a network burden.
The short answer: do not automatically resend to the entire group because feedback is missing. Separate three questions: was the command sent, what state did the device report, and did the light physically turn on? Those are different kinds of evidence.
This meeting room is a hypothetical example, not a field test. This article covers SIG Mesh multicast and model messages, not the implementation of products such as Mijia. No success rates, latency or node capacities were measured. State tracking and compensation below are engineering suggestions, not a complete feature automatically supplied by the protocol.
1. How far does “sent successfully” actually go?
The message on the phone might mean only that an application handed a request to a gateway, or that a module accepted a transmission task. Check the interface and logs rather than guessing from the label.
Separate the evidence into three layers:
The sender accepted a task. This proves progress at a sending stage, not receipt at the target light.
A target model reported its state. Generic OnOff Status, for example, reports the corresponding element's Generic OnOff state. Identify the source and distinguish the present value, target value and remaining transition time where applicable.
The physical lighting meets the requirement. This also involves the driver, supply, light source and site conditions. A model saying “on” is not independent optical sensing and cannot rule out a failed driver or LED.
These layers do not require three confirmations for every operation. They mean that the evidence should support exactly what the interface claims.
Check first: find the code or interface definition behind the success message. Does it represent queuing, a module result or target-state feedback? Without that definition, even your success-rate statistics may start from the wrong premise.
2. A group command is not a signed receipt from every member
SIG Mesh commonly uses publish–subscribe for group control: a switch sends to a group address, and relevant models on lights subscribe to it. This is closer to addressing the meeting room once than calling every light individually.
It avoids sending the same intent separately to every device. But a group address does not generate a complete list of members that executed it.
The management side must know the expected members. Was the new light's model subscription configured? Is a replaced device still in the old inventory? A handful of received statuses cannot reconstruct that inventory reliably.
Nor does the number of packets equal the number of completed lights. Match expected elements and models; duplicate messages from one source are not additional completed devices.
Check first: compare installation records with model configuration, AppKey binding and group subscriptions. If one light consistently fails, check whether it belongs to this control group before increasing every relay and retransmission setting.
3. Wouldn't replies from every light be more reliable?
Using Generic OnOff as an example:
- Generic OnOff Set is acknowledged; its response is Generic OnOff Status.
- Generic OnOff Set Unacknowledged does not require a model response to that request.
This is a model-layer response, not a single generic “ACK” covering lower-layer transport acknowledgements, gateway API replies and physical execution.
Waiting for a corresponding response can be useful for one-to-one operations. But if many nodes respond to one group command, radio use is no longer just one command.
Bluetooth SIG's scaling article discusses how multicast replies combined with further queries and retries can create a dense message stream. It highlights unacknowledged multicast control rather than assuming every operation needs a roll call.
That does not mean unacknowledged messages guarantee delivery, or that acknowledged group control is prohibited. It means budgeting both control and confirmation traffic according to the application. More replies do not automatically mean more reliability.
Not requiring a response to this request also does not mean a device never reports its state. State publication and request responses are separate configurations and behaviors to inspect.
Check first: list the message being sent, the response the controller expects, and configured state publications. Only then decide on retries.
4. Missing state should first mean “unknown,” not “failed”
Missing feedback can mean that the command never arrived, that execution succeeded but the return path failed, that a transition is ongoing, or that the controller confused an old report with a new result. A reply/no-reply flag cannot distinguish them.
Consider more honest application labels:
- Requested: the intent was submitted, without sufficient target evidence yet.
- State confirmed: model state meeting this operation's criteria was received, with source and time recorded.
- Needs verification: sufficient evidence was not obtained within the agreed observation window.
These are application design suggestions, not additional standard Mesh states.
Confirmation should not last forever. A wall switch, sensor or automation may change the device later. Show the last confirmation time instead of displaying yesterday's “on” as live state.
Also, Generic OnOff Status does not carry the TID from Set. Do not assume response transaction IDs provide one-to-one correlation. With rapid commands, publications and multiple controllers, evaluate source, value, reception time and application context. A recently received “on” alone does not prove the current operation completed.
5. Why not keep resending to the entire group?
A repeat may recover a lost command, but it costs resources. Most devices may already have completed the operation. Repeating also cannot repair missing subscriptions, disconnected power or driver failures.
A more controlled direction is: send the group command, observe feedback, rate-limit checks of a small set of uncertain members when necessary, and apply bounded compensation only where justified.
Do not turn this into querying every device immediately after each group operation. That merely shifts the same traffic. Test the scope, pacing, deadline and maximum attempts against the deployment size and required response time.
Retries must follow the model's transaction rules. TID in Generic OnOff Set distinguishes a new transaction from retransmission of the same transaction. Do not arbitrarily increment it on every retry, or keep reusing an old value for independent operations. Consult the applicable specification and SDK for complete windows and matching rules; no universal retry interval is proposed here.
Before compensation, ask whether the user has issued a newer intent. If “off” is followed by compensation for the previous “on,” old work is interfering with new work—not improving reliability.
6. Take this checklist to integration testing
This is troubleshooting guidance, not certification or a validated default product policy.
| Observation | Check first | Avoid assuming |
|---|---|---|
| UI says success; one light stays off | Meaning of success, subscriptions, power | All devices are guaranteed to have executed |
| Light is on; UI says failure | State return path, reception handling, observation window | Missing feedback proves no execution |
| Individual control works; group control sometimes fails | Group setup, response/publication traffic, concurrent load | More repeats must improve reliability |
| State is “on”; physical light is dark | State semantics, transitions, driver and light source | Software state equals optical acceptance |
| State oscillates after rapid on/off | Report age, other controllers, old compensation tasks | The last arriving message is the newest state |
| One device never provides feedback | Inventory, model, key binding, subscription, power, coverage | Whole-group retries must fix it |
Keep sender results, model state and physical observations as separate records. Use consistent samples, observation windows and expected membership; do not combine three different criteria into one “success rate.”
Log SDK version, message type, source, destination, time and relevant settings. Mask identities as needed; never publish NetKey, AppKey, DevKey or customer information.
In an isolated test environment, also try individual power loss, rapid operations and concurrent normal traffic. Observe how uncertainty is displayed, how retries stop and whether recovery executes obsolete tasks. Do not inject failures into public lighting or safety-related systems.
7. Reliability is more than “eventually all the lights came on”
The single “all on” button hides three problems: send efficiently, know what evidence you have, and recover from uncertainty without making things worse.
Not every operation needs a complete roll call. But missing feedback must not be marketed as 100% success either.
Before asking how many repeats are best, define expected members, completion evidence, waiting limits and how a newer instruction cancels obsolete work. Then the dark light in the corner becomes something you can diagnose—not merely a reason to press the button again.
Further reading: provisioning and model binding, selection and acceptance checklist and battery-node reception.
Sources and scope
- Bluetooth SIG: Mesh Model v1.1, especially 3.2.1, for Set, Set Unacknowledged, Status, TID and transition fields. Check the specification and SDK adopted by the product.
- Bluetooth SIG: Mesh in large-scale networks, 2018-06-26, for shared radio capacity and multicast response load. Historical examples and parameters are not current product performance claims.
- Silicon Labs: Lighting Demonstration, 11.0.1, for publish–subscribe and group control, not universal vendor behavior.
Sources checked on 2026-11-06. This is mechanism analysis and engineering guidance, without hardware or field performance testing.
The cover is an AI-generated illustration of meeting-room group lighting, not a photograph of a field test.
Originally published at ay3s.com.
Top comments (0)