The detections routes are the primary ingestion surface for BLE scan data produced by Raspberry Pi sensor nodes. Each detection record captures a hashed device address, the received signal strength (RSSI in dBm), a proximity zone (Documentation Index
Fetch the complete documentation index at: https://mintlify.com/AngelAmoSanchez/TFG-RaspberryPi-BLE/llms.txt
Use this file to discover all available pages before exploring further.
near, medium, or far), a timestamp, and the ID of the IoT node that performed the scan. All endpoints are mounted under /api/v1/detections.
POST /api/v1/detections/
Create a single detection record. The IoT device ID is passed as a query parameter rather than in the request body so that the same body schema can be reused without coupling it to the sender’s identity. Query parametersUnique identifier of the Raspberry Pi that recorded the detection. The device’s
last_seen timestamp is updated automatically on every successful call.SHA-based hash of the detected BLE MAC address. Raw MAC addresses are never stored.
Received signal strength in dBm. Negative integer, e.g.
-65.Proximity zone assigned by the Pi:
near, medium, or far.ISO 8601 timestamp of when the BLE advertisement was observed. If omitted, the server sets the current time in the Europe/Madrid timezone.
Auto-incremented primary key of the detection record.
Hashed BLE MAC address.
Signal strength in dBm.
Proximity zone:
near, medium, or far.ISO 8601 timestamp of the detection.
ID of the IoT node that submitted the detection.
POST /api/v1/detections/bulk
Create multiple detection records in a single request. This is the preferred endpoint for Raspberry Pi nodes that batch their scan results before sending. The device is automatically registered or updated with the suppliedname and location fields.
Request body
Unique identifier of the Raspberry Pi submitting the batch.
Array of detection objects. Each element should contain at minimum
device_hash, rssi, and zone. The timestamp field is optional in each element; if absent, the server uses the current time.Human-readable label for the device, e.g.
"Entrance sensor". Updates the stored device name if the device already exists.Physical location description, e.g.
"Floor 1 - Main entrance". Updates the stored device location if the device already exists.Confirmation string including the count of saved records.
ID of the submitting device, echoed back.
Number of detection records that were saved.
GET /api/v1/detections/recent
Return the most recent detection records, optionally filtered by proximity zone. Results are ordered by descending timestamp. Query parametersMaximum number of records to return. Must not exceed
1000.Filter to a single proximity zone. Accepted values:
near, medium, far. Omit to return records from all zones.GET /api/v1/detections/count
Count the number of unique BLE devices detected within the last N hours, optionally constrained to a single zone. The response also includes a people estimate derived by dividing unique device count by theDEVICES_PER_PERSON ratio (default 1.5).
Query parameters
How far back in time to look, measured in hours from the current moment.
Filter to a single proximity zone:
near, medium, or far. Omit to count across all zones.ISO 8601 timestamp of the start of the counting window.
ISO 8601 timestamp of the end of the counting window (current server time).
The zone filter that was applied, or
null if none was requested.Count of distinct
device_hash values observed within the window.People estimate:
round(unique_devices / devices_per_person), minimum 1 when at least one device is present.