co⚡e: Sparkplug™ MQTT edge

v1.1.1.7

Device Publisher Implemented

TODO debug

1.1.1.6

EoN => NBIRTH, NDATA, NCMD => REBIRTH, Write DATA from ServerSide
DEVICE => DBIRTH, DDATA

lib v1.1.1.6

Work in progress
Device Birth/Rebirth needs to be "stabilized" so that the device stay's alive.

SparkPlugB library
v1.1.1.6
fresh working branch

deleted

SparkPlugB library
v1.1.1.6
fresh working branch

example slightly retooled for lib v1.1.1.5

1.1.1.5
Added EoN ReBirth
FB_Edge_Of_Network_Node StateMachine Bug Fixes part 4

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