The surprising truth about MQTT on Azure IoT Hub is that it’s not just a transport protocol; it’s a deeply integrated messaging pattern that dictates how your devices communicate with the cloud, and how the cloud orchestrates those devices.
Let’s see it in action. Imagine a simple temperature sensor. On the device, you’d configure an MQTT client like Paho or Mosquitto.
import paho.mqtt.client as mqtt
import ssl
broker_address = "your-iot-hub.azure-devices.net"
port = 8883 # Standard TLS port for MQTT
client_id = "your-device-id"
username = "your-iot-hub.azure-devices.net/your-device-id/\nyour-sas-token" # SAS token goes here
password = "your-sas-token"
client = mqtt.Client(client_id=client_id)
client.username_pw_set(username=username, password=password)
client.tls_set(tls_version=ssl.PROTOCOL_TLSv1_2) # Use TLS for security
def on_connect(client, userdata, flags, rc):
if rc == 0:
print("Connected to Azure IoT Hub!")
else:
print(f"Failed to connect, return code {rc}\n")
def on_publish(client, userdata, mid):
print(f"Message Published: {mid}")
client.on_connect = on_connect
client.on_publish = on_publish
client.connect(broker_address, port)
client.loop_start() # Start a background thread for network communication
# Publish a telemetry message
temperature = 25.5
payload = f'{{"temperature": {temperature}}}'
topic = "devices/your-device-id/messages/events/" # Standard telemetry topic
client.publish(topic, payload)
# Keep the script running to maintain the connection
import time
time.sleep(60)
client.loop_stop()
This code snippet, using the Paho MQTT client library, establishes a secure TLS connection to your Azure IoT Hub endpoint. The client_id is crucial, and it’s your device’s unique identifier. The username is a combination of your IoT Hub hostname, device ID, and a Shared Access Signature (SAS) token for authentication. The password is the actual SAS token itself.
Once connected, the device subscribes to specific topics. For sending telemetry (device-to-cloud messages), the topic is devices/{your-device-id}/messages/events/. For receiving direct commands from the cloud, the topic is devices/{your-device-id}/messages/devicebound/commands/#. The # is a wildcard that allows subscribing to multiple command types.
Azure IoT Hub acts as the MQTT broker, but with specialized routing and management capabilities. When a device publishes to devices/your-device-id/messages/events/, IoT Hub intercepts it. It then uses its built-in routing rules to forward this message to other Azure services like Azure Blob Storage, Azure Event Hubs, or Azure Service Bus, based on your configuration.
Conversely, when you want to send a command to a device, you publish to a specific topic that IoT Hub monitors. For example, a direct method call would be published to devices/{your-device-id}/messages/devicebound/commands/method. IoT Hub then ensures this message reaches the correct device, which is subscribed to devices/your-device-id/messages/devicebound/commands/#.
The real power comes from understanding the topic structure and the message types. Azure IoT Hub supports several message patterns:
- Telemetry (Device-to-Cloud): Devices send data to IoT Hub. Topic:
devices/{device_id}/messages/events/. - C2D Commands (Cloud-to-Device): IoT Hub sends commands to devices. Topic:
devices/{device_id}/messages/devicebound/commands/{command_name}. Devices subscribe todevices/{device_id}/messages/devicebound/commands/#. - Device Twin Properties: Devices report their desired state and update reported properties. Topic for reporting:
devices/{device_id}/twin/PATCH. IoT Hub subscribes to this to update device twins. - Direct Methods: Synchronous request/response communication. Devices receive method calls on
devices/{device_id}/messages/devicebound/commands/methodand respond on/methods/res/{status_code}.
The device twin is a cloud representation of your physical device. It has desired properties set by the cloud and reported properties updated by the device. When you update desired properties in the cloud (e.g., set a new target temperature), IoT Hub sends a message to the device’s twin topic (devices/{device_id}/twin/PATCH). The device then receives this, updates its local state, and reports the new state back by patching its reported properties. This asynchronous, state-based communication is a cornerstone of IoT Hub’s device management.
The one thing most people don’t realize is that Azure IoT Hub’s MQTT broker isn’t just a dumb pipe; it actively participates in message routing and device twin synchronization. When a device sends a telemetry message to devices/{device_id}/messages/events/, IoT Hub doesn’t just forward it. It also inspects the message payload and can conditionally route it to different endpoints based on rules you define in the IoT Hub portal or via ARM templates. For instance, you can route messages with a temperature greater than 30 degrees Celsius to a specific storage account, while all other messages go to a default Event Hub. This built-in intelligence means you don’t need a separate middleware layer for basic message filtering and routing.
Understanding these topic patterns and the device twin’s role is key to building robust IoT solutions on Azure.