logo elektroda
logo elektroda
X
logo elektroda

Superior detector with ESP8266 and OLED SSD1306

szdom 7320 47

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.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
📢 Listen (AI):
  • 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.

    Cool? Ranking DIY
    About Author
    szdom
    Level 12  
    Offline 
    szdom wrote 37 posts with rating 43. Live in city Suwałki. Been with us since 2004 year.
  • ADVERTISEMENT
  • #2 20946555
    gulson
    System Administrator
    Posts: 29347
    Help: 148
    Rate: 6026
    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 MAC addresses, which could be easily entered by the user.
    MAC, of course, is not an encrypted data and, as you can see, it is publicly available, so it cannot be used for any security purposes.
    But simple detection of the presence of people...
    What if I added bluetooth in parallel? To think about!
    Contact me via Parcel Locker and I will send you a small gift that will be useful for future projects. ;)
  • #3 20946670
    Kkuba79
    Level 13  
    Posts: 49
    Rate: 4
    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.
  • #4 20946935
    analog_6
    Level 16  
    Posts: 319
    Help: 6
    Rate: 144
    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. It was supposed to resemble the functionality known from the movie "Minority Report", i.e. active dedicated advertising. They did it for some time and even had some contracts with J&J, but it didn`t take off. I don`t know why they gave up. Maybe because the law has started to keep up with the news and generally does not allow such practices. Unless the person being tracked gives consent. It is not without reason that various companies offer various services and applications for free, and at the same time force you to sign agreements on profiling, tracking, etc. People who are aware of such consents do not give such consents and, at least in Europe, it is not legally allowed to collect and process information about such people.
  • #5 20946939
    gulson
    System Administrator
    Posts: 29347
    Help: 148
    Rate: 6026
    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.
  • #6 20946944
    Anonymous
    Level 1  
  • #7 20947126
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    szdom wrote:
    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.

    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 is not registered on a given WiFi network, it should not communicate.
  • #8 20947190
    Sam Sung
    Level 33  
    Posts: 2013
    Help: 227
    Rate: 583
    krzbor wrote:
    szdom wrote:
    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.

    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 is not registered on a given WiFi network, it should not communicate.
    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 list of SSIDs of the networks to which the smartphone has previously connected.
    https://www.rfwireless-world.com/Terminology/WLAN-probe-request-and-response-frame.html
    https://blog.spacehuhn.com/probe-request
    https://niebezpiecznik.pl/post/kamery-w-zabce...warz-klientow-nie-motyw-w-zabce-i-nie-motywe/
  • ADVERTISEMENT
  • #9 20947204
    analog_6
    Level 16  
    Posts: 319
    Help: 6
    Rate: 144
    Otherwise, it would not be possible to connect to a network that has broadcasting disabled.
  • #10 20947256
    pixel7
    Level 24  
    Posts: 656
    Help: 53
    Rate: 160
    It is worth adding a buzzer to the system. Now you have to constantly watch the display or diode.
  • ADVERTISEMENT
  • #11 20947299
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    Quote:
    If the "Randomized MAC" function is enabled, there may be a problem with "tracking". In mine it is turned on ;)

    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 know if this is standard, but I noticed in my network that phones with randomization turned on always get the same IP address and are visible in the logs at the same MAC address.

    Quote:
    It is worth adding a buzzer to the system. Now you have to constantly watch the display or diode.

    This is an idea. Although at the moment, when it`s on the desk next to the monitor, there`s no way I wouldn`t notice it ;)
  • #12 20947345
    pixel7
    Level 24  
    Posts: 656
    Help: 53
    Rate: 160
    szdom wrote:
    anyway, they always get the same IP address and are visible in the logs at the same MAC address.


    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. I wonder how routers react to this?
  • #13 20947469
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    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 a new period (because the MAC has not changed).
  • #14 20947496
    Anonymous
    Level 1  
  • ADVERTISEMENT
  • #15 20947614
    pixel7
    Level 24  
    Posts: 656
    Help: 53
    Rate: 160
    khoam wrote:
    Corporate networks usually do not use long DHCP lease time,


    I can set any time, I know. But I meant 20 attempts/sec.

    khoam wrote:
    A supervisor can use this before inspecting the office


    Unless we know the local MACs, and every stranger is him.
  • #16 20947632
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    khoam wrote:
    A supervisor can use this before inspecting the office

    I wouldn`t be that optimistic about the supervisor`s skills ;-) ))
    Depending on age, it`s sometimes good to know where to find the slider to turn WiFi on/off.
  • #17 20947921
    analog_6
    Level 16  
    Posts: 319
    Help: 6
    Rate: 144
    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 various reasons.
    And so they pay according to the value of the work performed and the usefulness, regardless of how clever the employee thinks he is :)
  • #18 20947991
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    Sam Sung wrote:
    What you described is passive scanning. Smartphones perform active scanning by periodically sending a probe request frame, which - in addition to its own identifier - also contains a list of SSIDs of the networks to which the smartphone has previously connected.

    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 Link , in which user "heddha" (second answer) explained it quite well.
  • #19 20948385
    TechEkspert
    Editor
    Posts: 7165
    Help: 16
    Rate: 5536
    Do BT wristbands and watches have MAC randomization? BT listening can also provide a lot of information, e.g. BT headphones or even cars.
  • #20 20948514
    jarekgol
    Level 40  
    Posts: 5147
    Help: 642
    Rate: 1137
    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 be possible to write something similar on Android and have the notification immediately in your pocket.
  • #21 20948517
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    I came across an interesting website: Link , and in it a picture:
    Timeline diagram of MAC address randomization implementation by iOS and Android systems
    It shows that iOS8 and Android 8 already had random MACs in the probe request. In 2019 (Android 10), random MAC addresses were also enabled by default when connecting to the network. So the question arises - how does the "detector" work - the boss probably has a very old phone :)
  • #22 20948530
    jarekgol
    Level 40  
    Posts: 5147
    Help: 642
    Rate: 1137
    And what about the fact that a given manufacturer has an allocated pool of Macs? And I wonder what is the chance in larger chains that the Macs will clash after the draw?
  • #23 20948673
    analog_6
    Level 16  
    Posts: 319
    Help: 6
    Rate: 144
    Conflicts on the Internet are nothing extraordinary and there may be various reasons. It`s enough that Chinese shoddy switches and routers do not implement basic network protocols correctly (because anyone who checks it will notice it) and with a slightly developed infrastructure based on such "blocks", IP conflicts may occur, especially if the ports are connected in an unfortunate order.
    The safest option is to simply not use DHCP at all. At the same time, the level of security increases significantly and the network throughput increases at the same time.
  • #24 20948734
    jarekgol
    Level 40  
    Posts: 5147
    Help: 642
    Rate: 1137
    analog_6 wrote:
    at the same time, network throughput increases
    and why so? that DHCP generates so much traffic? I assume that in home networks it has no noticeable significance?
  • #25 20948736
    Anonymous
    Level 1  
  • #26 20948816
    analog_6
    Level 16  
    Posts: 319
    Help: 6
    Rate: 144
    Of course. Network protocols are written by smart people who know how to minimize the protocol load on the network.
    However, undoubtedly any unnecessary network mechanism always causes a load on the router and usually on the network itself. If there is a network, then also all receivers physically connected to it. Each single packet, even the shortest, means time on the links and power consumption of both the transmitter and the receivers (at least for data processing in the lowest layers). So why activate unnecessary protocols? The answer is obvious - for nothing. Don`t do this. DHCP is extremely useful, like any plug & play. But often it is not necessary. And when it is not necessary, it should not be used. The net is not a bottomless bag. Each has bandwidth and data processing limits. They should be saved whenever possible. Because it`s not that difficult to exhaust them considering today`s user expectations.

    PS As a side note, an average text email, a regular one, not burdened with any fashionable HTML junk, generates about 5g of CO2 into the atmosphere in the form of electricity consumed. It`s worth thinking about.
  • #27 20948833
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    khoam wrote:
    Not necessarily. On my work smartphone, after the first launch, MAC randomization was disabled by default. Produced in 2020

    Perhaps Android (GOOGLE) has its own and the manufacturer has its own.
  • #28 20948980
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    krzbor wrote:
    So the question arises - how does the "detector" work - the boss probably has a very old phone :)

    The newest iPhone ;) Also, set your own standards and live your own life.

    jarekgol wrote:
    Beautiful block :)
    Some time ago I looked at the DHCP server logs to check whether the management had reached the plant.

    Thanks.
    I solved it a little differently - since our plant is a bit scattered, several buildings are some distance from each other, and we have WiFi MESH networks on Ubiquiti, I solved the issue with a script.
    Sometimes I need to meet a certain person in person, so in order not to "disturb the guitar" with a telephone conversation, I have prepared a script that asks the controller which antenna the user was physically connected to in the last few minutes. Based on this data, it generates an HTML page where I have a list of people with their physical location ;) Of course, you must remember that this information is not 100% up to date, because the user may have already moved. But in most cases, it allows you to track down the perpetrator quite precisely.

    jarekgol wrote:
    And what about the fact that a given manufacturer has an allocated pool of Macs? And I wonder what is the chance in larger chains that the Macs will clash after the draw?

    The manufacturer can be identified by the first 6 characters in the MAC address, the remaining 6 can be randomized, I think this is enough for quite a large network.
  • #29 20949061
    sq3evp
    Level 39  
    Posts: 6509
    Help: 217
    Rate: 863
    Interesting idea, can any ESP or other controller be used?
  • #30 20949167
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    I`m thinking about using this device for monitoring. In the case of a separated and fenced building, you can detect that someone is hanging around (of course, if they have a phone :) . I noticed that information about the signal strength is transmitted - so you can determine approximately how far someone is. I am thinking about working in two modes - collecting data and then sending it via classic WiFi. This requires constant changes to the ESP settings. Currently in listening mode we have:
    Code: Arduino
    Log in, to see the code

    Here I have a question for people who know ESP well - how to switch it to transmit mode (STA)? Will running the above code again switch it back to listening mode?
📢 Listen (AI):

Topic summary

✨ The discussion revolves around a device called the Supervisor detector, which utilizes the ESP8266 chip and an SSD1306 OLED display to monitor the presence of smartphones by detecting their MAC addresses. Users express interest in the device's functionality, noting that smartphones often do not turn off Wi-Fi, leading to active scanning for known networks. Concerns about privacy and MAC address randomization are raised, as modern smartphones may generate random MAC addresses, complicating identification. Suggestions for enhancements include adding Bluetooth capabilities and a buzzer for notifications. The conversation also touches on the implications of using such technology in marketing and the legal considerations surrounding user consent for tracking. Additionally, technical discussions about the operation of the device, signal strength measurement, and the potential for using ESP32 are included.
Generated by the language model.

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.
ADVERTISEMENT