Hi Blynkers. For the past couple of days, all of my ESP8266 devices have gone offline, hanging on the SSL connection to the (US) Blynk server blynk-cloud.com. I have been using Blynk WiFiManager successfully for a long time. New 8266 compiles will not connect via SSL. Existing ESP8266 devices stopped connecting via SSL.
ESP32s are all working fine.
Recompiling my ESP8266 apps for non-SSL WiFiManager connections work. Recompiling for SSL hangs up trying to connect, WiFiManager’s Config Portal comes up with the correct info. Same with existing ESP8266 apps.
Hey everyone. Unfortunately that’s the only cure for this issue.
We’re sincerely sorry for this, but due to some technical limitations, as well as the fact that we’re fully focused on the New Blynk Platform release, we’re not going to fix this particular issue.
Ideally, we’d have to move all certificates to Let’sEncrypt, instead of self-signed certificates.
But due to technical reasons, we cannot perform such migration (it would impact a much broader audience, make even more devices unusable, require re-flashing devices, etc).
If you’re using ESP8266 SSL combo, just disable SSL and re-flash your device.
We’re now working hard to avoid such issues with the upcoming release.
Personally, I think that this is sends out a negative message to those Blynk users who have bought energy and expected to continue to be able to use the Blynk cloud servers (at least until a new version of Blynk was freely available), in the same way that they had been using them previously.
@PeteKnight Actually, there’s not much we can do. We have analyzed several probable solutions, each of them is creating more troubles than resolves. I’m trying to be clear and honest here, instead of making promises that we cannot fulfill.
Additionally, according to our data, ESP8266 + SSL combo is not widely used.
As @Pavel said, the old platform stays there. We’re not shutting down and we’re doing our best to keep it going for a good period of time (which is still TBD).
I’m one of the guys with a bunch of ESP8266 SSL platforms running round - ESPs and SONOFFs, many of which are in waterproof boxes. I use the powerful @khoih WiFiManager library and always go with SSL. Yes, Blynk is delightfully nearly free for me. I enjoy working with Blynk, but this one is painful.
And I do understand the balance between keeping old systems running and deploying new software.
But this breakage came suddenly and without warning. Now I have to open up and reflash multiple units, many of them manually (SONOFFs). OTA isn’t engaged on any of them because the systems are all hanging on the Blynk connection. Plus, they’ll all be talking to your servers unencrypted for some time, always a bad idea.
So I volunteer to help beta test your new Blynk, and will support the community. But this one hurt. Hope to not go through it again. Thanks.
@thorathome Thanks for your understanding.
At this stage, we cannot recover connectivity of your units without re-flashing them, and we feel your pain. Sorry about that.
With the new Blynk, we have a way to upgrade your unit OTA, even if device is not connected to the cloud. The only requirement is to integrate a physical button to reset your device (i.e. clear credentials).
So yeagh, we’re definitely trying to eliminate such issues in future.
I use Blynk’s Device Tiles and Blynk.inject for my personal project only because the wifi config process is more seamless and quick but that uses the SSL library and i tried changing the code and commenting out the USE_SSL flag and changing the library to the non ssl library but that still doesn’t seem to work. it’s still trying to establish connection at port 443 which is for HTTPS. Has anyone been able to change the blynk inject template to work with the non SSL libraries.
Also disappointed and impacted by this quite significantly.
If I move my devices to a local server install, will there be a version of the new platform that runs locally as well ? Or Will I have to migrate once again once the new platform is released ?
It seems unlikely that the new version of Blynk will be released in a form that can run on a local server - at least in the short term.
Migrating your current projects to a local server is very easy - via the Clone QR code process.
Migrating to the new version won’t be possible - it will be a case of setting everything up from scratch, with the exception of the sketches that run on your devices. These sketches will just need some minor modifications unless you want to take advantage of some of the new dynamic provisioning and OTA update features.
The app and datastream (virtual pin) setup are different in the new version because it works in a very different way, and much of the configuration is done via the web portal.
If you want SSL in the short to medium term, without a lot of work, then I’d set up a local server.
You are outstanding @khoih . Thank you for responding and for publishing on a Sunday.
I have loaded your new Blynk_WM release 1.3.0 and am using the SSL version with no issues on ESP8266 and SONOFFs. Thanks.
I will test 1.3.0 on ESP32 later this week.
While I do not wish to create any more work for you, can you please explain the difference between “True SSL” and and “insecure mode”? Thanks again and in advance.
permits you to actually connect to a TLS server (port 443,9443, etc., especially with expired CA Certs such as Blynk Cloud). It won’t let you connect to plain non-SSL server because full encryption is still required.
You never have to worry about CA Certs’ update and to include every trusted CA root certificate of every TLS server
Still requires encryption. It just does not validate the certificate or fingerprint. Insecure because we could be subject to a MITM (Man-In-The-Middle) attack.
It’s still much better than plain non-SSL mode which just communicates using no encryption at all.