Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec is misleading when it comes to "known" metrics. #370

Open
SeppPenner opened this issue Mar 14, 2024 · 3 comments
Open

Spec is misleading when it comes to "known" metrics. #370

SeppPenner opened this issue Mar 14, 2024 · 3 comments

Comments

@SeppPenner
Copy link

Check

6.4.19. NBIRTH
The NBIRTH is responsible for informing host applications of all of the information about the Edge
Node. This includes every metric it will publish data for in the future.

6.4.20. DBIRTH
The DBIRTH is responsible for informing the Host Application of all of the information about the
device. This includes every metric it will publish data for in the future.

--> All metrics need to be known in DBIRTH / NBIRTH already?

5.15
There are other reasons a Host Application may send out Node Control/Rebirth NCMD messages.
These include but are not limited to:
◦ Receiving any DBIRTH, NDATA, DDATA, or DDEATH before receiving an NBIRTH from a
Sparkplug Edge Node
Receiving a metric in an NDATA message that was not included in the previous NBIRTH
message

Receiving a metric in a DDATA message that was not included in the previous DBIRTH message
Receiving an alias value that was not included in the corresponding NBIRTH or DBIRTH

But still, metrics can be new from DDATA or NDATA messages? How do these requirements fit together?

@SeppPenner
Copy link
Author

SeppPenner commented Mar 14, 2024

Or is it meant to be used like this?

Imagine a scenario with one library and another one that speak Sparkplug. Let's say the other library allows to send unknown metrics on NDATA or DDATA --> Theoretically, my library would need to tell these nodes to do a rebirth because the metrics are unknown.

@ArFe
Copy link

ArFe commented May 7, 2024

I'm not sure I understand your question. Known means known. If you send an NDATA/DDATA with a new Metric, that would be invalid and the Host Application will require you to send a new NBIRTH/DBIRTH that contains your new Metric in order to move forward. Your Node/Device will be set as offline until you send an appropriate NBIRTH/DBIRTH.

In other words, sending an NDATA/DDATA with a new metric is wrong and should not be done.

What exactly is not clear?

PS.: I don't think this is the appropriate channel to discuss the Sparkplug B specs

@SeppPenner
Copy link
Author

@ArFe Thank you for the clearification. I just had the question within my project several times. Need to check it, so keep it open for now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants