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
andDBIRTH
for the samedevice_id
, behavior may be unpredictable.
To ensure consistent aliasing:
Use unique aliases per
device_id
, andAvoid 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
andhumidity
(or any other) will be available as independent variables within the device.The variable
sparkplug_data
will contain non-numeric data pointsgroup_id
, andedge_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:
|