AN-26091401 使用电子邮件通知告警

本文以温度监测为例，说明如何配置 ThinkLink，在温度达到 30℃ 时发送告警邮件，恢复到 30℃ 以下时发送恢复通知。

1. 工作流程与准备

设备上报 → 物模型解析 → 联动模型判断 → ALARM RPC
                                         ├─ 创建或清除告警记录
                                         └─ 邮件通知组 → SMTP → 收件人邮箱

开始前，请确认设备已接入 ThinkLink 并正常上报；物模型已将温度解析为数值字段。本文使用 temperature，实际字段若为 TP，需修改脚本。准备好发件邮箱的 SMTP 参数、测试收件邮箱，以及通知组、设备和模型的配置权限。SMTP 由系统管理员配置。

本例针对收到的有效温度数据做阈值判断，不作为设备离线检测规则。

2. 配置 SMTP 发件服务

进入 系统平台 → 系统配置 → SMTP 服务器配置，填写邮箱服务商提供的参数。

字段	填写说明
host	SMTP 服务器地址
port	SMTP 端口，按服务商要求填写
secure	与端口及服务商要求匹配；465 通常开启，587 通常使用 STARTTLS，初始连接的 secure 通常关闭
user	发件邮箱的登录用户名
pass	邮箱密码或 SMTP 授权码，以服务商要求为准

填写后点击 提交。SMTP 是整个部署共用的发件服务；使用已配置邮件服务的平台时，由管理员确认其可用即可。不要将发件密码写入联动脚本。

详细说明见系统配置。

3. 创建邮件通知组

进入 告警管理 → 通知组 → 新增，按以下示例填写：

字段	示例或操作
Id Name	ops-email
名称	ops-email
启用	开启
通知方式	email
联系人	实际接收告警的邮箱，可配置多个
备注	温度告警邮件通知

本例将 Id Name 和名称均设为 ops-email，脚本也使用同一值，避免混淆。

新增通知组默认未启用，保存前务必打开 启用。保存成功后，仍需通过后续告警测试确认邮件送达。

字段说明见通知组。

4. 为设备挂载 ALARM RPC

进入 运维管理 → 设备管理 → 目标设备 → 详情 → RPC → 新增，选择内置 ALARM RPC 并保存，确认其 Method 为小写 alarm。

ALARM RPC 负责创建、清除告警，并向指定通知组分发通知，无需修改其内置脚本。

5. 创建并挂载联动模型

在 模型管理 → 联动模型 中新建模型，名称可设为“温度告警邮件通知”。

将以下代码直接粘贴到脚本编辑器。代码是完整的函数体，无需再添加 function trigger_script(...) 包装。

const threshold = 30;
const notify = ["ops-email"];
const temperature = device?.telemetry_data?.[thingModelId]?.temperature;

// 缺失、字符串或非有限数值不产生告警，也不清除已有告警。
if (!Number.isFinite(temperature)) return null;

const isAlarm = temperature >= threshold;

return {
  delayms: 0,
  abort_previous_timer: true,
  should_dispatch: true,
  actions: [{
    method: "alarm",
    params: {
      _eui: device.eui,
      name: "high_temperature_email",
      action: isAlarm ? "new" : "clear",
      title: "[" + device.name + "] 温度超限",
      level: "high",
      desc: isAlarm
        ? "温度达到或超过 " + threshold + "℃，请检查设备。"
        : "温度已恢复到 " + threshold + "℃ 以下。",
      notify: notify
    }
  }]
};

根据实际设备调整以下内容：

内容	调整方法
告警阈值	将 threshold = 30 改为需要的温度
温度字段	将最后一级 .temperature 改为实际物模型字段，如 .TP
通知组	修改 ["ops-email"]；多个组可写为 ["ops-email", "duty-email"]
告警名称	high_temperature_email 是固定标识，产生和清除必须使用同一名称

保存后将联动模型挂载到目标设备，确认对应物模型的温度数据可供脚本读取。仅创建模型或设置物模型约束，不等于完成设备挂载。

当前 ALARM 使用 params.notify 接收字符串数组，内部再转换为 notice_groups。请保持示例结构，不要使用旧版 group 参数，也不要将数组写成字符串。

should_dispatch: true 使相同数据也可调用 RPC，重复告警仍由 ALARM 自身判断。通知功能不要求额外配置 MQTT 转发或设备无线下行。

如需让多台设备共用脚本，可将阈值和通知组存入设备服务端属性，并分别读取 device.server_attrs.alarm_temp 和 device.server_attrs.notify；必须先确认阈值是数字、通知组是实际的字符串数组，再启用该写法。本例直接在脚本顶部配置，便于首次验证。

契约说明见联动模型和RPC 模型。

6. 验证告警与恢复通知

使用测试设备和测试收件邮箱，让设备依次上报以下温度，并检查 告警管理 → 最新告警、告警日志和收件邮箱。

顺序	温度	预期结果
1	25℃	初始无活动告警时，不产生告警或恢复通知
2	31℃	产生温度告警，并收到告警邮件
3	35℃	同一告警持续存在，不重复通知
4	29℃	清除温度告警，并收到恢复通知
5	28℃	持续正常，不重复发送恢复通知
6	31℃	再次产生告警，并收到新的告警邮件

本例使用固定告警名称、标题、等级和异常描述，确保重复上报时 ALARM 可以识别同一告警。不要在标题、描述中加入每次变化的温度或时间戳，否则可能导致持续异常期间重复通知。实际邮件样式以部署版本和收件端为准。

自动恢复依赖设备再次上报有效的正常值。设备停止上报、温度字段缺失或值不是有效数字时，脚本不会清除已有告警。告警在阈值附近反复产生与恢复时，应按实际业务另行设计滞回或持续时间条件。

7. 常见问题

现象	排查方法
温度超限但没有告警	检查遥测字段名称和数值类型、联动模型挂载，以及 ALARM RPC 是否已绑定
有告警但收不到邮件	检查通知组是否启用、联系人邮箱、notify 数组，以及 SMTP 参数和服务器网络连接
邮件发送报错	结合执行日志核对认证失败、连接超时或收件地址错误，并检查邮箱服务商的发送限制
没有报错但邮箱未收到	检查垃圾邮件、企业邮箱隔离区及邮件服务商的投递记录
持续收到相似告警	检查标题、描述或等级是否随上报变化，以及温度是否反复跨越阈值
温度恢复但告警未清除	确认平台收到新的正常温度，脚本返回 clear，且告警 name 未改变

告警日志的 全部已读 只改变阅读状态，不代表设备已恢复、告警已清除或邮件已送达。更多生命周期说明见告警管理。