Conditions for transition

[GrKoR]

@muxa
Hi!
Thnx for your work! It's cool! =)

Is there any way for conditional transitions?

In the simple example below I can go into two different states from state ON by transition BTN_PRESSED. How can I specify that transition ON -> OFF should be performed if some variable is set true? ON -> UNKNOWN transition should be performed in all other cases.

state_machine:
  - name: On/Off Toggle State Machine
    states:
      - "OFF"
      - "ON"
      - "UNKNOWN"
    inputs:
      - name: BTN_PRESSED
        transitions:
          - ON -> OFF
          - ON -> UNKNOWN
          - OFF -> ON

Yes, I can divide BTN_PRESSED input into two separated inputs: BTN_PRESSED_ONOFF and BTN_PRESSED_UNKNOWN. But... it looks strange :)
Is it possible to do this in more convenient way?

[muxa]

@GrKoR conditional transitions are not yet supported. I have not had a use case for them yet, and as you said it's possible to work around the limitation with separate inputs.

Out of curiosity, in what circumstance would a transition from ON to UNKNOWN happen?

As a side note, a disadvantage of conditional transitions IMO is that conditions are not explicitly depicted on the state diagram, so it make it harder to reason about the state machine.

[GrKoR]

@muxa for a more substantive conversation, here is part of my task.

state_machine:
  - name: Finite State Machine
    states:
      - FSM_IDLE
      - FSM_STATUS_OK
      - FSM_STATUS_ERROR
    inputs:
      - name: TIMEOUT
        transitions:
          - FSM_STATUS_OK -> FSM_IDLE
          - FSM_STATUS_ERROR -> FSM_IDLE
      - name: BTN_PRESSED
        transitions:
          - FSM_IDLE-> FSM_STATUS_OK
          - FSM_IDLE -> FSM_STATUS_ERROR

TIMEOUT input is generated by timer. BTN_PRESSED input is the button.

The transition to the FSM_IDLE state occurs by timeout from any of the FSM_STATUS_x states.
Returning from the FSM_IDLE state by pressing the button should occur in that FSM_STATUS_x state from which we previously left in FSM_IDLE. You can determine this by the error code, for example. But there is no way to determine the logic of work inside a finite state machine. So I need to pull this logic out of the state machine somewhere into the button on_press handler. It looks kind of weird. One part of transitions logic is described in the finite state machine, but other one will have to be taken out to completely different places of firmware.

Am I missing some obvious way to do this?

[muxa]

@GrKoR Can you explain a bit about when/how the error code is known? Is the error status "pushed" or "pulled"?

E.g. Is the button press required to check if there's an error? If so then it makes sense to split the inputs, i.e. the button produces 2 inputs 'OK' or 'ERROR'.

If the error state is "pushed" from some sensor, then perhaps the following will be more appropriate?

state_machine:
  - name: Finite State Machine
    states:
      - FSM_IDLE_OK
      - FSM_IDLE_ERROR
      - FSM_STATUS_OK
      - FSM_STATUS_ERROR
    inputs:
      - name: TIMEOUT
        transitions:
          - FSM_STATUS_OK -> FSM_IDLE_OK
          - FSM_STATUS_ERROR -> FSM_IDLE_ERROR
      - name: ERROR
        transitions:
          - FSM_IDLE_OK -> FSM_IDLE_ERROR
          - FSM_STATUS_OK -> FSM_STATUS_ERROR
      - name: BTN_PRESSED
        transitions:
          - FSM_IDLE_OK-> FSM_STATUS_OK
          - FSM_IDLE_ERROR -> FSM_STATUS_ERROR

[GrKoR]

@muxa Thanx for your ideas!

Error status is "pushed" from external water flow sensor. I didn't consider to use two states IDLE for this task. Double IDLE lead to doubling idle code but the size of this code is relatively small. At least it is significantly less than button on_press handler. So this is good solution for me.

Thank you!

[muxa]

There's a feature request with proposed implementation for conditions: #38

[GrKoR]

Cool! 👍🏼