Daniel's back on the smart home thread, and this time he's asking why Wi-Fi IoT feels like the one neighborhood where you have to break into your own house. He points out that Zigbee and Matter have open ecosystems you can just walk into, but Wi-Fi devices ship locked to vendor clouds by default. His assumption used to be that Wi-Fi had no real future in IoT because it's not optimized for the traffic and it's congested. But then he lands on the one thing Wi-Fi does that nothing else in the low-power world can touch: throughput. You're not streaming video over Zigbee. And for renters, or old buildings, or anywhere wired ethernet is a nonstarter, Wi-Fi is sometimes the only option. So he wants the landscape. What are the use cases where Wi-Fi naturally fits, and what actually exists beyond WLED if you want vendor-lock-in-free options for other classes of devices?
The video point is the one that reframes the whole thing. Zigbee tops out around two hundred fifty kilobits per second. That's enough for a temperature reading and a firmware update if you're patient. It is not enough for a security camera. So the moment you need real data movement, you're either running ethernet or you're on Wi-Fi. And for a huge number of people, ethernet isn't on the table.
Daniel's phrase was narrow phylum. I like that. It's not the whole IoT world, but it's a real branch.
It's the branch that everyone pretends doesn't exist until they need a camera in a rental apartment. Then suddenly Wi-Fi is the only thing that works and they're stuck with whatever the vendor's cloud will allow.
So before we get into the liberation tooling, let's set the actual scope. When we say Wi-Fi-native IoT, we're talking about devices that connect directly to a Wi-Fi network. No hub, no coordinator, no Zigbee dongle hanging off a Raspberry Pi. The device is its own client on your router.
Right. And the central tension is that Wi-Fi was never designed for this. It's high throughput, high power draw, and it lives in the most crowded spectrum in your house. Zigbee and Thread were built from the ground up for low-power, low-bandwidth sensor traffic. Wi-Fi was built to move a lot of data to a laptop. So using it for a smart plug is like using a freight train to deliver a postcard.
But the freight train is already in every house. That's the economic argument. You don't need a hub, you don't need a coordinator, you just need the router you already own. For a manufacturer, that's one less thing to support and one less thing for the customer to complain about.
And one more thing you can point to as a feature. Plug it in, scan a QR code, it's on your network and talking to your phone in ninety seconds. That onboarding experience is the entire reason Tuya owns the low end of this market. The chips are cheap, the reference designs are everywhere, and the cloud platform handles all the hard parts. Firmware, app, remote access, voice assistant integration. A company can slap their logo on a Tuya module and have a product shipping in a quarter.
And that's the lock-in, right there. The hardware is just an ESP8266 or a Realtek chip, but the firmware is welded to Tuya's cloud. The device won't do anything without phoning home.
That's the part most coverage gets wrong. People think the lock-in is the hardware. It's not. The hardware is a five dollar microcontroller. The lock-in is the software and the cloud account. Zigbee is standardized at the protocol level, so a Zigbee2MQTT gateway can talk to almost any Zigbee device regardless of who made it. The radio speaks a common language. Wi-Fi devices don't have that common language. They have a proprietary protocol wrapped in TLS, talking to a vendor's server.
So the open-source community had a much easier job with Zigbee. Build one gateway, and it speaks to everything. With Wi-Fi, every vendor is a separate decryption project.
And that's why the liberation tooling for Wi-Fi is so different in shape. It's not a gateway. It's firmware replacement. You're not translating the device's language. You're ripping out its entire brain and installing a new one.
Which brings us to the actual toolchain. Let's talk about what exists, because Daniel asked for specific options beyond WLED.
WLED is the poster child because it does one thing beautifully. You flash an ESP8266 or ESP32, and you get local control of LED strips over MQTT, HTTP, or straight into Home Assistant. No cloud, no account, no phoning home. And it's mature enough that people build commercial products on it.
But WLED is just the lighting niche. For general purpose devices, the two big names are Tasmota and ESPHome.
Tasmota is the one that most people hit first. It's a firmware replacement that runs on ESP-based devices, and it's been around long enough that it supports a absurd list of hardware. Smart plugs, switches, relays, power monitoring, temperature sensors, IR blasters. You flash it, configure it over a local web page, and it talks MQTT to whatever home automation system you run. The cloud is gone.
And ESPHome is the other flavor. It's built around a YAML configuration file. You describe what the device is and what it should do, and it compiles firmware for you. It's deeply integrated with Home Assistant, and it's the one I'd recommend to someone who wants to build their own devices rather than liberate existing ones.
ESPHome is also the one that's easiest to maintain. You change the config, it recompiles, you push it over the air, done. No soldering, no serial programmer once you've got the first flash done. It's a pleasant workflow.
But both of those assume you have an ESP-based device. And here's the problem Daniel's really pointing at. Tuya has been shipping Realtek chips in a lot of their newer stuff.
That's where LibreTiny comes in. It's a port of the Arduino framework for those Realtek chips, which means you can write custom firmware for hardware that used to be a dead end. And Cloudcutter is the tool that gets you in. It exploits a vulnerability in the Tuya firmware update process to push your own firmware over the network. No opening the device, no soldering, no serial programmer.
That's the one that feels like a magic trick. You point it at a Tuya device on your network, it does its thing, and suddenly the device is running your code.
The catch is that it only works on specific Tuya devices with specific Realtek chips. The list is long but not universal. And Tuya patches the vulnerability in newer firmware, so you're always chasing the last version that was still vulnerable. It's a cat and mouse game.
The soldering route is the fallback. A lot of these devices have exposed serial pads on the board. You connect a USB to serial adapter, flash Tasmota or LibreTiny directly, and you're done. But that's not a beginner move.
I've done it enough times to say it's not fun. You're holding a soldering iron over a fifteen dollar smart plug, hoping you don't lift a pad. And sometimes you do. Then you've got a brick.
I want to sit with the economics of that for a second. A fifteen dollar Tuya smart plug. You buy it, you spend an evening flashing it, you might brick it, and if it works you've got a local smart plug. Or you buy a Zigbee plug for eighteen dollars and it just works locally out of the box.
And that's the honest answer to why Wi-Fi IoT is dominated by vendor lock-in. The open path exists, but it's a hobby. The Zigbee open path is a product category. Zigbee2MQTT is mature enough that a non-technical person can set it up in an afternoon. Flashing Tasmota onto a random Tuya device is still a project.
So the open-source Wi-Fi landscape is real, but it's a tinkerer's landscape. The barrier to entry is higher, and the failure mode is a bricked device sitting in a drawer.
Which is fine if that's your hobby. Daniel flashes ESP32s for fun. But it's not a mass market answer.
Let's talk about where Wi-Fi actually earns its place, because Daniel asked for the use cases where it naturally fits. Cameras are the obvious one.
Cameras are the whole argument. A Zigbee security camera doesn't exist because the protocol can't carry the data. Two hundred fifty kilobits per second gets you a terrible still image if you're lucky. Wi-Fi gives you tens to hundreds of megabits per second. You can stream full HD or four K video without thinking about it.
And that's why the open-source camera ecosystem is interesting. Frigate is the big name now. It's an open-source network video recorder with AI object detection. You point it at your Wi-Fi cameras, it records locally, and it uses a local AI model to figure out whether that thing in the driveway is a person or a raccoon.
Frigate is the answer to the cloud camera problem. You buy a cheap Wi-Fi camera that supports a standard stream, usually RTSP, and you run Frigate on a machine in your house. The camera streams to Frigate, Frigate does the detection, and nothing leaves your network. No subscription, no cloud storage, no company watching your driveway.
The catch is that a lot of cheap Wi-Fi cameras don't expose RTSP. They want you to use their app and their cloud. So you're back to the same lock-in problem.
Right. The camera that works with Frigate is the camera that lets you set a custom stream URL. Some vendors do, some don't. And that's the filter. You shop for cameras based on whether they'll give you the stream.
The other natural Wi-Fi use case is the renter. Daniel mentioned this. If you can't run ethernet and you can't install a hub anywhere permanent, Wi-Fi is what you've got.
And it's not just renters. Historic buildings, brick walls, listed properties where you can't drill. Anywhere the building itself resists new wiring, Wi-Fi is the path of least resistance. You don't need to run a single cable to get a smart device online.
The hub point is underrated. Zigbee needs a coordinator. Matter over Thread needs a border router. Wi-Fi needs nothing. Your router is already the hub.
For a renter, that's the difference between a smart home and no smart home. You can't rewire a rental. You can't drill through the landlord's walls. But you can plug in a Wi-Fi smart plug and have it working in five minutes.
And if that smart plug is running ESPHome or Tasmota, you've got local control without any permanent modification. You unplug it when you move, and the apartment is exactly as you found it.
The dark side of that is e-waste. If a renter buys a cloud-dependent Wi-Fi device and the vendor shuts down the cloud, the device is a brick. There's no local fallback. The renter throws it away and buys another one.
Local control is the insurance policy. If the cloud dies, the device still works. That's the argument for flashing firmware even if you don't care about privacy.
And that's the knock-on effect Daniel's really getting at. The open-source Wi-Fi movement isn't just about privacy. It's about ownership. You bought the device. It should keep working until the hardware fails, not until the vendor's server bill gets too high.
Let's shift to the industrial side, because Daniel asked about that too.
Industrial Wi-Fi IoT is a different beast. In a factory, you're not flashing Tasmota onto a smart plug. You're deploying sensors and controllers that need to survive interference, roaming between access points, and uptime requirements that make consumer gear look like toys.
But the same economic logic applies. Running ethernet in an old factory is expensive. Every new sensor needs a cable run, a conduit, a switch port. Wi-Fi lets you bolt a sensor to a machine and move on.
And the throughput matters there too. Industrial cameras, vibration sensors that sample at high rates, anything doing real data collection over Wi-Fi. Zigbee would choke on that.
The open-source angle in industrial is mostly ESP32-based prototyping. Companies use ESPHome or custom Arduino firmware to build proof of concepts cheaply. The ESP32 is five dollars, it has Wi-Fi and Bluetooth, and you can prototype a sensor node in a day.
The gap is scaling that prototype to industrial grade. Consumer Wi-Fi chips don't have the certifications, the temperature ratings, the reliability guarantees that industrial buyers demand. So you prototype on ESP32 and then you either build custom hardware or you buy from a vendor who's done the certification work.
And that's where the industrial lock-in creeps back in. The big industrial Wi-Fi vendors use proprietary protocols for reliability and security. They have their own management platforms, their own clouds, their own everything.
The difference is that industrial buyers are paying for that lock-in. It comes with a service level agreement and a support contract. The consumer lock-in is just you being the product.
Let's talk about Matter over Wi-Fi, because that's the thing people point to as the future.
Matter is the industry's attempt to do for smart home what USB did for peripherals. One standard, everything interoperates. And it supports Wi-Fi as a transport. So in theory, you could have a Matter over Wi-Fi device that works locally with any Matter controller, no vendor cloud required.
The theory is nice. The practice has been slow.
Adoption has been disappointing. Matter devices are shipping, but the ecosystem is fragmented. Every vendor implements the standard slightly differently, and the certification process doesn't catch everything. There are Matter devices that work with one controller but not another. That's not interoperability, that's a suggestion.
And Matter over Wi-Fi still has the same power problem. Wi-Fi is power hungry. A Matter over Wi-Fi battery sensor is going to eat batteries faster than a Thread version.
Wi-Fi six and seven are supposed to help there. Target wake time lets a device schedule when it wakes up to check for traffic, which reduces power draw significantly. OFDMA makes better use of the spectrum so a hundred devices aren't all shouting over each other.
Target wake time is the one I find interesting. Instead of the device waking up every few seconds to ask if there's anything new, it agrees with the router on a schedule. Wake up every minute, check in, go back to sleep. The radio is off the rest of the time.
That's the difference between a battery lasting three months and lasting two years. It doesn't make Wi-Fi as efficient as Zigbee, but it closes the gap enough that battery-powered Wi-Fi sensors stop being absurd.
And Wi-Fi six's OFDMA is the congestion fix. Instead of one device hogging a channel for a millisecond, the router can serve multiple devices in parallel. For a house with fifty Wi-Fi IoT devices, that's the difference between working and not working.
The catch is that all your devices need to support Wi-Fi six. The router can be Wi-Fi seven, but if the smart plug is still on Wi-Fi four, it doesn't get the benefit.
The installed base problem. IoT devices live for years. The cheap Tuya plug someone bought in twenty twenty is still on the network, still using the old protocol, still congesting the channel.
And that's the real answer to whether Wi-Fi has a future in IoT. It's already there. Hundreds of millions of Wi-Fi IoT devices are installed. The question isn't whether Wi-Fi belongs, it's how we make the installed base less terrible.
Let's talk about the fragmentation problem in the open-source tooling, because Daniel asked what exists and the answer is a pile of overlapping projects.
It's confusing. Tasmota, ESPHome, LibreTiny, Cloudcutter, WLED, Frigate. They all do different things, they overlap in places, and a newcomer has no idea where to start.
The saving grace is that most of them interoperate through MQTT and Home Assistant. You can have a Tasmota plug, an ESPHome sensor, and a WLED strip all talking to the same Home Assistant instance, and they all just work together.
MQTT is the common language. It's a lightweight messaging protocol that's been around since the late nineties, and it's the backbone of the local smart home. Every serious open-source firmware speaks it.
The fragmentation is a feature and a bug. It's a feature because different projects serve different needs. Tasmota is for liberating existing devices. ESPHome is for building new ones. WLED is for lighting. Frigate is for cameras. They're not really competitors, they're adjacent tools.
The bug is that the newcomer doesn't know that. They see five projects and assume they need to choose one. Actually they need maybe three of them for different things.
Daniel's question about what exists beyond WLED is really a question about the shape of the ecosystem. The answer is that it's not a single ecosystem. It's a constellation of tools that share a common language.
And the common language is what matters. MQTT and Home Assistant are the glue. Once your devices speak MQTT, the specific firmware matters less. You can mix and match freely.
Let's talk about the legal and ethical questions, because the liberation tooling sits in a gray area.
Cloudcutter exploits a vulnerability. That's not a secret. The tool works by taking advantage of a flaw in Tuya's update process. Using it on your own device is arguably fine. Using it on someone else's device is not.
And flashing custom firmware voids warranties. That's not a legal question, it's a practical one. If the device breaks and you've flashed it, the vendor won't replace it.
The reverse engineering question is more interesting. The DMCA has provisions about circumventing technical protection measures. Whether flashing firmware counts as circumvention is legally murky. Nobody's been sued for flashing Tasmota onto a smart plug, but the legal framework is unsettled.
The practical reality is that the manufacturers mostly don't care. A hobbyist flashing firmware on a fifteen dollar plug is not a threat to Tuya's business model. The threat is the power user community growing large enough that normal consumers start asking why their devices need the cloud at all.
And that's the long game. Every person who flashes Tasmota onto a plug tells two friends. Every person who sets up Frigate tells their family. The open-source Wi-Fi movement grows by word of mouth, and the vendors are watching.
Let's get concrete about the renter use case, because Daniel raised it and it's the one where Wi-Fi is the only option.
A renter wants a smart home. They can't run ethernet, they can't install a Zigbee coordinator in a permanent location, they can't drill holes. Their options are Wi-Fi or nothing.
With Wi-Fi, they can buy a plug, flash ESPHome, and have local control in an afternoon. No permanent modification, no landlord approval, no holes in the wall.
And the beauty of ESPHome is that it's fully local. The renter's automation runs on a Raspberry Pi or an old laptop running Home Assistant. Nothing leaves the apartment. When they move, they unplug everything and take it with them.
The alternative is the cloud-dependent Tuya plug that stops working when the internet goes down. For a renter, that's a real problem. Internet outages happen. The cloud goes down. The vendor goes out of business.
Local control means the smart home keeps working during an internet outage. The lights still turn on, the plugs still respond, the automations still run. The only thing that breaks is remote access from outside the house.
And that's the thing most people don't understand about local control. It's not just about privacy. It's about resilience. Your house keeps working when the outside world doesn't.
The e-waste angle is the other side of that. A cloud-dependent device that loses its cloud is a brick. A local device that loses its cloud doesn't notice, because it never had one.
Frigate is the case study that ties all this together. Open-source NVR, local AI object detection, works with Wi-Fi cameras that expose a standard stream. You get a fully local security system with no subscription.
And the AI part is what makes it interesting. Frigate uses a local model to do person detection, car detection, animal detection. It's not just recording everything, it's actually understanding what it sees. And it does it on hardware you already own.
The hardware requirement is the catch. Frigate wants a decent machine. A Raspberry Pi can do it if you're not pushing too many cameras, but the AI inference wants some compute. A used mini PC or a small server is the sweet spot.
But once it's running, it's a better experience than most cloud cameras. No subscription, no footage leaving your house, no company training their models on your driveway.
And the camera side is where Wi-Fi earns its keep. A Wi-Fi camera with RTSP support is a commodity. You can get one for thirty dollars. Point it at Frigate, and you've got a local security system that would cost hundreds in cloud subscriptions.
The filter is RTSP support. Some cameras expose it, some don't. The ones that don't are locked to their vendor's cloud, and they're useless for Frigate.
So the open-source Wi-Fi landscape is really two landscapes. There's the firmware liberation landscape, Tasmota and ESPHome and Cloudcutter, for taking vendor-locked devices and making them local. And there's the software landscape, Frigate and Home Assistant, for building local systems on top of open hardware.
WLED sits in between. It's firmware, but it's also a complete application. You flash it and you're done. No Home Assistant required, no MQTT required. It just works.
That's why WLED is the gateway drug. It's the one open-source Wi-Fi project that a non-technical person can actually use. Flash it, connect to the device's hotspot, configure your Wi-Fi, and you've got a working light controller.
The community around WLED is enormous. It's not just hobbyists. There are commercial products shipping with WLED preinstalled. It's become the default firmware for addressable LED control.
The question is whether any other open-source Wi-Fi firmware can reach that level of mainstream adoption. Tasmota is close, but it's still a tinkerer's tool.
ESPHome is the one I'd bet on. The YAML configuration model is accessible to people who'd never touch a compiler. You write a few lines of YAML, it builds the firmware, you flash it. It's not quite WLED simple, but it's close.
ESPHome is backed by the Home Assistant ecosystem, which is the largest local smart home platform in the world. That's a huge distribution channel.
The Home Assistant integration is the killer feature. ESPHome devices show up in Home Assistant automatically. No MQTT configuration, no manual entity setup. You adopt the device and it just appears.
Let's talk about the industrial open-source options, because Daniel asked and the answer is thinner than the consumer side.
The industrial open-source Wi-Fi landscape is mostly ESP32-based prototyping. Companies use ESPHome or custom Arduino firmware to build proof of concepts. The ESP32 is cheap, it's well documented, and it has a huge community.
The gap is certification. Industrial buyers need devices that are rated for temperature extremes, vibration, electromagnetic interference. The bare ESP32 doesn't have those ratings.
The security requirements are different. Industrial Wi-Fi networks have strict authentication, encryption, and monitoring requirements. A consumer ESP32 running ESPHome doesn't meet those standards out of the box.
The open-source industrial path is really a prototyping path. You prove the concept on ESP32, then you either build custom hardware with the right certifications or you buy from a vendor.
That's not a failure of open source. It's just the reality of industrial markets. Certification costs money, and open-source projects don't have the budget for it.
The interesting development is that some industrial vendors are starting to use open-source components. ESP32-based modules with industrial ratings are appearing. The line between consumer and industrial is blurring.
Wi-Fi six is making industrial Wi-Fi more viable. The efficiency improvements mean you can have more devices on a network without them interfering with each other. That's a real problem in factories with hundreds of sensors.
Let's zoom out and talk about the future. Daniel asked whether Wi-Fi has a future in IoT, and I think the answer is that it's already here and it's not going away.
The installed base is enormous. Hundreds of millions of Wi-Fi IoT devices are already deployed. They're not going to be replaced with Zigbee or Thread overnight. They're going to be on the network for years.
The new Wi-Fi standards are making the technology more suitable for IoT. Target wake time for power, OFDMA for congestion, better security with WPA3. The gap between Wi-Fi and the low-power protocols is narrowing.
The gap will never close completely. Zigbee and Thread will always be better for battery-powered sensors. But Wi-Fi is good enough for a lot of use cases, and it's getting better.
The open-source tooling is the wildcard. If Cloudcutter and LibreTiny make it easy to liberate Tuya devices, the lock-in weakens. If Matter over Wi-Fi actually delivers on its promise, the lock-in disappears entirely.
Matter is the one I'm watching. If it works, it solves the interoperability problem at the protocol level. You buy a Matter over Wi-Fi device, it works with any Matter controller, no cloud required.
Matter has been slow to deliver, and the vendor implementations have been inconsistent.
But the direction is right. The industry knows the current state is bad. Consumers are tired of devices that stop working when the cloud dies. Regulators are starting to ask questions about e-waste and planned obsolescence.
The open-source community has been saying this for years. Local control is not a fringe preference. It's the difference between owning your devices and renting them.
The tools are getting better. Cloudcutter is a genuine breakthrough. LibreTiny opens up a whole class of devices that were previously locked. ESPHome is becoming accessible.
The friction is still real. Flashing firmware is not a mass market activity. But the direction is clear.
Hilbert: I tried this once. Bought a cheap Tuya camera for the garage, figured I'd flash it and have a local setup. The thing phoned home to a server in China and stopped working every time the internet blinked. I spent three weeks trying to hack it. Bricked it completely. It's in a box in the basement with the smart plug I tried to flash with Tasmota. Desoldered a resistor by accident. That one's gone too.
The soldering is the part nobody warns you about. The pads are tiny, and one slip with the iron and the whole board is dead.
Hilbert: I've got a whole box of these. Bricked cameras, bricked plugs, a door sensor that never worked right even before I touched it. My wife says I should throw them out. I keep thinking I'll fix one of them someday.
The box of bricked devices is the real cost of the open-source Wi-Fi movement. Every success story has three failures behind it.
Hilbert: Before all that, I worked night security at a self-storage place. We had a dozen cameras wired straight to VHS tapes. The system never failed. Not once. The only thing more reliable than wired is a guard dog, and I can't have one of those because my dog ate the mailman's shoe.
The wired system never failed because there was nothing to fail. No firmware, no cloud, no update that bricks the device. It just recorded.
Hilbert: The thing is, I understand why they make these things cloud-dependent. It's easier for them. But it means the customer is always one server outage away from a useless device. That's not a product, that's a hostage situation.
The ransom is your data. The camera that phones home to China isn't just dependent on the cloud. It's feeding the cloud.
Hilbert: That's what got me started hacking in the first place. I didn't want my garage on some server I've never seen. But the hacking is harder than it looks, and the tools change every six months. I gave up after the third brick.
The tools have gotten better since then. Cloudcutter doesn't require soldering. You can do it over the network.
Hilbert: I hear that, but I'm not sure I believe it. Everything I've touched in this space has ended up in the box.
The box is the other side of the open-source promise. For every person who liberates a device, there's someone who bricked three trying.
Hilbert: I'd rather have a wired camera that works than a Wi-Fi camera I have to fight. But I can't run wire in the garage. The landlord won't let me drill. So I've got a Wi-Fi camera that phones home to China, and a box of bricks in the basement.
That's the renter's dilemma in one sentence.
Hilbert: The guard dog would've been simpler. But the mailman's shoe ended that.
The misconception people carry into this topic is that Wi-Fi is inherently unsuitable for IoT, full stop. The truth is more specific. Wi-Fi is terrible for battery-powered sensors, but it's the only option for high-bandwidth devices like cameras, and it's often the only option for renters who can't run wire. The protocol isn't the problem. The lock-in is.
The second misconception is that open-source Wi-Fi IoT begins and ends with WLED. The ecosystem is actually a constellation. Tasmota for liberating existing devices, ESPHome for building new ones, LibreTiny and Cloudcutter for cracking Tuya hardware, Frigate for local cameras. The tools are fragmented, but they interoperate through MQTT and Home Assistant.
The open question is whether Matter over Wi-Fi finally delivers the open standard that makes the liberation tooling unnecessary. If it works, you buy a device and it just works locally, no firmware flashing required. If it doesn't, the tinkerers keep soldering.
Wi-Fi six and seven are quietly making the technology more viable for IoT. Target wake time for power, OFDMA for congestion. The gap between Wi-Fi and Zigbee is narrowing, even if it never closes.
Thanks to Hilbert Flumingtop for producing, and for the box of bricks in the basement.
This has been My Weird Prompts. Check out the website at my weird prompts dot com for show notes and links to the projects we mentioned.
We'll be back soon.
