fgmacedo
question on documentation, process model
Hi, two points on https://github.com/fgmacedo/python-statemachine/blob/develop/docs/processing_model.md
- the statement below seems to have no effect on the code execution when removed:
def on_connect(self): return "on_connect"
-
It would be nice if the examples on the page included the use of Events by events, I mean explicitly declared events, the example on this page the events are not explicitly named and they automatically pass control from one to the other. I'd like events to be, for example, tied to (called from) outside the state machine, as in the "cycle" example.
Anyway, I know I'm misunderstanding something but I don't know exactly what I'm misunderstanding.
thank you bob s
For context, I am trying to implement a state machine for science operations of an ISR radar and yesterday I discovered that the "cycle" model does not match the reality of the states needed and today I'm trying to match reality with the process_model, except I need to add events that are explicitly called, not implicit in the transitions. An example would make this easier. thank you again
Hi @schaefer01, how are you?
-
You’re right — in this example the on_connect method doesn’t affect the execution flow itself. Its purpose is just to illustrate that the return value of an event action is collected by the state machine. That’s why the last line shows
['on_transition', 'on_connect']. -
Regarding Events: in my view, they’re more of an orthogonal concept. Declaring them explicitly makes the event class clearer, but in this specific example they don’t actually change the behavior.
When you mention the “cycle” mode, I believe you’re referring to a state machine that doesn’t receive explicit external events, but instead reacts only to a tick command. Is that correct? In the end, the choice really depends on how you want to design your use case.
Just a note: the Non-RTC mode is deprecated. In practice, it was a problematic implementation that could mix things up. What matters now is that in a reactive state machine only one event is processed at a time. Any additional events are placed into an internal queue. You’ll only run into this if you trigger new events from inside another event, or when working with multi-threading.
If you’d like, feel free to share a bit more about your expected events — maybe even a simplified version of your use case. It could help us build another useful example together. Also, have you had a chance to check out the examples gallery? https://python-statemachine.readthedocs.io/en/latest/auto_examples/index.html
HI, The "cycle" was the first example I found here: https://python-statemachine.readthedocs.io/en/develop/transitions.html the cycle allows events as well but the transitions must be in a cycle ala traffic lights and do not the freedom to transition more creatively. I'd suggest a pre-page, if you were the owner, of different types of transitions and perhaps a link to the gallery, which I have not yet looked at but will look at for ideas. When I saw the "transitions" page, I thought that cycles were the only transitions possible. If you walk back the URLs leading to this page, you can see what I mean. I followed the first URL to the wrong paradigm to a misleading conclusion.
The system I am using is RTC, anything Non-RTC would be a safety concern and would indicate something has gone wrong, though there are hardware safety features, so even if the software fails, the hardware will fail safe.
The use case is "data chained operations" a set of devices called services in a chain of data generation, data recording, and data processing, each a standalone program either running on its own physical or virtual computer. Each "ops device" runs a service. Each as well runs its own state machine. Each service goes through the initial state of power up to configure to initialize to run to servicing requests then an update (to check on its own status) then back to run or raise an error. If an error is detected, and that error is fatal, the service transitions to a cleanup then safe/exit state. Elsewhere is a monitoring service that monitors all devices state to make sure all are servicing requests. The communications protocol is mqtt. The database is a time-series tied to grafana for automated plots of system data for example power, temperature, etc.
The goal is to replace operations (that I don't know enough to talk about) with an instantiation of the above, the new running in parallel with the old system so in case the new is wrong operations wont break.