设备、配置和状态

设备注册

如需连接设备，必须先在设备管理器中注册设备。通过设备管理器，您可以创建和配置设备注册表及其中的设备。您可以通过 Cloud Platform Console、gcloud 命令或 REST 样式 API 使用设备管理器。

设备注册表

设备注册表是设备的容器。

每个设备注册表都是在特定云区域中创建的，属于一个云项目。
域名注册管理机构在 cloudiot.googleapis.com 服务中由其全名标识为：projects/{project-id}/locations/{cloud-region}/registries/{registry-id}。
设备注册表配置了一个或多个 Cloud Pub/Sub 主题，该注册表中所有设备的遥测事件会发布到这些主题。单个主题可用于收集所有区域的数据。
系统会为每个注册表自动启用 Stackdriver Monitoring。
Identity and Access Management (IAM) 可用于访问权限控制，授予用户查看、配置或完全管理设备的权限。请注意，Cloud IoT Core 会自动为每个项目授予对应的服务帐号 cloudiot.serviceAgent 角色，以便将其发布到 Pub/Sub 主题。
如需了解设备注册表 ID 命名和大小要求，请参阅允许使用的字符和大小要求。

如需了解详情，请参阅 DeviceRegistry 资源参考文档。

设备

在注册表中创建设备时，您要将其定义为 Cloud IoT Core 资源。然后，您就可以查看设备详细信息并控制部分属性。

可以阻止设备与 Cloud IoT Core 通信。当传感器出现故障或设备配置错误时，此功能非常有用。
设备时间戳显示最近一次收到的检测信号和遥测事件。
每台设备都可以通过完整的资源名称来识别：projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-id} 或 projects/{project-id}/locations/{cloud-region}/registries/{registry-id}/devices/{device-numeric-id}。如需详细了解设备 ID 和设备数字 ID，请参阅下一部分。

有关详情，请参阅设备资源参考。

使用设备时，请务必遵守 Cloud IoT Core 配额和限制。

设备标识符

每台设备都具有以下标识符：

用户定义的设备 ID。如需详细了解设备 ID 的命名和尺寸要求，请参阅允许使用的字符和尺寸要求。
服务器生成的设备数字 ID。设备数字 ID 由 Cloud IoT Core 自动创建；具有全局唯一性，且无法修改。要查看设备数字 ID，请转到设备详细信息页面。
设备的完整路径（如上一部分中所述）。

设备元数据

您可以定义设备的元数据，例如硬件指纹、序列号、制造商信息或任何其他属性。Cloud IoT Core 不会解读设备元数据或将其编入索引。理论上，设备元数据比设备状态或设备配置更安全，因为设备元数据绝不会发送到设备或从设备发送。也就是说，如果设备遭到入侵，就无法读取设备元数据。

设备元数据不应经常更改；为获得最佳效果，每天更新的频率不应超过一次。

在添加或修改设备时，您最多可以定义 500 个键值对。每个键必须是唯一的。

如需了解有关设备元数据键值对命名和大小要求的信息，请参阅允许使用的字符和大小要求。

设备配置

借助 Cloud IoT Core，您可以通过发送设备配置来控制设备。设备配置是从 Cloud IoT Core 发送到设备的任意用户定义的 blob 数据。数据可以是结构化数据，也可以是非结构化数据。它还可以是任何格式，例如任意二进制数据、文本、JSON 或序列化协议缓冲区。

设备配置会由 Cloud IoT Core 保存在存储空间中。配置数据的大小上限为 64 KB。如需了解其他限制，请参阅配额和限制。

为获得最佳效果，设备配置应侧重于所需的值或结果，而不是一系列命令。如果您指定了命令，则中间配置版本可能会产生冲突，并且无法恢复设备的状态（自设备首次初始化以来，不会执行每个命令序列）。如果您的配置强调值和结果，您将可以更轻松地恢复设备状态。

配置版本

MQTT 网桥

对于给定的 MQTT 连接，设备仅按版本号递增顺序接收配置；换句话说，系统绝不会向它发送早于当前版本的配置。但是，如果设备重新连接到 MQTT 网桥，可能会收到比较早连接期间收到的配置还要早的配置（但这种情况应该很少见，并且设备最终会收到最新版本）。

请注意，不能保证设备会收到所有配置更新；而是始终接收最新更新。如果配置正在快速更新，设备可能不会收到中间版本。

修改设备配置时，您可以指定要修改的版本号。这样做可以防止覆盖并发更改的配置。

HTTP 网桥

通过 HTTP 连接的设备可以指定本地版本（设备上的配置版本）。如 HTTP 网桥部分所述，Cloud IoT Core 将仅返回较新的版本。

设备状态

设备状态信息捕获设备的当前状态，而不是环境。设备可以使用从设备发送到云端的任意用户定义的数据 blob 描述其状态。数据可以是结构化数据，也可以是非结构化数据。它还可以是任何格式，例如二进制数据、文本、JSON 或序列化协议缓冲区。

设备状态的一些示例包括设备的运行状况或其固件版本。通常情况下，设备状态信息不会经常更新。

设备元数据、配置和状态之间的差异

通过结合使用配置和状态，您可以回答如下问题：设备目前“认为”它应该做什么？与设备的最新配置相比，该功能如何？相比之下，元数据主要用作设备的标签或标识符。

配置数据会从 Cloud IoT Core 发送到设备。状态数据由设备发送到 Cloud IoT Core。您可以将配置视为发送到设备的外部指令，并将状态视为设备的内部表示法。配置和状态数据可以具有相同的架构和编码，也可以不同。

因为设备元数据保留在云中，所以进出设备的信息不应存储为设备元数据。如果需要将该信息发送到设备，则应将其存储在设备配置中；如果您需要将该信息报告回 Cloud IoT Core，则应将其存储在设备状态数据中。

以下示例说明了在建筑物中使用设备时元数据、配置和状态的不同用法：

假设建筑物的每层都有多个设备。为了识别第 7 层的设备，您可以向第 7 层的设备添加 'floor': '7' 元数据键值对。应用这些元数据信息有助于识别设备，但由于元数据不会被解读或编入索引，因此元数据只能用于识别设备。
如果您想更改建筑物中设备的状态，可以向每台设备发送设备配置。此配置将包含任意数据 blob，其中包含设备所需的温度以及设备的指示灯是处于开启还是关闭状态：
```
{
  temperature: 50
  lights: off
}
```
单独该配置不会改变设备的温度或打开/关闭其灯；设备负责解读配置并使用自己的逻辑来执行命令。在接下来的几个小时内，设备配置将保持不变（除非您更新并发送新配置），但设备的状态应该会随着温度的增加或下降以及设备指示灯的改变而改变关闭。
为了验证配置是否已正确应用以及设备是否处于正确状态，每台设备都可以向 Cloud IoT Core 报告其状态（开关状态、温度是多少度、温度低于或等于 50 度）。

下表显示了设备元数据、配置和状态之间的主要差异：

	设备元数据	设备配置	设备状态
说明	对设备进行定义和分类	通过将预期状态作为配置发送来更新设备状态通过在配置中提供命令来控制设备	捕获设备的当前状态
内容	键值字符串对	用户定义的任意数据 blob	用户定义的任意数据 blob
限制	键：允许的字符：`[a-zA-Z][-a-zA-Z0-9._+~%]+` 第一个字符必须是字母 (`[a-zA-Z]`) 长度下限：1 个字符长度上限：128 个字符值：大小下限：0 KB 大小上限：32 KB 所有设备元数据键值对的最大总大小：256 KB	大小上限：64 KB 每台设备的 QPS 限制为 1	大小上限：64 KB 每台设备的 QPS 限制为 1
使用场景	将设备的序列号和制造商信息存储为键值对	发送包含固件版本的配置，以告知设备其固件版本向设备发送重新启动命令	检索设备的健康状况（例如崩溃频率）
邮件指向	无	仅限 Cloud IoT Core 到设备	仅限设备到 Cloud IoT Core
建议的频率	每台设备每天不超过一次	低于 0.1 QPS	低于 0.1 QPS

使用配置数据更改设备行为或状态

如上表中所述，配置数据的主要用例如下：

将设备的预期状态作为配置发送
向设备发送命令

以配置数据的形式发送所需状态

Cloud IoT Core 中存储的设备配置数据可用于更改设备状态。例如，假设设备配置的配置如下所示：

DeviceConfig

{
    firmwareVersionRequest: 1.11
}

您的 MQTT 或 HTTP 客户端可以将此配置数据解读为用于更改设备状态的说明，在这种情况下，请检查设备是否为固件版本 1.11。然后，设备可将其状态发送到 Cloud IoT Core，以显示其固件版本：

DeviceState

{
    firmwareVersion: 1.11
}

使用配置和状态数据为命令建模

Cloud IoT Core 中存储的设备配置数据可用于为设备命令建模。例如，假设设备配置的配置如下所示：

DeviceConfig

{
  rebootRequested: true
}

您的 MQTT 或 HTTP 客户端可以将此配置数据解读为执行操作的说明，在本例中，发送重新启动命令。然后，设备可以报告其状态并显示自上次重新启动以来经过了一秒，从而显示结果：

DeviceState

{
  last_reboot: 1
}

构建配置数据

配置数据也可以更加结构化，并且可以包含命令到期的详细信息：

DeviceConfig

{
  commands: {
    id1: {
      type: REBOOT
      requestedTimestamp: xxxx
      expirationTimestamp: yyyy
    }
    id2: ...
  }
}

您的客户端可以读取这些命令并相应地更新设备状态，从而提供重新启动的时间戳和可能的错误消息。

DeviceState

{
  commandResults: {
    id1: {
      type: REBOOT
      completedTimestamp: zzzz
      errorMessage: >empty<
    }
    id2: ...
  }
}