For some of our beacons such the manufacturers haven’t documented their Bluetooth Service Characteristics. This means that while they are ok for scanning/proximity type applications, you can’t write your own app to, for example, change programmatically the UUID, major and minor, transmit power, advertising period and must rely on the manufacturer’s configuration app. While this of no consequence for the majority of uses that set and forget settings, more ambitious scenarios might want directly access the Bluetooth GATT services to change settings.
Uri Shaked has a great article on Medium on how to Reverse Engineer a Bluetooth Lightbulb. His method uses the developer logging in Android 4.4 and later to allow inspection of the Bluetooth packets and hence the Bluetooth Services and Characteristics that are being used. This method can equally be used with iBeacon and Eddystone beacons to reverse engineer the Bluetooth GATT information.
It’s usually ill-advised to reverse engineer interfaces to discover undocumented features because the manufacturer can change the implementation thus breaking your solution. However, it’s very rare that firmware is ever updated in beacons and when it is, it’s usually only to fix bugs rather than change the implementation.
There are lots of brands of iBeacon and Eddystone beacon. Each brand has its own management app. We have often been asked,
“Is it possible to have just one app to manage different brands of beacon?”
While it’s technically possible, there’s no incentive for anyone to create such an app. Creating just one app to manage one beacon brand, across iOS and Android is significant effort in itself.
Google identified this problem and created the Eddystone Configuration GATT Service. The idea is that if manufacturers used just this, apps and beacons would be inter-operable. However, people want to configure iBeacon as well as Eddystone. Manufacturers also want to allow users to configure and read sensor data. Also, using Eddystone Configuration GATT Service software in all future beacons does nothing to help manage the large number of beacons that are already out there.
As of writing this, in 7 years since Eddystone Configuration GATT Service was published, no apps have been published that work with the Eddystone Configuration GATT Service. However, the Nordic nRF Connect app does understand some of the Bluetooth Characteristics to better read these kinds of beacons. There hasn’t been a rush for manufacturers to use Eddystone Standard GATT.
Back to the question. It looks like there will be a separate app per manufacturer for the foreseeable future.
When in typical use, it’s not necessary to connect to a beacon. A beacon just advertises and is detected by a smartphone or Bluetooth gateway. However, to initially set up a beacon you usually connect via a smartphone app. The app might not connect for a number of reasons. Here are some tips:
Most beacons need to be put into ‘connectable’ mode. For example, for most AnkhMaway beacons this means tapping them sharply on a table until they ring – they remain connectable for 45 secs and once connected remain so until you have configured the beacon. For Axaet and Meeblue beacons they stay connectable for a few minutes after turning them on.
Make sure you are connecting to the correct beacon. This is especially important if you are seeing multiple Bluetooth devices in the list. For example, we had one customer who hadn’t removed the plastic battery slip and had been trying to connect to some other Bluetooth beacon/device.
Connecting, via what is a wireless interface, might not work first time. While most connections do happen first time, there can be radio interference and radio signal reflections that can cause the connection to fail. Some configuration apps re-try if the first connect fails while others don’t. Make sure you have tried a few times before concluding a particular scenario doesn’t work.
Some phones have a faulty Bluetooth beacon stack. That’s the Bluetooth software built into your phone. While you might be able to view the beacon, connecting to it to change settings uses more advanced functionality that’s sometimes faulty. Over time, we have discovered about 5% of our customers have such problems, more so on Android. It’s a much more common problem than a faulty beacon. You can isolate this possibility by trying a different phone and/or different phone OS type.
Don’t try connecting from more than one phone at a time. When connected, that phone has exclusive access to the beacon and other phones won’t be able to see the beacon and connect.
Make sure you are using the correct password to connect. It’s not the password on the sticker which is the web site technical area password.
Try rebooting your phone to reset the internal Bluetooth software.
Try resetting the beacon by removing and replacing the battery (where possible). This isn’t the same as turning off via a button press which usually only puts the beacon into hibernation and doesn’t restart the device.
Some configuration apps have known bugs. Read the BeaconZone technical area for your particular beacon manufacturer where we document known problems and workarounds.
The beacon could be faulty. This is actually a very rare occurrence and you should initially be considering other more likely possibilities (above). You can isolate this possibility if you have another similar beacon. Please contact us for replacement if you conclude you have a faulty beacon.
Avoid the libraries produced by the beacon manufacturers. They tend to add little value, are usually poorly documented and aren’t changed when there are updates to underlying Android libraries. You can achieve everything with the Android APIs. The only exception is connecting via GATT to Sensoro beacons where the Service/Characteristic information isn’t publicly available and hence you have to use their SDK.
If you are developing a beacon app to receive unique iBeacon and Eddystone ids (as opposed to URLs), an area you should think about is caching text, images and other media.
Beacons transmit unique ids and these ids need to match up with information held elsewhere, not on the beacon, that determine what the app does and what’s displayed to the user. The problem is that in many scenarios the beacons have to be placed where the user is likely to have no or poor Internet connectivity. Poor connectivity can be as just as bad as no connectivity if larger size media such as images needs to be downloaded.
Your app and sometimes server design might need to take into account the caching of information. Some of this information can usually be bundled with the app at the time of install while information that needs to be up to date might need to be fetched ahead of time. In some cases, you might need to use a combination of the two with information bundled with the app being replaced as new information becomes available.
Here are the kinds of things you need to think about:
What information is included at the time of install. In the extreme case, where you think a large number of people will be foreign and roaming, this could be all your information.
Whether the bundled information needs to be updated at the time of install.
A server side mechanism to determine when information is out of date and needs to refreshed. Such mechanisms should prevent the same information from being downloaded more than once.
A client, app side mechanism to get notified of information updates.
Whether the information is updated in app background or under control of the user.
For optimal display of images, provision of different size images for different (screen) size devices.
Strategies to reduce client device resources (battery) and server stress. This might include grouping associated information that’s likely to have to be used together.
What the end user sees when information is being updated or not available yet.
If and how information eventually gets purged to save space.
A alternative to complex caching schemes is to provide free on-site WiFi. This is particularly suitable for indoor visitor spaces such as museums and galleries. This way the app can be less complex and data fetched as needed. However, remember there will always be some people who, for security reasons, won’t connect to public WiFi.
The app scans for advertising devices, optionally with a specific CoreBluetooth UUID, and displays them including RSSI (signal strength). It can connect to devices that are connectable and then browse device the Bluetooth Services and Characteristics. For iBeacons, it’s also possible to observe region updates for specified beacons.
The app monitors and graphs recent RSSI values. You can also set up your device to advertise iBeacon or custom services with custom Bluetooth Characteristics.
There’s a new app for iOS called Stepping In & Out that uses iBeacons to remind you when you move into or out of an area containing a beacon.
The source code is available on GitHub. It provides an example how to create an app using Swift that triggers when going into and out of zones. This can also be used for commercially oriented applications.
Flutter is Google’s UI toolkit for building native applications for mobile, web, and desktop from a single codebase. There are plugins that add functionality to Flutter. One such plugin is the beacon_plugin that makes it easier to scan and range iBeacons on iOS and Android. The plugin is open source on GitHub.