上一篇主要介紹一下物聯網的大環境和什麼是Lettuce IOT架構而這一篇将要講解華為的IOT平台。
華為OceanConnect平台操作一，profile檔案與編解碼插件的開發
思考一下：當今WEB應用都喜歡做成分布式，因為分布式可以将壓力平均的分發給下面小的伺服器去處理。包括hadoop也是，将碎片化的存儲和計算能力集中起來利用。但是這些技術都離不開一個元件，那就是監控管理中心，比如SpringCloud的Eureka服務治理以及hadoop的ZooKeeper服務協調。這樣就好比一個班裡有一個班長一樣，大家都聽他一個人。他也負責管理遲到，早退，請假等任務。這樣一來，原本渙散的班級從此被擰成一股繩。
在IoT的世界裡其實更需要監控管理中心，因為線下硬體不如線上軟體。硬體會有非常多一想不到的事情發生，是以更需要有一個去管理他們的平台。
以往的硬體管理平台都是我們自己搭建的，簡陋粗暴，在時間緊任務重的情況下還沒有鑒權機制，成為日後安全的隐患。其實硬體管理平台屬于必備品元件，但是做一個簡單的很容易。如果做一個功能很完善的，那真的是難上加難，因為涉及的東西實在是太多了。不過剛好，華為的OceanConnect全聯接平台（以下将簡稱OC平台）滿足了我們硬體管理平台所有需求。
之是以先講OC平台是因為，這款IOT架構其實由OC平台提供的項目開發思路，也是以OC平台的功能模組化。是以OC平台是這個架構的必要元件，也是架構的開發源頭。
這個就是OC平台的項目開發流程圖，我們需要先在OC平台把産品設計出來，比如我們示範的這個項目。
最後在手機上可以檢視裝置是否線上，對燈的操作，以及裝置完美退出。
鑒于這3個需求我們分析出一套完善的産品出來：
- 檢視裝置是否線上，這個需要線下裝置定時發送心跳狀态來實作。
- 燈的操作，需要對線下裝置發送開/關指令，
- 并且還要定時與線下裝置校對燈的狀态，那就是需要發送查詢燈狀态的指令，傳回燈的狀态。
- 裝置完美退出，這個主要是開發時用的功能，因為要不斷的調試，就要不斷的運作和退出。在退出時難免會有一些關閉流，接口之類的操作，是以有這個功能。
産品功能分析完了，接下來我們進入OC平台
華為雲平台https://www.huaweicloud.com/
産品 -> IoT物聯網 -> IoT開發者專區 -> 免費體驗 -> 進入開發中心
進入平台以後：
- 建立一個項目，随意填寫，不影響後面流程。
- 再建立一個産品，此時可能要填廠商資訊。廠商資訊随意填寫，不影響後面流程。然後繼續建立産品。
隻有這幾個需要注意，其他随意。
産品設計OK，産品建立OK。接下來是開發階段：
首先我們再看這個流程圖，接下來我們要開發profile配置檔案。
思考一下：以前的無線電電報都是靠發送或接受短/長的電信号來傳遞消息，而不管是發送方還是接受方都需要有一個翻譯電碼的标準，抗戰時期管這個叫密碼本。有了這個密碼本，無論是誰都可以翻譯出電信号的意思，翻出人能看明白的電報。
而這個密碼本類似于我們要開發的profile檔案，這個檔案制定的規則，屬性名稱，指令名稱。可以讓任何機器都對照profile檔案翻譯出來。是以不管是裝置端，OC平台，服務端都需要以這個檔案來了解上行或者下行機器發出的資料是什麼意思。
OC平台一大特點就是，可以幫助開發者更友善的開發，比如我們要想開發這個profile配置檔案，是要寫JSON檔案的，但是OC平台提供了更直覺的開發方式。
Profile的結構：
Profile由基礎資訊和服務能力構成。
服務能力我覺得類似于面向對象開發，每一個服務能力都對應着線下硬體的一個子產品。
比如燈有目前狀态的屬性，屬性的資料類型，還有開/關的方法，方法的入參與傳回值，是以燈作為一個類的存在，對應着線下燈的子產品。
這次示範我們提供2個服務能力，一個是燈的，一個是樹莓派的。
Profile檔案定義好了，我們還需要一個“譯碼員”
這個“譯碼員”就是下一個要開發的編解碼插件，OC平台接收時接到的是二進制資料。編解碼插件可以根據Profile檔案翻譯成我們可以看得懂的json資料。
資料來源主要有四種：
- 裝置發給OC平台的資料上報
- 資料上報以後OC平台發給裝置的響應，告訴裝置已接收
- OC平台發給裝置的指令下發
- 指令下發以後裝置發給OC平台的響應，告訴OC平台已接收并傳回響應的參數。
但是在華為OC平台中開發編解碼插件，我們将一個操作産生的上下行資料（發送和響應）作為一個編解碼消息模闆來收發。
一般來說一個編解碼消息模闆對應一個服務能力的一個或多個屬性或是一個服務能力一個指令。比如上面那個profile檔案中有2個服務能力，每個服務能力都有屬性，那麼這就是2個資料上報編解碼消息模闆。profile檔案中有2個服務能力，其中SwitchBulb有2個指令， 而OperationPi 有1個，這就對應着有3個指令下發編解碼消息模闆。
比如說燈的開/關下發指令這個編解碼消息模闆：
指令下發與響應是對應的，我們看到下發的value屬性和響應的result屬性對應的是剛才配置Profile檔案中的ON_OFF指令下的屬性。
除了Profile檔案中的ON_OFF指令下的屬性的還有3個字段，分别是messageId以及mid和errcode。
思考一下：信通常由位址和收信人組成。比如有兩封信都郵到一個學校裡，學校都有收發室。自然信會統一放到收發室保管。然後收發室裡的人會根據收信人把信發到指定人手中。
現在轉換過來，位址是你的華為OC平台。需要用messageId來區分是哪個消息模闆來解碼這條消息。
messageId是消息的位址域辨別符，用于編解碼區分是哪個消息模闆。比如SwitchBulb中裝置上傳status消息，和指令下發ON_OFF，這屬于2個消息模闆。在建立消息模闆時需要添加messageId位址域字段，OC平台會自動給這個字段指派。用于消息進來時，平台自動用哪個消息模闆來解碼消息。
Mid字段主要是指令下發模闆使用的，用于區分是哪個指令下發的響應。比如我們連續用ON_OFF這個消息模闆連續下發3條指令。當平台接收到響應時，便可以根據mid來對應是3條的哪一條的響應回值。
Errcode字段主要用于指令下發模闆響應時使用的，用來表示執行成功還是失敗（0為成功，1為失敗）
注意：指令下發的messageId和Mid必須要位置要對應。messageId字段序号1就要對應響應的序号1，不然會解碼失敗。
響應字段必須要有回值字段，作者曾經嘗試把result字段去掉，但是平台在接收響應時報無法比對消息模闆的錯。
這次示範的編解碼插件，我們一共建立5個消息模闆。
分别對應Profile檔案的2個服務能力的屬性和3個指令。
因為我們Profile檔案中所有屬性和指令内屬性都是0/1，是以長度設定1即可。
messageId，mid和errcode隻需要勾選相應選項即可。
添加完消息模闆以後，我們還需要将消息模闆手動的與profile檔案中的值一一對應。這樣編解碼插件才會将二進制資訊處理為json檔案。
将右側的屬性和指令拖拽至相應區域，與消息模闆中的字段對應即可。
這樣，編解碼插件就大功告成了。然後别忘了部署哦
部署好了以後，profile檔案與編解碼插件的開發就完成了！
下一章節我們來模拟調測一下。
歡迎加入我們的QQ群一起讨論IOT的問題。