Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WifiEvent Handling #2910

Closed
tkerby opened this issue Jan 30, 2017 · 8 comments
Closed

WifiEvent Handling #2910

tkerby opened this issue Jan 30, 2017 · 8 comments

Comments

@tkerby
Copy link

tkerby commented Jan 30, 2017

Description

Is there a way to use the WiFi Event Handling to recover the RSSI and Mac Address of received probe requests?

Specifically I would like to setup an AP using SoftAP and monitor for any probes it receives, logging the time, MAC and RSSI.

I've taken a good look at the WifiEvent example for a client but it doesn't cover how to access the data in the structures associated with the events. In particular I'm looking to read from this data in ESP8266WiFiType.h

+struct WiFiEventSoftAPModeProbeRequestReceived
+{

  • int rssi;
  • uint8 mac[6];
    +};

Ideallu I'd like to expand this to both run as a dummy AP, but connect to an access point as a client to get the time from NTP and forward Probe requests to an MQTT server

@tkerby
Copy link
Author

tkerby commented Feb 1, 2017

@igrr I think you may be working on this. Has there been any progress?

@igrr
Copy link
Member

igrr commented Feb 1, 2017

No, I'm not working on this issue. I don't know of a way to monitor probe requests in the non-OS SDK in SoftAP mode. So no clue how this can be implemented.

@tkerby
Copy link
Author

tkerby commented Feb 1, 2017

@igrr Apologies - I saw your comment here: #2100 (comment) and thought you were referring to passing the structures associated with events into the event handler so this data could be read.

I know it's possible in LUA and by using the SDK directly but I'd like to find a way to do this in Arduino

igrr added a commit that referenced this issue Feb 2, 2017
- add probe request event handler (#2910)
- update WiFi events handling example to use new handler

Pro tip: replace blinking LED with ‘analogWrite’ and connect the pin to
a loudspeaker (or use a servo to hit a bell). Get notified when someone
with a smartphone wanders around your country house.
@igrr
Copy link
Member

igrr commented Feb 2, 2017

Sorry — I haven't understood your question correctly last time. Opened #2917 which implements the method you need. If you're using the git version of ESP8266 Arduino core, you can give it a go by doing git fetch origin && git checkout feature/wifi_probereq_event.

@tkerby
Copy link
Author

tkerby commented Feb 4, 2017

That works perfectly! Thanks very much for your help with this @igrr

igrr added a commit that referenced this issue Feb 6, 2017
- add probe request event handler (#2910)
- update WiFi events handling example to use new handler

Pro tip: replace blinking LED with ‘analogWrite’ and connect the pin to
a loudspeaker (or use a servo to hit a bell). Get notified when someone
with a smartphone wanders around your country house.
@devyte
Copy link
Collaborator

devyte commented Oct 3, 2017

@igrr I'm a bit confused on this one. I could swear I had the onProbeRequest handler in use in my own app, but I just checked, and I have it commented out, which means I was waiting on something. No idea what now...
This looks merged into master. Is it staged for release? Should this issue be closed, or labeled or something?

@devyte devyte added the waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. label Oct 3, 2017
@igrr igrr added component: libraries staged-for-release type: enhancement and removed waiting for feedback Waiting on additional info. If it's not received, the issue may be closed. labels Oct 6, 2017
@igrr
Copy link
Member

igrr commented Oct 6, 2017

Thanks @devyte, indeed this has been implemented and is available in master. Applied the right labels.

@igrr igrr added this to the 2.4.0 milestone Oct 6, 2017
@d-a-v
Copy link
Collaborator

d-a-v commented Dec 13, 2017

@tkerby's issue seems to be solved.
@devyte any feedback on your side ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants