> ## Documentation Index
> Fetch the complete documentation index at: https://docs.farmtrace.co.za/llms.txt
> Use this file to discover all available pages before exploring further.

# Device profiles

> Use identity, capability, and behavior metadata to describe supported hardware.

A device profile is the contract between supported hardware and Dsync. It gives the app enough information to recognize a device, connect to it, and present meaningful operations instead of raw transport details.

## What a profile describes

| Area                | Purpose                                                                                            |
| ------------------- | -------------------------------------------------------------------------------------------------- |
| Identity            | Match the device during discovery.                                                                 |
| Metadata            | Provide a stable ID, display name, category, manufacturer, models, or tags.                        |
| Transport           | Set BLE or USB connection properties such as MTU, baud, timeout, or retry behavior when supported. |
| Services            | Map BLE services and characteristics or USB channels to the device protocol.                       |
| Components          | Group hardware capabilities and named operations into meaningful units.                            |
| Settings            | Define values, defaults, and constraints that the device session can use.                          |
| Rules and workflows | Describe automation and multi-step behavior for the profile.                                       |

## Identity matching

### USB

USB matching uses the vendor ID and product ID. A profile can also constrain the optional interface class. The identifiers must describe the actual device presented to Android.

### BLE

BLE matching can use a local-name prefix, one or more advertised service UUIDs, and an optional manufacturer ID. UUIDs are normalized before comparison, but the profile still needs to describe an identifier the device actually advertises.

<Warning>
  A broad identity rule can match the wrong hardware. Prefer the narrowest rule that reliably identifies the intended device, then test discovery with more than one physical unit when possible.
</Warning>

## Profile checklist

* The profile ID is stable and unique.
* The human-readable name tells a field user what the device is.
* At least one USB or BLE identity matcher reflects the real hardware.
* The transport and service metadata match the device protocol.
* Every operation used by a form or workflow belongs to the correct component.
* Settings have safe defaults and clear constraints.
* A failed or disconnected device has a user-visible recovery path.

If a profile change affects an active field workflow, test discovery, connection, one read, one write where appropriate, and the complete workflow before releasing it.