Define scope, owners and evidence
Testing and commissioning in a beacon deployment is the stage where you confirm that every physical device is doing what your plan requires, and that the system behaves as intended before it enters live service. It sits between the physical mounting of hardware and the formal handover to operations, and skipping it is the single most common cause of early project failure.
Testing covers individual unit verification: checking that each beacon broadcasts the correct identifiers, transmits at the configured power level, and registers an acceptable battery charge. Commissioning is broader. It is the process of confirming that the deployed fleet, taken as a whole, produces the zone behaviour, signal boundaries and platform responses that the project specification demands. A beacon that works perfectly in isolation can still fail commissioning if its signal bleeds into an adjacent zone or drops out where a notification is expected.
The distinction matters because a deployment can pass a quick walk-around check yet fail under real operating conditions. Commissioning is not a casual glance at a phone screen; it is a structured, documented process with pass and fail criteria agreed before testing begins. Without those criteria, every test becomes subjective and every dispute about whether the system is "working" becomes unresolvable.
Why Testing Differs from a Simple Walk-Through
A walk-through with a single smartphone proves only that at least one device, at that moment, received at least one signal. It does not confirm that the identifiers match the floor plan, that signal strength is consistent across the zone, or that the backend platform triggers the correct response. Testing requires multiple device types, measured positions, recorded RSSI values and a comparison against the placement plan. Commissioning adds the system-level view: do overlapping zones resolve correctly, do handoffs between zones behave as expected, and does the platform log the right events?
A controlled delivery sequence
Signal Verification at the Point of Install
Immediately after a beacon is mounted, the installer should verify its broadcast using a scanning tool that displays the UUID, Major and Minor values alongside the measured RSSI. This catches two frequent errors: a beacon programmed with the wrong identifiers before dispatch, and a beacon placed at the wrong position on the floor plan. If the beacon is supposed to mark Zone 3, Major 12, Minor 4 and the scanner shows Major 12, Minor 5, the fault is identified on the spot rather than weeks later during a live campaign.
RSSI should be recorded at a defined reference distance, typically one metre and three metres along the expected approach path. These readings become the baseline for future maintenance comparisons. If a beacon reads -55 dBm at one metre today and -72 dBm at one metre in six months, that change indicates a hardware issue or environmental shift worth investigating.
Zone Boundary Testing
Where a deployment relies on proximity zones rather than precise positioning, the commissioning test must confirm where the zone boundaries actually fall. This means walking the planned boundary path with a scanning device and noting where the RSSI crosses the threshold your platform uses to trigger an action. In practice, that boundary will not be a neat line on the floor. It will shift depending on the receiving device, the angle of approach and the number of people in the space.
For a retail entrance zone, the test should confirm that a customer walking through the door consistently enters the zone, while someone browsing a window display two metres outside does not. For a museum exhibit zone, the test should confirm that standing in front of the exhibit triggers the content, while standing at the neighbouring exhibit does not. Record the actual trigger points on a printed floor plan. If the boundary is unacceptable, adjustment means repositioning the beacon or changing the transmit power, not accepting a compromise and hoping the platform will filter out false triggers later.
Platform Integration Checks
Signal presence is necessary but not sufficient. Commissioning must confirm that the backend platform receives the beacon identifiers and responds correctly. This means triggering each zone or beacon at least once and observing the platform response: does the correct notification appear, does the analytics event log with the right zone label, and does the content match what the campaign specifies? A beacon broadcasting perfectly but mapped to the wrong content in the platform is a commissioning failure, not a hardware fault.
Multi-Device Testing
Bluetooth receivers vary considerably. A high-end Android phone and a mid-range iPhone will report different RSSI values from the same beacon at the same position. Commissioning should include at least two or three device types representative of your expected visitor base. If your venue attracts a mix of devices, test with a mix of devices. If the zone triggers reliably on one phone model but not another, the threshold or placement needs adjustment before the system goes live.
Use-Case Variations
In a retail environment, testing focuses on entrance zones, queue detection areas and product-adjacent triggers where the distance between beacon and customer is small and predictable. In a museum, the priority is exhibit-level zones where visitors may linger, and the test must confirm that a person standing still for thirty seconds remains in zone without the signal dropping. At events, where infrastructure is temporary and crowds are dense, testing should be conducted during a busy period if at all possible, because an empty hall will produce misleadingly clean signal readings.
Confirm the outcome before scaling
Testing Only in Empty Spaces
The human body attenuates Bluetooth signals. A venue full of visitors will produce measurably weaker and more variable RSSI readings than the same venue empty. If commissioning is completed on a quiet Monday morning, the results may not hold on a Saturday afternoon. Wherever possible, schedule at least some testing during representative operating conditions. If that is not feasible, document the limitation and plan a verification pass once the venue is busy.
Accepting Marginal Signals
A beacon that barely registers above the trigger threshold is a problem waiting to happen. Small environmental changes, a new display unit, a crowd, or a firmware update on the receiving device can push a marginal signal below threshold. If a zone trigger requires an RSSI stronger than -75 dBm and the beacon reads -74 dBm at the critical point, that is not a pass. Build in a margin. A practical approach is to require the measured RSSI at the zone boundary to exceed the trigger threshold by at least 5 to 10 dBm, though the exact margin depends on the variability observed during testing.
Not Documenting Results
Verbal assurances that "it all looked fine" have no operational value. Commissioning records should include, for each beacon or zone: the beacon identifier, the mounted position, the RSSI at defined test points, the device used, the platform response observed, and a pass or fail status. These records become the baseline for maintenance, the evidence for any dispute with an integrator, and the reference if something changes in the venue layout later.
Skipping Identifier Checks
It is tempting to assume that beacons arrived pre-configured correctly and move straight to signal testing. In practice, mislabelled beacons are common, particularly in deployments of fifty or more units where programming was done in batches. A quick identifier check takes seconds per beacon and prevents the much more time-consuming task of tracing a misbehaving zone back to a swapped label weeks later.
Ignoring Interference from Existing Infrastructure
Wi-Fi access points, other Bluetooth devices, LED lighting drivers and metal fixtures can all degrade beacon signals. If commissioning reveals unexpected dead spots or highly variable readings in a specific area, investigate what else is operating nearby before adjusting beacon placement. Moving a beacon away from a Wi-Fi access point by a metre may resolve the issue more effectively than increasing transmit power, which would also increase zone bleed into adjacent areas.
Key Checks to Run Before Declaring Commissioning Complete
- Every beacon identifier matches the placement plan.
- Every beacon battery level is at or above the accepted commissioning threshold.
- RSSI readings at defined test points meet the specified margin above the trigger threshold.
- Zone boundaries fall within the intended areas on the floor plan.
- The platform triggers the correct response for each tested zone or beacon.
- At least two different device types have been used for testing.
- Results are recorded with date, time, device details and pass or fail status.
- Any failures have been rectified and retested before sign-off.
Commissioning is complete when the documented evidence supports a reasoned conclusion that the system will perform as specified under normal operating conditions. It is not complete when the installation team has packed up and left. The sign-off should involve someone who was not part of the installation, ideally the operational manager who will be responsible for the system from that point forward. That separation of roles is what turns testing into commissioning: an independent acceptance that the deployment meets its specification, not just that the installers believe they have finished.
