一種Android端智能家居遠程控制方案的實(shí)現

摘要：針對智能家居遠程控制問(wèn)題，結合Android終端設備，設計了一套控制信息對用戶(hù)透明的遠程空調控制系統。系統底層控制信息通過(guò)基于GSM的短消息方式傳輸，實(shí)現了對由6臺空調組成系統的遠程控制。系統采用自定義通信協(xié)議，在Android端討論并實(shí)現了兩種接收返回信息方式——BroadcastReceiver和ContentObserver方式，對Android中的Handler機制進(jìn)行講解應用。測試結果表明，系統結構設計合理，操作簡(jiǎn)單，性能穩定。

引言

遠程控制作為智能家居的一種標志性技術(shù)，被廣泛應用于各種智能家居系統中。本文設計并實(shí)現了一種智能家居中遠程空調控制方案。本系統基于A(yíng)ndroid系統客戶(hù)端用戶(hù)友好型界面和GSM模塊，屏蔽控制信息傳輸處理細節，客戶(hù)端采用控件綁定號碼的方式，用戶(hù)只需根據終端Android界面提示，即可完成遠程空調控制。相比于以往方案中GSM模塊采用PDU方式進(jìn)行通信，用戶(hù)端需要手動(dòng)輸入具體命令的模式，本系統采用text文本方式進(jìn)行通信，傳輸的控制命令僅為數字即可。

本文實(shí)現了兩種Android應用中接收短消息的方式BroadcastReceiver(廣播接收者)方式和ContentObserver(內容觀(guān)察者)方式，采用Hand ler機制將接收到信息顯示，且對安卓中SQLite數據庫的操作進(jìn)行闡述及應用。本系統通過(guò)接收GSM控制消息的基于LPC1766芯片的集中器傳輸控制消息到各個(gè)分控制器，可以同時(shí)控制6臺空調，每臺空調對應一個(gè)分控制器，具體系統控制端架構見(jiàn)圖1。

1 系統控制端設計

1.1 硬件設計

本系統采用NXP公司的LPC1766芯片作為集中器的SoC。系統GSM模塊采用華為公司的GTM900-B型號無(wú)線(xiàn)模塊，該模塊具有標準的AT命令接口，并提供無(wú)線(xiàn)接口用于短消息的收發(fā)，且可通過(guò)串口通信和嵌入式MCU相連。

本系統葉GSM模塊和集中器通過(guò)串口相連。GTM900-B模塊的串口與LPC1766的UART0相連，具體連接見(jiàn)圖2。

1.2 AT指令

GTM900-B模塊使用了GSM Rec.07.07中規定的標準AT命令，本系統需要使用到的AT命令如表1所列。

1.3 通信協(xié)議

本系統主要通過(guò)GSM短消息的方式完成對每個(gè)房間的溫度獲取(通過(guò)分控制器上的溫度傳感器)和每個(gè)房間空調工作模式、溫度的設置，以及關(guān)閉房間空調的功能。從安卓終端的角度包括兩個(gè)方面的通信——發(fā)送和接收。

從安卓終端發(fā)送到GSM模塊的控制信息包括三個(gè)方面：獲取溫度值，設置某個(gè)房間空涮參數，關(guān)閉某個(gè)房間李調。GSM模塊采用text方式通信，系統將發(fā)送的三種控制信息數字化為相同規格：

其中Sent1表示控制信息類(lèi)型：“1”表示獲取溫度，“2”表示設置某個(gè)房間空調，“3”表示關(guān)閉某個(gè)房間空調。Sent2表示房間號，取值1～6對應相應房間。Sent3表示當Sent1為“2”時(shí)，設置號碼為Sent2的房間空調的工作模式：“1”表示制熱，“2”表示制冷，“3”表示送風(fēng)，“4”表示除濕。Sent4表示當Sent1為“2”時(shí)，設置號碼為Sent2房間的工作溫度。分隔符用冒號表示，主要作為區別控制信息與初始化返回信息的標識符。所以，Android發(fā)送端發(fā)送的控制信息格式表示為“Sent1：Sent2：Sent3：Sent4”。

對安卓終端接收的反饋消息也包括三個(gè)方面：集中器從分控制器得到的溫度信息，設置某個(gè)房間空調成功的返回消息，某個(gè)房間空調關(guān)閉的返回消息。因為這三種消息長(cháng)度不一致，處理方式不同，系統只對接收消息的前兩位格式化即可完成系統功能，具體如下：

其中：Rec1表示反饋信息類(lèi)型：“1”表示溫度信息，“2”表示設置空調返回信息，“3”表示關(guān)閉空調返回信息。Rec2表示當Rec1為“2”或“3”時(shí)空調返回信息，“1”表示設置或者關(guān)閉成功，“0”表示失敗。所以，Android接收端接收的由系統控制端返回的信息中，首先會(huì )判斷第1位(即Rec1位)，如果是“1”，則表示返回的是各個(gè)房間的溫度;如果是“2”，表示的是設置空調(Sent1等于“2”時(shí))的返回消息;如果是“3”，表示的是關(guān)閉空調(Sent1等于“3”時(shí))的返回消息;對于Rce1等于“2”或者“3”，再根據Rce2來(lái)判斷相應的返回消息狀態(tài)。

1.4 集中器軟件設計

集中器上的程序主要完成系統模塊和GSM模塊初始化，判斷控制信息類(lèi)型及作相應的處理，向終端用戶(hù)返回消息。具體程序流程見(jiàn)圖3。

其中GucRcvNew=1表示集中器從UART0接收到來(lái)自GSM模塊的返回消息，recvfg用來(lái)對GSM模塊進(jìn)行初始化，其初值為0。集中器發(fā)送命令at到GSM模塊，如果接收到GSM模塊的“at ok”返回消息，則設置recvfg=1，然后進(jìn)入switch語(yǔ)句，當recvfg=1時(shí)，向GSM模塊發(fā)送命令at+cmgf =1，如果返回值為“at+cmgf=1 ok”，設置recvfg=2。當recvfg=2時(shí)，向GSM模塊發(fā)送命令“at+cnmi=2，2，，1”，如果返回值為“at+cnmi =2，2，，1 ok”，設置recvfg=3，到此GSM模塊初始化結束。如果初始化過(guò)程中當集中器發(fā)送AT命令后，接收到的不是正確返回值，則設置recvfg=0，重新開(kāi)始初始化。

根據控制信息類(lèi)型設置flag子程序和根據flag值進(jìn)行相應處理的子程序主要是在初始化結束后完成系統功能，程序流程見(jiàn)圖4、圖5。

本系統集中器采用UART中斷方式和GSM模塊通信，當有數據返回集中器時(shí)，會(huì )觸發(fā)UART中斷，在UART中斷處理程序中從U0RBR寄存器讀數據到GucRcvBur[Gu1Num]數組中。因為每次通信返回的字節數不相等，本系統在UART中斷處理函數中引入定時(shí)器中斷，在定時(shí)器中斷處理函數中設置GucRcvNew==1。即每次進(jìn)入UART中斷處理函數時(shí)，開(kāi)啟定時(shí)器，UART在初始化時(shí)設定的中斷觸發(fā)點(diǎn)是1個(gè)字節，當所有返回字節都接收完成時(shí)，定時(shí)器超時(shí)會(huì )觸發(fā)定時(shí)器中斷處理函數，設置GucRcvNew==1，主程序檢測到有數據返回。系統中設置定時(shí)器的觸發(fā)時(shí)間是0.5 s。

2 Android端設計

本系統采用Android應用程序的用戶(hù)友好型界面作為與用戶(hù)的接口，Android終端程序通過(guò)控件綁定方式對固定號碼進(jìn)行短信接收與發(fā)送，用戶(hù)只需通過(guò)點(diǎn)擊控件方式即可傳遞和接收控制信息，具體根據系統自定義通信協(xié)議發(fā)送的控制信息則完全被程序屏蔽，對用戶(hù)完全透明。其中發(fā)送短信和接收短息都會(huì )對Android系統的SQLite數據庫作出改動(dòng)，需要對數據庫中的相關(guān)信息進(jìn)行刪除來(lái)保證對用戶(hù)透明。另外對于控件之間消息傳遞采用Android中的Handler機制。

2.1 發(fā)送控制信息

Android中發(fā)送消息主要通過(guò)SmsManager類(lèi)來(lái)實(shí)現，它繼承自java.lang.Object類(lèi)。其主要的方法說(shuō)明略——編者注。

發(fā)送短信程序首先調用SmsManager. getDefault()獲取SmsManager對象，然后通過(guò)PendingIntent的getActivity方法獲得一個(gè)Pending Intent對象。根據短信長(cháng)度Message.length()與短信長(cháng)度最大值比較來(lái)判斷是否需要調用smsManager.divideMessage(Message)將短信分割，然后再調用smsManager的sendTextMessage方法發(fā)送短信。代碼略——編者注。

發(fā)送短信模塊需要在清單文件AndroidManifest.xml中加入允許發(fā)送短信的權限：

2.2 接收返回信息

在A(yíng)ndroid端接收消息，可以采用兩種方式，一種通過(guò)BroadcastReceiver廣播接收器的方式，另外一種是通過(guò)觀(guān)察數據庫變化的內容觀(guān)察者類(lèi)ContentObserver來(lái)實(shí)現。

2.2.1 BroadcastReceiver接收短信

Android中的廣播是一種在應用程序之間傳遞信息的機制，在A(yíng)ndroid中有多種廣播，基于GSM短信的接收會(huì )產(chǎn)生一個(gè)廣播，應用程序可以監聽(tīng)這些廣播并根據廣播類(lèi)型作出相應的處理。BroadcastReceiver就是對接收到的廣播進(jìn)行過(guò)濾并響應的一類(lèi)組件。

當應用程序接收到廣播發(fā)送來(lái)的intent對象，BroadcastReceiver類(lèi)根據其注冊的廣播地址與接收到的intent對象進(jìn)行比較，如果匹配則調用BroadcastReceiver的onReceive()方法。

BroadcastReceiver類(lèi)的注冊有兩種方式，第一種是靜態(tài)注冊方式，即在A(yíng)ndroidManifest.xml文件中利用intent—filter指明需要過(guò)濾的廣播地址。靜態(tài)注冊方式會(huì )使程序始終監聽(tīng)廣播消息，并自動(dòng)調用程序繼承自BroadcastReceiver的類(lèi)。第二種是動(dòng)態(tài)注冊方式，其在activity中調用函數registerReceiver來(lái)注冊，當應用程序關(guān)閉后，就不在進(jìn)行監聽(tīng)。在動(dòng)態(tài)注冊的activity被銷(xiāo)毀前，需要調用unregist er Receiver解除注冊。

短消息廣播是一個(gè)有序廣播，即每次只被優(yōu)先級最高的接收者處理，然后由優(yōu)先級高的接收者傳遞到優(yōu)先級低的接收者。優(yōu)先級高的接收者可以終止這個(gè)廣播。對于有序廣播而言，動(dòng)態(tài)注冊的優(yōu)先級高于靜態(tài)注冊。

系統中定義SmsReceiver類(lèi)繼承自BroadcastReceiver類(lèi)，采用動(dòng)態(tài)注冊的方式，在activity中用于動(dòng)態(tài)注冊的代碼略——編者注。

接收短信模塊需要在清單文件AndroidManifest.xml中加入允許發(fā)送短信的權限：。

2.2.2 ContentObserver接收短信

系統實(shí)際使用中，對于用BroadcastReceiver接收短信往往效果不好，主要因為用戶(hù)在A(yíng)ndroid終端安裝的第三方軟件，比如接收短信軟件、安全軟件等，這類(lèi)軟件從底層獲取系統權限，優(yōu)先級始終高于應用層軟件，導致應用層軟件不能優(yōu)先接收到廣播消息，所以在設計短信接收客戶(hù)端時(shí)一般采用監聽(tīng)數據庫方式。

當客戶(hù)端接收到短信后會(huì )將其插入SQLite數據庫，數據庫發(fā)生變化會(huì )觸發(fā)內容觀(guān)察者——ContentObserver。

ContentObserver類(lèi)似于一個(gè)觸發(fā)器，當其所觀(guān)察的Uri發(fā)生變化，這個(gè)觸發(fā)器就會(huì )觸發(fā)來(lái)執行相應的處理。主要方法的說(shuō)明略——編者注。

本系統在onChange的方法中，利用Context實(shí)例對象的getContentResolver方法獲得一個(gè)ContentResolver對象，然后調用Content Reso lver的query方法獲取當前數據庫中的短消息。具體代碼略——編者注。

對于得到的短消息通過(guò)Cursor對象的getColumnIndexOrThrow方法獲取其thread_id，id和body內容。對于在數據庫中的短消息，為了保證對用戶(hù)的透明傳輸，要調用ContentResolver對象的delete方法將收件箱中的短消息刪除。具體代碼略——編者注。

ContentObserver接收短信模塊需要在清單文件AndroidManifest.xml中加入允許接收短信的權限：

2.3 Handler機制

對于使用ContentObserver接收到房間溫度信息后，通過(guò)Android的Handler機制將信息傳送到主activity顯示。在A(yíng)ndroid中，主程序會(huì )創(chuàng )建一個(gè)Looper對象，在Looper對象初始化時(shí)候會(huì )創(chuàng )建一個(gè)消息隊列Message Queue用來(lái)存放線(xiàn)程放入的消息。用戶(hù)可以構造一個(gè)Handler對象與Looper溝通，以便將消息push到消息隊列中。當主線(xiàn)程檢測到有新消息進(jìn)入消息隊列后，首先判斷該消息對應的Handler，然后將消息分發(fā)到指定的Handler處理。

系統中通過(guò)ContentObserver繼承類(lèi)SMSContentObserver的構造函數將在activity中定義的Handler對象傳入SMSContentObserver中，然后調用Handler對象的obtainMessage方法獲得一個(gè)message對象，最后調用message對象的sendToTarget方法將控制消息發(fā)送到消息隊列，在activity中定義了handleMessage函數用來(lái)處理得到的控制消息。具體代碼略——編者注。

2.4 Android終端效果

Android客戶(hù)端控制界面見(jiàn)圖6，當點(diǎn)擊“獲取溫度”按鈕，Android端會(huì )自動(dòng)向系統控制端發(fā)送短信“1：O：O：00”，這樣系統控制端會(huì )檢測到是1類(lèi)控制信息，則返回每個(gè)房間溫度。

當需要設置某個(gè)房間空調的丁作方式，則通過(guò)點(diǎn)擊“設置空調”按鈕左側的“房間號”、“空調模式”和“設置溫度”等三個(gè)下拉列表(Spinner)來(lái)設置。如設置房間號為“房間二”，空調模式為“制冷”，設置溫度為“25℃”，然后點(diǎn)擊“設置空調”按鈕，安卓端會(huì )自動(dòng)發(fā)送2類(lèi)控制信息“2：2：2：25”到系統控制端，系統接收到控制信息會(huì )處理后返回設置是否成功消息。安卓端解析后將其顯示。當需要關(guān)閉某個(gè)房間空調，可以通過(guò)“關(guān)閉空淵”按鈕左側的“要關(guān)閉空調所在房間號”下拉列表實(shí)現，比如選擇“房間五”，然后點(diǎn)擊“關(guān)閉空調”按鈕，Android端即把3類(lèi)控制信息“3：5：0：00”發(fā)送到系統控制端，系統控制端處理后將空調關(guān)閉狀態(tài)返回。

結語(yǔ)

智能家居中的遠程控制方式有很多，本系統結合Androld終端的用戶(hù)友好型界面，采用自定義協(xié)議方式，設計了一套基于短消息的空調控制系統。在A(yíng)ndroid終端接收返回信息的兩種方式中，ContentObserver因其穩定性在工程實(shí)踐中使用較多，本系統最終也是采用了Cont entOb—server的方式，并取得很好的效果。本系統設計合理，性能穩定，對其他工程設計也具有一定參考價(jià)值。