1. 课程导入与场景认知

在农业物联网项目中，传感器、控制器、网关和摄像头一旦"失联"，后果往往不是一条报错日志那么简单：大棚里的温度数据停止上传，可能意味着通风设备无法自动启动；鱼塘的溶氧仪离线两小时，可能意味着一整塘鱼虾面临缺氧风险。设备离线告警系统要解决的，正是"设备还在不在、数据还可不可信、异常该找谁"这三个基本问题。本课程围绕一套可落地的离线告警系统展开，从业务场景、架构设计、心跳机制、告警判定、通知渠道到运维复盘，逐步构建完整能力。

一、为什么离线告警是农业物联网的"底线能力"

农业物联网与工业物联网有一个显著差异：现场环境恶劣、网络条件不稳定、运维人员往往不在现场。大田依靠 4G/NB-IoT 回传，温室依赖园区 Wi-Fi 或网线，畜牧场舍内金属结构多、信号遮挡严重，水产养殖区常年高湿高盐雾。设备离线的原因可能是断电、SIM 卡欠费、网关死机、天线进水、基站覆盖变化，也可能是设备本身故障。若没有离线告警，这些情况通常要等到"数据曲线断了很久"或"作物已经出问题"才被发现。

离线告警的业务价值可以归纳为三层：数据可信层——只有确认设备在线，采集到的温湿度、土壤墒情、溶氧、氨氮等数据才具备决策价值；生产安全层——离线往往先于设备故障或环境失控出现，是提前干预的信号；运维效率层——把"人找故障"变成"故障找人"，减少无效巡检。需要强调的是，离线告警不是"设备一断网就疯狂打电话"，而是要在灵敏度与误报率之间取得平衡，这正是后续章节要解决的核心工程问题。

二、四类典型场景与离线判定的差异

不同农业场景对"离线多久算异常"的容忍度差别很大，这直接决定了心跳周期与告警阈值的设定。下表给出的是教学示例中的合理假设参数，实际项目需结合设备功耗、网络成本和业务风险重新标定。

可以看到，水产与温室对时效性要求最高，而大田可以容忍更长的判定窗口以节省功耗。这种差异不是随意设定的，而是由"离线造成的后果出现速度"倒推出来的。课程后续会讲如何用心跳周期 × 允许丢失次数的方式把阈值参数化，而不是把数字写死在代码里。

三、系统整体架构：从设备到人的五段链路

一套完整的离线告警系统，本质是一条"设备状态 → 平台判定 → 告警生成 → 通知触达 → 处置闭环"的信号链。下图展示了本课程采用的总体架构，也是后续各章节的学习地图：每一层都对应一组具体的技术任务。

这张图有两个用途。第一，它说明了离线告警不是单一功能，而是一条跨设备、平台、通知和运维的链路，任何一段缺失都会导致"告警不响"或"响了没人管"。第二，它同时是学习地图：后续章节会依次深入心跳协议设计、设备注册与数据接入、在线状态机与超时判定、告警分级与通知路由、工单与复盘，最后通过综合案例把各段串起来。

四、几个容易混淆的基础概念

在进入具体实现前，需要先厘清三组概念，它们会贯穿整个课程。离线与故障不是一回事：离线指平台在约定时间内没有收到设备有效数据，故障指设备自检或业务指标异常；设备可能在线但传感器已损坏，也可能离线但设备本身完好（如基站临时中断）。心跳与业务数据要分开看：心跳是轻量的"我还活着"信号，业务数据是测量值；有些低功耗设备只在有数据变化时上报，此时需要专门的心跳报文来支撑在线判定。告警与通知要解耦：告警是平台内部产生的一条事件记录，通知是把事件送达人的动作；同一条告警可以只记录不通知（如夜间低等级设备），也可以多次通知（如升级催办）。

五、从场景到参数的初步推演

以一个温室项目为例做一次简单推演（示例假设）：棚内温湿度传感器每 60 秒上报一次，网关通过园区 Wi-Fi 接入平台。若把离线阈值设为"连续 5 分钟无数据"，则允许连续丢失 4 个周期，既能过滤偶发的 Wi-Fi 抖动，又能在 5 分钟内发现真实断连。若该温室夏季高温时段风险高，可对温度通道单独设置更短的阈值，例如 3 分钟，并对责任人启用电话通知；而土壤墒情这类变化缓慢的数据，阈值可放宽到 30 分钟并只用微信通知。这种"按数据风险分级"的思路，比全系统统一阈值更符合农业现场实际。

需要提醒的是，阈值不是越小越好。阈值过小会把网络抖动、设备休眠唤醒、平台短时拥堵都判成离线，造成大量误报，运维人员很快会对告警"脱敏"，真正的事故反而被忽略。课程后续会介绍用历史离线事件统计来校准阈值的方法，让参数有据可依，而不是凭感觉设定。

六、本课程的学习方法与预期产出

学习本课程建议采用"边学边搭"的方式：每学完一个模块，就在自己的测试环境中补上对应的一段链路。例如学完心跳协议后，先用 MQTT 客户端模拟一台设备定时发布心跳；学完判定逻辑后，手动停掉模拟设备，观察平台是否在预期时间内产生告警；学完通知模块后，配置一个测试接收人，验证短信或微信是否真正送达。这样到课程结束时，你手上会有一套可运行的最小系统，而不是一堆零散知识点。