logo elektroda
logo elektroda
X
logo elektroda

Superior detector with ESP8266 and OLED SSD1306

szdom  47 7320 Cool? (+36)
📢 Listen (AI):

TL;DR

  • An ESP8266-based “Supervisor detector” with an SSD1306 OLED monitors nearby Wi‑Fi phones by matching their MAC addresses.
  • It listens for probe packets from phones that lose Wi‑Fi connection, then lights an LED for a few seconds and shows the assigned name on the display.
  • The code was adapted from Ricardo Oliveira’s Friend Detector project and is meant for building automation, including future IR control of an air conditioner.
  • In testing, it detected frames at about 80 m in a radio-polluted industrial environment and worked reliably enough to greet a supervisor by name.
  • The current algorithm signals only one active device nearby at a time, and the enclosure and wiring are only quick protective prototypes.
Generated by the language model.
Supervisor detector with a green LED and an OLED display showing Słucham....
I would like to present a recently created contraption.
I gave it a working name Supervisor detector.
The ESP8266 chip and the SSD1306 OLED display are used here.
I`m in a hurry to explain the principle of operation.
The WIFI network is widely used, we use it at home, at work, in a cafe.
Very often, as I have noticed, people do not turn off WIFI on their phone, either because of laziness or ignorance.
And when phones lose connection to the network, they become quite "talkative" and periodically start desperate attempts to find a known WIFI network to connect to.
They do this by sending packets containing, among others: their MAC address and this feature was used in the presented device.
We have a defined list of MAC addresses in the table that we want to monitor and when one appears within the range of our ESP,
we have signaling in the form of lighting the LED for a few seconds and displaying the name assigned to a given MAC address on the display.
The algorithm is quite primitive, it only signals 1 active device nearby at a time, but it works great for the intended purposes.
The listening library is not my own, a Ricardo Oliveira project called Friend Detector was used here.
https://github.com/RicardoOliveira/FriendDetector
I made changes to adapt the code to my requirements.
It is true that the application is intended to be part of a building automation project and serve other purposes, i.e. after detecting the MAC address we want, it is supposed to turn on the air conditioner in the heating mode using the IR diode before the user even enters the house.
But at the moment I`m testing the system at work and it works great as a supervisor detector ;)
While writing the post, the LED light came on and I was able to prepare for my supervisor`s visit ;-) ) (greet him by name without even seeing him yet).
I noticed that the system can catch frames at a distance of about 80 m and in a quite radio-polluted industrial environment where a lot of machines work.
The casing is not very beautiful, but it was made quickly to protect the device so that bystanders would not accidentally short circuit it.
I don`t have a diagram because it is a manual connection of the OLED display and LED to the ESP.
Below is a video of the device in operation.



Source codes attached.
Attachments:
  • esppl_functions.h (9.35 KB) You must be logged in to download this attachment.
  • main.cpp (3.98 KB) You must be logged in to download this attachment.
  • esppl_struct.h (4.62 KB) You must be logged in to download this attachment.

About Author
szdom wrote 37 posts with rating 43 . Live in city Suwałki. Been with us since 2004 year.

Comments

gulson 05 Feb 2024 18:25

Incredible! Let me tell you, there is a deposit for a device that could be normally sold, for analyzing the presence of people, detecting, and notifying. Of course, it would support a certain number of... [Read more]

Kkuba79 05 Feb 2024 19:11

A very interesting and clever device. From what I can see on my phone, the MAC address is generated randomly, which may make it difficult to identify the user. [Read more]

analog_6 05 Feb 2024 21:13

Some time ago, 15 years ago, my relative and his friend in the USA had a company that offered billboards and other marketing attention grabbers that scanned the environment for mobile devices with BT enabled.... [Read more]

gulson 05 Feb 2024 21:16

There could be many problems, including the worst - reservations regarding privacy and the need to obtain prior consent. Although no one cared 15 years ago, so maybe they failed on some technicality. [Read more]

Anonymous 05 Feb 2024 21:18

If the "Randomized MAC" function is enabled, there may be a problem with "targeting". In mine it is turned on ;) [Read more]

krzbor 05 Feb 2024 23:15

It seemed to me that the device was scanning for networks. Only when it finds a network saved in itself with the right to establish a connection does it become "talkative". In other words, if a device... [Read more]

Sam Sung 06 Feb 2024 00:44

What you described is passive scanning. Smartphones perform active scanning by sending a frame cyclically probe request , in which - in addition to your own identifier - there is also a place for a... [Read more]

analog_6 06 Feb 2024 01:31

Otherwise, it would not be possible to connect to a network that has broadcasting disabled. [Read more]

pixel7 06 Feb 2024 06:01

It is worth adding a buzzer to the system. Now you have to constantly watch the display or diode. [Read more]

szdom 06 Feb 2024 07:36

My observations show that random MAC is for different WiFi networks. If you connected to one network, e.g. at home, the phone will report the same "randomized" MAC address to a specific network. I don`t... [Read more]

pixel7 06 Feb 2024 08:30

This is actually true, otherwise the pool of addresses reserved on the router would increase. And with poor coverage, when the phone would lose and find (new MAC) the network, another IP would be blocked.... [Read more]

szdom 06 Feb 2024 10:02

If the phone loses coverage, it starts sending probe request frames and when it finds itself in the network coverage again, it is renegotiated on the DHCP server and the same IP address is granted for... [Read more]

Anonymous 06 Feb 2024 10:21

If smartphones are not restarted, enabling randomization may not actually be effective. In my opinion, in the name of generally understood security, the smartphone should be restarted once a day. The MAC... [Read more]

pixel7 06 Feb 2024 11:50

I can set any time, I know. But I meant 20 attempts/sec. Unless we know the local MACs, and every stranger is him. [Read more]

szdom 06 Feb 2024 12:01

I wouldn s skills ;-) )) Depending on age, it`s sometimes good to know where to find the slider to turn WiFi on/off. [Read more]

analog_6 06 Feb 2024 15:04

Most supervisors at some level know quite precisely how much time employees actually work and how much time they spend chatting, browsing the Internet or doing private matters. They just tolerate it for... [Read more]

krzbor 06 Feb 2024 15:48

Thanks for the clarification. I had previously read that the default mode for WiFi is passive mode and I thought this was used on smartphones. While researching the topic, I came across the website ... [Read more]

TechEkspert 06 Feb 2024 19:49

Do BT wristbands and watches have MAC randomization? BT listening can also provide a lot of information, e.g. BT headphones or even cars. [Read more]

jarekgol 06 Feb 2024 20:46

Beautiful block :) Some time ago I looked at the DHCP server logs to check whether the management had reached the plant. By the way, assuming you are on the same Wi-Fi as the president, it would probably... [Read more]

FAQ

TL;DR: This ESP8266 detector spotted phones from over 100 m, and one expert note says "probe request" frames expose nearby devices before they join Wi‑Fi. It helps makers build simple OLED presence alerts, but MAC randomization, Android scanning settings, and unstable RSSI limit reliable user identification and distance estimates. [#20986796]

Why this matters: It shows how a very small ESP8266 + SSD1306 build can detect nearby phones early enough for alerts or automation, while also exposing real limits in privacy, accuracy, and repeatability.

Method What it detects Range or scope from thread Main limitation
Probe-request sniffing on ESP8266 Nearby phone activity About 80 m, sometimes over 100 m Randomized MACs and noisy RSSI
Ping on local network Devices already on LAN Up to 254 IPs scanned Slower; needs network attachment
Wi‑Fi controller logs/script Last known AP association Whole site with several buildings Not fully real-time

Key insight: Probe-request detection works best as an early presence trigger, not as secure identification or ranging. The thread repeatedly shows that randomized MACs, reflections, and phone settings can change what the ESP8266 sees.

Quick Facts

  • The author reported reliable frame capture at about 80 m in an industrial environment with heavy radio noise, using an ESP8266 and SSD1306 OLED. [#20946036]
  • Later testing showed some phones were detected from over 100 m, even through walls, which confirms high sensitivity but weak location precision. [#20986796]
  • Android scan timing quoted in the thread is 60 s for the first 3 scans when stationary, then 180 s; in high mobility it is 20 s for the first 3 scans, then 60 s. [#20949726]
  • The OLED was expanded to show signal strength as 10 dashes, and the author observed jumps from 4 to 9 bars without device movement. [#20986796]
  • A ping-based alternative tried 50 addresses in parallel, then fell back to serial scanning across 254 IPs, which made full scans noticeably slower. [#20965761]

How does an ESP8266 in promiscuous mode detect nearby phones by listening for Wi-Fi probe request frames?

It detects phones by passively sniffing management traffic instead of joining a network. The ESP8266 runs in promiscuous mode, watches the air for probe request frames, compares observed MAC addresses with a stored list, then lights an LED and shows the assigned name on the SSD1306 for a few seconds. In the thread, that simple method worked at about 80 m and only signaled one active nearby device at a time. [#20946036]

What is a Wi-Fi probe request frame, and what information from a phone can it reveal to a detector like this?

A Wi‑Fi probe request frame is what makes this detector useful, because phones send it while actively searching for networks. "Wi‑Fi probe request frame" is a management frame that asks nearby access points about available networks, carrying the sender address and sometimes remembered SSID data. In the thread, it was described as containing the phone’s MAC address and a place for SSIDs of networks the smartphone had connected to before. That gives the ESP8266 a basis for presence detection without association. [#20947190]

What is MAC randomization on Android and iPhone, and how does it affect identifying a specific user with an ESP8266 detector?

MAC randomization changes the address a phone presents, which makes stable user identification harder. Several posters noted that if Randomized MAC is enabled, “targeting” can fail, and one later cited that iOS 8 and Android 8 already randomized probe requests while Android 10 enabled randomized MAC by default for network connections. In practice, the detector still worked on some devices, but reliability depended on phone model, OS behavior, and per-network settings. [#20948517]

Why can a phone still be detected over Wi-Fi even when the Wi-Fi toggle is set to OFF on Android?

Android can still emit detectable Wi‑Fi traffic when location-related scanning remains active. The author observed several frames from a phone in the morning with Wi‑Fi switched OFF, then later confirmed that turning off location accuracy stopped the phone from appearing in the detector. That means the Wi‑Fi toggle alone may not fully silence background scanning on some Android setups. [#20986796]

How often do smartphones send Wi-Fi scanning frames when stationary versus moving, and how does that change detection reliability?

They scan less often when stationary and more often when moving, so moving phones are easier to catch quickly. A source quoted in the thread gives low-mobility intervals of 60 seconds for the first 3 scans and 180 seconds after that, while high-mobility intervals are 20 seconds for the first 3 scans and 60 seconds after. Longer gaps make presence detection more bursty and can delay alerts by minutes. [#20949726]

Why is RSSI on ESP8266 too unstable to estimate distance accurately from a phone or smartwatch?

RSSI is too unstable because reflections, body position, walls, and radio clutter change signal strength without changing distance. The author expanded the OLED to show 10 dashes and saw the same phone jump from 4 to 9 bars while staying in a known place. He also reported alarms from a person about 100 m away behind several walls, which shows why RSSI is fine for rough presence but poor for ranging. [#20986796]

How can I switch an ESP8266 from Wi-Fi listening mode back to normal STA transmit mode and then return to sniffing mode again?

The thread does not give a verified STA-to-sniffer switch-back routine. It only shows the sniffing entry block with wifi_station_disconnect(), wifi_set_opmode(STATION_MODE), channel selection, callback registration, and promiscuous enable, then asks whether rerunning that code restores listening mode. A practical thread-based test path is: 1. enter sniffing with that block, 2. perform normal STA work, 3. rerun the block and confirm frames reappear. [#20949167]

What is the difference between active Wi-Fi scanning and passive Wi-Fi scanning on smartphones?

Active scanning sends frames; passive scanning mainly listens for network beacons. One poster first assumed phones stayed passive, but another corrected that smartphones actively scan by periodically sending probe request frames. That distinction matters because an ESP8266 sniffer can detect active scan traffic from phones that are not yet connected to any access point. [#20947190]

How does ESP8266 detection by probe requests compare with pinging devices on the local network for presence detection?

Probe-request sniffing detects nearby phones before they even join the LAN, while ping detects only devices already on the local network. In the thread, a ping-based build had to scan up to 254 addresses and could not keep 50 parallel pings working reliably, so it fell back to serial checks. The ESP8266 probe method gives earlier presence hints, but it depends on Wi‑Fi activity and can miss devices with quiet or randomized behavior. [#20965761]

How would I adapt a FriendDetector-style project from ESP8266 to ESP32 with an SSD1306 OLED display?

The thread’s direct guidance is to replace the ESP8266-specific libraries and keep the same overall idea. The author explicitly said the libraries used there were for ESP8266 and that, after replacing the libraries, ESP32 should also work. The OLED side stays simple because the project used manual wiring to the SSD1306 and no custom schematic was required in the post. [#20949413]

What are the privacy and legal issues of tracking people by Wi-Fi or Bluetooth MAC addresses in a workplace or public space?

The main issues are consent, privacy, and the fact that MAC data is not suitable for security decisions. One participant said MAC is public and unencrypted, so it cannot serve security purposes, while others warned that prior consent may be required and that such profiling may not be allowed in Europe without it. The thread treats presence detection as technically easy but legally sensitive in workplaces and public-facing systems. [#20946939]

How can I improve notifications in a MAC detector project beyond an LED and OLED, for example with a buzzer or remote alert?

Add an audible buzzer or forward alerts to another system. One poster suggested a buzzer because an LED and OLED require constant visual attention, and the author accepted that as a valid upgrade. The same thread also mentions broader automation, such as using detection to trigger air conditioning before a user reaches the house, which shows how local alerts can become remote or automated actions. [#20947256]

Why do some phones with randomized MAC addresses still appear with the same IP and MAC in router DHCP logs for a known network?

Some phones seem to keep one stable randomized MAC per known network, so DHCP keeps reissuing the same lease. The author observed that phones with randomization enabled still received the same IP and appeared under the same MAC in his logs, and he explained that after losing coverage the phone renegotiated with DHCP using that unchanged MAC. That behavior is not universal, but it explains why “randomized” devices can still look stable on one saved SSID. [#20947469]

How can Google location accuracy, Wi-Fi scanning, and Bluetooth scanning settings influence unwanted probe traffic from a smartphone?

Those settings can keep radios active enough to generate traffic even when users think they are off. In the thread, the phone stopped showing up only after location accuracy was disabled, and another poster recommended turning off Wi‑Fi and Bluetooth scanning inside the location menu and testing GPS-only mode. That makes these settings a practical checklist when a phone keeps leaking probe traffic. [#20986796]

What happens to Bluetooth devices like watches, wristbands, headphones, or cars with MAC randomization, and how useful are they for presence detection?

The thread does not confirm a stable answer for Bluetooth randomization on watches, bands, headphones, or cars. It only raises the question and notes that Bluetooth listening could reveal useful presence clues from devices such as headphones and even vehicles. So, in this discussion, Bluetooth is presented as promising for richer detection, but its reliability under randomization remains unverified. [#20948385]
Generated by the language model.
%}