Last Updated on : 2024-11-20 08:51:47download
Check whether the mobile phone and the gateway are in the same local area network (LAN). You can ping
the IP address of the mobile phone to verify in the gateway system.
These are ports 8883, 6667, 6668, 6669, 443, 6681, 6608, and 6682.
Yes.
Follow the steps below to troubleshoot:
get_ip
interface and whether the IP field passed to the SDK is correct.If the check result is consistent with the DP definition of the product, an error is still reported, the device shall be paired again to solve the problem.
During pairing, the device will get its DP information (schema) from the cloud and save it in the local DB file. After the DP definition is updated during debugging, the device shall be paired again to synchronize the information in the local DB file.
The reported value is not within the defined range, and the error is reported as follows:
[04-17 08:58:48 TUYA Err][smart_frame.c:2267] value check fail 3 25 50 350
The above log indicates that the DP value verification failed, the reported value is 25, and the value range defined by the DP is 50 to 350.
As shown in the figure below, log in to the Tuya Developer Platform to check the value range defined by the corresponding DP.
The reported DP type is inconsistent with the definition:
[04-17 09:08:48 TUYA Err][smart_frame.c:251] dparr[0] type not match.2 1
The above log shows that the reported DP type is 2, and the actually defined DP type value is 1.
DP type value is defined as follows.
// dp schema type
typedef BYTE_T DP_PROP_TP_E;
#define PROP_BOOL 0
#define PROP_VALUE 1
#define PROP_STR 2
#define PROP_ENUM 3
#define PROP_BITMAP 4
It is prompted that the DP is not found:
[04-17 08:48:30 TUYA Err][smart_frame.c:246] devid:xxx dparr[0]:4 not find, continue.
The above log indicates that the DP with DPID 4 does not exist. Log in to the Tuya Developer Platform to check whether this DP is defined.
When the mobile phone and the device are in the same LAN, the DP command of the mobile phone is first sent through the LAN.
For device log query operation instructions, see Log query: use behavior query on a single-device basis.
The interface prototype is tuya_iot_gw_bind_dev(tp, uddd, id, pk, ver)
.
tp
: the sub-device type. The optional parameters are as follows.
#define DEV_ZB_SNGL 2 // Zigbee single device
#define DEV_INFRARED_SNGL 3 // Infrared sub-device
#define DEV_OTHER_SNGL 4 // Other single device, and the self-developed device can use this type
#define DEV_BLE_SNGL 5 // Bluetooth Low Energy (LE) device
uddd
: 32-bit unsigned integer. You can define this parameter. It is used to distinguish devices of the same type, facilitating determination and processing by the application layer.
id
: The device ID information of the sub-device. Each device under the gateway must be unique. Generally, the MAC address of the device or the ID of the chip can be used, and the maximum length is 25 characters.
pk
: the PID of the sub-device, generated after the product is created on the Tuya Developer Platform.
ver
: The firmware version of the sub-device, in the format XX.XX.XX (0 ≤ X ≤ 9)
. It is used for version management of the OTA update of the sub-device.
No. Only one update thread can be in progress at the same time, and the other one can be run after the completion of the previous one.
Log in to the Tuya Developer Platform and submit a ticket. Please describe your problem in the following format, helping us respond quickly.
Is this page helpful?
YesFeedbackIs this page helpful?
YesFeedback