機房溫濕度感測器・八個角色接力

互動簡報 · IoT · 3D 列印 · 韌體 · AI

一台機房溫濕度感測器,八個角色接力做出來

每一站只做一件事,產出交給下一站。先看一句話和圖;想懂細節,再點「看深度」。

  • 約 14 小時11/10 17:26 提需求 → 11/11 07:18 裝殼上線
  • 約 NT$514實機材料:開發板+感測器+PLA
  • 923 筆/0 失敗上線那次開機以來的讀值

操作:← → 或頁尾按鈕翻頁;上方角色列可以直接跳到任一站。

闔上滑蓋的黑色列印外殼,側面與蓋上有通風格柵,兩端有安裝耳
成品。30 腳 ESP32+DHT11,裝在 PLA 列印的滑蓋殼裡,USB 5V 供電。

01 — 產品設計師

決定要什麼|需求方本人

先決定要什麼,後面每一站才知道往哪裡做。

需要一台 ,可以 。
隱含條件:

收到現場機房一句話:需要溫濕度的網路監控設備
交出規格:能上 Wi-Fi 的開發板+溫濕度感測器,市售模組、免焊
PLA 滑蓋殼 · USB 5V · 機櫃上 DHT11溫濕度 GPIO4 ESP32每 5 秒一筆RAM 約 1 小時 APIHTTP JSON 監看頁只顯示,不判斷 巡檢服務(自建)排程拉資料、門檻判斷 AI 助理調閱數據(下一步) 虛線框=下一步,尚未建置
大方向。裝置只量測、只提供 API;誰要看、要不要告警,都從同一個入口拿資料。

點畫線的詞:看它變成哪個決定、交給哪一站(上方角色列會一起亮)。

看深度

需求轉折:從「裝置自己告警」到「只量測+API」決策

第一版韌體會在裝置上判斷異常(溫度門檻、連續讀取失敗)。11/10 21:43,需求方改了方向:

「韌體變成持續量測,但是有 API 接口,讓我自己開發服務去巡數據,巡到異常我再處理。」

好處是之後要加監測點、改門檻或接其他告警管道,都不必重燒韌體。

兌現在

範圍刻意收窄:這台不做什麼範圍
  • 不控制除濕機或加濕機,也不接智慧插座。
  • 裝置不判斷異常、不發告警。
  • 裝置不存長期資料:RAM 只保留最近約 1 小時(720 筆)。
  • 不焊接:全部用市售模組加杜邦線。
這一頁的決定,後面在哪裡兌現扣合
  • 免焊、市售模組 → 、
  • 機房、機櫃安裝、只用 PLA → 、
  • 每 5 秒取樣、只提供 API → 、
  • 判斷交給巡檢服務、讓 AI 調閱 →

02 — 採購

規劃模組、比價|採購角色列清單;需求方本人到材料行買

核心只有兩樣:一塊 ESP32 開發板,一顆 DHT11 感測器。

其他是已有的配件和耗材。買之前要認清兩件事:開發板是 30 腳還是 38 腳,感測器是模組還是裸探頭。

  • 30 腳 DOIT 類 ESP32 開發板(Wi-Fi+藍牙)NT$420 實購
  • DHT11 溫濕度模組(3 針,非裸探頭)NT$80 實購
  • PLA 線材 1.75 mm,約 47.6 g約 NT$14 估算
  • 母對母杜邦線 ×3已有
  • USB-C 線+5V 充電頭已有
收到能上 Wi-Fi、免焊、市售模組
交出一塊 30 腳 ESP32、一顆 3 針 DHT11 模組(絲印 + out −)
兩包零件:ESP32 開發板 WiFi+藍芽 售價 420,電阻式溫濕度傳感器 DHT11 售價 80,材料行標籤
材料行買回的兩包。ESP32 開發板 NT$420(店內編號 102924)、DHT11 NT$80(店內編號 102754)。

一組開發板+感測器,三種買法

不含運費。網路價是 11/11(三)查到的同等規格商品,不是健新實購的同一批貨,也不保證板型或 USB 晶片完全相同。

看深度

BOM 全表:實購標價+網路同等品現價表格
品項規格(實物確認)數量實購標價(11/10)網路同等品現價/估算(11/11(三)查)
ESP32 開發板30 腳 DOIT DevKit V1、ESP-WROOM-32、4MB flash、USB-C、CP21021NT$420台灣物聯科技 NT$210(含稅;寫明 30 Pin)
酷澎市集・維貿企業社 NT$202(免運;選項「便宜板ESP32s Doit開發板」,30 腳)
DHT11 模組轉接板絲印 + out −(板上標 V1.82),3 針模組1NT$80台灣物聯科技 NT$63(含稅;3 線有燈模組)
酷澎市集・傑森創工商號 NT$55(3 針模組)
PLA 線材1.75 mm;Cura 估 15.95 m,以密度 1.24 g/cm³ 換算約 47.6 g(含 brim,未實秤)約 47.6 g已有約 NT$14(47.6 g × NT$300/kg;指定的估算單價,不是某家店的當日標價)
母對母杜邦線DHT11 接 3V3/GND/GPIO43已有不計入
USB-C 線+5V 充電頭一般手機充電頭即可1已有不計入(部分同等板是 Micro-USB)

小計:實機材料約 NT$514(420+80+14);網路同等品含 PLA 約 NT$287(台灣物聯科技)或 NT$271(酷澎市集),運費另計。

比價怎麼算、排除了哪些低價選項比價
  • 健新電子材料行(實購)NT$500:門市標價。官網查無這兩個店內編號,這次也沒有再向門市詢價。
  • 台灣物聯科技 NT$273:同一家可一起出貨;未滿 NT$1,000 要付運費(超商取貨 NT$50、掛號 NT$60、黑貓 NT$80)。
  • 酷澎市集 NT$257:兩個賣家分開出貨。開發板免運;DHT11 同商家滿 NT$149 免運,只買一顆未達門檻,要另計運費。
  • 排除:同一個酷澎商品頁上 NT$145 的選項其實是天線;酷澎上 NT$35 的 DHT11 是裸探頭,不是模組(另一家 NT$35 的模組已售完);NT$140 的 DevKit-32E 沒寫腳位,這個型號通常是 38 腳,裝不進 30 腳殼。
  • 這次詢價只用網路同等品的現價完成,沒有向門市電話或書面詢價,也沒有下單。
清單換過一次:C3+SHT31 → ESP32+DHT11迭代

第一版清單是 ESP32-C3 SuperMini+SHT31 溫濕度模組,第一代滑蓋殼也照它做到切片。同一天,需求方在材料行直接買到 ESP32 開發板和 DHT11,當晚就改用這組。

代價:外殼要重新設計;而且板子買回來時還在防靜電袋裡,看不出是 30 腳還是 38 腳。DHT11 在 25 °C 的精度是 ±2 °C、±5 %RH,看機房趨勢夠用。

影響到

再做一台,下單前先確認清單
  • 是 30 腳板:數一邊排針,15 根=30 腳(DOIT DevKit V1 類),19 根=38 腳。
  • USB 接頭與晶片:部分同等板是 Micro-USB;USB 轉序列晶片頁面不一定寫明。
  • DHT11 要買「模組」(3 針轉接板),不是裸探頭。
  • 運費門檻:台灣物聯科技未滿 NT$1,000 另計;酷澎 DHT11 同商家滿 NT$149 免運。
  • 網路標價會變動,也不保證和實購同批。

03 — 接線

讀腳位、出接線圖|AI 判讀腳位並操作接線軟體出圖;需求方本人照圖接線

AI 先讀懂開發板的腳位,再用接線軟體畫出一張照著插就對的圖。

  1. 讀 pinout。30 腳 DOIT 沒有官方線上文件,AI 拿兩份 Wokwi 腳位定義和兩份公開腳位圖交叉比對;用到的 3V3、GND、D4 完全一致。
  2. 選腳。排除開機腳、Flash 腳、USB 序列腳和只能輸入的腳,選 GPIO4。「AI 怎麼判讀腳位」分頁可以逐腳點看。
  3. 操作接線軟體出圖。用開源元件庫 @wokwi/elements(MIT)在無頭瀏覽器裡畫出板子和感測器,線端座標直接取元件自帶的腳位定義,每條線都落在真的腳上。
  4. 校稿。第 1 版圖例撞到標題、說明框互相重疊;調版面、縮短圖例、拉開標籤,第 2 版通過。
  5. 人照圖接。先拔 USB,對著絲印插三條母對母杜邦線。實物線色和圖不同,兩條白線插反過一次。
收到30 腳 ESP32、3 針 DHT11 模組
交出三條線、板下杜邦母頭約 14 mm,殼裡要留走線路徑
交出DATA 接在 GPIO4
ESP32 30 腳 DOIT DevKit V1 與 DHT11 接線圖:紅線 3V3 接 VCC、黑線 GND 接 GND、黃線 GPIO4 接 DATA,三條線都在右排靠 USB 端
AI 產生的 30 腳接線圖。元件圖取自 Wokwi Elements(MIT);DHT 外形改自 wokwi-dht22(改藍色、字樣改 DHT11)。圖中板子畫的是 Micro-USB,實物是 USB-C,腳位相同。圖內提到的 WIRING.md 是專案內的接線步驟文件。
點左邊三條線,或在「AI 怎麼判讀腳位」點任一腳,這裡會說明為什麼這樣接。

看深度

為什麼接 3V3,不接 5V原理

DHT11 可以吃 3.3–5.5 V(新版規格書)。轉接板的上拉電阻接在 VCC:如果 VCC 接 5V,DATA 平常就被拉到 5V,而 ESP32 的腳位最高只能 3.3 V,長期會傷腳。

接 3V3,DATA 的電位剛好是 ESP32 的電壓。現場用 USB 5V 供電也沒問題:5V 進板子,板上穩壓成 3.3 V 再給 DHT11。

為什麼是 GPIO4:要避開哪些腳原理
  • 開機腳(strapping)GPIO0/2/5/12/15:上電瞬間 ESP32 會讀這些腳決定開機模式或 Flash 電壓;DHT11 的 DATA 有上拉,會干擾開機。
  • Flash 腳 GPIO6–11:接在模組內部的 SPI Flash,接東西會當機或開不了機(30 腳板沒有拉出來)。
  • USB 序列 TX0/RX0(GPIO1/3):燒錄和看 log 在用。
  • 只能輸入 GPIO34/35/36(VP)/39(VN):送不出 DHT11 需要的啟動訊號。

GPIO4 不是開機腳、不接 Flash、可輸入也可輸出;30 腳和 38 腳兩種板子都有拉出來,而且離 3V3、GND 近,三條線能集中在 USB 端右排。

接完、通電前的檢查步驟
  1. 全程拔掉 USB 再接線、改線。
  2. 看 DHT11 板的絲印接,不要看位置:VCC 或 +、DATA 或 out/S、GND 或 −。
  3. 目視:三條線各自插在正確的針上,沒有插歪一格,紅線和黑線不能碰在一起。
  4. 有三用電表就量 3V3 對 GND,不應該「嗶」(嗶=短路)。
  5. 插上 USB 後,序列埠應該每 5 秒出現一行讀值。

真的接錯時怎麼查:

腳位來源與這張圖的授權出處
  • 腳位交叉比對:Wokwi 元件 wokwi-esp32-devkit-v1 的腳位定義(@wokwi/elements 1.9.2)、wokwi-boards 的同型板定義、CircuitState 與 Random Nerd Tutorials 的 DOIT 腳位圖。用到的 3V3/GND/D4 交叉比對一致;唯一出入是沒用到的 VP/VN 先後。
  • 元件圖:@wokwi/elements,MIT 授權(授權全文見 vendor/LICENSE-wokwi-elements.txt)。
  • 38 腳 DevKitC 版也畫過一張,但那張板圖的來源沒有附授權,只能內部參考,本頁不收錄。

04 — 機構/3D

建模、選結構、顧可印性|AI 協助 OpenSCAD 建模;列印性審查把關

殼分兩件:殼身,加一片沿長軸滑開的蓋。印得出來,比好看重要。

滑蓋這次採用

45° 燕尾沿長軸滑入,配合間隙 0.30 mm;推到底由蓋尾一個小扣點「喀」一聲定位。開合方便維修,插著 USB 線時插頭擋住蓋尾,等於多一道鎖。

卡扣(機構常識)

零件少、一壓就扣上;但扣臂要能彎,PLA 偏脆,常拆的地方容易疲勞,扣點尺寸也對層高很敏感。這次只把它縮成蓋尾的小扣點:高 0.56 mm,剛好兩層。

好不好印

  • 懸空都 ≤45°,整盤免支撐
  • 牆厚做成 0.8 mm 的倍數,2 道牆剛好填滿
  • 橋接只在 2.0 mm 通風槽頂、6 mm 走線孔頂
  • 滑蓋貼床面做 0.3 mm 倒角,防第一層外擴(象腳)
  • 15 項自動檢查全過,也刻意改壞參數,確認檢查抓得到錯
收到三條線的走線路徑、板下杜邦母頭高度
收到板型:買回來確認是 30 腳 DOIT
交出一盤兩件的 STL:殼身背面貼床、滑蓋平面貼床

模型載入中…

—
拖曳旋轉;滾輪或雙指縮放;右鍵或雙指拖曳平移。滑蓋沿長軸往 USB 端滑出,全開 125.6 mm,跟實際開蓋方向相同。
30 腳版殼體閉合等角圖,藍色滑蓋
閉合
滑蓋往 USB 端滑開一半,露出 DHT11 艙
滑蓋半開
拿掉滑蓋的俯視:ESP32 板在 USB 端、DHT11 在另一端,中間是隔牆與走線孔
拿掉滑蓋
側剖面:左側 DHT11 艙,右側 ESP32 板與板下杜邦母頭,線沿底部穿過隔牆
側剖面
印好的黑色殼身內:ESP32 開發板在 USB 端,DHT11 在格柵端,紫白杜邦線穿過隔牆
實物裝進去

算繪圖為 30 腳最終版;最後一張是需求方實拍。

看深度

佈局:感測器放在熱源的上游機構
  • 由一端到另一端:DHT 端牆 → DHT11 艙 → 1.6 mm 實心隔牆 → 12 mm 天線淨空區 → ESP32 艙 → USB 端牆。壁掛時 DHT 端朝下,感測器在 ESP32 熱源的下方。
  • 排針朝下,板下預留杜邦母頭(約 14 mm)加 9 mm 彎線空間;三條線從隔牆底部 6×8 mm 的孔穿到 DHT 艙,不經過天線正下方。
  • 開發板沒有螺絲孔:兩側牆夾住板寬、天線端角塊楔口壓住板角,USB 端由滑蓋擋住。
  • DHT 艙四周、背面、蓋上都有格柵(開口 2.0 mm);蓋上兩個 Ø3.2 小孔可用牙籤按 BOOT/EN。
板型不確定,就兩種都做決策

板子買回來時看不出是 30 腳還是 38 腳,查不到店家頁面,也還沒有實物可以量。殼體預設做 38 腳 DevKitC(尺寸取自 Espressif 官方圖面),另出一套 30 腳 DOIT 版(尺寸取自第三方實測圖)。

實物確認是 30 腳 DOIT 後,改印這一版:殼身約 35 × 124 × 36 mm,含安裝耳長 142 mm。

起因在

真的出過的錯:間隙被層高吃掉除錯
  • 前一代的楔口間隙設 0.35 mm,換算 0.28 mm 層高後實際只剩 0.12 mm;改成 0.50,實得約 0.36。
  • 改完殼身多了 6 條非流形邊(兩個共面方塊的浮點誤差),改成單一截面一次擠出才修好。
  • 扣點梯形底寬只有 1.385 mm(目標 1.4),修正斜率後 STL 實測 1.399。
  • USB-C 開口較寬,會切到 USB 端的支撐,改成支撐自動避開開口。

層高怎麼影響尺寸:

模型檔與這個 3D 檢視器檔案

模型檔隨本頁提供:GLB(殼身、滑蓋為兩個獨立零件)、STL(組裝態,單一網格)。

檢視器以 three.js r160(MIT,授權全文見 vendor/LICENSE-three.txt)實作。模型本身沒有動畫,滑開時程式只沿長軸平移滑蓋零件,沒有修改模型檔。

05 — 切片

把模型翻成走位路徑|列印性審查切片並逐層檢查;需求方本人列印

切片是關鍵的一步:把 3D 模型轉成印表機的路徑檔 G-code。

FDM 列印是噴頭擠出熔化的線材,一層一層往上疊,像蓋積木。切片軟體決定每一層怎麼走、走多快、多熱。

點上面任一格,看這個參數是什麼、這次怎麼設。
收到一盤兩件的 STL
交出G-code → Ender-3 印約 6 小時 → 黑色殼身,等燒好的板子裝進去
熱床(60 °C) 0.28
第 1 層|0.28 mm

示意:殼身短邊剖面,每層 0.28 mm,共 127 層;不是 G-code 的實際走位。

G-code 第 1 層路徑圖:殼身背面與滑蓋並排在熱床中央,外圍橘色為 5 mm brim,後緣 20 mm 為紅色禁區
真正的第 1 層。藍色是殼身背板與滑蓋,橘色是 5 mm brim;紅色是熱床後緣 20 mm 禁區。
Ender-3 熱床上剛印完的黑色殼身,兩端有安裝耳,側面是通風格柵
Ender-3 上剛印完的殼身。面板顯示列印約 6 小時。

看深度

三版 G-code 怎麼演進表格
版本內容預估線材
11/10 20:5938 腳預設版一盤;200 °C/熱床 50 °C6 h 00 m16.04 m
11/10 22:26改切 30 腳 DOIT 版,其他相同5 h 51 m15.64 m
11/10 22:3930 腳版整盤置中、加 5 mm brim;熱床 60 °C、首層 205 °C、之後 200 °C;前 3 層關風扇5 h 59 m15.95 m

第三版主要加強附著:零件細長、底面大,brim、較高的熱床溫度、前幾層關風扇,都是為了降低翹邊的機率。

這台印表機的兩個習慣:−20 offset、後緣 20 mm現場

切片用 Cura 5.6,機型 Creality Ender-3,沿用需求方原本的 Low 0.28 設定。印表機設定裡的噴頭 Y offset −20 是刻意的,不要補償;熱床後緣 20 mm 不放零件。第三版以實體熱床座標(扣掉 −20 offset)把整盤置中。

G-code 也要驗:逐層檢查驗證
  • 第一版 G-code 逐層檢查:滑蓋兩條切縫在 8 層裡都沒有被擠出線填住,彈片能獨立彎曲。
  • 楔口在 0.28 mm 層高下的實際間隙是 0.36 mm(設計值 0.50)。
  • 扣點剛好兩層 0.56 mm。

為什麼要驗:

這一盤的數字數字

127 層,最高 35.56 mm;Cura 預估 5 h 59 m;線材 15.95 m,以 1.75 mm 線徑、密度 1.24 g/cm³ 換算約 47.6 g(含 brim,未實秤)。

換成錢:

06 — 韌體

撰寫、燒錄、測試、連網|AI 協助撰寫與燒錄;需求方本人建 Wi-Fi 帳密檔

先讓板子穩定吐出數字,再讓它上網,最後用測試證明它真的連得上。

  1. 撰寫每 5 秒取樣一筆,RAM 留 720 筆
  2. 燒錄arduino-cli;自動重置,不用按 BOOT
  3. 測試電腦上 181+47 項,實機 API 30/30
  4. 連網最多 4 組 Wi-Fi,連不上自動換下一組

第一次燒錄就踩到一個典型問題:程式正常,但每一筆都讀不到。四段序列埠紀錄,看它怎麼被查出來。

收到DATA 接在 GPIO4
收到印好的殼
交出HTTP JSON API:latest、history、health、metrics

      

節錄自實機序列埠紀錄(有刪節);Wi-Fi 名稱與位址已遮蔽。

看深度

第一次燒錄失敗,怎麼查出來的除錯

11/10 22:49 第一次燒錄 v0.2.0(離線模式)。開機正常、每 5.00 秒取樣、序號照常遞增,但每一筆都是 read_error。

AI 另寫了一支診斷程式,只讀腳位電位並記錄 GPIO4 的回應波形:GPIO4 被外部拉到地,連晶片內建上拉都拉不起來;送出啟動訊號後感測器完全沒有回應。

判斷問題在模組端接線,請需求方拍照確認:兩條白線在模組端插反了(D4 接到 −、GND 接到 out)。23:04 對調後讀到 26.7 °C/64 %RH,燒回主程式連續 8 筆都是 ok。

回到

v0.1 → v0.2 → v0.3版本
  • v0.1.0:每 5 秒讀一次,取最近 6 筆滑動平均;溫度超過門檻或連續失敗就在序列埠警示。當時還沒有板子,只做了編譯。
  • v0.2.0:需求轉折後重寫。拿掉裝置端告警與滑動平均,只留原始值和健康計數;固定每 5 秒一筆,失敗也記一筆並帶狀態碼;RAM 環形緩衝 720 筆(每筆 24 B,共 17,280 B,約 1 小時);每筆帶序號,開機另產生 boot_id 讓巡檢端分辨重開機;NTP 校時,API 回 UTC 時間。
  • v0.3.0:最多 4 組 Wi-Fi,支援一般密碼與企業帳號;開機非同步掃描,自動連訊號最強的已設定網路,連不上就換下一組。Flash 用量 83%、RAM 20%。
沒有板子之前,先在電腦上測測試

核心邏輯(環形緩衝、history 的視窗與缺口判斷、參數檢查、JSON 輸出)抽成一份與平台無關的標頭檔,韌體和電腦上的測試共用同一份程式。

用 clang 加 AddressSanitizer 與 UBSan 編譯:單元測試 158 項、假裝置情境測試 47 項全過(v0.3.0 增加到 181+47)。也刻意植入 4 種錯誤(例如缺口計算差一),每一種都被測出來。

實機驗收 30/30:取樣間隔 4,998–5,002 ms,60 秒內序號增加 12;重開機後 boot_id 改變,巡檢範例也偵測到重開機。

編譯環境,以及 Wi-Fi 帳密放哪裡環境

arduino-cli 1.5.1、Espressif 官方 ESP32 Arduino core 3.3.12、Adafruit DHT sensor library 1.4.7 與 Adafruit Unified Sensor 1.1.15;過程不需要 sudo。

Wi-Fi 帳密放在 secrets.h,這個檔被版本控制排除;沒有這個檔也能編譯,此時進入離線模式,只輸出序列埠。

07 — 軟體

監看頁+API|AI 協助實作;需求方本人使用

一個 HTML 檔就是監看頁;同一組 API,也開給其他程式呼叫。

監看頁直接打裝置的 API,不需要後端。它只顯示、不判斷,判斷留給巡檢服務。

裝置提供的 API(點開看用途)

收到HTTP JSON API
交出同一組 API,加上已驗證的巡檢範例程式
即時監看頁:溫度 24.8°C、相對濕度 55.0%、感測器正常、成功 923 失敗 0、最新樣本 #923 07:18:42,韌體 0.3.0,每 5 秒取樣
裝殼上線後的監看頁(11/11 07:18)。點圓點看每一塊在說什麼。畫面上的 th-monitor.local 是韌體預設的 mDNS 名稱,只在同一個區網內解析得到;不是公網 IP,從外部解析不到。
點畫面上的圓點,這裡會說明那一塊的資料從哪裡來。

看深度

監看頁怎麼拿資料:增量輪詢與 boot_id機制
  • 每 5 秒呼叫 /api/v1/history?since=<上次的序號> 增量拉資料;每 3 輪(約 15 秒)讀一次 /api/v1/health。
  • 分頁切到背景時暫停,回來一次補齊;裝置只保留約 1 小時,離開更久就會出現缺口。
  • boot_id 改變代表重開機,從第 1 筆重新載入;API 回報缺口時,事件欄記下漏了幾筆。
  • 裝置回應都帶 Access-Control-Allow-Origin: *,所以單一 HTML 檔可以直接跨來源讀取。
  • 裝置位址只存在瀏覽器本機,不寫進任何檔案。
API 一覽與回應範例介面
端點用途
GET /api/v1/latest最新一筆(成功或失敗)+最後一次成功的讀值
GET /api/v1/history?since=<seq>&limit=N增量拉取;附最舊/最新序號、是否還有、缺口與漏掉筆數;limit 預設 100、上限 720
GET /api/v1/health開機時間、重開原因、NTP、Wi-Fi 訊號、記憶體、讀取計數、最後錯誤、韌體版本
GET /metricsPrometheus 文字格式,只有原始值與計數
GET /說明頁
怎麼驗證這一頁驗證

對實機用 Playwright 跑 Chromium 與 WebKit,直接開本機檔案 28/28 通過;對假裝置模擬讀取失敗、重開機、NTP 未同步,7/7 通過;淺色、深色與手機版都截圖檢查過。

mDNS 名稱與固定位址網路

th-monitor.local 是韌體預設的 mDNS 名稱:只在同一個區網內有效,不是公網位址,外部解析不到。

實測在 Mac 上第一次解析要約 5 秒,所以建議巡檢服務改用路由器 DHCP 保留的固定位址。本頁不列出任何實際位址。

08 — AI 接入

調閱數據,幫人遠端盯著|AI 已能透過 API 讀數據;長駐的遠端調閱是下一步

最後一站:讓 AI 接上同一組 API 調閱數據,人不在機房也看得到。

想問的事 → 對應的入口

點一個問題,看 AI 要走哪個入口、拿回什麼。

AI 在這個專案已經做過的事

  • 已完成讀 pinout、操作元件庫畫出接線圖
  • 已完成讀診斷波形,找出兩條白線插反
  • 已完成直接呼叫裝置 API 做實機驗收 30/30
  • 已完成寫巡檢範例程式:增量拉取、偵測重開機與缺口
  • 下一步巡檢服務長駐、保存長期資料,AI 經由它遠端調閱
收到API+巡檢範例
交回數據夠不夠、門檻怎麼訂,回頭修需求
受信任區網(不開對外埠) 你(遠端)用一句話問 AI 助理只讀調閱 VPN 巡檢服務存歷史、判門檻 裝置 APIESP32+DHT11約 1 小時 範例已驗證・長駐待建 已完成(30/30) 下一步
調閱路徑。實線框=已完成並驗證;虛線框=下一步,尚未建置。本頁不公開裝置位址,也不開放對外連線。

看深度

安全邊界:先把門關好,再接 AI安全
  • 裝置 API 沒有登入機制,也只走 HTTP,所以只放在受信任的區域網路。
  • 不做 port forwarding、不對外開放 80 埠;需要跨網段時走 VPN。
  • 之後可以加 Bearer token;CORS 已預留 Authorization 標頭。
  • AI 只做讀取:調閱數據,不改裝置設定。
巡檢服務要負責什麼職責
  • 排程拉資料:間隔建議 30–60 秒,一定要小於約 60 分鐘,不然會出現缺口。
  • 門檻判斷放在巡檢端;範例程式用「超過 30 °C」「連續 5 筆失敗」當示範門檻。
  • 長期資料由巡檢端保存:裝置只存約 1 小時,重開機就清空。
  • boot_id 變了就從第 1 筆重拉。
AI 看到的數字有多準限制

DHT11 在 25 °C 時精度 ±2 °C、±5 %RH,適合看趨勢;ESP32 也會自熱。建議和參考溫濕度計並放 30 分鐘,做一次偏移校正。

還沒驗證:緩衝存滿 720 筆時約 70 KB 的完整回應、連續一天的記憶體穩定性、實際關掉 AP 時的 Wi-Fi 重連。

回扣

一個小盒子,背後要懂的東西其實很多。

表面只有八句話。下面每一格都是點開才看得到的深度:點了會跳回那一站,直接打開那一段。

→→→→→→→↺

01產品設計師

02採購

03接線

04機構

05切片

06韌體

07軟體

08AI 接入

完整紀錄在研究報告區的詳版。時間軸、15 項檢查、測試數字、BOM 與查價來源都在那裡;這份簡報只挑重點。

機房溫濕度監測器實作紀錄(詳版)→

素材:實機照片由專案需求方拍攝(已移除照片中的位置等中繼資料,背景螢幕已模糊);30 腳外殼算繪圖與 3D 模型取自本專案機構成果;接線圖元件取自 Wokwi Elements(MIT,授權全文);3D 檢視器使用 three.js r160(MIT,授權全文)。

數字以詳版正文與 BOM(2026-11-11 查價)為準。網路價格會變動。