deconz-rest-plugin 🚀 - IKEAライトが時々接続を失った

ここでは2.05.58と同じです。 1つのTradfriGU10は無責任なATMのようです：

数日前にも色相ライトストリップで私に起こったので、IKEA固有の問題はないと思います。デバイスの電源を入れ直す必要があり、その後は通常どおりに戻ります。直接電力が供給され、電源を入れ直すための壁のスイッチがない私のFLOALTパネルの場合は、まだ面倒な場合があります。

peer69 2019年02月14日

理由は何ですか？

REST APIプラグインは、ライトの状態をポーリングするときに2、3回応答を受信しない場合、ライトを到達不能としてマークします。応答がない原因は、可能性の高い順に次のとおりです。
a。ライトの電力がカットされました（たとえば、20世紀の壁のスイッチによって）。
b。 Zigbeeネットワークには問題があります（たとえば、無線干渉やメッシュ内のルーティングの問題が原因です）。この場合でも、ライトはグループコマンドに反応します。
c。ライトのファームウェアがクラッシュしました。

他の接続を復元してから電源を切断/接続することは可能ですか？

a）およびc）：いいえ。 b）：はい。

REST APIプラグインは、ライトからメッセージを受信すると、ライトを到達可能としてマークします。ライトの電源を入れると、_DeviceAnnouncement_メッセージが送信されます。 b）では、通常、次のポーリングが成功すると、光は自然に戻ります。 deCONZ GUIでノードを選択し、 0を押すこともできます。

ebaauw 2019年02月14日

👍1

バージョン2.05.59でも同じ問題。

thomas70 2019年02月14日

2.05.59にアップグレードした後でも、この問題が発生します。今日は私の3つの屋外照明の1つでした。
そのTradfri電球はそれらの3つすべてです。

rich710se 2019年02月15日

@ebaauwご説明ありがとうございます。

a。ライトの電力がカットされました（たとえば、20世紀の壁のスイッチによって）。

これらのライトに使用できる壁のスイッチがないため、誤って電源を切断することはできません。

b。 Zigbeeネットワークには問題があります（たとえば、無線干渉やメッシュ内のルーティングの問題が原因です）。この場合でも、ライトはグループコマンドに反応します。

接続が失われると、ライトはグループコマンドに反応しません（ライトはPhosconアプリのHue Dimmerに割り当てられ、接続が失われるとHue Dimmerに反応しません）。

c。ライトのファームウェアがクラッシュしました。

ファームウェア1.2.214は、私のすべてのIKEAGU10スポットにインストールされています。それらの20以上を取得し、ランダムなライトがオフラインになります。たとえば、2〜3週間に1つです。

JBS5 2019年02月15日

https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2cで最新のdeCONZバージョンを試すことができ

ebaauw 2019年02月15日

私は先月、2つの異なるE14 IKEA電球（IKEA fw 1.2.214）で同じ経験を2回経験しました。
パワーサイクリングは私にとって両方の時間で機能しました。

tubalainen 2019年02月15日

c。ライトのファームウェアがクラッシュしました。

グループコマンドでもライトが反応しない場合は、ファームウェアがクラッシュしているように見えます。

2.05.59は、IKEAゲートウェイパラメーターを適応させて、ライトステートレポートを構成しました。主に、IKEA自体がテストしていない構成を使用してバグを引き起こさないことを望んでいます。この変更により、デバイスでのレポートにタイマーが使用されなくなることに注意してください。

ライトの電源を入れ直すと、新しい構成が適用されます。

グループメンバーシップやネイバーテーブルクエリなどのメンテナンスリクエストをライトに送信しますが、2.05.59で安定性が向上しない場合は、これらをさらに制限する可能性があります。

ゲートウェイが送信するリクエストとは関係のないバグがライトファームウェアにある可能性もあることに注意してください。

manup 2019年02月15日

👍3

c。ライトのファームウェアがクラッシュしました。
グループコマンドでもライトが反応しない場合は、ファームウェアがクラッシュしているように見えます。
2.05.59は、IKEAゲートウェイパラメーターを適応させて、ライトステートレポートを構成しました。主に、IKEA自体がテストしていない構成を使用してバグを引き起こさないことを望んでいます。この変更により、デバイスでのレポートにタイマーが使用されなくなることに注意してください。
ライトの電源を入れ直すと、新しい構成が適用されます。
グループメンバーシップやネイバーテーブルクエリなどのメンテナンスリクエストをライトに送信しますが、2.05.59で安定性が向上しない場合は、これらをさらに制限する可能性があります。
ゲートウェイが送信するリクエストとは関係のないバグがライトファームウェアにある可能性もあることに注意してください。

メーカーFWのZigbee標準解釈と相関して、「必ずしもdeconzに関連しているわけではなく、ZigbeeネットワークまたはメーカーFWに関連している」の+1。

tubalainen 2019年02月15日

2.05.59にアップデートしたところ、deconzを再起動した後、同じライトに再び到達できなくなりました。 GUIで0を押しても、元に戻りません。他のライトは機能します。私の場合、これはライト自体の問題かもしれません。

peer69 2019年02月15日

@ peer69 @ thomas70 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127で@manupが言及しているように、ライトの電源を入れ直しましたか？

ライトの電源を入れ直すと、新しい構成が適用されます。

JBS5 2019年02月15日

良いヒント、それをしていません。今のところ、私は別の理由で.58に戻らなければなりませんでした（高いCPU負荷がゲートウェイを無反応にします）、今日の後半に.59でこれを再試行し、すべてのikeaライトをパワーサイクルします。

peer69 2019年02月15日

私もこの問題を抱えています。同じGU10ライトで2回発生しました。現在2.05.59を実行しており、更新後にライトの電源を入れ直しました。

jurriaan 2019年02月17日

時々それが失敗し続ける同じ電球であるように思われることを付け加えるのを忘れました。しばらく前に私は別の電球に問題がありました、そしてそれは常に反応を止めることでした。

jurriaan 2019年02月17日

電源を入れ直した後、IKEAの電球が戻ってきました。しかし、私のIKEAFLOALTパネルWSはまだオフラインです

thomas70 2019年02月17日

私はこれと同じ問題を経験していて、かなり長い間そうしています、そして私は.59が実際に私にとって事態を悪化させたと言うでしょう。私は80のノードを持っており、そのうち32はTrådfriライトとスイッチ、5はHueライト、残りは温度、動き、煙探知器などの異なるXiaomiバッテリー駆動デバイスです。私の場合、すべてのタイプのデバイスが少なくとも1回は応答していません。それはTrådfriライトだけではありませんが、当時私はTrådfriライトとHueライトに問題がありました。

問題は、私が以前にすべてのライトをHueブリッジに通し、XiaomiセンサーをXiaomiゲートウェイに通した後、それらはすべて堅固だったので、それが原因でない限り、私の場合の原因はデバイスファームウェアではないと思います状況の変化。

以前は完全に機能していた6つのTrådfriGU10ライトが1つの場所にありますが、.59にアップグレードし、数回電源を入れ直した後、ほとんど完全に応答しなくなり、おそらくリセットする必要があります。奇妙なことに、この無反応は、電力を持っているライトに応じて、さまざまなライトから「移動」しているように見えます。応答しないライトの一部の電源を切ると、しばらく時間がかかる場合があります。その後、突然、正常に動作したくない他のライトになります。おそらくどこかに何かを壊しているオフセットがありますか？

Bllstc 2019年02月18日

問題は、私が以前にすべてのライトをHueブリッジに通し、XiaomiセンサーをXiaomiゲートウェイに通した後、それらはすべて堅固だったので、それが原因でない限り、私の場合の原因はデバイスファームウェアではないと思います状況の変化。

興味深いことに、Hueネットワークに32個すべてのIkeaライトもありましたか？ Hueブリッジはポーリングのみを使用し、属性レポートを構成しないため、質問しています。

XiaomiネットワークにHueやIkeaライトのようなルーターデバイスもありましたか？

以前は完全に機能していた6つのTrådfriGU10ライトが1つの場所にありますが、.59にアップグレードし、数回電源を入れ直した後、ほとんど完全に応答しなくなり、おそらくリセットする必要があります。奇妙なことに、この無反応は、電力を持っているライトに応じて、さまざまなライトから「移動」しているように見えます。応答しないライトの一部の電源を切ると、しばらく時間がかかる場合があります。その後、突然、正常に動作したくない他のライトになります。おそらくどこかに何かを壊しているオフセットがありますか？

うーん、それはかなり悪いです私はこれがどのように起こるのか本当に疑問に思います、2.05.59は以前のバージョンよりもIkeaライトに非常に「馴染みがある」です。 Ikeaゲートウェイと同じように設定が行われています。

ライトが応答しなくなったら、deCONZでノードを選択し、応答/黄色になったら0を押してください。ライトの電源を入れ直す必要はありません。この場合にゾンビになるライトはまもなく修正されることに注意してください。これは現在、特定のネットワークコンステレーションで発生する可能性があります。

ちなみにいつもの質問：

どのファームウェアバージョンを使用していますか？
RaspBeeまたはConBee？
ConBeeの場合、USB延長ケーブルを使用しますか？

manup 2019年02月18日

予想よりも少し時間がかかりましたが、実際にはすべてが正常に機能しているように見えます。少なくとも今のところ、私が言えることから。

サーバーを再起動し、ネットワーク内のすべてのメイン電源ライトの電源を入れ直して、最新の構成を取得したことを確認しましたが、それにもかかわらず、問題が解決するまでに数時間かかったため、私は少し時期尚早でした。すぐには機能しなかったため、問題は残りました。

興味深いことに、Hueネットワークに32個すべてのIkeaライトもありましたか？ Hueブリッジはポーリングのみを使用し、属性レポートを構成しないため、質問しています。

はい、そうですね。 Hueネットワークには31個のIkeaライトとHueライトがありました。 32番目のIkeaデバイスは、当時私が購入していなかったスイッチコンセントです。

XiaomiネットワークにHueやIkeaライトのようなルーターデバイスもありましたか？

いいえ、バッテリー駆動のセンサーだけです

ライトが応答しなくなったら、deCONZでノードを選択し、応答/黄色になったら0を押してください。ライトの電源を入れ直す必要はありません。この場合にゾンビになるライトはまもなく修正されることに注意してください。これは現在、特定のネットワークコンステレーションで発生する可能性があります。

私はこれを以前に何度も試しましたが、効果はありませんでした。また、ハードウェアとセットアップについては、USB延長ケーブルと262F0500を備えたConBeeを使用しています。今はすべてが正常に機能しているように見えるので、この情報は現時点では役に立たない可能性がありますが、結論にジャンプせず、ネットワークを数日間実行して、問題が発生しないことを確認します。戻る。

Bllstc 2019年02月19日

私は先週末から.59を実行していますが、それでもランダムなIkeaライトを失います。（家の正面に16個のE27電球。）
電球FWは、まだIkeaGatewayにある他のものと同じです。
262F0500FWでのConBeeの使用。
先週末、私もHUEブリッジを購入し、.59の「Underthe hood」リリースノートに気付いたとき、ライトを動かし始めようとしていました。延期することを決定しましたが、この次の週末を再検討します。
デコンズは今でも私の最高のXiaomi / miCubeコントローラーです。まだジェスチャーを見逃していません。

olemr 2019年02月20日

私は先週末から.59を実行していますが、それでもランダムなIkeaライトを失います。（家の正面に16個のE27電球。）
電球FWは、まだIkeaGatewayにある他のものと同じです。
262F0500FWでのConBeeの使用。
先週末、私もHUEブリッジを購入し、.59の「Underthe hood」リリースノートに気付いたとき、ライトを動かし始めようとしていました。延期することを決定しましたが、この次の週末を再検討します。
デコンズは今でも私の最高のXiaomi / miCubeコントローラーです。まだジェスチャーを見逃していません。

私はここでも同じような状況にあります。16個のIKEAライト、2個のIKEAコントロールコンセント、Heimanプラグとinnrプラグ、そしていくつかのXiaomiセンサー（キューブ/ドアセンサー/モーションセンサー）です。 IKEA以外のデバイスで問題が発生したことはありません。しかし、私は現在、IKEAライトがネットワークから落ちるというほぼ毎日の問題を抱えています

ファームウェア0x26300500およびdeCONZ.59でUSB延長ケーブル付きのConbeeを使用しています

jurriaan 2019年02月21日

私のライトはしばらくの間正常に機能していますが、数日前に私のTrådfriE14電球が突然反応しなくなりました。 1パワーサイクル後、それは生き返りました。

今日は、GU10の1つが脱落する時でした。物理的には前述のE14に非常に近いので、偶然かどうかはわかりません。私のすべてのライトがConBeeの範囲内にあるとしても、GU10はE14を介してルーティングされている可能性があります。

ノードを選択してdeCONZで0を押しても、何も起こりません。また、deCONZコンテナを再起動しようとしましたが、起動時にネットワークを再ルーティングしている間、その特定の電球にルートが接続されません。トラブルシューティングを進めるためにここで最善のアプローチは何でしょうか？

Bllstc 2019年02月25日

12日後、別のGU10に到達できなくなり、電源を入れ直さないと再接続できなくなります。

この問題に取り組むために必要な情報を共有してください。

JBS5 2019年02月26日

ここでも同じですが、昨日6日間の完璧な接続の後、Tradfri電球の1つを失いました。電源のオン/オフとリセットは役に立ちませんでした。 deConzではまだ黄色ですが、接続または制御できません。

rich710se 2019年02月27日

こっちも一緒。今日は何の問題もなく数日後、私のGU10Tradfriランプの2つが応答を停止しました。 GUIで0を押すことで、一方を生き返らせることができましたが、もう一方をパワーサイクルする必要がありました。
幸い、これはGU10デバイスのATMでのみ発生するようですが、私のFLOALTパネルにはまだ問題はありませんでした（私のセットアップでは、回路ブレーカーを使用してのみ電源を入れ直すことができます）。

peer69 2019年03月01日

この問題は私にも続いています。私は今、さらに3〜4個のGU10電球が接続を失い、Hue E27の1つとXiaomiドアセンサー（磁石）を経験しました。電源を入れ直した後、再び機能するライトもあれば、機能しないライトもあります。 0を押しても何も起こりません。

隣接する応答しないGU10の電源を入れ直した後、Xiaomiセンサーが再び機能し始めたことも注目に値します。そのため、センサーはそのライトを介してルーティングされていたと思いますが、接続に問題がある場合は自動的に再ルーティングする必要がありますか？

Bllstc 2019年03月01日

ここで同じ問題。昨日、最新バージョン.59にアップデートしましたが、Ikeaのライトがいくつか反応しなくなりました

Webserve 2019年03月04日

こんにちは。ネットワークのサイズやその他の主電源デバイスなど、ネットワーク全体についてさらに詳しく教えていただけますか？

数日前にホームネットワークを再配置しました。現在は次のようになっています。

5x IKEA WS GU10（ファームウェア1.2.221、製品コードLED1537R6GU10EU）
Macアドレス0x000b57ff .....（古いバッチ）
2x IKEA調光可能E27（ファームウェア1.2.214）
1x IKEA E14 WSライト（ファームウェア1.2.221）
1x IKEAリピーター（ファームウェア2.0.019）
1x IKEAアウトレット（ファームウェア2.0.019）
1x OSRAM GU 10
1x OSRAME27カラー電球
1xOSRAMプラグ
1x HueE27カラー電球
1x HueE27調光可能なルクス電球

deCONZ 2.05.59; ConBeeファームウェア0x26300500（ただし、0x262f0500でも問題ありません）。

私は4xFLS-PP lpを持っていますが、これらは非常に強力な信号リピーターとして機能するため、テストのために電源がオフになっています。

センサーとスイッチを使用すると、ネットワークの合計サイズは55になります。
すべてのライトは常に電力が供給されており、これまでは停止はゼロでした。

manup 2019年03月04日

これが私のネットワークのより詳細な仕様です。私はまだ262F0500とConBeeへの延長コードで2.05.59を実行しています。前述のように、最初に2.05.59に更新し、すべての主電源デバイスの電源を入れ直して数時間待った後、ネットワークはほぼ1週間問題がなかったため、問題が発生し始めるまでしばらく時間がかかるようです。残念ながら、問題が再発し、すべての主電源デバイスの完全な電源サイクルとdeCONZの再起動では、問題は解決されません。また、ライトがしばらく応答しなくなってから自動的に修正されることがあるため、問題はデバイスからデバイスへと移動しているようです。

今日の初めに、TrådfriE14と1つのHueE27が応答しないという問題がありました。 E27の電源を入れ直した後、E14も私が触れることなく生き返りました。同じことが時々取引場所のように見える無反応のGU10にも当てはまります。したがって、毎日少なくとも2つの無反応のGU10がありますが、常に同じライトであるとは限らないため、動作を開始するものと故障するものがあります。

私のネットワークは現在、ConBeeを含む次の80台のデバイスで構成されており、主電源のデバイスは24時間年中無休で電源が供給されています。

主電源

| 数量| タイプ| ファームウェア|
| ---------- | ------ | ------------- |
| 30 | TrådfriGU10調光可能| 1.2.214 |
| 4 | TrådfriGU10ホワイトスペクトル| 1.2.217 |
| 1 | TrådfriE14オパール調光可能| 1.2.217 |
| 1 | Trådfriコントロールアウトレット| 1.4.020 |
| 3 | 色相E27ホワイトとカラーA19 | 1.29.0_r21169 |
| 2 | HueE14ホワイトアンビエンスLTW012 | 1.29.0_r21169 |

電池で動く

数量| タイプ| ファームウェア
--------- | ------ | -----------
1 | Trådfriオン/オフスイッチ| 1.4.018
10 | Xiaomi Aqaraマルチセンサー（正方形の温度/ハム/圧力）| 20161129
3 | Xiaomi Aqaraモーションセンサー（モーション/ルクス）| 20170627
4 | XiaomiAqara水センサー| 20170721
1 | 色相モーションセンサー| 6.1.0.18912
11 | XiaomiAqaraコンタクトセンサー| 20161128
8 | Xiaomi / Honeywell煙センサー| 該当なし

Bllstc 2019年03月04日

先週、deconzはほぼ正常に動作しているように見えましたが、昨日、別のIKEA電球（白いスペクトル）がdeconzへの接続を失いました。それをオフにしてから再びオンにしても助けにはなりませんでした。どういうわけか再び機能するためにdeconzを再起動する必要がありました。

私は主にIKEA電球、Heimanコンセント、そしてかなりの数のXiaomiセンサーを備えたネットワークを持っています。

jurriaan 2019年03月10日

私のzigbeeネットワークのいくつかの仕様：

NUCの延長ケーブル付きのConbeeファームウェア262F0500。
DockerのdeCONZ2.05.55なので、最初にやらなければならないことは2.05.59にアップグレードすることだと思います。

パワード（24/7）

| 数量| タイプ| ファームウェア|
| ------------- | ------------- | ------------- |
| 4x | TradfriE27ホワイト| 1.1.1.0-5.7.2.0 |
| 2x | TradfriE27ホワイト| 1.2.214 |
| 21x | TradfriGU10調光可能| 1.2.214 |
| 3x | Osram Smart +ソケット| 1.04.12 |

電池で動く

| 数量| タイプ| ファームウェア|
| ------------- | ------------- | ------------- |
| 3x | Hue Dimmer Switch | 5.45.1.17846 |
| 1x | Aqaraスマートスイッチ| 20180525 |
| 1x | Aqaraスマートスイッチ| 20161128 |
| 1x | Aqaraダブルワイヤレススイッチ| 20170411 |
| 1x | TRADFRIリモート| 1.2.214 |
| 6x | Aqaraマルチセンサー| 20161129 |
| 10x | Aqaraコンタクトセンサー| 20161128 |
| 5x | Aqaraモーションセンサー| 20170627 |
| 1x | Aqaraリークセンサー| 20170721 |
| 1x | Aqara振動センサー| 20180130 |

JBS5 2019年03月11日

現在のバージョンのこれに関する更新はありますか？ .60を3日間実行していますが、まだ接続が失われているライトはありません。

peer69 2019年03月15日

残念ながら、私はすでに.60の通常のTradfriE27白い電球と最新のファームウェアとの接続が失われていました。

jurriaan 2019年03月15日

それは悪いニュースです...私が正しく理解していれば、ポーリング間隔は.60で変更され、攻撃性が低くなっています。ライトをハングアップさせる積極的なポーリングは、私には完全に理にかなっています。残念ながら、これは私たちの問題の解決策ではないようです。

peer69 2019年03月15日

昨日、すべての主電源デバイスの電源をオフにし、2.05.60と26320500に更新してから、安全に再生するために再度オンにしました。その後、ライトはすべて約24時間正常に機能しましたが、ほんの数分前に、GU10の1つが応答を停止したことに気付きました。幸いなことに、数分後に私の側から手動で操作することなく再び復活したので、おそらくネットワークが詰まっているだけでした。

Bllstc 2019年03月16日

@ JBS51.1.1.0-5.7.2.0の4xTradfriE27ホワイトを最新のファームウェアバージョンに更新することをお勧めします。私が正しく思い出せば、これはまだ最初のバージョンです。

@jurriaanどのバージョンにTradfriE27の白い電球がありますか？

それは悪いニュースです...私が正しく理解していれば、ポーリング間隔は.60で変更され、攻撃性が低くなっています。

はい、基本的にIKEAゲートウェイと非常によく似ています。現在残っている唯一の違いは、隣接テーブルの定期的なクエリです（メッシュネットワークラインを表示するために使用されます）。

これは、deCONZのCREアイコンをクリックして、[ルーターとコーディネーター]のチェックを外すことでオフにできます。
テストする価値があるかもしれません。

Redditには、IKEAゲートウェイは理論的には最大100台のデバイスをサポートする必要があるが、十分にテストされていないという投稿がありました。 IKEAチームがテストする通常のネットワークサイズを知ることは興味深いでしょう。

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

おそらく、ゲートウェイに100台のデバイスを接続することができます。これは私たちによって適切にテストされていないため、私たちはそれを保証しません。しかし、技術的な制限は100であり、100台のデバイスを持っていて、問題がまったくないか、わずかな問題しかない人を見てきました。

ゲートウェイの新しいバージョンは、同じ数のデバイス（正式には50）をサポートします。それを2倍にしたい場合は、システムに別のゲートウェイを追加できます。

manup 2019年03月18日

@ JBS51.1.1.0-5.7.2.0の4xTradfriE27ホワイトを最新のファームウェアバージョンに更新することをお勧めします。私が正しく思い出せば、これはまだ最初のバージョンです。

古いファームウェアを搭載したE27電球は、過去6か月間は故障しませんでしたが、他の電球は故障しました...

JBS5 2019年03月18日

非常に興味深いですが、バージョン1.2.214のE27はどうですか？

manup 2019年03月18日

非常に興味深いですが、バージョン1.2.214のE27はどうですか？

彼らは過去数ヶ月に一度だけ接続を失いました。

最後のGU10が接続を失ってから数週間前ですが、これはまだConbeeでdeCONZ2.05.55とファームウェア262F0500を使用している間です。

JBS5 2019年03月19日

私もこの問題を抱えています。 Ikeaノードのみ（43、主に点灯）。私はzigbeeについての知識はありませんが、それが言及されているのを見たことがないので、OTAUを無効にするとネットワークがより安定しているように見えます。先日、ネットワーク設定を安全性の低いものに変更しました。どれか思い出せませんが、その後は明かりを失いませんでした。

lb1974 2019年03月20日

問題なく数日後、いくつかのGU10が応答しなくなりました。
別の問題は無関係かもしれませんが、オスラムライトも接続を失いました。それはまだGUIに表示されていて、メッシュのように見えましたが、それ以上制御できませんでした。読み取ったライトを削除する必要があったため、別のライト番号が割り当てられましたが、追加した直後に以前の名前に戻りました。ここで何が起こっているのかわかりませんが、これは私のセットアップで見たいよりもかなり多くのメンテナンスです。

peer69 2019年03月24日

@ peer69ライトの電源を
2.05.60を使用していますか？また、ネットワーク、照明と主電源のデバイスの数について、もう少し詳しく教えていただけますか？

manup 2019年03月24日

@manupライトを
その間、この問題は出荷時設定にリセットした後も再び発生し、別のOSRAMライトにも影響を及ぼしました。今のところ、ネットワーク内の2つのOSRAMライトだけを取り除き、色相電球に置き換えています。 ORSAMライトを使用してテストを提供することはできますが、そのためには少し時間が必要です。

2.05.60を実行しています。現在、ネットワークに接続されているノードは57あり、そのうち27のデバイスが主電源です。私は13個のIKEAGU10、1個のIKEA FLOALTパネル、2個のIKEA E14、3個のOSRAM Smart +プラグ、3個のE14色相電球、5個のE27色相電球、1個の色相ライトストリップを使用しています。

また、過去数日間にいくつかのIKEA GU10の電源を入れ直さなければならず、無反応になりました。電源を入れ直した後、すべてが正常に戻り、パターンが表示されません。私はいくつかのGU10を備えたランプを持っており、それらが常にグループとして制御されているにもかかわらず、同時に応答しなくなったGU10は1つだけです。

peer69 2019年03月28日

現時点では、正方形に戻っています。現在、私は定期的に2〜3個のライトが応答しませんが、異なるライト間をジャンプするため、機能する場合と、オンラインになっている他のライトに依存しない場合があります。一部のライトの電源を切って物理的にオフにすると、他のライトに問題が移るので、問題は連鎖しているようです。

また、Xiaomi温度センサー、ドアセンサー、IKEAオン/オフスイッチをいくつか紛失しましたが、元に戻らないため、作業を再開するにはおそらく再ペアリングする必要があります。

先に述べたように、電源を入れ直した直後は問題なく動作しましたが、数日後、ライトが再び応答しなくなり、数週間はこのようになりました。初めてゲストが誤ってE14のプラグを数時間抜いたときのことなので、それが完全に無関係なのか、それともジグビーメッシュの予期しない外乱がルーティングを狂わせたのかはわかりません。これらの問題を抱えているのは私だけではないようですが、それは偶然だったのではないかと思います。

私はすべてのzigbeeデバイスを1つのメッシュにまとめるというコンセプトが本当に好きですが、古いHueゲートウェイとXiaomiゲートウェイを起動し、ConBeeを引き出しに入れるところです。これは本当にやりたくないことです。他のいくつかの理由で。何が起こっているのか、そしてそれを解決する方法を正確に特定するのに役立つ、さらなるトラブルシューティングのためのヒントはありますか？

Bllstc 2019年04月04日

私のIKEAGU10スポットの1つも応答しなくなりました。

スニファーでは、まだいくらか「生きている」ことがわかり、NWKリンクステータスメッセージを送信しますが、明らかにネットワーク内で単独であると考えています（リンクステータスカウント：0）。

ユニキャストコマンドには応答しませんが、modelidのZCL属性レポートを定期的に送信します。

約2時間からスニッフィングし、いつ応答しなくなったか、関連しているかどうかはわかりませんが、レポートのZCLシーケンス番号は低くなっています。

さらにいくつかのテストを行い、しばらくの間電源を入れ直しません。

私のTradri電源ソケットは今日も本当に奇妙な動作をし、再起動サークルで実行されました。

manup 2019年04月04日

2つ目のIKEAGU10もウォーキング主導で、他の症状と同じです。

どちらのデバイスも、ユニキャスト、グループキャスト、またはZCP nwkアドレス要求に応答しません（0を押します）。
空のNWKリンクステータスコマンドを送信します。

2番目のGU10も、ZCLOTAクエリの次の画像要求を送信しました。

応答がないようです。

ただの大げさな推測ですが、バッファ内のライトがブロックされていると思います。そのため、何も受信および処理されません。アウトバッファはまだ機能しているため、ファームウェアはレポートとotaクエリを送信できます。

macレイヤーが機能している（コマンドを受信している）が、nwkレイヤーとapsレイヤーがサイレントのままである場合に、ファームウェアがしばらくして再起動できるように、単純なヘルスチェックのようなものを実装するとよいでしょう。

manup 2019年04月04日

2.05.59にアップグレードした後でも、この問題が発生します。今日は私の3つの屋外照明の1つでした。
そのTradfri電球はそれらの3つすべてです。

オフトピック。このすべての中でどのようにあなたの光を見つけますか？私は似たようなセットアップをしていて、私は次のようでした...これには時間はありません

MattL0 2019年04月04日

同様に私は+ -50デバイスを意味します

MattL0 2019年04月04日

+ -50はちょっと大丈夫です。私たちのテストネットワークの1つには、Raspberry Pi1にdeCONZを備えた+180台のデバイスがあります。それは楽しいです:)

デバイスの検索を簡素化するために、deCONZにさらに優れたフィルター/並べ替えを追加する計画がいくつかありますが、現在、特定のデバイス数では非常に面倒です。

manup 2019年04月04日

👍1

ライトはまだスタックしています。

興味深い観察結果の1つは、Philips Hueモーションセンサーの親（Hue Lux）の電源を切ったため、新しい親を検索する必要があることです。センサーは、スタックしたIKEAGU10ライトの1つを介して再結合を試みます。

ライトはLeave（Rejoinを使用）コマンドで応答します。したがって、再結合要求を処理しました。

悲しいことに、Hueモーションセンサーは頑固で、スタックしたGU10ライトに永遠に再結合しようとしますが、代わりに、より良い親を探します。

ただし、ここで興味深いのは、スタックしたIKEAライトが再結合リクエストに応答することです。おそらくNWK脱退リクエストも処理します。これは、ライトを再び動作状態にするための回避策のベースになる可能性があります。

manup 2019年04月05日

👍1

訂正、Hueモーションセンサーはそれほど頑固ではありません。数分後、センサーは別の作業中の親を選択しました（良好）。

manup 2019年04月05日

ただし、ここで興味深いのは、スタックしたIKEAライトが再結合リクエストに応答することです。おそらくNWK脱退リクエストも処理します。これは、ライトを再び動作状態にするための回避策のベースになる可能性があります。

私はこれをテストしましたが、残念ながらそれは機能しません。ライトがスタック状態にある間は、再結合要求でNWK脱退を処理しません。

現在、IKEAはライトが動かなくなるという根本的な問題を修正するか、ファームウェアのNWK / APSレイヤーに何らかのウォッチドッグとヘルスチェックを実装する必要があると結論付けることしかできません。

光がこの状態になる正確な原因はまだ不明です-ブロードキャストストーム、特定のコマンド、ルーティングの問題...？

調査結果とスニファログをIKEAに転送し、問題を追跡するために使用できることを願っています。

manup 2019年04月06日

👍4

それで、 @ manup 、スタックしたIKEAライトに再び参加するためのベストプラクティスは何ですか？

Filialen 2019年04月06日

私にとって、光のパワーサイクルは明らかに最もよく機能します

djwlindenaar 2019年04月06日

@manup患者を良くする方法がわからない場合は、悪化させるように努めるべきだと思います。だから、ロックアップの潜在的な原因でライトを爆撃し、何が起こるかを見てください。
また、これらのライトはEmberスタックに基づいていませんか？たぶん、光を当てる可能性のあるサポートチームやフォーラムがあります（しゃれを意図しています）。

IKEAの場合、彼らはこのようなサポートのリクエストに対応していますか？それとも、チームを組んで注目を集める必要がありますか？

djwlindenaar 2019年04月06日

私にとって、光のパワーサイクルは明らかに最もよく機能します

私にとってはそれほど多くはありません...
Conbeeの再起動は、一時的に修正する唯一の方法です。
そして、同じ、またはもっと頻繁に、別のIKEAライトがしばらくすると動かなくなります...
常に1つのライトだけ！それはとても奇妙です...そして苛立たしい...：/

Filialen 2019年04月07日

@manup素晴らしい！これを調べてくれてありがとう！

また、このスレッドをReddit経由でIKEATradfriチームに転送しました。彼らから情報を転送したという返答がありました。彼らがこれを使ってファームウェアを改善したり、この問題の解決策を見つけたりできることを期待しましょう:)

jurriaan 2019年04月08日

👍4

特にHomeKitサポートを対象としたtradfriゲートウェイ用の新しいファームウェアが近日中に登場するようです。電球用の新しいファームウェアもあるかもしれません。

peer69 2019年04月11日

@ peer69これは最新のファームウェアリリースです。

version_info.json

[
  {
    "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"
  }
]

更新のみは次のとおりです。

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-ゲートウェイ-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

そのため、主にアウトレット/ゲートウェイに焦点を当てています。

jurriaan 2019年04月11日

今日、私の色相電球の1つがまったく同じ問題を示しました。再び応答するようにするには、電源を入れ直す必要がありました。

peer69 2019年04月20日

deCONZとConbeeのファームウェアを更新する人に関するニュースはありますか？

今まで、1つまたは2つのGU10は2〜4週間でオフラインになります。散発的なものですが、いくつかの場所に電源スイッチがないため、電源の入れ直しは面倒です。

ファームウェアを0x26330500に更新したので、見てみましょう。

JBS5 2019年05月05日

残念ながら、今日私のGU10の1つは利用できません。
Conbeeでファームウェア26330500を使用してdeCONZ2.05.64を使用する。

JBS5 2019年05月10日

フィリップスHUEブリッジでもまったく同じ問題が見られるため、これは電球のFWの問題であると結論付けられたと思います。 Trådfriアプリのリリースノートセクションで、CTv2電球について言及していることに気づきました。多分それは電球のハードウェアに関連していますか？

olemr 2019年05月10日

これまでのところ、2.05.65で問題は発生していません。

peer69 2019年05月31日

同じように、私は数週間以来この問題に直面していません

VincentMasselis 2019年06月02日

私は今までdeconzの最新バージョンで同じことをしていました..数日前にいくつかのランプを切り替えました。再び応答するようにするには、これらのランプの1つを手動でオフにしてから再びオンにする必要がありました。

jurriaan 2019年06月02日

数日前に、いくつかのGU10とE27電球がオフラインになりました。パワーサイクリングだけがそれらをオンラインに戻します。

たぶん関連性がある：これは私の休暇中に、1日または10日間ライトが切り替わっていなかったときに起こりました。

deCONZ2.05.64を搭載したファームウェア26330500

JBS5 2019年06月09日

数週間前に数週間問題がなかったと言った人にとって、この問題はどうですか？

私はまだこの問題を抱えています。場合によっては、どれもオフラインにならず、突然GU10がオフラインになり、数日後に別のGU10がオフラインになります。

私が見る限り、TradfriGU10で利用できる新しいファームウェアはまだありません。

JBS5 2019年08月21日

私はまだこの問題を抱えています。私の場合、グループコマンドは、単一のデバイスとしてライトを制御できない場合でも、ほとんどの場合は機能します。回避策として、wall-switch-scriptsでこれらを使用します。

peer69 2019年08月21日

グループコマンドは私にも機能しますが、数回しか機能しません。その後、ライトはオンまたはオフになり、応答しなくなります。バインドされたHueDimmerを使用している場合でも同様です。

JBS5 2019年08月21日

わたしも。問題は解決された以上に遅れているという印象を受けます。
また、グループコマンドの使用に関する問題も回避しました。

ちなみに、一部のライトはこの問題の影響を受けやすいように見えます。あなたはこれを認識していますか？

djwlindenaar 2019年08月21日

@djwlindenaar言うのは難しいですが、25以上のGU10の半分はこれまでこの問題が発生したことがなく、いくつかは何度も問題が発生したと確信しています。

@ peer69 @djwlindenaar groupコマンドは

JBS5 2019年08月21日

groupコマンドは通常は機能し続けますが、ライトの電源を入れ直さなければならなかったときのことを覚えています。また、しばらく応答せず、何もしなかったときに再び応答し始めたのを覚えています。

djwlindenaar 2019年08月21日

遅かれ早かれ、グループコマンドも失敗し、ライトの電源を入れ直さなければなりませんでした。

しばらくするとどういう意味ですか？数時間または数日？

JBS5 2019年08月21日

わからない、おそらく数時間、多分一日。しばらく忘れていたのですが、次回ライトを使うとまた戻ってくることに気づきました。
それは動きによって引き起こされるルールに関連していたので...

djwlindenaar 2019年08月21日

今週初めにGU10がオフラインになるまで約2日間待ちましたが、元に戻りませんでした。パワーサイクルが必要でした、GU10はまったく暖かくありませんでした。

JBS5 2019年08月24日

現在、オフラインになったGU10ライトが1つありますが、電源を入れ直してもオンラインに戻りません。また、VNCで0を押しても、この問題は解決されません。

また、グループコマンドまたはバインドされたHue DImmer Switchは、ライトのオン/オフを切り替えることができなくなりました。

JBS5 2019年09月29日

昨夜から、廊下に4つのikeaライトがあり、タイマー（Home Assistant）によってx時間後に消灯します。現在、4つのライトのうち1つが点灯し続け、Home Assistant / Deconzではオフにできません。デコンズによれば、オフラインであり、7時間以内に再参加していません。電源を入れ直して、それでうまくいくかどうかを確認します。

ライトが機能しない：バージョン1.2.214のTRÅDFRI電球E27オパール1000lm
ライトの動作：バージョン1.2.214のTRÅDFRI電球E27オパール1000lm
ファームウェア：26330500
デコンズ：V2_05_69

lubbertkramer 2019年09月30日

Ikea TrafriGU10ホワイトスペクトル電球にはハードウェアの問題があると思います。また、私のセットアップ（ローカルAPIを介してHome Assistantに接続されたIkeaゲートウェイ）では、17個の電球の少なくとも半分が数日ごとにオフラインになります。唯一の解決策は、電球の電源を入れ直すことです。

これが、Ikeaが異なるバージョンのファームウェア（1. *ではなく2. *）を実行する新しいハードウェアバージョンを発売した理由である可能性があります。

私の知る限り、古いバージョンの新しいファームウェアアップデートはありません。これは、ハードウェアに関連する何かの兆候である可能性があります。

保証内容はわかりませんが、新バージョンへの交換をお願いする予定です。

ReX1983 2019年09月30日

Ikea TrafriGU10ホワイトスペクトル電球にはハードウェアの問題があると思います。また、私のセットアップ（ローカルAPIを介してHome Assistantに接続されたIkeaゲートウェイ）では、17個の電球の少なくとも半分が数日ごとにオフラインになります。唯一の解決策は、電球の電源を入れ直すことです。
これが、Ikeaが異なるバージョンのファームウェア（1. *ではなく2. *）を実行する新しいハードウェアバージョンを発売した理由である可能性があります。
私の知る限り、古いバージョンの新しいファームウェアアップデートはありません。これは、ハードウェアに関連する何かの兆候である可能性があります。
保証内容はわかりませんが、新バージョンへの交換をお願いする予定です。

白のスペクトルではなく、暖かい白のGU10を使用しているため、1つのタイプのみに関連しているかどうかはわかりません。

JBS5 2019年09月30日

今日、2つのIKEA GU 10WWで同じ問題が発生しました。パワーサイクリングは役に立ちませんでした。それは、電源を入れ直してdeconzを再起動するのに役立ちました。多分いくつかの隣人テーブルの問題？両方のライトは2つのグループにあり、常にグループとして制御されます。

peer69 2019年09月30日

これが最近のいくつかのインストールで起こっているのは何という偶然です...または何か他のことが起こっていますか？

@ peer69

使用しているdeCONZおよびconbeeファームウェアのバージョンはどれですか？

使ってます：
deCONZ V2_05_66
ファームウェア26330500

JBS5 2019年10月01日

ここに同じファームウェア。 deCONZバージョン2.05.69。

peer69 2019年10月01日

そして、別のTradfriGU10ウォームホワイトが接続を失いました。

JBS5 2019年10月04日

テストブランチには新しいファームウェアファイルがありますが、これらが問題を修正するのか、それとも新しい問題を引き起こすのか、おそらく損傷を引き起こすのかはわかりません。

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 2019年10月04日

@manupこれらは、白色スペクトルのGU10ライト用であり、新しいバージョン用だと思いますか？ https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

JBS5 2019年10月04日

おそらく10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signedを使用できます。 IKEA E27調光可能ライトの1つでテストします。最悪の場合はクラッシュですが、燃えないことを願っています:)

manup 2019年10月04日

👍1

ファイルを手動で割り当てようとしましたが、電球が更新を取得するように見えません（起動しません）。

manup 2019年10月04日

これについては「私も」です。私の家全体はTradfriであり、今日サーバーを再起動した後、私は数日で3度目のネットワーク全体を失いました。パワーサイクリングは違いを生みませんでした。私の家にはTradfriしかいないので、他に比較できるものはありません。私はe27ホワイト、e27カラーとGU10の混合物を持っています。私が見つけた唯一の解決策は、電球をハードリセットし、すべてを最初から始めることです-悲しいことに、これは持続可能ではありません。

Conbeeファームウェア：264A0700
ライトファームウェア：1.2.214

どんな診断でも喜んでお手伝いしますが、家族が照明のオンとオフを切り替えることができるように、家のほとんどをTradfriゲートウェイに戻す必要があります。いくつかのランプを用意しておきます。

kinsago 2019年10月13日

私はちょうどこの問題への、多分、興味深い追加に気づきました。

いくつかの部屋には複数のTradfriGU10スポットがあり、ほとんどの部屋にはHue Dimmer Switchがあり、PhosconアプリのHue DimmerSwitchグループに追加することで作成された部屋のGU10に直接バインドされます。

Hue Dimmer Switchで直接バインドされているGU10のみが時々オフラインになり、オンラインに戻るには電源を入れ直す必要があります。
Hue Dimmer Switchで直接バインドされていないGU10は、オフラインになりません。

JBS5 2019年10月23日

私には当てはまらないようです。今までは、HueBulbsだけがかなり弾力性があるようです。私が所有するすべての種類のIKEAデバイス（GU10、E14、FLOALTパネル）とOsramデバイス（電球、ライトストリップ、ガーデンポール）が故障しました。特にオスラムのデバイスは完全に故障し、電源を入れ直しても何も起こりません。それらは取り外して修理する必要があり、これはこれらのデバイスにとって苦痛です。

peer69 2019年10月24日

いくつかのデバイスが失敗し、おそらくzll-dbが多少破損しているために、Conbee IIスティックへの移行も失敗した後、高価なKNXインストールのためにすべてのzigbeeデバイスをデバイスに置き換えることを考えて数日を過ごしました。それから私は根本的なアプローチを取り、すべてをゼロからセットアップしました。ゲートウェイをリセットし、すべてのデバイスを修復しました。 IKEAデバイスに関しては、これは以前よりずっと簡単でした。以前は、ゲートウェイの近くに移動し、数回リセットし、タッチリンクを使用して応答させる必要がありましたが、今回は何もしませんでした。電球をリセットしただけで、問題なくペアリングされました。それでも、70台のデバイスでこれを行うのは苦痛であり、一部のxiaomiセンサーはikeaのものよりも少し難しくしました。しかし、それは私が今より安定したネットワークを持っているかもしれないと私にすでに思わせます。それでも失敗したものはありませんが、失敗した場合はお知らせします。

peer69 2019年10月28日

ラズビーをアップデートしてからしばらく経ちましたが、古いバージョンではライトの温度の読み取りに問題があったため、最新のファームウェアと最新のdeCONZにアップデートすることにしました。ライトは2つしかありません（OSRAM73674）。 1つのライト（おそらくランダム）は、最新のdeCONZで数分後に接続を失い、手動でオフにしてから再度オンにする必要があります。私が見つけた唯一のバージョンは、温度を読み取ることができ、ライトを失うことはありませんでした。deconz-2.04.40-qt5.debは非常に古いですが、私の基本的な使用法で機能します。

danielocdh 2019年11月02日

IKEA GU10の単色で、私にとっても最近はもっと多くのことが起こります。お尻の痛みのようなもの。ただし、ノードは私にとって赤にはならず、グレー表示されるだけです。それらはリモートボタンの押下に反応しますが、PhosconまたはHAを介しては反応しません。

ACrazyConcept 2019年11月03日

リモートから制御した場合でも、deCONZはライトの状態を更新しますか？

これは通常、deCONZがランプへのルートを失ったときに発生します。ランプはまだネットワーク上にあり、ゲートウェイに到達でき、ブロードキャストを受信します。ただし、ゲートウェイはユニキャストを介してライトに到達できません。回避策として、 /lights代わりに/groupsコマンドを使用する場合があるため、deCONZは代わりにブロードキャストを送信します。

Xiaomi Curtain Controller（ZigBeeルーター）で同じ問題が時々（〜週に1回）発生します。デバイスの電源を入れ直した後の_DeviceAnnounment_により、deCONZはルートを再学習します。

これらのルーティングの問題は、Trådfriライトで使用されるルーティング検出のサポートで導入されたため、2.04.40が適切に聞こえます。

ebaauw 2019年11月03日

@ebaauwライトが利用できなくなったとき、グループコマンドは私のために機能しますが、限られた時間だけです。その後、ライトはオンまたはオフになり、グループコマンドに応答しなくなります。バインドされたHueDimmer Switchを使用する（PhosconアプリでHue Dimmer Switchがペアリングされているときに、デフォルトで作成されたグループにライトを追加することによって作成されたバインド）。

JBS5 2019年11月03日

リモートから制御した場合でも、deCONZはライトの状態を更新しますか？
これは通常、deCONZがランプへのルートを失ったときに発生します。ランプはまだネットワーク上にあり、ゲートウェイに到達でき、ブロードキャストを受信します。ただし、ゲートウェイはユニキャストを介してライトに到達できません。回避策として、 /lights代わりに/groupsコマンドを使用する場合があるため、deCONZは代わりにブロードキャストを送信します。

次回はこれらの提案を確認します。しかし、はい、彼らは通常それを返します私は数分で電源を切りました。ところで、私はIKEAの「ホッケーパック」リモコンを使用しています。

Xiaomi Curtain Controller（ZigBeeルーター）で同じ問題が時々（〜週に1回）発生します。デバイスの電源を入れ直した後の_DeviceAnnounment_により、deCONZはルートを再学習します。
これらのルーティングの問題は、Trådfriライトで使用されるルーティング検出のサポートで導入されたため、2.04.40が適切に聞こえます。

うーん、これは私にとってこれほど長い間悪いことではありません。私はそれを継続的に最新の状態に保ちました。

ACrazyConcept 2019年11月03日

うーん、これは私にとってこれほど長い間悪いことではありません。

それは断続的な問題です。思いのままに再現することはできませんでした。＃849をご覧ください。実際、ライトを制御するためのすべてのルールは/groupsアクションに基づいているため、カーテンコントローラーを入手するまで、この問題に気付くことはありませんでした。

ライトが利用できなくなったとき、グループコマンドは私のために機能しますが、限られた時間だけです。その後、ライトはオンまたはオフになり、グループコマンドに応答しなくなります。

ライトは、属性レポートのゲートウェイから長時間ACKを受信しない場合、ネットワークを離れることを決定すると理論付けます。

ebaauw 2019年11月03日

ライトは、属性レポートのゲートウェイから長時間ACKを受信しない場合、ネットワークを離れることを決定すると理論付けます。

私にとって、これは、オンになっているライト、またはほんの数分/時間前のライトでも発生します。

上記のいくつかの返信を投稿したように、私のGU10ライトのほとんどはHue Dimmer Switch（独自のHue Dimmer Switchがある部屋では3〜8）にバインドされています。いくつかはそうではなく、それらは数ヶ月からオンラインになっています。それらの1つが利用できなくなったことはありません。偶然かどうか..この@ebaauwについてどう思いますか？

JBS5 2019年11月03日

私のGU10ライトのほとんどはHueDimmerSwitchにバインドされています

それはありそうもないようです。 deCONZ GUIの_BindDropbox_パネルで、調光スイッチからライトへのバインディングを作成しましたか？

ZigBeeの用語での「バインディング」とは、デバイスのバインディングテーブルに、バインドされたクラスターからコマンドを送信するZigBeeアドレスへのエントリを作成することを意味することに注意してください。調光器スイッチの（クライアント！）_ OnOff_クラスターと_Level Control_クラスターは（deCONZ REST APIプラグインによって）グループにバインドされていると思います。このグループは、ZHASwitchリソースのconfig.group下にリストされています。次に、ライトがこのグループに追加されました。 ZigBeeグループはマルチキャストアドレスに似ているため、ライトがこのグループへのメッセージをサブスクライブしたと言った方が正しいでしょう。

理論的には、ライトファームウェアにバグがあり、グループを介して受信したコマンドの処理中にハングする可能性があると思います。しかし、これはありそうもないと思います。ライトがRaspBee / ConBeeにどれだけ近いか（ZigBeeネットワーク上のホップ数）、および/またはすべてのライトのハードウェアとファームウェアのリビジョンが同じかどうかを調べます。 IKEAは、すべてのデバイスの新しいZigBee 3.0（ZHA）バージョンを展開しているようです。

ebaauw 2019年11月03日

私のGU10ライトのほとんどはHueDimmerSwitchにバインドされています
それはありそうもないようです。 deCONZ GUIの_BindDropbox_パネルで、調光スイッチからライトへのバインディングを作成しましたか？
ZigBeeの用語での「バインディング」とは、デバイスのバインディングテーブルに、バインドされたクラスターからコマンドを送信するZigBeeアドレスへのエントリを作成することを意味することに注意してください。調光器スイッチの（クライアント！）_ OnOff_クラスターと_Level Control_クラスターは（deCONZ REST APIプラグインによって）グループにバインドされていると思います。このグループは、ZHASwitchリソースのconfig.group下にリストされています。次に、ライトがこのグループに追加されました。 ZigBeeグループはマルチキャストアドレスに似ているため、ライトがこのグループへのメッセージをサブスクライブしたと言った方が正しいでしょう。

いいえ、deCONZGUIのde_BindDropbox_パネルでバインディングを作成しませんでした。

Phosconアプリでこれらのグループにライトを追加しても、リモートとライトの間にバインディングが作成されないということですか？ deCONZ dockerコンテナまたはNUC全体がオフラインのときに、追加されたライトを対応するHue Dimmer Switchに切り替えることも可能であるため、私はそう思いました。

JBS5 2019年11月03日

さて、私は今反応しない塊を持っています。それはbthdeCONZとPhosconでグレー表示されていました。

リモートコマンドに反応し、Phosconの「グループ」モードでスライダーを動かしたときにも反応しました。

リモートから制御した場合でも、deCONZはライトの状態を更新しますか？

グレー表示されているので、最初はそうではありません。

次に、deCONZで「選択したノードをリセット」してみましたが、deCONZにクラスターのラジオボタンがないにもかかわらず、数分間グレー表示されなくなりました。

それでもリモートコマンドとグループコマンドにのみ応答しましたが、ライトの状態が更新されました。

しばらくすると、Phosconで再びグレー表示になりました。

その後、数分間電源を切ってみました。助けにはならなかった。

ACrazyConcept 2019年11月09日

今夜、興味深い状況が発生しました。

Tradfriの暖かい白いGU10ライトの1つが、数時間後に再びオフラインになります。現在オフラインになっているものを含む8つのGU10にバインドされているHueDimmer Switchは、deconzによると、オフラインGU10のオン/オフを切り替えます。不思議なことに、それだけです。
他のGU10は、バインドされたHue DimmerSwitchに応答しません。

グループを残りのAPIで切り替えると、オフラインGU10を含むすべてのライトがオン/オフになります。

GU10が以前にオフラインになったとき、バインドされたHue Dimmer Switchは、グループ内のすべてのライトをオン/オフに切り替えます。これには、t deconzによると、オフラインGU10が含まれます（遅かれ早かれ、deconzによると、オフラインGU10もグループコマンドのリッスンを停止します。どちらか）。

これは役に立ちますか？

\ Edit： VNC経由のdeCONZにあるこのオフラインGU10の「名前」は空です。

これを再度入力すると、設定されません（ここでは、通常はPhosconアプリでこれを実行しませんでした）。

まだ黄色：

「0」または「選択したノードのリセット」を押しても、GU10はオンラインに戻りません。

編集2 ：GU10がオフラインになってから約24時間後、前述のように、GU10はバインドされたHue DimmerSwitchに応答しなくなります。グループ内のどのGU10ライトも現在応答していません。 deCONZ GUIのノードはまだ黄色ですが、名前は灰色です。
オフラインのGU10ライトをパワーサイクルした後、オフラインだったものを含め、グループ内の8つのライトすべてが、バインドされたHue DimmerSwitchに再び応答しています。

@manupこの動作/状況は以前とはかなり異なりますが、おそらくこれは原因を見つけるのに役立ちますか？

JBS5 2019年11月12日

私はちょうどこの問題への、多分、興味深い追加に気づきました。
いくつかの部屋には複数のTradfriGU10スポットがあり、ほとんどの部屋にはHue Dimmer Switchがあり、PhosconアプリのHue DimmerSwitchグループに追加することで作成された部屋のGU10に直接バインドされます。
Hue Dimmer Switchで直接バインドされているGU10のみが時々オフラインになり、オンラインに戻るには電源を入れ直す必要があります。
Hue Dimmer Switchで直接バインドされていないGU10は、オフラインになりません。

残念ながら、Hue DimmerSwitchがバインドされていないTradfriGU10ウォームホワイトの1つが、昨日からオフラインになっています。

なぜいくつかのGU10スポット（同じwarmwhite）がオフラインにならないのか疑問に思っています。
\編集：これも数か月間オンラインであったGU10が、昨日からオフラインになっています。

JBS5 2019年11月22日

先週末にTradfriHubを購入し、1つの部屋のすべてのGU10スポットをそれにペアリングしました。今後数週間で何が起こるか見てみましょう。

JBS5 2019年12月04日

システムに4つのIKEAオン/オフコンセントスイッチを追加した後、システムのランダムライトが反応しなくなりました（クリスマスウィンドウライト用）...コンセントは家中に散らばっています。システム内のライトの少なくとも1つは、1日に電源を入れ直す必要があります。

トラブルシューティングを容易にするために、任意のタイプのログまたは情報を提供できますか？

tubalainen 2019年12月04日

@tubalainen応答しないとはどういう意味ですか？彼らは自分たちで反応するようになっていますか？彼らはパワーサイクルが必要ですか？

JBS5 2019年12月04日

@tubalainen応答しないとはどういう意味ですか？彼らは自分たちで反応するようになっていますか？彼らはパワーサイクルが必要ですか？

それらは「オンライン」（グレー表示されていない）としてリストされ、私の写真によるとメッシュの一部ですが、Home Assistantで（またはphosconを介して）切り替えても何も起こりません。それらを再び機能させるには、電源を入れ直す必要があります。

tubalainen 2019年12月04日

これについて何か進展はありますか？私のGU10ライトが灰色になるのは少しばかげています:(

誰かがカーテンコントローラーやオン/オフスイッチについて言及しているのを見たと思います。私がFYRTURブラインドを手に入れた頃に問題がさらに悪化したことは実際に私に起こります。これは私がネットワークに追加した最初のikeaボタンでもありました...私はしません...

ACrazyConcept 2019年12月05日

ここにはTradfriのオン/オフウォールスイッチやIKEAカーテンがなく、問題があります。

JBS5 2019年12月05日

👍2

私は夏の間にこの問題を抱えていました。私のGU10はいつも脱落していました。すべてのGU10を最新の「テスト」ソフトウェアにアップグレードし、ほぼ2か月間問題なく実行しています。

先週末、私はいくつかの新しいE27電球を追加しましたが、今ではいくつかのGU10が再びドロップアウトしています。

aherbjornsen 2019年12月05日

私は夏の間にこの問題を抱えていました。私のGU10はいつも脱落していました。すべてのGU10を最新の「テスト」ソフトウェアにアップグレードし、ほぼ2か月間問題なく実行しています。
先週末、私はいくつかの新しいE27電球を追加しましたが、今ではいくつかのGU10が再びドロップアウトしています。

どのGU10電球をお持ちで、どのファームウェアをインストールしましたか？

ReX1983 2019年12月05日

先週末にTradfriHubを購入し、1つの部屋のすべてのGU10スポットをそれにペアリングしました。今後数週間で何が起こるか見てみましょう。

Tradfriゲートウェイを使用したとき、ほとんど毎日応答しない電球がありました（Tradfri GU10ホワイトスペクトル、第1世代）。 Philips Hueブリッジに切り替えたところ、問題は解決したように見えましたが、2週間後に、1つの電球が応答しなくなりました（通常どおり、電源を入れ直すと問題が解決しました）。

HueブリッジがTradfri電球でうまく機能する理由と方法はわかりませんが、本当の問題は電球にあるように思われます。

ReX1983 2019年12月05日

私はGU10を1つも所有していませんが、それでも問題が発生します。

これを解決するために、ログなどをどのようにサポートできるか教えてください。
一部のノードが「スリープ状態になり」、最初の試行でウェイクアップしないのは簡単なようです（ここでは私の推測です）。

これは、メッシュに複数のノードホップがある場合にのみ問題になりますか？私にとっては、コンビーへのホップが複数ある場合は非常に重要です。繰り返しますが、ただの気持ちです。確認されていません。

tubalainen 2019年12月06日

私は生後約18ヶ月のGU-10を8つ持っています。そのうちの1つはその時に一度灰色になりました。それらはすべてコンビースティックと同じ部屋にあります。私は3年前の980lmの球根を持っています。 gu 10を介してジャンプするgwから最も遠いものは、おそらく2週間に1回灰色になります。
@tubalainenは何かにあるかもしれません。

灰色になっているものの隣に、私は一度も失敗したことのないオスラムを持っています。

Flurkmark 2019年12月06日

👍1

はい@tubalainenが手がかりになるかもしれません。私は実際に、灰色のGU10を、新しいライトを追加するときに使用するコードのランプソケットに入れています。しかし、私がそれらを元の場所に戻すと、再び外に出ます。彼らが戻ってくることは100％一貫しているわけではありませんが、それでも共犯者である可能性があります。

ACrazyConcept 2019年12月07日

👍1

ここに別の潜在的な手がかりがあります。ランプが灰色になることは一度もありませんでしたが（1年以上のアップタイムで8つのIKEAランプを使用）、Home Assistant deconzプラグインを3.8から3.9に更新し、2日で2つのGU10が灰色になりました。プラグインの3.8バージョンのバックアップを復元し、それ以来問題はありません。奇妙なことに、3.8プラグインと3.9プラグインは同じdeconzバージョンを使用します（変更ログが完了している場合）。それでも、フォスコンでさえ、ランプにはアクセスできませんでした。これはすべてかなり奇妙ですが、プラグインの3.9バージョンは、IKEAランプを不安定にする何らかのdeconz要求を行うと思います。

PremiumUsername 2019年12月19日

私はHAを使用していませんが、それでも問題が発生します。私はいくつかのneGU10を購入し、今では複数回灰色になるすべてのランプを交換しています。私が交換したランプは、再び灰色になりませんでした。ハードウェアの問題かもしれませんが、そうではないかもしれませんが、すぐに解決策がないようです。

peer69 2019年12月19日

同様の問題が発生しました。一部のライトノードはコマンドに応答せず、灰色になります。奇妙なことに、グループコマンドを送信すると、同じライトノードが毎回完全に応答します。

MikaelHoogen 2019年12月26日

同様の問題が発生しました。一部のライトノードはコマンドに応答せず、灰色になります。奇妙なことに、グループコマンドを送信すると、同じライトノードが毎回完全に応答します。

グループコマンドは、数日/ 1週間以上経過しても機能し続けますか？
私の場合：遅かれ早かれ、ライトはグループコマンドのリッスンも停止します。

JBS5 2019年12月27日

同様の問題が発生しました。一部のライトノードはコマンドに応答せず、灰色になります。奇妙なことに、グループコマンドを送信すると、同じライトノードが毎回完全に応答します。
グループコマンドは、数日/ 1週間以上経過しても機能し続けますか？
私の場合：遅かれ早かれ、ライトはグループコマンドのリッスンも停止します。

はい、時間の経過とともに正常に機能するようです。しかし、私には何が悪いのかという理論があります。ライトノードがTRADFRI電球E27WSオパール1000lmを介してルーティングされると、問題が発生します。だから昨日、私は自分のネットワークに持っていた2つをオフにしました。それ以来、すべてが完璧に機能しているようです。

ScreenClip 4

MikaelHoogen 2019年12月28日

私はTRADFRI電球GU10WS 400lm、TRADFRI電球E14 CWSオパール600lm、TRÅDFRI電球E27CWSオパール600lmを持っています。何の問題もないようです。

MikaelHoogen 2019年12月28日

古いTrådfriファームウェアに関連している可能性があります。最近のライトには新しいファームウェアが付属していますが、IKEAがすべての第1世代ライトの更新されたファームウェアを公開しているとは思いません。 TrådfriGU10スポットはありませんが、CWSによって電球はファームウェアアップデートを受け取りました。私の1000lm調光可能電球はそうではありませんでした。白いスペクトルの電球についてはよくわかりません。

ebaauw 2019年12月28日

古いTrådfriファームウェアに関連している可能性があります。最近のライトには新しいファームウェアが付属していますが、IKEAがすべての第1世代ライトの更新されたファームウェアを公開しているとは思いません。 TrådfriGU10スポットはありませんが、CWSによって電球はファームウェアアップデートを受け取りました。私の1000lm調光可能電球はそうではありませんでした。白いスペクトルの電球についてはよくわかりません。

私のTRADFRI電球GU10WS 400lmは、同じファームウェア2.0.022上にあります。それらは問題を引き起こさないようです（まだ:)）

MikaelHoogen 2019年12月28日

古いTrådfriファームウェアに関連している可能性があります。最近のライトには新しいファームウェアが付属していますが、IKEAがすべての第1世代ライトの更新されたファームウェアを公開しているとは思いません。 TrådfriGU10スポットはありませんが、CWSによって電球はファームウェアアップデートを受け取りました。私の1000lm調光可能電球はそうではありませんでした。白いスペクトルの電球についてはよくわかりません。

同意する。 Ikea電球の最初のバージョン（1. *ファームウェア上）には、2番目の反復（2. *上）に影響を与えないソフトウェア/ハードウェアのバグがありました。

残念ながら、Ikeaは元のバージョンをサポートしておらず、ファームウェアのアップデートも提供していないようです。同時に、電球を返品して新しい電球と交換することはできません（私は英国で試しました）。

ReX1983 2019年12月28日

古いTrådfriファームウェアに関連している可能性があります。最近のライトには新しいファームウェアが付属していますが、IKEAがすべての第1世代ライトの更新されたファームウェアを公開しているとは思いません。 TrådfriGU10スポットはありませんが、CWSによって電球はファームウェアアップデートを受け取りました。私の1000lm調光可能電球はそうではありませんでした。白いスペクトルの電球についてはよくわかりません。
同意する。 Ikea電球の最初のバージョン（1. *ファームウェア上）には、2番目の反復（2. *上）に影響を与えないソフトウェア/ハードウェアのバグがありました。
残念ながら、Ikeaは元のバージョンをサポートしておらず、ファームウェアのアップデートも提供していないようです。同時に、電球を返品して新しい電球と交換することはできません（私は英国で試しました）。

1.3.009にcws電球があります。それらは問題を引き起こさないようです。

MikaelHoogen 2019年12月28日

更新：

他のIKEA電球も問題を引き起こしているようです。

これが私のIKEA電球です。これまでのところ、問題を引き起こしているのはTRADFRI電球E27WSオパール1000lmだけです。それらは現在切断されており、物事は機能しているようです。ただし、新しいエラーが発生した場合は、更新を投稿します。

Skärmklipp tradfri

MikaelHoogen 2019年12月28日

2.xデバイスを所有していないようです。
一部のGU10は正常に動作し、一部は動作しませんでした。故障したものを数ヶ月後に購入した「新しい」ものと交換し始めました。ソケットには「1808-S」の番号が印刷されていますが、「新しい」ものには「1729-S」の番号が付いていますが、同じファームウェアを実行しているようです。
これまでに3個の電球を交換しましたが、2週間は新しい問題は発生しませんでした。 GU10だけでなく、交換しなかったFLOALTパネルにも問題がありました。

peer69 2019年12月28日

2.xデバイスを所有していないようです。一部のGU10は正常に動作し、一部は動作しませんでした。故障したものを数ヶ月後に購入した「新しい」ものと交換し始めました。ソケットには「1808-S」の番号が印刷されていますが、「新しい」ものには「1729-S」の番号が付いていますが、同じファームウェアを実行しているようです。これまでに3個の電球を交換しましたが、2週間は新しい問題は発生しませんでした。 GU10だけでなく、交換しなかったFLOALTパネルにも問題がありました。

面白い！球根を調べて、何らかの相関関係があるかどうかを確認します。

私のノードの1つが再び問題の影響を受けているようです。私はまだネットワークにいくつかのIKEAノードを持っているので、いくつかの結論を引き出すことができるかどうかを確認するためにいくつかのテストを行います。

MikaelHoogen 2019年12月28日

私はTRADFRI電球GU10WS 400lm、TRADFRI電球E14 CWSオパール600lm、TRÅDFRI電球E27CWSオパール600lmを持っています。何の問題もないようです。

メッシュがしばらくアップした後、他のIKEAデバイスでも問題が発生し、ノードがコマンドに応答しなくなったようです。他のIKEAノードでも影響を受ける可能性があります。問題が発生し始めたように見えます。その後、ノードはIKEAノードを介してルーティングされます。

これを調査する予定の活動はありますか？これが解決されるまで、すべてのIKEAデバイスを色相ゲートウェイに移動します。

MikaelHoogen 2019年12月31日

ノードはコマンドに応答するために停止します。

本当にそうですか？ ZigBeeトラフィックをスニッフィングしてこれを確認しましたか？他のノードは、ゲートウェイを経由せずに照明を制御するワイヤレススイッチに反応しなくなりましたか？グループコマンドに反応しなくなりましたか？
私の経験では、問題はゲートウェイが他のノードへのルートを認識しなくなったため、ゲートウェイからのユニキャストコマンドが他のノードに到達しないことです。ノード自体は正常に応答しており、応答するものを何も受信していません。

他のIKEAノードでも影響を受ける可能性があります。問題が発生し始めたように見えます。その後、ノードはIKEAノードを介してルーティングされます。

（ではない？）ルーティングIKEAノードは、ゲートウェイからの他のノードへのルートの検出や、ゲートウェイによるルートの検出を何らかの方法で中断します。

これを調査する予定の活動はありますか？

ドレスデンのelektronikサポートに問い合わせる必要があります。ルーティングは、RaspBee / ConBeeファームウェア（およびdeCONZコアプログラム？）によって処理されます。 RESTAPIプラグインではこれについて何もできません。

ebaauw 2019年12月31日

先週末にTradfriHubを購入し、1つの部屋のすべてのGU10スポットをそれにペアリングしました。今後数週間で何が起こるか見てみましょう。

言うのは少し早いかもしれませんが、29日前にすべてのTradfri GU10（8xウォームホワイト-1.2.214）を1つの部屋からTradfriハブに移動しましたが、今まで応答しなくなったものはありませんでした。

JBS5 2019年12月31日

言うのは少し早いかもしれませんが、29日前にすべてのTradfri GU10（8xウォームホワイト-1.2.214）を1つの部屋からTradfriハブに移動しましたが、今まで応答しなくなったものはありませんでした。

私はそう期待します。この問題は、ZigBee標準の解釈が異なる、異なるメーカーのデバイス間の相互作用のように、単一のメーカーのデバイスが原因ではありません。そのため、ほとんどのハブ/ゲートウェイ/ブリッジは独自のデバイスのみをサポートしています。さらに興味深い実験は、TrådfriスポットをHueブリッジまたはOSRAMゲートウェイに接続することです。

また、1つの部屋に8つのライトがあると、ハブと各ライトが直接接続される可能性があります。つまり、すべてのシングルホップ接続です。ルーティングの問題は、ネイバーテーブルのエントリよりも多くのデバイス（通常は約20）を備えた大規模なネットワークでのみ発生します。および/またはハブから物理的に範囲外のデバイスを使用する。

ebaauw 2019年12月31日

ノードはコマンドに応答するために停止します。
本当にそうですか？ ZigBeeトラフィックをスニッフィングしてこれを確認しましたか？他のノードは、ゲートウェイを経由せずに照明を制御するワイヤレススイッチに反応しなくなりましたか？グループコマンドに反応しなくなりましたか？
私の経験では、問題はゲートウェイが他のノードへのルートを認識しなくなったため、ゲートウェイからのユニキャストコマンドが他のノードに到達しないことです。ノード自体は正常に応答しており、応答するものを何も受信していません。

私には交通を嗅ぐための経験や設備がありません。問題がどのように動作しているかについては、おそらく正しいでしょう。私のノードは常にグループコマンドに応答します。問題は（私がそれを取得した場合）、ユニキャストコマンドが宛先に到達しないことです。

グループコマンドのみを送信する限り、すべてが非常にうまく機能しているようです。

他のIKEAノードでも影響を受ける可能性があります。問題が発生し始めたように見えます。その後、ノードはIKEAノードを介してルーティングされます。
（ではない？）ルーティングIKEAノードは、ゲートウェイからの他のノードへのルートの検出や、ゲートウェイによるルートの検出を何らかの方法で中断します。
これを調査する予定の活動はありますか？
ドレスデンのelektronikサポートに問い合わせる必要があります。ルーティングは、RaspBee / ConBeeファームウェア（およびdeCONZコアプログラム？）によって処理されます。 RESTAPIプラグインではこれについて何もできません。

ええ、私は彼らに電子メールを送りましたが、いくつかのチェックリスト以外に何の応答もありませんでした。

MikaelHoogen 2019年12月31日

言うのは少し早いかもしれませんが、29日前にすべてのTradfri GU10（8xウォームホワイト-1.2.214）を1つの部屋からTradfriハブに移動しましたが、今まで応答しなくなったものはありませんでした。
私はそう期待します。この問題は、ZigBee標準の解釈が異なる、異なるメーカーのデバイス間の相互作用のように、単一のメーカーのデバイスが原因ではありません。そのため、ほとんどのハブ/ゲートウェイ/ブリッジは独自のデバイスのみをサポートしています。さらに興味深い実験は、TrådfriスポットをHueブリッジまたはOSRAMゲートウェイに接続することです。
また、1つの部屋に8つのライトがあると、ハブと各ライトが直接接続される可能性があります。つまり、すべてのシングルホップ接続です。ルーティングの問題は、ネイバーテーブルのエントリよりも多くのデバイス（通常は約20）を備えた大規模なネットワークでのみ発生します。および/またはハブから物理的に範囲外のデバイスを使用する。

私はこれを、古いGU10のファームウェア1.2.214に関連していないことを確認するために行いました。これは、ここで考えられる原因として多く言及されています（そして、GU10の新しいバージョンを作成する考えられる理由）。
たぶん、別のルーターを介して接続されていることに関連しています。

他のGU10（これもwarmwhite 1.2.214）ライトをTradfriハブ（2de / 3階のライトも）とペアリングすることを検討します。

JBS5 2019年12月31日

これについて何か進展はありますか？私のGU10ライトが灰色になるのは少しばかげています:(
誰かがカーテンコントローラーやオン/オフスイッチについて言及しているのを見たと思います。私がFYRTURブラインドを手に入れた頃に問題がさらに悪化したことは実際に私に起こります。これは私がネットワークに追加した最初のikeaボタンでもありました...私はしません...

前回の投稿以来、ネットワークにfyrturのオン/オフスイッチがなく、その間にドロップアウトはありませんでした。偶然かもしれません...？

ACrazyConcept 2019年12月31日

これについて何か進展はありますか？私のGU10ライトが灰色になるのは少しばかげています:(
誰かがカーテンコントローラーやオン/オフスイッチについて言及しているのを見たと思います。私がFYRTURブラインドを手に入れた頃に問題がさらに悪化したことは実際に私に起こります。これは私がネットワークに追加した最初のikeaボタンでもありました...私はしません...
前回の投稿以来、ネットワークにfyrturのオン/オフスイッチがなく、その間にドロップアウトはありませんでした。偶然かもしれません...？

いいえ、Tradfriのオン/オフまたはTradfriカーテンがなく、この問題が発生します。
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

JBS5 2019年12月31日

この問題を誤ってクローズしました。再開。

JBS5 2019年12月31日

さらに興味深い実験は、TrådfriスポットをHueブリッジまたはOSRAMゲートウェイに接続することです。

Trådfriハブに接続されたTrådfri電球（第1世代）でも同じ問題が発生しました。すべての電球をフエ橋に移すと、問題は完全に解消されました。

ところで-Trådfri電球の第1世代にはバグがあると私はまだ確信していますが、Hueブリッジはライトの処理が異なります（Hueに接続するとライトがほんの一瞬同期しなくなることがあります-Trådfriでは発生しませんでした）。

ReX1983 2019年12月31日

Hueブリッジはライトの処理方法が異なります（Hueに接続すると、ライトがほんの一瞬同期しなくなることがあります。Trådfriでは発生しませんでした）。

Hueの設定では、ライトはHueブリッジによってのみ制御されます。ワイヤレススイッチとセンサーがブリッジに通知を送信し、ライトを制御するルールをトリガーします。ブリッジはライトの状態を予測し、ライトにコマンドを送信するときにキャッシュを事前に更新します。キャッシュされた状態を検証/更新するために、ライトを定期的にポーリングします。

Trådfriのセットアップでは、照明はワイヤレススイッチとセンサーからのコマンドによって直接制御されます。次に、ライトは更新された状態のレポートをハブに送信します。

（Trådfri）ワイヤレススイッチまたはセンサーから直接Hueブリッジに接続されたライトを制御する場合、Hueブリッジはライトに関する属性レポートを設定しないため、遅延が発生します。ネットワーク内のライトが多いほど、ポーリングがより多くのライトを循環するため、遅延が長くなります。

Hue電球をTrådfriハブに接続し、（Trådfri）ワイヤレススイッチまたはセンサーから直接それらのライトを制御する場合、Hueライトは属性レポートを行わず、Trådfriハブはポーリングを行わないため、ハブの状態は更新されません。

これらの違いはアプリケーションレベルであり、RESTAPIプラグインの制御の範囲内であることに注意してください。ルーティングはZigBeeスタックの下位レベルにあります。

ebaauw 2019年12月31日

👍2

これで、すべてのIKEAルーターノードが色相ブリッジに移動しました。ネットワークにも同じ問題があります。だから私はそれを引き起こしているのは何か他のものだと思います。また、ルーティングされ、ゲートウェイへの直接リンクがないノードにも影響します。

MikaelHoogen 2020年01月01日

これで、すべてのIKEAルーターノードが色相ブリッジに移動しました。ネットワークにも同じ問題があります。だから私はそれを引き起こしているのは何か他のものだと思います。また、ルーティングされ、ゲートウェイへの直接リンクがないノードにも影響します。

現在フエ橋とペアになっているトラッドフリライトと同じ問題がありますか？

@ebaauwライトがブリッジに直接接続されている場合、およびルーターを介して接続されている場合、またはブリッジに直接接続されていない場合にのみ、ルーティングの問題が発生する必要がありますか？

JBS5 2020年01月01日

これで、すべてのIKEAルーターノードが色相ブリッジに移動しました。ネットワークにも同じ問題があります。だから私はそれを引き起こしているのは何か他のものだと思います。また、ルーティングされ、ゲートウェイへの直接リンクがないノードにも影響します。
現在フエ橋とペアになっているトラッドフリライトと同じ問題がありますか？
ペアになっている電球は3つだけです。しかし、私が気付いた問題はありません。

@ebaauwライトがブリッジに直接接続されている場合、およびルーターを介して接続されている場合、またはブリッジに直接接続されていない場合にのみ、ルーティングの問題が発生する必要がありますか？

私のネットワークでは、失われたコマンドの問題が、ゲートウェイに直接ではなく、他のノードを経由してルーティングされるノードに影響を及ぼしているというのが私の経験です。 IKEAの電球が接続されていない場合でも、同じ問題が発生します。

ゲートウェイへの直接リンクのないノード（1）が1つありました。ユニキャストコマンドに応答しませんでした（またはebaauwが述べたように、ルーティングの問題のためにノードに到達しない可能性があります）。 node（2）の電源を切ると、node（1）を介してルーティングされ、ゲートウェイへの直接ルートが取得され、完全に機能し始めました。

MikaelHoogen 2020年01月01日

ライトが直接およびルーター経由でブリッジに接続されている場合、またはブリッジに直接接続されていない場合にのみ、ルーティングの問題が発生する必要がありますか？

ZigBeeには「接続」のようなものはありません。各ルーターは、（MACレベルで）直接到達できる近くのデバイスのネイバーテーブルを保持します。 deCONZ GUIの行は、これらの隣接テーブルのグラフィック表現にすぎません（deCONZが実際にこれらを読み取っている限り）。

ルーターが隣接テーブルにないデバイスにメッセージを送信する必要がある場合、ルーターは要求を隣接ルーターに送信して、転送できるようにします。 NWKレベルの単一メッセージは、MACレベルの複数のホップを介して再送信されます。 RaspBee / ConBee（この観点では）は単なる別のルーターです。 Afaikエンドデバイスは、親ルーターにのみメッセージを送信します。

したがって、ライトがRaspBee / ConBeeのネイバーテーブルにある場合、そのライトが他のルーターのネイバーテーブルであるかどうかに関係なく、ルート検出は含まれません。そうでない場合、RaspBee / ConBeeは、どの隣接ルーターがライトに到達する方法を知っているかを把握する必要があります。ライトが複数ホップ離れている場合、ライトへのパス上の各ルーターは再帰的に同じことを行う必要があります。

詳細が失われるのではないかと思いますが、このルート検出を行うには複数の方法があります。ゲートウェイとランプの間のパス上のルーターが異なる方法を使用すると、問題が発生する可能性があります。ゲートウェイが間違ったネイバールーター（ライトに到達する方法を知らない）にメッセージを送信してしまうか、ゲートウェイがライトに到達する方法をまったく知らず、メッセージをまったく送信しない可能性があります。ユニキャストメッセージは通常、ACKで応答する必要があるため、ゲートウェイは、ACKを受信しない場合、デバイスを到達不能としてマークします。もちろん、元のメッセージまたはACTが失われたかどうかを知る方法はありません（リモートデバイスは、ACKを送信するためにゲートウェイへのルートを知る必要があります）。

ブロードキャストメッセージ（groupsコマンドで使用）はルーティングを使用しません。それらは、すべてのルーターによってMACレベルで再ブロードキャストされるだけです。非常に信頼性がありますが、多くのネットワーク帯域幅を消費します。また、それらはACKによって応答されません。

私のネットワークでは、失われたコマンドの問題が、ゲートウェイに直接ではなく、他のノードを経由してルーティングされるノードに影響を及ぼしているというのが私の経験です。 IKEAの電球が接続されていない場合でも、同じ問題が発生します。

したがって、ルーティングの問題については、デバイスがRaspBee / ConBeeのルーティングテーブルに表示されないように十分な大きさのネットワークが必要です。デバイスの数がルーティングテーブルのサイズを超えているか、リモートデバイスが物理的にRaspBee / ConBeeの範囲外にあり、他のルーターを介してのみ到達できるためです。複数のホップが問題を悪化させると思います。

繰り返しになりますが、ルート検出を行うために異なる、いくぶん互換性のない方法を使用しているのは異なるメーカーであるため、IKEAのせいではありません。特にマルチホップルートの場合、RaspBee / ConBeeファームウェアで回避できるのはそれほど多くありません。

ゲートウェイへの直接リンクのないノード（1）が1つありました。ユニキャストコマンドに応答しませんでした（またはebaauwが述べたように、ルーティングの問題のためにノードに到達しない可能性があります）。 node（2）の電源を切ると、node（1）を介してルーティングされ、ゲートウェイへの直接ルートが取得され、完全に機能し始めました。

繰り返しになりますが、詳細が失われるのではないかと思いますが、この動作を引き起こす複数のシナリオを考えることができます。 RaspBee / ConBeeは、node2またはnode1にメッセージを送信しようとしていますが、ackを受信せず、node2に到達できないと判断し、隣接テーブルから削除します。これで、テーブルには、node1に使用される新しいエントリ用のスペースがあります。

ebaauw 2020年01月01日

繰り返しになりますが、ルート検出を行うために異なる、いくぶん互換性のない方法を使用しているのは異なるメーカーであるため、IKEAのせいではありません。特にマルチホップルートの場合、RaspBee / ConBeeファームウェアで回避できるのはそれほど多くありません。

これは、マルチベンダーのZigBeeプラットフォームのアプローチが、より完全な標準が確立されて従われるまで、設計によって運命づけられているように思えます。それでも、私の環境ではおそらく機能しない複数のゲートウェイを使用したくないので、今は一種のロックインです（たとえば、現在動作している電球を取り外した場合、ゲートウェイから直接到達できないセンサーなど）ルーターとして）。

peer69 2020年01月01日

これは、マルチベンダーのZigBeeプラットフォームのアプローチが運命づけられているように私には聞こえます

私は確かにそうしないことを望んでいますが、それは間違いなく挑戦的です。ここではサイズが重要であるように思われます。ネットワークが十分に小さい場合は、これらのルーティングの問題がまったく発生しない可能性があります。また、ネットワークの（地理的な）中心が互換性のあるベンダーのルーターで構成されている場合、ネットワークのエッジにある互換性の低いルーターはおそらく問題になりません（他のデバイスに到達するためにルーティングされないため）。

OSRAM、Trådfri、およびinnr電球（問題を引き起こしていた）をHue電球に交換しました。現在、104のノード、51のルーター、53のエンドデバイスがあります。ルーターの2/3はHueライトです。到達不能になる（ただしレポートを送信する）唯一のルーターは、Xiaomiカーテンコントローラーです。エンドデバイスのうち20は、Hue、20 Xiaomi、8 Eurotronic Spirit、5IKEAです。 EurotronicSpiritとIKEAFyrturは私に定期的に問題を引き起こしています（彼らは彼らの親によって追い出されていますが、新しい親を見つけられません-ゲートウェイからは到達できませんが、それでもレポートを送信しています）、他は問題ないようです。すべてのデバイスで、通常、電源を入れ直すと状況が改善されますが、デバイスの電源を入れ直すときにネットワークを開く必要がある場合があります。

私は、ベンダーではなく、家の床または通り側と裏側でネットワークを分割することを検討してきました。これは多くの作業であり、問題の原因を詳細に理解し、どのような設定で問題が発生しないかを理解するまで、そうすることには消極的です。

ebaauw 2020年01月01日

@ebaauw 、上記の投稿であなたが言ったことを考えて、deCONZルーティングテーブルの一種の好みを検討するのは興味深いでしょう。ファーストホップとして好ましくない「ブラックリスト」ルーターを検討できますか。十分な「適切な」ルーターを含むようにネットワークを構築できる場合、最初のホップは常にそれらを経由し、2番目のホップはネットワーク内の他のすべてのデバイスに到達します。
これは決定的な解決策ではありませんが、常に「優先」ルーターを経由しながら、はるかに大きな（地理的およびデバイス数）ネットワークを可能にします。

別の考え：IKEA（Silabs EFR32、geckoエンジン）で使用されているチップと、Silabsが提供するzigbeeエンジンを使用していること（ネット上のさまざまなソースから）がわかっているので、2つのアクションを検討できます。

silabsエンジンがルーティングを行う方法を分析し、そこからこの問題の原因を導き出します
同じsilabsエンジンに基づいてランプファームウェアのカスタムバージョンを構築し、問題を修正して、そのファームウェアをOTAでインストールする方法を見つけます。

どちらもSilabsSDKにアクセスする必要がありますが、私は必要ありません。ここで活動している人はいますか..？ SDKを含む開発キットに500ドルを支払うのは楽しみではありません。たぶんドレスデンエレクトロニクスはそれを喜んでしますか？

私の2カラット（時々接続が失われることにかなり不満を感じています）。

djwlindenaar 2020年01月02日

👍1

ファーストホップとして好ましくない「ブラックリスト」ルーターを検討できますか。

私たち：いいえ。 RaspBee / ConBeeファームウェアに実装する必要があると思います。悪い考えではありませんが、デバイスのEEPROMとNVRAMのサイズ制限を考えると、これがどれほど実現可能かはわかりません。 @manup 、これについてどう思いますか？

同じsilabsエンジンに基づいてランプファームウェアのカスタムバージョンを構築し、問題を修正して、そのファームウェアをOTAでインストールする方法を見つけます。

これは私の現在の知識をはるかに超えており、率直に言って、私の野心です-私は趣味のためにこれを行います。私はXBeeで遊んで、ZigBeeアプリケーションを作成できるかどうかを確認しています（私の最終的な目標はベネチアンブラインドをスマート化することです）が、ルーティングが行われるZigBeeスタックの下位レベルを調べたことはありません。。

ebaauw 2020年01月02日

私たち：いいえ。 RaspBee / ConBeeファームウェアに実装する必要があると思います。悪い考えではありませんが、デバイスのEEPROMとNVRAMのサイズ制限を考えると、これがどれほど実現可能かはわかりません。 @manup 、これについてどう思いますか？

@manupはWeの一部だと

これは私の現在の知識をはるかに超えており、率直に言って、私の野心です-私は趣味のためにこれを行います。私はXBeeで遊んで、ZigBeeアプリケーションを作成できるかどうかを確認しています（私の最終的な目標はベネチアンブラインドをスマート化することです）が、ルーティングが行われるZigBeeスタックの下位レベルを調べたことはありません。。

私にとっても趣味ですが、誰かがこれらの詳細についてもっと知識があることを願っています。

私はスプリンクラーシステムをジグビー化することを計画しているCC2530ボードを使用して同様のことをしています（特定のスプリンクラーのオン/オフを手動で切り替えるために庭を歩き回らなければならないことを受け入れることはできません:)）私はコンパイルすることができましたオン/オフライトとしてdeCONZネットワークに参加するCC2530ボード用のzigbeeファームウェア。私が使用する予定のバルブにはラッチ機構があるため、切り替えるには特定の信号が必要です。したがって、独自のファームウェアを作成する必要がありました...

djwlindenaar 2020年01月02日

私たち：いいえ。 RaspBee / ConBeeファームウェアに実装する必要があると思います。悪い考えではありませんが、デバイスのEEPROMとNVRAMのサイズ制限を考えると、これがどれほど実現可能かはわかりません。 @manup 、これについてどう思いますか？

ファームウェアのZigbeeスタックには、その品質（RSSI / LQI）に基づいて、直接リンクの代わりにルートを使用するかどうかを制御するパラメーターがあります。これはすでにかなりうまく機能するはずであり、長年にわたって調整されています。

さらなるパスは、すべてのデバイスのルーティングテーブルを制御するためのより一般的なアプローチである可能性があります。

注：ルーターのルーティングテーブルを選択してRキーを押すと、ルーターのルーティングテーブルを照会できます。ネクストホップルートは青色で表示されます。

現在、Zigbeeネットワークが開かれている場合、Mgmt_Permit_Joining_reqはブロードキャストとして送信されるため、すべてのルーターを親ノードにすることができます。ただし、この要求をユニキャストとして特定のルーターにのみ送信すると、新しいデバイスはこの1つのデバイスを介してのみ参加できます。これは、親に固執することが多いXiaomiエンドデバイスに役立つ可能性があります。ルーターやPhilipsHueエンドデバイスなどの他の参加デバイスの場合、新しい親とルートを自分で自由に選択できるため、これはあまり役に立ちません。

Zigbee R22仕様の（新しい）Mgmt_NWK_IEEE_Joining_List_reqも興味深いようです。

Mgmt_NWK_IEEE_Joining_List_reqコマンドは、ネットワークに参加すると予想されるIEEEアドレスのリストを取得するメカニズムとして提供されています。これにより、ローカルルーターは拡張ビーコン要求をフィルタリングし、参加しているデバイスにのみ応答できます。

ビーコンがないと、デバイスは特定のルーターに参加しようとさえしません。しかし、私はこの要求が現在利用可能なルーターによってどれほどうまくサポートされているかを知りません。

特効薬は、ゲートウェイが各フレーム内で完全なルートを提供するソースルーティングを使用している可能性がありますが、これが消費者向け製品やゲートウェイで使用されているのを見たことがないため、現在のルーターではサポートされていない（またはサポートが不十分である）可能性があります。しかし、試してみる価値があるかもしれません。

manup 2020年01月02日

注：ルーターのルーティングテーブルを選択してRキーを押すと、ルーターのルーティングテーブルを照会できます。ネクストホップルートは青色で表示されます。

かっこいい、知らなかった。 GUIでサポートされているすべてのキー/コマンドの概要はありますか？次のノードにクエリを実行する前に青い線を元に戻すことは可能ですか？ RaspBee / ConBee自体では機能しないようですか？

ルーティングテーブルはネイバーテーブルと異なりますか？スニッフィングすると、ZDP _Link QualityRequest_および_LinkQuality Response_メッセージのみが表示され、ネイバーテーブルが報告されます。これは、青色で表示されていないノードへの回線が「着信」ルートであることを意味しますか？

ebaauw 2020年01月02日

@manup 、確かに興味深い視覚化

特効薬はソースルーティングを使用している可能性があります

まあ...それは試してみる価値があると思います。私のネットワークでは、最も影響を受けるIKEAライトは、コーディネーターから遠い距離にあるライトであるように思われます。 @ebaauwが述べたように、ルーティングに関連する何かが問題を引き起こしているのではないかと疑っています。
私はあなたのためにこのようなものをテストしたいと思います。ただし、接続が失われることはあまり信頼できないため、テストが難しい場合があることを認めなければなりません。

コーディネーターが最初のホップにどのルーターを選択するかを選択するという方針に沿って、私はもっと考えていました。 IKEAデバイスでうまく機能するルーター（おそらくそれらはIKEAルーター）を見つけることができれば、それらを介してすべてのパケットをルーティングすることで、物事がより堅牢になるはずです。ルート検出プロセスをだまして、最初のホップに特定のルーターを優先させることができるかどうかはわかりませんが、おそらくコメントできます、

djwlindenaar 2020年01月02日

注：ルーターのルーティングテーブルを選択してRキーを押すと、ルーターのルーティングテーブルを照会できます。ネクストホップルートは青色で表示されます。
かっこいい、知らなかった。 GUIでサポートされているすべてのキー/コマンドの概要はありますか？次のノードにクエリを実行する前に青い線を元に戻すことは可能ですか？ RaspBee / ConBee自体では機能しないようですか？

誰かがすべての主要なコンボとそれらが何をしているのかをリストアップしたい場合は、それをクリーンアップしてwikiページを作成させていただきます。

dandrzejewski 2020年01月02日

かっこいい、知らなかった。 GUIでサポートされているすべてのキー/コマンドの概要はありますか？

リクエストノード記述子= 1
パワー記述子の要求= 2
Nwkアドレスのリクエスト= 0
リクエストルーティングテーブル= R
管理リーブのリクエスト= L （再結合あり、インライトでは使用しないでください！）
アクティブエンドポイントのリクエスト= 7
単純な記述子の要求= 8
更新= F5 / Cmd-R
削除= Delete / Backspace
Gateway Device Annce = A （あまり役に立ちません）

次のノードにクエリを実行する前に青い線を元に戻すことは可能ですか？

まだ、ルートを確認するのは簡単で汚い追加でした:)
おそらく、ノードのルートをクリアするためにShift-Rような別のキーを追加することは有用ですか？

RaspBee / ConBee自体では機能しないようですか？

残念ながら、RaspBee I / ConBee Iは関連するZDPコマンドをサポートしていません。これは、ConBeeIIで動作します。

ルーティングテーブルはネイバーテーブルと異なりますか？スニッフィングすると、ZDPリンク品質要求メッセージとリンク品質応答メッセージのみが表示され、ネイバーテーブルが報告されます。

これらは2つの分離テーブルであり、通常、ルーティングテーブルは、直接到達できず、隣接テーブル（1ホップノード）の対象となるノードへのルートのみを保持します。

ネイバーテーブルにある（そして強い信号を持っている）ノードの場合、ルート検出は必要ありません。ネイバーテーブル自体は、主に1ホップのNWKリンクステータスコマンドを使用して構築されます。

これは、青色で表示されていないノードへの回線が「着信」ルートであることを意味しますか？

青以外の線（緑/オレンジ/黄色）は、1ホップのネイバーテーブルを表しています。青い線は、ある宛先へ

manup 2020年01月03日

👍2

私たち：いいえ。 RaspBee / ConBeeファームウェアに実装する必要があると思います。悪い考えではありませんが、デバイスのEEPROMとNVRAMのサイズ制限を考えると、これがどれほど実現可能かはわかりません。 @manup 、これについてどう思いますか？
ファームウェアのZigbeeスタックには、その品質（RSSI / LQI）に基づいて、直接リンクの代わりにルートを使用するかどうかを制御するパラメーターがあります。これはすでにかなりうまく機能するはずであり、長年にわたって調整されています。
さらなるパスは、すべてのデバイスのルーティングテーブルを制御するためのより一般的なアプローチである可能性があります。
注：ルーターのルーティングテーブルを選択してRキーを押すと、ルーターのルーティングテーブルを照会できます。ネクストホップルートは青色で表示されます。

本当に便利な機能！昨日、ファームウェア2.0.022でTRÅDFRI電球GU10 WS 400lm（7電球）の電源を入れました。今日、問題が再発し、ファームウェア1.3.009のTRÅDFRI電球E27CWSオパール600lmに現れました。この機能のおかげで、E27電球がGU10電球を経由していることがわかりました。私はすべてのGU10の電源を切り、魔法のようにE27が再び機能し始めました。

そのため、InnrとIKEAを介したルーティングが問題を引き起こしていることがかなり明らかになりつつあります。 Innr ochIKEA電球を色相ゲートウェイに移動し始めました。フィリップスの電球は優れたルーターであり、問題を引き起こしていないようです。

MikaelHoogen 2020年01月04日

そこで、リビングの照明の位置を変えながら、ちょっとした実験をしました。 2つのルーターを取り外し、1つのライトを再配置しました。出来上がり、1つのライトがゾンビになりましたが、完全ではありません。時々接続が失われるIKEAライトで見たのとまったく同じように動作します。

IKEAライトは到達不能としてリストされていますが、それでもグループコマンドに応答します。また、それはまだ他のいくつかのルーターによって知られているので、彼らは光を見たと報告しているようです（それは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

そして

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

時々、コミュニケーションが可能であるように思われます：

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

時々そうではない：

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

何がうまくいかないかについての情報はほとんどありません。 0xA7ステータスはどういう意味ですか..？

何が起こっているのかを理解するのに役立つかもしれないさらなる情報はありますか？

djwlindenaar 2020年01月04日

そこで、リビングの照明の位置を変えながら、ちょっとした実験をしました。 2つのルーターを取り外し、1つのライトを再配置しました。出来上がり、1つのライトがゾンビになりましたが、完全ではありません。時々接続が失われるIKEAライトで見たのとまったく同じように動作します。
IKEAライトは到達不能としてリストされていますが、それでもグループコマンドに応答します。また、それはまだ他のいくつかのルーターによって知られているので、彼らは光を見たと報告しているようです（それは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
そして
11:49:50:017 Node 0x000B57FFFEC52C7D is known by 7 neighbors, last seen 33 s
時々、コミュニケーションが可能であるように思われます：
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
時々そうではない：
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
何がうまくいかないかについての情報はほとんどありません。 0xA7ステータスはどういう意味ですか..？
何が起こっているのかを理解するのに役立つかもしれないさらなる情報はありますか？

これは私の問題の正確な複製のように聞こえます！

MikaelHoogen 2020年01月04日

0xA7ステータスはどういう意味ですか..？

ここを参照してください： https ：

dedepene 2020年01月04日

👍2

ライトの電源を入れ直した

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

そして、そのステータスを喜んで報告しているようです

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

その後：

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

動作を停止します。まで..2分後

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

無線で何が起こっているのかを理解するには、ジグビースニファーを入手する必要があると思います。

この後、それは再び機能しなくなり、今回はやや永続的になりました。

djwlindenaar 2020年01月04日

0xA7ステータスはどういう意味ですか..？
ここを参照してください： https ：

それをありがとう！どういうわけかそれは私が期待していたものです...

djwlindenaar 2020年01月04日

😄1

TRÅDFRI電球GU10WS 400lm（7電球）をPhilipsHueブリッジとペアリングしようとしました。ネットワーク上の他のいくつかの電球が使用できなくなり、TRÅDFRI電球GU10 WS 400lmは、デコンズと同じ動作をしました。グループコマンドでは応答しましたが、ユニキャストでは応答しませんでした。

TRÅDFRI電球GU10WS400lmには何らかの問題があるようです。それが個々の球根であるか、またはそれらのすべてが機能していないかどうか、私はいくつかのテストを行います。

MikaelHoogen 2020年01月07日

今、私はいくつかのテストを行いました。私の結論は、ネットワークが応答しなくなる原因となっているのは実際には個々の電球であるということです。 Hue Bridgeにすぐにアルモンが現れ、電源を切るとすぐに動作が再開されました。したがって、7つの電球のうち3つが影響を受けます。新しい問題が見つかった場合は報告します。

MikaelHoogen 2020年01月07日

@MikaelHoogen 、あなたが持っている電球とファームウェアのバージョンはどれですか？

ReX1983 2020年01月07日

この問題は、v1 E27 WS 980lm、GU10 WS 400lm、E27 CWS 600lm、E15 WS、およびIkea、HUE、DeCONZゲートウェイの3つのFLOALTパネルすべてで昨年半にわたって見られました。
これはHWの問題だと私は確信しています。どのノードが死ぬかは完全にランダムです。
ここノルウェーでは、すべての電子機器が2年間の保証期間内にあります。チケットを開こうとし、彼らの言うことを聞きます。
FLOALTについて。数ヶ月前、Ikeaは彼らにクリアランスセールを行っていました。おそらくそれはすべてのv1を取り除くことでしたか？
FLOALT v2を見た人はいますか？（おそらくsy5882ドライバーで？）

olemr 2020年01月08日

この問題は、v1 E27 WS 980lm、GU10 WS 400lm、E27 CWS 600lm、E15 WS、およびIkea、HUE、DeCONZゲートウェイの3つのFLOALTパネルすべてで昨年半にわたって見られました。
これはHWの問題だと私は確信しています。どのノードが死ぬかは完全にランダムです。
ここノルウェーでは、すべての電子機器が2年間の保証期間内にあります。チケットを開こうとし、彼らの言うことを聞きます。
FLOALTについて。数ヶ月前、Ikeaは彼らにクリアランスセールを行っていました。おそらくそれはすべてのv1を取り除くことでしたか？
FLOALT v2を見た人はいますか？（おそらくsy5882ドライバーで？）

それは私がかなり長い間言いたかったことでもあります。 Trådfriv1バルブでのみ問題が発生します。 Philips Hueブリッジは役立ちますが、それでもノードに到達できなくなることがあります。

ReX1983 2020年01月08日

数日前、私は12個のIKEA GU10バルブすべてを新しいバージョン（ウォームホワイト）に交換することにしました。
それはこの問題をさらに悪化させました。現在、HueGU10の白い雰囲気とHueE14の色も失われています。

ACrazyConcept 2020年01月13日

deConzとIKEAlightが出た当初から使っていました。ネットワークに約70のノードがあります。それらのほとんどはIKEAライトです。 Philips Hue（4つのライト）と1つのOsramもあります。センサー私はIkeaモーションがほとんどなく、Xiaomiモーションセンサーがたくさんあります。

私はかなり長い間このセットアップで実行していて、お互いにライトが動かなくなって購入する日はないので、電源を入れ直す必要があります。私の妻はわくわくしておらず、私もわくわくしていません。私はすべてのzigbeeデバイスを捨てるのに非常に近く、普通の古い学校の照明に行きます。それはうまくいきません。期待はずれの。純粋なフィリップスやオスラムのライトを使っても同じ問題が発生するのではないでしょうか。

donnib 2020年01月16日

deConzとIKEAlightが出た当初から使っていました。ネットワークに約70のノードがあります。それらのほとんどはIKEAライトです。 Philips Hue（4つのライト）と1つのOsramもあります。センサー私はIkeaモーションがほとんどなく、Xiaomiモーションセンサーがたくさんあります。
私はかなり長い間このセットアップで実行していて、お互いにライトが動かなくなって購入する日はないので、電源を入れ直す必要があります。私の妻はわくわくしておらず、私もわくわくしていません。私はすべてのzigbeeデバイスを捨てるのに非常に近く、普通の古い学校の照明に行きます。それはうまくいきません。期待はずれの。純粋なフィリップスやオスラムのライトを使っても同じ問題が発生するのではないでしょうか。

このスレッドでまったく同じ問題を抱えているすべての人を見ると、デコンズのメーカーは、IKEAライトの問題がどのような臭いでIKEAファームウェアの問題のように見えるのかを理解できません。

多くのユーザーがIKEAハブでも同様の問題を抱えています。したがって、これはdeconzに関連する固有の問題ではないと思います。ただし、誰かがこれを修正できれば、「パッチを適用する/回避策を見つける」ことができます。 <3

私は家族とセットアップの両方でまったく同じ問題を抱えています。

tubalainen 2020年01月16日

👍1

悲しいです:(特に、今日販売している新しいものでもまだこれらの問題があります。私にはわかりません。2017年から私のものを持っているので、今では問題が修正されていると思います。全体を削除することを検討する必要があります@manupは以前、これはデバイスのファームウェアの問題であると言っていたので、これを修正できるのはIKEAだけであり、まだ修正していないため、希望はありません。

donnib 2020年01月16日

デコンズバージョン2.05.69
ConbeeIIファームウェア264A0700

それは100％完璧ではなく、私が気付いたドロップアウトはE27 Ikea（Rev1）電球です。
Philips HueブリッジでこれらのIkeaライトを使用したとき、それらは堅固だったので、おそらくHueに戻し、このZigbeeメッシュを純粋にCC2531（ルーターファームウェア）とXiaomiセンサーのままにしておきます。
私はInnr電球（E14）とSP120も持っていますが、これらはまだDeconzで問題ありません。

jtebbens 2020年01月16日

私はHomeAssistantとDeconzを使用して、約20個のIkea電球（および他の多くのセンサー）を制御しています。電球は主にGU10で、1つのライトに対して3つのスポットでグループ化されています。

私はこのセットアップを15か月以上使用していますが、この夏以降、1つ以上の単一の電球が動かなくなって電源を入れ直す必要がある、または取り外してZigbeeネットワークに再度追加するという問題が発生しました。これは常に、HASSのライトグループで定義されたGU10でした。

数週間前、Phosconでライトのグループを作成し、HASSでこれらのグループを参照し始めました。

その後、電球が動かなくなって電源を入れ直す必要があるという問題は1つもありませんでした。私が見る唯一の問題は、すべての屋内照明を一度にオフにすると、Phoscon / Deconzグループ全体がオンのままになることがあるということです。

私には、これはDeconz APIの問題のように思われ、複数の電球をすばやく連続して処理する可能性があります。

aherbjornsen 2020年01月16日

👍4

また、Ikeaデバイス（バルブ、最近ではSymfoniskリモコン）が使用できなくなり、deCONZとの再ペアリングが必要になるという問題もあります。私はこれらの問題を6か月ほど続けてきたと思います。最近頻繁に発生すると思う以上に追加することはあまりありません。私はGU10電球を持っていません。さまざまなE27とE14（およびさまざまなリモコン）だけです。特定のデバイスはドロップアウトする傾向があるようです（おそらく、メッシュの方法などによって異なります）。最新のFW / Phoscon / deCONZを備えたConbeeIから最大範囲5mのデバイスが約20台あります。

mvjt 2020年02月01日

また、Ikeaデバイス（バルブ、最近ではSymfoniskリモコン）が使用できなくなり、deCONZとの再ペアリングが必要になるという問題もあります。私はこれらの問題を6か月ほど続けてきたと思います。最近頻繁に発生すると思う以上に追加することはあまりありません。私はGU10電球を持っていません。さまざまなE27とE14（およびさまざまなリモコン）だけです。特定のデバイスはドロップアウトする傾向があるようです（おそらく、メッシュの方法などによって異なります）。私は、最新のFW / Phoscon / deCONZを備えたConbeeIから最大範囲5mの約20台のデバイスを持っています。

Deconzバージョン2.05.69をお試しください。 Ikea、Innr、Xiaomiで私にはかなり安定しています

jtebbens 2020年02月01日

私は同様の問題とチケットを開いていますhttps://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue-543476970

2.05.67バージョンにダウングレードすると、ネットワークがこれまで以上に安定したと言えます。いくつかの球根が無反応状態になりましたが、同じ2つで、それらと一緒に暮らすことができました。昨日はすべてが期待どおりに機能しました。

考えられるすべてのパーツが混在していると問題になるようですが、もちろん見つけるのが難しくなります。ただし、deconzバージョンは、安定したソリューションがあるかどうかの主要な部分のように見えます。

また、Ikeaデバイス（バルブ、最近ではSymfoniskリモコン）が使用できなくなり、deCONZとの再ペアリングが必要になるという問題もあります。私はこれらの問題を6か月ほど続けてきたと思います。最近頻繁に発生すると思う以上に追加することはあまりありません。私はGU10電球を持っていません。さまざまなE27とE14（およびさまざまなリモコン）だけです。特定のデバイスはドロップアウトする傾向があるようです（おそらく、メッシュの方法などによって異なります）。私は、最新のFW / Phoscon / deCONZを備えたConbeeIから最大範囲5mの約20台のデバイスを持っています。
Deconzバージョン2.05.69をお試しください。 Ikea、Innr、Xiaomiで私にはかなり安定しています

それだけでなく、

数週間前、Phosconでライトのグループを作成し、HASSでこれらのグループを参照し始めました。

PeterRemnemark 2020年02月01日

そこで、ついにスニッフィングハードウェアを入手し、Wiresharkを少しハッキングして、すべてのieee802.15.4アドレスの名前を表示しました（これにより、何が起こっているのかがはるかに読みやすくなります）。

とにかく、ジグビーに関する私の知識はあまり強くないので、おそらく私は愚かな質問をしています。しかし、私はいくつかのスニッフィングログを調べてきました。うまくいけば、イケアライトの不安定な動作を説明する何かを見ることができます。

以下のログを参照してください。それは「通常の」動作のように見えますか？関係する両方のライトはIkealigthsです。最初のDeConzは、「Zolder」を経由して「Garage」にリクエストを送信します。次に、「Zolder」はそれを「Garage」に送信しようとしますが、失敗したようで（なぜ？）、非常にすばやく連続して20回再試行されます（ほとんどは3ミリ秒以内です）。最後に、「Zolder」はあきらめて、リンク障害をDeConzに送り返します。

送信の再試行においてこれほど積極的である必要がありますか？

また、リンクが明らかに失敗しているにもかかわらず、DeConzがZolderを介してガレージにリクエストを送信し続けていることに気付きました。 DeConzは、GarageがZolderのリンクステータスレポートに含まれなくなった場合でも、これを実行します。また、ガレージがZolderのリンクステータスレポートに含まれている場合は、着信と発信の両方で7のコストがかかります。実際、ガレージからデコンズへのルートはゾルダーを経由していません...
リンク障害メッセージが表示された後でも、DeConzがZolderを介してルーティングを続けるのはなぜですか？

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

djwlindenaar 2020年02月02日

👍3

さて、私はしばらくの間、silabs ZigBeeのドキュメントを読んでいます（IKEAはsilabsチップに基づいています）。
どうやら、再試行の動作は、ドキュメントに記載されているとおりです。

それはなぜDeConzがこのルートを使用することを主張するのかという疑問を残します。リンクコストが高く、リンク障害の応答がありますが、それでもそのルートが使用されます。なぜ..？
（そしてより良いルートが利用可能です...）

djwlindenaar 2020年02月02日

👍5

私はこのレベルであなたを支援することはできませんが、非常に有用な洞察@djwlindenaar 。これは私の疑いを少し確認します。偶発的な停電が発生し、家全体が真っ暗になるまで、（ソフトウェアのダウングレードを伴う）まともな作業ネットワークがありました。

その後、私は再び戻ってきて、私は再び悪いルートを持っていると思います。

もう1つ。実際のデバイスが応答しない場合でも、deconzが状態を設定するのはなぜですか？インターフェイスで電球がオンになっているように見えますが、物理的にはオフになっています（まだ電源が入っています）。（ソフトウェアを介して）再度オンにする場合もあれば、電源を入れ直しても機能する場合もありますが、電源を入れ直してもまったく応答しない場合があります。同じ電球がしばらくすると突然再び反応することがあります

PeterRemnemark 2020年02月04日

いくつかのより興味深い動作（私は同じライトを示していますが、これは私のネットワークの他の場所でも起こっています）

DeConzはmany-to-one route Route Requestパケットを送信します。その結果、どのデバイスでも最初にルート検出が行われます。これは、コンセントレーター（コーディネーター）にそのデバイスに到達する方法に関する情報を提供することになっています。 DeConzはルーティングのためにこの情報を無視しているようです...

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

その最後のパケットには、ガレージに到達する方法に関する情報が含まれています。

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

しかし、ガレージへの次のリクエストは再びゾルダーを介して送信されます

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

この振る舞いが、薄片状のIKEAライトの振る舞いと関係があることは驚くことではありません。

@manup 、これについてコメントして
あるいは、ルートレコードからの情報を使用してDeConzのルーティングテーブルを更新することは、すでに大幅な改善になると思います...
または、DeConzがリンクの問題を報告するルートを使い続けたい理由/代替手段と比較してルーティングコストが高い理由を理解する必要があります。

djwlindenaar 2020年02月05日

👍1

別の観察...上記のパケットの2つのリレーデバイスは両方ともXiaomiプラグです。リンク品質について問い合わせられることはありません。どうして？
DeConzがリンク品質応答の情報を使用してルートテーブルを作成しているため、非常に有効なルーターを無視している可能性がありますか？私の不幸なIKEAライトのいくつかへの良いリンク品質で...

djwlindenaar 2020年02月05日

ikeaデバイスのこの動作、または最適なルートを無視する一般的な動作のみが表示されますか？あなたはまともな数のikeaデバイスを持っていると思いますか？

PeterRemnemark 2020年02月05日

よくわかりません。確認する必要があります。良い質問。

はい、かなりの数のIkea電球を持っています。

私の考えでは、これは私たちが到達できないIKEAライトで見た行動の大部分を説明しています。現時点では単なる仮説ですが、検証する必要があります。

djwlindenaar 2020年02月05日

他のいくつかのルートを調べると、同じ動作が見られます。

Xiaomiデバイスが他のすべてのブランドのリンク品質について照会されていないことがわかります。これはある種のブラックリストだと思います。

その他のルーティング動作の例：

DeConzから、常に：
DeConz --> WC Lamp --> Badkamer Ledstrip

多対1のルートリクエストの後、リターンルートは頻繁に変更されます。地理的な観点から、これらすべてが理にかなっていることに注意してください...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

ガレージライトについては、DeConzからわかります。
DeConz --> Zolder Noord Lamp --> Garage （非常に不安定なルート..！）

私が見る帰路：
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

リンクステータスレポートの表を見ると、ガレージからDeConzへのルートの上のルートは理にかなっています。
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz総費用：4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz総費用：4

DeConzからガレージへはしません：
DeConz --> Zolder Noord Lamp --> Garage総コスト：12（DeConzからZolder Noordランプへの着信コストに基づく）

@manup 、使用中のルートコストアルゴリズムについて詳しく

djwlindenaar 2020年02月06日

今日はもう少し分析...
私の以前の投稿では、私のガレージライトが私のゾルダーライトを経由しているのを見てきました。両方のIKEA電球。ゾルダーからガレージへの無線リンクは、到達可能な範囲の端にあるため、失敗することがよくあります。

現在、ガレージライトはグループコマンドに応答しますが、ユニキャストコマンドには応答しません。実際にはそうなることもあれば、そうでないこともあります。これは、このスレッドを読んだり投稿したりした人にはおなじみの動作です。

これはスニッフィングログで見つけることができます。ゾルダーライトがガレージと通信できる場合とできない場合があります。ゾルダーライトがガレージと通信できないときはいつでも、これを報告します：

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]

このパケットは、ガレージに到達するための別のルートを見つけ始めるようにDeConzに指示する必要がありますが、それは起こりません。ガレージに送信された次のパケットは、再びZolderを経由してルーティングされます。私にとって、それは解決しなければならないバグです。
ガレージのこの次のパケットはゾルダーライトによって受信されますが、そのライトはそれをガレージに送信しようとさえしません。おそらくこれはIKEAファームウェアの動作であり、良くありませんが、問題の根本的な原因は、DeConzが代替ルートを見つけることを拒否したことです。
ルートが長期間利用できない場合、802.15.4プロトコルよりも高いレベルのACKに対してガレージライトが不足し、ファームウェアが切断されたり、クラッシュしたりする可能性があると思います。そして、私はそうすべきではないことに同意しますが、根本的な原因の問題は、DeConzがガレージライトへの新しいルートを見つけることを拒否していることです。

今日、私はDeConzにガレージライトへの別のルートを見つけるための実験を行ったので、メインをZolderライトから切り離し、スニッフィングログを調べました。数回の試行の後、DeConzは、Zolderがなくなったことに気付き、ガレージへの代替ルートを探します。次に、Zolderを再接続し、Zolderにもその存在を発表した後、新しいルートが見つかりました。 DeConzは（まだ）Zolderを介したガレージのルーティングに戻りません。

面白いことに、新しい状況では、DeConzはガレージライトと直接通信し、間にルーターはありません。
Zolderは、他の2つのルーターを経由するルートを介して到達するようになりました（DeConzから直接到達可能でしたが）。そのため、DeConzルーティングファームウェア内で一部のテーブル（隣接テーブル？）がいっぱいになっているように見えます。

おそらくこれは、失敗したルートに応答して新しいルートを作成することを拒否したことに関連しています。

@manup 、上記の投稿についてのコメントをいただければ幸いです。または、少なくとも、解決策に貢献する方法を教えてください（根本原因を探すことは別として）。

これらの問題は私を悩ませているので、解決策の作成を手伝いたいと思います。ファームウェアのソースコードへのアクセスを許可する場合は、直接貢献できます（オープンソースでなくても）。私はそのようにドレスデンElektronikを助けてもかまいません:)

djwlindenaar 2020年02月09日

👍13 ❤5

素晴らしい仕事ができました！ 💪🏼
これを修正するために開発者から注目を集めることができることを願っています。セットアップとプロセスが適切であるように見えるので、修正を非常に「簡単」に検証できます。
私が見た「自己治癒」と呼ばれる行動と、なぜいくつかの球根が突然機能するのかがわかりました。

PeterRemnemark 2020年02月09日

いい仕事@ djwlindenaar @ manupがこれを見て

Webserve 2020年02月16日

@manupコメントはありますか？

donnib 2020年02月18日

このスレッドと作業に感謝します。私は20個のikea電球アップデートファームウェアと1年前のものを実行しています。私は最初からドロップフリーズまたは電球の紛失を経験しましたが、あまり頻繁ではありません。その後のdeconzの更新で悪化しました。ネットワークが2.4パック環境で最適化されていることを確認しました。それでも電球は毎日脱落し、ボタンやセンサーはこれらの電球を介してルーティングされ、データの移動を送信しないため、役に立たなくなります。電球がセンサーを再びルーティングし始めたら、センサーを再び利用できるように電源を入れ直す必要があります。うまくいけば、これはmorの注目を集めるでしょう。イライラします。

realwax 2020年02月23日

別の観察...上記のパケットの2つのリレーデバイスは両方ともXiaomiプラグです。リンク品質について問い合わせられることはありません。どうして？
DeConzがリンク品質応答の情報を使用してルートテーブルを作成しているため、非常に有効なルーターを無視している可能性がありますか？私の不幸なIKEAライトのいくつかへの良いリンク品質で...

Xiaomiデバイスのネイバーテーブル（別名ZDP Mgmt_Lqi_req）のクエリは、しばらくするとこれらのクエリに応答しなくなったため無効になりました。ファームウェアのエラーにより、無効な状態またはそれ以上の状態が発生する可能性があると考えました。

したがって、特定のリクエストを制限する主な要因は、エンドデバイスファームウェアのエラーを防ぎ、関連するベンダーゲートウェイの動作を厳密に模倣することです。調査結果の一部は、 https：//github.com/dresden-elektronik/deconz-restにあります。 -プラグイン/ウィキ/エンドデバイス-ポーリング

補足として、ネイバーテーブルクエリはビジュアルメッシュプレゼンテーションを構築するためにのみ使用され、ネットワーク操作やルーティングテーブルには影響しません。

manup 2020年02月23日

そこで、ついにスニッフィングハードウェアを入手し、Wiresharkを少しハッキングして、すべてのieee802.15.4アドレスの名前を表示しました（これにより、何が起こっているのかがはるかに読みやすくなります）。
とにかく、ジグビーに関する私の知識はあまり強くないので、おそらく私は愚かな質問をしています。しかし、私はいくつかのスニッフィングログを調べてきました。うまくいけば、イケアライトの不安定な動作を説明する何かを見ることができます。
以下のログを参照してください。それは「通常の」動作のように見えますか？関係する両方のライトはIkealigthsです。最初のDeConzは、「Zolder」を経由して「Garage」にリクエストを送信します。次に、「Zolder」はそれを「Garage」に送信しようとしますが、失敗したようで（なぜ？）、非常にすばやく連続して20回再試行されます（ほとんどは3ミリ秒以内です）。最後に、「Zolder」はあきらめて、リンク障害をDeConzに送り返します。
送信の再試行においてこれほど積極的である必要がありますか？
また、リンクが明らかに失敗しているにもかかわらず、DeConzがZolderを介してガレージにリクエストを送信し続けていることに気付きました。 DeConzは、GarageがZolderのリンクステータスレポートに含まれなくなった場合でも、これを実行します。また、ガレージがZolderのリンクステータスレポートに含まれている場合は、着信と発信の両方で7のコストがかかります。実際、ガレージからデコンズへのルートはゾルダーを経由していません...
リンク障害メッセージが表示された後でも、DeConzがZolderを介してルーティングを続けるのはなぜですか？
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

いいキャッチ！ここでは、deCONZファームウェアがこのエラーを処理し、新しいルートを見つけるために再試行する必要があると思われます。このケースが処理されるかどうか、およびその方法についてファームウェアを確認します。ルートが実際に破棄されていることを想像できますが、同じルートを介して新しいメッセージを受信した場合。たとえば、ライトからのZCL属性レポートにより、エントリはそのまま保持されます。

着信フレームからコマンドを受信するだけでルートを確立できます。しかし、最後のホップがその前のホップを維持しない場合（通常はそうします）、同じホップを戻る方法は機能しません。あなたの調査結果はまさにそのケースを反映しているかもしれません。

manup 2020年02月23日

ありがとう。

この場合、Zolderを介して受信したガレージライトからのメッセージはありません。したがって、DeConzがこのルートを使い続けるとは思いません。私の他の投稿を参照してください...

djwlindenaar 2020年02月23日

ステータスコード：非ツリーリンク障害（0x02）

勝者がいるようです。Zigbeeスタックソース（R21、ConBee II）を確認しましたが、このステータスコードは完全に無視されます。：-O AVR Zigbeeスタックもチェックする必要があります。おそらく、同じ問題があります。

修正として、「ルートが利用できません」ステータスが処理されるのと同じ方法でこのコードを処理したいと思います。これは、ルートエントリを解放し、スタックに新しいルートエントリを認識させるためです。

manup 2020年02月23日

🎉6

コーディネーターからIKEAライトに事前に送信されたコマンドの完全なパケットもありますか？発見ルートビットが設定されていれば興味深いでしょう。

manup 2020年02月23日

この特定の場合に何が起こるべきかについてのZigbee仕様のセクションは次のとおりです。

コマンドフレームペイロードのステータスコードフィールドの値がリンク障害を示す0x01または0x02である、コマンドの目的の宛先であるルーターがネットワークステータスコマンドフレームを受信すると、NWKレイヤーはルーティングテーブルエントリを削除します。コマンドフレームペイロードの宛先アドレスフィールドの値（存在する場合）に対応し、同じステータスコードを使用してNLME-NWK-STATUS.indicationを使用して次の上位層に障害を通知します。

したがって、上記の修正は0x02に対してここで機能するはずですが、0x01も処理されません。これも追加します。

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

manup 2020年02月23日

素晴らしい@manup！あなたはコンビーIIについて言及しました。この修正はConbeeIでも機能しますか？

JBS5 2020年02月23日

はい、ConBeeIとRaspBeeで使用されているスタックソースだけです。ここでも同じ問題があります。火曜日までテスト用に新しいファームウェアバージョンを作成します。それが少なくともIKEAルーティングの問題を解決するなら、いくつかのフィードバックを得るのはクールだろう。

IKEAの電球が完全に無音になり、グループキャストを聴かないなど、これでは修正されない他の問題もあったことに注意してください。

manup 2020年02月23日

この問題を誤って閉じました...再開しました。これについて進歩していることは素晴らしいことです。

@djwlindenaarは、新しいファームウェアが利用可能になった後、スニッフィングハードウェアが必要なため、フィードバックを提供できる人だと思いますか？

JBS5 2020年02月23日

コーディネーターからIKEAライトに事前に送信されたコマンドの完全なパケットもありますか？発見ルートビットが設定されていれば興味深いでしょう。

あなたの質問を理解できるかわかりません。どのパケットを探していますか？そして、どの光（ガレージまたはゾルダー）に？

djwlindenaar 2020年02月23日

はい、ConBeeIとRaspBeeで使用されているスタックソースだけです。ここでも同じ問題があります。火曜日までテスト用に新しいファームウェアバージョンを作成します。それが少なくともIKEAルーティングの問題を解決するなら、いくつかのフィードバックを得るのはクールだろう。
IKEAの電球が完全に無音になり、グループキャストを聴かないなど、これでは修正されない他の問題もあったことに注意してください。

確かにテストします。長い間問題がないこともあるので、結論が出るまでには少し時間がかかるかもしれませんが...

完全に沈黙するという行動を引き起こす何かがあるのではないかと思っていました。私は先週これが起こったことがありますが、スニファーログを調べる時間がまだありませんでした。

私はRaspbeeところでいます。

djwlindenaar 2020年02月23日

はい、ConBeeIとRaspBeeで使用されているスタックソースだけです。ここでも同じ問題があります。火曜日までテスト用に新しいファームウェアバージョンを作成します。それが少なくともIKEAルーティングの問題を解決するなら、いくつかのフィードバックを得るのはクールだろう。

私はこの問題をたくさん抱えており、スニッフィングはしていませんが、テストすることができました。

IKEAの電球が完全に無音になり、グループキャストを聴かないなど、これでは修正されない他の問題もあったことに注意してください。

これは、ソフトウェア（deconz）が状態を報告および設定しているが、電球自体が応答しない、または状態を変更しないという問題を指しますか？ルーティングの問題を突き止めれば、問題の重大度は同じではないかもしれません。

これを調べてくれてありがとう、高く評価されています！

PeterRemnemark 2020年02月23日

はい、ConBeeIとRaspBeeで使用されているスタックソースだけです。ここでも同じ問題があります。火曜日までテスト用に新しいファームウェアバージョンを作成します。それが少なくともIKEAルーティングの問題を解決するなら、いくつかのフィードバックを得るのはクールだろう。
IKEAの電球が完全に無音になり、グループキャストを聴かないなど、これでは修正されない他の問題もあったことに注意してください。

マヌプありがとう！新しいfwが利用可能になり次第、アップグレードしてアップデートを提供します。

tubalainen 2020年02月23日

この問題は、Ikea Fyrturブラインドの制御に関する問題にも関連している可能性がありますか？

olemr 2020年02月23日

私には奇妙に思えるもう1つ。 @manup 、これも問題になる可能性がありますか？

私はこれらの種類のシーケンスをたくさん見ます。これが応答を停止する前のハウトランプからの最後の通信であるため、私はこれを調べ始めました。 DeConzは、2つの属性レポート項目を構成し、ほぼ同時にグループメンバーシップを要求します。 de DeConzログでは、これは次のようになります。

シーケンス番号の選択にバグがあるのか、それとも許可されているのか（わかりません）、この動作がTradfriファームウェアのバグを引き起こしているのではないかと思います。番号215のリクエストが1つ、番号216のリクエストが2つあります。tradfriファームウェアによるリクエストの処理により、2つのリクエストが原因でメモリリークが発生したり、ハングアップしたりする競合状態が発生している可能性があります。ほぼ同時に同じ番号で？ Shoud DeConzは、同じシーケンス番号で2つのリクエストを出しましたか？

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

無線では、次のようになります（無線ですべてのパケットが表示されているわけではないようです。これは、スニファがラズビーのすぐ隣にあるため奇妙です。バッファオーバーフローなどで失われるほど、すばやく送信される可能性があります。スニファー）

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

djwlindenaar 2020年02月24日

👍2

確かに、シーケンス番号はこの短い時間で等しくないはずです、私はコードをチェックします、増分が欠落しているように見えます。

これがConBeeIIの最初のテストファームウェアです

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

これをConBeeI / RaspBeeファームウェアに移植し直すと、まもなくオンラインになります。

manup 2020年02月24日

👍3

これが、ルートエラーが修正されたConBeeIとRaspBeeのテストバージョンです。
エラーが発生したときに新しいルートを発見するためのいくつかの改善がもたらされることを願っています。

テストでは、数日/数週間だけ実行すると、ライトがユニキャストに応答しなくなるかどうかを確認できればよいと思います。この場合でも、ライトがグループコマンドに反応するか、完全に無音になるか試してみてください。

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

manup 2020年02月24日

👍4

テストでは、数日/数週間だけ実行すると、ライトがユニキャストに応答しなくなるかどうかを確認できればよいと思います。この場合でも、ライトがグループコマンドに反応するか、完全に無音になるか試してみてください。

また、グループコマンドに反応する場合は、数日待って、グループコマンドに反応し続けることを確認します。私の場合、ライトがグループコマンドにのみ反応しているときは、すぐに完全に無音になります。

JBS5 2020年02月24日

また、グループコマンドに反応する場合は、数日待って、グループコマンドに反応し続けることを確認します。私の場合、ライトがグループコマンドにのみ反応しているときは、すぐに完全に無音になります。

私も過去にこれを見たことがありますが、ユニキャストが受信されなくなったため、おそらくこれを行っています。

manup 2020年02月24日

@manupこの問題は関連している可能性がありますか？ https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

JBS5 2020年02月24日

たぶんそうです、少なくともルートが壊れたとき、到達可能な状態も偽になります。しかし、これは他の理由によっても引き起こされる可能性があります。

manup 2020年02月24日

👍3

一部のイケア電球には新しいファームウェアがあることに気づきました。変更ログには、ネットワーク/接続性と障害管理の改善が記載されています。私は20個の電球を更新しています...役に立ったら更新を提供します。

realwax 2020年02月24日

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

リリース日が含まれていないのは残念です...

olemr 2020年02月25日

https://ww8.ikea.com/ikeahomesmart/releasenotes/releasenotes.html
リリース日が含まれていないのは残念です...

リリースノートに記載されている会社の2.3.007をダウンロードできたので、リリースされたようです。

1月頃だったに違いないhttps://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

realwax 2020年02月25日

彼女のプログラマーではありません。 conbee 2にr21をインストールして待つべきではないと思いますか？これはベータファームウェアですか？

MattL0 2020年02月25日

少し外れたトピック：Trådfri調光器の新しいファームウェアもZB3にアップグレードします。＃2485を相互参照すると、調光器でも同じ問題が発生します...古いモデルのモーションセンサーが次に来ると思います...

ebaauw 2020年02月25日

これが、ルートエラーが修正されたConBeeIとRaspBeeのテストバージョンです。
エラーが発生したときに新しいルートを発見するためのいくつかの改善がもたらされることを願っています。
テストでは、数日/数週間だけ実行すると、ライトがユニキャストに応答しなくなるかどうかを確認できればよいと思います。この場合でも、ライトがグループコマンドに反応するか、完全に無音になるか試してみてください。
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

おかげで、 @ manup 、ちょうどそれをインストールしました。それが何をもたらすか見てみましょう。

これによりある程度の改善が見込めると思いますが、記録されたルートを無視するDeConzファームウェアについてどう思いますか（たてがみから1へのルーティングのため）。一般に、記録されたルートは、DeConzファームウェアで使用されるルートよりもはるかに論理的であることがわかりました。
ソースルーティングを有効にすることは大きな仕事だと想像できますが、DeConzファームウェアは、ルートレコードパケットからの情報を使用して、デバイスへの最初のホップを更新できます（すべきですか？）。コーディネーターへのラストホップがルーティングテーブルに格納されているものと一致するかどうかを確認し、一致しない場合は、ルーティングテーブルのエントリを無効にします。途中のデバイスはおそらく情報を無視するため、エントリを記録されたルートの最後のホップに置き換えてもよいかどうかはわかりませんが、少なくともDeConzファームウェアによってそのノードの新しいルート検出を開始できます。

これについてあなたはどう思いますか？

djwlindenaar 2020年02月25日

私は自分のraspbeeにファームウェアをインストールしました（私は73のノードを主にikeaに持っています）、結果を報告します。

donnib 2020年02月25日

確かに、シーケンス番号はこの短い時間で等しくないはずです、私はコードをチェックします、増分が欠落しているように見えます。

@manup 、多分あなたが問題を特定するのを助けるために、私は今日再びその問題を見ました。これは、2つの構成レポートアクションが非常に密接に関連しているようです。 2番目のシーケンス：この場合の183は、以前に報告したものとは異なります。

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

djwlindenaar 2020年02月25日

シーケンス番号の問題は2.05.74で修正されるはずです。これは現在構築中であり、数時間以内に利用可能になります。

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

manup 2020年02月25日

これが、ルートエラーが修正されたConBeeIとRaspBeeのテストバージョンです。
エラーが発生したときに新しいルートを発見するためのいくつかの改善がもたらされることを願っています。
テストでは、数日/数週間だけ実行すると、ライトがユニキャストに応答しなくなるかどうかを確認できればよいと思います。この場合でも、ライトがグループコマンドに反応するか、完全に無音になるか試してみてください。
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF
おかげで、 @ manup 、ちょうどそれをインストールしました。それが何をもたらすか見てみましょう。
これによりある程度の改善が見込めると思いますが、記録されたルートを無視するDeConzファームウェアについてどう思いますか（たてがみから1へのルーティングのため）。一般に、記録されたルートは、DeConzファームウェアで使用されるルートよりもはるかに論理的であることがわかりました。
ソースルーティングを有効にすることは大きな仕事だと想像できますが、DeConzファームウェアは、ルートレコードパケットからの情報を使用して、デバイスへの最初のホップを更新できます（すべきですか？）。コーディネーターへのラストホップがルーティングテーブルに格納されているものと一致するかどうかを確認し、一致しない場合は、ルーティングテーブルのエントリを無効にします。途中のデバイスはおそらく情報を無視するため、エントリを記録されたルートの最後のホップに置き換えてもよいかどうかはわかりませんが、少なくともDeConzファームウェアによってそのノードの新しいルート検出を開始できます。
これについてあなたはどう思いますか？

うーん奇妙なことに、ファームウェアはすでにこれらのルートレコードを使用して新しいルートを確立しているはずです。ここでコードを確認する必要がありますが、私のメモリが正しくサービスを提供している場合、これはしばらく前に有効になりました。

manup 2020年02月25日

これについてあなたはどう思いますか？
うーん奇妙なことに、ファームウェアはすでにこれらのルートレコードを使用して新しいルートを確立しているはずです。ここでコードを確認する必要がありますが、私のメモリが正しくサービスを提供している場合、これはしばらく前に有効になりました。

さて、私はこのようなことをZolderとGarageで（多くの投稿から）進行させました、そして私はこの振る舞いを得ました：

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

ルートレコードは次のことを示しました。

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

DeConzからガレージへの次の通信は次のとおりです。

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

したがって、ルートの記録を引き継いでいないことは明らかです。

このときに気付いたのは、 Zolder電源を切るとすぐに、DeConzが新しいルートを見つけることができるということでした。したがって、ルーティング関連のテーブルの一部がDeConzファームウェア内でいっぱいになっている可能性があります。これは本当でしょうか？ファームウェアのネイバー/ルーティングテーブルの大きさはどれくらいですか？完全なテーブルが新しいルート記録の採用を妨げている可能性がありますか？

djwlindenaar 2020年02月25日

成功！ツリー以外のリンクに障害が発生した後、ルート検出が実際に開始されるようになったことを確認できます。

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

djwlindenaar 2020年02月25日

❤1 🎉1

シーケンス番号の問題は2.05.74で修正されるはずです。これは現在構築中であり、数時間以内に利用可能になります。
33d8a8b

"swversion": "2.5.74",

：smile：ありがとう@manup素晴らしい応答時間：1st_place_medal：

djwlindenaar 2020年02月25日

2.05.74への更新を待つか、 http： //phoscon.de/appを使用してPhosconアプリを表示してください。ゲートウェイのオフラインページが表示されるべきではないページに表示されるのを確認しました。今すぐ再構築してから約2時間です。

manup 2020年02月25日

確かに、シーケンス番号はこの短い時間で等しくないはずです、私はコードをチェックします、増分が欠落しているように見えます。
これがConBeeIIの最初のテストファームウェアです
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF
これをConBeeI / RaspBeeファームウェアに移植し直すと、まもなくオンラインになります。

このFWは私には機能しません。すべてのデバイスが結合されていると表示されますが、メッシュは構築されていません。接続はGUIに表示されず、Phosconからの切り替えも機能しませんでした（2.05.74）。 Conbee IIをフラッシュして264A0700に戻し、すべてが期待どおりに再び機能します...

cs42 2020年02月25日

😕1

うーん、どれくらい走ったの？
私は今のところ問題なくこのファームウェアを複数のセットアップで実行しています。

manup 2020年02月25日

うーん、どれくらい走ったの？
私は今のところ問題なくこのファームウェアを複数のセットアップで実行しています。

数分。一部のデバイス（青い点）でいくつかのアクティビティを確認しましたが、リンクが構築されていません。そして、切り替えはまったく機能しませんでした。もっと長い時間テストする必要がありますか？

cs42 2020年02月25日

メッシュが構築されるまでしばらく時間がかかる場合がありますが、5〜10分後に線が表示されます。

manup 2020年02月25日

このFWは私には機能しません。

ここでも同じ、Rasperry Pi 4B、deCONZ 2.05.74、ConBeeII。 Trådriリピーター、Trådfriプラグ、XBee、Trådfri調光器、2つのTrådfriモーションセンサー（新旧）、およびTrådriオン/オフスイッチを備えた小規模なテストネットワーク。ゲートウェイは、どのデバイスからもトラフィックを送受信していないようです。 SyslogでUSBが切断されているのを確認します。 4Aにフラッシュバックした後、すべてが再びハンキーなドーリーです。
log.gz

ebaauw 2020年02月25日

テストするためにもう一度点滅しました：

GUIに行がありません（15分間実行します）
USB接続は安定しているようです
UBISYSC4およびD1スイッチは引き続き機能します
Tradfriボタンはしません

cs42 2020年02月25日

@ebaauwログは、コーディネーターがこのバージョンで2つのネイバーのみを認識していることを示しています。

おそらくそれはネットワークサイズです。私は現在、ここで電力を供給されているデバイスは40台だけです。このファームウェアバージョンには、原因となる可能性のある他の2つの変更があります。メッセージバッファサイズの増加（私が知る限り、少し上になりますが、再び減少します）と、TX電力設定がわずかに低くなります。

これらの設定を削除して別のバージョンを準備し、それがより適切に機能するかどうかを確認します。

USB延長ケーブルを使用していますか、それともConBee IIを直接接続していますか？

manup 2020年02月25日

私にとっては、Raspbeeで正常に動作します...

djwlindenaar 2020年02月25日

RaspBeeおよびConBee1では、ルート修正のみが新しいバージョンに含まれています（異なるファームウェア）。

manup 2020年02月25日

ログには、コーディネーターがこのバージョンのネイバーを2つしか認識していないことが示されています。

はい、2つのエンドデバイスがGUIでネイバーとして表示されました。 ConBee IIファームウェアをダウングレードした後、別のルーターに接続されていることが示されたため、ちょっと奇妙です。

USB延長ケーブルを使用していますか、それともConBee IIを直接接続していますか？

入手してからずっと直結しています。 XBeeを他のUSB-2ポートに接続した状態で、PiのUSB-2ポートに接続します。 USB-3には何もありません。 ConBee IIをルーターとして構成した場合を除いて、接続は安定しています（＃2463を参照）。

RaspBeeおよびConBee1では、ルート修正のみが新しいバージョンに含まれています（異なるファームウェア）。

まだ試していません。後でまで待たなければならないでしょう...

ebaauw 2020年02月25日

設定レポートパケットがかなりたくさんあります。少し調べてみると、これらは約30分ごとに定期的に送信されているようです。これらの構成レポート要求が定期的に繰り返される理由は何ですか？
@ ebaauw 、IKEAコーディネーターの行動についてこれらの調査をたくさん行ったことを正しく覚えていますか？それもそうですか？

de_web_plugin_private.h気づきました

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

djwlindenaar 2020年02月26日

多対1のルートレコードを無視したDeConzのルーティング動作に関する別の証拠を見つけました。これにより、一部のルーターは「昔ながらの」方法でルーティングを把握する必要があります。
（パケット117130：wink :)にいくつかの異常な干渉があることに注意してください。

以下のためのルートbadkamer ledstrip 、DeConzによると、で始まるOn/Off light 36当然そこに取得する方法を知っていません。したがって、ルートディスカバリーを開始し、最終的にledstrip自体に到達できることを（ほとんどないと思いますが）見つけます。リターンパスはGang 1経由します

多対1のルートリクエストが処理されるたびに、 On/Off light 36がBadkamer ledstrip忘れているようです...

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

次のコミュニケーション：

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

djwlindenaar 2020年02月26日

ConBee IIファームウェアの別の試み：

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

このバージョンのTX電力設定は0x264a0700です。バッファはまだ大きいです（ただし、マップによれば、RAMにうまく収まるはずです）。一度に1つのことだけをチェックします。

manup 2020年02月26日

最新のファームウェアにアップデートしようとするたびに、このエラーが発生しました。なぜヒントはありますか？
rich710 @ RichHassPc01 ：〜$ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13（c）ドレスデンelektronik ingenieurtechnik gmbh
デバイス/ dev / ttyACM1（ConBee II）を再起動します
deCONZファームウェアバージョン26490700
R21B18ブートローダー
Vers：2.05
ビルド：2019年3月22日
161378バイトの点滅：| ============================== |
確認：。
フラッシュアップデートに失敗しました。CRCが無効です。もう一度やり直してください。
rich710 @ RichHassPc01 ：〜$

rich710se 2020年02月26日

ダウンロードしたファイルのMD5合計を確認しましたか？（http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5）

timbru31 2020年02月26日

はい、確認して数回ダウンロードしましたが、古いファームウェアに戻そうとしても、今まではうまくいきました。今、私はこのエラーで立ち往生しています。NUCを数回再起動しましたが、フラッシャーがConbeeIIを再起動しようとするとスタックします。
rich710 @ RichHassPc01 ：〜$ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] rich710のパスワード：
GCFFlasher V3_13（c）ドレスデンelektronik ingenieurtechnik gmbh
デバイス/ dev / ttyACM1（ConBee II）を再起動します

2139：エラー：UARTのリセットに失敗しました。再試行を確認してください

rich710se 2020年02月26日

使用するときにttyACM1を使用していることに気づきました

GCFFlasher -l

シリアル番号が表示されます。
これを使用して、コマンドでより安定したデバイス名を指定できます。

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

（デバイスのシリアル番号に置き換えてください）

manup 2020年02月26日

申し訳ありませんが動作しませんでした、多分私はそれを私のWindowsマシンに移動して試してみる必要があります
rich710 @ RichHassPc01 ：〜$ GCFFlasher_internal -l
GCFFlasher V3_13（c）ドレスデンelektronik ingenieurtechnik gmbh
パス| ベンダー| 製品| シリアル| タイプ
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | ジェネリックFTDI
rich710 @ RichHassPc01 ：〜$ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13（c）ドレスデンelektronik ingenieurtechnik gmbh
デバイスを再起動します（ConBee II）

2139：エラー：UARTのリセットに失敗しました。再試行を確認してください
rich710 @ RichHassPc01 ：〜$

rich710se 2020年02月26日

それまたは代わりに、次のことを試してみてください。

ConBeeIIのプラグを抜きます
GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
ConBeeIIを再度プラグインします

manup 2020年02月26日

-tパラメーターを使用すると、GCFFlasherは1分間更新を処理しようとします。

manup 2020年02月26日

それはWindowsのファームウェアを更新するために機能し、ubuntuを使用してNUCに接続すると、接続されました。しかし、1時間後、ノードの4つに接続されました。：S
Annotation 2020-02-26 172624

rich710se 2020年02月26日

ConBee IIファームウェアの別の試み： http ：//deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

USBが切断されることはもうありませんが、deCONZはConBeeIIを頻繁に再検出しているようです。まだトラフィックはありません。
log.gz

編集ユーモアを交えて、私はXBeeを取り外し、10cmのUSB延長ケーブルを使用してConBeeIIを接続しました。変更はありません。

ebaauw 2020年02月26日

ConBee IIファームウェアの別の試み：
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF
このバージョンのTX電力設定は0x264a0700です。バッファはまだ大きいです（ただし、マップによれば、RAMにうまく収まるはずです）。一度に1つのことだけをチェックします。

新しいバージョンをテストしましたが、10分経ってもリンクが表示されません...安定したFWを使用すると、ネットワーク内のすべての正常な（ルーター）リンクが約2分後に表示されます。 IKEAプッシュボタンはすぐに機能しますが、テストファームウェアではまったく機能しません。

cs42 2020年02月26日

うーん不気味です、これをテストしてくれてありがとう。次に、前述のようにバッファサイズを小さくしてみます。
それでも、なぜそれが私のセットアップで機能しているのか疑問に思います。上のスクリーンショットから、ルーターよりもエンドデバイスの数が多いことがわかります。

manup 2020年02月26日

@manupはファームウェアをフラッシュした後も同じ問題を抱えていましたが、deconzでデバイスの再起動を押す/ deconzを再起動すると、リンクが戻ってきました。

jurriaan 2020年02月26日

これが、ルートエラーが修正されたConBeeIとRaspBeeのテストバージョンです。

私のPi3B +テストシステムでは問題なく動作しているようです。実稼働ネットワークをアップグレードする前に、今週末まで待ちます。

ebaauw 2020年02月26日

@ ebaauw 、IKEAコーディネーターの行動についてこれらの調査をたくさん行ったことを正しく覚えていますか？それもそうですか？

ほとんどのTrådfriデバイスのサポートを追加しましたが、Trådfriハブとの間のZigBeeトラフィックをスニッフィングできませんでした。タッチリンクペアリングのみを使用しており、ネットワークキーを回復するためにそれをキャプチャすることはまだ試みていません。つまり、それがまったく可能であると仮定します。

ebaauw 2020年02月26日

新しいファームウェアのリリース以来、約40ノードのセットアップでconbee 1スティックで新しいFWを実行してきましたが、問題なく正常に動作して

コードのトラブルシューティングと更新を行ってくれた関係者全員に感謝します。とても感謝しています！ <3

tubalainen 2020年02月27日

私のために働いていません。グリッド内の接続はほとんどありません。再起動後約20分待ちました。

Raspberry Pi3モデルBRev 1.2
コンビーII
バージョン2.05.74
バージョン26530700

77ノード

3への接続
1TRÅDFRIオン/オフスイッチ
1Xiaomiマルチセンサー
1フィリップス調光スイッチ
フィリップス調光スイッチからイベントをトリガーすることができます。
接続されているこれらは、コンビースティックに非常に近いです。スティックはガレージにあります。ガレージに接続のない球根がいくつかあります。

への接続なし
E27とGU10の両方の多くのイケア電球
Xiaomiマルチセンサーがたくさん
たくさんのIkeaTRÅDFRIリモコン
そして他のノード。

ログ
2月27日09：29：06raspberrypi systemd [1]：deCONZを開始しました：ZigBeeゲートウェイ-GUI / RESTAPI。
2月27日09：29：06raspberrypi deCONZ [7204]：libEGL警告：DRI2：認証に失敗しました
2月27日09：29：06raspberrypi deCONZ [7204]：libpng警告：iCCP：既知の不正なsRGBプロファイル

264A0700にダウングレードすると、メッシュの直接構築が開始されます。

danielkihlgren 2020年02月27日

@ ebaauw 、IKEAコーディネーターの行動についてこれらの調査をたくさん行ったことを正しく覚えていますか？それもそうですか？
ほとんどのTrådfriデバイスのサポートを追加しましたが、Trådfriハブとの間のZigBeeトラフィックをスニッフィングできませんでした。タッチリンクペアリングのみを使用しており、ネットワークキーを回復するためにそれをキャプチャすることはまだ試みていません。つまり、それがまったく可能であると仮定します。

そう、ごめんなさい。 gitのせいをチェックすべきだった。 IKEAゲートウェイの動作に言及するコードは、実際には@manupによって48d2c39a267b5c6d025577eed7530be27932aa2cに導入されました...

@ manup 、IKEAゲートウェイがこれを頻繁に報告する属性を再構成することを実際に確認しましたか？なぜ再構成が必要になるのでしょうか。光は定期的に思い出させる必要がありますか？

djwlindenaar 2020年02月27日

ConbeeIをベータFWおよびdeCONZ.74にアップグレードしました

メッシュはすぐに構築され、本当に見栄えがします！

@djwlindenaarに感謝し@manupにも感謝します...

mvjt 2020年02月27日

コンビーIと.74も。 Ikea FWを2.3.007にアップグレードしました（他のいくつかは2.x）。
大幅な改善！ドロップアウトはまだありません！

このスレッド以降で貢献、開発、デバッグ、テストを行っているすべての人に感謝します。

その過程で私が見つけたもの：
通常のグループON-OFFはすばやく機能しますが、シーンをリコールして（フェードイン時間後）再びオフにした後（<10秒）、GUIでのみライトが消えます（古いGUIまたは新しいGUIに関係なく）その後、一部のシーンが再びオンになります（GUIで）すべての物理的な球根がまだオンのままである間、グループで。 2回目または3回目のOFFを押した後、時々暗くなります。

ファームウェアのアップグレード後にシーンを復元/再構築することは珍しいことではありません
ただし、新しいシーンを作成する場合でも、古いシーンを修正しようとする場合でも、動作は同じです。通常のオンオフは影響を受けません。

もう少し待つと、いつものように動作することがわかりました。 15〜20秒としましょう。その後、通常どおりライトが消えます。 deconzは、フェードインするまでライトをオフにしたときと同じように混乱すると思います。

すべてのライトの状態が報告され、シーンのリコールがdeconzで実行されるか、正常に報告されるまで、遅延が増加したようです。そのため、そのグループ内の他のアクションは必要に応じて機能します。これにはもう少し時間がかかるようです。この期間内に-あなたは（合格;））-スイッチライトをオフにしてはならない。これは重要ではありません。

realwax 2020年02月27日

もう少しテストしました。行動に変化があります。以前は、briが特定の速度で変更された場合、またはシーンの遷移時間が長い場合、新しいコマンドで中断することができました。前のアクションがまだ実行されていても、次のコマンドはキューに入れられました。今では失われています。エグミーフロアライトはモーションセンサーで作動します。それらが消える前に、私はそれらを暗くし、それらをオフにする前に10秒間待ちます。モーションをトリガーして、フェード中にシーンをリコールすると、コマンドが失われます。その前に、それはキューに入れられ、後で実行されました。これはによるものですか。 74または新しいファームウェア？ありがとう

realwax 2020年02月28日

私のConbeeIIは、ベータ版でメッシュを構築しませんでした。「通常の」設定と異なる可能性があると私が考えることができるのは、チャネルを25に設定することだけです。264a0700に戻ると修正されました

helto4real 2020年02月28日

@ realwax 、Trådfriファームウェアのバグが発生していると思います。＃2068を参照してください。 GUIで遷移時間が長いコマンドを発行してから、2番目のコマンドを発行することで、これを簡単に確認できます。

その前に、それはキューに入れられ、後で実行されました。

ライトファームウェアを更新しましたか？同じライトを使用していますか？ REST APIプラグインは、ライトにコマンドを送信すると、遷移時間を追跡しません。

ebaauw 2020年02月28日

@ebaauw私を正しい方向に導いてくれてありがとう。 IKEAがリリースログにネットワークと安定性の改善を含めると述べたように、私はTRÅDFRIランプE14 WSオパール400lmをファームウェア2.3.007（最新）にアップグレードします。私はそれがこれらの問題のいくつかを和らげるかもしれないと思いました。これは使いやすさの大きな問題なので、IKEAは自分のブリッジでどのようにトリックを行うのだろうか。あなたが他の問題で述べたように、今私はより速い移行時間に行かなければなりません。私は初日からこれを経験しますが、悪化しました。今では、シーンのリコールのフェードに影響するだけでなく、トランジションが長い変更にも影響します。これは新しいことです...どうすればよいですか？ deconzとの闘いであるため、古いfwにフラッシュバックすることはほとんど不可能です。エリックありがとう。

realwax 2020年02月28日

これは使いやすさの大きな問題なので、IKEAは自分のブリッジでどのようにトリックを行うのだろうか。

Trådfriハブは、deCONZゲートウェイやHueブリッジほどアクティブではありません。 Trådfriコントローラー（スイッチ、調光器、およびそれらのモーションセンサー）は、ライトを直接制御します。 Trådfriライトは、状態の変化とともにプッシュ通知をハブに送信します。ハブは、アプリにのみ必要/使用されます。いくつかのアラームを実行する可能性がありますが、ボタンイベントやその他の凝ったものを処理するためのルールはありません。

Trådfriアプリがより長い遷移時間の指定をサポートしているかどうかはわかりませんが、私が見たコントローラーはサポートしていません。おそらく、ライトのデフォルトの遷移時間よりも速くコントローラーからコマンドを送信することはできません。そして、たまにそうするなら、あなたはおそらくあなたがボタンを完全に押さなかったと思うでしょう。

ebaauw 2020年02月28日

👍1

@ebaauwなるほど。まだ私を困惑させているのは、E14のグループ（ある種の軽いディスコを提供する;））を1秒以内（オン-オフ-オン）でオン/オフできるという事実です！しかし、deconzのシーンリコールボタンを押すとすぐにできなくなり、動作がおかしくなります。これは私がどういうわけかそれがIKEAのせいであると疑うところです。なぜ本当にすばやくオンとオフを切り替えることができますが、シーンを思い出すとすぐに、少なくとも5〜10秒間スタックしますか？

正確に測定された時間（20回の試行）：
8人のグループE14
グループオン->グループオフ-切り替え時間1秒
シーンのリコール->スイッチオン->オフ10〜12秒まで応答しません！

リコールにより、より多くのトラフィックが生成され、すべての電球がより多くのメッセージを受け取ることを理解していますが、10秒の違いはありますか？グループ全体でbriとctを変更した場合でも、すぐにオフにできますが、リコールはフリーズのようなものです。これはデコンズの問題のようだと思いますね。

私はそれをビデオ録画することができます。 ;）たぶん私はここで知識が不足しているので、理解の欠如を提示することを許してください、しかし私はそれが苦労しているのでどういうわけかイライラしています...

realwax 2020年02月28日

私はまだシーンについて少し混乱しているのではないかと思います。グループのように、それらはZigBeeのオブジェクトとして存在せず、デバイス（ライト）が状態を格納するための単なる数値です。シーンのリコール時に、番号が送信され、各デバイスはその不揮発性メモリから状態を復元します。

あいまいな部分は、シーンを保存するときにすべてのデバイスが状態を正しく保存しているようには見えないことです。色温度が悪名高いのはこの点です。私はまた、光がまだ移行している間にシーンを保存する面白いものを見ました。その場合、 /scenesリソースはライトに保存されている状態と同期していないため、APIは実際のライトの状態ではなくリソースの状態を反映します。これは、次にライトが点灯したときにのみ更新されます。ポーリング。通常、遷移時間はシーンを呼び出すときに指定されますが、保存された状態でもあるように見えます。

実稼働ネットワークのセットアップを（ phを使用して）スクリプト化したので、簡単に再作成できます。予測可能な方法でシーンの作成をスクリプト化するのに非常に苦労しました。結局、ライトの状態を設定し、数秒間スリープし、状態が落ち着くのを待ってシーンを保存し、再び数秒間スリープして、状態が保存されるのを待ちました。

シーンを再作成しようとするかもしれませんが、保証はありません...

ebaauw 2020年02月28日

👍1

同期していないトピックを初日から再現できました。私はデコンズとシーンの再構成の必要性に時々慣れていました。今、それは本当に悪いです。現在、deconzからiobrokerにソースを出し、そこですべてのシーンを再構築する必要があります。しかし、これは大変な作業です。うまくいけば、これは修正されます。問題を作成できますか？シーンを使用するとき、ライトはもう信頼できません...-私も再現しようとします。昨日、既存のシーンに加えて「テスト」シーンを実行しましたが、他の動作は見られませんでした。

realwax 2020年02月28日

関連するかどうかはわかりませんが、Conbee Iをベータファームウェアにアップグレードし、deCONZを.74にアップグレードした後、1日かかり、deCONZはConbeeへの接続を失いました。何年も前にこれを経験したことはありません...しかし、私はそれについて言及したいと思いました...ログはちょうどそれと何度も接続するための再試行を述べました... deCONZの再起動はそれを解決しました...（dockerコンテナを使用して）

mvjt 2020年02月28日

グループ、すべてのシーンを再作成しようとしました...作成プロセスでは、多くの問題が発生しています。 Phosconと「すべて」の電球の選択を使用すると、シーンの値が正しく保存されません。設定されたライトでさえあなたが望むものを示しますが、リコールはしません。同じ設定を行った場合でも、各ライトを独自に制御する必要があります。特に、誤って保存された色の色温度エラーを修正するには、古いGUIを使用する必要があります。シーンが「機能する」まで、シーンの構成プロセス中にライトのオンとオフを切り替えて適切に保存されるように、シーンを数回確認する必要があります。ここでは技術的な詳細はあまりありませんが、スレッド内のすべての人に、シーンのテスト、作成、保存、リコール、およびリコール後のスイッチオフを勇気づけたいと思います。これはIKEAの電球でめちゃくちゃになって悪化していると思います... IKEAの場合もありますが、他のすべてと直接のグループ制御がデコンズの魅力のように機能するので疑問です。

ファームウェアを1.xにロールバック/ダウングレードして、より適切に機能するかどうかを確認します。報告します。

realwax 2020年02月28日

OK。ふりだしに戻る。昨日2IKEAライトは休職しましたが、電源を入れ直した後に戻ってきました。修正されたバグがバグではなかったと言っているわけではありません。彼らはいた。問題を引き起こしているものだけではありません。

私は属性レポートのことをもっと深く調べていました。 30分（1800秒）ごとに属性レポートを繰り返し構成することで、ライトファームウェアがハングアップするのではないかと思っていました。
rq.maxinterval == 0明示的に処理していないように見えるこのコードに気づきました。 rq.maxinterval == 0はライトが変更のみを報告することを意味するため、このケースを適切に処理する方法は少し難しいので、その場合の「適切な」タイムアウトはありません...多分現在の実装は問題ありませんがもっといいアイデアがあるのかな。

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

番号タイムソース送信開発受信開発宛先デフォルトの応答情報を無効にする
208134 10h 43m23.151sギャング1ギャング1DeConz DeConz False ZCL：レポート属性、シーケンス：15
208136 10h 43m 23.158s DeConz DeConz Gang 1 Gang 1 APS：Ack、Dst Endpt：1、Src Endpt：1
208138 10h 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.

番号タイムソース送信開発受信開発宛先デフォルトの応答情報を無効にする
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL：Configure Reporting、Seq：41
207949 10h 43m8.481ギャング1ギャング1DeConz DeConz False ZCL：レポート応答の構成、シーケンス：41
207951 10h 43m8.485ギャング1ギャング1DeConz DeConz APS：Ack、Dst Endpt：1、Src Endpt：1
207952 10h 43m 8.487 DeConz DeConz Gang 1 Gang 1 APS：Ack、Dst Endpt：1、Src Endpt：1
207954 10h 43m8.493ギャング1ギャング1DeConz 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())

djwlindenaar 2020年02月29日

❤1

rq.maxinterval == 0を明示的に処理していないように見えるこのコードに気づきました。 rq.maxinterval == 0はライトが変更のみを報告することを意味するため、このケースを適切に処理する方法は少し難しいので、その場合の「適切な」タイムアウトはありません...おそらく現在の実装は問題ありませんが、もっと良いアイデアがあるのではないかと思います。

ええ、REST APIプラグインは、属性レポートが機能していることを確認します。そうでない場合は、再構成を試みますが、デバイスのポーリングにもフォールバックすると思います。

変更が加えられたときだけでなく、定期的にONOFFとLEVELを報告するようにIKEAライトに依頼するなど、いくつかの実験を行いました。ライトは定期的にステータスを喜んで報告するので、上記の問題を回避するための許容できる方法かもしれません。もちろん正しく検証されます。

かなり長い間、その設定で実行したと思います。 Trådfriファームウェアの一部がハングするため（ライトの電源を入れ直す必要があるため）、隣接テーブルのポーリングの頻度が減り、状態のポーリングが行われなくなるとともに、変更されました。レポート設定が実際にファームウェアのクラッシュに寄与したとは思えません。

ZCLパケットには、 Disable Default Response送信するかどうかを指示するビットがあります。

Disable Default Responseビットが設定されている場合、デフォルトの応答を送信してもそれほど害はないと思います。ビットが設定されていないときにデフォルトの応答を送信しないと、応答を待機しているデバイスがコーディネーターに到達できなくなり、最終的にネットワークを離れると結論付ける可能性があるため、害があります。

ebaauw 2020年02月29日

ZCLパケットには、 Disable Default Response送信するかどうかを指示するビットがあります。
Disable Default Responseビットが設定されている場合、デフォルトの応答を送信してもそれほど害はないと思います。ビットが設定されていないときにデフォルトの応答を送信しないと、応答を待機しているデバイスがコーディネーターに到達できなくなり、最終的にネットワークを離れると結論付ける可能性があるため、害があります。

@ebaauw 、確かに。それがまさにポイントです。 deCONZは、 Configure Reporting Responseへの応答としてDefault Response送信に失敗します。 IKEAライトがConfigure Reporting Responseに対してDefault Responseを要求していることがあります。
だから、あなたが言うように、それが30分ごとのConfigure Reporting Requestと相まって、IKEAライトが故障する理由かもしれません。

djwlindenaar 2020年02月29日

ただのリマインダー：
Ikea電球（E27およびGU10 v1）は、HUEブリッジに接続したときに到達不能になり、電源を入れ直す必要がある場合があるため、特定の問題はConbee I / IIに固有のものではありません。
私のHUEブリッジの16個のE27と12個のGU10のうち、おおよそ1〜2週間に1個の電球が「ハング」すると思います。時には長く、時には速く。この問題は、過去1年半にわたって最新のHUEファームウェアリリースで改善されました。

olemr 2020年02月29日

@allどのTradfriファームウェアバージョンを使用していますか？

1.xまたは2.xを使用していますか？ 2.xで、彼らはzigbee3.0を導入しました。 2.xにアップグレードすると、問題が発生し始めました。 E14電球。ネットワークの速度と接続性の改善に気づきました。しかし、2つの理由で20個の電球が

バージョンとdeconzの「完璧さ」を2.xで共有していただき、ありがとうございます。

おすすめはありますか？ FW対？接続が失われる問題とIkeaのfw自体の接続の問題に加えて、deconzは1.xをより適切に処理できるようです。

ありがとう！

realwax 2020年03月01日

使ってます：

0x26340500ファームウェアを搭載したConbee1
Deconzバージョン2.05.73（Debianでmarthoc dockerコンテナーを使用）
〜60ノード、主にIKEATrådfri
Conbee 1（コーディネーター）は私の200平方メートルの家の中央に設置されていません。このシステムは、ローミングとメッシュに大きく依存しています。
Conbee 1スティックは、0.5メートルのUSB延長ケーブルに取り付けられ、コンピューターが置かれている棚の側面に取り付けられて、RF信号用の空き容量を増やします。

Conbee 1スティックのアップグレード（リリースと同じ日）以来、ファームウェアdeconzは魅力のように機能しています！これまで何の問題もありません。

tubalainen 2020年03月01日

昨日、本番ネットワーク（RPi 3B +、stretch、RaspBee）を2.05.74と0x26340500にアップグレードしました。以下の問題を除いて、安定しているようです。

関連するかどうかはわかりませんが、私のlumi.curtainカーテンコントローラーへのルートが今朝失われました。コントローラによるレポートは引き続きゲートウェイに到達します。コントローラの電源を入れ直しても、ルートは復元されません。コーディネーターが再びネットワークに到達する前に、ネットワークを開いてコントローラーの電源を入れ直す必要がありました。

また、私のEurotronic Spiritラジエーターバルブの1つは、レポートを送信しているときに、deCONZを開始した後にdeCONZから到達できませんでした。 TRVの電源を入れ直すと、いつものように元に戻りました。

今回は詳細な調査を行う機会がありませんでしたが、どちらのデバイスも当初から問題があり、たまにこれらの症状が見られました。 IKEAFyrturブラインドも同じです。今後も状況を監視し、さらに問題が発生した場合は報告します。

ebaauw 2020年03月01日

@tubalainen
tradfri電球でどのファームウェアを使用していますか？私がテストした限り、これは接続喪失の問題に関してこのスレッドでも違いを生みます。私の結果は、ここで行った手順により、Conbee 1で1.xで動作するtradfri電球の動作が改善されたということです。しかし、tradfri fw2.3.xを使用した20e14のネットワークは混乱しています。タイミング、シーンのスタック、デコンズの取得、ライトの点滅の開始（失われましたか？）、..上記のように。これは、良い経験のために使用するikeafwの明確な推奨事項を提示するために議論および言及されるポイントだと思います。多分すでにgitの記事があります。しかし、私の経験から、アップグレードしないでください😅

だから私の観点とテストとフラッシュの時間から。 ikea fws 1.xの改善に感謝します！ 2.xを操作するときに現在の問題を軽減することは可能ですか？そうしないと、現在ikeaでzigbee3にアップグレードすることはできません。動作が変更されたようで、deconzでの操作を調整する必要があります。これはおそらく@ebaauwが判断または対処するためですか？

乾杯
良い日曜日をお過ごしください😊

realwax 2020年03月01日

@realwax
すべてのエンティティを最新のFWにFWアップグレードしようとしました。これがすべての（現在アクティブな）ノードのリストです。

問題の根本原因を突き止めようとすると同時に、すべての「可動部品」の混乱に同意しました。

tubalainen 2020年03月01日

@tubalainen

あなたのリストをありがとう。

特にルーター（バルブ）を見ると、E14で2.3.007を操作していることがわかります。私の問題リストを再現していただけませんか。 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
2.3.xへの自動fwアップグレードに気付いていなかったので、私のネットワークは1.xと2.xと混ざっていました。手作業で2.3.xにアップグレードしたところ、さらに悪化しました。（ネットワークは高速ですが、使いやすさが大幅に低下し、電球が点滅します）したがって、e14で電球が点滅したり、シーンで「遅延」が発生した場合は、1.2にダウングレードすることをお勧めします...「公式」を取得することに興味があります/これについては、ここでプロの開発者から専門家の声明が出されます。 deconzが1.2と同様に扱われ、改善された時期があったことは間違いありません。これは2.3.xでも行う必要があると思います。そうしないと、Ikeaが自分でそれを台無しにしました。私はコードに深く関わっていないので、言うのは難しいです。

realwax 2020年03月01日

👍1

@realwax
deconzのotau機能とそのファームウェアアップデートスクリプトを使用してfwファイルをダウンロードしています。
E14が更新されない理由がわかりません...フフム。

電球を「手動で」更新/ダウングレードするにはどうすればよいですか？

まあまあ。それはすべて正常に機能し、ルーティングの大部分はfw 2.3.xを備えたE27と、JormenおよびFLOALTパネル主導のドライバーによって行われます。

tubalainen 2020年03月01日

@tubalainen
あなたがその問題を経験していないのは興味深いことです。多分それはメッシュサイズのせいです。 2.3.007のその20e14から23個の電球があります。新しいファームウェアで使い勝手が悪くなったので、自動otauを無効にしました。 GUIを介して、更新ボタンでダウングレードできます。最初に適切なファームウェアを選択し、更新を押して、おそらくもう一度押します。フォームステータスが一時停止すると、->キュー->アイドル->ファームウェアアップデートの開始（パーセンテージ）になります。時々それはハングします。時々それは再起動を必要とします。パワーサイクルで十分な場合もあります。電球をコーディネーターに近づける必要がある場合があります。

realwax 2020年03月01日

動作が変更されたようで、deconzでの操作を調整する必要があります。これはおそらく@ebaauwが判断または対処するためですか？

ここで何を意味するのかわかりません。コントローラ（TrådfriリモートとTrådfriワイヤレス調光器）のZLLファームウェアとZB3ファームウェアのいくつかの違いを処理しました。＃2485を参照してください。これはZigBeeスタックのAPSレベルであり、RESTAPIプラグインによって処理されます。

このトピックのルーティングの問題はNWKレベルであり、デバイスのファームウェアによって処理されます。ここにいる他のみんなと同じように、私はファームウェアソースにアクセスできません。 NWK層とMAC層の詳細がわからないので、たとえそうだとしても、私にできることは何もありません。

ebaauw 2020年03月01日

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
正確に言えば。ここに、20 E142.3.007メッシュの調査結果を含めました。一部の機能がなくなり、シーンのリコールにより、そのグループの10〜15秒間すべてが台無しになります。これがファームウェア関連だけなのか、デコンズ関連なのかわかりません。これは私が対処するための変更で意味したことです。ですから、日常の操作では、2.3.007はダメだと思います。与えられたユーザビリティの例：phosconで構成されたシーンを回転させる単純なスイッチは、慎重に押されないと機能しなくなります。つまり、シーンの回転後に待機します。 1.xでは、2.3.xではすべてが迅速かつ正常に機能しますが、スタックします。

realwax 2020年03月01日

おかげで、 @ manup 、ちょうどそれをインストールしました。それが何をもたらすか見てみましょう。
これによりある程度の改善が見込めると思いますが、記録されたルートを無視するDeConzファームウェアについてどう思いますか（たてがみから1へのルーティングのため）。一般に、記録されたルートは、DeConzファームウェアで使用されるルートよりもはるかに論理的であることがわかりました。
ソースルーティングを有効にすることは大きな仕事だと想像できますが、DeConzファームウェアは、ルートレコードパケットからの情報を使用して、デバイスへの最初のホップを更新できます（すべきですか？）。コーディネーターへのラストホップがルーティングテーブルに格納されているものと一致するかどうかを確認し、一致しない場合は、ルーティングテーブルのエントリを無効にします。途中のデバイスはおそらく情報を無視するため、エントリを記録されたルートの最後のホップに置き換えてもよいかどうかはわかりませんが、少なくともDeConzファームウェアによってそのノードの新しいルート検出を開始できます。
これについてあなたはどう思いますか？
うーん奇妙なことに、ファームウェアはすでにこれらのルートレコードを使用して新しいルートを確立しているはずです。ここでコードを確認する必要がありますが、私のメモリが正しくサービスを提供している場合、これはしばらく前に有効になりました。

@manup 、これを見る時間がありましたか？今朝、コーディネーターから4ホップ離れた場所にあるライト（IKEA）の電源を入れ直した状況を見つけました。どういうわけか、その間のルーター（IKEAも）は、このライトへのルートがわからないと判断しました。私は実際に、ライトが他のライトのルーティング、リンクステータスの報告、deCONZからのNetwork Address Requestへの応答でうまく機能しているのを目にします。この最後の問題は、それらがネットワーク上のブロードキャストメッセージであるためにのみ発生しています。
ただし、その間のルーターは、このライトにルーティングする必要のあるユニキャストフレームをサイレントにドロップしています。もちろん、このルーターはそれらをサイレントにドロップするべきではありません。また、deCONZはこの悪い動作に対して堅牢である必要があります。
その間、ライトはルートレコードメッセージをdeCONZにも送信します。これらのメッセージは到着し、deCONZによって無視されます。

この場合、ルートを再検討するためにdeCONZをトリガーするロジックが必要だと思います。特に、ZCL要求が応答されていないことを検出した場合。最終的には、ライトがゾンビとしてマークされることになります。ゾンビとしてのマーキングに続く発見は、実際にはライトからの返信につながります。ゾンビの発見が開始されると、利用可能なルート情報も無効になる可能性があります。しかし、さらに良いことに、いくつかのZCL要求が応答されないときに、ルートがすでに無効になっている場合（おそらく、それらの最初または2番目にすでに）。

これについてあなたはどう思いますか？

djwlindenaar 2020年03月01日

この新しいファームウェアは私の問題を解決しませんでした。

別のPiとHomeAssistant（NUCで実行）でRaspbeeを使用し、appxを使用しています。 25個のtradfriライト。主に3つのグループで使用されるGU10。

ライトグループ内の単一のライトが応答しなくなり、再び電源を入れ直す必要があるという大きな問題がありました。これは、Ikea FWv1と電球を2.3.007にアップグレードした後の両方で発生しました。

解決策は、構成をHASSでのライトのグループ化から、Phosconでのライトグループの定義、およびHASSでの単一のライトとしてのPhosconグループの参照に変更することでした。この変更後、私は2、3か月間問題なく実行しています。

HASSでグループ化を実行できるようにしたいので、Raspbeeを0x26340500にアップグレードし、Deconzを2.05.74にアップグレードして、構成をHASSでライトグループを使用するように戻しました。これを1週間実行した後、球根が3〜4回古くなり、Phosconグループの使用に再び切り替えています。

aherbjornsen 2020年03月03日

この場合、ルートを再検討するためにdeCONZをトリガーするロジックが必要だと思います。特に、ZCL要求が応答されていないことを検出した場合。最終的には、ライトがゾンビとしてマークされることになります。ゾンビとしてのマーキングに続く発見は、実際にはライトからの返信につながります。ゾンビの発見が開始されると、利用可能なルート情報も無効になる可能性があります。しかし、さらに良いことに、いくつかのZCL要求が応答されないときに、ルートがすでに無効になっている場合（おそらく、それらの最初または2番目にすでに）。

私はまだ新しいファームウェアを使用していて、ルートレコードを含むいくつかのことをテストしています。今週、オンラインで入手したいと思っています。

これについてあなたはどう思いますか？

これは良い点です。APSレベルのACKが受信されない場合、ファームウェアはすでにルートの「品質」を低下させるはずなので、ここでコアとREST-APIプラグインのコードを確認する必要があります。 APS ACKは、ZCL / APS要求でオプションで設定されるフラグであり、ネットワークトラフィックを減らすために無効にされることがよくあります。したがって、大まかな考えは、ユニキャスト要求がタイムアウトにつながることをプラグインが検出した場合は、APSACKを有効にする必要があるということです。

おそらくこれの一部はすでに実施されているので、コードを確認する必要があります。

ただし、その間のルーターは、このライトにルーティングする必要のあるユニキャストフレームをサイレントにドロップしています。もちろん、このルーターはそれらをサイレントにドロップするべきではありません。また、deCONZはこの悪い動作に対して堅牢である必要があります。

新しいルートの検出がトリガーされるとすぐに、ライトは新しいルートをピックアップする必要があります。したがって、目標は、壊れたルートをできるだけ早く検出し（APS ACKでうまくいくことを願っています）、ルートの検出をトリガーする必要があります。

そのためのステートマシンはすでにdeCONZコアに配置されています（これがNWKアドレス要求ブロードキャストにつながるものです）これは、ワンホップリンクの場合、および着信コマンドに基づいてルートをピックアップするライトの場合に機能します（放送）。 MACアドレスが含まれているため、NWKアドレスへの変更も尊重されるため、ブロードキャストは便利です。応答がない場合の次のステップとして、APSACKが有効になっているユニキャストを送信しようとします。

manup 2020年03月03日

残念ながら、昨日はIKEA E27電球（ホワイト1000LM、v1ファームウェア）の電源を入れ直す必要がありました。グループにのみ反応し、ユニキャストコマンドには反応しませんでした。問題はまだ修正されていないようです:(

（はい、私はv74とRaspBeeのベータファームウェアを使用しています）

timbru31 2020年03月04日

上記のコメントを参照してください。次の変更はルーティングの回復に役立つ可能性があります。

manup 2020年03月04日

これについてあなたはどう思いますか？
これは良い点です。APSレベルのACKが受信されない場合、ファームウェアはすでにルートの「品質」を低下させるはずなので、ここでコアとREST-APIプラグインのコードを確認する必要があります。 APS ACKは、ZCL / APS要求でオプションで設定されるフラグであり、ネットワークトラフィックを減らすために無効にされることがよくあります。したがって、大まかな考えは、ユニキャスト要求がタイムアウトにつながることをプラグインが検出した場合は、APSACKを有効にする必要があるということです。
おそらくこれの一部はすでに実施されているので、コードを確認する必要があります。

APS ACK要求ビットが設定されている場合でも、deCONZは不足しているackに対して何も実行しないようです（1回の再試行で何も実行されません...）

ところでhoutlamp 2は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

ただし、その間のルーターは、このライトにルーティングする必要のあるユニキャストフレームをサイレントにドロップしています。もちろん、このルーターはそれらをサイレントにドロップするべきではありません。また、deCONZはこの悪い動作に対して堅牢である必要があります。
新しいルートの検出がトリガーされるとすぐに、ライトは新しいルートをピックアップする必要があります。したがって、目標は、壊れたルートをできるだけ早く検出し（APS ACKでうまくいくことを願っています）、ルートの検出をトリガーする必要があります。
そのためのステートマシンはすでにdeCONZコアに配置されています（これがNWKアドレス要求ブロードキャストにつながるものです）これは、ワンホップリンクの場合、および着信コマンドに基づいてルートをピックアップするライトの場合に機能します（放送）。 MACアドレスが含まれているため、NWKアドレスへの変更も尊重されるため、ブロードキャストは便利です。応答がない場合の次のステップとして、APSACKが有効になっているユニキャストを送信しようとします。

実際、 houtlamp 2は、ブロードキャストaddress requestへの応答を見ることはありません。 deCONZへのメッセージはtuin linksvoor 3を介してルーティングされるため、 houtlamp 2がそのルートを取得したとしても、チャンスはありません。これも、deCONZがroute recordを新しいルートとして選択しないことが原因です。

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]

これで、 Tuin linksvoor 2はnetwork address requestブロードキャストに応答を送信して成功しますが、deCONZからのAPS ACKはhoutlamp 2によってドロップされるため、 Tuin linksvoor 2に到達することはありません。したがって、あきらめる前に数回再送します。それは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

djwlindenaar 2020年03月04日

👍1

Conbee 1+最新のfw + .74は100％再生されていません。
かなりのヒット/ミスがありました。私にとっては.73の方がうまくいくようですが、100％ではありません。

では、製図板に戻りましょう。新しい（ベータ）Conbee 1 fwではまだ100％OKではありません。

tubalainen 2020年03月06日

ファームウェア1.2.221を搭載したTradfirE14のConbee1で.74および26340500を使用して数日間操作した後、次のことが報告されます。

4日間で紛失した電球は1つしかありませんでしたが、IKEAライトはネットワークからの脱落という点でより安定しました。また、E14 fw1.2.221で実行されているdeconzで動作するzigbeeネットワークから地獄を強調するとわかりました。毎秒変更されたbriを使用して単一のリクエストを送信することにより、電球をフェードダウンするスクリプトを実行しました。そのようにして、私は4つの球根を本当にすぐに失いました。しかし、とにかく誰がそれを望んでいます;）

まだ解決されていません：
私がまだ抱えている問題と懸念は、Tradfri FW 2.3.xが適切に実行されていないか、deconzで使用するために適切に実装されていないことです。 tradfri fw 1.2.xにとどまり、zigbee3.0に移行しないのは問題ありません。しかし、それは避けられない時点があるでしょう。または、新しく球根がダウングレードされたのではないかと心配しています。
私は、2〜3個の電球のグループは、4〜8個の電球のグループほど問題が悪いことを示していないことを発見しました。
私はここで私の発見を報告しました、そしてそれが拾われたら私は幸せで感謝しています。ここで意識を高めようとしましたhttps://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
すべての電球を2.3.xにフラッシュするだけでこの問題を再現できるので、あなたもそうできることを願っています。

結論-これは、私たちが話しているどのtradfriファームウェアが使用されているかについて違いをもたらします。使いやすさと経験した問題、およびdeconzの操作には大きな違いがあります。 1.2.x fwsはより古く、既知のドロップアウトのほかに魅力のように機能する可能性が高いですが、2.3.xは、提起された問題で説明されているように使いやすさを失っていません。このFWの違いを経験しているのは私だけだとは想像できません。

@ebaauwが別のスレッドで明らかにしたように、あなたの何人かが趣味の愛好家であることを理解したので、私は今、ドイツ語でドレスデンのelektronikサポートにメールを送りました。開発者のほとんどはドレスデンのelektronik請負業者だと思いました。誤解をお詫びし、貢献していただきありがとうございます。私は今、公式の答えに興味があります。

realwax 2020年03月06日

👍1

Conbee IIファームウェアも修正されましたか？リリースではConbeeIしか見ませんでした。ちなみに頑張ってくれてありがとう。

helto4real 2020年03月07日

👍1

これは、deCONZがルートレコードを新しいルートとして取得しないことが原因です。

@djwlindenaarは、ここで責任があることが

私の記憶が正しければ、当時の問題は、150ノード前後の大規模な混合ネットワークがあり、ルートレコードが正しく機能していないように見えることでした。新しいパスバックが正しく機能していませんでした。ただし、このコードは、NWKステータスコマンドのエラーコードの他の修正で機能した可能性があります。

これを元に戻すので、ルートレコードはルートをより適切なパスに更新する必要があります。

Zigbee仕様のその段落が大好きです：

ZigBeeルーターまたはZigBeeコーディネーターは、ルーティングテーブルを維持できます。 ZigBeeルーティングテーブルエントリに保存される情報を表3-66に示します。使用されなくなったエントリからテーブルスペースを再利用するために、ルーティングテーブルエントリをエージングおよびリタイアすることをお勧めします。ただし、この仕様の範囲外です。

これは基本的に、すべてのスタックがルートエージングを異なる方法で処理することを意味します。

だから私はそれが私たちの場合にどのように機能するかをチェックしました。 Bitcloudでは、Zigbeeスタックルートにはルート「レート」があり、最初は1です。

NWK送信が成功すると、最大値を下回るとレートが増加します。
(1 << 8) - 1 = 255
NWK送信が成功すると、最大255に達すると、すべてのルーティングテーブルエントリが「正規化」されます。
rate = (rate >> 1) + 1 （実質的に2で割って、最低1）
NWK送信が失敗した場合、関連するルートエントリのレートは次のように設定されます。
rate -= (rate / 2) > 0 ? rate / 2 : 1
失敗した送信が多すぎると、レートが0になり、ルートが削除されます

これは、トップリンクが次のように劣化することを意味します。

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

したがって、エントリが削除されて検出が再開されるまで、8つの失敗したコマンドが必要です。
これは通常のネットワークでは特に問題ありません。特に50 .. 100ノードに成長する場合は、ルートを早めに破棄しないでください。

私が懸念しているのは、ポイント（2）です。たとえば、非常に新しいルートや使用されていないルートは、リンクが良好なまったく関係のない高性能ノードによって劣化することがよくあります。たとえば、数秒ごとにポーリングされるPhilipsHueライトはトリガー（2）は、大規模なネットワークのライトの数で乗算することがよくあります。アクティブなOTAアップデートは言うまでもありません。

（2）を変更して、すべてのルートエントリを劣化（正規化）せず、送信の成功に関連する上位255のルートのみを変更するのが安全だと思います。これにより、正常に機能したが頻繁には使用されず、最初に失敗したNWK送信で削除されたルートが失われるのを防ぐことができます。

明日、これらの変更を加えた新しいファームウェアを構築します。ConBeeIIのファームウェアも、おそらく同じことが当てはまります。

manup 2020年03月07日

👍5

これを元に戻すので、ルートレコードはルートをより適切なパスに更新する必要があります。

OK、いいですね。テストを楽しみにしています！

Zigbee仕様のその段落が大好きです：

ええ、この種の指定は、すべてのベンダーをうまく共存させるのに苦労していると思います。：スマイル：

Bitcloudでは、Zigbeeスタックルートにはルート「レート」があり、最初は1です。

ルール2の背後にある論理は実際にはわかりません。それは一種の貧乏人の老化のバージョンのようです。これは、すべてのノードが同じ量のトラフィックを認識している場合は問題なく機能しますが、実際、バランスが取れていない場合（これは非常に一般的だと思います）、問題が発生します。
ZStackがルーティングテーブルのstatusバイトの隣にある実際のexpiryTimeフィールドを使用していることに気付きました。

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

これは実際にどのように機能しますか？
NWKは802.15.4MAC ACKのみをチェックするため、私が間違っていなければ、失敗したNWK送信は実際にはネクストホップのみを意味します。したがって、エンドツーエンドの送信に問題がないかどうかを確認するには、APSackに依存する必要があります。あれは正しいですか？ BitCloudではこのように機能しますか？
また、APSレイヤーのack要求ビットが設定されていない場合、それは成功した送信と見なされ（ackは予期されないため）、そのルートエントリの「レート」をインクリメントしますか？もしそうなら、私たちは常にAPSレイヤーACKを要求しないことによって自分自身を足で撃っているかもしれないからです。

NWKの障害のみに基づいている場合、これは中間ルーターの誤動作の状況を改善することはできず、APSレイヤーACKが到着しないことを考慮に入れるためにロジックを追加する必要があります。おそらく、「ゾンビ」ルーターを検出するために配置されている同様のロジックに基づいていますが、最初にそのルートのルートテーブルエントリを無効にします。

djwlindenaar 2020年03月08日

ConBeeIおよびRaspBeeIのファームウェアバージョン0x26350500をテストできます。

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

0x26340500と同様に、すべてのNWKステータスルートエラーが処理されます
不当なルートの劣化を修正します（https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584のポイント2を参照）
ルートレコードを修正してもルートのネクストホップが更新されませんでした。これは機能するようになりましたが、ルートレコードのときに現在のルートコストが高い場合に限ります。
APSACKが有効になっている失敗したAPS要求を修正しても、ルートが劣化しませんでした

現在、ConBee IIコードを調べて、これらの修正を適用できるかどうか、どこに適用できるかを確認しています。 0x26520700と0x26530700を却下し、これを現在の安定した0x264a0700に基づいています。

ルール2の背後にある論理は実際にはわかりません。それは一種の貧乏人の老化のバージョンのようです。これは、すべてのノードが同じ量のトラフィックを認識している場合は問題なく機能しますが、実際、バランスが取れていない場合（これは非常に一般的だと思います）、問題が発生します。
ZStackがルーティングテーブルのステータスバイトの横にある実際のexpiryTimeフィールドを使用していることに気付きました。

完全に同意します。これは修正されたため、レートが最大に達したときに正常な送信のルートのみが正規化されます。これを処理する期限切れのタイマーの方法は別のオプションかもしれませんが、大規模な独自の落とし穴があります。「レート」方式を使用すると、ネットワークのサイズや時間に依存することなく、かなりうまく機能するはずです。

NWKの障害のみに基づいている場合、これは中間ルーターの誤動作の状況を改善することはできず、APSレイヤーACKが到着しないことを考慮に入れるためにロジックを追加する必要があります。おそらく、「ゾンビ」ルーターを検出するために配置されている同様のロジックに基づいていますが、最初にそのルートのルートテーブルエントリを無効にします。

これは事実であるように思われ、実際、ルート障害を伴うNWKステータスコマンドを送信しない不正な動作のルーターは、デッドルートを存続させる可能性があります。これは0x26350500で修正されましたが、APSACK対応コマンドに依存しています。これは問題なく、deCONzとREST-APIプラグインで制御できます。

manup 2020年03月08日

👍1

ConBeeIおよびRaspBeeIのファームウェアバージョン0x26350500をテストできます。

それをフラッシュし、現在テスト中です。

これは0x26350500で修正されましたが、APSACK対応コマンドに依存しています。

ACKがない場合はどうしますか？ rate値を、失敗したNWK送信の場合と同じか、それ以上/異なる値に半分にしますか？欠落しているAPSACKは、失敗したNWK送信と比較してより深刻であると見なされるべきだと思うからです。そうしないと、ルーターの動作に問題がある場合でも、NWK送信が成功すると、欠落しているAPSACKがルーターを下げるよりもrateが増える可能性があります。

djwlindenaar 2020年03月08日

ACKがない場合はどうしますか？失敗したNWK送信の場合と同じ、またはそれ以上/異なるレート値を半分にしますか？欠落しているAPSACKは、失敗したNWK送信と比較してより深刻であると見なされるべきだと思うからです。そうしないと、ルーターの動作に問題がある場合でも、NWK送信が成功すると、欠落しているAPSACKがレートを下げるよりもレートが上がる可能性があります。

私は同じことを考えました、これがその場合に起こっていることです：

NWK送信ポジティブMACACK rate + 1
APSACKなしrate = rate / 4

したがって、レートはかなり急速に低下し、少し攻撃的すぎる可能性があり、 rate / 2で十分ですが、実際にどのように機能するかを見てみましょう。

manup 2020年03月08日

👍1

いいね。実行して報告します。

現在、ユニキャストメッセージ（OnOffwithLevel）をメッシュ内のかなり離れたライトに数秒ごとに送信することによるストレステストも行っています。

ところで、残りのプラグインコードも変更して、すべてのメッセージでAPSACKを要求しました。

djwlindenaar 2020年03月08日

HomeAssistantを使用してRpi3B +でDeconzを実行しています
現在、ConbeeIおよび26330500で2.05.75を実行しています

今晩、いくつかのライトがオンになっていないことに気づきました。
それらを手動でオンにしようとしました。以下のログを参照してください。
VNCメッシュを確認しました。メッシュネットワークの一部ですが、何にも反応していません。
このノードは、Tradfriのオン/オフコンセントスイッチです。

ここで奇妙なこと：
_個々のスイッチの代わりにDeconzグループを有効にするときにスイッチをオンにすることができます。_

19：23：58：979リクエストの送信を遅らせる57 dt 0 msから0x000D6FFFFEB1C9FF、ep：0x01クラスター：0x0004 onAir：1
19：24：15：744現在のチャネル25
19：24：15：776デバイスTTL 3920のフラグ：0x7
19：24：46：764 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：25：10：547 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：25：15：749現在のチャンネル25
19：25：15：782デバイスTTL 3860のフラグ：0x7
19：25：33：885 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：25：49：411 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：26：12：765 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：26：12：765ノード0x000D6FFFFEB1C9FFの最大送信エラー。最後にネイバーが確認した25秒
19：26：15：742現在のチャネル25
19：26：15：774デバイスTTL 3800のフラグ：0x7
19：26：48：221 0x000D6FFFFEB1C9FFエラーAPSDE-DATA.confirm：0xA7 on task
19：26：48：221ノード0x000D6FFFFEB1C9FFの最大送信エラー。最後にネイバーが60秒見た
19：27：03：845は9ミリ秒でノードの状態を保存しました
29789ミリ秒で19：27：33：634 sync（）

jan-dewit 2020年03月11日

最新の修正は26350500にあります...

djwlindenaar 2020年03月11日

@djwlindenaar私はあなたのテスト結果を待って息を止めています:-)

mvjt 2020年03月11日

ここまでは順調ですね。 deCONZが楽しくルートを切り替えているのが見えます。：スマイル：

djwlindenaar 2020年03月11日

🎉4

最新の修正は26350500にあります...

申し訳ありませんが、FWバージョンを読み間違えました。
公式のHomeAssistant Deconzアドオンを使用してテストを支援したいのですが、これをベータファームウェアに更新する方法がわかりません。（公式アップデートはOTAです）

jan-dewit 2020年03月12日

親愛なる@ manup 、Conbee ii fwアップデートのステータスはありますか？

EGruno 2020年03月13日

👍2

@manup 、 Many-to-One Route Failure (0x0c)に対するアクションがないようです。 deCONZが再びMTORRを実行することを期待します（すでに進行中の場合を除く）。私はこれらのメッセージを定期的に受け取ります。

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

djwlindenaar 2020年03月14日

@manup 、 route recordはまだdeCONZに引き継がれているとは限らないようです。例えば：

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

ライトTuin linksvoor 2はdeCONZに直接送信されますが、 deCONZからのパスはいくつかのホップを経由します...
deCONZからyes / noまでの意思決定プロセスについての洞察を与えて、 route recordメッセージからのルートを受け入れることができれば役に立ちます。

---私の推論に欠陥があったので、以下の項目を編集しました。うまくいけば：wink：---

そうは言っても、 deCONZが使用するルートは、実際にはTuin linksvoor 2への直接通信よりもはるかに信頼性が高くなります。これにより、多対1のルーティングについて疑問に思い、調査することになりました。ラズビーの送信電力は理想的ではないと思います...
これが私の推論です：

多対1のルーティングは、ブロードキャストの受信に基づいています
通常のルート処理とは異なり、着信パスと発信パスのコストの最大値がネクストホップのコストとして使用されます。
これで、ルーターまたはコーディネーターが受信（RX感度が低い）よりも送信（TX電力が高い）の方がはるかに優れている場合、多対1のルーティングがうまく機能しない可能性があります。

私が気付いた関連点は、deCONZがルートテーブルの着信コストについて（非常に）楽観的であるように見えることです。 Tuin linksvoor 2がdeCONZ直接メッセージを送信する場合、常に多くの再試行が必要です。ここで、ルートテーブルを見ると、次のことがわかります。着信コスト4で難しい送信は期待できません。基本的に、ルートテーブルのすべてのアイテムの着信コストは発信コストよりはるかに低いことに注意してください。

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

したがって、deCONZが着信コストについて楽観的でなかった場合は、ルートの動作が改善される可能性があります。または、TX電力を増やしてバランスをとる場合（入出力のコストも同様）
または、deCONZのTX電力を下げる場合は、より多くのホップを介してルーティングする必要があると思います（コスト7のデバイスはルートテーブルから外れます）が、着信メッセージの受信も容易になります。

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

djwlindenaar 2020年03月14日

遅れて申し訳ありません。ステータス：私たちはまだ新しいリリースに懸命に取り組んでおり、私たちが思っていたよりも複雑に見えるファームウェアのバグを追跡しています。 nvram処理の何かがオフになっているようです。また、USB列挙/起動の問題に取り組むことも検討しています。

更新が利用可能になり次第、ここに投稿します。

manup 2020年03月15日

👍7

更新：まだ強くなっています！

ネットワークがこれほど安定しているのを見たことがないと思います。これで、グループの代わりにユニキャストを使用するようにさまざまなルールを変更しました。今から2週間、0個のIKEAライトが消えました。

（私は今それをジンクスしないことを望みます）

すべてのリクエストに対してAPSackをリクエストするようにRESTプラグインを変更したことに注意してください。

djwlindenaar 2020年03月20日

ネットワークも大幅に改善されています。 100％ではありません。時々反応しない電球がありましたが、IKEAの電球を手動で変更すると反応しました。また、電球の状態が物理的な状態と同じになっていることもわかります。
しかし、私のオスラム電球の1つは、以前のikea電球と同じように反応しなくなりました。ポジティブな点は、イケアほど厳しい行動ではないということです。

これが他の人や特定された調査結果によって確認できることを願っています。

PeterRemnemark 2020年03月20日

私はConbee1を実行しており、FW26350500とDeconz2.05.75を使用しています。
これは先週の私の経験です

うまく機能しますが、100％ではありません
IKEAE27TRÅDFRI電球E27WSオパール980lmとfw2.3.007の一部がOFFコマンドに応答しないことがあります
もう一度オフにしようとすると、通常は機能します（電源を入れ直す必要はありません）

tubalainen 2020年03月21日

@djwlindenaarいいね！ REST APIのAPS修正は.75リリースに含まれていますか？それが以前の投稿のいくつかの違いを説明できるかどうか私は知っています...

mvjt 2020年03月21日

いいえ、ちがいます。プルリクエストも作成していません。それであなたはそれを自分で作ることができます。今日か明日やります。
また、ビルドされたREST APIプラグインを共有できますが、ラズベリー3用のプラグインしかありません。

@tubalainen 、それが

おそらく、deCONZの再試行動作に問題があります。そのための実験を行う必要があるか、おそらくそれはすでにスニフログにあります。

嗅ぐことができれば、その現象を嗅ぐことが役立つでしょう。できない場合は分析をお手伝いします。

djwlindenaar 2020年03月21日

昨日、本番ネットワーク（RPi 3B +、stretch、RaspBee）を2.05.74と0x26340500にアップグレードしました。以下の問題を除いて、安定しているようです。
関連するかどうかはわかりませんが、私のlumi.curtainカーテンコントローラーへのルートが今朝失われました。コントローラによるレポートは引き続きゲートウェイに到達します。コントローラの電源を入れ直しても、ルートは復元されません。コーディネーターが再びネットワークに到達する前に、ネットワークを開いてコントローラーの電源を入れ直す必要がありました。
また、私のEurotronic Spiritラジエーターバルブの1つは、レポートを送信しているときに、deCONZを開始した後にdeCONZから到達できませんでした。 TRVの電源を入れ直すと、いつものように元に戻りました。
今回は詳細な調査を行う機会がありませんでしたが、どちらのデバイスも当初から問題があり、たまにこれらの症状が見られました。 IKEAFyrturブラインドも同じです。今後も状況を監視し、さらに問題が発生した場合は報告します。

これらの断続的な問題を客観的に記録することは非常に困難ですが、0x26350500がここで改善をもたらしたという印象を持っています。上記のデバイスを除けば、私のネットワークは非常に安定しています。一部のTRVがゲートウェイから到達不能になっていますが、ほとんど（のみ？）deCONZを再起動した後です。過去3週間、FYRTURもカーテンコントローラーもMIAに移行していないと思います。

すべてのリクエストに対してAPSackをリクエストするようにRESTプラグインを変更したことに注意してください。

GUIの_NetworkSettings_でAPSAcksを有効にしていますが、これがGUIによって送信されたメッセージにのみ適用されるのか、RESTAPIプラグインにも適用されるのかわかりません。

ebaauw 2020年03月21日

上記のプルリクエストで実行したい場合は、私のフォークをチェックアウトしてビルドすることもできます：djwlindenaar / deconz-rest-plugin

djwlindenaar 2020年03月21日

@ebaauw 、私が知る限り、これはGUIから送信されたコマンドにのみ適用されます

スニファが継続的に実行されていますが、問題が発生したときの実時間ではありません。通常、その情報を使用すると、パケットを非常に簡単に見つけることができます...

ところで、私は多くのルール（特に頻繁にトリガーされるルール）をユニキャストに切り替えました。これまでのところ、うまく機能しています。また、私は過去2週間、明るさを継続的に（4秒ごとに）変更する1つのIKEAライトを実行しています。あれもまだ大丈夫です。

djwlindenaar 2020年03月21日

ええと...ログに何かファンキーなものがあることに気づきました。電源を入れ直したライトのどれも、それらの属性を報告していないことがわかりました。私は別のバグに直面していると思っていましたが、そうではありませんでした。とにかく、これをバグと見なしたいと思うかもしれません。

前述したように、数秒ごとにライトのレベルを変更するスクリプトを実行していました。これがIKEAライトの問題を加速させているのではないかと考えています。これにより、 d->idleLastActivityカウンターがリセットされ、アイドルタスクが実行されなくなります。属性レポートの構成を含む：rofl：

djwlindenaar 2020年03月21日

IKEAライトは、電源を入れ直した後、バインディングと属性レポートの構成が失われると言っていますか？！

ebaauw 2020年03月21日

それのように見えます...彼らは..？

djwlindenaar 2020年03月21日

私の問題は、セットアップを.75と50500にアップグレードしてから、Dockerコンテナーが少なくとも週に1回はConbeeを失ってしまうことです。コンテナを再起動すると、事態は再び進行します...非常に迷惑です

mvjt 2020年03月21日

@djwlindenaar 、いや、そうすべきではないと思う。私が見たほとんどのデバイスは、これらの設定を不揮発性メモリに保持しています。 ZigBee標準は、どちらの動作にも余裕があると思います。

ebaauw 2020年03月21日

私のIKEA電球は今ではずっと良く動いていますが、残念ながら、私のXiaomiセンサーの1つ（丸い温度センサー）はしばらくすると応答しなくなります。翌日、スニッフィングして証拠を集めてみます。

timbru31 2020年03月22日

私はConbee1を実行しており、FW26350500とDeconz2.05.75を使用しています。
これは先週の私の経験です
うまく機能しますが、100％ではありません
IKEAE27TRÅDFRI電球E27WSオパール980lmとfw2.3.007の一部がOFFコマンドに応答しないことがあります
もう一度オフにしようとすると、通常は機能します（電源を入れ直す必要はありません）

@tubalainenこんにちは、1.2.xと比較して2.3.xファームウェアでのikeaの動作が異なることに気づきました。私はそれに対処しようとしましたが、注意を引くことができませんでした。球根を1.2.xにダウングレードしましたが、今では魅力のように機能します。 2.3.xで。一定期間、シーンのリカル後にスイッチをオフにすることはできません。通常のオンオフが機能しました。奇妙な振る舞い。ここでテストして貢献したいと思うかもしれません。乾杯https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

realwax 2020年03月22日

👍1

IKEAライトは、電源を入れ直した後、バインディングと属性レポートの構成が失われると言っていますか？！

残念ながら、電源を入れ直した後、バインディングが失われます。コードは、それに対処するために少し前に調整されました。バインディングと構成は、ライトの電源を入れ直した後、しばらくの間レポートが受信されない場合にも復元され、プロセスが開始されて復元されます。

manup 2020年03月22日

👀1

@realwaxは、すべてのE27電球で1.2.xにダウングレードし、報告します。（少し時間がかかります:)）。

昨日、2つのE27ライト（2.3x FW）が朝のシーケンス中にオフになりませんでした。

tubalainen 2020年03月23日

@tubalainenグループコマンドまたはユニキャストコマンドを使用しますか？（つまり、REST APIを介して、/ groups /または/ lights /を介して状態を設定します）

ライトが到達可能である限り、実際にはユニキャストコマンドの方が信頼性が高いと思います。グループブロードキャストコマンドが何らかの理由で見落とされた場合、それは再試行されません。ユニキャストコマンドは、数回または配信されるまで再試行されます。

djwlindenaar 2020年03月23日

@tubalainenグループコマンドまたはユニキャストコマンドを使用しますか？（つまり、REST APIを介して、/ groups /または/ lights /を介して状態を設定します）
ライトが到達可能である限り、実際にはユニキャストコマンドの方が信頼性が高いと思います。グループブロードキャストコマンドが何らかの理由で見落とされた場合、それは再試行されません。ユニキャストコマンドは、数回または配信されるまで再試行されます。

HomeAssistantとREStapiを使用しています。 HomeAssistantが何をするのかわからない...

tubalainen 2020年03月23日

私の場合、それはdeconzプラグインとPhosconを備えたiobrokerです...だからAPIを休ませてください。 igroupを使用すると問題が発生します。グループシーンのリコールは、特にシーンのリコール後最大15秒以内に、グループをオフにしたり、他のグループシーン設定にすばやく変更したり、適切にオフにしたりできないことをトリガーします。 deconzが以前のコマンドでビジー状態であるか、2.3.x fw電球がフリーズしているようです（これは疑わしいです）。理解を深めるために、まだzigbeeレベルでデバッグすることはできません。 deconzのグループ化機能は、ユニキャストコマンドで変換される仮想レイヤーですか、それともgui / zigbeeで利用可能なグループ化オプションを介して実行されますか？結論私は組み込みのグループ関数を使用します。そうしないと、この仮想レイヤーをiobrokerで構築する必要があり、グループ化機能が優れているため理由はありません。それで、それがグループ化である場合... fw 1.2.xでは100％のように見え、2.3.xではそうではないように見えるので、違いは何ですか。何が変わったの？動作が異なるのはzigbee2なのですか。

@tubalainenはい、

しかし、より多くの人がそれを再現できるように指が交差したので、アップグレードする必要がある時点があるので、ikeas fw2.3.xはdeconzで操作可能になります。または電球を交換してください。 zigbee2もいいでしょうが。

頑張ってくれてありがとう！

realwax 2020年03月24日

@realwax @djwlindenaar @manup

昨夜、1つのライトが正常にオフになりませんでした（IKEA E27、fw 2.3.x）。オフにならなかったライトの明るさを変更するためにテストしたところ、選択した明るさの設定に即座に変更されました。明るさを変えた瞬間、ライトは突然オフコマンドにもよく反応しました。

私は個人的にHomeAssistantのすべての自動化を変更して、最初に明るさを変更し、2秒間待ってから、電源を切るコマンドを送信しました。

これまでのところ100％の成功率。

これが調査の手がかりになることを願っています。

編集：消灯に失敗するのは、常に調整（コンビースティック）から最も遠いライトです。（周波数帯域の性質上、メッシュする必要があるライト）

tubalainen 2020年03月25日

👍1

みなさん、こんにちは！

私の問題を売り込みたかっただけです...
ConBee IIスティックで安定性の問題が発生した後、ファームウェアのバージョンを確認しました。それは26530700でした。その後、264a0700にダウングレードしましたが、その後、アプリケーションはスティックを見ることができません。 HomeAssistantとdeCONZを試しました。ホストOSはスティックOKを識別し、GCFFlasherは機能します。

magnusoverli 2020年03月26日

みなさん、こんにちは！
私の問題を売り込みたかっただけです...
ConBee IIスティックで安定性の問題が発生した後、ファームウェアのバージョンを確認しました。それは26530700でした。その後、264a0700にダウングレードしましたが、その後、アプリケーションはスティックを見ることができません。 HomeAssistantとdeCONZを試しました。ホストOSはスティックOKを識別し、GCFFlasherは機能します。

26490700にダウングレードした後、すべてが再び

magnusoverli 2020年03月28日

更新はありますか？家全体をコンビーIIに切り替えたいのですが、今はとても不安定です。私の色合いは完璧に機能します、Conbeeiiはそれほど多くありません🥺

EGruno 2020年04月01日

👍1

RaspBee FW0x26350500を使用した最新のdeCONZ.75での私の経験は、これまでのところ非常に優れています。

私のデバイス：
4xTradfri 980luWSライト-FW2.3.007
17xTradfri 1000luWSライト-FW2.0.023
3xTradfriプラグ-FW2.0.022
3xTradfriラウンドリモコンE1810-FW2.3.014
4xAqaraTHPセンサー

morfei1 2020年04月02日

IKEA電球のファームウェアをクラッシュさせる別のものを見つけました。（そして私はそれがdeConzで修正できると思います）

今朝、1つのライトが反応しないのを見ました。最後の通信を以下に示します。

deConzはグループメンバーシップ応答を受信しているように見えますが、ライトによって送信されたAPS ACK（Get Group Membership Requestを確認）がdeConzによって受信されていません（MAC ACKも表示されません）。その結果、deConzはリクエストを再送信します。このリクエストはZCLで同じ番号を持っているため、ライトファームウェアがクラッシュします。

deConzは、対応する応答が到着するとすぐに要求が確認されたと見なし、別の要求を入れないようにすることができると思います。正しい？リクエストをキャンセルするために呼び出すことができるプラグインのAPIはありますか？ @manup？

この特定のバグは、これらのリクエストに対してAPS ACKをリクエストしないことによっても回避されることに注意してください。これは、現在のRESTAPIプラグインのデフォルトです。

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

djwlindenaar 2020年04月03日

v2.05.75を0x26350500で数週間実行しています。以前のバージョンよりも少し安定しているように見えますが、Eurotronic Spirit TRV、Fyrturブラインド、Xiaomi lumi.curtainカーテンコントローラーへのルートが失われることがあります。後者はルーターです。その他はエンドデバイスです。すべてのTRVのハードウェア/ファームウェアバージョンは同じですが、MIAに移行する頻度が高いものもあります。症状は一貫しています。デバイスはコーディネーターにレポートを送信し続けますが、コーディネーターからのコマンドは未応答の_RouteRequest_になります。

現在、最も頻繁に欠落しているTRVのトラフィックをスニッフィングおよび分析しています。レポートは、途中で2つのHueライトを使用して、3ホップでコーディネーターに到達します。また、TRVから途中の最初のライトまでの_データリクエスト_をキャプチャしたので、TRVはこれがその親であることを喜んでいるようです。 OTAUクラスターのTRVからの一致記述子要求は応答されません。親は_LinkStatus_で次のライトを報告しますが、TRVは報告しません（エンドデバイスであるためですか？）。

_Link Quality Response_メッセージには、20エントリのネイバーテーブルが表示されますが、TRVはその中にありません。 Xiaomiドアセンサー（永久に安定している）はです。奇妙なことに、コーディネーターもそうですが、TRVからコーディネーターへのレポートは別のルーター（これもネイバーテーブルにあります）を介して中継されました。
これで、コーディネーターも_Link Status_に含まれ、TRVからの次のレポートがコーディネーターに直接転送されます。

TRVの電源を入れ直しました。 TRVは、MAC _Data Request_を（以前の）親に送信します。ルータは、TRVの古いNWKアドレスを新しいアドレスとして渡す_RejoinResponse_で応答します。次に、TRVは_Device Announcement_をブロードキャストします（MACは親にユニキャストされます。親はMACブロードキャストとして転送します）。 TRVは_EndDevice TimeoutRequest_を親に送信します。親は_UpdateDevice_をコーディネーターに送信し、TRVが安全に再参加したことを通知します。親は、コーディネーターの_RouteRequest_に_RouteReply_も送信するようになりました。次の_LinkQuality Response_シーケンスには、TRVが含まれています。

TRVが再び行方不明になった瞬間を捉えることができれば、スニファーを実行し続けます。

関連する可能性のある注意事項：私のinnr SP120スマートプラグの1つは、サポートを追加しながら本番ネットワークに簡単に参加したHueボタンの親であるとまだ考えています。それ以来、ボタンは数週間テストネットワークに参加しており、プラグの電源を数回入れ直しました。迷子になった子供を忘れさせるために、プラグを出荷時設定にリセットする必要がありますか？

ebaauw 2020年04月04日

@manup 、コードと何が起こっているかに関する情報の両方が更新されてから長い時間が経ちました。安定性の問題に関するチームの進捗状況と、予想されるタイムラインについても、あえて最新情報を教えてください。

osos 2020年04月05日

👍5

deConzのルーティング動作に別の問題が見つかりました。

この場合、deConzはにルーティングするメッセージをしようとしますHal lampによってTuin linksvoor 3 。しかし、 Tuin linksvoor 3からのLink Statusレポートを見ると、 Hal lampについてはわかりません。そして、どうやらそれはまた、ルーティングを介してそれに到達する方法を知りません。もちろん、そのライト（IKEA）はそれ自体で動作し、失敗メッセージで応答する必要がありますが、そうではなく、変更することはできません。
ただし、deConzは、 Hal lampはゾンビであり、そのライトへの新しいルートを見つけようとはしていません。それが（新しい）ルーティングコードとどのように相互作用するかはわかりませんが、どういうわけか、ゾンビとしてフラグが立てられるのを防ぐのに十分な速さでそのルートを劣化させませんでした。（ところで、実際にはそうではありません。次を参照してください...）

これにより一時的な問題が発生し、数分後に解決しました（もちろん完全に受け入れられません）。 Hal lampは、APS ACKを受信しない属性レポートを送信することを決定したため、 Route Requestプロセスを開始します。これが完了した後、deConzはルートをHal lamp変更し、通常どおり通信を再開します。

ライトがdeConzにメッセージを送信することを決定しなかった場合、どれくらいの時間がかかったのだろうか。（私のネットワークでは、5分ごとにオン/オフおよびレベルクラスターの定期的な属性レポートを使用してIKEAライトを実行していることに注意してください）

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

djwlindenaar 2020年04月11日

🚀1

あなたの説明は私が経験しているように聞こえます。私は最新のfwではるかに優れたネットワーク（conbee 1）を持っています。しかし、それでも応答しない電球を取得し、しばらくすると再び応答します。
Home Assistantが提供する通常のコマンドや設定、および電球の通常のスケジュールを実行しません。ただし、内部の電球は日中（オン/オフまたは明るさ）に変化しますが、外部の電球は1日の樹木時間のみを変更します。応答しない電球がすぐに戻って、コマンドを発行すると応答することがあります。まれですが、発生する場合は、はるかに長い時間がかかるか、電源を入れ直す必要があります。

PeterRemnemark 2020年04月11日

@djwlindenaarまた素晴らしい仕事。どうもありがとうございました！ IKEA FWでのバグ発見をIKEAと共有していますか？

@djwlindenaar ：

もちろん、そのライト（IKEA）はそれ自体で動作し、失敗メッセージで応答する必要がありますが、そうではなく、変更することはできません。

mvjt 2020年04月13日

まあ、私はしていません。 @manupは、IKEAに連絡を取ろうとしたと思うので、これを行う成功率についてコメントできるかもしれませ
また、私は彼らの最新のファームウェアを使用していません。

おそらくシリコンラボに連絡する方が良い考えです。それがIKEAのものの上に構築されているからです。バグがEmberコードに起因するのかIKEAカスタマイズに起因するのかわかりません...

djwlindenaar 2020年04月13日

@djwlindenaar reddit経由でhttps ： //www.reddit.com/user/TRADFRI彼らはそこでかなり活発です。

@manup Conbee IIファームウェアに関するニュースはありますか？

jurriaan 2020年04月13日

ファームウェアを0x264a0700にダウングレードした後、ConbeeIIに接続できなくなりました。 0x264a0700といくつかの本当に古いファームウェアにダウングレードしようとしましたが、フラッシュは正常に機能しますが接続できません。 Conbee IIスティックをリセットする方法についてアドバイスはありますか？

Adminiuga 2020年04月21日

@manup更新はありますか？ deConz以外のものを探す必要がありますか、それとも問題を解決するための作業が進行中ですか？人生のしるしをください🤗

EGruno 2020年04月24日

テストファームウェアを試した後、ConbeeIIを再び動作させたいだけです...

Adminiuga 2020年04月24日

@djwlindenaarあなたの側からの更新はありますか？あなたの修正でまだ安定したネットワークですか？

あなたのPRが@manupによってマージされているのを見て

JBS5 2020年05月04日

👍2

@djwlindenaarあなたの側からの更新はありますか？あなたの修正でまだ安定したネットワークですか？
あなたのPRが@manupによってマージされているのを見て

@ JBS5状況に中程度の満足です。

私のネットワークでは明らかに改善されました。ただし、IKEAライトのバグがdeCONZを混乱させることがあります。

重要な点は、IKEAルーターが特定のルートのパケットをサイレントにドロップすることがあるということです。このサイレントドロップは違法ですが、deCONZは新しいルートを見つけることでそれに反応するはずですが、そうではありません。

deCONZファームウェアへの変更は状況を改善するように見えますが、これらの状況に追加するものがまだあります。確かに、APS ACKがない場合は、すぐに新しいルート検索がトリガーされます。

@manupは、ソースルーティングが問題を解決できると述べていたことに注意してください。これは、リモートノードへのルーティング方法を知っているネットワーク内のルーターに依存しないことを意味するため、この場合は特に当てはまると思います。

IKEAライトのバグは、一部のテーブルがリモートノードへのすべてのルートを保持できないことが原因であると考えています。したがって、ルートがわからないパケットはすべてサイレントにドロップします。

djwlindenaar 2020年05月05日

@djwlindenaarに感謝します。
@manupがここにコメントしたのは少し前のことですが、言及されたソースルーティングが実装されるものであるかどうかの手がかりはありますか？

JBS5 2020年05月07日

これは、ファームウェアで発生する必要のある変更です。私はdeCONZと提携していないので、その可能性についてコメントすることはできません...

@manup ？

それは私に私のホームネットワークのためにdeCONZから離れることを考えさせています...

djwlindenaar 2020年05月07日

👍3

@djwlindenaar 、どのような代替案を検討していますか？私は現在、ConbeeIIの安定性に感心していません。

EGruno 2020年05月07日

これは、ファームウェアで発生する必要のある変更です。私はdeCONZと提携していないので、その可能性についてコメントすることはできません...
@manup ？
それは私に私のホームネットワークのためにdeCONZから離れることを考えさせています...

Zigbee2MQTTはこれをより良くしますか、それとも代替手段でそれを意味しませんでしたか？

lubbertkramer 2020年05月09日

ええ。それでおしまい。

私は実際にそれがより良い仕事をするかどうかわかりません。そこで使用されるファームウェアはチップメーカーによって提供されていることに注意してください。これらのファームウェアはオープンソースではありません。したがって、ファームウェアに問題がある場合は、おそらくdeCONZよりもサポートが少なくなります...
一方、これらのファームウェアの構成はオープンソースです。また、それらはすでにソースルーティングをサポートしています。

djwlindenaar 2020年05月09日

チップメーカーはSDKのみを提供しています。SDKをダウンロードしてSimpleStudioの試用版をダウンロードし、ファームウェアを自分でコンパイルすることができます。 Z2Mは、ファームウェアに加えた変更のパッチを提供します。

Adminiuga 2020年05月09日

こんにちは、ふたりとも、

非常に時間がかかったことをお詫びします。これは、AVRファームウェア0x26350500からすべてのルーティング修正を移植したConBeeIIの新しいファームウェアです。さらに、起動が改善され、デバイスがサイレントになるのを防ぎます。（ブートの問題を完全に修正するために、さまざまなケースをまだテスト中です）。

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

このバージョンは、今後のdeCONZ 2.05.76リリースの一部になる可能性が高く、ConBeeIおよびRaspBeeIバージョン0x26350500ファームウェアは、更新ボタンを介してインストールされるように引き上げられます。

manup 2020年05月10日

👍8

ありがとう、@ manup。このバージョンをテストネットワークにインストールしましたが、動作しているようです。 52や53とは異なり、少なくともデバイスを制御できます。テストネットワークが小さすぎるため、このバージョンでルーティングが改善されるかどうかを確認できません。

ebaauw 2020年05月10日

@manup deCONZは、新しいファームウェアをフラッシュした後でも、ConBeeIIに接続しません。しばらくの間この問題がありました。

Adminiuga 2020年05月10日

@manup何度かフラッシュしようとしましたが、次のエラーが発生し続けます。

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.

jurriaan 2020年05月10日

これはGCFFlasher3.13ですか？

これが私のアップデートからのログです：

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

manup 2020年05月10日

はい、3.13でしたが、システム全体を再起動したので動作します。奇妙なことに、ConBee IIを再接続するだけでは機能しませんでしたが、再起動すると機能します。

jurriaan 2020年05月10日

確かに奇妙なことに、CRCチェックはデバイス上で直接実行されます。これがどのように発生するのか疑問に思っています。

manup 2020年05月10日

@manup古いファームウェア（複数のバージョン）と9600ボーレートをフラッシュしてみました。すべて同じCRCエラーが発生しました。

それが今動作することを嬉しく思います、ありがとう！すぐにネットワークに参加した問題のあるデバイスをすでに1つ見ました。だから私はこのファームウェアがいくつかの問題を修正することを願っています:)

jurriaan 2020年05月10日

それが今動作することをうれしく思います。ブートローダーについて大学と話し合ったところです。バージョン2.05は2019年のConBeeIIの最初のバッチ（約3500個）からのもので、このバージョンは場合によっては少しラフです。 2019年7月以降、ウォッチドッグの処理にいくつかの修正を加えた2.07を出荷しています。

すでにRaspBeeIIの一部である新しいブートローダー3.xが開発中であり、2.xバージョンの問題を修正するためのより堅牢な設計とプロトコルがあります。

現在、ConBeeIIブートローダーをGCFFlasherで更新していません。スタートアップベクターテーブルが変更された瞬間にブートローダーの更新が中止された場合、デバイスをブリックする微妙な可能性があるため、これは展開していません。しかし、ARMハードフォールトハンドラーを使用することでこれを理解できると思います。ブートローダーの更新が失敗し、ハードフォールトハンドラーがトリガーされた場合、ブートローダーが有効かどうかを確認でき、失敗した場合はアプリケーションにジャンプして、ブートローダーの更新を再試行できます。有望に見えるハードフォールトハンドラーを使用していくつかのテストを行いましたが、一般公開の準備が整うまでにはしばらく時間がかかります。

manup 2020年05月11日

👍4

こんにちは

今日は新しいファームウェアでフラッシュしましたが、まだ次のようなログが表示されます。

0x000D6FFFFE540E7CエラーAPSDE-DATA.confirm：タスクの0xA7

これは関係がありますか？

MartinTerp 2020年05月11日

0xA7は、APSACKが本来あるべき場所に提供されていないことを示します。それにはさまざまな理由があると思います。

SwoopX 2020年05月12日

こんにちは@manup 、またお返事をお待ちしております。残りのルーティングの問題についてさらに話し合う時間もありますか？そしてうまくいけばそれらを解決しますか？

djwlindenaar 2020年05月13日

また会ったね、

一部のライトがコマンド（オン/オフ/薄暗い）に反応しないという問題がまだあります。理由がわからないので、この問題と関係があると思いましたが、それが原因かどうかわかりません。

4日前に投稿したようなエラーがまだたくさんあります。

コード数
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
合計76

今日、26台のデバイスがこれらのエラーを投稿していますが、0x26580700で少し悪化しているようです

これがこのルーティングの問題に関連しているかどうか誰かに教えてもらえますか？または私は私の問題で問題を開く必要があります

fxを送信するときにのみ発生したように見えることに注意してください。「同時に」〜20個のライトまで「オン」

MartinTerp 2020年05月15日

こんにちは@manup 、またお返事をお待ちしております。残りのルーティングの問題についてさらに話し合う時間もありますか？そしてうまくいけばそれらを解決しますか？

こんにちは@djwlindenaarはい、絶対にそうです、私は週の間にこの問題のコメントに追いつく必要があります。私の記憶が私に役立つのであれば、残りの問題を改善するためのアイデアはすでにたくさんありました。

manup 2020年05月16日

👍5

こんにちは@djwlindenaarはい、絶対にそうです、私は週の間にこの問題のコメントに追いつく必要があります。私の記憶が私に役立つのであれば、残りの問題を改善するためのアイデアはすでにたくさんありました。

@manup 、確かに、重要な問題は、deCONZが機能しないルートを保持するのにまだ頑固であるということだと思います。
誤動作と影響を受けたライトの両方からのメッセージが（他のルートを介して）着信し続け、ファームウェアによって、機能していないルートがまだ機能しているように誤って解釈されていると思います。また、ACKが受信されない場合、deCONZはAPSレイヤー要求をすぐに放棄する傾向があります。再試行プロセスの一部として、より永続的であるか、ルート検出を開始する必要があると思います。

最後に、ソースルーティングによって、ルーターの誤動作の主な問題が解消されると確信しています。したがって、それを実装できれば、私たちははるかに良い場所にいるでしょう。ヘルプ/テスト/デバッグの準備ができています...

djwlindenaar 2020年05月16日

👍5

こんにちは@manup 、またお返事をお待ちしております。残りのルーティングの問題についてさらに話し合う時間もありますか？そしてうまくいけばそれらを解決しますか？
こんにちは@djwlindenaarはい、絶対にそうです、私は週の間にこの問題のコメントに追いつく必要があります。私の記憶が私に役立つのであれば、残りの問題を改善するためのアイデアはすでにたくさんありました。

こんにちはマナップ、私はこのスレッドをハイジャックしている可能性があるので、そうであれば無視してください。私はHomeAssistantにConbeeiiを持っていて、1か月ほど前まではうまく機能していました。その時点で、私のすべてのXiaomiセンサーは信頼性の低い破壊自動化になります。私は数年前から持っていたいくつかのdresdenfls-ppコントローラーを持っています。これらはLEDストリップに接続されており、ネットワークを散発的にドロップオフして、再起動して再びオンにするために使用されます。私はついにそれらをすべてConbeeネットワークから削除し、すぐにネットワーク全体が安定しました。数日放置した後、数時間機能するものを再導入し、その後一晩でZigbeeネットワークに障害が発生し、ドレスデンコントローラーをオフにするまですべてのスイッチ/センサーをオンラインに戻すことができませんでした。理由はわかりませんが、私にとっては、dresdenコントローラーを使用するとzigbeeネットワークが壊れます。私はこれについての初心者なので、これが役立つ/関連するかどうかはわかりませんが、これに関するコメントを探していて、このスレッドで起こったので、念のために私の経験をミックスに投げ込むと思いました。今のところ、私はそれらをネットワークから削除しているだけです-彼らが私に与えていた頭痛の価値はありません！
乾杯

greybags 2020年05月21日

こんにちは@djwlindenaarはい、絶対にそうです、私は週の間にこの問題のコメントに追いつく必要があります。私の記憶が私に役立つのであれば、残りの問題を改善するためのアイデアはすでにたくさんありました。
@manup 、確かに、重要な問題は、deCONZが機能しないルートを保持するのにまだ頑固であるということだと思います。
誤動作と影響を受けたライトの両方からのメッセージが（他のルートを介して）着信し続け、ファームウェアによって、機能していないルートがまだ機能しているように誤って解釈されていると思います。また、ACKが受信されない場合、deCONZはAPSレイヤー要求をすぐに放棄する傾向があります。再試行プロセスの一部として、より永続的であるか、ルート検出を開始する必要があると思います。
最後に、ソースルーティングによって、ルーターの誤動作の主な問題が解消されると確信しています。したがって、それを実装できれば、私たちははるかに良い場所にいるでしょう。ヘルプ/テスト/デバッグの準備ができています...

ルーティングの問題のため、zigbee2mqttに移行することにしました（最も厄介なのは、Ikea / Xiaomiを時々再ペアリングする必要があることです）。数週間以内に調査結果をここに投稿します...

mvjt 2020年05月21日

先週の月曜日に私のConbeeIでファームウェア0x26350500をフラッシュした後（そしてdeCONZを2.05.76に更新した後）、残念ながらGU10はオフラインになりました。

VNCでは少し灰色です：

フォスコン：

新しいファームウェアバージョンのルーティング修正を利用する前に、すべてのライトをパワーサイクルする必要がありますか？

JBS5 2020年05月27日

@ JBS5 、ファームウェアのアップグレード後にライトの電源を
これはおそらく、改善されたものの、ルーティングの問題が完全に明確になっていないという事実によるものです。私の以前の投稿を参照してください。

djwlindenaar 2020年05月28日

@djwlindenaarありがとう。わかります。

以前のファームウェアと同じ動作であるため、その価値はあります。

GU10が使用不可としてマークされた後も、グループコマンドに応答していました。数日後、2つのバッテリー駆動デバイス（AqaraモーションセンサーとXiaomi / Honeywell煙探知器）もオフラインになりました。 GU10はまだグループコマンドに応答していました。

GU10の電源を入れ直した後、2つのバッテリー駆動デバイスもすぐにオンラインに戻りました。
そのため、GU10がオフラインになった後、ルーターがオフラインになると、特定のGU10を使用するバッテリー駆動のデバイスまで数日かかりました。

JBS5 2020年05月29日

@ JBS5 、はい、それは典型的な振る舞いのように聞こえます。実際、そのGU10ライトには何の問題もありません。 deCONZが直接通信する方法を失っただけです。しばらくすると、エンドデバイスもdeCONZからフィードバックを受け取らないため、エンドデバイスがオフラインになります。最後に、GU10はネットワークパケットが十分に不足すると、実際にはオフラインになります。

おそらく、グループコマンドにまだ応答しているフェーズで、別のルーターの電源を入れ直すことができますが、これは明らかに問題なく、GU10は回復します。他のルーターは実際にはうまく機能しておらず、deCONZは状況にうまく対応していません。
だから、GU10に腹を立てないでください;）

djwlindenaar 2020年05月29日

😄1

こんにちは@djwlindenaarはい、絶対にそうです、私は週の間にこの問題のコメントに追いつく必要があります。私の記憶が私に役立つのであれば、残りの問題を改善するためのアイデアはすでにたくさんありました。
@manup 、確かに、重要な問題は、deCONZが機能しないルートを保持するのにまだ頑固であるということだと思います。

うーん、複数の送信が失敗した後、ルートを劣化させてドロップする必要があります。 APS-DATA.confirmでエラーが報告されるたびに（ルーティングエラーやAPS-ACKが受信されないなど）、最新のファームウェアが劣化します。

誤動作と影響を受けたライトの両方からのメッセージが（他のルートを介して）着信し続け、ファームウェアによって、機能していないルートがまだ機能しているように誤って解釈されていると思います。

それは非常に良いヒントです、私はそれをチェックします。それはなぜルートが死なないのかを説明するでしょう。ルートを評価する唯一の正しい方法は、成功した送信に基づくべきだと思います。

また、ACKが受信されない場合、deCONZはAPSレイヤー要求をすぐに放棄する傾向があります。再試行プロセスの一部として、より永続的であるか、ルート検出を開始する必要があると思います。

deCONZはルート検出を行いません。これはすべてZigbeeスタックによって処理されます。 REST-APIを拡張して、一部のコマンド（制御コマンドなど）を再試行できますが、これは1つです。

スタック自体は、あきらめるまで複数のAPS再試行を行うように構成できます。しかし、これは多くのことを台無しにし、長い間キューをブロックする可能性があります。 REST-APIではよりきめ細かいことを検討するのが最善だと思います。

最後に、ソースルーティングによって、ルーターの誤動作の主な問題が解消されると確信しています。したがって、それを実装できれば、私たちははるかに良い場所にいるでしょう。ヘルプ/テスト/デバッグの準備ができています...

理論的には、ソースルーティングはそれをすべて修正するための聖杯です:)

しかし、現実の世界では、多くのゲートウェイがそれを使用していません（使用していませんか？）。つまり、ほとんどの製品はソースルーティングをサポートしていないか、テストされていません。混合ネットワークで機能させるIMHOの可能性は非常に低いです。しかし、そのレベルでさまざまなゲートウェイを比較してからしばらく経ちました。現在、どのゲートウェイがどのルーティングアプローチを使用しているかについての現在の概要を把握しておくと興味深いでしょう。

manup 2020年05月29日

👍3

現在、どのゲートウェイがどのルーティングアプローチを使用しているかについての現在の概要を把握しておくと興味深いでしょう。

Hueブリッジ（第2世代と第1世代）、innrゲートウェイ、IKEAハブ、OSRAM Lightly Homeゲートウェイのテスト/スニッフィングを喜んでお手伝いしますが、使用するテストセットアップ（ルーター、エンドデバイス、それらの間の距離）についての入力が必要です。、...）そして何を探すべきか。

ebaauw 2020年05月29日

👍2

Z-Stack FWは、ソースルーティングを提供/使用し、大規模なネットワークに推奨するFWの一例です。しかし、弱いCC2351ではうまく機能しないというコメントもいくつか見ました。

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

mvjt 2020年05月30日

また、ACKが受信されない場合、deCONZはAPSレイヤー要求をすぐに放棄する傾向があります。再試行プロセスの一部として、より永続的であるか、ルート検出を開始する必要があると思います。
deCONZはルート検出を行いません。これはすべてZigbeeスタックによって処理されます。 REST-APIを拡張して、一部のコマンド（制御コマンドなど）を再試行できますが、これは1つです。
スタック自体は、あきらめるまで複数のAPS再試行を行うように構成できます。しかし、これは多くのことを台無しにし、長い間キューをブロックする可能性があります。 REST-APIではよりきめ細かいことを検討するのが最善だと思います。

スタックはいくつかの再試行を行います。私が間違っていなければ、3回試行したことを覚えています。そのコードに動作を追加して、関連付けられたルートを無効にし、1回または2回再試行できるように思われます。または、スタック内にコールバックを設定して、その動作を実装することもできます。それはルート発見を引き出すはずですよね？

最後に、ソースルーティングによって、ルーターの誤動作の主な問題が解消されると確信しています。したがって、それを実装できれば、私たちははるかに良い場所にいるでしょう。ヘルプ/テスト/デバッグの準備ができています...
理論的には、ソースルーティングはそれをすべて修正するための聖杯です:)
しかし、現実の世界では、多くのゲートウェイがそれを使用していません（使用していませんか？）。つまり、ほとんどの製品はソースルーティングをサポートしていないか、テストされていません。混合ネットワークで機能させるIMHOの可能性は非常に低いです。しかし、そのレベルでさまざまなゲートウェイを比較してからしばらく経ちました。現在、どのゲートウェイがどのルーティングアプローチを使用しているかについての現在の概要を把握しておくと興味深いでしょう。

正直なところ、私はこの問題についてあまり心配していません。ソースルーティングの場合のルーターの動作は非常に単純です。特に、ルーティング自体を行うために必要な動作と比較すると。基本的に、ルーターのNWKレイヤーが実行する必要があるのは、ソースルーティングが有効になっているかどうかを確認し、パケットからネクストホップを読み取り、MACレイヤーに戻すことだけです。テーブルもメモリも、何も悪いことはありません。基本的な動作がzigbee認定についてチェックされているかどうかはわかりませんが、確かにそれははるかに単純であり、通常のルーティングよりもバグの可能性がはるかに少ないです。

コーディネーターのファームウェアが複雑なため、実装するコーディネーターはほとんどいないと思います。また、このルーティングモードの恩恵を受ける大規模なネットワークに実際に焦点を当てている（消費者向けの）zigbeeの実装はほとんどありません。

最後に、これが混合ネットワークに最適なルーティングモードであると主張します。これは、通常のルーティングはルーターの個々の実装、特に不十分に指定されたリンク品質の表示に依存するためです。ソースルーティングは非常に単純であるため（=不適切な実装の可能性が低い）、通常のルーティング動作の前にそれを信頼します。

だから...これを言って、あなたがファームウェアを提供することができれば私はあなたのためにそれをテストする準備ができています。私はラズビーに乗っています、私のスニファーは行く準備ができています。

djwlindenaar 2020年05月30日

最後に、これが混合ネットワークに最適なルーティングモードであると主張します。これは、通常のルーティングはルーターの個々の実装、特に不十分に指定されたリンク品質の表示に依存するためです。ソースルーティングは非常に単純であるため（=不適切な実装の可能性が低い）、通常のルーティング動作の前にそれを信頼します。

KISS-私には非常に理にかなっています。

ebaauw 2020年05月30日

スタックはいくつかの再試行を行います。私が間違っていなければ、3回試行したことを覚えています。そのコードに動作を追加して、関連付けられたルートを無効にし、1回または2回再試行できるように思われます。または、スタック内にコールバックを設定して、その動作を実装することもできます。それはルート発見を引き出すはずですよね？

すでに発生しているコードを正しく理解している場合、問題は、他の要因（調査中）のためにルートが存続しているように見えることです。

正直なところ、私はこの問題についてあまり心配していません。ソースルーティングの場合のルーターの動作は非常に単純です。特に、ルーティング自体を行うために必要な動作と比較すると。基本的に、ルーターのNWKレイヤーが実行する必要があるのは、ソースルーティングが有効になっているかどうかを確認し、パケットからネクストホップを読み取り、MACレイヤーに戻すことだけです。テーブルもメモリも、何も悪いことはありません。基本的な動作がzigbee認定についてチェックされているかどうかはわかりませんが、確かにそれははるかに単純であり、通常のルーティングよりもバグの可能性がはるかに少ないです。

私は、認証を通じて持ち込んだBitCloudベースの製品（FLSバラスト）についてのみ話すことができます。認証プロセスでは、ソースルーティングのテストは行われませんでした。コンパイル時にスタックで有効になっていたかどうかはわかりません。ほとんどのスタックは、スペースを確保するために必要最小限の機能でコンパイルされるように構成されていることに注意してください。

理論的にはどれほど単純であっても、めったに使用/テストされていない機能に関する私の個人的な経験では、それらには常にバグがあります。たとえば、FLSの場合、サンプルのBitCloudスタックアプリケーションの多数のバグを修正する必要がありました。フィリップスは、一部の製品のBitCloudスタックにも多くの改善を加えたことを知っています。

コーディネーターのファームウェアが複雑なため、実装するコーディネーターはほとんどいないと思います。また、このルーティングモードの恩恵を受ける大規模なネットワークに実際に焦点を当てている（消費者向けの）zigbeeの実装はほとんどありません。

ファームウェアにはネットワークトポロジ全体やフラッシュスペースに関する十分な洞察がないため、複雑さはdeCONZREST-APIプラグインまたは新しいルータープラグインに実装する必要があります。その目的のために、 deCONZ::ApsDataRequestは、ルートのnwkアドレスを保持するstd::vector<quint16>形式のソースルートオプションで拡張できます。

現在メッシュルーティングによって処理されている、これがもたらす複雑さの概要がわかりません。次のタスクは、最小限かつ大規模に検討する必要があります。

ネットワークトポロジの再帰クエリ（Mgmt_Lqi_req）。それは簡単なことです。これはすでにメッシュルーティングで機能し、ソースルートに適合させることができます。
ノードの電源がオフになります。ここで、一部のロジックは代替ルートを選択する必要がありますが、リンクが壊れている場合も機能しない可能性があります。
ノードの電源が再びオンになります。
nwkアドレスを変更するノード。
親を変更するエンドデバイス。
参加しているエンドデバイス。マルチホップネットワークでは、ネットワークにクエリを実行しないと親がわかりません。

まだわからないこと：

すべてのルーターはソースルーティングをサポートしていますか？
ソースルーティングを使用する商用ゲートウェイはありますか？ここでは、トラフィックをスニッフィングし、送信元ルートを保持し、それぞれのフラグが設定されているNWKヘッダーを確認する必要があります。
ソースルーティングをサポートするデバイスの場合、どの程度うまく機能しますか？

manup 2020年05月31日

私は、認証を通じて持ち込んだBitCloudベースの製品（FLSバラスト）についてのみ話すことができます。認証プロセスでは、ソースルーティングのテストは行われませんでした。コンパイル時にスタックで有効になっていたかどうかはわかりません。ほとんどのスタックは、スペースを確保するために必要最小限の機能でコンパイルされるように構成されていることに注意してください。

これがどのように機能するかはよくわかりませんが、スタックも何らかの形で認定されていませんか？

理論的にはどれほど単純であっても、めったに使用/テストされていない機能に関する私の個人的な経験では、それらには常にバグがあります。たとえば、FLSの場合、サンプルのBitCloudスタックアプリケーションの多数のバグを修正する必要がありました。フィリップスは、一部の製品のBitCloudスタックにも多くの改善を加えたことを知っています。
コーディネーターのファームウェアが複雑なため、実装するコーディネーターはほとんどいないと思います。また、このルーティングモードの恩恵を受ける大規模なネットワークに実際に焦点を当てている（消費者向けの）zigbeeの実装はほとんどありません。
ファームウェアにはネットワークトポロジ全体やフラッシュスペースに関する十分な洞察がないため、複雑さはdeCONZREST-APIプラグインまたは新しいルータープラグインに実装する必要があります。その目的のために、 deCONZ::ApsDataRequestは、ルートのnwkアドレスを保持するstd::vector<quint16>形式のソースルートオプションで拡張できます。

私はこの声明を理解していません。ソースルーティングは、スタック内のNWKレベルで完全に処理されます。ビットクラウドスタックには、ソースルーティングを有効にするためのコンパイル時（またはランタイムの可能性は低い）フラグが必要です。コーディネーターによって数分ごとに送信されるMTORRのために、すでにネットワークに存在するルートレコードメッセージに基づいて、スタックによって最新の状態に保たれるソースルートテーブルがあります。

基本的に、ネットワーク内の各デバイスについて、コーディネーターへのルートはMTORRを介して認識されます。
コーディネーターは、ルートレコードメッセージを通じて、各デバイスへの各（完全な）ルートを認識しています。分析は必要ありません。RRメッセージをソースルートテーブルにコピーして貼り付けるだけです。

zigbee仕様の第3.6.3.5.4章および第3.6.3.3章を参照してください。

現在メッシュルーティングによって処理されている、これがもたらす複雑さの概要がわかりません。次のタスクは、最小限かつ大規模に検討する必要があります。
* 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.

これらはすべて、ビットクラウドスタック内のNWKレイヤーによって処理されると思います。いくつかのコンパイル時フラグを調整するのと同じくらい簡単でなければなりません（MTORの動作を有効にするのと同様）

まだわからないこと：
* Do all routers support source routing?

これはNWKレイヤーの基本的なzigbee仕様の一部であるため、そうなると思います。確かではありませんが、ソースルーティングのサポートがオプションであるというコメントは見当たりませんでした。これは、ネットワークですでに使用しているMTORの動作に似ています。

* 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.

これを知らない、またそれが私たちに何を教えてくれるのかわからない？

* For the devices which support source routing, how well does it work?

ソースルーティングを有効にしてファームウェアのビルドを作成できれば、すぐに学習できます。 bitcloudで有効にするには、コンパイル時のフラグをいくつか使用する必要があります。

また、Zigbee2MQTTでは一部のコーディネーターファームウェアで有効になっていますが、ソースルーティングを有効にすると、特定のルーターがうまく機能しないという問題はまだ見つかりませんでした（簡単なグーグルの後）。

djwlindenaar 2020年06月01日

👍3

これがどのように機能するかはよくわかりませんが、スタックも何らかの形で認定されていませんか？

はい。ただし、認定中に特定の構成が有効になり、後で製品で有効にならない場合があります。

私はこの声明を理解していません。ソースルーティングは、スタック内のNWKレベルで完全に処理されます。ビットクラウドスタックには、ソースルーティングを有効にするためのコンパイル時（またはランタイムの可能性は低い）フラグが必要です。コーディネーターによって数分ごとに送信されるMTORRのために、すでにネットワークに存在するルートレコードメッセージに基づいて、スタックによって最新の状態に保たれるソースルートテーブルがあります。

基本的に、ネットワーク内の各デバイスについて、コーディネーターへのルートはMTORRを介して認識されます。
コーディネーターは、ルートレコードメッセージを通じて、各デバイスへの各（完全な）ルートを認識しています。分析は必要ありません。RRメッセージをソースルートテーブルにコピーして貼り付けるだけです。

zigbee仕様の第3.6.3.5.4章および第3.6.3.3章を参照してください。

ああ、そうだね、ばかげた私はどういうわけかそれを一般的なノード発見（facepalm）と誤解した。
スタックは確かに多くのルートレコードコマンドを理解できますが、何も送信されなかった場合はすでに発生しています。以下を参照してください。

今日、私は多くの構成を試しましたが、ソースルーティングはある種機能しているようですが、メッシュルーティングが無効になっていて、以前にルートレコードコマンドを送信したデバイスの場合のみです。

私のPhilipsHueモーションセンサーは問題を起こし、ブロードキャストNWKアドレス要求を送信してゲートウェイNWKアドレスを取得します。この場合、ルートレコードフレームは事前に送信されませんでした（ブロードキャストのためだと思います）。メッシュルーティングが無効になっているため、ゲートウェイはルートディスカバリを開始しなかったため、センサーへの通信は確立されませんでした。

ソースルーティングの次にメッシュルーティングが有効になっている場合、両方が有効になっているにもかかわらず、ソースルーティングは使用されていないようです。

さらにテストを行う必要があります。ルートキャッシュにルートレコードエントリがすでに存在する場合は、メッシュルートの検出を防止する必要があると思います。コードは非常に複雑なので、ここでさらに深く掘り下げる必要があります。

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

これは、メッシュルーティングとソースルーティングの両方が有効になっているファームウェアです（ルートレコードテーブルのサイズは32）。あなたはそれを試すかもしれませんが、私の小さなネットワークで述べたように、ソースルーティングはその構成ではトリガーされませんでした。

manup 2020年06月03日

👍2

私はラズビーIを使用しているので、それをテストすることはできません。そのためにも作成できますか？
起動時にファームウェアにアップロードできる静的ルートのようなもので、または実際に他の情報に基づいて、この問題を回避できるかどうか疑問に思っています。
また、ソースルーティングに変更した後、このデバイスを修復しましたか？エンドデバイスがMTORを認識し、ソースルーティングが使用されているために必要な対話があるかどうか疑問に思います。もちろん、受信機がオフのときは、ブロードキャストMTORメッセージを受信しません。
ところで、Xiaomiエンドデバイスがスニッフィングでルートレコードを送信するのを見ました...

djwlindenaar 2020年06月03日

私は上記のファームウェアを一晩実行するように導きました。ソースルーティングはメッシュルーティングが有効な状態でも使用されているようですが、ごくまれです。約から。 5未満の200万パケットのみがソースルートを使用しました。

私はラズビーIを使用しているので、それをテストすることはできません。そのためにも作成できますか？

可能であれば、ConBeeIとRaspBeeIで使用されている他のスタック構成を確認する必要があります。

起動時にファームウェアにアップロードできる静的ルートのようなもので、または実際に他の情報に基づいて、この問題を回避できるかどうか疑問に思っています。

はい、どういうわけかルートキャッシュにルートを挿入できるはずだと思います。しかし、ルートを維持するために上記の私の懸念に戻ったとき。とにかく、テスト目的と固定ネットワークのために、ルーティングを構成するための便利な方法を提供します。

また、ソースルーティングに変更した後、このデバイスを修復しましたか？エンドデバイスがMTORを認識し、ソースルーティングが使用されているために必要な対話があるかどうか疑問に思います。

いいえ、ファームウェアを更新したばかりで、修復はありません。ルートレコードコマンドを受信した直後にソースルートが確立されました。

ところで、Xiaomiエンドデバイスがスニッフィングでルートレコードを送信するのを見ました...

IKEAもここに収まるようです。フィリップスや他のブランドのデバイスでさらにテストを行い、さまざまなデバイスをソースルーティングでどのように使用できるかを詳しく調べたいと思います。

manup 2020年06月04日

👍1

Raspbeeで機能させることができれば、テストのためにチャイムを鳴らすこともできます。

SwoopX 2020年06月04日

私は上記のファームウェアを一晩実行するように導きました。ソースルーティングはメッシュルーティングが有効な状態でも使用されているようですが、ごくまれです。約から。 5未満の200万パケットのみがソースルートを使用しました。

面白い！ソースルートが使用されるときの意思決定ロジックと、それが何らかの形で影響を受けたり調整されたりする可能性があるかどうかについての洞察を得るのは素晴らしいことです。

私はラズビーIを使用しているので、それをテストすることはできません。そのためにも作成できますか？
可能であれば、ConBeeIとRaspBeeIで使用されている他のスタック構成を確認する必要があります。

素晴らしいことだ...

起動時にファームウェアにアップロードできる静的ルートのようなもので、または実際に他の情報に基づいて、この問題を回避できるかどうか疑問に思っています。
はい、どういうわけかルートキャッシュにルートを挿入できるはずだと思います。しかし、ルートを維持するために上記の私の懸念に戻ったとき。とにかく、テスト目的と固定ネットワークのために、ルーティングを構成するための便利な方法を提供します。

同意しました

また、ソースルーティングに変更した後、このデバイスを修復しましたか？エンドデバイスがMTORを認識し、ソースルーティングが使用されているために必要な対話があるかどうか疑問に思います。
いいえ、ファームウェアを更新したばかりで、修復はありません。ルートレコードコマンドを受信した直後にソースルートが確立されました。

フィリップスのデバイスに役立つかどうか疑問に思っています...

djwlindenaar 2020年06月04日

こんにちはみんな、私は24時間Z2Mソースルーティングファームウェアを実行しています（5つの直接接続のみを許可します）。私は約35台のデバイスを持っています。正常に動作しますが、デフォルトのFWからSRファームウェアに移行した後、Hueデバイスを再接続するには電源を入れ直す必要があることに気付きました。 IkeaとXiaomiは自動的に再接続されました。多分これはあなたが見ている色相の振る舞いの一部を説明することができますか？

mvjt 2020年06月06日

こんにちは、
TRADFRI電球E14WSオパール400lmをikeaファームウェア2.3.050と、ConbeeIの最新のdeconzベータ版と最新ファームウェアで再テストしました。電球と通信が改善されたことを確認できます。シーンのリコール、オン/オフの切り替え、フェードインとフェードアウトがうまく機能するようになりましたが、問題が残っています。

ここに記載されている問題＃2518はほとんど解決されています。（phoscon guiからの）グループコマンドはさらにうまく機能するようです。＃2518閉店

シーンではなく手動で変更した場合、成功するためにCTの変更を複数回トリガーする必要がある場合があることにまだ気づきました。

表示される新しい問題＃2892は、グループ内でシーンがリコールされ、所属するすべての電球がオンになっている場合（シーンのため）、後でそのグループ内の別のシーンで、いくつかの電球のみがオンになっている場合（シーンによって定義）が思い出されます、オフにすべき「不要な」電球はオンのままです。
さらに、グループをオフにすると、現在定義されているシーンの球根だけがオフになり、前のシーン（グループの前のシーン）はオンのままになります。オフにする前に、いくつかのオフコマンドが必要です。
この問題はここで説明されていますが、PhosconまたはAPI自体を使用しても違いがないため、APIに含まれています。 https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

追記：2020年2月5日に最新のikea fw2.3.050リリースを使用

リリースバージョン：1.12.1
2020年5月20日
アクセサリの新機能と変更点：
WS 1.0（E14、E27、GU10）V-2.3.050。
OTAアップグレード後のオンオフ状態を修正しました。

あなたの継続的な改善と費やされた仕事に感謝します。

realwax 2020年06月06日

@ manup 、conbee Iのソースルートファームウェアバージョンに関するニュースはありますか？私はそれをテストするのを楽しみにしています:)

djwlindenaar 2020年06月13日

@ manup 、conbee Iのソースルートファームウェアバージョンに関するニュースはありますか？私はそれをテストするのを楽しみにしています:)

それを有効にしようとした私の最初の試みは、ひどいコンパイル時エラーの混乱で終わりました：/原因がまだわかっていないので、なんとかしてコンパイルできるようにしたいと思っています。

manup 2020年06月19日

@ manup 、conbee Iのソースルートファームウェアバージョンに関するニュースはありますか？私はそれをテストするのを楽しみにしています:)
それを有効にしようとした私の最初の試みは、ひどいコンパイル時エラーの混乱で終わりました：/原因がまだわかっていないので、なんとかしてコンパイルできるようにしたいと思っています。

うーん、いい音ではありません...

djwlindenaar 2020年06月21日

@manup 、何か進展はありますか？

djwlindenaar 2020年07月03日

@ manup 、pssst！ 😁

djwlindenaar 2020年07月08日

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。それ以上のアクティビティが発生しない場合は閉じられます。貢献していただきありがとうございます。

stale[bot] 2020年07月29日

まだ起こっています。 @manupこの問題に関する進捗状況や更新はありますか？

JBS5 2020年07月29日

@djwlindenaar @ JBS5私は更新のために@manup求めてきました。

Mimiix 2020年08月03日

👍1

はい、まだ問題です-以前よりはるかに少ないですが。

tubalainen 2020年08月03日

👀1

この問題の最新情報は何ですか？

Hueブリッジに接続された約20個のホワイトスペクトルGU10（第1世代）があり、zigbeeネットワークの合理化の一環として、すべてのデバイスをDeconzに移行したいと考えていました。

色相は非常に安定していますが、ライトは時々オフラインになります（たとえば、週に1回、1つのライトがオフラインになります）。球根を蘇生させるには、球根を再起動する必要があります。

デコンズは多かれ少なかれ安定していますか？

ReX1983 2020年08月14日

デコンズは安定していません。私は約40個のIkeaランプも持っており、時にはオフラインになることもあります。

salopette 2020年08月14日

❤1

@salopette私はその経験がありません。別の問題を開いていただけませんか。ログはありますか？

Mimiix 2020年08月14日

@Mimiixこの問題は、オフラインになるライトに関するものです。なぜ新しい号を開くのですか？

JBS5 2020年08月14日

こっちも一緒。ライトはまだ時々オフラインになります。しかし、それは時間とともに大幅に改善されました。 2018年にdeCONZを使い始めたとき、私はikeaライトの電源をほぼ毎日入れ直さなければなりませんでした。私はほとんどの場合、FLOALTパネルでこの問題を経験しますが、これは私のConbeeStickから最も遠い光でもあります。

peer69 2020年08月14日

@ JBS5このユーザーの設定については何も知らないため。バージョン、ログ、セットアップに関する情報はありません。彼の問題がこれに関連しているかどうかを判断する立場にはありません。

情報なしでコメントを追加しても、ケースではこれを助けません。だから私は別の問題が欲しいので、より良い概要があります。

私はかつて@manupにプライベートでこれを調べて優先順位を付けるように依頼しています。

Mimiix 2020年08月14日

@djwlindenaarはそれを深く掘り下げてきました。他のユーザーのセットアップを調べることで、ikeaライトに一般的に存在すると思われる問題について何もできないと思います。別の調査を開始するよりも、既存の調査に集中したいと思います。

peer69 2020年08月14日

👍2

一般的な発表：

これについては、 @ manupと非公開で話しました。彼は私に次のように言った：

「ファームウェアがルーティングの問題に関して更新を取得し、新しいネットワークが問題の再現に役立つことを願っています（以前は不可能でした）。
私の計画では、この次のファームウェアは今後2〜3週間以内に利用可能になる予定です。

一部の変更はすでに行われていますが、まだ公開されていません。
`` `

私はあなた全員を投稿し続けます。

Mimiix 2020年08月14日

👍5

一般的な発表：
これについては、 @ manupと非公開で話しました。彼は私に次のように言った：
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.
私はあなた全員を投稿し続けます。

3週間後、これに関する更新はありますか？

JBS5 2020年09月04日

👍3 😄2

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）

今朝も@manupをPmed 。次の応答があります。

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.

私はETAを要求しました、そして彼は現在それに取り組んでいます。

Mimiix 2020年09月04日

🎉1

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。

さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて

では、ETAとは2〜3週間経ちました。

lubbertkramer 2020年09月04日

👍2 👎1

@lubbertkramerここで合理的にしてください、古いボットは冗談でした。 @Mimiixが以前に行った唯一の約束は、更新が利用可能になったら共有することです。したがって、現在のステータスについて質問することは完全に有効です。現在、ETAについては、何も約束されていません。これは複雑なものであるため、約束されていないことを理解しています。厄介なことについて話すときのマヌプを知っているように、残念ながら、それは1日以内に整理できるものではなく、かなりの時間が経過した後にのみ表示されるか、予期しない副作用が発生します。

ですから、そういう意味では、辛抱強く、みんなに取り組んでもらいましょう（ちなみにまだ休暇中です）。次のリリースについて言えば、手を挙げてニュースを求めるのに1.5週間かかります。

SwoopX 2020年09月04日

👍1

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。

再起動の問題は、私が推測するこの問題とは関係ありませんか？
ルーティングの変更と前述のデバッグの機能強化についてはどうですか？これらのデバッグ拡張機能はこの問題に関連していますか？

そして、これらのルーティングの変更は@djwlindenaarの調査結果に基づいていますか、それとも@manupはすでにもう少し具体的にすることができますか？

JBS5 2020年09月04日

👍1

@lubbertkramerここで合理的にしてください、古いボットは冗談でした。 @Mimiixが以前に行った唯一の約束は、更新が利用可能になったら共有することです。したがって、現在のステータスについて質問することは完全に有効です。現在、ETAについては、何も約束されていません。これは複雑なものであるため、約束されていないことを理解しています。厄介なことについて話すときのマヌプを知っているように、残念ながら、それは1日以内に整理できるものではなく、かなりの時間が経過した後にのみ表示されるか、予期しない副作用が発生します。
ですから、そういう意味では、辛抱強く、みんなに取り組んでもらいましょう（ちなみにまだ休暇中です）。次のリリースについて言えば、手を挙げてニュースを求めるのに1.5週間かかります。

フォローアップなしで2〜3週間が3週間経過したときに、「冗談」を言わずに、人々にコミュニケーションや約束を通過させるのが合理的だと思います。よく調べてここに返信したユーザーは、フォローアップやコミュニケーションが不足しているため、すでに先に進んでいます。

では、この問題に戻って、この問題に関する最新情報は何ですか？

lubbertkramer 2020年09月04日

👍2 👎1

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。

あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。

ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。

_この世界で見たい変化になりましょう_

Mimiix 2020年09月05日

❤1 👎1

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_

誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。

一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？

lubbertkramer 2020年09月05日

👎1 👍1

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？

私が持っていたのは私が言ったことだけでした。感情をコントロールするようにアドバイスさせてください。私はあなたの怒りを理解していますが、無礼であることは助けにはなりません。私はここで炎上を受け入れません。トピックと市民にそれを保ちます。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。

あなたが不平を言うために問題を始めたいならば、私のゲストになってください。この号ではそれをしないでください。

Mimiix 2020年09月06日

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？
私が持っていたのは私が言ったことだけでした。感情をコントロールするようにアドバイスさせてください。私はあなたの怒りを理解していますが、無礼であることは助けにはなりません。私はここで炎上を受け入れません。トピックと市民にそれを保ちます。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。
あなたが不平を言うために問題を始めたいならば、私のゲストになってください。この号ではそれをしないでください。

この問題の唯一の恥ずかしさはmanupであり、ドレスデンは明らかにこの問題を修正することができません。 Conbeeは商用製品であり、それには責任が伴います。そのため、私たちの多くはすでにdeCONZ / ConbeeをTIチップとZ2Mに残しており、それ以来問題なく動作しています。

mvjt 2020年09月06日

👍3

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？
私が持っていたのは私が言ったことだけでした。感情をコントロールするようにアドバイスさせてください。私はあなたの怒りを理解していますが、無礼であることは助けにはなりません。私はここで炎上を受け入れません。トピックと市民にそれを保ちます。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。
あなたが不平を言うために問題を始めたいならば、私のゲストになってください。この号ではそれをしないでください。

繰り返しになりますが、あなたは何度も尋ねられるステータスに答えたり更新したりするのではなく、あなたがしている唯一のことは、すべての投稿の終わりに尋ねられたようにすでに更新を与えることができたオフトピックの議論に進むことです。あなたは開発会議での直接の接続/招待について自慢しているので、この問題の状況について最新の情報を入手し、ここですべての読書ユーザーを更新することができます。

ですから、もう一度更新を投稿するか、オフトピックの投稿をやめてください。オフトピックのディスカッションを存続させるのではなく、コミュニティモデレーターとしてのあなたの仕事だと思います:)

一般的な発表：
これについては、 @ manupと非公開で話しました。彼は私に次のように言った：
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.
私はあなた全員を投稿し続けます。

一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップとは何ですか、ユーザーは何を期待できますか？

lubbertkramer 2020年09月06日

新しい頼りになる人が1週間も経たないうちにやってくる。落ち着いておくことをお勧めします
新しい変更が何をもたらすかを確認するのを待ちます

私は1年以上問題なくたくさんのtradfriの仕事をしています。
最近、Tradfriライトの1つだけで問題が発生し始めました
約15分ごとにメッシュのドロップと接続を開始しました。 15分
到達可能、15分到達不能。問題を見つけるために多くのテストを行いました。
何だと思いますか....問題は何でしたか？それはdeCONZからではなく私のWiFiからでした
リピーターは憤慨してそれに置くスケジュールを立てます。

問題が常にdeCONZに関連していることを確信してはいけませんが、そうでない場合もあります。

日、2020年9月6日には、午前11時38 lubbertkramer [email protected]は書きました：

@ JBS5https ：//github.com/JBS5まだ3週間ではありません。古いボットを待っていました
ここに ;）
Pmed @manuphttps ：//github.com/manup今朝も。手に入れました
次の応答：
再起動の問題を調査するためにここ数日ファームウェアをクロールしていて、いくつかの厄介なバグを見つけました。
また、いくつかのルーティングの変更が含まれる予定です。次のリリースでリリースされることを期待しています。
デバッグの機能強化は、次の安定版リリースの後に続きます。
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたを抱きしめます
その約束に、21日/ 7日= 3週間
この問題がすでに発生しているときに、stalebotの後ろに隠れることは不十分です
2019年2月から活動中。ドレスデンのスポークスパーソンになりたいとき
そのように振る舞うか、 @ manuphttps ：//github.com/manupにこれを処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。
私は決してスポークスマンではありません、私は物事を得るためにここで首を突き出しています
直接接続しているのでソートしました。私が追跡するために使用する古いボット
問題が発生し、通知を受け取ります。マヌプが戻ってくると思います
時間枠が経過した場合、古いボットは私に思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。あなたが私がしたことをしたなら
コミュニティ、あなたはそれよりもよく知っているでしょう。また、それを追加すると、それはそうではありません
私は人生で他にやることはありませんでした。
この世界で見たい変化になりましょう
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度
燃え上がって花の力を変える代わりに、この問題を次のように残します
スポークスパーソンまたは問題と最新の情報に戻ります。
によって一般的な発表として投稿した2〜3週間が経過しました
3週間以上経ちましたが、フォローアップはどうなっていますか？
私が持っていたのは私が言ったことだけでした。私はあなたにあなたを保つようにアドバイスさせてください
制御下の感情。私はあなたの怒りを理解していますが、無礼です
助けていません。私はここで炎上を受け入れません。トピックにそれを保ち、
市民。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。
あなたが不平を言うために問題を始めたいならば、私のゲストになってください。しないでください
この号でそれを行います。
そして繰り返しますが、あなたは尋ねられたステータスに答えたり更新したりしていません
何度も、あなたがしている唯一のことは、オフトピックで進むことです
最後に尋ねられたようにあなたがすでに更新を与えることができたかもしれない議論
すべての投稿の。あなたは直接の接続/招待について自慢しています
開発会議なので、次の状況について把握する必要があります。
この問題は、ここですべての読書ユーザーを更新する可能性があります。
だからもう一度更新を投稿するか、オフトピックの投稿をやめてください:)
—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
。

morfei1 2020年09月06日

@ morfei1と@Mimiix次のリリースは、リリースがDEによってどのように機能しているかを確認している場合、約2週間以内にリリースされることを願っています（「15日」=支払いを受ける前に少し）。そして、休日の有無にかかわらず、1つの修正が含まれているのかどうかはわかりません。
そして、一部の人は（そして私は何度も）公式サポートがどのように機能しているか、そして顧客が大きな問題を抱えていると言っています。
オフレコ：ZHAは1〜2週間でSilabs EZSPのすべてのバージョンのスタックプロトコルの公式サポートを開始するため、1つのSonoff ZigbeeBridgeまたはElelabs-ELU013 / ELR023の方が、資金を投入してRFおよびSoCパワーを増やす方が良いと思います。 DE製品とコミュニティからのより良いサポート。
しかし、すべてのDE製品をRIPさせる前に、deCONZREST-APIバージョン2を待っています。

MattWestb 2020年09月06日

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？
私が持っていたのは私が言ったことだけでした。感情をコントロールするようにアドバイスさせてください。私はあなたの怒りを理解していますが、無礼であることは助けにはなりません。私はここで炎上を受け入れません。トピックと市民にそれを保ちます。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。
あなたが不平を言うために問題を始めたいならば、私のゲストになってください。この号ではそれをしないでください。
繰り返しになりますが、あなたは何度も尋ねられるステータスに答えたり更新したりするのではなく、あなたがしている唯一のことは、すべての投稿の終わりに尋ねられたようにすでに更新を与えることができたオフトピックの議論に進むことです。あなたは開発会議での直接の接続/招待について自慢しているので、この問題の状況について最新の情報を入手し、ここですべての読書ユーザーを更新することができます。
ですから、もう一度更新を投稿するか、オフトピックの投稿をやめてください。オフトピックのディスカッションを存続させるのではなく、コミュニティモデレーターとしてのあなたの仕事だと思います:)
一般的な発表：
これについては、 @ manupと非公開で話しました。彼は私に次のように言った：
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.
私はあなた全員を投稿し続けます。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップとは何ですか、ユーザーは何を期待できますか？

あなたの質問に直接答えるために：私がもう一度彼に尋ねた後、 @ manupが私に言ったことです。誰かに何かを強制することはできません。週末が終わったらまた聞いてみます。

これはあなたのコメントに対する一般的な最後の警告になります。 ここでの次のトピック外のコメントは、ニュースが増えるまでこの問題をロックすることです。

Mimiix 2020年09月06日

❤5

@ JBS5まだ3週間ではありません。ここで古いボットを待っていました;）
今朝も@manupをPmed 。次の応答があります。
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.
私はETAを要求しました、そして彼は現在それに取り組んでいます。
さて、あなたはコミュニティに対して約束をしたので、彼らはあなたをその約束に拘束します、21日/ 7日= 3週間
この問題が2019年2月以降すでにアクティブになっている場合、stalebotの背後に隠れることはできません。ドレスデンのスポークスパーソンになりたい場合は、そのように行動するか、 @ manupに処理させて
では、ETAとは2〜3週間経ちました。
あなたがこのように振る舞うとき、私はこの問題を私に残しても問題ありません。私は決してスポークスマンではありません。私は直接のつながりがあるので、物事を整理するためにここで首を突き出しています。問題を追跡するために使用している古いボットで、通知を受け取ります。 manupが戻ってくることを期待しています。時間枠が経過すると、古いボットが思い出させるのに役立ちます。
ですから、その背後に隠れることは「ラメ」ではありません。私がコミュニティのためにしたことをやったら、それよりもよく知っているでしょう。また、それを付け加えると、私が人生で他にやることがなかったというわけではありません。
_この世界で見たい変化になりましょう_
誰もあなたにユーザーとしての仲介者になることを求めたり強制したりしていないので、もう一度炎上して花の力を変える代わりに、この問題をスポークスパーソンのままにするか、問題と最新の情報に戻ってください。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップはどうですか？
私が持っていたのは私が言ったことだけでした。感情をコントロールするようにアドバイスさせてください。私はあなたの怒りを理解していますが、無礼であることは助けにはなりません。私はここで炎上を受け入れません。トピックと市民にそれを保ちます。私は自分の主張が何であるか、そしてなぜ私が自分のやり方で物事を行うのかを説明するだけです。
あなたが不平を言うために問題を始めたいならば、私のゲストになってください。この号ではそれをしないでください。
繰り返しになりますが、あなたは何度も尋ねられるステータスに答えたり更新したりするのではなく、あなたがしている唯一のことは、すべての投稿の終わりに尋ねられたようにすでに更新を与えることができたオフトピックの議論に進むことです。あなたは開発会議での直接の接続/招待について自慢しているので、この問題の状況について最新の情報を入手し、ここですべての読書ユーザーを更新することができます。
ですから、もう一度更新を投稿するか、オフトピックの投稿をやめてください。オフトピックのディスカッションを存続させるのではなく、コミュニティモデレーターとしてのあなたの仕事だと思います:)
一般的な発表：
これについては、 @ manupと非公開で話しました。彼は私に次のように言った：
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.
私はあなた全員を投稿し続けます。
一般発表として投稿した2〜3週間が3週間以上経ちましたが、フォローアップとは何ですか、ユーザーは何を期待できますか？
あなたの質問に直接答えるために：私がもう一度彼に尋ねた後、 @ manupが私に言ったことです。誰かに何かを強制することはできません。週末が終わったらまた聞いてみます。
これはあなたのコメントに対する一般的な最後の警告になります。 ここでの次のトピック外のコメントは、ニュースが増えるまでこの問題をロックすることです。

それはちょっとした答えです。正しく読んだら、今週後半にさらに詳細な回答が期待できます。これは、 @ manupが更新の一般的な発表としてあなたを通じて

@Mimiix解決策のない非常に協力的で献身的なユーザーからの多くの情報で、ほぼ2年間開かれているこの問題を解決したいという衝動を

lubbertkramer 2020年09月06日

👍1

@lubbertkramer私はロックと言った、閉じない。

そしてそれで、私はこの問題をロックします。 数日後、またはマヌエルがここに返信したときにロックを解除します。

Mimiix 2020年09月06日

こんにちは、この問題の更新の時間以上だと思います。

しかし、まず最初に、誰かがここで責任を負うのであれば、それは私であり、私だけです。私は欲求不満を理解していますが、@ Mimiixに対してここで礼儀正しくない余地はありません。したがって、彼がいなくて、彼がこのコミュニティのために達成したすべてのことを成し遂げたのでなければ、私は物事を成し遂げる時間がなかったでしょう。 deCONZコアとファームウェアで、バグ修正と改善に取り組んでいます。以前は簡単でしたが、このすべてが狂ったようにスケーリングされたため、todoリスト、サポートコール、および電子メールも狂ったように成長し、再起動ループのバグが私の個人的な地獄でした。モデレーターとすべての素晴らしい開発者と貢献者のおかげで、物事は今ではずっと良く見え、一度に1つずつより深い問題に取り組んでいます。

進捗状況の更新

（次のリリースのプレビュー）

私はソースルーティングで多くのテストを行っており、この問題の調査結果とさまざまなスニファログを試しました。着信ルートレコードコマンドに基づいて、「自動」ソースルーティングを確実に機能させるために多くの時間を費やしてください。これは基本的に、ソースルーティングを使用したほとんどの実装が行うことです— zigbee2mqttのソースルーティングファームウェアのように。それは時々機能しますが、ルートレコードホップがネイバーから見るLQI / RSSI値に基づいてソースルートが選択（および保持）される方法/かどうかについては、より大きなダイナミクスがあるようです。混合ネットワークでは、これは注意が必要です。スタックとハードウェアの違いのため。人々がノード間を移動し、ドアが開閉された場合、リンク品質も非常に動的になる可能性があります。これは、残念ながらルーティングにも影響します。

したがって、宛先ノードに向けて固定ソースルートを構成するというアイデアを実験しました。多くの場合、ネットワークの一部にのみルーティングの問題があります。ここでは、次の場合に固定ソースルートを指定すると便利です。

ソースルートは、オプションでノードごとに指定できます。
すべてのホップは常に電力が供給されている必要があります。
パスを通るホップ位置は妥当なはずです。場合によっては、ユーザーは、自動アルゴリズムが把握できるものよりも、パケットをルーティングする場所についてより適切な計画を立てている可能性があります。

これを行うために、ファームウェアプロトコルが拡張され、オプションでAPS要求ごとにソースルートを提供するようになりました。構成できるソースルートの数に制限はありません。ファームウェアは、要求とACKのためにいくつかをメモリに保持するだけで済みます。

deCONZは、ルート上の各ホップが到達可能かどうかを自動的に判断し、その場合にのみソースルートを使用します。
舞台裏では、ソースルートはノードのMACアドレスで構成されており、NWKアドレスの変更に耐えることができます。

固定ソースルートの作成

deCONZ guiで、コーディネーター（ソース）から宛先ノードまでのCTRL（複数選択）を押しながら、すべてのホップを選択します。 重要なのは、送信元と宛先の間に少なくとも1つのホップが必要です。
宛先ノードを右クリックして、コンテキストメニューを開きます。
「ソースルートの追加」を選択します。

これにより、新しいソースルートが作成され、青みがかった線で視覚化され、宛先ノードへの赤いエンドマークが表示されます。

（今後のリリースでは、代替のフォールバックルートを指定することが可能になりますが、そのための適切なUIを見つける必要があります。）

ソースルートを削除するには：宛先ノードのコンテキストメニューで[ソースルートの削除]を選択します。

ルートは次のリクエストに使用されます。

これは非常にうまく機能し、必要に応じてルーティングを手動で上書きできます。テストにも便利です。
現在、これはGUIを介して構成されている場合にのみ機能しますが、後でREST-APIを介して使用できるようになるはずです。

これですべてが修正されますか？

可能性は低いですが、宛先へのルーティングが改善されるはずです（ノード自体のルーティングは構成できません）。エンドデバイスは親を変更する傾向があり、ソースルートが機能しなくなるため、固定ソースルートはルーターにのみ適していることに注意してください。この場合、自動ソースルーティングの方がうまくいく可能性があります。

いつリリースされますか？

間もなく、次の2.05.81リリースで、リリースのToDoリストに次の（かなり軽い）項目があります。

ソースルートをデータベースに保存/復元します。
NWKセキュリティカウンターの処理を修正して、異なるConBee / RaspBee間のバックアップを修正し、何も動作しないバグを再起動します。
更新後にファームウェアが実行されていることをGCFFlasherに確認させます。

manup 2020年09月06日

❤10

したがって、 @ manupの応答で、答えが出されました。 トピックと主題にとどまってください。

Mimiix 2020年09月07日

こんにちは、この問題の更新の時間以上だと思います。
進捗状況の更新
（次のリリースのプレビュー）
私はソースルーティングで多くのテストを行っており、この問題の調査結果とさまざまなスニファログを試しました。着信ルートレコードコマンドに基づいて、「自動」ソースルーティングを確実に機能させるために多くの時間を費やしてください。これは基本的に、ソースルーティングを使用したほとんどの実装が行うことです— zigbee2mqttのソースルーティングファームウェアのように。それは時々機能しますが、ルートレコードホップがネイバーから見るLQI / RSSI値に基づいてソースルートが選択（および保持）される方法/かどうかについては、より大きなダイナミクスがあるようです。混合ネットワークでは、これは注意が必要です。スタックとハードウェアの違いのため。人々がノード間を移動し、ドアが開閉された場合、リンク品質も非常に動的になる可能性があります。これは、残念ながらルーティングにも影響します。
したがって、宛先ノードに向けて固定ソースルートを構成するというアイデアを実験しました。多くの場合、ネットワークの一部にのみルーティングの問題があります。ここでは、次の場合に固定ソースルートを指定すると便利です。
ソースルートは、オプションでノードごとに指定できます。
すべてのホップは常に電力が供給されている必要があります。
パスを通るホップ位置は妥当なはずです。場合によっては、ユーザーは、自動アルゴリズムが把握できるものよりも、パケットをルーティングする場所についてより適切な計画を立てている可能性があります。
これを行うために、ファームウェアプロトコルが拡張され、オプションでAPS要求ごとにソースルートを提供するようになりました。構成できるソースルートの数に制限はありません。ファームウェアは、要求とACKのためにいくつかをメモリに保持するだけで済みます。
deCONZは、ルート上の各ホップが到達可能かどうかを自動的に判断し、その場合にのみソースルートを使用します。
舞台裏では、ソースルートはノードのMACアドレスで構成されており、NWKアドレスの変更に耐えることができます。
固定ソースルートの作成
deCONZ guiで、コーディネーター（ソース）から宛先ノードまでのCTRL（複数選択）を押しながら、すべてのホップを選択します。 重要なのは、送信元と宛先の間に少なくとも1つのホップが必要です。
宛先ノードを右クリックして、コンテキストメニューを開きます。
「ソースルートの追加」を選択します。
これにより、新しいソースルートが作成され、青みがかった線で視覚化され、宛先ノードへの赤いエンドマークが表示されます。
（今後のリリースでは、代替のフォールバックルートを指定することが可能になりますが、そのための適切なUIを見つける必要があります。）
ソースルートを削除するには：宛先ノードのコンテキストメニューで[ソースルートの削除]を選択します。
ルートは次のリクエストに使用されます。
これは非常にうまく機能し、必要に応じてルーティングを手動で上書きできます。テストにも便利です。
現在、これはGUIを介して構成されている場合にのみ機能しますが、後でREST-APIを介して使用できるようになるはずです。
これですべてが修正されますか？
可能性は低いですが、宛先へのルーティングが改善されるはずです（ノード自体のルーティングは構成できません）。エンドデバイスは親を変更する傾向があり、ソースルートが機能しなくなるため、固定ソースルートはルーターにのみ適していることに注意してください。この場合、自動ソースルーティングの方がうまくいく可能性があります。
いつリリースされますか？
間もなく、次の2.05.81リリースで、リリースのToDoリストに次の（かなり軽い）項目があります。
ソースルートをデータベースに保存/復元します。
NWKセキュリティカウンターの処理を修正して、異なるConBee / RaspBee間のバックアップを修正し、何も動作しないバグを再起動します。
更新後にファームウェアが実行されていることをGCFFlasherに確認させます。

詳細な回答をありがとうございます。コミュニティがこの問題のために懸命に取り組んでおり、あなたが開発者として取り組んでいるため、多くの人が上記のような回答を待っていると思います。

私が持っているいくつかのフォローアップの質問：

上記がベータ版/安定版のアップデートとして利用可能になるのはいつですか？
conbee 1/2とRaspbeeに関して上記の動作に違いはありますか、それともこれはすべて同じですか？
アップデート2.05.81の場合、todoリストにかなり（軽い）項目があるとおっしゃっていますが、いつそのアップデートを期待できますか（このgitにロードマップを追加するのはアイデアかもしれません）。

lubbertkramer 2020年09月07日

こんにちは@lubbertkramer

私はその1に答えることができます：バージョン2.05.81はその月の15日に期待されます（Windowsは数日後にビルドされます）。私はそれをDiscordの早い段階で発表しましたが、Githubには当てはまらないと思いました。それをreadmeに追加します！私の悪い！

編集：readme.mdファイルのプルリクエストを行いました。安定したチャネルがどのように実行されているかはわかりませんが、少し明確にする必要があります。

Mimiix 2020年09月07日

👍3

conbee 1/2とRaspbeeに関して上記の動作に違いはありますか、それともこれはすべて同じですか？

これは同じように機能するはずです。コードをRaspBeeI / ConBee Iに移植し、ソースルートが同じように使用されています。

私は現在、IKEAリピータープラグが生きているが、ネットワークの他の部分で遊びたくないという奇妙なケースがあります。
（ソースルートの有無にかかわらず）それに送信されるコマンドは、サイレントに無視されます。

リピーターはNWKリンクステータスフレームを送信しますが、レポートと空のネイバーリストを送信します。

コーディネーターおよびリピーターが親であるOSRAMセンサーからのコマンドは無視されます。多くのXiaomiデバイスと同様に、センサーは新しい親を自動的に見つけようとしません...悪い状況：

このシナリオは現在2日間実行されていますが、リピーターを回復する方法が見つかりませんでした。リピーターの電源を入れ直すことで問題が解決するかもしれませんが、今のところはこのままにして、空気でなんとか解決できるかどうかを確認します。

manup 2020年09月11日

👍2

Tradfri USBリピーターまたはTradfriプラグに問題がありますか？

morfei1 2020年09月11日

この場合はプラグでした。最新バージョンかどうかはわかりません。後で確認する必要があります。

manup 2020年09月11日

確認できますか？私は3つのTradfriプラグを持っており、最新のFWロックソリッドを約1。5年間実行しています。新しいベータ版で問題が発生し始めた場合は、更新を遅らせる必要があります。

ありがとう！

morfei1 2020年09月11日

これが基本クラスターからのデータです。問題は2日前に、その時点で新しいファームウェアがなかったホームネットワークで最初に発生したことに注意してください。

manup 2020年09月11日

あなたは私のプラグとして最新のFWを使用しているようです。 Ikeaの古いFWのおかげでそうなることを願っています...

最新のFWが何を修正したかを確認するために、tradfri変更ログのあるWebページがダウンしています。

morfei1 2020年09月11日

最新のファームウェアファイルがオンラインになりました：

これらでは、最大でソースルーティングが有効になっています。 32のソースルート。最も古いエントリが自動的に新しいエントリに置き換えられます。この量は今後のリリースで増える可能性がありますが、すでにうまく機能しているはずです。
ソースルートと「通常の」ルートエントリが存在する場合は、ソースルートが優先されます。これは非標準ですが、うまく機能するようです。
ファームウェアには、シリアルプロトコルの堅牢性に関する一般的な改善があります。
ConBeeIIとRaspBeeIIは、フレームカウンターの処理が改善され、電源を入れ直した後、フレームカウンターが再び古い値に達するまでネットワークが失われたように見える問題を軽減しました。

manup 2020年09月14日

❤7 🚀3 👍2

@manupはファームウェアを実行しましたversionコマンドID 0x0Dを削除しましたか？このコマンドに対する応答がありません

Adminiuga 2020年09月15日

@Adminiuga @manupファームウェアに関する

Mimiix 2020年09月15日

最新のファームウェアファイルがオンラインになりました：
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
RaspBeeIとConBeeI
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF
これらでは、最大でソースルーティングが有効になっています。 32のソースルート。最も古いエントリが自動的に新しいエントリに置き換えられます。この量は今後のリリースで増える可能性がありますが、すでにうまく機能しているはずです。
ソースルートと「通常の」ルートエントリが存在する場合は、ソースルートが優先されます。これは非標準ですが、うまく機能するようです。
ファームウェアには、シリアルプロトコルの堅牢性に関する一般的な改善があります。
ConBeeIIとRaspBeeIIは、フレームカウンターの処理が改善され、電源を入れ直した後、フレームカウンターが再び古い値に達するまでネットワークが失われたように見える問題を軽減しました。

このファームウェアをフラッシュするにはどうすればよいですか（marthocのdeCONZ Dockerイメージを使用しています）？

ファイル（ConBee II）をダウンロードしましたが、手動更新手順がmarthocのdeCONZ Dockerイメージに適用されず、marthocのdeCONZのガイドでは、イメージに含まれていないファームウェアを使用できません（このファイルはリストされていません）。利用可能な場合）。

ReX1983 2020年09月18日

このファームウェアをフラッシュするにはどうすればよいですか（marthocのdeCONZ Dockerイメージを使用しています）？

USBドングルをWindowsラップトップに接続し、そこから接続して、完了したらSynologyNASに戻します。

frlarsendeloitte 2020年09月19日

👍1

このファームウェアをフラッシュするにはどうすればよいですか（marthocのdeCONZ Dockerイメージを使用しています）？
USBドングルをWindowsラップトップに接続し、そこから接続して、完了したらSynologyNASに戻します。

ファームウェアをフラッシュするためのWindowsユーティリティはありますか？もしそうなら、あなたはリンクを共有できますか？

ReX1983 2020年09月19日

このファームウェアをフラッシュするにはどうすればよいですか（marthocのdeCONZ Dockerイメージを使用しています）？
USBドングルをWindowsラップトップに接続し、そこから接続して、完了したらSynologyNASに戻します。
ファームウェアをフラッシュするためのWindowsユーティリティはありますか？もしそうなら、あなたはリンクを共有できますか？

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

salopette 2020年09月19日

👍1

したがって、宛先ノードに向けて固定ソースルートを構成するというアイデアを実験しました。多くの場合、ネットワークの一部にのみルーティングの問題があります。ここでは、次の場合に固定ソースルートを指定すると便利です。
ソースルートは、オプションでノードごとに指定できます。
すべてのホップは常に電力が供給されている必要があります。
パスを通るホップ位置は妥当なはずです。場合によっては、ユーザーは、自動アルゴリズムが把握できるものよりも、パケットをルーティングする場所についてより適切な計画を立てている可能性があります。

これですべてが修正されますか？
可能性は低いですが、宛先へのルーティングが改善されるはずです（ノード自体のルーティングは構成できません）。エンドデバイスは親を変更する傾向があり、ソースルートが機能しなくなるため、固定ソースルートはルーターにのみ適していることに注意してください。この場合、自動ソースルーティングの方がうまくいく可能性があります。

明確にするために...新しい静的ソースルートを手動で構成しない場合、この新しいファームウェアはIkeaデバイスのランダムな切断を修正（または少なくとも改善）しますか？または、この更新の恩恵を受ける唯一の方法は、接続が失われる傾向があるデバイスのルートを手動で設定することですか？

ReX1983 2020年09月19日

ルートを手動で設定しない場合、デバイスがルートをプロモートすると、自動ソースルーティングが実行されます（IKEAデバイスのように）。
したがって、以前のファームウェアと比較して、そのようなルートがわかっている場合、これらのデバイスにはソースルーティングが使用されます。

それが本当に開いたままでいるのに役立つなら、以前のファームウェアで定期的に問題を抱えていた人が何か変更があったかどうかを報告できるといいでしょう。

私のテストネットワークでは、ファームウェアは非常にうまく機能し、スニファーログに示されているようにソースルートが頻繁に使用されます。ソースルーティングがなくても私のネットワークはかなりしっかりしていたので、それはそれほど意味がありません。

manup 2020年09月20日

私は21個のライト（4-980lu WS、17-1000lu WS）、3個のプラグと3個（5ボタン）のIkeaの丸いリモコンを持っています。それらはすべて最新のIkeaFWに搭載されています。過去約+ 1。5年間、彼らとの不安定さを経験したことはありません。以前のdeCONZバージョンまたはFWリリースのいずれか、または現在のリリースのいずれかを使用したナイター。最新のRaspBeeFW 0x26370500で安定した.81を実行していますが、先週の使用でも問題は発生していません。

私は推測します....（多分私は完全に正しくありません）Ikeaは一般的な問題はありませんが、セットアップ固有です。 deCONZおよび一般的に、それらの動作とパフォーマンスに影響を与える可能性のあるさまざまな要因がたくさんあります。

morfei1 2020年09月21日

👍1

ほとんどの問題はIkeaGU10ランプで発生したと思います。安定性は時間の経過とともに大幅に改善されましたが、私が始めた2018年後半には混乱しました。過去3か月のリリース/ファームウェアでは、平均して2週間ごとに30個のGU10の1つをパワーサイクルする必要がありました。

peer69 2020年09月21日

👍2

ほとんどの問題はIkeaGU10ランプで発生したと思います。安定性は時間の経過とともに大幅に改善されましたが、私が始めた2018年後半には混乱しました。過去3か月のリリース/ファームウェアでは、平均して2週間ごとに30個のGU10の1つをパワーサイクルする必要がありました。

になり得る。私の知る限り、GU10はIkeaの他のライトのようにFWアップデートを受信していません。最近、私たちは不和チャンネルでそれを議論しました。 GU10 Ikeaライトを実行しているユーザーは、このような動作を経験します。私たちが何を試したとしても、彼の問題を甘やかすものは何もないようです。彼はIkeaTradfri Hubを購入したことを私たちと共有し、IkeaHubとGU10ライトでも同じ悪い経験をしました。

だから、Ikeaがこのタイプのライト用の新しいFWをリリースして、この問題を解決するのは時間の問題だと思います。

morfei1 2020年09月21日

@djwlindenaarがすでに最新のdeCONZとファームウェアに更新されており、彼の経験を共有できるかどうか疑問に思っていますか？ :)

JBS5 2020年09月21日

😄1

実際にはまだ...アップグレードする時間がまだ見つかりませんでした。また、z2mqttに切り替える時間が見つからなかったので、良いニュースは、新しいファームウェアにアップグレードすることです。報告するものがあれば、アップグレードします。

djwlindenaar 2020年09月21日

それが本当に開いたままでいるのに役立つなら、以前のファームウェアで定期的に問題を抱えていた人が何か変更があったかどうかを報告できるといいでしょう。

2日前に最新のファームウェアにアップデートしました。それ以来、Xiaomiウォールスイッチ（ctrl_neutral2、2017年11月25日）が3回自動的に切り替わりました。私はこれまでそのような問題を抱えたことはありません。

1.3.009のTradfri電球E27CWSを介してコーディネーターに接続されています。

さらに、この問題と厳密には関連していませんが、Deconz（コミュニティコンテナー）でOTAアップデートを取得することはできませんでした。

私はTradfri電球を持っています：

1.3.009のE27CWS
1.2.214のE14W
1.2.248のワイヤレス調光器
17 * 1.2.221上のGU10WS

ダウンロードされたTrafriOTAファイルを見ることができますが、何も起こりません。私は何をすべきか？

参考までに、これはコンテナの起動方法です。

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 2020年09月21日

@ ReX1983これはここafaikのこの問題とは関係ありません。別号を開いてください。 Dockerバージョンリポジトリに投稿する必要があると思います。 https://github.com/marthoc/docker-deconz

Mimiix 2020年09月21日

モデレートノート：

ここですべてが混乱する前に、ここでスコープを設定したいと思います。

元の問題に関連するもの：この問題では、IKEAライトが接続を失うことがあります。

ファームウェアに関連するその他の問題は、ここに投稿でき

Mimiix 2020年09月21日

👍1

実際にはまだ...アップグレードする時間がまだ見つかりませんでした。また、z2mqttに切り替える時間が見つからなかったので、良いニュースは、新しいファームウェアにアップグレードすることです。報告するものがあれば、アップグレードします。

@ JBS5 、あなたのトリガーが

ファームウェアと最新のdeCONZ.debをインストールしました。これまでのところ、ソースルーティングが機能していることを確認できますが、もちろん、安定性についての結論はまだありません。投稿し続けます

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

djwlindenaar 2020年09月21日

👍2 😄1

@ ReX1983OTAプラグインがhttps://github.com/dresden-elektronik/deconz-ota-pluginで機能し、デバイスを更新する方法を確認してください。
申し訳ありませんが、IKEAデバイスの通信に問題が1つあります。

MattWestb 2020年09月21日

@ morfei1 @ peer69
GU10電球だけではないことが確認できます。システムにGU10がない状態で、長い間ルーティングと接続喪失の問題が発生しました。

conbee 1の新しいファームウェアで.82がリリースされた後、いくつかの初期の問題が発生しました。
しかし、ネットワークメッシュが落ち着き、数回の電源を入れ直した後、ここ数日間は堅実でした。

私は愚かですが、将来問題が発生した場合に開始するためのより良いベースラインを持つために、すべての電球の最新ファームウェア（OTAU）に更新することにしました。幸運を祈ります。進捗状況をお知らせします。

tubalainen 2020年09月21日

👍2 🎉1

@tubalainenはHAアドオンを使用していますか？

morfei1 2020年09月21日

@tubalainenはHAアドオンを使用していますか？

いいえ、DockerのDebianでHA Coreを使用しています。そのため、ます。どちらもdrestenが提供する.debファイルを使用するため、同じように機能するはずです。 OTAUプラグインがdeconzHAアドオンに含まれているかどうかはわかりません。

tubalainen 2020年09月21日

👍1

これまでの私の観察を少しだけ取り入れています。

Ikea GU-10（そのうち23個）にのみ問題があり、残りのAPIを介してdeconz（docker）に接続するHome Assistantを使用しています。そして、HAがイベントを起動してdeconzに成功しているのを見ることができます。

HAを使用してオンにすると、17個の電球が1つずつ（互いに直後に）オンになりますが、17個のうち3個はオンになりませんが、HAはそれらをオンと見なします。
しかし、私がdeconzでグループを作るなら。そのグループにすべてのライトを置き、HAにそのグループをオンにするように指示します。まだ問題はありません。すべてのライトがオンになります。

ファームウェアの使用：0x26650700改善は見られませんでした（何らかの理由で17個の電球を再ペアリングする必要があり、再ペアリングした後でも同じ問題が発生しました）

それはおそらくrest-apiの制限ですか？

MartinTerp 2020年09月21日

😕1 👍1

@MartinTerp 、グループに対して1つのコマンドではなく、デバイスごとに一度に1つのコマンドを使用すると、失敗する可能性がありますが、ほとんどの場合、何かを実行するはずのランダムなデバイスでは失敗します。

これに対する私の回避策は、コマンド間の5秒の遅延です。例えば
寝室の照明を23:00にbri：127とct：454に切り替えたい場合、また廊下でも、部屋の1つに5秒の遅延を与えます。遅延を設定しないと、一方の部屋または両方の部屋の完全なコマンドをランダムに完了できなくなります。私はこれでたくさん実験します。 Ikeaのバグに似たもので、スイッチの色と明るさを同時に処理することはできません。

これが正確に何であるか、deconzバグ、一般的なzigbee制限、またはIkeaFWバグはわかりません。 zigbeeがどのように機能するかについての知識が不足しているのかもしれませんが、5秒の遅延は常に機能します。

原則として、私は常に使用します。一度にできるだけ少ないコマンドをサンドするか、遅延を使用します。したがって、チャネルをクリーンに保ちます。

一度に多くのグループ/ライトを切り替える必要がある場合は、新しいphosconグループを作成して、これらのライトのグループを含め、単一のグループコマンドを送信することをお勧めします。同じライトを含む多くの異なるグループを持つことができます。ライトごとに1つのグループを使用するだけに限定されません。 phosconに多くのグループを配置したくない場合は、遅延が親友です。

morfei1 2020年09月21日

👍1

@ morfei1私は同様の回避策を使用しており、ほとんどの場合、すべてのコマンド間で5秒の遅延があります。
@MartinTerp IKEA-Tradfriライト以外のデバイス、たとえばOSRAMスマートプラグやライトストリップでもこの問題が発生しました。バグのあるTradfri-Lightsがコマンドを転送しないことが問題の原因でしたが、それは可能だと思います。

githtz 2020年09月21日

👍1

しかし、それはこのように想定されていませんね？
スクリプトが1秒の遅延で1つずつオンにする瞬間、それを処理できる必要がありますか？

MartinTerp 2020年09月21日

😕1

@ morfei1 @MartinTerp

また、トリガーされたオートメーションごとにホームアシスタントからオンとオフのコマンドを2回送信する遅延+を使用していました。

.82以降、遅延と繰り返しコマンドを削除しました。

tubalainen 2020年09月21日

私はそれが5秒の遅延を必要としないことになっているとかなり確信しています。以前のバージョンではこれは必要なかったと思いますが、それ以来ネットワークが拡大しているため、これには賭けません。たぶん82（まだ遅延を減らして試していません）または将来のバージョンでこの動作が改善されるでしょう。

githtz 2020年09月22日

@ morfei1 @githtz @tubalainen @martinterp

他にデバイスのファームウェアを更新する方法について話し合うことはできますか？

Mimiix 2020年09月22日

👍2

ファームウェアのアップデートはしていませんか？

MartinTerp 2020年09月22日

私がそれを正しく読んだとき、すべてが通過するわけではない複数のコマンドを送信する問題が異なります。これは、タスクスケジューラの問題である可能性があります。

「ユニキャストコマンドを複数のライトに送信すると、すべてのライトが反応するわけではない」など、別の問題を開くことをお勧めします。

ここでの問題は、ライトが完全に失われ、まったく到達できない場合に関するものです。これは、ルーティングに関連している可能性があります。

manup 2020年09月22日

👍5

Mimiixによって編集されました

inconsx 2020年09月22日

Mimiixによって編集されました

ReX1983 2020年09月22日

@inconsx @ ReX1983 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-696541484およびhttps://github.com/dresden-elektronik/deconz-で明確だと思いましたrest-plugin / issues / 1261＃issuecomment -696046160

これらのルールを守ってください。 必要に応じて、別の問題を開きます。

Mimiix 2020年09月23日

これが私のフィードバックです。最新のファームウェアとdeconzapiにアップグレードしました。 HAからネットワークを実行しています。

私は約72のノードを持っています、それらのほとんどはIKEAGU10ライトです。アップグレード後、2つの異なるGU10が2日間「死んだ」ことに気づきました。それを元に戻す唯一の方法は、電源を入れ直すことです。 GU10は1.2.217と1.2.221のフィクスチャを使用します。それらをすべて同じバージョンにアップグレードしてみます。

donnib 2020年09月23日

私は4つのGU10しか持っていません。これらは、最新のotaバージョンで実行されている最初のリリースバージョンのものだと思います。到達可能性の点でこれらに問題があったことは一度もありませんでした。ライトファームウェアの更新後に私のシーンが台無しになりました。

manup 2020年09月23日

IKEATRADFRI電球E14W op / ch400lmバージョン1.2.214の1つが応答を停止しました。このランプは、これを何度も、さまざまなdeconzファームウェアで実行しています。現在、deconz26370500と2.05.82を使用しています。
Skärmavbild 2020-09-27 kl 22 35 47

cappadanna 2020年09月27日

私は4つのGU10しか持っていません。これらは、最新のotaバージョンで実行されている最初のリリースバージョンのものだと思います。到達可能性の点でこれらに問題があったことは一度もありませんでした。ライトファームウェアの更新後に私のシーンが台無しになりました。

2.3.050にアップデートした後、これらのGU10バルブで安定性が向上しましたか？私は現在0x26650700を使用しており、2.3.050（17球根）に更新してから、ネットワークがはるかに安定しているようです。デバイスは一晩オフラインにならず、Aqaraのボタン/スイッチは最初の試行で機能します。今は4日なので、言うのは早いです。

ReX1983 2020年10月01日

私は4つのGU10しか持っていません、これらは最初にリリースされたバージョンからのものだと思います

実際には、IKEA GU10のより安価なバージョンがあります（Wのみ）。これらは2.xソフトウェアに更新されたことがなく、1.2.214で実行されています。そして、これらは最も問題のあるものでした。個人的にはあきらめて、IKEAハブでスムーズに動いています。

antonbo 2020年10月01日

@antonboは問題の進行に近づいていると思います。
IKEAは異なるハードウェア（PSU / LEDドライブ）で同じファームウェアイメージを使用しており、異なるハードウェアの「ユーザーデータ」に異なる設定があります（モデルIDはそれに保存されています）。したがって、1つのファームウェアが1つのハードウェア（E14）で正常に動作し、他のハードウェア（GU10 / E27）で問題が発生する可能性があります。
1つの違いは、IKEA GWがZLLモード（Zigbee PRO上）で実行されており、デバイスのステータスをプルせず、デバイスがネットワークで送信しているステータスの変更（ala Zigbee PRO / ZB3標準）をリッスンし、HUEやその他と混合していることです。コーディネーターがデバイスからステータスを取得しているベンダー（ZB3の動作ではない）は、ネットワークを混乱させる可能性があります。
私は最も古いIKEARGBWと古い更新された（1.X）ファームウェア上の1つのE27 Opal WWを持っており、正常に動作し、1つの新しいZB3 GU10WSがうまく機能しています。私のバックボーンは、ネットワーク通信の安定性を維持している約10個のIKEAプラグであり、Xioamiセンサーはすべてのプラグで正常に動作しています。
私の感じでは、ネットワークレイアウトと組み合わせて、いくつかの問題のあるデバイス（パッケージを破損し、常に子を失うOSRAM Outdoor Plugなど）を回避することで、HWおよびおそらくFWの1つの一般的な問題ではありません。

MattWestb 2020年10月01日

@manup私のシステムでは、新しいファームウェアによって以前よりもはるかに悪化したとしか言えません。ソースルーティングであろうと、それが何であるかに関わらず、私は毎日1つまたは2つの電球が動かなくなっており、電源を入れ直す必要があります。 Philipsの色相電球の1つが動かなくなったのを見たこともありますが、電源を入れ直す必要はありませんでした。問題の原因が古いファームウェアであるかどうかはわかりませんが、スタックしているため、アップグレードすることもできません。 :(

donnib 2020年10月06日

新しいGU10にまだ問題があるのか、それとも問題がないのか誰かが知っているのだろうか？新しいデバイスがzigbee3.0を実行していると聞きましたが、妻はこれらの問題に満足していないので、問題が解決した場合はすべて変更できますか？

donnib 2020年10月08日

👀1

今朝はハンギングライトがありました。私はそれが新しいものの1つだと思います。

ライトはどのコマンドにも反応せず、オフラインとして表示されました。パワーサイクルは問題を修正しませんでした。リセットしてネットワークに再度追加する必要がありました。

githtz 2020年10月08日

@ JBS5 @djwlindenaar @lubbertkramerこの問題と比較して、最新のファームウェアに関するフィードバックはありますか？

Mimiix 2020年10月12日

私は48時間、このトピックが何に取り組んでいるのか、そして私が以前に経験したことについて何の問題もなかったことを付け加えることができます。

ただし、以下を追加する必要があります

毎晩deconzでコンテナを再起動します
グループ化をHome-assistantからdeconz / phosconに移動して処理しました。

上記の変更の前に、いくつかの応答性の低い球根がありましたが、より良い経験ですが、現在はそうではありません。

PeterRemnemark 2020年10月12日

@Mimiix 、まあ、言うのは少し早いです。

私を苛立たせているのは、ネットワークがはるかに遅く感じていることです。ボタンを押してからライトが点灯するまでの時間は（ルールにより）以前より長くなっています。また、ライトをオンにして明るさを変更することは、2段階のプロセスであり、その間にしばらく時間がかかります。これを引き起こしている原因を確認するために、スニフログを調べる必要があります。おそらくこれはソースルーティングへの変更とは何の関係もありませんが、そこに行きます。

応答しなくなったライトが1つありましたが、その状況も分析していないため、何が起こったのかを判断するのは困難です。

djwlindenaar 2020年10月17日

👍2

私のE27Ikea電球は、協力するために集合的に停止しました。
これまでのところ、パワーサイクリングはそれらのいくつかで機能しています。 3はまだ戻っていません。私はそれらを再度追加する必要があると思います... :(

ファームウェア：26610700
バージョン：2.05.84 / 14.9.2020
（Raspbee2）

umrath 2020年10月23日

@umrathこれは、この問題で対処されている問題とは無関係のようです。別の問題を開いてください:)

Mimiix 2020年10月23日

症状は私にはほとんど同じように見えます。明らかな理由もなくランプが反応しなくなります。

umrath 2020年10月23日

👍1

私が今言ったように：これは無関係のようです。別号を開いてください。その後、これが関連しているといつでも判断できます。私はこの問題について厳しい船を続けています。

Mimiix 2020年10月23日

はい、私もそれに関連していると思います。バグがなかった数か月後、昨日、（非常に古い）IKEA E27と新しいIKEAアウトレットの2つのデバイスで、両方とも最近のファームウェアで再び問題が発生しました。

当時私がしたことは、KADRILJブラインドを範囲外に運び、後で戻すことだけでしたが、これはまったく関係がないかもしれません。

スニファーを起動すると、同じ問題が発生します。

デバイスは引き続き定期的にNWKリンクステータスコマンドを送信します。
しかし、常に空のリストがあると、周囲のルーターをすべて無視しているように見えます。
それらはMACレベルで着信コマンドをACKします。
彼らはビーコン要求に反応してビーコンを送信しますが、それが彼らが与える唯一の「応答」です。

どういうわけか、IKEAデバイスのZigbeeスタックがNWKおよびAPSレイヤー以上で部分的にクラッシュするか、着信NWKバッファーがいっぱいで解放されないようです。

以下を送信して、デバイスをライブに戻そうとしました。

ZDPは再参加して去ります。
NWKは再参加して退出します（下位レベル）。

どちらもMACレベルでACKされますが、それ以外の場合は無視されます。

次に、デバイスがネイバーテーブルでコーディネーターを取得することを期待して、デバイスの着信および発信リンクコスト（3/3）が機能していることを示す有効なエントリを使用して、コーディネーターのNWKリンクステータスコマンドを偽造しようとしました。 ...どちらも機能しませんでした。

残念ながら、それが起こった後、状況を回避する方法はないようで、IKEAデバイスはこのほとんど死んだ状態になります。いくつかのフォーラムを見ると、あらゆる種類のゲートウェイと基盤となるZigbeeスタックで動作を確認できます。これは興味深いことです。たとえば、Hueブリッジは、ネイバーテーブルやバインディングのクエリやレポートなど、Zigbeeの凝った処理を行わないのに、バグが発生するからです。

IKEAが行う必要があるのは、少なくともNWKおよびAPSコンポーネントがまだ動作していることを確認するウォッチドッグを実装し、デバイスがウォッチドッグを再起動するようにトリガーすることです。これはバグを修正しませんが、少なくともそれが起こったときにデバイスを機能させ続けます。

manup 2020年10月24日

👀1 👍1

@manup診断クラスターを備えた古い
おそらく、数週間の間にそこのカウンターで何かが起こっているかどうかを見るのは興味深いかもしれません。
それは問題を修正することはできませんが、ファームウェアがレイクしないことのヒントを1つ与えます。
良い観察と結論のマンデ!!

Silabsは、最大の顧客の1人のためにバグハンティングをもう少し行っていると思います;-)

MattWestb 2020年10月24日

こんにちは、これは私を混乱させます。数か月前にZZHを使用してZ2Mに移行して以来、この問題は発生していません。たぶん、方程式には他の変数があります。同じ動きをした他の誰かが確認できれば素晴らしいでしょう。

mvjt 2020年10月24日

👍1

@mvjtRasp / CornBeeをZ2Mまたは他のコーディネーターと一緒に使用していますか？
さまざまなzigbeeスタックがさまざまな方法で機能しており、さまざまな問題が発生する可能性があります。

編集：申し訳ありませんが、ZZH =新しいTIコーディネーターが表示されます。
deCONZ NCP = Atmel / Microchip
IKEAデバイス/ NCP = Sirlabs EFR32 / EZSP

HA / ZHA / Zigpy / Bellowsが「BillyEZSP」= IKEAICC-1-AモジュールでIKEAルーターとIKEAおよびXiaomiのエンドデバイスとのコーディネーターとしてうまく機能し、OSRAMまたはXiaomiルーターがないことを確認できます。

MattWestb 2020年10月24日

@MattWestbはい、E27には診断クラスターがありますが、エラー状態を維持するためにまだ電源を入れ直していません。私の他のIKEAライトからクラスター属性を読み取ることにより、属性はすべて利用できないことを報告します：/

少なくとも過去には、TI CC253Xでも問題が発生し、問題の最後にCC26X2R1が記載されていましたが、それは1月の状態であり、その間に改善された可能性があります。 https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

これは一般的にSilabsのバグではない可能性があり、アプリケーション層のカスタムのものである可能性もあります。最近のHueデバイスもSilabsを使用していると思います。 Hueブリッジからは、少なくともTIバージョンとMicrochipバージョンがあります。

これは本当に厄介なことです。多くの場合、バグはまったく発生しないか、数か月後にのみ発生する可能性があります。他のネットワークでは、発生する間隔がはるかに短くなります。ネットワークの運用方法や、定期的に電源が切れるライトの影響が少ないことも重要だと思います。

manup 2020年10月24日

@manup私はあなたの「IKEA問題」で非常にうまく通過している1つのシナリオがあります。
ネットワークを設定している場合、ネットワークは1つのネットワークキーから始まり、セキュリティフレームカウンターが作動し始めます。ネットワークを再構築したり、ネットワークキーを長時間ローリングしたりしていない場合、カウンターは最大0xFFFFFFFF（32ビット）に達し、増加できないため、ストールしています。
次に、フレームカウンターが間違っているが、ネットワーク下のレイヤーが正常に機能しているため、デバイスはzigbeeレイヤーに入ってくるすべてのデータをスローしています。
デバイスのセキュリティフレームカウンターの地位を取得する1つの方法がわからないという問題。 Wiresharkでそれを見るのは不可能だと思います（考える=知らない）。

これを指しているのは、リセットされていない初期のペアリングされたデバイスがより速くストールしているということです。
新しいペアリング/リセットされたデバイスは、カウンターがストールする前に長く実行されています。
1つのデバイスへのMutchコマンドは、それほど「通信」していない1つのデバイスよりも速くストールすることにもなります。

ネットワークキーを安全に保つためにZB3ネットワークで定期的にローリングし、セキュリティフレームカウンターをリセットしてストールしないようにすることをお勧めします。
いくつかの情報AN1233：Zigbee Security2.1.6ネットワークセキュリティフレームカウンター。

その1つのワイルドなブレインストーミングですが、ネットワークを長時間実行した後に問題が発生する可能性があります。

1つのテストは、ネットワークキーをローリングしようとし、「生きている」デバイスはかなり長い間正常に実行されていますが、セキュリティフレームカウンターをゼロから開始するには、停止したデバイスをリセット/再結合する必要があります。

MattWestb 2020年10月25日

うーん、ネットワークキーをローリングすると、すべてのxiaomisが削除されます。

Adminiuga 2020年10月25日

彼らがネットワークを更新して離れていないという間違った200％の安全性（古いZB3のものはありません）!!!

@Adminiuga EZSPでネットワークキーをローリングしようとしていますか？
結果が面白いと思います!!!

MattWestb 2020年10月25日

ネットワークキーをローリングしようとしたことはありません。実際には、定期的にキーをロールする実装の数を知ることは興味深いでしょう。
しかし、pan-idの変更は、5回のうち4回のように、xiaomisがドロップする可能性が非常に高いことを確認できます。

Adminiuga 2020年10月25日

通りからpan-IDをスニッフィングし、数か月の間に数回戻って、1年後にネットワークキーをローリングしなかった大手ライトサプライヤ（ここでは名前がありません）がないセキュリティ侵入テストをいくつか見ました（ウィーンのマリアヒルファー通り））だから、あなたはおそらく正しい（年齢）を持っているでしょう。

MattWestb 2020年10月25日

問題を実行しているセキュリティフレームカウンターがすべての実際のzigbee3デバイスに対して同じことを実行している場合にのみ、「Base-Device-Behavior-Specification」で定義され、古いLLで推奨されていますが、 zigbee PRO（古いHAおよびLL）デバイスまたは認定されていないデバイス（名前のない.... mi）。
次に、ネットワークキーを1年に1〜2回ローリングする方が「手動」であり、ビルトインデバイスを口の中で何度もリセットするために家を破壊する必要はありません。家の構造に統合されており、リセットが簡単です（通常は開いて結合し、ボタンを押すと接続されます）。
Menny "chinese Zigbee 3"は、電源のリセット後に「古い」セキュリティフレームカウンターをスローし、近隣から最初に到着したパッケージから新しいものを使用しています（tasmotas zigbee 3の問題をテストした後、再起動時にNCPカウンターが誤ってリセットされたことがわかりました）だから彼らはただ力を取り戻し、彼らは戻ってきた。

MattWestb 2020年10月26日

昨年もいくつかのテストを行いましたが、ネットワークキーをローテーションするゲートウェイはありませんでした。仕様に記載されているように、ネットワークキー番号をインクリメントするときにNWKセキュリティフレームカウンターをリセットする唯一の方法です。また、これはすべてのデバイスでサポートされており、通常、ほとんど使用されない機能は十分にテストされていないという懸念も共有しています。私はここで間違っていることを心から願っています、そしてそれはほとんどのデバイスで動作します。

いずれにせよ、フレームカウンターのリセットはゲートウェイにとって最も重要です。これは、ゲートウェイに送信コマンドの数が最も多いため、ライトとセンサーは今後数年間は問題ないはずです。現在、これは問題ではありませんが、大規模なネットワークでゲートウェイカウンターに到達すると、2〜3年で1つになります。そのために、ネットワークキーのローテーション、キー番号、フレームカウンターのリセットが機能するかどうかを確認する計画がすでにあります。

とにかくここでの問題は異なります、ゲートウェイのフレームカウンターとエラー状態のライトはまだ問題なく、かなり低いです。

manup 2020年10月26日

👀1 👍1

@djwlindenaar私ができるように、ランプが再びオフラインになったと報告するだけでなく、調査結果を技術的に分析できるので、新しい調査結果があるのではないかと思います。あなたの発見と洞察は大いに感謝されます。 :)

JBS5 2020年11月08日

さて、感謝の気持ちをありがとう...正直なところ、私は現在のネットワークの安定性に完全に満足しているわけではありません。最新のdeconzファームウェアにアップデートしてからダウンしました。一部のライトは過去数週間でオフラインになりましたが、アップグレード前にこれは長い間発生しませんでした。 IKEAライトの定期的な属性レポートを有効にするパッチを使用して実行しましたが、現在の状況ではまだ適用していません

これを分析するのは楽しいですが、それは私にとって趣味であり、私の時間は今では家の改造に完全に費やされています。少し時間が取れるかどうか見ていきます...

djwlindenaar 2020年11月08日

👍3 👀1

さて、感謝の気持ちをありがとう...正直なところ、私は現在のネットワークの安定性に完全に満足しているわけではありません。最新のdeconzファームウェアにアップデートしてからダウンしました。

私は同じ否定的な経験をしています。現在、私のXiaomiデバイス（主にAqaraウォールスイッチ）のほとんどは、日中頻繁にオフラインになり、数分後に動作を再開します（これは、Xiaomiデバイスがリクエストへの応答を受信しない場合に再起動するためだと思いますコーディネーターからのタイムクラスターの属性）。

ReX1983 2020年11月11日

新しいv2.5.88リリースは状況を改善する可能性があります。ここでは、状態遷移がネットワークにレポートをぶつけないように、IKEAのレポート構成がスムーズになりました。以前の状態遷移中に、すべての属性が非常に速いペースで報告されました。

manup 2020年11月13日

👍4

新しいv2.5.88リリースは状況を改善する可能性があります。ここでは、状態遷移がネットワークにレポートをぶつけないように、IKEAのレポート構成がスムーズになりました。以前の状態遷移中に、すべての属性が非常に速いペースで報告されました。

有望に聞こえます:)また、オン/オフは状態遷移だと思いますか？または主に明るさや色モードが変わりますか？
この変更に必要な/推奨される最小のファームウェアバージョンはありますか？

JBS5 2020年11月13日

明るさと、colorX、colorY、色温度などのすべての色固有の属性のみ。
ファームウェアについては、常に最新のもの0x26660700をお勧めします（ConBeeIIおよびRaspBeeIIの場合）。

manup 2020年11月13日

新しいv2.5.88リリースは状況を改善する可能性があります。ここでは、状態遷移がネットワークにレポートをぶつけないように、IKEAのレポート構成がスムーズになりました。以前の状態遷移中に、すべての属性が非常に速いペースで報告されました。

@manup 、このアップデートでAqaraデバイスの安定性の問題も解決したと思います。ありがとう

ReX1983 2020年11月14日

🎉1 👍1

新しいv2.5.88リリースは状況を改善する可能性があります。ここでは、状態遷移がネットワークにレポートをぶつけないように、IKEAのレポート構成がスムーズになりました。以前の状態遷移中に、すべての属性が非常に速いペースで報告されました。
@manup 、このアップデートでAqaraデバイスの安定性の問題も解決したと思います。ありがとう

残念ながら、問題（＃3605）はまだここにあります、私はあまりにも早く結論に急いで行きました

ReX1983 2020年11月15日

Deconz-rest-plugin: IKEAライトが時々接続を失った

最も参考になるコメント

全てのコメント493件

他のIKEA電球も問題を引き起こしているようです。

進捗状況の更新

固定ソースルートの作成

これですべてが修正されますか？

いつリリースされますか？

進捗状況の更新

固定ソースルートの作成

これですべてが修正されますか？

いつリリースされますか？

ConBee II

RaspBee II

RaspBeeIとConBeeI

ConBee II

RaspBee II

RaspBeeIとConBeeI

これですべてが修正されますか？

関連する問題