iBeacon, Eddystone, Bluetooth, IoT sensor beacons, apps, platforms
We have a new variant of the waterproof, long range (up to 200m) i3 in stock. This differs to the previous i3 in that it uses the newer Nordic nRF52 SoC for improved battery life up to 5 years depending on the settings and the type of batteries (takes 2 x AA).
This beacon advertises up to 6 channels that can be iBeacon, Eddystone UID, Eddystone URL, Eddystone TLM and device info.
The iB003N can transmit up to three channels: iBeacon, Custom and Accelerometer Data. If you only want to send iBeacon, the iOS and Android app ‘Config’ screen implicitly sets the state to iBeacon only transmission when you set the iBeacon parameters.
On iOS only, the Eddystone screen allows you to set the custom channel to send Eddystone that implicitly sets the state to transmit the Custom channel only.
What if you want to transmit both iBeacon and Custom channels or also send the acceleration data? What if you want to enable motion triggered broadcasting? For cases such as these, you have to set the beacon state explicitly (manually) via the Bluetooth Service Characteristic 0x2A80 as described in the iB003N user guide .
Sleepy bit rot on Twitter has produced a useful table showing what values have to be set for some specific configurations:
We previously mentioned there are currently no app examples of how to provision Bluetooth mesh devices via apps on smartphones. Well, Filip Nowakowski has announced:
Hi, the lib #BluetoothMesh for iOS is now public (alpha version) https://t.co/k5lrZYrUT1. Similar for Android will follow in few weeks. We'll continue to fix features and add bugs, or something like that. Feedback is welcome.
— Filip Nowakowski (@AFNowakowski) April 27, 2018
Want to experiment with beacons without buying one? There’s a new command line tool mBeacon that allows you to set up your Mac to advertise iBeacon.
You use by typing the following command:
$ mbeacon -uuid "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" -major 0 -minor 0
The ability to easily change the UUID, major and minor is also useful for development purposes where you wish to test, for example, an app that’s looking for lots of different beacons.
Nordic, who provide the System on a Chip (SoC) in many beacons, have released v2 of their Mesh SDK that implements standard Bluetooth Mesh.
The main improvements are around support for Bluetooth GATT. It’s now possible for devices such as commercial beacons or smartphones to participate in the mesh via the GATT Proxy mechanism. It’s also possible for devices such as smartphones to provision new devices via GATT through Provisioning Bearer GATT (PB_GATT) rather than via firmware API or the serial API. Unfortunately, there are currently no app examples so there’s a large learning curve and development mountain to overcome to implement products based on these mechanisms.
Martin Woolley, who works for the Bluetooth organisation as an evangelist, has new slides (PDF – needs login at Google for some reason) from a Bluetooth Mesh talk at DroidConIT. The slides explain many of the mesh concepts. Here’s the slide showing the GATT proxy mechanism:
The documentation for Mesh v2 is on the Nordic web site.
Sensorberg has a great new video that provides inspiration regarding what’s possible in the smart workspace:
This video also provides a learning for marketers. As with all the best ideas (and promotion), it’s often best not to mention how things are achieved – in this case predominantly using beacons. People don’t need to know this and are more interested in what it does, the benefits and how it makes people feel.
We coincidentally had two customers last week with the same query and the same resolution. They wanted to know why their ultra long range beacons weren’t achieving the expected range.
It turns out both customers where expecting the beacons to transmit through obstacles. It’s important to understand what can block signals. When a signal gets blocked, there’s no point trying beacons with longer ranges in the hope they will push the signal through the physical obstructions. Longer range beacons only work long range when there is unobstructed line of sight such as in a large warehouse or event space.
In recent years there has been a movement towards software being provided “as a service” whether supplied free to induce users to buy/use other services/products or via a subscription model. The software provider usually gains through having a long term revenue stream. Companies gain easy access to ready-made and managed solutions to their problems. It all sounds perfect. However, there are risks in using Software as a Service (SaaS) that need to be understood and managed.
Creating an app or platform that integrates a 3rd party SaaS API ties you to that platform. If the platform is discontinued you have the complex task of re-writing to use the new API and migrating existing data. If there’s no similar alternative, you are faced with implementing the SaaS provided service for yourself.
Most SaaS providers are VC funded which means they tend to initially give away their APIs for free or at low cost to attract customers. Once shareholders start to want to see revenue, monthly fees increase. We are already seeing this with many beacon platform providers. Once Angel or VC funding runs out, platforms can disappear. A high profile example in the beacon ecosystem at the moment is Onyx.
The risks aren’t constrained to using VC funded companies’ services. Google has recently removed services related to the Physical Web. They are about to deprecate Google Cloud Messaging (GCM) that’s used in thousands if not millions of apps.
So what can you do? The first thing is do your due diligence. Is the company providing the SaaS you are considering likely to be around for the lifetime of your project? Is the company (like Google) renowned for deprecating services? Do you really need all the SaaS functionality or could you make do with a simpler developed or open source solution? Might you be able to use the SaaS for a proof of concept or minimum viable product (MVP) and plan to move to a developed solution?
Important: This web page is provided for historical purposes.
On 25 October 2018, Google announced they are discontinuing Nearby Notifications on Android. This mechanism should no longer be used.
Read about using Beacons for Marketing
There has been speculation that the Physical Web, as championed by Google, is dead.
Here’s what we know:
In summary, while new development on Physical Web is dead, the mechanism still works and Google is still applying fixes. Google has removed some functionality that was rarely used and has disbanded the Physical Web team. However, Google is still maintaining the Physical Web proxy and Eddystone notifications still work on Android.
Meanwhile, a group of people led by Agustin Musi from Switzerland is contemplating creating PhysicalWeb2. There’s a Slack channel you can join or you can email them at contactus@phwa.io. There’s also a new site at phwa.io.
Read about using beacons for marketing.
The latest Spring 2018 WirelessQ Magazine (pdf) from Nordic demonstrates some diverse uses of beacons. For example, it mentions the use of Beacons to open doors for the visually-impaired:
A later article in the magazine explains how Bluetooth Low Energy is rapidly
expanding into industrial markets:
“Bluetooth LE technology is growing far beyond its consumer roots by underpinning innovative solutions for the Industrial Internet of Things”