Control, Gateways & Networked Systems · Study deck

State Machines in IoT

Picture a pump controller that restarts after a power cut and resumes an unsafe command.

Gateway Gus is your guide for this deck.

statemachines

After studying this chapter

Learning objectives

You will be able to:

Explain why IoT systems use state machines to make device behavior checkable.
Route a learning path through fundamentals, implementation practice, and reusable design patterns.
Choose whether a behavior belongs in a device, gateway, service, or coordinated multi-machine design.
Compare Moore, Mealy, hierarchical, and parallel state-machine styles at a practical level.

State machine placement across IoT layers

Major section

Start With the Device Mode

Recovery must use recorded rules, not an operator's guess.

The first panel shows a dangerous restart command.
The final panel permits recovery only through a path someone else can replay.
A gateway connection is one event on that path, not proof of a safe pump state.

Major section

Start With the Device Mode (continued)

A gateway might be idle, joining, connected, retrying, degraded, or locked out, and each mode allows different events.

A gateway means the boundary system that joins local devices to another network or service.
A state machine starts when "the device is running" is no longer precise enough.
For IoT, naming those modes turns vague behavior into a contract that developers, operators, and testers can inspect.

State-machine style choice for IoT behavior

Major section

Minimum Viable Understanding

A state machine is useful when a system has named modes and clear events that move it between modes.

In IoT, those events often come from timers, sensors, radio links, buttons, gateway messages, reset causes, or service acknowledgements.
That order makes timing, persistence, and recovery part of the behaviour contract, so the later implementation and test record can prove deterministic outcomes.

Major section

Section Map

This section has three companion chapters.

The sequence moves from naming a behaviour contract, through implementing and testing it, to selecting structures that remain understandable as device coordination grows.

Major section

Where State Machines Fit in IoT

The key is to keep each machine responsible for one coherent behavior.

Choosing a state-machine boundary also chooses where events are interpreted and where recovery responsibility lives.
The separate operations line—incident, maintenance, rollback, close—shows why organisational response should not be hidden inside a device transition table.
This layering turns the chapter's “one coherent behavior” rule into a placement test: keep fast local safety near the device, coordination at the gateway or edge, and human workflow in systems that can own its full lifecycle.

Major section

State-Machine Styles

The style is a design choice.

Outputs are tied to state.
Outputs may depend on state and event.
Parent states share behavior across child states.
Independent concerns run as separate machines and coordinate through events instead of one flat combined state.

Major section

Pattern Families

Those differences explain the footer warning: Reusable does not mean copy blindly and connect the family choice to guards, faults, and tests for the actual device.

The: Workflow family adds acknowledgements and escalation, showing why an application transaction cannot inherit a radio reconnection machine unchanged.
Patterns are starting points, not templates to paste blindly.
Every pattern still needs guards, fault handling, and tests matched to the actual system boundary.

Major section

Coordination Without State Explosion

A gateway that tracks device link state, local buffer state, and command state should usually model those as separate machines that exchange events.

The important evidence in Figure: Parallel state machines coordinate through events is the relationship among offline, online: Service machine, and command_expired.
The first frames the issue, the second changes or constrains it, and the third makes the result visible.

Parallel state machines coordinate through events

Major section

Build Gateway State Machines

A building gateway receives sensor reports, buffers data during network outages, and forwards commands to local controllers.

The design check should split the concerns.
Event: buffer_full From: Buffer machine To: Command machine and Service machine Expected behavior: new noncritical commands are rejected and service check is opened.
This structure keeps each machine small while making coordination visible.

Major section

Overview: A State Machine Owns Behavior

A state machine is not just a diagram of possible modes.

If any step is missing, hidden flags and untested fault paths usually appear.
A sensor can report late, a gateway can lose backhaul, a command can expire, and a device can reboot in the middle of work.
The state machine makes those cases visible instead of leaving them as scattered flags.

Build IoT state machines as proofable behavior contracts: name the behavior boundary, define states and events, write the transition table, choose the smallest structure, verify fault and reset paths, and keep the proof record.

Deck summary

Key takeaways

Recovery must use recorded rules, not an operator's guess.

A gateway might be idle, joining, connected, retrying, degraded, or locked out, and each mode allows different events.
A state machine is useful when a system has named modes and clear events that move it between modes.
This section has three companion chapters.
The key is to keep each machine responsible for one coherent behavior.

Retrieval practice

Recall check 1 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q1A building gateway buffers sensor reports during backhaul outages and forwards local commands. The first diagram mixes link status, buffer fill, command acknowledgements, and maintenance lockout into one behavior claim. Which first check keeps the state-machine design traceable?

AApprove one combined diagram with extra labels but no separate events or ownership.

BUse one online command ACK as proof of buffer, service, and outage states.

CDefer timeout, retry, buffer-full, and reset behaviour until rollout.

DWrite event contracts for separate link, buffer, command, and service machines.

Show answer

Answer: D A traceable IoT state-machine design separates machine boundaries, names events and transitions, and proves normal, degraded, reset, and coordination behavior.

Retrieval practice

Recall check 2 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q2Which mapping of state-machine styles is accurate?

AHierarchy means unrelated machines; parallel means one shared child state.

BAll styles have identical output rules and differ only in drawing colour.

CMoore uses events only and Mealy state only; other styles are identical.

DMoore uses state; Mealy state and event; hierarchy shares parents; parallel coordinates.

Show answer

Answer: D Each style makes a distinct output or organization choice.

Retrieval practice

Recall check 3 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q3A gateway tracks radio link status, local buffer capacity, command acknowledgements, and maintenance lockout. The first design combines every combination into one flat state machine and becomes difficult to test. What is the best design response?

AKeep adding combined state names until every combination has a unique state.

BRemove the buffer and maintenance states because only link status matters.

CSplit concerns into separate machines coordinated by explicit events.

DUse boolean flags for the other concerns and keep only the radio link as a state machine.

Show answer

Answer: C Parallel state machines reduce state explosion when concerns are mostly independent but still coordinate through events.

Retrieval practice

Recall check 4 of 4

Gateway Gus says: answer from memory, then check your reasoning.

Q4A gateway reboots while a command is in the sent state. After restart, it restores sent from storage and waits forever for an acknowledgement that may never arrive. What should the state-machine proof require?

ARestore the previous state from storage and trust persistence to prove the command lifecycle is complete.

BTreat reset as a transition with expiry, recovery, visibility, and stale-command proof.

CDelete the command machine and rely on operator complaints plus logs to diagnose stuck acknowledgements.

DRetry the command indefinitely after reboot because the acknowledgement may still arrive later.

Show answer

Answer: B IoT state-machine proof should treat reset as a transition that checks persisted state, event age, safe outputs, expiry, recovery, and operator visibility before normal behavior resumes.

Print reference

Answers

Answer key.

D · A traceable IoT state-machine design separates machine boundaries, names events and transitions, and proves normal, degraded, reset, and coordination behavior.
D · Each style makes a distinct output or organization choice.
C · Parallel state machines reduce state explosion when concerns are mostly independent but still coordinate through events.
B · IoT state-machine proof should treat reset as a transition that checks persisted state, event age, safe outputs, expiry, recovery, and operator visibility before normal behavior resumes.