MQTT Engine JSON Parsing Error on NBIRTH Payload

3rd Party Modules
1

Ignition Version: 8.1.38
MQTT Engine Version: 4.0.21
MQTT Transmission Version: 4.0.21

I am currently testing the MQTT Transmission and Engine Modules with HiveMQ as the broker. When I set my Transmission side server to use JSON encoding instead of protobuf the engine side stops being able to process the payloads.

I start seeing the following error on the engine side:

image
image1193×561 102 KB

Looking at the NBIRTH payload it appears to be valid to me:

{
"timestamp": 1712061288423,
"metrics": [
{
"name": "Node Control/Next Server",
"timestamp": 1712061288423,
"dataType": "Boolean",
"value": false
},
{
"name": "Node Info/Transmission Version",
"timestamp": 1712061288425,
"dataType": "String",
"value": "4.0.21 (b2024012622)"
},
{
"name": "bdSeq",
"timestamp": 1712061288423,
"dataType": "Int64",
"value": 5
},
{
"name": "Node Control/Rebirth",
"timestamp": 1712061288423,
"dataType": "Boolean",
"value": false
}
],
"seq": 0
}

Switching the encoding to Protobuf resolves the problem, so worst case scenario that becomes the solve, but having the payloads in JSON makes processing them easier downstream and helps at the current system testing stages.

Any thoughts would be appreciated.

2

If nobody here has any idea, CL has their own forum as well: https://forum.cirrus-link.com/

3

Thanks Kevin, cross posted there.

4

Hello Marc,

Yes, this is to be expected. If our Sparkplug B Default Namespace is enabled it will choke on a JSON message coming from Transmission as it expects any message on the spBv1.0/ Topics to be encoded in Protobuf.

If you set MQTT Transmission to send JSON, instead of Protobuf encoded messages, they will be JSON but not encoded.

At MQTT Engine, you will have to disable the Default SparkplugB Namespace so that your Custom Namespace is the only namespace enabled to process the JSON on a sparkplugB Topic if you don’t want to see these messages in the log.

In general, we don’t consider this a proper configuration.

Daniel

5

Does this mean that the JSON encoding is generally intended to be consumed by subscribers that aren't Sparkplug-aware, and that it's not simply an alternative to the binary encoding that allows greater transparency of the message payloads between a Sparkplug-aware producer and consumer?

6

Hello Kevin,

That is correct with a minor caveat. This JSON option is a bit of a leftover from years ago and not often used. The Default SparkplugB Namespace is not expecting the JSON formatted messages and throws these ERROR messages.

We do not get many calls into Support for this.

Dan

7

Thanks Dan simple enough of a solution.

Sounds like I had misunderstood that JSON v. Protobuf setting, but with your explanation it now makes sense why the Engine does not have an equivalent setting for decoding.

8

I should add that to get the JSON message processed properly at Engine while using the Transmission module to send that JSON (not Protobuf) payload you will need to add the String Conversion to remove the '.' period character from the spBv1.0 Topic. We usually see spBv1.0 become spBv1_0 or something legal in Ignition.

Dan