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 BrokerEclipse 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(fopenrig/telemetry/{DEVICE_ID}, json.dumps(telemetry), qos1) time.sleep(10)注意这里我用了qos1保证消息至少到达一次。对于传感器上报这种低频数据qos1 是性价比最高的选择qos2 会多几轮确认资源消耗没必要qos0 又容易丢数据尤其是网络质量不太稳定时。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(fdiscard 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(fprocess 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 的机架这里有一份我实测过的物料清单可以作为参考。尺寸是按我桌面剩余空间设计的你可以等比缩放部件规格数量用途2020铝型材400mm长4根四根立柱2020铝型材280mm长8根横向支撑与层板框架角件2020专用24个连接固定型材3D打印托盘根据设备定制5个架高并固定设备理线槽30mm宽2条固定电源线与网线电源模块12V 5A 5V 3A各1个统一供电M3螺丝组含螺母若干固定型材与托盘组装顺序建议先搭两侧框架再固定层板最后安装理线槽。铝型材的角件螺丝不要一次锁死先把所有句子都带上调整好垂直度后再全部锁紧。我当时先锁死一侧结果另一侧始终对不齐重新松了半圈才对正。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_BROKERmqtt - MQTT_PORT1883 - INFLUX_URLhttp://influx:8086 influx: image: influxdb:1.8 environment: - INFLUX_DBopenrig volumes: - ./influx-data:/var/lib/influxdb grafana: image: grafana/grafana ports: - 3000:3000 environment: - GF_SECURITY_ADMIN_PASSWORDadmin123启动时踩过的坑基本集中在两个方面第一个是 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 这件事技术上没有太难的门槛真正有价值的是把“设备管理”变成一个完整的闭环体验。机架也好平台也好核心都指向同一件事让你对设备的状态心里有数。我自己的感觉是从“打开终端挨个看状态”到“打开一个页面全部清楚”这个转变带来的踏实感远比把设备堆在一起更大。