Reference · built on requestConnectorSensors, meters & gateways

Azure IoT Hub

Device-to-cloud telemetry, device twins, direct methods, and routed events from Azure IoT Hub.

Request accessPricing ↗

About

Azure IoT Hub is Microsoft's managed service for device messaging. Every hub keeps an identity registry of the devices and modules allowed to connect, each with symmetric keys or an X.509 certificate. Devices send telemetry over MQTT, AMQP, or HTTPS to a built-in Event Hubs-compatible endpoint that retains messages for up to seven days, and message routing forwards telemetry, twin change events, lifecycle events, and connection state events to Event Hubs, Service Bus, Storage, or Cosmos DB. Device twins hold tags, desired properties, and reported properties; direct methods call a device and wait for its reply.

An operator on Fibric reads the routed stream and the twins and proposes the desired property, the method call, or the ticket for your approval.

This is a reference listing. It documents what Fibric would read from Azure IoT Hub and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Device-to-cloud messages from the built-in messages/events endpoint or a custom route, with application properties, system properties, and body
  • Device twins: tags, properties.desired, properties.reported, connectionState, lastActivityTime, and $version, searched with the IoT Hub query language
  • Device twin change events, device lifecycle events, device job lifecycle events, and device connection state events as routing sources
  • Connection state snapshots taken every 60 seconds for devices on MQTT or AMQP; HTTPS-only devices produce none
  • Device and module identities in the identity registry, and the hub's daily message limit and throttling errors
  • Direct method results: the device's own status and payload, 404 when it is offline, or 504 on timeout

Proposed actions

  • Target capability: propose a partial update to a twin's desired properties or tags, sent with the etag for optimistic concurrency
  • Target capability: propose a direct method through POST /twins/{deviceId}/methods with methodName, payload, and responseTimeoutInSeconds
  • Target capability: propose a cloud-to-device message to a device's messages/devicebound endpoint
  • Target capability: propose a job that updates twins or invokes a method across many devices

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Spot the device that dropped off

    Route device connection state events and read lastActivityTime from each twin. When a device stays disconnected past its expected interval, propose the ticket with the last telemetry it sent.

    With Sensor Health, Data Freshness

  • Reconfigure a device through its twin

    When reported telemetry crosses your limit, propose a desired property such as a new sendFrequency or setpoint. The device applies it and reports back; you see the reported value change.

    With Cold Room Watch, Setpoint Drift

  • Stay under the daily message quota

    Watch the hub's daily message limit and its throttling error count. When usage trends toward the cap, propose which devices to slow or how many units to add before messages are rejected.

    With Quota Headroom, Integration Health

Requirements

  • An IoT hub in the standard tier; twins, direct methods, cloud-to-device messages, and jobs are absent from the basic tier
  • A shared access policy with ServiceConnect for twins and methods and RegistryRead for identities, or equivalent Entra ID roles
  • A route, or the fallback route, to the built-in endpoint and a consumer group for Fibric to read from
  • Devices connecting over MQTT or AMQP, including over WebSockets, if you want connection state events
Authentication
A SAS token signed with a shared access policy such as service or registryRead, granting ServiceConnect or RegistryRead at hub level, or Microsoft Entra ID roles for narrower service access; devices sign with their symmetric key or present X.509.

Limits

  • Device-to-cloud messages are capped at 256 KB, cloud-to-device at 64 KB with 50 pending per device, and direct method payloads at 128 KB
  • Twin sections are capped at 32 KB each for desired and reported properties and 8 KB for tags; nesting depth is 10
  • Throttles are per hub and unit: on S1, twin reads at 100 per second, twin updates at 50, direct methods at 160KB per second per unit, then 429
  • Under load a twin change notification can merge several changes into one message; device-to-cloud messages are the path for every intermediate state

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Azure IoT Hub ↗

Questions and answers

Which IoT Hub tier does Fibric need?
Standard (S1, S2, or S3), or Free for evaluation. Device twins, direct methods, cloud-to-device messages, jobs, and message enrichments are unavailable in the basic tier. A subscription can hold at most 50 hubs and one free-tier hub.
How does Fibric read telemetry?
From the built-in Event Hubs-compatible endpoint or from a custom endpoint you route to. Once any route exists, data stops reaching the built-in endpoint unless a route or the fallback route sends it there. Messages are retained for up to seven days.
What happens when a direct method times out?
IoT Hub waits responseTimeoutInSeconds, default 30 and settable from 5 to 300, then returns 504. An offline device returns 404 unless connectTimeoutInSeconds, up to 300, gives it time to connect. Fibric records the outcome either way.
Ask about Azure IoT Hub

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Azure IoT Hub through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy