First of all, I would like to say warm thank to the Blynk & its library development teams for the update.
I love using Blynk as I am doing at the moment and go on.
When Blynk library has an update, does it have any impact on running ESP the ones we did upload the code being used at end-user side ? Do we need to re-upload the code for those ESP?
No, it will keep running. You may or may not update the code. If you re-upload the same code with the new libraries installed, the running code will of course be run with the new library.
Keep in mind though that updates usually contain fixes and new functions, so it may be needed to update if you are currently running into problems or want newer things.
I’ve been running a couple ESP’s on very old libraries because I simply forgot to update (they just switch a relay, which works fine in any version). But if you want more, you need to stay up to date
BLYNK_APP_CONNECTED() { // Called when Smartphone App is opened
Serial.println("App Connected.");
}
BLYNK_APP_DISCONNECTED() { // Called when Smartphone App is closed
Serial.println("App Disconnected.");
}
Actually I am not aware all of functions of the blynk’s library so when I have seen these above ones shared by @Costas I feel they are very useful that I am thinking for some new tasks with those. Thanks.
@Dmitriy to reply to this and you, the APP_CONNECTED/DISCONNECTED doesn’t seem to work. I’m tailing the log files while I close the App, but it doesn’t show App has disconnected or something similar.
@Lichtsignaal it’s not entirely true to say ESP’s will continue to function without upgrades. I have a “Blynk” temperature sensor hooked up to an OLED on my desk that has been running for a year or so. Due to changes over the last year the time shown on the OLED is wrong by 3 hours. Not a problem for this project but some projects will completely fail if the time is incorrect because users didn’t upgrade to the latest server / app / library etc.
And as for updating, of course it will eventually go wrong because legacy stuff will be moved out. But for simple applications, as you mention, it’s ok to stay behind for a bit
Maybe it was the TimeInput changes that are affecting my hardware. Not even sure what sketch my WeMos is using but at one time I was using a very complex system of reading the project details to set the time every 24 hours. Not a good idea on my part.
TimeInput changes didn’t have backward compatibility, right?
@Dmitriy this is only to emphasise that Blynkers should regularly upgrade app, library and server if applicable.
It looks like your backward compatibility for the RTC widget fails under certain circumstances.
As per my earlier post, one WeMos has been happy for the last 12 months without me touching it. Now I have “tocuhed” it the WeMos is not happy, confirmed by the attached buzzer sounding every 20s.
I noticed some time ago that the time shown on the OLED was showing GMT rather than local time. Wasn’t really a concern as I knew you had changed the RTC widget and time wasn’t really important for this project. It just means the the data log is 3 hours out etc.
I dug out a version of the sketch from 12 months ago that is almost the same as the one running on the WeMos. It’s using 0.3.4 so it shows how old it is.
I haven’t looked at the project in the Blynk app for maybe 12 months but I found it amongst the 100 or so projects I have across my various accounts and servers. As soon as I took a look at the RTC settings to check the timezone the WeMos project fails to function.
It’s a project that uses deepSleep and it checks for a 1970 date during bootup. If the RTC sync fails for whatever reason it sleeps for 20s and tries again. Poor coding decision on my part but it served a purpose at the time. Simply checking the timezone setting in the RTC widget means it now fails RTC sync 100% of the time whereas for 12 months sync was 100% successful.
I’m not entirely sure why it now fails to sync but I’m guessing it’s simply because of your new implementation i.e. not tied to a virtual pin and that simply checking the timezone settings in the app breaks the code. I am guessing that viewing the timezone settings is wrongly telling the system something like new RTC widget being used and must therefore use the new RTC widget code syntax.
Edit: on reflection probably relates to the timezone bug fixes you made rather than the virtual pin removal. Wasn’t negative timezones buggy originally or was that just for the Timer / TimeInput widget(s)? Not important.