2019-10-22 02:05:36 -04:00
:mod: `ubluetooth` --- low-level Bluetooth
=========================================
2019-10-08 00:55:11 -04:00
2019-10-22 02:05:36 -04:00
.. module :: ubluetooth
2019-10-08 00:55:11 -04:00
:synopsis: Low-level Bluetooth radio functionality
This module provides an interface to a Bluetooth controller on a board.
Currently this supports Bluetooth Low Energy (BLE) in Central, Peripheral,
2020-09-10 22:26:09 -04:00
Broadcaster, and Observer roles, as well as GATT Server and Client. A device
may operate in multiple roles concurrently.
2019-10-08 00:55:11 -04:00
This API is intended to match the low-level Bluetooth protocol and provide
building-blocks for higher-level abstractions such as specific device types.
2019-12-10 00:58:27 -05:00
.. note :: This module is still under development and its classes, functions,
methods and constants are subject to change.
2019-10-08 00:55:11 -04:00
class BLE
---------
Constructor
-----------
.. class :: BLE()
Returns the singleton BLE object.
Configuration
-------------
2020-09-10 21:45:09 -04:00
.. method :: BLE.active([active], /)
2019-10-08 00:55:11 -04:00
Optionally changes the active state of the BLE radio, and returns the
current state.
The radio must be made active before using any other methods on this class.
2020-09-10 21:45:09 -04:00
.. method :: BLE.config('param', /)
BLE.config(*, param=value, ...)
2019-10-08 00:55:11 -04:00
2019-11-28 23:26:57 -05:00
Get or set configuration values of the BLE interface. To get a value the
parameter name should be quoted as a string, and just one parameter is
queried at a time. To set values use the keyword syntax, and one ore more
parameter can be set at a time.
Currently supported values are:
2019-10-08 00:55:11 -04:00
2020-08-14 01:17:14 -04:00
- `` 'mac' `` : The current address in use, depending on the current address mode.
This returns a tuple of `` (addr_type, addr) `` .
2020-07-17 01:18:32 -04:00
2020-08-14 01:17:14 -04:00
See :meth: `gatts_write <BLE.gap_scan>` for details about address type.
This may only be queried while the interface is currently active.
- `` 'addr_mode' `` : Sets the address mode. Values can be:
* 0x00 - PUBLIC - Use the controller's public address.
* 0x01 - RANDOM - Use a generated static address.
* 0x02 - RPA - Use resolvable private addresses.
* 0x03 - NRPA - Use non-resolvable private addresses.
By default the interface mode will use a PUBLIC address if available, otherwise
it will use a RANDOM address.
2019-10-08 00:55:11 -04:00
2020-05-07 23:54:10 -04:00
- `` 'gap_name' `` : Get/set the GAP device name used by service 0x1800,
characteristic 0x2a00. This can be set at any time and changed multiple
times.
2020-01-01 15:43:23 -05:00
- `` 'rxbuf' `` : Get/set the size in bytes of the internal buffer used to store
2019-11-28 23:26:57 -05:00
incoming events. This buffer is global to the entire BLE driver and so
handles incoming data for all events, including all characteristics.
Increasing this allows better handling of bursty incoming data (for
2020-09-10 22:26:09 -04:00
example scan results) and the ability to receive larger characteristic values.
2019-11-28 23:26:57 -05:00
2020-09-10 23:24:12 -04:00
- `` 'mtu' `` : Get/set the MTU that will be used during an MTU exchange. The
resulting MTU will be the minimum of this and the remote device's MTU.
MTU exchange will not happen automatically (unless the remote device initiates
it), and must be manually initiated with
:meth: `gattc_exchange_mtu<BLE.gattc_exchange_mtu>` .
Use the `` _IRQ_MTU_EXCHANGED `` event to discover the MTU for a given connection.
2019-10-08 00:55:11 -04:00
Event Handling
--------------
2020-09-10 21:45:09 -04:00
.. method :: BLE.irq(handler, /)
2019-10-08 00:55:11 -04:00
Registers a callback for events from the BLE stack. The *handler* takes two
arguments, `` event `` (which will be one of the codes below) and `` data ``
(which is an event-specific tuple of values).
2020-07-17 01:18:32 -04:00
**Note:** the `` addr `` , `` adv_data `` , `` char_data `` , `` notify_data `` , and
`` uuid `` entries in the tuples are references to data managed by the
:mod: `ubluetooth` module (i.e. the same instance will be re-used across
multiple calls to the event handler). If your program wants to use this
data outside of the handler, then it must copy them first, e.g. by using
`` bytes(addr) `` or `` bluetooth.UUID(uuid) `` .
2019-11-19 18:45:14 -05:00
2019-10-08 00:55:11 -04:00
An event handler showing all possible events::
def bt_irq(event, data):
if event == _IRQ_CENTRAL_CONNECT:
# A central has connected to this peripheral.
conn_handle, addr_type, addr = data
elif event == _IRQ_CENTRAL_DISCONNECT:
# A central has disconnected from this peripheral.
conn_handle, addr_type, addr = data
elif event == _IRQ_GATTS_WRITE:
2020-09-10 22:26:09 -04:00
# A client has written to this characteristic or descriptor.
2019-10-08 00:55:11 -04:00
conn_handle, attr_handle = data
elif event == _IRQ_GATTS_READ_REQUEST:
2020-09-10 22:26:09 -04:00
# A client has issued a read. Note: this is a hard IRQ.
2019-10-08 00:55:11 -04:00
# Return None to deny the read.
2019-10-14 00:45:31 -04:00
# Note: This event is not supported on ESP32.
2019-10-08 00:55:11 -04:00
conn_handle, attr_handle = data
elif event == _IRQ_SCAN_RESULT:
# A single scan result.
extmod/modbluetooth: Change scan result's "connectable" to "adv_type".
This commit changes the BLE _IRQ_SCAN_RESULT data from:
addr_type, addr, connectable, rssi, adv_data
to:
addr_type, addr, adv_type, rssi, adv_data
This allows _IRQ_SCAN_RESULT to handle all scan result types (not just
connectable and non-connectable passive scans), and to distinguish between
them using adv_type which is an integer taking values 0x00-0x04 per the BT
specification.
This is a breaking change to the API, albeit a very minor one: the existing
connectable value was a boolean and True now becomes 0x00, False becomes
0x02.
Documentation is updated and a test added.
Fixes #5738.
2020-03-09 20:45:03 -04:00
addr_type, addr, adv_type, rssi, adv_data = data
2020-05-13 02:49:57 -04:00
elif event == _IRQ_SCAN_DONE:
2019-10-08 00:55:11 -04:00
# Scan duration finished or manually stopped.
pass
elif event == _IRQ_PERIPHERAL_CONNECT:
# A successful gap_connect().
conn_handle, addr_type, addr = data
elif event == _IRQ_PERIPHERAL_DISCONNECT:
# Connected peripheral has disconnected.
conn_handle, addr_type, addr = data
elif event == _IRQ_GATTC_SERVICE_RESULT:
# Called for each service found by gattc_discover_services().
conn_handle, start_handle, end_handle, uuid = data
2020-05-13 02:49:57 -04:00
elif event == _IRQ_GATTC_SERVICE_DONE:
# Called once service discovery is complete.
2020-05-19 02:00:23 -04:00
# Note: Status will be zero on success, implementation-specific value otherwise.
2020-05-13 02:49:57 -04:00
conn_handle, status = data
2019-10-08 00:55:11 -04:00
elif event == _IRQ_GATTC_CHARACTERISTIC_RESULT:
# Called for each characteristic found by gattc_discover_services().
conn_handle, def_handle, value_handle, properties, uuid = data
2020-05-13 02:49:57 -04:00
elif event == _IRQ_GATTC_CHARACTERISTIC_DONE:
# Called once service discovery is complete.
2020-05-19 02:00:23 -04:00
# Note: Status will be zero on success, implementation-specific value otherwise.
2020-05-13 02:49:57 -04:00
conn_handle, status = data
2019-10-08 00:55:11 -04:00
elif event == _IRQ_GATTC_DESCRIPTOR_RESULT:
# Called for each descriptor found by gattc_discover_descriptors().
conn_handle, dsc_handle, uuid = data
2020-05-13 02:49:57 -04:00
elif event == _IRQ_GATTC_DESCRIPTOR_DONE:
# Called once service discovery is complete.
2020-05-19 02:00:23 -04:00
# Note: Status will be zero on success, implementation-specific value otherwise.
2020-05-13 02:49:57 -04:00
conn_handle, status = data
2019-10-08 00:55:11 -04:00
elif event == _IRQ_GATTC_READ_RESULT:
# A gattc_read() has completed.
conn_handle, value_handle, char_data = data
2020-05-13 02:49:57 -04:00
elif event == _IRQ_GATTC_READ_DONE:
# A gattc_read() has completed.
# Note: The value_handle will be zero on btstack (but present on NimBLE).
2020-05-19 02:00:23 -04:00
# Note: Status will be zero on success, implementation-specific value otherwise.
2020-05-13 02:49:57 -04:00
conn_handle, value_handle, status = data
elif event == _IRQ_GATTC_WRITE_DONE:
2019-10-08 00:55:11 -04:00
# A gattc_write() has completed.
2020-05-13 02:49:57 -04:00
# Note: The value_handle will be zero on btstack (but present on NimBLE).
2020-05-19 02:00:23 -04:00
# Note: Status will be zero on success, implementation-specific value otherwise.
2019-10-08 00:55:11 -04:00
conn_handle, value_handle, status = data
elif event == _IRQ_GATTC_NOTIFY:
2020-09-10 22:26:09 -04:00
# A server has sent a notify request.
2019-10-08 00:55:11 -04:00
conn_handle, value_handle, notify_data = data
elif event == _IRQ_GATTC_INDICATE:
2020-09-10 22:26:09 -04:00
# A server has sent an indicate request.
2019-10-08 00:55:11 -04:00
conn_handle, value_handle, notify_data = data
2020-07-20 03:33:12 -04:00
elif event == _IRQ_GATTS_INDICATE_DONE:
2020-09-10 22:26:09 -04:00
# A client has acknowledged the indication.
2020-07-20 03:33:12 -04:00
# Note: Status will be zero on successful acknowledgment, implementation-specific value otherwise.
conn_handle, value_handle, status = data
2020-09-10 23:24:12 -04:00
elif event == _IRQ_MTU_EXCHANGED:
# MTU exchange complete (either initiated by us or the remote device).
conn_handle, mtu = data
2019-10-08 00:55:11 -04:00
The event codes are::
from micropython import const
2020-05-13 02:49:57 -04:00
_IRQ_CENTRAL_CONNECT = const(1)
_IRQ_CENTRAL_DISCONNECT = const(2)
_IRQ_GATTS_WRITE = const(3)
_IRQ_GATTS_READ_REQUEST = const(4)
_IRQ_SCAN_RESULT = const(5)
_IRQ_SCAN_DONE = const(6)
_IRQ_PERIPHERAL_CONNECT = const(7)
_IRQ_PERIPHERAL_DISCONNECT = const(8)
_IRQ_GATTC_SERVICE_RESULT = const(9)
_IRQ_GATTC_SERVICE_DONE = const(10)
_IRQ_GATTC_CHARACTERISTIC_RESULT = const(11)
_IRQ_GATTC_CHARACTERISTIC_DONE = const(12)
_IRQ_GATTC_DESCRIPTOR_RESULT = const(13)
_IRQ_GATTC_DESCRIPTOR_DONE = const(14)
_IRQ_GATTC_READ_RESULT = const(15)
_IRQ_GATTC_READ_DONE = const(16)
_IRQ_GATTC_WRITE_DONE = const(17)
_IRQ_GATTC_NOTIFY = const(18)
_IRQ_GATTC_INDICATE = const(19)
2020-07-20 03:33:12 -04:00
_IRQ_GATTS_INDICATE_DONE = const(20)
2020-09-10 23:24:12 -04:00
_IRQ_MTU_EXCHANGED = const(21)
2019-10-08 00:55:11 -04:00
In order to save space in the firmware, these constants are not included on the
2019-10-22 02:05:36 -04:00
:mod: `ubluetooth` module. Add the ones that you need from the list above to your
2019-10-08 00:55:11 -04:00
program.
Broadcaster Role (Advertiser)
-----------------------------
2020-09-10 21:45:09 -04:00
.. method :: BLE.gap_advertise(interval_us, adv_data=None, *, resp_data=None, connectable=True)
2019-10-08 00:55:11 -04:00
Starts advertising at the specified interval (in **micro** \ seconds). This
interval will be rounded down to the nearest 625us. To stop advertising, set
*interval_us* to `` None `` .
*adv_data* and *resp_data* can be any type that implements the buffer
protocol (e.g. `` bytes `` , `` bytearray `` , `` str `` ). *adv_data* is included
in all broadcasts, and *resp_data* is send in reply to an active scan.
2020-07-17 01:18:32 -04:00
**Note:** if *adv_data* (or *resp_data* ) is `` None `` , then the data passed
2019-10-14 00:45:31 -04:00
to the previous call to `` gap_advertise `` will be re-used. This allows a
broadcaster to resume advertising with just `` gap_advertise(interval_us) `` .
To clear the advertising payload pass an empty `` bytes `` , i.e. `` b'' `` .
2019-10-08 00:55:11 -04:00
Observer Role (Scanner)
-----------------------
2020-09-10 21:45:09 -04:00
.. method :: BLE.gap_scan(duration_ms, interval_us=1280000, window_us=11250, active=False, /)
2019-10-08 00:55:11 -04:00
Run a scan operation lasting for the specified duration (in **milli** \ seconds).
To scan indefinitely, set *duration_ms* to `` 0 `` .
To stop scanning, set *duration_ms* to `` None `` .
Use *interval_us* and *window_us* to optionally configure the duty cycle.
The scanner will run for *window_us* **micro** \ seconds every *interval_us*
**micro** \ seconds for a total of *duration_ms* **milli** \ seconds. The default
interval and window are 1.28 seconds and 11.25 milliseconds respectively
(background scanning).
extmod/modbluetooth: Change scan result's "connectable" to "adv_type".
This commit changes the BLE _IRQ_SCAN_RESULT data from:
addr_type, addr, connectable, rssi, adv_data
to:
addr_type, addr, adv_type, rssi, adv_data
This allows _IRQ_SCAN_RESULT to handle all scan result types (not just
connectable and non-connectable passive scans), and to distinguish between
them using adv_type which is an integer taking values 0x00-0x04 per the BT
specification.
This is a breaking change to the API, albeit a very minor one: the existing
connectable value was a boolean and True now becomes 0x00, False becomes
0x02.
Documentation is updated and a test added.
Fixes #5738.
2020-03-09 20:45:03 -04:00
For each scan result the `` _IRQ_SCAN_RESULT `` event will be raised, with event
2020-08-14 01:17:14 -04:00
data `` (addr_type, addr, adv_type, rssi, adv_data) `` .
`` addr_type `` values indicate public or random addresses:
* 0x00 - PUBLIC
* 0x01 - RANDOM (either static, RPA, or NRPA, the type is encoded in the address itself)
`` adv_type `` values correspond to the Bluetooth Specification:
extmod/modbluetooth: Change scan result's "connectable" to "adv_type".
This commit changes the BLE _IRQ_SCAN_RESULT data from:
addr_type, addr, connectable, rssi, adv_data
to:
addr_type, addr, adv_type, rssi, adv_data
This allows _IRQ_SCAN_RESULT to handle all scan result types (not just
connectable and non-connectable passive scans), and to distinguish between
them using adv_type which is an integer taking values 0x00-0x04 per the BT
specification.
This is a breaking change to the API, albeit a very minor one: the existing
connectable value was a boolean and True now becomes 0x00, False becomes
0x02.
Documentation is updated and a test added.
Fixes #5738.
2020-03-09 20:45:03 -04:00
* 0x00 - ADV_IND - connectable and scannable undirected advertising
* 0x01 - ADV_DIRECT_IND - connectable directed advertising
* 0x02 - ADV_SCAN_IND - scannable undirected advertising
* 0x03 - ADV_NONCONN_IND - non-connectable undirected advertising
* 0x04 - SCAN_RSP - scan response
2019-10-08 00:55:11 -04:00
2020-08-13 21:49:41 -04:00
`` active `` can be set `` True `` if you want to receive scan responses in the results.
2020-09-10 21:45:09 -04:00
2019-10-08 00:55:11 -04:00
When scanning is stopped (either due to the duration finishing or when
2020-05-13 02:49:57 -04:00
explicitly stopped), the `` _IRQ_SCAN_DONE `` event will be raised.
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Central Role
------------
A central device can connect to peripherals that it has discovered using the observer role (see :meth: `gap_scan<BLE.gap_scan>` ) or with a known address.
.. method :: BLE.gap_connect(addr_type, addr, scan_duration_ms=2000, /)
Connect to a peripheral.
See :meth: `gap_scan <BLE.gap_scan>` for details about address types.
On success, the `` _IRQ_PERIPHERAL_CONNECT `` event will be raised.
Peripheral Role
---------------
A peripheral device is expected to send connectable advertisements (see
:meth: `gap_advertise<BLE.gap_advertise>` ). It will usually be acting as a GATT
server, having first registered services and characteristics using
:meth: `gatts_register_services<BLE.gatts_register_services>` .
When a central connects, the `` _IRQ_CENTRAL_CONNECT `` event will be raised.
Central & Peripheral Roles
--------------------------
.. method :: BLE.gap_disconnect(conn_handle, /)
Disconnect the specified connection handle. This can either be a
central that has connected to this device (if acting as a peripheral)
or a peripheral that was previously connected to by this device (if acting
as a central).
On success, the `` _IRQ_PERIPHERAL_DISCONNECT `` or `` _IRQ_CENTRAL_DISCONNECT ``
event will be raised.
Returns `` False `` if the connection handle wasn't connected, and `` True ``
otherwise.
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
GATT Server
-----------
A GATT server has a set of registered services. Each service may contain
2019-10-08 00:55:11 -04:00
characteristics, which each have a value. Characteristics can also contain
descriptors, which themselves have values.
2019-10-14 00:45:31 -04:00
These values are stored locally, and are accessed by their "value handle" which
is generated during service registration. They can also be read from or written
2020-09-10 22:26:09 -04:00
to by a remote client device. Additionally, a server can "notify" a
characteristic to a connected client via a connection handle.
A device in either central or peripheral roles may function as a GATT server,
however in most cases it will be more common for a peripheral device to act
as the server.
2019-10-08 00:55:11 -04:00
2019-10-14 19:10:41 -04:00
Characteristics and descriptors have a default maximum size of 20 bytes.
2020-09-10 22:26:09 -04:00
Anything written to them by a client will be truncated to this length. However,
2019-10-14 19:10:41 -04:00
any local write will increase the maximum size, so if you want to allow larger
2020-09-10 22:26:09 -04:00
writes from a client to a given characteristic, use
2019-10-14 19:10:41 -04:00
:meth: `gatts_write<BLE.gatts_write>` after registration. e.g.
`` gatts_write(char_handle, bytes(100)) `` .
2020-09-10 21:45:09 -04:00
.. method :: BLE.gatts_register_services(services_definition, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Configures the server with the specified services, replacing any
2019-10-08 00:55:11 -04:00
existing services.
*services_definition* is a list of **services** , where each **service** is a
two-element tuple containing a UUID and a list of **characteristics** .
Each **characteristic** is a two-or-three-element tuple containing a UUID, a
**flags** value, and optionally a list of *descriptors* .
Each **descriptor** is a two-element tuple containing a UUID and a **flags**
value.
The **flags** are a bitwise-OR combination of the
2019-11-11 23:15:12 -05:00
:data: `ubluetooth.FLAG_READ` , :data: `ubluetooth.FLAG_WRITE` and
:data: `ubluetooth.FLAG_NOTIFY` values defined below.
2019-10-08 00:55:11 -04:00
The return value is a list (one element per service) of tuples (each element
is a value handle). Characteristics and descriptor handles are flattened
into the same tuple, in the order that they are defined.
The following example registers two services (Heart Rate, and Nordic UART)::
HR_UUID = bluetooth.UUID(0x180D)
HR_CHAR = (bluetooth.UUID(0x2A37), bluetooth.FLAG_READ | bluetooth.FLAG_NOTIFY,)
2019-10-15 20:23:54 -04:00
HR_SERVICE = (HR_UUID, (HR_CHAR,),)
2019-10-08 00:55:11 -04:00
UART_UUID = bluetooth.UUID('6E400001-B5A3-F393-E0A9-E50E24DCCA9E')
UART_TX = (bluetooth.UUID('6E400003-B5A3-F393-E0A9-E50E24DCCA9E'), bluetooth.FLAG_READ | bluetooth.FLAG_NOTIFY,)
UART_RX = (bluetooth.UUID('6E400002-B5A3-F393-E0A9-E50E24DCCA9E'), bluetooth.FLAG_WRITE,)
UART_SERVICE = (UART_UUID, (UART_TX, UART_RX,),)
SERVICES = (HR_SERVICE, UART_SERVICE,)
( (hr,), (tx, rx,), ) = bt.gatts_register_services(SERVICES)
The three value handles (`` hr `` , `` tx `` , `` rx `` ) can be used with
2020-07-17 01:18:32 -04:00
:meth: `gatts_read <BLE.gatts_read>` , :meth: `gatts_write <BLE.gatts_write>` , :meth: `gatts_notify <BLE.gatts_notify>` , and
:meth: `gatts_indicate <BLE.gatts_indicate>` .
2019-10-08 00:55:11 -04:00
**Note:** Advertising must be stopped before registering services.
2020-09-10 21:45:09 -04:00
.. method :: BLE.gatts_read(value_handle, /)
2019-10-08 00:55:11 -04:00
Reads the local value for this handle (which has either been written by
2020-09-10 22:26:09 -04:00
:meth: `gatts_write <BLE.gatts_write>` or by a remote client).
2019-10-08 00:55:11 -04:00
2020-09-10 21:45:09 -04:00
.. method :: BLE.gatts_write(value_handle, data, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Writes the local value for this handle, which can be read by a client.
2019-10-08 00:55:11 -04:00
2020-09-10 21:45:09 -04:00
.. method :: BLE.gatts_notify(conn_handle, value_handle, data=None, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Sends a notification request to a connected client.
2020-07-17 01:18:32 -04:00
2020-09-10 22:26:09 -04:00
If *data* is not `` None `` , then that value is sent to the client as part of
2020-07-17 01:18:32 -04:00
the notification. The local value will not be modified.
2020-09-10 21:45:09 -04:00
Otherwise, if *data* is `` None `` , then the current local value (as
2020-07-17 01:18:32 -04:00
set with :meth: `gatts_write <BLE.gatts_write>` ) will be sent.
2020-09-10 21:45:09 -04:00
.. method :: BLE.gatts_indicate(conn_handle, value_handle, /)
2020-07-17 01:18:32 -04:00
2020-09-10 22:26:09 -04:00
Sends an indication request to a connected client.
2020-07-17 01:18:32 -04:00
**Note:** This does not currently support sending a custom value, it will
always send the current local value (as set with :meth:`gatts_write
<BLE.gatts_write>`).
2019-10-08 00:55:11 -04:00
2020-07-20 03:33:12 -04:00
On acknowledgment (or failure, e.g. timeout), the
`` _IRQ_GATTS_INDICATE_DONE `` event will be raised.
2019-10-08 00:55:11 -04:00
2020-01-11 01:44:17 -05:00
.. method :: BLE.gatts_set_buffer(value_handle, len, append=False, /)
2019-10-28 02:29:08 -04:00
Sets the internal buffer size for a value in bytes. This will limit the
largest possible write that can be received. The default is 20.
Setting *append* to `` True `` will make all remote writes append to, rather
than replace, the current value. At most *len* bytes can be buffered in
this way. When you use :meth: `gatts_read <BLE.gatts_read>` , the value will
be cleared after reading. This feature is useful when implementing something
like the Nordic UART Service.
2020-09-10 22:26:09 -04:00
GATT Client
-----------
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
A GATT client can discover and read/write characteristics on a remote GATT server.
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
It is more common for a central role device to act as the GATT client, however
it's also possible for a peripheral to act as a client in order to discover
information about the central that has connected to it (e.g. to read the
device name from the device information service).
2019-10-14 21:07:29 -04:00
2020-09-10 21:45:09 -04:00
.. method :: BLE.gattc_discover_services(conn_handle, uuid=None, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Query a connected server for its services.
2019-10-08 00:55:11 -04:00
2020-05-13 02:49:57 -04:00
Optionally specify a service *uuid* to query for that service only.
2019-10-08 00:55:11 -04:00
2020-05-13 02:49:57 -04:00
For each service discovered, the `` _IRQ_GATTC_SERVICE_RESULT `` event will
be raised, followed by `` _IRQ_GATTC_SERVICE_DONE `` on completion.
2020-09-10 21:45:09 -04:00
.. method :: BLE.gattc_discover_characteristics(conn_handle, start_handle, end_handle, uuid=None, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Query a connected server for characteristics in the specified range.
2019-10-08 00:55:11 -04:00
2020-05-13 02:49:57 -04:00
Optionally specify a characteristic *uuid* to query for that
characteristic only.
You can use `` start_handle=1 `` , `` end_handle=0xffff `` to search for a
characteristic in any service.
2019-10-08 00:55:11 -04:00
For each characteristic discovered, the `` _IRQ_GATTC_CHARACTERISTIC_RESULT ``
2020-05-13 02:49:57 -04:00
event will be raised, followed by `` _IRQ_GATTC_CHARACTERISTIC_DONE `` on completion.
2019-10-08 00:55:11 -04:00
2020-09-10 21:45:09 -04:00
.. method :: BLE.gattc_discover_descriptors(conn_handle, start_handle, end_handle, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Query a connected server for descriptors in the specified range.
2019-10-08 00:55:11 -04:00
For each descriptor discovered, the `` _IRQ_GATTC_DESCRIPTOR_RESULT `` event
2020-05-13 02:49:57 -04:00
will be raised, followed by `` _IRQ_GATTC_DESCRIPTOR_DONE `` on completion.
2019-10-08 00:55:11 -04:00
2020-09-10 21:45:09 -04:00
.. method :: BLE.gattc_read(conn_handle, value_handle, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Issue a remote read to a connected server for the specified
2019-10-08 00:55:11 -04:00
characteristic or descriptor handle.
2020-05-13 02:49:57 -04:00
When a value is available, the `` _IRQ_GATTC_READ_RESULT `` event will be
raised. Additionally, the `` _IRQ_GATTC_READ_DONE `` will be raised.
2019-10-08 00:55:11 -04:00
2020-01-11 01:44:17 -05:00
.. method :: BLE.gattc_write(conn_handle, value_handle, data, mode=0, /)
2019-10-08 00:55:11 -04:00
2020-09-10 22:26:09 -04:00
Issue a remote write to a connected server for the specified
2019-10-08 00:55:11 -04:00
characteristic or descriptor handle.
2019-11-28 20:48:38 -05:00
The argument *mode* specifies the write behaviour, with the currently
supported values being:
* `` mode=0 `` (default) is a write-without-response: the write will
2020-09-10 22:26:09 -04:00
be sent to the remote server but no confirmation will be
2019-11-28 20:48:38 -05:00
returned, and no event will be raised.
2020-09-10 22:26:09 -04:00
* `` mode=1 `` is a write-with-response: the remote server is
2019-11-28 20:48:38 -05:00
requested to send a response/acknowledgement that it received the
data.
2020-09-10 22:26:09 -04:00
If a response is received from the remote server the
2020-05-13 02:49:57 -04:00
`` _IRQ_GATTC_WRITE_DONE `` event will be raised.
2019-10-08 00:55:11 -04:00
2020-09-10 23:24:12 -04:00
.. method :: BLE.gattc_exchange_mtu(conn_handle, /)
Initiate MTU exchange with a connected server, using the preferred MTU
set using `` BLE.config(mtu=value) `` .
The `` _IRQ_MTU_EXCHANGED `` event will be raised when MTU exchange
completes.
**Note:** MTU exchange is typically initiated by the central. When using
the BlueKitchen stack in the central role, it does not support a remote
peripheral initiating the MTU exchange. NimBLE works for both roles.
2019-10-08 00:55:11 -04:00
class UUID
----------
Constructor
-----------
2020-09-10 21:45:09 -04:00
.. class :: UUID(value, /)
2019-10-08 00:55:11 -04:00
Creates a UUID instance with the specified **value** .
The **value** can be either:
- A 16-bit integer. e.g. `` 0x2908 `` .
- A 128-bit UUID string. e.g. `` '6E400001-B5A3-F393-E0A9-E50E24DCCA9E' `` .
Constants
---------
2019-10-22 02:05:36 -04:00
.. data :: ubluetooth.FLAG_READ
ubluetooth.FLAG_WRITE
ubluetooth.FLAG_NOTIFY