物联网中的 Node-RED（4）：MQTT 节点（连 Broker、订阅/发布）

物联网中的 Node-RED（4）：MQTT 节点（连 Broker、订阅/发布）

前面第09篇（系列二）讲过 MQTT 协议本身。这一篇讲 Node-RED 里怎么用它——mqtt in（订阅） 和 mqtt out（发布） 这两个节点，正是你双服务端推送、地灾平台转发的"传输主通道"。

一、是什么

• mqtt in（订阅）：连 Broker、订阅 Topic，收到消息转成 msg（msg.topic=主题，msg.payload=负载）。
• mqtt out（发布）：把 msg 发到指定 Topic（用 msg.topic 或节点固定 topic；payload 即负载）。
• 节点本身只是 MQTT 客户端，背后是你的 Broker（如 EMQX / Mosquitto，也就是双服务端架构里那个中心 Broker）。

二、怎么用

• 配连接：Server（IP:port，如 1883/8883）、Client ID、用户名密码、TLS（8883 必开）、clean session、keepalive、遗嘱 LWT（断线自动发"离线"）。
• mqtt in：填 Topic（支持 +/# 通配，如 factory/+/temp）、QoS（0/1/2）。
• mqtt out：Topic 可节点固定，或留空用 msg.topic 动态；可设 QoS / retain。
• 共用连接：多个节点配同一连接配置，避免每节点一条 TCP 连接，省资源。

三、用在哪里

• 双服务端推送：边缘 Node-RED 把清洗后的设备数据 mqtt out 推到中心 Broker，两个服务端各自 mqtt in 订阅同一 Topic 收数据（这正是"双服务端"的语义）。
• 地灾平台 P03：Node-RED 从设备侧 mqtt in 收原始上报 → 处理后 mqtt out 转发到平台订阅的 Topic。
• 下发控制：平台发指令到 cmd Topic，Node-RED mqtt in 收到 → 转串口/Modbus 下发给设备。

四、怎么能用好（避坑）

• 必走 TLS（8883）+ 鉴权：明文 1883 上公网等于裸奔。
• Client ID 唯一：重复 ID 互踢，多实例/多节点会错乱。
• 遗嘱 LWT 必配：断线自动广播"离线"，平台才知道设备掉线，否则状态滞后。
• QoS 取舍：关键数据用 QoS1（至少一次）；双服务端场景 QoS2 易重复，要配合去重。
• retain 谨慎用：保留最后一条给新订阅者，但配置类 retain 会一直顶着，错配难排查。
• Topic 设计要分层：用 device/{id}/{point}，便于 +/# 订阅与 ACL 权限控制，别 flat 命名。

五、原理

MQTT 是发布/订阅模型（系列二第09篇详述）。Node-RED 的 mqtt 节点 = MQTT 客户端，连 Broker 并维护订阅树；消息到达按 Topic 匹配分发给对应 mqtt in 节点，转成 msg 流入流；mqtt out 反之把 msg 按 topic 发布出去。底层靠 TCP 长连接 + 心跳保活。

六、背景（来龙去脉）

MQTT 1999 年 IBM 石油管道监控，2014 年成 OASIS 标准。Node-RED 内置 mqtt 节点是 IoT 集成的"主通道"，也是你双服务端架构的传输底座——没有它，边缘到中心的链路就断了一截。

误区澄清

1. "MQTT 节点 = Broker" —— 错。节点只是客户端，Broker 是独立服务（EMQX/Mosquitto），Node-RED 是连它的那一方。
2. "连上就能用，不用管断线" —— 错。要配遗嘱 + 重连 + QoS，否则断网丢数据、设备状态失真。
3. "Topic 随便起名" —— 错。分层 + 通配 + ACL 全靠命名约定，乱起名后面订阅和权限全乱套。