Templates allow you to define a specific structure for data, and then implement several instances.
Partly the advantage is that, if you transmit "names" rather than aliases, you translate the instance name once, and then just the member names.
Additionally, there are some Object Oriented advantages, for example making faceplates that require a particular template as input.
so:
Diff:
Sparkplug spec Chatper 6
"A Template Definition MUST have template_ref set to NULL."
does NULL mean:
1. include template_ref in the payload, but set it to ""
2. include template_ref in the payload, but set it to the unicode character 16#00
3. do not include template_ref in the payload
4. either 1 or 2 or 3 is accepted
We should see what other Edge Nodes do here. Our current implementation was to not include this member in the payload.
Subtask: combine and clean up the two different code paths for composing payloads from a List of Metrics.
With the adding of templates, we have built ourselves a bit of a warren of calls to add metrics to payloads.
When The device is ready to DBIRTH... the entry to the device is:
FB_Device.getMessage()
- obtain any aliases from edge
- THIS^._SparkplugB.GetDeviceBirthCertificate()
- ... Implementation not yet typed out.
- sets topics
When the device is ready to DDATA... the entry to the device is
FB_Device.getMessage()
- SPStack.PrepareData()
- pSparkplugB^.InitialiseDATA()
- gets timestamp from Runtime ???? done twice
- _Encoder.InitializePayloadBeforeAddingMetrics()
- _Payload.InitializeStructuredPayload()
- clears any existing data in the payload
- sets the _Payload timestamp
- SPStack.AddChangesToPayload()
- gets timestamp from Runtime ???? done twice
- Loops Metrics
- sparkplugB^._Encoder.AddMetricChanges() ???? access to internal variable _Encoder
- Add blank metric to _Payload
- Sets the Metric Alias (or name)
- FB_Metric.AddChangesToPayload()
- Sets the payload.metric timestamp
- Sets the payload.metric datatype
- Sets the payload.metric Value
- .AcknowledgeNotify() ??? done twice
- loop properties
- Set the payload.metric.Property Key
- tests if quality property has changed, in which case updates Payload.Metric Timestamp
- Set the payload.metric.Property Value
- Property.AcknowledgeNotify()
- looped Metric.AcknowledgeNotify() ??? done twice
- sets topics
meta: warren of calls => a myriad of calls / a swamp of calls??!
ontopic:
suggestion 1)
we can weed out several calls by clevrly combine some calls via encapsulation. advantage: less calls,
penalty: introduction of yet another onion peel.
suggestion 2)
we could combine underlying code in some calls, so we have less calls.
advantage: less calls,
penalty: might cause regression so edge, device and host should be debugged rigorously
suggestion 3)
build an ENTIRE NEW SET OF CALLS to encode and send payloads.
build an ENTIRE NEW SET OF CALLS to receive and decode payloads.
After these calls are built and tested we can phase out the old swamp of calls because we wont touch those before the new set is ready
advantage: with our new hindsights we can make these calls more to the point and we will have less overhead and onionpeel effects.
penalty: will take time and some effort but I believe this is for the best. The Stack will become a cookingpot of changes ... Edge, Device and Host will follow suit.
PS I am always for the change that yields the best end result allthough that might take more time then another alternative.
Last edit: hermsen 2021-11-21