Putting WiFi on a device is a power decision before it is a connectivity one. A WiFi link draws in steady use roughly what a low power radio spends across a whole duty cycle, so choosing between them tends to settle the power source first and the protocol second.

The pull toward WiFi is easy to feel. It reaches the internet without a gateway of its own, it carries enough bandwidth for a camera or a quick firmware push, and it lands on a network that is already in nearly every building. The cost shows up on the battery and in the heat, and a design that wants long life and WiFi together usually ends up rationing the radio's on-time or giving up and plugging the product into a wall.

The power gap WiFi opens

A low power radio and a WiFi radio are not two points on one scale, they sit in different power classes. A low power node idles at a microamp or two between brief events and pulses to perhaps ten milliamps when it transmits. A WiFi radio measures its appetite in tens to hundreds of milliamps while the link is up, draws the high end of that during a transmit burst, and even an associated but idle station can sit in the tens of milliamps if it holds the link awake. That gap is the heart of deciding between WiFi and a low power radio, and the power source settles it far more than the data the device has to move.

Walk through what a WiFi exchange costs in practice and the gap stops being abstract. Bringing a radio up from cold means scanning for the access point, running the association and authentication handshake, and pulling an address over DHCP, a sequence that keeps the radio awake for a stretch measured in hundreds of milliseconds to a second or two, all of it at the high transmit and receive currents. Once joined, the device either holds the link open or drops it and pays that cold-join cost again on the next wake. Holding it open is where WiFi power-save modes come in: a station can tell the access point it is going to sleep and then wake only on the DTIM beacon, every hundred milliseconds or so, to check whether traffic is waiting, which cuts the average current sharply but never to the level a low power node reaches, because the radio still has to wake on that beacon schedule and the link state has to be kept alive. A full IP stack rides on top, with its own memory and the timers that hold TCP connections and keepalives, so the processor cannot sleep as deeply or as long as a low power part can between its own beacons. None of this is wasteful engineering, it is the price of speaking the same protocol as a laptop, and it sets a floor on average current that no clever firmware drops below. A coin cell holding a couple of hundred milliamp hours cannot feed that floor for long, which is the real reason WiFi devices tend to run from a wall adapter, a sizeable rechargeable pack, or a primary cell sized for a short service life. The designs that do put WiFi on a battery survive by sending rarely and sleeping hard between sends, accepting the cold-join energy each time as the cost of not holding the link, and even then the battery is large or the reporting interval is long. The 2.4 GHz band that these radios share with every other WiFi and Bluetooth device nearby brings retries when the air is busy, and each retry spends more transmit energy, so an honest budget carries a margin for a congested band rather than the clean-air figure a datasheet quotes, a margin easy to leave out and painful to find in a building full of access points.

The reconnect math is where many WiFi battery designs are won or lost. If a cold join burns a few hundred millijoules and the device reports once a minute, the join energy alone can dwarf the energy of the data it carries, so the lever that matters is how often the radio has to come up rather than how much it sends when it does. Stretching the interval helps in the same way it does for any radio, and WiFi punishes a short interval harder because its fixed per-join cost is so much larger. A design that has to report every few seconds is usually better off holding the link in power-save than re-joining each time, while one that reports every few minutes comes out ahead by dropping the link and eating the join, and the crossover between those two is a real calculation, not a guess.

Heat is the quieter consequence. A radio pulling a few hundred milliamps in bursts warms the board and leans on the regulator feeding it, so a WiFi design needs a supply that can deliver those current spikes without sagging the rail, and a thermal path that a sealed enclosure does not choke. A brownout on a transmit peak shows up as a dropped connection that is maddening to trace, since it only happens under load, so the decoupling and the regulator headroom around a WiFi part get sized for the peak and not the average. These are concerns a low power node never raises, and they are part of what the WiFi choice quietly buys.

When WiFi is the right answer anyway

None of that rules WiFi out, it just names the bill. A device that has mains power, or that has to stream video, carry real bandwidth, or reach a cloud service without anyone installing a hub, often wants WiFi despite the current, and for those the question turns from whether to use it to how to fit it. A smart plug, a doorbell camera, and a countertop appliance all sit in this group, plugged in or charged often enough that the radio's appetite stops driving the design, and close enough to a router that the link is dependable. Even a battery product can land here if it reports rarely enough, a door sensor that sends a packet a few times a day and sleeps the rest can run on WiFi for a year on a decent pack, because the duty cycle is so low that the floor never gets a chance to drain it. The decision is less about the protocol's reputation than about matching its real duty cycle to the energy the product can carry.

The integrated route, WiFi in the SoC

The common way to add WiFi now is a system on chip that folds the radio, the stack, and an application processor into one part. The ESP32 pairs WiFi and Bluetooth on a single host, with a dual-core processor that has the headroom to run the application and the network stack together, which is why it shows up across consumer connected products that want both radios and a low part count. It carries enough flash and RAM for a real application, drives displays and sensors from its own peripherals, and its wide adoption means a deep pool of example code and a forgiving supply that a smaller vendor cannot match.

The line has since split by cost and by radio. The ESP32-C3 moves the same idea onto a single RISC V core at a lower price, which suits a simple WiFi node that needs the connectivity and a modest application without the dual-core compute the original part offered, and it keeps pin and software compatibility close enough to ease a cost-down. The ESP32-C6 brings WiFi 6 and an 802.15.4 radio for Thread into one part, aimed at a device that has to sit on a modern WiFi network and join a low power mesh at the same time, which is the shape Matter pushes designs toward, since a product can be commissioned over one radio and run its working traffic over the other. The newer parts trade up in radio and down in price against the original, each landing on a different point of the same curve.

The older part still has a place. The ESP8266EX remains a low cost way to put a device on WiFi when a design needs nothing more than a basic connected link and a known module footprint, and the bill of materials is the thing under pressure. It runs a single core with tight memory and no second radio, so it fits the narrow job rather than the flexible one, and a lot of simple connected gadgets ship on it precisely because it does that one thing for a price the newer parts do not chase.

A pattern runs through the family. The integrated SoC wins when WiFi is central to the product and the design can be built around it, trading the lowest possible standby current for a single part that does everything. Where the radio is an addition to a device that already has its own processor and its own low power needs, the calculus changes.

That is the split to keep in view.

Adding WiFi to an MCU you already have

Plenty of products already have the right microcontroller for the job and only need to put it on WiFi without handing the whole design over to a wireless SoC. The answer there is a WiFi coprocessor, a part that carries the radio and the network stack and talks to the host over SPI, leaving the application on the processor the team already chose. The ATWINC1500 adds WiFi to an MCU this way, running the TCP/IP stack on its own silicon so a modest host can get online without growing into a full applications processor, which keeps the certified module, the antenna, and the radio firmware as a known block the team does not have to build.

Power pulls this category too. The WF200 reaches for low power WiFi connectivity, trimming the current the radio draws across its various states so a battery or harvested design has a fighting chance of using WiFi at all, within the limits the protocol sets. It still cannot match a low power radio on a coin cell, and the same floor applies, but it narrows the gap enough to matter for a device that has to speak WiFi and stretch a battery at once, and it lets a host MCU that was chosen for low power keep that character instead of being replaced by a thirstier integrated part.

The coprocessor route keeps a design's existing investment intact, at the cost of two chips where the integrated part used one, and a link between them to manage. Which way a product goes comes back to where WiFi sits in it, central enough to build around, or an addition to a device whose heart is already chosen.