Bluetooth RSSI for garage auto-open is a mess. Anyone tried UWB instead?

So I got my garage door into HA last month using BT RSSI for proximity auto-open. Absolute disaster.

First fail: I’m sitting on my couch one night and the garage door just… goes up. Check the logs — my phone’s BT signal somehow leaked all the way to the ESP32 in the garage, hit the RSSI threshold, and HA decided I was “approaching.” I’m three walls and a living room away, dude.

Second fail was worse. I pull into the driveway, stand there like an idiot for like ten seconds, door doesn’t move. Phone had gone into BT sleep or whatever, advertising interval dropped, ESP32 never saw it. Ended up grabbing the remote.

After those two I’m like… okay, RSSI just can’t draw a clean boundary in a garage. Door itself, rails, torsion spring — all metal. Multipath, reflections, the whole thing. Your threshold is either too loose (false opens) or too tight (misses you). There’s no sweet spot, you just pick your poison.

So I started digging around for alternatives. Two things caught my eye:

  • iPhones have had UWB since the 11, and some Android flagships too. No extra tag needed — the phone is the tag.

  • UWB does actual time-of-flight ranging. Not “guess the distance from signal strength” like BT. A meter is actually a meter. Metal reflections shouldn’t turn 3m into 1m… right?

So here’s what I’m sketching out:

Small UWB+BT module stuck on/near the garage door. I pull in, it TOF-ranges my phone: 3m… 2m… 1m. Bluetooth handles identity so it knows it’s actually my phone, not my neighbor’s. Data goes through an ESP BT proxy into HA. HA gets one clean fact: “His phone, 1 meter.”

Execution stays completely separate — HA decides what to do, triggers a Shelly relay on the existing opener, or talks to whatever smart opener I already have. No cloud, no cracking open the motor, no voiding warranty. Just a sensor feeding HA.

But I’m still on paper, haven’t bought anything yet. Four things I can’t figure out:

1. UWB around metal — garage door, rails, torsion spring, all of it. Does UWB actually stay accurate in that environment, or does metal still throw off the range? Anyone actually tested this?

2. iPhone UWB when asleep — phone in pocket, locked, screen off. Is the UWB radio actually broadcasting, or does it only wake up for AirTag stuff? If I’m pulling into the driveway and my phone’s asleep, will the module even see me?

3. Latency — UWB range + BT identity + ESP proxy + HA processing + relay trigger. What kind of delay are we talking? If sensing and execution are fully separated, is it still fast enough to feel instant, or am I sitting in the driveway waiting?

4. If the sensing layer is completely external, no wiring into the motor at all — would you feel like you’re missing out on the hardcore modding fun, or more like “good, my warranty is safe”?

If this whole thing has a fatal flaw I’m not seeing, feel free to roast me. I’d rather find out now than after I’ve blown money on hardware.

I’m in a somehow similar situation with you. I say “somehow” as my garage is shared (so I wouldn’t tinker with the gate module or its external radio control), my HA instance is sitting 3 concrete slabs above (or one slab with 1 m of earth on top, depending how you draw the straight line) and I have no UWB capable Android phone.
I was thinking of several approaches:

  1. Have the antenna placed somewhere outside the garage so that it can pick up signals from far away. This way even if I have to trigger the door, I would have enough time for the gate to open by the time I am in the driveway. I currently keep one extra remote on top of the reverse mirror which is probably the best in terms of accesibility and signal propagation.
  2. Have one ESPhome board control one spare remote through a relay. This way I could trigger the gate opening from far away either from my phone of an Android Auto dashboard. Basically a longer range version of the above
  3. Use a location based trigger for the above setup. Either use HA’s location tracking or, better, use Tasker set to frequent updates while charging in the car.

My problem with automated access systems is the fact that even the smallest glitch can defeat the whole purpose of having a lock. And that is a very bad idea if your garage gives access to the whole house.

I hope this info helps you in any way.

*Tasker is a very versatile automation software for Android that can interact with HA

If your car has a BT head unit, you don’t need tasker. You can simply set the HA companion app to use High Accuracy Mode when connected to your car.

Thanks for sharing this. One thing I’m wondering — with the antenna mounted outside, will the signal be weak when I’m exiting the garage? And if it’s too far away, will there be any noticeable delay?

It’s all so much easier if you simply break down each of your “wants/needs” into logic statements and then either test them or incorporate them into automations…

>with the antenna mounted outside, will the signal be weak when I’m exiting the garage?

You’re asking way to much out of what a single esp32 board can achieve by itself and thats why you need multiple of them to each read and compare distance/signal and compare it with/against multiple other devices so that it can detect an accurate picture of your location, direction of travel, last room/area you were present in, etc, etc.

Check out Espresence as well as Bermuda because either of these is more than capable of solving your current problem.

Thank you for sharing. If I really can’t find a UWB solution, then I’ll give it a try.

Why are you so dedicated to using UWB?? Last I checked its nowhere near the same level of support or available firmware/integrations… For what it’s worth to you, the overwhelming majority of people who do room presence detection in HA, they all use BT because it’s so widely supported, documented, and has help available for it and I’ve seen nothing remotely similar being available for UWB yet… BT is very reliable, very accurate down to single digit inches and it’s very good for battery preservation on your devices. You should at least give it a try before automatically putting it lower on the list for something else that’s either not used or is only used by a small niche group of people.

All this angst about UWB.

A vague thought bubble rises to the surface. Many moons ago when Apple had their BlueTooth solution so firmly locked up you couldn’t experiment with it without an expensive SDK licence and NDA, a medical vendor took a different approach for communicating with their device and their App on an iPhone. It was for a monitor to be given away for free to improve health in developing countries. Your existing phone became the display - cheap and commonplace.

Still serial protocol. Us hobbyists love it. The industry loves it. They send it over BLE, RS232, RS485, WiFi, RF, InfraRed, etc, some one way, some both, some encrypted, some not.

The vendor gave up - how dare Apple demand a cut for each and every device they gave away for free! They turned from RF BLE to ultrasonic. They modulated the speaker at frequencies past the hearing threshold of humans, in the 15kHz range and up, and then used a microphone on the other end as the receiver. Yes frequency response tapers off at those out of spec frequencies, but is still there. With careful and robust error checking integrated, the data gets through. Like the acoustic dialup handset modems of yore, just at frequencies you cannot hear. It doesn’t have to be 56K, even 50bps should do.

In your case you just need a unique beacon signal emitted that can be detected by a microphone near your garage door and won’t penetrate walls.

Use something unique like your fixed device MAC address as the encoding, make sure it has a lot of error correction in the content, and let HomeAssistant decode it and validate it against a list of known users and patterns. A token kind of thing.

Recognise as valid? Open garage, otherwise ignore.

You could even just play an MP3 file pre-recorded with the high frequency ‘token’, and listen for that.

Voice recognition at ultrasonic frequency?

Be aware this is security by obscurity - you rely on nobody else suspecting, and your dog and cat covering their ears not giving it away. Anybody else that can replay your audio can open your garage. You may be able to get around that by using the rolling code concept, using an changing encryption algorithm to encode the sound, and the reverse at the HomeAssistant end.

If the BLE code was correctly structured in your original design, you should be able to just unplug the BLE communication modules and substitute them with your Ultrasonic ones, or even a InfraRed emitter. This is where HomeAssistant has headed to in the last twelve months, making Infrared first, then RF, then BLE, and more recently Modbus, all serial protocols part of the inner virtual UART engine, universally able to be accessed by developers.

A simpler design would be to whistle a tune as you arrive on your bike. Nobody would suspect it wasn’t just a happy biker high on exercise-induced endorphins. Behind the scenes the tune is recognised by voice recognition as you, and the trigger fires.

A microphone, and the spoken “Open sesame” with careful pattern matching just for your voice?

A tiny battery powered helmet mounted Infrared emitter? When you get in visual range it detects a short burst of a continual stream being repeated over and over, enough to extract the validating token at the other end.

Just some ideas.

Start small. You’ve built your garage opener. You’ve integrated it into HomeAssistant. Maybe a few changed lines of code and a receptor module connected to the ESP32 may be the next step.

https://youtu.be/WGS029Peq7k? Happy, joyous, unafraid tinkering.

[BTW: All those burly gents at the end of the video in the background are not called Claude]

Data point from the other side, since RSSI got called “accurate down to single digit inches” above. I run Bermuda with four ESP32 proxies in an apartment and logged it against a radar for a couple of days: the phone’s room assignment flipped 8.8 times an hour, the median stay in the living room was 39 seconds, and 57% of stays were under a minute while I was mostly sitting still. A 60 second hold cut that to 0.9 flips an hour, which is the same trade you’re describing: you can make it stop lying, but only by making it slow, and a garage door needs it fast. So I’d stop hunting for a threshold and gate the door on a second signal that has nothing to do with RSSI, like a GPS zone entry within the last minute, and require both.

Yep, it’s very accurate and very stable!

I can’t speak for Bermuda because I don’t use it but, I would imagine it’s no different than any others and just like them, you have to at least try to follow best practices when deciding where to place your receiver nodes because BT signals go right through apartment walls too and secondly you absolutely 100% have to take the time to calibrate each node inorder for it to actually work correctly and not show devices location bouncing back and forth between multiple rooms constantly.

The problems you’re having sound just like everyone else’s problems who get on here and complain about how bad it works or how it doesn’t even work. You all have the same things in common and that’s not reading the manuals/instructions let alone following the instructions which go into great detail on the importance of calibration and how to do it. When all of you guys just install some firmware and don’t do the parts that require an effort and lot’s of patience then this is what the end results will be every time and you will be dissapointed when things don’t just magically work when the only thing the user does is click “Install”.

You must configure each node based on room sizes, node installation position in each room, significant interference in any particular rooms, etc, etc. Then depending on which devices you are trying to track with those BT nodes and the calibration/filtering required on them, you must remember that many devices have their own BT beacon transmission settings that may or may not require some adjustments like, all of my BT keychain beacons have the default transmission power set at max power/range and for using them to do room level presence detection I dont need them set to 50m+ transmission distance etc, etc.

BT room presence requires a lot of attention to detail and as much calibration and filtering that a person is able to configure and once that is done then you won’t have bouncing location stated or any other random stuff happening.

FYI I know for at least Espresence has its own HA Integration and an Espresence Companion app that allows you to create your own custom floor plan, configure each rooms node placement and even any potentially significant obstructions that mat interfere with the signal and then the Companion app will show where each device is inside the house and shoes it on your floorplan. If you havn’t ever usef or tried Espresence then you might just like it??

Fair challenge, and it sent me back to the data instead of the settings. I had calibrated the per-proxy offsets already, all four, from +3 to -10 dB, after measuring that they read the same phone 13 dB apart at one metre, but my five-day sample straddled the day I applied them, so 8.8 was partly uncalibrated data. Split properly it is 13.5 room changes an hour before the offsets and 7.4 after, over 156 hours: calibration cut it nearly in half, which is your point, and it still moves seven times an hour with the phone sitting on a desk, which is mine. You are right about the beacon side too, but it split by platform here: the iPhone needed only its IRK and has no transmit settings to get wrong, while on the Android the power steps below high barely moved RSSI at all, so there was no middle setting to find. ref_power and attenuation are still at defaults, so there is probably more to get.