Fiware Entities и STH - PullRequest
       28

Fiware Entities и STH

0 голосов
/ 12 декабря 2018

Я использую контекстный брокер Orion, агент IoT и Cygnus для обработки и сохранения данных нескольких устройств в MongoDB.Это работает, но я не знаю, делаю ли я это с помощью Fiware, потому что после прочтения документации я все еще запутался в некоторых вещах:

  1. Я не до конца понимаю разницумежду сущностью и сущностью IoT (или устройством?).Я предполагаю, что это вопрос того, как они предоставляют контекстные данные и характер моделируемой сущности, но я был бы признателен, если бы кто-то смог это прояснить.Я особенно озадачен, потому что создание каждого типа сущности отличается (кажется, что я не могу инициализировать сущность IoT во время создания, что я могу при работе с обычной сущностью).
  2. Я могу только настаиватьданные IoT Entities.Возможно ли иметь кратковременную историю обычного субъекта?
  3. Я не понимаю, почему данные STH повторяют атрибуты, которые не изменились.Если у меня есть IoT-сущность с двумя атрибутами, «a» и «b», и я изменяю оба из них, для каждого из них создается запись STH, что нормально.Однако, если затем я изменю значение атрибута «b», будут созданы еще два регистра: один для «a» (который не изменился и отражает то же значение, которое у него уже было) и один для «b».Может ли кто-нибудь объяснить мне это поведение?

1 Ответ

0 голосов
/ 20 декабря 2018

1.Сущности против сущностей IoT

Я полагаю, что вы подразумеваете под сущностью IoT запись, сделанную агентом IoT при получении показаний датчика от подготовленного устройства.

Логически существуетнет разницы между объектом, созданным и поддерживаемым агентом IoT, и объектом, созданным и поддерживаемым любой другой службой, отправляющей запрос NGSI посреднику контекста.

Ваш так называемый IoT-объект - это просто конструкция, в которой агент IoT выполняет всю тяжелую работу за вас и преобразует данные, поступающие с устройства в примирительном формате, в стандарт NGSI.

2.Краткосрочная история обычной сущности

Для создания краткосрочной истории вам понадобится отдельный общий активатор, такой как STH-Comet или QuantumLeap.Оба эти активатора получают обновления от Orion, используя механизм подписок.Если вы настроили свои данные IoT, используя один заголовок fiware-service, а свои не-IoT данные, используя другой fiware-service, вы можете легко настроить подписку, чтобы различать их.

, например, следующая подписка:

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 будут сохранены при обновлении других атрибутов.

...