Теряются GET запросы

Здравствуйте. Есть код отправляющий GET запрос с данными из UART от датчика в веб. В месте, где стоит модуль ESP32, плохая связь, Wi-Fi отваливается и частенько запросы теряются. Прошу помощи в решении проблемы. Сразу говорю - связь никак не улучшить. Данные приходят каждые 5 секунд, а сеть пропадает на 10-15 секунд.

void SendGET(String reciv){   //Функция отправки get запроса на сервер
  if(WiFi.status()== WL_CONNECTED){
    HTTPClient http;
    
    String serverPath = serverName + reciv;  //URL-адрес
    http.begin(serverPath.c_str());
      
    //Отправка HTTP GET запроса
    int httpResponseCode = http.GET();

    if (httpResponseCode>0) {
      Serial.print("Код ответа HTTP: ");
      Serial.println(httpResponseCode);
      String payload = http.getString();
      Serial.println(payload);
      Serial.println();
    } else {
      Serial.print("Код ошибки: ");
      Serial.println(httpResponseCode);
    }
    // Освобождаем ресурсы
    http.end();
} else {
    Serial.println("Нет подключения к Wi-Fi сети");
  }
}

Не очень понимаю, чего вы хотите от форума. Если запросы отправляются каждые 5 сек, а связь пропадает на 15 - естесственно, запросы будут теряться.

Хочу узнать пути решения на основе опыта других людей. Связь пропадает периодически, бывает за целый день ни единого разрыва :grinning:

Если данные нужны несмотря на то, что они устарели - накапливать их во время обрыва связи и отсылать вторично, когда связь восстановится.
Если данные по прошествии 15 сек утратили актуальность - ничего не делать

Понял. Данные не теряют актуальность. Я правильно понимаю, что хранение этих данных на флешке ESP не лучшая идея? Постоянные перезаписи убьют её?

ничего не могу сказать.

Опишите подробнее свою задачу, может кто и откликнется.

Подробнее: на UART порт подключен RFID считыватель. Необходимо при появлении метки отправлять её EPC номер и время пребывания на сервер. Метки появляются каждые 5-30 секунд. Вокруг ESP стоит много высоковольтного оборудования, много разночастотных помех и наводок. Проводом не подключить. Сейчас оно работает, но отвалы Wi-Fi сети случаются, в сутки до 6-10 раз на периоды до 15 секунд.

Читайте response_code. если ошибочный отсылайте снова и снова, пока не уйдет.

Новые данные получается будут проигнорированы, пока я с одним запросом вожусь?

Как напишете. Можно ведь отсылать запросы только тогда, когда на считывателе нет карт.
Но вообще отслеживание и исправление ошибок - это отдельная большая задача.

Как бы вы написали это? Может подскажете где подсмотреть пример? Предположу что это буфер-очередь в RAM? У меня нет таких знаний.

Да я не спец, я уже несколько сообщений пытаюсь “соскочить” с темы, а вы все спрашиваете:)

1 лайк

Понял вас, все равно спасибо за ответы. Поковыряюсь сам и вернусь в тему. Может и какие-нибудь гуру заметят тред и подскажут решение :face_with_monocle:

зачем хранить на флешке? Сколько раз в минуту будет перезапись в одну и ту же ячейку? Через сколько миллионов лет убьют флешку, если запись будет раз в секунду?
Если доставка не гарантирована, то надо использовать протокол с подтверждением доставки. Тот же MQTT имеет атрибуты для гарантированной доставки. Или простой ModBus. В GET не нужно упираться в таких условиях.

Зачитай чонить про “очередь”(Queue)

ESP32 выпускаются с UFL разъемом, куда втыкается внешняя антенна.

Любят же на форумах отвечать вопросом на вопрос… :grinning:
MQTT не подходит - ему нужен брокер, а в моих условиях разрешен только локальный, следовательно еще один сервер поднимать ради 5-10 устройств. Про ModBus обещаю почитать. Но тут скорее протокол связи надо менять, например на LoRa. Но это снова уже нецелесообразно большие траты денег, времени и сил на небольшой тестовый проект. Спасибо.

Модуль конечно же используется с U.FL на борту и внешней всенаправленной антенной. Только тут дело в другом. У ESP слабая мощность усиления, а у роутера хорошая и размер антенны тут, по моему мнению, мало на что повлияет. Это как если мы с вами встанем по двум разным берегам реки и будем кричать что то друг другу. Вас то я услышу, ибо у вас мегафон в руках, но мне будет сложно докричаться до вас через сложенные ладошки. Спасибо за ответ.

Если антенна заюзана, можно попытаться сократить пакет, чтобы быстрее пролетал.

Я бы попробовал ESPnow, но не совсем понятно пока как ответную сторону забриджевать.

Спасибо, не знаком - почитаю. Но проблему отключения от точки доступа, как я думаю, это не решит. Данные все равно буду теряться. ESP-NOW это скорее больше про энергосбережение в аккумуляторных устройствах и общение между IoT девайсами.

Это, возможно, решит проблему канала. ESPnow не тратит время на переподключение, согласование и пр. Но бридж около роутера все равно нужен.
Однако это дешевле, чем архитектуру на Лору менять.