Fiware实体和STH

时间:2018-12-12 09:18:50

标签: entity fiware fiware-cygnus

我正在使用Orion上下文代理,IoT代理和Cygnus来处理并将多个设备的数据持久化到MongoDB中。它正在工作,但是我不知道我是否正在以Fiware的方式进行操作,因为在阅读了文档之后,我对某些事情感到困惑:

  1. 我不完全了解实体和IoT实体(或设备?)之间的区别。我的猜测是这取决于它们如何提供上下文数据以及所建模实体的性质,但是如果有人可以澄清它,我将不胜感激。我特别困惑,因为每种实体类型的创建都是不同的(似乎我无法在创建时初始化IoT实体,而在处理常规实体时可以做到)。
  2. 我只能保留IoT实体的数据。可能有常规实体的短期历史记录吗?
  3. 我不明白为什么STH数据会重复未更改的属性。如果我有一个具有两个属性“ a”和“ b”的物联网实体,并且我都对其进行了修改,则为每个属性创建一个STH条目,这很好。但是,如果然后我更改属性“ b”的值,则会再创建两个寄存器:一个用于“ a”(未更改,并且反映了已经具有的相同值),另一个用于“ b”。有人可以向我解释这种行为吗?

1 个答案:

答案 0 :(得分:0)

1。实体与物联网实体

我假设IoT实体的意思是IoT代理在收到来自已调配设备的传感器读数后所做的输入。

逻辑上,由IoT代理创建和维护的实体与由向上下文代理发出NGSI请求的任何其他服务创建和维护的实体之间没有区别。

您所谓的IoT实体仅仅是IoT代理为您完成所有繁重工作并将来自设备的数据以专有格式转换为NGSI标准的结构。

2。常规实体的短期历史记录

要创建短期历史记录,您将需要单独的通用启动器,例如STH-Comet或QuantumLeap。这两个启用器都使用订阅机制从Orion接收更新。如果您使用一个fiware-service标头设置IoT数据,并使用另一个fiware-service设置非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>可用于缩小保留历史数据的条件。

entitiesconditionsattrssubject的重要部分

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的多个条目将保留。