In a large enterprise, the tag hierarchy can be many levels deep. But sparkplug only allows the use of 3 levels on its MQTT Topic (groupID/EdgeNodeID/DeviceID) ? I don’t get this initiative.
On top of this, on Ignition gateway MQTT Engine, there is no option to selective subscribe down to DeviceID?
Trying to shed a light on these.
The purpose of the three topic levels was really about defining where a given message came from. It doesn’t prevent one from having a deeper tag hierarchy. Any metric in the payload can have any depth that is required. One can think of the topic like an street address with a number, street, and zip code. But the contents of any letter can have anything that is required by the application which can include tags at any folder depth.
@wes.johnson are you referring to the fact that the metric payload itself can be hierarchical, or does the SpB spec actually permit additional levels in the topic path beyond the standard topic namespace? I assumed that was what you meant by “tags at any folder depth” because that is how it would appear in Ignition but wanted to be certain.
I mean that a metric could have a name of a/b/c and it will then appear in Ignition in the MQTT Engine tag provider as [MQTT Engine]group_id/edge_node_id/device_id/a/b/c.
Thanks for clarifying. So the three levels really are to create a “namespace” in which the user can build whatever hierarchy they want. That’s excellent.
I agree with all what you said.
But couldn’t filter if I only want to subscribe to [MQTT Engine]group_id/edge_node_id/device_id/c/c/c
Even MQTT Engine does not have a feature to subscribe to device_id level. - at the time of writing this.
Yes - it is correct that you can’t use a subscription as you noted since that ‘tag’ isn’t actually published on that topic. The topic it is published on is spBv1.0/group_id/VERB/edge_node_id/device_id. ‘c/c/c’ is the metric name inside the payload.
The reason MQTT Engine doesn’t allow filtering on a device_id is due to the complexity of how a device is something attached to a Sparkplug Edge Node. Any device is encapsulated in the ‘session’ associated with the edge node it is a part of. In order for MQTT Engine to support this it must still subscribe to and get the Node level messages but effectively throw out the metrics associated with that node and all other attached devices. It is something we have in our backlog but it’ll take some work to implement and we still have some design decisions to make before we are going to implement it.
i was the original poster.
2 years later. I am re-setting up, and relearning these.
I am doing a POC.
Publishing data from modbus device (PAC Control Variable) → Ignition Edge → MQTT Transmitter (sparkplug) → Mosquitto
And subscribing via MQTT Engine → Tag Browser → OPC-UA Client.
I want to be able to context “asset modelling” the data by: siteN/areaN/lineN/TemperatureN
Objective is, to be able to organize folder hierarchy automatically in Ignition Tag Browser.
Let me any tips and experience.
Do I follow the Parris Method?