Prepare Your Code
A code example for ESP32/ ESP8266 / Arduino boards
4 simple steps to configure your code:
Open Arduino IDE and install Blynk library
Define Template ID and Device Name on top of your firmware, before any includes
Define your physical button and LED if needed
Upload this sketch into your test board
Final step: Provision your board via Dynamic Provisioning flow and add it to your account using Blynk app
Defining your physical button and LED
To enhance the user experience it's recommended that you plan these things into your electrical design:
A physical button which will allow resetting the device to its default settings. E.g.: Holding this button for N seconds will erase the AuthToken and WiFi credentials.
An LED to indicate different statuses of device (AP, connected, etc.). It can be RGB or one-color LED.
Depending on your board there can be different variants of the setup, we'll provide some examples for you to get an idea of how it can work.
Here we use the Edgent_ESP8266 sketch as an example, but the same principles apply to the ESP32 sketch as well. The Edgent_ESP8266.ino file (the first tab in the Arduino IDE) contains the following lines of code:
Notice that all of these board types are commented-out by default so you’ll have to un-comment the board you are using.
If the board you are using isn’t listed here then leaving all of the board types commented out will cause the sketch to use the “Custom board configuration” from the Settings.h tab, and you need to edit this custom configuration to suit your hardware.
This is what the relevant parts of the standard Settings.h file look like:
The first section starts with #if defined(USE_NODE_MCU_BOARD) || defined(USE_WEMOS_D1_MINI).
In plain English, this means, “If you’ve uncommented either the #define USE_NODE_MCU_BOARD or #define USE_WEMOS_D1_MINI lines of code in the first tab of the sketch, then the following settings will be used for the physical button and LED”.
The NodeMCU board has 2 physical buttons:
The button on the bottom left is labeled RST and the one on the bottom right is labeled FLASH.
The FLASH button is connected to GPIO0 (the pin labeled D3 on the board). When the button is pressed, GPIO0 is connected to GND (LOW).
Most NodeMCUs also have a built-in LED (located up near the top right of the board) which is connected to GPIO2 (the pin labeled D4). This LED lights up when GPIO2 is pulled LOW, so has what is known as inverse logic.
Below the comments are added explaining the standard settings for the NodeMCU/Wemos D1 Mini board:
If you’re using the Wemos D1 mini, it is very similar but you’ll notice that it only has one button labeled RESET (same as the RST button on the NodeMCU).
It doesn’t have the FLASH button, so you’ll need to add a physical momentary push to make a button in order to be able to clear the stored credentials if ever you need to re-provision the board.
One side of the physical push button will connect to the pin labeled D3 and the other side to GND (because we have this line set to true: #define BOARD_BUTTON_ACTIVE_LOW true which means that when the button is pressed the GPIO0 (D3) pin is pulled LOW).
Of course, if you wanted to, you could simply use a jumper wire, bent paperclip, or anything else that’s conductive to short-out pin D3 and GND for 10 seconds.
So, if you don’t un-comment one of the pre-defined board types, the custom board type configuration will be used. That looks like this:
As you can see, this uses GPIO0 (Pin D3) for the physical pushbutton switch, but GPIO4 (pin D2) for the LED. It also has the option to un-comment additional lines of code that allow an RGB or WS2812 RGB LED to be used.
If you didn’t un-comment any board types and allowed the custom board configuration to be used, then with a NodeMCU the built-in LED wouldn’t flash to indicate provisioning or pulse to indicate normal running. But, pin GPIO4 would still be receiving these pulses from the sketch, and if you had a sensor or relay attached to GPIO4 then this could provide unexpected results.
Make sure you check these before starting device provisioning:
Un-comment the correct board type
Check the Settings.h file to ensure that the selected board type does actually match your hardware setup
Add a physical button to the Wemos D1 mini if needed
Use the custom board configuration if you have an unusual type of board, but edit the custom section of Settinsg.h to make it match your hardware
Ensure that you don’t use the GPIOs assigned to the button or LED pins for anything else in your sketch.
Last updated