上一章講到如何將程式寫入到ESP8266 WiFi模塊中，實現物聯網終端對硬體的控制。本章將通過fubuki-iot實現自定義硬體控制。同時給出一個替代百度API的方案。

硬體準備

（無）

自定義語義模型

返回功能設備模型

在第一章的“提醒事項”的例子中，fubuki-iot就展現了語義模型的功能。它將命中語義模型的命令作為參數調用給定的函數，並重定向給ACOUSTICS，從而實現和用戶交互的功能。以此類推，要實現和硬體交互就只需要重定向給MESSAGE，通過MQTT消息實現硬體的操控。

拿智能洗衣機舉例，假設洗衣機有以下幾個功能：

• 以快洗/漂洗/脫水模式啟動洗衣機
• 預約X分鐘後啟動洗衣機
• 取消預約
• 暫停洗衣機
• 重新啟動洗衣機

這五個功能就會對應五個語義模型。現在拿第一個語義模型舉例，首先在mods內新建一個python文件命名為washing_machine.py，並構建一個語義模型類：

@SemanticsGroup.add_model
class WashingMachineSemanticModel(SemanticsModel):
    code = 'washing_machine'
    frm = SemanticsFromEnum.USER
    topic = ''
    regex = '以(.*)模式啟動洗衣機'
    regex_num = 2
    redirect = SemanticsRedirectEnum.MESSAGE
    func: SemanticsFunc = washing_machine_semanticsss_func

這個模型前三項和之前一樣，正則表達式這次只有一個分組用來確定模式，所以分組數就是2（加上第0個分組，即全文）。然後這次重定向就是消息。處理函數需要返回一個FunctionDeviceModel，函數類似這樣：

def washing_machine_semanticsss_func(*args) -> FunctionDeviceModel:
    mode = args[1]
    # do something here
    return FunctionDeviceModel(
        smt_code='washing_machine',
        topic='wm/mode',
        is_raw=False,
        acoustics=f"好的，洗衣機將會以{mode}模式啟動",
        data={
            'mode': ''
        }

    )

中間處理過程忽略，關鍵在於這個返回值。這次topic欄位必填，表示發送MQTT消息的topic，因為發送的payload是一個JSON數據，所以is_raw為False。這裡的acoustics是返回給用戶的語音提醒，data即payload數據，實際情況會複雜一點。

返回統一推送模型

在上一章，fubuki-iot展示了硬體主動推送消息的方式。當按下按鈕後，智能終端可以通知用戶有人按下了按鈕。直接拿內置的例子舉例：

def button_semantics_model_func(*args) -> UniverseNoticeModel:
    return UniverseNoticeModel(
        smt_code='default05', # 對應語義模型標識
        topic='self/button', # 對應的Topic，可不填
        device='button', # 對應的設備，可不填
        verbose=False, # 是否是詳細內容，如果填False則message為字元串，否則data為字典
        message="有人按下了按鈕" # 當verbose為False必填，為直接返回給用戶的語音信息
    )


@SemanticsGroup.add_model
class ButtonSemanticsModel(SemanticsModel):
    code = "default05" 
    frm = SemanticsFromEnum.DEVICE # 這次是來自設備
    topic = 'self/button' # 必填，用來匹配設備的發送的MQTT消息的Topic
    regex: Optional[str] = None
    regex_num: Optional[str] = None
    redirect = SemanticsRedirectEnum.ACOUSTICS
    func: SemanticsFunc = button_semantics_model_func

流程是這樣的，設備發出了MQTT消息包含Topic和Payload，fubuki-iot根據Topic找到對應的語義模型，並調用對應的func: SemanticsFunc語義函數處理，而Payload就作為func: SemanticsFunc的參數。和之前不同的是，這個語義函數是返回統一推送模型的，它的格式如上所示。

另外，除了重定向給Acoustics和MESSAGE還可以重定向給語義處理SEMANTICS，所以verbose欄位可能為True，這部分功能以後會提到。

自定義語音處理模塊

在前面的例子中，我們都是利用百度API實現語音識別和語音合成的，這次我們將其替換成PocketSphinx。根據官方文檔，可以直接構造一個AudioFile並遍歷其中的文字信息，即可獲得語音識別結果。

首先，需要構造一個類繼承AsrProcessor，並實現其中的asr方法。然後在通過工廠類將該類包含進去，比如：

@AsrProcessorFactory.set
class PocketSphinxAsrProcessor(AsrProcessor):
    def asr(self, path: str) -> Optional[str]:
        res = ''
        for word in pocketsphinx.AudioFile(audio_file=path):
            res += word.__str__()
        return res if res != '' else None

在這個方法中就是通過遍歷AudioFile獲取語音識別信息並返回。最後，在.env文件中表明調用這個類:

ASR_PROCESSOR=PocketSphinxAsrProcessor

註意：預設的PocketSphinx只支持英文識別，你可以在這裡找到不同語音的模型。並替換預設的模型。然後以參數的形式傳給AudioFile，比如:

for word in pocketsphinx.AudioFile(audio_file=path,
                                    hmm=os.path.join(model_path, 'zh-cn'),
                                    lm=os.path.join(model_path, 'zh-cn.lm.bin'),
                                    dict=os.path.join(model_path, 'cmudict-zh-cn.dict')):
            res += word.__str__()

除了ASR_PROCESSOR語音識別模塊以外，還有三個模型可供自定義替換，替換方法如下

到本章為止關於fubuki-iot的相關功能大致介紹完了，理論上講也確實能滿足一個基本的物聯網智能終端（智能音箱）的功能。但是這個項目除了拿去做科創競賽或者畢業設計似乎用處不大，因為它不能和現實生活中家居打通，下一章將介紹一種抓包家用路由數據的方法探索用戶對智能家居的控制。