Hi, I observed the following strage behaviour from time to time:
I’m using a ESP32 and I communicate with varions devices over wifi.
From time to time Blynk indicates to be offline in app and console but the application is running normal over wifi with other devices.(monitoring via serial port).
In my code I check regular with Blynk.connected() if wifi and Blynk is still connected. Even in case Blink indicateds to be offline Blink.connected() returns “true”. Can anybody explain this ?
> if (!Blynk.connected() ) {
> if(DEBUG_blynk){
> Serial.println(F("[WIFI] Lost Blynk server connection"));
> }
> Blynk.connect();
> } else {
> if (DEBUG_blynk){
> Serial.println(F("[WIFI] Blynk OK"));
> }
> }
The result returned by Blynk.connected() doesn’t change from true to false immediately.
It changes when a heartbeat ping to the server fails, which could be quite a few seconds later, depending on the HEARTBEAT INTERVAL setting that you’re using. This is visible in the bottom left hand side of the web console Device > Device Info screen and seems to default to 45 seconds for most board/connection types.
This means that if you lose connection ten seconds after that last heartbeat it will be around thirty five seconds until Blynk.connected() returns false.
Thanks Pete,
its unfortunately not a question about seconds, it still indicated true after serveral minutes/hours.
Could it be if I flood Blink with to many/fast data it behaves like that ?
In that case you need to provide more specific information about the behaviour you are observing, the code you are running, and the data you are seeing in your serial monitor.
Don’t forget the triple backticks when you post this data.
thats not so easy. The code is in the meantime >8000 lines of code… I thought there is a “easy” explanation about this I will dig in and check if I find our more about the behaviour. I still assume the service handler of the modbus library caused a too fast Blynk.write to the same variable… I will change the code to prevent this and see …
Some common problems in software libraries (Arduino, python etc.) is that the ESP32 randomly drops a Wi-Fi connection, so some checks and balances, check that your Wi-Fi connection is still valid and there are no IP conflicts (most common issue on ESP32). When doing a reconnect, first disconnect and close the old connection properly, then establish a new connection. This will inevitably resolve your issue, the second issue is how many data ppl,oads you are doing per second and per minute, check these to areas and this should solve your issue.
as said WIFI connection is still available as communication to other devices work normal.
I can reproduce the issue: If I add a Blynk.write direct into a the callback function of the modbus - Blynk stopps working after some time. (callback repetition time ~10seconds so this should not be an issue) if I just set a variable in the callback that new data is available and do a Blynk write outside of the callback it works fine. Question is still why Blink.connected() is still true even if there is no connection to Blynk server anymore
when you say “callback function” and “callback repetition time ~10seconds” that doesn’t make sense to me.
Normally a callback triggers automatically when an event occurs, and in the case of the Modbus library that I use (ModbusMaster) there are only two callbacks and these are for pre-transmission and post-transmission.
But, as I’ve said before, it’s almost impossible to help if you won’t share more info.
You say that the Wi-Fi connection is still ok because you are connecting to other devices, so does this mean you are using a closed network (127.0.0.1 etc) from your device or is it a separate network that acts like an access point? A little confusing on your setup.
Blynk disconnect handler is an instruction pushed from the Blynk server (@PeteKnight please confirm I am correct), so if your network is not functioning as it should then the server cannot push the message to the unit.
A simple rule of thumb, keep calls and returns simple, so as you have tested with the MODBUS routine.
Here are the Blynk Connection Status’ so maybe start here in your code to confirm the status
yes I’m working in my local network 172.16… having ESP32, Shelly smartmeter and a solar battery connected to my network. All are accessed with my ESP32 to control and read out. All theses devices are still connected to my ESP and communication is established and working.
Thanks for the additional information about status
No, that’s not how it works.
There is both a server and client side routine. Once the connection is established there is a regular heartbeat/handshake type of process. If the server detects that the device is MIA it shows it as offline and sends an offline notification.
If the client device loses comms with the server then Blynk.connected() == false (in C++ speak) and that flag can be used to drive a reconnection process.
However, one reconnection method is 100% blocking, so no connection = code execution stops.
The other method is partly blocking, in that it will block until the timeout period is met then allow code execution to continue. However, this method is triggered each time Blynk.run() is executed and Blynk.connected == false, so it’s important not to call Blynk.run() by default in your void loop if you want offline functionality.
This is sent once, after connection with the server, to pass data regarding the device to the server, which includes the heartbeat interval.
The heartbeat is a BLYNK_CMD_PING which is enumerated as 6
The server responds with a BLYNK_SUCCESS which is 200 (C6 in Hex).
There’s more info on this here…
Each time Blynk.run() is executed the device checks if new data (an updated value) has been received from the server. If it has then it executes the write handler for the virtual pin that the data corresponds to.
I will dig in and check if I find our more about the behaviour. I still assume the service handler of the modbus library caused a too fast Blynk.write to the same variable… I will change the code to prevent this and see …