Binary Sensor Profile v1.0
Binary Sensor Profile v1.0
Binary Sensor Profile v1.0
▪ Revision: v1.0
▪ Revision Date: 2019-07-02
▪ Group Prepared By: PUID Working Group
▪ Feedback Email: [email protected]
Abstract:
The Binary Sensor Profile (BSP) enables a Collector device to receive status reports from binary (open/closed,
on/off, etc.) sensors.
Revision History
Revision Number Date Comments
Contributors
Name Company
Use of this specification is your acknowledgement that you agree to and will comply with the following notices and
disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use,
interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements
between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at
www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership
and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable
agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members.
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the
intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license
to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH
SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-
INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE
OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that
may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications
and it disclaims any obligation or duty to do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES
DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION
CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS
INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER
CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR
AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
If this specification is a prototyping specification, it is solely for the purpose of developing and using prototypes to verify
the prototyping specifications at Bluetooth SIG sponsored IOP events. Prototyping Specifications cannot be used to develop
products for sale or distribution and prototypes cannot be qualified for distribution.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use,
implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous
countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations,
telecommunications regulations, technology transfer controls and health and safety regulations. You are solely responsible
for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or
licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth
Products. Nothing in this specification provides any information or assistance in connection with complying with applicable
laws or regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted
by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of
Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final
specifications in accordance with its membership and operating agreements.
Copyright © 2018–2019. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB,
Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The
Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of
their respective owners.
Contents
1 Introduction ..................................................................................................................................... 5
1.1 Profile dependencies ............................................................................................................... 5
1.2 Conformance ........................................................................................................................... 5
1.3 Bluetooth specification release compatibility............................................................................. 5
1.4 Language ................................................................................................................................ 5
1.4.1 Language conventions ...................................................................................................................... 5
1.4.2 Reserved for Future Use................................................................................................................... 6
1.4.3 Prohibited ......................................................................................................................................... 6
2 Configuration................................................................................................................................... 7
2.1 Roles ....................................................................................................................................... 7
2.2 Role/service relationships ........................................................................................................ 7
2.3 Concurrency limitations/restrictions .......................................................................................... 7
2.4 Topology limitations/restrictions ............................................................................................... 7
2.5 Transport dependencies .......................................................................................................... 7
3 Sensor role requirements ............................................................................................................... 8
3.1 Incremental Binary Sensor Service requirements ..................................................................... 8
3.1.1 Additional requirements for Low Energy transport .............................................................................. 8
4 Collector role requirements ............................................................................................................ 9
4.1 GATT sub-procedure requirements .......................................................................................... 9
4.2 Service discovery................................................................................................................... 10
4.2.1 Binary Sensor Service discovery ..................................................................................................... 10
4.3 Characteristic discovery ......................................................................................................... 10
4.3.1 Binary Sensor Service characteristic discovery ................................................................................ 10
4.4 BSS Control Point and BSS Response procedures ................................................................ 10
4.4.1 Get Sensor Status Command Procedure ......................................................................................... 10
4.4.2 Setting Sensor Command Procedure .............................................................................................. 11
4.4.3 Sensor Status Event Procedure ...................................................................................................... 11
5 Protocol requirements .................................................................................................................. 12
6 Segmentation and reassembly ..................................................................................................... 13
7 Connection establishment procedures ........................................................................................ 14
8 Security considerations ................................................................................................................ 15
8.1 Sensor security considerations............................................................................................... 15
8.2 Collector security considerations ............................................................................................ 15
9 Acronyms and abbreviations........................................................................................................ 16
10 References..................................................................................................................................... 17
Appendix A: Binary Sensors with wearable devices ......................................................................... 18
1 Introduction
The Binary Sensor Profile, in conjunction with the Binary Sensor Service [1], provides two characteristics
that are used for a protocol between the client and a server to transfer the status of binary sensors on the
server side.
1.2 Conformance
If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification
shall be supported in the specified manner (process-mandatory). This also applies to all optional and
conditional capabilities for which support is indicated.
1.4 Language
1.4.1 Language conventions
The Bluetooth SIG has established the following conventions for use of the words shall, must, will,
should, may, can, is, and note in the development of specifications:
OR
should is recommended that – used to indicate that among several possibilities one
is recommended as particularly suitable, but not required.
note Used to indicate text that is included for informational purposes only and is
not required in order to implement the specification. Each note is clearly
designated as a “Note” and set off in a separate paragraph.
For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.
1.4.3 Prohibited
When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values
shall never be used by an implementation, and any message received that includes a Prohibited value
shall be ignored and shall not be processed and shall not be responded to.
Where a field, parameter, or other variable object can take a range of values, and some values are
described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device
receiving an object with such a value should reject it, and any data structure containing it, as being
erroneous.
“Prohibited” is never abbreviated.
2 Configuration
2.1 Roles
The profile defines two roles: the Sensor role and the Collector role:
• The Sensor role applies to the device that reports binary sensor status to a Collector device.
• The Collector role applies to the device that receives data from a Binary Sensor device.
Hereafter, this document will simply refer to these devices that implement such roles as a Sensor and a
Collector.
For a wearable device with limited resources, the implementer can choose to implement the Alert
Notification Profile Client role to receive notification via a device implementing the Binary Sensor Profile
Collector role. For more information, see Binary Sensors with wearable devices.
The Sensor role shall have one instance of the Binary Sensor Service.
Service Server
M: Mandatory
M: Mandatory
Indications M
The GATT Discover All Characteristic Descriptors sub-procedure shall be used to discover the Client
Characteristic Configuration descriptor.
The Get Sensor Status Command Message shall have exactly 1 parameter.
The Sensor Type Parameter shall be set to the type of sensor the Collector is requesting information for.
The Collector shall wait for a Get Sensor Status Response Message indicated on the BSS Response
characteristic of the Binary Sensor Service.
The Setting Sensor Command Message shall have at least two parameters as described below:
• The Sensor Type Parameter shall be set to the type of sensor that the Setting Sensor Command
Message shall act on.
For a Single Sensor, the Setting Sensor Command Message may include one Name parameter.
For a Multiple Sensor, the Setting Sensor Command Message may include a Name parameter for each
sensor element.
The Collector shall wait for a Setting Sensor Response Message indicated on the BSS Response
characteristic of the Binary Sensor Service.
5 Protocol requirements
The Collector shall implement the protocol as described in the Binary Sensor Service [1]. The Collector
shall support all defined sensor types and the Named Sensors option.
8 Security considerations
This section describes the security requirements for both Sensor and Collector.
All supported characteristics specified by the Binary Sensor Service shall be set to LE security mode 1
and security level 2 as defined in [2] Volume 3, Part C.
The Collector shall accept any request by the Sensor for LE security mode 1 level 2, level 3, or level 4 as
defined in [2] Volume 3, Part C.
10 References
[1] Binary Sensor Service Specification
[2] Bluetooth Core Specification, Version 5.0 or later
[3] Service UUIDs, Characteristic, and Descriptor descriptions accessible via the Bluetooth SIG Assigned
Numbers
For a wearable device with limited resources, the implementer can choose to implement the Alert
Notification Profile Client role to receive notification via a device implementing the Binary Sensor Profile
Collector role. The wearable device then receives alerts from a smart device running the Binary Sensor
Profile as shown in Figure A.1.
Figure A.1: Relationship between the Binary Sensor Profile and the Alert Notification Profile