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

Gateway Gus, the module guide, in a scene from this chapter.

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.

Major section

Start With the Device Mode

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

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.

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.

State machine placement across IoT layers

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.

State-machine style choice for IoT behavior

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.

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 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.

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.

This section has three companion chapters.
The key is to keep each machine responsible for one coherent behavior.
The style is a design choice.
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.

Retrieval practice

Recall check 1 of 3

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?

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

BApprove the combined diagram after adding labels for link status, buffer fill, command acknowledgement, and maintenance lockout.

CRun one online command demonstration and treat the acknowledgement, buffer counter, and service log as proof of all states.

DLeave timeout, retry, buffer-full, and reset behavior for rollout because diagrams only need the normal gateway flow.

Show answer

Answer: A 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 3

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

Q2A 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?

ASplit concerns into separate machines coordinated by explicit events.

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

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

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

Show answer

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

Retrieval practice

Recall check 3 of 3

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

Q3A 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?

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

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

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: A 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.

A · A traceable IoT state-machine design separates machine boundaries, names events and transitions, and proves normal, degraded, reset, and coordination behavior.
A · Parallel state machines reduce state explosion when concerns are mostly independent but still coordinate through events.
A · 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.