Ticket #33: 50% of FB/Function will need a Unit Test ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Unit test will be written to cover 50% of the FB's and methods from the library using Cfunit v1.1.0.0 or better. The unittest project in the trunk is to be leading. Any other tests can be written in branches to test personal developments. As the trunk of the library gets updated, ideally the unittest project of the trunk gets updated too. The software will be unit tested and/or integration tested, as much as possible. My suggestion is that we all take a peek at the unit test code whenever we feel like it to ensure that it passes a basic sanity level 2020-10-18 19:43:12.584000 Ticket #33: 50% of FB/Function will need a Unit Test co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/33/ Ticket 50% of FB/Function will need a Unit Test False 0 2020-06-20 11:52:55.777000 33 50% of FB/Function will need a Unit Test wont-fix Unit test will be written to cover 50% of the FB's and methods from the library using Cfunit v1.1.0.0 or better. The unittest project in the trunk is to be leading. Any other tests can be written in branches to test personal developments. As the trunk of the library gets updated, ideally the unittest project of the trunk gets updated too. The software will be unit tested and/or integration tested, as much as possible. My suggestion is that we all take a peek at the unit test code whenever we feel like it to ensure that it passes a basic sanity level False False 0 0 0 33 1.0.0.0: EoN aliazzz aliazzz
Last updated: 2020-10-18

Ticket #37: FB_MQTTPUBSUB : Before sending a payload, ensure that MQTT.MQTTParam.g_udiMaxPayloadSize and g_udiMaxPacketSize are appropriately set ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
As MQTT.MQTTParam.g_udiMaxPayloadSize and MQTT.MQTTParam.g_udiMaxPacketSize are library parameters, the end user has to set these, we cannot change them using the library. However, we can raise errors if we try to send something too big. To investigate: what happens when a packet or payload is received which is too big?2020-10-18 11:17:31.853000 Ticket #37: FB_MQTTPUBSUB : Before sending a payload, ensure that MQTT.MQTTParam.g_udiMaxPayloadSize and g_udiMaxPacketSize are appropriately set co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/37/ Ticket FB_MQTTPUBSUB : Before sending a payload, ensure that MQTT.MQTTParam.g_udiMaxPayloadSize and g_udiMaxPacketSize are appropriately set False 0 2020-07-07 16:52:04.531000 37 FB_MQTTPUBSUB : Before sending a payload, ensure that MQTT.MQTTParam.g_udiMaxPayloadSize and g_udiMaxPacketSize are appropriately set closed As MQTT.MQTTParam.g_udiMaxPayloadSize and MQTT.MQTTParam.g_udiMaxPacketSize are library parameters, the end user has to set these, we cannot change them using the library. However, we can raise errors if we try to send something too big. To investigate: what happens when a packet or payload is received which is too big? False False 0 0 0 37 1.0.0.0: EoN i-campbell aliazzz
Last updated: 2020-10-18

Ticket #39: FB_SparkplugB_SimpleEncoder ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
FB_SparkplugB_SimpleEncoder This function block acts as a Helper to reduce work for FB_EoN. The FB contains a protobuf blob encoder and various methods to quickly create (compose and/or encode) various messages. Since this FB is of the 'simple' variant, it can can only deal with the SimpleObjects type. Messages which are mandatory for this FB are: Node Death Certificate Node Birth Certificate Node Data Device Death Certificate Device Birth Certificate Device Data Pass a list of every All Metrics Which Will Ever Reported on during this "Lifetime". (1) UpdateListOfMetricsWhichWillEverReportedOn( ListOfMetricsWhichWillEverReportedOn )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 Device or Node can die and be reborn, elements could be added or removed from the list which will be announced only at the next Birth. Warning! 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 the FB contains various methods for interaction and diagnosis Diag // Diagnosis of the internal decoder state Encode( Enable ) // Start Encoding if Enable = TRUE, Stops encoding if enable = FALSE Encoded // Is encoding finished? EncodeBusy // Is the encoder busy? EncodeError( => eError ) // An error occured InitEncoderBeforeAddingMetrics( Timestamp, SeqNr) // Initialize the Encoder before adding Metrics GetBDSeqNum GetSeqNum 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 GetEncodedBlob( BlobAdr, BlobSize )2020-10-03 23:45:17.100000 Ticket #39: FB_SparkplugB_SimpleEncoder co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/39/ Ticket FB_SparkplugB_SimpleEncoder False 0 2020-07-24 12:04:22.256000 39 FB_SparkplugB_SimpleEncoder closed FB_SparkplugB_SimpleEncoder This function block acts as a Helper to reduce work for FB_EoN. The FB contains a protobuf blob encoder and various methods to quickly create (compose and/or encode) various messages. Since this FB is of the 'simple' variant, it can can only deal with the SimpleObjects type. Messages which are mandatory for this FB are: Node Death Certificate Node Birth Certificate Node Data Device Death Certificate Device Birth Certificate Device Data Pass a list of every All Metrics Which Will Ever Reported on during this "Lifetime". (1) UpdateListOfMetricsWhichWillEverReportedOn( ListOfMetricsWhichWillEverReportedOn )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 Device or Node can die and be reborn, elements could be added or removed from the list which will be announced only at the next Birth. Warning! 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 the FB contains various methods for interaction and diagnosis Diag // Diagnosis of the internal decoder state Encode( Enable ) // Start Encoding if Enable = TRUE, Stops encoding if enable = FALSE Encoded // Is encoding finished? EncodeBusy // Is the encoder busy? EncodeError( => eError ) // An error occured InitEncoderBeforeAddingMetrics( Timestamp, SeqNr) // Initialize the Encoder before adding Metrics GetBDSeqNum GetSeqNum 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 GetEncodedBlob( BlobAdr, BlobSize ) False False 0 0 0 39 1.0.0.0: EoN aliazzz aliazzz
Last updated: 2020-10-03

Ticket #41: Add SparkplugB.T_DateTime ALIAS for ULINT ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
I gather the description says it all! Add a SparkplugB.T_DateTime ALIAS TYPE for ULINT Usage: TimeStampOld : ULINT; TimeStampNew : SparkplugB.T_DateTime; // Still an ULINT ;-) 2020-10-03 21:17:15.797000 Ticket #41: Add SparkplugB.T_DateTime ALIAS for ULINT co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/41/ Ticket Add SparkplugB.T_DateTime ALIAS for ULINT False 0 2020-07-25 12:16:44.844000 41 Add SparkplugB.T_DateTime ALIAS for ULINT closed I gather the description says it all! Add a SparkplugB.T_DateTime ALIAS TYPE for ULINT Usage: TimeStampOld : ULINT; TimeStampNew : SparkplugB.T_DateTime; // Still an ULINT ;-) False False 0 0 0 41 1.0.0.0: EoN aliazzz aliazzz
Last updated: 2020-10-03

Ticket #55: How do we Implement #PublishInterval / PublishRate? ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Publish interval Definition PublishInterval / PublishRate is default set to 5000 ms. So we cannot publish "updates" any faster then each 5s. This means the publish rate is a kind of "sample-rate" per signal change: 5000 means 1 signal change per interval of 5 seconds is sent, 100 means 1 signal change per interval of 100mec is sent, 10000 means 1 signal change per interval of 10 seconds is sent. Solution We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.2020-09-30 16:35:09.139000 Ticket #55: How do we Implement #PublishInterval / PublishRate? co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/55/ Ticket How do we Implement #PublishInterval / PublishRate? False 0 2020-09-13 00:17:19.752000 55 How do we Implement #PublishInterval / PublishRate? closed Publish interval Definition PublishInterval / PublishRate is default set to 5000 ms. So we cannot publish "updates" any faster then each 5s. This means the publish rate is a kind of "sample-rate" per signal change: 5000 means 1 signal change per interval of 5 seconds is sent, 100 means 1 signal change per interval of 100mec is sent, 10000 means 1 signal change per interval of 10 seconds is sent. Solution We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown. False False 0 0 0 55 1.0.0.0: EoN aliazzz aliazzz
Last updated: 2020-09-30

Ticket #56: Edge_node_id and group_id elements may not contain /, #, + characters ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Update code to check/replace these illegal characters "/,+,#" from the Edge_Node _Id or Group_id element The illegal characters will be replaced with an underscore "_" 2020-09-30 16:34:44.283000 Ticket #56: Edge_node_id and group_id elements may not contain /, #, + characters co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/56/ Ticket Edge_node_id and group_id elements may not contain /, #, + characters False 0 2020-09-13 01:03:28.150000 56 Edge_node_id and group_id elements may not contain /, #, + characters closed Update code to check/replace these illegal characters "/,+,#" from the Edge_Node _Id or Group_id element The illegal characters will be replaced with an underscore "_" False False 0 0 0 56 1.0.0.0: EoN aliazzz aliazzz
Last updated: 2020-09-30

Ticket #57: EoN / Metrics: The final Metric of the example project is not showing up in ignition ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
In the example project, there is a metric: name: "ws3", Value: "nöö" which isn't being displayed in the Host Node (ignition). could it be the strange characters (ö)? could it be that it is the last metric in the list? who knows! check the NBIRTH message with a suitable subscriber. (final metric was missing) find and fix the problem. (see comment below for the issues found)2020-10-02 15:26:56.505000 Ticket #57: EoN / Metrics: The final Metric of the example project is not showing up in ignition co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/57/ Ticket EoN / Metrics: The final Metric of the example project is not showing up in ignition False 0 2020-09-15 19:45:18.103000 57 EoN / Metrics: The final Metric of the example project is not showing up in ignition closed In the example project, there is a metric: name: "ws3", Value: "nöö" which isn't being displayed in the Host Node (ignition). could it be the strange characters (ö)? could it be that it is the last metric in the list? who knows! check the NBIRTH message with a suitable subscriber. (final metric was missing) find and fix the problem. (see comment below for the issues found) False False 0 0 0 57 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-10-02

Ticket #58: EoN, NDATA: extra metric "seq" is not allowed ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
in NDATA the metric named Seq is not required, as the Seq has it's own protobuf identifier Payload.Seq This is a bug because the spec says that "17.1 NBIRTH : This includes every metric it will publish data for in the future." and the NBIRTH didn't contain this unneeded Metric. ==> IS: Payload.Metric.Name = "Seq" and Payload.Seq ==> SHOULD: remove the metric named Seq.2020-09-27 20:52:29.511000 Ticket #58: EoN, NDATA: extra metric "seq" is not allowed co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/58/ Ticket EoN Bug EoN, NDATA: extra metric "seq" is not allowed False 0 2020-09-15 22:30:30.044000 58 EoN, NDATA: extra metric "seq" is not allowed closed in NDATA the metric named Seq is not required, as the Seq has it's own protobuf identifier Payload.Seq This is a bug because the spec says that "17.1 NBIRTH : This includes every metric it will publish data for in the future." and the NBIRTH didn't contain this unneeded Metric. ==> IS: Payload.Metric.Name = "Seq" and Payload.Seq ==> SHOULD: remove the metric named Seq. False False 0 0 0 58 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-09-27

Ticket #62: Sparkplug Birth Death Sequence: Should it MOD 256? ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
I cannot see in the spec that it says we must limit bdSeq to 255 (and start over from 0). Currently the code does do MOD 256 at FB_SparkplugBSimple.GetBDSeqNum line 3. 1. confirm if bdseq should be MOD 256, perhaps look at java sample code. 2. if not, correct the code so it counts up to MAX_ULINT2020-10-02 16:21:12.754000 Ticket #62: Sparkplug Birth Death Sequence: Should it MOD 256? co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/62/ Ticket Sparkplug Birth Death Sequence: Should it MOD 256? False 0 2020-10-02 12:06:52.163000 62 Sparkplug Birth Death Sequence: Should it MOD 256? wont-fix I cannot see in the spec that it says we must limit bdSeq to 255 (and start over from 0). Currently the code does do MOD 256 at FB_SparkplugBSimple.GetBDSeqNum line 3. 1. confirm if bdseq should be MOD 256, perhaps look at java sample code. 2. if not, correct the code so it counts up to MAX_ULINT False False 0 0 0 62 1.0.0.0: EoN i-campbell None
Last updated: 2020-10-02

Ticket #63: EoN: NDATA puts elements into a second list ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
NDATA uses another list, ChangeList, in addition to the AllMetricsList. The problem is, these elements can only belong to one list. Solution: Rather than how it currently is: 1. Cycle through Every Element 2. Add changed element to ChangeList (side effect: removing element from AllMetricsList) 3. Call the AddListOfMetrics, which cycles through every changed element and adds them to the Encoder Should do: 1. Cycle through Every Element 2. Add changed element to Encoder2020-10-03 17:57:07.572000 Ticket #63: EoN: NDATA puts elements into a second list co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/63/ Ticket EoN: NDATA puts elements into a second list False 0 2020-10-02 20:52:15.206000 63 EoN: NDATA puts elements into a second list closed NDATA uses another list, ChangeList, in addition to the AllMetricsList. The problem is, these elements can only belong to one list. Solution: Rather than how it currently is: 1. Cycle through Every Element 2. Add changed element to ChangeList (side effect: removing element from AllMetricsList) 3. Call the AddListOfMetrics, which cycles through every changed element and adds them to the Encoder Should do: 1. Cycle through Every Element 2. Add changed element to Encoder False False 0 0 0 63 1.0.0.0: EoN i-campbell aliazzz
Last updated: 2020-10-03

Ticket #64: EoN: repeatedly publising NDATA or missing NDATA ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
If you only call PublishNDATA once, then an NDATA is not sent. If you call PublishNDATA repeatedly though, it continuously sends NDATA. A balance should be found, such that each change is sent only once.2020-10-03 22:28:07.537000 Ticket #64: EoN: repeatedly publising NDATA or missing NDATA co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/64/ Ticket EoN NDATA EoN: repeatedly publising NDATA or missing NDATA False 0 2020-10-03 18:01:55.582000 64 EoN: repeatedly publising NDATA or missing NDATA closed If you only call PublishNDATA once, then an NDATA is not sent. If you call PublishNDATA repeatedly though, it continuously sends NDATA. A balance should be found, such that each change is sent only once. False False 0 0 0 64 1.0.0.0: EoN i-campbell aliazzz
Last updated: 2020-10-03

Ticket #67: Print library version into SparkplugLog (immutable) ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Print library version and varoious other stuff into SparkplugLog which cannot be muted. So this info will always be available no matter what setting the user has chosen as verboselevel2020-10-12 20:17:59.143000 Ticket #67: Print library version into SparkplugLog (immutable) co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/67/ Ticket Print library version into SparkplugLog (immutable) False 0 2020-10-07 16:12:45.123000 67 Print library version into SparkplugLog (immutable) closed Print library version and varoious other stuff into SparkplugLog which cannot be muted. So this info will always be available no matter what setting the user has chosen as verboselevel False False 0 0 0 67 1.0.0.0: EoN hermsen hermsen
Last updated: 2020-10-12

Ticket #68: EoN: repeatedly publising NDATA ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The below code does not survive a connect-disconnect-(wait 5 seconds)-connect. EoNStateType.ONLINE : _PublishBlockTimerEnable := _ChangeDetected AND NOT _PublishBlocked; _PublishBlockTimer(IN := _PublishBlockTimerEnable, PT := UINT_TO_TIME(publishPeriod), Q => _PublishBlocked, ET => _PublishBlockTimerElapsed); EoNStateType.EXITING : _PublishBlocked := FALSE; It should be rewritten, so that the timer doesn't get stuck. The effect is, that NDATAs are sent with unrestricted publish period.2020-10-15 22:26:08.993000 Ticket #68: EoN: repeatedly publising NDATA co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/68/ Ticket EoN: repeatedly publising NDATA False 0 2020-10-09 22:05:53.389000 68 EoN: repeatedly publising NDATA closed The below code does not survive a connect-disconnect-(wait 5 seconds)-connect. EoNStateType.ONLINE : _PublishBlockTimerEnable := _ChangeDetected AND NOT _PublishBlocked; _PublishBlockTimer(IN := _PublishBlockTimerEnable, PT := UINT_TO_TIME(publishPeriod), Q => _PublishBlocked, ET => _PublishBlockTimerElapsed); EoNStateType.EXITING : _PublishBlocked := FALSE; It should be rewritten, so that the timer doesn't get stuck. The effect is, that NDATAs are sent with unrestricted publish period. False False 0 0 0 68 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-15

Ticket #69: MQTT: ping interval should = keep alive time ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The MQTT spec says "If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed" IS: currently in our library Ping interval is fixed at 15s, but KeepAlive is set by the user. In the example it is set to 60 seconds. SHUOLD: The ping interval should be set equal to the KeepAlive time2020-10-15 22:26:35.632000 Ticket #69: MQTT: ping interval should = keep alive time co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/69/ Ticket MQTT: ping interval should = keep alive time False 0 2020-10-09 22:09:39.767000 69 MQTT: ping interval should = keep alive time closed The MQTT spec says "If the Keep Alive value is non-zero and the Server does not receive a Control Packet from the Client within one and a half times the Keep Alive time period, it MUST disconnect the Network Connection to the Client as if the network had failed" IS: currently in our library Ping interval is fixed at 15s, but KeepAlive is set by the user. In the example it is set to 60 seconds. SHUOLD: The ping interval should be set equal to the KeepAlive time False False 0 0 0 69 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-10-15

Ticket #70: MQTT: Subscribers outputting "Client not connected to broker" ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
IS: Because we do not unsubscribe before disconnecting, we get a Subscriber.xError and eMQTTError := Client not connected to broker. Should: unsubscribe before disconnecting.2020-10-15 22:42:09.132000 Ticket #70: MQTT: Subscribers outputting "Client not connected to broker" co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/70/ Ticket MQTT: Subscribers outputting "Client not connected to broker" False 0 2020-10-09 22:12:52.381000 70 MQTT: Subscribers outputting "Client not connected to broker" closed IS: Because we do not unsubscribe before disconnecting, we get a Subscriber.xError and eMQTTError := Client not connected to broker. Should: unsubscribe before disconnecting. False False 0 0 0 70 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-15

Ticket #72: MQTT: FB_MQTT.IsConnected producing false positives ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
There is an issue in our method FB_MQTT.IsConnected also rewrite it to resolve the eMQTTConnectionState then we are in the clear with false positives on the connect case.2020-10-15 22:28:01.915000 Ticket #72: MQTT: FB_MQTT.IsConnected producing false positives co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/72/ Ticket MQTT: FB_MQTT.IsConnected producing false positives False 0 2020-10-09 22:36:48.691000 72 MQTT: FB_MQTT.IsConnected producing false positives closed There is an issue in our method FB_MQTT.IsConnected also rewrite it to resolve the eMQTTConnectionState then we are in the clear with false positives on the connect case. False False 0 0 0 72 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-15

Ticket #73: EoN: Testing IIoT Host Node does not like it when it doesn't see a NDEATH ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Our current method of CONNECT/DISCONNECT does not allow an NDEATH do be sent, as we are considered to be disconnecting gracefully. Research must be done: 1. What are the Sparkplug B requirements for NBIRTH if we disconnect gracefully? disgracefully? 2. Can we disconnect disgracefully? 3. What are the requirements of our Testing IIoT Host Node, for NBIRTH / DBIRTH? 4. What can we do to recover from losing bdSeq synchronicity? Part of this might mean we need to implement Node Control/Rebirth spBv1.0/SparkplugBDevice/NBIRTH/EdgeOfNetworkNode1 {"timestamp":1602284262173,"metrics":[{"name":"Node Control/Rebirth","timestamp":1602284262173,"dataType":"Boolean","value":true}],"seq":-1} ~~~2020-10-15 22:26:51.002000 Ticket #73: EoN: Testing IIoT Host Node does not like it when it doesn't see a NDEATH co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/73/ Ticket EoN: Testing IIoT Host Node does not like it when it doesn't see a NDEATH False 0 2020-10-09 23:00:10.531000 73 EoN: Testing IIoT Host Node does not like it when it doesn't see a NDEATH closed Our current method of CONNECT/DISCONNECT does not allow an NDEATH do be sent, as we are considered to be disconnecting gracefully. Research must be done: 1. What are the Sparkplug B requirements for NBIRTH if we disconnect gracefully? disgracefully? 2. Can we disconnect disgracefully? 3. What are the requirements of our Testing IIoT Host Node, for NBIRTH / DBIRTH? 4. What can we do to recover from losing bdSeq synchronicity? Part of this might mean we need to implement Node Control/Rebirth spBv1.0/SparkplugBDevice/NBIRTH/EdgeOfNetworkNode1 {"timestamp":1602284262173,"metrics":[{"name":"Node Control/Rebirth","timestamp":1602284262173,"dataType":"Boolean","value":true}],"seq":-1} ~~~ False False 0 0 0 73 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-10-15

Ticket #77: TLS hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate Maybe as workaround, we could make our code convert hCert=0 to hCert=SysTypes.RTS_INVALID_HANDLE2020-10-18 19:37:44.572000 Ticket #77: TLS hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/77/ Ticket TLS hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate False 0 2020-10-18 11:20:43.238000 77 TLS hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate closed hCert needs to be SysTypes.RTS_INVALID_HANDLE, if there is no client certificate Maybe as workaround, we could make our code convert hCert=0 to hCert=SysTypes.RTS_INVALID_HANDLE False False 0 0 0 77 1.0.0.0: EoN hermsen hermsen
Last updated: 2020-10-18

Ticket #78: EoN: Uses non-unique ClientID ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
Every EoN Node must have the same GroupID. Every MQTT Client must have a unique ID. IS: Client ID = GroupID (non-unique) SHOULD: Suggest: ClientID = GroupID + EoNID . Then Strip illegal characters and shorten to 23 characters (take the right) Background From MQTT Spec: "The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5]."2020-10-18 19:37:31.158000 Ticket #78: EoN: Uses non-unique ClientID co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/78/ Ticket EoN: Uses non-unique ClientID False 0 2020-10-18 15:49:27.333000 78 EoN: Uses non-unique ClientID closed Every EoN Node must have the same GroupID. Every MQTT Client must have a unique ID. IS: Client ID = GroupID (non-unique) SHOULD: Suggest: ClientID = GroupID + EoNID . Then Strip illegal characters and shorten to 23 characters (take the right) Background From MQTT Spec: "The Server MUST allow ClientIds which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" [MQTT-3.1.3-5]." False False 0 0 0 78 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-10-18

Ticket #80: MQTT: Not resubscribing ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
The _NCMD and _DCMD are reporting NOT_CONNECTED_TO_BROKER, when we try to resubscribe. _Client.xConnectedToBroker is TRUE though 2020-10-24 22:18:57.382000 Ticket #80: MQTT: Not resubscribing co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/80/ Ticket MQTT: Not resubscribing False 0 2020-10-18 21:39:31.206000 80 MQTT: Not resubscribing closed The _NCMD and _DCMD are reporting NOT_CONNECTED_TO_BROKER, when we try to resubscribe. _Client.xConnectedToBroker is TRUE though False False 0 0 0 80 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-24

Ticket #81: Comment the Example Project ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
comment TLS example comment regular example2020-10-24 22:35:51.343000 Ticket #81: Comment the Example Project co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/81/ Ticket Comment the Example Project False 0 2020-10-18 21:41:43.534000 81 Comment the Example Project closed comment TLS example comment regular example False False 0 0 0 81 1.0.0.0: EoN i-campbell i-campbell
Last updated: 2020-10-24

Ticket #82: EoN: SparkplugSimple.Notify requires handshake ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
At the moment, if a SparkplugSimple.Value is written with a new value, a notify bit is set. If it is written again without changing the value, the notify bit is cleared. This should be changed to: if a SparkplugSimple.Value is written with a new value, a notify bit is set. If the notification is acknowledged, the notify bit is cleared. The code which uses the notification should then call the AcknowledgeNotify() method.2020-10-24 22:18:41.257000 Ticket #82: EoN: SparkplugSimple.Notify requires handshake co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/82/ Ticket EoN: SparkplugSimple.Notify requires handshake False 0 2020-10-22 20:17:23.722000 82 EoN: SparkplugSimple.Notify requires handshake closed At the moment, if a SparkplugSimple.Value is written with a new value, a notify bit is set. If it is written again without changing the value, the notify bit is cleared. This should be changed to: if a SparkplugSimple.Value is written with a new value, a notify bit is set. If the notification is acknowledged, the notify bit is cleared. The code which uses the notification should then call the AcknowledgeNotify() method. False False 0 0 0 82 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-24

Ticket #83: EoN: Retry connect timer ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
If the EoN Fails to connect, it should retry continuously to connect after a time. This should be an exponential backoff timer, with an upper limit.2020-10-24 22:18:27.624000 Ticket #83: EoN: Retry connect timer co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/83/ Ticket EoN: Retry connect timer False 0 2020-10-22 20:22:32.421000 83 EoN: Retry connect timer closed If the EoN Fails to connect, it should retry continuously to connect after a time. This should be an exponential backoff timer, with an upper limit. False False 0 0 0 83 1.0.0.0: EoN i-campbell hermsen
Last updated: 2020-10-24

Ticket #34: Implement basic metrics for now ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
For now, we do not use anything except the basic metrics we can sooner "complete" Payload encode/ decode by throwing not implemented for all of the Metric members we don't use (template, etc) Create a sample FB_SparkplugBoolMetric, which contains some storage to play around with this idea. With basic metrics is ment: basetype variables, no "advanced" metrics or historical things Whatever happens, the TimeStamp is mandatory and implemented. As TimeStamp we take the current time as read from the controller. If an interested user has a controller which does not contain an RTC, we will work with that user to come up with an alternative. For now though, it is not supported. 2020-09-16 18:30:17.305000 Ticket #34: Implement basic metrics for now co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/34/ Ticket Implement basic metrics for now False 0 2020-06-27 11:06:54.982000 34 Implement basic metrics for now closed For now, we do not use anything except the basic metrics we can sooner "complete" Payload encode/ decode by throwing not implemented for all of the Metric members we don't use (template, etc) Create a sample FB_SparkplugBoolMetric, which contains some storage to play around with this idea. With basic metrics is ment: basetype variables, no "advanced" metrics or historical things Whatever happens, the TimeStamp is mandatory and implemented. As TimeStamp we take the current time as read from the controller. If an interested user has a controller which does not contain an RTC, we will work with that user to come up with an alternative. For now though, it is not supported. False False 0 0 0 34 1.0.0.0: basic protobufs aliazzz i-campbell
Last updated: 2020-09-16

Ticket #60: FB_Payload: The shuffling of values uses one more byte than it need to ^{co⚡e: Sparkplug™ MQTT edge and host tickets (Ticket)}
In FB_Payload.ReencodeLengthDelimited, it shuffles a byte array along a few bytes. However, it shuffles one more byte than it should. This is only an issue, if the calling method gives you only exactly the same number of bytes as the payload. Solution: change the move so it doesn't move unnecessary bytes. Probably lines 7 and 9.2020-10-02 11:08:24.849000 Ticket #60: FB_Payload: The shuffling of values uses one more byte than it need to co⚡e: Sparkplug™ MQTT edge and host cobolt tickets tickets False /lib/cobolt/tickets/60/ Ticket FB_Payload: The shuffling of values uses one more byte than it need to False 0 2020-10-02 10:50:53.793000 60 FB_Payload: The shuffling of values uses one more byte than it need to closed In FB_Payload.ReencodeLengthDelimited, it shuffles a byte array along a few bytes. However, it shuffles one more byte than it should. This is only an issue, if the calling method gives you only exactly the same number of bytes as the payload. Solution: change the move so it doesn't move unnecessary bytes. Probably lines 7 and 9. False False 0 0 0 60 1.0.0.0: basic protobufs i-campbell i-campbell
Last updated: 2020-10-02

Sort by relevance or date