`ble_sensed_mode` in the data model

[JGreenlee]

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 a sensed_mode property. I think they should also have ble_sensed_mode where the value is the beacon's major:minor in hexadecimal as a string (e.g. "dfc0:fff0")

analysis/confirmed_trip objects should have new properties for primary_sensed_mode and primary_ble_sensed_mode. (The primary section is the one with the greatest distance, correct?) In https://github.com/e-mission/e-mission-docs/issues/1062#issuecomment-2027849093, we also spoke of having ble_sensed_section_summary, similar to the current inferred_section_summary and cleaned_section_summary.

I think we should also have a summary of the values in the confirmed and composite trips, similar to the current inferred_section_summary and cleaned_section_summary to make it easier to find the primary mode instead of having to iterate over the sections. This could be called ble_sensed_section_summary and the keys would be the baseMode

I want to make sure I understand what this would look like. The existing summaries have a structure of:

{
  count: {
    <baseMode>: number,
  },
  distance: {
    <baseMode>: number,
  },
  duration: {
    <baseMode>: number,
  },
}

To create the ble_sensed_section_summary, we will need to look up the baseMode in the dynamic config using the primary_ble_sensed_mode. Is that right?

[shankari]

analysis/confirmed_trip objects should have new properties for primary_sensed_mode and primary_ble_sensed_mode. (The primary section is the one with the greatest distance, correct?)

Yes

https://github.com/e-mission/em-public-dashboard/blob/134cd25722f1e1ebaa566e8ffb45f3d8d497e1fd/viz_scripts/scaffolding.py#L227

To create the ble_sensed_section_summary, we will need to look up the baseMode in the dynamic config using the primary_ble_sensed_mode. Is that right?

No. we will create a ble_sensed_mode for each section (similar to the current sensed mode). we will then expand get_section_summary to generate ble_sensed_summary similar to the existing cleaned_section_summary finally, we will generate the primary_ble_sensed_mode from the ble_sensed_summary. Note that we will do so on the client instead of adding this new field to the data model.