First off, I want to thank you all at Cirrus Link for the work you’ve put into making MQTT implementation more robust and integrated. First and foremost, I’m an integrator, not a full-scale software developer, so I apologize if some of my questions are dumb.
We will be using Ignition to handle most of our MQTT communication. More importantly, if I understand the Sparkplug spec correctly, we want to use Sparkplug for the Single-Source of Truth tag creation that it provides. However, some of my use-cases involve taking data out of places that are not in industrial SCADA.
My question is if I am tracking properly: if we are using a Sparkplug complaint broker like Chariot V2, we can make middleware to convert the data into a Sparkplug compliant message, and then the Sparkplug properties will reside for that data being transmitted? As most of my experience has been with process control; is this a fool-hardy approach? I have zero concept for the type of time/effort that would take, so is that a stupid approach to take?
Edit:
Also, it seems the Python stand-alone example was written in Python2 (from the print statements). I didn’t see anywhere on the installation page that a specific Python release was required; has there been any feedback on if the example client is stable with Python3.+?
Again, thank you all for the product.
Adam
1 Like
I’m not sure I fully follow your question. Is it that you want to consume (subscribe) to data from the MQTT Server and do something else with it? There are many options on how to do this from using a custom written application or using one of the Cirrus Link Cloud Injector modules in Ignition to push it to AWS, Azure, or some other cloud platform. Azure Injector has support for things like message based routing. AWS Kinesis endpoints support Lambda’s which can be written to perform custom actions (store, translate, push somewhere else, machine learning, etc) with the data. So again, there are many options.
On your Python question - I’ve heard of people using the Tahu library in Python 3 environments but I’ve not done it myself.
Wes,
Thank you for the response. My question is more on non-mqtt traffic converted to Mqtt traffic. I haven’t used but am aware of the (what I think are) one-directional injectors going process side to business intelligence side.
I have a case where a proprietary software is massaging process data outside the industrial environment and then that processed data is visualized but never reintroduced to the original system.
I know of a few other fields where this is taking place. My question is essentially, how difficult/time intensive is it to write an app to convert non-mqtt data to the sparkplug spec so I can sell customers on the idea that this data is now universal?
But, I think you answered my question: people do it and it’s possible, I just have to study up on how to do it.
Right - ok. Thanks for the clarification. Yes - people do it and it’s possible. Difficulty really depends on the skill level of you or your team and the exact goals of what you want to do. I should note IF you have a way to get this data into Ignition tags some how (i.e. the Web Dev module: WebDev Module - Ignition User Manual 8.0 - Ignition Documentation or something similar) then the MQTT Transmission module can be used to automatically push this data out to an MQTT server via Sparkplug/MQTT messages. This would not involve a custom Sparkplug application. Via a bit of Ignition scripting with the WebDev module and some MQTT Transmission config you might be up and running.
If the above isn’t possible, I should note Cirrus Link doesn’t support custom Sparkplug implementations directly. However, we did open source the Sparkplug Spec to the Eclipse Foundation. We also continue to be heavily involved in moving the spec forward with our involvement on the steering committee, spec committee, and a number of committers on both projects (Tahu and Sparkplug).
I would suggest posting some of your questions over there. The Slack channels are likely to give you the best responses. Many people there have implemented various aspects of the spec. Below are some of our standard recommendations for getting involved with the Sparkplug Working Group.
-
You can post your question directly on the Sparkplug Working Group mail list: Mailing list: sparkplug-wg (106 subscribers) | Eclipse - The Eclipse Foundation open source community website.
-
You can join the Sparkplug Slack channel(s):
-
Post an issue on the Eclipse Tahu project site: GitHub - eclipse/tahu: Eclipse Tahu addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures and provides a much-needed definition of how best to apply MQTT into these existing industrial operational environments.
- If posting an issue here, it is highly recommended to post a link on the mailing list to encourage responses.
Good luck with your projects.
1 Like