Aside from the extra overhead, due the SSL, that could be causing the disconnection in the first place…
When using Blynk.begin() and no connection management, if WiFi or even just server connection is lost, your sketch will also stop running.
You need to look at some form of connection management that allows the sketch to keep running, and even reconnect when WiFi and Server is again available.
One example is here:
@shur1k your sketch seems to be running fine here.
I have made a few changes like baud at 115200 as 9600 is only for super slow Arduino’s.
I have reduced the 60s timer to 10s and added a blinking Blynk LED on V0.
Providing your router doesn’t crash and that you manually reset your ESP after each local flash it should run forever without any connection management modifications.
I am using the following settings:
Blynk library v0.5.0 on their cloud server. Android app version 2.18.2
lwIP v1.4 Prebuilt and master Core as it was about 3 weeks ago (not 2.4.0 release).
#define BLYNK_PRINT Serial
#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266_SSL.h>
char auth[] = "xxxxx";
char ssid[] = "xxxx";
char pass[] = "xxxx";
BlynkTimer timer;
void myTimerEvent()
{
Blynk.virtualWrite(V0, 0);
delay(100);
if (Blynk.connected()) {
Serial.print("[");
Serial.print(millis()/1000);
Serial.print("]");
Serial.println(" Blynk is connected");
if (WiFi.status() == WL_CONNECTED) Serial.println("WiFi is Connected");
else Serial.println("WiFi Connection is lost");
}
else {
Serial.print("[");
Serial.print(millis()/1000);
Serial.print("]");
Serial.println(" Blynk is not Connected any more");
if (WiFi.status() == WL_CONNECTED) Serial.println("WiFi is Connected");
else Serial.println("WiFi Connection is lost");
}
delay(100);
Blynk.virtualWrite(V0, 255);
}
void setup()
{
Serial.begin(115200);
Blynk.begin(auth, ssid, pass);
timer.setInterval(10000L, myTimerEvent);
}
void loop()
{
Blynk.run();
timer.run(); // Initiates BlynkTimer
}
Please note the team behind the ESP8266 Core development are not entirely happy with their SSL implementation of axTLS. They are looking to switch to BearSSL. ESP8266’s really start to struggle with axTLS when you start to add complex libraries to your sketch so you would need to add functions one at a time and see if the ESP still runs OK. That is, don’t add 100 widgets and then test your project, build it up slowly.
This is Serial Monitor for your sketch:
[24006] Connecting to Myhomewifi-2797
[25009] Connected to WiFi
[25009] IP: 192.168.1.239
[25510] Got time: Wed Feb 28 15:02:19 2018
[25510]
___ __ __
/ _ )/ /_ _____ / /__
/ _ / / // / _ \/ '_/
/____/_/\_, /_//_/_/\_\
/___/ v0.5.0 on Arduino
[25530] Connecting to blynk-cloud.com:8441
[26231] Certificate OK
[26295] Ready (ping: 62ms).
[36] Blynk is connected
WiFi is Connected
[46] Blynk is connected
WiFi is Connected
[56] Blynk is connected
WiFi is Connected
[66] Blynk is connected
WiFi is Connected
I will leave it running for a few hours but with the correct Core settings it looks OK.
@shur1k looking back at one of your earlier posts I see you are missing the heartbeat with your “real” sketch.
This is exactly the same as covered in the link by @PeteKnight when using “bad Core” settings and DHT sensors.
Thanks @Gunner, @Costas
Just a few remarks. It’s not my sketch, it’s an example from the Blynk Code Builder, just to show that the problem is not in my code. And it worked fine for a 2 or 3 hours, when I’d started it yesterday. And only after that time it started to face troubles with connection. Please, note, that the both devices were disconnected at approximately the same time, regardless the different firmware running. The second device was running a pure blynk I can say.
@Gunner, I can rewrite the code to use the manual reconnect, but I don’t think it will help, As can be seen from the log (serial port messages), there were endless attempts to reconnect, but with no luck.
I think, that the most probably reason (as @Costas described), the problems with SSL inside the ESP8266 core. I’ll probably switch off the SSL in one of my devices and will see if it helps.
Thanks to everybody once again.
It’s not just SSL Core that is buggy it’s the official Core 2.4.0 release especially lwIP and combined with DHT sensors.
If you run a very basic Blynk sketch without any sensors the Core bugs might not be a problem but as soon as you start to add SSL, DHT, hostname, other lwIP functions you are likely to have problems.
Most of the Core bugs have been fixed and you need to pick up the master with Git until they release the new Core.
Correct… the manual reconnect is more for specific scenarios, so far as I can tell, but doesn’t hurt to have it.
I just thought you were trying to have the serial prints run when not connected to the server… for that you will need the isolate the Blynk.run() command to only process when connected to the server.
@Costas I am still unclear about all these bugs that are supposed to be lurking due the bad core… perhaps you can take a look here… it just keeps running fine… even before connection management I have just added.
2.4.0 Which should be the latest “release” as both rc1 & rc2 show as older versions in the IDE
2.4.0-rc2 is the version before 2.4.0 and generally didn’t seem to have some of the issues found in 2.4.0.
I don’t know precisely why some users don’t experience the bugs and others do, but they are there along with the bug fixes.
I think I was experimenting due to various RGB Strip driver options I was using before I settled on Fast_LED. That sketch is doing a lot, all at once, so seemed wise to stretch out the heartbeat. And it works, so I never reset it 
@Gunner you are setting OTA hostnames whereas others are setting just hostnames. After the very first hard reset OTA sketches don’t need any further hard resets to keep running were sketches flashed locally require a hard reset after every flash. You don’t use Serial Monitor as you are using OTA and wouldn’t see if the ESP had a reset.
What is the current uptime for that project?
Only 192 min… but that is becasue I am constantly fiddling around and testing that and other projects and resetting my router… but even when I leave things alone, they may reset due to whatever… but, they keep running.
My purpose for further inquiry in this topic was that I also always keep all other libraries updated (and eliminate any duplicates)… so I was just wondering if instead of always assuming the “buggy” core (although I agree, it is probably partially to blame… price of constant development), perhaps there are other library conflicts, corruption, version, etc. at play with many of these “common” disconnection issues?
I don’t know who did the magic, but both of my devices work fine from the early morning. No disconnects can be seen. The temperature data is being sent each 15 seconds from each device and I don’t see any gaps on the graph. Will see what will be further.
One of my devices disconnected from the server after a day and a half staying connected to WiFi . The second one couldn’t reconnect after the WiFi signal lost. Reboot solved the problem as usual. Didn’t try without SSL yet.
@shur1k do you have any Serial Monitor data for the disconnection?
Did you reboot the ESP after the last local flash before you began the test?
Do you have any idea what caused the disconnection?
Did the ESP lose WiFi connectivity, router problem or did the internet “break”?
Unfortunately, no. But I strongly believe, that it is the same Certificate validation problem.
It (*actually both of them) was rebooted several times before starting the test
I think, it is the same Certificate Validation problem.
As I already wrote, one of the devices lost the WiFi connection and couldn’t reconnect to server after the signal was renewed. The other one didn’t lost the signal and was all the time connected to WiFi, but lost the connection to server after a day and half of normal work.
If both are running SSL then based on your comments and our tests then I don’t think SSL is an issue.
Sounds like you had some random WiFi issue for the ESP that crashed. For me I would guess that the reason for the ESP not automatically reconnecting is an ESP Core issue similar to this https://github.com/esp8266/Arduino/issues/4242
As you will see the dev’s are still trying to resolve an issue with WiFi.disconnect().
You need to run both devices hooked up to Terminal app’s like Serial Monitor and Termite to get a better understanding of what’s happening. In addition try to track down the reason for the WiFi disconnect like proximity to routers, microwaves etc.
Connection Management, as covered in the docs, might help but if it’s a problem with the Core then it may not fix the problem.
@Costas. the problem is not in WiFi connection, the problem is in connection to Blynk server. As my previous test shown (see the log in post 39) there was no WiFi connection lost, just the connection to Blynk cloud server was lost.
As for my second test, the WiFi connection lost was made by the purpose, just to check if the device will be able to reconnect to server. And it failed. WiFi connection was restored, but the connection to Blynk server wasn’t.
I’ll try to leave at least one of the devices connected to terminal for a long period of time to see the messages, but I don;t think, that there will be something new.
Perhaps you could clarify this statement.
I am going to write what I thought you had written and you can correct my statement.
Device A disconnected from the server but the WiFi connection was never dropped.
Device B lost WiFi connection and didn’t automatically reconnect to the Blynk server.
Manually rebooting devices A and B reconnected them to the Blynk server.
Device A presumably reconnected to the Blynk server automatically.
Device A and device B are both connecting via SSL.