跳转至

设备配置文件

概述

租户管理员可以使用设备配置文件为多个设备配置通用设置。每个设备在单个时间点都有一个且唯一的配置文件。

经验丰富的 YiCONNECT 用户可能会注意到，设备类型已被弃用，取而代之的是设备配置文件。更新脚本将根据独特的设备类型自动创建设备配置文件并将其分配给适当的设备。

让我们一一看看设备配置文件中可用的设置。

设备配置文件设置

规则链

默认情况下，根规则链处理任何设备的所有传入消息和事件。但是，您拥有的设备类型越多，您的根规则链可能会变得越复杂。许多平台用户创建根规则链的唯一目的是根据设备类型向特定规则链发送消息。

为了避免这种痛苦而平凡的活动，您可以为您的设备指定自定义规则链。新的规则链将接收所有遥测、设备活动（活动/非活动）和设备生命周期（创建/更新/删除）事件。此设置可在设备配置文件向导和设备配置文件详细信息中找到。

图像

队列名称

默认情况下，主队列将用于存储来自任何设备的所有传入消息和事件。传输层将向该队列提交消息，规则引擎将轮询队列以获取新消息。但是，对于多个用例，您可能希望为不同的设备使用不同的队列。例如，您可能希望单独火灾报警/烟雾探测器传感器和其他设备的数据处理。这样，即使您的系统有数百万个水表产生的峰值负载，每当报告火灾警报时，都会立即得到处理。队列的分离还允许您定制不同的提交和处理策略。

此设置可在设备配置文件向导和设备配置文件详细信息中找到。

文档信息图标请注意： 如果您选择使用自定义队列，则应在使用前与系统管理员进行配置。

图像

运输配置

当前版本的 YiCONNECT 平台支持以下传输类型：Default、MQTT、CoAP、LWM2M 和 SNMP

图像

默认传输类型

默认传输类型旨在向后兼容以前的版本。使用默认传输类型，您可以继续使用平台的默认MQTT、HTTP、CoAP和LwM2M API 来连接您的设备。默认传输类型没有特定的配置设置。

MQTT 传输类型

MQTT 传输类型启用高级 MQTT 传输设置。现在，您可以为分别对应于 遥测上传 API和属性更新 API的时间序列数据和属性更新指定自定义 MQTT 主题过滤器。

MQTT 传输类型具有以下设置：

MQTT 设备主题过滤器

自定义 MQTT 主题过滤器支持单个“ + ”和多级“ # ”通配符，并允许您连接到几乎任何使用 JSON 或 Protobuf 发送有效负载的基于 MQTT 的设备。

图像

使用下图中的配置将允许您通过以下命令发布时间序列数据：

mosquitto_pub -h 'demo.yiqisoft.cn' -i 'c1' -u 't1' -P 'secret' -t '/telemetry' -m '{"humidity": 10.3}'

并使用以下命令更新属性：

mosquitto_pub -h 'demo.yiqisoft.cn' -i 'c1' -u 't1' -P 'secret' -t '/attributes' -m '{"firmwareVersion": "1.3"}'

让我们看一个例子：

  • 步骤 1. 在设备配置文件中指定 MQTT 设备主题过滤器。
  • 步骤 2. 使用客户端 ID“c1”、用户名“t1”和密码“secret”为您的设备提供基本 MQTT 凭据。
  • 步骤 3. 使用Terminal发布时序数据。
  • 步骤 4. 传输的数据将显示在设备的“最新遥测”选项卡中。

步骤 1. 在设备配置文件中指定 MQTT 设备主题过滤器。

步骤 2. 使用客户端 ID“c1”、用户名“t1”和密码“secret”为您的设备提供基本 MQTT 凭据。

步骤 3. 使用Terminal发布时序数据。

步骤 4. 传输的数据将显示在设备的“最新遥测”选项卡中。

MQTT 设备负载

默认情况下，平台希望设备通过 JSON 发送数据。但是，也可以通过Protocol Buffers发送数据

Protocol Buffers（或 Protobuf）是一种与语言和平台无关的结构化数据序列化方式。可以方便地最小化传输数据的大小。

YiCONNECT 平台的当前版本支持用于遥测上传 和属性上传的可定制原型模式，并实现了为下行消息（RPC 调用和属性更新）定义模式的功能。

图像

图像

YiCONNECT 动态解析 protobuf 结构，这就是为什么它还不支持一些 protobuf 功能，如 OneOf、扩展和映射。

与其他有效负载格式的兼容性

启用后，平台将默认使用 Protobuf 有效负载格式。如果解析失败，平台将尝试使用 JSON 负载格式。对于固件更新期间的向后兼容性很有用。例如，初始版本的固件使用 Json，而新版本使用 Protobuf。在设备群的固件更新过程中，需要同时支持 Protobuf 和 JSON。

兼容模式会带来轻微的性能下降，因此建议在所有设备更新后禁用此模式。

图像

CoAP传输类型

CoAP 传输类型启用高级 CoAP 传输设置。通过 CoAP 传输类型，您可以选择 CoAP 设备类型。

图像

CoAP 设备类型：默认

默认情况下，CoAP 设备类型 默认将 CoAP 设备有效负载设置为 JSON，支持与默认传输类型相同的基本CoAP API。但是，也可以通过将 CoAP 设备有效负载参数更改为 Protobuf，通过Protocol Buffers发送数据。

Protocol Buffers（或 Protobuf）是一种与语言和平台无关的结构化数据序列化方式。可以方便地最小化传输数据的大小。

YiCONNECT 平台的当前版本支持用于遥测上传定义模式的功能。

图像

图像

YiCONNECT 动态解析 protobuf 结构，这就是为什么它还不支持一些 protobuf 功能，如 OneOf、扩展和映射。

CoAP 设备类型：Efento NB-IoT

YiCONNECT 平台的当前版本支持与下一代 Efento NB-IoT 传感器集成：

  • 温度，
  • 湿度，
  • 空气压力，
  • 不同的压力，
  • 开关，
  • 泄漏，
  • 输入/输出。

需要固件版本为 06.02+ 的 Efento 设备。

图像

报警规则

平台用户可以使用规则引擎来配置警报。规则引擎是一个相当强大的功能，但它需要一些编程技能。从 YiCONNECT 3.2 开始，我们引入了警报规则来简化配置最流行警报类型的过程。现在您不需要成为规则引擎专家来配置您的处理逻辑。在底层，规则引擎使用“设备配置文件”规则节点评估警报规则。

警报规则由以下属性组成：

  • 警报类型 - 警报的一种类型。报警类型在设备配置文件报警规则内必须是唯一的；
  • 创建条件 - 定义创建/更新警报的条件。该条件由以下属性组成：
  • 严重性 - 将用于创建/更新警报。YiCONNECT 按严重性降序验证创建条件。例如，如果严重程度为“严重”的情况为真，则平台将发出严重程度为“严重”的警报，而不会评估“严重”、“轻微”或“警告”条件。每个警报规则的严重性必须是唯一的（例如，在同一警报规则中创建的两个条件不能具有相同的严重性）；
  • 关键过滤器 - 针对属性或遥测值的逻辑表达式列表。例如，“(温度 < 0 OR 温度 > 20) AND softwareVersion = '2.5.5'“ ;
  • 条件类型 - 简单、持续时间或重复。例如，连续 3 次或 5 分钟内 。简单条件一旦第一个匹配事件发生就会发出警报；
  • 时间表 - 定义规则处于活动状态的时间间隔。“一直活跃”、“特定时间活跃”或“自定义”；
  • 详细信息 - 警报详细信息模板支持使用 ${attributeName} 语法替换遥测或属性值；
  • 清除条件 - 定义清除警报的条件；
  • 高级设置 - 定义向相关资产、客户、租户或其他实体传播警报。

让我们通过示例来了解如何使用警报规则。假设我们想要跟踪冰箱内贵重物品的温度。 我们还假设我们已经创建了一个名为“温度传感器”的设备配置文件，并为我们的设备配置了温度传感器和访问令牌 - “ACCESS_TOKEN”。下面列出的命令将温度读数上传到 .

mosquitto_pub -d -h 'demo.yiqisoft.cn' -t "v1/devices/me/telemetry" -u "$ACCESS_TOKEN" -m '{"temperature": 5.3}'

示例 1. 简单报警条件

我们希望在温度高于 10 度时创建严重警报。

  • 步骤 1. 打开设备配置文件并切换编辑模式。
  • 步骤2.点击“添加报警规则”按钮。
  • 步骤3.输入警报类型并单击红色“+”号。
  • 步骤 4. 单击“添加密钥过滤器”按钮。
  • 步骤 5. 选择“Timeseries”密钥类型。输入“温度”键名称。将“值类型”更改为“数字”。单击“添加”按钮。
  • 步骤6.选择“大于”运算并输入阈值。单击“添加”。
  • 步骤7. 单击“保存”按钮。
  • 步骤 8. 最后，应用更改。

步骤 1. 打开设备配置文件并切换编辑模式。

步骤2.点击“添加报警规则”按钮。

步骤3.输入警报类型并单击红色“+”号。

步骤 4. 单击“添加密钥过滤器”按钮。

步骤 5. 选择“Timeseries”密钥类型。 输入“温度”键名称。 将“值类型”更改为“数字”。 单击“添加”按钮。

步骤6.选择“大于”运算并输入阈值。 单击“添加”。

步骤7. 单击“保存”按钮。

步骤 8. 最后，应用更改。

示例 2. 具有持续时间的警报条件

假设我们想要修改示例 1，仅当温度超过特定阈值 1 分钟时才发出警报。

为此，我们需要编辑报警条件，并将条件类型从“简单”修改为“持续时间”。我们还应该指定持续时间值和单位。

  • 步骤1.编辑警报条件并将条件类型更改为“持续时间”。指定持续时间值和单位。保存条件。
  • 步骤 2. 应用更改。

步骤1.编辑警报条件并将条件类型更改为“持续时间”。 指定持续时间值和单位。 保存条件。

步骤 2. 应用更改。

现在，假设您希望将 1 分钟持续时间替换为动态值，该值取决于特定设备、客户或租户的设置。

为此，您应该使用服务器端属性功能。

请为您的设备创建一个值为“1”的服务器端属性“highTemperatureDurationThreshold” 。

  • 步骤3. 编辑报警条件。按“切换到动态值”按钮转到报警延迟的动态值；
  • 步骤 4. 选择一个值：当前设备、当前客户或当前租户。并指定将从哪个属性获取警报阈值。您可以选择选中“从所有者继承”。如果未在设备级别设置阈值，则继承允许从客户获取阈值。如果设备和客户级别均未设置属性值，则规则将从租户属性中获取值；
  • 步骤 5. 应用所有更改。

步骤3. 编辑报警条件。 按“切换到动态值”按钮转到报警延迟的动态值；

步骤 4. 选择一个值：当前设备、当前客户或当前租户。 并指定将从哪个属性获取警报阈值。 您可以选择选中“从所有者继承”。 如果未在设备级别设置阈值，则继承允许从客户获取阈值。 如果设备和客户级别均未设置属性值，则规则将从租户属性中获取值；

步骤 5. 应用所有更改。

示例 3. 重复报警条件

假设我们想要修改示例 1，仅当传感器报告温度连续 3 次超过阈值时才发出警报。

为此，我们需要编辑报警条件，并将条件类型从“简单”修改为“重复”。我们还应该指定“3”作为“事件计数”。

  • 步骤1.编辑报警条件并将条件类型更改为“重复”。指定“3”作为“事件计数”以触发警报。如果您的设备没有设置属性，则默认使用此值。保存条件。
  • 步骤 2. 应用更改。

步骤1.编辑报警条件并将条件类型更改为“重复”。 指定“3”作为“事件计数”以触发警报。 如果您的设备没有设置属性，则默认使用此值。 保存条件。

步骤 2. 应用更改。

现在，假设您希望将超过警报条件的设定次数替换为动态值，该值取决于特定设备、客户或租户的设置。

为此，您应该使用服务器端属性功能。

请为您的设备创建一个服务器端属性 “highTemperatureRepeatingThreshold” ，其值为整数 “3” 。

  • 步骤4.按“切换到动态值”按钮转到重复报警条件的动态值；
  • 步骤 5. 选择一个值：当前设备、当前客户或当前租户。并指定从中获取值的属性，必须超过阈值多少次才能触发警报。您可以选择选中“从所有者继承”。如果未在设备级别设置阈值，则继承允许从客户获取阈值。如果设备和客户级别均未设置属性值，则规则将从租户属性中获取值；
  • 步骤 6. 应用所有更改。

步骤4.按“切换到动态值”按钮转到重复报警条件的动态值；

步骤 5. 选择一个值：当前设备、当前客户或当前租户。 并指定从中获取值的属性，必须超过阈值多少次才能触发警报。 您可以选择选中“从所有者继承”。 如果未在设备级别设置阈值，则继承允许从客户获取阈值。 如果设备和客户级别均未设置属性值，则规则将从租户属性中获取值；

步骤 6. 应用所有更改。

示例4.清除报警规则

假设我们希望在冰箱内的温度恢复正常时自动清除警报。

  • 步骤 1. 打开设备配置文件并切换编辑模式。单击“添加清除条件”按钮。
  • 步骤 2. 单击红色“+”号。
  • 步骤 3. 添加密钥过滤器。然后单击添加。
  • 步骤4.保存报警规则条件。
  • 步骤 4. 最后，应用更改。

步骤 1. 打开设备配置文件并切换编辑模式。 单击“添加清除条件”按钮。

步骤 2. 单击红色“+”号。

步骤 3. 添加密钥过滤器。 然后单击添加。

步骤 4. 最后，应用更改。

示例 5. 定义警报规则计划

假设我们希望警报规则仅在工作时间内评估警报。

  • 步骤1.编辑报警规则的排程。
  • 步骤2.选择时区、天数、时间间隔，然后单击“保存”。
  • 步骤 3. 最后，应用更改。

步骤1.编辑报警规则的排程。

步骤2.选择时区、天数、时间间隔，然后单击“保存”。

步骤 3. 最后，应用更改。

示例 6. 高级阈值

假设我们希望用户能够从仪表板 UI 覆盖阈值。我们还可以添加标志来启用或禁用每个设备的某些警报。为此，我们将在警报规则条件中使用动态值。我们将使用两个属性：布尔温度AlarmFlag和数字 温度AlarmThreshold 。我们的目标是当“ TemperatureAlarmFlag = True AND温度大于TemperatureAlarmThreshold ”时触发警报创建。

  • 步骤1.修改温度键过滤器并将值类型更改为动态。
  • 步骤2.选择动态源类型并输入温度警报阈值，然后单击“更新”。您可以选择选中“从所有者继承”。如果未在设备级别设置阈值，则继承允许从客户获取阈值。如果未在设备和客户级别上设置属性值，则规则将从租户属性中获取值。
  • 步骤 3. 为 TemperatureAlarmFlag 添加另一个关键过滤器，然后单击“添加”。
  • 步骤 4. 最后，单击“保存”并应用更改。
  • 步骤 5. 手动或通过脚本配置设备属性。

步骤1.修改温度键过滤器并将值类型更改为动态。

步骤2.选择动态源类型并输入温度警报阈值，然后单击“更新”。 您可以选择选中“从所有者继承”。 如果未在设备级别设置阈值，则继承允许从客户获取阈值。 如果未在设备和客户级别上设置属性值，则规则将从租户属性中获取值。

步骤 3. 为TemperatureAlarmFlag 添加另一个关键过滤器，然后单击“添加”。

步骤 4. 最后，单击“保存”并应用更改。

步骤 5. 手动或通过脚本配置设备属性。

示例 7. 基于租户或客户属性的动态阈值

示例 6 演示了如何根据设备的“TemperatureAlarmFlag”属性的值启用或禁用规则。但是，如果您想为属于租户或客户的所有设备启用或禁用某些规则，该怎么办？为了避免为每个设备配置属性，您可以配置报警规则以将常量值与租户或客户属性的值进行比较。为此，您应该使用“Constant”键类型并将其与动态值进行比较。请参见下面的配置示例：

  • 选择常量类型和值，并将其与租户或客户属性的值进行比较。应用所有更改。

选择常量类型和值，并将其与租户或客户属性的值进行比较。 应用所有更改。

上述技术可用于启用或禁用规则或将设备遥测/属性上的过滤器与租户或客户属性上的过滤器组合起来。

设备配置文件规则节点

设备配置文件规则节点根据设备配置文件中定义的警报规则创建和清除警报。默认情况下，这是处理链中的第一个规则节点。规则节点处理所有传入消息并对属性和遥测值做出反应。

图像

规则节点中有两个重要的设置：

保留警报规则的状态 - 强制规则节点存储处理状态。默认禁用。如果您有持续时间或重复条件，则此设置非常有用。假设您有一个条件“温度大于 50 度持续 1 小时”，并且第一个温度大于 50 度的事件是在下午 1 点报告的。下午 2 点您应该会收到警报（假设温度条件不会改变）。但是，如果您将在下午 1 点之后和下午 2 点之前重新启动服务器，则规则节点需要从 DB 中查找状态。基本上，如果启用此选项和“获取警报规则状态”选项，规则节点将能够发出警报。如果禁用它，规则节点将不会生成警报。出于性能原因，我们默认禁用此设置。如果启用，并且传入消息至少与其中一个警报条件匹配，则会导致额外的写入操作持续处于该状态。

获取警报规则的状态 - 强制规则节点恢复初始化时的处理状态。默认禁用。如果您有持续时间或重复条件，则此设置非常有用。它应与“保留警报规则状态”选项配合使用，但在极少数情况下，您可能希望在启用“保留警报规则状态”选项时禁用此设置。假设您有许多频繁或持续发送数据的设备，您可以避免在初始化时从数据库加载状态。当来自特定设备的第一条消息到达时，规则节点将从数据库中获取状态。

图像

有关警报的通知

假设您已配置警报规则，您可能还希望在 YiCONNECT 创建或更新警报时收到通知。设备配置文件规则节点具有三种可供您使用的主要出站关系类型：“警报已创建”、“警报严重性已更新”和“警报已清除”。请参阅下面的示例规则链。在继续操作或在规则节点中配置您自己的设置之前，请确保系统管理员已配置短信/电子邮件提供商。

您还可以使用现有指南： 在警报时发送电子邮件（使用解释“发送电子邮件”和“发送电子邮件”节点的部分）或Telegram 通知。还有一个附加的“警报已更新”关系类型，在大多数情况下应忽略该关系类型，以避免重复通知。

图像

设备配置

设备配置允许设备在制造期间或制造后自动在 YiCONNECT 中注册。 有关更多详细信息，请参阅独立的文档页面。