This article will cover multiple technologies for detecting people and pets in places. It involves bluetooth, esp32 microcontroller/SOC, home assistant, MQTT, and mmWave radar sensors.
The smart home is an ever evolving, ‘living and breathing’ thing. Or at least, it should be. New technologies add functionality previously never thought possible. I remember tinkering with x10 systems years ago when I was a teenager living at my parents house. I had a motion detector at the back door that would turn on my bedroom light when the door was opened. Things have evolved tremendously over the years but my passion for home automation has grown right along with them.
Those early motion sensors were generally “PIR” or passive infrared radar which works by sensing the difference in temperature of a living moving thing, generally humans, though some can be sensitive enough to pick up pets. While generally quick to pick up motion – they come with many drawbacks, as anyone who’s ever had the lights go out on them in a public restroom that uses a PIR switch can attest.
Enter mmWave radar. Radio frequencies so small that they’re wavelengths are measured in millimeters. They come in multiple ‘bands’ starting as low as a few 2-3ghz upwards to 60+ghz. There are advantages and disadvantages to each. While the lower end wins in distance detected, its less sensitive about what it detects. Whereas the higher frequencies can detect very minute movements like heartbeat and respiratory rate, they must be relatively close to the intended detection subject.
The speed at which these sensors pick up is mostly on par with PIR if not sometimes ever so slightly slower, and are typically acceptable as replacement in kind for applications that previously used PIR. The added benefit of greater sensitivity can lead to less false readings when someone is still present but not moving enough to be picked up by sensors like PIR.
I implemented two EPL (everything presence lite) units that operate in the 24ghz band, utilizing a LD2450 sensor on top of an ESP32 all in a handy lil case ready to be mounted. One sits happily above the fireplace on the back wall of our family room while the other sits over my shoulder on the back wall of the man cave beside my desk. Both are programmed to turn lights on when they sense presence and off again when they no longer sense presence + a grace period to keep the lights on just in case we sit a little too still watching a movie/working at the desk. This works out most of the time, I’ve adjusted the grace period from 5 to 10 minutes and that seemed to alleviate issues with the lights going off when we did’t intend them to.
For my office/mancave I also use a door/window sensor that is programmed to trigger the lights to come on, an homage to my x10 system…ahhhh, if it could see how far we’ve come, I’d like to think it would be proud of the journey we began together….I die grass.
Recently came across a youtubes video discussing ESPresence, a project that uses ESP32 devices as bluetooth proxies to help monitor for the bluetooth beacon of your phone/tablet/smartwatch/bluetooth tag (tile). I fell in love with the idea of knowing not only whether a particular family member was home or away but more specifically where they (or at least their devices) are within the home at any given time. Ordered a pack of 10 esp32-c3-super mini’s, some 1amp power blocks, usba>usbc cables/adapters and downloaded a 3d print file to start making cases for the esp32’s.
While I was waiting to receive everything I found a similar project called ‘Bermuda BLE Trilateration‘. It worked very similar to ESPresence with one very specific benefit – you could add some simple code to your existing ESP32 based projects and utilize them as bluetooth beacon without the need for a dedicated device per room/zone. Remember the EPL’s mentioned above…based on ESP32…now the mancave and family room are covered without the need for additional devices!
As I began to put everything together I struggled. I was growing familiar with ESPHome and the ESPHome builder tool in homeassistant. I worked out some snafu’s as I went. Learn from my mistake if you follow this way – Chrome browser makes all the difference – even over chromium based browsers like brave. The smoothest time I had with any of the web based tools for esp programming was on my macbook pro with a thunderbolt3 cable, using Chrome. I had mixed luck on my apple silicone m4 mini with USBA > USBC cables/adapters. I found if I reset the site permissions between devices, reloaded the page, then connected the new device – things seemed to work fairly consistently. Sometimes the ESP32 wouldn’t be recognized and I’d have to do a quick reset of the device and occasionally I’d have to hold the BOOT button while it began to write then I could release. Once I worked out a workflow I was able to juggle between devices quickly enough, getting the process down to about 2-3 minutes per device to flash esphome, join it to wifi, and push the updated yaml (yet another markup language) config file to the device OTA (over the air) via wifi. It would have been faster to push the updated yaml to the device by direct connection since I already had it plugged in to the computer, but this was as much proof of concept to make sure OTA features were working as intended. This would come into play once the devices are deployed in the real world – I’ll still be able to update/maintain/change as needed without having to bring them back to the computer to program by direct cabled connection.
Bermuda BLE’s documentation suggested adding bluetooth proxy feature support to existing esp32 devices was as simple as adding a single line to the yaml and writing it to the device at which point I guess its supposed to magically show up in Bermuda, ready to track bluetooth beacons it sees. In practice that method only worked for me with the EPL’s. While I could get the C3-Super Mini’s recognized into ESPHome, Bermuda never would see them for the purpose of proxying bluetooth beacons. Did some more digging and found a guide that suggested a yaml package that was designed to maximize support for Bermuda proxy use:
packages:
Bermuda.esp32: github://agittins/bermuda-proxies/packages/bermuda-proxy-esp32-c3-minimal.yamlThat was the key that had my C3 devices start showing up in Bermuda. Once I added that snippet into the yaml for each device, recompiled, and installed - et voila!Next hurdle was IRK (identity resolving key) #’s. Many modern bluetooth devices use randomized MAC addresses to protect the real identity of devices and users. This is also true of MAC addresses for wifi on these devices. While this is fantastic for security – its a NIGHTMARE when trying to monitor a device that may change its ID over time. So we need a more persistent identifier that won’t change over time. Enter the IRK. The IRK, as I understand is essentially a private key used with a random number that generates RPA (resolvable public address) which is the randomized MAC. Thats probably a gross oversimplification, but its a relatively new concept, and that is my present level of knowledge on the matter. Found a potentially helpful article that suggested a project that could act as a sniffer to pull IRK #’s from devices without the use of keychain access. While I didn’t need it at this point, its good to have options and I thought it worth noting here.
Armed with the real bluetooth MAC address, I opened ‘keychain access’ on my mac, under default keychains > iCloud…I searched for ‘bluetooth’ in the search field top right. That brought up about 8-10 entries with random characters. Clicking through each I looked at the header to see if I recognized any MAC addresses. When I found the one that corresponded to the device I was interested in tracking, in my case a process I repeated thrice for my phone, watch, and ipad respectively, I would open that entry, click the checkbox for “show password” at the bottom, click to place cursor in the resulting xml line, command + A to select all, then copy/paste the contents into a text document. Most of the resulting paste contents can be ignored, we’re looking for the “remote irk”, a base64 encoded key that I saved for each respective device. I followed a helpful guide here:
Once I’d assembled my list of device IRK’s I went back into home assistant where I’d installed Bermuda BLE from the HACS repository, and added the corresponding integration as well as the “Private BLE Device” integration. Within this integration I clicked “Add Device”, entering the IRK for each device. Once recognized, the name of the device was updated to something more easily identifiable like ‘jeffs-iphone-ble’. I chose unique names to avoid conflict with the iCloud integration I use that already leaves me with device id’s for most devices through the findmy system which is helpful for presence at the home versus away level. Upon renaming, home assistant confirms the change as multiple entities will be updated to reflect the new name.
I created a card on my dashboard to test things out. First pass I only added my phone and watch. Sure enough I was able to roam throughout the house into each ‘zone’ and it did a pretty solid job of updating as I came into each new area. The entity being monitored on the card is ‘jeff-iphone-ble Area’. The watch seemed to be nearly immediate, taking at most an average of 30 seconds before updating. The iphone would typically update within another minute, sometimes 3-5 minutes. I went into this knowing that the speed at which it associates with each new zone was not going to be reliably fast enough to trigger events based on, such as lights on once it associates with a respective area.
Kudos to Alan Byrne, one of the first youtubers I found discussing the Bermuda project. I followed the guide on his website to get started and found it quite helpful – check it out here. He also shared a snippet of his code that he uses to combines room sensors as well as device trackers for more reliable logic for presence automations.
Another feature I’m looking forward to implementing in time with the functionality afforded by Bermuda, is location dependent dashboards. Presently I have one large dashboard with all of my rooms and their respective devices/sensors/etc associated therein. As my home automation network grows with additional devices and integrations, that can become cumbersome at best. Having to scroll through other rooms/areas to get to the section pertaining to the room I’m in isn’t very convenient. Now with location dependent dashboards I can make the pertinent section front and center without extra work – presenting the respective card for the room I’m in at that moment. Mind you I have yet to implement this, but functionality I intend to add now that the base system seems to be functioning.
Several youtubers mentioned tagging their pets with bluetooth beacons like the tile or other eddystone type trackers. I’ll be looking into this further as I’d love to extend presence sensing to our pets so the room doesn’t go dark if one of the pups is still there; or tracking the activity of the cat throughout the day to see where all she gets into.
tl;dr: Utilizing multiple sensors/technologies works like layers to increase the reliability of detecting who is where within the home for the sake of automation.
Leave a Reply