I am working on the Azure IoT platform, and I understand how devices send data to the IoT hub (if I am not wrong, It is just web service call or something similar to that).

But I wonder how the IoT hub sends Data/Command/Input to the devices, because we are not working on the IoT hub for Device communication (we don't have any requirement to push data to devices). Can the IoT hub directly interact with the devices? (Using the unique Id of device or using any unique identity like IP, Mac address, etc).

Somewhere I've read that devices keep requesting to the IoT hub if IoT hub have any input for them, and the IoT hub then sends Data/Command/Input to devices in response. Is that true? If not, then please explain.


1 Answer 1


The model that IoT Hub connected devices use is that they will never accept incoming connections. IoT Hub devices never act as a 'server', and this is a crucial part of the security model in Azure IoT. The definitive model on this is encapsulated in Clemens Vasters' 'Service Assisted Communication'.

Therefore devices are always 'polling' an external service in order to send data or receive commands. The APIs make it look like data is being sent to a device, but it is always the device making the outgoing connection.

IoT hub does this in two ways:

  1. By sending data to the device endpoint /devices/{deviceId}/messages/devicebound. This is an AMQP messaging endpoint, similar to a queue or topic subscription. The device, when reading commands, needs to acknowledged receipt if needed, which is part of the underlying AMQP protocol. This works the same with MQTT, and https is a valid fallback. The API wraps all of this up for you. There are additional concepts, such as 'direct methods' which are an API wrapper around essentially the same underlying message protocol
  2. By using the server-side device twin, which is a way to logically keep properties in sync between device and server. You set a property on the device twin, and when the device syncs up that property will be synced to the device. This is less message-based and built on top of the LWM2M device management protocol.

A lot of the 'polling', connecting, sharing connections, receipts, etc should be taken care of as part of the AMQP (or MQTT) protocol, which in turn is wrapped up in the IoT Hub SDK. So the above is highly simplified, but to reiterate, IoT Hub cannot, and will not (ever) try and send data to a ip address/port on your device.

  • Thanks @Simon, Now I'm clear about that, devices only responsible to call IoT hub for sending or receiving data. You mentioned "Azure IoT" in your answer, so just want to confirm that, your answer application across all IoT platforms? or for Azure IoT only.
    – Shri
    Mar 9, 2017 at 13:20
  • @ShrikantBhusalwad The answer can't apply to all platforms, because many have not been developed yet. This is a common model, it's good for security, but other models might be justified - particularly in a new environment. Mar 9, 2017 at 13:29
  • 2
    I'm not familiar with all platforms, but most cloud platforms will be similar. AWS uses MQTT, which is mostly the same. As @sean observes, it cannot apply to all platforms, but very few cloud platforms will bake-in risky security practices up front. Methods that use device-as-server models will either be legacy or have far more security rigour (as edge or mesh patterns develop). Azure IoT architecturally supports field and cloud gateways to get around issues with legacy or edge-based devices Mar 9, 2017 at 19:17
  • Azure IoT Hub MQTT rules are spelled out at docs.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support Jul 18, 2019 at 12:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.