We catch notifications using beacons
Hi, my name is Ilya Garakh , I have my own studio where I manage mobile and web development, in parallel I develop and promote several startups. About the Bluetooth beacons for the first time I heard from the next presentation of Apple, and at that time the whole idea seemed dubious and confusing. Later, my colleagues and I returned to the topic of beacons: an interactive reaction to movement and high positioning accuracy in rooms looked very tempting.
Article author Ilya Garakh, in the framework of the competition "Device Lab from Google . "
But the blast of joy was overshadowed by the limitations of the devices, because only new iPhones and the latest versions of devices on Android were able to work with BLE (Bluetooth with low power consumption) at that time, so this solution was difficult to promote as working for a wide audience. Over time, the percentage of devices supporting BLE has grown significantly, so in early 2016 we purchased ibeacon beacons for testing. Since this all started.
If you do not know, ibeacon is the protocol (format) of BLE interaction invented by Apple. There are many lighthouse manufacturers on the market that transmit data in this format. The first beacon that came into my hands was the ibeacon beacon from iBecom.
')
He was delivered in a mailing envelope, without any instructions (actually, like any other beacons), and I had no idea what to do with it further. A long correspondence with the technical support of “iBecom” began, during which it became clear that the beacon can only be configured via the iPhonne app (you had to send registration requests to some of their internal portal), and the owners of Android devices can download any Beacon management application from the Play Market. I wanted to do quests from the iPhone; Android apps really saw a beacon, but none of them allowed it to be customized, the question: “So it should be?” remained unsolved.
By the way, all the applications showed different distances to the lighthouse: from 1 to 10 meters, although the lighthouse lay a few inches from the phone. It was so moving, and I began to look for feedback on real implementations. It turned out that positioning works fine in test rooms, but in real conditions the signal strength depends not only on the battery and the distance, but also on the walls, partitions, and everything else that is in the premises. Therefore, even if you have a lot of lighthouses stumbled out and you know their coordinates, then most likely it will not be possible to stragangate and accurately determine the location of the phone. This task is solved by creating a "map of signals" for micro-locations: arrange beacons, take a device and walk around the area, scan beacons in each small zone, read the strength of their signals, somehow hash the whole thing, the resulting hash will identify the micro-zone .
Small retreat
So, for Cordova, there was and is a ready - made plug - in for working with ibeacon. It was easily installed and quickly managed to build the first test application. The phone quite steadily caught the approach to the beacon and exit from the "visibility" zone. I do not remember the exact characteristics of the “iBecom” lighthouse, but they usually state that the lighthouse is caught at 10 meters (and some at 50 or more). My phone "lost" a beacon in one room when removed from it by about 4 meters.
Another interesting feature was that for catching a beacon, you must specify its UUID (you can find out the UUID using any application for working with BLE and beacons, you can also change the UUID, but you need software from the manufacturer)
And so on in the loop. The lighthouse notice will return to your callback. Thus, you need to know in advance the UUID of all your lighthouses, and it is impossible to do a broadcast search (looking ahead a bit - broadcast is still possible, though through ... one place).
Having played with ibeacon, we realized that in general it can be used as an additional “feature” and to catch the “client” when he comes close to the lighthouse, for example, sits down at the table or approaches the product. It seemed technically possible to use beacons for positioning in rooms, but it was too troublesome. Well, of course, the “client” should install your application.
As a result, we implemented this plug-in in test mode into a real application and everything went smoothly, nothing broke and did not conflict (if you are not familiar with Cordova, then problems with curves and conflicting plug-ins are something that you constantly have to spend time on in development, we call this problem “Cordova Plugin Hell”). After making sure that everything works, I ticked off the ibecon and with a clear conscience laid the beacon for the future.
Quite recently, I learned that besides ibeacon there are other protocols for the operation of lighthouses. This of course is about Eddystone, who invented Google, as well as Altbeacon, who invented the community. This brought me back to the thoughts about the lighthouses and their capabilities, and when I saw a post on Habré about the possibility to test Eddystone lighthouses, I could not pass by and applied for participation. And after a few weeks on my desk lay an eddystone beacon from the manufacturer Accent System.
If you are not up to date, the Eddystone format includes more data than iBeacon, which essentially transmits only a 16-byte UUID, as well as two numbers (major and minor values), and you can only catch this data in your application. . Eddystone allows the beacon to work in different modes: just like iBeacon, to transfer the UUID (in eddystone it is called the UID), transfer the URL (which is sewn directly into the beacon, and you can configure it), telemetry (beacon meta-data, heat), and also EUID transmission mode and its cyclic change.
The main chic is that Android phones that support BLE are able to catch Eddystone from a URL automatically - you do not need to install additional applications. Just turn on Bluetooth, go to the beacon and catch the notice that the phone has found the link.
Other technologies do not want to understand iPhone without crutches, but they can catch the URL if Google Chrome is installed.
Of course, I immediately wanted to check out this feature. On the manufacturer's website, I found a link to the application in the Play Market, which can be used to configure the beacon. The beacon was found, without any problems, I transferred it to the configuration mode (you need to pull out and insert the battery back, and within 30 seconds the beacon goes into Dev mode). I registered the URL, saved everything and waited for what would happen next. And nothing happened.
Of course, great Google will come to the rescue. I used to read about the Google Beacon Dashboard (this is the cloud control panel of beacons), about the Google Proximity API and NearBy API. It turned out that using a special mobile application (Google Beacon Tool) you need to catch the bacon and register it in the cloud, after which you can configure the URL and many other parameters via the web interface (attachments, map binding, etc.). ). All this blew up the brain quite well and thoroughly confused, but after about half a day of studying manuals I began to understand what was happening.
So:
The main goal of Google Beacon Dashboard and NearBy API is to implement beacons and manage their parameters through the web without developing your back-end for this. And the Google Proximity API is used if you need to embed beacon management into your project.
The problem was that my phone stubbornly did not want to catch the beacon with the URL. It turned out that I had a ban on the search for public links that can be removed in the Google settings in your Android device (it’s Google settings, not the system, and if you haven’t crawled there, you will find a lot of interesting things).
Deal with this problem. For the sake of interest, I checked the phones of all my closest colleagues and acquaintances: no one had such a garbage and after turning on Bluetooth, all the devices immediately caught the link. They wrote off everything on the weirdness of the settings of my device.
Then I tried to register the Eddystone beacon in the Google cloud, but the Google Beacon Tool stubbornly did not find Eddystone, although iBeacon (from iBecom) was found right away, and there were no problems with it. After an abundance of vain attempts, I wrote to the support of the manufacturer Accent Systems (by the way, if you are going to extensively introduce these beacons, please note that no one speaks Russian there by itself). I received a response from Accent Systems in 3-4 business days, which in my humble opinion is not at all fast.
In response, they sent me a link to Dropbox, where I could download a new version of the application for configuring the beacon and new documentation. A new application reflash the beacon, the Beacon Tool has finally found it. It is worth noting that the whole story with downloading the application from unclear links looks at least doubtful for a serious device manufacturer (and, by the way, Google partner).
According to Accent Systems, their eddystone beacons can simultaneously broadcast as 4 regular eddystone and 2 ibeacon.
In practice, I never managed to get slots to work, except for the first one. By the way, the realization of this fact took a lot of time, because at first I set up the 3rd slot and for a long time could not understand why nothing was working.
Thus, my Eddystone lighthouse could broadcast simultaneously as ibeacon and as eddystone (in any mode), i.e. 1 + 1 instead of the stated 4 + 2 simultaneous slots.
After the beacon with Eddystone was able to establish stable operation, it is time to develop a test application. As I wrote earlier - we will do everything on Cordova.
We are looking for plugins to work with eddystone for Cordova and immediately find this one . This is a plugin from Evothings , which develops and supplies various solutions for BLE devices.
I uploaded the final version of my test application to the githab .
Without going into the details of our internal kitchen, the example is based on our internal application framework, which runs on the F7 Framework and RequireJS. All main code is here .
I added a plugin (cordova-plugin-eddystone), copied their example, crashed the application and launched it on the phone.
A small digression for those who want to use Cordova. We do not build applications locally; instead, we deploy a build server to Digital Ocean. All of this can be integrated with your CI solution or handicraft scripts. As a result, when pushing, the build server is notified, pull-it changes and starts the build. The whole process is thoroughly commented on by our bot in Slack (with the text from commits), so everyone is always aware of what is being built, and when everything is ready for installation. In general, it is easy to set up feedback and, through ADB, automatically install applications on the phone.
You can test the core logic of Cordova applications in the browser, because in essence the application is a regular web site. We found this approach extremely convenient, because you don’t have to worry about environments, Java versions, Cordova, which Android Targets are installed, and the build server comes up from the snapshot in 1 minute. Of course, this is a story about Android, adaptation, build and production for ios are different.
If you decide to go this way, I recommend adding to the build the removal and addition of the platform, it will save you from many problems with plug-ins.
So, after the example build, I immediately plugged in the debugger (via chrome: // inspect) and saw that even though the example works without errors, it does not find any bacons. And this is absolutely normal for Cordova - plugins very often do not work as they should. I started learning the cordova-plugin-eddystone plugin and found the code that triggers the BLE scan .
The magic number 0000FEAA-0000-1000-8000-00805F9B34FB is the identifier of the Eddystone beacons. It is passed to other plug-in methods and eventually goes to the Java plug-in. We study the source code of the evothings.easyble.startScan method and understand that it is not necessary to transmit an identifier. Remove it and see what happens - the plugin catches the beacons, what you need!
Moreover, now the plugin catches all BLE devices, including non-beacons. And this is great, let it catch, and somehow we will decide what to do with this data.
A small digression for those who want to use Cordova. Connect your phone via USB, enable debugging, open in Google Chrome: // inspect and select your application. You can debug it as a normal site, as well as directly on the fly to change the JS-code.
Ok, I fork the plugin and start making changes.
First of all, we remove the line
I see that now the plugin catches ibeacon, but brushes it aside for further validation. I read the documentation on the format ibeacon and eddystone. All beacons send Scan Record, which contains all the data. In base64, it looks something like this:
We convert to hexadecimal system:
And we read the description of Scan record for ibeacon format:
We see that 6-8 bytes (x4c000215) are constants, followed by the UUID ibeacon. Parse scan record, find these 4 bytes and count the next 16 bytes. Then we convert everything into a string of a type format:
a07c5ca8-59eb-4ea8-9956-30b776e0fedc
( https://github.com/garakh/cordova-eddystone/blob/master/js/eddystone-plugin.js#L534 and further along the code).
I finish other trifles and validations, I launch, check - everything works as it should, now, apart from eddystone, the plugin also catches ibeacon. You do not need to specify in advance the UUID ibeacon, because the plugin catches everything.
I push the plugin and proceed to the implementation of Eddystone in the real application.
It's time to introduce you to one of the startups in which I take an active part.
Loya - loyalty as a service. Loy gives businesses the ability to quickly and easily implement loyalty programs, providing dashboards with analytics, APIs and other tools.
One of the chips is a business can order a mobile application where customers can save points and receive gifts. And if a business wants to make a quick start, it can offer its customers a common solution: Loy's client application, in which all other companies are present.
This is where we’ll add support for Eddystone. In order not to complicate the design of a simple algorithm for working with beacons:
Algorithm for the company:
Ok, so add to the dashboard control beacons:
By the way, the frontend is working on Angular 1.x, RequierJS, Bower, Gulp. Backend: PHP Phalcon, MongoDB. Excellent bundle tested on many projects. We add server API and we pass to programming of the mobile application. Since everything has already been tested, then we add our forc plug-in and enjoy bacon fishing.
Final video and release
Those. Not all devices support BLE. We keep several versions in the market. Version 0.1.0 with bacon support (will work on Android 5+) and 0.0.8 without support (4 versions of Android will work).
About 30 man-hours for studying and testing were spent and 5 hours for integration into the combat application, development of the back-end and release. Work with beacons in the network is still poorly lit and confused. You have to communicate with the support of the beacon manufacturers, and by their answers you understand that the manufacturers themselves do not work much better.
To use the beacons for indoor navigation, in my opinion, it is possible, but so far it is rather doubtful, and it is being implemented with great labor costs. Accent Systems hasn’t earned on all slots.
The battery of the iBecom beacon died about 6 months later (the beacon was just lying on the table), although almost 2-3 years of work were announced.
Eddystone URL - in my opinion a very promising thing, does not require special applications and the only thing that worked out of the box without shamanism.
Eddystone is a clear winner in comparing Eddystone and iBeacon. I see no reason to buy ibeacon beacons, which stand the same way, work just as crookedly, and in terms of functionality, they are several years behind.
Article author Ilya Garakh, in the framework of the competition "Device Lab from Google . "
But the blast of joy was overshadowed by the limitations of the devices, because only new iPhones and the latest versions of devices on Android were able to work with BLE (Bluetooth with low power consumption) at that time, so this solution was difficult to promote as working for a wide audience. Over time, the percentage of devices supporting BLE has grown significantly, so in early 2016 we purchased ibeacon beacons for testing. Since this all started.
If you do not know, ibeacon is the protocol (format) of BLE interaction invented by Apple. There are many lighthouse manufacturers on the market that transmit data in this format. The first beacon that came into my hands was the ibeacon beacon from iBecom.
')
He was delivered in a mailing envelope, without any instructions (actually, like any other beacons), and I had no idea what to do with it further. A long correspondence with the technical support of “iBecom” began, during which it became clear that the beacon can only be configured via the iPhonne app (you had to send registration requests to some of their internal portal), and the owners of Android devices can download any Beacon management application from the Play Market. I wanted to do quests from the iPhone; Android apps really saw a beacon, but none of them allowed it to be customized, the question: “So it should be?” remained unsolved.
By the way, all the applications showed different distances to the lighthouse: from 1 to 10 meters, although the lighthouse lay a few inches from the phone. It was so moving, and I began to look for feedback on real implementations. It turned out that positioning works fine in test rooms, but in real conditions the signal strength depends not only on the battery and the distance, but also on the walls, partitions, and everything else that is in the premises. Therefore, even if you have a lot of lighthouses stumbled out and you know their coordinates, then most likely it will not be possible to stragangate and accurately determine the location of the phone. This task is solved by creating a "map of signals" for micro-locations: arrange beacons, take a device and walk around the area, scan beacons in each small zone, read the strength of their signals, somehow hash the whole thing, the resulting hash will identify the micro-zone .
Small retreat
We are not engaged in native mobile development, and use Cordova. Cordova has its advantages, there are many drawbacks and limitations, and you also need to know how to cook it, but in certain cases there are more advantages (for us). Therefore, hereinafter we will talk exclusively about Cordova.
So, for Cordova, there was and is a ready - made plug - in for working with ibeacon. It was easily installed and quickly managed to build the first test application. The phone quite steadily caught the approach to the beacon and exit from the "visibility" zone. I do not remember the exact characteristics of the “iBecom” lighthouse, but they usually state that the lighthouse is caught at 10 meters (and some at 50 or more). My phone "lost" a beacon in one room when removed from it by about 4 meters.
Another interesting feature was that for catching a beacon, you must specify its UUID (you can find out the UUID using any application for working with BLE and beacons, you can also change the UUID, but you need software from the manufacturer)
var beaconRegion = new cordova.plugins.locationManager.BeaconRegion('someMyld', '00000000-0000-0000-0000-000000000000'); cordova.plugins.locationManager.startMonitoringForRegion(beaconRegion); beaconRegion = new cordova.plugins.locationManager.BeaconRegion ( 'someMyId2' , '00000000-0000-0000-0000-000000000123'); cordova.plugins.locationManager.startMonitoringForRegion(beaconRegion); And so on in the loop. The lighthouse notice will return to your callback. Thus, you need to know in advance the UUID of all your lighthouses, and it is impossible to do a broadcast search (looking ahead a bit - broadcast is still possible, though through ... one place).
Having played with ibeacon, we realized that in general it can be used as an additional “feature” and to catch the “client” when he comes close to the lighthouse, for example, sits down at the table or approaches the product. It seemed technically possible to use beacons for positioning in rooms, but it was too troublesome. Well, of course, the “client” should install your application.
As a result, we implemented this plug-in in test mode into a real application and everything went smoothly, nothing broke and did not conflict (if you are not familiar with Cordova, then problems with curves and conflicting plug-ins are something that you constantly have to spend time on in development, we call this problem “Cordova Plugin Hell”). After making sure that everything works, I ticked off the ibecon and with a clear conscience laid the beacon for the future.
Eddystone
Quite recently, I learned that besides ibeacon there are other protocols for the operation of lighthouses. This of course is about Eddystone, who invented Google, as well as Altbeacon, who invented the community. This brought me back to the thoughts about the lighthouses and their capabilities, and when I saw a post on Habré about the possibility to test Eddystone lighthouses, I could not pass by and applied for participation. And after a few weeks on my desk lay an eddystone beacon from the manufacturer Accent System.
If you are not up to date, the Eddystone format includes more data than iBeacon, which essentially transmits only a 16-byte UUID, as well as two numbers (major and minor values), and you can only catch this data in your application. . Eddystone allows the beacon to work in different modes: just like iBeacon, to transfer the UUID (in eddystone it is called the UID), transfer the URL (which is sewn directly into the beacon, and you can configure it), telemetry (beacon meta-data, heat), and also EUID transmission mode and its cyclic change.
The main chic is that Android phones that support BLE are able to catch Eddystone from a URL automatically - you do not need to install additional applications. Just turn on Bluetooth, go to the beacon and catch the notice that the phone has found the link.
Other technologies do not want to understand iPhone without crutches, but they can catch the URL if Google Chrome is installed.
Of course, I immediately wanted to check out this feature. On the manufacturer's website, I found a link to the application in the Play Market, which can be used to configure the beacon. The beacon was found, without any problems, I transferred it to the configuration mode (you need to pull out and insert the battery back, and within 30 seconds the beacon goes into Dev mode). I registered the URL, saved everything and waited for what would happen next. And nothing happened.
Of course, great Google will come to the rescue. I used to read about the Google Beacon Dashboard (this is the cloud control panel of beacons), about the Google Proximity API and NearBy API. It turned out that using a special mobile application (Google Beacon Tool) you need to catch the bacon and register it in the cloud, after which you can configure the URL and many other parameters via the web interface (attachments, map binding, etc.). ). All this blew up the brain quite well and thoroughly confused, but after about half a day of studying manuals I began to understand what was happening.
So:
- The Google Proximity API is an API (Java) with which you can connect to eddystone bacon and configure it (roughly a certain backend);
- The NearBy API is an API (Java) with which the client’s phone can receive data from the Google cloud about lighthouses;
- Google Beacon Dashboard - actually the cloud itself, through the web, you can configure the beacons;
- Google Beacon Tool - Google's mobile application for catching beacons and registering in the cloud;
- As well as at the Eddystone lighthouse itself, you can configure the URL;
- It is the URL embedded in the beacon that will be caught by the phone, even without installing applications;
The main goal of Google Beacon Dashboard and NearBy API is to implement beacons and manage their parameters through the web without developing your back-end for this. And the Google Proximity API is used if you need to embed beacon management into your project.
The problem was that my phone stubbornly did not want to catch the beacon with the URL. It turned out that I had a ban on the search for public links that can be removed in the Google settings in your Android device (it’s Google settings, not the system, and if you haven’t crawled there, you will find a lot of interesting things).
Deal with this problem. For the sake of interest, I checked the phones of all my closest colleagues and acquaintances: no one had such a garbage and after turning on Bluetooth, all the devices immediately caught the link. They wrote off everything on the weirdness of the settings of my device.
Then I tried to register the Eddystone beacon in the Google cloud, but the Google Beacon Tool stubbornly did not find Eddystone, although iBeacon (from iBecom) was found right away, and there were no problems with it. After an abundance of vain attempts, I wrote to the support of the manufacturer Accent Systems (by the way, if you are going to extensively introduce these beacons, please note that no one speaks Russian there by itself). I received a response from Accent Systems in 3-4 business days, which in my humble opinion is not at all fast.
In response, they sent me a link to Dropbox, where I could download a new version of the application for configuring the beacon and new documentation. A new application reflash the beacon, the Beacon Tool has finally found it. It is worth noting that the whole story with downloading the application from unclear links looks at least doubtful for a serious device manufacturer (and, by the way, Google partner).
According to Accent Systems, their eddystone beacons can simultaneously broadcast as 4 regular eddystone and 2 ibeacon.
In practice, I never managed to get slots to work, except for the first one. By the way, the realization of this fact took a lot of time, because at first I set up the 3rd slot and for a long time could not understand why nothing was working.
Thus, my Eddystone lighthouse could broadcast simultaneously as ibeacon and as eddystone (in any mode), i.e. 1 + 1 instead of the stated 4 + 2 simultaneous slots.
We program the test application
After the beacon with Eddystone was able to establish stable operation, it is time to develop a test application. As I wrote earlier - we will do everything on Cordova.
We are looking for plugins to work with eddystone for Cordova and immediately find this one . This is a plugin from Evothings , which develops and supplies various solutions for BLE devices.
I uploaded the final version of my test application to the githab .
Without going into the details of our internal kitchen, the example is based on our internal application framework, which runs on the F7 Framework and RequireJS. All main code is here .
I added a plugin (cordova-plugin-eddystone), copied their example, crashed the application and launched it on the phone.
A small digression for those who want to use Cordova. We do not build applications locally; instead, we deploy a build server to Digital Ocean. All of this can be integrated with your CI solution or handicraft scripts. As a result, when pushing, the build server is notified, pull-it changes and starts the build. The whole process is thoroughly commented on by our bot in Slack (with the text from commits), so everyone is always aware of what is being built, and when everything is ready for installation. In general, it is easy to set up feedback and, through ADB, automatically install applications on the phone.
You can test the core logic of Cordova applications in the browser, because in essence the application is a regular web site. We found this approach extremely convenient, because you don’t have to worry about environments, Java versions, Cordova, which Android Targets are installed, and the build server comes up from the snapshot in 1 minute. Of course, this is a story about Android, adaptation, build and production for ios are different.
If you decide to go this way, I recommend adding to the build the removal and addition of the platform, it will save you from many problems with plug-ins.
So, after the example build, I immediately plugged in the debugger (via chrome: // inspect) and saw that even though the example works without errors, it does not find any bacons. And this is absolutely normal for Cordova - plugins very often do not work as they should. I started learning the cordova-plugin-eddystone plugin and found the code that triggers the BLE scan .
// The device object given in this callback is reused by easyble. // Therefore we can store data in it and expect to have the data still be there // on the next callback with the same device. evothings.easyble.startScan( // Scan for Eddystone Service UUID. // This enables background scanning on iOS (and Android). ['0000FEAA-0000-1000-8000-00805F9B34FB'], function(device) { // A device might be an Eddystone if it has advertisementData... var ad = device.advertisementData; if(lad) return; // With serviceData... var sd = ad.kCBAdvDataServiceData; if(lsd) return; // And the 0xFEAA service. The magic number 0000FEAA-0000-1000-8000-00805F9B34FB is the identifier of the Eddystone beacons. It is passed to other plug-in methods and eventually goes to the Java plug-in. We study the source code of the evothings.easyble.startScan method and understand that it is not necessary to transmit an identifier. Remove it and see what happens - the plugin catches the beacons, what you need!
Moreover, now the plugin catches all BLE devices, including non-beacons. And this is great, let it catch, and somehow we will decide what to do with this data.
A small digression for those who want to use Cordova. Connect your phone via USB, enable debugging, open in Google Chrome: // inspect and select your application. You can debug it as a normal site, as well as directly on the fly to change the JS-code.
Ok, I fork the plugin and start making changes.
First of all, we remove the line
['0000FEAA-0000-1000-8000-00805F9B34FB'] .I see that now the plugin catches ibeacon, but brushes it aside for further validation. I read the documentation on the format ibeacon and eddystone. All beacons send Scan Record, which contains all the data. In base64, it looks something like this:
AgEGGv9MAAIVoHxcqFnrTqiZVjC3duD+3AAEAAS7DBbw/1/r3V649LuVAQAAAAAAAAAAAAAAAAAAAAAAAAA= We convert to hexadecimal system:
And we read the description of Scan record for ibeacon format:
We see that 6-8 bytes (x4c000215) are constants, followed by the UUID ibeacon. Parse scan record, find these 4 bytes and count the next 16 bytes. Then we convert everything into a string of a type format:
a07c5ca8-59eb-4ea8-9956-30b776e0fedc
( https://github.com/garakh/cordova-eddystone/blob/master/js/eddystone-plugin.js#L534 and further along the code).
I finish other trifles and validations, I launch, check - everything works as it should, now, apart from eddystone, the plugin also catches ibeacon. You do not need to specify in advance the UUID ibeacon, because the plugin catches everything.
I push the plugin and proceed to the implementation of Eddystone in the real application.
Production
It's time to introduce you to one of the startups in which I take an active part.
Loya - loyalty as a service. Loy gives businesses the ability to quickly and easily implement loyalty programs, providing dashboards with analytics, APIs and other tools.
One of the chips is a business can order a mobile application where customers can save points and receive gifts. And if a business wants to make a quick start, it can offer its customers a common solution: Loy's client application, in which all other companies are present.
This is where we’ll add support for Eddystone. In order not to complicate the design of a simple algorithm for working with beacons:
- The application catches the beacon and collects its data: MAC address, URL, UUID, NID + BID (this is the EUID of eddystone);
- Sends data to the server;
- The server checks to see if any company has such bacon;
- If there is bacon, then it returns the text of the message that we will display on the screen, as well as a PUSH helmet, is the phone in your pocket a little;
- If the application catches the Eddstone URL, then the MAC address of the beacon is validated on the server, and if everything is ok, then open the page with this URL.
By the way, if the client does not have our application installed, he will still see the URL, because Eddstone taxis.
Algorithm for the company:
- Buy a lighthouse;
- With the help of any utility find out his data (UUID, MAC, etc.);
- Specify an advertising message (in our web dashboard) or configure a beacon in the Eddystone URL mode;
- Place the lighthouse in the store;
- Passing by customers see the URL or push notification if our application is installed;
Ok, so add to the dashboard control beacons:
By the way, the frontend is working on Angular 1.x, RequierJS, Bower, Gulp. Backend: PHP Phalcon, MongoDB. Excellent bundle tested on many projects. We add server API and we pass to programming of the mobile application. Since everything has already been tested, then we add our forc plug-in and enjoy bacon fishing.
Final video and release
- Test ibeacon ( bring a bacon - apparently the message);
- Test eddystone URL (bring bacon - the page opens);
- Build the release and fill in the Play Market;
Those. Not all devices support BLE. We keep several versions in the market. Version 0.1.0 with bacon support (will work on Android 5+) and 0.0.8 without support (4 versions of Android will work).
Conclusion
About 30 man-hours for studying and testing were spent and 5 hours for integration into the combat application, development of the back-end and release. Work with beacons in the network is still poorly lit and confused. You have to communicate with the support of the beacon manufacturers, and by their answers you understand that the manufacturers themselves do not work much better.
To use the beacons for indoor navigation, in my opinion, it is possible, but so far it is rather doubtful, and it is being implemented with great labor costs. Accent Systems hasn’t earned on all slots.
The battery of the iBecom beacon died about 6 months later (the beacon was just lying on the table), although almost 2-3 years of work were announced.
Eddystone URL - in my opinion a very promising thing, does not require special applications and the only thing that worked out of the box without shamanism.
Eddystone is a clear winner in comparing Eddystone and iBeacon. I see no reason to buy ibeacon beacons, which stand the same way, work just as crookedly, and in terms of functionality, they are several years behind.
Source: https://habr.com/ru/post/310518/
All Articles