openrig：基于MQTT与树莓派的开放设备机架与监控平台实践

1. openrig是什么：把散落设备收进一个“开放机架”

我大概花了四个月时间，反复折腾之后才意识到，做 openrig 这件事的核心问题从来不是“缺一个机架”，而是“缺一套让设备能够被统一管理和观察的方法”。

说得更直接一点：我桌面上有三台树莓派、一块STM32开发板、两个温湿度传感器、一个网络交换机，再加上偶尔要接进来调试的USB摄像头和继电器模块。这些东西平时各自为政，线缆绕成一团，想看某台设备跑没跑，得挨个打开终端敲命令；想查历史数据，又没有统一的存储；想定时控制某个设备，几乎每次都靠人肉操作。久而久之，我就想做一个“闭环”的东西：物理上把它们装进同一个机架，逻辑上让它们接入同一套控制台。这就是 openrig 的起点，open取自开放、开源、通用，rig则恰好是机架和设备装置的双关。

openrig 适合谁？我觉得主要是这几类人：家里设备开始变多、但还远远没到机柜规模的极客玩家；需要在实验台上管理多块开发板的电子工程师或在校生；以及想把自己的传感器数据、自动化逻辑收敛到一个统一界面里的DIY爱好者。它不需要你有一个标准机房，也不需要你会造交换机，它解决的恰恰是“设备多了以后桌面和状态一起失控”这件事。

这套系统最终呈现出来的是两个东西的结合：一个用铝型材和3D打印零件搭成的物理机架，以及一套跑在树莓派上的轻量设备接入与监控平台。机架负责理线、固定、供电，平台负责设备发现、数据收发、状态面板和定时任务。下面我把设计思路、关键实现和踩坑过程完整拆开讲。

2. 整体设计思路：开放协议比开放机架更重要

2.1 为什么核心是一套“接入协议”

我一开始以为 openrig 的难点在机械结构，后来发现真正的灵魂在于软件侧的接入协议。

物理机架做得再漂亮，如果每台设备接入都要单独写一套采集脚本，那设备数量一多，维护成本就会爆炸。所以我在设计的第一天就定下一条原则：openrig 下所有设备统一通过 MQTT 协议上报状态，消息体统一采用 JSON 格式。设备端只负责两件事：把自己的状态发布到对应主题，接收控制指令并执行。剩下的存储、展示、告警、联动，全部由中央控制台处理。

这么做的好处是让“加设备”变成一种低成本动作。新设备只需要遵守这套约定，无论它是树莓派、ESP32还是纯软件脚本，都能在几分钟内完成接入。我用了 MQTT 而不是 HTTP 轮询，主要是因为 MQTT 是发布订阅模式，天然适合这种多点收发、实时性要求高的场景。传感器每10秒推一条消息，控制指令瞬间下发，网络开销也低。这个选择在后面的实际运行里省了非常多事。

2.2 一个名字，两层含义：物理机架与逻辑平台

Openrig 这个名字本身有两层落地载体，缺一不可。

第一层是物理机架。我选用2020铝型材作为主体框架，竖装着五层设备：最底层放网络设备和电源模块，第二层放树莓派和交换机，第三层留作扩展，第四层挂传感器阵列，最顶层保留给未来想加入的显示面板和调试工具。机架两侧预留标准安装孔位，所有设备通过3D打印的挂载托盘固定，托盘设计成可以快速拆卸，换设备时不用拧螺丝。

第二层是逻辑平台。所有接入设备的状态汇总到一个 Web 控制台，展示方式是卡片列表加实时曲线。控制台可以查看每个设备最近一次心跳时间、当前数据值、固件版本、运行时长，也可以下发定时任务。物理机架解决“东西放在哪”的问题，逻辑平台解决“设备在干什么”的问题。

2.3 软件选型：从容器化到显示的完整链路

软件侧的技术栈必须足够轻，毕竟主控设备是树莓派4B。我最终确定的组合如下：

• MQTT Broker：Eclipse Mosquitto，占用资源极小，配置简单，完全满足本地设备通信。
• 消息汇聚服务：Python 3 + paho-mqtt 写的中心服务，订阅所有设备主题，把有效数据清洗后写入数据库。
• 数据存储：InfluxDB 1.8，时序数据库，存传感器历史数据非常合适，查询也快。
• 展示面板：Grafana，直接对接InfluxDB，画曲线和状态卡片很顺手。
• 配置与部署：全部用 Docker Compose 管理，一台树莓派上跑完整的服务栈，出问题重建容器就行。

这套组合的好处是每一环都有明确的替代方案。不想用Grafana的话，也可以写个简单的Flask页面；不想用InfluxDB的话，SQLite 加定时导出也够用。我选这些组件，不是为了炫技，而是因为它们各自在“小规模、低功耗、长期运行”的场景下足够成熟和稳定。

2.4 一个关键取舍：控制台与设备端解耦

Openrig 在设计之初就刻意让控制台和设备端保持解耦。设备端不依赖控制台存在，控制台也不绑定具体某个设备品牌。换句话说，你把设备从机架上拆走，它照样能自己跑；你把控制台停掉，设备自身功能也不会受影响。

这个取舍带来一个实际好处：故障隔离。有一次 InfluxDB 服务因为写入不协调磁盘满了，导致控制台数据写不进去，但所有设备的 MQTT 上报依然正常，设备本身也继续在工作。修复存储后，历史数据补齐，整个链路自动恢复。如果当初把设备状态和控制台写成强耦合关系，这种故障就很容易变成“一台设备挂掉，整个机架跟着停摆”。

3. 核心细节实现：统一接入与消息链路

3.1 设备端接入规范

openrig 的设备接入规范大约就三条：

• 每台设备有一个唯一标识，建议用device_type/device_id的格式，比如temp_sensor/balcony_01。
• 状态上报统一发布到openrig/telemetry/{device_id}，消息体是 JSON，至少要包含timestamp和status字段。
• 控制指令统一发布到openrig/command/{device_id}，设备订阅这个主题，收到指令后执行并返回执行结果。

我放一个最简单的温湿度传感器示例代码，设备端用 ESP32 或者任何支持 MQTT 的开发板都行：

import json import random import time from paho.mqtt import client as mqtt_client BROKER = "192.168.1.100" PORT = 1883 DEVICE_ID = "temp_sensor/balcony_01" client = mqtt_client.Client(DEVICE_ID) client.connect(BROKER, PORT) while True: telemetry = { "timestamp": int(time.time()), "status": "online", "temperature": round(random.uniform(18.0, 30.0), 2), "humidity": round(random.uniform(40.0, 65.0), 2), } client.publish(f"openrig/telemetry/{DEVICE_ID}", json.dumps(telemetry), qos=1) time.sleep(10)

注意这里我用了qos=1，保证消息至少到达一次。对于传感器上报这种低频数据，qos=1 是性价比最高的选择，qos=2 会多几轮确认，资源消耗没必要，qos=0 又容易丢数据，尤其是网络质量不太稳定时。

3.2 中心服务的消息清洗与入库

中心服务承担三个职责：订阅所有 telemetry 主题、做一轮数据清洗、把合法数据写入 InfluxDB。清洁逻辑主要包含几个判断：

• timestamp必须存在且合理，与当前时间差超过24小时的一律丢弃。我遇到过设备断电后重启，系统时间没有同步导致上报时间错乱的情况，这一条直接把无效数据过滤掉。
• 数值字段必须在合理范围内，比如温度如果是99.99这种异常值，说明传感器采样出了问题，直接丢弃并把设备标记为“数据异常”。
• 每次收到消息后更新设备的最后心跳时间，心跳超过3分钟未更新的设备，在控制台显示离线。

这里给一段中心服务的核心处理流程：

def on_message(client, userdata, msg): try: payload = json.loads(msg.payload.decode()) device_id = msg.topic.split("/")[-1] if abs(payload.get("timestamp", 0) - time.time()) > 86400: logger.warning(f"discard invalid timestamp from {device_id}") return temperature = float(payload.get("temperature", 0)) if 0 < temperature < 60: write_to_influx(device_id, "temperature", temperature) update_device_heartbeat(device_id) except Exception as e: logger.exception(f"process message failed: {e}")

3.3 定时控制与规则联动

定时控制和规则联动是我觉得 openrig 真正加分的地方。控制端不需要写死逻辑，而是通过一套简单的规则配置实现。规则大概是三层：

• 定时层：比如“每天8点打开继电器1”，用 cron 表达式来描述触发时间。
• 条件层：比如“当阳台温度大于30度”，这个条件来自某个 telemetry 数据。
• 动作层：向目标设备发布控制指令。

我实际做过的几个规则都能正常工作，包括夏天阳台温度超过32度自动打开风扇继电器、湿度低于40%时发送提醒到钉钉机器人、每周末凌晨3点让所有设备进入低功耗模式。规则服务本身也是独立容器，单独跑一个 Python 进程，读配置文件里的规则列表，然后执行。

3.4 告警通知：用 Webhook 而不是短信轰炸

告警通知我选用的是 Webhook 方式，对接钉钉机器人或者企业微信机器人。原因很简单：不需要额外注册一个短信服务，也不需要忍受高峰期的短信延迟。设备离线、温湿度越界、心跳异常，这些事件都会聚合之后发送到一个 Webhook URL。

为了不烦人，告警里我加了聚合逻辑。比如设备掉线这种事件，不会每10秒发一次，而是连续确认5分钟后才发送一条，并且同一个设备在一小时内只告警一次。这个设计在夜里特别重要，否则传感器抖动一次，手机一晚上能响几十次。

4. 实操搭建全过程：从型材切割到服务上线

4.1 硬件物料清单与机架尺寸

如果你也想做一个类似 openrig 的机架，这里有一份我实测过的物料清单，可以作为参考。尺寸是按我桌面剩余空间设计的，你可以等比缩放：

组装顺序建议先搭两侧框架，再固定层板，最后安装理线槽。铝型材的角件螺丝不要一次锁死，先把所有句子都带上，调整好垂直度后再全部锁紧。我当时先锁死一侧，结果另一侧始终对不齐，重新松了半圈才对正。

4.2 理线：决定这个机架能用多久的细节

理线这件事，我吃了不少亏。第一次组装时图省事，电源线和网线一起用扎带绑住，结果一通电就出现传感器读数跳变，排查了很久，最后发现是220V交流电源线和信号线并行产生了干扰。

现在的做法是强弱电分开：电源线走左侧理线槽，网线和USB信号线走右侧理线槽，两侧在机架底部汇入一个接线端子板。控制信号线和电源线之间至少保持5厘米间距，实在避免不了交叉时，就垂直交叉而不是平行走线。这个细节直接决定你后期是睡得着觉还是半夜被传感器假报警吵醒。

4.3 软件部署：直接用 Docker Compose 拉起整套服务

软件部署比硬件组装简单得多，但也有一些值得记录的坑。先看 Compose 配置：

version: "3.8" services: mqtt: image: eclipse-mosquitto:2 ports: - "1883:1883" volumes: - ./mosquitto/config:/mosquitto/config central-service: build: ./central-service depends_on: - mqtt environment: - MQTT_BROKER=mqtt - MQTT_PORT=1883 - INFLUX_URL=http://influx:8086 influx: image: influxdb:1.8 environment: - INFLUX_DB=openrig volumes: - ./influx-data:/var/lib/influxdb grafana: image: grafana/grafana ports: - "3000:3000" environment: - GF_SECURITY_ADMIN_PASSWORD=admin123

启动时踩过的坑基本集中在两个方面：第一个是 Mosquitto 2.0 之后默认开启了匿名访问限制，设备端会一直连接不上去，必须在配置里显式开一个本地用户并允许局域网访问，或者在 mosquitto.conf 里显式写allow_anonymous true，我建议做成用户名密码模式，而不是直接开放匿名，安全等级完全不同。第二个是 InfluxDB 容器内外网地址的差异，中央服务用的是容器网络内的变量名influx，你在 Grafana 配置数据源时要用宿主机IP加映射端口，写错就会反复提示数据源连接失败。

4.4 接入第一个设备：树莓派上的温湿度上报

接入完整流程我建议不要直接上复杂设备，先拿一个树莓派加DHT22温湿度传感器练手。在树莓派上跑一个脚本，每10秒读取传感器数据并上报到MQTT。先通过命令行确认树莓派能ping通主控机，再启动脚本，在Grafana上看到第一条曲线之后，再逐步接入其它设备。

这个小循环的验证意义在于：它把网络连通性、MQTT配置、建库写库、Grafana数据源整条链路都串通了。链路通了，后面接设备就只是重复劳动。

5. 常见问题与排查实录

5.1 设备上线几十秒后就掉线

这个现象我刚开始接ESP32时遇到好几次。排查到最后发现是设备端没发心跳、MQTT的 keepalive 时间设置不合理导致的。Mosquitto 默认 keepalive 是60秒，如果你设备端的网络线程阻塞，Broker 就会判定离线。

解法是：在设备端把 keepalive 设置调大，比如180秒；同时在中心服务里把离线判定时间放宽到3分钟以上，给设备一些容错空间。不要一看到跳一次心跳就觉得设备挂了，机械地设个30秒掉线，反而会在网络抖动时误报。

5.2 MQTT 消息积压或者丢失

设备数量一多，如果所有传感器都是10秒上报一次，几十台设备加起来每秒就可能有几十条消息。Mosquitto 本身压力不大，但中心服务的单线程消费很容易成为瓶颈。

我当时的排查办法是先看中央服务日志有没有积压。如果日志时间戳和实际时间越拉越大，说明消费能力跟不上。解法有两个方向：一是提高上报间隔，传感器数据其实没必要10秒传一次，30秒甚至60秒完全够用，画曲线照样平滑；二是把中心服务的消费逻辑改成多线程，每个设备类型开一个消费协程。我实际方案是两者结合，把大部分传感器上报间隔改成30秒，曲线效果没有任何实质变化，系统压力却直接降到原来的三分之一。

5.3 传感器读数跳变

读数跳变是个特别常见的干扰问题。跳变的元凶大多是电源，而不是传感器本身。很多传感器对电源纹波极其敏感，供电不稳时读数会周期性跳跃，尤其当你用同一个电源同时给继电器和传感器供电时，继电器一动作，传感器读数就乱跳。

解决方法是把模拟传感器和继电器分开供电，传感器用线性稳压模块，继电器用开关电源，物理上隔开。实在没办法分开供电时，在传感器电源上加一个100微法的电容也能明显抑制杂波。这个经验值不少钱，我当年调了很久才发现是电源问题。

5.4 容器里日志时间不对

这个坑属于典型的小问题大烦恼。树莓派默认时区如果没设成北京时间，InfluxDB 里存的时间戳看着总是偏了8个小时，查数据时特别别扭。检查方法很简单，在宿主机跑date命令，如果显示 UTC 时间就说明时区没设对。修正时区之后，所有容器要重启一遍才能生效。

6. 扩展玩法与长期维护经验

6.1 从传感器监控变成自动化枢纽

Openrig 跑稳定后，我把它从“监控工具”变成了“自动化枢纽”。现在机架上接的东西包括一个智能插座控制的台灯、一个继电器控制的排风扇、一组门窗传感器。条件规则跑起来之后，日常体验确实变顺畅不少：开门自动亮灯、温度高了自动开风扇、设备离线自动在微信机器人里收到提醒。

做自动化规则时有条建议：规则的触发条件要加“持续多久”，比如 “温度大于32度” 和 “温度大于32度并且持续3分钟” 是两种完全不同的可靠度。后者能过滤掉传感器瞬时抖动和短时间异常，几乎不会误触发，日常体验会好非常多。

6.2 安全底线必须做好

虽然 openrig 本质上是一个局域网系统，但安全一点不能省。我有几条固定要求：

• MQTT 必须配置用户名密码，不要开匿名。
• 树莓派上所有管理端口不要暴露到公网，如果确实有远程访问需求，优先考虑正规的远程运维通道，并且打开系统层面的防火墙，只允许特定端口。
• Grafana 和管理后台务必设置独立的强密码，不要用默认 admin/admin。

这些事不做事的当下可能没感觉，但接入设备的权限一旦被拿到，可能影响到的就不止是一个传感器了。

6.3 后续还能怎么扩展

Openrig 的扩展空间其实很大。目前我已经把规则引擎抽成独立模块，下一步计划接入语音控制，让整个机架可以和智能音箱联动。传感器层面，我打算加入空气质量检测和漏水检测，做成更完整的家庭环境感知网。如果你也感兴趣，可以按 “传感器接入 → 规则联动 → 告警提醒 → 语音控制” 这个顺序慢慢迭代，每一步扩展开销都不大，但体验跃升很明显。

最后说点个人体会。做 openrig 这件事，技术上没有太难的门槛，真正有价值的是把“设备管理”变成一个完整的闭环体验。机架也好，平台也好，核心都指向同一件事：让你对设备的状态心里有数。我自己的感觉是，从“打开终端挨个看状态”到“打开一个页面全部清楚”，这个转变带来的踏实感，远比把设备堆在一起更大。