Data Path

In a nutshell

The gateway produces two kinds of data.

1) Asset scans: ble-scanner detects nearby Milwaukee tools, snapshots the current location into each scan, and writes session files; asset-publisher turns them into the expected payloads and publishes to AWS IoT Core over cellular.

2) Device state: location-collector and device-reporter write the device's shadows (location, identity, status) over direct MQTT.

Read this if: you're a software engineer who wants to follow the actual messages through the box.

Before this: skim the Overview and, for how the components fit together, the Architecture.

This page traces what actually flows through the reference gateway at runtime. There are two paths: the asset-scan pipeline (BLE detections → cloud) and device-shadow writes (device state → cloud). Provisioning and OTA are separate lifecycle flows covered in Device Provisioning and OTA.

Scan → Cache → Upload

The core detects nearby Milwaukee tools over BLE and publishes each session to AWS IoT Core as an RP2 asset-scan payload.

Key points:

• ble-scanner keeps only Milwaukee advertisements (Bluetooth company id 0x0165), reconstructs the xAd (the raw advertisement in hex), and dedups within a session.
• Each session file carries a snapshot of the latest location/fix from location-collector, so a detection records where it was captured. Handoff is via disk, not IPC: the scanner and publisher are deliberately decoupled because they may run on different cadences.
• asset-publisher reads completed sessions, builds the payload and publishes it over cellular.
• The core publishes directly on the Basic Ingest rule topic $aws/rules/dt_asset_scan_ingest/dt/<thing>/asset_scan, so the message goes straight to the IoT rule with no broker hop. (A plain dt/<thing>/asset_scan topic exists only on the mesh Pis; the core's bridge remaps those publishes onto this same rule topic.)
• Scan settings (enabled, ble_scan.duration_sec, ble_scan.rssi_threshold, ble_scan.service_uuids, ble_scan.schedule) are read by ble-scanner from the per-device config named shadow; asset-publisher separately reads its upload cadence (reporting.asset_scan_upload) from the same shadow. Both reconcile on connect and hot-update via shadow delta, so behavior changes without restarting.

For the payload format itself, see Asset Scans.

Device shadows over direct MQTT

The gateway reports its state through four named shadows, all written over direct MQTT to the AWS reserved shadow topics ($aws/things/<thing>/shadow/name/...) via the edge_shared.shadow / shadow_mqtt modules, not the Greengrass ShadowManager.

Shadow	Written by	When	Direction
identity	device-reporter	Once at boot (after cert/ready)	Device → cloud
status	device-reporter	Once at boot	Device → cloud
location	location-collector	On each GNSS/LTE fix	Device → cloud
config	ble-scanner (scan settings) + asset-publisher (upload cadence)	Reconciled on connect, updated on delta	Cloud → device (each reports its own fields)

identity and status are one-shot reports (device-reporter writes them, then exits). location updates as fixes arrive. config is the one that flows downward: a cloud client changes desired settings, the two consumers receive the delta, reconcile, and report their own fields back. This is the same shadow contract described in Device Shadows; here it is written by real components over direct MQTT.

How the mesh extends this path

The Edge Mesh experiment reuses this exact pipeline to widen coverage: a Raspberry Pi runs its own BLE scanner and publishes RP2 payloads to the core's local broker, which bridges them to the same Basic Ingest topic, so scans reach the cloud whether they originate on the core or on a Pi. The Pi carries its own per-node config shadow, relayed through the core. That extension (and the remote tool-control flow) is documented on the experimental Edge Mesh Data Path.

Where the code lives

• components/ble-scanner/README.md and components/asset-publisher/README.md: the scan-to-cloud pipeline and the config shadow.
• components/location-collector/README.md and components/device-reporter/README.md: the shadow writers.
• shared/README.md: edge_shared.payload (the RP2 transform), shadow / shadow_mqtt (direct-MQTT shadow clients), ble, location, sessions.
• iot-edge repo README: the end-to-end runtime and IPC flow.