怎样去设计一种基于ZigBee技术的智能家居系统

　　1 绪论
　　1.1 课题背景及来源
　　1.2 智能家居概述及研究现状
　　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可以使用已有的Java标准，其重点是如何集成这些相关的标准。
　　核心的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 的CC253x片上系统解决方案适合于广泛的应用，它们很容易的建立在基于 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 LEAVE，indication原语， 表示设备断开连接。
　　3.4.3 网络地址的分配机制
　　在ZigBee网络层中，采用分布式地址分配方案来分配网络地址，即该方案为每一个父设备分配一个有限的网络地址段。这些地址在一个特殊的网络中是唯一的，并且由父设备分配给它的子设备。ZlgBee协调器决定在其网络内允许连接的子设备的最大个数。对于这些子设备，参数nwkMaxRouters为路由器最大个数，而剩下的设备数为终端设备数。每一个设备具有一个连接深度，即连接深度表示仅仅采用父子关系的网络中，一个传送帧传送到ZigBee 协调器所传递的最小跳数。ZlgBee协调器自身深度为0，而它的子设备深度为1。对应多跳网络，其深度大于1。ZlgBee协调器决定网络的最大深度。
　　假定父设备拥有子设备数量的最大值为nwkMaxChildren （Cm），网络的最大深度为nwkMaxDepth （Lm），父设备将路由器作为它的子设备的最大数为nwkMaxRouters（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（Cotex-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 _ EVT 事件。
　　if （ even & tAPP _SEND _ MSG _ EVT ）
　　{
　　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（）函数将其 投递到mbox邮箱。投递结束，接收任务继续下一个数据包的接收，而被投递得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已经实现了信号量OSEVENT的各种操作，并且功能和LwIP上面几个函数的目的功能是完全一样的，所以只要把μC/OS的函数重新包装成上面的函数，就可直接使用。
　　（2） 消息队列
　　LwIP 使用消息队列来缓冲、传递数据报文，因此要实现消息队列结构sys_mbox_t ，以及相应的操作函数：sys_mbox_new（） 、sys_mbox_free （） 、sys_mbox _post （） 和sys_arch_mbox_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 （void） 函数，该函数返回正处于运行态的线程所对应的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 （*server_accepted）（void *arg， struct tcp_pcb *tpcb， err_socket err），有连接到来时
　　执行的回调函数
　　**** 说明： 调用该API的应用程序应该自己定义并实现回调函数，在回调函数中进行相关数据收发处理
　　***********************************************************************/
　　voidServer_Socket（ struct tcp_pcb *pcb， u16 port，
　　err_socket（* server_accepted）（void *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， server_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）（void*arg， struct tcp_pcb *tpcb， err_t err），连接服务器成功时
　　执行的回调函数
　　**** 说明： 调用该API的应用程序应该自己定义并实现回调函数，在回调函数中进行相关数据收发处理
　　***********************************************************************/
　　voidClient_Socket（ struct tcp_pcb *pcb，struct ip_addr *ip_remote， u16 port， u16remote_port，
　　err_socket（* client_connected）（void *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简单说就是JavaScript中的对象和数组，所以这两种结构就是对象和数组两种结构，通过这两种结构可以表示各种复杂的结构。
　　（1） 对象：对象在JavaScript中表示为“{}”括起来的内容，数据结构为 {key：value， key：value，。。.}的键值对的结构，在面向对象的语言中，key为对象的属性，value为对应的属性值，所以很容易理解，取值方法为 对象.key 获取属性值，这个属性值的类型可以是数字、字符串、数组、对象几种。
　　（2） 数组：数组在JavaScript中是中括号“［］”括起来的内容，数据结构为［“java”，“javascript”，“vb”，。。.］，取值方式和所有语言中一样，使用索引获取，字段值的类型可以是 数字、字符串、数组、对象几种。
　　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值都是可控的，所以需要有两个执行器用于接受这两个设定值。
　　对于传感器而言，一般来说其值由智能家居网关获取并上传至云平台，而控制终端只有读取的权限；对于执行器而言，在远程控制时，一般由控制终端来上传设定值，发送控制命令，由智能家居网关读取值，执行控制命令。
　　由以上分析可知，对于传感器和执行器，一般都只有一方（智能家居网关或控制终端）写入数据，另一方读取数据。我们可以将传感器和执行器统一为传感器，但为之分配不同的类型，用来标记传感器类型的差别，由智能家居网关和控制终端负责根据其类型，进行不同的处理。
　　这样做的目的在于，作为一个面向后续开发的系统，充分保证智能家居网关和控制终端的灵活性。同时也弱化云平台系统的特异性，尽量使所有的操作统一，并退化为对数据的操作，方便功能的扩展。当然，在后续的面对客户的版本发布时，应该完善这些操作方面的限制。
　　数据点应该由时间戳和数值组成，同时还要有个字段标记数据点所属的传感器。对于不同类型的传感器，其值的类型和范围都会有差别，为了提高数据库空间的利用效率，可以将不同类型的传感器的数据点保存在不同的表中。
　　由此，智能家居系统中的基本结构可确定为：一个具体设备（device）由多个传感器（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/x-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/devices
　　获取所有设备列表
　　POST
　　/api/devices
　　添加一个新的设备
　　GET
　　/api/device/《device_id》
　　获取设备的详细信息
　　PUT
　　/api/device/《device_id》
　　更改设备的详细信息
　　DELETE
　　/api/device/《device_id》
　　删除设备
　　传感器接口
　　GET
　　/api/sensors/《device_id》
　　获取指定设备下的所有传感器
　　POST
　　/api/sensors/《device_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/devices
　　响应内容：返回JSON格式的对象数组
　　设计方法：
　　首先调用公有函数_check_apikey（）检查用户状态并获取用户ID，使用用户ID在设备表（tb_device）中查询所有属于该用户ID的设备，进行JSON编码后返回数据给用户。
　　（2） 添加新的设备
　　请求方法：POST
　　请求URI：/api/devices
　　响应内容：成功或失败的提示性信息
　　设计方法：
　　首先调用公有函数_check_apikey（）检查用户状态并获取用户ID。使用基本的Web表单的形式将设备信息提交到云平台，由云平台获取表单数据，在结合已获取的用户ID，进行数据库的插入操作，返回操作成功的提示信息。
　　（3） 获取设备信息
　　请求方法：GET
　　请求URI：/api/device/《device_id》
　　响应内容：设备详细信息
　　设计方法：
　　首先调用公有函数_check_device（）检查设备的归属，然后直接使用URI中的参数在数据库中查询该设备的信息。
　　（4） 更改设备信息
　　请求方法：PUT
　　请求URI：/api/device/《device_id》
　　响应内容：成功或失败的提示信息
　　设计方法：
　　首先调用公有函数_check_device（）检查设备的归属（同时也会确认设备的存在性）。使用基本的Web表单的形式将新的设备信息提交到云平台，由云平台获取表单数据，进行数据库的更新操作，返回操作成功的提示信息。
　　（5） 删除设备（停用设备）
　　请求方法：DELETE
　　请求URI：/api/device/《device_id》
　　响应内容：成功或失败的提示信息
　　设计方法：
　　首先调用公有函数_check_device（）检查设备的归属，再使用URI中的参数进行数据库的更新操作，将设备表中符合要求的一条记录的状态（status）列设为1，返回操作成功的提示信息。由于存在外键约束，不能直接删除设备。同时真正的系统中，对数据的删除都应小心操作，因为一旦删除无法恢复。因此使用状态（status）字段来表示设备的删除状态。因此，前面的API获取设备列表和获取设备信息功能中，查询数据库都要添加对状态（status）字段的判断。在用户看来已被删除（实际上在表中没有删除）的设备不应出现在列表中，也不能被获取详细信息，不能更改设备信息。
　　5.4.2 传感器类
　　传感器和设备属于多对一的关系，即一个设备可以包含多个传感器，每个传感器必然属于某一个设备。因此在数据库设计中，传感器表中也使用了外键约束，设备ID（device_id）引用设备表（tb_device）中的设备ID（id）栏。
　　创建传感器时应该指定该传感器所属于的设备（创建设备时，自动设置所属用户为API使用者），因此API虽大部分类似与设备类，但依旧有些许不同。
　　对于传感器的操作，权限和归属的检查同时也要深入到传感器的层次，同时也要检查传感器所属设备的归属。
　　（1） 获取传感器列表
　　请求方法：GET
　　请求URI：/api/sensors/《device_id》
　　响应内容：返回JSON格式的对象数组
　　设计方法：
　　首先调用公有函数_check_device（）检查设备状态，使用该设备ID在传感器表（tb_sensor）中查询所有属于该设备ID的传感器，进行JSON编码后返回数据。
　　（2） 添加传感器（向特定设备添加）
　　请求方法：POST
　　请求URI：/api/sensors/《device_id》
　　响应内容：返回成功或失败的信息
　　设计方法：
　　首先调用公有函数_check_device（）检查设备状态。使用基本的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）、值（value）。
　　对于数据点的数据库设计曾经有多种方案，最终暂时采取了最简单、最直接的一种设计方案：只使用一个表保存不同类型数据传感器的数据，并且使用可变长度字符串（varchar）直接保存数值。这样设计的优点在于，数据点的插入和查询都比较简单，并且数值的类型几乎没有限制，传感器的值甚至可以使用一个字符串（一句话）。但缺点也很明显：首先，传感器类型的区分就没有太多意义了；存储空间的使用效率可能会比较低。
　　在MySql中，对于可变字符串（varchar）而言，真实占用的空间为字符串的实际长度n+1 Byte。对于开关量，以0和1表示的话，则每个值需要占用2 Bytes；对于整型数值，位数n越长，占用Byte数就越多，为n+1 Bytes；对于浮点数来说，以两位整数、两位小数为例，需要占6 Bytes。
　　总的来说，只有在数值为位数较少的整型时，才勉强占用空间略小；其它情况下，都多占了很多的存储空间。
　　另一种设计方案则是为每种数据类型的传感器设计不同的表存储数据。如开关量，将value列设为布尔型；整型数值，将value列设为int型；浮点型数值，将value列设为float型。这样的确充分利用了存储空间，但在某些功能的设计时遇到了很大的麻烦，尤其是批量上传数据、批量获取数据时。故而，这种数据库设计方案被置为保留方案，暂时使用最方便的方案。
　　（1） 创建数据点
　　请求方法：POST
　　请求URI：/api/datapoint/《sensor_id》
　　响应内容：返回成功或失败的信息
　　设计方法：
　　首先调用公有函数_check_sensor（）检查传感器状态和权限。使用基本的Web表单的形式将数据点信息提交到云平台，由云平台获取表单数据，在结合已有的URI参数传感器ID，进行数据库的插入操作，返回操作成功的提示信息。
　　该功能的数据库操作涉及3个表：数据点表（tb_datapoint_lite）、传感器表（tb_sensor）、设备表（tb_device）。在创建数据点的时候，时间戳使用的是服务器自动生成的时间戳，不需要再单独上传。在为传感器创建数据点的时候，我们认为传感器数据得到更新，于是同时更新传感器表（tb_sensor）中的最禁更新时间（last_update）和最近数据（last_data）为数据点的时间戳和数据值。同时，我们认为设备是活动的，于是将设备表中的活动时间（last_acitve）设置为当前时间戳。至此，创建数据点及其连带的操作才算完成。
　　（2） 获取传感器最新数据点
　　请求方法：GET
　　请求URI：/api/datapoint/《sensor_id》
　　响应内容：返回时间戳和数据
　　设计方法：
　　首先调用公有函数_check_sensor（）检查传感器状态和权限，然后直接从传感器表中读出最近（最新）的数据和时间戳，并返回。
　　（3） 批量上传数据点（网关用）
　　请求方法：POST
　　请求URI：/api/datapoints/《device_id》
　　响应内容：成功或失败的信息
　　设计方法：
　　该功能主要面向智能家居网关开发，用于批量上传某个设备内所有传感器的数据。这个操作只会修改URI中指定的设备的最后活动时间（不是根据传感器再来判断更新哪个设备）。因为数据处理比较复杂，所以对网关上传数据时有一定的要求：上传时在URI中指定传感器所属设备，上传数据的所有传感器都应属于该设备，否则不会为它创建数据点；上传数据时依然使用表单的形式，设置json值为要提交的数据的JSON字符串（即将数据组织成JSON数据再通过表单传递过来）。
　　处理流程为：
　　调用公有函数_check_device（）检查用户权限。云平台接受通过表单传递过来的JSON数组，对之进行解析成PHP索引数组。遍历数组每一个元素，然后组织出两个数组：一个用于批量更新传感器表的数据，一个用于批量插入数据点。执行SQL语句，返回结果。
　　（4） 批量获取数据
　　请求方法：GET
　　请求URI：/api/datapoints/《type》/《id》
　　响应内容：JSON格式的对象数组
　　设计方法：
　　当《type》=device时，《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。云平台面向的用户群为开发者，为无线智能家居系统后期开发服务。