準備跟 Smart Phone 說分手？淺談 BLE 開發模式

作者：Hedy

一、 前言

　　在這個大家都說物聯網即將爆發的時代，Bluetooth Low Energy (BLE) 在眾多的通訊協定中，無疑也是很重要的一環，特別因為它的低功耗特性以及可以很容易跟手機、平板搭配的緣故，始終讓它在眾多近距離無線通訊技術中佔有一席之地。

　　就我自己的觀察，目前市面上的 BLE 裝置普及率並不如我想像中的高，比較常看到或聽到的就是一些穿戴式裝置，像是運動手環或智慧手錶等等，而且現在看來，這些穿戴式裝置也並不如預期那樣熱銷 (新聞：Jawbone 宣布退出市場)。其他像智慧家庭那類的應用，在這個講求生態系的時代，BLE 極具彈性的資料模型卻傷害了產品間的相容性，各家的產品幾乎都是各玩各的，這間接導致 BLE 在智慧家庭應用中逐漸走入困境。接下來，我想要從 BLE 開發模式切入，來探討 BLE 想要進入物聯網需跨越的門檻。

二、 淺談 BLE 開發模式

　　在開始之前，我先粗淺地介紹 BLE 的連線架構。在 BLE 協定中，一個 connection 有兩種角色，分別是 central 和 peripheral。一般 BLE peripheral 經常作為周邊裝置，像智慧手環、手錶或各類 sensor 等，而 BLE central 則是負責管理、控制連入的 peripheral 裝置。

　　這裡我簡略地將 BLE 的開發方式區分成以下三種模式。不同的開發方式，有著不同的應用適用類型：

• 純嵌入式開發
• 通常用於周邊節點開發，或是單純點對點(例如開關對電燈的應用：gecko switch)
• 手機 App 開發
• 適合以個人為中心的應用，像是智慧手環、手錶、運動配件等等，這例子就太多了。另外，以手機控制智慧插座、電燈這一類的應用，也不算少見
• 以 BLE gateway 為中心的應用開發
• 適合小型區域網路，像是智慧家庭、工廠自動化。此種模式通常是將 BLE 轉換為 RS485 或 WiFi，再轉進另一頭的服務器，這種情況下 gateway 其實就是很單純的 bridge 而已。另一種可以跑應用的，就如 「XX 盒子」 那一類的東西，或許把它們稱為 gateway 也可以，畢竟有些可以上雲端或透過 IFTTT 之類的服務來控制。不過，在比較細節上來講，開發手法會比較像手機那種方式(特別是 XX 盒子很多都是基於 Android 下去做修改的阿)

1. 嵌入式開發

　　第一種開發模式，就是將藍芽應用建立於嵌入式板子上面，通常各家 IC vendor 會提供一套完整的 SDK 和開發板，幫助使用者能很快速地開發應用。像 TI CC2540 Development Kit 或是 CSR Bluetooth Smart Starter Development Kit，都是很完整的開發套件。

　　這種開發方式是最底層的一種，在大部分的情況下，你需要用 C/C++ 語言去改寫 firmware，操作硬體資源，以完成你的應用。通常你的藍芽周邊裝置 (BLE Peripheral) 都是這樣實作出來的。多數情況，周邊裝置不需要太多資源，像是一個溫度感測器，只需要一個很簡單的板子，上面有藍芽晶片和一些 I/O，可以讀取溫度值，並透過藍芽協定無線傳送出去，工作就完成了。

　　當然你也可以用這種方式開發 central 端，但除非是很簡單的應用，否則應該是很少人這樣做，因為 central 端要負責和裝置的連線、讀/寫等等，若是同時要控制多個裝置，單靠一些簡單的硬體設備(例如以按鈕操作)，使用的難度會比較高，所以多少會搭配比較友善的 GUI 介面來輔助。另一方面，若以前端工程師的角度來看，可能會比較不知道從何下手，這種比較靠近底層的開發模式會大幅增加他們開發的難度。

註：有一種使用 Arduino/MCU + 藍芽串列模組(如HC-05/06/08)的模式，我並不把它列為 BLE/Bluetooth 的開發，這只是用「無線」取代了「有線」的 UART，嚴格說起來我不認為這可以算是藍芽的應用開發，因為這中間絲毫沒有用到 GATT 的概念。業界應該是很少看到以這種模式兜出來的藍芽產品，畢竟你把它當 UART 使用，就注定閹割掉 BLE 低耗電的好處了(那還算的上 BLE 嗎？)。我不知道有多少開發者會認同我這樣的想法？

2. 手機 App 開發

　　第二種模式，是透過手機去開發藍芽應用程式，這種模式是目前最常見也最普遍的一種做法。

　　使用手機開發的好處是在於，現在大部分的手機都內建有藍芽晶片，而 Android 或 iOS 作業系統又都有提供和底層藍芽晶片溝通的 Library，因此開發者不用再擔心與藍芽晶片溝通的問題，也可以在手機這個容器裡很快速地開發出一套帶有美美 GUI 的 app。另一方面，開發者透過手機，可以很輕易地將藍芽裝置連上 Internet，以達成物聯網 (或者說「連網物」) 的功能，簡單快速，大多數的開發者都是以這種模式去搭建藍芽應用。

　　但是這種模式有一個很大的問題，就是在大部分的情況下，手機無法一直處在周邊裝置旁邊。若是手機必須一直跟藍芽裝置對連才能控制或監測它們，那就會大大限制住藍芽應用的使用範圍。另外，還有一個大家很常問的問題：「我應該如何說服使用者，讓他們把手機的藍芽(一直)打開呢？」。相較於單純的「連網物」，物聯網場景應該是周邊裝置能夠自動上網，然後接受某種形式的管理，並且在一個區域網路內擁有自己的行為，最終以構成服務為目的。此外，使用者應該要能隨時隨地(從外部)連網進來或透過雲端服務來觀察或控制那些裝置，而不是時時刻刻都必須待在裝置旁邊才能操作它們。

　　以上問題大概是要以 BLE 投入物聯網產品體系時，比較令人擔心的點。反過來說，為什麼目前藍芽多見於穿戴式這種可以長時間與手機保持貼近的應用，因為就很適合那樣的情境呀！

3. 以 BLE Gateway 為中心的應用開發

　　如上述所說，以往 BLE 的使用場景，往往是藍芽設備必須連接手機才能被控制或存取。例如具有 BLE 介面的溫、濕度感測器，多需要搭配安裝在智慧手機上的特定 App，才能將監測資料傳到雲端，這種模式對於 BLE 在物聯網的發展會非常不利。我會在下一節討論產品相容性的問題。

　　為了讓遠端使用者可以透過 Internet 連線至本地端藍芽裝置，進行遠端操控或監測，一台 BLE gateway 是不可或缺的，它可以將藍芽智慧設備連接到網際網路而不需要手機的參與，是遠端使用者和本地端藍芽裝置間溝通的橋梁。 

　　目前 BLE gateway 的做法大多是將藍芽封包轉換成 Wi-Fi，達成裝置連網的功能。以德州儀器的 Bluetooth Smart-to-Wi-Fi Gateway solution 為例，就是採用 Wi-Fi 模組 CC3200 配合 BLE CC2640 組合成一個簡單的 Gateway，這個 Gateway 主要是利用 MQTT 協定去遠端存取 gateway，藉此操作連接到 gateway 的藍芽裝置 (gateway 作為這些裝置們的 reverse proxy)。

　　透過 gateway，你就可以搭建一個小型的區域網路，並將網內的裝置都接上 Internet，完成物聯網應用。以智慧家庭為例，只要將家裡那些藍芽裝置連上 gateway，像溫溼度、煙霧感測器或電燈開關，使用者便可以在任何位置連線家中的 BLE 裝置，進行遠端控制或獲得資訊。 這不僅提高便利性，也擴展 BLE 在物聯網的應用功能。只不過，雖然在通訊方面已經內外打通了，但這種方式還是沒有解決產品間相容性的問題，每一家公司的產品可能都有自己的做法，整個 BLE 產品生態系同樣還是破碎化的狀態 (整個物聯網已經夠破碎了)。

三、相容性

　　BLE 的資料模型是基於 ATT/GATT 的，簡單來說，就是一個 BLE 裝置所帶有的屬性資料 (attributes) 是一條一條被記錄在一張表當中，資料如何在兩裝置間流動是由 ATT 的 Client/Server 模型所定義，而 GATT 則是定義了屬性(資料)的組織方式。SIG 定義了許多 UUIDs (Universally Unique Identifiers)，用來表示不同的 Characteristics 與 Services，也提供開發者定義自己私有的 UUID。為了讓文章保持簡單，我在這裡就此打住，先做一個簡單的總結：「開發者可以挑選這些 SIG 所定義好的和私有的 UUIDs，自由混合以組成描述裝置所需要的資料體。這為開發帶來了極高的彈性。」

　

　　這樣的彈性是雙面刃，在某些情況用起來確實很棒，但是在某些情況卻因為這樣的彈性而犧牲了產品間的相容性(因為各家公司的做法都不一樣)。就如同 BIPSO 官網上的例子：

當你買 A 公司的燈泡，智慧手機也裝了 A 公司提供的 App；哪一天你想換 B 公司的燈泡，結果你還是會被強迫裝 B 公司的 App。因為你不能用 A 公司的軟體去控制 B 公司的電燈。然後一個選擇 BLE 智慧家庭系列產品的消費者，不是被一家公司給綁死，就是被手機裡一堆 Apps 給煩死! XDDD

註：雖然 SIG 有定義一些 Public 的 Profiles 給開發者參考，但說實在，它們還是不足以應付物聯網世界中的多樣性 (Profile 是針對很特定應用的規範，內容制定的非常的細，包含裝置行為都囊括在內)。我想沒有人做一個 BLE 智慧插座會去找 SIG Profile 來跟著實作，況且也沒有智慧插座這種 Profile 可以用 XDD。 BLE 在這方面，比起 ZigBee 的 Clusters 或 IPSO 的 Smart Objects，我覺得真的是比較弱。

　　我個人認為，各家想以 BLE 開發產品的公司都必須好好深思相容性這個問題，如果產品的對象是普羅大眾，那麼想要建立自家（私有的）產品系統所帶來的結果可能會很兩極，要嘛就很多人用，要嘛就很少人用，很難均勻地散布於市場之中。當然，如果產品鎖定的是某一類特殊族群，那就另當別論了。說到底，同樣能做好一件事，為何不選擇相容性最好的做法？經過多年的戰爭與對峙，以往壁壘分明的物聯網體系目前也正在朝相容的路線發展。豈能 BLE 產品的世界，自己跟自己就不相容了，那不是很怪嗎？

　　大家可能會認為，因為我是 BIPSO 的作者，所以才會特別鼓吹相容性的重要性。好啦，或許是有一點啦，哈哈。 但不管我有沒有做 BIPSO，相容性本來就是我目前工作需要去解決的問題。BIPSO 因為解決問題而誕生，我就順便把它公開，然後想不到就這樣被 IPSO 官方給收錄了，我也很驚訝，只能說一切都是緣分啦！不過，我相信 BIPSO 應該還算有點價值，不然也不會受到 IPSO 官方青睞。但說真的，大部分的功勞都是制定 IPSO 標準的人，BIPSO 僅僅是踩在巨人的肩膀上，尋求更好的解決方案而已。小妹只是來沾沾光的XDD

四、結語

　　BLE gateway 雖然可以解決 BLE 要進入物聯網的一些難處，只不過沒有辦法像使用手機開發一樣那麼方便。再說，就算以 gateway 為中心來進行開發，仍然會遇到產品間不相容的問題，BLE 產品自身的破碎化同樣沒有獲得解決。

　　另一方面，gateway 的實作大都是將藍芽封包橋接到網際網路，裝置之間無法互相溝通，例如當溫度太高時自動開啟電風扇，都需要外部控制，若是想要在 gateway 上寫一套自動化應用，又需要改寫韌體，對應用開發者來說有一定的門檻。因此，大部分的開發者還是會選擇用手機去開發。不過呢！現在有個好消息，那就是 SIG 今年發表了基於 Node.js 的 BLE gateway 開發工具，我覺得這是 SIG 對 BLE 進入物聯網世界所做出的積極回應，真的很棒～～ 不過，這說起來也有點心酸啊… 因為早在 SIG 發表之前，就已經有這樣的 gateway 開源解決方案 ble-shepherd 了 (也是不才小妹我的專案，嗚嗚，只是好像都沒被注意到啊!! 算一算也弄了 1 年了說)。

　　SIG 的方案跟 ble-shepherd 一樣都是基於 noble，不過 ble-shepherd 還額外支援了 TI 的 CC254X 系列晶片(基於 cc-bnp，應該也是能支援 CC26XX，不過我目前手邊沒有 TI 的板子可以測試)。此外，ble-shepherd 也原生支援 BIPSO 規範！

　　SIG 方案的好處是，它有提供 10 幾支 RESTful APIs 跟 Client  端的 web 頁面範例給你用，我想這應該是給系統廠使用的懶人包吧！ㄎㄎ 身為一個 full-stack 工程師，那些東西應該會比較想要自己動手弄吧。 哎呀～反正都是基於 Node.js，不管用哪一個我都推薦啦！

　

　　這篇文章說到這裡，除了分享一點我在 BLE 應用開發的看法之外，最後的結語是想提醒大家，從今年 SIG 官方拋出 gateway solution 開始，BLE 的應用或開發模式在未來兩三年可能會出現很大的變化 (想當初某組織好像還很不屑需要閘道器的 solution 啊… XDD)。還有還有，Node.js 也是很大的重點，不僅是 SIG 官方，連 Intel 的 Home Gateway 也是跑 Node.js 啊。雖然小妹我是 Node的頭號大粉絲，話可能說的有點誇大，不過環顧周遭(包含開發環境、工具、雲端服務等等)，Node 好像是出來普渡眾生的啊。

　

　　當然除了上述所說的，還有一些其他的問題要克服，像是連線數的問題(這可能要等到 BLE Mesh 技術正式發布才有解了…)，這部分就等到之後有機會再討論吧！！ 不管如何，希望台灣科技產業在 BLE 與 Node.js 這方面，也能很快嗅到新的機會，當然也很希望能看到比較老字號的公司之類的，能夠大方擁抱 Node.js。(疑？怎麼好像變成一篇在推廣 Node.js 的文章了！？ 哈哈，那就先這樣吧 XDD 下次再聊！)

　

　

　

關於作者

王雅慧

Facebook

GitHub

　

一個 Node.js 的忠實粉絲，台灣若有 Node Girls 的活動拜託一定要找，哈哈哈...