Proposal of new LASS data format (under discussion)

編輯歷史

時間	作者	版本
2016-03-04 03:02 – 03:04	Chi-Hsiu Liang	r1364 – r1377
顯示 diff （106 行未修改）有被支援的，不用擔心！這就是 FAKE_GPS 欄位的作用哪裡有資料格式以及ｔｏｐｉｃ資料可以參考？？？？我沒寫過，但是我一直覺得ｔｏｐｉｃ真的要好好利用，不要把所有的東西全塞在ｐａｙｌｏａｄ（ｍｅｓｓａｇｅ）裡。 + 如果是用伺服器來接收 device 的資料，需要瞭解總 throughput 是多少、資料是否可以分流到不同的伺服器，是否進行異地備援、是否有現存主機系統適合進行這類的服務。 +
2016-03-03 07:00	cclljj@gmail.com	r1363
顯示 diff （108 行未修改）
2016-02-26 13:37 – 14:28	wuulong sheu	r1316 – r1362
顯示 diff （9 行未修改）針9:15 - 9:30 對在 FB 建議的事項討論嘗9:30 - 10:00 試下出結論 - * - 結論 - - 目前可能有以下的結論，最後會表決 - MQTT length 在 device 端，長度限制由 512 改到 14xx, device 盡可能支援，有不能支援的 device, 未來再討論作法（哈爸改 LinkItONE library 的支援, 科大改 Ameba 的支援） - - Meta Data都有歷史紀錄可以查（可以給 JSON api）如果沒有更新就以最新的一次更新為準 - 不分 dynamic/static + 結論：表決通過 - 在前述修改的情況下，同意 LJ 的提案 - LJ 有空會提 mata data 格式的建議緣由 + 經熱烈的溝通與討論，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長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（85 行未修改）
2016-02-26 13:31 – 13:33	Tzu-Te Wang	r1289 – r1315
顯示 diff （108 行未修改）那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好有被支援的，不用擔心！這就是 FAKE_GPS 欄位的作用 + *哪裡有資料格式以及ｔｏｐｉｃ資料可以參考？？？？我沒寫過，但是我一直覺得ｔｏｐｉｃ真的要好好利用，不要把所有的東西全塞在ｐａｙｌｏａｄ（ｍｅｓｓａｇｅ）裡。
2016-02-26 13:13 – 13:27	wuulong sheu	r1217 – r1288
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 在 device 端，長度限制由 512 改到 14xx + MQTT length 在 device 端，長度限制由 512 改到 14xx, device 盡可能支援，有不能支援的 device, 未來再討論作法（哈爸改 LinkItONE library 的支援, 科大改 Ameba 的支援） Meta Data都有歷史紀錄可以查（可以給 JSON api）如果沒有更新就以最新的一次更新為準 * - 不分 dynamic/static緣由 + 不分 dynamic/static + + 在前述修改的情況下，同意 LJ 的提案 + + LJ 有空會提 mata data 格式的建議緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:12	(unknown)	r1216
顯示 diff （106 行未修改）
2016-02-26 13:12 – 13:12	Jhih-Cyuan Shen	r1214 – r1215
顯示 diff （94 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - 要不就是 topic改成　/country code/state code/area (city) coode/LASS/device_id/t - /"，大量訂閱時，沒有的資料不會出現我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾 *篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。（8 行未修改）
2016-02-26 13:11 – 13:12	Tzu-Te Wang	r1205 – r1213
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不用具備ＲＴＣ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不用具備ＲＴＣ。小硬體可以參考取到的時間，上報資料時將ｔｉｍｅｓｔａｍｐ附上。3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11 – 13:11	wuulong sheu	r1200 – r1204
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這就是 GPS_OP + 有被支援的，不用擔心！這就是 FAKE_GPS 欄位的作用
2016-02-26 13:11 – 13:11	Tzu-Te Wang	r1197 – r1199
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不用具ㄅ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不用具備ＲＴＣ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1196
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這就是 GPS_OPT + 有被支援的，不用擔心！這就是 GPS_OP
2016-02-26 13:11	Tzu-Te Wang	r1195
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不用ㄐㄩ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不用具ㄅ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1194
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這就是 GPS_ + 有被支援的，不用擔心！這就是 GPS_OPT
2016-02-26 13:11	Tzu-Te Wang	r1193
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不用3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不用ㄐㄩ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1192
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這就是 GP + 有被支援的，不用擔心！這就是 GPS_
2016-02-26 13:11	Tzu-Te Wang	r1191
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不ㄩ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不用3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1190
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這就是 + 有被支援的，不用擔心！這就是 GP
2016-02-26 13:11	Tzu-Te Wang	r1189
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備不3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不ㄩ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1188
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！這ㄐㄧㄡ + 有被支援的，不用擔心！這就是
2016-02-26 13:11	Tzu-Te Wang	r1187
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，設備ㄅ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備不3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:11	wuulong sheu	r1186
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用擔心！ + 有被支援的，不用擔心！這ㄐㄧㄡ
2016-02-26 13:10 – 13:11	Tzu-Te Wang	r1178 – r1185
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間，3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，設備ㄅ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10 – 13:10	wuulong sheu	r1175 – r1177
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被支援的，不用 + 有被支援的，不用擔心！
2016-02-26 13:10	Tzu-Te Wang	r1174
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時間3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間，3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10 – 13:10	wuulong sheu	r1171 – r1173
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被知ㄩㄢ + 有被支援的，不用
2016-02-26 13:10 – 13:10	Tzu-Te Wang	r1169 – r1170
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱時ㄐ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時間3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1168
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被 + 有被知ㄩㄢ
2016-02-26 13:10	Tzu-Te Wang	r1167
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱ㄕ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱時ㄐ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1166
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有被ㄗ + 有被
2016-02-26 13:10	Tzu-Te Wang	r1165
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器訂閱3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱ㄕ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1164
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - 有 + 有被ㄗ
2016-02-26 13:10	Tzu-Te Wang	r1163
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器定ㄩㄝ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器訂閱3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1162
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - * + *有
2016-02-26 13:10	Tzu-Te Wang	r1161
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器定3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器定ㄩㄝ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1160
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - u. +
2016-02-26 13:10	Tzu-Te Wang	r1159
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器ㄉㄧㄥ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器定3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1158
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - u + u.
2016-02-26 13:10	Tzu-Te Wang	r1157
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器ㄉㄧ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器ㄉㄧㄥ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1156
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - * + *u
2016-02-26 13:10	Tzu-Te Wang	r1155
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向服務器3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器ㄉㄧ3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10 – 13:10	wuulong sheu	r1153 – r1154
顯示 diff （108 行未修改）
2016-02-26 13:10	Tzu-Te Wang	r1152
顯示 diff （71 行未修改）可參考研究筆記 - 資料時間 - 我建議向3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 我建議向服務器3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（32 行未修改）
2016-02-26 13:10	wuulong sheu	r1151
顯示 diff （105 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 + *
2016-02-26 13:10 – 13:10	Tzu-Te Wang	r1148 – r1150
顯示 diff （70 行未修改） 2. 不需要加上時間，服務器上就有時間了，最多就是紀錄最後更新的時間 - 可參考研究筆記 - 資料時間3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 + 可參考研究筆記 - 資料時間 + 我建議向3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題（31 行未修改）
2016-02-26 13:08 – 13:10	wuulong sheu	r1140 – r1147
顯示 diff （14 行未修改）目前可能有以下的結論，最後會表決 MQTT length 在 device 端，長度限制由 512 改到 14xx - 緣由 + + Meta Data都有歷史紀錄可以查（可以給 JSON api）如果沒有更新就以最新的一次更新為準 + * + 不分 dynamic/static緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:06 – 13:06	Tzu-Te Wang	r1138 – r1139
顯示 diff （101 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 - *
2016-02-26 13:05 – 13:05	wuulong sheu	r1124 – r1137
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 在 device 端緣由 + MQTT length 在 device 端，長度限制由 512 改到 14xx + 緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（85 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1123
顯示 diff （100 行未修改） Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好 + *
2016-02-26 13:05 – 13:05	wuulong sheu	r1121 – r1122
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 在 devi緣由 + MQTT length 在 device 端緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1118 – r1120
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標ㄐㄧ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標就好
2016-02-26 13:05	wuulong sheu	r1117
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 在 d緣由 + MQTT length 在 devi緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1116
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標ㄐㄧ
2016-02-26 13:05	wuulong sheu	r1115
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 在緣由 + MQTT length 在 d緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1111 – r1114
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳㄗㄨ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ座標
2016-02-26 13:05	wuulong sheu	r1110
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length 緣由 + MQTT length 在緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1109
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳㄨ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳㄗㄨ
2016-02-26 13:05	wuulong sheu	r1108
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT length緣由 + MQTT length 緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1107
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳㄨ
2016-02-26 13:05 – 13:05	wuulong sheu	r1105 – r1106
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQTT l緣由 + MQTT length緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1104
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳｙ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ
2016-02-26 13:05	wuulong sheu	r1103
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - MQT緣由 + MQTT l緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1102
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳｙ
2016-02-26 13:05 – 13:05	wuulong sheu	r1100 – r1101
顯示 diff （13 行未修改）目前可能有以下的結論，最後會表決 - 緣由 + MQT緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1098 – r1099
顯示 diff （99 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的ＧＰＳ
2016-02-26 13:05	wuulong sheu	r1097
顯示 diff （12 行未修改）結論 - 目前可能有以下的結論，最後會表決緣由 + 目前可能有以下的結論，最後會表決 + 緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1096
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上抱自己的 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自己的
2016-02-26 13:05 – 13:05	wuulong sheu	r1091 – r1095
顯示 diff （12 行未修改）結論 - 目前可能有以下的結論，最ㄏㄡ緣由 + 目前可能有以下的結論，最後會表決緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1090
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上爆自己ㄉㄜ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上抱自己的
2016-02-26 13:05	wuulong sheu	r1089
顯示 diff （12 行未修改）結論 - 目前可能有以下的結論，ㄗ緣由 + 目前可能有以下的結論，最ㄏㄡ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1088
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自ㄐㄧ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上爆自己ㄉㄜ
2016-02-26 13:05	wuulong sheu	r1087
顯示 diff （12 行未修改）結論 - 目前可能有以下的結論，緣由 + 目前可能有以下的結論，ㄗ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1086
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自ㄐㄧ
2016-02-26 13:05	wuulong sheu	r1085
顯示 diff （12 行未修改）結論 - 目前可能有以下的結論緣由 + 目前可能有以下的結論，緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1084
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報自
2016-02-26 13:05	wuulong sheu	r1083
顯示 diff （12 行未修改）結論 - 目前可能有以下的結ㄌㄨㄣ緣由 + 目前可能有以下的結論緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1082
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上ㄅㄠ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上報
2016-02-26 13:05	wuulong sheu	r1081
顯示 diff （12 行未修改）結論 - 目前可能有以下的結緣由 + 目前可能有以下的結ㄌㄨㄣ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1080
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上ㄅㄠ
2016-02-26 13:05	wuulong sheu	r1079
顯示 diff （12 行未修改）結論 - 目前可能有以下的緣由 + 目前可能有以下的結緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1078
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機ㄕㄤ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機上
2016-02-26 13:05	wuulong sheu	r1077
顯示 diff （12 行未修改）結論 - 目前可能有以下ㄉ緣由 + 目前可能有以下的緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1076
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機ㄕㄤ
2016-02-26 13:05	wuulong sheu	r1075
顯示 diff （12 行未修改）結論 - 目前可能有已緣由 + 目前可能有以下ㄉ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1074
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用手 + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手機
2016-02-26 13:05	wuulong sheu	r1073
顯示 diff （12 行未修改）結論 - 目前可能有ㄧ緣由 + 目前可能有已緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1072
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，用ㄕ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用手
2016-02-26 13:05	wuulong sheu	r1071
顯示 diff （12 行未修改）結論 - 目前可能ㄧ緣由 + 目前可能有ㄧ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1070
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，ㄩㄥ + 那還好，有救，手機安裝ＭＱＴＴ軟體，用ㄕ
2016-02-26 13:05	wuulong sheu	r1069
顯示 diff （12 行未修改）結論 - 目前可ㄋ緣由 + 目前可能ㄧ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1068
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體， + 那還好，有救，手機安裝ＭＱＴＴ軟體，ㄩㄥ
2016-02-26 13:05	wuulong sheu	r1067
顯示 diff （12 行未修改）結論 - 目前ㄎㄜ緣由 + 目前可ㄋ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1066
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，自 + 那還好，有救，手機安裝ＭＱＴＴ軟體，
2016-02-26 13:05	wuulong sheu	r1065
顯示 diff （12 行未修改）結論 - 目ㄑㄧㄢ緣由 + 目前ㄎㄜ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1064
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，自己 + 那還好，有救，手機安裝ＭＱＴＴ軟體，自
2016-02-26 13:05	wuulong sheu	r1063
顯示 diff （12 行未修改）結論 - 目ㄑ緣由 + 目ㄑㄧㄢ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1062
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，自己上 + 那還好，有救，手機安裝ＭＱＴＴ軟體，自己
2016-02-26 13:05 – 13:05	wuulong sheu	r1059 – r1061
顯示 diff （12 行未修改）結論 - 目ㄑㄧㄢ緣由 + 目ㄑ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1058
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體，自己ㄕ + 那還好，有救，手機安裝ＭＱＴＴ軟體，自己上
2016-02-26 13:05	wuulong sheu	r1057
顯示 diff （12 行未修改）結論 - 緣由 + 目ㄑㄧㄢ緣由目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1051 – r1056
顯示 diff （98 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ軟體 + 那還好，有救，手機安裝ＭＱＴＴ軟體，自己ㄕ
2016-02-26 13:05 – 13:05	wuulong sheu	r1049 – r1050
顯示 diff （11 行未修改） * 結論 - 緣由 + + 緣由目前的 MQTT message長度已經到達極限 *長度還可以延伸，請問為何說已到極限？（84 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1046 – r1048
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ + 那還好，有救，手機安裝ＭＱＴＴ軟體
2016-02-26 13:05	wuulong sheu	r1045
顯示 diff （100 行未修改）
2016-02-26 13:05 – 13:05	Tzu-Te Wang	r1040 – r1044
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴｂｊ０３ + 那還好，有救，手機安裝ＭＱＴＴ
2016-02-26 13:05	wuulong sheu	r1039
顯示 diff （10 行未修改）嘗9:30 - 10:00 試下出結論 - 節ㄌㄨ + 結論緣由 *目前的 MQTT message長度已經到達極限（85 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1038
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴｂ + 那還好，有救，手機安裝ＭＱＴＴｂｊ０３
2016-02-26 13:05	wuulong sheu	r1037
顯示 diff （10 行未修改）嘗9:30 - 10:00 試下出結論 - + 節ㄌㄨ緣由 *目前的 MQTT message長度已經到達極限（85 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1036
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱＴＴ + 那還好，有救，手機安裝ＭＱＴＴｂ
2016-02-26 13:05 – 13:05	wuulong sheu	r1032 – r1035
顯示 diff （100 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1031
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - 那還好，有救，手機安裝ＭＱ + 那還好，有救，手機安裝ＭＱＴＴ
2016-02-26 13:05	wuulong sheu	r1030
顯示 diff （9 行未修改）針9:15 - 9:30 對在 FB 建議的事項討論嘗9:30 - 10:00 試下出結論 - * * + 緣由 *目前的 MQTT message長度已經到達極限（85 行未修改）
2016-02-26 13:05	Tzu-Te Wang	r1029
顯示 diff （97 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 - * + *那還好，有救，手機安裝ＭＱ
2016-02-26 13:05	wuulong sheu	r1028
顯示 diff （9 行未修改）針9:15 - 9:30 對在 FB 建議的事項討論嘗9:30 - 10:00 試下出結論 + * * 緣由（86 行未修改）
2016-02-26 13:04	Tzu-Te Wang	r1027
顯示 diff （96 行未修改）所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾 + *
2016-02-26 13:03 – 13:03	wuulong sheu	r1005 – r1026
顯示 diff （95 行未修改）好的，我誤解了。以為是ＬＢＳ。所以ＬＡＳＳ必須自帶ＧＰＳ感應器？ + *Optional, 固定型的可以不用 GPS, 但是還是件義傳上 GPS informaton (寫死的)不要造成後端分析的困擾
2016-02-26 13:01 – 13:02	Tzu-Te Wang	r990 – r1004
顯示 diff （93 行未修改）對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去做？感謝！ Location Aware Sensing System + 好的，我誤解了。以為是ＬＢＳ。 + 所以ＬＡＳＳ必須自帶ＧＰＳ感應器？
2016-02-26 13:00 – 13:00	wuulong sheu	r975 – r989
顯示 diff （92 行未修改）重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去做？ - 感謝！ + 感謝！ Location Aware Sensing System
2016-02-26 12:59	Tzu-Te Wang	r974
顯示 diff （91 行未修改）篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code - 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去 + 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去做？ *感謝！
2016-02-26 12:59	wuulong sheu	r973
顯示 diff （92 行未修改）重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去 - * + *感謝！
2016-02-26 12:59	Tzu-Te Wang	r972
顯示 diff （91 行未修改）篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code - 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ + 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ可以讓服務器去 *
2016-02-26 12:59	wuulong sheu	r971
顯示 diff （92 行未修改）重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ + *
2016-02-26 12:57 – 12:59	Tzu-Te Wang	r954 – r970
顯示 diff （91 行未修改）篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code - 對齁！ + 對齁！我只想到固定式的裝備。移動的。。。其實沒想法。不過，那並不需要改ｃｏｄｅ，改ｔｏｐｉｃ
2016-02-26 12:55 – 12:55	wuulong sheu	r945 – r953
顯示 diff （90 行未修改）我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。 - 重點是 device 移動的時候，是不能改 code 的。 + 重點是 device 移動的時候，是不能改 code 的。比方說台北宜到新竹是不能改 code, 出國也不能改 code *對齁！
2016-02-26 12:55 – 12:55	Tzu-Te Wang	r943 – r944
顯示 diff （91 行未修改）篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。重點是 device 移動的時候，是不能改 code 的。 + *對齁！
2016-02-26 12:55 – 12:55	wuulong sheu	r932 – r942
顯示 diff （90 行未修改）我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。 + *重點是 device 移動的時候，是不能改 code 的。
2016-02-26 12:53 – 12:54	Tzu-Te Wang	r920 – r931
顯示 diff （89 行未修改） /"，大量訂閱時，沒有的資料不會出現我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾 + 篩選資料（感應器）時很有用。靠ＧＰＳ若要去計算某個區域裡的平均值會很累。
2016-02-26 12:51 – 12:52	wuulong sheu	r893 – r919
顯示 diff （88 行未修改）要不就是 topic改成　/country code/state code/area (city) coode/LASS/device_id/t /"，大量訂閱時，沒有的資料不會出現 + 我個人覺得在 topic 中說明在哪裡是沒有太大意義，複雜了 topic, 也讓同一個 APP 的接收造成困擾
2016-02-26 12:47 – 12:50	Tzu-Te Wang	r825 – r892
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - ㄧ奧ㄅㄨ + 要不就是 topic改成　/country code/state code/area (city) coode/LASS/device_id/t + /"，大量訂閱時，沒有的資料不會出現
2016-02-26 12:47	wuulong sheu	r824
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 sensor 存 + sensor 資料週期上傳，就知道 sensor 存在 Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r823
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - ㄧ + ㄧ奧ㄅㄨ
2016-02-26 12:47	wuulong sheu	r822
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 sensor + sensor 資料週期上傳，就知道 sensor 存 Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r821
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - * + *ㄧ
2016-02-26 12:47	wuulong sheu	r820
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 sensor + sensor 資料週期上傳，就知道 sensor Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r819
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - y +
2016-02-26 12:47	wuulong sheu	r818
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 sens + sensor 資料週期上傳，就知道 sensor Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r817
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - y9 + y
2016-02-26 12:47	wuulong sheu	r816
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 e + sensor 資料週期上傳，就知道 sens Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r815
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - y94 + y9
2016-02-26 12:47	wuulong sheu	r814
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 - sensor 資料週期上傳，就知道 + sensor 資料週期上傳，就知道 e Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新*dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（58 行未修改）
2016-02-26 12:47 – 12:47	Tzu-Te Wang	r812 – r813
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 - * + *y94
2016-02-26 12:47 – 12:47	wuulong sheu	r810 – r811
顯示 diff （26 行未修改）測試在線的話，服務器(或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 量測值（58 行未修改）
2016-02-26 12:47	Tzu-Te Wang	r809
顯示 diff （86 行未修改）多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少 + *
2016-02-26 12:45 – 12:47	wuulong sheu	r760 – r808
顯示 diff （26 行未修改）測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 + sensor Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（54 行未修改）慨念很有意思，就 LASS 設計精神，PM2.5 的情境只是其中之一。而且感測器是移動的，當你移動感測器時，沒有道理還要改 code. 而 LASS 的設計是以 APP 為單位的。另外一個問題點就是多 sensor device 必須送出多筆 MQTT data 多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些 + *每個 APP 就有定義哪些 sensor 在上面，基本上一個 APP 是一種情境。舉例，簡單的情況下，AP=PM25 一定就是 Field try 的 sensor, 不會多，也不會少
2016-02-26 12:45 – 12:45	Tzu-Te Wang	r758 – r759
顯示 diff （83 行未修改）慨念很有意思，就 LASS 設計精神，PM2.5 的情境只是其中之一。而且感測器是移動的，當你移動感測器時，沒有道理還要改 code. 而 LASS 的設計是以 APP 為單位的。另外一個問題點就是多 sensor device 必須送出多筆 MQTT data - 多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一 + *多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一能想到就是當meta自己更新自己的"性能"有哪些
2016-02-26 12:45	wuulong sheu	r757
顯示 diff （86 行未修改）
2016-02-26 12:36 – 12:44	Tzu-Te Wang	r699 – r756
顯示 diff （24 行未修改）可靠性感覺很難劃分,資料分析的時候再剔除感覺比較好一點,感應器種類真的需要加如果只是要測試連線的話,似乎可以設計一個特殊封包去Activate裝置,在裝置丟出這封包前都不算是有註冊的Sensor + + 測試在線的話，服務器(或APP)向 "/device_id/ECHONOW" 發訊息，device收到訊息回彈至 "/device_id/IMHERE" 訊息內容相同。 Meta data 需要支援 Online update（由 device 上傳）以及 Offline update (由 user update, 或是 server update), 目的是支援 meta data 可以需要的規格或是值得更新dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值（34 行未修改）可參考研究筆記 - 資料時間3. GPS不要在MQTT裡傳送，採用device id (unique)對應至GPS-->寫進資料庫，隱私考量 - 理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題4. + 理解隱私性考量，但是在移動感測時，需要 GPS 的資料。另外是 LASS ( Location aware .. ), 所以建議是要傳 GPS. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題 + 贊同，GPS資料就當retain message方式處理，有更動自己update。 + 4. 建議的Topic格式: /國碼(例如886)/區碼(02)/LASS/device id(HEX)/感應器類別(例如T0)/資料數值(十六進制, IEEE754標準) （12 行未修改）慨念很有意思，就 LASS 設計精神，PM2.5 的情境只是其中之一。而且感測器是移動的，當你移動感測器時，沒有道理還要改 code. 而 LASS 的設計是以 APP 為單位的。另外一個問題點就是多 sensor device 必須送出多筆 MQTT data + 多筆不是問題，訂閱者如何知道共有哪幾個sensors在一個device_id上，唯一
2016-02-26 11:41 – 12:33	wuulong sheu	r270 – r698
顯示 diff （2 行未修改） Event 連結 Event - LASS-MQTT 資料格式再進化規格討論 + + Agenda + 8:30 - 8:40 打招呼時間 + 8:40 - 9:00 LJ 針對提案的 proposal, 說明或是 Q&A + 9:針0 - 9:15 對已在 hackpad comment 的部份討論 + 針9:15 - 9:30 對在 FB 建議的事項討論 + 嘗9:30 - 10:00 試下出結論 * 緣由（11 行未修改）可靠性感覺很難劃分,資料分析的時候再剔除感覺比較好一點,感應器種類真的需要加如果只是要測試連線的話,似乎可以設計一個特殊封包去Activate裝置,在裝置丟出這封包前都不算是有註冊的Sensor - dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值 + + 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很容易跑掉 - static value 可當做 heart beat，用以確認感測點仍上線 + + 建議只分 meta data, data (含 dynamic value, static value) 以簡化系統設計static value 可當做 heart beat，用以確認感測點仍上線資料傳輸的頻率: meta data < static value < dynamic value （10 行未修改）基本上是很好的建議，畢竟會大幅更改，所以建議能多討論一些細節，一次改得更完整一點 + + 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. 基本上資料會被畫在地圖上，就算對應表也一樣有隱私性問題4. + 建議的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
2016-02-26 11:32 – 11:37	黃偉峻	r177 – r269
顯示 diff （15 行未修改） meta data描述硬體組成，例如感測器種類，可靠性分類(測試模組中或已穩定運作的佈點等區分) 可靠性分類可利於後續視覺化呈現的優先級別或是資料分析時雜訊的剔除 + 可靠性感覺很難劃分,資料分析的時候再剔除感覺比較好一點,感應器種類真的需要加 + 如果只是要測試連線的話,似乎可以設計一個特殊封包去Activate裝置,在裝置丟出這封包前都不算是有註冊的Sensor dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值 static value 描述短時間內未發生變化的感測值，例如定點的GPS座標 meta data, dynamic value, static value 用 APP 和 device_id 作為 index，每筆資料皆加上傳送時的 timestamp + Timestamp感覺在Server端處裡就好,Device端如果沒有常常校正RTC,timestamp很容易跑掉 static value 可當做 heart beat，用以確認感測點仍上線資料傳輸的頻率: meta data < static value < dynamic value （13 行未修改）
2016-02-23 03:45 – 03:47	Ming Hui Shih	r152 – r176
顯示 diff （8 行未修改）目前看到似乎都是自行限制，最少的也有1K，大的要幾百MB都沒問題，會有問題頂多是處理端有些資料似乎不需要一直傳（例如固定點的 gps 座標） + 建議將固定式與移動式資料分離，以利於後台分析並增加測試區，於開發測試階段使用測試區，區分正式與測試資料 *用sensor id 的方式很不直覺且不利於後端處理（例如 s_t0 s_t1 s_t2 都代表溫度）（22 行未修改）
2016-02-23 03:21 – 03:23	Chun-hsi Tso	r136 – r151
顯示 diff （12 行未修改）提案將資料分為 meta data, dynamic value, static value 三種類別 - meta data描述硬體組成，例如感測器種類 + meta data描述硬體組成，例如感測器種類，可靠性分類(測試模組中或已穩定運作的佈點等區分) + 可靠性分類可利於後續視覺化呈現的優先級別或是資料分析時雜訊的剔除 dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值 static value 描述短時間內未發生變化的感測值，例如定點的GPS座標（16 行未修改）
2016-02-23 02:55 – 02:59	Lanma Chiu	r102 – r135
顯示 diff （6 行未修改）目前的 MQTT message長度已經到達極限長度還可以延伸，請問為何說已到極限？ + 目前看到似乎都是自行限制，最少的也有1K，大的要幾百MB都沒問題，會有問題頂多是處理端有些資料似乎不需要一直傳（例如固定點的 gps 座標）用sensor id 的方式很不直覺且不利於後端處理（例如 s_t0 s_t1 s_t2 都代表溫度）（17 行未修改）和既有的資料格式不相容程式撰寫比較複雜，不同類別的資料要有所區別，且分別進行傳送 + 基本上是很好的建議，畢竟會大幅更改，所以建議能多討論一些細節，一次改得更完整一點
2016-02-23 02:07 – 02:15	wuulong sheu	r90 – r101
顯示 diff Proposal of new LASS data format (under discussion) + Event 連結 + Event - LASS-MQTT 資料格式再進化規格討論 + 緣由 *目前的 MQTT message長度已經到達極限（24 行未修改）
2016-02-23 00:16 – 00:19	wuulong sheu	r77 – r89
顯示 diff （2 行未修改）緣由目前的 MQTT message長度已經到達極限 + 長度還可以延伸，請問為何說已到極限？有些資料似乎不需要一直傳（例如固定點的 gps 座標）用sensor id 的方式很不直覺且不利於後端處理（例如 s_t0 s_t1 s_t2 都代表溫度）（17 行未修改）和既有的資料格式不相容程式撰寫比較複雜，不同類別的資料要有所區別，且分別進行傳送 + + *基本上是很好的建議，畢竟會大幅更改，所以建議能多討論一些細節，一次改得更完整一點
2016-02-21 14:25 – 14:28	cclljj@gmail.com	r1 – r76
顯示 diff - Untitled + Proposal of new LASS data format (under discussion) + + 緣由 + 目前的 MQTT message長度已經到達極限 + 有些資料似乎不需要一直傳（例如固定點的 gps 座標） + 用sensor id 的方式很不直覺且不利於後端處理（例如 s_t0 s_t1 s_t2 都代表溫度） - This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents! + 提案 + 將資料分為 meta data, dynamic value, static value 三種類別 + meta data描述硬體組成，例如感測器種類 + dynamic value 描述短時間內產生變化的感測值，例如PM2.5 量測值 + static value 描述短時間內未發生變化的感測值，例如定點的GPS座標 + meta data, dynamic value, static value 用 APP 和 device_id 作為 index，每筆資料皆加上傳送時的 timestamp + static value 可當做 heart beat，用以確認感測點仍上線 + 資料傳輸的頻率: meta data < static value < dynamic value + + 優點 + 可大幅減少資料傳輸量 + 不再需要一次將所有資料塞在一個 MQTT msg 中 + 若感測器太多，可用多個 mqtt msg 傳送 + 相同的物理性質（例如溫度）可用相同的代號(temperature)，僅需要在 meta-data中敘明感測器型號即可 + + 缺點 + 和既有的資料格式不相容 + 程式撰寫比較複雜，不同類別的資料要有所區別，且分別進行傳送
2016-02-21 14:25	(unknown)	r0
顯示 diff + Untitled + This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!