Thingboot's 12-bit touch button access control supports HTTP interface remote control, which can be integrated into your software just like calling a normal API. Below I have compiled an access plan, covering several key aspects of hardware docking, interface calling and password management.

Solution: Integrate the 12-bit touch button access control into the software project

1. Hardware analysis and docking preparation

First of all, we need to figure out what the "12-digit touch button access control device" in our hands is.

According to Thingboot’s hardware information, this device is often called"Smart password access control | touch version". It's not just an input keyboard, it's actually a standalone controller with WiFi capabilities.

• Core features

  • Communication method: Comes with WiFi (2.4G), no need to buy an additional gateway, you can connect to the Internet as long as there is a WiFi signal.

  • interface protocol: Supports HTTP interface, which means it can communicate directly with the cloud. For software development, we only need to call the API..

  • docking ability:Supports docking with electromagnetic locks and electric plug locks (12V DC).

• Requires explicit parametersBefore starting to write code, log in to the Thingboot console and enterAppID、AppSecret(equivalent to your software account password) andDevice ID(The unique ID card for the access control device) Get ready.

2. Overall architecture process

The general logic is this:

1. software project -> 2. Call the core step open interface -> 3. Cloud server -> 4. Access control equipment (WiFi reception) -> 5. Perform unlocking/password verification.

• Notice: Even if there is no network, the device itself supports the "offline password" function, which is a good supplementary solution when the network is disconnected..

3. Practical operation of accessing core functions

Here we are a little more "colloquial" and don't talk about virtual things, just talk about how to adjust it.

1. Remote door opening (real-time control)

This scenario is suitable for administrators to click the "Open Door" button on the computer or remotely open the computer room door through the APP.

• interface address: https://api.thingboot.com/{yourAppID}/device/control/

• How to operate: Send a command to the device to "unlock" it.

• Request parameters: We need to tell the server "which device" to do "what action".

Thoughts in the codeYou only need to write a function in the backend to initiate a POST request to this URL, bringing the signature (Sign) and timestamp (Ts). The signature algorithm is generally available in the Thingboot documentation, such asmd5(md5(AppSecret) + ts)this format. This is equivalent to telling the door control: "I am the legal administrator, please open the door!"

2. Password management (this is a pain point)

As computer room access control, we definitely don’t want everyone to use the same password, and it needs to be managed according to different people or timeliness.

According to the hardware specifications, the device supports 100 dynamic passwords and 30 permanent passwords.

• Issue permanent passwordFor example, the computer room operation and maintenance supervisor needs long-term authority. You can "write" the password into the device's memory through the interface. The setting parameters may look like this:

• Issue dynamic passwordFor example, the outsourced cleaner will go in to clean the house at 7pm today. You can set a password that is only valid from 6 to 8 tonight.

Workflow

1. The software background generates a random code (such as 889900).

2. Call the interface to push the password and validity period (StartTime/EndTime) to the device.

3. Device storage successful.

4. The user inputs on the access controller889900 + #Confirm and the door opens.

5. After the validity period, the device will refuse to open the door even if the correct password is entered.

3. Event reporting and logging (monitoring who moved the door)

Whether it is swiping a card, pressing a password or prying a door, the device will upload the record. Core steps usually supportCloud message push(HTTP Push or MQTT).

• How to access: You need to configure a "receiving address" (URL) in the project. When someone opens the door, Thingboot's server will actively POST a piece of JSON data to your server.

• Data content may include

  • key_id: Which password was used to open it (if it is a dynamic password, you will know who opened it).

  • time: Door opening time.

  • method: Verification method (password/remote/key).

  • status: Whether to open the door normally or try an incorrect password (alarm).

In this way, you can not only control the door, but also generate a beautiful "access control flow record sheet".

4. Implementation steps

If you are holding a device in your hand and want to access it, you can refer to the following steps:

1. Hardware distribution networkFirst, power on the access control device (DC 5-12V). According to the manual, generally press and hold a certain key combination (such as#+*) to put it into network configuration mode. Use the mobile app or configure it through AP hotspot and tell it the WiFi account password..

2. Interface debuggingFirst, activate the first "open door" command in a tool such as Postman. There is no need to write code. First, adjust the signature and parameters, and confirm that the device can receive the command "di beep" or the relay is closed.

3. Business logic encapsulationWrite one in your projectDoorLockServiceClass, encapsulate the instructions for opening and closing the door into methods to avoid scattering API call code everywhere.

4. security policy

   • protect key: AppSecretDo not write it in the front-end code, it must be called in the back-end, otherwise it will be easily captured and the device will be maliciously controlled.

   • logging: Every API call (who clicked on the software to open the door at what time) is recorded for auditing.

5. Summary

Integrating this "12-bit touch button access control device" into your software project is actually a one-timeHTTP API docking. Its openness is pretty good. It doesn't require complicated hardware protocol development. You only need to understand the interface documentation.

In one sentence:When the device is connected to the Internet, you are responsible for taking its device ID to the interface to send a password or unlocking command, and it is responsible for executing and pushing the result back to you.