在IoT物聯網的架構中，由於受限於網路IP資源與網路通訊方式的限制，因此所謂的雲端(Cloud)伺服器這個中介裝置就變成一個重要不可或缺的設備，但是也因此衍伸出不少限制；因為在網路通訊的世界裡，基本上就是由發主動發出請求的客戶端(Client)裝置，及接受請求的伺服器(Server)裝置這兩種角色所構成，一般來說客戶端(Client)裝置才能發出請求，伺服器(Server)端則只能被動接受請求，以我們的系統來說，在使用雲端中介伺服器之後，不管是主控端或是被控端(例如前一節範例的ESP8266)，這時候都必須執行客戶端(Client)裝置的角色了!
當我們的ESP8266等元件執行客戶端(Client)裝置的角色時，我們就不可能在上面撰寫網頁程式，也就是說便無法像之前介紹過的AP單機模式或WiFi網路模式那樣，把一些人機介面或操作方法直接以網站網頁的方式供連線者使用。而在主控端除非剛好有可用的APP(例如瀏覽器)可用，否則這時候我們就需要另外設計應用的APP程式了！不過由於主控端可能是電腦(PC或筆電)或行動通訊裝置(如手機或平板電腦等)，這時我們就會面臨這些裝置所使用的軟體操作系統(OS)為何﹖是微軟的Windows﹖還是Apple的iOS﹖還是第三方的Linux系統﹖這些問題在在都增加了開發者的難度與成本。
因為一般人的開發硬體還以使用Windows的個人電腦為大宗，所以目前市面上要開發設計手機的應用APP程式，最容易入門也成本最低的大概就是由Google所開發的App
Inventer(因為已經升級到第二版了，一般簡稱為AI2)了！不過這個軟體所開發出來的APP只能針對使用Android系統的手機。
接下來的這一個單元打算使用AI2設計一個簡單的Dweet.io網站測試程式，以便測試我們設計的ESPXX物聯網系統動作是否正常﹖
在進入Google
AI2之後，先開啟一個新的專案(Project)，名稱請自訂，然後在畫面布局設計(Design)開發環境下完成下面的頁面。
在這個程式中共使用了：
1. 4個水平布局元件HorizontalArrangement
2. 4個標記元件Label
3. 2個文字輸入盒TextBox
4. 3個按鈕Button
5. 1個網路元件Web
6. 1個時鐘元件Clock
7. 1個通知器元件Notifier
上列這些元件在手機螢幕上的相關位置如下圖所示：
下圖是使用模擬器執行之後的畫面，在左邊的手機模擬器畫面中，標記1是用來輸入要上傳或下載的IoT物件名稱輸入文字盒，名稱為「txbIoTName」；標記2是啟動自動讀取感測器DHT11測量結果的按鈕，名稱為「getDHT11」(按鈕標題為「開始讀取DHT11」)；標記3是輸入自動讀取DHT11的間隔時間文字盒，名稱為「txbTimerInt」；標記4是讀取或下載標記1所輸入的IoT物件啟動按鈕，名稱為「getDweets」(按鈕顯示標題為「接收dweets」)；而標記5則是顯示接收自Dweet.io網站的回應訊息或下載資料的標記元件，其名稱為「dweetPayload」；標記6名稱為「sendDweets」(按鈕標題為「送出」)的按鈕則是啟動上傳資料到Dweet.io網站之用，上傳的IoT物件名稱共用由標記1文字盒輸入的內容，而上傳的內容則是由標記7「txbDweets」文字盒所提供。
如果我們要以手動的方式讀取前一節範例中，由ESP6266所上傳名稱為『ESP_DHT11』的DHT11溫/濕度的測量結果，則可如下圖所示，首先在標記1的文字盒「txbIoTName」中輸入『ESP_DHT11』這個IoT物件名稱，後按下標記2的「接收dweets」按鈕，便可以在標記3這個名稱為「dweetPayload」的標記元件區域中看到由Dweet.io所送回來的結果了。
至於這個「接收dweets」按鈕的程式方塊(Block)則如下圖所示，當這個按鈕被按下時，程式會先檢查使用者是否有在標記1的文字盒「txbIoTName」中輸入要下載的IoT物件名稱[1]﹖也就是說文字盒「txbIoTName」的輸入內容不能是空白，至於名稱是否正確那就不是我們能處理的範圍了！如果輸入是空白，則程式會由Notifier1送出短暫的警告訊息[不要忘了輸入IoT名稱!] [2]。
如果輸入正常，則程式會將此IoT物件名稱，和前面介紹過的Dweet.io雲端網站下載指令，也就是：
http://dweet.io/get/latest/dweet/for/
組合打包後，指派給Web1的Url[3]，然後再呼叫Web1的【Get】處理副程式[4]，當Dweet.io雲端網站將結果回傳給程式時，會觸發Web1的【GetText】事件，這時我們再啟動”Web1.GetText”事件處理方塊[5] (即下圖中的最下方處)，在此程式方塊中會將Dweet.io雲端網站回傳的回應碼(responseCode)與回傳內容(responseContent)，分別交由「dweetRC」與「myThing」這兩個全域變數傳送給原來呼叫的按鈕程式去處理[6]。
接著程式會先判斷這次的請求及回傳過程是否正常﹖即回應碼是否為「200」[7]﹖如果是則將接收到的完整的訊息內容顯示在「dweetPayload」這個標記元件區域中[8]。如果有錯，則會顯示[接收錯誤!錯誤碼為：XXX]的訊息[9]，其中的”XXX”即為傳送或接收錯誤的回應碼(responseCode)。
如果想啟動自動讀取感測器DHT11測量結果的功能，則可按下標題為「開始讀取DHT11」的按鈕，當程式開始執行時，如下圖左邊手機模擬器畫面的標記1所示，這個按鈕的標題會先切換為「停止讀取DHT11」，且文字的顏色也會改成藍色；除此之外由於程式會定時自動去Dweet.io雲端網站讀取資料，為了避免跟其他的動作衝突，這時標記3名稱為「getDweets」(顯示標題為「接收dweets」)及標記4名稱為「sendDweets」(按鈕標題為「送出」)這兩個按鈕會被禁能(disable)。按鈕，
當自動下載讀取指令送出之後，在等待的過程中，標記2這個用來負責顯示回應接收訊息的標記元件「dweetPayload」區域中，會先出現[DHT11讀取中…]的提示訊息，等Dweet.io雲端網站回應到來時，標記元件「dweetPayload」的內容會如下圖右邊畫面標記5所示，先是接收到的量測結果；其中的訊息內容包括本程式已經從Dweet.io雲端網站讀取的次數、這個DHT11的編號、以及量測到的溫/溼度值。
至於標記6名稱為「txbTimerInt」的文字盒，則是用來輸入自動讀取DHT11感測器的測量間隔時間，其單位是以秒計；在程式啟動後的預設值為10秒，由於Dweet.io雲端網站跟我們的距離是未知數，應該是在遙遠的天涯海角，因為路途遙遠即使是電磁波由於要經過許多關卡，來回也是要花一些時間，所以不要期望能馬上就能看到結果，也就是說即使設定為1秒可能也要等一段時間才會收到回應，所以建議最小值不要小於5秒，以免因為短時間內重複發送太多次反而造成雍塞而產生錯誤。
標題為「開始讀取DHT11」的自動讀取感測器DHT11按鈕，其程式方塊如下圖所示，在一開始同樣的有防呆的功能，會先去測試名稱為「txbTimerInt」這個用來輸入自動讀取DHT11感測器的測量間隔時間文字盒內容是否為空白[1]﹖如果是，則會由Notifier1送出短暫的警告訊息[請輸入讀取時間值!] [2]，由於這個輸入文字盒已經設定屬性為僅能輸入數字(NumberOnly)，但使用者還是可以輸入負號”-“和”0”，所以我們發現這些輸入值都必須發出不同的警告訊息提醒使用者，請他們再次輸入，以免程式當掉或是出現不可預期的錯誤[3]、[4]。
由於這個按鈕是一魚兩吃，同時具備開始與停止自動讀取的功能，至於是執行那一種動作，在此是以它的標題文字來決定，如果按鈕的標題為「開始讀取DHT11」，代表開始啟動自動讀取的功能[5]。而這個功能主要是靠時鐘元件『Clock1』來完成，在此主要是先將「getDweets」(顯示標題為「接收dweets」)及「sendDweets」(按鈕標題為「送出」)這兩個按鈕禁能(Disable) [6]，並把按鈕本身的標題改為「停止讀取DHT11」[7]；然後依照使用者輸入的讀取時間去設定『Clock1』的動作時間(TimerInterval) [8]，接著讓回應接收訊息的標記元件「dweetPayload」區域顯示[DHT11讀取中…]的提示訊息[9]，最後一個步驟才啟動時鐘『Clock1』，也就是讓他的「Enabled」屬性設定為”true”10。
如果按鈕是停止自動讀取的功能，則程式會先將時鐘計時動作停下來[11]，然後將按鈕的標題恢復為「開始讀取DHT11」[12]，最後讓標題為「接收dweets」及「送出」的這兩個按鈕重新啟用(Enabled=true) [13]。
接下來讓我們看一下時鐘Clock1計時器(Timer)程式方塊的內容首先將顯示接收回應訊息的標記元件「dweetPayload」內容清空[1]，然後將Dweet.io雲端網站下載指令指派給Web1的Url[2]，然後再呼叫網路元件Web1的【Get】處理副程式等待Dweet.io雲端網站的回應[3]。
當Dweet.io雲端網站將結果回傳之後，同樣先判斷這次的請求及回傳過程是否正常﹖即回應碼(responseCode)是否為「200」[4]﹖如果有錯，則會顯示[接收錯誤!錯誤碼為：XXX]的訊息[10]。假如接收正確，便開始將相關的訊息顯示在標記元件「dweetPayload」內，首先是顯示本程式已經從Dweet.io雲端網站讀取和下載的次數[5]、[6]，再來是這個DHT11的編號[7] ，接著是量測到的濕度值[8] ，最後是溫度值[9] 。
為了後面的遠端輸出控制範例，本測試程式預先加入手動輸出控制的功能，如下圖所示，便是這個功能的使用畫面；當要上傳資料到Dweet.io雲端網站時，先在標記1的文字盒內輸入這筆資料的IoT物件名稱，以圖中的內容為例，即為「ESP_LEDS_Control」；接著在標記2的文字盒內輸入要上傳的資料內容後，按下標記3標題為「送出」的按鈕即可。只要網路有正常的傳輸，不管結果是否正確，Dweet.io雲端網站的回應內容都會顯示在標記4的標記元件「dweetPayload」內。
標題為「送出」的「sendDweets」按鈕，其程式方塊如下圖所示，程式一樣先檢查使用者是否有在文字盒「txbIoTName」中輸入要下載的IoT物件名稱是否為空白[1]﹖如果輸入是空白，則程式會由Notifier1送出短暫的警告訊息[不要忘了輸入IoT名稱!] [2]。
如果輸入正常，則程式會將此IoT物件名稱，和前面介紹過的Dweet.io雲端網站下載指令，組合打包後，指派給Web1的Url[3]，然後再呼叫Web1的【Get】處理副程式[4]，當Dweet.io雲端網站將結果回傳給程式時，會觸發Web1的【GetText】事件，這時我們再啟動”Web1.GetText”事件處理方塊[5] (即下圖中的最下方處)，在此程式方塊中會將Dweet.io雲端網站回傳的回應碼(responseCode)與回傳內容(responseContent)，分別交由「dweetRC」與「myThing」這兩個全域變數傳送給原來呼叫的按鈕程式去處理[6]。
接著程式會先判斷這次的請求過程是否正常﹖即回應碼是否為「200」[7]﹖如果是則將接收到的完整的訊息內容顯示在「dweetPayload」這個標記元件區域中[8]。如果有錯，則會顯示[接收錯誤!錯誤碼為：XXX]的訊息[9]，其中的”XXX”即為傳送或接收錯誤的回應碼(responseCode)。
沒有留言:
張貼留言