Skip to main content

Ubidots Basics: Sending Data to Ubidots With MQTT Sparkplug

Sergio M avatar
Written by Sergio M
Updated over a week ago

Sparkplug B is a lightweight, efficient protocol specification designed to enhance MQTT communications in industrial IoT applications. It defines a structured format for data transmission, ensuring consistent messaging between devices, gateways, and platforms. By standardizing the way data is encoded, Sparkplug B streamlines integration with platforms like Ubidots.

Sparkplug reduces bandwidth consumption by transmitting only relevant data changes, improving performance for devices operating in remote or bandwidth-limited environments. Its state management capabilities ensure data integrity, minimizing the risk of incomplete or outdated information.

Aware of the need to provide support for this specification, Ubidots has incorporated Sparkplug into its MQTT broker.

Learn how to easily forward data from your Sparkplug-enabled devices to Ubidots.

1. How to Send Data to Ubidots Using Sparkplug B

To send data from your Sparkplug B-compatible devices to Ubidots, follow these steps:

1.1. Configure Your Device

Ensure your device is set to publish data using the Sparkplug B protocol. The topic structure must follow this format:

spBv1.0/<group_id>/<message_type>/<edge_node_id>/<device_id>

Where:

  • group_id: Identifies the group of devices.

  • message_type: Indicates the type of message (e.g., NBIRTH, DBIRTH, NDATA, DDEATH).

  • edge_node_id: Identifies the gateway or node sending the data.

  • device_id: The unique ID of the device, which will become the Device Label in Ubidots.

1.2. Authentication

Sparkplug authentication is the same as in plain MQTT, where you only need your Ubidots token as the username. The password can be left empty.

1.3. Aliasing Support in Sparkplug B Messages

Ubidots supports aliasing for Sparkplug B messages, allowing devices to send DDATA or NDATA updates using only aliases (instead of full metric names). This improves payload efficiency and aligns more closely with the Sparkplug B specification.

1.3.1. How it works

When a device sends a DBIRTH or NBIRTH message, Ubidots caches the mapping between each metric’s alias and name, uniquely associated with the device_id. Subsequent messages (DDATA or NDATA) that contain only aliases will be correctly decoded and attributed to their corresponding variable names in Ubidots.

For example:

{
"alias": 1,
"value": 42.5
}

If alias 1 was associated with "temperature" in the birth message, the value will be correctly stored in the temperature variable.

1.3.2. Current limitation

The alias mapping is per device_id, but it does not yet distinguish between message types (N vs D). This means:

  • Aliases must be unique across all devices under a given device_id.

  • If the same alias is used with different names in NBIRTH and DBIRTH for the same device_id, behavior may be unpredictable.

To ensure consistent aliasing:

  • Use unique aliases per device_id, and

  • Avoid assigning the same alias to different metrics across node/device scopes.

1.4. Viewing Data in Ubidots

Once your data reaches Ubidots, it will be automatically mapped as follows:

  • Each Sparkplug B device will appear in Ubidots as a device with a label matching its <device_id>.

  • Defined numeric variables like temp and humidity (or any other) will be available as independent variables within the device.

  • The variable sparkplug_data will contain non-numeric data points group_id, and edge_node_id.

For example, with this topic (which follows the Sparkplug specification):

spBv1.0/myGroup/DDATA/myNode/myDevice 

Your device (and its variables) will look like this in Ubidots:

Notes:

  • Currently, only publish operations are supported.

  • All variables, including sparkplug_data, will have synchronized timestamps.

Did this answer your question?