Sepertinya terkait dengan perubahan serial yang saya buat baru-baru ini.

Pin gpio apa yang Anda gunakan?

Mungkin, mari kita lihat, saya kira Anda telah menemukan titik Gijs :-)

esp01 = Gpio0 Gpio2 (belum ada masalah yang terlihat)
esp02 = Gpio14 Gpio12
esp08 = Gpio14 Gpio12
esp18 = Gpio14 Gpio12

Petrus

Saya memiliki dua node di sini, saya juga dapat mengujinya nanti sore

Oke,
Kesalahan tidak langsung, mereka berhenti mengirim setelah beberapa saat, dan cukup bertahan dalam hal itu, reboot atau sw downgrade tidak cukup untuk membuat mereka mengirim data lagi. Mereka membutuhkan siklus daya dan beberapa waktu antara mati dan hidup.

Berapa lama "setelah beberapa saat" ?
Saya baru saja menyiapkan node menggunakan salah satu sensor ini dan juga BMP280 terhubung.
Ini menggunakan GPIO-14 & -12 untuk sensor CO2.

beberapa jam, kemarin semuanya bekerja, pagi ini saya memiliki 3 dari 4 dengan status yang sama.

Dan mereka semua boot pada waktu yang sama, sebelum mereka semua berhenti bekerja?

ya, semuanya dimulai ulang/diperbarui dalam waktu satu jam, saya pikir, memperbaruinya kemarin malam. dan pada malam hari mereka berhenti bekerja

Saya baru saja akan memperbarui node saya tetapi untungnya memperhatikan ini. @TD-er mana yang akan menjadi rilis terbaru sebelum perubahan pada Serial yang Anda duga mungkin penyebabnya? Atau akan lebih berguna jika saya mem-flash versi terbaru untuk melihat apakah saya akan mengalami masalah yang sama?

Jika ada pembaruan yang hilang bukan masalah besar, saya akan menyarankan versi terbaru.
Untuk mempertahankan versi sebelum pembungkus port serial, Anda dapat menggunakan 20181231. (Saya pikir saya melakukan perubahan tahun ini)

saya melakukan downgrade 3 "masalah" esp ke 20181231 kemarin, dapat mengonfirmasi bahwa mereka masih mengirim data tanpa perubahan perangkat keras, sekarang selama 24 jam sehingga ketiga esp masih menggunakan gpio12 dan gpio14 dalam kasus saya

Adakah keberuntungan dengan membuatnya kembali Gijs ?

Tidak, node saya masih mengirimkan nilai dan menjalankan build mulai 16 Januari. (inti 2.5.0)

saya menggunakan ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin pada node tersebut, yang memiliki inti 2.4.1 saya percaya?

@pwassink Itu benar.
Anda juga dapat melihat build inti di halaman sysinfo.

Saya menginstal versi itu ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin kembali ke esp02 di sini, mari kita lihat apakah itu terjadi lagi

Hmm,
Mungkin hari dalam seminggu atau posisi bulan memiliki pengaruh tertentu,
Saya tidak melihat kesalahan yang terjadi kembali di sini dalam beberapa hari terakhir.

Tampaknya bekerja dengan baik di sini juga.
Saat itu hampir bulan purnama ketika Anda melaporkannya, jadi saya rasa seharusnya begitu ;)

Memperbarui,

saya membiarkan esp02 berjalan dengan versi ESP_Easy_mega-20190116_normal_core_241_ESP8266_4096.bin yang masih berjalan sebagaimana mestinya.

Kemarin saya memperbarui sisa node saya ke ESP_Easy_mega-20190121_normal_core_241_ESP8266_4096.bin

Dan esp-18 berbunyi lagi pada 06:55 waktu setempat, semua berfungsi sebagaimana mestinya, kecuali sensor MHZ19 Co2, di tab perangkat itu menampilkan "nilai bagus yang terakhir diketahui" dari sekitar pukul 07:00 dan lagi dengan entri yang sama di Logfile :
MHZ19: Kesalahan, waktu habis saat mencoba membaca
MHZ19: Respons tidak diketahui: 0 0 0 0 0 0 0 0 0

Esp-18 menggunakan Gpio 14 / 12
itu adalah Nodemcu dengan Ch340 versi 2 dari 3 dari ali
Reboot jarak jauh melalui konsol web tidak menyelesaikan masalah
lagi itu menampilkan entri yang disebutkan di atas beberapa kali
Setelah powercycle
78640: MHZ19: Kesalahan, waktu habis saat mencoba membaca
78641: MHZ19: Kesalahan membaca: checksum = 202 / 0 byte baca => 255/168/12/161/226/255/0/0/0/
78643: MHZ19: Menggeser 1 byte untuk mencoba memperbaiki penyelarasan buffer
Setelah beberapa waktu lagi:
255652: MHZ19: Nilai PPM: 1584 Nilai Temp/S/U: 25/0/0,00
255656: ACARA: Rik-CO2#PPM=1584.00
255656: ACARA: Rik-CO2#PPM=1584.00 Waktu pemrosesan: 1 milidetik
255659: ACARA: Rik-CO2#Suhu=25.00
255659: ACARA: Rik-CO2#Temperature=25.00 Waktu pemrosesan: 1 milidetik
255662: ACARA: Rik-CO2#U=0,00
255662: ACARA: Rik-CO2#U=0,00 Waktu pemrosesan: 1 milidetik

Tampaknya berfungsi lagi sekarang, tetapi membutuhkan siklus daya sekitar 2 menit tanpa daya

Apakah perlu melakukan sesuatu pada saat itu? Bisakah sesuatu yang dapat menyebabkan gangguan wifi di ESP?

Tidak ada sama sekali,

Tidak ada pengaturan ulang terjadwal, reboot, backup, reset wfi, pembersihan dhcp atau alasan eksternal apa pun pada saat itu

Dan wifi terus bekerja dengan baik hanya pembacaan mhz19 yang berhenti, semua sensor (berbasis i2c) lainnya pada esp yang sama masih berfungsi

Pagi ini jam 03:00 terjadi lagi dengan Esp-18 menjalankan versi 0121 Mega, Kesalahan yang sama di esp-logfile seperti sebelumnya, sensor lain berfungsi dengan baik

Dan pada jam 19:05 esp02 yang berjalan dengan ESP_Easy_mega20190116_normal_core_241_ESP8266_4096.bin juga mogok, situasinya sama seperti di atas, tidak ada data lagi dan entri yang sama dalam logging.

Sekali lagi 2 hickup hari ini, esp02 dan esp18 keduanya salah lagi kesalahan yang sama di log
Perangkat lunak 2 versi yang terlibat, 0116 dan 0121 keduanya 2.4.1 inti dan versi 4 Mb
perangkat keras esp02 adalah nodemcu-d1-mini / esp18 adalah nodemcu-v2 keduanya menggunakan gpio12/gpio14

Bisakah Anda mencoba build ini di salah satu node Anda?

ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Itu berjalan di salah satu node saya dengan MH-Z19 dan sekarang memiliki waktu aktif 54 hari 23 jam 21 menit
Itu karena listrik padam...
Yang ini berjalan dengan baik dengan pembaruan rutin nilai CO2.

saya akan,

tetapi apakah saya sudah menyebutkan sebelumnya bahwa hingga versi mega 20181231 core 2.4.1 normal 4Mb tidak ada masalah stabilitas yang dilaporkan yang terlihat, jadi mengapa versi khusus ini?

saya akan mengunduh versi spesifik itu dan menginstalnya ke eesp02 dan esp18 co2-measuring node, tetapi masalah muncul di kisaran mega-2019* tidak lebih awal menurut pendapat saya Gijs ..

Oke, kalau begitu memang tidak ada gunanya.

Versi spesifik itu berjalan pada versi yang saya miliki yang tampaknya (sayangnya tidak biasa) stabil.
Dan Anda benar, jika itu berjalan dengan baik hingga 20181231, maka tidak ada gunanya mencoba yang lebih lama.

Namun demikian,
Esp02 dan esp18 berjalan di ESP_Easy_mega-20181109_normal_ESP8266_4096.bin sekarang
Esp01 dan Esp08 berjalan di ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin

Dan kita akan melihat

Catatan, mata saya baru saja menangkap bahwa versi 1109 memiliki nomor build 20102 jadi itu jauh dan berbeda?

Gijs,

Saya mungkin telah menemukan petunjuk lain tentang masalah ini.

beberapa menit yang lalu Esp08 A nodemcu ch340V2 4Mb saya yang menjalankan ESp-Easy_mega_20190121_normal_core_241_ESP8266_4096.bin berhenti mengirim co2data juga.

Cuplikan log
377508579: UDP : 60:01:94:0F:AF:9D,192.168.3.46,17
37508785: UDP : 24:0A:C4:82:F2:B8,192.168.3.51,21
37059501: 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: Kesalahan baca: checksum = 120/248 byte baca => 255/134/5/183/71/128/15/112/248/
370515677: MHZ19: Menggeser 1 byte untuk mencoba memperbaiki penyelarasan buffer
370517702: ACARA: Jam#Waktu=Rabu,12:19
370517755: ACARA: Jam#Waktu=Rabu,12:19 Waktu pemrosesan:53 milidetik
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

Ini adalah pertama kalinya saya melihat kesalahan ini, mungkin ..

Kesalahan checksum harus ditangani dengan lebih anggun.
Mungkin kita harus menambahkan beberapa ambang batas kapan harus mulai bergeser untuk mencari awal baru yang baik.
Atau algoritme yang lebih baik untuk sinkron lagi.
Sejauh yang saya tahu, tidak ada perubahan dalam kode untuk ini selama lebih dari setahun. Hanya ada perubahan dalam cara koneksi port serial dibuat, jadi saya benar-benar tidak tahu mengapa ini mengarah ke masalah ini.

Saya memiliki gagasan bahwa sensor mhz19 itu sendiri memasuki status "diblokir" setelah beberapa jam miskomunikasi atau sebagai akibat dari tidak dapat mengeluarkan data. ?
Motivasi: reboot atau bahkan pembaruan sw penuh tidak menyelesaikan status itu, mhz19 harus tidak berdaya selama satu menit atau lebih untuk mendapatkan kembali kehidupan, saya menemukan perilaku ini ketika macet dalam status yang terlihat seperti:
MHZ19: Kesalahan, waktu habis saat mencoba membaca
MHZ19: Respons tidak diketahui: 0 0 0 0 0 0 0 0 0

Kesalahan esp08 adalah pagi ini masih dapat dipecahkan dengan opsi reboot jarak jauh dari konsol web sehingga tidak sama dengan penguncian lengkap setelah beberapa jam saya menemukan dan melaporkan beberapa kali.

Tetapi menemukan ini setelahnya:
sekitar 1800 waktu setempat masuk ke status diblokir, reset, reboot melalui powercycle konsol tidak ada yang berhasil kali ini, Perangkat membutuhkan flash ulang dengan versi mega 20181231 4mb kemudian hidup kembali. Esp08 menggunakan kombinasi Gpio12/14 dan merupakan model nodemcu v2 ch340 juga

Kedengarannya cukup aneh, karena plugin memang mengirim perintah untuk mengumpulkan data sensor baru ke MH-Z19
Jadi saya tidak mengerti mengapa bahkan soft-reboot tidak berfungsi.
Saya juga akan menambahkan beberapa statistik untuk melihat seberapa sering terjadi kesalahan checksum (menerima akhir)
Jika itu sering terjadi, mungkin juga terjadi saat mengirim data ke sensor dan mungkin sensor kemudian dimasukkan ke dalam mode perintah yang tidak diketahui.
Mungkin beberapa konfigurasi resistor pull-up telah berubah ketika saya mengubah cara konfigurasi pin serial???

Itu mungkin,

akan memeriksanya sedikit lebih jauh besok atau selama akhir pekan yang akan datang mungkin saya akan dapat menemukan sesuatu, apakah sensor itu tidak banyak digunakan sehingga tidak ada yang mengalami perilaku yang sama?

Atau tidak digunakan oleh orang yang menjalankan build terbaru

Saya memiliki 2 MH-Z19b, keduanya berjalan pada build uji 20190116 tanpa masalah

Oke, hanya ingin tahu persis versi inti dari uji coba dan Gpio mana yang Anda gunakan?

Saya melihat 1 menjalankan ESP_Easy_mega-20190116_test_core_250_beta_ESP8266_4096.bin, yang lain ESP_Easy_mega-20190121_test_core_250_beta_ESP8266_4096.bin. Pada kedua sensor terhubung ke GPIO 13 & 12

Jadi itu inti lain dan satu GPIO lain yang Anda gunakan di 13/12, bukan GPIO 14/12 yang saya gunakan di sini

Hari ini saya update 4 dari 4 ke versi ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin

Mari kita lihat

Kalau dipikir-pikir, mungkin ada perubahan lain di perpustakaan SWserial yang digunakan sejak awal tahun ini.
Kami dulu memiliki pustaka SWserial versi kami sendiri, yang saya tambal untuk menggunakan lebih sedikit memori iRAM.
Tetapi sekarang kami menggunakan versi yang disertakan dalam pustaka inti dan untuk inti 2.5.0 ini mungkin merupakan versi yang lebih baru dari sebelumnya.
Juga mungkin ada beberapa perubahan dalam penggunaan interupsi pada koneksi berkecepatan rendah. (9600 baud dan lebih rendah)
Saya harus melihat ke dalam itu juga.

Itu masih tidak menjelaskan mengapa sensor tampaknya bisa menjadi sangat kacau sehingga perlu dimatikan untuk berfungsi normal kembali.

Dalam waktu 3 jam setelah memperbarui ke ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin esp18 saya terkunci lagi, reboot webconsole tidak berfungsi, diperlukan powerdown lagi.
yang lain masih berfungsi, akan ditambahkan di sini jika membekukan MHZ19 juga

Ya, yang lain esp18 berhenti mengirim Data CO2 yang masuk akal pada 19:05 malam ini, jadi kesalahan tetap ada di mega 202 core 2.4.1 kemarin setidaknya.
Yang itu kembali dan diturunkan ke versi 20181231 sekarang juga.

Sekitar tengah malam esp ketiga, esp02 membeku dengan pembacaan Co2, juga diturunkan ke 20181231 sekarang

Satu-satunya yang masih berjalan di ESP_Easy_mega-20190202_normal_core_241_ESP8266_4096.bin adalah yang menggunakan Gpio-0/Gpio-2, tiga lainnya yang membeku menggunakan Gpio14/gpio12.
Saya tidak berpikir ini adalah kebetulan lagi,

saya akan mengubah kabel esp02 menjadi Gpio-0/Gpio-2 dan memutakhirkannya ke versi 0202 core 2.4.1 lagi dan kita mungkin melihat apakah itu tetap hidup setelah perubahan gpio ini.
Selesai

Saya baru saja menambahkan komitmen untuk melakukan beberapa perbaikan pada bacaan.
Lihat https://github.com/TD-er/ESPEasy/commit/3d507bdbb9dc6dd4aee2ce0c7ce6c809ea7dfb7c

Bisakah Anda membuat versi pengujian untuknya, atau Anda ingin saya membuatnya?

Jika Anda bisa memberi saya tempat sampah, saya akan dengan senang hati meletakkannya di keduanya masih di gpio12/14 yang menjalankan esp
dan kemudian dipastikan filenya sama, tidak ada pengaruh lokal dll..

Oke, butuh beberapa waktu, tapi ini adalah tes build

Mengerti,

Esp08 dan esp18 berjalan pada versi uji ini dengan inti 2.4.1 sekarang, keduanya menggunakan gpio12/14

Ayo lihat !

Anda juga akan melihat beberapa indikator yang menunjukkan jumlah baris yang diproses dan nr kegagalan CRC

Ya, saya juga memilikinya di konsol sekarang!

akan meninggalkan 2 itu dan melihat pada interval tertentu jika penghitung itu meningkat.
Tetaplah mengabariku ..

Kedua sensor yang digunakan pada node pengujian adalah versi B sehingga deteksi juga berfungsi

Checksum (lulus/gagal): | 11/0
-- 08 --
Terdeteksi: | MH-Z19B

Checksum (lulus/gagal): | 8/0
-- 18 --
Terdeteksi: | MH-Z19B

Apakah Anda juga memiliki campuran MH-Z19 A/B atau hanya versi B yang lebih baru?
Seharusnya tidak masalah, hanya ingin tahu.

Apakah Anda juga memiliki campuran MH-Z19 A/B atau hanya versi B yang lebih baru?
Seharusnya tidak masalah, hanya ingin tahu.

Versi B, baru saja menambahkan info itu, deteksi juga berfungsi :-)

pembaruan kecil, semua masih berjalan dengan baik, yang dengan versi khusus Anda esp8 dan 18 menunjukkan penghitung yang meningkat tetapi masih tidak ada kesalahan atau kesalahan checksum, nilai saat ini adalah:

Esp08: Checksum (lulus/gagal): | 1795/0
Esp18: Checksum (lulus/gagal): | 724/0

dan yang lain yang gagal cukup konsisten esp02 juga masih berjalan sekarang dengan Gpio yang diubah
dan dengan demikian di-mini sekarang memiliki mhz19 pada Gpio-0/Gpio-2 dan mega 20190202 versi core 2.4.1

Bummer tidak sengaja menghapus posting di sini, coba buat ulang dari ingatan saya:

Kemarin malam tiga esp saya 02, 08 dan 18 menjadi merah di Domoticz, tidak ada data sensor Co2.
dua di antaranya memiliki inti versi khusus 2.4.1 , dan gpio 14/12. Reboot konsol web tidak menyelesaikannya, dan hanya menghasilkan: MHZ19: Unknown response: 0 0 0 0 0 0 0 0 0 tetapi pengukuran esp18 co2 hidup kembali setelah kira-kira satu jam, pada 0:56 ia mulai mengirimkan nilai yang tepat lagi .

Esp08 telah menerima reboot juga, dan esp02 juga (yang memiliki gpio0/2 sekarang sama dengan esp01) keduanya tidak pulih, dan pagi ini keduanya mendapat power-down 2 menit, setelah itu keduanya hidup kembali ok.

Saya sekarang mengubah versi perangkat lunak pada esp02 menjadi ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4 sehingga kami dapat menguji versi inti itu juga, gpio chnage tidak membuat perbedaan menjalankan versi lama (saat ini 2.4.1) menjadi jelas
esp02 memang menunjukkan satu kegagalan checksum hari ini: Checksum (lulus/gagal): | 79/1

Saya juga mengaktifkan syslog untuk esp08 hanya di awal, dengan pengaturan als di bawah ini, jika Anda ingin pengaturan tertentu, silakan bertanya.

Mungkin Anda juga bisa memerinci konfigurasi Anda di postingan (bisa juga postingan berikutnya, tidak perlu mengedit yang ini) dengan tampilan sebagai berikut:

• Unit internal Anda nr (untuk referensi Anda sendiri seperti "02, 08, 18)
• Membangun berjalan
• nr sukses/gagal (jika tersedia)
• jenis kegagalan/masalah

Informasi terperinci (bagi saya) lebih mudah diikuti dibandingkan dengan teks deskriptif.
Saya juga kadang-kadang membalas dari telepon saya.

esp08/18 ESP_Easy_mega-20190202-58-PR_2235_normal_ESP8266_4096 inti 2.4.1 gpio12/14
esp01/02 ESP_Easy_mega-20190202-58-PR_2235_normal_core_250_beta_ESP8266_4096 gpio 0/2

-- beku berarti bekerja dengan baik kecuali untuk pembacaan co2

22:57 esp08 dibekukan lagi, counter Checksum (lulus/gagal): | 1077/2 kesampingkan syslog saat ditemukan.
05:05 esp18 dibekukan lagi, counter Checksum (lulus/gagal): | 1076/2
06:25 esp08 dibekukan lagi, tidak ada penghitung, esp macet total kali ini, mendapat syslog
12:57 esp18 dibekukan lagi. counter Checksum (lulus/gagal): | 116/2
20:43 esp18 dibekukan lagi, counter Checksum (lulus/gagal): | 316/2 mencoba perintah mhzreset
Tidak ada perubahan apa pun, sensor mengirim mhz19 respons yang tidak diketahui 0 0 0 0 0 0 0 0
pesan berulang-ulang, mencoba beberapa kali tidak ada solusi, daya memutar simpul.

Gijs,

Saya melakukan beberapa analisis pada syslog terakhir esp08, selama jam berjalan saya melihat 78 kejadian:
08-02-2019T05:27:07.581181+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Respons tidak diketahui: ff 0 0 0 0 0 0 0 0

Pencarian otomatis menggunakan #cat messages-crash-esp08-0625 |grep MHZ19 | tanggapan grep | grep 'ff 0 0 0 0 0 0 0 0' | wc -l

dan setelah mengubah cmdline itu ke varian kedua yang tidak diketahui responsnya, linux menghitung 408 kali baris ini:
08-02-2019T10:44:06.855432+01:00 hub08 EspEasy - - - EspEasy: MHZ19: Respons tidak diketahui: 0 0 0 0 0 0 0 0 0

Penghitung kesalahan checksum dalam versi debug kustom Anda tidak lebih tinggi dari 2 sejauh yang saya lihat selama beberapa hari terakhir.
pesan kesalahan pertama (MHZ19: Unknown response: ff 0 0 0 0 0 0 0 0) datang beberapa kali enam atau lebih langsung setelah satu sama lain sebelum membeku pagi ini.

Sepertinya sensor itu sendiri mogok, tetapi saya tidak dapat memikirkan alasan mengapa ia melakukannya sekarang.
Di sumber kami ada perintah untuk memanggil reset sensor MH-Z19, tapi itu tidak didokumentasikan dalam lembar data.
Jadi saya tidak tahu statusnya.
Bisakah Anda mencoba memanggil perintah itu pada simpul yang macet seperti ini?

Sunting: perintah itu adalah mhzreset

Harus ada beberapa perubahan yang dilakukan setelah mega 20181231 2.4.1. Versi 4Mb yang memiliki hasil ini pada MHZ19 sejauh yang saya temukan. yang satu ini berjalan selama berminggu-minggu tanpa masalah bahkan pada gpio 14/12.

akan mencobanya lain kali sesuatu berhenti bekerja, pada 23:20 menemukan bahwa esp18 dibekukan, mhzreset tidak mengubahnya, lihat log di atas.

perintah mhzreset tidak membuka jendela perintah di webconsole, tidak melaporkan Ok kembali atau lebih, setelah beberapa upaya saya temukan di syslog:
<5>1 2019-02-08T23:25:34.164674+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sensor terkirim ulang!
<5>1 2019-02-08T23:25:36.313828+01:00 hub18 EspEasy - - - EspEasy: MHZ19: Sensor terkirim ulang!
jadi gampang katanya sudah terkirim, tapi sepertinya tidak dalam rasa yang mhz19 paham atau suka :-)

Perintah itu tampaknya melakukan sesuatu untuk versi 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

Jadi sepertinya tidak bisa digunakan di versi B.

Saya bisa berasumsi bahwa perintah seperti itu juga digunakan di startup/init plugin?
yang mungkin menjelaskan mengapa reboot / reset tanpa siklus daya tidak menyelesaikan masalah.

Tidak melihat kegagalan sampai sore ini:
15:43 esp08 dibekukan lagi, counter Checksum (lulus/gagal): | 2316/2 kesampingkan systlog.

Dan untuk memastikan, node ini berjalan dengan baik pada versi firmware yang lebih lama?

Ya sampai ESP_Easy_mega-20181231_normal_ESP8266_4096 adalah dan masih ok,
Mereka akan berjalan selama berminggu-minggu tanpa masalah

Saya melihat perubahan terbaru di perpustakaan SWserial, karena itulah yang sekarang kami gunakan.
Salah satu perubahan yang dilakukan di sana adalah tidak lagi menggunakan interupsi pada transfer TX untuk 9600 baud.
Bisakah Anda mencoba build tes ini ?

NB Saya juga menghapus build inti 2.5.0, karena mereka bertindak aneh saat menyajikan halaman web.

Esp08 dan Esp18 menjalankan ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
keduanya juga mengirim data mereka ke server syslog sehingga data log akan direkam

Dua lainnya akan menyusul besok, salah satunya mungkin Mhz19A, Dan memang begitu.

Konfigurasi Hw sekarang:
Esp01 memiliki MHZ19A di gpio0/gpio2
Esp02 memiliki MHZ19B di gpio0/gpio2
Esp08 memiliki MHZ19B di gpio12/gpio14
Esp18 memiliki MHZ19B di gpio12/gpio14

Semuanya pada versi uji yang sama dari esp-easy sekarang, berjalan di:
ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin

memperbarui

06:01 esp08 dibekukan lagi, penghitung hilang (disebabkan pengguna) mengesampingkan syslog.

05:21 Esp18 beku, Checksum (lulus/gagal): | 1460/0, singkirkan syslog
12:53 Esp08 beku , Checksum (lulus/gagal): | 1351/28, singkirkan syslog

Core 2.4.1 build tidak disertakan dalam test build itu, jadi saya hanya membuat satu yang hanya berisi versi core itu. core 2.4.1 build kode yang sama seperti di ESP_Easy_mega-20190202-82-PR_2235_normal_ESP8266_4096.bin
Yang itu menggunakan versi lama dari perpustakaan SoftwareSerial.
Jika berhasil, maka saya akan mengubah perpustakaan serial SW yang digunakan.

Mulai upgrade ke versi khusus: firmware.bin untuk semua 4 node sekarang, selesai pada 12:30

Hal pertama yang saya perhatikan, Esp08 dibekukan, pembaruan firmware ini memulai ulang MHZ19B, itu kembali hidup, dan init yang saya maksud: sensor memberi saya Nilai C02 yang masuk akal ini juga tampak jauh lebih cepat

Saya menjalankan perpustakaan SWserial lama pada node uji juga dan memang bekerja jauh lebih baik
Misalnya pemantauan energi Eastron memiliki sekitar 20 - 30% dari saluran yang diterima rusak, tetapi ini sekarang berjalan dengan sempurna. (belum ada checksum yang gagal)

Saya baru saja membuat test build baru di mana saya banyak berubah mengenai pembungkus serial HW/SW.
Sekarang berfungsi dengan plugin Eastron untuk serial SWserial dan HW dan SWserial sekarang menggunakan perpustakaan lama yang kami gunakan hingga 20180131.

Jadi ini sebenarnya sama dengan versi 0202 tetapi dengan serial lib yang sama dengan versi 20181231, saya akan langsung mengupgradenya.. sebentar

Menginstal ESP_Easy_mega-20190212-73-PR_2235_normal_ESP8266_4096.bin
di Esp0/02/08/18 sekarang

Mari kita lihat ..

Ya dan ia memiliki pembungkus HWserial/SWserial, jadi seharusnya mudah untuk beralih ke HWserial segera setelah Anda menggunakan pin yang benar untuk itu.

Saya masih perlu menambahkan GPIO2 sebagai opsi tambahan untuk HWserial0 dan masih ada beberapa pembersihan yang harus dilakukan dalam kode.

Karena jam pertama berlalu mereka masih bekerja, setelah pembaruan terakhir saya tidak dapat melihat yang tidak diketahui
respon ff 7 x 0 atau 8 kali 0 pesan di syslog dari esp08 atau esp18 lagi.

Butuh beberapa waktu untuk melihat syslog-data dari 2 node:
Esp08 masih memiliki respons yang tidak diketahui dengan kode yang bervariasi sesekali,
Esp18 belum menghasilkan kesalahan apa pun

Senang mendengarnya.
Saya pikir kami memiliki beberapa masalah di mana data yang dikirim ke sensor rusak.
Kemudian sensor itu sendiri mungkin macet, saya kira.

Dengan plugin Eastron (mengirim lebih banyak data) jumlah kesalahan checksum berkurang secara signifikan.
Dari sekitar 20 - 30% kesalahan CRC dalam pesan hingga mendekati 0. (1 kesalahan dalam 10.000 pesan) menggunakan SWserial.

Masih berjalan dengan baik, mereka berempat

Melihat daftar tetap rilis 20190215, apakah versi itu sekarang sama dengan versi yang saya jalankan pada node pengukuran 4 Co2 di sini?

Hampir sama.
Setidaknya kode untuk port serial dan plugin Anda sama.

Lalu saya biarkan apa adanya dan melanjutkan pengujian dengan "khusus"

Tidak jelas bagi saya apa yang termasuk dalam rilis dan apa yang tidak, beberapa nomor memang cocok.

Ya, PR besar yang saya gabungkan kemarin adalah sumber dari semua build tes yang saya buat minggu lalu.

Esp08 dibekukan pada 14:17, counter Checksum (lulus/gagal): | 3292/70, syslog disisihkan untuk analisis lebih lanjut

Dan apakah reboot sederhana (atau simpan pengaturan) dari node me-restart sensor (bukan matikan)?

Akan mencobanya lain kali, hanya menyalakannya setelah memeriksa penghitung.

Esp08 dibekukan lagi, counter Checksum (lulus/gagal): | 2660/55

simpan parameter perangkat co2 memang menyelesaikan pembekuan!

Esp08 18:18 dibekukan lagi, counter Checksum (lulus/gagal): | 2660/55

simpan parameter perangkat co2 memang menyelesaikan pembekuan!

OK, jadi dimungkinkan untuk melakukan reset.
Saya akan menambahkan centang untuk N tanggapan yang tidak diketahui dan kemudian melakukan init lagi.

Itu mungkin menyelesaikan masalah ini sepenuhnya.

Untuk saat ini seluruh masalah serial yang kami alami pada semuanya tampaknya hilang sekarang pada modelA dan dengan dua dari tiga sensor model Mhz19B.
Esp08, yang merupakan model B, adalah satu-satunya yang saya lihat dengan variabel "respons tidak diketahui (setiap kali berubah) nilai Hex " masih dalam file log, jika sensor ini dapat disetel ulang dari plugin saat berperilaku buruk, mungkin itu solusinya.

Upgrade semua ke Mega 201902026 4Mb sekarang.

Hal pertama yang saya perhatikan, jenis sensor Co2 mhz19B memberikan nilai yang benar hampir seketika setelah mem-flash gambar baru, jauh lebih cepat dari sebelumnya juga.

Ini terdengar sangat menjanjikan! Udah nonton thread ini, nunggu sebentar akhirnya bisa upgrage. :grin: Saya memiliki simpul yang memiliki MH-Z19 dan PMS7003 terpasang. MH-Z19 telah bekerja> 90% dari waktu tetapi kadang-kadang saya harus mengatur ulang ESP untuk itu.

PMS7003 tampaknya lebih banyak gagal. Sebagian besar waktu bahkan reset tidak membantu tetapi memutuskan daya selama beberapa detik mungkin memperbaikinya. Saya telah mencurigai konektornya mungkin menjadi pelakunya tetapi belum pernah men-debug-nya. Utas ini membuat saya penasaran apakah ini masih terkait dengan firmware... Saya akan mencobanya ketika saya cukup yakin bahwa itu tidak akan menyebabkan masalah dengan MH-Z19 karena datanya lebih penting.

Dan ya, saya perhatikan #2349 hanya menyentuh kode MH-Z19 tetapi build yang saya jalankan adalah "201000 - Mega (core 2_4_0)" yang menurut saya sudah cukup tua.

Saya ingin mengatakan bahwa jarang melihat kegigihan seperti itu dari kedua sisi masalah. Saya rasa banyak yang akan menyerah setelah beberapa hari. Angkat topi untuk Anda dari pengamat ini @TD-er dan @pwassink!

Anda mungkin ingin menunggu 1 hari lagi sebelum meningkatkan.
Saya sekarang sedang mengerjakan beberapa tambalan untuk konektivitas jaringan.

Terimakasih atas infonya! Saya berencana untuk menunggu laporan @pwassink sebentar (malas saya).

Ketahuilah bahwa banyak yang telah berubah sejak build Anda saat ini, dan sayangnya tidak semuanya positif.
Salah satu masalah yang masih kami coba atasi adalah boot ulang pengawas perangkat keras. Jadi, Anda mungkin ingin menyimpan cadangan pengaturan saat ini yang Anda miliki dan menuliskan versi saat ini yang Anda gunakan. Hanya untuk memastikan.
Saya berharap untuk sedikit meningkatkan reboot ini dengan perbaikan hari ini, tetapi karena reboot ini memiliki beberapa penyebab yang berbeda, saya tidak berpikir perbaikan hari ini akan menangani semuanya.

Catatan diambil. Saya hanya bisa membayangkan kesulitan untuk menghindari regresi dalam sistem seperti ESPEasy. Saya akan melaporkan regresi apa pun setelah saya melakukan peningkatan (tentu saja sebagai masalah terpisah).

Saya berencana untuk meningkatkan dua ESP yang saya miliki di sini. Berdasarkan itu saja saya dapat mengamati apakah ada regresi pada MH-Z19, PMSx003, BMx280, TSL2561, sensor DHT22 atau penanganan tampilan OLED SSD1306. TSL2561 di ESP lain cenderung berhenti mengembalikan data secara acak juga (cukup jarang). Ini menjalankan build "20102 - Mega".

Itu bukan build, tetapi format file internal (saya tahu membingungkan) Anda dapat menemukan nama/tanggal build di halaman sysinfo.

Setidaknya ada di bidang "build". Nama file biner adalah "ThisIsTheDummyPlaceHolderForTheBinaryFilename64ByteLongFilenames". Saya mungkin mem-flash-nya langsung dari PlatformIO. Saya mungkin mengalami kesulitan untuk menginstal versi yang sama seperti hampir setahun yang lalu. Saya tidak benar-benar membuat catatan apa pun, apalagi tag. :joy: Yah saya rasa saya bisa melakukan backup firmware jika saya tidak merasa cukup berani.

Tidak ada stempel waktu pembuatan di halaman sysinfo?

Ada stempel waktu tetapi itu tidak akan banyak membantu karena saya tidak ingat apakah saya telah memasukkan kode terbaru sebelum melakukan itu. Tapi tentu saja itu memberikan beberapa rata-rata.

Ini bukan ESP yang menampung MH-Z19 dan PMS7003.

Tapi saya kira ini akan keluar dari topik. Maaf untuk sementara membajak utas dan terima kasih telah membalas komentar saya!

ini diperbaiki di versi berapa?

setelah beberapa jam saya mendapatkan MHZ19: Respons tidak diketahui: 0 0 0 0 0 0 0 0 0
reboot tidak akan memperbaikinya harus mencabutnya dan memasangnya kembali

saya menggunakan wemos 1d mini pro, apakah versi ini memiliki perbaikan di dalamnya?

Bangun:⋄ | 20104 - Mega
-- | --
Perpustakaan Sistem:⋄ | ESP82xx Core 2_5_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.1.2 dukungan PUYA
Git Membangun:⋄ | mega-20191003
Plugin: | 46 [Biasa]
Bangun Md5: | 3180a4d3e118166b3414444513a6169
Cek Md5: | lulus.
Waktu Pembuatan:⋄ | 3 Okt 2019 02:15:29
Nama File Biner:⋄ | ESP_Easy_mega-20191003_normal_ESP8266_4M1M.bin

Terima kasih

Yap dan versi sebelumnya juga.
Saya sarankan mencoba dengan build 20190928, karena yang Oktober memiliki beberapa masalah lain (yang saya perbaiki selama sekitar seminggu terakhir)

Anda mungkin juga ingin melihat jumlah kesalahan baca yang ditampilkan pada halaman plugin, setelah dijalankan selama beberapa jam.

Misalnya salah satu unit saya sendiri (3 hari uptime)

NB filter (diatur ke "Gunakan Tidak Stabil" di tangkapan layar) tidak memiliki arti pada sensor MH-Z19B, itu hanya berlaku untuk versi -A.

Dan satu lagi:

Seperti yang Anda lihat, jumlah pembacaan yang gagal minimal.
Jika Anda memiliki beberapa kesalahan di sana, Anda mungkin memiliki masalah lain.

11 penyetelan ulang di mana saya mencoba untuk mem-boot-nya lagi tanpa plugin masuk dan keluar, saya tidak ingat melihat kesalahan apa pun tetapi saya dapat mencobanya lagi, haruskah saya menggunakan Serial Perangkat Lunak?

Hardware Serial adalah yang lebih baik, tetapi Anda juga harus menonaktifkan port serial di Tools->Advanced->Serial Port. (seperti yang dinyatakan dalam tangkapan layar Anda :))

Saya tidak yakin apakah adaptor USB ke serial yang ada di papan mungkin berpengaruh pada komunikasi.
Jika ragu, Anda dapat mengubah ke serial perangkat lunak.

Bangun: ESP_Easy_mega_20201130_normal_ESP8266_4M1M
melapor ke FHEM.
Saya memiliki masalah serupa: Sensor MH-Z190B membeku setiap beberapa jam dan terus turun hingga 400 saat saya menggunakan serial perangkat keras.
Setelah beralih ke serial perangkat lunak tampaknya berfungsi normal dan tidak membeku lagi.
2 tangkapan layar terlampir.

BME280 yang terpasang dengan I2C berfungsi dengan baik dan terus melaporkan setiap saat

Hmm aneh.
Ke port serial HW apa yang terhubung?
Apa lagi yang terhubung ke papan? (misalnya USB ke chip serial)
Apakah "Gunakan Serial" tidak dicentang pada halaman Alat->Lanjutan?

Terhubung ke GPIO-13 (D7) <- TX dan GPIO-15 (D8) -> RX (pertama di HW sekarang di SW) karena saya ingin menggunakan TXD0 dan RXD0 untuk membaca pesan melalui port USB (CH340 ) dari Wemos D1 mini.
Apakah "Gunakan Serial" berarti "Pengaturan Serial - Aktifkan port Serial:" dicentang? Saya membiarkan ini dicentang untuk dapat membaca pesan melalui USB.

Serial HW pada ESP8266 menggunakan Serial0.
Jika Anda juga mengirim log ke port serial yang sama, sensor mungkin macet karena tidak memahami "perintah" yang diterimanya saat log dikirim melalui port tersebut.

Jika Anda menghubungkan sesuatu ke port HW Serial, Anda seharusnya tidak lagi mengirim data lain. Dengan demikian Anda harus menonaktifkan "Gunakan Serial" pada halaman alat-> Lanjutan.

Kemarin, saya mendapat Sensor kedua MH-Z19C. Yang ini tampaknya berfungsi dengan baik dengan HW-Serial di Serial2. Karena semua sensor terhubung ke Pin D7 (GPIO 13) dan D8 (GPIO 13) (RXD2 dan TXD2) seharusnya tidak ada konflik dengan Serial0 (Pin RXD0 (GPIO3) dan TXD0 (GPIO1)) sejauh saya memahami Pinout. Saya pikir sensor pertama (MH-Z19B dari pemasok lain) hanya palsu yang tidak berfungsi dengan baik sama sekali, ...
Jadi berhati-hatilah saat membeli sensor tersebut. Yang kedua, saya dapatkan kemarin dalam kemasan yang jauh lebih baik dengan Logo Winsen dan sertifikat uji bergabung. Pemasok tampaknya lebih serius daripada yang menjual saya yang pertama.