物聯(lián)網(wǎng)中的通信 - 即設備如何向網(wǎng)絡發(fā)送和接收數(shù)據(jù) - 可以以不同的方式處理，通信方式主要由應用層中的協(xié)議來控制。了解數(shù)據(jù)在您服務中的設備周圍的流動方式可以讓您了解其可能的響應以及數(shù)據(jù)在設備之間的同步速度。

推（push），拉（pull）和輪詢（polling）

作為一名UX（用戶體驗）設計師，您需要注意的關鍵因素包括：

?設備如何將消息傳輸?shù)骄W(wǎng)絡中：它是定期推送（push）還是滿足某些條件后再推送？還是僅當客戶端設備（如智能手機應用程序）或者服務請求（pull：拉）它時才會傳輸（即）？

?設備如何從網(wǎng)絡中接收消息：消息是否是從服務或者其他設備推送過來的，還是第一個設備根據(jù)需要請求它們接收的？

?設備連接頻率：它是不斷地持續(xù)連接，還是定期連接的，還是只有當它知道它需要連接時才連接？

?指令或數(shù)據(jù)可能多快通過？這是一個組合的問題包括以下的問題：

->設備建立連接需要多長時間

->連接可能有多快

->需要發(fā)送多少數(shù)據(jù)

->它可以多直接地被路由（任何信息要通過Internet可能需要花更長的時間）

如圖1的例子所示，說明了您可能會遇到的一些問題：

電池供電加熱控制器使用ZigBee每兩分鐘聯(lián)系其網(wǎng)關登記注冊其狀態(tài)信息并尋求新的指令。這種方式稱為輪詢（polling）：控制器不知道什么時候會有新的指令，但必須定期地檢查更新。

用戶使用移動應用程序來加熱使溫度從19°C升高到21°C。該應用程序將該指令傳遞給Internet服務。網(wǎng)關設備定期輪詢（polls）Internet服務并接收指令。 （網(wǎng)關具有主電源供電，因此可能會相當頻繁地進行輪詢，也許每隔幾秒鐘就輪詢一次。）加熱控制器（polls）輪詢網(wǎng)關并接收指令。

圖1、加熱系統(tǒng)中的輪詢和推送

如果用戶在加熱控制器面前使用移動應用程序app時，則可能會看到控制器花費長達兩分鐘的時間來響應來自移動設備的命令。

在此期間，手機UI（用戶接口）和控制器顯示器將顯示不同的狀態(tài)信息，并且可能會不同步。手機可能會說是21°C，控制器則可能顯示19°C。控制器反映系統(tǒng)當前的真實狀態(tài)。在連貫性方面，這是一個連續(xù)性問題。

它可以更快地將指令從Internet服務推送到網(wǎng)關和設備中。但這通常不太可能通過家庭路由器來實現(xiàn)。大多數(shù)路由器向世界呈現(xiàn)的是單個公共IP地址，并將本地網(wǎng)絡上的設備地址保留為私有（這種共享一個IP地址的技術稱為NAT：網(wǎng)絡地址轉換（network address translation））。因此，服務器難以推送（push）到本地家庭網(wǎng)絡上的設備或者從本地家庭網(wǎng)絡上的設備中拉出（pull）信息。另外，安全防火墻也可能是一個問題。

所以，設備必須通過輪詢來檢查新的指令，這可能需要更長的時間。

如果用戶使用安裝在加熱控制器設備上的控制來升溫，則延遲可能會較短?？刂破髦老到y(tǒng)發(fā)生了變化，并通過集線器（hub）將更新信息的消息推送（push）到Internet服務中。它知道它需要連接，所以它不會等待計劃的下一個輪詢。如果用戶的智能手機加熱控制應用程序打開，那么它可能會每30秒向服務請求新的數(shù)據(jù)。所以如果用戶在同一時間看著他們的智能手機加熱應用程序，他們可能仍然會觀察到不連續(xù)性，但可能只是一個短暫的延時。

智能手機和加熱控制器正在輪詢互聯(lián)網(wǎng)服務以進行更新，這是一個拉（pull）的例子。當他們知道他們有最新的信息或者命令要分享時，那么它們兩者都能夠推送消息。

智能手機和加熱控制器都不會保持與網(wǎng)絡的持續(xù)連接，因為這樣會耗盡電池的電量。但手機可以比控制器更頻繁地檢查更新，因為它的電源受到的限制較少。

雖然這種安排確實會暴露偶爾的不連續(xù)性，但是對于加熱系統(tǒng)的應用情況，這些不會是災難性的影響。大多數(shù)時候，用戶不會拿著智能手機站在加熱控制器的面前。另外在大多數(shù)時候，發(fā)出加熱指令和實際開啟指令之間的兩分鐘延遲滯后并不是一個問題：加熱器的工作時間是以小時為單位的而不是秒。

輪詢時間間隔太長可能會使服務感到反應太遲鈍。例如，使用If This Then That（IFTTT）， 當有電子郵件從特定收件人傳遞到您的Gmail帳號上時Philips Hue bulb可以配置為閃爍或者更改顏色。雖然這是一個好主意，但是IFTTT只能每15分鐘輪詢一次Gmail（這可能是由Gmail限制的，以避免輪詢太頻繁而導致其服務器過載）。這意味著在收到電子郵件后15分鐘內(nèi)，燈泡可能不會響應。這是一個非常不及時響應的通知系統(tǒng)。

如果您希望設備能夠快速響應命令，則要么必須保持打開連接以監(jiān)聽推送的命令，或者更頻繁地進行輪詢。給消費者推送通知的一個很好的例子是Google通訊錄（Google Contacts）。如果您使用Web來更新Google聯(lián)系人（Google Contact），則幾秒鐘內(nèi)就會將更新推送到您的手機。手機不經(jīng)常輪詢：它只是收到從Google服務器發(fā)來的自發(fā)更新通知。

當沒有什么新的東西可以分享時，頻繁的輪詢可能會導致服務器過載（以及會耗盡電池）。維持與許多不同設備之間的許多開放連接也是不切實際的。但是，你無法連接到一個沒有打開連接的設備上來告訴它進行連接。當您需要一個設備快速響應時，您可能至少需要一個打開的連接。例如，如果氣體傳感器檢測到泄漏，則關閉家庭電源的開關將立即關閉。

控制設備發(fā)送命令的時間更容易。一個設備可以被配置為在滿足某些條件時向網(wǎng)絡發(fā)送數(shù)據(jù);例如，加熱時間表發(fā)生了改變，或者濕度傳感器檢測地下室中有水。它也可以配置為在某些條件下更頻繁地發(fā)送數(shù)據(jù)。如果一個檢測可能的火災的熱探測器僅每2分鐘發(fā)送一次狀態(tài)信息，則可能會在接下來的20分鐘時間內(nèi)每隔一秒傳輸一次狀態(tài)信息。如果它不能聯(lián)系到其通常的網(wǎng)絡網(wǎng)關時，那么它可能通過網(wǎng)狀網(wǎng)絡上的替代節(jié)點來嘗試跳躍通過。使用靜態(tài)IP地址（例如IPv6）和適當?shù)膽贸绦?，那么從理論上也可以在緊急情況下嘗試使用相鄰的網(wǎng)絡。

當消息沒有通過時，設備也可能需要有提醒用戶的方法。例如老年人的緊急警報按鈕需要盡可能的可靠，并提供如蜂窩數(shù)據(jù)這樣的備份連接。但是，該按鈕仍然應該可以告訴用戶不僅是他們的幫助呼叫是否被發(fā)送出去，而且也要告訴用戶該呼叫是否已經(jīng)被另一端的系統(tǒng)所接收。

UX（用戶體驗）的一個關鍵考慮是了解數(shù)據(jù)在系統(tǒng)周圍傳遞的速度，以及它是否適合在應用的上下文環(huán)境中被使用。例如，用于家庭用電的家庭能源監(jiān)控系統(tǒng)可能會每隔幾分鐘或者更長時間將最近24小時的數(shù)據(jù)上傳到互聯(lián)網(wǎng)服務中。當您請求此信息時，它將從Internet服務中發(fā)送過來而不會直接查詢能量監(jiān)視器。這樣做可能會更快，和/或降低與您的能源公司連接的蜂窩數(shù)據(jù)的成本。但是，如果您想知道您家的前門是否被鎖緊，那么知道該數(shù)據(jù)是否是2分鐘前的舊數(shù)據(jù)是非常重要的 - 因為有人可能在其期間已經(jīng)打開它了。

物聯(lián)網(wǎng)（IOT）的應用層協(xié)議

應用層協(xié)議位于Internet網(wǎng)絡的最頂層。他們建立計算機進程的通道來進行交流。它們形成設備通過網(wǎng)絡并從網(wǎng)絡中獲取數(shù)據(jù)的連接模式。您的系統(tǒng)使用的應用程序協(xié)議的選擇主要是一個技術設計問題，并不太可能對UX（用戶體驗）產(chǎn)生重大的影響。但是，值得注意的是要留意您聽到的一些可能的選項，并了解您正在處理的系統(tǒng)如何傳遞數(shù)據(jù)的。

IoT應用程序通常是使用超文本傳輸協(xié)議（HTTP）通過Internet來進行通信的。

HTTP是一種可靠的方式來傳遞圍繞著少量設備的不需要立即更新的任何更改信息。但是它不是按照推送（ push）或者流式（streaming ）而設計的，因此通常需要輪詢。圍繞著很多設備來傳遞數(shù)據(jù)的也不是最流暢的方法，特別是對于電源和計算能力受限制的設備來說更是如此。它需要在需要共享數(shù)據(jù)的任何設備（點對點網(wǎng)絡，參見圖2）之間建立直接連接，并且消息占用了大量的字節(jié)。

其他協(xié)議，尤其是MQTT協(xié)議，是專為物聯(lián)網(wǎng)而設計的。這些優(yōu)先級更小的數(shù)據(jù)傳輸以及更有效的方式適合用來在低功耗設備的大型網(wǎng)絡上傳輸數(shù)據(jù)。MQTT沒有采用直接連接而是使用一種發(fā)布訂閱模型，其中的設備將數(shù)據(jù)推送到一個中央消息代理器中。其他設備可以訂閱他們想要的數(shù)據(jù)源（“主題（topics）”）（見圖2）。這種方式可以很快：Facebook Messenger就是運行MQTT協(xié)議的。它也是管理大量設備之間的互連的一種更靈活的方式：每個設備只需調(diào)整到它們所需的主題上。

但HTTP得到廣泛的支持。它可以通過Web API以易于訪問和通用的方式利用傳感器網(wǎng)絡。它也通過使用防火墻來增加安全性，因為它看起來就像普通的網(wǎng)頁瀏覽。

圖2、像MQTT這樣的發(fā)布訂閱應用程序協(xié)議可以提供一種比點對點協(xié)議（如HTTP）更有效的方式來傳遞大型設備網(wǎng)絡中的數(shù)據(jù)。在這種情況下，每個接收器從發(fā)送方1和2獲取數(shù)據(jù)，但并不都需要來自發(fā)送者3和4的數(shù)據(jù)。在這種發(fā)布預訂（Publish-subscribe）的網(wǎng)絡中，只需要較少的連接來正確地分發(fā)消息。

互聯(lián)網(wǎng)服務

在本節(jié)中，我們將介紹Internet服務在IoT系統(tǒng)中的作用，以及API（應用程序編程接口）的設計與UX（用戶體驗）設計之間的關系。

互聯(lián)網(wǎng)服務的作用

物聯(lián)網(wǎng)系統(tǒng)通常需要依靠某種的遠程集中式互聯(lián)網(wǎng)服務來收集，處理和分發(fā)數(shù)據(jù)和指令（少數(shù)的連接設備可能沒有遠程集中式Internet服務。例如，許多WiFi打印機都有自己的嵌入式Web服務器，從而可以托管它們自己的互聯(lián)網(wǎng)服務。但這在物聯(lián)網(wǎng)的應用中就相對少見）；

互聯(lián)網(wǎng)服務通常包括一些存儲和處理方式：

?系統(tǒng)數(shù)據(jù)（例如，傳感器數(shù)據(jù)或者設備的當前狀態(tài)）；

?運行在頂層中的應用（例如，健康監(jiān)控或者照明控制）；

該服務通過應用程序編程接口（APIs）來使數(shù)據(jù)和系統(tǒng)命令可用于移動或者Web應用程序中。服務提供商越來越多地將APIs提供給第三方開發(fā)人員以使其他服務能夠與系統(tǒng)集成。

例如，從傳感器網(wǎng)絡獲取的數(shù)據(jù)由Internet服務器進行匯聚和處理，然后因特網(wǎng)服務器發(fā)布數(shù)據(jù)總結。

系統(tǒng)設計人員可以選擇處理發(fā)生的位置：在遠程服務中（“云”），網(wǎng)關中或者邊緣設備中。在云中進行更多處理可以更容易地維護對系統(tǒng)的一個集中式視圖。但是當設備丟失連接并且無法訪問云時，系統(tǒng)將無法正常工作。

對于非緊急的數(shù)據(jù)，例如空氣質(zhì)量監(jiān)測，這是可以接受的。如果傳感器暫時離線，他們可以存儲數(shù)據(jù)，并在重新連接時再將其上傳。發(fā)生的最糟糕的事情是一些數(shù)據(jù)可能是舊的。

但是，對于數(shù)據(jù)必須盡快完成這樣做是不行的。如果嬰兒監(jiān)視器沒有及時警告隔壁房間的父母導致孩子已經(jīng)停止了呼吸，那么這是不能接受的。這就是需要進行本地處理的地方，因此設備可以在沒有互聯(lián)網(wǎng)的情況下工作（例如，具有設備上控制功能或者網(wǎng)關的恒溫器可以繼續(xù)控制家庭照明）。

互聯(lián)網(wǎng)服務可能是專有的（針對您的服務定制），也許使用API來與第三方服務共享數(shù)據(jù)?；蛘咚赡苁且环N開放式服務（例如，Thingspeak的開放數(shù)據(jù)平臺）。如果您依賴別人的服務，那么請記住，如果他們出現(xiàn)中斷，提高價格，丟失或者公布您的數(shù)據(jù)，或者它們破產(chǎn)了...，那么最終您也會如此。

平臺（在這種情況下）是一種可用于構建多個遠程服務應用程序的軟件框架。 Thingspeak，Kaa，Xively，以及Thingworx是開發(fā)人員可以用來創(chuàng)建IoT服務的平臺例子。平臺可以使工程師更容易地讓系統(tǒng)運行起來，但是可能也會限制您或者使您的服務缺乏靈活性。依靠第三方平臺需要承擔平臺提供商可能會停業(yè)的風險。與開放標準連接的獨立服務可能會提供更多的控制和選擇：如果需要，您可以用一個等效的服務來替換現(xiàn)有的服務。

APIs（應用程序編程接口）

應用程序編程接口（API： application programming interface）是開發(fā)人員的接口。API為開發(fā)人員提供了一些組件工具來構建系統(tǒng)里的東西。它們可能是您自己的前端網(wǎng)絡或者移動應用apps或與您的系統(tǒng)交互的第三方服務。 API是創(chuàng)建可互操作的設備和服務生態(tài)系統(tǒng)的重要組成部分。

API使開發(fā)人員可以創(chuàng)建易于鏈接到其它服務的Web服務。因此，您無需為您的雨量預報設備而構建自己的天氣預報服務：您可以輕松地呼叫第三方天氣服務的API。 “小件（small pieces），松散加盟（loosely joined）”的原則鼓勵開發(fā)商創(chuàng)造有針對性的服務：做好一件事，同時與其他服務進行良好的互操作。這提供了將不同服務組合在一起來創(chuàng)建完全不同的應用的靈活性。

UX（用戶體驗）人員通常不負責設計API，但API設計可能會對您能夠創(chuàng)建的UX（用戶體驗）產(chǎn)生重大的影響。您在APIs中提供的功能可以決定您可以使用自己的UX設計做什么以及其他（第三方）可以對您的服務做什么。

設計API非常像為內(nèi)容網(wǎng)站設計信息架構。您需要了解您的用戶需要哪些信息，以及如何分塊和組織，以便使用戶輕松快捷地找到自己想要的內(nèi)容。

有時設計決策將涉及到權衡：您可能通過使一些任務變得更容易，而卻使別的任務變得更難。

如果您的UX（用戶體驗）設計和您的API（應用程序編程接口）設計相互不適合，其結果可能是導致長時間延遲，響應速度差以及服務器過載。 API設計應與產(chǎn)品定義和UX設計緊密相連。

web API是如何工作的？

API可以描述數(shù)據(jù)或者函數(shù)調(diào)用。它們可以用多種語言編寫，但在本章中我們將使用基于HTTP的標準Web API的示例。

Web API調(diào)用將操作應用于URL。以下是一個連接的家庭系統(tǒng)的一種可能的API URL架構的示例：http：// api.[服務供應商的名字].com /屬性（property）/網(wǎng)關（gateway）/設備類型（devicetype）/設備（device）/信道（channel）。

·第一部分是服務提供商的公共域名。

·屬性（property）是系統(tǒng)所在的家（例如，克萊爾的房子）。

·網(wǎng)關（gateway）是網(wǎng)關設備的名稱（如果您有多個網(wǎng)關設備的話）。

·設備類型（devicetype）是設備的類型（例如，運動傳感器，接觸傳感器，燈開關）的名稱。

·設備（device）是由用戶分配的特定設備（例如餐廳運動傳感器或者后門接觸傳感器）的名稱。

·信道（channel）是來自該設備的數(shù)據(jù)饋源。設備可能有多個（例如，所有運動和接觸傳感器也可能感測溫度，因此將有兩個數(shù)據(jù)饋源：運動和溫度）。

您可以使用API檢索數(shù)據(jù)，或在某些情況下通過使用HTTP方法發(fā)送請求將命令發(fā)送給系統(tǒng)。

GET是最常見的，用于檢索數(shù)據(jù)的方法。使用下面的示例：如果您想從房間中的所有運動傳感器中檢索到狀態(tài)信息，那么就可以通過使用GET方法來發(fā)出請求：http：// api.[serviceprovidername] .com / claireshouse / gateway1 / motionsensors。

系統(tǒng)會回應以下XML代碼：

<channel type="motion">

<events>

<event type="motion" detected="no" timestamp=""

location=""/>

<event type="motion" detected="no" timestamp=""

location=""/>

... (在房子里的每個運動傳感器的一個條目)...

</events>

</channel>

如果您有這樣做的授權，您也可以使用其他方法修改服務器上的數(shù)據(jù)。

在這個例子中，如果你想把飯廳的燈光調(diào)暗50％，你可以提出一個PUT請求：

/{ claireshouse/gateway1/lightswitches/diningroom

<light>

<state value="on"/>

<dimming percentage="50"

</light>

這些是非常簡單的例子，但應該可以幫助您了解以下部分中描述的設計問題。

APIs的關鍵設計問題

在設計API時要做出的關鍵決定是數(shù)據(jù)和控制的顆粒度，以及如何將其組織到層次結構中去。

Granularity（顆粒度）：由連接到互聯(lián)網(wǎng)的一個設備組成的簡單系統(tǒng)可以具有一個簡單的API。該設備發(fā)布已收集的關鍵數(shù)據(jù)，如前面的例子所示您可以將簡單的命令（控制）傳回給它。這是一種細粒度（或者面向端點的）設計，因為它暴露了設備本身的底層數(shù)據(jù)。

端點/細粒度的APIs（圖3）允許控制特定設備或檢索特定的數(shù)據(jù)，這對于小型系統(tǒng)來說是足夠好的。但是，如果您想要同時從許多設備檢索數(shù)據(jù)，則細粒度的系統(tǒng)意味著需要大量單獨的API調(diào)用。這將是緩慢的：在3G連接上每個API調(diào)用每次往返可能需要1秒鐘。需要進行20個API調(diào)用的網(wǎng)頁或移動應用程序屏幕的加載速度要比只有兩個或者三個API調(diào)用的速度要慢得多。

圖3、細粒度和粗粒度APIs的簡單的例子

在具有大量設備的物聯(lián)網(wǎng)系統(tǒng)中，各個個體設備通常對用戶來說并不重要。如果您想知道您家客廳的溫度，您會關心您的房間而不是可以在房間監(jiān)測溫度的設備。系統(tǒng)應該為您計算室溫，并通過單個的API調(diào)用就可以使其呈現(xiàn)給您。

這些是面向任務的（針對特定任務）或粗粒度（匯聚數(shù)據(jù)）API函數(shù)的示例。服務匯聚來自多個設備的數(shù)據(jù)，并在后端應用一些算法處理。您的智能手機應用程序只需要運行一個API調(diào)用，來知道房子中哪些燈是開的或者哪些是關的。

面向任務的API使得更容易實現(xiàn)在多個設備上支持復雜功能。您可以將API緊密地綁定到您的UI（用戶接口）上，匯聚通過單個API調(diào)用訪問的特定屏幕或小部件所需的所有數(shù)據(jù)。這將是高度響應的系統(tǒng)，但如果您想要更改您的UI，則需要重新設計。所有使用您的API的第三方都必須提供與您完全相同的屏幕/小部件塊數(shù)據(jù)。因此面向任務的APIs存在靈活性不夠的風險：UX設計人員和開發(fā)人員必須按照您設計API的方式來使用它們。

如果API的粗粒度過大，也可能會阻止您訪問單個設備或者數(shù)據(jù)。你可能有時候需要關掉所有的燈，但是你也有時候只想要關掉走廊上的燈。

來自Evrythng的Niall Murphy引用了現(xiàn)有使用單一API連接汽車的例子。這是為維修/制造商診斷而設計的，但對其它的用途來說是不切實際的：

“你可以打開汽車上的所有信息流，或者關閉它。當你回家的時候，家里一直不需要車位置的信息流來打開車庫門。您需要將大小信息縮小到與特定應用程序匹配的所需信息”。

有可能使用混合設計：一些聚合數(shù)據(jù)和面向任務的APIs以及一些端點（設備）APIs。這將使您能夠顯示家庭中所有電器的能源使用情況，也可以只跟蹤烘干機的使用情況。

結構體。除了選擇正確的數(shù)據(jù)和控制的顆粒度之外，還需要對API中的單位（設備和數(shù)據(jù)點）進行分組和組織，以使其他人能夠使用。當您擁有更多的設備和數(shù)據(jù)點后這一點會變得越來越重要。

數(shù)據(jù)/設備在您的API中的組織方式可以使您更容易或者更難以從您想要的設備組合中檢索數(shù)據(jù)或者應用控制。嘗試著從不適合的API設計中創(chuàng)建UX設計將會導致一個遲緩的，無響應的UX。

家庭中的設備可以通過其感測能力（例如，溫度或運動），位置（例如在廚房里或者在樓上），它們支持的應用（例如，安全性或者加熱）或者其它更多的方式來組織。有些設備可以做超過一件事情的 - 例如，一些設備既可以感測溫度又可以監(jiān)測運動，以及和/或可能被多個應用程序所使用。如果您繪制了這些設備之間的相互關系的映射，那么它將看起來像一個網(wǎng)絡結構（見圖4）。

圖4、設備之間的相互關系形成網(wǎng)絡結構

用戶可能希望訪問不同的被組織起來的分組。例如，您可能想要看到房子周圍的溫度讀數(shù)?；蛘吣赡芟胍榭此邪踩O備。或者您可能想要檢查客廳中每個設備的當前狀態(tài)。

對于復雜的多設備系統(tǒng)，網(wǎng)絡類型的UX通?？雌饋硐袷且环N直觀的方式來供用戶探索可用的內(nèi)容。從客廳運動傳感器，您可以瀏覽其它的安全設備，其他運動傳感器以及其它測量溫度的設備。

麻煩的是，在UX中提供這種靈活性不一定會很容易地使用APIs。特別是查找相關數(shù)據(jù)往往是一個挑戰(zhàn)。 URL是分級的，因此它們并不反映數(shù)據(jù)可以相互關聯(lián)的所有方式。

還是以我們前面看過的餐廳溫度為例。在與餐廳溫度相同的屏幕上，您還想顯示家中其他溫度傳感器的讀數(shù)。對用戶來說，這似乎是一件很明顯的事情：從一個溫度讀數(shù)，我可以查看其它的讀數(shù)。但是在這個架構中，它們都位于樹結構的底部，并且彼此之間的關系沒有被映射。所以您必須單獨調(diào)用每個其它溫度傳感器的數(shù)據(jù)。這將是緩慢而低效的，就像您不得不從上到下瀏覽網(wǎng)站的樹結構以比較大量單獨的網(wǎng)頁頁面里的內(nèi)容。

如果您正在設計一個只有少量設備的小型系統(tǒng)，那么潛在的低效率就會很小。但是，您必須應對的數(shù)據(jù)點和設備越多，那么讓您的API結構很好地適應UX就越重要。

作為一名UX設計師，重要的是確保您的工作與設計APIs的開發(fā)人員要緊密合作。

第三方API。您可以依賴于第三方例如Xively或Twitter的API。如果是這樣，您就受到他們的條款約束，您需要檢查您可以如何使用它們。供應商通常對您可以進行的調(diào)用頻率施加限制，或每天的API調(diào)用數(shù)量，以避免使他們的服務器過來。他們也可能收取API調(diào)用費用，如天氣預報服務forecast.io所做的那樣，另外與第三方平臺提供商一樣，他們也可能會停業(yè)。

總結

網(wǎng)絡對物聯(lián)網(wǎng)（IoT）系統(tǒng)的UX（用戶體驗）產(chǎn)生了根本的影響。許多連接的設備僅間歇地連接到網(wǎng)絡以輪詢新的指令。這可能會造成系統(tǒng)的部分相互不同步而產(chǎn)生較小的延遲。網(wǎng)絡延遲和可靠性問題可能意味著連接的設備的行為不與如我們期望的現(xiàn)實世界的對象所做的那樣。

系統(tǒng)架構決定設備如何圍繞系統(tǒng)傳遞數(shù)據(jù)，處理發(fā)生的事情，以及系統(tǒng)的某些部分離線時將會或者將會不起作用。設備可以直接連接到Internet或者通過本地網(wǎng)絡連接到網(wǎng)關。許多設備只能支持低功率網(wǎng)絡，如藍牙和ZigBee。網(wǎng)關使這些設備間接連接到Internet中。未來，通過為低功率網(wǎng)絡提供I功能P將使更多的設備能夠直接連接到互聯(lián)網(wǎng)中。這種互聯(lián)網(wǎng)標準的使用將使不同的系統(tǒng)能夠更容易的合作。

應用協(xié)議塑造了設備通過網(wǎng)絡并從網(wǎng)絡中獲取數(shù)據(jù)的連接模式。數(shù)據(jù)可能被推送（push）或者被拉到（pull）設備上;該設備可以不間斷連接或者以規(guī)則間隔來輪詢指令。 HTTP是常用的;而專門的IoT協(xié)議（如MQTT）針對具有有限帶寬的低功率設備進行了優(yōu)化。

所有IoT系統(tǒng)都依賴某種遠程集中式Internet服務來收集，處理和分發(fā)數(shù)據(jù)和指令。該服務通過應用程序編程接口（APIs）使數(shù)據(jù)和系統(tǒng)命令可用于移動或者Web應用程序中。

應用程序編程接口（APIs）是開發(fā)人員的界面。它為他們提供了使用系統(tǒng)數(shù)據(jù)來制作最終用戶應用程序和其他系統(tǒng)的基本模塊。如果API設計不適合UX的要求，那么可能會導致緩慢的，無響應的體驗或者會過度限制您所提供的功能。

應用舉例

Proteus數(shù)字健康（Proteus Digital Health）：連接的藥丸

藥物是20世紀的一個驚人的創(chuàng)新，但它們只有在正確使用時才能奏效。來自世界衛(wèi)生組織的專家估計，一半的藥物沒有按規(guī)定服用，意思是劑量不足，劑量不正確或藥物不正確.由于這些依從性的挑戰(zhàn)，大多數(shù)人不能從藥物中獲得最大的價值。 Proteus Digital Health正在通過在口服藥物中添加傳感器并將其連接到物聯(lián)網(wǎng)中來解決這個問題。

這些連接的藥物正在為患者，護理人員和醫(yī)護人員提供新的數(shù)據(jù)流。 Proteus的系統(tǒng)在人們服用藥物時，不可思議地捕捉到數(shù)據(jù)，并將數(shù)據(jù)與其他生理和行為數(shù)據(jù)（如心率，活動和睡眠模式）進行比較。這些信息匯聚在一起可以實現(xiàn)新的自我管理方法，并產(chǎn)生新的見解以便臨床決策。

技術

該系統(tǒng)的核心創(chuàng)新是在藥物制造的過程中可以藥丸中放入的一個小型，低成本的1mm×1mm可攝取傳感器（見圖5）。這種一次性傳感器被設計為從根本上安全的，由通?？梢栽谌祟愶嬍持邪l(fā)現(xiàn)的元素制成的。用戶也不可見，完全封閉在藥丸內(nèi)，所以“連接”藥丸看上去與標準藥物沒有任何區(qū)別。

在設計物理傳感器時，我們認為保持人們對熟悉使用的藥物的習慣方式非常重要，因此拒絕使用傳感器對用戶可見的設計方法。

圖5、 Proteus的可攝入傳感器

可攝入傳感器通過專有的傳輸技術與由Proteus開發(fā)包含在佩戴在身體上并每周更換的小貼片內(nèi)的小型穿戴式傳感器進行通信。佩戴設備可以收集其他數(shù)據(jù)，例如活動和心率，并將所有的內(nèi)容傳送到手機中（參見圖6）。然后，手機將數(shù)據(jù)發(fā)送到云端，可以通過安全的門戶網(wǎng)站和應用程序對這些數(shù)據(jù)進行分析和訪問。這些應用可以針對不同的用例進行定制，并可以針對不同的用戶進行優(yōu)化。人們對信息有不同的用途：患者管理日常護理，個人護理人員獲得對親人的保證，護士可以立即關注需要分診的病人，醫(yī)生參考它們來做臨床決策，醫(yī)護人員通過它們來了解其人群趨勢等。

設計一項使該技術成功推出的服務也很重要。最初這種系統(tǒng)有兩個服務設計目標：（1）降低使用不熟悉產(chǎn)品的障礙，（2）加快學習可以如何改進產(chǎn)品。為了達到這些目標，Proteus投資雇用了全職的“教練”，他們負責訪問家中早期的客戶，幫助他們使用系統(tǒng)，并報告他們所面臨的挑戰(zhàn)。這項投資至關重要，因為這使Proteus能夠快速識別和修復產(chǎn)品痛點。隨著產(chǎn)品變得更容易使用，客戶對新技術的信心越來越高，Proteus預計將其轉變?yōu)楦叱杀拘б婧透儋Y源密集型服務模式。

圖6、 Proteus系統(tǒng)

Proteus早期的設計任務之一是找出誰需要訪問什么數(shù)據(jù)以及如何訪問。由Proteus生成的數(shù)據(jù)可以用于各種各樣原因下的上下文環(huán)境中?？s小并集中在幾個用例上來開始是關鍵。

Proteus的業(yè)務團隊確定了一套潛在的市場。然后，為了定義產(chǎn)品，Proteus的設計研究團隊訪問了家庭或診所市場上的潛在客戶，并仔細觀察了最嚴峻的挑戰(zhàn)，傾聽了Proteus可以直接回答的具體問題。通過這些學習，Proteus的交互設計師以靜態(tài)截圖的形式創(chuàng)建了潛在的信息可視化，然后將其帶回到現(xiàn)場進行反饋（見圖7）。雖然Proteus早期的原型展示了大量的數(shù)據(jù) - 展示了廣泛的系統(tǒng)功能 - Proteus收集的反饋意見促使他們更直接地實施信息可視化，更直接地關注所提問題，留下大量的原始數(shù)據(jù)。我們發(fā)現(xiàn)，提供太多的數(shù)據(jù)產(chǎn)生的噪音對幫助人們最大限度地利用系統(tǒng)的利益起到了適得其反的作用，特別是在用新技術建立“應用文化”的早期階段。

圖7、用戶測試可視化

早期用例1：護理

該技術非常適合幫助護理人員遠離脆弱的家庭成員。Proteus的員工和家人見面，聽了他們的故事。從護理者那里聽到的主要訴求是需要知道媽媽是否早上服用藥物，是否會在下午2點做她的三明治。媽媽的主要需求是要保持尊嚴。Proteus對這種用例的信息可視化涉及可以利用藥物治療和活動數(shù)據(jù)的一個簡單的功能區(qū)，允許家庭成員來看到親人全天的高級概述模式（參見圖CS1-4）?？梢暬梢员苊庵T如心率之類的臨床數(shù)據(jù)，這些數(shù)據(jù)并沒有為家庭成員提供有意義的洞察力，并且有可能在這種個人用例中侵犯媽媽的隱私。

圖8、顯示功能區(qū)的平板電腦應用程序

早期用例2：通知高血壓治療

第二個用例涉及幫助醫(yī)生確定為什么高血壓患者會出現(xiàn)不受控制的癥狀。醫(yī)生對于不服用藥物或由于處方藥物不當而導致病人不受控制的了解甚微。使用Proteus系統(tǒng)兩周后，醫(yī)師可以訪問回答了兩個關鍵問題的簡明報告：病人是否服用藥物，現(xiàn)在是否處于控制狀態(tài)？報告中沒有列出活動數(shù)據(jù)，因為它們在回答醫(yī)生的關鍵問題時沒有用處。大多數(shù)患者由于霍桑效應（Hawthorne effect）而在觀察期間按照規(guī)定服用藥物 - 意識在被觀察會在短時間內(nèi)改變?nèi)说男袨?- 因此臨床醫(yī)生現(xiàn)在已經(jīng)驗證了遵守情況，并指出藥物是否正在起作用。這種組合提供可操作的洞察力，幫助臨床醫(yī)生作出決定是堅持治療還是要升級到下一療程。