2  The Output Side of IoT

Output Roles, Driver Boundaries, Power Needs, Protection, Control Evidence, and Safety Review

actuators

2.1 Start With the Story

Picture a soil-moisture node that decides a planter needs water. The useful work is not finished when the dashboard says “open valve”; it is finished when a safe driver energizes the valve, the power path survives the load, and the system has evidence that water actually moved.

Read every actuator choice through that loop: command, driver, load, protection, result. A good output design treats the microcontroller pin as a request for action, not as the power source for the action.

Motor Max, the actuation guide

Motor Max

“Sensing decides; actuating commits — and a commit to the physical world needs a safe stop.”

On the module’s front door, Max runs one Motion Check on every output: the action committed, the limits that bound it, and the stop that ends it.

2.2 Overview: Actuators Are The Output Side

Actuators let an IoT system affect the physical world. Sensors report what is happening, software decides what should happen next, and actuators turn that decision into motion, switching, light, sound, heat, or another physical output.

The useful overview question is not “which motor should I buy?” It is “what action must the system perform, how much power does that action need, what driver separates logic from load, what protection is required, and what evidence shows the action is safe and repeatable?”

A simple irrigation valve makes the boundary clear. A controller GPIO may produce a 3.3 V logic signal, but a small solenoid valve might need 12 V at 0.5 A. That load is 12 V x 0.5 A = 6 W, far beyond what a logic pin should supply. The GPIO should drive a transistor or MOSFET gate, the solenoid should draw current from a suitable 12 V supply, and the circuit should include a flyback path so stored coil energy does not strike the switching device when the valve turns off.

A correct actuator driver configuration separates a low-current ESP32 GPIO control signal from the high-current motor power path. External power feeds the motor driver and DC motor, common ground ties the control and driver reference together, and the driver provides flyback protection, current handling, and separate power domains.
Figure 2.1: Correct actuator driver boundary showing an ESP32 sending a low-current GPIO signal to a motor driver while external power supplies the DC motor.

Actuator design starts by separating the logic command from the load current: the controller sends a small signal, while the driver and external supply handle motor power and protection.

The same pattern applies to other output roles. A warning LED may need only a resistor and a few milliamps. A fan may need a MOSFET and a supply that tolerates startup current. A bidirectional motor needs an H-bridge. A stepper needs a current-limited stepper driver. A servo needs a control pulse plus a separate power rail sized for stall or holding current. The software command is only the first part of the output path; the power stage, wiring, load, and observed result complete the action.

Actuator selection also depends on consequence. If a status LED fails, the system may simply lose visibility. If a heater, valve, lock, pump, or moving arm fails, the result can damage equipment or create a hazard. That is why the actuator overview always includes safe state and feedback: what happens when power is lost, communication stops, the controller resets, or the mechanism does not move after being commanded?

If you only need the intuition, this layer is enough: never treat a microcontroller pin as the actuator power source; choose the output role first; use a driver circuit; protect inductive loads; and verify the actuator’s result when safety, position, or process quality matters.

2.2.1 Common Output Roles

  • Motion: DC motors, servo motors, stepper motors, solenoids, pumps, valves, locks, and mechanisms that move or position something.
  • Switching: Relays, solid-state switches, transistors, and contactors that let a low-power controller command a higher-power load.
  • Feedback output: LEDs, displays, buzzers, speakers, and haptic outputs that communicate status to a person or nearby system.
  • Thermal or process action: Heaters, fans, coolers, pumps, valves, and dampers that change an environment or process state.

2.2.2 Beginner Examples

  • A smart thermostat senses room temperature, decides whether cooling is needed, and commands a fan or relay through a driver stage.
  • A soil-moisture controller can open a solenoid valve, but the valve needs a suitable supply, switching device, and flyback protection.
  • A robot arm uses position-oriented actuators because the decision is not only “move” but “move to this angle and hold it.”
  • A warning buzzer or LED is still an actuator because it turns software state into a physical signal.

2.2.3 Overview Knowledge Check

2.3 Practitioner: Build The Actuator Selection Record

A practical actuator review should produce a record that another engineer can inspect before wiring, testing, or release. It should state the required physical action, load, supply, driver, protection, control method, feedback need, duty cycle, fail-safe behavior, and retest trigger.

This record prevents two common mistakes: choosing an actuator from a generic parts list before understanding the action, and proving software behavior while leaving the electrical and mechanical load unverified.

2.3.1 Selection Sequence

  1. Name the physical action. State whether the system needs rotation, linear motion, switching, light, sound, heat, airflow, fluid flow, or positioning.
  2. Describe the load. Record voltage, current, force, torque, speed, travel, duty cycle, inrush behavior, and environment where known.
  3. Choose the driver boundary. Match the load to a MOSFET, H-bridge, relay, motor driver, servo interface, stepper driver, or isolated switch as appropriate.
  4. Add protection and failure behavior. Review flyback paths, fuses, current limits, thermal limits, watchdogs, manual override, and safe state on power loss.
  5. Verify the action. Decide whether open-loop command evidence is enough or whether sensor feedback, position feedback, or process feedback is required.

2.3.2 Selection Ledger

Actuator Role Typical Evidence Driver Or Interface Failure To Review
DC motor Required speed, torque, supply, running current, startup current, duty cycle, and load direction. MOSFET for one direction, H-bridge for reverse, or motor driver with current capability. Stall current, back-EMF, overheating, mechanical jam, and uncontrolled restart.
Servo or stepper Position range, holding force, speed, backlash, load, mechanical stops, and required repeatability. Servo control signal, external servo power, or stepper driver with current setting. Missed steps, overload, brownout, calibration drift, and unsafe motion after reset.
Relay or solenoid Coil supply, load rating, contact type, activation time, duty cycle, isolation, and default state. Transistor or MOSFET driver, relay module, solid-state relay, or protected low-side switch. Flyback spike, contact wear, welded contact, heat, and unsafe energized state.
Visual or audio output User role, visibility or audibility, ambient conditions, current draw, timing, and accessibility. Current-limited GPIO path, LED driver, display bus, buzzer driver, or amplifier. Ambiguous status, overload, inaudible alert, color-only meaning, and stale indication.

2.3.3 Worked Review: Greenhouse Actuator Set

A greenhouse controller may need a fan for cooling, a solenoid valve for irrigation, a light driver for grow lighting, and a lock or latch for access control. The actuator review should not stop at naming those parts. It should record supply voltage, expected current, switching device, flyback protection for inductive loads, duty cycle, enclosure heat, and what safe state is required when the controller restarts or loses network access.

If watering can cause damage, command logging alone is not enough. The design may need a normally closed valve, timeout, flow sensor, leak sensor, or manual shutoff. The required evidence depends on the consequence of an incorrect action.

2.3.4 Practitioner Knowledge Check

2.4 Under The Hood: Power, Protection, And Control Evidence

Under the hood, an actuator path crosses several boundaries: logic signal, driver input, power supply, load current, physical mechanism, and environmental result. Each boundary can fail differently, so actuator design needs electrical and mechanical evidence, not only software tests.

Inductive actuators such as motors, relays, and solenoids are especially important to review because changing current through a coil can create voltage spikes. Protection components, driver ratings, wiring, grounding, heat paths, and enclosure choices all affect whether the controller survives repeated switching.

A coil stores energy in its magnetic field. The approximate stored energy is E = 1/2 x L x I^2. If a relay coil has 20 mH inductance and carries 0.5 A, the stored energy is 0.5 x 0.020 x 0.5^2 = 0.0025 J. That sounds small, but when the switch opens the coil tries to keep current flowing. Without a flyback diode, TVS, snubber, or other safe path, the voltage can rise high enough to damage a transistor or reset nearby electronics. Protection is not an optional accessory; it is part of the actuator power path.

Phoebe the physics guide

Phoebe’s Why

The 0.0025 J stored in that coil is not the danger – how fast it is forced to leave is. When a switch opens, it tries to make current stop in an instant, but an inductor resists any change in its own current, so it fights back with whatever voltage it takes to keep the current flowing somewhere. Cut the fall time short enough and that voltage becomes huge, which is exactly why an unprotected coil can arc across a switch or punch through a transistor junction. A flyback diode fixes this the same way a semiconductor junction always fixes an over-voltage: it turns on at a fixed, small forward drop and gives the current a path to decay through the coil’s own resistance instead of through open air. That same fast, unclamped edge is also a radio problem – a voltage that rises in nanoseconds is rich in high-frequency content, which is exactly the kind of noise layout guides warn about keeping away from a nearby 2.4 GHz radio.

The Derivation

Ohm’s law gives the coil’s own DC resistance from its rated operating point:

\[R_{coil} = \frac{V_{supply}}{I}\]

An unclamped coil’s voltage spike from forcing current to stop in time \(t_{off}\):

\[V_{spike} = L\,\frac{dI}{dt} \approx L\,\frac{I}{t_{off}}\]

With a flyback diode added, the loop becomes a simple decaying-current circuit – the inductive analogue of an RC time constant, with \(L/R\) in place of \(RC\):

\[I(t) = I_0\,e^{-t/\tau}, \qquad \tau = \frac{L}{R_{coil}}\]

That same time constant sets a natural corner frequency for the decay, using the identical \(1/(2\pi\times\text{time constant})\) relationship that defines any RC or RL filter’s roll-off:

\[f_c = \frac{1}{2\pi\tau} = \frac{R_{coil}}{2\pi L}\]

Worked Numbers: This Chapter’s 20 mH Relay Coil

Using the chapter’s own 20 mH, 0.5 A relay coil on its established 12 V actuator supply:

  • Coil resistance (Ohm’s law): \(R_{coil} = 12/0.5 = 24.0\ \Omega\)
  • With a flyback diode, decay time constant: \(\tau = 0.020/24.0 = 8.33\times10^{-4}\) s \(= 0.833\) ms
  • Corner frequency of that decay: \(f_c = 1/(2\pi\times8.33\times10^{-4}) = 191\) Hz
  • Without protection, using a standard/typical 100 ns MOSFET turn-off time: \(dI/dt = 0.5/(100\times10^{-9}) = 5.00\times10^{6}\) A/s, so \(V_{spike} = 0.020\times5.00\times10^{6} = 100{,}000\) V (unclamped, ideal) – far beyond any silicon rating, which is exactly why this chapter treats flyback protection as mandatory rather than optional

That same ~100 ns edge has a spectral knee near \(f_{knee}=0.35/t_{rise}=0.35/(100\times10^{-9})=3.50\times10^{6}\) Hz \(=3.50\) MHz, with harmonics extending well up into the range shared by a 2.4 GHz radio’s front end. Clamping the edge with a diode, or slowing it further with an RC snubber, raises \(\tau\) and lowers both the corner frequency and the radiated-noise knee – the same fix protects the transistor and keeps the switching transient out of the radio.

Motors add another hidden case: startup and stall current. A 12 V DC motor with 2 ohms of winding resistance can draw 12 V / 2 ohms = 6 A at stall before back-EMF builds. Once spinning, if back-EMF rises to 9 V, the winding current falls to (12 V - 9 V) / 2 ohms = 1.5 A. A supply and driver sized only for the running current may brown out during startup or overheat during a jam. This is why actuator reviews record startup current, stall or inrush behavior, duty cycle, and thermal limits instead of only nominal voltage.

Max’s Motion Check

  • Commit: spin a 12 V motor through 2-ohm windings.
  • Limits: stall draws 12/2 = 6 A until back-EMF builds; at 9 V back-EMF, running current falls to 1.5 A.
  • Safe stop: current sensing catches a jam held at stall current; critical outputs need a defined fallback state.

Control evidence closes the loop. A pump command may be verified by current draw, flow rate, pressure change, or tank-level change. A lock may be verified by a limit switch. A stepper may need homing because missed steps are otherwise invisible. The right evidence depends on the consequence of being wrong. Low-consequence outputs may rely on command logging; safety or process-critical outputs need independent confirmation and a defined fallback state.

2.4.1 Internal Responsibilities

  • Logic boundary: The microcontroller output should command a driver input, not carry the actuator’s load current.
  • Power path: The supply, wiring, driver, connector, fuse, and return path must match expected current, startup behavior, and environment.
  • Protection path: Flyback paths, snubbers, current limits, thermal design, isolation, and emergency stops reduce damage from normal and abnormal switching.
  • Action proof: Feedback sensors, limit switches, current sensing, flow sensing, timing checks, or process measurements prove whether the action happened.

Max’s Motion Check

  • Commit: run the pump — prove water moved by current draw, flow rate, pressure, or tank level.
  • Limits: command logging suits only low-consequence outputs; missed stepper steps stay invisible without homing.
  • Safe stop: verify the lock with a limit switch; give every critical output a defined fallback state.

2.4.2 Failure Modes To Review

  • Overcurrent: startup, stall, jam, or short-circuit current can exceed the driver or supply rating.
  • Back-EMF: inductive loads can damage switching devices if the energy has no safe path.
  • Brownout: actuator startup can pull down the supply and reset the controller.
  • Unsafe default state: a relay, valve, motor, heater, or lock may energize or remain active during reset or communication loss.
  • Unverified action: software may command motion even when the mechanism is stuck, disconnected, miswired, or overloaded.

2.4.3 Retest Signals

Retest the actuator path when the load changes, the supply changes, the driver changes, wiring length changes, enclosure temperature changes, duty cycle changes, firmware changes startup behavior, a safety requirement changes, or field evidence shows missed motion, overheating, resets, or unexplained state changes.

2.4.4 Under-The-Hood Knowledge Check

2.5 Summary

Actuators are the physical output side of IoT systems. They complete the sense-decide-act loop by converting controller decisions into motion, switching, light, sound, heat, flow, or other physical effects. A useful actuator design starts with the required action, then records load evidence, driver boundary, supply sizing, protection, control method, feedback need, safe state, and retest triggers.

The safest designs do not treat software commands as proof of physical action. They verify that the actuator can be powered, switched, protected, and observed in the context where it will operate.

2.6 Key Takeaway

Choose actuators from the physical action and failure consequence, then prove the driver, power, protection, feedback, and safe-state behavior before trusting the output.

2.7 See Also