基于智能家居中控屏的設備控制方案設計

DOI：10.16652/j.issn.1004-373x.2025.16.005

中圖分類號：TN929.5-34 文獻標識碼：A 文章編號：1004-373X（2025）16-0025-06

Design of device control scheme based on smart home gateway

XUEYalu’，ZHAOZuoxi1，LIAOZhifeng2，ZHENGLi

Abstract：With thedevelopmentof smarthomes，thecentralcontrol screenhasgradually becomeamust-have device for whole housesmarthomesduetoitsexcellnt interactiveexperiene，playingacentralroleincontrolandinteraction.Inodeto solvethe problemsofcomplex protocoldockingbetweethecentralcontrolscreeandhomedevices，aswellasloweffciencyin UI interactiondevelopment，adynamicloadingoptimizationschemebasedonthecontrolprotocolandinteractiveUIof the centralcontrolscreenisproposed.Inthisscheme，theobjectmodelisusedasthecentertodigitalldescribethefunction propertiesofthecontrolleddevice.Theatributecontrolinstructionofthedeviceobjectmodelandtheconversionof Zigbee wireless protocolarerealizedbymeansofLUAanalyticalscript.UIcontrolandpagelayoutdescriptionfilearedefined，the AndroidNativeandReactNativeframeworkareusedtorealizethedynamicrenderingofuserinteractioninterface.Theatribute mapingrelationship between UIcontrolandobject modelisestablished torealizetheatributechangethattheuser's click actionbehavioristransformedintotheobjectmodel，andtheZigBeecontrolinstructionisexecutedbymeansofLUAsriptto realize thepurposeofdevicecontrol.The testing resultsshowthattheproposedschemecanachievemoreeficientaccessto smart home devices and better interactive experience.

Keywords：whole house intelligence;central control screen;dynamic UI;object model device; LUAscripting language; ReactNativeframework

0 引言

21世紀初國內興起智能家居概念[，發展至今主要分為三個階段：1.0單品智能時代—一單臺設備的智能控制；2.0場景聯動時代——可以實現有限的聯動智能；2022年華為正式發布全屋智能3.0，提出全屋智能解決方案概念，進入3.0全屋智能時代2，市場逐漸擴大，其中智能中控屏的市場增長尤為迅速。

智能中控屏是全屋智能系統的核心部件[3，屬于“云邊端\"結構中的邊緣智能，在靠近子設備的邊緣側對海量數據進行本地處理4，負責設備的集中控制管理。在操作系統方面，鑒于Android系統自身的優越性，大多智能家居系統的研究設計首選基于Android系統開發APP來完成交互控制[5。Android系統本質上也是一個不錯的嵌入式軟件開發平臺，中控屏逐漸選用其作為基礎底層系統，但需要根據全屋智能應用場景進行改造。在設備通信上，通常采用智能家居行業公認較成熟的ZigBee作為中控屏與子設備之間的通信協議。但是現階段行業內仍缺乏智能設備統一的標準體系和網絡協議，需要對于屏端底層系統進行代碼開發來解析協議處理數據8，同時不同的設備也需要實現不同功能的UI交互界面。所以，對于提供全屋智能解決方案的廠商來說存在以下問題：

1）需要針對不同控制協議的設備進行開發，開發工作量與所需接入的子設備數量呈線性增長關系；

2）基于Android原生XML布局開發全部UI界面，結構樣式實現不夠靈活且代碼冗余、不易調整；

3）產品上線后需要發布整體固件包進行全網推送升級，增加了開發和測試成本，系統版本難以管理；

4）更新包體積龐大，升級過程依賴用戶的主動觸發，并需要重啟生效，用戶升級成本較高且易導致用戶版本滯后。

本文提出一種基于中控屏的控制協議和交互UI的動態加載優化方案。該方案的設計亮點在于優化中控屏對不同產品協議的快速適配和UI交互的動態加載，提升開發效率和用戶體驗。

1整體架構設計

本文優化方案整體架構圖如圖1所示。

圖1本文優化方案整體架構圖

本文優化方案的結構設計包括用戶面和技術面兩個方面。

1）用戶面：提供兩層UI交互呈現——設備快捷控制頁和設備詳情控制頁。少量高頻、必需的操作（如開關狀態）集合在前者表現，后者則提供更豐富完整的功能模塊。

2）技術面：主要分為IoT管理平臺、控制協議模塊、快捷控制模塊、詳情控制模塊等4個部分。其中：IoT管理平臺負責定義設備物模型信息、設備控制LUA腳本等；控制協議模塊通過LUA腳本解析轉換物模型指令與設備可識別控制指令，實現設備控制；快捷控制模塊通過對自定義的卡片描述文件進行解析渲染，生成設備快捷控制界面；詳情控制模塊采用組件化開發模式，定義了包含布局和控制邏輯的JS文檔，通過RN框架的橋接功能與原生代碼進行雙向通信，完成設備詳情頁渲染。

2技術面設計與實現

2.1控制協議模塊

2.1.1 設備物模型定義

首先在IoT平臺對具體接人設備進行物模型屬性（property）、事件（action）定義。屬性描述家居智能設備的基本信息、狀態屬性，例如開關狀態、溫度值參數、空調工作模式等，通過設置讀寫操作來實現對設備功能參數的修改和查詢；事件則表示設備可以進行的操作或行為，例如智能門鎖下發動態密碼、故障報警等。完成功能定義后，平臺將自動生成該產品JSON格式的物模型文件。

例如新風設備的風速檔位物模型定義如下：

在proprties對象中定義各功能屬性，其中windSpeed屬性定義了風速的低、中、高、關閉4個檔位以及其對應值，并在defaultValue對象中存儲當前設備狀態值。

2.1.2 解析腳本開發

中控屏硬件中封裝有ZigBee模塊，可以與子設備實現穩定且低功耗的無線通信[10-1]。在此基礎上通過開發LUA腳本實現統一標準的物模型協議轉換接口（如writerProperty、readProperty），從而實現物模型控制指令和具有差異化的設備ZigBee協議之間的轉換。

當用戶在交互界面進行操作時，觸發物模型值的更改，屏端調用LUA腳本將該物模型指令解析成ZigBee協議數據并發送設備可識別信號，實現功能控制；當設備端在改變狀態時，觸發ZigBee信息發送至屏端的ZigBee協調器，屏端調用LUA腳本對ZigBee信息進行解析，轉換成物模型結構數據，應用層收到數據更新會驅動UI刷新，實現中控屏同步真實設備狀態。

接人新設備時，除了原有對設備自身功能以及ZigBee通信協議的開發以外，不需要對于中控屏底層進行代碼改動并發布新版本，直接更新LUA腳本并發布至IoT平臺，通過云端推送到各中控屏端進行設備接入支持。

2.2快捷控制模塊

根據Android底層操作系統，采用Android原生技術實現設備基礎控制功能。由于設備類型多、業務操作邏輯繁雜且UI類型豐富，采用MVVM的GUI架構模式[12]將數據管理、UI繪制和邏輯控制分開。

2.2.1 定義配置文件

在ViewModel層管理界面相關數據和操作，Model層封裝可通用的設備卡片模板，繪制模板的同時，將各模板界面元素與相對應的數據綁定。最終以View的形式實現快捷控制頁，在屏端應用層與其父Fragment或父Activity保持關聯。

例如定義一個按鈕卡片模板時，先定義一個物模型文據類：

dataclassEnumButtonCardModelconstructor（ override val modelld： String， override val category： String， overrideval properties：JSONObject，

valoperateTd： String，

valswitchTd： String，

val des： String，

再根據設備實際狀態對物模型的數據類進行實例化，用于在快捷控制頁上呈現真實的設備狀態：

\"enumButton\" -gt;1

val operateTd Σ=Σ cardDes.optString（\"operateTd\"，\"\"）

valinfoModel Σ=Σ EnumButtonCardModel（ gatewayDevice.modelID， gatewayDevice.category，

JSONObject（gatewayDevice.properties.toString）， operateTd， cardDes.optString（\"switchTd\"，\"\"）， cardDes.optString（\"des\"，\"\"）， ）

1

另外，針對不同品類（category）的設備編寫頁面Config文件，用于定義具體設備UI布局以及各控件與物模型的綁定關系：

一

\"type\"：2，

\"viewType\"： \"enumButton\"，

\"operateTd\"：\"windSpeed\"，

\"switchTd\"：\"power_1\"，

\"des\"：\"風速\"

1

2.2.2設備交互UI動態繪制

將Config文件和設備icon圖像資源打包成設備卡片資源文件夾，并上傳至云服務器。屏端應用在啟動時先獲取自身綁定的設備信息，根據modeIID值從云端獲取對應型號設備的物模型描述文件。遇到\"category\"屬性時，讀出對應值，依照該值從云端下載卡片資源文件夾，如圖2所示。

在屏端進行資源文件夾解析，其中“type\"值為2表示生成 1×2 尺寸的模板頁面；再根據\"viewType\"屬性獲取并創建“enumButton\"空白模板，通過配置文件獲取該設備當前物模型的值，在空白模板進行具體渲染。

圖2快捷控制頁動態渲染流程

2.3詳情控制模塊

設備詳情頁用來展示更完整的設備功能和狀態，所需物模型數據更多、UI交互元素更豐富，需要將這部分開發與其他交互界面的開發進行解耦。同時，也需要在保證渲染效果一致的情況下，提高代碼復用率，實現彈性布局和熱更新。為了實現這些特性，采用ReactNative作為基礎框架。在此基礎上，通過自定義組件、數據驅動UI顯示的方式實現一套模板，適用于不同型號的產品。

2.3.1 封裝自定義組件

ReactNative框架提供一系列內置控件，可以直接調用，比如用于包裹其他組件進行布局，顯示文本內容，顯示圖像，顯示滾動視圖，、等是用于交互的可觸摸控件。

將高復用的部分頁面功能模塊封裝在同一個中，并定義其業務邏輯，形成獨立、可調用的自定義組件。其中復用率較高的有標題組件、開關組件、風速檔位組件等。以標題組件為例，在View中定義布局邏輯（多層View嵌套關系）和動作定義：

{this.props.devName}

{this.props.roomName}

2.3.2 編寫詳情頁面

每一款設備詳情控制頁的開發都可以直接調用已封裝好的自定義組件，提高代碼復用率，比如新風詳情頁調用標題組件和風速檔位組件：

roomName={this.props.device.roomName）

devName={this.props.device.devName}

（20 1gt; （20

（this.modelTab=c）}

model={this.properties.windSpeed} onChange={this._operateDevice} /gt;

2.3.3詳情頁面動態繪制

在整個屏端應用程序啟動時，會對RN模塊進行信息初始化，獲取所支持打開詳情頁的設備信息。進入設備詳情頁時，首先進行數據初始化，獲取最新設備狀態屬性；然后調用ViewModel中的flow，啟動異步操作加載指定詳情頁面。

中控屏端進行頁面渲染時，根據控件名稱讀取其同名JS文件，并獲取所有需要用到的物模型數據properties，再利用props和state進行層級組件之間的狀態信息傳遞、函數回調等，同樣的組件在不同的設備頁面可以展示不同行為、狀態，組件state更新時也可以觸發自動渲染界面 UI^[13] 。

比如不同型號的新風設備檔位分級不一定相同，只需將該款新風的風速物模型檔位數據windSpeed傳給控件中的model對象，渲染出符合該款設備的檔位分級，并獲得設備的真實狀態值，形成UI。

在設備控制時，組件的狀態發生變化，系統會主動回調該組件注冊的自定義處理函數。例如上述示例中針對組件的onChange方法注冊了自定義處理函數\"onChange O= {this._operateDevice]”，當新風設備切換風速時，組件狀態發生變化，_operateDevice方法會被調用，最終調用LUA腳本執行設備控制動作。

3 無感知更新

中控屏產品在出廠時內置完整APK包，包含當前版本數據的設備配置文件和bundle插件包。當業務拓展、升級時，修改后的新版本卡片資源文件包發布至IoT平臺，需將詳情操作頁面的全部前端代碼（包括

JavaScript邏輯、引用的靜態資源及第三方依賴庫）通過構建工具打包為標準化bundle文件[4]，并部署至IoT平臺。

如圖3所示，中控屏應用在啟動或定時輪詢時，會從IoT平臺獲取最新的配置文件版本，通過與本地文件的版本號進行比較得知是否需要更新本地文件，如果有更新，在下載解析新配置文件后通知GUI進行頁面刷新。用戶無需下載更新整個系統固件代碼，也不需要手動觸發屏端重啟，直接無感知更新。

圖3用戶端更新流程

4功能測試及結果分析

注：本文通訊作者為趙祚喜。

將該優化方案應用到現有智能家居中控屏系統，主要對設備控制頁面動態生成、設備有效控制及無感知更新等功能的實現進行了驗證。在新接入一款新風設備時，只需要定義物模型、編寫LUA控制腳本、頁面配置文件和編寫詳情頁面，即可實現自動生成快捷控制頁和設備詳情頁，無需發布中控屏固件就可以自動渲染生成頁面，并成功控制設備。新風設備屏端顯示狀態圖如圖4所示。

圖4新風設備屏端顯示狀態圖

將該方案應用到實際項目中，版本更新從需要手動下載的 190MB 系統整包優化成自動觸發下載更新的2MB插件包，并且開發、測試用時對比優化前的方案而言具有如表1所示改進。

表1網關開發、測試用時對比 天

5結語

本文介紹了一種基于智能家居中控屏進行設備接人和控制的優化方案設計，接人一款家居設備時只需要對于設備本身進行ZigBee協議開發，不涉及中控屏底層代碼更改，不需要發布新屏端固件包。交互界面的解耦與動態渲染可以極大地提高開發效率，且用戶在使用中控屏時不需要頻繁下載新版本和重啟就可以獲得最新的系統功能和UI呈現。

將本文設計應用在企業的實際上線項目中，極大地節省了開發、測試、市場維護的成本，優化了用戶體驗，具有一定的市場應用性，對全屋智能中控屏產品的發展具有現實意義。

參考文獻

[1]張俠丹.中國智能家居行業研究[J].未來與發展，2021，45（12）：14-19.

[2]蔣翰林.智能家居新浪潮：從智能單品到全屋智能[N].中國經營報，2022-11-14（B14）.

[3]佚名.智能家居新寵兒，中控屏有什么獨到之處？[J].世界電子元器件，2023（7）：3-7.

[4]張曉東，張朝昆，趙繼軍.邊緣智能研究進展[J].計算機研究與發展，2023，60（12）：2749-2764.

[5]李昌奇，何志琴，周恒，等.基于Android和WiFi的智能家居監控系統設計與實現[J].現代電子技術，2020，43（20）：67-70.

[6]蔣志偉，王偉，劉姍，等.基于ARM的智能家居系統的設計與實現[J].現代電子技術，2023，46（4）：177-181.

[7]姚健，劉郵政，季曦冉，等.包容性導向下的智能家居設計研究現狀與展望[J].包裝工程，2024，45（6）：1-13.

[8]劉基成，田祎然，李國鋒.基于ZigBee的嵌人式智能家居網關設計[J].電子制作，2023，31（22）：100-103.

[9]張靜，薛茹.基于JSBridge技術的跨平臺移動應用開發研究[J].信息與電腦（理論版），2021，33（6）：100-102.

[10]劉超，徐志方，王方前，等.面向智能家居的物聯網操作系統應用框架設計[J].現代電子技術，2020，43（23）：143-145.

[11]梁海潔，陳嬌英，陳延明.基于嵌入式ARM構架的智能家居控制系統設計[J].廣西大學學報（自然科學版），2021，46（1）：144-149.

[12]馬利軍.Web前端架構模式的演化及MVVM模式在 Web 前端框架中的研究[J].軟件，2023，44（7）：61-65.

[13]陳磊.一種跨平臺移動APP開發ReactNative方法的實現[J].電子技術與軟件工程，2020（10）：40-41.

[14]蘇家嘯，武永成.ReactNative技術淺析[J].中國管理信息化，2021，24（11）：192-194.

[15]雷賽楠，章文俊，李昊.基于STM32和ZigBee網絡的智能家居系統[J].電子設計工程，2023，31（7：109-112.

[16]劉正業，李震，常新峰.基于Arduino的智能家居系統的設計與實現[J].電子設計工程，2021，29（6）：29-33.

作者簡介：薛雅璐（2001—），女，湖南益陽人，碩士研究生，研究方向為智能家居控制系統。趙祚喜（1968—），男，湖南張家界人，博士研究生，教授，博士生導師，研究方向為車輛導航控制系統、計算機視覺及農業電氣化與自動化。廖志峰（1985—），男，廣東梅州人，廣東睿住智能科技有限公司軟件研發總監，研究方向為智能家居控制系統。鄭麗（2000—），女，四川自貢人，碩士研究生，研究方向為機器人、機械臂強化學習。