Design Patterns · Study deck

Device State Machines: Transition Contracts

A transition contract states when a device may change state.

Blueprint Bina is your guide for this deck.

statemachine

After studying this chapter

Learning objectives

You will be able to:

Explain: This distinction carries the running transition contract into the cloud: version the request, apply it idempotently on the device, and acknowledge the resulting reported state before declaring reconciliation complete.
Explain: A connection state machine protects the device from chaotic reconnect behavior and gives the cloud a clear view of whether the device is online, degraded, or intentionally disabled.
Explain: A received packet moves into: Receive, whereas local data takes the: Transmit path and waits at: Wait ACK before the cycle can close.
Explain: The pattern therefore connects transition timing and acknowledgement policy to the battery-life claim.

Major section

Start With the Decision

A transition contract states when a device may change state.

An event asks for the change.
A guard is a condition that must pass before an action runs.
A timeout sets the limit for waiting.
A transition contract connects current state, event, guard, action, target state, timeout, and log output.

Major section

Transition Contract

The visual matters because mixing those responsibilities makes retries unsafe and field failures difficult to reconstruct.

Every transition should be readable enough that firmware, cloud, QA, and operations teams can review it together.
Current state: The only mode where this transition is valid.
For safety paths, this should often be SAFE_OFF, ERROR, or LOCKOUT.

A transition contract connects current state, event, guard, action, target state, timeout, and log output

Major section

Pattern 1: Connection Lifecycle

A connection state machine protects the device from chaotic reconnect behavior and gives the cloud a clear view of whether the device is online, degraded, or intentionally disabled.

Offline: Radio or client is inactive.
Credentials may be missing, provisioning may be incomplete, or a retry delay may be running.
Online: The session is established.

Major section

Pattern 1: Connection Lifecycle (continued)

Connecting: The device activates the network, starts a bounded connection attempt, and waits for success or timeout.

Heartbeats, subscriptions, telemetry, and command channels are active.
Degraded: The device cannot reach the cloud but can still sample, buffer, or run local safety rules.
Connection retries need backoff, jitter, and a maximum local buffer policy.

Major section

Pattern 2: Sampling and Power

The pattern therefore connects transition timing and acknowledgement policy to the battery-life claim.

Sampling state machines keep energy, latency, and data quality decisions visible.
Energy claims need a time sequence, not just a list of modes.
The next event may be a timer, interrupt, command, or safety alarm.

Sensor duty cycling state machine with listen, receive, transmit, and sleep states

Major section

Pattern 2: Sampling and Power (continued)

A received packet moves into: Receive, whereas local data takes the: Transmit path and waits at: Wait ACK before the cycle can close.

The device filters, compresses, aggregates, or classifies data while the active budget remains available.
The device sends data if the network is available and a deadline remains.
If transmission is not possible, bounded local storage preserves the sample and the device returns to sleep.

Major section

Pattern 3: Actuator Safety

Actuator state machines need stricter recovery rules than telemetry workflows.

The safe state should be easy to enter, and dangerous states should be hard to re-enter accidentally.
Armed: Preconditions are satisfied, but motion or output has not started.
Guards are checked again before activation.
Active: The actuator is moving or energized.

Major section

Pattern 4: Cloud Shadow Reconciliation

Cloud shadows, device twins, and desired-reported property models are state reconciliation patterns.

They work best when the device treats cloud instructions as events and reports its actual state honestly.
Cloud reconciliation becomes unsafe when desired and observed state are treated as one value.
The cloud records an intended configuration or command.

Major section

Pattern 4: Cloud Shadow Reconciliation (continued)

The delta exists only while those values differ; it is not proof that the actuator already changed.

This distinction carries the running transition contract into the cloud: version the request, apply it idempotently on the device, and acknowledge the resulting reported state before declaring reconciliation complete.
The device has accepted a desired change and is attempting local work.
The device rejects an invalid, stale, unsafe, or unsupported desired state and reports why.

Major section

Hierarchical and Parallel State Machines

Simple FSMs are enough for many devices.

When the state count grows, use hierarchy or parallel regions rather than multiplying every combination into a new flat state.
One flat machine would multiply every link, buffer, command, and service mode into an unmanageable cross-product.
Hierarchical States.

Coordinating separate state machines with events

Major section

Hierarchical and Parallel State Machines (continued)

When the link changes from offline to online, it can emit an event that lets the buffer flush without rewriting command logic.

The event contracts preserve coordination while keeping each machine testable, which is the reason to introduce parallel state machines here.
For example, CONNECTED can contain IDLE, SAMPLING, and TRANSMITTING, while connection-loss handling remains defined once at the parent level.
A device may have one state machine for connectivity and another for actuator safety.

Major section

Architecture Review Checklist

Waiting states: Every waiting state has timeout and cancellation behavior.

Event inventory: External events, internal timers, watchdog warnings, cloud commands, operator actions, and sensor faults are all named.
Transition contract: Each transition defines source, event, guard, target, action, timeout, and log behavior.
Persistence: The design identifies which state is persisted across reboot and which state must be recomputed.

Deck summary

Key takeaways

A transition contract states when a device may change state.

The visual matters because mixing those responsibilities makes retries unsafe and field failures difficult to reconstruct.
A connection state machine protects the device from chaotic reconnect behavior and gives the cloud a clear view of whether the device is online, degraded, or intentionally disabled.
Connecting: The device activates the network, starts a bounded connection attempt, and waits for success or timeout.
The pattern therefore connects transition timing and acknowledgement policy to the battery-life claim.

Retrieval practice

Recall check 1 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q1A state machine has a WAIT_FOR_ACK state after sending an actuator command. The diagram only shows the transition when the acknowledgement arrives. What is the most important missing transition?

AA transition to a decorative loading state for the dashboard

BA timeout transition to safe, retry, or confirmation state

CA transition that retries the actuator command forever

DA transition that ignores all events until manual reboot

Show answer

Answer: B Every state that waits for an external event needs a timeout path.

Retrieval practice

Recall check 2 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q2A pump controller enters EMERGENCY_STOP after a pressure sensor fault. Which recovery rule is safest for a serious repeated fault?

AAutomatically restart after a short delay

BIgnore the sensor fault if the cloud is unreachable

CMove to LOCKOUT and require an explicit inspected reset

DRetry the actuator command until the pump starts

Show answer

Answer: C Serious or repeated actuator faults should move toward safe off or lockout.

Retrieval practice

Recall check 3 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q3A device model has connection states, power states, and actuator states. The team starts creating combined states such as CONNECTED_SLEEP_ARMED and RECONNECTING_SAMPLE_ACTIVE. What is the likely design problem?

AToo many transition events are being written to the device log

BThe system needs to delete all explicit states from the model

CState explosion from mixing concerns in one flat machine

DThe system has too few safety states for actuator lockout

Show answer

Answer: C State explosion happens when one flat machine combines independent dimensions.

Q4What input or elapsed condition asks a state machine to leave its current state?

AGuard

BAction

CEvent

DSafe fallback

Show answer

Answer: C It names the input or elapsed condition that asks the machine to leave its current state.

Retrieval practice

Recall check 4 of 4

Blueprint Bina says: answer from memory, then check your reasoning.

Q5Complete the table-driven state machine dispatch method:

Aself.state = initial

Bself.state = None

Cself.event = initial

Dinitial = self.state

Show answer

Answer: A A table-driven FSM keeps the current state, looks up transitions by (state, event), logs rejected events, runs the transition action, and then records the target state.

Q6Why should state transitions be logged with previous state, event, target state, and timestamp?

AThey replace unit tests for timeout, guard, and lockout behavior

BThey make invalid transitions safe without guards or review

CThey allow the system to remove guards after deployment

DThey provide transition history for diagnosing error or lockout paths

Show answer

Answer: D Transition logs make state-machine behavior observable.

Print reference

Answers 1 of 2

Answer key.

B · Every state that waits for an external event needs a timeout path.
C · Serious or repeated actuator faults should move toward safe off or lockout.
C · State explosion happens when one flat machine combines independent dimensions.
C · It names the input or elapsed condition that asks the machine to leave its current state.
A · A table-driven FSM keeps the current state, looks up transitions by (state, event), logs rejected events, runs the transition action, and then records the target state.

Device State Machines: Transition Contracts

Learning objectives

Start With the Decision

Transition Contract

Pattern 1: Connection Lifecycle

Pattern 1: Connection Lifecycle (continued)

Pattern 2: Sampling and Power

Pattern 2: Sampling and Power (continued)

Pattern 3: Actuator Safety

Pattern 4: Cloud Shadow Reconciliation

Pattern 4: Cloud Shadow Reconciliation (continued)

Hierarchical and Parallel State Machines

Hierarchical and Parallel State Machines (continued)

Architecture Review Checklist

Key takeaways

Recall check 1 of 4

Recall check 2 of 4

Recall check 3 of 4

Recall check 4 of 4

Answers 1 of 2

Answers 2 of 2