Espeasy: [BUG] [Stabilitas WiFi] Pengecualian ESP 3/29 saat lapisan 2 terputus

Sepertinya saya memiliki masalah yang sama. Terkadang esp saya kehilangan koneksi wifi dan terus "hilang" dari wifi selama berjam-jam. Saya pikir mereka harus reboot dan menyambung kembali ke wifi berkat pengawas tetapi mereka tidak melakukannya. Booting dingin menyelesaikan masalah.

Hal terakhir yang dijelaskan oleh @wolverinevn adalah sesuatu yang saya lihat terjadi di sini juga.

seperti yang kita bahas di # 1957 Saya cukup yakin banyak masalah WiFi / jaringan yang aneh ini berasal dari ketidakstabilan lapisan 2 ini ... Saya telah melihat semua jenis perilaku aneh sebelum mengubah AP saya ke beberapa pengaturan waktu yang ditingkatkan ...

seperti yang kita bahas di # 1957 Saya cukup yakin banyak masalah WiFi / jaringan yang aneh ini berasal dari ketidakstabilan lapisan 2 ini ... Saya telah melihat semua jenis perilaku aneh sebelum mengubah AP saya ke beberapa pengaturan waktu yang ditingkatkan ...

Semoga Anda menemukan solusinya. Salah satu Nodemcu saya hang dan menghilang dari router selama 5 jam sampai sekarang tanpa alasan. Saya berharap bisa pulih dari pengawas tetapi tidak ada yang terjadi. Saya harus mem-boot ulang secara manual sekarang. Sangat kesal!

@wolverinevn ketika Anda memiliki akses ke node lagi pergi ke tools => advanced dan atur "Connection Failure Threshold" ke sesuatu yang lain dari 0 (Saya menyarankan sesuatu antara 50 dan 100, tergantung pada jumlah tugas yang Anda miliki). Ini sebenarnya tidak mengubah masalah tetapi meningkatkan kemungkinan node melakukan boot ulang dan menghubungkan kembali secara signifikan!

solusi lainnya adalah jika Anda dapat mengubah beberapa parameter di titik akses Anda, tergantung pada jenis AP apa yang Anda miliki jika itu dapat diubah ...

@ kikuk-stefan Haruskah kita menyetel default di ESPeasy ke tingkat ini dengan mudah juga?

Dan mungkin kita juga harus menampilkan nilai ini di halaman sysinfo dan membuatnya tersedia untuk aturan?

@ TD-er mengaturnya ke beberapa level secara default mungkin bukan hal yang buruk jika tidak terlalu rendah (bisa selalu terjadi kegagalan koneksi).

Saat men-debug masalah, saya berpikir tentang bagaimana hal ini dilakukan, saat ini setiap koneksi yang tidak menyenangkan meningkatkan penghitung dan koneksi yang berhasil menurunkannya. Saya berpikir apakah akan lebih logis untuk mengatur ulang ke 0 segera setelah koneksi sukses terjadi, tapi saya rasa itu adalah pertanyaan ideologis yang lebih masuk akal.

Masalah dengan angka itu adalah, jika Anda memiliki 10 tugas, masing-masing tugas dengan jumlah percobaan ulang 10 dan penundaan pengiriman ulang 100 md, boot ulang terjadi cukup cepat jika ada masalah komunikasi yang sebenarnya (100 percobaan ulang dalam waktu sekitar 10 detik.) .

Sekarang jika Anda misalnya selalu memiliki 5 komunikasi yang gagal dan 1 yang berhasil, Anda akan terus meningkatkan kegagalan koneksi. jika ini terjadi sepanjang waktu, Anda akan mem-boot ulang node cepat atau lambat meskipun semua data dapat dikirim.

masalah utama yang saya lihat adalah, entah bagaimana node tidak menyadari bahwa koneksi pada layer 2 benar-benar hilang dan terus mengirim data (saya kira). selain ini yang saya sadari malam ini, apa yang terjadi pada syslog (dan komunikasi lain seperti NTP dll) jika tidak ada koneksi wifi? Apakah ini juga dihentikan? ini bisa menjelaskan mengapa node saya tiba-tiba melompat ke 100% cpu ketika layer 2 hilang. mungkin tidak ada lagi data tugas yang dikirim, tetapi mencoba untuk menyingkirkan paket syslog UDP dan tidak bisa ... hanya menebak ...

maaf, teks panjang untuk dua pertanyaan sederhana ... singkatnya:
tingkat default: ya, saya akan mengaturnya ke maksimal (100) atau lebih secara default ... jika semuanya baik-baik saja tidak ada salahnya jika tidak, unit dapat diakses lagi ...
sysinfo halaman dan aturan: Saya akan mengatakan tidak, mengapa ini harus diubah secara dinamis? itu adalah nilai darurat ...

@ clumsy-stefan Saya sudah setel ke 50. Ayo tunggu. ;)

@wolverinevn hmm ... 50 seharusnya terjadi cukup cepat tergantung pada jumlah interval tugas dan percobaan ulang yang Anda miliki (5-15 menit.) ... jika ini tidak membantu, saya pikir node sebenarnya tidak dibekukan, tetapi hanya bisa ' t sambungkan kembali ke jaringan. Saya memiliki ini juga bahkan setelah reboot WD. dapatkah Anda melihat apakah node mencoba masuk ke mode AP? apakah Anda melihat AP-WLAN dari node?

sysinfo halaman dan aturan: Saya akan mengatakan tidak, mengapa ini harus diubah secara dinamis? itu adalah nilai darurat ...

Saya bermaksud untuk diperiksa dalam aturan menggunakan variabel sistem seperti %conn_fail% dan menampilkannya di halaman sysinfo, di samping jumlah koneksi ulang wifi.
Bagaimanapun, ini adalah nilai statistik kinerja

Saya bermaksud untuk diperiksa dalam aturan menggunakan variabel sistem seperti% conn_fail% dan menunjukkannya di halaman sysinfo, di samping jumlah koneksi ulang wifi. Bagaimanapun, ini adalah nilai statistik kinerja

ah, ya, setuju, itu masuk akal! itu juga sedikit terkait dengan masalah # 1993. Memiliki plugin yang mengirimkan sejumlah variabel sistem / kinerja secara teratur ke pengontrol (tanpa menyia-nyiakan tugas yang tersedia terbatas) akan sangat bagus!

@wolverinevn hmm ... 50 seharusnya terjadi cukup cepat tergantung pada jumlah interval tugas dan percobaan ulang yang Anda miliki (5-15 menit.) ... jika ini tidak membantu, saya pikir node sebenarnya tidak dibekukan, tetapi hanya bisa ' t sambungkan kembali ke jaringan. Saya memiliki ini juga bahkan setelah reboot WD. dapatkah Anda melihat apakah node mencoba masuk ke mode AP? apakah Anda melihat AP-WLAN dari node?

Saya punya 9 tugas, 3 di antaranya adalah Dummy dan MQTT_import. Saya pikir aturannya agak sibuk dengan komputasi dan membaca sensor, saya mencoba membatasi mqtt_publish dengan memanggil aturan setiap beberapa menit. Beban sekitar 29%.
Seingat saya, terakhir kali dibekukan pagi ini, saya tidak dapat menemukan AP Espeasy (maksud Anda AP_WLAN beroperasi dalam mode AP).
Pengaturan saya (jaringan, lokasi ESP) berfungsi dengan baik dengan Nodemcu lain yang menjalankan 2.3 atau 2.4 yang dirilis pada bulan Maret.

_Uptime adalah 7 jam 20 menit, RSSI -71dbm, ada beberapa wifi di sekitar saya.
Alasan Pemutusan Terakhir: | (200) Batas waktu suar
Nomor menghubungkan kembali: | 35_

@wolverinevn Masalah dengan masalah ini adalah, bahwa itu terjadi sepenuhnya secara acak. Saya memiliki ~ 30 node yang berjalan, beberapa dari mereka menghadapi masalah beberapa di antaranya tidak, beberapa di-boot ulang, beberapa ingin ke mode AP ...

Ini benar-benar tampaknya merupakan kombinasi dari seberapa sibuk node, seberapa sibuk udaranya (mis. Jumlah perangkat wifi) dan bagaimana AP Anda secara akurat menangani kondisi tertentu (missnig layer 2 acks dll.) ...

jadi saya kira sampai kita menemukan cara dalam aplikasi (ESPEasy) untuk mendeteksi kondisi ini secara andal dan menanganinya, tidak ada solusi "nyata" ....

@wolverinevn PS: Anda tidak menggunakan mikrotik AP secara kebetulan?

@wolverinevn Tentang jumlah tersambung kembali (dalam suntingan Anda)
35 menyambung kembali dalam waktu sekitar 8 jam itu banyak.
Saya memiliki node di sini yang berjalan selama berhari-hari yang hanya memiliki sedikit koneksi ulang.
Yang paling stabil berjalan selama 20 hari 11 jam 46 menit sekarang dan hanya 1 yang tersambung kembali.

Terhubung | 19d22h33m
- | -
Alasan Pemutusan Terakhir | (202) Otorisasi gagal
Nomor menghubungkan kembali | 1

@wolverinevn PS: Anda tidak menggunakan mikrotik AP secara kebetulan?

Tidak. Saya menggunakan router yang menjalankan firmware Padavan (jenis ASUS).

@ TD-er aku tahu itu. Saya sedang memeriksa alasannya, mungkin suara dari modul uang di dekatnya. Yang lain memiliki 0 sambungan ulang setelah 2 jam.

Tidak. Saya menggunakan router yang menjalankan firmware Padavan (jenis ASUS).

Sayangnya saya tidak tahu FW ini sama sekali ... Adakah kesempatan untuk mengubah parameter layer 2? Sesuatu seperti batas waktu ack bingkai atau serupa? Beberapa jenis pengaturan "jarak"?

@ clumsy-stefan Sayangnya, saya tidak melihat yang seperti itu.

@ clumpsy-stefan Unit di-boot ulang 2 kali tadi malam dengan 50 set ambang kegagalan. Kabar baiknya adalah tidak ada lagi pembekuan. Hari ini saya akan mencoba meningkatkan koneksi wifi dengan beberapa perubahan kecil dalam pengaturan perangkat keras.

3 unit Wemo di ruangan yang sama, terhubung ke AP yang sama.
Terhubung kembali dalam 16 jam terakhir atau lebih,
Dengan Aturan: On WiFi # Connected ....

26 WD reboot dan 104 koneksi ulang:

9 WD reboot dan 32 koneksi ulang

Reboot 2WD dan 40 koneksi ulang

Semua memiliki 50 set ambang batas kegagalan

@Domosapiens & @wolverinevn satu hal lagi yang dapat Anda coba adalah meningkatkan group-key-timeout pada AP Anda (jika Anda memiliki opsi seperti itu). Biasanya sekitar 5 menit. Anda dapat mencoba meningkatkan hingga 30 menit. atau bahkan 1 jam dan lihat apakah itu berkembang (selama itu tidak dalam jaringan keamanan super tinggi, yang saya tidak berasumsi jika Anda memiliki IoT di dalamnya) ...

@ TD-er

Yang paling stabil berjalan selama 20 hari 11 jam 46 menit sekarang dan hanya 1 yang tersambung kembali.

Saya juga saat ini memiliki unit yang berjalan selama lebih dari 3 hari sekarang dan lainnya yang reboot dalam satu hari ...

Saya memang melihat beberapa masalah dengan rekeeying kunci grup. tampaknya entah bagaimana, bahwa dalam versi inti yang lebih baru dapat terjadi bahwa rekeying mengalami batas waktu ... namun aplikasi harus bertindak atas hal ini dan tidak masuk ke mode beban tinggi tidak responsif ... tapi saya tidak yakin di mana itu gagal ..

@ clumsy-stefan terima kasih atas saran Anda.
Saya melihat di router dd-wrt saya sebuah param. "Key Renewal Interval" dengan nilai 3600 (dalam detik).
Jadi itu tidak masalah?

rekeying mengalami batas waktu

Itu akan menjelaskan hanya imho menghubungkan kembali setiap jam.
Berkat fitur aturan hebat _WiFi # Connected_, kita dapat melihat ini.
Tidak tahu bagaimana kinerja versi yang lebih lama ini.
Masalah tersembunyi sudah lama sekali?

setelah mengatur penggantian kunci grup saya dari 5 menit. untuk 1 jam unit berjalan jauh lebih stabil. Saya berasumsi, bahwa dengan 40 klien yang terhubung ke satu AP yang dilakukan setiap 5 menit. a rekey baru saja mendapat udara agak terlalu sibuk .. setelah itu saya bahkan dapat mengurangi waktu tunggu frame-ack lagi dan unit menjadi lebih responsif lagi, juga saya mendapat lebih sedikit "waktu tunggu koneksi" setelah mengubah parameter ini ...

@ TD-er masih saya pikir ini "group key timeout" dan "assoc fail" setelah itu perlu ditangkap dan ditangani oleh aplikasi. Saya merasa bahwa unit terus mencoba mengirim pesan antrian ke pengontrol / server ketika mencoba melakukan rekey yang membuat unit terlalu lambat dan rekeeying gagal ... oleh karena itu memutuskan sambungan pada lapisan 2.

hanya gambaran kasar, saya masih mencoba untuk benar-benar menyematkannya, tapi itu yang paling dekat yang bisa saya dapatkan sampai sekarang.

@ TD-er jsut sekarang saya mengalami lagi sebuah node yang masuk ke loop tak terbatas mencoba menghubungkan kembali dan selalu mendapatkan kedaluwarsa (lihat log di bawah). intersting adalah, bahwa obvisouly menyadari itu tidak terhubung dan tidak mencoba mengirim data ke pengontrol, yang berarti "upaya koneksi yang gagal" tidak meningkat lagi dan oleh karena itu tidak pernah mencapai batas koneksi yang gagal.

juga beban menunjukkan selalu 100%, itulah mengapa saya kira itu tidak berhasil menyambung kembali karena selalu terlalu lambat untuk benar-benar melakukan jabat tangan .... sems like a tail-bite to me ... hanya memori perlahan menurun (sampai Saya berasumsi itu crash karena keluar dari mem) ...

Saya akan menguji dengan # 2073 dan melihat apakah situasi ini terjadi lagi ... namun, ini sangat jarang terjadi pada dua node yang terhubung secara serial, sehingga saya dapat benar-benar melacak apa yang terjadi ...

105587 : EVENT: WiFi#Disconnected
3105617 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms
3131325 : WD   : Uptime 52 ConnectFailures 84 FreeMem 12976
3134621 : EVENT: WiFi#Disconnected
3134652 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5141 ms
3141487 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3141488 : WIFI : Connecting clumsy_ap2 attempt #53
3142671 : EVENT: WiFi#Disconnected
3142700 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3153443 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3153444 : WIFI : Connecting clumsy_ap2 attempt #54
3153713 : EVENT: WiFi#Disconnected
3153743 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 157 ms
3161324 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12976
3165518 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3165519 : WIFI : Connecting clumsy_ap2 attempt #55
3178542 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3178543 : WIFI : Connecting clumsy_ap2 attempt #56
3179728 : EVENT: WiFi#Disconnected
3179757 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3189704 : SYS  : 31.00,12808.00,100.00,53.00
3189708 : EVENT: sysinfo#rssi=31.00
3189743 : EVENT: sysinfo#mem=12808.00
3189773 : EVENT: sysinfo#load=100.00
3189804 : EVENT: sysinfo#uptime=53.00
3191297 : WD   : Uptime 53 ConnectFailures 84 FreeMem 12800
3191441 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3191442 : WIFI : Connecting clumsy_ap2 attempt #57
3191576 : EVENT: WiFi#Disconnected
3191606 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3200507 : EVENT: Clock#Time=Tue,10:25
3204458 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3204459 : WIFI : Connecting clumsy_ap2 attempt #58
3217493 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3217493 : WIFI : Connecting clumsy_ap2 attempt #59
3218677 : EVENT: WiFi#Disconnected
3218707 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1122 ms
3221325 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12800
3245444 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3245445 : WIFI : Connecting clumsy_ap2 attempt #61
3249673 : SYS  : -80.00,12632.00,100.00,54.00
3249677 : EVENT: sysinfo#rssi=-80.00
3249709 : EVENT: sysinfo#mem=12632.00
3249741 : EVENT: sysinfo#load=100.00
3249772 : EVENT: sysinfo#uptime=54.00
3250620 : EVENT: WiFi#Disconnected
3250650 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5130 ms
3251307 : WD   : Uptime 54 ConnectFailures 84 FreeMem 12624
3259435 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3259436 : WIFI : Connecting clumsy_ap2 attempt #62
3260490 : EVENT: Clock#Time=Tue,10:26
3260650 : EVENT: WiFi#Disconnected
3260679 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
3273521 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3273522 : WIFI : Connecting clumsy_ap2 attempt #63
3273659 : EVENT: WiFi#Disconnected
3273689 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 125 ms
3281281 : WD   : Uptime 55 ConnectFailures 84 FreeMem 12624
3287445 : WIFI : AP Mode ssid will be wemos-mini-18_18 with address 192.168.4.1
3287446 : WIFI : Connecting clumsy_ap2 attempt #64

Sulit untuk terhubung dengan RSSI - 80

Nilai RSSI tidak dapat diandalkan ketika node ESP tidak terhubung! node yang sama memiliki kurang dari -70 ketika terhubung .... pada node deep-sleep mereka bahkan menunjukkan default "tidak terhubung" dari +31 saat mengirim nilai!
dan setelah reboot berjalan tanpa masalah ... (tanpa memindahkannya ...) jika Anda membaca di atas, ini adalah masalah lapisan 2 yang dapat direproduksi ketika Anda mengubah parameter pada AP ....

PS: Anda bisa mencobanya sendiri! cukup hubungkan 20-30 Nodes dan turunkan timout kunci grup menjadi 5 menit. dan nilai ambang balasan bingkai ke sesuatu seperti 7 ... lihat apa yang terjadi!

Saya pikir ini adalah tempat yang salah untuk masalah dengan layer2, Anda harus mengisi masalah pada inti esp8266 atau mungkin lebih baik pada proyek sdk nonos
Tapi tolong jangan berteriak di sini

ini hanya terjadi dengan ESPeasy dan tidak dengan jenis firmware lain yang saya coba. Saya berasumsi node menjadi terlalu sibuk di beberapa titik waktu dan tidak menyisakan cukup waktu untuk inti melakukan rekeying (semuanya dijelaskan beberapa kali), jadi jangan ragu untuk membaca debug dan penjelasan ...
tapi saya setuju, sebenarnya Anda tidak perlu menjawab ...
PS: @ uzi18 apakah Anda pernah memiliki 30 node yang berjalan dengan sukses pada waktu yang sama?

@ TD-er: di ESPEasyWifi.ino baris 650 - 669 kecocokan default pernyataan switch keluar dari saklar dan oleh karena itu tryConnectWiFi() mengembalikan true meskipun WiFi.status() adalah belum tentu WL_CONNECTED tetapi dapat berupa status lain (hanya 2 status pengembalian palsu yang diperiksa ..).

Mengubah ini dan mengembalikan true hanya jika WiFi.status() benar-benar mengembalikan WL_CONNECTED menyelesaikan setidaknya satu dari masalah pemutusan / pengecualian lapisan 2 yang saya hadapi!

Bagaimana menurut anda?
Apakah saya melewatkan sesuatu atau mengapa tryConnectWiFi() dikembalikan ketika WiFi.status() bukan? WL_CONNECTED`?

@ clumsy-stefan Senang melihat Anda masih menggali kode WiFi.

https://github.com/letscontrolit/ESPEasy/blob/5ee18ec556c9c58802af29f5fd78593905ef35c1/src/ESPEasyWifi.ino#L604 -L671

Ide awal dari fungsi ini adalah memulai urutan koneksi WiFi.
Mungkin fungsinya telah sedikit berubah sepanjang semua perubahan sejak itu.
Tapi Anda mungkin menemukan sesuatu di sini.
Saya pikir itu mungkin perubahan yang tepat menjadi return true (di akhir fungsi itu) hanya jika status kembali itu terhubung.

Dapatkah Anda menjelaskan apa yang tampaknya menjadi masalah lapisan 2 lain yang Anda hadapi?

tidak dapat mengatakan dengan tepat kapan pengecualian lain terjadi, tetapi setidaknya ada perbedaan jika fungsi ini hanya mengembalikan true jika statusnya adalah WL_CONNECTED Saya melampirkan debug sebelum dan setelah perubahan. .

sebelum

156874 : EVENT: WiFi#Disconnected Processing time:74 milliSeconds
156876 : WIFI : Disconnected! Reason: '(0) Unknown' Connected for 2 m 32 s
156877 : WIFI  : Arduino wifi status: WL_CONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
157208 : WIFI : Connecting clumsy_ap2 attempt #0
157212 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
160069 : Fatal exception 9(LoadStoreAlignmentCause):
epc1=0x40105cd4, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000003, depc=0x00000000

Exception (9):
epc1=0x40105cd4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000003 depc=0x00000000

setelah

108304 : EVENT: WiFi#Disconnected Processing time:73 milliSeconds
108307 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2014 ms
108308 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
109217 : WIFI : Connecting clumsy_ap2 attempt #1
109220 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_DISCONNECTED
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED
ip:10.0.10.117,mask:255.255.0.0,gw:10.0.0.2
113751 : WIFI : DHCP IP: 10.0.10.117 (wemos-mini-17-17) GW: 10.0.0.2 SN: 255.255.0.0   duration: 1636 ms
113765 : EVENT: WiFi#Connected

Hmm .. Saya baru sadar, setelah ini status internal tidak (belum) sesuai dengan status Arduino ... ini juga bisa menyebabkan masalah saya kira ...

@ clumsy-stefan status ini karena kita tidak bisa menyampaikan status wifi Arduino, oleh karena itu @ TD-er memperkenalkan status ESPEasy, tapi ok mungkin kita bisa mencoba untuk mengecek ulang apakah setiap status dalam kode sudah diperiksa dengan benar.

Bisa jadi status wifi ini sudah diperbaiki di core 2.5.0, jadi mungkin status kita sendiri sudah menjadi usang.
Itu akan menyenangkan, karena itu membuat kode WiFi agak rumit dan rentan terhadap kesalahan.

Edit:
Saya melihat kesalahan yang Anda berikan ini:
Fatal exception 9(LoadStoreAlignmentCause):
Salah satu perbaikan terbaru dalam inti 2.5.0 adalah tentang konstruktor IPAddress , yang seharusnya memperbaiki masalah ketika penyelarasan urutan byte yang diberikan tidak selaras 32-bit.
Mungkinkah ini sesuatu yang mirip?

Itulah salah satu tebakan yang saya miliki, bahwa status ESPEasy tidak selalu sinkron dengan status Arduino. Khususnya pemutusan sementara pada lapisan 2 (mis. Pemasangan kembali WiFi) mungkin tidak benar-benar ditangani / direalisasikan.

Satu hal lain bisa jadi sebaliknya, bahwa ESPEasy menganggapnya terputus dan mencoba menyambung kembali tetapi intinya masih terhubung dan karena itu mengarah ke pengecualian. tapi belum bisa membuktikan yang itu ...

tentang penyelarasan, ya, bisa jadi, tapi tidak bisa juga saat ini ...

jadi satu-satunya hal yang saya yakin saat ini adalah kode kembali tryConnectWiFi() harus sesuai dengan status koneksi sebenarnya atau setidaknya memeriksa WL_CONNECTED ...

@ TD-er Saya agak lebih khawatir

connected with clumsy_ap2, channel 9
dhcp client start...
112113 : WIFI : Connected! AP: clumsy_ap2 (4C:5E:0C:39:F6:55) Ch: 9 Duration: 2895 ms
112115 : WIFI  : Arduino wifi status: WL_DISCONNECTED ESPeasy internal wifi status: ESPEASY_WIFI_CONNECTED

Bagi saya, dua baris terakhir menunjukkan bahwa inti belum memperbarui statusnya, meskipun ESPEasy mengira demikian ... jadi bisa berakhir dalam beberapa kondisi balapan di sini ...

setelah ini terjadi kadang-kadang saya mulai melihat banyak

7989956 : Read settings: ControllerSettings index: 0
7989997 : Read settings: ControllerSettings index: 0
7990130 : Read settings: ControllerSettings index: 0
7990267 : Read settings: ControllerSettings index: 0
7990399 : Read settings: ControllerSettings index: 0
7990531 : Read settings: ControllerSettings index: 0
7990664 : Read settings: ControllerSettings index: 0
7990799 : Read settings: ControllerSettings index: 0
7990938 : Read settings: ControllerSettings index: 0

dari mana ia tidak pernah pulih ...

beberapa saat kemudian saya diberitahu:

8185850 : ip:169.254.37.119,mask:255.255.0.0,gw:0.0.0.0
Read settings: ControllerSettings index: 0
8185975 : WIFI : DHCP IP: 169.254.37.119 (wemos-mini-18-18) GW: (IP unset) SN: 255.255.0.0
8185990 : EVENT: WiFi#Connected

Tidak ada petunjuk dari mana asalnya ... tetapi setelah ini mulai mencoba terhubung ke pengontrol / server yang jelas gagal sampai kehabisan percobaan (100) dan reboot ...

EDIT: btw, Anda dapat memaksa perilaku ini jika Anda menendang node dari AP secara manual ... terkadang itu hanya terhubung kembali, terkadang terjadi seperti yang dijelaskan di atas ...
EDIT2: kadang-kadang crash dengan Pengecualian 9 ... jadi tampaknya semacam kondisi balapan bagaimana tepatnya itu pulih dari pemutusan! salahku, punya addLog() di callback onDisconenct() ...

kurang lebih selalu situasinya sama. setelah jabat tangan 4 arah gagal (rekeeying) tidak pernah pulih lagi ... tidak yakin bagaimana cara memaksa pemulihan ini ..

setidaknya menambahkan beberapa delay(100) di processConnect() dan processDisconnect sehingga memberikan waktu inti untuk memperbarui status WiFi membuat satelit WiFi disinkronkan lagi. Ini juga membuat unit jauh lebih jarang masuk ke situasi di bawah ini!

900695 : WIFI : DHCP renew probably failed
900697 : Reset WiFi.
900699 : WIFI : Connecting clumsy_ap2 attempt #0
901713 : EVENT: WiFi#Disconnected
901772 : WIFI : Disconnected! Reason: '(8) Assoc leave' Connected for 14 m 56 s
902326 : WD   : Uptime 15 ConnectFailures 44 FreeMem 20248 WiFiStatus 0
907048 : EVENT: WiFi#Disconnected
907106 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 6172 ms
907786 : WIFI : Connecting clumsy_ap2 attempt #1
911821 : EVENT: WiFi#Disconnected
911879 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3860 ms
911894 : WIFI : Connecting clumsy_ap2 attempt #2
912793 : EVENT: Clock#Time=Sat,08:29
919974 : EVENT: WiFi#Disconnected
920033 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 7962 ms
920824 : WIFI : Connecting clumsy_ap2 attempt #3
922083 : EVENT: WiFi#Disconnected
922141 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1125 ms
922805 : WIFI : Connecting clumsy_ap2 attempt #4
923138 : EVENT: WiFi#Disconnected
923196 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 133 ms
925831 : WIFI : Connecting clumsy_ap2 attempt #5
931179 : EVENT: WiFi#Disconnected
931238 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5165 ms
931775 : WIFI : Set WiFi to AP+STA
932701 : EVENT: WiFi#APmodeEnabled
932778 : WIFI : AP Mode ssid will be wemos-mini-17_17 with address 192.168.4.1
932778 : WIFI : Connecting clumsy_ap2 attempt #6
933023 : WD   : Uptime 16 ConnectFailures 44 FreeMem 17856 WiFiStatus 0
934065 : EVENT: WiFi#Disconnected
934122 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1123 ms
935712 : WIFI : Connecting clumsy_ap2 attempt #7
936042 : EVENT: WiFi#Disconnected
936106 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 169 ms
938745 : WIFI : Connecting clumsy_ap2 attempt #8
939079 : EVENT: WiFi#Disconnected
939138 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 131 ms
941778 : WIFI : Connecting clumsy_ap2 attempt #9
947130 : EVENT: WiFi#Disconnected
947189 : WIFI : Disconnected! Reason: '(15) 4way handshake timeout' Connected for 5140 ms
947725 : WIFI : Connecting clumsy_ap2 attempt #10
948976 : EVENT: WiFi#Disconnected
949035 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 1121 ms
951805 : WIFI : Connecting clumsy_ap2 attempt #11
952140 : EVENT: WiFi#Disconnected
952199 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 134 ms
955778 : WIFI : Connecting clumsy_ap2 attempt #12
956115 : EVENT: WiFi#Disconnected
956174 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 142 ms
959734 : WIFI : Connecting clumsy_ap2 attempt #13
960064 : EVENT: WiFi#Disconnected
960123 : WIFI : Disconnected! Reason: '(203) Assoc fail' Connected for 129 ms

@ TD-er tryConnectWiFi() mengembalikan true atau false seandainya koneksi berhasil atau tidak ... namun WiFiConnectRelaxed() sebenarnya tidak pernah memeriksa ini ...

apakah fungsi ini entah bagaimana dari sebelumnya WiFi berbasis acara? sepertinya tidak pernah mencapai 2 baris terakhir dalam fungsi itu ...

Ya itu semacam sisa dari sebelum wifi berbasis acara.
Saya pikir kita benar-benar harus mempertimbangkan untuk melihat dengan baik kode WiFi itu lagi, karena tidak terstruktur sebagaimana mestinya.

ok ... Saya masih men-debug apa yang sebenarnya terjadi karena batas waktu jabat tangan 4way dan mengapa node tidak dapat menyambung kembali .... tapi saya rasa saya masih sedikit bingung namun menemukan sedikit hal kecil di sini dan ada yang bisa bertambah ....

satu kecil lainnya tampaknya berada di WifiCheck() ... di sana memeriksa konektivitas lapisan 2 hanya dilakukan ketika IP tidak valid lagi (mis. semua oktet adalah 0). Hal ini dapat menyebabkan situasi di mana lapisan 2 dis- (atau kembali) terhubung / handshaking, dll. Tetapi IP masih valid karena belum kedaluwarsa (DHCP). Itu mungkin penyebab mengapa "perpanjangan DCHP mungkin gagal" hanya terjadi setelah waktu yang lama, ketika sewa benar-benar hilang ... tetapi saya masih memverifikasi ini ...

juga ada wifiCheck() , WiFiConnected() dan connectionCheckHandler() yang semuanya melakukan semacam pemeriksaan koneksi, dan saling memanggil serta resetWiFi() dalam kondisi tertentu .. .terutama connectionCheckHandler() tampaknya hanya dipanggil jika mqtt_reconnect_count > 10 . Jadi apa yang terjadi di lingkungan non-MQTT?

PS: Saya hanya mendokumentasikan temuan saya di sini mencari masalah WiFi yang mendasari ... Jadi saya senang untuk pemikiran tentang itu, tapi tidak perlu diharapkan ...

pasti ada semacam kondisi ras misterius di suatu tempat. ketika AP memulai reauth atau rekeeying terkadang node / core tidak mendapatkan cukup waktu cpu untuk menyelesaikan jabat tangan atau terganggu saat melakukannya, terutama pada node dengan sinyal rendah (dan karena itu jabat tangan memakan waktu lebih lama) .. . (Lihat di bawah).

rekeesings / reauths ini tampaknya menghasilkan peristiwa pemutusan oleh inti, meskipun inti akan melakukan negosiasi ulang otomatis atau menghubungkan kembali (seperti yang saya mengerti). tetapi kemudian tampaknya proses jabat tangan ini terganggu oleh mesin status ESPEasy karena sambungan ulang manual dipicu ... proses ini berulang dan tidak pernah berakhir (atau dalam beberapa kasus menghasilkan wdt) ..

` 810114 : EVENT: WiFi#Disconnected 810146 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 13 m 16 s 810977 : WIFI : Connecting clumsy_ap2 attempt #0 811081 : WIFI : Connection lost to: clumsy_ap2 813089 : EVENT: WiFi#Disconnected 813120 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2011 ms 814977 : EVENT: Clock#Time=Thu,08:55 821529 : WD : Uptime 14 ConnectFailures 0 FreeMem 22000 WiFiStatus 0 831976 : WIFI : Connecting clumsy_ap2 attempt #1 832079 : WIFI : Connection lost to: clumsy_ap2 836831 : EVENT: WiFi#Disconnected 836863 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4753 ms

Jadi mungkin kita harus menggunakan acara wifi hanya untuk memantau prosesnya, bukan mengambil tindakan sendiri?
Mengubah ini akan membuat versi 2.3.0 dan mungkin 2.4.0 tidak dapat digunakan.

Tidak, saya tidak akan melakukan itu ... Di cabang saya, saya sudah melakukan beberapa perubahan (tidak terlalu mengganggu) yang tampaknya membuat kasus ini lebih jarang terjadi ...

baru saja menemukan hal kecil lainnya: di tryConnectWiFi() cek WiFi.status() menunjukkan akhir setelah panggilan WiFi.begin() mulai mengembalikan WL_DISCONNECTED . Menurut Dokumentasi ini berarti "jika modul tidak dikonfigurasi dalam mode stasiun". mencoba mencari tahu mengapa ini terjadi atau sebenarnya apakah itu membantu untuk menempatkan esp secara eksplisit dalam mode AP sebelum memanggil WiFi.begin()

Jadi saya masih berharap untuk menemukan masalah mendasar yang "sebenarnya" mengapa kios ini terjadi ... Jika demikian (semoga saja) saya sarankan, agar saya melakukan PR dengan semua perubahan untuk Anda (dan orang lain) untuk meninjau ....

Perlu diketahui bahwa saya juga telah melihat banyak dan banyak situasi di mana status WiFi.status() tidak benar.
Jadi mungkin pustaka inti sekarang memiliki perbaikan dan kemungkinan besar saya juga mengacaukannya di suatu tempat dalam semua upaya untuk membuat WiFi berperilaku stabil.
Proses debug itu sangat sulit dilakukan, karena saya tidak dapat mereproduksi masalah ini sendiri dan harus menindaklanjuti laporan pengguna lain.
Belakangan ini saya memiliki modul yang juga berperilaku buruk terkait WiFi, jadi itu modul tes WiFi favorit saya. Tapi itu juga bisa menjadi indikasi masalah akan menjadi lebih buruk ketika beberapa bagian hampir keluar dari spesifikasi. Misalnya catu daya, atau kapasitor decoupling hilang, (terlalu) jejak PCB tipis, lebih sedikit pelindung, dll.

tentu, bukan berarti saya mengesampingkan masalah HW. Tetapi saya memiliki ~ 40 node yang berjalan, dengan semua jenis catu daya yang berbeda, berbagai papan, merek, dll ... dan pada suatu saat sebagian besar dari mereka menghadapi masalah konektivitas ... terutama yang dengan jangkauan wifi yang lemah atau banyak GPIO sedang digunakan ..

Dan saat ini saya memiliki sedikit waktu untuk melakukan beberapa debugging dan saya masih merasa sangat menarik dan menantang;) Sekarang saya bahkan mulai memahami bagaimana keseluruhan urutan menghubungkan, memeriksa, memutuskan hubungan dan sebagainya bekerja;)

Jadi jika tidak masalah bagi Anda, saya akan terus menggali lebih dalam masalah konektivitas ini .... Anda bosnya ....

Silakan lanjutkan menggali :)
Saya benar-benar ingin terbebas dari semua masalah pemutusan hubungan yang hampir mustahil untuk direproduksi.
Mereka sudah memakan waktu terlalu lama sekarang dan akan sangat bagus jika diperbaiki.

Saya mendapatkan sekitar 4-24 jam waktu aktif diikuti oleh rata-rata 2-10 jam waktu tidak aktif.
Selama waktu henti, node terus bekerja, tetapi tidak ada koneksi wifi.

Accesspoint (MikroTik) menunjukkan:

18:16:15 wireless,info 80:xx:xx:xx:xx:xx<strong i="8">@iotnet</strong>: connected, signal strength -62 
18:16:20 wireless,info 80:xx:xx:xx:xx:xx<strong i="9">@iotnet</strong>: disconnected, unicast key exchange timeout 
18:17:31 wireless,info 80:xx:xx:xx:xx:xx<strong i="10">@iotnet</strong>: connected, signal strength -60 
18:17:36 wireless,info 80:xx:xx:xx:xx:xx<strong i="11">@iotnet</strong>: disconnected, unicast key exchange timeout 

ESP Mudah | Informasi |
----- | ----- |
Bentukan: ⋄ | 20103 - Mega |
Pustaka: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 dukungan PUYA |
Versi GIT: ⋄ | mega-20190110 |
Plugin: ⋄ | 7 [Normal] [Sonoff POW R1 / R2] |
Waktu pembuatan: ⋄ | Jan 10 2019 03: 21: 19 |
Nama file biner: ⋄ | ESP_Easy_mega-20190110_hard_SONOFF_POW_4M.bin |

Ini bukan masalah pada versi lama (ketika saya masih bisa menggunakan saluran 14 dan memiliki jaringan ssid tersembunyi).

Apakah Anda memiliki saluran WiFi tetap, atau itu variabel?
Saya telah membaca di halaman pemecahan masalah di Tasmota dan mereka sangat menyarankan agar saluran WiFi diperbaiki.
Jika saluran 14 tidak dapat digunakan, maka sesuatu tentang pengaturan regional mungkin telah berubah di suatu tempat, karena hanya saluran 1-11 yang diperbolehkan di semua negara.
Juga saluran 1, 6 & 11 sebenarnya adalah satu-satunya saluran yang dapat digunakan tanpa gangguan dari saluran lain.

hanya saluran 1-10 yang berfungsi, bukan 11. Lihat ini: https://github.com/letscontrolit/ESPEasy/issues/1337#issuecomment -394118989

Saluran Wifi sudah diperbaiki, tentu saja.

Saluran apa pun dapat mengalami gangguan dari saluran lain, tidak ada cara untuk mengontrolnya. Sial, bahkan bisa ada gangguan dari saluran yang sama.

btw, mengenai masalah yang saya hadapi - status wifi led (terbalik GPIO13) biasanya berwarna biru solid, tetapi ketika perangkat offline, itu masuk dalam pola 0,0,0,0,0,1,2,3, 4,5,6,7,8,9,0,0,0,0,0,0,0,0,1,2,3,4,5,6,7,8,9,0,0, 0,0,0, ... kecerahan.

Memperbaiki IP dan DCS, tetapi salurannya tidak pernah berubah di masa lalu.

Von: Gijs Noorlander [mailto: [email protected]]
Gesendet: Freitag, 11. Januar 2019 21:47
J: letscontrolit / ESPEasy
Cc: Berlangganan
Betreff: Re: [letscontrolit / ESPEasy] [BUG] [stabilitas WiFi] Pengecualian ESP 3/29 saat lapisan 2 terputus (# 1987)

Apakah Anda memiliki saluran WiFi tetap, atau itu variabel?
Saya telah membaca di halaman pemecahan masalah di Tasmota dan mereka sangat menyarankan agar saluran WiFi diperbaiki.
Jika saluran 14 tidak dapat digunakan, maka sesuatu tentang pengaturan regional mungkin telah berubah di suatu tempat, karena hanya saluran 1-11 yang diperbolehkan di semua negara.
Juga saluran 1, 6 & 11 sebenarnya adalah satu-satunya saluran yang dapat digunakan tanpa gangguan dari saluran lain.
-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment-453651579 , atau nonaktifkan https://github.com/notifications/unsubscribe-auth/AomgSxPjVKWrp0MSQTtbESKxFqaPVt90ks5vPCPg4 . https://github.com/notifications/beacon/AomgS_fhHQnmg1AdpX11mVL9yNra8S_kks5vCPgxgaJpZM4YDivP.gif

Barang mikrotik memberikan kekuatan besar tetapi bahkan pengaturan default untuk wifi tidak tepat.

• Pastikan Anda tidak memiliki pengaturan keamanan tkip dan hanya mengaktifkan enkripsi aes ccm
• Masukkan Pembaruan grup kunci seperti 30 menit atau 1 jam
• di saluran memiliki lebar saluran 20Mhz dan menurut saya dich band B dan pergi hanya untuk G / N
• Saluran Ekstensi dinonaktifkan
• Hanya menonaktifkan PMKID (disarankan jika Anda histeris tentang keamanan) tampaknya membuat Esp veeeery tidak senang
• Tambahkan negara Anda ke pengaturan wifi (atau lihat berapa daya maksimal Anda untuk AP yang Anda miliki dan turunkan daya transmisi sebesar 3). Ini sangat sering meningkatkan kinerja wifi (kontra intuitif, saya tahu)

Saya biasanya tidak memiliki pemutusan (kecuali ketika saya memiliki PMKID ini)

Bagaimanapun, akan sangat berguna untuk memposting pengaturan AP Anda :-)

Itu adalah tips yang bagus. Saya cukup fasih dengan jaringan dan bahkan lebih berpengalaman dalam mikrotik dan saya telah mengkonfigurasi semua seperti yang Anda katakan kecuali kunci grup.

Pembaruan kunci grup hanya ada hubungannya dengan kunci grup, bukan kunci unicast di mana masalahnya juga, tetapi saya telah menurunkan pengaturan itu untuk tujuan percobaan.

@ 0ki Cool tidak tahu Anda di mana ahli RouterOS!

Saya telah menyimpulkan bahwa itu jelas bug di perangkat lunak ESPEasy. Anda dapat melihat perilaku bermasalah di sebelah kanan yang sesuai dengan RouterOS yang memutuskan klien yang berperilaku buruk di sebelah kiri. Spektrum radionya jelas seperti yang Anda lihat.

Sayangnya saya tidak punya waktu untuk mempelajari basis kode ESPEasy sekarang, tetapi saya percaya perbandingan komunikasi yang buruk vs komunikasi yang baik ini akan berguna.
Legenda: __red - titik akses | biru - espeasy | hijau - perangkat lain di jaringan iot saya__

Saya percaya bahwa ESP_easy karena alasan tertentu memutuskan untuk beralih ke mode AP setelah menerima respons assoc (bingkai 380 di sebelah kiri) dan tidak melanjutkan jabat tangan empat arah. Perhatikan juga perubahan alamat utama espeasy - oktet pertama berubah dari 80 menjadi 82.

@ 0

Saya telah menyimpulkan bahwa itu jelas bug di perangkat lunak ESPEasy.

Saya juga, tapi saya tidak tahu di mana bug itu seharusnya.
Sepertinya keadaan internal ESPeasy tentang keadaan terputus tidak sinkron dengan keadaan sebenarnya.
Sangat mungkin saya membuat beberapa kesalahan dalam menulis kode itu, atau itu adalah bug di pustaka inti.

File mana yang secara spesifik Anda maksud dengan "kode itu"? Jika Anda menunjuk ke satu atau dua file, saya bisa melihatnya.

Jika tidak - karena sekarang Anda melihat saat yang tepat di mana itu terjadi, saya harap Anda dapat melihatnya lebih dekat.

Saat saya sedang menggali masalah ini (selama sekitar 2 bulan sekarang) saya tidak sepenuhnya yakin lagi apakah itu kode ESPEasy itu sendiri. lebih merupakan interaksi antara ESPEasy dan inti / perpustakaan WiFi ... Debug / log saya menunjukkan bahwa "Putuskan sambungan" selalu terjadi setelah pertukaran kunci grup / rekeeying. TAPI callback hanya dipanggil setelah rekeying timeout dan kemudian setelah otentikasi gagal ... Jadi saat ini tebakan saya adalah, bahwa ESPEasy tidak meninggalkan cukup waktu cpu ke inti untuk benar-benar melakukan rekeeying ... sampai sekarang saya tidak Namun, tidak menemukan cara untuk mengetahui kapan node berada dalam node rekeeying ini atau dalam mode reauth dan oleh karena itu dapat menambahkan cukup delay() panggilan sehingga reauth rekeeying berhasil ...

Untuk membantu menentukan masalah tepat waktu - itu berfungsi dengan baik:

Build   20100 - Mega (core 2_3_0)
GIT version mega-20180224
Plugins 48 [Normal]
Build Md5   719b94a4d6bc257b86916e4989eed3a0
Md5 check   passed.
Build time  Feb 24 2018 03:03:12

Dan oke, maksud saya tidak hanya tidak ada pemutusan, tetapi juga menghubungkan ke AP tersembunyi di saluran 14 tidak menjadi masalah.

@ kikuk-stefan, saya sepenuhnya mendukung penangkapan masalah yang menyebabkannya memutuskan sambungan di tempat pertama, tetapi jujur, mungkin ada sejumlah alasan mengapa wifi assoc dapat turun, tentu saja pertukaran kunci grup tidak boleh salah satu dari mereka.

Masalah yang lebih mendesak adalah - mengapa tidak bisa tersambung kembali setelah terputus. Ini bukan masalah waktu, karena saya memberi espeasy waktu 5000ms untuk membalas dengan pesan 2 dari 4way HS.

Saya pikir masalahnya adalah, Anda hanya mendapatkan pemutusan SETELAH pertukaran kunci gagal ... jadi Anda tidak pernah sekarang ketika pertukaran benar-benar dimulai, di situlah Anda perlu memberikan lebih banyak waktu untuk inti ...

di log Anda dapat melihat bahwa ESPEasy berpikir untuk beberapa waktu itu masih terhubung, meskipun tidak (bahkan ping ke node gagal), tetapi node masih mencoba mengirim data (dan jelas koneksi gagal saat itu) ...

Masalah kedua yang saya setujui sepenuhnya adalah, meskipun terputus, mengapa tidak dapat terhubung kembali dengan urutan koneksi yang benar-benar baru ... mungkin modul atau inti macet dalam keadaan yang aneh?

EDIT: PS: HS 4way tidak selalu gagal, (saya melakukannya setiap 10 menit.), Jadi sepertinya kombinasi dari keadaan / kesibukan ESPEasy dan waktu kemudian HS terjadi ..

Apa yang dapat saya lakukan adalah mencoba untuk benar-benar menjatuhkan WiFi (mematikan modem juga) dan mulai menyambungkan kembali sepenuhnya ketika pemutusan yang tidak terduga terjadi.
Tidak yakin apakah itu ada di utas ini, tetapi dalam salah satu masalah ini, seseorang membalas dengan tweet seseorang di Shelly, yang menyebutkan bahwa mereka harus memulai ulang tumpukan wifi sepenuhnya setelah memutuskan sambungan.

@ TD-er itu juga yang saya masukkan di versi terbaru saya. dalam processDisconnect() Saya menambahkan setWifiMode(WIFI_OFF); meskipun tidak yakin, jika itu cukup ... saat ini berjalan pada beberapa node uji (karena sekitar 1 jam) ...

@ TD-er itu ide yang bagus. mendorong rilis git dan saya akan mem-flash barang saya!

Saya baru saja mulai membaca beberapa basis kode 5 menit yang lalu, jadi ini mungkin tidak relevan, tetapi: Pastikan juga wifi_connect_attempt disetel ke 0 pada saat itu.

hmm ... menambahkan beberapa delay(0) dalam backgroundtasks() setelah setiap panggilan subrutin, tampaknya lebih menstabilkan edisi pertama (4way-HS). Tidak yakin apakah itu kebetulan yang sulit ...
@ TD-er mungkinkah, bahwa backgroundtasks() memblokir eksekusi di beberapa titik waktu?

secara umum: menambahkan delay(0) di semua jenis tempat berbeda di mana timingstats menunjukkan waktu pemrosesan yang lama tampaknya banyak meningkatkan penanganan 4way-HS. Saya memiliki lebih banyak pengawas SW / HW yang bekerja sekarang daripada masalah rekeeying (tetapi masih memiliki beberapa) ... secara simtomatis jadi saya akan mengatakan itu benar-benar terkait dengan bagian inti / wifi tidak mendapatkan cukup siklus untuk benar-benar melakukan (cukup cepat) hal-hal seperti rekeeying dan AP kemudian bosan menunggu jawaban ...

Apa yang juga saya lihat adalah terkadang client.connect() atau sendData() bisa memakan waktu cukup lama (hingga 2 detik). Dalam beberapa dokumentasi saya menemukan bahwa jika sesuatu membutuhkan lebih dari 50ms, Anda harus memanggil delay(0) inbetween .... tetapi Anda tidak dapat membagi panggilan ini karena dilakukan oleh perpustakaan ...

Ada juga panggilan balik lain onStationModeAuthModeChanged di inti. Mungkin akan layak untuk dilihat, karena yang satu ini mungkin dipicu sebelum pemutusan yang sebenarnya terjadi. tetapi sangat sedikit yang didokumentasikan ... Ada yang punya pengalaman dengan ini?

EDIT: sepertinya kebetulan / kondisi balapan dengan beberapa hal lain yang dilakukan pada saat AP meminta rekeying .... tapi sekali lagi hanya observasi ...

Saya tidak tahu seberapa sering permintaan yang dikirim oleh AP ini dikirim ulang.
Biasanya sinyal beacon dari AP dikirim setiap 102,4 msec. Jika beberapa tugas membutuhkan lebih dari itu, ESP melewatkan salah satu bingkai suar tersebut. Jadi saya tidak yakin seberapa buruk ini.
Saya tahu bahwa permintaan ARP kadang-kadang terlewat, yang mengarah pada masalah bahwa switch tidak tahu lagi bagaimana merutekan paket ke alamat MAC itu dan dengan demikian membuat ESP tidak dapat dijangkau, sementara itu masih dapat mengirim data itu sendiri.

bingkai suar yang hilang bukanlah apa-apa. itu bahkan tidak perlu bingkai suar karena seharusnya secara aktif menyelidiki jaringan tersembunyi saya.

Saya bukan ahli WiFi.
Seperti yang saya pahami, interval suar adalah satu-satunya momen yang dijamin-agak- ESP mencoba mendengarkan WiFi dan di antaranya akan mencoba tidur sebanyak mungkin.

Dan seperti yang saya pahami, satu-satunya perbedaan antara jaringan 'tersembunyi' dan jaringan 'tidak tersembunyi' adalah SSID tidak disiarkan. Jadi sebenarnya itu menghubungkan hanya berdasarkan BSSID (MAC-address of AP).
Itu juga yang dilakukan ESP saat menghubungkan ke jaringan WiFi (tidak tersembunyi), dengan satu-satunya perbedaan bahwa ESP akan melakukan pemindaian sebelumnya dan mencoba menemukan BSSID yang memiliki SSID yang cocok dengan yang diberikan.
Saat melakukan koneksi ulang otomatis, ini akan mencoba kombinasi saluran BSSID + terakhir yang diketahui terlebih dahulu tanpa melakukan pemindaian. Dengan kata lain, ini hanya berbeda saat membuat sambungan.

Jadi sepengetahuan saya, selama ada koneksi ke jaringan, itu juga akan mendengarkan bingkai suar.

Saya bukan ahli WiFi.
Seperti yang saya pahami, interval suar adalah satu-satunya momen yang dijamin-agak- ESP mencoba mendengarkan WiFi dan di antaranya akan mencoba tidur sebanyak mungkin.

Dan seperti yang saya pahami, satu-satunya perbedaan antara jaringan 'tersembunyi' dan jaringan 'tidak tersembunyi' ..........

Oh, itu mengingatkan saya sesuatu yang mungkin sangat penting. Saya menjalankan ESP saya di SSID tersembunyi
Ngomong-ngomong masih tidak ada pemutusan atau reboot pada node saya (mencoba 5 menit pembaruan kunci grup)

Salah satu node saya di-boot ulang pada tanggal 5 Desember karena pemadaman listrik.

Ini dari yang itu:

Satuan: | 5
- | -
Waktu Setempat: | 2019-01-15 23:27:32
Uptime: | 41 hari 12 jam 46 menit
Beban: | 15,80% (LC = 9135)
Nona gratis: | 12160 (5360 - sendContentBlocking)
Tumpukan Gratis: | 3552 (1520 - SensorSendTask)
Boot: | Boot dingin (0)
Atur Ulang Alasan: | Sistem Eksternal
Jaringan ❔
Wifi: | 802.11N (RSSI -67 dB)
Konfigurasi IP: | DHCP
IP / subnet: | 192.168.1.89 / 255.255.255.0
GW: | 192.168.1.1
IP Klien: | 192.168.1.67
DNS: | 192.168.1.1 / 0.0.0.0
Rentang IP yang Diizinkan: | Semua Diizinkan
STA MAC: | 5C: CF: 7F: B1: 3F: 12
AP MAC: | 5E: CF: 7F: B1: 3F: 12
SSID: | Lurch4 (34: 31: C4: B1: 8D: C7)
Saluran: | 11
Terhubung: | 20h04m
Alasan Pemutusan Terakhir: | (202) Otorisasi gagal
Nomor menghubungkan kembali: | 61
Firmware
Bangun: ⋄ | 20102 - Mega
Perpustakaan: ⋄ | ESP82xx Core 2_4_2, NONOS SDK 2.2.1 (cfd48f3), LWIP: 2.0.3 dukungan PUYA
Versi GIT: ⋄ | mega-20181109
Plugin: ⋄ | 46 [Normal]
Bangun Md5: | 47f19d99d0c3f083314b45668b1f5c
Md5 cek: | lulus.
Waktu pembuatan: ⋄ | 9 November 2018 03:23:22
Nama file biner: ⋄ | ESP_Easy_mega-20181109_normal_ESP8266_4096.bin

Seperti yang Anda lihat, rata-rata lebih dari satu pemutusan dalam sehari. Terhubung ke AVM Fritzbox 1750E

Saya pikir bingkai suar tidak begitu penting ... Saya masih tidak jelas mengapa setelah memutuskan urutan normal WiFi.begin() selalu gagal dengan '(2) Auth expire' .

Satu-satunya indikasi adalah, bahwa Beban CPU pada saat ini selalu menunjukkan 100% dan mengisyaratkan bahwa inti tidak mendapatkan cukup waktu untuk melakukan jabat tangan ...

Dugaan saya adalah ada yang salah di pustaka inti (LWIP atau Arduino atau ESP) dan kami harus mengatur ulang wifi.
Jadi matikan wifi dan mulai dari awal lagi. Mungkin juga menunggu di antara langkah-langkah tersebut untuk memastikan buffer dikosongkan atau setidaknya dibilas dan permintaan yang belum selesai secara aktif dibatalkan.

@ TD-er dapatkah Anda mendorong perubahan ini, jadi saya dapat melihat apakah berhasil?

Perubahan yang dibahas dalam 2 posting terakhir?
Ini belum diimplementasikan, tapi saya bisa mencoba malam ini untuk mengkodekannya dan membuat uji coba.

Ya, menyetel ulang wifi.

@ TD-er menulis:

Jadi matikan wifi dan mulai dari awal lagi. Mungkin juga menunggu di antara langkah-langkah tersebut untuk memastikan buffer dikosongkan atau setidaknya dibilas dan permintaan yang belum selesai secara aktif dibatalkan.

Tidak yakin aout pembilasan ... karena saya menghapus semua client.flush() panggilan sebelum client.stop() Tampaknya juga pemutusan hubungan lebih jarang terjadi. Saat membaca beberapa dokumentasi, saya melihat bahwa flush mengosongkan semua buffer input (tcp), jadi secara teoritis bisa terjadi balasan hilang ...

Hanya menambahkan 2c saya, saya memiliki beberapa Mikrotik AP, dengan beberapa sonoff menjalankan espurna dan beberapa NodeMCU menjalankan ESPEasy. Saya harus menambahkan AP ekstra untuk perangkat ESP, karena selama periode lalu lintas tinggi di jaringan saya, seperti cadangan, saya akan kehilangan perangkat ESP saya. Saya pikir ini adalah kekuatan sinyal WiFi dan lalu lintas terkait. Setelah AP ekstra ditambahkan, saya tidak ingat melihat masalah ini lagi.

Tetapi perangkat NodeMCU dan ESPEasy saya memiliki beberapa pemutusan. Saya akan mengatur monitor ping netdata ke perangkat dan melihat apakah saya dapat mengetahui kapan, bagaimana dan mengapa ini mungkin terjadi dan melihat apakah saya memberikan beberapa info kembali.

Catatan lain, saya tidak memiliki 40+ perangkat seperti @ clumsy-stefan, hanya sekitar 5 pengguna dan perangkat seluler mereka dan perangkat pintar aneh seperti TV, tetapi mungkinkah perangkat Mikrotik kelebihan beban atau jaringan WiFi RF jenuh ?

Saya berharap saya memiliki cara untuk melihat jumlah kebisingan RF. Saya memiliki aplikasi (WiFi Analyzer) yang menunjukkan jumlah AP dan cara penyebaran saluran WiFi. Saya menggunakan alat ini untuk mengatur saluran WiFi saya untuk AP WiFi yang berbeda.

Tetapi tidak dapat memastikan apakah mungkin ada gangguan RF lainnya.

Adapun gagasan perangkat Mikrotik yang kelebihan beban, saya menggunakan MikroTik 951UI-2HND untuk router utama saya dan MikroTik RB9412nD hAP lite sebagai ESP AP saya.

Saya ingin tahu apakah info itu berguna?

@LeeNX terima kasih atas petunjuknya. node saya didistribusikan melalui 3 AP dan RF agak seimbang (maks. 20 klien per AP atau lebih), sehingga ada gangguan sesedikit mungkin (tentu saja tidak mungkin tidak ada ...). Jadi saya tidak berpikir MT kelebihan beban (saya bekerja di perusahaan yang menyediakan konektivitas tulang punggung jaringan dan WLAN untuk acara profesional, dll. Jadi saya memiliki beberapa tes infrastruktur yang cukup mendalam), tetapi saya setuju bahwa waktu udara yang berlebihan dapat menjadi masalah ... namun meskipun demikian, sebuah node tidak pernah dapat menyambung kembali selama> 250 kali setelah terputus dan kemudian setelah reboot segera terhubung kembali saya pikir tidak bisa menjadi masalah airtime ... selain itu saya tidak ' tidak melihatnya di perangkat lain ...
jadi saya masih berpikir itu adalah kebetulan atau kondisi balapan antara keadaan chip wifi internal, jumlah waktu cpu yang didapat inti wifi dan tugas-tugas lain apa yang sedang berjalan di bagian ESPEasy ...

@ kikuk-stefan Saya setuju dengan wawasan Anda. Saya hanya ingin menunjukkan bahwa menggunakan Mikrotik AP kecil dengan 40+ node, bisa saja merupakan CPU Mikrotik atau RAM yang terbatas, tetapi sepertinya bukan itu masalahnya.

Saya bertanya-tanya apakah dpeloying ESP32 dan perangkat NodeMCU dengan tidak lain adalah inti ESPEasy dasar dan biarkan berjalan, sehingga kami dapat menguji ESP CPU dan tidak ada pengaruh plugin lainnya. Lihat apa yang dapat saya terapkan dan uji ping netdata.

Jika ini memberi kami info berguna, saya akan melaporkan kembali.

Terima kasih Guys !!!

Saya memiliki node di sini yang berjalan hampir tidak ada (IR RX / TX) dan berjalan selama berminggu-minggu tanpa masalah.
Node lain yang memiliki waktu aktif lebih dari 40 hari menjalankan Domoticz MQTT dan BME280 + MH-Z19 CO2.
Jadi mungkin juga akan tergantung pada plugin mana yang sedang berjalan dan seberapa sering dan mungkin juga jika interval baca selalu cocok dengan interval baca plugin lain.

Saya sudah mengatur beberapa panggilan fungsi berkala (10 / detik, 1 / detik dan 30 detik) dengan offset awal di penjadwal sehingga mereka tetap berjalan sebanyak mungkin dalam panggilan loop yang berbeda.

Mungkin saya juga harus menambahkan beberapa acara yang digerakkan oleh pengatur waktu interupsi seperti yang dilakukan Tasker (atau cukup gunakan tasker alih-alih penjadwal yang saya tulis) dan mengatur satu tugas pada interval 10 msec untuk menjalankan penundaan (0).
Hanya masalahnya, itu dapat mengganggu transfer GPIO lainnya dan dengan demikian mengganggu pembacaan sensor.

yang mungkin akan menyelesaikan masalah 4way-HS, tapi saya rasa bukan masalah menyambung kembali ... itu masih yang paling aneh ... Saya baru saja simpul uji saya gagal lagi selama 12 jam mencoba menyambung kembali selama> 300 kali ke AP tanpa keberhasilan. setelah (soft-) mem-boot ulang, itu terhubung kembali secara instan (reboot + menghubungkan kembali membutuhkan waktu sekitar 5 detik atau lebih) ...

Saya baru saja menemukan masalah ini yang tampaknya cukup terkait dengan apa yang kita lihat di sini:
https://github.com/esp8266/Arduino/issues/5527

terlihat mirip, ya ... tetapi memanggil wifi MATI tampaknya tidak mengubahnya (mencobanya), saat ini saya mencoba dengan WiFi.setOutputPower(0) sebelum memanggil WiFi.begin() seperti yang disarankan di sini
https://github.com/esp8266/Arduino/issues/2235
dan di sini
https://github.com/esp8266/Arduino/issues/2186#issuecomment -233853152
masih menunggu itu terjadi sekarang tangguh ...

itu mirip tapi tidak sama. Infact dalam kasus kami me-reboot AP menyelesaikan masalah, dalam masalah yang diposting oleh Gijs, me-reboot AP tidak menyelesaikan masalah.

@ giig1967g me-reboot AP tidak menyelesaikannya untuk saya! hanya me-reboot node membuatnya terhubung kembali (meskipun di lingkungan saya) ...

@ giig1967g Dalam masalah yang disebutkan oleh @ clumsy-stefan, reboot AP ini juga disebutkan: https://github.com/esp8266/Arduino/issues/2235#issuecomment -248851270

Jadi sepertinya kami memiliki beberapa masalah di sini.

@ kikuk-stefan
Ah ok. Dan dalam kasus saya hanya dengan Mikrotik ... :(
@ TD-er
mungkin Anda harus bertanya merek / model AP mana yang mereka gunakan ...

@ giig1967g Saya juga memiliki beberapa node di sini yang tidak dapat dijangkau, tetapi interval dari peristiwa tersebut lebih dari 10 hari, jadi agak sulit untuk mengatakan apakah ini terkait dengan salah satu masalah ini.
Sekitar setengah dari node saya sekarang terhubung ke Mikrotik dan setengah lainnya terhubung ke Fritzbox 1750E

@ giig1967g Saya juga hanya memiliki MT ... dan tampaknya lebih sering terjadi pada node dengan sinyal yang lebih lemah dan node yang menggunakan GPIO (khususnya PCF) ...

Saya berharap saya memiliki cara untuk melihat jumlah kebisingan RF. Saya memiliki aplikasi (WiFi Analyzer) yang menunjukkan jumlah AP dan cara penyebaran saluran WiFi. Saya menggunakan alat ini untuk mengatur saluran WiFi saya untuk AP WiFi yang berbeda.

Tetapi tidak dapat memastikan apakah mungkin ada gangguan RF lainnya.

Anda dapat melakukan /interface wireless registration-table print interval=1 pada mikrotik Anda untuk melihat snr.

sayangnya WiFi.setOutputPower(0) juga tidak membantu ... setelah hampir 6 jam berjalan lancar (tanpa ada perubahan pada infrastruktur wifi, tiba-tiba ia menemui jalan buntu lagi (lihat keluaran serial di bawah) dari mana ia tidak pernah pulih, kecuali jika secara kebetulan SW atau HW WDT dimulai ...

ini hanya tampaknya terjadi setelah "Batas waktu pembaruan kunci grup" atau "jabat tangan 4 cara gagal". jika saya menendang node dari AP secara manual, node juga mendapat "auth expire" tetapi dapat menyambung kembali secara instan ...

keluaran serial (bukan beban pergi ke 100% kemudian) ...

20457441 : WIFI : Disconnected! Reason: '(16) Group key update timeout' Connected for 2h19m
20457593 : WIFI : Connecting clumsy_ap2 attempt #0
20458607 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20459707 : EVENT: WiFi#Disconnected
20459763 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 2012 ms
20470762 : SYS  : 31.00,20048.00,66.70,341.00
20470766 : EVENT: sysinfo#rssi=31.00
20470824 : EVENT: sysinfo#mem=20048.00
20470882 : EVENT: sysinfo#load=66.70
20470940 : EVENT: sysinfo#uptime=341.00
20472658 : EVENT: Clock#Time=Thu,14:22
20473264 : WD   : Uptime 341 ConnectFailures 22 FreeMem 20040 WiFiStatus 0
20477609 : WIFI : Connecting clumsy_ap2 attempt #1
20478135 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20482577 : EVENT: WiFi#Disconnected
20482635 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 4771 ms
20503270 : WD   : Uptime 342 ConnectFailures 22 FreeMem 18440 WiFiStatus 0
20505709 : WIFI : Connecting clumsy_ap2 attempt #2
20506235 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20509784 : EVENT: WiFi#Disconnected
20509845 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3879 ms
20530897 : SYS  : 31.00,16248.00,100.00,342.00
20530902 : EVENT: sysinfo#rssi=31.00
20530963 : EVENT: sysinfo#mem=16248.00
20531025 : EVENT: sysinfo#load=100.00
20531087 : EVENT: sysinfo#uptime=342.00
20532688 : EVENT: Clock#Time=Thu,14:23
20533158 : WD   : Uptime 342 ConnectFailures 22 FreeMem 16240 WiFiStatus 0
20533716 : WIFI : Connecting clumsy_ap2 attempt #3
20534242 : WIFI : Not configured in Station Mode!!: clumsy_ap2
20537788 : EVENT: WiFi#Disconnected
20537851 : WIFI : Disconnected! Reason: '(2) Auth expire' Connected for 3865 ms

hanya komentar singkat: menambahkan wifi_set_phy_mode(PHY_MODE_11G); dan memaksa node ke mode 802.11g tampaknya setidaknya merupakan solusi. Saya tidak memiliki reboot unit apa pun sejak beberapa jam dan juga sekali atau dua kali unit pulih dari masalah batas waktu kunci grup di atas ...
mungkin terkait dengan

• ESP8266 SoftAP hanya mendukung 802.11b / g.

yang dicatat dalam dokumen ...

Saya akan perbarui nanti / besok jika tetap stabil ...

Seperti yang telah disebutkan (beberapa kali) oleh orang lain, sensitivitas juga harus ditingkatkan dengan beralih ke 802.11G.
Tujuan saya menentangnya adalah (dulu?) Bahwa sebagian besar AP mengalami masalah saat beralih antara N, G, dan B.
Apakah Anda memiliki klien campuran? (G dan N) aktif di AP yang sama?

Saya menggunakan mode yang berbeda di semua Mikrotik. Campuran B / G / N / AC, juga kedua band 2 / 5GHz termasuk AP virtual yang ditentukan ... Klien yang berbeda terhubung dengan mode berbeda pada AP yang sama, tanpa masalah (kecuali esp8266) ..

kabar baik (setidaknya untuk saya) ... node saya berjalan selama 12 jam terakhir tanpa terputus / reboot / macet!

memaksa node ke 802.11g tampaknya bekerja dengan lancar bersama-sama dengan AP MikroTik. setidaknya ini adalah solusi sederhana (selama Anda tidak memerlukan kecepatan tambahan 802.11n).

jika seseorang ingin menguji dirinya sendiri, cukup tambahkan ESPEasyWifi.ino sekitar baris 644 dalam fungsi tryConnectWiFi() baris berikut (setelah setupStaticIPconfig(); ):
WiFi.setPhyMode(WIFI_PHY_MODE_11G);

Saya hanya bisa menebak bahwa masalah muncul karena mode SoftAP tidak mendukung 802.11n dan node terhubung dalam mode N inti menjadi "bingung" entah bagaimana ... tapi saya rasa ini adalah masalah untuk diangkat dengan inti-orang. ..

Untuk ESPEasy ini dapat dibuat dapat dikonfigurasi, saya kira (@ TD-er?) Sehingga dapat dipilih pada halaman konfigurasi di mode mana ESP harus berjalan (B / G / N) ...

Ya saya akan menambahkan opsi pemilihan di pengaturan lanjutan.
Saya lupa siapa yang menanyakannya terlebih dahulu, tetapi akan mencarinya dan memuji dia juga dalam komit;)

sempurna!! Saya tidak membutuhkan kredit, saya hanya membutuhkannya untuk bekerja;) jadi silakan persembahkan untuknya !! 😄

Saat debugging saya menemukan beberapa hal kecil lain yang saya sarankan untuk diubah (seperti memanggil delay() tanpa syarat setelah panggilan plugin, beberapa tambahan {} dan beberapa tambahan pada keluaran logging. Haruskah saya melakukan PR untuk ASPIT ini atau apakah Anda ingin tetap seperti itu (menurut saya ini bukan perubahan penting, hanya beberapa perbaikan kecil yang mungkin terjadi)?

Tolong buat PR.
Setidaknya akan membantu diskusi dan melacak temuan Anda.
Juga menambahkan komentar ke apa yang telah Anda periksa akan membantu

Untuk referensi # 2012
Semua kredit untuk dev. tim!

Apakah patch ini juga menyertakan ide WiFi.setOutputPower (0)?

Saya telah menjalankan eksperimen selama 7 hari sekarang.
mega-20180224 node - nol reboot
mega-20190110 node - 35 reboot; 9 dari mereka hari ini.

Saya meninggalkan baris yang relevan di kode tetapi mengomentarinya. Jadi Anda perlu menghapus // (tentang baris 644) di ESPEasyWiFi.ino dan mengkompilasinya ulang!

@oki maaf, saya baru saja melihat saya salah membaca pertanyaan Anda ... Tidak, ini tidak disertakan karena saya tidak melihat perbedaan saat menyetel daya ke 0 sebelum menyambungkan kembali ... Jadi saya membuang yang itu lagi!

Saya telah menjalankan eksperimen selama 7 hari sekarang.
mega-20180224 node - nol reboot
mega-20190110 node - 35 reboot; 9 dari mereka hari ini.

Itu membandingkan secara efektif:

• inti 2.3.0 tanpa wifi berbasis acara
• inti 2.4.2 dengan wifi berbasis acara.

kabar baik (setidaknya untuk saya) ... node saya berjalan selama 12 jam terakhir tanpa terputus / reboot / macet!

memaksa node ke 802.11g tampaknya bekerja dengan lancar bersama-sama dengan AP MikroTik. setidaknya ini adalah solusi sederhana (selama Anda tidak memerlukan kecepatan tambahan 802.11n).

Saya melakukannya sebaliknya untuk pengujian.
Saya mengatur Mikrotik saya ke N-Mode saja dan yah ... semua ESP berjalan sejak> 12 jam tanpa reboot tunggal.

pendekatan yang baik dan valid juga! Sayangnya saya tidak dapat melakukan ini, karena saya melakukan sejumlah klien tanpa kemampuan N ...

Nonaktifkan mode B dan aktifkan G / N saja. Anda lebih baik tanpa mode B. Kecuali Anda memiliki ponsel lama atau (biasanya) pemindai kode batang wifi dari 10 tahun yang lalu yang hanya mendukung mode dan tarif B.

Sensitivitas tambahan antena dalam mode B juga tidak akan memainkan peran penting dalam jangkauan. Mode B hanya menghabiskan airtime. Secara harfiah tidak ada kekurangan dalam tidak menggunakan mode B dan tidak ada kekurangan dalam menggunakan mode N di atas G juga. Mode N memiliki jangkauan yang lebih baik dari B dan G juga.

@ jimmys01 Anda benar, mode B mungkin tidak digunakan di mana pun lagi ... tetapi saya tidak bisa hanya menggunakan N ... oleh karena itu terserah untuk menguji apa yang terjadi dalam mode G / N jika node tetap stabil dan dapat menyambung kembali jika terjadi waktu tunggu HS 4way ..

g / n tidak stabil untuk saya.

Apakah ini berarti bahwa esp8266 mengalami masalah setiap kali bertransisi antara mode (B / G / N)?

Apakah ini berarti bahwa esp8266 mengalami masalah setiap kali bertransisi antara mode (B / G / N)?

Sangat mungkin.
Saya telah melihat banyak masalah dengan beberapa perangkat (bukan yang ESP) yang hanya mendukung mode G.
Jika Anda menggunakannya dengan N perangkat, perangkat tersebut tampak tidak terjangkau.
Terkenal adalah HomeWizard dan beberapa kamera WiFi.

Dengan versi baru mega-20190121 ini ESP tampaknya lebih stabil, saya tidak mengalami masalah crash / Wlan sampai sekarang.
Tapi sekarang saya tidak bisa lagi mematikan OLED (framedPlugin). Ketika saya mengirim OLEDFRAMEDCMD, mematikan layar untuk beberapa saat yang sangat singkat dan kemudian menyala lagi.
Saya melakukan tes back to back dengan Versi lama (dari 2018) tampilan bereaksi seperti yang diharapkan.

Baru saja mencoba mega-20190121 dan stabilitas WiFi tetap sama. Itu macet dalam waktu sekitar satu jam sejak dimulai.

@ TD-er, kapan menurut Anda Anda dapat mendorong versi dengan perubahan yang telah didiskusikan sehingga saya dapat mengujinya?

pembaruan cepat: sejak pengaturan mode diperbaiki ke 802.11g, saya tidak lagi membeku, reboot, dll.! meskipun AP beroperasi dalam mode g / n campuran ... jadi saya juga akan memilih tambalan yang membuat mode wifi dapat dikonfigurasi di esp!

Berharap untuk tambalan segera juga 😉

Saya baru saja menambahkan komit untuk memilih B / G saja.
Ini belum berfungsi dengan baik di ESP32, jadi saya menonaktifkan opsi untuk memilihnya untuk ESP32.
Saya juga menambahkan opsi mundur agar dapat terhubung kembali jika AP tidak mengizinkan B / G saja.

@ TD-er Maksud saya perubahan ini:

Dugaan saya adalah ada yang salah di pustaka inti (LWIP atau Arduino atau ESP) dan kami harus mengatur ulang wifi.
Jadi matikan wifi dan mulai dari awal lagi. Mungkin juga menunggu di antara langkah-langkah tersebut untuk memastikan buffer dikosongkan atau setidaknya dibilas dan permintaan yang belum selesai secara aktif dibatalkan.

Perubahan yang dibahas dalam 2 posting terakhir?
Ini belum diimplementasikan, tapi saya bisa mencoba malam ini untuk mengkodekannya dan membuat uji coba.

@oki Saya mencoba kedua varian, mengatur daya keluaran ke 0 dan secara aktif memutus / menyambungkan kembali saat masalah terjadi. kedua versi tidak membantu untuk mereset / menyambung kembali ke AP ... (di lingkungan saya) ... detail mre di atas ...
satu-satunya hal yang membuatnya stabil adalah dengan menggunakan N-Mode.

Saya sangat menyadari itu. Berharap tambalan segera, jadi saya bisa melanjutkan debugging saya.

@ 0ki Saya dapat membuat testbuild untuk Anda menggunakan commit terbaru ini.
Atau apakah Anda juga ingin menguji dengan menonaktifkan WiFi?

Dan jika ya, opsi apa yang Anda inginkan / butuhkan? WiFi mati / hidup dan restart semua layanan?
Bagian terakhir itu (layanan restart) juga merupakan satu hal yang harus diperhatikan, karena saya tidak sepenuhnya yakin semua layanan yang menggunakan soket dimulai ulang dengan benar.
Itu juga dapat menyebabkan beberapa masalah yang saya kira ketika koneksi WiFi dibuat ulang.

Secara otomatis mematikan sepenuhnya (dan kemudian menghidupkan) pemancar wifi saat terputus terdeteksi.

Saya melihat bahwa Anda telah menambahkan beberapa kode. Versi mana yang dapat saya gunakan untuk mengujinya?

Tidak yakin, saya akan membuat build baru untuk pengujian.
Ini akan dilakukan dalam +/- 30 menit.

uji membangun
Ini didasarkan pada apa yang saya gabungkan sebelumnya hari ini dan PR # 2235 yang memiliki perubahan untuk menghubungkan dalam mode B / G.
Sepertinya ada masalah dengan beberapa plugin di PR itu, jadi itulah alasannya belum digabungkan.

Terima kasih! Menjalankan pengujian build.

Saya memiliki pengaturan berikut sekarang:
Connection Failure Threshold: 0 Force WiFi B/G: NO Restart WiFi on lost conn.: YES

Apakah menurut Anda saya harus menguji sesuatu secara berbeda mengingat saya memiliki PLATFORMIO_ESP12E?
Artinya, saya yakin apakah b / g akan berfungsi pada esp12e dan apa ambang batas kegagalan koneksi sebenarnya.

Ambang batas itu hanyalah penghitung untuk memulai boot ulang jika sejumlah upaya penyambungan yang gagal melebihi nilai itu.
0 adalah default dan berarti tidak akan melakukan reboot.

Saya kira mengaturnya ke 50 atau 100 akan membantu Anda untuk mem-boot ulang ketika mungkin berada di tempat yang sulit dijangkau dan itu masuk ke beberapa loop menghubungkan kembali.

Bahkan dengan pengaturan ini, ini mungkin masih menampilkan boot ulang pengawas HW, seperti yang telah ditunjukkan oleh sejumlah node saya.
Mungkin lebih sulit untuk mereproduksi mereka yang mode B / G aktif.

uji membangun
Ini didasarkan pada apa yang saya gabungkan sebelumnya hari ini dan PR # 2235 yang memiliki perubahan untuk menghubungkan dalam mode B / G.
Sepertinya ada masalah dengan beberapa plugin di PR itu, jadi itulah alasannya belum digabungkan.

Terima kasih untuk test buildnya.
ESP12F saya yang sebelumnya paling tidak stabil sekarang aktif sejak 59 jam tanpa reboot :)

EDIT: Pengaturannya adalah:
Paksa WiFi B / G: YA
Mulai ulang WiFi saat koneksi hilang: YA

Saya pikir saya akan membagi komit itu (B / G WiFi) menjadi PR terpisah, sehingga dapat digabungkan sebelum saya memperbaiki PR lainnya yang sekarang menunggu untuk digabungkan.

Ide bagus!

Pengaturan saya sebelumnya RestartWifi = YES tidak berguna.

Sekarang saya beralih ke

Connection Failure Threshold: 0
Force WiFi B/G: YES
Restart WiFi on lost conn.: NO

dan sudah dua hari tanpa reboot atau bahkan satu pemutusan. Luar biasa. Saya tidak berpikir saya bahkan akan menjauh dari rilis pengujian ini.

Setelah kira-kira. 100 jam modul akhirnya melakukan reset. :(

Atur Ulang Alasan: Pengawas Perangkat Keras

Namun hal ini juga dapat disebabkan oleh konfigurasi yang menantang (sensor 12 x 1-kabel dan server FHEM).

Anda juga dapat mencoba menambahkan tambalan ini: https://github.com/letscontrolit/ESPEasy/pull/2235/commits/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf2
Mungkin itu juga akan membantu meningkatkan stabilitas.
Itu termasuk dalam build uji ini

Anda juga dapat mencoba menambahkan tambalan ini: 9a05eaf
Mungkin itu juga akan membantu meningkatkan stabilitas.
Itu termasuk dalam build uji ini

Terima kasih!
Memasangnya pada dua unit yang dikonfigurasi sangat berbeda dan akan memberikan umpan balik.

menjalankan salah satu node pengujian saya termasuk
https://github.com/letscontrolit/ESPEasy/commit/9a05eaf828a737ae416ab11c8df8c4a5b03ceaf sayangnya hanya butuh waktu sekitar 2 jam sampai mengalami masalah group-key-timout lagi dan tidak pulih atau pernah menghubungkan kembali ke AP. Dengan mengaktifkan "restart wifi saat koneksi terputus" dan tidak memaksanya ke B / G .... jadi N sepertinya masih menjadi masalah ..
Jadi bagi saya mode B / G masih satu-satunya pilihan kerja yang stabil.

Bisakah kita melihat penurunan dukungan N sama sekali? Apakah kita membutuhkan manfaat yang diberikan oleh N untuk perangkat sederhana seperti itu?

@ 0ki dengan opsi "baru" untuk memaksa mode B / G yang @ TD-er built in, pada dasarnya menjatuhkan N pada tingkat perangkat lunak, Anda tidak dapat menghapusnya dari libs inti yang saya asumsikan ...

Saat memindahkan ini ke pengaturan utama, saya sarankan opsi ini dikirim ON secara default.

Kami bisa membuatnya dinamis.
Jika tidak ada koneksi yang memungkinkan, coba lagi dengan opsi N aktif.

Ada banyak pengaturan yang hanya memiliki N yang diperiksa di AP. Jadi di lingkungan tersebut Anda tidak dapat kembali jika Anda menonaktifkan dukungan N di ESPeasy.

Anda juga dapat mencoba menambahkan tambalan ini: 9a05eaf
Mungkin itu juga akan membantu meningkatkan stabilitas.
Itu termasuk dalam build uji ini

Terima kasih!
Memasangnya pada dua unit yang dikonfigurasi sangat berbeda dan akan memberikan umpan balik.

Sejauh ini, satu modul dimulai ulang setelah 2 hari, yang lainnya setelah 5 hari.
Keduanya menunjukkan "Hardware Watchdog" sebagai alasan reset.
Kedua modul disetel ke "Paksa WiFi B / G: Ya" dan "Mulai ulang WiFi saat koneksi hilang .: Ya".
AP adalah Mikrotik yang diatur ke B / G saja (uptime 49 hari).
Jarak antara AP dan modul kira-kira. 2 ... 3 m.

Saya bertanya-tanya mengapa saran saya untuk membuatnya dinamis (untuk kembali ke N dari pengaturan B / G saja) telah menerima 2 jempol "suara".
Jelaskan mengapa ini bukan saran yang bagus.

Saya bertanya-tanya mengapa saran saya untuk membuatnya dinamis (untuk kembali ke N dari pengaturan B / G saja) telah menerima 2 jempol "suara".
Jelaskan mengapa ini bukan saran yang bagus.

Menurut pendapat saya, jika seseorang mengaktifkan opsi ini, dia sudah mati-matian mencari lebih banyak stabilitas dan tahu apa artinya ini untuk pengaturan AP-nya.
Saya lebih memilih solusi statis karena ketika saya memilih opsi B / G saja, saya benar-benar tidak pernah ingin berada dalam situasi di mana saya pikir itu menggunakan B / G tetapi sekali lagi tidak.
Namun, karena node saya me-reboot (meskipun jauh lebih jarang) saya ingin memiliki solusi nyata untuk masalah yang terkait dengan inti yang lebih baru.

Saya mengerti, tetapi Anda juga harus memahami masalah ketika pengguna tidak tahu apa yang dilakukan pengaturan dan berakhir dengan node yang tidak dapat dijangkau.
Jadi itu harus memiliki ambang batas besar sebelum beralih kembali ke dukungan N.
Misalnya fall-back untuk plugin yang rusak adalah:
Setelah 10 kali boot ulang gagal, 1 plugin atau pengontrol akan dinonaktifkan untuk melihat apakah reboot berhasil.

Hal serupa juga dapat diterapkan pada koneksi wifi.
Setelah X gagal menyambungkan kembali, ia akan mengizinkan untuk menyambung dengan 802.11N diperbolehkan
Kualitas penerimaan lebih baik untuk jaringan mode G, jadi jika Anda meletakkan X ke sesuatu seperti 10, sangat kecil kemungkinannya itu akan terhubung dengan N daripada G. Terutama jika Anda mengatur ulang penghitung ini setiap kali Anda mencobanya dalam mode N.

Hmm, beberapa minggu terakhir lebih sedikit waktu untuk ESPeasy tampaknya mengaburkan ingatan saya tentang apa yang saya rencanakan untuk diterapkan atau apa yang telah diterapkan.

Saya baru saja melihat kode untuk ini dan menemukan:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Jadi tampaknya itu telah diterapkan untuk hanya mengizinkan N ketika wifi_connect_attempt adalah> 10.
Penghitung ini disetel ulang ke 0 segera setelah ada upaya berhasil untuk menyambung ke wifi.

Apakah ini solusi yang dapat diterima?

Hmm, beberapa minggu terakhir lebih sedikit waktu untuk ESPeasy tampaknya mengaburkan ingatan saya tentang apa yang saya rencanakan untuk diterapkan atau apa yang telah diterapkan.

Saya baru saja melihat kode untuk ini dan menemukan:

void setConnectionSpeed() {
  #ifdef ESP8266
  if (!Settings.ForceWiFi_bg_mode() || wifi_connect_attempt > 10) {
    WiFi.setPhyMode(WIFI_PHY_MODE_11N);
  } else {
    WiFi.setPhyMode(WIFI_PHY_MODE_11G);
  }
  #endif

Jadi tampaknya itu telah diterapkan untuk hanya mengizinkan N ketika wifi_connect_attempt adalah> 10.
Penghitung ini disetel ulang ke 0 segera setelah ada upaya berhasil untuk menyambung ke wifi.

Apakah ini solusi yang dapat diterima?

Baiklah .. saya akan mengatakan ya (berharap bug di 2.5.0 akan segera ditemukan).

Umpan balik tentang pengaturan B / G saja.
Saya baru saja menginstal test fw pada satu unit yang di-boot ulang setiap 20 menit terakhir. Sebelum dihubungkan ke N dengan -72dBi. Itu seharusnya menjadi sinyal yang cukup baik untuk tidak memutuskan sambungan. Saya mengoperasikan AP kelas perusahaan dengan kemampuan penerimaan -105dBi. Jadi sekali lagi itu tidak boleh menjatuhkan saluran.

Setelah beberapa jam dengan uji FW dan sejauh ini tidak ada pengaturan ulang.
Saya akan tetap menjalankannya dan melaporkan kembali.

PS: Saya setuju itu terkait dengan N entah bagaimana.
PSS: Saya menjalankan 20 x ESP-07 node yang telah ditingkatkan ke 4M. Memakan waktu tetapi membayar kembali saat melakukan flashing ulang diperlukan.

Saya memiliki 120+ node yang semuanya berjalan di GN (mega-20190202) tanpa masalah apa pun. Mereka semua melaporkan untuk dihubungkan ke N

@ jimmys01 Berapa banyak node yang terhubung ke AP yang sama?
Dan apa merek AP itu? (Mikrotik?)

Hampir semuanya terhubung ke AP yang berbeda (satu per kamar hotel) Mereka memiliki sakelar (sensor PIR), sensor suhu dan kelembaban HTU, dan LED IR.
Merek AP adalah Mikrotik.
Pengaturannya adalah sebagai berikut:
Negara sudah diatur
Saluran Kontrol: 20Mhz
Band: GN
Saluran Ekstensi: Dinonaktifkan
Jenis Otentikasi: hanya WPA2 PSK
Enkripsi: aes ccm saja
Enkripsi Grup: aes ccm
Pembaruan Kunci Groyp: 00:01:00

Umpan balik tentang pengaturan B / G saja.
Saya baru saja menginstal test fw pada satu unit yang di-boot ulang setiap 20 menit terakhir. Sebelum dihubungkan ke N dengan -72dBi. Itu seharusnya menjadi sinyal yang cukup baik untuk tidak memutuskan sambungan. Saya mengoperasikan AP kelas perusahaan dengan kemampuan penerimaan -105dBi. Jadi sekali lagi itu tidak boleh menjatuhkan saluran.

Setelah beberapa jam dengan uji FW dan sejauh ini tidak ada pengaturan ulang.
Saya akan tetap menjalankannya dan melaporkan kembali.

PS: Saya setuju itu terkait dengan N entah bagaimana.
PSS: Saya menjalankan 20 x ESP-07 node yang telah ditingkatkan ke 4M. Memakan waktu tetapi membayar kembali saat melakukan flashing ulang diperlukan.

Sayangnya Unit terus mengatur ulang setelah waktu acak. Apa pun dalam 1-4 jam.
B / G only FW tidak menyelesaikan masalah saya

Saya bertanya-tanya mengapa saran saya untuk membuatnya dinamis (untuk kembali ke N dari pengaturan B / G saja) telah menerima 2 jempol "suara".
Jelaskan mengapa ini bukan saran yang bagus.

Katakanlah wifi itu sendiri mati selama satu jam karena keadaan eksternal / lingkungan. Node saya beralih ke N dan menjadi sangat tidak stabil lagi (aplikasi saya sensitif terhadap reboot - wifi tidak harus selalu ada di sana 100%, tetapi node itu sendiri harus beroperasi sepanjang waktu).

Saya ingin konfigurasi untuk node saya yang menghindari ketidakstabilan dan tidak pernah terhubung ke N melakukannya untuk saya sekarang.

Saat memindahkan ini ke pengaturan utama, saya sarankan opsi ini dikirim ON secara default.

Sebagai solusi, kami dapat mengirimkannya ke mode fallback (B / G-lalu-N) secara default dengan hanya dapat dialihkan ke B / G atau B / G / N.

Adapun solusi aktual untuk 2.5.0, silakan coba ini:

#include "esp_wifi.h"
esp_wifi_set_ps(WIFI_PS_NONE);

Saya memiliki 120+ node yang semuanya berjalan di GN (mega-20190202) tanpa masalah apa pun. Mereka semua melaporkan untuk dihubungkan ke N

Bagaimana Anda memperbarui 120+ node dalam jangka waktu yang dapat diterima ??
"..tidak ada masalah apa pun ..." apakah Anda memeriksa uptime setiap node dan apa itu?
Apakah semua sama sejak booting ulang terakhir?

Uptime menghitung hari dan semuanya memiliki 0 koneksi ulang. Berbulan-bulan sekarang saya tidak pernah memiliki masalah dengan konektivitas kecuali ketika saya menonaktifkan PMKID di AP. Mungkin inti yang lebih baru menjadi pemilih tentang pengaturan wifi atau saya tidak tahu apa .. Saya juga menjalankan semuanya dengan catu daya 2A. Kami berencana di bulan depan untuk menyebarkan 80 esp8266 lagi. Omong-omong, jika @ TD-er Anda menginginkan akses untuk melihat pengaturan tertentu, saya dengan senang hati memberikannya kepada Anda. Saya sangat ingin ESPEasy berkembang, ini telah banyak membantu kami.

Edit: @ chunter1 Saya memperbaruinya menggunakan skrip batch

curl -# -o /dev/null --form update=@ESP_Easy.bin --max-time 40 --connect-timeout 20 --retry 1 http://x.x.x.x/update

@ jimmys01 Saya baru saja membeli Mikrotik sendiri, untuk dapat menguji berbagai hal.

Dan hanya pemberitahuan tentang build inti 2.5.0.
Dalam versi malam yang akan datang, versi 2.5.0 tidak disertakan, karena ada bug di inti 2.5.0 yang membuat server web berhenti merespons dan membiarkan node rusak.
Segera setelah diperbaiki, akan ada build inti 2.5.0 lagi.
Dalam build nightly terakhir, ada core 2.6.0 alpha yang disertakan, yang pada dasarnya adalah kode terbaru dari github pustaka inti sehingga Anda dapat melihatnya sendiri.

Mendapat 2.6.0 dengan B / G hanya berjalan sejak 4 hari pada dua modul dan yang pertama melakukan reboot.
Alasan reset adalah "pengawas perangkat keras" biasa.
Yang saya amati karena mode "B / G" saja yang aktif adalah runtime 3..5 hari sebelum reset terjadi.

Mungkin juga membandingkan jumlah pemutusan wifi, karena pemutusan tersebut tampaknya terkait dengan crash.

Kedua modul tersebut berada di ruang bawah tanah, hanya berjarak 2..3m dari Mikrotik AP.
Saya baru saja memeriksa modul kedua yang menjalankan versi FW yang sama dan itu menunjukkan 0 menghubungkan kembali dan waktu aktif 4d02h (tidak ada reboot sejak flashing).
Saya sangat percaya bahwa modul lain, yang melakukan reset. juga memiliki 0 menyambung kembali sebelum disetel ulang.

Mengenai tugas yang dikonfigurasi pada dua modul uji:
Modul yang melakukan reset memiliki 12 sensor DS18B20 yang dikonfigurasi yang mengirimkan nilainya setiap 120 detik ke server FHEM.
Modul yang tidak diatur ulang sejauh ini hanya memiliki dua gpios yang dikonfigurasi yang juga mengirimkan nilainya setiap 120 detik ke server FHEM yang sama.

Jadi, AP (Mikrotik) sama, jarak (2..3mm) sama, server FHEM sama - hanya modul dengan 12 sensor suhu pasti lebih sering diatur ulang daripada yang dengan 2 gpios.

pada node saya, ini terjadi terutama ketika fhem terlalu lambat untuk merespons atau tidak dapat dijangkau karena saya menetapkan percobaan ulang maksimum 100 dan kemudian node melakukan boot ulang (yang juga menampilkan reboot manual).

pada node saya, ini terjadi terutama ketika fhem terlalu lambat untuk merespons atau tidak dapat dijangkau karena saya menetapkan percobaan ulang maksimum 100 dan kemudian node melakukan boot ulang (yang juga menampilkan reboot manual).

Mengapa node Anda harus di-boot ulang ketika percobaan ulang melebihi 100?
(Saya telah menyetel percobaan ulang ke 0 untuk pengujian)

alat -> lanjutan -> ambang kegagalan koneksi

untuk memastikan bahwa jika wifi pada modul tersedak karena alasan tertentu, ia akan reboot setelah beberapa waktu ...

Ahh dengan "retries" yang Anda maksud adalah "Connection Failure Threshold:" bukan "Max retries:" dalam pengaturan pengontrol FHEM.
Saya telah menyetel ambang batas kegagalan koneksi ke 0.

BTW: untuk pertama kalinya saya memiliki node yang macet di masalah batas waktu 4WHS meskipun "hanya B / G" yang aktif ... tidak pernah memiliki itu sebelumnya hingga sekarang (dikompilasi sendiri, 2.5.0 core) .... Saya akan terus menonton ini, jika ini hanya kebetulan ...

Harap dicatat bahwa akan segera ada inti 2.5.1 yang mengembalikan SDK yang digunakan ke SDK2.2.1, karena ada banyak masalah dengan SDK3.0.0
Ini juga dapat mengubah bagaimana node bereaksi pada wifi dan mungkin akan sebanding dengan core 2.4.2 lagi.
Tidak yakin apa perbaikan dalam inti 2.5.0 yang disertakan yang dapat memperbaiki beberapa masalah lain yang kami hadapi.

@ chunter1 Tentang node yang Anda miliki.
Sepertinya yang di-boot ulang mengirimkan lebih banyak pesan ke pengontrol, jadi secara statistik, pengontrol memiliki peluang lebih tinggi untuk mencoba mengirim sesuatu yang terhenti di suatu tempat dalam proses.

@ clumsy-stefan Dapatkah Anda menguji kode saat ini di Github? (atau versi terbaru)

Saya telah membuat beberapa perubahan dalam cara melakukan aktivitas terkait jaringan.

Ini yang kau maksudkan?

ESP_Easy_mega-20190227_test_core_260_sdk3_alpha_ESP8266_4M.bin

Hampir semua bangunan tadi malam.
Saya juga menambahkan versi "normal" untuk core 2.6.0 menggunakan SDK2.
Core 2.6.0 SDK2 sekarang berjalan di beberapa node dan hanya memiliki pengawas HW pada salah satunya yang sangat rendah sumber dayanya (menjalankan banyak plugin memori tinggi) dan juga yang memiliki memori flash yang mungkin sudah usang (seharusnya buang yang itu karena memiliki 1000 pembaruan firmware)

@ TD-er Saya mengkompilasi dan menginstal dari git sekitar 6 jam yang lalu pada node 2test .. tetapi karena saya masih memiliki akses internet yang sangat terbatas, saya mungkin hanya dapat melaporkan kembali dalam 24 jam jadi ...

Saya telah menguji firmware terbaru dengan "mode Force B / G" dengan router Mikrotik dan sejauh ini tampaknya berfungsi dengan stabil. Akan melaporkan kembali.

@ TD-er Satu pertanyaan: Apa aturan untuk fallback ke mode-N jika "Mode Force B / G" disetel?

@jogja_lowker
Jika gagal terhubung lebih dari 10 kali ke AP dengan _B / G only_, itu akan kembali ke mode BGN default.

Jadi ini menyisakan kemungkinan itu akan terhubung dalam mode N jika AP offline selama beberapa waktu.
Jika ini tampaknya menjadi masalah nyata, saya dapat mencoba mengaturnya untuk hanya melakukan itu setiap upaya ke-10, tetapi kemudian saya harus memastikan itu juga akan mencobanya ketika ssid fallback dicoba.

Hai @ TD-er
Menurut saya, fallback adalah ide yang buruk.
Lihat skenario ini: Unit saya dipaksa ke mode B / G berjalan dengan gembira dengan Mikrotik saya.
Untuk beberapa alasan Mikrotik saya offline (perbarui, reboot, apa pun).
Kapanpun mikrotik muncul lagi, ESP kemudian akan terhubung dalam mode-N dan saya kehilangan stabilitas unit.

Dengan kata lain, jika saya menyetel mode Force B / G dan koneksi gagal maka itu harus menjadi AP (192.168.4.1), tetapi tidak boleh kembali ke mode N. Kemungkinan fallback menciptakan ekspektasi palsu bagi pengguna.

Jangan salah paham, fallback bagus untuk menguji validitas perubahan, tetapi sekarang setelah terbukti menyelesaikan masalah (setidaknya milik saya sejauh ini) fallback harus dihapus.

Saya setuju dengan komentar @ chunter1 : https://github.com/letscontrolit/ESPEasy/issues/1987#issuecomment -462295204

Apa pendapat Anda tentang skenario selanjutnya.
Segera setelah memungkinkan untuk terhubung ke AP yang diberikan hanya dengan menggunakan B / G, flag tambahan akan disetel untuk tidak menyediakan fallback lagi.
Jika beberapa pengaturan ini (hanya B / G, atau pengaturan AP lainnya) berubah, fitur mundur akan diaktifkan kembali hingga berhasil terhubung ke AP yang diberikan.

Edit:
Yang saya maksud dengan fallback adalah setelan ekstra tersebut, bukan "SSID fallback"

Dengan kata lain, fallback tetap aktif hanya sampai koneksi pertama yang berhasil ke AP, lalu dihapus. Dalam hal ini akan sangat membantu untuk melihat mode wifi di syspage.
Ini adalah solusi yang mungkin bahkan jika saya masih lebih suka menghindari fallback ke N jika saya menyetel Force B / G.
Saya memahami kemungkinan pengguna melakukan kesalahan, tetapi pengguna dapat salah mengetik SSID dan tidak mendapatkan akses ke unit dalam hal apa pun ...

Pertanyaan lain: dalam implementasi saat ini di skenario mana unit akan menjadi AP?
Karena menurut saya unit akan mencoba B / G sebanyak 10 kali kemudian mencoba N tetapi pada akhirnya akan menyerah dan menjadi AP?

Tidak, mode AP tetap aktif saat masih menguji untuk terhubung ke AP yang diberikan.
Mungkin kita juga harus menambahkan pemeriksaan opsional untuk uptime dan hanya mengizinkan untuk memulai mode AP dalam 10 menit pertama node di-boot.
Hanya untuk keamanan ekstra dan juga untuk mengecualikan kemungkinan mode AP mungkin berpengaruh pada ESP yang tidak dapat menjangkau jaringan wifi yang diberikan.

Dan kita harus tetap fokus pada bagian "mudah" dari proyek.
Ini berarti default yang tepat dan tidak ada banyak pengaturan yang ditawarkan, tetapi berikan opsi kepada ahlinya untuk melakukan semuanya.
Ini juga berarti harus ada penggantian yang tepat untuk pengguna yang kurang berpengalaman.
Khusus untuk pengaturan B / G saja. Saya kira 90+ persen orang yang memulai dengan ESPeasy tidak mengetahui perbedaan antara 802.11B / G / N Jadi jika mereka mengalami masalah, yang dapat ditangani dengan sangat baik dengan menggunakan fallback, ini dapat menyebabkan mereka mencari proyek lain .
Saya juga memahami mengapa fallback ini tidak memberikan kesan palsu tentang 'stabilitas', jadi saya benar-benar memahami mengapa penerapan saat ini memiliki ruang untuk perbaikan. Tetapi jika "upaya menghubungkan pertama berhasil => menonaktifkan fallback" dibuat otomatis, maka ini juga cocok untuk pengguna yang lebih berpengalaman. (yang juga membuat kesalahan bodoh, seperti yang saya ketahui dari pengalaman;))

Saya setuju itu harus dibuat lebih jelas pengaturan koneksi apa yang digunakan secara aktif.

mengerti.
Jadi, keuntungannya adalah:
Unit Boots.
Bendera N-fallback disetel ke true.
Jika FORCE B / G diatur, ia mencoba 10 kali untuk terhubung ke wifi AP di B / G.
Jika dapat terhubung, setel N-fallback flack ke false.
Jika tidak dapat terhubung, coba dalam mode N.

Harap pertimbangkan juga skenario ini dengan set Angkatan B / G: kegagalan daya.
ESP dan Router Wifi dimatikan.
Kemudian daya kembali, dan ESP lebih cepat daripada router wifi.
Dalam hal ini bisa terjadi setelah 10 kali AP wifi tidak mendengarkan.
Jadi unit akan mencoba N-mode dan pada akhirnya akan berhasil.
Pengguna (berpengalaman) tidak akan tahu bahwa koneksi dalam mode-N dan berpikir bahwa itu dalam mode B / G dengan stabilitas yang kurang.

Nggak mau ngotot, tapi sebenarnya masalah HW dan freeze ini sudah berlangsung sejak 1 tahun. Sekarang Anda dengan bantuan komunitas menemukan satu solusi yang berfungsi, saya sangat menyarankan untuk memastikannya tetap diterapkan. Risiko bagi pengguna yang tidak berpengalaman untuk menyetel "Mode Paksa B / G" lebih kecil daripada dia yang menyetel SSID yang salah dengan hasil yang sama: tidak ada akses ke titik akses.

SARAN:
Untuk memastikan pengguna yang kurang berpengalaman tidak membuat kesalahan, mengapa Anda tidak menambahkan tombol ke "Uji mode B / G". Jika berhasil, ini akan mengaktifkan "FORCE B / G mode", jika tidak tetap dinonaktifkan.

Dalam hal ini, pengguna yang kurang berpengalaman akan tahu apa yang mereka lakukan dan pengguna yang lebih berpengalaman akan yakin bahwa ketika mode ForceB / G disetel, ia tidak dapat mundur ke N.

Bagaimana menurut anda?

Anda bisa

Tidak hanya jika boot, tetapi opsi fallback kemudian akan dinonaktifkan di pengaturan dan disimpan.

baik. Kemudian pemeriksaan manual bahkan lebih sesuai daripada pemeriksaan otomatis. Bukankah begitu?

Ya, pertama-tama saya akan menambahkan tanda centang sederhana untuk menonaktifkan penggantian.
Tapi nanti itu harus dibuat lebih dinamis dalam hal ini juga untuk membantu kami, para "ahli" untuk membuat lebih sedikit kesalahan :)

baik

Versi 2019_02_16 sekarang berjalan selama 9 hari tanpa reboot (dipaksa ke B / G). Kemarin itu mulai reboot lagi. Pengawas perangkat keras memaksa ini dua kali.
Setelah beberapa saat, unit itu tidak bisa dihubungi lagi. Peralihan router WLAN tidak membantu (mencobanya 3 kali, hingga 30 menit). Memulai ulang ESP dengan mengganti sekring daya juga tidak membantu.
Saya harus mematikan wlan lagi dan kemudian terhubung ke ESP melalui 192.168.4.1 langsung untuk mendapatkan akses di atasnya

Saya sama sekali tidak tahu apa yang terjadi

@kischde Apa jenis
Tadi malam saya mengalami hal serupa sendiri saat bereksperimen dengan memasang AP baru.
Saya mencoba menginstal MikroTik AP dan semuanya berfungsi dengan baik sampai ESP perlu menyambung kembali.
Melalui antarmuka web MikroTik, saya dapat melihat node terhubung ke WiFi, tetapi tidak menerima alamat IP.
Bahkan ketika saya mencoba menghubungkannya ke hotspot ponsel saya, saya dapat me-reboot ESP tetapi perilaku ini berulang.
Hanya ketika saya mengatur konfigurasi AP utama ke AP lain, itu mulai terhubung seperti seharusnya.

Perhatikan bahwa node tidak di-boot ulang untuk mencapai ini.

Satu hal yang disetel "salah" pada AP itu, dibandingkan dengan MikroTik lain yang saya miliki, adalah bahwa ia memiliki setelan "Jarak" yang disetel ke "dalam ruangan".
Saya akan melakukan lebih banyak tes untuk melihat apa perbedaannya di sini, tetapi seperti yang dibahas sebelumnya, tampaknya ada beberapa pengaturan batas waktu untuk balasan pada sebuah paket.
Dan saya dapat membayangkan ESP membutuhkan waktu untuk menanggapi permintaan DHCP, yang mungkin terlalu pendek untuk pengaturan ini.

Saya menggunakan Swisscom AP (penyedia swiss Telecom AP), tetapi saya memiliki semua masalah yang sama yang ditulis di sini di tempat yang berbeda seperti orang-orang dengan MikroTik. Jadi mungkin memiliki chipset yang sama, tetapi saya tidak dapat mengubah banyak pengaturan, misalnya pengaturan yang diperluas.
Sebelum menyalakan kembali, saya juga mencoba menyambungkan dengan ponsel saya, seperti yang Anda lakukan, dengan perilaku yang sama dengan Anda.
Saya menggunakan fix IP, tidak ada DHCP
Saya beralih sekarang ke 2019_03_05 yang sebenarnya, akan melihat apa yang terjadi ...

Apakah Anda baru-baru ini mengubah pengaturan WiFi?
Misal access point dengan MAC address AA: AA: AA: AA: AA pada posisi 1 SSID AP lain dengan MAC address BB: BB: BB: BB: BB: BB
Saya merasa ada beberapa pengaturan yang tersisa di beberapa tempat di ESP di mana kami tidak menyimpannya.

Saya juga akan mencoba melihat di dokumen NonOS bagaimana ini dapat dibersihkan secara efektif ketika kami mengubah pengaturan WiFi.
Juga dalam pengujian saya, tampaknya sangat berguna untuk memiliki lebih dari 2 SSID untuk digunakan.
Saya juga akan mencoba menambahkan lebih banyak bidang untuk ini, atau mungkin bahkan mengizinkan untuk menyimpan beberapa file terenkripsi di SPIFFS untuk menyimpan jumlah AP WiFi yang hampir tidak terbatas.

Apakah Anda baru-baru ini mengubah pengaturan WiFi?

Tidak, karena saya hanya memiliki satu AP, ini IMO tidak perlu

BAIK. Senang mendengarnya.
Karena saya belum tahu apa yang menyebabkan ini, saya mencoba menghilangkan sebanyak mungkin hal yang tidak diketahui.
Jadi satu-satunya hal yang perlu Anda lakukan untuk membuatnya berfungsi lagi adalah menambahkan pengaturan untuk wifi lagi.

Tidak, bahkan lebih sedikit
Saya terpaksa terhubung langsung ke esp melalui 192.168.4.1 (menonaktifkan AP)
Kemudian saya memeriksa semuanya, tetapi tidak menemukan hal-hal yang tidak normal ... Jadi saya mencobanya dan me-restart AP saya, daripada mengatur ulang ESP dan itu berjalan lagi. Jadi IMO saya hanya harus memaksa untuk melakukan koneksi WLAN "normal / lainnya".
BTW Saya juga melihatnya terhubung di AP, tetapi juga tidak ada Alamat IP yang ditetapkan, namun itu statis

Hmm, saya sudah bermain-main sedikit, dengan 5 node terhubung ke MikroTik yang saya mainkan.

Segera setelah saya menyetel "Hw. Fragmentation Threshold" (hanya 'membuka' opsi), simpul ESP tidak lagi dapat menerima alamat IP lagi.
Nilai default dari pengaturan ini adalah 256. Jika saya mengaturnya ke 1600 (sesuai dengan MTU penuh), semua node akan menerima alamat IP dan terus bekerja.

Ini ditunjukkan di MikroTik UI ketika node dapat berkomunikasi:

Dan ini ketika mereka tidak dapat mengirim / menerima data apa pun (tetapi terhubung ke lapisan WiFi)

@ TD-er apakah Anda melihat bahwa ada opsi di inti esp8266 baru bernama LWIP_FEATURES yang menurut saya akan mengaktifkan perakitan ulang IP ... Mungkin itu tidak ditentukan dalam build Anda?

lihat di sini: https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L748 -L754

juga dukungan untuk fragmentasi IP diatur dengan ini:
https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/tools/sdk/lwip2/include/lwipopts.h#L756 -L763

Hmm, tidak yakin apa defaultnya.
Apakah nomor yang diberikan pada baris pertama dalam dokumentasi Doxygen merupakan default?

Saya tidak tahu ... saya hanya tahu, bahwa di Arduino IDE dalam file definisi plattforms Anda dapat memilih apakah Anda ingin disertakan dan ditentukan atau tidak ..

Saya selalu berpikir bahwa bagian LWIP dimasukkan sebagai perpustakaan yang telah dikompilasi sebelumnya dalam distribusi inti.
Jadi cukup sulit untuk memastikan LWIP dibangun kembali menggunakan flag yang benar.

ya, tetapi itu tergantung mana yang Anda tautkan (dari boards.txt):

-llwip2-1460-feat
-llwip2-536-feat
-llwip2-536
-llwip2-1460
-llwip2

Jadi mereka menggunakan bendera ini:

https://github.com/esp8266/Arduino/blob/192aaa42919dc65e5532ea4b60b002c4e19ce0ec/boards.txt#L357 -L387

| Label | build.lwip_lib | build.lwip_flags |
| --- | --- | --- |
| v2 Memori Lebih Rendah | -llwip2-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Bandwidth Lebih Tinggi | -llwip2-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 0 |
| v2 Memori Lebih Rendah (tidak ada fitur) | -llwip2-536 | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 Bandwidth Lebih Tinggi (tanpa fitur) | -llwip2-1460 | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 0 -DLWIP_IPV6 = 0 |
| v2 IPv6 Memori Lebih Rendah | -llwip6-536-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 536 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v2 IPv6 Bandwidth Lebih Tinggi | -llwip6-1460-feat | -DLWIP_OPEN_SRC -DTCP_MSS = 1460 -DLWIP_FEATURES = 1 -DLWIP_IPV6 = 1 |
| v1.4 Bandwidth Lebih Tinggi | -llwip_gcc | -DLWIP_OPEN_SRC |
| v1.4 Kompilasi dari sumber | -llwip_src | -DLWIP_OPEN_SRC |

Jadi semua versi v2 memiliki LWIP_FEATURES=1 kecuali yang berlabel "tanpa fitur"

ya, tetapi jika Anda melihat pernyataan -l , Anda perlu menambahkan -feat di akhir pustaka (berlawanan dengan labelnya, agak conter-intuitif) ...