Bluetooth Mesh Device Development Kit

Last Updated on : 2024-06-25 09:35:08download

Bluetooth Mesh Device Development Kit is built on top of TuyaOS for Bluetooth mesh device development. This kit includes a host of features and standard APIs to help you develop easily, including device pairing, upstream and downstream communication, production testing, authorization, and OTA updates.

You do not need to take care of feature implementation for different chip platforms. Just working on the standard APIs, you can connect your products to the Tuya Developer Platform and make them IoT-enabled.

Capability map

Device management

Capability	Description
Initialization	Understanding the initialization process can help you get through Bluetooth mesh software development. Initialization is a process where after a device enters the `main` function after power on, it calls a range of APIs to initialize the hardware environment, TuyaOS software, and applications. During the application initialization, take care of the sequence of API calls. Business logic is generally after the Bluetooth stacks. The dependencies for initialization vary depending on the modules.
Authorization	Only authorized Bluetooth devices can connect to the Tuya Developer Platform. Authorization is the process of writing the device identification information for authentication and pairing to the non-volatile memory (typically the flash memory) on the device. You have two options for adding authorization information: you can either write it directly into the code using the API, or download it to the device via Tuya’s host. Writing it into the code is intended for debugging, while downloading it is meant for mass production.
Production testing	Testing in the production process helps you identify any Bluetooth hardware issues for better yield. There are PCBA testing and end product testing. In PCBA testing, communication with Bluetooth devices is established through the serial port. In end product testing, communication is over Bluetooth to test the device’s radio and peripheral functionality.

Communication

Capability	Description
Communication modes	Bluetooth mesh devices are categorized into two types based on their supported communication modes. Bluetooth mesh devices that support communication through advertising as well as GATT connection via Mesh Proxy service. They can be controlled through Bluetooth connection with mobile phones or through gateway advertising. Bluetooth mesh devices that only support communication through advertising. They cannot communicate with mobile phones.
Communication policy	If a device is bound with a gateway and connected to a mobile phone over Bluetooth, gateway advertising takes precedence when the device is controlled with a mobile app. Device control through Bluetooth connection to a mobile phone is used only when a device is not bound with a gateway or the gateway is offline.
Binding with gateway	A device can be bound with one gateway only. If a device is paired through a gateway, it is automatically bound with that gateway. If a device is paired through Bluetooth, the user needs to manually bind the device with a gateway on the gateway’s app panel. When multiple gateways are on the same network, the user can unbind a device from a gateway and bind it with a desired one.
Proxy capability	A node with the proxy capability enabled is called a proxy node. A proxy node acts as an intermediary to allow a non-mesh-supported Bluetooth LE device to interact with a Bluetooth mesh network. This allows a mobile phone to monitor and control a mesh network via a proxy node through GATT data transmission.
Relay capability	A node with the relay capability enabled is called a relay node. A relay node can retransmit messages that are broadcast by other nodes to extend the reach of these messages across the entire Bluetooth mesh network.

Pairing and reset

Capability	Description
Pairing modes	A device can be paired through GATT communication with a mobile phone or through advertising by a gateway. There are two approaches to pairing. Standard Bluetooth mesh provisioning: The fixed and secure provisioning procedure defined in the Bluetooth mesh specification. Tuya’s proprietary fast provisioning: The provisioning procedure using Tuya-defined custom GATT service and vendor model. Fast provisioning is a more efficient alternative to standard Bluetooth mesh provisioning. It allows for bulk provisioning at a faster speed and with a higher success rate.
Reset	A reset can restore a device to the settings that the device had before it was paired. Device reset can be triggered by hardware operation or mobile app operation.
Device network recovery	After a device is reset locally, calling the recovery interface can restore to the latest network configuration. This feature is particularly useful in cases where the device was accidentally reset locally. If the device remains unpaired after a certain time or is powered on again, its network configuration will be automatically restored to the latest version.

Device control

Capability	Description
Data point (DP) model	DP models are used for device control on the Tuya Developer Platform. The gateway and mobile app can convert the DP model data to the Bluetooth mesh model and opcodes.
Bluetooth SIG models	Models defined by the Bluetooth Special Interest Group (SIG) in the Bluetooth Mesh Model Specification are known as Bluetooth SIG models. Tuya uses the Generic OnOff Model and lighting models for lighting and electrical products.
Vendor models	Tuya-defined vendor models transmit information about raw-type DPs. Vendor model opcodes are used to transmit data for standard DPs that cannot be converted to Bluetooth SIG model opcodes. For more information, see the SDK documentation.
Tap-to-Run	Tap-to-Run is a sequence of control commands that can be created and triggered on the mobile app. When activated, these commands are sent in a specified order. Sending multiple commands continuously in Bluetooth mesh networks is not recommended as it can cause network storms and concurrency conflicts, leading to packet loss and latency.
Cloud linkage and gateway linkage	Cloud linkage: The linkage rules are stored on the cloud. When they are triggered, the preset actions will be run. Gateway linkage: The linkage rules are stored on the gateway. The preset actions can be run as expected even when the gateway loses internet access.

Additional capabilities

Capability	Description
Request for time data	After connected to a mobile phone or bound with a gateway, a Bluetooth mesh device can request the current time and location coordinates (longitude and latitude) from the cloud.
Request for daylight saving time (DST)	After connected to a mobile phone or bound with a gateway, a Bluetooth mesh device can request DST information from the cloud.
Local control for remote controls	A remote control can connect to and operate Bluetooth mesh devices directly, without the need for a mobile app or gateway.
Locally distributed linkage	Local linkage allows rule storage on the device. It can run without the cloud and gateway. A device might act as a condition or action. The condition device sends its status to a specified address on the Bluetooth mesh network. The action device subscribing to the same address can receive the status data from the condition device and run the preset actions.
Reliable data reporting	The channel for reliable data reporting helps to ensure the successful delivery of data to the gateway. You can choose a suitable reporting method as required.

Device driver

Capability	Description
GPIO	GPIO driver, with debugging routines. With a host, you can set a GPIO to output high or low and check the current state of a GPIO.
UART	UART driver, with debugging routines. With a host, you can set the baud rate for a UART and control a UART to send custom data.
PWM	PWM driver, with debugging routines. With a host, you can set the frequency and duty cycle of a PWM and restore a PWM to the initial state.
ADC	ADC driver, with debugging routines. With a host, you can read the value or voltage of an ADC channel and change the resolution of an ADC.
SPI	SPI driver, with debugging routines. With a host, you can control the SDI and SDO of an SPI module to receive and send custom data and change the transfer rate of an SPI module.
I2C	I2C driver, with debugging routines. With a host, you can control an I2C module to turn on an OLED screen and display custom data.
RTC	RTC driver, with debugging routines. With a host, you can set or get the RTC of a device and start or stop the RTC module.
Watchdog	Watchdog driver, with debugging routines. With a host, you can start or stop the watchdog, enable or disable automatic feeding, and test manual feeding.

Power consumption

Capability	Description
Standard power	Bluetooth mesh devices use advertising and scanning to send and receive packets. A typical Bluetooth mesh node should always be in scanning mode to avoid missing packets, which requires continuous energy consumption. The power consumption varies depending on chip platforms, generally ranging from 5 mA to 8 mA. The transmitter power has minimal impact on overall power consumption. Instead, it is the RF and MCU operation during scanning that consumes significant amounts of power. The power consumption of typical Bluetooth mesh devices is mainly affected by the RF process and MCU clock rate.
Ultra-low power	Ultra-low power devices are in sleep mode most of the time and typically woken up by timers. They can also be woken up by external interrupts, during which they remain awake briefly to collect and report data before returning to sleep mode. Generally, power consumption is below 10 μA in sleep mode. During the pairing process, the device must stay awake for a specific duration.
Periodic sleep and wake-up	Periodic sleep and wake-up can limit the device’s power consumption to less than 1 mA when it is idle. During the wake-up period, the device receives messages that were sent while it was asleep. It then stays awake for a certain time period (typically 30 seconds) to receive any additional data. This low-power strategy applies to devices with a large battery pack or a solar charger.
Low-power for smart switches (no neutral wire required)	The device alternates between sleep and wake-up cycles, but cannot remain awake for long periods. To ensure successful message delivery when the device wakes up, the sender should try multiple retransmission. This strategy is designed for smart switches that do not require a neutral wire.

OTA update

Capability	Description
OTA Bluetooth firmware updates	Send an OTA update to a Bluetooth device through the Smart Life app or the gateway. Resumable transfer, data integrity check, and exception processing are supported.
Bulk OTA updates	Multiple devices can be updated simultaneously through the gateway. The drawback is the time-consuming and uncontrollable update process. This feature is used to update devices on a large scale during idle periods or at night.

Support and help

If you have any problems with TuyaOS development, you can post your questions in the Tuya Developer Forum.

Prev DocBluetooth

Next DocBluetooth Beacon Mesh