1. Server Configuration

1.1. ThingsBoard

ThinkLink does not provide the service of building the ThingsBoard server, but supports seamless data connection with the deployed ThingsBoard platform. By configuring relevant connection parameters, TKL can synchronize device data to ThingsBoard in real time, which is convenient for users to perform visual display and advanced application development.

1.1.1. Get ThingsBoard connection information

• Protocol: communication protocol
• Host: Server Address
• Port: Service Port
• AccessToken: Device Access Token

1.1.2. fill in the ThingsBoard information

Operating Instructions:

1. log in to the TKL system and enter the "Server Configuration" page;
2. findThingsBoard docking configuration area;
3. fill in the above four necessary information;
4. click "Submit" to save the layout;
5. when the configuration is complete, click the Restart button to start or update the ThingsBoard service connection.

1.1.3. Enable ThingsBoard functionality at the device level

completing the server configuration alone is not enough to activate data synchronization. You also need to enable the ThingsBoard synchronization function in the specific device management.

1. Enter the "device management" module of TKL;
2. select the device that needs to be docked to the ThingsBoard;
3. in the device details page, find and enable the "ThingsBoard function" switch;
4. save the configuration.

✅ When enabled, the device and its properties, telemetry data, and entity information are automatically synchronized to the ThingsBoard platform.

1.1.4. View devices on ThingsBoard

when a device successfully ascends the first piece of data, ThingsBoard will automatically register the device (based on the provided accessstoken) and display it in its device list. Note:

• make sure AccessToken it is correct and has been pre-created on the ThingsBoard side;
• if the device does not appear, check the network connectivity, Port openness, and whether the Access Token is bound to the correct device;
• data Synchronization is bidirectional: TKL is responsible for data collection and processing, and ThingsBoard is responsible for display and rule engine processing.

1.1.5. Attached: How to create an Access Token for a gateway

To create an Access Token for a gateway in the ThingsBoard platform, follow these steps:

1. login to the ThingsBoard Web interface;
2. create or select a device of type Gateway;
3. enter the "Credentials" page of the device;
4. copy or Build** Access Token **;
5. fill this Token in the server configuration of TKL.

1.2. HomeAssistant

the HomeAssistant server needs to be built by the user and does not belong to the functional scope of the ThinkLink(TKL) system. TKL provides seamless connection with HomeAssistant to realize automatic discovery and synchronization of device information, attributes, and entities.

After completing the relevant configuration, click submission button and click on the prompt restart to start the service connection with HomeAssistant.

**[Note]]**if you want the device to be fully displayed and used normally in HomeAssistant, you must enable it in the management configuration of the corresponding device.HomeAssistant function. When enabled, the device, its properties, and entities will be automatically discovered and rendered in the HomeAssistant page.

1.2.1. Docking mode

TKL supports two Broker modes to integrate with HomeAssistant:

• useMQTT Broker for ThinkLink + use HomeAssistant's MQTT Broker

either way, make sure that the following two prerequisites are met:

✅Prerequisite 1:
the HomeAssistant related fields are correctly configured in the object model. For the configuration method, see Chapter 7.1.

✅Prerequisite 2: enabled in the configuration page of the target device HomeAssistant function

1.2.2. method 1: Use the Broker of ThinkLink

in this mode, the user's HomeAssistant server connects to the built-in MQTT Broker of ThinkLink as an MQTT client.

1.2.2.1. Configuration steps:

1. log in to your HomeAssistant server;
2. enter MQTT integration settings to add a new MQTT Broker;
3. enter the Broker connection information of ThinkLink, including:
   • address (IP or domain)
   • port
   • username/Password
4. set the following key parameters:
   • discovery_prefix (Service Discovery Prefix)
   • manufacturer (Manufacturer Name)
5. save the configuration and restart the HomeAssistant service.

After completing the above operations, devices that have the HomeAssistant function enabled will be automatically discovered and displayed as corresponding entities in HomeAssistant.

1.2.3. Method 2: Use the Broker of HomeAssistant

In this mode, ThinkLink acts as an MQTT client and actively connects to the Broker built into HomeAssistant.

1.2.3.1. Enable the MQTT Broker in HomeAssistant

The HomeAssistant MQTT integration must be running before ThinkLink can connect to it.

1. In HomeAssistant, go to Settings → Devices & Services → Add Integration and search for MQTT;
2. Select MQTT and configure the broker settings. If using the built-in Mosquitto add-on, the broker host is localhost or the HA IP, port 1883.
3. Note the username and password configured for the broker.

1.2.3.2. Configure ThinkLink to connect as a client

1. Log in to the TKL system and go to System Management → Server Configuration;
2. Find the HomeAssistant section and set the mode to Use HomeAssistant Broker;
3. Fill in the HomeAssistant broker parameters:

Parameter	Description	Example
Protocol	MQTT connection protocol	mqtt
Host	HomeAssistant host IP or domain	192.168.1.100
Port	MQTT broker port on HA	1883
Username	MQTT credentials configured on HA	ha_user
Password	MQTT credentials configured on HA	ha_pass
discovery_prefix	HA MQTT discovery prefix (must match HA setting)	/V32/{tcode}/HA

4. Click Submit, then Restart to activate the connection.

In this mode ThinkLink publishes device discovery and state topics to the HA broker, so HA can automatically register TKL devices as entities without HA connecting to TKL's broker.

1.2.4. Validation

after completion, ThinkLink releases device information to HomeAssistant through the MQTT protocol to realize automatic entity registration and status synchronization.

✅ Verify success:
go to the "devices and services" page of HomeAssistant, check whether there are new devices from ThinkLink, and check whether its sensors, switches and other entities are displayed and updated normally.

1.3. BACnet

attention: The BACnet Service function can only be used on independently deployed TKE devices. This function is not available in the Cloud Service version.

ThinkLink(TKL) allows device data in the TSL to be exposed to the outside using the standard BACnet protocol for easy integration with the building management system (BMS). To implement the full functionality of the BACnet service, complete the following two steps:

1. configure the BACnet attribute of the relevant fields in the thing model;
2. enable the BACnet feature on the target device and configure the server parameters correctly.

1.3.1. BACnet field configuration

Before enabling the BACnet service, you must thing Model configure the corresponding BACnet attribute for the field to be mapped externally. Please refer to document 7.1 for specific configuration methods.

1.3.2. Server Configuration

For to successfully run TKL as a BACnet server, you need to configure the following core parameters in the system. All settings are located in MAINTENANCE → BACnet under the menu.

Please ensure that you have enabled the BACnet service for the device before completing the detailed configuration here, and export the generated BACnet point table to the BMS platform for use.

Item	description	default Value	can be modified
IP address	the local IP address of the TKL device, which is used for BACnet communication. If set 0.0.0.0 , indicating that all network interfaces are bound	0.0.0.0	yes
Port	BACnet service listening port	47808 (Decimal) (I. E., UDP port 0xbac0)	yes, adjustable according to BMS requirements
Device ID	BACnet device unique identifier, must be unique within the system need to negotiate with BMS platform	1	yes
Vendor Identifier	vendor identification number, representing the equipment manufacturer	99(Unofficial reserved value, it is recommended to fill in according to the actual)	yes
Device Name	device name, for displaying in BMS	TKE	yes, it is recommended to modify according to site naming convention
Max APDU Length Accepted	maximum acceptable APDU length, affecting communication efficiency and compatibility	1024	yes, adjust for client capabilities
Segmentation Supported	segmentation support mode, which defines whether the device supports segmented transmission	segmentedBoth (Means both sending and receiving can be segmented)	yes, optional: noSegmentation segmentedTransmit segmentedReceive segmentedBoth

After completing the above configuration, please enterpoint Table Management the module views or exports the BACnet object list (that is, the point table) of the current device and delivers it to the BMS integrator for access and monitoring.Prompt:

• After modifying the configuration, you need to restart the BACnet service or related devices to take effect.
• We recommend that you confirm the specific requirements of the preceding parameters with the BMS integrator to avoid connection failure due to protocol mismatch.
• The BACnet over IP protocol is built based on UDP to ensure that the corresponding port is allowed to pass through at the network level.

1.4. Third-Party MQTT

TKL supports pushing parsed device telemetry data to a third-party MQTT broker. This allows external platforms to receive structured device data without subscribing to the ThinkLink broker directly.

1.4.1. Configuration

Go to System Management → Server Configuration and find the ThirdParty section. Fill in the following parameters:

Parameter	Description	Example
Protocol	MQTT connection protocol	mqtt or mqtts
Host	Third-party broker address	192.168.1.100
Port	Broker port	1883
Telemetry Topic	Topic to publish device telemetry data	/your/custom/topic
Username	Broker authentication username	user
Password	Broker authentication password	pass

After filling in the parameters, click Submit then Restart to activate the connection.

1.4.2. Enable at the device level

After completing the server configuration, enable the ThirdParty function on each target device:

1. Go to Device Management and open the target device;
2. On the device details page, enable the ThirdParty switch;
3. Save the configuration.

Once enabled, ThinkLink publishes the device's parsed telemetry data to the configured topic whenever new data arrives.

1.5. Modbus TCP Server

Attention: The Modbus TCP Server function is only available on independently deployed TKE/TKG devices. It is not available in the Cloud Service version.

TKL can act as a Modbus TCP slave server, exposing device telemetry data as Modbus registers. This allows SCADA systems, PLCs, and other Modbus TCP masters to read device data using standard Modbus protocol.

1.5.1. Server Configuration

Go to System Management → Server Configuration and find the Modbus TCP Server section. Configure the following parameters:

Parameter	Description	Default	Notes
Port	Modbus TCP listening port	502	Ensure this port is open at the network level
Coils	Coil register mapping (read/write bit registers)	—	Mapped to device boolean fields
Discrete Inputs	Discrete input register mapping (read-only bit registers)	—	Mapped to device boolean fields
Input Registers	Input register mapping (read-only 16-bit word registers)	—	Mapped to device numeric fields
Holding Registers	Holding register mapping (read/write 16-bit word registers)	—	Mapped to device numeric fields

After configuration, click Submit then Restart to start the Modbus TCP service.

1.5.2. Enable at the device level

The Modbus TCP register values are sourced from device thing model fields. To expose a device's data:

1. Configure the Modbus TCP field mapping in the Thing Model;
2. Enable the Modbus TCP function on the target device in Device Management.

Modbus TCP masters can then read register values from the TKL device using the configured port and register addresses.

1.6. Org Params

Org Params are organization-level (tenant-level) "environment variables" maintained centrally under System Management → Server Configuration → Org Params. Configure them once and they are shared across the entire tenant. The platform automatically injects them as the org_params argument into the following user scripts:

• RPC Model: rpc_script({ device, params, alarms, logger, org_params })
• Thing Model parse script: payload_parser(device, msg, thingModelId, noticeAttrs, org_params)
• Trigger Model: trigger_script(device, thingModelId, org_params)
• MQTT Forwarder script: forwardScript({ topic, msg, org_params })

💡 Why it exists: keep credentials / endpoints / business identifiers out of script bodies. Scripts hold only logic; secrets live in Org Params. Rotating a webhook, swapping environments, or changing a third-party endpoint is then a single edit in one place — no need to touch every RPC, trigger, or forwarder.

1.6.1. Comparison with server_attrs / shared_attrs / params

Source	Scope	Where it's set	Who can see it
params	One RPC call	Provided by the caller	The caller
device.shared_attrs	One device	Synchronized device ↔ platform	The device's operator
device.server_attrs	One device	Device detail page on the platform	The device's operator
org_params	Whole organization	Server Configuration → Org Params	Org admin only (regular operators cannot see it)

Typical uses:

• Webhook URLs / keys for third-party bots (WeCom, DingTalk, Slack, Telegram)
• Base URLs and access keys for third-party HTTP APIs
• Tenant-wide business identifiers (BMS integrator code, carrier account, etc.)
• Constants that differ between production and staging

1.6.2. Configuration

Open System Management → Server Configuration → Org Params and maintain key-value pairs:

Field	Description
Key	Accessed in scripts as org_params.<key>. Use lowercase snake_case, e.g. wecom_webhook_url
Value	String value. For structured data, store a JSON string and JSON.parse it in script
Remark	Operator-facing note explaining what this param is for, e.g. "WeCom alarm-bot webhook, rotated quarterly"

Click Submit — new values take effect immediately for all scripts in the org (no service restart required).

1.6.3. Reading Org Params from Scripts

// RPC: read the WeCom webhook from org_params
function rpc_script({ device, params, alarms, logger, org_params }) {
    let webhook = org_params?.wecom_webhook_url;
    if (!webhook) {
        logger.error("wecom_webhook_url not configured in org_params");
        return null;
    }
    return [{
        sleepTimeMs: 0,
        type: "axios",
        dnMsg: {
            method: "POST",
            url: webhook,
            headers: { "Content-Type": "application/json" },
            data: { msgtype: "text", text: { content: params.content } },
            timeout: 5000
        }
    }];
}

1.6.4. Security Notes

• The Org Params page is only accessible to org admins — regular operators cannot see webhook keys or secrets, so it is safe to store sensitive credentials here
• If you suspect a credential has leaked: rotate it on the third-party platform, then update the value on this page; all scripts that reference the key automatically pick up the new value
• Rotate webhook URLs / access keys at least once per quarter, and record the last rotation date in the Remark field

⚠️ Do not echo org_params values back into device.server_attrs or into log messages — that defeats the whole point of hiding the secret from callers and log readers.