Espeasy: Masalah wifi -tidak pernah berakhir cerita- kembali ke wifi berbasis non acara?

Dibuat pada 23 Apr 2018  ·  388Komentar  ·  Sumber: letscontrolit/ESPEasy

Seperti yang telah Anda perhatikan beberapa minggu terakhir, ada banyak masalah dengan wifi.
Ini semua dimulai ketika saya mengubah cara wifi beroperasi menjadi berbasis acara.

  • IP statis tidak berfungsi
  • Loop booting (ESP32)
  • Terhubung tetapi transfer data tidak memungkinkan (NTP tidak dapat terhubung ke 0.0.0.0)
  • Tidak ada AP yang menemukan kesalahan
  • Memuat halaman pengaturan dari mode AP tidak berfungsi (diubah ke inti 2.4.0 untuk ini)
  • Kesalahan batas waktu suar => tidak ada koneksi ulang yang tepat
  • Berbagai masalah terkait wifi lainnya.

Beberapa kesalahan ini terkait dengan versi inti, dan pembaruan ke inti 2.4.0 memang menimbulkan banyak masalah lainnya.
Dan kemudian ada masalah dengan pengaturan yang rusak yang juga terjadi pada periode ini. Itu tidak terkait dengan koneksi berbasis acara wifi, tetapi itu membuat saya mencari banyak masalah lain yang sebenarnya bukan masalah sama sekali tetapi hanya pengaturan yang rusak.

Jadi saat ini wifi state machine yang saya tulis terlalu rumit karena banyak perbaikan yang tidak ada perbaikan, karena barang tidak rusak.
Dan masih ada masalah nyata lainnya, baik yang disebabkan oleh inti 2.4.0 atau masalah wifi yang masih terbuka.

Jadi sekarang kita harus memilih:

  1. Kembali ke sloooowwww tapi wifi stabil (masih ada masalah dengan MQTT saat koneksi terputus)
  2. Investasikan lebih banyak waktu untuk mendapatkan wifi berbasis acara yang tepat + coba agar inti 2.4.1 berfungsi.
  3. Investasikan lebih banyak waktu untuk mendapatkan wifi berbasis acara yang tepat, tetapi tetap kembali ke inti 2.3.0
  4. Beberapa solusi perantara untuk melakukan wifi async dengan inti 2.3.0

Core 2.3.0 tampaknya memberikan lebih sedikit masalah dan menyisakan lebih banyak memori bebas.
Jadi saya rasa itu basis pilihan saya.
Ini berarti bahwa untuk wifi berbasis acara, masih ada beberapa masalah sehubungan dengan memuat halaman penyiapan saat konfigurasi awal diperlukan.

Bagaimanapun, ini harus berhenti sekarang dan menjadi stabil lagi.
Saat ini ada terlalu banyak masalah yang cukup sulit untuk dilihat sebagai masalah yang terpisah.

Ada saran lain?

Core related Stabiliy Wifi Fixed Discussion

Komentar yang paling membantu

Saya tidak yakin tentang LED status. Itu dipanggil dari fungsi MQTTconnect dan dari beberapa tempat lain.
Tapi mungkin Anda bisa menambahkan masalah untuk membuatnya dapat dipilih apa yang ditampilkan melalui LED itu?

Dan bagus untuk mendengar masalah MQTT tampaknya diperbaiki dengan batas waktu yang lebih rendah.
Kita mungkin harus membuatnya dapat dipilih.

Semua 388 komentar

Saya benar-benar tidak dapat berbicara tentang ini dari tingkat pemrograman tetapi menurut saya dari apa yang saya lihat adalah bahwa dengan pengecualian alamat ip statis adalah bahwa ketika menyiapkan unit "baru" wifi tampaknya berfungsi bagus. Saya belum melihat masalah koneksi dengan instalasi "baru" dengan firmware terbaru. Halaman web dimuat dengan cepat dan semuanya tampak cepat dan responsif. Saat Anda mencoba memutakhirkan adalah saat sebagian besar masalah ini tampaknya terjadi. Sepertinya ada masalah korupsi saat memutakhirkan ke firmware yang lebih baru.

Saya juga memperhatikan bahwa sepertinya banyak firmware yang dikompilasi pengguna mengalami masalah wifi. Hanya dari membaca semua posting masalah ini saya mendapatkan kesan itu. Saya bisa sepenuhnya salah tentang itu. Saya tidak mencoba mengatakan itu sebagai fakta, tetapi hanya kemungkinan.

Saya tidak dapat berbicara dengan MQTT karena saya tidak menggunakannya.

Nilai saya hanya 2 sen.....

Jika Anda condong ke opsi 3, saya mendukung Anda sepenuhnya. Saya tidak suka melihat kami membatalkan peningkatan yang telah diberikan WiFi berbasis acara Anda kepada kami. Core 2_4_x mungkin lebih mudah untuk dikembalikan/dialihkan ke up stream?

Dari sudut pandang pengguna:
Saya akan melanjutkan dan menggunakan Core 2.4.1 yang baru sesegera mungkin.
Pengguna selalu dapat menggunakan versi yang lebih lama.

Jangan lupa, core 2.4.x memperbaiki beberapa masalah:
PWM berkedip adalah sejarah (#1156 diperbaiki dengan inti 2.4.0)
Serial dengan paket besar juga diperbaiki ...
Pada titik tertentu kita harus melakukan transisi ke inti baru. Kembali ke 2.3.0 berarti hanya untuk menunda masalah. Pada akhirnya kita harus tetap melakukan pekerjaan itu. ESP saya pasti lebih baik dengan 2.4.0

Seperti yang saya lihat, inti 2_4_x akan terjadi tetapi mungkin tidak diperlukan untuk saat ini. Kami melakukan keputusan yang buruk ketika kami melanjutkan dengan pembaruan inti dan pendekatan berbasis acara wifi secara bersamaan. Kita seharusnya membuat mereka satu demi satu. Ketika kami, pada saat yang sama, memiliki pembaruan dalam pengaturan global, masalahnya menjadi sangat sulit untuk ditentukan. Saya sangat mendukung gagasan untuk kembali ke 2_3_0 selama perbaikan stabilitas wifi + perbaikan pengaturan korupsi.

Setelah itu semoga kita bisa merilis v2.1.0 dan kemudian fokus untuk mendapatkan core 2_4_x stabil untuk v2.2.0

Setelah menghapus pengaturan dan mengunggah versi dari 22.04. Sejauh ini semuanya bekerja. Setidaknya untuk saat ini :) Hanya memori bebas tidak cukup, bahkan dalam NORMAL. Kita lihat saja bagaimana kelanjutannya.

Saya harus setuju dengan @Budman1758 dan @melwinek : Saya juga menemukan bahwa mulai dari unit yang bersih tidak ada masalah sama sekali dengan Wifi, IP statis dan pengaturan.
Masalah utamanya adalah kenyataan bahwa untuk memutakhirkan, saya sekarang perlu membersihkan semua unit secara manual, mem-flash ulang, dan membangun kembali konfigurasinya.

Saya kira kita tidak boleh lupa bahwa secara resmi kita masih dalam proses beralih dari stable R120 ke stable 2.1.0 dan pengaturan tidak akan diubah di antara kedua rilis ini sehingga Anda tetap harus memulai dari awal. Apa yang kami lakukan dengan pembaruan inti 2_4_x adalah membuat "titik istirahat" lagi. Jika kita bisa hidup dengan itu maka itu tidak masalah. Saya setuju bahwa instalasi bersih benar-benar stabil (setidaknya pada NORMAL, yang paling sering saya uji). Dan NORMAL adalah satu-satunya bagian yang benar-benar akan di rilis, tes dan dev hanya dalam rilis malam pengembangan pula.

Maksud saya adalah: jika firmware yang dikembangkan saat ini berfungsi dan stabil pada pengaturan yang bersih, maka itu berarti tidak ada yang salah dengan itu. Saya tidak akan kembali ke 2,3 atau wifi lama.

Ya, saya mendengar Anda dan saya agak setuju. Satu-satunya hal adalah kita membuat break point lain yang menurut saya tidak masalah karena masih beta.

Meskipun ini adalah langkah mundur yang tidak saya sukai, saya khawatir akan lebih baik untuk kembali ke inti 2_3_0 untuk saat ini karena saya pikir beberapa masalah aneh mungkin terjadi karena kurangnya memori kosong pada 2_4_0.

@giig1967g Saya setuju dengan Anda di sana. Saya percaya ada beberapa masalah korupsi yang terjadi. Mungkin apa yang mengacaukan wifi vs memiliki banyak masalah bawaan.

Masih ada opsi untuk mendapatkan penggunaan memori ke titik yang dapat diterima.
Saya pikir saya bisa mendapatkan sekitar 3 - 4 kB lebih banyak memori dalam 1 malam pemrograman. (perlu mengubah semua file plugin)
Dan impor MQTT juga merupakan sesuatu yang sangat menyebalkan yang harus segera diselesaikan.
Dan plugin Switch memang memiliki terlalu banyak fungsi itu sendiri yang harus dipisah.

Saya akan memikirkannya hari ini, apa yang harus kita lakukan, jadi silakan tambahkan lebih banyak saran/argumen :)

@TD-er Anda benar dengan SWITCH.
Kebanyakan orang hanya menggunakan ON / OFF untuk sakelar / relai.
Dan di plugin ini ada servo, dimmer dan mungkin sesuatu.
Itu bisa terpisah.

Itu juga menangani hal-hal yang sangat spesifik untuk MQTT dan/atau Domoticz. Itu seharusnya tidak menjadi bagian dari plugin.

@TD-er Dalam banyak kasus, itu akan membantu saya untuk mengkompilasi sendiri, setelah menghapus plugin yang tidak perlu, dalam banyak kasus saya hanya perlu SWITCH, FHEM Controller, DHT.
Tapi setelah petualangan ini dengan pengaturan saya takut untuk mengkompilasi sendiri. Terutama setelah posting Anda: https://github.com/letscontrolit/ESPEasy/issues/1292

Apakah Anda melihat, bagaimana wifi diwujudkan di proyek lain (misalnya tasmota)?

Tentang memori: saya bilang :senyum:
Saya pikir ada terlalu banyak fitur yang jarang digunakan di inti - keputusannya, jika permintaan fitur inti diterapkan harus jauh lebih ketat - sekarang ini sedikit seperti Natal untuk semua orang ...
Mungkin pemungutan suara dengan batas tertentu akan membantu.

Jika memungkinkan, inti harus dibersihkan terlebih dahulu dari fitur yang jarang digunakan (atau diubah menjadi plugin) dan kemudian dioptimalkan. Juga, orang dapat memikirkan antarmuka tambahan untuk plugin, untuk memungkinkan pertukaran lebih banyak fungsi di luar inti.

@M0ebiu5 Setuju.
Apa yang seharusnya terjadi adalah bahwa fitur-fitur baru akan dikembangkan pada cabang yang terpisah, kemudian mengumpulkan beberapa di antaranya dan menggabungkannya ke cabang kandidat rilis dan mengujinya.
Kemudian lepaskan dan gabungkan fitur yang digunakan ke cabang master (atau cabang dev, atau apa pun namanya).

Dan satu hal yang saya pelajari adalah bertanya dua kali tentang apa yang diamati, apa yang harus diamati dan versi apa yang digunakan. Itu akan membuat segalanya lebih jelas dan menyebabkan lebih sedikit kesalahan.
Bagian dari itu harus dilakukan dalam kode itu sendiri untuk membuat semacam jejak agar dapat melihat (dan mencatat) perangkat lunak apa yang digunakan.

Juga plugin seharusnya hanya plugin untuk menghubungkan sensor ke beberapa nilai output.
Mungkin plugin yang menghasilkan output (seperti tampilan) tidak boleh digunakan sama dengan input.
Jadi kita mendapatkan sesuatu seperti:

  • Sensor untuk membaca perangkat dan menghasilkan pengukuran
  • Output (display?) untuk menyajikan nilai. Ini juga bisa menjadi sesuatu selain tampilan, misalnya JSON atau gambar.
  • Controller untuk interface ke dunia luar (input dan output)
  • Aturan untuk memproses data dan peristiwa.
  • Pemberitahuan untuk mengonversi acara menjadi sesuatu yang lain. Sebenarnya kedengarannya seperti pengontrol yang lebih rumit.
  • Perintah untuk melakukan beberapa pengaturan dasar atau perubahan/pembaruan sementara (tidak persisten) dan melakukan beberapa tindakan (misalnya reboot)
  • Halaman web untuk mengkonfigurasi semuanya.

Tetapi desain ulang seperti itu akan membutuhkan banyak usaha.

@TD-er Anda benar, tetapi saya akan membuat perubahan dalam langkah-langkah kecil - karena sebagian besar bekerja dengan stabil dan perubahan besar dapat membahayakan stabilitas ini.

Antarmuka baru ke inti adalah salah satu cara yang mungkin. Mereka tidak akan memengaruhi perilaku saat ini dan hanya plugin baru atau yang banyak diubah yang akan menggunakannya. Dibutuhkan lebih banyak waktu untuk berubah menjadi arsitektur yang bersih, tetapi dengan risiko yang lebih rendah dan upaya juga akan tersebar seiring waktu.

Saya setuju bahwa perubahan ini harus dilakukan dengan santai.
Ini lebih merupakan pandangan tentang desain ulang untuk masa depan.

Namun, simpul dari 22,04 telah kehilangan koneksi.
Menyetel ulang router tidak membantu.
Reset ESP akan membantu, tetapi saya jauh.
Jadi, versi terbaik di node saya adalah mega-20180410.
Mungkin karena itu pada inti 2.3?
Namun, mungkin solusi yang baik adalah kembali ke 2.3 untuk beberapa waktu?

Tidak, tadi malam saya melihat masalahnya (dalam kode dan terjadi di unit saya sendiri).
Node saya tidak terhubung kembali ketika mereka mendapatkan kesalahan 'batas waktu suar', yang merupakan alasan umum untuk memutuskan sambungan. Ini adalah kesalahan logika dalam kode, tetapi sudah lewat pukul 1:30 pagi dan saya tidak ingin memperbaikinya saat itu. Pasti sudah melewati waktu build malam untuk memperbaikinya, jadi itu tidak masalah lagi;)

terkait: #1064

Saya baru saja mem-flash 6 perangkat dengan versi saat ini ESP_Easy_mega-20180425_test_ESP8266_4096.bin.

Saya pikir dengan versi ini kami telah mencapai titik terendah mutlak.
Semua perangkat tidak dapat dijangkau dalam jaringan setelah beberapa jam.

Itu sebabnya saya akan -dengan satu atau lain cara- kembali ke versi wifi yang berfungsi.

Mungkin kita juga harus menghapus build hari ini, hanya untuk mencegah orang lain memuat yang sama.

Saya akan menyarankan untuk membangun sekarang versi baru 04.25 pada inti 2.3.0 dan mengganti yang sekarang :)

Saya tidak memiliki kendali atas server build.
dan 2 versi dengan nomor build yang sama bukanlah ide yang bagus.

Saya tahu @Grovkillen dapat menghapus build.

Anda pikir saya harus menghapusnya @TD-er ? Yang baru akan dibangun besok.

Rupanya itu bahkan lebih buruk dibandingkan dengan build kemarin.
Jadi ya, hapus.

Selesai

Dan platformio.ini juga berubah.
Jadi apapun yang terjadi, build besok tidak akan seburuk hari ini.

Aku merasakan kepanikan di sekitar sini. Jangan khawatir, masih ada harapan.
Pertama, mari kita minum :beer: atau :beers: Sekarang,
terima kasih @TD-er untuk menyerbu ke depan dengan gelisah terlepas dari kekhawatiran Anda, terima kasih @Grovkillen karena mendukungnya. Terima kasih untuk semua orang lain juga. Dan terima kasih kepada semua orang karena telah mendiskusikan ide-ide baru secara terbuka.

Karena itu, izinkan saya mengatakan ini:

  1. Menurut pengalaman saya, tidak ada yang salah dengan versi inti yang lebih baru kecuali untuk 2.4.1 yang memiliki kebocoran memori wificlient (dan solusinya).
  2. Versi lama dari cabang master sampai pada titik ketika ada keputusan untuk meninggalkan 2.0 bekerja cukup stabil dengan versi inti tersebut. Dan cepat.
  3. Kita benar-benar harus (penekanan pada benar-benar !) fokus pada stabilitas. Tidak ada fitur baru untuk sementara waktu (kecuali untuk meningkatkan stabilitas) ESP32 lebih sedikit dan perburuan memori lebih sedikit, kurang mempercepat segalanya kecuali stabilitas. Anggap saja kita berencana terbang ke bulan. Nyata. Hal itu perlu dioperasikan. Itu perlu mentolerir kegagalan bit tunggal, restart, fluktuasi daya dan tekanan suhu.
    Maksud saya pemrograman toleran gagal. Selesai. Ini bisa menyenangkan jika Anda membungkus pikiran Anda di sekitarnya.

Apa berikutnya ? Jika saya adalah pengembang inti, saya akan memilih konfigurasi berbasis json itu. Secepat mungkin. Sepertinya akar kejahatan saat ini seperti server web intensif memori beberapa waktu lalu.

Aku merasakan kepanikan di sekitar sini. Jangan khawatir, masih ada harapan.
Pertama, mari kita atau Sekarang,
terima kasih @TD-er untuk menyerbu ke depan dengan gelisah terlepas dari kekhawatiran Anda, terima kasih @Grovkillen karena mendukungnya. Terima kasih untuk semua orang lain juga. Dan terima kasih kepada semua orang karena telah mendiskusikan ide-ide baru secara terbuka.

100% setuju!!!

Saya tidak tahu apakah kesalahan ini sudah diketahui:
Setelah satu atau dua hari, tampaknya server web tidak berfungsi lagi. Penerbitan MQTT masih berfungsi.
Saya menggunakan versi normal dari 04.22.

@TD-er secara pribadi saya akan memilih sesuatu yang baru seperti 2.4.1 untuk dicoba.

1+

1+

Aku merasakan kepanikan di sekitar sini. Jangan khawatir, masih ada harapan.

Ini bukan panik, ini murni frustrasi ;)
Masalahnya adalah saya benar-benar menguji hal-hal di sini dan dalam beberapa menit (setidaknya memang terasa seperti itu) build gagal lebih buruk dari sebelumnya.
Saya terbiasa memprogram melawan kotak hitam, dan juga rev. merekayasa kotak hitam itu.
Tapi ini terasa seperti umpan balik yang menurut saya lihat di log benar-benar berbeda dari kenyataan.
Sekarang jelas ada beberapa masalah beberapa minggu terakhir, karena bug di perpustakaan inti, pengaturan yang rusak dan beberapa perubahan yang saya buat tampaknya terkait dengan beberapa bug di firmware AP.

Dan pendapat pribadi saya tentang perangkat lunak adalah bahwa itu harus stabil dan kecepatan berada di urutan kedua.
Tapi minggu lalu peningkatan kecepatannya OK, tapi stabilitasnya memburuk dari hari ke hari, apa pun yang saya coba.

Jadi sekarang sudah waktunya untuk berhenti dan fokus pada stabilitas terlebih dahulu. Anda bisa menyebutnya 'panik', tetapi sebenarnya ini adalah semacam langkah mundur untuk benar-benar fokus pada apa yang sedang terjadi.
Saya sekarang tahu lebih banyak tentang wifi daripada sebulan yang lalu, jadi saya harus bisa membuat paket yang dirancang dengan baik. Tapi itu membutuhkan waktu dan saya benar-benar ingin mencapai titik stabilitas dan mendapatkan beberapa momen kemudahan di kepala saya untuk membuatnya bekerja seperti seharusnya.
Dan masih ada banyak ruang untuk membuat barang lebih cepat, karena saya telah melihat ik terhubung lebih cepat :)
Tapi itu untuk versi selanjutnya.

Tentang sisa masalah utama:

  • penggunaan memori
  • Impor/ekspor pengaturan JSON
  • Desain ulang impor MQTT
  • beberapa plugin seperti P001-switch harus diubah.
  • Apa yang tersisa.

bagi saya (dan mungkin hanya untuk saya) pindah ke 2.4.1 atau bahkan GIT Core tidak membaik, sebaliknya yang terjadi. Saya mencoba sekitar 20 kombinasi berbeda dari versi inti, mage-commits, dan versi lwIP. Kembali ke 2.3.0 terutama lwIP 1.4 adalah satu-satunya cara untuk membuatnya berjalan stabil. Tetapi sekali lagi, hanya pandangan saya tentang ini di lingkungan khusus saya ...

Dan ya, terima kasih banyak @TD-er dan @Grovkillen atas pekerjaan hebat yang mereka lakukan dan waktu yang mereka investasikan untuk komunitas!

Terima kasih semuanya, @TD-er merangkum jalan ke depan dengan cukup bagus.

Tentang sisa masalah utama:
• penggunaan memori
• Impor/ekspor setelan JSON
• Desain ulang impor MQTT
• beberapa plugin seperti P001-switch harus diubah.
• Apa yang tersisa.

Dan kami akan kembali ke 2.3.0 untuk rilis besok dan mengujinya untuk sementara waktu.

Sebagian besar gambar pembuatan diri saya didasarkan pada core rev. 491c9b8b (2.4.1 + x).
Satu-satunya hal yang saya lihat adalah reboot acak dengan perangkat Sonof 4ch saya. Sayangnya itu bagian dari kontrol kolam saya, jadi tidak ada kesempatan untuk menghubungkan antarmuka serial untuk pemantauan yang lebih baik, Syslog sangat tidak dapat digunakan, karena info yang relevan dimuntahkan sebelum WIFI aktif dan berjalan.

Ini cukup berguna - selama Anda menggunakan perpustakaan lwIP 'v2 Higher Bandwith'.
Jika tidak, Anda akan melihat masalah dengan fragmentasi MTU dengan paket > 512Bytes (rusak, dengan informasi jendela yang tidak tepat).

Revs ESPEasy yang berfungsi (repos saya) adalah

komit 3576619181926b3adff5a1a133390eb71e808ae9
Gabungkan: 9038bd2 d083a58
Pengarang: Susis Strolch
Tanggal: Jum 13 Apr 17:07:30 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180413
  [wifi] Event based wifi, fix set AP and crash on start

dan
komit daf39a064d3633fe1eccfa33576fafbccd7611a7
Gabungkan: 2a96218 806a275
Pengarang: Susis Strolch
Tanggal: Sen 9 Apr 09:15:52 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180409
  Both reset/factoryreset option
  Factory Reset (not enabled yet)

Setiap ESPEasy setelah Jum 13 Apr menunjukkan hasil yang mengerikan - berbicara tidak berfungsi -, bahkan ketika menghapus seluruh flash sebelum mem-flash biner (melalui Arduino IDE).

Jadi, saya sarankan untuk menggunakan 2.4.1 (atau lebih baru) dan memoles ESPEasy (WIFI dan konfigurasi).
Core itu sendiri tampaknya baik-baik saja sejauh ini.

lol @Friday the 13th, hari yang sial memang..
Jadi apa itu "polish ESPEasy (WIFI dan config)." ?
Cabang yang berbeda..?
Polandia alias Polandia atau semir seperti dalam buff & shine, ha

@susisstrolch Bagaimana cara menangkap kesalahan seperti ini?
"masalah dengan fragmentasi MTU dengan paket> 512Bytes (rusak, dengan informasi jendela yang tidak tepat)."

Cukup kirimkan permintaan yang sudah disiapkan untuk server web espeasy, dengan header tambahan dengan minimal 512 karakter

@Oxyandy : menjalankan tcpdump di server FHEM saya dan menganalisis dengan WireShark, saya menemukan bahwa 512 byte terakhir dari respons JSON ~700 Byte dikirim terlebih dahulu, diikuti oleh header HTTP.
Dan kedua paket itu kehilangan informasi jendela TCP.
Bisa kirim lebih detail sesuai permintaan...
poles seperti pada buff & shine

Bagi saya, versi 22.04.2018 dengan Core 2.4.1 berjalan cukup baik.
sysinfo

Bisakah Anda juga memeriksa pekerjaan saya kemarin, tetapi kemudian dibangun di atas 2.4.1?
https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability

Di 2.3.0 saya masih memiliki masalah dengan IP statis.
Belum menguji mode AP dengan halaman pengaturan.

Saya baru saja menginstal wemos dengan versi Anda
[wifi] Cobalah untuk membuat wifi berbasis acara lebih sederhana).

vesi berjalan.....

Apa yang harus saya lakukan sekarang?

Sial, dari Tes terakhir saya (22.04.1018) 4 dari 8 perangkat ditutup setelah sekitar 7 jam.

Saya kira tidak ada log? :(
Apakah node macet (hang) atau tidak terhubung kembali?
Apakah mereka membalas ping, dan dengan demikian hanya server web yang dinonaktifkan atau terlalu sibuk (koneksi ulang MQTT membutuhkan banyak sumber daya)?

Sementara itu hang 5 perangkat.
Saya tidak punya log. Server web tidak dapat diakses. Ping juga tidak berfungsi.

mereka baru saja mati.

Anda harus benar-benar mencoba untuk mencatatnya. Ini mungkin memberi kita beberapa petunjuk yang berguna

Saya mencatat versi Gijs. Sudah berjalan selama 55 menit sekarang. :)

oh, aku bisa mengalahkan itu! Saya memiliki 12 perangkat yang berjalan antara 45 dan 263Min pada versi Gijs (dengan inti esp dari GIT) dan semuanya masih senang ...

Ya, zaman telah berubah.
Di masa lalu, perangkat saya berjalan selama berminggu-minggu.

Hari ini saya senang ketika mereka bekerja beberapa jam. :)

Salah satu perangkat saya di rumah, masih menjalankan build yang saya buat pada 20171231 dan melewati waktu aktif 60 hari hari ini.

jadi aku tau maksud kamu :(

Kalau begitu kita ambil saja yang rilis 2017123, baru kita bisa fokus ke hal lain. :)

Waktu Setempat: | 2018-04-26 17:47:23
Waktu beroperasi: | 0 hari 2 jam 27 menit
Muat: | 10% (LC=9371)
Mem Gratis: | 10336 (9544 - sendContentBlocking)
IP: | 192.168.0.201
Wifi RSSI: | -67 dB

Hei, mengapa tidak mengambil versi 60 hari itu, beri tag dengan 2.0 dan tulis beberapa poin penting tentang masalah yang diketahui (bukan fitur yang hilang)

@ s0170071 apakah kita benar-benar membutuhkan 75% produk yang berfungsi, dan banyak masalah terisi setelah rilis?

Mungkin tidak perlu kembali sejauh ini... Ini dari reboot manual terbaru:

Uptime: 21 hari 3 jam 32 menit
Beban: 32% (LC=6281)
Mem Gratis: 14328 (13392 - parseTemplate3)

Bangun | 10000 - Mega (inti 2_3_0)
versi GIT | mega-20180308
Plugin | 72 [Normal] [Pengujian] [Pengembangan]
Bangun Md5 | eb5a94ae675cb343cc387319fd8c4f9a
Cek Md5 | lulus.
Waktu pembuatan | 8 Maret 2018 03:05:36
Nama file biner | firmware.bin

6 perangkat telah berjalan selama 5 jam - rekor baru.

Itu sudah lebih dari 30 jam ;)

Saya sekarang memiliki hampir semua (12+) perangkat yang berjalan pada perubahan @TD-er dari tonigt. Semua Wemos D1 Mini dengan berbagai sensor dan relay terpasang (semua berbeda). Sebagian besar dari mereka sekarang memiliki waktu aktif lebih dari 10 jam. Saya akan mem-flash yang terakhir juga sekarang.
Saya memang memiliki dua atau tiga reboot spontan dari satu atau dua perangkat tetapi ini juga bisa dari plugin atau sensor yang salah (saya juga menggunakan beberapa plugin devel dan bahkan mengubah konfigurasi untuk mendukung 24tugas dan menggunakan inti esp GIT, beberapa bahkan tanpa menghapus konfigurasi terlebih dahulu). Tapi mereka selalu kembali dan terhubung ke jaringan dengan sukses!

Jadi bagi saya ini adalah versi paling stabil yang saya miliki sampai sekarang. mirip dengan apa yang saya miliki sebelum 2.4.0 core.

Oleh karena itu saya akan memilih untuk menggabungkan perubahan @TD-er mulai malam ini untuk mengujinya dan melanjutkan dari sana ... Tapi itu hanya MHO ...

Dan terima kasih kepada @TD-er untuk perbaikan bug cepat (coba)!! Bagi saya itu berhasil!!

Saya juga melakukan reboot pada satu perangkat, tetapi segera terhubung kembali.
Semua Perangkat Wemos D1 mini.

Saya telah menjalankan versi uji di sini dengan 71 plugin.
Pada perangkat hampir hanya BME280, Pir, MH-Z19 dan sensor debu dan beberapa Led.

Server web bereaksi sangat cepat.
Saat ini saya sangat puas dengan versi ini dan Core 2.4.1.

Mungkin sudah diketahui (jika demikian, abaikan saja)
Saya telah menginstal ESP pro mini dengan ESP_Easy_mega-20180422_normal_ESP8266_4096.bin (core 2.4.0).
Ini berjalan sejak 3 hari!
GUI tidak dapat dijangkau lagi, hanya setelah cold start. (testet dengan esp lain)
Ping ok, penerbitan mqtt juga berfungsi, peralihan GPIO melalui http juga berfungsi.
Masalah "satu-satunya", gui tidak dapat dijangkau.
Dengan kata lain, ESP bekerja buta, semuanya baik-baik saja, hanya GUI yang tidak merespons.
Setelah mengetik ip di browser, dapatkan:

ily: sans-serif; ukuran font: 12pt; margin: 0 piksel; bantalan: 0px; ukuran kotak: kotak perbatasan; }h1 {ukuran font: 16pt; warna: #07D; margin: 8 piksel 0; font-weig190 ; warna: #07D; }.button {margin: 4px; bantalan: 4px 16px; warna latar: #07D; warna: #FFF; dekorasi teks: tidak ada; batas-radius: 4px; perbatasan: 190 190 asli; kursor: penunjuk; ukuran font: 12pt; -webkit-pengguna-pilih: tidak ada; -moz-pengguna-pilih: tidak ada; -ms-u

Saya telah mengaktifkan logging dengan perangkat kedua saya setelah reboot dingin, setelah perangkat menjadi tidak responsif, saya akan melaporkan log di sini, jika diinginkan.

Bisakah Anda juga mencatat penggunaan memori? Hanya untuk melihat apakah ada kebocoran memori di 2.4.1 seperti yang dilaporkan oleh beberapa orang.

Ya, sama persis dengan yang saya miliki dengan versi dari 22.04.2018.
Perangkat berjalan tetapi server web tidak dapat dijangkau.

Saya akan mencoba untuk mencatatnya.
Tampaknya konstan.

Mem Gratis: | 9792 (9008 - sendContentBlocking)

Apakah yang Anda maksud: sysheap

unbenannt

@ uzi18 Anda tidak dapat memiliki keduanya, canggih dan stabilitas. Versi 60 hari stabil, kan?

@TD-er Jika Anda membiarkan jendela Aturan terbuka selama beberapa menit, semua aturan akan hilang.

Itu dengan 2.3.0?

Saya punya 2.4.1

Hai,
Saya menguji 20180426. Berfungsi tetapi sangat lambat dibandingkan dengan 20180424.
Bagi saya inti 2.4.0 bekerja dengan sangat baik dan stabil.
Dengan versi baru, MQTT membutuhkan waktu lebih dari 1 menit untuk terhubung sementara versi sebelumnya adalah separuh waktu.
Apakah saya hanya beruntung dengan inti 2.4.0? Atau itu hanya masalah konfigurasi?

Saya menemukan versi @TD-er dari kemarin dengan Core 2.4.1 sangat cepat.

Setelah menyalakan voltase, hanya perlu beberapa detik untuk mencapai antarmuka web.
Pesan MQTT segera datang.

hanya untuk yang berminat. Saya melacak CPU, Memori, dan RSSI. Terlampir grafik dari semua unit. Anda dapat melihat dengan jelas pada penggunaan memori, ketika saya melakukan upgrade ke inti 2.4.x. Namun, memori tampaknya stabil (mis. tidak ada kebocoran)...
Perangkat 1-11 & 16 "sedang digunakan" dengan sensor dll. yang lain hanya D1 biasa tanpa ada yang terpasang.

image

Hai @micropet : bagaimana saya bisa menggunakan versi kemarin dengan core 2.4.1?

Saya mulai berpikir bahwa mungkin Wemos lebih stabil daripada SONOS?
Saya juga menggunakan Wemos

Dengan:
https://github.com/TD-er/ESPEasy/commits/bugfix/wifi_stability
dan di platformio:
[inti_2_4_1]
platform = [email protected]

@micropet dan @TD-er : Saya baru saja mengkompilasi cabang stabilitas wifi dengan inti 2.4.1.
WOW. Cepat luar biasa.
Akan membiarkannya berjalan selama 3 hari ke depan dan melaporkan kembali. Ini berisi aturan yang cukup rumit ...
Untuk saat ini: 7 detik untuk terhubung ke MQTT dibandingkan dengan 60 dengan versi 2.3.0 20180426.

Saya melihat beberapa koneksi ulang di MQTT Import.

104 : INIT : Free RAM:20040
104 : INIT : I2C
104 : INIT : SPI not enabled
1213 : INFO : Plugins: 72 [Normal] [Testing] [Development] (ESP82xx Core 2_4_1)
1214 : EVENT: System#Wake
1289 : WIFI : Set WiFi to STA
mode : sta(60:01:94:8e:ba:c9)
                             add if0
                                    1292 : WIFI : Connecting KeepOut attempt #0
1293 : IP   : Static IP : 192.168.1.206 GW: 192.168.1.1 SN: 255.255.255.0 DNS: 8.8.8.8
1405 : EVENT: System#Boot
1412 : ACT  : gpio,14,1
1414 : SW   : GPIO 14 Set to 1
1416 : ACT  : gpio,12,1
1417 : SW   : GPIO 12 Set to 1
1420 : ACT  : gpio,13,1
1420 : SW   : GPIO 13 Set to 1
1422 : ACT  :
1431 : ACT  : taskvalueset 1,1,1
1441 : ACT  : taskvalueset 1,2,1
1453 : ACT  : taskvalueset 1,3,1
1465 : ACT  : taskvalueset 1,4,1
1474 : ACT  :
1482 : ACT  :
1489 : ACT  : timerset,4,60
1568 : WD   : Uptime 0 ConnectFailures 0 FreeMem 18616
1682 : Dummy: value 1: 1.00
1683 : Dummy: value 2: 1.00
1683 : Dummy: value 3: 1.00
1683 : Dummy: value 4: 1.00
1684 : EVENT: Relay1#r1=1.00
1753 : EVENT: Relay1#r2=1.00
1824 : EVENT: Relay1#r3=1.00
1890 : EVENT: Relay1#r4=1.00
2251 : SYS  : 0.00
2253 : EVENT: SysInfoUptime#UptimeDays=0.00
3188 : IMPT : MQTT 037 Intentional reconnect
3562 : IMPT : MQTT 037 Intentional reconnect
scandone
        state: 0 -> 2 (b0)
                          5130 : Dummy: value 1: 25.80
5130 : Dummy: value 2: 27.20
5130 : Dummy: value 3: 27.40
5130 : Dummy: value 4: 0.00
5131 : EVENT: temp#t1=25.80
state: 2 -> 3 (0)
                 5158 : ACT  : timerset,1,2
state: 3 -> 5 (10)
                  add 0
                       aid 5
                            cnt
                                5174 : ACT  : lcd,1,20,*

connected with KeepOut, channel 9
                                 ip:192.168.1.206,mask:255.255.255.0,gw:192.168.1.1
   5239 : EVENT: temp#t2=27.20
5266 : ACT  : timerset,2,3
5276 : ACT  : lcd,1,20,*
5335 : EVENT: temp#t3=27.40
5365 : ACT  : timerset,3,4
5375 : ACT  : lcd,1,20,*
5428 : EVENT: temp#t4=0.00
5503 : Dummy: value 1: 18.00
5504 : Dummy: value 2: 11.00
5504 : Dummy: value 3: 12.00
5504 : Dummy: value 4: 0.00
5505 : EVENT: local#LSet1=18.00
5575 : EVENT: local#LSet2=11.00
5645 : EVENT: local#LSet3=12.00
5715 : EVENT: local#empty=0.00
6553 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
6554 : EVENT: Time#Initialized
6627 : EVENT: Clock#Time=Thu,22:59
6702 : IMPT : MQTT 037 Intentional reconnect
6964 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
6965 : EVENT: MQTTimport#Connected
6981 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7059 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
7061 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
7062 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
7063 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
7065 : WIFI : Connected! AP: KeepOut (BC:EE:7B:EF:A3:38) Ch: 9 Duration: 3911 ms
7065 : EVENT: WiFi#ChangedAccesspoint
7144 : WIFI : Static IP: 192.168.1.206 (ESPT6-16) GW: 192.168.1.1 SN: 255.255.255.0   duration: 1940 ms
7173 : EVENT: Time#Set
7247 : EVENT: WiFi#Connected
7316 : Webserver: start
7332 : IMPT : MQTT 037 Intentional reconnect
7587 : IMPT : Error subscribing to /OH2/status/nSetTemp1
7588 : EVENT: Rules#Timer=1
ping 1, timeout 0, total payload 32 bytes, 1067 ms
                                                  7648 : [if 0=1]=false
7650 : else = true
7651 : ACT  : timerset,5,6
7688 : EVENT: Rules#Timer=1 Processing time:100 milliSeconds
7690 : MQTT : Intentional reconnect
7704 : MQTT : Connected to broker with client ID: ESPClient_60:01:94:8E:BA:C9
7707 : Subscribed to: /ESPT6/#
7708 : EVENT: MQTT#Connected
7722 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
7813 : EVENT: MQTT#Connected Processing time:105 milliSeconds
7828 : IMPT : [import1#Set1] : 18.00
7828 : EVENT: import1#Set1=18.00
7882 : ACT  : taskvalueset,6,1,18
7893 : ACT  : timerset,1,2
7904 : ACT  : lcd,1,20,*
7955 : EVENT: import1#Set1=18.00 Processing time:127 milliSeconds
8065 : MQTT : Topic: /ESPT6/status/LWT
8065 : MQTT : Payload: Connected
8075 : IMPT : [import1#Set2] : 11.00
8075 : EVENT: import1#Set2=11.00
8131 : ACT  : taskvalueset,6,2,11
8143 : ACT  : timerset,2,3
8152 : ACT  : lcd,1,20,*
8199 : EVENT: import1#Set2=11.00 Processing time:124 milliSeconds
8206 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8207 : MQTT : Payload: 0
8218 : MQTT : Topic: /ESPT6/Relay1/r1
8218 : MQTT : Payload: 0
8219 : MQTT : Topic: /ESPT6/Relay1/r2
8219 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r3
8220 : MQTT : Payload: 1
8220 : MQTT : Topic: /ESPT6/Relay1/r4
8220 : MQTT : Payload: 1
8221 : MQTT : Topic: /ESPT6/SysInfoUptime/UptimeDays
8221 : MQTT : Payload: 0.1
8222 : MQTT : Topic: /ESPT6/status/LWT
8222 : MQTT : Payload: Connected
8223 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
8223 : MQTT : Payload: 0
ping 1, timeout 0, total payload 32 bytes, 1112 ms
                                                  8320 : IMPT : [import1#Set3] : 12.00
8320 : EVENT: import1#Set3=12.00
8376 : ACT  : taskvalueset,6,3,12
8387 : ACT  : timerset,3,4
8396 : ACT  : lcd,1,20,*
8441 : EVENT: import1#Set3=12.00 Processing time:121 milliSeconds
8565 : IMPT : [import1#master] : 0.00
8565 : EVENT: import1#master=0.00
8581 : ACT  : timerset,1,2
8591 : ACT  : timerset,2,3
8600 : ACT  : timerset,3,4
8608 : ACT  : lcd,1,20,*
8684 : EVENT: import1#master=0.00 Processing time:119 milliSeconds
8696 : EVENT: MQTTimport#Disconnected
8774 : EVENT: MQTTimport#Disconnected Processing time:78 milliSeconds
8775 : IMPT : MQTT 037 Connection lost
9712 : IMPT : Connected to MQTT broker with Client ID=ESPT6-Import
9713 : EVENT: MQTTimport#Connected
9725 : ACT  : publish /ESPT6/dummy/requestedTempUpdate,0
9809 : EVENT: MQTTimport#Connected Processing time:96 milliSeconds
9813 : IMPT : [import1#Set1] subscribed to /OH2/status/nSetTemp1
9813 : IMPT : [import1#Set2] subscribed to /OH2/status/nSetTemp2
9814 : IMPT : [import1#Set3] subscribed to /OH2/status/nSetTemp3
9815 : IMPT : [import1#master] subscribed to /OH2/status/nMasterCaldaia
9817 : MQTT : Topic: /ESPT6/dummy/requestedTempUpdate
9817 : MQTT : Payload: 0
9931 : IMPT : [import1#Set1] : 18.00
9931 : EVENT: import1#Set1=18.00
9985 : ACT  : taskvalueset,6,1,18
9996 : ACT  : timerset,1,2
10005 : ACT  : lcd,1,20,*
10053 : EVENT: import1#Set1=18.00 Processing time:122 milliSeconds
10173 : IMPT : [import1#Set2] : 11.00
10174 : EVENT: import1#Set2=11.00
10228 : ACT  : taskvalueset,6,2,11
10239 : ACT  : timerset,2,3
10248 : ACT  : lcd,1,20,*
10295 : EVENT: import1#Set2=11.00 Processing time:121 milliSeconds
10414 : IMPT : [import1#Set3] : 12.00
10414 : EVENT: import1#Set3=12.00
10470 : ACT  : taskvalueset,6,3,12

@giig1967g Adakah kemungkinan Anda bisa membuat file bin yang bisa saya unduh? versi 4meg? Masih belajar proses kompilasi....

@ giig1967g, seperti yang saya katakan - sangat cepat dan juga terlihat stabil.

Saya sekarang memiliki koneksi ulang dalam 7 jam.

@giig1967g Menjalankan IP statis masih memiliki beberapa masalah dengan kode baru saya.
Terutama saat berjalan dengan MQTT.
DHCP tampaknya berfungsi dengan baik.

Besok akan menjadi hari yang sangat sibuk bagi saya, karena ini adalah "Hari Raja" dan keluarga kerajaan akan berada di Groningen. Saya juga diundang ke sana untuk -mungkin- memberi tahu raja tentang masalah kami di sini.
Jadi saya akan tidur sekarang dan saran saya adalah untuk tidak menggabungkan kode hari ini ke cabang utama. Besok kami akan melanjutkan pengembangan dan membuat kode koneksi wifi terbaik :)

ok, saya menemukan masalah pada 20180426 (2.3.0) dan WifistabilityBranch (2.4.1).
Jika saya mematikan router dan menyalakannya kembali, unit tidak terhubung kembali ke Wifi meskipun tertulis di serial "Wifi#Connected". Unit berfungsi (serial dan aturan ok) tetapi tidak ada koneksi WiFi jadi tidak ada antarmuka web.

@ TD-dia, ayo lakukan itu. Salam untuk Raja - mungkin dia punya ide lain. :)
Dan selamat malam.

@TD-er : semoga sukses dengan masalah kehidupan nyata Anda ...

Beberapa di sini, jika saya memutuskan koneksi WIFI selama 0,2 Detik:

29113846 : ACT : timerSet,1,60
29115651 : MQTT : Sambungan terputus
29115652 : ACARA: MQTT#Terputus
29115689 : MQTT : Gagal terhubung ke broker
29115690 : ACARA: WiFi#Terputus
29115706 : WIFI : Terputus! Alasan: '(1) Tidak ditentukan' Terhubung selama 8j04m <-------- !!
29116189 : MQTT : Gagal terhubung ke broker
29116939 : MQTT : Gagal terhubung ke broker
29117860 : WD : Waktu Aktif 485 ConnectFailures 6 FreeMem 16416
29117881 : MQTT : Gagal terhubung ke broker
29117938 : MQTT : Gagal terhubung ke broker
29119189 : MQTT : Gagal terhubung ke broker
29120689 : MQTT : Gagal terhubung ke broker
29120736 : DS : Suhu: 19,94 (28-ff-b8-ea-b4-16-3-ed)
29120738 : ACARA: DS18b20#Temperature=19.94
29122440 : MQTT : Gagal terhubung ke broker
29124440 : MQTT : Gagal terhubung ke broker
29126441 : MQTT : Gagal terhubung ke broker
29128442 : MQTT : Gagal terhubung ke broker

@giig1967g
Anda dapat mencari fungsi untuk memulai/menghentikan server web dan menambahkan return; pada baris pertama dari fungsi tersebut.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Saya kira ada beberapa masalah dengan memanggil fungsi 'gotIP' saat menggunakan IP statis.
Itu juga alasan ketidakstabilan saat menjalankan MQTT + IP statis.

Tapi itu mungkin untuk @ TD-er sepele. :)

Hm, saya tidak melihat melalui.
Saya pikir Anda lebih baik melakukannya besok.
Selain itu, saya bekerja di sini dengan DHCP.

Bagi saya stabilitas dengan perangkat keras saya selalu 'lebih baik' (tidak sempurna) dengan 2.3.0 core build

  • mencoba 2.4.0 & 2.41 -- mereka lebih buruk...

0403 mega normal - sepertinya berfungsi & versi sebelumnya ..
Siapa pun yang masih dengan masalah seperti saya dapat mencoba 0403..
@susisstrolch & @uzi18 - terima kasih atas tanggapan Anda .. Saya memiliki ide yang lebih baik tentang bagaimana saya dapat melihat komunikasi sekarang - adaptor wireshark & ​​usb wifi 2.4g akan berfungsi, saya punya banyak cadangan
Terima kasih

Milik saya berjalan hampir 17 jam sekarang. Koneksi tunggal

perbarui dari unit saya (nama|waktu aktif dalam hitungan menit|disk terakhir. alasan|wifi terhubung dalam ms):
wemos_mini_01_sysinfo | 1220 | 200 | 6462869
wemos_mini_02_sysinfo | 1223 | 1 | 19359544
wemos_mini_03_sysinfo | 657 | 1 | 1018597
wemos_mini_04_sysinfo | 1078 | 201 | 439668
wemos_mini_05_sysinfo | 650 | 6 | 9194816
wemos_mini_06_sysinfo | 927 | 1 | 955432
wemos_mini_07_sysinfo | 1142 | 1 | 14078412
wemos_mini_08_sysinfo | 730 | 1 | 7848454
wemos_mini_09_sysinfo | 1005 | 1 | 5536489
wemos_mini_10_sysinfo | 550 | 201 | 465734
wemos_mini_11_sysinfo | 662 | 4 | 15658520
wemos_mini_12_sysinfo | 1211 | 1 | 17915701
wemos_mini_13_sysinfo | 1211 | 1 | 17896590
wemos_mini_14_sysinfo | 1210 | 1 | 17882406
wemos_mini_15_sysinfo | 753 | 1 | 58904600
wemos_mini_16_sysinfo | 1197 | 1 | 17210855

satu reboot unit 10 (bisa juga terkait dengan plugin). semua unit dengan pengontrol DHCP dan FHEM serta pembaruan status JSON reguler (dipanggil melalui HTTPMOD dari fhem).
server web pada semuanya masih berjalan dan sangat responsif. tidak pernah menggunakan ip-statis atau halaman pengaturan.

jadi bagi saya ini sepertinya versi yang agak stabil.

karena saya kebanyakan offline 4 hari ke depan, saya akan melihat minggu depan berapa banyak yang masih hidup

Oh, dan salam untuk raja! saya harap dia juga menyukai IoT

@kikuk-stefan versi ini? https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability
dan inti apa?
Sudahkah Anda mencoba me-restart router?

@melwinek git commit: d582cab938f041f622f2d4d8016b3d4bada55580 dari cabang master esp8266 (jadi komit terbaru pada cabang master dari pengembangan inti).

@kikuk-stefan inti 2.3.0, 2.4.0 atau 2.4.1 ?

komit GIT terbaru! (jadi Anggap itu inti 2.4.1+)

Saya tidak dapat menemukan komit ini.
Terbaru adalah: https://github.com/letscontrolit/ESPEasy/commit/d780f1a07fdcd4eec394a0677866c2a9778eb696
Dapatkah Anda menyediakan sebuah sambungan?

@kikuk-stefan Saya mengerti, Anda menulis git ke intinya.
Komit ESPEasy mana yang Anda kompilasi?

ESPEasy komit f9be283 dari https://github.com/TD-er/ESPEasy/tree/bugfix/wifi_stability cabang
esp8266 komit d582cab dari https://github.com/esp8266/Arduino

@TD-er:

@giig1967g
Anda dapat mencari fungsi untuk memulai/menghentikan server web dan menambahkan pengembalian; pada baris pertama dari fungsi tersebut.
https://github.com/TD-er/ESPEasy/blob/f9be283cb70043733fdc45575457a85244660ea8/src/WebServer.ino#L570 -L585

Saya kira ada beberapa masalah dengan memanggil fungsi 'gotIP' saat menggunakan IP statis.
Itu juga alasan ketidakstabilan saat menjalankan MQTT + IP statis.

Hai, masalahnya bukan pada server webnya, itu adalah unit yang tampaknya terhubung ke Wifi tetapi tidak. Tidak dapat melakukan ping, tidak dapat mengirim MQTT, dll.

Github terbaru berjalan dengan sempurna di sini pada inti 2.4.1. Tidak ada masalah koneksi, tidak ada kebocoran anggota

@mvdbro Apakah Anda menggunakan perangkat esp32 atau esp8266?

Saya menggunakan ESP8266 dan ESP32. Keduanya bekerja dengan baik.

Catatan samping:
Selalu menggunakan IP statis
Hanya menggunakan plugin yang saya butuhkan (menjaga RAM pada minimum yang aman. Saya pikir set default memiliki banyak plugin yang dimuat)

Besar! :senyum:
Saya mencoba core 2.4.1 di esp8266 saya juga.
Statis dan dhcp berfungsi.
dnsserver dan captive portal berfungsi.
ntp bekerja!

@Feuerreiter : apakah Anda mencoba mematikan dan menghidupkan router untuk melihat apakah unit terhubung kembali?
Dalam kasus saya, log mengatakan bahwa itu terhubung kembali tetapi tidak.

@giig1967g Saya akan mencobanya nanti di rumah. Saya telah melakukan tes di mobil saya dengan ponsel saya sebagai hotspot. ;-)

@mvdbro

Saya pikir set default harus memuat banyak plugin

Saya setuju. Harus ada beberapa pemilihan awal pada plugin, atau mungkin pemeriksaan yang lebih baik pada semuanya untuk tidak menggunakan lebih banyak memori daripada yang benar-benar dibutuhkan saat tidak digunakan.
Dan ada banyak memori yang didapat ketika melihat secara dekat struct besar yang berisi informasi tentang plugin yang tersedia.

[PlatformIO] Inti yang diperbarui ke 2.4.1
1+

Saya pikir itu keputusan yang bagus.
Saya tidak punya masalah sejak kemarin sore.

Seperti yang saya posting di utas lain:
Bagi mereka yang membutuhkan sedikit bantuan dalam membangun, saya baru saja membuat versi tambalan yang saya tulis 2 hari yang lalu, tetapi sekarang dengan inti 2.4.1:
TD-er_wifi_stability_core-2.4.1

Memori tetap cukup konstan.
Itu tenggelam sedikit dalam 15 menit pertama.
(Mereka tidak terlihat di sini)
19:05:33 ESP-206/SYSHEAP 11536
19:08:34 ESP-206/SYSHEAP 11536
19:11:36 ESP-206/SYSHEAP 11536
19:14:37 ESP-206/SYSHEAP 11536
19:17:40 ESP-206/SYSHEAP 11536
19:20:42 ESP-206/SYSHEAP 11536
19:23:45 ESP-206/SYSHEAP 11536
19:26:47 ESP-206/SYSHEAP 11536
19:29:50 ESP-206/SYSHEAP 11536
19:32:52 ESP-206/SYSHEAP 11536
19:35:54 ESP-206/SYSHEAP 11536
19:38:57 ESP-206/SYSHEAP 11536
19:41:59 ESP-206/SYSHEAP 11536
19:45:01 ESP-206/SYSHEAP 11536
19:48:04 ESP-206/SYSHEAP 11536
19:51:06 ESP-206/SYSHEAP 11536
19:54:09 ESP-206/SYSHEAP 11536
19:57:11 ESP-206/SYSHEAP 11536
20:00:13 ESP-206/SYSHEAP 11536
20:03:16 ESP-206/SYSHEAP 11536
20:06:17 ESP-206/SYSHEAP 11536
20:09:29 ESP-206/SYSHEAP 11656
20:12:19 ESP-206/SYSHEAP 11592
20:15:21 ESP-206/SYSHEAP 11592
20:18:23 ESP-206/SYSHEAP 11592
20:21:24 ESP-206/SYSHEAP 11592
20:24:25 ESP-206/SYSHEAP 13192
20:27:27 ESP-206/SYSHEAP 11592
20:30:30 ESP-206/SYSHEAP 11592
20:33:31 ESP-206/SYSHEAP 11592
20:36:34 ESP-206/SYSHEAP 11592
20:39:36 ESP-206/SYSHEAP 11592
20:42:39 ESP-206/SYSHEAP 11592
20:45:40 ESP-206/SYSHEAP 11592
20:48:43 ESP-206/SYSHEAP 11592
20:51:45 ESP-206/SYSHEAP 11592
20:54:48 ESP-206/SYSHEAP 11592
20:57:50 ESP-206/SYSHEAP 11592
21:00:52 ESP-206/SYSHEAP 11592
21:03:54 ESP-206/SYSHEAP 11592
21:06:56 ESP-206/SYSHEAP 11424
21:09:58 ESP-206/SYSHEAP 13024
21:13:01 ESP-206/SYSHEAP 11424
21:16:03 ESP-206/SYSHEAP 13024
21:19:06 ESP-206/SYSHEAP 11424
21:22:08 ESP-206/SYSHEAP 11448
21:25:10 ESP-206/SYSHEAP 11424
21:28:13 ESP-206/SYSHEAP 11424
21:31:15 ESP-206/SYSHEAP 11424
21:34:18 ESP-206/SYSHEAP 11424
21:37:20 ESP-206/SYSHEAP 11424
21:40:22 ESP-206/SYSHEAP 11424
21:43:24 ESP-206/SYSHEAP 11424
21:46:27 ESP-206/SYSHEAP 11424
21:49:28 ESP-206/SYSHEAP 13024
21:52:31 ESP-206/SYSHEAP 11424
21:55:33 ESP-206/SYSHEAP 11424
21:58:36 ESP-206/SYSHEAP 11424
22:01:38 ESP-206/SYSHEAP 11424

Sementara itu, 8 perangkat sudah berjalan sejak siang kemarin.
Tak satu pun dari mereka terjebak.

Salah satunya tidak dapat diakses selama sekitar 15 menit - tiba-tiba ia kembali ke jaringan.
Secara keseluruhan, hasil yang menyenangkan.

Sangat bagus untuk didengar.
Semoga @Oxyandy juga bisa berbagi hasil positif serupa dengan build terbaru yang saya bagikan.
Nodenya adalah yang paling kritis saat menggunakan 2.4.x

@TD-er Pagi, akhirnya menemukan posting ini setelah melakukan pengejaran
0403 menggunakan 2.4.1 berjalan dengan baik sepanjang malam..
Sekarang flashing dari rar terbaru Anda normal 1024 8266
menghubungkan percobaan pertama, memperbarui waktu langsung, tidak ada kesalahan wifi (sejauh ini) & tetap terhubung (sejauh ini),
server web merespons setiap saat..
Perlu sedikit lebih banyak waktu pengujian, tetapi terlihat bagus

Itu terdengar baik :)

Saya akan melihat masalah NTP yang dilaporkan oleh @ giig1967g dan kemudian mendorong kode ini ke repositori ESPeasy.
Mari kita berharap untuk yang terbaik.

Akan sangat bagus jika kita bisa meninggalkan wifi apa adanya dan melanjutkan sisanya.

Berharap Anda dapat menyempurnakan beberapa hal yang saya berikan umpan balik, setelah semuanya kembali stabil.
Saya akan mencoba beberapa tes khusus dengan sumber wifi_stability_core-2.4.1 Anda dari Github
& mungkin perbaikan terhadap masalah lama saya, jika sumber tidak berubah secara radikal

Jika Anda memiliki beberapa perbaikan, silakan bagikan.

@ giig1967g saya telah melakukan pengujian. Pemutusan yang sangat singkat tidak masalah. AP mati dan langsung hidup. mcunode saya terhubung jika AP kembali. PC saya sudah terhubung ke AP lain.

Juga baru mulai menguji dengan D1-Mini dan BME280

ESPEasy: komit 2abec2b0bb74018ea76203886f683761796091a2
Gabungkan: 16d3a9f 29f89b6
Penulis: Susis Strolch
Tanggal: Sab 28 Apr 10:26:14 2018 +0200

Merge remote-tracking branch 'upstream/mega' into mega

* upstream/mega:
  automaticly updated release notes for mega-20180428

Inti: komit 41a64707f149d01ace37c903f448d5e3f1cee5d8
Penulis: Marcel Stör [email protected]
Tanggal: Kam 26 Apr 01:46:17 2018 +0200

Fix WiFi status formatting issue (bullet list) (#4671)

Kustom.h:
`#warning " ** Menggunakan Pengaturan dari File Custom.h * "

jika ditentukan (ESP8266)

// aktifkan pembaruan Arduino OTA.
//Catatan: Ini menambahkan sekitar 10kb ke ukuran firmware, dan ram tambahan 1kb.
// #define FEATURE_ARDUINO_OTA

//mengaktifkan mode mDNS (menambahkan sekitar 6kb ram dan beberapa byte IRAM)
// #define FEATURE_MDNS

berakhir jika

undef PLUGIN_BUILD_NORMAL

undef PLUGIN_BUILD_TESTING

undef PLUGIN_BUILD_DEV

tentukan PLUGIN_BUILD_CUSTOM

undef BUILD_UPLOADER

jika ditentukan(BUILD_UPLOADER)

#warning "**** Building ESP8285 Uploader image ***"

kalau tidak

// tentukan plugin kita sendiri
#define USES_P001 // Beralih
#define USES_P002 // ADC
#define USES_P004 // Dallas
#define USES_P005 // DHT
#define USES_P013 // HCSR04
#define USES_P026 // SysInfo
#define USES_P028 // BME280
#define USES_P033 // Boneka

#define USES_C008   // Generic HTTP
#define USES_C009   // FHEM HTTP
#define USES_C013   // ESPEasy P2P network

berakhir jika

undef BUILD_GIT

definisikan BUILD_GIT "2abec2b"`

Sepertinya ada beberapa masalah dengan NTP:
`
INIT : Versi booting: 2abec2b (ESP82xx Core 41a64707)

80 : INIT : Boot hangat #2

81 : FS : Memasang...

106 : FS : Mount berhasil, menggunakan 76053 byte dari 957314

115 : CRC : Tidak ditemukan checksum memori program. Periksa keluaran crc2.py

144 : CRC : Pengaturan Keamanan CRC ...OK

227 : INIT : RAM Gratis

227 : INIT : I2C

227 : INIT : SPI tidak diaktifkan

232 : INFO : Plugin: 8 (ESP82xx Core 41a64707)

233 : ACARA: Sistem#Bangun

241 : WIFI : Setel WiFi ke STA
242 : WIFI : Upaya menghubungkan SusiconStrolch #0
355 : ACARA: Sistem#Boot
364 : WD : Uptime 0 ConnectFailures 0 FreeMem 31504
3987 : BMx280 : Terdeteksi BME280
5575 : BME280: titik embun 8.03C
5576 : BME280 : Alamat: 0x76
5576 : BME280 : Suhu: 18,49
5576 : BME280 : Kelembaban: 50,75
5576 : BME280 : Tekanan Barometrik: 1010.58
5583 : ACARA: BMx280#Suhu = 18,49
5592 : ACARA: BMx280#Kelembaban=50.75
5597 : ACARA: BMx280#Tekanan=1100.58
5853 : Zona Waktu Saat Ini: Waktu mulai DST: 25-03-2018 02:00:00 offset: 120 mnt Waktu mulai STD: 28-10-2018 03:00:00 offset: 60 mnt
5853 : ACARA: Waktu#Diinisialisasi
5862 : ACARA: Jam#Waktu=Sab,10:52
5866 : ACT : taskvalueset 12,1,0
5872 : ACT : taskvalueset 12,2,-58
5877 : ACT : taskvalueset 12,3.29912
5883 : ACT : taskvalueset 12,4.39164
5888 : WIFI : Terhubung! AP: SusiconStrolch (38:10:D5:B2:22:1E) Bab: 13 Durasi: 3783 ms
5888 : ACARA: WiFi#ChangedAccesspoint
5894 : WIFI : DHCP IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0 durasi: 17 ms
5913 : Zona Waktu Saat Ini: Waktu mulai DST: 2036-03-30 02:00:00 offset: 120 menit Waktu STD mulai: 2036-10-26 03:00:00 offset: 60 menit
5914 : ACARA: Waktu#Set
5921 : ACARA: WiFi#Terhubung
5928 : Server web: mulai
5935 : ACARA: Jam#Waktu=Kamis,07:28
`
5853 : Zona Waktu Saat Ini: Waktu mulai DST: 25-03-2018 02:00:00
5913 : Zona Waktu Saat Ini: Waktu mulai DST: 2036-03-30 02:00:00 offset: 120 menit waktu STD mulai:

Itu adalah kode kesalahan -1 yang diketahui dan masih dikonversi ke bug waktu.

Hmm, saya masih bertanya-tanya bagaimana panggilan ke NTP dapat menghasilkan -1.

@susisstrolch
Itu versi berapa? ESPeasy menggunakan nilai BUILD_GIT untuk menentukan apa yang harus ditambal di file pengaturan dan mungkin juga file lain. Ini adalah semacam versi internal yang digunakan untuk menentukan tambalan yang diperlukan. (jika ada)
ketika Anda mengubah nilai itu, itu dapat menyebabkan hal-hal aneh.

Saya kira itu terkait UDP. Saya tidak melihat perangkat saya yang lain. Dan sebaliknya.

@susisstrolch Itu dengan IP statis, atau dengan DHCP?

Penambalan @TD-er berdasarkan BUILD_GIT adalah ide yang buruk, karena itu berubah pada garpu, cabang, dan komit lokal.
Harus ada beberapa tipe/variabel yang berbeda - mungkin BUILD_FEATURE - yang mengontrol perilaku seperti itu.

Karena saya hampir tidak pernah me-reboot AP saya, tidak disadari bahwa koneksi ulang gagal dengan sumber github terbaru (20180428). Saya mencoba mendapatkan beberapa status internal untuk melihat apa yang terjadi:

Setelah boot:
panggilan ke Wifi.status() : 3 berarti WL_CONNECTED
variabel wifiStatus : 3 berarti ESPEASY_WIFI_SERVICES_INITIALIZED

Setelah reboot AP
panggilan ke Wifi.status() : 3 berarti WL_CONNECTED
variabel wifiStatus : 0 berarti ESPEASY_WIFI_DISCONNECTED

ini tidak berubah seiring waktu dan ESP tidak pernah terhubung kembali

Hanya ingin tahu mengapa panggilan Wifi.status() ke inti masih melaporkan status 3 (WL_CONNECTED)
Apakah ini karena wifi berbasis acara mengganggu status inti internal?

Perilaku sama pada inti 2_3_0 dan 2_4_1

Itu dengan DHCP

Dan saya harapkan setelah reboot normal:

panggilan ke Wifi.status() : 3 berarti WL_CONNECTED
variabel wifiStatus : 1 berarti ESPEASY_WIFI_CONNECTED

dari pada:
panggilan ke Wifi.status() : 3 berarti WL_CONNECTED
variabel wifiStatus : 3 berarti ESPEASY_WIFI_SERVICES_INITIALIZED

Hmm, itu pertanyaan yang bagus @mvdbro
Mungkin status WL_CONNECTED tidak pernah diupdate karena tidak memanggil fungsi untuk mengupdate status tersebut.
Hanya dari memori, saya akan mengatakan bahwa fungsi dipanggil di perpustakaan inti ketika acara "mendapat IP" ditangani.
Saya akan melihat ke area kode perpustakaan inti itu.
Terima kasih telah memperhatikan.

@susisstrolch OK, saya juga akan mencoba dengan DHCP di sini.
Unit pengujian saya dapat melihat satu sama lain melalui komunikasi UDP ESPeasy internal, tetapi mereka saat ini berjalan pada IP statis, karena itu memberikan sebagian besar masalah akhir-akhir ini.

@TD-er tunggu - akan memeriksa apakah itu masalah terkait inti.

@mvdbro
Berikut kodenya:
https://github.com/esp8266/Arduino/blob/836c7da8cc1ad11a66e0be1f30d35a92b5317bcc/libraries/ESP8266WiFi/src/ESP8266WiFiSTA.cpp#L497 -L513

Memang, selama status internal tidak disetel ke 'punya IP', itu tidak akan mengembalikan WL_CONNECTED.

Tentang perbedaan nama variabel antara enum/defines di ESPeasy dan pustaka inti.
Status perpustakaan inti tidak benar-benar mencerminkan keadaan sebenarnya, karena Anda dapat terhubung dan tidak memiliki IP.

Saya mungkin lebih baik menyimpan utas ini hanya untuk masalah koneksi/sambungan kembali Wifi sehingga ini dapat diperbaiki sejak awal.

Saya kira ini adalah kode efektif yang digunakan:

Wifi.status() kode:
WL_IDLE_STATUS 0
WL_NO_SSID_AVAIL 1
WL_SCAN_COMPLETED 2
WL_CONNECTED 3
WL_CONNECT_FAILED 4
WL_CONNECTION_HILANG 5
WL_DISCONNECTED 6

kode status wifi:
ESPEASY_WIFI_DISCONNECTED 0
ESPEASY_WIFI_CONNECTED 1
ESPEASY_WIFI_GOT_IP 2
ESPEASY_WIFI_SERVICES_INITIALIZED 3

Saya kira itu mungkin terkait dengan masalah koneksi / koneksi kembali wifi.
Dengan IP statis, tidak ada acara untuk "mendapatkan IP", sehingga penanganannya saat ini mungkin tidak lengkap, yang menyebabkan beberapa masalah ini.

Jadi Setelah reboot AP
panggilan ke Wifi.status() : 3 berarti WL_CONNECTED
Ini tidak benar.

Jika Wifi.status() tidak berfungsi seperti yang diharapkan, ini akan menjadi bug inti arduino yang serius. Bukankah ini seharusnya dilaporkan pada pelacak masalah github mereka?

@susisstrolch Baru saja mengalami hal yang sama. Memperbarui perangkat terkonfigurasi yang baik dan siap pakai. Tidak menemukan unit lain.

Solusi: periksa entri port UDP. (65500) Milik saya baru saja hilang. Reboot lagi dan berhasil.
Kita harus benar-benar menggunakan konfigurasi berbasis JSON !!!

@mvdbro Saya baru saja menemukan ini, lihat bagian atas halaman 39:
https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
Jadi saya sekarang akan menguji untuk melihat apakah kita harus mengatur konfigurasi IP (lagi) setelah memproses acara koneksi.

Dapatkah seseorang menguji kode dalam PR ini: https://github.com/letscontrolit/ESPEasy/pull/1328

@s0170071 - dikonfirmasi - pengaturan port UDP berubah.

@TD-er tentang #1328:

INIT : Booting version: 62e6317 (ESP82xx Core 41a64707)
75 : INIT : Warm boot #1
76 : FS   : Mounting...
101 : FS   : Mount successful, used 76053 bytes of 957314
111 : CRC  : No program memory checksum found. Check output of crc2.py
142 : CRC  : SecuritySettings CRC   ...OK 
248 : INIT : Free RAM:31624
248 : INIT : I2C
248 : INIT : SPI not enabled
253 : INFO : Plugins: 8 (ESP82xx Core 41a64707)
254 : EVENT: System#Wake
261 : WIFI : Set WiFi to STA
        mode : sta(5c:cf:7f:f1:bb:e1)
        add if0
264 : WIFI : Connecting SusiconStrolch attempt #0
267 : OTA  : Arduino OTA enabled on port 8266
379 : EVENT: System#Boot
390 : WD   : Uptime 0 ConnectFailures 0 FreeMem 30112
        scandone
        state: 0 -> 2 (b0)
4014 : BMx280 : Detected BME280
        state: 2 -> 3 (0)
        state: 3 -> 5 (10)
        add 0
        aid 3
        cnt 
        connected with SusiconStrolch, channel 13
        dhcp client start...
        ip:192.168.254.71,mask:255.255.255.0,gw:192.168.254.1
5602 : BME280: dew point 8.12C
5603 : BME280 : Address: 0x76
5603 : BME280 : Temperature: 20.25
5603 : BME280 : Humidity: 45.75
5603 : BME280 : Barometric Pressure: 1010.14
5611 : EVENT: BMx280#Temperature=20.25
5620 : EVENT: BMx280#Humidity=45.75
5626 : EVENT: BMx280#Pressure=1010.14
5884 : Current Time Zone:  DST time start: 2018-03-25 02:00:00 offset: 120 minSTD time start: 2018-10-28 03:00:00 offset: 60 min
5884 : EVENT: Time#Initialized
5893 : EVENT: Clock#Time=Sat,16:10
5898 : ACT  : taskvalueset 12,1,0
5903 : ACT  : taskvalueset 12,2,-60
5908 : ACT  : taskvalueset 12,3,28376
5914 : ACT  : taskvalueset 12,4,58217
5921 : WIFI : Connected! AP: SusiconStrolch (38:10:D5:B2:22:1E) Ch: 13 Duration: 3788 ms
5921 : EVENT: WiFi#ChangedAccesspoint
5927 : IP   : Static IP : 192.168.254.71 GW: 192.168.254.1 SN: 255.255.255.0 DNS: 192.168.254.1
        STUB: dhcp_stop
5932 : WIFI : Static IP: 192.168.254.71 (D1pro-01-11) GW: 192.168.254.1 SN: 255.255.255.0   duration: 1879 ms
5957 : Current Time Zone:  DST time start: 2036-03-30 02:00:00 offset: 120 minSTD time start: 2036-10-26 03:00:00 offset: 60 min
5957 : EVENT: Time#Set
5964 : EVENT: WiFi#Connected
5971 : Webserver: start
5979 : EVENT: Clock#Time=Thu,07:28
5989 : ACT  : taskvalueset 12,1,0
5999 : ACT  : taskvalueset 12,2,-59
6006 : ACT  : taskvalueset 12,3,26040
6014 : ACT  : taskvalueset 12,4,26896
6019 : EVENT: Clock#Time=Thu,07:28 Processing time:40 milliSeconds
        ping 1, timeout 0, total payload 32 bytes, 1064 ms
        ping 1, timeout 0, total payload 32 bytes, 1065 ms
7269 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
8088 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
8396 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
11998 : Dummy: value 1: 0.00
12000 : Dummy: value 2: -59.00
12000 : Dummy: value 3: 26040.00
12001 : Dummy: value 4: 26896.00
12006 : EVENT: sysinfo#uptime=0.00
12015 : EVENT: sysinfo#uptime=0.00 Processing time:9 milliSeconds
12016 : EVENT: sysinfo#RSSI=-59.00
12025 : EVENT: sysinfo#RSSI=-59.00 Processing time:8 milliSeconds
12025 : EVENT: sysinfo#sysheap=26040.00
12034 : EVENT: sysinfo#sysheap=26040.00 Processing time:9 milliSeconds
12034 : EVENT: sysinfo#syssec_d=26896.00
12043 : EVENT: sysinfo#syssec_d=26896.00 Processing time:9 milliSeconds
12068 : HTTP : connecting to 192.168.254.27:8383
12275 : HTTP : closing connection
        pm open,type:2 0
14437 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
18430 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
18533 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
25189 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
30390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
30391 : UDP  : Send Sysinfo message
34917 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
37273 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
38092 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
38501 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
44441 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
48436 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
48641 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
49979 : EVENT: Clock#Time=Thu,07:29
49987 : ACT  : taskvalueset 12,1,1
49994 : ACT  : taskvalueset 12,2,-57
50001 : ACT  : taskvalueset 12,3,25544
50009 : ACT  : taskvalueset 12,4,26940
50014 : EVENT: Clock#Time=Thu,07:29 Processing time:35 milliSeconds
55193 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
60390 : WD   : Uptime 1 ConnectFailures 0 FreeMem 24816
60392 : UDP  : Send Sysinfo message
64922 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
66569 : BME280: dew point 8.10C
66571 : BME280 : Address: 0x76
66572 : BME280 : Temperature: 20.28
66572 : BME280 : Humidity: 45.58
66573 : BME280 : Barometric Pressure: 1010.10
66576 : EVENT: BMx280#Temperature=20.28
66587 : EVENT: BMx280#Temperature=20.28 Processing time:11 milliSeconds
66588 : EVENT: BMx280#Humidity=45.58
66594 : EVENT: BMx280#Humidity=45.58 Processing time:6 milliSeconds
66595 : EVENT: BMx280#Pressure=1010.10
66602 : EVENT: BMx280#Pressure=1010.10 Processing time:7 milliSeconds
66627 : HTTP : connecting to 192.168.254.27:8383
66833 : HTTP : closing connection
67277 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
68096 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
68403 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
72860 : Dummy: value 1: 1.00
72861 : Dummy: value 2: -57.00
72862 : Dummy: value 3: 25544.00
72863 : Dummy: value 4: 26940.00
72865 : EVENT: sysinfo#uptime=1.00
72872 : EVENT: sysinfo#uptime=1.00 Processing time:7 milliSeconds
72872 : EVENT: sysinfo#RSSI=-57.00
72878 : EVENT: sysinfo#RSSI=-57.00 Processing time:6 milliSeconds
72879 : EVENT: sysinfo#sysheap=25544.00
72887 : EVENT: sysinfo#sysheap=25544.00 Processing time:8 milliSeconds
72888 : EVENT: sysinfo#syssec_d=26940.00
72897 : EVENT: sysinfo#syssec_d=26940.00 Processing time:9 milliSeconds
72924 : HTTP : connecting to 192.168.254.27:8383
73129 : HTTP : closing connection
74446 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
78747 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
78950 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
85197 : UDP  : 60:01:94:83:B1:70,192.168.254.80,10
90390 : WD   : Uptime 2 ConnectFailures 0 FreeMem 24816
90391 : UDP  : Send Sysinfo message
94925 : UDP  : 5C:CF:7F:9E:CC:3D,192.168.254.98,8
97280 : UDP  : 5C:CF:7F:23:CB:63,192.168.254.97,7
98101 : UDP  : 5C:CF:7F:1C:0B:DD,192.168.254.94,4
98407 : UDP  : 5C:CF:7F:1B:E4:F7,192.168.254.92,2
104448 : UDP  : 5C:CF:7F:9E:CB:D4,192.168.254.99,9
108852 : UDP  : 5C:CF:7F:23:C5:5A,192.168.254.96,6
108954 : UDP  : 5C:CF:7F:1B:E9:2F,192.168.254.91,1
110842 : EVENT: Clock#Time=Thu,07:30
110849 : ACT  : taskvalueset 12,1,2
110856 : ACT  : taskvalueset 12,2,-54
110864 : ACT  : taskvalueset 12,3,24504
110871 : ACT  : taskvalueset 12,4,27000
110876 : EVENT: Clock#Time=Thu,07:30 Processing time:34 milliSeconds

Seperti yang Anda lihat DHCP dimulai bahkan ketika diatur ke IP statis ...

Dan inilah JSON saya

{"System":{
"Build":20102,
"Git Build":"62e6317",
"Local time":"2036-02-07 07:33:33",
"Unit":11,
"Name":"D1pro-01",
"Uptime":5,
"Load":1,
"Load LC":10747,
"Free RAM":25280
},
"WiFi":{
"Hostname":"D1pro-01-11",
"IP":"192.168.254.71",
"Subnet Mask":"255.255.255.0",
"Gateway IP":"192.168.254.1",
"MAC address":"5C:CF:7F:F1:BB:E1",
"DNS 1":"192.168.254.1",
"DNS 2":"0.0.0.0",
"SSID":"SusiconStrolch",
"BSSID":"38:10:D5:B2:22:1E",
"Channel":13,
"Connected msec":319382,
"Last Disconnect Reason":1,
"Last Disconnect Reason str":"(1) Unspecified",
"RSSI":-59
},
"Sensors":[
{
"TaskNumber":4,
"Type":"Environment - BMx280",
"TaskName":"BMx280",
"TaskValues": [
{"ValueNumber":1,
"Name":"Temperature",
"Value":20.31},
{"ValueNumber":2,
"Name":"Humidity",
"Value":44.70},
{"ValueNumber":3,
"Name":"Pressure",
"Value":1010.10}]
},
{
"TaskNumber":12,
"Type":"Generic - Dummy Device",
"TaskName":"sysinfo",
"TaskValues": [
{"ValueNumber":1,
"Name":"uptime",
"Value":5},
{"ValueNumber":2,
"Name":"RSSI",
"Value":-60},
{"ValueNumber":3,
"Name":"sysheap",
"Value":25464},
{"ValueNumber":4,
"Name":"syssec_d",
"Value":27180}]
}
]
}

99 : CRC : Tidak ditemukan checksum memori program. Periksa keluaran crc2.py
130 : CRC : Pengaturan Keamanan CRC ...OK
211 : INIT : RAM Gratis
211 : INIT : I2C
211 : INIT : SPI tidak diaktifkan
1042 : INFO : Plugin: 71 [Normal] [Pengujian] (ESP82xx Core 2_4_1)
1042 : ACARA: Sistem#Bangun
1089 : WIFI : Setel WiFi ke STA
1091 : WIFI : Menghubungkan upaya SMC #0
1103 : ACARA: Sistem#Boot
1111 : ACT : Publikasikan ESP-201/IP,0.0.0.0
1124 : ACT : timerSet,1,60
1152 : WD : Uptime 0 ConnectFailures 0 FreeMem 20160
1183 : DS : Suhu: 20,37 (28-ff-b8-ea-b4-16-3-ed)
1184 : ACARA: DS18b20#Suhu=20.37
4887 : WIFI : Terhubung! AP: SMC (78:8A:20:D1:9B:D9) Bab: 1 Durasi: 3795 ms
4888 : ACARA: WiFi#ChangedAccesspoint
4910 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4911 : WIFI : IP Statis: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 durasi: 25 ms
5009 : Zona Waktu Saat Ini: Waktu mulai DST: 25-03-2018 02:00:00 offset: 120 mnt Waktu mulai STD: 28-10-2018 03:00:00 offset: 60 mnt
5010 : ACARA: Waktu#Diinisialisasi
5027 : ACARA: WiFi#Terhubung
5044 : Server web: mulai
5127 : MQTT : Disambungkan kembali dengan sengaja
5182 : MQTT : Terhubung ke broker dengan ID klien: ESPClient_5C:CF:7F:0B:68:52
5184 : Berlangganan: ESP-201/#
5185 : ACARA: MQTT#Terhubung
5846 : ACARA: Jam#Waktu=Sab,16:19

@susisstrolch Itu aneh tentang memulai DHCP, karena saya menulis tambalan untuknya baru-baru ini.
Mungkin ada yang berubah di 2.4.1?

Apa yang Anda lakukan untuk mendapatkan info debug tambahan?

Saya baru saja mengatur level debug ke "Debug more"...

@susisstrolch Anda juga tampaknya memiliki keluaran debug lain yang dihasilkan oleh perpustakaan inti.
Saya tidak melihatnya di log saya di port serial.

Sunting:
Ditemukan, Serial.setDebugOutput dipanggil dari Setup(). Jadi reboot sederhana sudah cukup :)

Berikut adalah interaksi SYSHEAP dan Uptime.

sysheap

Saya ingin tahu bagaimana grafik sysheap akan terlihat setelah satu atau dua hari.

Jika dia tidak gagal, kita akan melihatnya. :)

Semua grafik terlihat berbeda: ini adalah perangkat dengan perubahan terakhir Anda dan IP statis.

esp-201 sysheap

Bagan sebelumnya versi berapa?

Bagan pertama, versi khusus dari Anda dari tadi malam. Dengan DHCP

Menarik.
Saya akan menambahkan beberapa sysheap logging ke node saya juga.

Saya masuk dengan openHAB. Ini juga bagus dengan Grafana.

Haruskah saya mem-flash komit Anda saat ini? Kemudian grafik saya hilang di ESP-201.

Saya kira tes stabilitas wifi lebih penting saat ini.

Oke saya akan lakukan.

Oke, sedang Online.

INIT : Versi booting: (ESP82xx Core 2_4_1)
92 : INIT : Boot hangat #2
94 : FS : Memasang...
118 : FS : Mount berhasil, menggunakan 76806 byte dari 957314
131 : CRC : Tidak ditemukan checksum memori program. Periksa keluaran crc2.py
162 : CRC : Pengaturan Keamanan CRC ...OK
243 : INIT : RAM Gratis
243 : INIT : I2C
243 : INIT : SPI tidak diaktifkan
1073 : INFO : Plugin: 71 [Normal] [Pengujian] (ESP82xx Core 2_4_1)
1073 : ACARA: Sistem#Bangun
1120 : WIFI : Setel WiFi ke STA
1152 : WIFI : Menghubungkan upaya SMC #0
1153 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 1 Status Arduino: 6
1172 : ACARA: Sistem#Boot
1178 : ACT : NeoPixelAll,0,0,0,0
1189 : ACT : Publikasikan ESP-201/IP,192.168.0.201
1201 : ACT : timerSet,1,60
1226 : WD : Uptime 0 ConnectFailures 0 FreeMem 20088
1257 : DS : Suhu: 20,25 (28-ff-b8-ea-b4-16-3-ed)
1259 : ACARA: DS18b20#Suhu=20.25
4952 : WIFI : Terhubung! AP: SMC (78:8A:20:D1:9B:D9) Bab: 1 Durasi: 3798 ms
4953 : ACARA: WiFi#ChangedAccesspoint
4974 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4975 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
4980 : WIFI : IP Statis: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 durasi: 24 ms
5102 : Zona Waktu Saat Ini: Waktu mulai DST: 25-03-2018 02:00:00 offset: 120 mnt Waktu mulai STD: 28-10-2018 03:00:00 offset: 60 mnt
5103 : ACARA: Waktu#Diinisialisasi
5123 : ACARA: WiFi#Terhubung
5140 : Server web: mulai
5141 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
5223 : MQTT : Disambungkan kembali dengan sengaja
5261 : MQTT : Terhubung ke broker dengan ID klien: ESPClient_5C:CF:7F:0B:68:52
5264 : Berlangganan: ESP-201/#
5265 : ACARA: MQTT#Terhubung
5912 : ACARA: Jam#Waktu=Minggu,00:14
31226 : WD : Waktu Aktif 1 ConnectFailures 0 FreeMem 15968

Saya juga memperluas informasi di halaman sysinfo.
Menambahkan penghitung koneksi ulang dan menggunakan pengaturan Statis/DHCP (dan versi SDK)

Juga termasuk beberapa pemeriksaan sambung ulang paksa, yang akan menyambung kembali ketika tidak terhubung untuk sementara waktu.

Haruskah saya menginterupsi WIFI selama 0,2 detik?

Silakan coba untuk menghancurkannya :)

Oke

244302 : ACT : Publikasikan ESP-201/IP,192.168.0.201
244318 : ACT : Publikasikan ESP-201/MAC,5C:CF:7F:0B:68:52
244331 : ACT : Publikasikan ESP-201/Waktu,00:18:18
244343 : ACT : Publikasikan ESP-201/Uptime,4
244355 : ACT : Publikasikan ESP-201/RSSI,-62
244367 : ACT : Publikasikan ESP-201/SSID,SMC
244379 : ACT : Publikasikan ESP-201/BSSID,78:8A:20:D1:9B:D9
244391 : ACT : Publikasikan ESP-201/CH,1
244406 : ACT : Publikasikan ESP-201/SYSHEAP,12616
244422 : ACT : timerSet,1,60
255542 : ACARA: WiFi#Terputus
255560 : WIFI : Terputus! Alasan: '(1) Tidak ditentukan' Terhubung selama 4 m 10 dtk
255560 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
255571 : MQTT : Koneksi terputus
255572 : ACARA: MQTT#Terputus
255610 : MQTT : Gagal terhubung ke broker
256110 : MQTT : Gagal terhubung ke broker
256860 : MQTT : Gagal terhubung ke broker
257860 : MQTT : Gagal terhubung ke broker
259110 : MQTT : Gagal terhubung ke broker
260610 : MQTT : Gagal terhubung ke broker
262360 : MQTT : Gagal terhubung ke broker
264360 : MQTT : Gagal terhubung ke broker
266360 : MQTT : Gagal terhubung ke broker
268360 : MQTT : Gagal terhubung ke broker
270360 : MQTT : Gagal terhubung ke broker
271226 : WD : Uptime 5 ConnectFailures 22 FreeMem 17224
271247 : MQTT : Gagal terhubung ke broker
272360 : MQTT : Gagal terhubung ke broker
274360 : MQTT : Gagal terhubung ke broker
276360 : MQTT : Gagal terhubung ke broker
278360 : MQTT : Gagal terhubung ke broker
280360 : MQTT : Gagal terhubung ke broker
282360 : MQTT : Gagal terhubung ke broker
284360 : MQTT : Gagal terhubung ke broker
286291 : ACARA: Jam#Waktu=Minggu,00:19
286359 : MQTT : Gagal terhubung ke broker
288360 : MQTT : Gagal terhubung ke broker
290360 : MQTT : Gagal terhubung ke broker

Hanya untuk pemeriksaan ini, bisakah Anda membiarkannya dalam keadaan ini selama 4 menit?
Saya akan mengurangi interval ticker untuk pemeriksaan ini (saat ini 240 detik)

OK aku lakukan.

240 detik sangat lama

Ya saya tahu, saya akan mengubahnya.
Baru saja mengambil ide dari masalah ini: https://github.com/esp8266/Arduino/issues/4445

Tidak ada apa-apa....

432148 : MQTT : Gagal terhubung ke broker
434148 : MQTT : Gagal terhubung ke broker
436148 : MQTT : Gagal terhubung ke broker
438147 : MQTT : Gagal terhubung ke broker
440148 : MQTT : Gagal terhubung ke broker
442147 : MQTT : Gagal terhubung ke broker
444148 : MQTT : Gagal terhubung ke broker
446148 : MQTT : Gagal terhubung ke broker
448148 : MQTT : Gagal terhubung ke broker
450147 : MQTT : Gagal terhubung ke broker
451222 : WD : Uptime 8 ConnectFailures 446 FreeMem 17384
451243 : MQTT : Gagal terhubung ke broker
452148 : MQTT : Gagal terhubung ke broker
453907 : ACARA: Jam#Waktu=Minggu,00:29
454148 : MQTT : Gagal terhubung ke broker
456148 : MQTT : Gagal terhubung ke broker
458148 : MQTT : Gagal terhubung ke broker

Aku akan tidur, sampai jumpa besok.

baru saja menemukan masalah lain, mungkin terkait UDP:
pada unit reset pabrik yang baru, gunakan perintah serial
kunci wifi
wifissid
menyimpan

reboot, lalu pergi ke pengaturan lanjutan dan periksa ssdp. Menyalakan ulang.
Itu masuk ke loop boot kemudian:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v41a64707
~ld
⸮U87 : 


INIT : Booting version: (custom) (ESP82xx Core 41a64707)
88 : INIT : Warm boot #741
89 : FS   : Mounting...
114 : FS   : Mount successful, used 75802 bytes of 957314
120 : CRC  : No program memory checksum found. Check output of crc2.py
152 : CRC  : SecuritySettings CRC   ...OK 
258 : INIT : Free RAM:27288
258 : INIT : I2C
258 : INIT : SPI not enabled
272 : INFO : Plugins: 49 [Normal] (ESP82xx Core 41a64707)
273 : WIFI : Set WiFi to STA
304 : WIFI : Connecting MNET attempt #0
306 : WIFI  : SDK station status differs from Arduino status. SDK-status: 1 Arduino status: 6
311 : WD   : Uptime 0 ConnectFailures 0 FreeMem 26448

Exception (28):
epc1=0x40208931 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

Decoding 14 results
0x40208931: UdpContext::next() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x4024a055: Print::write(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024a2f1: Print::printNumber(unsigned long, unsigned char) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x4024ac4f: String::changeBuffer(unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/WString.cpp line 714
0x40249cf8: HardwareSerial::write(unsigned char const*, unsigned int) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp line 69
0x401071a2: millis at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring.c line 183
0x4024a27c: Print::println(char const*) at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/Print.cpp line 220
0x40213ece: LogStruct::add(char const*) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
:  (inlined by) addLog(unsigned char, char const*) at /home/john/Arduino/scetchbooks/ESPEasy/Misc.ino line 1395
0x4023545d: runEach30Seconds() at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4020c678: timeOutReached(unsigned long) at /home/john/Arduino/scetchbooks/ESPEasy/_P030_BMP280.ino line 390
0x4023eac5: loop at /home/john/Arduino/scetchbooks/ESPEasy/ESPEasy.ino line 436
0x4024bcc8: loop_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp line 125
0x40100739: cont_wrapper at /home/john/ArduinoPortable/arduino-1.8.5_ESPgit/hardware/esp8266com/esp8266/cores/esp8266/cont.S line 81

Selamat pagi semua.
Bagi saya, koneksi ulang belum berfungsi.

INIT : Versi booting: (ESP82xx Core 2_4_1)
92 : INIT : Boot hangat #8
94 : FS : Memasang...
118 : FS : Mount berhasil, menggunakan 76806 byte dari 957314
131 : CRC : Tidak ditemukan checksum memori program. Periksa keluaran crc2.py
162 : CRC : Pengaturan Keamanan CRC ...OK
243 : INIT : RAM Gratis
243 : INIT : I2C
243 : INIT : SPI tidak diaktifkan
1073 : INFO : Plugin: 71 [Normal] [Pengujian] (ESP82xx Core 2_4_1)
1074 : ACARA: Sistem#Bangun
1121 : WIFI : Setel WiFi ke STA
1153 : WIFI : Upaya menghubungkan SMC #0
1154 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
1155 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 1 Status Arduino: 6
1173 : ACARA: Sistem#Boot
1179 : ACT : NeoPixelAll,0,0,0,0
1190 : ACT : Publikasikan ESP-201/IP,192.168.0.201
1201 : ACT : timerSet,1,60
1226 : WD : Uptime 0 ConnectFailures 0 FreeMem 20072
1258 : DS : Suhu: 19,75 (28-ff-b8-ea-b4-16-3-ed)
1259 : ACARA: DS18b20#Temperature=19.75
4925 : WIFI : Terhubung! AP: SMC (78:8A:20:D1:9B:D9) Bab: 1 Durasi: 3770 ms
4926 : ACARA: WiFi#ChangedAccesspoint
4947 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
4947 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
4953 : WIFI : IP Statis: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 durasi: 23 md
5066 : Zona Waktu Saat Ini: Waktu mulai DST: 25-03-2018 02:00:00 offset: 120 mnt Waktu mulai STD: 28-10-2018 03:00:00 offset: 60 mnt
5066 : ACARA: Waktu#Diinisialisasi
5087 : ACARA: WiFi#Terhubung
5104 : Server web: mulai
5104 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
5186 : MQTT : Disambungkan kembali dengan sengaja
5222 : MQTT : Terhubung ke broker dengan ID klien: ESPClient_5C:CF:7F:0B:68:52
5225 : Berlangganan: ESP-201/#
5226 : ACARA: MQTT#Terhubung
5906 : ACARA: Jam#Waktu=Minggu,10:01
31227 : WD : Uptime 1 ConnectFailures 0 FreeMem 16336
47905 : ACARA: Jam#Waktu=Minggu,10:02
61229 : WD : Uptime 1 ConnectFailures 0 FreeMem 16336
61926 : DS : Suhu: 19,75 (28-ff-b8-ea-b4-16-3-ed)
61928 : ACARA: DS18b20#Suhu=19,75
61972 : ACARA: Aturan#Timer=1
61983 : ACT : Publikasikan ESP-201/IP,192.168.0.201
61999 : ACT : Publikasikan ESP-201/MAC,5C:CF:7F:0B:68:52
62015 : ACT : Publikasikan ESP-201/Waktu,10:02:14
62030 : ACT : Publikasikan ESP-201/Uptime,1
62044 : ACT : Publikasikan ESP-201/RSSI,-62
62060 : ACT : Publikasikan ESP-201/SSID,SMC
62076 : ACT : Publikasikan ESP-201/BSSID,78:8A:20:D1:9B:D9
62091 : ACT : Publikasikan ESP-201/CH,1
62107 : ACT : Publikasikan ESP-201/SYSHEAP,13536
62120 : ACT : timerSet,1,60
67292 : ACARA: WiFi#Terputus
67310 : WIFI : Terputus! Alasan: '(1) Tidak ditentukan' Terhubung selama 1 m 2 dtk
67310 : WIFI : Status stasiun SDK berbeda dari status Arduino. Status SDK: 5 Status Arduino: 3
67316 : MQTT : Sambungan terputus
67317 : ACARA: MQTT#Terputus
67357 : MQTT : Gagal terhubung ke broker
67856 : MQTT : Gagal terhubung ke broker
68606 : MQTT : Gagal terhubung ke broker
69607 : MQTT : Gagal terhubung ke broker
70857 : MQTT : Gagal terhubung ke broker
72357 : MQTT : Gagal terhubung ke broker
74107 : MQTT : Gagal terhubung ke broker
76106 : MQTT : Gagal terhubung ke broker
78107 : MQTT : Gagal terhubung ke broker
80107 : MQTT : Gagal terhubung ke broker
82106 : MQTT : Gagal terhubung ke broker
84106 : MQTT : Gagal terhubung ke broker
86107 : MQTT : Gagal terhubung ke broker
88106 : MQTT : Gagal terhubung ke broker
90107 : MQTT : Gagal terhubung ke broker
91228 : WD : Uptime 2 ConnectFailures 30 FreeMem 17368
91250 : MQTT : Gagal terhubung ke broker
92107 : MQTT : Gagal terhubung ke broker
94107 : MQTT : Gagal terhubung ke broker
96106 : MQTT : Gagal terhubung ke broker
98107 : MQTT : Gagal terhubung ke broker
100107 : MQTT : Gagal terhubung ke broker
102107 : MQTT : Gagal terhubung ke broker
104106 : MQTT : Gagal terhubung ke broker
106107 : MQTT : Gagal terhubung ke broker
107905 : ACARA: Jam#Waktu=Minggu,10:03
108107 : MQTT : Gagal terhubung ke broker
110107 : MQTT : Gagal terhubung ke broker
112107 : MQTT : Gagal terhubung ke broker
114107 : MQTT : Gagal terhubung ke broker
116107 : MQTT : Gagal terhubung ke broker
118107 : MQTT : Gagal terhubung ke broker
120107 : MQTT : Gagal terhubung ke broker
121228 : WD : Uptime 2 ConnectFailures 62 FreeMem 17368
121249 : MQTT : Gagal terhubung ke broker
121926 : DS : Suhu: 19,75 (28-ff-b8-ea-b4-16-3-ed)
121927 : ACARA: DS18b20#Temperature=19.75
122107 : MQTT : Gagal terhubung ke broker
122905 : ACARA: Aturan#Timer=1
122915 : ACT : Publikasikan ESP-201/IP,0.0.0.0
122927 : ACT : Publikasikan ESP-201/MAC,5C:CF:7F:0B:68:52
122939 : ACT : Publikasikan ESP-201/Waktu,10:03:15
122950 : ACT : Publikasikan ESP-201/Uptime,2
122961 : ACT : Publikasikan ESP-201/RSSI,0
122972 : ACT : Publikasikan ESP-201/SSID,--
122983 : ACT : Publikasikan ESP-201/BSSID,00:00:00:00:00:00
122994 : ACT : Publikasikan ESP-201/CH,0
123005 : ACT : Publikasikan ESP-201/SYSHEAP,16992
123015 : ACT : timerSet,1,60
124107 : MQTT : Gagal terhubung ke broker
126106 : MQTT : Gagal terhubung ke broker
128107 : MQTT : Gagal terhubung ke broker
130107 : MQTT : Gagal terhubung ke broker
132107 : MQTT : Gagal terhubung ke broker
134107 : MQTT : Gagal terhubung ke broker
136107 : MQTT : Gagal terhubung ke broker
138107 : MQTT : Gagal terhubung ke broker
140107 : MQTT : Gagal terhubung ke broker
142107 : MQTT : Gagal terhubung ke broker
144107 : MQTT : Gagal terhubung ke broker
146107 : MQTT : Gagal terhubung ke broker
148107 : MQTT : Gagal terhubung ke broker
150107 : MQTT : Gagal terhubung ke broker
151228 : WD : Uptime 3 ConnectFailures 94 FreeMem 17368
151249 : MQTT : Gagal terhubung ke broker
152107 : MQTT : Gagal terhubung ke broker
154107 : MQTT : Gagal terhubung ke broker
156107 : MQTT : Gagal terhubung ke broker
158107 : MQTT : Gagal terhubung ke broker
160107 : MQTT : Gagal terhubung ke broker
162107 : MQTT : Gagal terhubung ke broker
164107 : MQTT : Gagal terhubung ke broker
166107 : MQTT : Gagal terhubung ke broker
167905 : ACARA: Jam#Waktu=Minggu,10:04
168107 : MQTT : Gagal terhubung ke broker
170107 : MQTT : Gagal terhubung ke broker
172107 : MQTT : Gagal terhubung ke broker
174106 : MQTT : Gagal terhubung ke broker
176106 : MQTT : Gagal terhubung ke broker
178107 : MQTT : Gagal terhubung ke broker
180107 : MQTT : Gagal terhubung ke broker
181228 : WD : Uptime 3 ConnectFailures 126 FreeMem 17368
181250 : MQTT : Gagal terhubung ke broker
181926 : DS : Suhu: 19,75 (28-ff-b8-ea-b4-16-3-ed)
181927 : ACARA: DS18b20#Temperature=19.75
182107 : MQTT : Gagal terhubung ke broker
183905 : ACARA: Aturan#Timer=1
183915 : ACT : Publikasikan ESP-201/IP,0.0.0.0
183927 : ACT : Publikasikan ESP-201/MAC,5C:CF:7F:0B:68:52
183938 : ACT : Publikasikan ESP-201/Waktu,10:04:16
183950 : ACT : Publikasikan ESP-201/Uptime,3
183961 : ACT : Publikasikan ESP-201/RSSI,0
183972 : ACT : Publikasikan ESP-201/SSID,--
183983 : ACT : Publikasikan ESP-201/BSSID,00:00:00:00:00:00
183994 : ACT : Publikasikan ESP-201/CH,0
184005 : ACT : Publikasikan ESP-201/SYSHEAP,16992
184015 : ACT : timerSet,1,60
184107 : MQTT : Gagal terhubung ke broker
186106 : MQTT : Gagal terhubung ke broker
188107 : MQTT : Gagal terhubung ke broker
190106 : MQTT : Gagal terhubung ke broker
192107 : MQTT : Gagal terhubung ke broker
194106 : MQTT : Gagal terhubung ke broker
196106 : MQTT : Gagal terhubung ke broker
198106 : MQTT : Gagal terhubung ke broker
200106 : MQTT : Gagal terhubung ke broker
202106 : MQTT : Gagal terhubung ke broker
204106 : MQTT : Gagal terhubung ke broker
206106 : MQTT : Gagal terhubung ke broker
208106 : MQTT : Gagal terhubung ke broker
210106 : MQTT : Gagal terhubung ke broker
211228 : WD : Uptime 4 ConnectFailures 158 FreeMem 17368
211249 : MQTT : Gagal terhubung ke broker
212106 : MQTT : Gagal terhubung ke broker
214106 : MQTT : Gagal terhubung ke broker
216106 : MQTT : Gagal terhubung ke broker
218106 : MQTT : Gagal terhubung ke broker
220106 : MQTT : Gagal terhubung ke broker
222106 : MQTT : Gagal terhubung ke broker
224106 : MQTT : Gagal terhubung ke broker
226106 : MQTT : Gagal terhubung ke broker
227905 : ACARA: Jam#Waktu=Minggu,10:05
228107 : MQTT : Gagal terhubung ke broker
230107 : MQTT : Gagal terhubung ke broker
232107 : MQTT : Gagal terhubung ke broker
234107 : MQTT : Gagal terhubung ke broker
236106 : MQTT : Gagal terhubung ke broker
238106 : MQTT : Gagal terhubung ke broker
240106 : MQTT : Gagal terhubung ke broker
241228 : WD : Uptime 4 ConnectFailures 190 FreeMem 17368
241249 : MQTT : Gagal terhubung ke broker
241925 : DS : Suhu: 19,75 (28-ff-b8-ea-b4-16-3-ed)
241927 : ACARA: DS18b20#Temperature=19.75
242107 : MQTT : Gagal terhubung ke broker
244106 : MQTT : Gagal terhubung ke broker
244908 : ACARA: Aturan#Timer=1
244918 : ACT : Publikasikan ESP-201/IP,0.0.0.0
244930 : ACT : Publikasikan ESP-201/MAC,5C:CF:7F:0B:68:52
244942 : ACT : Publikasikan ESP-201/Waktu,10:05:17
244953 : ACT : Publikasikan ESP-201/Uptime,4
244964 : ACT : Publikasikan ESP-201/RSSI,0
244975 : ACT : Publikasikan ESP-201/SSID,--
244986 : ACT : Publikasikan ESP-201/BSSID,00:00:00:00:00:00
244997 : ACT : Publikasikan ESP-201/CH,0
245008 : ACT : Publikasikan ESP-201/SYSHEAP,16992
245018 : ACT : timerSet,1,60
246107 : MQTT : Gagal terhubung ke broker
248106 : MQTT : Gagal terhubung ke broker
250106 : MQTT : Gagal terhubung ke broker
252106 : MQTT : Gagal terhubung ke broker
254106 : MQTT : Gagal terhubung ke broker
256106 : MQTT : Gagal terhubung ke broker
258106 : MQTT : Gagal terhubung ke broker
260106 : MQTT : Gagal terhubung ke broker
262106 : MQTT : Gagal terhubung ke broker
264106 : MQTT : Gagal terhubung ke broker
266107 : MQTT : Gagal terhubung ke broker

ESP32 - perubahan terakhir (28-04-2018) MQTT berhenti bekerja, NTP berhenti bekerja
(IP statis)

@flexiti
MQTT memang kehilangan koneksi setiap detik jika Anda tidak berlangganan dan hanya mencoba untuk mempublikasikan.

52898 : MQTT : Connection lost
52925 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
52926 : Subscribed to: 
53176 : MQTT : Connection lost
53203 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53204 : Subscribed to: 
53498 : MQTT : Connection lost
53527 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53528 : Subscribed to: 
53778 : MQTT : Connection lost
53806 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
53807 : Subscribed to: 
54058 : MQTT : Connection lost
54086 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54087 : Subscribed to: 
54337 : MQTT : Connection lost
54363 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54364 : Subscribed to: 
54615 : MQTT : Connection lost
54642 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54643 : Subscribed to: 
54894 : MQTT : Connection lost
54921 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
54922 : Subscribed to: 
55172 : MQTT : Connection lost
55199 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55200 : Subscribed to: 
55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2

Cobalah untuk memasukkan sesuatu di baris berlangganan meskipun Anda tidak menggunakannya. Bekerja untuk saya.

55630 : FILE : Saved config.dat
55692 : FILE : Saved config.dat
55861 : MQTT : Connection lost
55889 : MQTT : Connected to broker with client ID: ESPClient_2C:3A:E8:06:5E:B2
55890 : Subscribed to: SMA
60404 : WD   : Uptime 1 ConnectFailures 354 FreeMem 19224
90404 : WD   : Uptime 2 ConnectFailures 353 FreeMem 19224
120404 : WD   : Uptime 2 ConnectFailures 352 FreeMem 19224
150404 : WD   : Uptime 3 ConnectFailures 351 FreeMem 19224
180404 : WD   : Uptime 3 ConnectFailures 350 FreeMem 19224
210404 : WD   : Uptime 4 ConnectFailures 349 FreeMem 19224

@TD-er
utas ini menjadi sedikit kelebihan beban dan sepertinya ada beberapa masalah wifi/stabilitas. Saya menyarankan untuk memindahkan semua masalah ke masalah github terpisah dan menandainya dengan kata kunci, misalnya
[WIFICORE] ssdp
[WIFICORE] MQTT subscription needed
[WIFICORE] Unit not found - port setting vanished
[WIFICORE] ticker interval

Sekedar laporan, baru saja ditingkatkan dari mega-20180428 menjadi mega-20180429.

Di mega-20180428 wifi stabil secara keseluruhan, tetapi tidak akan terhubung kembali setelah terputus.
di mega-20180429 wifi sangat tidak stabil dan saya tidak bisa melakukan ping tanpa banyak membaca timeout.

Saya menggunakan sonoff basic, mengkompilasi rilis sendiri dengan #define PLUGIN_SET_SONOFF_BASIC untuk membuat bin cukup kecil untuk OTA.
Tidak yakin apakah itu membantu, sementara itu kembali ke mega-20180428.

@louis-lau Bisakah Anda menguji ulang dengan komit+gabungan terbaru yang baru saja saya buat?

Ini ada di komit terbaru
screenshot

@louis-lau Dan log dari node itu sendiri?
Jika mencoba menyambung kembali ke broker MQTT, responsnya lebih lambat dan saat ini ada pengendali penyambungan ulang di latar belakang untuk menyambungkan kembali ketika ada banyak kegagalan penyambungan ulang MQTT.
Oh dan kadang-kadang setelah upaya flash yang terbaik adalah melakukan reset node (bukan pengaturan ulang, seperti menekan tombol reset). Terkadang ada beberapa konfigurasi yang tersisa yang masih ada di node setelah flashing, yang dapat menyebabkan hasil yang aneh.

@louis-lau dasar sonoff?
saya juga saya suka 0429, 0428 sangat buruk
Bisakah saya tahu lebih banyak tentang pengaturan 'keseluruhan' Anda?
Dan sebagai kompilasi sendiri, apakah itu dikompilasi dengan 2.4.1 Core ?
Saya baru saja menguji 0429 flash baru pada node kosong & itu berjalan dengan sempurna.
Percobaan saya sebelumnya dengan 0429 adalah pembaruan ke node set statis yang telah dikonfigurasi sebelumnya. sempurna juga
Papan saya bertanggal 5-5-2017

@Oxyandy
2.4.2 inti????

Ini semua yang saya dapatkan yang tampaknya relevan:

04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:46 milliSeconds
04-29-2018  15:43:29    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:29    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 12 Set to 0
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1132 milliSeconds
04-29-2018  15:43:06    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:43:06    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,3,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,2,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,1,0
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: Subscribed to: /sonoff_lavalamp/#
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:71:68:FB
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set Processing time:47 milliSeconds
04-29-2018  15:43:05    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: EVENT: Time#Set
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP replied: 20 mSec
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: NTP  : NTP host time.google.com (216.239.35.8) queried
04-29-2018  15:43:05    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
04-29-2018  15:42:53    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: WD   : Uptime 3 ConnectFailures 2 FreeMem 19456
04-29-2018  15:42:53    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: 2: lowest: 12320  parseTemplate3-> 17112 ruleMatch-> 17088 ruleMatch2-> 17040 parseTemplate-> 17176 parseTemplate3-> 17112 ruleMatch-> 17072 ruleMatch2-> 17008 rulesProcessingFile2-> 17160 sendContentBlocking-> 17184 sendConten
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: EVENT: MQTT#Connected Processing time:1131 milliSeconds
04-29-2018  15:42:47    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: else = false
04-29-2018  15:42:47    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: SW   : GPIO 13 Set PWM to 1023
04-29-2018  15:42:46    Kernel.Debug    192.168.2.22    sonoff_lavalamp EspEasy: [if 0=0]=true
04-29-2018  15:42:46    Kernel.Notice   192.168.2.22    sonoff_lavalamp EspEasy: ACT  : timerSet,4,0

@Oxyandy Saya akan mencoba reset pabrik. Saya belum melakukan perubahan apa pun sebelum kompilasi, kecuali flag plugin dasar sonoff dan pengaturan jaringan di Custom.h.

Anda benar, berfungsi dengan baik dengan pengaturan pabrik .

Saya akan mencoba memulihkan, melihat apakah itu rusak lagi.

Itu hanya terlihat seperti reboot?

Di log web Anda akan mendapatkan lebih banyak baris, karena yang itu memiliki buffer 15 baris.
Juga di halaman sysinfo Anda bisa mendapatkan info lebih lanjut.

Log yang direkam di server syslog mungkin tidak lengkap, karena yang itu tidak menerima data saat wifi terputus.

Baiklah, mulai terjadi lagi ketika saya mengaktifkan pengontrol mqtt.
Dan berhenti ketika saya menonaktifkannya.

Saya akan mencoba untuk mendapatkan log yang lebih baik, agak sulit ketika Anda tidak dapat terhubung dengannya sepanjang waktu.
tingkat log apa? debug?

Koneksi MQTT juga ditampilkan di tingkat info.
Info memang menunjukkan kesalahan + info.
Dengan begitu, Anda tidak mengisi buffer log weblog terlalu cepat untuk ditampilkan.

Oke, saat saya stop server mqtt juga berfungsi normal, hanya saat server sedang berjalan koneksi time out.

Ini semua yang bisa saya dapatkan dari log:
screenshot

Kontroler MQTT macam apa ini? Domoticz? BukaHAB?

Atau apakah Anda mencoba melakukan importMQTT?

Ada juga tombol salin di halaman web yang menunjukkan log.
Halaman itu diperbarui setiap N detik, yang memungkinkan Anda untuk menempelkan teks di antara pembaruan ke editor teks.
Ini tidak sempurna, saya tahu, tapi itu lebih baik daripada tidak sama sekali :)

Sunting:
Silakan lihat juga aturannya, jika sudah lengkap.
Masih ada masalah saat menyimpan aturan. Penyimpanan ini mungkin bukan kumpulan aturan lengkap yang dimasukkan.

Menggunakan githib terbaru (07bfec42347d13ad49dda907654a36bf747df3bc), Wifi terhubung tanpa masalah di semua node saya. Sekarang juga terhubung kembali dengan benar setelah AP reboot. Menggunakan inti 2.4.1.

Hehe, setelah itu benar-benar dimuat saya punya sedikit waktu, jadi saya hanya mengambil tangkapan layar. Saya menggunakan pengontrol openhab mqtt, servernya adalah mosquitto.

EDIT: tidak menggunakan aturan sekarang. Hanya untuk memastikan bukan itu masalahnya.

Sama disini. Cobalah untuk berlangganan topik apa pun. Itu memperbaiki masalah saya.

-------- Ursprüngliche Nachricht --------
Von: pemberitahuan Louis [email protected]
Gesendet: 29. April 2018 16:23:54 MESZ
An: letcontrolit/ESPEasy [email protected]
CC: s0170071 [email protected] , mention [email protected]
Betreff: Re: [letscontrolit/ESPEasy] Masalah Wifi -tidak pernah berakhir cerita- kembali ke wifi berbasis non acara? (#1302)

Hehe, setelah itu benar-benar dimuat saya punya sedikit waktu, jadi saya hanya mengambil tangkapan layar. Saya menggunakan pengontrol openhab mqtt, servernya adalah mosquitto.

--
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/letscontrolit/ESPEasy/issues/1302#issuecomment -385255207

@s0170071 Di mana langganan ini harus dilakukan?
Jika itu dalam beberapa jenis pengaturan default, maka mungkin kita harus menambahkannya.

Apakah waktu antara MQTT menghubungkan kembali sekitar 15 - 16 detik? Maka bisa jadi Nyamuk menendang Anda keluar dan kemudian saya tahu di mana harus menambal ini.

Dalam pengaturan pengontrol openhab. Ada kolom berlangganan.

Menggunakan githib terbaru (07bfec4), MQTT juga berfungsi tanpa masalah di sini menggunakan pengontrol openhab dan menghubungkan ke Mosquitto. Menggunakan inti 2.4.1.

@td-er lihat beberapa posting di atas.

Saya sudah berlangganan /sonoff_lavalamp/# seperti yang Anda lihat di log.

Saya memang memperhatikan ketika saya berlangganan # (jadi, semua topik). Wifinya stabil, tapi itu membuat mqtt tidak bisa digunakan ;)

Nyamuk tidak boleh mengusir pengguna, pengguna yang saya gunakan memiliki izin untuk semua topik.

Ini adalah log nyamuk:

1525014154: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014168: New connection from 192.168.2.22 on port 1883.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014168: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014168: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014196: New connection from 192.168.2.22 on port 1883.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014196: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014196: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014214: New connection from 192.168.2.22 on port 1883.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014214: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014214: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014226: New connection from 192.168.2.22 on port 1883.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014226: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014226: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014255: New connection from 192.168.2.22 on port 1883.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB already connected, closing old connection.
1525014255: Client ESPClient_5C:CF:7F:71:68:FB disconnected.
1525014255: New client connected from 192.168.2.22 as ESPClient_5C:CF:7F:71:68:FB (c1, k15, u'my_mqtt_username').
1525014270: New connection from 192.168.2.22 on port 1883.

Tampaknya terhubung kembali, dan nyamuk menutup koneksi lama.

Saya telah mencari sumber PubSubClient.
Tampaknya harus ada aktivitas masuk dan keluar dalam periode batas waktu.
Jika salah satunya gagal, PubSubClient akan terputus dan dengan demikian ESPeasy akan menyambung kembali.

Saya akan mencoba menambahkan semacam ping otomatis. Sudah ada beberapa, tetapi mungkin pemeriksaan dilakukan sebelum ping kembali.

@louis-lau Bisakah Anda menemukan pengaturan waktu tetap hidup yang digunakan di Nyamuk Anda?

Sepertinya setting timeout MQTT yang kita gunakan adalah 15 detik.
Ini didefinisikan sebagai: #define MQTT_KEEPALIVE 15

Lihat juga https://github.com/knolleary/pubsubclient/issues/239

Wow, Anda berhasil @TD-er !!!!!

467279 : ACARA: Jam#Waktu=Minggu,17:24
467588 : WD : Uptime 8 ConnectFailures 0 FreeMem 16304
481935 : MQTT : Sambungan terputus
481935 : ACARA: MQTT#Terputus
481953 : ACARA: WiFi#Terputus
481969 : WIFI : Terputus! Alasan: '(1) Tidak ditentukan' Terhubung selama 7 m 40 dtk
482278 : WIFI : Upaya menghubungkan SMC #0
482278 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
483304 : ACARA: WiFi#Terputus
483322 : WIFI : Terputus! Alasan: '(202) Auth gagal' Terhubung selama 1018 md
484291 : WIFI : Menghubungkan upaya SMC #1
484292 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488073 : WIFI : Terhubung! AP: SMC (78:8A:20:D1:9B:D9) Bab: 1 Durasi: 3780 ms
488074 : IP : IP Statis : 192.168.0.201 GW: 192.168.0.3 SN: 255.255.255.0 DNS: 192.168.0.3
488078 : WIFI : IP Statis: 192.168.0.201 (ESP-201-1) GW: 192.168.0.3 SN: 255.255.255.0 durasi: 6 ms
488099 : ACARA: WiFi#Terhubung
488245 : MQTT : Terhubung ke broker dengan ID klien: ESPClient_5C:CF:7F:0B:68:52
488247 : Berlangganan: ESP-201/#
488248 : ACARA: MQTT#Terhubung
489111 : ACARA: Waktu#Set

@TD-er Apakah Anda yakin tentang pubsubclient yang mengalami masalah? Unit saya tidak menerima apa pun, hanya mengirim nilai analog setiap 30 detik. Tidak ada masalah koneksi MQTT. Jika ada masalah dengan perpustakaan, bukankah kita akan memiliki lebih banyak pengguna yang mengeluh?

Mungkin ini kondisi balapan...

Broker MQTT harus mempertimbangkan klien sebagai terputus pada 1,5x batas waktu.
Pubsubclient mengirim ping ketika aktivitas terakhir lebih dari 15 detik yang lalu.
Jadi jika timeout default Mosquito (10s) sedang digunakan, maka timing menjadi cukup kritis.

Pada pengaturan saya, saya melihat banyak lalu lintas MQTT dari semua node di sini mengobrol di saluran (domoticz) yang sama.
Jadi batas waktu tidak pernah menjadi masalah di sini.
Tetapi jika hanya ada satu node, lalu lintasnya jauh lebih sedikit dan dengan batas waktu default ESPeasy ditetapkan tepat 1,5x batas waktu default Mosquito, ini mungkin agak kritis.

Kemudian dia dapat mencoba mengirim nilai analog dummy setiap 5 detik untuk memeriksa apakah masalahnya hilang...

Atau gunakan komit terakhir saya ;)

Koneksi ulang saya sangat cepat, setiap detik atau lebih

Pengembang MQTT sepertinya tidak menyukainya:
Saya tidak cenderung untuk mengubah nilai default. Sudah 15 detik selama 7+ tahun. Jika ada, kami akan membuatnya lebih mudah untuk menyesuaikan dan tidak bergantung pada pengeditan file header.

Definisi dibungkus dengan #ifdef
Jadi ada opsi untuk mendefinisikannya di bagian lain dari kode.

Di halaman github dari PubSubclient, ada juga masalah tentang membuatnya dapat dikonfigurasi.

Komentar lain oleh penulisnya:
Dalam protokol MQTT, klien menentukan nilai keepalive yang digunakan pada koneksi. Broker tidak memiliki suara di dalamnya.

Satu-satunya opsi konfigurasi keepalive di mosquitto adalah bridge keepalive - di mana ia bertindak sebagai klien yang terhubung ke broker lain - https://mosquitto.org/man/mosquitto-conf-5.html

Saya telah memeriksa konfigurasi mosquitto saya. Tidak dapat menemukan opsi batas waktu untuk koneksi

Dokumen ini membahas perilaku timeout.

Dan dokumen itu menyatakan hal yang sama:

Klien MQTT bertanggung jawab untuk mengatur nilai keep-live yang tepat. Misalnya, ia dapat menyesuaikan interval dengan kekuatan sinyalnya saat ini.

Jadi dari mana datangnya waktu Nyamuk 10 detik? Apakah itu di-hardcode?

https://mosquitto.org/man/mosquitto-conf-5.html

keepalive_interval detik
Tetapkan jumlah detik setelah jembatan harus mengirim ping jika tidak ada lalu lintas lain yang terjadi. Default ke 60. Nilai minimum 5 detik diperbolehkan.

Pengaturan itu hanya untuk menjembatani

Perlu diingat bahwa ini bukan masalah di 20180428 :)

EDIT: Saya akan mencoba komit terbaru Anda ketika saya pulang.

Anda dapat mencoba menonaktifkan connectionCheckHandler .

Untuk melihat apa yang berubah di hari terakhir: https://github.com/letscontrolit/ESPEasy/compare/mega@%7B1day%7D...mega

Baru saja diperbarui ke https://github.com/letscontrolit/ESPEasy/commit/4e6e31fdae11476a2f3dfce00e01ed77d1858c00 dan wifi sekarang stabil. Itu juga terhubung kembali sekarang ketika saya me-restart AP saya! terima kasih

(btw, apakah ada cara untuk mengaktifkan pengaturan LED Status Wifi menggunakan aturan? Misalnya saya hanya ingin mengaktifkannya jika mqtt terputus, dan menggunakannya untuk status relai saat terhubung.)

Saya tidak yakin tentang LED status. Itu dipanggil dari fungsi MQTTconnect dan dari beberapa tempat lain.
Tapi mungkin Anda bisa menambahkan masalah untuk membuatnya dapat dipilih apa yang ditampilkan melalui LED itu?

Dan bagus untuk mendengar masalah MQTT tampaknya diperbaiki dengan batas waktu yang lebih rendah.
Kita mungkin harus membuatnya dapat dipilih.

Bisakah Anda membuat jendela LOG sedikit lebih lama?
Maksudku, menambah jumlah baris.

Kalau tidak, itu berjalan sangat baik sekarang.

Saya hanya mengurangi mereka.
Itu 20 baris, tetapi dengan 2.4.0 harus ada sedikit lebih banyak mem bebas, jadi saya menguranginya menjadi 10 baris untuk dev/test dan 15 untuk normal.

Saya akan melihat konsumsi memori minggu ini dan @Grovkillen sedang mencari cara untuk mendapatkan jendela log yang tepat.

Oke, aku pergi tidur.
Banyak Terima kasih atas kerja keras Anda!!

Tentang jendela itu. Seperti yang saya lihat, ada tiga opsi.

  1. Gunakan ram sebanyak yang tersedia untuk menyimpan info sampai diminta. Bisa dinamis, tergantung berapa banyak plugin yang aktif.
  2. Streaming ke Webbrowser.
  3. Kompres sementara dan pulihkan saat diminta. Misalnya menggunakan lebih banyak kode numerik. Kurang terbaca tentunya.

Saya suka 2. Memberikan tampilan web yang halus juga. Ini tidak sesederhana itu.

Idenya adalah untuk mendapatkan semacam JavaScript untuk mengumpulkan log dan menyimpannya di browser.
Ada beberapa opsi untuk mengirimkan data ke browser, seperti menjaga koneksi tetap terbuka, atau beberapa teknik lainnya.
Itu hanya menyisakan beberapa baris log yang perlu disimpan dalam memori.
Dan buffer itu juga bisa digunakan untuk mentransfer log ke syslog.

Objek cache log saat ini tidak begitu efisien dengan memori. Banyak ruang untuk perbaikan.

Saya juga bertanya-tanya sekarang apakah versi nyamuk yang berbeda?
berjalan pada sistem operasi yang berbeda memiliki perilaku yang berbeda?
Saya tahu ESPeasy harus fleksibel, tetapi pembaruan nyamuk akan menyelesaikan masalah bagi sebagian orang.

Hanya untuk memahami...
Mengapa saya mendapatkan langsung setelah mem-boot ESP saya ini:

Last Disconnect Reason str |  (1) Unspecified
Number reconnects | 1

Di syslog saya melihat dua pesan IP STATIS dan Uptime 0 ConnectFailures 0:

INIT : Booting version: mega-20180430 (ESP82xx Core 2_4_1)
104 : INIT : Warm boot #1
105 : FS   : Mounting...
130 : FS   : Mount successful, used 75802 bytes of 957314
419 : CRC  : program checksum       ...OK
426 : CRC  : SecuritySettings CRC   ...OK 
532 : INIT : Free RAM:23528
532 : INIT : I2C
532 : INIT : SPI not enabled
546 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1)
546 : WIFI : Set WiFi to STA
578 : WIFI : Connecting im6shop attempt #0
579 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
585 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22688
4342 : WIFI : Connected! AP: im6shop (30:B5:C2:EB:DB:7D) Ch: 9 Duration: 3763 ms
4343 : IP   : Static IP : 192.168.1.17 GW: 0.0.0.0 SN: 0.0.0.0 DNS: 0.0.0.0
4346 : WIFI : Static IP: 0.0.0.0 (ESP-Easy-7) GW: 0.0.0.0 SN: 0.0.0.0   duration: 3 ms
4356 : Webserver: start
4710 : WIFI : Static IP: 192.168.1.32 (ESP-Easy-7) GW: 192.168.1.1 SN: 255.255.255.0   duration: 356 ms

Mungkin istilah "reconnect" tidak dipilih dengan baik.
Ini lebih seperti "(kembali) menghubungkan", atau "menghubungkan upaya"
Penghitung dimulai pada 0 dan pada setiap upaya koneksi, itu adalah penghitung ++.

Saya mengubah penghitung dengan menginisialisasi ke '-1'. Jadi upaya koneksi pertama akan mengaturnya ke 0, sehingga label "Nomor terhubung kembali" sekarang masuk akal lagi :)
Saya tidak bisa memikirkan nama yang lebih baik, jadi saya mengubah nilai yang dilaporkan ;)

Penamaan yang tepat masih merupakan bagian tersulit dari pemrograman.

Kedengarannya bagus!

koneksi coba x

Sayangnya build terbaru 20180503 (4096 dev) tidak berfungsi untuk saya - web ESP tidak terbuka, melainkan berhenti merespons di konsol serial (setelah upaya membuka web). Pengaturan diatur ulang ke default dan hanya mengatur WifiSSID dan kunci melalui konsol serial. PING berfungsi, tidak ada reboot, tidak ada pesan kesalahan.

Sudahkah Anda melakukan reboot dingin setelah flash?
Saya memiliki sesuatu yang serupa tepat setelah menginstal.
Siklus daya memang menyelesaikannya saat itu.

Ya saya mencoba reboot dingin berkali-kali, itu masih sama. Diuji dari MSIE dan Firefox di Win7. Saya akan menguji perangkat di lokasi lain beberapa menit kemudian (PC / OS berbeda, AP berbeda).
Tepat setelah flash itu reboot dan digantung.

Saya sudah mencobanya sekarang, dengan versi normal. Di sisi saya, tidak ada masalah. Tidak ada daya pada reset yang diperlukan.

Anehnya di lokasi lain web ESP perangkat yang sama berfungsi (Win10 + Firefox / MS Edge, AP berbeda) tetapi konsol serial terlihat "hanya baca"... :-/
Perbarui - mencoba aplikasi terminal lain - konsol serial yang sama hanya baca. Kemudian jalankan Putty (yang merupakan aplikasi terminal default saya) lagi dan lihat perangkat me-reboot segera setelah saya terhubung dengan Putty ke port COM yang sesuai. Sekarang konsol serial menerima perintah dan web juga berfungsi ... Saya tidak mengerti apa-apa ...

Mungkin coba hapus total flash dan program lagi?
Tampaknya ada hubungan dengan koneksi wifi dan apakah port serial sedang dibaca. Saya pernah melihat seseorang menyebutkan itu di utas. Tidak yakin apakah itu pada masalah PlatformIO atau pada LWIP.
Akhir-akhir ini saya banyak membaca ;)

Ya, saya akan mencobanya dengan beberapa build berikutnya, yang ini saya ingin uji di lokasi lain lagi untuk melihat apakah itu masih masalah yang sama (konfigurasi perangkat diperbarui sedikit sementara itu).
OMONG-OMONG. ketika saya mengatur ulang pengaturan untuk pertama kalinya (setelah build ini berkedip, dengan mengeluarkan perintah Reset dari konsol serial), sebenarnya itu TIDAK mengatur ulang pengaturan meskipun dikatakan "memformat flash" dll. Perangkat di-boot ulang dan setidaknya pengaturan WiFi masih ada ketika saya melihat upaya menghubungkan ke AP di konsol serial ... Upaya reset kedua dari konsol serial menghapus pengaturan ...

Yap, perpustakaan inti menyimpan pengaturan wifi di area di luar SPIFF.
Ini dapat memengaruhi upaya koneksi wifi.

Saya sudah membaca di kode (inti) bahwa sekarang ada dukungan hingga 5 pengaturan wifi, yang dapat Anda pilih.
Jadi mungkin saya akan aktif menggunakan tempat penyimpanan itu juga, untuk memastikan tidak akan bertentangan dengan pengaturan kita sendiri.
Satu-satunya hal yang saya takutkan, adalah bahwa pengaturan itu akan terlalu sering ditulis. Saya harus memeriksa kapan itu sedang ditulis.
Tapi itu mungkin membuat koneksi wifi sedikit lebih dapat diprediksi ketika area itu juga diperhitungkan dengan ESPeasy.

@Oxyandy Saya sekarang akan mendorong perubahan PlatformIO.ini untuk menggunakan LWIP2_LOW_MEMORY.
Bisakah Anda menguji ini?
Dan juga pertanyaan apakah Anda menggunakan tugas/perangkat 12?
Saya baru saja mengujinya di node saya dan segera terputus + menolak untuk online lagi.
Itu dengan LWIP1.4

Dan juga pertanyaan apakah Anda menggunakan tugas/perangkat 12?

Dalam pengujian, tidak hanya yang pertama, satu sakelar
Ya, ada 15 file yang diubah di GitHub Desktop yang ditarik sekarang

Dikompilasi dengan baik, server web hebat, menggunakan LWIP2_LOW_MEMORY, tes F5, bagus sekali..
tidak ada tanda-tanda LmacRxBlk: 1 di log
Saya telah menghapus semua pengaturan pada Node, tetapi akan 'menyetel ulang' dan menjalani prosesnya, melaporkan keanehan apa pun ..
Wifi nyambung langsung masuk dulu..

hanya hati-hati dengan memori rendah lwIP2, saya harus menggunakan bandwidth tinggi lwIP2, jika tidak, paket besar terpotong (misalnya sensor dengan banyak nilai), setidaknya saat menggunakan fhem sebagai server/pengontrol ...

Saat ini saya menggunakan cabang mega dengan inti esp dari GIT dan bandwidth tinggi lwIP2 yang berjalan dengan baik, kecuali setelah beberapa waktu beberapa unit tidak dapat membaca nilai sensor lagi dan oleh karena itu tidak akan mengirimkannya ke pengontrol. unit itu sendiri serta antarmuka web berjalan dengan lancar ... Saya masih menyelidiki ini, tidak pernah melakukan ini sebelumnya Mai..

Kami mencoba bandwidth tinggi LwIP2 dan pesan POST yang kacau.
Misalnya, aturan penyimpanan > 1520 byte terpotong.

ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Apakah yang dimaksud sebagai serangan DoS pada server waktu?
Setelah saya mem-flash saya dipanggil, saya memiliki halaman & halaman loop ini

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
105 : INIT : Cold Boot
106 : FS   : Mounting...
113 : FS   : Mount successful, used 76053 bytes of 113201
15:40:37: 410 : CRC  : program checksum       ...OK
417 : CRC  : SecuritySettings CRC   ...OK 
418 : CRC  : binary has changed since last save of Settings
433 : INIT : Free RAM:23448
434 : INIT : I2C
434 : INIT : SPI not enabled
449 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
449 : EVENT: System#Wake
458 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:96:ec)
add if0
491 : WIFI : Connecting MAD_IOT attempt #0
492 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
505 : EVENT: System#Boot
514 : SW   : Switch state 1 Output value 1
517 : EVENT: Float_SW#Switch=1.00
530 : ACT  : Publish domoticz/in,{"idx":66,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
541 : Command: publish
1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22736
15:40:39: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:41: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
4480 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 3986 ms
4485 : EVENT: WiFi#ChangedAccesspoint
4497 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
4499 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
4517 : EVENT: WiFi#Connected
4525 : Webserver: start
4526 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5015 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
5066 : NTP  : NTP replied: 50 mSec
5068 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-04-01 01:00:00 offset: 600 min
5071 : EVENT: Time#Initialized
5082 : EVENT: Time#Initialized Processing time:11 milliSeconds
5083 : EVENT: Clock#Time=Fri,15:40
5089 : EVENT: Clock#Time=Fri,15:40 Processing time:6 milliSeconds
5091 : MQTT : Intentional reconnect
5091 : LoadFromFile: config.dat index: 28672 datasize: 336
5221 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
5222 : Subscribed to: domoticz/out
5224 : EVENT: MQTT#Connected
5234 : EVENT: MQTT#Connected Processing time:9 milliSeconds
15:40:43: ping 1, timeout 0, total payload 32 bytes, 1365 ms
15:40:48: bcn_timout,ap_probe_send_start
15:40:50: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
13912 : EVENT: WiFi#Disconnected
13919 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9432 ms
13930 : MQTT : Connection lost
13931 : EVENT: MQTT#Disconnected
14514 : WIFI : Connecting MAD_IOT attempt #0
14515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
15:40:51: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:40:52: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16258 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 1738 ms
16260 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16269 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
16288 : EVENT: WiFi#Connected
16295 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16389 : LoadFromFile: config.dat index: 28672 datasize: 336
16425 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
16426 : Subscribed to: domoticz/out
16427 : EVENT: MQTT#Connected
16434 : EVENT: MQTT#Connected Processing time:6 milliSeconds
16557 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
16599 : NTP  : NTP replied: 40 mSec
16600 : EVENT: Time#Set
16606 : EVENT: Time#Set Processing time:5 milliSeconds
15:40:54: ping 1, timeout 0, total payload 32 bytes, 1022 ms
15:40:59: bcn_timout,ap_probe_send_start
15:41:01: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25176 : EVENT: WiFi#Disconnected
25183 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms
25194 : MQTT : Connection lost
25195 : EVENT: MQTT#Disconnected
25514 : WIFI : Connecting MAD_IOT attempt #0
25515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:02: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
26186 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 666 ms
26189 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
26197 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
26217 : EVENT: WiFi#Connected
26224 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
26318 : LoadFromFile: config.dat index: 28672 datasize: 336
26344 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
26345 : Subscribed to: domoticz/out
26346 : EVENT: MQTT#Connected
26353 : EVENT: MQTT#Connected Processing time:7 milliSeconds
15:41:04: ping 1, timeout 1, total payload 0 bytes, 1022 ms
27623 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
27664 : NTP  : NTP replied: 41 mSec
27665 : EVENT: Time#Set
27671 : EVENT: Time#Set Processing time:6 milliSeconds
27672 : EVENT: Clock#Time=Fri,15:41
27677 : EVENT: Clock#Time=Fri,15:41 Processing time:5 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1024 ms
15:41:07: 31004 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
15:41:10: bcn_timout,ap_probe_send_start
15:41:12: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
36143 : MQTT : Connection lost
36144 : EVENT: MQTT#Disconnected
36151 : EVENT: WiFi#Disconnected
36156 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9948 ms
36514 : WIFI : Connecting MAD_IOT attempt #0
36515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
15:41:13: 
connected with MAD_IOT, channel 13
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
37145 : WIFI : Connected! AP: MAD_IOT (F4:F2:6D:25:84:C6) Ch: 13 Duration: 625 ms
37147 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
37155 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
37176 : EVENT: WiFi#Connected
37182 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
37276 : LoadFromFile: config.dat index: 28672 datasize: 336
37296 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:96:EC
37297 : Subscribed to: domoticz/out
37298 : EVENT: MQTT#Connected
37306 : EVENT: MQTT#Connected Processing time:8 milliSeconds
37551 : NTP  : NTP host au.pool.ntp.org (129.250.35.250) queried
37592 : NTP  : NTP replied: 41 mSec
37593 : EVENT: Time#Set
37599 : EVENT: Time#Set Processing time:6 milliSeconds
15:41:15: ping 1, timeout 0, total payload 32 bytes, 1046 ms
15:41:20: bcn_timout,ap_probe_send_start
15:41:22: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
46076 : MQTT : Connection lost
46076 : EVENT: MQTT#Disconnected
46083 : EVENT: WiFi#Disconnected
46089 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8921 ms
46514 : WIFI : Connecting MAD_IOT attempt #0
46515 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

Dengan inti saat ini (Master, ESP82xx Core 41a64707, NONOS SDK 2.2.1(cfd48f3)) masalah MTU tidak muncul lagi.
Memiliki 10 ESP (Sonoff, NodeMcu, W1pro) yang berjalan sejak 1 Mei tanpa masalah.

FYI... Flash build resmi terbaru, reset pengaturan melalui serial ke default, masukkan WiFiSSID dan kunci. Tidak dapat terhubung ke AP utama meskipun terlihat (tetapi sinyal lemah sekitar -82). Kemudian jatuh seperti yang Anda lihat di bawah.
Di lokasi lain, perangkat terhubung ke AP sekunder dengan cepat tanpa masalah dan sejauh ini berfungsi (tetapi tidak ada plugin yang dikonfigurasi, tidak ada aturan yang aktif).
....
....
458745 : WIFI : Menghubungkan IOTP1 upaya #57
458749 : Mode AP: Klien terputus: xx:xx:xx:xx:xx:xx Perangkat yang terhubung: 0
458810 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 64 md
459360 : Mode AP: Klien terhubung: xx:xx:xx:xx:xx:xx Perangkat yang terhubung: 1
471739 : WIFI : AP Mode ssid akan menjadi ESP_Easy_0 dengan alamat 192.168.4.1
471739 : WIFI : Menghubungkan IOTAP2 upaya #58

Pengecualian (29):
epc1=0x4000e1c3 epc2=0x00000000 epc3=0x40000f68 excvaddr=0x00000018 depc=0x00000000

ctx: sys
sp: 3ffffc50 akhir: 3fffffb0 offset: 01a0

tumpukan>>>
3ffffdf0: 3fff5108 1f385062 401021e6 3fffa2b0
3ffffe00: 402706a6 402705c4 3fff9454 40100eb6
3ffffe10: 3ffeb6d5 401042bb 3ffef160 4026a718
3ffffe20: 00000018 3ffefb30 3ffefaac 00000000
3ffffe30: 40270767 3ff20a00 3fff9454 3ffedf1a
3ffffe40: 3ffedf00 00000000 00000000 00000006
3ffffe50: 00000021 1f4328f4 401021e6 3ffedf00
3ffffe60: 3ffedf1a 0000002c 00000008 401004f4
3ffffe70: 3ffedf0a 3fff6454 4026d324 3ff20a00
3ffffe80: 3fff9454 3fff55c4 00000015 4026d1f7
3ffffe90: 3fffc278 40101f80 3fffc200 00000022
3ffffea0: 3ffebf74 00000000 00000000 3fff4fe4
3ffffeb0: 40000f68 00000030 00000010 ffffffff
3ffffec0: 40000f58 00000000 00000020 00000000
3ffffed0: 3ffff7d4 7ffffffff 00000000 3ffeed30
3ffffee0: 3ffef138 00000006 00000000 3fffdab0
3ffffef0: 00000000 3fffdcc0 00000040 00000030
3fffff00: 40274fd1 ffffffe0 00000000 00000000
3fffff10: 4026ca2f 3ffedf00 3ffef160 3fff9454
3fffff20: 00000000 3ffedf0a 3ffedf20 4026a4d1
3fffff30: 4027fac5 00000001 00000000 3ffedf0a
3fffff40: 4027ec78 00000092 3ffedef4 3fff6454
3fffff50: 3ffedef4 00000000 00000040 4027e5a2
3fffff60: 3ffef160 3ffedef4 3fffdcc0 3ffeb710
3fffff70: 3ffedf10 3fff752c 00000040 3ffeb710
3fffff80: 00000040 3ffef160 00000002 00000000
3fffff90: 4027de7f 3fffdab0 00000000 40283f5f
3fffffa0: 3ffeb710 40000f49 3fffdab0 40000f49
<<

ets 8 Jan 2013, penyebab pertama

muat 0x4010f000, len 1384, kamar 16
ekor 8
chksum 0x2d
csum 0x2d
v614f7c32
~ld
-U88 :

INIT : Versi boot: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Boot hangat #6
90 : FS : Memasang...
116 : FS : Mount berhasil, menggunakan 75802 byte 957314
436 : CRC : program checksum ...OK
442 : CRC : Pengaturan Keamanan CRC ...OK
548 : INIT : RAM Gratis
549 : INIT : I2C
549 : INIT : SPI tidak diaktifkan
565 : INFO : Plugin: 72 [Normal] [Pengujian] [Pengembangan] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
566 : WIFI : Setel WiFi ke STA
599 : WIFI : Menghubungkan IOTP1 upaya #0
607 : WD : Uptime 0 ConnectFailures 0 FreeMem 20616
3461 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2861 mdtk
3604 : WIFI : Menghubungkan IOTP1 upaya #1
6466 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2862 ms
6604 : WIFI : Menghubungkan upaya IOTP2 #2
9467 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2862 ms
9604 : WIFI : Menghubungkan upaya IOTAP2 #3
12467 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2862 ms
12604 : WIFI : Menghubungkan IOTAP1 upaya #4
15466 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2862 ms
15604 : WIFI : Menghubungkan IOTP1 upaya #5
18466 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2862 ms
18604 : WIFI : Setel WiFi ke AP+STA
19524 : WIFI : AP Mode ssid akan menjadi ESP_Easy_0 dengan alamat 192.168.4.1
19524 : WIFI : Menghubungkan IOTAP2 upaya #6
22388 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2863 mdtk
22603 : WIFI : AP Mode ssid akan menjadi ESP_Easy_0 dengan alamat 192.168.4.1
22603 : WIFI : Menghubungkan IOTAP2 upaya #7
25463 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2860 mdtk
25602 : WIFI : AP Mode ssid akan menjadi ESP_Easy_0 dengan alamat 192.168.4.1
25603 : WIFI : Menghubungkan IOTP1 upaya #8
28464 : WIFI : Terputus! Alasan: '(201) Tidak ada AP ditemukan' Terhubung selama 2860 mdtk
28602 : WIFI : AP Mode ssid akan menjadi ESP_Easy_0 dengan alamat 192.168.4.1
28603 : WIFI : Menghubungkan IOTAP1 upaya #9
30606 : WD : Uptime 1 ConnectFailures 0 FreeMem 18176
...
...

Saya juga melihat kesalahan "Tidak ditemukan AP" kemarin.
Tampaknya terkait dengan beberapa pengaturan yang salah atau rusak. Bukan hanya pengaturan yang kami simpan, tetapi mungkin juga pengaturan yang disimpan di bagian lain dari flash, oleh perpustakaan inti.

Pembaruan @Oxyandy NTP harus dilakukan hanya setelah satu jam, atau saat tidak disetel.

@susisstrolch Bisakah Anda menguji untuk menulis file aturan yang berisi> 1800 byte?
Versi bandwidth tinggi LWIP2 merusak permintaan HTTP POST ketika ukurannya melebihi satu MTU.

Hai Gijs,
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Jika Anda melihat log, itu adalah pola, selalu terhubung, MQTT terhubung, memperbarui waktu

bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
2515788 : EVENT: WiFi#DisconnectedDisconnected! Reason: '(200) Beacon timeout' Connected for 8919 ms

setiap 10 hingga 12 detik, dilingkari seperti itu selama berjam-jam, oops

Ukuran aturan perangkat pondctrl saya: Ukuran saat ini: 1859 karakter (Maks 2048)
MTU: 534 (mem lwip 2.x rendah)
Tidak Ada Masalah - diubah beberapa kali minggu ini.

Kami saat ini menggunakan memori rendah LwIP 2.x, karena versi bandwidth tinggi memberikan masalah ini.
@Oxyandy Saya akan melihat kode mengenai pembaruan waktu dan tentu saja loop penyambungan kembali.
Topik ini menjadi lebih dan lebih sesuai topik :(

Saya tidak mengerti, yang saya kompilasi homebrew (pagi ini) sesuai permintaan Anda bekerja dengan baik ..
kemudian ketika rilis resmi tersedia, saya pikir saya lebih baik menggunakannya, saya terkejut dengan perbedaannya..
Sekarang, mengenai balasan terakhir Anda .. pembaruan waktu baik-baik saja ..
rilis resmi mulai hari ini terhubung ke wifi tidak ada masalah, menghubungkan MQTT, mendapatkan waktu, lalu memutuskan koneksi dengan "(200) Beacon timeout" lalu loop setiap 11 detik
Hubungkan - wifi, MQTT, waktu, putuskan sambungan, ulangi
Jadi jangan melihat "time update", jika tetap terhubung akan baik-baik saja ...

Itu aneh. Ada sesuatu yang sangat funky tentang proses pembuatan PlatformIO.
Saya telah memperhatikannya sendiri juga beberapa kali bahwa membangunnya untuk kedua kalinya benar-benar membuat perbedaan.
Ini seperti ada yang salah pada level linker di PlatformIO.
Sungguh aneh apa yang terjadi di sini.

itu mungkin di flag compiler atau linker. Optimasi bisa jadi menyebalkan.
Arduino IDE memiliki file konfigurasi ini (platform.txt)

# ESP8266 platform
# ------------------------------

# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification

name=ESP8266 Modules
version=2.5.0-dev

runtime.tools.xtensa-lx106-elf-gcc.path={runtime.platform.path}/tools/xtensa-lx106-elf
runtime.tools.esptool.path={runtime.platform.path}/tools/esptool

compiler.warning_flags=-w
compiler.warning_flags.none=-w
compiler.warning_flags.default=
compiler.warning_flags.more=-Wall
compiler.warning_flags.all=-Wall -Wextra

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC

build.vtable_flags=-DVTABLES_IN_FLASH

build.float=-u _printf_float -u _scanf_float
build.led=

compiler.path={runtime.tools.xtensa-lx106-elf-gcc.path}/bin/
compiler.sdk.path={runtime.platform.path}/tools/sdk
compiler.libc.path={runtime.platform.path}/tools/sdk/libc/xtensa-lx106-elf
compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

compiler.as.cmd=xtensa-lx106-elf-as

compiler.ar.cmd=xtensa-lx106-elf-ar
compiler.ar.flags=cru

compiler.elf2hex.cmd=esptool
compiler.elf2hex.flags=

compiler.size.cmd=xtensa-lx106-elf-size

compiler.esptool.cmd=esptool
compiler.esptool.cmd.windows=esptool.exe

# This can be overriden in boards.txt
build.extra_flags=-DESP8266

# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

## generate file with git version number
## needs bash, git, and echo
recipe.hooks.core.prebuild.1.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_VER 0x`git --git-dir {runtime.platform.path}/.git rev-parse --short=8 HEAD 2>/dev/null || echo ffffffff` >{build.path}/core/core_version.h"
recipe.hooks.core.prebuild.2.pattern=bash -c "mkdir -p {build.path}/core && echo \#define ARDUINO_ESP8266_GIT_DESC `cd {runtime.platform.path}; git describe --tags 2>/dev/null || echo unix-{version}` >>{build.path}/core/core_version.h"
## windows-compatible version without git
recipe.hooks.core.prebuild.1.pattern.windows=cmd.exe /c mkdir {build.path}\core & (echo #define ARDUINO_ESP8266_GIT_VER 0x00000000 & echo #define ARDUINO_ESP8266_GIT_DESC win-{version} ) > {build.path}\core\core_version.h
recipe.hooks.core.prebuild.2.pattern.windows=

## Build the app.ld linker file
recipe.hooks.linking.prelink.1.pattern="{compiler.path}{compiler.c.cmd}" -CC -E -P {build.vtable_flags} "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld.h" -o "{runtime.platform.path}/tools/sdk/ld/eagle.app.v6.common.ld"

## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.c.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpreprocessor.flags} {compiler.cpp.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.cpreprocessor.flags} {compiler.S.flags} -DF_CPU={build.f_cpu} {build.lwip_flags} {build.debug_port} {build.debug_level} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} -DARDUINO_BOARD="{build.board}" {build.led} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"

## Create archives
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/arduino.ar" "{object_file}"

## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" -Wl,-Map "-Wl,{build.path}/{build.project_name}.map" {compiler.c.elf.flags} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" -Wl,--start-group {object_files} "{build.path}/arduino.ar" {compiler.c.elf.libs} -Wl,--end-group  "-L{build.path}"

## Create eeprom
recipe.objcopy.eep.pattern=

## Create hex
#recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"

recipe.objcopy.hex.pattern="{runtime.tools.esptool.path}/{compiler.esptool.cmd}" -eo "{runtime.platform.path}/bootloaders/eboot/eboot.elf" -bo "{build.path}/{build.project_name}.bin" -bm {build.flash_mode} -bf {build.flash_freq} -bz {build.flash_size} -bs .text -bp 4096 -ec -eo "{build.path}/{build.project_name}.elf" -bs .irom0.text -bs .text -bs .data -bs .rodata -bc -ec

## Save hex
recipe.output.tmp_file={build.project_name}.bin
recipe.output.save_file={build.project_name}.{build.variant}.bin

## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.irom0\.text|\.text|\.data|\.rodata|)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.rodata|\.bss)\s+([0-9]+).*
#recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*

# ------------------------------

tools.esptool.cmd=esptool
tools.esptool.cmd.windows=esptool.exe
tools.esptool.path={runtime.platform.path}/tools/esptool
tools.esptool.network_cmd=python
tools.esptool.network_cmd.windows=python.exe

tools.esptool.upload.protocol=esp
tools.esptool.upload.params.verbose=-vv
tools.esptool.upload.params.quiet=
tools.esptool.upload.pattern="{path}/{cmd}" {upload.verbose} -cd {upload.resetmethod} -cb {upload.speed} -cp "{serial.port}" {upload.erase_cmd} -ca 0x00000 -cf "{build.path}/{build.project_name}.bin"
tools.esptool.upload.network_pattern="{network_cmd}" "{runtime.platform.path}/tools/espota.py" -i "{serial.port}" -p "{network.port}" "--auth={network.password}" -f "{build.path}/{build.project_name}.bin"

tools.mkspiffs.cmd=mkspiffs
tools.mkspiffs.cmd.windows=mkspiffs.exe
tools.mkspiffs.path={runtime.platform.path}/tools/mkspiffs

Untuk menghindari masalah dengan platformIO, saya menghapus folder .pioenvs & tetap menjalankan 'Bersih'
Sejak build pagi ini - 2 file telah berubah
ESPEasy-Globals.h & Misc.ino (Perbaiki pengaturan tugas yang rusak)

Mulai melakukan ini: struktur folder saya saat ini adalah GitHub/ESpeasy
Saya menyalin folder ESpeasy & mengganti namanya untuk memasukkan tanggal sebelum saya melakukan pengambilan, akan membantu saya membandingkan perubahan secara lokal ..

FritzBox melakukan pembaruan firmware otomatis. Semua ESP gagal ke AP Mesh alternatif tanpa masalah.

@TD-er Anda berkata, "Apakah Anda memiliki batas waktu Beacon ini dengan 0504 pada simpul apa pun, atau hanya beberapa?"
Ok untuk bersikap adil saya akan mengambil modul baru & mem-flash itu & di masa depan mem-flash 2 node setiap firmware baru.
Saya punya waktu luang karena hanya jam 4 sore di bagian dunia Anda

Ok, Node baru, terhapus.
Di-flash dengan ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Log di bawah ini memiliki perilaku yang identik dengan node lain..
Bisakah Anda melihat pola di log?

INIT : Booting version: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
104 : INIT : Cold Boot
105 : FS   : Mounting...
111 : FS   : Mount successful, used 76053 bytes of 113201
408 : CRC  : program checksum       ...OK
419 : CRC  : SecuritySettings CRC   ...OK 
420 : CRC  : binary has changed since last save of Settings
439 : INIT : Free RAM:23448
440 : INIT : I2C
440 : INIT : SPI not enabled
455 : INFO : Plugins: 47 [Normal] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
455 : EVENT: System#Wake
464 : WIFI : Set WiFi to STA
mode : sta(5c:cf:7f:72:97:2a)
add if0
497 : WIFI : Connecting MAD_MOB attempt #0
498 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
STUB: dhcp_stop
511 : EVENT: System#Boot
519 : SW   : Switch state 1 Output value 1
522 : EVENT: Float_SW#Switch=1.00
536 : ACT  : Publish domoticz/in,{"idx":26,"nvalue":0,"svalue":"FLOAT_SWITCH_1_00:00:00"}
547 : Command: publish
00:23:56: 1004 : WD   : Uptime 0 ConnectFailures 0 FreeMem 22752
00:23:59: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:01: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
5287 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 4787 ms
5293 : EVENT: WiFi#ChangedAccesspoint
5304 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
5306 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 19 ms
5324 : EVENT: WiFi#Connected
5332 : Webserver: start
5332 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
5423 : MQTT : Intentional reconnect
5424 : LoadFromFile: config.dat index: 28672 datasize: 336
5500 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
5501 : Subscribed to: domoticz/out
5502 : EVENT: MQTT#Connected
5512 : EVENT: MQTT#Connected Processing time:10 milliSeconds
5796 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
5867 : NTP  : NTP replied: 70 mSec
5869 : Current Time Zone:  DST time start: 2018-10-07 01:00:00 offset: 660 minSTD time start: 2018-08-05 01:00:00 offset: 600 min
5871 : EVENT: Time#Initialized
5879 : EVENT: Time#Initialized Processing time:8 milliSeconds
5881 : EVENT: Clock#Time=Sat,01:24
5887 : EVENT: Clock#Time=Sat,01:24 Processing time:6 milliSeconds
00:24:02: ping 1, timeout 0, total payload 32 bytes, 1023 ms
00:24:07: bcn_timout,ap_probe_send_start
00:24:09: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
14289 : EVENT: WiFi#Disconnected
14296 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9002 ms
14311 : MQTT : Connection lost
14311 : EVENT: MQTT#Disconnected
14519 : WIFI : Connecting MAD_MOB attempt #0
14520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
00:24:11: scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
16497 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 1972 ms
16499 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
16507 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
16527 : EVENT: WiFi#Connected
16533 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
16608 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
00:24:12: 16679 : NTP  : NTP replied: 70 mSec
16680 : EVENT: Time#Set
16686 : EVENT: Time#Set Processing time:6 milliSeconds
16688 : LoadFromFile: config.dat index: 28672 datasize: 336
16713 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
16714 : Subscribed to: domoticz/out
16715 : EVENT: MQTT#Connected
16724 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:14: ping 1, timeout 0, total payload 32 bytes, 2070 ms
00:24:18: bcn_timout,ap_probe_send_start
00:24:21: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
25349 : EVENT: WiFi#Disconnected
25356 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 8852 ms
25371 : MQTT : Connection lost
25371 : EVENT: MQTT#Disconnected
25519 : WIFI : Connecting MAD_MOB attempt #0
25520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
25683 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 158 ms
25686 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
25694 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
25714 : EVENT: WiFi#Connected
25721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
25815 : LoadFromFile: config.dat index: 28672 datasize: 336
25836 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
25838 : Subscribed to: domoticz/out
25838 : EVENT: MQTT#Connected
25845 : EVENT: MQTT#Connected Processing time:7 milliSeconds
00:24:22: 26585 : NTP  : NTP host au.pool.ntp.org (27.124.125.251) queried
26656 : NTP  : NTP replied: 70 mSec
26657 : EVENT: Time#Set
26663 : EVENT: Time#Set Processing time:6 milliSeconds
ping 1, timeout 0, total payload 32 bytes, 1010 ms
00:24:26: 31005 : WD   : Uptime 1 ConnectFailures 4 FreeMem 19304
00:24:28: bcn_timout,ap_probe_send_start
00:24:30: ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
35077 : EVENT: WiFi#Disconnected
35083 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 9394 ms
35094 : MQTT : Connection lost
35095 : EVENT: MQTT#Disconnected
35519 : WIFI : Connecting MAD_MOB attempt #0
35520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
35685 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 160 ms
35687 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
35696 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 11 ms
35715 : EVENT: WiFi#Connected
35721 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
35816 : LoadFromFile: config.dat index: 28672 datasize: 336
35844 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
35845 : Subscribed to: domoticz/out
35846 : EVENT: MQTT#Connected
35855 : EVENT: MQTT#Connected Processing time:9 milliSeconds
00:24:32: 36735 : NTP  : NTP host au.pool.ntp.org (144.48.166.166) queried
ping 1, timeout 0, total payload 32 bytes, 1016 ms
37739 : NTP  : No reply
00:24:39: bcn_timout,ap_probe_send_start
00:24:41: pm open,type:2 0
ap_probe_send over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7
46238 : EVENT: WiFi#Disconnected
46244 : WIFI : Disconnected! Reason: '(200) Beacon timeout' Connected for 10 s
46260 : MQTT : Connection lost
46261 : EVENT: MQTT#Disconnected
46519 : WIFI : Connecting MAD_MOB attempt #0
46520 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 
00:24:42: 
connected with MAD_MOB, channel 7
ip:192.168.0.225,mask:255.255.255.0,gw:192.168.0.254
46679 : WIFI : Connected! AP: MAD_MOB (18:90:D8:AC:0F:D8) Ch: 7 Duration: 154 ms
46681 : IP   : Static IP : 192.168.0.225 GW: 192.168.0.254 SN: 255.255.255.0 DNS: 8.8.8.8
46689 : WIFI : Static IP: 192.168.0.225 (ESP-Easy-0) GW: 192.168.0.254 SN: 255.255.255.0   duration: 10 ms
46709 : EVENT: WiFi#Connected
46715 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
46809 : LoadFromFile: config.dat index: 28672 datasize: 336
46843 : MQTT : Connected to broker with client ID: ESPClient_5C:CF:7F:72:97:2A
46844 : Subscribed to: domoticz/out
46845 : EVENT: MQTT#Connected
46851 : EVENT: MQTT#Connected Processing time:6 milliSeconds

Ah saya kira sudah waktunya saya menyiapkan titik akses khusus yang menjalankan wireshark

Menggunakan GitHub Desktop, saya mengambil sumber 'langsung' terbaru yang hanya mencakup 2 file yang diubah dari https://github.com/letscontrolit/ESPEasy/commit/92680c5542b76a15db16af198a3a07ed17618c4e sejak kompilasi kerja saya mulai pagi ini, membuat versi malam & berfungsi dengan sempurna ..
Mengapa build malam berbeda jika sumbernya sama, apa yang terjadi berbeda di GitHub ?

Adakah yang menggunakan Arduino IDE?
Apakah Anda dapat membuat "ESP8266 normal 1024" dari src saat ini dan membuangnya di sini?
Terima kasih

tidak yakin apakah ini terkait dengan beberapa masalah acak yang kami lihat, tetapi saya perhatikan, bahwa setelah beberapa waktu, unit saya berhenti mengirim data ke pengontrol. Namun antarmuka web masih aktif dan berjalan, tetapi t menunjukkan Alamat IP 0.0.0.0. (lihat tangkapan layar). Ada orang lain yang melihat ini?

untitled

image

Ini versi build apa?

@Oxyandy

Mengapa build malam berbeda jika sumbernya sama, apa yang terjadi berbeda di GitHub ?

Itu juga yang saya herankan.
Saya kira itu ada hubungannya dengan fakta kita juga harus membangunnya dua kali kadang-kadang ketika membangunnya sendiri.
Sepertinya ada yang salah dengan cara kami mengkompilasi sesuatu, atau dengan kompilernya.
Itu mungkin juga menjelaskan mengapa kita melihat begitu banyak hal yang sangat sulit, jika bukan tidak mungkin, untuk direproduksi dalam beberapa minggu terakhir.

Saya mendiskusikan ini juga dengan @arendst dari Tasmota, dan dia mengonfirmasi bahwa dia juga harus membangun kembali sesekali untuk mendapatkan versi yang berfungsi dengan baik.
Saya akan bertanya kepada @psy0rz apakah mungkin untuk membuat build malam dua kali sebagai ujian.

dikompilasi sendiri dari mega-20180503
Bangun | 20102 - Mega
Perpustakaan | ESP82xx Inti 76a14b1f, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3

Bisakah Anda mencoba membangunnya dua kali, sebelum menulisnya ke simpul?
Tidak ada pembersihan antar build, cukup build dan build lagi.

tentu, tapi saya menggunakan Arduino SDK di mac, bukan platformIO... masih patut dicoba?

Ya silakan, karena kami belum tahu apa penyebabnya.
Pastikan Anda menggunakan pustaka inti yang sama seperti yang kami lakukan, karena Arduino IDE tidak melihat versi tetap yang disetel di PlatformIO.
Versi saat ini yang kami gunakan adalah:
ESP82xx Inti 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3

ok, saya akan mencobanya sekarang dan mem-flash beberapa unit. Saya akan melaporkan segera setelah sesuatu terjadi... atau tidak sama sekali;)

OMONG-OMONG. build saat ini dapat macet kapan saja dengan terus menekan F5 di browser web setidaknya di halaman Perangkat atau Pemberitahuan (mungkin di halaman web ESP mana pun) selama beberapa detik. Saya dapat mengulanginya kapan saja dari Firefox di Win10:
...
...
39543696 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39551825 : LoadFromFile: config.dat indeks: 27648 ukuran data: 320
39557599 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39566681 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39566879 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39567105 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39567490 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39567690 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39567883 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39568086 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39568287 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39568495 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39568701 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39568910 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39569112 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39569324 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39569530 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39569739 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39569948 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39570158 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39570366 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39570582 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
39570742 : Halaman web dilewati: memori rendah: 1784
39570832 : Halaman web dilewati: memori rendah: 1784
39570906 : Halaman web dilewati: memori rendah: 1784
39570992 : Halaman web dilewati: memori rendah: 1784
39571074 : Halaman web dilewati: memori rendah: 1784
39571161 : Halaman web dilewati: memori rendah: 1784
39571240 : Halaman web dilewati: memori rendah: 1784
39571322 : Halaman web dilewati: memori rendah: 1784
39571401 : Halaman web dilewati: memori rendah: 1784

Pengecualian (28):
epc1=0x4025cb66 epc2=0x00000000 epc3=0x401003f2 excvaddr=0x00000000 depc=0x00000000

ctx: lanjutan
sp: 3fff4690 akhir: 3fff4b20 offset: 01a0

tumpukan>>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 00000043 4021ada8
3fff4860: 00000000 00000000 00000000 000006c0
3fff4870: 000006f8 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fffbfdc
3fff48c0: 0000000f 0000000b 3fff815c 0000000f
3fff48d0: 00000000 3fffb8a4 0000025f 0000025c
3fff48e0: 00000001 3fff16d4 3fff6294 40227cb4
3fff48f0: 3fffb414 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000855 00000855 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff5d14 3fff5d14 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff5d14 40257abb
3fff4940: 00000000 00000010 3fff5d14 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff6294 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff1868 4028577b
3fff4990: 4025653c 00000001 3fff1868 40253308
3fff49a0: 3fff4d6c 00000c35 00000c35 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff6294 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff6294 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 3fff4d6c 00000112 3fff6294 402532fe
3fff4a20: 3fff6294 3fff366c 3fff6294 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff6294 3fff366c 3fff3628 402533c1
3fff4a50: 3fff5afc 0000000f 00000008 00000000
3fff4a60: 00000000 3fff4ab0 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 000000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff7b4c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff7b4c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: feefeffe feefeffe 3fff3b00 40100700
<<

ets 8 Jan 2013, penyebab pertama

muat 0x4010f000, len 1384, kamar 16
ekor 8
chksum 0x2d
csum 0x2d
v614f7c32
~ld
U88 :

INIT : Versi boot: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Boot hangat #3
90 : FS : Memasang...
115 : FS : Mount berhasil, menggunakan 75802 byte 957314
437 : CRC : program checksum ...OK
469 : CRC : Pengaturan Keamanan CRC ...OK
575 : INIT : RAM Gratis
575 : INIT : I2C
575 : INIT : SPI tidak diaktifkan
1677 : INFO : Plugin: 72 [Normal] [Pengujian] [Pengembangan] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
1678 : ACARA: Sistem#Bangun
1682 : WIFI : Setel WiFi ke STA
...
...

Perangkat kemudian terhubung ke AP dengan sukses. Kecelakaan lain:

973 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
279178 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
279387 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
279590 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
279798 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
280321 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
280558 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
280785 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
Pengecualian fatal 28 (LoadProhibited Cause):
epc1=0x4025cb66, epc2=0x00000000, epc3=0x40100408, excvaddr=0x00000000, depc=0x00000000

Pengecualian (28):
epc1=0x4025cb66 epc2=0x00000000 epc3=0x40100408 excvaddr=0x00000000 depc=0x00000000

ctx: lanjutan
sp: 3fff4690 akhir: 3fff4b20 offset: 01a0

tumpukan>>>
3fff4830: 00000000 3ffe90c0 3fff48a4 40253308
3fff4840: 00000000 3ffe90c0 3fff48d4 40257c32
3fff4850: 00000000 3ffe90c0 0000002f 4021ada8
3fff4860: 00000000 00000000 00000000 000007e8
3fff4870: 00000820 00000000 00000000 00000000
3fff4880: 00000000 00000000 00000000 40107b18
3fff4890: 00000000 000003e8 3fff48f0 00000000
3fff48a0: 00000000 00000000 00000000 00000000
3fff48b0: 4029cdfc 00000007 3fff48f0 3fff9af4
3fff48c0: 0000000f 0000000b 3fff9adc 0000000f
3fff48d0: 00000004 3fffb7bc 0000025f 00000130
3fff48e0: 00000001 3fff16d4 3fff773c 40227cb4
3fff48f0: 3fff83ac 0000000f 00000007 4010053d
3fff4900: 3fff4d6c 00000a67 00000a67 3fff4d6c
3fff4910: 00000010 00000010 00000000 3fff36d4
3fff4920: 00000010 3fff9014 3fff9014 40257a6f
3fff4930: 3ffe8ea1 00000000 3fff9014 40257abb
3fff4940: 00000000 00000010 3fff9014 3fff4d6c
3fff4950: 40107b70 ffffffff 00000000 40253308
3fff4960: 3fff3a14 00000001 3fff773c 4022fc8d
3fff4970: 00000010 3fff49e0 3ffe8ea1 40207ae8
3fff4980: 00000000 3fff49e0 3fff185c 4028577b
3fff4990: 4025653c 00000001 3fff185c 40253308
3fff49a0: 3fff4d6c 00000628 00000628 4010020c
3fff49b0: 00000001 00000001 3fff49e0 40107b70
3fff49c0: ffffffff 40107b70 00000000 40257a14
3fff49d0: 4020a8ca 00000001 3fff773c 4022fd96
3fff49e0: 00000000 00000000 00000000 40253308
3fff49f0: 00000001 00000001 3fff773c 4022fe80
3fff4a00: 00000001 00000001 3fff4a30 40259cfa
3fff4a10: 00000000 00000000 3fff773c 402532fe
3fff4a20: 3fff773c 3fff366c 3fff773c 4025333a
3fff4a30: 00000000 00000000 00000000 40257c18
3fff4a40: 3fff773c 3fff366c 3fff3628 402533c1
3fff4a50: 3fff9594 0000000f 00000008 00000000
3fff4a60: 00000000 00000000 3fff362c 4024ca28
3fff4a70: 3fff366c 00000001 00000000 4024d200
3fff4a80: 000000001 00000000 40251b18 0000000d
3fff4a90: 00000000 3fff9b0c 3fff3628 3fff3af4
3fff4aa0: 00000001 3fff3650 3fff3628 40253618
3fff4ab0: 40107910 00000000 00001388 3fff3b00
3fff4ac0: 00000000 3fff9b0c 00000000 40256abd
3fff4ad0: 3fffdad0 00000000 3fff1944 4023742a
3fff4ae0: 3fffdad0 00000000 3fff19c4 40240380
3fff4af0: 00000000 00000000 00000001 40258a31
3fff4b00: 3fffdad0 00000000 3fff3aee 40258a5c
3fff4b10: feefeffe feefeffe 3fff3b00 40100700
<<

ets 8 Jan 2013, penyebab pertama

muat 0x4010f000, len 1384, kamar 16
ekor 8
chksum 0x2d
csum 0x2d
v614f7c32
~ld
U89 :

INIT : Versi boot: mega-20180504 (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
89 : INIT : Boot hangat #8
91 : FS : Memasang...
116 : FS : Mount berhasil, menggunakan 75802 byte 957314
438 : CRC : program checksum ...OK
469 : CRC : Pengaturan Keamanan CRC ...OK
575 : INIT : RAM Gratis
576 : INIT : I2C
576 : INIT : SPI tidak diaktifkan
1678 : INFO : Plugin: 72 [Normal] [Pengujian] [Pengembangan] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
1678 : ACARA: Sistem#Bangun
1683 : WIFI : Setel WiFi ke STA
...

Nah itu dengan 72 plugin, bagaimana dengan normal apakah itu berperilaku sama ;)

Itu normal jika Anda membanjiri tumpukan IP dengan permintaan. Satu-satunya hal yang membantu adalah melayani Webserver lebih sering sehingga buffer masuk dibebaskan lagi.

Setidaknya itu baik yang dapat dipulihkan - hang total akan lebih buruk daripada reboot ... Tapi aneh bahwa penyebab boot tidak sama setiap saat - saya juga melihat penyebab 4.

ESP_Easy_mega-20180504_test_ESP8266_1024.bin
Saya bisa mendapatkan wifi untuk terhubung (percobaan pertama) dan tetap terhubung
F5 (Halaman perangkat) tidak menyebabkan kesalahan atau crash
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Terhubung dan gagal dalam siklus 11 detik berulang-ulang - (200) Batas waktu suar
ESP_Easy_mega-20180504_normal_ESP8266_1024_(Self_Compiled).bin
Sempurna

@Oxyandy Pengulangan otomatis keyboard lambat? ;-)
Milik saya mogok di setiap halaman web yang saya coba.

@ghtester Saya akan membuat satu set di PC saya, dengan semua kode saat ini. Akan memakan waktu sekitar 30 menit untuk membangun.

@TD-er Terima kasih banyak atas usaha Anda, saya akan mengujinya saat build baru sudah siap.

@TD-er mem-flash unit saya (16) sekarang dengan ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3 dibuat dua kali sebelum mem-flash... Saya akan melihat besok jika mereka masih hidup dan mengirim data... Saya harus mengambil bandwidth tinggi lwIP2 jika tidak, data yang dikirim melalui FHEM-Controller akan terpotong!
tapi perlu tidur sekarang.... n8

Waspadai masalah HTTP POST dengan versi bandwidth tinggi.

Build saya sekarang berjalan untuk ketiga kalinya (memiliki beberapa masalah ESP32 yang perlu diperbaiki dan ingin memastikan hanya penautan yang dilakukan di build terakhir)
Jadi akan ada file zip dalam beberapa menit.
Lalu aku pergi tidur juga.

TD-er, build Anda, perangkat keras saya, tidak ada masalah dengan (normal 1024 8266)
Menunggu build harian untuk ditampilkan akan mencobanya selanjutnya;)

@TD-er Terima kasih banyak, dengan cepat menguji rilis dev 4096 (untuk dilanjutkan), masalah reboot "F5" masih ada (percobaan pertama menggantung perangkat sepenuhnya) dan info firmware mengatakan pemeriksaan MD5 gagal (saya kira itu karena bangunan uji). Namun demikian, semuanya baik-baik saja sejauh ini dan terhubung dengan sempurna dan cepat ke AP.


Bangun 20102 - Mega
Perpustakaan ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3
versi GIT
Plugin 72 [Normal] [Pengujian] [Pengembangan]
Bangun Md5 4d44355f4d44355f4d44355f4d44355f
Pemeriksaan Md5 gagal!
Waktu pembuatan 5 Mei 2018 00:33:21
Nama file biner ThisIsTheDummyPlaceHolderForTheBinaryFilename...

Seperti yang dibangun dan dirilis di GitHub kedua BIN ini, terpisah 1 hari (1 Build).
ESP_Easy_mega-20180504_normal_ESP8266_1024.bin
Dikonfirmasi 'salah' dengan berbagai cara, mengatur ulang, node yang berbeda, dll
masalah konsisten (201 Beacon Timeout) dalam loop 11 detik
Homebrew bekerja dengan sempurna dari sumber yang sama.
ke
ESP_Easy_mega-20180505_normal_ESP8266_1024.bin
Bekerja dengan sempurna, perubahan sumber menjadi minimal
memberitahu saya, rilis GitHub mengalami kegagalan 'di suatu tempat' dalam kompilasi..
Terhubung ke Wifi percobaan pertama, pembaruan waktu instan, tidak menjatuhkan Wifi sekali pun,
MQTT mempertahankan koneksi
dll dll -
tidak ada yang salah ;)

Jadi ini berarti banyak waktu yang dihabiskan beberapa minggu terakhir (???) mungkin karena masalah kompilasi?
Sangat disayangkan, tetapi setidaknya memberi saya kepercayaan diri bahwa saya tidak kehilangan akal, dalam melihat semua jenis masalah dilaporkan yang tidak dapat saya ulangi atau jelaskan.

Adapun masalah f5: coba lwip bandwidth tinggi karena memiliki buffer yang lebih besar. Ini mungkin crash sedikit kemudian.

Masalah kompilasi: Anda menjalankan pada 80 MHz, bukan?

80 MHz adalah default saya kira.

Aku tahu. Tetapi menyetelnya ke 160 dapat menyebabkan perilaku aneh.

Ya, masalah "F5" adalah satu-satunya masalah serius yang saya lihat sejauh ini dalam build khusus ini. Bahkan jika saya menekannya dengan cepat beberapa kali untuk me-refresh halaman web ESP, itu membuat masalah:

18084332 : ACARA: Jam#Waktu=Sab,08:47 Waktu pemrosesan
18091174 : WD : Uptime 302 ConnectFailures 0 FreeMem 14504
bcn_timout,ap_probe_send_start
18112119 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18115167 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18116976 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18119084 : LoadFromFile: indeks notifikasi.dat: 0 ukuran data: 996
18119089 : LoadFromFile: indeks notifikasi.dat: 1024 ukuran data: 996
18119092 : LoadFromFile: notification.dat index: 2048 ukuran data: 996
18119129 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18121330 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18121337 : WD : Uptime 302 ConnectFailures 0 FreeMem 13584
18128862 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18130833 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18135120 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18136605 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18138356 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18140067 : LoadFromFile: indeks notifikasi.dat: 0 ukuran data: 996
18140076 : LoadFromFile: indeks notifikasi.dat: 1024 ukuran data: 996
18140078 : LoadFromFile: indeks notifikasi.dat: 2048 ukuran data: 996
18140152 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18144694 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18144700 : ACARA: Jam#Waktu=Sab,08:48
18144702 : ACARA: Jam#Waktu=Sab,08:48 Waktu pemrosesan
18148558 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18151336 : WD : Uptime 303 ConnectFailures 0 FreeMem 12568
18153230 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18153763 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18155000 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18155592 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18156416 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18156838 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18164949 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18165234 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18165587 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18170770 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18170947 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18171120 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18171300 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18171733 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18177686 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
bcn_timout,ap_probe_send_start
18181336 : WD : Uptime 303 ConnectFailures 0 FreeMem 10832
18182865 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18183367 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18188878 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18190025 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18203237 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18203809 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18203817 : ACARA: Jam#Waktu=Sab,08:49
18203819 : ACARA: Jam#Waktu=Sab,08:49 Waktu pemrosesan
bcn_timout,ap_probe_send_start
bcn_timout,ap_probe_send_start
bcn_timout,ap_probe_send_start
18496844 : Penggunaan Ram: Hanya server web: 0 termasuk Core: 0
18496850 : WD : Uptime 304 ConnectFailures 0 FreeMem 8736
18496856 : ACARA: Jam#Waktu=Sab,08:53
18496858 : ACARA: Jam#Waktu=Sab,08:53 Waktu pemrosesan

Setelah tiga pesan bcn_timout,ap_probe_send_start terakhir

Ya itu berjalan pada 80 MHz - Info Sistem mengatakan: ESP Chip Freq: 80 MHz

Respons web ESP sangat cepat sampai saya mencoba me-refresh terlalu cepat...

pagi semua ... unit saya berjalan stabil selama sekitar 10 jam sekarang. namun masalah terkadang muncul hanya setelah satu atau dua hari, jadi saya membiarkannya berjalan seperti ini. satu unit reboot dua kali pada malam hari (dari 16 D1) yang mungkin terkait dengan plugin atau lebih... dasar-dasar sonoff juga berjalan dengan lancar.

Saya tahu Anda tidak dapat melihat atau menjelaskan TD-er, tetapi apakah Anda menggunakan build GitHub sebagai ujian?
Saya mungkin akan kembali ke sumber untuk rilis dalam sebulan terakhir dan membandingkan vs. homebrew
Saya punya banyak yang saya anggap tidak berguna, salah satu tab saya di Notepad++ memiliki daftarnya

Tentang F5, sebenarnya bukan masalah - saya menggunakannya sebagai benchmark, saya tidak memiliki auto-refresh untuk kunci F5,
jadi saya menekannya secara manual, menonton penggunaan RAM dan output log serial pada saat yang bersamaan..
"lwip bandwidth tinggi" dari memori hampir instan
LmacRxBlk:1 kesalahan dan tidak dapat dipulihkan..
Yang mengingatkan saya bahwa saya dimaksudkan untuk menulis sesuatu tentang .. pada daftar yang harus dilakukan ..
Dan saya akan mencoba pengaturan kompilasi yang berbeda lagi sebagai ukuran

Hmm, saya tidak tahu apakah alasannya adalah saya mengkonfigurasi tampilan LCD di posisi 12 tetapi segera setelah itu saya kehilangan koneksi ke AP dan tidak dapat menyambung kembali lagi (Tidak ada AP yang ditemukan meskipun terlihat oleh wifiscan). Setelah reboot masalah yang sama. Kemudian perangkat memasuki mode AP tetapi mungkin karena garis bawah pada nama SSID dikatakan:

1127917 : WIFI : Error saat memulai Mode AP dengan SSID: ESP_01_1 IP: 192.168.4.1

Tetapi perangkat itu terlihat sebagai AI-THINKER_XXXXXXX, saya dapat menghubungkannya tetapi ketika saya mencoba mengubah nama perangkat dll. Saya mengalami kehilangan koneksi ke perangkat, crash & reboot dll ... :-(

Perbarui - setelah beberapa upaya saya mengganti nama perangkat untuk menghapus garis bawah, tetapi masih ada sebelum nomor perangkat:
599417 : WIFI : Error saat memulai Mode AP dengan SSID: ESP-001_1 IP: 192.168.4.1
Dan perangkat masih terlihat sebagai AI-THINKER_XXXXXXX
tidak dapat terhubung ke AP saya sebagai klien lagi... Saya akan mencoba mengatur ulang pengaturan pabrik...

Update2 OK... Reset pabrik, perangkat terlihat sebagai AP ESP_Easy_0... Setel WifiSSID dan WifiKey melalui konsol serial, perangkat langsung terhubung ke AP...

sebagian besar unit saya masih berjalan dengan baik ... namun saya tidak benar-benar berpikir ini masalah kompilasi dua kali ... satu-satunya perbedaan adalah, beberapa perpustakaan hanya dikompilasi pertama kali, kemudian setelah itu, ketika SDK melihat bahwa mereka tidak mengubahnya tidak akan mengkompilasi ulang ...

satu hal lain yang akan saya coba sekarang adalah alih-alih menentukan papan "D1 Mini" di arduino, saya mengatur semua parameter sendiri dan menggunakan modul "generic 8266" ... kita akan melihat apakah ini membuat perbedaan ...

saat ini satu-satunya hal yang saya lihat adalah beberapa reboot spontan dari unit tertentu ... tapi ini bisa terkait dengan hal lain ...

satu pertanyaan dari saya: sonoff basic hanya memiliki memori 1M ... adakah kesempatan untuk memperbarui hal-hal ini secara OTA? itu jelas selalu mengklaim "memori tidak cukup"... ada ide?

PS: tentang masalah kompilasi, saya selalu menggunakan binari yang dikompilasi sendiri (plugin lain) sejak awal, dan memiliki masalah stabilitas "sama" ... ..

Anda dapat menggunakan lebih sedikit plugin saat kompilasi. Lihat https://github.com/letscontrolit/ESPEasy/blob/mega/src/define_plugin_sets.h

Anda tidak akan pernah bisa OTA secara langsung, tetapi cara ini setidaknya cukup kecil untuk OTA dalam dua tahap. Lihat wiki untuk yang itu :)

itulah yang saya lakukan ... itu sebabnya saya selalu mengkompilasi sendiri ... tetapi bahkan dengan hanya 2 plugin yang diaktifkan, sketsa menggunakan 500k ...
itu sebabnya saya mencari solusi yang berbeda (mis. tidak ada antarmuka web ... dll.)..

500k cukup kecil. Seperti yang saya katakan, dua bagian OTA. Anda tidak dapat memperbarui secara langsung. lihat wikinya :)

thx.. mencari.... ;)

tambahkan: entah bagaimana saya melewatkan bagian dua langkah ....

Dengan 1M Sonoffs, Anda harus menggunakan Pengunggah Awal yang memiliki tanda DOUT di header,
dari memori yang ada di Wiki tidak, tetapi mungkin telah diperbarui baru-baru ini..

Saya ingat sesuatu seperti itu, Baru saja mencari saya menggunakan yang ini untuk OTA: https://github.com/soif/EspBuddy/blob/master/firmwares/ESPEasyUploader.OTA.1m128.esp8266.bin

Ya, diperiksa itu DOUT
Ini yang saya kumpulkan lebih kecil
Initial_Firmware_Uploader_Sonoff_1M_DOUT.zip

Aku bilang aku akan melakukannya karena aku sangat penasaran........
Sebagai perbandingan dengan Self_Compiled mega-20180422 dengan GitHub yang dirilis, sejauh ini - saya hanya mencoba satu
ESP_Easy_mega-20180422_normal_ESP8266_1024.bin
Saya meninggalkan komentar dan mencatat perilakunya di sini https://github.com/letscontrolit/ESPEasy/issues/1301#issuecomment -383433822 (GitHub dirilis)
Sumber yang sama dikompilasi sendiri, tidak mengherankan, saya melihat perilaku yang berbeda dengan Nightly.
Itu tetap terhubung, kejutan horor!
GitHub merilis mega-20180422, melintas di atas, perilaku yang sama persis seperti yang saya laporkan ketika saya pertama kali mencobanya.
Tidak akan tetap terhubung, WIFI : Disconnected! Reason: '(200) Beacon timeout' bersepeda berulang-ulang
Penyebabnya perlu diselidiki ... menghela nafas
GitHub dirilis = tidak bisa dipercaya ?

Saya memposting flag compiler Arduino kemarin atau lebih. Bendera apa yang digunakan Travis?

Saya memiliki 16 D1 dan 3 basic yang berjalan pada f69e476 yang dikompilasi sendiri, Core 2.4.1, bandwidth tinggi lwIP2.
Hampir semuanya dengan uptime >900Min. sekarang dan masih berfungsi dengan baik. 2 dari mereka beralih ke mode AP sekitar satu jam yang lalu dan tidak terhubung kembali sampai sekarang. Saya akan menunggu sampai malam ini dan melihat apakah mereka pulih.

sayangnya perilakunya tidak benar-benar dapat direproduksi, dan saya tidak dapat memberikan bukti apa pun di mana masalah itu muncul, tetapi saya akan terus mencari kekurangan dan melaporkannya jika saya menemukan sesuatu ...

@Oxyandy : Saya juga mengkompilasi ulang unggahan agar basic saya berfungsi dengan baik! terima kasih lagi untuk menunjukkan saya ke arah yang benar .. ;)

@s0170071
Mereka disimpan di .travis.yml & platformio.ini
Saya mempercepat membaca, tada, lihat apa yang saya temukan
skip_cleanup: true
Sunting: Bacaan lebih lanjut Saya tidak yakin apakah ini mengacu pada membuat build yang bersih ?
Saya akui semuanya baru bagi saya... ??? Menonaktifkan Caching?

Travis melakukan pembangunan bersih setiap saat, karena ia bahkan mengunduh lingkungan python, dll.

Pembuatan malam dilakukan oleh @psy0rz , bukan oleh Travis

Okee dokee, jadi apakah mereka bersih?
Mencoba memahami mengapa mereka berperilaku berbeda?

Bagaimana dengan membandingkan MD5 dari bin1 dan bin2?
Ini akan menunjukkan Jika itu Masalah waktu kompilasi atau runtime ...

@susisstrolch maksud Anda ketika Anda mengkompilasi sendiri? Itu karena MD5 dihitung setelah kompilasi. Ada skrip yang melakukannya untuk Anda.
https://github.com/s0170071/CRC4ESP

-edit: @susisstrolch saya mungkin salah
ya, Anda dapat membandingkan md5, mereka harus identik. Jika Anda melakukannya secara offline, Anda juga bisa membandingkan binari sedikit demi sedikit. Dengan cara ini Anda bahkan dapat mengetahui di mana penyimpangannya. Jika Anda mahir, Anda bahkan dapat melacaknya kembali ke kode. File .elf harus memiliki semua info.

Lagi pula, saya tidak terlalu peduli tentang apa yang sebenarnya berbeda. Saya pikir lebih penting untuk memastikan semuanya pada biner yang sama - tidak peduli siapa yang menyusunnya.

Jadi sekali lagi, apa flag kompilasi untuk Arduino, platformio, nightly, dan travis? Menang / Linux,.

TIDAK - Maksud saya, alih-alih berspekulasi tentang perbedaan output kompiler dalam build otomatis, cukup bandingkan MD5 dari kedua build. Jadi Anda bisa tahu persis jika mereka berbeda.

Flag untuk Arduino IDE di linux adalah:

build.lwip_lib=-llwip_gcc
build.lwip_include=lwip/include
build.lwip_flags=-DLWIP_OPEN_SRC
build.vtable_flags=-DVTABLES_IN_FLASH
build.float=-u _printf_float -u _scanf_float


compiler.cpreprocessor.flags=-D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ "-I{compiler.sdk.path}/include" "-I{compiler.sdk.path}/{build.lwip_include}" "-I{compiler.libc.path}/include" "-I{build.path}/core"

compiler.c.cmd=xtensa-lx106-elf-gcc
compiler.c.flags=-c {compiler.warning_flags} -Os -g -Wpointer-arith -Wno-implicit-function-declaration -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals -falign-functions=4 -MMD -std=gnu99 -ffunction-sections -fdata-sections

compiler.S.cmd=xtensa-lx106-elf-gcc
compiler.S.flags=-c -g -x assembler-with-cpp -MMD -mlongcalls

compiler.c.elf.flags=-g {compiler.warning_flags} -Os -nostdlib -Wl,--no-check-sections -u app_entry {build.float} -Wl,-static "-L{compiler.sdk.path}/lib" "-L{compiler.sdk.path}/ld" "-L{compiler.libc.path}/lib" "-T{build.flash_ld}" -Wl,--gc-sections -Wl,-wrap,system_restart_local -Wl,-wrap,spi_flash_read

compiler.c.elf.cmd=xtensa-lx106-elf-gcc
compiler.c.elf.libs=-lhal -lphy -lpp -lnet80211 {build.lwip_lib} -lwpa -lcrypto -lmain -lwps -laxtls -lespnow -lsmartconfig -lairkiss -lwpa2 -lstdc++ -lm -lc -lgcc

compiler.cpp.cmd=xtensa-lx106-elf-g++
compiler.cpp.flags=-c {compiler.warning_flags} -Os -g -mlongcalls -mtext-section-literals -fno-exceptions -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections

@s0170071 Saya mencoba bertanya kepada Edwin, tetapi dia belum menjawab.
Jadi untuk saat ini, kami tidak tahu persis apa yang sedang dilakukan untuk pembangunan malam.
Dan masih ada perilaku aneh (yang saya alami juga pada pengaturan saya) yang mengkompilasinya dua kali memberikan hasil yang berbeda.
Binari antar build tidak dapat dibandingkan melalui checksum. Ada stempel waktu build yang disertakan, yang akan berbeda untuk build apa pun. Jadi kompilasi sumber yang sama 100 kali akan memberikan 100 checksum yang berbeda.
Tetapi setidaknya itu harus memberikan fungsionalitas yang sama dan itu tampaknya tidak terjadi (kadang-kadang) antara build pertama dan kedua. Dan _itu_ tidak seharusnya.

Jadi, untuk tujuan pengujian dan untuk menyelesaikannya, saya akan melewatkan pengaturan semua perubahan prakompilasi antara kompilasi yang berurutan untuk mendapatkan src yang sebanding.

@s0170071 jadi kami mendapatkan banyak informasi debug karena opsi -g saat membangun dengan Arduino IDE.
Mungkin titik untuk mengurangi ukuran ...

Pengurangan ukuran adalah sesuatu yang harus kita perhatikan di masa mendatang, tetapi Anda harus berhati-hati saat mengganti tanda pengoptimalan. Beberapa mungkin menyebabkan lebih sulit untuk mereproduksi masalah.

keduanya belum pulih beberapa jam kemudian di siang hari, tetapi yang lain gagal secara acak ... dua hal yang saya temukan sampai sekarang:
Saya mendapatkan entri di log yang mengatakan:
96493069 : IP diblokir: 0.0.0.0 Diizinkan: 10.0.0.0 - 10.0.255.255
96517068 : WD : Waktu Aktif 1608 ConnectFailures 0 FreeMem 11544
baris pertama tampak aneh bagi saya, apa yang mencoba terhubung dengan IP 0.0.0.0? ini mungkin terkait dengan masalah yang saya lihat beberapa hari yang lalu, bahwa unit dapat dijangkau, tetapi ia memberi tahu saya bahwa ia memiliki IP 0.0.0.0.

hal kedua, meskipun tidak ada yang dilakukan selama 24 jam terakhir saya melihat lompatan tiba-tiba dalam beban CPU, bahkan di unit "kecil", yang hanya menggunakan fungsionalitas sakelar (mis. Nr. 7 pada grafik terlampir).

Adakah kesempatan untuk mencari tahu, mengapa perubahan mendadak pada beban CPU ini terjadi? log tidak mengatakan apa-apa spesifik .. (CPU Load dari hari ini dan kemarin) ...
image
image

Apakah beban CPU de melompat pada saat reboot?
Cara menghitung beban CPU agak aneh.
Dibutuhkan berapa kali fungsi loop utama dijalankan dalam 30 detik.
Ini dibandingkan dengan jumlah maksimum yang diamati.
Ini berarti bahwa selama operasi jumlah maksimum yang diamati dapat meningkat, tetapi juga dapat tiba-tiba berkurang setelah reboot.

tidak, tidak saat reboot ... hanya "secara acak" di beberapa titik ... menariknya itu terjadi pada beberapa unit sekaligus ... Saya tidak tahu apa yang terjadi di sana (saat itu tidak ada di rumah) ... terutama unit 12- 14 benar-benar papan biasa tanpa tugas kecuali rssi, memuat, uptime dan mem... juga grafik memori tidak menunjukkan tanda-tanda perubahan yang signifikan...
masih sekarang, memuat pada beberapa unit menunjukkan ~ 50% tetapi antarmuka web cepat ..

saya juga memiliki satu unit jam tangan yang digerakkan nfx yang mengubah posisi jarum setiap detik. menariknya jam berhenti pada satu titik waktu, tetapi unit terus bekerja tanpa masalah ... seperti tugas ini tidak berjalan lagi ... tetapi ini bisa terkait dengan plugin (karena ini adalah salah satu playgound) .. tapi bisa mungkin menunjuk ke masalah ...

tapi seperti yang saya katakan, saat ini saya benar-benar tidak tahu dari mana semua masalah ini berasal.. benar-benar hanya mengaduk-aduk mencoba menemukan sesuatu.... dan memberikan umpan balik kepada semua orang untuk bertukar pikiran....

anyways, terima kasih banyak atas usaha dan bantuan Anda ... jika saya menemukan sesuatu yang masuk akal saya akan melaporkan ...

Itu juga bisa berarti semua beberapa layanan mengubah ketersediaan pada suatu saat.
Entah itu menjadi tersedia yang menyebabkan node benar-benar melakukan lebih banyak pekerjaan.
Atau sudah tidak tersedia. ESPeasy mencoba melakukan ping ke host untuk mendeteksi ketersediaannya. Jika ping itu gagal, itu akan menghentikan node selama periode waktu habis.

bagaimana "ping" itu dilakukan? karena saya melihat beberapa "host tidak dikenal" dari waktu ke waktu... mungkinkah, batas waktu ini cukup besar? atau pencarian DNS ord ping harus timeout singkat? sebenarnya saya tidak menggunakan FQDN lagi, hanya IP, jadi DNS cenderung tidak menjadi masalah ...

Saya baru saja memperbarui dengan komit terbaru ... beberapa unit mudah diperbarui dan cukup cepat, yang lain sangat lambat ...

Saya memiliki 4 AP yang berjalan pada SSID yang sama, apakah Anda juga terkadang memilih yang lebih buruk dan kemudian memiliki masalah kecepatan?

Saya berencana untuk mengubah cara ping dilakukan menjadi async ping.
Saat mencoba membuat koneksi, ada pemeriksaan untuk melihat apakah host tersedia. Itu dilakukan melalui ping.

dan itu panggilan pemblokiran?

Memang, itu sebabnya saya ingin mengubahnya ke beberapa varian async.

hmm.. ini bisa menjelaskan, ketika konektivitas jaringan lemah, hal-hal itu tidak terlalu "lancar" ... terutama ketika mencoba mengunggah sketsa baru ... apakah mungkin untuk menambah batas waktu ping jika jaringannya banyak dari latensi?

Itu hanya dilakukan saat membuat koneksi.
Beban yang dialami dari percobaan ulang koneksi MQTT yang akan gagal jauh lebih terlihat.
Sebenarnya tidak banyak host yang kami sambungkan, jadi mungkin harus ada beberapa pemeriksaan ketersediaan asinkron yang berjalan di latar belakang untuk membantu memutuskan apakah akan menyambung kembali atau tidak.
NB, pencarian DNS mungkin juga cukup memblokir ketika pada akhirnya akan gagal.

mungkinkah 0.0.0.0 adalah DNS sekunder?

Saya menyadari ini dengan DNS, itu sebabnya saya hanya menggunakan alamat IP sekarang ... Saya tidak menggunakan MQTT sama sekali, hanya plugin pengontrol fhme serta kueri json biasa (dari fhem dengan plugin HTTPMOD).

satu hal yang mungkin akan saya coba adalah menonaktifkan jaringan antar-ESPEasy UDP... Saya tidak dapat menghilangkan perasaan, bahwa ini memiliki pengaruh pada unit, terutama ketika menjalankan 15+ unit yang mengirimkan pembaruan rutin. ..

setelah memperbarui semua unit ke komit mega terbaru, semua beban CPU kembali ke "normal" ... pagi ini sekitar jam 8 saya mem-boot ulang Nr. 4 dan 9, dan lihat apa yang terjadi pada beban CPU, hampir semua unit memiliki puncak sekitar 30 menit. dan kembali normal setelah itu....

hanya ide singkat: apakah mungkin acara UDP antar-ESPEasy yang diterima "didistribusikan kembali" ke unit lain dan karenanya dapat menghasilkan loop dan mengisi tumpukan jaringan?
image

Saya tidak pernah melihat ke dalam kode 'komunikasi antar ESPeasy' ini, oleh karena itu saya tidak bisa mengatakan apa-apa tentang itu.
Saya berharap protokol ini hanya mengirim datanya sendiri dan tidak mengulangi sisanya.
Protokol ini terdiri dari 2 bagian:

  1. Menyatakan kehadirannya sendiri.
  2. Mengirim nilai parameter plugin melalui apa yang dulunya adalah "sinkronisasi global".

Yang terakhir sekarang diganti dengan "controller c_013".

Tetapi tidak yakin apakah tidak ada loop yang mungkin. Misalnya dengan perangkat dummy, impor MQTT, dll.
Mungkin juga perilaku yang berbeda antara versi lama dan versi baru yang menggunakan "controller 13".

ok, terima kasih atas balasan cepatnya... Saya akan mematikannya sekarang, resp. atur port UDP ke 0 dan lihat apakah ada yang berubah ...

Tambahkan: setelah mengubahnya, saya melihat sekitar 50% unit me-reboot (tanpa disuruh melakukannya)... dan beberapa "HTTP : koneksi gagal" di log....

Saya telah melihat masalah serupa dengan beban CPU. Wemos menjalankan FW yang dikompilasi sendiri dengan 13 plugin. Saya menggunakan Rest API dengan Pimatic. Seperti yang Anda lihat karena beberapa alasan, bebannya naik hingga 90% ke atas.
image

untuk info: karena saya mematikan jaringan Inter-ESPEasy dengan mengatur port ke 0 dalam pengaturan lanjutan, tampaknya (sebagian besar) masalah saya hilang! semua 20 unit memiliki waktu aktif >20 menit. dan masih secara teratur melaporkan nilai. web-jika aktif dan berjalan. juga CPU-grafik tidak menunjukkan lagi lompatan tiba-tiba ini. Hanya satu unit yang diubah ke mode AP, saya akan melihat apakah itu pulih..
mungkin ini perlu diselidiki (di sumbernya) ... dengan banyak unit, barang-barang UDP mungkin membebani tumpukan jaringan ...
semoga ini bisa membantu orang lain yang menghadapi masalah serupa ...

Berikut pengalaman saya:
6 unit semua dengan IP Statis dan Jaringan Inter-ESPeasy aktif.
Firmware terbaru yang dimuat adalah "Mega 20180505 Manual dibuat dua kali". (tapi firmware sebelumnya juga bekerja dengan sangat baik).
Mereka telah berjalan selama hampir 3 hari tanpa masalah.

immagine

Itulah salah satu alasan saya ingin menunggu beberapa hari sebelum saya melakukan perbaikan wifi/jaringan. Biarkan berjalan sebentar untuk melihat apa yang sebenarnya salah dan coba baca beberapa masalah pada daftar masalah Arduino.
Saya sudah memperhatikan bahwa sejumlah masalah menyarankan untuk menonaktifkan manajemen daya untuk beberapa konfigurasi wifi. Rupanya beberapa kombinasi titik akses ESP8266 + tidak berfungsi dengan baik dengan fitur manajemen daya diaktifkan (yang diaktifkan secara default)
Jadi itu opsi untuk ditambahkan ke ESPeasy.

Saya mencari lebih banyak ide pada hari-hari berikutnya dan Jumat/Sabtu saya memiliki lebih banyak waktu untuk membuat kode.

Untuk referensi Access Point saya adalah ASUS RT-AC68U dengan firmware Merlin

Saya kira sebagian besar masalah adalah dengan firmware default pabrik untuk model yang lebih murah dan mungkin titik akses yang agak lebih tua yang tidak mengetahui opsi penghematan daya perangkat wifi modern.
Pertanyaan tetap apakah mungkin untuk menegosiasikan fitur tersebut untuk mendeteksi fitur ini secara otomatis.

Apa tentang membiarkan dinonaktifkan secara default dan mengaktifkan hanya jika diminta di halaman pengaturan?
Opsi hemat daya masuk akal untuk perangkat yang dioperasikan dengan baterai saja, saya kira.

Mereka juga masuk akal untuk tujuan lain.
Lebih banyak daya berarti lebih banyak panas dan beberapa tertutup dengan sensor.... ;)

Selain beban prosesor yang tinggi. Saya kembali ke FW tanggal 16/03 dengan 2.3.0 Core dan semuanya menjadi normal kembali. Beban sekarang maks. 25%. Juga waktu respon wemos jauh lebih baik lagi. Dengan kedua 08/05 dan 16/03 saya tidak memiliki WiFi terputus sama sekali. Masih tidak tahu apa yang menyebabkan beban tinggi. Juga dalam kedua kasus saya tidak menggunakan udp.

sejak menonaktifkan UDP, unit berjalan tanpa masalah, kecuali yang memiliki LCD terpasang. Saya pikir jika Anda memiliki banyak unit yang berbicara (> 20) mereka menjadi terlalu sibuk mendekode semua pesan UDP atau memiliki beberapa kebocoran memori atau serupa. Itu juga akan menjelaskan reboot unit secara tiba-tiba setelah memulai yang lain. hanya MHO ... perlu men-debug lebih banyak untuk memastikan ...

Ini mungkin juga terkait dengan melakukan tugas yang lebih lama tanpa waktu untuk beberapa panggilan ke yield() , yang juga dilakukan saat menelepon delay() .
Saya dapat membayangkan plugin LCD (dan mungkin beberapa yang lain juga) melakukan beberapa tugas yang membutuhkan waktu > 10msec.

unit dengan LCD tampaknya semakin sibuk dari waktu ke waktu ... ketika mencoba untuk reflash saya harus mem-boot ulang mereka terlebih dahulu, karena setelah beberapa jam unggahan tidak berfungsi lagi (atau membutuhkan waktu lama ...)

semua unit lain berjalan dengan baik sekarang, tetapi seperti yang dikatakan, pengumuman antar ESP harus dinonaktifkan ...

setidaknya WiFi stabil seperti ini, tidak ada masalah lain dengan konektivitas sejauh ini ... (menjalankan 20+ unit sekarang)

Apakah Anda mengaktifkan logging pada port serial?
Bisakah Anda mengaturnya ke "Tidak Ada"?

hmm.. poin yang menarik, saya memiliki "info" default pada port serial logging, tetapi menonaktifkan serialport sepenuhnya ke bawah ... dapatkah itu menyebabkan masalah?

Saya akan mengubahnya menjadi "tidak ada" pada unit, saya akan melihat apakah itu membuat perbedaan..

Saya telah mendengar laporan sebelumnya, tentang data yang tidak diambil dari buffer serial akan menumpuk.
Dan saya baru menyadari bahwa pada node yang sedang berjalan, ketika saya menghubungkan monitor serial saya menerima data kembali ke saat boot, seperti satu menit sebelumnya.

Dengan ini perbedaan antara inti 2.3.0 dan 2.4.1 10 Mei saya telah mengubah FW dari 2.4 kembali ke 2.3. Pengaturan dan aturan untuk keduanya persis sama.
image

@jopiekr : apa perangkat lunak yang Anda gunakan untuk mencetak beban CPU?

@gii1967g itu pimatic. Jalankan di OrangePi One selama lebih dari satu tahun tanpa masalah. Sebagai back up juga pada Raspberry Pi. pimatic.org

mengubah semua log serial menjadi tidak ada sekarang ... Saya akan melihat apa yang terjadi ...

apa yang juga luar biasa adalah wifi RSSI.. jika unit mendapat sinyal lemah, mereka bisa sangat tidak responsif... karena saya menjalankan 4AP, tampaknya agak "acak" yang mereka sambungkan dan tidak selalu mengambil yang terkuat satu....

Saya perhatikan di atas -77dB mereka bisa menjadi tidak responsif. Juga ketika mereka tidak dioperasikan dengan baterai, periksa pembaruan waktu sewa router Anda. Saya telah membuat aturan untuk me-reboot mereka setelah 12000 menit.
image

Mereka harus menyambung kembali ke yang terakhir. Upaya penyambungan ulang pertama adalah ke BSSID dari sambungan aktif terakhir.
Tapi saya kira kita harus menambahkan BSSID ke pengaturan.

Beberapa hari terakhir saya telah banyak memikirkan masalah wifi dan saya menemukan beberapa jenis solusi untuk bug yang mungkin ada di lib inti, atau kombinasi dengan versi firmware AP di sekitar
Saat ini lib inti melakukan pemindaian ketika mencoba menghubungkan hanya menggunakan SSID + pwd.
Dengan cara ini jauh lebih cepat ketika Anda menyediakan saluran BSSID + saat menghubungkan.
Karena itu tidak perlu memindai.
Jadi mengapa tidak memindai sendiri, temukan SSID yang diketahui, simpan semua BSSID + saluran untuk jaringan yang cocok dan kemudian coba sambungkan hanya menggunakan saluran BSSID +.
Kemudian Anda juga memiliki failover otomatis dan memiliki kontrol penuh atas kapan harus mempertimbangkan sambungan untuk diperbarui. (dan dengan demikian restart layanan)

Anda juga tahu RSSI terkuat, jadi sambungkan ke yang terkuat terlebih dahulu dan selalu coba gunakan kembali yang terakhir digunakan terlebih dahulu
Dan ketika koneksi tidak stabil, coba nonaktifkan fitur hemat daya yang diaktifkan secara default di inti 2.4.x.
Fitur hemat daya ini dapat menyebabkan wifi terhubung kembali, terhenti saat menjelajah halaman web, atau bahkan menolak saat terhubung.

Dengan mengaktifkan fitur hemat daya, wifi dimatikan untuk sementara dan kemudian diaktifkan kembali tepat pada waktunya untuk menerima sinyal suar dari titik akses.
Jika tidak sinkron, beberapa paket mungkin tidak sampai ke ESP dan hanya akan ditransmisikan ulang saat sinyal suar berikutnya diterima. (yang mungkin memakan waktu cukup lama)

Saya tidak tahu banyak secara spesifik tentang masalah penghematan daya ini, tetapi saya cukup tahu tentang pengembangan firmware untuk mengetahui bahwa standar mungkin tidak diterapkan sama di antara vendor. Sehingga sangat mungkin ada beberapa kombinasi hardware yang akan beroperasi kurang optimal dengan fitur hemat daya yang diaktifkan. Bahkan mungkin ada perangkat WiFi lain yang menunda interval suar wifi dari titik akses. Ada terlalu banyak variabel.

Pemutusan sementara seperti itu juga dapat memengaruhi pencarian DNS dan gangguan koneksi lainnya yang dapat menghentikan ESP untuk sementara waktu. Ini juga dapat memengaruhi beban CPU, karena nilai (didefinisikan dengan buruk) didasarkan pada berapa kali fungsi loop() dijalankan dalam 30 detik. Jika panggilan ke beberapa permintaan penyelesaian DNS menghentikan ESP, jumlah loop kemudian akan cukup rendah dan dengan demikian beban CPU yang dilaporkan tinggi.

@jopiekr Anda juga bisa mengeluarkan reboot saya kira dari aturan.
Pertama-tama saya akan melihat menonaktifkan opsi hemat daya (dan tentu saja membuatnya dapat dipilih)

@TD-er tentang penanganan WiFi: Saya sepenuhnya setuju dengan fungsi manajemen daya. Seseorang harus dapat mematikannya, karena dapat menyebabkan masalah yang sangat aneh dan perangkat yang lamban ...

Untuk koneksi ulang ke AP saya melihatnya berbeda, saya selalu mencoba untuk terhubung ke AP terkuat untuk memastikan koneksi yang baik. hanya setelah itu saya mungkin akan mengambil yang terakhir. Hanya karena jika AP "utama" crash/boot ulang/tidak menjawab dll. unit akan terhubung ke yang lain. Sejak saat itu dan seterusnya akan selalu mengambil yang (lebih buruk) sampai yang ini juga gagal... tidak akan pernah kembali ke yang kuat, bahkan jika yang ini bangkit kembali... juga jika Anda memindahkan perangkat , bisa jadi AP nya milih AP sebelumnya padahal yg itu jauh/lebih lemah sinyalnya...

Saya setuju meskipun dalam memindai dalam kode Anda dan kemudian memutuskan mana yang akan diambil berdasarkan RSSI dan BSSID yang dikenal ...

Ini hanya upaya pertama untuk menyambung kembali ke BSSID terakhir yang diketahui.
Ini akan menghasilkan koneksi yang lebih stabil saat menggunakan repeater.
Pengulang tersebut terkadang dapat memutuskan koneksi saat mereka terlalu sibuk menangani tugas lain dan mereka mungkin tampak kurang kuat saat memindai. Yang murah hanya memiliki satu radio untuk menerima dan mengirim, jadi ketika mereka menerima data, mungkin mereka tidak memancarkan sinyal suar mereka saat pemindaian dilakukan. Jadi RSSI dari AP lain mungkin tampak lebih kuat pada saat itu.

ok, bagaimana dengan pemindaian "biasa" yang melacak kekuatan? atau setidaknya setelah reboot, ia harus mengevaluasi kembali titik akses apa yang dipilihnya ...

Saat reboot dan jika upaya pertama untuk menyambung kembali gagal, itu akan melakukan pemindaian dan memilih kecocokan terkuat untuk SSID yang ditetapkan.

Saya akan mengubahnya menjadi menyimpan BSSID dari AP pilihan di pengaturan, untuk menjadikan BSSID itu selalu yang disukai.
Sambungan ulang sangat cepat jika salurannya juga dikenal. (sub 200 msec dimungkinkan, tergantung pada AP yang digunakan)
Juga pengaturan IP statis membutuhkan waktu sekitar 20 - 25 msec, dibandingkan dengan DHCP yang membutuhkan waktu 2,5 - 10 detik.
Itu akan ideal untuk perangkat bertenaga baterai.

Jadi ada ruang untuk perbaikan :)

Kedengarannya sangat menjanjikan. Sampai sekarang saya memiliki masa pakai baterai 2 bulan dengan baterai 2AA naik ke 3.3V dan satu sensor DHT mengirim setiap 900 detik. Ini ada di papan RobotDyn ESP Pro dengan pengatur tegangan yang dilepas.

@TD-er Baru saja mencoba build dari kemarin. Saya tidak dapat melihat perbedaan waktu koneksi jika saya menggunakan IP statis atau dhcp. Kedua koneksi membutuhkan waktu sekitar 3 detik setelah reset.

Kemudian Anda memiliki server DHCP cepat.
Fritzbox saya membutuhkan waktu sekitar 2,5 detik untuk DHCP, setelah 2,5 detik terhubung ke wifi.
Jadi pengaturan waktu koneksi MQTT + NTP membutuhkan waktu sekitar 6 - 6,5 detik sejak boot.

Kotak Fritz 7490.

pembaruan cepat: setelah menonaktifkan InterESP UDP (dan menghapus C13 dari 1 juta unit) dan mengatur log serial ke "non" (juga menonaktifkan port serial) hampir semua unit saya berjalan stabil selama 30+ jam terakhir... D1 Mini, D1 pro, Sonoff Basic, Dual dan 4ch... 20+ unit... berjalan pada komit dari mega-20180511, dikompilasi sendiri dengan Arduino IDE...

Saya memiliki 7581 sebagai modem dan 3* 1750E sebagai titik akses.

BTW: Saya menjalankan AP Mikrotik (dan satu USR yang sangat lama). Akan memperbarui unit sekarang dengan komit terbaru mulai malam ini ...

Komit terbaru saat ini hanya menangani kode terkait JSON (penampil log + memperbarui nilai sensor).
Belum dengan kode wifi.

tentu, tetapi wifi tampaknya bae "cukup stabil" dengan komit terbaru, jadi saya ingin up to date dengan unit saya ;)

maaf untuk mengemukakan ini lagi, tetapi saya masih mengalami masalah yang menurut ESP memiliki IP 0.0.0.0 dan berhenti berbicara dengan server, sedikit di jaringan dan tingkat web semuanya baik-baik saja! lihat tangkapan layar terlampir, coba dengan kombinasi versi ESPEAsy dan esp8266 yang berbeda ...
apakah ada orang lain yang mengalami ini?
untitled

Sangat aneh memang, karena saya bertanya-tanya bagaimana Anda dapat melihat halaman web sama sekali dengan konfigurasi IP seperti itu.
Atau apakah Anda terhubung ke ESP melalui fungsi titik aksesnya?

tidak, terhubung melalui jaringan secara langsung. ping dan http berfungsi tanpa masalah, cepat, (lihat IP klien adalah 10.0.0.10 yang merupakan laptop saya, net internal adalah 10.0.0.0/16)... ya, cukup aneh..
mungkin terkait DHCP atau lebih.. setelah reboot semuanya baik-baik saja lagi..

mungkinkah ini terkait dengan fakta, bahwa saya hanya mengaktifkan satu pengontrol (FHEM) dan tidak ada pengontrol yang mengaktifkan MQTT? Saya melihat banyak kode mqtt di sumber, di luar plugin pengontrol... hanya tebakan... tapi saya pikir itu tidak benar-benar terkait...

Mungkin dhcp kedaluwarsa dan tidak diperbarui?

bisa jadi ... mungkin tumpukan jaringan masih memiliki IP aktif tetapi jika pembaruan gagal, konfigurasi yang sesuai menjadi nol ... tidak yakin bagaimana kode DHCP bekerja, tetapi itu bisa menjelaskan keadaan I0m melihat.

juga saya menemukan bahwa ketika server (dalam kasus saya fhem) tidak merespon cukup cepat beberapa kali, unit mulai reboot setelah beberapa waktu. bisa menjadi masalah dalam kode plugin atau tumpukan tcp yang mendasarinya ... Saya melakukan beberapa penyesuaian kinerja di server, sejak itu unit berjalan jauh lebih stabil (beberapa sekarang memiliki waktu aktif lebih dari 48 jam sekarang)..

Saya telah melihat 10+ hari waktu koneksi (uptime tanpa koneksi ulang) dengan versi terbaru.
Dimungkinkan untuk membuat unit mengisi ram mereka dengan banyak permintaan.
Dan saya telah melihat LWIP melakukan hal-hal aneh ketika melakukan banyak permintaan. (membaca dari memori yang tidak berisi data yang terkait dengan permintaan itu.)

Hari ini satu node berhenti merespons lagi. Dia terputus dari wifi. Saya tidak dapat terhubung ke jaringan "esp". Dia berhenti mengirim data ke pengontrol. Aku harus me-reboot dia. Mungkin pengawas akan menjadi solusi yang baik. Jika, misalnya, satu jam terputus dari wifi, itu reboot. Atau mungkin bisa dilakukan dengan aturan, tapi saya tidak tahu caranya :)

Hari ini saya mengalami banyak tindakan Watchdog saat men-debug sebuah plugin.
Dan sekarang saya tahu bahwa terkadang ketika pengawas melakukan intervensi, sebuah simpul dapat tetap dihentikan.
Jadi pengawas bukanlah solusi yang sempurna.

Apakah mungkin simpul gantung Anda tidak pernah di-boot ulang setelah mem-flash? (tekan reset atau siklus daya)

Ada kemungkinan tidak ada reboot setelah flashing. Tapi itu flashing melalui www, bukan serial.

OK, maka itu tidak masalah, jika Anda mem-flash OTA.
Selama ada reset/reboot yang tepat setelah flash serial.

Nah, setelah berjuang menghadapi banyak masalah stabilitas dan masalah wifi aneh dengan rilis firmware terbaru, saya akhirnya harus kembali ke versi sebelumnya. Misalnya, hingga pemadaman listrik terjadi baru-baru ini, satu node ESP12E lama dengan mega-20180311dev bekerja selama 70 hari, mengirimkan data suhu ke ThingSpeak.
Di node lain setelah memutakhirkan ke mega-20180522dev saya mengalami reboot karena pengecualian setiap 24 jam meskipun disetel ulang ke default, hanya berjalan tanpa perangkat apa pun yang dikonfigurasi, tidak ada NTP yang dikonfigurasi, tidak ada pengontrol... Tidak pernah bertahan 48 jam. Setelah downgrade ke mega-20180324 dua setengah hari yang lalu, pertahankan konfigurasinya, cukup aktifkan NTP lagi dan sejauh ini berjalan. Meskipun ada beberapa bug dan fitur yang hilang di versi lama ini, bagi saya itu adalah pilihan terbaik saat ini.

Tidak banyak yang bisa dilakukan siapa pun jika masalahnya tidak dapat direproduksi dengan andal.
Yang sedikit membantu adalah menjadwalkan reboot setiap malam. Anda dapat menggunakan aturan untuk itu.

Saya tahu, tetapi saya lebih suka node stabil tanpa reboot terjadwal. Saya tidak tahu apakah stabilitasnya berkurang secara signifikan karena beralih ke inti 2.4.1 (mungkin yang belum cukup matang) atau apakah itu terkait dengan desain ulang ESP Easy tetapi itu terjadi meskipun upaya maksimal dari semua kontributor ESP Easy. Saya sangat menghargai kerja keras kalian semua tetapi saat ini saya tidak dapat menggunakan rilis ESP Easy terbaru lagi.

Saya pikir itu juga terkait dengan plugin yang digunakan atau mungkin kombinasi dari plugin.

Minggu lalu saya bekerja untuk melihat efek pengaturan waktu dan saya yakin itu akan memiliki efek signifikan pada tugas-tugas kritis waktu.

Saya baru saja melihat beberapa node saya, semua menjalankan build resmi:

Nama file biner ESP_Easy_mega-20180513_normal_ESP8266_4096.bin

Unit 3

  • Uptime 16 hari 18 jam 26 menit
  • Terhubung 5d23h07m
  • Alasan Putus Terakhir (201) Tidak ada AP ditemukan
  • Nomor menghubungkan kembali 2

Unit 5

  • Uptime 11 hari 5 jam 22 menit
  • Terhubung 5d22h57m
  • Alasan Putus Terakhir (201) Tidak ada AP ditemukan
  • Nomor menghubungkan kembali 4

Satuan 6

  • Uptime 11 hari 5 jam 23 menit
  • Terhubung 45 m 1 s
  • Alasan Putus Terakhir (201) Tidak ada AP ditemukan
  • Nomor menghubungkan kembali 58

Nama file biner ESP_Easy_mega-20180619_test_ESP8266_4096.bin

Satuan 7

  • Uptime 13 hari 20 jam 51 menit
  • Terhubung 5d23h05m
  • Alasan Putus Terakhir (202) Auth gagal
  • Nomor menghubungkan kembali 2

Sekitar 6 hari yang lalu, saya mengalami beberapa masalah dengan salah satu titik akses WiFi saya, yang harus saya mulai ulang.

Unit 6 terhubung sama dengan unit 3 & 7, tetapi memiliki lebih banyak koneksi ulang.
Ketiga unit tersebut berada tepat bersebelahan, dalam jarak satu meter dari satu sama lain untuk membandingkan sensor CO2 yang berbeda (MH-Z19 A, B, dan SenseAir S8) dan semuanya ditenagai oleh catu daya yang sama (pengisi daya USB 3 port IKEA).

Satu-satunya perbedaan di antara mereka adalah bahwa yang lebih banyak terhubung kembali memiliki sensor Senseair.
Jadi bisa jadi penerapan sensor itu lebih membebani rutinitas WiFi (lebih sedikit panggilan tunda), yang dapat menyebabkan ketidakstabilan WiFi.

Bisakah Anda memberikan daftar plugin yang digunakan?
Saya juga membuat permintaan tarik kemarin yang mencatat banyak statistik waktu. Mungkin Anda bisa membuat build berdasarkan yang itu dan menjalankannya selama beberapa menit untuk mendapatkan beberapa ide tentang plugin menggunakan terlalu banyak waktu.

Saya selalu menggunakan build resmi karena saya tidak dapat menyiapkan dan memelihara lingkungan pengembangan untuk perangkat ini.
Rilis yang disebutkan mega-20180522dev, seperti yang saya jelaskan di atas, adalah konfigurasi yang benar-benar kosong sehingga sama sekali tidak ada plugin yang digunakan, tidak ada aturan, saya bahkan telah menghapus Controller Nr1 default pada akhirnya. Tidak ada yang bisa menghentikan node dari reboot karena pengecualian pada interval sekitar 24-40 jam.

Tidak tahu apakah ini masalah wifi - sepertinya tidak, saya telah berhasil mengatur alamat IP statis untuk wifi, tetapi terutama masih mengambilnya dengan dhcp dan mengatur yang berbeda.

1104 : WD   : Uptime 0 ConnectFailures 0 FreeMem 21800
1105 : S
W   : State 1.00
1106 : EVENT: x#w=1.00

scandone

state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
c
nt 

connected with BJ3, channel 12
dhcp client start...
4350 : WIFI : Connected! AP: BJ3 (E8:DE:27:4F:66:86) Ch: 12 Duration: 3760 ms
4351 : EVENT: WiFi#ChangedAccesspoint
4355 : IP   : Static IP : 192.168.2.184 GW: 192.168.2.1 SN: 192.168.2.0 DNS: 8.8.8.8
4360 : WIFI : Static IP: 0.0.0.0 (ESP5-5) GW: 0.0.0.0 SN: 0.0.0.0   duration: 11 ms
4367 : EVENT: WiFi#Connected
4374 : Webserver: start
4374 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
ip:192.168.2.123,mask:255.255.255.0,gw:192.168.2.1
4400 : WIFI : Static IP: 192.168.2.123 (ESP5-5) GW: 192.168.2.1 SN: 255.255.255.0   duration: 50 ms
4401 : EVENT: WiFi#Connected
4406 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_SERVICES_INITIALIZED
4500 : MQTT : Intentional reconnect
4501 : LoadFromFile: config.dat index: 28672 datasize: 724


@uzi18 Sudahkah Anda mengatur semua bidang untuk konfigurasi IP statis?

Jika demikian, maka saya khawatir itu adalah masalah yang diketahui (bagi saya), di mana ada beberapa sesi sebelumnya yang disimpan di wilayah di mana kami (belum) menghapus data di reset pabrik.
Ini berarti saat ini tidak ada cara lain selain menghapus semua flash dan memulai lagi dengan versi terbaru ESPeasy.
Versi yang lebih baru memang menetapkan nilai untuk tidak membuat pengaturan wifi tetap ada.

@TD-er Ya, semua data terisi - seperti yang Anda lihat di log.
Saya telah menginstal modul BARU, dengan
INFO : Plugin: 71 [Normal] [Pengujian] (ESP82xx Core 2_4_1, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
dan itu bekerja seperti itu.
Modul hanya diambil dari tas asli dan di-flash, apalagi sebelumnya belum pernah ada di sini.

@TD-er: Dua pemikiran tentang itu:

  1. Pemanasan non ESPEasy saya ke penyiar MQTT bekerja dengan sempurna menggunakan klien pubsub terbaru. Apakah menghubungkan kembali dan sebagainya. Mungkin pengawasan konektivitas ESPEasy mengganggu apa yang sudah dilakukan oleh perpustakaan inti. Haruskah kita memiliki cara untuk menonaktifkan semua hal ping-reconnect-wifistate tambahan itu? Hanya untuk pengujian?
  2. Apakah Anda mengetahui wifi mati secara otomatis? https://blog.creations.de/?p=149

Akan lebih baik jika seseorang dengan wifi yang agak tidak stabil dapat menguji PR ini: https://github.com/letscontrolit/ESPEasy/pull/1562

@TD-er baru saja menemukan https://github.com/esp8266/Arduino/pull/4718
berurusan dengan masalah penyambungan kembali lwip. Diperbaiki untuk sementara. Mungkin Anda ingin melewatinya ...

Saya selalu menggunakan Versi GIT terbaru dari esp8266.. itu sebabnya saya mungkin tidak melihat masalah 0.0.0.0 lagi...

Kemarin lagi satu node setelah restart router kehilangan kontak dengan jaringan.
Aturan bekerja dengan benar.
Ini adalah saklar dinding saya sendiri, sulit untuk membongkar untuk reset.

Untuk memfasilitasi ini di masa depan, saya memodifikasi aturan:

on S1#Switch do
timerSet,1,5 
if [R1#Relay]=1
gpio,12,0
else
gpio,12,1
endif
endon

on S2#Switch do
if [R2#Relay]=1
gpio,13,0
else
gpio,13,1
endif
endon

On Rules#Timer=1 do
if [S1#Switch]=1.00
 reboot
endif
endon

Sekarang hidup akan lebih sederhana :))

Saya melakukan reboot setiap 24 jam. Ini menghidupkan kembali satu node dengan firmware dari 4 minggu lalu dua kali seminggu.
Mungkin ini harus menjadi fitur permanen ....

Apakah ini masih menjadi masalah? Jika demikian silakan buka kembali.

Utas terpanjang kami di daftar masalah ....

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

TD-er picture TD-er  ·  4Komentar

ghtester picture ghtester  ·  3Komentar

s0170071 picture s0170071  ·  3Komentar

MarceloProjetos picture MarceloProjetos  ·  4Komentar

uzi18 picture uzi18  ·  5Komentar