Daniel's been helping someone set up Home Assistant for a vacation property — place that sits empty ten months of the year. They've already got a professionally installed alarm, but what actually grabbed them was the idea of remote microphone monitoring. The logic's straightforward: if someone breaks in, you'd probably hear something, and that audio might give you a lead. So Daniel's asking what kind of microphone you'd pick for this — where the specs that matter are wide pickup pattern and long range.
This is a interesting engineering problem, because you're asking a microphone to do something it's fundamentally bad at. Microphones obey the inverse square law just like light does — double the distance, quarter the sound pressure. A room is a terrible acoustic environment for what this person wants. Hard surfaces, reflections, HVAC noise, refrigerator compressors kicking on. The signal you want is quiet and far away, and the noise floor is everywhere.
So the first question is whether you're trying to hear a conversation or just detect that something is happening.
Right. And those are two completely different systems. If all you need is event detection — glass breaking, footsteps, a door being forced — you don't need a microphone at all in the traditional sense. You want an acoustic glass break sensor, or you let the alarm system handle that layer. But Daniel's person wants to actually listen in. They want to pull up an audio feed and hear what's happening in real time. That's a much harder problem.
And they want it through Home Assistant, which means whatever microphone they pick has to integrate cleanly. No proprietary hub that phones home to a server in Shenzhen.
That constraint actually narrows the field in a useful way. You're looking at a few paths. Path one is IP cameras that expose an audio stream. Path two is a dedicated microphone module feeding into something like an ESP32. Path three is a USB microphone connected to whatever's running Home Assistant or a satellite device. Each has tradeoffs, and the wide-pickup long-range requirement eliminates most of what's on the shelf.
Walk me through the camera route first, because that's what most people reach for.
Most IP cameras have terrible microphones. They're tiny electret capsules buried inside a weatherproof housing, and they're designed to pick up someone standing within about six feet of the camera, facing it, in a quiet environment. The audio codec is usually low-bitrate — think eight kilohertz mono, sometimes worse. It's fine for "person at the doorbell" but useless for "what's happening in that room thirty feet away."
So the Reolink and Amcrest cameras people normally pair with Home Assistant aren't going to cut it.
Not for this use case. Some of their higher-end models have slightly better audio — the Reolink Duo series, for example, has a slightly larger microphone element and marginally better preamps — but you're still dealing with a microphone that's optimized for weather resistance, not acoustic sensitivity. The Amcrest IP five-megapixel turret cameras have audio input jacks on some models, which is interesting because you could connect an external microphone. But now you're running cable, you're mounting a separate mic, and at that point you might as well build a purpose-built solution.
Which brings us to the ESP32 path.
This is where it gets fun. The INMP441 is a MEMS microphone — microelectromechanical systems, basically a microphone etched onto a silicon die — and it has an I-two-S digital output. That means you can connect it directly to an ESP32's I-two-S bus and stream pulse-code modulation audio over Wi-Fi. No analog noise picked up along a cable run, no separate analog-to-digital converter introducing its own noise floor. The INMP441 has a signal-to-noise ratio of about sixty-one decibels, which is solid, and a flat frequency response from about sixty hertz up to fifteen kilohertz.
And the pickup pattern?
Omnidirectional. That's the key spec for this application. You want to hear everything in the room, not just what's directly in front of the mic. The INMP441's omnidirectional response is good — it's within a couple of decibels across nearly the full three hundred sixty degrees in the horizontal plane. There's some high-frequency roll-off as you move off-axis above about ten kilohertz, but for voice and environmental sounds, it's effectively uniform.
So one of these in the center of an open-plan living area would hear... what, a conversation anywhere in the room?
In a quiet room, you'd pick up normal conversation at twenty to twenty-five feet. Whispering, maybe ten to twelve feet. Footsteps on hardwood, easily thirty feet. The limiting factor stops being the microphone and starts being the room acoustics and the noise floor. A refrigerator cycling on in the next room will mask a lot.
What about the software side? You're streaming raw audio from an ESP32 into Home Assistant — Home Assistant doesn't natively handle live audio streaming.
Correct, and this is where the project gets real. You'd run something like ESPHome on the ESP32, which has an I-two-S microphone component that can stream audio. But ESPHome doesn't have a built-in audio streaming server — it can sample the mic and expose the data, but you need something to receive it. The common approach is to run a separate service that ingests the stream. A lot of people use a small Python script that receives the UDP audio packets and makes them available as an HTTP stream, or pipes them into an MQTT broker with a binary sensor that triggers on audio level thresholds.
So you'd open Home Assistant, see the audio level, and if something looks suspicious you'd pull up the stream separately.
That's the practical architecture. You'd have a microphone entity in Home Assistant that shows you the decibel level in near real-time, maybe with a threshold sensor that fires an automation if the level spikes above ambient. Then a separate dashboard or companion app that lets you actually listen when you want to. It's not a single polished product — it's a project.
Which is fine for Daniel, honestly. He builds things.
He absolutely builds things. And the ESP32 route gives you something cameras can't touch — you can place the microphone anywhere. Middle of the ceiling, high on a wall, wherever gives you the best acoustic coverage of the space. You're running USB power to it, which is trivial, and the thing is the size of a postage stamp. You could hide it in a light fixture.
Now what about the third path — the USB microphone? That seems almost too simple.
It can work, but the integration path is different. If you have a small computer running somewhere in the house — a Raspberry Pi, an old Intel NUC, whatever — you plug in a USB condenser microphone and run software that streams the audio. The advantage is you can use a much better microphone. A Blue Yeti in omnidirectional mode, or an Audio-Technica AT twenty twenty USB plus, has a vastly better capsule, better preamps, and lower self-noise than any MEMS mic. The Yeti's self-noise is something like twelve decibels A-weighted, which is exceptionally quiet. The INMP441 is around twenty-eight decibels. That's a sixteen-decibel difference in noise floor — it's meaningful.
But now you've got a full computer running, and a very obvious microphone sitting on a shelf.
Right. And the computer is another thing to maintain, another thing drawing power, another thing that can crash and need a reboot. For a vacation home that sits empty most of the year, reliability is everything. The ESP32 boots in under a second, draws less than a watt, and will run for years without anyone touching it. I'd take the ESP32 with the INMP441 over the USB route for this application every time.
What about something more exotic? I've seen those parabolic microphones — the clear plastic dishes you see on the sidelines at football games.
Parabolic mics are incredible at what they do, but what they do is the opposite of what Daniel's person wants. A parabolic dish focuses sound from a very narrow angle — you're talking a beam width of maybe ten to twenty degrees depending on the dish size and frequency. You point it at something specific and it pulls in sound from that direction with astonishing gain. But it's deaf to everything outside that cone. For room surveillance, you'd hear one chair really well and miss the guy breaking into the kitchen.
Shotgun microphones, same problem.
Same problem, different mechanism. A shotgun mic uses an interference tube — a long slotted tube in front of the capsule — to cancel sound arriving from the sides. The longer the tube, the narrower the pickup. A Sennheiser MKH four sixteen, which is about as standard as shotgun mics get, has a pickup pattern that's effectively a tight oval. At a thousand hertz, it's down six decibels at about sixty degrees off-axis. At higher frequencies it's even tighter. You'd have to aim it precisely, and you'd still miss most of the room.
So the exotic options are exactly wrong for this.
They're solving the inverse problem. They're for isolating a distant source in a noisy environment. Daniel's person has a quiet environment and wants to hear everything. The INMP441 in a central ceiling mount is close to ideal.
What about multiple microphones? If one omnidirectional mic in the center gives you coverage, three or four scattered around starts to look like whole-home audio pickup.
Now you're talking about an array, and this gets into beamforming territory — which is fascinating but probably overkill. If you place multiple ESP32 microphones in different rooms and stream them independently, you get coverage without complexity. Each one is a separate entity in Home Assistant with its own audio level sensor. You can switch between them or monitor all of them. The cost per node is maybe eight dollars in parts — ESP32 dev board, INMP441 breakout, a USB power supply, and a short USB cable. For under forty dollars you could cover a four-bedroom house with a mic in each main area.
That's absurdly cheap.
It really is. The INMP441 breakout boards are about three dollars each. The ESP32 dev boards, maybe four dollars. The most expensive component is the USB charger. We're living through a moment where a distributed whole-home audio monitoring system costs less than a single proprietary security sensor from ADT.
And the audio quality from these cheap MEMS mics is actually usable?
For voice, absolutely. You're not recording a podcast on them — the frequency response rolls off below about sixty hertz, and there's some harmonic distortion at very high sound pressure levels — but for the frequency range of human speech, roughly three hundred to three thousand hertz, they're flat and clean. The bigger issue is compression artifacts if you're streaming over a low-bandwidth connection. If the vacation home is on satellite internet or a slow DSL line, you might need to dial down the sample rate. Sixteen kilohertz mono PCM is about two hundred fifty-six kilobites per second. That's fine on broadband but could saturate a slow uplink. You'd drop to eight kilohertz and it'd still be intelligible — it'd just sound like a telephone call.
And that's fine for "is someone in my house right now."
More than fine. You'd hear glass break, footsteps, voices, doors opening. A car pulling into the driveway if the mic is near a window. The audio level sensor in Home Assistant gives you the passive monitoring layer — you don't have to be actively listening. You set a threshold above ambient, and if it trips, you get a notification on your phone. Then you pull up the stream and listen.
The one thing we haven't touched is the legal side. Vacation home — could be anywhere. Different states, different rules about audio recording.
This is important and easy to get wrong. In the US, audio recording laws fall into two categories. One-party consent states, where as long as one person in the conversation knows it's being recorded — and that can be the person who set up the recorder — it's legal. And all-party consent states, where everyone being recorded needs to know. California, Florida, Illinois, Maryland, Massachusetts, Montana, New Hampshire, Pennsylvania, and Washington are the all-party states. But here's the thing — those laws generally apply to recording conversations where there's an expectation of privacy. An empty vacation home that you own, where no one is supposed to be, is a different legal context from bugging your tenant's apartment.
So if someone breaks in, they don't have an expectation of privacy in your house.
Correct. And you're not recording continuously and storing everything — you're monitoring in real time. The legal exposure shrinks considerably. But I'd still want to know which state the property is in and I'd probably put up a small sign. "Audio monitoring in use." It's cheap insurance.
Even if it just says that to the burglar.
Even then. The deterrent effect is real. A sign that says "live audio monitoring" next to a visible alarm system sticker might make someone pick a different house.
What about the Home Assistant automation side? You mentioned threshold triggers — what does that actually look like in practice?
ESPHome exposes the microphone as a sensor that reports decibel levels. You can create a template binary sensor in Home Assistant that goes true when the level exceeds whatever you've calibrated as normal ambient. Then an automation: if the binary sensor turns on, send a notification with a deep link to the audio stream. You could get fancy — only trigger if the level stays elevated for more than three seconds, to filter out a car horn or a door slam from outside. You could have it snap a still from any connected cameras at the same moment. You could have it turn on lights, which is a surprisingly effective deterrent.
The lights thing is underrated. A house that suddenly lights up at three in the morning looks very occupied.
And it's trivially easy to automate. The audio trigger fires, lights come on in sequence to simulate someone waking up and walking through the house. The psychology of that is brutal — a burglar doesn't know if it's automated or if someone's home, and they're not going to stick around to find out.
So the full setup is: ESP32 with an INMP441 in each major room, ESPHome firmware, UDP audio streaming to a small service that provides an HTTP stream, audio level sensors in Home Assistant with threshold automations, and optional camera snapshots and light sequences on trigger. Total cost under a hundred dollars for a whole house.
And the whole thing runs locally. No cloud service, no subscription, no data leaving the network. The audio never touches a server you don't own. For a vacation home that sits empty, that's the right architecture. The professionally installed alarm handles the door and window contacts and the motion sensors — the audio layer gives you something those can't: situational awareness before you decide whether to call the police.
One thing I wonder about — and this is the kind of thing Daniel would actually run into during setup — is gain staging. How do you set the microphone level so it's sensitive enough to hear a conversation across the room but not so hot that the refrigerator compressor pegs the meter?
This is the part that takes tuning. The INMP441 has a configurable gain setting in ESPHome — you can set it anywhere from zero to about sixty decibels of gain in three-decibel steps. The trick is to start low and work up. Set it to zero gain, make some noise at the farthest point in the room you care about, and see what the reported level is. Then add gain until that sound registers clearly above the noise floor but normal ambient doesn't trigger your threshold. It usually ends up somewhere around twenty to thirty decibels of gain for a typical residential room. The refrigerator will still show up — it's a constant low-frequency hum — but it won't trip the threshold if you've set it right.
And you do this calibration with the HVAC running, because that's the real ambient floor.
You calibrate under worst-case ambient conditions. If the house has central air, you run it. If there's a dehumidifier in the basement, it's on. You want your threshold above the highest normal ambient, not the average. Otherwise you get false positives every time the AC kicks on.
Which erodes trust in the system fast. After three false alarms you stop checking.
And then the one real event gets ignored. Alert fatigue is the thing that kills security monitoring. The automation has to be tuned tight enough that when it fires, you believe it.
Daniel mentioned this is for someone who uses the place a month or two a year. Does the system need to be winterized or maintained?
The hardware doesn't care. The ESP32 is rated for industrial temperature ranges — negative forty to positive eighty-five Celsius for the chip itself. The INMP441 is specified for negative forty to positive eighty-five as well. A vacation home that drops to forty degrees Fahrenheit in the winter is nothing to these components. The bigger concern is humidity and condensation, but in a sealed indoor environment that's unlikely to be a problem. The USB power supplies are probably the weakest link — cheap ones can fail after a couple of years of continuous operation. I'd spend an extra three dollars on a name-brand charger.
And if the power goes out and comes back, the ESP32 just boots and reconnects.
That's the beauty of it. No filesystem to corrupt, no operating system to hang on boot. It's a microcontroller. Power comes back, it's running firmware in under a second, Wi-Fi reconnects, and it's streaming audio again before the router has even finished booting.
We should talk about an alternative approach that someone might suggest — just using an old Android phone as a network microphone.
It works, and there are apps that do exactly this — turn an Android device into an IP camera with audio streaming that Home Assistant can ingest. The microphone in a mid-range phone from the last five years is good. Multiple mics, noise cancellation, decent preamps. The problem is the battery. You're leaving a lithium-ion battery plugged in and charging continuously for months at a time in an unoccupied building. That's a fire risk I'm not comfortable with. You can remove the battery on some phones and run them directly off USB power, but not all models support that, and it's a project in itself.
So the phone route works in theory, but the ESP32 route is safer and simpler.
And cheaper, and more reliable, and easier to hide. The phone wins on audio quality — a Pixel or an iPhone has a much better microphone subsystem than a three-dollar MEMS breakout board. But for this application, "good enough" audio that runs forever without catching fire beats excellent audio with a thermal runaway risk.
I keep coming back to the placement question. Ceiling mount, center of the room — that's the ideal. But most people aren't going to run a USB cable through their ceiling. What about just... putting it on top of the refrigerator?
Refrigerator top is actually not bad. It's central in most kitchens, it's elevated, and it's inconspicuous. The refrigerator's own noise is below the mic — literally, the compressor is at the bottom — so you're not coupling vibration directly into the mic element. The downside is the kitchen isn't where most break-ins happen. Burglars go for master bedrooms and home offices first — that's where the jewelry and electronics are. You want a mic near the entry points and near the high-value rooms.
So maybe two mics minimum. One covering the main entry and living area, one covering the master bedroom hallway.
That's the setup I'd recommend. Two ESP32s, two INMP441s, maybe thirty dollars in parts total, and you've got coverage of the areas that matter. If the house is larger, add more. They're cheap enough that the decision is about where to put them, not whether you can afford another one.
What about outdoor coverage? Hearing someone before they break in is even better than hearing them after.
Outdoors changes everything. Wind noise, rain, traffic, animals. The noise floor is twenty to thirty decibels higher. A MEMS mic outdoors is nearly useless without a windscreen and some kind of weather protection. For outdoor audio, you're better off with a camera that has a built-in microphone designed for exterior use, or a dedicated outdoor microphone with a weatherproof housing. But honestly, for perimeter detection, audio is the wrong tool. Outdoor PIR sensors, cameras with person detection, even a driveway alert — those are all more reliable than trying to hear footsteps on gravel from fifty feet away.
So keep the audio monitoring indoors, let other sensors handle the perimeter.
That's the right division of labor. The alarm system handles entry detection. The cameras handle visual verification. The microphones give you ears inside the house after someone's in — or, ideally, confirm that nobody's in and you don't need to drive out there at two in the morning.
One last thing on the Home Assistant integration — you mentioned a Python script receiving UDP packets. Is there an off-the-shelf solution for this yet, or is it still very much a roll-your-own situation?
It's still roll-your-own, but the pieces are well-documented. ESPHome has example configs for the I-two-S microphone. There are at least three different projects on GitHub that do the UDP-to-HTTP bridge for audio streaming. The Home Assistant side — the template sensor, the automation — is all native. The only custom piece is the streaming server, and that's maybe fifty lines of Python. Daniel could write it in an afternoon.
Hilbert: Nineteen ninety-four. I was running sound for a club in Providence.
That's not where I thought you were going.
Hilbert: The owner wanted to hear what the bartenders were saying when he wasn't there. Thought they were skimming. So we put microphones behind the bar — little Radio Shack electret condensers, nothing fancy — and ran them to a cassette deck in the office that recorded in four-hour loops.
Did it work?
Hilbert: He caught two of them in the first week. But the thing that stuck with me was the false positives. The ice machine had a defrost cycle that sounded exactly like someone counting bills. Every four hours, this mechanical groan, and he'd come running. After a month he stopped checking. Stopped checking entirely. The tapes piled up and nobody ever listened to them again.
Alert fatigue.
Hilbert: That's what you called it. Yeah. The system worked fine. The microphones were fine. The whole thing fell apart because the human on the other end stopped trusting it.
That's the part that doesn't show up in the spec sheet. The threshold tuning isn't just a technical problem — it's a behavioral one. If the system cries wolf, it's worse than having no system at all, because now you've trained yourself to ignore it.
Hilbert: The ice machine was the worst of it, but there were others. The walk-in cooler door had a hinge that squeaked at the exact frequency of someone saying "hey." The neon sign over the bar buzzed at sixty hertz and the mic picked it up as a low hum that sounded like a truck idling outside. We spent more time chasing phantom sounds than we ever did catching actual problems.
How did you solve it?
Hilbert: We didn't. The owner sold the place. New guy ripped it all out and just put up a sign that said "smile, you're on camera." No cameras either. Just the sign.
The sign did the work.
Hilbert: Far as I know, nobody stole from that bar for five years. The bartenders hated the sign. They'd stare at it all shift.
The lesson is that the deterrent is worth more than the detection.
Hilbert: I wouldn't go that far. But I'd say the detection is only as good as the person who believes it when it goes off. All that gear, all that wire I ran through the ceiling — the whole thing came down to whether one guy would get out of bed at three in the morning because a light on a box told him to. And after the ice machine got him a few times, he wouldn't.
That's actually a strong argument for the audio level sensor approach we were talking about. You're not listening to a live stream all night. You're waiting for a threshold crossing, and you've tuned the threshold above the ice machine equivalent.
Hilbert: The ice machine equivalent is the thing you don't know about yet. That's the problem. You don't know what it is until it wakes you up at four AM.
You calibrate, you tune, and then you live with it for a few weeks and tune again.
Hilbert: You accept that nothing's perfect. That's all I'm saying.
The other thing your story highlights is that the audio doesn't have to be perfect to be useful. Those Radio Shack electrets through a cassette deck — that's terrible audio quality by any modern standard. But it was good enough to catch two people stealing.
Hilbert: You could hear the register open. That sound, you don't need high fidelity for. The coins hitting the tray, the drawer sliding — it cuts through anything.
Some sounds are just unmistakable. Glass breaking. A door being forced. Footsteps on a floor that's supposed to be empty.
Hilbert: Footsteps on hardwood, you can hear through a tin can and string. You don't need the fancy MEMS thing. But I wasn't going to say that earlier.
Why not?
Hilbert: Because the MEMS thing is three dollars and it's digital and it won't hum. The Radio Shack mics hummed. Everything hummed in nineteen ninety-four. The whole building hummed. I spent half my time chasing ground loops.
The modern approach is better.
Hilbert: The modern approach is better. I just wanted to say that the weak link was never the microphone. It was the human. And that part hasn't changed.
That's... actually a good note to land on. The technology is solved. Two ESP32s, a couple of INMP441s, some Python glue, and you've got a system that would have cost thousands of dollars twenty years ago and required a dedicated tape deck. The hard part is tuning it so the human trusts it, and that's just patience and iteration.
Hilbert, thanks for producing as always. And for the Providence story. This has been My Weird Prompts, the human-AI collaboration podcast. If you've built something like this — an ESP32 audio monitor, a Home Assistant security setup, or you've got a better approach to the false-positive problem — we'd love to hear about it. Email the show at show at my weird prompts dot com.
We'll be back soon.
