電子發燒友網>電子資料下載>電子資料>重訪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);
}