I'm involved in a business case where this will pop up as a question sooner or later, for deployment simplicity reasons:
For iOS, the integrated iBeacon support will be used. For Android, the AltBeacon library (by Radius) will be used.
Are there any fundamental problems and gotchas if all beacons for a given content/interaction, and in close proximity to each other, and possibly also overlapping, share the same UUID, Major ID and Minor ID?
They will all ping the same info, so in theory at least the app will just see a lot of pinging from seemingly the same device, unless somewhere in the system also MAC address will play a role to identify the source.
I'm thankful for any practical advice about this. We are potentially talking hundreds of beacons spread out in moving vehicles, with more than one per vehicle.
Regards, Anders
While the typical best practice is to give each beacon a different unique identifier, there are some use cases where it is helpful to give multiple physical beacons the same identifier. Both iOS and Android will properly handle the case of multiple beacons in range with the same identifier, but it is important to understand how it works:
On iOS CoreLocation, ranging callbacks will contain multiple beacon instances in the beacons array with the same identifiers. Internally, the OS keeps them distinct by Mac address, but there is no way to access this Mac or any other proxy for it using Core Location. So while you can tell how many beacons are around and get rssi and distance estimates to each, you cannot tell which beacon is which.
With the Android Beacon Library, by default all beacons with the same identifier are combined into one, with their RSSI measurements averaged and used to create a single distance estimate. However, you can configure it to behave the same way as iOS by setting Beacon.setHardwareEqualityEnforced(true). When you do, each beacon will be kept distinct by Mac address, and unlike iOS, you can also read the Mac with beacon.getBluetoothAddress().