ESP32 lost connection but Blynk.connected() indicates connected

Need Help With My Project
2

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.

Pete.

3

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 ?

4

I don’t know.
Maybe it would be better to move away from a hypothetical discussion and for you top provide more solid and specific data.

Pete.

5

ok, forget the second part. Still why indicate Blynk.connected() true even if it appears offline ?

6

In the template for your device do you have an OFFLINE IGNORE PERIOD defined in the Info screen?

Pete.

7

No it is:
Offline Ignore Period
0 hrs 0 mins 0 secs

8

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.

Pete.

9

thats not so easy. The code is in the meantime >8000 lines of code… I thought there is a “easy” explanation about this :wink: 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 …

10

That’s always a good idea!

Pete.

11

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.

12

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

13

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.

Pete.

14

I call modbus read request ever 10 seconds so the callback Or handler which provides the read values will also occure arround every 10 seconds

example: https://github.com/eModbus/eModbus/blob/master/examples/TCP03example/main.cpp

15

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

Python Code

# Connection Status
DISCONNECTED = const(0)
CONNECTING = const(1)
CONNECTED = const(2)
AUTHENTICATED = const(3)
16

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

1 Like
17

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.

Pete.

1 Like
18

Ah, that makes sense, just to clarify on the heartbeat / Handshake message is this

(in Python speak)

MSG_INTERNAL = const(17)					# Internal Message Command

blynksend(MSG_INTERNAL, 'ver', __version__, 'h-beat', self.heartbeat//1000, 'buff-in', self.buffin, 'dev', sys.platform + ' uPython')                             # Heartbeat Message (Send after connection is successful

Or is it each time a value is updated, Virtual Pin or whatever, on the Blynk server? This updated value is seen as a sort of “heartbeat”?

19

@klaus313 - I think this is where you might need to look to find your problem, possibly and issue between internal and external network connections.

20

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.

Pete.

1 Like
21

Thanks Pete, don’t want to hijack this thread, will dig deeper in the info and if necessary open a relevant new thread

1 Like