一、先分清三条回路：本地控制、数据采集、云端告警
不少项目把YQWSK温湿度控制器接上RS485、再通过网关送进物联网云平台之后，很快会遇到两类相反的抱怨：手机上一晚收到几十条“湿度超限”，运维人员干脆把通知静音；而另一次真正的除湿装置失效，却没有任何提示，直到巡检时才发现柜内已经凝露。
这两类问题看起来相反，根源却相同：现场其实同时运行着三条时间尺度完全不同的回路，而云端告警规则常常被当成“把控制器的阈值再抄一遍”。一旦三条回路的职责混在一起，规则就必然要么太敏感、要么太迟钝。
本文只讨论一个问题：柜内温湿度数据上云之后，告警规则应该如何与本地控制、采集周期配合，才能既不刷屏、也不漏报。文中涉及的平台功能均按项目确认，不代表统一标配。
| 回路 | 谁负责 | 典型时间尺度 | 它的目标 |
|---|---|---|---|
| 本地控制回路 | YQWSK温湿度控制器驱动YQCS除湿装置、DJR加热器 | 秒～分钟级，由控制器自身采样和回差决定 | 让柜内湿度回到安全区间；断网时也必须照常工作 |
| 数据采集回路 | RS485轮询、网关、上传链路 | 按项目设定的轮询和上报周期 | 把真实状态按可接受的延迟送到平台，并带时间戳 |
| 云端告警回路 | 平台规则、通知渠道、值班人员 | 分钟～小时级，含人的响应时间 | 只在“需要人处理”时提醒，并给出足够的判断依据 |
一个基本原则由此得出：控制器负责“把湿度拉回去”，云端告警负责“拉不回去时叫人”。云端阈值不应与本地启停值重合，云端也不应承担闭环控制职责——控制器本身不含发热或除湿元件，只负责检测并联动执行设备，它在断网时依然要独立运行。
二、为什么阈值附近会刷屏：湿度信号的三个特点
1. 相对湿度随温度变化，而柜内温度天天在波动
相对湿度是相对于当前温度下饱和水汽量的比值。柜内水汽总量没变，只要负荷电流使柜温上升几度，读数就会明显下降；夜间柜温回落，读数又会回升。所以单点湿度曲线在一天内自然呈“起伏”，并不是传感器在乱跳。
2. 加热只降相对湿度，不减少水分，停机后会回弹
DJR配电柜加热器采用PTC陶瓷发热体，通过升温降低柜内相对湿度，但水分并未离开柜体；YQCS智能除湿装置则采用帕尔贴半导体制冷，把湿气冷凝成液态水并排出，真正降低柜内含湿量。两者的差别直接体现在曲线上：只靠加热时，加热停止后湿度往往回弹，回弹再次越限，就形成“越限→加热→恢复→停止→再越限”的往复循环，云端若逐次触发告警，就是典型的刷屏。
3. 传感器位置、气流与开门扰动
传感器靠近除湿装置出风口、靠近加热器或靠近柜门缝，读数都会出现与整体柜内状态不一致的短时波动；巡检开门几十秒，也足以造成一次明显的湿度尖峰。这些波动本身并不代表柜内出现了需要处理的风险。
三、为什么又会漏报：五种常见原因
刷屏之后，很多现场的应对是“把阈值放宽”“把通知合并”“把间隔调长”。这些做法如果没有配套的判据，会直接制造漏报。下面这几种是更常见的漏报来源：
| 现象 | 常见原因 | 如何确认 |
|---|---|---|
| 柜内明显潮湿，平台没有任何告警 | 持续判定时间设得过长，或对数据先做了长周期平均，短而反复的越限被抹平 | 调出原始采样曲线，对照规则的判定窗口，看越限片段是否都短于窗口 |
| 只收到第一次告警，之后同一柜再越限没有通知 | 冷却期或“未确认不重复”策略把后续事件压住了 | 对比曲线上的多次越限与实际通知次数，确认压制规则是否生效 |
| 曲线是一条平直线，告警一直不来 | 设备实际已离线或数据被平台“沿用上一个值”，平台把缺数据当成“正常” | 核对“最后采集/最后上报/最后入库”时间；离线应单独设置告警，见本文相关阅读 |
| 现场短时高湿，平台曲线完全没有峰值 | 网关上报周期过长，或采用变化量上传时死区设置过大，峰值发生在两次上报之间 | 同时抓取控制器轮询值与网关上报值，核对采样、轮询、上报三个周期 |
| 历史曲线补出了峰值，却没有实时告警 | 断网后补传的数据已经过期；若强行参与实时规则，又会产生迟到告警 | 同时查看设备采集时间、网关接收时间和平台入库时间，明确过期数据处理规则 |
| 湿度已高，却因规则过迟而没有告警 | 云端告警值设置过高，或持续判定时间超过风险允许时间；本地控制长期无法拉回湿度，平台仍在等待 | 回看历史凝露记录与本地动作时间，分别确定关注线、告警线和最长允许持续时间 |
| 手机端没收到，平台里却有记录 | 通知渠道、账号权限或推送环节问题，与规则本身无关 | 先在平台内确认“已触发”，再单独验证通知渠道，避免把两类问题混在一起调 |
四、告警规则怎么设计：几个必须分开考虑的参数
较稳妥的做法是把“一次告警”拆成几个独立参数，逐项对应上面两类问题。下表中的数值仅为说明思路的示例，实际取值必须结合该柜的历史曲线、所用控制器型号的本地启停设置和现场风险确定。
| 参数 | 解决什么问题 | 设计要点 | 示例（仅示意） |
|---|---|---|---|
| 关注线 / 告警线分级 | 把“值得看一眼”和“必须处理”分开 | 告警线要高于本地启停值并留出余量，让本地动作先有机会起效；关注线只做记录或低打扰提示 | 关注线略高于控制器启动值；告警线再高一档 |
| 持续判定 | 过滤开门尖峰与采样噪声 | 用“连续N个采样点越限”或“持续T分钟越限”，而不是单点越限；窗口要长于典型开门扰动，又要短于风险发展时间 | 连续3个采样点，或持续10分钟 |
| 触发线 / 恢复线（回差） | 避免在阈值附近反复触发与恢复 | 恢复线明显低于触发线，且恢复也要满足持续判定，避免加热回弹造成假恢复 | 触发85%RH，恢复78%RH，恢复也需连续满足 |
| 重复提醒与冷却 | 防止同一事件不断打扰，也防止长期被压制 | 同一事件只在首次、超过一定时长未恢复时重复；恢复后计数重置，新事件重新计 | 首次提醒；未恢复每60分钟提醒一次 |
| 数据缺失告警 | 避免把“没数据”当成“没问题” | 超过若干个上报周期无新数据，独立触发“设备离线/数据中断”，与湿度告警分开 | 连续3个上报周期无数据 |
把规则写成状态机，避免“去抖”和“漏报”互相打架
只在数据库查询语句里写“湿度大于某值就发送通知”，很难正确处理持续判定、恢复、重复提醒和数据中断。更可靠的做法是让每台设备、每条规则都维护独立状态，并保存本次状态进入时间：
恢复：RH ≤ Hoff，并连续保持 Toff
必要条件：Hoff ＜ Hon
离线：当前时间－最后有效采集时间 ＞ Toffline
若上传周期稳定，可初估 Non＝ceil(Ton/Tupload)；实际系统仍应优先按时间戳累计，而不是只数报文条数。
当数据不等间隔、网络发生补传或网关批量上报时，“连续3个点”可能只覆盖几秒，也可能横跨几十分钟。因此平台应使用设备采集时间判断持续时长，同时记录网关接收时间和平台入库时间；明显晚到、乱序或超过有效期的数据可以进入历史曲线，但不应倒过来触发实时告警。
同一事件的重复提醒不能新建另一条告警。建议用“设备SN＋规则ID＋本次事件开始时间”标识事件：首次进入告警状态时推送一次；持续未恢复时按策略提醒；满足恢复条件后关闭本事件，下一次重新越限才创建新事件。这样既能限制通知数量，也不会因为一次旧告警未确认而永久压住后续故障。
用“设备动作是否生效”来区分真故障与正常起伏
湿度高本身并不一定是异常；湿度高，同时本应已经起效的除湿或加热动作没有把它拉下来，才更接近需要人工处理的情况。因此更有价值的规则是组合条件，例如：
- 湿度越过告警线，且YQCS已运行足够长时间（按该柜正常除湿速度确定），湿度仍未下降——提示除湿装置排水、热端散热、电源或安装位置可能存在问题；
- 加热器运行期间湿度下降，但停机后短时间内又回弹到触发线以上——提示需要的是除湿（去除水分），而不只是加热，应回头评估YQCS与DJR的配合；
- 湿度、柜温同时缓慢升高，但从未越过湿度阈值——提示需要关注负荷或散热，而不是靠湿度规则去发现。
是否能读取到设备的运行状态，取决于所选型号与通讯配置：带RS485的YQWSK可接入采集，但可读的是温湿度、设定参数还是负载状态，必须核对具体型号协议；YQCS的RS485与故障报警输出为选配；常规DJR加热器通常由温湿度控制器联动，其状态可通过控制回路辅助判断。具体寄存器与可读字段一律以对应说明书和通讯协议为准，本文不列举。
五、采样与保存：周期怎么选，数据量怎么算
采样周期没有通用答案，而应从“要发现的最短事件”和“系统能承受的数据量”两头倒推。柜内湿度的正常变化通常是分钟到小时级；开门尖峰是秒到几十秒级，多数情况下本来就不该触发告警。因此把湿度采样压到很短，通常只会换来更多噪声和更大的存储量，而不会多发现真正的问题。
数据量增长很容易被低估。以一个示例项目估算：200台柜、每台上传温度和湿度2个数据点、每分钟1次：
| 项目 | 计算 | 结果 |
|---|---|---|
| 每日数据点 | 200 × 2 × 1440 | 576,000 个 |
| 每年数据点 | 576,000 × 365 | 约 2.1 亿个 |
| 若改为每10秒1次 | 200 × 2 × 8640 | 每日约 345.6 万个数据点 |
这是数据点数量，不等于数据库行数：如果一次报文把温度和湿度写入同一行，实际行数可能减半；若还保存质量码、设备状态、索引和审计字段，占用空间又会增加。因此云平台侧通常需要在项目阶段确定分层保留策略：较短时间保留原始明细，较长时间只保留按固定周期聚合的平均、最大、最小值。这样既能在事后回看开门尖峰，也不会让历史曲线查询越来越慢。平台的数据库类型、存储与保留方案均按项目确认。
六、YQWSK、YQCS、DJR 在方案中的分工
| 设备 | 在监控方案中的角色 | 选型与确认要点 |
|---|---|---|
| YQWSK温湿度控制器 | 检测柜内温湿度，按本地设定联动除湿装置和加热器；带RS485的型号按实际协议向采集链路提供数据 | 需要上云的项目应选用带RS485的型号，并在下单时确认通讯字段与安装方式；按钮款参数固定、拨盘款调节范围受产品结构限制，需要现场灵活设置时优先核对数码管或液晶款 |
| YQCS智能除湿装置 | 帕尔贴半导体制冷排水，真正去除柜内水分；是“拉不回去”类告警最需要观察的设备 | RS485与故障报警输出均为选配，需在订货时明确；按柜体空间选择功率与材质 |
| DJR配电柜加热器 | PTC升温降低相对湿度，辅助防凝露，需配温湿度控制器启停 | 本身不含通讯，其状态通过控制器体现；与YQCS搭配时，两者分工要在规则里体现 |
| 物联网云平台 / 微信小程序 / APP | 集中显示、历史曲线、告警推送与权限管理 | 能力、通讯方式、部署方式与收费均按项目确认，是否包含某项功能以项目方案为准 |
七、按什么顺序调：一周试运行流程
- 先固定本地控制。确认每台YQWSK的本地启停值与回差已按所用型号说明书设置，且断网时能独立工作。不要为了让告警变少而放宽本地保护参数。
- 只记录、不告警运行3～7天。让平台只保留原始曲线，不推送通知，统计每台柜的日波动范围、开门尖峰出现时间以及除湿装置一次动作后湿度下降的典型速度。
- 用历史曲线回放规则。把拟定的关注线、告警线、持续判定和回差应用到这几天的曲线上，数一数每台柜每天会产生多少事件。如果单柜单日事件数很多，说明阈值或判定窗口不合理，而不是“告警灵敏”。
- 加入组合条件与数据缺失告警。加入“除湿动作后未下降”“停止加热后回弹”等规则，并单独设置数据中断告警。
- 小范围开通通知，再逐步扩大。先在少数关键柜开启通知，运行一周，统计每条告警是否对应到一次有意义的处理动作，再放大范围。
验收时建议检查的几项
- 同一台柜同一事件，从越限到恢复只产生一次“触发”和一次“恢复”；
- 人为断开该柜上报（在允许的条件下），数据中断告警能在设定的周期内触发，而不是显示为“正常”；
- 每条告警内容至少包含：柜号、当前温湿度、越限起始时间、除湿/加热设备当前状态；
- 运维人员能说明每类告警对应的处理动作，没有“看到了但不知道该干什么”的规则；
- 断网时，本地除湿与加热仍能按控制器设定工作，恢复网络后历史数据的补传方式已明确（是否支持补传取决于网关与平台方案）。
⚠️ 使用边界：云端告警只是提醒手段，不能替代本地控制，也不能替代现场检修。柜内接线、传感器位置调整、除湿装置排水与热端检查等工作，均应在停电条件下由具备资质的人员完成。本文所有数值均为示例，具体阈值、周期与保留策略必须结合现场数据与产品说明书确定。
💡 一句话小结：不要用同一个阈值同时承担“控制”和“告警”两件事。控制器负责拉回湿度，云端负责在拉不回去时叫人；把它们的阈值错开、加上回差与持续判定，并对“没有数据”单独告警，刷屏和漏报会同时减少。
需要为配电柜设计温湿度监控与告警方案？
提供柜体类型、数量、通讯方式和是否需要云平台，我们的工程师帮您确认YQWSK、YQCS、DJR的配置与远程监控方案。
在线询价 销售热线 15888772322 技术热线 17276078653本文由温州益旗电气有限公司原创发布，转载请注明出处： yqelect.com