IoT Hub. Передача телеметрии. Урок 1.

Изучение работы с IoT Hub не стоит начинать с развертывания Microsoft IoT Solution Accelerator. В его состав включено много компонентов, которые усложняют понимание и приводят к быстрому расходованию средств на Azure Trial.

Передача телеметрии в IoT Hub

Для начала передадим в облако IoT Hub телеметрическую информацию с симулятора устройства. У Microsoft на этот счет имеется простой пример датчика температуры.

Первое консольное приложение передает поток данных, а второе принимает данные в облаке IoT Hub, отображая принятое сообщение и информацию о нём.

Передача сообщений происходит с помощью пары строк кода:

// Connect to the IoT hub using the MQTT protocol
DeviceClient s_deviceClient = DeviceClient.CreateFromConnectionString(s_connectionString, TransportType.Mqtt);
SendDeviceToCloudMessagesAsync();

s_connectionString — параметр получается через Azure CLI командой:

$hub_name = "SchneiderEq"
az iot hub device-identity show-connection-string --hub-name $hub_name --device-id MyDotnetDevice --output table

где MyDotnetDevice — имя созданного в примере устройства.

Параметр TransportType задает тип используемого протокола для передачи данных телеметрии:

Amqp 0 Advanced Message Queuing Protocol transport. Try Amqp over TCP first and fallback to Amqp over WebSocket if that fails
Amqp_Tcp_Only 3 Advanced Message Queuing Protocol transport over native TCP only
Amqp_WebSocket_Only 2 Advanced Message Queuing Protocol transport over WebSocket only.
Http1 1 HyperText Transfer Protocol version 1 transport.
Mqtt 4 Message Queuing Telemetry Transport. Try Mqtt over TCP first and fallback to Mqtt over WebSocket if that fails
Mqtt_Tcp_Only 6 Message Queuing Telemetry Transport over native TCP only
Mqtt_WebSocket_Only 5 Message Queuing Telemetry Transport over Websocket only.

Здесь

небольшое сравнение протоколов. Отметим, что в списке поддерживаемых протоколов нет, например, Modbus TCP для прямого считывания данных IoT Hub-ом с устройств поддерживающих этот распространенный протокол.

В статье Максима Хлупнова «Leaving on the Edge: гибридные IoT-решения» приводится классическая архитектура IoT и архитектура IoT Edge.

IoT Edge

Из неё видно, что прямая работа устройств с облаком IoT Hub воможна только при поддержке IoT Ready устройством вышеперечисленных протоколов. В любых других случаях необходимо наличие шлюза, преобразующего протоколы устройства (обычно, ModBus RTU/TCP) в протоколы понимаемые IoT Hub-ом. И уже на облачной стороне выполняется работа по обработке полученной информации.

Управление IoT устройствами через web интерфейсе Azure

Посмотрим, где находится управление устройствами в web интерфейсе Azure. Для этого нужно:

  • Зайти в All resources.
  • Выбрать созданный ранее ресурс с типом IoT Hub.
  • Зайти в раздел «Explorers» -> «IoT devices»
Устройства в Azure IoT Hub

Устройства в Azure IoT Hub

В этом разделе находятся устройства, передающие телеметрическую информацию напрямую в облако IoT Hub, без использования прокси в виде IoT Edge.

В списке устройств увидим созданное в уроке устройство «MyDotnetDevice». Если на нем кликнуть, то увидим параметры устройства:

Параметры IoT Hub устройства. Строка соединения с IoT Hub устройством

Параметры IoT Hub устройства

На скриншоте я привел вариант получения строки соединения с устройством через консоль и через веб интерфейс Azure IoT Hub.

Обратим внимание на пункт меню «Device twin». Перевести можно как «Устройство-близнец/двойник».  На мой взгляд правильнее было бы называть «Зеркальным устройством», поскольку устройство созданное в IoT Hub работает лишь как отражение реального устройства  или симулятора, как в нашем случае. Параметры заданные в JSON скрипте «Device twin» могут (если реализована поддержка) транслироваться на устройство.

Передача телеметрии в IoT Hub через IoT Edge

Как указано в статье Максима Хлупнова передача данных с физических устройств через прокси в виде IoT Edge устройства выглядит более логичной и снимает массу проблем. Основная — высокие задержки при передаче данных в облако и сниженная надежность из-за увеличения точек отказа (относительно медленный и ненадежный Интернет-канал).

Попробуем добавить в учебную модель IoT Edge устройство. Для этого воспользуемся готовым модулем TempSensor. Исходники модуля доступны на GitHub. Последовательность действий для развертывания модуля подробно изложена в документации, поэтому повторятся не буду. Остановлюсь лишь на некоторых командах, не приведенных в пособии.

Установка службы производится командой Install-SecurityDaemon.  При добавлении другого устройства необходимо перепривязать физическое устройство к зеркальному в IoT Hub, чтобы сменить connection string. Судя по всему, единственный вариант это сделать — удалить сервис IoT Edge командой Uninstall-SecurityDaemon и затем повторно развернуть IoT Edge, введя новую строку соединения.

Когда данные не нужно передавать, полезно «опустить» iotedge сервис, а при необходимости «поднять» вновь. Это делается командами:

Stop-Service iotedge
Start-Service iotedge

Чтобы перезапустить определенный модуль в случае проблем используется команда:

iotedge restart [tempSensor]

В данном примере испольщуется имя модуля tempSensor. Если после выполнения команды проверить лог передачи данных:

iotedge logs tempSensor -f

видно, что порядковый номер сообщений вновь начался с 1.

Вызов IoT device Direct Method

Для управления модулем устройства может быть использован Direct Method. В разделе статьи Direct Method Invocation приводится пример кода C# для вызова метода устройства с IoT Hub:

...
var resetMethod = new CloudToDeviceMethod("reset");
var response = await serviceClient.InvokeDeviceMethodAsync(deviceId, moduleId, resetMethod);
...

Название вызываемого метода «reset». Вызовем его со стороны IoT Hub. Для этого зайдем в IoT Edge Module -> tempSensor -> Direct method. В имени метода введем reset и нажмем «Invoke Method».

Invoke IoT Direct Method

На скриншоте видно, что результатом вернулся 200 код, свидетельствующий о успешном выполнении команды. В логе работы модуля появилась строка говорящая о том, что модуль принял вызов Direct Method.

Правка свойства модуля в разделе Module Identity Twin свойства desired (SendInterval был изменен с 5 до 7)

  "properties": {
    "desired": {
      "SendData": true,
      "SendInterval": 7,
    }
}

в соотвествии с документацией ни к чему не привела. Создал issue.

Проверка передачи данных в IoT Hub

в примере выше для проверки передачи данных от устройства IoT Hub используется консольное приложение read-d2c-messages. Пример его работы. Воспользуемся этим-же приложением для проверки передачи данных от модуля tempSensor.

Запустим приложение  read-d2c-messages и перезапустим эмулятор температуры командой iotedge restart tempSensor на IoT Edge устройстве.

Check Telemetry from IoT EdgeКонсольное приложение read-d2c-messages получает данные отправленные в облако IoT Hub с IoT Edge устройства.

Продолжение следует…

Spread the love
Запись опубликована в рубрике IT опыт, IT рецепты с метками , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *