wot gateway

目前,我的工作是智慧家庭的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

https://ubiworx.com/

 

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

http://www.eclipse.org/kura/

 

而最後,其WOT gateway

Node.js 生態系的介紹。

Node.js 的非同步編程與事件驅動模型。

Node.js 的慣例、錯誤處理、Debug 與 Logging 等等。

傳統與現今的前端開發，有什麼不同。可能會順便聊點 React.js (吧?)。

熱門的通訊協定介紹：主要區分 IP-suite 與 Non-IP-suite 兩類協定。應該會談到各自以 TCP 與 UDP 作為基礎的 MQTT 和 CoAP，還有屬於 PAN 系統的 ZigBee、BLE、Thread，以及 LPWAN 的 LoRa 或 SigFox。

以閘道器模式來將 Non-IP-suite 協定與 Web 接軌

Eclipse 基金會的 IoT Working Group 在提倡什麼。

為什麼走 IP-suite 協定也可能需要閘道器。

Apple HomeKit、Google Brillo (Android Things) 和 Weave 協定想做什麼。

Google 的 Physical Web 在做什麼。

Lightweight Machine-to-Machine (LWM2M) 這個協定又在做什麼。

相容性的問題：應用層資料模型。包含 IPSO 聯盟、OCF 基金會與 Google Weave 的 Schema 在做的事，它們各是由誰主導。

想做周邊裝置設計、想做閘道器或機器網路伺服器，在軟硬體上有什麼樣的選擇。

 

https://speakerdeck.com/hedywings/full-stack-iot-development-yi-ble-zha-dao-qi-dai-lai-de-quan-xin-kai-fa-mo-shi-wei-li