RTX 3060 12GB的LLM性能測試

Rentry的易讀版本： https://rentry.org/uwq752e3

LLM性能測試

硬體

CPU: Intel i5-12500
RAM: 64GB DDR4-3200 （雙通道）
GPU: NVIDIA RTX 3060 12GB
OS: Unraid 7.5

測試軟體：llama-benchy 0.3.7
指令
llama-benchy --base-url <api url> --model zerofata/G4-MeroMero-26B-A4B --depth 0 4096 8192 16384 --tg 128 --latency-mode generation --enable-prefix-caching
測試模型：G4-MeroMero-26B-A4B Q5_K_M量化版本（Gamma 4 26B A4B的微調版本）

測試標的

llamacpp b9014 cuda12 backend（官方提供的docker映像）

啟動參數
llama-server -m /models/model.gguf --port 8000 --host 0.0.0.0 -fit on -c 32768 --chat-template-file /models/g4-chat_template.jinja

測試結果

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
zerofata/G4-MeroMero-26B-A4B	pp2048	512.92 ± 26.80		4105.91 ± 202.11	4005.34 ± 202.11	4105.91 ± 202.11
zerofata/G4-MeroMero-26B-A4B	tg128	31.04 ± 0.27	32.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d4096	468.40 ± 29.34		8880.41 ± 526.80	8779.84 ± 526.80	8880.41 ± 526.80
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d4096	29.73 ± 0.10	31.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d4096	466.13 ± 21.00		4503.40 ± 204.89	4402.83 ± 204.89	4503.40 ± 204.89
zerofata/G4-MeroMero-26B-A4B	tg128 @ d4096	29.50 ± 0.04	30.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d8192	461.37 ± 16.77		17882.10 ± 663.02	17781.53 ± 663.02	17882.10 ± 663.02
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d8192	29.79 ± 0.04	31.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d8192	451.60 ± 13.77		4639.80 ± 140.88	4539.23 ± 140.88	4639.80 ± 140.88
zerofata/G4-MeroMero-26B-A4B	tg128 @ d8192	28.83 ± 0.66	30.67 ± 0.47
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d16384	473.32 ± 15.88		34756.61 ± 1166.07	34656.04 ± 1166.07	34756.61 ± 1166.07
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d16384	28.18 ± 0.48	30.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d16384	453.97 ± 5.18		4612.45 ± 51.82	4511.88 ± 51.82	4612.45 ± 51.82
zerofata/G4-MeroMero-26B-A4B	tg128 @ d16384	29.21 ± 0.11	30.00 ± 0.00

測試結果分析（Gemini

這份針對 32k 上下文長度（Context Size） 的測試結果，展現了 Gemma 4 26B A4B 在 RTX 3060 12GB 顯卡上極為驚人的長文本處理韌性。以下將數據整理為效能分析段落：

核心生成效能與穩定性

在將上下文長度擴展至 32,768 的環境下，模型展現了極強的生成速度（Token Generation）穩定性。從初始狀態的 31.04 t/s 到處理至 16k 深度時的 28.18 t/s，效能衰減率僅約 9.2%。這意味著即便在長篇對話或處理複雜劇本時，使用者幾乎感受不到「蹦字」速度的變化。這種在 26B 等級模型中罕見的高穩定性，側面證實了該模型架構（如 GQA 分組查詢注意力機制）與 llama.cpp 記憶體管理的高度優化，能將活躍參數與 KV Cache 完美控制在 12GB 的 VRAM 極限內。

提示詞處理與延遲趨勢

在處理輸入（Prompt Processing）方面，吞吐量穩定維持在 450 ~ 510 t/s 之間，展現了極佳的預處理效率。首字響應時間（TTFT）則隨著文本長度呈精確的線性增長：處理 4k 文本約需 8.8 秒，8k 需 17.8 秒，當長度達到 16k 時則需約 34.7 秒。雖然等待時間隨長度增加，但並沒有出現因顯存溢出或系統記憶體交換（Swap）導致的效能崩潰（Cliff edge），這對於需要頻繁貼入長文進行摘要或代碼分析的使用者來說，提供了非常可預測且穩定的使用體驗。

綜合效能評價

總結來看，這套配置在 16k context 範圍內達到了「效能與容量」的甜蜜平衡點。雖然系統設定上限為 32k，但在 16k 深度下依然能維持超過 28 t/s 的生成速度，完全能勝任中長篇文件閱讀、深度角色扮演（Roleplay）以及長代碼庫的維護任務。對於 RTX 3060 12GB 的使用者而言，這份數據證明了該硬體在適當的量化方案下，依然擁有越級挑戰大型長文本模型的實力。

本地跑LLM的算力需求

Prefill（預填充階段）：運算性能。處理使用者輸入的提示詞，運算速度卡在GPU的性能。影響首字輸出時間（Time to First Token, TTFT），如果處理的的上下文很大，就需要花很長的時間才會開始輸出結果。比如說我的Radeon 780m能夠處理400t/s，處理32k的上下文大約得花80秒。

Decode（解碼階段）：記憶體頻寬。逐一生成 Token 的過程，卡在GPU與VRAM之間的頻寬。每生成一個新 Token，模型都必須把所有的模型參數從顯示記憶體重新讀取到運算單元中一次，只為了計算「那一個」Token。以Radeon 780m為例，搭配雙通道DDR5-5600 SODIMM理論上有89.6GB/s的頻寬，跑Gemma 4 26B A4B Q5_K_M，因為量化加上只有啟動3.8B的參數，每次從記憶體讀取的量約為2.6GB。這樣可以估算生成速度約在34t/s，但實際上會有額外耗損，根據我的實測是在20~14t/s左右。不算快，但高於一般人的閱讀速度。我有試過跑Gemma 4 31B IQ4_XS的量化稠密模型，生成速度大約是2t/s，太慢了。

結論
如果要處理的文本很大，優先考慮GPU運算性能。
如果輸出的內容很大，優先考慮記憶體頻寬。

若是兩者都需要，RTX 6000 Blackwell 96GB在旁邊招手呢，一張約新台幣30萬左右，比買三張RTX 5090貴，但是配置較簡單。

Ryzen 8845HS w/ Radeon 780M的LLM性能測試

 Rentry的易讀表格版本：https://rentry.co/5utrg5cy

LLM性能測試

硬體

GMKTek K8 Plus
CPU: AMD Ryzen 8845HS
RAM: 64GB DDR5-5600 SODIMM（雙通道）
GPU: Radeon 780m 8GB（透過BIOS設置VRAM大小）
OS: Ubuntu 24.04

系統配置調整：

/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.gttsize=49152 ttm.pages_limit=12582912"
主要是讓單一程序可以使用最多48GB的記憶體。

測試軟體：llama-benchy 0.3.7
指令
llama-benchy --base-url <api url> --model zerofata/G4-MeroMero-26B-A4B --depth 0 4096 8192 16384 32768 --tg 128 --latency-mode generation --enable-prefix-caching
測試模型：G4-MeroMero-26B-A4B Q5_K_M量化版本（Gamma 4 26B A4B的微調版本）

測試標的

koboldcpp-1.112.2

啟動指令
./koboldcpp-linux-x64-nocuda --model ./G4-MeroMero-26B-A4B-Q5_K_M.gguf --host 0.0.0.0 --threads 7 --usevulkan 0 --blasbatchsize 2048 --gpulayers 49 --contextsize 32768 --flashattention --skiplauncher --jinja --mmproj ./mmproj-Gemma-4-26b-a4b-f16.gguf --mlock --usemmap --jinjatemplate ./chat_template.jinja

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
zerofata/G4-MeroMero-26B-A4B	pp2048	419.95 ± 2.39		5288.49 ± 27.66	4879.28 ± 27.66	5288.49 ± 27.66
zerofata/G4-MeroMero-26B-A4B	tg128	18.41 ± 0.04	20.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d4096	384.90 ± 3.16		11054.21 ± 87.02	10644.99 ± 87.02	11054.21 ± 87.02
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d4096	17.54 ± 0.05	19.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d4096	350.57 ± 2.01		6251.27 ± 33.44	5842.05 ± 33.44	6251.27 ± 33.44
zerofata/G4-MeroMero-26B-A4B	tg128 @ d4096	17.30 ± 0.02	19.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d8192	357.27 ± 1.90		23341.93 ± 122.05	22932.71 ± 122.05	23341.93 ± 122.05
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d8192	16.97 ± 0.02	18.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d8192	313.21 ± 0.19		6947.91 ± 3.87	6538.69 ± 3.87	6947.91 ± 3.87
zerofata/G4-MeroMero-26B-A4B	tg128 @ d8192	16.75 ± 0.02	18.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d16384	311.77 ± 1.46		52964.47 ± 245.13	52555.26 ± 245.13	52964.47 ± 245.13
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d16384	16.19 ± 0.08	17.33 ± 0.47
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d16384	254.26 ± 0.49		8464.01 ± 15.68	8054.79 ± 15.68	8464.01 ± 15.68
zerofata/G4-MeroMero-26B-A4B	tg128 @ d16384	15.94 ± 0.02	17.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d32768	261.11 ± 1.65		125417.69 ± 791.20	125008.48 ± 791.20	125417.69 ± 791.20
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d32768	14.70 ± 0.02	16.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d32768	142.70 ± 1.09		14761.37 ± 109.20	14352.15 ± 109.20	14761.37 ± 109.20
zerofata/G4-MeroMero-26B-A4B	tg128 @ d32768	14.77 ± 0.02	16.00 ± 0.00

llamacpp-rocm b1256

啟動指令
./llamacpp-rocm/llama-server -m ./G4-MeroMero-26B-A4B-Q5_K_M.gguf -ngl 99 -c 32768 --temp 1 --top-k 64 --top-p 0.95 --host 0.0.0.0 -mm ./mmproj-Gemma-4-26b-a4b-f16.gguf --chat-template-file ./chat_template.jinja
在16k的測試出現異常，可能是模型崩潰與重複輸出造成。

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
zerofata/G4-MeroMero-26B-A4B	pp2048	335.70 ± 14.45		6233.64 ± 258.34	6115.70 ± 258.34	6233.64 ± 258.34
zerofata/G4-MeroMero-26B-A4B	tg128	15.42 ± 0.01	16.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d4096	290.31 ± 12.24		14253.80 ± 580.96	14135.86 ± 580.96	14253.80 ± 580.96
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d4096	14.07 ± 0.01	15.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d4096	238.90 ± 2.19		8691.36 ± 78.59	8573.42 ± 78.59	8691.36 ± 78.59
zerofata/G4-MeroMero-26B-A4B	tg128 @ d4096	13.79 ± 0.01	14.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d8192	260.37 ± 3.20		31589.77 ± 383.96	31471.83 ± 383.96	31589.77 ± 383.96
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d8192	13.67 ± 0.01	14.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d8192	218.36 ± 0.69		9497.17 ± 29.59	9379.23 ± 29.59	9497.17 ± 29.59
zerofata/G4-MeroMero-26B-A4B	tg128 @ d8192	13.55 ± 0.00	14.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d16384	241.87 ± 3.54		67874.56 ± 1000.78	67756.62 ± 1000.78	67874.56 ± 1000.78
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d16384	66.75 ± 0.02	70.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d16384	204.84 ± 2.69		10117.85 ± 130.36	9999.91 ± 130.36	10117.85 ± 130.36
zerofata/G4-MeroMero-26B-A4B	tg128 @ d16384	66.23 ± 0.04	69.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d32768	191.92 ± 10.78		171424.55 ± 10017.11	171306.61 ± 10017.11	171424.55 ± 10017.11
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d32768	12.37 ± 0.07	13.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d32768	142.47 ± 3.70		14502.40 ± 380.91	14384.46 ± 380.91	14502.40 ± 380.91
zerofata/G4-MeroMero-26B-A4B	tg128 @ d32768	12.34 ± 0.00	13.00 ± 0.00

llamacpp b8999 (vulkan backend)

啟動指令
./llama-b8999/llama-server -m ./G4-MeroMero-26B-A4B-Q5_K_M.gguf -ngl 99 -c 49152 --temp 1 --top-k 64 --top-p 0.95 --host 0.0.0.0 -mm ./mmproj-Gemma-4-26b-a4b-f16.gguf --chat-template-file ./chat_template.jinja
在32k的測試出現異常，可能是模型崩潰與重複輸出造成。

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
zerofata/G4-MeroMero-26B-A4B	pp2048	315.62 ± 12.25		6633.52 ± 244.36	6502.53 ± 244.36	6633.52 ± 244.36
zerofata/G4-MeroMero-26B-A4B	tg128	20.70 ± 0.02	21.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d4096	291.80 ± 10.49		14189.23 ± 493.34	14058.24 ± 493.34	14189.23 ± 493.34
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d4096	19.54 ± 0.00	20.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d4096	275.22 ± 1.81		7572.64 ± 49.08	7441.65 ± 49.08	7572.64 ± 49.08
zerofata/G4-MeroMero-26B-A4B	tg128 @ d4096	19.53 ± 0.01	20.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d8192	286.29 ± 1.35		28747.85 ± 134.81	28616.86 ± 134.81	28747.85 ± 134.81
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d8192	19.68 ± 0.03	20.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d8192	252.09 ± 0.21		8254.93 ± 6.84	8123.94 ± 6.84	8254.93 ± 6.84
zerofata/G4-MeroMero-26B-A4B	tg128 @ d8192	18.64 ± 0.03	19.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d16384	269.11 ± 1.28		61018.78 ± 289.55	60887.79 ± 289.55	61018.78 ± 289.55
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d16384	18.08 ± 0.00	19.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d16384	217.98 ± 1.58		9526.90 ± 67.69	9395.91 ± 67.69	9526.90 ± 67.69
zerofata/G4-MeroMero-26B-A4B	tg128 @ d16384	18.01 ± 0.02	19.00 ± 0.00
zerofata/G4-MeroMero-26B-A4B	ctx_pp @ d32768	231.32 ± 0.68		141795.99 ± 417.40	141665.00 ± 417.40	141795.99 ± 417.40
zerofata/G4-MeroMero-26B-A4B	ctx_tg @ d32768	31.67 ± 20.37	41.67 ± 33.47
zerofata/G4-MeroMero-26B-A4B	pp2048 @ d32768	168.40 ± 1.35		12292.98 ± 97.49	12161.99 ± 97.49	12313.51 ± 124.96
zerofata/G4-MeroMero-26B-A4B	tg128 @ d32768	16.47 ± 0.01	17.00 ± 0.00

綜合測試結論（使用Gemini做的分析

1. 硬體潛力與系統優化

• 記憶體配置與優化： 透過調整 Linux 核心參數（GRUB）將 amdgpu.gttsize 設為 48GB，是成功在此類 iGPU 設備上順暢執行 26B 大模型量化版的關鍵。64GB 的實體記憶體為 780M 提供了充足的空間來處理大型模型文件及高達 32K 的 Context 需求。
• 推論效能： 整體而言，在 8845HS 的平台上，26B Q5 模型能達到約 15~20 t/s 的生成速度，對於單人使用情境已具備極高的實用性，接近一般人的閱讀速度。

2. 後端軟體性能對比 (Backend Comparison)

測試項目	Koboldcpp-1.112.2	Llamacpp (Vulkan)	Llamacpp-rocm
提示處理 (Prompt Processing)	最快 (~420 t/s)	中等 (~315 t/s)	較慢 (~335 t/s)
權杖生成 (Token Gen)	穩定 (~18.4 t/s)	最高 (~20.7 t/s)	較慢 (~15.4 t/s)
長文本穩定性 (Stability)	極高，隨 Context 增加性能衰減平緩。	高 Context (32k) 時出現數據異常。	中 Context (16k) 時出現異常。

• Koboldcpp： 在本次測試中表現最為均衡且可靠。其 Prompt Processing 速度大幅領先，且在高 Context (32768) 下依然維持穩定的生成速度（14.7 t/s），沒有出現模型崩潰或邏輯異常，是長文本應用的首選。
• Llamacpp (Vulkan)： 提供了最高的初始生成速度（超過 20 t/s），但在 Context 達到 32k 時出現數據劇烈波動與異常（Variance 較大），顯示在極端上下文負荷下驅動或後端尚不夠穩定。
• Llamacpp-rocm： 在此硬體配置下表現差強人意，不僅生成速度最低，且在 16k Context 時便提早出現模型異常，推測 ROCm 在此 APU 上的優化或記憶體管理仍有改進空間。

3. 測試異常觀察

• 在 llamacpp-rocm (16k) 與 vulkan (32k) 的測試中，出現了速度異常（如跳升至 66 t/s）或誤差值過大的現象，這通常與模型崩潰、重複輸出 (Repetition) 或 K-V Cache 溢位有關。這指出在 iGPU 環境下進行超長文本推論時，後端軟體的穩定性 (Robustness) 比純粹的峰值速度更為重要。

---

總結建議

對於使用 AMD Ryzen 8000 系列 APU 的用戶，若要執行 26B 規模 的模型：

1. 推薦後端： 優先選用 Koboldcpp，其在長文本處理的穩定度與 Prompt 處理速度上具有明顯優勢。
2. 效能追求： 若僅進行短文本對話，可嘗試 Llamacpp (Vulkan) 以獲取最高生成速度。
3. 環境設定： 務必修改系統核心參數以釋放顯存限制，否則無法充分發揮 64GB 記憶體的硬體優勢。

在Ryzen 7 8845HS w/ Radeon 780M用ComfyUI生圖（Linux）

試了很久才發現成功的方程式…這是因為每次安裝ROCm都需要下載安裝超過30GB的檔案！！！

 

tl;dr 直接說結論

OS: Ubuntu 22.04（因為ROCm 6.1只支援此以下的版本）

ROCm:  <= 6.1.2，6.2跟6.3都沒辦法正常運行

PyTorch: <= 2.4.1，2.5.1版會顯示不支援硬體的警告，圖片有時候無法正確產生。

UserWarning: Attempting to use hipBLASLt on an unsupported architecture! Overriding blas backend to hipblas 

2.6以上則完全無法正常運行。使用PyTorch官網的版本而不是AMD提供的。

https://pytorch.org/get-started/previous-versions/

ComfyUI: 當前版本v0.3.14可正常運行。 

 

Update 2024/2/25

使用 Radeon 780M 產生圖片的時候經常會出現全黑的圖，並且出現以下警告

RuntimeWarning: invalid value encountered in cast
  img = Image.fromarray(np.clip(i, 0, 255).astype(np.uint8))

原本以為是 780M 沒有被 ROCm 支援的問題，但 ComfyUI 在去年的確發生過這樣的 bug，且不限硬體。我從下面的連結得到解法
https://github.com/comfyanonymous/ComfyUI/issues/3500

解法就是：換 scheduler，預設是 normal ，換成 karras 似乎就沒有再出現這樣的問題。

我的Home Assistant配置

Home Assistant 是用於家庭自動化的免費開源軟體。它作為整合平台和智慧家庭中心，允許用戶控制智慧家居設備。該軟體強調本地控制和隱私，設計獨立於任何特定的物聯網生態系統。 - 維基百科

我會使用Home Assistant （簡稱HA）應該是在我買了Sonoff S30智慧插座與Basic R2智慧開關，但我不想使用製造商的平台或App，研究了一下決定在S30刷入ESPHome，Basic R2刷入Tasmota，然後接上HA來控制。而S30還有電流計的功能，可以整合到HA做能源消耗的監測。Home Assistant是裝在Raspberry Pi 4 (4GB RAM，簡稱RPi4）。

之後我想監控每個房間的溫濕度，上網搜尋可用的方案，最多人建議是小米的米家藍牙溫濕度計 2因為這個小裝置非常便宜，並刷入ATC的韌體來改善耗電與連接性。但問題來了，溫濕度計的放置位置離RPi4很遠，肯定收不到訊號。而改善的作法是購買幾個便宜的ESP32-C3-MINI-1刷入ESPHome的Bluetooth Proxy配置。之前提到使用ATC的韌體是要讓溫濕度計定期用藍芽低功耗技術來廣播資料，而這些Bluetooth Proxy則作為中繼，傳送資料回HA，這樣的設計會比主動連接的耗電量少，資料取得比較快且穩定。

後來我買了兩個Reolink的網路攝影機，作為車庫與門口的監控。但跟前面一樣，我不想使用製造商提供的平台或軟體，會選擇這個廠牌是因為它提供區域網路連接功能，網路上最多人推薦使用FRIGATE，這個開源軟體可以與HA深度整合，方便檢視與管理各種事件與錄影，並且支援物件識別的功能，雖然可以使用CPU來做識別但極度推薦專用的AI加速器：Coral USB Accelerator，可以快速識別影像中的物件。當然它提供物件識別的模型並不完美，你可以支付一次性的費用，上傳需要辨識或修正的影像來做訓練，一年內可以訓練12次。就我的經驗只訓練兩次就已經沒碰到識別錯誤的問題。自動化的部份則是使用HA論壇上網友提供的藍圖，在影像偵測到有人時發送通知到HA的手機APP。

因為我家是透天有鐵捲門，我就在想要怎麼把開關鐵捲門的功能整合到HA，但是我不想去修改鐵捲門控制器，因為風險太高。最後我想到的作法是拿一個外殼破損但功能完好的鐵捲門遙控器來改裝，上網研究發現只需要一片Lolin d1 mini、一個12V轉3.3V的降壓模組、然後加上幾個電晶體與電阻做成開關電路，就可以接上遙控器來控制。

幾個月前買了SwitchBot的套件組（主控機器人2、開關機器人、門窗感測器），主控機器人2的功能需要透過雲端連接，但是開關機器人與門窗感測器則可以使用藍芽連接，前面提到的Bluetooth Proxy又可以派上用場。門窗感測器裝在大門，可以很方便知道大門是不是沒關好，有沒有人經過，這也是透過HA來發送通知。而開關機器人則是裝在車庫的電燈開關，透過HA可以設計為打開鐵捲門同時開燈。

最近買了Shelly EM想要強化能源消耗的監控，但是打開配線箱後發現這遠超過我的能力，可能要找水電技師來協助安裝。

總而言之，家庭自動化是一條不歸路，花的錢會越來越多。