Ticket #20: Workflow for certificate handling between a MQTT broker ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
With a feasible MQTT broker with TLS, a quick way of handling the certificates. Aim would be to allow someone with the right authorization, to efficiently register 50 EoNs and one SCADA / IIoT Host to the MQTT Broker.2020-11-01 19:06:29.170000 Ticket #20: Workflow for certificate handling between a MQTT broker co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/20/ Ticket Workflow for certificate handling between a MQTT broker False 0 2020-03-29 20:07:43.888000 20 Workflow for certificate handling between a MQTT broker closed With a feasible MQTT broker with TLS, a quick way of handling the certificates. Aim would be to allow someone with the right authorization, to efficiently register 50 EoNs and one SCADA / IIoT Host to the MQTT Broker. False False 0 0 0 20 2.0.0.0: TLS i-campbell i-campbell
Last updated: 2020-11-01

Ticket #106: AWS IoT Core Support ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Can we please get this AWS compatible with the AWS IOT Core Client library? Kind regards2021-02-05 18:24:34.890000 Ticket #106: AWS IoT Core Support co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/106/ Ticket AWS IoT Core Support False 0 2020-12-21 08:58:54.440000 106 AWS IoT Core Support wont-fix Can we please get this AWS compatible with the AWS IOT Core Client library? Kind regards False False 1 0 1 106 2.0.0.0: TLS ferraraf i-campbell
Last updated: 2021-02-05

Ticket #108: TLS: use the new TLSContext to allow verification of the server certificate ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
With the 1.0.2.0 MQTT SL library, it is now possible to verify the server certificate. This should be added, so that the certificate can be verified.2020-12-27 20:44:14.332000 Ticket #108: TLS: use the new TLSContext to allow verification of the server certificate co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/108/ Ticket TLS: use the new TLSContext to allow verification of the server certificate False 0 2020-12-21 23:34:32.767000 108 TLS: use the new TLSContext to allow verification of the server certificate closed With the 1.0.2.0 MQTT SL library, it is now possible to verify the server certificate. This should be added, so that the certificate can be verified. False False 0 0 0 108 2.0.0.0: TLS i-campbell hermsen
Last updated: 2020-12-27

Ticket #31: Define how Store & Forward should be implemented (historical data) ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Purpose of store & Forward: Determine a way in which we can store and forward hystorical information to bridge any trendgaps / database gaps on SCADA side of the architecture. When a EoN Node has lost its connection to a broker, any updated value which had to be published now gets stored in the local storage of the EoN node. Whenever the EoN node gets online again (after a succesful restored connection) the EON now will publish it's local hystorical data to the broker. Any primary SCADA should also be able to consume these store & forward Values. The implementation of this usecase can be achieved in multiple ways. We should determine the way which solves the usecase with the least effort and without deviating from sparkplug's specification. I should read up in the spec on what it statesbon this point, but without having done so, I can think of these suggestions on how to achive the usecase. Some suggestions from my side; a file, filled with hystorical metrics can forwarded after reconnect by the EoN node. The SCADA server can issue a command to ask for such a file from the EoN,which then replies with said anwser(s). The anwser can be a file of hystoric metrics or a payload with metrics marked as hystorical data. Maybe tere are even other possibilities on achieving this within the constraints of the sparkplug spec? 2020-11-01 18:53:47.245000 Ticket #31: Define how Store & Forward should be implemented (historical data) co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/31/ Ticket Define how Store & Forward should be implemented (historical data) False 0 2020-05-19 02:38:19.788000 31 Define how Store & Forward should be implemented (historical data) open Purpose of store & Forward: Determine a way in which we can store and forward hystorical information to bridge any trendgaps / database gaps on SCADA side of the architecture. When a EoN Node has lost its connection to a broker, any updated value which had to be published now gets stored in the local storage of the EoN node. Whenever the EoN node gets online again (after a succesful restored connection) the EON now will publish it's local hystorical data to the broker. Any primary SCADA should also be able to consume these store & forward Values. The implementation of this usecase can be achieved in multiple ways. We should determine the way which solves the usecase with the least effort and without deviating from sparkplug's specification. I should read up in the spec on what it statesbon this point, but without having done so, I can think of these suggestions on how to achive the usecase. Some suggestions from my side; a file, filled with hystorical metrics can forwarded after reconnect by the EoN node. The SCADA server can issue a command to ask for such a file from the EoN,which then replies with said anwser(s). The anwser can be a file of hystoric metrics or a payload with metrics marked as hystorical data. Maybe tere are even other possibilities on achieving this within the constraints of the sparkplug spec? False False 0 0 0 31 3.0.0.0 Full Feature Product (FFP) aliazzz None
Last updated: 2020-11-01

Ticket #113: PrimaryHost: Dispose of unwanted objects ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
So the Primary Host starts with a collection of blank GroupIDs, RemoteEdges, RemoteDevices, and Metrics. on xBirth, it will assign these values. It should be possible to dispose of these objects if they are no longer required. GroupID => Explicitly by the end user RemoteEdge => Explicitly by the end user RemoteDevice => Explicitly by the end user Metric => On xBIRTH, when the metric is no longer declared Disposing a GroupID will recursively dispose of all children and so on.2021-05-08 13:13:14.603000 Ticket #113: PrimaryHost: Dispose of unwanted objects co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/113/ Ticket PrimaryHost: Dispose of unwanted objects False 0 2021-01-15 10:56:08.410000 113 PrimaryHost: Dispose of unwanted objects open So the Primary Host starts with a collection of blank GroupIDs, RemoteEdges, RemoteDevices, and Metrics. on xBirth, it will assign these values. It should be possible to dispose of these objects if they are no longer required. GroupID => Explicitly by the end user RemoteEdge => Explicitly by the end user RemoteDevice => Explicitly by the end user Metric => On xBIRTH, when the metric is no longer declared Disposing a GroupID will recursively dispose of all children and so on. False False 0 0 0 113 3.0.0.0 Full Feature Product (FFP) i-campbell i-campbell
Last updated: 2021-05-08

Ticket #8: SCADA: ability to save structures found online to offline project ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Obviously you could copy and paste all the Metrics from the EoN's project offline, but it would be ideal to get this from being online over MQTT also2020-10-09 22:40:00.610000 Ticket #8: SCADA: ability to save structures found online to offline project co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/8/ Ticket SCADA: ability to save structures found online to offline project False 0 2020-03-28 01:38:44.969000 8 SCADA: ability to save structures found online to offline project open Obviously you could copy and paste all the Metrics from the EoN's project offline, but it would be ideal to get this from being online over MQTT also False False 0 0 0 8 9.9.9.9: Backlog i-campbell None
Last updated: 2020-10-09

Ticket #26: LibCat.xml ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
From "CODESYS\Templates\Library_Template\LibraryCategoryBase.libcat.xml" many categories are available. Which, if any, category should we pick for the Library? 2020-11-01 19:15:10.037000 Ticket #26: LibCat.xml co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/26/ Ticket LibCat.xml False 0 2020-05-15 19:09:35.786000 26 LibCat.xml closed From "CODESYS\Templates\Library_Template\LibraryCategoryBase.libcat.xml" many categories are available. Which, if any, category should we pick for the Library? False False 0 0 0 26 9.9.9.9: Backlog aliazzz None
Last updated: 2020-11-01

Ticket #48: Cforge tool integration ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
According to the Cforge homepage we can get the following such advantages. Import / Commit Again, you can use the standard mechanism of CODESYS SVN to commit your changes on your projects. But here cforge has several advantages: You can import or check in several projects and libraries at once cforge will also commit every project in binary form, containing the SVN connection settings to your repository cforge will commit a Markdown file, containing an export of the source code MyProject/ MyLib/ (these files are generated) MyProject.project MyProject.md MyLib.library MyLib.md So investigate integrating the cforge tool into our workflow.2021-02-22 19:39:28.603000 Ticket #48: Cforge tool integration co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/48/ Ticket Cforge tool integration False 0 2020-08-22 21:47:01.723000 48 Cforge tool integration wont-fix According to the Cforge homepage we can get the following such advantages. Import / Commit Again, you can use the standard mechanism of CODESYS SVN to commit your changes on your projects. But here cforge has several advantages: You can import or check in several projects and libraries at once cforge will also commit every project in binary form, containing the SVN connection settings to your repository cforge will commit a Markdown file, containing an export of the source code MyProject/ MyLib/ (these files are generated) MyProject.project MyProject.md MyLib.library MyLib.md So investigate integrating the cforge tool into our workflow. False False 0 0 0 48 9.9.9.9: Backlog i-campbell i-campbell
Last updated: 2021-02-22

Ticket #71: MQTT: Subscribers outputting "No Error" but xError is true ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
IS: Upon reconnecting, MQTT.MQTTSubscriber is returning xError = TRUE and eMQTTError = No_Error SHOULD: If xError is set, eMQTTError must have a value other than No_Error2021-02-22 19:43:59.342000 Ticket #71: MQTT: Subscribers outputting "No Error" but xError is true co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/71/ Ticket MQTT: Subscribers outputting "No Error" but xError is true False 0 2020-10-09 22:15:44.655000 71 MQTT: Subscribers outputting "No Error" but xError is true wont-fix IS: Upon reconnecting, MQTT.MQTTSubscriber is returning xError = TRUE and eMQTTError = No_Error SHOULD: If xError is set, eMQTTError must have a value other than No_Error False False 0 0 0 71 9.9.9.9: Backlog i-campbell i-campbell
Last updated: 2021-02-22

Ticket #85: www: integrate javascript sparkplug client into project website ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Hi, I stumbled upon the javascript - Javascript client library https://github.com/eclipse/tahu/tree/master/sparkplug_b/stand_alone_examples/js and wondered if it would be fun to integrate the script into forge.codesys.com? The .js emulates a SparkplugB device with some metrics and publishes this. Idea or bin food? Aliazzz2020-10-25 21:53:48.218000 Ticket #85: www: integrate javascript sparkplug client into project website co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/85/ Ticket www Idea www: integrate javascript sparkplug client into project website False 0 2020-10-25 21:53:48.099000 85 www: integrate javascript sparkplug client into project website open Hi, I stumbled upon the javascript - Javascript client library https://github.com/eclipse/tahu/tree/master/sparkplug_b/stand_alone_examples/js and wondered if it would be fun to integrate the script into forge.codesys.com? The .js emulates a SparkplugB device with some metrics and publishes this. Idea or bin food? Aliazzz False False 0 0 0 85 9.9.9.9: Backlog i-campbell hermsen
Last updated: 2020-10-25

Ticket #88: EoN / Device: RBE or time based publishing ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Some people just really like periodic reporting without exception.2021-04-30 13:21:23.245000 Ticket #88: EoN / Device: RBE or time based publishing co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/88/ Ticket EoN / Device: RBE or time based publishing False 0 2020-11-03 23:25:27.280000 88 EoN / Device: RBE or time based publishing wont-fix Some people just really like periodic reporting without exception. False False 0 0 0 88 9.9.9.9: Backlog i-campbell i-campbell
Last updated: 2021-04-30

Ticket #98: install notes: update docs when Debian release with Mosquitto v2 ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Wait for Debian to update to 2.0.0. We can monitor the mosquitto version in the debian stable repository here. As mosquitto 2.0 is in the debian testing repository already, 2.0 is expected to be in Debian 11, circa June or August 2021. Ubuntu has it in Hirsute Hippo, due out end of April, should anyone install it on Ubuntu in the mean time.2021-05-01 14:53:53.388000 Ticket #98: install notes: update docs when Debian release with Mosquitto v2 co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/98/ Ticket install notes: update docs when Debian release with Mosquitto v2 False 0 2020-12-04 08:25:21.345000 98 install notes: update docs when Debian release with Mosquitto v2 open Wait for Debian to update to 2.0.0. We can monitor the mosquitto version in the debian stable repository here. As mosquitto 2.0 is in the debian testing repository already, 2.0 is expected to be in Debian 11, circa June or August 2021. Ubuntu has it in Hirsute Hippo, due out end of April, should anyone install it on Ubuntu in the mean time. False False 0 0 0 98 9.9.9.9: Backlog hermsen None
Last updated: 2021-05-01

Ticket #115: Every type of Node will have it's seperate log (bonus kudos) ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Every "node" in the library will have it's own log. This will make logging in general and debugging easier as a log only will contains messages from that certain component. How this should be realised is yet to be seen. If the effort is too high this ticket will be backlogged.2021-03-13 19:25:53.384000 Ticket #115: Every type of Node will have it's seperate log (bonus kudos) co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/115/ Ticket Every type of Node will have it's seperate log (bonus kudos) False 0 2021-01-24 09:28:55.104000 115 Every type of Node will have it's seperate log (bonus kudos) closed Every "node" in the library will have it's own log. This will make logging in general and debugging easier as a log only will contains messages from that certain component. How this should be realised is yet to be seen. If the effort is too high this ticket will be backlogged. False False 0 0 0 115 9.9.9.9: Backlog hermsen hermsen
Last updated: 2021-03-13

Ticket #7: Update Git to https://github.com/eclipse/tahu ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
[Git] seems to point to an old version of repository, with an old version (v2.1) of the SparkPlug B spec. Suggest we upgrade to https://github.com/eclipse/tahu Comparing the spec though, it is just changing the owner from CirrusLink to eclipse.2020-09-14 07:37:59.891000 Ticket #7: Update Git to https://github.com/eclipse/tahu co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/7/ Ticket Update Git to https://github.com/eclipse/tahu False 0 2020-03-27 23:38:49.326000 7 Update Git to https://github.com/eclipse/tahu closed [Git] seems to point to an old version of repository, with an old version (v2.1) of the SparkPlug B spec. Suggest we upgrade to https://github.com/eclipse/tahu Comparing the spec though, it is just changing the owner from CirrusLink to eclipse. False False 0 0 0 7 999 Backlog i-campbell aliazzz
Last updated: 2020-09-14

Ticket #12: Embedded some resources ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
I added a corner called Embedded Resources in the library and embedded the following files sparkplug_b.json sparkplug_b.proto example.py sparkplug_b.py sparkplug_b_pb2.py to it I use example.py sparkplug_b.py sparkplug_b_pb2.py To base my first FB_EoN_Node implementation on. Please do not remove those files until finalisation of the library Thank you2020-09-14 07:37:59.890000 Ticket #12: Embedded some resources co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/12/ Ticket Embedded some resources False 0 2020-03-28 19:53:24.866000 12 Embedded some resources closed I added a corner called Embedded Resources in the library and embedded the following files sparkplug_b.json sparkplug_b.proto example.py sparkplug_b.py sparkplug_b_pb2.py to it I use example.py sparkplug_b.py sparkplug_b_pb2.py To base my first FB_EoN_Node implementation on. Please do not remove those files until finalisation of the library Thank you False False 0 0 0 12 999 Backlog aliazzz None
Last updated: 2020-09-14

Ticket #21: Payload Structure -> Metric Structure -> ... ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
So looking at the attached .txt, you can see that each metric can have: recursive properties So in theory you could receive a payload: Payload.metric[0].properties.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].string_value 'ad finitum' recursive metrics Same for: Payload.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0] a large 'static' address space for decoding Payload Blobs Take for example "Payload.metrics[].dataset_value.rows[].elements[].string_value" 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. So this ticket is to discuss the structure of the memory management. Some options I can currently think of: 1. Convert to JSON or XML using one of those libraries, and then use the same JSON or XML library to access the data 2. 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. 3. Use one of the FB_Factories to allow dynamic creation and distruction of FB instances. I will put this ticket in the 999.0 backlog, and for milestone 1.0 FB_Payload will only support those fields listed in the ticket [#11]2020-09-14 07:37:59.896000 Ticket #21: Payload Structure -> Metric Structure -> ... co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/21/ Ticket Payload Structure -> Metric Structure -> ... False 0 2020-04-04 23:29:58.964000 21 Payload Structure -> Metric Structure -> ... closed So looking at the attached .txt, you can see that each metric can have: recursive properties So in theory you could receive a payload: Payload.metric[0].properties.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].propertyset_value.values[0].string_value 'ad finitum' recursive metrics Same for: Payload.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0].template_value.metrics[0] a large 'static' address space for decoding Payload Blobs Take for example "Payload.metrics[].dataset_value.rows[].elements[].string_value" 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. So this ticket is to discuss the structure of the memory management. Some options I can currently think of: 1. Convert to JSON or XML using one of those libraries, and then use the same JSON or XML library to access the data 2. 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. 3. Use one of the FB_Factories to allow dynamic creation and distruction of FB instances. I will put this ticket in the 999.0 backlog, and for milestone 1.0 FB_Payload will only support those fields listed in the ticket [#11] False False 0 0 0 21 999 Backlog i-campbell None
Last updated: 2020-09-14

Ticket #29: MIT Licence ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Edit https://forge.codesys.com/prj/mqttsparkplugb/code/HEAD/tree/license.txt Year 2020 i would like my copyright to appear as i-campbell " Copyright (c) <year> <copyright holders=""></copyright></year> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "2020-09-14 07:37:59.889000 Ticket #29: MIT Licence co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/29/ Ticket MIT Licence False 0 2020-05-18 21:03:41.356000 29 MIT Licence closed Edit https://forge.codesys.com/prj/mqttsparkplugb/code/HEAD/tree/license.txt Year 2020 i would like my copyright to appear as i-campbell " Copyright (c) <year> <copyright holders=""></copyright></year> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. " False False 0 0 0 29 999 Backlog i-campbell None
Last updated: 2020-09-14

Ticket #47: list.removecomponents: it uses a while loop that causes headaches ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Headaches? yes, PLC crashes2020-09-14 07:37:59.893000 Ticket #47: list.removecomponents: it uses a while loop that causes headaches co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/47/ Ticket list.removecomponents: it uses a while loop that causes headaches False 0 2020-08-17 20:51:21.387000 47 list.removecomponents: it uses a while loop that causes headaches closed Headaches? yes, PLC crashes False False 0 0 0 47 999 Backlog i-campbell None
Last updated: 2020-09-14

Ticket #4: Create session state management for EoN Node ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The Eon device interacts with the MQTT server in a session. The session state management is well described in the techref. PDF. This session state management can be implemented via a state machine. Or if the state machine is 'simple' we can choose to implement is via simple binary logic. 2020-09-14 07:27:14.047000 Ticket #4: Create session state management for EoN Node co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/4/ Ticket Create session state management for EoN Node False 0 2020-03-26 16:01:43.707000 4 Create session state management for EoN Node closed The Eon device interacts with the MQTT server in a session. The session state management is well described in the techref. PDF. This session state management can be implemented via a state machine. Or if the state machine is 'simple' we can choose to implement is via simple binary logic. False False 0 0 0 4 MVP EoN aliazzz aliazzz
Last updated: 2020-09-14

Ticket #24: FB_MQTT_PubSub ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
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 SetSubscriberBuffer => // !needs implementation! IsMessageReceived() // TRUE if a message is ready to be digested GetMessage() // Provides the message itself => DEBUG! provides NOTHING currently :-( Subscribe() SubscriberBusy() SubscriberDone() SubscriberError() Unsubscribe() The behaviourmodel is phased out as it is overkill because each of the composite FB's allready implemented their own CMBL.IConc statemachine 2020-09-14 07:27:14.045000 Ticket #24: FB_MQTT_PubSub co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/24/ Ticket FB_MQTT_PubSub False 0 2020-04-13 12:32:02.777000 24 FB_MQTT_PubSub closed 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 SetSubscriberBuffer => // !needs implementation! IsMessageReceived() // TRUE if a message is ready to be digested GetMessage() // Provides the message itself => DEBUG! provides NOTHING currently :-( Subscribe() SubscriberBusy() SubscriberDone() SubscriberError() Unsubscribe() The behaviourmodel is phased out as it is overkill because each of the composite FB's allready implemented their own CMBL.IConc statemachine False False 0 0 0 24 MVP EoN aliazzz aliazzz
Last updated: 2020-09-14

Ticket #32: FB_MQTT_PubSub Considerations ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
PubSub can inform us that a message has been received via .MessageReceived(). The message & topic then can be obtained via .getmessage(). Example IF PubSub.MessageReceived() THEN myRecvMessage := PubSub.MyMessage( wsTopic => MyTopic); // pass the message to the payload decoder MyDecodedMessage := Payload.Decode( pBuf:=ADR(myRecvMessage),udiBufSize:=SIZEOF(myRecvMessage)); END_IF; => Passing a pointer/length of the blob (the undecoded received message) is far superior in speed and resources as no data is physically copied around. Binding a dynamic buffer is under future consideration. => Interaction/handshaking between PubSub and Payload in the usual way (xbusy, xdone, xerror) and methods for this are provided. => according to the documentation of the CODESYTS IIoT lib, there is a maximum message payload length. In the CODESYS IIot MQTT library, is a single subscriber only capable of just subscribing to a single topic? => I Assume so, as the provided example shows a single topic per subscriber instance. 2020-09-14 07:27:14.040000 Ticket #32: FB_MQTT_PubSub Considerations co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/32/ Ticket FB_MQTT_PubSub Considerations False 0 2020-05-24 11:49:29.024000 32 FB_MQTT_PubSub Considerations closed PubSub can inform us that a message has been received via .MessageReceived(). The message & topic then can be obtained via .getmessage(). Example IF PubSub.MessageReceived() THEN myRecvMessage := PubSub.MyMessage( wsTopic => MyTopic); // pass the message to the payload decoder MyDecodedMessage := Payload.Decode( pBuf:=ADR(myRecvMessage),udiBufSize:=SIZEOF(myRecvMessage)); END_IF; => Passing a pointer/length of the blob (the undecoded received message) is far superior in speed and resources as no data is physically copied around. Binding a dynamic buffer is under future consideration. => Interaction/handshaking between PubSub and Payload in the usual way (xbusy, xdone, xerror) and methods for this are provided. => according to the documentation of the CODESYTS IIoT lib, there is a maximum message payload length. In the CODESYS IIot MQTT library, is a single subscriber only capable of just subscribing to a single topic? => I Assume so, as the provided example shows a single topic per subscriber instance. False False 0 0 0 32 MVP EoN aliazzz aliazzz
Last updated: 2020-09-14

Ticket #49: EoN: FB_Edge_Of_Network_Node.ServerURL is not used ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_Edge_Of_Network_Node.ServerURL is not used, so the user cannot connect to a broker of their choice. Ideally this would be passed to _MQTT before connect2020-09-14 07:27:14.050000 Ticket #49: EoN: FB_Edge_Of_Network_Node.ServerURL is not used co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/49/ Ticket EoN: FB_Edge_Of_Network_Node.ServerURL is not used False 0 2020-09-11 22:57:38.637000 49 EoN: FB_Edge_Of_Network_Node.ServerURL is not used closed FB_Edge_Of_Network_Node.ServerURL is not used, so the user cannot connect to a broker of their choice. Ideally this would be passed to _MQTT before connect False False 0 0 0 49 MVP EoN i-campbell aliazzz
Last updated: 2020-09-14

Ticket #50: FB_MQTT: false calculation of _LastwillMessageSize ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_MQTT Line 2 is _LastWillMessageSize := DINT_TO_UINT(2*Stu.StrLenW(ADR(_LastWillMessage))); This doesn't make sense. _LastWillMessageSize is already set in FB_MQTT.SetLastWill, so you don't need to set it again to twice the length of some random series of bytes before you hit a dword 0x0000 (Pointer to Pointer to a Byte Array which isn't a wstring). I think line 2 has to go! (also line 1)2020-09-14 07:27:14.047000 Ticket #50: FB_MQTT: false calculation of _LastwillMessageSize co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/50/ Ticket FB_MQTT: false calculation of _LastwillMessageSize False 0 2020-09-11 23:30:18.688000 50 FB_MQTT: false calculation of _LastwillMessageSize closed FB_MQTT Line 2 is _LastWillMessageSize := DINT_TO_UINT(2*Stu.StrLenW(ADR(_LastWillMessage))); This doesn't make sense. _LastWillMessageSize is already set in FB_MQTT.SetLastWill, so you don't need to set it again to twice the length of some random series of bytes before you hit a dword 0x0000 (Pointer to Pointer to a Byte Array which isn't a wstring). I think line 2 has to go! (also line 1) False False 0 0 0 50 MVP EoN i-campbell aliazzz
Last updated: 2020-09-14

Ticket #51: EoN: EON.PublishBirth() calls publish() twice ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
EON.PublishBirth() calls _MQTT.publish() twice. publish() only sets the inputs to _Publisher, it is not until _MQTT() is called that the message is published with a call to _Publisher(). Either have some sort of state machine to 1. Connect 2. Publish NBirth 3. Publish DBirth Or have two publishers (and two blobs, etc)2020-09-14 07:27:14.049000 Ticket #51: EoN: EON.PublishBirth() calls publish() twice co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/51/ Ticket EoN: EON.PublishBirth() calls publish() twice False 0 2020-09-12 20:08:31.668000 51 EoN: EON.PublishBirth() calls publish() twice closed EON.PublishBirth() calls _MQTT.publish() twice. publish() only sets the inputs to _Publisher, it is not until _MQTT() is called that the message is published with a call to _Publisher(). Either have some sort of state machine to 1. Connect 2. Publish NBirth 3. Publish DBirth Or have two publishers (and two blobs, etc) False False 0 0 0 51 MVP EoN i-campbell aliazzz
Last updated: 2020-09-14

Ticket #52: FB_MQTT: PublishMessageSize is falsely calculated around line 32 ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Similar to [#50], but this time around line 30-32 of FB_MQTT(). _PublishMessageSize := DINT_TO_UDINT(2*Stu.StrLenW( ADR(_PublishMessage))); Should be deleted.2020-09-14 07:27:14.039000 Ticket #52: FB_MQTT: PublishMessageSize is falsely calculated around line 32 co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/52/ Ticket FB_MQTT: PublishMessageSize is falsely calculated around line 32 False 0 2020-09-12 20:15:20.127000 52 FB_MQTT: PublishMessageSize is falsely calculated around line 32 closed Similar to [#50], but this time around line 30-32 of FB_MQTT(). _PublishMessageSize := DINT_TO_UDINT(2*Stu.StrLenW( ADR(_PublishMessage))); Should be deleted. False False 0 0 0 52 MVP EoN i-campbell aliazzz
Last updated: 2020-09-14

Sort by relevance or date