1. ThinkLink Introduction

ThinkLink (hereinafter referred to as TKL) is an IoT platform with native LoRaWAN support. It covers the full loop from device onboarding and data modeling to automation, alerting, and third-party integration. TKL has a built-in LoRaWAN Network Server (NS) that centrally manages LoRaWAN devices and gateways, and also ingests data from third-party systems over standard MQTT for unified modeling across heterogeneous sources.

Cloud platform: https://thinklink.manthink.cn

1.1. Deployment Forms

TKL offers an integrated "cloud–edge–device" deployment model. Pick the form that matches your scale and latency requirements:

• Cloud server (Cloud): Out-of-the-box, ideal for pilots and small-to-medium deployments.
• Edge server (TKE): Private deployment with data localization and low-latency communication; unlocks local-protocol integrations such as BACnet and Modbus TCP.
• Gateway internal (TKG): Embeds the NS directly inside the gateway for lightweight, low-cost local networking.

The same Thing Models, RPCs, and trigger logic migrate seamlessly across all three forms.

1.2. Device and Data Onboarding

• Native LoRaWAN: Built-in NS with OTAA/ABP, managing the gateway and device lifecycle in one place.
• MQTT ingestion: Onboard data from third-party systems or custom devices through the ThinkLink protocol.
• Sub-device management: Sub-devices polled by a DTU or acquisition unit over RS-485, M-Bus, etc. are managed as first-class devices, forming a hierarchical "gateway → DTU → sub-device" structure.
• Network data debugging: Live monitoring of gateway-side traffic (NS data) and post-NS output (AS data) to accelerate LoRaWAN device bring-up and troubleshooting.

1.3. Modeling and Automation

TKL turns raw frames into usable, controllable, and composable business objects through a stack of models:

• Thing Model: JS parsers transform raw LoRaWAN / MQTT payloads into structured telemetry, powering tables, charts, dashboards, and historical queries.
• RPC Model: Defines downlink commands and parameter pushes — a uniform remote-control interface; ships with system RPCs such as ALARM.
• Trigger Model: A JS script runs on every uplink, can read the latest telemetry of the current or any other device, and may invoke any RPC — enabling cross-device automation (e.g. auto-adjusting an AC based on a temperature threshold).
• Asset Model: Aggregates Thing-Model data from multiple devices into a higher-level "asset" view for cross-device analytics.
• Template: Bundles Thing Model, RPC, Trigger Model, protocol bindings, and server/shared attributes into a single preset that can be applied during device creation or bulk import.
• Scheduled Tasks: Periodically invoke RPCs for polling, inspection, or timed control.
• Alarm Model: The Trigger Model creates / clears alarms via the ALARM RPC, with low / mid / high / urgent severity levels and multi-channel notifications (email, WeCom, DingTalk, Telegram, Slack).

1.4. Visualization and Operations

• Dashboard: Custom layouts, cards configured by device + Thing Model + data points, optional RPC buttons under each card, and carousel display across multiple boards.
• Application data: Realtime and historical data views for live monitoring and retrospective analysis.
• Device / Gateway Management: Unified UI for devices, gateways, templates, upgrades, and organizations.
• Organization parameters (org_params): Tenant-level "environment variables" that parser, trigger, and alarm scripts can all read uniformly.

1.5. Third-Party Protocols and Systems

TKL bridges heterogeneous systems through template- and Thing-Model-level configuration:

• MQTT Forwarder: A JS-script-driven middleware that performs cross-broker routing, topic redirection, and payload transformation when integrating with third-party platforms.
• Protocol integrations: BACnet, Home Assistant, ThingsBoard, Modbus TCP, MCP server, and more.

[Note] BACnet and Modbus TCP integrations are available only in TKE (edge server) or TKG (gateway internal) deployments.

1.6. EdgeBus (EB)

EdgeBus is TKL's edge-side acquisition / uplink runtime, built on an event-driven, periodic-execution model:

• Query Event: Periodically sends commands to sub-devices to fetch data.
• UpAfterQueryEvent: Uploads immediately after a query, with no intermediate processing.
• LoraUp Event: Periodically sends processed data to the cloud over LoRaWAN.

EB code can be compiled and downloaded in the cloud via EB Cloud Compiler, simplifying the development and update of embedded business logic.