Event Hub and IoT Hub share a lot of similarities, and indeed the underlying infrastructure for IoT Hub is based on Event Hub.

However, it is important to understand the differences, so the correct choice can be made when required.

From the table, it can be seen that one of the key reasons to choose between the two hubs is whether or not your devices are capable of bidirectional communication. However, even if your devices are only able to transmit telemetry data, IoT Hub is still useful when protocol support and greater security are required.

IoT Hub uses a device identity registry to provide per device authentication and access control. Using device-initiated access control, per-device security, and trusted peer-to-peer communication between the device and IoT Hub, the attack vector to compromise devices is reduced.

Of course, devices themselves can still be physically compromised, but having a device identity registry allows quick remedial action to be taken to remove access to the IoT Hub and any backend services in the event of a compromise taking place.

It is not possible to create devices through the Azure portal directly; they need to be created either in a tool or via code. We discuss two tools for the simple management of devices and IoT Hub later in the chapter, but to create via code, you can use the RegistryManager class in the SDK:

static RegistryManager registryManager; 
static string connectionString = "[IOT-HUB-CONNECTION-STRING]"; 
 
static void Main(string[] args) 
{ 
   registryManager = 
   RegistryManager.CreateFromConnectionString(connectionString); 
   AddDeviceAsync().Wait(); 
   Console.ReadLine(); 
} 

static async Task AddDeviceAsync(string deviceId) 
{ 
    Device device; 
    try

    { 
        device = await registryManager.AddDeviceAsync(new Device(deviceId)); 
    } 
    catch (DeviceAlreadyExistsException) 
    { 
        device = await registryManager.GetDeviceAsync(deviceId); 
    } 
    Console.WriteLine("Generated device key: {0}", device.Authentication.SymmetricKey.PrimaryKey); 
}

To provision large volumes of devices at once, it is possible to import information in bulk.

Once created or imported, devices and their basic configuration can be viewed through the portal by clicking on Devices on the main IoT Hub blade.

In the resulting blade, information can be added to the view by clicking on Columns and choosing which information you wish to display.

Choosing a device opens a new blade that contains information such as shared access keys used to create shared access signatures and a connection string defined for the shared access key. It is possible to enable or disable a device from this blade.

While the device information in the identity registry is important for the functionality of IoT Hub, in a real-world scenario, it is likely that further information is required to help define and administer a device, such as firmware version and commands that a device accepts. For this purpose, IoT Hub supports the concept of a Device Twin.

A device twin is a JSON document, stored, for example, in Azure DocumentDB, that contains additional metadata about a device that allows devices and backend services to synchronize device configurations, or it can be used to understand the state of any long-running operations that a device is reporting on. This metadata can include the following:

Device twins provide a mechanism to maintain the configuration state of a device using reported properties and desired properties:

Using device twins is an optimal way to manage device configuration, especially when physical access to the device is either limited or unavailable. By having a device call home to update itself either on a frequency or on restart ensures the state of the device is correct for the current operating scenario.

IoT Hub supports the concept of shared access policies that are similar to the security within Event Hub. These policies can be used to create a azure (SASshared access signature (SAS) that can be used for device-to-cloud and cloud-to-device communication.

When an SAS token is created, the time for which it is valid has to be provided. Creating timebound tokens for secure access reduces the attack vector for compromised devices and enhance the overall security of the solution.

When created, an IoT Hub has the following default policies:

These policies cover the operations that are possible in an instance, but it is possible to create new policies by clicking on the Add button on the Shared access policies page and choosing which permissions apply.

With this approach, it is possible to create boundaries between operations and between different parts of a more complex solution.

In the event of a compromise, it is important to maintain a strict security protocol.

It is possible to regenerate the keys that are used for each policy, by clicking on More and then Regen key, to ensure that any device currently using it to sign SAS tokens can no longer connect without an update to the key. The connection string for a policy can be copied from the appropriate connection string text.

Shared access policies define the operations that are allowed by parts of an IoT solution, but shared access signatures should normally be used to perform the required operation.

Using SAS tokens adds an additional level of abstraction to the security protocol and ensures that keys are not sent across the wire.

SAS tokens are generated based on the device URI information, an expiry time, a cryptographic signature based on the device URI and expiry time, and a shared access policy name.

Because the token is based on an expiry time and shared access policy that defines the scope of access to IoT Hub, if a device connection string is obtained, the token can only be used for the time-period for which it is valid.

When using the managed SDKs, the creation of the SAS token is handled automatically at the time of the client connection.

If devices are capable of supporting full cryptographic certificate exchange, the security can be further enhanced through the use of X.509 certificates.

For IoT Hub, certificates can be obtained from a trusted certificate authority or self-signed. To create a self-signed certificate, you can use the New-SelfSignedCertificate PowerShell command.

The final part of the security that is supported by IoT Hub is the use of IP filtering.

IP filtering allows the creation of white lists (allowed devices or services) and black lists (denied devices or service) to further lock down and enhance the security.

IP filtering is applied by clicking on the Add button.

An IP address range is defined in CIDR format and the range is either allowed or rejected.

Messages are sent from devices to IoT Hub to provide telemetry or to query a service backend or device twin. Sending messages can be done in several languages, including NodeJS, Python, C#, and C.

To send a message using the managed SDK for C#, a Nuget package needs to be installed, which contains the code for the SDK along with dependencies required for transport and security.

Once installed, using the SDK to send a message is simple. First, you need to create a DeviceClient object and provide a connection string. The SDK takes care of generating a SAS token and uses the device connect shared access policy; the connection string should be the string for the specific device:

static DeviceClient deviceClient; 
static string connectionString = "[DEVICE-CONNECTION-STRING]"; 
 
static void Main(string[] args) 
{ 
   deviceClient = 
   DeviceClient.CreateFromConnectionString(connectionString); 
   while (true)

   {

      SendToIoTHub();

      Thread.Sleep(2000);
   
   } 
} 
 
static async void SendToIoTHub() 
{ 
   Var myObject = new MyObject(); 
   var messageString = JsonConvert.SerializeObject(myObject); 
   var message = new Message(Encoding.UTF8.GetBytes(messageString)); 
   await client.SendEventAsync(message); 
   Console.WriteLine($"Sent message: {messageString}"); 
} 

This code can be used to create a simulated device that sends messages every 2 seconds based on an object of type MyObject().

Only a few lines of code are required to start sending messages to IoT Hub, and this makes it simple to start creating the infrastructure required for an entire solution while development and build of a device is ongoing.

Once messages have been sent to IoT Hub, they can be processed using several services. However, once processed, it may be necessary to send messages back to the device. These messages could be notifications that the device wishes to know about or commands that instruct the device to perform a function or update configuration.

If using the managed SDK for C#, there is a NuGet package that needs to be installed in to a Visual Studio project to start interacting with the ServiceClient class. It is this class that allows communication with the service endpoint of the IoT Hub.

Once installed, interacting with the service endpoint is as simple as D2C messaging:

static async void SendToIoTHub(object data) 
{ 
   var messageString = JsonConvert.SerializeObject(data); 
   var message = new Message(Encoding.UTF8.GetBytes(messageString)); 
   message.Ack = DeliveryAcknowledgement.Full; 
   message.MessageId = Guid.NewGuid().ToString(); 
 
   var serviceClient = ServiceClient.CreateFromConnectionString("[IOT-HUB-
   SERVICE-POLICY-CONN-STRING"); 
   await serviceClient.SendAsync("[DeviceId]", message); 
   await serviceClient.CloseAsync(); 
} 

In this case, the ServiceClient class is created from a connection string that has the service connect policy associated with it. The outbound message has properties set for a MessageId and type of acknowledgement required from the device. In this case, DeliveryAcknowledgement.Full requests that the device sends an acknowledgement in the event of both success and failure of processing the message.

Once a message has been sent to IoT Hub from a service, it remains available for the device to pick up to account for scenarios when a device may only be occasionally connected.

To receive messages on a device, the DeviceClient class is used once again, and this requires installation of the NuGet package for the managed SDK for C#. Unlike the method for sending messages, which creates the shared access signature as part of the call, when receiving messages the shared access signature must be supplied:

static DeviceClient deviceClient; 
 
static void Main(string[] args) 
{ 
   deviceClient = 
   DeviceClient.CreateFromConnectionString("[DEVICE-CONN-STRING-INCLUDING-
   SAS-TOKEN]"); 
 
   ReceiveIoTHub(); 
   Console.ReadLine(); 
} 
private static async void ReceiveIoTHub() 
{ 
   while (true) 
   { 
       Message receivedMessage = await deviceClient.ReceiveAsync(); 
          
       if (receivedMessage == null) continue; 
 
      Console.WriteLine("
Receiving message"); 
            var message = 
            Encoding.UTF8.GetString(receivedMessage.GetBytes()); 
      Console.WriteLine("Message: {0}", message); 
 
      await deviceClient.CompleteAsync(receivedMessage); 
   } 
} 

In this code, there is a loop that keeps polling the IoT Hub device endpoint for messages. Upon receiving a message, it can be processed as appropriate. Once it has been processed, CompleteAsync is called, which delivers the notification back to IoT Hub.

Again, the amount of code required to receive messages in IoT Hub when using one of the managed SDKs is very low and provides a quick route to build out a solution.

There are several Azure platform services capable of processing a stream of data from IoT Hub, for example, Stream Analytics, Azure Functions, and HDInsight. Some of the decisions required when processing telemetry data is about the immediacy of insight.

Capturing data delivers no intrinsic value, but processing the data either in real time, sometimes named the Hot Path, or in batch processing, sometimes named the Cold Path, can deliver deep insight into a process or the potential outcome of a set of separate events. This data can be combined with data from other sources to build models and derive deep learning through services such as Azure Machine Learning.

Using Azure platform services allows a solution to be built out of building block services that are designed to be stitched together. This provides a mechanism to quickly build and prototype and solution to find out early if it can deliver real business value.

One of the most useful tools for those starting with IoT Hub is Device Explorer. This provides an easy tool to use to interact directly with device and service endpoints as well as the device identity registry.

Once the IoT connection string has been entered on the Configuration tab and Update clicked, the application provides a mechanism to create, update, or delete devices, and to generate SAS tokens based on a configurable TTL. For devices in the Management tab, right-clicking opens a context menu that allows you to copy the device connection string.

The Data and Messages To Device tabs allows the application to act as a message consumer service backend and a service backend sending messages to a device.

The Data tab is useful when checking the content of the data being sent by the chosen device and provides a mechanism to check the connectivity of the device to the IoT Hub. Likewise, the Messages To Device tab provides a mechanism to check the connectivity between the outbound message communication between an IoT Hub backend service and a device.

For cross-platform support, there is a Node.js application that allows some management of IoT Hub and device identities.

With Node.js installed, iothub-explorer can be installed from the command prompt or terminal window with the following command:

npm install -g iothub-explorer@latest 

Once installed, calling the application with the --help command switch shows all the commands and their functionality.

Using a PowerShell command prompt is convenient as it allows variables to be assigned for use within commands. For example, issuing the following command assigns the connection string to a variable that can then be used during a session:

$conn = [YOUR CONNECTION STRING] 

Once stored, commands can be issued as necessary. Before performing any functions, a connection must be established with the IoT Hub instance:

iothub-explorer login $conn 

Once logged in, commands can then be issued as normal without the need to pass in a connection string. For example, to list the deviceId and connectionState of all devices, you would issue the following:

iothub-explorer list --display="deviceId, connectionState" 

The one exception to the rule for not having to supply a connection string once logged in is if you wish to monitor events for a specific device:

iothub-explorer $conn monitor-events [deviceId] 

The iothub-explorer is a good tool if you are used to using a command line when working with resources. Although it is not capable of doing everything, it is a handy tool to have available.

To overcome the issue when a device is unable to communicate using one of the IoT Hub-supported protocols, a protocol gateway must be used to act as a bridge between a device and IoT Hub.

Azure IoT Hub provides a sample protocol gateway that is open source. This gateway acts as a protocol translator and can run on capable devices that sit between deployed devices and IoT Hub or in a cloud service that is running in Microsoft Azure that can communicate with the devices.

The sample shows how to translate from MQTT. However, because MQTT is fully supported within IoT Hub, the sample is there as a means to show how to translate from a protocol that is available on low-powered and low capability devices.

A scenario would be simple sensors that are deployed and can communicate via protocols such as CoAP, which is a popular protocol on constrained devices, but for which no support currently exists within IoT Hub. In this case, a gateway could be deployed on a device in the field that can communicate with the devices via CoAP, and it could translate these messages to AMQP for delivery to IoT Hub.

Another scenario where it is important to consider the deployment of a field gateway is when local computing resources are required to process messages before they are transmitted. This could include protocol translation, as possible with the IoT Hub protocol gateway, or could include more complex stream processing computing such as translation or data enrichment.

Having local compute resources also ensures that action can be taken by the gateway in the event of the Internet connection being unavailable.

Consider a scenario where a valve is reporting inlet pressure for a gas pipeline. In this scenario, imagine what the consequence would be if the only analysis of this data was performed in the cloud. It may be important to understand if the data is showing a trend that indicates the inlet pressure is increasing. In this case, it may be necessary to close the valve to protect equipment and life downstream of the valve. If the only analysis is done in the cloud and the connection is not available, damage to equipment or loss of life could occur. Having a gateway that is capable of making decision based on the streaming data becomes important in this case.

Fog Computing is the name given to local computing resources in this example and is increasingly important in the industrial and manufacturing sectors.