English
English
简体中文
Contact Us
Register
Log In
Language
English
English
简体中文
Contact Us
Log In
Register
Go to main website
App Develop

App Development Platform

App development platform provides multiple development methods such as no-code or IoT App SDK development to maximize the monetization of IoT apps.
layoutIndex

BLE SDK FAQ

Last Updated on : 2021-09-08 03:52:37download

This topic was no longer updated as of August 24, 2021. If you want to see the updated content, please refer to Bluetooth Device Access of TuyaOS.

How to report data point (DP) data?

Call the function tuya_ble_dp_data_report() to report DP data. For the DP data format and other APIs in the BLE SDK, see BLE SDK Guide.

  • The Tuya IoT Platform manages data through DPs. The data generated by any device must be abstracted into DPs. A complete DP data consists of the following four parts.

    • Dp_id: The dp_id serial number registered on the Tuya IoT platform. It has one byte.

    • Dp_type: DP type. It has one byte.

      #define DT_BOOL 1 // Boolean type 
      #define DT_VALUE 2 // Numeric type, whose range is specified during registration on the Tuya IoT Platform 
      #define DT_STRING 3 // String type 
      #define DT_ENUM 4 // Enumeration type 
      #define DT_BITMAP 5 // Bit mapping type
      
    • Dp_len: It can be one byte or two bytes. Currently, Bluetooth only supports one byte, and a single DP data can be up to 255 bytes.

    • Dp_data: data, with dp_len bytes.

    For more information, see Custom Functions.

  • The data pointed to by the parameter p_data of the DP reporting function must be assembled and reported in the following format:

    DP 1 data DP n data
    1 2 3 4 n n+1 n+2 n+3
    Dp_id Dp_type Dp_len Dp_data Dp_id Dp_type Dp_len Dp_data
  • When this function is called, the maximum length of the parameter len is TUYA_BLE_REPORT_MAX_DP_DATA_LEN, which is currently 255+3.

How to write the authorization code obtained on the platform to the firmware?

Example of writing the test authorization code (located in tuya_ble_app_demo.c):

static const char auth_key_test[] = "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy";
static const char device_id_test[] = "zzzzzzzzzzzzzzzz";

Can I change the PID in the demo? Where to change?

You can change the PID of Tuya BLE SDK Demo Project in the tuya_ble_app_demo.h header file.

#define APP_PRODUCT_ID          "YourProductId"

For more information, see BLE SDK Demo Overview.

Do I need to write the MAC in the authorization code?

Yes. Although the custom MAC address can also work at present, the registered device will be managed based on the MAC address in the subsequent BLE device access specification.

What is the h_id in the demo code? Do I need to change it?

h_id is used by SDK internal device management. You do not need to change h_id.

What is the authorization process through Tuya host?

  • Get the Tuya technical ticket and the host authorization token from the PM, and install the host production test tool.
  • Connect the device and the host through USB to UART converter.
  • Click the host to run and write the authorization information.
  • The firmware version and name used for authorization must be consistent with those bound to the technical ticket. Otherwise, it cannot pass the verification on the host.

For more information, see Production Test Tools.

Where can I receive the sent DP?

Receive and process DP data at the CALL BACK EVENT with the ID of TUYA_BLE_CB_EVT_DP_WRITE. For more information, see the BLE SDK Demo Overview.

For example, you can view the DP of the nRF52832 chip in the source file tuya_ble_app_demo.c of the Demo Project.

static void tuya_cb_handler(tuya_ble_cb_evt_param_t* event)
{
	int16_t result = 0;
	switch (event->evt)
	{
	case TUYA_BLE_CB_EVT_CONNECTE_STATUS:
		TUYA_BLE_LOG_INFO("received tuya ble conncet status update event,current connect status = %d",event->connect_status);
		break;
	case TUYA_BLE_CB_EVT_DP_WRITE:
		dp_data_len = event->dp_write_data.data_len;
		memset(dp_data_array,0,sizeof(dp_data_array));
		memcpy(dp_data_array,event->dp_write_data.p_data,dp_data_len);		
		TUYA_BLE_LOG_HEXDUMP_DEBUG("received dp write data :",dp_data_array,dp_data_len);
		tuya_ble_dp_data_report(dp_data_array,dp_data_len);
		//custom_evt_1_send_test(dp_data_len);
		break;
	case TUYA_BLE_CB_EVT_DP_DATA_REPORT_RESPONSE:
		TUYA_BLE_LOG_INFO("received dp data report response result code =%d",event->dp_response_data.status);
		break;
	case TUYA_BLE_CB_EVT_DP_DATA_WTTH_TIME_REPORT_RESPONSE:
		TUYA_BLE_LOG_INFO("received dp data report response result code =%d",event->dp_response_data.status);
		break;
	case TUYA_BLE_CB_EVT_UNBOUND:
		
		TUYA_BLE_LOG_INFO("received unbound req");

		break;
	case TUYA_BLE_CB_EVT_ANOMALY_UNBOUND:
		
		TUYA_BLE_LOG_INFO("received anomaly unbound req");

		break;
	case TUYA_BLE_CB_EVT_DEVICE_RESET:
		
		TUYA_BLE_LOG_INFO("received device reset req");

		break;
	case TUYA_BLE_CB_EVT_DP_QUERY:
		TUYA_BLE_LOG_INFO("received TUYA_BLE_CB_EVT_DP_QUERY event");
		tuya_ble_dp_data_report(dp_data_array,dp_data_len);
		break;
	case TUYA_BLE_CB_EVT_OTA_DATA:
		tuya_ota_proc(event->ota_data.type,event->ota_data.p_data,event->ota_data.data_len);
		break;
	case TUYA_BLE_CB_EVT_NETWORK_INFO:
		TUYA_BLE_LOG_INFO("received net info : %s",event->network_data.p_data);
		tuya_ble_net_config_response(result);
		break;
	case TUYA_BLE_CB_EVT_WIFI_SSID:

		break;
	case TUYA_BLE_CB_EVT_TIME_STAMP:
		TUYA_BLE_LOG_INFO("received unix timestamp : %s ,time_zone : %d",event->timestamp_data.timestamp_string,event->timestamp_data.time_zone);
		break;
	case TUYA_BLE_CB_EVT_TIME_NORMAL:

		break;
	case TUYA_BLE_CB_EVT_DATA_PASSTHROUGH:
		TUYA_BLE_LOG_HEXDUMP_DEBUG("received ble passthrough data :",event->ble_passthrough_data.p_data,event->ble_passthrough_data.data_len);
		tuya_ble_data_passthrough(event->ble_passthrough_data.p_data,event->ble_passthrough_data.data_len);
		break;
	default:
		TUYA_BLE_LOG_WARNING("app_tuya_cb_queue msg: unknown event type 0x%04x",event->evt);
		break;
	}
}

Are there any specifications for modification of parameters such as broadcast interval and connection interval?

Tuya BLE SDK does not include the setting of the broadcast interval and connection interval. Your application must customize the broadcast and connection parameters according to product functions and performance requirements.

However, the iOS has restrictions on connection parameters. If it does not meet the iOS specifications, the device will be rejected when updating the connection parameters. The current connection parameters required by iOS must meet the following requirements:

  • Interval Min ≥ 15 ms (multiples of 15 ms)
  • Interval Min + 15 ms ≤ Interval Max (Interval Max == 15 ms is allowed)
  • Interval Max * (Slave Latency + 1) ≤ 2 seconds
  • Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
  • Slave Latency ≤ 30
  • 2 seconds ≤ connSupervisionTimeout ≤ 6 seconds

The broadcast interval should not exceed one second. Otherwise, it is not easy to be scanned, discovered, and connected by a mobile phone.

How to perform firmware OTA update?

For specific steps, see BLE SDK Guide and BLE SDK Demo Overview.

For Tuya BLE SDK Demo Project, the following describes the overall steps for configuring OTA updates on the Tuya IoT Platform.

  1. Modify the firmware version number in tuya_ble_app_demo.h. For example, change it from 1.0 to 1.1.

    // Firmware version 
    #define TY_APP_VER_NUM       0x0101
    #define TY_APP_VER_STR      "1.1"  
    
  2. Compile the firmware and generate an OTA file. It might be a .bin file or .hex file depending on the chip platforms.

  3. On the page of Smart Products on the Tuya IoT Platform, find the Bluetooth product you developed, and configure the firmware OTA updates on the page of Product Configuration > Firmware Updates Center.

    Note: If it is Tuya firmware or OEM PID, the new firmware version is not supported, so the firmware version for OTA update cannot be customized. But when the firmware updates are available, the update package will be pushed to you for your verification.

    BLE SDK FAQ

  4. Click Settings to enter the configuration page. Click Add Firmware Versions in the top right corner, and upload the new firmware file according to prompts.

  5. On the page of Firmware Version Management, click Common white list, and then add whitelisted devices for the update test.

What is the transmission speed of the BLE SDK?

The transmission speed of the BLE protocol depends on the connection interval parameter set by the product app and the processing capacity of the Bluetooth chip. Currently, the GATT MTU size of Tuya BLE SDK is 20 bytes.

Take Tuya BLE SDK Demo Project with nRF52832 SoC as an example. When the GATT MTU size is 20 bytes and the connection interval is 30 ms, the OTA transmission rate is about 2 KB/s.

I have a lot of data to send. How can I improve the transmission efficiency?

You can send as many DP data as possible for each report command. Currently, the DP reporting function can send up to 258 bytes of data including the DP data header.

The data pointed to by the parameter p_data of the DP reporting function must be assembled and reported in the following format:

DP 1 data DP n data
1 2 3 4 n n+1 n+2 n+3
Dp_id Dp_type Dp_len Dp_data Dp_id Dp_type Dp_len Dp_data

When this function is called, the maximum length of the parameter len is TUYA_BLE_REPORT_MAX_DP_DATA_LEN, which is currently 255+3.

Do I need to write the bootloader?

  • If the Bluetooth chip model you choose has a Tuya BLE SDK demo, you can develop based on this Demo Project.

  • If not, you can migrate Tuya BLE SDK and write bootloader and firmware OTA code. To compile the bootloader, you must consider firmware verification to prevent illegal firmware writing and running.

How much resources will the BLE SDK consume?

Resource consumption depends on Tuya BLE SDKs. The default configuration consumes about 4 KB RAM and 14 KB ROM (excluding port and application files).

Why can’t the device be found by the Tuya Smart app?

Check whether the broadcast data is correct. If this product is developed through self-migration , you need to check the setting of broadcast port, PID, and authorization information.

  • adv data

    Broadcast data segment Type Description
    Device LE physical connection identification 0x01 Length: 0x02
    Type: 0x01
    Data: 0x06
    Service UUID 0x02 Length: 0x03
    Type: 0x02
    Data: 0xA201
    Service data 0x16 Length: 0x0C or 0x14
    Type: 0x16
    Data: 0x01 or 0xA2, type (0-pid,1-product_key) PID or product_key (8 or 16 bytes)

    Example (8-byte PID): 02 01 05 03 02 01 A2 0C 16 01 A2 00 00 00 00 00 00 00 00 00

  • Scan response data

    Broadcast data segment Type Description
    Complete Local Name 0x09 Length: 0x03
    Type: 0x09
    Data: 0x54 or 0x59
    Custom data 0xff Length: 0x19
    Type: 0xff
    Data: company ID: 0x07D0
    Flag: 0x00
    Protocol version: 0x03
    Encryption method: 0x00
    Communication capability: 0x0000
    Reserved field: 0x00
    ID field: 16 or 6 bytes

    Example (unbound): 03 09 54 59 19 FF D0 07 00 0 300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

How does Tuya BLE SDK affect power consumption?

If the SDK is migrated correctly according to BLE SDK Guide, Tuya BLE SDK will not affect the power consumption architecture of the Bluetooth chip.

The factors that affect power consumption are:

  • Whether the low power mode (sleep) is enabled.
  • Whether peripherals are turned off in the low power mode.
  • Bluetooth broadcast interval
  • Bluetooth connection interval