Alarm management is a critical component of large-scale IoT systems, especially in LoRaWAN deployments where devices are widely distributed and operate unattended. ThinkLink provides a flexible alarm notification mechanism built on its native RPC framework and trigger linkage models. By implementing alarm logic entirely at the platform level, users can configure, adjust, and scale alarm rules without modifying device firmware. This article explains the alarm implementation principles, data processing flow, and configuration process in ThinkLink, and highlights the role of the TKL + EB architecture in LoRaWAN retrofit projects.
1. Overview of ThinkLink Alarm Notification
ThinkLink’s alarm notification feature is implemented using its built-in RPC (Remote Procedure Call) mechanism.
Alarm logic is encapsulated within trigger linkage models, which evaluate incoming telemetry data in real time and determine whether alarm conditions are triggered or cleared.
ThinkLink provides a default ALARM RPC implementation covering the full alarm lifecycle and notification delivery. Users may customize this behavior to meet specific operational requirements without changing device-side code.
2. Core Mechanism: RPC and Alarm Data Flow
2.1 ALARM RPC Message Type
Alarm functionality is realized through the alarm RPC method.
This RPC delivers alarm events to the platform’s alarm processing module, including:
- Trigger or clear actions
- Alarm identifiers
- Severity levels
- Alarm descriptions
- Notification groups
Once received, the platform executes configured notification actions such as email alerts or external system integrations.
2.2 Alarm Processing Flow
Alarm triggering in ThinkLink follows a complete processing chain.
Telemetry data is uploaded by the device
The platform parses data using the Thing Model
The associated trigger linkage model is executed
Conditions are evaluated and the ALARM RPC is invoked
This architecture fully decouples alarm logic from hardware, enabling flexible and maintainable alarm strategies.
3. Alarm Configuration Workflow
3.1 Trigger Linkage Model Creation
All alarm logic is defined in a trigger linkage model using JavaScript.
Recommended practices include:
- Storing alarm thresholds and notification groups in device Server Attributes
- Adjusting alarm behavior by modifying attributes instead of scripts
- Explicitly invoking the alarm RPC method
This approach supports centralized management and large-scale deployments.
3.2 Rule Binding and Deployment
After creating the trigger linkage model, it must be bound to an ALARM rule and deployed to the target object.
Supported targets include devices, assets, and sub-devices.
Once deployed, every telemetry update automatically triggers script execution and alarm evaluation.
ThinkLink + EB for LoRaWAN Retrofit Projects
The ThinkLink and EB combined architecture redefines the role of LoRaWAN in legacy system retrofit projects.
It enables hardware-first deployment, software logic added later, and continuous remote iteration.
For system integrators without deep protocol or platform development expertise, this model provides a practical and scalable path to standardized IoT project delivery.
Cooperation and Support
ThinkLink supports rapid integration of traditional devices into LoRaWAN networks.
Free technical support and integration assistance
No platform access fees
Only device samples and documentation are required
ThinkLink platform access:
https://thinklink.manthink.cn