Могут ли устройства IoT с разными протоколами использовать агентов IoT для «общения» друг с другом? - PullRequest
1 голос
/ 02 февраля 2020

Я играю с FIWARE Orion, агентом IoT JSON и агентом IoT OP C UA. Мне интересно, что, поскольку все агенты IoT соединяются с Orion и отображают различные протоколы IoT в NGSI, возможно ли для устройств, использующих разные протоколы, обмениваться данными друг с другом без добавления каких-либо дополнительных журналов приложений c?

Давайте рассмотрим MQTT-устройство A и OP C UA-сервер B, например, возможно ли: атрибут. Что-то вроде B -> IoT Agent OP C UA -> Orion -> IoT Agent JSON -> mosquitto -> A (Я пытался зарегистрировать провайдера контекста. Однако URL-адрес Атрибуты сущности B (orion:1026/v2/B/attrs/XXX), очевидно, не работают, поскольку Orion отправит POST на orion:1026/v2/B/attrs/XXX/op/query, который не существует), а предоставленный атрибут не предоставлен агенту IoT JSON ... Мне кажется, что я Я иду в совершенно неверном направлении)

A и B получают доступ к одному и тому же объекту и сообщают свои измерения этому объекту в Орионе. Поскольку A и B оба нуждаются в своих собственных агентах IoT, и один и тот же объект не может быть предоставлен каждому агенту из-за дублирования ...

Это очень плохая идея, что попытка испортить один объект с несколькими устройствами протоколов ... Большое спасибо за ответ на мои сомнения заранее !!!

1 Ответ

1 голос
/ 03 февраля 2020

Каждый объект NGSI должен отображаться на что-то, что имеет состояние в реальном мире . В вашем случае ваши модели данных должны основываться на устройстве , и у вас должен быть отдельный объект на основе OP C -UA * Device и второе отдельное устройство JSON сущность. Это низкоуровневые объекты в вашей системе, которые будут хранить показания устройств IoT, а также будут содержать дополнительные данные (например, уровень заряда батареи или ссылку на документацию или что-то еще).

Если вы хотите смоделируйте состояние второй агрегированной сущности, тогда вы также можете сделать это - просто подписаться на изменения в контексте в устройстве и Сохранить значения и метаданные для другой сущности.

curl --location --request POST 'http://localhost:1027/v2/subscriptions/' \
--header 'Content-Type: application/json' \
--header 'fiware-service: openiot' \
--data-raw '{
  "description": "Notify Subscription Listener of Lamp context changes",
  "subject": {
    "entities": [
      {
        "idPattern": "Lamp.*"
      }
    ],
    "condition": {
      "attrs": ["luminosity"]
    }
  },
  "notification": {
    "http": {
      "url": "http://tutorial:3000/device/subscription/luminosity"
    },
    "attrs": ["luminosity", "controlledAsset", "supportedUnits"]
  },
  "throttling": 5
}'

Пример кода для выполнения работы с конечной точки прослушивания (/device/subscription/luminosity) можно найти здесь - это учебное пособие, которое все еще находится в стадии разработки, поэтому полная документация в настоящее время отсутствует.

function shadowDeviceMeasures(req, res) {
  const attrib = req.params.attrib;

  async function copyAttributeData(device, index) {
    await upsertDeviceEntityAsLD(device);
    if (device[attrib]) {
      await upsertLinkedAttributeDataAsLD(device, 'controlledAsset', attrib);
    }
  }

  req.body.data.forEach(copyAttributeData);
  res.status(204).send();
}

Дело в том, что вы можете (и должны) думать о сущностях данных на разных уровнях -

  • У меня есть термометр Устройство - это отправка показаний температуры. У него есть атрибут temperature
  • У меня есть Здание - в нем есть термометр - Здание имеет атрибут temperature и metadata.providedBy обратная связь с устройством

В зависимости от вашего варианта использования вам может потребоваться рассмотреть объекты только на одном слое или вам может понадобиться использовать оба.

...