Stream stops after 30 minutes, if writing to the database in the loop section commented out ( Example : CallBack.ino)

[UnknownKhan2023]

Example : CallBack.ino

If the following line commented out from the loop section of the example: CallBack.ino, Stream stops responding after 30 minutes

count++;
FirebaseJson json;
json.add("data", "hello");
json.add("num", count);
Serial.printf("Set json... %s\n\n", Firebase.RTDB.setJSON(&fbdo, "/test/stream/data/json", &json) ? "ok" : fbdo.errorReason().c_str());

Can you help me to understand the behavior?

[mobizt]

That is not because of what you mentioned.

As long as stream is running in separate RTOS task in ESP32 and schedule tasks in ESP8266, you will get the debug info of stream time out status.

I guess that you use ESP8266 and your code in loop causes blocking operation that causes the new schedule task cannot be created.

The above condition is not possible in ESP32 which stream task runs in RTOS task.

[UnknownKhan2023]

Board using : ESP32

No stream timeout occurred in that period, Esp32 didn't freezes either as other functions running well, fbdo writes to the firebase seamlessly, but stream data has no response over database changes.

I dont know why, but it happens some times in 30 minutes and sometimes in 1 hour.

[mobizt]

You should debug it yourself.

And you should prove what you call "stop responding" without timed out which is not possible in anyway.

You should used runStream() to test what is actually issue but I'm sure that it's not server or library issue.

As long as runStream() was called, you will get the callback when your database at streaming node changed.

[mobizt]

The function runStream will stop the RTOS stream task and takes over the stream operation and it should run in main loop.

This will prove what you call "not responding" will never happened unless your device stuck on some of your blocking code or freeze.

[mobizt]

Another reason is the FirebaseData object used for stream should be defined as global and when it used with callback, it should not share the usage with other Firebase tasks otherwise stream task will stop or will not resume.

[UnknownKhan2023]

Thanks for your reply, let me try and shorted out the issue. I will let you know the updates as soon as possible

[UnknownKhan2023]

Here is my debug data,

[516048][V][ssl_client.cpp:155] start_ssl_client(): Setting up the SSL/TLS structure...
[516051][D][ssl_client.cpp:176] start_ssl_client(): WARNING: Skipping SSL Verification. INSECURE!
[516060][V][ssl_client.cpp:254] start_ssl_client(): Setting hostname for TLS session...
[516068][V][ssl_client.cpp:269] start_ssl_client(): Performing the SSL/TLS handshake...
[517685][V][ssl_client.cpp:290] start_ssl_client(): Verifying peer X.509 certificate...
[517685][V][ssl_client.cpp:298] start_ssl_client(): Certificate verified.
[517688][V][ssl_client.cpp:313] start_ssl_client(): Free internal heap after TLS 103856
[517696][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 47 bytes...
Server - LIVE[517705][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 918 bytes...

[517716][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 177 bytes...
[620687][E][ssl_client.cpp:37] _handle_error(): [data_to_read():361]: (-76) UNKNOWN ERROR CODE (004C)
[620687][V][ssl_client.cpp:321] stop_ssl_socket(): Cleaning SSL connection.
Server - LOST[620698][V][ssl_client.cpp:321] stop_ssl_socket(): Cleaning SSL connection.

[620905][V][ssl_client.cpp:62] start_ssl_client(): Free internal heap before TLS 147500
[620905][V][ssl_client.cpp:68] start_ssl_client(): Starting socket
[621111][V][ssl_client.cpp:146] start_ssl_client(): Seeding the random number generator
[621112][V][ssl_client.cpp:155] start_ssl_client(): Setting up the SSL/TLS structure...
[621115][D][ssl_client.cpp:176] start_ssl_client(): WARNING: Skipping SSL Verification. INSECURE!
[621124][V][ssl_client.cpp:254] start_ssl_client(): Setting hostname for TLS session...
[621132][V][ssl_client.cpp:269] start_ssl_client(): Performing the SSL/TLS handshake...
[625717][V][ssl_client.cpp:290] start_ssl_client(): Verifying peer X.509 certificate...
[625717][V][ssl_client.cpp:298] start_ssl_client(): Certificate verified.
[625720][V][ssl_client.cpp:313] start_ssl_client(): Free internal heap after TLS 103956
[625729][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 47 bytes...
Server - LIVE[625737][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 918 bytes...

[625749][V][ssl_client.cpp:369] send_ssl_data(): Writing HTTP request with 177 bytes...
[672198][E][ssl_client.cpp:37] _handle_error(): [data_to_read():361]: (-76) UNKNOWN ERROR CODE (004C)
[672199][V][ssl_client.cpp:321] stop_ssl_socket(): Cleaning SSL connection.
Server - LOST[672211][V][ssl_client.cpp:321] stop_ssl_socket(): Cleaning SSL connection.
[672214][V][ssl_client.cpp:62] start_ssl_client(): Free internal heap before TLS 147640
[672218][V][ssl_client.cpp:68] start_ssl_client(): Starting socket

[672621][V][ssl_client.cpp:146] start_ssl_client(): Seeding the random number generator
[672622][V][ssl_client.cpp:155] start_ssl_client(): Setting up the SSL/TLS structure...
[672625][D][ssl_client.cpp:176] start_ssl_client(): WARNING: Skipping SSL Verification. INSECURE!
[672634][V][ssl_client.cpp:254] start_ssl_client(): Setting hostname for TLS session...
[672642][V][ssl_client.cpp:269] start_ssl_client(): Performing the SSL/TLS handshake...
[674465][V][ssl_client.cpp:290] start_ssl_client(): Verifying peer X.509 certificate...
[674465][V][ssl_client.cpp:298] start_ssl_client(): Certificate verified.
[674468][V][ssl_client.cpp:313] start_ssl_client(): Free internal heap after TLS 103864

Loop() code :

if (stream.httpConnected()) {
if (Device_Led_Status == 0) {
Device_Led_Status = 1;
digitalWrite(Device_LED, 1);
Serial.println("Server - LIVE");
}

} else {
if (Device_Led_Status == 1) {
Device_Led_Status = 0;
digitalWrite(Device_LED, 0);
Serial.println("Server - LOST");
}
}

What I think is,

• UNKNOWN ERROR CODE (004C)
• WARNING: Skipping SSL Verification. INSECURE!
• SSL - Memory allocation failed
  are responsible for disconnecting from the database
  stream.httpConnected() shows false and true frequently for the above errors and re-established the connection withing 2-3 seconds most of the time but it takes sometime 15 minutes to re-establish the connection

stream timeout never happened, but stream.httpConnected() showing FALSE, and database change is not getting by esp32

Could you please help me to understand the behavior?

[mobizt]

Your device free Heap is not enough for the SSL Client (WiFiClientSecure) used in FirebaseData object to work.

You have to reduce your memory (heap) usage in your global variables.

The alternative approach is to use external SSL Client instead of internal SSL Client that consumed approx. 40 - 50k by mbedTLS SSL engine when connecting.

Use this ESP_SSLClient as external client instead for lower memory usage.

To use external SSL Client in this library, follow this example.

When you use ESP_SSLClient, you can set the rx/tx buffer size as in ESP8266 WiFiClientSecure like this.

Any way, you should reduce memory usage because you currently have only 100k free heap which is also critical.

[mobizt]

Do not forget to call setInsecure() in ESP_SSLClient to bypass the certificate verification.

[UnknownKhan2023]

Thanks a lot for your support. above suggestion is great for smooth operations.
Now I am looking for further optimization...

Could you help me to know, (Obviously, if you wish)

• Do you use ESP32 CORE 0 & CORE 1 for different operations for this library?
• Should I use both core for balanced running operations?
• Choosing ESP32 having PSRAM will boost smooth operations?

[mobizt]

You should know that you cannot use core 0 for WiFi task as core 0 is for system tasks which WiFi task is time consuming.

Stream callback RTOS task always uses core 1.

[mobizt]

Library uses PSRAM when device supports it.

The internal Heap will always be used in SSL Client while binary and string payload stored in FirebaseData object will use PSRAM.

The ESP_SSLClient is currently used internal Heap and I have not yet tried it with PSRAM.

Edit:
In ESP32, the memory will be allocated in PSRAM for over 4k memory allocation.

[UnknownKhan2023]

Thanks for everything.... “Keep up the good work!