Capability Map

Last Updated on : 2024-06-25 03:48:03download

TuyaOS Zigbee Development Framework provides service-based capabilities in the form of APIs. This allows you to focus on application innovation without caring about the underlying logic.

The following diagram shows the framework of capabilities.

Capability Map

Features

Device build

Capability	Description
Device types	Support development of Zigbee router devices (ZRDs) and Zigbee end devices (ZEDs): ZRDs: mains-powered devices with the relay capability ZEDs: battery-powered lower-power devices without the relay capability
Property build	Build endpoints, clusters, and attributes supported by Zigbee devices based on Zigbee specifications. Custom clusters and attributes are supported.
Device information	Customize device information, such as the device ID, manufacturer name, model ID, and firmware version.

Network management

Capability	Description
Generic pairing	Set power-on behavior parameters or call APIs to get a device ready for pairing and add it to a Zigbee network. To start generic pairing, users can reset a device, for example, by powering on, or perform a specified action that makes the device ready for pairing.
Pairing with QR code	Use the app to scan the QR code on the device. Then, the gateway is notified to enable pairing and scan for Zigbee sub-devices. This pairing capability does not require special operations on Zigbee sub-devices.
Touchlink	A pairing capability without the need for any gateway. For example, a lighting remote control can be paired with a light in this mode. Touchlink works on two devices that are physically close to each other. During pairing or after they are paired, no gateways or apps are required.
Local reset	Restore a device to the status prior to pairing. Users can also choose whether to clear data, for example, respecting groups, scenes, and device status.
Network leave requested by the gateway	Restore a device to the status prior to pairing after the gateway sends a leave command to remove the device from the network.
Installation code	A random value preconfigured on a device and used to join the device to a Zigbee network. You can choose whether to use the installation code during pairing. An installation code is 16 bytes in length and unique to each device. TuyaOS supports the following ways of pairing Zigbee devices: Use a global link key only Use an installation code only Use both a global link key and an installation code
Auto recovery	This capability can prevent a device from leaving a network by unintended operations. When a Zigbee device gets ready for the pairing mode after local reset, if pairing timeout or device restart occurs, the device can automatically restore to the previous networking status. All data such as groups and scenes will be retained after restoration.

Data transfer

Capability	Description
Report attribute values	Zigbee devices proactively report attribute values to a gateway to sync device status. For example, when a light switches between the on and off states, it reports the `on` or `off` value of the `onoff` attribute.
Send commands	Send commands to another device on a Zigbee network. For example, a lighting remote control sends the `on` or `off` command to a light.
Receive commands	Receive commands from another device on a Zigbee network. For example, a light receives the `on` or `off` command from a gateway.
Read and write attribute values	Generally, a gateway can query or configure an attribute value of a Zigbee sub-device. For example, a gateway can query the `onoff` attribute value of a light to sync the on/off status with the light.
Send data point (DP) data of raw type	If a DP defined on the Tuya Developer Platform cannot be mapped with a standard attribute or command of Zigbee 3.0, private Zigbee commands defined by Tuya can be used to send raw DP data. This capability applies to commands except standard ones of Zigbee 3.0.

Device relationship

Capability	Description
Group	Group control allows users to control multiple devices in a group with just one command, instead of sending this command respectively to each device. This feature minimizes the number of over-the-air packets. Devices in the same group can keep their behaviors synced with each other. Multiple Zigbee sub-devices can be added to the same group. Each Zigbee sub-device can be added to multiple groups.
Scene	Each scene is a combination of states supported by a device. This group of states is stored as a snapshot on the device and assigned a scene ID for indexing. Then, users can send a command to the device anytime to invoke the scene and restore the specified status. This can minimize the number of control commands. For example, add a scene to a light, including details such as on/off, brightness, and color temperature. When this scene is invoked, the pre-defined states related to on/off, brightness, color temperature, and more are restored on the light.
Finding & binding	Enable direct control between Zigbee devices in a way like a subscription to a command. This process makes both devices bound with each other. Thus, one of the devices can directly send a command to the other, even when the gateway is powered off.

OTA update

Capability	Description
Full over-the-air (OTA) update	In this OTA update mode, each OTA package contains the full firmware. The whole OTA update process including firmware transmission takes about 10 to 15 minutes, depending on the size of the OTA firmware. This is the standard OTA update mode supported by Zigbee specifications.
Incremental OTA update	Tuya’s proprietary incremental OTA update mode, designed for Zigbee devices. In this OTA update mode, each OTA package contains the incremental firmware generated based on dedicated incremental computing. If the OTA firmware has little difference from the firmware running on the target device, the incremental OTA package is very small and thus takes a short time for transmission. The whole OTA update process can be finished within one minute. The less difference between the new firmware and existing firmware results in a more efficient update process.
Bulk OTA updates	For a group with multiple identical devices, updating these devices via OTA one by one can be time-consuming. To fix this problem, bulk OTA updates are recommended. In this mode, the identical devices in a group are updated in bulk to shorten the whole update process. A larger number of group devices to be updated in bulk results in a more efficient update process. Incremental OTA updates and bulk OTA updates can work at the same time. Bulk OTA updates are designed independently by Tuya.

Generic services

Capability	Description
Time service	Zigbee sub-devices request time from a gateway and get the time including the year, month, day, hour, minute, and second.
Device heartbeat	ZRDs and ZEDs can have device heartbeat enabled to indicate their online status in the cloud. TuyaOS makes devices proactively report their device version or battery level to maintain the heartbeat connection. Tuya-enabled gateways regularly query the attributes of ZRDs to check whether they stay online. Therefore, ZRDs do not need to proactively report device status.
Exception log	Keep logs of exceptions and special operations, such as restart and local reset for devices. These logs contain the time when the exceptions or special operations have occurred. After power on or successful pairing, devices will report these logs to the respective gateways for further analytics of historical behaviors. Devices will delete the exception logs that are successfully reported.
Production test	A production test is designed to identify possible defects that devices might have before they leave the factory, for example, loose solder joints and poor signal reception. This helps prevent defective products from entering the market. TuyaOS supports the following ways of starting a production test: Over UART in the PCBA stage. By sending beacon signals in the end product stage. Through a gateway. This is not recommended. A production test must work with dedicated tools, such as the host, dongles, and gateways. A specific production test determines the types of tools required.

Basic tools

Capability	Description
Data storage	The application layer is provided with 8 KB of user flash memory to store data.
Software timer	Provide a software timer for you to configure scheduled tasks.
Log printing	Provide the serial log service that you can enable during development to support device debugging.
ECC signature	A signature carried by firmware after compiling based on Tuya’s development framework. You must purchase a license from Tuya before your firmware development for mass production.
JSON	The development framework has a built-in cJSON parser to be used in a production test.

Hardware driver abstraction

Capability	Description
GPIO	The GPIO driver that allows you to set a GPIO to output high or low and check the current state of a GPIO.
UART	The UART driver that allows you to set the baud rate for a UART and control a UART to send custom data.
PWM	The PWM driver that allows you to set the frequency and duty cycle of a PWM and restore a PWM to the initial state.
ADC	The ADC driver that allows you to read the value or voltage of an ADC channel and change the resolution of an ADC.
Flash	The flash driver that provides on-chip flash memory with secure interfaces for erasing, reading, and writing.
RTC	The RTC driver that allows you to set or get the RTC of a device and initialize or reset the RTC module.
Watchdog	The watchdog driver that allows you to enable or disable the watchdog and feeding features.

Support and help

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

Prev DocZigbee Sub-Device Development Framework

Next DocDevice Build