To complete the last two article series (data from device to cloud, command/feedback from cloud to device) on using AMQP protocol stack to interact with Azure IoT Hub, we need to get telemetry data from the devices.
When devices send data through their D2C endpoints, these data flow into the IoT Hub system and are made available to the service through its D2C endpoint that is Event Hubs compatible which means we can use any Event Hubs client to get data from it.
On the new Azure portal we can see a lot of information about that in the related “Messaging” tab for our IoT Hub. The main information are :
- Partitions : the number of partitions through which data from devices are ingested by the IoT Hub;
- Event Hub compatible name : it’s the name of the event hub;
- Event Hub compatible endpoint : it’s the complete path (with namespace) of the event hub;
- Retention time : it’s the time the messages are retained inside the event hub;
- Consumer groups : the available consumer groups for reading messages from event hub using related receivers (there is always the $Default consumer group);
To read from this event hub endpoint we can use any shared access policy that has the ServiceConnect permission. The portal provides us a default policy named “service” with its related shared access key. Using three of the above information we are able to build the connection string needed to connect to this auto-generated event hub :
Endpoint={Event Hub-compatible endpoint};SharedAccessKeyName={iot hub policy name};SharedAccessKey={iot hub policy key}
Of course, other than the above connection string we have to use the Event Hub compatible name.
Now … how the get data from event hub ? What’s the code we have to write ?
The simpler way to do that is to use the Event Processor Host provided by Microsoft as Nuget package that instantiates receivers for us on all available partitions and handle their leases providing us a checkpoint feature. The “only” big problem we have with this awesome software component is that it works only on .Net Framework so we can use it on PC based and Web based service applications.
UWP apps ? : AMQP and Azure SB Lite the solution
What can we do for UWP apps ? What we can do if we want to monitor telemetry data from an UWP app on Windows 10 without bridging data from a Web application ?
As in the previous articles the solution is to use a good C# implementation of AMQP protocol stack as AMQP .Net Lite but in this case, to avoid AMQP stuff, we can use the Azure SB Lite library (available on Nuget too) that wraps the protocol stack and exposes same official Service Bus SDK APIs to access to Event Hubs (other than queues and topics/subscriptions).
If you know the above APIs to interact with Event Hubs, the following code will be familiar to you :
static string ConnectionString = "Endpoint=[EVENT_HUB_COMPATIBLE_ENDPOINT];SharedAccessKeyName=[IOT_HUB_POLICY_NAME];SharedAccessKey=[IOT_HUB_POLICY_KEY]";
static string eventHubEntity = "[EVENT_HUB_COMPATIBLE_NAME]";
static string partitionId = "[PARTIION_ID]";
static DateTime startingDateTimeUtc;
static void Main(string[] args)
{
ServiceBusConnectionStringBuilder builder = new ServiceBusConnectionStringBuilder(ConnectionString);
builder.TransportType = TransportType.Amqp;
MessagingFactory factory = MessagingFactory.CreateFromConnectionString(ConnectionString);
EventHubClient client = factory.CreateEventHubClient(eventHubEntity);
EventHubConsumerGroup group = client.GetDefaultConsumerGroup();
startingDateTimeUtc = new DateTime(2015, 10, 31, 16, 00, 00);
EventHubReceiver receiver = group.CreateReceiver(partitionId, startingDateTimeUtc);
while (true)
{
EventData data = receiver.Receive();
Debug.WriteLine("{0} {1} {2}", data.PartitionKey, data.EnqueuedTimeUtc.ToLocalTime(), Encoding.UTF8.GetString(data.GetBytes()));
}
receiver.Close();
client.Close();
factory.Close();
}
The above example is using Azure SB Lite and connecting to my current IoT Hub, it produces the following output :
Without having the Event Processor Host available on UWP apps, the bid deal is to create one or more receivers on all partitions by ourselves and handling the checkpoint on what is the position inside the stream we have already read. In that case, it’s useful to save the last reading date/time and use it as offset for starting a new read on the stream.
Conclusion
If you scaried to develop a monitoring UWP application because the related IoT Hub SDK doesn’t work on it … don’t worry you always have a solution that is based on using the underlying AMQP protocol stack. In that case, the solution is simpler thanks to the work I already done for the community with the Azure SB Lite. Of course, the choice to use and UWP application on a Windows 10 device instead of a .Net / Web application for monitoring your telemetry data is up to you and depends on the scenario, so it can make sense or not.
DEVEXPERIENCE 
One comment