以太网温湿度传感器心跳包设计：平台在线状态检测与离线告警

以太网温湿度传感器心跳包设计：平台在线状态检测与离线告警

物联网 · 数据中心 · 环境监控 · 盛世宏博

以太网温湿度传感器接进平台后，有个问题经常被忽略：传感器掉线了，平台怎么知道？如果只看"最后一次数据时间"，网络抖动一次就误报；如果不检测，传感器断电了平台还显示几个小时前的旧数据，管理员以为一切正常，实际已经盲了。解决办法是设计心跳包机制。本文讲怎么给以太网传感器做心跳和离线告警。

心跳检测

图1：传感器心跳与在线状态

一、为什么需要心跳

纯Modbus TCP轮询模式下，平台主动读传感器。传感器断电、网线拔了、交换机故障，平台读的时候超时，能知道离线。但问题：平台轮询周期30秒，发现离线要等好几轮；而且如果平台自己重启或网络闪断，容易误判。

心跳是传感器主动上报：每隔固定时间传感器发一个小包给平台，平台收到就知道它活着。比被动轮询更及时，也能区分"传感器真离线"和"网络临时抖动"。

二、心跳包内容

心跳不用复杂，一个UDP或TCP小包就行，包含：设备ID、固件版本、当前温湿度、电池/供电状态、时间戳。传感器每30到60秒发一次。

// 心跳包示例（JSON over UDP）
{
  "id": "TH-rack01-u12",
  "fw": "v2.3.1",
  "t": 23.5,
  "h": 48.2,
  "pow": "poe",
  "ts": 1729500000
}

温湿度数据顺便在心跳里带了，平台不用再轮询拿数据，一举两得。

三、平台侧离线判断

平台维护每个传感器的最后心跳时间。判断逻辑：

# 平台离线判断
last_seen = db.get_last_heartbeat(device_id)
now = time.time()

if now - last_seen > 3 * heartbeat_interval:
    # 连续3个心跳周期没收到，判离线
    alarm.push(device_id, "传感器离线")
elif now - last_seen > heartbeat_interval:
    # 1个周期没收到，标记"可疑"但不报警
    db.mark_suspicious(device_id)

关键是"连续3个周期没收到"才报警——避免网络抖动一次就误报。心跳间隔30秒，就是90秒内没收到才报离线。

在线状态

图2：在线状态监控

四、UDP还是TCP

心跳用UDP更轻量：传感器不用维持长连接，发完就完。缺点是UDP包可能丢，但心跳本来就有重试机制，丢一个包不影响。对可靠性要求高的场合用TCP长连接，传感器和平台保持连接，断开TCP就知道离线。

PoE供电的工业传感器一般用UDP心跳，简单省电。

五、离线告警分级

传感器离线本身是个故障，但影响程度要看位置：

• 核心机房主测点离线——立即告警，派运维检查。
• 辅助测点离线——工作时间通知，下次巡检看。
• 批量传感器同时离线——大概率交换机或网络故障，紧急告警。

批量离线这个判断很重要：一个传感器离线是设备问题，一整排离线是网络问题，处理方式完全不同。

六、心跳与数据上报分离

设计时把心跳和数据上报分开：心跳包只带状态，数据上报可以按更长周期（比如1分钟）发一次完整数据。或者心跳里就带最新数据，省一个通道。后者更简单，推荐。

告警平台

图3：离线告警监控

七、时间同步

心跳包里的时间戳要准。传感器一般靠NTP对时，平台启动时下发时间。时间不准会导致"最后心跳时间"判断错乱，离线报警延迟或误报。部署时确保传感器能访问NTP服务器，或者平台定期对时。

八、结语

以太网温湿度传感器的心跳包设计，是保证监控系统"真的在看"的关键。传感器定时上报小包，平台按最后心跳时间判断在线/离线，连续3个周期没收到才报警。UDP轻量、TCP可靠，按场景选。批量离线要识别为网络故障。把心跳做扎实，管理员才能相信平台上的数据是活的，不是僵尸数据。

关键词 / 标签：以太网温湿度传感器 · 心跳包 · 在线状态 · 离线告警 · 物联网 · 盛世宏博