최근에 만든 시리얼의 변경 사항과 관련이 있는 것 같습니다.

어떤 gpio 핀을 사용합니까?

그것은 아마도 당신이 요점을 찾은 것 같습니다. Gijs :-)

esp01 = Gpio0 Gpio2(아직 발견된 문제 없음)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

베드로

여기에 두 개의 노드가 있습니다. 오늘 오후에 테스트할 수도 있습니다.

확인,
오류는 즉각적이지 않고 잠시 후 전송을 중지하고 계속 지속되며 재부팅이나 SW 다운그레이드만으로는 데이터를 다시 전송하기에 충분하지 않습니다. 전원을 껐다 켜는 사이에 약간의 시간이 필요합니다.

"잠시 후"는 얼마나 걸립니까?
이 센서 중 하나를 사용하여 노드를 설정했으며 BMP280도 연결되어 있습니다.
CO2 센서에 GPIO-14 & -12를 사용하고 있습니다.

두어 시간, 어제 모든 것이 작동하고 있었고 오늘 아침에는 동일한 상태로 4 개 중 3 개를 사용했습니다.

그리고 그들은 모두 작동을 멈추기 전에 같은 시간에 부팅했습니다.

예, 내가 생각하는 한 시간 이내에 모두 다시 시작/업데이트되었으며 어제 저녁에 업데이트되었습니다. 그리고 밤에 그들은 일을 멈췄다

노드를 업데이트하려고 했으나 운 좋게 이것을 알아차렸습니다. @TD-er는 Serial이 변경되기 전의 최신 릴리스가 될 것입니다. 당신이 추측하는 원인은 무엇입니까? 아니면 최신 버전을 업데이트하여 동일한 문제가 발생하는지 확인하는 것이 더 유용할까요?

누락된 업데이트가 큰 문제가 아니라면 최신 버전을 제안합니다.
직렬 포트 래퍼 이전 버전을 유지하려면 20181231을 사용할 수 있습니다. (올해 변경 사항을 커밋했다고 생각합니다)

어제 3개의 "문제" esp를 20181231로 다운그레이드했습니다. 하드웨어 변경 없이 여전히 데이터를 전송하고 있음을 확인할 수 있습니다. 이제 24시간 동안 3개의 esp가 여전히 gpio12 및 gpio14를 사용하고 있습니다.

Gijs를 다시 만드는 데 행운이 있습니까?

아니오, 제 노드는 여전히 값을 보내고 있으며 1월 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에 다시 bozo가 되었습니다. MHZ19 Co2 센서를 제외하고 모든 것이 정상적으로 작동하고 있습니다. 장치 탭에서 약 07:00 이후에 "마지막으로 성공한 값"을 표시하고 있습니다. 로그 파일의 동일한 항목으로 :
MHZ19: 오류, 읽기 시도 중 시간 초과
MHZ19: 알 수 없는 응답: 0 0 0 0 0 0 0 0 0

Esp-18은 Gpio 14/12를 사용하고 있습니다.
ali의 Ch340 버전 2/3이 있는 Nodemcu입니다.
웹 콘솔을 통한 원격 재부팅으로 문제가 해결되지 않음
다시 위에서 언급한 항목을 여러 번 표시합니다.
전원을 껐다 켠 후
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#Temperature=25.00
255659: 이벤트: Rik-CO2#Temperature=25.00 처리 시간: 1 밀리초
255662: 이벤트: Rik-CO2#U=0.00
255662: 이벤트: Rik-CO2#U=0.00 처리 시간: 1 밀리초

지금 다시 작동하는 것 같지만 전원이 꺼지면 약 2분 동안 전원을 껐다 켜야 합니다.

그 순간에 뭔가를 해야 합니까? ESP에서 Wi-Fi가 끊길 수 있는 문제가 될 수 있습니까?

전혀,

예약된 재설정, 재부팅, 백업, wfi 재설정, dhcp 정리 또는 그 당시 외부 이유가 없습니다.

그리고 Wi-Fi는 계속 잘 작동합니다. 멈추는 것은 mhz19의 판독일 뿐이며 동일한 esp의 다른 모든(i2c 기반) 센서는 여전히 작동합니다.

오늘 아침 03:00에 0121 Mega 버전을 실행하는 Esp-18에서 다시 발생했습니다. esp-logfile에서 이전과 동일한 오류, 다른 센서는 정상적으로 작동합니다.

그리고 19:05에 ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin과 함께 실행되는 esp02도 충돌했습니다. 위와 같은 상황, 더 이상 데이터가 없고 로깅에 동일한 항목이 있습니다.

오늘 다시 2개의 딸꾹질, esp02와 esp18이 모두 잘못되었습니다. 로그에서 동일한 오류가 다시 발생했습니다.
소프트웨어 2 버전 관련, 0116 및 0121 모두 2.4.1 코어 및 4Mb 버전
esp02의 하드웨어는 nodemcu-d1-mini / esp18은 nodemcu-v2 둘 다 gpio12/gpio14를 사용합니다.

노드 중 하나에서 이 빌드를 시도할 수 있습니까?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

MH-Z19가 있는 내 노드 중 하나에서 실행 중이며 현재 가동 시간은 54일 23시간 21분입니다.
정전 이후라...
이것은 CO2 값의 정기적인 업데이트로 잘 실행되고 있습니다.

그럴 게요,

하지만 이전에 메가 20181231 코어 2.4.1 일반 4Mb 버전까지 보고된 안정성 문제가 하나도 발견되지 않았다고 이미 언급했는데 왜 이 특정 버전입니까?

특정 버전을 다운로드하여 eesp02 및 esp18 co2-measuring 노드에 설치하지만 문제는 내 겸손한 의견 Gijs에서 더 일찍이 아닌 mega-2019* 범위에서 나타났습니다.

좋아, 그렇다면 그것은 실제로 아무 소용이 없다.

그 특정 버전은 (슬프게도 드문) 안정적인 것으로 보이는 버전에서 실행되고 있습니다.
그리고 당신이 맞습니다. 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를 가지고 있다는 것을 알아차렸습니다.

기즈,

이 문제에 대한 또 다른 단서를 찾았을 수도 있습니다.

몇 분 전에 ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin을 실행하는 내 Esp08 A nodemcu ch340V2 4Mb가 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: 이벤트: Clock#Time=Wed,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: BC:DD:C2:EA:3D:BC,192.168.3.54,24

이런 결함은 처음 봅니다. 아마도..

체크섬 오류는 보다 적절하게 처리되어야 합니다.
새로운 좋은 출발을 찾기 위해 이동을 시작할 때 임계값을 추가해야 할 수도 있습니다.
또는 다시 동기화하기 위한 더 나은 알고리즘.
내가 아는 한, 1년이 넘도록 이 코드에 변화가 없었습니다. 직렬 포트 연결이 생성되는 방식에만 변경 사항이 있으므로 이러한 문제가 발생하는 이유를 모르겠습니다.

나는 mhz19 센서 자체가 몇 시간의 잘못된 통신 후 또는 데이터를 가져올 수 없는 결과로 "차단된" 상태에 들어간다는 생각을 가지고 있습니다. ?
동기 부여: 재부팅 또는 전체 sw-update는 해당 상태를 해결하지 못합니다. mhz19는 생명을 되찾기 위해 1분 정도 무력해야 합니다. 다음과 같은 상태에 멈췄을 때 이 동작을 발견했습니다.
MHZ19: 오류, 읽기 시도 중 시간 초과
MHZ19: 알 수 없는 응답: 0 0 0 0 0 0 0 0 0

오늘 아침에 발생한 오류 esp08은 웹 콘솔에서 원격 재부팅 옵션으로 여전히 해결할 수 있었기 때문에 몇 시간 동안 발견하고 보고한 전체 잠금과 동일하지 않았습니다.

그러나 나중에 이것을 발견했습니다.
현지 시간으로 약 1800시에 차단된 상태로 전환되고 콘솔 전원 주기를 통해 재부팅되고 이번에는 아무 것도 작동하지 않았습니다. 장치는 메가 20181231 4mb 버전으로 다시 플래시해야 했고 다시 살아났습니다. Esp08은 Gpio12/14 조합을 사용하고 있으며 nodemcu v2 ch340 모델이기도 합니다.

플러그인이 MH-Z19에 새 센서 데이터를 수집하라는 명령을 보내기 때문에 꽤 이상하게 들립니다.
그래서 소프트 재부팅조차 작동하지 않는 이유를 이해할 수 없습니다.
체크섬 오류가 얼마나 자주 발생하는지 보기 위해 몇 가지 통계도 추가하겠습니다(수신 종료)
이런 일이 많이 발생하면 센서에 데이터를 보낼 때도 발생할 수 있으며 센서가 알 수 없는 명령 모드로 전환될 수 있습니다.
직렬 핀이 구성되는 방식을 변경했을 때 일부 풀업 저항 구성이 변경되었을 수 있습니까?

그것은 수도,

내일이나 다가오는 주말에 조금 더 조사할 것입니다. 아마도 무언가를 찾을 수 있을 것입니다. 그 센서는 아무도 동일한 동작을 겪지 않는 널리 사용되지 않습니까?

또는 최신 빌드를 실행하는 사람들이 사용하지 않음

20190116 테스트 빌드에서 문제 없이 실행되는 2개의 MH-Z19b가 있습니다.

좋습니다. 테스트 빌드의 코어 버전과 사용 중인 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입니다. 여기서 GPIO 14/12 대신 13/12를 사용하고 있습니다.

오늘 저는 4개 중 4개를 ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin 버전으로 업데이트했습니다.

보자

지금 생각해보면 올해 초부터 사용하던 SWserial 라이브러리에 또 다른 변화가 있었던 것 같다.
우리는 더 적은 iRAM 메모리를 사용하기 위해 패치한 SWserial 라이브러리의 자체 버전을 가지고 있었습니다.
그러나 지금 우리는 코어 라이브러리에 포함된 버전을 사용하고 있으며 코어 2.5.0의 경우 이전보다 최신 버전일 수 있습니다.
또한 저속 연결에서 인터럽트 사용에 약간의 변경이 있을 수 있습니다. (9600 보드 이하)
그것도 살펴봐야 겠습니다.

센서가 왜 그렇게 엉망이 되어 다시 정상적으로 작동하려면 전원을 꺼야 하는지 아직 설명하지 않습니다.

ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin으로 업데이트한 후 3시간 이내에 내 esp18이 다시 잠겼고 웹 콘솔 재부팅이 작동하지 않아 전원을 다시 꺼야 했습니다.
다른 하나는 여전히 작동 중이며 MHZ19도 정지되면 여기에 추가됩니다.

예, 다른 하나 esp18은 오늘 저녁 19:05에 합리적인 CO2 데이터 전송을 중단했으므로 어제의 메가 202 코어 2.4.1 이상에서 오류가 지속됩니다.
그 하나가 돌아와서 지금 20181231 버전으로 다운그레이드되었습니다.

자정쯤에 세 번째 esp인 esp02가 Co2 수치와 함께 동결되었으며 현재 20181231로 다운그레이드되었습니다.

ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin에서 여전히 실행 중인 유일한 것은 Gpio-0/Gpio-2를 사용하는 것이고 정지된 다른 3개는 Gpio14/gpio12를 사용하고 있습니다.
나는 이것이 더 이상 우연이 아니라고 생각한다.

esp02의 배선을 Gpio-0/Gpio-2로 변경하고 이를 0202 버전 코어 2.4.1로 다시 업그레이드하면 이 gpio 변경 후에도 여전히 활성 상태인지 확인할 수 있습니다.
완료

방금 읽기를 개선하기 위해 커밋을 추가했습니다.
https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c 참조

테스트 버전을 빌드할 수 있습니까, 아니면 제가 빌드하기를 원하십니까?

당신이 저에게 빈을 제공할 수 있다면 나는 esp를 실행하는 gpio12/14에서 둘 다에 두는 것을 기쁘게 생각합니다.
그런 다음 파일이 동일하고 로컬 영향 등이 없는 것이 확실합니다.

시간이 좀 걸렸지만 테스트 빌드 는 다음과 같습니다.

알았다,

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에는 이제 Gpio-0/Gpio-2 및 메가 20190202 버전 코어 2.4.1에 mhz19가 있습니다.

Bummer가 실수로 여기에서 게시물을 삭제했습니다. 내 기억에서 다시 작성해 보세요.

어제 저녁 내 esp의 02, 08 및 18 중 3개가 Domoticz에서 빨간색으로 바뀌었고 Co2 센서 데이터가 없습니다.
그 중 두 개에는 특별 버전 core 2.4.1 및 gpio 12/14가 있습니다. 웹 콘솔을 재부팅해도 문제가 해결되지 않고 다음만 생성되었습니다. MHZ19: 알 수 없는 응답: 0 0 0 0 0 0 0 0 0 그러나 esp18 co2 측정값은 약 1시간 후에 다시 살아났고 0:56에 적절한 값을 다시 보내기 시작했습니다.

Esp08도 재부팅을 받았고 esp02도(이 중 하나는 esp01과 동일한 gpio0/2를 가짐) 둘 다 복구되지 않았으며 오늘 아침에 둘 다 2분 동안 전원을 껐다가 다시 정상으로 돌아왔습니다.

이제 esp02의 소프트웨어 버전을 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4로 변경하여 코어 버전도 테스트할 수 있습니다. gpio 변경은 이전(현재 2.4.1) 버전을 실행하는 데 차이가 없었습니다.
esp02는 오늘 단일 체크섬 실패를 표시했습니다. 체크섬(통과/실패): | 79/1

나는 또한 처음에 esp08용 syslog를 활성화했는데 아래 설정으로 특정 설정을 원하면 문의하십시오.

다음을 표시하는 게시물에서 구성을 항목화할 수도 있습니다(다음 게시물도 가능, 편집할 필요 없음).

• 내부 단위 nr("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

-- frozen 은 CO2 판독값을 제외하고 잘 작동함을 의미합니다.

22:57 esp08 다시 고정, 카운터 체크섬(통과/실패): | 1077/2가 발견되면 syslog를 따로 보관합니다.
05:05 esp18 다시 고정, 카운터 체크섬(통과/실패): | 1076/2
06:25 esp08 다시 고정, 카운터 없음, 이번에는 esp가 완전히 충돌했으며 syslog가 있습니다.
12:57 esp18 다시 멈췄습니다. 카운터 체크섬(통과/실패): | 116/2
20:43 esp18 다시 고정, 카운터 체크섬(통과/실패): | 316/2가 mhzreset 명령을 시도했습니다.
변경 사항이 없습니다. 센서가 mhz19 알 수 없는 응답을 보내고 있습니다. 0 0 0 0 0 0 0 0
메시지가 계속해서 표시되고 여러 시도를 시도했지만 해결되지 않고 노드의 전원을 껐다 껐다 켰습니다.

기즈,

esp08의 마지막 syslog에 대한 분석을 수행했는데 실행되는 시간 동안 다음과 같은 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 | 그렙 응답 | 그렙 'ff 0 0 0 0 0 0 0 0' | 화장실 -l

그리고 그 cmdline을 두 번째 알 수 없는 응답 변형으로 변경한 후 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: Unknown response: ff 0 0 0 0 0 0 0 0)는 오늘 아침에 멈추기 전까지 6번 정도 연속해서 나타났습니다.

센서 자체가 충돌하는 것 같은데 왜 지금 이러는지 이유가 생각이 안나네요.
우리 소스에는 MH-Z19 센서의 재설정을 호출하는 명령이 있지만 데이터시트에는 문서화되어 있지 않습니다.
그래서 상태를 모릅니다.
이렇게 멈춘 노드에서 해당 명령을 호출할 수 있습니까?

편집: 해당 명령은 mhzreset 입니다.

메가 20181231 2.4.1 이후에 약간의 변경이 있어야 합니다. 내가 아직 찾은 한 MHZ19에 이 결과가 있는 4Mb 버전. gpio 12/14에서도 문제 없이 몇 주 동안 실행되고 있습니다.

다음에 무언가가 작동을 멈추면 시도할 것입니다. 23:20에 esp18이 고정된 것을 발견했고 mhzreset은 이를 변경하지 않았습니다(위의 로그 참조).

mhzreset 명령은 웹 콘솔에서 명령 창을 열지 않고 syslog에서 여러 번 시도한 후에도 Ok를 다시 보고하지 않습니다.
<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: 센서 재설정을 보냈습니다!
너무 쉽게 보냈지만 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는 systlog를 따로 보관합니다.

그리고 확실히 하자면 이 노드는 이전 펌웨어 버전에서 제대로 실행되고 있었습니까?

예, ESP_Easy_mega-20181231_normal_ESP8266_4096이 있었고 여전히 괜찮습니다.
그들은 문제 없이 몇 주 동안 달릴 것입니다.

SWserial 라이브러리의 최근 변경 사항을 살펴보았습니다. 현재 사용 중인 라이브러리이기 때문입니다.
변경 사항 중 하나는 9600 보드에 대한 TX 전송에서 더 이상 인터럽트를 사용하지 않는다는 것입니다.
이 테스트 빌드 를 시도할 수 있습니까?

NB 또한 웹 페이지를 제공할 때 이상하게 작동하기 때문에 핵심 2.5.0 빌드를 제거했습니다.

ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin을 실행하는 Esp08 및 Esp18
이 둘은 또한 syslog 서버에 데이터를 보내므로 로그 데이터가 기록됩니다.

다른 두 개는 내일 뒤따를 것입니다. 그 중 하나는 Mhz19A일 수 있습니다. 그리고 그렇습니다.

하드웨어 구성은 현재 다음과 같습니다.
Esp01에는 gpio0/gpio2에 MHZ19A가 있습니다.
Esp02에는 gpio0/gpio2에 MHZ19B가 있습니다.
Esp08에는 gpio12/gpio14에 MHZ19B가 있습니다.
Esp18에는 gpio12/gpio14에 MHZ19B가 있습니다.

모두 동일한 테스트 버전의 esp-easy에서 다음에서 실행됩니다.
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

업데이트

06:01 esp08 다시 고정, 카운터 손실(사용자 발생) syslog를 따로 보관합니다.

05:21 Esp18 고정, 체크섬(합격/불합격): | 1460/0, syslog를 따로 보관했습니다.
12:53 Esp08 고정 , 체크섬(합격/불합격): | 1351/28, syslog를 따로 보관했습니다.

코어 2.4.1 빌드는 해당 테스트 빌드에 포함되지 않았으므로 해당 코어 버전만 포함하는 빌드를 만들었습니다. ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin과 동일한 코드의 코어 2.4.1 빌드
그 하나는 이전 버전의 SoftwareSerial 라이브러리를 사용합니다.
작동하면 사용된 SW 직렬 라이브러리를 변경하겠습니다.

특수 버전으로의 업그레이드 시작: 현재 4개 노드 모두에 대한 firmware.bin, 12:30에 완료

내가 가장 먼저 알아차린 것은 Esp08이 정지되었고, 이 펌웨어 업데이트가 MHZ19B를 다시 시작했고, 다시 살아났습니다. 초기화 의미: 센서가 합리적인 C02 값을 제공하므로 이것도 훨씬 빨라 보였습니다.

테스트 노드에서도 이전 SWserial 라이브러리를 실행하고 있으며 실제로 훨씬 더 잘 작동하고 있습니다.
예를 들어 Eastron 에너지 모니터링은 수신된 라인의 약 20 - 30%가 손상되었지만 지금은 완벽하게 실행되고 있습니다. (아직 실패한 체크섬 없음)

방금 HW/SW 직렬 래퍼와 관련하여 많이 변경한 새 테스트 빌드 를 만들었습니다.
이제 SWserial 및 HW 직렬 모두에 대한 Eastron 플러그인과 함께 작동하며 SWserial은 이제 20180131까지 사용했던 이전 라이브러리를 사용합니다.

그래서 이것은 실제로 0202 버전과 동일하지만 20181231 버전과 동일한 직렬 라이브러리를 사용하여 직접 업그레이드하겠습니다. 잠시만

ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin 설치
지금 Esp0/02/08/18에서

보자 ..

예, HWserial/SWserial 래퍼가 있으므로 올바른 핀을 사용하는 즉시 HWserial로 쉽게 전환할 수 있습니다.

여전히 HWserial0에 대한 추가 옵션으로 GPIO2를 추가해야 하며 코드에서 수행할 정리 작업이 여전히 남아 있습니다.

처음 몇 시간이 지남에 따라 그들은 여전히 ​​작동하며 마지막 업데이트 후에 알 수없는 것을 볼 수 없습니다.
응답 ff 7 x 0 또는 8 x 0 메시지가 더 이상 esp08 또는 esp18의 syslog에 있습니다.

2개 노드의 syslog-data를 살펴보는 데 시간이 좀 걸렸습니다.
Esp08에는 때때로 코드가 달라지는 알 수 없는 응답이 있습니다.
Esp18은 아직 어떠한 결함도 생성하지 않았습니다.

좋은 소식입니다.
센서로 전송된 데이터가 손상되는 문제가 있었던 것 같습니다.
그러면 센서 자체가 충돌할 수 있습니다.

Eastron 플러그인(더 많은 데이터 전송)을 사용하면 체크섬 오류 수가 크게 감소했습니다.
메시지의 약 20 - 30% CRC 오류에서 SWserial을 사용하여 거의 0.(10,000개 메시지에서 1개의 오류).

여전히 잘 실행되고 있습니다. 4개 모두

릴리스 20190215의 고정 목록을 살펴보면 해당 버전이 여기 4개의 Co2 측정 노드에서 실행 중인 버전과 동일한가요?

거의 같다.
최소한 직렬 포트와 플러그인의 코드는 동일합니다.

그런 다음 그대로 두고 "특수"로 테스트를 계속합니다.

릴리스에 포함된 내용과 포함되지 않은 내용이 명확하지 않은 경우 일부 숫자가 일치했습니다.

예, 어제 병합한 큰 PR은 지난 주에 만든 모든 테스트 빌드의 소스였습니다.

Esp08이 14:17에 고정됨, 카운터 체크섬(통과/불합격): | 3292/70, syslog는 추가 분석을 위해 따로 보관

그리고 노드의 간단한 재부팅(또는 설정 저장)이 센서를 다시 시작했습니까(전원이 꺼지지 않음)?

다음에 시도하고 카운터를 확인한 후 전원을 껐다 켭니다.

Esp08 다시 고정, 카운터 체크섬(통과/실패): | 2660/55

co2-device 매개변수를 저장하면 정지가 해결되었습니다!

Esp08 18:18 다시 고정, 카운터 체크섬(통과/불합격): | 2660/55

co2-device 매개변수를 저장하면 정지가 해결되었습니다!

알겠습니다. 재설정을 수행할 수 있습니다.
N개의 알 수 없는 응답에 대한 검사를 추가한 다음 초기화를 다시 수행합니다.

그러면 이 문제를 완전히 해결할 수 있습니다.

현재로서는 우리가 그들 모두에서 발생했던 전체 직렬 문제가 이제 modelA와 3개의 Mhz19B 모델 센서 중 2개에서 사라진 것 같습니다.
모델 B인 Esp08은 로그 파일에 변수 "알 수 없는 응답(변경할 때마다) 16진수 값"이 있는 것을 본 유일한 것입니다. 이 센서가 잘못 작동할 때 플러그인에서 재설정될 수 있다면, 해결책이 될 수 있습니다.

지금 모두 Mega 201902026 4Mb로 업그레이드 중입니다.

내가 처음 알아차린 것은 Co2 센서 유형 mhz19B가 플래시 새 이미지 직후에 정확한 값을 제공한다는 것입니다. 이전보다 훨씬 빠릅니다.

이것은 정말 유망하게 들립니다! 나는 이 스레드를 보고 있었고, 마침내 업그레이드할 수 있기를 기다리고 있습니다. :grin: MH-Z19와 PMS7003이 모두 연결된 노드가 있습니다. MH-Z19는 90% 이상 작동했지만 때때로 ESP를 재설정해야 했습니다.

하지만 PMS7003은 훨씬 더 많이 실패하는 것 같습니다. 대부분의 경우 재설정해도 도움이 되지 않지만 몇 초 동안 전원 연결을 끊으면 문제가 해결될 수 있습니다. 나는 그것의 커넥터가 범인일지도 모른다고 의심했지만 그것을 디버깅하는 데에는 들어가지 않았다. 이 스레드는 여전히 펌웨어와 관련이 있는지 궁금합니다. 데이터가 더 중요하기 때문에 MH-Z19에 문제를 일으키지 않을 것이라고 확신할 수 있을 때 시도해 보겠습니다.

그리고 예, #2349는 MH-Z19 코드만 건드렸지만 실행 중인 빌드는 "20100 - Mega(core 2_4_0)"이며 꽤 오래된 것으로 가정합니다.

문제의 양쪽에서 이러한 끈기를 보이는 경우는 드물다고 말하고 싶습니다. 나는 많은 사람들이 며칠 만에 포기했을 것이라고 생각합니다. 이 구경꾼 @TD-er와 @pwassink의 인사를 전합니다!

업그레이드하기 전에 1일 더 기다려야 할 수 있습니다.
저는 지금 네트워크 연결을 위한 몇 가지 패치 작업을 하고 있습니다.

정보 주셔서 감사합니다! 어쨌든 @pwasink 보고를 잠시 기다리려고 했습니다(게으른 나).

현재 빌드 이후로 많은 것이 변경되었으며 슬프게도 모두 긍정적인 것은 아닙니다.
우리가 여전히 해결하려고 하는 문제 중 하나는 하드웨어 워치독 재부팅입니다. 따라서 현재 설정의 백업을 유지하고 사용 중인 현재 버전을 기록해 두는 것이 좋습니다. 확인차.
오늘의 수정 사항으로 이러한 재부팅을 조금 개선하기를 희망하지만 이러한 재부팅에는 여러 가지 다른 원인이 있기 때문에 오늘의 수정 사항이 모든 것을 처리할 수 있다고 생각하지 않습니다.

메모했습니다. ESPEasy와 같은 시스템에서 회귀를 피하는 것이 얼마나 어려운지 상상할 수 있을 뿐입니다. 업그레이드를 수행한 후 회귀를 보고할 것입니다(물론 별도의 문제로).

여기에 있는 두 개의 ESP를 업그레이드할 계획입니다. 이를 기반으로 MH-Z19, PMSx003, BMx280, TSL2561, DHT22 센서 또는 OLED SSD1306 디스플레이 처리에 회귀가 있는지 관찰할 수 있습니다. 다른 ESP의 TSL2561도 데이터 반환을 무작위로 중지하는 경향이 있습니다(매우 드물지만). 빌드 "20102 - Mega"를 실행 중입니다.

그것은 빌드가 아니라 내부 파일 형식입니다.

최소한 "빌드" 필드에 있습니다. 바이너리 파일 이름은 "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames"입니다. 아마도 PlatformIO에서 직접 플래시했을 것입니다. 거의 1년 전과 동일한 버전을 플래싱하는 데 약간의 어려움이 있을 수 있습니다. 나는 태그를 언급하지 않고 어떤 메모도하지 않았습니다. :joy: 모험심이 충분하지 않다면 펌웨어 백업을 할 수 있을 것 같습니다.

sysinfo 페이지에 빌드 타임스탬프가 없습니까?

타임 스탬프가 있지만 그렇게하기 전에 최신 코드를 가져 왔는지 기억이 나지 않으므로별로 도움이되지 않습니다. 그러나 물론 그것은 약간의 야구장을 제공합니다.

이것은 MH-Z19 및 PMS7003을 호스팅하는 ESP가 아닙니다.

그러나 나는 이것이 주제에서 벗어나고 있다고 생각합니다. 스레드를 일시적으로 가로채서 죄송합니다. 어쨌든 제 의견에 답해주셔서 감사합니다!

이것은 어떤 버전에서 수정되었습니까?

몇 시간 후 MHZ19: 알 수 없는 응답: 0 0 0 0 0 0 0 0 0
재부팅해도 해결되지 않고 플러그를 뽑았다가 다시 꽂아야 합니다.

wemos 1d mini pro를 사용하고 있습니다. 이 버전에 수정 사항이 있습니까?

빌드:⋄ | 20104 - 메가
-- | --
시스템 라이브러리:⋄ | ESP82xx 코어 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 PUYA 지원
Git 빌드:⋄ | 메가-20191003
플러그인:⋄ | 46 [일반]
빌드 Md5: | 3180a4d3e118166b3414444513a6169
Md5 확인: | 통과했다.
빌드 시간:⋄ | 2019년 10월 3일 02:15:29
바이너리 파일명:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

감사 해요

예 및 이전 버전도 마찬가지입니다.
10월에 다른 문제가 있었기 때문에 20190928 빌드로 시도하는 것이 좋습니다.

플러그인 페이지가 몇 시간 동안 실행된 후 표시되는 읽기 오류 수를 확인하고 싶을 수도 있습니다.

예를 들어 내 장치 중 하나(가동 시간 3일)

NB 필터(스크린샷에서 "Unstable 사용"으로 설정됨)는 MH-Z19B 센서에서 의미가 없으며 -A 버전에만 적용 가능합니다.

그리고 또 하나:

보시다시피 실패한 읽기 횟수는 최소입니다.
거기에 약간의 오류가 있으면 다른 문제가 있을 수 있습니다.

그 11개 재설정은 플러그인을 다시 인/아웃하지 않고 다시 부팅하도록 하려고 합니다. 오류가 표시되지는 않지만 다시 시도해 볼 수 있습니다. 소프트웨어 직렬을 사용해야 합니까?

하드웨어 직렬이 더 좋지만 도구->고급->직렬 포트에서도 직렬 포트를 비활성화해야 합니다. (스크린샷에 명시된 대로 :))

보드에 있는 USB-직렬 어댑터가 통신에 영향을 미칠 수 있는지 확실하지 않습니다.
확실하지 않은 경우 소프트웨어 직렬로 변경할 수 있습니다.

빌드: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
FHEM에 보고합니다.
비슷한 문제가 있었습니다. MH-Z190B 센서가 몇 시간마다 멈추고 하드웨어 직렬을 사용할 때 400으로 계속 떨어집니다.
소프트웨어 직렬로 전환한 후 정상적으로 작동하는 것으로 보이며 더 이상 정지하지 않습니다.
2개의 스크린샷이 첨부되었습니다.

I2C가 부착된 BME280은 잘 작동하고 항상 보고합니다.

흠 이상하네요.
어떤 HW 직렬 포트에 연결되었습니까?
보드에 연결된 다른 것은 무엇입니까? (예: USB에서 직렬 칩으로)
도구->고급 페이지에서 "일련 사용"이 선택 해제되어 있습니까?

TXD0 및 RXD0을 사용하여 USB 포트(CH340 ) Wemos D1 mini.
"직렬 사용"은 "직렬 설정 - 직렬 포트 활성화:"가 선택되었음을 의미합니까? 나는 USB로 메시지를 읽을 수 있도록 이것을 체크 상태로 두었다.

ESP8266의 HW 직렬은 Serial0을 사용합니다.
동일한 직렬 포트에도 로그를 보내는 경우 해당 포트를 통해 로그를 보낼 때 수신하는 "명령"을 이해하지 못하기 때문에 센서가 충돌할 수 있습니다.

HW Serial 포트에 무언가를 연결하면 더 이상 다른 데이터를 보내지 않아야 합니다. 따라서 도구->고급 페이지에서 "시리얼 사용"을 비활성화해야 합니다.

어제 두 번째 Sensor MH-Z19C를 받았습니다. 이것은 Serial2의 HW-Serial과 잘 작동하는 것 같습니다. 센서가 모두 핀 D7(GPIO 13) 및 D8(GPIO 13)(RXD2 및 TXD2)에 연결되었으므로 Serial0(핀 RXD0(GPIO3) 및 TXD0(GPIO1))과 충돌이 없어야 합니다. 핀아웃 이해하기. 첫 번째 센서(다른 공급업체의 MH-Z19B)는 제대로 작동하지 않는 가짜일 뿐이라고 생각합니다...
따라서 해당 센서를 구입할 때 주의하십시오. 두 번째 것은 어제 받은 Winsen 로고와 테스트 인증서가 포함된 훨씬 더 나은 포장에 있었습니다. 먼저 나에게 팔았던 것보다 공급자가 더 심각한 것 같다.