[chermi]

Is there a modern reference implementation of statecharts? My understanding is that there's tons of offspring and they all kind of disagree. Same with regular FSM at least from limited understanding from this book https://ptolemy.berkeley.edu/books/leeseshia/.

I'm a little worried the author (Lee) may have a particular PoV and perhaps this wasn't the best resource to learn from?

I'm building an automated environmentally monitored +. controlled mushroom fruiting chamber. V1 I got by just with very basic state machines but I'm trying to take it up a notch in sophistication and do it the "right " way.

[RossBencina]

The ?modern reference specification is UML statecharts. However I'm under the impression that not all features are efficiently implementable. For example Miro Samek's book covers a subset for real-time systems: https://www.state-machine.com/psicc2 I highly recommend that book even if you end up rolling your own implementation.

[chermi]

Thanks! A quick glance at the book and it seems like it's focused on event-driven. Also seems kind of aligned with Lee's "actor model" stuff. I will read it more.

I am ok-but-not-great programmer, hence trying this project to get better. It seems like I should learn UML proper and this book looks like a good way to start; my "architecture" diagrams are pretty laughable. I bounce between trying to be formal and learn what "proper architecture diagrams" are vs. thinking I'm spending way too much time not coding.

I'm on a dirty and probably not-so-great hybrid of timer + event (mqtt) right now. I really want to try fully event-driven but it's a big change and I'm not very familiar with what it would entail. My original goal with this project was to implement MPC from scratch. V0 was mostly learning esp32 stuff and very basic bang-bang and timer control + FSMs that probably matched no formal specification. I've finished(or at least froze) the V1 microcontroller am starting the basic control/"driver" layer now, which is FSM based, so this reference is perfect timing. Thanks again!

[RossBencina]

Yes, very event/message-oriented. The state machines exchange messages and process them to completion. I'm not sure who Lee is (Actor Model proper is Carl Hewitt, Gul Agha) but it's interesting that you make the connection, I agree. Erlang, the actor language that never heard of the actor model, has an FSM class that is also interesting to look at.

UML is a standardisation of a bunch of different techniques for drawing pictures about systems. Drawing pictures can be useful for thinking about things, especially if you're a visual thinker. But statecharts are really the star of the show I think, they represent something that is easier to understand as a picture (hygraph) than as code.

[all2]

There is for JavaScript called XState. I think it is SCXML compliant .You might also take a look at qmuntal/stateless (not SCXML compliant), a golang module. It has rudimentary sub-state functionality.

I'm in the process of writing a golang library, if you're interested in seeing some raw development (IE, I'm in the middle of designing dev UX, and the guts of the lib have yet to be implemented).

You may also consider n8n for your uses. As workflow management goes, it is quite robust.

For embedded work, I honestly don't know. I do know that golang can be transpiled into C (https://tinygo.org/) and tinygo + qmuntal/stateless might work really well for your use-case.

[murki]

There's also https://github.com/cmars/statechart library built in rust

[chermi]

Thank you so much! For context, this for a "driver" running on a pi that controls actuators on an esp32 via MQTT. So the the most basics states just clones of the states (On/Off) on the esp32, while more complicated states would combine actions like fan + humidifier. I've written everything on the pi in python so far. But that was all V1 and I'm starting over so maybe I'll try something new.

[all2]

You might map out your functionality and see what you actually need in terms of programmatic functionality. LLMs are actually decent at creating the boilerplate if you know what you need.

Here's an example I had Claude throw together for states/substates for a door with a lock

https://mermaidchart.com/play?utm_source=mermaid_live_editor...

Wow. That's a lot of link. Here's the raw chart:

    stateDiagram-v2
    [*] --> Closed
    
    state Closed {
        [*] --> Locked
        Locked --> Unlocked: unlock / disengageBolt()
        Unlocked --> Locked: lock / engageBolt()
    }
    
    Closed --> Open: open [unlocked] / swing()
    Open --> Closed: close / checkSensors()
    
    note right of Closed
        Composite state with
        two substates
    end note
    
    note left of Open
        Simple state
    end note
    
    Locked: entry / engageBolt()
    Unlocked: entry / disengageBolt()
    Open: entry / startTimer()
    Open: exit / stopTimer()

The syntax in the text labels is written the same way the Harel paper proposes: <State>: <entry/exit> / <action>()

[chermi]

Thank you! I just started using mermaid via llms, it's been so helpful mapping ideas out and making sure the llm and I have shared understanding.

I definitely don't need super sophisticated functionality, but I'm trying learn a little more about formal system specification, modeling and verification like in https://mitpress.mit.edu/9780262548922/principles-of-cyber-p... and https://ptolemy.berkeley.edu/books/leeseshia/ while I'm working on this project(it might be a stretch, i'm trying to pack a lot of outcomes into one project in finite time).

I want to be able to do things like prove certain bad states are unreachable or that a certain state of the system will eventually be reached, stuff like that. I'm intrigued by the idea of analyzing/enumerating traces and the dynamical systems perspectives of trajectories through state space (background in physics- statistical mechanics).

My thinking is that the more formal and precise I am with specifying the state machine to begin with, the easier the analyses/modeling will be. I'm following a configuration-driven approach where the whole system is specified/composed from YAML/JSON, so I was planning in this iteration to come up with like a pydantic model to specify state machine behavior.

[all2]

I haven't looked into 'formal' verification methods for FSMs, so I did some light googling. I found this guy [0] which gives an overview of potential methods.

I'll have to think about testing methods more. There are a few things I would want to know about a single FSM: does it exit (various exit states, either error final state or valid final state), are there unreachable states, does it loop in places it shouldn't, does it enter states it shouldn't for a given stimuli (Events + Guards are the params for this test). I think there's also a place for event fuzzing to try and break the machine.

[0] https://www.linkedin.com/pulse/verification-testing-fsms-too...

[neilv]

It's not available, but I once made a researchy Statechart->Java compiler. For the concurrency, it leaned on Java's green threads.

Since then, I sometimes do manual implementations in code. For example, the Swift code of an iOS app I wrote has an ASCII art diagram of a hierarchical Statechart, for making the UI and NFC event handling solid (despite SwiftUI quirks and inconsistent docs at the time).