Wouldn’t it be nice if your smart home was able to detect your presence and perform actions based on whether you are at home or not? It could be switching on the lights when you arrive, or activating the security system when you leave. There are a number of ways this can be done.
The first and most obvious question is – how do we determine if a given person is at home (or when they have left)? A few possible ways are listed below, with all having their pros and cons.
- Facial recognition (using strategically placed smart cameras)
- Geo fencing / Location (typically using an app on a phone)
- IP / MAC address tracking (e.g., of a user’s personal/computing device)
- Bluetooth / Wi-Fi scanning (you use Wi-Fi, right?)
In all cases, the real challenge is getting reliable results. Let’s run through some caveats for the abovementioned solutions, in no particular order. Smart cameras can detect the presence of a known face, or even a pet, but good ones tend to be pricey, and you may need one at every entrance, or possibly every room. IP and MAC tracking typically requires some creative configuration, it really depends on your network setup, and let’s not forget that ARP tables do time out periodically so reliability may be hit and miss. Bluetooth scanning requires that your Bluetooth is always on, not everyone likes that, or you need to carry a dedicated BLE tag, it’s potentially a decent solution provided you remember to carry your tag at all times. Geo fencing can work, but typically requires a dedicated app, and interesting things may occur if, say, you live in an area with poor 4G/5G coverage, your phone may not update your presence (assuming the use of GPS) until you get inside and connect to the Wi-Fi, and by that time you would have really liked to have those lights on already… Note that this is by no means a complete list, there are other possible solutions, maybe a LoRa gateway and a battery powered GPS tag.. but that’s for another time.
So, let’s explore Wi-Fi scanning. It’s also not without its pros and cons, but with some care taken to cover the basic pitfalls workable results can be achieved. Later we can get into the specific setup used for this experiment.
How can we detect a Wi-Fi device?
At a basic level, unconnected Wi-Fi clients scan and probe for known networks, and connected Wi-Fi clients pass data (when they are not sleeping that is).
Connected clients tend to be a little easier to catch, they are after all connected to our Wi-Fi system, so it’s a case of logging in to the management page and seeing which devices are connected. Let’s take a Meraki (cloud managed) Wi-Fi solution as an example, with the Meraki Dashboard API you can easily retrieve the status of a client. In effect, this is very similar to tracking a device by MAC address.
Now is probably a good time to talk about randomized MAC addresses.
The idea of randomizing a device MAC address has become quite commonplace, think of it as a game of cops and robbers, between the vendors providing device tracking solutions, and the vendors providing consumer devices – thereby “protecting your privacy”. Modern devices have MAC randomization turned on by default. Meaning that, when probing for a Wi-Fi network a device can use a different MAC address each time, and the same when connecting to a Wi-Fi network. This of course breaks (to some extent) solutions that utilize the MAC address for any sort of location/presence services as well as for authentication. For the smart home this is a little easier to deal with, as we tend to know the users and their devices, so MAC randomization for the home SSID can simply be disabled on the phone/tablet.
Power saving.
Another thing to consider are power saving and sleep functions. Most devices have some sort of power saving mode which may try to limit battery usage by putting the device to sleep. A sleeping device may not be detected and may result in a false positive (or false negative depending on your point of view), causing the home automation to assume the user has left. Battery saving is part of all modern Wi-Fi standards and there is not much that can be done about it, but, what can be done is disabling various advanced AI/ML battery saving features that try to determine when the actual user is sleeping, and put the device into a deep sleep during that time. Here are some examples from a Galaxy S21 and Oppo Reno3.
This battery saving part may take some fiddling to get right, and really depends on what the desired outcome is. For example, do you care if the home automation determines the user to be away when they are in fact sleeping? Maybe you want the security system to be enabled when no one is at home, in this case maybe enabling it when everyone is asleep is not such a bad thing? What about turning on the lights when you come home, or indeed wake up and check your phone… this may require some additional consideration.
The graph below shows the impact of the advanced battery saving. The X-axis is a timeline and the Y-axis depicts total number of minutes since a device was last seen, the two large spikes show the phone has determined the optimum time for a deep sleep is from just after midnight until just after 6am (using Sleep standby optimization). This is just one example from a single device (Oppo Reno 3), each device may behave differently, as may each user.
What about devices that are present but not connected to the Wi-Fi?
There are a few points to consider here. Maybe the device has just entered the home and has simply not connected to the Wi-Fi yet. Typically, this would be a transient state, but could also mean something is preventing the device from associating. It could be that the device Wi-Fi is simply switched off (in which case it will not be possible to detect the device at all).
Maybe there are multiple Wi-Fi networks in the house and the device connects to a different network. Or maybe, the system doing the scanning is not the same system that is providing the Wi-Fi… wait what? This last case is exactly how the test lab for this experiment is configured.
The setup.
For this solution there is a single Meraki AP (MR33) using the dedicated RF management radio for Wi-Fi telemetry. Client serving radios are disabled on the Meraki AP as the Wi-Fi for the home is provided by a different set of APs, effectively making this an overlay scanning solution. There is an option to detect devices that are either Associated or Visible, Visible is the correct selection here as the Meraki system will not know about associated clients (as it is not advertising any SSIDs). Lastly, device MAC addresses are defined to filter the output to only what is required.
The results are published to a separate MQTT broker using the MQTT feature found under IoT Radio Settings, publish frequency is configured for 5 seconds (for higher resolution), security is disabled as this is just an experiment. MQTT QoS settings determine the level of reliability of the streamed messages, QoS level 0 is a fire and forget model and is sufficient for this exercise. Various message fields can be included in the telemetry, the key fields for this home automation are the device MAC and the Timestamp of when the device was last seen – required for calculating if the device is present or not.
The rest of the setup.
MQTT is a publish/subscribe messaging protocol and requires a dedicated broker service to receive and pass along the messages. The open-source Eclipse Mosquito is used here, it is available (amongst others) as a Docker image and can be deployed as a container with basic configuration, with a home NAS serving as the Docker host.
To verify the messages being sent from the Meraki AP (note: from the AP not the Meraki cloud) we can use an MQTT browser, in this case the excellent MQTT Explorer, pointing it to the broker.
The two configured MAC addresses are being reported correctly, along with the additional message fields e.g., RSSI of the device. The next step is to subscribe to the MQTT broker from our home automation system. Here we have openHAB running on a dedicated Raspberry PI. openHAB is a “technology agnostic home automation platform” and provides deep customization options for interactions between smart devices, it uses a concept of Things, Channels, and Items to enable interaction between the various components.
For openHAB to interact with MQTT an MQTT Broker Thing is required, functioning as a logical bridge to the Eclipse Mosquito broker, followed by Things to represent the devices being tracked (mapped to the MQTT Broker bridge), then the published MQTT topics are the Channels to which we can link Items (i.e., the message fields sent by the Meraki AP).
Once the Items are created in openHAB the received data can be used to configure various rules, actions, and visualizations as needed, and of course trigger events to external systems. Two use cases were presented at the start – switching on the lights when a device is detected, and the security system when it is not, these actions can be triggered using a variety of possible methods including API calls (depending on supported capabilities of the particular system). The details of these interactions, as well as openHAB configuration are well outside the scope of this article, the purpose here was to show how to get streaming telemetry data from the Meraki system into the home automation system using MQTT.
In summary then, presence detection is tricky to do reliably, and can get complicated pretty fast, but decent results can be achieved with some understanding of the caveats (and some determination).
Some additional points.
The sensor AP will not report on clients that it does not detect, this is where the Timestamp becomes important to calculate when a given device was last seen. The specific duration between the last time a device was detected and when it is determined to be away can (and should) be fine-tuned to the specific purpose, keeping in mind the previously mentioned points about battery saving.
Location of the detecting AP is important to ensure that devices can be detected throughout the whole house. In this case a single (but strategically placed) AP is sufficient to detect clients in a two-level home, with the actual Wi-Fi coverage being provided by another 2 APs. Additional sensor APs may be required depending on the size of the house / deployment.