It is not good to use the wifi check in the library

[cotestatnt]

It is not good to use the wifi check in the library

[cotestatnt]

You are right, but the library is so deep dependent on wifi functionality for the moment that it don't make so big difference.
Aniway I'm planning to extend support for others platform / devices so I will definitely follow your advice (I'm waiting delivering of some ethernet boards for start developing).

Regarding the loss of connection with Telegram server, after some time without responses, connection should be resetted thank to the message's timestamp check. Have you some more detailed information about the issue?

[bergutja]

I have no more information about that, but I have observed that in the esp32, the camera heats up with higher processor speed and that causes more errors (ideally 80Mhz).
In addition, the continuous consumption of the camera causes failures in the wifi of the ESP32, this is avoided by turning off the camera (-40mA), and only activating it when a photo is requested.

[bergutja]

You are right, but the library is so deep dependent on wifi functionality for the moment that it don't make so big difference.
Aniway I'm planning to extend support for others platform / devices so I will definitely follow your advice (I'm waiting delivering of some ethernet boards for start developing).

Regarding the loss of connection with Telegram server, after some time without responses, connection should be resetted thank to the message's timestamp check. Have you some more detailed information about the issue?

We should think about what happens when:
1- Processor 0 sends a bot check to search for new messages (POST) and waits for a response.
2- If at that moment an image or another command is being sent from processor 1, what happens to the response from processor 0? Is it lost or will it arrive correctly?

[cotestatnt]

I'm deep testing a new version of AsyncTelegram completely independent both from platform and trasport layer.
It works with WiFi, Ethernet and should work also with GSM adapter and with any kind of "Arduino" supported board with enough power to handle a SSL connection (tested unitl now with ESP8266, ESP32, STM32 and nRF52832).

For this reason, support to ESP32 double core is delegated to "sketch side" as user choice (ESP32 example will be updated).

Unfortunately this version will not be backward compatible because we must pass the "base SSL client" to the class constructor.
with this approach I have also obtained a significant improvement in terms of RAM consumption and stability, so i'm plannig to lock this repo in read-only mode and start developing AsyncTelegram2 (?)

[bergutja]

I'm deep testing a new version of AsyncTelegram completely independent both from platform and trasport layer.
It works with WiFi, Ethernet and should work also with GSM adapter and with any kind of "Arduino" supported board with enough power to handle a SSL connection (tested unitl now with ESP8266, ESP32, STM32 and nRF52832).

For this reason, support to ESP32 double core is delegated to "sketch side" as user choice (ESP32 example will be updated).

Unfortunately this version will not be backward compatible because we must pass the "base SSL client" to the class constructor.
with this approach I have also obtained a significant improvement in terms of RAM consumption and stability, so i'm plannig to lock this repo in read-only mode and start developing AsyncTelegram2 (?)

ok, I think it's perfect and it improves the library, thanks.

[woodlist]

I'm deep testing a new version of AsyncTelegram completely independent both from platform and trasport layer. It works with WiFi, Ethernet and should work also with GSM adapter and with any kind of "Arduino" supported board with enough power to handle a SSL connection (tested unitl now with ESP8266, ESP32, STM32 and nRF52832).

For this reason, support to ESP32 double core is delegated to "sketch side" as user choice (ESP32 example will be updated).

Unfortunately this version will not be backward compatible because we must pass the "base SSL client" to the class constructor. with this approach I have also obtained a significant improvement in terms of RAM consumption and stability, so i'm plannig to lock this repo in read-only mode and start developing AsyncTelegram2 (?)

Dear, what about AsyncTelegram2 ? Any news?