Blynk WiFiManager for ESP8266/ESP32 with Multi-WiFi and Multi-Blynk

PeteKnight · April 28, 2020, 5:04pm

I think what @Gyromike was saying is that he is using Bridge code in Blynk to communicate with multiple devices that have different auth codes. The server setting would be the same, but there would be multiple auth codes, one for each device.
This is the recommended way (in fact the only real way) of passing data between devices and is quite common.

This post from @GTT explains the basics in a sort of “Blynk Bridge for Dummies” way

Pete.

khoih · April 28, 2020, 5:37pm

Thanks @PeteKnight for the clarification.

I think we can already do that by specifying in the dynamic Params, then read/use/put them in the Blynk Bridge auth very similar to using to access MQTT server.

The dynamic Params feature is very good in this use case, as we don’t know ahead how many params/auths to be used for each application. It’s totally up to the users to specify and use.

For example

In dynamicParams.h

#if USE_DYNAMIC_PARAMETERS

#define MAX_BLYNK_AUTH_LEN      32
char Auth_A  [MAX_BLYNK_AUTH_LEN + 1]   = "token_A";
char Auth_B  [MAX_BLYNK_AUTH_LEN + 1]   = "token_B";
char Auth_C  [MAX_BLYNK_AUTH_LEN + 1]   = "token_C";
....

In the code

BLYNK_CONNECTED() 
{
  bridgeA.setAuthToken(Auth_A); // Token of the receiving hardware A
  bridgeB.setAuthToken(Auth_B); // Token of the receiving hardware B
  bridgeC.setAuthToken(Auth_C); // Token of the receiving hardware C
}

Gyromike · April 29, 2020, 1:00am

Does that make it change when you change servers?

Perhaps I just need to better understand the documentation.

khoih · May 12, 2020, 8:44pm

Update May 12 2020

Releases v1.0.15

Update to use LittleFS for ESP8266 core 2.7.1+.
Fix SSL connection bug.
Fix dynamicParams loading bug in v1.0.14.
Add Blynk_WM_Template example contributed by thorathome.

Again thanks to thorathome in GitHub and thorathome in Blynk for testing, bug finding, feature adding, README rewriting, collaborating, etc…

bwouters · May 13, 2020, 3:34pm

@khoih
I am impressed by the developments of the BlynkSimpleEsp8266 WifiManager library.
Is there a way to get similar functionality for the BlynkSimpleShieldEsp8266 library, used for projects that require more complex Mega I/O?

khoih · May 13, 2020, 4:25pm

@bwouters

Thanks for your encouraging words.

There are several ESP8266 AT-command libraries developed with similar functionalities such as:

Blynk_Esp8266AT_WM

ESP_AT_WiFiManager

ESP_AT_WM_Lite

ESP8266_AT_WebServer

You’re very welcome to use and give feedbacks, enhancement requests, bug reports, etc.

Regards,

bwouters · May 14, 2020, 5:17pm

@khoih
Thanks for this clear overview!
For an Arduino Mega + ESP8266 shield libray to use for dynamic WifiManager functionality is ESP_AT_WM_Lite. Light means fewer parameters to configure? Ex. SSID and PW is fixed to the ugly ESP_AT_**** MyESP_AT_***?

khoih · May 14, 2020, 6:47pm

@bwouters

It’s good that you start exploring the libs.

Lite (light-weight) here means you don’t need a complicated WiFiManager with callback functions and a lot of memory which is impossible to use on those resource-constraint boards such as Mega.

Depending on how much memory you can spare, you can turn ON or OFF the dynamic params by using

#define USE_DYNAMIC_PARAMETERS true

Ex. SSID and PW is fixed to the ugly ESP_AT_**** MyESP_AT_***?

The SSID and PW for Config Portal are configurable by using the function

void setConfigPortal(String ssid = "", String pass = "")

For example, in README

In Configuration Portal Mode, it starts an AP called ESP_AT_XXXXXX. Connect to it using the configurable password you can define in the code. For example, MyESP_AT_XXXXXX (see examples):
// SSID and PW for Config Portal
String ssid = "Your-Config-Portal-SSID";
String password = "Your-Config-Portal-SSID-PW";

And use the function in setup()

void setup()
{
// Debug console
Serial.begin(115200);
while (!Serial);

//delay(1000);

Serial.print(F("\nStart Mega_ESP8266Shield on "));
Serial.println(BOARD_TYPE);

// initialize serial for ESP module
EspSerial.begin(115200);

ESP_AT_WiFiManager = new ESP_AT_WiFiManager_Lite(&EspSerial, ESP8266_BAUD);

// Optional to change default AP IP(192.168.4.1) and channel(10)
//ESP_AT_WiFiManager->setConfigPortalIP(IPAddress(192, 168, 120, 1));
ESP_AT_WiFiManager->setConfigPortalChannel(1);

// To configure Config Portal SSID and PW
ESP_AT_WiFiManager->setConfigPortal(ssid, password);

ESP_AT_WiFiManager->begin();
}

bwouters · May 18, 2020, 9:25am

Works perfectly … Great work on the lib!

bwouters · May 20, 2020, 2:29pm

khoih,
We are currently converting our project from wired to wifi functionality and further link it to blynk (and removing node-red dependency).
FYI: We noticed your lib has a EEPROM.h lib dependency what can be a challenge for projects using the much more functional EEPROMex.h lib as if you include both libs in your project there will be a conflict because the simple one defines “static EEPROMClass EEPROM” and the extended lib defines “external EEPROMClassEx EEPROM” so the compiler sees 2 classes with the same EEPROM name.
(Ugly) solution is to rename one of them in the lib and code will compile fine with both libraries used.

khoih · May 20, 2020, 5:17pm

@bwouters

The easiest solution, if you insist of using the EEPROMex library, is to change the file

Esp8266_AT_WM_Lite.h of Esp8266_AT_WM_Lite library , assuming you’re using Mega, from

#include <EEPROM.h>

into

#include <EEPROMex.h>

Just recheck / retest the code to see if changing the lib breaking anything.

Also remember that some EEPROM locations have been reserved for the WM + dynamicParams purposes and use different location to store your params.

I also suggest to move this discussion to the correct topic from now on

BTW, I’ll add in next release v1.0.3

Option to use EEPROMex library, by just specifying from sketch,
Add support to nRF52-based boards, , such as Adafruit’s NRF52840_FEATHER, NRF52832_FEATHER, NRF52840_FEATHER_SENSE, NRF52840_ITSYBITSY, NRF52840_CIRCUITPLAY, NRF52840_CLUE, NRF52840_METRO, NRF52840_PCA10056, PARTICLE_XENON, NINA_B302_ublox, etc. The Credentials and Dynamic Parameters’ data will be stored in LittleFS/InternalFS .

Anything you’d like to suggest to add into that new release?

bwouters · May 23, 2020, 7:06pm

Sounds great. Think your library is already very complete. We noted using some of the setConfigPortal call some weird behavior on iPhones with WEP2 and security but we are still debugging to see what is causing it, apart from that great library.

khoih · June 26, 2020, 3:02am

Update June 25th 2020

Releases v1.0.16

Fix bug and logic of USE_DEFAULT_CONFIG_DATA.
Auto format SPIFFS / LittleFS for first time usage.

murilonascimento · December 11, 2020, 8:42am

Dear @khoih. Congratulations on your work, it has helped me a lot. I would like to know how to prevent a failure / oscillation in the power supply causing the DoubleResetDetector to be involuntarily triggered? I have faced this problem and I do not know how to solve it. My devices after 2 consecutive power outages they enter the Config Portal, that is, the devices understand this power failure as triggering the DoubleResetDetector and do not leave the Config Portal until the information is filled, this is not good because the devices will be disconnected from the server while in the Config Portal in an undesired manner. is this possible to fix? thanks

khoih · December 11, 2020, 4:41pm

It’s nice to know the library can somehow help you.

The power failure issue can be hopefully solved by

Using battery
Using big electrolytic capacitor
Using UPS (Uninterrupted Power Supply)
You can also try to shorten the DRD time (default at 10s to something like 1s). But not sure can totally solve your power failure issue.

// Number of seconds after reset during which a
// subsequent reset will be considered a double reset.
#define DRD_TIMEOUT 10

You can also use the SW, instead of DRD, to force the Config Portal.
Compare the examples ConfigOnSwitch and ConfigOnDoubleReset and see how to change.

Good Luck,

Gyromike · December 24, 2020, 1:37am

It sounds like there should be a timeout added to the double reset config so that it will not hangup for too long.

khoih · December 24, 2020, 2:20am

The DRD is a different and independent library and you certainly can configure its features to whatever way you’d like.

For example, in the ConfigOnDoubleReset example, the time spent in Config Portal (CP) is forced to be indefinite by disable time-out, as this is considered as intentional to do some change to the Credentials. So the CP will stay until valid / new data are entered and saved.

Have a look at ConfigOnDoubleReset.ino Line 666-673 for a way to change the time-out

1. No timeout

  if (drd->detectDoubleReset())
  {
    // DRD, disable timeout.
    ESP_wifiManager.setConfigPortalTimeout(0);

    Serial.println("Open Config Portal without Timeout: Double Reset Detected");
    initialConfig = true;
  }

2. Timeout

If you don’t like to disable time-out, just specify the time-out different from 0.

  if (drd->detectDoubleReset())
  {
    // DRD, using timeout 180s
    ESP_wifiManager.setConfigPortalTimeout(180);

    Serial.println("Open Config Portal with 180s Timeout: Double Reset Detected");
    initialConfig = true;
  }

Gyromike · December 24, 2020, 2:08am

Looks like a reasonable way to handle the problem.

khoih · January 2, 2021, 12:42am

Updated Jan 1st 2021

Major Releases v1.1.0

Add support to LittleFS for ESP32 using LittleFS_esp32 Library
Add support to MultiDetectDetector. MultiDetectDetector feature to force Config Portal when configurable multi-reset is detected within predetermined time.
Clean-up all compiler warnings possible.
Add Table of Contents
Add Version String
Add MRD-related examples.

trungkien20188 · January 12, 2021, 4:00pm

Bạn là người Việt Nam phải không?