但是执行器呢？

是的pub-sub 模式适用于执行器。

这是执行器的方法吗？

这是一种可行的方法，并且由于许多云提供商，例如

• AWS IoT即服务支持 MQTT（通过 TLS、WebSockets）
• Google 的Google Cloud 发布订阅消息服务
• 支持 MQTT 的Microsoft物联网中心

试图占据物联网空间以使用不同的方法轻松地将数据从传感器移动到云端，并且由于设备的连接性、功率、带宽有限，他们需要更轻的协议，如 MQTT 等基于发布 - 订阅模型的协议。

我在这里的观点是任何可以感知并拥有数据的设备都可以使用发布-订阅，但聪明的事情来自他们正在做的实现类型。假设您没有通过某种加密机制 (TLS/SSL) 使用 MQTT，则可以嗅探数据。

有没有更聪明的解决方案？

这取决于应用程序和问题的限制，所谓的更智能的解决方案会随着时间的推移而变化。这里要注意的另一件事是，拥有更智能的解决方案并不是最明智的解决方法，因为实施才是最重要的，而不是您选择的协议或方法。

是否可以从任何地方发布开门事件？它有多容易被黑客入侵？

是的，可以通过发布事件从任何地方打开大门，但这一切都取决于您提供的应用程序和身份验证，例如，您可以使您的应用程序订阅/发布主题仅在身份验证之后。

真实案例：

我知道很多公司都在为执行器使用这种精确模型，最近我在一个团队工作，该团队是太阳能跟踪系统的一部分，太阳能电池板使用无线技术进行控制和监控。

特别是根据太阳位置移动/旋转面板阵列，并基于我们使用线性执行器的不同能量优化算法，在该系统中，我们还提供了在紧急情况下从网络/移动仪表板手动控制面板的规定或任何维修目的。

在上述场景中，使用身份验证/加密来控制执行器发布-订阅模型。

安全性如何，例如考虑将其用于门。是否可以从任何地方发布开门事件？它有多容易被黑客入侵？

根据文档 RabbitMQ 使用TLS/SSL。因此安全级别与这些技术一样好。如果您查看RabbitMQ-TLS Support，这里是您使用 SSL、获取服务器证书等的示例。

关于您关于电灯开关的问题。

你所描述的听起来很简单。开关侦听（订阅）想要打开或关闭灯具的潜在源。它还会通知他们有关灯具状态变化的信息，以便他们知道何时以及如何采取行动。

我认为您的交换机设备应该连接到处理所有这些事件的集线器（domotic box，zwave 控制器，...），因此交换机应该专用于与对象的低级交互（zwave，433Mhz，...）

智能设备的电池电量非常有限，因此它们在网络上运行的次数越少，它们的持续时间就越长。