Post by aliazzz on Ticket #55: How do we Implement #PublishInterval / PublishRate? discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,10 +1,9 @@ -PublishInterval / PublishRate is default set to 5000ms. +PublishInterval / PublishRate is default set to 5000 ms. This means we cannot publish "updates" any faster then each 5000 ms. How should we implement this? -1) some form of delay which acts as a NDATA/DDATA buffer? -For this to work we have to prevent NDATA/DDATA data to get sent immediately on-change and "buffer" theses changes into the encoding list until the PublishInterval expires. If the interval expired we can encode/send the blob which contains all changes from/during the last interval period. +1) For this to work we have to prevent NDATA or DDATA data to get sent immediately on-change and "buffer" all incoming changes into the encoding list until the PublishInterval expires. If the interval expires we can encode the list into a blob which contains all changes from/during the last interval period and send it. 2) Some readily available mechanism via the MQTT Publisher? (haven't looked for it, but cannot remember its there either)
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 @@ -20,7 +20,9 @@ PublisherDone() PublisherError() /Subscriber - Received() + SetSubscriberBuffer => // !needs implementation! + IsMessageReceived() // TRUE if a message is ready to be digested + GetMessage() // Provides the message itself Subscribe() SubscriberBusy() SubscriberDone()
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)}
status: open --> 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)}
Implemented in Branch v1.3.2.0
Last updated: 2021-08-10

Post by hermsen on Ticket #135: Project Homepage: Update guides discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
labels: Homepage, www --> status: open --> closed
Last updated: 2021-08-10

Post by aliazzz on Ticket #21: Payload Structure -> Metric Structure -> ... discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Ticket [#11]: Large 'static' address space for decoding Payload Blobs Take for example "Payload.metrics[].datasetvalue.rows[].elements[].stringvalue" This is fine for encoding, because you can build only the array elements you need. If we limit the decoder statically (even with values set in the user application), to allow any of 64 incoming metrics to have a dataset with 64 rows and 10 columns, which any could be allowed to be string(80)s, would require 81 x 10 x 64 x 64 = 3MB just for that address. repeat for the others, allow for a few more rows of data, and you've quickly filled your memory. I'd opt for static limit of 32 devices per address. We could opt for a user dependent max setting (library parameter) and default it to 32. Reason is memory usage. Plus 32 devices behind a single Node is quite a few devices if you ask me... If needed, the setting can be changed by the user. Then their mileage may vary. Ticket 999 options Convert to JSON or XML using one of those libraries, and then use the same JSON or XML library to access the data Each Payload has a metric pool array, properties pool array, dataset pool array, template pool array. Rather than a metric having his own arrays, he just has index values to the pools. Use one of the FB_Factories to allow dynamic creation and distruction of FB instances. Option 3 seems the nicest too me. I am open to this option but I am hesitant towards long term usage in an industrial environment stability wise. Using it in a lab environment should be no issue at all.
Last updated: 2021-08-10

Post by i-campbell on Ticket #71: MQTT: Subscribers outputting "No Error" but xError is true discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
labels: MQTT --> status: open --> wont-fix
Last updated: 2021-08-10

Post by hermsen on Ticket #16: Implement SparkPlugB Device discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,21 +1,9 @@ -EoN Node will initially be developed to only send its own Metrics. Later, in this ticket, we will also support devices, which are children of EoN Nodes. - Advantages of Devices: -* Can tell when they come online/go offline -* Can help logically sort data +* Can tell when a device online/go offline, +* Helps logically sort data on client and server side, * Application nodes can look only at devices they are interested in (for example a HMI node that only wants data for the page it is on) -Workaround: until this is implemented, all Metrics that would have been put in a device, can be published instead as EoN Node Metrics - -Ideas for implementation: FB_Device - - based on FB_EoN - - every FB_Device has its own Publisher - - every FB_Device has its own Subscriber - - every FB_Device has its own AllMetricsList - - shared connection with the EoN. i.e. there is only one connection - -an ARRAY [*] of FB_Device will be passed by the user to FB_EoN - -"not enough subscribers" error too, for MQTT.MQTTParam.g_udiMaxPublishersAndSubscribers -This is not yet needed, as we are generally under the default value of 20 publishers or subscribers. MQTT.MQTTPublisher might already return an error. + - Based on List Element, + - shares the connection with the EoN i.e. there is only one connection, + - The user ties an arbitrary number of Devices to the EoN.
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)}
I assume that the subscriber implemented in the IIoT suite MQTT library can only subscribe a single topic. That is why I allready implemented two subscribers in the FB_MQTT_PubSub located in in my private branch as a single topic does not suffice for sparkplugB. I checked the CODESYS documentation whether a list of topics can be added to a single subscriber, but I gathered it cannot be achieved. The provided example also implements two seperate subscribers. Granted I didn't try it, but the example should have shown this if it was a feature. I still have to merge it into the trunk and add the appropriate unittests.
Last updated: 2021-08-10

Post by hermsen on Ticket #67: Print library version into SparkplugLog (immutable) discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
status: accepted --> closed
Last updated: 2021-08-10

Post by i-campbell on Ticket #28: FB_Payload.ClaimNextFree* should initialize for you discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
with [r181] you no longer need to call InitializeStructure from outside the FB_Payload folder. Todo: update example project.
Last updated: 2021-08-10

Post by aliazzz on Ticket #18: SVN: use 'standard' cforge folder structure discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,6 +1,8 @@ The cforge svn guidelines are in the logical location: https://forge.codesys.com/forge/wiki/Migrating%20Projects/ so folder structure should be: + license.txt + STRUCTURE.MD branches/ tags/ trunk/ status: open --> pending
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 @@ -17,7 +17,9 @@ * [ ] 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. + 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. @@ -25,8 +27,10 @@ * [ ] 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" + 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) @@ -34,13 +38,18 @@ * [ ] AddlistOfMetricsWhichWillEverReportedOn( ListOfMetricsWhichWillEverReportedOn ) Note 3 - 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 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. + 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 + 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. Warning! Never send values that have not been announced on 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' + 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' Apart from these methods it contains various interaction methods and diagnosis
Last updated: 2021-08-10

Post by i-campbell on Ticket #37: FB_MQTTPUBSUB : Before sending a payload, ensure that MQTT.MQTTParam.g_udiMaxPayloadSize and g_udiMaxPacketSize are appropriately set discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Milestone: MVP EoN --> 1.0.0.0: EoN
Last updated: 2021-08-10

Post by aliazzz on Ticket #5: FB_EoN_Node discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Implemented "PublishState" statemachine
Last updated: 2021-08-10

Post by hermsen on Ticket #96: Versions: Upgrade MQTT Client SL to the one that installs with IIoT Libraries SL 1.3.0.0 discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
assigned_to: i-campbell --> h-hermsen
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)}
status: accepted --> pending
Last updated: 2021-08-10

Post by aliazzz on Ticket #55: How do we Implement #PublishInterval / PublishRate? discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Pushed into trunk v0.0.0.26
Last updated: 2021-08-10

Post by aliazzz on Ticket #15: Example project for a SCADA discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Description has changed: Diff: --- old +++ new @@ -1,4 +1,4 @@ * create installation and usage instructions * A CODESYS SCADA / IIoT Host should connect to a third party MQTT_Broker and receive data from an EoN and send commands to an EoN, and indicate the EoN connection status. * This CODESYS SCADA (PLC) application is the so called 'Primary Application' (see SparkplugB specs page 20 and beyond) and can reside on any CODESYS PLC. -Thie primary application is effectivly decoupled from the infrastructure via the use of the MQTT broker. +The primary application is effectivly decoupled from the infrastructure via the use of the MQTT broker.
Last updated: 2021-08-10

Post by hermsen on Ticket #91: Protobufs: support communicating to buggy implementations discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
labels: Protobufs, Improvement --> status: open --> closed
Last updated: 2021-08-10

Post by i-campbell on Ticket #127: Edge / Device BUG SeqNums discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
status: open --> closed
Last updated: 2021-08-10

Post by i-campbell on Ticket #113: PrimaryHost: Dispose of unwanted objects discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Milestone: 2.0.0.0: SparkplugB Primary Node --> 3.0.0.0 Full Feature Product (FFP)
Last updated: 2021-08-10

Post by ferraraf on Ticket #106: AWS IoT Core Support discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
@i-campbell Thank you!, any estimation of when? Im not aware of the quantity of work required from your side, also is there any short term solution I can do to make this work with the library we have currently?
Last updated: 2021-08-10

Post by aliazzz on Ticket #51: EoN: EON.PublishBirth() calls publish() twice discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
Implementing state machine to 1. Connect, 2. Publish NBirth, 3. Publish DBirth.
Last updated: 2021-08-10

Post by hermsen on Ticket #103: Device unplugging "on the fly" causes an exception discussion ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Post)}
status: accepted --> closed
Last updated: 2021-08-10

Sort by relevance or date