bot.sendPhotoByBinary Not Working

[HoseinPorazar]

Serial.println("was successfully sent"); is called but nothing is sent to telegram.

[gilang4official]

I have same problem, Serial.println("was successfully sent"); is called

but the photo didn't sent to my telegram.

[tuan-karma]

I have the same problem on ESP32 (SPIFFS).

[mitofile]

I have the same problem but reading file from spiffs. Is this issue related to (https://github.com/esp8266/Arduino/issues/2281)

[grzwolf]

ESP32 TTGO T-Camera-Plus (board 'ESP32 Dev Module' with PSRAM) To me the issue happened sporadically when using SPIFFS, while it happened permanently when sending an image directly from the camera buffer "camera_fb_t *fb". So perhaps a timing thing at Telegram?

In UniversalTelegramBot.cpp UniversalTelegramBot::sendMultipartFormDataToTelegram(..) I added after each "client->print" / "client->println" / "client->write" a "delay(50)".

Now it works reliable, even with shorter delay @10ms. But @1ms again it fails big time. Therefore out of paranoia, I kept 50ms.

Update: After switching to branch V1.2.0 workaround is not needed anymore.

[robotzero1]

@WolfEnders

ESP32 TTGO T-Camera-Plus (board 'ESP32 Dev Module' with PSRAM)

How did you get this working? I've been going round in circles trying to chunk the data. I hacked about with sendMultipart to send a QVGA file in one go but anything bigger doesn't arrive.

[witnessmenow]

I'm playing around with this at the moment, I will be updated soon

[grzwolf]

@WolfEnders

ESP32 TTGO T-Camera-Plus (board 'ESP32 Dev Module' with PSRAM)

How did you get this working? I've been going round in circles trying to chunk the data. I hacked about with sendMultipart to send a QVGA file in one go but anything bigger doesn't arrive.

As I briefly mentioned as an ugly workaround: I literally added after every "client->write" in method sendMultipartFormDataToTelegram a "delay(5)".

I really appreciate the effort, that @witnessmenow is dealing with this subject.

Update: After switching to branch V1.2.0 workaround is not needed anymore.

[javierferwolf]

@WolfEnders @witnessmenow hi, I have the same problem! you said that in your case the problem was solved add after every "client->write" in method sendMultipartFormDataToTelegram a "delay(5)". but i use the v1.2.0 and i added that you indicated but I still have the same problem! will there be any additional arrangements? I use 8266 and I want to send the photo from SPIFFS!

[grzwolf]

Perhaps ESP32 makes the difference. This might be interesting in a future release of the esp package. https://github.com/espressif/arduino-esp32/issues/3722

[jameszah]

Update: (48 hours later)

1. I figured out what branch V1.2.0 means -- it is this project with the master and branches.
2. branch V1.2.0 seems to solve the problem, but I don't know why. It uses client->write rather than client->print, which might be meaningful ??
3. I am still using the master branch with the delay(50) after all the client->println which works, and I have added that solution to the sendPostToTelegram function, which has solved my problem with missing messages.
4. The ftp library I am using has a series of 8k client->write statements which require no delay, although there is some processing between the sends, so there might be some delay ... and they are client->write rather than print, so there could be a defect in the wifi println function.

Update: (24 hours later)

I had some success with this single 2 second delay (below), but after shutting off the pre-existing debug comments, things seem to fall apart. Perhaps the Serial.println() statements were helping by introducing a delay. So I have adopted @WolfEnders solution of the 50ms delay after every client->println(). I am puzzled why the final client->print(end_request); is a print rather than a println, even though is a cr lf in the text??

But that has succeeded in delivering photos every 30 min overnight from 2 devices without fail.

I was send a text message after each picture, and several of those have gotten lost overnight. Perhaps something about closing the channel, and then opening it again a few seconds later.

I also tried to increase the waitforResponse timeout - as some of my responses were exceeding the 1.5s allowed.

I also added this line "if (responseReceived && ch_count > 5)" in the test to see if we should break out of the while loop. The response from telegram would be hundreds of bytes, so if there is a byte or two of noise on that channel, we would continue waiting for the response, or the end of the response timeout.

Original post 24 hours earlier:

I think the problem is in sendMultipartFormDataToTelegram.

After the sending is done it goes into this loop (below), where it gets some trash to set the responseReceived to true, but it has not got the response yet from telegram, and then it breaks out of the while, and closes the connection, before telegram has fully consumed all the data, and thus it abandons that picture. It closes the connection an instant after the client->print(end_request);.

So the following debug statement after client->print(end_request); seemed to solve the problem

    client->print(end_request);
    if (_debug)
      Serial.print(end_request);

    Serial.print("... Done Sending.  Client.Available = ");  Serial.println(client->available());
    delay(2000);
    Serial.print("... 2 secs later.  Client.Available = ");  Serial.println(client->available());
    count = 0;`

Here is the while loop that closes the connection too quickly.

   while (millis() - now < waitForResponse) {
      while (client->available()) {
        char c = client->read();
        responseReceived = true;

... collect up the response

      if (responseReceived) {
        if (_debug) {
          Serial.println();
          Serial.println(body);
          Serial.println();
        }
        Serial.println("... breaking");
        break;
      }
    }
  }

  closeClient();

[cvdabbeele]

Just FYI. I experimented with "client_tcp.writeln" abd "client_tcp.write" (as described here: https://www.viralsciencecreativity.com/post/esp32-cam-motion-alert-send-image-to-telegram) and I can confirm I see the same issues. For a stable solution, I also need to add delays after a write....maybe this info can help you chris

[ischinella]

I encountered the same issue in my project. After trying version 1.2.0 of library (and the code in ESP32-Cam.ino) without resolving the problem, I turned back at current version of library (1.1.0) adding the delay after "client->print(end_request)". My two AI-Thinker ESP32-CAM after 4 days not missed the sending of a single photo not even. Great!

[JulioCalandrin]

I faced the same issue on v1.3.0 and solved it by adding "client->flush();" after every client->write, client->print and client->println calls. Working smoothly :).