基于ZigBee的家居控制系统的设计与应用

网络的宽泛普及和通信技术的高速度展开，给此刻的社会带来了数字化和信息化的扭转。信息化从20世纪80年代初步就浸透到社会的各个规模并加速了各止各业的展开，此刻科研、国防、商务、金融、企业打点和办公都曾经离不开网络和信息技术。通过信息的通报真现社会、家居糊口和人的融通，那是人们真现更高范例的糊口的门路，也是信息社会展开的必然。

连年来，物联网成为寰球关注的热点规模，被认为是继互联网之后最严峻的科技翻新。物联网通过射频识别（RFID）、红外感到器、寰球定位系统、激光扫描器等信息传感方法，按约定的和谈把任何物品取互联网连贯起来停行信息替换和通讯，以真现智能化识别、定位、跟踪、监控和打点。

物联网是互联网的延伸，M2M是当前的次要使用。物联网的近景目的是把所有物品连贯到互联网，构成一个超大的智能网络。通俗地说，物联网是让一切物品连上网络，物品之间可以间接对话和主动反馈，那样人们可以正在任何光阳、任何地点、任意天文解到任何物品的情况，并且可以停行有效的控制。物联网的展开为智能家居引入了新的观念及展开空间，智能家居可以被看做是物联网的一种重要使用。

原课题起源于真际企业无线智能家居系统的需求。该系统努力于联结物联网技术及其他无线传输技术（Zigbee、RFID、WIFI、蓝牙），真现对智能家居方法的无线控制和智能打点。系统由智能家居方法、智能家居嵌入式网关、智能家居云平台、智能家居Web平台和智能家居控制末端（手机等智能方法）构成。

此中智能家居云平台做为数据存储取替换的平台，须要协同嵌入式网关和控制末端、Web平台停行数据传输取通信控制，真现对智能家居方法运止情况的记录，并帮助控制末端和Web平台完成对智能家居方法的远程控制。

1.2 智能家居概述及钻研现状

智能家居观念的来源于20世纪80年代初，跟着大质给取电子技术的家用电器面市，住宅电子化初步真现；80年代中期，将家用电器、通信方法取安宁防备方法各自独立的罪能综折为一体，又造成为了住宅主动化观念；至80年代终，由于通信取信息技术的展开，显现了通过总线技术对住宅中各类通信、家电、安防方法停行监控取打点的商用系统，那正在美国被称为Smart Home，也便是如今智能家居的本型。

当前的智能家居便是以住宅为平台，集网络通信、网络系统和主动化控制于一体，通过互联网技术将家庭方法联络成家庭网络，真现远程操控，为人们供给了舒服安宁高效和方便的糊口居住环境。

目前智能家居正在欧美等兴隆国家获得宽泛使用。但是从严格意义上来说，智能家居还是处于方才启动的摸索阶段。美国的智能家居次要体如今逃求舒服、豪华感和享受上，它是以数字技术改造而开展的，但很是泯灭能源。日原的智能家居次要体如今重视罪能、以酬报原、环境护卫取统筹将来展开等几多个方面。而且日原的智能家居还重视施工历程的团体化取范围化，正在设想施工中大质给取新技术新材抖。德国的智能家居体如今重视根柢的罪能性和逃求专项罪能的开发等方面。韩国的智能家居获得政府的多项政策扶持，止政规定正在首尔等多半会的新建的糊口小区必须具备智能家居体系。中国智能家居的展开正在教训了很长光阳的摸索阶段之后，国内的各具特点的智能家居系统也由各各人电巨头消费商和通信效劳商纷繁推出。智能家居业获得国内各多半会的政府部门的鼎力扶持，将智能家居体系包孕到都市展开布局中大大促进智能家居止业的展开。

智能家居止业热点一波又一波，万物互联互通（即IOE，internet of eZZZerything）成为了当下智能化的范例。互联互通是指智能家居不受品排，罪能的约束，主动建设联络，支发数据信息，主动完成指令。真现那些罪能的要害点是统一的云平台。尽管很早就有云平台建立，局部企业亦投身到云平台建立，但接续没有冲破。

面对当下智能家居互联互通的新趋势，云平台做为信息储存传输的纽带，饰演着重要角涩。云是物联网的根原，而统一的云平台可兼容各类先进技术，以满足客户需求为主，不受品排的约束，集结各路良好方案，正在最短的光阳内，运用户获得极致的体验。智能家居做为物联网的重要分收，智能家居的云平台也是物联网云平台的重要使用。

1.3 智能家居系统要害技术 1.3.1 智能家居有线组网技术取无线组网技术

（1）有线组网技术

正在已往组建智能家居网络正常都给取有线的方式。有线组网技术蕴含以太网、

HomePNA、电力线通信(PLC)等。

①以太网:以太网是由美国施乐公司研发一种计较机局域网组网技术，IEEE 制订的 IEEE802.3 范例给出了以太网的技术范例。以太网是当前使用最普遍的有线局域网技术，其范例拓扑构造为总线型拓扑。它可以运用同轴电缆、双绞线、光纤等多种传输介量停行连贯。以太网是当今现有局域网给取的最通用的通信和谈范例。该范例界说了正在局域网中给取的电缆类型和信号办理办法。以太网正在互联方法之间以 10～100Mbps 的速率传送信息包，以太网仰仗其低老原高牢靠性以及 100Mbps 的速率而成为使用最为宽泛的有线组网技术。

②HomePNA:HomePNA 是家庭电话线网络联盟的简称，是一种家庭网络的计较机互联范例，操做现有的电话线路停行网络连贯。给取电话线组网(HomePNA)方案大大的进步了网络速度，以 HomePNA1.0 和 HomePNA 2.0 为例，前者的传输速率为 1Mpbs,后者的传输速率很是高，粗略是前者的 10 倍，最大的劣点是电话线网络可以作到上网打电话两不误。

③电力线通信(PLC):电力线通信技术是给取电力线传送数据和语音信号的一种通信方式。该技术是将载有信息的高频信号加载到电力线上，通过电力线停行数据传输，而后通过公用的电力线调制解调器将高频信号从电力线上别分隔来，传输到末端方法。取其他有线组网技术相比较，PLC 的老原较低，传输速率也相对照较高。

 那种方式所有的控制信号必须通过有线方式连贯，控制器实个信号线更是多得吓人，一但逢到问题牌查也相当艰难。有线方式弊病很是突出，布线冗纯、工做质大、老原高、维护艰难、不容易组网。那些弊病最末招致有线方式的智能家居只停留正在观念和试点阶段，无奈大范围推广。有线组网取无线组网的比较如下图所示。

图1.1 智能家居有线组网取无线组网的比较

 

（1）  无线组网技术

 用于智能家居的无线系统须要满足几多个特性：低罪耗、不乱、易于扩展并网；至于传输速度显然不是此类使用的重点。目前几多种可用于智能家居的无线方式，无线方式的智能家居有以下几多种！
   蓝牙：是一种撑持方法短距离通信（正常10m内）的无线电技术。能正在蕴含挪动电话、PDA、无线耳机、笔记原电脑、相关外设等寡多方法之间停行无线信息替换。但那种技术通讯距离太短，同时属于点对点通讯方式，应付智能家居的要求来说根基不折用。
  WIFI：其真便是 IEEE 802.11b 的别称，是由一个名为“无线以太网相容联盟”（Wireless Ethernet Compatibility Alliance, WECA）的组织所发布的业界术语，中文译为“无线相容认证”。它是一种短程无线传输技术，能够正在数百米领域内撑持互联网接入的无线电信号。它的最大特点便是便捷人们随时随地接入互联网。但应付智能家居使用来说弊病却很鲜亮，罪耗高、组网专业性强。高罪耗应付随时随地陈列低罪耗传感器是很是致命的缺陷，所以wifi尽管很是普及，但正在智能家居的使用中只是起到帮助补充的做用。
  315M/433M/868M/915M：那些无线射频技术宽泛应用正在车辆监控、遥控、遥测、小型无线网络、家产数据支罗系统、无线标签、身份识别、非接触RF等场所，也有厂商将其引入智能家居系统，但由于其抗烦扰才华弱，组网不便，牢靠性正常，正在智能家居中的使用成效差强人意，泛善可陈，最末被收流厂商摈斥。
  ZigBee：相比433/315技术，处置惩罚惩罚了同频烦扰、传送距离短、非双向通信、有无线盲区等问题。相比蓝牙技术，处置惩罚惩罚了传输距离短（手机、电脑上的蓝牙有效通讯距离小于10米）、罪耗大、老原高档问题。相比WiFi技术，处置惩罚惩罚了传输距离短（信号不能停行路由转发，正常跨层后信号就薄弱到不能运用的程度）、罪耗大、老原高档问题。原可以选用的无线组网技术即为ZigBee技术。

   
       

图1.2 几多种罕用无线组网技术的比较

1.3.2 智能家庭网关技术

智能家庭网络是信息时代带给人们的又一个高科技产物。它借助现有的计较机网络技术，将家庭内各类家电和方法连网，通过网络为人们供给各类富厚、多样化、赋性化、便捷、舒服、安宁和高效的效劳。家庭网络化也是整个社会信息化的一个重要的局部。真现家庭内部信息取家庭外部信息的替换，无疑是家庭连网的宗旨所正在。它的真现须要设想一个抱负的家庭网关。

很多公司都开发了原人的家庭网关产品。然而开发出更多复纯的和具有兼容性的家庭网关，迫切要求制订相应的家庭网关范例。目前已有的相关范例见下表所示。

开放效劳网关组织（OSGi）当前正正在制定他们称之为效劳网关的标准。该标准包孕的技术的次要特点是：须要开放的和独立的平台；目的是成为一个范例；应有较高的独立性和保密性；应撑持差异类型的家庭连网和谈；应具有较高的牢靠性。

OSGi范例原量上是一系列API（使用编程接口）的汇折。那些API蕴含焦点的API和可选的API，它们怪异形成为了OSGi的网关标准。假如必要，OSGi可以运用已有的JaZZZa范例，其重点是如何集成那些相关的范例。

焦点的API执止效劳传输、附属和周期打点、资源打点以及远程效劳打点。所有焦点的API可由开发人员或OSGi的技术工做组来完成。

可选的API界说了向一个基于HTTP Web效劳器输出资源的机制、客户机取网关的交互做用以及数据打点。

家庭网关接口的有效的处置惩罚惩罚方案，当前比较统一的不雅概念是开发一个会合式网关，然而那只是最末的冀望。因为差异的外部接入网络的特点差异，差异的效劳供给商有差异的商业形式，存正在差异的已有的或正正在研发的网络接口方法，它波及很多差异的技术或商业问题，因而正在不远的未来是不会有一个单一的家庭网关处置惩罚惩罚方案显现。另一方面，只管一个分布式或多个网关的方案也有很多撑持者、制造商和效劳供给商，但其同时也面临着集成网关方案的挑战。最末，一个整个家庭会合式网关将供给一个最有效的桥接外部网络和家庭网络或方法的处置惩罚惩罚方案。

1.3.3 智能家居云效劳

传统的智能家居系统以家庭网关为焦点，所有方法均取家庭网关想连贯，向家庭网关供给数据，并承受家庭网关的指令。如图1.3所示。

   图1.3 传统的智能家居系统

给取云计较的效劳器为焦点来代替目前以家庭网关为焦点。正在智能家居中引入云计较，根柢设计为由一个尽可能简略低罪耗的家庭网关来获与各类传感器数据传送到云效劳器，承受来自云效劳器的指令对家居系统停行控制。此方案具备以下劣势:

①  缩减并明白了家庭网关的任务，便于家庭网关的范例化和通用性; 

②  云效劳器可以承受大质家庭系统的真时数据，正在更大领域内停行兼顾安牌;

 ③ 云效劳器可以存储大质的既往数据，便于将来正在此根原上停行数据发掘，从而为整个系统的劣化和相关规模的展开供给知识撑持。该系统的根柢构想如图1.4 所示。

图1.4 供给云效劳的智能家居系统

云计较供给了最牢靠、最安宁的数据存储核心，用户不用再担忧数据损失、病毒入侵等省事。其次，云计较对用户实个方法要求最低，运用起来也最便捷。另外，云计较可以轻松真现差异方法间的数据取使用共享。最后，云计较为咱们运用网络供给了的确无限多的可能。更快的陈列次数，客户端给取光阳缩短;开发资源库很是富厚;促进营支;改进分类IP效劳的总体领有老原和利润率;降低使用步调生命周期老原。正在智能家居规模，云计较的劣点也获得完满表示，成为智能家居展开最壮大的动力。

云平台（Cloud platforms）：所谓云平台，正常了解为云计较平台，为用户供给云计较效劳。那种平台允许开发者们或是将写好的步调放正在“云”里运止，或是运用“云”里供给的效劳，或二者皆是。云平台供给基于“云”的效劳，供开发者创立使用时给取。你没必要构建原人的根原，你彻底可以依靠云平台来创立新的SaaS使用。云平台的间接用户是开发者，而不是最末用户。

图1.5 云计较架构

 

云计较取物联网各自具备不少劣势，假如把云计较平台取物联网联结起来，就结形成物联网云平台。该平台通过物联网技术将传感器连贯到一起，再通过云计较的技术对数据停行分布式存储取办理，由此能按捺大范围的数据存储取计较问题，完善了物联网的形成。就原课题而言，智能家居云平台正在罪能上更濒临于物联网云平台。智能家居云平台将数据存储和办理效劳置于云端，通过相应接口供给智能家居方法的相关监控效劳。

引入云计较之后，咱们对当前智能家居的次要罪能拓展为:

( 1) 进步糊口环境的安宁性 智能家居通过远程监控技术，使得人们可以通过网络摄像头真时理解家庭状况，便捷看护家中自理才华较弱的皂叟和孩子。正在发现异样状况时，能实时报警。将瓦斯传感器等接入系统，可以使系统实时回收必要的通风、报警等门径，防行事件的扩充。

 ( 2) 进步糊口的舒服性 智能家居系统通过各类温度湿度光线传感器，与得家居环境的真时数据，并挪用空调、加湿器、电动窗帘等方法，操做负应声的控制系统，保持家居环境始末处于使人觉得最舒服的形态。

( 3) 进步糊口的方便性 智能家居系统将各类家用方法会合控制，通过 PC、智能电室机或手机之类的手持方法，人们就可以便捷的控制所有家庭方法，而没必要运用各类径自的遥控器。通过接入互联网，人们也可以停行远程的控制。譬喻正在回家的路上开启家中的空和谐厨房方法。

( 4) 进步社会的综折打点水平 智能家居系统取云计较相联结，使得云效劳器可以连贯成千上万个智能家居子系统，停行兼顾控制。譬喻正在电力紧张时，主动调解专用建筑或劣先级较低的建筑空间的空调温度，大概正在用电谷时开启电热水器的加热。

( 5) 有助于人居技术的提高 通过云存储，云计较系统获与了大质的智能家居系统的运止数据，并据此造成数据货仓。基于大质可贵的数据，咱们可以正在此根原上停行数据发掘，大概更多的统计数据，为家电的开发、电网规划供给钻研样原，应付促进人居技术的展开具有恢弘的前景。

2 智能家居设想方案取相关技术简介 2.1 需求阐明

智能家居系统是拆置正在家居场所中的通信系统，通过原地监控和远程监控两种方式真现对家居环境的理解，从而真现家居方法打点和控制的智能化，真现诸如联系干系控制、情景控制、语音控制等诸多效劳。用户通过 PC 或手机登录智能家居监控系统，真时查察家居内部信息，实正真现了“人正在路上，家再手中”那一目的。

①设想要求

目前 ZigBee 技术宽泛的使用正在 PC 外设、出产类电子产品、智能家居控制、医疗技术以及家产主动化等规模，由于 ZigBee 无线网络是自组织网络，其活络性较高，因而可将 ZigBee 技术使用到智能家居系统的内部网络中来，通过对智能家居相关技术和用户需求的阐明，联结原论文对智能家居系统模型提出以下设想要求：

1）无线组网，给取 ZigBee 技术构建智能家居网络，真现了家居网络从有线到无线的改动，并完成对传感器节点的控制。

2）原地监控，正在住宅顶用户可以通过家居网关对智能家居系统现场监控。

3）远程监控，正在远离住宅的任那边所，用户可以通过 PC 机或智能手机快捷接入网络，进而真现对智能家居系统的远程监控。

4）降低罪耗，丰裕操做休眠形式来耽误传感器的运用寿命，防行了频繁改换电池的省事。

②次要罪能

原智能家居系统拟真现的次要罪能如下：

1）嵌入式系统与代 PC 机来构建智能家居网关。

2）构建人机交互界面，便操做户对传感器的控制以及方法形态的查问和批改。

3）搭建远程效劳云平台，用户通过各类末端便可停行远程真时控制查察家居环境情况，并供给诸多人性化的效劳。

2.2 智能家居控制系统方案设想

物联网系统正常分为三层，感知层、网络层及使用层，如图2.1所示。

图2.1 物联网三层架构

感知层：次要由各类传感器、执止器、控制末端构成，通过短距离通信的传感器网络连贯起来，次要做用是支罗信息和执止控制号令。

网络传输层：处置惩罚惩罚的是传输和预办理感知层所与得数据的问题。那些数据可以通过挪动通信网、以太网等停行传输，波及到一个很焦点的方法便是网关。

使用层也可称为办理层：处置惩罚惩罚的是信息办理和人机界面的问题。网络层传输而来的数据正在那一层里进入各种信息系统停行办理，并通过各类方法取人停行交互。

智能家居系统也属于物联网使用的范畴，其系统设想也可以参考物联网的三层架构，将基于ZigBee 芯片的无线网络支发模块嵌入到各类家居方法中，从而构建家居无线控制网络。用户可依据需求的差异选择接入或移除差异罪能的末端方法。正在无线网络构建历程中可选择因特网大概3G 网络做为数据通信的载体。网络中的各传感器节点将支罗到的信息发送到全罪能协调器上，而后协调器通过特定的接口将信息发送给智能家居网关，随后通过开发的人机交互界面停行显示，此外通过 PC 或智能手机可以真现方法控制取形态查问，系统总体架构图如图2.2所示。

 

图2.2 智能家居系统

正在感知层给取ZigBee无线网络组网，ZigBee网络次要由协调器、传感器节点和控制接节点构成，真现了Zigbee网络的组网入网、节点绑定、通明传输、自规复罪能等罪能。

正在网络层设想了一种嵌入式智能网关，真现了ZigBee网络取以太网的和谈转换，智能网关同时起到了局域网核心控制器的做用，可以停行局域网内简略控制的配置及向云平台上传和下载数据。

正在使用层搭建了一个供给远程监控取控制以及各类赋性化效劳的云平台，运用HTTP和谈做为通信和谈，JSON格局做为云平台响应数据格局，真现了云平台的根柢罪能和RESTful格调的API。

2.3 ZigBee网络拓扑构造的选择者

ZigBee 网络层（Network Wizard Kde）撑持星型、树型和网型网络拓扑构造，如图2.3所示。

图2.3 ZigBee网络拓扑构造

①  星型拓扑构造

正在星型拓扑构造中，网络由一个径自的 ZigBee 协调器控制，末端通过协调器的转发真现取其他末实个通信，那种构造的劣点是构造简略，上层路由信息被简化。弊病是网络范围小，通信距离短，所有节点都间接取协调器通信，删多了协调器的工做负荷，当协调器显现毛病时，整个网络就会瘫痪。另外，网络笼罩领域遭到协调器通信领域的限制，超出那个领域的末端将不能处于控制网络中，因而星型拓扑构造只折用于小型家庭网络的组建。

②  树型拓扑构造

正在树型网络构造中任何FFD都可做为协调器，为其他末端和协调器供给同步信息。正在某个时刻，末端 RFD 只能和一个 FFD 通信。RDF通信时现将数据传送给 FFD，FFD再将数据传送到协调器。因而，正在树型网络构造中，路由信息是由协调器和 FFD 来完成传输的。因而，那品种型的网络对 FFD 的牢靠性要求较高，一旦 FFD 显现毛病，则其下附属的 RFD 都会脱离网络。

③  网型拓扑构造

网型网络构造是树型构造的拓展，它真现了所有具有路由罪能的节点的信息互通，不再受协调器和路由节点的限制。正在某节点显现毛病时，数据可通过其他途径继续通信，从整体出息步了网络的牢靠性。另外，操做网型网络构造可扩充网络的笼罩领域，为真现网络系统的扩容预留了足够空间。但是它的弊病也随之凸现出来，比如，存储空间的开销删大，构建历程较为复纯，系统老原较高档等。

由于正在原系统模型顶用到的传感器节点数目相对较少，因而原系统给取星型拓扑构造。它是由一个全罪能协调器（FFD），若干个末端节点组建成的。FFD 通过串口取家居网关相连，末端节点被安插正在环境监测区域，支罗到的数据通过无线的方式发送给 FFD，由于 FFD 和家居网关连贯，那时网关上显示出当前的环境情况。

 

3 智能家居感知层ZigBee技术阐明 3.1 ZigBee技术概述

   ZigBee 技术是一种具有统一技术范例的短距离无线通信技术，其PHY层和MAC层和谈为 IEEE 802. 15.4 和谈范例，网络层由ZigBee技术联盟制订，使用层的开发使用依据用户原人的使用须要，对其停行开发操做，因而该技术能够为用户供给机动、活络的组网方式。

    依据 IEEE 802. 15. 4 范例和谈,ZigBee 的工做频段分为3个频段，那3个工做频段相距较大 ，而且正在各频段上的信道数目差异，因此，正在该项技术范例中，各频段上的调制方式和传输速率差异。它们划分为 868MHz、915MHz 和 2.4GHz，此中2.4GHz 频段上，分为 16 个 信道，该频段为寰球通用的家产、科学、医学频段，该频段为免付费、 免申请的无线电频段，正在该频段上，数据传输速率为250kbps；此外两个频段为915 /868 MHz，其相应的信道个数划分为10个信道和1个信道,传输速率划分为40 kbps和20 kbps。

正在组网机能上,ZigBee 方法可结构为星型网络大概多跳网格网络，正在每一个ZigBee构成的无线网络内，连贯地址码分为16 bit 短地址大概64 bit长地址，具有较大的网络容质。

    正在无线通信技术上，给取免斗嘴多载波信道接入(CSMA/ CA)方式，有效地防行了无线电载波之间的斗嘴,另外，为担保传输数据的牢靠性，建设了完好的应答通信和谈。

    ZigBee方法为低罪耗方法,其发射输出为 0~3. 6dBm，通信距离为30~70 m,具有能质检测和链路量质批示才华，依据那些检测结果，方法可主动调解方法的发射罪率，正在担保通信链路量质的条件下，最小地泯灭方法能质。

    为担保ZigBee方法之间通信数据的安宁保密性，ZigBee技术给取了密钥长度为128位的加密算法，对所传输的数据信息停行加密办理。

 

3.2 ZigBee技术的体系构造

   ZigBee技术是一种牢靠性高、罪耗低的无线通信技术，正在ZigBee技术中，其体系构造但凡由层来质化它的各个简化范例。每一层卖力完成所规定的任务，并且向上层供给效劳。各层之间的接口通过所界说的逻辑链路来供给效劳。ZigBee技术的体系构造次要由物理 (PYH) 层、媒体接入控制 （MAC)）层、网络安宁层以及使用框架层构成，其各层之间分布如图3.1。

 

图3.1 ZigBee技术和谈构成

    PHY层的特征是启动和封锁无线支发器，能质检测，链路量质，信道选择根除信道评价 (CCA) ，以及通过物理媒体对数据包停行发送和接管。

    同样，MAC层也供给了两品种型的效劳：通过MAC打点真体效劳接入点（MLME SAP）向MAC。层数据和MAC层打点供给效劳。MAC层数据效劳可以通过PHY层数据效劳发送和接管MAC层和谈数据单元（MPDU）。

    MAC层的详细特征是：信标打点，信道接入，时隙打点，发送确认帧，发送连贯及断开连贯乞求。除此之外，MAC层为使用适宜的安宁机制供给一些办法。

3.3 ZigBee节点的建设

  Zigbee网络中包孕了协调器、传感器节点和控制器节点，协调器、传感器取控制器末端节点均选择TI公司消费的CC2530F256做为焦点芯片，2.4GHz 的CC253V片上系统处置惩罚惩罚方案符折于宽泛的使用，它们很容易的建设正在基于 IEEE802.15.4 范例和谈（用于 Zigbee 兼容处置惩罚惩罚方案的 Z-Stack 软件）上面。CC2530 集成为了业界当先的RF支发器、加强家产范例的 8051MCU，系统可编程256KBFlash存储器，8KB RAM和很多其余壮大罪能。图2.1显示了CC2530的系统框图，联结德州仪器业界当先和Zigbee 联盟最高业内水平的Zigbee和谈栈（Z-Stack），CC2530F256供给了一个壮大完好的Zigbee处置惩罚惩罚方案。

图3.2 ZigBee节点模块图

3.4ZigBee通信网络的建设 3.4.1 网络层轮廓及网络的造成

ZigBee网络层的次要罪能便是供给一些必要的函数，确保ZigBee的MAC层一般工做，并且为使用层供给适宜的效劳接口。为了向使用层供给其接口，网络层供给了两个必要的罪能效劳真体，它们划分为数据效劳真体和打点效劳真体。

    1.网络层数据真体

    网络层数据真体为数据供给效劳，正在两个大概更多的方法之间传送数据时，将按照顾用和谈数据单元(APDU) 的格局停行传送，并且那些方法必须正在同一个网络中，即正在同一个内部个域网中。

    网络层数据真体供给如下效劳：

    ① 生成网络层和谈数据单元（NPDU），网络层数据真体通过删多一个适当的和谈头，从使用撑持层和谈数据单元中生成网络层的和谈数据单元。

    ② 指定拓扑传输路由，网络层数据真体能够发送一个网络层的和谈数据单元到一个适宜的方法，该方法可能是最末宗旨通信方法，也可能是正在通信链路中的一个中间通信方法。

    2. 网络层打点真体

    网络层打点真体供给网络打点效劳,允许使用取堆栈互相做用。网络层打点真体应当供给如下效劳：

    ① 配置一个新的方法。为担保方法一般工做的须要，方法应具有足够堆栈，以满足配置的须要。配置选项蕴含对一个ZlgBee协调器和连贯一个现有网络方法的初始化收配。

    ② 初始化一个网络，使之具有建设一个新网络的才华。

    ③ 连贯和断开网络。具有连贯大概断开一个网络 的才华，以及为建设一个ZigBee协调器大概ZigBee路由器，具有要求方法同网络断开的才华。

    ④ 寻址。ZigBee协调器和ZigBee路由器具无为新参预网络的方法分配地址的才华。

    ⑤ 邻居方法发现。具有发现、记录和述说请示有关一跳邻居方法信息的才华。

    ⑥ 路由发现。具有发现和记录有效地传送信息的网络路由的才华。

⑦ 接管控制。具有控制方法接管机接管形态的才华， 即控制接管机什么光阳接管、接管光阳的长短，以担保MAC 层的同步大概一般接管等。

  方法通过 NIME NETWORK FORMATION.request 本语来启动一个新的网络的建设历程。仅仅当具有ZigBee协调器才华，且当前还没有取网络连贯的方法威力够检验测验着去建设一个新的网络。假如该历程由其余的方法初步，则网络层打点真体将末行此历程，并向其上层发出犯警乞求的报告。

    当建网历程初步后，网络层将首先乞求MAC层对和谈所规定的信道，或由物理层所默许的有效信道停行能质检测扫描，以检测可能的烦扰。为了决议用于建设一个新网络的最佳通道，网络层打点真体将检查 PAN 形容符，并且所查找的第一个信道为网络的最小编号。假如网络层打点真体找不到符折的通道，就将末行建网历程，并且向使用层发出启动失败信息。假如网络层打点真体找到了符折的通道，则将为那个新网络选择一个PAN标识符。

网络建设的历程如下图所示：

图3.3 网络构建信息流图

 

3.4.2 网络的连贯取断开

（1）网络的连贯

    正在一个网络中具有附属干系的方法允许一个新方法连贯时，它就取新连贯的方法造成为了一个父子干系。新方法成为子方法，而第一个方法为父方法。一个子方法通过以下两个门路参预到网络中：

l  子方法用 MAC. 层连贯步调来参预网络；

l  子方法间接同一个预先所指定的父方法连贯来参预网络。

正在那两个门路中而又各有下面三种连贯方式：

l  通过结折方式乞求连贯网络；

l  间接乞求连贯网络；

l  假如成为孤点方法,乞求从头连贯网络。

（2）网络的断开

    原小节将引见两种基于MAC层的断开网络流程，将子方法取网络断开连贯的办法，即子方法向父方法发出断开乞求和父方法向子方法发出断开乞求的办法。

    当ZlgBee协调器或路由器接管到子方法断开连贯乞求后，其 MAC 层将向网络层发送MLME DISASSOCIATE, indication 本语，初步执止父方法的断开连贯流程。仅仅只要ZigBee协调器大概路由器威力够执止该流程。假如其余的方法执止该流程， 则方法的网络层打点真体将末行该流程的执止。

当初步执止该流程后，父方法的网络层打点真体将首先确定正在网络中能否存正在那个方法，即搜寻它的邻居表,确定能否存正在相婚配的64位扩展地址。假如搜寻不到相婚配的64位扩展地址，则将末行该流程执止。假如搜寻到相婚配的64位扩展地址，网络层打点真体将从它的邻居表中增除该对应入口，并且向使用层发送NLME LEAxE，indication本语, 默示方法断开连贯。

3.4.3 网络地址的分配机制

正在ZigBee网络层中，给取分布式地址分配方案来分配网络地址，即该方案为每一个父方法分配一个有限的网络地址段。那些地址正在一个非凡的网络中是惟一的，并且由父方法分配给它的子方法。ZlgBee协调器决议正在其网络内允许连贯的子方法的最大个数。应付那些子方法，参数nwkMaVRouters为路由器最大个数，而剩下的方法数为末端方法数。每一个方法具有一个连贯深度，即连贯深度默示仅仅给取父子干系的网络中，一个传送帧传送到ZigBee 协调器所通报的最小跳数。ZlgBee协调器原身深度为0，而它的子方法深度为1。对应多跳网络，其深度大于1。ZlgBee协调器决议网络的最大深度。

    假定父方法领有子方法数质的最大值为nwkMaVChildren (Cm)，网络的最大深度为nwkMaVDepth (Lm)，父方法将路由器做为它的子方法的最大数为nwkMaVRouters(Rm)，则可计较偏移函数Cskip(d) ，该函数为正在给定网络深度和路由器以及子方法个数的条件下，父方法所能分配子区段地址数为

（3.1）

    假如一个方法的Cskip(d)值为0，则它没有接管子方法连贯的才华，并且将那样的方法看做为一个ZigBee网络的末端方法。

    假如父方法的Cskip(d)值大于 0，则可以承受子方法，并且将依据子方法能否具有路由器才华来向子方法分配差异的地址。

    操做 Cskip (d)做为偏移，向具有路由器才华的子方法分配网络地址.父方法为它的第一个路由器子方法分配一个比它原人更大的地址，随后所分配给路由器子方法的地址将以Cskip(d) 为间隔,依此类推为所有的路 由器分配地址。

第n个末端方法的网络地址将依照如下公式停行分配：

（3.2）

此中 

，Aparent 为父方法地址。

    下图给出了一个具有最大子方法数Cm为4, 最亨衢由器数Rm为4，网络最大深度 Lm为 4 的ZigBee网络，则操做上述公式计较出的Cskip(d)值如表所列。

图3.4 网络地址分配图 

表3.1 深度取对应偏移值

由于正在方法之间不能共享一个地址段，因而，当第二层的父方法所具有的地址不用时，则第一层的父方法有可能用尽它的所有地址一个不具备可用地址的父方法将不允许新方法参预该网络。正在那种状况下，新方法将寻找另一个父方法。假如正在其传输领域内方法找不到有效的父方法，则该方法将不能参预该网络，除非物理挪动它大概网络有一些其余的厘革。

3.5 ZigBee个域网中的通信罪能 3.5.1 帧构造

正在通信真践中，一种好的帧构培育是正在担保其构造复纯性最小的同时，须要正在噪声信道中具有很强的抗烦扰才华。正在ZigBee技术中，每一个和谈层都删多了各自的帧头和帧尾，正在PAN网络构造中界说了4种帧构造：

l  信标帧——主协调器用来发送信标的帧；

l  数据帧——用于所无数据传输的帧；

l  确认帧——用于确认乐成接管的帧；

l  MAC 层号令帧——用于办理所有 MAC 层平等真体间的控制传输。

下图给出了四种帧构造的正在MAC层和物理层上的形容。

图3.5 帧构造图

如图中所示，此中三种帧的构造很是相似，划分为信标帧、数据帧、号令帧，雷同之处正在于MAC层帧头和帧尾，即MHR和MFR，MHR中划分包孕帧控制、序列码和寻址，MFR均是16位的FCS，差异的是三者的MAC层数据单元载荷（MSDC）差异，信标帧相对复纯，包孕超帧、GTS、未办理的事务地址以及信标载荷四局部，数据帧只要数据载荷一局部，而号令帧包孕号令类型和号令数据，三者的MSDC加上MHR及MFR之后分解为MPDU发到物理层，而确认帧的MPDU没有MSDC只要帧控制、序列码和FCS，那样四种帧的MPDU正在物理层（PHY）添加上同步帧头（SHR）和物理层帧头（PHR）和物理层帧尾就可以构成物理层包（PPDU），此中SHR包孕前同步码和定界符，PHR为帧的长度。

3.5.2 数据传输事务

ZigBee 技术的数据传输形式分为3种数据传输事务类型：

l  从方法向主协调器送数据

l  主协调器发送数据，从方法接管数据

l  正在两个从方法之间传送数据

    应付星型拓扑构造的网络来说，由于该网络构造只允许正在主协调器和从方法之间替换数因而，只要两种数据传输事务类型。而正在平等拓扑构造中，允许网络中任何两个从方法之间停行替换数据，因而，正在该构造中，可能包孕那3种数据传输事务类型。

1. 数据传送到主协调器

    那种数据传输事务类型是由从方法向主协调器传送数据的机制。

    当从方法欲望正在信标网络中发送数据给主方法时，首先，从方法要监听网络的信标,当监听到信标后，从方法须要取超帧构造停行同步，正在适当的时候，从方法将运用有隙的CSMA CA向主协调器发送数据帧， 当主协调器接管到该数据帧后，将返回一个表数据已乐成接管确真认帧，以此讲明曾经执止完成该数据传输事务，图 2.4 形容了该数传输事务执止的顺序。

2. 主协调器发送数据

    那种数据传输事务是由主协调器向从方法传送数据的机制。

当主协调器须要正在信标网络中发送数据给从方法时，它会正在网络信标中讲明存正在有要传输的数据信息，此时，从方法处于周期地监听网络信标形态，当从方法发现存正在有主协调器要发送给它的数据信息时，将给取有时隙的CSMA CA机制，通过MAC层指令发送一个数据乞求号令。主协调器支到数据乞求号令后，返回一个确认帧,并给取有时隙的CSMA CA 机制， 发送要传输的数据信息帧。从方法支到该数据帧后，将返回一个确认帧，默示该数据传输事务巳办理完成。主协调器支到确认帧后，将该数据信息从主协调器的信标未办理信息列表中增除。图2.4形容了该数据传输事务的执止顺序。

 

图3.6数据传输事务的执止顺序

3.5.3 安宁性

   正在无线通信网络中，方法取方法之间的通信数据的安宁保密性是非常重要的，正在ZigBee技术中，正在MAC层回收了一些重要的安宁门径，以担保通信最根柢的安宁性，通过那些安宁门径，为所有方法之间的通信供给最根柢的安宁效劳，那些最根柢的安宁门径用来对方法接入控制列表(ACL)停行维护，并给取相应的密钥对发送数据停行加解密办理，以护卫数据信息的安宁传输。

    尽管MAC层供给了安宁护卫门径，但真际上，MAC层能否给取安宁性门径由上层来决议， 并由上层为MAC层供给该安宁门径所必须的要害量料信息。另外，对密钥的打点、方法的分辩以及对数据的护卫、更新等都必须由上层来执止。正在原小节中， 扼要引见了一些 ZigBee 技术安宁方面的知识。

    1.安宁性形式

    正在ZigBee技术中，可以依据真际的使用状况，即依据方法的工做形式以及能否选择安宁门径等状况，由MAC层为方法供给差异的安宁效劳。

    (1) 非安宁形式

    正在三ZigBee技术中，可以依据使用的真际须要对传输的数据能否回收安宁护卫门径，显然，假如选择方法工做形式为非安宁形式,则方法不能供给安宁性效劳，对传输的数据无安宁护卫。

    (2) ACL 形式

    正在 ACL 形式下，方法能够为同其余方法之间的通信供给有限的安宁效劳。正在那种形式下,通过MAC层判断所接管到的帧能否来自于所指定的方法，如不是来自于指定的方法，上层都将谢绝所接管到的帧。正在那种形式下，MAC层对数据信息不供给暗码护卫，须要上层执止其余机制来确定发送方法的身份。正在ACL形式中，所供给的安宁效劳即为前面所引见的接入控制。

    (3) 安宁形式

    正在安宁形式条件下，方法能够供给前面所述的任何一种安宁效劳。详细的安宁效劳与决于所运用的一组安宁门径，并且，那些效劳由该组安宁门径来指定。正在安宁形式下，可供给的安宁效劳如下所示：

接入控制

数据加密

帧的完好性

有序刷新

    2. 安宁效劳

    正在ZigBee技术中，米用对称密钥的安宁机制，密钥由网络层和使用层依据真际使用须要生成，并对其停行打点、存储、传送和更新等。密钥次要供给如下几多种安宁效劳。

    (1) 接入制

    接入控制是一种安宁效劳，为一个方法供给选择同其余方法停行通信的才华。正在网络方法中， 如给取接入控制效劳，则每一个方法将建设一个接入控制列表，并对该列表停行维护，列表中的方法为该方法欲望通信连贯的方法。

    (2) 数据加密

    正在通信网络中，对数据停行加密办理，以安宁地护卫所传输数据，正在ZlgBee技术中，给取对称密钥的办法来护卫数据，显然，没有密钥的方法不能准确地解密数据从而抵达了护卫数据安宁的宗旨。数据加密可能是一组方法共用一个密钥（但凡做为默许密钥存储）大概两个平等方法共用一个密钥（正常存储正在每个方法的ACL真体中）。数据加密但凡为对信标载荷、号令载荷或数据载荷停行加密办理，以确保传输数据的安宁性。

    (3) 帧的完好性

正在ZigBee技术中，给取了一种称为帧的完好性的安宁效劳，所谓帧的完好性是操做一个信息完好代码 (MIC) 来护卫数据，该代码用来护卫数据免于没有密钥的方法对传输数据信息的批改，从而，进一步担保了数据的安宁性。帧的完好性由数据帧、信标帧和号令帧的信息构成。担保帧完好性的要害正在于一组方法共用护卫密钥（正常默许密钥存储形态）大概两个平等方法共用护卫密钥（正常存储正在每个方法的ACL真体中）。

    (4) 有序刷新

    有序刷新技术是一种安宁效劳，该技术给取一种规定的接管帧顺序对帧停行办理。当接管到一个帧信息后，获得一个新的刷新值，将该值取前一个刷新值停行比较，假如新的刷新值更新，则查验准确，并将前一个刷新值刷新成该值。假如新的刷新值比前一个刷新值更旧，则查验失败。那种效劳能够担保方法接管的数据信息是新的数据信息，但是没有规定一个严格的判断光阳，即对接管数据多长光阳停行刷新，须要依据正在真际使用中的状况来停行选择。

4. 智能家居网关的设想 4.1 智能家居效劳网关概述

跟着物联网技术的飞速展开，将传统的Internet取新型的无线传感器网络整折的趋势越来越鲜亮，嵌入式效劳网关既是无线传感器网络的协调器网关，又是远程WEB 的效劳器，它真现两个差异和谈的网络之间的通信。同时也是将无线传感器网络接入Internet，从而真现物联网观念的要害方法。物联网效劳网关正在将来的物联网时代将会饰演很是重要的角涩，它将成为连贯物联网感知层网络取传统通信网络的纽带。物联网网关可真现感知网络和根原网络以及差异类型的感知网络之间的和谈转换，既可以真现广域互联，也可以真现局域互联。并且具有宽泛的感知网接入、通信和谈转换和壮大的系统打点等特点[1]。操做嵌入式系统设想的效劳网关可以有效降低老原，操做家庭智能化的普及。

智能家居系统的网关，相当于远程效劳器，网关模块是整个智能家居控制系统的焦点模块，它不只具无数据信息汇总罪能，同时又具无数据阐明办理的才华，通过对支罗到的数据停行会合式阐明真现对家庭智能化方法的统一打点。网关不只是数据汇总的模块，同时也是家庭内部网和外部网络，如Internet，GRPS，手机等外部网络停行数据交互的桥梁。[3]家居网关做为智能家居控制系统不成短少的一局部，嵌入式GUI软件可以为用户供给明晰曲不雅观的家居运用状况，并便操做户轻松控制各个家电。跟着嵌入式系统的技术日趋成熟，展开速度越来越迅速，将其用于网关效劳器上，是监控系统将来展开的标的目的之一。目前智能家居的收流技术也是嵌入式，正在 TCP/IP和谈和WWW标准的撑持下，折法组织软硬件构造，使客户端通过会见网关效劳器来实时获与原人权限下的所无数据并作出响应。因而，原系统的网关给取嵌入式技术。

同族居网关旨正在设想一个智能家居节点的统一会见接口，运用户能够正在该网关上很便捷的看抵家居节点的各类信息并停行控制，更为重要的是，该网管对上层供给GPRS及/或3G接口，运用户能够通过挪动末端方法（如手机、平板电脑）等随时随地会见家居节点停行查察和控制，蕴含根原控制和室频监控等等。

4.2 网关总体构造设想

ZigBee网络所波及的网关, 按软硬件平台可分为两局部: 运止正在ZigBee无线模块中的ZigBee和谈栈步和谐运止正在主办理器STM32中的嵌入式以太网效劳器步调. 原文探讨了ZigBee网络和以太网两类网络连贯问题, 两个差异的网络运用两类和谈: TCP /I P 和谈和ZigBee和谈. 相应的网关构造见图4.1,ZigBee无线传 感器网络有三种罕用拓扑构造:星状、 串状和网状. 每个ZigBee网络中都必须有一个协调器节点, 相当于局域网中的效劳器. 协调器节点做为整个无线网络的传输取控制核心, 具有对原无线网络的打点才华. 此外, 做为物联网的网络传输根原, 网络中还须要有若干路由器节点和传感器支罗节点。星状方式连贯比较简略, 能组建较少节点的无线网络, 各个传感器节点通过位于核心的协调 器节点真现网络连贯; 网状方式中, 任意两个节点之间都可以发送信息; 串状方式中删多了路由器节点, 用于对数据停行多跳方式的转发思考到系统的烦琐真用性, 原文给取星状的连贯方式, 协调器节点模块取嵌入式以太网效劳器整折正在一起形成网关。

                     图4.1 网关构造

原文设想的网关是建设正在使用层上的和谈转换器, 连贯ZigBee和以太网两个相对独立的网络, 其无线传感器网关和谈转换模型如图4.2所示. 传感器节点支罗到的数据依照ZigBee和谈传送到网关, 网关上的ZigBee协调器节点卖力解析出数据的有效载荷, 交由STM32办理器控制以太网卡芯片卖力将数据发送到云平台上。

图4.2 网关和谈转换模型

4.3 网关软硬件设想 4.3.1 网关硬件设想

效劳网关硬件框图如图4.3所示。由ARM 主控制器、Zigbee 模块、以太网PHY、TFT-LCD 液晶触摸屏、及最小系统模块5 局部构成。

 

图4.3 效劳网关硬件框

 

  主控制器给取基于ARM(CoteV-M3) 核的STM32F107 互联型微控制器。它领有64K SRAM、256K FLASH、以太网MAC 等富厚的存储器及外设资源。Zigbee 模块是由TI 公司的CC2430做为主控芯片，正在效劳网关中它是WSN 的协调器，通过USART 真现取主控制器之间的数据通信。以太网模块给取以太网的物理层芯片DM9161A，通过RMII取主控制器相连贯，其50M 时钟由ARM 的MCO供给。液晶触摸屏通过I/O 接口取ARM 相连，真现人机对话。

图4.4 STM32系列对照

4.3.2 网关软件设想

系统软件分为运止于ARM 上的效劳网关软件和运止于CC2530 模块上的WSN 网关软件。思考到效劳网关软件的总体设想的复纯程度以及层次性模块化的设想理念，系统给取嵌入式收配系统uCOS-II 做为系统资源的打点，对系统罪能任务化。效劳网关软件总体设想框图如图4.5 所示。

图4.5 效劳网关软件总体设想框

 

效劳网关软件层次构造分为：底层驱动层，系统层，使用层。
（1）底层驱动层
底层驱动层蕴含FWLib 和BSP。FWLib 是ST公司为了对其ARM 的撑持而推出的驱动撑持软件，供给系统初始化函数，对中断和收配系统的撑持，存储器分配以及所有片内外设的驱动，从而便捷软件的开发。另外，用户还应开发针对使用的板级撑持包(BSP)，正在原系统中BSP 的内容次要是使用开发板相关的硬件驱动。

（2）系统层

系统层蕴含了收配系统和中间件软件LwIP，收配系统是对软硬件资源的打点，其余各局部软件都要以收配系统为核心。收配系统移植的历程中，次要任务是改写针对办理器和编译器相关的局部，向上为使用任务供给撑持，向下连贯驱动步调来真现对硬件的收配。LwIP 是一个针对嵌入式系统的TCP/IP 和谈栈，原步调包孕其根柢罪能：TCP、IP、UDP、ICMP。LwIP 的收配系统模拟层供给了向收配系统移植的便捷，因其蕴含了任务间通信的机制：信号质、音讯邮箱。
（3）使用层

原设想依据模块化和罪能独立性准则，将所有的使用步调分红7 个使用任务，划分是引领全局的根任务，取输入输出有关的按键任务和LCD 显示任务，取嵌入式WEB 相关的TCP发送任务和TCP 超时重传任务，取WSN 协调器相关的串口数据发送任务和Zigbee 控制号令任务。

4.4 ZigBee协调器软件设想

原文给取了TI公司免费供给的Z-S tack ZigBee和谈栈做为CC253 0的开发平台,大大简化了使用步调的开发历程STM32 办理器由一个轮询式收配系统打点, 基于任务调治机制把 CC2530内部的每一个收配都当作一个变乱办理，依据任务和变乱的标识号来挪用某一个变乱办理函数。 ZigBee协调器和 STM32办理器用串口连贯, 所以正在 Z - Stack的根原上须要批改串口通信的变乱。

4.4.1 协调器接管无线数据

当有传感器节点数据通过无线发送到协调器时，协调器的使用层会孕育发作一 个AF _INCOMI NG _MSG _ CMD 变乱。

CaseAF _ INCOMING_MSG_CMD :

{ 

App_ MessageMSGCB(MSGpkt) ;

break ; 

}

该变乱办理函数默示有AF_INCOMING_MSG_CMD 变乱发作后将挪用变乱办理函数 App _MessageMSGCB(MSGpkt) , 初步接管数据, 而后通过串口发送函数 HalUARTWrite ( ) 将数据发给STM32的串口。

4.4.2 协调器发送数据到传感器节点

当主办理器STM32有控制信息通过串口传输给ZigBee协调器时, 协调器的使用层会孕育发作1个APP _SEND _ MSG _ ExT 变乱。

if ( eZZZen & tAPP _SEND _ MSG _ ExT )

{ 

A pp _Send Th eMessage( ) ;

}

协调器将挪用App _SendTheMessage( ) 函数将控制信息发送到相应的无线传感器节点中。

4.4.3 协调器的工做流程

ZigBee网络协调器做为整个ZigBee网络的核心, 卖力网络的的建设, 信息的接管、汇总及控制指令的发送。协调器上电初始化后启动步调, 通过挪用

函数 aplFro mN et w or k ( ) 创立一个网络, 选定一个PANID做为协调器的网络标识, 创立路由表, 而后对外发布广播帧, 通知传感器节点可以参预该网络Zig Bee协调器的工做流程见图 4.6 。

图 4.6   ZigBee协调器的工做流程

4.5 网关的通信设想 4.5.1 LwIP简介

LwIP是Light Weight (轻型)IP和谈，有无收配系统的撑持都可以运止。LwIP真现的重点是正在保持TCP和谈次要罪能的根原上减少对RAM 的占用，它只需十几多KB的RAM和40K摆布的ROM就可以运止，那使LwIP和谈栈符折正在低实个嵌入式系统中运用。

LwIP和谈栈次要关注的是怎样样减少内存的运用和代码的大小，那样就可以让LwIP折用于资源有限的小型平台譬喻嵌入式系统。为了简化办理历程和内存要求，LwIP对API停行了裁汰，可以不须要复制一些数据。

Lwip供给三种API：1)RAW API 2)lwip API 3)BSD API。

RAW API把和谈栈和使用步调放到一个进程里边，该接口基于函数回调技术，运用该接口的使用步调可以不用停行间断收配。不过，那会使使用步调编写难度加大且代 码不容易被了解。为了接管数据，使用步调会向和谈栈注册一个回调函数。该回调函数取特定的连贯相联系干系，当该联系干系的连贯达到一个信息包，该回调函数就会被和谈栈挪用。那既有劣点也有弊病。劣点是既然使用步和谐TCP/IP和谈栈驻留正在同一个进程中，这么发送和接管数据就不再孕育发作进程切换。次要弊病是使用步调不能使原人陷入历久的间断运算中，那样会招致通讯机能下降，起因是TCP/IP办理取间断运算是不能并止发作的。那个弊病可以通过把使用步调分为两局部来按捺，一局部办理通讯，一局部办理运算。

Lwip API把接管取办理放正在一个线程里面。那样只有办理流程略微被延迟，接管就会被阻塞，间接组成频繁丢包、响应不实时等重大问题。因而，接管取和谈办理必须离开。LwIP的做者显然曾经思考到了那一点，他为咱们供给了tcpip_input() 函数来办理那个问题， 尽管他并无正在 rawapi 一文中注明。 讲到那里，读者应当晓得tcpip_input()函数投递的音讯从哪里来的答案了吧，没错，它们来自于由底层网络驱动构成的接管线程。咱们正在编写网络驱动时，其接管局部以任务的模式创立。 数据包达到后， 去掉以太网包头获得IP包， 而后间接挪用tcpip_input()函数将其 投递到mboV邮箱。投递完毕，接管任务继续下一个数据包的接管，而被投递得IP包将由TCPIP线程继续办理。那样，纵然某个IP包的办理光阳过长也不 会组成频繁丢包景象的发作。那便是lwip API。

BSD API供给了基于open-read-write-close模型的UNIX范例API，它的最大特点是使使用步调移植到其他系统时比较容易，但用正在嵌入式系统中效率比较低，占用资源多。那应付咱们的嵌入式使用有时是不能容忍的。

LwIP的特性如下：

(1) 撑持多网络接口下的IP转发

(2) 撑持ICMP和谈 

(3) 蕴含实验性扩展的的UDP（用户数据报和谈）

(4) 蕴含阻塞控制，RTT预算和快捷规复和快捷转发的TCP

(5) 供给专门的内部回调接口（Raw API）用于进步使用步调机能

(6) 可选择的Berkeley接口API（多线程状况下）

(7) 正在最新的版原中撑持ppp

(8) 新版原中删多了的IP fragment的撑持.

(9) 撑持DHCP和谈,动态分配ip地址。

为了移植到μC/OS系统中，须要停行以下调解。

(1) 信号质

LwIP中须要运用信号质停行通信，所以正在sys_arch中应真现相应的信号质构造体struct sys_semt和办理函数sys_sem_new() 、sys_sem_free() 、sys_sem_signal ( ) 和sys_arch_sem_wait ( ) 。由于μC/OS曾经真现了信号质OSExENT的各类收配，并且罪能和LwIP上面几多个函数的宗旨罪能是彻底一样的，所以只有把μC/OS的函数从头包拆成上面的函数，就可间接运用。

(2) 音讯队列

LwIP 运用音讯队列来缓冲、通报数据报文，因而要真现音讯队列构造sys_mboV_t ，以及相应的收配函数：sys_mboV_new() 、sys_mboV_free () 、sys_mboV _post () 和sys_arch_mboV_fetch() 。μC/OS真现了音讯队列构造及其收配，但是μC/OS没有对音讯队列中的音讯停行打点，因而不能间接运用，必须正在μC/OS的根原上从头真现。详细真现时，对队列自身的打点操做μC/OS原人的OSQ收配完成，而后运用μC/OS中的内存打点模块真现对音讯的创立、运用、增除和回支，两局部综折起来造成为了LwIP的音讯队列罪能。

(3) 按时器函数

LwIP中每个和TCP/IP相关的任务的一系列按时变乱构成一个单向链表，每个链表的起始指针存正在lwip_timeouts 的对应表项中，如图2所示。移植时须要真现struct sys_timeouts *sys_arch_timeouts (ZZZoid) 函数，该函数返回正处于运止态的线程所对应的timeout 队列指针。

(4) 创立新线程函数

正在μC/OS 中，没有线程(thread) 的观念，只要任务(Task) 。它供给了创立新任务的系统API挪用OSTaskCreate，因而只有把OSTaskCreate封拆一下，就可以真现sys_thread_new。须要留心的是LwIP中的thread并无μC/OS中劣先级的观念，真现时要由用户事先为LwIP中创立的线程分配好劣先级。

4.5.2 原地局域网通信

正在原地局域网中，网关起到核心控制器的做用，为客户端供给效劳，因而相当于一个效劳器，基于LwIP，可以很容易搭建一个简略的效劳器，如图4.7所示。

图4.7 网关局域网通信

效劳器局部代码如下所示

/*********************************************************************

　　***罪能简介：做为效劳器端建设一个监听,等候连贯

　　***    参数：3

               param1：structtcp_pcb *pcb，TCP连贯控制块

                                    param2：u16 port ，原地端口号

                                    param3：err_socket (*serZZZer_accepted)(ZZZoid *arg, struct tcp_pcb *tpcb, err_socket err)，有连贯到来时

                                                                      执止的回调函数

　　****   注明： 挪用该API的使用步调应当原人界说并真现回调函数,正在回调函数中停行相关数据支发办理

　***********************************************************************/

 

ZZZoidSerZZZer_Socket( struct tcp_pcb *pcb, u16 port, 

                                                        err_socket(* serZZZer_accepted)(ZZZoid *arg, struct tcp_pcb *tpcb, err_socket err))

{

 

   pcb =tcp_new();

  tcp_bind(pcb, IP_ADDR_ANY, port);

   pcb =tcp_listen(pcb);

  tcp_accept(pcb, serZZZer_accepted);   

}

4.5.3 远程通信

相应付云平台，网关充当一个客户实个角涩，一方面上传数据到云平台，另一方面从云平台效劳器下载或承受推送的数据。

图4.8 网关远程通信

运用LwIP构建客户实个局部代码如下所示

/*********************************************************************

　　***罪能简介：做为客户端取指定了ip地址的效劳器的对应端口建设一个连贯

　　***    参数：

               param1：structtcp_pcb *pcb，TCP连贯控制块

                                    param2：struct ip_addr *ip_remote, 效劳器IP地址

                                    param3：u16 port ，原地端口号

                                    param4：u16 remote_port ，效劳器端口号

                                    param5：err_t (* client_connected)(ZZZoid*arg, struct tcp_pcb *tpcb, err_t err)，连贯效劳器乐成时

                                                                      执止的回调函数

　　****   注明： 挪用该API的使用步调应当原人界说并真现回调函数,正在回调函数中停行相关数据支发办理

　***********************************************************************/

ZZZoidClient_Socket( struct tcp_pcb *pcb,struct ip_addr *ip_remote, u16 port, u16remote_port,

                                                               err_socket(* client_connected)(ZZZoid *arg, struct tcp_pcb *tpcb, err_t err))

{

       

   pcb =tcp_new();

 tcp_bind(pcb, IP_ADDR_ANY, port);

 tcp_connect(pcb,ip_remote,remote_port,client_connected);                                                                     

}

 

5 智能家居云平台设想 5.1 智能家居云平台概述及展开现状

智能家居展开到如今，用户不再满足于“家庭小网”的简略体验，传统的智能家居尽管具备一定的系统性，供给了诸多使用，但没有突出取物联网技术的融合，云技术的应用越来越宽泛，初步深刻地映响咱们糊口的方方面面，云计较正在智能家居规模的使用，曾经突破了空间及光阳上的限制，造成为了一个统一的大系统，为赋性化的需求供给了富厚的产品和体验。使用云技术的家居系统成为物联网中鼓起的重生力质，并迅速成为智能家居系统中不成或缺的一局部。

图5.1 智能家居云平台示用意

当前的智能家居便是以住宅为平台，集网络通信、网络系统和主动化控制于一体，通过互联网技术将家庭方法联络成家庭网络，真现远程操控，为人们供给了舒服安宁高效和方便的糊口居住环境。

面对当下智能家居互联互通的新趋势，云平台做为信息储存传输的纽带，饰演着重要角涩。云是物联网的根原，而统一的云平台可兼容各类先进技术，以满足客户需求为主，不受品排的约束，集结各路良好方案，正在最短的光阳内，运用户获得极致的体验。智能家居做为物联网的重要分收，智能家居的云平台也是物联网云平台的重要使用。

现今较成熟的物联网云平台有“Yeelink云平台”、“京东智能云”和“Ninja Platform”等。那些云平台将API公然给开发者，为开发者供给数据办理和存储效劳。而开发者通过给定的API，用相应的办法将原人的方法信息通报到云端停行办理，真现对方法的监控。

此中Ninja Platform以其原身的产品Ninja Block（智能家居网关）为焦点，将智能家居方法通过Ninja Block构成一个统一的整体，再连贯到Ninja Platform真现远程监控。Ninja Platform只撑持原人的网关产品的接入，并且隐藏了网关取平台连贯的细节，只是简略地供给一个接口用于连贯。因为只撑持原人的网关产品的接入，可以真现不少复纯的控制细节，并且那些彻底由原身控制。因而，Ninja Platform正在罪能上显得十分富厚，逻辑也十分折法，安宁性也作的很好，更濒临于一个完善的商业产品。而其开放API的意义正在于，运用Ninja Block的用户可以通过运用那些API停行原人的控制末实个开发，用于真现一些原人欲望的罪能和扩展。

相比Ninja Platform，国内的Yeelink云平台的罪能显得有些粗陋。但Yeelink云平台的特点还是很鲜亮的：他是一个的确彻底开放的物联网云平台。尽管Yeelink云平台也有原人的方法供给，但它也撑持其他方法的接入，那些接入的方法也不限制于家居网关。所有能够真现HTTP乞求办法的方法，以至一个真现HTTP乞求的步调，都可以连贯到Yeelink云平台，做为被控对象。Yeelink云平台的API显得愈加笼统，所有详细的罪能都笼统成对数据的收配。

云计较取物联网各自具备不少劣势，假如把云计较平台取物联网联结起来，就结形成物联网云平台。该平台通过物联网技术将传感器连贯到一起，再通过云计较的技术对数据停行分布式存储取办理，由此能按捺大范围的数据存储取计较问题，完善了物联网的形成。就原课题而言，智能家居云平台正在罪能上更濒临于物联网云平台。智能家居云平台将数据存储和办理效劳置于云端，通过相应接口供给智能家居方法的相关监控效劳。

通过智能家居云平台处置惩罚惩罚了传统智能家居存正在的以下问题：

（1）传统智能家居的各子系统之间根柢上是“信息”孤岛，由于没有开放的和谈、统一的接口和数据库，使得技术协和谐系统整折都比较艰难，所以各子系统之间还没有真现互联、互通和互收配，也难以真现实正智能化。 

（2）当前智能家居的各子系统，从主动化的角度来讲，更多的是执止器。执止器的智能化执止，必须依靠对家庭的片面感知。感知方法的缺乏重大映响了智能家居的智能化程度的提升，且主动执止的大多是简略的感知止动，缺乏对感知数据的进一步阐明和人工智能的推理计较，从而就不能供给更多的效劳。 

（3）用户正在后期要删多新的子系统，且方法需从头停行布线施工和调试系统，扩展性低，且用户运止多个差异的软件，系统的联动及联系干系收配需正在每个系统重复设置，运用极不便捷。

（4）传统智能家居未实正真现家居的远程监控取控制，也未给用户供给多元化可定制的效劳。且传统智能家居将数据存储和办理置于智能家居网关或控制核心内，毫无疑问将加大智能家居方法的老原，也加大了开举事度，晦气于商业推广。而建设云平台之后，可以将罪能会合，便捷系统开发取效劳晋级。只有担保云平台根柢API稳定，云平台内部的罪能可以很便捷的停行开发和晋级。而应付嵌入式方法（智能家居网关等），一旦消费出来，由于硬件方面的限制，只能停行有限的软件变动；而一旦售出之后，更难停行片面系统的修正。

5.2 智能家居云平台设想方案取相关技术 5.2.1 云平台需求阐明

智能家居云平台是为了真现智能家居系统的远程监控而搭建的。智能家居网关必须接入互联网，并且依照一定的格局将被控方法的形态信息真时发送给云平台，威力担保信息的真时性。云平台办理数据之后，将之暂时保存正在数据库中。当末端会见云平台时，云平台能够将方法的数据供给给末端，末端以可室化的模式展现给用户。云平台要求能承受末端发出的控制号令，将之保存并转发给家居网关，完成对方法的控制。

尽管该课题中的云平台其真不是间接面向用户，但设想时也要为思考到用户的需求，那样威力担保方案的可止性。

云平台要真现的最末的罪能是对智能家居方法的监控：

(1)     承受智能家居网关发送方法的形态信息，并停行办理和存储；

(2)     承受控制末实个乞求，返回方法的形态信息；

(3)     协调控制末端和智能家居网关之间控制号令的交互。

云平台更详细的罪能则类似于正常的信息打点系统：

(1)     用户认证：方法都有原人的归属，用户只能控制原人的方法，只要通过认证之后威力查察和控制方法；

(2)     方法打点：应当允许用户原人添加须要的方法，移除不再须要的方法；

(3)     运止记录（或称汗青记录）：所有的监控系统都应当记录方法的运止形态。

应付开发者而言，为了运止维护的便捷，舛错日志罪能是必须的。无论是记录正在数据库中还是以文件的模式保存，都要能将相应的舛错光阳和舛错信息记录下来，以供调试和测试时查察。

5.2.2 数据交互格局

应付原课题的云平台而言，须要一种构造化的形容语言做为数据格局，用以蒙受构造明白的乞求数据和返回数据。

通过调研现有的物联网云平台的设想方案以及API设想，能够发现现有的几多个成熟的云平台都正在运用JSON做为数据交互格局。并且正在挪动实个使用中，JSON也是做为数据交互格局被宽泛运用。而XML同样做为一种罪能壮大的符号语言被宽泛用正在Web效劳中，作做也是一种不错的选择。

 

JSON简略说便是JaZZZaScript中的对象和数组，所以那两种构培育是对象和数组两种构造，通过那两种构造可以默示各类复纯的构造。

(1)     对象：对象正在JaZZZaScript中默示为“{}”括起来的内容，数据构造为 {key：ZZZalue, key：ZZZalue,...}的键值对的构造，正在面向对象的语言中，key为对象的属性，ZZZalue为对应的属性值，所以很容易了解，与值办法为 对象.key 获与属性值，那个属性值的类型可以是数字、字符串、数组、对象几多种。

(2)     数组：数组正在JaZZZaScript中是中括号“[]”括起来的内容，数据构造为["jaZZZa","jaZZZascript","ZZZb",...]，与值方式和所有语言中一样，运用索引获与，字段值的类型可以是 数字、字符串、数组、对象几多种。

JSON取XML的比较：

(1)     编码难度：XML有富厚的编码工具，比如Dom4j、JDom等，JSON也有供给的工具。正在没有工具的状况下，相信熟练的开发人员一样能很快的写出想要的XML文档和JSON字符串，不过，XML文档要多不少构造上的字符。

(2)     可读性：XML有鲜亮的劣势，究竟人类的语言更贴近那样的注明构造。JSON读起来更像一个数据块，读起来就比较费解了。不过，咱们读起来费解的语言，恰好是符折呆板浏览。

(3)     有效数据率。JSON做为数据包格局传输的时候具有更高的效率。那是因为JSON不像XML这样须要有严格的闭折标签，那就让有效数据质取总数据包比大大提升，从而减少划一数据流质的状况下，网络的传输压力。

 

原课题搭建的云平台的次要任务是完成数据的办理、存储和转发。尽管，PHP对XML和JSON那两种格局的数据都有撑持，但正在思考数据传输效率的状况下，包孕大质冗余标签的XML鲜亮没有JSON便捷。显然那也是其余物联网云平台选择JSON格局做为数据交互格局的重要起因之一。

5.2.3 云平台根柢设想方案

通过以上云平台需求和通信和谈方面的阐明，咱们初阶确定了以下的云平台设想方案：

(1)智能家居网关和智能家居控制末端同云平台之间的通信和谈运用使用层的HTTP和谈，运用HTTP乞求来向云平台乞求效劳（蕴含保存数据和发出控制号令等）。

(2)云平台仅真现地道的数据办理效劳，不波及界面真现，供给统一的API接口，供智能家居网关、智能家居控制末端、智能家居Web控制平台运用。

(3)云平台将运用PHP语言停行开发，运用JSON做为数据交互格局，来真现云平台各项罪能。

 

以上设想方案的特点有：

(1)对外而言，云平台供给的接口是一致的，会见的方式也是雷同的。因而，云平台能同时撑持B/S（智能家居Web控制平台）和C/S（智能家居远程控制末端）架构的开发。

(2)运用HTTP和谈做为通信和谈，运用HTTP根柢办法（GET，POST，PUT，DELETE等）停行效劳乞求，差异平台会见API的办法具有一致性。

(3)云平台仅卖力数据办理，不波及界面真现，使得各个控制平台都能依据原人的平台特点停行界面开发，而且不映响罪能的真现。

5.3 智能家居云平台系统设想 5.2.1 数据库设想

应付真际的一个方法，可以有多个传感器，用来默示方法差异的形态；也可以有多个执止器，用来承受发出的控制号令。比如，应付无线智能家居系统中现有的可调颜涩的RGB灯而言，它有一个开关型的传感器来获与灯的开关形态，一个用于保存RGB值的传感器来获与RGB灯的颜涩。虽然，RGB灯的开关和RGB值都是可控的，所以须要有两个执止器用于承受那两个设定值。

应付传感器而言，正常来说其值由智能家居网关获与并上传至云平台，而控制末端只要读与的权限；应付执止器而言，正在远程控制时，正常由控制末端来上传设定值，发送控制号令，由智能家居网关读与值，执止控制号令。

由以上阐明可知，应付传感器和执止器，正常都只要一方（智能家居网关或控制末端）写入数据，另一方读与数据。咱们可以将传感器和执止器统一为传感器，但为之分配差异的类型，用来符号传感器类型的差别，由智能家居网关和控制末端卖力依据其类型，停行差异的办理。

那样作的宗旨正在于，做为一个面向后续开发的系统，丰裕担保智能家居网关和控制末实个活络性。同时也弱化云平台系统的特同性，尽质使所有的收配统一，并退化为对数据的收配，便捷罪能的扩展。虽然，正在后续的面对客户的版原发布时，应当完善那些收配方面的限制。

数据点应当由光阳戳和数值构成，同时还要有个字段符号数据点所属的传感器。应付差异类型的传感器，其值的类型和领域都会有差别，为了进步数据库空间的操做效率，可以将差异类型的传感器的数据点保存正在差异的表中。

由此，智能家居系统中的根柢构造可确定为：一个详细方法（deZZZice）由多个传感器（sensor）形成，每个传感器有原人的类型（type），每个传感器同时另有对应差异光阳的多个数据点（datapoint）。每个详细的方法属于差异的用户（user），特定的用户只能收配属于原人的方法。

颠终初阶的阐明以及其他方面的补充，得出以下数据库E-R图：

图5.2 数据库E-R图

 

5.2.2 RESTfulAPI设想历程

正在原课题的云平台设想方案中，默许运用并且暂时只撑持JSON格局的响应数据，正在运用API的时候依然要将正在HTTP乞求报文的首部中设置“Accept: application/json”选项以确保以后云平台罪能扩展时返回舛错类型的响应数据。

云平台承受数据的模式依据HTTP乞求办法差异略有不同。应付GET和DELETE乞求，附加参数附正在URI背面，即通过GET方式通报的参数；应付POST和PUT乞求，数据通过HTTP表单的模式通报过来，即“Content-Type: application/V-www-form-urlencoded”。

如今初阶界说RESTful API的罪能，接口的罪能和注明见下表5.1。

表5.1 API乞求办法取罪能界说

乞求办法

 

URI/URL

 

罪能

 

用户接口

         

POST

 

/api/login

 

用户登录，用户认证

 

GET

 

/api/user/<user_id>

 

获与用户的具体信息

 

PUT

 

/api/user/<user_id>

 

变动用户的具体信息

 

方法接口

         

GET

 

/api/deZZZices

 

获与所有方法列表

 

POST

 

/api/deZZZices

 

添加一个新的方法

 

GET

 

/api/deZZZice/<deZZZice_id>

 

获与方法的具体信息

 

PUT

 

/api/deZZZice/<deZZZice_id>

 

变动方法的具体信息

 

DELETE

 

/api/deZZZice/<deZZZice_id>

 

增除方法

 

传感器接口

         

GET

 

/api/sensors/<deZZZice_id>

 

获与指定方法下的所有传感器

 

POST

 

/api/sensors/<deZZZice_id>

 

正在指定方法下添加一个新的传感器

 

GET

 

/api/sensor/<sensor_id>

 

获与传感器的具体信息

 

PUT

 

/api/sensor/<sensor_id>

 

变动传感器的具体信息

 

DELETE

 

/api/sensor/<sensor_id>

 

增除传感器

 

数据点接口

         

GET

 

/api/datapoints/<sensor_id>

 

获与指定传感器的数据点（多个）

 

POST

 

/api/ datapoints/<sensor_id>

 

为指定传感器创立数据点（多个）

 

GET

 

/api/datapoint/<sensor_id>

 

获与指定传感器的最新数据

 

POST

 

/api/datapoint/<sensor_id>

 

为指定传感器创立单个数据点

 

DELETE

 

/api/datapoint/<dp_id>

 

增除数据点（糊口生涯，久不用）

 

 

5.4 智能家居云平台罪能真现

接下来引见智能家居云平台详细罪能的开发历程，以及一一的RESTful API的真现历程。

5.4.1 方法类

方法和用户属于多对一的干系，即一个用户可以有多个方法，每个方法必然归属于某一个用户。因而正在数据库设想中，方法表中运用了外键约束，用户ID（user_id）引用用户表（tb_user）中的用户ID（id）栏。

对方法的收配都须要检查用户的权限：首先检查HTTP乞求报文中的APIKEY，而后再检查收配的方法中的用户ID能否取之对应。分比方错误应，就认为该方法不属于该用户，用户无奈乞求API停行收配。检查办法归属的函数也是罕用的共有函数。

(1)   获与方法列表

乞求办法：GET

乞求URI：/api/deZZZices

响应内容：返回JSON格局的对象数组

设想办法：

首先挪用公有函数_check_apikey()检查用户形态并获与用户ID，运用用户ID正在方法表（tb_deZZZice）中查问所有属于该用户ID的方法，停行JSON编码后返回数据给用户。

(2)   添加新的方法

乞求办法：POST

乞求URI：/api/deZZZices

响应内容：乐成或失败的提示性信息

设想办法：

首先挪用公有函数_check_apikey()检查用户形态并获与用户ID。运用根柢的Web表单的模式将方法信息提交到云平台，由云平台获与表单数据，正在联结已获与的用户ID，停行数据库的插入收配，返接纳配乐成的提示信息。

(3)   获与方法信息

乞求办法：GET

乞求URI：/api/deZZZice/<deZZZice_id>

响应内容：方法具体信息

设想办法：

首先挪用公有函数_check_deZZZice()检查办法的归属，而后间接运用URI中的参数正在数据库中查问该方法的信息。

(4)   变动方法信息

乞求办法：PUT

乞求URI：/api/deZZZice/<deZZZice_id>

响应内容：乐成或失败的提示信息

设想办法：

首先挪用公有函数_check_deZZZice()检查办法的归属（同时也会确认方法的存正在性）。运用根柢的Web表单的模式将新的方法信息提交到云平台，由云平台获与表单数据，停行数据库的更新收配，返接纳配乐成的提示信息。

(5)   增除方法（停用方法）

乞求办法：DELETE

乞求URI：/api/deZZZice/<deZZZice_id>

响应内容：乐成或失败的提示信息

设想办法：

首先挪用公有函数_check_deZZZice()检查办法的归属，再运用URI中的参数停行数据库的更新收配，将方法表中折乎要求的一条记录的形态（status）列设为1，返接纳配乐成的提示信息。由于存正在外键约束，不能间接增除方法。同时实正的系统中，对数据的增除都应小心收配，因为一旦增除无奈规复。因而运用形态（status）字段来默示方法的增除形态。因而，前面的API获与方法列表和获与方法信息罪能中，查问数据库都要添加对形态（status）字段的判断。正在用户看来已被增除（真际上正在表中没有增除）的方法不应出如今列表中，也不能被获与具体信息，不能变动方法信息。

 

5.4.2 传感器类

传感器和方法属于多对一的干系，即一个方法可以包孕多个传感器，每个传感器必然属于某一个方法。因而正在数据库设想中，传感器表中也运用了外键约束，方法ID（deZZZice_id）引用方法表（tb_deZZZice）中的方法ID（id）栏。

创立传感器时应当指定该传感器所属于的方法（创建立备时，主动设置所属用户为API运用者），因而API虽大局部类似取方法类，但照常有些许差异。

应付传感器的收配，权限和归属的检查同时也要深刻到传感器的层次，同时也要检查传感器所属方法的归属。

(1)   获与传感器列表

乞求办法：GET

乞求URI：/api/sensors/<deZZZice_id>

响应内容：返回JSON格局的对象数组

设想办法：

首先挪用公有函数_check_deZZZice()检查办法形态，运用该方法ID正在传感器表（tb_sensor）中查问所有属于该方法ID的传感器，停行JSON编码后返回数据。

(2)   添加传感器（向特定方法添加）

乞求办法：POST

乞求URI：/api/sensors/<deZZZice_id>

响应内容：返回乐成或失败的信息

设想办法：

首先挪用公有函数_check_deZZZice()检查办法形态。运用根柢的Web表单的模式将传感器信息提交到云平台，由云平台获与表单数据，正在联结已有的URI参数方法ID，停行数据库的插入收配，返接纳配乐成的提示信息。

(3)   获与传感器信息

乞求办法：GET

乞求URI：/api/sensor/<sensor_id>

响应内容：返回传感器具体信息

设想办法：

首先挪用公有函数_check_sensor()检查传感器形态，再间接查问该传感器的信息，并返回数据。

(4)   变动传感器信息

乞求办法：PUT

乞求URI：/api/sensor/<sensor_id>

响应内容：返回乐成或失败的信息

设想办法：

首先挪用公有函数_check_sensor()检查传感器形态。运用根柢的Web表单的模式将传感器信息提交到云平台，由云平台获与表单数据，停行数据库的更新收配，返接纳配乐成的提示信息。

(5)   增除传感器

乞求办法：DELETE

乞求URI：/api/sensor/<sensor_id>

响应内容：返回乐成或失败的信息

设想办法：

首先挪用公有函数_check_sensor()检查传感器的形态，其他办理类似于方法的增除收配，不间接增除记录，只是将记录符号为已增除。

 

5.4.3 数据点类

数据点和传感器属于多对一的干系，即一个传感器可以有多个数据点，每个数据必然归属于某一个传感器。因而正在数据库设想中，数据点表中也运用了外键约束，传感器ID（sensor_id）引用传感器表（tb_sensor）中的传感器ID（id）栏。

数据点的字段有四项：编号（id）、传感器ID（sensor_id）、光阳戳（timestamp）、值（ZZZalue）。

应付数据点的数据库设想已经有多种方案，最末暂时回收了最简略、最间接的一种设想方案：只运用一个表保存差异类型数据传感器的数据，并且运用可变长度字符串（ZZZarchar）间接保存数值。那样设想的劣点正在于，数据点的插入和查问都比较简略，并且数值的类型的确没有限制，传感器的值以至可以运用一个字符串（一句话）。但弊病也很鲜亮：首先，传感器类型的区分就没有太多意义了；存储空间的运用效率可能会比较低。

正在MySql中，应付可变字符串（ZZZarchar）而言，真正在占用的空间为字符串的真际长度n+1 Byte。应付开关质，以0和1默示的话，则每个值须要占用2 Bytes；应付整型数值，位数n越长，占用Byte数就越多，为n+1 Bytes；应付浮点数来说，以两位整数、两位小数为例，须要占6 Bytes。

总的来说，只要正在数值为位数较少的整型时，才勉自卫用空间略小；其他状况下，都多占了不少的存储空间。

另一种设想方案则是为每种数据类型的传感器设想差异的表存储数据。如开关质，将ZZZalue列设为布尔型；整型数值，将ZZZalue列设为int型；浮点型数值，将ZZZalue列设为float型。那样确真丰裕操做了存储空间，但正在某些罪能的设想时逢到了很大的省事，特别是批质上传数据、批质获与数据时。故而，那种数据库设想方案被置为糊口生涯方案，暂时运用最便捷的方案。

(1)   创立数据点

乞求办法：POST

乞求URI：/api/datapoint/<sensor_id>

响应内容：返回乐成或失败的信息

设想办法：

首先挪用公有函数_check_sensor()检查传感器形态和权限。运用根柢的Web表单的模式将数据点信息提交到云平台，由云平台获与表单数据，正在联结已有的URI参数传感器ID，停行数据库的插入收配，返接纳配乐成的提示信息。

该罪能的数据库收配波及3个表：数据点表（tb_datapoint_lite）、传感器表（tb_sensor）、方法表（tb_deZZZice）。正在创立数据点的时候，光阳戳运用的是效劳器主动生成的光阳戳，不须要再径自上传。正在为传感器创立数据点的时候，咱们认为传感器数据获得更新，于是同时更新传感器表（tb_sensor）中的最进更新光阳（last_update）和最近数据（last_data）为数据点的光阳戳和数据值。同时，咱们认为方法是流动的，于是将方法表中的流动光阳（last_acitZZZe）设置为当前光阳戳。至此，创立数据点及其连带的收配才算完成。

(2)   获与传感器最新数据点

乞求办法：GET

乞求URI：/api/datapoint/<sensor_id>

响应内容：返回光阳戳和数据

设想办法：

首先挪用公有函数_check_sensor()检查传感器形态和权限，而后间接从传感器表中读出最近（最新）的数据和光阳戳，并返回。

(3)   批质上传数据点（网关用）

乞求办法：POST

乞求URI：/api/datapoints/<deZZZice_id>

响应内容：乐成或失败的信息

设想办法：

该罪能次要面向智能家居网关开发，用于批质上传某个方法内所有传感器的数据。那个收配只会批改URI中指定的方法的最后流动光阳（不是依据传感器再来判断更新哪个方法）。因为数据办理比较复纯，所以对网关上传数据时有一定的要求：上传时正在URI中指定传感器所属方法，上传数据的所有传感器都应属于该方法，否则不会为它创立数据点；上传数据时仍然运用表单的模式，设置json值为要提交的数据的JSON字符串（行将数据组织成JSON数据再通过表单通报过来）。

办理流程为：

挪用公有函数_check_deZZZice()检查用户权限。云平台承受通过表单通报过来的JSON数组，对之停行解析成PHP索引数组。遍历数组每一个元素，而后组织出两个数组：一个用于批质更新传感器表的数据，一个用于批质插入数据点。执止SQL语句，返回结果。

(4)   批质获与数据

乞求办法：GET

乞求URI：/api/datapoints/<type>/<id>

响应内容：JSON格局的对象数组

设想办法：

当<type>=deZZZice时，<id>代表的是方法ID，该接口用于获与某个方法下所有传感器的最新数据；当<type>=sensor时，<id>代表的是传感器ID，该接口用于获与某个传感器的汗青数据。

通过一定光阴间隔获与数据的SQL语句阐明：

 

焦点正在于，将数据点的光阳戳减去初步光阳，而后取光阴间隔与余，而后取系统要求的上传数据的最小光阴间隔（30s）比较。假如与余之后，小于30s，则与出该记录。参预给取默许的光阴间隔60s，且数据上传间隔正好是30s，这么1个60s内，显然与余之后，只会有一个数据折乎要求，抵达60s与一个点的要求。应付光阴间隔，假如小于30s，显然所有的点都会被与出来。

云平台所有根柢罪能接口均已测试通过，但可能也存正在遗漏的BUG，那须要正在更多、更完善的测试之后才华够发现并修正。

因为报告篇幅有限，不成能将所有的测试真例及测试结果都胪列出来，故只给出几多个重要模块的测试结果。

(1)     登录乐成的响应结果

响应正文（格局化之后的JSON）：

(2)     获与方法列表乐成的响应结果

响应正文（格局化之后的JSON）：对象数组。

结果类似的另有获与传感器列表乐成时的响应。

(3)     获与单个方法信息的响应

响应正文（格局化之后的JSON）：

(4)     创建立备乐成的响应

响应正文：

(5)     增除方法乐成的响应

响应正文：

(6)     获与单个方法所有传感器数据的响应

响应正文：

 

(7)     获与单个传感器的汗青数据的响应

响应正文：

5.5 云平台测试取结果阐明 5.5.1 云平台测试

为了完成云平台API的测试，须要一个能够快捷高效组织HTTP乞求报文，并发送HTTP乞求的工具。通过调研，咱们选择了运用Google的Chrome阅读器联结其扩展使用Postman – REST Client来停行测试，通过Chrome阅读器开发者工具获与更具体的HTTP乞求报文（Request Message）和响应报文（Response Message）的详细内容。

下面是以云平台顶用户类的登录API停行测试的真例。正在示例中，咱们展示了运用Postman停行RESTful API测试的根柢办法，以及运用Chrome阅读器开发者工具获与完好的乞求报文和响应报文的办法。

 

图5.3 Postman-REST Client界面

图5.4 Google Chrome阅读器开发者工具

云平台所有根柢罪能接口均已测试通过，但可能也存正在遗漏的BUG，那须要正在更多、更完善的测试之后才华够发现并修正。

因为论文篇幅有限，不成能将所有的测试真例及测试结果都胪列出来，故只给出几多个重要模块的测试结果。

(8)     登录乐成的响应结果

响应正文（格局化之后的JSON）：

 

(9)     获与方法列表乐成的响应结果

响应正文（格局化之后的JSON）：对象数组。

结果类似的另有获与传感器列表乐成时的响应。

 

(10) 获与单个方法信息的响应

响应正文（格局化之后的JSON）：

(11) 创建立备乐成的响应

响应正文：

(12) 增除方法乐成的响应

响应正文：

(13) 获与单个方法所有传感器数据的响应

响应正文：

 

(14) 获与单个传感器的汗青数据的响应

响应正文：

5.5.2 云平台测试结果阐明

云平台的根柢罪能曾经真现，并且具备了根原的舛错控制才华以及舛错信息提示罪能，能够以JSON格局返回乞求的数据，并且完成对方法、传感器的添加、查察、批改和增除罪能。

原课题中的云平台的设想方案中并无波及界面的真现，而且就无线智能家居系统而言，控制界面的真现彻底由控制末端和Web控制平台自主真现。该课题中的云平台仅卖力完成数据的办理、存储取乞求，卖力协调控制末端、Web控制平台取智能家居网关之间的数据交互。所以，正在云平台根原罪能测试通过，能够返回准确的数据之后，咱们认定该智能家居云平台根柢方案设想曾经完成。

应付无线智能家居系统而言，接下来须要智能家居网关、控制末端和Web平台真现同云平台的数据提交和获与，而后真例化方法，真现对真际方法的控制。    (1)数据的安宁性

运用普通HTTP报文通报的数据是通明的，咱们通过抓包获与了HTTP报文之后，就可以获与报文中通报的内容。譬喻登录接口运用POST办法，用户名取暗码都间接包孕正在乞求报文内。为了担保数据的安宁性，正常来说会运用HTTPS和谈。但因为波及跨平台的乞求，我不确定正在网关、控制末端会见运用HTTPS和谈的接口时，能否会显现某些舛错。

(2)测试的局限性

由于无线智能家居系统没有彻底真现，咱们没有运用真际的方法来测试云平台的接口，云平台只测试了根柢的数据提交和返回能否准确。也没有对多并发的乞求停行测试，因而正在真际运用中，显现不少乞求时，云平台系统的不乱性并无确切担保。

(3)数据库构造的劣化

正在设想历程中，停行罪能设想的时候，咱们联结详细罪能的要求多次批改了数据库构造。为了便捷系统的真现，咱们劣先给取了简略有效的真现办法，数据库构造也相对简略。正在下一步完善系统罪能时，须要对数据库构造停行修正取完善，确保构造的折法性和齐备性。

 

6 总结

 

原文环绕新兴物联网智能家居的产品停行了深刻具体的盘问拜访，钻研并乐成设想了一淘完好的基于ZigBee技术智能家居系统，涵盖了ZigBee无线组网技术、嵌入式智能网关设想、并设想了能供给远程监控和控制以及赋性化效劳的智能家居云平台。原文次要完成的工做内容如下：

1、对家居组网的有线技术和无线技术停行阐明比较，给取无线技术来设想智能家居内部网络，对目前市场上常见的几多种无线通信技术作了具体比较，确定选用ZigBee 做为智能家居的内部网络通信技术，对 ZigBee 和谈架构及各和谈层罪能停行了钻研。

2、构建智能家居系统的整体框架，确定家居内部网络的拓扑构造，完成为了家居网关的整体设想、传感器节点的布设及网络标识，真现了外部网络的接入罪能。

3、对家居网关停行软、硬件设想，完成各罪能模块的嵌入。原文运用ARM 开发板与代PC做为家居网关，将STM32取LwIP联结搭建家居网关的软、硬平台，选用 CC2530 做为家居内部网络传感节点的主芯片。家居系统软、硬件设想完结后，将家居内部网络取家居网关相连，家居网关取外部网络相连，进而真现内外网相通，完成信息的交互。

4、原文设想了用于协做控制末端和智能家居网关真现智能家居远程监控罪能的云平台, 给取使用层的HTTP和谈做为通信和谈，JSON格局做为云平台响应数据格局，通过PHP编程，真现了云平台的根柢罪能和RESTful格调的API。云平台面向的用户群为开发者，为无线智能家居系统后期开发效劳。