• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

esp8266 MQTT client + WEBserver

Efim25

New member
Здравствуйте!
Ситуация такая: на esp поднят MQTT клиент, который работает в паре с Яндекс Алисой

Дома бесшовная сеть на базе микротиков по технологии caps man

В общем через определенное время ESP перестает реагировать на команды (от суток до трех), при этом он связь не теряет (с точек доступа его видно - пингуется), а вот другие устройства его не видят, раза с цатого удается зайти вед морду и сделать какие-нибуть переключения. Но лучше всего помогает перезагрузка через питание.

В доме еще RGB лампа так же на ESP и у нее такие же симптомы
сейчас на праздники хочу сделать отдельную обычную сеть для устройств, что бы убрать влияние бесшовной сети
если надо могу выложить код, может конечно проблема в коде, но учитывая что устройство не одно и код для RGB лампы писал не я, а поведение идентичное, то у меня пока предположение в сторону библиотек от ардуино (несовместимость с бесшовными сетями)
 

pvvx

Активный участник сообщества
Аналогичное поведение у всех устройств на ESP (к примеру "Умные розетки"). Это не зависит от роутеров. Иногда могут работать несколько недель.
Восстанавливаются после перезагрузки путем выдергивания и обратной установки (питанием) или если было отключения электро-энергии...

Вставьте в код принудительную перезагрузку через несколько часов работы.
 

Efim25

New member
Аналогичное поведение у всех устройств на ESP (к примеру "Умные розетки"). Это не зависит от роутеров. Иногда могут работать несколько недель.
Восстанавливаются после перезагрузки путем выдергивания и обратной установки (питанием) или если было отключения электро-энергии...

Вставьте в код принудительную перезагрузку через несколько часов работы.
ну это же не нормально :oops: причем по разрыву связи перезагрузку не сделать (так как связь с роутером не рвется), надо или по времени или еще как
но в любом случае хотелось бы как то это исправить без костылей
 

pvvx

Активный участник сообщества
но в любом случае хотелось бы как то это исправить без костылей
Для этого есть только два метода программирования на малых SoC не имеющих MMU:
1. Строить весь код с использованием только статических буферов. На это у ESP никогда не хватит памяти, а PSRAM не годится из-за скорости.
2. Строить дерево вызовов вложенных процедур с использованием памяти в стеке и решается только на чистом C. Так-же не проходит для ESP.
3. Аналогично п.2, но не в стеке, а типа в FIFO...

Все остальные варианты с C++ годятся для включения светодиода и посылки в цикле сообщения в UART: "Светодиод включен/выключен.". Т.к. каждый проход heap будет освобождаться полностью.
Т.е. никаких WiFi, TCP/IP стеков и тем более MQTT.
 

Efim25

New member
Все остальные варианты с C++ годятся для включения светодиода и посылки в цикле сообщения в UART: "Светодиод включен/выключен.". Т.к. каждый проход heap будет освобождаться полностью.
Т.е. никаких WiFi и тем более MQTT.
блин ну прям печаль.
я думал избавиться от всех строк и переменные сделать глобальными
 

pvvx

Активный участник сообщества
Может помочь, частично. Lwip можно перетранслировать на статические буфера.
Тут надо пробовать написать код так, чтобы после обслуживания запроса/функции вся использованная память очищалась и не оставалось хвостов. А MQTT и TCP нужно постоянно держать всякие структуры...
TCP и MQTT - это явная перегрузка функционала для данного чипа.
И там не только проблемы с "heap". Вполне возможно и кучка других ошибок и неверных алгоритмов, которые возможно поправить.

Предупреждение о бардаке в heap есть где-то и в описании к Arduino ESP, что не стоит использовать string в C++.
 
блин ну прям печаль.
Не спешите выбрасывать все esp в мусорку. Поищите проблему. ESP может работать несколько недель без перезагрузки и глюков с mqtt, web server, telegram, opentherm, espnow и ещё кучей всего навешанного одновременно, проверено.
 

pvvx

Активный участник сообщества
Не спешите выбрасывать все esp в мусорку. Поищите проблему. ESP может работать несколько недель без перезагрузки и глюков с mqtt, web server, telegram, opentherm, espnow и ещё кучей всего навешанного одновременно, проверено.
Проверялось, несколько лет назад, в Прошивка TCP2UART переходника с настройкой по Web. Работало более 2-х месяцев c ИБП, без перезагрузок и постоянным непрекращающимся тестовым трафиком. Но потом стал подводить драйвер WiFi - неизвестные сбросы от сигналов в эфире WiFi. А ESP32 стал уже не интересен из-за дикого потребления и прочего функционала в сравнении с другими чипами. (Arduino я не пользуюсь, т.к. это C++ на неприспособленном для этого чипе)
А ныне, т.к. все мои термометры и прочий рой BLE переходит на Long Range, то ESP32 совсем всё. Он BT4.2 в макс. А остальные ESP32-x без USB, а это в наше время...
 

pvvx

Активный участник сообщества
Не спешите выбрасывать все esp в мусорку.
Аналогично себя ведут все мелкие SoC, по наблюдению за 2 года с "Вумными розетками" имеющимися в продаже. И это действительно печально...
Но системы на Linux, типа Xiaomi Gateway 3, разные board на OpenWRT и т.д. работают стабильно, до высыхания кондеров в БП.
 

pvvx

Активный участник сообщества
А esp32-c3, bt5 и USB есть вроде?
Он немного лучше, по этому их давно взял пачку для опытов. На рабочие проекты всё равно не покатит - нет WiFi6. И там всё та-же технология производства чипа и соответственно и потребление RF части: BLE потребляет как wifi.
У всех новых ESP32-x ущербный USB1.1 (USB2.0FS). Ограничен вдоль и поперек...
Возможно в следующих сделают нормальный (правда уже нет надежды). А пока не встречал дешевых плат с USB напрямую к ESP, и без никчемного USB-UART...
 

enjoynering

Well-known member
В общем через определенное время ESP перестает реагировать на команды (от суток до трех), при этом он связь не теряет (с точек доступа его видно - пингуется), а вот другие устройства его не видят, раза с цатого удается зайти вед морду и сделать какие-нибуть переключения. Но лучше всего помогает перезагрузка через питание.
была у меня такая же болезнь с tthRelay. работало месяцами пока не добавил поддержку https и началось... свободный heap уменьшился с 28КБ до 14КБ и esp8266 стала перегружаться от малейшего обращения к серверу.

Screenshot 2023-02-23 070424.png

решал долго. первое что сделал, полностью переписал server.streamFile(file, contentTypeStr). скорость отдачи файлов выросла на 50% и кол перезагрузок уменьшилось на столько же. потом очень долго расставлял optimistic_yield() и yield(). причем с optimistic_yield() намного стабильнее чем с yield(). сейчас реле работает месяцами и с HTTPS.
 

pvvx

Активный участник сообщества
Раз в 10 секунд реле по https связывается Telegram и проверяет не пришла ли команда от другог бота или юзера.
Такое приложение можно перезагружать каждые 10 секунд и забыть на всё.
В нормальных BLE, без RTOS, перезагружается после каждой передачи-приема и там таких проблем нет, как и "heap".
А дальность связи в LE Long Range уже больше чем WiFi у ESP.
 
Сверху Снизу