Espeasy: MQTT перестает работать с 20181008

В 20181004 изменилось следующее:

• [sendHttp] # 1830 Достигнут тайм-аут и ранний выход по таймауту
• [WiFiClient] Установите тайм-аут и сделайте его настраиваемым для контроллеров.
• [Core 2.4.1] Вернуться к ядру 2.4.1 из 2.4.2

А в 20181006:

• [WiFi] Добавьте задержку для попыток подключения в настройках контроллера.

Не могли бы вы протестировать сборку 20181003 и, может быть, эти 2, чтобы сузить проблему?

Я попробую, но боюсь, что не смогу это сделать до субботы. ;-)

Вы хоть представляете, сколько времени пройдет, прежде чем соединение MQTT будет потеряно?
И это как-то совпадает с переподключением wifi?

Насколько я мог видеть, потери Wi-Fi не было.
то, что соединение MQTT было потеряно, было довольно быстро сегодня утром (10 минут), но у меня также были часы в соответствии с последней записью от IOBroker ...
Сегодня вечером я постараюсь запустить хотя бы одну из 3 сборок.

Просто как чек; Вы строите его сами или используете ночные сборки?

еще что проверить:

вы уверены, что MQTT перестает работать?
Мой здесь через некоторое время показывает "Connection LOST", но все еще работает с MQTT.

Единственная ошибка, которую я вижу, это сообщение «Соединение потеряно», хотя все еще работает.
Например, я получаю минуты безотказной работы от контроллера MQTT.
Через некоторое время (от 10 минут до 10 часов) я вижу «Соединение потеряно», но минуты все еще подсчитываются, отправленные через MQTT.

Greetz
Саша

MQTT должен выполнить переподключение, как только обнаружит, что больше не подключен.
См. Также другую связанную проблему @ Sasch600xt :
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

За несколько сборок до 20180927, та, которая, как вы сообщаете, работает нормально, я добавил исправление для контроллеров MQTT, в котором клиент MQTT на ESP выдает себе новый идентификатор клиента, просто чтобы брокер не отказывался от нового соединения, когда брокер по-прежнему предполагает существующее соединение от этого клиента, а клиент думает, что оно отключено.

Можете ли вы увеличить время ожидания контроллера? По умолчанию было 1000 мс, до того, как я ввел этот параметр, и в первой сборке по умолчанию было 100 мс. Позже я изменил значение по умолчанию (для новых настроек) на 300 мсек.
Так что, возможно, вы можете попробовать установить его на 300 или выше (не выше 1000 мс) просто в качестве теста. (независимо от того, какая версия, по крайней мере, та, которая раньше выходила из строя)

У меня была такая же проблема с 1 (из 5) единиц. Я немного поигрался с настройками контроллера MQTT (минимальный интервал отправки, максимальная глубина очереди, максимальное количество повторных попыток и действие полной очереди); настройки, которые теперь работают у меня с этим устройством: 1000 мс, 5/5 и «Удалить старые».

Хорошо, новости ...
Похоже, это та же проблема, о которой говорит blb4github, прокомментированная 12 часов назад. Взял НОВЫЙ агрегат и до сих пор работает без проблем !!!! Похоже, у "старого" есть проблемы с памятью или синхронизацией. Я постараюсь увеличить тайм-аут в этом ... держать вас в курсе ;-)
Кстати ... (Извините ... Самостоятельная сборка с Atom ... потому что мне не нужны все плагины ... Но до сих пор все шло хорошо ...) Вы все отлично работаете над этим ... и насколько я обнаружил только у этого (и, следовательно, у того, у которого есть новейшее ПО) есть эта проблема. Я увеличу настройки и дам знать.

С уважением, Питер

@fraeggle можно ли вставить сюда скриншоты хороших и плохих страниц systeminfo модулей? (разделы esp и storage)

И немного описания оборудования.
Например, у меня такое чувство, что недавно были внесены некоторые изменения в модули sonoff.
Sonoff basic и S20

@fraeggle Не могли бы вы также выполнить полную очистку проблемного узла и начать с чистого
Пустые файлы bin включены в ZIP-файлы выпуска.

Привет TD-er
Я уже стер плохой узел раньше ... Так как я изменил настройки тайм-аута на 800 мс
это стабильно. Напряжение обновляется каждые 120 секунд.

Аппаратно ничего особенного .... потому что все еще ждем прибытия INA219 .. ;-)

С уважением, Питер

взлеты я, к сожалению, закрыл ..

Но я думаю, что с помощью этого "обходного пути" его можно закрыть ... Я действительно думаю, что теперь это проблема Unit ..
Что вы думаете об этом TD-er?

И все же странно, что в этом аспекте агрегаты различаются.
Можно предположить, что стабильность Wi-Fi хуже в одном устройстве

Я согласен, но я думаю, что у этого устройства просто слишком большой диапазон допусков. Как я уже сказал, с тех пор, как я перешел на 800 мс, он отлично работает ...
поэтому, если вы согласны, я закрою это, потому что есть возможность изменить тайм-аут.

Спасибо за вашу помощь..

С уважением, Питер

я нашел "с 20181007 MQTT Open Hab показывает" Соединение потеряно "# 1873.
Может та же проблема?
TD-er скажите мне, могу ли я помочь, создав журналы или что-то в этом роде ...
Использование Openhab (с IOBroker). но до сих пор нет ошибок после установки тайм-аута на 800 мс

Брокер MQTT для OpenHAB, который вы используете, установлен на компьютере в вашей собственной сети или во внешней сети?
А если локально, возможно, он установлен на компьютере, на котором не хватает ресурсов?

У меня также есть тест, запущенный с 394 минут на 20181020.
Тайм-аут 800 мс.
Иногда он отображается как "Отключено" через 24 часа или даже дольше. Но я так и не дожил до двух дней.
И снова, для меня все еще работает после того, как он показывает "Соединение потеряно". Так что меня сбивает с толку именно сообщение. Я буду держать вас в курсе

Connection Lost - это всего лишь информационное сообщение, указывающее на то, что соединение было потеряно.
Но он должен перезапустить новое соединение.
На странице sysinfo вы можете увидеть, как часто соединение WiFi было потеряно и восстановлено, а также как долго оно было подключено к WiFi с момента последнего (повторного) подключения к точке доступа.

Как только соединение WiFi будет прервано, он также предположит, что соединение MQTT необходимо восстановить, поэтому он будет считать, что соединение с брокером MQTT потеряно.
Еще 4 недели назад было возможно, что брокер MQTT не примет новую попытку подключения, поскольку брокер все еще считал клиента подключенным.
Это могло привести к бесконечным попыткам повторного подключения, когда клиент продолжал пытаться подключиться, а брокер не принимает подключение.
Я менял идентификатор клиента MQTT при каждом повторном подключении (добавляя количество повторных подключений к идентификатору клиента), чтобы брокер считал его новым клиентом.
Это приводит к быстрому повторному подключению, с единственным недостатком, когда брокер отправляет LWT (последнее завещание и завещание), поскольку он предполагает, что клиент отключен.

Если это приведет к нежелательному поведению, я могу изменить это на новую стратегию.
Например, при неудачной попытке повторного подключения я могу попытаться сначала отправить правильное сообщение об отключении.

Короче говоря, существует множество вариантов, при которых соединение с брокером может быть потеряно, и я не уверен, почему в вашем случае оно потеряно.
Это может быть тайм-аут, отключение Wi-Fi, неизвестный ответ брокера или другая причина.

хорошо понял.
Очень хорошее заявление, спасибо.
Я сейчас на 507-й минуте / Open HAB controller / 800ms timeout.
Пока все хорошо :)

Должен ли я установить тайм-аут по умолчанию для новых экземпляров контроллера обратно на 1000 мс?

ну ...... дай мне еще 36 часов ..... тогда я лучше знаю об ошибке, приходит также с 800 мс или нет.

629 минута сейчас без проблем ...

странно ... обнаружено после изменения на 800 мс.
Причина последнего отключения | (200) Тайм-аут маяка
Номер переподключается | 3
Что значит das Beacon Timeout?
MQTT все еще работает, но сейчас такой же, как Sasch600txt. Но по-другому, чем раньше ... MQTT все еще работает
только брокер сообщает, что этот не подключен.

Дополнительные сведения о кадре маяка см. В Википедии.
Короче говоря, точка доступа периодически отправляет пакет, содержащий информацию о сети.
Этот интервал обычно составляет 100 TU (102,4 мс).
Модуль ESP пытается прослушивать этот маяк каждый раз, но по ряду причин он может пропустить фрейм маяка. Тайм-аут превышает 100 TU, поэтому он должен пропустить некоторое количество этих кадров маяка, чтобы сообщить о тайм-ауте маяка.
Причины пропустить такую ​​рамку маяка:

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

Таким образом, на узлах ESP то и дело происходит «тайм-аут маяка».
Я упорно работаю над тем, чтобы каждый плагин / контроллер использовал короткие временные отрезки, чтобы сделать задачи как можно меньше блокирующими.

Я могу подтвердить все, что сказал Фрэггл.
Когда-нибудь сегодня вечером я получил "Связь потеряна"

Хороших выходных :)
Саша

@fraeggle :
если он отображается как «Соединение потеряно», попробуйте войти в настройки контроллера ESPEasy, просто отключите контроллер -> сохранить, снова включите -> сохранить. Тогда, по крайней мере, для меня это снова отображается как подключенное. Не решение, но, по крайней мере, интересно :) Вы используете этот IPSymcon?

@ TD-er:
слишком загруженные задачи? ну ... в "ТЕСТОВОМ УСТРОЙСТВЕ", который у меня работает, я отправляю только минуты безотказной работы каждые 60 секунд ...... на этом устройстве больше ничего не работает ..... так что, вероятно, это самая маленькая возможная система

@ Sasch600xt термин "слишком занят", возможно, не самый лучший для описания реальной проблемы.
Способ работы Arduino:

• позвонить setup()
• звоните loop() снова и снова.

Вдобавок к этому версия Arduino для ESP8266 (и ESP32 Arduino) выполняет некоторые задачи за пределами loop() для части Arduino.
Эти задачи связаны с фоновыми процессами, такими как обработка сетевого подключения и входящего трафика и т. Д.
Фоновые задачи выполняются только при:

• конец loop()
• при вызове delay() или yield() из пространства Arduino.

Если цикл занимает более 102,4 мс и не выполняется никаких вызовов yield () или delay (), узел ESP пропустит интервал маяка.
Кроме того, если он выполняет несколько задач блокировки, которые всегда заняты, прямо в тот момент, когда точка доступа Wi-Fi отправляет маяк, некоторое количество маяков будет пропущено.

Когда вы посмотрите серийный журнал (с включенным уровнем отладки), вы увидите статистику времени.
Некоторые из них могут составлять несколько десятков миллисекунд и, таким образом, могут быть причиной этих причин «отключения».

Я мог бы добавить задачу в планировщик, чтобы пытаться прослушивать маяк каждые 102,4 мс. Единственное, я не уверен, как увидеть, когда такой маяк был замечен.

Что касается этой проблемы, я мог бы изучить отключение / повторное подключение MQTT, когда соединение было потеряно.
Какого брокера вы используете? Здесь я использую Mosquito, и он отлично работает с текущим поведением.

хорошо, "слишком занят" было немного проще сказать обо мне :)

Я использую скрипт, запущенный в моем экземпляре ipsymcon housecontrol для брокера MQTT.

Greetz
Саша

Привет, Саша .. Использование IOBroker.
@ TD-er вернулся к сборке 27092018. Брокер Сообщает мне, что все еще подключен ...
Действительно сбивает с толку .. НЕТ ошибок в течение 14 часов (номер повторно подключается | 0)

Сейчас я устанавливаю IObroker на свой компьютер, просто чтобы посмотреть, что происходит.

Редактировать:
45 минут спустя я все еще не могу запустить IObroker на моих компьютерах.
Не уверен, что здесь происходит, но установщик Windows просто не работает (файл служебной bat нигде не может быть найден), а установка в Linux просто не завершается. Он пытается снова и снова выполнять одну и ту же установку npm.
Протестировано в Ubuntu 18.04 на хосте ЦП Intel и Bash в Windows (Ubuntu 18.04)

не уверен с окнами .. я думаю, что есть некоторые зависимости программного обеспечения. Запускаем его на Raspberry.
для Windows ioBroker поддерживает Node.js, как Plattform, и набор настроек. (Загрузить: http://nodejs.org/download/) Сначала должен быть установлен node.js.

Еще у меня проблема с одним модулем с подключенными 4 датчиками DS18B20.
Я думал, что это мой RasPi, но взял чистый образ Raspbian Streth и установил на него mosquitto и node-red. Та же проблема, соединение разрывается через 6-12 часов.

Панель управления: https://emoncms.org/Edegem/scrtmp2e
4 кривые от ESP: CV_aanvoer, CV_retour и Sanitair_warm, Sanitair_koud.

@fluppie, если вы используете официальные сборки?

Нет, я создаю себя с помощью PlatformIO / Atom
РЕДАКТИРОВАТЬ: Ха, я плохо читал, попробую официальную сборку.

Давайте посмотрим на это!

Привет

У меня была / была такая же проблема, я использую HomeAssistant, но после ESPEasy_mega-20181111 fw проблема кажется мне исправленной.

Спасибо
Т

Через 2-3 дня у меня все еще пропадало соединение. Я обновлюсь до: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

Посмотрим!

Моя была потеряна. через 1-10 часов. У меня ~ 10ч30мин безотказной работы и все (5шт) связанные модули подключены. :-)

вроде бы стоило бы попробовать ... все же на 2709 т.к. нужна стабильная связь. Пожалуйста, держите меня в курсе. :-))

Вы также можете подписаться на: https://emoncms.org/Edegem/scrtmp2e и проверить, есть ли там графики CV_ и Sanitair_ :).

1 день безотказной работы и все в порядке. :-)

Вы также можете подписаться на: https://emoncms.org/Edegem/scrtmp2e и проверить, есть ли там графики CV_ и Sanitair_ :).

:-D Sanitair_warm почти 60 C? маленький костер? ;-)
Фирму попробую .. Спасибо ...

Я принимал душ ;-)

1 день ... все еще на связи :-D
используя 12112018

Через ~ 3 дня 3 часа один из моих устройств потерял соединение MQTT. :-( (мега-20181112 4096 VCC прошивка)

@redskinhu :
просто чтобы убедиться, все ли работает нормально после того, как устройство потеряло соединение MQTT?
потому что, с моей стороны, он отображается только как «соединение потеряно», но по-прежнему отлично работает со всеми действиями MQTT.

Greetz
Саша

Действительно, время от времени потеря связи - не редкость.
Пока соединение восстанавливается без вмешательства человека, проблем нет.
Соединения WiFi будут время от времени сбрасываться, и вы ничего не можете сделать, чтобы предотвратить это.
Как только такое соединение потеряно, он уведомляет клиентов MQTT на том же узле о повторном подключении.

Похоже, какая-то проблема, связанная с LWT. MQTT не отключен полностью, ESPEasy отправляет / получает сообщения MQTT, но LWT не обновляется, поэтому HomeAssistant не получил сообщение LWT connected, поэтому он показывает, что соответствующий датчик / переключатель недоступен. Это моя теория ...

Моя все еще подключена, и, в отличие от моего первого поста, даже MQTT LWT сообщает мне, что подключен. Выглядит неплохо.

Действительно, время от времени потеря связи - не редкость.
Пока соединение восстанавливается без вмешательства человека, проблем нет.
Соединения WiFi будут время от времени сбрасываться, и вы ничего не можете сделать, чтобы предотвратить это.
Как только такое соединение потеряно, он уведомляет клиентов MQTT на том же узле о повторном подключении.

ОК, есть ли возможность обновить подключенный LWT в этом случае?

Предполагается, что LWT будет отправлен в момент обновления соединения.

Прямо сейчас у меня есть узел, который в LWT показан отключенным, и он отлично отправляет измерения. Немного более старая сборка ... может это вам что-то говорит

Версия GIT: | мега-20181008
Время работы: | 3 дня 17 часов 36 минут

Я видел странные вещи, когда узел ESP думал, что он был отключен и ему необходимо повторно подключиться, но брокер с этим не согласен.

Привет

Я провел небольшое расследование. Похоже, проблема в LWT. Один из моих ESP снова произвел эту "отключенную" вещь MQTT.

Все работает нормально, датчики / переключатели. Но Home Assistant не мог их видеть, потому что в конфигурации я предоставил детали LWT.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

Я проверил трафик MQTT: я получил данные датчика, и я мог включить / выключить GPIO. Все ок. LWT.

И после того, как я опубликовал сообщение LWT "Connected", все вернулось в норму.

Я надеюсь, что это помогает.

Т

PS:
Я думаю об одном правиле, которое может публиковать сообщение LWT Connected, если сообщение LWT отключено, но, к сожалению, я не могу импортировать строки MQTT ;-)

Как бы то ни было, я с нетерпением ждал выхода новой прошивки. 4 долгих дня ....

Я отсутствовал в понедельник / вторник, а в последующие дни был очень занят;)

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

Каков тайм-аут брокера MQTT?
Я думаю о возможности того, что брокер предполагает потерянное соединение, но узел ESP по-прежнему действует так, как будто он был активен и все еще подключен.

Я пробовал 100-1000 мс. Сейчас 300. Неважно.

Не в контроллере, а в брокере.
Это время порядка 10-15 секунд.
Поэтому, пожалуйста, проверьте в конфигурации брокера, какой тайм-аут используется.

Я ничего не менял в тайм-ауте LWT, и я не смог найти никаких соответствующих настроек в моей конфигурации Mosquitto. Это должно быть по умолчанию. Я также не смог найти настройку тайм-аута LWT в документах.

Нет, не тайм-аут LWT, тайм-аут брокера.
Если клиент не отправит сообщение в течение периода ожидания, брокер будет считать его отключенным.
Таким образом, если клиент использует другой параметр тайм-аута, это может быть связано с тем, что брокер считает, что клиент отключен, и клиент не пытается повторно подключиться.

Насколько я понимаю из спецификации mqtt, брокер отправляет LWT, когда не получил сообщение от клиента в течение периода Keep Alive Period, установленного клиентом. На стороне брокера настраивать нечего.

См. Https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

А также

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

Это правда, но я хочу знать, что это за «Период сохранения активности» на стороне брокера.
Я знаю, что это исправлено на стороне ESPeasy.
Но если они не синхронизированы друг с другом, вы увидите странные вещи.

хм, у меня нет возможности установить что-то подобное

Но все равно говорит "Подключено". 4 дня :-D

только что один мега-20181006 делал то же самое. LWT не обновлен до онлайн, но нормально работает MQTT

@ jimmys01 Можете ли вы увидеть у своего брокера, основывает ли он решение на идентификаторе клиента? (это меняется при потере связи)
Это изменение идентификатора клиента - это то, что я добавил в сборках в конце сентября.

@ TD-er, я нашел способ воспроизвести это! Я отменяю авторизацию wemos на маршрутизаторе mikrotik, и он подключается сразу после резервного копирования, но LWT остается в автономном режиме, в то время как mqtt все еще работает. Присылайте мне сборки для тестирования по желанию

Вы также можете увидеть идентификатор клиента в брокере MQTT?
Если за идентификатором клиента стоит «-1» или что-то в этом роде, это означает, что он принимает новый идентификатор клиента.
Если нет, то это может быть связано с изменением идентификаторов клиентов, которое я сделал некоторое время назад.

Я не понял, где идентификатор клиента находится в Mosquitto, но журналы показывают, как будто ни один клиент не отключен, а новый подключен, вероятно, потому, что процесс деаутентификации и авторизации Wi-Fi быстрее, чем сердцебиение протокола MQTT.

Новое соединение после перезапуска и esp, и брокера

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

Деаутентифицируйте клиента, и клиент снова подключится. Брокер на этот раз почему-то оставил клиента LWT подключенным ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

Второй деавторитет

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

После этого повторного подключения и на LWT остается офлайн, сообщения MQTT работают нормально. Обратите внимание на дополнительный _1_1 в имени клиента.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

Хорошо, тогда я отменю изменение идентификатора клиента.
Может, еще можно удаленно проверить, если клиент считается подключенным?
Я видел, как соединение отклоняется, когда брокер считает, что клиент все еще подключен, и клиент пытается подключиться повторно.
Повторные попытки через короткие промежутки времени сохранят этот статус, и, таким образом, клиент никогда не сможет повторно подключиться.

Есть ли обновления статуса по этому поводу?

Нет еще нет.
Но поскольку мы добились некоторого прогресса (наконец) по другим вопросам стабильности, я думаю, это будет следующим в моем списке.
Спасибо за пинг;)

Я сделал необязательным изменение идентификатора клиента при повторном подключении. (Инструменты => Дополнительно, рядом с другими настройками MQTT)

Пожалуйста, закройте проблему, если она сейчас работает.
Я установлю его на фиксированное.

Зачем все равно менять идентификатор клиента?

Были сообщения о том, что брокер отклоняет попытки подключения, пока брокер предполагает, что клиент все еще подключен.
Таким образом, клиент получил отказ и попытался снова.
Но каким-то образом эти повторные подключения вызвали что-то на стороне брокера, чтобы рассматривать попытки подключения как недавнюю активность этого клиента, и поэтому он никогда не будет считать клиента отключенным.

Хорошо, это подошло к концу, но решение не требует пояснений для других, которые видят этот флажок.
Возможно, добавьте всплывающее окно, которое объяснит, как поставить галочку, если возникнут проблемы с повторным подключением после потери Wi-Fi.
Поиск по проблемам с тасмотой покажет вам, что у них были похожие проблемы с внешним видом, связанные с сохранением MQTT, похоже, что это проблема брокера.
У меня также был один клиент, который вообще не подключался к Wi-Fi после того, как я деавторизовал его ... нужно исследовать это.

Мы добавим это в документацию .
Мы очень много работаем над обновлением документации, а также перемещаем большую часть документации из вики в ReadTheDocs. Это позволяет иметь документацию по каждой версии.
Файлы документации также включены в репозиторий GitHub.

В идеале фиксация исправления в коде также будет содержать обновление в документации.
Сейчас я закрою этот вопрос.
Если у вас есть дополнительная информация по другой упомянутой вами проблеме, пожалуйста, откройте для нее новую проблему.

Привет

Я недавно установил релиз 20190110. Выглядит многообещающе. Никаких проблем с LWT после 5 дней тестирования. :-)
У меня есть несколько узлов с включенной опцией «MQTT изменить ClientId при повторном подключении», а некоторые - с отключенной.

Хорошие новости!

Т