Battery Service

Revision: v1.1
Revision Date: 2022-12-20
Prepared By: HID Working Group

Revision History

Revision Number	Date (yyyy-mm-dd)	Comments
V10r00	2011-12-27	Adopted by the Bluetooth SIG Board of Directors
v1.1	2022-12-20	Adopted by the Bluetooth SIG Board of Directors.

Version History

Versions	Changes
v1.0 to v1.1	New feature: 11 new characteristics with associated behavior Battery Level Status Estimated Service Date Battery Critical Status Battery Energy Status Battery Time Status Battery Health Status Battery Health Information Battery Information Manufacturer Name String Model Number String Serial Number String Incorporated erratum E16258

Versions

Changes

v1.0 to v1.1

New feature: 11 new characteristics with associated behavior

Battery Level Status

Estimated Service Date

Battery Critical Status

Battery Energy Status

Battery Time Status

Battery Health Status

Battery Health Information

Battery Information

Manufacturer Name String

Model Number String

Serial Number String

Incorporated erratum E16258

Acknowledgments

Name	Company
Rob Hulvey	Meta Platforms, Inc.
Siegfried Lehmann	Apple Inc.
Robert D. Hughes	Intel Corporation
Frank Gorgenyi	Microsoft Corporation
Shirin Ebrahimi-Taghizadeh	Microsoft Corporation
Chris Church	Qualcomm Technologies International
Xavier Boniface	Logitech International SA
Frank Berntsen	Nordic Semiconductor ASA

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. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

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.

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 © 2011–2022. 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.

1. Introduction

The Battery Service exposes the Battery Level and other information for a battery (which may be composed of one or more cells) in the context of the battery’s electrical connection to a device. If a device has several batteries to be monitored, then multiple instances of the Battery Service should be declared. The following examples show various ways of using the Battery Service. In each case, it is possible that the batteries are removable.

Figure 1.1 shows an example of a basic device with a single battery and Battery Service instance.

Figure 1.1. Example of Battery Service use in a basic device

Figure 1.2 and Figure 1.3 show examples of one system made up of two devices that can operate independently. In the example of Figure 1.2, these devices are physically separate, while in the example of Figure 1.3, these devices are attachable. Each device has a single battery, Battery Service instance, and Generic Attribute Profile (GATT) Server whether the devices are attached or not.

Figure 1.2. Example of Battery Service use in two physically separate devices

Figure 1.3. Example of Battery Service use in two attachable devices

Figure 1.4 shows an example of a distributed device (i.e., two physical ear buds that present as a single headset), where each device has a single battery and Battery Service instance, but the devices share a GATT Server.

Figure 1.4. Alternate example of Battery Service use in a distributed device

Figure 1.5 shows an example of a detachable and distributed device. The display has a single non-removable battery with its Battery Service instance. The base has two batteries, each with a Battery Service instance. The entire device shares a GATT Server. In this example, only the display has a Bluetooth radio and can expose the Battery Service instances for the batteries in the base. When the base is detached, the services and characteristics for those batteries remain in the GATT database but their values will show the batteries as being removed. See Appendix A for an example message sequence illustrating the removal and insertion of a battery.

Figure 1.5. Alternate example of Battery Service use in a detachable and distributed device

Figure 1.6 shows an example of a phone with a primary non-removable battery and a phone battery sleeve that was purchased later. The phone starts with a single instance of the Battery Service; however, when the phone battery sleeve is attached, the phone recognizes it and supports sending detailed battery status over a link providing battery information. The phone chooses to start a new instance of the Battery Service to represent the state of the phone battery sleeve.

Figure 1.6. Alternate example of Battery Service use in a phone with an extra battery purchased later

1.1. Language

1.1.1. Language conventions

The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, and note in the development of specifications:

shall	is required to – used to define requirements.
must	is used to express: a natural consequence of a previously stated mandatory requirement. OR an indisputable statement of fact (one that is always true regardless of the circumstances).
will	it is true that – only used in statements of fact.
should	is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required.
may	is permitted to – used to allow options.
can	is able to – used to relate statements in a causal manner.
note	Text that calls attention to a particular point, requirement, or implication or reminds the reader of a previously mentioned point. It is useful for clarifying text to which the reader ought to pay special attention. It shall not include requirements. A note begins with “Note:” and is set off in a separate paragraph. When interpreting the text, the relevant requirement shall take precedence over the clarification.

If there is a discrepancy between the information in a figure and the information in other text of the specification, the text prevails. Figures are visual aids including diagrams, message sequence charts (MSCs), tables, examples, sample data, and images. When specification content shows one of many alternatives to satisfy specification requirements, the alternative shown is not intended to limit implementation options. Other acceptable alternatives to satisfy specification requirements may also be possible.

1.1.2. Reserved for Future Use

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

1.1.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.

1.2. Table requirements

Requirements are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.3. 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 for all optional and conditional capabilities for which support is indicated.

1.4. Byte transmission order

All characteristics used with this service shall be transmitted with the least significant octet first (i.e., little endian). The least significant octet is identified in the characteristic definitions in [2].

1.5. Definitions

For the purposes of this specification, the following definitions apply.

1.5.1. Low

Low represents the battery condition in which the device will still function normally, but immediate recharge or replacement of the battery is recommended.

1.5.2. Critical

Critical represents the battery condition in which a load powered by the battery might not function fully or correctly.

1.5.3. Battery Aggregation Group

A Battery Aggregation Group represents a collection of one or more batteries that provide power to a device concurrently and in parallel. The capacity and level information of the batteries in the group, as provided by the Battery Service instances, can be aggregated for presentation to the user.

An example usage of a Battery Aggregation Group would be to sum the Available Energy field of the Battery Energy Status characteristic and sum the Available Battery Capacity field from two instances of Battery Service that share a Battery Aggregation Group as depicted in Figure 1.5. An application could choose to visually represent the percent of remaining energy for the Aggregation Group by calculating the sum of available energy divided by the sum of available battery capacity.

Another example of a Battery Aggregation Group would be to select the maximum value of the Time Until Discharged fields of the Battery Time Status characteristics from two instances of Battery Service that share a Battery Aggregation Group as depicted in Figure 1.5. An application could choose to represent this value as the estimated remaining time on the battery.

2. Service

2.1. Service dependencies

The Battery Service has no dependencies on other GATT-based services.

2.2. Bluetooth Core Specification release compatibility

The Battery Service is compatible with any version of the Bluetooth Core Specification [1] that includes GATT.

2.3. Transport dependencies

The Battery Service may operate over Low Energy (LE) and Basic Rate/Enhanced Data Rate (BR/EDR) transports. Except for the optional use of the LE broadcast feature for some characteristics, there are no transport restrictions imposed by this service specification.

2.4. Attribute Protocol Application error codes

This service does not define or reference any Attribute Protocol (ATT) Application error codes.

2.5. GATT sub-procedure requirements

Additional GATT sub-procedures requirements beyond those required by GATT are indicated in Table 2.1.

GATT Sub-Procedure	Requirements
Notifications	C.1
Indications	C.2
Read Characteristic Descriptors	M
Write Characteristic Descriptors	C.3

Table 2.1. GATT sub-procedure requirements

C.1:: Mandatory if any characteristic properties in this service allow notification; otherwise excluded.
C.2:: Mandatory if any characteristic properties in this service allow indication; otherwise excluded.
C.3:: Mandatory if any characteristic properties in this service allow notification, indication, or broadcast; otherwise excluded.

2.6. Declaration

The service UUID shall be set to «Battery Service» as defined in [2].

This service should be instantiated as a primary service if it represents the battery status for the device even if the instance is included in another service.

3. Service characteristics

The characteristics listed in Table 3.1 are exposed in the Battery Service. Only one instance of each characteristic is permitted within this service. The service, characteristic, and descriptor UUIDs are defined in [2] and the characteristic formats are defined in the GATT Specification Supplement (GSS) [3].

Where a characteristic’s properties allow it to be notified or indicated, a Client Characteristic Configuration descriptor must be included in the characteristic definition as required in Volume 3, Part G, Section 3.3.3.3 in [1].

Where a characteristic’s properties allow it to be broadcast, a Server Characteristic Configuration descriptor must be included in the characteristic definition as required in Volume 3, Part G, Section 3.3.3.4 in [1].

For many devices, the values of characteristics exposed by the Battery Service will not change frequently, therefore devices should not poll for the characteristic value at a high frequency. For example, if the expected battery life is in the order of years, reading any characteristic value more frequently than once a week is unnecessary.

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Battery Level	M	Read	Notify	None
Battery Level descriptor: Characteristic Presentation Format descriptor	C.1	Read	None	None
Battery Level Status	O	Read, Notify	LE: Broadcast **, Indicate BR/EDR: Indicate *	None
Estimated Service Date	C.2	Read, Notify	Indicate *	None
Battery Critical Status	C.2	Read, Indicate	None	None
Battery Energy Status	C.2	Read, Notify	Indicate *	None
Battery Time Status	C.2	Read, Notify	Indicate *	None
Battery Health Status	C.2	Read, Notify	Indicate *	None
Battery Health Information	C.3	Read, Indicate	None	None
Battery Information	C.2	Read, Indicate	None	None
Manufacturer Name String	O	Read, Indicate	None	None
Model Number String	O	Read, Indicate	None	None
Serial Number String	C.2	Read, Indicate	None	None**
* Recommended for life-critical or other critical applications that require reliable delivery. The connection should be authenticated if the Serial Number String can contain personally identifiable information for a device. * Broadcasting relatively static data without encryption may constitute personally identifiable information.

Table 3.1. Service characteristics and properties

C.1:: Mandatory if a device has more than one instance of Battery Service; otherwise optional.
C.2:: Optional if the Battery Level Status characteristic is exposed; otherwise excluded.
C.3:: Optional if the Battery Health Status characteristic is exposed; otherwise excluded.

Security permissions of None mean that the Battery Service does not impose any specific security requirements; however, a higher level profile can specify stronger requirements.

Properties not listed as Mandatory or Optional are excluded for this version of the Battery Service.

Most characteristics have optional fields. The following requirements apply to the usage of fields:

A server is said to support the field if it is capable of setting the field to a value conformant with the specification.
All fields that have an associated flag bit are optional to support.
At least one field shall be supported for any exposed characteristic.
Transmission of any given field that has an associated flag bit is optional for the server.
When a characteristic is read, notified, or indicated, all supported fields that have a value different from what was last transmitted during the current connection shall be included.

Note:: Later revisions of this specification can append additional optional fields to any characteristic with a Flags field.

3.1. Battery Level

This characteristic is used to describe the level of the battery represented by this instance of the Battery Service.

3.1.1. Characteristic behavior

When read, the Battery Level characteristic returns the current battery level.

The value of the battery level is represented as a percentage from 0 to 100, where 0 percent represents a battery that is fully discharged, and 100 percent represents a battery that is fully charged.

If the Battery Energy Status characteristic is not exposed, then the Battery Level value should represent the linear range of its expected lifetime, where 0 percent represents the battery that is unable to power the device and 100 percent represents full capacity.

If the Battery Energy Status characteristic is exposed, then the Battery Level value shall be calculated using the following equation:

$\frac{A v a i l a b l e E n e r g y}{A v a i l a b l e B a t t e r y C a p a c i t y} \cdot 100$

Where the Available Energy is the value of the Available Energy field of the Battery Energy Status characteristic, and Available Battery Capacity is the value of the Available Battery Capacity field of the Battery Energy Status characteristic (see Section 3.4).

If the battery is not present, then the value of the Battery Level characteristic should be set to zero.

Upon reconnection with a bonded GATT Client, if the Battery Level characteristic is configured for notifications and the value of the Battery Level characteristic has changed while the device was disconnected, then the Battery Level characteristic shall be notified.

If the Battery Level characteristic is configured for notifications and the Battery Level characteristic value changes while in a connection, then the characteristic shall be notified.

3.1.2. Characteristic descriptors

3.1.2.1. Characteristic Presentation Format descriptor

When a device has more than one instance of the Battery Service, each Battery Level characteristic shall include a Characteristic Presentation Format descriptor (Volume 3, Part G, Section 3.3.3.5 in [1]) that has the Name Space field set to ”Bluetooth SIG” and the Description field set to a valid value from the GATT Namespace Descriptors [4] and that is unique among all instances of the Battery Service exposed by the GATT Server.

If the service that instantiates the Battery Level characteristic represents the battery status for the device, the Description field should be set to “main”.

3.2. Battery Level Status

This characteristic may be used to describe the battery level and power state of the battery represented by this instance of the Battery Service. Fields included in the characteristic value are a Flags field, a Power State field, and, depending upon the contents of the Flags field, one or more optional fields defined in [3].

3.2.1. Characteristic behavior

When read, the Battery Level Status characteristic returns summary information related to the battery status.

While the Battery Level Status characteristic is configured for indication or notification, the following requirements apply:

The characteristic may be indicated or notified if the value of the Battery Level field changed by at least 1 percent of the expected range since the last transmission of this field in this connection.
The characteristic shall be indicated or notified if the value of the Power State field or the value of the Service Required bit of the Additional Status field changed since the last transmission of these fields in this connection.
The characteristic may be indicated or notified upon reconnection with a bonded Client.

Note: Later revisions of this specification can append additional optional fields to any characteristic with a Flags field.
The characteristic shall also be notified or indicated if the Battery Level field is supported, and the Battery Level characteristic is notified.
The characteristic shall not be indicated or notified under any other condition.

When the Battery Level Status characteristic is configured for broadcast, the advertising interval recommendations given for Peripheral devices in Volume 3, Part C, Section 9.3.11.2 in [1] should be used.

When the Battery Level Status characteristic is configured for broadcast, a <Service Data> AD Type must be used and the additional service data (after the Service UUID) must be the characteristic's value as mandated in Volume 3, Part G, Section 2.7 in [1]; see also Part A, Section 1.11 in the Bluetooth Core Specification Supplement [5].

If a device needs to broadcast more than one instance of the Battery Level Status characteristic from different instances of the Battery Service, then each characteristic value must be broadcast in a separate AD structure following the format in Volume 3, Part C, Section 11 in [1].

3.2.1.1. Flags field

The Flags field shall be included in the Battery Level Status characteristic.

The bits of this field represent the presence of optional fields.

3.2.1.2. Power State field

The Power State field shall be included in the Battery Level Status characteristic.

This field represents the battery power status including the presence of the battery, whether it is connected to an external power source, and whether it is charging or discharging.

3.2.1.2.1. Battery Present bit

If the battery is not present, then the Battery Present bit shall be set to the value No.

If the battery is present, then the Battery Present bit shall be set to the value Yes.

3.2.1.2.2. Wired External Power Source Connected bits

If the battery is not connected to a wired external power source, then the Wired External Power Source Connected bits shall be set to the value No.

If the battery is connected to a wired external power source, then the Wired External Power Source Connected bits shall be set to the value Yes.

If it is not known if the battery is connected to a wired external power source, then the Wired External Power Source Connected bits shall be set to the value Unknown.

3.2.1.2.3. Wireless External Power Source Connected bits

If the battery is not connected to a wireless external power source, then the Wireless External Power Source Connected bits shall be set to the value No.

If the battery is currently connected to a wireless external power source, then the Wireless External Power Source Connected bits shall be set to the value Yes.

If it is not known if the battery is connected to a wireless external power source, then Wireless External Power Source Connected bits shall be set to the value Unknown.

3.2.1.2.4. Battery Charge State bits

If the battery is not present or the charging state of the battery is unknown, then the Battery Charge State bits shall be set to the value Unknown.

If the battery is present and charging, the Battery Charge State bits shall be set to the value Charging.

If the battery is present and discharging through a load, the Battery Charge State bits shall be set to the value Discharging: Active.

If the battery is present and self-discharging, or discharging only because of leakage, the Battery Charge State bits shall be set to the value Discharging: Inactive. This also applies when self-discharging or leakage is being compensated (i.e., in the case of a battery that stopped charging because it is full, but the charger remained present).

3.2.1.2.5. Battery Charge Level bits

If the battery is not present or if the monitoring of low and critical battery levels is not supported, then the Battery Charge Level bits shall be set to the value Unknown.

If the battery is present and is currently at a low battery level as defined in Section 1.5.1, then the Battery Charge Level bits shall be set to the value Low.

If the battery is present and is currently at a critical battery level as defined in Section 1.5.2, then the Battery Charge Level bits shall be set to the value Critical.

If the battery is present and if the battery level is not at a low or critical battery level, then the Battery Charge Level bits shall be set to the value Good.

3.2.1.2.6. Charging Type bits

If the battery is not present or if the monitoring of charging type is not supported, then the value of the Charging Type bits shall be set to the value Unknown or Not Charging.

If the battery is present and using a constant current charging type, then the Charging Type bits shall be set to the value Constant Current.

If the battery is present and using a constant voltage charging type, then the Charging Type bits shall be set to the value Constant Voltage.

If the battery is present and using a trickle charging type, then the Charging Type bits shall be set to the value Trickle.

If the battery is present and using a float charging type, then the Charging Type bits shall be set to the value Float.

3.2.1.2.7. Charging Fault Reason bitfield

If charging malfunctions (e.g., underperforms or entirely fails to charge), then this bitfield gives the reason(s) why.

If charging malfunctions because the battery’s state prevents it from being charged properly (e.g., battery is under or over temperature), then the “Battery” bit shall be set.

If charging malfunctions because of the external power source (e.g., source not providing enough power), then the “External Power Source” bit shall be set.

If charging malfunctions because of any other issue in the device, then the “Other” bit shall be set.

3.2.1.3. Identifier field

This field is used as a service identifier and shall be included in the Battery Level Status characteristic when multiple instances of the Battery Service are present on a GATT Server and the characteristic is broadcast. This field is optional otherwise.

When the Characteristic Presentation Format descriptor of the Battery Level characteristic (see Section 3.1.2.1) is present, the value of this field shall be identical to the Description field of that descriptor. When the descriptor is not present, then this field shall have the value representing “main”.

3.2.1.4. Battery Level field

The Battery Level field may be included in the Battery Level Status characteristic if the battery is present; otherwise it shall not be included.

The value of this field shall be identical to the Battery Level characteristic (see Section 3.1).

3.2.1.5. Additional Status field

The Additional Status field may be included in the Battery Level Status characteristic. It contains additional status information such as whether or not service is required. If the battery needs servicing for any reason, then the value of the Service Required bits shall be set to the value True. Otherwise, the value of the Service Required bits shall be set to the value False or the value Unknown. The type of servicing is battery- and product-dependent, but might include replacing or reconditioning the battery.

If the battery is currently in a bad state but could recover without servicing (e.g., over or under temperature) then the value of the Battery Fault bit shall be set to the value True. Otherwise, the value of the bit shall be set to the value False or Unknown.

3.3. Estimated Service Date

This characteristic may be used to describe the estimated service or replacement date of the battery represented by this instance of the Battery Service.

3.3.1. Characteristic behavior

When read, the Estimated Service Date characteristic returns the current estimated date when the battery is likely to require service or replacement.

The estimated service date may change over time. When configured for notification or indication, then the characteristic may be notified or indicated whenever the value of the characteristic changes, but this should not be notified or indicated more than once a day; otherwise, it shall not be notified or indicated.

If the battery is not present, then the value has no meaning, and this characteristic shall not be notified or indicated.

3.4. Battery Critical Status

This characteristic aggregates state information indicating that the device may no longer function as expected due to low energy or service required.

3.4.1. Characteristic behavior

When read, the Battery Critical Status characteristic returns status bits related to potential battery malfunction.

When configured for indication, then the characteristic may be indicated whenever the value of the characteristic changes; otherwise, it shall not be indicated. If the battery is not present, then the value has no meaning and this characteristic shall not be indicated.

3.4.1.1. Battery Critical Status field

The Battery Critical Status field shall be included in the Battery Critical Status characteristic.

The value of the Critical Power State bit shall be set to True if the value of the Battery Charge Level bits is set to Critical in the Power State field of the Battery Level Status characteristic if implemented. Otherwise, the Critical Power State bit shall be set to False.

The value of the Immediate Service Required bit shall be set to True if the value of the Service Required bits is set to True in the Additional Status field of the Battery Level Status characteristic if implemented. Otherwise, the Immediate Service Required bit shall be set to False.

3.5. Battery Energy Status

This characteristic may be used to describe quantitative information of the battery (e.g., capacity in kilowatt-hour) represented by this instance of the Battery Service. Included in the characteristic value are a Flags field and, depending upon the contents of the Flags field, one or more optional fields defined in [3].

3.5.1. Characteristic behavior

When read, the Battery Energy Status characteristic returns the current energy status details of the battery.

When the Battery Energy Status characteristic is configured for indication or notification, the following requirements apply:

The characteristic may be indicated or notified if the value of the Available Energy field changed by at least 1 percent of the expected range since the last transmission of the field in this connection.
The characteristic may be indicated or notified if the value of the Available Battery Capacity field changed by at least 1 percent of the expected range since the last transmission of the field in this connection.
The characteristic shall be indicated or notified if the value of the Power State field of the Battery Level Status characteristic changed since the last transmission of the field in this connection.
The characteristic may be indicated or notified upon reconnection with a bonded Client.

Note: This option is necessary for an implementation that does not save the state per bonded GATT Client (for example, because of nonvolatile memory limitations).
The characteristic shall not be indicated or notified under any other condition.

If the battery is not present, then the Present Voltage, Available Energy, Available Battery Capacity, Charge Rate, and Available Energy at Last Change fields have no meaning and shall not be present.

3.5.1.1. Flags field

The Flags field shall be included in the Energy Status characteristic.

The bits of this field represent the presence of optional fields.

3.5.1.2. External Source Power field

The External Source Power field may be included in the Battery Energy Status characteristic.

This field represents the total power being consumed from an external power source. If this instance of Battery Service is in a Battery Aggregation Group (see Section 1.5.3), then the value of this field is an aggregate value and shall be the same across all instances within the same Aggregation Group. Otherwise, this field represents the total power being consumed for this instance of Battery Service.

If there is no external power source connected, this field shall not be present.