co⚡e: Sparkplug™ MQTT edge

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