Setting WiFi credentials posthumously

Please excuse newbie’s naivete … I am an old school programmer with no previous exposure to the IOT/ WiFi world.
If you could kindly give me a hint into the right direction …
I realise it’s not exactly a Blynk specific topic …

Addie lives in Adelaide, SA. He is tech adequate.
He has a brother Bret in Broome, WA. Bret is not tech brilliant.

Addie has built an IOT gadget for Bret that includes:

  • 3G to WiFi modem router (he names it AP1), and

  • Arduino + ESP WiFi module (he names it STA1)

Addie configures AP1 and STA1 establishing a link between them. Addie writes down all relevant details of configuration.
Addie sends AP1 and STA1 to Bret. Bret confirms that the gadget is powered and works well.
Bret asks for another module - STA2 - to work under the same AP1.

Addie builds another gadget identical to STA1.

Is it possible for Addie to configure STA2 for working with AP1 without taking a flight from Adelaide to Broome?
If yes, - HOW?
Are there technical requirement to the access point device to enable this scenario?
What is the right terminology for this process?

Thanks a lot,

@PhilMond I have read your post a few times but still confused.

Addie didn’t fly when he sent AP1 and STA1 so why would he fly for STA2?

He would simply send STA2 like he did STA1 (with AP1).

If Bret knows the SSID and PWD of his regular router, let’s call it AP0, then with WiFiManager or Blynk Provisioning Addie can configure STA1 just to enter the credentials for AP0 i.e. they are dynamic and not hard coded in the sketch.

Thanks Costas,

You have actually answered my questions.
RE your confusion: at the first step Addie had both AP1 and STA1 sitting on his workbench.
At the second step AP1 has gone to Broome (BTW, have you been to Broome? An amazing place!)

What I learned from your reply: this is possible, it is called something like Dynamic Configuration.
All Addie needs to know is SSID and PWD. Right?



Wrong. Addie doesn’t need the details at all. As long as Broome knows his own AP credentials then Addie can flash a sketch to the hardware that asks Broome or anyone else that receives the hardware to enter their AP details.

I really don’t go anywhere or send my stuff to others, so I also find this process a bit confusing… but I think what you are looking at is Dynamic Auth Token Provisioning, as the WiFi Credentials, Account Login and Auth Codes are all related in their necessity for a complete Blynk setup.

Hi Costas, That seems like a problem.

I understand that Bret in Broome would be able to link a new gadget STA2 to the existing access point AP1.
Addie wants to avoid any action by Bret who already keeps the system.
Addie wants to configure STA2 in such a way that it would be hooked up by AP1 with no local efforts.

Thanks Gunner,
I’ll have a look at this

In that case he simply puts the AP1 credentials in the STA2 sketch.

1 Like

Kind regards/

The only thing to look out for is if you’ve hard-coded either the IP address or MAC address of gadget STA1 in the code you used. This is unlikely, as most people use a blynk.begin statement which takes care of this dynamically.

However, if you did hard code an IP address or MAC address then device STA2 will need different ones.

Another thing you might want to look at is HTTP OTA updates. This allows you to get your ‘gadgets’ to check for a firmware update every so often (daily maybe?) and automatically download and install it then reboot themselves. You could also add a Blynk button to manually go and look for updates at any time you want. Handy if you want to tweak the code without having to get the gadget mailed back to you. There are a few threads about HTTP OTA on here if you’re interested.



Pete, I am still waiting for my first ESP module to arrive.

I’ve never had one in my hands and will need some hands-on experience to fully digest yours and other experts’ advice.

You have [partly] de-mystified IOT networking to me.

It seems to me now that it is possible to set up a gadget at the ‘factory’ for a specific remote LAN with known parameters in such a way that this new gadget would snug itself in with no additional customisation performed on the target LAN.

As to HTTP OTA I understand it this way: an Internet linked device has its IP address dynamically assigned. To enable firmware updates the device must report its current IP / Web socket to the server. Correct?

Thanks to you and other contributors.


It’s actually much simpler than that. The ESP simply visits a website ands looks for an update. IP’s don’t come into it.

What if a server needs to push data to the device?
How does it know the URL?

It’s a pull by the ESP not a push by the server.

Well, that explains … no problem with a dynamic IP

One more basic point for clarification, please:

What is the definition of ‘firmware update’?

In ‘normal’ programming I might have an app that makes an API call or sends an HTTP request to a server and upon getting a response parses the content. This is data exchange; the program is not get affected.

In the IOT/ M2M world does the term ‘firmware update’ means that the program, e.g. Arduino sketch gets modified?
Is there room for the pure data exchange in this world?


Yes, it can be done quite easily with Blynk’s Webhook widget to send / receive data.

1 Like

No, the OTA server doesn’t care about the IP address of the device that’s downloading the firmware update.
There are three ways to do firmware updates to an ESP based device:

  1. Via USB - plug it into your PC and flash the new code to the device via the Arduino IDE or other software compiler.

  2. Over The Air (OTA) update from within the same network. In this situation, you load the OTA code onto the ESP device using method 1 above, then next time you want to update it you can leave it in situ in your Home and connect to it via a virtual network port rather than a Com port. Handy if you’ve buried the ESP device away in a wall cavity, or if you’re using a Sonoff device and don’t want to have to take the cover off and connect-up a USB to serial interface.

  3. OTA remotely, over the Internet - known as HTTP OTA. By compiling your code in the normal way then taking the file that’s produced and putting it on a HTTP web server (I use a free web hosting account to do mine). The remote ESP device needs to be told which web address to go to for the update, so you program-in the URL and file name when you do (1) above and also program the device to go and check that web address on a regular basis (every day at 2am for example) or to run the update routine manually when you press a Blynk button.

Obviously the device that’s already been deployed (STA1) doesn’t have the OTA code in place, so you’d need it back on your workbench to make any code updates. However, your new device (STA2) could be programmed with HTTP OTA code so that once deployed to the remote location you can update the code to fix bugs or add new features without having to have it back on the workbench.



nice explanation. i just would like to add another method to init http ota update: via blynk api. this way there is zero activity needed by the end user, also no need for timers or special button in the app.

you just can set a virtual pin high in the api, init the update, send an “update init” message to another virtual pin (to have feedback whats happening).

after successful update and restart, send a confirmation message (including the version number and timestamp) to the virtual pin. and delete the bin file from the server manually.

it sounds complicated, but actually quite easy to code. i even have a function implemented which monitors the last restart cause and timestamp, and sends a message to a virtual pin. like:

  • wifi / server connection timeout
  • restarted by user
  • restarted by performing http ota
  • unknown / blackout

this way i can see when was the last time the device was (re)started. i also monitor the wifi signal strength in superchart.

once a client complained that the device / firmware is bad quality and often crashes. then i could proove the cause of the “crash” was wifi signal lower than -80 dbm.

1 Like

Thank you Pete for the comprehensive answer that clarifies the picture.

Our conversation somehow moved from WiFi credentials to the firmware update.
What are this forum rules? Is it my responsibility as a topic initiator to close it or it’s done by a higher authority?