本文從物聯網的中心要素、物聯網的關鍵場景、微信硬體平臺的通訊協議剖析三個維度去剖析基於微信硬體平臺的物聯網架構。

一、基於微信硬體平臺的物聯網架構圖

上圖涵蓋以下資訊：

基於微信硬體平臺的物聯網的架構組成，有微信大眾平臺/硬體平臺、第三方廠商雲後端、手機微信/大眾號、微信硬體裝置終端（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裝置接入微信硬體平臺是遠場控制，裝置只需處於聯網線上形態，那手機使用者無論在哪裡，只需能上網都可以對裝置停止控制，典型的例子是在公司下班可以經過手機控制家裡的智慧插座上電；藍芽裝置接入微信硬體平臺必需依賴於手機，是近場控制，典型的場景是手機控制家裡的燈和空調等。

二、物聯網的中心要素

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

裝置的合法性和獨一性

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

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

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

這就是裝置的註冊場景。設備註冊了當前在微信硬體平臺就具有合法性和獨一性了。

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

裝置最終是應該和人/手機使用者互動的，否則就得到了物聯的意義了。那麼哪個使用者可以拜訪這個裝置呢？

微信譽戶要關注裝置商的微信大眾號和繫結裝置才幹對裝置停止拜訪。假如不繫結就可以拜訪，那就是一切使用者都可以拜訪這個裝置，這顯然是不合理的。你買的智慧插座放家裡，另一團體也能控制你的插座，多風險。

微信硬體平臺確保裝置的獨一性，微信大眾平臺確保微信譽戶的獨一性，兩者經過關注和繫結這個流程樹立起完全權益的拜訪關係。

微信硬體平臺是微信大眾平臺的一個子集，微信硬體平臺會應用微信大眾平臺已有的功用來完成根底效勞。

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

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

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

效率

掃一掃功用對微信的影響是巨集大的，加關注，好友，挪動領取等等都經過二維碼來完成，裝置繫結是二維碼。微信硬體平臺和大眾平臺發生的二維碼關聯了使用者、裝置ID等資訊，經過掃一掃功用能方便地停止繫結，接入進入大眾號的音訊介面。

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

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

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

三、物聯網場景剖析和通訊協議剖析（近場藍芽控制方案）

1.註冊

下面已有闡明

2.使用者繫結

下面已有闡明

3.銜接

使用者在繫結程序中會自動完成對提供裝置的廠商的微信大眾號的關注。在當前每次進入大眾號時，會自動經過手機藍芽對藍芽裝置停止掃描銜接。只要完成airsync協議的藍芽裝置才幹連上微信。例如藍芽裝置播送的欄位外面要宣告本人的MAC地址，這樣微信能辨認到這個一個要接入微信的藍芽裝置，然後才會自動地銜接它。

4.控制(選單控制)

• 1）使用者點選微信大眾號提供的選單，如開燈。

• 2）音訊經過微信大眾平臺傳送給廠商雲後端。

• 3）雲後端在本人的資料庫內驗證微信譽戶和裝置的無效性後，將微信選單的開燈音訊轉化為自定義協議的開燈音訊（這個協議只要雲後端和外設裝置所看法），並依據airsync中的protobuf協議抵訊息體停止打包封裝，最初經過呼叫微信硬體平臺提供的API介面自動推送出去。

• 4）微信硬體平臺收到資訊後經過微信大眾平臺回傳給微信譽戶所在的大眾號。

• 5）微信將這個音訊依據airsync協議經過手機藍芽傳送藍芽外設。

• 6）藍芽外設收到音訊停止相應的處置。

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

5. 控制（H5/JASPI控制）

• 1）使用者點選微信大眾號提供的H5網頁連結

• 2）微信閱讀器經過H5地址向廠商雲後端懇求呼應，前往H5頁面。

• 3）使用者點選H5頁面的開燈button

• 4）button經過JSAPI介面間接向藍芽裝置收回自定義的控制音訊，JSAPI藍芽介面曾經封裝好airsync協議。

• 5）藍芽裝置收到音訊停止相應的處置。

四、物聯網場景剖析和通訊協議剖析（遠場wifi控制方案）

1.註冊

下面已有闡明

2.使用者繫結

下面已有闡明

3.銜接

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

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

假定裝置線上，雲後端前往線上形態，微信大眾號就會顯示裝置銜接上。

4. 控制（選單控制）

• 1）使用者點選微信大眾號提供的選單，如開燈。

• 2）音訊經過微信大眾平臺傳送給廠商雲後端。

• 3）雲後端在本人的資料庫內驗證微信譽戶和裝置的無效性後，將微信選單的開燈音訊轉化為自定義協議的開燈音訊（這個協議只要雲後端和外設裝置所看法），然後間接經過網路發給wifi裝置。

• 4）wifi外設收到音訊停止相應的處置。

5. 控制（H5控制）

• 1）使用者點選微信大眾號提供的H5網頁連結

• 2）微信閱讀器經過H5地址向廠商雲後端懇求呼應，前往H5頁面。

• 3）使用者點選H5頁面的開燈button

• 4）button經過AJAX介面向廠商雲後端收回自定義的控制音訊。

• 5）廠商雲接納到音訊會轉化硬體控制音訊，間接經過網路發給wifi裝置。

• 6）wifi裝置收到音訊停止相應的處置。

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

五、微信硬體平臺的優與劣

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

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

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