co⚡e: Sparkplug™ MQTT edge

1.1.1.5
FB_Edge_Of_Network_Node StateMachine Bug Fixes part TROIS

EoN Statemachine Bugfixes part DEUX

EoN Statemachine Bugfixes part one

pre alpha version of the EoN state machine

1.1.1.4
FB_Edge_Of_Network_Node work in progress

restructured project by deleting nonsense;
Created a rough EoNStateMachine, which needs to be instantiated into the FB_Edge_Of_Network_Node

Created a rough EoNStateMachine, which needs to be instantiated into the FB_Edge_Of_Network_Node

Starting point new EoN device v1.1.1.3

Starting with v1.1.1.2 as base for the new EoN SFC State Machine implementation

Starting with v1.1.1.2 as base for the new EoN SFC State Machine implementation

As an EoN implementation has proven to be growing too complex too fast using a CASE construct,
I started experimenting with alternatives in a smaller setting, the device;

FB_DEVICE_ST_CASE: Showcases a StateMachine built usingthe CASE construct,
Plus: small / quick and fast, good for very simple state machines (at most 4 to 5 steps)
Min: The CASE construct requires self written burnerplate code to enable step enrty pulse, step exit pulses and lots of local variables to make stuff happen. The CASE quickly grows to 300+ lines of code and isn't nearly finished.

FB_DEVICE_ST_OOP: Showcases a StateMachine built using the State Design Pattern,
Plus: Very extensible, leverages the power of OOP really well. Combines interfaces, classes, inheritance and lots of other OOP tricks for ultimatly segmented code (DRY). Though I personnaly love it, it has some big downsides.
Min: The burnplate of this pattern is very big. Just to build a few stats you need to write lots of code. The State's are build into a separate FB's. This makes this pattern very usable foir highly complex machines!
Min: If the Statemachine is not too large this pattern shouldn't be used as it like shooting a cannon on a fly.
Because of the code high segmentation, overview is quickly lost without a proper diagram as this pattern isn't self describing and difficult to follow for someone who isn't into OOP.

FB_DEVICE_SFC: Showcases a StateMachine built using the SFC State Design Pattern
This language mixes the visual style of SFC with ST or any other IEC language. After some tinkering, I found that it can also be mixed with OOP very well. This pattern let me buid a statemachine with entry / exit code i n a few hours (2 a 3) so it is suited for our purpose!

Conclusion:
From what I see, the SFC is the best way to go as it mixes a visual style in combination with ST statements.
Therefore the Device will be put on HOLD as I will first rewrite the EoN using the SFC State design pattern
After introducttion of the state machine SFC pattern in the EoN, I can "extend" the EoN and the Device simultaniously with all goals in mind

Branch lib v1.1.1.0
Completely revised FB_Device with OOP Statemachine

Todo
Implement OOP Statemachine into EoN
Publish DDEATH
Support of multiple Devices

Branch lib v1.1.1.0
Completely revised FB_Device with OOP Statemachine

Todo
Implement OOP Statemachine into EoN
Publish DDEATH
Support of multiple Devices

copy trunk example to personal branch

copy trunk to new personal branch

sunk personal branch

update of branch

Version 1.1.0.13
Fixed the Rebirth publish issue for a connected device after the Server Node requests an EoN Rebirth
Fixed improved readability and control over the state entry, exit and continuous parts in EoN/Device
Fixed stable Device state

After a fierce fight with the code, we managed to get it working! Thx Ian
v1.1.0.11 features a working Device with a working DBIRTH /DDATA publish

Todo:
1) Refine the mechanism to allow for a DBIRTH after a Rebirth has been issued;
Hint: check the command chain and its feedback
_ItfCurDevice.NotifyBIRTHPublish := _ItfCurDevice.NotifyBIRTHPublish + 1;

2) Test/ check /refine to allow for more then 2 devices to publish MQTT wise

3) Implement DDEATH

v1.1.0.10 Device DBIRTH and DDATA working with stable seqnums.

> Encoder init separated from .addSeq
> Some EoN methods moved to Functions
> EoN notifies Device(s) when to Publish
> GC_SparkplugB Global Constants list
> Improved EoN state machine

TODO;
DDEATH
NCMD
DCMD

v1.1.0.10 Device DBIRTH and DDATA working with stable seqnums.

> Encoder init separated from .addSeq
> Some EoN methods moved to Functions
> EoN notifies Device(s) when to Publish
> GC_SparkplugB Global Constants list
> Improved EoN state machine

TODO;
DDEATH
NCMD
DCMD

v1.1.0.5 Device ith may tweaks but still no working SeqNum for DDATA...

> Encoder init separated from .addSeq (!)
> Some EoN methods moved to Functions
> EoN notifies Device when to Publish
> GC_SparkplugB Global Constants list

Branched from Trunk

V1.1.0.1 Example

Various small updates on the example to test various scenario's

Branch of Trunk

Device V1.1.0.1

TODO
* Check publishing DBIRTH Topic SeqNum (should be working)
* Check publish DDATA SeqNum (triggers REBIRTH, not correct yet)
* Publish DDEATH of a Device when occurs

teardown of branches