---
title: "Reading Bluetooth sensors from a field app: pairing, permissions and readings you can trust | R&D COPILOT"
lang: en
canonical: https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/
content_version: 1b0810e5cc0897a316b34db4479902c3dc122ab44f304033c4200329c1b19c1b
contact: https://rdcopilot.com/contact/
---

[RDC](https://rdcopilot.com/) [Insights](https://rdcopilot.com/insights/)Mobile apps

Mobile appsHow-to guide

# Reading Bluetooth sensors from a field app: pairing, permissions and readings you can trust

When a technician types a meter value by hand, the number is only as good as their eyesight and patience. Reading the sensor over Bluetooth Low Energy removes the typing, but it adds new questions: which device did the phone actually talk to, what happens when the connection drops, and how does the office know the value came from the sensor and not from a guess? We build field apps that answer those questions in the design, so readings arrive in the business system with their evidence attached.

By R&D COPILOT7 October 20265 min read

In this guide

1.  [Start from the reading, not the radio](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-1)
2.  [Make sure the phone talks to the right device](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-2)
3.  [Ask for permissions that match the task](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-3)
4.  [Keep the evidence with every reading](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-4)
5.  [Design for connections that drop](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-5)
6.  [Test with the real hardware on the real site](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-6)
7.  [How we scope a sensor-connected field app](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-section-7)

[Sources & inspiration](https://rdcopilot.com/insights/mobile-app-bluetooth-sensor-readings/#guide-sources)

## Start from the reading, not the radio

Write down the values the person on site needs, the unit, the acceptable age of a reading and what decision it supports. A temperature checked once per visit has different needs from a vibration trend sampled every second. This list decides whether the app reads a value on demand, subscribes to updates or simply listens to broadcast packets.

Bluetooth Low Energy devices expose data through GATT services and characteristics. Some sensors use standard profiles registered with the Bluetooth SIG; many industrial devices use vendor-specific ones. Ask the hardware supplier for the profile document early: characteristic identifiers, byte layout, scaling, units and firmware differences. Without it, the app team ends up reverse-engineering packets, which is slow and fragile when firmware changes.

Start from the reading, not the radio
| Pattern | Good for | Watch out for |
| --- | --- | --- |
| Read on demand | Spot checks during a visit | Connection setup time on each read |
| Subscribe to notifications | Live values while the screen is open | Battery use and background limits |
| Listen to advertising packets | Many nearby sensors, no connection | Small payload and no delivery confirmation |

## Make sure the phone talks to the right device

On a site with ten identical sensors, “connect to the strongest signal” is a recipe for readings attached to the wrong asset. Signal strength changes with walls, bodies and phone orientation, so it is a hint, not an identity. Filter scans by service identifier to ignore unrelated devices, then confirm the device with something the technician can see: a serial number printed on the label, a QR code or a short code shown on the device.

Once confirmed, bind the device identifier to the asset record. The next visit can then show “Pump 3, sensor ending 4F2A” instead of a list of anonymous addresses. When the same asset lives in ERP, the binding belongs there too, so maintenance history, readings and spare parts point to one record.

## Ask for permissions that match the task

Android 12 and later split Bluetooth access into scan and connect permissions, and an app that never derives location from scans can declare that explicitly. Older Android versions tie scanning to location permission, which users understandably question. On iOS, the app must explain its Bluetooth use in a purpose string that appears in the system prompt.

Show a short screen before the system prompt that explains why the app needs Bluetooth on this job. Then design the refused state: the technician can still enter the value manually, the record is marked as manual entry, and the app offers a path to settings. A field app that stops working because one permission was denied creates a support call instead of a reading.

## Keep the evidence with every reading

Store the raw value alongside the converted one, plus unit, device identifier, firmware version, the device timestamp if it has one, the phone timestamp, the user and the asset. Mark the source clearly as sensor or manual entry. Apply simple range checks on the phone and keep the flag with the record rather than silently discarding suspicious values.

Readings collected without coverage go into the same durable offline queue as forms and photos, each with a stable identity, so a resend after reconnection does not create duplicates. When the office sees an unusual number, it can trace it to the exact device, time and person instead of starting a phone call.

## Design for connections that drop

BLE connections fail more often than teams expect: the sensor sleeps to save battery, another phone holds the connection, or the technician walks away mid-read. Set clear timeouts, retry a limited number of times and show the state in plain words: searching, connected, reading, saved. Disconnect after a spot reading so the sensor is free for the next person and its battery lasts.

Background behaviour differs between platforms. iOS restricts scanning and connections when the app is not in the foreground, and Android adds its own power limits. If the workflow needs continuous collection without the screen open, that is a design decision to make early, and sometimes a sign that a fixed gateway is the better tool.

## Test with the real hardware on the real site

Simulators do not reproduce metal cabinets, crowded radio space or a sensor on low battery. Test on the oldest supported phones, with gloves if the team wears them, and with the firmware versions actually installed.

-   Confirm the device by label or code before the first reading is saved against an asset.
-   Read with two phones near the same sensor and check that each reading lands on the correct record.
-   Deny the Bluetooth permission and check that manual entry still works and is flagged as manual.
-   Interrupt a read halfway, restart the app with queued readings and check for loss or duplicates.
-   Update the sensor firmware on a test unit and confirm the app still decodes values correctly.

## How we scope a sensor-connected field app

Bring the list of readings, the sensor models and their profile documents, the phones your team uses and where the data must end up. We usually start with one asset type and one visit workflow, then add devices once the evidence trail works end to end. The same app can show threshold alerts and trends from our IoT monitoring platform and write readings into ERP asset records, inventory or reports.

The work is priced as a one-off setup and implementation fee, then a monthly subscription that covers EU hosting, updates and support. Additional sensor models or screens are estimated at a fixed hourly rate, so the scope stays clear as the fleet grows.

Inside the product

## Mobile apps

[![OffLingua text translation on iPhone.](https://rdcopilot.com/mobile-apps/offlingua-text.jpg)View full size](https://rdcopilot.com/mobile-apps/offlingua-text.jpg)

OffLingua — translation on the device.

Swipe or use the arrows to explore.

Image 1 of 1

Follow the references

## Sources & inspiration

### [Bluetooth Low Energy Asset Tracking](https://devpost.com/software/bluetooth-low-energy-asset-tracking)

Devpost project by Yi Han, skydiving94, Tingting Gao

An Android app reads temperature and humidity from a SensorTag over Bluetooth Low Energy.

This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.

-   [Android Developers: Bluetooth Low Energy overview](https://developer.android.com/develop/connectivity/bluetooth/ble/ble-overview)
-   [Android Developers: Bluetooth permissions](https://developer.android.com/develop/connectivity/bluetooth/bt-permissions)
-   [Apple Developer: Core Bluetooth](https://developer.apple.com/documentation/corebluetooth)
-   [Bluetooth SIG: Assigned Numbers](https://www.bluetooth.com/specifications/assigned-numbers/)

Put the guide to work

## Start with your workflow.

Tell us what your team needs to do, which systems are involved and where the current process slows down.

[Discuss your project](https://rdcopilot.com/contact/?service=mobile-apps) [Explore Mobile apps](https://apps.rdcopilot.com/)

Mobile apps

## Keep exploring.

[All guides](https://rdcopilot.com/insights/)

Workflow

### [Push alerts in a business app: design notifications people act on](https://rdcopilot.com/insights/mobile-push-alerts-business-app/)

A practical workflow for business push alerts: choose which events deserve a notification, map urgency to iOS and Android levels, show live context on open and plan acknowledgement and escalation.

[Read guide](https://rdcopilot.com/insights/mobile-push-alerts-business-app/)

Decision guide

### [Scope the first release of a business mobile app](https://rdcopilot.com/insights/mobile-app-development-first-release/)

Scope a first mobile release around one complete user task, essential backend dependencies, interrupted journeys and acceptance on the devices you support.

[Read guide](https://rdcopilot.com/insights/mobile-app-development-first-release/)