MQTT using Sparkplug B

[allnerag]

Good day,

Do we see the need to bring in support for "SparkPlug B" to be able to use any easy accessible sensor in the OT (OT network is industrial-oriented,) network with MQTT by using the extension. I think we would then be able to integrate custom build sensors into any OT type of software like. We can do this now when we integrate with Node Red to convert from MQTT to MQTT with SparkPlug B. This is now an additional work to be done and would like if it was native.

https://www.hivemq.com/solutions/technology/mqtt-sparkplug/

Thanks

[barbudor]

A standard MQTT topic structure insuring interoperability could be interresting.
Is that achievable in Tasmota without breaking everything is a more complex question.

So far from th elinks you provided I can just see blahblah whitepapers and nothing concrete in terms of topic structure specification
Have you found anything more solid ? A real specification ?

[barbudor]

Berry will target only ESP32 and will not replace Tasmota native MQTT scheme
Which is also a big question: Should Sparkplug comes in addition or as a replacement of Tasmota's native scheme ?
If it has to replace, it has to cover all main MQTT activity of Tasmota : cmnd, stat and tele

When I see the type of messages, I feel the match might not be easy to achieve

[michcfr]

ok so you mean it is not more than MQTT messages translation of the Tasmota native scheme to and from SparkPlug? it is rather a complete rewriting?
Is the existing Tasmota MQTT code be separated into layers: one specific to Tasmota and the other specific to the MQTT output: native scheme or SparkPlug? At least the Tasmota MQTT can be modular so that we can choose (at compilation with #define?) between the native or the sparkplug?

[sfromis]

As the "M" in the name "Tasmota" literally means "MQTT", this is not isolated into a plug-able component, like when the data format JSON is handled throughout the relevant places in the Tasmota code, including the features allowing users to create commands, rules, scripter and Berry programs. While the MQTT protocol handling is only a few places, that does not go for the data format and control flows.

The question would be how to map between the Tasmota MQTT design and whatever message structure and flows SparkPlug requires. If this would not be straightforward to do in a separate bridge based on the existing MQTT communication, it would likely not be practical to integrate into Tasmota with a #define to switch which way. And the latter is my guess. But if a separate bridge would be feasible, that would be my suggestion.

Still, moving forward with this would need analysis by someone familiar with both sides, and with a strong interest in making it work with SparkPlug. And willing to do a significant (my guess) amount of work.

[michcfr]

In other words, it means it would heavily break the Tasmota code to move to SparkPlug?

[s-hadinger]

Not necessarily. After a quick look, it seems that all Sparkplug topics are in the form spBv1.0/[Group ID]/[Message Type]/[EON Node ID]/[Device ID] which does not interfere with Tasmota topics.

But it would require a whole new layer of Sparkplug interface, and largely doable in Berry.

It looks to me an overkill for home automation. Sparkplug is designed for SCADA and industrial usage. Again any volunteer is welcome.