Integration with Video Access Control Devices (Linux)

Last Updated on : 2024-06-20 05:48:23download

This topic describes how to integrate Linux video access control devices with the Tuya Developer Platform.

Key terms

No.	Term	Description
1	cid	The unique ID of a specified access control device.
2	sn	The unique serial number of a specified data point (DP).
3	ATOP interface	The HTTPS interface provided by Tuya.
4	Send	Commands are sent from the cloud to devices through MQTT messages.
5	Report	Device messages are reported to the cloud through the ATOP interface or MQTT messages.

Architecture

Integration with Video Access Control Devices (Linux)

This topic only supports integration with access control devices that have built-in Tuya IPC SDK.

Business process

Integration with Video Access Control Devices (Linux)

List of data points

No.	Data point	Description
1	Device pairing	Devices must be paired before they can receive commands from the cloud and interact with the cloud.
2	Video call	Initiate, receive, and hang up calls.
3	Manage persons	Add, update, remove, enable, and disable persons.
4	Manage face data	Add, update, and remove face data.
5	Manage access control cards	Add, update, and remove access control cards.
6	Manage QR codes	Add, update, and remove QR codes.
7	Manage remote unlocking	Use the Smart Life app to send unlocking commands to an access control device. Then, the device unlocks a door and reports the access control record.
8	Report events	The access control device recognizes people who pass by and reports their access control records.
9	Grade face images	The server grades the captured face images. This feature is used only for check-in at hotels.
10	Dynamically refresh the QR code for persons’ access control	In addition to the access control QR code from the cloud, a dynamically refreshable access control QR code is also supported.
11	Manage access control passwords	Add, update, and remove access control passwords.

Integration process

Download Jizhi Community app

Download the Jizhi Community app in an app store to establish audio and video calls with the access control device through the app.

Integrate devices with Tuya IPC SDK

Get the demo of Tuya IPC SDK for Linux.

Get Tuya IPC SDK documents.

Device pairing and configuration

Request a private key

Request a private key from Tuya to decrypt pairing information.

Scan the QR code on the device

Request a test account from Tuya and generate a QR code.

The device scans the QR code on the construction app to pair the device. The QR code includes content in the following format:

{
    "t":"AYRfQ***",
    "a":"a1-cn***",
    "key":"1168***"
}

The device scans the QR code to get the content and requests the HTTPS interface based on the QR code content. Example:

Generate a request URL. The format of a request URL is as follows: https://%s/api.json?a=%s&v=%s&clientId=%s&lang=%s&t=%s&requestId=%s&sign= %s
Example of a full URL: https://a1-cn.wgine.com/api.json?a=tuya.device.industry.base.edge.net.qrcode.query&v =1.0&clientId=mtn9nxykycwmknutmfky&lang=zh&t=1598010014&requestId=0928d339a d654fd1874b28d245948fc3&sign=d014ed4d192f60edd2d4ffeab545919bc3527ff4b0df2 6b4176ef1c0baed10cf

Generate URL parameters.

a:apiName Default: tuya.device.industry.base.edge.net.qrcode.query
v:version    Default: 1.0
time           Example: 1598010014, the current time of Long type
lang         Default: zh
clientId     Default: mtn9nxykycwmknutm***
requestId    It is generated by UUID, such as: 0928d339ad654fd1874b28d24594****
postData    Description: Generate a JSON string based on the key and cid in the scanned QR code. The format is: {"t":1598010***,"key":"a354fffa81674d80b7d1e0696ad6****","cid":"device16411*** *"}. And then, perform MD5 encryption. The string encrypted by MD5 is: a1941a0237df3e2e2e315c8dca27c***.

sign description: Sort a, v, time, lang, clientId, requestId, and postData in ascending order, and the resulting string is: a=tuya.device.industry.base.edge.net.qrcode.query||clientId =mtn9nxykycwmknutm***||lang=zh||postData=a1941a0237df3e2e2e315c8dca27c***||requestId=0928d339ad654fd 1874b28d245948***||time=1598010014||v=1.0.
Then, encrypt the sorted data a based on the secret key wjx7ss3hww7xcpc7s4t3unxwfuw37*** through HMAC-SHA256, and generate a sign. The signing result is: d014ed4d192f60edd2d4ffeab545919bc3527ff4b0df26b4176ef1c0baed1***.

Generate HTTP Body parameters.
1. Generate a JSON string based on cid (the unique serial number of the device), key and time t in the result of scanning the QR code. The data is: {"t":1598010***,"key":"a354fffa81674d80b7d1e0696ad6****","cid": "device164114***"}.
2. Take the request URL and Body as HTTPS request parameters. The body format is: postData = {"t":1598010***,"key":"a354fffa81674d80b7d1e0696ad6****","cid":"device16411****"}.
3. Send an HTTP POST request based on the URL and Body.

Here is an example of the returned result.

{
    "result": {
        "data": "0e90f53c95772614c7a9be4b41f7130d764551a315f11d3bd04c7b50ac778f23d6e 6184f4a7e47d2fe58858c5019bc1086cb622855b7d0fad3491f0ee73bab21835bc67 ecbc04511321b0de51f63b3fc30d281c1a304244d0cefc59a976dbc830b11ef43785 204c16952edfa8eb6a7572cc8d8e49927f558f4dbd1086f3af5b33c8c998b4d84119 39bc78d2334aa633c49ba4f099cbbabc8a0de3e06f44a24c63d5ae167d985e70e19a 1bfedd44ddff1248b683c41c5b4733a8a9f201b854***",
        "key": "a354fffa81674d80b7d1e0696ad69***"
    },
    "t": 1598010614705,
    "success": true,
    "status": "ok"
}

Decrypt the data time with AES. The key is the requested private key. An example of the decrypted data is shown as follows.

{
    "authKey": "BO3CzAHnqtbwyf4d6T2F3rOlJwugp***",
    "installLocation": "Unit 1, Building 1",
    "vendor": "yufan",
    "pid": "toftl4za2qhgf***",
    "projectId": "1197119053387350***",
    "uuid": "3aaa3d3fef65f***"
}

Device pairing

The parameters required for device pairing include t, pid, uuid, and authKey. You can scan the QR code to get the value of the t parameter, which is valid for 10 minutes.

t, pid, uuid, and authKey need to be written to the device after the pairing is successful. Make sure that the above data can be obtained again after the device is restarted, powered off, or restored to factory settings, and the pairing interface can be requested again to connect the device to the cloud. The t parameter will not expire after the pairing is successful.

For more information about pairing implementation, see the documents and demo about IPC SDK development.

Bind device with community

After pairing is successful, request this ATOP interface. You only need to request this API when the pairing is successful for the first time. The request parameters are as follows:

Request parameter

Request parameter	Parameter type	Description	Required
cid	String	The ID of a specified access control device.	Yes
deviceId	String	The device ID.	Yes
uuid	String	The universally unique identifier (UUID) of the device.	Yes
projectId	String	The project ID.	Yes
productId	String	The product ID.	Yes
installLocation	String	The location where the device is installed.	Yes
vendorCode	String	The code of a specified supplier.	Yes
macAddress	String	The MAC address of a specified device.	Yes

Response parameter

Type	Description
Boolean	The returned result. Valid values: `true`: The call is successful. `false`: The call failed.

Example:

    api_name: tuya.device.industry.base.edge.device.area.bind
    api_version:1.0
    message:
        {
	"input": "{\"cid\":\"device164114***\",\"deviceId\":\"6c4363e795dcd496e6b***\",\"installLocation\":\"Unit 1, Building1\",\"productId\":\"toftl4za2qhgf***\",\"projectId\":\"1197119053387350***\",\"uuid\":\"b893fa6d54ed3***\",\"vendorCode\":\"yufan\",\"macAddress\":\"01:23:45:67:89:**\"}"
}
   result:
         {
         	"result": {true},
	         "t": 1598010614***,
	         "success": true,
	         "status": "ok"
         }

API description

Video call

Call this ATOP interface to start, answer, or hang up a video call. The request parameters are as follows:

Request parameter

Request parameter	Parameter type	Description	Required
sn	String	The serial number. This parameter is required in all modes except calling. The value must be the serial number returned in a calling session.	No
mode	String	The device mode, such as `ac_doorbell` for a doorbell.	Yes
type	String	The operation type. See the subsequent descriptions.	Yes
deviceId	String	The device ID.	Yes
targetAddress	String	The destination address. For example, `01-01-01-01-01-01` means Room 01, Floor 01, Unit 01, Building 01, Block 01, Community 01. If one level is empty, enter `00`. For example, if there is no block, the value of the block field is `00`.	Yes
extend	String	After a call is answered and then hanged up, a JSON string is returned, such as `{"beginTime":1592373736,"endTime": 1593373736}`. `beginTime`: the time when a call is answered. `endTime`: the time when a call is ended. The time type is `Long`.	No

Response parameter

Type	Description
String	The serial number.

Description of targetAddress

Example: Room 101, Unit x, Building x, xx Community.

When the device acts as a unit door:

The destination address is parsed into data in the format of 00-00-00-00-01-01. The parsed result includes six groups of digits. The value range of the first four groups does not affect the call feature of an outdoor station. The default value is 00. The last two groups can be input from the device based on practical conditions. To call Room 101, 00-00-00-00-01-01 is sent to the cloud.

The first four groups: 00-00-00-00. It does not affect the calling feature, and the default value is 00.

The last two groups: 01-01. Enter the actual value on the device.
When the device acts as a building door:

As above, the data is parsed to 00-00-00-01-01-01.

The first three groups: 00-00-00. It does not affect the calling feature, and the default value is 00.

The last three groups: 01-01-01. Enter the actual value on the device.
When the device acts as a community door:

As above, the data is parsed to 00-01-01-01-01-01.

The first group: 00. It does not affect the calling feature, and the default value is 00.

The last five groups: 01-01-01-01-01. Enter the actual value on the device.

Description of operation types

Operation type	Scene	Operation
1	The device calls the app and indoor monitor.	The device sends an event of type 1.
3	The device calls the app and indoor monitor and then hangs up. The app and indoor monitor do not operate.	The device sends an event of type 3. If the call is answered on the app, the `extend` parameter is required.
4	The device calls the app and indoor monitor. The call is not answered within the timeout period, and the device hangs up. The default calling timeout period is 30s.	The device sends an event of type 4.
5	The device calls the app and indoor monitor. The app or indoor monitor answers and then hangs up. The SDK will send a callback event to the device.	The device sends an event of type 5. The `extend` parameter is required.
6	The device calls the app and indoor monitor. The community app or indoor monitor answers. The SDK will send a callback event to the device.	The device sends an event of type 6.
7	The device calls the app and indoor monitor. The call is answered, the conversation time exceeds the timeout period, and then the device hangs up. The default conversation timeout period is 90s.	The device sends an event of type 7. The `extend` parameter is required.

Example:

   api_name: tuya.device.industry.base.edge.control.protocol.send
   api_version:1.0
   message:
       {
	"input": "{\"deviceId\":\"6c8f87e58d5ae1ccd7q***\",\"mode\":\"ac_doorbell\",\"targetAddress\":\"00-00-00-00-01-01\",\"type\":\"1\"}"
}
   result:
         {
         	"result":"1208283103756304***",
	         "t": 1598010614***,
	         "success": true
         }

Query the number of P2P clients simultaneously supported by the device

After pairing is successful, request this ATOP interface to query the number of P2P clients simultaneously supported by the device.

This number is set as the value of s_mgr_info.max_p2p_user, in order to limit the number of clients that view the video at the same time.

Request parameter

Request parameter	Parameter type	Description	Required
deviceId	String	The device ID.	Yes

Response parameter

Parameter	Type	Description
maxClientNum	Integer	The number of P2P clients simultaneously supported by the device.
deviceId	String	The device ID.

Example:

   api_name: tuya.device.industry.base.edge.device.p2p.client.num

   api_version:1.0
   message:
       {
	       "input": "{\"deviceId\":\"6c8f87e58d5ae1ccd7q***\"}"
       }
   result:
         {
	         "result": {
		           "maxClientNum": 3,
		           "deviceId": "6c8f87e58d5ae1ccd7q***"
	          },
	         "t": 1604494***,
	         "success": true
         }

Grade face images

Evaluate the face images captured by the access control device, and return the grades. If a face image is confirmed to be qualified, it will be sent to other access control devices.

Request parameter

Request parameter	Parameter type	Description	Required
fileId	String	The ID of a specified face image. See how to get the image ID.	Yes

Response parameter

Parameter	Type	Description
value	Double	Valid values: `0` to `10`. The recognition is successful if the grade is above `8`.
url	String	The URL of the face image.

Example:

   api_name: tuya.device.industry.base.edge.ai.face.score
   api_version:1.0
   message:
       {
	       "fileId": "45976fb2a6c06811ecc6a790ac562***"
       }
   result:
         {
	         "result": {
		           "value": 10,
		           "url": "www.tuya.com/he***.jpg"
	          },
	         "t": 1604494***,
	         "success": true
         }

Query time rule list

Request parameter

Request parameter	Parameter type	Description	Required
input	List<String>	The list of time rule IDs.	Yes

Response parameter

Parameter	Type	Description
ruleId	Float	The number of P2P clients simultaneously supported by the device.
ruleName	String	The name of a specified time rule.
period	String	The allowed period in the format of a JSON string. For example, `[{"weekDay":1,"weekTime":[{"start":"32400000","end":"64800000"}]},{"weekDay":2,"weekTime":[{"start":"684000000","end":"75600000"}]}]`.
allowedDate	String	The allowed date in the format of a JSON string. For example, `[{"start":"1571587200000","end":"1864569600000"},{"start":"1573022801885","end":"1864569600000"}]`.
deniedDate	String	The denied date in the format of a JSON string. For example, `[{"start":"1571587200000","end":"1864569600000"},{"start":"1573022801885","end":"1864569600000"}]`.

Example:

   api_name: tuya.device.industry.base.edge.device.time.rules
   api_version:1.0
   message:
       {
	       "input": ["242021****00000001","242021****00000002"]
       }
   result:
         {
	         "result":[ {
              "ruleId": "242021****00000001",
               "ruleName": "Time rule 1",
               "period": " [{\"weekDay\":1,\"weekTime\":    [{\"start\":\"1571587200000\",\"end\":\"1864569600000\"},{\"start\":\"1864569600000\",\"end\":\"1864569700000\"}]}]",
               "allowedDate": "[{\"start\":\"1571587200000\",\"end\":\"1864569600000\"}]",
               "deniedDate": "[{\"start\":\"1571587200000\",\"end\":\"1864569600000\"}]",
            }],
	         "t": 1604494202,
	         "success": true
         }

Description of time rules

period: allowed period. You can specify which periods of the week are allowed.
weekDay: use 1 to 7 to represent Monday to Sunday respectively. The start time and end time are represented by the number of milliseconds from 0 o’clock. For example, 32400000 means 9 o’clock.
For example, [{"weekDay":1,"weekTime":{"start":"32400000","end":"64800000"}},{"weekDay":2,"weekTime":{"start":"684000000 ","end":"75600000"}}] means that the access is allowed from 9:00 to 18:00 on Monday and from 19:00 to 21:00 on Tuesday.
allowedDate: The 13-digit timestamp of the time when the access is allowed.
deniedDate: The 13-digit timestamp of the time when the access is denied.
Time priority: denied date > allowed date > allowed period.
First, check whether the visit time is in the “denied date”. If yes, access will be denied. If not, check whether the visit time is in the “allowed date”. If yes, access is allowed. If not, continue to check whether it is in the “allowed period”. If yes, the allow is allowed. Otherwise, the access is denied.

Report access records

If a user’s access is recognized, the access control device calls the MQTT interface to report the access records. The reported parameters are as follows:

Request parameter

Request parameter	Parameter type	Description	Required
uid	String	The user ID. The value is empty for a stranger.	Yes
t	long	The time when an access event occurred, in the `long` type.	Yes
way	Integer	The unlocking method. Valid values: `1`: card `2`: password `3`: QR code `4`: face `5`: fingerprint `6`: infrared sensor `8`: Bluetooth `9`: remote control `10`: others	Yes
imageId	String	The ID of a specified image file. See how to get the image ID.	No
passPwd	String	The access control password. It is required in password mode.	No
cardNo	String	The card number.	No
temp	String	The body temperature.	No
passType	Integer	The type of access control. Valid values: `1`: enter `2`: exit	No
location	String	The location information.
success	Integer	Specifies whether the operation is successful. `true`: succeeded `false`: failed	Yes
message	String	The error message, indicating the error cause.

Response parameter

Type	Description
boolean	`true`: The call is successful. `false`: The call failed.

Follow the instructions in the IPC SDK development documents that describe the DP data saving interface, and report DP 126. The sample DP data format is as follows:

{\"uid\":\"uid9***\",\"imageId\":\"imageId\",\"t\":1598521531***,\"success\":1,\"way\":4}

Report access control alerts

The access control device calls the MQTT interface to proactively report alert events. The reported parameters are as follows:

Request parameter	Parameter type	Description	Required
alarmId	String	The ID of a specified alert.	Yes
alarmType	Integer	The alert type. Valid values: `1`: tamper alarm `2`: stranger alarm `3`: trailing `4`: loitering `5`: anti-passback `10`: others	Yes
alarmCont	String	The alert value.	Yes
imageId	String	The ID of a specified image file. See how to get the image ID.	No
happenTime	Long	The time when an alert was sent.	Yes
confirmEnable	Boolean	The processing status of a specified alert. Valid values: `true`: already processed. `false`: to be processed.	No
extendData	String	The extension field in the JSON format.	No

Description of extendData

Parameter	Type	Description	Required
taggerType	Integer	The type of a specified trailer, a second person following the first one who has passed through the gate. This field is required when `alarmType` is `3`, indicating the alert type is trailing. Valid values: `1`: family member `2`: stranger	No

Follow the instructions in the IPC SDK development documents that describe the DP data saving interface, and report DP 185. The sample DP data format is as follows:

{
    \"deviceId\":\"123123***\",
    \"alarmTime\": 1609435288373,
    \"alarmType\": 1,
    \"alarmContent\": \"Exception\",
    \"dealTime\": 1609435348373,
    \"alarmId\": \"123123123123\",
    \"extendData\": \"\"
}

Upload image

Upload the images captured by the access control device when a user’s access is recognized.

Get image URL and token

Call this ATOP interface to get the image URL and token. The sample request is as follows:

    api_name: tuya.device.industry.base.edge.file.upload.token
    api_version: 1.0
    message: {"subjectType":"edgegateway_faceImg"}
    result:
         {
         	"result": {
	              "uploadUrl": "https://cetus-cn.wgine.com/v1.0/file/up***",
	              "token": "0f2bf5e20cf2cc99c73986c196b0d***"
              },
	         "t": 1598010614***,
	         "success": true,
	         "status": "ok"
         }

Upload image

Send an HTTPS POST request to upload an image. The HTTPS URL is the uploadUrl returned by the above interface. The header is the token returned by the above interface and the header key is file_upload_token. The request body is the byte stream of the image. The image type is image/jpg.

Sample of uploading images:

Integration with Video Access Control Devices (Linux)

The result returned in the response body:

{
    "result": {"tmp_file_id": "45976fb2a6c06811ecc6a790ac562***"},
    "success": true,
}

The value of tmp_file_id is the ID of the image file.

Report execution result

After a DP is sent from the cloud and successfully executed on the device, the ATOP interface is called to report the execution result.

Request parameter

Parameter	Type	Description	Required
sn	String	The serial number.	Yes
success	Integer	The device status. Valid values: `0`: failure `1`: success	Yes
message	String	The description of the execution result.	Yes

Response parameter

Type	Description
Boolean	`true`: The call is successful. `false`: The call failed.

Example:

	api_name: tuya.device.industry.base.edge.Issue.data.cmd.result.upload
	api_version: 1.0
	message: {"message": "Executed successfully","success": 1,"sn": 12082831037563****}
	result: {
		"result": {true},
		"t": 1598010614***,
		"success": true,
		"status": "ok"
	}

Verify a person’s access permission

Perform the following steps to verify a person’s access permission.

The person needs to pass validation by access control card, face, or QR code.
In case of failure, the access will be denied.
If the validation is successful, request the interface to verify the person’s access permission. That is, verify the health code to get the health code status.
If the health code is yellow or red, the access will be denied. If the health code is green or does not exist, the access is allowed.

Request parameter

Parameter	Type	Description	Required
uid	String	The user ID.	Yes
deviceId	String	The device ID.	Yes
verifyTypeList	List<Integer>	The list of validation types. `1`: health code	Yes

Response parameter

Parameter	Type	Description
uid	String	The user ID.
extend	String	A JSON string like `{\"healthCode\":\"unknown\"}`.

Description of extend

Validation type	extend	Description
1	Returns the `healthCode` field	`unknown`: The health code is unknown, with an internal exception or with no health code. `red`: The health code is red. `green`: The health code is green. `yellow`: The health code is yellow.

The sample is as follows.

  api_name: tuya.industry.base.edge.door.verify.pass
   api_version:1.0
   message:
       {
	       "uid": "ay16110581781387****",
	       "deviceId": "6c2421a42631dcda68****",
	       "verifyTypeList": "[1]"
       }
   result:
         {
	         "result": {
		           "uid": "ay16110581781387****",
		           "extend": "{\"healthCode\":\"unknown\"}"
	          },
	         "t": 1614167169000,
	         "success": true
         }

Features of access control device

Add User

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
name	String	The username.	No
idCard	String	The identity card ID of the user.	No
phone	String	The mobile phone number.	No
beginTime	Long	The 13-digit timestamp when a validity period starts.	No
endTime	Long	The 13-digit timestamp when a validity period ends.	No
ruleIdList	List	The list of time rule IDs.	No
userFloor	Integer	The floor where a person is located. It is used when calling the elevator from the edge gateway.	No
secretKey	String	The user’s secret key with 32 characters. We recommend that you generate it through the UUID. The app and device generate dynamic QR codes based on the same secret key.	No
refreshTime	Long	The time when a QR code is refreshed. Default value: 5 minutes. Unit: milliseconds.	No
extend	String	The extension field in the JSON format.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
  "t": 1573557869,
  "data": {
  	"cid": "12345678",
  	"dps": {
  		"128": {
  			"data": {
  				"beginTime": 1576846010886,
  				"endTime": 1576846010886,
  				"idCard": "idcard",
  				"name": "username",
  				"phone": "1778888****",
  				"uid": "123123",
        "userFloor": 1,
        "ruleIdList":["242021030300000***","242021030300000***"],
        "secretKey":"fa26477e064d884c2fc13120e9da****",
        "refreshTime": 300000
  			},
  			"mode": "dc_userInfo",
  			"sn": 120800586238851****,
  			"type": "add"
  		}
  	}
  }
}

This interface supports idempotence. After a person with a specified UID is added, this person with the same UID can be added again successfully.

If beginTime and endTime are not empty, the person’s validity period is the same as beginTime and endTime. Otherwise, timeRuleList will prevail. The timeRuleList supports up to 3 items. After you get the ruleIdList, you can query the list of specified time rules. When a person passes, verify whether the access is allowed based on the time rule.

Update User

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
name	String	The username.	No
idCard	String	The identity card ID of the user.	No
phone	String	The mobile phone number.	No
beginTime	Long	The 13-digit timestamp when a validity period starts.	No
endTime	Long	The 13-digit timestamp when a validity period ends.	No
ruleIdList	List	The list of time rule IDs.	No
userFloor	String	The floor where a person is located. It is used when calling the elevator from the edge gateway.	No
secretKey	String	The user’s secret key with 32 characters. We recommend that you generate it through the UUID. The app and device generate dynamic QR codes based on the same secret key.	No
refreshTime	Long	The time when a QR code is refreshed. Default value: 5 minutes. Unit: milliseconds.	No
extend	String	The extension field in the JSON format.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"beginTime": 1576846387411,
					"endTime": 1576846387411,
					"idCard": "idcard",
					"name": "username",
					"phone": "1778888****",
					"uid": "uid",
          "userFloor": 1,
          "secretKey":"fa26477e064d884c2fc13120e9da****",
          "refreshTime": 300000
				},
				"mode": "dc_userInfo",
				"sn": 120800744162785****,
				"type": "update"
			}
		}
	}
}

When a person passes, verify whether the access is allowed based on the time rule.

Delete User

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"uid": "123123"
				},
				"mode": "dc_userInfo",
				"sn": 120801049576484****,
				"type": "del"
			}
		}
	}
}

Verify access permission

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
enable	Integer	Specifies whether to enable the access permission. Valid values: `0`: disable. `1`: enable. The added person’s access permission is enabled by default. If the permission is disabled, the person cannot pass based on the face, QR code, or access card.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"enabled": 1,
					"uid": "uid"
				},
				"mode": "dc_userInfo",
				"sn": 12080078984253****,
				"type": "enable"
			}
		}
	}
}

Add face

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
faceId	String	The face ID.	Yes
url	String	The URL of the face image.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"faceId": "faceid",
					"uid": "uid",
					"url": "url"
				},
				"mode": "dc_faceInfo",
				"sn": 120801153336434****,
				"type": "add"
			}
		}
	}
}

This interface supports idempotence. After a face image with a specified faceId is added, the face image with the same faceId can be added again and a success response is returned.

Update Face Information

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
faceId	String	The face ID.	Yes
url	String	The URL of the face image.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"faceId": "faceid",
					"uid": "uid",
					"url": "url"
				},
				"mode": "dc_faceInfo",
				"sn": 120801477101051****,
				"type": "update"
			}
		}
	}
}

Delete face

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
faceId	String	The face ID.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"faceId": "faceid",
					"uid": "uid"
				},
				"mode": "dc_faceInfo",
				"sn": 120801517856684****,
				"type": "del"
			}
		}
	}
}

Add Card

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
cardNo	String	The access card number.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"cardNo": "cardNo",
					"uid": "uid"
				},
				"mode": "dn_cardInfo",
				"sn": 120801655522969****,
				"type": "add"
			}
		}
	}
}

This interface supports idempotence. After a card with a specified cardNo is added, the card with the same cardNo can be added again and a success response is returned. Each user can have only one access control card. If another card is added to the same user, a failure result will be returned.

Update Card

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
cardNo	String	The access card number.	Yes
oldCardNo	String	The number of the card to be updated.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"cardNo": "cardNo",
					"oldCardNo": "oldCardNo",
					"uid": "uid9****"
				},
				"mode": "dn_cardInfo",
				"sn": 120801783846441****,
				"type": "update"
			}
		}
	}
}

Each user can have only one access control card. A user’s previous card must be cleared before the card is updated.

Delete card

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
cardNo	String	The number of the card to be deleted.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"cardNo": "uid9****",
					"uid": "uid9****"
				},
				"mode": "dn_cardInfo",
				"sn": 120801875624104****,
				"type": "del"
			}
		}
	}
}

Enable/disable card

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
enable	Boolean	Specifies whether to enable a specified card. Valid values: `0`: disable. `1`: enable.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"uid": "uid9****",
          "enable":true
				},
				"mode": "dn_cardInfo",
				"sn": 120801875624104****,
				"type": "enable"
			}
		}
	}
}

Add QR Code

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
qrCode	String	The `Code` of the QR code.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"qrcode": "qrCode",
					"uid": "uid9****"
				},
				"mode": "dc_qrCodeInfo",
				"sn": 120802035040372****,
				"type": "add"
			}
		}
	}
}

This interface supports idempotence. After a specified qrCode is added, the same qrCode can be added again successfully. Each user can have only one QR code. If a second QR code is added to the same user, a failure result will be returned.

Update QR Code

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
qrCode	String	The `Code` of the QR code.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"qrcode": "qrCode",
					"uid": "uid9****"
				},
				"mode": "dc_qrCodeInfo",
				"sn": 120802035040372****,
				"type": "update"
			}
		}
	}
}

Each user can have only one QR code. The user’s previous QR code must be cleared before the QR code is updated.

Delete QR code

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"uid": "uid9****"
				},
				"mode": "dc_qrCodeInfo",
				"sn": 120802035040372****,
				"type": "del"
			}
		}
	}
}

Manage remote unlocking

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 127. The sample DP data format is as follows:

{
    "t": 1573557869,
    "data": {
        "cid": "12345678",
        "dps": {
            "127": {
                "sn": 8839438****,
                "uid": "uid9****"
            }
        }
    }
}

In the process of remote unlocking, the person’s permissions are not verified. A door is opened as long as the device receives the specified DP.

Clear device data

Clear device data with one click, such as person, face, card, and password. It is used when a device is initialized or returned to the factory for repair.

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
all	Boolean	Specifies whether to clear all the data.	No
person	Boolean	Specifies whether to clear the data of all persons.	No
face	Boolean	Specifies whether to clear the data of all faces.	No
card	Boolean	Specifies whether to clear the data of all card numbers.	No
qrcode	Boolean	Specifies whether to clear the data of all QR codes.	No
passPwd	Boolean	Specifies whether to clear the data of all access control passwords.	No
other	Boolean	Specifies whether to clear other data.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 188. The sample DP data format is as follows:

{
    "t": 1573557869,
    "data": {
        "cid": "12345678",
        "dps": {
            "188": {
                "sn": 123****,
                "all": false,
               	"person": true,
               	"face": true,
               	"card": false,
               	"qrcode": false,
               	"passPwd": false
            }
        }
    }
}

Synchronize device time

The cloud service sends the time to a specified device, so the device time is synchronized with the time in the cloud.

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
timestamp	Long	The timestamp.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 187. The sample DP data format is as follows:

{
    "t": 1573557869,
    "data": {
        "cid": "12345678",
        "dps": {
            "187": {
                "sn": 123****,
                "timestamp": 1652698441227
            }
        }
    }
}

Enable/disable access control device

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
sn	String	The serial number and unique identifier of a specified request.	Yes
bizType	String	The business type. Default value: `maintain`.	Yes
operateType	String	The operation type. Default value: `enable_disable_device`.	Yes
extendData	String	A JSON string, such as {“value” :1}. Valid values: `1`: enable. `0`: disable.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 186. The sample DP data format is as follows:

{
    "t": 1573557869,
    "data": {
        "cid": "12345678",
        "dps": {
            "186": {
                "sn": 140550692870396****,
                "bizType": "maintain",
                "operateType": "enable_disable_device",
                "extendData": "{\"value\":1}"
            }
        }
    }
}

If the device feature is disabled, features such as card, password, QR code, face, fingerprint, and remote unlocking will not be available.
If the device feature is enabled, features such as card, password, QR code, face, fingerprint, and remote unlocking will be available.

Add Password

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
passPwd	String	The access control password.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"passPwd": "passPwd",
					"uid": "uid9****"
				},
				"mode": "dc_passPwd",
				"sn": 120802035040372****,
				"type": "add"
			}
		}
	}
}

Each user supports multiple passwords, and different users can be assigned the same password.
This interface supports idempotence. A successful result will be returned if a user is assigned the same password again.

Update password

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
passPwd	String	The access control password.	Yes
oldPassPwd	String	The old password to be updated.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
					"passPwd": "passPwd",
          "oldPassPwd": "oldPassPwd",
					"uid": "uid9****"
				},
				"mode": "dc_passPwd",
				"sn": 120802035040372****,
				"type": "update"
			}
		}
	}
}

Modify the user’s password. If the specified old password (oldPassPwd) does not exist under the user, a failure result will be returned.

Delete password

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
uid	String	Tuya user ID.	Yes
passPwd	String	The password to be deleted.	Yes

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 128. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"128": {
				"data": {
          "passPwd": "passPwd",
					"uid": "uid9****"
				},
				"mode": "dc_passPwd",
				"sn": 120802035040372****,
				"type": "del"
			}
		}
	}
}

Delete a user’s password. If the specified password (passPwd) does not exist, a failure result will be returned.

Hang up Video Call

The request parameters are as follows:

Request parameter	Parameter type	Description	Required
type	Integer	The type of hanging up the video call. `1`: The app rejects and hangs up all calls.	Yes
mes	String	The reason for hanging up a video call.	No

Follow the instructions in the IPC SDK development documents that describe the DP data reading interface, and send the DP of 191. The sample DP data format is as follows:

{
	"t": 1573557869,
	"data": {
		"cid": "12345678",
		"dps": {
			"191": {
				"sn": 120802035040372****,
				"type": 1,
				"mes":"The integrator hangs up the video call"
			}
		}
	}
}

Send a command of hanging up to a specified video access control device. After receiving the command, the device stops video streaming.

Others

MD5 algorithm

For more information about the standard MD5 algorithm, visit GitHub.

The MD5 algorithm is encapsulated based on the standard algorithm. For more information, see the method md5Hex.

#include <iostream>
#include "./md5.h"

using std::cout;
using std::endl;

string md5Hex(string data, bool isMd5){
	string hex = "";
	if (data != "") { //data != null
		if (!isMd5) {
			hex = MD5(data).toStr();
		}

		string midden = hex.substr(8, 16);
		string temp = midden.substr(0, 8);
		temp = temp + hex.substr(0, 8);
		temp = temp + hex.substr(24, 8);
		temp = temp + midden.substr(8, 8);
		hex = temp;
	}
	return hex;
}

int main()
{
	string data = "{\"t\":1598010***,\"key\":\"a354fffa81674d80b7d1e0696ad69***\",\"cid\":\"4rfvd80basdue7d***\"}";
	cout<< md5Hex(data, false) <<endl;
	return 0;
}

QR code recognition

The device must support the QR codes in two formats:

v1.0 QR code:

7421371370865597349888943036

v2.0 QR code:

{
  "qrcode": "YXkxNjExMDU4MTc4MTM4N240Mjd8ZTRhZjIzZTY=" //value: Base64 encoded string
}

After scanning, the device verifies the QR code in the following steps.

Check the content of the QR code to determine whether it is v1.0 or v2.0.
- If it is a v1.0 QR code, compare it with the person’s QR code. If the comparison is successful, access is allowed.
- If it is a v2.0 QR code, first decode the content through the Base64 method, and parse the QR code information.
Compare and verify the static QR code, and compare the QR code information with the person’s QR code. If the comparison is successful, access is allowed.
If the comparison fails, verify it through the dynamic QR code verification interface. If the verification is successful, the access will be allowed. Otherwise, the access will be denied.

The interface to verify dynamic QR code:

Verify the dynamic QR code by using the method totp_util.c verifyTOTPFlexibility.

totp_util.h

#ifndef __TOTP_UTIL_H__
#define __TOTP_UTIL_H__

#ifdef __cplusplus
	extern "C" {
#endif

// The returned char* must be released manually.
char* generateTOTP(char* uid, char* secretKey，LONG_T refreshTime) ;

BOOL_T  verifyTOTPFlexibility(char* uid, char* secretKey, char* willVerifyTotp, LONG_T refreshTime);



#ifdef __cplusplus
} // extern "C"
#endif

#endif

totp_util.c

#include "tuya_sha256.h"
#include "uni_time.h"
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <ctype.h>
#include "totp_util.h"
static  long INITIAL_TIME = 0;
#ifndef MAX
#define MAX(a,b) (((a) > (b)) ?(a) : (b))
#endif
static void insert_zero(char* input);
static void hex_to_string(IN BYTE_T *input, IN INT_T input_len, OUT BYTE_T *output, INOUT INT_T* p_out_len);
static UINT64_T timeFactor(UINT64_T targetTime, UINT64_T refreshTime) ;
static char* doGenerateTOTP(char* key, char* time);
static unsigned char* hexStr2Bytes(char* src);
static void toUpperCase(char* input);

static void toUpperCase(char* input)
{
    for(int i = 0 ;i<strlen(input);i++)
    {   
        input[i]=toupper(input[i]);
    }
}
// Populate the head with 0
static void insert_zero(char* input)
{
    int size = strlen(input);
    char* tmp = (char*)malloc(size+1) ;
    strcpy(tmp,input);
    int i=0;
    for(;i <size;i++){
        input[i+1]=tmp[i];
    }
    input[0]='0';
    free(tmp);
}



static void hex_to_string(IN BYTE_T *input, IN INT_T input_len, OUT BYTE_T *output, INOUT INT_T* p_out_len)
{
    INT_T i;
    INT_T offset = 0;
    
    if(NULL == input || NULL == output || NULL == p_out_len)
    {
        printf("invalid argument\r\n");
        return;
    }

    if(*p_out_len < input_len * 2 + 1)
    {
        printf("OUTPUT LEN IS SHORT THAN INPUT LEN * 2\r\n");
        *p_out_len = 0;
        return;
    }

    for(i = 0;i < input_len;i++) 
    {
        sprintf(&output[offset],"%02x",input[i]);
        offset += 2;
    }
    output[offset] = 0;

    *p_out_len = offset;
}

static char* longtoHexString(unsigned long input)
{
    printf("long input=%lu \n",input);
    char* str = (char*)malloc(10);
    int i = 0;
    unsigned long temp = 0;
    while(input > 0 || i==0){
            temp = input % 16;// Take the remainder
            str[i++] = temp >= 10 ?((temp - 10) + 'a') : (temp + '0');
            input = input >> 4;
    }
    str[i] = '\0';
    // Flip the high and low bits
    int t = 0;
    for(int j = 0; j < i / 2; j++){
            t = str[j];
            str[j] = str[i - j - 1];
            str[i - j - 1] = t;
    }
    printf("longtoHexString ouput=%lu \n",str);
    return str;
}



static unsigned char* hexStr2Bytes(char* src)
{
    unsigned char* tmp = (char*)malloc(strlen(src)+1);
    memset(tmp,0,sizeof(tmp));
    strcpy(tmp,src);
    // Make sure that `tmp` is an even number.
    if(strlen(tmp)%2 != 0){
       insert_zero(tmp);
    }

    int m=0;
    int len = strlen(tmp)/2;
    char* end ;
    unsigned char* dst = (char*)malloc(len+1);
    memset(dst,0,len+1);
    for(int i =0;i<len;i++)
    {
    	m = i*2;
        char subs[3]={0};
        memcpy(subs,tmp+m,2);
        dst[i]=strtol(subs,NULL,16);
    }
    free(tmp);
}

/**
 * Get dynamic factor
 *
 * @param targetTime   The specified time
 * @param refreshTime    The refresh time of the QR code
 * @return long
 */
static UINT64_T timeFactor(UINT64_T targetTime, UINT64_T refreshTime)
{
    return (targetTime - INITIAL_TIME) / refreshTime;
}

/**
 * @param key   The user ID + seed key
 * @param time  The time factor
 * @return
 */
static char* doGenerateTOTP(char* key, char* time)
{
    // 1. If time is less than 16 characters, pad it with zeros. Example: 30B649C -> 00000000030B649C
    int time_len = MAX(17,strlen(time));
    char* fill_time=(char*)malloc(time_len);
    memset(fill_time,0,time_len);
    strcpy(fill_time,time);
    while (strlen(fill_time) < 16) {
        insert_zero(fill_time);
    }

    unsigned char* input = hexStr2Bytes(fill_time);
    // Hash encryption
    BYTE_T hash[32+1] = {0};
    sha2_hmac(key,strlen(key),input,strlen(input),hash,0);

    // Return a dynamic password of the specified number of digits
    INT_T result_len = 65;
    char* result = (char*)malloc(result_len);
    memset(result,0,result_len);
	hex_to_string(hash, strlen(hash), result, &result_len);

    // If the returned value is less than the specified number of digits, pad it with 0
    while (strlen(result) < 8) {
        insert_zero(result);
    }
    printf("sha2_hmac result:%s\n", result);
    free(fill_time);
    fill_time=NULL;
    free(input);
    input=NULL;
    return result;
}

/**
 * Rigid password verification, which can be successfully verified within 3 cycles.
 *
 * @param uid     The user ID.
 * @param secretKey   The secret key, 32-digit string. It is recommended to be generated by the UUID.
 * @param willVerifyTotp    The QR code information to be verified.
 * @param refreshTime    The refresh time of the QR code.
 * @return boolean
 */
BOOL_T  verifyTOTPFlexibility(char* uid, char* secretKey, char* willVerifyTotp, LONG_T refreshTime)
{
    if (!uid || !secretKey|| !willVerifyTotp ) {      
        printf("param err \r\n");
        return false;
    }

// Get the timestamp of the current time in milliseconds
    UINT64_T now = uni_time_get_posix_ms();

// Construct a variable with uuid and secretKey
    char* uid_secretKey = (char*)malloc(strlen(uid)+strlen(secretKey)+1);
    memset(uid_secretKey,0,sizeof(uid_secretKey));
    strcpy(uid_secretKey,uid);
    strcat(uid_secretKey,secretKey);
    char* time1 = longtoHexString(timeFactor(now, refreshTime));
    toUpperCase(time1);

    // TOTP encryption, cycle 1
    char* tempTotp1 = doGenerateTOTP(uid_secretKey, time1);
    // Returns TRUE
    if (strcmp(tempTotp1,willVerifyTotp)==0) {
        free(tempTotp1);
        free(uid_secretKey);
        free(time1);
        return TRUE;
    }
    free(tempTotp1);



// TOTP encryption, cycle 2

    char* time2 = longtoHexString(timeFactor(now - refreshTime, refreshTime));
    toUpperCase(time2);
    // Construct a variable with uuid and secretKey
    memset(uid_secretKey,0,sizeof(uid_secretKey));
    strcpy(uid_secretKey,uid);
    strcat(uid_secretKey,secretKey);

    char* tempTotp2 = doGenerateTOTP(uid_secretKey, time2);
    if (strcmp(tempTotp2,willVerifyTotp)==0) {
        free(tempTotp2);
        free(uid_secretKey);
        free(time2);
        return true;
    }
    free(tempTotp2);

 // TOTP encryption, cycle 3
    char* time3 = longtoHexString(timeFactor(now + refreshTime, refreshTime));
    toUpperCase(time3);
    memset(uid_secretKey,0,sizeof(uid_secretKey));
    strcpy(uid_secretKey,uid);
    strcat(uid_secretKey,secretKey);

    char* tempTotp3 = doGenerateTOTP(uid_secretKey, time3);
    if (strcmp(tempTotp3,willVerifyTotp)==0) {
        free(tempTotp3);
        free(uid_secretKey);
        free(time3);
        return true;
    }
    free(tempTotp3);
    free(uid_secretKey);
    free(time3);
    return false;
}

/**
  Generate a dynamic QR code
  *
  * @param uid     The user ID.
  * @param secretKey   The dynamic secret key, 32-digit string. It is recommended to be generated by the UUID.
  * @param refreshTime    The refresh time of the QR code
  * @return
  */
 char* generateTOTP(char* uid, char* secretKey，LONG_T refreshTime)
 {
      if (!uid || !secretKey || refreshTime==0) {    
        printf("param err \r\n");
        return false;
    }
     // Get the timestamp of the current time
     UINT64_T now = uni_time_get_posix_ms();
     // Convert the dynamic factor to hexadecimal
     printf("cur time =%llu,",now);
     printf("timeFactor%lu,",timeFactor(now, refreshTime));
     char* time = longtoHexString(timeFactor(now, refreshTime));
     toUpperCase(time);
     char* uid_secretKey = (char*)malloc(strlen(uid)+strlen(secretKey)+1);
     strcpy(uid_secretKey,uid);
     strcat(uid_secretKey,secretKey);
     char* totp = doGenerateTOTP(uid_secretKey, time);
     free(uid_secretKey);
     free(time);
     return totp;
 }

Sample v2.0 QR code:

The content of the QR code
{
  "qrcode": "YXkxNjExMDU4MTc4MTM4N240Mjd8ZTRhZjIzZTY=" //value: Base64 encoded string
}

YXkxNjExMDU4MTc4MTM4N240Mjd8ZTRhZjIzZTY= Get a string after Base64 decoding
"ay16110581781387****|e4af2***"

User ID: ay16110581781387****
QR code information: e4af2***

First, get a static QR code based on the user ID for comparison.
If the comparison fails, perform dynamic QR code verification.
QR code refresh time: 5 × 60 × 1000
Query the user's secretKey based on the user ID.
Then, call the dynamic QR code verification interface TOTPUtils.verifyTOTPFlexibility.
If `true` is returned, the verification is passed.

Access control card recognition

The access control device must support reading access control cards. The person’s card number is stored in the seventh sector of the card. After the device reads the card from the seventh sector, it is compared with the person’s access control card in the device. If the comparison is successful, the card is recognized successfully.

Prev DocIntegration with Industry Devices

Next DocElevator Controller