Deconz-rest-plugin: Lampu IKEA terkadang kehilangan koneksi

Sama di sini dengan 2.05.58. Satu Tradfri GU10 tampaknya tidak bertanggung jawab atm:

Terjadi pada saya dengan strip cahaya rona beberapa hari sebelumnya, jadi saya rasa tidak ada masalah khusus IKEA. Perangkat harus dihidupkan ulang dan kembali normal setelah itu. Masih mengganggu dalam beberapa kasus, kebanyakan untuk Panel FLOALT saya yang diberi daya secara langsung dan tidak memiliki sakelar dinding untuk menghidupkannya.

1. Ada petunjuk kenapa?

Plugin REST API menandai cahaya sebagai tidak terjangkau, ketika tidak menerima respons beberapa kali saat mengumpulkan cahaya untuk statusnya. Penyebab tidak menerima tanggapan adalah, dalam urutan kemungkinannya:
Sebuah. Daya lampu telah terputus (misalnya oleh sakelar dinding abad ke-20);
b. Jaringan Zigbee mengalami cegukan (misalnya karena gangguan radio atau masalah perutean pada mesh). Dalam hal ini, cahayanya masih bereaksi terhadap perintah grup;
c. Firmware lampu macet.

1. Apakah mungkin untuk memulihkan koneksi selain memutuskan / menghubungkan daya?

Dalam a) dan c): tidak. Dalam b): ya.

Plugin REST API menandai cahaya sebagai dapat dijangkau, ketika menerima pesan darinya. Menyalakan lampu menyebabkannya mengirim pesan _Device Announcement_. Dalam b), biasanya, cahaya kembali secara spontan, saat polling berikutnya berhasil. Anda juga dapat memilih node di deCONZ GUI dan menekan 0 .

Masalah yang sama juga terjadi di versi 2.05.59.

Saya juga mengalami masalah ini, bahkan setelah memutakhirkan ke 2.05.59. Hari ini adalah salah satu dari tiga lampu luar ruang saya yang "mati".
Lampu Tradfri-nya bertiga.

@ ebaauw Terima kasih atas penjelasan Anda.

Sebuah. Daya lampu telah terputus (misalnya oleh sakelar dinding abad ke-20);

Tidak ada sakelar dinding yang tersedia untuk lampu ini, jadi saya tidak dapat memutuskan daya secara tidak sengaja.

b. Jaringan Zigbee mengalami cegukan (misalnya karena gangguan radio atau masalah perutean pada mesh). Dalam hal ini, cahayanya masih bereaksi terhadap perintah grup;

Lampu tidak bereaksi pada perintah grup saat koneksi terputus (lampu ditetapkan ke Hue Dimmer di aplikasi Phoscon dan tidak merespons pada Hue Dimmer saat koneksi terputus).

c. Firmware lampu macet.

Firmware 1.2.214 diinstal di semua tempat IKEA GU10 saya. Punya 20+ dari mereka dan cahaya acak menjadi offline, katakanlah satu dalam 2-3 minggu.

Anda dapat mencoba versi deCONZ terbaru dengan https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

Saya memiliki pengalaman yang sama dua kali dalam beberapa bulan terakhir dengan dua lampu E14 IKEA yang berbeda (IKEA fw 1.2.214).
Power cycle bekerja dua kali untuk saya.

c. Firmware lampu macet.

Ketika lampu tidak bereaksi bahkan terhadap perintah grup, sepertinya firmware rusak.

2.05.59 telah mengadaptasi parameter gerbang IKEA untuk mengonfigurasi pelaporan kondisi cahaya. Terutama dengan harapan tidak memicu bug apa pun dengan menggunakan konfigurasi yang tidak diuji oleh IKEA sendiri. Catatan samping perubahan tidak akan menyebabkan timer digunakan untuk pelaporan di perangkat lagi.

Konfigurasi baru akan diterapkan setelah lampu dinyalakan ulang.

Kami masih mengirimkan beberapa permintaan pemeliharaan seperti keanggotaan grup dan permintaan tabel tetangga ke lampu, dan mungkin membatasi ini lebih lanjut jika stabilitas tidak meningkat dengan 2.05.59.

Ingatlah bahwa mungkin juga ada kemungkinan bahwa bug ada di firmware ringan yang tidak terkait dengan permintaan apa pun yang dikirim gateway.

c. Firmware lampu macet.

Ketika lampu tidak bereaksi bahkan terhadap perintah grup, sepertinya firmware rusak.

2.05.59 telah mengadaptasi parameter gerbang IKEA untuk mengonfigurasi pelaporan kondisi cahaya. Terutama dengan harapan tidak memicu bug apa pun dengan menggunakan konfigurasi yang tidak diuji oleh IKEA sendiri. Catatan samping perubahan tidak akan menyebabkan timer digunakan untuk pelaporan di perangkat lagi.

Konfigurasi baru akan diterapkan setelah lampu dinyalakan ulang.

Kami masih mengirimkan beberapa permintaan pemeliharaan seperti keanggotaan grup dan permintaan tabel tetangga ke lampu, dan mungkin membatasi ini lebih lanjut jika stabilitas tidak meningkat dengan 2.05.59.

Ingatlah bahwa mungkin juga ada kemungkinan bahwa bug ada di firmware ringan yang tidak terkait dengan permintaan apa pun yang dikirim gateway.

+1 pada "tidak selalu terkait dengan deconz melainkan jaringan Zigbee atau FW pabrikan" sehubungan dengan interpretasi standar Zigbee di pabrikan FW.

Saya baru saja memperbarui ke 2.05.59 dan setelah memulai ulang deconz lampu yang sama tidak dapat dijangkau lagi. Menekan 0 di gui tidak mengembalikannya. Karya cahaya lainnya. Dalam kasus saya ini mungkin juga menjadi masalah dengan cahaya itu sendiri.

@ peer69 @ thomas70 Apakah Anda menyalakan lampu seperti yang disebutkan oleh @manup di https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127?

Konfigurasi baru akan diterapkan setelah lampu dinyalakan ulang.

Petunjuk bagus, belum melakukan itu. Untuk saat ini saya harus kembali ke .58 karena alasan lain (beban cpu tinggi yang membuat gateway tidak responsif), akan coba ini nanti hari ini dengan .59 lagi dan matikan semua lampu ikea.

Saya juga mengalami masalah ini, itu terjadi dua kali untuk lampu GU 10 yang sama. Saat ini menjalankan 2.05.59, dan saya melakukan siklus daya lampu setelah pembaruan.

Lupa menambahkan bahwa terkadang bohlam yang sama terus rusak. Beberapa waktu yang lalu saya memang memiliki masalah dengan bohlam lain, dan itu akan selalu menjadi yang berhenti bereaksi.

Setelah siklus daya, bohlam IKEA saya kembali. Tetapi panel IKEA FLOALT WS saya masih offline

Saya mengalami masalah yang sama dan telah melakukannya cukup lama, dan menurut saya 0,59 sebenarnya memperburuk keadaan. Saya memiliki 80 node di mana 32 adalah lampu dan sakelar Trådfri, 5 adalah lampu Hue dan sisanya adalah perangkat bertenaga baterai Xiaomi yang berbeda seperti suhu, gerakan, detektor asap, dll. Setiap jenis perangkat telah tidak responsif setidaknya sekali jadi dalam kasus saya ini bukan hanya lampu Trådfri, tetapi saat ini saya hanya mengalami masalah dengan lampu Trådfri dan Hue.

Masalahnya adalah saya menjalankan semua lampu melalui jembatan Hue dan sensor Xiaomi melalui gateway Xiaomi sebelumnya dan kemudian semuanya kokoh, jadi saya rasa bukan firmware perangkat yang menjadi penyebab dalam kasus saya kecuali jika disebabkan oleh perubahan keadaan.

Saya memiliki enam lampu Trådfri GU10 di satu lokasi yang bekerja dengan sempurna sebelumnya, tetapi setelah peningkatan ke .59 dan beberapa siklus daya kemudian, mereka sekarang hampir sepenuhnya tidak responsif dan saya mungkin harus mengatur ulangnya. Yang aneh adalah ketidakresponsifan ini juga tampaknya "bergerak" dari lampu yang berbeda tergantung pada lampu mana yang memiliki daya. Jika saya mematikan daya ke beberapa lampu yang tidak responsif, mungkin diperlukan beberapa saat dan kemudian tiba-tiba ada lampu lain yang tidak ingin berfungsi dengan benar. Mungkin ada penyeimbangan di suatu tempat yang merusak barang?

Masalahnya adalah saya menjalankan semua lampu melalui jembatan Hue dan sensor Xiaomi melalui gateway Xiaomi sebelumnya dan kemudian semuanya kokoh, jadi saya rasa bukan firmware perangkat yang menjadi penyebab dalam kasus saya kecuali jika disebabkan oleh perubahan keadaan.

Menarik, apakah Anda juga memiliki semua 32 lampu Ikea di jaringan Hue? Saya bertanya karena Hue bridge hanya menggunakan polling dan tidak mengonfigurasi pelaporan atribut.

Apakah Anda juga memiliki perangkat router seperti lampu Hue atau Ikea di jaringan Xiaomi?

Saya memiliki enam lampu Trådfri GU10 di satu lokasi yang bekerja dengan sempurna sebelumnya, tetapi setelah peningkatan ke .59 dan beberapa siklus daya kemudian, mereka sekarang hampir sepenuhnya tidak responsif dan saya mungkin harus mengatur ulangnya. Yang aneh adalah ketidakresponsifan ini juga tampaknya "bergerak" dari lampu yang berbeda tergantung pada lampu mana yang memiliki daya. Jika saya mematikan daya ke beberapa lampu yang tidak responsif, mungkin diperlukan beberapa saat dan kemudian tiba-tiba ada lampu lain yang tidak ingin berfungsi dengan benar. Mungkin ada penyeimbangan di suatu tempat yang merusak barang?

Hmm itu sangat buruk Saya benar-benar bertanya-tanya bagaimana ini terjadi, 2.05.59 adalah cara yang "akrab" bagi lampu Ikea daripada versi sebelumnya. Konfigurasi sekarang terjadi seperti gateway Ikea yang melakukannya.

Ketika lampu menjadi tidak responsif, dapatkah Anda memilih node di deCONZ dan tekan 0 jika menjadi responsif / kuning lagi lampu tidak perlu di-power-cycled. Perhatikan cahaya yang menjadi Zombie dalam hal ini akan segera diperbaiki, hal ini mungkin terjadi pada konstelasi jaringan tertentu saat ini.

Ngomong-ngomong pertanyaan biasa:

• Versi firmware mana yang Anda gunakan?
• RaspBee atau ConBee?
• Jika ConBee apakah Anda menggunakan kabel ekstensi usb?

Butuh beberapa saat lebih lama dari yang diharapkan tetapi sekarang semuanya benar-benar tampak berfungsi dengan baik lagi. Setidaknya untuk saat ini dari apa yang bisa saya ceritakan.

Saya mem-boot ulang server dan juga menyalakan siklus setiap lampu bertenaga utama di jaringan untuk memastikan bahwa mereka mengambil konfigurasi terbaru, tetapi meskipun demikian, butuh beberapa jam sebelum masalah hilang jadi saya agak prematur dalam asumsi saya bahwa masalah tetap ada karena tidak langsung bekerja.

Menarik, apakah Anda juga memiliki semua 32 lampu Ikea di jaringan Hue? Saya bertanya karena Hue bridge hanya menggunakan polling dan tidak mengonfigurasi pelaporan atribut.

Ya, semacam itu. Saya memiliki 31 lampu Ikea di jaringan Hue serta lampu Hue. Perangkat Ikea ke-32 adalah stopkontak yang belum saya beli saat itu.

Apakah Anda juga memiliki perangkat router seperti lampu Hue atau Ikea di jaringan Xiaomi?

Tidak, hanya sensor bertenaga baterai

Ketika lampu menjadi tidak responsif, dapatkah Anda memilih node di deCONZ dan tekan 0 jika menjadi responsif / kuning lagi lampu tidak perlu di-power-cycled. Perhatikan cahaya yang menjadi Zombie dalam hal ini akan segera diperbaiki, hal ini mungkin terjadi pada konstelasi jaringan tertentu saat ini.

Saya memang mencoba ini beberapa kali sebelumnya tanpa efek. Dan untuk perangkat keras dan pengaturannya, saya menggunakan ConBee dengan kabel ekstensi USB dan 262F0500. Karena semuanya tampaknya berfungsi dengan baik untuk saya sekarang, info ini mungkin tidak ada gunanya saat ini tetapi saya akan mencoba untuk tidak langsung mengambil kesimpulan dan membiarkan jaringan berjalan selama beberapa hari untuk memastikan bahwa masalahnya tidak kembali.

Saya telah menjalankan 0,59 sejak akhir minggu lalu dan saya masih kehilangan lampu Ikea acak. (16 lampu E27 di fasad rumah.)
Bulb FW sama dengan yang lain yang masih ada di Ikea Gateway.
Menggunakan ConBee dengan 262F0500 FW.
Akhir minggu lalu saya juga membeli jembatan HUE dan baru saja akan mulai memindahkan lampu ketika saya melihat catatan rilis 'Di bawah kap' untuk 0,59. Memutuskan untuk menunda, tetapi akan mempertimbangkan kembali akhir minggu mendatang ini.
Deconz masih akan menjadi pengontrol Xiaomi / mi Cube terbaik saya. Belum melewatkan satu gerakan pun.

Saya telah menjalankan 0,59 sejak akhir minggu lalu dan saya masih kehilangan lampu Ikea acak. (16 lampu E27 di fasad rumah.)
Bulb FW sama dengan yang lain yang masih ada di Ikea Gateway.
Menggunakan ConBee dengan 262F0500 FW.
Akhir minggu lalu saya juga membeli jembatan HUE dan baru saja akan mulai memindahkan lampu ketika saya melihat catatan rilis 'Di bawah kap' untuk 0,59. Memutuskan untuk menunda, tetapi akan mempertimbangkan kembali akhir minggu mendatang ini.
Deconz masih akan menjadi pengontrol Xiaomi / mi Cube terbaik saya. Belum melewatkan satu gerakan pun.

Saya memiliki situasi yang sama di sini, 16 lampu IKEA, 2 outlet kontrol IKEA, steker Heiman dan steker innr dan beberapa sensor Xiaomi (sensor kubus / pintu / sensor gerak). Tidak pernah mengalami masalah dengan perangkat non-IKEA. Namun saat ini saya memiliki masalah hampir setiap hari di mana lampu IKEA padam dari jaringan

Saya menggunakan Conbee dengan kabel ekstensi USB pada firmware 0x26300500 dan deCONZ .59

Lampu saya telah bekerja dengan baik untuk beberapa waktu sekarang, tetapi beberapa hari yang lalu lampu Trådfri E14 saya tiba-tiba menjadi tidak responsif. Satu siklus daya kemudian hidup kembali.

Hari ini adalah waktu untuk salah satu GU10 untuk keluar. Secara fisik sangat dekat dengan E14 yang disebutkan sebelumnya jadi saya tidak yakin apakah itu kebetulan atau bukan. GU10 mungkin telah dirutekan dengan baik melalui E14 meskipun semua lampu saya berada dalam jangkauan ConBee.

Memilih node dan menekan 0 di deCONZ tidak akan menghasilkan apa-apa. Saya juga mencoba me-reboot container deCONZ dan saat merutekan ulang jaringan saat startup, ia tidak menghubungkan rute apa pun ke bohlam tertentu. Apa pendekatan terbaik di sini untuk melanjutkan pemecahan masalah?

12 hari kemudian, GU10 lain menjadi tidak dapat dijangkau dan tidak akan tersambung lagi tanpa siklus daya.

Senang berbagi info apa pun yang diperlukan untuk mengatasi masalah ini.

Sama di sini, kemarin setelah 6 hari koneksi tanpa cela, saya kehilangan salah satu lampu Tradfri saya .. power on / off dan reset tidak membantu. Masih kuning di deConz tetapi tidak dapat menghubungkan atau mengontrolnya.

Sama disini. Setelah beberapa hari tanpa masalah apa pun, hari ini dua lampu GU10 Tradfri saya berhenti merespons. Saya dapat menghidupkan kembali salah satunya dengan menekan 0 di GUI, tetapi saya harus menghidupkan yang lain.
Untungnya ini sepertinya hanya terjadi untuk perangkat GU10 atm, Panel FLOALT saya belum memiliki masalah (dalam pengaturan saya, panel tersebut hanya dapat dihidupkan dengan menggunakan pemutus sirkuit).

Masalahnya terus berlanjut untuk saya juga. Saya sekarang telah mengalami 3-4 lagi lampu GU10 kehilangan koneksi serta salah satu dari Hue E27 saya dan sensor pintu Xiaomi (magnet). Beberapa lampu mulai bekerja kembali setelah siklus daya, yang lainnya tidak. Menekan 0 tidak melakukan apa-apa.

Perlu juga dicatat bahwa sensor Xiaomi mulai bekerja lagi setelah saya menyalakan siklus GU10 yang berdekatan dan tidak responsif, jadi saya kira sensor sedang merutekan cahaya itu, tetapi bukankah seharusnya itu secara otomatis mengubah rute jika ada masalah koneksi?

Masalah yang sama di sini. Kemarin saya memperbarui ke versi terbaru .59 sekarang beberapa lampu Ikea tidak responsif

Hai, bisakah Anda memberikan lebih banyak wawasan tentang total jaringan, seperti ukuran jaringan dan perangkat bertenaga listrik lainnya di sana?

Saya telah mengatur ulang jaringan rumah saya beberapa hari yang lalu, sekarang termasuk:

• 5x IKEA WS GU10 (firmware 1.2.221, kode produk LED1537R6GU10EU)
  Dengan alamat mac 0x000b57ff ..... (kelompok lama)
• 2x IKEA E27 yang dapat diredupkan (firmware 1.2.214)
• 1x lampu IKEA E14 WS (firmware 1.2.221)
• 1x IKEA repeater (firmware 2.0.019)
• 1x outlet IKEA (firmware 2.0.019)
• 1x OSRAM GU 10
• 1x OSRAM E27 bohlam warna
• 1x OSRAM steker
• 1x Hue E27 warna bohlam
• 1x Hue E27 bohlam lux yang dapat diredupkan

deCONZ 2.05.59; Firmware ConBee 0x26300500 (tetapi 0x262f0500 juga baik-baik saja).

Saya memiliki 4x FLS-PP lp tetapi ini dimatikan sekarang untuk pengujian, karena mereka bertindak sebagai repeater sinyal yang sangat kuat.

Dengan sensor dan sakelar, ukuran jaringan total adalah 55.
Semua lampu selalu menyala dan sampai sekarang tidak ada pemadaman.

Berikut adalah beberapa spesifikasi jaringan saya yang lebih rinci jika dapat membantu. Saya masih menjalankan 2.05.59 dengan 262F0500 dan kabel ekstensi ke ConBee. Seperti disebutkan di atas, setelah pertama kali memperbarui ke 2.05.59 dan siklus daya setiap perangkat bertenaga listrik dan menunggu beberapa jam, jaringan menjadi sempurna selama hampir seminggu, jadi sepertinya perlu beberapa saat hingga masalah mulai muncul. Sayangnya masalah muncul kembali dan siklus daya penuh dari semua perangkat bertenaga listrik serta reboot deCONZ tidak menyelesaikan masalah lagi. Tampaknya masalahnya juga mengembara dari satu perangkat ke perangkat lain karena terkadang lampu mungkin tidak responsif untuk sementara waktu dan kemudian teratasi sendiri.

Sebelumnya hari ini saya memiliki masalah di mana Trådfri E14 tidak responsif serta satu Hue E27. Setelah siklus daya E27, E14 hidup kembali bahkan tanpa saya menyentuhnya. Hal yang sama berlaku untuk GU10 yang tidak responsif yang tampaknya menjadi tempat perdagangan sekarang dan nanti, jadi setidaknya ada dua GU10 yang tidak responsif setiap hari tetapi tidak selalu lampu yang sama sehingga beberapa mulai bekerja sementara yang lain rusak dan sebaliknya.

Jaringan saya saat ini terdiri dari 80 perangkat berikut termasuk ConBee dan perangkat yang diberdayakan listrik 24/7.

Bertenaga listrik

| Kuantitas | Ketik | Firmware |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 dapat diredupkan | 1.2.214 |
| 4 | Spektrum putih Trådfri GU10 | 1.2.217 |
| 1 | Trådfri E14 opal dapat diredupkan | 1.2.217 |
| 1 | Stopkontak kontrol Trådfri | 1.4.020 |
| 3 | Hue E27 Putih dan Warna A19 | 1.29.0_r21169 |
| 2 | Hue E14 Suasana putih LTW012 | 1.29.0_r21169 |

Bertenaga baterai

Kuantitas | Ketik | Firmware
--------- | ------ | -----------
1 | Sakelar hidup / mati Trådfri | 1.4.018
10 | Xiaomi Aqara multisensor (suhu persegi / hum / pres) | 20161129
3 | Sensor gerak Xiaomi Aqara (gerak / lux) | 20170627
4 | Sensor air Xiaomi Aqara | 20170721
1 | Sensor gerak rona | 6.1.0.18912
11 | Sensor kontak Xiaomi Aqara | 20161128
8 | Sensor asap Xiaomi / Honeywell | T / A

Minggu lalu deconz tampaknya berjalan baik-baik saja, tetapi kemarin saya memiliki bohlam IKEA lain (spektrum putih) yang kehilangan koneksi ke deconz. Bahkan mematikan dan menyalakannya lagi tidak membantu. Harus memulai ulang deconz agar berfungsi lagi entah bagaimana.

Saya memiliki jaringan dengan sebagian besar bohlam IKEA, outlet Heiman, dan beberapa sensor Xiaomi.

Beberapa spesifikasi jaringan zigbee saya:

Firmware Conbee 262F0500 dengan kabel ekstensi pada NUC.
deCONZ 2.05.55 di Docker, jadi hal pertama yang harus saya lakukan adalah mengupgrade ke 2.05.59.

Didukung (24/7)

| Kuantitas | Ketik | Firmware |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 putih | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 putih | 1.2.214 |
| 21x | Tradfri GU10 dapat diredupkan | 1.2.214 |
| 3x | Osram Smart + socket | 1.04.12 |

Bertenaga baterai

| Kuantitas | Ketik | Firmware |
| ------------- | ------------- | ------------- |
| 3x | Sakelar Peredup Warna | 5.45.1.17846 |
| 1x | Sakelar pintar Aqara | 20180525 |
| 1x | Sakelar pintar Aqara | 20161128 |
| 1x | Sakelar nirkabel ganda Aqara | 20170411 |
| 1x | TRADFRI jarak jauh | 1.2.214 |
| 6x | Aqara multisensor | 20161129 |
| 10x | Sensor kontak Aqara | 20161128 |
| 5x | Sensor gerak Aqara | 20170627 |
| 1x | Sensor kebocoran Aqara | 20170721 |
| 1x | Sensor getaran Aqara | 20180130 |

Adakah pembaruan ini untuk versi saat ini? Saya telah menjalankan .60 selama 3 hari dan belum ada lampu yang kehilangan koneksi.

Sayangnya saya sudah kehilangan koneksi dengan bola lampu putih Tradfri E27 biasa di .60 dan firmware terbaru.

Itu berita buruk ... jika saya mengerti dengan benar, interval pemungutan suara telah diubah di 0,60 agar tidak terlalu agresif. Jajak pendapat yang agresif yang menyebabkan lampu ditutup sangat masuk akal bagi saya, sayang sekali ini sepertinya bukan solusi untuk masalah kita.

Kemarin saya mematikan daya untuk semua perangkat bertenaga listrik dan memutakhirkannya ke 2.05.60 dan 26320500 sebelum menyalakannya lagi, hanya untuk bermain aman. Lampu kemudian semua bekerja dengan baik selama sekitar 24 jam tetapi hanya beberapa menit yang lalu saya perhatikan bahwa salah satu GU10 saya berhenti merespons. Untungnya itu hidup kembali beberapa menit kemudian tanpa interaksi manual dari pihak saya jadi mungkin jaringan hanya tersumbat.

@ JBS5 Saya akan merekomendasikan untuk memperbarui 4x Tradfri E27 putih di 1.1.1.0-5.7.2.0 ke versi firmware terbaru. Jika saya ingat dengan benar, ini masih versi pertama.

@jurriaan versi mana yang memiliki lampu putih Tradfri E27?

Itu berita buruk ... jika saya mengerti dengan benar, interval pemungutan suara telah diubah di 0,60 agar tidak terlalu agresif.

Ya pada dasarnya sangat mirip dengan gateway IKEA. Sekarang satu-satunya perbedaan yang tersisa adalah kueri tabel tetangga secara berkala (yang digunakan untuk menampilkan garis jaringan mesh).

Ini dapat dimatikan dengan mengklik ikon CRE di deCONZ dan hapus centang "Router dan Koordinator".
Mungkin layak untuk dicoba.

Di Reddit ada posting yang menyebutkan bahwa gateway IKEA secara teori harus mendukung hingga 100 perangkat, tetapi itu tidak testet dengan baik. Akan menarik untuk mengetahui ukuran jaringan yang biasa diuji oleh tim IKEA.

https://www.reddit.com/r/tradfri/comments/96yiq4/google_home_losing_lamps_and_rooms/e4x1scz/?context=1

Anda mungkin memiliki 100 perangkat yang terhubung ke Gateway Anda. Ini tidak diuji dengan benar oleh kami, itulah mengapa kami tidak menjaminnya. Tetapi batas teknisnya adalah 100, dan saya telah melihat orang-orang yang memiliki 100 perangkat tanpa atau hanya memiliki masalah kecil.

Versi baru untuk Gateway akan mendukung jumlah perangkat yang sama (Resmi 50). Anda dapat menambahkan Gateway lain ke sistem Anda jika Anda ingin menggandakannya.

@ JBS5 Saya akan merekomendasikan untuk memperbarui 4x Tradfri E27 putih di 1.1.1.0-5.7.2.0 ke versi firmware terbaru. Jika saya ingat dengan benar, ini masih versi pertama.

Bola lampu E27 dengan firmware lama tidak gagal selama 6 bulan terakhir sementara yang lain ...

Menarik sekali, bagaimana dengan E27 di versi 1.2.214?

Menarik sekali, bagaimana dengan E27 di versi 1.2.214?

Mereka kehilangan koneksi hanya sekali dalam beberapa bulan terakhir.

Sudah beberapa minggu yang lalu sejak GU10 terakhir kehilangan koneksi, sementara ini saya masih menggunakan deCONZ 2.05.55 dan firmware 262F0500 di Conbee.

Saya juga punya masalah ini. Hanya simpul Ikea, (43, terutama lampu). Saya tidak memiliki pengetahuan tentang zigbee, tetapi karena saya belum melihatnya disebutkan: jaringan saya tampaknya lebih stabil dengan OTAU dinonaktifkan. Beberapa hari yang lalu saya juga mengubah preferensi jaringan menjadi kurang aman. Tidak dapat mengingat yang mana, tetapi setelah itu saya tidak kehilangan lampu.

Setelah beberapa hari tanpa masalah apa pun, beberapa GU10 menjadi tidak responsif.
Masalah lain mungkin tidak terkait tetapi lampu Osram kehilangan koneksi juga. Meskipun itu masih ditampilkan di GUI dan tampaknya menyatu, saya tidak dapat mengontrolnya lagi. Harus menghapus lampu dan membacanya, lampu tersebut diberi Lampu No lain tetapi mendapatkan kembali nama aslinya segera setelah menambahkannya. Tidak tahu apa yang terjadi di sini tetapi ini adalah perawatan yang sedikit lebih banyak daripada yang ingin saya lihat untuk pengaturan saya.

@ peer69 Apakah Anda juga hanya mencoba menyalakan lampu? Biasanya reset pabrik tidak diperlukan.
Anda menggunakan 2.05.60? Dapatkah Anda juga memberikan beberapa detail lebih lanjut tentang jaringan Anda, berapa banyak lampu dan perangkat yang bertenaga listrik?

@manup Saya menyalakan lampu. Beberapa kali. Itu dapat dikontrol selama sekitar 10 detik setelah siklus daya tetapi kemudian berubah tidak responsif lagi (lampu merah berkedip di GUI).
Sementara itu, masalah ini kembali lagi bahkan setelah reset pabrik dan juga memengaruhi lampu OSRAM lain. Untuk saat ini saya telah menyingkirkan hanya dua lampu OSRAM di jaringan saya dan menggantinya dengan lampu warna. Saya dapat menawarkan beberapa pengujian dengan lampu ORSAM tetapi saya memerlukan waktu untuk itu.

Saya menjalankan 2.05.60. Saat ini terdapat 57 node yang terhubung ke jaringan dengan 27 perangkat dialiri daya. Saya menggunakan 13 IKEA GU10, 1 IKEA FLOALT Panel, 2 IKEA E14, 3 OSRAM Smart + Plugs, 3 lampu warna E14, 5 lampu warna E27, 1 strip lampu warna.

Saya juga harus menyalakan beberapa IKEA GU10 di hari-hari terakhir yang berubah tidak responsif. Setelah power cycle semuanya kembali normal dan saya tidak melihat polanya. Saya memiliki lampu dengan beberapa GU10 dan tidak lebih dari satu GU10 menjadi tidak responsif pada saat yang sama meskipun selalu dikontrol sebagai satu kelompok.

Saat ini saya kembali ke titik awal. Sekarang saya secara teratur memiliki 2-3 lampu yang tidak merespons, tetapi beralih di antara lampu yang berbeda sehingga terkadang berfungsi dan terkadang tidak tergantung pada lampu lain yang sedang online. Masalahnya tampaknya menurun karena ketika saya secara fisik mematikan beberapa lampu dengan memutus daya ke lampu tersebut, masalah tersebut akan dipindahkan ke lampu lain.

Saya juga kehilangan beberapa sensor suhu Xiaomi serta sensor pintu dan tombol on / off IKEA tetapi mereka tidak muncul kembali sehingga mereka mungkin perlu dipasangkan kembali untuk mulai bekerja lagi.

Segalanya bekerja dengan baik segera setelah siklus daya total seperti yang saya catat sebelumnya tetapi beberapa hari kemudian lampu mulai tidak responsif lagi dan sudah seperti ini selama beberapa minggu sekarang. Kembali ketika itu terjadi pertama kali seorang tamu secara tidak sengaja mencabut E14 selama beberapa jam jadi saya tidak yakin apakah itu benar-benar tidak terkait atau jika gangguan tak terduga dari zigbee mesh menyebabkan perutean menjadi gila. Mengingat bahwa saya ternyata bukan satu-satunya dengan masalah ini, saya pikir itu mungkin hanya kebetulan.

Saya sangat menyukai konsep memiliki semua perangkat zigbee saya dalam satu mesh tetapi saya hampir pada titik di mana saya mem-boot gateway Hue dan Xiaomi yang lama dan meletakkan ConBee di laci, yang benar-benar tidak ingin saya lakukan karena beberapa alasan lain. Adakah yang punya tip untuk pemecahan masalah lebih lanjut yang dapat membantu saya mengidentifikasi dengan tepat apa yang terjadi dan bagaimana mengatasinya?

Salah satu tempat IKEA GU10 saya sekarang juga tidak responsif.

Di sniffer saya melihat itu masih agak "hidup" dan mengirim pesan Status Tautan NWK, tetapi jelas mengira itu sendirian di jaringan (Jumlah Status Tautan: 0).

Itu tidak menanggapi perintah unicast tetapi mengirimkan laporan atribut ZCL secara berkala dari modelid.

Mengendus sejak ~ 2 jam, tidak yakin kapan menjadi tidak responsif dan jika terkait tetapi nomor urut laporan ZCL rendah:

Saya akan melakukan beberapa tes lagi dan tidak akan menyalakannya untuk sementara waktu.

Soket daya Tradri saya bertindak sangat aneh hari ini juga dan berjalan dalam lingkaran reboot, belum pernah yang ini sebelumnya.

Baru saja dicatat IKEA GU10 kedua juga merupakan led berjalan, gejala yang sama seperti yang lainnya.

Kedua perangkat tidak merespons permintaan alamat unicast, groupcast atau ZCP nwk (menekan 0).
Mereka mengirim perintah Status Tautan NWK kosong.

GU10 kedua juga mengirimkan permintaan ZCL OTA Query Next Image.

Sepertinya responnya tidak datang.

Hanya tebakan liar tapi saya pikir lampu di buffer diblokir dan itulah mengapa tidak ada yang diterima dan diproses. Buffer luar masih berfungsi, oleh karena itu firmware dapat mengirim laporan dan kueri ota.

Akan lebih baik jika mereka menerapkan sesuatu seperti pemeriksaan kesehatan sederhana sehingga firmware dapat melakukan boot ulang setelah beberapa saat, jika lapisan mac berfungsi (perintah diterima) tetapi lapisan nwk dan aps tetap diam.

Saya juga mengalami masalah ini, bahkan setelah memutakhirkan ke 2.05.59. Hari ini adalah salah satu dari tiga lampu luar ruang saya yang "mati".
Lampu Tradfri-nya bertiga.

keluar topik. Bagaimana Anda menemukan cahaya Anda dalam semua ini? Saya memiliki pengaturan serupa dan saya seperti ... tidak ada waktu untuk ini

dengan maksud saya yang serupa + - 50 perangkat

+ - 50 cukup baik. Salah satu jaringan uji kami memiliki +180 perangkat dengan deCONZ di Raspberry Pi 1, itu menyenangkan :)

Kami memiliki beberapa rencana untuk menambahkan filter / penyortiran yang lebih baik ke deCONZ untuk mempermudah pencarian perangkat, saat ini sangat tidak praktis pada jumlah perangkat tertentu.

Lampunya masih macet.

Satu pengamatan menarik: Saya mematikan induk dari sensor gerak Philips Hue (Hue Lux) sehingga perlu mencari induk baru. Sensor sekarang mencoba untuk bergabung kembali melalui salah satu lampu IKEA GU10 yang macet.

Lampu merespons dengan perintah Leave (with Rejoin). Jadi itu memproses permintaan bergabung kembali!

Sayangnya sensor gerak Hue keras kepala dan mencoba untuk bergabung kembali ke lampu GU10 yang macet selamanya, alih-alih mencari orang tua yang lebih baik.

Namun bagian yang menarik di sini adalah bahwa lampu IKEA yang macet merespons permintaan bergabung kembali, mungkin juga memproses permintaan Cuti NWK, yang bisa menjadi dasar solusi untuk membuat lampu kembali berfungsi.

Koreksi, sensor gerak Hue tidak terlalu keras kepala; setelah beberapa menit sensor memilih orang tua lain yang berfungsi (baik).

Namun bagian yang menarik di sini adalah bahwa lampu IKEA yang macet merespons permintaan bergabung kembali, mungkin juga memproses permintaan Cuti NWK, yang bisa menjadi dasar solusi untuk membuat lampu kembali berfungsi.

Saya memang menguji ini, tetapi sayangnya itu tidak berhasil. Saat lampu dalam keadaan macet, mereka tidak akan memproses Cuti NWK dengan permintaan bergabung kembali.

Saat ini saya hanya dapat menyimpulkan bahwa IKEA perlu memperbaiki masalah akar dari lampu yang macet atau menerapkan semacam pengawas + pemeriksaan kesehatan untuk lapisan NWK / APS dari firmware.

Masih belum diketahui apa sebenarnya yang menyebabkan cahaya masuk ke status ini - badai siaran, perintah tertentu, masalah perutean ...?

Saya akan meneruskan temuan saya dan log pelacak ke IKEA semoga mereka dapat menggunakannya untuk melacak masalah tersebut.

Jadi @manup , apa praktik terbaik untuk bergabung kembali dengan lampu IKEA yang macet?

Bagi saya siklus daya cahaya jelas bekerja paling baik

@manup Saya rasa jika Anda tidak tahu bagaimana membuat pasien lebih baik, Anda harus mencoba memperburuk keadaan. Jadi, bombardir cahaya dengan kemungkinan penyebab penguncian dan lihat apa yang terjadi.
Juga, bukankah lampu ini didasarkan pada tumpukan Ember? Mungkin ada tim atau forum dukungan yang bisa menjelaskan (permainan kata-kata).

Kepada IKEA, apakah mereka responsif terhadap permintaan dukungan seperti ini? Atau haruskah kita bekerja sama untuk mendapatkan perhatian?

Bagi saya siklus daya cahaya jelas bekerja paling baik

Tidak terlalu banyak untukku ...
Restart Conbee adalah satu-satunya hal yang memperbaikinya untuk sementara.
Dan kemudian sama, atau lebih sering, lampu IKEA lain macet setelah beberapa saat ...
Selalu hanya satu lampu! Aneh sekali ... Dan menjengkelkan ...: /

@manup Luar biasa! Terima kasih telah melihat ini!

Saya juga telah meneruskan utas ini ke tim IKEA Tradfri melalui Reddit. Baru saja mendapat tanggapan dari mereka yang mengatakan bahwa mereka telah meneruskan informasi tersebut. Semoga mereka dapat menggunakan ini untuk meningkatkan firmware mereka atau menemukan solusi untuk masalah ini :)

Sepertinya ada firmware baru untuk gateway tradfri yang akan datang di hari-hari mendatang yang secara khusus menargetkan dukungan HomeKit. Mungkin ada firmware baru untuk bohlam juga.

@ peer69 Ini adalah rilis firmware terbaru:

[
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/190579-ncp572b444.ebl.ota.ota.signed",
    "fw_build_version": 444,
    "fw_file_version_LSB": 444,
    "fw_file_version_MSB": 5720,
    "fw_filesize": 166270,
    "fw_hotfix_version": 2,
    "fw_image_type": 2,
    "fw_major_version": 5,
    "fw_manufacturer_id": 4476,
    "fw_minor_version": 7,
    "fw_type": 1
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 204222,
    "fw_image_type": 4353,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed",
    "fw_file_version_LSB": 1571,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 182078,
    "fw_image_type": 4549,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035514-TRADFRI-bulb-ws-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8705,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10035534-TRADFRI-bulb-ws-gu10-1.2.221.ota.ota.signed",
    "fw_file_version_LSB": 5490,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 172734,
    "fw_image_type": 8707,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed",
    "fw_file_version_LSB": 9763,
    "fw_file_version_MSB": 8194,
    "fw_filesize": 209790,
    "fw_image_type": 16900,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/1004764-TRADFRI-bulb-cws-1.3.009.ota.ota.signed",
    "fw_file_version_LSB": 38258,
    "fw_file_version_MSB": 4864,
    "fw_filesize": 178366,
    "fw_image_type": 10241,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159495-TRADFRI-transformer-1.2.245.ota.ota.signed",
    "fw_file_version_LSB": 21874,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 181118,
    "fw_image_type": 16641,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159695-TRADFRI-bulb-ws-1000lm-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 8706,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159696-TRADFRI-bulb-w-1000lm-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 168318,
    "fw_image_type": 8449,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159697-TRADFRI-driver-hp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16898,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159698-TRADFRI-driver-lp-1.2.217.ota.ota.signed",
    "fw_file_version_LSB": 30066,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 173246,
    "fw_image_type": 16897,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed",
    "fw_file_version_LSB": 13683,
    "fw_file_version_MSB": 4642,
    "fw_filesize": 159806,
    "fw_image_type": 4545,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159700-TRADFRI-motion-sensor-1.2.214.ota.ota.signed",
    "fw_file_version_LSB": 17778,
    "fw_file_version_MSB": 4641,
    "fw_filesize": 157822,
    "fw_image_type": 4548,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/159701-TRADFRI-wireless-dimmer-1.2.248.ota.ota.signed",
    "fw_file_version_LSB": 34162,
    "fw_file_version_MSB": 4644,
    "fw_filesize": 172926,
    "fw_image_type": 4546,
    "fw_manufacturer_id": 4476,
    "fw_type": 2
  },
  {
    "fw_binary_url": "http://fw.ota.homesmart.ikea.net/Tradfri_OTA_release_signed_2019_04_05_111559/bin/10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed",
    "fw_filesize": 698748,
    "fw_hotfix_version": 25,
    "fw_major_version": 1,
    "fw_minor_version": 8,
    "fw_req_hotfix_version": 26,
    "fw_req_major_version": 9,
    "fw_req_minor_version": 9,
    "fw_type": 0,
    "fw_update_prio": 5,
    "fw_weblink_relnote": "https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotesltd.html"
  }
]

Hanya pembaruan yang:

• 10005777-4.1-TRADFRI-control-outlet-2.0.022.ota.ota.signed
• 10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
• 10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed
• 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI-remote-control-1.2.223.ota.ota.signed

Jadi kebanyakan difokuskan pada outlet / gateway.

Hari ini salah satu bohlam rona saya menunjukkan masalah yang sama persis. Harus menyalakannya agar menjadi responsif lagi.

Ada berita tentang siapa yang memperbarui deCONZ dan firmware Conbee?

Sampai saat ini 1 atau 2 GU10 akan offline dalam 2-4 minggu. Agak sporadis, tetapi powercycling itu mengganggu karena saya tidak memiliki powerwitch di beberapa tempat.

Baru saja memperbarui firmware ke 0x26330500 jadi mari kita lihat.

Sayangnya, hari ini salah satu GU10 saya tidak tersedia ..
Menggunakan deCONZ 2.05.64 dengan firmware 26330500 pada Conbee.

Saya pikir telah disimpulkan bahwa ini adalah masalah FW bohlam, karena kami melihat masalah yang persis sama di Philips HUE Bridge. Saya perhatikan di Aplikasi Trådfri, bagian Catatan rilis, penyebutan bohlam CT v2. Mungkin bahkan bohlam terkait HW?

Saya tidak memiliki masalah dengan 2.05.65 sejauh ini.

Sama, saya belum pernah menghadapi masalah ini sejak berminggu-minggu

Saya memiliki hal yang sama dengan versi deconz terbaru sampai sekarang .. mengganti beberapa lampu beberapa hari yang lalu. Saya hanya perlu mematikannya secara manual dan menyalakan kembali salah satu lampu ini agar menjadi responsif lagi.

Beberapa GU10 dan bohlam E27 tidak aktif beberapa hari yang lalu. Hanya power cycle yang membuat mereka kembali online.

Mungkin relevan: Ini terjadi selama liburan saya ketika tidak ada lampu yang dinyalakan selama satu atau 10 hari.

Firmware 26330500 dengan deCONZ 2.05.64

Bagaimana dengan masalah ini bagi mereka yang mengatakan bahwa mereka tidak mengalami masalah selama beberapa minggu beberapa minggu yang lalu?

Saya masih memiliki masalah ini. Terkadang tidak ada yang offline, dan tiba-tiba GU10 offline, dan beberapa hari kemudian yang lain ..

Sejauh yang saya bisa lihat, masih belum ada firmware baru yang tersedia untuk Tradfri GU10.

Saya masih memiliki masalah ini juga. Bagi saya, perintah grup masih berfungsi sebagian besar waktu bahkan jika saya tidak dapat mengontrol cahaya sebagai satu perangkat, saya menggunakan ini di skrip sakelar dinding saya sebagai solusi.

Perintah grup juga berfungsi untuk saya, tetapi hanya beberapa kali. Setelah itu, lampu tetap menyala atau mati dan tidak merespons lagi. Bahkan saat menggunakan Peredup Warna yang terikat.

Sama untuk ku. Saya mendapat kesan bahwa masalahnya tertunda, lebih dari sekadar terselesaikan.
Saya juga telah mengatasi masalah ini dengan menggunakan perintah grup.

Saya benar-benar memperhatikan bahwa beberapa lampu tampak jauh lebih rentan terhadap masalah ini. Apakah Anda mengenali ini?

@djwlindenaar Sulit untuk mengatakannya, tetapi saya kira setengah dari 25+ GU10 yang saya miliki tidak pernah mengalami masalah ini dan saya yakin beberapa mengalami masalah beberapa kali.

@ peer69 @djwlindenaar Apakah perintah grup tetap bekerja? Hari ini GU10 offline dan bahkan tidak menanggapi perintah grup untuk pertama kalinya (perintah grup dari deCONZ dan Hue Dimmer yang diikat).

Perintah grup biasanya tetap berfungsi, tetapi saya ingat suatu kesempatan di mana saya harus menyalakan lampu. Juga saya ingat suatu saat ketika tidak merespon untuk beberapa saat dan tanpa tindakan apapun mulai merespon lagi nanti.

Semua waktu lebih cepat dari kemudian juga perintah kelompok gagal dan harus menyalakan lampu.

Apa maksudmu dengan beberapa saat? Beberapa jam atau beberapa hari?

Tidak yakin, mungkin berjam-jam, mungkin sehari. Saya baru saja melupakannya untuk beberapa waktu, tetapi perhatikan itu akan kembali pada kesempatan berikutnya saya menggunakan lampu.
Itu terkait dengan aturan yang dipicu oleh gerakan, jadi ...

Menunggu sekitar 2 hari ketika GU10 offline awal minggu ini, tapi tidak juga kembali. Diperlukan siklus listrik, GU10 sama sekali tidak hangat.

Sekarang, saya memiliki satu lampu GU10 yang mati, tetapi tidak kembali online setelah siklus daya. Juga menekan 0 di VNC tidak menyelesaikan masalah ini.

Juga perintah grup atau Switch Hue DImmer yang diikat tidak dapat lagi menghidupkan / mematikan lampu.

Mulai tadi malam di lorong saya ada 4 lampu ikea yang padam setelah x waktu oleh timer (Home Assistant) sekarang 1 dari 4 lampu terus menyala dan tidak bisa dimatikan oleh Home Assistant / Deconz. Ini offline menurut Deconz dan belum bergabung kembali dalam 7 jam. Akan mencoba untuk menyalakan sepeda dan melihat apakah itu berhasil.

Lampu tidak berfungsi: Bohlam TRÅDFRI E27 opal 1000lm dengan versi 1.2.214
Lampu berfungsi: Bohlam TRÅDFRI E27 opal 1000lm dengan versi 1.2.214
Firmware: 26330500
Deconz: V2_05_69

Saya yakin ada masalah perangkat keras dengan bohlam spektrum putih Ikea Trafri GU10. Juga dalam pengaturan saya (gateway Ikea terhubung melalui api lokal ke Asisten Rumah) setidaknya setengah dari 17 bohlam saya offline setiap beberapa hari. Satu-satunya solusi adalah menyalakan siklus bohlam.

Ini mungkin alasan Ikea meluncurkan versi perangkat keras baru yang menjalankan versi firmware yang berbeda (2. * bukan 1. *).

Sejauh yang saya tahu, tidak ada pembaruan firmware baru untuk versi lama, ini mungkin pertanda ada sesuatu yang terkait dengan perangkat keras.

Tidak yakin apa garansinya, tetapi saya berencana untuk meminta penggantian dengan versi baru.

Saya yakin ada masalah perangkat keras dengan bohlam spektrum putih Ikea Trafri GU10. Juga dalam pengaturan saya (gateway Ikea terhubung melalui api lokal ke Asisten Rumah) setidaknya setengah dari 17 bohlam saya offline setiap beberapa hari. Satu-satunya solusi adalah menyalakan siklus bohlam.

Ini mungkin alasan Ikea meluncurkan versi perangkat keras baru yang menjalankan versi firmware yang berbeda (2. * bukan 1. *).

Sejauh yang saya tahu, tidak ada pembaruan firmware baru untuk versi lama, ini mungkin pertanda ada sesuatu yang terkait dengan perangkat keras.

Tidak yakin apa garansinya, tetapi saya berencana untuk meminta penggantian dengan versi baru.

Tidak yakin apakah ini hanya terkait dengan satu jenis, karena saya menggunakan GU10 putih hangat, bukan spektrum putih.

Memiliki masalah yang sama dengan dua IKEA GU 10 WW hari ini. Bersepeda daya tidak membantu. Itu memang membantu untuk menyalakan kembali dan memulai ulang deconz. Mungkin beberapa masalah meja tetangga? Kedua lampu tersebut berada dalam kelompok dua dan selalu dikontrol sebagai satu kelompok.

Sungguh kebetulan bahwa ini terjadi pada beberapa instalasi hari ini ... Atau sesuatu yang lain sedang terjadi?

@ peer69

Versi deCONZ dan firmware conbee mana yang Anda gunakan?

Saya menggunakan:
deCONZ V2_05_66
Firmware 26330500

Firmware yang sama di sini. deCONZ Versi 2.05.69.

Dan warna putih hangat Tradfri GU10 lainnya kehilangan koneksinya ..

Ada file firmware yang lebih baru di cabang pengujian, tetapi saya tidak tahu apakah ini memperbaiki masalah atau menyebabkan masalah baru bahkan mungkin merusak.

http://fw.test.ota.homesmart.ikea.net/feed/version_info.json

10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed 10038562-TRADFRI-sy5882-bulb-ws-2.0.023.ota.ota.signed 10035514-TRADFRI-bulb-ws-2.3.007.ota.ota.signed 10035534-TRADFRI-bulb-ws-gu10-2.3.007.ota.ota.signed 159695-TRADFRI-bulb-ws-1000lm-2.3.007.ota.ota.signed

@ Manup Ini untuk lampu GU10 spektrum putih dan, saya rasa, untuk versi baru? https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Mungkin 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed dapat digunakan untuk mereka. Saya akan mengujinya di salah satu lampu IKEA E27 saya yang dapat diredupkan, semoga kasus terburuk adalah crash tetapi tidak terbakar :)

Saya sudah mencoba untuk menetapkan file secara manual tetapi bohlam tidak terlihat untuk mengambil pembaruan (tidak mulai).

Hanya 'aku juga' dalam hal ini. Seluruh rumah saya adalah Tradfri dan setelah me-reboot server saya hari ini, saya kehilangan seluruh jaringan untuk ketiga kalinya dalam beberapa hari. Power-cycling tidak membuat perbedaan. Saya hanya punya Tradfri di rumah saya jadi saya tidak punya hal lain untuk dibandingkan. Saya memiliki campuran e27 white, e27 color dan GU10's. Satu-satunya resolusi yang saya temukan adalah menyetel ulang bohlam dengan keras dan memulai semuanya dari awal - sayangnya ini tidak berkelanjutan.

Firmware Conbee: 264A0700
Firmware ringan: 1.2.214

Senang membantu dengan diagnosis apa pun tetapi saya perlu mengembalikan sebagian besar rumah saya ke gerbang Tradfri sehingga keluarga saya dapat menyalakan dan mematikan lampu. Saya akan meninggalkan beberapa lampu tersedia.

Saya baru menyadari, mungkin, tambahan yang menarik untuk masalah ini.

Beberapa ruangan dilengkapi dengan beberapa spot Tradfri GU10 dan sebagian besar ruangan dengan Hue Dimmer Switch, dengan pengikatan langsung ke GU10 di ruangan yang dibuat dengan menambahkannya ke grup Hue Dimmer Switch di aplikasi Phoscon.

• Hanya GU10 dengan pengikatan langsung dengan Hue Dimmer Switch yang terkadang offline dan memerlukan siklus daya untuk kembali online.
• GU10 tanpa pengikatan langsung dengan Hue Dimmer Switch tidak akan offline.

Sepertinya tidak demikian bagi saya. Hingga saat ini hanya Hue Bulbs yang tampaknya cukup tangguh. Semua jenis perangkat IKEA (GU10, E14, Panel FLOALT) dan perangkat Osram (Bulbs, Lighstrips dan Garden Poles) yang saya miliki gagal. Terutama perangkat Osram gagal total, siklus daya tidak melakukan apa pun. Mereka harus dilepas dan diperbaiki yang merupakan rasa sakit untuk perangkat ini.

Saya menghabiskan beberapa hari memikirkan untuk mengganti semua perangkat zigbee saya dengan perangkat untuk instalasi KNX yang terlalu mahal setelah beberapa perangkat gagal dan migrasi ke tongkat Conbee II juga gagal mungkin karena zll-db yang agak rusak. Saya kemudian mengambil pendekatan radikal untuk mengatur semuanya dari awal. Saya mengatur ulang gateway dan memperbaiki semua perangkat. Untuk perangkat IKEA, ini jauh lebih mudah daripada sebelumnya. Di masa lalu saya harus memindahkannya ke dekat gateway, mengatur ulang beberapa kali, menggunakan tautan sentuh untuk membuat mereka merespons - kali ini tidak ada. Saya baru saja menyetel ulang bohlam dan memasangkannya tanpa masalah. Namun, melakukan ini untuk 70 perangkat itu menyakitkan dan beberapa sensor xiaomi membuatnya sedikit lebih sulit daripada perangkat ikea. Tapi itu membuat saya sudah berpikir saya mungkin memiliki jaringan yang lebih stabil sekarang. Namun tidak ada yang gagal tetapi saya akan memberi tahu Anda jika gagal.

Sudah lama sejak saya memperbarui raspbee saya, versi lama saya bermasalah dengan membaca suhu lampu, jadi saya memutuskan untuk memperbarui ke firmware terbaru dan deCONZ terbaru. Hanya punya 2 lampu (OSRAM 73674). 1 lampu (mungkin acak) kehilangan koneksi setelah beberapa menit dengan deCONZ terbaru dan saya harus mematikan dan menghidupkan kembali secara manual. Satu-satunya versi yang dapat saya temukan yang dapat membaca suhu dan tidak kehilangan cahaya adalah deconz-2.04.40-qt5.deb yang sangat tua, tetapi berfungsi untuk penggunaan dasar saya.

Terjadi lebih banyak akhir-akhir ini untuk saya juga dengan IKEA GU10 satu warna. Agak sakit di pantat. Namun simpul tidak menjadi merah untuk saya, hanya berwarna abu-abu. Mereka akan bereaksi terhadap penekanan tombol jarak jauh, tetapi tidak melalui Phoscon atau HA.

Apakah deCONZ masih memperbarui status lampu saat Anda mengontrolnya dari remote?

Ini biasanya terjadi ketika deCONZ kehilangan rute ke lampu. Lampu masih dalam jaringan, dapat mencapai gateway, dan menerima siaran. Namun, gateway tidak dapat menjangkau cahaya melalui unicast. Sebagai solusinya, Anda mungkin menggunakan perintah /groups alih-alih /lights , jadi deCONZ mengirim siaran sebagai gantinya.

Saya masih mengalami masalah yang sama sesekali (~ sekali seminggu) dengan Xiaomi Curtain Controller saya (yang merupakan router ZigBee). _Pengumuman Perangkat_ setelah perputaran daya perangkat menyebabkan deCONZ mempelajari kembali rute tersebut.

Masalah perutean ini diperkenalkan dengan dukungan untuk penemuan perutean yang digunakan oleh lampu Trådfri, jadi 2.04.40 terdengar benar.

@ ebaauw Saat lampu tidak tersedia, perintah grup berfungsi untuk saya tetapi hanya untuk waktu terbatas. Setelah itu, lampu terus menyala atau mati dan tidak merespons perintah grup lagi. Menggunakan Hue Dimmer Switch yang diikat (penjilidan dibuat dengan menambahkan lampu ke grup yang dibuat secara default saat Hue Dimmer Switch dipasangkan di aplikasi Phoscon).

Apakah deCONZ masih memperbarui status lampu saat Anda mengontrolnya dari remote?

Ini biasanya terjadi ketika deCONZ kehilangan rute ke lampu. Lampu masih dalam jaringan, dapat mencapai gateway, dan menerima siaran. Namun, gateway tidak dapat menjangkau cahaya melalui unicast. Sebagai solusinya, Anda mungkin menggunakan perintah /groups alih-alih /lights , jadi deCONZ mengirim siaran sebagai gantinya.

Saya akan memeriksa saran ini lain kali. Tapi ya mereka biasanya mengembalikannya. Saya mematikan listrik selama beberapa menit. Btw saya menggunakan remote "keping hoki" IKEA.

Saya masih mengalami masalah yang sama sesekali (~ sekali seminggu) dengan Xiaomi Curtain Controller saya (yang merupakan router ZigBee). _Pengumuman Perangkat_ setelah perputaran daya perangkat menyebabkan deCONZ mempelajari kembali rute tersebut.

Masalah perutean ini diperkenalkan dengan dukungan untuk penemuan perutean yang digunakan oleh lampu Trådfri, jadi 2.04.40 terdengar benar.

Hmm, aku tidak melakukannya, sudah lama ini buruk bagiku. Saya terus memperbaruinya terus menerus.

Hmm, aku tidak melakukannya, sudah lama ini buruk bagiku.

Ini masalah intermiten. Saya belum dapat mereproduksinya sesuka hati, lihat # 849. Faktanya, semua aturan saya untuk mengontrol lampu didasarkan pada tindakan /groups , jadi saya tidak pernah memperhatikan masalah ini sebelumnya, sampai saya mendapatkan pengontrol tirai.

Saat lampu tidak tersedia, perintah grup berfungsi untuk saya tetapi hanya untuk waktu terbatas. Setelah itu, lampu terus menyala atau mati dan tidak merespons perintah grup lagi.

Saya akan berteori bahwa cahaya memutuskan untuk meninggalkan jaringan, ketika tidak menerima ACK dari gateway untuk laporan atributnya untuk waktu yang lama.

Saya akan berteori bahwa cahaya memutuskan untuk meninggalkan jaringan, ketika tidak menerima ACK dari gateway untuk laporan atributnya untuk waktu yang lama.

Bagi saya, ini terjadi juga dengan lampu yang dinyalakan atau hanya beberapa menit / jam sebelumnya.

Seperti yang diposting beberapa balasan di atas, sebagian besar lampu GU10 saya terikat ke Hue Dimmer Switch (3-8 di ruangan dengan Hue Dimmer Switch sendiri). Beberapa tidak, dan mereka sudah online sejak berbulan-bulan. Tidak pernah salah satu dari mereka tidak tersedia. Kebetulan atau tidak .. Apa pendapatmu tentang @ebaauw ini?

sebagian besar lampu GU10 saya terikat ke Hue Dimmer Switch

Sepertinya tidak mungkin. Apakah Anda membuat pengikatan di panel _Bind Dropbox_ di deCONZ GUI dari sakelar peredup ke lampu?

Perhatikan bahwa "mengikat" dalam istilah ZigBee berarti: membuat entri di tabel pengikat perangkat ke alamat ZigBee tujuan pengiriman perintah dari cluster terikat. Saya pikir cluster (klien!) _OnOff_ dan _Level Control_ dari sakelar dimmer Anda terikat ke grup (oleh plugin deCONZ REST API). Grup ini terdaftar dalam sumber daya ZHASwitch di bawah config.group . Selanjutnya, lampu telah ditambahkan ke grup ini. Grup ZigBee lebih seperti alamat multicast, jadi mungkin lebih tepat untuk mengatakan lampu telah berlangganan pesan ke grup ini.

Secara teori, saya kira, firmware ringan mungkin memiliki bug, menyebabkannya hang saat memproses perintah yang diterima melalui grup. Saya tidak berpikir ini mungkin terjadi. Saya akan melihat seberapa dekat (berapa banyak lompatan melalui jaringan ZigBee) lampu ke RaspBee / ConBee dan / atau apakah semua lampu memiliki revisi perangkat keras dan firmware yang sama. IKEA tampaknya meluncurkan versi ZigBee 3.0 (ZHA) baru dari semua perangkat mereka.

sebagian besar lampu GU10 saya terikat ke Hue Dimmer Switch

Sepertinya tidak mungkin. Apakah Anda membuat pengikatan di panel _Bind Dropbox_ di deCONZ GUI dari sakelar peredup ke lampu?

Perhatikan bahwa "mengikat" dalam istilah ZigBee berarti: membuat entri di tabel pengikat perangkat ke alamat ZigBee tujuan pengiriman perintah dari cluster terikat. Saya pikir cluster (klien!) _OnOff_ dan _Level Control_ dari sakelar dimmer Anda terikat ke grup (oleh plugin deCONZ REST API). Grup ini terdaftar dalam sumber daya ZHASwitch di bawah config.group . Selanjutnya, lampu telah ditambahkan ke grup ini. Grup ZigBee lebih seperti alamat multicast, jadi mungkin lebih tepat untuk mengatakan lampu telah berlangganan pesan ke grup ini.

Tidak, saya tidak membuat pengikatan di panel de _Bind Dropbox_ di deCONZ GUI.

Apakah maksud Anda menambahkan lampu ke grup ini di aplikasi Phoscon tidak membuat pengikatan antara remote dan lampu? Saya berasumsi demikian, karena mengganti lampu tambahan dengan Hue Dimmer Switch yang sesuai juga dimungkinkan ketika kontainer buruh pelabuhan deCONZ saya atau seluruh NUC sedang offline.

Oke, saya memiliki bulp yang tidak responsif sekarang. Itu berwarna abu-abu di deCONZ dan Phoscon bth.

Itu bereaksi terhadap perintah jarak jauh dan juga ketika saya memindahkan slider dalam mode "grup" di Phoscon,

Apakah deCONZ masih memperbarui status lampu saat Anda mengontrolnya dari remote?

Tidak pada awalnya karena berwarna abu-abu.

Saya kemudian mencoba dengan "reset node yang dipilih" di deCONZ, dan kemudian selama beberapa menit tidak lagi menjadi abu-abu meskipun tidak ada lagi tombol radio cluster di deCONZ.

Masih hanya menanggapi perintah jarak jauh dan grup, tetapi sekarang status lampu diperbarui.

Setelah beberapa saat, warnanya menjadi abu-abu lagi di Phoscon.

Saya kemudian mencoba memutus daya selama beberapa menit. Tidak membantu.

Situasi yang menarik terjadi malam ini:

Salah satu lampu GU10 putih hangat Tradfri sedang offline lagi sejak beberapa jam. Hue Dimmer Switch yang diikat ke 8 GU10 termasuk yang sedang offline sekarang, menyalakan / mematikan, menurut deconz, GU10 offline. Cukup aneh, hanya yang itu.
GU10 lainnya tidak merespons Hue Dimmer Switch yang diikat.

Mengalihkan grup dengan API lainnya akan menyalakan / mematikan semua lampu, termasuk GU10 offline.

Ketika GU10 offline sebelumnya, Hue Dimmer Switch yang diikat mengaktifkan / menonaktifkan semua lampu dalam grup, termasuk, menurut tot deconz, GU10 offline (cepat atau lambat, menurut deconz, GU10 offline juga berhenti mendengarkan perintah grup antara).

Mungkinkah ini berguna?

\ Edit: 'Nama' GU10 offline ini di deCONZ melalui VNC kosong.

Saat mengisi ini lagi, itu tidak diatur (tidak pernah melakukan ini di sini, biasanya di Aplikasi Phoscon):

Masih kuning juga:

Menekan '0' atau 'Reset node yang dipilih' tidak membuat GU10 kembali online.

Sunting 2 : Sekitar 24 jam setelah GU10 offline, GU10 tidak lagi merespons ke Hue Dimmer Switch yang diikat seperti yang dijelaskan sebelumnya. Tidak ada lampu GU10 di grup yang tidak merespons sekarang. Node di deCONZ GUI masih kuning tapi namanya abu-abu.
Setelah menyalakan lampu GU10 offline, semua 8 lampu dalam grup, termasuk yang offline, merespons lagi Hue Dimmer Switch yang diikat.

@manup Perilaku / situasi ini cukup berbeda dari sebelumnya, mungkinkah ini dapat membantu untuk menemukan penyebabnya?

Saya baru menyadari, mungkin, tambahan yang menarik untuk masalah ini.

Beberapa ruangan dilengkapi dengan beberapa spot Tradfri GU10 dan sebagian besar ruangan dengan Hue Dimmer Switch, dengan pengikatan langsung ke GU10 di ruangan yang dibuat dengan menambahkannya ke grup Hue Dimmer Switch di aplikasi Phoscon.

• Hanya GU10 dengan pengikatan langsung dengan Hue Dimmer Switch yang terkadang offline dan memerlukan siklus daya untuk kembali online.
• GU10 tanpa pengikatan langsung dengan Hue Dimmer Switch tidak akan offline.

Sayangnya, salah satu warmwhite Tradfri GU10 saya tanpa Hue Dimmer Switch yang terikat sedang offline sejak kemarin ..

Masih bertanya-tanya mengapa beberapa tempat GU10 (warmwhite yang sama) _never_ offline.
\ Edit : Juga GU10 yang online selama berbulan-bulan, offline sejak kemarin.

Membeli Tradfri Hub akhir pekan lalu dan memasangkan semua tempat GU10 dari satu ruangan ke sana. Mari kita lihat apa yang terjadi beberapa minggu mendatang ..

Lampu acak di sistem saya mulai tidak responsif setelah saya menambahkan empat sakelar stopkontak on / off IKEA ke sistem saya (untuk lampu jendela xmas) ... Outletnya tersebar di seluruh rumah saya. Setidaknya satu dari lampu saya di sistem saya perlu siklus daya per hari.

Dapatkah saya memberikan jenis log atau info apa pun untuk memudahkan pemecahan masalah?

@tubalainen Apa yang Anda maksud dengan non-responsif? Apakah mereka menjadi responsif sendiri apakah mereka membutuhkan power cycle?

@tubalainen Apa yang Anda maksud dengan non-responsif? Apakah mereka menjadi responsif sendiri apakah mereka membutuhkan power cycle?

Mereka terdaftar sebagai "online" (tidak diwarnai abu-abu) dan merupakan bagian dari mesh menurut gambar saya tetapi ketika beralih di Home Assistant (atau melalui phoscon) tidak ada yang terjadi. Untuk membuatnya berfungsi kembali, saya perlu menyalakan sepeda.

Apakah ada kemajuan dalam hal ini? Agak konyol dengan lampu GU10 saya yang menjadi abu-abu :(

Saya rasa saya melihat seseorang menyebutkan pengontrol tirai atau tombol on / off. Sebenarnya saya sadar bahwa masalah menjadi jauh lebih buruk saat saya mendapatkan tirai FYRTUR. Ini juga tombol ikea pertama yang saya tambahkan ke jaringan ... Saya tidak ...

Saya tidak memiliki sakelar dinding on / off Tradfri atau tirai IKEA di sini dan saya mengalami masalah.

Saya mengalami masalah ini selama musim panas. GU10 saya akan putus sepanjang waktu. Saya memutakhirkan semua GU10 saya ke perangkat lunak "uji" terbaru dan telah berjalan tanpa masalah selama hampir dua bulan.

Akhir pekan lalu saya menambahkan beberapa bohlam E27 baru dan sekarang beberapa GU10 saya putus terus-menerus.

Saya mengalami masalah ini selama musim panas. GU10 saya akan putus sepanjang waktu. Saya memutakhirkan semua GU10 saya ke perangkat lunak "uji" terbaru dan telah berjalan tanpa masalah selama hampir dua bulan.

Akhir pekan lalu saya menambahkan beberapa bohlam E27 baru dan sekarang beberapa GU10 saya putus terus-menerus.

Bohlam GU10 mana yang Anda miliki dan firmware mana yang Anda instal?

Membeli Tradfri Hub akhir pekan lalu dan memasangkan semua tempat GU10 dari satu ruangan ke sana. Mari kita lihat apa yang terjadi beberapa minggu mendatang ..

Ketika saya menggunakan gateway Tradfri, saya memiliki lampu tidak responsif hampir setiap hari (spektrum putih Tradfri GU10, generasi pertama). Saya beralih ke jembatan Philips Hue dan masalahnya sepertinya hilang, tetapi setelah 2 minggu, satu bohlam menjadi tidak responsif (seperti biasa, siklus daya menyelesaikan masalah).

Tidak yakin mengapa dan bagaimana jembatan Hue bekerja lebih baik dengan lampu Tradfri, tetapi menurut saya masalah sebenarnya adalah dengan lampu.

Saya tidak memiliki GU10 tunggal dan masih mengalami masalah.

Tolong beritahu saya bagaimana saya bisa membantu dengan log dll untuk mencoba menyelesaikan ini.
Tampaknya ringan (tebakan saya di sini) bahwa beberapa node "tertidur" dan tidak bangun saat pertama kali mencoba membangunkannya?

Apakah ini hanya menjadi masalah jika ada beberapa node hop di mesh? Bagi saya itu cukup konsekuen ketika ada lebih dari satu lompatan ke conbee. Sekali lagi, hanya perasaan. Belum dikonfirmasi.

Saya memiliki 8 GU-10 berusia sekitar 18 bulan. Salah satunya menjadi abu-abu sekali dalam waktu itu. Mereka semua berada di ruangan yang sama dengan tongkat conbee. Saya memiliki beberapa lampu 980lm 3 tahun. Yang terjauh dari gw yang melompat melalui gu 10 menjadi abu-abu mungkin setiap dua minggu sekali.
@tubalainen mungkin

Di samping yang menjadi abu-abu, saya memiliki Osram yang tidak pernah mati.

Ya, @tubalainen mungkin memiliki petunjuk. Saya sebenarnya telah memasukkan GU10 abu-abu saya ke dalam soket lampu pada kabel yang saya gunakan saat menambahkan lampu baru dan ketika mereka masuk, mereka berkali-kali hidup kembali. Tapi kemudian ketika saya mengembalikannya ke tempatnya, mereka keluar lagi. Tidak 100% konsisten bahwa mereka kembali, tetapi mungkin masih merupakan kaki tangan.

Berikut adalah petunjuk potensial lainnya. Saya tidak pernah memiliki lampu menjadi abu-abu (dalam waktu lebih dari setahun dengan 8 lampu IKEA), tetapi kemudian saya memperbarui plugin dekonz Asisten Rumah dari 3,8 menjadi 3,9 dan dalam dua hari saya memiliki dua GU10 menjadi abu-abu, saya memulihkan cadangan dari versi 3.8 plugin dan tidak ada masalah sejak saat itu. Yang aneh adalah plugin 3.8 dan 3.9 menggunakan versi deconz yang sama (jika log perubahan selesai). Namun, bahkan di Phoscon lampu tidak bisa diakses. Ini semua agak aneh, tapi saya berasumsi bahwa versi 3.9 plugin membuat semacam permintaan untuk deconz yang membuat lampu IKEA tidak stabil.

Saya tidak menggunakan HA dan masih mengalami masalah. Saya telah membeli beberapa GU10 ne dan sekarang mengganti setiap lampu yang menjadi abu-abu lebih dari sekali. Lampu apa pun yang sudah saya ganti tidak menjadi abu-abu lagi. Mungkin masalah perangkat keras, mungkin tidak tetapi sepertinya kami tidak akan memiliki solusi dalam waktu dekat.

Saya punya masalah serupa. Beberapa node terang tidak merespons perintah dan menjadi abu-abu. Yang aneh adalah jika saya mengirim perintah grup, node cahaya yang sama merespons dengan sempurna setiap saat.

Saya punya masalah serupa. Beberapa node terang tidak merespons perintah dan menjadi abu-abu. Yang aneh adalah jika saya mengirim perintah grup, node cahaya yang sama merespons dengan sempurna setiap saat.

Apakah perintah grup tetap berfungsi setelah katakanlah beberapa hari / lebih dari seminggu?
Dalam kasus saya: cepat atau lambat lampu juga berhenti mendengarkan perintah grup.

Saya punya masalah serupa. Beberapa node terang tidak merespons perintah dan menjadi abu-abu. Yang aneh adalah jika saya mengirim perintah grup, node cahaya yang sama merespons dengan sempurna setiap saat.

Apakah perintah grup tetap berfungsi setelah katakanlah beberapa hari / lebih dari seminggu?
Dalam kasus saya: cepat atau lambat lampu juga berhenti mendengarkan perintah grup.

Ya, tampaknya ini juga berfungsi dengan baik seiring waktu. Tapi saya punya teori tentang apa yang salah. Ketika node cahaya dirutekan melalui bohlam TRADFRI E27 WS opal 1000lm masalah terjadi. Jadi kemarin saya mematikan dua yang saya miliki di jaringan saya. Sejak itu semuanya tampak berjalan dengan sempurna.

Saya memiliki bohlam TRADFRI GU10 WS 400lm, bohlam TRADFRI E14 CWS opal 600lm dan bohlam TRÅDFRI E27 CWS opal 600lm. Mereka sepertinya tidak menimbulkan masalah.

Ini mungkin terkait dengan firmware Trådfri yang lebih lama. Lampu yang lebih baru hadir dengan firmware yang lebih baru, tetapi menurut saya IKEA belum menerbitkan firmware yang diperbarui untuk semua lampu generasi pertama. Saya tidak memiliki spot Trådfri GU10, tetapi dengan bohlam CWS menerima pembaruan firmware. Bohlam 1000lm saya yang dapat diredupkan tidak; Saya tidak yakin tentang bola spektrum putih.

Ini mungkin terkait dengan firmware Trådfri yang lebih lama. Lampu yang lebih baru hadir dengan firmware yang lebih baru, tetapi menurut saya IKEA belum menerbitkan firmware yang diperbarui untuk semua lampu generasi pertama. Saya tidak memiliki spot Trådfri GU10, tetapi dengan bohlam CWS menerima pembaruan firmware. Bohlam 1000lm saya yang dapat diredupkan tidak; Saya tidak yakin tentang bola spektrum putih.

Bohlam TRADFRI saya GU10 WS 400lm menggunakan firmware yang sama, 2.0.022. Mereka sepertinya tidak menimbulkan masalah (belum :))

Ini mungkin terkait dengan firmware Trådfri yang lebih lama. Lampu yang lebih baru hadir dengan firmware yang lebih baru, tetapi menurut saya IKEA belum menerbitkan firmware yang diperbarui untuk semua lampu generasi pertama. Saya tidak memiliki spot Trådfri GU10, tetapi dengan bohlam CWS menerima pembaruan firmware. Bohlam 1000lm saya yang dapat diredupkan tidak; Saya tidak yakin tentang bola spektrum putih.

Saya setuju. Versi pertama dari bohlam Ikea (pada 1. * firmware) memiliki beberapa bug perangkat lunak / perangkat keras yang tidak mempengaruhi iterasi kedua (pada 2. *).

Sayangnya, Ikea tampaknya tidak mendukung lagi versi aslinya dan tidak akan menyediakan pembaruan firmware apa pun. Pada saat yang sama, tidak mungkin mengembalikan bohlam dan menukar dengan yang baru (saya sudah mencoba, di Inggris).

Ini mungkin terkait dengan firmware Trådfri yang lebih lama. Lampu yang lebih baru hadir dengan firmware yang lebih baru, tetapi menurut saya IKEA belum menerbitkan firmware yang diperbarui untuk semua lampu generasi pertama. Saya tidak memiliki spot Trådfri GU10, tetapi dengan bohlam CWS menerima pembaruan firmware. Bohlam 1000lm saya yang dapat diredupkan tidak; Saya tidak yakin tentang bola spektrum putih.

Saya setuju. Versi pertama dari bohlam Ikea (pada 1. * firmware) memiliki beberapa bug perangkat lunak / perangkat keras yang tidak mempengaruhi iterasi kedua (pada 2. *).

Sayangnya, Ikea tampaknya tidak mendukung lagi versi aslinya dan tidak akan menyediakan pembaruan firmware apa pun. Pada saat yang sama, tidak mungkin mengembalikan bohlam dan menukar dengan yang baru (saya sudah mencoba, di Inggris).

Saya memiliki bohlam cws di 1.3.009. Mereka sepertinya tidak menimbulkan masalah.

Memperbarui:

Sepertinya bohlam IKEA lain juga menyebabkan masalah.

Ini bohlam IKEA saya. Sejauh ini hanya bohlam TRADFRI E27 WS opal 1000lm yang menyebabkan masalah. Mereka sekarang terputus dan segala sesuatunya tampak berfungsi. Tetapi saya memposting pembaruan jika saya mendapatkan kesalahan baru.

Sepertinya saya tidak memiliki perangkat 2.x apa pun.
Beberapa GU10 bekerja dengan baik, beberapa tidak. Saya mulai mengganti yang rusak dengan yang "baru" yang saya beli beberapa bulan kemudian. Tampaknya mereka menjalankan firmware yang sama meskipun ada nomor "1808 -S" yang tercetak pada soket sementara yang "lebih baru" memiliki "1729-S".
Saya mengganti 3 lampu sejauh ini dan tidak ada masalah baru yang terjadi selama 2 minggu. Saya tidak hanya memiliki masalah dengan GU10 tetapi juga dengan Panel FLOALT yang tidak saya ganti.

Sepertinya saya tidak memiliki perangkat 2.x apa pun. Beberapa GU10 bekerja dengan baik, beberapa tidak. Saya mulai mengganti yang rusak dengan yang "baru" yang saya beli beberapa bulan kemudian. Tampaknya mereka menjalankan firmware yang sama meskipun ada nomor "1808 -S" yang tercetak pada soket sementara yang "lebih baru" memiliki "1729-S". Saya mengganti 3 lampu sejauh ini dan tidak ada masalah baru yang terjadi selama 2 minggu. Saya tidak hanya memiliki masalah dengan GU10 tetapi juga dengan Panel FLOALT yang tidak saya ganti.

Menarik! Saya akan melihat bohlam saya untuk melihat apakah ada semacam korelasi.

Sepertinya salah satu node saya terpengaruh oleh masalah lagi. Saya masih memiliki beberapa node IKEA di jaringan jadi saya akan melakukan beberapa tes untuk melihat apakah saya dapat menarik beberapa kesimpulan.

Saya memiliki bohlam TRADFRI GU10 WS 400lm, bohlam TRADFRI E14 CWS opal 600lm dan bohlam TRÅDFRI E27 CWS opal 600lm. Mereka sepertinya tidak menimbulkan masalah.

Sepertinya setelah jala telah naik untuk sementara bahkan perangkat IKEA lainnya menyebabkan masalah dan node berhenti untuk merespons perintah. Bahkan node IKEA lainnya dapat terpengaruh, bagi saya sepertinya masalah mulai muncul kemudian node dirutekan melalui node IKEA.

Apakah ada kegiatan yang direncanakan untuk melihat ini? Saya akan memindahkan semua perangkat IKEA saya ke gateway warna saya sementara ini diselesaikan.

node berhenti untuk menanggapi perintah.

Apakah Anda yakin ini masalahnya? Sudahkah Anda memastikan ini dengan mengendus lalu lintas ZigBee? Apakah node lain tidak lagi bereaksi terhadap sakelar nirkabel yang mengontrol lampu tanpa melalui gateway? Apakah mereka tidak lagi bereaksi terhadap perintah grup?
Menurut pengalaman saya, masalahnya adalah gateway tidak lagi mengetahui rute ke node lain, jadi perintah unicast dari gateway tidak pernah mencapai node lain. Node itu sendiri merespons dengan baik, mereka tidak menerima apa pun untuk ditanggapi.

Bahkan node IKEA lainnya dapat terpengaruh, bagi saya sepertinya masalah mulai muncul kemudian node dirutekan melalui node IKEA.

Perutean IKEA node (bukan?) Entah bagaimana memutus rute dari dan / atau penemuan rute oleh gateway ke node lain.

Apakah ada kegiatan yang direncanakan untuk melihat ini?

Anda harus meminta dukungan elektronik dresden. Perutean ditangani oleh firmware RaspBee / ConBee (dan program inti deCONZ?). Tidak ada yang bisa kami lakukan tentang ini di plugin REST API.

Membeli Tradfri Hub akhir pekan lalu dan memasangkan semua tempat GU10 dari satu ruangan ke sana. Mari kita lihat apa yang terjadi beberapa minggu mendatang ..

Mungkin agak terlalu dini untuk mengatakannya, tetapi 29 hari yang lalu saya telah memindahkan semua GU10 Tradfri (8x warmwhite - 1.2.214) dari satu ruangan ke Tradfri Hub, dan tidak ada satupun yang menjadi tidak responsif hingga sekarang.

Mungkin agak terlalu dini untuk mengatakannya, tetapi 29 hari yang lalu saya telah memindahkan semua GU10 Tradfri (8x warmwhite - 1.2.214) dari satu ruangan ke Tradfri Hub, dan tidak ada satupun yang menjadi tidak responsif hingga sekarang.

Saya berharap begitu. Masalahnya tidak begitu banyak disebabkan oleh perangkat dari satu pabrikan, melainkan oleh interaksi antara perangkat dari pabrikan yang berbeda, menafsirkan standar ZigBee secara berbeda. Itulah mengapa kebanyakan hub / gateway / bridge hanya mendukung perangkat mereka sendiri. Eksperimen yang lebih menarik adalah menghubungkan Trådfri spot a ke Hue bridge atau OSRAM gateway.

Selain itu, delapan lampu dalam satu ruangan mungkin akan menghasilkan koneksi langsung antara hub dan setiap lampu: semua koneksi single-hop. Masalah perutean muncul hanya dengan jaringan yang lebih besar, dengan lebih banyak perangkat daripada entri di tabel tetangga (biasanya sekitar 20); dan / atau dengan perangkat yang secara fisik berada di luar jangkauan dari hub.

node berhenti untuk menanggapi perintah.

Apakah Anda yakin ini masalahnya? Sudahkah Anda memastikan ini dengan mengendus lalu lintas ZigBee? Apakah node lain tidak lagi bereaksi terhadap sakelar nirkabel yang mengontrol lampu tanpa melalui gateway? Apakah mereka tidak lagi bereaksi terhadap perintah grup?
Menurut pengalaman saya, masalahnya adalah gateway tidak lagi mengetahui rute ke node lain, jadi perintah unicast dari gateway tidak pernah mencapai node lain. Node itu sendiri merespons dengan baik, mereka tidak menerima apa pun untuk ditanggapi.

Saya tidak memiliki pengalaman atau peralatan untuk mengendus lalu lintas. Anda mungkin benar tentang perilaku masalah tersebut. Node saya merespons perintah grup sepanjang waktu. Masalahnya adalah (jika saya mengerti) bahwa perintah unicast tidak pernah mencapai tujuannya.

Selama saya hanya mengirim perintah grup, semuanya tampaknya berfungsi dengan baik.

Bahkan node IKEA lainnya dapat terpengaruh, bagi saya sepertinya masalah mulai muncul kemudian node dirutekan melalui node IKEA.

Perutean IKEA node (bukan?) Entah bagaimana memutus rute dari dan / atau penemuan rute oleh gateway ke node lain.

Apakah ada kegiatan yang direncanakan untuk melihat ini?

Anda harus meminta dukungan elektronik dresden. Perutean ditangani oleh firmware RaspBee / ConBee (dan program inti deCONZ?). Tidak ada yang bisa kami lakukan tentang ini di plugin REST API.

Ya saya telah mengirim email kepada mereka, tetapi tidak mendapat tanggapan selain beberapa daftar periksa.

Mungkin agak terlalu dini untuk mengatakannya, tetapi 29 hari yang lalu saya telah memindahkan semua GU10 Tradfri (8x warmwhite - 1.2.214) dari satu ruangan ke Tradfri Hub, dan tidak ada satupun yang menjadi tidak responsif hingga sekarang.

Saya berharap begitu. Masalahnya tidak begitu banyak disebabkan oleh perangkat dari satu pabrikan, melainkan oleh interaksi antara perangkat dari pabrikan yang berbeda, menafsirkan standar ZigBee secara berbeda. Itulah mengapa kebanyakan hub / gateway / bridge hanya mendukung perangkat mereka sendiri. Eksperimen yang lebih menarik adalah menghubungkan Trådfri spot a ke Hue bridge atau OSRAM gateway.

Selain itu, delapan lampu dalam satu ruangan mungkin akan menghasilkan koneksi langsung antara hub dan setiap lampu: semua koneksi single-hop. Masalah perutean muncul hanya dengan jaringan yang lebih besar, dengan lebih banyak perangkat daripada entri di tabel tetangga (biasanya sekitar 20); dan / atau dengan perangkat yang secara fisik berada di luar jangkauan dari hub.

Saya telah melakukan ini untuk memastikan itu tidak terkait dengan firmware 1.2.214 dari GU10 lama yang banyak disebutkan sebagai kemungkinan penyebab di sini (dan kemungkinan alasan untuk membuat versi baru GU10).
Mungkin dalam kaitannya dengan terhubung melalui router lain.

Saya akan mempertimbangkan untuk memasangkan lampu GU10 saya yang lain (juga warmwhite 1.2.214) ke Tradfri Hub juga (juga yang ada di lantai 2de / 3)

Apakah ada kemajuan dalam hal ini? Agak konyol dengan lampu GU10 saya yang menjadi abu-abu :(

Saya rasa saya melihat seseorang menyebutkan pengontrol tirai atau tombol on / off. Sebenarnya saya sadar bahwa masalah menjadi jauh lebih buruk saat saya mendapatkan tirai FYRTUR. Ini juga tombol ikea pertama yang saya tambahkan ke jaringan ... Saya tidak ...

Saya belum memiliki tombol on / off fyrtur di jaringan sejak posting terakhir saya dan tidak ada putus sekolah pada waktu itu. Mungkinkah kebetulan ...?

Apakah ada kemajuan dalam hal ini? Agak konyol dengan lampu GU10 saya yang menjadi abu-abu :(
Saya rasa saya melihat seseorang menyebutkan pengontrol tirai atau tombol on / off. Sebenarnya saya sadar bahwa masalah menjadi jauh lebih buruk saat saya mendapatkan tirai FYRTUR. Ini juga tombol ikea pertama yang saya tambahkan ke jaringan ... Saya tidak ...

Saya belum memiliki tombol on / off fyrtur di jaringan sejak posting terakhir saya dan tidak ada putus sekolah pada waktu itu. Mungkinkah kebetulan ...?

Tidak, saya tidak memiliki Tradfri on / off atau tirai Tradfri dan mengalami masalah ini.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Masalah ini tidak sengaja ditutup. Membuka kembali.

Eksperimen yang lebih menarik adalah menghubungkan Trådfri spot a ke Hue bridge atau OSRAM gateway.

Saya memiliki masalah yang sama dengan bohlam Trådfri (generasi pertama) yang terhubung ke hub Trådfri. Masalahnya benar-benar hilang ketika saya memindahkan semua bohlam ke jembatan Hue.

BTW - Saya masih yakin bahwa gen pertama lampu Trådfri disadap, tetapi jembatan Hue menangani lampu secara berbeda (saya perhatikan bahwa kadang-kadang lampu tidak sinkron selama sepersekian detik saat terhubung ke Hue - tidak pernah terjadi dengan Trådfri ).

jembatan Hue menangani lampu secara berbeda (saya perhatikan bahwa kadang-kadang lampu padam selama sepersekian detik ketika terhubung ke Hue - tidak pernah terjadi dengan Trådfri).

Dalam pengaturan Hue, lampu hanya dikontrol oleh jembatan Hue: sakelar dan sensor nirkabel mengirim pemberitahuan ke jembatan, memicu aturan yang mengontrol lampu. Bridge memprediksi keadaan cahaya dan memperbarui cache-nya di muka saat mengirim perintah ke lampu. Ini mengumpulkan lampu secara berkala untuk memvalidasi / memperbarui status cache.

Dalam penyiapan Trådfri, lampu dikontrol langsung oleh perintah dari sakelar dan sensor nirkabel. Lampu kemudian mengirim laporan dengan status diperbarui ke hub.

Saat mengontrol lampu yang terhubung ke jembatan Hue langsung dari sakelar atau sensor nirkabel (Trådfri), Anda akan melihat penundaan karena jembatan Hue tidak mengatur pelaporan atribut pada lampu. Semakin banyak lampu di jaringan Anda, semakin lama penundaannya, karena polling berputar melalui lebih banyak lampu.

Saat menyambungkan bohlam Hue ke hub Trådfri, dan mengontrol lampu tersebut langsung dari sakelar atau sensor nirkabel (Trådfri), status hub tidak akan pernah diperbarui, karena lampu Hue tidak melakukan pelaporan atribut dan hub Trådfri tidak melakukan polling.

Perhatikan bahwa perbedaan ini ada pada level aplikasi, baik dalam kendali plugin REST API. Perutean berada pada level yang lebih rendah dalam tumpukan ZigBee.

Sekarang semua node router IKEA saya dipindahkan ke jembatan warna saya. Saya masih memiliki masalah yang sama di jaringan saya. Jadi saya curiga ada hal lain yang menyebabkannya. Dan sekali lagi itu mempengaruhi node yang dirutekan dan tidak memiliki tautan langsung ke gateway.

Sekarang semua node router IKEA saya dipindahkan ke jembatan warna saya. Saya masih memiliki masalah yang sama di jaringan saya. Jadi saya curiga ada hal lain yang menyebabkannya. Dan sekali lagi itu mempengaruhi node yang dirutekan dan tidak memiliki tautan langsung ke gateway.

Masalah yang sama dengan lampu Tradfri yang sekarang dipasangkan ke jembatan Hue?

@ ebaauw haruskah masalah perutean muncul ketika lampu terhubung ke jembatan secara langsung DAN melalui router, atau hanya jika tidak langsung terhubung ke jembatan?

Sekarang semua node router IKEA saya dipindahkan ke jembatan warna saya. Saya masih memiliki masalah yang sama di jaringan saya. Jadi saya curiga ada hal lain yang menyebabkannya. Dan sekali lagi itu mempengaruhi node yang dirutekan dan tidak memiliki tautan langsung ke gateway.

Masalah yang sama dengan lampu Tradfri yang sekarang dipasangkan ke jembatan Hue?

Saya hanya memiliki 3 bohlam yang dipasangkan. Tapi tidak ada masalah yang saya perhatikan.

@ ebaauw haruskah masalah perutean muncul ketika lampu terhubung ke jembatan secara langsung DAN melalui router, atau hanya jika tidak langsung terhubung ke jembatan?

Di jaringan saya kedaluwarsa saya adalah bahwa masalah dengan perintah yang hilang memengaruhi node yang dirutekan melalui node lain dan tidak langsung dengan gateway. Saya memiliki masalah yang sama sekarang bahkan saat tidak ada lampu IKEA yang terhubung.

Saya memiliki satu node (1) tanpa tautan langsung ke gateway. Itu tidak merespons (atau seperti yang disebutkan ebaauw, mungkin mereka tidak pernah mencapai node karena masalah perutean) ke perintah unicast. Ketika saya mematikan node (2) itu dialihkan melalui node (1) memang mendapatkan rute langsung ke gateway dan mulai bekerja dengan sempurna.

haruskah masalah perutean muncul ketika lampu terhubung ke jembatan secara langsung DAN melalui router, atau hanya jika tidak langsung terhubung ke jembatan?

Tidak ada yang namanya "koneksi" di ZigBee. Setiap router menyimpan tabel tetangga dari perangkat terdekat, yang dapat dijangkau secara langsung (pada level MAC). Garis-garis dalam GUI deCONZ tidak lebih dari representasi grafis dari tabel tetangga ini (sejauh deCONZ benar-benar telah membaca ini).

Saat router perlu mengirim pesan ke perangkat yang tidak ada di tabel tetangganya, ia mengirim permintaan ke router tetangga, sehingga mereka dapat meneruskannya. Pesan tunggal di level NWK ditransmisikan ulang melalui beberapa hop di level MAC. RaspBee / ConBee (dalam perspektif ini) hanyalah router lain. Afaik perangkat akhir hanya mengirim pesan ke router induknya.

Jadi, ketika lampu ada di tabel tetangga RaspBee / ConBee, tidak ada penemuan rute yang terlibat, terlepas dari apakah lampu itu adalah tabel tetangga dari router lain. Jika tidak, RaspBee / ConBee perlu mencari tahu router tetangga mana yang tahu cara menjangkau cahaya. Jika cahaya berjarak beberapa lompatan, setiap router di jalurnya secara rekursif perlu melakukan hal yang sama.

Saya khawatir detailnya hilang pada saya, tetapi ada banyak cara untuk melakukan penemuan rute ini. Ketika router di jalur antara gateway dan lampu menggunakan cara yang berbeda, bisa saja terjadi kesalahan. Gateway mungkin akhirnya mengirim pesan ke router tetangga yang salah (yang tidak tahu cara menjangkau cahaya), atau gateway mungkin tidak tahu cara menjangkau cahaya sama sekali, dan tidak akan mengirim pesan sama sekali. Pesan unicast umumnya harus dijawab dengan ACK, sehingga gateway akan menandai perangkat sebagai tidak dapat dijangkau jika tidak menerima ACK. Tentu saja, tidak ada cara untuk mengetahui apakah pesan asli atau ACT hilang (perangkat jarak jauh perlu mengetahui rute ke gateway untuk mengirim ACK).

Pesan siaran (digunakan oleh perintah grup) tidak menggunakan perutean apa pun; mereka hanya disiarkan ulang pada level MAC oleh semua router. Meskipun sangat andal, mereka mengkonsumsi banyak bandwidth jaringan. Juga, mereka tidak dijawab oleh ACK.

Di jaringan saya kedaluwarsa saya adalah bahwa masalah dengan perintah yang hilang memengaruhi node yang dirutekan melalui node lain dan tidak langsung dengan gateway. Saya memiliki masalah yang sama sekarang bahkan saat tidak ada lampu IKEA yang terhubung.

Jadi untuk masalah perutean, Anda memerlukan jaringan yang cukup besar agar perangkat tidak muncul di tabel perutean RaspBee / ConBee. Entah karena jumlah perangkat yang melebihi ukuran tabel routing, atau karena perangkat jarak jauh secara fisik berada di luar jangkauan RaspBee / ConBee, dan hanya dapat dijangkau melalui router lain. Saya kira banyak lompatan akan membuat masalah menjadi lebih buruk.

Sekali lagi, ini bukan kesalahan IKEA karena produsen berbeda menggunakan cara yang berbeda dan agak tidak kompatibel untuk melakukan penemuan rute. Terutama dengan rute multi-hop, hanya ada begitu banyak yang dapat dikerjakan di firmware RaspBee / ConBee.

Saya memiliki satu node (1) tanpa tautan langsung ke gateway. Itu tidak merespons (atau seperti yang disebutkan ebaauw, mungkin mereka tidak pernah mencapai node karena masalah perutean) ke perintah unicast. Ketika saya mematikan node (2) itu dialihkan melalui node (1) memang mendapatkan rute langsung ke gateway dan mulai bekerja dengan sempurna.

Sekali lagi, saya khawatir detailnya hilang pada saya, tetapi saya dapat memikirkan beberapa skenario yang akan menyebabkan perilaku ini. RaspBee / ConBee ingin mengirim pesan ke node2 atau node1, tidak menerima ack, menyimpulkan bahwa node2 tidak dapat dijangkau dan menghapusnya dari tabel tetangganya. Tabel sekarang memiliki ruang untuk entri baru, yang digunakan untuk node1.

Sekali lagi, ini bukan kesalahan IKEA karena produsen berbeda menggunakan cara yang berbeda dan agak tidak kompatibel untuk melakukan penemuan rute. Terutama dengan rute multi-hop, hanya ada begitu banyak yang dapat dikerjakan di firmware RaspBee / ConBee.

Bagi saya, ini terdengar seperti pendekatan platform ZigBee multi-vendor dikutuk oleh desain sampai standar yang lebih menyeluruh ditetapkan dan diikuti. Masih saya agak terkunci sekarang karena saya tidak ingin menggunakan beberapa gateway yang mungkin tidak akan berfungsi di lingkungan saya (misalnya untuk sensor yang tidak dapat dijangkau secara langsung oleh gateway jika saya melepas lampu yang saat ini berfungsi sebagai router).

Bagi saya ini terdengar seperti pendekatan platform ZigBee multi vendor sudah hancur

Saya pasti berharap tidak, tapi ini pasti menantang. Ukuran tampaknya penting di sini: jika jaringan Anda cukup kecil, Anda mungkin tidak mengalami masalah perutean ini sama sekali. Selain itu, jika pusat (geografis) jaringan Anda terdiri dari router oleh vendor yang kompatibel, beberapa router yang kurang kompatibel di tepi jaringan Anda mungkin tidak masalah (karena tidak dirutekan untuk menjangkau perangkat lain).

Saya memang mengganti lampu OSRAM, Trådfri, dan innr saya (yang menyebabkan masalah) dengan bohlam Hue. Saya sekarang memiliki 104 node, 51 router dan 53 perangkat akhir. 2/3 dari router adalah lampu Hue. Satu-satunya router yang tidak dapat dijangkau (tetapi masih mengirim laporan) adalah pengontrol tirai Xiaomi. 20 dari perangkat akhir adalah Hue, 20 Xiaomi, 8 Eurotronic Spirit dan 5 IKEA. Semangat Eurotronik dan IKEA Fyrtur membuat saya bermasalah secara teratur (mereka diusir oleh orang tua mereka, tetapi tidak menemukan orang tua baru - lagi-lagi tidak dapat dijangkau oleh gateway, tetapi masih mengirimkan laporan), yang lain tampaknya baik-baik saja. Untuk semua perangkat, perputaran daya biasanya memperbaiki situasi, tetapi terkadang saya perlu membuka jaringan saat menghidupkan perangkat.

Saya telah mempertimbangkan untuk membagi jaringan saya, bukan berdasarkan vendor, tetapi berdasarkan lantai atau sisi jalan vs sisi belakang rumah saya. Ini banyak pekerjaan dan saya enggan melakukannya, sampai saya memiliki pemahaman yang lebih baik tentang apa yang menyebabkan masalah secara mendetail, dan penyiapan apa yang mungkin mencegahnya terjadi.

@ ebaauw , memikirkan tentang apa yang Anda katakan di posting di atas, Akan menarik untuk mempertimbangkan semacam preferensi untuk tabel routing deCONZ. Bisakah kita mempertimbangkan router 'daftar hitam' yang tidak disukai sebagai hop pertama. Jika Anda dapat membangun jaringan untuk memuat cukup router 'bagus', maka hop pertama akan selalu melalui itu dan hop kedua akan menjangkau semua perangkat lain di jaringan.
Itu bukan solusi yang pasti, tetapi akan memungkinkan jaringan yang jauh lebih besar (geografis dan jumlah perangkat) sambil selalu melalui router 'pilihan'.

Pemikiran lain: karena kami tahu chip mana yang digunakan oleh IKEA (Silabs EFR32, mesin tokek) dan kami tahu (dari berbagai sumber di internet) bahwa mereka menggunakan mesin zigbee yang disediakan oleh Silabs, kami dapat mempertimbangkan dua tindakan.

1. Kami menganalisis cara mesin silab melakukan perutean dan dari situ mengetahui apa yang menyebabkan masalah ini
2. Kami membuat versi kustom dari firmware lampu berdasarkan mesin silab yang sama, memperbaiki masalah dan mencari cara untuk menginstal firmware tersebut OTA

Keduanya akan membutuhkan akses ke Silabs SDK, yang tidak saya lakukan. Apakah ada orang yang aktif di sini yang melakukan ..? Saya tidak berharap mengeluarkan $ 500 untuk kit pengembangan mereka yang mencakup SDK. Mungkin Dresden Electronics bersedia melakukan itu?

my 2 cts (agak frustrasi dengan koneksi yang kadang-kadang terputus).

Bisakah kita mempertimbangkan router 'daftar hitam' yang tidak disukai sebagai hop pertama.

Kami tidak. Itu harus diimplementasikan di firmware RaspBee / ConBee, saya kira. Bukan ide yang buruk imho, tapi saya tidak tahu seberapa layak ini, mengingat batasan ukuran di perangkat EEPROM dan NVRAM. @ Manup , apa pendapat Anda tentang ini?

1. Kami membuat versi kustom dari firmware lampu berdasarkan mesin silab yang sama, memperbaiki masalah dan mencari cara untuk menginstal firmware tersebut OTA

Ini jauh di luar pengetahuan saya saat ini, dan, sejujurnya, ambisi saya - saya melakukan ini untuk hobi. Saya telah bermain-main dengan XBee untuk melihat apakah saya dapat menulis aplikasi ZigBee (tujuan akhir saya adalah untuk memperhalus tirai venetian saya), tetapi saya tidak pernah melihat ke tingkat yang lebih rendah dari tumpukan ZigBee, di mana perutean dilakukan .

Kami tidak. Itu harus diimplementasikan di firmware RaspBee / ConBee, saya kira. Bukan ide yang buruk imho, tapi saya tidak tahu seberapa layak ini, mengingat batasan ukuran di perangkat EEPROM dan NVRAM. @ Manup , apa pendapat Anda tentang ini?

Saya kira saya menganggap @manup bagian dari Kami;)

Ini jauh di luar pengetahuan saya saat ini, dan, sejujurnya, ambisi saya - saya melakukan ini untuk hobi. Saya telah bermain-main dengan XBee untuk melihat apakah saya dapat menulis aplikasi ZigBee (tujuan akhir saya adalah untuk memperhalus tirai venetian saya), tetapi saya tidak pernah melihat ke tingkat yang lebih rendah dari tumpukan ZigBee, di mana perutean dilakukan .

Saya setuju, bagi saya juga itu hobi, namun saya berharap seseorang lebih tahu tentang detail ini.

Saya telah melakukan sesuatu yang serupa dengan menggunakan papan CC2530 Saya berencana untuk zigbeeify sistem sprinkler saya (saya tidak dapat menerima saya harus berjalan di sekitar taman untuk secara manual mengaktifkan / menonaktifkan sprinkler tertentu :)) Saya telah dapat mengkompilasi a zigbee firmware untuk papan CC2530 saya yang bergabung dengan jaringan deCONZ sebagai lampu hidup / mati. Katup yang saya rencanakan untuk digunakan memiliki mekanisme penguncian, jadi memerlukan sinyal khusus untuk beralih, oleh karena itu saya harus membuat firmware sendiri ...

Kami tidak. Itu harus diimplementasikan di firmware RaspBee / ConBee, saya kira. Bukan ide yang buruk imho, tapi saya tidak tahu seberapa layak ini, mengingat batasan ukuran di perangkat EEPROM dan NVRAM. @ Manup , apa pendapat Anda tentang ini?

Tumpukan Zigbee di firmware memiliki parameter untuk dikontrol jika sebuah rute akan digunakan sebagai pengganti tautan langsung berdasarkan kualitasnya (RSSI / LQI), ini seharusnya sudah berfungsi dengan cukup baik dan telah diubah selama bertahun-tahun.

Jalur lebih lanjut mungkin merupakan pendekatan yang lebih umum untuk mengontrol tabel perutean semua perangkat.

Catatan: Anda dapat meminta tabel routing dari sebuah router dengan memilihnya dan menekan R key, rute hop berikutnya akan ditampilkan dengan warna biru.

Saat ini, ketika jaringan Zigbee dibuka, semua router diizinkan untuk menjadi node induk karena Mgmt_Permit_Joining_req dikirim sebagai siaran. Namun jika kami mengirim permintaan ini sebagai unicast hanya ke router tertentu, perangkat baru hanya dapat bergabung melalui perangkat yang satu ini. Ini mungkin berguna untuk perangkat akhir Xiaomi yang sering menempel pada orang tuanya. Untuk perangkat lain yang bergabung seperti router dan misalnya perangkat akhir Philips Hue, ini tidak akan banyak membantu karena mereka bebas memilih orang tua dan rute baru sendiri.

Mgmt_NWK_IEEE_Joining_List_req (baru) dalam spesifikasi Zigbee R22 juga terlihat menarik:

Perintah Mgmt_NWK_IEEE_Joining_List_req disediakan sebagai mekanisme untuk mendapatkan daftar alamat IEEE yang diharapkan untuk bergabung ke jaringan. Hal ini memungkinkan router lokal untuk memfilter Permintaan Beacon yang Ditingkatkan dan hanya menanggapi perangkat yang bergabung.

Tanpa perangkat beacon bahkan tidak akan mencoba untuk bergabung dengan router tertentu. Tapi saya tidak tahu seberapa baik permintaan ini didukung oleh router yang tersedia saat ini.

Peluru perak mungkin menggunakan Perutean Sumber di mana gateway menyediakan rute lengkap dalam setiap frame, tetapi saya belum pernah melihat ini digunakan oleh produk konsumen atau gateway dan saya kira karena itu mungkin tidak (atau buruk) didukung oleh router saat ini. Mungkin patut dicoba.

Catatan: Anda dapat meminta tabel routing dari sebuah router dengan memilihnya dan menekan R key, rute hop berikutnya akan ditampilkan dengan warna biru.

Keren, saya tidak tahu yang itu. Apakah ada gambaran umum dari semua kunci / perintah yang didukung oleh GUI? Apakah mungkin untuk mengembalikan garis biru sebelum menanyakan node berikutnya? Sepertinya tidak berfungsi untuk RaspBee / ConBee itu sendiri?

Apakah tabel routing berbeda dengan tabel tetangga? Mengendus, saya hanya melihat pesan ZDP _Link Quality Request_ dan _Link Quality Response_, melaporkan tabel tetangga. Apakah ini berarti bahwa garis ke node yang tidak berwarna biru adalah rute "masuk"?

@manup , Sungguh visualisasi yang menarik

Peluru perak mungkin menggunakan Source Routing

Yah ... itu patut dicoba, kurasa. Menurut saya, di jaringan saya, lampu IKEA yang paling terpengaruh adalah lampu yang berada pada jarak yang lebih jauh dari koordinator. Saya curiga bahwa sesuatu yang terkait dengan perutean menyebabkan masalah, seperti yang disebutkan @ebaauw .
Saya bersedia menguji sesuatu seperti ini untuk Anda. Meskipun, saya harus mengakui bahwa kehilangan koneksi tidak terlalu dapat diandalkan, jadi pengujian mungkin sulit.

Saya lebih berpikir di sepanjang garis koordinator menjadi selektif tentang router mana yang akan dipilih untuk hop pertama. Jika kami dapat menemukan router yang berfungsi baik dengan perangkat IKEA (mungkin itu adalah router IKEA), merutekan semua paket melalui itu akan membuat segalanya lebih kuat. Tidak yakin apakah Anda dapat mengelabui proses penemuan rute agar lebih memilih router tertentu untuk hop pertama, tetapi mungkin Anda dapat mengomentarinya, @manup

Catatan: Anda dapat meminta tabel routing dari sebuah router dengan memilihnya dan menekan R key, rute hop berikutnya akan ditampilkan dengan warna biru.

Keren, saya tidak tahu yang itu. Apakah ada gambaran umum dari semua kunci / perintah yang didukung oleh GUI? Apakah mungkin untuk mengembalikan garis biru sebelum menanyakan node berikutnya? Sepertinya tidak berfungsi untuk RaspBee / ConBee itu sendiri?

Jika seseorang ingin membuat daftar semua kombo kunci dan apa yang mereka lakukan, saya akan dengan senang hati membersihkannya dan menulis halaman wiki.

Keren, saya tidak tahu yang itu. Apakah ada gambaran umum dari semua kunci / perintah yang didukung oleh GUI?

Deskriptor Node Permintaan = 1
Minta Keterangan Daya = 2
Minta Alamat Nwk = 0
Permintaan Tabel Perutean = R
Minta Mgmt Tinggalkan = L (dengan bergabung kembali, jangan gunakan dengan lampu innr!)
Minta Titik Akhir Aktif = 7
Minta Deskriptor Sederhana = 8
Segarkan = F5 / Cmd-R
Hapus = Delete / Backspace
Gateway Device Annce = A (tidak terlalu berguna)

Apakah mungkin untuk mengembalikan garis biru sebelum menanyakan node berikutnya?

Belum, itu hanya tambahan yang cepat dan kotor untuk melihat rute :)
Mungkin menambahkan kunci lain seperti Shift-R untuk menghapus rute node berguna?

Sepertinya tidak berfungsi untuk RaspBee / ConBee itu sendiri?

Sayangnya RaspBee I / ConBee I tidak mendukung perintah ZDP terkait, ini berfungsi dengan ConBee II.

Apakah tabel routing berbeda dengan tabel tetangga? Mengendus, saya hanya melihat Permintaan Kualitas Link ZDP dan pesan Respon Kualitas Link, melaporkan tabel tetangga.

Ini adalah dua tabel terpisah, biasanya tabel routing hanya menampung rute ke node yang tidak dapat dijangkau secara langsung dan tunduk pada tabel tetangga (node ​​1-hop).

Untuk node yang berada di tabel tetangga (dan memiliki sinyal kuat) tidak diperlukan pencarian rute. Tabel tetangga itu sendiri sebagian besar dibangun menggunakan perintah Status Tautan NWK 1-hop.

Apakah ini berarti bahwa garis ke node yang tidak berwarna biru adalah rute "masuk"?

Garis non-biru (hijau / oranye / kuning) hanya mewakili tabel tetangga 1-hop. Garis biru adalah rute keluar ke beberapa tujuan dan hanya mewakili hop berikutnya (bukan rute lengkap) dalam tampilan saat ini, alamat NWK tujuan tidak ditampilkan, tetapi ada kemungkinan cetakan debug.

Kami tidak. Itu harus diimplementasikan di firmware RaspBee / ConBee, saya kira. Bukan ide yang buruk imho, tapi saya tidak tahu seberapa layak ini, mengingat batasan ukuran di perangkat EEPROM dan NVRAM. @ Manup , apa pendapat Anda tentang ini?

Tumpukan Zigbee di firmware memiliki parameter untuk dikontrol jika sebuah rute akan digunakan sebagai pengganti tautan langsung berdasarkan kualitasnya (RSSI / LQI), ini seharusnya sudah berfungsi dengan cukup baik dan telah diubah selama bertahun-tahun.

Jalur lebih lanjut mungkin merupakan pendekatan yang lebih umum untuk mengontrol tabel perutean semua perangkat.

Catatan: Anda dapat meminta tabel routing dari sebuah router dengan memilihnya dan menekan R key, rute hop berikutnya akan ditampilkan dengan warna biru.

Fungsi yang sangat berguna! Kemarin saya menyalakan bohlam TRÅDFRI GU10 WS 400lm (7 bohlam) dengan firmware 2.0.022. Hari ini masalah muncul kembali, muncul di bohlam TRÅDFRI E27 CWS opal 600lm dengan firmware 1.3.009. Berkat fungsi ini, saya dapat melihat bahwa bohlam E27 dialihkan melalui bohlam GU10. Saya mematikan semua GU10 dan seperti sulap, E27 mulai bekerja kembali.

Jadi menjadi sangat jelas bahwa perutean melalui Innr dan IKEA menyebabkan masalah. Saya sudah mulai memindahkan bohlam IKEA Innr och ke gateway rona saya. Sepertinya bohlam Philips adalah router yang bagus dan tidak menyebabkan masalah.

Jadi, saya melakukan sedikit eksperimen sambil mengatur ulang posisi lampu saya di ruang tamu. Saya menghapus dua router dan mengatur ulang posisi satu lampu. Et voila, satu cahaya telah menjadi zombie, tetapi tidak sepenuhnya. Ini berperilaku persis seperti yang saya lihat dengan lampu IKEA yang terkadang kehilangan koneksi.

Lampu IKEA terdaftar sebagai tidak dapat dijangkau, tetapi masih merespons perintah grup. Juga karena masih dikenal oleh beberapa router lain, sepertinya mereka melaporkan melihat cahaya (itu 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

dan

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Terkadang, tampaknya komunikasi dimungkinkan:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

terkadang tidak:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Hanya ada sedikit informasi tentang apa yang salah. Apa arti status 0xA7 ..?

Ada informasi lebih lanjut yang mungkin membantu untuk mengetahui apa yang terjadi?

Jadi, saya melakukan sedikit eksperimen sambil mengatur ulang posisi lampu saya di ruang tamu. Saya menghapus dua router dan mengatur ulang posisi satu lampu. Et voila, satu cahaya telah menjadi zombie, tetapi tidak sepenuhnya. Ini berperilaku persis seperti yang saya lihat dengan lampu IKEA yang terkadang kehilangan koneksi.

Lampu IKEA terdaftar sebagai tidak dapat dijangkau, tetapi masih merespons perintah grup. Juga karena masih dikenal oleh beberapa router lain, sepertinya mereka melaporkan melihat cahaya (itu 0x000B57FFFEC52C7D ):

11:49:33:392 ZDP Mgmt_Lqi_rsp zdpSeq: 190 from 0x000B57FFFE9BEBC3 total: 11, startIndex: 6, listCount: 3
11:49:33:392     * neighbor: 0x00158D00017028B0 (0xA3F5), LQI: 71, relation: 0x02 rxOnWHenIdle: 1
11:49:33:392     * neighbor: 0x90FD9FFFFE054F81 (0xC7BC), LQI: 41, relation: 0x02 rxOnWHenIdle: 1
11:49:33:393     * neighbor: 0x000B57FFFEC52C7D (0xD338), LQI: 69, relation: 0x02 rxOnWHenIdle: 1

dan

11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s

Terkadang, tampaknya komunikasi dimungkinkan:

11:49:44:901 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 11:49:44:902 0x0000 11:49:44:902 ]
11:49:44:902 add task 6636 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 213
11:49:44:902 Poll APS request 213 to 0x000B57FFFEC52C7D cluster: 0x0006
11:49:44:904 Idle timer triggered
11:49:44:951 Poll APS confirm 213 status: 0x00
11:49:44:951 Erase task req-id: 213, type: 19 zcl seqno: 89 send time 0, profileId: 0x0104, clusterId: 0x0006

terkadang tidak:

12:18:51:033 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:18:51:033 0x0000 12:18:51:033 ]
12:18:51:033 add task 4658 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 119
12:18:51:033 Poll APS request 119 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:19:02:077 Poll APS confirm 119 status: 0xA7
12:19:02:077     drop item attr/modelid
12:19:02:077     drop item attr/swversion
12:19:02:077     drop item state/bri
12:19:02:077 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task

Hanya ada sedikit informasi tentang apa yang salah. Apa arti status 0xA7 ..?

Ada informasi lebih lanjut yang mungkin membantu untuk mengetahui apa yang terjadi?

Ini terdengar seperti replikasi yang tepat dari masalah saya!

Apa arti status 0xA7 ..?

Lihat di sini: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Power mengayunkan cahaya

12:39:21:833 ZDP device announce: 0x000B57FFFEC52C7D, 0xD338, 0x8E
12:39:21:833 ZDP add fast discover for 0x000b57fffec52c7d
12:39:21:838 DeviceAnnce of LightNode: 0x000b57fffec52c7d Permit Join: 0
12:39:22:040 ZDP finished fast discover for 0x000b57fffec52c7d

Dan sepertinya dengan senang hati melaporkan statusnya

12:39:22:665 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:39:22:665 0x0000 12:39:22:665 ]
12:39:22:665 add task 10024 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 175
12:39:22:665 Poll APS request 175 to 0x000B57FFFEC52C7D cluster: 0x0006
12:39:22:753 Poll APS confirm 175 status: 0x00
12:39:22:753 Erase task req-id: 175, type: 19 zcl seqno: 167 send time 0, profileId: 0x0104, clusterId: 0x0006
12:39:22:920 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 1 s

kemudian:

12:39:26:760 ZDP active ep request to 0x000b57fffec52c7d
12:39:26:760 ZDP send request id: 0x07 to 0x000b57fffec52c7d
---
12:39:32:520 node 0000B57FFFEC52C7D leave wait state
12:39:32:521 ZDP active ep request to 0x000b57fffec52c7d
12:39:32:521 Incr. ZDP retry count 2 on item 7
---
12:39:44:655 add task 10125 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 60
12:39:44:700 Erase task req-id: 60, type: 21 zcl seqno: 171 send time 0, profileId: 0x0104, clusterId: 0x0004
---
12:39:45:405 create binding for attribute reporting of cluster 0x0000
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0000
12:39:45:405 create binding for attribute reporting of cluster 0x0006
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0006
12:39:45:405 create binding for attribute reporting of cluster 0x0008
12:39:45:405 queue binding task for 0x000B57FFFEC52C7D, cluster 0x0008
12:39:45:405 Force binding of attribute reporting for node HK houtlamp 2
---
12:39:50:760 Node 0x000B57FFFEC52C7D is known by 9 neighbors, last seen 28 s
---
12:40:06:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
12:40:08:905 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:11:881 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:11:881 0x0000 12:40:11:881 ]
12:40:11:882 add task 10241 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 205
12:40:11:882 Poll APS request 205 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:21:640 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:22:957 Poll APS confirm 205 status: 0xA7
12:40:22:957     drop item attr/modelid
12:40:22:957     drop item attr/swversion
12:40:22:957     drop item state/bri
12:40:22:957 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:22:957 Erase task req-id: 205, type: 19 zcl seqno: 175 send time 11, profileId: 0x0104, clusterId: 0x0006
12:40:22:957 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 78 s
---
12:40:28:904 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:30:904 binding/unbinding timeout srcAddr: B57FFFEC52C7D, retry
---
12:40:32:050 giveup binding srcAddr: B57FFFEC52C7D
---
12:40:33:568 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:39:481 ZDP skip fetch, node 0xB57FFFEC52C7D has unconfirmed requests [1]
---
12:40:42:987 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 10 s
---
12:40:43:276 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:40:43:276 0x0000 12:40:43:276 ]
12:40:43:277 add task 10380 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 157
12:40:43:277 Poll APS request 157 to 0x000B57FFFEC52C7D cluster: 0x0006
---
12:40:54:621 Poll APS confirm 157 status: 0xA7
12:40:54:621     drop item attr/modelid
12:40:54:621     drop item attr/swversion
12:40:54:621     drop item state/bri
12:40:54:621 0x000B57FFFEC52C7D error APSDE-DATA.confirm: 0xA7 on task
12:40:54:621 Erase task req-id: 157, type: 19 zcl seqno: 180 send time 12, profileId: 0x0104, clusterId: 0x0006
12:40:54:621 max transmit errors for node 0x000B57FFFEC52C7D, last seen by neighbors 22 s

itu berhenti bekerja. sampai .. 2 menit kemudian

12:42:10:529 LightNode removed 0x000b57fffec52c7d
12:42:10:530 Node zombie state changed 0x000b57fffec52c7d
---
12:42:39:361 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 0 s
---
12:43:06:904 add task 11002 type 21 to 0x000B57FFFEC52C7D cluster 0x0004 req.id 83
12:43:06:953 Erase task req-id: 83, type: 21 zcl seqno: 198 send time 0, profileId: 0x0104, clusterId: 0x0004
12:43:07:329 Node 0x000B57FFFEC52C7D is known by 0 neighbors, last seen 22 s
---
12:43:12:455 read attributes of 0x000B57FFFEC52C7D cluster: 0x0006: [ 12:43:12:455 0x0000 12:43:12:455 ]
12:43:12:455 add task 11026 type 19 to 0x000B57FFFEC52C7D cluster 0x0006 req.id 125
12:43:12:455 Poll APS request 125 to 0x000B57FFFEC52C7D cluster: 0x0006
12:43:12:498 ZDP status = 0x00 -> SUCCESS

Saya kira saya perlu membuat diri saya sniffer zigbee untuk mencari tahu apa yang terjadi melalui udara.

setelah ini berhenti bekerja lagi, kali ini agak lebih permanen.

Apa arti status 0xA7 ..?

Lihat di sini: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Terima kasih untuk itu! entah bagaimana itu yang kuharapkan ...

Saya mencoba memasangkan bohlam TRÅDFRI GU10 WS 400lm (7 bohlam) dengan bridge Philips Hue saya. Beberapa bohlam lain di jaringan menjadi tidak tersedia dan bohlam TRÅDFRI GU10 WS 400lm memiliki perilaku yang sama dengan Deconz, respons pada perintah grup tetapi tidak ada respons pada unicast.

Bohlam TRÅDFRI GU10 WS 400lm sepertinya bermasalah. Saya akan melakukan beberapa pengujian jika bohlam induvidual atau semuanya tidak berfungsi.

Sekarang saya telah melakukan beberapa pengujian. Kesimpulan saya adalah bahwa sebenarnya bohlam individu yang menyebabkan jaringan menjadi tidak responsif. Itu muncul almons langsung di Jembatan Hue dan hal mulai bekerja lagi segera setelah saya mematikannya. Jadi dari 7 umbi 3 terpengaruh . Saya akan melaporkan jika saya menemukan beberapa masalah baru.

@ MikaelHoogen , versi bohlam dan firmware mana yang Anda miliki?

Saya telah melihat masalah ini di v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS dan semua 3 panel FLOALT di gateway Ikea, HUE dan DeCONZ selama satu setengah tahun terakhir.
Saya yakin ini adalah masalah HW. Ini benar-benar acak node mana yang mati.
Di sini, di Norwegia, semua elektronik memiliki garansi 2 tahun. Akan mencoba membuka tiket dan mendengar apa yang mereka katakan.
Tentang FLOALT. Beberapa bulan yang lalu, Ikea menjalankan obral izin pada mereka. Mungkin itu untuk menyingkirkan semua v1?
Adakah yang pernah melihat FLOALT v2 di luar sana? (dengan driver sy5882 mungkin?)

Saya telah melihat masalah ini di v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS dan semua 3 panel FLOALT di gateway Ikea, HUE dan DeCONZ selama satu setengah tahun terakhir.
Saya yakin ini adalah masalah HW. Ini benar-benar acak node mana yang mati.
Di sini, di Norwegia, semua elektronik memiliki garansi 2 tahun. Akan mencoba membuka tiket dan mendengar apa yang mereka katakan.
Tentang FLOALT. Beberapa bulan yang lalu, Ikea menjalankan obral izin pada mereka. Mungkin itu untuk menyingkirkan semua v1?
Adakah yang pernah melihat FLOALT v2 di luar sana? (dengan driver sy5882 mungkin?)

Itu juga yang telah saya coba katakan selama beberapa waktu. Saya hanya memiliki masalah dengan bohlam Trådfri v1. Jembatan Philips Hue membantu tetapi node tetap tidak dapat dijangkau dari waktu ke waktu.

Beberapa hari yang lalu saya memutuskan untuk mengganti semua 12 bulps IKEA GU10 dengan versi baru (putih hangat).
Itu membuat masalah ini semakin buruk. Sekarang saya juga kehilangan suasana putih Hue GU10 dan warna Hue E14.

Saya telah menggunakan lampu deConz dan IKEA sejak awal saat mereka keluar. Saya memiliki sekitar 70 node di jaringan saya. Kebanyakan dari mereka adalah lampu IKEA. Saya juga memiliki beberapa Philips Hue (4 lampu) dan satu Osram. Sensor saya memiliki sedikit Ikea motion dan banyak sensor gerak Xiaomi.

Saya telah menjalankan pengaturan ini cukup lama dan tidak ada hari yang berlalu tanpa satu sama lain lampu macet sehingga saya perlu menyalakan siklus. Istri saya tidak senang dan saya juga tidak. Saya sangat dekat dengan membuang semua perangkat zigbee dan hanya pergi ke lampu sekolah tua biasa. Itu tidak berhasil. sangat mengecewakan. saya bertanya-tanya apakah orang lain melihat masalah yang sama menggunakan lampu Philips atau Osram murni atau hanya IKEA yang tidak berguna?

Saya telah menggunakan lampu deConz dan IKEA sejak awal saat mereka keluar. Saya memiliki sekitar 70 node di jaringan saya. Kebanyakan dari mereka adalah lampu IKEA. Saya juga memiliki beberapa Philips Hue (4 lampu) dan satu Osram. Sensor saya memiliki sedikit Ikea motion dan banyak sensor gerak Xiaomi.

Saya telah menjalankan pengaturan ini cukup lama dan tidak ada hari yang berlalu tanpa satu sama lain lampu macet sehingga saya perlu menyalakan siklus. Istri saya tidak senang dan saya juga tidak. Saya sangat dekat dengan membuang semua perangkat zigbee dan hanya pergi ke lampu sekolah tua biasa. Itu tidak berhasil. sangat mengecewakan. saya bertanya-tanya apakah orang lain melihat masalah yang sama menggunakan lampu Philips atau Osram murni atau hanya IKEA yang tidak berguna?

Dengan melihat semua orang memiliki masalah yang sama persis di utas ini dan pembuat deconz tidak dapat mengetahui masalah apa dengan lampu IKEA baunya dan terlihat seperti masalah firmware IKEA.

Banyak pengguna mengalami masalah serupa bahkan dengan hub IKEA. Jadi saya rasa ini bukan masalah unik yang berhubungan dengan deconz. Namun, jika seseorang dapat memperbaiki ini, "perbaiki / temukan solusi" itu adalah orang-orang di sini! <3

Saya memiliki masalah yang persis sama baik dengan keluarga maupun dengan pengaturan.

Menyedihkan :( terutama bahwa bahkan yang baru yang mereka jual hari ini masih memiliki masalah ini. Saya hanya tidak mengerti. Saya memiliki milik saya dari tahun 2017 jadi Anda pasti berharap mereka telah memperbaiki masalah sekarang. Saya harus mempertimbangkan untuk menghapus semuanya Tidak bisa diperbaiki disini, @manup pernah mengatakan sebelumnya bahwa ini adalah masalah di firmware perangkat jadi hanya IKEA yang bisa memperbaikinya dan karena mereka belum melakukannya belum ada harapan.

Deconz versi 2.05.69
Firmware Conbee II 264A0700

Ini tidak 100% sempurna dan yang saya perhatikan adalah lampu E27 Ikea (Rev1).
Ketika saya memiliki lampu Ikea ini dengan jembatan Philips Hue saya, mereka sangat kokoh jadi saya mungkin memindahkannya kembali ke Hue dan menyimpan mesh Zigbee ini murni CC2531 (firmware router) dan sensor Xiaomi.
Saya juga memiliki bohlam Innr (E14) dan SP120 tetapi ini masih baik-baik saja dengan Deconz.

Saya menggunakan Asisten Rumah dan Deconz untuk mengontrol sekitar 20 lampu Ikea (dan sejumlah sensor lainnya). Lampu utamanya adalah GU10 yang dikelompokkan berdasarkan 3 tempat ke satu lampu.

Saya telah menggunakan pengaturan ini selama lebih dari 15 bulan dan sejak musim panas ini saya mengalami masalah dengan satu atau lebih bohlam yang macet dan membutuhkan siklus daya, atau bahkan dicabut dan ditambahkan kembali ke jaringan Zigbee. Ini selalu GU10 yang ditentukan dalam grup ringan di HASS.

Beberapa minggu yang lalu saya membuat grup untuk lampu saya di Phoscon, dan mulai mereferensikan grup ini di HASS.

Setelah itu saya tidak punya satu masalah pun dengan bohlam macet dan membutuhkan siklus daya. Satu-satunya masalah yang saya lihat adalah ketika mematikan semua lampu di dalam ruangan saya sekaligus, terkadang seluruh grup Phoscon / Deconz tetap menyala.

Bagi saya, ini sepertinya masalah dengan API Deconz dan mungkin menangani beberapa bohlam secara berurutan di atasnya.

Saya juga memiliki masalah dengan perangkat Ikea (bohlam dan belakangan ini juga remote Symfonisk) menjadi tidak tersedia dan memerlukan penyandingan ulang dengan deCONZ. Saya sudah mengalami masalah ini selama 6 bulan atau lebih saya percaya. Tidak banyak yang bisa ditambahkan lebih dari yang saya kira itu terjadi lebih sering belakangan ini. Saya tidak memiliki bohlam GU10 hanya berbagai E27 dan E14 (dan berbagai remote). Tampaknya perangkat tertentu lebih rentan putus (mungkin tergantung pada bagaimana mereka menyatu atau serupa). Saya memiliki kira-kira 20 perangkat dengan jangkauan maksimal 5 m dari Conbee I dengan FW / Phoscon / deCONZ terbaru.

Saya juga memiliki masalah dengan perangkat Ikea (bohlam dan belakangan ini juga remote Symfonisk) menjadi tidak tersedia dan memerlukan penyandingan ulang dengan deCONZ. Saya sudah mengalami masalah ini selama 6 bulan atau lebih saya percaya. Tidak banyak yang bisa ditambahkan lebih dari yang saya kira itu terjadi lebih sering belakangan ini. Saya tidak memiliki bohlam GU10 hanya berbagai E27 dan E14 (dan berbagai remote). Tampaknya perangkat tertentu lebih rentan putus (mungkin tergantung pada bagaimana mereka menyatu atau serupa). Saya memiliki perangkat approx 20 dengan jangkauan maksimal 5 m dari Conbee I dengan FW / Phoscon / deCONZ terbaru.

Coba Deconz versi 2.05.69. Cukup stabil bagi saya dengan Ikea, Innr, dan Xiaomi

Saya memiliki masalah yang sama dan tiket buka https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Akan mengatakan bahwa ketika downgrade ke versi 2.05.67 telah membuat jaringan saya lebih stabil dari sebelumnya. Memiliki beberapa umbi yang menjadi tidak responsif, tetapi dua yang sama dan dapat hidup dengan itu. Kemarin semuanya berjalan seperti yang diharapkan.

Tampaknya menjadi masalah dengan campuran dari semua bagian yang mungkin, dan tentu saja membuatnya sulit ditemukan. Namun, versi deconz tampaknya menjadi bagian utama dari memiliki solusi yang stabil atau tidak.

Saya juga memiliki masalah dengan perangkat Ikea (bohlam dan belakangan ini juga remote Symfonisk) menjadi tidak tersedia dan memerlukan penyandingan ulang dengan deCONZ. Saya sudah mengalami masalah ini selama 6 bulan atau lebih saya percaya. Tidak banyak yang bisa ditambahkan lebih dari yang saya kira itu terjadi lebih sering belakangan ini. Saya tidak memiliki bohlam GU10 hanya berbagai E27 dan E14 (dan berbagai remote). Tampaknya perangkat tertentu lebih rentan putus (mungkin tergantung pada bagaimana mereka menyatu atau serupa). Saya memiliki perangkat approx 20 dengan jangkauan maksimal 5 m dari Conbee I dengan FW / Phoscon / deCONZ terbaru.

Coba Deconz versi 2.05.69. Cukup stabil bagi saya dengan Ikea, Innr, dan Xiaomi

Akan mencoba itu sebaik itu

Beberapa minggu yang lalu saya membuat grup untuk lampu saya di Phoscon, dan mulai mereferensikan grup ini di HASS.

Jadi saya akhirnya mendapatkan perangkat keras sniffing saya dan saya juga telah meretas Wireshark sedikit untuk menampilkan nama semua alamat ieee802.15.4 (yang membuatnya lebih mudah untuk membaca apa yang terjadi).

Bagaimanapun, pengetahuan saya tentang hal-hal zigbee tidak terlalu kuat, jadi mungkin saya mengajukan pertanyaan bodoh. Namun saya telah memeriksa beberapa batang kayu dan mudah-mudahan kami dapat melihat sesuatu yang menjelaskan perilaku serpihan lampu ikea.

Lihat log di bawah ini. Apakah itu tampak seperti perilaku 'normal'? Kedua lampu yang terlibat adalah Ikea ligth. DeConz pertama mengirimkan permintaan ke 'Garasi', merutekan melalui 'Zolder'. Kemudian 'Zolder' mencoba mengirimkannya ke 'Garage', tetapi tampaknya gagal (Mengapa?) Dan dicoba ulang 20 kali secara berurutan (sebagian besar dalam 3 ms). Akhirnya 'Zolder' menyerah dan mengirimkan link yang gagal kembali ke DeConz.

Haruskah seagresif ini dalam mencoba ulang transmisi?

Juga: Saya perhatikan bahwa DeConz dengan senang hati terus mengirimkan permintaan ke Garage melalui Zolder, meskipun tautannya jelas gagal. DeConz bahkan melakukan ini ketika Garage tidak lagi ada dalam laporan Status Tautan Zolder. Juga jika kadang-kadang Garasi ada dalam laporan Status Tautan Zolder, biayanya 7 baik yang masuk maupun keluar. Sebenarnya rute dari Garage ke DeConz tidak melalui Zolder ...
Mengapa DeConz terus merutekan melalui Zolder bahkan setelah pesan Gagal Tautan?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Oke, jadi saya telah meluangkan waktu membaca dokumentasi ZigBee silab (IKEA didasarkan pada chip silab).
Rupanya perilaku coba lagi persis seperti yang dijelaskan dalam dokumen.

Itu meninggalkan pertanyaan mengapa DeConz bersikeras menggunakan rute ini. Biaya link tinggi, ada balasan Link Failure dan rute tersebut tetap digunakan. Mengapa..?
(dan rute yang lebih baik tersedia ...)

Wawasan yang sangat berguna @djwlindenaar meskipun saya tidak dapat membantu Anda di level ini. Ini sedikit menegaskan kecurigaan saya. Saya memiliki jaringan yang berfungsi baik (dengan penurunan versi perangkat lunak) sampai saya mengalami pemadaman listrik yang tidak disengaja, dan seluruh rumah padam.

Setelah itu saya kembali lagi dan mengira saya mendapat rute yang buruk lagi.

Satu hal lagi. Kenapa deconz mengatur status bahkan jika perangkat yang sebenarnya tidak merespons? Sepertinya bohlam menyala di antarmuka tetapi secara fisik mati (masih bertenaga). Terkadang berfungsi untuk menyalakannya lagi (melalui perangkat lunak), terkadang berfungsi dengan siklus daya, tetapi sering kali tidak merespons sama sekali bahkan setelah siklus daya. Bohlam yang sama dapat tiba-tiba merespons lagi setelah beberapa saat

Beberapa perilaku yang lebih menarik (saya menunjukkan lampu yang sama, tetapi ini juga terjadi di tempat lain di jaringan saya)

• DeConz mengirim many-to-one route Route Request paket. Hasilnya adalah perangkat apa pun pertama-tama akan melakukan penemuan rute. Ini seharusnya memberi makan konsentrator (koordinator) dengan informasi tentang bagaimana mencapai perangkat itu. Tampaknya DeConz mengabaikan informasi ini untuk peruteannya ...

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7544        747.873     DeConz      DeConz      Zolder      Garage      ZigBee ZDP  Link Quality Request
7546        747.876     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7547        747.882     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7548        747.887     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7549        747.892     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7550        747.919     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7551        747.925     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7552        747.929     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7553        747.932     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7554        747.980     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7555        747.985     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7556        747.990     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7557        747.995     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7558        748.046     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7559        748.052     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7560        748.055     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7561        748.061     DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7563        748.066     Garage      Garage      Kerstver    DeConz      ZigBee      Route Record, Dst: 0x0000
7565        748.076     Garage      Kerstver    HK zoutlamp DeConz      ZigBee      Route Record, Dst: 0x0000
7567        748.084     Garage      HK zoutlamp DeConz      DeConz      ZigBee      Route Record, Dst: 0x0000

Paket terakhir berisi informasi tentang cara mencapai Garasi:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 2
    Relay Device 1: 0x731e[Kerstverli]
    Relay Device 2: 0xa3f5[HK zoutlam]

Tapi permintaan berikutnya ke Garasi dikirim lagi melalui Zolder

No.         Time        Source      Tran Dev    Recv Dev    Destination Protocol    Info
7569        748.112847  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7570        748.117327  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request
7573        748.126608  DeConz      Zolder      Garage      Garage      ZigBee ZDP  Link Quality Request

Saya tidak akan terkejut bahwa perilaku ini ada hubungannya dengan perilaku lampu IKEA yang tidak rata.

@manup , bisakah Anda mengomentari ini? Pernyataan Anda bahwa Source Routing akan membantu, sangat masuk akal.
Sebagai alternatif, saya berharap bahwa menggunakan informasi dari Route Record untuk memperbarui tabel perutean DeConz mungkin sudah merupakan peningkatan besar ...
Atau kita perlu mencari tahu mengapa DeConz ingin tetap menggunakan rute yang melaporkan masalah tautan / memiliki biaya perutean yang tinggi dibandingkan dengan alternatif.

Pengamatan lain ... Kedua perangkat relai dalam paket di atas sama-sama Colokan Xiaomi. Mereka tidak pernah ditanyai tentang Kualitas Tautan. Mengapa?
Mungkinkah DeConz menggunakan informasi dalam Link Quality Response untuk membangun tabel rutenya dan karena itu mengabaikan router yang cukup valid? Dengan kualitas tautan yang bagus ke beberapa lampu IKEA saya yang tidak menyenangkan ...

Apakah hanya melihat perilaku ini untuk perangkat ikea atau perilaku umum untuk mengabaikan rute optimal? Saya kira Anda memiliki sejumlah perangkat ikea yang layak?

Saya tidak yakin, saya perlu memeriksanya. Pertanyaan bagus.

Saya punya cukup banyak bohlam Ikea, ya.

Dalam pikiran saya, ini menjelaskan sebagian besar perilaku yang telah kita lihat dengan lampu IKEA yang tidak terjangkau. Meski hanya hipotesis untuk saat ini, untuk diverifikasi.

Melihat ke beberapa rute lain dan saya melihat perilaku yang sama.

Saya hanya melihat bahwa perangkat Xiaomi tidak mempertanyakan Kualitas Tautan semua merek lain. Saya kira ini adalah semacam daftar hitam ..?

Contoh perilaku perutean lainnya:

Dari DeConz, selalu:
DeConz --> WC Lamp --> Badkamer Ledstrip

Rute pulang sering berubah setelah permintaan rute banyak-ke-satu. Perhatikan bahwa dari sudut pandang geografis semua ini masuk akal ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Untuk lampu Garasi, saya melihat dari DeConz:
DeConz --> Zolder Noord Lamp --> Garage (rute sangat tidak stabil ..!)

Rute pulang yang saya lihat:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Sekarang ketika saya melihat tabel di laporan Status Tautan, rute di atas rute dari Garage ke DeConz Masuk akal:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz total biaya: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz total biaya: 4

dari DeConz ke Garage tidak:
DeConz --> Zolder Noord Lamp --> Garage total biaya: 12 (berdasarkan biaya masuk dari DeConz ke Zolder Noord Lamp)

@manup , bisakah Anda menjelaskan tentang algoritma biaya rute yang digunakan? Mengapa hal di atas masuk akal?

Beberapa analisis lagi hari ini ...
Di posting saya sebelumnya, Anda telah melihat bahwa lampu Garasi saya diarahkan melalui lampu Zolder saya. Keduanya bohlam IKEA. Tautan radio dari Zolder ke Garage berada tepat di tepi jangkauannya, jadi sering gagal.

Saat ini, meskipun lampu Garasi merespons perintah grup, ia tidak merespons perintah unicast. Sebenarnya terkadang ya dan terkadang tidak. Ini adalah perilaku yang harus familiar bagi mereka yang telah membaca / berkontribusi pada utas ini.

Saya dapat menemukan ini di log sniffing. Terkadang lampu Zolder dapat berkomunikasi dengan Garasi dan terkadang tidak. Kapan pun lampu Zolder tidak dapat berkomunikasi dengan Garage, ia melaporkan ini:

ZigBee Network Layer Command, Dst: DeConz, Src: Zolder No
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0xd6b7[Zolder Noo]
    Radius: 30
    Sequence Number: 65
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: SiliconL_ff:fe:c3:4a:3e (00:0b:57:ff:fe:c3:4a:3e)
    ZigBee Security Header
    Command Frame: Network Status
        Command Identifier: Network Status (0x03)
        Status Code: Non-tree Link Failure (0x02)
        Destination: 0x9e0c[Garage]

Paket ini seharusnya memberi tahu DeConz untuk mulai mencari rute lain untuk mencapai Garage, tetapi itu tidak terjadi. Paket berikutnya yang dikirim ke Garage kembali dirutekan melalui Zolder. Bagi saya itu adalah bug yang harus diselesaikan.
Paket berikutnya untuk Garasi ini diterima oleh lampu Zolder, tetapi lampu itu bahkan tidak mencoba mengirimkannya ke Garasi. Mungkin ini adalah perilaku firmware IKEA yang tidak baik, tetapi akar penyebab masalahnya adalah penolakan DeConz untuk mencari jalur alternatif.
Saya pikir jika rute tidak tersedia untuk jangka waktu yang lama, mungkin lampu Garasi kekurangan ACK pada level yang lebih tinggi daripada protokol 802.15.4 dan itu dapat menyebabkan firmware terputus atau bahkan macet. Dan saya setuju seharusnya tidak, tetapi akar masalahnya adalah DeConz menolak menemukan rute baru ke lampu Garasi.

Hari ini saya melakukan percobaan agar DeConz menemukan rute lain ke lampu Garasi, jadi saya memutus sambungan listrik dari lampu Zolder dan melihat log yang mengendus. Setelah beberapa kali mencoba, DeConz menyadari bahwa Zolder telah pergi dan terus mencari rute alternatif ke Garasi. Selanjutnya saya menghubungkan kembali Zolder dan setelah mengumumkan kehadirannya juga untuk Zolder, rute baru ditemukan. DeConz (belum) kembali ke perutean Garasi melalui Zolder.

Lucunya dalam situasi baru, DeConz sekarang berbicara langsung dengan lampu Garage, tidak ada peralihan router.
Zolder sekarang dicapai melalui rute melalui 2 router lain (meskipun itu jelas dapat dicapai langsung oleh DeConz), jadi menurut saya beberapa tabel (tabel tetangga?) Penuh di dalam firmware routing DeConz.

Mungkin ini terkait dengan penolakannya untuk membuat rute baru sebagai tanggapan atas rute yang gagal ..?

@manup , saya akan sangat menghargai setiap komentar dari Anda pada posting di atas. Atau setidaknya beri tahu saya cara berkontribusi pada solusi (selain mencari akar masalahnya).

Saya ingin membantu menciptakan solusi untuk masalah ini, karena mereka mengganggu saya. Jika Anda memberi akses ke kode sumber firmware, saya dapat berkontribusi secara langsung (meskipun itu bukan sumber terbuka). Saya tidak keberatan membantu Dresden Elektronik dengan cara itu :)

Kerja bagus selesai! 💪🏼
Semoga kami bisa mendapatkan perhatian dari pengembang untuk memperbaikinya. Tampaknya Anda memiliki penyiapan dan proses yang baik sehingga perbaikan akan dapat diverifikasi dengan cukup "mudah".
Sekarang saya mengerti perilaku yang saya lihat yang saya sebut sebagai "penyembuhan diri sendiri" dan mengapa beberapa lampu tiba-tiba bekerja.

Kerja bagus @djwlindenaar semoga @manup bisa melihat ini.

@manup ada komentar?

Terima kasih atas utas dan pekerjaan ini. Saya sendiri menjalankan firmware update 20 ikea bulb dan berumur satu tahun. Saya mengalami drop freeze atau bola lampu hilang sejak awal tetapi tidak terlalu sering. Itu menjadi lebih buruk dengan pembaruan deconz nanti. Saya memeriksa jaringan saya mengoptimalkannya dalam 2.4 lingkungan yang dikemas. Masih bohlam putus setiap hari dan membuat tombol atau sensor tidak berguna karena masih dialihkan melalui bohlam ini sehingga tidak mengirimkan pergerakan data apa pun. Saya perlu menyalakan siklus agar sensor tersedia lagi saat bohlam mulai mengarahkannya lagi. Semoga ini mendapat perhatian lebih. Itu membuat frustrasi.

Pengamatan lain ... Kedua perangkat relai dalam paket di atas sama-sama Colokan Xiaomi. Mereka tidak pernah ditanyai tentang Kualitas Tautan. Mengapa?
Mungkinkah DeConz menggunakan informasi dalam Link Quality Response untuk membangun tabel rutenya dan karena itu mengabaikan router yang cukup valid? Dengan kualitas tautan yang bagus ke beberapa lampu IKEA saya yang tidak menyenangkan ...

Permintaan tabel tetangga (alias ZDP Mgmt_Lqi_req) dinonaktifkan untuk perangkat Xiaomi karena mereka kebetulan tidak menanggapi pertanyaan ini setelah beberapa saat dan saya curiga bahwa kesalahan dalam firmware dapat memicu beberapa keadaan tidak valid atau lebih buruk.

Dengan demikian, pendorong utama untuk membatasi permintaan tertentu adalah untuk mencegah kesalahan pada firmware perangkat akhir dan untuk meniru perilaku gateway vendor terkait, beberapa hasil penyelidikan dapat ditemukan di https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / End-device-Polling

Sebagai catatan, query tabel tetangga hanya digunakan untuk membangun presentasi mesh visual dan tidak mempengaruhi operasi jaringan atau tabel routing.

Jadi saya akhirnya mendapatkan perangkat keras sniffing saya dan saya juga telah meretas Wireshark sedikit untuk menampilkan nama semua alamat ieee802.15.4 (yang membuatnya lebih mudah untuk membaca apa yang terjadi).

Bagaimanapun, pengetahuan saya tentang hal-hal zigbee tidak terlalu kuat, jadi mungkin saya mengajukan pertanyaan bodoh. Namun saya telah memeriksa beberapa batang kayu dan mudah-mudahan kami dapat melihat sesuatu yang menjelaskan perilaku serpihan lampu ikea.

Lihat log di bawah ini. Apakah itu tampak seperti perilaku 'normal'? Kedua lampu yang terlibat adalah Ikea ligth. DeConz pertama mengirimkan permintaan ke 'Garasi', merutekan melalui 'Zolder'. Kemudian 'Zolder' mencoba mengirimkannya ke 'Garage', tetapi tampaknya gagal (Mengapa?) Dan dicoba ulang 20 kali secara berurutan (sebagian besar dalam 3 ms). Akhirnya 'Zolder' menyerah dan mengirimkan link yang gagal kembali ke DeConz.

Haruskah seagresif ini dalam mencoba ulang transmisi?

Juga: Saya perhatikan bahwa DeConz dengan senang hati terus mengirimkan permintaan ke Garage melalui Zolder, meskipun tautannya jelas gagal. DeConz bahkan melakukan ini ketika Garage tidak lagi ada dalam laporan Status Tautan Zolder. Juga jika kadang-kadang Garasi ada dalam laporan Status Tautan Zolder, biayanya 7 baik yang masuk maupun keluar. Sebenarnya rute dari Garage ke DeConz tidak melalui Zolder ...
Mengapa DeConz terus merutekan melalui Zolder bahkan setelah pesan Gagal Tautan?

No.          Time         Source       Transmit Dev Receive Dev  Destination  Protocol     Info         
7580         748.356336   DeConz       DeConz       Zolder       Garage       ZigBee ZDP   Link Quality Request
7582         748.360218   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7583         748.363417   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7584         748.368857   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7585         748.373337   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7587         748.419739   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7588         748.424219   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7589         748.429019   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7590         748.434460   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7591         748.481181   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7592         748.485021   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7593         748.488541   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7594         748.492702   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7595         748.541983   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7596         748.545824   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7597         748.550944   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7598         748.556384   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7599         748.594786   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7600         748.597986   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7601         748.602787   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7602         748.608226   DeConz       Zolder       Garage       Garage       ZigBee ZDP   Link Quality Request
7603         748.640867   Zolder       Zolder       DeConz       DeConz       ZigBee       Network Status, 0x9e0c: Non-tree Link Failure

Tangkapan yang bagus! Di sini saya curiga firmware deCONZ harus menangani kesalahan ini dan mencoba lagi untuk menemukan rute baru. Saya akan memeriksa firmware jika kasus ini ditangani dan bagaimana. Saya dapat membayangkan bahwa rute tersebut sebenarnya dibuang tetapi jika pesan baru diterima melalui rute yang sama. Misalnya karena laporan atribut ZCL dari cahaya, entri tersebut tetap hidup.

Rute dapat dibuat hanya dengan menerima perintah apa pun dari bingkai yang masuk. Tetapi jika lompatan terakhir tidak mempertahankan lompatan sebelum itu (yang biasanya mereka lakukan), jalan kembali melalui lompatan yang sama tidak akan berhasil. Temuan Anda mungkin mencerminkan kasus itu.

Terima kasih.

Dalam hal ini, tidak pernah ada pesan dari lampu Garasi yang diterima melalui Zolder. Oleh karena itu saya tidak berharap DeConz terus menggunakan rute tersebut. Lihat posting saya yang lain ...

Kode Status: Kegagalan Tautan Non-pohon (0x02)

Sepertinya, kami mendapat pemenang, saya telah memeriksa sumber tumpukan Zigbee (R21, ConBee II) dan kode status ini sepenuhnya diabaikan. : -O Perlu memeriksa tumpukan AVR Zigbee juga, kemungkinan ada masalah yang sama di sana.

Sebagai perbaikan, saya ingin menangani kode ini dengan cara yang sama seperti status "Tidak Ada Rute yang Tersedia" ditangani, yang hanya untuk membebaskan entri rute dan membiarkan tumpukan menemukan yang baru.

Apakah Anda juga memiliki paket lengkap perintah yang sebelumnya dikirim dari koordinator ke lampu IKEA? Akan menarik jika bit rute temukan ditetapkan.

Berikut adalah bagian dari spesifikasi Zigbee tentang apa yang harus terjadi dalam kasus khusus ini:

Saat menerima bingkai perintah status jaringan oleh router yang merupakan tujuan yang dituju dari perintah di mana bidang kode status dari muatan bingkai perintah memiliki nilai 0x01 atau 0x02 yang menunjukkan kegagalan tautan, lapisan NWK akan menghapus entri tabel perutean sesuai dengan nilai bidang alamat tujuan dari payload bingkai perintah, jika ada, dan beri tahu lapisan berikutnya yang lebih tinggi tentang kegagalan menggunakan indikasi NLME-NWK-STATUS. menggunakan kode status yang sama.

Jadi perbaikan di atas harus berfungsi di sini untuk 0x02, 0x01 juga tidak ditangani, saya akan menambahkannya juga.

0x00 No Route Available  (already handled)
0x01 Tree Link Failure
0x02 Non Tree Link Failure

Hebat @manup! Anda menyebutkan Conbee II. Apakah perbaikan ini juga akan berhasil untuk Conbee I?

Ya, saya baru saja sumber tumpukan yang digunakan oleh ConBee I dan RaspBee. Masalah yang sama di sini, saya akan memasak versi firmware baru untuk pengujian hingga Selasa. Akan sangat bagus untuk mendapatkan umpan balik jika itu menyelesaikan setidaknya masalah perutean IKEA.

Perhatikan juga ada masalah lain yang tidak akan diperbaiki oleh ini, seperti lampu IKEA menjadi benar-benar sunyi dan bahkan tidak mendengarkan pemeran grup.

Secara tidak sengaja menutup masalah ini ... Dibuka kembali. Hebat bahwa kami membuat kemajuan dalam hal ini.

Saya kira @djwlindenaar lah yang bisa memberikan umpan balik setelah firmware baru tersedia karena perangkat keras sniffing diperlukan untuk ini?

Apakah Anda juga memiliki paket lengkap perintah yang sebelumnya dikirim dari koordinator ke lampu IKEA? Akan menarik jika bit rute temukan ditetapkan.

Saya tidak yakin saya mengerti pertanyaan Anda. Paket apa yang kamu cari? Dan ke lampu mana (Garasi atau Zolder)?

Ya, saya baru saja sumber tumpukan yang digunakan oleh ConBee I dan RaspBee. Masalah yang sama di sini, saya akan memasak versi firmware baru untuk pengujian hingga Selasa. Akan sangat bagus untuk mendapatkan umpan balik jika itu menyelesaikan setidaknya masalah perutean IKEA.

Perhatikan juga ada masalah lain yang tidak akan diperbaiki oleh ini, seperti lampu IKEA menjadi benar-benar sunyi dan bahkan tidak mendengarkan pemeran grup.

Saya akan mengujinya dengan pasti. Walaupun mungkin butuh waktu untuk sampai pada kesimpulan karena terkadang tidak ada masalah untuk waktu yang lama ...

Saya berpikir bahwa mungkin ada sesuatu yang memicu perilaku diam sama sekali. Saya sudah mengalami ini minggu lalu tetapi belum punya waktu untuk memeriksa log sniffer.

Saya di Raspbee btw.

Ya, saya baru saja sumber tumpukan yang digunakan oleh ConBee I dan RaspBee. Masalah yang sama di sini, saya akan memasak versi firmware baru untuk pengujian hingga Selasa. Akan sangat bagus untuk mendapatkan umpan balik jika itu menyelesaikan setidaknya masalah perutean IKEA.

Beri tahu kami, saya punya banyak masalah dan bisa mengujinya, meski tidak membuat mengendus.

Perhatikan juga ada masalah lain yang tidak akan diperbaiki oleh ini, seperti lampu IKEA menjadi benar-benar sunyi dan bahkan tidak mendengarkan pemeran grup.

Apakah Anda merujuk ini pada masalah bahwa perangkat lunak (deconz) melaporkan dan mengatur keadaan tetapi bohlam itu sendiri tidak merespons atau mengubah keadaan? Mungkin masalahnya tidak akan sama parahnya jika kita menyelesaikan masalah perutean.

Terima kasih telah melihat ini, sangat kami hargai!

Ya, saya baru saja sumber tumpukan yang digunakan oleh ConBee I dan RaspBee. Masalah yang sama di sini, saya akan memasak versi firmware baru untuk pengujian hingga Selasa. Akan sangat bagus untuk mendapatkan umpan balik jika itu menyelesaikan setidaknya masalah perutean IKEA.

Perhatikan juga ada masalah lain yang tidak akan diperbaiki oleh ini, seperti lampu IKEA menjadi benar-benar sunyi dan bahkan tidak mendengarkan pemeran grup.

Terima kasih manup! Saya akan meningkatkan ke fw baru begitu tersedia dan memberikan pembaruan.

Mungkinkah masalah ini juga terkait dengan masalah dengan mengendalikan tirai Ikea Fyrtur?

Satu lagi yang tampak aneh bagi saya. @ Manup , apakah ini bisa menjadi masalah juga?

Saya melihat banyak urutan seperti ini. Saya mulai menyelidiki ini, karena ini adalah komunikasi terakhir dari houtlamp sebelum berhenti merespons. DeConz mengkonfigurasi 2 item pelaporan atribut dan hampir pada waktu yang sama meminta keanggotaan grup. Di deConz log ini terlihat seperti di bawah ini.

Saya bertanya-tanya apakah ada bug dalam memilih nomor urut atau mungkin diperbolehkan (saya tidak tahu) dan perilaku ini memicu bug di firmware Tradfri. Ada satu permintaan dengan nomor 215 dan dua permintaan dengan nomor 216. Mungkinkah kita memiliki semacam kondisi balapan di mana penanganan permintaan oleh firmware tradfri menyebabkan kebocoran memori atau sebaliknya terputus karena dua permintaan dengan nomor yang sama di waktu yang hampir bersamaan? Shoud DeConz memiliki dua permintaan dengan nomor urut yang sama?

13:09:40:905 Force read attributes for node HK houtlamp
13:09:40:905 binding for cluster 0x0000 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 binding for cluster 0x0006 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:905 configure reporting rq seq 215 for 0x000B57FFFEDBFE18, attribute 0x0006/0x0000
13:09:40:906 binding for cluster 0x0008 of 0x000B57FFFEDBFE18 exists (verified by reporting)
13:09:40:906 configure reporting rq seq 216 for 0x000B57FFFEDBFE18, attribute 0x0008/0x0000
13:09:40:906 Force binding of attribute reporting for node HK houtlamp
13:09:40:908 add task 7435258 type 21 to 0x000B57FFFEDBFE18 cluster 0x0004 req.id 233
13:09:41:013 Erase task req-id: 233, type: 21 zcl seqno: 216 send time 0, profileId: 0x0104, clusterId: 0x0004
13:09:41:053 ZCL configure reporting rsp seq: 215 0x000B57FFFEDBFE18 for cluster 0x0006 attr 0x0000 status 0x00
13:09:41:077 ZCL configure reporting rsp seq: 216 0x000B57FFFEDBFE18 for cluster 0x0008 attr 0x0000 status 0x00
13:09:41:116 verified group capacity: 255 and group count: 2 of LightNode 0x000b57fffedbfe18
13:09:41:116 0x000b57fffedbfe18 found group 0x0001
13:09:41:116 0x000b57fffedbfe18 found group 0xFFF0

Melalui udara ini terlihat seperti: (sepertinya saya tidak melihat setiap paket melalui udara, yang aneh karena sniffer tepat di sebelah raspbee. Mungkin mereka dikirim begitu cepat sehingga tersesat dalam buffer overflow atau sesuatu di pelacak)

No.          Source       Transmit Dev Receive Dev  Destination  Protocol     Info
2196482      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL: Configure Reporting, Seq: 215
2196484      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196486      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196488      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196490      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196492      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196494      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 215
2196496      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196497      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196498      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196500      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196502      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee HA    ZCL Groups: Get Group Membership, Seq: 216
2196504      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196506      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       Route Record, Dst: 0x0000
2196508      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL: Configure Reporting Response, Seq: 216
2196510      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196511      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196512      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196513      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196515      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196517      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196519      HK houtlamp  HK houtlamp  DeConz       DeConz       ZigBee HA    ZCL Groups: Get Group Membership Response, Seq: 216
2196521      DeConz       DeConz       HK zoutlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1
2196523      DeConz       HK zoutlamp  HK houtlamp  HK houtlamp  ZigBee       APS: Ack, Dst Endpt: 1, Src Endpt: 1

Memang nomor urut tidak boleh sama dalam waktu singkat ini, saya akan periksa kodenya, sepertinya ada kenaikan yang hilang.

Ini adalah firmware uji pertama untuk ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Sekarang porting ini kembali ke firmware ConBee I / RaspBee, akan segera online.

Dan berikut adalah versi uji untuk ConBee I dan RaspBee dengan perbaikan kesalahan rute.
Semoga ini membawa beberapa perbaikan untuk menemukan rute baru saat kesalahan terjadi.

Untuk pengujian, saya pikir akan lebih baik jika hanya berjalan selama beberapa hari / minggu dan kita akan melihat apakah lampu masih berhenti merespons unicast. Dalam hal ini, silakan coba jika lampu masih bereaksi terhadap perintah grup atau mati sama sekali.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Untuk pengujian, saya pikir akan lebih baik jika hanya berjalan selama beberapa hari / minggu dan kita akan melihat apakah lampu masih berhenti merespons unicast. Dalam hal ini, silakan coba jika lampu masih bereaksi terhadap perintah grup atau mati sama sekali.

Dan ketika bereaksi terhadap perintah grup, tunggu beberapa hari untuk memverifikasi itu terus bereaksi terhadap perintah grup. Dalam kasus saya, ketika lampu hanya bereaksi terhadap perintah kelompok, segera kemudian mereka menjadi sunyi sama sekali.

Dan ketika bereaksi terhadap perintah grup, tunggu beberapa hari untuk memverifikasi itu terus bereaksi terhadap perintah grup. Dalam kasus saya, ketika lampu hanya bereaksi terhadap perintah kelompok, segera kemudian mereka menjadi sunyi sama sekali.

Saya telah melihat ini juga di masa lalu, mungkin mereka melakukan ini karena tidak ada unicast yang diterima lagi, waktu akan menjawabnya.

@manup Mungkinkah masalah ini terkait? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Mungkin ya, setidaknya status dapat dijangkau akan berubah menjadi salah juga saat rute terputus. Tetapi ini mungkin juga disebabkan oleh alasan lain.

Saya perhatikan bahwa ada firmware yang lebih baru untuk beberapa lampu ikea. Perubahan status log peningkatan jaringan / konektivitas dan manajemen kegagalan. Saya memperbarui 20 lampu ... Saya akan memberikan pembaruan jika membantu.

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Sayang itu tidak berisi tanggal rilis ...

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html

Sayang itu tidak berisi tanggal rilis ...

Tampaknya dirilis karena saya dapat mengunduh firmware 2.3.007 yang dijelaskan dalam catatan rilis.

Pasti sekitar Januari https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

bukan programmer nya. Saya kira saya tidak harus menginstal r21 pada conbee 2 dan menunggu? Ini adalah firmware beta?

Sedikit keluar dari topik: juga firmware baru untuk peredup Trådfri, meningkatkannya ke ZB3. Referensi silang # 2485, kita akan memiliki masalah yang sama untuk peredup ... Saya berharap sensor gerak model lama menjadi yang berikutnya ...

Dan berikut adalah versi uji untuk ConBee I dan RaspBee dengan perbaikan kesalahan rute.
Semoga ini membawa beberapa perbaikan untuk menemukan rute baru saat kesalahan terjadi.

Untuk pengujian, saya pikir akan lebih baik jika hanya berjalan selama beberapa hari / minggu dan kita akan melihat apakah lampu masih berhenti merespons unicast. Dalam hal ini, silakan coba jika lampu masih bereaksi terhadap perintah grup atau mati sama sekali.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Terima kasih, @manup , baru saja menginstalnya. Mari kita lihat apa yang akan terjadi.

Meskipun saya berharap ini akan membawa beberapa perbaikan, bagaimana perasaan Anda tentang firmware DeConz yang mengabaikan rute yang direkam (karena perutean mane-to-one)? Secara umum, saya telah melihat bahwa rute yang direkam jauh lebih logis daripada yang digunakan oleh firmware DeConz.
Meskipun saya dapat membayangkan mengaktifkan perutean sumber adalah pekerjaan besar, firmware DeConz masih dapat menggunakan informasi dari paket rekaman rute untuk memperbarui lompatan pertama ke perangkat. Mungkin hanya memeriksa apakah hop terakhir ke koordinator cocok dengan apa yang disimpan dalam tabel routing dan jika tidak, maka entri dalam tabel routing tidak valid. Saya tidak yakin apakah boleh mengganti entri dengan lompatan terakhir dari rute yang direkam, karena perangkat di sepanjang jalan mungkin mengabaikan informasi tersebut, tetapi setidaknya ini dapat memulai penemuan rute baru untuk node tersebut dengan firmware DeConz.

Apa pendapat Anda tentang ini?

Saya telah menginstal firmware pada raspbee saya, (saya memiliki 73 node kebanyakan ikea), akan melaporkan kembali temuan.

Memang nomor urut tidak boleh sama dalam waktu singkat ini, saya akan periksa kodenya, sepertinya ada kenaikan yang hilang.

@manup , Mungkin untuk membantu Anda menemukan masalahnya, saya melihat masalah itu lagi hari ini. Tampaknya ini terkait dengan 2 tindakan pelaporan konfigurasi yang sangat berdekatan. Urutan kedua: 183 dalam hal ini berbeda dari yang saya laporkan sebelumnya.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
39174           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 182
39180           DeConz          DeConz          Gang 1          Gang 1          ZigBee HA       ZCL: Configure Reporting, Seq: 183
39227           DeConz          DeConz          On/Off light 36 Badkamer ledstr ZigBee HA       ZCL: Read Attributes, Seq: 183

Masalah nomor urut harus diperbaiki di 2.05.74, yang sedang dibangun sekarang dan akan tersedia dalam beberapa jam.

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/33d8a8b349c9f4967e8b94ed2657e038406317c8

Dan berikut adalah versi uji untuk ConBee I dan RaspBee dengan perbaikan kesalahan rute.
Semoga ini membawa beberapa perbaikan untuk menemukan rute baru saat kesalahan terjadi.
Untuk pengujian, saya pikir akan lebih baik jika hanya berjalan selama beberapa hari / minggu dan kita akan melihat apakah lampu masih berhenti merespons unicast. Dalam hal ini, silakan coba jika lampu masih bereaksi terhadap perintah grup atau mati sama sekali.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Terima kasih, @manup , baru saja menginstalnya. Mari kita lihat apa yang akan terjadi.

Meskipun saya berharap ini akan membawa beberapa perbaikan, bagaimana perasaan Anda tentang firmware DeConz yang mengabaikan rute yang direkam (karena perutean mane-to-one)? Secara umum, saya telah melihat bahwa rute yang direkam jauh lebih logis daripada yang digunakan oleh firmware DeConz.
Meskipun saya dapat membayangkan mengaktifkan perutean sumber adalah pekerjaan besar, firmware DeConz masih dapat menggunakan informasi dari paket rekaman rute untuk memperbarui lompatan pertama ke perangkat. Mungkin hanya memeriksa apakah hop terakhir ke koordinator cocok dengan apa yang disimpan dalam tabel routing dan jika tidak, maka entri dalam tabel routing tidak valid. Saya tidak yakin apakah boleh mengganti entri dengan lompatan terakhir dari rute yang direkam, karena perangkat di sepanjang jalan mungkin mengabaikan informasi tersebut, tetapi setidaknya ini dapat memulai penemuan rute baru untuk node tersebut dengan firmware DeConz.

Apa pendapat Anda tentang ini?

Hmm aneh firmware seharusnya sudah menggunakan Catatan Rute ini untuk membuat Rute baru, perlu memeriksa kode di sini, tetapi jika memori saya melayani saya, ini diaktifkan beberapa waktu yang lalu.

Apa pendapat Anda tentang ini?

Hmm aneh firmware seharusnya sudah menggunakan Catatan Rute ini untuk membuat Rute baru, perlu memeriksa kode di sini, tetapi jika memori saya melayani saya, ini diaktifkan beberapa waktu yang lalu.

Saya melakukan hal ini dengan Zolder dan Garage (dari sejumlah pos belakang) dan saya mendapatkan perilaku ini:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163778          Garage          Kerstverlicht   DeConz          DeConz          ZigBee          Route Record, Dst: 0x0000
163779                                                                          IEEE 802.15.4   Ack

Catatan rute menunjukkan:

Command Frame: Route Record
    Command Identifier: Route Record (0x05)
    Relay Count: 1
    Relay Device 1: 0x731e[Kerstverli]

Komunikasi berikutnya dari DeConz ke Garage:

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
163788          DeConz          DeConz          Zolder          Garage          ZigBee          APS: Ack, Dst Endpt: 0, Src Endpt: 0

Jadi jelas tidak mengambil alih rute rekaman.

Apa yang saya perhatikan saat ini adalah, segera setelah saya melepaskan Zolder , DeConz segera dapat menemukan rute baru. Jadi mungkin beberapa tabel terkait perutean sudah penuh di dalam firmware DeConz. Mungkinkah ini benar? Seberapa besar tabel tetangga / perutean di firmware? Mungkinkah tabel penuh menghalangi adopsi rekaman rute baru?

Keberhasilan! Saya dapat mengkonfirmasi bahwa perilakunya sekarang setelah kegagalan tautan non-pohon, pencarian rute memang dimulai.

No.             Source          Transmit Dev    Receive Dev     Destination     Protocol        Info
173142          DeConz          Buiten - R sch  Tuin rechtsach1 Tuin rechtsach1 ZigBee ZDP      Bind Request, Basic (Cluster ID: 0x0000) Src: SiliconL_ff:fe:16:47:5f, Dst: dresden-_ff:ff:00:c4:9a
173143          Buiten - R sch  Buiten - R sch  DeConz          DeConz          ZigBee          Network Status, 0x35b7: Non-tree Link Failure
173144                                                                          IEEE 802.15.4   Ack
173206          DeConz          DeConz          Broadcast       Broadcast       ZigBee          Route Request, Dst: 0x35b7, Src: 0x0000

Masalah nomor urut harus diperbaiki di 2.05.74, yang sedang dibangun sekarang dan akan tersedia dalam beberapa jam.

33d8a8b

"swversion": "2.5.74",

: smile: Terima kasih @manup waktu respons yang bagus: 1st_place_medal:

Harap tunggu pembaruan ke 2.05.74, atau gunakan http://phoscon.de/app untuk menampilkan Aplikasi Phoscon. Kami baru saja melihat bahwa halaman offline gateway ditampilkan di beberapa halaman yang tidak semestinya, membangun kembali sekarang ~ 2 jam.

Memang nomor urut tidak boleh sama dalam waktu singkat ini, saya akan periksa kodenya, sepertinya ada kenaikan yang hilang.

Ini adalah firmware uji pertama untuk ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF

Sekarang porting ini kembali ke firmware ConBee I / RaspBee, akan segera online.

FW ini tidak bekerja untuk saya. Ini menunjukkan semua perangkat saya sebagai bergabung, tetapi tidak ada mesh yang dibangun. Tidak ada koneksi yang ditampilkan di GUI, juga tidak ada peralihan dari Phoscon yang berfungsi (2.05.74). Mem-flash Conbee II kembali ke 264A0700 dan semuanya berfungsi seperti yang diharapkan ...

Hmm aneh berapa lama itu berjalan?
Saya menjalankan firmware ini pada beberapa pengaturan sekarang tanpa masalah sejauh ini.

Hmm aneh berapa lama itu berjalan?
Saya menjalankan firmware ini pada beberapa pengaturan sekarang tanpa masalah sejauh ini.

Beberapa menit. Saya telah melihat beberapa aktivitas di beberapa perangkat (titik biru) tetapi tidak ada pembuatan tautan. Dan peralihan tidak berhasil sama sekali. Haruskah saya menguji untuk waktu yang lebih lama?

Mungkin perlu waktu beberapa saat hingga jala terbentuk, tetapi Anda akan melihat garis setelah 5–10 menit.

FW ini tidak bekerja untuk saya.

Sama di sini, Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Jaringan uji kecil dengan repeater Trådri, steker Trådfri, XBee, peredup Trådfri, 2 sensor gerak Trådfri (lama dan baru), dan sakelar On / Off Trådri. Gateway tampaknya tidak mengirim atau menerima lalu lintas apa pun dari perangkat apa pun. Melihat USB terputus di syslog. Semuanya kembali keren, setelah berkedip kembali ke 4A.
log.gz

Baru saja di-flash lagi untuk menguji:

• tidak ada garis di GUI (biarkan berjalan selama 15 menit)
• Koneksi USB tampaknya stabil
• Sakelar UBISYS C4 dan D1 masih berfungsi
• Tombol Tradfri tidak

@ ebaauw log menunjukkan bahwa koordinator hanya melihat dua tetangga dengan versi ini.

Mungkin itu ukuran jaringan. Saat ini saya hanya memiliki 40 perangkat yang diberdayakan di sini. Versi firmware ini memiliki dua perubahan lain yang mungkin menjadi penyebabnya, peningkatan ukuran buffer pesan (sejauh yang saya tahu sedikit berlebihan, akan menguranginya lagi) dan dan pengaturan daya TX yang sedikit lebih rendah.

Saya akan menyiapkan versi lain dengan pengaturan ini dihapus untuk melihat apakah itu berfungsi lebih baik.

Apakah Anda menggunakan kabel ekstensi USB, atau apakah ConBee II terhubung langsung?

Bagi saya ini berfungsi dengan baik di Raspbee ...

Pada RaspBee dan ConBee 1 hanya perbaikan Rute yang disertakan dalam versi baru (firmware berbeda).

log menunjukkan bahwa koordinator hanya melihat dua tetangga dengan versi ini.

Ya, dua perangkat akhir ditampilkan sebagai tetangga di GUI. Agak aneh, karena mereka menunjukkan terhubung ke router lain setelah menurunkan firmware ConBee II.

Apakah Anda menggunakan kabel ekstensi USB, atau apakah ConBee II terhubung langsung?

Sudah terhubung langsung sejak saya mendapatkannya. Ke port USB-2 di Pi, dengan XBee terhubung ke port USB-2 lainnya; tidak ada di USB-3. Koneksi telah stabil, kecuali ketika saya mengkonfigurasi ConBee II sebagai router (lihat # 2463).

Pada RaspBee dan ConBee 1 hanya perbaikan Rute yang disertakan dalam versi baru (firmware berbeda).

Belum mencobanya. Akan harus menunggu sampai nanti ...

Saya melihat cukup banyak paket pelaporan konfigurasi. Setelah sedikit mencari, tampaknya ini dikirim secara berkala setiap setengah jam. Apa alasan permintaan pelaporan konfigurasi ini diulang secara berkala?
@ ebaauw , apakah saya ingat benar bahwa Anda melakukan banyak penyelidikan ini terhadap perilaku koordinator IKEA? Apakah itu melakukan itu juga?

Saya perhatikan di de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

Saya menemukan sedikit bukti lain tentang perilaku perutean DeConz yang mengabaikan catatan rute banyak-ke-satu. Hal ini menyebabkan beberapa router harus mencari tahu perutean dengan cara 'kuno'.
(perhatikan saya memiliki beberapa gangguan devellish di paket 117130: wink :)

Rute untuk badkamer ledstrip , menurut DeConz, dimulai dengan On/Off light 36 yang jelas tidak tahu bagaimana menuju ke sana. Jadi itu memulai penemuan rute dan akhirnya menemukan itu dapat (hampir tidak, saya kira) mencapai ledstrip itu sendiri. Jalur kembali melalui Gang 1

Sepertinya On/Off light 36 lupa tentang Badkamer ledstrip setiap kali permintaan rute banyak-ke-satu diproses ...

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177114            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177115                                                                                    IEEE 802.15.4     Ack
177116            On/Off light 36   On/Off light 36   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177117            On/Off light 36   HK plafond ledstrip                 Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177118            On/Off light 36   HK zoutlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177119            On/Off light 36   Zoldertrap Lamp   Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177120            On/Off light 36   Kerstverlichting  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177121            On/Off light 36   HK stalamp        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177122            On/Off light 36   DeConz            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177123            On/Off light 36   HK houtlamp 2     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177124            On/Off light 36   Keuken links      Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177125            On/Off light 36   Keuken Rechts     Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177126            On/Off light 36   HK houtlamp       Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177127            On/Off light 36   Keuken mid        Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177128            On/Off light 36   Tuin linksvoor 2  Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177129            On/Off light 36   WC lamp           Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177130            0x6666            0x6666            0x6666            0x6666            IEEE 802.15.4     Data, Dst: 0x6666, Src: 0x6666, Bad FCS
177131            On/Off light 36   Gang 1            Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177132            On/Off light 36   Hal lamp          Broadcast         Broadcast         ZigBee            Route Request, Dst: 0xc520, Src: 0xde81
177133            DeConz            On/Off light 36   Badkamer ledstrip Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 55
177134                                                                                    IEEE 802.15.4     Ack
177135            Badkamer ledstrip Badkamer ledstrip Gang 1            DeConz            ZigBee            Command, Dst: DeConz, Src: Badkamer , Bad FCS
177136                                                                                    IEEE 802.15.4     Ack
177137            On/Off light 36   Voordeur          Broadcast         0xfcfd            ZigBee            Command, Dst: 0xfcfd, Src: On/Off li, Bad FCS
177138            Badkamer ledstrip Gang 1            DeConz            DeConz            ZigBee            Route Record, Dst: 0x0000

komunikasi selanjutnya:

No.               Source            Transmit Dev      Receive Dev       Destination       Protocol          Info
177366            DeConz            DeConz            On/Off light 36   Badkamer ledstrip ZigBee HA         ZCL: Read Attributes, Seq: 58

Coba lagi pada firmware ConBee II:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Versi ini memiliki pengaturan daya TX 0x264a0700. Buffernya masih besar (tetapi menurut peta mereka harus cocok dengan RAM) untuk memeriksa hanya satu hal pada satu waktu.

Saya mendapat kesalahan ini, setiap kali saya mencoba memperbarui ke firmware terbaru. Ada petunjuk kenapa?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) teknologi elektronik gmbh
Reboot perangkat / dev / ttyACM1 (ConBee II)
firmware deCONZ versi 26490700
R21B18 Bootloader
Ayat: 2.05
membangun: 22 Mar 2019
mem-flash 161378 byte: | ============================== |
verifikasi:.
Pembaruan flash gagal, CRC tidak valid. Silakan coba lagi.
rich710 @ RichHassPc01 : ~ $

Sudahkah Anda memverifikasi jumlah MD5 dari file yang diunduh? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Ya, saya telah memverifikasi, dan mengunduh beberapa kali, bahkan mencoba mengembalikan ke firmware lama, dan itu berjalan dengan baik, sampai sekarang. Sekarang saya terjebak dengan kesalahan ini, saya telah me-reboot NUC saya beberapa kali tetapi masih saya macet ketika flasher mencoba me-reboot ConbeeII saya.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] sandi untuk rich710:
GCFFlasher V3_13 (c) teknologi elektronik gmbh
Reboot perangkat / dev / ttyACM1 (ConBee II)

2139: Error: uart reset gagal, periksa ulangi

Perhatikan Anda menggunakan ttyACM1, saat Anda menggunakan

GCFFlasher -l

Ini akan menunjukkan nomor seri.
Anda dapat menggunakannya untuk memberikan nama perangkat yang lebih stabil dalam perintah.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(ganti dengan nomor seri perangkat Anda)

Maaf tidak berhasil, mungkin saya harus memindahkannya ke mesin Windows saya dan mencoba
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) teknologi elektronik gmbh
Jalan | Penjual | Produk | Serial | Tipe
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | FTDI generik
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) teknologi elektronik gmbh
Reboot perangkat (ConBee II)

2139: Error: uart reset gagal, periksa ulangi
rich710 @ RichHassPc01 : ~ $

Entah itu atau sebagai alternatif, Anda dapat mencoba mengikuti:

• Cabut ConBee II
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Pasang kembali ConBee II

Parameter -t memungkinkan GCFFlasher mencoba selama satu menit untuk memproses pembaruan.

Ini berfungsi untuk memperbarui firmware di windows, dan ketika saya mencolokkannya di NUC saya dengan ubuntu lagi itu terhubung. TAPI, setelah satu jam sekarang, baru saja terhubung ke 4 om node saya ..: S

Coba lagi firmware ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Tidak ada lagi USB yang terputus, tetapi deCONZ tampaknya cukup sering mendeteksi ulang ConBee II. Masih tidak ada lalu lintas.
log.gz

EDIT Untuk menghibur Anda, saya mencabut XBee dan menggunakan kabel ekstensi USB 10cm untuk menghubungkan ConBee II: tidak ada perubahan.

Coba lagi pada firmware ConBee II:

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Versi ini memiliki pengaturan daya TX 0x264a0700. Buffernya masih besar (tetapi menurut peta mereka harus cocok dengan RAM) untuk memeriksa hanya satu hal pada satu waktu.

Menguji versi baru Anda, tetapi setelah 10 menit masih tidak ada tautan yang ditampilkan ... Dengan FW yang stabil, semua tautan (router) yang baik di jaringan ditampilkan setelah sekitar 2 menit. Tombol tekan IKEA langsung bekerja, sementara dengan firmware uji itu tidak berfungsi sama sekali.

Hmm seram, terima kasih sudah mengujinya. Selanjutnya saya akan mencoba menurunkan ukuran buffer seperti yang disebutkan sebelumnya.
Masih saya bertanya-tanya mengapa ini berfungsi pada pengaturan saya. Dari tangkapan layar di atas saya hanya dapat mengatakan bahwa saya memiliki lebih banyak perangkat akhir daripada router.

@manup memiliki masalah yang sama setelah flash firmware, tetapi menekan perangkat reboot di deconz / restart deconz membuat tautan kembali.

Dan berikut adalah versi uji untuk ConBee I dan RaspBee dengan perbaikan kesalahan rute.

Tampaknya berfungsi dengan baik pada sistem pengujian Pi 3B + saya. Akan menunggu hingga akhir pekan ini sebelum memutakhirkan jaringan produksi saya.

@ ebaauw , apakah saya ingat benar bahwa Anda melakukan banyak penyelidikan ini terhadap perilaku koordinator IKEA? Apakah itu melakukan itu juga?

Saya menambahkan dukungan untuk sebagian besar perangkat Trådfri, tetapi saya belum dapat mengendus lalu lintas ZigBee ke / dari hub Trådfri. Ini hanya menggunakan pemasangan tautan sentuh, dan saya belum mencoba dan menangkapnya untuk memulihkan kunci jaringan. Artinya, dengan asumsi itu mungkin sama sekali.

Saya telah menjalankan FW baru di conbee 1 stick di ~ 40 node setup saya sejak rilis firmware baru dan telah bekerja dengan baik tanpa masalah! (Dalam gambar, node yang tidak terhubung kehabisan baterai atau tidak diberi daya)

Terima kasih kepada semua yang terlibat yang telah memecahkan masalah dan memperbarui kode. SANGAT dihargai! <3

Tidak bekerja untuk saya. Hampir tidak ada koneksi di grid. Telah menunggu sekitar 20 menit setelah restart.

Raspberry Pi 3 Model B Rev 1.2.0
Conbee II
versi 2.05.74
versi 26530700

77 node

3 Koneksi ke
1 saklar on / off TRÅDFRI
1 Xiaomi multi sensor
1 sakelar peredup Philips
Saya dapat memicu peristiwa dari sakelar dimmer philips.
Ini yang memiliki koneksi cukup dekat dengan tongkat Conbee. Tongkat itu terletak di garasi. Saya punya beberapa bohlam di garasi yang tidak ada sambungannya.

Tidak ada koneksi ke
Banyak bohlam ikea, baik E27 dan GU10
Banyak multi sensor Xiaomi
Banyak remote control Ikea TRÅDFRI
Dan node lainnya.

Log
feb 27 09:29:06 raspberrypi systemd [1]: Memulai deCONZ: gateway ZigBee - GUI / REST API.
27 feb 09:29:06 raspberrypi deCONZ [7204]: peringatan libEGL: DRI2: gagal untuk otentikasi
27 feb 09:29:06 raspberrypi deCONZ [7204]: peringatan libpng: iCCP: diketahui profil sRGB salah

Saat menurunkan ke 264A0700, itu mulai membangun mesh secara langsung.

@ ebaauw , apakah saya ingat benar bahwa Anda melakukan banyak penyelidikan ini terhadap perilaku koordinator IKEA? Apakah itu melakukan itu juga?

Saya menambahkan dukungan untuk sebagian besar perangkat Trådfri, tetapi saya belum dapat mengendus lalu lintas ZigBee ke / dari hub Trådfri. Ini hanya menggunakan pemasangan tautan sentuh, dan saya belum mencoba dan menangkapnya untuk memulihkan kunci jaringan. Artinya, dengan asumsi itu mungkin sama sekali.

Benar, maaf. Seharusnya memeriksa kesalahan git. Kode yang menyebutkan perilaku gerbang IKEA sebenarnya diperkenalkan di 48d2c39a267b5c6d025577eed7530be27932aa2c oleh @manup ...

@ Manup , apakah Anda benar-benar mengidentifikasi bahwa gerbang IKEA mengonfigurasi ulang atribut yang sering melaporkan ini? Mengapa konfigurasi ulang diperlukan; apakah lampu perlu diingatkan secara teratur?

Mengupgrade Conbee I ke beta FW dan deCONZ .74

Mesh segera terbentuk dan terlihat sangat bagus!

Terima kasih banyak untuk @djwlindenaar . Saya sangat terkesan bahwa Anda datang entah dari mana dan menemukan bug yang parah. Dan terima kasih @manup juga tentu saja sudah memperbaikinya ...

Conbee I dan 0,74 juga. Ikea FW ditingkatkan menjadi 2.3.007 (beberapa lainnya 2.x).
Peningkatan besar! Belum ada putus sekolah!

Terima kasih banyak kepada semua orang yang berkontribusi, mengembangkan, debugging, pengujian di thread ini dan seterusnya.

Sesuatu yang saya temukan dalam prosesnya:
Grup normal ON-OFF bekerja- cepat, tetapi setelah mengingat sebuah adegan (setelah waktu memudar) dan mematikannya lagi (<10 detik) lampu hanya padam di GUI (terlepas dari gui lama atau baru) Kemudian beberapa di antaranya menyala kembali (dalam gui) dalam grup sementara SEMUA lampu fisik masih menyala. Setelah menekan untuk kedua atau ketiga kalinya MATI terkadang menjadi gelap.

Tidak jarang memulihkan / membangun kembali adegan setelah peningkatan firmware
Tetapi terlepas dari apakah saya membangun adegan baru, atau mencoba memperbaiki yang lama, perilakunya tetap sama. Normal on-off tidak terpengaruh.

Saya menemukan bahwa itu berfungsi seperti biasa ketika saya menunggu lebih lama. Katakanlah 15-20 detik. Lalu lampu padam seperti biasa. Saya berasumsi deconz menjadi bingung seperti saat Anda mematikan lampu sampai memudar.

Tampaknya kami mendapat peningkatan penundaan hingga setiap status cahaya dilaporkan kembali dan penarikan kembali adegan dilakukan dalam dekonz atau dilaporkan berhasil sehingga tindakan lain dalam kelompok itu berfungsi sesuai keinginan. Sepertinya ini butuh waktu lebih lama sekarang. Dalam periode ini - Anda tidak boleh (lewat;)) - mematikan lampu. Ini tidak penting.

Saya menguji sedikit lebih jauh. Kami memiliki perubahan perilaku. Sebelumnya, jika bri diubah dengan kecepatan tertentu, atau adegan memiliki waktu transisi yang lebih lama, Anda dapat menginterupsi dengan perintah baru. Bahkan tindakan sebelumnya masih dilakukan, perintah berikutnya sudah antri. Sekarang hilang. Lampu lantai Egmy dioperasikan dengan sensor gerak. Sebelum mereka pergi, saya meredupkannya dan menunggu 10 detik sebelum mematikannya. Ketika saya memicu gerakan dan mengingat adegan saat mereka memudar, perintahnya hilang. Sebelumnya itu antri dan dieksekusi sesudahnya. Apakah ini karena. 74 atau firmware baru? Terima kasih

Conbee II saya tidak membuat mesh pada versi beta. Satu-satunya hal yang terpikir oleh saya yang dapat berbeda dari pengaturan "normal" adalah mengatur saluran ke 25. Kembali ke 264a0700 memperbaikinya

@realwax , saya rasa Anda terkena bug firmware Trådfri, lihat # 2068. Anda dapat dengan mudah memverifikasi ini dengan mengeluarkan perintah dengan waktu transisi yang lebih lama di GUI dan kemudian mengeluarkan perintah kedua.

Sebelumnya itu antri dan dieksekusi sesudahnya.

Apakah Anda memperbarui firmware ringan? Apakah Anda yakin Anda menggunakan cahaya yang sama? Plugin REST API tidak melacak waktu transisi setelah ia mengirim perintah ke lampu.

@ ebaauw Terima kasih telah membawa saya ke arah yang benar. Seperti yang dinyatakan IKEA untuk menyertakan peningkatan jaringan dan stabilitas dalam log rilis mereka, saya meningkatkan TRÅDFRI Lampe E14 WS opal 400lm saya ke firmware 2.3.007 (terbaru). Saya pikir ini mungkin meringankan beberapa masalah ini. Saya bertanya-tanya bagaimana IKEA melakukan trik di jembatan mereka sendiri karena ini adalah masalah kegunaan yang besar. Sekarang saya harus pergi untuk waktu transisi yang lebih cepat seperti yang Anda nyatakan di edisi lain. Saya mengalami ini sejak hari pertama tetapi semakin parah. Sekarang tidak hanya mempengaruhi ingatan adegan, tetapi juga mempengaruhi perubahan dengan transisi yang lebih lama dan itu baru ... Apa yang dapat saya lakukan? Flashing kembali ke fw lama hampir tidak bisa dilakukan, karena ini adalah perjuangan dengan deconz. Terima kasih Erik.

Saya bertanya-tanya bagaimana IKEA melakukan trik di jembatan mereka sendiri karena ini adalah masalah kegunaan yang besar.

Hub Trådfri jauh lebih aktif dibandingkan gateway deCONZ atau jembatan Hue. Pengontrol Trådfri (sakelar, peredup, tetapi juga sensor geraknya) mengontrol lampu secara langsung. Lampu Trådfri mengirimkan pemberitahuan push ke hub dengan perubahan status. Hub hanya dibutuhkan / digunakan untuk aplikasinya. Mungkin menjalankan beberapa alarm, tetapi tidak ada aturan untuk menangani peristiwa tombol atau sesuatu yang mewah.

Saya tidak yakin apakah aplikasi Trådfri bahkan mendukung penentuan waktu transisi yang lebih lama, tetapi pengontrol yang pernah saya lihat tidak. Anda mungkin tidak akan dapat mengirim perintah dari pengontrol lebih cepat dari waktu transisi default lampu. Dan jika Anda melakukannya sesekali, Anda mungkin mengira Anda tidak menekan tombol sepenuhnya.

@ ebaau begitu. Apa yang masih membingungkan saya adalah kenyataan bahwa saya dapat menghidupkan dan mematikan sekelompok E14 (menyediakan semacam disko ringan;)) dalam waktu 1 detik (on-off-on) itu berhasil! Tapi begitu saya menekan tombol mengingat adegan di deconz saya tidak bisa dan perilakunya menjadi aneh. Di sinilah saya ragu entah itu kesalahan IKEA. Mengapa saya dapat menghidupkan dan mematikan dengan sangat cepat, tetapi begitu saya mengingat sebuah adegan, saya terhenti setidaknya selama 5-10 detik?

Waktu yang diukur secara tepat (20 percobaan):
kelompok 8 E14
grup ON -> grup OFF - beralih waktu 1 detik
ingat adegan -> aktifkan -> MATI tidak merespons hingga 10-12 detik!

Saya memahami bahwa dengan penarikan kembali lebih banyak lalu lintas dihasilkan dan setiap bola lampu mendapat lebih banyak pesan, tetapi selisih 10 detik? Bahkan ketika saya mengubah bri dan ct untuk seluruh grup, saya dapat mematikannya dalam sekejap, tetapi sekali lagi penarikan itu seperti macet. Saya pikir ini tampaknya menjadi masalah deconz, bukan?

Saya bisa merekam video itu. ;) Mungkin saya kurang pengetahuan di sini, maka maafkan saya karena kurangnya pemahaman saya tetapi saya entah bagaimana frustrasi karena ini adalah perjuangan ...

Saya khawatir saya masih agak bingung tentang adegan. Seperti grup, mereka tidak ada sebagai objek di ZigBee, mereka hanya angka di mana perangkat (cahaya) menyimpan status. Pada penarikan kembali adegan, nomor tersebut dikirim, dan setiap perangkat memulihkan status dari memori non-volatilnya.

Bagian fuzzynya adalah tidak semua perangkat tampaknya menyimpan statusnya dengan benar saat menyimpan pemandangan: suhu warna terkenal dalam hal ini. Saya juga melihat hal-hal lucu yang menyimpan pemandangan saat cahaya masih dalam transisi. Dalam hal ini, sumber daya /scenes tidak sinkron dengan keadaan yang disimpan pada lampu, menyebabkan API merefleksikan status sumber daya alih-alih keadaan cahaya sebenarnya, yang hanya akan diperbarui saat lampu dinyalakan lagi. disurvei. Biasanya waktu transisi ditentukan saat mengingat adegan, tetapi tampaknya itu juga dalam status tersimpan.

Saya telah membuat skrip untuk penyiapan jaringan produksi saya (menggunakan ph ), sehingga saya dapat membuatnya kembali dengan mudah. Saya mengalami kesulitan untuk membuat skrip pembuatan adegan dengan cara yang dapat diprediksi. Saya akhirnya mengatur keadaan cahaya, tidur selama beberapa detik, menunggu keadaan menetap, menyimpan pemandangan, dan lagi tidur beberapa detik, menunggu keadaan disimpan.

Anda dapat mencoba dan membuat ulang adegan Anda, tetapi tidak ada jaminan ...

Saya bisa mereproduksi topik yang tidak sinkron sejak hari pertama. Saya terbiasa mendekonz dan kebutuhan konfigurasi ulang adegan dari waktu ke waktu. Sekarang lebih buruk. Saat ini saya perlu mengambil sumber dari deconz ke iobroker dan membangun kembali semua adegan saya di sana. Tapi ini banyak pekerjaan. Semoga ini diperbaiki. Bolehkah saya membuat masalah? Lampu tidak dapat diandalkan lagi saat menggunakan pemandangan ... - Saya juga mencoba membuat ulang. Saya melakukan adegan "tes" kemarin selain yang sudah ada tetapi tidak menunjukkan perilaku lain.

Tidak yakin apakah itu terkait tetapi setelah memutakhirkan Conbee I saya ke firmware beta dan deCONZ ke 0,74 butuh satu hari dan sekarang deCONZ kehilangan koneksi ke Conbee. Tidak pernah mengalami ini bertahun-tahun sebelumnya ... Tapi saya ingin menyebutkannya ... Log baru saja menyatakan mencoba lagi untuk menghubungkannya berulang kali ... Mulai ulang deCONZ menyelesaikannya ... (menggunakan kontainer buruh pelabuhan)

Saya hanya mencoba membuat ulang grup, semua adegan ... Dalam proses pembuatan, ada banyak hal yang salah. Saat menggunakan Phoscon dan pemilihan bohlam "ALL", nilai pemandangan tidak disimpan dengan benar. Bahkan lampu yang dikonfigurasi menunjukkan apa yang Anda inginkan, penarikan kembali tidak. Anda harus mengontrol setiap lampu sendiri bahkan ketika Anda menggunakan pengaturan yang sama. Terutama gui lama harus digunakan untuk memperbaiki kesalahan suhu warna dari warna yang salah disimpan. Sampai adegan "berfungsi", Anda harus mengulanginya beberapa kali, mungkin menyalakan dan mematikan lampu saat berada dalam proses konfigurasi adegan sehingga dapat disimpan dengan benar. Saya tidak memiliki banyak detail teknis di sini, tetapi saya ingin memberanikan Anda semua di utas untuk menguji adegan, pembuatan, penyimpanan, penarikan kembali, dan mematikan setelah penarikan kembali. Saya pikir ini kacau dengan lampu IKEA dan menjadi lebih buruk ... Mungkin dengan IKEA tapi saya ragu karena yang lainnya dan kontrol kelompok langsung bekerja seperti pesona dengan deconz.

Sekarang saya akan mengembalikan / menurunkan versi firmware ke 1.x dan melihat apakah itu berfungsi lebih baik. Saya akan melaporkan kembali.

BAIK. Kembali ke papan gambar. Kemarin 2 lampu IKEA mengambil cuti, hanya untuk kembali setelah menyalakan satu siklus. Tidak mengatakan bahwa bug yang diperbaiki bukanlah bug. Mereka. Bukan hanya yang menyebabkan masalah.

Saya melihat lebih dalam tentang hal pelaporan atribut. Saya bertanya-tanya apakah konfigurasi berulang dari atribut yang melaporkan setiap 30 menit (1800-an) menyebabkan hangupnya firmware ringan.
Saya melihat sedikit kode ini yang tampaknya tidak menangani rq.maxinterval == 0 secara eksplisit. Sekarang cara menangani kasus ini dengan benar agak sulit, karena rq.maxinterval == 0 berarti lampu hanya akan melaporkan perubahan, jadi tidak ada batas waktu 'baik' untuk kasus itu ... Mungkin implementasi saat ini baik-baik saja, meskipun Saya ingin tahu apakah ide yang lebih baik mungkin ada.

bool DeRestPluginPrivate::sendConfigureReportingRequest(BindingTask &bt, const std::vector<ConfigureReportingRequest> &requests)
{
<hidden>
        if (val.clusterId == bt.binding.clusterId)
        {
            // value exists
            if (val.timestampLastReport.isValid() &&
                val.timestampLastReport.secsTo(now) < qMin((rq.maxInterval * 3), 1800))
            {
                DBG_Printf(DBG_INFO, "skip configure report for cluster: 0x%04X attr: 0x%04X of node 0x%016llX (seems to be active)\n",
                           bt.binding.clusterId, rq.attributeId, bt.restNode->address().ext());
            }
 ```

I Did some experiments, including asking the IKEA lights to report `ONOFF` and `LEVEL` periodically instead of only when a change is made. The lights happily report their status periodically, so that may be an acceptable way to avoid the above issue. To be verified properly of course.

Anyway, while doing these experiments, I stumbled upon an actual bug. I noticed the magical Default Response Command being returned whenever the IKEA lights now report their attributes. So I looked into what that thing is. Apparently that is supposed to conclude an ZCL/APS transaction when requested. There's a bit in the ZCL packet which dictates whether or not it should be sent `Disable Default Response`.

For attribute reports these are handled nicely by deCONZ

Tidak. Sumber Waktu Mengirimkan Dev Terima Dev Tujuan Nonaktifkan Info Tanggapan Default
208134 10j 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL: Report Attributes, Seq: 15
208136 10j 43m 23.158s DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
208138 10j 43m 23.212s DeConz DeConz Gang 1 Gang 1 True ZCL: Default Response, Seq: 15

However for Configure Reporting Response command, deCONZ fails to send the Default Response. I'm not sure how the IKEA lights handle this situation, but it may be a cause for a memory leak. Remembering that the Default Response is a kind of closure of the transaction, it may be that the firmware only releases a certain amount of memory after it is received.

Tidak. Sumber Waktu Mengirimkan Dev Terima Dev Tujuan Nonaktifkan Info Tanggapan Default
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL: Konfigurasi Pelaporan, Urutan: 41
207949 10j 43m 8.481 Gang 1 Gang 1 DeConz DeConz False ZCL: Konfigurasi Tanggapan Pelaporan, Urutan: 41
207951 10j 43m 8.485 Gang 1 Gang 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1
207952 10j 43m 8.487 DeConz DeConz Gang 1 Gang 1 APS: Ack, Dst Endpt: 1, Src Endpt: 1
207954 10j 43m 8.493 Gang 1 Gang 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1

I'm going to test this hypothesis with this patch in place:
```diff
diff --git a/bindings.cpp b/bindings.cpp
index 9607b09..0c2b5fc 100644
--- a/bindings.cpp
+++ b/bindings.cpp
@@ -443,6 +443,12 @@ void DeRestPluginPrivate::handleZclConfigureReportingResponseIndication(const de
         allNodes.push_back(&l);
     }

+    // send DefaultResponse if not disabled
+    if (!(zclFrame.frameControl() & deCONZ::ZclFCDisableDefaultResponse))
+    {
+        sendZclDefaultResponse(ind, zclFrame, deCONZ::ZclSuccessStatus);
+    }
+
     for (RestNodeBase * restNode : allNodes)
     {
         if (restNode->address().ext() != ind.srcAddress().ext())

Saya melihat sedikit kode ini yang tampaknya tidak menangani rq.maxinterval == 0 secara eksplisit. Sekarang cara menangani kasus ini dengan benar agak sulit, karena rq.maxinterval == 0 berarti lampu hanya akan melaporkan perubahan, jadi tidak ada batas waktu 'baik' untuk kasus itu ... Mungkin penerapan saat ini baik-baik saja, meskipun Saya ingin tahu apakah ide yang lebih baik mungkin ada.

Ya, plugin REST API memeriksa apakah pelaporan atribut berfungsi. Jika tidak, ia mencoba untuk mengkonfigurasi ulang, dan, saya pikir itu juga kembali ke polling perangkat.

Saya Melakukan beberapa eksperimen, termasuk meminta lampu IKEA untuk melaporkan ONOFF dan LEVEL secara berkala alih-alih hanya ketika ada perubahan. Lampu dengan senang hati melaporkan statusnya secara berkala, jadi itu mungkin cara yang dapat diterima untuk menghindari masalah di atas. Untuk diverifikasi dengan benar tentunya.

Saya pikir kami menjalankan pengaturan itu untuk beberapa waktu. Itu diubah, bersama dengan polling tabel tetangga yang lebih jarang dan tidak lagi polling status, karena beberapa firmware Trådfri akan hang (memerlukan siklus daya lampu). Saya ragu bahwa pengaturan pelaporan benar-benar berkontribusi pada kerusakan firmware.

Ada sedikit dalam paket ZCL yang menentukan apakah harus dikirim Disable Default Response .

Saya tidak berpikir mengirim respons default akan sangat merugikan, ketika Disable Default Response bit disetel. Tidak mengirimkan respons default saat bit tidak disetel akan merugikan, karena perangkat yang menunggu respons mungkin menyimpulkan bahwa koordinator tidak lagi dapat dijangkau dan akhirnya meninggalkan jaringan.

Ada sedikit dalam paket ZCL yang menentukan apakah harus dikirim Disable Default Response .

Saya tidak berpikir mengirim respons default akan sangat merugikan, ketika Disable Default Response bit disetel. Tidak mengirimkan respons default saat bit tidak disetel akan merugikan, karena perangkat yang menunggu respons mungkin menyimpulkan bahwa koordinator tidak lagi dapat dijangkau dan akhirnya meninggalkan jaringan.

@ebaauw , memang. Itulah intinya. deCONZ gagal mengirim Default Response sebagai balasan untuk Configure Reporting Response . Kebetulan lampu IKEA meminta Default Response untuk Configure Reporting Response .
Jadi, seperti yang Anda katakan, mungkin itulah alasannya, ditambah dengan Configure Reporting Request setiap setengah jam, agar lampu IKEA menjadi awol.

Sekadar pengingat:
Bohlam Ikea (E27 & GU10 v1) terkadang menjadi tidak dapat dijangkau dan membutuhkan siklus daya saat dihubungkan ke jembatan HUE juga, sehingga masalah tertentu tidak hanya terjadi pada Conbee I / II
Dari 16 E27 dan 12 GU10 di jembatan HUE saya, saya akan mengatakan satu bohlam 'hang' per 1-2 minggu, kira-kira. Terkadang lebih lama, terkadang lebih cepat. Masalah ini diperbaiki dengan rilis firmware HUE terbaru selama satu setengah tahun terakhir.

@all Yang Tradfri versi firmware yang Anda gunakan?

Apakah Anda menggunakan 1.x atau 2.x? Dengan 2.x mereka memperkenalkan zigbee 3.0. Saya meningkatkan ke 2.x dan masalah dimulai. Lampu E14. Saya melihat peningkatan terkait kecepatan jaringan dan konektivitas. Tapi dua hal membuat saya memutar kembali 20 lampu mendesah "Soft on" tidak berfungsi lagi. Bohlam dinyalakan tanpa fade in. Adegan tidak berfungsi seperti dulu. Tepatnya berbicara setelah mengingat adegan waktu tunggu sebelum mematikan lampu atau mengingat szene berikutnya diperlukan jika tidak, deconz pergi asinkron dan sinkronisasi ulang ke hidup sementara bohlam tidak melakukan apa-apa.

Saya menghargai pengalaman Anda yang dibagikan dengan versi dan deconz 'kesempurnaan' dengan 2.x tampaknya tidak diberikan.

Apakah ada rekomendasi? FW v.? Selain masalah koneksi yang hilang dan masalah koneksi pada fw Ikea itu sendiri, tampaknya deconz dapat menangani 1.x lebih baik.

Terima kasih!

Saya menggunakan:

• Conbee 1 dengan firmware 0x26340500
• Deconz versi 2.05.73 (menggunakan container docker marthoc di Debian)
• ~ 60 node, kebanyakan IKEA Trådfri
• Conbee 1 (koordinator) TIDAK dipasang secara terpusat di rumah saya seluas 200 meter persegi. Sistem ini sangat bergantung pada roaming dan meshing.
• Stik Conbee 1 dipasang pada kabel ekstensi USB 0,5 meter dan dipasang di sisi rak tempat komputer berada agar memiliki lebih banyak ruang kosong untuk sinyal RF.

Sejak upgrade (hari yang sama dengan rilis) dari deconz firmware tongkat Conbee 1 telah bekerja seperti pesona ! Tidak ada masalah apa pun.

Meningkatkan jaringan produksi saya (RPi 3B +, stretch, RaspBee) menjadi 2.05.74 dan 0x26340500 kemarin. Tampaknya stabil, kecuali untuk masalah di bawah ini.

Tidak yakin apakah terkait, tetapi rute ke pengontrol tirai lumi.curtain saya hilang pagi ini. Laporan oleh pengontrol masih akan mencapai gateway. Rute tidak akan dipulihkan pada siklus daya pengontrol. Saya harus membuka jaringan dan menyalakan pengontrol, sebelum koordinator akan mencapainya lagi.

Juga, salah satu katup radiator Eurotronic Spirit saya tidak dapat dijangkau oleh deCONZ setelah memulai deCONZ, saat masih mengirimkan laporan. Power cycle TRV mengembalikannya, seperti biasa.

Saya tidak memiliki kesempatan untuk melakukan penyelidikan mendalam kali ini, tetapi kedua perangkat bermasalah sejak awal, menunjukkan gejala ini sesekali. Sama untuk buta IKEA Fyrtur saya. Saya akan terus memantau situasi dan melaporkan kembali jika mengalami lebih banyak masalah.

@tokopedia
Firmware mana yang Anda gunakan pada bohlam tradfri Anda? Ini membuat perbedaan bahkan di utas ini sehubungan dengan masalah koneksi yang hilang sejauh yang saya uji. Hasil saya adalah bahwa langkah-langkah yang diambil di sini meningkatkan pengoperasian lampu tradfri yang dioperasikan 1.x di Conbee 1. Tetapi jaringan 20 e14 dengan tradfri fw 2.3.x berantakan. Pengaturan waktu, adegan macet, dekonz mendapat, lampu mulai berkedip (hilang?), .. seperti yang dilaporkan di atas. Saya pikir ini adalah poin untuk dibahas dan disebutkan untuk mengeluarkan rekomendasi yang jelas tentang ikea fw untuk digunakan untuk pengalaman yang baik. Mungkin artikel git sudah ada. Tapi dari pengalaman saya jangan upgrade 😅

Jadi dari sudut pandang saya dan jam pengujian dan flashing. Terima kasih atas peningkatan untuk ikea fws 1.x! Apakah mungkin untuk mengurangi masalah saat ini ketika 2.x dioperasikan? Jika tidak, saat ini tidak akan mungkin untuk meningkatkan ke zigbee 3 dengan ikea. Sepertinya perilaku berubah dan mengoperasikannya dalam dekonz harus disesuaikan. Ini mungkin untuk dinilai atau ditangani oleh @ebaauw ?

Bersulang
Semoga hari Minggu menyenangkan 😊

@bayu_joo
Saya telah mencoba FW meningkatkan semua entitas saya ke FW terbaru. Berikut adalah daftar saya dari semua node (yang sedang aktif).

Menyetujui kekacauan dengan semua "bagian yang bergerak" pada saat yang sama mencoba untuk menemukan akar penyebab masalah.

@tokopedia

Terima kasih atas daftar Anda.

Melihat terutama pada router (lampu) saya melihat bahwa Anda beroperasi 2.3.007 pada E14 Anda. Dapatkah Anda mereproduksi daftar masalah saya. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Karena saya tidak menyadari peningkatan fw otomatis ke 2.3.x, jaringan saya bercampur dengan 1.x dan 2.x tidak terlalu baik. Saya meningkatkan secara manual ke 2.3.x dan kemudian menjadi lebih buruk. (Jaringan lebih cepat tetapi kegunaan masif dran dan, bohlam berkedip putus) Jadi saya dapat merekomendasikan jika Anda mengalami lampu berkedip pada e14 atau "kelambatan" pada scences yang menurunkan versinya ke 1.2 ... Saya akan tertarik untuk mendapatkan "resmi" / pernyataan profesional dari pengembang profesional kami di sini tentang ini. Saya cukup yakin ada saat deconz ditangani dengan 1,2 serupa dan itu diperbaiki. Saya merasa ini perlu dilakukan untuk 2.3.x juga atau Ikea mengacaukannya sendiri. Sulit untuk dikatakan karena saya tidak jauh ke dalam kode.

@bayu_joo
Saya menggunakan fitur otau deconz dan skrip pembaruan firmware untuk mengunduh file fw.
Saya tidak tahu mengapa E14 tidak diperbarui ... huhum.

Bagaimana cara Anda memperbarui / menurunkan versi bohlam secara "manual"?

Baiklah. Semuanya bekerja dengan baik dan sebagian besar perutean dilakukan oleh E27 dengan fw 2.3.x dan driver yang dipimpin panel Jormen dan FLOALT.

@tokopedia
Menarik bahwa Anda tidak mengalami masalah itu. Mungkin karena ukuran jaringnya. Saya memiliki 23 bohlam dari 20 e14 itu di 2.3.007. Saya menonaktifkan otau otomatis karena mengacaukan kegunaan saya dengan firmware baru. Melalui Gui Anda dapat menurunkan versi dengan tombol perbarui. Pilih firmware yang tepat terlebih dahulu, tekan update dan mungkin lagi. Status formulir dijeda masuk ke -> antri -> siaga -> mulai pembaruan firmware (persentase). Terkadang hang. Terkadang perlu reboot. Terkadang power cyle sudah cukup. Terkadang Anda perlu mendekatkan bohlam ke koordinator.

Sepertinya perilaku berubah dan mengoperasikannya dalam dekonz harus disesuaikan. Ini mungkin untuk dinilai atau ditangani oleh @ebaauw ?

Tidak yakin apa yang Anda maksud di sini. Saya menangani beberapa perbedaan antara firmware ZLL dan ZB3 untuk pengontrol (Trådfri remote dan Trådfri wireless dimmer), lihat # 2485. Ini berada di level APS di tumpukan ZigBee, dan ditangani oleh plugin REST API.

Masalah perutean dari topik ini berada pada level NWK, yang ditangani oleh firmware perangkat. Seperti semua orang di sini, saya tidak memiliki akses ke sumber firmware. Bahkan jika saya mau, tidak ada yang bisa saya lakukan, karena saya tidak tahu detail dari lapisan NWK dan MAC.

@bayu_joo
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Tepatnya berbicara. Saya memasukkan temuan saya dengan 20 E14 2.3.007 mesh di sini. Beberapa fitur hilang dan penarikan kembali adegan cukup banyak mengacaukan semuanya selama 10 hingga 15 detik dalam grup itu. Saya tidak tahu apakah ini hanya terkait firmware atau terkait dengan dekonz. Inilah yang saya maksud dengan perubahan yang harus dihadapi. Jadi untuk operasi harian saya melihat 2.3.007 sebagai no go. Contoh kegunaan yang diberikan: Sakelar sederhana memutar adegan yang dikonfigurasi di phoscon tidak berfungsi lagi ketika tidak ditekan dengan hati-hati yang berarti setelah rotasi adegan menunggu. Sementara di 1.x semuanya cepat dan bagus dengan 2.3.x macet.

Terima kasih, @manup , baru saja menginstalnya. Mari kita lihat apa yang akan terjadi.
Meskipun saya berharap ini akan membawa beberapa perbaikan, bagaimana perasaan Anda tentang firmware DeConz yang mengabaikan rute yang direkam (karena perutean mane-to-one)? Secara umum, saya telah melihat bahwa rute yang direkam jauh lebih logis daripada yang digunakan oleh firmware DeConz.
Meskipun saya dapat membayangkan mengaktifkan perutean sumber adalah pekerjaan besar, firmware DeConz masih dapat menggunakan informasi dari paket rekaman rute untuk memperbarui lompatan pertama ke perangkat. Mungkin hanya memeriksa apakah hop terakhir ke koordinator cocok dengan apa yang disimpan dalam tabel routing dan jika tidak, maka entri dalam tabel routing tidak valid. Saya tidak yakin apakah boleh mengganti entri dengan lompatan terakhir dari rute yang direkam, karena perangkat di sepanjang jalan mungkin mengabaikan informasi tersebut, tetapi setidaknya ini dapat memulai penemuan rute baru untuk node tersebut dengan firmware DeConz.
Apa pendapat Anda tentang ini?

Hmm aneh firmware seharusnya sudah menggunakan Catatan Rute ini untuk membuat Rute baru, perlu memeriksa kode di sini, tetapi jika memori saya melayani saya, ini diaktifkan beberapa waktu yang lalu.

@manup , apakah Anda punya waktu untuk melihat ini? Pagi ini saya menemukan situasi di mana saya menyalakan lampu (IKEA) yang berjarak 4 lompatan dari koordinator. Entah bagaimana peralihan router (juga IKEA) memutuskan tidak mengetahui rute ke lampu ini lagi. Saya benar-benar melihat lampu dengan senang hati melakukan tugasnya dalam mengarahkan lampu lain, melaporkan status tautan dan menanggapi Network Address Request dari deCONZ. Yang terakhir ini terjadi hanya karena itu adalah pesan siaran di jaringan ..!
Namun, router di antaranya secara diam-diam menjatuhkan frame unicast yang harus dirutekan ke cahaya ini. Router ini, tentu saja, tidak harus menjatuhkannya secara diam-diam, dan sekali lagi, deCONZ harus kuat melawan perilaku buruk ini.
Sementara itu, lampu dengan senang hati mengirim pesan rekaman rute ke deCONZ juga, yang tiba dan diabaikan oleh deCONZ.

Saya pikir harus ada beberapa logika yang harus memicu deCONZ untuk mempertimbangkan kembali rute itu dalam kasus ini. Terutama, ketika mendeteksi bahwa permintaan ZCL tidak dibalas. Yang pada akhirnya mengarah pada cahaya yang ditandai sebagai zombie. Penemuan yang mengikuti penandaan sebagai zombie sebenarnya mengarah pada balasan dari ligtht. Mungkin ketika penemuan untuk zombie dimulai, itu juga akan membatalkan informasi rute apa pun yang tersedia. Tetapi lebih baik lagi, jika sudah lebih awal, rute tidak valid ketika beberapa permintaan ZCL tidak dijawab (mungkin sudah pada yang pertama atau kedua).

Apa pendapat Anda tentang ini?

Firmware baru ini tidak menyelesaikan masalah saya.

Saya menggunakan Raspbee pada Pi dan Home Assistant terpisah (berjalan pada NUC) dan memiliki appx. 25 lampu tradfri. Sebagian besar GU10 digunakan dalam kelompok 3 orang.

Saya mengalami masalah besar dengan lampu tunggal dalam kelompok cahaya yang tidak responsif dan membutuhkan siklus daya untuk kembali lagi. Ini terjadi baik dengan Ikea FW v1 dan setelah meningkatkan bohlam ke 2.3.007.

Solusinya adalah mengubah konfigurasi saya dari mengelompokkan lampu di HASS menjadi menentukan grup lampu di Phoscon dan merujuk grup Phoscon sebagai lampu tunggal di HASS. Setelah perubahan ini, saya telah berjalan tanpa masalah selama beberapa bulan.

Saya ingin dapat melakukan pengelompokan di HASS jadi saya mengupgrade Raspbee saya menjadi 0x26340500 dan Deconz menjadi 2.05.74 dan mengubah konfigurasi saya kembali menggunakan light group di HASS. Setelah menjalankan ini selama seminggu, saya memiliki bohlam menjadi basi 3 atau 4 kali, dan sekarang saya beralih kembali menggunakan grup Phoscon lagi.

Saya pikir harus ada beberapa logika yang harus memicu deCONZ untuk mempertimbangkan kembali rute itu dalam kasus ini. Terutama, ketika mendeteksi bahwa permintaan ZCL tidak dibalas. Yang pada akhirnya mengarah pada cahaya yang ditandai sebagai zombie. Penemuan yang mengikuti penandaan sebagai zombie sebenarnya mengarah pada balasan dari ligtht. Mungkin ketika penemuan untuk zombie dimulai, itu juga akan membatalkan informasi rute apa pun yang tersedia. Tetapi lebih baik lagi, jika sudah lebih awal, rute tidak valid ketika beberapa permintaan ZCL tidak dijawab (mungkin sudah pada yang pertama atau kedua).

Saya masih menggunakan firmware baru dan menguji beberapa hal termasuk catatan rute, berharap mendapatkannya online minggu ini.

Apa pendapat Anda tentang ini?

Itu poin yang bagus, saya perlu memeriksa kode plugin inti dan REST-API di sini, karena menurut saya firmware harus menurunkan rute "kualitas" saat tidak ada ACK level APS yang diterima. APS ACK adalah flag yang ditetapkan secara opsional dalam permintaan ZCL / APS dan sering dinonaktifkan untuk menurunkan lalu lintas jaringan. Jadi ide kasarnya adalah kita harus mengaktifkan APS ACK jika plugin mendeteksi bahwa permintaan unicast menyebabkan waktu tunggu.

Mungkin bagian ini sudah ada, perlu memeriksa kode.

Namun, router di antaranya secara diam-diam menjatuhkan frame unicast yang harus dirutekan ke cahaya ini. Router ini, tentu saja, tidak harus menjatuhkannya secara diam-diam, dan sekali lagi, deCONZ harus kuat melawan perilaku buruk ini.

Lampu akan mengambil rute baru segera setelah penemuan rute baru dipicu. Jadi tujuannya harus mendeteksi rute yang rusak secepat mungkin (semoga APS ACK akan melakukan triknya) dan memicu penemuan rute.

Mesin negara untuk yang sudah ada di inti deCONZ (inilah yang mengarah ke siaran permintaan alamat NWK) ini berfungsi dalam kasus tautan satu-hop dan untuk lampu yang mengambil rute berdasarkan perintah masuk (balasan ke siaran). Siarannya bagus karena juga menghormati diubah ke alamat NWK karena alamat MAC disertakan. Saya akan mencoba mengirim unicast dengan APS ACK yang diaktifkan sebagai langkah selanjutnya jika tidak ada balasan yang diterima.

Sayangnya, kemarin saya harus menyalakan siklus bohlam IKEA E27 (White 1000LM, firmware v1) juga. Itu hanya bereaksi terhadap grup, tetapi bukan perintah unicast. Sepertinya masalah belum diperbaiki :(

(dan ya, saya menggunakan v74 dan firmware beta untuk RaspBee)

Lihat komentar di atas, perubahan selanjutnya mungkin membantu memulihkan perutean.

Apa pendapat Anda tentang ini?

Itu poin yang bagus, saya perlu memeriksa kode plugin inti dan REST-API di sini, karena menurut saya firmware harus menurunkan rute "kualitas" saat tidak ada ACK level APS yang diterima. APS ACK adalah flag yang ditetapkan secara opsional dalam permintaan ZCL / APS dan sering dinonaktifkan untuk menurunkan lalu lintas jaringan. Jadi ide kasarnya adalah kita harus mengaktifkan APS ACK jika plugin mendeteksi bahwa permintaan unicast menyebabkan waktu tunggu.

Mungkin bagian ini sudah ada, perlu memeriksa kode.

Sepertinya meskipun bit permintaan APS ACK disetel, deCONZ tidak melakukan apa pun dengan ack yang hilang (hanya sekali coba lagi dan kemudian tidak ada ...)

BTW houtlamp 2 adalah yang menjatuhkan paket yang diarahkan ke Tuin linksvoor 2

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
245915  10h 28m 42.108501s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245
245922  10h 28m 46.033452s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2    True    ZCL: Read Attributes, Seq: 245

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False

        .1.. .... = Acknowledgement Request: True

        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 107

Namun, router di antaranya secara diam-diam menjatuhkan frame unicast yang harus dirutekan ke cahaya ini. Router ini, tentu saja, tidak harus menjatuhkannya secara diam-diam, dan sekali lagi, deCONZ harus kuat melawan perilaku buruk ini.

Lampu akan mengambil rute baru segera setelah penemuan rute baru dipicu. Jadi tujuannya harus mendeteksi rute yang rusak secepat mungkin (semoga APS ACK akan melakukan triknya) dan memicu penemuan rute.

Mesin negara untuk yang sudah ada di inti deCONZ (inilah yang mengarah ke siaran permintaan alamat NWK) ini berfungsi dalam kasus tautan satu-hop dan untuk lampu yang mengambil rute berdasarkan perintah masuk (balasan ke siaran). Siarannya bagus karena juga menghormati diubah ke alamat NWK karena alamat MAC disertakan. Saya akan mencoba mengirim unicast dengan APS ACK yang diaktifkan sebagai langkah selanjutnya jika tidak ada balasan yang diterima.

Sebenarnya, houtlamp 2 tidak pernah melihat balasan untuk siaran address request . Pesan ke deCONZ dirutekan melalui tuin linksvoor 3 , jadi meskipun houtlamp 2 akan mengambil rute itu, itu tidak pernah mendapat kesempatan. Ini sekali lagi disebabkan oleh deCONZ tidak mengambil route record sebagai rute baru.

ZigBee Network Layer Command, Dst: DeConz, Src: Tuin link
    Frame Control Field: 0x1a09, Frame Type: Command, Discover Route: Suppress, Security, Destination, Extended Source Command
    Destination: 0x0000[DeConz]
    Source: 0x0ea5[Tuin linksvoor 2]
    Radius: 29
    Sequence Number: 51
    Destination: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)
    Extended Source: EnergyMi_ff:fe:e9:91:86 (d0:cf:5e:ff:fe:e9:91:86)
    ZigBee Security Header
    Command Frame: Route Record
        Command Identifier: Route Record (0x05)
        Relay Count: 1
        Relay Device 1: 0xc9fa[Tuin linksvoor 3]

Sekarang Tuin linksvoor 2 mengirim balasan ke siaran network address request dan berhasil, tetapi APS ACK dari deCONZ tidak pernah mencapai Tuin linksvoor 2 , karena dijatuhkan oleh houtlamp 2 . Jadi itu dikirim ulang beberapa kali sebelum menyerah. Itu akan memiliki peluang bagus untuk mengacaukan Tuin linksvoor 2 .

No. Time    Source  Transmit Dev    Receive Dev Destination Disable Default Response    Info
246199  10h 29m  1.496384s  Tuin linksvoor 2    Tuin linksvoor 3    DeConz  DeConz      Network Address Response, Status: Success, Address: EnergyMi_ff:fe:e9:91:86 = 0x0ea5
246201  10h 29m  1.502056s  DeConz  DeConz  HK houtlamp 2   Tuin linksvoor 2        APS: Ack, Dst Endpt: 0, Src Endpt: 0

Conbee 1 + fw terbaru + .74 tidak diputar 100%.
Memiliki beberapa hit / miss. Sepertinya bekerja lebih baik dengan 0,73 untuk saya, tetapi tidak 100%.

Jadi kembali ke papan gambar. Ini masih belum 100% ok dengan Conbee 1 fw (beta) baru.

Setelah beberapa hari beroperasi dengan 0,74 dan 26340500 pada Conbee 1 pada Tradfir E14 dengan firmware 1.2.221 dapat melaporkan bahwa:

Lampu IKEA menjadi lebih stabil dalam hal putus jaringan meskipun saya hanya memiliki satu bohlam yang hilang dalam 4 hari. Saya juga menemukan bahwa jika Anda stres karena jaringan zigbee yang dioperasikan deconz Anda berjalan pada E14 fw 1.2.221. Saya menjalankan skrip yang memudarkan bola dengan mengirimkan permintaan tunggal dengan perubahan bri setiap detik. Dengan cara itu saya kehilangan 4 bohlam dengan sangat cepat. Tapi siapa yang menginginkan itu;)

Masih belum terselesaikan:
Masalah dan perhatian yang masih saya miliki adalah Tradfri FW 2.3.x tidak berjalan dengan baik, atau tidak diimplementasikan dengan baik untuk digunakan dengan deconz. Tidak masalah untuk tetap menggunakan tradfri fw 1.2.x dan tidak menggunakan zigbee 3.0. Tetapi akan ada suatu saat hal itu tidak dapat dihindari. Atau umbi baru diturunkan lagi, saya takut.
Saya menemukan bahwa sekelompok 2-3 bohlam tidak menunjukkan masalah itu terlalu buruk sebagai sekelompok 4-8 ​​bohlam.
Saya melaporkan temuan saya di sini dan saya senang dan bersyukur jika diambil. Saya mencoba meningkatkan kesadaran di sini https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
karena saya dapat mereproduksi masalah ini hanya dengan mem-flash semua bohlam saya ke 2.3.x dan saya berharap Anda juga dapat melakukannya.

Intinya - itu membuat perbedaan tentang firmware tradfri mana yang digunakan dan yang sedang kita bicarakan. Ada perbedaan besar dalam kegunaan dan masalah yang dialami dan pengoperasian dengan deconz. Sementara 1.2.x fws lebih mungkin lebih tua dan bekerja seperti pesona di samping dropout yang diketahui, 2.3.x tidak kehilangan kegunaan seperti yang dijelaskan dalam masalah yang diangkat. Saya tidak bisa membayangkan saya adalah satu-satunya yang mengalami perbedaan FW ini.

Saya sekarang telah mengirim email ke dresden elektronik support dalam bahasa Jerman untuk meningkatkan kesadaran akan hal ini karena saya memahami beberapa dari Anda adalah penggemar hobi seperti yang dijelaskan @ebaauw di utas lainnya. Saya pikir sebagian besar pengembang adalah kontraktor elektronik dresden. Mohon maaf atas kesalahpahaman dan terima kasih atas kontribusi Anda. Saya ingin tahu tentang jawaban resminya sekarang.

Apakah firmware Conbee II juga sudah diperbaiki sekarang? Saya hanya melihat Conbee I di rilis. Terima kasih atas kerja keras Anda.

Hal ini sekali lagi disebabkan oleh deCONZ tidak mengambil catatan rute sebagai rute baru.

@djwlindenaar ternyata saya yang harus disalahkan disini, saya sudah mengecek kode Route Record yang ada di stack repository (ConBee I dan RaspBee I). Pada tahun 2018 saya telah menambahkan "perbaikan" (atau saya pikir begitu) untuk masalah serupa yang hanya menonaktifkan pembaruan alamat hop berikutnya pada catatan rute yang masuk.

Jika ingatan saya benar, masalah pada saat itu adalah kami memiliki jaringan campuran yang besar sekitar 150 node dan catatan rute tampaknya tidak berfungsi dengan benar. Jalur kembali baru tidak berfungsi dengan benar. Namun kode tersebut mungkin telah bekerja dengan perbaikan lain dari kode kesalahan perintah status NWK.

Saya mengembalikan ini sekarang, jadi catatan rute harus memperbarui rute ke jalur yang lebih baik.

Suka paragraf itu dari spesifikasi Zigbee:

Router ZigBee atau koordinator ZigBee dapat memelihara tabel routing. Informasi yang harus disimpan dalam entri tabel perutean ZigBee ditunjukkan pada Tabel 3-66. Penuaan dan penghentian entri tabel perutean untuk mengklaim kembali ruang tabel dari entri yang tidak lagi digunakan adalah praktik yang direkomendasikan; Namun demikian, di luar cakupan spesifikasi ini.

Yang pada dasarnya berarti setiap tumpukan menangani penuaan rute secara berbeda.

Jadi saya telah memeriksa cara kerjanya dalam kasus kami. Di Bitcloud, rute tumpukan Zigbee memiliki rute "rate", yang awalnya 1.

1. Pada transmisi NWK yang berhasil, laju akan bertambah jika di bawah maksimum yang ada
   (1 << 8) - 1 = 255
2. Pada transmisi NWK yang sukses, jika maksimum 255 tercapai, semua entri tabel routing menjadi "dinormalisasi"
   rate = (rate >> 1) + 1 (secara efektif dibagi 2, dengan minimum 1)
3. Pada transmisi NWK yang gagal, tingkat entri rute terkait ditetapkan sebagai:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. Pada terlalu banyak transmisi yang gagal, nilainya menjadi 0 dan rute dihapus

Artinya, tautan teratas akan diturunkan sebagai:

255  top rate
127  first failed transmission
63   ...
31
15
7
3
1
0    the record gets removed

Oleh karena itu dibutuhkan 8 perintah gagal sampai sebuah entri dihapus dan pencarian akan dimulai lagi.
Itu cukup baik di jaringan normal terutama ketika mereka berkembang menjadi 50 .. 100 node, sebuah rute tidak boleh dibuang terlalu dini.

Yang menjadi perhatian saya adalah poin (2) karena misalnya rute yang sangat baru atau yang tidak digunakan yang sering akan terdegradasi oleh node berkinerja tinggi yang sama sekali tidak terkait dengan tautan yang baik, misalnya lampu Philips Hue yang disurvei setiap beberapa detik akan trigger (2) cukup sering dikalikan dengan jumlah lampu di jaringan yang besar. Belum lagi pembaruan OTA aktif.

Saya pikir aman untuk mengubah (2) untuk tidak menurunkan (menormalkan) semua entri rute tetapi hanya 255 rute teratas yang terkait dengan transmisi yang berhasil. Ini akan mencegah kehilangan rute yang berfungsi dengan baik tetapi tidak sering digunakan dan dihapus pada transmisi NWK pertama yang gagal.

Saya akan membangun firmware baru dengan perubahan ini besok, juga untuk ConBee II kemungkinan besar sama berlaku di sana.

Saya mengembalikan ini sekarang, jadi catatan rute harus memperbarui rute ke jalur yang lebih baik.

Oke terdengar bagus. Saya menantikan untuk menguji!

Suka paragraf itu dari spesifikasi Zigbee:

Ya, saya rasa spesifikasi semacam ini membuat kami kesulitan membuat semua vendor hidup berdampingan dengan baik. :tersenyum:

Di Bitcloud, rute tumpukan Zigbee memiliki rute "rate", yang awalnya 1.

Saya tidak benar-benar memahami logika di balik aturan 2. Sepertinya ini adalah versi penuaan orang miskin. Yang berfungsi cukup baik jika semua node melihat jumlah lalu lintas yang sama, tetapi memang, jika tidak seimbang (yang menurut saya cukup umum), itu akan salah.
Saya perhatikan ZStack menggunakan bidang expiryTime aktual di tabel perutean mereka, di sebelah status byte.

3. On a failed NWK transmission the rate of the related route entry is set as:

Bagaimana sebenarnya yang ini bekerja?
Jika saya tidak salah, transmisi NWK yang gagal sebenarnya hanya berarti hop berikutnya, karena NWK hanya memeriksa 802.15.4 MAC ACK. Jadi untuk mengecek apakah transmisi end-to-end OK, kita harus mengandalkan APS ack. Apakah itu benar? Apakah ini berfungsi seperti ini di BitCloud?
Juga: jika bit permintaan ack di lapisan APS tidak disetel, apakah itu dianggap transmisi berhasil (karena tidak ada ack yang diharapkan) dan apakah itu menaikkan "laju" entri rute itu? Karena jika demikian, kita mungkin akan menembak diri sendiri dengan tidak meminta lapisan APS ACK setiap saat.

Jika hanya didasarkan pada kegagalan NWK, maka ini tidak akan membantu situasi bahwa router perantara tidak berfungsi dengan baik dan kita perlu menambahkan logika tambahan untuk memperhitungkan ACK lapisan APS tidak datang. Mungkin didasarkan pada logika serupa untuk mendeteksi router 'zombie', tetapi dengan terlebih dahulu membatalkan entri tabel rute untuk rute itu.

Versi firmware 0x26350500 untuk ConBee I dan RaspBee I tersedia untuk pengujian.

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26350500.bin.GCF

• Seperti 0x26340500 semua kesalahan rute status NWK ditangani
• Perbaiki degrasi rute yang tidak adil (lihat poin 2. di https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Perbaiki catatan rute tidak memperbarui lompatan berikutnya dari sebuah rute, perhatikan ini sekarang akan berfungsi tetapi hanya jika biaya rute saat ini lebih tinggi ketika catatan rute
• Memperbaiki permintaan APS yang gagal dengan APS ACK yang diaktifkan tidak menurunkan rute

Sekarang saya mencari di kode ConBee II untuk melihat apakah dan di mana perbaikan ini dapat diterapkan. Menutup 0x26520700 dan 0x26530700 dan mendasarkannya pada 0x264a0700 stabil saat ini.

Saya tidak benar-benar memahami logika di balik aturan 2. Sepertinya ini adalah versi penuaan orang miskin. Yang berfungsi cukup baik jika semua node melihat jumlah lalu lintas yang sama, tetapi memang, jika tidak seimbang (yang menurut saya cukup umum), itu akan salah.
Saya perhatikan ZStack menggunakan bidang expiryTime aktual di tabel perutean mereka, di sebelah byte status.

Setuju sekali, ini sekarang sudah diperbaiki sehingga hanya rute transmisi yang berhasil yang dinormalisasi saat laju mencapai maksimum. Cara penanganan pengatur waktu yang kedaluwarsa ini mungkin merupakan opsi lain tetapi memiliki kesulitan sendiri dalam skala besar. Saya pikir memiliki cara "rate" akan bekerja dengan cukup baik tanpa bergantung pada ukuran jaringan dan waktu.

Jika hanya didasarkan pada kegagalan NWK, maka ini tidak akan membantu situasi bahwa router perantara tidak berfungsi dengan baik dan kita perlu menambahkan logika tambahan untuk memperhitungkan ACK lapisan APS tidak datang. Mungkin didasarkan pada logika serupa untuk mendeteksi router 'zombie', tetapi dengan terlebih dahulu membatalkan entri tabel rute untuk rute itu.

Ini tampaknya menjadi kasusnya dan memang router yang berperilaku tidak semestinya, yang tidak mengirim perintah status NWK dengan kegagalan rute, dapat membuat rute mati tetap hidup. Ini sekarang diperbaiki di 0x26350500 tetapi bergantung pada perintah yang diaktifkan APS ACK. Yang seharusnya baik-baik saja dan dapat dikontrol oleh deCONz dan plugin REST-API.

Versi firmware 0x26350500 untuk ConBee I dan RaspBee I tersedia untuk pengujian.

Sudah di-flash, sekarang sedang diuji.

Ini sekarang diperbaiki di 0x26350500 tetapi bergantung pada perintah yang diaktifkan APS ACK.

Apa yang Anda lakukan sebagai tanggapan atas ACK yang hilang? Apakah Anda membagi dua nilai rate sama dengan transmisi NWK yang gagal atau lebih / berbeda? Karena menurut saya APS ACK yang hilang dianggap lebih parah dibandingkan dengan transmisi NWK yang gagal. Jika tidak, sekali lagi dalam kasus router yang tidak berfungsi, transmisi NWK yang berhasil dapat meningkatkan rate lebih banyak daripada APS ACK yang hilang menurunkannya.

Apa yang Anda lakukan sebagai tanggapan atas ACK yang hilang? Apakah Anda membagi dua nilai laju yang sama dengan transmisi NWK yang gagal atau lebih / berbeda? Karena menurut saya APS ACK yang hilang dianggap lebih parah dibandingkan dengan transmisi NWK yang gagal. Jika tidak, sekali lagi dalam kasus router yang tidak berfungsi, transmisi NWK yang berhasil dapat meningkatkan laju lebih dari APS ACK yang hilang menurunkannya.

Saya juga memikirkan hal yang sama, inilah yang terjadi dalam kasus itu:

• Transmisi NWK MAC ACK positif rate + 1
• Tidak ada APS ACK rate = rate / 4

Jadi tarifnya turun cukup cepat, mungkin agak terlalu agresif dan rate / 2 sudah cukup, tapi mari kita lihat cara kerjanya dalam praktik.

Bagus. Saya akan menjalankannya dan melaporkan kembali.

Saat ini juga pengujian stres dengan mengirimkan pesan unicast (OnOffwithLevel) ke cahaya yang cukup jauh di mesh, setiap beberapa detik.

Btw Saya juga mengubah kode plugin lainnya untuk meminta APS ACK di semua pesan.

Saya menjalankan Deconz dengan Rpi 3 M + menggunakan Home Assistant
Saat ini menjalankan 2.05.75 dengan Conbee I dan 26330500

Diketahui malam ini beberapa lampu tidak dinyalakan.
Mencoba menyalakannya secara manual, lihat log di bawah ini.
Memeriksa mesh VNC, itu adalah bagian dari jaringan mesh tetapi tidak bereaksi terhadap apa pun.
Node ini adalah saklar on / off outlet Tradfri.

Hal yang aneh disini:
_Saya DAPAT menyalakan sakelar saat mengaktifkan grup Deconz alih-alih sakelar individual._

19: 23: 58: 979 penundaan pengiriman permintaan 57 dt 0 ms ke 0x000D6FFFFEB1C9FF, ep: 0x01 cluster: 0x0004 onAir: 1
19: 24: 15: 744 Saluran saat ini 25
19: 24: 15: 776 Device TTL 3920 s flag: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 pada tugas
19: 25: 10: 547 0x000D6FFFFEB1C9FF kesalahan APSDE-DATA. Konfirmasi: 0xA7 pada tugas
19: 25: 15: 749 Saluran saat ini 25
19: 25: 15: 782 Device TTL 3860 s flag: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF kesalahan APSDE-DATA. Konfirmasi: 0xA7 pada tugas
19: 25: 49: 411 kesalahan 0x000D6FFFFEB1C9FF APSDE-DATA. Konfirmasi: 0xA7 pada tugas
19: 26: 12: 765 0x000D6FFFFEB1C9FF kesalahan APSDE-DATA. Konfirmasi: 0xA7 pada tugas
19: 26: 12: 765 kesalahan transmisi maks untuk node 0x000D6FFFFEB1C9FF, terakhir dilihat oleh tetangga 25 detik
19: 26: 15: 742 Saluran saat ini 25
19: 26: 15: 774 Device TTL 3800 s flag: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF kesalahan APSDE-DATA. Konfirmasi: 0xA7 pada tugas
19: 26: 48: 221 kesalahan pengiriman maks untuk node 0x000D6FFFFEB1C9FF, terakhir dilihat oleh tetangga 60 detik
19: 27: 03: 845 status node tersimpan dalam 9 ms
19: 27: 33: 634 sync () dalam 29789 md

Perbaikan terbaru ada di 26350500 ...

@djwlindenaar Saya menahan nafas menunggu hasil tes anda :-)

Sejauh ini bagus. Saya dapat melihat deCONZ dengan senang hati berpindah rute. :tersenyum:

Perbaikan terbaru ada di 26350500 ...

Maaf, salah membaca versi FW.
Saya ingin membantu pengujian, menggunakan add-on resmi Home Assistant Deconz, tidak yakin bagaimana cara memperbarui yang ini ke firmware beta. (pembaruan resmi adalah OTA)

Dear @manup , ada status update Conbee ii fw?

@manup , sepertinya tidak ada tindakan ke Many-to-One Route Failure (0x0c) . Saya berharap deCONZ melakukan lagi MTORR (kecuali jika sudah dalam proses). Saya menerima pesan-pesan ini secara teratur.

Command Frame: Network Status
    Command Identifier: Network Status (0x03)
    Status Code: Many-to-One Route Failure (0x0c)
    Destination: 0x499e[Tuin rechtsachter 2]

@manup , sepertinya route record masih belum selalu diambil alih oleh deCONZ. Sebagai contoh:

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default Response              Acknowledgement Request               Info
700766             13h 27m 35.628249s Tuin linksvoor 2   Tuin linksvoor 2   DeConz             DeConz                                                   Route Record, Dst: 0x0000
700784             13h 27m 39.591343s DeConz             DeConz             WC lamp            Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700786             13h 27m 39.597002s DeConz             WC lamp            Tuin linksvoor 1   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162
700788             13h 27m 39.600699s DeConz             Tuin linksvoor 1   Tuin linksvoor 2   Tuin linksvoor 2   True               True               ZCL Level Control: Move to Level with OnOff, Seq: 162

Cahaya Tuin linksvoor 2 dikirim langsung ke deCONZ , tetapi jalur dari deCONZ adalah melalui sevaral hop ...
Akan sangat membantu jika Anda dapat memberikan beberapa wawasan tentang proses pengambilan keputusan di deCONZ ke yes / no, terima rute dari pesan route record .

--- mengedit item di bawah ini, karena ada kesalahan dalam alasan saya. Sekarang semoga tidak: wink: ---

Karena itu, rute yang digunakan oleh deCONZ sebenarnya jauh lebih dapat diandalkan daripada komunikasi langsung ke Tuin linksvoor 2 . Ini membuat saya bertanya-tanya dan melihat ke dalam perutean banyak-ke-satu. Saya berpikir bahwa mungkin daya pancar Raspbee tidak ideal ...
Inilah alasan saya:

• Perutean banyak ke satu didasarkan pada penerimaan siaran
• Tidak seperti penanganan rute normal, biaya jalur masuk dan keluar maksimum diambil sebagai biaya untuk hop berikutnya
• Sekarang jika router atau koordinator jauh lebih baik dalam mentransmisikan (daya TX tinggi) daripada menerima (sensitivitas RX rendah), ini dapat menyebabkan perutean banyak-ke-satu tidak berfungsi dengan baik.

Hal terkait yang saya perhatikan adalah bahwa deCONZ tampaknya (sangat) optimis tentang biaya yang masuk di tabel rutenya. Ketika Tuin linksvoor 2 mengirim pesan ke deCONZ secara langsung, itu membutuhkan banyak percobaan ulang, sepanjang waktu. Sekarang jika saya melihat di tabel rute saya melihat yang berikut, dan saya tidak akan mengharapkan transmisi yang sulit dengan biaya masuk 4. Perhatikan bahwa pada dasarnya semua item dalam tabel rute memiliki biaya masuk yang jauh lebih rendah daripada biaya keluar.

Link 4
    Address: 0x0ea5[Tuin linksvoor 2]
    .... .100 = Incoming Cost: 4
    .111 .... = Outgoing Cost: 7

Jadi jika deCONZ kurang optimis tentang biaya masuk, kita mungkin melihat perilaku rute yang lebih baik. Atau jika kita ingin meningkatkan daya TX agar lebih seimbang (biaya yang sama untuk masuk dan keluar)
Atau jika kita akan menurunkan daya TX dari deCONZ, saya berharap itu akan membutuhkan rute melalui lebih banyak lompatan (biaya 7 perangkat akan keluar dari tabel rute), tetapi juga akan lebih mudah untuk pesan masuk yang akan diterima.

Daftar total dari pesan status tautan deCONZ:

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0010 = Link Status Count: 18
    Link 1
        Address: 0x0118[Buiten - R schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 2
        Address: 0x0143[HK stalamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 3
        Address: 0x05b5[HK houtlamp 2]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 4
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .100 = Incoming Cost: 4
        .111 .... = Outgoing Cost: 7
    Link 5
        Address: 0x1ad3[HK plafond ledstrip]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 7
        Address: 0x4b4d[Keuken mid]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x5693[Keuken Rechts]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x68c4[WC lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6c35[Buiten - L schuur]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 11
        Address: 0x731e[Kerstverlichting]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 12
        Address: 0x7d2a[0x7d2a]
        .... .011 = Incoming Cost: 3
        .101 .... = Outgoing Cost: 5
    Link 13
        Address: 0xa3f5[HK zoutlamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 14
        Address: 0xc7bc[Hal lamp]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 15
        Address: 0xc9fa[Tuin linksvoor 3]
        .... .011 = Incoming Cost: 3
        .111 .... = Outgoing Cost: 7
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .010 = Incoming Cost: 2
        .101 .... = Outgoing Cost: 5
    Link 17
        Address: 0xde81[On/Off light 36]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1
    Link 18
        Address: 0xefd5[Zoldertrap Lamp]
        .... .010 = Incoming Cost: 2
        .001 .... = Outgoing Cost: 1

Maaf atas keterlambatannya. Status: Kami masih bekerja keras untuk rilis baru, dan masih melacak bug di firmware yang tampaknya lebih kompleks dari yang kami kira. Sesuatu dalam penanganan nvram sepertinya tidak aktif. Kami juga mencari cara untuk mengatasi masalah pencacahan / startup usb.

Saya akan memposting pembaruan di sini segera setelah tersedia.

Pembaruan: masih kuat!

Saya rasa saya belum pernah melihat jaringan yang stabil ini. Saya sekarang telah mengubah berbagai aturan untuk menggunakan unicast alih-alih grup. Sekarang selama 2 minggu dan 0 lampu IKEA hilang.

(Harap saya tidak membawa sial sekarang)

Perhatikan bahwa saya mengubah plugin REST untuk meminta APS ack untuk semua permintaan.

Saya juga mengalami jaringan yang jauh lebih baik. Tidak 100%. Terkadang ada bohlam yang tidak merespons tetapi ketika saya mengganti bohlam IKEA secara manual, bohlam itu merespons. Saya juga melihat bahwa status bohlam sekarang adalah status fisiknya.
Namun, salah satu bohlam Osram saya berperilaku tidak responsif seperti yang dilakukan ikea sebelumnya. Positifnya, perilaku itu tidak seserius yang dialami oleh ikea.

Semoga ini bisa dikonfirmasi oleh orang lain atau temuan diidentifikasi.

Saya menjalankan Conbee 1, dengan FW 26350500 dan Deconz 2.05.75.
Ini pengalaman saya beberapa minggu terakhir

• Bekerja lebih baik tetapi tidak 100%
• Beberapa bohlam IKEA E27 TRÅDFRI saya E27 WS opal 980lm dengan fw 2.3.007 terkadang gagal menjawab perintah MATI
• Saya bisa mencoba mematikannya lagi dan biasanya berfungsi (tidak perlu power cycle)

@djwlindenaar bagus! Apakah perbaikan APS Anda untuk REST API termasuk dalam rilis .75? Asal tahu saja apakah itu bisa menjelaskan beberapa perbedaan pada posting sebelumnya ...

Tidak, tidak. Saya bahkan belum membuat permintaan tarik untuk itu. Dengan itu Anda bisa membangunnya sendiri. Saya akan melakukannya hari ini atau besok.
Saya juga dapat membagikan plugin API sisa bawaan, tetapi saya hanya memiliki satu untuk raspberry 3.

@tubalainen , saya akan memeriksa apakah itu dapat dijelaskan dengan APS ack. Saya juga tidak memiliki lampu 2,3 ​​IKEA.

Mungkin, ada masalah dengan perilaku coba lagi di deCONZ. Saya perlu melakukan percobaan untuk itu atau mungkin sudah ada di log sniff.

Jika Anda bisa mengendus, mengendus fenomena itu akan membantu. Saya dapat membantu menganalisis jika Anda tidak bisa.

Meningkatkan jaringan produksi saya (RPi 3B +, stretch, RaspBee) menjadi 2.05.74 dan 0x26340500 kemarin. Tampaknya stabil, kecuali untuk masalah di bawah ini.
Tidak yakin apakah terkait, tetapi rute ke pengontrol tirai lumi.curtain saya hilang pagi ini. Laporan oleh pengontrol masih akan mencapai gateway. Rute tidak akan dipulihkan pada siklus daya pengontrol. Saya harus membuka jaringan dan menyalakan pengontrol, sebelum koordinator akan mencapainya lagi.
Juga, salah satu katup radiator Eurotronic Spirit saya tidak dapat dijangkau oleh deCONZ setelah memulai deCONZ, saat masih mengirimkan laporan. Power cycle TRV mengembalikannya, seperti biasa.
Saya tidak memiliki kesempatan untuk melakukan penyelidikan mendalam kali ini, tetapi kedua perangkat bermasalah sejak awal, menunjukkan gejala ini sesekali. Sama untuk buta IKEA Fyrtur saya. Saya akan terus memantau situasi dan melaporkan kembali jika mengalami lebih banyak masalah.

Sangat sulit untuk mencatat masalah intermiten ini secara objektif, tetapi saya mendapat kesan bahwa 0x26350500 telah membawa peningkatan di sini. Terlepas dari perangkat yang disebutkan di atas, jaringan saya sangat stabil. Saya mengalami beberapa TRV menjadi tidak dapat dijangkau dari gateway, tetapi sebagian besar (hanya?) Setelah memulai ulang deCONZ. Saya tidak berpikir FYRTUR atau pengontrol tirai tidak mengalami MIA selama tiga minggu terakhir.

Perhatikan bahwa saya mengubah plugin REST untuk meminta APS ack untuk semua permintaan.

Saya mengaktifkan Tindakan APS di _Pengaturan Jaringan_ di GUI, tetapi saya tidak yakin apakah ini hanya berlaku untuk pesan yang dikirim oleh GUI, atau juga untuk plugin REST API.

Jika Anda ingin menjalankan dengan pull request di atas, Anda juga dapat melakukan checkout fork saya dan membangunnya: djwlindenaar / deconz-rest-plugin

@ ebaauw , sejauh yang saya tahu, ini hanya berlaku untuk perintah yang dikirim dari GUI

Saya memiliki sniffer yang berjalan terus menerus dan saya tidak mengetahui waktu jam dinding ketika masalah terjadi. Biasanya dengan info itu saya bisa menemukan paketnya dengan cukup mudah ...

BTW Saya telah mengubah banyak aturan saya (terutama yang sering memicu) ke unicast. Sejauh ini bekerja dengan baik. Saya juga telah menyalakan satu lampu IKEA yang terus-menerus mengubah kecerahan (setiap 4 detik atau lebih) selama 2 minggu terakhir. Yang itu juga masih bagus.

baik ... Saya baru saja melihat sesuatu yang funky di log saya. Saya menemukan bahwa tidak ada lampu yang saya nyalakan dengan daya akan melaporkan atributnya. Saya pikir saya terkena bug lain, tetapi ternyata tidak, meskipun menurut saya kami mungkin ingin menganggap ini bug.

Seperti yang saya sebutkan, saya menjalankan skrip untuk mengubah level cahaya setiap beberapa detik. Berpikir bahwa ini mungkin mempercepat masalah dengan lampu IKEA. Ternyata ini mengatur ulang penghitung d->idleLastActivity , yang mencegah tugas menganggur apa pun agar tidak dijalankan. Termasuk mengonfigurasi pelaporan atribut: rofl:

Apakah Anda mengatakan bahwa lampu IKEA kehilangan ikatan dan konfigurasi pelaporan atribut setelah siklus daya ?!

Sepertinya ... Bukankah mereka ..?

Masalah saya sekarang adalah sejak saya mengupgrade setup saya ke .75 dan 50500, container buruh pelabuhan saya kehilangan Conbee setidaknya sekali seminggu. Restart container akan membuat semuanya berjalan lagi ... SANGAT mengganggu

@djwlindenaar , tidak, saya rasa mereka tidak harus melakukannya. Sebagian besar perangkat yang pernah saya lihat menyimpan pengaturan ini dalam memori non-volatile. Saya kira standar ZigBee menyisakan ruang untuk kedua perilaku tersebut.

Sementara bohlam IKEA saya bekerja lebih baik sekarang, sayangnya, salah satu sensor Xiaomi saya (sensor suhu bulat) tidak merespons setelah beberapa saat. Saya akan mencoba mengumpulkan beberapa bukti dengan mengendus di hari-hari berikutnya.

Saya menjalankan Conbee 1, dengan FW 26350500 dan Deconz 2.05.75.
Ini pengalaman saya beberapa minggu terakhir

• Bekerja lebih baik tetapi tidak 100%
• Beberapa bohlam IKEA E27 TRÅDFRI saya E27 WS opal 980lm dengan fw 2.3.007 terkadang gagal menjawab perintah MATI
• Saya bisa mencoba mematikannya lagi dan biasanya berfungsi (tidak perlu power cycle)

@ Tubalainen Hai, Saya melihat perbedaan perilaku ikea dengan firmware 2.3.x dibandingkan dengan 1.2.x juga. Saya mencoba mengatasinya tetapi tidak mendapat perhatian. Saya menurunkan bohlam saya menjadi 1.2.x dan sekarang bekerja dengan sangat baik. Pada 2.3.x. Anda tidak dapat mematikan setelah pengulangan adegan untuk jangka waktu tertentu. Normal aktif bekerja. Perilaku aneh. Mungkin Anda ingin menguji dan berkontribusi di sini. ceria https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

Apakah Anda mengatakan bahwa lampu IKEA kehilangan ikatan dan konfigurasi pelaporan atribut setelah siklus daya ?!

Sayangnya mereka kehilangan ikatan mereka setelah siklus daya, kode diadaptasi beberapa waktu lalu untuk mengatasinya. Binding dan konfigurasi akan dipulihkan setelah lampu dinyalakan kembali juga jika tidak ada laporan yang diterima untuk sementara waktu, proses akan dimulai untuk memulihkannya.

@realwax akan diturunkan ke 1.2.x di semua bohlam E27 saya dan melaporkannya kembali. (membutuhkan waktu :)).

Kemarin dua lampu E27 (dengan 2,3x FW) tidak mati selama rangkaian pagi.

@ Tubalainen apakah Anda menggunakan perintah grup atau perintah unicast? (mis. melalui REST api, setel status melalui / groups / atau / lights /)

Saya pikir selama lampu bisa dijangkau, sebenarnya perintah unicast lebih bisa diandalkan. Jika perintah siaran grup tidak terjawab, perintah tersebut tidak akan dicoba lagi. Perintah unicast akan dicoba beberapa kali atau sampai terkirim.

@ Tubalainen apakah Anda menggunakan perintah grup atau perintah unicast? (mis. melalui REST api, setel status melalui / groups / atau / lights /)

Saya pikir selama lampu bisa dijangkau, sebenarnya perintah unicast lebih bisa diandalkan. Jika perintah siaran grup tidak terjawab, perintah tersebut tidak akan dicoba lagi. Perintah unicast akan dicoba beberapa kali atau sampai terkirim.

Saya menggunakan Asisten Rumah dan api RESt. Tidak tahu apa yang dilakukan Asisten Rumah ...

Dalam kasus saya ini adalah iobroker dengan plug in deconz dan Phoscon ... Jadi API lainnya. Masalah muncul saat menggunakan igroups. Pengingat adegan grup memicu bahwa grup tidak dapat dimatikan, atau dengan cepat diubah ke pengaturan adegan grup lainnya atau dimatikan dengan benar, terutama dalam waktu hingga 15 detik setelah ingatan adegan. Sepertinya deconz sibuk dengan perintah sebelumnya, atau bohlam 2.3.x fw membeku (yang saya ragu). Tidak dapat men-debug pada level zigbee untuk mendapatkan pemahaman yang lebih baik. Apakah fitur pengelompokan deconz merupakan lapisan virtual yang diterjemahkan dalam perintah uni cast atau dilakukan melalui opsi pengelompokan yang tersedia di gui / zigbee? Intinya saya menggunakan fungsi grup bawaan jika tidak saya perlu membangun lapisan virtual ini di iobroker dan tidak ada alasan karena fitur pengelompokan bagus. Jadi jika itu adalah pengelompokan ... Apa perbedaannya karena 100% dengan fw 1.2.x dan tidak dengan 2.3.x. Apa yang berubah? Apakah zigbee 2 mengapa mereka berperilaku berbeda.

@tubalainen Ya, itu banyak pekerjaan karena Anda mungkin perlu memulai ulang dari waktu ke waktu atau mendekatkan beberapa bohlam. Saya melakukannya dua kali dengan 20 e14 tradfri. Anda akan melihat peningkatan besar. Apakah Anda memperhatikan bahwa bohlam Anda dengan 2.3..x tidak menyala lembut. (fade in) lagi dan 1.2.x do?

TAPI semoga lebih banyak yang dapat mereproduksinya sehingga ikeas fw 2.3.x akan dapat dioperasikan di deconz karena akan ada saatnya kita perlu meningkatkan. Atau ganti bohlam. Padahal zigbee 2 akan menyenangkan juga.

Terima kasih atas usaha Anda!

@realwax @djwlindenaar @manup

Tadi malam satu lampu tidak mati sebagaimana mestinya (IKEA E27 dengan fw 2.3.x). Saya menguji untuk mengubah kecerahan pada lampu itu yang tidak mati dan langsung berubah ke pengaturan kecerahan yang saya pilih. Beberapa saat setelah mengubah kecerahan, cahaya tiba-tiba merespons dengan baik juga untuk perintah nonaktif.

Saya pribadi sekarang telah mengubah semua otomatisasi saya di Home Assistant untuk mengubah kecerahan terlebih dahulu, tunggu selama 2 detik lalu kirim perintah matikan.

Sejauh ini tingkat keberhasilan 100%.

Semoga ini bisa menjadi petunjuk untuk penyelidikan.

EDIT: Selalu masih lampu yang paling jauh dari koordinasi (tongkat Conbee) yang gagal mati. (lampu yang karena sifat pita frekuensi harus bertautan)

Hai semuanya!

Hanya ingin menyampaikan masalah saya ...
Setelah mengalami masalah stabilitas dengan tongkat ConBee II saya, saya memeriksa versi firmware. Itu 26530700. Saya kemudian menurunkannya ke 264a0700, dan setelah itu tidak ada aplikasi yang dapat melihat tongkatnya. Saya telah mencoba HomeAssistant dan deCONZ. OS host mengidentifikasi tongkat OK dan GCFFlasher berfungsi.

Hai semuanya!

Hanya ingin menyampaikan masalah saya ...
Setelah mengalami masalah stabilitas dengan tongkat ConBee II saya, saya memeriksa versi firmware. Itu 26530700. Saya kemudian menurunkannya ke 264a0700, dan setelah itu tidak ada aplikasi yang dapat melihat tongkatnya. Saya telah mencoba HomeAssistant dan deCONZ. OS host mengidentifikasi tongkat OK dan GCFFlasher berfungsi.

Setelah diturunkan ke 26490700 semuanya tampaknya berfungsi kembali ... Jala Zigbee stabil selama 24 jam sekarang ....

Ada pembaruan? Saya benar-benar ingin mengalihkan seluruh rumah saya ke Conbee II saya tetapi saat ini sangat tidak stabil. Rona saya bekerja dengan sempurna, Conbee ii tidak terlalu banyak 🥺

Pengalaman saya dengan deCONZ .75 terbaru dengan RaspBee FW 0x26350500 sejauh ini sangat bagus.

Perangkat saya:
Lampu 4xTradfri 980lu WS - FW 2.3.007
Lampu 17xTradfri 1000lu WS - FW 2.0.023
3xTradfri Colokan - FW 2.0.022
3xTradfri Putaran Jarak Jauh E1810 - FW 2.3.014
Sensor THP 4xAqara

Menemukan yang lain yang merusak firmware bohlam IKEA. (dan saya pikir itu bisa diperbaiki di deConz)

Saya melihat satu lampu tidak merespons pagi ini. Komunikasi terakhir ditunjukkan di bawah.

Sepertinya deConz menerima Tanggapan Keanggotaan Grup, tetapi entah bagaimana APS ACK (mengakui Permintaan Dapatkan Keanggotaan Grup) yang dikirim oleh lampu tidak diterima oleh deConz (saya juga tidak melihat MAC ACK). Akibatnya, deConz mengirim ulang permintaan tersebut. Permintaan ini memiliki nomor yang sama di ZCL, yang merusak firmware ringan.

Saya kira deConz dapat menganggap permintaan itu diakui segera setelah Tanggapan yang sesuai tiba dan menghindari memasukkan permintaan lain. Baik? Apakah ada API untuk plugin yang dapat dipanggil untuk membatalkan permintaan? @up?

Perhatikan bahwa bug khusus ini juga diselesaikan dengan tidak meminta APS ACK untuk permintaan ini, yang merupakan default di plugin REST API saat ini.

No.               Time              Source            Transmit Dev      Receive Dev       Destination       Disable Default Response            Acknowledgement Request             Info
74174             2h 48m 12.832154s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
74176             2h 48m 12.841977s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74178             2h 48m 12.847098s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                                                Route Record, Dst: 0x0000
74180             2h 48m 12.890302s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz            True              True              ZCL Groups: Get Group Membership Response, Seq: 32
74182             2h 48m 12.896074s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74183             2h 48m 12.899402s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74184             2h 48m 12.902460s HK houtlamp 2     HK houtlamp 2     DeConz            DeConz                              False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74185             2h 48m 12.904330s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       False             APS: Ack, Dst Endpt: 1, Src Endpt: 1
74190             2h 48m 14.186599s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2     True              True              ZCL Groups: Get Group Membership, Seq: 32
76346             2h 52m 41.998416s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
76354             2h 52m 43.668838s DeConz            DeConz            HK houtlamp 2     HK houtlamp 2                       True              Link Quality Request
202171            7h 39m 10.905361s HK houtlamp 2     HK houtlamp 2     Broadcast         Broadcast                           False             Device Announcement, Nwk Addr: 0x05b5, Ext Addr: SiliconL_ff:fe:c5:2c:7d

Menjalankan v2.05.75 dengan 0x26350500 selama beberapa minggu sekarang. Tampaknya sedikit lebih stabil daripada versi sebelumnya, tetapi saya kadang-kadang masih kehilangan rute ke Eurotronic Spirit TRVs saya, Fyrtur blind saya, dan pengontrol tirai Xiaomi lumi.curtain . Yang terakhir adalah router; yang lainnya adalah perangkat akhir. Semua TRV memiliki versi perangkat keras / firmware yang sama, tetapi beberapa TRV lebih sering menggunakan MIA daripada yang lain. Gejalanya konsisten: perangkat terus mengirim laporan ke koordinator, tetapi perintah dari koordinator hanya menghasilkan _Route Request_ yang tidak terjawab.

Saat ini mengendus dan menganalisis lalu lintas untuk TRV yang paling sering hilang. Laporan sampai ke koordinator dalam tiga lompatan, menggunakan dua lampu Hue di sepanjang jalan. Saya juga menangkap Permintaan _Data_ dari TRV ke cahaya pertama dalam perjalanan, jadi TRV tampak senang karena ini adalah induknya. Permintaan deskriptor kecocokan dari TRV untuk cluster OTAU tidak dijawab. Induk melaporkan lampu berikutnya dalam _Link Status_, tetapi bukan TRV (karena ini perangkat akhir?).

Pesan _Link Quality Response_ menunjukkan tabel tetangga yang terdiri dari 20 entri, tetapi TRV tidak ada di antara mereka. Sensor pintu Xiaomi (yang telah stabil selamanya) adalah. Anehnya juga koordinatornya, namun laporan dari TRV ke koordinator disampaikan melalui router lain (yang juga ada di tabel tetangga).
Oke, sekarang koordinator juga masuk di _Link Status_ dan laporan selanjutnya dari TRV langsung diteruskan ke koordinator.

Power mengayuh TRV. TRV mengirimkan MAC _Data Request_ ke (mantan) induk; router merespons dengan _Rejoin Response_ yang meneruskan alamat NWK lama TRV sebagai alamat baru. TRV kemudian menyiarkan _Device Announcement_ (MAC unicast ke induk; induk meneruskan sebagai siaran MAC). TRV mengirimkan Permintaan Batas Waktu Perangkat _End_ ke induk; induk mengirimkan _Update Device_ ke koordinator yang memberitahukan bahwa TRV telah bergabung kembali dengan aman. Induk sekarang juga mengirimkan _Route Reply_ ke _Route Request_ koordinator. Dalam urutan _Link Quality Response_ berikutnya, TRV disertakan.

Saya akan terus menjalankan sniffer, semoga bisa menangkap momen di mana TRV hilang lagi.

Pada catatan yang mungkin terkait: salah satu colokan pintar innr SP120 saya masih mengira itu adalah induk untuk tombol Hue, yang saya gabungkan sebentar ke jaringan produksi saya sambil menambahkan dukungan. Tombol tersebut telah digabungkan ke jaringan pengujian saya selama beberapa minggu sekarang, dan saya telah menyalakan steker beberapa kali. Apakah saya perlu mengatur ulang steker ke setelan pabrik agar melupakan anak yang hilang?

@manup , lama sekali sejak pembaruan apa pun baik dalam kode dan info tentang apa yang sedang terjadi. Bisakah Anda memberi kami pembaruan tentang kemajuan tim Anda tentang masalah stabilitas dan jika Anda berani juga dengan jadwal yang diharapkan.

Saya menemukan masalah lain dalam perilaku perutean deConz.

Dalam kasus ini, deConz mencoba merutekan pesan ke Hal lamp melalui Tuin linksvoor 3 . Tetapi melihat laporan Link Status dari Tuin linksvoor 3 tidak mengetahui tentang Hal lamp . Dan ternyata juga tidak tahu bagaimana menjangkaunya melalui routing. Tentu saja lampu itu (IKEA) harus berperilaku sendiri dan merespons dengan pesan kegagalan, tetapi tidak dan kami tidak dapat mengubahnya.
Namun, deConz menyimpulkan bahwa Hal lamp adalah zombie tanpa ada upaya untuk menemukan rute baru menuju cahaya itu. Tidak yakin bagaimana itu berinteraksi dengan kode perutean (baru), tetapi entah bagaimana itu tidak menurunkan rute itu cukup cepat untuk mencegahnya ditandai sebagai zombie. (BTW sebenarnya tidak, lihat selanjutnya ...)

Ini menyebabkan masalah sementara yang diselesaikan sendiri setelah beberapa menit (yang tentu saja sama sekali tidak dapat diterima). Karena Hal lamp memutuskan untuk mengirim laporan atribut, yang tidak menerima APS ACK dan oleh karena itu memulai proses Route Request . Hanya sekarang, setelah ini selesai, deConz mengubah rutenya menjadi Hal lamp dan komunikasi dilanjutkan seperti biasa.

Saya bertanya-tanya berapa lama waktu yang dibutuhkan jika lampu tidak memutuskan untuk mengirim pesan ke deConz. (Perhatikan bahwa di jaringan saya, saya menjalankan lampu IKEA dengan pelaporan atribut reguler untuk cluster Nyala / Mati dan Level setiap 5 menit)

No.                Time               Source             Transmit Dev       Receive Dev        Destination        Disable Default R  Acknowledgement Request               Info
392213             13h 31m 26.050526s Tuin linksvoor 3   Tuin linksvoor 3   Broadcast          Broadcast                                                Link Status
392241             13h 31m 26.182875s DeConz             DeConz             Tuin linksvoor 3   Hal lamp           True               True               ZCL Level Control: Move to Level with OnOff, Seq: 252

Command Frame: Link Status
    Command Identifier: Link Status (0x08)
    .1.. .... = Last Frame: True
    ..1. .... = First Frame: True
    ...1 0000 = Link Status Count: 16
    Link 1
        Address: 0x0000[DeConz]
        .... .111 = Incoming Cost: 7
        .100 .... = Outgoing Cost: 4
    Link 2
        Address: 0x0118[Buiten - R schuur]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 3
        Address: 0x0143[HK stalamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 4
        Address: 0x05b5[HK houtlamp 2]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 5
        Address: 0x0ea5[Tuin linksvoor 2]
        .... .011 = Incoming Cost: 3
        .001 .... = Outgoing Cost: 1
    Link 6
        Address: 0x1ff6[Tuin linksvoor 1]
        .... .011 = Incoming Cost: 3
        .011 .... = Outgoing Cost: 3
    Link 7
        Address: 0x23ec[Tuin linksachter 1]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 8
        Address: 0x2b9e[Bijkeuken]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 9
        Address: 0x325d[0x325d]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 10
        Address: 0x6339[Tuin rechtsvoor 3]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 11
        Address: 0x68c4[WC lamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 12
        Address: 0x731e[Kerstverlichting]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0
    Link 13
        Address: 0x7d2a[HK houtlamp]
        .... .111 = Incoming Cost: 7
        .111 .... = Outgoing Cost: 7
    Link 14
        Address: 0xc520[Badkamer ledstrip]
        .... .111 = Incoming Cost: 7
        .101 .... = Outgoing Cost: 5
    Link 15
        Address: 0xca27[Tuin rechtsvoor 2]
        .... .101 = Incoming Cost: 5
        .101 .... = Outgoing Cost: 5
    Link 16
        Address: 0xd6b7[Zolder Noord Lamp]
        .... .111 = Incoming Cost: 7
        .000 .... = Outgoing Cost: 0

Deskripsi Anda terdengar seperti yang saya alami. Saya memiliki jaringan yang jauh lebih baik (conbee 1) dengan fw terbaru. Tapi masih mendapatkan bohlam tidak responsif yang setelah beberapa saat menjadi responsif lagi.
Saya tidak menjalankan perintah atau pengaturan yang luar biasa daripada yang disediakan oleh Home Assistant dan jadwal saya yang biasa untuk bulb. Meskipun, bohlam interior berubah pada siang hari (hidup / mati atau kecerahan) di mana bohlam eksterior saya hanya mengubah waktu pohon dalam sehari. Terkadang bohlam yang tidak responsif kembali dengan cukup cepat dan jika saya mengeluarkan perintah, ia merespons. Jarang, tapi terjadi, butuh waktu lebih lama atau saya sudah menyalakan siklus.

@djwlindenaar kerja bagus lagi. Terima kasih banyak! Apakah Anda membagikan temuan bug Anda di IKEA FW dengan IKEA?

@djwlindenaar :

Tentu saja lampu itu (IKEA) harus berperilaku sendiri dan merespons dengan pesan kegagalan, tetapi tidak dan kami tidak dapat mengubahnya.

Ya, saya belum. Mungkin @manup bisa mengomentari tingkat keberhasilan melakukan ini, karena saya yakin dia sudah mencoba menghubungi IKEA.
Juga saya tidak menggunakan firmware terbaru mereka.

Mungkin menghubungi laboratorium silikon adalah ide yang lebih baik, karena dari situlah barang IKEA dibuat. Saya tidak yakin apakah bug berasal dari kode Ember atau kustomisasi IKEA ...

@djwlindenaar Anda juga dapat mencoba menghubungi melalui reddit: https://www.reddit.com/user/TRADFRI Mereka cukup aktif di sana.

@ Manup Ada berita untuk firmware Conbee II?

setelah menurunkan firmware kembali ke 0x264a0700 Saya tidak dapat lagi terhubung ke Conbee II. Mencoba menurunkan versi ke 0x264a0700 dan beberapa firmware yang sangat tua juga, flashing berfungsi dengan baik tetapi tidak dapat terhubung. Adakah saran untuk mengatur ulang stik Conbee II?

@manup ada pembaruan? Haruskah saya mencari yang lain selain deConz atau sedang dalam proses untuk menyelesaikan masalah? Tolong beri tanda kehidupan 🤗

Saya hanya ingin Conbee II saya berfungsi kembali setelah mencoba firmware uji ...

@djwlindenaar Adakah pembaruan dari pihak Anda? Masih jaringan yang stabil dengan perbaikan Anda?

Senang melihat PR Anda digabungkan oleh @manup :)

@djwlindenaar Adakah pembaruan dari pihak Anda? Masih jaringan yang stabil dengan perbaikan Anda?

Senang melihat PR Anda digabungkan oleh @manup :)

@ JBS5 Saya sedang senang dengan situasi ini.

Ini jelas telah meningkat untuk jaringan saya. Namun, terkadang saya masih melihat bug di lampu IKEA yang membingungkan deCONZ.

Poin utamanya adalah terkadang router IKEA secara diam-diam menjatuhkan paket untuk rute tertentu. Pengantaran diam-diam ini ilegal, tetapi deCONZ harus bereaksi dengan menemukan rute baru dan ternyata tidak.

Sepertinya perubahan pada firmware deCONZ memperbaiki situasi, tetapi masih ada sesuatu yang ditambahkan untuk situasi ini. Yang pasti, tidak adanya APS ACK harus segera memicu pencarian rute baru.

Perhatikan bahwa @manup memang menyebutkan bahwa perutean sumber dapat menyelesaikan masalah dan saya yakin ini benar terutama dalam kasus ini, karena itu berarti kami tidak bergantung pada router di jaringan yang mengetahui cara merutekan ke node jarak jauh.

Saya yakin bug di lampu IKEA adalah hasil dari beberapa tabel yang tidak dapat menampung semua rute ke node jarak jauh. Jadi diam-diam menjatuhkan paket apa pun yang rutenya tidak diketahui.

Terima kasih @djwlindenaar.
Seperti beberapa waktu yang lalu @manup berkomentar di sini, apakah Anda tahu apakah perutean sumber yang disebutkan adalah sesuatu yang akan diterapkan?

Ini adalah perubahan yang perlu terjadi di firmware. Saya tidak berafiliasi dengan deCONZ, jadi saya tidak dapat berkomentar tentang kemungkinan ...

@up ?

Ini _is_ menyebabkan saya mempertimbangkan untuk pindah dari deCONZ untuk jaringan rumah saya ...

@djwlindenaar , alternatif apa yang kamu pertimbangkan? Saat ini saya tidak terkesan dengan stabilitas Conbee II saya.

Ini adalah perubahan yang perlu terjadi di firmware. Saya tidak berafiliasi dengan deCONZ, jadi saya tidak dapat berkomentar tentang kemungkinan ...

@up ?

Ini _is_ menyebabkan saya mempertimbangkan untuk pindah dari deCONZ untuk jaringan rumah saya ...

Apakah Zigbee2MQTT melakukan ini dengan lebih baik atau bukankah Anda bermaksud demikian dengan alternatifnya?

Ya. Itu dia.

Saya sebenarnya tidak tahu apakah itu bekerja lebih baik. Perhatikan bahwa firmware yang digunakan di sana disediakan oleh pembuat chip. Firmwares tersebut bukan open source. Jadi jika mereka memiliki masalah firmware, Anda mungkin terjebak dengan dukungan yang kurang dari deCONZ ...
Di sisi lain, konfigurasi firmware ini adalah open source. Juga mereka sudah mendukung perutean sumber.

Pembuat chip hanya menyediakan SDK, jika Anda mau, Anda dapat mengunduh SDK, versi percobaan dari studio kesederhanaan dan mengompilasi sendiri firmware. Z2M menyediakan patch perubahan yang mereka lakukan pada firmware.

Halo bersama,

Mohon maaf karena butuh waktu lama, berikut adalah firmware baru untuk ConBee II yang telah mem-port semua perbaikan perutean dari firmware AVR 0x26350500. Selanjutnya telah meningkatkan startup untuk mencegah perangkat menjadi diam. (Kami masih menguji berbagai kasus untuk memperbaiki masalah boot untuk selamanya).

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26580700.bin.GCF

Versi ini kemungkinan akan menjadi bagian dari rilis deCONZ 2.05.76 yang akan datang, firmware ConBee I dan RaspBee I versi 0x26350500 akan dimunculkan untuk diinstal melalui tombol perbarui.

Terima kasih, @manup. Memasang versi ini di jaringan pengujian saya dan tampaknya berfungsi. Setidaknya perangkat dapat dikontrol, tidak seperti di bawah 52 dan 53. Jaringan pengujian terlalu kecil untuk memeriksa apakah versi ini meningkatkan perutean.

@manup deCONZ tetap tidak dapat terhubung ke ConBee II, bahkan setelah menginstal firmware baru. Mengalami masalah ini untuk sementara waktu.

@manup Saya mencoba

Flash update failed, invalid CRC. Please try again.

14:29:06:105 query bootloader v1 ID after 5 ms
14:29:06:122 RX 60 bytes ASCII
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
, 14:55:05
 after 22 ms
14:29:06:122 bootloader start after 22 ms
R21B18 Bootloader
Vers: 2.05
build: Mar 22 2019
14:29:06:124 GCF_ResetDeviceDone
14:29:06:125 bootloader v1 update firmware
flashing 160930 bytes: |==============================|
verify: .
Flash update failed, invalid CRC. Please try again.

Apakah ini GCFFlasher 3.13?

Ini log dari pembaruan saya:

GCFFlasher_internal -d /dev/ttyACM0 -f deCONZ_ConBeeII_0x26580700.bin.GCF 
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reboot device /dev/ttyACM0 (ConBee II)
deCONZ firmware version 26570700
R21B18 Bootloader
Vers: 2.05
build: Mar 11 2019
flashing 160930 bytes: |==============================|
verify: .
SUCCESS
Wait 10 seconds until application starts

Ya itu 3.13, itu berfungsi sekarang saya telah mem-boot ulang sistem penuh. Aneh, hanya dengan mengganti ConBee II tidak berhasil, tetapi reboot berhasil ..

Memang aneh, pemeriksaan CRC dilakukan langsung di perangkat, saya bertanya-tanya bagaimana ini bisa terjadi.

@ Manup Saya bahkan mencoba

Senang itu berhasil sekarang, terima kasih! Saya sudah melihat satu perangkat bermasalah yang langsung bergabung dengan jaringan. Jadi saya berharap firmware ini akan memperbaiki beberapa masalah :)

Senang itu berhasil sekarang. Baru saja berdiskusi dengan perguruan tinggi tentang bootloader. Versi 2.05 berasal dari batch pertama ConBee II pada tahun 2019 (sekitar 3500 pcs), versi ini agak kasar dalam beberapa kasus. Sejak Juli 2019 kami mengirimkan 2.07 dengan beberapa perbaikan pada penanganan pengawas.

Ada bootloader 3.x baru dalam pengembangan yang sudah menjadi bagian dari RaspBee II, ia memiliki desain dan protokol yang jauh lebih kuat untuk memperbaiki masalah versi 2.x.

Saat ini kami tidak memperbarui bootloader ConBee II dengan GCFFlasher. Kami belum meluncurkannya karena ada peluang halus untuk membuat perangkat menjadi bata jika pembaruan bootloader dibatalkan pada saat tabel vektor startup diubah. Tapi saya pikir kita bisa mengetahuinya dengan menggunakan handler kesalahan keras ARM. Idenya adalah jika pembaruan bootloader gagal dan penangan kesalahan keras dipicu, ia dapat memeriksa apakah bootloader valid dan jika gagal, ia akan melompat ke aplikasi, di mana pembaruan bootloader dapat dicoba lagi. Kami telah melakukan beberapa pengujian dengan hard fault handler yang terlihat menjanjikan, tetapi akan memakan waktu hingga siap untuk dirilis ke publik.

Hai

Saya mem-flash dengan firmware baru hari ini, tetapi saya masih melihat log seperti:

0x000D6FFFFE540E7C kesalahan APSDE-DATA.confirm: 0xA7 pada tugas

Apakah ini terkait?

0xA7 menunjukkan bahwa APS ACK belum disediakan di tempat yang seharusnya. Saya rasa itu bisa memiliki berbagai alasan.

Hai @manup , senang mendengar kabar dari Anda lagi. Apakah Anda juga memiliki waktu untuk membahas lebih lanjut masalah perutean yang tersisa? Dan semoga menyelesaikannya?

Halo lagi,

Saya masih mengalami masalah di mana beberapa lampu tidak bereaksi terhadap perintah (hidup / mati / redup), dan saya benar-benar tidak tahu mengapa, saya pikir saya ada hubungannya dengan masalah ini, tetapi sekarang saya tidak yakin apakah itu?

Saya masih mendapatkan banyak kesalahan seperti yang saya posting 4 hari yang lalu.

jumlah kode
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
total 76

Saya memiliki 26 perangkat yang memposting kesalahan ini HARI INI, sepertinya itu menjadi sedikit lebih buruk dengan 0x26580700

Dapatkah seseorang memberi tahu saya jika ini terkait dengan masalah perutean ini? atau saya harus membuka masalah dengan masalah saya

Perhatikan, tampaknya hanya terjadi saat mengirim fx. "menyala" ke ~ 20 lampu "pada saat yang sama"

Hai @manup , senang mendengar kabar dari Anda lagi. Apakah Anda juga memiliki waktu untuk membahas lebih lanjut masalah perutean yang tersisa? Dan semoga menyelesaikannya?

Halo @djwlindenaar ya, saya perlu

Halo @djwlindenaar ya, saya perlu

@manup , tentu, saya pikir masalah kuncinya masih bahwa deCONZ masih keras kepala dalam mempertahankan rute yang tidak berfungsi.
Saya percaya bahwa pesan dari lampu yang bermasalah dan yang terpengaruh terus masuk (melalui beberapa rute lain) dan itu disalahartikan oleh firmware seolah-olah rute yang tidak berfungsi masih berfungsi. Juga deCONZ cenderung menyerah pada permintaan lapisan APS dengan cukup cepat jika tidak ada ACK yang diterima. Saya pikir itu harus lebih gigih dan / atau memulai penemuan rute sebagai bagian dari proses coba lagi.

Akhirnya, saya sekarang yakin bahwa perutean sumber akan menghilangkan masalah utama perutean yang tidak berfungsi dengan baik. Jadi jika Anda bisa menerapkannya, kami akan berada di tempat yang jauh lebih baik. Saya siap membantu / menguji / debug ...

Hai @manup , senang mendengar kabar dari Anda lagi. Apakah Anda juga memiliki waktu untuk membahas lebih lanjut masalah perutean yang tersisa? Dan semoga menyelesaikannya?

Halo @djwlindenaar ya, saya perlu

Hai Manup, saya mungkin membajak utas ini jadi jika demikian harap abaikan. Saya memiliki Conbee ii di Asisten Rumah dan berfungsi dengan baik hingga sebulan yang lalu. Pada saat itu, semua sensor Xiaomi saya akan menjadi otomatisasi pemecah yang tidak dapat diandalkan. Saya memiliki beberapa pengontrol fls-pp dresden yang telah saya miliki selama beberapa tahun. Ini terhubung ke strip LED dan digunakan untuk secara sporadis melepaskan jaringan yang memaksa reboot untuk menyalakannya kembali. Saya akhirnya menghapus semuanya dari jaringan Conbee saya dan segera seluruh jaringan menjadi stabil. Saya meninggalkannya beberapa hari kemudian memperkenalkan kembali satu yang bekerja selama beberapa jam kemudian dalam semalam jaringan Zigbee saya gagal dan saya tidak bisa mendapatkan semua sakelar / sensor saya kembali online sampai saya mematikan pengontrol Dresden. Tidak tahu mengapa tetapi bagi saya, menggunakan pengontrol dresden sekarang merusak jaringan zigbee saya. Saya hanya seorang pemula dalam hal ini jadi tidak yakin apakah ini membantu / relevan tetapi saya sedang mencari komentar tentang ini dan terjadi pada utas ini jadi saya pikir saya akan memasukkan pengalaman saya ke dalam campuran untuk berjaga-jaga. Untuk saat ini saya hanya menghapusnya dari jaringan saya - tidak sebanding dengan sakit kepala yang mereka berikan kepada saya!
Bersulang

Halo @djwlindenaar ya, saya perlu

@manup , tentu, saya pikir masalah kuncinya masih bahwa deCONZ masih keras kepala dalam mempertahankan rute yang tidak berfungsi.
Saya percaya bahwa pesan dari lampu yang bermasalah dan yang terpengaruh terus masuk (melalui beberapa rute lain) dan itu disalahartikan oleh firmware seolah-olah rute yang tidak berfungsi masih berfungsi. Juga deCONZ cenderung menyerah pada permintaan lapisan APS dengan cukup cepat jika tidak ada ACK yang diterima. Saya pikir itu harus lebih gigih dan / atau memulai penemuan rute sebagai bagian dari proses coba lagi.

Akhirnya, saya sekarang yakin bahwa perutean sumber akan menghilangkan masalah utama perutean yang tidak berfungsi dengan baik. Jadi jika Anda bisa menerapkannya, kami akan berada di tempat yang jauh lebih baik. Saya siap membantu / menguji / debug ...

Saya telah memutuskan untuk pindah ke zigbee2mqtt karena masalah perutean (yang paling menjengkelkan adalah kebutuhan untuk memasangkan ulang Ikea / Xiaomi sesekali). Saya akan memposting temuan saya di sini dalam beberapa minggu ...

Setelah mem-flash firmware 0x26350500 di Conbee I saya (dan memperbarui deCONZ ke 2.05.76) Senin lalu, sayangnya GU10 offline.

Di VNC warnanya sedikit abu-abu:

Phoscon:

Apakah perlu untuk menyalakan semua lampu sebelum memanfaatkan perbaikan perutean di versi firmware baru?

@ JBS5 , menurut saya tidak perlu menyalakan lampu siklus setelah pembaruan firmware (kecuali jika lampu mati sebelum peningkatan, lampu tersebut tidak hidup kembali secara ajaib ...).
Mungkin karena fakta bahwa, meskipun ditingkatkan, kami tidak sepenuhnya jelas dari masalah perutean; lihat posting saya sebelumnya.

@djwlindenaar Terima kasih. Saya mengerti.

Untuk apa nilainya, karena ini adalah jenis perilaku yang sama seperti dengan firmware sebelumnya:

Setelah GU10 ditandai sebagai tidak tersedia, itu masih menanggapi perintah grup. Setelah beberapa hari, 2 perangkat bertenaga baterai (sensor gerak Aqara dan detektor asap Xiaomi / Honeywell) juga offline. GU10 masih menanggapi perintah grup.

Setelah menyalakan GU10, 2 perangkat bertenaga baterai juga langsung online.
Jadi setelah GU10 offline, perlu beberapa hari hingga perangkat bertenaga baterai menggunakan GU10 tertentu karena router juga offline.

@ JBS5 , ya, kedengarannya seperti perilaku biasa. Sebenarnya tidak ada yang salah dengan lampu GU10 itu. Hanya saja deCONZ kehilangan cara untuk berkomunikasi langsung dengannya. Setelah beberapa waktu, ini juga menyebabkan perangkat akhirnya menjadi offline karena mereka juga tidak mendapatkan umpan balik dari deCONZ. Akhirnya karena GU10 menjadi cukup kekurangan paket jaringan, ia menjadi offline secara nyata.

Mungkin dalam fase ketika masih menanggapi perintah grup, Anda akan dapat menyalakan siklus router lain, yang tampaknya baik-baik saja, dan GU10 akan pulih. Router lain itu sebenarnya tidak berfungsi dengan baik dan deCONZ tidak merespons situasi dengan baik.
Jadi jangan marah pada GU10;)

Halo @djwlindenaar ya, saya perlu

@manup , tentu, saya pikir masalah kuncinya masih bahwa deCONZ masih keras kepala dalam mempertahankan rute yang tidak berfungsi.

Hmm, rute harus diturunkan dan dibatalkan setelah beberapa transmisi gagal. Firmware terbaru akan menurun setiap kali kesalahan dilaporkan di APS-DATA.confirm (seperti kesalahan perutean atau tidak ada APS-ACK yang diterima).

Saya percaya bahwa pesan dari lampu yang bermasalah dan yang terpengaruh terus masuk (melalui beberapa rute lain) dan itu disalahartikan oleh firmware seolah-olah rute yang tidak berfungsi masih berfungsi.

Itu petunjuk yang sangat bagus, saya akan memeriksanya. itu akan menjelaskan mengapa rute tidak akan mati. Saya pikir satu-satunya cara yang masuk akal untuk menilai rute harus didasarkan pada transmisi yang berhasil.

Juga deCONZ cenderung menyerah pada permintaan lapisan APS dengan cukup cepat jika tidak ada ACK yang diterima. Saya pikir itu harus lebih gigih dan / atau memulai penemuan rute sebagai bagian dari proses coba lagi.

deCONZ tidak melakukan pencarian rute apa pun, ini semua ditangani oleh tumpukan Zigbee. Kita dapat memperluas REST-API untuk melakukan percobaan ulang untuk beberapa perintah (seperti perintah kontrol) tetapi ini adalah salah satunya.

Tumpukan itu sendiri dapat dikonfigurasi untuk membuat beberapa percobaan ulang APS hingga menyerah. Tapi ini bisa mengacaukan banyak hal dan memblokir antrian untuk waktu yang lama. Saya pikir yang terbaik adalah mempertimbangkan itu lebih halus di REST-API.

Akhirnya, saya sekarang yakin bahwa perutean sumber akan menghilangkan masalah utama perutean yang tidak berfungsi dengan baik. Jadi jika Anda bisa menerapkannya, kami akan berada di tempat yang jauh lebih baik. Saya siap membantu / menguji / debug ...

Dalam teori source routing adalah cawan suci untuk memperbaiki semuanya :)

Tetapi di dunia nyata banyak gateway yang tidak menggunakannya (apakah ada?), Yang berarti bahwa sebagian besar produk tidak mendukung perutean sumber atau tidak diuji dengannya. Peluang IMHO untuk membuatnya berfungsi di jaringan campuran sangat rendah. Tapi sudah lama sejak saya membandingkan berbagai gateway di level itu. Akan menarik untuk memiliki gambaran saat ini tentang gateway mana yang menggunakan pendekatan perutean mana saat ini.

Akan menarik untuk memiliki gambaran saat ini tentang gateway mana yang menggunakan pendekatan perutean mana saat ini.

Senang membantu pengujian / mengendus Hue bridge (gen 2 dan gen 1), gateway innr, hub IKEA, dan gateway OSRAM Lightly Home, tetapi saya memerlukan beberapa masukan tentang pengaturan pengujian apa yang akan digunakan (berapa banyak router, perangkat akhir, jarak di antara mereka , ...) dan apa yang harus dicari.

Z-Stack FW adalah salah satu contoh FW yang menawarkan / menggunakan perutean Sumber dan merekomendasikannya untuk jaringan yang lebih besar. Tetapi saya juga telah melihat beberapa komentar yang tidak bekerja dengan baik untuk CC2351 yang lebih lemah.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Juga deCONZ cenderung menyerah pada permintaan lapisan APS dengan cukup cepat jika tidak ada ACK yang diterima. Saya pikir itu harus lebih gigih dan / atau memulai penemuan rute sebagai bagian dari proses coba lagi.

deCONZ tidak melakukan pencarian rute apa pun, ini semua ditangani oleh tumpukan Zigbee. Kita dapat memperluas REST-API untuk melakukan percobaan ulang untuk beberapa perintah (seperti perintah kontrol) tetapi ini adalah salah satunya.

Tumpukan itu sendiri dapat dikonfigurasi untuk membuat beberapa percobaan ulang APS hingga menyerah. Tapi ini bisa mengacaukan banyak hal dan memblokir antrian untuk waktu yang lama. Saya pikir yang terbaik adalah mempertimbangkan itu lebih halus di REST-API.

Tumpukan melakukan beberapa percobaan ulang, saya ingat itu mencoba tiga kali, jika saya tidak salah. Menurut saya, Anda dapat menambahkan perilaku dalam potongan kode tersebut untuk membatalkan rute terkait dan mencoba lagi sekali atau dua kali. Atau mungkin Anda dapat memiliki callback di dalam stack untuk mengimplementasikan perilaku tersebut. Itu seharusnya mendatangkan penemuan rute, bukan?

Akhirnya, saya sekarang yakin bahwa perutean sumber akan menghilangkan masalah utama perutean yang tidak berfungsi dengan baik. Jadi jika Anda bisa menerapkannya, kami akan berada di tempat yang jauh lebih baik. Saya siap membantu / menguji / debug ...

Dalam teori source routing adalah cawan suci untuk memperbaiki semuanya :)

Tetapi di dunia nyata banyak gateway yang tidak menggunakannya (apakah ada?), Yang berarti bahwa sebagian besar produk tidak mendukung perutean sumber atau tidak diuji dengannya. Peluang IMHO untuk membuatnya berfungsi di jaringan campuran sangat rendah. Tapi sudah lama sejak saya membandingkan berbagai gateway di level itu. Akan menarik untuk memiliki gambaran saat ini tentang gateway mana yang menggunakan pendekatan perutean mana saat ini.

Sejujurnya, saya tidak terlalu khawatir tentang masalah ini. Perilaku router dalam kasus perutean sumber sangat sederhana. Apalagi jika membandingkannya dengan perilaku yang diharuskan untuk melakukan routing sendiri. Pada dasarnya satu-satunya hal yang harus dilakukan lapisan NWK di router, adalah memeriksa apakah perutean sumber diaktifkan, membaca hop berikutnya dari paket dan menyerahkannya kembali ke lapisan MAC. Tidak ada tabel, tidak ada memori, tidak ada yang salah. Saya tidak yakin apakah perilaku dasar diperiksa untuk sertifikasi zigbee, tetapi yang pasti itu jauh lebih sederhana dan kemungkinan bug jauh lebih sedikit daripada perutean normal.

Harapan saya hanya sedikit koordinator yang mengimplementasikannya, karena kerumitannya ada pada firmware koordinator. Juga sangat sedikit implementasi zigbee (konsumen) yang benar-benar difokuskan pada jaringan yang lebih besar yang akan mendapat manfaat dari mode perutean ini.

Akhirnya saya berpendapat bahwa ini adalah mode perutean terbaik untuk jaringan campuran, karena perutean normal bergantung pada implementasi individual dari router dan terutama indikasi kualitas tautan yang ditentukan dengan buruk. Karena sumber routing sangat sederhana (= peluang rendah untuk implementasi yang buruk), saya percaya bahwa sebelum perilaku routing normal.

Jadi ... setelah mengatakan ini, saya siap mengujinya untuk Anda jika Anda dapat memberikan firmware. Saya menggunakan raspbee, sniffer saya siap untuk digunakan.

Akhirnya saya berpendapat bahwa ini adalah mode perutean terbaik untuk jaringan campuran, karena perutean normal bergantung pada implementasi individual dari router dan terutama indikasi kualitas tautan yang ditentukan dengan buruk. Karena sumber routing sangat sederhana (= peluang rendah untuk implementasi yang buruk), saya percaya bahwa sebelum perilaku routing normal.

KISS - sangat masuk akal bagi saya.

Tumpukan melakukan beberapa percobaan ulang, saya ingat itu mencoba tiga kali, jika saya tidak salah. Menurut saya, Anda dapat menambahkan perilaku dalam potongan kode tersebut untuk membatalkan rute terkait dan mencoba lagi sekali atau dua kali. Atau mungkin Anda dapat memiliki callback di dalam stack untuk mengimplementasikan perilaku tersebut. Itu seharusnya mendatangkan penemuan rute, bukan?

Jika saya memahami kode dengan benar yang sudah terjadi, masalahnya adalah rute tampaknya tetap hidup karena faktor lain (dalam penyelidikan).

Sejujurnya, saya tidak terlalu khawatir tentang masalah ini. Perilaku router dalam kasus perutean sumber sangat sederhana. Apalagi jika membandingkannya dengan perilaku yang diharuskan untuk melakukan routing sendiri. Pada dasarnya satu-satunya hal yang harus dilakukan lapisan NWK di router, adalah memeriksa apakah perutean sumber diaktifkan, membaca hop berikutnya dari paket dan menyerahkannya kembali ke lapisan MAC. Tidak ada tabel, tidak ada memori, tidak ada yang salah. Saya tidak yakin apakah perilaku dasar diperiksa untuk sertifikasi zigbee, tetapi yang pasti itu jauh lebih sederhana dan kemungkinan bug jauh lebih sedikit daripada perutean normal.

Saya hanya dapat berbicara untuk produk berbasis BitCloud yang saya bawa melalui sertifikasi (ballast FLS). Dalam proses sertifikasi, mereka tidak pernah diuji untuk perutean sumber. Saya tidak yakin apakah itu bahkan diaktifkan di tumpukan pada waktu kompilasi. Perhatikan bahwa kebanyakan tumpukan dikonfigurasi untuk dikompilasi dengan fitur minimum yang diperlukan ke ruang yang aman.

Pengalaman pribadi saya dengan fitur yang jarang digunakan / diuji, tidak peduli seberapa sederhananya secara teori, adalah selalu ada bug. Misalnya untuk FLS kami harus memperbaiki banyak bug dalam contoh aplikasi tumpukan BitCloud. Saya tahu bahwa Philips juga membuat banyak peningkatan dalam tumpukan BitCloud untuk beberapa produk mereka.

Harapan saya hanya sedikit koordinator yang mengimplementasikannya, karena kerumitannya ada pada firmware koordinator. Juga sangat sedikit implementasi zigbee (konsumen) yang benar-benar difokuskan pada jaringan yang lebih besar yang akan mendapat manfaat dari mode perutean ini.

Kompleksitas perlu diimplementasikan di plugin deCONZ REST-API atau plugin router baru, karena firmware tidak memiliki wawasan yang cukup tentang seluruh topologi jaringan atau ruang flash. Untuk tujuan itu deCONZ::ApsDataRequest dapat diperpanjang dengan opsi rute sumber dalam bentuk std::vector<quint16> memegang alamat nwk dari sebuah rute.

Saya tidak memiliki gambaran umum yang baik tentang kompleksitas yang ditimbulkannya, yang saat ini ditangani oleh perutean mesh. Tugas berikut perlu dipertimbangkan minimal dan dalam skala besar:

• Kueri rekursif topologi jaringan (Mgmt_Lqi_req). Itu, yang mudah, ini sudah berfungsi untuk perutean mesh dan dapat disesuaikan dengan rute sumber.
• Node dimatikan. Di sini beberapa logika perlu memilih rute alternatif, yang mungkin juga tidak berfungsi jika tautannya juga rusak.
• Node dinyalakan kembali.
• Node mengubah alamat nwk.
• Perangkat akhir mengubah orang tua.
• Perangkat-akhir bergabung, dalam jaringan multi-hop kita tidak tahu induknya tanpa menanyakan jaringan.

Apa yang belum kami ketahui:

• Apakah semua router mendukung perutean sumber?
• Apakah ada gateway komersial yang menggunakan perutean sumber? Di sini kita perlu mengendus lalu lintas dan melihat header NWK yang menyimpan rute sumber dan menetapkan flag masing-masing.
• Untuk perangkat yang mendukung perutean sumber, seberapa baik kerjanya?

Saya hanya dapat berbicara untuk produk berbasis BitCloud yang saya bawa melalui sertifikasi (ballast FLS). Dalam proses sertifikasi, mereka tidak pernah diuji untuk perutean sumber. Saya tidak yakin apakah itu bahkan diaktifkan di tumpukan pada waktu kompilasi. Perhatikan bahwa kebanyakan tumpukan dikonfigurasi untuk dikompilasi dengan fitur minimum yang diperlukan ke ruang yang aman.

Saya tidak terbiasa dengan cara kerjanya, tetapi bukankah tumpukannya juga disertifikasi?

Pengalaman pribadi saya dengan fitur yang jarang digunakan / diuji, tidak peduli seberapa sederhananya secara teori, adalah selalu ada bug. Misalnya untuk FLS kami harus memperbaiki banyak bug dalam contoh aplikasi tumpukan BitCloud. Saya tahu bahwa Philips juga membuat banyak peningkatan dalam tumpukan BitCloud untuk beberapa produk mereka.

Harapan saya hanya sedikit koordinator yang mengimplementasikannya, karena kerumitannya ada pada firmware koordinator. Juga sangat sedikit implementasi zigbee (konsumen) yang benar-benar difokuskan pada jaringan yang lebih besar yang akan mendapat manfaat dari mode perutean ini.

Kompleksitas perlu diimplementasikan di plugin deCONZ REST-API atau plugin router baru, karena firmware tidak memiliki wawasan yang cukup tentang seluruh topologi jaringan atau ruang flash. Untuk tujuan itu deCONZ::ApsDataRequest dapat diperpanjang dengan opsi rute sumber dalam bentuk std::vector<quint16> memegang alamat nwk dari sebuah rute.

Saya tidak mengerti pernyataan ini. Perutean sumber sepenuhnya ditangani pada tingkat NWK dalam tumpukan. Tumpukan bitcloud harus memiliki beberapa tanda waktu kompilasi (atau kemungkinan waktu proses yang lebih kecil) untuk mengaktifkan perutean sumber. Ada tabel rute sumber yang selalu diperbarui oleh tumpukan, berdasarkan pesan Catatan Rute yang sudah ada di jaringan kami karena MTORR yang dikirim oleh koordinator setiap beberapa menit.

• Pada dasarnya untuk setiap perangkat di jaringan, rute ke koordinator dikenal melalui MTORR
• Koordinator mengetahui setiap rute (lengkap) ke setiap perangkat melalui pesan Route Record. Tidak ada analisis yang diperlukan, cukup copy-past pesan RR ke tabel rute sumber

Lihat spesifikasi zigbee bab 3.6.3.5.4 dan bab 3.6.3.3

Saya tidak memiliki gambaran umum yang baik tentang kompleksitas yang ditimbulkannya, yang saat ini ditangani oleh perutean mesh. Tugas berikut perlu dipertimbangkan minimal dan dalam skala besar:

* Recursive query of network topology (Mgmt_Lqi_req). Thats, the easy one, this already works for mesh routing and could be adapted to source routes.

* Nodes are powered off. Here some logic needs to select alternate routes, which may also not work if their links are broken too.

* Nodes are powered on again.

* Nodes changing the nwk address.

* End-devices changing parents.

* End-devices joining, in multi-hop networks we don't know the parent without querying the network.

Saya yakin ini semua ditangani oleh lapisan NWK di dalam tumpukan bitcloud. Ini harus sesederhana menyesuaikan beberapa tanda waktu kompilasi (mirip dengan mengaktifkan perilaku MTOR)

Apa yang belum kami ketahui:

* Do all routers support source routing?

Saya berharap demikian, karena ini adalah bagian dari spesifikasi zigbee dasar dari lapisan NWK. Saya tidak dapat memastikannya, tetapi saya tidak melihat komentar apapun yang mendukung perutean sumber adalah opsional. Ini mirip dengan perilaku MTOR, yang sudah kami gunakan di jaringan kami.

* Are there any commercial gateways which use source routing? Here we need to sniff traffic and look at the NWK headers which hold the source routes and have respective flags set.

Tidak tahu yang ini, juga tidak tahu apa yang akan memberitahu kita?

* For the devices which support source routing, how well does it work?

Jika Anda dapat membuat versi firmware dengan perutean sumber diaktifkan, kami akan belajar dengan cepat. Ini seharusnya hanya berupa beberapa tanda waktu kompilasi untuk mengaktifkannya di bitcloud.

Juga Zigbee2MQTT telah mengaktifkannya untuk beberapa firmware koordinator dan saya belum (setelah google cepat) menemukan masalah dengan router tertentu yang tidak bekerja dengan baik dengan perutean sumber diaktifkan.

Saya tidak terbiasa dengan cara kerjanya, tetapi bukankah tumpukannya juga disertifikasi?

Ya, tetapi selama sertifikasi, konfigurasi khusus diaktifkan yang mungkin tidak diaktifkan di produk nanti.

Saya tidak mengerti pernyataan ini. Perutean sumber sepenuhnya ditangani pada tingkat NWK dalam tumpukan. Tumpukan bitcloud harus memiliki beberapa tanda waktu kompilasi (atau kemungkinan waktu proses yang lebih kecil) untuk mengaktifkan perutean sumber. Ada tabel rute sumber yang selalu diperbarui oleh tumpukan, berdasarkan pesan Catatan Rute yang sudah ada di jaringan kami karena MTORR yang dikirim oleh koordinator setiap beberapa menit.

Pada dasarnya untuk setiap perangkat di jaringan, rute ke koordinator dikenal melalui MTORR
Koordinator mengetahui setiap rute (lengkap) ke setiap perangkat melalui pesan Route Record. Tidak ada analisis yang diperlukan, cukup copy-past pesan RR ke tabel rute sumber

Lihat spesifikasi zigbee bab 3.6.3.5.4 dan bab 3.6.3.3

Ah Anda benar, saya konyol, entah bagaimana saya salah menafsirkannya dengan penemuan simpul umum (facepalm).
Tumpukan memang dapat mengetahui banyak karena perintah rekaman rute, tetapi saya sudah mengalami kasus di mana tidak ada yang dikirim, lihat di bawah.

Hari ini saya telah mencoba banyak konfigurasi, tampaknya perutean sumber berfungsi dengan baik, tetapi hanya ketika perutean mesh dinonaktifkan dan untuk perangkat yang mengirim perintah rekaman rute sebelumnya.

Sensor gerak Philips Hue saya membuat masalah dan mengirimkan permintaan alamat NWK siaran untuk mendapatkan alamat gateway NWK. Dalam hal ini tidak ada frame record rute yang dikirim sebuah biara (saya pikir karena siaran). Karena perutean mesh dinonaktifkan, gateway tidak memulai pencarian rute sehingga komunikasi ke sensor tidak dibuat.

Ketika perutean mesh diaktifkan di sebelah perutean sumber, tampaknya perutean sumber tidak lagi digunakan meskipun keduanya diaktifkan.

Saya perlu melakukan lebih banyak tes, saya pikir penemuan rute mesh harus dicegah ketika sudah ada entri catatan rute di cache rute. Kodenya cukup kompleks, saya perlu menggali lebih dalam di sini.

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

Berikut adalah firmware yang mengaktifkan perutean mesh dan sumber (ukuran tabel rekaman rute 32). Anda dapat mencobanya tetapi seperti yang disebutkan dalam perutean sumber jaringan saya yang lebih kecil tidak dipicu dalam konfigurasi itu.

Saya di raspbee I, jadi tidak bisa menguji yang itu. Bisakah Anda membuatnya juga?
Saya bertanya-tanya apakah kami dapat mengatasi masalah ini dengan semacam rute statis yang dapat kami unggah ke firmware saat startup atau mungkin memang berdasarkan beberapa informasi lain.
Selain itu, apakah Anda memperbaiki perangkat ini setelah perubahan pada perutean sumber? Ingin tahu apakah ada beberapa interaksi yang diperlukan untuk perangkat akhir untuk mengenali MTOR dan perutean sumber sedang digunakan. Tentu saja mereka tidak menerima pesan MTOR siaran saat penerima mereka mati.
BTW Saya memang melihat perangkat akhir Xiaomi saya mengirim catatan rute di sniffing saya ...

Saya telah memimpin firmware di atas dijalankan sepanjang malam. Tampaknya perutean sumber digunakan juga dengan perutean jala diaktifkan, tetapi sangat jarang. Dari ca. 2 juta paket hanya <5 menggunakan jalur sumber.

Saya di raspbee I, jadi tidak bisa menguji yang itu. Bisakah Anda membuatnya juga?

Tidak yakin, saya perlu memeriksa konfigurasi tumpukan lain yang digunakan oleh ConBee I dan RaspBee I jika memungkinkan.

Saya bertanya-tanya apakah kami dapat mengatasi masalah ini dengan semacam rute statis yang dapat kami unggah ke firmware saat startup atau mungkin memang berdasarkan beberapa informasi lain.

Ya, saya pikir itu harus mungkin untuk menyuntikkan rute ke cache rute. Tetapi ketika kita kembali ke keprihatinan saya yang disebutkan di atas untuk mempertahankan rute. Bagaimanapun untuk tujuan pengujian dan jaringan tetap itu akan memberikan cara yang berguna untuk mengkonfigurasi perutean.

Selain itu, apakah Anda memperbaiki perangkat ini setelah perubahan pada perutean sumber? Ingin tahu apakah ada beberapa interaksi yang diperlukan untuk perangkat akhir untuk mengenali MTOR dan perutean sumber sedang digunakan.

Tidak, saya baru saja memperbarui firmware, tidak ada perbaikan - rute sumber dibuat segera setelah menerima perintah rekaman rute.

BTW Saya memang melihat perangkat akhir Xiaomi saya mengirim catatan rute di sniffing saya ...

IKEA tampaknya cocok di sini juga, saya ingin melakukan lebih banyak tes dengan Philips dan perangkat merek lain untuk mendapatkan detail lebih lanjut bagaimana berbagai perangkat dapat digunakan dengan perutean sumber.

Saya juga dapat ikut serta untuk menguji apakah kami dapat membuatnya berfungsi untuk Raspbee.

Saya telah memimpin firmware di atas dijalankan sepanjang malam. Tampaknya perutean sumber digunakan juga dengan perutean jala diaktifkan, tetapi sangat jarang. Dari ca. 2 juta paket hanya <5 menggunakan jalur sumber.

Menarik! Akan menyenangkan untuk mendapatkan wawasan tentang logika pengambilan keputusan ketika rute sumber digunakan dan apakah itu dapat dipengaruhi / disetel entah bagaimana.

Saya di raspbee I, jadi tidak bisa menguji yang itu. Bisakah Anda membuatnya juga?

Tidak yakin, saya perlu memeriksa konfigurasi tumpukan lain yang digunakan oleh ConBee I dan RaspBee I jika memungkinkan.

Akan lebih bagus ...

Saya bertanya-tanya apakah kami dapat mengatasi masalah ini dengan semacam rute statis yang dapat kami unggah ke firmware saat startup atau mungkin memang berdasarkan beberapa informasi lain.

Ya, saya pikir itu harus mungkin untuk menyuntikkan rute ke cache rute. Tetapi ketika kita kembali ke keprihatinan saya yang disebutkan di atas untuk mempertahankan rute. Bagaimanapun untuk tujuan pengujian dan jaringan tetap itu akan memberikan cara yang berguna untuk mengkonfigurasi perutean.

Sepakat

Selain itu, apakah Anda memperbaiki perangkat ini setelah perubahan pada perutean sumber? Ingin tahu apakah ada beberapa interaksi yang diperlukan untuk perangkat akhir untuk mengenali MTOR dan perutean sumber sedang digunakan.

Tidak, saya baru saja memperbarui firmware, tidak ada perbaikan - rute sumber dibuat segera setelah menerima perintah rekaman rute.

Ingin tahu apakah itu akan membantu untuk perangkat Philips ...

Halo teman-teman, saya telah menjalankan firmware Perutean Sumber Z2M selama 24 jam (hanya memungkinkan 5 sambungan langsung). Saya memiliki ~ 35 perangkat. Ini berfungsi dengan baik tetapi saya telah memperhatikan bahwa perangkat Hue memerlukan siklus daya untuk menyambung kembali setelah saya pindah dari FW default ke firmware SR. Ikea dan Xiaomi terhubung kembali secara otomatis. Mungkin ini dapat menjelaskan bagian dari perilaku Hue yang Anda lihat?

Hai,
Saya menguji ulang bohlam TRADFRI E14 WS opal 400lm dengan firmware ikea 2.3.050 dan deconz beta terbaru dan firmware terbaru di Conbee I. Saya dapat memastikan bohlam dan komunikasi telah meningkat. Pengingat adegan, pengaktifan / penonaktifan, pemudaran masuk dan keluar sekarang berfungsi lebih baik tetapi masih ada masalah.

Masalah yang didokumentasikan di sini # 2518 sebagian besar telah diselesaikan. Sepertinya perintah grup (dari phoscon gui) bekerja lebih baik. # 2518 ditutup

Saya telah memperhatikan bahwa mengubah CT kadang-kadang perlu dipicu lebih dari satu kali untuk sukses jika diubah dengan tangan, bukan adegan.

Masalah baru # 2892 yang muncul adalah jika dalam sebuah grup sebuah adegan dipanggil kembali dan semua lampu yang dimiliki dinyalakan (karena adegan itu) dan kemudian adegan lain dalam grup itu dengan hanya beberapa lampu yang dinyalakan (ditentukan oleh adegan) ingat, lampu "tidak diinginkan" yang harus dimatikan tetap menyala.
Selain itu, jika Anda mematikan grup, hanya lampu adegan yang ditentukan saat ini yang mati dan yang lain dari sebelumnya (adegan sebelumnya dari grup) tetap menyala. Mereka membutuhkan beberapa perintah off sebelum pergi.
Masalahnya dijelaskan di sini tapi pasti ada di API karena tidak ada bedanya jika menggunakan Phoscon atau api itu sendiri. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

catatan tambahan: menggunakan rilis ikea fw 2.3.050 terbaru pada 20.5.2020

Versi Rilis: 1.12.1
20 Mei 2020
Fitur dan perubahan baru di Aksesoris:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Memperbaiki On Off State setelah OTA Upgrade.

Terima kasih atas peningkatan berkelanjutan dan kerja keras Anda.

@ Manup , ada berita untuk versi firmware rute sumber conbee I? Saya tidak sabar untuk mengujinya :)

@ Manup , ada berita untuk versi firmware rute sumber conbee I? Saya tidak sabar untuk mengujinya :)

Upaya pertama saya untuk mengaktifkannya berakhir dengan kekacauan waktu kompilasi yang mengerikan: / Belum tahu apa penyebabnya dan berharap untuk membuatnya bisa dikompilasi.

@ Manup , ada berita untuk versi firmware rute sumber conbee I? Saya tidak sabar untuk mengujinya :)

Upaya pertama saya untuk mengaktifkannya berakhir dengan kekacauan waktu kompilasi yang mengerikan: / Belum tahu apa penyebabnya dan berharap untuk membuatnya bisa dikompilasi.

Hmmmm kedengarannya tidak bagus ... @manup , saya ingin membantu, tetapi saya tidak memiliki akses ke kode itu.

@manup , ada kemajuan?

@manup , ps! 😁

Masalah ini secara otomatis ditandai sebagai usang karena tidak ada aktivitas terbaru. Ini akan ditutup jika tidak ada aktivitas lebih lanjut. Terima kasih atas kontribusi Anda.

Masih terjadi. @manup kemajuan dan / atau pembaruan tentang masalah ini?

@djwlindenaar @ JBS5 Saya telah meminta @manup untuk update.

Ya, masih menjadi masalah - meski jauh lebih sedikit dari sebelumnya.

Apa yang terbaru tentang masalah ini?

Saya memiliki sekitar 20 GU10 spektrum putih (gen pertama) yang terhubung ke jembatan Hue dan sebagai bagian dari rasionalisasi jaringan zigbee saya, saya ingin memigrasi semua perangkat saya ke Deconz.

Rona cukup stabil tetapi lampu masih mati dari waktu ke waktu (mis. Seminggu sekali, satu lampu mati). Saya hanya perlu menyalakan ulang bohlam untuk menyadarkannya.

Apakah Deconz lebih atau kurang stabil?

Tidak ada Deconz yang tidak lebih stabil, saya juga memiliki sekitar 40 lampu Ikea dan terkadang beberapa mati

@salopette Saya tidak punya pengalaman itu. Maukah Anda membuka terbitan terpisah? Ada log?

@Mimiix Masalah ini tentang lampu yang

Sama disini. Lampu masih mati sesekali. Tapi itu jauh lebih baik dari waktu ke waktu. Ketika saya mulai menggunakan deCONZ pada tahun 2018, saya harus menyalakan lampu ikea saya hampir setiap hari. Saya paling sering mengalami masalah ini dengan Panel FLOALT tetapi ini juga yang paling jauh dari Conbee Stick saya.

@ JBS5 Karena kami tidak tahu apa-apa tentang pengaturan pengguna ini. Tidak ada versi, tidak ada log, tidak ada informasi tentang penyiapan. Kami tidak dalam posisi untuk menentukan apakah masalahnya terkait dengan ini.

Menambahkan komentar tanpa informasi apa pun tidak membantu hal ini dalam kasus. Itu sebabnya saya ingin masalah terpisah sehingga kami memiliki gambaran yang lebih baik.

Saya pernah meminta @manup secara pribadi untuk melihat dan memprioritaskannya.

@djwlindenaar telah menggali lebih dalam. Saya ragu memeriksa pengaturan pengguna lain dapat melakukan apa saja tentang masalah yang tampaknya ada secara umum dengan lampu ikea. Saya lebih suka berkonsentrasi pada penyelidikan yang ada daripada memulai yang lain.

Pengumuman umum:

Saya baru saja berbicara dengan @manup secara pribadi tentang ini. Dia memberi tahu saya hal berikut:

`` Bahwa firmware akan mendapatkan pembaruan sehubungan dengan masalah perutean, dan jaringan baru semoga membantu menciptakan kembali masalah (yang sebelumnya tidak mungkin dilakukan).
Rencana saya adalah firmware berikutnya ini tersedia dalam 2–3 minggu ke depan.

Beberapa perubahan sudah dilakukan tetapi belum untuk publik.
``

Saya akan terus mengabari Anda.

Pengumuman umum:

Saya baru saja berbicara dengan @manup secara pribadi tentang ini. Dia memberi tahu saya hal berikut:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Saya akan terus mengabari Anda.

3 minggu kemudian, ada pembaruan tentang ini?

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)

Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)

Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)

Jadi berapa ETA sekarang 2-3 minggu telah berlalu

@lubbertkramer Harap masuk akal di sini, bot basi adalah lelucon. Satu-satunya janji yang dibuat @Mimiix sebelumnya adalah membagikan pembaruan setelah beberapa tersedia, jadi sangat valid untuk bertanya tentang status saat ini. Sekarang untuk ETA, tidak ada yang dijanjikan dan saya mengerti tidak akan ada, karena ini adalah hal yang rumit. Seperti yang saya tahu manup ketika berbicara tentang hal-hal buruk, sayangnya tidak ada yang dapat diselesaikan dalam sehari, hanya muncul setelah waktu yang cukup lama atau mengembangkan beberapa efek samping yang tidak terduga.

Jadi dalam hal itu, harap bersabar dan biarkan orang-orang yang mengerjakannya (omong-omong, ini masih waktu liburan). Ketika berbicara tentang rilis berikutnya, dalam 1,5 minggu untuk mengangkat tangan Anda dan meminta berita.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)

Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Masalah boot ulang tidak terkait dengan masalah ini, saya kira?
Bagaimana dengan perubahan perutean dan peningkatan debug yang disebutkan? Apakah peningkatan debug tersebut terkait dengan masalah ini?

Dan apakah perubahan perutean tersebut didasarkan pada temuan @djwlindenaar atau apakah @manup sudah bisa lebih spesifik?

@lubbertkramer Harap masuk akal di sini, bot basi adalah lelucon. Satu-satunya janji yang dibuat @Mimiix sebelumnya adalah membagikan pembaruan setelah beberapa tersedia, jadi sangat valid untuk bertanya tentang status saat ini. Sekarang untuk ETA, tidak ada yang dijanjikan dan saya mengerti tidak akan ada, karena ini adalah hal yang rumit. Seperti yang saya tahu manup ketika berbicara tentang hal-hal buruk, sayangnya tidak ada yang dapat diselesaikan dalam sehari, hanya muncul setelah waktu yang cukup lama atau mengembangkan beberapa efek samping yang tidak terduga.

Jadi dalam hal itu, harap bersabar dan biarkan orang-orang yang mengerjakannya (omong-omong, ini masih waktu liburan). Ketika berbicara tentang rilis berikutnya, dalam 1,5 minggu untuk mengangkat tangan Anda dan meminta berita.

Saya pikir lebih masuk akal untuk menahan orang untuk menyampaikan komunikasi atau janji tanpa membuat "lelucon" ketika 2-3 minggu telah berlalu dalam 3 minggu tanpa tindak lanjut. Pengguna yang telah menyelidiki banyak dan menjawab di sini sudah pindah karena kurangnya tindak lanjut / komunikasi.

Jadi kembali pada masalah apa informasi terbaru tentang masalah ini?

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)

Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)

Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.

Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.

_Jadilah perubahan yang ingin Anda lihat di dunia ini_

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.

Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.

_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.

2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.
_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.

2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Tolong izinkan saya menyarankan Anda untuk mengendalikan emosi Anda. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan topik dan sopan. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.

Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan lakukan itu dalam masalah ini.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.
_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.
2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Tolong izinkan saya menyarankan Anda untuk mengendalikan emosi Anda. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan topik dan sopan. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.

Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan lakukan itu dalam masalah ini.

Satu-satunya hal yang memalukan dalam masalah ini adalah manup dan Dresden jelas tidak mampu memperbaiki masalah ini. Conbee adalah produk komersial dan disertai tanggung jawab. Itulah sebabnya banyak dari kita telah meninggalkan deCONZ / Conbee untuk chip TI dan Z2M, yang telah bekerja dengan sempurna sejak saat itu.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.
_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.
2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Tolong izinkan saya menyarankan Anda untuk mengendalikan emosi Anda. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan topik dan sopan. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.

Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan lakukan itu dalam masalah ini.

Dan lagi, Anda tidak menjawab atau memperbarui status yang ditanyakan berkali-kali dan satu-satunya hal yang Anda lakukan adalah melanjutkan dengan diskusi offtopic di mana Anda sudah dapat memberikan pembaruan seperti yang diminta di akhir setiap posting. Anda membual tentang koneksi / undangan langsung dalam pertemuan pengembangan, jadi Anda harus mengetahui status masalah ini dan dapat memperbarui semua pengguna yang membaca di sini.

Jadi sekali lagi posting update atau hentikan posting offtopic, saya rasa itu adalah tugas Anda sebagai moderator komunitas daripada menjaga diskusi offtopic tetap hidup :)

Pengumuman umum:

Saya baru saja berbicara dengan @manup secara pribadi tentang ini. Dia memberi tahu saya hal berikut:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Saya akan terus mengabari Anda.

2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya, apa yang bisa kami harapkan pengguna?

Sebuah ketergantungan baru akan datang dalam waktu kurang dari seminggu. Saya menyarankan untuk tetap tenang
dan menunggu untuk melihat apa yang akan dihasilkan oleh perubahan baru

Saya memiliki banyak trader yang bekerja tanpa masalah selama lebih dari setahun.
Baru-baru ini, saya mulai mengalami masalah hanya dengan satu lampu Tradfri saya
mulai menjatuhkan dan menghubungkan ke jaring setiap 15 menit. 15 menit
dapat dijangkau, 15 menit tidak dapat dijangkau. Melakukan banyak pengujian untuk menemukan masalahnya.
Tebak apa .... masalahnya? Itu bukan dari deCONZ tapi WiFi saya
jadwal pengulang a resently diletakkan di atasnya.

Jangan terlalu yakin bahwa masalahnya selalu terkait deCONZ, terkadang tidak.

Pada hari Minggu, 6 Sep 2020, 11:38 lubbertkramer [email protected] menulis:

@ JBS5 https://github.com/JBS5 Belum 3 minggu. Menunggu bot basi
di sini;)
Pmed @manup https://github.com/manup pagi ini lagi. Punya
tanggapan berikut:

Telah merayapi firmware dalam beberapa hari terakhir untuk menyelidiki masalah boot ulang dan menemukan beberapa bug yang tidak menyenangkan.
Ini juga akan berisi beberapa perubahan perutean, berharap untuk mengeluarkannya dengan rilis yang akan datang.

Peningkatan debug akan mengikuti setelah rilis stabil berikutnya.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah Anda membuat janji kepada komunitas jadi wajar saja mereka menahan Anda
untuk janji itu, 21 hari / 7 hari = 3 minggu
maka timpang bersembunyi di balik stalebot ketika masalah ini sudah selesai
aktif sejak Februari 2019. Saat Anda ingin menjadi pembicara di Dresden
bertindak seperti itu atau biarkan @manup https://github.com/manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini.
Saya sama sekali bukan juru bicara, saya berusaha keras di sini untuk mendapatkan sesuatu
diurutkan karena saya memiliki koneksi langsung. Bot basi yang saya gunakan untuk melacak
masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan
jika jangka waktu berlalu, bot yang lama membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk file
komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan itu
Saya tidak punya hal lain untuk dilakukan dalam hidup.
Jadilah perubahan yang ingin Anda lihat di dunia ini

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna sekali lagi
alih-alih menyala dan mengubah kekuatan bunga tinggalkan masalah ini sebagai
juru bicara atau kembali ke masalah dan informasi terbaru.
2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum oleh
lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Izinkan saya menyarankan Anda untuk menyimpan
emosi terkendali. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat
tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan agar tetap sesuai topik dan
sipil. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.

Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan
lakukan dalam masalah ini.

Dan sekali lagi, Anda tidak menjawab atau memperbarui status yang diminta
berkali-kali dan satu-satunya hal yang Anda lakukan adalah melanjutkan dengan offtopic
diskusi di mana Anda sudah bisa memberikan pembaruan seperti yang diminta di akhir
dari setiap postingan. Anda membual tentang koneksi / undangan langsung
pertemuan pengembangan, jadi Anda harus mengetahui status
masalah ini dan dapat memperbarui semua pengguna yang membaca di sini.

Jadi sekali lagi posting update atau hentikan posting offtopic :)

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 dan @Mimiix Rilisan berikutnya diharapkan akan datang sekitar 2 minggu jika Anda telah melihat bagaimana perilisan ini bekerja oleh DE ("15th" = sedikit sebelum dibayar). Dan tidak ada kata jika salah satu perbaikan berada di dalamnya dengan atau tanpa hari libur.
Dan ada yang mengatakan (dan saya berkali-kali) bagaimana dukungan resmi bekerja kemudian pelanggan mengalami masalah besar.
Tidak dicatat: ZHA dalam 1 - 2 minggu mendapatkan dukungan resmi untuk Silabs EZSP semua versi protokol tumpukan mereka jadi saya pikir satu Jembatan Sonoff Zigbee atau Elelabs-ELU013 / ELR023 lebih baik menggunakan uang dan mendapatkan lebih banyak daya RF dan SoC kemudian produk DE dan dukungan yang lebih baik dari komunitas.
Tapi saya menunggu deCONZ REST-API versi 2 sebelum mengizinkan semua produk DE RIP.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.
_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.
2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Tolong izinkan saya menyarankan Anda untuk mengendalikan emosi Anda. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan topik dan sopan. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.
Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan lakukan itu dalam masalah ini.

Dan lagi, Anda tidak menjawab atau memperbarui status yang ditanyakan berkali-kali dan satu-satunya hal yang Anda lakukan adalah melanjutkan dengan diskusi offtopic di mana Anda sudah dapat memberikan pembaruan seperti yang diminta di akhir setiap posting. Anda membual tentang koneksi / undangan langsung dalam pertemuan pengembangan, jadi Anda harus mengetahui status masalah ini dan dapat memperbarui semua pengguna yang membaca di sini.

Jadi sekali lagi posting update atau hentikan posting offtopic, saya rasa itu adalah tugas Anda sebagai moderator komunitas daripada menjaga diskusi offtopic tetap hidup :)

Pengumuman umum:
Saya baru saja berbicara dengan @manup secara pribadi tentang ini. Dia memberi tahu saya hal berikut:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Saya akan terus mengabari Anda.

2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya, apa yang bisa kami harapkan pengguna?

Untuk menjawab pertanyaan Anda secara langsung: Itulah yang @manup katakan kepada saya setelah saya bertanya lagi kepadanya. Saya tidak bisa memaksa siapa pun untuk melakukan sesuatu. Saya akan bertanya lagi setelah akhir pekan.

Ini akan menjadi peringatan umum terakhir pada komentar Anda. Komentar di luar topik berikutnya di sini membuat masalah ini dikunci hingga ada lebih banyak berita.

@ JBS5 Belum 3 minggu. Menunggu bot basi di sini;)
Pmed @manup pagi ini lagi. Mendapat respon berikut:

Have been crawling in the firmware the last couple of days to investigate the reboot issues and found some nasty bugs.
It will also contain a few routing changes, hope to get it out with the coming release.

The debug enhancements will follow after the next stable release.

Saya meminta ETA dan dia sedang melakukannya saat ini.

Nah kamu sudah berjanji kepada komunitas jadi wajar saja mereka menepati janji itu, 21 hari / 7 hari = 3 minggu
Maka timpang bersembunyi di balik stalebot ketika isu ini sudah aktif sejak Februari 2019. Ketika Anda ingin menjadi juru bicara Dresden bertindak seperti itu atau biarkan @manup menangani ini :)
Jadi berapa ETA sekarang 2-3 minggu telah berlalu

Saya tidak punya masalah untuk meninggalkan masalah ini ketika Anda bertindak seperti ini. Saya sama sekali bukan juru bicara, saya berusaha keras untuk menyelesaikan masalah karena saya memiliki hubungan langsung. Bot usang yang saya gunakan untuk melacak masalah dan saya mendapatkan notifikasi. Saya berharap manup kembali kepada saya dan jika kerangka waktu berlalu, bot basi membantu saya mengingatkan.
Jadi tidak, bukan "lumpuh" untuk bersembunyi di baliknya. Jika Anda melakukan apa yang saya lakukan untuk komunitas, Anda akan tahu lebih baik dari itu. Juga untuk menambahkan itu, bukan karena saya tidak memiliki hal lain untuk dilakukan dalam hidup.
_Jadilah perubahan yang ingin Anda lihat di dunia ini_

Tidak ada yang meminta atau memaksa Anda untuk menjadi perantara sebagai pengguna, jadi sekali lagi alih-alih menyalakan dan mengubah kekuatan bunga, tinggalkan masalah ini sebagai juru bicara atau kembali ke masalah dan informasi terbaru.
2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya?

Yang saya miliki hanyalah apa yang saya sebutkan. Tolong izinkan saya menyarankan Anda untuk mengendalikan emosi Anda. Saya memahami kemarahan Anda, tetapi bersikap tidak hormat tidak membantu. Saya tidak menerima nyala api di sini. Pertahankan topik dan sopan. Saya hanya menjelaskan apa argumen saya dan mengapa saya melakukan sesuatu dengan cara yang saya lakukan.
Jika Anda ingin memulai masalah untuk mengeluh, jadilah tamu saya. Jangan lakukan itu dalam masalah ini.

Dan lagi, Anda tidak menjawab atau memperbarui status yang ditanyakan berkali-kali dan satu-satunya hal yang Anda lakukan adalah melanjutkan dengan diskusi offtopic di mana Anda sudah dapat memberikan pembaruan seperti yang diminta di akhir setiap posting. Anda membual tentang koneksi / undangan langsung dalam pertemuan pengembangan, jadi Anda harus mengetahui status masalah ini dan dapat memperbarui semua pengguna yang membaca di sini.
Jadi sekali lagi posting update atau hentikan posting offtopic, saya rasa itu adalah tugas Anda sebagai moderator komunitas daripada menjaga diskusi offtopic tetap hidup :)

Pengumuman umum:
Saya baru saja berbicara dengan @manup secara pribadi tentang ini. Dia memberi tahu saya hal berikut:

My plan is that this next firmware is available within the next 2–3 weeks.

Some changes are already done but are not public yet.

Saya akan terus mengabari Anda.

2-3 minggu telah berlalu yang telah Anda posting sebagai pengumuman umum lebih dari 3 minggu sekarang, jadi apa tindak lanjutnya, apa yang bisa kami harapkan pengguna?

Untuk menjawab pertanyaan Anda secara langsung: Itulah yang @manup katakan kepada saya setelah saya bertanya lagi kepadanya. Saya tidak bisa memaksa siapa pun untuk melakukan sesuatu. Saya akan bertanya lagi setelah akhir pekan.

Ini akan menjadi peringatan umum terakhir pada komentar Anda. Komentar di luar topik berikutnya di sini membuat masalah ini dikunci hingga ada lebih banyak berita.

Itu sedikit jawaban, jadi ketika saya membacanya dengan benar kita dapat mengharapkan jawaban yang lebih rinci akhir minggu ini karena hampir 4 minggu telah berlalu, bukan 2-3 yang @manup telah komunikasikan melalui Anda sebagai pengumuman umum bahwa pembaruan akan dilakukan tersedia

@Mimiix jika Anda melihat dorongan untuk menutup masalah ini yang hampir terbuka selama dua tahun dengan banyak informasi dari pengguna yang sangat mendukung dan berdedikasi tanpa solusi maka saya bukan orang yang dapat menahan Anda, itu terserah Anda sebagai komunitas juru bicara :)

@lubbertkramer saya bilang Lock, tidak dekat.

Dan dengan itu, saya akan mengunci masalah ini. Saya akan membuka kunci dalam beberapa hari atau ketika Manuel menjawab di sini.

Hai lagi, tebak sudah lebih dari waktunya untuk pembaruan tentang masalah ini.

Tapi hal pertama yang pertama, jika ada yang harus disalahkan di sini itu aku dan hanya aku. Saya mengerti frustrasinya tetapi tidak ada ruang untuk bersikap tidak sopan di sini terhadap

Pembaruan kemajuan

(Pratinjau untuk rilis berikutnya)

Saya telah banyak menguji dengan perutean sumber dan melakukan percobaan dengan temuan dalam masalah ini dan berbagai log sniffer. Luangkan banyak waktu agar perutean sumber "otomatis" berfungsi dengan andal, berdasarkan perintah Catatan Rute yang masuk. Yang pada dasarnya adalah apa yang dilakukan sebagian besar implementasi dengan perutean sumber - seperti firmware perutean sumber untuk zigbee2mqtt. Kadang-kadang berfungsi, tetapi tampaknya ada dinamika yang lebih besar tentang bagaimana / jika rute sumber dipilih (dan disimpan) berdasarkan nilai LQI / RSSI yang dilihat oleh hop Route Record dari tetangganya, dalam jaringan campuran ini rumit karena perbedaan stack dan hardware. Kualitas link juga bisa sangat dinamis jika orang bergerak di antara node dan pintu dibuka dan ditutup, yang sayangnya mempengaruhi routing juga.

Oleh karena itu saya telah bereksperimen dengan ide untuk mengkonfigurasi rute sumber tetap menuju node tujuan. Dalam banyak kasus hanya sebagian dari jaringan yang memiliki masalah perutean, di sini akan bermanfaat untuk menentukan rute sumber tetap di mana:

• Rute sumber dapat ditentukan secara opsional per node.
• Setiap lompatan harus selalu bertenaga.
• Posisi lompatan melalui jalur harus masuk akal. Dalam beberapa kasus, pengguna mungkin memiliki rencana yang lebih baik di mana paket harus dirutekan daripada yang dapat diketahui oleh algoritme otomatis.

Untuk melakukan itu, protokol firmware telah diperpanjang untuk menyediakan rute sumber secara opsional sesuai permintaan APS. Tidak ada batasan berapa banyak rute sumber yang dapat dikonfigurasi, firmware hanya perlu menyimpan beberapa di memori untuk permintaan dan ACK.

deCONZ secara otomatis mengetahui apakah setiap lompatan pada rute dapat dijangkau dan hanya dalam kasus tersebut menggunakan rute sumber.
Rute sumber di balik layar dikonfigurasi dengan alamat MAC dari node agar tahan terhadap perubahan alamat NWK.

Membuat rute sumber tetap

• Pada gui deCONZ pilih semua hop sambil menahan CTRL (banyak pilihan) mulai dari koordinator (sumber) hingga node tujuan. Penting setidaknya perlu ada satu lompatan antara sumber dan tujuan.
• Klik kanan pada node tujuan untuk membuka menu konteks.
• Pilih "Tambahkan rute sumber".

Ini akan membuat rute sumber baru, divisualisasikan dengan garis kebiruan, tanda ujung merah ke simpul tujuan.

(Pada rilis selanjutnya, dimungkinkan untuk menentukan rute fallback alternatif tetapi saya perlu mencari tahu ui yang baik untuk itu.)

Untuk menghapus rute sumber: Pilih "Hapus rute sumber" di menu konteks node tujuan.

Rute ini akan digunakan untuk permintaan berikutnya:

Ini bekerja dengan cukup baik dan memungkinkan penimpaan perutean secara manual jika diperlukan, seharusnya berguna untuk pengujian juga.
Saat ini ini hanya berfungsi ketika dikonfigurasi melalui GUI, tetapi harus tersedia melalui REST-API juga nanti.

Apakah ini akan memperbaiki semuanya?

Tidak mungkin, tetapi harus meningkatkan perutean menuju tujuan (perutean pada node itu sendiri tidak dapat dikonfigurasi). Perhatikan rute sumber tetap hanya baik untuk router, karena perangkat akhir cenderung mengubah induk dan rute sumber tidak akan berfungsi lagi, dalam hal ini perutean sumber otomatis mungkin berfungsi lebih baik.

Kapan akan dirilis?

Segera, di rilis 2.05.81 berikutnya, saya memiliki item berikut (agak ringan) di daftar rencana untuk rilis:

• Simpan / pulihkan rute sumber dalam database.
• Perbaiki penanganan penghitung keamanan NWK untuk memperbaiki cadangan antara ConBee / RaspBee yang berbeda dan reboot tidak ada bug yang berfungsi.
• Biarkan GCFFlasher memverifikasi firmware berjalan setelah pembaruan.

Makanya dengan @manup respon nya sudah dikasih jawaban. Harap tetap pada topik dan subjek.

Hai lagi, tebak sudah lebih dari waktunya untuk pembaruan tentang masalah ini.

Pembaruan kemajuan

(Pratinjau untuk rilis berikutnya)

Saya telah banyak menguji dengan perutean sumber dan melakukan percobaan dengan temuan dalam masalah ini dan berbagai log sniffer. Luangkan banyak waktu agar perutean sumber "otomatis" berfungsi dengan andal, berdasarkan perintah Catatan Rute yang masuk. Yang pada dasarnya adalah apa yang dilakukan sebagian besar implementasi dengan perutean sumber - seperti firmware perutean sumber untuk zigbee2mqtt. Kadang-kadang berfungsi, tetapi tampaknya ada dinamika yang lebih besar tentang bagaimana / jika rute sumber dipilih (dan disimpan) berdasarkan nilai LQI / RSSI yang dilihat oleh hop Route Record dari tetangganya, dalam jaringan campuran ini rumit karena perbedaan stack dan hardware. Kualitas link juga bisa sangat dinamis jika orang bergerak di antara node dan pintu dibuka dan ditutup, yang sayangnya mempengaruhi routing juga.

Oleh karena itu saya telah bereksperimen dengan ide untuk mengkonfigurasi rute sumber tetap menuju node tujuan. Dalam banyak kasus hanya sebagian dari jaringan yang memiliki masalah perutean, di sini akan bermanfaat untuk menentukan rute sumber tetap di mana:

• Rute sumber dapat ditentukan secara opsional per node.
• Setiap lompatan harus selalu bertenaga.
• Posisi lompatan melalui jalur harus masuk akal. Dalam beberapa kasus, pengguna mungkin memiliki rencana yang lebih baik di mana paket harus dirutekan daripada yang dapat diketahui oleh algoritme otomatis.

Untuk melakukan itu, protokol firmware telah diperpanjang untuk menyediakan rute sumber secara opsional sesuai permintaan APS. Tidak ada batasan berapa banyak rute sumber yang dapat dikonfigurasi, firmware hanya perlu menyimpan beberapa di memori untuk permintaan dan ACK.

deCONZ secara otomatis mengetahui apakah setiap lompatan pada rute dapat dijangkau dan hanya dalam kasus tersebut menggunakan rute sumber.
Rute sumber di balik layar dikonfigurasi dengan alamat MAC dari node agar tahan terhadap perubahan alamat NWK.

Membuat rute sumber tetap

• Pada gui deCONZ pilih semua hop sambil menahan CTRL (banyak pilihan) mulai dari koordinator (sumber) hingga node tujuan. Penting setidaknya perlu ada satu lompatan antara sumber dan tujuan.
• Klik kanan pada node tujuan untuk membuka menu konteks.
• Pilih "Tambahkan rute sumber".

Ini akan membuat rute sumber baru, divisualisasikan dengan garis kebiruan, tanda ujung merah ke simpul tujuan.

(Pada rilis selanjutnya, dimungkinkan untuk menentukan rute fallback alternatif tetapi saya perlu mencari tahu ui yang baik untuk itu.)

Untuk menghapus rute sumber: Pilih "Hapus rute sumber" di menu konteks node tujuan.

Rute ini akan digunakan untuk permintaan berikutnya:

Ini bekerja dengan cukup baik dan memungkinkan penimpaan perutean secara manual jika diperlukan, seharusnya berguna untuk pengujian juga.
Saat ini ini hanya berfungsi ketika dikonfigurasi melalui GUI, tetapi harus tersedia melalui REST-API juga nanti.

Apakah ini akan memperbaiki semuanya?

Tidak mungkin, tetapi harus meningkatkan perutean menuju tujuan (perutean pada node itu sendiri tidak dapat dikonfigurasi). Perhatikan rute sumber tetap hanya baik untuk router, karena perangkat akhir cenderung mengubah induk dan rute sumber tidak akan berfungsi lagi, dalam hal ini perutean sumber otomatis mungkin berfungsi lebih baik.

Kapan akan dirilis?

Segera, di rilis 2.05.81 berikutnya, saya memiliki item berikut (agak ringan) di daftar rencana untuk rilis:

• Simpan / pulihkan rute sumber dalam database.
• Perbaiki penanganan penghitung keamanan NWK untuk memperbaiki cadangan antara ConBee / RaspBee yang berbeda dan reboot tidak ada bug yang berfungsi.
• Biarkan GCFFlasher memverifikasi firmware berjalan setelah pembaruan.

Terima kasih atas tanggapan yang mendetail, saya rasa banyak dari kita yang menunggu tanggapan seperti di atas karena semua kerja keras yang dilakukan komunitas untuk masalah ini dan Anda lakukan sebagai pengembang.

Beberapa pertanyaan lanjutan yang saya miliki:

• Kapan di atas akan tersedia sebagai pembaruan dalam beta / stabil?

• Apakah akan ada perbedaan cara kerja di atas untuk conbee 1/2 dan Raspbee atau akankah ini semua sama?

• Untuk pembaruan 2.05.81 Anda menyebutkan memiliki item yang agak (ringan) pada daftar rencana, kapan kita dapat mengharapkan pembaruan itu (mungkin itu ide untuk menambahkan peta jalan ke git ini?)

Hai @lubbertramer

Saya dapat menjawab nomor 1: Versi 2.05.81 diharapkan pada tanggal 15 bulan ini (Windows membangun beberapa hari kemudian). Saya telah menempatkannya pada pengumuman sebelumnya di Discord, tetapi saya baru saja berpikir bahwa itu bukan kasus Github. Saya akan menambahkannya ke readme! Salahku!

Edit: Melakukan permintaan Pull dari file readme.md. Saya tidak yakin bagaimana saluran stabil berjalan yang perlu diklarifikasi sedikit.

Apakah akan ada perbedaan cara kerja di atas untuk conbee 1/2 dan Raspbee atau akankah ini semua sama?

Seharusnya berfungsi sama, saya sekarang telah mem-porting kode ke RaspBee I / ConBee I dan rute sumber digunakan di sana dengan cara yang sama.

Saat ini saya memiliki kasus aneh di mana steker repeater IKEA hidup tetapi tidak ingin bermain-main dengan jaringan lainnya.
Perintah yang dikirim ke sana (dengan dan tanpa rute sumber) diabaikan secara diam-diam.

Repeater mengirimkan bingkai Status Tautan NWK, tetapi melaporkan dan daftar tetangga kosong:

Perintah dari koordinator serta sensor OSRAM yang repeaternya adalah induknya akan diabaikan. Sensor, seperti banyak perangkat Xiaomi, tidak mencoba mencari orang tua baru secara otomatis ... situasi buruk:

Skenario ini berjalan selama dua hari, belum menemukan cara untuk memulihkan repeater. Mungkin siklus daya pengulang akan memperbaiki masalah, tetapi saya akan tetap seperti ini untuk saat ini untuk melihat apakah itu dapat diselesaikan entah bagaimana melalui udara.

Ada masalah dengan repeater USB Tradfri atau steker Tradfri?

Dalam hal ini itu adalah steker, saya tidak yakin apakah itu versi terbaru, perlu memeriksanya nanti.

Apakah mungkin untuk diperiksa? Saya memiliki 3 colokan Tradfri yang menjalankan FW rock solid terbaru selama sekitar 1,5 tahun. Jika saya mulai bermasalah dengan mereka dengan versi beta baru, saya harus menunda pembaruan.

Terima kasih!

Ini adalah data dari cluster dasar, perhatikan masalah pertama kali terjadi dua hari yang lalu di jaringan rumah saya yang tidak memiliki firmware baru pada saat itu.

Sepertinya Anda menggunakan FW terbaru sebagai colokan saya. Saya berharap itu terjadi, karena Ikea FW lama ...

Halaman web dengan log perubahan tradfri tidak aktif, untuk memeriksa apa yang diperbaiki FW terbaru.

File firmware terbaru sedang online sekarang:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I dan ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• Ini memiliki perutean sumber diaktifkan dengan maks. 32 rute sumber, di mana entri terlama diganti secara otomatis dengan yang lebih baru. Jumlahnya kemungkinan akan meningkat di rilis selanjutnya, tetapi seharusnya sudah berfungsi dengan baik.
• Jika rute sumber dan entri rute "normal" ada, rute sumber lebih disukai. Ini tidak standar tetapi tampaknya berfungsi lebih baik.
• Firmware memiliki peningkatan umum untuk ketahanan protokol serial.
• ConBee II dan RaspBee II mendapatkan penanganan penghitung bingkai yang lebih baik, untuk mengurangi masalah di mana setelah siklus daya, jaringan mungkin tampak hilang hingga penghitung bingkai mencapai nilai lamanya lagi.

@manup melakukan firmware untuk ConBee Saya menjatuhkan version perintah id 0x0D ? Saya tidak mendapat tanggapan lagi untuk perintah ini

@Adminiuga @manup Hal-hal tentang firmware: Gunakan # 3260.

File firmware terbaru sedang online sekarang:

ConBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF

RaspBee II

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF

RaspBee I dan ConBee I

http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF

• Ini memiliki perutean sumber diaktifkan dengan maks. 32 rute sumber, di mana entri terlama diganti secara otomatis dengan yang lebih baru. Jumlahnya kemungkinan akan meningkat di rilis selanjutnya, tetapi seharusnya sudah berfungsi dengan baik.
• Jika rute sumber dan entri rute "normal" ada, rute sumber lebih disukai. Ini tidak standar tetapi tampaknya berfungsi lebih baik.
• Firmware memiliki peningkatan umum untuk ketahanan protokol serial.
• ConBee II dan RaspBee II mendapatkan penanganan penghitung bingkai yang lebih baik, untuk mengurangi masalah di mana setelah siklus daya, jaringan mungkin tampak hilang hingga penghitung bingkai mencapai nilai lamanya lagi.

Bagaimana cara mem-flash firmware ini (saya menggunakan image deCONZ Docker marthoc)?

Saya telah mengunduh file (ConBee II) tetapi instruksi pembaruan manual tidak berlaku untuk gambar Docker deCONZ marthoc dan panduan untuk deCONZ marthoc tidak mengizinkan untuk menggunakan firmware yang tidak termasuk dalam gambar (dan file ini tidak terdaftar tersedia).

Bagaimana cara mem-flash firmware ini (saya menggunakan image deCONZ Docker marthoc)?

Saya cukup mencolokkan dongle USB ke laptop Windows dan melakukannya dari sana dan kembali ke NAS Synology saya setelah selesai.

Bagaimana cara mem-flash firmware ini (saya menggunakan image deCONZ Docker marthoc)?

Saya cukup mencolokkan dongle USB ke laptop Windows dan melakukannya dari sana dan kembali ke NAS Synology saya setelah selesai.

Apakah ada utilitas Windows untuk mem-flash firmware? Jika ya, dapatkah Anda membagikan tautannya?

Bagaimana cara mem-flash firmware ini (saya menggunakan image deCONZ Docker marthoc)?

Saya cukup mencolokkan dongle USB ke laptop Windows dan melakukannya dari sana dan kembali ke NAS Synology saya setelah selesai.

Apakah ada utilitas Windows untuk mem-flash firmware? Jika ya, dapatkah Anda membagikan tautannya?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

Oleh karena itu saya telah bereksperimen dengan ide untuk mengkonfigurasi rute sumber tetap menuju node tujuan. Dalam banyak kasus hanya sebagian dari jaringan yang memiliki masalah perutean, di sini akan bermanfaat untuk menentukan rute sumber tetap di mana:

• Rute sumber dapat ditentukan secara opsional per node.
• Setiap lompatan harus selalu bertenaga.
• Posisi lompatan melalui jalur harus masuk akal. Dalam beberapa kasus, pengguna mungkin memiliki rencana yang lebih baik di mana paket harus dirutekan daripada yang dapat diketahui oleh algoritme otomatis.

Apakah ini akan memperbaiki semuanya?

Tidak mungkin, tetapi harus meningkatkan perutean menuju tujuan (perutean pada node itu sendiri tidak dapat dikonfigurasi). Perhatikan rute sumber tetap hanya baik untuk router, karena perangkat akhir cenderung mengubah induk dan rute sumber tidak akan berfungsi lagi, dalam hal ini perutean sumber otomatis mungkin berfungsi lebih baik.

Hanya untuk memperjelas ... apakah firmware baru ini akan memperbaiki (atau setidaknya meningkatkan) pemutusan acak perangkat Ikea jika saya tidak secara manual mengkonfigurasi rute sumber statis baru? Atau satu-satunya cara untuk mendapatkan keuntungan dari pembaruan ini adalah dengan mengatur rute perangkat tersebut secara manual yang cenderung kehilangan koneksi?

Tanpa rute pengaturan manual, perutean sumber otomatis terjadi jika perangkat mempromosikannya (seperti yang dilakukan perangkat IKEA).
Jadi dibandingkan dengan perutean sumber firmware sebelumnya akan digunakan untuk perangkat ini jika rute seperti itu diketahui.

Jika benar-benar membantu tetap terbuka, alangkah baiknya jika siapa saja yang memiliki masalah rutin dengan firmware sebelumnya dapat melaporkan jika ada yang berubah.

Dalam jaringan pengujian saya, firmware bekerja dengan cukup baik dan rute sumber sering digunakan seperti yang ditunjukkan oleh log sniffer. Itu tidak berarti banyak karena bahkan tanpa perutean sumber, jaringan saya cukup solid.

Saya memiliki 21 lampu (4 - 980lu WS, 17 - 1000lu WS), 3 colokan dan 3 (5 tombol) remote putaran Ikea. Semuanya di Ikea FWs terbaru. Saya tidak pernah mengalami ketidakstabilan dengan mereka selama sekitar 1,5 tahun terakhir. Nighter dengan versi deCONZ sebelumnya atau rilis FW atau dengan yang saat ini. Saya menjalankan 0,81 stabil dengan RaspBee FW 0x26370500 terbaru, dan juga tidak mengalami masalah apa pun selama minggu terakhir menggunakannya.

Saya kira .... (mungkin saya kurang tepat) Ikea tidak memiliki masalah umum, tetapi pengaturan khusus. Ada banyak faktor berbeda yang dapat memengaruhi perilaku dan performa mereka di deCONZ dan secara umum.

Saya pikir sebagian besar masalah terjadi dengan Lampu Ikea GU10. Stabilitas telah meningkat pesat dari waktu ke waktu, tetapi berantakan pada akhir 2018 ketika saya mulai. Saya harus menyalakan satu dari 30 GU10 rata-rata setiap dua minggu selama tiga bulan terakhir rilis / firmware.

Saya pikir sebagian besar masalah terjadi dengan Lampu Ikea GU10. Stabilitas telah meningkat pesat dari waktu ke waktu, tetapi berantakan pada akhir 2018 ketika saya mulai. Saya harus menyalakan satu dari 30 GU10 rata-rata setiap dua minggu selama tiga bulan terakhir rilis / firmware.

Bisa jadi. GU10 belum menerima pembaruan FW seperti lampu Ikea lainnya, sejauh yang saya tahu. Baru-baru ini, kami mendiskusikannya di saluran perselisihan. Seorang pengguna yang menjalankan lampu GU10 Ikea mengalami perilaku seperti itu. Tidak peduli apa yang kami coba, sepertinya tidak ada yang memecahkan masalahnya. Dia bahkan berbagi dengan kami bahwa dia membeli Ikea Tradfri Hub dan dia juga memiliki pengalaman buruk yang sama, bahkan dengan lampu Ikea Hub dan GU10.

Jadi, saya kira ini masalah waktu Ikea merilis FW baru untuk jenis lampu ini untuk mungkin mengatasi / memperbaiki masalah ini ....

Saya ingin tahu apakah @djwlindenaar sudah mengupdate deCONZ dan firmware terbaru dan bisa berbagi pengalamannya? :)

Sebenarnya belum ... Saya belum menemukan waktu untuk meningkatkan. Saya juga tidak menemukan waktu untuk beralih ke z2mqtt, jadi kabar baiknya adalah saya akan meningkatkan ke firmware baru dan jika ada yang perlu dilaporkan, saya akan melakukannya.

Jika benar-benar membantu tetap terbuka, alangkah baiknya jika siapa saja yang memiliki masalah rutin dengan firmware sebelumnya dapat melaporkan jika ada yang berubah.

Saya telah memperbarui ke firmware terbaru 2 hari yang lalu dan sejak itu salah satu sakelar dinding Xiaomi saya (ctrl_neutral2, 11-25-2017) beralih sendiri 3 kali. Saya belum pernah mengalami masalah seperti itu sebelumnya.

Terhubung ke koordinator melalui lampu Tradfri E27 CWS di 1.3.009.

Selain itu, tidak sepenuhnya terkait dengan masalah ini, tetapi saya tidak pernah berhasil mendapatkan pembaruan OTA dengan Deconz (wadah komunitas).

Saya memiliki lampu Tradfri:

• E27 CWS pada 1.3.009
• E14 W pada 1.2.214
• Peredup nirkabel pada 1.2.248
• 17 * GU10 WS pada 1.2.221

Saya dapat melihat file Trafri OTA diunduh tetapi tidak ada yang terjadi. Apa yang harus saya lakukan?

Sebagai referensi, beginilah cara wadah dimulai:

docker run -d --name=deconz --net=host --restart=always -v /etc/localtime:/etc/localtime:ro -v /opt/otau:/root/otau -v /opt/deconz:/root/.local/share/dresden-elektronik/deCONZ --device=/dev/ttyACM0 -e DECONZ_WEB_PORT=801 -e DECONZ_WS_PORT=445 -e DECONZ_VNC_PORT=5930 -e DECONZ_VNC_PASSWORD=... -e DECONZ_VNC_MODE=1 -e DEBUG_INFO=1 marthoc/deconz

@ ReX1983 Ini tidak ada hubungannya dengan masalah ini di sini, afaik. Silakan buka masalah terpisah. Saya pikir Anda harus memposting di repo versi Docker. https://github.com/marthoc/docker-deconz

Catatan moderasi:

Sebelum semuanya tercampur di sini, saya ingin menetapkan cakupan di sini.

Apa pun yang terkait dengan masalah asli: Lampu IKEA yang terkadang kehilangan koneksi diperbolehkan dalam masalah ini.

Masalah lain yang terkait dengan firmware dapat diposting di sini

Sebenarnya belum ... Saya belum menemukan waktu untuk meningkatkan. Saya juga tidak menemukan waktu untuk beralih ke z2mqtt, jadi kabar baiknya adalah saya akan meningkatkan ke firmware baru dan jika ada yang perlu dilaporkan, saya akan melakukannya.

@ JBS5 , pemicu Anda membantu;)

Saya baru saja menginstal firmware dan deCONZ .deb terbaru. Sejauh ini saya dapat mengonfirmasi bahwa perutean sumber berfungsi, tentu saja belum ada kesimpulan tentang stabilitasnya. Aku akan mengabarimu

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

@ ReX1983 Lihat bagaimana plugin OTA bekerja https://github.com/dresden-elektronik/deconz-ota-plugin dan memperbarui perangkat Anda.
Maaf, tapi itu masalah komunikasi perangkat IKEA.

@ morfei @ peer69
Saya dapat mengonfirmasi bahwa ini tidak hanya disebabkan oleh bola lampu GU10. Saya mengalami masalah perutean dan kehilangan koneksi untuk waktu yang lama tanpa GU10 di sistem saya.

Saya mengalami beberapa masalah awal setelah rilis .82 dengan firmware baru pada conbee 1 saya.
Tapi sekarang setelah jaring jaringan diselesaikan dan beberapa siklus daya menjadi kokoh selama beberapa hari terakhir.

Betapa bodohnya saya, saya memutuskan untuk memperbarui ke firmware terbaru (OTAU) pada semua bohlam saya untuk memiliki dasar yang lebih baik untuk memulai jika ada masalah di masa mendatang. Doakan aku. Akan terus mengabari kemajuan Anda.

@ Tubalainen apakah Anda menggunakan pengaya HA?

@ Tubalainen apakah Anda menggunakan pengaya HA?

Tidak, saya menggunakan HA Core pada Debian di buruh pelabuhan - jadi saya juga menggunakan https://github.com/marthoc/docker-deconz paket buruh pelabuhan stand-a-lone. Mereka berdua menggunakan file .deb yang disediakan oleh dresten sehingga mereka harus bekerja sama. Saya tidak yakin apakah plugin OTAU disertakan dalam add-on deconz HA ....

sejauh ini hanya menyumbang pengamatan saya;

Saya hanya memiliki masalah dengan Ikea GU-10 saya (23 di antaranya), dan saya menggunakan asisten Rumah, yang terhubung ke deconz (buruh pelabuhan) melalui rest api, dan saya dapat melihat HA menjalankan acara untuk mendekonz dengan sukses.

Ketika saya menggunakan HA untuk menyalakan, 17 lampu, satu-per-satu (tepat setelah satu sama lain) mungkin 3 dari 17 dosnt menyala, tetapi HA melihatnya seperti pada.
TAPI, jika saya membuat grup di deconz. letakkan semua lampu di grup itu, dan beri tahu HA untuk menyalakan grup itu, belum ada masalah, semua lampu menyala.

Menggunakan firmware: 0x26650700 saya belum melihat peningkatan (selain saya harus memasangkan kembali 17 bola lampu itu karena alasan tertentu, dan bahkan setelah memasangkan kembali saya memiliki masalah yang sama)

apakah itu batasan pada rest-api mungkin?

@MartinTerp , jika Anda menggunakan satu perintah untuk setiap perangkat pada satu waktu, daripada 1 perintah ke grup itu akan gagal, mungkin tidak setiap saat tetapi sebagian besar waktu perangkat acak yang seharusnya melakukan sesuatu tidak akan melakukan itu.

Solusi saya untuk ini adalah penundaan 5 detik antar perintah. Sebagai contoh
Jika saya ingin menyalakan lampu kamar tidur saya pada pukul 23:00 pada bri: 127 dan ct: 454, dan juga di lorong saya, saya memberikan penundaan 5 detik untuk salah satu ruangan. Jika saya tidak menunda, itu akan gagal secara acak untuk menyelesaikan perintah penuh untuk salah satu ruangan atau mungkin untuk keduanya. Saya banyak bereksperimen dengan ini. Ini sesuatu yang mirip seperti bug Ikea yang tidak dapat menangani warna dan kecerahan pada saat yang bersamaan.

Saya tidak tahu persis apa ini, bug deconz, batasan zigbee secara umum atau bug Ikea FW. Mungkin karena kurangnya pengetahuan saya tentang cara kerja zigbee, tetapi penundaan 5 detik selalu berhasil untuk saya.

Sebagai aturan umum saya selalu menggunakan: pasir perintah sesedikit mungkin pada satu waktu atau gunakan penundaan. Dengan demikian Anda menjaga saluran tetap bersih.

Jika Anda perlu mengganti banyak grup / lampu pada satu waktu, seperti yang Anda perhatikan, lebih baik buat grup phoscon baru, sertakan grup lampu ini di dalamnya dan kirimkan satu perintah grup kepada mereka. Anda dapat memiliki banyak kelompok berbeda termasuk cahaya yang sama. Kami tidak dibatasi hanya menggunakan satu grup per lampu. Jika Anda tidak suka memiliki banyak grup di phoscon, maka penundaan adalah sahabat Anda.

@ morfei1 Saya menggunakan solusi serupa dan bekerja hampir sepanjang waktu dengan penundaan 5 detik antara semua perintah.
@MartinTerp Saya juga mengalami masalah ini dengan perangkat lain selain lampu IKEA-Tradfri, misalnya OSRAM Smart Plugs dan Light Strips. Saya kira itu mungkin meskipun masalahnya disebabkan oleh beberapa Tradfri-Lights yang bermasalah tidak meneruskan perintah.

Tapi seharusnya tidak seperti ini, bukan?
pada saat skrip menyalakannya 1-by-1 dengan penundaan 1 detik, HARUS bisa mengatasinya?

@ morfei1 @ morfei1

Saya juga biasa menggunakan penundaan + yang saya kirim dan nonaktifkan perintah dari asisten rumah dua kali per otomatisasi yang dipicu.

Saya sekarang telah menghilangkan penundaan dan mengulangi perintah sejak 0,82.

Saya cukup yakin ini tidak membutuhkan penundaan 5 detik. Saya pikir ini tidak diperlukan dengan beberapa versi sebelumnya tetapi saya tidak akan bertaruh karena jaringan saya telah berkembang sejak saat itu. Mungkin 82 (belum mencoba dengan penundaan yang dikurangi) atau versi mendatang akan memperbaiki perilaku ini.

@ morfei1 @githtz @tubalainen @martinterp

Bisakah kita berdiskusi tentang cara memperbarui firmware perangkat di tempat lain?

Kami tidak sedang mengupdate firmware?

Ketika saya membacanya dengan benar masalah pengiriman banyak perintah, di mana tidak semua bisa melewatinya berbeda. Ini mungkin lebih merupakan masalah dengan penjadwal tugas.

Saya menyarankan untuk membuka masalah terpisah untuk itu seperti "Tidak semua lampu bereaksi saat mengirim perintah unicast ke beberapa lampu".

Masalahnya di sini lebih banyak tentang kapan lampu benar-benar hilang dan tidak dapat dijangkau sama sekali, yang dapat terkait dengan perutean.

Disunting oleh Mimiix

Disunting oleh Mimiix

@inconsx @ ReX1983 Saya pikir saya sudah jelas di https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 dan https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # Issuecomment -696046160

Harap patuhi aturan ini. Buka masalah terpisah jika Anda mau.

Jadi inilah tanggapan saya, saya telah mengupgrade ke firmware terbaru dan api deconz. Saya menjalankan jaringan saya dari HA.

Saya memiliki sekitar 72 node, kebanyakan adalah lampu IKEA GU10. Setelah upgrade saya melihat dua GU10 berbeda yang "mati" dua hari yang berbeda, satu-satunya cara untuk mendapatkannya kembali adalah dengan power cycle. GU10 menggunakan perlengkapan 1.2.217 dan 1.2.221. Saya akan mencoba memutakhirkan semuanya ke versi yang sama.

Saya hanya memiliki 4 GU10, saya rasa ini dari versi rilis pertama, berjalan pada versi ota terbaru. Tidak pernah ada masalah dengan ini dalam hal jangkauan, hanya adegan saya yang kacau setelah pembaruan firmware ringan.

Saya baru saja memiliki salah satu bohlam IKEA TRADFRI E14 W op / ch 400lm Versi 1.2.214 berhenti merespons. Lampu ini telah melakukan ini berkali-kali dan pada firmware deconz yang berbeda. Saat ini saya menggunakan deconz 26370500 dan 2.05.82.

Saya hanya memiliki 4 GU10, saya rasa ini dari versi rilis pertama, berjalan pada versi ota terbaru. Tidak pernah ada masalah dengan ini dalam hal jangkauan, hanya adegan saya yang kacau setelah pembaruan firmware ringan.

Pernahkah Anda melihat peningkatan stabilitas dengan bohlam GU10 ini setelah memperbarui ke 2.3.050? Saya sekarang menggunakan 0x26650700 dan sejak pembaruan ke 2.3.050 (dari 17 bohlam) tampaknya jaringan saya jauh lebih stabil. Perangkat tidak offline dalam semalam dan tombol / sakelar Aqara saya berfungsi pada upaya pertama. Sekarang sudah 4 hari, terlalu dini untuk mengatakannya.

Saya hanya memiliki 4 GU10, saya rasa ini dari versi rilis pertama

Sebenarnya ada versi IKEA GU10 yang lebih murah (hanya W). Mereka tidak pernah diperbarui ke perangkat lunak 2.x dan masih berjalan di 1.2.214. Dan inilah yang paling bermasalah. Saya pribadi menyerah begitu saja dan sekarang semuanya berjalan lancar dengan hub IKEA.

Saya pikir @antonbo semakin dekat dengan jalannya masalah.
IKEA menggunakan gambar firmware yang sama dengan perangkat keras yang berbeda (drive PSU / LED) dan memiliki pengaturan yang berbeda di "data pengguna" untuk perangkat keras yang berbeda (dan ID model disimpan di dalamnya). Jadi satu firmware dapat berfungsi dengan baik pada satu perangkat keras (E14) dan mengalami masalah pada perangkat lain (GU10 / E27).
Satu perbedaan adalah IKEA GW berjalan dalam mode ZLL (pada Zigbee PRO) dan tidak menarik status perangkat hanya mendengarkan pada perubahan status perangkat yang dikirim dalam jaringan (ala Zigbee PRO / standar ZB3) dan mencampurnya dengan HUE dan lainnya vendor yang statusnya ditarik oleh koordinator dari perangkat (Bukan perilaku ZB3) dapat membuat satu kekacauan jaringan.
Saya memiliki IKEA RGBW tertua dan satu E27 Opal WW pada firmware lama yang diperbarui (1.X) yang berjalan OK dan satu kelompok ZB3 GU10 WS baru yang berfungsi dengan baik. Tulang punggung saya sekitar 10 colokan IKEA yang menahan komunikasi jaringan stabil dan juga sensor Xioami saya berfungsi dengan baik dengan semuanya.
Perasaan saya adalah bahwa tidak ada satu masalah umum lagi HW dan mungkin FW dalam kombinasi dengan tata letak jaringan dan menghindari beberapa perangkat bermasalah (seperti OSRAM Outdoor Plug yang merusak paket dan kehilangan anak sepanjang waktu).

@ Manup Saya hanya dapat mengatakan bahwa untuk sistem saya, firmware baru membuatnya jauh lebih buruk daripada sebelumnya. Entah itu perutean sumber atau apa adanya, saya sekarang memiliki setiap hari satu atau dua lampu macet dan membutuhkan siklus daya. Saya bahkan telah melihat salah satu lampu rona Philips saya macet tetapi itu tidak memerlukan siklus daya. Saya tidak tahu apakah masalahnya sekarang disebabkan oleh firmware lama yang saya jalankan pada mereka tetapi sekali lagi saya tidak dapat memutakhirkan karena macet. :(

Saya ingin tahu apakah ada yang tahu apakah GU10 yang lebih baru masih memiliki masalah atau mereka tidak memiliki masalah? Saya mendengar perangkat yang lebih baru menjalankan zigbee 3.0, istri saya tidak senang dengan masalah ini sehingga saya dapat mengubah semuanya jika membantu?

Saya memiliki lampu gantung pagi ini. Saya pikir itu salah satu yang lebih baru.

Lampu tidak bereaksi terhadap perintah apa pun, ditampilkan sebagai offline. Siklus listrik tidak memperbaiki masalah. Saya harus mengatur ulang dan menambahkannya kembali ke jaringan.

@ JBS5 @djwlindenaar @lubbertkramer Ada tanggapan tentang firmware terbaru yang dibandingkan dengan masalah ini?

Saya dapat menambahkan bahwa selama 48 jam saya tidak memiliki masalah apa pun tentang topik ini dan apa yang saya alami sebelumnya.

Namun, perlu menambahkan berikut

• restart wadah dengan deconz setiap malam
• memindahkan pengelompokan dari Asisten-Rumah ke deconz / phoscon untuk ditangani.

Saya memiliki beberapa lampu yang kurang responsif sebelum perubahan di atas meskipun pengalamannya lebih baik tetapi tidak seperti sekarang.

@Mimiix , yah, masih terlalu dini untuk diceritakan.

Yang mengganggu saya adalah jaringan terasa jauh lebih lamban. Waktu antara menekan tombol dan lampu menyala (melalui aturan) lebih lama dari sebelumnya. Juga menyalakan lampu dan mengubah kecerahan sekarang adalah proses dua langkah dengan beberapa waktu di antaranya. Saya masih perlu memeriksa log sniff untuk memeriksa apa yang menyebabkan ini. Mungkin ini tidak ada hubungannya dengan perubahan ke perutean sumber, tapi begitulah.

Saya memang memiliki satu lampu yang tidak merespons, tetapi saya juga belum menganalisis situasi itu, sangat sulit untuk mengatakan apa yang terjadi.

Bohlam E27 Ikea saya secara kolektif berhenti untuk bekerja sama.
Sejauh ini, siklus daya telah berhasil untuk beberapa dari mereka. 3 masih belum kembali. Sepertinya saya harus menambahkannya kembali ... :(

Firmware: 26610700
Versi: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Sepertinya ini tidak terkait dengan masalah yang dibahas dalam masalah ini. Silakan buka masalah terpisah :)

Bagi saya, gejalanya hampir sama: Lampu menjadi tidak responsif tanpa alasan yang jelas.

Seperti yang baru saja saya katakan: Ini sepertinya tidak berhubungan. tolong buka masalah terpisah. Kami selalu dapat menentukan setelah itu bahwa ini terkait. Saya tetap memperhatikan masalah ini.

Ya saya juga pikir itu terkait. Setelah beberapa bulan tanpa bug, kemarin saya mengalami masalah lagi dengan dua perangkat, IKEA E27 (sangat tua) dan outlet IKEA yang lebih baru, keduanya pada firmware terbaru.

Satu-satunya hal yang saya lakukan pada saat itu adalah mengangkut seorang KADRILJ buta di luar jangkauan dan kemudian kembali, tetapi ini mungkin sama sekali tidak ada hubungannya.

Mengaktifkan sniffer menunjukkan masalah yang sama:

• Perangkat masih mengirimkan perintah Status Tautan NWK secara berkala;
• Tapi selalu dengan daftar kosong, sepertinya mereka mengabaikan semua router di sekitarnya;
• Mereka ACK perintah masuk pada tingkat MAC;
• Mereka bereaksi terhadap Permintaan Beacon dan mengirimkan Beacon, tetapi hanya itulah "balasan" yang mereka berikan.

Entah bagaimana tampaknya tumpukan Zigbee pada perangkat IKEA rusak sebagian karena lapisan NWK dan APS dan di atasnya atau mungkin buffer NWK yang masuk penuh dan tidak pernah dirilis.

Saya mencoba menghidupkan kembali perangkat dengan mengirim:

• ZDP Pergi dengan bergabung kembali;
• NWK Pergi dengan bergabung kembali (level lebih rendah).

Keduanya diberi ACK pada level MAC tetapi diabaikan.

Saya kemudian mencoba memalsukan perintah Status Tautan NWK koordinator dengan entri yang valid yang menunjukkan bahwa perangkat memiliki biaya tautan masuk dan keluar yang berfungsi (3/3) dengan harapan perangkat akan mengambil koordinator di tabel tetangganya. ... tidak berhasil.

Sayangnya sepertinya tidak ada cara untuk mengatasi situasi tersebut setelah itu terjadi dan perangkat IKEA mengalami keadaan yang sebagian besar mati ini. Melihat melalui beberapa forum, perilaku dapat dilihat dengan semua jenis gateway dan tumpukan Zigbee yang mendasarinya. Yang menarik karena misalnya jembatan Hue tidak melakukan hal-hal Zigbee mewah seperti menanyakan tabel tetangga atau binding dan pelaporan dan masih terjadi bug.

Apa yang perlu dilakukan IKEA adalah setidaknya menerapkan Pengawas yang memeriksa bahwa komponen NWK dan APS masih beroperasi dan membiarkan perangkat memicu pengawas untuk melakukan boot ulang. Ini tidak akan memperbaiki bug tetapi setidaknya akan menjaga perangkat tetap berfungsi ketika itu terjadi.

@ Manup Apakah Anda E27 satu LL tua dengan cluster diagnostik?
Mungkin itu bisa menjadi menarik jika sesuatu terjadi dengan counter di sana dengan beberapa minggu antara.
Itu tidak dapat memperbaiki masalah tetapi memberikan satu petunjuk bahwa firmware tidak berfungsi.
Baik mengamati dan kesimpulan mande !!

Saya pikir Silabs semakin sedikit berburu bug untuk salah satu pelanggan terbesar di sana ;-)

Hai, ini membingungkan saya karena sejak saya pindah ke Z2M menggunakan ZZH beberapa bulan lalu, saya belum melihat masalah ini. Mungkin ada variabel lain dalam persamaan. Akan lebih bagus jika orang lain yang telah melakukan langkah yang sama dapat mengonfirmasi.

@mvjt Apakah Anda menggunakan Rasp / CornBee dengan Z2M atau Koordinator lain?
Tumpukan zigbee yang berbeda bekerja dengan cara yang berbeda dan dapat memiliki / membuat masalah yang berbeda.

Edit: Maaf saya melihat ZZH = koordinator TI baru.
deCONZ NCP = Atmel / Microchip
Perangkat IKEA / NCP = Sirlabs EFR32 / EZSP

Saya dapat memastikan bahwa HA / ZHA / Zigpy / Bellows berfungsi baik dengan modul "Billy EZSP" = IKEA ICC-1-A sebagai koordinator dengan router IKEA dan perangkat akhir dari IKEA dan Xiaomi dan NO OSRAM atau router Xiaomi.

@MattWestb Ya, E27 memiliki kluster Diagnostik tetapi saya belum menyalakannya untuk mempertahankannya dalam status kesalahan. Dengan membaca atribut cluster dari lampu IKEA saya yang lain, laporan atribut semua menjadi tidak tersedia: /

Setidaknya di masa lalu masalah yang saya lihat terjadi juga dengan TI CC253X dan di akhir masalah CC26X2R1 disebutkan, tetapi itu adalah keadaan di bulan Januari yang mungkin telah membaik sementara itu. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Ini mungkin bukan bug Silabs secara umum, bisa juga beberapa hal khusus di lapisan aplikasi. Saya pikir perangkat Hue baru-baru ini juga menggunakan Silab. Dari jembatan Hue setidaknya ada versi TI dan Microchip di luar sana.

Ini adalah hal yang sangat buruk, dalam banyak kasus bug mungkin tidak terjadi sama sekali atau hanya setelah beberapa bulan, di jaringan lain itu terjadi dalam interval yang jauh lebih kecil. Saya rasa juga penting bagaimana jaringan dioperasikan dan lampu yang dimatikan secara teratur tidak terlalu terpengaruh.

@manup Saya punya satu skenario yang menyampaikan dengan baik "masalah IKEA" Anda.
Jika Anda telah menyiapkan jaringan Anda, mulailah dengan satu kunci jaringan dan Penghitung Bingkai Keamanan mulai berdetak. Jika Anda tidak harus mereformasi jaringan atau menggulung kunci jaringan untuk waktu yang lama, penghitung akan terhenti karena telah mencapai maks 0xFFFFFFFF (32 bit) dan tidak dapat meningkat.
Kemudian perangkat membuang semua data yang masuk ke lapisan zigbee karena penghitung bingkai salah tetapi lapisan jaringan di bawah masih berfungsi normal.
Masalahnya saya tidak tahu satu metode mendapatkan status Penghitung Bingkai Keamanan perangkat. Saya pikir itu tidak mungkin melihatnya di Wireshark (berpikir = tidak tahu).

Hal yang menunjukkan hal ini adalah bahwa perangkat yang dipasangkan lebih awal dan tidak disetel ulang lebih cepat macet.
Perangkat baru yang dipasangkan / disetel ulang berjalan lebih lama sebelum penghitung berhenti.
Perintah mutch ke satu perangkat juga membuatnya lebih cepat mengulur dibandingkan satu perangkat yang tidak begitu "komunikatif".

Disarankan untuk menggulirkan kunci jaringan secara teratur di jaringan ZB3 untuk menjaganya tetap aman dan kemudian juga mengatur ulang Penghitung Bingkai Keamanan sehingga tidak terhenti.
Beberapa info AN1233: Zigbee Security 2.1.6 Penghitung Bingkai Keamanan Jaringan.

Ini adalah salah satu curah pendapat liar tetapi bisa jadi masalah datang setelah jaringan berjalan lama.

Satu tes mencoba menggulirkan kunci jaringan dan perangkat "hidup" suld berjalan OK untuk waktu yang cukup lama tetapi yang terhenti harus diatur ulang / digabungkan kembali untuk memulai Penghitung Bingkai Keamanan dari nol.

Hrm, cukup yakin menggulirkan kunci jaringan akan menghapus semua xiaomi.

Salah 200% aman karena mereka tidak memperbarui dan meninggalkan jaringan (yang lama tidak ada ZB3) !!!

@Adminiuga Apakah Anda sudah mencoba menggulirkan kunci jaringan di EZSP?
Saya menemukan itu menarik dari hasilnya !!!

Belum mencoba memutar kunci jaringan. Sebenarnya akan menarik untuk mengetahui berapa banyak implementasi roll key secara teratur.
Tetapi saya dapat mengonfirmasi bahwa perubahan pan-id memiliki peluang xiaomi yang sangat tinggi untuk dijatuhkan, seperti 4 dari 5 peluang

Saya telah melihat beberapa tes penetrasi keamanan yang mengendus pan-ID dari jalan dan kembali beberapa kali dengan beberapa bulan antara dan tidak ada pemasok lampu besar (tidak disebutkan di sini) tidak memutar kunci jaringan setelah satu tahun (Mariahilferstraße di Wien ) sehingga Anda kemungkinan besar memiliki hak (agen).

Jika dan hanya jika penghitung bingkai keamanan yang melakukan masalah maka itu melakukan hal yang sama untuk semua perangkat zigbee 3 yang sebenarnya maka itu didefinisikan dalam "Base-Device-Behavior-Specification" dan direkomendasikan di LL lama tetapi sangat mungkin tidak dengan no perangkat zigbee PRO (HA dan LL lama) atau perangkat yang tidak bersertifikat (tidak bernama .... mi).
Kemudian lebih baik "manual" menggulung kunci jaringan satu atau dua kali setahun dan tidak perlu menghancurkan rumah untuk mengatur ulang perangkat yang dibangun lebih sering di mulut kemudian mereka mengulur-ulur dan mengambil ulang / bergabung kembali dengan sensor Xiaomi lama yang biasanya tidak terintegrasi dalam struktur rumah dan lebih mudah untuk diatur ulang (biasanya membuka bergabung dan menekan tombol dan mereka terhubung).
Menny "Chinese Zigbee 3" membuang penghitung bingkai keamanan "lama" setelah power reset dan menggunakan yang baru dari paket kedatangan pertama dari tetangganya (telah melihat bahwa kemudian menguji masalah tasmotas zigbee 3 maka penghitung NCP salah disetel ulang saat restart) jadi mereka hanya repower dan mereka kembali.

Kami juga melakukan beberapa pengujian tahun lalu, tidak ada gateway yang merotasi kunci jaringan. Seperti yang dijelaskan dalam spesifikasi, itulah satu-satunya cara untuk mengatur ulang penghitung bingkai keamanan NWK saat menambah nomor kunci jaringan. Saya juga berbagi kekhawatiran bahwa ini didukung oleh semua perangkat, biasanya fitur yang hampir tidak pernah digunakan tidak diuji dengan baik. Saya sangat berharap saya salah di sini dan berfungsi untuk sebagian besar perangkat.

Bagaimanapun, mengatur ulang penghitung bingkai adalah yang paling penting untuk gateway karena memiliki jumlah perintah keluar terbesar, lampu dan sensor harus baik-baik saja untuk tahun-tahun berikutnya. Saat ini ini bukan masalah tetapi menjadi masalah dalam 2-3 tahun ketika penghitung gateway tercapai di jaringan yang lebih besar. Untuk itu kami sudah memiliki rencana untuk memeriksa apakah perputaran kunci jaringan serta nomor kunci dan reset penghitung bingkai berfungsi.

Bagaimanapun masalahnya di sini berbeda, penghitung bingkai dari gateway dan lampu dalam status kesalahan masih bagus dan cukup rendah.

@djwlindenaar Saya ingin tahu apakah Anda memiliki temuan baru karena Anda dapat menganalisis temuan secara teknis selain hanya melaporkan bahwa lampu telah mati lagi, seperti yang dapat saya lakukan. Temuan dan wawasan Anda sangat dihargai. :)

Terima kasih atas apresiasinya ... Sejujurnya, saya tidak sepenuhnya senang dengan stabilitas jaringan saat ini. Itu turun sejak memperbarui ke firmware deconz terbaru. Beberapa lampu mati dalam beberapa minggu terakhir, dan hal ini tidak terjadi dalam waktu lama sebelum peningkatan. Saya menjalankan dengan tambalan yang memungkinkan pelaporan atribut reguler untuk lampu IKEA, yang belum saya terapkan dalam situasi saat ini

Meskipun mengasyikkan untuk menganalisis hal ini, ini adalah hobi bagi saya dan waktu saya sekarang sepenuhnya digunakan oleh beberapa renovasi rumah. Saya akan melihat apakah saya bisa meluangkan sedikit waktu untuk itu ...

Terima kasih atas apresiasinya ... Sejujurnya, saya tidak sepenuhnya senang dengan stabilitas jaringan saat ini. Itu turun sejak memperbarui ke firmware deconz terbaru.

Saya mengalami pengalaman negatif yang sama. Sekarang sebagian besar perangkat Xiaomi saya (terutama sakelar dinding Aqara) sering offline di siang hari dan kembali berfungsi setelah beberapa menit (saya kira ini disebabkan oleh fakta bahwa perangkat Xiaomi reboot jika mereka tidak menerima tanggapan atas permintaan atribut cluster Waktu dari koordinator).

Rilis v2.5.88 baru mungkin memperbaiki situasi. Di sini konfigurasi pelaporan IKEA diperhalus sehingga transisi status tidak membombardir jaringan dengan laporan. Sebelumnya selama transisi status, setiap atribut dilaporkan dengan kecepatan yang sangat cepat.

Rilis v2.5.88 baru mungkin memperbaiki situasi. Di sini konfigurasi pelaporan IKEA diperhalus sehingga transisi status tidak membombardir jaringan dengan laporan. Sebelumnya selama transisi status, setiap atribut dilaporkan dengan kecepatan yang sangat cepat.

Kedengarannya menjanjikan :) Juga on / off adalah transisi keadaan, saya kira? Atau sebagian besar kecerahan atau mode warna berubah?
Adakah versi firmware minimal yang diperlukan / direkomendasikan untuk perubahan ini?

Hanya kecerahan dan semua atribut khusus warna seperti colorX, colorY, dan temperatur warna.
Untuk firmware, saya selalu merekomendasikan yang terbaru 0x26660700 (untuk ConBee II dan RaspBee II).

Rilis v2.5.88 baru mungkin memperbaiki situasi. Di sini konfigurasi pelaporan IKEA diperhalus sehingga transisi status tidak membombardir jaringan dengan laporan. Sebelumnya selama transisi status, setiap atribut dilaporkan dengan kecepatan yang sangat cepat.

@manup , saya pikir pembaruan ini juga menyelesaikan masalah stabilitas dengan perangkat Aqara. Terima kasih

Rilis v2.5.88 baru mungkin memperbaiki situasi. Di sini konfigurasi pelaporan IKEA diperhalus sehingga transisi status tidak membombardir jaringan dengan laporan. Sebelumnya selama transisi status, setiap atribut dilaporkan dengan kecepatan yang sangat cepat.

@manup , saya pikir pembaruan ini juga menyelesaikan masalah stabilitas dengan perangkat Aqara. Terima kasih

Sayangnya masalah (# 3605) masih ada, saya terburu-buru mengambil kesimpulan terlalu dini