That’s my understanding, which is why I use the regular WiFi.begin command with a loop which allows me to specify how many WiFi connection attempts I’ll do before ‘timing out’ and running in offline mode.
I havent tested edgent at all. To me, it seems to offer i) WiFi privisioning and ii) OTA (via blynk web).
But would it help in running a Device in “local mode” when there is no WiFi available? I.e. avoiding blocking.
One usage is:
The Device is a Thermostat with a temp sensor input and relay output controlling a heater. Blynk UI used to a) set target temp Manually or via Automation and b) display actual temperature.
If heater starts/resets, for any reason, and there is no WiFi, I dont want the Device to be blocked. But instead run locally to control the heater with either a hard coded default temp or the latest (saved) set target temp value in blynk ui.
Would edgent be better in “non-blocking”?
If so, interesting - otherwise not a solution.
@jonas great news buddy, I turned off the router then I powered the esp32 and now I can confirm that it’s working flawlessly, even after half an hour of continually running I didn’t notice any blocking or weird activities at all.
Hi John93, I’d like to check back in on this method for WiFi connection to Blynk via BlynkEdgent.begin(). Is this method currently considered the best practice for such connection management? Reason for asking is the many comments and code fragments which appear in the Forum which suggest inserting several kinds of WiFi connection checks and routines (e.g., WiFi.status() != WL_CONNECTED) etc.) into the void loop and elsewhere. As noted above, all appear to be blocking, which as you also note will cause issues if WiFi is not available. Since Edgent is documented to manage both these connections in a non-blocking way, is there any reason I can’t use it in the Void loop to manage these connections?
I’m not sure that you’re using the term “blocking” correctly.
The Blynk.begin() command is a blocking command. If it cant connect to WiFi ir the Blynk server then all code execution will stop at that line in the code. This means that all other code, such as the rest of the void setup, the void loop and any timed functions will not be executed
WiFi.status() != WL_CONNECTED) is not a blocking function. It checks if WiFi is connected and returns true or false. If you then use an if statement to direct the code to a routine that attempts to re-connect to WiFi in an endless while loop then you will have caused code execution to be locked-in to that while loop until a WiFi connection is established, but that’s you who has created that blocking functionality, not the WiFi.status() != WL_CONNECTED) command.
Maybe it would be best if you created your own “need help with my project” topic and provide full details of your hardware, code, library versions etc etc, then describe what it is that you are trying to achieve and what issues you are encountering in the various scenarios that are proving problematic.
Pete, thanks as always. I think I do understand blocking and how it used in this context. I should have been more precise in my use of quoted pieces of code like WiFi.status() != WL_CONNECTED). I was referring to the use of “Blynk.begin()” and subsequent use of the “if” condition. What I am really trying to get at: is it OK to just use BlynkEdgent.begin() or do I need to also use another connection code to independently establish Wifi connection? As you have advised many times, if possible I don’t want to go muck around with the edgent files in the sketch folder and end up out of sync with the latest releases.
Ultimately I want to be able to test for WiFi not present and perform some offline logic in that case. Thanks!
Here is my general code flow:
BlynkEdgent.begin(); // start Blynk IOT with WiFi Provisoning and OTA
// other code
void loop() // keep loop lean & clean!!
BlynkEdgent.run(); // for Blynk IOT & OTA!
I’d suggest that you do a search of the Edgent code for “ WL_CONNECTED” (don’t forget to check the “all tabs” checkbox). Then you might unde4snad more about how Edgent works. As you’ll see, Edgent uses Blynk.config and Blynk.connect rather than the Blocking Blynk.begin.
Edgent does this already, and returns an error code…
#define BLYNK_PROV_ERR_NONE 0 // All good
#define BLYNK_PROV_ERR_CONFIG 700 // Invalid config from app (malformed token,etc)
#define BLYNK_PROV_ERR_NETWORK 701 // Could not connect to the router
#define BLYNK_PROV_ERR_CLOUD 702 // Could not connect to the cloud
#define BLYNK_PROV_ERR_TOKEN 703 // Invalid token error (after connection)
#define BLYNK_PROV_ERR_INTERNAL 704 // Other issues (i.e. hardware failure)