Post by hermsen on Ticket #65: EoN Example discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
summary: 1.0.0.0: Example --> EoN Example Description has changed: Diff: --- old +++ new @@ -1 +1 @@ -Write a v1.0.0.0 demo example => I have a good idea +Write a EoN v1.0.0.0 demo example => I have a good idea
Last updated: 2021-08-10
Post by aliazzz on Ticket #39: FB_SparkplugB_SimpleEncoder discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Description has changed: Diff: --- old +++ new @@ -14,8 +14,8 @@ Pass a single instance of SimpleObject to the Encoder. -* [ ] AddMetric( Timestamp, SimpleObject ) // It is not mandatory for the SimpleObject to be part of a list. -* [ ] AddMetric( Timestamp, ListOfSimpleObjects ) // Passes a prepared list of SimpleObjects to the encoder +* [ ] AddSimpleMetric( Timestamp, SimpleObject ) // It is not mandatory for the SimpleObject to be part of a list. +* [ ] AddMetricList( Timestamp, ListOfSimpleObjects ) // Passes a prepared list of SimpleObjects to the encoder Apart from these methods it contains various interactions / diagnosis
Last updated: 2021-08-10
Post by i-campbell on Ticket #48: Cforge tool integration discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: open --> wont-fix
Last updated: 2021-08-10
Post by hermsen on Ticket #124: Replace Payload.ClaimNextFree*() with FB_Factory.Create*() discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: open --> closed
Last updated: 2021-08-10
Post by aliazzz on Ticket #44: example project: theirPayloadDecoder.GetNextMetric.metricvalid stays false discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: closed --> open
Last updated: 2021-08-10
Post by i-campbell on Ticket #69: MQTT: ping interval should = keep alive time discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Owner: aliazzz --> h-hermsen Milestone: 9.9.9.9: Backlog --> 1.0.0.0: EoN
Last updated: 2021-08-10
Post by hermsen on Ticket #110: Primary Host: Connect, publish state, subscribe discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
A single subscriber/publisher FB_PrimaryHost is now "beta ready"
Last updated: 2021-08-10
Post by i-campbell on Ticket #106: AWS IoT Core Support discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Yes of course, it is MIT licensed. You can get the latest "release" here: https://forge.codesys.com/prj/mqttsparkplugb/code/HEAD/tree/tags/v1.0.0.0/Code5Automation%20SparkPlugB%20v1.0.0.0/ or if you want the more advanced-stage library, the .library and an example.project are available here: https://forge.codesys.com/prj/mqttsparkplugb/code/HEAD/tree/trunk/mqttsparkplugb/ ProvideCertificate is not coming true, because the FB is hard coded to need all three of the certificate parameters, and the AWS library only sets the common name. If you use this modfied FB (attached), I was able to get my Client Cert that was made by the AWS IoT Core SL library, as it now only requires the common name. I have just added it to the trunk Library as well. You are right, we do not verify the server certificate. This was only introduced with the library MQTT SL 1.0.2.0, so I will create another ticket to verify the server certificate.
Last updated: 2021-08-10
Post by hermsen on Ticket #88: EoN / Device: RBE or time based publishing discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
labels: EoN --> status: open --> wont-fix
Last updated: 2021-08-10
Post by aliazzz on Ticket #39: FB_SparkplugB_SimpleEncoder discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Description has changed: Diff: --- old +++ new @@ -5,56 +5,55 @@ Messages which are mandatory for this FB are: -* [x] Node Death Certificate -* [x] Node Birth Certificate -* [x] Node Data -* [x] Device Death Certificate -* [x] Device Birth Certificate -* [x] Device Data +* [ ] Node Death Certificate +* [ ] Node Birth Certificate +* [ ] Node Data +* [ ] Device Death Certificate +* [ ] Device Birth Certificate +* [ ] Device Data -Pass a single instance of SimpleObject to the Encoder. - -* [ ] AddSimpleMetric( Timestamp, SimpleObject ) (1) - - Note 1 - This method accepts a single SimpleObject deliberatly, to keep burnerplate code low - and added flexibility as it is not mandatory for a SimpleObject to be part of an - array or a list. - - -Pass a prepared list of SimpleObjects to the Encoder. - -* [ ] AddMetricList( Timestamp, ListOfSimpleObjects ) (2) - - Note 2 - This method accepts a List of SimpleObject, this way you can send multiple values - in one list. This list can not contain other metrics metrics than those announced - on birth. The list is thus at most the same list as - "ListOfMetricsWhichWillEverReportedOn". - - -Pass a list of every All Metrics Which Will Ever Reported on during this "Lifetime" (3) +Pass a list of every All Metrics Which Will Ever Reported on during this "Lifetime". (1) * [ ] AddlistOfMetricsWhichWillEverReportedOn( ListOfMetricsWhichWillEverReportedOn ) - Note 3 + Note 1 This Method can be used to pass the entire list of metrics which will ever be reported on and send this list ONLY on node / device (re)birth. We can only send - values which have been 'announced at birth' of the Node or Device. Since the + values which have been 'announced at birth' of the Node or Device. Since the Device or Node can die and be reborn, elements could be added or removed from the - list which will be announced on the next Birth. + list which will be announced only at the next Birth. Warning! - Never send values that have not been announced on Birth! + Never send values that have not been announced this Birth! Idea Add a way to let a Node/Device die and be reborn in order to anounce the latest list so we can update 'on-the-fly' + + +Pass a single instance of SimpleObject to the Encoder. (2) + +* [ ] AddSimpleMetric( Timestamp, SimpleObject ) + + Note 2 + This method accepts a single SimpleObject deliberatly, to keep burnerplate code low + and added flexibility as it is not mandatory for a SimpleObject to be part of an + array or a list. The SimpleObject must have been announced at this Birth. + + +Pass a prepared list of SimpleObjects to the Encoder. (3) + +* [ ] AddMetricList( Timestamp, ListOfSimpleObjects ) + + Note 3 + This method accepts a List of SimpleObject, this way you can send multiple values + in one list. This list can not contain other metrics metrics than those announced + on birth. The list is thus at most the same list as "ListOfMetricsWhichWillEverReportedOn". -Apart from these methods it contains various interaction methods and diagnosis +Apart from these Methods the FB contains various methods for interaction and diagnosis -* [x] Diag // Diagnosis +* [x] Diag // Diagnosis of the internal decoder state * [x] Encode( Enable ) // Start Encoding if Enable = TRUE, Stops encoding if enable = FALSE * [x] Encoded // Is encoding finished? * [x] EncodeBusy // Is the encoder busy? @@ -63,6 +62,6 @@ * [x] GetBDSeqNum * [x] GetSeqNum -Last but not least it should provide the end user with a way to obtain the protobuf encoded blob in order to publish it under the correct Sparkplug Topic +Last but not least it should provide the end user with a way to obtain the protobuf encoded (serialized) blob in order to publish it under the correct SparkPlugB Topic * [x] GetEncodedBlob( BlobAdr, BlobSize )
Last updated: 2021-08-10
Post by i-campbell on Ticket #106: AWS IoT Core Support discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Hello, I must go and lunch, but attached is the working project example with AWS. Note that AWS IoT Core does not support the SparkplugB specification, as it does not allow retained messages (which are needed by the host) and does not guarantee the order of messages... This does not effect the EoN connecting and publishing, but the Primary Host which we are currently developing will need a special setting for "Support AWS IoT Core by departing from the specification". Later I will post some step by step instructions. You can get the 1.4.0.4 library here: https://forge.codesys.com/prj/mqttsparkplugb/code/716/tree/trunk/mqttsparkplug/mqttsparkplug_trunk.library?format=raw The steps for registering the thing are very similar to: https://forge.codesys.com/forge/talk/Engineering/thread/eb7b1c293b/#56c7 I find using the xGet_a_CSR and sCSR from my attached example easier than steps 2,43-47 of the guide. outstanding items: CANCELLED @i-campbell Ticket to make FB_Primary Host "Support AWS IoT Core by departing from the specification". CANCELLED @i-campbell Provide an instruction page for using this example. CANCELLED @ferraraf to provide feedback if it works for him.
Last updated: 2021-08-10
Post by aliazzz on Ticket #7: Update Git to https://github.com/eclipse/tahu discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: accepted --> closed
Last updated: 2021-08-10
Post by i-campbell on Ticket #42: Devicetree (Json) discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Milestone: SFP: Device --> 2.0.0.0: Device
Last updated: 2021-08-10
Post by i-campbell on Ticket #137: Edge: Not obeying max publish rate discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
labels: bug, edge --> status: open --> closed
Last updated: 2021-08-10
Post by hermsen on Ticket #65: EoN Example discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: accepted --> closed
Last updated: 2021-08-10
Post by aliazzz on Ticket #32: FB_MQTT_PubSub Considerations discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Description has changed: Diff: --- old +++ new @@ -1,20 +1,52 @@ -PubSub exposes the pointer to the memory area and the lenght of the buffer. +PubSub can inform us a message has been received via pubsub.IsMessageReceived(). +PubSub can then be called to obtain the message via pubsub.getmessage(). The blob data which is received should be consumed by FB_Payload. -=> interaction/handshaking between PubSub and Payload in the usual way (xbusy, xdone, xerror) methods for this are provided. -=> pubsub.receive() should be called continuously and is by design asynchronous (I wrote it in a non blocking style/ therefore penalty is that it should be called continuously) -=> as the memory buffer of pubsub is envisioned to be filled ad-hoc with fresh data, payload should be able to process the received data within a single cycle. +thinking aloud: +Passing a pointer/length of the blob is far superior (as no data is physically copied around) +Binding a dynamic buffer is also under my consideration as an option if needed/wanted or has some unforseen advantage. +Offcourse the simplest idea is the best and should be chosen. +=> interaction/handshaking between PubSub and Payload in the usual way (xbusy, xdone, xerror) methods for this are provided. However I thought of the following, simple handshake; + +~~~ +IF pubsub.IsMessageReceived() THEN + // pseudocode call, true implementation will probably differ + pubsub.GetMessage( pBuf=>pBuf, udiBufSize=>udiBufSize); + xDecode := TRUE; +END_IF; +IF xDecode THEN + // GO GO GADGET DECODE + MyDecodedMessage := Payload.Decode( pBuf:=pBuf, udiBufSize:=udiBufSize); + xDecode := FALSE; +END_IF; +~~~ + + +=> +~~~pubsub.IsMessageReceived() +~~~ + +should be called continuously and is asynchronous by design as I wrote it in a non blocking style. Therefore the penalty is that it should be called continuously. If It can be designed in aonther (simpeler) way please let me know! + +=> As the memory buffer of pubsub is envisioned to be filled ad-hoc with fresh data, payload should be able to process the received data within a single cycle (!) + +**Questions:** To mitigate send/receive issues, maybe we should implement a send/receive message buffer? -This buffer then can act as LIFO on and ideally isn't filled (the contents is sent/received directly), but when many events occur at once, the buffer gets utilized. - -Is such a buffer allready implemented within the MQTT lib? +This buffer then can act as LIFO on and ideally isn't filled (the contents is sent/received directly), but when many events occur at once, the buffer gets utilized. Is such a buffer even necessary ? +Is such a buffer allready implemented within the CODESYS IIot MQTT library? If not, and we should implement this buffer, where should it be implemented? My guts say it should be in the vicinity of the Payload either before/after or embedded into. -Ideas? +Any ideas? -//// +In the CODESYS IIot MQTT library, is a single subscriber only capable of just subscribing to a single topic? +=> The provided example shows a subscribed topic per subscriber instance. +I assume this this means that for every subscription, a new FB instance is needed. Correct? +How many topics subscriptions should the EoN node subscribe too? +Thus how many subscribers should I implement (offcourse with an accompanying subscription strategy)? + +//////////////////////////////////////////////////// Part2 Also at this moment, I have code which publishes arbitrary messages. The initialisation of sending a new message takes 2 cycles, as the first cycle resets the state machine (xDone = false, xBusy = false, Xerror = false, internal client state is dormant) @@ -38,5 +70,4 @@ xPublish := xPublishBusy AND NOT(xPublishDone OR xPublishError); ~~~ - - +////////////////////////////////////////////////////
Last updated: 2021-08-10
Post by aliazzz on Ticket #63: EoN: NDATA puts elements into a second list discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Success!
Last updated: 2021-08-10
Post by hermsen on Ticket #119: FB_RemoteEdge discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Milestone: 9.9.9.9: Backlog --> 2.0.0.0 Standard Feature Product (SFP)
Last updated: 2021-08-10
Post by i-campbell on Ticket #6: How to implement “Google Protobufs” serialization/deserialization ? discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: accepted --> closed
Last updated: 2021-08-10
Post by hermsen on Ticket #109: Move DCMD from EoN to Device discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: pending --> closed
Last updated: 2021-08-10
Post by aliazzz on Ticket #24: FB_MQTT_PubSub discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Description has changed: Diff: --- old +++ new @@ -1,17 +1,31 @@ ~~~ -FB_MQTT_PubSub IMPLEMENTS CBML.ILConC, CBML.IBehaviourModel - FB_Init() - Initialise() - Connect() - IsConnected() - Disconnected() - Publish() - Received() - Subscribe() - Unsubscribe() - Credentials() - WillSet - TlsSet() +FB_MQTT_PubSub + /Client + ClientBusy(Private) + ClientDone(Private) + ClientError() + Connect() + Disconnect() + InitialiseClient(Private) + IsConnected() + IsConnecting() + SetBroker() + SetLastWill() + SetSessionCredentials() + SetSessionTls() + GetConnectionState() + /Publisher + Publish() + PublisherBusy() + PublisherDone() + PublisherError() + /Subscriber + Received() + Subscribe() + SubscriberBusy() + SubscriberDone() + SubscriberError() + Unsubscribe() // ?Needed? ~~~ -The FB shall implement common behaviour model : level controlled continuous behaviour +*The behaviourmodel is phased out as it is overkill because each of the composite FB's allready implemented their own CMBL.IConc statemachine*
Last updated: 2021-08-10
Post by i-campbell on Ticket #10: Secure testing MQTT broker discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
assigned_to: i-campbell Milestone: 999.0 Backlog --> 2.5 TLS
Last updated: 2021-08-10
Post by hermsen on Ticket #125: PrimaryHost: proces & publish messages discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
Description has changed: Diff: --- old +++ new @@ -11,5 +11,5 @@ publish it's STATE and, if applicable, issue commands * [x] Publish STATE -* [ ] Process NCMD -* [ ] Process DCMD +* [ ] Issue NCMD's (Node REBIRTH) +* [ ] Issue DCMD's
Last updated: 2021-08-10
Post by i-campbell on Ticket #77: TLS hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate discussion
co⚡e: Sparkplug™ MQTT edge and host
tickets
(Post)
status: pending --> closed
Last updated: 2021-08-10