Ticket #61: EoN: Maximum size NDEATH ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
In the code, it asks "What is the maximum size of an NDEATH" Answer: 44 Bytes. (see attachment) Note that changing the size to exactly 44 requires the fix in ticket [#60]. 2020-10-03 22:28:28.503000 Ticket #61: EoN: Maximum size NDEATH co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/61/ Ticket EoN: Maximum size NDEATH False 0 2020-10-02 10:51:33.261000 61 EoN: Maximum size NDEATH closed In the code, it asks "What is the maximum size of an NDEATH" Answer: 44 Bytes. (see attachment) Note that changing the size to exactly 44 requires the fix in ticket [#60]. False False 0 0 0 61 1.0.0.0: basic protobufs i-campbell aliazzz
Last updated: 2020-10-03

Ticket #76: FB_PayLoadMetric "hangs" if it receives an invalid message ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Is: FB_PayLoadMetric hangs after receiving an empty Message via NCMD/# (This is also expected with DCMD/# Should: FB_PayLoadMetric should at least continue without hanging and generate a warning or error (wwhaetever fits best) => Seeline 161, no CASE ELSE implemented.2020-10-15 22:29:02.148000 Ticket #76: FB_PayLoadMetric "hangs" if it receives an invalid message co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/76/ Ticket FB_PayLoadMetric "hangs" if it receives an invalid message False 0 2020-10-15 18:48:45.602000 76 FB_PayLoadMetric "hangs" if it receives an invalid message closed Is: FB_PayLoadMetric hangs after receiving an empty Message via NCMD/# (This is also expected with DCMD/# Should: FB_PayLoadMetric should at least continue without hanging and generate a warning or error (wwhaetever fits best) => Seeline 161, no CASE ELSE implemented. False False 0 0 0 76 1.0.0.0: basic protobufs hermsen None
Last updated: 2020-10-15

Ticket #93: Refining the state machine(s) ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The State Machine needs refinement to accommodate; improved readability and control over the state entry, exit and continuous parts. This is neccessary to get a statemachine that is usable for the EoN and Device to provide a better control over sending NBIRTH, NDATA, DBIRTH and DDATA payloads with according (Bd)seqnum's. FB_StateHelper is used for this task. It generates a pulse for StepEntry, StepExit and improves readability and reduces the burnplatecode considerably. 2020-12-12 17:19:51.495000 Ticket #93: Refining the state machine(s) co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/93/ Ticket Refining the state machine(s) False 0 2020-11-21 12:34:43.333000 93 Refining the state machine(s) closed The State Machine needs refinement to accommodate; improved readability and control over the state entry, exit and continuous parts. This is neccessary to get a statemachine that is usable for the EoN and Device to provide a better control over sending NBIRTH, NDATA, DBIRTH and DDATA payloads with according (Bd)seqnum's. FB_StateHelper is used for this task. It generates a pulse for StepEntry, StepExit and improves readability and reduces the burnplatecode considerably. False False 0 0 0 93 2.0.0.0 Standard Feature Product (SFP) hermsen hermsen
Last updated: 2020-12-12

Ticket #94: (Bd)SeqNum flow control issue's ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The EoN sends NDATA payloads. The Device is allowed to send DDATA payloads (by/through command of the EoN) It seems that the DDATA payloads are tagged with a SeqNum that is too high (it needs to be N, but is tagged with N+1) This incorrect tagging (N+1) causes/triggers the Server Node to issue a DBIRTH NCMD. Improve "assigning of seqnums to payloads" by implementing a mechanism to tag payloads "just in time" with a correct seqnum. This ticket also has a certain relation with "Improve control of/over/with statemachine [#93]" 2020-12-12 17:17:12.249000 Ticket #94: (Bd)SeqNum flow control issue's co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/94/ Ticket (Bd)SeqNum flow control issue's False 0 2020-11-21 12:54:51.650000 94 (Bd)SeqNum flow control issue's closed The EoN sends NDATA payloads. The Device is allowed to send DDATA payloads (by/through command of the EoN) It seems that the DDATA payloads are tagged with a SeqNum that is too high (it needs to be N, but is tagged with N+1) This incorrect tagging (N+1) causes/triggers the Server Node to issue a DBIRTH NCMD. Improve "assigning of seqnums to payloads" by implementing a mechanism to tag payloads "just in time" with a correct seqnum. This ticket also has a certain relation with "Improve control of/over/with statemachine [#93]" False False 0 0 0 94 2.0.0.0 Standard Feature Product (SFP) hermsen hermsen
Last updated: 2020-12-12

Ticket #95: Versions: Downgrade to 3.5.14.0 ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Downgrade library, compiler version, project, device to 3.5.14.0. This is the minimum system requirement for the MQTT Client SL. Moving to a lower version will allow more runtime systems to use this code.2021-02-06 16:37:40.714000 Ticket #95: Versions: Downgrade to 3.5.14.0 co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/95/ Ticket Improvement Versions: Downgrade to 3.5.14.0 False 0 2020-11-23 22:16:09.277000 95 Versions: Downgrade to 3.5.14.0 closed Downgrade library, compiler version, project, device to 3.5.14.0. This is the minimum system requirement for the MQTT Client SL. Moving to a lower version will allow more runtime systems to use this code. False False 0 0 0 95 2.0.0.0 Standard Feature Product (SFP) i-campbell i-campbell
Last updated: 2021-02-06

Ticket #114: Refactor anything "SparkplugB" into "Sparkplug" ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
With an eye on the future I noticed that we rely heavily on "SparkplugB", which is a specific version of the Sparkplug protocol instead of "Sparkplug" which is the protocol itself. So anything in the library which now is called "SparkplugB" could be refactored to "Sparkplug" where due (not everywhere!) I want to refactor several spots where I think a change is prudent.2021-02-18 21:00:08.768000 Ticket #114: Refactor anything "SparkplugB" into "Sparkplug" co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/114/ Ticket Refactor anything "SparkplugB" into "Sparkplug" False 0 2021-01-17 14:31:55.725000 114 Refactor anything "SparkplugB" into "Sparkplug" closed With an eye on the future I noticed that we rely heavily on "SparkplugB", which is a specific version of the Sparkplug protocol instead of "Sparkplug" which is the protocol itself. So anything in the library which now is called "SparkplugB" could be refactored to "Sparkplug" where due (not everywhere!) I want to refactor several spots where I think a change is prudent. False False 1 0 1 114 2.0.0.0 Standard Feature Product (SFP) hermsen None
Last updated: 2021-02-18

Ticket #117: FB_GroupID ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_GroupID is allocated through NBIRTHs and holds a list of Birthed Edge Nodes2021-02-22 20:23:03.396000 Ticket #117: FB_GroupID co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/117/ Ticket FB_GroupID False 0 2021-02-03 22:51:47.128000 117 FB_GroupID closed FB_GroupID is allocated through NBIRTHs and holds a list of Birthed Edge Nodes False False 0 0 0 117 2.0.0.0 Standard Feature Product (SFP) hermsen i-campbell
Last updated: 2021-02-22

Ticket #118: FB_RemoteDevice ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_RemoteDevice scans and allocates detected devices2021-07-25 12:46:03.071000 Ticket #118: FB_RemoteDevice co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/118/ Ticket FB_RemoteDevice False 0 2021-02-03 22:53:46.559000 118 FB_RemoteDevice closed FB_RemoteDevice scans and allocates detected devices False False 0 0 0 118 2.0.0.0 Standard Feature Product (SFP) hermsen i-campbell
Last updated: 2021-07-25

Ticket #119: FB_RemoteEdge ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_RemoteEdge parses and allocates Edges (nodes)2021-07-25 12:46:25.289000 Ticket #119: FB_RemoteEdge co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/119/ Ticket FB_RemoteEdge False 0 2021-02-03 23:01:07.229000 119 FB_RemoteEdge closed FB_RemoteEdge parses and allocates Edges (nodes) False False 0 0 0 119 2.0.0.0 Standard Feature Product (SFP) hermsen i-campbell
Last updated: 2021-07-25

Ticket #121: FB_VisuFolderStructure ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_VisuFolderStructure will make the chosen namespace visible2021-02-05 18:55:40.109000 Ticket #121: FB_VisuFolderStructure co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/121/ Ticket FB_VisuFolderStructure False 0 2021-02-05 18:55:39.996000 121 FB_VisuFolderStructure open FB_VisuFolderStructure will make the chosen namespace visible False False 0 0 0 121 2.0.0.0 Standard Feature Product (SFP) hermsen None
Last updated: 2021-02-05

Ticket #122: IFolderStructureSource ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
which can be implemented by (in order of priority) PrimaryHost Edge RemoteEdge RemoteDevice RemoteMetric2021-02-05 18:59:41.380000 Ticket #122: IFolderStructureSource co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/122/ Ticket IFolderStructureSource False 0 2021-02-05 18:59:41.338000 122 IFolderStructureSource open which can be implemented by (in order of priority) PrimaryHost Edge RemoteEdge RemoteDevice RemoteMetric False False 0 0 0 122 2.0.0.0 Standard Feature Product (SFP) hermsen None
Last updated: 2021-02-05

Ticket #134: Library Category: add Application category so library can be selected without "Display advanced libraries" ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
By Adding an additional library category "Application", the library can be found also when the "Display advanced libraries" button is not pressed. The category can be found in C:\Program Files\CODESYS 3.5.16.40\CODESYS\Templates\Library_Template\LibraryCategoryBase.libcat.xml2021-06-13 14:46:03.567000 Ticket #134: Library Category: add Application category so library can be selected without "Display advanced libraries" co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/134/ Ticket Library Category: add Application category so library can be selected without "Display advanced libraries" False 0 2021-04-12 11:05:07.836000 134 Library Category: add Application category so library can be selected without "Display advanced libraries" closed By Adding an additional library category "Application", the library can be found also when the "Display advanced libraries" button is not pressed. The category can be found in C:\Program Files\CODESYS 3.5.16.40\CODESYS\Templates\Library_Template\LibraryCategoryBase.libcat.xml False False 0 0 0 134 2.0.0.0 Standard Feature Product (SFP) i-campbell i-campbell
Last updated: 2021-06-13

Ticket #136: Edge seems to publish "empty" payloads ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The edge publishes somehow publishes payloads that are valid but empty i.e; Payloads contain timestamp and a valid seqnum, but the metrics section is empty; NDATA {"timestamp":1619874081095,"metrics":[],"seq":218} Replication: Set GenerateDataTimer to e.g. T#60s whilst keeping publishPeriod to e.g. 500 1) Find root cause of this unwanted and unnecessary sending of empty payloads, 2) Suggest and implement a suitable fix.2021-05-10 20:45:55.161000 Ticket #136: Edge seems to publish "empty" payloads co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/136/ Ticket Edge seems to publish "empty" payloads False 0 2021-04-30 13:32:44.858000 136 Edge seems to publish "empty" payloads closed The edge publishes somehow publishes payloads that are valid but empty i.e; Payloads contain timestamp and a valid seqnum, but the metrics section is empty; NDATA {"timestamp":1619874081095,"metrics":[],"seq":218} Replication: Set GenerateDataTimer to e.g. T#60s whilst keeping publishPeriod to e.g. 500 1) Find root cause of this unwanted and unnecessary sending of empty payloads, 2) Suggest and implement a suitable fix. False False 0 0 0 136 2.0.0.0 Standard Feature Product (SFP) hermsen hermsen
Last updated: 2021-05-10

Ticket #16: Implement SparkPlugB Device ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Advantages of Devices 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) FB_Device 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, Implements the same dynamic arrays of Sparkplug values as EoN, The EoN can iterate through the connected FB_Devices via a list and sends all relevant Data to Primary SCADA v1.1.x.x solution implements the basis for a List of Devices V1.3.x.x solution allows for multiple devices and DDATA V1.4.x.x solution can receive, digest and follow up DCMD's // Standard DCMD's digestion has been implemented2021-05-15 23:40:27.910000 Ticket #16: Implement SparkPlugB Device co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/16/ Ticket Implement SparkPlugB Device False 0 2020-03-29 00:35:06.103000 16 Implement SparkPlugB Device closed Advantages of Devices 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) FB_Device 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, Implements the same dynamic arrays of Sparkplug values as EoN, The EoN can iterate through the connected FB_Devices via a list and sends all relevant Data to Primary SCADA v1.1.x.x solution implements the basis for a List of Devices V1.3.x.x solution allows for multiple devices and DDATA V1.4.x.x solution can receive, digest and follow up DCMD's // Standard DCMD's digestion has been implemented False False 0 0 0 16 2.0.0.0: Device i-campbell hermsen
Last updated: 2021-05-15

Ticket #42: Devicetree (Json) ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
A hierarchical representation of the Edge of Network with devices. An EoN posseses it own metrics (meta data or information or properties, etc etc) and even have some sensors with corresponding metadata and values. It can also act as a gateway for (legacy)devices which also posses metrics and/ or sensors. The following is an example of such an EoN {"EoN": { "EoNMetric1": "Value", "EoNMetric2": "Value", "EoNMetric3": "Value", "EoNMetric4": "Value", "EoNMetric5": "Value", "EoNMetric6": "Value", "EoNMetric7": "Value", "EoNMetric8": "Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Device1": { "DeviceMetric1": "Value", "DeviceMetric2": "Value", "DeviceMetric3": "Value", "DeviceMetric4": "Value", "DeviceMetric5": "Value", "DeviceMetric6": "Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor3": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value" }, "Sensor4": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value" } }, "Device2": { "DeviceMetric1": "Metric1Value", "DeviceMetric2": "Metric2Value", "DeviceMetric3": "Metric3Value", "DeviceMetric4": "Metric4Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" } } } } ~~~2020-11-01 18:29:45.438000 Ticket #42: Devicetree (Json) co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/42/ Ticket Devicetree (Json) False 0 2020-07-31 10:40:30.514000 42 Devicetree (Json) closed A hierarchical representation of the Edge of Network with devices. An EoN posseses it own metrics (meta data or information or properties, etc etc) and even have some sensors with corresponding metadata and values. It can also act as a gateway for (legacy)devices which also posses metrics and/ or sensors. The following is an example of such an EoN ~~~ json {"EoN": { "EoNMetric1": "Value", "EoNMetric2": "Value", "EoNMetric3": "Value", "EoNMetric4": "Value", "EoNMetric5": "Value", "EoNMetric6": "Value", "EoNMetric7": "Value", "EoNMetric8": "Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Device1": { "DeviceMetric1": "Value", "DeviceMetric2": "Value", "DeviceMetric3": "Value", "DeviceMetric4": "Value", "DeviceMetric5": "Value", "DeviceMetric6": "Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor3": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value" }, "Sensor4": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value" } }, "Device2": { "DeviceMetric1": "Metric1Value", "DeviceMetric2": "Metric2Value", "DeviceMetric3": "Metric3Value", "DeviceMetric4": "Metric4Value", "Sensor1": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" }, "Sensor2": { "SensorMetric1": "Value", "SensorMetric2": "Value", "SensorMetric3": "Value", "SensorMetric4": "Value", "SensorMetric5": "Value", "SensorMetric6": "Value" } } } } False False 0 0 0 42 2.0.0.0: Device aliazzz None
Last updated: 2020-11-01

Ticket #92: FB_Device: Digest DCMD ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Implement DCMD similar to NCMD in [#89] 2020-12-27 20:45:03.178000 Ticket #92: FB_Device: Digest DCMD co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/92/ Ticket FB_Device: Digest DCMD False 0 2020-11-17 23:26:55.644000 92 FB_Device: Digest DCMD closed Implement DCMD similar to NCMD in [#89] False False 0 0 0 92 2.0.0.0: Device i-campbell hermsen
Last updated: 2020-12-27

Ticket #97: Allow correct publishing of Multiple Device Data ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Technically this should be orchestrated in the EoN. Is: Multiple devices claim the encoder ate the same time, so the buffer gets wiped and the last device "wins" Should: Devices should wait for each other to publish or maybe implement some totally different publish strategy.2020-12-18 22:06:26.085000 Ticket #97: Allow correct publishing of Multiple Device Data co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/97/ Ticket Allow correct publishing of Multiple Device Data False 0 2020-11-26 21:36:55.625000 97 Allow correct publishing of Multiple Device Data closed Technically this should be orchestrated in the EoN. Is: Multiple devices claim the encoder ate the same time, so the buffer gets wiped and the last device "wins" Should: Devices should wait for each other to publish or maybe implement some totally different publish strategy. False False 0 0 0 97 2.0.0.0: Device hermsen hermsen
Last updated: 2020-12-18

Ticket #100: EoN state machine should return to offline when an MQTT error occurs ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
as there is no way to error out of the two publish states, there is no way to reconnect to an MQTT Server once a connection is lost. => Yes, I have seen this effect during testing too, thanks for reminding me to make this ticket😀 A solution had already been thought off but the current seqnums issue has higher priority.😔 Suggested solution; After loss of connection, make sure the EoN can return to the offline step. The trigger to detect this is programmed outside the StateMachine. It is then forwarded into the state machine in form of an input command to let the EoN StateMachine go-to The offline state. The above mechanism will also trigger devices to go to plugged but offline as they monitor the EoN continuously. Whenever the connection restores the EoN will reconnect and the devices will automatically follow after the connection is restored with no programming required (by design)2021-01-02 13:03:35.029000 Ticket #100: EoN state machine should return to offline when an MQTT error occurs co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/100/ Ticket EoN state machine should return to offline when an MQTT error occurs False 0 2020-12-18 03:39:20.795000 100 EoN state machine should return to offline when an MQTT error occurs closed as there is no way to error out of the two publish states, there is no way to reconnect to an MQTT Server once a connection is lost. => Yes, I have seen this effect during testing too, thanks for reminding me to make this ticket😀 A solution had already been thought off but the current seqnums issue has higher priority.😔 Suggested solution; After loss of connection, make sure the EoN can return to the offline step. The trigger to detect this is programmed outside the StateMachine. It is then forwarded into the state machine in form of an input command to let the EoN StateMachine go-to The offline state. The above mechanism will also trigger devices to go to plugged but offline as they monitor the EoN continuously. Whenever the connection restores the EoN will reconnect and the devices will automatically follow after the connection is restored with no programming required (by design) False False 0 0 0 100 2.0.0.0: Device hermsen hermsen
Last updated: 2021-01-02

Ticket #101: Implement trigger for a DDEATH message as input FB_Device ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
An input on the Device POU should trigger sending a DDEATH certificate for this device. This input serves to accommodate this as the customer can then build a watchdog in their application to monitor the physical device. If the physical device is offline and the watchdogs triggers, this will be notified to the primary SCADA. FB_Device input : Device_Healthy, must be TRUE, if this signal becomes FALSE the DDEATH certificate will be issue if the connectionstate is online. During this phase the device will not send any data again. After the Device_Healthy has been set to TRUE, the device can resume it's normal course of functioning again (plugged, DBIRTH, DDATA etc). This mechanisms requires at least two states: DDEATH and HEALTH_RESTORE state DDEATH publishes the DDEATH certificate and after this the device moves to HEALTH_RESTORE state where the device idles and waits until the device health status returns to normal. After this the Device returns to the INIT state and resumes PLUGGED/ONLINE Note that the monitoring and sending of the input is only valid during device online sessionstate. If the EON session turns to offline during DDEATH period, the device will stay in HEALTH_RESTORE until the device is again healthy. If so the device goes to INIT and resumes plugged/ OFFLINE2020-12-19 01:23:57.470000 Ticket #101: Implement trigger for a DDEATH message as input FB_Device co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/101/ Ticket Implement trigger for a DDEATH message as input FB_Device False 0 2020-12-18 04:06:03.007000 101 Implement trigger for a DDEATH message as input FB_Device closed An input on the Device POU should trigger sending a DDEATH certificate for this device. This input serves to accommodate this as the customer can then build a watchdog in their application to monitor the physical device. If the physical device is offline and the watchdogs triggers, this will be notified to the primary SCADA. FB_Device input : Device_Healthy, must be TRUE, if this signal becomes FALSE the DDEATH certificate will be issue if the connectionstate is online. During this phase the device will not send any data again. After the Device_Healthy has been set to TRUE, the device can resume it's normal course of functioning again (plugged, DBIRTH, DDATA etc). This mechanisms requires at least two states: DDEATH and HEALTH_RESTORE state DDEATH publishes the DDEATH certificate and after this the device moves to HEALTH_RESTORE state where the device idles and waits until the device health status returns to normal. After this the Device returns to the INIT state and resumes PLUGGED/ONLINE Note that the monitoring and sending of the input is only valid during device online sessionstate. If the EON session turns to offline during DDEATH period, the device will stay in HEALTH_RESTORE until the device is again healthy. If so the device goes to INIT and resumes plugged/ OFFLINE False False 1 0 1 101 2.0.0.0: Device hermsen i-campbell
Last updated: 2020-12-19

Ticket #103: Device unplugging "on the fly" causes an exception ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
cause: pointer will turn to zero while still dereferencing this pointer 2020-12-19 15:24:24.543000 Ticket #103: Device unplugging "on the fly" causes an exception co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/103/ Ticket Device unplugging "on the fly" causes an exception False 0 2020-12-18 21:34:24.518000 103 Device unplugging "on the fly" causes an exception closed cause: pointer will turn to zero while still dereferencing this pointer False False 0 0 0 103 2.0.0.0: Device hermsen hermsen
Last updated: 2020-12-19

Ticket #105: Lowering Device CPU consumption ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
I have some ideas on how to get a lower CPU consumption per Device. This ticket is a placeholder for trying out many ideas 😄 Some of them can be mapped to the EoN too2021-04-30 13:39:48.547000 Ticket #105: Lowering Device CPU consumption co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/105/ Ticket Lowering Device CPU consumption False 0 2020-12-19 15:43:53.024000 105 Lowering Device CPU consumption closed I have some ideas on how to get a lower CPU consumption per Device. This ticket is a placeholder for trying out many ideas 😄 Some of them can be mapped to the EoN too False False 1 0 1 105 2.0.0.0: Device hermsen None
Last updated: 2021-04-30

Ticket #109: Move DCMD from EoN to Device ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The title says it all, moving DCMD to FB_Device2020-12-27 00:42:45.577000 Ticket #109: Move DCMD from EoN to Device co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/109/ Ticket Move DCMD from EoN to Device False 0 2020-12-23 02:42:01.343000 109 Move DCMD from EoN to Device closed The title says it all, moving DCMD to FB_Device False False 0 0 0 109 2.0.0.0: Device hermsen hermsen
Last updated: 2020-12-27

Ticket #131: Device: DDEATH or DBIRTH sometimes skipped ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
In testing, we saw that sometimes the DDEATH or (re-)DBIRTH are skipped, when the device transitions between healthy and not healthy. It should reliably send a DDEATH and (re-)DBIRTH. 2021-05-01 14:12:55.477000 Ticket #131: Device: DDEATH or DBIRTH sometimes skipped co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/131/ Ticket Device: DDEATH or DBIRTH sometimes skipped False 0 2021-03-30 20:39:29.924000 131 Device: DDEATH or DBIRTH sometimes skipped closed In testing, we saw that sometimes the DDEATH or (re-)DBIRTH are skipped, when the device transitions between healthy and not healthy. It should reliably send a DDEATH and (re-)DBIRTH. False False 0 0 0 131 2.0.0.0: Device i-campbell None
Last updated: 2021-05-01

Ticket #89: EoN: Digest NCMD ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Digest NCMD data and update .Value(s) Update example, for how to deal with variables which may be written by the user code or written by the NCMD from the Sparkplug Host. Ensure values which are written by NCMD are later published by an NDATA, if the new value is accepted.2021-04-30 13:34:43.542000 Ticket #89: EoN: Digest NCMD co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/89/ Ticket EoN: Digest NCMD False 0 2020-11-16 19:32:57.674000 89 EoN: Digest NCMD closed Digest NCMD data and update .Value(s) Update example, for how to deal with variables which may be written by the user code or written by the NCMD from the Sparkplug Host. Ensure values which are written by NCMD are later published by an NDATA, if the new value is accepted. False False 0 0 0 89 2.0.0.0: Edge i-campbell i-campbell
Last updated: 2021-04-30

Sort by relevance or date