I like what you have started. I have a few observations and questions.
I have been playing with this a bit and wonder if it can have the config portal auto start as it does in some other wifi managers. I have not played with this much as it just worked for me in the wifi manager that I have been using.
I use more than one auth code in some projects that use bridge. It would be nice to be able to have the codes paired. I need them next to each other and to change when I change blynk servers. Can This happen in the current code?
I think it would be nicer to move more things out of the code and into the defines. Make is easy to just look at the defines and fill in a few things and be up and running.
I removed the DHT code from the last example and moved things around a bit to make it easier for me.
I like the double reset option and the ability to use different wifi and blynk servers, I can see a lot of potential.
Let’s Encrypt will allow to retrieve certificates for IPs only, so no need in the domain name will be necessary.
Thanks for the info. When do you think that’s ready? How about OpenSSL?
But the majority of people (without more expensive static WAN IP) is using DDNS and still must use domain name.
BTW, great Blynk system you guys have created and made me enjoy, learn, work and think again.
if it can have the config portal auto start as it does in some other wifi managers
Can you clarify? I think Config Portal must start only when absolutely necessary.
Please try, explore, suggest and help find/kill bugs as there is so much a small guy can do.
I just recently got help from people in this forum (@thorathome, @mikekgr, etc.) to enhance, fix the libs.
You’re very welcome to give a free hand, either open issues, suggestions here or GitHub, especially as you’re an experienced programmer.
Plsalso see
I use more than one auth code in some projects that use bridge. It would be nice to be able to have the codes paired. I need them next to each other and to change when I change blynk servers. Can This happen in the current code?
Please explore and I think this feature is ready from recent MultiWiFi/MultiBlynk release v1.0.7
I think it would be nicer to move more things out of the code and into the defines. Make is easy to just look at the defines and fill in a few things and be up and running.
Examples are redesigned to separate Credentials / Defines / Dynamic Params / Code so that you can change Credentials / Dynamic Params quickly for each device.
In regards to autostart. What I really need is for it to open the portal from the phone when it connects to the portal wifi so that I am not required to go to the browser and enter the ip address. This happens with other wifi managers.
I see that I can add additional config data. but the point made here is that the blynk key needs to be connected to the blynk server. in my case I need two keys tied to each server others may need more.
In regards to autostart. What I really need is for it to open the portal from the phone when it connects to the portal wifi so that I am not required to go to the browser and enter the ip address. This happens with other wifi managers.
That’s good to have. Could you help exploring how they do that. I’m having too much in my plate now. Certainly will add this good feature when ready.
in my case I need two keys tied to each server others may need more.
So the current 2 Blynk Servers / Blynk Tokens are not enough? You need to add more BlynkServers/Tokens in dynamic Config Data and have them used to auto-connect to Blynk?
I’ll explore this option whenever having time, but I’m afraid this feature is not popular and necessary.
Please discuss with use cases.
BTW, these discussions are becoming too technical for the people in this forum. I think I’ll create a Blynk_WM_Dev private repository and invite people interested and willing to contribute to participate, collaborate, enhance, maintain, etc. Certainly will invite you in if you’re OK with that.
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 @Gunner explains the basics in a sort of “Blynk Bridge for Dummies” way
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.
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
}
@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
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_***?
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
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);
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.
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?
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.
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
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.
