Over a year ago! Seems a little slow to add an open protocol like MQTT Sparkplug B.
Great summary of MQTT Sparkplug B benefits and what it would take to make Tulip a best-in-class Industry 4.0 solution. Hopefully Tulip will not fall too far behind by delaying this update. It may be too late.
I donāt think so. There are many solutions that allow you to switch from a REST protocol to an MQTT protocol and back again. Of course it is better to avoid these conversions, but if MQTT is important in your architecture, as important as a NoCode platform of choice, then alternatives exist while waiting for MQTT support. From my point of view, the main thing is not to be blocked by a solution, a vendor.
Hello @Richard-SNN ,
Great post & very well summarized the benefits of designing the industrial stack around MQTT.
We at Tulip for the past months have been working on redesigning our architecture that would allow Tulip to natively support MQTT & would enable our customers to leverage all the scalability that come with MQTT. As you mentioned, we are looking into building support for Tulip being a MQTT client where Tulip is capable to publish / subscribe to a MQTT broker.
Thanks,
Sagar
Hello @jrankinen & welcome to community!
Completely aligned with what you have mentioned. We at Tulip have been working to build an architecture that allow us to natively provide support for MQTT.
I would like to hear more about your use-case specifically & how you envision using Tulip with MQTT.
If itās easier, Iād be happy to get on a call.
Thanks,
Sagar
Hi Youri,
Completely aligned with your post. However, we understand managing middleware / protocol translators can be an overhead at scale, and are working towards building support for MQTT natively in Tulip.
I will look into setting up some time with you to speak more on this, get your perspective & how you envision using MQTT with Tulip.
Thanks,
Sagar
Do not hesitate to contact me, we have a very precise idea of our architecture and the role of the MQTT protocol in this architecture
I didnāt see this until now since I wasnāt tagged in it but hereās some use cases for meā¦
Briefly Iāll note that I had to smile at the irony of the āDemocratizing the Edgeā live event several months ago. I know the intent, but the reality is that itās not very easy to get data/information out of Tulip en masse. Sure with Tulip nodes in NodeRed I can pull 100 records at a time, and through connector functions or the native REST api I can get some info but Tulip certainly isnāt as open as an IoT platform as letās say Ignition. I think here is where MQTT could be important.
For the machine activity table:
- Publishing either machine attributes directly or results of trigger calculations to a broker.
- Subscribing to a broker to create machines from MQTT the same way we do OPC/UA today.
In applications:
- Publishing events in any arbitrary trigger to a topic, preferably with the ability to use the Expression Editor to have dynamic topics.
- Subscribing to topics to pull in additional variables/data.
- Subscribing within a trigger to perform additional logic within an app/step/widget.
I wouldnāt say this is all inclusive but itās what I can think of off the top of my head that would be immediately useful. This could also help relive some potential latency issues weāre having running connector functions in an app since they wait for the full response before exiting the trigger.
For initial release, MQTT 3.1.1 support would do a world of good but long term SparkplugB and MQTT 5 support would be nice as well.
3 Likes
Fully agree. Completion data should be also available, not only table data. We work more and more with GraphQL API and GraphQL Query/Subscription to MQTT can be super powerful to select data you want and publish in real time in a broker.
1 Like
Hey @Richard-SNN-
Youāre totally right. Tulip is all about not asking you to rip and replace your existing systems with Tulip, but our data model is too closed often for those highly integrated with existing BI tools. The ask to āLoop through hitting the APi, and store it to your own database, and reliably do this on some cadenceā is far from no-code.
The backend of table data is actual postgres tables hosted on the cloud, and I can go into some detail around why we donāt expose this directly to customers, if you care. This is a common ask, so eventually we might facilitate the duplication of this data periodically into a table that you could connect your BI tools to directly.
There is work going on around the data model to unify functionality from completions to tables to machine attribute data. This isnt a small undertaking, but there is a team exclusively working on this. This architecture change will bring a lot more parity across the platform when it comes to everything from Analytics to the API.
Hope this context helps-
Pete
1 Like
To add an update:
Weāre adding a local MQTT broker on the Edge IO that will make it easier to connect devices and get MQTT data into NodeRED. This is coming out in OS50, which releases publicly on July 5th. Weāre working on extending MQTT through the rest of the platform, but itās several quarters away. I tagged @Sagar from the connectivity team, who can provide more insight to schedule there.
MQTT in Edge IO can for sure help us to connect easily some devices. I thing what we are doing with ProGlove Mark Display. I will order 1-2 Edge IO to test this new release. Thanks
Hi OS50 works for Edge IO and Edge MC?
Hi Youri,
The MQTT broker is available in OS 50.1 for both Edge IO and Edge MC.
1 Like
Hey Youri -
Important note! Youāre right that all ProGloves can communicate over MQTT with a ProGlove Gateway present. However, I would recommend using it in USB CDC mode instead, with a Tulip device like an Edge MC.
Specifically, this is because CDC enables us to take advantage of the Streams API, their bidirectional communications API. I mention this because Streams API is the only way (to my knowledge) that weāre able to write to the screen on the Mark Display, as well as read from it.
You can see a brief proof-of-concept/unit test that I made here - under the hood, this is just my Edge MC reading and writing JSON objects over USB Serial connection nodes. Let me know if this brings up new questions - it might be worth it to start a new thread at any rateā¦
Hi,
MQTT use also stream API with MQTT message. So I manage to change display of PG Mark Display with MQTT protocol, too.
Best
Oh great! Good to hear both can work out.
Iām integrating some Sparkplug B, and I have a few recommendations for folks.
Community based support for Node Red and Tulip is pretty good. Node Red support for Sparkplug B is also pretty good. You can use Node Red as an edge ādeviceā and have it participate in MQTT on one side and Tulip via the Node Red Tulip API and not have to pay for Kepware. This also lets you somewhat address I.T./O.T. separation if you have an on-site MQTT broker. Even if you use a cloud-based broker, you can still use Node Red to connect it to Tulip. I find this to be a lot more flexible than trying to use Kepware. There was a time when Kepware was the thing to use, but recent improvements to Kepware seem to all be centered around Thingworxā¦ other than that I feel like the product has really stagnated.
Agree, we see Kepware as a legacy solution in a modern manufacturing stack. Kepwareās shortcomings are more and more visible in a āDevSecOpsā environment. Moreover, the obligation to use Thingworx to manage Kepware at scale is the opposite of an open architecture. Long live Cybus, Node-Red, Edge gateway, embedded MQTT client or broker, in brief next connectivity generation HW and SW included Tulip
1 Like