Open rkdarst opened 8 years ago
Another question is: what data are you logging regarding beacons?
Currently we would only log the unique ID (UUID, mac, whatever). Our current case is this:
We want to monitor where people go, but only in a small set of locations. Instead of using GPS, we tag these locations with bluetooth beacons. We have a master list of what beacon is where. The app just logs the beacons it sees (either all, or those on a certain list), records the UIDs, and sends them with timestamps.
For iOS, we would need to give a certain list of beacons UIDs to be notified of. For Android, I think we could watch for all beacons. The extra data the beacon may send is not important to us, but may as well be logged.
The above is crafted with help of the Secure Systems Group at Aalto. According to them, the different beacon protocols shouldn't matter in this use case. I also think this means that we wouldn't need an explicit background service, just an intent service (receiving pushes only, both Android and iOS). And the we wouldn't need to depend on any particular beacon library. These beacons are limited to Bluetooth low energy devices (4.0+).
So for Android, I think the procedure is this (daniel? denzil?)
So the table would contain: timestamp, device_id, beacon_id, beacon_label, beacon_rssi
It would be great to also get the RSSI value to the beacon. This can be used to measure the proximity of the user to the beacon itself. The label could work to create scan results groups. E.g., where I am positioned (office), the scan have all the same label. This would allow us to identify indoor places :-)
Denzil;
On 01 Aug 2016, at 12:36, Richard Darst notifications@github.com wrote:
Currently we would only log the unique ID (UUID, mac, whatever). Our current case is this:
We want to monitor where people go, but only in a small set of locations. Instead of using GPS, we tag these locations with bluetooth beacons. We have a master list of what beacon is where. The app just logs the beacons it sees (either all, or those on a certain list), records the UIDs, and sends them with timestamps.
For iOS, we would need to give a certain list of beacons UIDs to be notified of. For Android, I think we could watch for all beacons. The extra data the beacon may send is not important to us, but may as well be logged.
The above is crafted with help of the Secure Systems Group at Aalto. According to them, the different beacon protocols shouldn't matter in this use case. I also think this means that we wouldn't need an explicit background service, just an intent service (receiving pushes only, both Android and iOS). And the we wouldn't need to depend on any particular beacon library. These beacons are limited to Bluetooth low energy devices (4.0+).
So for Android, I think the procedure is this (daniel? denzil?)
Study how the API works Create a new sensor that is an intent service, receiving any beacon-related intents Create a new variable btbeacon_list which is a space-separated string containing UIDs. If this is non-null, the intent service only monitors for these UIDs (however that is done. Tell what the format is). — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CxAalto/aware-client/issues/3#issuecomment-236534423, or mute the thread https://github.com/notifications/unsubscribe-auth/AH9NLaotrpYYmf1_dfzdK838mZWqtkmpks5qbb4XgaJpZM4JWrkP.
Yes, that sounds good. RSSI should definitely be included!
Would beacon_label be basically whatever data the beacon transmitted? I'm not sure what the granularity of the generic beacon APIs are, but should this be interpreted as basically "whatever data the beacon API sends"? (and then it's up to the user to figure out how to use it).
Thanks,
No, the label would be used for human-based / machine learning strings of a place. For example, using ESM and detecting a beacon being close, I could ask: where are you? And save that answer. Then I could broadcast that answer and apps/plugins can react to designed labels :)
https://developers.google.com/awareness/overview
Take a look at the Fence API. Could make this sensor easier to develop.
Add support for bluetooth beacons.
My initial thoughts
Thoughts?