Control, Gateways & Networked Systems · Study deck
States, Events, and Transitions
Picture a cabinet controller receiving an unlock command while its door is already open.
Gateway Gus is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Define state, event, transition, guard, action, and fault state as distinct model elements
- Write a transition table naming source state, event, guard, action, next state, and expected output
- Design a bounded retry path that routes guard failures to an explicit fault or recovery state instead of retrying forever
- Convert asynchronous interrupts, callbacks, timers, and radio messages into explicit queued events before evaluating them against the current state
Major section
Overview: Make Device Behavior Explicit
Instead of scattering behavior across flags, callbacks, and nested conditionals, the state machine names where the device is, what happened, and what behavior is allowed next.
- This chapter focuses on the fundamentals: states, events, transitions, guards, actions, outputs, and fault paths.
- The goal is not a decorative diagram.
- A guard is not the same as an action.
Major section
Overview: Make Device Behavior Explicit (continued)
The goal is behavior that a developer can implement, a tester can exercise, and an operator can reason about when the device is under stress.
- For example, a soil-moisture sensor can be described with states such as SLEEP, SAMPLE, TRANSMIT, WAIT_ACK, and FAULT.
- The state-machine view also separates facts that are easy to confuse in code.
- The current state is not the same as the event that just arrived.
Major section
Overview: Make Device Behavior Explicit (continued)
A condition that must be true before the transition can fire.
- A timeout event is not the same as the retry policy.
- Each mode should have clear event handling and a clear way out.
- Good guards are fast, deterministic, and side-effect free.
- The event names the input, timer, completion, or failure that must be handled.
Major section
Overview: Make Device Behavior Explicit (continued)
The labels expose the mechanism behind a state-machine route is reviewable when the current state, event, guard, transition action, next state, and observable output are all named before code is written.
- An explicit safe mode that preserves useful context and prevents ambiguous half-completed behavior.
- The guard decides whether the transition is safe under the current context.
- The action and next state define visible output, resource use, and follow-up behavior.
Major section
Transition Contract
A practical state machine is a contract.
- It says which events are accepted in each state, which guards must pass, which actions run, and which next state becomes active.
- The contract should be readable as a transition table before it becomes code.
- Thus Transition Contract becomes part of the running system argument, not an isolated diagram tour.
Major section
Transition Contract (continued)
A flag combination that nobody can inspect.
- A clear side-effect-free condition, such as retry count below its limit.
- A guard that also sends messages or changes hardware.
- A battery sensor samples periodically, transmits a packet, and waits for an acknowledgement.
- Timers should arrive as events.
Major section
Transition Contract (continued)
Those labels explain how a transition table makes the design checkable because each row connects source state, event, guard, action, next state, and expected output.
- When the retry guard fails, the machine should enter a fault or recovery state instead of transmitting forever.
- Tests need that boundary.
- Retries need explicit guards and a recovery path.
Major section
Timing, Hierarchy, Fault Paths
In IoT devices, those hard parts are usually asynchronous events, timers, retries, shared resources, and recovery after faults.
- The internal design should make those pressures visible without turning every flag combination into a separate state.
- Asynchronous sources should not execute hidden state changes in whichever callback happens to run first.
- Behavior runs in an unpredictable order.
Major section
Timing, Hierarchy, Fault Paths (continued)
Timeouts become hidden loops or blocking waits.
- The: Event queue makes those inputs ordered and visible, and the: State machine handles one event at a time.
- That serialization is the connection from asynchronous hardware pressure to deterministic guards, actions, and replayable tests.
- Model timeout as an event and move long work into states.
Major section
Timing, Hierarchy, Fault Paths (continued)
It also gives a failure trace an unambiguous event order instead of leaving reviewers to reconstruct callback timing.
- Radio, sensor, storage, or actuator ownership becomes ambiguous.
- Once events are serialized, fault handling still needs an explicit route back to known behaviour.
- A flat state machine is easiest to audit, but it can grow quickly.
Major section
Timing, Hierarchy, Fault Paths (continued)
That path makes recovery evidence part of the transition contract and closes the timing discussion with a testable failure outcome.
- Tests can now assert both the FAULT entry outputs and the conditions that permit IDLE to resume.
- Events that arrive in the wrong state should be handled deliberately, not left to default behavior.
- Recovery tests should prove safe outputs, retry limits, preserved context, and return to a known state.
Deck summary
Key takeaways
Instead of scattering behavior across flags, callbacks, and nested conditionals, the state machine names where the device is, what happened, and what behavior is allowed next.
- The goal is behavior that a developer can implement, a tester can exercise, and an operator can reason about when the device is under stress.
- A condition that must be true before the transition can fire.
- The labels expose the mechanism behind a state-machine route is reviewable when the current state, event, guard, transition action, next state, and observable output are all named before code is written.
- A practical state machine is a contract.
Retrieval practice
Recall check 1 of 3
Gateway Gus says: answer from memory, then check your reasoning.
Q1A sensor alternates between SLEEP, SAMPLE, TRANSMIT, and FAULT. Why is this a good fit for a finite state machine?
Show answer
Answer: A Finite state machines are strongest when device modes, events, guards, outputs, and recovery paths need to be named and tested.
Retrieval practice
Recall check 2 of 3
Gateway Gus says: answer from memory, then check your reasoning.
Q2A TRANSMIT state retries forever after acknowledgement timeouts. Which transition-table change most directly fixes the design?
Show answer
Answer: A A transition table should expose both the retry path and the recovery path.
Retrieval practice
Recall check 3 of 3
Gateway Gus says: answer from memory, then check your reasoning.
Q3A firmware design handles radio callbacks, sensor completions, button presses, and timer expirations. What is the safest state-machine pattern?
Show answer
Answer: A Under the hood, robust IoT state machines turn asynchronous signals into explicit events and then evaluate those events against the current state.
Print reference
Answers
Answer key.
- A · Finite state machines are strongest when device modes, events, guards, outputs, and recovery paths need to be named and tested.
- A · A transition table should expose both the retry path and the recovery path.
- A · Under the hood, robust IoT state machines turn asynchronous signals into explicit events and then evaluate those events against the current state.