3  How Actuators Work

3.1 Start With the Story

Start with a room that is too hot. A sensor reports the temperature, software decides to cool, and then a fan, vent, relay, or valve has to make the physical change. The actuator chapter begins at that handoff from decision to action.

The beginner move is to keep the roles separate: software asks, the driver switches power, the actuator moves or signals, and feedback tells you whether the world changed. That simple split prevents many unsafe GPIO-to-load mistakes.

3.2 In 60 Seconds

Actuators are the output devices of IoT systems. Sensors measure the world, software decides what should happen, and actuators make a physical change such as motion, switching, light, sound, airflow, heat, or fluid movement.

The central beginner rule is simple: a microcontroller pin can command an actuator, but it usually cannot power the actuator directly. Use a driver circuit, a suitable power supply, and protection for inductive loads before trusting the physical action.

3.3 Overview: Actuators Close The Sense-Decide-Act Loop

An IoT system becomes useful when it can connect sensing to action. A temperature sensor can report that a room is too hot, but the fan motor, relay, vent, or valve is what changes the environment. That physical-output side is the actuator layer.

Actuators include motors, servos, steppers, relays, solenoids, valves, pumps, heaters, LEDs, displays, buzzers, and speakers. They differ in motion, power, precision, response time, and safety consequence, but the review question is always the same: what physical action is required, and what evidence proves it happened safely?

Make the loop concrete. In a greenhouse, the sensor may report 35 C, the controller may target 28 C, and the actuator path may run a 12 V, 0.5 A fan. The running electrical load is 12 x 0.5 = 6 W, but the startup current may be several times higher, so the fan cannot be treated as a GPIO accessory. The actuator design must include the driver, supply margin, wiring, protection, and a way to see that temperature or airflow actually changed.

Figure 3.1: A useful actuator path closes the loop: sense the condition, decide on the command, drive the physical output, and use feedback when the result matters.

An irrigation valve shows the same pattern with a different output. If a normally closed solenoid draws 0.4 A at 12 V, it dissipates 12 x 0.4 = 4.8 W while energized. A short watering pulse may be fine, but holding it open indefinitely changes the heat and battery budget. The control decision is only useful if the valve driver can energize the coil, the flyback path protects the electronics, and a flow, pressure, current, or timeout rule catches a stuck valve.

The key beginner move is to name the boundary. Software owns the decision; the driver circuit owns power switching; the actuator owns the physical output; and feedback proves the result. Confusing those roles is how simple IoT projects end up with reset loops, overheated coils, jammed motors, or dashboards that claim success while nothing moved.

If you only need the intuition, remember this: sensors notice, controllers decide, actuators act, and feedback proves whether the action worked.

3.3.1 Output Families

• Motion: DC motors, servo motors, stepper motors, pumps, valves, locks, dampers, and solenoids move or position something.
• Switching: Relays, contactors, MOSFETs, and solid-state switches let low-power logic command higher-power loads.
• Human Feedback: LEDs, displays, buzzers, speakers, and haptic outputs turn system state into visible, audible, or tactile signals.
• Process Change: Heaters, fans, coolers, pumps, and valves change temperature, airflow, fluid flow, pressure, or another process state.

3.3.2 Beginner Examples

• A greenhouse controller senses high temperature, decides to cool, and commands a fan motor.
• A smart irrigation system senses dry soil, decides to water, and opens a normally closed solenoid valve.
• A robot arm receives a target angle, decides a motion path, and commands a servo or stepper through a driver.
• A safety monitor detects a fault and commands a buzzer, warning LED, relay cutoff, or all three.

3.4 Practitioner: Put A Driver Between Logic And Load

The first practical actuator design step is to separate the logic signal from the load current. GPIO pins are designed for small digital signals. Motors, relays, solenoids, heaters, lamps, and pumps often need more current, different voltage, inductive-load protection, or isolation.

A driver boundary lets the microcontroller command a power stage safely. The correct driver depends on the load: a MOSFET for a one-direction DC load, an H-bridge for a reversible motor, a relay or solid-state relay for switched loads, a servo signal with separate power, or a stepper driver with a current setting.

3.4.1 Wiring Review Workflow

1. Name the load. Record actuator type, voltage, running current, startup or inrush current, duty cycle, and environment.
2. Choose the driver. Match the load to a MOSFET, H-bridge, relay module, solenoid driver, servo supply, or stepper driver.
3. Protect the controller. Add flyback paths, current limits, fuses, isolation, heat paths, and shared-ground rules as appropriate.
4. Define safe defaults. Decide what happens on boot, reset, power loss, network loss, watchdog timeout, and emergency stop.
5. Prove the action. Decide whether command logging is enough or whether feedback from position, current, flow, pressure, speed, or process state is required.

3.4.2 Actuator Driver Boundary Review Ledger

Actuator Case	Why GPIO Alone Is Not Enough	Typical Interface	Evidence To Keep
DC motor or fan	Startup and stall current can exceed logic-pin limits, and the motor is an inductive moving load.	MOSFET for one direction, H-bridge for reverse, rated motor driver for higher current.	Supply voltage, startup current, driver rating, PWM rule, protection, and motion or process feedback.
Servo or stepper	Positioned motion needs a separate power path, current margin, and mechanical-limit review.	Servo control signal plus external power, or a current-limited stepper driver.	Target range, load, calibration, current setting, missed-step or overload behavior, and safe reset state.
Relay or solenoid	Coils require more current than GPIO and create voltage spikes when switched off.	Transistor or MOSFET driver with flyback diode, protected relay module, or solid-state switch.	Coil rating, contact or valve rating, flyback path, duty cycle, default state, and timeout behavior.
LED strip or buzzer	Large output arrays or audio devices may exceed pin current and need timing, current, or accessibility review.	Current-limited output, LED driver, MOSFET switch, buzzer driver, or amplifier.	Current limit, visibility or audibility, color or tone meaning, failure state, and user confirmation.

3.4.3 Starter Review Record

Physical action:
Actuator type:
Load voltage and current:
Driver or interface:
Protection:
Safe default:
Feedback evidence:
Retest trigger:

3.5 Under The Hood: Action Needs Feedback And Safe Failure

Under the hood, an actuator command crosses electrical, mechanical, and process boundaries. The software may set a PWM duty cycle, relay output, or step command, but the actual result depends on supply voltage, driver rating, wiring, load, friction, heating, timing, and physical limits.

That is why actuator systems often need feedback. Feedback can come from a sensor that measures the process, an encoder that measures motion, a limit switch that confirms position, current sensing that detects stall, flow sensing that confirms water movement, or a timeout that forces a safe state when proof does not arrive.

Each boundary has a failure mode that can be tested. On the electrical side, a motor that draws 2 A at startup through 0.3 ohm of wiring and connector resistance can lose about 2 x 0.3 = 0.6 V before the driver even sees the load. That voltage drop may be enough to reset a marginal controller supply. On the mechanical side, a motor may spin freely on the bench but stall once connected to a sticky linkage. On the process side, a pump may rotate while a blocked tube prevents flow.

Phoebe’s Field Notes: Why Wiring Resistance Is A Voltage Divider

Phoebe’s Why

The wiring resistance above the load and the load itself carry exactly the same current, so the supply voltage splits between them the way it splits across any two resistors in series – an ordinary voltage divider, just one where the “top” resistor happens to be a length of copper instead of a component on the schematic. Ohm’s law over that shared current is what predicts the 0.6 V loss. If a reviewer wants software to catch that sag before it resets a marginal supply, an ADC has to sample the rail with a fine enough quantization step to resolve it, and fast enough to actually land a sample inside the brief startup transient – two separate digital limits that a purely analog voltage-divider calculation does not reveal.

The Derivation

Wiring resistance and load resistance share the same current, so the supply splits as a divider:

\[V_{wire} = V_{supply}\times\frac{R_{wire}}{R_{wire}+R_{load}} = I\,R_{wire}\]

An ADC’s quantization step sets the smallest voltage change it can resolve:

\[q = \frac{V_{ref}}{2^N}\]

To guarantee at least one sample lands inside a transient of duration \(\tau_{pulse}\), the sampling period must be shorter than the pulse itself:

\[T_s < \tau_{pulse} \quad\Longleftrightarrow\quad f_s > \frac{1}{\tau_{pulse}}\]

Worked Numbers: This Chapter’s 2 A Startup Sag

Using the chapter’s own figures, \(I=2\) A through \(R_{wire}=0.3\ \Omega\) gives the stated \(V_{wire}=0.6\) V. Check whether a standard 12-bit ADC on a 3.3 V reference can see it:

• Quantization step: \(q = 3.3/4096 = 0.000806\) V \(= 0.806\) mV
• The 0.6 V sag spans \(0.6/0.000806 = 745\) ADC codes – quantization is not the limiting factor here

The limiting factor is timing, not resolution. A motor startup surge typically settles within about 1 ms (a standard/typical value, since the chapter names no duration). Guaranteeing a sample inside that window needs \(f_s > 1/0.001 = 1000\) Hz. A control loop sampling at a common 100 Hz rate has \(T_s=10\) ms, which is longer than the 1 ms transient, so a periodic sample at an arbitrary phase is not guaranteed to land inside the sag at all – the startup fault can be real and still invisible in the logged reading.

Safe failure means the system has a planned response for those cases. A fan might stop and log a fault after current stays above its startup band for too long. A solenoid might be limited to a 5 s energize window unless flow is detected. A servo-driven vent might require a limit switch, end-position current signature, or temperature trend before the dashboard claims the vent opened. The evidence should match the consequence: a status LED can be open loop, but water, heat, access control, and moving machinery need stronger proof.

Actuator acceptance should therefore test more than the happy path. Include boot defaults, brownout recovery, power loss, stuck load, repeated cycling, feedback loss, and manual override where they matter. The goal is not to make every actuator complicated; it is to make the proof and protection proportional to the physical risk.

3.5.1 Feedback And Safety Loops

• Open Loop: The controller sends a command and assumes the action occurred. This can be acceptable for low-consequence indicators or simple outputs.
• Closed Loop: The controller measures the result and adjusts or stops the actuator based on feedback from the mechanism or process.
• Protection Loop: Flyback diodes, snubbers, fuses, current limits, thermal limits, watchdogs, and emergency stops protect during normal and fault conditions.
• Fail-Safe State: The design should define what the actuator does when power, firmware, communication, feedback, or the physical load fails.

3.5.2 Failure Modes To Surface Early

• Stall or jam: a motor is commanded on but cannot move, causing high current and heat.
• Inductive kick: a relay, solenoid, or motor coil creates a damaging voltage spike when switched off.
• Brownout: actuator startup current pulls the supply down and resets the controller.
• Unsafe default: an output turns on during boot, reset, or network loss when it should remain off.
• No action proof: software reports success because it sent a command, but the physical mechanism did not move.

3.5.3 Acceptance Evidence

Acceptance evidence should include normal command, startup, shutdown, reset, power-loss, blocked-load, repeated-use, and recovery cases where relevant. For low-risk indicators, visual or audible confirmation may be enough. For water, heat, motion, access control, or safety-related outputs, the evidence should include protective behavior and proof that the physical result matched the command.

3.6 See Also

• Actuators Overview for the broader output-role and selection doctrine.
• Actuator Types and Comparison for choosing between common actuator families.
• DC Motors for continuous-motion motor driver and feedback details.
• PWM Control for Actuators for duty cycle, frequency, servo pulses, and soft-start behavior.

3.7 Key Takeaway

Actuators turn IoT decisions into physical change, so every design needs the right driver boundary, protection, safe default, and feedback evidence for the consequence of the action.