去年在朋友的小酒廠盯了整整一個發(fā)酵季的Excel表格之后我終于受不了了。每天去罐邊抄溫度、記比重、算失重數(shù)據(jù)記在紙質(zhì)本子上回頭要復(fù)盤時還得一張張拍照翻聊天記錄。發(fā)酵這件事本身已經(jīng)夠復(fù)雜了我不想讓記錄這件事再拖后腿。于是就有了Madeira這套系統(tǒng)的雛形——一個用低成本硬件自建的發(fā)酵數(shù)據(jù)記錄平臺可以長期放在發(fā)酵罐旁邊自動采集溫度、pH、重量最后生成曲線和異常報警讓我不用再守著罐子看數(shù)據(jù)。Madeira這個名字是和一位釀酒師朋友敲定的。馬德拉酒最出名的特點是陳年過程中反復(fù)受熱和氧化風(fēng)味反而變得復(fù)雜而有層次。我希望這套系統(tǒng)也能像馬德拉酒一樣把平時容易忽略的細(xì)節(jié)記錄下來讓它們在時間的沉淀里變成真正有用的歷史數(shù)據(jù)。說白了這個項目做的是“給發(fā)酵過程記筆記”只是這個筆記是用傳感器和數(shù)據(jù)庫來寫的。這套系統(tǒng)適合什么人我認(rèn)為主要有三類。第一類是小型精釀工坊的釀酒師需要長期跟蹤發(fā)酵過程但不想花幾千塊去買商業(yè)記錄儀也不希望數(shù)據(jù)被鎖在某個廠商的App里第二類是家庭釀造愛好者想用業(yè)余時間做出一套能跑、能看、能報警的自動化監(jiān)測裝置第三類是做康普茶、酸奶、奶酪這類發(fā)酵食品的手工食品愛好者原理完全一樣換個傳感器和量程就能復(fù)用。今天的文章我會把整個項目從思路、選型到實操、避坑的過程完整講一遍。1. 項目整體設(shè)計與思路拆解1.1 核心需求與方案取舍做這個項目的第一步不是買傳感器而是先想清楚到底要解決什么問題。發(fā)酵記錄這件事拆開來看有四個核心需求實時性每隔一段時間就要能看到當(dāng)前發(fā)酵狀態(tài)不能等到發(fā)酵結(jié)束才拿到數(shù)據(jù)。歷史性一個發(fā)酵周期可能持續(xù)7天、14天甚至30天數(shù)據(jù)要能完整回放重啟、斷電都不能丟?？蓤缶?dāng)溫度、pH偏離設(shè)定區(qū)間時要能及時通知我否則半夜出了問題只能第二天早上才發(fā)現(xiàn)。可導(dǎo)出數(shù)據(jù)格式要開放最好能導(dǎo)出CSV或直接查數(shù)據(jù)庫方便后續(xù)做復(fù)盤和工藝調(diào)整。這四個需求單獨看都不難聚在一起就關(guān)系到架構(gòu)選擇。我最初考慮過兩種方案一種是完全用現(xiàn)成的商業(yè)物聯(lián)網(wǎng)平臺把數(shù)據(jù)傳到云端手機上查看另一種是本地自建一套輕量級服務(wù)數(shù)據(jù)全部落在自己控制的存儲里。最終我選了第二種。理由很直接釀酒數(shù)據(jù)的價值在于長期積累如果數(shù)據(jù)傳到了第三方平臺平臺的接口調(diào)整、服務(wù)停運、收費變化都會讓歷史數(shù)據(jù)變成一堆無法讀取的黑箱。而本地自建雖然前期要折騰一下但數(shù)據(jù)的管理權(quán)完全在自己手里哪怕三年后回頭整理導(dǎo)出一份CSV就能還原整個發(fā)酵過程。1.2 整體架構(gòu)與數(shù)據(jù)流確定了自建路線之后我把系統(tǒng)分成了三層采集層、核心層、展示層。采集層由主控板和傳感器組成負(fù)責(zé)定時讀取溫度、pH、重量等數(shù)據(jù)然后通過局域網(wǎng)HTTP請求發(fā)送給核心層。核心層運行在一臺低功耗小主機上負(fù)責(zé)接收數(shù)據(jù)、校驗清洗、寫入數(shù)據(jù)庫同時執(zhí)行報警判斷。展示層是一個輕量級網(wǎng)頁接口把數(shù)據(jù)庫里的記錄讀取出來形成曲線和表格。這個架構(gòu)最大的好處是松耦合。采集端只要按照固定的JSON格式把數(shù)據(jù)POST到接口后端不關(guān)心你用的是哪個型號的溫度探頭還是稱重模塊。以后想增加二氧化碳濃度傳感器或者把pH測量改成自動進(jìn)樣只需要在采集端改動后端代碼一個字符都不用變。這種“接口固定、內(nèi)部自由”的設(shè)計在實際使用中幫我省了很多事。1.3 為什么不用現(xiàn)成的發(fā)酵記錄儀市面上其實已經(jīng)有不少現(xiàn)成的發(fā)酵記錄設(shè)備比如一些帶WiFi的溫濕度記錄儀配套的手機App也能看曲線。但它們普遍有幾個問題數(shù)據(jù)導(dǎo)出往往要額外收費報警推送方式很單一大多數(shù)只能接一種類型的傳感器。更有意思的是很多設(shè)備的云端服務(wù)需要廠商服務(wù)器正常運轉(zhuǎn)才能用一旦廠商停止維護設(shè)備就變成了廢鐵。對釀酒來說我更在意數(shù)據(jù)的可追溯性和可組合性。發(fā)酵罐旁邊不只有一個測點可能是罐體溫度、環(huán)境溫度、環(huán)境濕度、失重曲線同時存在。商業(yè)設(shè)備一臺管一種傳感器數(shù)據(jù)還散落在不同的App里。自己做這套系統(tǒng)只需要在總線上掛不同的模塊所有數(shù)據(jù)最終匯入同一個數(shù)據(jù)庫前后對比非常方便。2. 核心細(xì)節(jié)解析與實操要點2.1 傳感器選型溫度、pH、重量怎么搭配發(fā)酵監(jiān)測最常用的三類傳感器我根據(jù)自己的實測經(jīng)驗整理成了一張對比表傳感器類型采集內(nèi)容推薦模塊/方案精度與誤差注意事項溫度探頭液體或環(huán)境溫度DS18B20防水?dāng)?shù)字探頭±0.5℃穩(wěn)定性好單總線可并聯(lián)多個長線需上拉電阻pH傳感器液體酸堿度Analog pH meter如DFRobot需要校準(zhǔn)長期浸泡會漂移不要長期泡在發(fā)酵液里定期用標(biāo)準(zhǔn)液校準(zhǔn)稱重模塊發(fā)酵罐重量HX711稱重傳感器承重板精度受電源紋波影響大必須做滑動平均濾波防止讀數(shù)抖動溫度探頭是整個系統(tǒng)里最可靠的部分。DS18B20是數(shù)字傳感器走單總線協(xié)議一條總線上可以掛多個探頭每個探頭有唯一地址通過編程就能區(qū)分。防水封裝版本可以直接放進(jìn)發(fā)酵液里但要注意長期浸泡后探頭表面會結(jié)一層生物膜影響導(dǎo)熱測出的溫度會比實際偏低。我的經(jīng)驗是每兩周把探頭拿出來用清水沖洗一下。pH傳感器是最需要小心的。它本質(zhì)上是模擬傳感器輸出信號會隨時間和水質(zhì)發(fā)生變化如果不校準(zhǔn)讀數(shù)會慢慢漂移。日常使用中我每三天用pH 4.0和6.86的標(biāo)準(zhǔn)液做一次兩點校準(zhǔn)。因為麻煩所以我在系統(tǒng)里把pH設(shè)計成“可選上報字段”不是每次采樣都要求有值但一旦上報就會保留下來足夠畫出一條相對平滑的趨勢線。重量傳感器用HX711模塊比較多它是24位高精度ADC可以直接和稱重傳感器連接。這個模塊最大的問題是容易受電源紋波影響在持續(xù)通電情況下單片機供電不穩(wěn)會導(dǎo)致同一時刻讀數(shù)來回跳。后面我會專門講怎么用濾波解決。2.2 數(shù)據(jù)接口設(shè)計與防重處理采集端與核心層之間的數(shù)據(jù)交換我設(shè)計成一個極簡的HTTP JSON接口。主控板每次采樣后把數(shù)據(jù)拼成下面的格式POST到服務(wù)端payload { device_id: fermenter-01, ts: 1612345678, temp: 20.3, ph: 3.85, weight_grams: 21500 }每個字段的含義都很明確device_id標(biāo)記數(shù)據(jù)來源ts是Unix時間戳后面是各個指標(biāo)的數(shù)值。為什么用HTTP POST而不是MQTT原因有兩個。第一家庭局域網(wǎng)環(huán)境下HTTP協(xié)議足夠簡單直接任何編程語言都能方便地構(gòu)造請求第二MQTT需要一個獨立的Broker服務(wù)對這套項目來說增加了不必要的維護成本。防重復(fù)是必須考慮的問題。主控板通過WiFi上報數(shù)據(jù)時經(jīng)常會遇到網(wǎng)絡(luò)抖動導(dǎo)致請求超時但服務(wù)端已經(jīng)寫庫成功。如果采集端在超時后重試就會寫入兩條相同時間戳的數(shù)據(jù)。我的做法是在數(shù)據(jù)庫層面加唯一約束同一設(shè)備同一時間戳只保留一條記錄寫入時使用INSERT OR IGNORE。這個處理雖然樸素但非常有效能徹底避免重復(fù)數(shù)據(jù)干擾曲線。2.3 數(shù)據(jù)庫表結(jié)構(gòu)與存儲選型有人看到“數(shù)據(jù)庫”三個字就想到要安裝MySQL或PostgreSQL其實沒必要。家庭項目的數(shù)據(jù)量很小一天撐死幾千條記錄用一個SQLite單文件數(shù)據(jù)庫完全夠用還免去了安裝配置的麻煩。我的表結(jié)構(gòu)設(shè)計如下CREATE TABLE readings ( id INTEGER PRIMARY KEY AUTOINCREMENT, device_id TEXT NOT NULL, ts INTEGER NOT NULL, temp REAL, ph REAL, weight_grams REAL, UNIQUE(device_id, ts) ); CREATE TABLE alerts ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts INTEGER NOT NULL, device_id TEXT NOT NULL, metric TEXT NOT NULL, value REAL, threshold REAL, message TEXT );兩張表的分工很明確readings存原始采樣數(shù)據(jù)alerts存報警事件。為什么報警要單獨建表因為報警是“偏離正常區(qū)間”的離散事件和周期性的采樣記錄結(jié)構(gòu)不同單獨存放可以避免重復(fù)掃描全表也方便在界面上高亮顯示異常時間點。SQLite有一個優(yōu)勢特別適合這個場景備份就是復(fù)制文件。每天晚上用一條crontab命令把madeira.db復(fù)制到另一塊硬盤或者網(wǎng)盤數(shù)據(jù)安全就有了基本保障不用搞復(fù)雜的數(shù)據(jù)庫主從復(fù)制。3. 實操過程與關(guān)鍵環(huán)節(jié)實現(xiàn)3.1 第一步搭建本地后端服務(wù)后端我用的是Python加FastAPI框架。選FastAPI而不是Flask主要是因為異步接口寫起來順手而且自帶數(shù)據(jù)校驗?zāi)芰m合處理傳感器上報這類高頻小請求。安裝環(huán)境的過程很簡單mkdir madeira cd madeira python3 -m venv .venv source .venv/bin/activate pip install fastapi uvicorn然后在項目目錄建一個main.py寫下最核心的接收接口from fastapi import FastAPI, Request import sqlite3 import time app FastAPI() def get_db(): return sqlite3.connect(madeira.db) app.post(/api/readings) async def receive_reading(req: Request): data await req.json() # 校驗必需字段 required {device_id, ts, temp} if not required.issubset(data.keys()): return {status: error, msg: missing fields} conn get_db() conn.execute( INSERT OR IGNORE INTO readings (device_id, ts, temp, ph, weight_grams) VALUES (?,?,?,?,?), (data[device_id], data[ts], data.get(temp), data.get(ph), data.get(weight_grams)) ) conn.commit() conn.close() return {status: ok}這段代碼是整個系統(tǒng)的心臟邏輯很直白接收J(rèn)SON校驗必要字段寫入數(shù)據(jù)庫。INSERT OR IGNORE保證了重復(fù)數(shù)據(jù)不會插入。實測在局域網(wǎng)環(huán)境下這個接口單次響應(yīng)時間在10毫秒以內(nèi)哪怕一秒來一條數(shù)據(jù)也完全扛得住。初始化數(shù)據(jù)庫可以用一條Python命令或者直接用sqlite3命令行工具執(zhí)行建表語句。我習(xí)慣在main.py的同目錄放一個init_db.py腳本每次測試前干凈重建。3.2 第二步編寫主控板采集程序主控板我選了ESP32搭配MicroPython環(huán)境。DS18B20溫度探頭接在一個GPIO引腳上HX711稱重模塊接在另外兩個引腳上。采集程序的邏輯是啟動后連接WiFi循環(huán)執(zhí)行“讀探頭、拼JSON、POST上報、等待下一次采樣”。下面是溫度采集部分的簡化代碼import machine import onewire import ds18x20 import network import urequests import time # 初始化DS18B20溫度傳感器 ow onewire.OneWire(machine.Pin(4)) ds ds18x20.DS18X20(ow) roms ds.scan() # 連接WiFi wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(home-ap, password) while not wlan.isconnected(): time.sleep(1) def upload(temp, weight): payload {\device_id\:\fermenter-01\,\ts\:%d,\temp\:%.2f,\weight_grams\:%.1f} % (time.time(), temp, weight) try: res urequests.post(http://192.168.1.10:8000/api/readings, datapayload, headers{Content-Type: application/json}) res.close() except Exception as e: print(upload failed:, e) while True: ds.convert_temp() time.sleep_ms(750) temp ds.read_temp(roms[0]) upload(temp, read_weight()) time.sleep(600) # 每10分鐘上報一次這里的采樣間隔我設(shè)成了600秒也就是10分鐘一次。為什么不是每秒鐘都上報因為發(fā)酵本身是一個緩慢的過程溫度變化很少會在幾分鐘內(nèi)劇烈波動10分鐘一個點已經(jīng)能畫出一條非常平滑的曲線同時還能顯著降低ESP32的功耗和網(wǎng)絡(luò)請求頻率。如果你做的是對溫度極敏感的發(fā)酵可以改成60秒但要注意WiFi模塊頻繁喚醒會發(fā)熱主控板別放在封閉的泡沫箱里。HX711的讀數(shù)函數(shù)需要單獨處理直接讀取原始值是不穩(wěn)定的。我的做法是連續(xù)采樣10次去掉最大最小值后取平均def read_weight(): values [] for _ in range(10): values.append(hx711.read()) time.sleep_ms(50) values.sort() return sum(values[2:-2]) / len(values[2:-2])這個簡單的濾波已經(jīng)能顯著減少抖動。后面在常見問題里我還會補充更系統(tǒng)的處理方法。3.3 第三步實現(xiàn)曲線查詢和報警判斷數(shù)據(jù)進(jìn)來之后光存在數(shù)據(jù)庫里沒有意義要能看、能報警才算完整。我先寫一個曲線查詢接口按設(shè)備和時間范圍返回記錄app.get(/api/curve) def get_curve(device_id: str, hours: int 24): start_ts int(time.time()) - hours * 3600 conn get_db() rows conn.execute( SELECT ts, temp, ph, weight_grams FROM readings WHERE device_id? AND ts? ORDER BY ts ASC, (device_id, start_ts) ).fetchall() conn.close() return {data: [dict(zip([ts, temp, ph, weight], r)) for r in rows]}前端用Chart.js做一個簡單的曲線圖每次頁面刷新時調(diào)用這個接口。為了不引入構(gòu)建工具我直接寫了一個靜態(tài)HTML文件放在FastAPI的static目錄下通過瀏覽器打開就能看到實時曲線。這樣做雖然簡陋但足夠可靠不需要Node環(huán)境和打包步驟。報警判斷我放在了接收接口里每次寫入讀數(shù)后立刻檢查該讀數(shù)的值和最近N條數(shù)據(jù)的中位數(shù)如果偏差超過閾值就寫入alerts表。為什么不直接用原始值判斷因為單個突刺可能來自傳感器干擾直接報警會造成大量誤報。我在報警邏輯里加了一個滑動窗口取最近5個點的中值做平滑def should_alert(device_id, metric, value): conn get_db() rows conn.execute( SELECT metric FROM readings WHERE device_id? ORDER BY ts DESC LIMIT 5, (device_id,) ).fetchall() conn.close() if len(rows) 3: return False vals sorted([r[0] for r in rows if r[0] is not None]) median_val vals[len(vals) // 2] return abs(value - median_val) ALERT_THRESHOLD[metric]這個函數(shù)只在每個采樣點調(diào)用一次性能開銷完全可以忽略。當(dāng)判斷結(jié)果超過閾值時服務(wù)端會向一個釘釘群機器人或者自定義Webhook發(fā)一條通知方便我在手機上第一時間掌握異常情況。3.4 第四步部署到低功耗小主機并開機自啟核心層我跑在一臺舊筆記本上安裝了Ubuntu Server連上路由器放在角落。為了確保重啟后服務(wù)能自動啟動我寫了一個systemd服務(wù)單元文件[Unit] DescriptionMadeira record service Afternetwork.target [Service] WorkingDirectory/home/pi/madeira ExecStart/home/pi/madeira/.venv/bin/uvicorn main:app --host 0.0.0.0 --port 8000 Restartalways RestartSec5 [Install] WantedBymulti-user.target操作方法如下sudo cp madeira.service /etc/systemd/system/ sudo systemctl enable --now madeira.service sudo systemctl status madeira.service這段配置里我最看重Restartalways。傳感器長期掛在現(xiàn)場偶爾會遇到電源波動或系統(tǒng)內(nèi)存不足導(dǎo)致進(jìn)程退出沒有這個配置服務(wù)死了就是死了要等人發(fā)現(xiàn)才恢復(fù)。設(shè)置成5秒后自動重啟能最大程度保證系統(tǒng)的無人值守能力。4. 常見問題與排查技巧實錄4.1 溫度探頭讀數(shù)整體偏高或偏低這個現(xiàn)象我遇到過好幾次表現(xiàn)不是隨機跳變而是整體偏移。比如某一天后半夜溫度曲線突然比前一夜高了1℃其他條件都沒變。排查后才發(fā)現(xiàn)是探頭表面結(jié)了一層看不見的生物膜影響了熱傳導(dǎo)。處理辦法很簡單把探頭拿出來用清水沖洗再用干凈的軟布擦干。注意不要用硬刷否則會破壞防水密封層。另外還有一種可能是探頭位置移動了。發(fā)酵罐底部溫度通常比液面中層高0.5℃左右如果探頭從罐體上部滑到了底部曲線就會出現(xiàn)平臺式抬升。解決辦法是在安裝時給探頭做一個固定支架不讓它在發(fā)酵液中飄動。4.2 數(shù)據(jù)庫里連續(xù)幾小時沒有數(shù)據(jù)排查這種問題時我有一套固定的順序檢查項方法常見原因主控板連接狀態(tài)看ESP32的LED指示燈或串口日志W(wǎng)iFi掉線網(wǎng)關(guān)連通性ping主控板的IP地址設(shè)備休眠、天線位置差服務(wù)端日志journalctl -u madeira.service服務(wù)崩潰、端口沖突數(shù)據(jù)庫寫入查詢readings表最新記錄接口校驗失敗最常見的坑是ESP32的WiFi長時間運行后自動斷開。MicroPython環(huán)境下WiFi連接不是長連接掉線后不會自動重連必須在上報前檢查連接狀態(tài)如果斷開就主動重新連接。我在代碼里加了一個簡單的檢查邏輯if not wlan.isconnected(): wlan.disconnect() wlan.connect(home-ap, password) while not wlan.isconnected(): time.sleep(1)這段代碼雖然簡單但解決了我90%的掉線問題。4.3 重量數(shù)據(jù)頻繁抖動HX711稱重模塊最大的敵人是電源紋波。ESP32在WiFi發(fā)射瞬間會有較大的電流波動這個波動會通過供電線路傳到HX711的參考電壓上導(dǎo)致ADC讀數(shù)跳變。我用過兩個解決方案效果都不錯。第一個方案是硬件隔離給HX711模塊單獨做一組電源濾波用100微法電解電容加0.1微法陶瓷電容并聯(lián)放在模塊的VCC和GND之間。第二個方案是軟件濾波在讀取函數(shù)里執(zhí)行“連續(xù)采樣10次排序后去掉最大最小各兩個取中間值平均”的算法。兩者結(jié)合后我的稱重模塊讀數(shù)穩(wěn)定性從±5克降到了±2克以內(nèi)完全滿足失重法觀察發(fā)酵速率的精度需求。4.4 報警太多成了狼來了報警功能剛上線時我最頭疼的其實是誤報。只要某一個采樣點瞬時波動稍微大一點就會觸發(fā)一次報警推送一天下來手機響個不停。后來我做了兩個改進(jìn)一是報警判斷使用5個點的中值過濾而不是單個點比較二是同一個設(shè)備同一指標(biāo)在30分鐘內(nèi)只報警一次防止重復(fù)轟炸。實現(xiàn)方式就是在alerts表后加一個查詢檢查最近一次報警的時間戳距離是否超過1800秒。這個方法已經(jīng)被我提煉成一個獨立的函數(shù)并針對不同指標(biāo)單獨配置冷卻時間。發(fā)酵溫度每天的變化本來就是緩慢的連續(xù)多天報警通常說明是真有問題而不是干擾。5. 關(guān)于這個項目我的實際操作體會整套系統(tǒng)從開始動手到穩(wěn)定運行前后花了一個多月時間。中間踩過的坑不少但我最大的體會是這個項目真正值錢的不是那幾根曲線也不是報警推送而是讓我養(yǎng)成了“對數(shù)據(jù)負(fù)責(zé)”的習(xí)慣。以前看一壇酒發(fā)酵憑的是感覺現(xiàn)在打開儀表盤看曲線任何一個異常的拐點都能追溯到一個具體的時間點再結(jié)合當(dāng)時的操作記錄找到原因這種可回溯性幫我把工藝細(xì)節(jié)提升了一個臺階。最后再分享一個小技巧定時把SQLite數(shù)據(jù)庫文件備份到另一個地方。我在小主機上掛了一塊移動硬盤每小時執(zhí)行一次復(fù)制命令數(shù)據(jù)安全又多了一層保障。如果再想往前走一步可以給系統(tǒng)加一個繼電器控制端報警之后自動切斷或啟動加熱棒讓記錄系統(tǒng)升級成閉環(huán)溫控系統(tǒng)。這個項目本身不復(fù)雜但搭建起來之后后續(xù)的擴展空間很大值得花時間慢慢完善。