The power symbol printed on almost every device you own is not an abstract pictogram. It is binary. A vertical line is a 1, meaning on. A circle is a 0, meaning off. That is the whole design: the two states of a switch, written in the two digits of the number system the machine runs on.
The convention is codified in IEC 60417, the international standard that defines graphical symbols for use on equipment — the icons stamped into plastic and silkscreened onto panels, meant to be understood without translation. The relevant entries are a small family, and the difference between them is where things get interesting.
Four symbols, not one
- A plain vertical line means power on.
- A plain circle means power off.
- A line inside a broken circle means standby.
- A line inside a closed circle means a push-push on/off toggle — one button that alternates between both states.
The first two belong on a rocker or a rotary switch, where the position of the control tells you which state you are in. The last two exist because modern equipment does not have that kind of switch. A single button cannot sit in a labelled position, so the symbol has to carry the ambiguity instead.
Look at your laptop, your monitor, your router, your TV. The icon is almost certainly a line inside a broken circle. That is the standby symbol. It is not claiming the device turns off. It is telling you, correctly, that pressing it moves the machine into a low-power state that is still a powered state.
Standby is a state, not an absence of one
This is where the trivia turns into engineering. A device in standby is still drawing current. It is holding RAM contents, keeping a real-time clock running, watching an infrared receiver or a network interface for a wake signal, and maintaining whatever the power-management controller needs to bring the rest of the system back up quickly. The reason your TV responds to the remote is that some part of it never stopped listening.
For mains-powered consumer equipment this shows up as standby draw — small per device, real in aggregate, and the reason efficiency regulations put caps on it. For anything running from a battery, it is the entire design problem.
Why this decides IoT battery life
Ask what a connected sensor actually does over a day. It wakes, takes a reading, maybe joins a network, transmits, and goes back to sleep. The active portion might total a few seconds. The other 86,000-odd seconds are spent in whatever "off" you chose — and that choice, not the radio, usually determines how long the battery lasts.
On an ESP32-class microcontroller the difference between sleep modes spans orders of magnitude. Light sleep keeps RAM and peripherals alive and resumes almost instantly, at a cost measured in milliamps. Deep sleep powers down most of the chip and wakes through a timer or an external pin, dropping to microamps, but the application restarts rather than resumes — so any state you care about has to be written somewhere that survives. Getting from a device that lasts a week to one that lasts three years is rarely about a bigger battery. It is about choosing the deepest sleep state the product can tolerate and then engineering around what that state destroys: reconnect time, lost RAM, buffered readings, clock drift.
The same reasoning applies to everything else on the board. A sensor that idles at 200 microamps because nobody added a load switch will quietly outweigh a well-tuned MCU. Quiescent current in the regulator, pull-ups that are always conducting, an LED left on to show the device is alive — these are the items that turn a modelled three-year battery life into a fourteen-month field failure. Measuring average current on real firmware, rather than adding up datasheet numbers, is the only way to know which state your product is actually in.
The design lesson in a symbol
The standby symbol is honest about something product teams often are not: there is usually no true off. Devices with a physical disconnect are increasingly rare, because the features people expect — instant wake, remote power-on, scheduled reporting, over-the-air updates — all require something to stay awake. The engineering question is never "is it off?" but "how little can it draw while still being able to come back?"
If you are specifying a connected product, that question belongs in the requirements document, not in firmware optimisation at the end. What must the device be able to wake for, how quickly, and how often? Answer that and the sleep strategy, the power budget, and the battery size follow. Answer it late and you are recalculating all three after the enclosure is tooled.
We design IoT and embedded systems from silicon to cloud, including the unglamorous power-budget work that decides whether a deployment survives its first year in the field. If you have a connected product in the planning stage or a fleet that is draining faster than the model said it would, tell us what you are building or take a look at how we work.
Top comments (0)