地下室那台老酒柜终于让我下定决心改造了——给里面藏着的十几瓶马德拉酒配了一套专属环境监控系统项目代号就叫 Madeira。没错就是那个以陈年和稳定风味著称的马德拉酒我拿它当项目名意思是让这套系统像好酒一样经得起时间敲打。起因很实际老酒柜温湿度波动大压缩机一启动温度能跳两三度湿度一掉到五十以下软木塞干缩进空气酒质就毁了。我最初想买成品智能温湿度计后来发现要么数据存在云端要么不支持本地存储和自定阈值索性自己用 ESP32 加传感器搭了一套实时监测温度、湿度、气压能画趋势图能推告警数据全部本地保存日常使用成本几乎为零。如果你也想给酒窖、雪茄柜、胶片、地下室或者精密仪器做一个类似的“智能哨兵”这篇从选型到踩坑的记录可以直接抄作业。1. 项目缘起与整体设计思路1.1 为什么叫 Madeira从马德拉酒到环境监控马德拉酒和我们熟悉的葡萄酒最大的不同是它刻意经历了“加热与氧化”环节在湿热环境中度过一段漂泊岁月后反而拥有极强的抗氧化能力开瓶后能放很久。但这里有个容易被忽略的细节酿造过程需要特殊环境陈化过程却依然害怕温度的剧烈波动。酒柜不是保险箱压缩机启停带来的温差会让软木塞反复热胀冷缩时间长了密封性下降瓶内酒液与氧气接触过多风味就会松垮。我起名 Madeira其实有两层意思。一层是明确使用场景就是酒类储藏环境另一层是提醒自己做监控系统也要有“陈年”意识不能只想跑三天要能连续记录一整年的数据稳定比好看重要。这个心态直接影响了所有选型决策能选有线供电就不折腾电池能放到本地服务端就不依赖公共云能用成熟协议就不自己瞎发明。后面整个架构都是围绕“长期稳定”这四个字展开的。1.2 需求拆解与方案选型动工之前我把需求拆成了四块避免做到一半才发现遗漏环境数据采集温度、湿度、气压每 1 分钟采样一次能保存至少一年。本地存储数据必须存在我自己控制的设备上不依赖任何公共平台。异常告警温度超过上限、湿度低于下限时能主动通知我最好带上当前读数。远程查看与复盘要能看到趋势曲线和单日波动而不是只有一串数字。围绕这四块我对比过三类方案。第一类是直接买成品温湿度记录仪能联网的几百块但不少品牌的数据存私有云端拉数据要手动导出告警规则也很死板。第二类是 Zigbee 温湿度传感器加网关优点是便宜省电缺点是传感器本身通常不显示气压雨霉天气的露点估算能力略弱。第三类是我最终采用的 DIY 方案一个 ESP32 做主控搭配 BME280 数字温湿度气压传感器用 MQTT 协议把数据发给本地 broker然后由 Python 脚本写入 InfluxDB最后用 Grafana 看板和 Home Assistant 联动告警。这套方案成本大概在 60 元左右所有组件都能随时替换Sensor 坏了换个同款无缝接入不会被某个厂家的生态绑死。整个链路成熟度非常高每一环都是公开协议家里跑服务的旧电脑能兼数也好单拎一台树莓派也好都能承接。1.3 架构全景图从物理世界到可视化看板数据完整路径是这样ESP32 传感器节点每秒/每分钟采集环境数据 → 通过 Wi-Fi 发布到 MQTT BrokerMosquitto→ Python 数据订阅服务接收消息并解析 JSON → 写入 InfluxDB 时序数据库 → Grafana 从 InfluxDB 查数据画曲线Home Assistant 监听同一个 MQTT 主题做条件判断和推送。这个链路里每一个组件都是可以独立替换的。我后来修过一次 bug只是改了 Python 解析逻辑没有动传感器端充分体现出解耦设计的好处。后面所有小节都会按照这个顺序展开先讲硬件端为什么选这些零件再讲数据怎么传、怎么存、怎么出图最后是实际部署和排障。2. 核心硬件选型与数据精度分析2.1 传感器选型对比BME280 才是性价比王者市面上常用的温湿度传感器主要有 DHT22、SHT30、BME280 三种。很多人贪便宜买 DHT22一开始我也踩了这个坑但实测下来问题很多。DHT22 是单总线通信读取时序特别讲究换个库性能就不一样传感器内部以聚合物感湿湿度超过 80% 后读数经常乱跳甚至有老化后彻底不准的情况。我曾在酒柜里遇到过 85% 湿度DHT22 直接飙到 99%连续大半天都下不来后来查资料才知道是传感器本身进入“饱和区”了。BME280 就好得多它内部是 Bosch 的数字传感芯片Ⅰ²C 或 SPI 接口输出量包括温度、湿度、气压三个指标而且自带温度补偿算法。温度精度 ±0.5°C湿度精度 ±3%RH气压精度 ±1 hPa。SHT30 的温湿度精度确实比 BME280 略高一点温度 ±0.3°C、湿度 ±2%RH但没有气压价格还贵几块钱性能差距在酒柜这种环境里几乎体现不出来。考虑到我还要用气压数据算露点最终选择 BME280一块模块十几块钱非常划算。传感器温度精度湿度精度气压接口典型价格稳定度DHT22±0.5°C±2~5%RH无单总线约 8 元差易漂移SHT30±0.3°C±2%RH无I²C约 15 元良好BME280±0.5°C±3%RH±1 hPaI²C/SPI约 13 元优秀2.2 主控选型ESP32 为什么比 ESP8266 值得多花几块钱ESP8266 是玩物联网的老将价格低到十元以内跑温湿度数据完全够用。但我还是选了 ESP32理由有三双核处理器。传感器读取、MQTT 发布、Wi-Fi 重连可以分散到两个核心实际跑起来很少出现“读取数据时网络卡住”的问题。支持蓝牙和更多 GPIO。蓝牙虽然这次没用但后面想接信标做开放提醒硬件上不用换板子。电源容忍度和稳定性更好尤其是我这种把节点放在金属箱体内的环境ESP32 的射频抗干扰能力明显强于 ESP8266。我说的“强于”不是玄学是实测体会。用同样的外部天线方案ESP8266 在酒柜金属壳内经常丢包ESP32 的 Wi-Fi 信号稳定不少。当然如果你只做桌面小摆件ESP8266 也够但既然总价差不到十块直接上 ESP32 可以减少后期维护成本。2.3 数据采集频率、精度与露点计算酒柜里的温度变化是分钟级的压缩机一次启停周期少说十几分钟所以我没有必要做成每秒采样。最终设定 60 秒读取一次并上报Grafana 上能看到平滑曲线数据量也不大。估算一下每分钟 1 条每小时 60 条每天 1440 条一年大约 52 万条InfluxDB 处理这点量级非常轻松即使加上消息标签和索引也就几百兆大小。BME280 的湿度在高于 80% 时会缓慢漂移尤其长期处于潮湿环境。对于酒类储藏我会关注两个衍生指标露点和绝对湿度。露点温度能直接反映墙壁、玻璃门会不会结露绝对湿度可以衡量单位体积空气里的水汽含量避免只看相对湿度被温度变化带偏。露点用 Magnus 公式近似计算Python 里实现很简单import math def dew_point(temp_c, rh_percent): a 17.62 b 243.12 gamma math.log(rh_percent / 100.0) (a * temp_c) / (b temp_c) return (b * gamma) / (a - gamma)我这里温度单位是摄氏度湿度是百分比。实测下来这个公式在 0~50°C 范围内的误差小于 0.1°C足够用了。2.4 供电与部署细节传感器节点最怕的不是耗电而是供电不稳定。BME280 的工作电压是 3.3VESP32 开发板一般是 5V USB 供电板载稳压芯片会降到 3.3V。但酒柜内部压缩机启动瞬间市电会有较大的谐波和压降劣质 USB 充电头在这种场合就会输出抖动导致设备偶发重启。我的经验是使用带认证的 5V/1A 电源并且把电源适配器放在酒柜外部只把 USB 线穿进去。穿线的开口用硅胶密封不破坏酒柜保温层。节点本身我固定在酒柜中层靠后壁的位置那里受开关门影响小也不用紧贴制冷板。千万不能放在门缝附近每次开门都会测到明显的温湿度跳变误以为系统出问题。3. 服务端与流数据链路搭建3.1 MQTT 消息设计与 Topic 规划MQTT 是我使用最频繁的 IoT 传输协议基础概念很像一个消息信箱。发送方发布消息到某个话题Topic订阅方订阅感兴趣的话题Broker 负责转发。为了让多个客户端分享数据我把每个测量指标拆成独立 Topic或者用一个 Topic 加多个字段两种方式都通畅。我最终选择了一个 Topic 发布完整 JSON因为解析端只需要订阅一次而且后续加字段不用改 Topic。Topic 结构设计如下TopicPayload 示例retain 标志madeira/sensor/status{state:online}是madeira/sensor/weather{temperature:18.6,humidity:63.2,pressure:1013.4}是madeira/sensor/warning{low_battery:false}否retain 标志很关键。Broker 会保存消息的最后一条新订阅者连上来立刻能拿到当前值避免要等下一轮上报才知道设备状态。我建议在设备端发布所有传感器数值时都带 retain这样 Home Assistant 重启后不用等一分钟就能恢复显示。3.2 数据解析与存储MQTT → Python → InfluxDB本地服务端我用 mosquitto 作为 MQTT Broker再跑一个轻量 Python 进程订阅 madeira/sensor/#。收到消息后解析 JSON按时间顺序写入 InfluxDB。InfluxDB 是专为时序数据设计的数据库用“measurement tag field timestamp”的模型存储查询聚合比普通关系型数据库方便太多。InfluxDB 2.x 的 Python 客户端里写入方式并不复杂from influxdb_client import InfluxDBClient, Point from influxdb_client.client.write_api import SYNCHRONOUS import paho.mqtt.client as mqtt import json ORG home BUCKET brewery TOKEN 你的token influx InfluxDBClient(urlhttp://localhost:8086, tokenTOKEN, orgORG) write_api influx.write_api(write_optionsSYNCHRONOUS) def on_message(client, userdata, msg): try: data json.loads(msg.payload.decode(utf-8)) point Point(madeira) \ .field(temperature, data[temperature]) \ .field(humidity, data[humidity]) \ .field(pressure, data[pressure]) write_api.write(bucketBUCKET, recordpoint) except Exception as e: print(write error, e) mqtt_client mqtt.Client() mqtt_client.on_message on_message mqtt_client.connect(localhost, 1883, 60) mqtt_client.subscribe(madeira/sensor/#) mqtt_client.loop_forever()有一点要提醒时间戳默认是服务端当前时间如果你的传感器时钟不准也没有关系因为 MQTT 消息到达服务端的时间可以视为数据产生时间传输延迟在局域网内通常小于几十毫秒。如果你需要跨时区展示最好统一存 UTC展示时在 Grafana 里配置时区。3.3 可视化与告警Home Assistant 和 Grafana 联动数据进 InfluxDB 之后我同时用了两套展示系统。Home Assistant 负责告警和日常手机端查看Grafana 负责深度分析。Home Assistant 侧有两种接法一种是添加 MQTT 传感器实体直接读取 retain 消息另一种是集成 InfluxDB 数据源直接查询数据库。我更推荐前者因为 QTT 消息天然实时HA 判断自动化响应更快。在 configuration.yaml 里这样配置即可mqtt: sensor: - name: Madeira Temperature state_topic: madeira/sensor/weather value_template: {{ value_json.temperature }} unit_of_measurement: °C device_class: temperature - name: Madeira Humidity state_topic: madeira/sensor/weather value_template: {{ value_json.humidity }} unit_of_measurement: % device_class: humidityGrafana 侧则直接选择 InfluxDB 数据源写 Flux 查询就能画图。一个小技巧按时间范围自动聚合every(5m)或者every(1h)这样长时间曲线不会被每秒数据压垮并且能看到趋势。3.4 告警规则与阈值设计温度阈值我是参考马德拉酒储藏建议来设的范围 12~20°C湿度范围 50%~75%。具体告警规则不能只看单次读数因为传感器偶发毛刺很可能误报。我的做法是连续三次采样都越界才触发并且触发后至少 30 分钟内不重复通知这段冷却时间能防止压缩机启停造成的短暂波动刷屏。我这里给一个 HA 自动化示例条件是连续 3 次温度高于 21°C 就推送automation: - alias: Madeira temp high alert trigger: - platform: numeric_state entity_id: sensor.madeira_temperature above: 21 for: minutes: 3 condition: [] action: - service: notify.personal_telegram data: message: 高温告警当前 {{ states(sensor.madeira_temperature) }}°C虽然示例里用了 telegram实际你完全可以用邮件、钉钉机器人、Server酱、或者本地蜂鸣器。告警渠道不重要重要的是告警规则必须带迟滞和冷却不然一个晚上你就会被通知炸醒。4. 完整实操流程从焊板到出图4.1 硬件接线与烧录固件这一节是可以直接照着做的。清单如下ESP32 DevKitC 开发板 1 块BME280 模块 1 个Ⅰ²C 版本面包板或洞洞板、杜邦线若干5V/1A 电源适配器 USB 线接线方式非常简单。BME280 的 VCC 接 ESP32 的 3V3GND 接 GNDSCL 接 GPIO22SDA 接 GPIO21。注意有的模块需要把上拉电阻跳线焊上买模块时问卖家是不是默认支持 I²C很多廉价模块出厂时跳线是断开的导致读不到数据。固件我直接用 Arduino IDE arduino-esp32 插件代码参考如下#include WiFi.h #include PubSubClient.h #include Wire.h #include Adafruit_Sensor.h #include Adafruit_BME280.h const char* ssid 你的WiFi; const char* password 你的密码; const char* mqtt_server 192.168.1.100; const int mqtt_port 1883; WiFiClient espClient; PubSubClient mqttCli(espClient); Adafruit_BME280 bme; void connect_wifi() { WiFi.begin(ssid, password); while (WiFi.status() ! WL_CONNECTED) { delay(500); } } void connect_mqtt() { while (!mqttCli.connected()) { if (mqttCli.connect(madeira_node)) { mqttCli.publish(madeira/sensor/status, {\state\:\online\}, true); } else { delay(2000); } } } void publish_weather() { float t bme.readTemperature() 0.3; // 实测修正 float h bme.readHumidity(); float p bme.readPressure() / 100.0F; char json[128]; snprintf(json, sizeof(json), {\temperature\:%.2f,\humidity\:%.2f,\pressure\:%.2f}, t, h, p); mqttCli.publish(madeira/sensor/weather, json, true); } void setup() { Serial.begin(115200); connect_wifi(); mqttCli.setServer(mqtt_server, mqtt_port); connect_mqtt(); Wire.begin(21, 22); bme.begin(0x76); delay(300); } void loop() { if (!mqttCli.connected()) { connect_mqtt(); } mqttCli.loop(); publish_weather(); delay(60000); }这里我加了 0.3°C 的偏移补正不同批次 BME280 会有个体差异需要放上一支参考温度计对比后才能确定。如果买到的 BME280 地址不是 0x76可能是 0x77需要实测一下。4.2 配置 MQTT Broker 和数据采集服务Broker 我用 Docker 跑省得污染宿主机环境。一个简单的 docker-compose 文件长这样services: mqtt: image: eclipse-mosquitto:2 container_name: mosquitto ports: - 1883:1883 volumes: - ./mosquitto/config:/mosquitto/config - ./mosquitto/data:/mosquitto/data restart: unless-stopped记得在 mosquitto.conf 里开启 retain 支持并允许本地连接。数据采集服务也用 Docker 运行Python 脚本打包成镜像后启动配合 restart 策略保证异常退出自动拉起来。整体上我不建议在宿主机裸跑 Python 进程因为一旦环境变动部署行为就会变得不可预测。4.3 搭建 Grafana 看板与告警Grafana 部署同样用 Docker数据源选择 InfluxDB 时填入 URL、Token、Org、Bucket。创建一个新 Dashboard选择 Panel 类型为 Time series查询语句大体如下from(bucket: brewery) | range(start: v.timeRangeStart, stop: v.timeRangeStop) | filter(fn: (r) r[_measurement] madeira) | filter(fn: (r) r[_field] temperature) | aggregateWindow(every: 5m, fn: mean, createEmpty: false) | yield(name: mean)这个查询会把原始 1 分钟数据聚合为 5 分钟平均值曲线看起来更稳定。画完温度曲线后再复制一份改成湿度就得到一张双轴面板。告警也可以直接在 Grafana 里配置选择 Alert 规则每次评估间隔设 1 分钟条件设为当前值大于 21持续 3 分钟。不过我前面已经用了 Home Assistant 自动化Grafana 里就不重复告警避免“告警打架”。这里的核心原则是一个指标最多注册两个推送渠道多了只会让真正的异常淹没在噪音里。4.4 实际部署位置与校准经验传感器装好之后我花了整整一天做对测校准。拿一支经过校准的电子温湿度计放在同一个小环境里静置半小时每 10 分钟对比一次读数。我发现 BME280 的湿度比参考计低了约 4%RH温度高了 0.3°C这是芯片个体差异和放置角度带来的系统误差。在代码里加偏移量修正后再对比偏差收敛到 0.5%RH 以内。物理位置我最终固定在酒柜中部靠后的置物架上传感器探头上方不要堆放酒瓶保证空气流通。有朋友习惯把传感器贴在柜门上这是错误示范——柜门内侧温度往往更高而且开门瞬间水滴和热浪会直冲探头读数波动非常大影响所有联动的告警逻辑。5. 常见问题与排查技巧实录5.1 传感器读数跳变先怀疑电源和总线干扰我调试时碰到一个很头疼的问题温度读数每十几秒跳一次波动幅度达到一两度但用手摸传感器温度又是稳定的。排查方向其实很明确先看供电再看接线长度和总线干扰。因为 BME280 走 I²C 线长超过 20cm 后信号容易受周围电线干扰尤其是靠近压缩机电源线时读出来的数值会瞬间失真。解决方法是把传感器和 ESP32 之间的连接线控制在 15cm 以内如果必须延长建议使用屏蔽线或者直接把 BME280 焊在主控板上。同时我在代码里做了中值滤波连续读 5 次去掉最大值和最小值取中间 3 次的平均值。这个滤波逻辑虽然简单但对付偶发毛刺非常有效。5.2 信号弱或断线重连靠 MQTT LWT 和看门狗酒柜外壳是金属时Wi-Fi 穿透能力会打折扣。我的设备曾出现过“MQTT 连接已经断开但 HAL 还很自信”的状态导致不再发数据但还是亮着指示灯。更隐蔽的问题是 Broker 不知道设备掉了因为 TCP 断连检测需要时间。这个场景适合用 MQTT 的 Last Will and Testament遗嘱机制设备启动时注册遗嘱mqttCli.connect(madeira_node, madeira/sensor/status, 1, false, {\state\:\offline\});如果设备异常掉线Broker 会立刻向外广播“offline”HA 侧就能收到通知。另外我设置了 WiFi 看门狗如果超过 5 分钟没有成功发布消息就自动重启 ESP32保证节点不会长时间沉默。5.3 湿度传感器长时间漂移定期盐浴校准BME280 长期在 60%~75% 湿度环境里确实会出现湿度漂移我用了半年后对比过读数比刚校准时偏高约 4%RH。对于酒柜监控来说湿度偏差 4% 不至于致命但为了严谨还是得定期校准。业余条件下最简单的校准方式是盐浴法。找一个密封盒装入少量盐加一点点水调成糊状但不要淹没盐然后把传感器悬在盒子内不要碰触液体盖上盖子。在 25°C 附近饱和食盐水的平衡相对湿度约为 75%。等 12 小时后再看传感器读数如果和目标差得太多记录偏移量并在固件里修正。这么做至少每半年一次。5.4 告警轰炸冷却时间比阈值更重要最怕的不是告警不响而是持续告警把真正重要的信息淹没。有一次压缩机故障导致温度持续上扬不到半小时我的手机就被推送刷屏了。后面我在自动化里加了冷却时间告警触发后同一通道在 30 分钟内不再重复发送直到状态恢复正常一次再重新触发。这个逻辑对任何环境监控都适用远比你死磕阈值更有效。6. 扩展思路与个人体会做完整套系统我最大的感触是真正费心思的不是焊板和写代码而是“为长期稳定做取舍”。成品方案省心但壅塞DIY 方案自由但需要维护。为了减维护我刻意把每个环节都做得“无聊”——固定 IP、固定 Topic、固定读数频率传感器坏了就换同型号插上去代码都不用改。机器稳定运行三个月之后再回看那种“看不见它”的感觉才是最有成就感的。这套架构还可以继续扩展。我现在只监测一个酒柜如果以后加雪茄柜或者胶片箱只需要复制几个 ESP32 节点用新的 Topic 前缀区分比如madeira2/sensor/weather然后在 InfluxDB 里统一查询。Grafana 看板也可以按标签过滤几乎不用改服务端代码。最后分享一个压箱底的小技巧不要急着把传感器装进柜子再调参数。先在桌面通电跑一周连续记录温湿度摸清这个传感器的性格和漂移方向再上柜子做正式部署。桌面测试时记录的数据和正式环境有差异但至少能让你把滤波、阈值、重连逻辑调顺。如果这一步跳过大概率会把“环境异常”和“设备故障”混在一起后面排错会非常痛苦。这台 Madeira 系统后来帮我发现了一次酒柜门封条老化导致的夜间温度爬升。凌晨三点的推送我爬起来给门框涂了一圈密封胶顺手补了几瓶冰水进去降温第二天看曲线峰值只比平日高了两度。这件事让我确信花不到一百块和两个周末做一套本地监控比守着整柜酒不知道它们过得好不好安心太多了。