Отправка сообщений с конечного устройства Нисходящее устройство не обрабатывается IoT Edge, работающим на прозрачном шлюзе - PullRequest
0 голосов
/ 18 сентября 2018

Я выполнил все инструкции по настройке «Устройства нисходящего потока» для отправки сообщений через IoT Edge, работающий в Transparent Gateway.Я считаю, что мои правила маршрутизации верны, но мой функциональный модуль не получает ни одно из Сообщений через поток сообщений.

Это инструкция, которой я следовал: https://docs.microsoft.com/en-us/azure/iot-edge/how-to-create-transparent-gateway-linux

Яиспользуя 2 виртуальные машины Linxu (Ubuntu 16.04.5).

  1. Виртуальный шлюз IoT Edge Transparent Gateway настроен с правильной настройкой, настройкой и проверкой всех сертификатов.Я смог использовать инструмент openssl из

openssl s_client -connect {my-gateway-machine-name-dns-name} .centralus.cloudapp.azure.com: 8883 -CAfile/certs/certs/azure-iot-test-only.root.ca.cert.pem -showcerts

Нижестоящее устройство, работающее на виртуальной машине Linux с установленными и проверенными сертификатами.Моя строка подключения выглядит следующим образом:

HostName = {IoTHubName} .azure-devices.net; DeviceId = TC51_EdgeDownStreamDevice01; SharedAccessKey = {My-Shared-Access-Key} = GatewayHostName = {my-gateway-machine-name-dns-name} .centralus.cloudapp.azure.com

a.Я подтвердил, что получил успешную проверку сертификата SSL с помощью инструмента openssl.б.Я использую следующее в моем нисходящем устройстве для подключения с использованием NodeJS SDK

var client = DeviceClient.fromConnectionString (connectionString, Mqtt);с.Я вижу сообщения, отображаемые в концентраторе IoT Azure в облаке, но не могу запустить мой модуль на прозрачном шлюзе IoT.

Вот мои правила маршрутизации, сконфигурированные для edgeHub, как указано в разделе «Маршрутизация сообщений от нижестоящих устройств» на странице примера документа.

Это то, что показывают примеры документов: {"маршруты":{"sensorToAIInsightsInput1": "FROM / messages / * WHERE NOT IS_DEFINED ($ connectionModuleId) INTO BrokeredEndpoint (\" / modules / ai_insights / input / input1 \ ")", "AIInsightsToIoTHub": "FROM / messages / modules / ai_insights/ output1 INTO $ upstream "}}

Это то, что моя конфигурация маршрутизации установлена ​​на:" route ": {" downstreamBatterySensorToBatteryDataFunctionInput1 ":" FROM / * ГДЕ НЕ IS_DEFINED ($ connectionModuleId) INTO BrokeredEndpoint (\ "/modules / BatteryDataFunctionModule / входы / input1 \ ")", "BatteryDataFunctionModuleToIoTHub": "FROM / messages / modules / BatteryDataFunctionModule / output / * INTO $ upstream"}

** Обратите внимание, что я использовал "FROM/ * WHERE NOT IS_DEFINED "и" FROM / messages / * WHERE NOT IS_DEFINED "

Мой модуль на IoT Edge настроен как функция.Когда я использую пример «из коробки», где имитирующее устройство - это другой модуль, работающий на IoT Edge, моя функция срабатывает правильно.Только когда я пытаюсь использовать «Устройство нисходящего потока», модуль не запускается.

Я включил «Журналирование отладки для IoT Edge Service», запущенное на моем Прозрачном шлюзе.

This is the basic Run method for the Function module:

#r "Microsoft.Azure.Devices.Client"
#r "Newtonsoft.Json"

using System.IO;
using Microsoft.Azure.Devices.Client;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

// Filter messages based on the temperature value in the body of the     message and the temperature threshold value.
public static async Task Run(Message messageReceived, IAsyncCollector<Message> output, TraceWriter log)
{

Как я могу выяснить, как заставить мой Модуль работать в IoT Edge, чтобы он попадал / запускался с устройства Downstream?

Ответы [ 2 ]

0 голосов
/ 24 сентября 2018

Есть две проблемы, которые необходимо решить, чтобы подключить нисходящее устройство к связи

  1. Благодаря @ Steve-Busby-Msft мне нужно было ставить точку с запятой (;) в концеSharedAccessKey и до GatewayHostName

вы опубликовали это как строку подключения в приложении узла: HostName = {IoTHubName} .azure-devices.net; DeviceId = TC51_EdgeDownStreamDevice01; SharedAccessKey = {My-Shared} = GatewayHostName = {мой шлюз-машина-имя-DNS-имя -Access-Key} .centralus.cloudapp.azure.com

Приложение NodeJS Downstream Device также должно корректно загрузить сертификат на «уровне приложения».

Обратите внимание на фрагмент кода для

var edge_ca_cert_path ='[Путь к сертификату Edge CA]';

Узел JS Downstream Application

'use strict';

var fs = require('fs');
var Protocol = require('azure-iot-device-mqtt').Mqtt;
// Uncomment one of these transports and then change it in fromConnectionString to test other transports
// var Protocol = require('azure-iot-device-http').Http;
// var Protocol = require('azure-iot-device-amqp').Amqp;
var Client = require('azure-iot-device').Client;
var Message = require('azure-iot-device').Message;

// 1) Obtain the connection string for your downstream device and to it
//    append this string GatewayHostName=<edge device hostname>;
// 2) The edge device hostname is the hostname set in the config.yaml of the Edge device
//    to which this sample will connect to.
//
// The resulting string should look like the following
//  "HostName=<iothub_host_name>;DeviceId=<device_id>;SharedAccessKey=<device_key>;GatewayHostName=<edge device hostname>"
var connectionString = '[Downstream device IoT Edge connection string]';

// Path to the Edge "owner" root CA certificate
var edge_ca_cert_path = '[Path to Edge CA certificate]';

// fromConnectionString must specify a transport constructor, coming from any transport package.
var client = Client.fromConnectionString(connectionString, Protocol);

var connectCallback = function (err) {
  if (err) {
    console.error('Could not connect: ' + err.message);
  } else {
    console.log('Client connected');
    client.on('message', function (msg) {
      console.log('Id: ' + msg.messageId + ' Body: ' + msg.data);
      // When using MQTT the following line is a no-op.
      client.complete(msg, printResultFor('completed'));
      // The AMQP and HTTP transports also have the notion of completing, rejecting or abandoning the message.
      // When completing a message, the service that sent the C2D message is notified that the message has been processed.
      // When rejecting a message, the service that sent the C2D message is notified that the message won't be processed by the device. the method to use is client.reject(msg, callback).
      // When abandoning the message, IoT Hub will immediately try to resend it. The method to use is client.abandon(msg, callback).
      // MQTT is simpler: it accepts the message by default, and doesn't support rejecting or abandoning a message.
    });

    // Create a message and send it to the IoT Hub every second
    var sendInterval = setInterval(function () {
      var windSpeed = 10 + (Math.random() * 4); // range: [10, 14]
      var temperature = 20 + (Math.random() * 10); // range: [20, 30]
      var humidity = 60 + (Math.random() * 20); // range: [60, 80]
      var data = JSON.stringify({ deviceId: 'myFirstDownstreamDevice', windSpeed: windSpeed, temperature: temperature, humidity: humidity });
      var message = new Message(data);
      message.properties.add('temperatureAlert', (temperature > 28) ? 'true' : 'false');
      console.log('Sending message: ' + message.getData());
      client.sendEvent(message, printResultFor('send'));
    }, 2000);

    client.on('error', function (err) {
      console.error(err.message);
    });

    client.on('disconnect', function () {
      clearInterval(sendInterval);
      client.removeAllListeners();
      client.open(connectCallback);
    });
  }
};

// Provide the Azure IoT device client via setOptions with the X509
// Edge root CA certificate that was used to setup the Edge runtime
var options = {
  ca : fs.readFileSync(edge_ca_cert_path, 'utf-8'),
};

client.setOptions(options, function(err) {
  if (err) {
    console.log('SetOptions Error: ' + err);
  } else {
    client.open(connectCallback);
  }
});
0 голосов
/ 19 сентября 2018

Итак, вы говорите, что видите сообщения, отображаемые в IoT Hub, но не в Edge ... Пара вещей:

вы опубликовали это как строку подключения в приложении узла: HostName = {IoTHubName} .azure-devices.net; DeviceId = TC51_EdgeDownStreamDevice01;} = GatewayHostName = {мой шлюз-машина-имя-DNS-имя SharedAccessKey = {My-Shared-Access-Key} .centralus.cloudapp.azure.com

Вы копировали / вставляли это точно?причина, по которой я спрашиваю, заключается в том, что между общим ключом доступа и словом «GatewayHostName» у вас есть знак равенства, а не точка с запятой.

это должно быть: HostName = {IoTHubName} .azure-devices.net; DeviceId = TC51_EdgeDownStreamDevice01; SharedAccessKey = {My-Shared-Access-Key}; GatewayHostName = {my-gateway-machine-name-dns-name} .centralus.cloudapp.azure.com

(обратите внимание на ';' перед GatewayHostName ... если у вас действительно есть знак равенства вместо точки с запятой, то нет никакого объяснения того, какой хаос это может вызвать: -)

Во-вторых, на вашем маршруте вы называете свойmoduleDataFunctionModule .. просто хочу убедиться, что имя модуля является точным, в том числе с учетом регистра.Вы, вероятно, знаете это, но не хотите предполагать ..

Наконец, если две вышеуказанные вещи подтвердятся, вы можете добавить дополнительный маршрут отладки, который также отправляет «входящие данные» в IoTHub ...
"FROM / * WHERE NOT IS_DEFINED ($ connectionModuleId) INTO $ upstream"

, чтобы мы могли убедиться, что сообщения действительно передают его с по iot edge.

...