mobizt / Firebase-ESP32

[DEPRECATED]🔥 Firebase RTDB Arduino Library for ESP32. The complete, fast, secured and reliable Firebase Arduino client library that supports CRUD (create, read, update, delete) and Stream operations.
MIT License
414 stars 119 forks source link

Assistance Needed with Connection Refused in Firebase ESP32 Library #300

Closed Helmar0 closed 8 months ago

Helmar0 commented 8 months ago

Dear Suwatchai K. I hope this message finds you well. I've been actively using the Firebase ESP32 library (version 4.4.8) in my project, and I appreciate the work you've put into this library. It has been a valuable tool for me.

However, I've been encountering intermittent connection issues when working with the Real-Time Database (RTDB). While I've made some progress in addressing these issues, I'm reaching out for assistance with a specific goal in mind – to reestablish a new connection with the RTDB without the need to restart the entire ESP32 using ESP.restart().

Here are some of the details of my experiences:

  1. Random "Connection Refused" Errors: I've observed that the "Connection Refused" error is seemingly random and can occur at any point during an update or query to the RTDB. I have taken measures to check the Wi-Fi connection and the state of Firebase before each operation.

  2. "Response Payload Read Timed Out" Error: A new issue has emerged – the "response payload read timed out." Unlike the random "Connection Refused" error, this one appears more deterministically. It often occurs on the 100th operation and similar intervals, such as the 200th, 300th, etc. The error is sensitive to the speed of updates, and for shorter intervals (e.g., 0.5 seconds), it exhibits a very specific pattern. One solution I've implemented is to increase the retry attempts using Firebase.setMaxRetry(fbdo, 3) when this error occurs.

  3. Strategies Implemented: I have taken several steps to address these issues, including resetting the Wi-Fi connection, creating a new FirebaseData object (fbdo), and reinitializing the Firebase connection. While some of these actions have mitigated the problems, they haven't eliminated the root cause.

In my recent communication with you, you mentioned that the Rx and Tx buffer sizes I set for fbdo were too large. However, even after adjusting these sizes as recommended, the issues persist. You also pointed out that the errors might occur when working with large data at the node being updated. I have reviewed the size of my data, and while it's not excessively large, I am exploring ways to reduce the payload size.

I'm reaching out for guidance on how to establish a fresh RTDB connection without having to resort to a full ESP32 restart. Is there a way to reset just the RTDB connection or identify and rectify the issue that is leading to these connection errors?

I understand that network-related issues can be complex and multifaceted, and the solution may vary depending on specific environments. However, your insights and guidance will be highly appreciated. I'm committed to resolving these issues to ensure the reliability of my project.

Thank you for your time and support, and I look forward to your expert advice on addressing these challenges.

Best regards,

Helmar Alvares

mobizt commented 8 months ago

You can delete these two lines of undef macro then you will understand why I mention you to reduce the data size on your database. https://github.com/mobizt/Firebase-ESP32/blob/9f264df8c996c3f4515293b1f34e2725c0b68cc1/src/client/SSLClient/Custom_ESP_SSLClient_FS.h#L5-L6

mobizt commented 8 months ago

SSL client was unable to handle incoming incomplete SSL encrypted data which library does not report all SSL error which assumed to be connection refused (actually no decrypted data received because BearSSL gets truncated SSL encrypted data from server as rx buffer is too small).

For the response time out, it is because internet condition is poor, or server drops the connection due to time out.

This should not repost as issue because it is user network specific.

mobizt commented 8 months ago

There is no reset as it is not infinite operation. It is about HTTP request and response.

To just stop the sever connection (closing the session) without clearing the data in FirebaseData, use fbdo.stopWiFiClient().

To stop session and clear all data, use fbdo.clear().

Helmar0 commented 8 months ago

Thank you for your prompt response and the information provided. I understand the issues you've explained, but my primary concern is finding a way to re-establish the connection service with the Firebase Realtime Database (RTDB) without restarting the entire ESP32.

As you mentioned, the "connection refused" error may occur due to various reasons, and it can be challenging to handle in a way that restores the connection or resolves the error. I would like to explore options to handle this particular issue more gracefully, without resorting to a full ESP32 restart.

Is there any guidance or suggestions you can provide to achieve this goal? I'm keen to ensure a more seamless experience in handling these connection-related errors.

Thank you for your continued support and assistance.

Best regards,

Helmar0 commented 8 months ago

I want to apologize for not noticing your previous message. Thank you for providing additional information and clarification. Your guidance is highly appreciated.

I will test the methods you've recommended: fbdo.stopWiFiClient() and fbdo.clear(). These seem to be valuable additions to our toolkit for managing Firebase connections, and I'm eager to see how they can help improve the handling of connection issues.

Your prompt and helpful responses are always invaluable, and I'm grateful for your ongoing support.

mobizt commented 8 months ago

Terminating server connection is not the way to fix "connection refused" and "response read time out" unless it answered your inquiry to reset the Firebase connection.

I recommend reducing the payload and set up the proper SSL buffer size to make sure that the SSL client is ok, and the problem is from network or internet which you need to find out.

Sometimes change the board can help by using board from well-known manufacturer (good quality PCB design and fabrication involved much in ultra-high frequency application).