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.
 
Сверху Снизу