11 Device State Machines: Modes and Safety

11.1 Start With the Decision

Prove the Door Cannot Enter an Impossible Mode

11.2 Route Overview

This is part 1 of 2. Continue with Device State Machines: Transition Contracts.

11.3 Part Objectives

• Test modes become safer when they are named with a concrete scenario and pass criteria.
• Validate state machine pattern map with a concrete scenario and pass criteria.

11.4 Start With the Behavior That Must Not Be Ambiguous

Prove the Door Cannot Enter an Impossible Mode

Picture a powered door that reports locked while it is still moving. A state diagram is useful only if the real controller rejects that impossible combination.

An actuator means the part that causes a physical action, such as moving the lock. Name each state, event, guard, and action before writing the transition rules.

Run normal, blocked, repeated, and out-of-order events. Keep the starting state, event, guard result, next state, actuator command, time, and software version so another person can replay the sequence.

This check proves the named sequences on one build, not every timing fault. The deeper sections compare patterns, hierarchy, concurrency, persistence, and recovery.

A state-machine pattern earns its place when a device has behavior that prose cannot keep straight. Sleep, wake, sample, transmit, retry, fault, and recover are simple words, but a deployed device needs exact rules for moving between them.

The practical story is to make modes visible before adding cleverness. Start with the confusing behavior, turn it into named states and events, then choose the pattern that keeps illegal transitions out of the system.

11.5 Modes Become Safer When They Are Named

A state machine turns scattered conditions into a small set of legal modes. That matters for IoT because connection, power, command, actuator, and cloud-shadow behavior all depend on what the device or service is allowed to do right now. A device that is commissioning over BLE, reconnecting over LTE, applying a firmware update, or holding an actuator in lockout should not be interpreted through the same loose set of flags. The mode is part of the product contract.

The design quality test is whether the model rejects impossible combinations before they escape into firmware and operations. A gateway should not be both locked out and active. A sensor should not transmit forever after a missed acknowledgement. A shadow should not report success for a command the device rejected locally. These are not cosmetic diagram problems; they are the conditions that create dead batteries, duplicate commands, stale dashboards, and unsafe recovery paths.

State machines are useful when behavior depends on history. A temperature node may accept a calibration command only after it has completed warmup. A lock may accept an unlock command only after it has verified authorization, door position, and local safety state. A Matter or Bluetooth LE pairing flow may allow different events during advertising, credential exchange, verification, and operational modes. Naming those modes lets engineers ask precise questions: which events are valid here, which ones are rejected, and what trace record will explain the decision later?

• States name legal modes such as offline, connecting, online, sampling, buffering, safe off, active, lockout, applying, and rejected.
• Events move the model: timer expired, MQTT connected, packet acknowledged, command received, watchdog warning, battery low, or sensor fault.
• Guards prevent unsafe transitions unless conditions such as authorization valid, battery above threshold, door closed, retry budget remaining, or command sequence accepted are true.

Good state-machine work also separates independent concerns. Connection lifecycle, sampling cycle, actuator safety, and cloud synchronization often deserve separate machines or hierarchical regions rather than one giant list of combined states. That keeps the model reviewable. It also makes the design easier to test: replay an MQTT disconnect, a sensor fault, a stale desired-property update, or a watchdog warning and confirm that the same transition contract appears in the diagram, code, tests, and logs.

The practical value is shared language. Firmware engineers can implement table-driven dispatch in C, Rust, or MicroPython. Backend engineers can model command lifecycles in services and device shadows. QA can write tests for rejected events and timeout paths. Operations can read transition logs when a field unit enters lockout. The diagram is only the start; the real product improvement is making legal behavior and failure behavior explicit enough to review.

11.6 Build The Transition Table First

Before writing firmware branches, write the transition table for one workflow. For a battery sensor, list sleep, wake, sample, transmit, buffer, and error paths, then force every waiting state to show a timeout transition. The table should include source state, event, guard, action, target state, timeout, and the log fields needed for diagnosis. If a row cannot be reviewed by firmware, cloud, QA, and support together, the model is probably still too informal.

Work from a real scenario rather than a generic drawing. For an ESP32 or nRF52 environmental sensor, the sampling cycle might start in SLEEP, wake from an RTC or GPIO interrupt, warm the sensor, read a value, validate range and checksum, publish through MQTT, buffer locally when the network is unavailable, then return to low power. The transition table should say what happens when the sensor never becomes ready, the broker acknowledgement times out, flash storage is full, battery is below threshold, or the device receives an OTA update request mid-cycle.

• Connection: MQTT, WebSocket, BLE, cellular modem, or Matter commissioning states need bounded connect attempts and backoff with jitter.
• Power: ESP-IDF, Zephyr, FreeRTOS, or Arduino firmware should make sleep, wake source, radio-on time, and buffer limits visible.
• Safety: actuator transitions should move toward SAFE_OFF, EMERGENCY_STOP, or LOCKOUT on watchdog, sensor fault, overcurrent, or invalid command events.
• Cloud shadow: AWS IoT Device Shadows, Azure Device Twins, or similar desired/reported models need rejected and stale states, not only synchronized success.

Review the table against risk. A telemetry-only node may safely drop low-value readings after a retention limit, but a medical, industrial, or building-control device may need to preserve records until acknowledged. A valve, pump, or door controller should treat local interlock state as stronger than a cloud command. A gateway that bridges Modbus, BLE, Zigbee, or LoRaWAN into MQTT should not report a cloud command as applied until the downstream device confirms it or the command enters a visible failed state.

Then turn the table into implementation and tests. In Zephyr or FreeRTOS, keep transition logic separate from driver actions so the model can be unit tested without real radios and sensors. In a backend service, store command-state transitions with command id, actor id, device id, previous state, target state, reason, and trace id. In CI, replay representative event sequences: normal sampling, offline buffering, duplicate command retry, invalid event in lockout, stale device-shadow version, and watchdog warning during an actuator action. The goal is not to prove every possible event ordering; it is to make the important transitions boring, observable, and repeatable.

11.7 State Is Data With Time

The implementation must carry enough context to explain a transition later: previous state, event, guard result, target state, action result, timestamp, firmware version, boot reason, command id, sequence number, and correlation id. Without that context, a field failure becomes a guess about which branch ran. With it, the team can reconstruct whether a timeout fired, a guard rejected a command, a retry budget was exhausted, or a stale cloud update arrived after the device had already moved on. Inspect Figure 11.1 to see how those fields attach to a complete device lifecycle rather than one successful transition.

• Timers: use monotonic timers for connection attempts, sensor warmup, acknowledgements, watchdog windows, and lockout cooldowns.
• Persistence: persist only states that must survive reboot; recompute volatile states such as transient network connection after startup.
• Tools: statecharts, SCXML, XState-style models, table-driven dispatch, and property-based tests can keep diagrams, code, and tests aligned.
• Synchronization: device-shadow version, MQTT retained state, OTA rollback slot, and local event log sequence need explicit rules when cloud and device reconnect.

Before applying those implementation rules, inspect Figure 11.1 to see how state and event history span routine operation, recovery, and retirement. The lifecycle makes clear why a record needs more than the current mode.

Read Figure 11.1 from manufacturing and provisioning into the active-state boundary. Within that boundary, follow the sleep, wake, update, and completion events between operating, sleeping, and updating. Then trace fault handling into maintenance, repair back to active operation, and the end-of-life route to decommissioning. This ordering shows why state is data with time: a later reviewer needs the event, prior state, and recorded outcome to distinguish routine activity, recovery, and irreversible retirement.

The dispatch algorithm should prefer deterministic rules over clever branching. Many production systems use a transition table keyed by state and event, with guard functions and action functions attached to each row. The dispatch step finds candidate rows, evaluates guards in a documented order, executes one idempotent action, records the transition, and rejects everything else with a structured log. That pattern works in embedded C, Rust, Python services, TypeScript backends, and test harnesses because the reviewable artifact is the table, not the syntax.

Concurrency is where informal state machines fail. A device may receive a cloud command while it is reconnecting, wake because of a local interrupt while an OTA update is pending, or reboot after writing the action but before writing the final state. The implementation needs atomic update rules for persisted state, sequence checks for command messages, idempotent actions for retry, and a startup policy that decides whether to resume, roll back, or enter a safe state. For cloud shadows and twins, desired and reported versions should be compared explicitly so an old desired property cannot overwrite a newer local decision.

A mature state machine makes normal behavior, rejected events, timeout paths, and recovery paths equally reviewable. It also admits its boundaries. State machines do not replace hardware interlocks, watchdogs, security authorization, or formal safety analysis. They make software behavior explicit enough that those other protections can be checked against it. The deeper engineering habit is to treat every missing transition as a product decision waiting to be made.

11.8 Learning Objectives

By the end of this chapter, you will be able to:

• Choose when a state machine is a better design than scattered flags or nested conditionals.
• Model IoT connection, sampling, actuator-safety, and cloud-shadow workflows as state machines.
• Define transition contracts using states, events, guards, actions, targets, timeouts, and logs.
• Explain why waiting states need timeout and error transitions.
• Review state-machine designs for safety, power behavior, observability, and test coverage.
• Build a table-driven state machine implementation that rejects invalid transitions clearly.

11.9 Prerequisites

• State Machine Fundamentals: Review states, transitions, guards, and events.
• State Machine Lab: Practice implementing simple FSM behavior.
• SOA Resilience Patterns: Connect state-machine transitions to timeouts, retry budgets, fallbacks, and circuit breakers.
• MQTT Fundamentals: Understand connection lifecycle and reconnection behavior.
• WSN Duty Cycling: Review sleep, wake, sample, transmit, and buffer behavior.

11.10 State Machine Pattern Map

Use a state machine when behavior depends on a small set of modes and different events are valid in each mode.

Use Figure 11.2 before choosing a state-machine pattern, because the same transition contract must support four different operating concerns: connection recovery, energy scheduling, actuator safety, and cloud reconciliation. The map turns those concerns into review questions rather than treating a state diagram as an end in itself.

Begin Figure 11.2 at TRANSITION CONTRACT, whose fields include state + event + guard and action + target + timeout + log. Then compare the CONNECT, SAMPLE, ACTUATE, and RECONCILE branches. Each ends at requires reviewed recovery rules, so the map’s message is practical: selecting a pattern identifies which failures and recovery events the implementation must make explicit before the chapter examines individual examples.

11.11 Continue to the Next Part

Carry this evidence into Device State Machines: Transition Contracts, which begins with Transition Contract.