Services and characteristics in IOT Protocols - Deep Dive

Overview - Services and characteristics

What is it?

Services and characteristics are the building blocks of communication in Bluetooth Low Energy (BLE) devices. A service groups related features or data, while characteristics are individual pieces of data or functions within a service. Together, they allow devices to share and control information in a structured way.

Why it matters

Without services and characteristics, BLE devices would have no organized way to exchange data, making communication chaotic and unreliable. This structure enables smart devices like fitness trackers, smart locks, and sensors to work smoothly and interact with apps or other devices. It solves the problem of how to share specific data points clearly and efficiently.

Where it fits

Learners should first understand basic Bluetooth and BLE concepts, including device roles and connections. After mastering services and characteristics, they can explore advanced topics like BLE security, custom profiles, and data synchronization between devices.

Mental Model

Core Idea

Services organize related data and functions, while characteristics represent the individual data points or controls within those services in BLE communication.

Think of it like...

Think of a service as a folder on your computer that holds related documents, and characteristics as the individual files inside that folder. Just like you open a folder to find specific files, a device accesses a service to find and use its characteristics.

┌───────────────┐
│   BLE Device  │
├───────────────┤
│ Service 1     │
│ ├─ Char A     │
│ ├─ Char B     │
│ └─ Char C     │
│ Service 2     │
│ ├─ Char D     │
│ └─ Char E     │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding BLE Device Roles

Concept: Introduce the basic roles of BLE devices: central and peripheral.

BLE devices communicate by roles. The peripheral advertises data and waits for connections. The central scans and connects to peripherals to read or write data. This role division helps organize communication.

Result

Learners can identify which device initiates communication and which responds.

Knowing device roles is essential because services and characteristics exist within peripherals, and centrals access them.

2

Foundation

What Are Services in BLE?

Concept: Explain that services group related data and functions on a BLE device.

A service is like a container that holds characteristics related to a specific feature. For example, a Heart Rate service groups all data related to heart rate measurement. Services have unique identifiers called UUIDs.

Result

Learners understand that services organize data logically on BLE devices.

Recognizing services as containers helps learners see how BLE devices structure their data for easy access.

3

Intermediate

Characteristics: The Data Points Inside Services

🤔Before reading on: do you think characteristics can only hold data, or can they also trigger actions? Commit to your answer.

Concept: Characteristics represent individual data or controls within a service and can be read, written, or notify changes.

Each characteristic has a UUID and contains a value. It can be readable, writable, or send notifications when data changes. For example, a temperature characteristic holds the current temperature value.

Result

Learners see how specific data or commands are accessed inside services.

Understanding characteristics as both data holders and control points clarifies how devices interact dynamically.

4

Intermediate

Properties and Permissions of Characteristics

🤔Before reading on: do you think all characteristics allow both reading and writing? Commit to your answer.

Concept: Characteristics have properties that define how they can be used and permissions that control access.

Properties include read, write, notify, and indicate. Permissions control who can access the characteristic, such as requiring encryption. For example, a characteristic might be readable but not writable.

Result

Learners understand how characteristics control data flow and security.

Knowing properties and permissions helps prevent misuse and ensures secure, efficient communication.

5

Intermediate

Standard vs Custom Services and Characteristics

Concept: Explain the difference between predefined standard services and custom ones created by developers.

Bluetooth SIG defines standard services like Battery Service or Heart Rate Service with fixed UUIDs. Developers can create custom services and characteristics with unique UUIDs for special device features.

Result

Learners can distinguish when to use standard or custom definitions.

Recognizing this distinction helps in designing interoperable devices and custom solutions.

6

Advanced

How Notifications and Indications Work

🤔Before reading on: do you think notifications require acknowledgment from the receiver? Commit to your answer.

Concept: Notifications and indications let a device send data updates without the central constantly asking for them.

Notifications send data updates without expecting confirmation, making them faster but less reliable. Indications require acknowledgment, ensuring the central received the data. This mechanism optimizes communication efficiency.

Result

Learners understand how devices push data updates effectively.

Knowing the difference prevents communication errors and optimizes battery life in devices.

7

Expert

Handling Complex Data with Characteristic Descriptors

🤔Before reading on: do you think descriptors change the data value itself or provide extra info? Commit to your answer.

Concept: Descriptors add metadata or configuration to characteristics without altering the main data.

Descriptors can describe the format, units, or user descriptions of a characteristic. For example, a descriptor might specify that a temperature value is in Celsius. They help clients interpret data correctly.

Result

Learners see how BLE devices provide rich, understandable data beyond raw values.

Understanding descriptors is key to building user-friendly and interoperable BLE applications.

Under the Hood

BLE devices store services and characteristics in a hierarchical attribute table. Each attribute has a unique handle and UUID. When a central device connects, it discovers services by querying this table, then accesses characteristics by their handles. The BLE stack manages reading, writing, and notifications through this attribute protocol, ensuring efficient and secure data exchange.

Why designed this way?

The attribute-based design allows flexible, extensible communication without fixed data formats. It supports both standard and custom profiles, enabling a wide range of devices to interoperate. This modular approach balances simplicity for basic devices and complexity for advanced features.

┌─────────────────────────────┐
│       BLE Peripheral        │
│ ┌───────────────┐           │
│ │ Service 1     │           │
│ │ ┌───────────┐ │           │
│ │ │ Char A    │ │           │
│ │ └───────────┘ │           │
│ │ ┌───────────┐ │           │
│ │ │ Char B    │ │           │
│ │ └───────────┘ │           │
│ └───────────────┘           │
│                             │
│ Attribute Table (UUIDs, Handles)│
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│        BLE Central           │
│ Discover Services & Chars   │
│ Read/Write/Notify Data       │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think all characteristics can be freely read and written by any device? Commit yes or no.

Common Belief: All characteristics are open for reading and writing by any connected device.

Reality: Characteristics have specific properties and permissions that restrict reading or writing, sometimes requiring encryption or authentication.

Why it matters: Ignoring permissions can cause security risks or failed communication when devices try unauthorized access.

Quick: Do you think notifications always guarantee data delivery? Commit yes or no.

Common Belief: Notifications always ensure the receiver gets the data.

Reality: Notifications do not require acknowledgment, so data might be lost; only indications guarantee delivery with confirmation.

Why it matters: Assuming notifications are reliable can lead to missed critical updates in applications.

Quick: Do you think services and characteristics are fixed and cannot be customized? Commit yes or no.

Common Belief: Only standard services and characteristics defined by Bluetooth SIG can be used.

Reality: Developers can create custom services and characteristics with unique UUIDs for specialized device features.

Why it matters: Believing this limits creativity and prevents building unique device capabilities.

Quick: Do you think descriptors change the main data value of a characteristic? Commit yes or no.

Common Belief: Descriptors modify or hold the main data value of a characteristic.

Reality: Descriptors provide extra information or configuration about the characteristic but do not change its main data value.

Why it matters: Misunderstanding descriptors can cause incorrect data interpretation or misuse of BLE features.

Expert Zone

1

Some characteristics support multiple properties simultaneously, requiring careful handling to avoid conflicts between read, write, and notify operations.

2

The order of service and characteristic discovery can affect connection speed and power consumption in constrained devices.

3

Custom UUIDs must be managed carefully to avoid collisions and ensure interoperability with other devices and apps.

When NOT to use

Avoid using custom services and characteristics when standard ones meet your needs, as custom definitions reduce interoperability. For very high data rates or complex interactions, consider other wireless protocols like Wi-Fi or Thread instead of BLE.

Production Patterns

In production, devices often implement a mix of standard and custom services to balance compatibility and unique features. Notifications are used for real-time updates like sensor readings, while indications ensure critical commands are acknowledged. Descriptors provide user-friendly metadata for apps to display data correctly.

Connections

RESTful APIs

Both use structured data models to organize and access information remotely.

Understanding services and characteristics in BLE helps grasp how REST APIs organize resources and endpoints for communication.

File System Hierarchy

Services and characteristics map to folders and files respectively in a file system.

Recognizing this parallel aids in visualizing how BLE data is organized and accessed.

Human Nervous System

Services act like organs grouping functions, characteristics like nerves carrying specific signals.

This biological analogy highlights how complex systems organize and transmit information efficiently.

Common Pitfalls

#1 Trying to read a characteristic without checking if it is readable.

Wrong approach:

centralDevice.readCharacteristic(characteristicUUID); // without checking properties

Correct approach:

if (characteristic.properties.read) { centralDevice.readCharacteristic(characteristicUUID); }

Root cause:

Assuming all characteristics support reading leads to errors or failed operations.

#2 Using notifications when guaranteed delivery is required.

Wrong approach:

characteristic.enableNotification(); // expecting guaranteed data receipt

Correct approach:

characteristic.enableIndication(); // ensures acknowledgment from central

Root cause:

Confusing notifications with indications causes unreliable data transfer.

#3 Defining custom services with UUIDs that conflict with standard ones.

Wrong approach:

Using a UUID like 180D (Heart Rate Service) for a custom service.

Correct approach:

Generate and use a unique 128-bit UUID for custom services.

Root cause:

Not understanding UUID uniqueness leads to interoperability issues.

Key Takeaways

Services group related data and functions on BLE devices, making communication organized and efficient.

Characteristics are the individual data points or controls within services, each with specific properties and permissions.

Notifications and indications provide different ways to send data updates, balancing speed and reliability.

Descriptors add important metadata to characteristics, helping devices interpret data correctly.

Using standard services ensures compatibility, while custom services allow unique device features but require careful management.

Practice

1. What is the main role of a service in IoT protocols?

easy

A. To encrypt communication between devices

B. To store individual data values

C. To define the device's network address

D. To group related data and functions on a device

Solution

1. Step 1: Understand the concept of a service

   A service groups related data and functions on a device to organize them logically.

2. Step 2: Differentiate service from characteristics

   Characteristics are individual data pieces inside a service, not the grouping itself.

3. Final Answer:

   To group related data and functions on a device -> Option D

4. Quick Check:

   Service = Grouping data [OK]

Hint: Services group data; characteristics hold data values [OK]

Common Mistakes:

• Confusing services with characteristics
• Thinking services store single data values
• Mixing service role with network functions

2. Which of the following is the correct way to define a characteristic with read and write properties in a device configuration?

easy

A. characteristic: { uuid: '1234', properties: read; write }

B. characteristic: { uuid: '1234', properties: 'read, write' }

C. characteristic: { uuid: '1234', properties: ['read', 'write'] }

D. characteristic: { uuid: '1234', properties: read write }

Solution

1. Step 1: Check the syntax for properties list

   Properties should be an array of strings, e.g., ['read', 'write'].

2. Step 2: Identify correct syntax among options

   Only characteristic: { uuid: '1234', properties: ['read', 'write'] } uses an array with strings correctly; others use invalid formats.

3. Final Answer:

   characteristic: { uuid: '1234', properties: ['read', 'write'] } -> Option C

4. Quick Check:

   Properties as array of strings = characteristic: { uuid: '1234', properties: ['read', 'write'] } [OK]

Hint: Use array of strings for properties, not comma strings [OK]

Common Mistakes:

• Using comma-separated string instead of array
• Omitting quotes around property names
• Using invalid separators like semicolons

3. Given this code snippet for a device service:

service = {
  uuid: 'abcd',
  characteristics: [
    { uuid: '1234', properties: ['read'] },
    { uuid: '5678', properties: ['write'] }
  ]
}
console.log(service.characteristics[1].properties.includes('write'))

What will be the output?

medium

A. false

B. true

C. undefined

D. Error

Solution

1. Step 1: Access the second characteristic's properties

   service.characteristics[1] refers to the characteristic with uuid '5678'.

2. Step 2: Check if 'write' is included in properties

   Its properties array is ['write'], so includes('write') returns true.

3. Final Answer:

   true -> Option B

4. Quick Check:

   Includes 'write' = true [OK]

Hint: Check array index and use includes() to verify property [OK]

Common Mistakes:

• Confusing index 0 and 1 in array
• Assuming includes returns false for single-item arrays
• Expecting an error due to property access

4. You have this characteristic definition:

{ uuid: 'abcd', properties: ['read', 'notify'] }

But notifications are not working on your device. What is the most likely mistake?

medium

A. The 'notify' property is misspelled or unsupported

B. The characteristic is missing the 'write' property

C. The service UUID is incorrect

D. The characteristic UUID is too short

Solution

1. Step 1: Verify the 'notify' property spelling and support

   Notifications require the 'notify' property spelled exactly and supported by device.

2. Step 2: Check other options for relevance

   Missing 'write' does not affect notifications; UUID length or service UUID unrelated.

3. Final Answer:

   The 'notify' property is misspelled or unsupported -> Option A

4. Quick Check:

   Notification needs correct 'notify' property [OK]

Hint: Check spelling and support of 'notify' property first [OK]

Common Mistakes:

• Assuming 'write' is needed for notifications
• Blaming UUID length without evidence
• Ignoring property spelling errors

5. You want to create a service with two characteristics: one readable temperature and one writable threshold. Which configuration correctly represents this?

hard

A. service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: ['read'] }, { uuid: 'thresh1', properties: ['write'] } ] }

B. service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: 'read' }, { uuid: 'thresh1', properties: 'write' } ] }

C. service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: ['write'] }, { uuid: 'thresh1', properties: ['read'] } ] }

D. service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: ['read', 'write'] }, { uuid: 'thresh1', properties: [] } ] }

Solution

1. Step 1: Identify required properties for each characteristic

   Temperature characteristic must be readable only; threshold must be writable only.

2. Step 2: Check each option's properties array

   service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: ['read'] }, { uuid: 'thresh1', properties: ['write'] } ] } correctly assigns ['read'] to temperature and ['write'] to threshold.

3. Final Answer:

   service: { uuid: 'temp', characteristics: [ { uuid: 'temp1', properties: ['read'] }, { uuid: 'thresh1', properties: ['write'] } ] } -> Option A

4. Quick Check:

   Correct properties arrays for read and write [OK]

Hint: Match properties array exactly to read or write need [OK]

Common Mistakes:

• Using string instead of array for properties
• Swapping read and write properties
• Leaving properties empty when needed