目前,我的工作是智慧家庭的sensor device及gateway整合.
之前,只是依他們先前的做法實作sensor device(zigbee). 也有在接保全業者的專案.
而我則是主要是朝者gateway方向進行中,就目前只是由vendor提供的sdk去修改.
但是不同的sdk有著不同的gateway stack. 因此相容性一直是問題之一.
以下,是整理
硬體．軟體．物聯網 - (IV) 物聯網閘道器 的內容.
分為二類.IoT Gateway
A.本地端.
“負責管理內網(本地端) 的機器節點”
“本地端的閘道器上可以實作一些自家產品特別的服務或應用程式。”
“拿 MQTT 當例子好了，你可以在 RaspPi 上安裝 Broker (例如使用 Mosquitto 或 Mosca)，區網內的機器 (使用 Paho 或 mqtt.js) 透過本地 Broker 來互動”
自家的雲平台,訊息數據的聚合 (aggregation),提供 RESTful APIs 讓開發者
ubiworx
B.雲端伺服器上，Microsoft (Azure)、Oracle 或 VMWare
"
這有一點像是把雲端服務變成 API Gateway 的味道，但又多了資料儲存與裝置資料模型的定義。其實這樣的方案，最陽春的作法就是在雲端來個 MQTT Broker，機器端則做為 MQTT Client 接入雲端。那麼 topic (或資源存取點) 與資料模型，就隨人自己定義了。因為機器節點可以直接上 Cloud，所以當然就是跑 IP-based 的協定
"
“ 這種雲閘道有個問題，那就是未來物聯網裝置真的開始大爆發時，會相當吃資源，而且網路壅塞也將是個大問題 (對於佈建基礎設施的電信商也許是好消息吧？)，再來就是裝置控制與訊息傳遞即時性也會是個問題。再者，要求所有裝置都走 IP-based 的協定也有點為難大家啊 (跑其他協定的裝置，可以透過一台本地端的閘道器來克服此問題，例如 SIG 官方就有推出 BLE 的閘道器，可以讓 BLE 裝置上雲端)。”
IP-based 的協定,即時性,網路壅塞
遵循標準的 本地跨協定 IoT Gateway 開發框架
統一管理或存取介面Open Mobile Alliance 的 LWM2M (Lightweight Machine-to-Machine)
“LWM2M 定義了一種裝置管理與存取的標準介面，它將自己定義成一種機器網路管理的「應用層」協定。它背後採用了 IP-base 智慧物件 (IP-based Smart Object, IPSO) 作為裝置資料模型，目標是為了讓大家可以將裝置資料抽象成統一的結構，以達到相容的目的”
kura
而最後,其WOT gateway
