Brief connects to different access points while retaining Particle Cloud connection details

I am using a Photon running 2.3.0 firmware.
Programming it via the Web IDE and need it to be able to do publishes.

I need to briefly connect to a an access point offered by an ESP-01 (and which I dynamically discover from a WiFi.Scan list while connected to the Particle Cloud). The ESP-01 is running a very simple webserver host on a hard coded IP address. When I connect to that server’s “home” page it will return a simple set of numbers as text - there is no password on the AP or the webserver cos returning that number is all it does.

I have looked for some example code on how best to do this but not found quite what I need. So before I code up my approach below, just wanted to make sure that there is no way to make WiFi.Connect() go to a specific AP rather than sequentially stepping through all the credentials it has stored?

I plan to do this:

* Connect to Particle Cloud (which I need to be for WebIDE and for publishing numbers obtained)

* Scan wifi network until I found an AP that has a name which matches a pattern - it will be one of a possible ten, but will come into range pretty much at random.

* Disconnect from Particle cloud using WiFi,disconnect()

* clearCredentials on the photon

* Install credentials for the found AP (which will just mean the AP name in this case since there is no password)

* Connect to the AP concerned

* Connect to its web server and grab the info (probably using a TCPClient)

* close the connection and disconnect from the AP

* clearCredentials on the photon again

* use SetCredentials to reinstall the Particle Cloud and then reconnect to it.

* use Particle.publish to share what I retrieved to all other subscribed Photons/Argons 

Now, that does seem like (a) a convoluted way to do this and (b) since these mobile APs will come into range up to 4-5 times per day each, it will involve of a lot of flash erases and re-writes over time (I assume) so before I go ahead with it I was wondering if anyone can suggest any better approach.?

Thanks in advance
Alan T

Hi Alan,
What is that AP that comes and go? Why do you want to clearCredentials in between connects?
I’d like to understand what you want to do. What if you tell me (and us) what do you want to achieve by this, what is it that leads you to think of this solution this way?
That way, maybe we can come up with different ways of tackling this beast.
Maybe you can describe (if at al possible) the environment the photon will be in.

Hi Gus,

Thanks for your prompt reply.
The photon is in a building (garage). There is a parking area adjacent to the garage where vehicles park. The overall aim is to provide alerts whenever a vehicle arrives.

The APs which come and go are in vehicles and are on any time the vehicle ignition is on.

The number which my code will retrieve from the AP webserver is simply the millis() value as text. This is needed so that my code can tell if the AP in question has just now been started (i.e. the vehicle is leaving and no alert is needed) or has been running for more than [Mumble] seconds and has thus just arrived. The AP name will be unique to each vehicle - but follow a pattern like OurVAN_123.

Why clear credentials? Wifi.connect takes no arguments - and the documentation says - effectively - it will search stored credentials until it finds something that works, Clearing credentials and entering the desired AP after that seems like the only way to guarantee that it will connect to the one that I need at that moment?

Before you say it, yes, the webserver approach is overkill, it could just be a socket, but I may need to add more items or functions so I want to retain that approach if I can.

I would probably implement this differently: Put a Bluetooth beacon in each vehicle, and put a BLE central in place of the Photon, possibly on an Argon. BLE is a much better choice for continuous scanning and it runs independently of the cloud connection so both can be running at the same time.

It could either be a standalone beacon in the vehicle, or if you also needed Wi-Fi, the ESP32 has both. BLE advertising data has room for 32-ish bytes so if you can fit the identifying data in that, you don’t even need to make a secondary connection.


Hey Alan, thank you for the explanation. I would also suggest you look into the BLE beacons world.
If in the future you needed to send some commands to the cars, you could put an Argon/Boron acting as a BLE Beacon, and then the device in the garage can connect to them via BLE and send the command as you imagined via WiFi.

You may start here if you want:

There are few tutorials that can give you ideas as well.


Yep looks like the BT route is a better one.
many thanks guys.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.