π α Adding BLE Beacon Scanner #1135
Conversation
- Setup for adding BLE Scanning - TODO: Change permissions for iOS dev menu selection
BLE Plugin NotesLouis and I have done some reading into the BLE plugins available for Cordova, and have found that the cordova-plugin-ibeacon plugin seems to be the best fit. While we're looking at incorperating this into our preexisting scanner code, it seems to me that there are some subtle differences in how BLE is handled. Below are some of my stream-of-thought notes on the plugin and this project!
Going ForwardWith all of this in mind, Louis and I have come up with a rough game-plan for this project!
As we go forward with this plan, I'll keep this thread updates with our challenges / notes on the experience! |
- Built successfully on iOS
|
It seems that only iOS builds after adding the plugin... For legibility / book keeping, these are the build errors that occurred: |
|
Touching on the Android build errors that Katie mentioned above, we managed to get those resolved. To fix it we had to fork our own version of this plugin and make some changes, which are shown in this commit. The two problems in particular were... It seems like this plugin is a bit older, so it used a deprecated gradle method. To fix this we changed This plugin defines a dependency in its gradle build file called Android now builds, but we have yet to test the beacon at all so we will see if it holds up! |
- Added template for BLE Scanning function - Changed iOS compatibility check to only run for bluetooth classic scanner
|
I was able to build for Android successfully with the plugin installed. I am now running into an issue, however, when trying to test the plugin. I am following this part of the demo code the plugin provides, but whenever I try to invoke this code, I get this error in logcat. The main thing to consider here is this line, which is...
This is caused by a To fix this, I am not quite sure how we do it. I am assuming to fix this, we will need to do these following things.
This seems straight forward, but I am a bit hazy on how to do step 3. In the next few days, hopefully we'll have that figured out and sorted so we can test the plugin and get it to work on Android! EDIT: |
β¦t work yet, but it is a starting point.
|
Quick observation: Looking at the config data for Louis and I's test beacons, it appears that the UUIDs* of the beacons are identical right out of the box. For this specific brand, we do have the capability to change these UUID's. Whether or not we will need to change the UUIDs will depend on whether or not we can also access the systems-level beacon data: i.e., the System ID that appears on all Bluetooth devices (these are seen in the Classic Scanner, as a string of 8 hexidecimal(?) numbers in the format XX:XX:XX:XX:XX:XX). We can gather this data when working with Bluetooth Classic; I have to imagine we will also be able to do so with BLE. If we are able to have both the Sys_ID and UUID, we may be able to perform verification by checking both of these values. Will update once I have more data!
|
iOS Build IssuesI'm noticing an discrepancy between the iOS DevApp build of this branch, and the iOS Hardware build. Below are two videos: on the latter, I receive an error when attempting to run the test code: Serve Build
Native / Full Build
Error Code:NotesFrom my initial reading and assumptions, this issue has to do with the way React renders components; specifically, there's an issue with our set up methods. Our code closely follows the example code from the plugin repo, but the React interface is a notable difference. Interestingly, we haven't had this issue on the Android Build; the components from the plugin render without error. My assumption is, this has to do with how we're using the |
BLE Scanner IssueKatie and I have gotten the scanner set up and giving us some type of callback, but yet it doesn't pick up either of our beacons when we attempt to scan. We have been a bit stuck on this the past few days, but have made a little breakthrough as to what could be going wrong. First and foremost, I never knew this but you can view the logcat of a physical Android device connected to your computer by following this StackOverflow post. I thought this was only a feature if you used Android Studio, so this is super nice to have. It also helped us find the error that we think is causing the scanning to not work. Error When following the sample code for monitoring a single beacon, this error pops up whenever Thoughts As we are using an iBeacon plugin, distancing ranging is something that this plugin supports. I guess on the Android side of things, they have some type of distance json file that they use to compute the distances. If you try to go to https://s3.amazonaws.com/android-beacon-library/android-distance.json the file doesn't exist, which is where our problem lies. The code where this file gets called/used can be found here. The code where the error occurred can be found here in the This issue gets discussed here in this Github issue, but the very next comment says it was a "permissions issue" that has been resolved already. Its been 4 years since he said that, so maybe the file either got taken down or the permissions issue came back. I'm going to dig a bit deeper to see if I can find anything else about this issue along with potential solutions. If not that, maybe I can find that android distance file somewhere so we could upload it as a static JSON file in our project. Potential Solution I noticed that if you go to https://s3.amazonaws.com/android-beacon-library/, it shows all the JSON files available under the android-beacon-library. Our |
- Merge to keep up with changes in bluetooth_scanner branch this PR is based off of
Android Distance Missing File UpdateLooks like someone beat us to it and filed an issue about the missing file error we saw above. Here is the issue that was just created. It appears that this is unfortunately not the reason our beacons aren't scanning, as the main dev says you can ignore this error. We'll have to dig a bit deeper to figure out why our beacons aren't picking up! |
- Successfully detected beacon on iOS - Minor changes to JSX to properly render `logToDom()` - Renamed Bluetooth Classic Scan to reflect purpose
iOS UpdatesSuccess! It took some wrestling with XCode, but we are successfully detecting the BLE beacons on iOS. Below is a screenshot of the scanner, as of the latest commit: as can be seen in the Now that we know that this is working on iOS, I think we can formulate a plan for how we want to proceed:
Ideally, I would also like to add the following functions to this scanner:
I'll make some of the cosmetic changes, since we should be able to knock those out pretty quickly. In general, however, I believe getting the Android side of things up-and-running is priority #1. I'll update this thread's checklist as I make changes!
|
Android UpdatesI just had a chance to test the Android changes between meetings: on both my LGv30 and Nexus 6, it appears that both are scanning properly!! Please see the screenshots attached. While exciting, raises some questions: chief among them, why is the scanner not working on Louis' device? At first, we thought it was an issue with the Android Version, as described in this thread. Considering my LGv30 is running Android 9, I believe we can rule this out as the issue. We're going to do some more testing, and report back! LGv30
Nexus V6
|
BLE Scan UpdateSeeing that Katie was able to scan, as shown above, I tried my personal iPhone and another Android test phone that I haven't used yet. I'm happy to report that they both work like shown above! Piggybacking off of what Katie said above, it is bizarre that my Motorolla G6 test phone could not scan for the beacons. I was fiddling with it last night and decided to restart the phone to see if that would do anything, and of course it now works. Out of all the debugging I did, I never thought to try the old tried and true method of turning it on and off again. With these issues now behind us, we can move forward and tidy this up! |
- Scanner now displays all potential beacons - When scanning, beacon icons will change to show when they are in / out of range - Expanded typing for BLE Devices
- The color of beacon cards will now change depending on whether or not they are within range - Refactored scan button - Added ability to stop scanning for BLE Beacons
BLE Scanner Update!Success!! Both Android and IOS are detecting the BLE Beacons! Below is a (somewhat compressed) video of me testing on both Android (LGv30) and iOS (iPhone 8) simultaneously. Some notes on the tests:
BLE_TEST_Compressed.mp4Future WorkCurrently, the scanner is searching for multiple beacons at once. Unfortunately, I have not been able to test what happens when there are two beacons available; exiting one zone to another being in two zones at once, etc. Once the other test beacons arrive, I'll update this thread accordingly! |
Codecov ReportAll modified and coverable lines are covered by tests β
Additional details and impacted files@@ Coverage Diff @@
## master #1135 +/- ##
=======================================
Coverage 77.49% 77.49%
=======================================
Files 29 29
Lines 1693 1693
Branches 370 370
=======================================
Hits 1312 1312
Misses 381 381
Flags with carried forward coverage won't be shown. Click here to find out more. |
There was a problem hiding this comment.
I think we should add the ability to add new BLE entries, since iOS can only scan for known beacon UUIDs (@the-bay-kay @louisg1337 please confirm)
But I will probably want to add buttons to simulate enter and exit anyway, so will see if I can add it at the same time. This will be my first time writing react native UI code.
Whooo!!!
Great news! This will allow us to make the FSM more robust. @louisg1337 If we detect that we have entered the zone, we can start the trip, but if there is some noise/glitches in there, we can also use our regular geofence and start scanning |
|
Tried to remove all references to COARSE location from the beacon plugin |
|
However, I am not sure that this is the problem. That is a dynamic permission and should not affect the static checks. And it is not in the plugin.xml for the plugin Ah! I do see it in why have we not encountered this before? |
|
The clue is in Anddddd here it is altbeacon is the library that we want to use, so maybe the COARSE location permission is long-term after all. |
|
That (at least with the we should consider adding that line to the data collection |
The intent of this PR is to add a BLE Beacon Scanner to the developer settings, building off of the work done in the previous dev-scanner PRs.
For further context, please see: