CN109156066B - 用于对凭证进行验证的系统和方法 - Google Patents

Abstract

所公开的是用于对物理环境的基于云的监视和控制的系统和方法。在各种实施例中，寻求验证照明系统控制器（1352，1452，1552）的凭证的计算设备（1350，1450，1550）可以获取所述照明系统控制器的未经验证的凭证。所述计算设备可以经由第一网络通信信道向第一远程设备发送对于验证所述未经验证的凭证的请求。所述计算设备可以经由第二网络通信信道从所述第一远程设备或第二远程设备接收验证。所述第二网络通信信道可以与所述第一网络通信信道不同。所述计算设备可以将所述未经验证的凭证与所述验证数据进行比较，以及基于所述比较，验证所述未经验证的凭证是合法的。基于所述验证，所述计算设备可以在所述计算设备与所述照明系统控制器之间建立照明信息通信信道。

Description

用于对凭证进行验证的系统和方法

技术领域

本公开总体涉及对诸如室内或室外空间的物理环境的监测和控制。更具体地，但非排他地，本文中公开的各种系统、方法和装置涉及验证与被部署在物理环境中的各种设备相关联的凭证。

背景技术

由于能量效率对于节约成本已经变得至关重要，所以对室内环境以及资源（例如，电器的使用）的监测最近已经变得重要，并且多种多样的努力领域中的技术进步已经使得实时搜集和处理相关数据成为可能。然而，尽管有这些技术进步，但存在尚未被现有技术充分解决的许多障碍（例如，数据隐私和可伸缩性的问题）。

出于多种多样的原因，室内以及室外照明当前正离开传统的荧光灯、HID和白炽灯，并走向并入了半导体光源（例如，发光二极管（LED））的数字照明技术。除其他益处外，LED照明还提供可控性、高能量转换和光学效率、耐久性和显著降低操作成本的优点。另外，可控LED技术的更新近的进步已经产生多种多样高效且鲁棒的全光谱照明源，这些全光谱照明源可以被容易地控制以创建用于剧场、办公室或家庭环境中的各种照明效果和场景。

如照明技术中一样，在传感器技术领域中也已经做出了快速发展。由于这些改进，传感器正在变得更小、更便宜、并且因此更泛在。由于它们现在适合放入各种日常设备（例如，光源外壳、摄像头和各种其他小型电器）中，所以它们不仅正被用于持续地测量和监测更简单的环境指标（例如，自然光照、噪声、占用、温度、湿度），而且被用于测量和监测诸如资源和空间使用、活动水平、入侵和心情的更复杂的指标，这可能需要对各种传感器类型的经协调的使用。

进一步地，无线通信、智能移动设备和云计算领域中的创新的交叉已经为智能环境创造了甚至更多的可能性。利用具有空前的移动性和计算能力的新一代计算设备、连接的电器（例如，物联网）、对泛在的连接的传感器的访问和基于云的服务的处理和分析能力，现在能够接近实时地搜集和处理来自直接环境和远程环境二者的数据。随着更多设备能够不仅连接到公共或私有网络（例如，互联网），而且还与彼此连接和通信，已经存在关于物理环境的数据的剧增。由于许多类型的设备内的传感器的剧增和集成，我们现在知道何时设备已经损坏或接近到达它们的寿命终点，以及关于围绕这些设备的环境状况的许多信息。由于这样的数据昼夜不停地生成，所以存在对于以及时和有意义的方式对其进行分析使得可以纠正不利状况或避免灾难的不断增长的需要。然而，如在下面讨论的，在寻求监测和操纵这些智能物理空间内的状况时存在许多需要避免的陷阱。

在传感器从包括与私人或人群相关联的房间的物理建筑的全部角落搜集数据时，被搜集的数据可以是来自智能电话或平板电脑的能够标识个人和他们参与的活动的数据或敏感性图像数据。对这样的数据的搜集和处理造成数据隐私问题，数据隐私问题可能变成用于对物理空间进行监测的系统正常运转的核心。需要仔细地考虑和实现这样的数据需要如何被匿名化和/或聚合、谁可以查看原始数据或经分析的数据、如何呈现数据以避免标识具体的个人、数据如何被安全地从其源（例如，搜集原始数据的传感器）发送到其目的地（例如，基于云的服务器或个人的智能电话上的应用）。现有的用于监测空间和资源使用的系统尚未开发用于解决这样的问题的综合策略。

另外，从物理空间搜集的空间和资源使用数据需要被准确地加时间戳、以足够的粒度被搜集和以及时的方式被处理，以便提供可以产生能量效率或其他使用效率的见解。例如，未被恰当地加时间戳的占用数据可能无法提供关于何时诸如会议室或走廊的空间被大量使用的准确信息。并且向用于分析的合适云服务器提供该数据的延迟可以例如导致不能（例如，通过建议备选走廊来引导业务量流）及时地在高业务量区域中调度维护或积极地影响近期对这样的空间的调度。同样，现有的用于监测空间和资源使用的系统尚未开发用于解决这样的问题的综合策略。

为了充分管理大型站点（诸如充当大型公司的总部的建筑）处的能量和/或空间使用，通常将需要大量的（并且多种多样的）传感器设备以执行基本数据生成。此外，这样的设施通常具有多种多样的电器（例如，打印机、扫描仪、照明设备），并且对它们的使用进行监测将还提供关于能量效率的有用信息。尽管这些设备可以能够全部连接到诸如局域网的网络，但它们生成的数据将很可能采用多种多样的格式。相应地，任何将使用由全部存在的设备生成的信息的系统需要能够将来自这些设备的数据的格式转换成可以被由系统使用的各种数据处理应用理解和处理的一种或多种公用格式。同时，这样的建筑级的系统需要使得对于多种多样的设备来说易于与彼此和与系统接口连接（例如，通过暴露使得易于添加对新通信协议或新设备类型的支持的API）。并且即使随着这样的用于对空间和资源进行监测的建筑或站点级系统在它们的功能复杂度方面增长，在这样的系统内安装和升级单独部件需要是相对无缝的，而不需要每一步都有高技能的安装人员的参与。

此外，这样的系统需要具有在不压垮系统的任意部分的情况下并入新设备的能力。换言之，这样的系统需要是可扩展的，原因在于从网络带宽、安装效率和数据分析的角度看，它们应当能够舒适地容纳越来越多数量的设备和用户，以及因此容纳越来越多量的所生成的数据。并且这样的复杂系统应当能够在没有显著数据丢失的情况下对错误进行管理。换言之，它们应当预见和最小化硬件或软件故障时的数据丢失。

附加地，为了确保这样的环境的部件之间的通信的安全性以及命令和/或传感器日志数据的完整性和/或机密性，应当对环境内的各种部件和实体进行认证。通常，这样的认证是在传输层处（例如，在网络栈的TCP或UDP层处）实现的，因为它允许不同的应用层协议安全地操作。传输层认证通常是使用诸如证书的凭证或通过执行使用密钥（例如，预共享秘密）的操作实现的。例如，可以在一个通信对端上安装根证书。该根证书可以被用于对证书链进行验证。然而，在一些情况下，这可能要求建立和维护公钥基础设施（“PKI”）。PKI往往在经济和所需的专业技能方面都很昂贵。 没有现有的用于监测和控制物理环境的系统为至少前述的挑战提供解决方案。下面呈现的系统、方法和装置提供被设计为解决这些和其他挑战的解决方案。

发明内容

本文中的各种实施例针对用于对物理环境的基于云的监测和控制的系统和方法，以便解决前面的部分中阐述的问题。本部分呈现这些方法和系统中的一些的简化的发明内容，以便提供对各种系统部件、这样的部件之间的交互和各种实施例中所涉及的各种步骤的基本理解。本发明内容不旨在作为对全部发明实施例的详尽概述。本部分中描述的系统部件和方法步骤不一定是关键的部件或步骤。本发明内容部分的目的是作为随后的具体实施方式的序言以更简化的形式呈现对各种概念的概述。

在各种实施例中，一种用于对凭证进行验证的计算机实现的方法可以包括以下操作：在寻求验证照明系统控制器的凭证的计算设备处获取照明系统控制器的未经验证的凭证；由计算设备经由第一网络通信信道向第一远程设备发送对于验证未经验证的凭证的请求；在计算设备处经由第二网络通信信道从第一远程设备或第二远程设备接收验证数据，其中，第二网络通信信道与第一网络通信信道不同；由计算设备将未经验证的凭证与验证数据进行比较；由计算设备基于比较验证未经验证的凭证是合法的；基于验证，由计算设备在计算设备与照明系统控制器之间建立照明控制信息通信信道；以及由计算设备经由照明信息通信信道与照明系统控制器交换与一个或多个光源的操作相关的数据或来自一个或多个传感器的数据。

在各种实施例中，第二网络通信信道可以包括光学无线通信信道，并且接收可以包括在计算设备的光传感器处检测经调制的光学无线信号。在各种实施例中，光学无线通信信道可以包括可见光通信信道。在各种实施例中，验证数据可以是从第二远程设备接收到的，并且第二远程设备包括连网的灯具。在各种实施例中，光学无线通信信道可以是由第一远程设备或第二远程设备经由数字显示设备或经由一个或多个基于LED的指示器灯实现的。

在各种实施例中，第一网络通信信道可以包括基于射频的通信信道。在各种实施例中，基于射频的通信信道可以是使用Wi-Fi、ZigBee或Z-Wave实现的。在各种实施例中，验证数据可以包括由第一或第二远程设备生成的未经验证的凭证的第一散列，并且比较包括：将第一散列与由计算设备生成的未经验证的凭证的第二散列进行比较。

在各种实施例中，方法还可以包括：由计算设备设置定时器；以及由计算设备拒绝任何在定时器期满之后被接收到的验证数据。在各种实施例中，验证数据可以是从第二远程设备接收的，并且对于验证未经验证的凭证的请求可以包括与第二远程设备相关联的标识符。

在各种实施例中，方法还可以包括：由计算设备基于从被提供在第一远程设备的表面上的标记中获取的信息生成秘密密钥；由计算设备基于秘密密钥执行加密散列函数以生成第一加密散列函数输出；由计算设备向第一或第二远程设备发送第一加密散列函数输出；由计算设备从第一或第二远程设备接收第二加密散列函数输出；以及由计算设备对第二加密散列函数输出进行验证。在各种实施例中，由计算设备向第一远程设备发送对于验证未经验证的凭证的请求可以是基于对第二加密散列函数输出进行的验证的结果有选择地执行的。

其他实施例可以包括存储指令的非暂时性计算机可读存储介质，该指令是可以被处理器执行的，以执行诸如本文中描述的方法中的一个或多个的方法。其他实施例可以包括包含存储器和一个或多个处理器的系统，该一个或多个处理器可操作以执行存储在存储器中的指令以执行诸如本文中描述的方法中的一个或多个的方法。

如本文中出于本公开的目的所使用的，术语“LED”应当被理解为包括任何电致发光二极管或能够响应于电信号而生成辐射和/或充当光电二极管的其他类型的载流子注入/基于结的系统。因此，术语LED包括但不限于响应于电流而发射光的各种基于半导体的结构、发光聚合物、有机发光二极管（OLED）、电致发光带等。特别地，术语LED指的是可以配置为在红外光谱、紫外光谱和可见光谱（通常包括从大约400纳米到大约700纳米的辐射波长）的各个部分中的一个或多个中生成辐射的所有类型的发光二极管（包括半导体和有机发光二极管）。LED的一些示例包括但不限于各种类型的红外LED、紫外LED、红色LED、蓝色LED、绿色LED、黄色LED、琥珀色LED、橙色LED和白色LED（下面进一步讨论）。还应当领会，可以配置和/或控制LED以生成具有对于给定光谱（例如，窄带宽、宽带宽）的各种带宽（例如，半高全宽，或FWHM）以及给定的一般颜色分类中的各种主波长的辐射。

例如，配置为生成基本上白光的LED的一种实施方式（例如，白色LED）可以包括多个管芯，其分别发射组合地混合以形成基本上白光的不同的电致发光光谱。在另一实施方式中，白光LED可以与磷光体材料相关联，该磷光体材料将具有第一光谱的电致发光转换为不同的第二光谱。在此实施方式的一个示例中，具有相对短波长和窄带宽光谱的电致发光“泵浦”磷光体材料，其反过来辐射具有稍微更宽光谱的更长波长的辐射。

还应该理解，术语LED不限制LED的物理和/或电封装类型。例如，如上文所讨论的，LED可以指具有多个管芯的单个发光设备，该多个管芯配置为分别发射不同的辐射光谱（例如，其可以是或可以不是可单独控制的）。而且，LED可以与被认为是LED（例如，一些类型的白色LED）的组成部分的磷光体相关联。通常，术语LED可以指封装的LED、非封装的LED、表面安装LED、板上芯片LED、T封装安装LED、径向封装LED、功率封装LED、包括一些类型的外壳和/或光学元件（例如，漫射透镜）的LED等。

术语“光源”应该被理解为是指各种辐射源中的任何一个或多个，包括但不限于基于LED的源（包括如上定义的一个或多个LED）。给定光源可以配置为在可见光谱内、可见光谱外或二者的组合中生成电磁辐射。因此，术语“光”和“辐射”在本文中可互换使用。另外，光源可以包括一个或多个滤光器（例如，滤色器）、透镜或其他光学部件作为组成部件。而且，应该理解，光源可以被配置用于各种应用，包括但不限于指示、显示和/或光照。“光照源”是特别配置为生成具有足够强度的辐射以有效地照射内部或外部空间的光源。在此上下文中，“足够强度”是指在空间或环境中生成的用于提供环境光照（即，可以间接感知的光、以及可能例如在被全部或部分感知之前从各种中间表面中的一个或多个反射掉的光）的可见光谱中足够的辐射功率（就辐射功率或“光通量”而言，单位“流明”通常被采用来表示从光源在所有方向上的总光输出）。

术语“光谱”应当被理解为指由一个或多个光源产生的任何一个或多个频率（或波长）的辐射。相应地，术语“光谱”指不仅可见光范围中的频率（或波长），而且还有总电磁光谱的红外区域、紫外区域和其他区域中的频率（或波长）。此外，给定光谱可以具有相对窄的带宽（例如，FWHM具有基本上少量频率或波长分量）或相对宽的带宽（若干频率或波长分量具有各种相对强度）。还应当认识到，给定光谱可以是由对两个或多个其他光谱进行的混合产生的（例如，混合分别从多个光源发射的辐射）。

出于本公开的目的，术语“颜色”与术语“光谱”可互换地使用。然而，术语“颜色”一般被用于主要指可以被观察者感知的辐射的属性（尽管该用法不旨在限制该术语的范围）。相应地，术语“不同颜色”暗含地指具有不同的波长分量和/或带宽的多个光谱。还应当领会，术语“颜色”可以结合白光和非白光二者使用。

术语“照明器材”和“灯具”在本文中被可互换地使用，以指代具有特定形状因子、组装或封装中的一个或多个照明单元的实施方式或布置。术语“照明单元”在本文中用于指包括相同或不同类型的一个或多个光源的装置。给定的照明单元可以具有针对（多个）光源、外壳/壳体布置和形状、和/或电气和机械连接配置的各种安装布置中的任何一种。另外，给定的照明单元可选地可以与涉及（多个）光源的操作的各种其他部件（例如，控制电路）相关联（例如，包括、耦合到和/或与其一起封装）。“基于LED的照明单元”是指包括如上文所讨论的一个或多个基于LED的光源（单独或与其他非基于LED的光源组合）的照明单元。“多通道”照明单元是指包括配置为分别生成不同的辐射光谱的至少两个光源的基于LED或非基于LED的照明单元，其中每个不同的源光谱可以被称为多通道照明单元的“通道”。

术语“控制器”在本文中被一般用于描述涉及对一个或多个光源的操作各种装置。控制器可以用许多方式（例如，诸如用专用硬件）被实现以执行本文中讨论的各种功能。“处理器”是采用一个或多个微处理器的控制器的一个示例，所述一个或多个微处理器可以使用软件（例如，微代码）被编程以执行本文中讨论的各种功能。控制器可以在采用或不采用处理器的情况下被实现，并且还可以被实现为用于执行一些功能的专用硬件与用于执行其他功能的处理器（例如，一个或多个经编程的微处理器和相关联的电路）的组合。可以在本公开的各种实施例中被采用的控制器部件的示例包括但不限于常规微处理器、专用集成电路（ASIC）和现场可编程门阵列（FPGA）。

在各种实施方式中，处理器或控制器可以与一个或多个存储介质（本文统称为“存储器”，例如，易失性和非易失性计算机存储器（诸如RAM、PROM、EPROM和EEPROM）、软盘、压缩盘、光盘，磁带等）相关联。在一些实施方式中，存储介质可用一个或多个程序编码，该一个或多个程序在一个或多个处理器和/或控制器上执行时执行本文所讨论的至少一些功能。各种存储介质可以固定在处理器或控制器内，或可以是便携的，使得存储在其上的一个或多个程序可以加载到处理器或控制器中，以便实现本文讨论的本发明的各种方面。本文使用的术语“程序”或“计算机程序”在一般意义上是指可以被采用于编程一个或多个处理器或控制器的任何类型的计算机代码（例如，软件或微代码）。

在一个网络实施方式中，耦合到网络的一个或多个设备可以充当耦合到网络的一个或多个其他装置的控制器（例如，以主/从关系）。在另一实施方式中，联网环境可以包括一个或多个专用控制器，其配置为控制耦合到网络的设备中的一个或多个。通常，耦合到网络的多个设备各自可以访问存在于一个或多个通信介质上的数据；然而，给定设备可以是“可寻址的”，原因在于，它配置为基于例如指派给它的一个或多个特定标识符（例如，“地址”）选择性地与网络交换数据（即，从网络接收数据和/或向网络发射数据）。

如在本文中使用的术语“网络”是指促进在任何两个或更多个设备之间、和/或耦合到网络的多个装置之中的信息的传输（例如，用于设备控制、数据存储、数据交换等）的两个或更多个设备（包括控制器或处理器）的任何互连。如应该容易领会的，适合于互连多个设备的网络的各种实施方式可以包括各种网络拓扑中的任一种，并采用各种通信协议中的任一种。另外，在根据本公开的各种网络中，在两个设备之间的任何一个连接可以表示在两个系统之间的专用连接、或可替换地是非专用连接。除了携带旨在用于两个设备的信息之外，这种非专用连接可以携带不一定旨在用于两个设备中的任一个的信息（例如，开放网络连接）。此外，应该容易领会的是，如本文所讨论的设备的各种网络可以采用一个或多个无线、有线/线缆和/或光纤链路来促进整个网络的信息传输。如本文使用的，短语被通信地耦合指能够或直接地或经由中介实体（例如，其他设备或网络）间接地与彼此通信的两个设备或其他实体。为了被通信地耦合，两个或多个设备不需要具有专用连接。它们应当简单地能够在必要时向彼此发送数据和/或从彼此接收数据。

如本文使用的术语“用户”指与本文中描述的系统和方法交互的任何实体、人或人工品。例如，该术语包括而不限于诸如办公室职员或访问者的空间占用者、空间的远程用户、设施经理、入网初始化工程师、建筑IT经理、服务工程师和安装人员。

术语“模块”或“应用模块”在本文中被频繁地用于描述部件。这些术语针对软件或固件部件或其组合。单个软件/固件模块可以由一个或多个模块组成。完整的软件模块可以在各自驻留在一个或多个设备上的一个或多个处理器上被执行。相同模块（例如，前端）的一个或多个部件可以在一个设备上被执行或以其他方式显示，该一个设备可以远离执行或显示该相同模块的其他部件的另一个设备。单个软件模块可以包含一个或多个例程或功能。软件模块可以暴露可以被其他模块使用的API。这些术语被用于描绘不是正在被执行的计算机代码和正在执行的代码（例如，“运行时间”模块）二者。

术语“系统设备”贯穿本说明书使用。在各种实例中，它可以意指诸如网关（无线或其他）或建筑服务器的设备。它还应用于被用在物理环境中的其他设备，诸如传感器、照明设备（例如，灯具、独立光源）、HVAC设备（例如，加热设备、湿度调节器、空调）、电器（例如，智能板、电冰箱、清洁电器、洗碗机、洗衣机/干衣机、电视机）、计算/通信设备（例如，路由器、智能电话、平板计算机）和各种其他感应器（sensic）或照明器（lumic）设备。

在本说明书中描述的图中的许多图中，加标记的箭头被用于描绘模块之间的通信（例如，模块-模块通信）、设备之间的通信（例如，设备-设备通信）或其某种组合（例如，设备-模块通信）。模块-模块通信可以在例如云中的系统应用模块与建筑服务器中的模块之间或在建筑服务器中的模块与无线网关中的另一个模块之间。取决于箭头代表的通信类型，通信可以涉及功能调用或其他进程间通信机制。这样的通信可以通过一个模块或设备发出用于直接地调用来自模块或设备的动作或响应（例如，通过调用模块的导致使该模块执行诸如更新数据库的动作的API）的命令或其他信号而被直接地执行。这样的通信还可以被间接地或异步地执行，诸如，一个模块更新队列或其他存储器，另一个模块在某个稍后的时间点处访问该队列或其他存储器，导致由第二个模块使用经更新的信息的动作。各种通信协议（例如，HTTPS和MQTT）可以被用于在各种模块和设备之间传送或交换信息。例如，HTTPS有时被称为例如建筑服务器中的模块与网关中的另一个模块之间或建筑服务器与云之间的通信协议。然而，出于图示数据交换的目的对HTTP和MQTT的使用不应当被看作限制性的，并且也可以应用其他通信协议和技术。

应当领会的是，前述概念和下面更详细讨论的附加概念的所有组合（假设这些概念不相互不一致）被认为是本文公开的发明主题的一部分。特别地，出现在本公开结尾处的所要求保护的主题的所有组合被认为是本文公开的发明主题的一部分。还应当领会的是，也可以出现在通过引用并入的任何公开中的本文明确采用的术语应当被赋予与本文公开的特定概念最一致的含义。

附图说明

在附图中，相同的附图标记贯穿不同视图一般地指相同的部分。此外，附图不一定按比例绘制，而是一般将重点放在说明本发明的原理上。

图1图示了用于对物理环境的基于云的监测和控制的系统的实施例的框图，该实施例包括若干基于云的模块和若干位于被监测的环境内的模块和设备。

图2图示了从各种源进入管理与被监测的空间相关联的信息流的数据平台的示范性数据流。

图3图示了被用于对物理环境的基于云的监测和控制的系统的实施例使用的数据存储和操纵系统的实施例。

图4图示了用于对用于对物理环境的基于云的监测和控制的系统的实施例内的设备进行入网初始化的方法的实施例。

图5A、5B和5C图示了用于对物理环境的基于云的监测和控制的系统中的设备定位的各种实施例。

图6图示了可以被用于对物理环境进行监测和控制的示范性的基于云的系统使用的各种照明应用的交互的实施例。

图7A、7B和7C图示了用于对物理环境进行监测和控制的示范性的基于云的系统的特定部署的实施例的框图。

图8A和8B图示了将建筑服务器注册和连接到用于对物理环境进行监测和控制的示范性的基于云的系统的方法的实施例。

图9图示了更新用于对物理环境进行监测和控制的示范性的基于云的系统中的诸如感应器设备的系统设备的软件或固件的方法的实施例。

图10A和10B图示了在用于对物理环境进行监测和控制的示范性的基于云的系统处定位建筑服务器的方法的实施例。

图11图示了在用于对物理环境进行监测和控制的示范性的基于云的系统处定位网关设备的方法的实施例。

图12A、12B-I和12B-II图示了在用于对物理环境进行监测和控制的示范性的基于云的系统处定位诸如感应器设备的系统设备的方法的实施例。

图13示意性地图示了根据各种实施例的用于验证各种部件的凭证的一种示例技术。

图14示意性地图示了根据各种实施例的用于对各种部件的凭证进行验证的另一种示例技术。

图15示意性地图示了根据各种实施例的用于对各种部件的凭证进行验证的又一种示例技术。

具体实施方式

现在详细参考本发明的说明性实施例，在附图中示出了这些实施例的示例。

在以下详细描述中，出于解释而非限制的目的，阐述了公开具体细节的有代表性的实施例以提供对本教导的透彻理解。然而，对于已经具有本公开内容的好处的领域的技术人员应当显然的是，脱离本文中公开的具体细节的符合本教导的其他实施例仍然落在所附权利要求的范围内。此外，可以省略对公知的系统、装置和方法的描述，以便不使对有代表性的实施例的描述模糊不清。这样的系统、方法和装置明显落在本教导的范围内。

图示总体系统架构的特征的实施例

图1图示了用于物理环境的基于云的监测和控制的系统100A。该系统包括建筑服务器100、网关110A和110B、系统设备101至106、计算云115、系统能量应用模块120、系统摄入应用模块130、系统项目应用模块140、用户管理应用模块150、系统地图应用模块160、项目数据库170A、数据数据库170B、数据平台模块180和云连接性模块190。系统100A的其他实施例可以包括附加的或更少的建筑服务器、网关、系统设备、云、数据库模块、云连接性模块和数据平台。使用图1中描绘的链接线通信地链接系统100A的各种部件。然而，图中的两个块或模块之间的链接线的缺少不一定指示这些块或模块之间的通信能力的缺少。如本文中使用的术语“物理结构”或“物理环境”指任何建筑结构（无论是否是独立式的、永久性的、封闭式的还是覆盖式的）。该术语包括例如办公、住宅、娱乐、教育、政府和商业建筑和复合体以及停车场和车库。如本文中使用的术语“链接”指任何使能至少两个设备或系统部件之间的信息通信的连接或部件（无论是物理的还是虚拟的）。例如，链接包括有线或无线通信连接、射频通信连接和光学通信连接。链接还可以指示共享的通信协议、软件或硬件接口或远程方法调用或过程调用（call）。

云115是被用于云计算的典型的云。它向可以访问其的各种设备提供共享的数据和处理资源。其使能进行对诸如网络、服务器、存储装置、应用和服务的计算资源的共享池的按需访问。云115支持系统100A的各种基于云的应用，包括系统能量应用模块120、系统摄入应用模块130、系统项目应用模块140、用户管理应用模块150、系统地图应用模块160。这些应用和云基础设施提供系统100A的两个关键方面。首先，负责在特定建筑或建筑群中安装如系统100A的系统的安装人员不需要专业培训。其次，被监测和控制的物理环境中的系统设备和资源的期望行为被存储在云自身中，并因此可以容易地配置和下载。

系统能量应用模块120是可以由系统100A的外行（lay）终端用户或由系统100A的特殊专家用户（例如，设施经理）用于审查报告或执行与能量管理相关的各种任务的基于云的软件应用。例如，设施经理可能希望检查在特定一周中的平均每日消费以确定一个特定星期一是否具有相比于平均星期一显著更高的能耗，或审查关于过去一年中的每月能耗的数据以确定能量使用的季节性改变。系统能量应用模块120因此能够出于搜集关于用户想要看到什么类型的信息被呈现的信息的目的以及出于以图形的（例如，条形图、热图）或原始形式呈现必要信息的目的向其用户呈现用户接口，其可以是本质上交互式的。它可以自身或通过使用位于云115之内或外部的分析模块来执行使用被存储在数据数据库170B中的能耗数据的分析。在与图6相关联的描述中详细讨论了系统能量应用模块120。

系统摄入应用模块130是可以被系统100A的摄入工程师（在下文中“摄入者”）或其他专家用户用于为被系统100A管理的一个或多个物理结构确定和/或建立照明和/或其他能量需求的基于云的软件应用。使用至少用户接口提供的系统摄入应用模块130，摄入者可以从由应用模块130呈现的地图视图中选择一个或多个建筑。摄入者可以进一步使用应用模块130加载所选建筑的特定楼层的现有平面布置图，并进行至建立特殊区域（例如，开放式办公空间、会议室）和用于在这些空间中使用的系统设备（例如，光源、光源网格、网关、开关），以及提供与空间和设备相关联的各种注解（例如，笔记、照片、录音）。系统摄入应用模块130还允许摄入者检查摄入过程以确保例如灯具/光源被恰当地指派给指定区域以及被恰当地指派给各个网关。来自系统摄入应用模块130的该信息此后可以被用于填充项目数据库170A。在与图6相关联的描述中详细讨论了系统摄入应用模块130。

系统项目应用模块140是基于云的软件应用，该基于云的软件应用可以被与系统100A相关联的摄入者、专家、安装人员、管理员和终端用户用于创建和查看被存储在项目数据库170A中的项目分层。应用模块140还将所创建和更新的项目派遣给诸如系统地图应用模块160、系统能量应用模块120或系统摄入应用模块130的其他应用模块。可以例如通过使具有合适特权的用户（诸如管理员）指定与项目相关联的实体（例如，诸如公司的组织）来创建项目分层。此后，管理员可以添加与该实体相关联的物理站点（例如，阿姆斯特丹的物理站点）。对于每个物理站点或位置，管理员此后可以添加一个或多个建筑以及它们相关联的地址和其他标识细节。对于每个建筑，管理员还可以指定诸如总安装功率、备用总功率（无论能量基线是否是动态的）等的能量设置信息。还可以指定诸如与每个建筑或物理站点相关联的工作时间和工作日的细节。在与图6相关联的描述中详细讨论了系统项目应用模块140。

用户管理应用模块150是用于管理与系统100A相关的用户的基于云的软件应用。用户可以取决于他们的称号（例如，安装人员、管理员、项目经理、专家、摄入者或终端用户）被允许对系统100A的不同级别的访问特权。还有可能指定其他称号。用户可以与特定建筑或与整个项目相关联。用户管理应用模块150可以提供允许有资格的个人或实体访问项目数据库170A以及创建、更新和删除与项目分层相关联的用户或与特定项目分层内的特定建筑/站点相关联的用户的多种多样的用户接口。例如，具有管理与公司A的项目分层相关联的用户的特权的管理员可以添加具有带有特定姓名、地址、年龄和其他详情的安装人员的角色的用户，并且指派允许该用户利用系统摄入应用模块130和系统项目应用模块140执行诸如灯具、开关和网关的设备向与公司A的项目分层相关联的各种位置处的建筑的安装的合适访问特权。在与图6相关联的描述中详细讨论了用户管理应用模块150。

系统地图应用模块160是可以被作为安装人员的用户用于向与项目分层相关联的各种系统设备（例如，灯具、传感器、开关、网关）注册、定位以及部署配置信息的基于云的软件应用。它可以呈现与这些设备相关联的定位信息、建筑的各种楼层的地图视图和相关联的系统设备在每个楼层的平面布置图上的位置。它可以允许安装人员图形化地在交互式地图/平面布置图上添加、移除或重新定位系统设备，以及在其上描绘与这些设备相关联的其他配置信息。为了便于安装，应用模块160可以在安装人员可以在位于安装站点处时使用的诸如智能电话或平板型计算机的移动设备上渲染其前端。在与图6相关联的描述中详细讨论了系统地图应用模块160。

建筑服务器100是充当物理建筑与诸如云115的云之间的数据网关的系统设备。在其许多任务中，其将配置数据从云路由到建筑中的系统设备、将能耗数据从设备路由到云、对能耗数据进行缓冲以预计与云的临时连接性丢失以及将环境度量数据和诊断数据从建筑路由到云，环境度量数据包括例如建筑占用数据，并且诊断数据包括例如感应器诊断数据。建筑服务器100还可以执行各种系统管理任务。例如，它可以向网关提供时间同步、管理软件/固件升级过程（例如，处置来自云115的软件/固件更新触发，以及存储网关和感应器的软件/固件图像）以及实现建筑级功能（例如，调度器、ADR）。建筑服务器100可以使用以下外部接口：MQTT，以从云115获取系统设备的配置数据、向云115推送发现消息和通知各种网关关于软件/固件更新。建筑服务器100还可以使用HTTPS来在云115中注册设备、向云115提供能量使用和其他环境度量数据以及将软件/固件更新提供给网关和其他系统设备。建筑服务器100还可以采用用于在MQTT与网络提供商之间交换数据的ZeroC（ICE）进程间通信框架（例如，低层Dynalite协议），来在应用之间交换安全数据。

网关110A或110B可以用硬件、硬件与计算机代码（例如，软件或微代码）的任意组合或完全用计算机代码来实现。该模块可以在一个或多个处理器上执行。在一些实施例中，网关110A或110B的硬件实现可以涉及STM32芯片。网关110A或110B可以与物理结构的特定楼层相关联，并且可以从位于该楼层上的诸如灯具的多个系统设备发送和/或接收数据。在一些实施例中，网关110A或110B可以从大量（例如，1000个）诸如灯具、传感器和HVAC设备的系统设备发送和/或接收数据。

网关110A或110B可以被配置为提供多种多样的功能。例如，它可以在用于在入网初始化灯具时使用的接口（例如，远景IP（EnvisionIP））与另一个接口（例如，RS-485标准）之间提供网关，以及提供用于在各种应用和网络协议之间进行转换的服务。在许多实施例中，它还可以促进系统100A内的多个网关之间数据的路由，以及参与网关110A或110B可以在其期间确定处在其控制下的设备是否仍然在线的系统诊断和/或硬件点名（roll call）。网关110A或110B还可以负责离线设备的高速缓存和/或报告，用于本地调度任务和监测和诊断数据的管理。例如，网关110A或110B可以针对能耗和占用监测物理结构内的一个或多个区域，以及在区域级别上诊断和报告系统健康信息。它还可以存储区域监测信息。

在一些实施例中，网关110A或110B监测系统的一部分中的全部DyNet和远景IP业务。其可以存储和/或高速缓存该信息，以及将该信息转发给其他系统模块使得系统100A在任意给定时间具有对全部经入网初始化的系统设备的状态的准确概览。在许多实施例中，可以将诸如网关110A和110B的多个网关模块与单个建筑服务器100通信地链接，其中每个网关充当建筑的特定楼层的楼层控制器。在功能上，可以将网关110A或110B分解成以下功能部件：FW更新部件、NTP客户机部件、WG诊断部件、发现和注册部件以及ZigBee时钟同步服务器部件。如建筑服务器的被类似命名的模块那样，FW更新模块主要负责协调其自身的和感应器设备的固件和软件更新。在图9的上下文中进一步详细描述了该过程。NTP客户机部件与建筑服务器中的被类似地命名的模块类似，原因在于它参与向感应器设备推送时间数据（例如，用于为环境度量数据加时间戳）。ZigBee时钟同步服务器模块也参与时间同步，并且在伴随图7A-C的描述中详细解释了相关的加时间戳和时间同步过程。WG诊断部件主要负责报告在网关的例行操作期间遇到的错误或其他异常状况或状态。此后经由建筑服务器将这些错误状况或状态向上报告给云（例如，云115）以便进一步分析。最后，发现和注册部件主要负责使网关能够将其自身注册到建筑服务器和/或云。

设备101-106是诸如第三方ZigBee设备、ZigBee绿色电力开关和电池供电的传感器的系统设备。它们还包括可以与像网关110A或110B的网关以及灯具驱动器和灯具自身二者通信的照明器和感应器设备。感应器和照明器可以用软件、硬件或固件来实现，并且包含用于对灯具/设备驱动器的占用或日光控制的模块、用于控制灯具/设备驱动器的致动器、用于感测环境照明或其他环境状况的（多个）传感器、时钟同步模块、用于保持跟踪什么（如果存在）模板已经被部署到它们的各个灯具/设备驱动器的机制以及用于准备关于它们的各个灯具/设备驱动器的行为的报告的机制。

感应器灯具是感应器/照明器设备的一个示例。它通常与传感器、光源和控制模块相关联。在一些实施例中，传感器和光源位于相同的设备或外壳内。在一些实施例中，控制模块包括在被收容在与传感器和/或光源模块相同的设备或外壳内的一个或多个处理器上执行的计算机代码（例如，软件或微代码）。光源可以能够执行一个或多个光致动功能（诸如打开/关闭、调光和可调谐白光或彩色光产生）。传感器是能够感测例如日光、占用、IR、二氧化碳、湿度和温度中的一个或多个的传感器。控制模块提供用于控制其他模块和设备（诸如一个或多个光源、传感器、网关和其他IP灯具）的行为的一个或多个控制功能。附加地，IP灯具可以提供用于与系统100A的其他模块通信的一个或多个外部接口。

项目170A是存储与所创建的与系统100A相关联的项目分层相关的数据并且使其可访问的数据库。该数据库对于诸如建筑服务器100的外部实体和对于诸如系统摄入应用模块130、系统项目应用模块140和系统地图应用模块160的基于云的应用模块来说经由云115可访问。数据170B是存储由各种感应器设备搜集的与能量使用相关的数据以及与空间和资源使用相关的经聚合的/分析数据并且使其可访问的数据库。分析数据也可以被存储在可访问数据170B的其他数据存储库中或利用从数据170B中提取的数据来即时（on thefly）准备。数据平台模块180是为工业级大数据照明或能量基础设施提供用于高效地管理和高效地检索来自多种多样的源的各种格式的数据的软件和硬件结构和服务的数据捕获、管理和存储机制。在图2和3中详细讨论了其各种特征。

云连接性服务模块190允许云和对于云可访问的数据资源中的应用（例如，系统能量应用模块120、项目数据库170A和数据平台模块180）与建筑服务器100之间的连接性。在各种实施例中，它使用MQTT协议在云115与建筑服务器100之间来回移动设备配置和控制。使用HTTPs协议在云115与建筑服务器100之间传输建筑服务器100、网关110A和110B和感应器设备的设备注册和固件或软件更新数据以及建筑/能量使用度量。

随后是对于对系统100的示范性使用的简要描述。在高层处，安装人员（例如，被指派了安装人员的角色的用户）在位于物理建筑中时，首先使用例如系统摄入应用模块130安装建筑服务器100，系统摄入应用模块130的前端被渲染在他们的移动设备上。此后，建筑服务器100访问云115中的注册服务以注册其自身。在与图8A和8B相关联的描述中更详细地描述了注册过程。本质上，注册过程涉及确保出于数据报告目的的建筑服务器100与云115之间的连接性的简单自举（bootstrapping）过程。在安装人员已经成功地安装建筑服务器100之后，安装人员安装网关（例如，110A和110B）并且将它们连接到建筑的IP骨干。在网关被加电时，它们能够自动“发现”建筑服务器100。网关此后将使用建筑服务器100来将其自身注册到云115。在本申请中将结合其他附图讨论关于这如何完成的细节。在成功安装之后，云中的（例如，被存储在项目170A数据库中的）相关联的项目分层将具有对于系统100A的操作必要的全部数据。ZigBee®协议是用于在系统/感应器设备与网关之间传送环境度量数据以及固件/软件更新数据的最常见的协议。网关和建筑服务器还使用其他通信协议（例如，TLS和HTTPs）来传送网关和感应器设备的固件/软件更新数据以及传送诸如设备/能量使用度量的环境度量数据。

接下来，安装人员在诸如系统地图应用模块160的基于云的应用在诸如平板型计算机的便携式设备上运行的情况下的进入建筑。安装人员扫描建筑服务器100的QR码。该QR码包含与建筑服务器100相关联的唯一标识符。应用模块160能够从项目170A数据库中检索与建筑服务器100相关联的项目分层数据、基于安装人员在应用模块160上描绘的平面布置图上对建筑服务器的位置的选择来定位建筑服务器100，以及必要时用关于建筑服务器100的附加信息（例如，定位信息）更新项目170A数据库。

接下来，安装人员对诸如ZigBee灯具的感应器设备进行定位。诸如系统地图应用模块160的应用从项目170A数据库检索相关项目分层数据，并且安装人员在物理地去往每个灯具处，并且在平面布置图上选择代表灯具的图标。使用诸如IR遥控器的设备，然后安装人员可以将设备添加到诸如ZigBee网络的个域网。物理灯具然后可以使用ZigBee网络与被指派的网关（例如，网关110A）通信。配置信息（诸如哪个网关应当负责哪个系统设备）被存储在项目170A数据库中。相应地，在灯具被选择时，云115已经“知道”需要打开哪个网关连接以正式将设备添加到网关。网关-系统设备定位是双方面（two-fold）过程。云115经由建筑服务器100向特定网关发送用于将诸如灯具的设备添加到其自身的命令。设备或灯具自身尝试加入特定网关的ZigBee网络，并且在成功地加入网络时，它向该特定网关通告其自身。

如在上面简要描述的，一旦定位已经完成，云115将经由建筑服务器和网关将配置数据部署到各种系统/感应器设备。配置数据包括例如控制诸如灯具的设备的行为的数据。这样的数据包括关于设备对指示区域现在被占用的传感器应当如何反应的信息。在配置部署完成时，将在系统地图应用模块160上可视化该事实。例如，已经成功地接收其配置数据的灯具将由改变了的图标代表。一旦定位和配置数据部署已经完成，安装人员具有验证定位和部署的方面是否成功的选项。例如，应用模块160提供用于测试被部署的灯具的行为的引导的测试程序。一旦任何这样的测试成功完成，建筑被认为是经入网初始化的。

数据捕获部件和基础设施

图2描绘了如在系统100A的数据平台模块180中被使用的用于数据捕获目的的信息流的系统（200A）。该系统提供围绕用于从在内部可访问的照明基础设施或其他外部源可靠地摄取/捕获数据的有限数量的机制的标准化。外部数据源的示例是来自诸如Twitter®和Facebook®的社交网络的数据、天气数据、安全数据和诸如会议室时间表的调度数据。系统200A本质上是使得数据流能够以既批量又实时或接近实时的方式将与下游消费连接在一起的内部管道。实时或接近实时的数据将使能实现低等待时间实时应用体验。如本文中描述的用于对物理环境的基于云的监测和控制的系统、方法和装置的上下文中的数据捕获关注提供机制或数据捕获服务220A-E以促进对来自多种多样的源的数据的可伸缩和可靠的摄取。这些机制是HTTP（S）微批量摄取（220A）、流数据摄取（220B）、大批数据摄取（220C）、社交连接器（220D）和web内容收集器（220E）。

库（例如，SDK）可以被客户机用于使能与HTTP（S）（220A）和流（220B）接口二者的简化交互。HTTP（S）微批量摄取（220A）的一个示例是可以提供例如面向基于HTTPS的数据以摄取到数据结构230中的标准互联网的应用编程接口（API）。它可以使用标准HTTP语义，并且通常被设计用于具有高的水平可伸缩性要求的小有效载荷。例如，HTTP（S）微批量摄取API220A可以被设计为容纳每秒数万的请求。该API通常可以被看作设备到服务器API。流数据摄取（220B）的一个示例是被设计用于通过持久或长期数据网络连接进行的数据捕获的服务或API。该类型的数据摄取通常是服务器到服务器的。大批数据摄取（220C）的一个示例通常是用于大型二进制对象摄取的符合SFTP标准的接口。大型二进制对象的示例包括大型zip文件和长视频剪辑。社交连接器（220D）的一个示例是被设计为允许诸如社交网络数据服务210C的服务访问数据结构230的API。它主要允许从诸如Twitter®和Facebook®的社交网络对数据的实时摄取。基于预定准则，允许使用220D API摄取特定类型的来自社交网络的感兴趣数据。该信息可以是例如人口统计或用户配置文件信息或位置信息。并且web内容收集器（220E）的一个示例是用于出于分析的目的从互联网网站提取内容的服务或API。例如，特定区域中的建筑中的典型能量使用可以被用于用作附近的正在被诸如系统100A的系统监测的建筑中的能量使用的基准。

设备和客户机200代表软件、固件和硬件代理。例如，可以直接地递送或经由充当网关或代理的商业应用/服务捕获数据。来自一些源的数据可以被路由通过诸如基于云的应用/服务210A（例如，服务器/应用日志）的云/服务器以摄取到系统200A中。然而，基于云的应用/服务210A的代理方法不排除服务自身消费数据和执行某个不可缺少的（integral）动作（例如，由于HTTP事务而更新数据库）。然而，在大多数这样的情况下，从客户机导出的底层消息特性也到达数据捕获系统200A以使能实现下游分析和/或消费。其他云/服务器示例包括FTP服务器（210B）、社交网络数据服务（210C）和互联网web服务（210D），该其他云/服务器可以将来自设备和客户机（200）的数据通过其路由。FTP服务器210B的示例包括任何使用FTP网络协议或其任何衍生或扩展（例如，FTPS、SSH、TFTP或SFTP）在客户机与服务器之间传输文件的服务器。社交网络数据服务210C的示例包括由如Twitter®或Facebook®的社交网络提供的数据服务。互联网web服务210D的示例包括由电子设备向经由万维网（WWW）通信的另一个电子设备提供的任何服务。互联网web服务210D可以使用HTTP协议用于传输诸如XML的机器可读文件格式。互联网web服务210D是提供去往一个或多个数据库服务器的用于向终端用户提供内容和/或用户接口的基于web的接口的任何web服务。

数据结构230是位于数据生产者与数据消费者之间的数据管道。它包括使数据生产者能够从数据消费者去耦合的数据经理人（broker）和可以对访问进行控制以及确保合适的数据集被递送给合适的数据消费者的路由部件。该路由部件包括支持多个并发的生产者和消费者的水平可伸缩、高度可用、高度耐久的持久队列。它提供用于入站（inbound）消息接受的API/接口以及用于内部消费的API/接口。数据结构230是数据驱动的，原因在于它可以配置新数据集，并且视情况使数据宿与新数据集相关联。相应地，通常应当不需要重新部署数据结构子系统以管理数据结构自身内的数据流的配置。路由部件还负责弄清楚是否发送每个消息和向何处发送每个消息（例如，向哪个数据宿）。实际上，它不仅路由而且复用（例如，它能够视情况向多个目的地发送相同的消息）。数据宿可以是标准的现成数据宿。例如，数据宿可以是被用于向S3存储装置写入（经校对的（collated））消息（集合）的数据宿。数据宿也可以是使得能够实现由下游应用处理对消息的接近实时消费的数据宿。作为一般原则，经由数据结构来路由全部数据（不考虑源）。对于小数据（KB），在数据结构消息内‘内联地（inline）’递送数据。对于较大数据集，将数据串接（serialize）到外部存储装置，并且经由数据结构消息提供“指针”。该方法可以被用于使得能够实现对较大数据集（例如，诸如音频、图像和视频的二进制内容）的接近实时的处理。

仅出于说明的目的，我们现在提供通过图2中描绘的系统200A的数据流的一个示例。占用传感器确定办公室已经变得不被占用，并且因此，灯具将光水平降低到预定水平。在办公室在其期间处于使用中的相邻时段中收集的能量使用度量被加时间戳并通过例如ZigBee®通信协议被发送给合适的无线网关（例如，图1的网关110A）。无线网关此后，在从建筑的相同楼层上的其他办公室捕获类似度量数据之后，经由HTTPS协议将该信息传送给建筑服务器（例如，图1的建筑服务器100）。建筑服务器使用HTTPS协议将度量数据传送给基于云的应用210A。基于云的应用服务210A可以被要求对向其发送数据的建筑服务器进行认证，并且此后，取决于被呈现给它自身的数据的类型，调用对或HTTPS微批量摄取220A API或流数据摄取API 220B的合适功能调用。此后，数据被数据结构230进一步处理和编目，并且被存储在诸如图1中描绘的数据库170B的云可访问的数据库中。

图3图示了被图1的数据平台模块180使用的主数据存储装置的一个实施例。概括地说，被摄取到数据平台模块180中的全部数据可以被持久化到数据平台的主存储装置—实际上是诸如Amazon Web服务（AWS）简单存储服务（S3）的云存储服务之上的策划（orchestrated）层。数据平台模块180的许多实施例对于可用性和耐久性可以依赖于这样的云存储服务。另外，平台引入构建以根据被摄取到平台中的数据的类型将数据隔离和组织到不同的云存储位置中的数据组织。

图3图示了来自各种源（例如，数据结构310A、数据访问服务310B和数据支持服务310C）的数据如何被主数据存储装置和作为数据平台模块160的组成部分的相关服务处置。数据结构310A是在图2的上下文中描述的任何类型的数据结构230。数据支持服务310B是控制对被存储在存储装置340中的数据的访问的基础设施。其主要目的在于提供访问控制或认证服务以确定是否调用对存储API 330的调用的一方具有必要的特权/许可（clearance）。存储API 330能够在数据结构310A调用其功能接口时，从数据结构310A接收数据的多样性。然后，它可以在数据被编制索引和存储在耐久、可伸缩的在线存储装置340中之前自己对数据执行各种动作，诸如在必要时对某些数据进行聚合或在必要时对数据匿名化。审计&日志记录模块320主要负责为对存储API 330的调用进行记录或日志记录。关于发起对API的调用的一方的细节以及数据访问服务310B对所述方进行认证的结果也被模块320记录。从耐久存储模块340读取和向耐久存储模块340写入也可以被日志记录模块320记录。

数据归档服务350代表包含和/或实现支配数据何时可以被归档（例如，被发送给长期高等待时间存储装置360）或删除的策略或规则、和用于对数据进行归档或（例如，从诸如存储装置360的长期存储装置）恢复的机制的软件或固件模块。换言之，数据归档服务350为被数据结构摄取并且然后被存储在耐久存储装置340中的数据实现预定的生命周期策略。耐久存储装置340通常被用于对来自多种多样的源的多种多样的数据（例如，来自家庭的Hue®数据）进行组织和存储而不混合数据。本质上，耐久存储装置340实现用于单独地维护数据自身以及与该数据相关联的元数据的方法。存在用于出于存储和分析目的分离数据进行的许多方式。例如，数据分层的顶层可以分离大规模办公园区项目数据与来自个人家庭的数据。可以通过基于客户身份或地理局部性（geo-locality）分离数据进行来实现数据分层的第二层。图3中的数据集1和数据集2代表为了易于由耐久存储装置340访问未混合和被单独维护的不同数据集。

设备入网初始化

图4图示了用于对用于对诸如图1的系统100A的物理环境的基于云的监测和控制的系统内的设备进行入网初始化的方法的实施例。在步骤410中，安装人员（诸如参照系统100A描述的安装人员）在诸如结合图1的系统100A描述的系统摄入应用模块130的基于云的入网初始化应用上的平面布置图上选择系统设备（例如，灯具）。安装人员此时位于例如将被系统100A监测的建筑内部。可以例如在被安装人员使用的诸如智能电话或平板电脑的移动设备上显示应用模块130的用户接口。在步骤420中，在安装人员的移动设备上运行的入网初始化应用将平面布置图上的所选系统设备的位置发送给基于云的入网初始化应用（例如，基于云的系统摄入应用模块130的后端）。在步骤430中，基于云的入网初始化应用（例如，在与项目分层相关联的项目170A数据库中，项目分层被链接到安装人员当前位于其中的建筑）保存平面布置图位置，并且指导与项目分层中的建筑相关联的建筑服务器（例如，系统100A的建筑服务器100）打开与建筑服务器相关联的正确网关的网络连接。在这样的情况下，建筑服务器能够基于所选系统设备在建筑物平面图上的物理位置来标识正确的网关（例如，系统100A的网关110A或110B）。在步骤440中，建筑服务器向合适的网关发送打开网络请求。在步骤450中，网关通过打开其网络（例如，ZigBee®网络）做出响应。跟随在对网关的网络的成功打开之后，在步骤460中，安装人员使用IR遥控设备将系统设备“添加”到网关的网络。安装人员可以通过将IR遥控器指向正在考虑的设备以及然后按下IR遥控设备上的“添加”按钮来做到这一点。此时，系统设备中的逻辑向网关的打开的网络广播系统设备（例如，灯具）希望被添加，并且网关既本地将来自系统设备的标识信息添加到其相关联系统设备的组，又将系统设备的标识信息发送给建筑服务器（步骤470）。在步骤480中，建筑服务器经由例如云连接性服务模块190和/或数据平台模块180（例如，经由MQTT或HTTPs协议）将系统设备的标识信息发送给云（例如，云115）。在步骤490中，诸如系统摄入应用模块130的基于云的应用将系统设备的标识信息与原来由安装人员在步骤410中指示的平面布置图上的位置耦合在一起，并且向在安装人员的移动设备上运行的相关联应用发送确认消息。该确认消息可以指示例如系统设备已经被成功入网初始化。

设备定位用例

如前所述，安装人员在诸如系统地图应用模块160的应用的帮助下可以定位建筑服务器100和网关110A和110B。该定位可以使用QR码完成。另一方面，如在下面的用例中描述的，诸如灯具和墙壁开关的其他系统设备可以通过使用IR技术或按下按钮来定位。

典型用例

图5A描绘了针对系统设备（例如，诸如吸顶式灯具的感应器设备）的定位用例。在图5A中描绘的步骤中，用户（例如，安装人员）在诸如系统地图应用模块160的基于云的应用模块的用户接口上轻击代表系统设备的图标（步骤510A）。作为响应，基于云的应用模块打开与系统设备相关联的无线网关（例如，网关110A）的无线网络（例如，ZigBee网络）（步骤520A）。然后，用户使用例如遥控设备向系统设备发送红外线（IR）触发（步骤530A）。系统设备然后向用户可视地指示接收到IR触发（例如，通过闪光预定次数）（步骤540A）。系统设备加入无线网络，并且向基于云的应用模块发送签署（SignOn）消息（步骤550A）。基于云的应用模块接收该签署消息，在对用户可见的用户接口上改变对图标的描绘以指示成功的定位（步骤560A）。基于云的应用模块还向系统设备发送对于可视地或通过其他方式指示成功的定位的请求（步骤570A）。例如，如果系统设备是灯具，它可以请求灯具将光输出调暗到10%。在接收到该请求时，系统设备服从指示成功的定位（步骤580A）。系统设备现在被认为是已定位的。在许多实施例中，在系统设备的成功定位之后，自动开始部署。在对系统设备的部署完成之后，其在基于云的应用模块上的相对应的图标将再次改变以指示它的“已部署”状态，以便向用户提供反馈。在一些实施例中，一旦系统设备已经被成功部署，将不存在向用户进行的对部署的进一步的可视确认。

在一些情况下，在定位完成之前的某处，并且在正在考虑的系统设备已经指示IR触发的接收之后，第二IR触发被系统设备接收。在这样的情况下，在许多实施例中，系统设备将向其相关联的无线网关发送第二签署消息。然而，在许多实施例中，基于云的应用模块将接收第二签署消息，识别签署消息来自已定位的还是定位未决的系统设备，并选择简单地忽略第二签署消息（例如，它被假设为是错误）。

来自不同位置处的感应器的第二签署

在图5B中描绘的用例中，系统设备已经被定位到（例如，用特定图标描绘在系统地图应用模块160上的）位置A，但用户仍然希望将它定位到另一个位置B（步骤510B）。用户可以通过在由应用模块160呈现的UI中轻击代表位置B的另一个图标来指示这一点。作为响应，基于云的应用模块打开相关联的无线网关（例如，网关110A）的无线网络（例如，ZigBee网络）（步骤520B）。用户然后用遥控设备向系统设备发送红外线触发（步骤530B），并且系统设备通过向用户可视地指示接收到IR触发（例如，通过闪光预定的次数）做出响应（步骤540B）。尽管系统设备可能在之前被定位到位置A时已经加入其相关联的无线网关的无线网络，系统设备仍然向基于云的应用模块发送签署消息，指示与其自身相对应的新位置（位置B）（步骤550B）。即使系统设备已经被映射到与位置A相对应的位置，基于云的应用模块也接收具有与位置B相对应的系统设备的位置信息的签署消息。在接收签署消息时，在各种实施例中，基于云的应用模块将提示用户系统设备之前已经被定位，并且询问他/她是否希望将系统设备重新定位（例如，移动）到新位置（例如，位置B）（步骤560B）。如果用户指示他/她事实上确实希望移动系统设备，则系统设备将被定位到位置B，并且一旦系统设备的任何之前开始的部署已经完成，则系统设备的新部署将开始（步骤570B）。在系统设备的部署完成时，基于云的应用模块上的与系统设备相关联的图标将改变以向用户指示系统设备的新部署状态。在许多实施例中，将不存在来自系统设备自身的用于指示其部署已经完成的可视确认。如果用户指示他/她不希望移动（重新定位）系统设备，不会发生系统设备定位的改变，并且它仍然被定位到位置A（步骤580B）。

在选择已定位图标（或什么都不选）时触发感应器

参照图5B中描绘的场景，我们可以考虑修改。考虑存在彼此接近的两个系统设备（感应器A和B）。例如，各自可以是吸顶式灯具。假设感应器B已被定位到基于云的应用模块（例如，系统地图应用模块160）上的位置B。还假设在该经修改的场景中，与感应器B的网关相关联的无线网络（例如，ZigBee®网络）是打开的。此时，用户使用遥控设备向尚未被定位的感应器A发送红外线（IR）触发。感应器A指示接收IR触发（例如，通过闪光3次）。感应器A也加入无线网络，并且发送签署消息，该签署消息被基于云的应用模块接收。此时，基于云的应用模块已经接收到来自感应器（感应器A）的签署消息，但没有感应器A将被定位到的相关联位置。在这样的情况下，在许多实施例中，基于云的应用模块可以进入“闪光流”序列。在这样的序列中，可以呈现未被定位的感应器的列表。当前场景中的第一个和仅有的感应器（感应器A）将接收到来自基于云的应用模块的“闪光”消息。作为响应，用户将需要在应用模块的UI上指示与闪光的感应器A相对应的图标（以及因此位置）。作为响应，应用模块将进行至将感应器A定位到所指示的位置。

在选择未定位图标（或什么都不选）时触发感应器

图5C描绘了其中在没有位置/图标在被用于定位的基于云的应用模块（例如，系统地图应用模块160）上被选择时触发多个系统设备（例如，感应器）的场景或用例。该用例也可以被用于在多个系统设备被使用应用模块上被选择的未被定位的图标/位置触发时确定事件的序列。

在步骤510C中，在未选择基于云的应用模块上的位置的情况下，用户（例如，安装人员）使用遥控设备向两个或多个系统设备（例如，感应器）发送IR触发。在步骤520C中，两个或多个系统设备可视地或通过其他方式指示它们已经接收到IR触发（例如，通过使它们的灯各自闪光3次）。两个或多个系统设备加入与它们的网关设备相关联的打开的无线网络，并且每个系统设备经由无线网络发送指示签署的消息（例如，签署消息）（步骤530C）。基于云的应用模块接收签署的两个或多个指示，并基于例如标识它们签署消息中的信息来在应用模块的UI上标识相对应的系统设备（步骤540C）。被标识的相对应的系统设备是被触发的物理系统设备的可视表示。在步骤550C中，两个或多个被触发的系统设备中的第一系统设备将可视地或通过其他方式向用户标识其自身（例如，通过继续闪光）。这可以是由于基于云的应用模块向被识别的相对应的系统设备中的第一系统设备发送对于开始闪光的请求造成的。作为响应，用户将在应用模块的UI上指示将使哪个位置/图标与闪光的（或通过其他方式吸引注意的）物理系统设备相关联（步骤560C）。在步骤570C中，基于云的应用模块将进行至将第一系统设备定位到用户选择的位置/图标。一旦成功定位，系统设备还将被部署。结合被触发的两个或多个系统设备，基于云的应用模块将以上面描绘的方式循环通过被基于云的应用模块标识为对应于被触发的两个或多个系统设备的系统设备中的每个系统设备，使得用户已经有机会定位被触发的系统设备中的每个系统设备。

触发其中的一个感应器已经被定位的多个感应器

在与图5C中被描绘并且在上面被描述的用例相似的一个用例中，考虑用户（例如，安装人员）已经在基于云的应用模块（例如，系统地图应用模块160）上选择了位置/图标（例如，图标A）。假设这时与一些系统设备（例如，感应器A和B）相关联的网关（例如，网关110A）的无线网络（例如，ZigBee®网络）是打开的。用户然后使用遥控设备向感应器A和B二者发送红外线（IR）触发。作为响应，感应器A和B可视地或通过其他方式指示接收到IR消息（例如，通过闪光3次）。它们随后加入打开的无线网络，并且各自向基于云的应用模块发送签署消息。应用模块接收两个签署消息，一个签署消息与感应器A的ID相关联，并且另一个签署消息与感应器B的ID相关联。但由于感应器A已经被定位到图标A，应用模块可以简单地不理会感应器A的签署消息。在该场景中，由于剩下仅另外一个感应器（感应器B），可以将感应器B立即定位到与图标A相关联的位置。在成功的定位之后，可以启动感应器B的部署。

定位期间的潜在问题

在一个进一步的场景中，假设用户（例如，安装人员）已经在基于云的应用模块（例如，系统地图应用模块160）的UI上轻击图标（图标A）。此后，与网关（例如，网关110A）相关联的无线网络被应用模块打开。用户从遥控设备向系统设备（感应器B）发送IR触发。感应器B通过例如闪光三次指示对IR消息的接收。此时，出于说明目的，我们讨论可能出现而干扰定位过程的两个潜在问题。我们还讨论用于解决这些问题的潜在方式。

问题1：系统设备被触发但不可以加入网关的无线网络

感应器B可以由于多种多样的原因而不能够加入无线网络。例如，它可以超出范围或以其他方式有缺陷。因此，感应器B不发送签署消息，并且不为用户提供对成功定位的任何可视或其他的指示。在没有对成功定位的指示的情况下，用户将很可能认识到在定位过程中出问题了。为进行故障排除，用户可以检查基于云的应用模块的UI以确定与感应器B相关联的网关或建筑服务器自身是否离线。备选地，用户可以尝试触发不同的尚未被定位的系统设备（例如，感应器A）以查看是否发现发生了相同的行为。用户还可以使用遥控设备向感应器B发送工厂重置命令，并且此后再次尝试对其进行触发。最后，用户可以替换感应器B。

问题2：系统设备加入网络但签署指示未到达云

感应器B加入打开的无线网络，并且然后尝试向基于云的应用模块发送签署指示（例如，签署消息）。然而，如果基于云的应用模块与网关之间的通信链路随后断开（例如，网关与建筑服务器（例如，建筑服务器100）、建筑服务器与云（例如，云115）或基于云的应用模块与云之间的通信链路中的一个或多个被中断），定位将不能够照常进行。但将在基于云的应用模块的UI上向用户可视地指示这些连接性的断开。由于来自感应器B的签署将不会到达基于云的应用模块，对感应器B的定位将不继续。但一旦中断的连接被恢复，用户可以再次尝试向感应器B发送第二IR触发。同样，与之前一样，感应器B将闪光预定的次数（例如，三次）以指示对IR消息的接收。然而，这次如果之前经历的连接问题被解决，基于云的应用模块将接收发送自感应器B的新签署消息，并且定位将以在前面部分中指示的方式继续。部署也将如之前指示的那样在成功定位之后发生。

修复感应器的之前的不正确定位

以下讨论涉及可以通过其纠正系统设备（例如，感应器A）之前的不正确定位的一些示范性方式。该讨论仅出于说明目的，并且不意在是限制性的。假设感应器A已经被定位到与图标A相关联的位置，该定位是不正确定位。对于用户（例如，安装人员）来说，存在至少两种修复不正确定位的方式。

在第一场景中，如果用户想作为代替将感应器A定位到图标B，并且他/她注意到感应器C已经在物理上展示对其已经被定位的可视指示（例如，它已经被调暗到10%），用户可以使用遥控设备向感应器C发送工厂重置命令。作为响应，感应器C将重置，离开它之前被指派到的网络，并且向与它相关联的网关发送指示相同内容的消息（例如，‘离开网络’消息）。事件的该序列将具有移除感应器C定位到图标A的效果。在基于云的应用模块（例如，系统地图应用模块160）中，图标A的外观将相应地改变以指示当前不与系统设备相关联。现在，用户可以进行至将感应器A定位到与图标B（或他/她选择的任何其他图标）相关联的位置。

在第二场景中，用户知道感应器A向图标A的定位未如预期的那样继续（例如，在定位过程期间出问题了）。用户可以使用基于云的应用模块启动重新定位过程。用户可以例如轻击图标A以将其与感应器A解除映射。这将移除感应器A向与图标A相关联的位置的定位。基于云的应用模块（例如，系统地图应用模块160）然后将启动移除错误定位的过程。例如，它可以向感应器A发送“工厂重置”信号，并且感应器A将作为响应重置并且离开它之前与之相关联的网关的无线网络。现在，用户可以将感应器A定位到与图标B（或他/她选择的任何其他图标）相关联的位置。

各种基于云的系统应用模块之间的示范性交互

图6图示了可以被用于对物理环境进行监测和控制的示范性的基于云的系统利用的各种基于云的系统应用模块的交互的实施例。之前已经在图1的上下文中讨论了这些基于云的应用中的一些应用。图6提供了附加的模块和关于如前所述的模块的进一步的细节（诸如它们与彼此的交互和它们的示范性使用）。图6中描绘的用户A、B、C和D是各自与不同的角色相关联的用户。基于用户的角色，可以授权他或她访问应用模块中的一个或多个应用模块。

用户A代表通常与自身托管和/或通过其他方式管理用于对物理环境进行监测和控制的示范性基于云的系统的操作的实体（例如，公司Z）相关联操作人员。在各种实施例中，用户A可以访问被基于云的系统维护和控制的全部项目数据（例如，项目分层）。它支持全部其他用户（具体地，用户D）维护在对被基于云的系统监测的各种站点进行监测和控制时终端用户的日常操作。用户B代表摄入工程师，其在该上下文内的主要功能可以是在项目分层内创建一个或多个建筑的数字模型。用户C是诸如安装人员或入网初始化工程师的人，他的主要任务可以是基于创建的建筑的数字模型在物理上和逻辑上在建筑内安装设备，以及此后参与入网初始化、配置和部署过程。用户D是来自作为示范性基于云的终端用户的实体/客户（例如，公司X）的诸如设施管理、财务或可持续性的部门的人员。

之前在图1的上下文中讨论的用户管理应用模块150是在各种实施例中允许系统管理员或被类似地授以凭证的某个人为用于对物理环境进行监测和控制的基于云的系统创建新用户帐户的基于云的软件模块。例如，系统管理员可以创建新用户（例如，用户L），并且为那个用户指派诸如用户名和临时密码的用户凭证使得用户L此后可以使用系统登录应用模块610获得对图6中描绘的基于云的系统应用模块中的一个或多个模块的访问。

在各种实施例中，系统用户应用模块630被用于将用户指派给一个或多个项目分层、站点或建筑。在当前基于云的监测和控制系统的各种实施例中，项目分层是分层的根（root）。每个项目分层可以包含一个或多个站点，每个站点可以包含一个或多个建筑，每个建筑可以包含一个或多个楼层。如果用户（例如，用户L）被指派给项目分层PH，则该用户将基于他或她的角色可以访问项目分层PH的各种特征。还可以用定制的方式限制用户的访问权限。例如，如果用户L被指派给站点1，他/她可以被允许对仅与站点1而非站点1所属的项目分层内的其他站点相关联的建筑的访问。

之前在图1的上下文中讨论的系统项目应用模块140是控制对全部其他系统应用模块的访问的中央系统应用模块。在用户登录到基于云的监测和控制系统中时，用户遇到的应用模块是系统项目应用模块140。用户将仅能够查看和/或操纵他或她已经被指派到的项目分层、站点或建筑。在各种实施例中，用户向各种项目分层、站点和/或建筑的指派与他或她的登录凭证（例如，用户ID）相关联，而他/她访问诸如系统地图应用模块160或系统摄入应用模块130的一个或多个系统应用模块的能力是与他/她被指派的角色（例如，安装人员或摄入工程师）相关联的。一旦用户已经访问系统项目应用模块140，并且被呈现了例如他/她已经被指派到的一个项目分层（例如，MegaCorp），他可以经由在图形用户接口上向他呈现的用户接口元素选择项目分层。然后可以为他呈现与项目分层MegaCorp相关联的各种站点（例如，伦敦和上海）。在伦敦站点上点击将例如为用户呈现与伦敦站点相关联的各种建筑（例如，建筑1和2）的图形化表示（例如，图标）。在许多实施例中，向用户呈现的系统项目应用模块140的图形用户接口将为用户提供用于访问用户基于用户的角色和/或登录凭证可以访问的其他系统应用模块（例如，系统操作应用模块620或系统能量应用模块120）的一种或多种方式。

之前在图1的上下文中讨论了系统摄入应用模块130。在许多实施例中，它允许诸如已被指派了操作人员或摄入工程师的角色的用户的被恰当地授以凭证的用户在站点和项目分层内创建建筑的数字模型。在这样的实施例中，这还意指用户必须还具有用于通过系统项目应用模块140访问建筑的凭证。假设必要的凭证存在，则将为用户（例如，用户L）呈现允许他/她添加用于图形化地和在逻辑上代表所选建筑的各种物理楼层的平面布置图的用户接口。一旦选择了特定建筑的楼层的平面布置图，用户可以然后进行至在平面布置图内图形化地细分各种区域以描绘各种类型的空间（例如，单间办公室、开放式办公室、会议室或走廊）。用户正在图形化地创建楼层的虚拟布局。在各种实施例中，还为用户呈现合适的用户接口元素和功能性（例如，拖放、剪切-和-粘贴、代表诸如灯具和无线网关的单个设备的图标），使得用户可以在平面布置图上的许多房间或区域内的特定位置处图形化地描绘诸如网关、灯具、灯具的网格、开关、光和占用传感器的系统设备。在各种方面中，指导诸如灯具的设备在空间内的行为（例如，特定走廊中的灯具如何对占用的改变做出响应）的配置数据在该阶段也是与不同区域（例如，办公室、走廊、开放空间）相关联的。系统摄入应用模块130还可以被用于关联附加的配置数据以进一步控制诸如灯具和传感器的单个设备的行为（例如，光输出）。在各种实施例中，应用模块130仅对那些具有被指派了操作人员或摄入工程师的角色的用户可访问。

根据许多实施例，之前在图1的上下文中讨论的系统地图应用模块160通常被诸如安装人员的用户在位于作为与基于云的监测和控制系统相关联的项目分层的部分的建筑的现场时使用。在许多实施例中，安装人员进入建筑，并且在物理上在使用例如系统摄入应用模块130创建的建筑的数字模型的图形化描绘上指示的位置处安装设备。系统地图应用模块160此后辅助之前在图4和5的上下文中以及也在图10、11和12的上下文中描述的入网初始化、定位和部署过程。在各种实施例中，使用应用模块160，安装人员标识提供系统设备中的全部系统设备的可视化的合适数字平面布置图是平面布置图上的区域。入网初始化过程以与眼前的建筑相关联的建筑服务器（例如，建筑服务器100）开始，并且然后继续去往各种无线网关和相关联的诸如灯具和开关的系统设备。如之前指示的，使用诸如智能电话或平板电脑的移动计算设备，安装人员选择他/她希望入网初始化和定位的特定物理设备（通过在应用模块160的用户接口上选择它）。安装人员然后进行至使用智能电话或平板电脑上的摄像头拍摄设备上的QR（快速响应®）码的图片，并且这启动结合各种其他附图和贯穿本说明书被详细讨论的入网初始化、定位和部署过程。QR码仅被单纯地用作一个示例，并且也可以使用任何其他码。在各种实施例中，系统地图应用模块160仅是对那些具有操作人员或安装人员的角色的用户可访问的。

在许多实施例中，系统能量应用模块120可以被终端用户访问，终端用户通常是与托管和/或通过其他方式管理基于云的监测和控制系统的操作的实体（例如，公司Z）相关联的操作人员，或与关联于其建筑正在被基于云的监测系统监测的特定项目分层的终端用户实体相关联的设施管理人员。相应地，在各种实施例中，仅具有合适角色（例如，操作人员或设施经理）并且具有合适的访问凭证的用户被允许访问应用模块120。在这样的和其他的实施例中，来自全部被监控的系统设备和区域的空间和资源利用数据经由它们的各个网关和建筑服务器被传输到与基于云的监测系统相关联的云（例如，图1中描绘的云115），在该云处对数据进行分析。可以采用统计分析和机器学习技术导出有用的分析，然后将该分析以显示过去的使用、对未来的能耗的预测和当前的（实时的）能量利用的图表和其他可视化模式的形式呈现给终端用户。结合占用数据所分析的能耗数据可以揭示被欠佳地使用的物理区域和资源，并且因此可以贡献于用于降低未来的能量使用的策略。

在许多实施例中，系统操作应用模块620通常是仅对与托管和/或通过其他方式管理基于云的监测系统的操作的实体（例如，公司Z）相关联的操作人员（例如，图6中描绘的用户A）可访问的。它提供用于远程地故障排除、诊断和解决运行时间问题（诸如不合适的光水平、能量和占用数据收集或分析中的错误或不准确的入网初始化、定位或部署）的后端逻辑和用户接口。

部署

图7A-C图示了对图1中描绘的用于对物理环境进行监测和控制的基于云的系统进行的部署的实施例。图7A中图示的云模块是与在图1的上下文中描述的云115类似的。系统项目应用模块140、系统摄入应用模块130、系统地图应用模块160、系统操作应用模块620、系统能量应用模块120、云连接性服务模块190、数据平台模块180和项目170A是与图1和6中描绘的被同样地命名的模块类似的。项目服务模块708使诸如系统摄入应用模块130和系统地图应用模块160的各种系统应用模块能够支持诸如Dynet®和ZigBee®的多种通信协议。其本质上允许系统应用模块以协议无关的方式执行它们的功能。其还促进项目170A数据库与系统应用模块之间的数据通信。

远景部署引擎模块711参与用于诸如感应器设备的系统设备的配置文件的生成。这些配置文件是适用于各个感应器或感应器的组的，并且被用于响应于诸如环境照明的改变、占用、一天中的时间等事件控制它们的行为。远景插件模块709是允许远景部署引擎模块711以无缝方式与项目服务模块708通信的插件模块。换言之，由于插件可以与远景部署引擎模块711和项目服务模块708二者通信，所以可以在没有对远景部署引擎模块711的实施方式或架构的任何依赖的情况下实现项目服务模块708。远景数据分析模块714对通过建筑服务器和网关从感应器设备搜集的能量和资源使用信息执行必要的分析，并且使经分析的数据可用于呈现给系统能量应用模块120。

对注册、用户认证和设备授权的概述

图7A中描绘的设备701是数据库模块，该数据库模块被配置为，保存与关联于每个项目分层的全部各种建筑服务器（例如，建筑服务器100）、网关（例如，网关110A）和系统设备（例如，系统设备101）相关的信息。例如，在特定的建筑服务器能够被用于针对特定的项目或站点的资源和能量管理目的之前，其将需要将其自身注册到云（例如，云115）。在伴随图8A-B的描述中进一步详细描述了该注册过程。与图1的基于云的系统的被注册用户相关联的信息（例如，用户名称、密码、角色）被安全地存储在图7A中描绘的用户702数据库模块中。在各种实施例中，在用户希望访问例如基于云的系统应用模块中的一个或多个（例如，系统地图应用模块160）时，该信息在认证过程期间被身份管理模块705访问。标准的认证技术可以被身份管理模块705使用。在各种实施例中，Forgerock 开放式AM/DJ模块706负责确保关于寻求对云的访问以在用于对物理环境进行监测和控制的示范性系统中执行它们的部分的各种设备（例如，建筑服务器和无线网关）的身份的合适的授权。在这样的实施例中，策略代理模块707有助于向用户授予对访问各种所描绘的系统应用模块的授权。例如，甚至在用户已经被正确地认证并且已经获得对初始的系统项目应用模块140的访问之后，基于用户已经被分配的角色限制对诸如系统摄入应用模块130和系统地图应用模块130的其他系统应用模块的进一步访问。已经在与图6相关联的描述中进一步详细描述了角色。在许多实施例中，与各种角色相关联的访问策略是经由URL来配置/实现的。例如，假设可以各自利用不同的URL访问系统项目应用模块140的各种方面。尽管已经被分配了管理员角色的用户可以被授予用于访问全部这些不同的URL的能力（每个URL允许用户访问由系统项目应用模块140提供的多种多样的功能），但已经被分配了安装人员角色的用户可以仅被授予对这些URL中的两个的访问。策略代理模块707强制施行关于每个角色能够访问的功能的预设和可配置的策略。

固件/软件图像和更新

图7A的FW图像700数据库模块存储用于更新建筑服务器、网关和系统设备固件和/或软件的图像。FW/SW更新过程以从云的SW更新模块703经由MQTT协议去往建筑服务器的触发开始。在各种实施例中，触发可以包含用于检索必要的更新图像的URL。在建筑服务器固件更新的情况下，云中的SW更新模块703将经由MQTT发送触发，建筑服务器中的FW更新BS模块721将识别触发，并且建筑服务器然后将使用触发中的URL检索更新图像，并且使用MQTT信道向云报告其已经完成下载更新图像。在这些实施例中，云中的SW更新模块703此后将经由MQTT发送明确的触发，并且在接收触发时，建筑服务器将执行为了切换到新的经更新的图像所需的任务（例如，重新启动和切换到新图像的应用）。用于执行对无线网关的固件更新的过程是与上面描述的用于建筑服务器的固件更新类似的。然而，用于无线网关的更新过程使用建筑服务器作为代理。例如，经由在当前的图中的建筑服务器模块中描绘的HTTP代理模块718对由无线网关经由URL对FW图像做出的检索进行代理。

图7A中描绘的建筑服务器是与在图1的上下文中描述的建筑服务器100类似的。建筑服务器的这个实施例描绘了在促进软件更新、设备注册和数据收集中发挥作用的各种模块。HTTP代理模块718和MQTT代理模块720在一个或多个无线网关与云之间对分别使用HTTP和MQTT协议的通信进行代理。例如，由建筑服务器的MQTT代理模块720对产生自与图7A的建筑服务器相关联的无线网关中的MQTT客户机的通信进行路由。在许多实施例中，被监测的物理环境内的仅一个设备（例如，建筑服务器）将具有对被用于对环境进行监测的云的直接访问。来自各种无线网关和系统设备的全部数据将通过建筑服务器进行代理。在这样的实施例中，无线网关和系统设备是云无关的。换言之，它们不需要具有用于直接与云连接的数据或逻辑。设备注册模块716策划建筑服务器向云的注册。在伴随图8A-B的描述中更详细地描述了该过程。在发现网络中的设备的过程中涉及现场网络发现模块717。网络提供商模块719从云中的远景插件模块709接收配置数据，并且负责将该数据转发给系统设备（例如，感应器设备）。另外，网络提供商模块719促进云与无线网关之间的双向通信。例如，其可以经由远景插件模块709将产生于感应器、无线网关和建筑服务器的签署消息发送给云。类似地，网络提供商模块719还可以将来自云的命令（例如，打开ZigBee网络命令）传播到无线网关。

故障切换模块726和恢复模块728一起负责检测建筑服务器的操作中的错误和从这样的错误中恢复过来。在一些实施例中，通过定时器持续地监测一个或多个关键软件进程的操作。在进程由于错误状况而停止的情况下，定时器也停止。定时器停止是导致一个或多个进程或建筑服务器自身重启以便从错误状况中恢复过来的触发。BS诊断模块727搜集关于建筑服务器的例行操作的信息。例如，在许多实施例中，收集可以有助于诊断操作错误的错误消息。将这些消息定期地发送给云以便由诸如系统能量应用模块120的系统应用模块进行分析和可视化。在基于诸如占用或日光的改变的事件的覆盖物理环境（例如，建筑）中的惯常行为的调度任务中涉及建筑服务器中的调度模块729。在一些实施例中，在建筑服务器中执行调度模块729，而在其他实施例中，在云中执行调度模块729。

图7B和7C中描绘的网关（例如，无线网关）是与之前在图1的上下文中描述的网关110A和110B类似的。图7B和7C描绘了无线网关的各种模块。就贯穿本说明书所描述多数模块而言，这些模块可以用固件或完全用软件来实现。如果完全用软件来实现，则可以在物理上位于无线网关自身处的一个或多个处理器上或在被远程地放置但对无线网关可访问的一个或多个处理器上执行它们。无线网关的NTP客户机模块735是与建筑服务器中的被类似地命名的模块类似的，因为其参与向诸如感应器的系统设备推送时间数据。无线网关的ZigBee时钟同步服务器模块736也参与该时间同步相关的过程，并且在接下来的关于时间同步的部分中详细描述了其参与以及无线网关的NTP客户机模块735。在从系统设备（例如，感应器）对能量和其他度量进行的收集和通过建筑服务器向上向云推送该信息中涉及无线网关的数据收集模块733。在随后的关于度量报告的部分中描述了关于该功能的细节。在各种实施例中，WG诊断模块734主要负责报告在无线网关的例行操作期间遇到的错误或异常状况或状态。此后，经由建筑服务器将这些错误状况或状态向上报告给云以便进行进一步分析和呈现。像建筑服务器上的被类似地命名的模块一样，无线网关的FW更新模块732主要负责协调其自身和感应器设备的固件和软件更新。在图9的上下文中进一步详细描述了该过程。无线网关的发现注册模块730起到将其自身注册到建筑服务器和/或云的作用。MQTT客户机模块731起到经由建筑服务器的MQTT代理模块720将产生自无线网关和与无线网关通信的任何设备的基于MQTT协议的通信路由到建筑服务器的作用。

图7C中描绘的感应器是与在图1的上下文中描述的设备101-106类似的。在各种实施例中，感应器诊断模块737将与感应器的惯常操作相关联的错误状态和状况报告给度量报告模块，在随后的关于时间同步的部分中描述了度量报告模块。也在随后的关于时间同步的部分中描述了ZigBee时钟同步客户机模块743和ZigBee时钟同步服务器模块744。在这样的和其他的实施例中，FW更新模块742参与更新感应器的固件和/或软件的过程，并且在伴随图9的描述中详细讨论了该过程。传感器740对例如红外线信号、运动或光强的改变进行感应。致动器738致动诸如灯具的设备改变例如强度或与光照相关联的其他特性。其还可以致动在建筑中找到的多种多样的其他设备（诸如HVAC设备、百叶窗、窗帘、投影仪、显示器等）。根据许多实施例，远景控制模块739起到应用经由建筑服务器和网关从云中的远景部署引擎模块711和远景插件模块709被向下传递给感应器的配置数据（例如，配置文件）的作用。在这样的实施例中，配置文件详述特定的感应器或感应器的组对诸如占用、温度或移动的改变的各种光照和环境状况的响应。

时间同步

在许多实施例中，被描绘为图7A中的建筑服务器的部分的NTP客户机模块723被用于时间同步目的。其结合诸如互联网的网络上的NTP服务器模块715、也是图7A中描绘的建筑服务器的部分的NTP服务器模块725和被描绘为图7B中的无线网关WG的部分的NTP客户机模块735和ZigBee时钟同步服务器模块736起作用。NTP一般指已知的网络时间协议，网络时间协议是通常被用于计算机系统之间的时钟同步的网络协议。NTP通常起到将计算设备同步到协调世界时的几毫秒内的作用。尽管NTP可以在客户机-服务器模型下操作，但其也可以在对等解决方案中被使用，在对等解决方案中，多个设备可以被看作潜在时间源。

在许多实施例中，为了准确地为从感应器收集的能量和资源使用数据加时间戳，有必要定期地对全部感应器、无线网关和建筑服务器进行同步。首先从被描绘为位于云或建筑服务器之外的NTP服务器模块715检索当前时间数据。一般说来，这样的NTP服务器位于互联网上。在各种实施例中，建筑服务器的NTP客户机模块723接收当前时间数据。接下来，该当前时间数据在其被传送给图7B中描绘的无线网关的NTP客户机模块735之前被建筑服务器中的NTP服务器模块725接收。在无线网关内，该当前时间数据转而被传送给ZigBee时钟同步服务器模块736。此后，启动用于识别最接近无线网关的那些感应器设备的级别发现阶段。在许多实施例中，这是通过无线网关以特定的级别（例如，与其自身相关联的级别0）经由ZigBee发送广播命令来完成的。在最接近无线网关的感应器设备接收广播命令时，它们将它们自己的级别提高到1，并且然后以级别1重新广播相同或相似的消息。接收被重新广播的消息的感应器设备此后将把它们自身识别为具有级别2，并且再次重新广播消息。该过程继续，直到全部相邻的感应器设备已经被识别并且是与一级别相关联的为止。跟随在级别发现阶段之后的第二阶段是同步阶段，同步阶段涉及使用已知的成对时间同步算法。作为同步过程的部分，处在第一级别处的多个感应器中的一个感应器的ZigBee时钟同步客户机模块743从无线网关的ZigBee时钟同步服务器模块736接收当前时间数据。然后由感应器自身对等地传递该信息。如在图7C中用箭头线指示的，这可以是由特定的感应器的ZigBee时钟同步服务器模块744经由ZigBee网络传送该信息以便被相邻的感应器中的ZigBee时钟同步客户机模块743接收造成的。

度量报告

在各种实施例中，感应器将定期地对能量和/或占用数据进行报告（例如，可以每十五分钟对能量数据进行报告，以及每五十分钟对占用数据进行报告）。在图7C中被示为每个感应器的部分的度量报告模块741从ZigBee时钟同步客户机模块743接收时间数据，该时间数据然后作为时间戳被添加到被报告的能量或资源使用数据。感应器诊断模块737还为度量报告模块741提供关于感应器自身的操作的诊断数据。该诊断数据可以是指示伴随感应器的例行操作的潜在或已知问题（诸如不能够以惯常的方式进行感应或致动）的错误消息。在许多实施例中，通过以下方式从每个感应器发送度量数据。首先，存在一些不同的被使用的分组类型：一种分组类型用于发送地址信息，另一种分组类型用于随着第一度量发送完整时间戳，以及又另一种分组类型用于随着进一步的度量发送时间偏移量。在一个典型的实施例中，在感应器的度量报告模块741报告例如与能量使用相关的度量时，其首先发送具有为了识别度量来自于的感应器设备所需要的地址信息的第一消息。此后，随着与能量使用相关的第一度量发送完整时间戳。最后，随同指示自从发送第一度量起已经过去的时间的量的时间偏移量数据一起发送与能量使用相关的第二度量。度量数据被无线网关的数据收集模块733接收。

在一些实施例中，感应器自己不在报告度量数据时提供任何向无线网关唯一地标识其自身的地址信息。在这样的实施例中，（在图7B和7C中被描绘的）无线网关中的数据收集模块733将感应器的全局唯一的地址附加或以其他方式关联到其报告的度量。无线网关中的数据收集模块733也可以添加其自己的地址信息。在各种实施例中，无线网关的地址信息和与特定的感应器或感应器的组相关联的地址的该组合造成与被报告的特定的度量或度量的集合相关联的地址的全局唯一的本质。无线网关中的地址收集模块733通常使用ZigBee协议从感应器接收信息，而通常使用HTTPS向建筑服务器提供信息。

定期地，无线网关的数据收集模块733向建筑服务器中的数据收集模块724发送数据。在各种实施例中，无线网关定期地推送该信息。在其他实施例中，建筑服务器从无线网关拉取该信息。在接收度量数据之后，建筑服务器的数据收集模块724将其自己的地址添加到地址信息。该地址信息可以被添加到每个接收自无线网关的度量或在将整批度量发送给云之前被集体地被添加到整批度量。在许多实施例中，建筑服务器在将度量批量发送给云的数据平台模块180之前收集一个短的时段（例如，5秒）内的全部被接收的度量。在这样的实施例中，如果在一个时段内缺少与云的连接性，则将在最大持续时间的时间（例如，24小时）内缓冲接收自与建筑服务器相关联的全部无线网关的度量数据。在与云的连接性被重新建立时，建筑服务器将把被缓冲的度量数据推送给云。在许多实施例中，这样的缓冲在无线网关处也是可用的以防止如果无线网关与建筑服务器之间的连接性被中断时的数据丢失。

建筑服务器注册和连接

图8A和8B图示了将建筑服务器注册和连接到用于对物理环境进行监测和控制的基于云的系统的云（例如，图1的云115）的方法的实施例。位于这两个图顶部的块代表设施内的建筑服务器（例如，图1的建筑服务器100）和例如与图1的云115相关联的各种基于云的模块。设备注册模块704、身份管理模块705、数据平台模块180全部是之前在图7A的上下文中描述的被同样地命名的基于云的模块的实施例。

如在图8A中描绘的，建筑服务器100检索跨建筑服务器的全部厂商唯一地标识建筑服务器的被存储在本地的MAC地址（检索建筑服务器ID()）。此后，建筑服务器100通过例如API调用启动例如设备到服务通信（注册()）。在许多实施例中，云（例如，云115）中的设备注册模块704本质上暴露建筑服务器100调用其以便启动注册过程的API。在各种实施例中，为将其自身注册到云，建筑服务器100传送其检索的建筑服务器ID（例如，64位MAC地址）、指示其是建筑服务器的设备类型和带密钥的散列消息认证码（HMAC）。HMAC是结合密钥使用散列函数的一种已知的密码消息认证码。其被用于验证消息认证和数据完整性二者。可以使用任何已知的密码散列函数（诸如MD5或SHA-1）计算HMAC。在各种实施例中，设备注册模块704可以访问存储用于每个建筑服务器的秘密加密密钥的数据库。每个建筑服务器转而可以访问其自己的加密密钥副本，但不可以访问任何其他建筑服务器的秘密加密密钥。云上的设备注册模块704此后验证所接收的建筑服务器ID和HMAC是与彼此相关联的（验证BSID和HMAC()）。在这样做时，设备注册模块704对建筑服务器100进行认证。如果，在该过程期间，设备注册模块704从建筑服务器接收其不能够验证/认证的多个注册尝试，则其可以临时阻塞来自建筑服务器的这样的尝试。

接下来，设备注册模块704创建密码（创建密码()），密码结合建筑服务器ID将在与各种基于云的模块交互时充当建筑服务器的操作ID。在许多实施例中，设备注册模块704然后调用身份管理模块705以让其创建在用于对室内空间和资源使用进行监测的基于云的系统内代表建筑服务器100的新身份（创建身份()）。建筑服务器ID和密码被用于制定新身份。一旦建筑服务器100的新身份已经被成功地创建，则身份管理模块705进行至将建筑服务器100添加到被云识别的建筑服务器的组（添加到组()）。这可以通过简单地在数据库中创建建筑服务器ID和建筑服务器的新造的身份与已定义的组之间的关联来完成。在云的一些实施例中，每个被注册到云的建筑服务器属于一个可以被称为建筑服务组的组。属于该组是一种将设备标识为一种特殊类型的设备（即，建筑服务器）的方式。跟随在向组中进行的成功添加之后，身份管理模块705向设备注册模块704通知成功的完成（通过从身份管理模块705到设备注册模块704的虚线箭头来描绘）。

此后，设备注册模块704为建筑服务器100创建将使用以便充当安全服务器的密码证书。存在各种用于使这样的密码证书被创建的方式。通常，证书是被签名和使用证书权威的私钥被加密的公钥。证书的用户（例如，建筑服务器100）可以将公钥作为其真实性的证据呈现给其他实体——因此防止实体假冒彼此。在各种实施例中，设备注册模块704然后将其之前为建筑服务器100生成的密码、已创建的证书、经加密的私钥和关于建筑服务器100可以使用其来与云通信的资源（例如，MQTT端点或URL）的信息发送给建筑服务器100（通过从设备注册模块704到建筑服务器100的虚线箭头来描绘）。

在从设备注册模块704接收上面识别的这些条信息时，建筑服务器100使用例如它已经与设备注册模块704共享的其秘密密钥对经加密的私钥进行解密（提取安装私钥证书（））。为了建筑自身内的（例如，建筑服务器100与各种无线网关之间的）安全通信，可以使用共享秘密来确保这些设备之间的安全连接。建筑服务器100生成用于在建筑内使用的像共享秘密的站点密钥（生成安装站点密钥（））。

接下来，建筑服务器100尝试通过例如提供其从设备注册模块704接收的其建筑服务器ID和密码使其自身被身份管理模块705认证（认证（BSID, 密码））。如果认证是成功的，身份管理模块705返回建筑服务器100可以使用以随后访问云中的服务的访问令牌（通过被标记了‘访问令牌’的虚线箭头来描绘）。

在许多实施例中，为了访问与云相关联的数据平台模块180，要求建筑服务器100具有访问凭证的第二集合。这实质上将与获得对全部其他云模块的访问相关的安全性与关联于对云的数据平台自身的访问的安全性相分离。以下讨论应对将导致对凭证的该附加集合进行授权的建筑服务器100的注册过程的部分。为了启动该过程，建筑服务器调用例如API调用（激活数据平台（BSID, 密码）），并且提供其建筑服务器ID以及其密码。该通信可以通过HTTPS发生。在接收该通信时，设备注册模块704调用身份管理模块705以验证所提供的凭证（验证凭证（BSID, 密码））。一旦被验证（被标记了OK的从身份管理模块705到设备注册模块704的虚线箭头），则设备注册模块704进行至为建筑服务器100生成将用于其与数据平台模块180的通信的另一个密码（创建密码（））。在许多实施例中，设备注册模块704然后为数据平台模块180提供以下信息：建筑服务器ID、用于数据平台访问的新密码和关于建筑服务器100所属的特定组的信息（提出设备组（））。在许多实施例中，该通信可以经由HTTPS完成。使用该信息，数据平台模块180创建用于在于其未来与建筑服务器的交互中标识建筑服务器100时使用的唯一身份（创建DP身份（））。在成功地创建该新身份时，数据平台模块180向设备注册模块704通知相同的内容（被标记了DP身份的从数据平台模块180到设备注册模块704的虚线箭头）。设备注册模块704进而将这个对成功的通知随同建筑服务器的新生成的数据平台凭证一起继续传递给建筑服务器100（被标记了DP身份的从设备注册模块704到建筑服务器100的虚线箭头）。

此后，建筑服务器100尝试用数据平台模块180使其自身被直接认证，这是通过调用例如数据平台模块180处的用于该目的的API来完成的。它为数据平台模块提供其建筑服务器ID和由数据平台模块180创建的密码。进而，数据平台模块180验证由建筑服务器100提供的凭证（验证凭证（）），并返回用于被建筑服务器100在未来与数据平台模块180的通信中使用的访问令牌（被标记了数据平台令牌的从数据平台模块180到建筑服务器100的虚线箭头）。

如图8B中描绘的，在注册之后，建筑服务器100通过例如使用云连接性服务模块190提供的API调用云连接性服务模块190的方法和提供其建筑服务器ID和由设备注册模块704为建筑服务器100初始创建的密码第一次与云连接（连接（BSID, 密码））。作为响应，云连接性服务模块190调用认证方法，由此要求身份管理模块705认证建筑服务器的凭证。由建筑服务器100提供的建筑服务器ID和密码被用于该目的（认证（BSID, 密码））。在许多实施例中，认证过程可以由云连接性服务模块190在身份管理模块705处使用HTTPS协议启动。在成功认证时，身份管理模块705向云连接性服务模块190返回指示建筑服务器100已经被成功地认证的令牌（通过被标记了‘令牌’的虚线箭头来描绘）。使用接收的令牌，云连接性服务模块190然后请求身份管理模块705检索建筑服务器100之前被指派到的组（检索组（令牌））。作为响应，身份管理模块705返回对建筑服务器100被指派到的组（例如，包含对与特定云相关联的全部已注册建筑服务器的参考的组）的参考。

在各种实施例中，以上信息交换中的全部信息交换可以使用HTTPS协议来执行。使用对被指派给建筑服务器100的组的参考，云连接性服务模块190可以对建筑服务器100的授权进行验证（验证授权（））。要做到这一点，在各种实施例中，云连接性服务模块190检查以查明建筑服务器100属于正确的授权组。像建筑服务器和网关的系统设备通常与设备组相关联。因此，在任何设备使用MQTT与云连接性服务模块190连接时，云连接性服务模块190检查以查明设备是否实际上是设备组的部分。在许多实施例中，仅设备或服务（例如，远景协议插件）而没有用户被允许经由MQTT与云连接。一旦建筑服务器100的授权状态已经被成功验证，云连接性服务模块190（使用例如MQTT）向建筑服务器100发回指示其被成功地连接的通知（通过被标记了‘已连接’的从云连接性服务模块190到建筑服务器100的虚线箭头来描绘）。建筑服务器100此后可以经由云连接性服务模块190使用例如MQTT的“发布”机制发布“签署”消息。该“签署”消息被发布到与特定建筑服务器相关联的特定话题。在MQTT中，不同的话题与不同的信道或功能性相关联。各种设备可以订阅各种信道以接收在那些信道上发布的消息。相应地，订阅特定话题的全部设备将接收对建筑服务器100的“签署”消息的通知。然而，在确认建筑服务器100希望发布其“签署”消息之前，云连接性服务模块190像其之前已经在建筑服务器100的连接调用之后执行的那样再一次执行授权验证（验证授权（））。在成功授权验证之后，向建筑服务器100返回确认（通过被标记了‘ACK’的从云连接性服务模块190到建筑服务器100的虚线箭头来描绘）。此后，云连接性服务模块190将建筑服务器100的签署消息（建筑服务器签署（））推送到建筑服务器100希望向之发布其签署消息的话题的全部订阅者。作为订阅者，远景插件模块709接收签署消息并且对接收进行确认（通过被标记了‘ACK’的从远景插件模块709到云连接性服务模块190的虚线箭头来描绘）。在接收到建筑服务器100的签署时，远景插件模块709立即将相同的内容报告给项目服务模块708，使得其知道新设备签署，并且可以采取任何必要的动作（回调发现设备（））。

更新系统设备的软件或固件

图9图示了更新诸如感应器设备（例如，图1的设备101）的系统设备的软件或固件的方法的实施例。图9中示出的箭头可以代表功能调用、命令或任何其他用于调用来自在相同或不同但可访问的处理器上执行这件软件或固件的动作或响应的机制。在下面的描述中，HTTPS有时作为例如建筑服务器与网关或建筑服务器与云之间的通信协议被提到。然而，HTTPS是可以在任意实施例中被使用的许多协议中的一种协议。例如，MQTT可以也适用于这些通信。在该图顶部图示的模块中的三个模块（具体地说，SW更新模块703、项目服务模块708和SW图像700）是驻留在诸如图1的云115或图7A的云的云中的软件模块。这里描绘的项目服务模块708是与图7A中描绘的项目服务模块708类似的。在该图顶部图示的剩余三个模块或设备（即，FW更新BS模块721、网关110A和系统设备101）代表位于诸如建筑的物理结构内的物理设备或在与物理设备相关联的处理器上执行的模块。SW更新模块703首先执行项目服务模块708上的“打开”命令或功能调用。在各种实施例中，SW更新模块703希望打开特定的预先存在的项目分层。之前已经在图5A-C和图6的上下文中讨论了项目分层。作为响应，特定项目的逻辑模型被返回，SW更新模块703使用其获得对与特定楼层相关联的数据（选择(楼层)）和与特定楼层上的一个或多个系统设备（例如，感应器设备）相关联的数据（选择(系统设备)）的访问。

浏览更新文件()箭头指示SW更新模块703从SW图像700存储库请求或通过其他方式检索与SW更新模块703之前选择的系统设备相关的更新文件的URL。SW更新模块703此后向建筑服务器的FW更新BS模块721发送具有系统设备的更新文件的URL、设备MAC和通信路径中的一项或多项的FW更新消息（FW更新(文件URL，设备MAC，通信路径)）。在其中将被更新的设备是建筑服务器自身的情况下，通信路径可以是空的。如果网关（例如，无线网关）将被更新，则通信路径是网关的IP地址。并且如果系统设备将被更新，则通信路径是无线网关的IP地址和/或ZigBee短地址。在各种实施例中，至少在对诸如感应器设备的系统设备的更新的情况下，FW更新(文件URL，设备MAC，通信路径)箭头将完全绕过FW更新BS模块721，并且进行至直接调用网关的FW更新模块732。在当前的情况下（例如，图9中描绘的方法的实施例），建筑服务器的FW更新BS模块721进行检查（检查设备MAC()）以确定由SW更新模块703提供的设备MAC是否属于建筑服务器（例如，其自身）。如果不是这样，则其启动对与设备MAC相关联的设备的更新文件的检索。HTTPs 获取(文件URL)箭头指示FW更新BS模块721使用HTTPs协议来使用之前从SW更新模块703接收的文件URL检索合适的更新文件。

接下来，在其中建筑服务器的FW更新BS模块721已经检索将被更新的感应器设备的更新文件的实施例中，建筑服务器的FW更新BS模块721向合适的无线网关（例如，与将被更新的感应器设备相关联的无线网关）通知（FW更新()）更新文件的文件URL。设备MAC和通信路径也可以在这时被中继到无线网关。作为响应，无线网关110A使用所传达的文件URL从建筑服务器检索更新文件（HTTPs 获取（文件URL)）。在可替换的实施例中，无线网关自身可以实现HTTPS服务器，而非必须向建筑服务器查询该信息。无线网关还可以定期地向建筑服务器调查新更新。另外，无线网关可以实现TLS服务器套接字。

图像通知()箭头是无线网关向需要更新的特定感应器发送的关于存在可用的新更新的触发。产生于感应器（系统设备101）的查询下一个图像()箭头是对来自感应器的触发的响应，实质上询问与新更新相关联的细节。产生于无线网关的查询下一个图像响应()箭头是对该查询的响应。该响应可以包含与更新相关的信息，诸如版本划分信息（例如，主要和次要版本号）和硬件ID。在许多实施例中，使用ZigBee协议执行这些查询和响应。

此时，执行请求和响应的循环，直到与感应器的更新文件相关联的整个图像已经被传输给感应器自身为止。循环以感应器从无线网关请求图像块（图像块请求()）开始。作为响应，无线网关以所请求的图像块（图像块响应()）响应。一旦更新图像文件中的全部图像块已经被感应器设备接收，则循环终止。

根据许多实施例，在对全部更新文件图像块的传输之后，感应器设备通过例如调用升级结束请求()方法从无线网关请求关于前进的进一步的指令。在一些实施例中，无线网关可以通过指示其直到进一步的通知之前都不应当抑制开始软件/固件更新来对感应器做出响应（更新结束响应()）。通常使用ZigBee协议实现该升级结束请求/响应通信，但不必限于此。接下来，无线网关调用用于向建筑服务器的FW更新BS模块721通知与感应器设备相关联的新状态的方法（HTTPS(状态，设备MAC)）。在接收该通知时，建筑服务器的FW更新BS模块721转而通知云上的SW更新模块703与特定MAC地址相关联的感应器设备为更新准备就绪（状态更新(设备MAC)）。作为响应，SW更新模块703可以调用建筑服务器的FW更新BS模块721处的方法以触发对感应器设备处的更新的启动（触发FW更新(设备MAC，通信路径)）。该触发可以传送感应器设备的MAC地址和/或感应器设备的通信路径。在许多实施例中，建筑服务器的FW更新BS模块721转而使用类似的机制向无线网关通知更新触发（触发FW更新（…），其中“…”指设备MAC、通信路径）。响应于该通知，无线网关通知由MAC设备地址和/或通信路径识别的感应器设备其可以现在开始应用更新（更新结束响应(现在)）。感应器此后使用之前接收的更新的图像块应用更新（应用FW更新()）。在感应器已经完成安装更新并且已经执行像成功地重新启动这样的其他必要任务之后，其向无线网关指示其现在为签署和恢复惯常操作准备就绪（签署()）。

建筑服务器定位

图10A和10B一起图示了在用于对物理环境进行监测和控制的示范性的基于云的系统处定位建筑服务器的方法的实施例。两个图顶部的方框代表位于设施内的建筑服务器（例如，图1的建筑服务器100）和例如与图1的云115相关联的各种基于云的模块。项目服务模块708、远景插件模块709、远景部署引擎模块711、云连接性服务模块190和设备注册模块704全部是之前在图7A的上下文中描述的被同样地命名的基于云的模块的实施例。另外，系统地图应用模块160是之前在图1和图6的上下文中描述的基于云的应用模块。在图10A的左边描绘的用户C之前也在图6的上下文中作了描述。实质上，用户C是诸如安装人员或入网初始化工程师这样的人，其主要任务可以是在物理上和在逻辑上基于已创建的建筑的数字模型在建筑内安装设备。用户C或某个其他的被类似地授以凭证的用户此后可以参与入网初始化、配置和部署过程。

当前描绘的实施例以云中的项目服务模块708自启动（启动项目服务()）并且调用远景插件模块709的实例开始（启动()）。一旦执行，则远景插件模块709的实例将其自身注册到云连接性服务模块190（注册()）。同时，将被监测的建筑中的建筑服务器100将其自身注册到设备注册模块704。已经在伴随图8A和8B的描述中详细描述了建筑服务器100的注册过程。注册过程中的初始步骤中的一个步骤涉及建筑服务器100调用设备注册模块704处的API调用（注册()）并且提供其在本地已存储的建筑服务器ID，在各种实施例中，其在本地已存储的建筑服务器ID是MAC地址。在成功注册时，设备注册模块704返回建筑服务器100可以在其处继续与云的进一步通信的地址/位置和建筑服务器100为了访问由云提供的各种服务所需要呈现的凭证（连接设置()）。通常每建筑服务器实例地发出这些凭证。通过使用所接收的连接设置和其建筑服务器ID，建筑服务器100接下来通过与位于由设备注册模块704提供的地址/位置处的云连接性服务模块190联系而启动对安全连接的创建（创建连接(建筑服务器ID)）。在成功建立与云的安全连接时，云连接性服务模块190向建筑服务器100通知相同的内容（通过被标记了‘OK’的箭头来描绘）。

接下来，建筑服务器100进行至经由远景部署引擎（EDE）模块711向云通告其自身。其实质上调用由EDE模块711暴露正是用于该目的的API，并且提供关于自身的各种信息（例如，其建筑服务器ID以及软件和硬件版本划分信息）。这在图10A中是由被标记了建筑服务器通告(设备信息)的箭头代表的。为了将该通告传送到作为对来自诸如建筑服务器100的设备、诸如系统项目应用模块140和系统地图应用模块160的系统用模块的数据进行传送的模块的项目服务模块708，建筑服务器的通告必须首先被传播到远景插件模块709（建筑服务通告()）。在一些实施例中，来自建筑服务器100的建筑服务器通告被直接发送给远景插件模块709自身，而非被发送给远景部署引擎模块711。一旦建筑服务器的通告已经通过远景插件模块709到达云，则项目服务模块708被通知，并且其将建筑服务器添加到已知设备的列表（将设备添加到发现列表()）。项目服务模块708可以通过任何已知的手段（诸如将建筑服务器ID以及其他信息（例如，版本划分信息）添加到数据库）来做到这一点。

一旦建筑服务器100被注册和连接，并且项目服务模块708知道其出现，则用户（例如，在该图中描绘的用户C）可以在他/她在现场时使用被呈现在诸如平板型计算机的移动设备上的应用的前端访问系统应用模块（启动应用）。用户C可以是例如之前已经被授以用于访问诸如系统地图应用模块160的一个或多个系统应用的必要访问凭证的安装人员或入网初始化工程师。之前在图1和图6的上下文中详细讨论了示范性的系统应用模块。在各种实施例中，用户C然后浏览一遍他/她基于他/她的角色和凭证能访问的各种项目，并且图形化地选择与他/她在物理上位于其处的站点相关联的项目分层和建筑（选择项目(建筑)）。系统地图应用模块160然后从项目服务模块708取回或请求之前已为所选择的建筑创建的数据模型（获取()）。作为响应，项目服务模块708提供与所选择的建筑相关联的数字平面布置图（平面布置图()），该数字平面布置图此后被显示在在用户C的移动计算设备上执行的系统地图应用模块160的前端上（虚线箭头）。

接下来，用户C在系统地图应用模块160的前端上指示他/她希望定位建筑服务器（选择(建筑服务器)）。这可以通过简单地选择建筑服务器的图标并且将其拖拽到建筑的平面布置图的可视表示上来完成。与系统应用模块的该用户交互指示到了用户C获取建筑服务器的唯一的、制造商提供的QR码的图片的时候。相应地，应用模块160激活用户C的移动计算设备上的照相机设备（启动照相机()），并且从用户C请求QR码（要求QR码()）。用户C通过拍摄包含QR码的建筑服务器部分的照片来同意。QR在这里是作为示例被使用的，并且将不是限制性的。在其他实施例中，可以使用任何被物理地安装或附着在建筑服务器上的唯一码。系统地图应用模块160此后从由用户C的移动设备上的照相机设备捕获的图像中提取QR码（返回QR码(ID)）。

在图10B中描绘了与对建筑服务器进行定位的该实施例相关联的剩余步骤。一旦系统地图应用模块160已经从由用户C的移动设备上的照相机获取的图像中检索到QR码数据，则应用模块160将建筑服务器的ID随同QR码数据一起发送给项目服务模块708（放置<BSID>(QR数据)，其中BS代表建筑服务器）。在一些实施例中，这可以经由HTTPS 放置方法调用来完成。作为响应，项目服务模块708在可访问的发现列表中搜索具有相匹配的QR码数据的设备，并且返回所识别的设备的配置文件（例如，“被发现的设备配置文件”）（在发现列表中搜索设备(QR数据，被发现的设备配置文件)）。接下来，项目服务模块708在存储器中使物理设备（例如，其QR码被用户C在图像中捕获的建筑服务器）与用于定位到物理的建筑服务器驻留在其中的建筑的模型的楼层平面中的虚拟设备相互关联（将物理的关联到虚拟的设备(模型，被发现的设备配置文件)）。项目服务模块708此后向系统地图应用模块160返回确认（虚线箭头）。

在接收确认之后，应用模块160检查以确定用户C正在定位的建筑服务器是在线的还是离线的。相应地，其调用项目服务模块708处的合适API调用，并且提供必需的建筑服务器ID（获取在线状态(建筑服务器ID)）。项目服务模块708使用所提供的建筑服务器ID执行查找（例如，在数据库中）以检索相关联的被发现的设备配置文件（查找(建筑服务器ID，被发现的设备配置文件)）。通过使用被发现的设备配置文件，项目服务模块708然后利用建筑服务器的合适ID调用远景插件模块709，并且请求在线状态（获取在线状态(BS ID)），远景插件模块709此后可以使用该在线状态与正确的建筑服务器联系以直接请求在线状态信息（请求在线状态()）。建筑服务器然后返回其在线状态（例如，对其当前在线还是离线的指示）（虚线箭头）。该信息然后被远景插件模块709经由例如对合适API调用的调用（回调设备状态(在线)）传播到项目服务模块708。基于由项目服务模块708接收的信息（例如，在线或离线），项目服务模块708恰当地向系统地图应用模块160进行通知（替换虚线箭头在线和离线）。如果建筑服务器100当前是在线的（例如，在用户C正在尝试完成定位过程时），则系统地图应用模块160通知用户C建筑服务器100已经被成功地定位（显示成功的定位()）。可替换地，如果建筑服务器100当前被确定为离线的，则在各种实施例中，项目服务模块708移除之前已创建的被发现的设备配置文件与物理建筑服务器之间的关联，并且系统地图应用模块160通知用户C定位已经失败（显示定位失败()）。可以通知用户C定位失败的原因，例如，建筑服务器100是离线的，并且为了定位恰当地完成定位建筑服务器必须在线在线是必要的。

网关定位

图11图示了在用于对物理环境进行监测和控制的示范性的基于云的系统处定位无线网关（例如，图1的网关110A）的方法的实施例。该图顶部的方框代表位于设施内的建筑服务器100（例如，与图1的建筑服务器100类似的）和例如与图1的云115相关联的各种基于云的模块。远景插件模块709和项目服务模块708是之前在图7A的上下文中描述的被同样地命名的基于云的模块的实施例。另外，系统地图应用模块160是之前在图1和图6的上下文中描述的基于云的应用。之前也在图6的上下文中描述了在图11的左边描绘的用户C。实质上，用户C是诸如安装人员或入网初始化工程师这样的人，其执行诸如在物理上和在逻辑上基于已创建的建筑的数字模型在建筑内安装设备和此后参与入网初始化、配置和/或部署过程这样的任务。

在一些实施例中，用于无线网关110A的定位过程以无线网关经由例如MQTT协议发送签署消息开始。在许多实施例中，签署消息包含建筑服务器的唯一ID、无线网关的IP地址、关于网关的信息和与无线网关相关联的ID（签署(建筑服务器ID，IP地址，设备信息、无线网关ID)）。在各种实施例中，建筑服务器运行MQTT代理（例如，如在图7B中描绘的那样），MQTT代理然后将签署消息转发给远景插件模块709（如第二个被标记了签署(建筑服务器ID，IP地址，设备信息，无线网关ID)的箭头描绘的那样）。远景插件模块709自己将签署消息及其相关联的参数转发给在云115上运行的项目服务模块708。为此，其可以调用项目服务模块708作为其API的部分暴露的回调方法或功能（回调(建筑服务器ID，IP地址，设备信息，无线网关ID)）。回调是一种通知项目服务模块708尚未被定位的新设备正在尝试签署并且是可用的方法。项目服务模块708然后将在回调中接收的关于无线网关110A的信息添加到它的它之前尚未遇到的“新”设备的列表（将设备添加到发现列表()）。

同时，在该实施例中，用户C在于诸如平板型计算机的便携式计算设备上执行的系统地图应用模块160的用户接口上图形化地选择代表无线网关110A的图标（对无线网关的选择）。这使系统地图应用模块160激活便携式设备上的照相机应用（启动照相机()）。地图应用模块160然后可以向用户C提示与无线网关相关联的QR码（要求QR码()）。为了遵从，用户C使照相机指向在其上具有QR码的无线网关的部分，并且拍摄照片（拍摄照片()）。然后由地图应用模块160对图像进行分析，并且提取QR码（返回并解码QR码()）。

一旦从图像中提取了QR码，则地图应用模块160请求项目服务模块708使与QR码相关联的物理设备与被表示在建筑的数据模型中（例如，建筑的数字平面布置图上）并且被表示在地图应用模块160的图像用户接口上的虚拟设备相互关联（将物理设备关联到虚拟设备(QR码，虚拟设备ID)）。在许多实施例中，为了识别物理设备，地图应用模块160提供QR码，并且为了识别虚拟设备，其提供虚拟设备ID。作为响应，项目服务模块708在它的被发现的设备列表中定位虚拟设备（在列表中搜索设备()），并且此后出于定位目的在存储器中使物理设备（例如，其QR码被用户C在图像中捕获的无线网关）与虚拟设备（例如，与由系统地图应用模块160提供的虚拟设备ID相匹配的其列表中的虚拟设备）相互关联（将物理设备关联到虚拟设备()）。项目服务模块708此后向系统地图应用模块160返回确认（通过从项目服务模块708到系统地图应用模块160的虚线箭头来描绘）。

在接收对关联的确认之后，系统地图应用模块160请求与无线网关相关联的在线状态。为了允许项目服务模块708检索该状态，其提供无线网关的虚拟设备ID（获取在线状态(虚拟设备ID)）。项目服务模块708此后基于虚拟设备ID检索被发现的设备配置文件。在各种实施例中，配置文件包括设备（在该示例中，无线网关）的物理地址（查找(虚拟设备ID，被发现的设备配置文件)）。项目服务模块708然后将对无线网关的在线状态的请求转发给远景插件模块709（获取在线状态(DDP)，其中“DDP”代表被发现的设备配置文件），并且该请求被级联（取得在线状态（DDP））到合适的建筑服务器（在该示例中，建筑服务器100）。在许多实施例中，被包括在被发现的设备配置文件中的无线网关的物理地址还识别与正在考虑的网关相关联的合适建筑服务器的地址。建筑服务器100请求在被发现的设备配置文件中被识别的无线网关进行签署（请求签署()），并且作为响应，无线网关进行签署，并且向建筑服务器指示相同的内容（签署()）。建筑服务器此后通知远景插件模块709无线网关是在线的（在线状态结果(真)），并且该插件转而使用例如其回调API通知项目服务模块708（回调(在线状态真)）。最后，项目服务模块708通知系统地图应用模块160无线网关事实上是在线的（设备在线()），并且地图应用模块转而向用户C指示成功的定位（显示成功的定位()）。

对诸如感应器设备的系统设备进行定位

图12A、12B-I和12B-II图示了在用于对物理环境进行监测和控制的示范性基于云的系统处定位诸如感应器设备（例如灯具）的系统设备的方法的一个实施例。该图顶部的方框代表位于设施内的建筑服务器（例如，图1的建筑服务器100）、无线网关（例如，图1的网关110A）、感应器设备（例如，图1的设备101）、IR遥控设备和例如与图1的云115相关联的各种基于云的模块。远景插件模块709和项目服务模块708是之前在图7A的上下文中描述的被同样地命名的基于云的模块的实施例。附加地，系统地图应用模块160是之前在图1和6的上下文中描述的基于云的应用。之前也在图6的上下文中描述了在这些图的左上方描绘的用户C。实质上，用户C是诸如安装人员或入网初始化工程师的人，在该上下文中他的主要任务可以是在物理上和在逻辑上基于已创建的建筑的数字模型在建筑内安装设备。在许多实施例中，用户C此后参与入网初始化、配置和部署过程。

用户C通过选择被描绘在被呈现在系统地图应用模块160上的建筑的数字平面布置图上的诸如灯具的感应器设备开始定位过程（选择（感应器））。如前所述，地图模块160的前端可以正在平板型计算设备上执行。在许多实施例中，由于被用于填充平面布置图的底层数据模型已经具有关于与所选感应器设备相关联的无线网关的信息，地图模块160请求项目服务模块708打开与特定无线网关相关联的网络。为了促进网络的打开，地图模块160提供网关的合适ID（打开网络（网关ID））。在接收到该请求时，项目服务模块708在添加相关联的建筑服务器的ID和网关的IP地址之后向远景插件模块709转发类似的请求（打开网络（建筑服务器ID，网关ID、网关IP地址））。远景插件模块709进而请求由所提供的建筑服务器的ID标识的特定建筑服务器打开ZigBee网络。为了促进这一点，插件提供相关联的网关的IP地址（打开ZigBee网络（网关IP地址））。作为响应，建筑服务器（例如，该示例中的建筑服务器100）向由网关IP地址识别的无线网关转发对于打开建筑服务器的ZigBee网络的类似请求（打开ZigBee网络（））。无线网关（例如，该示例中的网关110A）打开其ZigBee网络，并且向全部相关联的感应器设备通知相同的内容（发送信标（））。无线网关110A还通知建筑服务器100网络已经被成功地打开（网络打开（））。建筑服务器100进而向远景插件模块709通知对ZigBee网络的成功打开（通知（成功打开））。插件模块709就其本身而言通知项目服务模块708特定网络的状态已经改变为“打开”状态（网络状态改变（打开））。项目服务模块709此后通知系统地图应用模块160原来从应用模块接收的网络打开请求已经实际上被成功完成，以及与由应用模块标识的特定网关ID相关联的网络实际上是打开的（网络打开（网关ID））。在一些实施例中，系统地图应用模块160在接收到该信息时在其GUI上显示其IR遥控对话框（显示IR对话框（））。

一旦IR遥控对话框已经在地图应用模块上被打开，则用户C可以自由地使IR遥控设备指向感兴趣的感应器，以及按下按钮以指示感应器应当被添加到其无线网关的网络。在许多实施例中，该按钮可以被指定为“添加”按钮。IR遥控设备接收该输入，并且作为响应，向感应器设备发送指示感应器设备应当将其自身添加到其无线网关的打开的网络的信号（添加（））。在已经接收该指令的情况下，感应器设备向无线网关110A发送对于加入无线网关110A的网络的请求（请求加入（）），在此之后无线网关110A将感应器添加到其无线网络（将设备添加到网络（）），并且通知感应器它的对于加入网关的网络的请求被接受（接受加入（））。在许多实施例中，如果感应器加入无线网关的网络，则它挑选短地址来标识其自身。感应器然后提供其设备信息以及其短地址与无线网关110A签署。无线网关110A将签署请求随同与感应器相关联的感应器ID、无线网关自身的ID、建筑服务器的ID、无线网关的IP地址和感应器的设备信息一起转发给建筑服务器100（签署（感应器ID，网关ID，建筑服务器ID，网关IP地址、设备信息））。在各种实施例中，无线网关110A可以提供上面标识的信息的子集。在接收时，建筑服务器100将相同的请求转发给远景插件模块709。该插件模块用相同或相似的参数调用项目服务模块708的回调方法（回调（感应器ID，网关ID，建筑服务器ID，网关IP地址，设备信息）），并且项目服务模块708进而通知系统地图应用模块160与之前由用户C在应用上选择的感应器相对应的新设备已经被发现。在许多实施例中，项目服务模块708还向地图应用模块160转发唯一物理设备标识符作为功能调用的参数（发现设备（物理设备ID））。

此后，如在图12B-I和12B-II中描绘的那样，项目服务模块708将感应器设备添加到被云管理的设备的列表（将物理设备添加到设备管理器列表（物理设备ID，虚拟设备ID））。如之前在对网关和建筑服务器进行定位的上下文中讨论的那样，物理设备ID通常是与物理设备自身相关联的唯一标识符（例如，制造商提供的ID），并且虚拟设备ID通常是可以已经是与物理设备（例如，在数据库中）的虚拟表示相关联的唯一标识符。例如，与收容物理感应器的特定建筑相关联的数据模型可以甚至在物理感应器被实际地定位或关联到其虚拟表示之前具有用于代表物理感应器的虚拟标识符。

接下来，项目服务模块708在诸如数据库的存储器中使感应器的物理设备ID与其虚拟设备ID相关联（将物理设备关联到虚拟设备（物理设备ID，虚拟设备ID））。同时，系统地图应用模块160向用户C（例如，可视地）指示感应器设备已经被成功地定位（显示成功的定位（））。用户C此后可以进行至通过例如在被显示在地图应用模块160上的数字平面布置图上选择代表感应器设备的图标来定位另一个感应器设备（选择（感应器设备））。在各种实施例中，即使在于建筑中定位各种感应器设备时涉及云系统时，但对已定位设备的部署自动地、并行地进行，而没有来自用户C的任何进一步的辅助或介入。

项目服务模块708通常通过用感应器设备的虚拟设备ID调用其自身的方法开始已定位感应器设备（例如，灯具）的部署过程（部署（虚拟设备ID））。此后，项目服务模块向远景插件模块709发送对于创建适合于感应器设备的设备配置的请求。在各种实施例中，这样的请求包括感应器设备的虚拟设备ID、该设备位于其中的区域的指示（例如，门厅、会议室、办公室、建筑楼层）和指示感应器设备在各种情况（例如，占用、光或热的改变）下的行为的一个或多个模板片段（采用人类或机器可读的格式）（创建设备配置（虚拟设备ID，区域，模板片段））。在接收到该请求时，远景插件模块709在执行协议之间的任何必要的转换之后简单地将其转发给远景部署引擎模块711。在接收到该请求时，远景部署引擎模块711使用所接收的模板片段、区域信息和虚拟设备ID创建可以被正在考虑的感应器设备读取的目标配置文件（创建设备配置（虚拟设备ID，区域，模板片段））。对成功的创建的确认被级联（cascaded）回远景插件模块709和项目服务模块708（通过被标记了‘ACK’的虚线箭头来描绘）。

一旦项目服务模块708已经接收到成功创建目标配置的确认，则它向远景插件模块709发送对于开始更新感应器设备的配置的请求（发送更新命令（虚拟设备ID，目标配置））。作为响应，远景插件模块709在执行任何必要的协议格式转换之后向建筑服务器100转发类似请求。建筑服务器100然后将更新请求随同虚拟设备ID一起添加到保持对于更新各种设备的配置的类似请求的更新队列（队列命令（虚拟设备ID））。这是由于关于用户C可以在其他已定位的设备正在被配置的同时定位新设备的事实造成的。配置过程，具体地说，将许多配置数据块写入设备自身可能是耗时的。相应地，在许多实施例中，在对于对最近被定位的设备进行的配置的请求被建筑服务器100接收时，其被添加到队列并且在先来先服务的基础上处理。假设在该示例中正在讨论的感应器设备是被添加到队列中的第一个，则建筑服务器100通知感应器设备它应当现在开始监听来自建筑服务器的命令（侦听（））。作为响应，感应器设备向建筑服务器100发回确认（通过被标记了‘ACK’的虚线箭头来描绘）。

接下来，建筑服务器100向无线网关110A发送它希望将配置数据的块写入由虚拟设备ID标识的特定感应器设备的信号/消息（写入配置块（虚拟设备ID，配置块））。无线网关将消息转发给由虚拟设备ID标识的正确感应器设备。在接收来自感应器设备的确认时，其被级联回建筑服务器100（通过被标记了‘ACK’的两个虚线箭头来描绘）。重复地执行的序列，直到与已为感应器设备创建的目标配置文件相关联的全部块已经被写入感应器设备为止。一旦全部块已经被写入，则建筑服务器100通知远景插件模块709特定感应器设备的配置更新已经完成（更新完成（虚拟设备ID））。该消息然后被级联到项目服务模块708，项目服务模块708记录关于特定感应器设备的配置现在最新的事实。项目服务可以用多种多样的方式做到这一点，包括将对基于云的应用模块可访问的数据库更新为指示相同的内容（设备配置最新（））。最后，项目服务向系统地图应用模块160发送指示对特定感应器设备的配置现在完成的消息（更新完成（虚拟设备ID））。

同时，建筑服务器100还向感应器设备发送重置消息（重置（）），该重置消息使感应器设备重新启动其自身。在许多实施例中，在成功地重新启动其自身时，感应器设备将签署消息随同其设备信息和对设备具有新配置的指示一起发送给建筑服务器100（签署（设备信息，新配置））。

凭证验证和安全通信

在一些实施例中，网关110A和/或110B（见例如图1；和/或如将在下面讨论的照明系统控制器）可以直接地或间接地连接到基于云的服务。操作诸如智能电话、智能手表、平板电脑等移动计算设备的用户可能希望控制由与这样的网关通信的一个或多个灯具输出的光的一个或多个属性（和/或例如从HVAC部件输出的空气的一个或多个属性）。在一些情况下，用户可以在移动计算设备上安装可以直接连接到网关和/或基于云的服务以便对光输出进行控制的应用（或“app”）。网关和/或云服务可以是可以经由一个或多个诸如Wi-Fi、以太网的基于IP的网络访问。

对于传输层安全，在这样的移动设备运行的app可能需要验证通信对端（peer）的凭证。可以使用信任链对公钥证书进行验证，信任链在可以被安装在对该信任链进行验证的设备上的受信任的根证书中结束。然而，这呈现各种挑战。如上面指出的，PKI基础设施需要被实现用本公开内容的经选择方面进行配置的系统的一方部分地建立和维护，而PKI基础设施的剩余部分可以被卸载到公知的第三方认证机构（“CA”）。这可能是在经济上昂贵的，并且可能需要内部（in-house）专业技能。可能还需要在内部或由第三方CA维护PKI基础设施的安全性（诸如，保持证书签名密钥是安全的）。可能还有必要实现签名密钥被泄露的情况下的措施。在第三方CA被用于颁发证书时，成本可以是高昂的，并且也是贯穿设备/系统的生命周期重复发生的。附加地，第三方CA颁发证书可以具有有效期（通常最多3年），并且因此，用于更新证书的机制需要准备就绪。网关（例如，110A、110B）可能需要下载它们的证书，这将需要它们在至少一个短的时段内是在线的。

鉴于这些挑战，一种更简单的方法在于，让网关（例如，110A和/或110B）和/或照明系统控制器生成其自身的经自签名的证书，并且使用该证书进行通信。经自签名的证书不可以使用常规PKI机制进行认证，并且尽管将证书固定（pin）在第一联系人上大大减小了中间人（“MITM”）攻击的风险，但对第一联系人的攻击仍是一个风险。此外，需要对于每个应用/设备完成固定，并且这轻微地增大了攻击窗口，因为针对MITM发起这样的攻击的存在更多机会窗口。相应地，下面描述了用于对经自签名的证书和其他类似的自生成的凭证的带外（“OOB”）验证的技术。在本文中描述的示例中，OOB信道采用基于电磁辐射的信道（例如，光）的形式。然而，这将不意图是限制性的。可以在其他介质（诸如，（例如，对于人类可听的频率范围和/或对于人类不可听的频率范围中的）基于音频的信道）上使用本文中描述的技术实现OOB信道。

图13示意性地图示了验证诸如上面描述的网关110A和110B这系统部件以及可以提供类似功能的其他部件的自生成的凭证的技术的一个实施例。在图13中，寻求验证照明系统控制器1352的凭证的计算设备1350采用智能电话的形式，该智能电话具有采用一个或多个摄像头（例如，前置和/或后置）形式的光传感器1354。然而，这将不意图是限制性的。在其他实施例中，计算设备1350可以采用诸如膝上型计算机、智能手表、智能眼镜或其他智能服装、独立的交互式扬声器等这样的其他形式。尽管未描绘，在其中OOB信道使用基于音频的技术实现的一些实施例中，计算设备1350可以包括诸如麦克风的音频传感器。

照明系统控制器1352可以以各种形式出现，并且可以包括诸如一个或多个处理器、存储器、（多个）通信接口、输入、输出等这样的通常在计算设备中被找到的各种部件。尽管在图13中描绘了照明系统控制器1352，这不意图是限制性的。在各种实施例中，与参照图13描述的那些技术类似的技术可以被用于对本文中描述的其他部件（诸如，上面描述的网关110A和110B）的凭证进行验证。在图13中，照明系统控制器1352包括一个或多个指示器灯1356，该一个或多个指示器灯1356在一些实施例中可以采用LED的形式，但这不意图是限制性的。在一些实施例中，照明系统控制器1352可以包括与智能电话的触摸屏或与典型计算机相关联的屏幕类似的能够渲染多种多样的颜色的显示设备（未被描绘）。从计算设备1350的角度看，照明系统控制器1352（或网关110A和110B）可以被称为“远程设备”，因为它们是与计算设备1350分离的并且完全不同的，但经由一个或多个通信网络与计算设备1350通信的。

还在图13中描绘了连网的灯具1358。连网的灯具1358可以具有各种形式因素。在一些实施例中，连网的灯具1358可以包括所谓的“智能灯泡”，该“智能灯泡”包括可操作以发射具有各种属性的光的一个或多个LED（例如，RGB信道）。在其他实施例中，连网的灯具1358可以采用其他形式和/或可以使用其他光源类型，这样的光源类型包括但不限于卤素灯、白炽灯、荧光灯等。在各种实施例中，连网的灯具1358可以包括各种计算部件（诸如，（多个）处理器、存储器、网络通信接口等）。在一些实施例中，连网的灯具1358可以经由一个或多个网络（未在图13中描绘）与照明系统控制器1352通信（例如，“通信地耦合”）。这些网络可以使用各种有线的和/或无线的（例如，ad hoc或其他）技术来实现，这样的技术包括但不限于ZigBee、Z-Wave、Wi-Fi、蓝牙、一种或多种光学无线通信技术（例如，可见光通信或“VLC”）等。

如上面指出的，图13演示了计算设备1350可以如何对其从（或代表）照明系统控制器1352获取的凭证进行验证的一个示例。这些凭证可以采用任何建立通信对端的身份（诸如，密码、加密密钥、公钥证书等）的形式。在一些实施例中，计算设备1350可以在图13中描绘的那些操作之前的操作中（例如，作为初始握手程序）从照明系统控制器1350获取这些凭证。例如，在一些实施例中，在计算设备1350初始尝试联系照明系统控制器1352时，照明系统控制器1352可以向计算设备1350提供其凭证。在图13的操作之前，被计算设备1350获取的凭证可以不是经验证的，并且因此可以被称为“未经验证的凭证”。

在图13的操作1A处，计算设备可以经由第一网络通信信道（例如，诸如Wi-Fi这样的基于射频的和/或基于IP的网络通信信道、诸如ZigBee或Z-Wave的ad hoc网络等）向照明系统控制器1352发送对于对未经验证的凭证进行验证的请求。在一些实施例中，操作1A处的请求可以伴随远程设备id，该远程设备id可以标识诸如连网的灯具1358的另一个远程设备。例如，假设操作计算设备1350的用户位于由连网的灯具1358发射的光的视线内。用户可以例如通过读取被提供在连网的灯具1358的表面上（例如，经由贴纸或被直接印刷在该表面上）的标记获取与连网的灯具相关联的标识符。在一些实施例中，标记可以是可以例如使用计算设备1350的光传感器1354读取的计算机可读的（例如，条形码或快速响应（“QR”）码）。例如，被安装在计算设备1350上的照明控制应用（或“app”）可以包括用于例如从连网的灯具1358的表面（或，如将在下面描述，从照明系统控制器1352的表面）读取计算机可读信息的功能性。在其他实施例中，用户可以例如使用触摸屏、语音输入等手动输入连网的灯具1358的标识符。

在一些实施例中，在操作1B处，计算设备1350可以设置定时器（例如，T _A ），该定时器可以建立用于计算设备1350从连网的灯具1358接收所谓的“验证数据”（这将在下面更详细地描述）的时间间隔或时间限制。任何由计算设备1350在该定时器期满之后接收的验证数据可以被忽略。

在操作2A处，照明系统控制器1352可以使用诸如Wi-Fi的基于IP的网络、诸如ZigBee或蓝牙的ad hoc网络等例如向连网的灯具1358发送基于照明系统控制器1352的凭证的所谓的“基于凭证的数据”。在一些实施例中，基于凭证的数据可以包括之前被提供给计算设备1350的相同的（未经验证的）凭证的散列。在一些实施例中，与操作2A同时地或至少同时期地（contemporaneously），在操作2B处，照明系统控制器1352可以将其自身的定时器设置为例如，T _B 。该时间间隔T _B 可以与由计算设备1350在操作1B处设置的时间间隔T _A 相同，或可以是不同的时间间隔。在时间间隔T _B 期间，照明系统控制器1352可以忽略任何到来的照明控制命令。否则，中间人（“MITM”）攻击者可以向照明系统控制器1352发出例如用于使连网的灯具1358输出经调制的光（例如，VLC）的照明控制命令，该经调制的光包括将使计算设备1350信任MITM攻击者的与MITM攻击者相关联的非法的经编码的凭证。类似地，计算设备1350可以设置定时器T _A ，因为计算设备1350不应当信任任何在定时器T _A 期满之后被接收的凭证。

在图13的操作3处，经由与被计算设备1350用于直接与照明系统控制器1352通信的网络通信信道（例如，Wi-Fi、ZigBee等）不同的另一个网络通信信道（一般被称为“带外”或“OOB”信道），连网的灯具1358可以发送并且计算设备1350可以接收验证数据。在一些实施例中，可以在计算设备1350处（经由光传感器1354）以经调制的VLC数据的形式和/或以使用颜色编码的信息的形式从连网的灯具1358接收该验证数据。在一些实施例中，验证数据可以包括在照明系统控制器1352与计算设备1350之间共享的未经验证的凭证的散列。

在图13的操作4处，计算设备1350可以将其之前获取的未经验证的凭证（以及，在一些情况下，由计算设备1350生成的未经验证的凭证的散列）与从连网的灯具1358接收的验证数据进行比较。基于比较，计算设备1350可以验证未经验证的凭证是合法的，或确定它们是非法的。在前一种情况下，计算设备1350可以在计算设备1350与照明系统控制器1352之间建立照明信息通信信道。此后，计算设备1350可以例如被操作以经由照明信息通信信道向照明系统控制器1352发送一个或多个照明命令，其中该一个或多个照明命令使照明系统控制器1352使得一个或多个灯具（例如，连网的灯具1358）根据该一个或多个照明命令发射光。附加地或备选地，计算设备1350可以经由照明信息通信信道从照明系统控制器1352接收各种数据，诸如，关于灯具操作的操作信息、传感器数据（例如，日光传感器、存在传感器等）等。

利用图13中描绘的操作序列，有可能邪恶方可以通过请求照明系统控制器1352验证凭证来发起拒绝服务（“DoS”）攻击，其如上面指出的情况是照明系统控制器1352将设置定时器T _B ，在T _B 期间照明系统控制器1352可以忽略任何照明控制命令的。同样地，可以使照明系统控制器1352接洽OOB信道以使连网的灯具1358（或其他连网的灯具）对未经验证的凭证进行编码，这可能是不期望的。相应地，在各种实施例中，可以以各种方式执行用于防止这样的DoS攻击的各种操作。例如，在一些实施例中，必须在照明系统控制器 1352将与连网的灯具1358接洽以执行凭证验证之前促动照明系统控制器1352（或网关110A/110B）上的物理的用户接口元件（未被描绘）（诸如，按钮、触摸屏等）。

附加地，在一些实施例中，照明系统控制器1352可以对“正常”照明命令（例如使连网的灯具1358发射具有由用户为日常使用选择的各种属性的光的例行照明控制命令）强制施行（多个）速率限制。照明系统控制器1352可以响应于操作1A仅以超过该（多个）速率限制的速率向连网的灯具1358发送照明控制命令。这可以防止中间人（“MITM”）攻击欺骗照明系统控制器1352在定时器T _A 期满之前提供对非法的凭证的散列进行编码的命令。

在图14中描绘了用于防止或限制DoS攻击的另一种技术。图14示意性地描绘了与图13中描绘的场景和操作序列类似的场景和操作序列。然而，在图14中，OOB信道是直接由照明系统控制器1452（或在其他实施例中，网关110A和/或110B）而非在诸如连网的灯具（未在图14中描绘）的单独的远程设备上实现的。具体地说，照明系统控制器1452上的一个或多个LED指示器1456可以被操作以发射被调制为携带信息（例如，VLC）的光。在各种实施例中，可以在计算设备1450的光传感器1454（例如，智能电话的前置或后置摄像头）处检测该经调制的光。

图14的操作在其他方面与图13的那些操作相似。在图14的操作1A处，计算设备1450向照明系统控制器1452发送对于对未经验证的凭证进行验证的请求。如上面指出的，在各种实施例中，可以在图14的操作之前例如由照明系统控制器1452或另一个网络部件与计算设备1450共享这些未经验证的凭证（例如，公钥、密码、证书等）。应当指出，在图14中，该请求不包括与连网的灯具（或一般地，另一个远程设备）相关联的标识符，原因在于照明系统控制器1452自身将接洽OOB验证。就像分别在图13的操作1B和2B处被完成的那样，分别在操作1B和2处，计算设备1450设置定时器T _A ，并且照明系统控制器设置定时器T _B 。在操作3处，照明系统控制器1452使用OOB网络通信信道——在该实例中，通过从一个或多个LED指示器1456发射的经调制（或“编码”）的光——以经编码和散列的凭证的形式提供验证数据。图14的操作4与图13的操作4类似。由于连网的灯具未被用于实现OOB信道，所述DoS攻击不会使灯发射具有不希望的属性（例如，闪烁、颜色变更、其他效果）的光。附加地，MITM攻击可以因为不允许它们控制使用一个或多个LED指示器1456实现的OOB信道而被受挫——在该特定示例中，照明系统控制器1452仅可以响应于操作1A的验证凭证请求来接洽OOB信道。

在图15中描绘了用于防止/减少DoS攻击的另一种技术。在图15中，计算设备1550和照明系统控制器1552（或网关110A/110B）可以共享诸如共享秘密（shared secret）的信息，以确保仅具有关于这样的信息的知识的计算设备能够使照明系统控制器1552接洽OOB信道以向计算设备1550发送验证数据。共享秘密可以采用各种形式。在一些实施例中，共享秘密可以包括例如经由被印刷在其表面上的可视标记1557或通过贴到其表面的贴纸/标签被提供在照明系统控制器1552的表面上（或诸如连网的灯具1558的另一个远程设备上）的唯一码、序列号等。在一些实施例中，可以使用标记渲染共享秘密，该标记是计算机可读的（例如，QR码、条形码等），并且因此可以被计算设备1550直接读取。在其他实施例中，共享秘密可以被用户读取并在计算设备1550处手动输入。在一些实施例中，计算设备1550可以被配置为，执行光学字符识别（“OCR”）以读取否则人类可读的共享秘密，使用户免于必须手动输入共享秘密。在任何情况下，尽管共享秘密可以是可以被位于现场的某人容易观察到的，但其很可能将不是可以被位于现场外但希望实现MITM攻击的邪恶方观察到的。实际上，在一些情况下，可以使共享秘密是在对于即使是现场攻击者也难以访问的位置处可得的。例如，在一些实例中，可以某个标记在诸如可插入插座中的公端的位置处被印刷或贴到灯具，使得除非攻击者在物理上从插座移除灯具，否则它不是可见的。标记也可以被提供在照明控制器1552的很难看到的位置上，诸如在被安装时面向墙壁或天花板的表面。

在图15的操作1处，计算设备1550发送在本文中将以非限制性的方式被称为DEVICE_HELLO_VERIFICATION消息的内容。在各种实施例中，该消息可以包括由计算设备1550生成或通过其他方式获取的随机数DEVICE_随机。与图13的操作1处的消息类似，该消息可以附加地或备选地包括计算设备1550的用户希望从其接收验证数据的已标识的远程设备（连网的灯具1358）的远程设备标识符。在图15的操作2处，照明系统控制器1550可以发送在本文中将以非限制性的方式被称为GATEWAY_HELLO_VERIFICATION消息的内容。在各种实施例中，该消息可以包括由照明系统控制器1552（或网关110A/110B）生成或通过其他方式获取的随机数，GATEWAY_随机。

在操作3A和3B处，照明系统控制器1552和计算设备1550分别可以计算将被用于加密功能的秘密密钥。在一些实施例中，密码函数可以是密钥散列消息认证码（“HMAC”），尽管这不是必需的，并且可以使用诸如安全远程密码协议（“SRP”）的其他协议。在图15中，计算设备1550和照明系统控制器1552中的每一个可以（分别在操作3B和3A处）基于各种数据点以各种方式（诸如，使用以下方程）计算秘密密钥K：

K = hash(共享秘密 || DEVICE _随机 || GATEWAY _随机 )。

在操作4处，计算设备1550可以（使用密钥K）使用各种数据计算和发送HMAC _K 消息。在一些实施例中，HMAC _K 消息可以由计算设备1550使用以下方程计算：

HMAC _K (DEVICE_HELLO_VERIFICATION消息 || 远程设备id ||DEVICE _随机 || GATEWAY _随机 )。

在图15的操作5处，照明系统控制器1552可以计算它自身的HMAC _K 消息，并比较它自身的HMAC _K 消息与它在操作4处接收的HMAC _K 消息。在一些实施例中，由照明系统控制器1552计算的HMAC _K 消息可以使用与由计算设备1550在操作4使用的方程相同的方程计算。照明系统控制器1552然后可以检查它在操作4处接收的散列是否与它在操作5处计算的散列相匹配。

仅当这些消息相匹配，照明系统控制器1552可以继续图15的操作。如果存在匹配，则在图15的操作6处，照明系统控制器1552可以计算并向计算设备1550发送其自身计算的HMAC _K 消息。在一些实施例中，照明系统控制器1552可以使用以下方程：

HMAC _K (GATEWAY_HELLO_VERIFICATION消息 || 远程设备id ||GATEWAY _随机 ||DEVICE _随机 )。

该消息可以向计算设备1550证明，计算设备1550事实上正在与照明系统控制器1552通信。否则，MITM攻击者可以向照明系统控制器1552发送用于使照明系统控制器1552接洽OOB信道以对其凭证进行编码的命令。在操作7处，照明系统控制器1552可以如之前描述的那样设置定时器T _B 。

在图15的操作8处，计算设备1550可以例如使用与由照明系统控制器1552在操作6处使用的相同的方程计算HMAC _K 消息，计算设备1550然后比较该HMAC _K 消息与其在操作6处从照明系统控制器1552接收的HMAC _K 消息。仅当这些消息相匹配时，计算设备1550可以继续图15的操作。例如，在操作8处，计算设备1550可以如之前描述的那样设置定时器T _A 。图15的剩余操作9-11与图13的操作2A、3和4类似。然而，在一些实施例中，与被用于操作9的网络通信信道（照明系统控制器1552到连网的灯具1558）不同的网络通信信道可以被用于操作1、2、4和6（计算设备1550与照明系统控制器1552之间，例如，诸如Wi-Fi的基于IP的有线或无线网络）。例如，ZigBee或另一种类似类型的网络可以被用于操作9，因为这样的信道可能已经内置了防止MITM攻击者在那个信道上改变消息的保护性机制（例如，可能之前例如在入网初始化阶段期间已经将一个或多个连网的灯具与照明系统控制器1552配对）。

还在本文中设想了图13-15中描绘的技术的各种变型。例如，在图15中描绘的技术的一种变型中，可以省略在图15的操作6处被发送的HMAC _K 消息。作为代替，照明系统控制器1552可以通过IP网络或通过OOB信道发送HMAC _K （凭证）。在另一种变型中，在一些实施例中，可以使用照明系统控制器1552的LED指示器1556而非单独的连网的灯具1558实现OOB信道。

在仍另一实施例中，不具有任何用于输入/读取/检测网络中的共享秘密的单元的受限的用户接口设备（例如，连网的摄像头）也可以验证网关（例如，110A/110B）和/或照明系统控制器（例如，1352、1452、1552）的凭证。这可以是有用的，因为具有用于读取共享秘密手段的另一个设备（诸如，智能电话）可以证明共享信息（共享秘密）的所有权（例如，图15中的操作步骤1至8），这可以使网关/照明系统控制器将验证数据（例如，凭证的散列）编码在OOB信道上。受限的用户接口设备可以检测该验证数据，并且例如使用凭证的散列进行验证。由于受限的用户接口设备不具有用于输入/读取/检测共享秘密的手段，其不可以自己计算HMAC _K 消息。相应地，图15的流程对于这样的设备是有用的。OOB信道可以是可以被受限的用户接口设备理解的任何信道。实际上，也可以用图13和14中描述的技术来采用该变型。

虽然本文已经描述和说明了若干发明实施例，但是本领域普通技术人员将容易设想到用于履行功能和/或获得本文所描述的结果和/或优点中的一个或多个的各种其他装置和/或结构，并且这些变化和/或修改中的每个被认为是在本文所描述的发明实施例的范围内。更一般地，本领域技术人员将容易领会，本文所描述的所有参数、尺寸、材料和配置意在是示范性的，并且实际参数、尺寸、材料和/或配置将取决于使用了发明教导的一个或多个具体应用。在使用不超过常规的实验方法的情况下，本领域技术人员将认识到或能够确定本文所描述的具体发明实施例的许多等同物。因此，要理解，前述实施例仅以示例的方式呈现，并且在所附权利要求及其等同物的范围内，发明实施例可以按照不同于具体描述和要求保护的方式实施。本公开的发明实施例涉及本文所描述的每个单独的特征、系统、制品、材料、成套工具和/或方法。此外，如果这些特征、系统、制品、材料、成套工具和/或方法不相互矛盾，则两个或更多个这样的特征、系统、制品、材料、成套工具和/或方法的任何组合包括在本公开的发明范围内。

如本文定义和使用的所有定义应当理解为控制字典定义、通过引用并入的文献中的定义、和/或所定义的术语的普通含义。

除非明确相反指示，如本文在说明书和权利要求书中使用的不定冠词“一（a或an）”应当理解为指的是“至少一个”。

如本文在说明书中和在权利要求中使用的短语“和/或”应当被理解成指的是如此结合的要素（即，在一些情况中结合地存在并且在其他情况中分离地存在的要素）中的“任一或两个”。用“和/或”列出的多个要素应当以同样的方式解释，即，如此结合的要素中的“一个或多个”。除了由“和/或”从句具体识别的要素之外的其他要素可以可选地存在，无论与具体识别的那些要素相关还是不相关。因此，作为非限制性示例，当与诸如“包括”的开放式语言结合使用时，对“A和/或B”的引用可以在一个实施例中仅指代A（可选地包括除了B之外的要素）；在另一个实施例中，仅指代B（可选地包括除了A之外的要素）；在又一个实施例中，指代A和B二者（可选地包括其他要素）；等。

如本文在说明书中和在权利要求书中使用的，“或”应当被理解为具有与如上文定义的“和/或”相同的含义。例如，当分离列表中的项目时，“或”或“和/或”应当被解释为是包括性的，即，包括多个要素或要素列表中的至少一个，但是也包括多于一个，以及可选地附加的未列出的项目。仅明确相反地指示的术语，诸如“…的仅仅一个”或“…的恰好一个”，或当在权利要求中使用时，“由……组成”将指代包括多个要素或要素列表中的恰好一个要素。通常，当前缀以诸如“二者中任何一个”、“其中一个”、“仅仅其中一个”或“恰好其中一个”的排他性术语时，如本文中使用的术语“或”应当仅被解释为指示排他性选择（即，“一个或另一个，但不是二者”）。当在权利要求中使用时，“基本上由......组成”应当具有其如在专利法领域中使用的普通含义。

如本文在说明书中和在权利要求书中使用的，在引用一个或多个要素的列表中的短语“至少一个”应当被理解为是指从该要素列表中的任何一个或多个要素中选择的至少一个要素，但是不一定包括在该要素列表中具体列出的每个和各个要素中的至少一个，并且不排除在该要素列表中的要素的任何组合。此定义还允许可以可选地存在除了在短语“至少一个”所指代的要素列表中具体识别的要素之外的要素，无论与具体识别的那些要素相关还是不相关。因此，作为非限制性示例，“A和B中的至少一个”（或等效地，“A或B中的至少一个”，或等效地，“A和/或B中的至少一个”）可以在一个实施例中指代至少一个、可选地包括多于一个A，不存在B（并且可选地包括除了B之外的要素）；在另一个实施例中，指代至少一个、可选地包括多于一个B，不存在A（并且可选地包括除了A之外的要素）；在又一个实施例中，指代至少一个、可选地包括多于一个A，以及指代至少一个、可选地包括多于一个B（并且可选地包括其他要素）；等。

还应当理解，除非明确相反指示，在包括多于一个步骤或动作的本文所要求保护的任何方法中，该方法的步骤或动作的次序不一定限于该方法的该步骤或动作被叙述的次序。

在权利要求中出现在圆括号之间的附图标记是仅为了方便与欧洲专利实践一致而被提供的，并且不应当被解释为以任何方式限制权利要求。

在权利要求中以及在上文说明书中，诸如“包含”、“包括”、“承载”、“具有”、“含有”、“涉及”、“拥有”、“包括有”等的所有过渡性短语要被理解为开放式的，即，指的是包括但不限于。仅仅过渡性短语“由……组成”和“基本上由……组成”应当分别是封闭或半封闭的过渡性短语。

Claims (15)

1.一种用于对凭证进行验证的方法，包括：

在寻求验证照明系统控制器（1352，1452，1552）的凭证的计算设备（1350，1450，1550）处获取所述照明系统控制器的未经验证的凭证；

由所述计算设备经由第一网络通信信道向所述照明系统控制器发送对于验证所述未经验证的凭证的请求；

经由有线或无线网络由所述照明系统控制器向另一远程设备发送基于凭证的数据；

在所述计算设备处经由第二网络通信信道从所述另一远程设备接收验证数据，其中，所述第二网络通信信道与所述第一网络通信信道不同；

由所述计算设备将所述未经验证的凭证与所述验证数据进行比较；

由所述计算设备基于所述比较验证所述未经验证的凭证是合法的；

基于所述验证，由所述计算设备在所述计算设备与所述照明系统控制器之间建立照明信息通信信道；以及

由所述计算设备经由所述照明信息通信信道与所述照明系统控制器交换与一个或多个光源的操作相关的数据或来自一个或多个传感器的数据。

2.根据权利要求1所述的方法，其中，所述第二网络通信信道包括光学无线通信信道，并且所述接收包括在所述计算设备的光传感器处检测经调制的光学无线信号。

3.根据权利要求2所述的方法，其中，所述光学无线通信信道包括可见光通信信道。

4.根据权利要求2所述的方法，其中，所述验证数据是从所述另一远程设备接收到的，并且所述另一远程设备包括连网的灯具（1358，1558）。

5.根据权利要求2所述的方法，其中，所述光学无线通信信道是由所述另一远程设备经由数字显示设备或经由一个或多个基于LED的指示器灯（1356，1456，1556）实现的。

6.根据权利要求2所述的方法，其中，所述第一网络通信信道包括基于射频的通信信道。

7.根据权利要求6所述的方法，其中，所述基于射频的通信信道是使用Wi-Fi、ZigBee或Z-Wave实现的。

8.根据权利要求1所述的方法，其中，所述验证数据包括由所述照明系统控制器或所述另一远程设备生成的所述未经验证的凭证的第一散列，并且所述比较包括：将所述第一散列与由所述计算设备生成的所述未经验证的凭证的第二散列进行比较。

9.根据权利要求1所述的方法，进一步包括：

由所述计算设备设置定时器；以及

由所述计算设备拒绝任何在所述定时器期满之后被接收到的验证数据。

10.根据权利要求1所述的方法，其中，所述验证数据是从所述另一远程设备接收的，并且所述对于验证所述未经验证的凭证的请求包括与所述另一远程设备相关联的标识符。

11.根据权利要求1所述的方法，进一步包括：

由所述计算设备基于从被提供在所述照明系统控制器的表面上的标记中（1557）获取的信息生成秘密密钥；

由所述计算设备基于所述秘密密钥执行加密散列函数以生成第一加密散列函数输出；

由所述计算设备向所述照明系统控制器或所述另一远程设备发送所述第一加密散列函数输出；

由所述计算设备从所述照明系统控制器或所述另一远程设备接收第二加密散列函数输出；以及

由所述计算设备对所述第二加密散列函数输出进行验证；

其中，由所述计算设备向所述照明系统控制器发送对于验证所述未经验证的凭证的请求是基于对所述第二加密散列函数输出进行的所述验证的结果有选择地执行的。

12.一种照明系统控制器（1352，1452，1552），包括一个或多个处理器和与所述一个或多个处理器能够操作地耦合的存储器，其中，所述存储器存储指令，所述指令响应于所述指令由一个或多个处理器执行使所述一个或多个处理器执行以下操作：

经由第一网络通信信道从寻求验证所述照明系统控制器的凭证的远程计算设备（1350，1450，1550）接收对于验证所述照明系统控制器的未经验证的凭证的请求；

经由有线或无线网络由所述照明系统控制器向连网的灯具（1358，1558）发送基于凭证的数据，其中，所述基于凭证的数据是基于所述照明系统控制器的所述凭证的；

其中，在所述连网的灯具处接收到所述基于凭证的数据使所述连网灯具经由与所述第一网络通信信道不同的第二网络通信信道向所述远程计算设备发送所述验证数据，其中，所述验证数据是基于所述基于凭证的数据的；以及

在由所述计算设备将所述未经验证的凭证与所述验证数据进行比较以及由所述计算设备基于所述比较验证所述未经验证的凭证是合法的之后，响应于由所述计算设备基于所述验证在所述计算设备与所述照明系统控制器之间建立照明信息通信信道，经由所述照明信息通信信道与所述远程计算设备交换与一个或多个光源的操作相关的数据或来自一个或多个传感器的数据。

13.根据权利要求12所述的照明系统控制器，其中，所述基于凭证的数据包括使用所述照明系统控制器的所述凭证计算的散列。

14.根据权利要求12所述的照明系统控制器，其中，所述第一网络通信信道包括基于射频的通信信道，并且所述第二网络通信信道包括光学无线通信信道。

15.根据权利要求14所述的照明系统控制器，其中，所述基于射频的通信信道是使用Wi-Fi、ZigBee或Z-Wave实现的。

Images