FarmOS — AI 智慧室內農場 POC

軟體工程師主導的智慧室內農場驗證專案，規劃成果報告

建立日期 2026-05-29　·　第一階段 POC　·　種植目標：萵苣

狀態：純規劃階段（開發解禁 2026-06-01）

專案概述

FarmOS 旨在驗證「能否利用軟體、自動化控制、感測器與 AI 技術，建立低成本且可複製的室內種植系統」。第一階段 POC 以單一作物（萵苣）在室內書房環境下，建立可穩定運作 30 天以上、全自動、可遠端監控的種植系統。

第一輪株數

30 天

連續運作目標

≥ 90%

存活率目標

< 5 分

每日維運

~33K

估算成本（NT$）

SLI/SLO 指標

成功標準：植物存活率 ≥ 90%、系統連續運作 ≥ 30 天、環境數據完整率 ≥ 95%。

需求規格 v1.0

透過六面向需求釐清，收斂出 12 項核心決策。整體指向「高自動化、高容錯、低人工介入」的工程化系統。

#	面向	決策	關鍵工程含意
1	種植目標	萵苣（單一）	喜涼，最適 18~22°C，生長週期 30~45 天
2	擺放場地	室內書房	靜音、防漏、控濕熱外溢
3	自動化範圍	全自動	LED / 風扇 / 降溫 / 補水皆程控
4	監控告警	手機遠端 + 告警	需遠端存取與推播
5	溫控策略	分層降溫	書房冷氣（粗）+ TEC 冷營養液（精）
6	水耕方式	DWC 深水栽培	耐停電、適合新手
7	告警/控制	Telegram + 遠端控制	outbound，不需內網穿透
8	維運投入	< 5 分鐘 / 天	高容錯：自動補水、斷電復原、告警分級
9	種植規模	少量 12 株	營養液 15~40L，補水桶撐一週以上
10	相機	先裝 + 定時拍照	為第二階段 AI 影像辨識累積資料
11	預算彈性	可超支（3~10 萬）	POC 成功優先於控制預算
12	EC/pH 管理	方案 A 半自動	自動補清水 + 每週手動調（~5 分鐘）

EC/pH 關鍵洞察：「全自動加藥」的全自動是假象——它把「每週加營養液」換成「每週校正探針」，省時有限卻多花 1 萬多並新增故障點。方案 A（手持筆每週測調）反而更接近「不想管」，故第一階段採方案 A，全自動加藥留待第二階段。

驗證指標體系（SLI / SLO）

把模糊的「成功」轉成可量測的服務水準目標，共 4 類 15 個指標。

類別一：植物生長

指標	定義 / 量測	SLO 目標	頻率
存活率	存活株數 / 總株數	≥ 90%	每日
抽苔率	抽苔株數佔比（高溫失敗訊號）	= 0%	每週
葉片數成長	每株真葉數	第30天 ≥ 8~10 片	每週
冠幅成長	植株最大直徑	遞增曲線	每週
採收鮮重	單株地上部鮮重	≥ 80 g/株	第30天

類別二：環境控制（POC 核心）

指標	定義 / 量測	SLO 目標	頻率
氣溫達標率	落在 18~24°C 的時間佔比	≥ 90%	每分鐘
根區水溫	DWC 營養液溫度	≤ 24°C，達標 ≥ 90%	每分鐘
濕度達標率	RH 落在 50~70% 佔比	≥ 85%	每分鐘
光照排程準確率	LED 開關符合排程（14~16h）	≥ 99%	每次切換
EC/pH 在範圍	EC 1.2~1.8、pH 5.5~6.5 比例	≥ 80%	每週

類別三：系統可靠性

指標	定義 / 量測	SLO 目標	頻率
連續運作天數	無重大人工介入的連續天數	≥ 30 天	持續
系統可用度	控制服務正常運行佔比	≥ 99%	持續
斷電復原成功率	斷電後自動恢復	= 100%	每次事件
告警有效性	漏報 / 誤報	漏報 0、誤報 < 1次/週	持續

類別四：資料完整性

指標	定義 / 量測	SLO 目標	頻率
感測資料完整率	實收 / 應收筆數（每分鐘1筆）	≥ 95%	持續
最長資料缺口	連續無資料最長時間	≤ 10 分鐘	持續
照片完整率	成功 / 應拍張數	≥ 95%	每次拍照

三個設計考量：

第一輪種滿 12 株，讓存活率指標有容錯空間（6 株死 1 株即掉到 83%）。
啟動後 3 天為調校期不計入 SLO，從第 4 天起算 30 天驗證窗。
「重大人工介入」定義為需動手修硬體/重啟/手動接管；每週 5 分鐘例行加營養液不算。

系統架構

硬體拓樸

種植區（grow tent）
  DWC 桶 × 12 株萵苣 + 打氣石(24h)
  ▲LED   ▲相機   ▲風扇/降溫
        │
Raspberry Pi（運算核心）
  ┌ 感測（數位，免 ADC）
  │  I2C   SHT31  氣溫/濕度
  │  I2C   BH1750 光照
  │  1-Wire DS18B20 根區水溫
  │  GPIO  浮球   水位
  │  CSI   Pi Camera
  └ 控制
     PWM/MOSFET  LED（調光）
     繼電器       風扇
     繼電器       TEC 水冷
     繼電器       補水泵
     ★直供電      打氣泵（24h）
  UPS / 斷電偵測（保打氣泵+Pi）
        │
     路由器 ──(outbound)──> Telegram / Tailscale

軟體服務拓樸

Raspberry Pi（systemd 託管）

 Sensor Service ─publish─┐
                         ▼
   ┌──────────────┐  ┌───────────┐
   │ MQTT Broker  │◄►│ Scheduler │
   │ (Mosquitto)  │  └───────────┘
   └──┬────────┬──┘
      ▼        ▼
 Controller   Logger
 (規則+聯鎖)    │
      │        ▼
      │     ┌────────┐
      ▼     │ SQLite │◄──┐
 (繼電器/PWM) └───┬────┘   │
                 ▼        │
          ┌──────────┐ ┌──┴────────┐
          │ Grafana  │ │Telegram Bot│
          └────┬─────┘ └─────┬──────┘
       (Tailscale)      (outbound polling)
               ▼              ▼
          手機看 Dashboard  手機收告警/發控制

六個關鍵架構決策

決策	說明
免 ADC	方案 A 的 EC/pH 為手動量測，感測器全為 I2C/1-Wire/GPIO 數位介面，省去 ADC 模組
打氣泵獨立供電 + UPS	打氣是 DWC 命脈，獨立直供電避免程式誤關，UPS + 停氣告警
Telegram 走 outbound	long polling 主動外連，NAT 後即可收發，遠端控制不需內網穿透或開對外端口
MQTT 解耦	各服務以 topic 解耦，第二階段 AI 模組可直接訂閱接入
安全聯鎖	規則控制內建硬性保護與異常安全預設狀態
systemd 託管	Restart=always + 開機自啟，對應斷電復原與 30 天連續運作

分層降溫方案

熱力學硬限制：製冷設備若把廢熱排在書房內，整個書房總熱量不減反增（增加量 = 耗電）。 TEC 因 COP 僅 0.3~0.6 特別吃虧（搬 1 份熱排 2.5~4 份）。故 TEC 只冷小水量（廢熱小），絕不冷整腔空氣又把熱留室內。核心原則：冷水優於冷氣——冷的東西越小，留在書房的廢熱越少。

┌ 書房（分離式/窗型冷氣維持室溫, 廢熱→室外）─────────┐
│  ┌ grow tent 120×60×150（反光內襯）────────────┐  │
│  │  腔體氣溫: inline 抽風扇排 LED 熱 + 進氣        │  │
│  │           → 腔體 ≈ 室溫（不強求 20°C）         │  │
│  │  ┌ DWC 營養液桶 ──────────────┐               │  │
│  │  │ ★ TEC 水冷恆溫 ~20°C        │               │  │
│  │  │ (循環泵 + 水冷頭 + 水溫感測)  │               │  │
│  │  └────────────────────────────┘               │  │
│  └────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────┘
分工：書房冷氣 = 粗調室溫(排室外)   TEC = 精調根溫(廢熱小)

為什麼成立：書房冷氣把大部分熱排到室外（粗調），TEC 只把營養液從室溫再壓低幾度（精調）；廢熱小、書房冷氣輕鬆吸收；根溫是萵苣成敗的關鍵變數，被精準控制，氣溫不過熱即可。

風險盤點

嚴重度 = 可能性 × 衝擊。先列會直接搞垮 POC 或危及安全的單點致命風險。

單點致命風險

風險	嚴重度	緩解設計
電氣安全（水+電共存）	高	漏電斷路器 RCD/GFCI；強電繼電器隔離；防水、抬高；優先低壓 12/24V
漏水浸書房	高	防水集水盤；接頭漏水感測（P1）；補水泵運轉上限防溢水
打氣中斷→根缺氧	高	打氣泵獨立直供電 + UPS + 停氣立即告警
高溫抽苔	高	分層降溫；根溫 ≤ 22°C 主控；超標告警；耐熱品種保險
Telegram 失聯=告警瞎了	高	本地蜂鳴器+燈備援；Pi 心跳；網路恢復補送
SD 卡損壞（系統全掛）	高	工業級 SD / SSD 開機；減少寫入；定期備份映像

其餘風險（節錄）

風險	嚴重度	緩解
藻類滋生	中	不透光桶、定植板完全遮光
根腐病 Pythium	中	控水溫、保持清潔、必要時加 H₂O₂/益生菌
補水桶見底	中	補水桶液位感測 + P1 告警；容量配足一週
控制邏輯 bug 誤動作	中	安全聯鎖、補水泵運轉上限、打氣不受程式控制
感測器失效/漂移	中	讀數合理性檢查 → 異常進安全預設狀態
服務 crash	低	systemd Restart=always + watchdog + 心跳
遠端控制未授權	低	chat_id 白名單、危險操作二次確認、操作日誌

告警分級（< 5 分鐘維運的關鍵）

把眾多風險收斂成你實際要做的反應：平日只有 P3，P2 偶爾，P1 才真正打斷你——且 P1 都配本地備援，不怕漏接。

級別	觸發條件	你的反應	通知方式
P1 緊急	漏水、斷電、停氣、高溫失控、補水桶空、Pi 心跳中斷	馬上處理	Telegram + 本地蜂鳴器/燈
P2 警示	水溫偏高、EC/pH 待調、單一感測器異常、服務重啟過	當天處理	Telegram
P3 資訊	生長數據、趨勢、週報	每週翻閱	Dashboard（不推播）

殘餘風險（已知接受的取捨）：(1) EC/pH 漂移——方案 A 無自動感測，靠每週手動 + 目視； (2) 盛夏極端高溫——若書房冷氣也壓不住根溫，第一輪可能避開盛夏或換耐熱品種。

硬體採購清單（BOM）

第一輪 12 株。估價為台灣市場概略值，單位新台幣，取中間估值加總。標「安全」者對應風險緩解，不可省。

分類	主要項目	小計
① 結構環境	grow tent、防水集水盤(安全)、inline 抽風扇、循環風扇	5,300
② 種植系統	不透光 DWC 桶、定植籃、打氣泵、營養液、育苗材料	3,500
③ 降溫	TEC 水冷模組、循環泵、12V 大電流電源、保溫水管	4,000
④ 補水	清水桶、補水泵、液位感測(安全)	1,200
⑤ 光照	全光譜植物 LED 板、PWM 調光驅動	4,000
⑥ 控制核心	Raspberry Pi、工業級 SD/SSD(安全)、繼電器、MOSFET、端子	5,700
⑦ 感測器	SHT31、DS18B20 水溫、BH1750 光照	850
⑧ 相機	Pi Camera Module 3、支架+排線	1,500
⑨ 安全可靠性	RCD/GFCI、UPS、漏水感測、本地蜂鳴器+燈（全為安全項）	3,300
⑩ 水質工具	EC/pH 手持筆、pH 調整劑+校正液、配藥器具	1,700
⑪ 雜項	線材、防水接線盒、走線、備品	2,000
合計（中間估值）		約 33,050

~33K

中間估值

26~45K

估價區間

73K

原預算

~40K

剩餘可用

關鍵發現：遠低於原預算 73,000。原計劃貴在「大種植架 + 複雜水耕 + 管材」，但第一輪 12 株小規模 + grow tent + 單桶 DWC 大幅壓縮成本。剩餘約 4 萬可留給：第二輪擴大規模、第二階段 AI 算力、或設備升級（如 chiller 取代 TEC）。

Pre-mortem 失敗分析

以「假設 6 週後 POC 失敗了，最可能死在哪」的事前驗屍角度，檢視方案中「看似帶過、其實仍是假設」的薄弱點。按致命程度排序。

排序	失敗點	為什麼會死	現況
1	溫控物理算不過	營養液持續熱負荷估 30~60W+（打氣泵把室溫空氣打進水裡是隱形大宗），DIY TEC 淨製冷僅 20~40W → 水溫壓不到 22°C → 抽苔	從沒真算過
2	育苗空窗吃掉時程	育苗 2~3 週，30 天 POC 扣掉後 DWC 期僅剩 1~2 週長不大；育苗夭折又使起跑不足 12 株	時程未分離
3	光熱矛盾	LED 夠亮萵苣才長好，但 150W LED 約等於 150W 加熱器，直接惡化第 1 點	未一起算
4	首版做不到「免照顧」	免照顧是迭代磨出來的；首版控制邏輯必有 bug（溢水、誤觸發、競態）	期望落差
5	電源 / 整合首次組裝	總電源預算沒算、I2C 衝突、感測器跳值	未驗證

新發現風險：單一 DWC 桶 = 全批相關性失效。12 株共用一桶營養液，一旦根腐病、水溫失控或加錯藥污染水體，是全有全無 12 株一起垮，不是線性死幾株。先前「12 株給容錯空間」是錯覺——共用水體讓環境事件變成滿盤皆輸，更凸顯溫控/水質必須先解決。

核心觀察：POC 的生死壓在「溫控物理 + 作物生命週期」這兩個最不熟、最沒被驗證的物理問題上，與「自動化多完整、能否遠端、AI」幾乎無關。這是工程師專案的典型陷阱——在熟悉的軟體面過度建設，在陌生的致命面只放假設。

分階段 POC 方案（已採行）

因應 pre-mortem 結論，第一輪 POC 改採分階段：用最小成本先消滅致命的物理不確定性，再疊加擅長的軟體面。每階段設明確 Go / No-Go 關卡，前一關沒過絕不進下一關。

Stage 0 — 「乾測」溫控（不種菜）

目的：投入任何育苗週期前，先用一桶水回答「水溫到底壓不壓得到 22°C」——頭號失敗風險，且不需植物即可驗。

配置：grow tent + LED 全開 + 一桶清水 + 打氣泵 + 降溫裝置（TEC 或 chiller）+ 水溫/氣溫感測。

做法：挑熱天連續跑 48~72 小時，記錄水溫曲線。

過水溫穩定 ≤ 22°C → 進 Stage 1
不過加保溫桶 / 冷氣調低再測；仍不過 → TEC 換 chiller；再不過 → 此季節/場地不可行，須改季節或改場地

把「賭整個種植週期」變成「賭 3 天一桶水」，是分階段策略最大的價值點。

Stage 1 — 種植物理驗證（手動 / 半自動）

目的：溫控確認後，驗證第二個致命問題——萵苣能否在這套環境種活、且在合理時間長到可採收。

配置：Stage 0 硬體 + DWC 定植 + 手動補水 / 手動測調 EC-pH。先不接 MQTT / Telegram / 遠端 / AI，控制可僅簡單排程。

關鍵修正：

時程明確分離：育苗 2~3 週 + 定植後 30 天，總窗口拉到約 6~7 週，不把育苗塞進 30 天。
育苗多播種備援（播 18~20 株，挑 12 株最好的定植）補夭折損耗。
考慮分 2 桶降低相關性失效，或接受單桶風險但靠 Stage 0 先壓掉環境風險。

過存活率 ≥ 90%、無抽苔、30 天長到接近可採收鮮重 → 進 Stage 2

Stage 2 — 疊加全自動 / 遠端 / AI

物理問題都驗證過後，才把完整系統疊上：MQTT + 5 service + 安全聯鎖 + Telegram 遠端 + Grafana + 相機定時拍照。此時是在已知能種活的環境上做自動化，bug 不致命（最多退回手動），風險大幅下降。

為什麼這樣切

致命風險前置：Stage 0 用 3 天一桶水，就否決或確認最可能殺死 POC 的事。
成本前置低：Stage 0/1 只需硬體子集，軟體那套延後，不浪費。
每關可獨立宣告成敗：即使 Stage 1 失敗，也已有「溫控可行 + 失敗原因」的明確數據，不是模糊的整體失敗。

時程與下一步

規劃期完成項目

項目	狀態
需求釐清（12 項決策）	完成
驗證指標細化（15 個 SLI/SLO）	完成
系統架構圖（硬體 + 軟體 + 降溫）	完成
風險盤點（含告警分級）	完成
硬體 BOM 草稿	完成
Pre-mortem 失敗分析	完成
策略定案：採分階段 POC	完成

下一個規劃動作：溫控熱負荷計算——把「TEC 到底夠不夠、要不要保溫桶、書房冷氣要開到幾度、總電源預算」用數字算清楚，作為 Stage 0 乾測的設備配置依據。需要書房與設備實際參數（房間大小、冷氣可達溫度、LED 預計瓦數等）。

開發解禁後（2026-06-01 起）建議起點

Stage 0 先行：先採購並組裝乾測所需硬體子集（grow tent、LED、降溫裝置、水溫感測），跑溫控乾測。
安全項優先到位：RCD/GFCI、UPS、漏水感測、防水盤。
軟體骨架（MQTT + 服務 + SQLite schema）延後至 Stage 2，待物理驗證通過再投入。