Похоже, это связано с изменением серийного номера, которое я недавно внес.

Какие контакты gpio вы используете?

Может быть, давайте посмотрим, я думаю, вы нашли точку Gijs :-)

esp01 = Gpio0 Gpio2 (пока проблем не замечено)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Питер

У меня есть два узла, которые я также могу проверить позже днем.

Хорошо,
Неисправность возникает не сразу, они перестают отправлять данные через некоторое время и довольно упорствуют в этом, поэтому перезагрузки или понижения версии ПО недостаточно, чтобы они снова отправили данные. Им нужен цикл питания и некоторое время между выключением и включением.

Как долго это "через некоторое время"?
Я только что настроил узел, используя один из этих датчиков, а также подключил BMP280.
Он использует GPIO-14 и -12 для датчика CO2.

пару часов, вчера все работало, сегодня утром у меня было 3 из 4 с таким же статусом.

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

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

Я как раз собирался обновить свои узлы, но, к счастью, заметил это. @TD-er, который будет последним выпуском до изменений в Serial, которые, как вы предполагаете, могут быть виновниками? Или было бы полезнее, если бы я прошил самую новую версию, чтобы посмотреть, не возникнет ли у меня такая же проблема?

Если какие-либо отсутствующие обновления не имеют большого значения, я бы предложил последнюю версию.
Чтобы сохранить версию до оболочки последовательного порта, вы можете использовать 20181231. (Я думаю, что я зафиксировал изменения в этом году)

вчера я понизил 3 «проблемных» esp до 20181231, могу подтвердить, что они все еще отправляют данные без аппаратных изменений, теперь в течение 24 часов, так что эти три esp все еще используют gpio12 и gpio14 в моем случае

Удачи с воссозданием этого Gijs?

Нет, мой узел все еще отправляет значения, и на нем запущена сборка с 16 января. (ядро 2.5.0)

я использовал ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin на тех узлах, которые, я полагаю, имеют ядро ​​2.4.1?

@pwassink Это правильно.
Вы также можете увидеть основную сборку на странице sysinfo.

Я установил эту версию ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin обратно на esp02 здесь, посмотрим, произойдет ли это снова

Хм,
Может быть, день недели или положение луны имеют определенное влияние,
Я не видел, чтобы неисправность повторялась здесь в течение последних дней.

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

Обновлять,

я оставил esp02 работающим с версией ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin, которая все еще работает как надо.

Вчера я обновил остальные узлы до ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin.

И esp-18 снова лохнулся в 06:55 по местному времени, все работает как надо, кроме датчика MHZ19 Co2, на вкладке устройств он показывает "последнее известное хорошее значение" примерно с 07:00 и снова с теми же записями в файле журнала:
MHZ19: Ошибка, тайм-аут при попытке чтения
MHZ19: Неизвестный ответ: 0 0 0 0 0 0 0 0 0

Esp-18 использует Gpio 14/12
это Nodemcu с Ch340 версии 2 из 3 с али
Удаленная перезагрузка через веб-консоль не решила проблему
снова он отображает эти записи, упомянутые выше, несколько раз
После выключения питания
78640: MHZ19: ошибка, тайм-аут при попытке чтения
78641: MHZ19: Ошибка чтения: контрольная сумма = 202/0 байт прочитано => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: сдвинут на 1 байт, чтобы попытаться исправить выравнивание буфера.
Еще через некоторое время:
255652: MHZ19: значение PPM: 1584 значения Temp/S/U: 25/0/0,00
255656: СОБЫТИЕ: Rik-CO2#PPM=1584,00
255656: СОБЫТИЕ: Rik-CO2#PPM=1584,00 Время обработки: 1 мс
255659: СОБЫТИЕ: Rik-CO2 # Температура = 25,00
255659: СОБЫТИЕ: Rik-CO2#Temperature=25,00 Время обработки: 1 мс
255662: СОБЫТИЕ: Rik-CO2#U=0,00
255662: СОБЫТИЕ: Rik-CO2#U=0,00 Время обработки: 1 мс

Кажется, теперь он снова работает, но потребовалось отключение питания около 2 минут без питания.

Нужно ли что-то делать в этот момент? Может быть что-то, что могло привести к зависанию Wi-Fi на ESP?

Вообще ничего,

На данный момент нет запланированных сбросов, перезагрузок, резервных копий, сбросов WFI, очисток dhcp или каких-либо внешних причин.

И Wi-Fi продолжает работать нормально, останавливается только считывание mhz19, все остальные (на основе i2c) датчики на том же esp все еще работают.

Сегодня утром в 03:00 это произошло снова с Esp-18 с версией 0121 Mega, те же ошибки в esp-logfile, что и раньше, другие датчики работают нормально.

И в 19:05 esp02, запущенный с ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin, также рухнул, та же ситуация, что и выше, больше нет данных и те же записи в журнале.

Сегодня снова 2 зависания, esp02 и esp18 оба вышли из строя, снова те же ошибки в журнале
Задействовано 2 версии программного обеспечения, 0116 и 0121, оба ядра 2.4.1 и версия 4 Мб.
аппаратное обеспечение esp02 — это nodemcu-d1-mini / esp18 — это nodemcu-v2, оба используют gpio12/gpio14

Можете ли вы попробовать эту сборку на одном из ваших узлов?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Он работает на одном из моих узлов с MH-Z19 и теперь имеет время безотказной работы 54 дня 23 часа 21 минуту.
Это после отключения электроэнергии...
Этот работает нормально с регулярными обновлениями значения CO2.

Я буду,

но я уже упоминал ранее, что до версии mega 20181231 core 2.4.1 normal 4Mb ни одна из заявленных проблем со стабильностью не наблюдалась, так почему именно эта версия?

я скачаю эту конкретную версию и установлю ее на узлы измерения со2 esp02 и esp18, но проблемы появились в диапазоне mega-2019 * не раньше, по моему скромному мнению, Gijs ..

Хорошо, тогда это действительно бесполезно.

Эта конкретная версия работает на моей версии, которая кажется (к сожалению, необычной) стабильной.
И вы правы, если до 20181231 работал нормально, то старшие пробовать особо не стоит.

Тем не менее,
Esp02 и esp18 теперь работают на ESP_Easy_mega-20181109_normal_ESP8266_4096.bin
Esp01 и Esp08 работают на ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

И мы увидим

Заметьте, я только что заметил, что версия 1109 имеет номер сборки 20102, так что это очень старая и другая версия?

Гийс,

Я мог бы найти другую подсказку по этому вопросу.

пару минут назад мой Esp08 A nodemcu ch340V2 4Mb с ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin перестал отправлять co2data.

Фрагмент журнала
370508579: UDP: 60:01:94:0F:AF:9D,192.168.3.46,17
370508785: UDP: 24:0A:C4:82:F2:B8,192.168.3.51,21
370509501: UDP: 60:01:94:0C:2E:FD,192.168.3.48,19
370514624: UDP: 5C:CF:7F:82:FD:47,192.168.3.31,2
370515674: MHZ19: Ошибка чтения: контрольная сумма = 120/248 байт прочитано => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: сдвинут на 1 байт, чтобы попытаться исправить выравнивание буфера.
370517702: СОБЫТИЕ: Часы#Время=ср,12:19
370517755: СОБЫТИЕ: Clock#Time=Wed,12:19 Время обработки: 53 миллисекунды
370520257: UDP: 60:01:94:0B:94:5C,192.168.3.30,1
370520460: UDP: 60:01:94:02:0E:E8,192.168.3.36,7
370523940: UDP: 18:FE:34:E2:18:84,192.168.3.35,6
370529880: UDP: до н.э.:DD:C2:EA:3D:BC,192.168.3.54,24

Я впервые вижу эту ошибку, может быть..

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

У меня есть идея, что сам датчик mhz19 переходит в «заблокированное» состояние после нескольких часов недопонимания или в результате невозможности получить данные. ?
Мотивация: перезагрузка или даже полное обновление прошивки не решает этот статус, mhz19 должен быть бессилен в течение минуты или около того, чтобы восстановить жизнь, я обнаружил такое поведение, когда он застрял в статусе, который выглядит следующим образом:
MHZ19: Ошибка, тайм-аут при попытке чтения
MHZ19: Неизвестный ответ: 0 0 0 0 0 0 0 0 0

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

Но потом нашел это:
примерно в 18:00 по местному времени он перешел в состояние блокировки, перезагрузился, перезагрузился через питание консоли, на этот раз ничего не помогло, устройству потребовалась повторная прошивка версией mega 20181231 4 МБ, после чего оно снова ожило. Esp08 использует комбинацию Gpio12/14 и также является моделью nodemcu v2 ch340.

Звучит довольно странно, так как плагин отправляет команду на сбор новых данных датчиков на MH-Z19.
Так что я не понимаю, почему даже мягкая перезагрузка не работает.
Я также добавлю некоторую статистику, чтобы увидеть, как часто возникает ошибка контрольной суммы (приемный конец)
Если это происходит часто, это также может происходить при отправке данных на датчик, и, возможно, датчик затем переводится в какой-то неизвестный командный режим.
Может быть, какая-то конфигурация подтягивающего резистора изменилась, когда я изменил способ настройки последовательных контактов ???

Это могло бы,

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

Или не используется людьми, использующими последние сборки

У меня есть 2 MH-Z19b, оба работают на тестовой сборке 20190116 без проблем.

Хорошо, просто любопытно, какую именно основную версию тестовой сборки и какие Gpio вы используете?

Я вижу, что на 1 запущен ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, на другом ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. На обоих датчиках, подключенных к GPIO 13 и 12

Итак, это еще одно ядро ​​и еще один GPIO, который вы используете в 13/12 вместо GPIO 14/12, который я использую здесь.

Сегодня обновил 4 из 4 до версии ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

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

Теперь, когда я об этом думаю, с начала этого года в используемой библиотеке SWserial может произойти еще одно изменение.
Раньше у нас была собственная версия библиотеки SWserial, которую я исправил, чтобы использовать меньше памяти iRAM.
Но сейчас мы используем версию, включенную в основную библиотеку, а для ядра 2.5.0 это может быть более новая версия, чем раньше.
Также могут быть некоторые изменения в использовании прерываний на низкоскоростных соединениях. (9600 бод и ниже)
Я должен изучить это тоже.

Это все еще не объясняет, почему датчик, по-видимому, может так испортиться, что ему нужно отключить питание, чтобы снова работать нормально.

Через 3 часа после обновления до ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin мой esp18 снова завис, перезагрузка вебконсоли не работала, снова требовалось powerdown.
другой все еще работает, добавлю сюда, если он также заморозит MHZ19

Да, другой esp18 перестал отправлять разумные данные CO2 в 19:05 сегодня вечером, поэтому ошибка сохраняется во вчерашнем mega 202 core 2.4.1, по крайней мере.
Тот вернулся и теперь тоже переведен на версию 20181231.

Около полуночи третий esp, esp02 завис с показаниями Co2, также понижен до 20181231 сейчас

Единственный, кто все еще работает на ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin, — это тот, который использует Gpio-0/Gpio-2, остальные три, которые зависли, используют Gpio14/gpio12.
Я больше не думаю, что это совпадение,

я изменю проводку esp02 на Gpio-0/Gpio-2 и снова обновлю ее до ядра версии 0202 2.4.1, и мы можем посмотреть, останется ли она в живых после этого изменения gpio.
Сделанный

Я только что добавил коммит, чтобы немного улучшить чтение.
См. https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c .

Можете ли вы создать для него тестовую версию или вы хотите, чтобы я сделал ее?

Если бы вы могли предоставить мне корзину, я был бы рад установить ее на оба устройства, все еще работающие на gpio12/14 с esp.
и тогда точно файл такой же, никаких местных влияний и т.д..

Хорошо, потребовалось некоторое время, но вот тестовая сборка

Понятно,

Esp08 и esp18 теперь работают на этой тестовой версии с ядром 2.4.1, они оба используют gpio12/14.

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

Вы также должны увидеть индикатор, показывающий количество обработанных строк и количество ошибок CRC.

Да, они у меня тоже есть в консоли!

оставит эти 2 и через определенный интервал увидит, увеличиваются ли эти счетчики.
Держать вас в курсе ..

Оба датчика, используемые в тестовых узлах, относятся к версии B, так что обнаружение тоже работает.

Контрольная сумма (пройдено/не пройдено): | 11/0
-- 08 --
Обнаружено: | MH-Z19B

Контрольная сумма (пройдено/не пройдено): | 8/0
-- 18 --
Обнаружено: | MH-Z19B

У вас также есть смесь MH-Z19 A/B или только более новые версии B?
Это не должно иметь значения, просто любопытно.

У вас также есть смесь MH-Z19 A/B или только более новые версии B?
Это не должно иметь значения, просто любопытно.

B версии, просто добавил эту информацию, обнаружение тоже сработало :-)

небольшое обновление, все по-прежнему работает нормально, те, у которых есть специальная версия esp8 и 18, показывают увеличение счетчиков, но по-прежнему нет ошибок или ошибок контрольной суммы, текущие значения:

Esp08: Контрольная сумма (пройдено/не пройдено): | 1795/0
Esp18: контрольная сумма (пройдено/не пройдено): | 724/0

а другой, который дал сбой, вполне последовательный esp02, также все еще работает с измененным Gpio.
и, таким образом, у di-mini теперь есть mhz19 на Gpio-0/Gpio-2 и mega 20190202 версии ядра 2.4.1.

Облом случайно удалил пост здесь, попробуй воссоздать по памяти:

Вчера вечером три из моих esp 02, 08 и 18 стали красными на Domoticz, нет данных датчика Co2.
два из них имеют специальную версию ядра 2.4.1 и gpio 12/14. Перезагрузка веб-консоли не решила проблему, а только выдала: MHZ19: Неизвестный ответ: 0 0 0 0 0 0 0 0 0 0, но измерения co2 esp18 возобновили работу примерно через час, в 0:56 он снова начал отправлять правильные значения.

Esp08 тоже перезагрузился, и esp02 тоже (у которого gpio0/2 теперь такой же, как у esp01) оба не восстановились, и сегодня утром оба отключились на 2 минуты, после чего оба вернулись к жизни в порядке.

Теперь я изменил версию программного обеспечения на esp02 на ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4, чтобы мы могли протестировать и эту версию ядра.
Сегодня esp02 показал единственную ошибку контрольной суммы: Контрольная сумма (пройдено/не пройдено): | 79/1

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

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

• Номер вашего внутреннего блока (для справки, например "02, 08, 18")
• Построить работает
• номер успеха/неудачи (если доступно)
• вид сбоя/проблемы

Детализированная информация (для меня) легче воспринимается по сравнению с описательным текстом.
Я тоже иногда отвечаю с телефона.

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 ядро ​​2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- замороженный означает, что работает нормально, за исключением показаний СО2

22:57 esp08 опять завис, счетчики Контрольная сумма (пройдено/не пройдено): | 1077/2 отложите системный журнал, когда найдете его.
05:05 esp18 опять завис, счетчики Checksum (пройдено/не пройдено): | 1076/2
06:25 esp08 снова завис, счетчиков нет, на этот раз esp полностью завис, есть syslog
12:57 esp18 снова завис. счетчики Контрольная сумма (пройдено/не пройдено): | 116/2
20:43 esp18 снова завис, счетчики Checksum (пройдено/не пройдено): | 316/2 попробовал команду mhzreset
Никаких изменений, датчик отправляет неизвестный ответ mhz19 0 0 0 0 0 0 0 0
сообщение снова и снова, пробовал несколько попыток без решения, выключил и снова включил узел.

Гийс,

Я проанализировал последний системный журнал esp08, за время его работы я увидел 78 случаев:
2019-02-08T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Неизвестный ответ: ff 0 0 0 0 0 0 0 0

Автоматический поиск с помощью #cat messages-crash-esp08-0625 |grep MHZ19 | ответ grep | grep 'ff 0 0 0 0 0 0 0 0' | туалет -л

и после изменения этой командной строки на второй вариант с неизвестным ответом linux посчитал эту строку 408 раз:
2019-02-08T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Неизвестный ответ: 0 0 0 0 0 0 0 0 0

Счетчики ошибок контрольной суммы в вашей пользовательской отладочной версии не превышали 2, насколько я видел в течение последних нескольких дней.
первое сообщение об ошибке (MHZ19: Неизвестный ответ: ff 0 0 0 0 0 0 0 0) пришло пару раз шесть или около того непосредственно друг за другом, прежде чем оно зависло сегодня утром.

Похоже, что сам датчик дает сбой, но я не могу понять, почему он делает это сейчас.
В нашем исходнике есть команда для вызова сброса датчика MH-Z19, но она не задокументирована в даташите.
Так что я не знаю его статуса.
Не могли бы вы попробовать вызвать эту команду на узле, который вот так застрял?

Изменить: эта команда mhzreset

После мега 20181231 2.4.1 должны быть внесены некоторые изменения. Версия 4Mb, которая, насколько я нашел, имеет такие же результаты на MHZ19. тот работает неделями без проблем даже на gpio 12/14.

попробую в следующий раз, когда что-то перестанет работать, в 23:20 обнаружил, что esp18 завис, mhzreset этого не изменил, см. лог выше.

команда mhzreset не открывает командное окно в веб-консоли, не сообщает «ОК» или около того, после нескольких попыток я нашел в системном журнале:
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Сброс датчика отправлен!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Сброс датчика отправлен!
so easy говорит, что оно было отправлено, но, похоже, это не тот вкус, который mhz19 понимает или любит :-)

Эта команда, кажется, что-то делает для версии MH-Z19 A.

127136: MHZ19: Sent sensor reset!
137272: MHZ19: Unknown response: ff ff ff ff ff ff ff ff ff
152275: MHZ19: Unknown response: ff 31 f5 4b 42 32 30 30 d
167277: MHZ19: Bootup detected! PPM value: 5000 Temp/S/U values: 23/1/15000.00
197279: MHZ19: Bootup detected! PPM value: 400 Temp/S/U values: 23/1/15000.00
<repeat a few times>
257279: MHZ19: PPM value: 906 Temp/S/U values: 24/64/11554.00

Так что похоже, что его нельзя использовать на B-версии.

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

Не видел отказов до сегодняшнего дня:
15:43 esp08 опять завис, счетчики Контрольная сумма (пройдено/не пройдено): | 2316/2 отложил системный журнал.

И чтобы убедиться, что эти узлы нормально работали на старых версиях прошивки?

Да, до ESP_Easy_mega-20181231_normal_ESP8266_4096 это было и все еще нормально,
Они будут работать неделями без проблем

Я изучил последние изменения в библиотеке SWserial, поскольку именно ее мы сейчас используем.
Одно из внесенных изменений заключалось в том, что больше не использовались прерывания при передаче TX на скорости 9600 бод.
Можете ли вы попробовать эту тестовую сборку ?

NB Я также удалил основные сборки 2.5.0, так как они ведут себя странно при обслуживании веб-страниц.

Esp08 и Esp18 с ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
эти двое также отправляют свои данные на сервер системного журнала, поэтому данные журнала будут записаны

Два других последуют завтра, один из них может быть Mhz19A, и это так.

Hw конфиг сейчас:
Esp01 имеет MHZ19A на gpio0/gpio2
Esp02 имеет MHZ19B на gpio0/gpio2
Esp08 имеет MHZ19B на gpio12/gpio14
Esp18 имеет MHZ19B на gpio12/gpio14

Все они сейчас на одной и той же тестовой версии esp-easy, работающей на:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

Обновить

06:01 esp08 снова завис, счетчики потеряны (вызвано пользователем), отложите системный журнал.

05:21 Esp18 завис, Контрольная сумма (пройдено/не пройдено): | 1460/0, системный журнал отложен
12:53 Esp08 завис , Контрольная сумма (пройдено/не пройдено): | 1351/28, системный журнал отложен

Сборка ядра 2.4.1 не была включена в эту тестовую сборку, поэтому я просто сделал ее, содержащую только эту версию ядра. сборка ядра 2.4.1 с тем же кодом, что и в ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
В нем используется более старая версия библиотеки SoftwareSerial.
Если это сработает, я изменю используемую серийную библиотеку SW.

Начинаем обновление до специальной версии: сейчас прошивка.bin для всех 4 нод, завершено в 12:30

Первое, что я заметил, Esp08 был завис, это обновление прошивки перезапустило MHZ19B, он вернулся живым, я имею в виду инициализацию: датчик дает мне разумное значение C02, это тоже казалось намного быстрее.

Я также запускаю старую библиотеку SWserial на тестовом узле, и действительно, она работает намного лучше.
Например, у системы мониторинга энергии Eastron было повреждено около 20-30% принимаемых линий, но теперь она работает отлично. (пока нет неудачных контрольных сумм)

Я только что сделал новую тестовую сборку , в которой я многое изменил в отношении последовательной оболочки HW/SW.
Теперь он работает с подключаемым модулем Eastron как для SWserial, так и для HW serial, а SWserial теперь использует старую библиотеку, которую мы использовали до 20180131.

Так что это на самом деле то же самое, что и версия 0202, но с той же последовательной библиотекой, что и версия 20181231, я обновлю их напрямую.

Установлен ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
на Esp0.02.08.18 сейчас

Давайте посмотрим ..

Да, и у него есть оболочка HWserial/SWserial, так что должно быть легко переключиться на HWserial, как только вы используете правильные контакты для них.

Мне все еще нужно добавить GPIO2 в качестве дополнительной опции для HWserial0, и в коде еще нужно выполнить некоторую очистку.

По прошествии первых часов они все еще работают, после последнего обновления я не вижу никаких неизвестных
ответ ff 7 x 0 или 8 x 0 сообщений в системном журнале от esp08 или esp18 больше.

Потребовалось некоторое время, чтобы изучить системные данные двух узлов:
У Esp08 все еще есть неизвестный ответ с разным кодом время от времени,
Esp18 пока ошибок не выдавал

Рад слышать.
Я думаю, у нас были некоторые проблемы, когда данные, отправленные на датчики, были повреждены.
Тогда сам датчик может сломаться, я думаю.

С помощью плагина Eastron (отправляет намного больше данных) количество ошибок контрольной суммы было значительно уменьшено.
Примерно от 20-30% ошибок CRC в сообщениях до почти 0 (1 ошибка на 10 000 сообщений) при использовании SWserial.

Все еще работает нормально, все четверо

Посмотрел список исправлений выпуска 20190215, эта версия теперь такая же, как версия, которую я использую на 4 узлах измерения Co2 здесь?

Почти то же самое.
По крайней мере, код для последовательного порта и вашего плагина одинаковый.

Затем я оставляю все как есть и продолжаю тестирование со «специальным»

Мне было непонятно, что было включено в релиз, а что нет, некоторые номера совпадали.

Да, большой PR, который я вчера объединил, был источником всех тестовых сборок, которые я сделал за последние недели.

Esp08 завис на 14:17, счетчики Checksum (пройдено/не пройдено): | 3292/70, системный журнал отложен для дальнейшего анализа

И была ли простая перезагрузка (или сохранение настроек) узла перезапуском датчика (не отключением питания)?

Попробую это в следующий раз, просто включил его после проверки счетчиков.

Esp08 опять завис, счетчики Checksum (пройдено/не пройдено): | 2660/55

сохранение параметров co2-устройства решило зависание!

Esp08 18:18 опять завис, счетчики Контрольная сумма (пройдено/не пройдено): | 2660/55

сохранение параметров co2-устройства решило зависание!

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

Это может полностью решить эту проблему.

На данный момент вся проблема с серийным номером, с которой мы столкнулись на всех из них, теперь исчезла на модели A и с двумя из трех датчиков модели Mhz19B.
Esp08, который является моделью B, является единственным, который я видел с переменной «неизвестный ответ (каждый раз меняющийся) шестнадцатеричное значение», все еще в файлах журналов, если этот датчик можно было сбросить из плагина, когда он ведет себя плохо, это может быть решением.

Обновление всего до Mega 201902026 4Mb сейчас.

Первое, что я заметил, датчик Co2 типа mhz19B выдает правильные значения почти сразу после вспышки нового изображения, намного быстрее, чем раньше.

Это звучит очень многообещающе! Я наблюдал за этой веткой, ожидая момента, когда я наконец смогу обновиться. :grin: У меня есть узел, к которому подключены MH-Z19 и PMS7003. MH-Z19 работал более 90% времени, но иногда мне приходилось сбрасывать ESP для этого.

Однако PMS7003, похоже, выходит из строя гораздо чаще. В большинстве случаев даже сброс не помогает, но отключение питания на несколько секунд может исправить ситуацию. Я подозревал, что его разъем может быть виновником, но не занимался его отладкой. Эта ветка вызвала у меня любопытство, может ли это быть связано с прошивкой ... Я собираюсь попробовать, когда буду достаточно уверен, что это не вызовет проблем с MH-Z19, поскольку его данные более важны.

И да, я заметил, что # 2349 касается только кода MH-Z19, но я запускаю сборку «20100 - Mega (ядро 2_4_0)», которая, как я полагаю, довольно старая.

Я хочу сказать, что редко можно увидеть такую ​​настойчивость с обеих сторон в вопросе. Думаю, многие бы сдались через несколько дней. Снимаю шляпу перед вами от этих очевидцев @TD-er и @pwassink!

Вы можете подождать еще 1 день перед обновлением.
Сейчас я работаю над некоторыми исправлениями для подключения к сети.

Спасибо за информацию! Я все равно планировал немного подождать отчетов @pwassink (мне лень).

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

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

Я планирую обновить два ESP, которые у меня есть. Основываясь только на них, я могу наблюдать, есть ли регрессия при работе с датчиками MH-Z19, PMSx003, BMx280, TSL2561, DHT22 или дисплеем OLED SSD1306. TSL2561 на другом ESP, как правило, также перестает возвращать данные случайным образом (хотя и довольно редко). Работает сборка "20102 - Мега".

Это не сборка, а внутренний формат файла (я знаю, это сбивает с толку). Вы можете найти имя/дату сборки на странице sysinfo.

По крайней мере, в поле «Сборка». Имя двоичного файла — «ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames». Я, вероятно, прошил его прямо из PlatformIO. У меня могут возникнуть трудности с прошивкой той же версии, что и почти год назад. Я действительно не делал никаких заметок, не говоря уже о теге. :joy: Ну, я думаю, я могу просто сделать резервную копию прошивки, если я не чувствую себя достаточно предприимчивым.

Нет отметки времени сборки на странице sysinfo?

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

Это не ESP, на котором установлены MH-Z19 и PMS7003.

Но я думаю, что это уходит далеко от темы. Извините, что временно захватил ветку, и спасибо, что все равно ответили на мои комментарии!

в какой версии это было исправлено?

через несколько часов получаю ответ MHZ19: Unknown: 0 0 0 0 0 0 0 0 0
перезагрузка не исправит, надо отключить и снова подключить

я использую wemos 1d mini pro, есть ли в этой версии исправление?

Сборка:⋄ | 20104 - Мега
-- | --
Системные библиотеки:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: поддержка 2.1.2 PUYA
Сборка Git:⋄ | мега-20191003
Плагины:⋄ | 46 [Нормальный]
Сборка Md5: | 3180a4d3e118166b3414444513a6169
Мd5 проверка: | прошедший.
Время сборки:⋄ | 3 окт 2019 02:15:29
Имя двоичного файла:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

Спасибо

Да и предыдущие версии тоже.
Я бы посоветовал попробовать сборку 20190928, так как в октябрьской были некоторые другие проблемы (которые я исправляю на прошлой неделе или около того).

Вы также можете посмотреть на количество ошибок чтения, отображаемых на странице плагина, после того, как он проработал несколько часов.

Например, один из моих собственных юнитов (время безотказной работы 3 дня)

Обратите внимание, что фильтр (установленный на «Использовать нестабильный» на скриншоте) не имеет значения для датчика MH-Z19B, он применим только для версии -A.

И еще один:

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

те 11 сбросов, когда я пытался заставить его снова загрузиться, не вставляя и не подключая его, я не помню, чтобы видел какие-либо ошибки, но я могу попробовать еще раз, должен ли я использовать Software Serial?

Аппаратный серийный номер лучше, но тогда вы также должны отключить последовательный порт в Tools->Advanced->Serial Port. (как указано на вашем скриншоте :) )

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

Сборка: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
отчетность в ФГЭУ.
У меня была аналогичная проблема: датчик MH-Z190B зависает каждые несколько часов и продолжает падать до 400, когда я использую аппаратный последовательный порт.
После переключения на серийный номер программного обеспечения он работает нормально и больше не зависает.
2 скриншота прилагаются.

BME280, подключенный через I2C, работает нормально и все время сообщает

Хм, это странно.
К какому последовательному порту HW он был подключен?
Что еще подключено к плате? (например, USB к последовательному чипу)
Не установлен ли флажок «Использовать серийный номер» на странице «Инструменты» -> «Дополнительно»?

Он подключен к GPIO-13 (D7) <- TX и GPIO-15 (D8) -> RX (сначала в HW, теперь в SW), так как я хотел использовать TXD0 и RXD0 для чтения сообщений через USB-порт (CH340). ) Wemos D1 mini.
Означает ли «Использовать последовательный порт» флажок «Настройки последовательного порта — Включить последовательный порт:»? Я оставил этот флажок, чтобы иметь возможность читать сообщения через USB.

Последовательный порт HW на ESP8266 использует Serial0.
Если вы также отправляете журналы на тот же последовательный порт, датчик может дать сбой, поскольку он не понимает «команды», которые он получает, когда журналы отправляются через этот порт.

Если вы что-то подключаете к последовательному порту HW, вы больше не должны отправлять другие данные. Таким образом, вы должны отключить «Использовать серийный номер» на странице «Инструменты» -> «Дополнительно».

Вчера получил второй Сенсор MH-Z19C. Этот, кажется, отлично работает с HW-Serial на Serial2. Поскольку все датчики были подключены к контактам D7 (GPIO 13) и D8 (GPIO 13) (RXD2 и TXD2), не должно быть никакого конфликта с Serial0 (контакты RXD0 (GPIO3) и TXD0 (GPIO1)) насколько я понимаю. понимание распиновки. Я думаю, что первый датчик (MH-Z19B от другого поставщика) был просто подделкой, вообще не работающей должным образом, ...
Так что будьте осторожны при покупке этих датчиков. Второй, который я получил вчера, был в гораздо лучшей упаковке с логотипом Winsen и сертификатом испытаний. Поставщик вроде более серьезный, чем тот, что продал мне первый.