1. Server Configuration

1.1. BACnet

attention: The BACnet Service function can only be used on independently deployed TKE/TKG 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.1.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.1.2. Server Configuration

For to successfully run TKL as a BACnet server, you need to configure the following core parameters in the system. Service parameters are under System Management → Server Configuration → BACnet; point tables are maintained separately under Maintenance → BACnet.

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.

Since 2.00.077, BACnet is built into the platform. After the system administrator allows BACnet under System Platform → System Config → Organization Service Permissions, enter the organization's settings here, click Submit, then Restart. Global disable stops the service and blocks configuration and point-table operations; allowing it again does not start it automatically. Point-table writes synchronize a running service without an Apply Point Table action. Only one organization's BACnet service can run per process; starting another stops the previous instance. See BACnet and 2.00.079 Upgrade Notes.

The values below are configuration references, not guaranteed defaults in a new form. Read existing settings and confirm them with the BMS integrator.

Item	Description	Reference 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	Use the assigned vendor identifier	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	This setting does not enable segmented transfers in the current version. Confirm communication compatibility with the BMS integrator.	Check the actual form	Commissioning required

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.2. 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.2.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.2.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.3. 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.3.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.

The global Modbus permission is also controlled in System Config. Disabling it stops the service and blocks starts and recovery while preserving configuration and register mappings. After allowing it again, click Restart manually.

1.3.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.4. 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.4.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.4.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.4.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.4.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.