All right, scenario. Your parking indicator is three floors underground in a concrete garage. You've got a magnetic contact sensor on the door down there, and you need to know whether that spot is open or closed. Drops at ten meters on a good day. Doesn't exist down there. You're not running Ethernet through three floors of reinforced concrete for a single binary sensor. What's your move?
It's the move. And the timing on Daniel's question is actually perfect, because three things have lined up that make this genuinely practical right now. LoRa module costs have dropped below fifteen dollars. Home Assistant integration via ESPHome is production-ready and stable. And Israel just standardized LoRaWAN, which removes the regulatory ambiguity that used to make tinkerers nervous about whether they were even allowed to transmit.
Daniel sent us this one — he's laying out a pretty specific hypothetical. A parking indicator in a garage three or four stories below a house. The idea is using LoRa to send a tiny data packet — literally "parking open" or "parking closed" — from somewhere that has no cellular, no Wi-Fi, no internet connection of any kind. And he's asking the practical questions: realistic range through concrete, regulatory concerns here in Israel, what hardware you need on the receiver end, and what it costs to add a LoRa transmitter to a Home Assistant stack running on a mini PC.
Which is exactly the right set of questions. Because LoRa sits in this weird niche that most smart home people never touch. It's not a replacement for Zigbee or Wi-Fi. It's for the sensor that's too far away, too buried, and too low-data for anything else to make sense.
The parking garage hypothetical is perfect because it's right at the edge of what's possible. Three or four floors of reinforced concrete is not a trivial ask for any radio technology. But LoRa operates in sub-gigahertz bands — eight sixty eight megahertz here in Israel, nine fifteen in the US — and those lower frequencies punch through walls and floors in a way that two point four gigahertz simply cannot.
And that's the first thing to understand. Zigbee and Wi-Fi both sit at two point four gigahertz. At that frequency, the wavelength is about twelve and a half centimeters. Concrete and rebar eat that signal for breakfast. Sub-gigahertz LoRa has a wavelength closer to thirty five centimeters. Longer waves diffract around obstacles better and lose less energy per meter of material they have to penetrate. So the physics is fundamentally on your side before you even get to the clever modulation tricks.
Which is why this isn't just a "what if" exercise. Anyone who's tried to get a Zigbee sensor working in a basement or a detached garage knows that pain intimately. You add a repeater, then another repeater, and suddenly your simple ten-dollar sensor has a fifty-dollar mesh network supporting it.
The mesh still doesn't work through three floors of parking garage. So let's actually define what we're talking about, because the terminology gets sloppy fast. LoRa is the physical layer — it's the actual radio modulation scheme, this chirp spread spectrum thing that's remarkably good at pulling signals out of noise. LoRaWAN is the network protocol built on top of it, which adds encryption, device management, authentication, and the ability to connect to carrier-grade infrastructure. For Daniel's parking garage scenario, you almost certainly want raw point-to-point LoRa, not the full LoRaWAN stack.
Why not LoRaWAN?
Because LoRaWAN assumes you're connecting to a network server through a gateway, which then routes your data to an application server. It's designed for thousands of devices across a city, not one sensor talking to one receiver three floors up. You can use it, but it's overkill. Point-to-point LoRa between two modules is simpler, cheaper, and doesn't require any network infrastructure or subscription. You just have two radios talking to each other.
It's the difference between making a phone call on a cellular network versus using a walkie-talkie. One has a whole system behind it, the other is just two devices on the same frequency.
That's exactly the right analogy. And for "parking open" and "parking closed" — two bytes of data, sent maybe once an hour or on state change — you don't need the cellular network. The walkie-talkie is perfect.
The core trade-off here is that you get that penetration and range by accepting extremely low data rates. We're talking zero point three to fifty kilobits per second. You're not streaming anything. You're not even sending a photo. You're sending a handful of bytes.
Which is exactly what a parking indicator needs. One byte for the sensor ID, one byte for the state. That's it. The whole payload is smaller than the header on a typical Wi-Fi packet. And LoRa is designed around that assumption — tiny payloads, infrequent transmissions, long battery life.
Before we dive into the range numbers and the regulations and the hardware, let's frame this around the practical use cases beyond just the parking garage. Because once you start thinking in LoRa terms, you realize how many smart home problems fit this exact profile. Remote gate sensors at the end of a long driveway. A water alarm in a basement that's three floors down with no Wi-Fi. Soil moisture monitors scattered across a garden fifty meters from the house. Anything where running Ethernet is absurd, Wi-Fi doesn't reach, and you don't want to change batteries every week.
That last point matters more than people think. LoRa modules can run for months or years on a small battery because they spend almost all their time in deep sleep, wake up, transmit for a few milliseconds, and go back to sleep. A Zigbee sensor doing the same thing would drain faster because it has to maintain a mesh connection and check in regularly. LoRa is fundamentally designed for low-power, low-duty-cycle operation.
With that picture in mind — sub-gigahertz radio, tiny data payloads, years of battery life, and a concrete parking garage as our test case — the first question anyone asks is the obvious one. How far does it actually go? And specifically, how far does it go through reinforced concrete?
Let's get into the numbers.
The Nature study from last year is the best data we have on this. They measured LoRa signal attenuation through reinforced concrete at eight sixty eight megahertz and found twenty to thirty decibels of loss per floor. So for Daniel's parking garage, four floors down, you're looking at potentially a hundred decibels of signal loss before the packet even reaches open air.
A hundred decibels is brutal. What's the link budget on a typical LoRa module?
A standard SX1276 chip transmitting at fourteen dBm — that's about twenty five milliwatts — has a link budget around a hundred and sixty eight decibels with the spreading factor cranked up. So a hundred dB of concrete loss eats most of that, but not all of it. You've got roughly sixty eight dB left for free-space path loss, which at sub-gigahertz frequencies gets you quite a bit of distance. The math says it's marginal but possible.
Marginal but possible is basically the slogan for every ambitious smart home project.
Marginal is where antenna placement becomes everything. If your receiver is on the ground floor near a stairwell or a window that faces the garage, you might catch enough signal bouncing up through the stairwell shaft. Concrete floors are bad, but concrete floors with a vertical air gap — like a stairwell — create a propagation path that's much friendlier than trying to punch straight through four solid slabs.
The difference between "works fine" and "dead silent" could be whether you put the gateway three meters to the left.
And that's what the RAK Wireless range tests confirmed in real-world conditions. They got fifteen kilometers in open fields with a twenty dollar module. Two kilometers in suburban environments with houses and trees. And about half a kilometer in dense urban environments with multiple buildings in the way. None of those tests involved underground garages, but they establish the scaling behavior. Every concrete wall or floor knocks off twenty to thirty dB, and eventually you hit the noise floor.
Which brings us to the regulatory side, because Israel just standardized all of this, and the rules shape what's actually practical.
Israel's Ministry of Communications adopted the LoRaWAN standard for the ISM bands, which means both eight sixty eight megahertz and nine fifteen megahertz are permitted. But — and this is the part that trips people up — they come with different duty cycle limits.
Define duty cycle for the person who's never had to care about radio regulations.
It's the percentage of time you're allowed to be transmitting. On eight sixty eight megahertz, you get one percent per hour. So in any given hour, your device can transmit for a total of thirty six seconds. On nine fifteen, in some sub-bands, it's even tighter — zero point one percent, or about three point six seconds per hour.
For a parking sensor that transmits once when the door opens and once when it closes, that's basically irrelevant. You're transmitting for milliseconds.
But it becomes very relevant if you're designing a system that polls sensors every few seconds. You can't. The regulations force you into event-driven design, which is actually the right approach anyway for battery-powered sensors. Transmit on state change, not on a timer.
The power limits?
End devices under twenty five milliwatts effective radiated power don't need a license. That covers basically every off-the-shelf LoRa module you'd buy for a home project. Gateways are a different story — they may need registration, especially if you're putting up an outdoor antenna with higher gain. The Ministry hasn't been aggressive about enforcing that for hobbyists, but it's worth knowing the line exists.
What about interference? Daniel specifically asked about dense environments with other operators.
This is where spread spectrum earns its keep. LoRa's chirp spread spectrum modulation is inherently resistant to interference because it spreads the signal across a wider bandwidth than the data actually needs. Multiple LoRa devices can transmit on the same frequency using different spreading factors and they're effectively orthogonal — they don't collide in a way that destroys both packets.
It's like multiple conversations in a room where everyone is speaking a slightly different dialect. You can pick out your conversation even with background noise.
But there's a limit. Once you get above roughly a hundred devices per gateway, packet collision rates start climbing noticeably. Telcos running public LoRaWAN networks in dense urban areas add to that noise floor. For a home user with one or two sensors, it's a non-issue. If you're deploying fifty soil moisture sensors across a farm, you start needing to think about spreading factor allocation and transmission scheduling.
Which is well beyond the parking garage problem. So on the receiver side — what are we actually buying?
Two main paths. The cheaper one is an ESP32 board with an integrated LoRa module — something like a TTGO or Heltec board with the SX1276 chip. Fifteen to twenty five dollars total, and it runs ESPHome natively. The other path is a Raspberry Pi with a LoRa HAT, like the Dragino, which runs forty to sixty dollars. The Pi gives you more processing headroom and easier Python scripting, but it's overkill for decoding two bytes from a parking sensor.
Both can feed data into Home Assistant?
The ESP32 with ESPHome exposes the LoRa data as native Home Assistant entities directly. The Pi route typically uses MQTT as the bridge — a Python script decodes the LoRa packets and publishes to an MQTT topic that Home Assistant subscribes to. ESPHome is cleaner for this use case.
For the garage setup specifically, you'd put the receiver on the ground floor, maybe near a window facing the garage entrance or next to the stairwell.
With an external antenna if possible. The little coiled antennas that come on these boards are fine for open-air testing, but for punching through concrete, a half-wave dipole or even a basic whip antenna with some gain makes a measurable difference. Ten dollars for an antenna can be the difference between reliable reception and packet loss.
We've got the receiver sorted. What about the other end — the transmitter sitting in the garage next to the parking indicator? If I'm running Home Assistant on a mini PC upstairs, how do I actually get a LoRa signal out of that thing?
Two clean paths. The simplest is a USB LoRa dongle — basically an SX1276 on a stick — plugged directly into the mini PC. Those run ten to twenty dollars. You'd use a Python library like PyLoRa or run a small MQTT bridge that listens for LoRa packets and publishes to Home Assistant. It works, but it ties your transmitter to the physical location of the PC.
Which in a house is probably fine. In an apartment where the mini PC is tucked in a closet somewhere, maybe less ideal.
That's where the second path shines. You use a separate ESP32 with a LoRa module as a serial bridge. Fifteen dollars for the board, flash it with ESPHome, and it sits wherever you want — near a window, on a bookshelf — connected back to Home Assistant over Wi-Fi. The ESP32 receives the LoRa packet from the garage and forwards it to HA as a native entity. M5Stack published a full walkthrough on their blog last year that walks through exactly this setup.
That walkthrough — thirty minute job?
For a soil moisture sensor sending data over a kilometer, yeah, they had it running in about thirty minutes. The parking garage version is even simpler because you're not reading an analog sensor, you're just watching for a digital state change on a GPIO pin. Magnetic contact sensor closes, ESP32 wakes up, transmits two bytes, goes back to sleep.
The full bill of materials for Daniel's hypothetical. Transmitter side: an ESP32 LoRa board, a magnetic contact sensor, and a battery. That's twenty to thirty dollars total. Receiver side: another ESP32 LoRa board or a USB dongle, twenty to fifty dollars depending on which route you pick. Add ten bucks for decent antennas on both ends.
Forty to eighty dollars all in. Compare that to the alternatives. Running Ethernet through three floors of concrete — you're hiring an electrician, drilling through slabs, probably violating your building's fire code in the process. Thousands of dollars and a headache. A cellular modem with a data plan? Fifteen dollars a month forever, for two bytes an hour. It's absurd.
The cellular comparison is where LoRa's value proposition becomes almost comical. You're paying a monthly subscription to transmit less data than a single emoji.
Burning power doing it. A cellular modem needs to maintain a connection to a tower, negotiate authentication, handle handshakes. A LoRa module wakes from deep sleep, transmits in under fifty milliseconds, and goes back to drawing microamps. Battery life measured in years, not days.
LoRa owns this niche completely. One sensor, far away, low data, no power outlet. Nothing else comes close on cost or power.
There's a wrinkle we haven't touched, and Daniel specifically raised it. LoRa at the physical layer is unencrypted. Anyone with another LoRa module on the same frequency and spreading factor can receive your "parking open" packet and read it.
For a parking indicator, I do not care if my neighbor knows my parking spot is open.
Neither do I. But Daniel mentioned alarming as a use case. If you're using LoRa to report whether a door is locked or a window is open, suddenly plaintext transmission matters. Someone with a fifteen dollar TTGO board could sniff your alarm state.
Which is where LoRaWAN earns its keep. AES-128 encryption built into the protocol stack.
LoRaWAN encrypts payloads end to end. Point-to-point LoRa doesn't, but you can add your own encryption layer in software — AES on the ESP32 before transmission, decryption on the receiver side. It's extra work, but for anything security-sensitive, it's mandatory. You never send lock/unlock commands or alarm states in plaintext over any radio protocol.
The duty cycle limits reinforce good security design here too. If you can only transmit for thirty six seconds per hour, you're not polling a door sensor every second. You're event-driven by necessity. Door opens, transmit. Door closes, transmit. Motion detected, transmit. That's inherently harder for an attacker to jam or spoof than a continuous polling loop.
The constraint becomes a feature. Event-driven sensors are also harder to fingerprint from outside — there's no regular beacon saying "I'm here, here's my pattern." An attacker scanning the spectrum sees occasional chirps with no predictable timing.
When you lay it all out side by side — Zigbee at ten to thirty meters with zero concrete penetration, Wi-Fi at thirty to fifty meters burning power, cellular with its monthly fees — LoRa is the only thing in the "underground parking garage" weight class. The constraints aren't bugs. Low bandwidth, duty cycle limits, infrequent transmissions — they're the design that makes the range and penetration possible in the first place.
Given all that, here's a concrete plan for anyone wanting to try the parking garage experiment. Step one, grab an ESP32 with an SX1276 LoRa module configured for eight sixty eight megahertz — that's the Israel-compliant band. Fifteen to twenty five dollars, board in hand, you're ready.
Step two is where the physics meets the floor plan. Place the receiver on the ground floor near a window that faces the garage, or better yet, next to a stairwell. That vertical air shaft is your signal's best friend.
Step three, swap the stock antenna for a half-wave dipole. Ten dollars, maybe fifteen. The gain difference versus those little coiled PCB antennas is not subtle when you're trying to punch through a hundred decibels of concrete.
Step four, configure ESPHome for event-driven reporting. No polling loops. Transmit only on state change. That keeps you comfortably inside the duty cycle limits and stretches battery life from months to years.
Step five, before you mount anything permanently, run a ping test. Put the transmitter in the garage, walk the receiver around the ground floor, and map where you get reliable packets. You might discover the sweet spot is three meters left of where you assumed.
That last step saves more headaches than all the others combined. Nothing worse than epoxying a sensor to a concrete wall and discovering it only works on Tuesdays.
For the security and alarm use cases Daniel mentioned, the calculus shifts. Point-to-point LoRa is fine for "parking open" — nobody cares. But if you're reporting door lock states or window sensor trips, you need encryption. LoRaWAN gives you AES-128 built in, no extra work. Or you can roll your own AES layer on point-to-point LoRa if you want to avoid the LoRaWAN stack.
The rule is simple. If the data would help someone decide whether to break into your house, it doesn't go over the air in plaintext.
Here's the thing that surprised me when I totaled it up. A full LoRa extension for five to ten remote sensors — garage parking indicator, gate sensor, basement water alarm, garden moisture monitors, mailbox — comes in under two hundred dollars.
The barrier was never cost. It was knowing the regulations, placing the antennas right, and having a clear integration path into Home Assistant. All three of those are solved now.
LoRa is viable, cheap, and surprisingly capable. But it's still evolving, and there's a question that's been nagging at me through this whole discussion. Israel just standardized LoRaWAN. Public networks are starting to roll out. At what point do we stop needing personal gateways at all?
That's the roaming question. Right now, if you deploy a LoRa sensor, you own both ends of the link. But if public LoRaWAN networks reach the kind of density that cellular networks have, your parking garage sensor could just connect to the nearest carrier gateway and route data to your Home Assistant through the internet. No receiver on your ground floor. No antenna placement headaches.
Walk your sensor from your garage to your office, and it just...
The infrastructure isn't there yet, but the standardization makes it possible. The question is whether telcos see enough demand to build out that density. Cellular carriers put towers everywhere because people stream video. LoRaWAN carriers are serving a market of devices that transmit twelve bytes an hour. The business case is different.
Which is why the personal gateway isn't going anywhere soon. But there's another shift coming that could change the hardware landscape entirely. LoRa at two point four gigahertz.
The global ISM band. No more choosing between eight sixty eight for Europe and nine fifteen for the US. One frequency, works everywhere, no regulatory fragmentation. A manufacturer can build one SKU and sell it globally.
The trade-off being that two point four gigahertz doesn't punch through concrete the way sub-gigahertz does. You get global simplicity but lose the very thing that makes LoRa special for underground garages.
It's a different tool for a different job. Two point four gigahertz LoRa will be great for above-ground, cross-border deployments where regulatory compliance is a headache. For Daniel's parking garage three floors down? Stick with eight sixty eight. The physics doesn't negotiate.
That's really the through-line of this whole episode. LoRa fills a specific niche so perfectly that the constraints stop feeling like limitations and start feeling like the point. Low bandwidth, infrequent transmissions, sub-gigahertz penetration. That's the formula.
Here's what I want from our listeners. If you try the parking garage experiment — or anything like it — report back. We want real-world range numbers from dense urban environments. Tel Aviv apartments, Jerusalem stone buildings, Haifa hillsides. How many floors did you punch through? Where did you put the antenna? What actually worked versus what the math predicted?
Send it to the show. We'll compile the best results. Nothing beats field data from people who actually drilled the hole and ran the test.
Now: Hilbert's daily fun fact.
Hilbert: The Basque language exhibits ergative-absolutive alignment, a grammatical structure so rare among European languages that linguists in the nineteen twenties initially classified it as a corrupted dialect of ancient Iberian. The term "ergative" itself was coined from the Greek word for "work" or "deed," reflecting how the subject of a transitive verb is marked differently from the subject of an intransitive one — a feature Basque shares with languages spoken as far away as the Horn of Africa, including several in modern Eritrea.
...right.
That was disorienting.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for making this show possible. If you enjoyed this episode, tell a friend who's tired of their Zigbee sensors dropping out two rooms away. And if you run the parking garage experiment, email us your results at show at my weird prompts dot com. We want those numbers.
I'm Herman Poppleberry.
I'm Corn. We'll catch you next time.
