
The short version
- A cooling fan is a wear part, and fans wear out fastest in extreme heat — which is exactly when wildfires happen.
- A controller built around a computer has to boot up, and it takes software updates that can break things.
- FireShield has no cooling fan and no computer. Nothing inside a FireShield controller moves except the valves.
- It's sealed, so dust, water and insects can't get in, and there's no filter to clean.
- If you're comparing FireShield with other systems, put the same question to each of them: is there a fan in it, and does it run an operating system?
It is the third week of October in Los Angeles. A red flag warning has been up for two days. The Santa Anas have been blowing since Tuesday, the air is bone dry, and the controller on the side of your house has been baking in the afternoon sun at 104°F.
This is the moment your wildfire system exists for. It is also the hardest day it will ever have.
Most California homeowners shopping for exterior wildfire protection end up comparing FireShield with the competition. Price and zone count usually come up first.
I'd start somewhere else. Here's the question I'd ask before spending twenty or thirty thousand dollars on any of them: what is the most likely thing to be broken when you finally press the button?
For most outdoor equipment, it isn't the software or the sprinklers. It's the cooling fan. And the second answer is the little computer the fan is there to cool.
Neither one exists in the FireShield controller. That isn't a cost decision or a marketing angle — it's the first thing FireShield decided, and everything else was built around it.
Part 01: The fan
A fan has a spinning part. Spinning parts wear out. That's not controversial.
What most people don't know is when they wear out. Fan bearings die faster when they're hot — the grease inside thins out, drifts away, and stops doing its job. A fan rated to last twenty years in a cool room does not last twenty years inside a sealed metal enclosure sitting in direct October sun.
Then there's everything the fan pulls in. An enclosure with a fan needs vents, and vents in Southern California take in dust, pollen, ash, and insects. The fan blows all of it straight onto the electronics it's cooling. You can put a filter in front — but filters need cleaning, and nobody cleans the filter on a controller that has sat quietly in the side yard for four years asking for nothing.
Now put those two facts together and you get the part that actually matters.
A fan is most likely to fail in extreme heat. Wildfires happen in extreme heat. They are the same days.
Read that again, because it's the whole argument. A fan-cooled controller isn't unreliable in general. It's unreliable specifically on the days you need it. Its worst day and your worst day are the same day.
The fix isn't a better fan. It's not having one at all. That's the choice FireShield made.
FireShield's patent application says it plainly: the controller has "no fan or other moving cooling part," and "operates within a sealed, high-temperature enclosure." That one sentence forced every other decision. With no fan, the processor has to be one that survives inside a sealed enclosure in the heat — so FireShield picked the chip for that job, instead of picking a fast chip and bolting a fan on to keep it alive.
Sealing the enclosure buys something else, too. If it can't breathe, it can't take in dust, water, or bugs. There's no filter to clean, no vent to clog, and no wasp nest in the housing three summers from now.
Part 02: The computer
The second missing part is less obvious and, honestly, matters more.
A lot of modern control equipment is, underneath, a small computer running an operating system — usually a version of Linux. There are good reasons to build things that way. You get networking, drivers, apps, and a much easier job for the engineers.
This is also the part that's hardest to see from a brochure. If you're weighing FireShield against the competition, it's worth asking each company directly rather than guessing from a spec sheet.
For a controller that has to open a valve at an exact moment, on a day when the power is flickering and nobody is home, it costs you three things.
One: it has to start up. A computer takes anywhere from a few seconds to most of a minute to boot — and during that time it is powered on but protecting nothing. On a normal Tuesday you'd never notice. During a wildfire, when the power is browning out and cycling as flames reach the poles, a computer can spend a real chunk of the emergency booting instead of working. Every power blip costs you that window again.
FireShield's controller doesn't boot. There's nothing to boot.
Two: it gets updates, and updates break things. An operating system is a stack of parts — kernel, drivers, libraries — each updated on its own schedule. Usually they get along. Sometimes an update and a driver disagree and something that worked yesterday doesn't work today. In an office that's an annoying morning. In a life-safety device that sits untouched for years, it's a failure you discover at the exact moment it matters, with nobody there to discover it.
The patent is blunt about why FireShield went the other way: dropping the operating system "removes operating-system updates and the version dependencies among operating-system components, drivers, and libraries that can mismatch and cause failure or downtime."
Three: the timing drifts. This is the one engineers feel immediately.
A computer's operating system juggles many jobs at once and is very good at it. What it won't promise is that one specific instruction runs at one specific instant. Usually that's fine.
Valves are not usually. A motorized valve travels while power is applied and stops when it's cut. Too short a pulse and it doesn't finish opening. Too long and you're grinding a valve that's already shut. The right pulse depends on that exact valve and the water pressure behind it — in FireShield's own example, about 8 to 10 seconds for a low-pressure roof valve, and 25 to 30 seconds for a high-pressure one. Those numbers only mean anything if the controller hits them every time, under load, while it's also talking to a satellite modem.
So instead of a computer, the FireShield controller runs software written directly for the chip, with valve control given its own dedicated processor core. The satellite radio has a processor of its own so it can't interrupt a valve mid-travel. No boot. No updates that can break a valve. Much less to go wrong, and it goes wrong far less often.
Is there a trade-off? Yes, and it's fair to say so: this kind of software is harder to write and slower to change than an app on Linux. FireShield gets that flexibility back a different way — all the settings live in a configuration file the controller reads fresh each time, so your system can be adjusted without ever touching the software itself.
Part 03: The part nobody plans for
There's a bonus that falls out of the first two, and it's my favorite because nobody designs for it.
No fan and no computer means the FireShield controller sips power. Less power means less heat. And heat is the single biggest reason electronics die — components dry out faster hot, and solder joints crack faster when things swing hot and cold. Cooler electronics simply last longer, across every part on the board.
Then it pays off a second time. When the power goes out — and during a wildfire that's close to guaranteed once flames reach the lines — everything runs off the battery. A controller that draws less power runs longer on that battery, and leaves more of it for the things that actually move water: the valves and the pumps — which is what matters most in the hours after the grid goes down.
One decision. Four benefits. And the fourth one shows up on the worst day of your life.

What to ask any company before you sign
You don't need to be an engineer to check this. Five questions, and you can ask them on the phone.
| Question | Why it matters |
|---|---|
| Is there a cooling fan? | If yes, it's a wear part — and it fails fastest in fire weather. |
| Does the enclosure have vents? | Vents mean dust, water and insects get in over the years. |
| Does it run an operating system? | If yes, ask what happens during the 30 seconds it spends starting up after a power blip. |
| Can settings change without a software update? | With FireShield they can — it's a settings file, not a code change. |
| What does it draw on backup? | Less power means longer runtime on battery, and more left for the pumps. |
Ask the competition. Ask FireShield. Ask anyone else you're considering. The answers will sort the field quickly.
None of this is something you'll ever see working. That's the whole point. The measure of a system like this isn't what it does on the day it runs — it's what it hasn't quietly become during the four silent years before that day.
Every moving part is a countdown you can't see. Every layer of software is something that can drift.
FireShield removed both.

Part of a series on how automated wildfire defense actually works — in plain English.
Next in this series
- The Setting You Can Change in Ten Seconds — Why FireShield's behavior lives in a settings file instead of its software — and what that means when an installer wires a valve backwards.
- What Happens When the Cell Towers Go Down — Four ways to start a FireShield system, three of which need no internet at all.
- One Controller Fits Every House — The same design, seen from the factory.
- What Actually Has to Work When Nobody's Home — The whole system, start to finish, in plain English.
About FireShield — FireShield builds automated exterior wildfire defense systems for homes across Southern California. The controller described here is covered by FireShield's patent. See the wildfire defense system or talk to us.