I was trying to get TTN to Azure IOT Hub connectivity working myself. I Initially started with building a .Net client for the V3 Application+EndDevice APIs. I generated a client from the Swagger file available on Github as a starting point. I got as far as being able to list an Application’s EndDevices and query individual EndDevices. When I tried creating an EndDevice it didn’t quite work as expected so I haven’t been able to fully configure a device yet.
The aim of this approach was - provisioning a TTN EndDevice (?with a template) when a device was created in my Azure IoT hub (most probably using EventGrid notifications).
In effect Azure->TTN
Next, I figured I would use the MQTT API to get notifications of when Application EndDevices were create/updated/deleted by subscribing to MQTT topics with a suitable wild cards. I can connect to my V3 instance and successfully subscribe to topics but don’t receive any messages when I create/update/delete EndDevices. I have tried different QoS settings etc. and if I try and subscribe to an “invalid” topic (e.g. malformed name) it fails but I still wonder if my topic names aren’t quite right.
The aim of this approach was - provisioning a device in my Azure IoT Hub (maybe with a tag indicating it’s an “orphan” so it is discoverable or some EventGrid magic) when an EndDevice was created in TTN.
In effect TTN->Azure
Overall the later approach looked better for my scenario. My AzureIoT Hub application has other devices which are not connected via LoRaWAN and there are many specialised LoRaWAN settings (the TTN software is good at managing these) which would need to be validated in my software which could rapidly become a PITA (maybe templates would make this easier).
The TTN people provided me with access to a V3 system for dev/test which was great and I would like to progress these two approaches but I’m struggling with documentation etc…
When we started in 2017 we used an Azure ServiceBus and it’s endpoint. The TTN integration ‘HTTP integration’ and just forward it to the ServiceBus.
On the other end of the ServiceBus an Azure Function waits and handles the data and stores it into a SQL DB. In 2017 the IoTHub was way more expensive than a ServiceBus. I don’t know the cost now but it still works flawlessly. https://docs.kolibricloud.ch/overview/architecture/