Espeasy: MQTT berhenti bekerja sejak 20181008

Pada 20181004 hal-hal berikut telah berubah:

• [sendHttp] # 1830 Setel waktu tunggu dan keluar lebih awal pada waktu tunggu tercapai
• [WiFiClient] Tetapkan waktu tunggu dan buat itu dapat dikonfigurasi untuk pengontrol
• [Core 2.4.1] Kembali ke inti 2.4.1 dari 2.4.2

Dan di 20181006:

• [WiFi] Tambahkan penundaan untuk upaya koneksi di ControllerSettings

Bisakah Anda menguji build 20181003 dan mungkin 2 lainnya ini juga untuk mempersempit masalah?

Saya akan mencoba tapi saya khawatir saya tidak akan bisa melakukannya sampai hari Sabtu. ;-)

Apakah Anda tahu berapa lama sebelum koneksi MQTT terputus?
Dan apakah itu entah bagaimana bertepatan dengan koneksi ulang wifi?

Sejauh yang saya bisa lihat, tidak ada kehilangan Wifi.
bahwa koneksi MQTT terputus cukup cepat pagi ini (10 menit) tetapi saya juga punya waktu berjam-jam menurut entri terakhir dari IOBroker ...
Saya akan mencoba memulai setidaknya satu dari 3 bangunan malam ini.

Sama seperti cek; Apakah Anda membangunnya sendiri, atau menggunakan bangunan malam?

hal lain untuk diperiksa:

apakah Anda yakin MQTT berhenti bekerja?
Yang saya lihat di sini setelah beberapa saat "Sambungan HILANG" tetapi semuanya masih bekerja dengan MQTT.

Satu-satunya bug yang saya lihat adalah pesan "Sambungan Hilang" saat semuanya masih berfungsi.
Misalnya saya mendapatkan menit uptime oleh pengontrol MQTT.
Setelah beberapa saat (antara 10 menit dan 10 jam) saya melihat "Sambungan Hilang" tetapi menit masih menghitung kirim melalui MQTT.

Salam
Sascha

MQTT harus melakukan penyambungan kembali segera setelah mendeteksi bahwa ia tidak lagi terhubung.
Lihat juga @ Sasch600xt masalah terkait lainnya:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

Beberapa build sebelum 20180927, yang Anda laporkan berfungsi dengan baik, saya menambahkan perbaikan untuk pengontrol MQTT di mana klien MQTT di ESP akan memberikan ID klien baru, hanya untuk mencegah broker menolak koneksi baru ketika broker masih mengasumsikan koneksi yang ada dari klien itu dan klien mengira itu terputus.

Dapatkah Anda meningkatkan pengaturan batas waktu pengontrol? Default-nya adalah 1000 msec, sebelum saya memperkenalkan pengaturan itu dan build pertama memiliki 100 msec sebagai default. Kemudian saya mengubah default (untuk pengaturan baru) menjadi 300 msec.
Jadi mungkin Anda dapat mencoba menyetelnya ke 300 atau lebih tinggi (tidak lebih tinggi dari 1000 msec) hanya sebagai percobaan. (tidak peduli versi apa, setidaknya yang dulu gagal)

Saya mengalami masalah yang sama dengan 1 (dari 5) unit. Saya telah bermain sedikit dengan pengaturan pengontrol MQTT (Minimum Send Interval, Max Queue depth, Max retries & Full Queue Action); pengaturan yang berfungsi sekarang untuk saya dengan unit ini: 1000ms, 5/5 dan "Hapus Terlama".

Ok berita ...
Sepertinya ini adalah masalah yang sama dengan yang dibicarakan oleh blb4github 12 jam yang lalu. Mengambil Unit BARU dan bekerja sampai sekarang tanpa Masalah !!!! Sepertinya yang "lama" memang memiliki masalah memori atau masalah waktu. Saya akan mencoba meningkatkan timout yang satu ini ... terus memberi tahu Anda ;-)
Btw .. (Maaf .. Bangun Sendiri dengan Atom .. karena saya tidak ingin semua Plugin ... Tapi sampai sekarang selalu berjalan dengan baik ..) Kalian semua melakukan pekerjaan yang bagus untuk ini ... dan sejauh yang saya temukan hanya ini (dan karena itu yang memiliki SW terbaru) yang memiliki masalah ini. Saya akan meningkatkan pengaturan dan memberi tahu Anda.

Salam Peter

@fraeggle apakah mungkin bagi Anda untuk menempelkan di sini tangkapan layar dari halaman modul systeminfo yang baik dan buruk? (esp dan bagian penyimpanan)

Dan beberapa deskripsi tentang perangkat kerasnya.
Misalnya saya merasa ada beberapa perubahan baru-baru ini dalam modul sonoff.
Sonoff basic dan S20

@fraeggle Bisakah Anda mungkin juga melakukan penghapusan penuh node bermasalah dan mulai bersih?
File tempat sampah kosong disertakan dalam file ZIP rilis.

Hai TD-er
saya telah menghapus node yang buruk sebelumnya ... Karena saya telah mengubah Pengaturan Timeout ke 800ms
itu stabil. Tegangan diperbarui setiap 120 detik.

Hardware tidak ada yang istimewa .... karena masih menunggu INA219 tiba .. ;-)

Salam Peter

ups saya sayangnya menutupnya ..

Tapi menurutku dengan "workaroud" ini bisa ditutup ... Menurutku sekarang ini adalah masalah Unit ..
Apa pendapat Anda tentang itu TD-er?

Namun anehnya unit berbeda dalam aspek ini.
Ini menunjukkan stabilitas wifi lebih buruk dalam satu unit

Saya setuju tetapi saya pikir unit ini memiliki rentang toleransi yang terlalu besar. Seperti yang saya katakan, karena saya berubah menjadi 800 ms itu berfungsi dengan baik ...
jadi jika Anda setuju saya akan menutup yang ini, karena fakta bahwa ada kemampuan untuk mengubah batas waktu.

Terima kasih atas bantuan Anda..

salam Peter

saya menemukan "sejak 20181007 MQTT Open Hab menunjukkan" Connection Lost "# 1873.
Mungkin masalah yang sama?
TD-er beri tahu saya jika saya dapat membantu dengan membuat log atau sesuatu seperti itu ...
Menggunakan Openhab (dengan IOBroker). tapi sampai sekarang tidak ada error setelah setting Timeout ke 800ms

Apakah broker MQTT untuk OpenHAB Anda jalankan, diinstal pada komputer di jaringan Anda sendiri, atau eksternal?
Dan jika bersifat lokal, apakah mungkin diinstal di komputer yang kekurangan sumber daya?

saya juga memiliki tes yang berjalan sejak 394 menit pada 20181020.
Batas waktu di 800ms.
Terkadang itu muncul sebagai Terputus setelah 24 jam atau bahkan lebih lama. Tapi saya tidak pernah mencapai 2 hari.
Dan sekali lagi, bagi saya semua masih berfungsi setelah menunjukkan "Koneksi Hilang". Jadi hanya pesannya saja yang membingungkan bagi saya. saya akan tetap mengiformasikan ke anda

Koneksi Hilang hanya pesan informasi yang menunjukkan ... koneksi terputus.
Tetapi itu harus memulai kembali koneksi baru.
Di halaman sysinfo Anda dapat melihat seberapa sering koneksi WiFi terputus dan dibangun kembali dan juga berapa lama terhubung ke WiFi sejak terakhir (kembali) terhubung ke titik akses.

Segera setelah koneksi WiFi terputus, itu juga akan menganggap koneksi MQTT harus dibangun kembali, jadi koneksi ke broker MQTT akan dianggap hilang.
Hingga 4 minggu yang lalu, ada kemungkinan broker MQTT tidak menerima upaya koneksi baru, karena broker masih menganggap klien terhubung.
Hal ini dapat mengakibatkan upaya menghubungkan kembali tanpa batas, ketika klien terus mencoba untuk terhubung dan broker tidak menerima koneksi.
Saya mengubah ID klien MQTT pada setiap koneksi ulang (menambahkan jumlah koneksi ulang ke ID klien) sehingga broker akan menganggapnya sebagai klien baru.
Ini menghasilkan koneksi ulang yang cepat, dengan satu-satunya kekurangan, broker akan mengirimkan LWT (surat wasiat dan wasiat terakhir) karena menganggap klien terputus.

Jika itu menghasilkan perilaku yang tidak diinginkan, saya bisa mengubahnya menjadi strategi baru.
Misalnya pada upaya menyambungkan kembali yang gagal, saya dapat mencoba mengirim pesan putuskan sambungan yang benar terlebih dahulu.

Singkatnya, ada banyak opsi di mana koneksi ke broker bisa hilang dan saya tidak yakin mengapa dalam kasus Anda itu hilang.
Bisa jadi timeout, koneksi WiFi terputus, beberapa respon yang tidak diketahui dari broker atau alasan lainnya.

OK mengerti.
Pernyataan yang sangat bagus, terima kasih.
Saya berada di menit ke-507 sekarang / Buka pengontrol HAB / batas waktu 800ms.
Sejauh ini semuanya baik-baik saja :)

Haruskah saya menyetel batas waktu default untuk instance baru pengontrol kembali ke 1000 msec?

baik ...... beri saya 36 jam lagi ..... maka saya tahu lebih baik tentang bug yang datang juga dengan 800ms atau tidak.

Menit 629 sekarang tanpa masalah ...

aneh ... ketahuan mengikuti setelah perubahan ke 800ms.
Alasan Pemutusan Terakhir | (200) Batas waktu suar
Nomor menghubungkan kembali | 3
Apa artinya das Beacon Timeout?
MQTT masih berjalan tetapi sekarang sama dengan Sasch600txt. Tapi berbeda dari sebelumnya ... MQTT masih berfungsi
hanya broker yang mengatakan bahwa ini tidak terhubung.

Untuk informasi lebih lanjut tentang bingkai Beacon, lihat Wikipedia
Singkatnya, jalur akses secara berkala mengirimkan paket yang berisi informasi tentang jaringan.
Interval ini biasanya 100 TU (102,4 msec).
Modul ESP mencoba mendengarkan beacon ini setiap saat, tetapi karena sejumlah alasan modul ini mungkin melewatkan bingkai beacon. Waktu tunggu lebih lama dari 100 TU, sehingga sejumlah bingkai suar harus terlewat untuk melaporkan waktu tunggu suar.
Alasan untuk melewatkan bingkai suar seperti itu adalah:

• terlalu sibuk memproses tugas pemblokiran lainnya (sangat mungkin)
• titik akses tidak mengirim suar karena permintaan lalu lintas yang tinggi dari orang lain (tergantung pada merek / model / pengaturan)
• Gangguan RF (kemungkinan tidak diberikan seberapa sering hal ini terjadi)
• clock drift (tidak terlalu mungkin)

Jadi "batas waktu suar" terjadi sesekali di simpul ESP.
Saya bekerja keras agar setiap plugin / pengontrol menggunakan irisan waktu singkat untuk membuat tugas sesedikit mungkin memblokir.

saya bisa mengkonfirmasi semua kata fraeggle.
Suatu saat malam ini saya mendapat "Koneksi Hilang"

Selamat berakhir pekan :)
Sascha

@rumahsakitotak :
jika muncul sebagai "Sambungan Hilang" coba masuk ke Pengaturan Pengontrol ESPEasy, cukup nonaktifkan pengontrol -> simpan, aktifkan lagi -> simpan. Kemudian setidaknya bagi saya itu muncul sebagai terhubung lagi. Bukan solusi, tapi setidaknya menarik :) apakah IPSymcon ini yang Anda gunakan?

@ TD-er:
tugas yang terlalu sibuk? baik ...... di "TEST UNIT" saya telah berjalan di sini, saya hanya mengirim menit uptime setiap 60 detik ...... tidak ada lagi yang berjalan di unit ini ..... jadi mungkin sistem sekecil mungkin

@ Sasch600xt istilah "terlalu sibuk" mungkin bukan yang terbaik untuk menjelaskan masalah sebenarnya.
Cara Arduino dalam melakukan sesuatu adalah:

• hubungi setup()
• panggil loop() berulang kali.

Selain itu, versi Arduino untuk ESP8266 (dan ESP32 Arduino) menjalankan beberapa tugas di luar loop() untuk bagian Arduino.
Tugas-tugas ini tentang proses latar belakang, seperti menangani koneksi jaringan dan lalu lintas masuk, dll.
Tugas latar belakang dijalankan hanya di:

• akhir dari loop()
• saat menelepon delay() atau yield() dari dalam ruang Arduino.

Jika menjalankan loop membutuhkan waktu lebih dari 102,4 msec dan tidak ada panggilan ke yield () atau delay () yang dibuat, node ESP akan melewatkan interval beacon.
Juga jika menjalankan beberapa tugas pemblokiran yang selalu sibuk saat titik akses WiFi mengirim suar, sejumlah suar akan terlewat.

Saat Anda melihat log serial (dengan level Debug diaktifkan), Anda akan melihat statistik waktu.
Beberapa dari mereka mungkin membuat beberapa puluh msec dan dengan demikian merupakan kandidat untuk menyebabkan alasan 'putuskan' ini.

Saya dapat menambahkan tugas ke penjadwal untuk mencoba mendengarkan suar setiap 102,4 msec. Hanya masalahnya, saya tidak yakin bagaimana cara melihat ketika suar seperti itu telah terlihat.

Tentang masalah ini, saya dapat memeriksa pemutusan / menyambungkan kembali MQTT ketika koneksi telah hilang.
Broker apa yang Anda gunakan? Saya menggunakan Mosquito di sini dan berfungsi dengan baik dengan perilaku saat ini.

ok, "terlalu sibuk" itu agak mudah dikatakan oleh saya :)

Saya menggunakan skrip yang berjalan di eviroment kontrol rumah ipsymcon saya

Salam
Sascha

Hai Sascha .. Menggunakan IOBroker.
@ TD-er kembali ke Build 27092018. Pialang Memberitahu saya masih Terhubung ...
Benar-benar Membingungkan .. TIDAK ADA kesalahan dalam 14 Jam (Nomor terhubung kembali | 0)

Saya menginstal IObroker sekarang di komputer saya, hanya untuk melihat apa yang terjadi.

Edit:
45 menit kemudian dan saya masih belum bisa menjalankan IObroker di komputer saya.
Tidak yakin apa yang terjadi di sini, tetapi penginstal Windows tidak berfungsi (file layanan bat tidak dapat ditemukan) dan instalasi di Linux tidak selesai. Itu terus mencoba melakukan instalasi npm yang sama berulang kali.
Diuji pada Ubuntu 18.04 pada host Intel CPU dan Bash pada Windows (Ubuntu 18.04)

tidak yakin dengan windows .. saya rasa ada beberapa ketergantungan perangkat lunak. Menjalankannya di Raspberry.
untuk Windows ioBroker verwendet Node.js als Plattform und setzt diese voraus. (Unduh: http://nodejs.org/download/) node.js pertama harus diinstal.

Saya juga memiliki masalah dengan satu modul dengan 4 sensor DS18B20 terhubung.
Saya pikir itu adalah RasPi saya tetapi mengambil gambar Raspbian Streth yang bersih dan menginstal mosquitto dan node-red di atasnya. Masalah yang sama, koneksi terputus setelah 6-12 jam.

Dasbor: https://emoncms.org/Edegem/scrtmp2e
4 kurva dari ESP adalah CV_aanvoer, CV_retour dan Sanitair_warm, Sanitair_koud

@fluppie jika Anda menggunakan bangunan resmi?

Tidak, saya membangun sendiri dengan PlatformIO / Atom
EDIT: Ha, saya tidak membaca dengan baik, saya akan mencoba versi resmi.

Ayo lihat ini!

Hai

Saya memiliki / memiliki masalah yang sama, saya menggunakan HomeAssistant tetapi setelah ESPEasy_mega-20181111 fw adalah masalah yang tampak diperbaiki bagi saya.

Terima kasih
T

Punyaku masih kehilangan koneksi setelah 2-3 hari. Saya akan memperbarui ke: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

Ayo lihat!

Punyaku kehilangan koneksi. setelah 1-10 jam. Saya memiliki waktu aktif ~ 10 jam 30 menit dan semua (5 pcs) modul terkait terhubung. :-)

sepertinya akan layak untuk dicoba ... masih di 2709 karena membutuhkan koneksi yang stabil. Tolong beri saya informasi. :-))

Anda juga dapat mengikuti melalui: https://emoncms.org/Edegem/scrtmp2e dan memeriksa apakah grafik CV_ dan Sanitair_ ada di sana :).

1 hari uptime dan masih ok. :-)

Anda juga dapat mengikuti melalui: https://emoncms.org/Edegem/scrtmp2e dan memeriksa apakah grafik CV_ dan Sanitair_ ada di sana :).

:-D Sanitair_warm hampir 60 C? api unggun kecil? ;-)
Saya akan mencoba perusahaan .. Terima kasih ...

Saya sedang mandi ;-)

1 hari ... masih terhubung :-D
menggunakan 12112018

Setelah ~ 3 hari 3 jam salah satu unit saya kehilangan koneksi MQTT. :-( (mega-20181112 4096 VCC fw)

@bayu_joo :
hanya untuk memastikan, apakah masih berfungsi dengan baik setelah unit kehilangan koneksi MQTT?
karena di sisi saya, ini hanya muncul sebagai "koneksi terputus" tetapi masih berfungsi dengan baik dengan semua tindakan MQTT.

Salam
Sascha

Memang, koneksi yang terputus tidak jarang terjadi sesekali.
Selama koneksi dibangun kembali tanpa campur tangan manusia, tidak ada masalah.
Koneksi WiFi akan disetel ulang sesekali dan tidak ada yang dapat Anda lakukan untuk mencegahnya.
Segera setelah koneksi terputus, klien MQTT pada node yang sama akan diberitahu untuk menyambungkan kembali.

Sepertinya masalah terkait LWT. MQTT tidak sepenuhnya terputus, ESPEasy mengirim / menerima pesan MQTT tetapi LWT tidak diperbarui sehingga HomeAssistant tidak mendapatkan pesan terhubung LWT sehingga menunjukkan sensor / sakelar yang relevan tidak tersedia. Ini teori saya ...

Milik saya Masih terhubung dan tidak seperti posting pertama saya, bahkan MQTT LWT memberi tahu saya terhubung. Kelihatan bagus.

Memang, koneksi yang terputus tidak jarang terjadi sesekali.
Selama koneksi dibangun kembali tanpa campur tangan manusia, tidak ada masalah.
Koneksi WiFi akan disetel ulang sesekali dan tidak ada yang dapat Anda lakukan untuk mencegahnya.
Segera setelah koneksi terputus, klien MQTT pada node yang sama akan diberitahu untuk menyambungkan kembali.

OK, apakah ada kemungkinan untuk memperbarui LWT yang terhubung dalam kasus ini?

Itu seharusnya mengirim LWT pada saat itu memperbarui koneksi.

Saya memiliki node sekarang yang ditampilkan terputus di LWT dan mengirimkan pengukuran dengan baik. Sedikit lebih tua ... mungkin ini memberitahumu sesuatu

Versi GIT: | mega-20181008
Uptime: | 3 hari 17 jam 36 menit

Saya telah melihat hal-hal aneh ketika simpul ESP mengira itu terputus dan perlu dihubungkan kembali, tetapi pialang tidak setuju.

Hai

Saya melakukan penyelidikan kecil. Sepertinya hanya LWT yang menjadi masalahnya. Salah satu ESP saya menghasilkan benda "terputus" MQTT ini lagi.

Semuanya bekerja dengan baik, sensor / sakelar. Tetapi Asisten Rumah tidak dapat melihatnya karena di konfigurasi saya memberikan detail LWT.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

Saya memeriksa lalu lintas MQTT: Saya mendapatkan data sensor dan saya dapat menyalakan / mematikan GPIO. Semuanya baik-baik saja ex. LWT tersebut.

Dan setelah saya mempublikasikan pesan "Terhubung" LWT dan semuanya kembali normal.

Saya harap ini membantu.

T

PS:
Saya memikirkan tentang satu aturan yang dapat mempublikasikan pesan LWT Connected jika pesan LWT Terputus, tetapi sayangnya saya tidak dapat mengimpor string MQTT ;-)

Bagaimanapun, saya sangat menantikan rilis fw baru. 4 hari yang panjang ....

Saya pergi pada hari Senin / Selasa dan hari-hari setelahnya sangat sibuk;)

Saya akan melihat LWT untuk melihat apakah saya dapat menemukan mengapa LWT tidak dipublikasikan saat tersambung kembali.

Apa pengaturan batas waktu dari broker MQTT?
Saya memikirkan kemungkinan broker mengasumsikan koneksi yang hilang, tetapi simpul ESP masih bertindak seperti itu telah aktif dan masih terhubung.

Saya mencoba 100-1000 ms. Sekarang 300. Tidak masalah.

Bukan di controller, di broker.
Pengaturan waktu tersebut berkisar antara 10 - 15 detik.
Jadi harap periksa di konfigurasi broker tentang batas waktu yang digunakan.

Saya tidak mengubah apa pun tentang batas waktu LWT dan saya tidak dapat menemukan pengaturan yang relevan di konfigurasi Mosquitto saya. Ini harus default. Saya tidak bisa menemukan pengaturan batas waktu LWT di dokumen juga.

Tidak, bukan batas waktu LWT, batas waktu broker.
Jika klien tidak mengirim pesan dalam periode waktu tunggu, broker akan menganggapnya terputus.
Jadi jika klien menggunakan pengaturan waktu tunggu lain, bisa jadi broker menganggap klien terputus dan klien tidak mencoba menyambung kembali.

Apa yang saya pahami dari spesifikasi mqtt Broker mengirim LWT ketika tidak menerima pesan dari klien dalam Keep Alive Period yang diatur oleh klien. Tidak ada yang perlu dikonfigurasi di sisi pialang.

Lihat https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

Dan

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

Itu benar, tapi yang ingin saya ketahui adalah apakah "Periode Tetap Hidup" ini ada di sisi pialang.
Saya tahu itu diperbaiki di sisi ESPeasy.
Tetapi jika ini tidak sinkron satu sama lain, Anda akan melihat hal-hal aneh terjadi.

hm saya tidak punya kemungkinan untuk mengatur sesuatu seperti ini

Tapi tetap bertuliskan "Terhubung". 4 Hari :-D

baru saja satu mega-20181006 melakukan hal yang sama. LWT tidak diperbarui ke Online tetapi MQTT berfungsi normal

@ jimmys01 Dapatkah Anda melihat di pialang Anda apakah itu mendasarkan keputusan pada ID klien? (ini berubah ketika koneksi terputus)
Perubahan ID klien ini adalah sesuatu yang saya tambahkan pada build akhir September.

@ TD-er, saya menemukan cara untuk mereproduksi ini! Saya de-auth wemos dari router mikrotik dan terhubung langsung kembali, tetapi LWT tetap offline sementara mqtt masih berfungsi. Kirimkan saya bangunan untuk diuji sesuka hati

Bisakah Anda juga melihat ID klien di broker MQTT?
Jika memiliki "-1" atau sesuatu di belakang ID klien, itu berarti menerima ID klien baru.
Jika tidak, mungkin ada hubungannya dengan perubahan ID klien yang saya buat beberapa waktu lalu.

Saya tidak tahu di mana id klien berada di Mosquitto, tetapi log menunjukkan seolah-olah tidak ada klien yang terputus dan yang baru terhubung, mungkin karena proses de-auth wifi dan auth lebih cepat daripada detak jantung protokol MQTT.

Koneksi baru setelah saya restart baik esp maupun brokernya

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

De-auth klien dan klien terhubung kembali. Pialang kali ini membiarkan klien LWT online karena suatu alasan ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

De-auth kedua

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

Dari sambungan ulang ini dan di LWT tetap ofline, pesan MQTT berfungsi dengan baik. Perhatikan _1_1 tambahan pada nama klien.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

Oke, saya akan mengembalikan perubahan ID klien.
Mungkin juga untuk memeriksa jarak jauh jika klien dianggap terhubung?
Saya telah melihat koneksi menolak ketika broker menganggap klien masih terhubung dan klien mencoba untuk menyambung kembali.
Mencoba ulang dalam interval singkat akan mempertahankan status ini dan dengan demikian klien tidak akan pernah dapat menyambung kembali.

Ada pembaruan status tentang ini?

Tidak, belum.
Tetapi karena kami membuat beberapa kemajuan (akhirnya) pada masalah stabilitas lainnya, saya kira ini akan menjadi yang berikutnya dalam daftar saya.
Terima kasih atas pingnya;)

Saya menjadikannya opsional untuk mengubah ID klien saat menghubungkan kembali. (Tools => Advanced, di sebelah pengaturan MQTT lainnya)

Harap tutup masalah jika berfungsi sekarang.
Saya akan mengaturnya menjadi tetap.

Mengapa tetap mengubah ID klien?

Ada laporan broker menolak upaya koneksi selama broker menganggap klien masih terhubung.
Jadi klien ditolak dan mencoba lagi.
Tetapi entah bagaimana menghubungkan kembali itu memicu sesuatu di sisi broker untuk menganggap upaya koneksi sebagai aktivitas terbaru dari klien itu dan karenanya tidak akan pernah menganggap klien untuk diputuskan.

Ok ini menyelesaikannya, tetapi solusinya tidak cukup jelas untuk orang lain yang melihat kotak centang itu.
Mungkin menambahkan pop up yang akan menjelaskan untuk mencentangnya jika ada masalah koneksi ulang setelah kehilangan wifi
Pencarian di masalah tasmota akan menunjukkan kepada Anda bahwa mereka memiliki masalah yang tampak serupa, terkait dengan penyimpanan MQTT, sepertinya ini adalah masalah broker.
Saya juga memiliki satu klien yang tidak tersambung kembali ke wifi sama sekali setelah saya membatalkannya ... perlu menyelidikinya.

Kami akan menambahkan ini ke dokumentasi .
Kami bekerja sangat keras untuk membuat dokumentasi menjadi mutakhir dan juga memindahkan banyak dokumentasi dari wiki ke ReadTheDocs. Ini memungkinkan untuk memiliki dokumentasi per versi.
File dokumen juga disertakan dalam repositori GitHub.

Idealnya komit untuk perbaikan dalam kode juga akan berisi pembaruan dalam dokumentasi de.
Sekarang saya akan menutup masalah ini.
Jika Anda memiliki informasi lebih lanjut tentang masalah lain yang Anda sebutkan, buka masalah baru untuk itu.

Hai

Saya menginstal rilis 20190110 baru-baru ini. Ini terlihat menjanjikan. Tidak ada masalah LWT setelah 5 hari pengujian. :-)
Saya memiliki beberapa node dengan opsi "MQTT change ClientId at reconnect" diaktifkan dan beberapa dengan nonaktif.

Kabar baik!

T