想清楚自己要做什么再動手這句話放在STM32智能家居項目上特別合適。很多人一提智能家居語音系統(tǒng)第一反應(yīng)就是上云、接APP、搞遠程控制其實最容易翻車的往往不是代碼而是需求沒拆解清楚。這套基于STM32的智能家居語音系統(tǒng)核心思路就一個用離線語音模塊做本地控制不依賴公網(wǎng)開口即響應(yīng)配合傳感器和執(zhí)行器完成燈光、窗簾、溫濕度檢測、報警這些家庭場景里的實際動作。全程使用STM32F103系列做主控結(jié)合CubeMX配置工程和Keil5調(diào)試環(huán)境硬件成本控制在百元左右適合正在做畢業(yè)設(shè)計、電子競賽或者單純想把手頭開發(fā)板變成能聽懂人話的家電遙控器的朋友參考。1. 項目定位先拆解智能家居語音系統(tǒng)到底在做什么開始寫代碼之前我花了整整兩天梳理需求。這一步很多人會跳過直接畫原理圖、建工程結(jié)果做到一半發(fā)現(xiàn)功能之間互相打架或者選型有硬傷返工成本極高。智能家居語音系統(tǒng)的本質(zhì)是把人的語音指令翻譯成設(shè)備能執(zhí)行的開關(guān)動作同時采集環(huán)境數(shù)據(jù)形成一套完整的閉環(huán)控制。1.1 功能清單與目標(biāo)場景我給自己定的功能范圍很明確不貪多語音控制客廳燈、臥室燈、衛(wèi)生間的排風(fēng)扇、客廳窗簾電機溫濕度實時采集溫度超過閾值自動觸發(fā)風(fēng)扇轉(zhuǎn)動人體紅外傳感器檢測到有人活動時自動點亮夜燈一鍵離家模式語音指令觸發(fā)后關(guān)閉所有燈光和排風(fēng)扇窗簾自動拉合OLED屏實時顯示當(dāng)前設(shè)備狀態(tài)和溫濕度數(shù)據(jù)這些功能聽起來多但落到執(zhí)行層本質(zhì)只有三類操作GPIO口開合控制繼電器、PWM或方向信號控制電機、I2C或模擬I2C讀取傳感器數(shù)據(jù)。把需求收斂到這個粒度之后選型就變得非常順暢了。1.2 系統(tǒng)整體架構(gòu)這套系統(tǒng)的數(shù)據(jù)流是這樣的用戶的語音 → 離線語音識別模塊 → 串口輸出識別結(jié)果幀 → STM32串口中斷接收 → 協(xié)議解析 → 狀態(tài)機跳轉(zhuǎn) → GPIO/定時器執(zhí)行動作 → 傳感器采集數(shù)據(jù)回傳 → OLED刷新顯示。整個鏈路里STM32是絕對的核心調(diào)度者。語音模塊只負責(zé)聽懂不負責(zé)決策執(zhí)行器只負責(zé)動作不負責(zé)業(yè)務(wù)邏輯。這樣的好處是每個模塊的職責(zé)單一出問題時很容易定位。即使后續(xù)要把ESP8266接進來做手機遠程控制也只需要在STM32的串口協(xié)議層增加一路數(shù)據(jù)源不需要改動執(zhí)行層邏輯。1.3 為什么選STM32當(dāng)主控而不是直接上樹莓派或ESP32這是個老生常談的問題但我還是想說清楚理由。樹莓派跑語音識別確實方便但那不是一個單片機項目而是一個Linux項目。整機成本高、啟動慢、功耗高更重要的是它不符合很多人想學(xué)習(xí)的裸機/RTOS開發(fā)路徑。ESP32自帶WiFi和藍牙做物聯(lián)網(wǎng)很香但要跑流暢的本地語音識別資源仍然緊張需要外接語音協(xié)處理芯片工程復(fù)雜度反而上去了。STM32的優(yōu)勢是生態(tài)成熟。無論是江科大教程、標(biāo)準(zhǔn)庫還是HAL庫學(xué)習(xí)資料一抓一大把遇到問題基本都能搜到答案。F103系列雖然只是Cortex-M3內(nèi)核、72MHz主頻但是跑一個語音指令解析狀態(tài)機加上傳感器輪詢綽綽有余。更關(guān)鍵的是外部中斷、定時器、串口DMA、低功耗模式這些MCU核心外設(shè)在這個項目里全都能用上學(xué)完這一套對其他單片機項目的駕馭能力會明顯提升。2. 語音識別方案選型離線模塊和在線識別的權(quán)衡語音方案是整個項目的靈魂也是我最早定下來的部分。市面上的方案看著多其實可以分成三個流派離線固定詞條模塊、離線自學(xué)習(xí)模塊、在線云端識別。我在選型時分別做了調(diào)研和實物測試結(jié)論可能和不少人的預(yù)期不太一樣。2.1 常見語音方案的橫向?qū)Ρ确桨割愋痛懋a(chǎn)品優(yōu)點缺點適合場景離線固定詞條模塊SU-03T這類低成本離線語音模塊配置簡單、響應(yīng)快、不依賴網(wǎng)絡(luò)、功耗低詞條數(shù)量有限、定制性一般智能家居本地控制、小家電語音交互離線自學(xué)習(xí)芯片方案LD3320系列可編程詞條、非特定人識別、芯片級方案環(huán)境噪聲下誤識別率偏高、需要自己處理音頻前端語音交互類DIY、對成本敏感的批量產(chǎn)品在線云端識別ESP32百度/訊飛SDK識別率高、支持自然語言、詞庫無限依賴網(wǎng)絡(luò)、延遲受帶寬影響、交互流程復(fù)雜智能音箱、需要語義理解的場景2.2 我為什么最終選了離線本地識別我一開始也想跟風(fēng)上云端識別覺得智能兩個字必須連上互聯(lián)網(wǎng)才算數(shù)。后來仔細想了智能家居的使用場景設(shè)備離線時是徹底不能用還是降級到本地控制邏輯對家人來說語音控制燈光窗簾是剛需但網(wǎng)絡(luò)不是。如果路由器一重啟全家燈都開不了這種體驗就是災(zāi)難。離線語音模塊的優(yōu)勢正好卡在這個需求上。以SU-03T為代表的一類模塊內(nèi)部集成了麥克風(fēng)陣列接口、語音增強算法和固定的詞條識別引擎我只需要通過配套的上位機配置工具把命令詞和識別ID下載進去模塊上電后就能在本地完成語音識別識別結(jié)果通過UART輸出一個固定格式的幀。整個識別鏈路不發(fā)生任何網(wǎng)絡(luò)交互從說出打開客廳燈到串口收到指令幀體感延遲不到500毫秒。而且它對環(huán)境的適應(yīng)能力比我想象中好普通家庭客廳環(huán)境下喚醒詞識別率能穩(wěn)定在95%以上。2.3 語音模塊配置中的幾個坑配置語音模塊時有幾個細節(jié)很容易踩坑。第一麥克風(fēng)的位置很講究不要把模塊放在揚聲器旁邊也不要放在繼電器模塊正上方否則聲學(xué)回聲和電磁干擾都會拉低識別率。第二命令詞的設(shè)計要有區(qū)分度打開燈和打開排風(fēng)扇這種組合問題不大但關(guān)上和關(guān)上窗簾這類短詞容易混淆建議把指令設(shè)計成動詞對象的完整短語比如語音助手關(guān)閉窗簾喚醒詞和命令詞分開誤觸發(fā)率會低很多。第三串口波特率默認一般是9600或115200很多人在STM32端設(shè)置完波特率后忘記在模塊端確認實際配置導(dǎo)致收不到數(shù)據(jù)這個低級錯誤我親眼見過不少次。3. 硬件電路設(shè)計主控選型、電源隔離和接口分配硬件是整個系統(tǒng)里最容易出玄學(xué)問題的部分。很多人在開發(fā)板上跑得好好的程序一焊到自制PCB上就各種復(fù)位、亂碼、誤觸發(fā)十有八九是電源和IO分配沒設(shè)計好。我把自己的硬件設(shè)計思路和分配表完整列出來盡量讓后來人少走彎路。3.1 主控選型與最小系統(tǒng)的考慮主控我選的是STM32F103C8T6原因很簡單性價比極高、64KB Flash、20KB RAM跑這套邏輯完全夠用LQFP48封裝手工焊接不算太難板子便宜燒壞了不心疼。如果你手里的板子是多引腳的大封裝比如STM32F103RCT6或ZET6也完全能跑只是IO分配上可以更寬松。最小系統(tǒng)的設(shè)計要留意幾點。晶振我用了8MHz無源晶振配合兩個20pF負載電容復(fù)位電路用10kΩ上拉電阻加100nF電容BOOT0和BOOT1都必須接10kΩ下拉到地確保從主Flash啟動。最關(guān)鍵的是CubeMX配置工程的時候SYS這一項里必須把Debug選項選為Serial Wire對應(yīng)PA13/PA14兩個引腳作為SWD調(diào)試口。我見過太多人在這里默認選了No Debug程序下載一次后第二次就提示找不到芯片不得不按住復(fù)位鍵搶下載非常狼狽。3.2 傳感器、執(zhí)行器與語音模塊的接口方案執(zhí)行器部分燈光和排風(fēng)扇通過繼電器控制繼電器模塊選用低電平觸發(fā)的光耦隔離型避免線圈反電動勢順著IO口倒灌進MCU。窗簾電機是直流減速電機需要正反轉(zhuǎn)控制我用了一個雙路繼電器模塊常開端和常閉端的組合接線實現(xiàn)電機的正轉(zhuǎn)和反轉(zhuǎn)。電機供電單獨從5V電源走不要和MCU的3.3V共用一條電源軌。傳感器部分溫濕度傳感器用DHT11雖然精度一般但勝在便宜、時序簡單人體紅外模塊用HC-SR501靈敏度旋鈕調(diào)到中等位置延時旋鈕調(diào)到最小讓它只輸出一次高電平而不是長時間維持。OLED屏用0.96寸I2C接口的SSD1306占用兩個GPIO就能完成顯示刷新率足夠展示設(shè)備狀態(tài)。語音模塊通過串口與STM32連接。要注意語音模塊通常是3.3V電平如果你的語音模塊是5V供電需要確保它的TX輸出電平不高于3.3V否則必須用電阻分壓或電平轉(zhuǎn)換芯片。ESP8266作為可選擴展模塊我預(yù)留了一個USART3接口方便后續(xù)接入MQTT做手機遠程控制。3.3 IO口分配完整表格功能引腳模式備注語音模塊RXPA2復(fù)用推挽輸出USART2_TX語音模塊TXPA3浮空輸入USART2_RX調(diào)試串口TXPA9復(fù)用推挽輸出USART1_TX接USB轉(zhuǎn)TTL調(diào)試串口RXPA10浮空輸入USART1_RXESP8266 TXPB10浮空輸入USART3_RX預(yù)留ESP8266 RXPB11復(fù)用推挽輸出USART3_TX預(yù)留繼電器1-客廳燈PB0推挽輸出低電平觸發(fā)繼電器2-臥室燈PB1推挽輸出低電平觸發(fā)繼電器3-排風(fēng)扇PB3推挽輸出低電平觸發(fā)窗簾正轉(zhuǎn)繼電器PB4推挽輸出與PB5互鎖窗簾反轉(zhuǎn)繼電器PB5推挽輸出與PB4互鎖DHT11數(shù)據(jù)PB12開漏輸出/輸入需外接4.7kΩ上拉HC-SR501輸出PB13浮空輸入人體紅外OLED SCLPB6復(fù)用開漏I2C1_SCLOLED SDAPB7復(fù)用開漏I2C1_SDA本地按鍵PB14下拉輸入備用控制LED狀態(tài)燈PC13推挽輸出板載LED這個分配表的核心思路是慢速外設(shè)按鍵、傳感器放在低速引腳區(qū)域串口分散開避免互相干擾電機控制引腳集中到同一組端口方便統(tǒng)一管理。還有一個容易被忽略的點PB3和PB4默認是JTAG復(fù)用引腳需要在CubeMX的GPIO設(shè)置里確認已經(jīng)禁用JTAG功能只保留SWD否則這兩個引腳無法正常輸出高電平控制電機。3.4 電源和隔離設(shè)計經(jīng)驗電源是整個硬件設(shè)計里最考驗經(jīng)驗的地方。我自己的系統(tǒng)供電方案是220V交流通過5V電源模塊降壓成5V5V經(jīng)過AMS1117-3.3穩(wěn)壓后給MCU、OLED、語音模塊供電。繼電器的線圈和電機驅(qū)動直接用5V這樣大電流設(shè)備和小信號電路之間至少隔了一級LDO。關(guān)鍵來了5V電源模塊的輸出端必須放置一個大容量電解電容470μF以上并聯(lián)一個0.1μF瓷片電容。原因很簡單繼電器吸合瞬間電流尖峰很大如果電源輸出阻抗高電壓會瞬間跌落MCU檢測到欠壓直接復(fù)位。繼電器線圈兩端務(wù)必并聯(lián)續(xù)流二極管1N4007方向是反向并聯(lián)否則線圈斷電瞬間產(chǎn)生的反向電動勢可能擊穿驅(qū)動三極管或光耦內(nèi)部的光敏管。我最初調(diào)試時偷懶沒加續(xù)流二極管繼電器每動作一次STM32就重啟一次后來用示波器一測3.3V電源線上出現(xiàn)了將近6V的尖峰加了續(xù)流二極管和電容之后徹底解決。4. 軟件框架與核心邏輯狀態(tài)機怎么寫才不會亂硬件就位之后軟件的架構(gòu)設(shè)計決定了后續(xù)開發(fā)是順風(fēng)順?biāo)€是天天打補丁。這套系統(tǒng)涉及串口中斷接收、語音幀解析、外設(shè)控制、傳感器輪詢、OLED刷新多個任務(wù)雖然任務(wù)不算重但如果全部堆在while(1)里用延時函數(shù)串聯(lián)系統(tǒng)響應(yīng)會被嚴重拖累語音指令發(fā)出后要等傳感器采集完才能處理體感非?？?。我的方案是主循環(huán)狀態(tài)機串口中斷收幀定時器節(jié)拍三層架構(gòu)。4.1 CubeMX工程配置的要點工程初始化用STM32CubeMX生成HAL庫版本選1.8.0以上芯片型號選STM32F103C8Tx。RCC設(shè)置里HSE選擇Crystal/Ceramic Resonator這樣外部8MHz晶振才會被啟用Clock Configuration里把PLL Source選為HSE倍頻系數(shù)設(shè)為9得到72MHz主頻。SYS選項里Debug選Serial Wire時基源TIM1保留默認。USART1和USART2都配置為異步模式波特率統(tǒng)一1152008位數(shù)據(jù)位、1位停止位、無校驗。USART2需要開啟全局中斷因為語音模塊的數(shù)據(jù)幀是隨機到達的必須靠中斷接收。GPIO配置按照上面的分配表逐項設(shè)置DHT11的數(shù)據(jù)引腳要配置為開漏輸出模式。I2C1配置為標(biāo)準(zhǔn)模式100kHz即可OLED對速度不敏感。生成代碼后還要檢查一下是不是真的配置對了重點看main函數(shù)里SystemClock_Config的正確性以及MX_GPIO_Init里有沒有把PB3/PB4正確復(fù)位為普通輸出口。很多人在這個環(huán)節(jié)圖省事去手寫寄存器其實完全沒必要CubeMX生成的代碼雖然啰嗦但穩(wěn)定性比手寫高得多。4.2 主循環(huán)里的五態(tài)狀態(tài)機狀態(tài)機不是炫技它解決的核心問題是一個時間點系統(tǒng)只能做一件事。我用了一個非常樸素的五狀態(tài)模型typedef enum { ST_IDLE 0, // 空閑態(tài)等待語音指令 ST_RECV, // 接收態(tài)串口DMA/中斷收幀完成 ST_PARSE, // 解析態(tài)校驗幀頭幀尾和CRC ST_EXEC, // 執(zhí)行態(tài)根據(jù)命令碼操作外設(shè) ST_FEEDBACK // 反饋態(tài)刷新OLED、串口回顯狀態(tài) } sys_state_t;主循環(huán)的偽代碼是while (1) { switch (current_state) { case ST_IDLE: if (voice_frame_flag 1) { current_state ST_RECV; } else { sensor_timer_handler(); // 定時采集傳感器 } break; case ST_RECV: memcpy(rx_buf, voice_rx_buf, voice_rx_len); voice_frame_flag 0; current_state ST_PARSE; break; case ST_PARSE: if (frame_verify(rx_buf, cmd)) SUCCESS) { current_state ST_EXEC; } else { current_state ST_ERROR; } break; case ST_EXEC: exec_cmd(cmd); current_state ST_FEEDBACK; break; case ST_FEEDBACK: oled_update(); printf(CMD:%d\r\n, cmd); current_state ST_IDLE; break; default: current_state ST_IDLE; break; } }這種寫法最大的優(yōu)勢是每個狀態(tài)的代碼塊非常獨立調(diào)試時我甚至可以在ST_PARSE階段加一個斷點單步看接收到的原始幀數(shù)據(jù)定位問題非?？?。而傳感器采集不占用主循環(huán)的固定周期而是放在定時器中斷的回調(diào)里每500ms采集一次并更新全局變量。4.3 命令解析與執(zhí)行映射語音模塊識別出的指令幀經(jīng)過校驗后得到一個合理的命令碼。我維護了一個簡單的函數(shù)指針數(shù)組把命令碼映射到實際執(zhí)行函數(shù)void (*cmd_table[])(void) { cmd_light_on, cmd_light_off, cmd_fan_on, cmd_fan_off, cmd_curtain_open, cmd_curtain_close, cmd_all_off };這種映射表的好處是后續(xù)增加新設(shè)備時不需要改動主循環(huán)和狀態(tài)機只需要在語音配置工具里增加詞條、在協(xié)議解析里增加命令碼、在數(shù)組里掛一個執(zhí)行函數(shù)三處改動即可完成擴展。實際測試中從語音識別輸出到執(zhí)行函數(shù)跑完整個過程在毫秒級別體感就是話音剛落燈就亮了。5. 模塊間通信協(xié)議讓語音、WiFi、執(zhí)行器說同一種話系統(tǒng)里不止STM32一個活物語音模塊會輸出識別結(jié)果ESP8266會轉(zhuǎn)發(fā)手機指令DHT11會返回溫濕度數(shù)據(jù)如果每個模塊都按自己的私有格式來協(xié)議解析代碼會變成一團亂麻。我在項目一開始就定義了一套統(tǒng)一的內(nèi)部通信協(xié)議所有模塊的數(shù)據(jù)都封裝成同一種幀結(jié)構(gòu)解析代碼寫一次到處復(fù)用。5.1 自定義幀格式幀格式參考了MODBUS的簡潔思路設(shè)計如下字節(jié)位置字段名長度說明0幀頭11字節(jié)固定0xA51幀頭21字節(jié)固定0x5A2數(shù)據(jù)長度LEN1字節(jié)從命令字到CRC前一個字節(jié)的長度3命令字CMD1字節(jié)0x01燈光開、0x02燈光關(guān)、0x03排風(fēng)扇開、0x04排風(fēng)扇關(guān)、0x05窗簾開、0x06窗簾關(guān)、0x07離家模式4~4LEN-2數(shù)據(jù)區(qū)DATA0~8字節(jié)可攜帶溫度、濕度等參數(shù)末字節(jié)CRC81字節(jié)從幀頭2開始到數(shù)據(jù)區(qū)末尾的異或校驗舉個例子燈光開的完整指令幀是A5 5A 01 01 5F。其中0x5F是前面字節(jié)的異或結(jié)果這一幀只有命令字沒有數(shù)據(jù)區(qū)。窗簾控制需要指定方向我直接設(shè)計在命令字里不額外加數(shù)據(jù)位。如果以后要控制空調(diào)溫度就可以在數(shù)據(jù)區(qū)填上目標(biāo)溫度解析函數(shù)里留一個判斷。5.2 語音識別結(jié)果到命令字的映射語音模塊輸出的幀格式跟這個自定義協(xié)議不一樣所以就存在一個翻譯的過程。我的做法是在STM32的解析層維護一張映射表把語音模塊的識別ID翻譯成內(nèi)部命令字。這張表的位置固定在一個獨立文件中方便調(diào)整語音指令詞語音模塊識別ID內(nèi)部命令字打開客廳燈0x0A0x01關(guān)閉客廳燈0x0B0x02打開排風(fēng)扇0x0C0x03關(guān)閉排風(fēng)扇0x0D0x04打開窗簾0x0E0x05關(guān)閉窗簾0x0F0x06離家模式0x100x07不要小看這一層映射它把語音識別模塊制造商定義的格式和STM32內(nèi)部業(yè)務(wù)邏輯徹底解耦了。以后如果我覺得某個語音模塊識別率不行換一個品牌只需要修改這個映射表對應(yīng)的協(xié)議解析部分執(zhí)行層一個字節(jié)都不用動。5.3 數(shù)據(jù)流鏈路與超時重傳的考慮語音模塊串口數(shù)據(jù)到達STM32之后全部通過USART2中斷接收。我在中斷回調(diào)里做幀緩存當(dāng)一個完整幀接收完成后置一個標(biāo)志位通知主循環(huán)取走數(shù)據(jù)。這里有一個細節(jié)幀頭0xA5 0x5A可能在噪聲環(huán)境中被誤收所以我要求收到的前兩個字節(jié)必須嚴格按照順序匹配如果第一個字節(jié)不是0xA5直接丟棄如果是0xA5但第二個字節(jié)不是0x5A同樣丟棄并要求重新同步。同時主循環(huán)里設(shè)置了超時機制如果超過200ms沒有收到語音模塊的完整幀就自動回到空閑態(tài)避免因為接收一半卡死。WiFi模塊的通信也復(fù)用這套幀協(xié)議只是傳輸通道變成了網(wǎng)絡(luò)。ESP8266通過訂閱MQTT主題收到手機APP發(fā)來的指令然后通過串口轉(zhuǎn)發(fā)出同樣的幀結(jié)構(gòu)。這樣一來STM32端完全不需要區(qū)分指令是來自語音模塊還是來自手機協(xié)議的統(tǒng)一性讓擴展變得極其輕松。6. 調(diào)試排障實錄從亂碼到繼電器誤復(fù)位再完美的設(shè)計也繞不過調(diào)試。我在這個項目里踩的坑不算少挑三個最有代表性的問題完整復(fù)盤這些問題基本覆蓋了嵌入式聯(lián)調(diào)階段的經(jīng)典故障類型。6.1 排查亂碼電平與波特率的雙重陷阱第一次把語音模塊和STM32連接起來打開串口調(diào)試助手屏幕上全是亂碼。我第一反應(yīng)是波特率不一致把波特率從9600到115200挨個試了一遍亂碼依舊。這時候我開始懷疑硬件連接用萬用表量了語音模塊TX引腳的靜態(tài)電平發(fā)現(xiàn)空閑電平是5V而STM32的PA3引腳是3.3V容忍極限。問題找到了語音模塊是5V供電它的UART輸出高電平也是5V直接懟到3.3V的引腳上電平邏輯雖然勉強能識別但上升沿和下降沿的整形效果很差數(shù)據(jù)位采樣不穩(wěn)定。解決辦法是把語音模塊改為3.3V供電。如果模塊不支持3.3V就必須在TX線上串一個1kΩ電阻再加一個3.3V穩(wěn)壓管做電平鉗位或者用一片MAX3232做電平轉(zhuǎn)換。改完供電后串口輸出立即恢復(fù)正常。這個坑給了一個很深的教訓(xùn)串口亂碼的第一排查順序不是波特率而是電平匹配。6.2 繼電器動作導(dǎo)致STM32重啟電源問題的經(jīng)典場景程序邏輯全部調(diào)通語音一喊打開燈光繼電器啪嗒一聲吸合緊接著OLED熄滅、串口停止輸出STM32直接重啟了。我用示波器去抓3.3V電源軌繼電器吸合瞬間電壓下跌到了2.2V左右持續(xù)接近100ms足夠讓MCU觸發(fā)掉電復(fù)位。根因有兩層。第一層5V電源模塊的輸出能力不足以支撐繼電器線圈和MCU同時工作的瞬態(tài)電流繼電器線圈吸合瞬間需要較大的沖擊電流。第二層繼電器線圈沒有續(xù)流二極管斷電瞬間產(chǎn)生的反電動勢在電源線上形成高壓尖峰。處理方式繼電器模塊換成帶光耦隔離和續(xù)流二極管的版本5V電源輸出端并聯(lián)470μF電解電容另外給繼電器驅(qū)動單獨加一個100μF電容做儲能緩沖。經(jīng)過這三項整改繼電器吸合時3.3V電源軌的電壓跌落控制在了0.2V以內(nèi)。6.3 語音誤觸發(fā)的真實原因系統(tǒng)穩(wěn)定運行后遇到了一個讓人哭笑不得的問題有時候電視里有人說話語音模塊會被喚醒然后執(zhí)行了錯誤指令客廳燈光莫名其妙被打開。一開始我懷疑識別引擎太靈敏把靈敏度調(diào)到最低還是有概率誤觸發(fā)。仔細回看語音模塊的配置發(fā)現(xiàn)問題出在喚醒詞我設(shè)置得太短只有你好助手四個字這兩個詞的音節(jié)組合在很多電視對白中都會出現(xiàn)。解決辦法是把喚醒詞改成長詞比如我的智能管家同時在命令詞設(shè)計上增加條件限定比如小管家打開客廳燈最后一個詞燈必須跟在客廳后面被識別到才算有效。經(jīng)過調(diào)整一周測試下來誤觸發(fā)次數(shù)降到了零。6.4 聯(lián)調(diào)排障的復(fù)盤建議排障過程給我最大的經(jīng)驗是不要一上來就在完整系統(tǒng)里找問題一定先做模塊級測試。我的實測流程是先單獨驗證電源模塊輸出再接MCU跑一個閃燈程序然后單獨接語音模塊用USB轉(zhuǎn)TTL在電腦上看串口輸出是否正常再把語音模塊接到STM32上用printf回顯收到的原始幀最后才接繼電器和電機進行全系統(tǒng)聯(lián)調(diào)。每一步都有明確的驗證標(biāo)準(zhǔn)哪一步出了問題范圍已經(jīng)被壓縮得很小了。7. 整機實測效果與下一步擴展完整聯(lián)調(diào)通過之后我把這套系統(tǒng)跑了一個星期記錄了大量真實數(shù)據(jù)。語音識別方面正常家庭環(huán)境有一點電視聲音有一點點廚房噪聲下命令識別準(zhǔn)確率實測在92%到97%之間從說出指令到繼電器動作的響應(yīng)時間集中在1.2到1.8秒連續(xù)一周沒發(fā)生一次誤觸發(fā)。執(zhí)行器方面繼電器帶載60W的LED燈泡、85W的排風(fēng)扇完全沒問題連續(xù)開關(guān)500次沒有一次失靈。溫濕度采集部分DHT11讀數(shù)在室內(nèi)環(huán)境和空調(diào)房之間的切換響應(yīng)速度大約需要一分鐘和常見智能家居設(shè)備的表現(xiàn)持平。系統(tǒng)待機功耗維持在0.8W左右全部設(shè)備激活時峰值功耗約2W不含繼電器帶載這也意味著用一個小功率電源模塊就能長期供電。如果你不想讓語音模塊一直處于監(jiān)聽狀態(tài)可以進一步優(yōu)化低功耗模式讓STM32和語音模塊進入睡眠通過語音模塊的GPIO喚醒引腳把系統(tǒng)叫醒這樣待機功耗能壓到0.1W以下。擴展方向上我目前預(yù)留了ESP8266接口和協(xié)議層后續(xù)計劃接入Home Assistant這類開源智能家居平臺把語音控制、手機APP控制、傳感器聯(lián)動全部統(tǒng)一到一個生態(tài)里。另一個值得嘗試的方向是給窗簾電機加電流檢測判斷窗簾是否已經(jīng)拉到底或者堵轉(zhuǎn)防止繼電器一直通電燒毀電機。如果你跟著做下來在基礎(chǔ)功能跑通之后可以優(yōu)先從這兩個方向挑一個深入它們對理解整個物聯(lián)網(wǎng)體系都很有幫助。最后再分享一個小技巧整個項目的日志系統(tǒng)從一開始就要留著。我在每個關(guān)鍵節(jié)點都加了串口打印雖然平時看起來有點吵但出了問題之后日志能幫你直接定位到是語音模塊沒識別、還是協(xié)議解析失敗、還是繼電器沒吸合。這個習(xí)慣幫我省下了至少一半的調(diào)試時間強烈建議從一開始就養(yǎng)成。