固件实体和 STH

Question

我正在使用 Orion Context Broker、物联网代理和 Cygnus 来处理多个设备的数据并将其保存到 MongoDB 中。它正在工作，但我不知道我是否以 Fiware 的方式这样做，因为在阅读文档后我对某些事情感到困惑：

我不完全理解实体和物联网实体（或设备？）之间的区别。我的猜测是，这与他们如何提供上下文数据和建模实体的性质有关，但如果有人能澄清一下，我将不胜感激。我特别困惑，因为每个实体类型的创建都是不同的（似乎我无法在创建时初始化 IoT 实体，而在处理常规实体时我可以）。
我只能持久化物联网实体的数据。是否可以拥有常规实体的短期历史记录？
我不明白为什么 STH 数据重复没有改变的属性。如果我有一个具有两个属性 'a' 和 'b' 的 IoT 实体，并且我修改了这两个属性，则会为每个属性创建一个 STH 条目，这很好。但是，如果我随后更改属性 'b' 的值，则会创建另外两个寄存器：一个用于 'a'（它没有改变并且反映的是它已经具有的相同值）和一个用于 'b'。有人可以向我解释这种行为吗？

Answer 1

1.实体与物联网实体

我假设您所说的 IoT 实体是指 IoT 代理在收到来自配置设备的传感器读数后所做的输入。

从逻辑上讲，物联网代理创建和维护的实体与向上下文代理发出 NGSI 请求的任何其他服务创建和维护的实体之间没有区别。

您的 so-called IoT 实体仅仅是一个构造，其中 IoT 代理为您完成所有繁重的工作，并将来自设备的数据以适当的格式转换为 NGSI 标准。

2。常规实体的短期历史

要创建短期历史记录，您需要一个单独的通用启动器，例如 STH-Comet 或 QuantumLeap。这两个启用程序都使用订阅机制从 Orion 接收更新。如果您使用一个 fiware-service header 设置您的物联网数据并使用另一个 fiware-service 设置您的 non-IoT 数据，您可以轻松设置订阅以区分两者。

例如以下订阅：

curl -iX POST \
  'http://localhost:1026/v2/subscriptions/' \
  -H 'Content-Type: application/json' \
  -H 'fiware-service: iotdata' \
  -H 'fiware-servicepath: /' \
  -d '<body>'

将仅适用于具有 iotdata 服务路径的实体，该路径将在您配置 IoT 服务时创建。

3。重复未更改的属性。

订阅的<body>可以用来缩小历史数据持久化的条件

entities、conditions和attrs是subject

的重要组成部分

subject": {
    "entities": [
      {
        "idPattern": "Motion.*"
      }
    ],
    "condition": {
      "attrs": [
        "count"
      ]
    }
  },
  "notification": {
    "http": {
      "url": "http://quantumleap:8668/v2/notify"
    },
    "attrs": [
      "count"
    ],
    "metadata": ["dateCreated", "dateModified"]
  },
  "throttling": 1
}'

上面定义的订阅只有在 count 属性改变时才会触发，并且只保留 count 属性。如果你不限制你的 attrs 那么多行将被保存到数据库中。同样，如果您不限制 condition，那么 count 的多个条目将在更新其他属性时保留。

固件实体和 STH

Fiware Entities and STH

entity

fiware

fiware-cygnus