边缘侧阈值联动逻辑：不依赖云端，在以太网温湿度变送器上实现本地告警输出

边缘侧阈值联动逻辑：不依赖云端，在以太网温湿度变送器上实现本地告警输出

在前几篇中，我们解决了“数据怎么采、怎么传、怎么存”的问题。但在智慧档案馆、冷库、机房等场景中，还有一个更严苛的需求：

当温湿度越限时，系统必须在秒级内响应（如启动除湿机、关闭风阀），而不能等待云端指令。

如果依赖云端决策，链路上的任何抖动（网络延迟、云端服务重启）都可能导致灾难性后果。因此，边缘侧本地联动是以太网温湿度变送器必须具备的“保底”能力。

本文将聚焦如何在资源受限的 MCU 上，设计一套不依赖云端、高可靠、可配置的本地阈值联动逻辑。

一、为什么必须做边缘侧联动？

1. 网络不可靠是常态

• 交换机重启、POE 供电波动、光纤中断，都可能导致设备“离线”；
• 云端服务升级、容器迁移，可能导致 API 短暂不可用。

2. 云端时延不可控

• 数据上云：设备 → 网关 → 平台 → 规则引擎 → 下发指令 → 设备，全链路时延通常在 1～5 秒；
• 对于精密库房，几秒钟的温湿度失控可能损坏珍贵档案或疫苗。

3. 合规与审计要求

• GSP（药品经营质量管理规范）、档案馆“十防”要求中明确强调现场就地控制能力；
• 审计时，需要证明即使断网，系统依然具备自主保护能力。

结论：云端用于“管理与分析”，边缘用于“生存与保护”。

二、边缘联动的核心架构：事件驱动模型

在变送器固件中，我们设计一个轻量级的边缘规则引擎，其核心是“采样 → 判断 → 执行 → 回执”的事件驱动模型。

1. 逻辑架构图

[温湿度传感器] 
          │
          ▼
    [ADC + 数字滤波] → [环境数据缓存区] (双缓冲，前文已述)
          │
          ▼
    ┌─────────────────┐
    │  阈值判断引擎   │ ←─── [阈值配置表] (Flash中)
    │ (周期扫描/中断) │
    └─────────────────┘
          │
          ├── 正常 ──→ [更新状态字] ──→ [继续采样]
          │
          └── 越限 ──→ [触发联动动作] ──→ [告警输出]
                            │
                            ├──→ [继电器干接点闭合]
                            ├──→ [蜂鸣器鸣叫]
                            ├──→ [LED 闪烁]
                            └──→ [主动上报 Trap/MQTT]

三、阈值配置模型：从“单值”到“逻辑组”

简单的“高于 30℃ 报警”无法满足复杂场景。我们需要定义一套结构化配置模型，存储在 MCU 的 Flash 中。

1. 基础阈值（Primary Thresholds）

• 上限（High Limit）：如温度 > 24℃
• 下限（Low Limit）：如温度 < 14℃
• 回差（Hysteresis）：防止在临界点抖动。
  • 例：上限 24℃，回差 1℃。触发条件：>24℃；解除条件：<23℃。

2. 高级逻辑（逻辑与/或）

支持多条件组合，这是边缘联动的精髓。

• AND 逻辑：温度 > 24℃ 且​ 湿度 > 60% → 触发除湿机。
• OR 逻辑：温度 > 30℃ 或​ 湿度 < 20% → 触发告警。

3. 持续时间（Persistence/Delay）

防止瞬时干扰误触发。

• 触发延时：条件满足持续 N 秒后才确认告警（如 10s）。
• 恢复延时：条件解除持续 N 秒后才确认恢复（如 30s）。

4. 联动动作配置表

每个规则对应一组动作：

四、固件实现：状态机与消抖算法

1. 阈值判断状态机（以温度过高为例）

// 伪代码
typedef enum {
    STATE_NORMAL,
    STATE_TRIGGER_DELAY,
    STATE_ALARM,
    STATE_RECOVER_DELAY
} alarm_state_t;

alarm_state_t temp_state = STATE_NORMAL;
uint32_t trigger_timer = 0;
uint32_t recover_timer = 0;

void check_temperature_alarm(float temp) {
    switch (temp_state) {
        case STATE_NORMAL:
            if (temp > HIGH_LIMIT) {
                temp_state = STATE_TRIGGER_DELAY;
                trigger_timer = get_tick(); // 启动计时
            }
            break;
        case STATE_TRIGGER_DELAY:
            if (temp < HIGH_LIMIT - HYSTERESIS) {
                // 未到时间就恢复了，回到正常
                temp_state = STATE_NORMAL;
            } else if (get_tick() - trigger_timer > TRIGGER_DELAY_MS) {
                // 持续越限，确认告警
                temp_state = STATE_ALARM;
                execute_actions(ACTION_RELAY_ON | ACTION_TRAP_SEND);
            }
            break;
        case STATE_ALARM:
            if (temp < HIGH_LIMIT - HYSTERESIS) {
                temp_state = STATE_RECOVER_DELAY;
                recover_timer = get_tick();
            }
            break;
        case STATE_RECOVER_DELAY:
            if (temp > HIGH_LIMIT) {
                // 恢复期间又超限，回到告警态
                temp_state = STATE_ALARM;
            } else if (get_tick() - recover_timer > RECOVER_DELAY_MS) {
                // 确认恢复
                temp_state = STATE_NORMAL;
                execute_actions(ACTION_RELAY_OFF);
            }
            break;
    }
}

2. 联动执行器（Executor）

执行器模块负责将逻辑动作转化为硬件操作。

• 继电器安全设计：
  • 上电默认状态：继电器默认断开（NC 或开路），防止上电误动作。
  • 看门狗保护：如果 MCU 死机，看门狗复位，继电器回到安全状态。
  • 自锁逻辑：某些场景（如消防）需要自锁，需手动复位。

3. 本地告警输出接口

• 干接点（Dry Contact）：最通用的方式。变送器提供无源开关量（COM, NO, NC），直接接入空调、除湿机、声光报警器的控制回路。无需共地，抗干扰强。
• 有源电平：12V/24V 高低电平，驱动简单，但需注意共地干扰。
• 蜂鸣器与 LED：用于就地提示。建议支持静音按钮（就地消音，但继电器保持吸合）。

五、边缘联动与云端协同机制

边缘联动不是“孤岛”，它必须与云端协同工作。

1. 配置下发

• 云端（平台/APP）通过 Modbus TCP​ 或 MQTT​ 下发阈值配置到设备 Flash；
• 设备重启或实时生效（需考虑临界区保护）；
• 设备回复 ACK，确认配置成功。

2. 状态同步

• 设备本地状态变化（Normal → Alarm）时，立即通过 SNMP Trap​ 或 MQTT​ 上报；
• 云端数据库更新设备状态，触发短信/APP 推送；
• 即使网络断开，设备依然按本地逻辑执行；网络恢复后，补报离线期间的告警事件（利用前文提到的环形存储）。

3. 优先级策略

• 边缘逻辑优先：只要本地条件满足，立即执行继电器动作，不受云端指令影响。
• 云端干预：云端可发送“强制复位”或“强制动作”指令（需鉴权），用于远程调试或紧急处置。

六、典型应用场景配置示例

场景 1：档案馆库房防霉（除湿联动）

• 条件：湿度 > 60% RH 持续 5 分钟。
• 动作：继电器闭合 → 启动除湿机。
• 恢复：湿度 < 55% RH 持续 10 分钟 → 继电器断开 → 停止除湿机。
• 上报：SNMP Trap 通知平台。

场景 2：机房高温保护（空调联动）

• 条件：温度 > 28℃ 持续 30 秒。
• 动作：继电器闭合 → 启动备用空调；LED 红色快闪；蜂鸣器间歇鸣叫。
• 恢复：温度 < 25℃ 持续 2 分钟 → 停止空调；LED 恢复绿色慢闪。
• 上报：MQTT 紧急消息。

场景 3：冷库门未关（温湿度突变）

• 条件：温度上升速率 > 1℃/分钟 且​ 湿度 > 80% RH。
• 动作：蜂鸣器长鸣；本地红灯常亮。
• 目的：提醒现场人员关门，无需启动设备。

七、落地难点与工程经验

难点 1：传感器漂移导致误联动

• 现象：传感器老化，长期偏高 0.5℃，导致频繁误触发。
• 对策：
  • 支持现场一键校准（Offset 修正）；
  • 云端大数据分析，识别漂移趋势，提醒更换传感器；
  • 联动逻辑中增加软件滤波（如滑动平均），平滑瞬时波动。

难点 2：继电器频繁动作损坏设备

• 现象：温湿度在临界点反复横跳，导致除湿机频繁启停。
• 对策：
  • 加大回差（Hysteresis）：如 24℃ 开，22℃ 关；
  • 最小动作间隔：设定继电器两次动作之间的最小时间间隔（如 5 分钟），防止机械磨损。

难点 3：配置冲突

• 现象：云端下发新配置，与本地正在执行的联动逻辑冲突。
• 对策：
  • 配置下发时，若设备处于 Alarm 状态，新配置不立即生效，待恢复 Normal 后再加载；
  • 或云端下发“强制覆盖”指令，设备立即按新逻辑执行（需确认风险）。

八、小结

在以太网温湿度变送器中实现边缘侧阈值联动，本质上是将“感知”与“控制”在物理空间上合二为一。

设计 Checklist：

• [ ] 是否支持上下限、回差、延时配置？
• [ ] 是否支持多条件逻辑（AND/OR）？
• [ ] 继电器输出是否为无源干接点？
• [ ] 上电及死机时，继电器是否处于安全状态？
• [ ] 本地联动是否独立于网络连接？
• [ ] 联动事件是否支持主动上报与历史补传？

💡 核心思想：云端负责“智慧”（策略优化、大数据分析），边缘负责“本能”（秒级响应、保底防护）。

这种架构确保了智慧档案馆在面临网络风暴或云端故障时，依然能像“植物人”一样维持最基本的生命体征——保持环境安全。