Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article lists some of the common terms used in the IoT Hub articles.
Advanced Message Queueing Protocol
Advanced Message Queueing Protocol (AMQP) is one of the messaging protocols that IoT Hub supports for communicating with devices. For more information about the messaging protocols that IoT Hub supports, see Send and receive messages with IoT Hub.
Automatic Device Management
Automatic Device Management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. With Automatic Device Management, you can target a set of devices based on their properties, define a desired configuration, and let IoT Hub update devices whenever they come into scope. Consists of automatic device configurations and IoT Edge automatic deployments.
Automatic device configuration
Your solution back end can use automatic device configurations to assign desired properties to a set of device twins and report status using system metrics and custom metrics.
Azure classic CLI
The Azure classic CLI is a cross-platform, open-source, shell-based, command tool for creating and managing resources in Azure. This version of the CLI should be used for classic deployments only.
Azure CLI
The Azure CLI is a cross-platform, open-source, shell-based, command tool for creating and managing resources in Azure.
Azure IoT device SDKs
There are device SDKs available for multiple languages that enable you to create device apps that interact with an IoT hub. The IoT Hub tutorials show you how to use these device SDKs. You can find the source code and further information about the device SDKs in this GitHub repository.
Azure IoT Explorer
The Azure IoT Explorer is used to view the telemetry the device is sending, work with device properties, and call commands. You can also use the explorer to interact with and test your devices, and to manage plug and play devices.
Azure IoT service SDKs
There are service SDKs available for multiple languages that enable you to create back-end apps that interact with an IoT hub. The IoT Hub tutorials show you how to use these service SDKs. You can find the source code and further information about the service SDKs in this GitHub repository.
Azure IoT Tools
The Azure IoT Tools is a cross-platform, open-source Visual Studio Code extension that helps you manage Azure IoT Hub and devices in VS Code. With Azure IoT Tools, IoT developers could develop IoT project in VS Code with ease.
Azure portal
The Azure portal is a central place where you can provision and manage your Azure resources. It organizes its content using blades.
Azure PowerShell
Azure PowerShell is a collection of cmdlets you can use to manage Azure with Windows PowerShell. You can use the cmdlets to create, test, deploy, and manage solutions and services delivered through the Azure platform.
Azure Resource Manager
Azure Resource Manager enables you to work with the resources in your solution as a group. You can deploy, update, or delete the resources for your solution in a single, coordinated operation.
Azure Service Bus
Service Bus provides cloud-enabled communication with enterprise messaging and relayed communication that helps you connect on-premises solutions with the cloud. Some IoT Hub tutorials make use Service Bus queues.
Azure Storage
Azure Storage is a cloud storage solution. It includes the Blob Storage service that you can use to store unstructured object data. Some IoT Hub tutorials use blob storage.
Back-end app
In the context of IoT Hub, a back-end app is an app that connects to one of the service-facing endpoints on an IoT hub. For example, a back-end app might retrieve device-to-cloudmessages or manage the identity registry. Typically, a back-end app runs in the cloud, but in many of the tutorials the back-end apps are console apps running on your local development machine.
Built-in endpoints
Every IoT hub includes a built-in endpoint that is Event Hub-compatible. You can use any mechanism that works with Event Hubs to read device-to-cloud messages from this endpoint.
Cloud gateway
A cloud gateway enables connectivity for devices that cannot connect directly to IoT Hub. A cloud gateway is hosted in the cloud in contrast to a field gateway that runs local to your devices. A typical use case for a cloud gateway is to implement protocol translation for your devices.
Cloud-to-device
Refers to messages sent from an IoT hub to a connected device. Often, these messages are commands that instruct the device to take an action. For more information, see Send and receive messages with IoT Hub.
Configuration
In the context of automatic device configuration, a configuration within IoT Hub defines the desired configuration for a set of devices twins and provides a set of metrics to report status and progress.
Connection string
You use connection strings in your app code to encapsulate the information required to connect to an endpoint. A connection string typically includes the address of the endpoint and security information, but connection string formats vary across services. There are two types of connection string associated with the IoT Hub service:
- Device connection strings enable devices to connect to the device-facing endpoints on an IoT hub.
- IoT Hub connection strings enable back-end apps to connect to the service-facing endpoints on an IoT hub.
Custom endpoints
You can create custom endpoints on an IoT hub to deliver messages dispatched by a routing rule. Custom endpoints connect directly to an Event hub, a Service Bus queue, or a Service Bus topic.
Custom gateway
A gateway enables connectivity for devices that cannot connect directly to IoT Hub. You can use Azure IoT Edge to build custom gateways that implement custom logic to handle messages, custom protocol conversions, and other processing on the edge.
Data-point message
A data-point message is a device-to-cloud message that contains telemetry data such as wind speed or temperature.
Desired configuration
In the context of a device twin, desired configuration refers to the complete set of properties and metadata in the device twin that should be synchronized with the device.
Desired properties
In the context of a device twin, desired properties is a subsection of the device twin that is used with reported properties to synchronize device configuration or condition. Desired properties can only be set by a back-end app and are observed by the device app.
Device-to-cloud
Refers to messages sent from a connected device to IoT Hub. These messages may be data point or interactive messages. For more information, see Send and receive messages with IoT Hub.
Device
In the context of IoT, a device is typically a small-scale, standalone computing device that may collect data or control other devices. For example, a device might be an environmental monitoring device, or a controller for the watering and ventilation systems in a greenhouse. The device catalog provides a list of hardware devices certified to work with IoT Hub.
Device app
A device app runs on your device and handles the communication with your IoT hub. Typically, you use one of the Azure IoT device SDKs when you implement a device app. In many of the IoT tutorials, you use a simulated device for convenience.
Device condition
Refers to device state information, such as the connectivity method currently in use, as reported by a device app. Device apps can also report their capabilities. You can query for condition and capability information using device twins.
Device data
Device data refers to the per-device data stored in the IoT Hub identity registry. It is possible to import and export this data.
Device explorer
The device explorer has been replaced with the Azure IoT Explorer, which is used to view the telemetry the device is sending, work with device properties, and call commands. You can also use the explorer to interact with and test your devices, and to manage plug and play devices.
Device identity
The device identity is the unique identifier assigned to every device registered in the identity registry.
Device management
Device management encompasses the full lifecycle associated with managing the devices in your IoT solution including planning, provisioning, configuring, monitoring, and retiring
Device management patterns
IoT hub enables common device management patterns including rebooting, performing factory resets, and performing firmware updates on your devices.
Device REST API
You can use the Device REST API from a device to send device-to-cloud messages to an IoT hub, and receive cloud-to-device messages from an IoT hub. Typically, you should use one of the higher-level device SDKs as shown in the IoT Hub tutorials.
Device provisioning
Device provisioning is the process of adding the initial device data to the stores in your solution. To enable a new device to connect to your hub, you must add a device ID and keys to the IoT Hub identity registry. As part of the provisioning process, you might need to initialize device-specific data in other solution stores.
Device twin
A device twin is JSON document that stores device state information such as metadata, configurations, and conditions. IoT Hub persists a device twin for each device that you provision in your IoT hub. Device twins enable you to synchronize device conditions and configurations between the device and the solution back end. You can query device twins to locate specific devices and query the status of long-running operations.
Direct method
A direct method is a way for you to trigger a method to execute on a device by invoking an API on your IoT hub.
Endpoint
An IoT hub exposes multiple endpoints that enable your apps to connect to the IoT hub. There are device-facing endpoints that enable devices to perform operations such as sending device-to-cloud messages and receiving cloud-to-device messages. There are service-facing management endpoints that enable back-end apps to perform operations such as device identity management and device twin management. There are service-facing built-in endpoints for reading device-to-cloud messages. You can create custom endpoints to receive device-to-cloud messages dispatched by a routing rule.
Event Hubs service
Event Hubs is a highly scalable data ingress service that can ingest millions of events per second. The service enables you to process and analyze the massive amounts of data produced by your connected devices and applications. For a comparison with the IoT Hub service, see Comparison of Azure IoT Hub and Azure Event Hubs.
Event Hub-compatible endpoint
To read device-to-cloud messages sent to your IoT hub, you can connect to an endpoint on your hub and use any Event Hub-compatible method to read those messages. Event Hub-compatible methods include using the Event Hubs SDKs and Azure Stream Analytics.
Field gateway
A field gateway enables connectivity for devices that cannot connect directly to IoT Hub and is typically deployed locally with your devices. For more information, see What is Azure IoT Hub?
Trial Subscription
You can create a Azure account to complete the IoT Hub tutorials and experiment with the IoT Hub service (and other Azure services).
Gateway
A gateway enables connectivity for devices that cannot connect directly to IoT Hub. See also Field Gateway, Cloud Gateway, and Custom Gateway.
Identity registry
The identity registry is the built-in component of an IoT hub that stores information about the individual devices permitted to connect to an IoT hub.
Interactive message
An interactive message is a cloud-to-device message that triggers an immediate action in the solution back end. For example, a device might send an alarm about a failure that should be automatically logged in to a CRM system.
Automatic Device Management
Automatic Device Management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. With Automatic Device Management, you can target a set of devices based on their properties, define a desired configuration, and let IoT Hub update devices whenever they come into scope. Consists of automatic device configurations and IoT Edge automatic deployments.
IoT Edge
Azure IoT Edge enables cloud-driven deployment of Azure services and solution-specific code to on-premises devices. IoT Edge devices can aggregate data from other devices to perform computing and analytics before the data is sent to the cloud. For more information, see Azure IoT Edge.
IoT Edge agent
The part of the IoT Edge runtime responsible for deploying and monitoring modules.
IoT Edge device
IoT Edge devices have the IoT Edge runtime installed and are flagged as “IoT Edge device” in the device details. Learn how to deploy Azure IoT Edge on a simulated device in Linux - preview.
IoT Edge automatic deployment
An IoT Edge automatic deployment configures a target set of IoT Edge devices to run a set of IoT Edge modules. Each deployment continuously ensures that all devices that match its target condition are running the specified set of modules, even when new devices are created or are modified to match the target condition. Each IoT Edge device only receives the highest priority deployment whose target condition it meets. Learn more about IoT Edge automatic deployment.
IoT Edge deployment manifest
A Json document containing the information to be copied in one or more IoT Edge devices' module twin(s) to deploy a set of modules, routes and associated module desired properties.
IoT Edge gateway device
An IoT Edge device with downstream device. The downstream device can be either IoT Edge or not IoT Edge device.
IoT Edge hub
The part of the IoT Edge runtime responsible for module to module communications, upstream (toward IoT Hub) and downstream (away from IoT Hub) communications.
IoT Edge leaf device
An IoT Edge device with no downstream device.
IoT Edge module
An IoT Edge module is a Docker container that you can deploy to IoT Edge devices. It performs a specific task, such as ingesting a message from a device, transforming a message, or sending a message to an IoT hub. It communicates with other modules and sends data to the IoT Edge runtime. Understand the requirements and tools for developing IoT Edge modules.
IoT Edge module identity
A record in the IoT Hub module identity registry detailing the existence and security credentials to be used by a module to authenticate with an edge hub or IoT Hub.
IoT Edge module image
The docker image that is used by the IoT Edge runtime to instantiate module instances.
IoT Edge module twin
A Json document persisted in the IoT Hub that stores the state information for a module instance.
IoT Edge priority
When two IoT Edge deployments target the same device, the deployment with higher priority gets applied. If two deployments have the same priority, the deployment with the later creation date gets applied. Learn more about priority.
IoT Edge runtime
IoT Edge runtime includes everything that Microsoft distributes to be installed on an IoT Edge device. It includes Edge agent, Edge hub, and the IoT Edge security daemon.
IoT Edge set modules to a single device
An operation that copies the content of an IoT Edge manifest on one device' module twin. The underlying API is a generic 'apply configuration', which simply takes an IoT Edge manifest as an input.
IoT Edge target condition
In an IoT Edge deployment, Target condition is any Boolean condition on device twins’ tags to select the target devices of the deployment, for example tag.environment = prod. The target condition is continuously evaluated to include any new devices that meet the requirements or remove devices that no longer do. Learn more about target condition
IoT Hub
IoT Hub is a fully managed Azure service that enables reliable and secure bidirectional communications between millions of devices and a solution back end. For more information, see What is Azure IoT Hub? Using your Azure subscription, you can create IoT hubs to handle your IoT messaging workloads.
IoT Hub metrics
IoT Hub metrics give you data about the state of the IoT hubs in your Azure subscription. IoT Hub metrics enable you to assess the overall health of the service and the devices connected to it. IoT Hub metrics can help you see what is going on with your IoT hub and investigate root-cause issues without needing to contact Azure support.
IoT Hub query language
The IoT Hub query language is a SQL-like language that enables you to query your Job and device twins.
IoT Hub Resource REST API
You can use the IoT Hub Resource REST API to manage the IoT hubs in your Azure subscription performing operations such as creating, updating, and deleting hubs.
IoT solution accelerators
Azure IoT solution accelerators package together multiple Azure services into solutions. These solutions enable you to get started quickly with end-to-end implementations of common IoT scenarios.
The IoT extension for Azure CLI
The IoT extension for Azure CLI is a cross-platform, command-line tool. The tool enables you to manage your devices in the identity registry, send and receive messages and files from your devices, and monitor your IoT hub operations.
Job
Your solution back end can use jobs to schedule and track activities on a set of devices registered with your IoT hub. Activities include updating device twin desired properties, updating device twin tags, and invoking direct methods. IoT Hub also uses to import to and export from the identity registry.
Modules
On the device side, the IoT Hub device SDKs enable you to create modules where each one opens an independent connection to IoT Hub. This functionality enables you to use separate namespaces for different components on your device.
Module identity and module twin provide the same capabilities as device identity and device twin but at a finer granularity. This finer granularity enables capable devices, such as operating system-based devices or firmware devices managing multiple components, to isolate configuration and conditions for each of those components.
Module identity
The module identity is the unique identifier assigned to every module that belong to a device. Module identity is also registered in the identity registry.
Module twin
Similar to device twin, a module twin is JSON document that stores module state information such as metadata, configurations, and conditions. IoT Hub persists a module twin for each module identity that you provision under a device identity in your IoT hub. Module twins enable you to synchronize module conditions and configurations between the module and the solution back end. You can query module twins to locate specific modules and query the status of long-running operations.
MQTT
MQTT is one of the messaging protocols that IoT Hub supports for communicating with devices. For more information about the messaging protocols that IoT Hub supports, see Send and receive messages with IoT Hub.
Operations monitoring
IoT Hub operations monitoring enables you to monitor the status of operations on your IoT hub in real time. IoT Hub tracks events across several categories of operations. You can opt into sending events from one or more categories to an IoT Hub endpoint for processing. You can monitor the data for errors or set up more complex processing based on data patterns.
Physical device
A physical device is a real device such as a Raspberry Pi that connects to an IoT hub. For convenience, many of the IoT Hub tutorials use simulated devices to enable you to run samples on your local machine.
Primary and secondary keys
When you connect to a device-facing or service-facing endpoint on an IoT hub, your connection string includes key to grant you access. When you add a device to the identity registry or add a shared access policy to your hub, the service generates a primary and secondary key. Having two keys enables you to roll over from one key to another when you update a key without losing access to the IoT hub.
Protocol gateway
A protocol gateway is typically deployed in the cloud and provides protocol translation services for devices connecting to IoT Hub. For more information, see What is Azure IoT Hub?
Quotas and throttling
There are various quotas that apply to your use of IoT Hub, many of the quotas vary based on the tier of the IoT hub. IoT Hub also applies throttles to your use of the service at run time.
Reported configuration
In the context of a device twin, reported configuration refers to the complete set of properties and metadata in the device twin that should be reported to the solution back end.
Reported properties
In the context of a device twin, reported properties is a subsection of the device twin used with desired properties to synchronize device configuration or condition. Reported properties can only be set by the device app and can be read and queried by a back-end app.
Resource group
Azure Resource Manager uses resource groups to group related resources together. You can use a resource group to perform operations on all the resources on the group simultaneously.
Retry policy
You use a retry policy to handle transient errors when you connect to a cloud service.
Routing rules
You configure routing rules in your IoT hub to route device-to-cloud messages to a built-in endpoint or to custom endpoints for processing by your solution back end.
SASL PLAIN
SASL PLAIN is a protocol that the AMQP protocol uses to transfer security tokens.
Service REST API
You can use the Service REST API from the solution back end to manage your devices. The API enables you to retrieve and update device twin properties, invoke direct methods, and schedule jobs. Typically, you should use one of the higher-level service SDKs as shown in the IoT Hub tutorials.
Shared access signature
Shared Access Signatures (SAS) are an authentication mechanism based on SHA-256 secure hashes or URIs. SAS authentication has two components: a Shared Access Policy and a Shared Access Signature (often called a token). A device uses SAS to authenticate with an IoT hub. Back-end apps also use SAS to authenticate with the service-facing endpoints on an IoT hub. Typically, you include the SAS token in the connection string that an app uses to establish a connection to an IoT hub.
Shared access policy
A shared access policy defines the permissions granted to anyone who has a valid primary or secondary key associated with that policy. You can manage the shared access policies and keys for your hub in the portal.
Simulated device
For convenience, many of the IoT Hub tutorials use simulated devices to enable you to run samples on your local machine. In contrast, a physical device is a real device such as a Raspberry Pi that connects to an IoT hub.
Solution
A solution can refer to a Visual Studio solution that includes one or more projects. A solution might also refer to an IoT solution that includes elements such as devices, device apps, an IoT hub, other Azure services, and back-end apps.
Subscription
An Azure subscription is where billing takes place. Each Azure resource you create or Azure service you use is associated with a single subscription. Many quotas also apply at the level of a subscription.
System properties
In the context of a device twin, system properties are read-only and include information regarding the device usage such as last activity time and connection state.
Tags
In the context of a device twin, tags are device metadata stored and retrieved by the solution back end in the form of a JSON document. Tags are not visible to apps on a device.
Telemetry
Devices collect telemetry data, such as wind speed or temperature, and use data-point messages to send the telemetry to an IoT hub.
Token service
You can use a token service to implement an authentication mechanism for your devices. It uses an IoT Hub shared access policy with DeviceConnect permissions to create device-scoped tokens. These tokens enable a device to connect to your IoT hub. A device uses a custom authentication mechanism to authenticate with the token service. IF the device authenticates successfully, the token service issues a SAS token for the device to use to access your IoT hub.
Twin queries
Device and module twin queries use the SQL-like IoT Hub query language to retrieve information from your device twins or module twins. You can use the same IoT Hub query language to retrieve information about a Job running in your IoT hub.
Twin synchronization
Twin synchronization uses the desired properties in your device twins or module twins to configure your devices or modules and retrieve reported properties from them to store in the twin.
X.509 client certificate
A device can use an X.509 certificate to authenticate with IoT Hub. Using an X.509 certificate is an alternative to using a SAS token.