logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

"Superior Detector" - another version

krzbor 3891 5

TL;DR

  • An ESP8266-based "supervisor detector" logs nearby cell phones by scanning Wi‑Fi MAC addresses and RSSI, then sends the collected data to a server.
  • The ESP runs in WIFI_AP_STA dual mode, using one radio for access point login and the other for periodic Wi‑Fi sniffing and transmission.
  • The code extends MAC collection to 1 minute and remembers only the strongest RSSI plus hit count for each MAC address; ArduinoJson needed updates for newer libraries.
  • Phones with active Wi‑Fi were detected reliably near the house, with RSSI above -75 meaning close and above -70 meaning at or inside the building.
  • Randomized MACs limit identification outside a phone's own network, so the system mainly sees nearby devices associated with a known Wi‑Fi network.
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • Sonoff Basic – Wi-Fi Smart Switch with attached power cord
    Recently it appeared in the DIY section "Supervisor Detector" by @szdom. The topic aroused great interest, including mine. However, I decided to approach the problem differently - ESP was to collect data and periodically send it to the server. The main task is to detect the presence of someone`s cell phone nearby. This is possible thanks to the RSSI information. Generally, weak RSSI (small RSSI value) means greater distance between the transmitter and receiver. It may also result from an unusual pattern of occlusions and reflections. Therefore, this is a poor indicator. A high RSSI value indicates the proximity of the transmitter and receiver. This is rather a certain fact - I ignore directional antennas, etc.
    I searched the Internet for code - how to acquire data and send it. I was thinking about constantly switching between listening and sending mode. The solution turned out to be much simpler - it is the WIFI_AP_STA mode, i.e. dual mode in which ESP works as both AP and STA.
    Below is the original code that I found on several websites:
    Code: Arduino
    Log in, to see the code

    I failed to compile it in the original version - the reason was the newer ArduinoJson library. I also made a number of changes:
    - blinking of the built-in diode - signaling the start, connection to WiFi and each sending,
    - initial login using wifiManager,
    - extension of MAC address collection time to 1 minute,
    - for a given MAC, only one item is remembered, containing the highest RSSI value and the number of occurrences of a given address. Arduino code:
    Code: Arduino
    Log in, to see the code

    Below is an example code in PHP that receives data and writes it to a log file:
    Code: PHP
    Log in, to see the code


    Hardware
    The hardware is so trivial that I did not dare to present this article as a DIY :) . For some time now I have been using SONOFFs as a base for projects based on ESP8266. Sonoff provides me with ESP, power and housing. The only thing left for me to do was add a power cable. In the presented system, the relay is not used.

    MAC devices
    Current cells use random MAC addresses when trying to connect:
    Timeline with information on MAC address randomization in iOS and Android systems.
    Random MAC addresses are easy to recognize - if the second MAC digit is 2, 6, A, or E, it is a random MAC address. As you can see from the diagram above, Android introduced random MAC addresses in connection attempts in 2017. Interestingly, random MAC addresses have also been used since 2019 when connecting to a WiFi network. However, there is an exception here - the randomly selected address is constant for a given SSID. This solution is necessary due to access points presenting regulations or requiring consent. We find this type of access in hotels, restaurants and other public access points. A permanent change to the MAC would require constant confirmation of the regulations. There will probably be changes in this respect, e.g. MAC address randomization if you have not logged in to a given network for a given period (e.g. 24 hours). So, can the “supervisor detector” work? Well, if a phone with active WiFi is within the range of its network, it can be identified. However, if it is outside "its" WiFi network, this is not possible.

    Because the log contains information about all "caught" MAC addresses, if they are not random, you can identify the manufacturer of the WiFi card, and sometimes also the manufacturer of the equipment. However, these will mainly be routers and other stationary equipment.

    However, my goal was to use the system for some kind of supervision. After placing it in a building (preferably inside), it can tell us whether any cell was near the house or even inside. I use it in a newly built house and I can say that it detected my (and not only my) presence. Of course, RSSI thresholds need to be established. In my case, it turned out that non-stationary devices with RSSI above -75 mean they are close to home. RSSI above -70 is directly at the house or inside the building. Cells are very talkative. A connection attempt is recorded practically every minute. By looking at the table, I can determine the time of arrival, stay and departure from the house.
    If you liked the article or contained useful information, give it a "plus"

    Cool? Ranking DIY
    About Author
    krzbor
    Level 29  
    Offline 
    krzbor wrote 1755 posts with rating 1063, helped 41 times. Been with us since 2004 year.
  • ADVERTISEMENT
  • #2 20998163
    gulson
    System Administrator  
    Posts: 29347
    Help: 148
    Rate: 6026
    Thanks for developing the idea, I also think that user @szdom`s idea deserves further development.
    If you give me the Parcel Locker, I will send you a small gift! :)
  • ADVERTISEMENT
  • #3 20998656
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    I use a system to detect whether someone is near or inside the house. As I wrote, the MAC address in the WiFi network in which we are logged in, although random, is permanent. If we assign such a MAC to a specific person, we can determine which household member is at home (if they did not forget to take their cell phone). In a block of flats you can check whether your neighbor has returned from work. The tracking possibilities are huge and a little scary...
  • ADVERTISEMENT
  • #4 21000665
    szdom
    Level 12  
    Posts: 37
    Rate: 43
    @krzbor Nice project. Thanks for reminding me about the WIFI_AP_STA mode, I forgot that this mode existed.
    The tracking possibilities are truly enormous. By installing several/dozen such devices in an office building, we can track the location of a specific person in almost real time.
    The ability to connect to the server provides new functionalities - e.g. verification of authorizations.
    It can be used for specific access control, e.g. entering a company parking lot (of course, this would require forcing the user to turn off MAC randomization).
  • ADVERTISEMENT
  • #5 21001626
    krzbor
    Level 29  
    Posts: 1755
    Help: 41
    Rate: 1063
    An interesting development of the project may be replacing the sending of information to the server with MQTT. Instead of a minute, we can collect data for a second. Our MQTT client on ESP can subscribe to the "interesting MACi" channel and publish MAC and RSSI when an interesting MAC appears. With MQTT we can do everything, e.g. in HA.
  • #6 21105014
    pitsa
    Level 12  
    Posts: 32
    Help: 3
    Rate: 12
    If someone's arduino code wasn't working, a small correction needs to be made, in two places.
    Such was:
    Code: text Expand Select all Copy to clipboard
    HTTPClient http;
...
http.begin(host);

    Replace with this:
    Code: text Expand Select all Copy to clipboard
    WiFiClient client;
HTTPClient http;
...
http.begin(client, host);
    .
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law
Today's popular

FAQ

TL;DR: A 1-minute capture window and the rule "RSSI above -70 is directly at the house" make this ESP8266 detector useful for homeowners who want phone-presence logging from Wi‑Fi probe requests. It runs in AP+STA mode, stores the strongest RSSI per MAC, and posts JSON to PHP or, for faster reactions, can be reworked for MQTT and Home Assistant. [#20996869]

Why it matters: This design turns a cheap ESP8266 or Sonoff into a practical presence sensor, but MAC randomization sharply limits reliable person identification.

Approach Transport Capture window Best use Main limit
PHP logging HTTP POST 60 s Simple history and timestamps Slower updates
Event-style tracking MQTT 1 s Fast alerts and Home Assistant More integration work
Person identification MAC matching Depends on phone behavior Known devices on known Wi‑Fi Random MACs reduce certainty

Key insight: The project works best as a presence estimator, not a universal people tracker. Strong RSSI and repeated sightings help, but randomized MAC addresses break identity outside known Wi‑Fi conditions.

Quick Facts

  • The ESP8266 collects probe-request data for 60 seconds, then sends JSON; if no devices appear, it suppresses empty uploads until 60 empty cycles pass. [#20996869]
  • Reported practical thresholds were above -75 dBm for "close to home" and above -70 dBm for "directly at the house or inside the building." [#20996869]
  • The detector runs in WIFI_AP_STA mode, so one ESP8266 acts as both an access point and a station at the same time. [#20996869]
  • A later compatibility fix changed http.begin(host) to http.begin(client, host) with an added WiFiClient client; object. [#21105014]

How do I build an ESP8266-based phone presence detector that captures Wi-Fi probe requests and sends RSSI data to a server?

Build it around an ESP8266, enable WIFI_AP_STA, register onSoftAPModeProbeRequestReceived, and POST collected JSON to a PHP endpoint every 60 seconds. 1. Connect the module to your home Wi‑Fi. 2. Start a soft AP and capture probe requests. 3. Store MAC, strongest RSSI, and count, then send them as JSON. A Sonoff can serve as the hardware base, with only power and housing used and the relay left unused. [#20996869]

What is WIFI_AP_STA mode on the ESP8266, and how does it let the module scan nearby devices while staying connected to Wi-Fi?

WIFI_AP_STA is an ESP8266 operating mode that runs the module as an access point and a station simultaneously, letting it stay connected to Wi‑Fi while receiving nearby probe requests. In this project, the ESP joins the home network as STA and exposes a soft AP for probe capture. That removes the need to keep switching between listening and sending states. [#20996869]

Why does the original ESP8266 probe-request sketch fail to compile with newer ArduinoJson versions, and how should it be updated for ArduinoJson v7?

It fails because the original code uses older ArduinoJson constructs such as DynamicJsonBuffer and createObject(), while the revised sketch switches to JsonDocument for v7. Update the JSON-building section so each device is written into doc[index], then serialize with serializeJson(doc, json). The thread explicitly states the compile problem came from a newer ArduinoJson version. [#20996869]

How can I use WiFiManager on an ESP8266 to configure the home network first and then switch into AP+STA mode for MAC detection?

Use WiFiManager first, then reconnect manually in AP+STA mode. 1. Call wifiManager.autoConnect(APname, APpassword) and wait up to 180 seconds. 2. Read the saved SSID and password with getWiFiSSID(true) and getWiFiPass(true). 3. Disconnect, set WiFi.mode(WIFI_AP_STA), start softAP(), and call WiFi.begin() with the saved credentials. The sample also blinks the built-in LED to show startup, connection, and each upload. [#20996869]

What is RSSI in Wi-Fi scanning, and how should I interpret values like -75 dBm and -70 dBm for detecting whether a phone is near or inside a house?

RSSI is a Wi‑Fi signal-strength reading that indicates how strong the received transmission is, with higher values such as -70 dBm meaning a closer transmitter than weaker values such as -85 dBm. In the reported setup, non-stationary devices above -75 dBm were treated as close to home, and readings above -70 dBm meant directly at the house or inside it. The author also notes that weak RSSI is a poor distance indicator because reflections and occlusions distort it. [#20996869]

How can I modify the ESP8266 code so it stores only one entry per MAC address, keeps the strongest RSSI, and counts how many times that MAC appeared?

Replace the raw event list with a structure that stores mac[6], rssi, and count, then merge repeated sightings into one record. The shown onProbeRequestPrint() handler compares all 6 MAC bytes against existing entries. If the MAC already exists and the new RSSI is stronger, it updates rssi and increments count; otherwise it creates a new record with count = 1. [#20996869]

Why do modern Android phones show random MAC addresses during Wi-Fi scans, and how can I tell a randomized MAC from a hardware MAC by looking at the address?

Modern Android phones randomize MAC addresses during Wi‑Fi connection attempts, which reduces reliable device identification from probe traffic alone. The thread gives a simple visual rule: if the second MAC digit is 2, 6, A, or E, treat it as a randomized address. It also states Android introduced random MACs for connection attempts in 2017 and used them for Wi‑Fi connections from 2019, with a stable random MAC kept per SSID. [#20996869]

How does MAC randomization affect using an ESP8266 'Supervisor Detector' to identify people by their phones at home or near a building?

MAC randomization makes identity tracking unreliable outside a phone’s known Wi‑Fi environment. The project can still identify presence when a phone with active Wi‑Fi is within range of its own network, because the random MAC used for that SSID remains constant. Outside that condition, the thread says identification is not possible, so the detector works better for presence estimation than universal person recognition. [#20996869]

What is the best way to log ESP8266 probe-request data on a PHP server, including MAC address, RSSI, timestamp, and sender IP?

Use a simple PHP endpoint that checks a private key, reads raw JSON from php://input, extracts REMOTE_ADDR, and appends a timestamped line to a log file. The sample writes date('Y.m.d-H:i:s'), the sender IP, and the JSON payload into mazskan.log using file locking with flock(). That gives a durable text log of each ESP8266 upload without requiring a database. [#20996869]

HTTP POST to PHP vs MQTT on ESP8266 for Wi-Fi presence tracking — which approach is better for faster updates and Home Assistant integration?

MQTT is better for faster updates and Home Assistant integration, while HTTP POST to PHP is simpler for periodic logging. The thread’s HTTP version uploads every 60 seconds and is suited to history files. The proposed MQTT version would collect data every 1 second, subscribe to a channel of interesting MACs, and publish MAC plus RSSI immediately when one appears, which the author says can be used in HA. [#21001626]

How can I use a Sonoff device as a simple hardware base for an ESP8266 Wi-Fi detector without using the built-in relay?

Use the Sonoff only as an ESP8266 board, power supply, and enclosure, and leave the relay disconnected from the project logic. The author says this hardware was so simple it barely qualified as DIY: the only extra job was adding a power cable. That makes Sonoff a compact housing for a detector that only needs Wi‑Fi, power, and status LED signaling. [#20996869]

Why does HTTPClient.begin(host) stop working in some ESP8266 Arduino setups, and how do I fix it with WiFiClient and http.begin(client, host)?

It stops working in some setups because the HTTP client call needs an explicit WiFiClient object. The thread’s fix is short: declare WiFiClient client;, keep HTTPClient http;, and replace http.begin(host); with http.begin(client, host);. If your old sketch suddenly fails while compiling or connecting, this is the exact compatibility change reported by another builder. [#21105014]

What timing interval should I use for collecting Wi-Fi probe data on ESP8266 — one minute, one second, or something in between for reliable presence detection?

Use 60 seconds for simple presence logging and 1 second for event-driven automation. The working build in the thread waits delay(60000) and still reports that phones attempt connections practically every minute, which was enough to estimate arrival, stay, and departure. The later MQTT idea suggests shrinking the window to 1 second when you need fast reactions or Home Assistant triggers. [#20996869]

How could multiple ESP8266 detectors placed around a house or office be used to estimate a person's location in near real time from MAC and RSSI data?

Place several detectors in different zones and compare which unit sees the target MAC with the strongest RSSI and highest repeat count. One post states that installing several or even a dozen devices in an office building could track a specific person’s location in almost real time. The same post links server connectivity to new features such as authorization checks and access-control logic. [#21000665]

What privacy and security risks should I consider before using an ESP8266, Sonoff, and RSSI-based MAC tracking system for home supervision or access control?

The main risks are covert tracking, household profiling, and misuse against neighbors or coworkers. The thread explicitly says you could infer whether a neighbor returned from work and calls the tracking possibilities "huge and a little scary." For access control, the idea also depends on disabling MAC randomization, which weakens privacy by making a user’s phone easier to identify across repeated sightings. [#20998656]
Generated by the language model.
ADVERTISEMENT