描述

背景

在客戶放棄概念證明( PoC )項目后，我在我桌子下面的盒子。

在過去幾年中，我構建了一系列Windows 10 IoT Core現場網關應用程序，用于將LoRa設備連接到Azure IoT 中心、Azure IoT Central和Adafruit.IO 。這些運行良好，但現在我需要一個基于Microsoft Azure 云的解決方案，將連接到物聯網 (TTN)的LoRaWAN設備連接到在Microsoft Azure中運行的應用程序。

我一直在為 .NET nanoFramework和GHI Electronics TinyCLR設備開發庫的另一個項目，以啟用與RAK811 LPWAN 模塊（ PoC 的Wisduino外形）的LoRaWAN連接。

在新西蘭有兩個全國性的網絡（Spark IoT 、KotahiNet ），但我一直想探索 TTN 和The Things Industries的功能，它們看起來有足夠的診斷功能來滿足我的目的。

我假設如果您正在閱讀這個項目故事，那么您熟悉為 Microsoft Azure 開發應用程序，尤其是 IoT 服務。TTN 應用程序和設備的配置在其他幾個Hackster.IO項目中已經詳細介紹過，這里不再贅述。

這個項目是我博客上一系列帖子的總結，我在其中更詳細地介紹了解決方案的構建。

在一開始的時候

我最初連接了RAK WisGate 開發者網關并配置了 RAK7200 Track Lite 設備。在 TTN 應用程序設備數據選項卡中，我可以看到從設備接收到上行鏈路消息，并且大部分有效負載都被解碼，這是一個好的開始。

建立聯系

我配置了我的 Arduino IDE，以便我可以訪問 Seeeduino、LoRaWAN 示例，然后編譯并將它們下載到我的設備。我使用本地網關測試了個性化激活 (ABP) 和空中激活 (OTAA)示例的修改版本，以確認我的設備配置良好。在我記得我需要打開我的Seeeduino Grove I2C 溫度和濕度傳感器連接器的電源之后，設備代碼第二次工作了。

反序列化 TTN 消息

我為我的一個 TTN 應用程序配置了TTN HTTP集成，因此它將上行鏈路消息發布到帶有 HTTP 觸發端點的 Azure 函數。

我使用JSON2Csharp和從 TTN 網站下載的示例上行鏈路有效負載來生成一些C#類的初始版本，以對上行鏈路消息進行反序列化。

由于 JSON2CSharp 無法確定數字字段是整數還是無符號長整數，因此生成的代碼存在一些問題。

TTN 文檔指出，在成功解碼上行鏈路消息時填充了 payload_fields 屬性。TTN 有一個內置的Cayenne 低功耗有效負載 (LPP)消息解碼器，RAK7200 Wisnode 軌道燈部分支持該解碼器（還提供具有增強功能的定制解碼器/編碼器）。

我在我的Seeeduino LoRaWAN 設備上使用了第 3 方庫（來自 Electronic Cats 的 CayenneLPP 庫）來對包含溫度和濕度信息的有效載荷進行編碼。

超越自己

解壓payload_fields 屬性讓我有些痛苦。我嘗試了許多不同的方法，但都失敗了。經過大量實驗后，我發現使用C# 對象是最簡單的方法（盡管該字段的后處理更為復雜）。

public class PayloadV4
{
   public string app_id { get; set; }
   public string dev_id { get; set; }
   public string hardware_serial { get; set; }
   public int port { get; set; }
   public int counter { get; set; }
   public bool is_retry { get; set; }
   public string payload_raw { get; set; }
   //public JsonObject payload_fields { get; set; }
   //public JObject payload_fields { get; set; }
   //public JToken payload_fields { get; set; }
   //public JContainer payload_fields { get; set; }
   //public dynamic payload_fields { get; set; }
   public Object payload_fields { get; set; }
   public MetadataV4 metadata { get; set; }
   public string downlink_url { get; set; }
}

我還必須在我的 PoC 應用程序中添加一些代碼來解壓縮具有嵌套字段的 RAK Wisnode 7200 Tracker 加速度計、陀螺儀和位置值。

然后，我使用Microsoft.Azure.Devices.Client庫連接到Azure IoT Hub或Azure IoT Central （使用 DPS-KeyGen 生成連接字符串）并上傳了我可以在Azure IoT explorer中看到的遙測消息。

使用 Azure 存儲隊列處理消息和失敗

對于我的HTTP 集成，我需要可靠地將上行鏈路消息轉發到Azure IoT 中心或Azure IoT Central ，因此我使用Azure 存儲隊列在我的Azure Function HTTPTrigger端點和消息處理器之間提供彈性緩沖區。

我的解決方案需要強大且不會丟失任何消息，即使系統的某些部分由于故障或入站流量突然激增而無法使用。

用于接收物聯網 (TTN) HTTP 集成 JSON 消息的代碼使用了 Azure 函數 HTTPTrigger。（使用APIKey 保護），然后將它們放入Azure 存儲隊列以進行處理。

這段代碼故意保持盡可能小和盡可能簡單，這樣就不會出錯。經過一些實驗，只用了不到兩打 C# 行就創建了一個安全端點來接收上行鏈路消息并將它們放入Azure 存儲隊列。

通過存儲來自 TTN 的原始上行鏈路事件 JSON，應用程序可以在無法反序列化時恢復（消息格式已更改或生成類問題）當隊列處理器無法處理上行鏈路事件消息時（引發異常）重試幾次后，它將最終進入有毒消息隊列（以防故障是暫時的）。

上行鏈路消息隊列處理器使用Azure 函數隊列觸發器從隊列中提取消息，并在需要時預配設備，檢索 Azure IoT 中心/Azure IoT 中央連接字符串或使用緩存的 DeviceClient。

“自動”供應

對于開發和測試而言，能夠預配單個設備確實很有用，盡管對于Azure IoT Central來說這并不容易（尤其是在棄用 DPS-KeyGen 的情況下）。通過Azure IoT Hub設備連接字符串在門戶中可用，這很方便，但可擴展性不是很好。

Azure IoT 中心與 Azure IoT Central集成，并且Azure IoT Central強制使用設備預配服務 (DPS)。DPS 旨在支持管理 1000 臺設備，這些設備需要一些自定義應用程序來進行壓力和浸泡測試。

我的物聯網HTTP 集成(TTN)旨在支持許多設備并與Azure IoT Central集成。DPS 支持使用可信平臺模塊 (TPM)進行設備認證，但這種方法不適用于我的應用程序。我的 TTN 應用程序集成使用具有對稱密鑰證明的組注冊

Azure IoT 中心集成

盡管可以在Azure IoT 中心預配單個設備，但Azure 設備預配服務 (DPS)是首選方法。

scopeID 和主要/次要注冊密鑰在Azure Key Vault中配置，Azure QueueTrigger 函數可以安全地訪問它們。

對于更復雜的部署，可以使用基于 applicationID（或 applicationID + 端口號）的不同 GroupEnrollment 密鑰來配置物聯網 (TTN)設備。這方面的一個例子是卡車上的跟蹤設備報告位置數據，其中一個端口號和另一個端口號的貨物溫度和濕度，因此可以將遙測事件路由到正確的應用程序。

然后，在處理設備的第一條上行鏈路消息時，它會在 DPS 和 Azure IoT Hub 中“自動”創建。

Azure IoT 中心集成

物聯網 (TTN) HTTP 集成上行鏈路消息必須進行配置，然后進行后處理，以便 Azure IoT Central 顯示它們。

第一步是從 Administration\Device 連接復制 IDScope 和一個主/輔助密鑰，并將它們存儲在Azure Key Vault中。

對于更復雜的部署，可以根據啟動配置的第一個上行鏈路消息中的 applicationid（或 applicationID + 端口號）使用不同的GroupEnrollment密鑰來配置物聯網 (TTN)設備。

在處理來自 TTN 設備的第一條上行鏈路消息后不久，它將在“未關聯設備”選項卡中列出。

然后可以將設備與Azure IoT Central Device Template關聯。

設備模板提供上行消息有效載荷字段到設備屬性的映射。在此示例中，有效載荷字段已由TTN 應用集成 Cayenne 低功耗協議 (LPP)解碼器生成。許多LoRaWAN設備使用 LPP 來最小化網絡負載的大小。

一旦設備與模板相關聯，就可以配置用戶友好的設備名稱等。

Azure IoT Central 具有映射功能，可用于顯示設備的位置。

TTN LPP 解碼器生成的位置有效負載的格式與 Azure IoT Central 所需的格式不同。我添加了臨時代碼（“一種具有成本效益的加速部署修改”又名黑客）來格式化 TelemetryEvent 有效負載，以便顯示它。

if (token.First is JValue)
{
   // Temporary dirty hack for Azure IoT Central compatibility
   if (token.Parent is JObject possibleGpsProperty)
   {
      if (possibleGpsProperty.Path.StartsWith("GPS", StringComparison.OrdinalIgnoreCase))
      {
         if (string.Compare(property.Name, "Latitude", true) == 0)
         {
            jobject.Add("lat", property.Value);
         }
         if (string.Compare(property.Name, "Longitude", true) == 0)
         {
            jobject.Add("lon", property.Value);
         }
         if (string.Compare(property.Name, "Altitude", true) == 0)
         {
            jobject.Add("alt", property.Value);
         }
      }
   }
   jobject.Add(property.Name, property.Value);
}

在配置設備模板、將一些設備與模板關聯并修改每個設備的屬性后，我可以創建一個儀表板來查看我的Seeeduino LoRaWAN 設備返回的溫度和濕度信息。

保守秘密

應用程序集成配置包含敏感信息，例如設備預配服務 (DPS) 組注冊對稱密鑰和Azure IoT 中心連接字符串。

Azure Key Vault旨在保護連接字符串等敏感信息，因此我在資源組中添加了一個。

我編寫了一個包裝器，它根據上行鏈路消息有效負載中的物聯網 (TTN)應用程序標識符和端口信息解析配置設置。resolve 方法首先查找 applicationId 和 port 的配置（由 – 分隔），然后是 applicationId，最后返回到默認值。

此功能用于 AzureIoTHub 連接字符串、DPS IDScopes、DPS 注冊組對稱密鑰，也用于格式化緩存密鑰。

Azure 函數配置設置（如 Azure 存儲連接字符串）的值被替換為對 Azure Key Vault 中機密的引用。

在 Azure Key Vault“訪問策略”中，我配置了“應用程序訪問策略”，因此我的 Azure TTNAzureIoTHubMessageV2Processor 函數標識可以檢索機密。

去大或回家

在我最初的實現中，我使用ConcurrentDictionary來存儲Azure IoT Hub連接，以減少對設備預配服務 (DPS) 的調用次數。經過一些測試后，我將其替換為 a. Net ObjectCache位于System.Runtime.Caching命名空間中。

我使用緩存來存儲Azure IoT Hub連接以減少對設備預配服務 (DPS)的調用次數，但連接數仍然太高。

因此，經過一番研究，我決定啟用高級消息隊列協議（AMQP）連接池。

return DeviceClient.Create(result.AssignedHub,
   authentication,
   new ITransportSettings[]
   {
      new AmqpTransportSettings(TransportType.Amqp_Tcp_Only)
      {
         PrefetchCount = 0,
         AmqpConnectionPoolSettings = new AmqpConnectionPoolSettings()
         {
            Pooling = true,
         }
      }
   }
);

在此之后，連接數顯著減少

“市場結構”圖

哎呀我把自己畫到一個角落里

在對上行鏈路消息的處理進行擴展和浸泡測試后，我意識到我所做的一些設計和實現選擇意味著處理下行鏈路消息并不容易。

如果您的應用程序只需要接收來自 LoRaWAN 設備的消息，此解決方案將是理想的。

為了支持下行消息，我很可能必須轉換到MQTT 數據 API并刪除一些高級配置選項。

這將需要一段時間，所以如果您有興趣，請關注我的博客，我將在其中發布我的進展。