TTN support for MQTT SparkPlug?

Good morning, TTN friends -

I have some temperature sensors out in the field that utilize our Holland Michigan LORA city-wide network. The nodes report up through gateways to TTN, and I pull data down via MQTT. All is well.

We want to, however, bring the data into our power plant’s SCADA system that speaks MQTT, plus SparkPlug, which is an additional data specification that overlays MQTT. Anyone familiar with it?

My understanding is that a Edge of Network (EON) device would take data from sensors and provide MQTT+Sparkplug formatted data. In my environment, that would be TTN.

So, here’s my question!

Can TTN act as a Sparkplug EON, providing additional data format and functionality?

Since my search is in vain, I’m thinking no, which leads to my second question - How would I get my nodes to deliver MQTT+SparkPlug? Are there sensor nodes that support it? Is there some other device that would convert data?

Thanks in advance for any answers and advice you might have.

hi,

without much investigation, but with my current knowledge is the short answer: NO. mqtt is a transport protocol with leaves the topic design at user side. there is no DIN/IEEE whatever standard fore the topics imho. but there a best practices…but thats the problem you, and may others are facing.

if you need special MQTT topic format you will have to script a “translation machine” at one of your mqtt servers that copies the sensors to the your “correct” topics to match your needed format.

First up, there’s no SLA for TTN which is for testing, evaluation & community use, so be aware that your power plant may not always get the data it needs - @rish1 can advise.

LW network & application servers are generally standalone affairs as everyone has a data standard that they want and they can’t possibly do them all.

So all the outgoing data connections are generic - the web hooks send TTI defined JSON to the end point and the consumer has to process it in to whatever local form they need, the MQTT broker is restricted to sending out the same JSON with only a few incoming endpoints - some hope they will have access to use it to reformat & rebroadcast but it doesn’t.

There’s also a distinct lack of mentions of ‘SparkPlug’ in the very comprehensive docs and a total lack of hidden features, so you can use the docs as canon.

As @drsash suggests, you need to have something in between that morphs the packets in the format you need. If you are lucky, this will be a simple web server with some Python or PHP, if less lucky, an AWS Lambda instance.

Thanks, folks.

Your responses are in line with my research. I think a “middleware” translator, as @descartes , suggests, is probably the way to go.

I’m not too interested in that.

The data’s not critical, so we could live with TTN SLAs, for sure.

A bit of background - These are homebrew temperature sensors that measure the temperature of the sidewalks throughout town. We have a large snowmelt system fed by waste heat from our power plant. Fun stuff.

Back to the drawing board…. Perhaps our SCADA system can ingest data in other ways.

Thanks for the feedback!