I would like to have a car presence detector that detects the arrival of the car as I pull into the driveway.
I already have a motion sensor that turns up the driveway lights but I would like to have more things triggered if it is my car arriving – such as turning on more lights for longer and unlocking the front door or open the garage door.
Using the HA phone app tracking is not fast enough unless I set an uncomfortably large home zone and it has not proven to be reliable. It’s fine for detecting when someone is home but not when they pull into the driveway.
I have tried using ble_presence but the detection time can be as long as 2 minutes. I have not investigated why but I suspect a BT/WiFi radio sharing issue. In addition, spoofing a BLE beacon would be trivial and absolutely not secure.
I was thinking I could put a ESPHome device on the car itself and detect presence through simple availability. A simple test shows the device connects to my WiFi and reports its availability just as I nose to the garage door. The WiFi password plus ESPHome’s encrypted communication would provide sufficient security. Only problem is that I would need it to be powered at all times, draining the battery when the car is off.
My current thinking is to use three ESP32: one in the car and two in the garage
The one in the car is powered only when the engine is running. After booting, it would send over BLE a “I’m just waking up” message for a short period of time, then fall back to sending a “I’m present” message every second or so. This would be implemented using ESP-IDF.
One of the pair in the garage is a ESPHome device that reports the car arrival to HA. It detects the arrival of the car via a GPIO input. That ESP32 would be doing WiFi communication only.
That GPIO input is connected to a GPIO output on the second ESP32 in the garage. That second ESP32 would be doing BLE communication only. If it is not receiving the “I’m present” message, it assumes the car is either off or away. If it first receives a sequence of “I’m waking up” messages, it’s because the car was just started and no arrival is reported. If it first receives a sequence of “I’m present” messages, it’s because the car just arrived and signals the arrival of the car to the other ESP32 via the GPIO – which then forwards it to HA. That one would be implemented using ESP-IDF as well.
For security, the garage side would challenge the car side when receiving a “I’m present” message to prove its identity using pre-shared symmetrical encryption keys so the arrival of the car could not be spoofed. the garage and car BLE devices would be bench-paired which encrypts the communication.
My concern now is the unreliability and sometimes slow speed I have observed in establishing BLE connections delaying arrival detection.
You don’t need a Bluetooth connection, just detection of Bluetooth advertising. The ESPHome ble_presence component provides a binary sensor for that. In the car you need a BLE device of some kind that is powered only when the car is on, and just advertises continually. Just bear in mind it can’t distinguish between the car arriving in the driveway and the car being turned on when already in the garage.
I use this to open the garage door. Be also aware it’s not particularly secure, in my case that’s not a big issue but might be for some.
How quickly does that phone connect to your wifi on arrival?
Sometimes you can combine approaches.
I had a motion sensor set up outside my apartment door which would trigger a scan for my phones Bluetooth. Got that to around 10sec (still not fast enough for me though).
Then other methods step in for ongoing detection (ping, ble etc).
Tried that using a Blue Charms beacon but got 2+ minutes arrival detection time. If it were sub 5 secs or detected while I’m still approaching (my phone detects the beacon when the car is reaching my neighbor’s house), I could use it to trigger a secure handshake with an on-board ESP32 to confirm that it is my car and thus close the security hole.
Actually, that’s going to be my project for today: code a small BLE detector using ESP-IDF that simply turns on the on-board LED when it detects the car and see what kind of “raw” range and reaction time I get.
Have you tried turning on high accuracy mode for the Background Location Sensor?
You can set it up so that it only runs when you’re connected to your car’s bluetooth stereo (if you have one) so that it doesn’t drain your phone battery.
It detects the beacon immediately and reports the arrival of the car in less than a second. So I’m going with the hypothesis of BLE/WiFI sharing issue when using ESPHome’s ble_presence. With clear line-of-sight, it detected the car’s arrival two houses away.
If you follow the docs you shouldn’t have “sharing” issues on single core esp32’s
Use on single-core chips
On dual-core devices the WiFi component runs on core 1, while this component runs on core 0. When using this component on single core chips such as the ESP32-C3 both WiFi and ble_tracker must run on the same core, and this has been known to cause issues when connecting to WiFi. A work-around for this is to enable the tracker only while the native API is connected
Just did a test with the exact same hardware in the same location. The presence detection was 20 seconds behind the motion detection. By that time the car was fully parked, engine turned off and I was standing outside of it with the driver door closed.
In contrast, the “raw” ESP-IDF implementation without any WiFI or ESPHome had detected the car well before the motion detector.
output:
- platform: gpio
pin: GPIO02
id: led
esp32_ble_tracker:
binary_sensor:
# Presence based on MAC address
- platform: ble_presence
mac_address: AA:BB:CC:DD:EE:FF
name: "Honda Fit Presence"
on_press:
then:
- output.turn_on: led
on_release:
then:
- output.turn_off: led
Well, I’m using those on WiFi nodes as well. The IDF stack does manage co-existence of BLE and WiFi and it seems to work fine. A BLE proxy that’s doing a lot of work will certainly benefit from having an ethernet connection, but this is just for presence detection.
It could be that the OPs detection times are more driven by the advertising beacon frequency rather than the scanning frequency? You mentioned yours advertises “continuously”?
But that does not address the spoofing issue if I want to do things like open the garage door or unlock the front door. I still need to authenticate that it is my car. This shows I might be able to accomplish this using a single pair of ESP32s, one in the garage and one in the car, but it will require a custom ESPHome component to connect and handshake with the second ESP32.
There are a couple of ways I can think of to address the security hole;
Ignore it. Whether that’s acceptable depends on both your location and level of paranoia.
Implement a custom BLE device (e.g. using an ESP32 with the recently merged BLE server enhancements) that broadcasts digitally signed manufacturer-specific data. The broadcast would hash some time dependent data with a pre-shared secret key. The receiver verifies the hash using the same PSK.
Along similar lines, use active scanning and vary the secondary advertising data also using a PSK.
Pair the BLE scanner and transmitter and require a bonded connection to be established after detection. This is secure since pairing involves exchanging keys, but will introduce a delay. If service discovery can be avoided the delay could be quite short.
Unless I have a device that is powered all the time or has a RTC peripheral, I don’t think I can generate time-dependent data as the clock would reset every time it shuts down. And do the tiny ESP32 boards we use have a stable clock that could ensure good time sync over a long period of time?
I think #4 is the most appealing at the moment - I was running something similar using non-ESPHome BLE devices and it worked pretty well, but occasionally the device would fail to connect even though it had seen the other device advertising.
As regards #2, you don’t need real time. A rolling code will work just as well, just that the code needs to be included in the broadcast and the receiver needs to keep track of it.
I am planning a BLE 5 platform for the packet transport component using extended and periodic advertising which would tick all the boxes as the packet transport component already has encryption and rolling codes implemented.
Did you try this? Because the Companion app can send back to HA that your phone is connected to your home wifi very quickly. If you have a spare old router you could add an another ap if needed and it might have other benefits to you.
