电子发烧友网>电子资料下载>电子资料>重访The Things Industries (TTI) V3 Azure IoT连接器

重访The Things Industries (TTI) V3 Azure IoT连接器

1946861 2023-06-14 | zip | 0.00 MB | 次下载 | 免费

资料介绍

描述

早在 2020 年 11 月，我就发布了我的 The Things Network V2 Azure IoT Hubs & IoT Central Gateway。该项目是关于构建物联网 (TTN)HTTP 应用程序集成，它启用Azure IoT 中心和Azure IoT Central与Azure IoT 中心设备供应服务 (DPS)供应支持的连接。

该项目使用了“符合流行语”的Microsoft Azure服务选择，但它不支持云到设备 (C2D) 消息，存在消息排序问题，并且部署和设置复杂。（还有其他问题，但不值得在这里重新讨论）

然后在 2021 年 3 月，我再次尝试使用我的 The Things Industries(TTI) V3 Azure IoT 连接器，它是一个TTI（消息队列遥测传输）MQTT 集成，也使用了 TTI应用程序和终端设备 API 。

此版本使用MQTTNet （这是一个很棒的库）和在应用程序启动时连接到Azure IoT Hub或Azure IoT Central的 TTI 设备。即使我使用多个线程并对 Application 和 EndDevice 请求进行分页，这个过程也很慢。

该应用程序更容易调试，因为我可以在桌面上运行它，并且更容易配置，因为我将配置转移回appsettings.json文件（我可能会重新考虑放弃Azure Key Vault支持的决定）。

此版本具有基本的Azure 数字孪生定义语言 (DTDL)支持，因此可以在Azure IoT Central中“自动”预配设备。

我还添加了对Azure IoT Hubs和Azure IoT Central的C2D 支持，并基于下行链路消息有效负载确认标志跟踪消息传递。我发现TTI 交付进度更新的顺序可能有问题。

在生产环境中使用基于MQTT的集成后，我发现它过于“有状态”并且无法从意外事件中很好地恢复。（还有其他问题，但不值得在这里重新讨论）

然后在 2021 年 10 月，我决定我的“学习之旅”还没有结束，我将构建另一个TTI 连接器，该连接器将 Azure 存储队列用于 C2D 和 D2C 消息。

试用该应用程序后，我意识到消息排序和部署复杂性可能是一个问题（我忘记了我的 TTN V2 网关学习），所以我暂停了项目。（虽然我确实认为这个项目可能对一些集成项目有用）

此时，我回顾了从多个 TTI 集成项目中学到的知识，并决定再次尝试使用The Things Stack(TTS) 网络挂钩集成。

我的“The Things Industries(TTI) V3 connector revisited”项目是一个身份转换云网关，它将LoRaWAN EndDevices映射到Azure IoT Hub Devices 。

连接器为每个LoRaWAN设备创建一个DeviceClient ，并且可以使用Azure 设备连接字符串或Azure 设备预配服务 (DPS) 。

The Things Industries Azure IoT 集成架构

在我所有的集成中，TTI 一直是设备配置的单一事实来源 (SSOT) ，因为LoRaWAN配置设置的数量和复杂性会使从其他应用程序管理它成为一个难题。（我还考虑过使用TTSEndDevice 模板来创建我可能会回来的设备）

当前版本的一个限制是，EndDevice 将连接到Azure IoT Hub （提供应用程序配置连接字符串或Azure IoT Hub DPS ），并且只有在收到 TTI 上行链路或Azure IoT Hub D2C 消息后才会处理 C2D 消息。一体化。

Azure IoT Hub 设备在第一个 TTI 上行链路上连接

这可能是一个问题（尤其是在重新启动集成后）或配置了新设备。我考虑过添加几个Azure HTTP 触发器函数，应用程序调用这些函数可以检查设备的连接状态并可选择启动连接。（短期内从 TTI EndDevice 用户界面或 API 模拟上行链路应该可以工作）

我从D2C 消息传递开始，然后添加了C2D 消息传递，然后添加了支持DTDLV2 的 Device Provisioning(DPS) ，然后扩展了C2D 消息传递，最后实现了Azure IoT Central D2C和C2D （使用少参数、单值和JavaScript 对象表示法（JSON ）有效载荷命令）

Azure IoT Central 仪表板，用于我的测试环境中的 Seeeduino LoRaWAN 传感器

该应用程序的核心是五个Azure HTTP 触发函数（已发送函数当前未使用）和一个为 C2D 调用的方法（与SetReceiveMessageHandlerAsync方法连接）消息。

Azure 门户功能列表

Azure IoT 中心可以调用方法（同步）或将消息（异步）发送到设备进行处理。Azure IoT 中心 DeviceClient有两个方法SetMethodDefaultHandlerAsync和SetReceiveMessageHandlerAsync ，它们可以处理直接方法和消息。

在对以前的 TTI 连接器进行了一些实验之后，我发现DirectMethods的同步特性不适用于LoRAWAN通常“不规则”的上行链路，因此目前不支持它们。

该集成广泛使用了Microsoft.Extensions.Logging功能和Azure Application Insights ，因此调试、监控和故障查找更省时。

Azure Application Insights（说明搜索功能）

我已将有用的“元数据”添加到各个日志项中，因此更容易跟踪为处理事件而执行的所有步骤，例如 ReceiveMessageCallback 、AbandonAsync 、CompleteAsync和RejectAsync C2D 消息处理中使用的 LockToken。

应用程序配置概述

可以使用appsettings.json文件配置应用程序（对桌面开发和调试很有用）

{
   "Values": {
      "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=...",
      "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
      "APPINSIGHTS_INSTRUMENTATIONKEY": "..."
      },
      "TheThingsIndustries": {
      "WebhookBaseURL": "https://....eu1.cloud.thethings.industries/api/v3/as/applicat      ions",
      "Applications": {
         "seeeduinolorawan": {
         "webhookId": "azure-iot-hub-connector",
         "APIKey": "..."
         },
         "Wisnode Devices": {
         "webhookId": "azure-iot-hub-connector",
         "APIKey": "..."
         },
         "dragino-lht65": {
         "webhookId": "azure-iot-hub-connector",
         "APIKey": "..."
         },
         "SeeeduinoLoRaWAN100": {
         "webhookId": "azure-iot-hub-connector",
         "APIKey": "..."
         },
         "rak3172": {
            "webhookId": "azure-iot-hub-connector",
            "APIKey": "..."
         },
       "application1": {
          "webhookId": "azure-iot-hub-connector",
          "APIKey": "..."
        }
      }
   },
   "AzureIoT": {
      "DeviceClientCacheSlidingExpiration": "P2H30M",
      "IoTHub": {
         "IoTHubConnectionString": "HostName=...",
         "Applications": {
            "SeeeduinoLoRaWAN": {
            "DtdlModelId": "dtmi:ttnv3connectorclient:SeeeduinoLoRaWAN4cz;1"
            },
            "Wisnode Devices": {
            },
            "Dragino LHT65": {
            }
         }
      },
      "DeviceProvisioningService": {
         "IdScope": "0ne..",
         "Applications": {
         "seeeduinolorawan": {
            "DtdlModelId": "dtmi:ttnv3connectorclient:SeeeduinoLoRaWAN4cz;1",
            "GroupEnrollmentKey": "...",
         },
         "Wisnode Devices": {
            "GroupEnrollmentKey": "..."
         },
         "dragino-lht65": {
            "GroupEnrollmentKey": "..."
         },
         "rak3172": {
            "GroupEnrollmentKey": "..."
         },
      "application1": {
         "DtdlModelId": "dtmi:ttnv3connectorclient:FezduinoWisnodeV14x8;4",
         "GroupEnrollmentKey": "..."
      }
   }
},
"IoTCentral": {
   "methods": {
      "LightsGoOn": {
         "Port": 10,
         "Payload": "{"value_1": 1}"
      },
      "LightsGoOff": {
         "Port": 10,
         "Payload": "{"value_1": 0}"
      },
      "value_0": {
         "Port": 20
      },
      "value_1": {
         "Port": 21
      },
      "value_2": {
         "Port": 22
      },
      "TemperatureOOBAlertMinimumAndMaximum": {
         "Port": 23
      },
   }
}

暂存和生产部署的首选方法）是使用Azure 门户Azure 功能配置刀片

Azure 门户 Azure Function 配置

Things Industries Webhook 集成配置

要发送下行链路和接收上行链路消息，必须配置 TTI 应用程序和TTI 连接器并配置 API 密钥。

注意 – TTN URL 和 Azure IoT 中心设备标识符区分大小写

Azure Function 配置 TTI webhook 配置设置

TTI 连接器需要webhookbaseURL ，然后是每个 TTI 应用程序和一个API 密钥，以及 WebhookId

Azure 功能配置应用程序密钥

当调用 Azure Functions 时，Azure Function Host Key会在名为“x-functions-key”的HTTP 标头中传递

Azure Function API Key TTI Webhook 消息处理进度配置

使用TTI App Key保护下行链路消息处理

显示所需权限的 TTI 应用程序密钥创建

当调用TTI webhook 下行链路端点时， TTI 应用程序密钥在标准HTTP 授权标头中传递。

使用 Azure Function 端点作为基本 URL 创建 TTI Webhook 集成

Azure IoT 中心连接配置

TTI 连接器需要共享访问签名 (SAS) 设备策略连接字符串才能连接到Azure IoT 中心。

突出显示 Azure IoT 中心配置的 Azure 函数配置

Azure IoT 中心设备策略连接字符串配置刀片

Azure IoT Hub设备必须手动或通过Azure IoT Hub REST API进行预配。我已经试用了一个Azure 逻辑应用程序，它管理设备配置并且可以在操作失败时稳健地处理所需的补偿事务。

Azure IoT 中心设备

如果同时配置了Azure IoT 中心/Azure IoT 中心设备预配 (DPS) 支持，则 TTI 连接器应用程序将不会启动。

请注意：Azure IoT 中心设备 ID 是一个区分大小写的字符串（最长 128 个字符），由 ASCII 7 位字母数字字符加上某些特殊字符组成：-。+ % _ # * ? ！( ), : = @$ '

Azure IoT 中心设备预配服务 (DPS) 配置

TTI 连接器支持用于独立Azure IoT 中心应用程序的Azure IoT 中心设备预配服务 (DPS) 。TTI 连接器实现还支持用于设备配置的Azure IoT Central 数字孪生定义语言( DTDL V2 )。

Azure IoT 中心设备预配服务支持使用X.509证书、可信平台模块 (TPM)和使用共享访问签名(SAS) 安全令牌的对称密钥进行设备证明。

Things Industries(TTI) V3 Azure IoT 连接器仅支持对称密钥设备证明。

如果Azure IoT 中心/ Azure IoT 中心设备预配 (DPS)支持两者/两者均未配置，则 TTI 连接器应用程序将不会启动。

Azure 功能配置与 Azure IoT 中心设备预配服务配置

Azure IoT 中心设备预配服务 (DPS)具有确定设备分配方式的服务级别设置。有四种支持的分配策略：

均匀加权分布：链接的物联网中心同样可能有设备配置给它们。默认设置。如果您仅将设备预配到一个 IoT 中心，则可以保留此设置。
最低延迟：将设备预配到设备延迟最低的 IoT 中心。如果多个链接的 IoT 集线器将提供相同的最低延迟，则供应服务会在这些集线器之间散列设备
通过注册列表进行静态配置：注册列表中所需 IoT 中心的规范优先于服务级别分配策略。
自定义（使用 Azure 函数）：自定义分配策略使您可以更好地控制如何将设备分配给 IoT 中心。这是通过使用 Azure 函数中的自定义代码将设备分配给 IoT 中心来实现的。设备预配服务调用您的 Azure 函数代码，提供有关设备和代码注册的所有相关信息。您的函数代码将执行并返回用于预配设备的 IoT 中心信息。

在我的测试环境中，我使用均匀加权分布，当我预置 1000 台设备时，它们分布在我的五个Azure IoT 中心。

Azure IoT 中心设备预配服务 Azure IoT 中心配置

Azure IoT Hub DPS 设备分发

Azure IoT Central DPS 配置

TTI 连接器支持Azure IoT Central应用程序所需的Azure IoT 中心设备预配服务 (DPS) （有一种预配单个设备的方法）。TTI 连接器实现还支持用于“自动”设备预配的Azure IoT Central 数字孪生定义语言( DTDL V2 )。

如果同时配置了Azure IoT 中心/Azure IoT 中心设备预配 (DPS) 支持，则 TTI 连接器应用程序将不会启动。

Azure 功能配置与 Azure IoT 中心设备预配服务配置

第一步是配置Azure IoT Central 注册组（确保“自动连接该组中的设备”为“零接触”配置）并将IDScope和组注册密钥复制到 TTI 连接器配置

RAK3172 设备连接配置

然后，我为我的RAK3172 分线板基于 .Net Core 供电的测试设备创建了一个 Azure IoT Central 模板。

RAK3172 设备模板

RAK3172 设备注册组

将设备组与组注册配置关联

复制 RAK3172 DTDL V2 模板 ID

还可以使用在 TTI 连接器配置中指定的可选 dtdlmodelid 为 TTI 应用程序设置设备模板 @Id。

Azure IoT Hub 设备到云 (D2C)

LoRaWAN设备使用共享访问签名 (SAS) 设备策略连接字符串连接到Azure IoT 中心。我正在使用Device Twin Explorer显示遥测数据并向我的传感器节点发送消息。

显示来自我的 Seeeduinolorawan2 设备的遥测数据的设备资源管理器

如果有效负载已被有效负载格式化程序解码，则将对其进行后处理，然后包含在消息有效负载中。

try
{
	JObject telemetryEvent = new JObject
	{
		{ "ApplicationID", applicationId },
		{ "DeviceEUI" , payload.EndDeviceIds.DeviceEui},
		{ "DeviceID", deviceId },
		{ "Port", port },
		{ "Simulated", payload.Simulated },
		{ "ReceivedAtUtc", payload.UplinkMessage.ReceivedAtUtc.ToString("s", CultureInfo.InvariantCulture) },
		{ "PayloadRaw", payload.UplinkMessage.PayloadRaw }
	};

	// If the payload has been decoded by payload formatter, put it in the message body.
	if (payload.UplinkMessage.PayloadDecoded != null)
	{
		EnumerateChildren(telemetryEvent, payload.UplinkMessage.PayloadDecoded);
	}

	// Send the message to Azure IoT Hub
	using (Message ioTHubmessage = new Message(Encoding.ASCII.GetBytes(JsonConvert.SerializeObject(telemetryEvent))))
	{
		// Ensure the displayed time is the acquired time rather than the uploaded time. 
		ioTHubmessage.Properties.Add("iothub-creation-time-utc", payload.UplinkMessage.ReceivedAtUtc.ToString("s", CultureInfo.InvariantCulture));
		ioTHubmessage.Properties.Add("ApplicationId", applicationId);
		ioTHubmessage.Properties.Add("DeviceEUI", payload.EndDeviceIds.DeviceEui);
		ioTHubmessage.Properties.Add("DeviceId", deviceId);
		ioTHubmessage.Properties.Add("port", port.ToString());
		ioTHubmessage.Properties.Add("Simulated", payload.Simulated.ToString());

		await deviceClient.SendEventAsync(ioTHubmessage);

		logger.LogInformation("Uplink-DeviceID:{deviceId} SendEventAsync success", deviceId);
	}
}
catch( Exception ex)
{
	logger.LogError(ex, "Uplink-DeviceID:{deviceId} SendEventAsync failure", deviceId);

	// If retries etc fail remove from the cache and it will get tried again on the next message
	_DeviceClients.Remove(deviceId);
}