eclipse-sparkplug / sparkplug

Sparkplug
Eclipse Public License 2.0
114 stars 39 forks source link

Question: Spec ambiguities. Aliases, templates and instances? #431

Closed Llorx closed 1 year ago

Llorx commented 1 year ago

Hi,

I can't find info about this in the Sparkplug specification.

Having alises enabled, it says that for each metric you should send an alias and that not two metrics should have the same alias. It also says that you have to send the alias and name on each NBIRTH and DBIRTH message.

Now the problem arises when I'm sending Templates and instances of those templates.

It says that I have to send all the metric info in my NBIRTH and DBIRTH messages, so here is the situation:

With this premise I send these messages:

And another problem is if I should even send the metric name, as it has already been sent by the NBIRTH command so I should only send the updated data, for example, not sending the name and not sending the "not_updated_prop" property as the value has not changed, like it is just a DDATA inside the template instance, because this metric definition has already been sent with the NBIRTH command, so is duplicated data.

wes-johnson commented 1 year ago

So for template definitions there is no reason/point in including an alias. Conceptually, the aliases are used in place of the metric name in DATA messages. Since template definitions only exist in NBIRTH messages, an alias has no significance or use in a template definition. So, you should use aliases in the template instances only. Then you only need to include the aliases for those given template metric members that change in subsequent DATA messages.

Llorx commented 1 year ago

Ok, perfect. And metrics of two different instances of the same template should have different alias IDs I guess, right? For example, having the metric test1 inside a Template named INV, if I instance this Template as INV01 and INV02, I guess that the metric test1 inside INV01 should have a different alias than the metric test1 inside INV02.

Thank you @wes-johnson for the clarification.