问一个 PLC 销售员关于 MQTT，你会得到一张路线图："明年，也许，在高端型号上。" 然后你查看小字，发现一个网关、一个转换器或一个隐藏在功能背后的云订阅。xLogic 以太网 CPU 上的 MQTT 支持没有这些——自 1.04 修订版以来，它一直在固件中，并且直接从控制器发布。
这改变了预算机器的功能，大多数集成商并没有注意到。
为什么选择 MQTTMicro PLC
MQTT 正是为这种情况而构建的：在不可靠网络上的设备，向代理发布小消息，订阅者时来时去。工厂中的一台机器、田野中的泵站、距离办公室两小时的温室——每个设备都发布其状态；云仪表板、手机应用和工程师的笔记本电脑都订阅同一主题。没有轮询，没有开放端口进入工厂，没有 SCADA 服务器看护连接。
代理处理混乱。PLC 只需发布。
你实际配置的内容
连接块存在于程序中：设置代理地址、主题、发布间隔，并映射哪些值进入有效负载。CPU 处理连接生命周期——在掉线后重新连接，在间隔后重新发布——这是手动实现中最麻烦的部分。
将其与 Web 服务器和报警短信配对，你就有了一个控制器上的三个独立远程通道。办公室的云仪表板、操作员的浏览器页面、值班工程师的短信。根据受众选择你的通道。
真实案例：远程温室监控
一个拥有四个区域的温室希望在不重建现场网络的情况下实现云可见性；每个区域控制器将温度、湿度和阀门状态发布到租用的 VPS 上；一个简单的仪表板订阅并在一个屏幕上显示所有四个区域。当互联网在一个下午中断时，控制器继续发布到本地队列，值在重新连接时赶上。
种植者的总结，翻译自热情的表达："我在度假时通过手机查看温度图。这比亲自到场更好。"
MQTT 是错误答案的地方
诚实面对限制。MQTT 是事件和遥测导向的——它不是一个确定性的控制循环。如果你需要保证交付和毫秒级响应，使用本地的 Modbus TCP。MQTT 用于监督和报告，而不是用于安全联锁。这样设计，它将为你服务多年。
并保持代理凭据的准确性。发布到公共主题的 PLC 就像是在广播其业务。私有主题、本地代理，或者至少在代理上使用 TLS——设置成本只需几分钟，避免的尴尬是真实的。
值得借鉴的模式
可扩展的主题设计
MQTT 只有在你的主题结构干净时才干净，而主题结构是小项目悄然变得不可管理的地方。幼稚的方法——每个设备一个主题，一个有效负载包含所有内容——适用于一台机器，但在十台时崩溃。每个订阅者重新解析每个有效负载，每次对有效负载的更改都会破坏每个仪表板，调试变成逐个主题的追踪。
在第一次发布之前设计层次结构。一个对我很有效的模式：站点/设备/类别/值。所以plant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level。通配符订阅者——plant1 的仪表板、pump1 的页面、所有内容的报警监听器——各自订阅他们所需的切片。新设备插入而不触及旧主题，有效负载保持小且类型化。
保持有效负载简单：一个值和一个时间戳。除非你确实需要，否则不要嵌套包含十一个字段的 JSON 块。简单的有效负载是可调试的——你可以在代理控制台中读取一个，并立即知道它是否正确。并在状态主题上设置保留标志，以便新订阅者立即看到最后已知状态，而不是等待下一个发布。保留状态是一个仪表板立即弹出准备好与一个空白凝视几分钟之间的区别。
最后一条规则是人们抵制的：当有效负载格式更改时，对主题进行版本控制。plant1/pump1/status/v2。这很丑陋。它可以让你避免因一次更改而破坏生产中的五个订阅者。有效的丑陋主题胜过爆炸的干净主题。
值得发布的数据
发布所有内容和发布无内容一样糟糕——它淹没了代理，膨胀了日志，并掩埋了重要的值。从订阅者会问的问题出发，而不是从寄存器列表出发。操作员想要状态、警报和运行总数。工程师想要趋势：温度、压力、运行小时。经理想要正常运行时间和计数。发布这些，仅这些。
速率也很重要。警报转换：立即发布，始终如此。状态：在变化时加上心跳。模拟值：在实际显示过程的间隔内——慢速温室温度为十秒，机床为一秒。每个你不需要的快速主题都是浪费的代理负载和无线模型上的浪费 SIM 数据。
并在本地记录重要的内容。CPU 的数据记录加上代理的保留消息为你提供了关键历史的两个副本。当代理有一个糟糕的日子时——它们都会有——机器端日志是真相的来源，恢复对话很短。
CPU 上的本地控制，通过 MQTT 实现云可见性，两者从不干扰。这种分离是现代小型自动化的架构，它适合于 DIN 导轨。销售员的路线图没有到达。固件已经发货。
