用於將物聯網設備收集的數據(Telemetry),做下一步的處理,提供強大的服務鏈幫助我們「用數據」,這邊先列出幾個Telemetry best practice:
- 每五秒讀一次(既能了解變化,又能不讓資料量那麼大)bandwith of data storage
- 資料時間用UTC time,就不用考慮時區
- 收集所有sensor的監測數據,全部打包成一包string給AWS IOT (effective of getting time series data to the AWS cloud)
— 以下進入正文
當你有監測需求,有了sensor後就會希望有個地方能幫你處理好收到數據後的事情,此時就可利用AWS IOT這個強大的生態系,我們一起來看他能為我們做什麼吧。
假設我們是一個國小中央廚房,為了避免受到食安檢舉,我們可能需要追蹤以下數據:
冷藏/冷凍庫的溫度、炒菜時間、炒菜火侯..
在安裝感測器監測這些數據之後,我們將sensor和aws連線( Connecting to AWS IoT Core.),這個連線會是安全的:
將感測器在aws上註冊,這種虛擬的代表就稱為thing,而實體的感測器稱為device。
Device Advisor(在發布前使用,確保沒問題才發布)
想要檢查/了解設定的thing是否正確,像是看TLS連線,確定policy,mqtt動作等等就可以使用Device advisor (Device Advisor test cases)
確認連線都沒問題後,我們來看看有哪些東西能為我們所用吧。
device shadow & thing type
AWS 提供device shadow記載裝置的資訊,像是版本,thing本身可以放三個屬性,若有指定thing的thingType則可以多至多50個屬性,每一個thingType都是我們自己定義的,像是溫度、開關等等,我們把一些有共通屬性的sensor提出來統一放在type當中,舉例來說,溫度的屬性會有大卡、最低溫度、最高溫度等屬性。
將這些thing設定好了之後,如果我希望在溫度超過40度的時候發警報通知給廠長並且將這個異常記錄到dynomodb,我們可以仰賴Message Broker, engine rules,加上lambda function。
thing group (進階使用)
分為靜態群組跟動態群組,靜態群組是我們自己手動拉的,哪些thing組合再一起叫什麼,而動態群組有點像我們設定一些群組成員的樣貌,由aws自動幫我們維護每個群組的成員列表(sensor member list)有誰。
動態群組的案例可以是跨thing的:
將溫度高於40的感測器加入到這個異常溫度群組,並且將冷氣打開。
Message Broker
sensor收集到的資訊會利用Message Broker將收集到的數據發布給訂閱者,訂閱者可能是某一個aws服務(ex: rules),或是其他sensor。
AWS有提供一些預設的topic提供我們使用,像是config/update或是斷線。
rules
監聽某一個message topic,將訊息用sql like的方式做操作,rules的組成為:
name: 規則的名稱
query: sql like搜尋語法,像是SELECT * FROM 某個topic。
action: 要把資料路由到哪裡 (ex: 轉換資料後發到其他topic, 將資料pass給lambda function做其他處理)
Lambda function
就是一個無伺服器的雲端function,我們只需要寫好Function要做什麼就好了,aws會為我們處理底層的一些東西,不過我們也是需要設定一些基本的,像是記憶體等等。
我們可以把rules傳來的資料,做進一步複雜的處理後寫入dynomodb,詳細怎麼使用,可以去閱讀官方文件或之後有空會獨立在寫一篇。