I have a BLE Beacon and instead of broadcasting constantly it just broadcasts a message when you push a button. It's a commissioning message. I'm looking all over the place but can't find a library that listens to Beacon messages.
I've taken a look and tried these solutions:
https://altbeacon.github.io/android-beacon-library/index.html
https://developers.google.com/nearby/messages/android/get-started
Is there a library that allows this?
In order to detect a beacon message sent at the push of a button, you need the mobile app to be listening constantly ("scanning" is the BLE term) because it doesn't know when you are going to press the button.
You can use the open source Android Beacon Library mentioned in your question to do this. You would want to use its "beacon ranging" API which scans for beacons and tells your app what beacons it sees (if any) with a callback every second. If somebody hits the button the beacon, your app will get a callback to didRangeBeaconsInRegion with a single beacon in the list. (If nobody hits the button, the app would get a callback with zero beacons in the list.)
A couple of important points:
You need to know the format of the beacon your hardware is transmitting (iBeacon, AltBeacon, Eddystone-UID, Eddystone-URL, etc.) so you can set up the scanning library to look for that kind of beacon.
You need to know what kind of identifier the hardware beacon sends out. Formats like iBeacon and Altbeacon transmit long hexadecimal UUID identifiers like "2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6". You will need to know what it sends so you can tell if the beacon is yours. Otherwise your program will react even if somebody else's beacon is transmitting.
Full disclosure: I am the lead developer on the Android Beacon Library Open Source Project
Related
I'm trying to see if I can use the Android beacon library to set Data Fields on a physical beacon. The function setExtraDataFields exists, and if i call that on a Beacon object and immediately call getExtraDataFields, the object itself has changed but on the next ranging when I pickup the beacon signal, getExtraDataFields remains unchanged. Is there some "force" or "update" function I need to call to enact/save the changes? I feel like something like this is possible because the Location app attempts to change the RSSI of a device I believe, but all the code examples I have found thus far are for using the Android device as a simulated beacon.
Unfortunately, it is not possible to use the Android Beacon Library to modify the values of a hardware beacon. The values returned by getExtraDataFields are effectively read-only.
Two reasons why:
Bluetooth beacons are one-way transmitters that send a unique identifier and associated data. They do not receive data, and cannot be remotely updated over the same channel.
Some beacon hardware manufacturers do have proprietary extensions allowing an external app to use a Bluetooth service to configure the beacon's identifiers and data fields. But the mechanism to do so is different for every manufacturer. It is not possible for the Android Beacon Library to even figure out which manufacturer made each beacon it sees, let alone use their proprietary SDK or service to update the fields.
Bottom line: If you want to update the fields from your app, you need to ask your hardware manufacturer to give you instructions on how to do it.
I am trying to create an Android app thats detect a rasperry pi by using the AltBeacon library by davidgyoung. So far I am able to get most data including distance, although the only things that I really need are dBms and the UUID of the device. Inside the rangeNotifier() function I pretty much print every piece of data to see if the UUID might come out somewhere that matches the one of the device but the only thing that resembles a UUID is given to me as "00000000-0000-0000-0000-000000000000" and is found by using the getIdentifier method. Any ideas why I can't see the actual UUID of the device? Thanks!!
If multiple Android apps say the ProximityUUID is 00000000-0000-0000-0000-000000000000, then they are probably right.
The reason iOS apps probably won't detect 00000000-0000-0000-0000-000000000000 is because unlike Android, iOS can only detect a beacon's UUID if it is pre-configured into the app (yeah, that's a chicken and egg problem I know!) and your UUID is probably not configured into those iOS apps. So it may be showing the ProximityUUID of a different beacon in the vicinity.
Also, don't confuse the Bluetooth GATT Service UUID with the iBeacon Proximity UUID. Even though these look superficially similar -- they are completely different identifiers If you are using a more general Bluetooth scanning app on iOS (and not a beacon scanning app) this may be what iOS is seeing.
I was earlier using the AltBeacon Library for detecting beacons and it works perfectly without any problems.
Then i came across
https://developers.google.com/beacons/overview?hl=en
Which suggest
The Google Proximity Beacon API can be used to register any beacon that supports one of the following specifications: (They mentioned register may be i was mistaken to assume it may detect as well)
Eddystone
iBeacon
AltBeacon
So i was interested and started using the subscribe API after creating the Project in Google Console and using the googleApiClient along with Nearby.MESSAGES_API and strategy BLE_ONLY for detecting beacons. And was unsuccessful.
After that reading the API docs completely (should have done before investing time) it mentions
In order to work with Google APIs, beacons must first be provisioned with some initial settings (namespace ID, instance ID, frame format, and so on), and then registered using the Google Proximity Beacon API.
So does this mean i have to compulsorily configure the beacons individually before using just any random beacon with my app to detect and get message? It might seem obvious i just don't want to go with a custom 3rd party implementation like AltBeacon if GooglePlayService.Nearby_Message_API supports listening to any beacon.
In case its possible and if someone has already tried just listening to beacons enter and exit events without the need to configure do let me know i can share the code and take it forward. Or i should leave the Nearby API and go back to good old AltBeacon.
BR,
Jayshil
As far as I can tell, there is nothing to restrict any developer from programming their beacon to use a particular UUID, major, minor or identifier.
In the event I create an iBeacon with a UUID of "foo", what is to prevent another developer of creating a beacon with the same ID and (either accidentally or maliciously) causing my app to display incorrect data ?
Have I misunderstood how iBeacons work ? Please correct me if I'm wrong.
This is absolutely true. I have both spoofed the Apple Store's iBeacons (to prove this point) and had my beacons spoofed by Make magazine for the Consumer Electronics Show Scavenger Hunt.
This is not a flaw at all. You just need to design an app that uses iBeacons so spoofing is relatively inconsequential. If you design your app so it doesn't much matter, who cares?
The specific security mechanisms appropriate to counter this depend on the app in question, but there are countless possibilities.
For the CES Scavenger hunt, for example, we simply kept an audit log with timestamps so we'd know if somebody found all the targets impossibly quickly. In the end nobody did this -- our participants were all good sports!
You can't prevent spoofing of the advertisement packet because there is no central authority that issues universal unique identifiers (UUID's). UUIDs are arbitrarily assigned to a beacon and are not actually guaranteed to be unique.
However, once you have paired your handheld with the beacon, the picture is different. You can program a beacon (or, more specifically, a beacon-like device) to generate absolutely unique information when paired, such as a one-time password or some private-key encrypted handshaking between your app and the paired beacon.
The typical process flow would be:
handset detects ibeacon broadcast, reads UUID + Major/Minor.
handset launches your app (using the didEnterRegion event).
your app requests to pair with the beacon, sends it a command to generate an encrypted response.
your app decrypts the response. If successful, display a happy face! If failure, display a sad face.
Moving forward, I suspect that most beacon systems will be implemented this way. Unless and until the iBeacon standard is updated to accommodate encryption, it will have to be a hybrid approach of ping + pair.
I'm just reading up on iBeacon, and I might want to use it for a project I'm currently involved in. What I currently understand from it is this:
Simply put, an iBeacon device broadcasts a message to whomever is
within range. This message includes the sender its mac-address, and
from the intensity of its signal, the receiver can calculate the
distance. iBeacon devices can either be senders, receivers, or both.
1) First of all; is this correct?
Secondly, on the wikipedia page I read that it could enable payments at the point of sale (POS). Because I understand that it is basically a very local broadcast service I'm just trying to understand how something like that would work.
2) So would in case of a payment, the store or the customer initiate the payment?
3) And how would you prevent that other nearby devices pick up the payment messages?
4) Lastly; is it possible to send an iBeacon message to only one iBeacon device identified by its mac address?
Any tips and insights are very welcome!
Enabling mobile payments is an example of something you could build on top of iBeacon technology. But iBeacons themselves are very simple building blocks that would only be a small piece of a solution. It is a common misconception to confuse what iBeacons do themselves with what can be done with iBeacons.
In the payment use case, the only function the iBeacon would perform would be to wake up the payment app and tell it the phone is near the point of sale. (With a specific numeric identifier for the point of sale.) That's it! That is all the iBeacon does. Everything else necessary would be built with other software.
There are lots of possible answers to your other questions about payment processing, but they are not specifically related to iBeacons. Typically, a mobile payment system will require entry of a PIN to confirm payment. So an app using iBeacons could simply display an option to pay to any device with the payment app that is a few feet of the point of sale.
In the simplest implementation, the phone would query the payment server with a message like "I am near POS terminal with iBeacon identifier #12345. How much is the payment?" And the server might respond with a message like "$23.95", which would be displayed on the screen of the phone. In this implementation, the user would verify the amount on the screen and enter a PIN to confirm. This confirmation would be the security mechanism ensuring that the wrong device does not pay for the wrong order. Other more sophisticated implementations are possible, but again they are not strictly related to iBeacons.
Two other clarifications:
While an iBeacon does transmit its Bluetooth Mac address, this is typically ignored. In fact, iOS blocks reading this Mac address, so it is useless on that platform. Instead, applications rely on a three part identifier specific to iBeacons: ProximityUUID, Major, Minor.
There is no way to make only a single device see an iBeacon. It is an open radio transmission visible by everything in its approx. 150 ft. range.