Proposal of new LASS data format (under discussion)

Event 連結

Event - LASS-MQTT 資料格式再進化規格討論

Agenda

8:30 - 8:40 打招呼時間
8:40 - 9:00 LJ 針對提案的 proposal, 說明或是 Q&A
9:00 - 9:15 針對已在 hackpad comment 的部份討論
9:15 - 9:30 針對在 FB 建議的事項討論
9:30 - 10:00 嘗試下出結論

結論：表決通過

經熱烈的溝通與討論，LJ 的提案表決通過，含以下的修正
1. MQTT length 在 device 端，長度限制由 512 改到 14xx, device 盡可能支援，有不能支援的 device, 未來再討論作法（哈爸改 LinkItONE library 的支援, 科大改 Ameba 的支援）
2. Meta Data都有歷史紀錄可以查（可以給 JSON api）如果沒有更新就以最新的一次更新為準
3. 不分 dynamic/static
4. LJ 有空會提 mata data 格式的建議

緣由

目前的 MQTT message長度已經到達極限

長度還可以延伸，請問為何說已到極限？
目前看到似乎都是自行限制，最少的也有1K，大的要幾百MB都沒問題，會有問題頂多是處理端

有些資料似乎不需要一直傳（例如固定點的 gps 座標）

建議將固定式與移動式資料分離，以利於後台分析並增加測試區，於開發測試階段使用測試區，區分正式與測試資料

用sensor id 的方式很不直覺且不利於後端處理（例如 s_t0 s_t1 s_t2 都代表溫度）

提案

將資料分為 meta data, dynamic value, static value 三種類別
meta data描述硬體組成，例如感測器種類，可靠性分類(測試模組中或已穩定運作的佈點等區分)

可靠性分類可利於後續視覺化呈現的優先級別或是資料分析時雜訊的剔除
可靠性感覺很難劃分,資料分析的時候再剔除感覺比較好一點,感應器種類真的需要加
如果只是要測試連線的話,似乎可以設計一個特殊封包去Activate裝置,在裝置丟出這封包前都不算是有註冊的Sensor
測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。
sensor 資料週期上傳，就知道 sensor 存在

Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新

dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值
static value 描述短時間內未發生變化的感測值，例如定點的GPS座標
meta data, dynamic value, static value 用 APP 和 device_id 作為 index，每筆資料皆加上傳送時的 timestamp

Timestamp感覺在Server端處裡就好,Device端如果沒有常常校正RTC,timestamp很容易跑掉
建議只分 meta data, data (含 dynamic value, static value) 以簡化系統設計

static value 可當做 heart beat，用以確認感測點仍上線
資料傳輸的頻率: meta data < static value < dynamic value

優點

可大幅減少資料傳輸量
不再需要一次將所有資料塞在一個 MQTT msg 中
若感測器太多，可用多個 mqtt msg 傳送
相同的物理性質（例如溫度）可用相同的代號(temperature)，僅需要在 meta-data中敘明感測器型號即可

缺點

和既有的資料格式不相容
程式撰寫比較複雜，不同類別的資料要有所區別，且分別進行傳送

基本上是很好的建議，畢竟會大幅更改，所以建議能多討論一些細節，一次改得更完整一點

Q&A

Lanma Chiu

Ｑ1: 有人喜歡內文使用Json格式嗎？雖然長了點，但各式接收端好處理。

A1-1: 資料格以越簡單的方式表示，甚至 device 收到 MQTT 也容易實現 Paser, 個人不建議用 JSON

後端有轉 JASON API 的 service, 可參考

LASS Data Platform

Tzu-Te Wang

Q2:

我的建議是，

1. 所有資料都是即時更新，在MQTT協議裡叫做retain message

2. 不需要加上時間，服務器上就有時間了，最多就是紀錄最後更新的時間

可參考研究筆記 - 資料時間
我建議向服務器訂閱時間，設備不用具備ＲＴＣ。小硬體可以參考取到的時間，上報資料時將ｔｉｍｅｓｔａｍｐ附上。

3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量

理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題
贊同，GPS資料就當retain message方式處理，有更動自己update。

建議的Topic格式:

/國碼(例如886)/區碼(02)/LASS/device id(HEX)/感應器類別(例如T0)/資料數值(十六進制, IEEE754標準)

/國碼(例如886)/區碼(02)/LASSTEST/test device id(HEX)/感應器類別(例如T0)/資料數值(十六進制, IEEE754標準)

這樣當我要收集台灣區的溫度資料只要scubscribe "/886/#/T0" 就有了

我要收集台南市的空汙資料只要訂閱 "/886/06/#/PM2.5" 就有了

我要分析台南市的空汙及溫度濕度的關係只要訂閱 "/886/06/LASS/+"

我要收集美國的資料只要訂閱topic開頭是 "/1/+/LASS/+"

未來topic可以平行擴充，例如 "/886/02/EARTHQUAKE/+" 表示地震數據

因為資料是retain的，所以，我只需要將所有收到的數據加起來平均。

META用來發佈到服務器讓服務器去做資料登入資料庫

例如發布

/device id/GPS/LAT 訊息23.nnnn 代表讓服務器中的資料庫更改我的GPS座標

/device id/OWNER 訊息 "老王"(utf-8編碼的16進位數字) 資料庫中就能變更我的訊息

要做長期統計資料的話，向服務器訂閱就好了，需要的人自己去架服務器寫app

慨念很有意思，就 LASS 設計精神，PM2.5 的情境只是其中之一。而且感測器是移動的，當你移動感測器時，沒有道理還要改 code. 而 LASS 的設計是以 APP 為單位的。另外一個問題點就是多 sensor device 必須送出多筆 MQTT data
多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些
每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少
我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾
篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。
重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code
對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去做？
感謝！ Location Aware Sensing System
好的，我誤解了。以為是ＬＢＳ。
所以ＬＡＳＳ必須自帶ＧＰＳ感應器？
Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾
那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好
有被支援的，不用擔心！這就是 FAKE_GPS 欄位的作用
哪裡有資料格式以及ｔｏｐｉｃ資料可以參考？？？？我沒寫過，但是我一直覺得ｔｏｐｉｃ真的要好好利用，不要把所有的東西全塞在ｐａｙｌｏａｄ（ｍｅｓｓａｇｅ）裡。
如果是用伺服器來接收 device 的資料，需要瞭解總 throughput 是多少、資料是否可以分流到不同的伺服器，是否進行異地備援、是否有現存主機系統適合進行這類的服務。