-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ble_sensed_mode
in the data model
#1068
Comments
Yes
No. we will create a |
Since last week, we have a basic working demo for bluetooth integration. The native code records BLE scans as
background_bluetooth_ble
entries. The phone reads these entries and matches them to composite trips according to timestamp. Essentially, we treat the ble scans the same as unprocessed user inputs.The matched beacon is the one that had the most RANGE_UPDATE entries during the timestamps of the trip. This works for now, but we will want something more robust moving forward.
I think we want to implement matching on the server with respect to sections rather than entire trips.
The
analysis/*section
objects already have asensed_mode
property. I think they should also haveble_sensed_mode
where the value is the beacon'smajor:minor
in hexadecimal as a string (e.g."dfc0:fff0"
)analysis/confirmed_trip
objects should have new properties forprimary_sensed_mode
andprimary_ble_sensed_mode
. (The primary section is the one with the greatest distance, correct?)In #1062 (comment), we also spoke of having
ble_sensed_section_summary
, similar to the currentinferred_section_summary
andcleaned_section_summary
.I want to make sure I understand what this would look like. The existing summaries have a structure of:
To create the
ble_sensed_section_summary
, we will need to look up thebaseMode
in the dynamic config using theprimary_ble_sensed_mode
. Is that right?The text was updated successfully, but these errors were encountered: