Skip main navigation

IoT Hub Messaging

.

In this step, we’ll learn about IoT Hub messaging.

We’ll take a look at:

  • How Azure IoT Hub manages messages
  • How device-to-cloud and cloud-to-device messaging works
  • How to manage the messaging life cycle using Azure IoT Hub.

As we noted in the previous topic, IoT Hub provides the following messaging primitives to communicate with a device:

  • Device-to-cloud from a device to a back-end app.
  • Cloud-to-device from a back-end app (service or cloud).

Core properties of IoT Hub messaging functionality are the reliability and durability of messages. These properties enable resilience to intermittent connectivity on the device side, and to load spikes in event processing on the cloud side. IoT Hub implements once delivery guarantees for both device-to-cloud and cloud-to-device messaging.

IoT Hub supports multiple device-facing protocols (such as MQTT, AMQP, and HTTP). To support seamless interoperability across protocols, IoT Hub defines a common message format that all device-facing protocols support.

IoT Hub exposes a built-in Event Hub-compatible endpoint to enable back-end apps to read the device-to-cloud messages received by the Hub. You can also create custom endpoints in your IoT Hub by linking other services in your subscription to the Hub.

Use device-to-cloud messages for sending time-series telemetry and alerts from your device app, and cloud-to-device messages for one-way notifications to the device app.

Device-To-Cloud

You send device-to-cloud messages through a device-facing endpoint (/devices//messages/events). Routing rules then route your messages to one of the service-facing endpoints on your IoT Hub. Routing rules use the properties of the device-to-cloud messages flowing through your hub to determine where to route them. By default, messages are routed to the built-in service-facing endpoint (messages/events) that’s compatible with Event Hubs. Therefore, you can use standard Event Hubs integration and SDKs to receive device-to-cloud messages.

IoT Hub implements device-to-cloud messaging using a streaming messaging pattern. IoT Hub’s device-to-cloud messages are more like Event Hubs events than Service Bus messages in that there’s a high volume of events passing through the service that can be read by multiple readers.

This implementation has the following implications:

  • Like Event Hubs events, device-to-cloud messages are durable and retained in an IoT Hub’s default messages/events endpoint for up to seven days.
  • Like Event Hubs events, device-to-cloud messages can be at most 256 KB, and can be grouped in batches to optimise sends. Batches can be at most 256 KB.

There are, however, a few important distinctions between IoT Hub device-to-cloud messaging and Event Hubs:

  • IoT Hub allows per-device authentication and access control.
  • IoT Hub allows you to create up to 10 custom endpoints. Messages are delivered to the endpoints based on routes configured on your IoT Hub.
  • IoT Hub allows millions of simultaneously connected devices (see Quotas and throttling), while Event Hubs is limited to 5000 AMQP connections per namespace.
  • IoT Hub does not allow arbitrary partitioning using a PartitionKey. Device-to-cloud messages are partitioned based on their originating device.
  • Scaling IoT Hub is slightly different than scaling Event Hubs.
  • Cloud-To-Device
  • You send cloud-to-device messages through a service-facing endpoint (/messages/device bound). A device receives them through a device-specific endpoint (/devices//messages/device bound).

Each cloud-to-device message is targeted at a single device by setting the to property to /devices//messages/devicebound.

Message Lifecycle

To guarantee message delivery, IoT Hub persists cloud-to-device messages in per-device queues. Devices must explicitly acknowledge completion for IoT Hub to remove them from the queue. This guarantees resilience against connectivity and device failures.

Cloud-To-Device-Messaging

When the service sends a message, it’s considered Enqueued. When a device wants to receive a message, IoT Hub locks the message (sets the state to Invisible) allowing other threads on the same device to start receiving other messages. When a device thread completes the processing of a message, it notifies IoT Hub by completing the message.

A device can also:

  • Reject the message, which causes IoT Hub to set it to the Deadlettered state. Note: devices connecting with MQTT cannot reject cloud-to-device messages.
  • Abandon the message, which causes IoT Hub to put the message back in the queue, with the state set to Enqueued.

A thread could fail to process a message without notifying IoT Hub. In this case, messages automatically transition from the Invisible state back to the Enqueued state after a visibility (or lock) timeout. The default value of this timeout is one minute.

A message can transition between the Enqueued and Invisible states for the number of times specified in the max delivery count property on IoT Hub. After that number of transitions, IoT Hub sets the state of the message to Deadlettered. Similarly, IoT Hub sets the state of a message to Deadlettered after its expiration time (see Time to live).

Do you have a good understanding of Hub messaging? If so, mark this step as complete and let’s move on to IoT device configuration.

This article is from the free online

Microsoft Future Ready: Fundamentals of Internet of Things (IoT)

Created by
FutureLearn - Learning For Life

Our purpose is to transform access to education.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.

Learn more about how FutureLearn is transforming access to education