MQTT and Sparkplug B


Is there a plan to support MQTT/Sparkplug B and make Tulip a MQTT client to MQTT broker?


1 Like

It is likely that we will support MQTT and possibly Sparkplug B in the near/medium future. We would love to learn more about what you are trying to accomplish - can you provide more details? I’d also be happy to jump on a call if that is easier.

We are working on the definition of our “stack manufacturing” including Tulip. The MQTT protocol is interesting to distribute the collected OT data and merge IT and OT data. As Tulip is both a consumer of IT data and a collector of OT data, support of the MQTT protocol could facilitate Tulip integration into our futur “Manufacturing Stack”. For more detail feel free to context me to schedule a call - Youri-

A real example. We have an engraving machine that generates data as an MQTT customer (EoN). In order to ingest data in machine in Tulip, we have to create this chain :
MQTT Client -> MQTT Broker -> Kepware with MQTT Client Driver -> Kepware OPC UA -> Tulip

Perfect, thanks! I’ll reach out; I’d like to ask a few more questions about this.

I second that request. Supporting MQTT gives us an opportunity to plug into the flow of machine data much more centrally than we can with OPC UA, which requires a presence on the individual OT networks of our various manufacturing sites.

1 Like

@MoPositive would you be interested in discussing this as well? If so, feel free to schedule a time: Calendly - Peter Neylan

1 Like

I’m also interested in MQTT but I’m confused…

Says, “Natively connect with network-based protocols such as OPC UA, MQTT, and Modbus, as well as legacy equipment.” but this thread suggests otherwise.

If Tulip doesn’t have the capability of being a MQTT client, what does it support exacty?


It would be great to discuss more about how you plan to use MQTT. If you are interested we can have a quick call, just schedule a time.

Currently OPC UA is supported directly in Tulip and in many cases customers utilize a central server that processes other sources, such as MQTT, before sending that data to Tulip. In addition, you can connect to SQL and REST APIs. For equipment, the focus has been on OPC UA but we plan to open it up to more industrial protocols this year. We will also be supporting Node-RED on our devices to enable even more flexibility. I can see how the link you sent could be misleading, I’ll talk to the team to see if we can make it more clear.

I’m aware of the Kepserver client for MQTT but I wasn’t sure if it allowed for bi-directional communication. Due to the Tulip architecture change a few months ago the Tulip IoT gateways no longer allow us to collect data from a station as “machine data” only “application data” so we are evaluating a couple of Opto 22 groov devices for machine data collection and potentially control which can communicate via MQTT.

I believe you can use IoT Gateway from Kepware to enable bi-directional flow with MQTT, but I haven’t tested. We do have plans to add support for Tulip Gateways and MQTT directly as ‘machine data’. In addition we plan to offer a REST API to allow you to send machine events to Tulip. This work will eliminate the need for Kepware in many cases. It would also work for the groov; although we would prefer to bring you back to the Tulip Edge devices :wink: .

it is essential that the data collected by Tulip gateways can be published on the Tulip platform, but also to other destinations such as an MQTT broker, a DataHub, an Analytics platform,… An open architecture based on modern, open protocols is necessary to support the digitisation of our factories.