1. 從一塊開發(fā)板到全屋智能我為什么選擇 Android Things 做智能家居中樞2017 年夏天我拿到第一塊 Raspberry Pi 3 的時(shí)候腦子里想的全是這玩意兒能不能當(dāng)家里的控制中心。當(dāng)時(shí)市面上主流的方案無非是樹莓派跑 Home Assistant、ESP8266 接繼電器、或者直接買小米/涂鴉的成品套裝。成品套裝省事但擴(kuò)展性差想加個(gè)自定義傳感器就得看廠商臉色ESP8266 方案便宜但每個(gè)節(jié)點(diǎn)都要單獨(dú)寫固件設(shè)備一多維護(hù)成本直線上升。后來接觸到 Android Things我才算找到了一個(gè)相對平衡的切入點(diǎn)——它既有 Android 成熟的開發(fā)工具鏈和 UI 框架又能直接操作 GPIO、I2C、SPI 這些硬件接口最關(guān)鍵的是我可以用寫 App 的思路去寫硬件邏輯這對一個(gè) Android 開發(fā)者來說幾乎是零門檻。Android Things 是 Google 在 2015 年當(dāng)時(shí)叫 Brillo推出、2016 年正式更名的物聯(lián)網(wǎng)操作系統(tǒng)本質(zhì)上是裁剪過的 Android 系統(tǒng)專門跑在 Raspberry Pi 3、NXP i.MX7D、Intel Edison 這類開發(fā)板上。它的核心價(jià)值在于把 Android 的 Framework 層保留下來同時(shí)提供一套 Peripheral I/O API讓開發(fā)者用 Java/Kotlin 就能控制 GPIO 引腳、讀寫 I2C 傳感器、驅(qū)動(dòng) PWM 設(shè)備。換句話說你不需要懂 Linux 驅(qū)動(dòng)開發(fā)也不需要寫 C 語言固件只要會(huì)寫 Android App就能做出一個(gè)能跑起來的智能家居網(wǎng)關(guān)。這篇文章適合誰看如果你是有 Android 開發(fā)基礎(chǔ)、想折騰智能家居但不想從零學(xué)嵌入式的人那這篇內(nèi)容基本就是為你寫的。如果你完全沒接觸過 Android 開發(fā)也沒關(guān)系我會(huì)把關(guān)鍵概念用生活化的方式講清楚你至少能理解整套系統(tǒng)的運(yùn)作邏輯。整篇內(nèi)容我會(huì)圍繞一個(gè)實(shí)際項(xiàng)目展開用 Raspberry Pi 3 Android Things 做一個(gè)智能家居中樞接入溫濕度傳感器、繼電器控制燈光、通過手機(jī) App 遠(yuǎn)程查看和控制。所有代碼和配置我都會(huì)給出可直接參考的版本踩過的坑也會(huì)一并說明。2. 整體方案設(shè)計(jì)與技術(shù)選型思路2.1 為什么不用 Home Assistant 或 ESP8266 方案在動(dòng)手之前我先花了兩周時(shí)間對比了三種主流方案最后才確定用 Android Things。這個(gè)對比過程很有必要因?yàn)檫x型決定了后面所有的開發(fā)路徑。Home Assistant 方案的優(yōu)勢是生態(tài)成熟插件多幾乎支持市面上所有主流品牌的設(shè)備。但它的短板也很明顯配置全靠 YAML 文件邏輯稍微復(fù)雜一點(diǎn)就要寫 Python 腳本而且 UI 定制能力有限。我之前用 Home Assistant 接了一個(gè)自定義的土壤濕度傳感器光是調(diào)試 MQTT 通信就花了一個(gè)周末最后發(fā)現(xiàn)是 YAML 縮進(jìn)問題。對于想深度定制交互邏輯的人來說Home Assistant 更像是一個(gè)配置平臺(tái)而不是開發(fā)平臺(tái)。ESP8266/ESP32 方案的優(yōu)勢是成本低、功耗小一個(gè)節(jié)點(diǎn)十幾塊錢就能搞定。但問題在于每個(gè)節(jié)點(diǎn)都是獨(dú)立的固件你要么用 Arduino IDE 寫 C要么用 MicroPython。設(shè)備少的時(shí)候還好一旦超過 5 個(gè)節(jié)點(diǎn)固件版本管理、OTA 升級、設(shè)備間通信都會(huì)變成噩夢。我之前做過一個(gè) 8 節(jié)點(diǎn)的 ESP8266 方案光是統(tǒng)一固件版本就折騰了三天。Android Things 的定位剛好在兩者之間它比 Home Assistant 更靈活因?yàn)槟憧梢酝耆远x業(yè)務(wù)邏輯它比 ESP8266 方案更好維護(hù)因?yàn)樗性O(shè)備可以共享一套 Android 代碼庫OTA 升級直接用 Android 的機(jī)制。當(dāng)然它的成本比 ESP8266 高一塊 Raspberry Pi 3 大概 200 多塊但作為中樞只需要一塊終端節(jié)點(diǎn)還是可以用便宜的 ESP8266 通過 MQTT 接入。2.2 系統(tǒng)架構(gòu)中樞 終端 手機(jī) App 三層結(jié)構(gòu)最終確定的架構(gòu)是三層中樞層Raspberry Pi 3 跑 Android Things負(fù)責(zé)設(shè)備管理、數(shù)據(jù)聚合、邏輯決策。它直接通過 GPIO/I2C 連接本地傳感器和執(zhí)行器同時(shí)通過 MQTT 或 HTTP 與遠(yuǎn)程終端節(jié)點(diǎn)通信。終端層ESP8266 節(jié)點(diǎn)負(fù)責(zé)分布式傳感和執(zhí)行比如臥室的溫濕度采集、客廳的燈光控制。它們通過 Wi-Fi 與中樞通信協(xié)議用 MQTT因?yàn)?MQTT 輕量、支持發(fā)布訂閱、斷線重連機(jī)制成熟。應(yīng)用層Android 手機(jī) App 通過 HTTP/WebSocket 與中樞交互查看數(shù)據(jù)、下發(fā)控制指令。App 本身也是 Android 項(xiàng)目可以復(fù)用一部分代碼邏輯。這個(gè)架構(gòu)的核心思路是集中決策、分布執(zhí)行。中樞負(fù)責(zé)所有邏輯判斷終端只做數(shù)據(jù)采集和指令執(zhí)行這樣終端固件可以做得非常簡單幾乎不需要改動(dòng)。比如溫度高于 28 度自動(dòng)開風(fēng)扇這個(gè)邏輯放在中樞里用 Kotlin 寫幾行代碼就行不需要在每個(gè)終端節(jié)點(diǎn)里重復(fù)實(shí)現(xiàn)。2.3 硬件選型與參數(shù)計(jì)算硬件清單如下設(shè)備型號(hào)數(shù)量用途參考價(jià)格開發(fā)板Raspberry Pi 3 Model B1中樞主機(jī)220 元溫濕度傳感器DHT111環(huán)境監(jiān)測8 元繼電器模塊5V 單路繼電器2燈光控制6 元/個(gè)電源5V 2.5A Micro USB1中樞供電25 元杜邦線母對母 20cm1 排接線5 元ESP8266 模塊NodeMCU2終端節(jié)點(diǎn)15 元/個(gè)這里重點(diǎn)說一下電源的選擇。Raspberry Pi 3 的峰值電流可以到 2.5A如果用手機(jī)充電器通常 1A 或 2A在 Wi-Fi 滿負(fù)荷 GPIO 驅(qū)動(dòng)繼電器的時(shí)候會(huì)出現(xiàn)電壓跌落導(dǎo)致系統(tǒng)重啟。我一開始用了一個(gè) 5V 1A 的充電器結(jié)果每次繼電器吸合的瞬間樹莓派就重啟排查了半天才定位到是供電不足。后來換成 5V 2.5A 的專用電源問題徹底消失。所以電源這塊千萬別省寧可買大一點(diǎn)。DHT11 的精度是溫度 ±2°C、濕度 ±5%RH對于家居環(huán)境監(jiān)測夠用了。如果你需要更高精度可以換成 DHT22 或 SHT30但價(jià)格會(huì)貴一些而且 SHT30 是 I2C 接口接線方式不同。DHT11 用的是單總線協(xié)議Android Things 的 Peripheral I/O API 不直接支持這種協(xié)議需要自己用 GPIO 模擬時(shí)序這部分后面會(huì)詳細(xì)講。3. Android Things 核心開發(fā)細(xì)節(jié)與實(shí)操要點(diǎn)3.1 環(huán)境搭建從 Android Studio 到開發(fā)板燒錄Android Things 的開發(fā)環(huán)境搭建和普通 Android 開發(fā)差不多但有幾個(gè)關(guān)鍵區(qū)別。首先Android Studio 需要安裝 Android Things SDK。在 SDK Manager 里勾選 Android Things 相關(guān)的包主要是com.google.android.things這個(gè)庫。然后在build.gradle里添加依賴dependencies { implementation com.google.android.things:androidthings:1.0 }注意版本號(hào)1.0 是穩(wěn)定版0.8 之前的 API 有較大變動(dòng)網(wǎng)上很多老教程用的是 0.5 或 0.6代碼直接拿過來會(huì)編譯不過。其次開發(fā)板需要燒錄 Android Things 鏡像。以 Raspberry Pi 3 為例去 Android Things 官網(wǎng)下載對應(yīng)版本的鏡像文件.img格式然后用 Etcher 或dd命令寫入 SD 卡。寫入完成后把 SD 卡插入樹莓派接上 HDMI 顯示器和網(wǎng)線上電啟動(dòng)。第一次啟動(dòng)會(huì)比較慢大概 2-3 分鐘屏幕上會(huì)顯示一個(gè) Android Things 的 Logo 和 IP 地址。這里有個(gè)坑Android Things 默認(rèn)通過 ADB over Ethernet 連接但如果你沒有網(wǎng)線想用 Wi-Fi 連接需要先通過串口或 HDMI 鍵盤進(jìn)入系統(tǒng)設(shè)置。我當(dāng)時(shí)的做法是先用網(wǎng)線連上通過adb connect IP連上去然后用adb shell執(zhí)行 Wi-Fi 配置命令adb shell am startservice \ -n com.google.wifisetup/.WifiSetupService \ -a WifiSetupService.Connect \ -e ssid 你的WiFi名稱 \ -e passphrase 你的WiFi密碼配置成功后拔掉網(wǎng)線重啟樹莓派就會(huì)自動(dòng)連上 Wi-Fi。之后每次連接只需要adb connect Wi-Fi IP就行。3.2 GPIO 控制用代碼點(diǎn)亮一盞燈Android Things 的 GPIO 操作非常直觀。核心類是PeripheralManagerService通過它獲取Gpio對象然后設(shè)置方向輸入或輸出和初始狀態(tài)。PeripheralManagerService manager new PeripheralManagerService(); Gpio ledPin manager.openGpio(BCM17); ledPin.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW); ledPin.setValue(true); // 點(diǎn)亮這里的BCM17是引腳名稱對應(yīng) Raspberry Pi 的 GPIO17。不同開發(fā)板的引腳名稱不一樣Raspberry Pi 用的是 BCM 編號(hào)NXP i.MX7D 用的是另一套命名。你可以在 Android Things 的官方文檔里查到對應(yīng)開發(fā)板的引腳映射表。實(shí)際接線的時(shí)候GPIO 輸出是 3.3V 邏輯電平而繼電器模塊通常是 5V 觸發(fā)的。這里有兩種處理方式一是用 3.3V 兼容的繼電器模塊市面上有專門為 3.3V 設(shè)計(jì)的二是加一個(gè)電平轉(zhuǎn)換模塊。我一開始用的是普通 5V 繼電器直接接 GPIO 發(fā)現(xiàn)繼電器不吸合用萬用表一量GPIO 輸出只有 3.3V達(dá)不到繼電器的觸發(fā)閾值。后來換了一個(gè) 3.3V 兼容的繼電器模塊問題解決。所以買繼電器的時(shí)候一定要看清楚觸發(fā)電壓。另外GPIO 引腳在系統(tǒng)啟動(dòng)時(shí)的默認(rèn)狀態(tài)是不確定的可能會(huì)在初始化之前有一個(gè)短暫的高電平脈沖。如果你控制的是燈光這個(gè)脈沖會(huì)導(dǎo)致燈閃一下。解決辦法是在硬件上加一個(gè)下拉電阻或者在軟件里盡早初始化 GPIO。我在代碼里是在onCreate里第一時(shí)間就打開 GPIO 并設(shè)置為低電平這樣脈沖時(shí)間可以縮短到幾毫秒肉眼基本看不出來。3.3 I2C 與單總線DHT11 的驅(qū)動(dòng)實(shí)現(xiàn)DHT11 用的是單總線協(xié)議Android Things 沒有現(xiàn)成的 API需要用 GPIO 手動(dòng)模擬時(shí)序。這個(gè)協(xié)議的核心是主機(jī)拉低總線至少 18ms然后釋放等待傳感器響應(yīng)。傳感器會(huì)拉低 80us再拉高 80us然后開始傳輸 40 位數(shù)據(jù)8 位濕度整數(shù) 8 位濕度小數(shù) 8 位溫度整數(shù) 8 位溫度小數(shù) 8 位校驗(yàn)和。用 Java 實(shí)現(xiàn)的時(shí)候最大的難點(diǎn)是時(shí)序精度。Android Things 跑在 Linux 上Java 的Thread.sleep()精度只有毫秒級而 DHT11 的時(shí)序要求是微秒級。我試過直接用System.nanoTime()做忙等待但 Java 的 JIT 編譯和 GC 會(huì)導(dǎo)致偶爾的延遲抖動(dòng)讀取成功率只有 60% 左右。后來我換了一個(gè)思路用 Android Things 的Gpio回調(diào)機(jī)制來捕獲邊沿變化而不是主動(dòng)輪詢。具體做法是設(shè)置setEdgeTriggerType(Gpio.EDGE_BOTH)然后注冊GpioCallback在回調(diào)里記錄時(shí)間戳。這樣雖然不能完全消除抖動(dòng)但成功率能提高到 85% 以上。對于家居環(huán)境監(jiān)測來說這個(gè)成功率夠用了因?yàn)槟憧梢悦棵胱x一次連續(xù)讀 3 次取有效值。如果你對精度要求更高建議直接用 I2C 接口的傳感器比如 SHT30 或 BME280。Android Things 對 I2C 的支持非常完善I2cDevice device manager.openI2cDevice(I2C1, 0x44); byte[] data new byte[6]; device.read(data, data.length); // 解析溫濕度數(shù)據(jù)I2C 的讀取是硬件級別的不受 Java 時(shí)序抖動(dòng)影響穩(wěn)定性遠(yuǎn)超單總線方案。我后來把 DHT11 換成了 SHT30讀取成功率直接到 100%而且精度也更高。3.4 網(wǎng)絡(luò)通信MQTT 與 HTTP 的取舍中樞與終端節(jié)點(diǎn)的通信我選了 MQTT。原因有三第一MQTT 是發(fā)布訂閱模型終端節(jié)點(diǎn)只需要訂閱自己關(guān)心的主題不需要知道其他節(jié)點(diǎn)的存在第二MQTT 有 QoS 等級可以保證消息至少送達(dá)一次第三MQTT 的 Keep Alive 機(jī)制可以自動(dòng)檢測斷線配合遺囑消息Last Will可以在節(jié)點(diǎn)離線時(shí)通知中樞。Android Things 上跑 MQTT 客戶端我用的是 Eclipse Paho 庫implementation org.eclipse.paho:org.eclipse.paho.client.mqttv3:1.2.0連接代碼MqttClient client new MqttClient(tcp://192.168.1.100:1883, android-things-hub, new MemoryPersistence()); MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(true); options.setKeepAliveInterval(30); options.setAutomaticReconnect(true); client.connect(options); client.subscribe(home/sensor/#, (topic, message) - { // 處理傳感器數(shù)據(jù) });這里有個(gè)細(xì)節(jié)setAutomaticReconnect(true)是必須的因?yàn)?Wi-Fi 不穩(wěn)定的時(shí)候 MQTT 連接會(huì)斷自動(dòng)重連可以省去很多手動(dòng)處理的代碼。但自動(dòng)重連有個(gè)問題重連后之前的訂閱會(huì)丟失如果cleanSession為 true所以需要在MqttCallback的connectComplete方法里重新訂閱。HTTP 主要用于手機(jī) App 與中樞的交互。我在中樞上跑了一個(gè)輕量級的 HTTP 服務(wù)器用的是 NanoHTTPD大概 50KB 的 jar 包足夠處理 REST 請求。手機(jī) App 通過GET /api/sensors獲取傳感器數(shù)據(jù)通過POST /api/control下發(fā)控制指令。WebSocket 用于實(shí)時(shí)推送比如溫度變化時(shí)主動(dòng)通知 App 更新 UI。4. 完整實(shí)操流程從零搭建一個(gè)可運(yùn)行的系統(tǒng)4.1 硬件接線與檢查接線是整個(gè)過程里最容易出錯(cuò)的一步。我按照以下順序操作第一步斷開所有電源把 Raspberry Pi 3 放在桌面上確認(rèn) GPIO 引腳編號(hào)。樹莓派的 GPIO 引腳有兩套編號(hào)物理引腳號(hào)1-40和 BCM 編號(hào)。Android Things 用的是 BCM 編號(hào)所以接線的時(shí)候要看 BCM 映射圖不能看物理引腳號(hào)。第二步連接 DHT11。DHT11 有三個(gè)引腳VCC、DATA、GND。VCC 接 3.3V物理引腳 1GND 接 GND物理引腳 6DATA 接 GPIO4物理引腳 7BCM 編號(hào)是 4。注意 DHT11 的 DATA 引腳需要接一個(gè) 4.7K 到 10K 的上拉電阻到 VCC否則信號(hào)不穩(wěn)定。我一開始沒加上拉電阻讀取成功率只有 30%加上之后提升到 85%。第三步連接繼電器模塊。繼電器的 VCC 接 5V物理引腳 2GND 接 GND物理引腳 9IN 接 GPIO17物理引腳 11。繼電器的輸出端接燈具的火線零線直連。這里涉及 220V 強(qiáng)電如果你沒有電工經(jīng)驗(yàn)建議先用 LED 燈珠模擬等邏輯跑通了再接觸強(qiáng)電。安全第一。第四步上電檢查。先不插 SD 卡只接電源用萬用表測量各引腳電壓確認(rèn) 3.3V 和 5V 正常。然后斷電插上 SD 卡上電啟動(dòng)。4.2 Android Things 項(xiàng)目結(jié)構(gòu)與關(guān)鍵代碼項(xiàng)目結(jié)構(gòu)如下app/ ├── src/main/ │ ├── java/com/example/smarthome/ │ │ ├── MainActivity.java // 主入口初始化 GPIO 和 MQTT │ │ ├── SensorManager.java // 傳感器讀取邏輯 │ │ ├── DeviceController.java // 繼電器控制邏輯 │ │ ├── MqttHandler.java // MQTT 通信 │ │ └── HttpServer.java // HTTP API │ ├── res/ │ └── AndroidManifest.xmlAndroidManifest.xml里需要聲明權(quán)限和特性uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_NETWORK_STATE / uses-feature android:nameandroid.hardware.type.embedded /uses-feature這一行很關(guān)鍵它告訴系統(tǒng)這是一個(gè)嵌入式設(shè)備應(yīng)用沒有它的話Android Things 可能不會(huì)在啟動(dòng)時(shí)自動(dòng)運(yùn)行你的 App。主入口MainActivity的核心邏輯public class MainActivity extends Activity { private Gpio ledPin; private SensorManager sensorManager; private MqttHandler mqttHandler; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); PeripheralManagerService manager new PeripheralManagerService(); try { ledPin manager.openGpio(BCM17); ledPin.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW); } catch (IOException e) { Log.e(TAG, GPIO init failed, e); } sensorManager new SensorManager(manager); mqttHandler new MqttHandler(this); mqttHandler.connect(); } Override protected void onDestroy() { super.onDestroy(); if (ledPin ! null) { try { ledPin.close(); } catch (IOException e) { } } mqttHandler.disconnect(); } }傳感器讀取的定時(shí)任務(wù)用ScheduledExecutorService每 5 秒讀一次ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() - { float temp sensorManager.readTemperature(); float humidity sensorManager.readHumidity(); mqttHandler.publish(home/sensor/bedroom, String.format({\temp\:%.1f,\humidity\:%.1f}, temp, humidity)); }, 0, 5, TimeUnit.SECONDS);4.3 手機(jī) App 與中樞的聯(lián)調(diào)手機(jī) App 我用的是 Kotlin Retrofit接口定義很簡單interface SmartHomeApi { GET(/api/sensors) suspend fun getSensors(): SensorData POST(/api/control) suspend fun controlDevice(Body command: ControlCommand): ResponseUnit }聯(lián)調(diào)的時(shí)候遇到一個(gè)典型問題Android Things 的 HTTP 服務(wù)器默認(rèn)監(jiān)聽 8080 端口但手機(jī) App 用 Retrofit 請求的時(shí)候一直超時(shí)。排查后發(fā)現(xiàn)是 Android Things 的防火墻默認(rèn)只開放了 ADB 端口5555其他端口需要手動(dòng)開放。解決辦法是在adb shell里執(zhí)行adb shell iptables -A INPUT -p tcp --dport 8080 -j ACCEPT但這個(gè)命令重啟后會(huì)失效需要寫一個(gè)啟動(dòng)腳本。我把命令放到了MainActivity的onCreate里用Runtime.getRuntime().exec()執(zhí)行這樣每次 App 啟動(dòng)都會(huì)自動(dòng)開放端口。另一個(gè)問題是 JSON 解析。Android Things 上跑的是完整 Android 系統(tǒng)可以用 Gson 或 Moshi但要注意混淆規(guī)則。我在proguard-rules.pro里加了-keep class com.example.smarthome.model.** { *; }否則 Release 版本會(huì)因?yàn)榛煜龑?dǎo)致 JSON 字段名被改解析失敗。4.4 自動(dòng)化邏輯的實(shí)現(xiàn)智能家居的核心價(jià)值在于自動(dòng)化。我實(shí)現(xiàn)了幾個(gè)基礎(chǔ)規(guī)則溫度高于 28°C 自動(dòng)開風(fēng)扇繼電器 1濕度低于 40% 自動(dòng)開加濕器繼電器 2晚上 10 點(diǎn)后自動(dòng)關(guān)閉所有燈光這些規(guī)則用簡單的if-else就能實(shí)現(xiàn)但更好的方式是做一個(gè)規(guī)則引擎。我用了一個(gè)輕量級的方案把規(guī)則定義成 JSON存在 SD 卡里中樞啟動(dòng)時(shí)加載{ rules: [ { name: 高溫開風(fēng)扇, condition: {sensor: temperature, operator: , value: 28}, action: {device: fan, command: on} } ] }然后寫一個(gè)RuleEngine類每次傳感器數(shù)據(jù)更新時(shí)遍歷規(guī)則匹配到就執(zhí)行動(dòng)作。這樣做的好處是修改規(guī)則不需要重新編譯代碼直接改 JSON 文件重啟就行。5. 常見問題與排查技巧實(shí)錄5.1 系統(tǒng)啟動(dòng)失敗與 ADB 連接問題問題現(xiàn)象樹莓派上電后 HDMI 無輸出或者卡在 Android Things Logo 不動(dòng)。排查思路首先檢查電源用萬用表量一下電壓是否穩(wěn)定在 5V。如果電壓低于 4.8V系統(tǒng)會(huì)啟動(dòng)失敗。其次檢查 SD 卡Android Things 對 SD 卡的速度有要求Class 10 以上比較穩(wěn)妥。我用過一張雜牌的 Class 4 卡寫入鏡像后啟動(dòng)一直失敗換卡后正常。ADB 連接問題如果adb connect一直失敗先確認(rèn)樹莓派和電腦在同一個(gè)網(wǎng)段。然后檢查 ADB 版本Android Things 需要 ADB 1.0.39 以上。如果還是不行用adb kill-server adb start-server重啟 ADB 服務(wù)。5.2 GPIO 控制異常與電平匹配問題現(xiàn)象繼電器不吸合或者吸合后樹莓派重啟。排查思路繼電器不吸合先量 GPIO 輸出電壓如果是 3.3V 而繼電器需要 5V就需要電平轉(zhuǎn)換。吸合后重啟基本是電源功率不夠換大功率電源。另外繼電器線圈在斷電時(shí)會(huì)產(chǎn)生反向電動(dòng)勢可能干擾樹莓派建議在繼電器線圈兩端并聯(lián)一個(gè)續(xù)流二極管1N4007。5.3 傳感器讀取不穩(wěn)定問題現(xiàn)象DHT11 讀取成功率低數(shù)據(jù)偶爾為 NaN。排查思路首先檢查上拉電阻4.7K 到 10K 都可以我用的 10K。其次檢查接線長度杜邦線太長會(huì)引入干擾建議不超過 20cm。如果還是不穩(wěn)定在代碼里加重試機(jī)制for (int i 0; i 3; i) { float temp sensorManager.readTemperature(); if (!Float.isNaN(temp)) return temp; Thread.sleep(100); } return Float.NaN;5.4 MQTT 斷線重連與消息丟失問題現(xiàn)象Wi-Fi 波動(dòng)后 MQTT 連接斷開重連后收不到消息。排查思路確保setAutomaticReconnect(true)和setCleanSession(false)。cleanSession設(shè)為 false 時(shí)Broker 會(huì)保留訂閱關(guān)系和未送達(dá)的消息QoS 1 或 2。但要注意cleanSession為 false 時(shí)客戶端 ID 必須固定否則 Broker 會(huì)認(rèn)為是新客戶端。5.5 常見問題速查表問題可能原因解決方法系統(tǒng)啟動(dòng)失敗電源不足 / SD 卡速度慢換 5V 2.5A 電源 / Class 10 SD 卡ADB 連不上網(wǎng)段不同 / ADB 版本低檢查網(wǎng)絡(luò) / 升級 ADB繼電器不吸合電平不匹配換 3.3V 繼電器或加電平轉(zhuǎn)換樹莓派重啟電源功率不夠換大功率電源DHT11 讀取失敗缺上拉電阻 / 線太長加上拉電阻 / 縮短線長MQTT 斷線Wi-Fi 不穩(wěn)定開啟自動(dòng)重連 / 固定客戶端 IDHTTP 超時(shí)防火墻未開放端口iptables 開放端口JSON 解析失敗混淆規(guī)則缺失添加 keep 規(guī)則6. 系統(tǒng)擴(kuò)展與個(gè)人實(shí)操體會(huì)這套系統(tǒng)跑了大半年中間經(jīng)歷過幾次迭代。最開始只有溫濕度和燈光控制后來陸續(xù)加了人體紅外傳感器HC-SR501、門窗磁傳感器MC-38、以及一個(gè)簡單的語音控制模塊。每次加新設(shè)備核心邏輯幾乎不用改只需要在SensorManager里加一個(gè)讀取方法在RuleEngine里加一條規(guī)則。這種中樞集中決策的架構(gòu)擴(kuò)展性確實(shí)比分散式方案好很多。不過 Android Things 也有它的局限。首先是啟動(dòng)速度從通電到 App 完全就緒大概需要 40 秒比 ESP8266 的 3 秒慢太多。如果你需要快速響應(yīng)的場景比如人體感應(yīng)開燈純 Android Things 方案會(huì)有明顯的延遲。我的做法是把人體感應(yīng)這種低延遲需求放到 ESP8266 終端節(jié)點(diǎn)上本地直接觸發(fā)繼電器同時(shí)通過 MQTT 通知中樞記錄狀態(tài)。這樣既保證了響應(yīng)速度又保留了中樞的數(shù)據(jù)聚合能力。其次是成本。一塊 Raspberry Pi 3 加上電源、SD 卡、外殼整套下來接近 300 塊。如果你只是想做一兩個(gè)燈的控制用 ESP8266 方案 30 塊就能搞定。Android Things 適合的是那種需要復(fù)雜邏輯、多設(shè)備協(xié)同、且你本身有 Android 開發(fā)經(jīng)驗(yàn)的場景。如果你完全不懂 Android為了做智能家居去學(xué) Android 開發(fā)投入產(chǎn)出比可能不太劃算。最后分享一個(gè)我在調(diào)試過程中總結(jié)的小技巧Android Things 的日志可以通過adb logcat查看但默認(rèn)輸出量很大建議用標(biāo)簽過濾adb logcat -s SmartHome:V MqttHandler:V SensorManager:V這樣只看自己代碼的日志排查問題效率高很多。另外Android Things 支持遠(yuǎn)程調(diào)試你可以在 Android Studio 里直接對樹莓派上的 App 下斷點(diǎn)單步調(diào)試硬件邏輯這個(gè)體驗(yàn)比串口打印日志好太多了。我第一次用遠(yuǎn)程調(diào)試定位到 DHT11 時(shí)序問題時(shí)感覺就像在調(diào)試一個(gè)普通的 Android App完全忘了自己是在操作硬件。