Pushing data to Azure Event Hubs

Consibio Cloud can push your project’s data to an Azure Event Hub instance as it arrives. Every time new values are logged in the project — from devices, integrations or virtual sensors — and every time an alarm changes state, Consibio Cloud sends a message to your Event Hub, so you can process the data in your own systems in near real-time.

What you need

• A project in Consibio Cloud where you have the admin or owner role.
• An Event Hub instance in your Azure subscription.
• The connection string for the Event Hub. Follow Microsoft’s guide Get an Event Hubs connection string to obtain it.

Setting up the integration

1. Open your project in Consibio Cloud.
2. In the left menu, select More, open the Settings section and select Integrations.
3. Select Add new integration. A panel opens with the new integration.
4. Give the integration a name, and make sure Integration type is set to Azure Event Hub.
5. Save your changes.

Saving the connection string

The connection string is stored as a secret: the dashboard only lets you update it — it is not displayed again after saving. Only project admins and owners can edit it.

1. Open the integration from the Integrations view.
2. Under Connection string, select Edit secret.
3. Paste the connection string from Azure and save.

Consibio Cloud starts pushing new values to your Event Hub right away. Note that only values logged after the integration is set up are pushed — historical data is not sent. To pull historical data, use the REST API instead.

The messages

Every message sent to your Event Hub is a JSON document with a type field telling you what kind of message it is:

• telemetry — new measured values.
• alarm — an alarm changed state (activated or deactivated).

Both message types share these fields:

• time — when the values were measured (or the alarm was checked), as a Unix timestamp in seconds.
• datetime — the same time as an ISO 8601 string in UTC.
• project_id — the ID of your Consibio Cloud project.

To map element, location and device IDs to what you see in the dashboard, open the Elements, Locations and Devices views, or list them with the REST API.

Telemetry messages

A telemetry message holds all the numeric values from one value event, keyed by element ID:

{
  "type": "telemetry",
  "time": 1756106468,
  "datetime": "2025-08-25T07:21:08Z",
  "project_id": "your_project_id",
  "values": {
    "element_id_1": {
      "value": 21.5,
      "type": "temperature",
      "location_id": "location_id_1",
      "source_type": "device",
      "source_id": "device_id_1",
      "device_id": "device_id_1"
    },
    "element_id_2": {
      "value": 7.2,
      "type": "ph",
      "location_id": "location_id_1",
      "source_type": "virtual_sensor",
      "source_id": "virtual_sensor_id_1",
      "device_id": ""
    }
  }
}

Each entry in values describes one element:

• value — the measured value. Only numeric values are forwarded; text values are left out.
• type — the element’s parameter type, for example temperature, ph or flow. Use it to interpret the value without looking up the element.
• location_id — the ID of the location the element belongs to, or an empty string if the element is not placed in a location.
• source_type, source_id and device_id — where the value comes from, explained below.

Where a value comes from

Every element in Consibio Cloud gets its values from a source. Most often the source is a physical device, but values can also be produced by a virtual sensor that calculates them from other elements. The three source fields let you trace a value back to its origin without querying Consibio Cloud:

• source_type — the kind of entity that produced the value: device or virtual_sensor.
• source_id — the ID of that entity: the device ID or the virtual sensor ID.
• device_id — the ID of the physical device the value originates from, regardless of how it was produced:
  • For an element sourced from a device, device_id is the same as source_id.
  • For an element sourced from a virtual sensor that runs on a device (edge execution), device_id is the ID of that device.
  • For an element sourced from a virtual sensor that runs in the cloud, there is no single originating device — cloud virtual sensors typically combine values from several devices — so device_id is an empty string.

This makes it easy to group values by physical device (device_id) while still knowing whether a value is a raw measurement or a calculated one (source_type). If an element has been deleted, its source fields are empty strings.

Alarm messages

An alarm message is sent every time an alarm in the project is activated or deactivated:

{
  "type": "alarm",
  "alarm_type": "interval",
  "time": 1756106468,
  "datetime": "2025-08-25T07:21:08Z",
  "project_id": "your_project_id",
  "device_id": "device_id_1",
  "location_id": "location_id_1",
  "activated": true,
  "alarm_parameter": {
    "element_id": "element_id_1",
    "value": 31.2,
    "type": "temperature"
  },
  "alarm_settings": {
    "lower_limit": 5,
    "upper_limit": 30
  }
}

• alarm_type — interval for alarms on a value range, or offline for alarms on missing data. See Creating an alarm.
• device_id and location_id — the originating device and the location of the element the alarm is defined on, resolved the same way as for telemetry messages.
• activated — true when the alarm was activated, false when it was deactivated.
• alarm_parameter — the element the alarm watches: its element_id, its parameter type, and the value that was checked. For offline alarms there is no measured value, so the value field is left out.
• alarm_settings — the settings of the alarm. The fields depend on alarm_type:
  • interval alarms hold lower_limit and upper_limit.
  • offline alarms hold max_offline_hours, the number of hours without data before the alarm activates.

Custom payloads

If you need messages in a different format — for example to match an existing ingestion pipeline — Consibio Cloud also supports custom payload templates, where you control the exact structure of each message. Reach out to support@consibio.com to have custom payloads set up for your project.

Troubleshooting

• No messages arrive in the Event Hub: check that the connection string is correct and includes the EntityPath of your Event Hub, and that new values are actually being logged in the project.
• Some values are missing: only numeric values are pushed — text values are not included in telemetry messages.
• device_id is empty: the element is sourced from a virtual sensor executed in the cloud, or the element no longer exists.

If you are stuck, contact support@consibio.com.