物联网-家庭监控系统

 

我们最终迟早都会在家庭监控/自动化系统上工作。那对我来说是目前的大背景项目。

我已经准备好了几个阶段的一些部分，但我缺乏对整个系统的整体看法。我最初的方法是将所有内容存储在MySQL数据库中，并开发一个Web应用程序来绘制时间序列值。计划是部署一个无线传感器网络，其中有不确定数量的传感器通过Zigbee传输信息。Xbee协调器放置在插入服务器的Sparkfun Xbee Explorer USB上，它将接收信息，python脚本将解码包并将消息存储在数据库中。

我计划基于物理构建块（设备，传感器，值）设计数据库，然后提供REST API（我是一个REST粉丝）来使用数据。

然后我考虑存储我正在使用的其他服务的信息，如Efergy Engage（我将在另一篇文章中讨论）。不幸的是，Efergy没有为他们的产品提供API。我问过他们几次，他们说这不是优先事项，但我认为这会违背他们认为自己的业务，所以我认为他们不会打开它。无论如何，不​​难看出他们在他们的在线图形应用程序上做的请求，我写了一个小的脚本登录并发出一个请求来读取过去24小时的数据并将其存储在数据库中。

然后我认为在Cosm.com或RRD工具中开始绘制所有数据并不会有害。毕竟，我需要一些时间来放置我想要的UI。但那我应该在哪里插上？我是否必须为REST API创建一个消费者，每分钟只用cron将数据推送到Cosm.com？或者，Xbee驱动程序和efergy脚本是否应将信息转储到MySQL *和*到Cosm.com？在第二个选项中，MySQL是一个简单的数据备份存储，并且有许多驱动程序执行各种任务。此外，如果我将来想要更多的消费者，我将不得不为所有这些驱动程序添加代码......第一个选项似乎更具可持续性，并且解耦了网络的几个组件。MySQL成为网络的中心，客户端将使用REST API定期从中提取数据。这里没有实时数据，你。

然后有一天，在上班途中阅读我手机中的新闻信息时，我偶然发现了Robbert Henkkens博客（我最喜欢的）关于使用MQTT发布传感器数据的帖子。MQTT （消息队列遥测传输）是一种轻量级的发布/订阅消息传递协议，旨在进行机器到机器的通信。它于1999年在IBM创建，但它拥有开放许可证，并且它是免版税的。基础结构需要接收和发送消息的代理以及许多客户端。每条消息都有一个主题和一个内容（以及一个可以短至两个字节的标题）。客户端可以发布或订阅任意数量的主题（您可以定义访问控制规则）并指定I消息以在断开连接时发布主题。有3个QoS级别，订户可以请求断开连接时丢失的消息。

我花了几天时间才意识到这是我需要解耦网络组件的解决方案。我可以以一种孤立的方式处理我的网络的每个组件：MQTT消息的发布者或消费者，无论通信的另一端是什么或谁。有许多MQTT代理可用，包括Mosquitto，一个开源项目，提供守护程序代理，C库，python库和命令行实用程序，用于发布和订阅，这对我来说非常适合。此外，我将使用（事实上的）标准协议，不再使用自定义API或其他解决方案。甚至Cosm.com也支持MQTT（尽管它不支持完整的规范）！

这就是我的以MQTT为中心的WSN的样子：

我已经在调整我的模式了。我还有一些问题需要解决，比如如何存储传感器数据（MySQL不是最好的选择），并定义主题命名约定或如何在正确的主题下从哑传感器发布数据。罗伯特为这最后一个问题提出了几个解决方案。我认为重新发布主题选项是我最喜欢的选项，但这是另一篇文章的主题（ehem）。