一張圖讓你讀懂鵝廠的物聯網架構

本文從物聯網的中心要素、物聯網的關鍵場景、微信硬體平台的通訊協定剖析三個次元去剖析基于微信硬體平台的物聯網架構。

/#%E4%B8%80-%E5%9F%BA%E4%BA%8E%E5%BE%AE%E4%BF%A1%E7%A1%AC%E4%BB%B6%E5%B9%B3%E5%8F%B0%E7%9A%84%E7%89%A9%E8%81%94%E7%BD%91%E6%9E%B6%E6%9E%84%E5%9B%BE 一、基于微信硬體平台的物聯網架構圖

上圖涵蓋以下資訊：

• 基于微信硬體平台的物聯網的架構組成，有微信大衆平台/硬體平台、第三方廠商雲後端、手機微信/大衆号、微信硬體裝置終端（Wifi和藍牙BLE）。
• 綠色代表騰訊向開發者和大衆提供的根底平台和效勞，并經過白色（airsync/airkiss）定義的硬體外設協定供硬體裝置接入，白色（微信硬體平台接入協定，XML/JSON）供廠商雲後端接入；藍牙和紫色區域代表開發者所要完成的義務，其中藍牙是嵌入式硬體裝置終端的義務，紫色是第三方廠商雲後端的義務。
• 物聯網各個組成局部之間的通訊協定辨別。除了白色辨別的協定是微信大衆平台和硬體平台制定的協定必需遵照外，其他組成局部的協定都是自定義的協定。
• Wifi模組的供給商提供的SDK普通都提供socket通訊接口，而雲後端普通會運用JSP/PHP等web程式設計技術，因而wifi裝置需求模仿HTTP協定跟雲終端通訊。HTTP是一個規範的公共的通訊協定，使用層需求在HTTP之上樹立自定義的使用協定來完成裝置的控制和互動，而使用協定可以是XML/JSON等等。當然，假如雲後端運用底層的socket程式設計，則wifi裝置終端可以不需求模仿http。
• 藍牙經過airsync協定接入微信，該協定規則了裝置發現、綁定、登陸、初始化、接納使用者指令、自動發送音訊等程序。
• Airkiss是經過JSAPI的方式讓使用者可以在微信上輸出路由器的使用者名和密碼，然後告知沒有按鍵輸出和螢幕顯示的wifi裝置，讓該裝置可以連上路由器進入網絡線上形态。除此之外，Airkiss跟之後使用者和廠商、裝置的互動完成沒有關系。實質上，Airkiss隻是一個配置上網功用，跟物聯網的控制和互動有關。
• Wifi裝置接入微信硬體平台是遠場控制，裝置隻需處于聯網線上形态，那手機使用者無論在哪裡，隻需能上網都可以對裝置停止控制，典型的例子是在公司下班可以經過手機控制家裡的智能插座上電；藍牙裝置接入微信硬體平台必需依賴于手機，是近場控制，典型的場景是手機控制家裡的燈和空調等。

/#%E4%BA%8C-%E7%89%A9%E8%81%94%E7%BD%91%E7%9A%84%E4%B8%AD%E5%BF%83%E8%A6%81%E7%B4%A0 二、物聯網的中心要素

本文是從開發者的角度去剖析整個微信硬體平台物聯網，不去讨論物聯網營運之類等範疇。那麼，從開發的角度，物聯網的中心要素什麼，微信平台又支援了什麼？我的了解是：

裝置的合法性和獨一性

微信硬體平台在物聯網範疇做的事情其實不多，隻需細心想想架構圖中的這麼多的紫色和藍色都是留給開發者，而且都是要光秃秃的程式設計。關于普通的裝置商，他們想接入也是勉爲其難啊。在這集體系架構中，微信硬體平台做的最重要的一件事情就是身份認證。

就像一團體出生後要辦一張身份證（出生證明的号碼也是身份證号碼）一樣，裝置消費出來要想進入微信硬體範疇，它就必需到微信硬體平台注冊本人的身份，那它拿什麼去注冊呢，這個根據自然應該是無獨有偶的，就像每團體的指紋，假如我國的小孩辦身份證都以錄指紋爲根據，那就不會呈現那麼多拐賣兒童了。如今警察局的做法是什麼，是硬生生地把一串身份證數字跟人名綁在一同，跟自然人的生物特征沒有一丁點關系！！！裝置的無獨有偶的根據就是48位的MAC位址（或許是MAC位址經過某種加密運算失掉的後果）。

接着辦身份證/出生證不是要給小孩起個名字嗎，目前大家交流就叫名字了，警察局也是叫名字的嘛，不能夠每次喊話都把指紋的二進制數字讀出來的啊。嗯，那硬體裝置注冊時也要報備本人的名字，即裝置ID。裝置ID也應該在微信硬體平台獨一啊，不然會亂的。就像MAC位址一樣，有一局部是代表一個裝置提供商向世界IETF組織請求的企業辨認字段，另一局部是裝置商外部的配置設定。或許像身份證那樣，後面6個字段是代表一團體出生時的縣區行政區劃碼，前面的數字才代表本身，但同時要保證在這個行政區外面的獨一性。那微信硬體平台怎樣标準裝置身份？裝置身份包括兩個局部，deviceType是裝置商/銷售商的微信大衆号的原始ID，deviceID由裝置商/銷售商自定義，由裝置商保證deviceID在其deviceType中的獨一性。

這就是裝置的注冊場景。裝置注冊了目前在微信硬體平台就具有合法性和獨一性了。

裝置被拜訪的合感性和合理性

• 裝置最終是應該和人/手機使用者互動的，否則就得到了物聯的意義了。那麼哪個使用者可以拜訪這個裝置呢？
• 微信譽戶要關注裝置商的微信大衆号和綁定裝置才幹對裝置停止拜訪。假如不綁定就可以拜訪，那就是一切使用者都可以拜訪這個裝置，這顯然是不合理的。你買的智能插座放家裡，另一團體也能控制你的插座，多風險。
• 微信硬體平台確定裝置的獨一性，微信大衆平台確定微信譽戶的獨一性，兩者經過關注和綁定這個流程樹立起完全權益的拜訪關系。
• 微信硬體平台是微信大衆平台的一個子集，微信硬體平台會應用微信大衆平台已有的功用來完成根底效勞。

裝置和使用者互動的音訊觸達才能

裝置要成爲物聯網中的一員，必需可以聯網，好比人體的神經元，具有可以和外界交流的才能。

微信硬體平台次要從雲後端接入和硬體接入兩方面作出努力。一是經過airsync協定讓藍牙裝置和微信互通，airkiss協定讓複雜的沒有按鍵和UI互動的wifi裝置聯網；二是經過制定雲後端接入協定來接納廠商雲，經過音訊接口和API接口運使用者和裝置的音訊可以互相觸達。即裝置收回的音訊經過微信平台發送到廠商雲，廠商雲的音訊也能自動推送給裝置，完成互動。

效率

掃一掃功用對微信的影響是宏大的，加關注，好友，挪動領取等等都經過二維碼來完成，裝置綁定是二維碼。微信硬體平台和大衆平台發生的二維碼關聯了使用者、裝置ID等資訊，經過掃一掃功用能友善地停止綁定，接入進入大衆号的音訊界面。

物聯網觸及到終端、前端和後端等等，是一個大工程，無論從開發的角度，還是從使用者運用的角度，都要一直強調便捷的效率，以讓使用者有足夠好的體驗，才幹使得物聯網得以壯大。

音訊處置才能—嵌入式零碎

這一點并沒有在物聯網架構的圖示中呈現。物聯網決不隻僅是一種控制，例如開燈和關燈之類，也不隻僅是複雜的經過各種傳感器來停止資料采集，将來的物聯網一定會讓使用者不時地進步使用者體驗，例如多媒體、虛拟與完成、資料決策等等，這局部是由初級的嵌入式零碎來完成的。嵌入式零碎才是裝置的大腦，物聯網應該更好地擁抱嵌入式零碎。

/#%E4%B8%89-%E7%89%A9%E8%81%94%E7%BD%91%E5%9C%BA%E6%99%AF%E5%89%96%E6%9E%90%E5%92%8C%E9%80%9A%E8%AE%AF%E5%8D%8F%E8%AE%AE%E5%89%96%E6%9E%90%E8%BF%91%E5%9C%BA%E8%93%9D%E7%89%99%E6%8E%A7%E5%88%B6%E6%96%B9%E6%A1%88 三、物聯網場景剖析和通訊協定剖析（近場藍牙控制方案）

/#1%E6%B3%A8%E5%86%8C 1.注冊

下面已有闡明

/#2%E7%94%A8%E6%88%B7%E7%BB%91%E5%AE%9A 2.使用者綁定

/#3%E8%A1%94%E6%8E%A5 3.銜接

使用者在綁定程序中會自動完成對提供裝置的廠商的微信大衆号的關注。在目前每次進入大衆号時，會自動經過手機藍牙對藍牙裝置停止掃描銜接。隻要完成airsync協定的藍牙裝置才幹連上微信。例如藍牙裝置播送的字段外面要聲明本人的MAC位址，這樣微信能辨認到這個一個要接入微信的藍牙裝置，然後才會自動地銜接它。

/#4%E6%8E%A7%E5%88%B6%E8%8F%9C%E5%8D%95%E6%8E%A7%E5%88%B6 4.控制(菜單控制)

• 1）使用者點選微信大衆号提供的菜單，如開燈。
• 2）音訊經過微信大衆平台發送給廠商雲後端。
• 3）雲後端在本人的資料庫内驗證微信譽戶和裝置的無效性後，将微信菜單的開燈音訊轉化爲自定義協定的開燈音訊（這個協定隻要雲後端和外設裝置所看法），并依據airsync中的protobuf協定抵消息體停止打包封裝，最初經過調用微信硬體平台提供的API接口自動推送出去。
• 4）微信硬體平台收到資訊後經過微信大衆平台回傳給微信譽戶所在的大衆号。
• 5）微信将這個音訊依據airsync協定經過手機藍牙發送藍牙外設。
• 6）藍牙外設收到音訊停止相應的處置。

從這個程序來看，間接的菜單控制走的流程太長了，影響效率。上面引見的JSAPI控制就是間接控制，不需求再經過廠商雲來發指令。

/#5-%E6%8E%A7%E5%88%B6h5jaspi%E6%8E%A7%E5%88%B6 5. 控制（H5/JASPI控制）

• 1）使用者點選微信大衆号提供的H5網頁連結
• 2）微信閱讀器經過H5位址向廠商雲後端懇求呼應，前往H5頁面。
• 3）使用者點選H5頁面的開燈button
• 4）button經過JSAPI接口間接向藍牙裝置收回自定義的控制音訊，JSAPI藍牙接口曾經封裝好airsync協定。
• 5）藍牙裝置收到音訊停止相應的處置。

/#%E5%9B%9B-%E7%89%A9%E8%81%94%E7%BD%91%E5%9C%BA%E6%99%AF%E5%89%96%E6%9E%90%E5%92%8C%E9%80%9A%E8%AE%AF%E5%8D%8F%E8%AE%AE%E5%89%96%E6%9E%90%E8%BF%9C%E5%9C%BAwifi%E6%8E%A7%E5%88%B6%E6%96%B9%E6%A1%88 四、物聯網場景剖析和通訊協定剖析（遠場wifi控制方案）

/#1%E6%B3%A8%E5%86%8C-2

/#2%E7%94%A8%E6%88%B7%E7%BB%91%E5%AE%9A-2

/#3%E8%A1%94%E6%8E%A5-2

由于使用者和wifi裝置并不在一個區域，而是經過網絡來銜接，因而使用者是不間接跟wifi裝置打交道的，一切的互動都給經過wifi裝置商的雲後端停止直接互動。（之前曾經說了airkiss隻是微信提供的一個配置上網功用，wifi裝置經過一次配置後，目前會記住這個路由器的ssid和pwd的，是以配置好一次後，airkiss跟物聯網互動一點關系都沒有，因而airkiss不應該算在物聯網的音訊觸達協定内）。

使用者進入wifi裝置對應的大衆号後，微信大衆号會經過微信大衆平台向廠商雲訂閱和征詢裝置的線上形态。因而裝置一上線時應該自動聯絡廠商雲後端，告知本人上線了，并不時地發送心跳包維持銜接。這樣微信大衆号一訂閱懇求，雲就前往裝置的形态給它。

假定裝置線上，雲後端前往線上形态，微信大衆号就會顯示裝置銜接上。

/#4-%E6%8E%A7%E5%88%B6%E8%8F%9C%E5%8D%95%E6%8E%A7%E5%88%B6 4. 控制（菜單控制）

• 3）雲後端在本人的資料庫内驗證微信譽戶和裝置的無效性後，将微信菜單的開燈音訊轉化爲自定義協定的開燈音訊（這個協定隻要雲後端和外設裝置所看法），然後間接經過網絡發給wifi裝置。
• 4）wifi外設收到音訊停止相應的處置。

/#5-%E6%8E%A7%E5%88%B6h5%E6%8E%A7%E5%88%B6 5. 控制（H5控制）

• 4）button經過AJAX接口向廠商雲後端收回自定義的控制音訊。
• 5）廠商雲接納到音訊會轉化硬體控制音訊，間接經過網絡發給wifi裝置。
• 6）wifi裝置收到音訊停止相應的處置。

從這點來看，wifi裝置接入微信硬體平台，微信硬體平台僅僅起到一個入口的作用，音訊轉發都不經過微信硬體平台了。

/#%E4%BA%94-%E5%BE%AE%E4%BF%A1%E7%A1%AC%E4%BB%B6%E5%B9%B3%E5%8F%B0%E7%9A%84%E4%BC%98%E4%B8%8E%E5%8A%A3 五、微信硬體平台的優與劣

回過頭來想想，國際這幾年早曾經有多家物聯網平台，如機智雲，yelink等等，它們除了充任警察局的角色確定裝置的獨一性，還完成了後端的效勞平台，甚至給使用者提供物聯裝置子產品，極大地簡化了物聯裝置消費商的開發流程。在這樣的根底上，微信硬體平台把那麼多的義務丢給了開發者，但還是很多廠商擁抱它，隻能說微信是一個超級APP，是一個極佳的入口，掌握了全社會大局部使用者的入口。在挪動網際網路範疇，使用者數量就是霸道。

固然，使用者量宏大和騰訊體量龐大是微信硬體平台物聯網的劣勢，但要想做得更好，是不是思索給使用者多做一些像機智雲一樣的任務？

換作各位小同伴，你們會怎樣做呢？歡迎留言~~