Business Lock Implementation Process

Pairing

Scenarios

For first-time pairing or pairing again after a device is removed, you do not need to manually set the data points (DPs).

Implementation process

• To add a sub-device, you need to pair the gateway with the mobile app, such as Tuya Smart app or Smart Life app. Then, the Zigbee locks can be added to the gateway as sub-devices to connect to the cloud. For more information, see How to add Zigbee devices to the mobile app.

• After successful pairing, power on the module to transmit data and wait for the server connection result returned from the module.

• The data transmission is as follows.

  
  • 0x01: Query product information.
  • 0x02: Query network status.
  • 0x03: Configure the Zigbee module.

Lock information changes

Scenarios

Battery level, door sensor, anti-lock state, and deadbolt state are the lock information. When lock information changes, the MCU must report it to the Zigbee module.

Data points (DP)

• DP 26: Residual Electricity
• DP 27: Door Sensor Status Report
• DP 28: Anti Lock State
• DP 29: Deadbolt State
• DP 30: Language Switch
• DP 31: Doorbell Volume
• DP 32: Get Lock Status

Description

• Residual electricity: Display remaining battery level percentage, ranging from 0 to 100.

• Door sensor status report, anti lock state, deadbolt state, and language switch are enum data types.

• Doorbell volume is enum data types, including mute, low, normal, and high.

• The DP 32 get lock status is used to return all the lock information or individual state to the query sent from the mobile app.

• The MCU reports the battery level in the following scenarios:

  • First-time pairing or pairing again.
  • Device reboot after specific operations, for example, after the battery is replaced.
  • The battery level is changed.
  • Regular reporting, such as reporting once every 10 days.
    0x05 is used for the MCU to proactively report lock status.

View unlocking records

Scenarios

View the unlocking record on the app.

Data points (DP)

• DP 13: Unlock by Temporary Password
• DP 14: Unlock by Admin Password
• DP 15: Unlock by Sub-admin Password
• DP 16: Unlock by Dynamic Password
• DP 17: Unlock by Offline Password
• DP 18: Clear all Offline Password Report
• DP 19: Unlock by Card
• DP 20: Unlock by Fingerprint
• DP 21: Open the Door from Inside
• DP 22: Unlock by Unknown Method
• DP 43: Unlock by Identity Card

Description

• Unlock by temporary password, card, fingerprint, and identity card: The DP values are used to distinguish members. Valid values: 0 to 999. The unlocking records are displayed on the app and show member information in each entry.

• Unlock by dynamic password: The DP values do not have a special meaning. Valid values: 0 to 999. The unlocking records are displayed on the app and do not show member information in each entry.

• Unlock by admin password and sub-admin password: The admin role (ID 1) and sub-admin role (ID 2) can only be held by one user.

• Unlocking event: The MCU must report an unlocking event as long as the door is opened.

Implementation process

• Implementation logic

  When the door is opened, the DP of the used unlocking method is reported. If the door is disconnected from the network, the time when an unlocking event occurs must be recorded. Therefore, we recommend that the records of actual status are reported. In this case, the module stores the records that failed to be reported and reports them along with other latest unlocking records after network recovery. The records use the local time of the device. The following table describes the DP values.

• Implementation process

  

  0x23 is used to report status records.

Note: The serial number of a specific unlocking method is generated by the MCU. Note that the MCU-generated serial number is independent of the ID of each temporary password.

View alerts

Scenarios

If an alert is triggered, the app instantly shows the alert. Users can view the alerts on the app.

Data points (DP)

DP 23: Lock Alarm

Description

Lock alerts: The alerts cover multiple scenarios, including fingerprint attempts, password attempts, card attempts, face recognition attempts, stuck bolts, high temperature, overtime unlocked reminders, electronic lock tongue not ejected, anti-pry design, key insertion, low battery, running out of battery, and vibration alerts.

Implementation process

• Implementation logic

  After an alert is triggered, the MCU reports the specified alert DP value.

  Note: When status records are reported, the accurate local time of the device is included in the records. If the local time of the device lags behind the actual time, when the app receives an alert, the alert icon on the app does not blink. Users can tap the icon to view the alert. If the server time prevails, after the device is reconnected after network recovery, the record time does not reflect the actual event time.

• Alert:

  

  0x23 is used to report status records.

Password management

Scenarios

Manage the admin password and tenant password.

Data points (DP)

• DP 1: Admin Password Management
• DP 2: Create Temporary Password
• DP 3: Delete Temporary Password
• DP 4: Change Temporary Password
• DP 5: Disable Temporary Password
• DP 6: Enable Temporary Password
• DP 7: Delete all Temporary Password
• DP 24: Local Password Changed Report

Description

• Manage the admin password: Change the admin password. Change, reset, disable, and enable the sub-admin password.

• Create, delete, change, disable, and enable the temporary passwords used for tenants.

• Delete all temporary passwords: If a lock is reset to factory settings by the mobile app, the cloud will send a command to delete all the locally saved temporary passwords. If a lock is physically reset to its factory settings, it needs to report the DP 7 to the cloud for sync. If reporting failed, the lock must report the DP 7 again after it is connected to the cloud.

• Local password changed report: If the password assigned to the admin, sub-admin, or users is changed through hardware operation, the lock must report the DP 24 for sync.

Implementation logic

• Three roles for password management: admin, sub-admin, and user.
• Seven operations on password: create, change, delete, disable, enable, reset, and delete all.
• The role of the upper level can create, delete, disable, enable, and clear (if any) the password assigned to the role of the lower level.
• Users can only change their own passwords.
• The admin password can only be changed.
• The sub-admin password can only be changed, disabled, enabled, or reset.
• The user password can be created, changed, deleted, disabled, enabled, or cleared.
• The sub-admin password can be reset to its default.

Status description

• For temporary passwords, its status can be:
• Issuing: A temporary password takes effect but the server does not receive any messages about this password from the lock.
• Issuing a password failed: The server does not receive any messages about this password from the lock within 90s.
• Not take effect: The password has not taken effect.
• Issuing a password succeeded: The server receives a message about this password from the lock.
• Password disabled: Disable a password by using the mobile app.
• Password expired: The valid time has expired.
• Password deleted: Delete a password by using the mobile app. If a temporary password failed to be issued, a retry button will appear on the mobile app.

Implementation process

Sync password

Scenarios

Sync password information between the server and the lock.

Data points (DP)

• DP 9: Tenant Password Verification
• DP 10: Sync Tenant Password No.
• DP 11: Get Password
• DP 12: Report Password

Description

• Tenant password verification: Verify whether passwords saved in the server match these locally saved on the lock. Initiated by the mobile app: If the lock is paired again, the MCU must proactively report the DP 9 to the module. Typically, the MCU reports DP 9 every seven days.
• Sync tenant password No.: If the result of tenant password verification is false, the server will request password sync. The MCU will return the password No. and a list of checksum. Up to 20 pieces can be reported at a time.
• Get password: Get the password by password No. to sync between the lock and the server.
• Report password: The MCU proactively reports the password after sync.

Offline passwords

Scenarios

Offline temporary passwords are used when the door lock is disconnected from the internet.

Data points (DP)

DP 8: Offline Password T0 Time

Description

Offline Password T0 Time: The server sends the basic time to the lock, which is used for encrypting the offline password.

Usage description

Users can choose whether to assign the password as one time.

If so, the effective time cannot be set. The expiration time is the effective time plus 6 hours, which cannot be changed.

If the user does not assign the password as one time, the effective and expiration time can be set. The usage times of the password are not limited within the effective time.

Implementation process

0x08 is used to report offline passwords.

Dynamic password

Scenarios

The user sets a dynamic password on the app. A visitor can enter the dynamic password within the validity period of the password to unlock the door.

Data points (DP)

DP 16: Unlock by Dynamic Password

Implementation process

• Implementation logic

  • A normal password can be set as a dynamic password. If the dynamic password feature is enabled, the dynamic password field will be displayed on the control panel in the tenant’s mobile app.
  • Get a dynamic password on the app. When it is used to unlock the door, the lock will report this event. The module returns the verification result that controls the unlocking operation. Note that the timestamp in the command of reporting the dynamic password must be the Greenwich Mean Time (GMT) instead of local time. The dynamic password is valid within five minutes and shall be obtained again after timeout.

    Note: Get the dynamic password on the app. Currently, the all-in-one Wi-Fi panels do not support entering an administrator password, but it is supported on the embedded system and server.

• Implementation process

  

SMS

Scenarios

This function is used along with the temporary password function. When the user creates a temporary password on the Tuya Smart app or OEM app, a text message is sent to a specified mobile number. The text message contains the device name, password, validity period, and expiry time.

SMS is only available for services deployed in mainland China. When creating an app account, the user can select the country or region code.

Data points (DP)

DP33: Message Notification

Description

• This DP is optional. This function is a paid offer.

• After you select this DP, go to the Functional Expansion tab on the value-added services (VAS) platform and subscribe to the Door Lock SMS Notification function.

  

  It is the app functionality and no communication protocols are involved.

Restore factory defaults

Scenarios

The lock will be reset to its factory settings.

Data points (DP)

DP 25: Reset The Lock

Implementation logic

Reset a lock to its default settings by using the mobile app.

This operation will remove the lock from the app and clear all the data from the cloud. The temporary passwords and offline passwords locally saved on the lock are still available.

After a lock is paired again, the server will send DP 25. After the module receives this DP, the MCU will clear all the authorization information, reset the admin and sub-admin passwords to default values, and notify the module to delete all temporary passwords.

Reset a lock to its default settings through hardware operation.

The MCU will clear all the authorization information and notify the module to delete all temporary passwords.

After the lock is paired again, it should report the DP 25 to clear all the data from the cloud.

Production test

Scenarios

Perform production tests on the network modules on the PCB to verify the RF performance and serial communication.

Tuya provides the beacon used in testing. Contact the account manager to request it.

Set the beacon channel to channel 11. Power on the module and place the device under test (DUT) near the beacon. Send the test command and wait for the module to return the result within about 3s. The acceptance rate is about 60%.

Note: The transmission power of the beacon has been attenuated, so the distance between the beacon and DUT must be within 1m. The DUT must not be paired.

Additional information

Set alerts

To send push notifications to the app, configure Device Notification on the platform.

Network modules

• Recommended: Only TYZS5 module supports wake-up by UART.
• Module datasheet: Find the module details in the Hardware Development step of product development on the platform.
• Baud: Support 115200.
• Module debugging assistant: Download the module debugging assistant in the Hardware Development step of product development on the platform.