Define the service before assigning tasks
In any deployment of Bluetooth beacons or similar proximity hardware, firmware and configuration are distinct but tightly linked concerns. Firmware is the low-level software embedded on the device by the manufacturer, controlling the Bluetooth stack, power management and supported broadcasting formats. Configuration refers to the specific parameters applied to that firmware: the advertising interval, transmit power, UUID, Major and Minor values, and security locks.
Managing these two layers properly is what separates a stable, predictable installation from one that quietly drifts out of spec. Mobile operating systems evolve, and changes to how iOS or Android handle background Bluetooth scanning can render older firmware versions unreliable. Similarly, a configuration pushed to a single beacon can behave very differently once that same setting is applied across hundreds of devices in a physically complex space.
Updates to firmware are delivered either Over-The-Air (OTA) via a gateway or a mobile app, or through a wired connection to a PC. Configuration changes are typically pushed via Bluetooth from a mobile app or a dedicated gateway. Both processes require a clear understanding of the device's current state, as interrupting an update can render the hardware temporarily or permanently unresponsive.
Tools, records and handover practice
Initial provisioning and batch consistency
When a retailer or venue takes delivery of a shipment of beacons, the first operational task is ensuring every unit runs the same firmware version and shares a baseline configuration. Beacons ordered months apart often arrive with different factory firmware, even if the hardware model number is identical. Applying a standardised configuration—setting a consistent advertising interval and transmit power, assigning identifiers, and enabling connection locking—must be done methodically to prevent duplicate identifiers or mismatched broadcast behaviours in the field.
Adjusting to physical changes
In a museum, exhibits move. When an exhibit is relocated from an open gallery to a narrow corridor, the transmit power on its associated beacon may need reducing to prevent the signal from bleeding into adjacent zones and triggering incorrect content. This requires a targeted configuration change to a single device, verified on-site with a signal scanner, without disrupting the broader fleet.
Event reuse and configuration wiping
For event organisers, beacons are often deployed for a weekend and then placed back into storage. Before the next event, the previous configuration—specific identifiers, custom passwords, and locked states—must be wiped and replaced. If a device is locked with a password that has been lost by the operations team, the beacon becomes practically useless until a factory reset, which often requires a physical wired connection.
Version control across a fleet
Maintaining a record of which firmware version sits on which physical unit is essential. When a manufacturer releases a patch to improve battery management or fix a broadcasting bug, the operations team needs to know exactly which beacons require the update. This relies on an accurate asset register cross-referenced with firmware versions, rather than assuming uniformity across the fleet.
Review points and lifecycle decisions
Failing to lock configurations
Leaving a beacon unlocked means anyone with a generic scanning app within Bluetooth range can alter its advertising interval, transmit power or identifiers. In a public-facing venue, this is a significant operational risk. Configuration locking should be standard practice once a device is placed, with the lock password recorded in the asset register.
Mass updating without a pilot
Pushing a firmware update to an entire fleet simultaneously is a common error. If the new firmware contains a bug, or if the update process is interrupted by a low battery or weak connection, the beacon may "brick"—becoming unresponsive to further OTA commands. The safe approach is to update a small pilot batch, verify stable operation for a set period, and then roll out the update in stages.
Ignoring battery state before updates
OTA firmware updates require sustained power and a stable radio connection. If a beacon's battery is already depleted, the power spike required during the write process can cause the device to shut down mid-update. Checking battery levels before initiating an OTA update is a basic but frequently overlooked step.
Assuming identical hardware means identical firmware
Two beacons that look identical and share the same model name can behave differently if one was manufactured a year later. Relying on visual inspection or model numbers alone to confirm firmware parity leads to inconsistent broadcasting behaviour. Always verify the firmware version reported by the device itself.
Key checks before and after changes
- Pre-update: Record the current firmware version, configuration parameters and battery level for each device.
- During update: Maintain a stable, close-range connection and avoid moving the beacon or introducing significant RF interference.
- Post-update: Verify the new firmware version is correctly reported, re-apply the desired configuration if the update wiped settings, test the broadcast with a scanner, and re-lock the device.
- Documentation: Update the asset register with the new firmware version and the date of change.
Firmware and configuration management is fundamentally about maintaining control over the physical hardware once it leaves the staging area. Without disciplined processes for tracking versions, securing settings and staging updates, even a well-planned deployment will degrade over time as devices drift out of sync with the platform and each other.
