Sparkplug B Support

[Aaron Freedman]

Does RabbitMQ MQTT officially support the Sparkplug B specification? I haven't been able to successfully parse data on my client side, but when looking at my logs I see that the dot in the topic namespace (spBv1.0) is actually being replaced with a forward slash as you can see below. I would love to know if anyone has a workaround or could help. The client systems I am testing on don't provide an interface to accept anything deviating from the specification.

Via Sparkplug B Support Broker: Message arrived on topic spBv1.0/MACLab/DDATA/Opto22/CLX from client MQTTEngineClient-aae2c251-603a-441a

Via RabbitMQ: Message arrived on topic spBv1/0/MACLab/DDATA/Opto22/CLX from client MQTTEngineClient-81f1ab2e-9192-4f74

[Luke Bakken]

Hi Aaron,

Unfortunately I don't believe there is a workaround for this behavior - https://www.rabbitmq.com/mqtt.html#implementation

I'll double-check - Luke

[Michael Klishin]

MQTT topics are translated to AMQP 0-9-1 topics since that's the protocol currently used to implement most features (such as topic routing) internally.

Topics actually are translated back at delivery time but the translating function does not know what the original was and thus what dots

are routing separators vs. "regular" ones.

In 3.9 we plan to remove the need to do the translation.

[Aaron Freedman]

Thanks for the reply. Is there a rough timeline on 3.9 launch?

[Luke Bakken]

Hi Aaron,

We're currently working on 3.8.0. There is no timeline at this point for 3.9.0.

Thanks,

Luke

[Aaron Freedman]

I appreciate the response, thanks! I work in the Industrial Automation space (O&G specifically) and it looks as though Sparkplug is being adopted as an open standard used on most devices and host systems. I was really hoping I could use RabbitMQ as an option for an open source broker, rather than the few licensed options that currently exist. I will keep checking back, thanks again!

[Luke Bakken]

Hi Aaron -

If you have a second to provide some links to the spec for this standard, that would be great. As Michael pointed out, the main issue is translating dots to-and-from slashes because AMQP is used internally.

If spBvX.Y is a well-known topic prefix we could add support for this standard.

Thanks,

Luke

[Aaron Freedman]

Hey Luke,

I've pasted a copy to the definition below. The SCADA systems with the largest footprints in O&G have built drivers to handle this specification.
https://s3.amazonaws.com/cirrus-link-com/Sparkplug+Topic+Namespace+and+State+ManagementV2.1+Apendix++Payload+B+format.pdf

[Luke Bakken]

Hi Aaron,

Keep an eye on this pull request - https://github.com/rabbitmq/rabbitmq-mqtt/pull/207

I'll follow up when it's merged to let you know what release it will ship in.

Thanks,

Luke

[Luke Bakken]

A bit more information -

When the mqtt.sparkplug_b = true setting is enabled, messages arriving using the MQTT topic spAv1.0/Foo/Bar/Frazzle/Baz it will be translated to the AMQP topic spAv1___0.Foo.Bar.Frazzle.Baz for routing. Messages published to that AMQP topic to MQTT subscribers will receive messages whose topic is converted back to spAv1.0/Foo/Bar/Frazzle/Baz.

Translation of wildcards like + remains the same.

This means that if you are using AMQP topic permissions, you will have to take Sparkplug B namespace prefixes in the sp[AB]v1___0 format into account, not using a dot. You can see that here:

https://github.com/rabbitmq/rabbitmq-mqtt/blob/rabbitmq-mqtt-206/test/java_SUITE.erl#L96-L97

Thanks,

Luke

[Luke Bakken]

Hi Aaron,

Support for Sparkplug will ship with RabbitMQ 3.7.18.

You will have to use the following setting in rabbitmq.conf:

mqtt.sparkplug = true

Please note that the name is slightly different from what I describe below.

Thanks,

Luke