Storing MQTT SparkplugB Dataset Objects


We're testing Canary and the MQTT Collector towards a MQTT broker were most of our data is sent as SparkplugB messages. Regular SparkplugB messages are automatically picked up and stored in the historian, but it seems messages defined as SparkplugB Dataset Objects (described in Sparkplug specification rev. 2.2, chapter 15.1.7) are not picked up by the collector.

We're running Canary version Typically, a dataset object we publish will be structured like this:


    "name" : "Site/Area/Device/datasettag",

    "timestamp" : 16215305151561,

    "datatype" : "DataSet",

    "properties" : {

        "Quality" : {

            "type" : "Int32",

            "value" : 192



    "value" : {

        "rows" : [    [ 10, 10.1, true, "one" ],    [ 20, 20.2, false, "two" ] ],

        "numberOfColumns" : 4,

        "columnNames" : [ "Col1", "Col2", "Col3", "Col4" ],

        "types" : [ "Int32", "Float", "Boolean", "String" ]


} ],

"seq" : 1


So I have a few qeustions collection of Sparkplug Datasets through the MQTT Collector supported by Canary? If not, is that something that will eventually be supported?

If it is supported, does Canary require a certain structure of the messages (any properties that are required/must be omitted, naming requirements, etc.)?

Are there any specific way to configure the MQTT collector for dataset objects?

How should we expect values to be stored in the historian given that these messages can contain a single name and multiple rows, values and columnnames? Would for example the name be treated as a node/device with the column names storing the datapoints indivudally below the name in the hierarchy?

Best regards, Jørn

3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hi jorn. hella ,

    Unfortunately, we do not support dataset objects. As of right now, there are no plans to include this functionality.

    Sorry 😕

  • Hi,

    Thank you for the quick response!

    That's okay, I realize datasets aren't the most compatible with how data is stored in historians. We should be able to make due using MQTT JSON for the more complex messages we wish to store, and I hope it's okay if I post a follow-up question regarding that here.

    In the MQTT Collector Overiview Knowledge base, you posted a JSON payload example. If I understood it correctly, the MQTT collector is capable of deserializing the JSON payload and create multiple tags, given that the payload contains at least an ID and a Value key (defined in the collector) for each tag.  Say we wanted the collector to store multiple key-value pairs nested within the defined Value key, what format would the MQTT collector be able to read and/or deserialize?

    After some testing, we're able to store our payload as a large string for a single tag. This happens reliably as long as everything we want to store is placed within quotation marks after the Value key:
    "id": "tagname",
    "v": "everything we want to store, i.e. rows: { [1,4,true,'one'],[20,20.2,false,'two'] }, numberofcolumns: 4, etc…"

    With this format we cannot include any additional quotation marks within the value string, which is difficult to achieve with our publishing gateways. Are there any workarounds where we could somehow escape/ignore quotation marks as long as they are nested within the value key?

    Best regards, Jørn

    • Hi jorn. hella ,

      I don't think we have a way of parsing this. We're expecting to have a single value per tagname.

print this pagePrint this page
Like Follow
  • 1 yr agoLast active
  • 3Replies
  • 66Views
  • 2 Following