특성 읽기와 쓰기

A service is a folder, but the real values live inside characteristics. These are the slots a phone actually reads and writes. 📦

Like services, every characteristic carries its own UUID. The phone uses it to target one exact value, such as temperature.

You build a characteristic on a service and declare what it allows: reading, writing, or both. Properties decide who can do what.

Use PROPERTY_READ for values the phone fetches, and PROPERTY_WRITE for ones it sends back. Combine them when both directions matter.

Your sketch stores the current data with setValue. When the phone reads, it gets exactly whatever you placed there last.

For a writable characteristic, the phone can push a value to your board. Your code reads it with getValue to learn what arrived.

To respond the instant a write happens, attach a callback. Its onWrite method fires automatically whenever the phone sends data.

With notify, your board pushes new values the moment they change. The phone gets fresh data without asking again and again.

BLE sends raw bytes, not numbers. Send text like 23.5 or pack the number yourself, then unpack it on the phone side.

A default BLE write fits about twenty bytes. Keep each characteristic focused on one small value rather than a giant blob.

Those three jobs cover almost every project. Read shares state, write accepts commands, and notify streams live updates.

You want the phone to get new readings the instant they change.

Characteristics hold the data: set properties for read, write, or notify, store values, and let callbacks react to incoming writes. 🚀