MQTT-Explorer 0.4.0-beta4 SparkplugB decode some strings as "{}"

[LoicGoulefert]

In the latest release of MQTT-Explorer, some payloads seem to be decoded by SparkplugB when they're not meant to be.
This results in some topics to display "{}" instead of the actual payload.

@kc2zgu mentionned here that some strings (like 5000) are detected as SparkplugB payloads. I can't reproduce this in my application, but the string "empty" gets decoded by SparkplugB, and rendered as {} in MQTT-Explorer. Turns out that strings of length 5 starting with "e" are decoded wrongly, based on a few manual tests.

[kc2zgu]

5-character strings starting with "5" are what I noticed. So "50000" or "50.00" but not "5000"

[LoicGoulefert]

True, did some more tests and all the strings that you mentioned turned into {} in MQTT-Explorer. I can't count 😞

[bj00rn]

@thomasnordquist this is a release stopper i guess, sparkplugb decoding "detection" seems to be flaky..

The decoder choice logic is pretty naive at the moment it seems, it simply tries to decode the payload as sparkplug and if the result is !== undefined we return it. Any suggestion on how to improve the logic is welcome.

MQTT-Explorer/backend/src/index.ts

Line 52 in 65b86ac

payload: SparkplugDecoder.decode(buffer) ?? Base64Message.fromBuffer(buffer),

A naive solution might be, to add a check to see if Object.keys(message).length === 0 here, and return undefined here? I lack deeper understanding of protobuf decoding, maybe there is a way to inspect the payload to determine if it's sparkplugb.

MQTT-Explorer/backend/src/Model/sparkplugb.ts

Line 14 in 65b86ac

const message = Base64Message.fromString(

[LoicGoulefert]

Tried to run some more tests, here's what i found:
Strings starting with any of the following characters: 'e', 'E', 'u', 'U', 'm', 'M', 5, with a length that is a multiple of 5, will be decoded as {}.

[thomasnordquist]

Thank you, I consider this rather critical.
Maybe we can use part of this implementation #493 to make the decoding customizable.

I believe currently we run a decoder chain which is kind of broken

tryToDecodeAsJson
else tryToDecodeAsSparkplugB
else ....

[bj00rn]

Thank you, I consider this rather critical. Maybe we can use part of this implementation #493 to make the decoding customizable.

I believe currently we run a decoder chain which is kind of broken

tryToDecodeAsJson else tryToDecodeAsSparkplugB else ....

Thank you, I consider this rather critical. Maybe we can use part of this implementation #493 to make the decoding customizable.

I believe currently we run a decoder chain which is kind of broken

tryToDecodeAsJson else tryToDecodeAsSparkplugB else ....

Would be awesome to prepare for image support to while we are at it.
#734

[jst-mbs]

I lack deeper understanding of protobuf decoding, maybe there is a way to inspect the payload to determine if it's sparkplugb.

As someone that has knowledge about Sparkplug but not about JS/TS, I would suggest to inspect the topic structure to detemine if the message is sparkplugb. In my opinion, relying only on the message payload is a bad idea. The sparkplug specifikation can be found here: https://www.eclipse.org/tahu/spec/sparkplug_spec.pdf. The chapter 4.1 is describing the topic structure:

All MQTT clients using the Sparkplug specification MUST use the following topic namespace structure:

namespace/group_id/message_type/edge_node_id/[device_id]

The namespace element must be spBv1.0.

[tobehn]

I think @jst-mbs has a pretty good point.
spBv1.0 will always be in the topic of the message. It is at least a good way to double check if decoding might need to be used.
Though in some cases people send uncompressed messages to the spBv1.0 namespace. For example i do not know if all STATE messages in SparkplugB are send protobuf compressed.

[jst-mbs]

Though in some cases people send uncompressed messages to the spBv1.0 namespace. For example i do not know if all STATE messages in SparkplugB are send protobuf compressed.

You are right: The state messages of the 'Host application' is JSON encoded, see chapter '4.2 Sparkplug Host Application'.

[bj00rn]

Sidenote, there is a package sparkplug-payload that can do decoding/encoding. Might be worth looking into instead of rolling own protobuf decoding.

[bj00rn]

I think @jst-mbs has a pretty good point. spBv1.0 will always be in the topic of the message. It is at least a good way to double check if decoding might need to be used. Though in some cases people send uncompressed messages to the spBv1.0 namespace. For example i do not know if all STATE messages in SparkplugB are send protobuf compressed.

@tobehn @jst-mbs have a look at #793, Will (topic.match(/spBv1\.0\/[^/]+\/(DDATA|NDATA|NCMD|DCMD|NBIRTH|DBIRTH|NDEATH|DDEATH\/[^/]+\/)/u)) regexp suffice to identify encoded sparkplug payloads?