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