co⚡e: Sparkplug™ MQTT edge

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

messing around with broken /trunk/

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

branching library to branches/i-campbell/

tearing down branch

copy trunk example to personal branch

copy trunk to new personal branch

sunk personal branch

binary commit of example v1.1.1.0

prepared/updated example to libray v1.1.1.0

prepared/updated example to libray v1.1.1.0

binary commits of library v1.1.1.0

Version 1.1.1.0
merged hermsen branch 1.1.0.14 into trunk
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

update of branch

Extended the example with a total of 3 devices

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