1. BrewUI是什么为什么自酿圈开始讨论这个界面层最近在逛自酿社区的时候发现 brewui 这个热词的出镜率越来越高。一开始我以为是某个新的酿酒软件后来动手折腾了一遍才明白它指的不是某一款具体的固件或者单一工具而是一套把自酿流程可视化、可控制的开源界面层方案。简单说BrewUI 的核心思路是把你家里那套酿酒设备——温度探头、加热棒、发酵柜、比重计——全部接进一个跑在浏览器里的控制面板你在手机或者电脑上就能看到当前发酵温度、目标温度、比重变化甚至直接远程切换发酵阶段。这套东西解决的痛点我太有体会了。我最早酿酒的头两年发酵温度基本靠一张贴在冰箱上的温度计早中晚各看一次手写记录。遇到冬天室温波动大一夜之间温度掉了五度第二天一看酵母罢工发酵提前停滞那一锅酒的风味基本就毁了。后来试过用 Inkbird 之类的温控插座能控制温度了但数据是“黑盒”的它只告诉你现在多少度不告诉你过去十个小时曲线是什么样的更不会把比重、糖度、品评记录放一起分析。所以当我第一次把 BrewUI 跑起来、看到浏览器里那条平滑的发酵温度曲线和重力变化曲线时心里最大的感受是这才是现代自酿该有的工具。BrewUI 适合谁用我觉得有三个层次。第一层是刚入坑的酿酒爱好者你可能还不想买昂贵的 Tilt 比重计只想低成本把温度监控做起来BrewUI 对硬件很宽容一块 ESP32 加几个 DS18B20 防水探头就能跑第二层是已经有一套温控设备、但受够了各个设备互相独立的“数据孤岛”的中级玩家你会需要统一界面和报警通知第三层则是爱折腾的开发型酿酒师BrewUI 本身是开源项目你会想往里面加新数据源、新展示组件、甚至接 Home Assistant。这篇文章我会尽量把三个层次的需求都覆盖到。需要先说明一句因为 BrewUI 在不同社区里被用得比较宽泛我没有拿着特定版本的官方文档来写而是基于这套界面层常见的部署形态和我在自酿自动化项目中的实际经验把通用流程梳理出来。你最终拿到手的具体版本可能略有差异但原理和数据链路基本一致照这个思路走不会偏。2. 架构与数据链路从传感器到浏览器里的完整路径2.1 三种部署形态本地单机、Docker 全家桶、云端访问BrewUI 这类自托管系统的部署方式实际跑起来无非三种形态。第一种是最省事的本地单机模式直接把 BrewUI 装在树莓派或者旧笔记本上传感器通过 USB 或 GPIO 直连界面只在内网访问。这种形态优点是功耗低、不依赖外网缺点是不方便出门查看报警通知需要额外做内网穿透。第二种是我推荐大多数人的 Docker 全家桶模式。一个树莓派或小主机上跑 Docker Compose里面同时起三个容器BrewUI 主程序、MQTT Broker我一般用 Mosquitto、数据库PostgreSQL 或 SQLite 看版本。传感器数据先发到 MQTTBrewUI 订阅 Topic 入库再呈现在界面上。这种解耦设计的好处是哪怕 BrewUI 临时崩了传感器数据还会在 MQTT 里留存重启后不会丢失关键曲线。第三种是加了反向代理和域名证书的云端访问模式。在 Docker 模式前面加一层 Nginx 或者 Caddy配合内网穿透工具就能在外网用 HTTPS 打开面板。我自己实测下来最舒服的组合是 Caddy 自动签证书加 Tailscale 组网但这属于进阶玩法新手建议先把本地跑通再考虑。三种模式的选择逻辑其实很简单如果你只是一个人在家里酿酒单机模式完全够用如果你有多个批次、多台设备或者出差期间喜欢盯着发酵曲线的强迫症那 Docker 模式是底线云端访问则取决于你有没有在外网看数据的硬需求。2.2 传感器数据是怎么流进 BrewUI 的不管哪种部署BrewUI 的数据链路本质上是同一条传感器采集 → 网关转发 → MQTT Broker → BrewUI 订阅 → 数据库持久化 → 浏览器渲染我举个最典型的例子。你买了几根 DS18B20 防水温度探头一根测发酵液温度贴桶壁保温棉下面一根测冰箱环境温度。它们接到 ESP32 上ESP32 跑一段 Arduino 或者 ESPHome 固件每隔 30 秒读取一次温度通过 WiFi 发到 MQTT Broker 上。MQTT 消息长这样{ device: fermenter_01, sensor: wort_temp, value: 18.6, unit: c, timestamp: 1734600000 }BrewUI 启动的时候会订阅特定的主题比如brewui/devices//temperature收到这条 JSON 后解析出数值存进数据库同时更新网页上对应设备的实时值。如果界面显示的是--那基本就是 Topic 路径不匹配或者 JSON 字段名对不上我在后面避坑部分会细说。比重数据则走另一条独立通道。Tilt 比重计是通过蓝牙广播的通常需要一个树莓派或者手机 App 做中转iSpindel 则是自带 WiFi 的 DIY 比重计可以直接通过 HTTP 或 MQTT 上报比重和温度。数据格式类似{ name: iSpindel_01, temperature: 19.1, gravity: 1.048, tilt: 38.5 }BrewUI 拿到重力数据后不仅会画一条比重下降曲线还会自动计算当前酒精度并在界面上估算发酵终点。这一步看起来简单实际操作中需要处理很多东西比如起始比重从哪来、什么时候锁定终点、比重计读数要不要做温度校正我在第五节讲校准的时候会展开。2.3 控制回路从目标温度到加热棒动作监控只是 BrewUI 的一半温控执行是另一半。它的控制逻辑不复杂你在配方或者批次设置里指定了当前发酵阶段的目标温度比如低温拉格 10°CBrewUI 就会持续比较“当前温度”和“目标温度”。如果温差大于回差它就向控制设备下发指令——一般是打开继电器或智能插座接通加热棒或压缩机的电源。这里有一个很多新手会搞混的点BrewUI 本身不是温控器它是下指令的大脑真正执行开关动作的是执行器。你可以用 5V 继电器模块加 SSR 固态继电器控制 220V 加热棒也可以用智能插座加被动散热。重要的是配置好执行器的“控制周期”我建议加热控制周期设到 10 到 15 分钟一个轮询制冷控制周期要更长一些避免压缩机频繁启停。因为压缩机启动那一下电流很大频繁启停非常伤压缩机这个坑我踩过后面细讲。3. 部署一套BrewUI硬件清单、Docker Compose与设备接入3.1 硬件准备清单预算从入门到进阶先列一份我实际跑过的硬件清单价格区间大概覆盖了从穷玩到小康的两档组件入门方案进阶方案作用主控树莓派 3B 或旧安卓机树莓派 4B/8G 或 NUC 类小主机跑 BrewUI 和数据库温度传感器DS18B20 防水探头 × 3DS18B20 或 PT100 高精度探头测桶温、环境温、常温网关ESP32 开发板ESP32 太阳能电池供电采集传感器转 MQTT比重计手动糖度计手动记录iSpindel 或 Tilt在线比重曲线执行器智能插座加热模式SSR 继电器模块 接触器控加热棒或发酵柜网络家用路由器足够千兆有线 UPS 备用电源保证数据不断流入门方案总成本可以控制在三百块左右进阶方案大概在一千到两千。我的建议是别一开始就买一堆传感器先把一套温度监控跑通再逐步加比重计和控制回路。3.2 Docker Compose 安装一份可以直接抄的配置如果你选择 Docker 模式我建议用下面这份 Compose 配置作为基础。注意要根据你的实际版本修改镜像名和数据目录version: 3.8 services: mosquitto: image: eclipse-mosquitto:2 container_name: brewui-mqtt ports: - 1883:1883 volumes: - ./mosquitto/config:/mosquitto/config - ./mosquitto/data:/mosquitto/data restart: unless-stopped brewui: image: ghcr.io/brewui/brewui:latest container_name: brewui ports: - 8080:8080 environment: - DB_PATH/data/brewui.db - MQTT_BROKERmosquitto:1883 - MQTT_USERNAMEbrewui - MQTT_PASSWORDstrong_password volumes: - ./brewui/data:/data depends_on: - mosquitto restart: unless-stopped把上面的内容存成docker-compose.yml然后执行docker compose up -d等三十秒左右浏览器访问http://树莓派IP:8080应该就能看到初始化页面。第一次进入会让你创建管理员账号、设置 MQTT 连接信息照着填就行。这里有一个值得注意的细节MQTT 的用户名和密码不要复用你自己系统的 root 密码。因为 Mosquitto 默认允许匿名连接如果你在配置里没关匿名整个局域网的人都能看到你的传感器数据虽然这不算什么大秘密但毕竟没必要敞开。我自己的做法是在 Mosquitto 配置里加上allow_anonymous false然后给 BrewUI 单独建一个只读订阅账号。3.3 设备接入主题、字段名和显示名字的坑设备接入是整套系统里最容易烦躁的环节也是最值得仔细打磨的环节。在 BrewUI 里添加一个设备本质上要填三样东西设备 token、数据 Topic、字段映射规则。设备 token 是 BrewUI 给你这个设备分配的唯一标识传感器发上来的数据里必须带上它系统才知道这条数据属于哪个设备。主题路径则需要和网关固件里设置的完全一致。我强烈建议从一开始就统一成这样的命名规则brewui/{device_token}/telemetry传感器网关端的数据结构尽量简洁BrewUI 通常能自动识别常见字段名。如果你用的传感器字段名比较特殊比如某些固件会把温度写成temp_c而不是temperature那就需要到设备设置里把字段映射关系改一下。这里我建议你写一个小工具或者直接用一个 MQTT 客户端先手动发一条测试数据确认 BrewUI 能正常接收再接真实传感器能省下大量排查时间。显示名字也别随便起。我见过不少人把设备名起成sensor1、sensor2跑了两周之后根本分不清哪根探头对应哪个位置。我的习惯是直接命名成发酵桶温度、冰箱环境温度、室温参考并在备注里写下探头的物理位置和接线颜色方便日后检修。4. 配方、批次与自动温控把啤酒酿造流程装进数据库4.1 配方数据结构为什么我要把配方数字化BrewUI 真正拉开和普通温度计差距的是它把配方和批次数据绑在了一起。我曾经用纸质配方文件夹每张纸上手写着原料、时间、比重记录做完全凭感觉。数字化之后有些背后的逻辑你需要理解。一个典型的啤酒配方包含这些字段配方名称、风格、目标批次量、煮沸时间、麦芽列表各品种重量和潜在出糖率、酒花列表品种、添加时间、数量、α 酸、酵母种类和发酵温度范围、期望起始比重和终点比重、色度 SRM、苦度 IBU。BrewUI 拿到这些字段不只是做展示它会帮你自动计算效率、换算不同批量下的用量甚至在批次进行中结合当前比重估算实际糖化效率。我在实际使用中发现配方结构里最重要的其实是“目标终点比重”和“发酵温度阶梯”这两个字段。很多新手不填目标终点结果发酵跑了一个月还差一点没到目标不知道是该继续等还是该升温催一催。有了这两个字段BrewUI 的进度条会告诉你目前完成了多少百分比提示你是正常推进还是偏离预期。4.2 批次生命周期从投放酵母到装瓶入库批次是配方的“运行实例”。我的工作流是糖化煮沸之后把麦汁放进发酵桶在 BrewUI 里创建一个新批次选择对应配方填入实际起始比重、酵母投放时间然后绑定温度设备、比重设备和执行器。创建完批次后系统会自动生成一个发酵时间轴。下面这个表是一个比较典型的艾尔批次时间轴时间阶段目标温度操作第 0-3 天主发酵18°C投放酵母保持低温第 4-6 天升温还原21°C双乙酰还原提高温度第 7-10 天熟化12°C慢慢降温让酵母沉降第 10-14 天冷沉/包装2°C冷沉后装瓶或装桶每个阶段都可以设定目标温度和持续时间。BrewUI 的自动控制逻辑很简单当前时间进入哪个阶段就自动把执行器的目标温度设为那个阶段的温度。我特别建议打开阶段切换提醒这样到升温还原那一天手机会收到通知你就可以顺便去测一下比重确认主发酵是不是接近尾声。这里有个取舍问题是按时间切阶段还是按比重切阶段我做的最初几批是纯按时间切结果低温发酵时酵母活性差三天根本发不完按时间升了温酯类物质产生过多风味偏杂醇。后来我改成“时间 比重双重条件”比如主发酵阶段必须满足两个条件才算完成——至少过了 4 天并且实际比重比目标终点比重高出 0.008 以内。这样操作下来批次质量稳定多了。4.3 自动温控背后的啤酒酿造逻辑自动温控不是简单的“到了 20 度就加热”要理解它背后的酿造逻辑才能用得好。酵母在发酵过程中本身会产热一个 20 升发酵桶在高峰发酵期麦汁温度可能比环境温度高出 3 到 5 度。如果你把探头贴在发酵桶外壁测得是环境温度而不是发酵液真实温度就会出现“控温控了个寂寞”的情况。所以我的建议是至少用两根探头一根用保温棉贴在发酵桶外壁和桶身中间测“桶壁温度”用来做控制另一根悬吊在发酵柜里测“环境温度”用来做参考。桶壁温度比液温有几小时延迟比环境温度更接近真实液温用它做控制源比直接用环境温度准得多。另一个细节是升温与降温的优先级。BrewUI 的默认逻辑通常是先判断温度是否超出回差范围超出上限就开制冷低于下限就开加热。但在冬季和夏季环境温度可能持续偏向一侧这时候你需要手动调整执行器的最大工作时间防止加热棒一直开着导致局部过热。比如我用 60W 加热带冬天发酵柜内温度比目标低 5 度时如果持续加热超过 25 分钟温度还是上不去我就知道保温出问题了而不是继续加时间。5. 实战两个月后的避坑总结校准、报警、断线与温控调参5.1 温度传感器校准偏差不是玄学是物理规律DS18B20 这类传感器标称精度是 ±0.5°C听起来不错但实际使用中你会发现读数偏个 1 到 2 度很正常。原因很简单探头外壳和被测液体之间存在热阻加上你安装的位置偏了温差就出来了。我采用的校准方法是“冰水浴两点校准”。先取一个大保温杯装满冰水混合物等 10 分钟后把探头放进去记录稳定读数再用刚烧开的水做第二个点记录沸水读数。理想状态下一个是 0°C一个接近 100°C根据当地海拔修正。两个数据点确定一条偏差直线然后到 BrewUI 设备设置里填偏移量和斜率。如果系统只支持固定偏移那就在中温区20-25°C校准因为酿酒控制基本都在这个区间。实际操作中最让人抓狂的是 DS18B20 偶尔读数异常要么显示 85°C 不动要么显示 -127°C。这基本可以断定是接线问题。85°C 通常是传感器数据线短路到电源线-127°C 则是信号线断开。排查顺序是检查三根线的杜邦头有没有松动确认是否接了 4.7kΩ 上拉电阻最后再看线缆长度超过两米时要换质量好一点的屏蔽线。我有一段时间读数乱跳折腾了大半天最后发现是 ESP32 开发板的电源不稳定换了个 5V/2A 的电源适配器就解决了。5.2 报警规则设置阈值和持续时长的平衡BrewUI 的报警系统如果不配置等于白装。但配置得太激进一天到晚响个不停最后你反而会选择无视它跟没配一样。我的经验是报警要设两个维度一个是“超限值”另一个是“超限持续时间”。打个比方你的目标温度是 18°C回差设 ±1°C。如果只是温度瞬时到 19.5°C不值得报警因为酒体本身有很大热惯性波动是很正常的。但如果持续 30 分钟以上超过 19.8°C说明执行器可能坏了或者发酵太猛烈这时候才需要推通知。这个“持续时间”设定是报警系统不变成噪音的关键。通知渠道方面我最常用的是 Telegram Bot 和 ntfy.sh。Telegram 胜在可以发一条包含温度数值和批次的富文本消息简单例子是这样{ chat_id: 123456789, text: 发酵桶温度偏高当前 20.2°C目标 18.0°C持续 35 分钟 }ntfy.sh 则更轻量一行 curl 就能推送还支持按 topic 订阅。我的建议是至少配两个渠道一个手机推送一个备用邮件或者 Webhook防止单一渠道挂了连不上。经历过半夜 2 点发现自己睡死过去、报警推送没人看、最终那批拉格出了异味之后我就学会了给报警系统设双重保险。5.3 断线重连与数据补录发酵曲线不能有黑洞自酿自动化最怕的就是夜里 WiFi 断连第二天一看曲线缺了一段。你说这段数据重要吗可能没那么重要但长期看不到完整曲线你会慢慢对系统失去信任。我这里给出三个层面的防护策略。第一层是 MQTT 端设置遗嘱消息和保留消息网关掉线后 Broker 会广播离线事件BrewUI 立刻把设备标记为离线并触发提示。第二层是网关固件里加数据缓存ESP32 上用 SPIFFS 或者一个小环形缓冲区断网时本地暂存温度读数恢复连接后再补发。第三层是 BrewUI 端打开自动续点功能至少保证历史曲线平滑过渡。如果你用的是 iSpindel 这类自带 WiFi 的设备断线问题会少很多但它用的是 HTTP 上报而非 MQTT 长连接每次上报都是一次独立的请求。我遇到过 iSpindel 睡眠后醒来 IP 变化导致 Mesh 网络无法识别的问题最后在固件里固定了静态 IP 才解决。硬件层的稳定性永远是软件层无法替代的这一点怎么强调都不过分。5.4 温控调参回差、比例带和压缩机保护温控不是把目标温度设好就完事参数调不好温度会在目标值附近来回震荡。BrewUI 里最需要调的两个参数是回差hysteresis和轮询周期。回差的意思简单说就是目标温度 18°C回差设为 1那系统会在温度降到 17°C 时开始加热升到 19°C 时停止加热。回差太小比如 0.2°C会导致执行器频繁启停加热棒寿命缩短发酵温度波动反而更激烈回差太大比如 2°C温度控制精度又不够。我自己的经验是加热模式回差 0.8-1°C制冷模式回差 1-1.5°C在稳定性和精度之间是比较平衡的区间。如果 BrewUI 支持 PID 模式你可以用表格里这组参数做起点参数加热回路建议值制冷回路建议值比例带2.0°C3.0°C积分时间90 分钟120 分钟微分时间15 分钟20 分钟控制周期10 分钟15 分钟这个参数组合不算唯一解但它能保证你在绝大多数家用发酵柜上不至于震荡太严重。重点是理解 PID 的直觉逻辑比例带越小加热越猛积分时间越短系统对长期偏差的纠错越激进。初期不要追求完美曲线先用一个稳定但不完美参数跑两批等摸清设备的惯性后再逐步调紧。6. 进阶思路与我的实际感受当你把 BrewUI 用顺了以后很容易开始琢磨更多玩法。我目前用得比较多的进阶功能有两个。第一个是多批次对比分析。以往我一个批次换个配方很难说清楚“上次那批酒为啥好喝”到底是酵母状态的问题还是发酵温度曲线的问题。现在所有历史批次的数据都存在 BrewUI 里我会把酒评分数、品鉴笔记和发酵曲线放在一起看。慢慢发现一个规律凡是我在温度曲线平稳、没有大波动的批次品鉴分数平均高出 3 到 5 分。这说明稳定的发酵温度对风味的贡献可能比某些昂贵的新潮原料更明显。第二个是外部系统联动。BrewUI 的数据接口是开放的我目前把它接进了 Home Assistant做了一件挺酷的事当发酵进入冷沉阶段时Home Assistant 会在家里那盏氛围灯上显示蓝色当冷沉结束可以装瓶了灯会变成绿色。这种联动看似花哨实际上很有用它让“监控系统”变成“提醒系统”我不用整天打开 BrewUI 盯着数字看。如果你问我对 BrewUI 这套方案的整体感受我的评价是它不是那种开箱即用、零维护的消费级产品但它的上限完全取决于你愿意投入多少折腾时间。我记得第一次看到完整的发酵曲线在网页上铺开时的激动心情那种十几公斤麦芽、十几个小时酿造、无数次测量记录被一个界面收拢的感觉确实是值得回味的体验。它的门槛不低传感器、MQTT、Docker 这些词劝退了很多人但每一步的坑都会让你更懂整个发酵系统的运作原理。对自酿爱好者来说这种“知其然也知其所以然”的收获可能比省下的那点温度波动更有价值。