• 沒有找到結果。

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

5.移除所有事件:

以上整個API程式中有五個主要的地方須進行新感測類型的相關方法與事件 定義。整個API中,可針對ZbDeviceManager類別做擴充更改,讓開發者更直覺使 用取得感測裝置的方法與事件,而方法與事件命名會儘可能貼近該裝置的特性。

public void RemoveAllEvents()

{

this.LocalhostIpReceived = null;

this.BroadcastReceived = null;

this.TemperatureReceived = null; //溫度 this.VoltageReceived = null; //電力 this.HumidityReceived = null; //濕度 this.LedReceived = null;

}

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

3.2.7 裝置控制晶片換版

本小節將說明若裝置上晶片版本或製造廠商更換時,本 API 該如何處理?其 調整幅度多少?由於 ZigBee 無線感測裝置晶片製造大廠德州儀器(TI)是 ZigBee 聯盟的主要領導者,所以本論文以其晶片為標準,相信未來要更改晶片指令集之 標準的機會應該會最小。但晶片的版本更改是無可必免,但就 CC2530 之前版本 與現在 CC2531 版本的演變過程,指令的變化不大,所以本論文之 API 針對 TI ZigBee 晶片的指令定義修改幅度預估不會太大。主要是當新增功能後,需對裝 置控制指令類別增加新指令之定義,當然,若指令用途修改,亦需根據晶片規格 書配合做類別定義調整。

而比較複雜的是,使用非 TI ZigBee 晶片來當做裝置控制指令類別,這牽涉 到整個裝置控制指令類別與裝置操作類別要調整,可能從 Frame Format 的定義 與指令碼的定義均需調整。

圖 3.14 裝置晶片更換意示圖

根據圖 3.14,將說明更換 TI 晶片與非 TI 晶片之 API 修改處理。當更換 TI 晶片時,通常 Frame Format 標準不會變換,但指令集可能會新增或改變。假設 晶片由 CC2530-ZNP 改為 CC2531-ZNP,此時類別專案檔可由 LIB_ZBCC2530 複製 一份為 LIB_ZBCC2531,並在 MS VS2010 中開發專案組件名稱改為 ZBCC2531,而 LIB_ZBDevice 參照之組件亦需改為 ZBCC2531。

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

接著修改新裝置指令類別專案檔 LIB_ZBCC2531,其主要三個類別程式定義 檔:Command.cs、CommandParser.cs、CommandSender.cs。程式中的類別名稱均 無需變更,僅對新增或修改之指令做處理,加入方式可參考現有指令定義之模 式。類別名稱不更動,則不影響 LIB_ZBDevice 專案之引用。

再來需針對 LIB_ZBDevice 專案中 ZbDeviceManager.cs 程式檔作指令操作的 定義,此處亦不更改相關類別名稱,但需調整類別中部份實做方法(Method)的定 義。而有關應用程式使用 API 時,無需做任何修改配合,用法均一樣。

至於若換為非 TI 晶片時,指令的處理原則同上之描述,但需注意每個指令 碼用途與 TI 的定義不一樣,則需在 Command.cs 中重新定義指令名稱與 16 進位 之運途碼。另外,由於該廠商之 Frame Format 雖遵循 ZigBee 協定之標準,但格 式上若有不同之處,則需重新定義裝置指令類別專案中所有的類別檔。同樣地,

類別名稱不必更動,ZbDeviceManager.cs 程式檔亦只作指令操作的定義,不更 改相關類別名稱。

基本上不論更換何種晶片,均須新增組件(即 dll 檔)讓 LIB_ZBDevice 專案 參照。而更換裝置指令類別專案名稱與組件名稱主要是便於管理與日後切換。新 指令類別定義時,類別中的結構定義於非 TI 晶片時可能須重定,指令結構須依 廠商提功之規格書作調整,而實作方法中,部份的指令操作亦需將已修改或新增 之指令定義之。至於應用程式引用 API 時,僅需引用 ZbDeviceManager 類別,使 用讀取裝置感測資料方法即可。

流程至少有以下七種狀況:a.無線感測網路建立流程;b. Coordinator 重新啟 動流程;c.部署新裝置(Router/ End Device)與重新部署/啟動流程;d.節點存 活偵測流程;e.取得特定節點感測值之流程;f.取得所有節點感測值流程;g.

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

a.無線感測網路建立流程

每一個 ZigBee 無線感測網路均要有一個 Coordinator 當做啟動點。一般而 言,建議將該 Coordinator 的 IP 設為 0000,作法上可在韌體上寫入這個設定,

詳細作法非本論文討論範圍,在此不作說明。本研究之開發平台,Coordinator IP 均已設定為 0000。所以當 Coordinator 第一次啟動後,與網管軟體溝通後,會 將該 Coordinator IP 0000 記錄到資料庫中(注 1)。並且將該 Coordinator 之 MAC Address 和電力值也一併記錄之。其實以上的動作即是 ZigBee 無線感測網路節 點在網管軟體上的註冊,Coordinator 是整個網路的第一個節點所以需優先被註 冊和定義,方能進行後續所以節點的註冊。整個建置網路流程如圖 3.11。

圖 3.15 無線感測網路建立流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

b. Coodinator 重新啟動流程

Coordinator 重新啟動時,會重新連結各已存在之 ZigBee 無線感測節點。

但因考量效率問題,在此不針對所有已連結之節點做重新註冊之比對工作。而在 網管軟體中,因 Coordinator 已被註冊過,故網管軟體會先再取得 Coordinator IP 和 MAC Address,已確保此為原來之 Coordinator。若是有更換,則會以取得 之 IP 和 MAC Address 當作該 Coordinator 新的註冊內容。當然電力值亦須同時 更新之。其實重新啟動作業與 Coordinator 建立之流程很類似,主要是讓作業流 程設計儘量一致以減少網管軟體的設計。後續流程介紹亦有此情況,在此先聲明 之。流程如圖 3.12。

圖 3.16 Coordinator 重新啟動流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

c. 部署新裝置(Router/ End Device)與重新部署/啟動流程

圖 3.17 部署新裝置與重新部署或啟動流程

圖 3.13 為部署新裝置與重新部署或啟動之流程。此流程中所提之新裝置,

主要是針對 Router 或 End Device。當新裝置要加入 ZigBee 網路,會先搜尋最

接近的頻道(Channel),一個頻道表示一個 ZigBee 無線感測網路,而網路中唯一 的 Coordinator 會分配 IP 給新裝置。新裝置的 IP 會先被記錄在 Coordinator 中,此即表示該新裝置已是該 ZigBee 網路某一節點。後續再透過網管軟體進行 節點註冊,將 IP、MAC Address、電力、節點功能屬性定義資料記錄於網管資料 庫。

在記錄註冊資訊時,網管軟體要負責判斷該節點是已存在節點重新部署或是 新裝置的加入。一般情況下 Coordinator 分配 IP 給某裝置通常 IP 是會固定下來 的,但 IP 有可能還是會被用掉而須給新的 IP,所以不建議用 IP 來判斷節點是 否為新節點。比較合理的方式應該是用 MAC Address,其如我們電腦上的網路卡,

是具唯一性的。所以,當 MAC Address 已被定義在註冊表中,表是該節點是重新

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

再配合報表或查詢作業提供電力不足或無電力節點之列示,更能方便掌握整個網 路節點存活狀況。

圖 3.18 節點存活偵測流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

e. 取得特定節點感測值之流程

此流程主要應用在節點相互控制時,利用程式取得某節點之感測值做後續 之互動性控制。當控制節點經由 Coordinator 分配 IP 連上 ZigBee 網路後,可配 合控制程式指定之感測裝置,透過 Coordinator 叫醒節點感測裝置,並回傳感測 值。取得後之感測值可記錄程式中,透過管控邏輯可讓該感測值控制其他節點。

當然依需求,該感測值亦可回寫資料表,當做日後統計分析使用。相關流程如圖 3.15 所示。

圖 3.19 取得特定節點感測值之流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

f. 取得所有節點感測值流程

欲取得所有感測裝置之感測值,可透過網管軟體或控制程式,透過後者可更 彈性設計取得之頻率與應用範圍,其流程如圖 3.16 所示。

圖 3.20 取得所有節點感測值流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

本流程說明以控制程式方式為例,程式透過控制節點針對註冊表中所有感測 裝置 IP 下達取得感測值之動作,如:GetValue(),在本研究的 API 其讀取的方 法(Method)以溫度為例,為 DeviceManager.ReadTemperatureSensor(IP)。之後 將結果收集或顯示之,以便後續應用。透過程式可以設定連續讀取感測值,藉此 收集資料觀察感測值的變化;亦可做定期數據收集之工作,如醋工廠醋庫存的回 報作業。當然透過此作業流程亦可加入尚餘電力之記錄,因為其作業流程是相似 的。

g.節點互動控制流程

本流程說明兩個節點的控制,由感測裝置節點 A 控制感測裝置節點 B。當控 制節點連上 Coordinator 後,透過控制程式 New 一感測裝置節點 A 類別之感測物 件,並設定節點 A 之 IP,表示針對節點 A 做操作。該物件透過取得感測值之 Method(),經由控制節點與 Coordinator 取得節點 A 之感測值。取得之感測值經 判斷,若符合驅動感測裝置節點 B,則同樣經由控制節點與 Coordinator 取得節

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

點 B 之感測值,傳回之感測值可做相關之應用。而感測裝置節點 A 控制感測裝置 節點 B 之運行若為持續性之動作,則可加入條件判斷之。

圖 3.21 節點互動控制流程

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

3.3.2 如何讀取裝置測值感

如何利用本研究 API 讀取某裝置之感測值? 運用時之程式實作流程可參考 圖 3.19, 主要的關鍵在於如何決定讀取感測資料之動作及讀取後資料的處理,

並判斷為一次性或連續性的讀取。

圖 3.22 運用 API 之程式實作流程

以下針對一次性與連續性取得感測值之 C#程式寫法做說明:

引入 ZBDevie 命名空間(Namespace):

定義程式中的全域變數:

取得溫度之按鈕動作:

溫度讀取之 Callback 事件:

相關完整程式碼請參考附錄 C.1。

using ZigBee.LIB.ZBDevice;

//若需與 Database 做存取則須引入該 Namespace

using ZigBee.LIB.ZBDatabase.BLL;

using ZigBee.LIB.ZBDatabase.DAL;

private ZbDeviceManager DeviceManager; /與ZB Device有關 private ZigBeeEntities db = new ZigBeeEntities(); //與DB有關

//設定溫度感測器被觸發的次數,當按啟動的按鈕,觸發次數設為 1

private byte SensorTriggerOnce_Temper = 0;

private void btnTemperGet_Click(object sender, EventArgs e)

{ //觸發次數設為1

SensorTriggerOnce_Temper = 1;

//將畫面上指定之裝置IP轉為整數模式

UInt16 ipAddress = Convert.ToUInt16(this.txtIpAddress.Text);

//根據此裝置IP,透過DeviceManager進行感測值之取得

this.DeviceManager.ReadTemperatureSensor(ipAddress);

}

void DeviceManager_TemperatureReceived

(object sender, TemperatureReceivedEventArgs e) {……}

btnTemperGet.PerformClick() 連續執行btnTemperGet_Click取得感測值。

同樣地,須引入ZBDevie命名空間。相關程式說明如下:

this.zbTemperTimer.Interval =1000;

private void zbTemperTimer_Tick(object sender, EventArgs e)

{ // Sensor Request

btnTemperGet.PerformClick();

}

private void zbTemperRead_Click(object sender, EventArgs e)

{

//若該裝置為無效者或COM Port沒打開,則不讀取感測值

if (this.activeZbDevice == null ||

this.DeviceManager.SerialPort.IsOpen == false) return;

//根據此裝置IP,透過DeviceManager進行感測值之取得

this.DeviceManager.ReadTemperatureSensor(SensorLog_TargetIp);

}

void DeviceManager_TemperatureReceived

(object sender, TemperatureReceivedEventArgs e) {

this.Invoke((MethodInvoker)delegate()//安全跨執行緒

{ //經由DeviceManger_TemperatureReceived事件,將資料(e)傳回

string value = string.Format("{0}.{1}",e.Msg.Integral,e.Msg.FloatValue);

//將取得之感測值傳至畫面上

this.zbTemperValue.Text = value;

});

}