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):
  • #31 20949413
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    sq3evp wrote:
    Interesting idea, can any ESP or other controller be used?

    The libraries used in this particular case are for ESP8266, I think that after replacing the libraries you can also use ESP32.

    krzbor wrote:
    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.

    Provided that Wi-Fi is turned on on the phone ;) For example, I always have it turned off and turn it on when I need it.
    When it comes to determining the distance, unfortunately it will not be so rosy - reflections and distortions of the signal can significantly change its strength. As a result, the relationship between RSSI and distance can vary between samples - even if the transmitter and receiver remain stationary. (...) the RSSI value can increase or decrease without changing the physical distance between the transmitter and receiver, depending on how the user holds the smartphone, how their body is positioned in relation to the device, or how surrounding structures reflect, block or absorb radio signals.
    Here`s a quote about BT, because I can`t find an article about wifi Link
    But the principle will be the same, these are radio waves.
    From my observations lasting several days, I see that this is how it works - sometimes I see a person being monitored through the window, and sometimes I have several alarms within an hour, even though I know that the person is in the other building, i.e. about 100 m away, behind a few walls - just a few packages will arrive and you are already notified.
    The basic design assumption for which I did this is absolutely fine, the system is supposed to send a signal to turn on the air conditioning, even before the user drives up to the gate, opens it, drives in, closes the gate, opens the door - the air conditioning will already be raging nicely. ;-)
  • ADVERTISEMENT
  • #32 20949707
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    szdom wrote:
    From my observations lasting several days, I see that this is how it works - sometimes I see a person being monitored through the window, and sometimes I have several alarms within an hour, even though I know that the person is in the other building, i.e. about 100 m away, behind a few walls - just a few packages will arrive and you are already notified.

    How often do phones send information (locate the network)?
  • ADVERTISEMENT
  • #33 20949726
    Sam Sung
    Level 33  
    Posts: 2013
    Help: 227
    Rate: 583
    krzbor wrote:
    How often do phones send information (locate the network)?

    https://source.android.com/docs/core/connect/wifi-network-selection?hl=pl
    Quote:
    In the low mobility state (device is stationary), the interval is 60 seconds for the first three scans (...) and 180 seconds (fixed 3x overlay multiplier) for subsequent scans. In the high mobility state, the interval is 20 seconds for the first three scans (...) and 60 seconds (fixed 3x overlay multiplier) for subsequent scans.
  • #34 20949730
    jarekgol
    Level 40  
    Posts: 5147
    Help: 642
    Rate: 1137
    @szdom and the time it takes for the client to reach the office, does this air conditioning have a noticeable effect, or is it more about psychology, "that she worked"?
  • ADVERTISEMENT
  • #35 20949770
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    In this case, the point is for it to start as quickly as possible. I am perfectly aware that she needs time to flex and get going.
  • #36 20952896
    Mlody_Zdolny
    Level 31  
    Posts: 1439
    Help: 109
    Rate: 643
    Who goes outside with Wi-Fi or Bluetooth on? :D

    Moderated By gulson:

    Report: malice, quarrel, mockery

  • ADVERTISEMENT
  • #37 20953088
    sq3evp
    Level 39  
    Posts: 6509
    Help: 217
    Rate: 863
    The average user has WiFi and BT turned on all the time, and then wonders why there are so many advertisements from the stores he visits.
  • #38 20953140
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    Mlody_Zdolny wrote:
    Who goes outside with Wi-Fi or Bluetooth on? :D

    99.9% of people do not turn off WiFi and BT. The question is who is normal :)
    Otherwise, he leaves the house - turns off BT, gets to the car - turns on BT, leaves the car, turns off BT, puts BT headphones in his ears, but first turns on BT. When entering the gallery, he takes out his headphones, because they don`t work without BT, and to avoid being spied on, he turns off BT on his phone.
    A bit too much paranoia. For me, the real threat are WiFi devices installed in homes. Such a device is able to do everything while in the internal network. It can also be a serious security hole.
  • #39 20957387
    sq3evp
    Level 39  
    Posts: 6509
    Help: 217
    Rate: 863
    krzbor wrote:

    A bit too much paranoia. For me, the real threat are WiFi devices installed in homes. Such a device is able to do everything while in the internal network. It can also be a serious security hole.


    And it is - I recommend reading security bulletins regarding IoT vulnerabilities :)

    There`s a lot you can do, but it`s not always worth it.
  • #40 20959085
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    Today I noticed interesting behavior of Android - I have Wi-Fi turned off on my phone, and yet in the morning the phone sent frames several times and the detector registered them.
    I suspect this is related to the location enabled on the phone. I always thought that it works passively, it only scans nearby networks, but it turns out that this is not necessarily the case.
  • #41 20959153
    sq3evp
    Level 39  
    Posts: 6509
    Help: 217
    Rate: 863
    A location needs a network - find out what Google knows about you,
  • #42 20959191
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    I know more or less what Google knows about me.
    But WiFi-based localization works by scanning nearby networks and comparing signal strength and several other parameters.
    Here I was surprised that the location is not completely passive, but the phone actively participates in it and forces traffic in the air, despite the WiFI slider being set to OFF. What is he for then?
  • #43 20959423
    sq3evp
    Level 39  
    Posts: 6509
    Help: 217
    Rate: 863
    Hmmm... I also noticed this once, that even though the phone was offline, the router saw that it was connected and was transmitting something.
    Apparently Google (or another Apple) likes to know what and how - then software like Pegasus or another Predator appears.
  • #44 20959587
    jarekgol
    Level 40  
    Posts: 5147
    Help: 642
    Rate: 1137
    You can check if you have "Google location accuracy" turned on and if so, change it to GPS only and see if it stops spamming over Wi-Fi.
    I still have it in the "location" section: Wi-Fi and Bluetooth scanning are turned off.
    Maybe it`s related to connections without AP:
    https://stackoverflow.com/questions/21501909/...cast-communication-without-network-connection
    https://developer.android.com/develop/connectivity/wifi/wifi-aware
  • #45 20965761
    Mocny Amper
    Level 11  
    Posts: 87
    Rate: 19
    I made a similar device myself, but the detection method was simply ping. A successful ping meant that I received the MAC address of the device, and from there it was a simple way to turn on the appropriate structure of the RGB LED. Also quite effective, but... time-consuming, because I encountered problems with pseudo-parallel sending of ping packets. For example, I ping 50 addresses at once and listen to 50 responses at once. Despite a hard fight, I failed, I had to do it serially, IP address by IP address, and it took some time to scan 254 addresses. But since I only wanted two people/devices, once I found them, I "shortened" the pool of addresses, omitting the rest, and the next cycle was faster. I also predicted a situation where the MAC you are looking for may get a different IP than the last one, etc. surprises in the network.
    I haven`t heard about the scanning method used by the author, maybe one day I will improve my detector.
  • #46 20976572
    Anonymous
    Level 1  
  • #47 20976652
    Mocny Amper
    Level 11  
    Posts: 87
    Rate: 19
    Everyone probably didn`t notice the simple fact that it is a presence detector.
    Meanwhile, it is impossible to check it based on its operation NO presence. Contrary to appearances, it is not the same :)
  • #48 20986796
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    jarekgol wrote:
    You can check if you have "Google location accuracy" turned on and if so, change it to GPS only and see if it stops spamming over Wi-Fi.

    After turning off the location accuracy, the phone stopped appearing in the detector.
    @MocnyAmper In your solution, you had information about the user only when he connected to the network, in my case the phone may not even be in range to get the IP, and you already have information that it is nearby. Recently I noticed the phone being detected from a distance of over 100m.
    @erbit Thanks!

    Currently, I have expanded the code to display information about the signal strength that caused the call, in the form of 10 dashes on the OLED. Only now I see how the packets (reflections, etc.) must follow a different path, because the phone is in a known location, and one moment I have 4 lines and the next moment I have 9. It is certainly impossible to determine on this basis how far the monitored object is.
📢 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