Diagram showing the system states?

[m-mcgowan]

I've been asked for this more than once:

https://community.spark.io/t/firmware-state-during-forced-wifi-credentials-erasure/9732/4?u=mdma

The state diagram would provide a high-level overview of all the states the system can be in regarding

• system mode (manual, semi-automatic, automatic)
• listening mode (on/off)
• wifi connection (off/on/connecting/connected)
• cloud connection (disconnected/connecting/connected)
• details of when setup() and loop() are executed.
• LED color/flash/breathe in each state

The diagram also shows the transitions between states, and the events that happen to cause those transitions, such as external events (such as WiFi disconnected) or API calls (WiFi.disconnect())

Before creating the diagram, we of course need to write down all the info needed in the diagram - I'll gladly assist with that since I've been through the code in minute detail over the past weeks. With that done, we can then find a creative way to present all of that info concisely in a diagram.

[joegoggins]

A state machine diagram would be amazing. I have a huge and ridiculous wishlist surrounding this, treat all of the following like some "wouldn't it be cool if" type of feedback.

Though definitely not strictly necessary, it would be super cool if you could represent the state machine in a machine readable way and generate the diagram from that, using something like GraphViz. We could use a machine readable firmware state machine file for lots of things like:

• generating diagrams or interactive visualizations + tools to illustrate how the firmware works
• build automated external tests that validate firmware complies with it.
• build a hooks/callbacks system to trigger user specified functions before or after targeted state changes.

Lastly, if there were a way to extract + build the machine readable state file by parsing the firmware code directly, that would also be spectacularly useful to keep things up to date.

These suggestions are inspired by my usage of a Ruby Gem called "State Machine" in a prior project. This tool allowed us to encapsulate extremely complex workflows in a concise, documented, executable fashion that both programmers and application stakeholders could review to ensure we're all on the same page. The design of this tool was spectacular and it gave the dev team more confidence and understanding into how the app actually worked (and resulted in much less support questions after we shipped it). Though I know solving this problem in the firmware space will be wildly different, the design of this tool was wonderful and I imagine there are some insights + ideas that could be used from it.

Cheers!

-j

[pkourany]

OMG, what an amazing idea! With the Photon using FreeRTOS, the FSM and process view of the firmware is so important. With mutex and semaphores flying around, a visual representation of the firmware is a huge plus. The FSM approach is interesting, since most, if not all of the firmware is essentially a huge state driven machine. This needs further bantering about :)