IoT Hub provides built-in endpoints that can be easily used with IoT SDK. The following image with reference from the Microsoft Azure IoT documentation gives a snapshot of all the endpoints an IoT Hub gives:

IoT Hub provides HTTP rest APIs for device provisioning. These device identities are used for authentication purposes with access controls. This endpoint provides different operations to manage devices:

• Create devices: Using the create method, you can easily create a device in the IoT Hub. This will create and assign a unique key to each device, which will be required for each communication of that device.
• Update devices: Using update device API, we are able to control the current state of the device, whether to disable or enable the device.
• Delete devices by using deviceId: If device is no longer required to be registered or communicated with, we can remove it from the Hub using the delete API.
• Some of the other useful operations are:
  • Retrieve devices by using deviceId
  • List up to 1000 device identities
  • Import device identities from Azure Blob storage
  • Export all device identities to Azure Blob storage

For each IoT enabled device that is provisioned and registered with IoT Hub, it provides device endpoints which expose the sent or received message endpoints.

A message from device-to-cloud is sent through a device-facing endpoint, then internally, IoT Hub puts these messages for the devices. You can pull these messages using device registration details such as the device ID and device key. In the coming chapters, we will be doing this practically.

Other frequently used endpoints are cloud-to-device, which act as the route for bidirectional communication.

IoT Hub has started supporting file ingestion also. When we have a large file to upload or a batch of telemetry, file ingestion is best suited for these scenarios.

We can configure the blob storage account within IoT Hub and, using the device IoT SDKs, the file will be uploaded. On completion, IoT Hub will check and publish a message for service endpoints to work further on the data.

Device twin is a document store collection of all devices, in which each collection can store multiple device's metadata, configurations and so on. A device twin is useful for storing a device's specific details in the cloud, finding out the current state of the device. Whenever a device or backend system needs to sync device information, a device twin is used which holds the latest state of it.

Direct methods is a way IoT Hub helps to control a device directly such as an HTTP communication. When we want a result or an action to be taken by a device, a direct method is used, where we immediately get a response from the device through this communication.

A service endpoint enables any backend system to interact with the IoT Hub. These endpoints allow the backend to perform operations such as:

• Receiving cloud-to-device messages.
• Sending cloud-to-device messages and getting an acknowledgement for the same.
• File ingestion officiation, if this method is used for telemetry.
• Direct method invocation. A backend system can invoke any direct method on the device.

Scheduling jobs on multiple devices is a way in which we can perform an operation in bulk. For example, if we need to update device properties for a set of devices or invoke some direct methods on a group of devices, this is useful at the execution level.

A backend application can schedule the activities planned for a group of devices.