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世紀初國內(nèi)興起智能家居概念[,發(fā)展至今主要分為三個階段:1.0單品智能時代—一單臺設(shè)備的智能控制;2.0場景聯(lián)動時代——可以實現(xiàn)有限的聯(lián)動智能;2022年華為正式發(fā)布全屋智能3.0,提出全屋智能解決方案概念,進入3.0全屋智能時代2,市場逐漸擴大,其中智能中控屏的市場增長尤為迅速。
智能中控屏是全屋智能系統(tǒng)的核心部件[3,屬于“云邊端\"結(jié)構(gòu)中的邊緣智能,在靠近子設(shè)備的邊緣側(cè)對海量數(shù)據(jù)進行本地處理4,負責設(shè)備的集中控制管理。在操作系統(tǒng)方面,鑒于Android系統(tǒng)自身的優(yōu)越性,大多智能家居系統(tǒng)的研究設(shè)計首選基于Android系統(tǒng)開發(fā)APP來完成交互控制[5。Android系統(tǒng)本質(zhì)上也是一個不錯的嵌入式軟件開發(fā)平臺,中控屏逐漸選用其作為基礎(chǔ)底層系統(tǒng),但需要根據(jù)全屋智能應(yīng)用場景進行改造。在設(shè)備通信上,通常采用智能家居行業(yè)公認較成熟的ZigBee作為中控屏與子設(shè)備之間的通信協(xié)議。但是現(xiàn)階段行業(yè)內(nèi)仍缺乏智能設(shè)備統(tǒng)一的標準體系和網(wǎng)絡(luò)協(xié)議,需要對于屏端底層系統(tǒng)進行代碼開發(fā)來解析協(xié)議處理數(shù)據(jù)8,同時不同的設(shè)備也需要實現(xiàn)不同功能的UI交互界面。所以,對于提供全屋智能解決方案的廠商來說存在以下問題:
1)需要針對不同控制協(xié)議的設(shè)備進行開發(fā),開發(fā)工作量與所需接入的子設(shè)備數(shù)量呈線性增長關(guān)系;
2)基于Android原生XML布局開發(fā)全部UI界面,結(jié)構(gòu)樣式實現(xiàn)不夠靈活且代碼冗余、不易調(diào)整;
3)產(chǎn)品上線后需要發(fā)布整體固件包進行全網(wǎng)推送升級,增加了開發(fā)和測試成本,系統(tǒng)版本難以管理;
4)更新包體積龐大,升級過程依賴用戶的主動觸發(fā),并需要重啟生效,用戶升級成本較高且易導致用戶版本滯后。
本文提出一種基于中控屏的控制協(xié)議和交互UI的動態(tài)加載優(yōu)化方案。該方案的設(shè)計亮點在于優(yōu)化中控屏對不同產(chǎn)品協(xié)議的快速適配和UI交互的動態(tài)加載,提升開發(fā)效率和用戶體驗。
1整體架構(gòu)設(shè)計
本文優(yōu)化方案整體架構(gòu)圖如圖1所示。
圖1本文優(yōu)化方案整體架構(gòu)圖

本文優(yōu)化方案的結(jié)構(gòu)設(shè)計包括用戶面和技術(shù)面兩個方面。
1)用戶面:提供兩層UI交互呈現(xiàn)——設(shè)備快捷控制頁和設(shè)備詳情控制頁。少量高頻、必需的操作(如開關(guān)狀態(tài))集合在前者表現(xiàn),后者則提供更豐富完整的功能模塊。
2)技術(shù)面:主要分為IoT管理平臺、控制協(xié)議模塊、快捷控制模塊、詳情控制模塊等4個部分。其中:IoT管理平臺負責定義設(shè)備物模型信息、設(shè)備控制LUA腳本等;控制協(xié)議模塊通過LUA腳本解析轉(zhuǎn)換物模型指令與設(shè)備可識別控制指令,實現(xiàn)設(shè)備控制;快捷控制模塊通過對自定義的卡片描述文件進行解析渲染,生成設(shè)備快捷控制界面;詳情控制模塊采用組件化開發(fā)模式,定義了包含布局和控制邏輯的JS文檔,通過RN框架的橋接功能與原生代碼進行雙向通信,完成設(shè)備詳情頁渲染。
2技術(shù)面設(shè)計與實現(xiàn)
2.1控制協(xié)議模塊
2.1.1 設(shè)備物模型定義
首先在IoT平臺對具體接人設(shè)備進行物模型屬性(property)、事件(action)定義。屬性描述家居智能設(shè)備的基本信息、狀態(tài)屬性,例如開關(guān)狀態(tài)、溫度值參數(shù)、空調(diào)工作模式等,通過設(shè)置讀寫操作來實現(xiàn)對設(shè)備功能參數(shù)的修改和查詢;事件則表示設(shè)備可以進行的操作或行為,例如智能門鎖下發(fā)動態(tài)密碼、故障報警等。完成功能定義后,平臺將自動生成該產(chǎn)品JSON格式的物模型文件。
例如新風設(shè)備的風速檔位物模型定義如下:
在proprties對象中定義各功能屬性,其中windSpeed屬性定義了風速的低、中、高、關(guān)閉4個檔位以及其對應(yīng)值,并在defaultValue對象中存儲當前設(shè)備狀態(tài)值。
2.1.2 解析腳本開發(fā)
中控屏硬件中封裝有ZigBee模塊,可以與子設(shè)備實現(xiàn)穩(wěn)定且低功耗的無線通信[10-1]。在此基礎(chǔ)上通過開發(fā)LUA腳本實現(xiàn)統(tǒng)一標準的物模型協(xié)議轉(zhuǎn)換接口(如writerProperty、readProperty),從而實現(xiàn)物模型控制指令和具有差異化的設(shè)備ZigBee協(xié)議之間的轉(zhuǎn)換。
當用戶在交互界面進行操作時,觸發(fā)物模型值的更改,屏端調(diào)用LUA腳本將該物模型指令解析成ZigBee協(xié)議數(shù)據(jù)并發(fā)送設(shè)備可識別信號,實現(xiàn)功能控制;當設(shè)備端在改變狀態(tài)時,觸發(fā)ZigBee信息發(fā)送至屏端的ZigBee協(xié)調(diào)器,屏端調(diào)用LUA腳本對ZigBee信息進行解析,轉(zhuǎn)換成物模型結(jié)構(gòu)數(shù)據(jù),應(yīng)用層收到數(shù)據(jù)更新會驅(qū)動UI刷新,實現(xiàn)中控屏同步真實設(shè)備狀態(tài)。
接人新設(shè)備時,除了原有對設(shè)備自身功能以及ZigBee通信協(xié)議的開發(fā)以外,不需要對于中控屏底層進行代碼改動并發(fā)布新版本,直接更新LUA腳本并發(fā)布至IoT平臺,通過云端推送到各中控屏端進行設(shè)備接入支持。
2.2快捷控制模塊
根據(jù)Android底層操作系統(tǒng),采用Android原生技術(shù)實現(xiàn)設(shè)備基礎(chǔ)控制功能。由于設(shè)備類型多、業(yè)務(wù)操作邏輯繁雜且UI類型豐富,采用MVVM的GUI架構(gòu)模式[12]將數(shù)據(jù)管理、UI繪制和邏輯控制分開。
2.2.1 定義配置文件
在ViewModel層管理界面相關(guān)數(shù)據(jù)和操作,Model層封裝可通用的設(shè)備卡片模板,繪制模板的同時,將各模板界面元素與相對應(yīng)的數(shù)據(jù)綁定。最終以View的形式實現(xiàn)快捷控制頁,在屏端應(yīng)用層與其父Fragment或父Activity保持關(guān)聯(lián)。
例如定義一個按鈕卡片模板時,先定義一個物模型文據(jù)類:
dataclassEnumButtonCardModelconstructor( override val modelld: String, override val category: String, overrideval properties:JSONObject,
valoperateTd: String,
valswitchTd: String,
val des: String,
再根據(jù)設(shè)備實際狀態(tài)對物模型的數(shù)據(jù)類進行實例化,用于在快捷控制頁上呈現(xiàn)真實的設(shè)備狀態(tài):
\"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)的設(shè)備編寫頁面Config文件,用于定義具體設(shè)備UI布局以及各控件與物模型的綁定關(guān)系:
一
\"type\":2,
\"viewType\": \"enumButton\",
\"operateTd\":\"windSpeed\",
\"switchTd\":\"power_1\",
\"des\":\"風速\"
1
2.2.2設(shè)備交互UI動態(tài)繪制
將Config文件和設(shè)備icon圖像資源打包成設(shè)備卡片資源文件夾,并上傳至云服務(wù)器。屏端應(yīng)用在啟動時先獲取自身綁定的設(shè)備信息,根據(jù)modeIID值從云端獲取對應(yīng)型號設(shè)備的物模型描述文件。遇到\"category\"屬性時,讀出對應(yīng)值,依照該值從云端下載卡片資源文件夾,如圖2所示。
在屏端進行資源文件夾解析,其中“type\"值為2表示生成 1×2 尺寸的模板頁面;再根據(jù)\"viewType\"屬性獲取并創(chuàng)建“enumButton\"空白模板,通過配置文件獲取該設(shè)備當前物模型的值,在空白模板進行具體渲染。
圖2快捷控制頁動態(tài)渲染流程

2.3詳情控制模塊
設(shè)備詳情頁用來展示更完整的設(shè)備功能和狀態(tài),所需物模型數(shù)據(jù)更多、UI交互元素更豐富,需要將這部分開發(fā)與其他交互界面的開發(fā)進行解耦。同時,也需要在保證渲染效果一致的情況下,提高代碼復用率,實現(xiàn)彈性布局和熱更新。為了實現(xiàn)這些特性,采用ReactNative作為基礎(chǔ)框架。在此基礎(chǔ)上,通過自定義組件、數(shù)據(jù)驅(qū)動UI顯示的方式實現(xiàn)一套模板,適用于不同型號的產(chǎn)品。
2.3.1 封裝自定義組件
ReactNative框架提供一系列內(nèi)置控件,可以直接調(diào)用,比如用于包裹其他組件進行布局,顯示文本內(nèi)容,顯示圖像,顯示滾動視圖,、等是用于交互的可觸摸控件。
將高復用的部分頁面功能模塊封裝在同一個中,并定義其業(yè)務(wù)邏輯,形成獨立、可調(diào)用的自定義組件。其中復用率較高的有標題組件、開關(guān)組件、風速檔位組件等。以標題組件為例,在View中定義布局邏輯(多層View嵌套關(guān)系)和動作定義:
{this.props.devName}
{this.props.roomName}
2.3.2 編寫詳情頁面
每一款設(shè)備詳情控制頁的開發(fā)都可以直接調(diào)用已封裝好的自定義組件,提高代碼復用率,比如新風詳情頁調(diào)用標題組件和風速檔位組件:
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詳情頁面動態(tài)繪制
在整個屏端應(yīng)用程序啟動時,會對RN模塊進行信息初始化,獲取所支持打開詳情頁的設(shè)備信息。進入設(shè)備詳情頁時,首先進行數(shù)據(jù)初始化,獲取最新設(shè)備狀態(tài)屬性;然后調(diào)用ViewModel中的flow,啟動異步操作加載指定詳情頁面。
中控屏端進行頁面渲染時,根據(jù)控件名稱讀取其同名JS文件,并獲取所有需要用到的物模型數(shù)據(jù)properties,再利用props和state進行層級組件之間的狀態(tài)信息傳遞、函數(shù)回調(diào)等,同樣的組件在不同的設(shè)備頁面可以展示不同行為、狀態(tài),組件state更新時也可以觸發(fā)自動渲染界面 UI[13] 。
比如不同型號的新風設(shè)備檔位分級不一定相同,只需將該款新風的風速物模型檔位數(shù)據(jù)windSpeed傳給控件中的model對象,渲染出符合該款設(shè)備的檔位分級,并獲得設(shè)備的真實狀態(tài)值,形成UI。
在設(shè)備控制時,組件的狀態(tài)發(fā)生變化,系統(tǒng)會主動回調(diào)該組件注冊的自定義處理函數(shù)。例如上述示例中針對組件的onChange方法注冊了自定義處理函數(shù)\"onChange O= {this._operateDevice]”,當新風設(shè)備切換風速時,組件狀態(tài)發(fā)生變化,_operateDevice方法會被調(diào)用,最終調(diào)用LUA腳本執(zhí)行設(shè)備控制動作。
3 無感知更新
中控屏產(chǎn)品在出廠時內(nèi)置完整APK包,包含當前版本數(shù)據(jù)的設(shè)備配置文件和bundle插件包。當業(yè)務(wù)拓展、升級時,修改后的新版本卡片資源文件包發(fā)布至IoT平臺,需將詳情操作頁面的全部前端代碼(包括
JavaScript邏輯、引用的靜態(tài)資源及第三方依賴庫)通過構(gòu)建工具打包為標準化bundle文件[4],并部署至IoT平臺。
如圖3所示,中控屏應(yīng)用在啟動或定時輪詢時,會從IoT平臺獲取最新的配置文件版本,通過與本地文件的版本號進行比較得知是否需要更新本地文件,如果有更新,在下載解析新配置文件后通知GUI進行頁面刷新。用戶無需下載更新整個系統(tǒng)固件代碼,也不需要手動觸發(fā)屏端重啟,直接無感知更新。
圖3用戶端更新流程

4功能測試及結(jié)果分析
注:本文通訊作者為趙祚喜。
將該優(yōu)化方案應(yīng)用到現(xiàn)有智能家居中控屏系統(tǒng),主要對設(shè)備控制頁面動態(tài)生成、設(shè)備有效控制及無感知更新等功能的實現(xiàn)進行了驗證。在新接入一款新風設(shè)備時,只需要定義物模型、編寫LUA控制腳本、頁面配置文件和編寫詳情頁面,即可實現(xiàn)自動生成快捷控制頁和設(shè)備詳情頁,無需發(fā)布中控屏固件就可以自動渲染生成頁面,并成功控制設(shè)備。新風設(shè)備屏端顯示狀態(tài)圖如圖4所示。
圖4新風設(shè)備屏端顯示狀態(tài)圖

將該方案應(yīng)用到實際項目中,版本更新從需要手動下載的 190MB 系統(tǒng)整包優(yōu)化成自動觸發(fā)下載更新的2MB插件包,并且開發(fā)、測試用時對比優(yōu)化前的方案而言具有如表1所示改進。
表1網(wǎng)關(guān)開發(fā)、測試用時對比 天

5結(jié)語
本文介紹了一種基于智能家居中控屏進行設(shè)備接人和控制的優(yōu)化方案設(shè)計,接人一款家居設(shè)備時只需要對于設(shè)備本身進行ZigBee協(xié)議開發(fā),不涉及中控屏底層代碼更改,不需要發(fā)布新屏端固件包。交互界面的解耦與動態(tài)渲染可以極大地提高開發(fā)效率,且用戶在使用中控屏時不需要頻繁下載新版本和重啟就可以獲得最新的系統(tǒng)功能和UI呈現(xiàn)。
將本文設(shè)計應(yīng)用在企業(yè)的實際上線項目中,極大地節(jié)省了開發(fā)、測試、市場維護的成本,優(yōu)化了用戶體驗,具有一定的市場應(yīng)用性,對全屋智能中控屏產(chǎn)品的發(fā)展具有現(xiàn)實意義。
參考文獻
[1]張俠丹.中國智能家居行業(yè)研究[J].未來與發(fā)展,2021,45(12):14-19.
[2]蔣翰林.智能家居新浪潮:從智能單品到全屋智能[N].中國經(jīng)營報,2022-11-14(B14).
[3]佚名.智能家居新寵兒,中控屏有什么獨到之處?[J].世界電子元器件,2023(7):3-7.
[4]張曉東,張朝昆,趙繼軍.邊緣智能研究進展[J].計算機研究與發(fā)展,2023,60(12):2749-2764.
[5]李昌奇,何志琴,周恒,等.基于Android和WiFi的智能家居監(jiān)控系統(tǒng)設(shè)計與實現(xiàn)[J].現(xiàn)代電子技術(shù),2020,43(20):67-70.
[6]蔣志偉,王偉,劉姍,等.基于ARM的智能家居系統(tǒng)的設(shè)計與實現(xiàn)[J].現(xiàn)代電子技術(shù),2023,46(4):177-181.
[7]姚健,劉郵政,季曦冉,等.包容性導向下的智能家居設(shè)計研究現(xiàn)狀與展望[J].包裝工程,2024,45(6):1-13.
[8]劉基成,田祎然,李國鋒.基于ZigBee的嵌人式智能家居網(wǎng)關(guān)設(shè)計[J].電子制作,2023,31(22):100-103.
[9]張靜,薛茹.基于JSBridge技術(shù)的跨平臺移動應(yīng)用開發(fā)研究[J].信息與電腦(理論版),2021,33(6):100-102.
[10]劉超,徐志方,王方前,等.面向智能家居的物聯(lián)網(wǎng)操作系統(tǒng)應(yīng)用框架設(shè)計[J].現(xiàn)代電子技術(shù),2020,43(23):143-145.
[11]梁海潔,陳嬌英,陳延明.基于嵌入式ARM構(gòu)架的智能家居控制系統(tǒng)設(shè)計[J].廣西大學學報(自然科學版),2021,46(1):144-149.
[12]馬利軍.Web前端架構(gòu)模式的演化及MVVM模式在 Web 前端框架中的研究[J].軟件,2023,44(7):61-65.
[13]陳磊.一種跨平臺移動APP開發(fā)ReactNative方法的實現(xiàn)[J].電子技術(shù)與軟件工程,2020(10):40-41.
[14]蘇家嘯,武永成.ReactNative技術(shù)淺析[J].中國管理信息化,2021,24(11):192-194.
[15]雷賽楠,章文俊,李昊.基于STM32和ZigBee網(wǎng)絡(luò)的智能家居系統(tǒng)[J].電子設(shè)計工程,2023,31(7:109-112.
[16]劉正業(yè),李震,常新峰.基于Arduino的智能家居系統(tǒng)的設(shè)計與實現(xiàn)[J].電子設(shè)計工程,2021,29(6):29-33.
作者簡介:薛雅璐(2001—),女,湖南益陽人,碩士研究生,研究方向為智能家居控制系統(tǒng)。趙祚喜(1968—),男,湖南張家界人,博士研究生,教授,博士生導師,研究方向為車輛導航控制系統(tǒng)、計算機視覺及農(nóng)業(yè)電氣化與自動化。廖志峰(1985—),男,廣東梅州人,廣東睿住智能科技有限公司軟件研發(fā)總監(jiān),研究方向為智能家居控制系統(tǒng)。鄭麗(2000—),女,四川自貢人,碩士研究生,研究方向為機器人、機械臂強化學習。