Incompatibility with ESPAsyncWebServer and/or ESPAsyncTCP

[Salomon-MH]

Hello,

I'm having a bit of an issue: I'm planning on using the ESPAsyncWebServer library instead of the ESP8266WebServer library within my sketch which also uses CTBot, however, this seems to break CTBot nearly entirely.

As soon as I add the include to ESPAsyncWebServer and start using the library, CTBot stops working. The weird thing is: It seems to still work partially. What I mean by that: I can still check for messages and reply to those accordingly, but when I try to send a message at another part of the code, this doesnt work anymore. For debugging purposes, I've also included evaluating the testConnection() method, but in this case it returns FALSE.

Further testing showed, that this might be only the case, when the sendMessage(...) function is called in an asynchronous context (e.g. calling a webpage and directly calling a function in this asynchronous call to send a message). I'm not 100% sure about this though.

Do you have any idea why this is happening, and how can I fix this (other than by temporarily saving the desired message to a variable and then sending them using the synchronous loop() call)?

Thanks in advance and enjoy the rest of your weekend! 👍🏼

[shurillu]

Hello Salomon, first of all, which version of the library are you using? I guess the 2.1.3. In any case, the library use the 443 port for negotiating data to/from the Telegram Server. If you use the same port, this could be an issue, so you have to close the WebServer connection before calling any CTBot member functions. If you already close the webserver active connections / don't share the same port, you could try the dynamic allocation. Every time you need to use the CTBot class,

1. declare a CTBot pointer (CTBot* pMyBot)
2. allocate the memory (pMyBot = new CTBot)
3. check memory (if (NULL == pMyBot) <manage the error!>)
4. set the token (pMyBot->setTelegramToken("myToken"))
5. call the CTBot member functions that you need / do all the stuff with the CTBot object
6. release the memory (delete pMyBot)

Obviously you have to connect to the WiFi network once (not every time you allocate the CTBot object). This solution is a bit slower, but maybe it can solve your issue.

BTW I guess the issue is due to some sort of incompatibility/overlap between ESPAsync class (and the ESPAsyncWebServer!) and the WiFiClientSecure class used inside the CTBot class.

Finally you can try the new version (3.0.0) that you can find in the v3.0.0 branch in github.

Let me know if you solve the issue (or if it still exist).

Ceers

Stefano

[Salomon-MH]

Hi @shurillu,

I've temporarily fixed the issue by creating a global String variable as a quick and dirty "message queue", which is checked in the loop() function for content - if it's an empty string (.equals("")), nothing is done; if it has content, the message is sent and the string cleared.

However, there still indeed seems to be an issue / incompatibility between some of the libraries used in my sketch. Once every few minutes, the ESP seems to be completely crashing and rebooting - an exception is thrown via Serial as well, which can then be read. The WiFiClientSecure library seems like a good guess for incompatibility, as this is in every exception thrown by the ESP.

For now, I've reverted to use a different library, which seems to actually be a fork of your repo: https://github.com/cotestatnt/AsyncTelegram This works without these issues, somehow. Kind of sad, because I really like and appreciate your work! I've been using your library for a few years now already - on a daily basis, as part of a home automation project (to notify about sensor changes). At least I'll still be using some of your code basis, as this is a fork of your project. :)

If you still want to further investigate the issue or have any other suggestions, I'm of course also happy to test it out for you if I've got the time. Connection issues (e.g. duplicate usage of the same port, ...) are out of the question, as I only use port 80. Also, since I'm now not using any of the functionalities of your library in an asynchronous context, it has to be some general incompatibility. I could try out the version v3.0.0, if that helps for you.

Thanks for your support and again thanks for the great work! 👍🏼

Greetings from Germany!

Daniel

[shurillu]

HI Daniel,

as some users says, the v3.0.0 have better stability and solves most of the compatibility/reboot issues. There are some major difference between the previous versions:

• no more Strings: the class use only the standard C string and allocate/deallocate the memory when needed. The class keeps the compatibility with the previous versions with some stub member functions. Most of the problems of the previous versions seems to be related to the use of the String class!
• it use the HTTP POST in spite of HTTP GET
• it keeps an active connection to the Telegram Server (increase the execution time of all the communication methods). You can disable this functionality by calling the keepAlive(false) member function so every time you call a connection related member function, a new connection to the Telegram Server will be created and closed as the previous versions did
• there are some changes in codes returned by the getNewMessage member function: check it if you don't use the defined constants
• it can send binary data as text files, images etc...

Basically you should download the library, recompile and run with no (or very few) changes. The v3.0.0 version is in a pre-release stage: I did extensive tests (memory leaks, stability, compatibility etc) but miss some new examples (for this reason is a pre-release). If you want to check it out and leave me some feedbacks, you are welcome, thanks!

Thank you for supporting the library with your feedback!

Greetings from Cagliari (Italy)!

Stefano