There’s recent example code for the M5StickC, usable on almost any ESP32 device, that shows how to advertise iBeacon. The nice thing about this example is that it also shows the iBeacon parameters on the OLED display.
While adding iBeacon advertising to an ESP32 project can make sense, it’s often not the best choice if you only want advertising functionality. Stand alone beacons are more physically robust, use much less power and settings are configurable via ready-made apps rather than fixed in code.
Depending on the beacon, this can be setup either to only advertise when the key is pressed (button triggered) or advertising all the time and the advertising changes. The former is better for longer battery life while the latter is better when you need to continuously know the beacon is working.
Advertising can be detected:
In apps using standard Apple and Android Bluetooth APIs
A few beacons allow a keypress to be notified to a connected application. Apps on iOS and Android, applications on single board computers and desktops/laptops can connect to a Bluetooth Service Characteristic to be notified when there’s a key press. Connection suspends advertising and prevents the button device from being seen/connected to from other devices.
Long pressing OFF does not cause the beacon to turn off but instead puts the beacon into ‘SOS’ mode where the configured advertising is stopped and the ‘SOS’ can be detected in the configuration app or your custom app and the ‘SOS’ state cancelled.
We sometimes get asked how many connections an iBeacon can support? The answer is ‘1’ but it’s often the right answer to the wrong intended question. The intended question is usually “How many receivers can see a beacon?”
Beacons don’t usually connect. They just advertise and can be seen by an infinite number of receivers that include phones, gateways or single board computers such as the Raspberry Pi.
The receivers only usually connect once, during setup via an app, to set the initial iBeacon parameters. When connected, the beacon doesn’t advertise which prevents extra receivers from connecting. Once set up, the app disconnects and the beacon starts advertising again.
Many gadgets and IoT devices need to connect to the Internet via WiFi. The problem is getting the WiFi credentials to the device when it isn’t connected yet. It’s a ‘chicken and egg‘ situation in that you need to connect to the device in order to set the WiFi settings but you can’t connect because you aren’t WiFi connected.
The usual, but complex, way to solve this is for the device itself to initially act as a WiFi router in ‘station mode’ while the user on a phone, laptop or desktop connects and uses a web interface to set the WiFi settings and then reboot. After rebooting, it’s not in station mode and instead connects to the assigned access point. The assigned local network DHCP IP address isn’t known to the user so they have to examine router settings or use some other contrived method to work out the URL to further administer the device.
None of this is simple for most users so alternative mechanisms are preferable. We previously mentioned Android WiFi Direct via Bluetooth and now there’s a new open standard, Improv, for setting up Wi-Fi via Bluetooth LE.
For Improv, the client (web or mobile) application sends the Wi-Fi credentials to the gadget via a defined Bluetooth LE Service (00467768-6228-2272-4663-277478268000). The device connects to the WiFi and returns a URL on the network that can be used to further administer the device.
Under the hood, a Bluetooth Characteristic is used to send a RPC Command to set up the Wi-Fi settings.
There’s a new Capacitor plugin for Bluetooth LE. Capacitor is new way to build web apps. Capacitor’s native plugin APIs allow easy access to common functionality, such as Bluetooth, across multiple platforms.
The plugin supports the web, Android and iOS. It allows scanning, GATT connecting, reading, writing and notifications. The source code is available on GitHub.
There’s a new Mr Beacon podcast with Eason Huang of Minew. It describes how Minew focus mainly on hardware rather than full solutions and how they provide re-branded hardware for many platforms and beacon providers. Steve Statler (Mr Beacon) provides the insight that many of those platforms don’t really want to sell hardware and they are often focussing on software their customers might not necessarily want.
The conversation turns to the growth and challenges of IoT. The main challenges are lack of clarity of return on investiment (ROI), proof of concepts (POC) taking too long and end results not being scalable. Eason identifies that better preparation is required before starting. Steve suggests projects should initially bring in consultants to provide expert and neutral advice.
The podcast resonates with what we do at Beaconzone. We set up Beaconzone because we identified the reliance on subscription-based cloud platforms and beacons locked to platforms was limiting the available information, products and solutions. We set up BeaconZone in 2015 to provide for standalone solutions, using original manufacture beacons, not locked to subscriptions. We use and stock Minew and tens of other manufacturers’ beacons and gateways.
The issues of IoT projects also resonates with what we have seen through providing consultancy. Too many people come to us, too late, with projects that shouldn’t have been started because they had obvious technical limitations or have been developed in a direction that makes them technically or financially non-viable. A small amount of expert advice, early on, can make a huge difference and reduce risk.
Even when organisations know they should seek initial help and contact us, we sometimes find they are reticent about investing what is a relatively small amount of money compared to a failed POC cost. The reason is that these organisations have no experience of using Bluetooth for IoT so don’t know the unknown unknowns. Everything looks feasible until they are deep into the POC. It’s for these situations that we also offer quick, low priced Micro Consultancy.
We have the LW003-B Bluetooth LoRaWAN® Probe in stock that scans for Bluetooth LE devices and sends detected advertising via LoRaWAN®. This extends Bluetooth sensing up to 15Km.
LoRa provides relatively low throughout so it’s important not to send data for unwanted detected devices. The probe provides extensive filtering options to ensure only the data required for specific Bluetooth devices is sent via LoRa: