1. 项目概述与整体设计思路

1.1 什么是 OpenRig：它解决的是什么问题

OpenRig 这个项目，光看名字就能猜个大概：Open 代表开源，Rig 在硬件圈子里一般指“设备架”或者“工作台”。我做的这个 OpenRig，是一套从零开始搭建的开源桌面级开发测试工作台，重点解决两件事：一是硬件环境太杂、走线混乱、散热不透明，二是软件监控割裂，每次调设备都要开好几个工具来回切。把硬件架子、供电系统、传感器网络和监控面板拼成一个整体，用一套自动化脚本统一管理，这是 OpenRig 最核心的定位。

适合什么人参考这套方案？主要是硬件爱好者、嵌入式开发者和搞网络设备测试的运维朋友。如果你手里有一堆开发板、交换机、小型服务器或者 GPU 盒子，却总感觉桌面像个爆炸现场——线缠在一起、风扇全速狂转、温度只能靠手摸——那 OpenRig 就是给你准备的。它不追求高大上的工业标准，更关心一个普通人用常见的工具和零件能不能在周末把它搭出来，并且能长期稳定运行。

1.2 设计取舍：为什么采用开源硬件加第三方监控栈

项目启动的时候，我其实考虑过直接买成品机架设备，比如那种带温度监控的服务器机柜，或者商业环境监测系统。但价格先不提，光“闭源”这一点就劝退了我。我自己的开发环境里，会遇到各种非标准的设备尺寸和供电需求，成品架子固定死板的孔位根本伺候不了。开源硬件的价值在于，你可以自己设计结构件、自己决定传感器装在哪里、自己改调度逻辑，整套系统像一个随时可以拼插的积木平台，而不是一台买回来就只能按说明书用的家用电器。

软件层面我没有选择闭源的收费监控平台，而是把宝押在开源社区的成熟套件上。InfluxDB 存时序数据、Grafana 出面板、Telegraf 做采集，这三个组合在运维圈子里已经打磨了很多年，稳定性和资料丰富度都靠谱。用它们等于站在前人肩膀上，不用重复造轮子，出现问题随便一搜就有现成的解决方案，这比什么都重要。后面涉及的所有模块，全部以配置文件和数据接口的方式解耦，换掉任何一块都不影响其他模块运行。

2. 核心部件选型与硬件细节

2.1 机架结构与布局：从零开始设计设备托架

OpenRig 的物理骨架我选择的是 4040 铝型材，也就是常说的欧标工业铝型材。为什么不用传统的木板或者铁皮机箱？原因很简单：模块化和可调性。4040 型材配合角件和 T 型螺母，可以随意构建框架，孔位不需要提前精确规划，哪里需要横梁就加横梁，哪里要装设备就装设备，承重能力大，整体刚度也相当不错。我花了大概两张 A4 纸的时间画了简单的布局图：底层放体积最大的设备，比如 ATX 电源和硬盘阵列，中层放常折腾的开发板，顶层做理线层和传感器扩展区域。

设计机架的时候一定要留一个细节——轨道空间。很多人第一次搭架子会把所有设备装得严严实实，结果后面想加一个 USB 扩展坞都找不到位置。我的建议是整体尺寸比实际需求多留出 20% 的空余，内部走线槽留足 3 厘米以上的宽度，电源线和数据线分两边走，这样后期维护掀开侧板的时候心情会好很多。另外，铝型材切割的端面一定要打磨，否则毛刺会划伤线材外皮，这个细节不处理，运行两三个月后容易出现莫名其妙的短路。

2.2 供电系统：稳定是一切监控数据的前提

供电部分我用的是一个二手服务器电源改装的 12V 直流总线配上 3 个 DC-DC 降压模块。为什么这么折腾，不直接用现成的多口 USB 充电器？因为开发板和各种外设对电压稳定性要求并不低，树莓派在负载骤升的时候如果电压跌落超过 5%，外接 SSD 就会出现 IO 错误，硬盘直接掉盘。

我用了一个常见的 400W 服务器电源，改出三路输出：第一路固定 12V 给风扇集线器和部分网络设备；第二路过 LM2596 降压模块调到 5.2V，专门给树莓派等单板机供电；第三路也调到 5V，但是串联了一个二极管做 0.4V 左右的压降，得到大约 4.6V，给一些老旧的 5V 传感器板使用，避免过压。每路输出都加了自恢复保险丝，并且并联一个 470uF 的电解电容做瞬态缓冲。这里有个关键参数要算一下：LM2596 模块的输入输出压差不能低于 2V，也就是说 12V 输入降到 5.2V 是安全的，但如果我直接用 5V 输入想降出 3.3V，模块会进入欠压保护，根本没法工作。很多第一次做电源系统的人就是栽在这个压差参数上。

2.3 散热与风道：让气流按设计的路径走

OpenRig 的机架装了三层设备，如果用传统的一箱式散热，风扇对着吹，中间层很容易变成热死区。我设计了一个前后贯通的风道：前面板统一进风，后面板统一排风，中间设备之间的隔板全部打孔，让气流水平穿过每一层的设备散热片。

风扇选型我建议用双滚珠轴承的 12cm 风扇，不要迷信静音轴承——在这种连续运行 7x24 小时的场景里，静音轴承一年左右就会出现噪音增大的问题，双滚珠虽然初始噪音稍大，但寿命实打实长。风扇转速控制不能靠手动拨档，一定要用 PWM 信号控制。我直接采购了一块 6 路 PWM 风扇集线器，每路能查转速输出报警信号，配合后面的单片机控制模块，可以实现温度变化时风扇转速的实时调整。气流方向规划完，实测设备温度比原先敞开放置还要低 3 到 5 度，这个提升完全来自风道的合理性，而不是风扇转速的提升。

3. 软件栈搭建与自动化监控实操

3.1 传感器网络：用 ESP32 做数据采集网关

整个监控系统的神经末梢是温湿度传感器和电流计，数据汇总节点我用了一块 ESP32 开发板。为什么选它？因为它自带 Wi-Fi，原生支持 Arduino 框架，ADC 引脚够多，而且还能通过 FreeRTOS 在后台并行处理好几个任务，作为传感器网关再合适不过。我选择了三路 DS18B20 数字温度传感器，分别贴在电源模块散热片、机架中部空气区域和交换机外壳上，另外加了一路 DHT22 测环境湿度。

接线看起来简单，但这里有一个常见的坑：DS18B20 是单总线协议，多个传感器并联在一根数据线上的时候，需要接一个 4.7k 欧姆的上拉电阻，否则总线电平不稳定，读出来的数据要么全是 85 度（传感器复位默认值），要么干脆随机跳变。我第一版接线的时候偷懒没接上拉，排障花了大半个小时，后来查资料才确认是上拉电阻的问题。改成三线制接法（VCC、GND、DATA），在数据线跟 VCC 之间焊上 4.7k 电阻之后，数据一下就稳定了。

ESP32 采集的数据通过 MQTT 协议发布到局域网里的 Mosquitto Broker 上，每一个传感器都有独立的 topic。比如openrig/temp/psu就是电源模块温度，openrig/humidity/environment就是环境湿度。采用 MQTT 而不是直接写入数据库，好处是解耦——采集端不关心数据落到哪里，其他服务只要订阅对应的 topic 就能拿到数据，后面接 Grafana 还是接自动化脚本都非常干净。

3.2 数据链路与 Grafana 可视化面板

数据从 MQTT 到 Grafana，中间必须有一个“翻译官”角色的服务。我选的是 Telegraf，它有一个 MQTT Consumer 插件，可以订阅 MQTT topic，将数据转换成时序数据之后写入 InfluxDB。这套链路的好处是每一个环节都是可替换的标准件：MQTT Broker 可以换，数据库可以换，仪表盘可以重新画，但核心的数据流不会变。

配置 Telegraf 也很直接，核心是把 MQTT 订阅到的 payload 解析成数值型字段。我让 ESP32 每次发布的数据都是干净的 JSON 格式，比如{"temp": 48.3}，Telegraf 端配置好 JSON 解析器，它就能自动把temp字段提取出来。这里有一个数据标准化的小技巧——所有温度统一用摄氏度加小数点一位，所有发布时间统一用 MQTT 自带的保留消息机制，这样即使某一次采集间隔抖动，也不会出现前后数据错位的情况。

Grafana 这边的可视化我做了三层：第一层是全局总览，用数字面板展示当前环境温度、电源温度和平均负载；第二层是趋势曲线，看最近 24 小时温度变化趋势，用来判断有没有缓慢升温的问题；第三层是告警状态，把风扇转速、供电电压这些硬指标标红显示。面板配置好以后，我基本不用每天都登录设备查看，扫一眼 Grafana 的全局视图就能掌握 OpenRig 的实时状态。说实话，这套界面最爽的地方在于数据是自己的，想要什么视图自己拖拽配置就行，商业软件给了你一百个模板也未必有一个合心意。

3.3 自动化风扇调速：一个简单的 PID 控制实现

风扇不能永远全速转，白天调试设备倒还好，晚上挂机跑任务的时候噪音就很烦人了。我在这套系统里加了一个简单的 PID 调速逻辑，跑在 ESP32 上。控制目标是让机架内部温度稳定在 38 度左右，如果温度高了，风扇 PWM 占空比就加大，温度低了就调小。

PID 参数我调了三组，最终固定成 P=30、I=0.2、D=10。为什么这样选？P 值太大，风扇转速会跟着温度波动剧烈抖动；P 值太小，温度又压不住。D 项可以防止风扇在温度到达目标值附近时反复震荡。实际数据表明，调整后风扇的转速变化非常平滑，温度曲线基本是一条贴着目标值的平线，波动幅度不超过 1.5 度。这里提一句，如果不想折腾 PID，也可以用简单的分段阈值控制，比如温度超过 42 度就把风扇拉到 70%，低于 35 度降到 30%，实现效果也不差，只是温度曲线会有肉眼可见的台阶感。

PID 控制的输出，通过 ESP32 的 LEDC 引脚产生 25kHz 的 PWM 信号送到风扇集线器。25kHz 这个频率也值得说一下——低于 20kHz 的 PWM 会被人耳听到明显的啸叫，超过 25kHz 就基本无声了，这是风扇调速被很多人忽略的细节。如果你用了一般的低频 PWM 调速，晚上那种滋滋声会让整个人都不舒服。

4. 常见问题与排查技巧实录

4.1 温度数据漂移和异常值处理

系统跑了一段时间后，最常遇到的问题是 Grafana 面板上偶尔会出现一个毫无征兆的尖峰，比如温度瞬间从 39 度跳到 75 度，又马上跳回来。这种情况十有八九不是设备真的过热，而是传感器数据噪声。

DS18B20 本身精度是正负 0.5 度，但它在受到电磁干扰，或者电源电压波动的时候，单次转换结果会有离谱的偏差。我的处理策略是在 ESP32 的采集代码里做滑动窗口滤波：每 5 秒采一次，缓存最近 5 个值，取中间三个的平均值作为当前值，最大值和最小值直接丢弃。这样处理以后，异常尖峰基本消失了。还有一个更简单的办法——在采集端不做处理，而是在 Telegraf 的查询语句里用median()聚合函数，把 1 分钟内的原始数据聚合后再写入 InfluxDB，效果类似。

说了滤波，还要提醒一个新手容易走的弯路：不要一看到异常数据就去改硬件屏蔽，先确认是不是读取频率太高导致总线冲突。DS18B20 每次转换时间约 750 毫秒，如果主控在转换期间发起新的读取请求，数据就会是上一次的缓存值，表现出来就是数据好像不动了，或者每隔几次出现重复值。给采集任务之间加 800 毫秒以上的间隔，问题自然消失。

4.2 风扇 PWM 调速失效：原因居然在共地

这个坑我印象非常深刻。刚开始把风扇集线器接到 ESP32 的 PWM 输出上，转速始终不变，一直是静音模式下的低速。用万用表量了一下看，PWM 信号引脚的波形是正常的，但风扇就是接收不到。

排查到最后，发现是电源共地的问题。ESP32 由 5V 降压模块供电，风扇集线器由 12V 主电源供电，这两个电源模块虽然输入都是 12V，但输出地之间没有连通。没有共地，PWM 信号的参考地跟风扇控制电路的地是两套体系，信号自然就无法形成回路。

解决办法很简单，把 ESP32 的 GND 和风扇集线器的 GND 用一根线直接连起来。从那之后我做任何信号连接都把这个“共地优先”当成铁律。如果你要控制其他设备，比如继电器模块、舵机驱动板，只要涉及两套以上供电系统，第一件事永远是检查所有模块是否共地，这能省下非常多的排查时间。

4.3 OpenRig 常见问题速查表

4.4 维护心得：长期稳定运行的三个好习惯

OpenRig 稳定运行半年之后，我有几个特别想强调的维护习惯。第一个习惯是定期清理防尘网，这个听起来太基础，但很多设备突然温度升高都是因为防尘网积灰导致风道堵塞。我现在每两个月把前面板防尘网拆下来用吸尘器吸一遍，GPU 盒子上的散热鳍片用气吹处理一下，温度立刻就能降 2 度左右。

第二个习惯是给每个设备做标签。我在电源模块、风扇集线器、传感器线材上都贴了标签，标注电压、方向和接口类型。这套系统模块化程度高，后期免不了拆装维护，如果没有清晰的标签，插错一次线就可能烧掉一个模块。标签的成本几乎为零，但省下的排查时间不可估量。

第三个习惯是定期备份配置。系统里最重要的东西不是硬件，而是 Telegraf 和 Grafana 的配置，以及 ESP32 的固件源码。我每次改完配置都会 Git 提交一次，半年下来积累了完整的版本记录，哪次改坏了随时能回滚。这个习惯帮助我两次快速恢复系统，一次是 Grafana 面板误删，一次是配置文件覆盖错误，两次都用了不到五分钟就回到了可用状态。

最后再分享一个自己调试时的小技巧：给 ESP32 加一个 OLED 显示当前温度和风扇转速，放在机架前面板。这样不用每次看数据都打开电脑上的 Grafana，人走到机架前扫一眼屏幕就能确认一切正常。这算不上什么高深技术，但确实让 OpenRig 的日常体验好了很多，也让我越来越愿意在这个开源工作台上继续折腾下去。