deconz-rest-plugin 🚀 - 宜家灯偶尔会断开连接

与2.05.58相同。一个Tradfri GU10似乎是不负责任的atm：

几天前，我还带一个色带灯条发生在我身上，所以我不认为有任何宜家特定的问题。设备必须重新启动，然后再恢复正常。在某些情况下，仍然令人烦恼，主要是因为我的FLOALT面板直接供电且没有墙壁开关来关闭它们的电源。

peer69 于 2019-02-14

有什么线索吗？

REST API插件在轮询光源的状态几次时未收到响应时，将光源标记为不可访问。未收到响应的原因按可能性顺序为：
一种。灯光的功率已经切断（例如，通过20世纪的墙壁开关）；
b。 Zigbee网络出现打（（例如，由于网格中的无线电干扰或路由问题）。在这种情况下，指示灯仍会对组命令作出反应；
C。指示灯的固件已崩溃。

是否可以恢复连接，然后再断开/连接电源？

在a）和c）中：不。在b）中：是。

REST API插件在收到消息时将其标记为可到达。接通电源后，它会发送_Device Announcement_消息。在b）中，通常，当下一次轮询成功时，光会自发地返回。您也可以在deCONZ GUI中选择节点，然后按0 。

ebaauw 于 2019-02-14

👍1

在2.05.59版本中也存在相同的问题。

thomas70 于 2019-02-14

即使升级到2.05.59，我也有这个问题。今天是我的三个户外灯之一。
它的Tradfri灯泡都属于它们。

rich710se 于 2019-02-15

@ebaauw感谢您的解释。

一种。灯光的功率已经切断（例如，通过20世纪的墙壁开关）；

这些灯没有可用的墙壁开关，因此无法意外断开电源。

b。 Zigbee网络出现打（（例如，由于网格中的无线电干扰或路由问题）。在这种情况下，指示灯仍会对组命令作出反应；

断开连接时，指示灯不会对组命令作出反应（在Phoscon应用程序中，指示灯已分配给Hue Dimmer，而在断开连接时，它们不会对Hue Dimmer做出响应）。

C。指示灯的固件已崩溃。

我的所有IKEA GU10位置上都安装了固件1.2.214。有20多个，随机灯离线，比方说2-3周中的一个。

JBS5 于 2019-02-15

您可以使用https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c尝试最新的deCONZ版本

ebaauw 于 2019-02-15

最近两个月，我两次使用两种不同的IKEA E14灯泡（IKEA fw 1.2.214）获得了相同的体验。
动力骑行对我来说都是两次。

tubalainen 于 2019-02-15

C。指示灯的固件已崩溃。

当指示灯甚至对组命令都没有反应时，看起来好像是固件崩溃。

2.05.59修改了IKEA网关参数以配置灯光状态报告。主要是希望不使用宜家本身未测试的配置来触发任何错误。旁注的更改将导致不再使用计时器来报告设备。

重新接通电源后，将应用新配置。

我们仍然向灯发送一些维护请求，例如组成员身份和邻居表查询，并且如果2.05.59无法改善稳定性，则可能会进一步限制这些请求。

请记住，轻固件中也可能存在与网关发送的任何请求无关的错误。

manup 于 2019-02-15

👍3

C。指示灯的固件已崩溃。
当指示灯甚至对组命令都没有反应时，看起来好像是固件崩溃。
2.05.59修改了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您是否对电源进行了电源循环，因为这是@manup在https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127中提到的需要？

重新接通电源后，将应用新配置。

JBS5 于 2019-02-15

很好的提示，还没有做到。现在，由于另一个原因，我不得不回到.58（高cpu负载使网关无响应），今天晚些时候将再次尝试使用.59进行此操作，然后关闭所有宜家灯。

peer69 于 2019-02-15

我也遇到这个问题，在相同的GU 10灯下发生了两次。当前正在运行2.05.59，并且在更新后我确实关闭了电源然后再打开。

jurriaan 于 2019-02-17

忘了补充，有时候好像是不断失效的灯泡。前一阵子我确实有另一个灯泡的问题，而且总是会停止反应。

jurriaan 于 2019-02-17

关闭电源后，我的宜家灯泡又回来了。但是我的宜家FLOALT面板WS仍然离线

thomas70 于 2019-02-17

我遇到了同样的问题，并且已经这样做了相当长的时间，我想说.59实际上会使我的情况变得更糟。我有80个节点，其中32个是Trådfri灯和开关，5个是Hue灯，其余的是不同的小米电池供电的设备，例如温度，运动，烟雾探测器等。每种类型的设备至少无响应一次，因此在我的情况下这不仅是Trådfri灯，而且当时我只是在遇到Trådfri和Hue灯的问题。

关键是我早先通过了Hue桥运行了所有指示灯，并通过了Xiaomi网关运行了小米传感器，然后它们全都坚如磐石，所以我认为不是设备固件成为我的罪魁祸首，除非是由以下原因造成的：情况的变化。

我在一个位置上有六个TrådfriGU10灯，以前该灯工作正常，但是在升级到.59和几个电源循环后，它们现在几乎完全没有反应，我可能必须将它们重置。奇怪的是，这种不响应也似乎是从不同的灯光“移动”而来的，这取决于哪个灯光有电。如果我切断了一些无响应灯的电源，可能要花一会儿时间，然后突然有些其他灯却无法正常工作。也许某个地方有一些抵消额，可以解决问题？

Bllstc 于 2019-02-18

关键是我早先通过了Hue桥运行了所有指示灯，并通过了Xiaomi网关运行了小米传感器，然后它们全都坚如磐石，所以我认为不是设备固件成为我的罪魁祸首，除非是由以下原因造成的：情况的变化。

有趣的是，您在Hue网络上是否还拥有所有32个宜家灯？我问是因为Hue bridge仅使用轮询，并且未配置属性报告。

您在小米网络上是否也有路由器设备，如Hue或Ikea灯？

我在一个位置上有六个TrådfriGU10灯，以前该灯工作正常，但是在升级到.59和几个电源循环后，它们现在几乎完全没有反应，我可能必须将它们重置。奇怪的是，这种不响应也似乎是从不同的灯光“移动”而来的，这取决于哪个灯光有电。如果我切断了一些无响应灯的电源，可能要花一会儿时间，然后突然有些其他灯却无法正常工作。也许某个地方有一些抵消额，可以解决问题？

嗯，那真是太糟糕了，我真的很想知道这是怎么发生的，与以前的版本相比，2.05.59是“熟悉”宜家灯的方式。现在正在像宜家网关一样进行配置。

当灯变得无响应时，可以请您在deCONZ中选择节点，然后按0如果它再次变为响应/黄色，则不需要重新通电。请注意，在这种情况下成为僵尸的光将很快被修复，这可能会在当前某个网络星座上发生。

顺便问一下常见问题：

您正在使用哪个固件版本？
RaspBee还是ConBee？
如果使用ConBee，您是否使用USB延长线？

manup 于 2019-02-18

它花费了比预期更长的时间，但是现在一切似乎又可以正常工作了。至少从现在我能说出来。

我重新启动了服务器，并重新启动了网络中的每个主电源指示灯，以确保它们获取了最新的配置，但是尽管如此，问题仍然消失了两个小时，所以我认为我认为还为时过早问题仍然存在，因为它无法立即生效。

有趣的是，您在Hue网络上是否还拥有所有32个宜家灯？我问是因为Hue bridge仅使用轮询，并且未配置属性报告。

是的，有点。我在色相网络上有31个宜家灯以及色相灯。第32个宜家设备是我当时没有买过的开关插座。

您在小米网络上是否也有路由器设备，如Hue或Ikea灯？

不，仅电池供电的传感器

当灯变得无响应时，可以请您在deCONZ中选择节点，然后按0如果它再次变为响应/黄色，则不需要重新通电。请注意，在这种情况下成为僵尸的光将很快被修复，这可能会在当前某个网络星座上发生。

我确实多次尝试了此操作，但没有任何效果。至于硬件和设置，我使用的是带USB延长线和262F0500的ConBee。既然一切对我来说似乎都工作正常，但此信息目前可能没有任何用处，但我将尽量避免下任何结论，并让网络运行几天以确保问题不会返回。

Bllstc 于 2019-02-19

自上周末以来，我一直在跑步.59，但我仍然会随机丢宜家灯。（房屋外墙上有16个E27灯泡。）
灯泡FW与仍在宜家网关上的其他灯泡相同。
将ConBee与262F0500 FW一起使用。
上周末，我还购买了一个HUE桥，当我注意到.59的“引擎盖下”发行说明时，我正要开始移动灯光。决定推迟，但将重新考虑即将到来的周末。
Deconz仍将是我最好的小米/ mi多维数据集控制器选择。还没有错过任何手势。

olemr 于 2019-02-20

自上周末以来，我一直在跑步.59，但我仍然会随机丢宜家灯。（房屋外墙上有16个E27灯泡。）
灯泡FW与仍在宜家网关上的其他灯泡相同。
将ConBee与262F0500 FW一起使用。
上周末，我还购买了一个HUE桥，当我注意到.59的“引擎盖下”发行说明时，我正要开始移动灯光。决定推迟，但将重新考虑即将到来的周末。
Deconz仍将是我最好的小米/ mi多维数据集控制器选择。还没有错过任何手势。

我在这里也遇到了同样的情况，有16个宜家灯，2个宜家控制插座，海曼插头和innr插头以及一些小米传感器（立方体/门传感器/运动传感器）。非宜家设备从未有问题。但是我目前几乎每天都遇到宜家灯掉出网络的问题

我在固件0x26300500和deCONZ .59上使用带有USB延长线的Conbee

jurriaan 于 2019-02-21

我的灯已经好一阵子了，但是几天前，我的TrådfriE14灯泡突然变得无响应。一个电源循环后，它又恢复了生命。

今天是GU10之一退出的时候了。它在物理上与前面提到的E14非常接近，因此我不确定这是否是巧合。即使我的所有灯都在ConBee范围内，GU10还是很可能通过E14路由了。

在deCONZ中选择节点并按0不会执行任何操作。我还尝试过重新启动deCONZ容器，并且在启动时重新路由网络时，它不会将任何路由连接到该特定灯泡。进行故障排除的最佳方法是什么？

Bllstc 于 2019-02-25

12天后，另一个GU10变得无法访问，并且没有重新启动就无法重新连接。

很高兴分享解决此问题所需的任何信息。

JBS5 于 2019-02-26

同样在这里，昨天经过6天的完美连接后，我丢失了一个Tradfri灯泡。.打开/关闭电源并重置无济于事。它在deConz中仍然是黄色的，但是无法连接或控制它。

rich710se 于 2019-02-27

同样在这里。经过几天没有任何问题的今天，我的两个GU10 Tradfri灯停止响应。通过在GUI中按0，我可以使其中的一个恢复活力，但是我必须重新启动另一个。
幸运的是，这似乎只发生在GU10设备atm上，我的FLOALT面板还没有问题（在我的设置中，只能使用断路器对它们重新通电）。

peer69 于 2019-03-01

对我来说，这个问题也一直存在。现在，我已经经历了3-4个GU10灯泡丢失连接以及我的Hue E27灯泡和一个小米门传感器（磁铁）的问题。在重新启动电源后，某些指示灯会重新开始工作，而其他指示灯则没有。按下0不会执行任何操作。

还值得注意的是，小米传感器在对相邻且无响应的GU10重新上电后会再次开始工作，因此我认为传感器正在通过该灯布线，但是如果存在任何连接问题，它是否应该自动重新布线？

Bllstc 于 2019-03-01

这里同样的问题。昨天我更新到了最新版本.59，现在几个宜家灯无响应

Webserve 于 2019-03-04

您好，您能否提供整个网络的更多见解，例如网络规模和其中的其他由主电源供电的设备？

几天前，我重新布置了家庭网络，现在包括：

5个IKEA WS GU10（固件1.2.221，产品代码LED1537R6GU10EU）
使用Mac地址0x000b57ff .....（旧批处理）
2个IKEA可调光E27（固件1.2.214）
1个IKEA E14 WS灯（固件1.2.221）
1个IKEA中继器（固件2.0.019）
1个IKEA出口（固件2.0.019）
1个OSRAM GU 10
1个OSRAM E27彩色灯泡
1个OSRAM插头
1个Hue E27彩色灯泡
1个Hue E27可调光lux灯泡

deCONZ 2.05.59; ConBee固件0x26300500（但也可以使用0x262f0500）。

我有4个FLS-PP lp，但由于它们充当非常强大的信号中继器，因此现在已关闭电源进行测试。

带有传感器和交换机的总网络大小为55。
所有的灯一直通电，到现在为止零故障。

manup 于 2019-03-04

如果可以提供任何帮助，这是我的网络的一些更详细的规格。我仍在运行带有262F0500的2.05.59和连接到ConBee的延长线。如上所述，在首先更新到2.05.59并关闭所有市电设备的电源后，等待了几个小时，网络近一周没有出现故障，因此似乎需要一段时间才能开始出现问题。不幸的是，该问题再次出现，并且所有主电源供电设备的整个电源循环以及deCONZ重新启动均无法解决该问题。似乎该问题在各个设备之间徘徊，因为有时灯可能会在一段时间内无响应，然后自行修复。

今天早些时候，我遇到了一个问题：TrådfriE14和一个Hue E27都没有响应。在重新启动E27之后，E14也重新恢复了生命，我什至没有触摸它。无反应的GU10似乎有时会交易的情况也是如此，因此每天至少有两个无反应的GU10，但并非总是相同的灯，因此有些灯开始工作，而另一些灯坏了，反之亦然。

我的网络当前由包括ConBee在内的以下80个设备组成，市电供电的设备全天候24/7供电。

电源供电

| 数量| 类型固件|
| ---------- | ------ | ------------- |
| 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 | 色相E14白色氛围LTW012 | 1.29.0_r21169 |

电池供电

数量| 类型固件
--------- | ------ | -----------
1 | Trådfri开/关开关| 1.4.018
10 | 小米Aqara多传感器（方形温度/嗡嗡声/压力）| 20161129
3 | 小米Aqara运动传感器（运动/勒克斯）| 20170627
4 | 小米Aqara水传感器| 20170721
1 | 色相运动传感器| 6.1.0.18912
11 | 小米Aqara接触式传感器| 20161128
8 | 小米/霍尼韦尔烟雾传感器| 不适用

Bllstc 于 2019-03-04

上周deconz的运行情况似乎还不错，但昨天我又有一个宜家灯泡（白色光谱）与deconz失去了联系。即使关闭然后重新打开也无济于事。必须重新启动deconz才能以某种方式再次工作。

我有一个主要装有宜家灯泡，海曼插座和一些小米传感器的网络。

jurriaan 于 2019-03-10

我的Zigbee网络的一些规格：

Conbee固件262F0500，带有NUC上的扩展电缆。
Docker中的deCONZ 2.05.55，所以我要做的第一件事就是升级到2.05.59。

供电（24/7）

| 数量| 类型固件|
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27白色| 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27白色| 1.2.214 |
| 21x | Tradfri GU10可调光| 1.2.214 |
| 3x | 欧司朗Smart +插座| 1.04.12 |

电池供电

| 数量| 类型固件|
| ------------- | ------------- | ------------- |
| 3x | 色调调光器开关| 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

当前版本对此有任何更新吗？我已经运行了0.60天，至今没有三盏灯。

peer69 于 2019-03-15

不幸的是，我已经无法连接.60上常规的Tradfri E27白色灯泡和最新的固件了。

jurriaan 于 2019-03-15

这是个坏消息……如果我正确理解轮询间隔已更改为.60，以降低攻击性。激进的轮询导致灯挂起对我来说是完全合理的，这太可惜了，这似乎不能解决我们的问题。

peer69 于 2019-03-15

昨天，我关闭了所有主电源设备的电源，并更新为2.05.60和26320500，然后再重新打开它们，以确保安全。然后，所有灯都可以正常工作约24小时，但就在几分钟前，我注意到我的GU10之一已停止响应。幸运的是，几分钟后它又重新恢复了生命，而从我的末端开始没有任何手动交互，因此也许是网络被阻塞了。

Bllstc 于 2019-03-16

@ JBS5我建议将1.1.1.0-5.7.2.0的4x Tradfri E27白色更新为最新的固件版本。如果我没记错的话，这仍然是第一个版本。

@jurriaan您的Tradfri E27白色灯泡有哪个版本？

这是个坏消息……如果我正确理解轮询间隔已更改为.60，以降低攻击性。

是的，基本上与宜家网关非常相似。现在唯一剩下的区别是定期查询邻居表（用于显示网格网络线）。

可以通过单击deCONZ中的CRE图标并取消选中“ Routers and Coordinator”来关闭此功能。
可能值得一试。

在Reddit上有一篇文章提到IKEA网关理论上应该支持多达100个设备，但是它并不是一个很好的选择。知道宜家团队要测试的常规网络规模会很有趣。

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

您可能有100台设备连接到网关。我们没有对此进行正确的测试，这就是我们不保证的原因。但是技术极限是100，而且我见过拥有100台设备的人没有任何问题或只有很小的问题。

网关的新版本将支持相同数量的设备（正式数量为50）。如果您想将它添加一倍，则可以在系统中添加另一个网关。

manup 于 2019-03-18

@ JBS5我建议将1.1.1.0-5.7.2.0的4x Tradfri E27白色更新为最新的固件版本。如果我没记错的话，这仍然是第一个版本。

那些使用旧固件的E27灯泡在过去6个月中没有发生故障，而其他灯泡却发生了故障。

JBS5 于 2019-03-18

非常有趣，1.2.214版的E27怎么样？

manup 于 2019-03-18

非常有趣，1.2.214版的E27怎么样？

在过去的几个月中，他们仅失去了一次联系。

自从上次GU10断开连接以来，已经有几个星期了，而我仍在Conbee上使用deCONZ 2.05.55和固件262F0500。

JBS5 于 2019-03-19

我也有这个问题。仅宜家节点（43个，主要是灯光）。我对zigbee不了解，但是由于我没有看到它，因此：禁用OTAU后，我的网络似乎更加稳定。前几天，我还将网络偏好设置更改为不太安全。不记得是哪一个了，但是在那之后我还没有丢下任何灯。

lb1974 于 2019-03-20

几天后没有任何问题，几个GU10变得没有响应。
另一个问题可能无关紧要，但是Osram指示灯也失去了连接。即使它仍在GUI中显示并且似乎已经啮合，但我再也无法控制它了。不得不删除已读取的灯，它被分配了另一个灯号，但在添加后不久重新获得了它的前名。不知道这是怎么回事，但这比我希望在安装程序中看到的要多得多。

peer69 于 2019-03-24

@ peer69您是否也尝试过将灯重新通电？通常，不需要恢复出厂设置。
您使用的是2.05.60？您还可以提供有关您的网络，多少灯和市电供电设备的更多详细信息吗？

manup 于 2019-03-24

@manup我重新启动了灯。几次。关机后大约10秒钟可以控制它，但是随后再次变得无响应（GUI中的红灯闪烁）。
同时，即使恢复出厂设置后，该问题仍会再次出现，并且还影响了另一个OSRAM指示灯。现在，我已经摆脱了网络中仅有的两个OSRAM灯，并用色相灯泡代替了它们。我可以使用ORSAM灯进行一些测试，但是我需要一些时间。

我正在运行2.05.60。当前有57个节点连接到网络，其中27个设备由主电源供电。我使用13个IKEA GU10、1个IKEA FLOALT面板，2个IKEA E14、3个OSRAM Smart +插头，3个E14色相灯泡，5个E27色相灯泡，1个色相灯带。

在过去的日子里，我还不得不关闭部分宜家的IKEA GU10，然后重新启动。重启后，一切恢复正常，我看不到任何模式。我有几盏GU10的灯，尽管总是受到一个组的控制，但同时没有响应的GU10却无响应。

peer69 于 2019-03-28

此刻，我回到正题。现在，我通常有2-3个无响应的灯，但它会在不同的灯之间跳转，因此有时它们可以工作，有时又不取决于其他哪些在线灯。这个问题似乎是级联的，因为当我通过切断电源来物理关闭某些灯时，它会将问题转移到其他灯上。

我还丢失了几个小米温度传感器，门传感器和宜家开/关开关，但是它们没有弹出，因此可能需要重新配对才能重新开始工作。

就像我之前提到的那样，在整个电源循环之后，一切都很好，但是几天后，灯又开始变得没有反应了，现在已经好几个星期了。当它第一次发生时，有一个客人不小心将E14拔掉了几个小时，所以我不确定它是否完全无关，或者zigbee网格的意外干扰是否导致路由疯狂。考虑到我显然不是唯一一个遇到这些问题的人，我认为这可能只是一个巧合。

我真的很喜欢将所有zigbee设备都集成在一个网格中的概念，但是我几乎要启动旧的Hue和Xiaomi网关并将ConBee放在抽屉中，我真的不想这样做。由于其他几个原因。是否有人有进一步解决问题的技巧，可以帮助我准确地确定正在发生的事情以及如何解决它？

Bllstc 于 2019-04-04

我的宜家GU10灯箱之一现在也没有响应。

在嗅探器中，我看到它仍然处于“活动状态”并发送NWK链接状态消息，但显然它认为它在网络中是单独存在的（链接状态计数：0）。

它不响应单播命令，但会定期发送modelid的ZCL属性报告。

从大约2个小时开始进行嗅探，不确定何时无响应以及是否相关，但是报告ZCL序列号很低：

我将做一些更多的测试，并且暂时不对它重新通电。

我的Tradri电源插座今天也真的很奇怪，并且确实在重新启动圈子中运行，以前从未有过。

manup 于 2019-04-04

刚刚注意到，第二个IKEA GU10也是走路导致的，与另一个相同。

两种设备均不响应单播，组播或ZCP nwk地址请求（按0）。
他们发送空的NWK链接状态命令。

第二个GU10也确实发送了ZCL OTA查询下一个图像请求。

似乎没有得到回应。

只是一个疯狂的猜测，但是我认为缓冲区中的灯光被阻止了，这就是为什么什么也没收到和处理的原因。输出缓冲区仍在工作，因此固件能够发送报告和ota查询。

如果他们实施了简单的运行状况检查之类的操作，以便在mac层正常工作（收到命令）但nwk和aps层保持沉默的情况下，固件可以在一段时间后重新启动，那将是很好的。

manup 于 2019-04-04

即使升级到2.05.59，我也有这个问题。今天是我的三个户外灯之一。
它的Tradfri灯泡都属于它们。

题外话。您如何在所有这一切中找到自己的光芒？我有类似的设置，我想...没有时间了

MattL0 于 2019-04-04

类似地，我的意思是+-50个设备

MattL0 于 2019-04-04

+-50还可以。我们的测试网络之一在Raspberry Pi 1上具有+180个带有deCONZ的设备，这很有趣:)

我们有一些计划在deCONZ中添加更好的过滤器/分类，以简化设备查找过程，目前在某些设备上确实很麻烦。

manup 于 2019-04-04

👍1

灯仍然被卡住。

一个有趣的发现：我关闭了飞利浦Hue运动传感器（Hue Lux）的父级，因此它需要搜索一个新的父级。传感器现在尝试通过卡住的宜家GU10灯之一重新加入。

指示灯确实会以“离开（带有重新加入）”命令作出响应。因此它确实处理了重新加入请求！

可悲的是，色相运动传感器很固执，试图永远重新加入卡住的GU10灯，而不是寻找更好的父母。

但是，这里有趣的部分是，卡住的IKEA灯确实会响应重新加入请求，也许它还会处理NWK离开请求，这可能是使灯重新进入工作状态的一种解决方法。

manup 于 2019-04-05

👍1

校正，色相运动传感器不是太顽固。几分钟后，传感器选择了另一个工作父母（好）。

manup 于 2019-04-05

但是，这里有趣的部分是，卡住的IKEA灯确实会响应重新加入请求，也许它还会处理NWK离开请求，这可能是使灯重新进入工作状态的一种解决方法。

我确实对此进行了测试，但遗憾的是它不起作用。当灯处于卡住状态时，它们将不处理带有重新加入请求的NWK离开。

目前，我只能得出的结论是，宜家需要解决灯卡住的根本问题，或者对固件的NWK / APS层实施某种看门狗+健康检查。

究竟是什么导致光进入这种状态仍然未知，包括广播风暴，某些命令，路由问题...？

我会将我的发现和嗅探器日志转发给宜家，希望他们可以使用它们来跟踪问题。

manup 于 2019-04-06

👍4

那么@manup ，重新加入被卡住的宜家灯的最佳实践是什么？

Filialen 于 2019-04-06

对我来说，打开电源再打开显然是最好的

djwlindenaar 于 2019-04-06

@manup我猜想，如果您不知道如何使患者变得更好，您应该尝试使其变得更糟。因此，用可能导致锁定的原因轰炸一盏灯，看看会发生什么。
而且，这些灯不是基于Ember堆栈吗？也许有一些支持团队或论坛可能会引起关注（双关语）。

向宜家致意，他们是否对这样的支持请求做出了回应？还是我们应该合作以引起关注？

djwlindenaar 于 2019-04-06

对我来说，打开电源再打开显然是最好的

对我来说不是那么多...
重新启动Conbee是暂时解决此问题的唯一方法。
然后一段时间后，相同或更多情况下，另一个宜家灯被卡住了...
总是只有一盏灯！真是奇怪...令人不快...：/

Filialen 于 2019-04-07

@manup太棒了！感谢您查看这个！

我还通过Reddit将此线程转发给了IKEA Tradfri团队。刚刚得到他们的回应，说他们已经转发了信息。希望他们可以使用它来改进固件或找到解决此问题的方法：）

jurriaan 于 2019-04-08

👍4

似乎在未来几天内将为tradfri网关提供新固件，该固件特别针对HomeKit支持。灯泡可能还会有新的固件。

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-控制插座-2.0.022.ota.ota.signed
10005778-4.1-TRADFRI-onoff-shortcut-control-2.0.020.ota.ota.signed
10032198-2.1-TRADFRI-gateway-1.8.25.p.elf.sig.ota.signed
10038562-TRADFRI-sy5882-bulb-ws-2.0.022.ota.ota.signed
159699-2.1-TRADFRI-远程控制-1.2.223.ota.ota.signed

因此主要集中在网点/网关。

jurriaan 于 2019-04-11

今天，我的一个色相灯泡显示了完全相同的问题。必须重新启动它才能重新响应。

peer69 于 2019-04-20

有关谁更新了deCONZ和Conbee固件的任何新闻？

直到现在1或2个GU10将在2-4周内脱机。偶尔会出现这种情况，但由于我在几个地方没有电源开关，因此重启电源很烦人。

刚刚将固件更新为0x26330500，让我们看看。

JBS5 于 2019-05-05

不幸的是，今天我的GU10之一不可用。
在Conbee上将deCONZ 2.05.64与固件26330500一起使用。

JBS5 于 2019-05-10

我认为可以得出结论，这是灯泡的FW问题，因为我们在Philips HUE Bridge上看到了完全相同的问题。我在Trådfri应用程序的发行说明部分中注意到，提到了CT v2灯泡。也许甚至与灯泡硬件有关？

olemr 于 2019-05-10

到目前为止，我对2.05.65没有任何问题。

peer69 于 2019-05-31

一样，我已经有好几个星期没遇到这个问题了

VincentMasselis 于 2019-06-02

直到现在，我都使用最新版本的deconz进行相同操作。几天前更换了一些灯泡。我只需要手动将其关闭然后再打开这些灯中的一个，它就可以再次响应。

jurriaan 于 2019-06-02

几天前，一些GU10和E27灯泡离线。只有重新通电后，它们才能重新联机。

可能是相关的：这发生在我的假期中，一天或10天都没有电。

带有deCONZ 2.05.64的固件26330500

JBS5 于 2019-06-09

对于那些说几周前几周都没有问题的人来说，该问题如何？

我仍然有这个问题。有时它们都不是脱机的，而GU10突然掉线了，几天后又出现了另一个。

据我所知，Tradfri GU10仍然没有可用的新固件。

JBS5 于 2019-08-21

我仍然有这个问题。因为对我来说，即使我不能将灯光作为一个单独的设备来控制，组命令在大多数情况下仍然可以正常工作，因此我在壁挂开关脚本中使用了这些作为解决方法。

peer69 于 2019-08-21

组命令也对我有用，但只有几次。在那之后，指示灯保持打开或关闭状态，并且不再响应。即使使用绑定的Hue Dimmer也不行。

JBS5 于 2019-08-21

我也是。我的印象是该问题被延迟了，而且还没有解决。
我也使用组命令解决了这个问题。

我确实注意到有些灯似乎更容易受到此问题的影响。你知道吗？

djwlindenaar 于 2019-08-21

@djwlindenaar很难说，但是我想我25个以上的GU10中有一半从来没有遇到过这个问题，我敢肯定有几次会出现这个问题。

@ peer69 @djwlindenaar group命令是否继续工作？今天，GU10脱机，甚至第一次没有响应组命令（来自deCONZ和绑定的Hue Dimmer的组命令）。

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灯已脱机，但在关机后再开机后又不会恢复在线。在VNC中也按0不能解决此问题。

此外，组命令或绑定的Hue DImmer Switch无法再打开/关闭灯。

JBS5 于 2019-09-29

从昨晚开始，我在走廊上有4个宜家灯，x灯在x时间后被计时器（家庭助理）熄灭，现在4个灯中的1个一直保持点亮，并且无法由家庭助理/ Deconz关闭。据Deconz称，它处于离线状态，并且7个小时没有重新加入。将尝试重新启动并查看是否能解决问题。

灯不亮：TRÅDFRI灯泡E27蛋白石1000lm版本1.2.214
工作灯：TRÅDFRI灯泡E27蛋白石1000lm，版本1.2.214
固件：26330500
Deconz：V2_05_69

lubbertkramer 于 2019-09-30

我相信宜家Trafri GU10白色光谱灯泡存在硬件问题。同样在我的设置中（通过本地api连接到Home Assistant的宜家网关），每隔几天我的17个灯泡中至少有一半会脱机。唯一的解决方案是对灯泡重新通电。

这可能是宜家推出了一个新的硬件版本的原因，该版本运行的固件版本不同（2. *而非1. *）。

据我所知，旧版本没有新的固件更新，这可能是硬件相关的迹象。

不知道保修是什么，但是我打算要求更换新版本。

ReX1983 于 2019-09-30

我相信宜家Trafri GU10白色光谱灯泡存在硬件问题。同样在我的设置中（通过本地api连接到Home Assistant的宜家网关），每隔几天我的17个灯泡中至少有一半会脱机。唯一的解决方案是对灯泡重新通电。
这可能是宜家推出了一个新的硬件版本的原因，该版本运行的固件版本不同（2. *而非1. *）。
据我所知，旧版本没有新的固件更新，这可能是硬件相关的迹象。
不知道保修是什么，但是我打算要求更换新版本。

不确定是否仅与一种类型有关，因为我使用的是温暖的白色GU10，而不是白色光谱。

JBS5 于 2019-09-30

今天有两个宜家GU 10 WW也有同样的问题。重启电源并没有帮助。它确实有助于重启并重新启动deconz。也许一些邻居表问题？两个灯都是两个一组，并且始终作为一个组进行控制。

peer69 于 2019-09-30

这几天在几次安装中遇到了什么巧合……或者正在发生其他事情？

@ peer69

您正在使用哪个版本的deCONZ和conbee固件？

我在用：
deCONZ V2_05_66
固件26330500

JBS5 于 2019-10-01

这里的固件相同。 deCONZ版本2.05.69。

peer69 于 2019-10-01

另一款Tradfri GU10暖白色失去了连接。

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可以用于它们。我将在我的宜家E27可调光灯上进行测试，希望最坏的情况是崩溃但不燃烧:)

manup 于 2019-10-04

👍1

我尝试手动分配文件，但是灯泡看不到要进行更新（无法启动）。

manup 于 2019-10-04

对此也只是“我也”。我的整个房子都是Tradfri，今天重启服务器后，我已经连续三天第三次失去整个网络。循环上电并没有改变。我家只有Tradfri，所以没有别的可比之处。我混合了e27白色，e27颜色和GU10。我发现的唯一解决方案是硬重置灯泡并从头开始整个过程-遗憾的是这是不可持续的。

Conbee固件：264A0700
轻固件：1.2.214

很高兴为您提供诊断服务，但我需要将大部分房屋放回Tradfri网关，以便家人可以打开和关闭灯。我要留几盏灯。

kinsago 于 2019-10-13

我刚刚意识到这个问题可能还有一个有趣的补充。

几个房间配备了多个Tradfri GU10点，大多数房间都配有Hue Dimmer Switch，通过将它们添加到Phoscon应用程序的Hue Dimmer Switch组中而直接绑定到房间中的GU10。

仅与Hue Dimmer Switch直接绑定的GU10偶尔会下线，并且需要重新启动电源才能恢复在线状态。
没有与Hue Dimmer Switch直接绑定的GU10不会离线。

JBS5 于 2019-10-23

对我来说似乎并非如此。到现在为止，只有Hue Bulbs看起来相当有弹性。我拥有的所有IKEA设备（GU10，E14，FLOALT面板）和欧司朗设备（灯泡，灯带和菜杆）都失败了。尤其是Osram设备完全失效，关机后再开机无济于事。必须将它们卸下并修理，这对于这些设备来说是痛苦的。

peer69 于 2019-10-24

我花了几天的时间考虑用所有设备替换我的所有zigbee设备，因为在某些设备出现故障并且迁移到Conbee II记忆棒后也失败了，原因可能是zll-db有点损坏，因此安装KNX太昂贵了。然后，我采取了激进的方法从头开始设置所有内容。我重置了网关并修复了所有设备。对于宜家设备，这比以前更容易。过去，我不得不将它们移到网关附近，对其进行多次重置，使用触摸链接使它们响应-这次没有任何反应。我只是重置了灯泡，它们配对没有任何问题。尽管如此，为70台设备执行此操作还是很痛苦的，一些小米传感器使它比宜家的产品更加困难。但这使我已经认为我现在可能拥有一个更稳定的网络。一切都没有失败，但我会告诉您是否成功。

peer69 于 2019-10-28

自从更新了raspbee以来已经有一段时间了，我的旧版本在读取灯光温度方面存在问题，因此我决定更新为最新的固件和最新的deCONZ。只有2盏灯（OSRAM 73674）。几分钟后，使用最新的deCONZ，1盏灯（可能是随机的）失去了连接，我必须手动关闭然后再打开。我能找到的唯一能够读取温度并且不失光的版本是deconz-2.04.40-qt5.deb，它非常旧，但是可以用于我的基本用途。

danielocdh 于 2019-11-02

最近，宜家GU10单色对我来说也发生了很多事情。屁股有点疼。但是，节点对我而言不会变成红色，只会变灰。他们将对远程按钮按下做出反应，但不会通过Phoscon或HA做出反应。

ACrazyConcept 于 2019-11-03

当您通过遥控器控制deCONZ时，是否仍会更新灯光状态？

当deCONZ丢失了通往灯泡的路径时，通常会发生这种情况。灯仍在网络上，可以到达网关，并接收广播。但是，网关无法通过单播广播。解决方法是，您可以使用/groups命令而不是/lights ，因此deCONZ会发送广播。

我的小米窗帘控制器（这是ZigBee路由器）偶尔（每周一次）仍然遇到相同的问题。重新启动设备后，_Device Announment_会导致deCONZ重新学习路由。

这些路由问题是由于对Trådfri灯使用的路由发现的支持而引入的，因此2.04.40听起来不错。

ebaauw 于 2019-11-03

@ebaauw当一个灯不可用时，组命令对我有效，但仅在有限的时间内有效。此后，指示灯将保持打开或关闭状态，并且不再响应组命令。使用绑定的Hue Dimmer Switch（通过在Phoscon应用程序中将Hue Dimmer Switch配对时，将灯光添加到默认创建的组中来创建绑定）。

JBS5 于 2019-11-03

当您通过遥控器控制deCONZ时，是否仍会更新灯光状态？
当deCONZ丢失了通往灯泡的路径时，通常会发生这种情况。灯仍在网络上，可以到达网关，并接收广播。但是，网关无法通过单播广播。解决方法是，您可以使用/groups命令而不是/lights ，因此deCONZ会发送广播。

下次我将检查这些建议。但是是的，他们通常会回来，因为我在几分钟内切断了电源。顺便说一句，我使用宜家的“冰球”遥控器。

我的小米窗帘控制器（这是ZigBee路由器）偶尔（每周一次）仍然遇到相同的问题。重新启动设备后，_Device Announment_会导致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）。少数人没有，而且自几个月以来一直在线。从来没有一个人不可用。是否巧合。.您如何看待这个@ebaauw？

JBS5 于 2019-11-03

我的大多数GU10灯都绑定到Hue Dimmer Switch

这似乎不太可能。您是否已在deCONZ GUI的_Bind Dropbox_面板中从调光器开关到灯光创建了绑定？

请注意，ZigBee术语中的“绑定”是指：在设备的绑定表中创建一个条目，该条目指向要从绑定的集群发送命令的ZigBee地址。我认为您的调光器开关的（客户端！）_ OnOff_和_Level Control_集群绑定到了一个组（通过deCONZ REST API插件）。该组在ZHASwitch资源中的config.group 。接下来，将灯光添加到该组中。 ZigBee组更像是多播地址，所以说光已经订阅了该组消息可能更正确。

从理论上讲，我认为轻型固件可能有一个错误，导致它在处理通过组接收的命令时挂起。不过，我认为这不太可能。我要看看灯与RaspBee / ConBee的距离（在ZigBee网络上跳了几跳）和/或所有灯的硬件和固件版本是否相同。宜家似乎正在为其所有设备推出新的ZigBee 3.0（ZHA）版本。

ebaauw 于 2019-11-03

我的大多数GU10灯都绑定到Hue Dimmer Switch
这似乎不太可能。您是否已在deCONZ GUI的_Bind Dropbox_面板中从调光器开关到灯光创建了绑定？
请注意，ZigBee术语中的“绑定”是指：在设备的绑定表中创建一个条目，该条目指向要从绑定的集群发送命令的ZigBee地址。我认为您的调光器开关的（客户端！）_ OnOff_和_Level Control_集群绑定到了一个组（通过deCONZ REST API插件）。该组在ZHASwitch资源中的config.group 。接下来，将灯光添加到该组中。 ZigBee组更像是多播地址，所以说光已经订阅了该组消息可能更正确。

不，我没有在deCONZ GUI的de _Bind Dropbox_面板中创建绑定。

您是说在Phoscon应用程序中向这些组添加灯光不会在遥控器和灯光之间建立绑定吗？我以为是这样，因为当我的deCONZ docker容器或整个NUC处于脱机状态时，也可以使用相应的Hue Dimmer Switch切换添加的灯光。

JBS5 于 2019-11-03

好的，我现在没有反应了。它在deCONZ和Phoscon中均呈灰色。

它确实对远程命令以及当我在Phoscon中以“组”模式移动滑块时做出了反应，

当您通过遥控器控制deCONZ时，是否仍会更新灯光状态？

刚开始不是因为它是灰色的。

然后，我尝试在deCONZ中使用“重置选定的节点”，尽管几分钟后在deCONZ中不再具有群集单选按钮，但几分钟后它不再变灰。

仍然仅响应远程和组命令，但是现在更新了灯光状态。

一段时间后，它在Phoscon中再次变灰。

然后，我尝试切断电源几分钟。没帮助

ACrazyConcept 于 2019-11-09

今晚发生了一个有趣的情况：

Tradfri暖白色GU10灯之一已经关闭了几个小时。根据deconz的说法，与8个GU10（包括现在离线的）绑定的Hue Dimmer Switch可以打开/关闭离线GU10。够奇怪的，只有那个。
其他GU10不响应绑定的Hue Dimmer Switch。

使用其余API切换组将打开/关闭所有灯，包括离线GU10。

当GU10之前脱机时，绑定的Hue Dimmer Switch会打开/关闭组中的所有指示灯，包括根据离线状态下的GU10（根据deconz的说法，迟早或以后，离线GU10也会停止收听组命令）要么）。

这有用吗？

\编辑：通过VNC在deCONZ中此离线GU10的“名称”为空。

再次填写时，未设置（通常在Phoscon应用程序中从来没有这样做）：

还是黄色：

按“ 0”或“重置所选节点”不会使GU10重新联机。

编辑2 ：GU10脱机大约24小时后，GU10不再对绑定的Hue Dimmer Switch做出响应，如上所述。该组中的GU10灯现在都没有响应。 deCONZ GUI中的节点仍为黄色，但名称为灰色。
重新启动离线的GU10灯后，组中的所有8盏灯（包括一个离线的灯）都再次响应绑定的Hue Dimmer Switch。

@manup这种行为/情况与以前大不相同，也许这可以帮助找到原因？

JBS5 于 2019-11-12

我刚刚意识到这个问题可能还有一个有趣的补充。
几个房间配备了多个Tradfri GU10点，大多数房间都配有Hue Dimmer Switch，通过将它们添加到Phoscon应用程序的Hue Dimmer Switch组中而直接绑定到房间中的GU10。
仅与Hue Dimmer Switch直接绑定的GU10偶尔会下线，并且需要重新启动电源才能恢复在线状态。
没有与Hue Dimmer Switch直接绑定的GU10不会离线。

不幸的是，我的一架Tradfri GU10暖白色没有绑定色调调光开关，自昨天起就离线。

仍然想知道为什么没有几个GU10点（相同的whitewhite）离线。
\编辑：另外一个GU10上线了几个月，从昨天起就离线了。

JBS5 于 2019-11-22

上周末购买了Tradfri集线器，并将一个房间的GU10点配对。让我们看看接下来几周会发生什么。

JBS5 于 2019-12-04

在系统上添加了四个IKEA开关插座（用于圣诞节窗灯）后，系统中的随机灯开始无响应。每天至少需要对系统中的一盏灯重新通电。

我可以提供任何类型的日志或信息来简化故障排除吗？

tubalainen 于 2019-12-04

@tubalainen您说什么都不响应？他们自己是否需要响应才能重新启动？

JBS5 于 2019-12-04

@tubalainen您说什么都不响应？他们自己是否需要响应才能重新启动？

根据我的图片，它们被列为“在线”（未变灰），并且是网格的一部分，但是在Home Assistant（或通过phoscon）中切换时，什么也没有发生。为了让它们重新工作，我确实需要重新启动。

tubalainen 于 2019-12-04

在这方面有什么进展吗？ GU10灯变灰有点荒谬:(

我想我看到有人提到窗帘控制器或开/关开关。实际上，在我得到FYRTUR百叶窗的时候，问题变得更加严重。这也是我添加到网络中的第一个宜家按钮...我不...

ACrazyConcept 于 2019-12-05

我这里没有任何Tradfri开关墙壁开关或IKEA窗帘，确实有问题。

JBS5 于 2019-12-05

👍2

我在夏天遇到了这个问题。我的GU10会一直掉线。我将所有GU10升级到了最新的“测试”软件，并且已经运行了将近两个月没有问题。

上个周末，我添加了几个新的E27灯泡，现在我的几个GU10灯泡一直都在退货。

aherbjornsen 于 2019-12-05

我在夏天遇到了这个问题。我的GU10会一直掉线。我将所有GU10升级到了最新的“测试”软件，并且已经运行了将近两个月没有问题。
上个周末，我添加了几个新的E27灯泡，现在我的几个GU10灯泡一直都在退货。

您拥有哪些GU10灯泡和安装了哪些固件？

ReX1983 于 2019-12-05

上周末购买了Tradfri集线器，并将一个房间的GU10点配对。让我们看看接下来几周会发生什么。

当我使用Tradfri网关时，几乎每天都有灯泡无响应（Tradfri GU10白色光谱，第一代）。我切换到飞利浦Hue桥，问题似乎消失了，但是两周后，一个灯泡变得无响应（照常，重新通电可以解决问题）。

不确定为什么色调桥和Tradfri灯泡可以更好地工作，但是在我看来，真正的问题在于灯泡。

ReX1983 于 2019-12-05

我没有一个GU10，但仍然遇到了问题。

请告诉我如何处理日志等问题，以尝试解决此问题。
似乎是轻巧的（我在这里猜想），有些节点“入睡”并且在第一次尝试唤醒它们时没有唤醒？

当网格中有多个节点跃点时，这仅仅是一个问题吗？对我来说，到达蜂巢的跳数超过一跳是非常必然的。再次，只是一种感觉。还没有确定。

tubalainen 于 2019-12-06

我有8个GU-10，大约18个月大。其中之一曾经在那个时候变灰。它们和conbee棒子都在同一个房间里。我有3岁的980lm灯泡。从gw出发，经由gu 10跳得最远的那一个，可能每两周变灰一次。
@tubalainen可能有点问题。

在那变灰的人旁边，我有一个从来没有消失过的欧司朗。

Flurkmark 于 2019-12-06

👍1

是的， @ tubalainen可能是一个线索。实际上，我一直在将灰色的GU10放到电线上的灯座中，当添加新的灯光时，我会用它来恢复生命。但是，当我把它们放回原处时，它们又再次消失了。他们确实回来并不是100％一致的，但仍然可能是帮凶。

ACrazyConcept 于 2019-12-07

👍1

这是另一个潜在的线索。我从来没有过任何变灰的灯（在使用8个宜家灯的正常运行时间中，是一年多的时间），但是后来我将Home Assistant的deconz插件从3.8更新为3.9，两天后，我有两个GU10变灰，我恢复了该插件3.8版本的备份，此后一直没问题。奇怪的是3.8和3.9插件使用相同的deconz版本（如果更改日志已完成）。但是，即使在Phoscon中，灯具也难以接近。这一切都相当奇怪，但是我认为该插件的3.9版本发出了某种要求进行装饰的请求，这使IKEA灯不稳定。

PremiumUsername 于 2019-12-19

我不使用HA，但仍然遇到问题。我购买了一些ne GU10，现在更换了每盏变灰的灯不止一次。我更换的所有灯泡都没有再次变灰。可能是硬件问题，也许不是，但似乎我们很快将找不到解决方案。

peer69 于 2019-12-19

我也遇到类似的问题。一些光节点不响应命令而变成灰色。奇怪的是，如果我发送组命令，则同一灯光节点每次都能完美响应。

MikaelHoogen 于 2019-12-26

我也遇到类似的问题。一些光节点不响应命令而变成灰色。奇怪的是，如果我发送组命令，则同一灯光节点每次都能完美响应。

在说了几天/一周以上的时间之后，group命令是否继续工作？
以我为例：灯光迟早也会停止收听群组命令。

JBS5 于 2019-12-27

我也遇到类似的问题。一些光节点不响应命令而变成灰色。奇怪的是，如果我发送组命令，则同一灯光节点每次都能完美响应。
在说了几天/一周以上的时间之后，group命令是否继续工作？
以我为例：灯光迟早也会停止收听群组命令。

是的，随着时间的推移，它似乎也可以正常工作。但是我有什么错的理论。当光节点通过TRADFRI灯泡E27 WS蛋白石1000lm布线时，会出现问题。所以昨天我关闭了两个我的网络。从那时起，一切似乎都运转良好。

ScreenClip 4

MikaelHoogen 于 2019-12-28

我有TRADFRI灯泡GU10 WS 400lm，TRADFRI灯泡E14 CWS蛋白石600lm和TRÅDFRI灯泡E27 CWS蛋白石600lm。他们似乎不会造成任何麻烦。

MikaelHoogen 于 2019-12-28

这可能与较旧的Trådfri固件有关。较新的照明灯带有更新的固件，但是我不认为宜家没有为所有第一代照明灯发布更新的固件。我没有TrådfriGU10斑点，但是CWS bulb确实收到了固件更新。我的1000 lm可调光灯泡没有；我不确定白色光谱灯泡。

ebaauw 于 2019-12-28

这可能与较旧的Trådfri固件有关。较新的照明灯带有更新的固件，但是我不认为宜家没有为所有第一代照明灯发布更新的固件。我没有TrådfriGU10斑点，但是CWS bulb确实收到了固件更新。我的1000 lm可调光灯泡没有；我不确定白色光谱灯泡。

我的TRADFRI灯泡GU10 WS 400lm使用相同的固件2.0.022。他们似乎没有引起问题（但:)）

MikaelHoogen 于 2019-12-28

这可能与较旧的Trådfri固件有关。较新的照明灯带有更新的固件，但是我不认为宜家没有为所有第一代照明灯发布更新的固件。我没有TrådfriGU10斑点，但是CWS bulb确实收到了固件更新。我的1000 lm可调光灯泡没有；我不确定白色光谱灯泡。

我同意。宜家灯泡的第一个版本（在1. *固件上）具有一些软件/硬件错误，这些错误不会影响第二个迭代（在2. *上）。

可悲的是，宜家似乎不再支持原始版本，也不会提供任何固件更新。同时，不可能退还灯泡并更换新灯泡（我在英国尝试过）。

ReX1983 于 2019-12-28

这可能与较旧的Trådfri固件有关。较新的照明灯带有更新的固件，但是我不认为宜家没有为所有第一代照明灯发布更新的固件。我没有TrådfriGU10斑点，但是CWS bulb确实收到了固件更新。我的1000 lm可调光灯泡没有；我不确定白色光谱灯泡。
我同意。宜家灯泡的第一个版本（在1. *固件上）具有一些软件/硬件错误，这些错误不会影响第二个迭代（在2. *上）。
可悲的是，宜家似乎不再支持原始版本，也不会提供任何固件更新。同时，不可能退还灯泡并更换新灯泡（我在英国尝试过）。

我在1.3.009上安装了cws灯泡。它们似乎不会引起问题。

MikaelHoogen 于 2019-12-28

更新：

似乎其他宜家灯泡也正在引起麻烦。

这是我的宜家灯泡。到目前为止，造成问题的只有TRADFRI灯泡E27 WS蛋白石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面板的问题。

有趣！我看一下灯泡，看是否存在某种相关性。

看来我的节点之一再次受此问题影响。我的网络中仍然有一些IKEA节点，因此我将做一些测试以查看是否可以得出一些结论。

MikaelHoogen 于 2019-12-28

我有TRADFRI灯泡GU10 WS 400lm，TRADFRI灯泡E14 CWS蛋白石600lm和TRÅDFRI灯泡E27 CWS蛋白石600lm。他们似乎不会造成任何麻烦。

似乎在网格建立了一段时间之后，甚至其他IKEA设备也出现了问题，节点停止响应命令。甚至其他宜家节点也可能受到影响，在我看来，问题开始出现，然后将节点路由到宜家节点。

有计划开展任何活动来调查此事吗？解决此问题后，我将所有宜家设备移至我的色相网关。

MikaelHoogen 于 2019-12-31

节点停止响应命令。

您确定是这种情况吗？您是否通过嗅探ZigBee流量确认了这一点？其他节点是否不再对不通过网关的控制灯光的无线交换机做出反应？他们不再对组命令做出反应了吗？
以我的经验，问题在于网关不再知道到其他节点的路由，因此来自网关的单播命令永远不会到达其他节点。节点本身的响应很好，只是没有收到任何响应。

甚至其他宜家节点也可能受到影响，在我看来，问题开始出现，然后将节点路由到宜家节点。

（不是？）路由宜家节点以某种方式中断了网关到其他节点的路由和/或路由发现。

有计划开展任何活动来调查此事吗？

您必须询问德累斯顿电子技术支持。路由由RaspBee / ConBee固件（和deCONZ核心程序？）处理。 REST API插件对此无能为力。

ebaauw 于 2019-12-31

上周末购买了Tradfri集线器，并将一个房间的GU10点配对。让我们看看接下来几周会发生什么。

也许这还为时过早，但是29天前，我已经将所有Tradfri GU10（8x暖白色-1.2.214）从一个房间移到了Tradfri Hub，直到现在它们都没有反应。

JBS5 于 2019-12-31

也许这还为时过早，但是29天前，我已经将所有Tradfri GU10（8x暖白色-1.2.214）从一个房间移到了Tradfri Hub，直到现在它们都没有反应。

我希望如此。问题不是由单个制造商的设备引起的，而是由不同制造商的设备之间的交互引起的，它们对ZigBee标准的解释不同。这就是为什么大多数集线器/网关/桥仅支持自己的设备的原因。一个更有趣的实验是将Trådfri点连接到Hue桥或OSRAM网关。

同样，在单个房间中使用八盏灯可能会导致集线器与每个灯之间直接连接：所有单跳连接。路由问题仅在较大的网络中出现，并且其设备比邻居表中的条目更多（通常约20个）。和/或物理上超出集线器范围的设备。

ebaauw 于 2019-12-31

节点停止响应命令。
您确定是这种情况吗？您是否通过嗅探ZigBee流量确认了这一点？其他节点是否不再对不通过网关的控制灯光的无线交换机做出反应？他们不再对组命令做出反应了吗？
以我的经验，问题在于网关不再知道到其他节点的路由，因此来自网关的单播命令永远不会到达其他节点。节点本身的响应很好，只是没有收到任何响应。

我没有经验或设备来监听流量。您可能对问题的表现是正确的。我的节点一直都在响应组命令。问题是（如果我明白了）单播命令永远不会到达它的目的地。

只要我只发送组命令，一切似乎就可以很好地工作了。

甚至其他宜家节点也可能受到影响，在我看来，问题开始出现，然后将节点路由到宜家节点。
（不是？）路由宜家节点以某种方式中断了网关到其他节点的路由和/或路由发现。
有计划开展任何活动来调查此事吗？
您必须询问德累斯顿电子技术支持。路由由RaspBee / ConBee固件（和deCONZ核心程序？）处理。 REST API插件对此无能为力。

是的，我已经给他们发送了电子邮件，但是除了一些清单之外没有得到任何回应。

MikaelHoogen 于 2019-12-31

也许这还为时过早，但是29天前，我已经将所有Tradfri GU10（8x暖白色-1.2.214）从一个房间移到了Tradfri Hub，直到现在它们都没有反应。
我希望如此。问题不是由单个制造商的设备引起的，而是由不同制造商的设备之间的交互引起的，它们对ZigBee标准的解释不同。这就是为什么大多数集线器/网关/桥仅支持自己的设备的原因。一个更有趣的实验是将Trådfri点连接到Hue桥或OSRAM网关。
同样，在单个房间中使用八盏灯可能会导致集线器与每个灯之间直接连接：所有单跳连接。路由问题仅在较大的网络中出现，并且其设备比邻居表中的条目更多（通常约20个）。和/或物理上超出集线器范围的设备。

我这样做是为了确保它与旧版GU10的固件1.2.214不相关，在这里可能是很多原因（以及制作GU10新版本的可能原因）引起的。
也许与通过另一个路由器连接有关。

我还将考虑将其他GU10（也为warmwhite 1.2.214）灯与Tradfri Hub配对（也包括2de / 3楼的灯）

JBS5 于 2019-12-31

在这方面有什么进展吗？ GU10灯变灰有点荒谬:(
我想我看到有人提到窗帘控制器或开/关开关。实际上，在我得到FYRTUR百叶窗的时候，问题变得更加严重。这也是我添加到网络中的第一个宜家按钮...我不...

自上次发帖以来，我还没有在网络中使用fyrtur开/关开关，并且在那个时候没有辍学。可能是巧合...？

ACrazyConcept 于 2019-12-31

在这方面有什么进展吗？ GU10灯变灰有点荒谬:(
我想我看到有人提到窗帘控制器或开/关开关。实际上，在我得到FYRTUR百叶窗的时候，问题变得更加严重。这也是我添加到网络中的第一个宜家按钮...我不...
自上次发帖以来，我还没有在网络中使用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灯泡（第一代）也遇到了相同的问题。当我将所有灯泡移至顺化桥时，问题完全消失了。

顺便说一句-我仍然坚信Trådfri灯泡的第一代已被窃听，但是Hue桥对灯的处理方式有所不同（我注意到，有时当连接到Hue时，灯不同步一秒钟的时间-Trådfri从未发生过）。

ReX1983 于 2019-12-31

色相桥对灯的处理方式有所不同（我注意到，有时在连接到色相时，灯不同步一秒钟的时间-Trådfri从未发生过）。

在Hue设置中，灯光仅由Hue桥控制：无线开关和传感器将通知发送到桥，从而触发控制灯的规则。当向灯光发送命令时，网桥会预测灯光状态并预先更新其缓存。它定期轮询灯光以验证/更新缓存状态。

在Trådfri设置中，灯光直接由无线开关和传感器发出的命令控制。然后，指示灯将状态更新的报告发送到集线器。

当直接从（Trådfri）无线开关或传感器控制连接到Hue桥的灯时，您会看到一个延迟，因为Hue桥未在灯上设置属性报告。网络中的指示灯越多，延迟越长，因为轮询会循环通过更多的指示灯。

将Hue灯泡连接到Trådfri集线器并直接从（Trådfri）无线开关或传感器控制这些灯时，集线器状态将永远不会更新，因为Hue灯不进行属性报告，而Trådfri集线器也不进行轮询。

请注意，这些差异是在应用程序级别上，并且完全在REST API插件的控制之内。路由在ZigBee堆栈中处于较低级别。

ebaauw 于 2019-12-31

👍2

现在，我所有的IKEA路由器节点都移至我的色相桥。我的网络中仍然存在相同的问题。因此，我怀疑是由其他原因引起的。同样，它会影响已路由且没有直接链接到网关的节点。

MikaelHoogen 于 2020-01-01

现在，我所有的IKEA路由器节点都移至我的色相桥。我的网络中仍然存在相同的问题。因此，我怀疑是由其他原因引起的。同样，它会影响已路由且没有直接链接到网关的节点。

现在与色相桥配对的Tradfri灯也存在同样的问题？

@ebaauw当灯直接通过路由器连接到网桥时，还是仅在不直接连接到桥的情况下才出现路由问题？

JBS5 于 2020-01-01

现在，我所有的IKEA路由器节点都移至我的色相桥。我的网络中仍然存在相同的问题。因此，我怀疑是由其他原因引起的。同样，它会影响已路由且没有直接链接到网关的节点。
现在与色相桥配对的Tradfri灯也存在同样的问题？
我只有3个灯泡配对。但没有我注意到的问题。

@ebaauw当灯直接通过路由器连接到网桥时，还是仅在不直接连接到桥的情况下才出现路由问题？

在我的网络中，我的经验是丢失命令的问题正在影响通过其他节点而不是直接通过网关路由的节点。即使没有连接宜家灯泡，我现在也遇到同样的问题。

我有一个没有直接链接到网关的节点（1）。它没有对单播命令作出响应（或者如ebaauw所述，也许由于路由问题它们可能从未到达节点）。当我关闭节点（2）的电源时，它通过了节点（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应答。

在我的网络中，我的经验是丢失命令的问题正在影响通过其他节点而不是直接通过网关路由的节点。即使没有连接宜家灯泡，我现在也遇到同样的问题。

因此，对于路由问题，您需要一个足够大的网络以使设备不会出现在RaspBee / ConBee的路由表中。原因可能是因为设备数量超出了路由表的大小，或者是因为远程设备实际上不在RaspBee / ConBee的范围内，并且只能通过其他路由器访问。我想多跳会使问题变得更糟。

同样，这不是宜家的错，而是不同的制造商使用不同的，有些不兼容的方法进行路由发现。特别是在多跳路由中，RaspBee / ConBee固件只能解决很多问题。

我有一个没有直接链接到网关的节点（1）。它没有对单播命令作出响应（或者如ebaauw所述，也许由于路由问题它们可能从未到达节点）。当我关闭节点（2）的电源时，它通过了节点（1）的路由，并确实获得了到网关的直接路由，并开始正常工作。

再次，我担心细节丢失了，但是我可以想到会导致这种行为的多种情况。 RaspBee / ConBee希望将消息发送到node2或node1，没有收到确认，得出的结论是node2无法访问并将其从其邻居表中删除。该表现在有空间供新条目使用，该条目用于节点1。

ebaauw 于 2020-01-01

同样，这不是宜家的错，而是不同的制造商使用不同的，有些不兼容的方法进行路由发现。特别是在多跳路由中，RaspBee / ConBee固件只能解决很多问题。

在我看来，多厂商ZigBee平台的方法在设计上注定了失败，直到建立并遵循了更全面的标准。现在我仍然处于锁定状态，因为我不想使用多个网关，而这些网关可能无论如何都无法在我的环境中工作（例如，对于如果我卸下当前起作用的灯泡，网关无法直接到达的传感器）作为路由器）。

peer69 于 2020-01-01

在我看来，多厂商ZigBee平台的方法注定要失败

我当然希望不要，但这绝对是挑战。大小似乎很重要：如果您的网络足够小，您可能根本不会遇到这些路由问题。另外，如果网络的（地理）中心由兼容厂商的路由器组成，则网络边缘上一些兼容性较差的路由器可能无关紧要（因为它们没有通过路由到达其他设备）。

我确实用Hue灯泡更换了引起问题的OSRAM，Trådfri和inrr灯泡。我现在有104个节点，51个路由器和53个终端设备。路由器的2/3是色相灯。唯一无法访问（但仍在发送报告）的路由器是小米窗帘控制器。终端设备中有20个是Hue，20个小米，8个Eurotronic Spirit和5个宜家。 Eurotronic Spirit和IKEA Fyrtur经常引起我一些问题（它们被其父母赶出了家，但找不到新的父母-网关仍然无法到达，但仍在发送报告），其他似乎还不错。对于所有设备，通常可以通过关闭电源然后再打开电源来解决这种情况，但是有时需要在打开设备电源后再打开网络。

我一直在考虑不按供应商而是按房屋的地板或街道侧与背面侧分开网络。这是一项繁重的工作，我不愿意这样做，直到我更好地了解是什么导致了这些问题的细节以及哪些设置可能会阻止这些问题的发生。

ebaauw 于 2020-01-01

@ebaauw ，请考虑您在上面的帖子中所说的内容，考虑对deCONZ路由表的一种偏好会很有趣。我们是否可以考虑将“黑名单”路由器作为第一跳而不可取。如果您可以构建网络以包含足够的“好”路由器，那么第一跳将始终通过这些路由器，第二跳将到达网络中的所有其他设备。
那不是一个确定的解决方案，但可以允许更大的网络（地理和设备数量），同时始终通过“首选”路由器。

另一个想法：既然我们知道IKEA使用了哪些芯片（Silabs EFR32，壁虎引擎），并且（从网络上的各种来源得知）它们使用了Silabs提供的zigbee引擎，我们可以考虑采取两种措施。

我们分析了Silabs引擎进行路由的方式，并从中得出导致此问题的原因
我们基于相同的Silabs引擎构建了灯泡固件的自定义版本，修复了该问题并找出了OTA安装该固件的方法

两者都需要访问Silabs SDK，而我不需要。这里有人活跃吗？我不希望为包含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是我们的一部分;）

这超出了我目前的知识范围，坦率地说，我的野心-我这样做是出于业余爱好。我一直在玩XBee，看看是否可以编写ZigBee应用程序（我的最终目标是智能化百叶窗），但是我从未研究过ZigBee堆栈的较低层，在该层进行路由。

我同意，对我来说，这也是一种业余爱好，但是我希望有人对这些细节有更多的了解。

我一直在使用CC2530板做类似的事情，我打算对喷水灭火系统进行Zigbee化（我不能接受必须绕着花园手动打开/关闭某些喷水灭火：））我已经可以编译一个我的CC2530电路板的zigbee固件，它作为开/关灯加入了deCONZ网络。我打算使用的阀门具有闩锁机制，因此需要特定的信号来切换，因此我必须创建自己的固件...

djwlindenaar 于 2020-01-02

我们：不。我想，它必须在RaspBee / ConBee固件中实现。恕我直言，这不是一个坏主意，但是鉴于设备EEPROM和NVRAM的大小限制，我不知道这有多可行。 @manup ，您怎么看？

固件中的Zigbee堆栈具有一个参数，可根据其质量（RSSI / LQI）来控制是否应使用路由而不是直接链接，因此该参数已经可以很好地工作并且经过多年的调整。

另一条路径可能是控制所有设备的路由表的更通用的方法。

注意：您可以通过选择查询路由器的路由表并按R键，下一跳路由将显示为蓝色。

当前，当Zigbee网络打开时，由于Mgmt_Permit_Joining_req是作为广播发送的，因此所有路由器都可以成为父节点。但是，如果我们仅以单播方式将此请求发送到某个路由器，则新设备只能通过该设备加入。这对于经常紧贴其父母的小米终端设备可能很有用。对于路由器等其他连接设备，例如Philips Hue终端设备，这没有太大帮助，因为它们可以自由选择新的父项和路由。

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 Quality Request_和_Link Quality Response_消息，报告邻居表。这是否意味着到节点的未涂成蓝色的线是“传入”路由？

ebaauw 于 2020-01-02

@manup ，确实是一个有趣的可视化

一个灵丹妙药可能正在使用源路由

好吧，我想这值得一试。在我看来，在我的网络中，受影响最大的IKEA灯是与协调员距离较远的灯。我一直怀疑与路由相关的问题导致了问题，如@ebaauw所述。
我愿意为您测试这样的事情。虽然，我必须承认失去连接不是很可靠，所以测试可能很困难。

我更多地考虑了协调器的选择是否要为第一跳选择哪个路由器。如果我们能找到与IKEA设备配合使用的路由器（也许是IKEA路由器），则将所有数据包路由通过这些路由器应该会使功能更强大。不知道您是否可以欺骗路由发现过程以使其首选第一跳使用某个路由器，但是您可以对此发表评论， @ manup

djwlindenaar 于 2020-01-02

注意：您可以通过选择查询路由器的路由表并按R键，下一跳路由将显示为蓝色。
酷，我不知道那个。有GUI支持的所有键/命令的概述吗？查询下一个节点之前是否可以还原蓝线？ RaspBee / ConBee本身似乎不起作用？

如果有人想列出所有关键组合以及他们的工作，我很乐意清理它并编写一个Wiki页面。

dandrzejewski 于 2020-01-02

酷，我不知道那个。有GUI支持的所有键/命令的概述吗？

请求节点描述符= 1
请求功率描述符= 2
请求Nwk地址= 0
请求路由表= R
请求Mgmt假= L （带有重新加入，请勿与inrr灯一起使用！）
请求活动端点= 7
请求简单描述符= 8
刷新= F5 / Cmd-R
删除= Delete / Backspace
网关设备秒数= A （不是很有用）

查询下一个节点之前是否可以还原蓝线？

尚未，这只是查看路线的快速又肮脏的东西:)
也许添加另一个像Shift-R这样的键来清除节点的路由很有用？

RaspBee / ConBee本身似乎不起作用？

不幸的是RaspBee I / ConBee我不支持相关的ZDP命令，它可以与ConBee II一起使用。

路由表与邻居表是否不同？嗅探，我只看到ZDP链接质量请求和链接质量响应消息，报告邻居表。

这是两个分离表，通常路由表仅保存到无法直接访问且受邻居表（1跳节点）约束的节点的路由。

对于在邻居表中（且信号较强）的节点，不需要路由发现。邻居表本身主要使用1跳NWK链接状态命令构建。

这是否意味着到节点的未涂成蓝色的线是“传入”路由？

非蓝线（绿色/橙色/黄色）仅表示1跳邻居表。蓝线是到某个目标的出站路由，并且在当前视图中仅表示下一跳（不是完整的路由），目标NWK地址未显示，但是可能会有调试打印。

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灯泡E27 CWS蛋白石600lm上。借助此功能，我可以看到E27灯泡通过了GU10灯泡。我关闭了所有GU10的电源，就像魔术一样，E27重新开始工作。

因此，很明显，路由槽Innr和宜家正在引起问题。我已经开始将Innr och IKEA灯泡移至我的色相网关。 philips灯泡似乎是好的路由器，不会引起问题。

MikaelHoogen 于 2020-01-04

因此，我在客厅里重新放置灯光时做了一些实验。我卸下了两个路由器，然后重新放置了一个灯。瞧，一盏灯已经消失了，但是还没有完全消失。它的行为与我偶尔看到的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

因此，我在客厅里重新放置灯光时做了一些实验。我卸下了两个路由器，然后重新放置了一个灯。瞧，一盏灯已经消失了，但是还没有完全消失。它的行为与我偶尔看到的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

我想我需要给自己一个Zigbee嗅探器，以弄清正在发生的事情。

之后，它又停止工作了，这次更加持久了。

djwlindenaar 于 2020-01-04

0xA7状态是什么意思..？
看到这里： https :

感谢那！不知何故，这就是我所期待的...

djwlindenaar 于 2020-01-04

😄1

我试图将TRÅDFRI灯泡GU10 WS 400lm（7个灯泡）与飞利浦Hue桥配对。网络上的其他几个灯泡不可用，TRÅDFRIGU10 WS 400lm灯泡的行为与Deconz相同，但对组命令的响应却对单播没有响应。

TRÅDFRI灯泡GU10 WS 400lm似乎有某种问题。如果是独立灯泡或所有灯泡都不工作，我将做一些测试。

MikaelHoogen 于 2020-01-07

现在我做了一些测试。我的结论是，实际上是个别灯泡导致网络无法响应。顺化桥上立即出现了阿尔蒙斯，当我关闭它们后，事情又开始恢复正常。因此，在7个灯泡中，有3个受到了影响。如果发现一些新问题，我将报告。

MikaelHoogen 于 2020-01-07

@MikaelHoogen ，您拥有哪个版本的灯泡和固件？

ReX1983 于 2020-01-07

我已经在去年半年的宜家，HUE和DeCONZ网关的v1 E27 WS 980lm，GU10 WS 400lm，E27 CWS 600lm，E15 WS以及所有3个FLOALT面板上看到了此问题。
我坚信这是硬件问题。哪个节点死亡是完全随机的。
在挪威，所有电子产品均享有2年保修。会尝试打开一张车票，听听他们在说什么。
关于浮动。几个月前，宜家正在对他们进行清仓拍卖。也许那是为了摆脱所有v1？
有人看到过FLOALT v2吗？（也许使用sy5882驱动程序？）

olemr 于 2020-01-08

我已经在去年半年的宜家，HUE和DeCONZ网关的v1 E27 WS 980lm，GU10 WS 400lm，E27 CWS 600lm，E15 WS以及所有3个FLOALT面板上看到了此问题。
我坚信这是硬件问题。哪个节点死亡是完全随机的。
在挪威，所有电子产品均享有2年保修。会尝试打开一张车票，听听他们在说什么。
关于浮动。几个月前，宜家正在对他们进行清仓拍卖。也许那是为了摆脱所有v1？
有人看到过FLOALT v2吗？（也许使用sy5882驱动程序？）

这也是我一段时间以来一直在试图说的话。我只有Trådfriv1灯泡有问题。飞利浦Hue桥可以帮助您，但仍然有时会无法访问节点。

ReX1983 于 2020-01-08

几天前，我决定用新版本（暖白色）替换所有12个IKEA GU10灯泡。
这使这个问题更加严重。现在也失去了色相GU10的白色氛围和色相E14的色彩。

ACrazyConcept 于 2020-01-13

我从一开始就使用deConz和IKEA灯。我的网络中大约有70个节点。其中大多数是宜家灯。我也没有几个Philips Hue（4盏灯）和一个Osram。传感器我没有宜家运动，而小米运动传感器很多。

我已经使用此设置运行了一段时间，没有一天没有其他灯卡住，所以我需要重启电源。我的妻子不高兴，我也不。我非常接近抛弃所有Zigbee设备，只是去普通的老式学校灯光。就是行不通。非常失望。我想知道其他人是否在使用纯飞利浦或欧司朗灯时也会遇到相同的问题，还是只是宜家？

donnib 于 2020-01-16

我从一开始就使用deConz和IKEA灯。我的网络中大约有70个节点。其中大多数是宜家灯。我也没有几个Philips Hue（4盏灯）和一个Osram。传感器我没有宜家运动，而小米运动传感器很多。
我已经使用此设置运行了一段时间，没有一天没有其他灯卡住，所以我需要重启电源。我的妻子不高兴，我也不。我非常接近抛弃所有Zigbee设备，只是去普通的老式学校灯光。就是行不通。非常失望。我想知道其他人是否在使用纯飞利浦或欧司朗灯时也会遇到相同的问题，还是只是宜家？

通过查看所有在该线程中存在完全相同问题的人，deconz的制造商无法弄清楚IKEA灯的问题是什么，而且看起来像是IKEA固件问题。

即使使用IKEA集线器，许多用户也遇到类似的问题。因此，我想这不是与deconz相关的独特问题。但是，如果有人可以解决此问题，请“修补/找到解决方法”，那就是这里的家伙！ <3

我对家庭和设置都有完全相同的问题。

tubalainen 于 2020-01-16

👍1

令人遗憾的是：（尤其是即使他们今天出售的新产品仍然存在这些问题。我只是不理解。我是2017年的人，所以您希望他们现在已经解决了该问题。我将不得不考虑删除整个问题@manup之前曾说过，这是设备固件中的问题，所以只有IKEA可以解决此问题，因为他们还没有这样做，所以没有希望。

donnib 于 2020-01-16

Deconz版本2.05.69
Conbee II固件264A0700

它不是100％完美，我注意到的辍学者是E27宜家（Rev1）灯泡。
当我在飞利浦Hue桥上安装这些宜家灯时，它们坚如磐石，因此我很可能将它们移回Hue，并保留Zigbee网格纯CC2531（路由器固件）和小米传感器。
我也有一个Innr灯泡（E14）和一个SP120，但对于Deconz来说还是可以的。

jtebbens 于 2020-01-16

我正在使用Home Assistant和Deconz来控制约20个宜家灯泡（以及许多其他传感器）。灯泡主要是GU10，它们按3个点归为一个灯。

我已经使用此设置超过15个月了，自今年夏天以来，我遇到了一个或多个单个灯泡被卡住并需要重新启动，甚至被卸下并重新添加到Zigbee网络的问题。这始终是在HASS的灯光组中定义的GU10。

几周前，我在Phoscon中为灯光创建了分组，并开始在HASS中引用这些分组。

在那之后，我再也没有遇到灯泡被卡住并需要重启的问题。我看到的唯一问题是，一次关闭所有室内照明灯时，整个Phoscon / Deconz组有时仍保持打开状态。

对我来说，这似乎是Deconz API的问题，并且可能会快速连续处理多个灯泡。

aherbjornsen 于 2020-01-16

👍4

我也遇到了宜家设备（灯泡以及最近的Symfonisk遥控器）无法使用并需要与deCONZ重新配对的问题。我相信这些问题已经解决了6个月左右。添加的数量不多，我认为最近发生的更多。我没有GU10灯泡，只有各种E27和E14（以及各种遥控器）。似乎某些设备更容易掉线（可能取决于它们的啮合或类似方式）。从最新的FW / Phoscon / deCONZ到Conbee I，我大约有20台设备，最大射程为5 m。

mvjt 于 2020-02-01

我也遇到了宜家设备（灯泡以及最近的Symfonisk遥控器）无法使用并需要与deCONZ重新配对的问题。我相信这些问题已经解决了6个月左右。添加的数量不多，我认为最近发生的更多。我没有GU10灯泡，只有各种E27和E14（以及各种遥控器）。似乎某些设备更容易掉线（可能取决于它们的啮合或类似方式）。从最新的FW / Phoscon / deCONZ的Conbee I起，我大约有20台设备，最大射程为5 m。

尝试Deconz版本2.05.69。宜家，客栈和小米对我来说很稳定

jtebbens 于 2020-02-01

我有类似的问题和票证打开https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

可以说，当降级到2.05.67版本时，我的网络比以往任何时候都更加稳定。有几个灯泡进入反应迟钝的状态，但两个灯泡仍然可以使用。昨天一切都按预期进行。

所有可能的部分混合在一起似乎是一个问题，当然很难找到。但是，deconz版本似乎是拥有或没有稳定解决方案的主要部分。

我也遇到了宜家设备（灯泡以及最近的Symfonisk遥控器）无法使用并需要与deCONZ重新配对的问题。我相信这些问题已经解决了6个月左右。添加的数量不多，我认为最近发生的更多。我没有GU10灯泡，只有各种E27和E14（以及各种遥控器）。似乎某些设备更容易掉线（可能取决于它们的啮合或类似方式）。从最新的FW / Phoscon / deCONZ的Conbee I起，我大约有20台设备，最大射程为5 m。
尝试Deconz版本2.05.69。宜家，客栈和小米对我来说很稳定

将尝试以及

几周前，我在Phoscon中为灯光创建了分组，并开始在HASS中引用这些分组。

PeterRemnemark 于 2020-02-01

因此，我终于有了嗅探器的硬件，并且还对Wireshark进行了一些破解，以显示所有ieee802.15.4地址的名称（这使读取正在发生的事情变得容易得多）。

无论如何，我对zigbee的知识不是很强，所以我可能会问一些愚蠢的问题。但是，我一直在浏览一些嗅探日志，希望我们能看到一些可以解释宜家灯片状行为的东西。

请参阅下面的日志。这看起来像是“正常”行为吗？涉及的两个灯都是宜家ligths。首先，DeConz向“车库”发送请求，并通过“ Zolder”进行路由。然后，“ Zolder”尝试将其传输到“ Garage”，但这似乎失败了（为什么？），并且非常连续地重试了20次（大多数都在3 ms内）。最后，“ Zolder”放弃，并将链接故障发送回DeConz。

重试传输是否应该如此激进？

另外：我注意到DeConz很高兴一直通过Zolder向Garage发送请求，尽管链接显然失败了。当Garage不在Zolder的“链接状态”报告中时，DeConz甚至会执行此操作。另外，如果有时车库出现在Zolder的“链接状态”报告中，则传入和传出的成本均为7。实际上，从车库到DeConz的路线不是通过Zolder ...
为什么即使在出现链接失败消息后，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文档（宜家基于Silabs芯片）。
显然，重试行为与文档中所述完全相同。

这就留下了一个问题，为什么DeConz坚持使用这条路线。链接成本很高，有链接失败的答复，并且仍然使用该路由。为什么..？
（还有更好的路线可用...）

djwlindenaar 于 2020-02-02

👍5

非常有用的见解@djwlindenaar，尽管我无法在此级别为您提供帮助。这证实了我的怀疑。我拥有一个不错的工作网络（软件版本已降低），直到意外断电，整个房子都被夷为平地。

之后，我又回来了，以为我又遇到了糟糕的路线。

另一件事。即使实际设备不响应，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]

但是对车库的下一个请求再次通过Zolder发送

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

我不会对此行为与宜家的轻巧行为有任何关系感到惊讶。

@manup ，您可以对此发表评论吗？您关于源路由会有所帮助的说法确实很有道理。
另外，我希望使用“路由记录”中的信息来更新DeConz的路由表可能已经是一个很大的改进...
或者，我们需要弄清楚为什么DeConz希望继续使用报告链接问题/相比于替代路由而言成本高的路由。

djwlindenaar 于 2020-02-05

👍1

另一个观察结果...上面数据包中的两个中继设备都是小米插头。从未询问他们链接质量。为什么？
难道DeConz使用链路质量响应中的信息来构建其路由表，因此忽略了非常有效的路由器？通过良好的链接质量，可以连接到我一些不愉快的宜家灯...

djwlindenaar 于 2020-02-05

是否只看到宜家设备的这种行为或忽略最佳路线的一般行为？我猜你有相当数量的宜家设备吗？

PeterRemnemark 于 2020-02-05

我不确定，我需要检查一下。好问题。

我确实有很多宜家灯泡。

在我看来，这确实解释了我们在无法使用宜家灯时看到的大部分行为。尽管目前仅是假设，尚待验证。

djwlindenaar 于 2020-02-05

查看其他几条路线，我发现相同的行为。

我只看到小米设备没有被其他所有品牌的链路质量要求。我想这是某种黑名单。

其他路由行为示例：

从DeConz，始终：
DeConz --> WC Lamp --> Badkamer Ledstrip

通常在多对一路由请求后返回路由更改。请注意，从地理角度来看，所有这些都是有道理的...
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到Garage不会：
DeConz --> Zolder Noord Lamp --> Garage总费用：12（基于从DeConz到Zolder Noord Lamp的进货成本）

@manup ，您能详细说明所使用的路线成本算法吗？为何上述解释有意义？

djwlindenaar 于 2020-02-06

今天进行更多分析...
在我以前的文章中，您已经看到我的车库灯穿过我的Zolder灯。两个宜家灯泡。从Zolder到Garage的无线电链路就在它可以到达的边缘，因此经常会失败。

今天，尽管车库灯可以响应组命令，但不能响应单播命令。实际上有时候是这样，有时不是。对于已阅读/对此线程有贡献的人员，应该熟悉这种行为。

我可以在嗅探日志中找到它。有时Zolder灯可以与Garage通信，有时则不能。每当Zolder light无法与Garage通信时，它都会报告以下内容：

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开始寻找另一条到达Garage的路线，但这不会发生。下一个发送到Garage的数据包再次通过Zolder路由。对我来说，这是一个必须解决的错误。
车库灯的下一个数据包由Zolder灯接收，但是该灯甚至没有尝试将其发送到车库。也许这是IKEA固件的不良行为，但是问题的根本原因是DeConz拒绝寻找替代路线。
我认为，如果某条路由长时间不可用，则车库灯可能会比802.15.4协议更高级别的ACK饿死，这可能会导致固件断开甚至崩溃。我同意不应这样做，但根本原因是DeConz拒绝寻找通往车库灯的新路线。

今天，我做了一个实验，让DeConz找到通往车库灯的另一条路线，因此我从Zolder灯上断开了电源，看了看嗅探日志。经过几次尝试，DeConz意识到Zolder已经离开并继续寻找通往Garage的替代路线。接下来，我重新连接Zolder，并在Zolder也宣布存在之后，找到了一条新路线。 DeConz尚未（尚未）恢复通过Zolder路由Garage。

有趣的是，在新情况下，DeConz现在直接与Garage light对话，而中间没有路由器。
Zolder现在可以通过其他2个路由器通过一条路由到达（尽管显然DeConz可以直接到达），所以在我看来，DeConz路由固件中已装满一些表（邻居表？）。

也许这与拒绝创建新路由以应对失败的路由有关。

@manup ，如果您对以上帖子发表任何评论，我将不胜感激。或者至少让我知道如何为解决方案做出贡献（除了寻找根本原因之外）。

我想帮助解决这些问题，因为它们使我感到困扰。如果您可以访问固件源代码，我可以直接提供帮助（即使它不是开源的）。我不介意以这种方式帮助德累斯顿电子公司:)

djwlindenaar 于 2020-02-09

👍13 ❤5

做得好！ 💪🏼
希望我们能引起开发人员的注意以解决此问题。看来您的设置和流程都不错，因此可以很“轻松”地验证修订。
现在，我了解了我所看到的被称为“自我修复”的行为以及为什么有些灯泡突然起作用了。

PeterRemnemark 于 2020-02-09

不错的工作@djwlindenaar，我希望@manup可以看看这个。

Webserve 于 2020-02-16

@manup有何评论？

donnib 于 2020-02-18

感谢您的参与和工作。我有20个宜家灯泡更新固件和一岁的旧玩具。从一开始我就经历了水滴冻结或灯泡丢失，但并不太频繁。随着后来的deconz更新，情况变得更糟。我检查了我的网络在2.4打包环境中对其进行了优化。静止的灯泡每天都会掉落，使按钮或传感器仍然通过这些灯泡进行布线，因此不会发送任何数据移动，从而使按钮或传感器失效。我需要重新启动电源，使传感器再次可用，因为灯泡开始重新布线。希望这能引起更多关注。真令人沮丧。

realwax 于 2020-02-23

另一个观察结果...上面数据包中的两个中继设备都是小米插头。从未询问他们链接质量。为什么？
难道DeConz使用链路质量响应中的信息来构建其路由表，因此忽略了非常有效的路由器？通过良好的链接质量，可以连接到我一些不愉快的宜家灯...

对于小米设备，邻居表（又名ZDP Mgmt_Lqi_req）的查询被禁用，因为它们恰好在一段时间后不响应这些查询，并且我怀疑固件中的错误可能会触发某些无效状态或更糟。

因此，限制某些请求的主要驱动力是防止终端设备固件中的错误并密切模仿相关的供应商网关行为，一些调查结果可以在https://github.com/dresden-elektronik/deconz-rest中找到

附带说明一下，邻居表查询仅用于构建可视化网格表示，而不会影响网络操作或路由表。

manup 于 2020-02-23

因此，我终于有了嗅探器的硬件，并且还对Wireshark进行了一些破解，以显示所有ieee802.15.4地址的名称（这使读取正在发生的事情变得容易得多）。
无论如何，我对zigbee的知识不是很强，所以我可能会问一些愚蠢的问题。但是，我一直在浏览一些嗅探日志，希望我们能看到一些可以解释宜家灯片状行为的东西。
请参阅下面的日志。这看起来像是“正常”行为吗？涉及的两个灯都是宜家ligths。首先，DeConz向“车库”发送请求，并通过“ Zolder”进行路由。然后，“ Zolder”尝试将其传输到“ Garage”，但这似乎失败了（为什么？），并且非常连续地重试了20次（大多数都在3 ms内）。最后，“ Zolder”放弃，并将链接故障发送回DeConz。
重试传输是否应该如此激进？
另外：我注意到DeConz很高兴一直通过Zolder向Garage发送请求，尽管链接显然失败了。当Garage不在Zolder的“链接状态”报告中时，DeConz甚至会执行此操作。另外，如果有时车库出现在Zolder的“链接状态”报告中，则传入和传出的成本均为7。实际上，从车库到DeConz的路线不是通过Zolder ...
为什么即使在出现链接失败消息后，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

您是否还有一个完整的命令包，它是事先从协调员发送到宜家灯的？如果发现路由位已设置，将会很有趣。

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！您提到了Conbee II。此修复程序还将对Conbee I起作用吗？

JBS5 于 2020-02-23

是的，我只有ConBee I和RaspBee使用的堆栈源。同样的问题，我将烹饪新的固件版本进行测试，直到星期二。如果至少可以解决IKEA路由问题，获得一些反馈将很酷。

请注意，还有其他无法解决的问题，例如宜家灯泡完全静音，甚至听不到集体演员的讲话。

manup 于 2020-02-23

意外关闭了此问题...重新打开。很高兴我们在此方面取得进展。

我猜@djwlindenaar是能够在新固件发布后给出一些反馈的人，因为这需要嗅探硬件吗？

JBS5 于 2020-02-23

您是否还有一个完整的命令包，它是事先从协调员发送到宜家灯的？如果发现路由位已设置，将会很有趣。

我不确定我是否理解您的问题。您在寻找什么包装？以及哪盏灯（车库或Zolder）？

djwlindenaar 于 2020-02-23

是的，我只有ConBee I和RaspBee使用的堆栈源。同样的问题，我将烹饪新的固件版本进行测试，直到星期二。如果至少可以解决IKEA路由问题，获得一些反馈将很酷。
请注意，还有其他无法解决的问题，例如宜家灯泡完全静音，甚至听不到集体演员的讲话。

我一定会测试一下。尽管可能要花一些时间才能得出结论，因为有时很长一段时间都没有问题...

我当时在想，也许有某种事情触发了完全保持沉默的行为。我上周发生了这种情况，但还没有时间浏览嗅探器日志。

我在Raspbee上。

djwlindenaar 于 2020-02-23

是的，我只有ConBee I和RaspBee使用的堆栈源。同样的问题，我将烹饪新的固件版本进行测试，直到星期二。如果至少可以解决IKEA路由问题，获得一些反馈将很酷。

让我们知道，尽管没有进行任何嗅探，但我有很多这个问题可以测试。

请注意，还有其他无法解决的问题，例如宜家灯泡完全静音，甚至听不到集体演员的讲话。

您是否提到软件（deconz）报告并设置状态但灯泡本身不响应或更改状态的问题？如果我们确定路由问题，则问题的严重性可能不会相同。

感谢冷杉对此的关注，深表感谢！

PeterRemnemark 于 2020-02-23

是的，我只有ConBee I和RaspBee使用的堆栈源。同样的问题，我将烹饪新的固件版本进行测试，直到星期二。如果至少可以解决IKEA路由问题，获得一些反馈将很酷。
请注意，还有其他无法解决的问题，例如宜家灯泡完全静音，甚至听不到集体演员的讲话。

谢谢manup！我将在可用的第二个版本升级到新的固件并提供更新。

tubalainen 于 2020-02-23

这个问题是否也可能与控制宜家Fyrtur百叶窗有关？

olemr 于 2020-02-23

另一个对我来说似乎很奇怪。 @manup ，这也可能是个问题吗？

我看到很多这样的序列。我开始研究此问题，因为这是houtlamp停止响应之前的最后一次通信。 DeConz配置2个属性报告项，几乎同时请求组成员资格。在de DeConz日志中，如下所示。

我想知道选择序列号是否存在错误，或者是否允许（我不知道），并且此行为触发了Tradfri固件中的错误。有一个编号为215的请求和两个编号为216的请求。是否可能是我们存在某种竞争状况，tradfri固件对请求的处理导致其内存泄漏或由于两个请求而挂断几乎同时使用相同的数字？ Shoud DeConz有两个请求具有相同的序列号？

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

确实，在短时间内序列号不应该相等，我将检查代码，好像缺少增量。

这是ConBee II的第一个测试固件

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

现在，将其移植回ConBee I / RaspBee固件，将很快上线。

manup 于 2020-02-24

👍3

这是带有路由错误修复的ConBee I和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并等待？这是Beta固件吗？

MattL0 于 2020-02-25

主题略有偏离：Trådfri调光器的新固件，将其升级到ZB3。交叉引用＃2485，调光器会遇到相同的问题...我希望下一个旧型号的运动传感器...

ebaauw 于 2020-02-25

这是带有路由错误修复的ConBee I和RaspBee的测试版本。
希望它会带来一些改进，以便在发生错误时发现新路线。
对于测试，我认为如果它只运行几天/几周会很好，我们将看看灯光是否仍然停止响应单播。在这种情况下，请尝试使指示灯仍然对组命令作出反应或完全静音。
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

谢谢@manup ，刚刚安装了它。让我们看看它会带来什么。

尽管我希望这会带来一些改进，但是您对DeConz固件忽略记录的路由（由于鬃毛到一对路由）的感觉如何？总的来说，我已经看到记录的路由比DeConz固件所使用的路由更具逻辑性。
尽管我可以想象启用源路由是一项艰巨的任务，但DeConz固件仍可以（应该？）使用路由记录数据包中的信息将第一跳更新为设备。也许只是检查到协调器的最后一跳是否与路由表中存储的内容匹配，否则，请使路由表中的条目无效。我不确定是否可以用记录的路由中的最后一跳替换条目，因为沿途的设备可能会忽略该信息，但是至少它可以通过DeConz固件为该节点启动新的路由发现。

你怎么看待这件事？

djwlindenaar 于 2020-02-25

我已经在raspbee上安装了固件（我有73个节点，主要是ikea），它将报告结果。

donnib 于 2020-02-25

确实，在短时间内序列号不应该相等，我将检查代码，好像缺少增量。

@manup ，也许可以帮助您查明问题，今天我又看到了这个问题。似乎与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

这是带有路由错误修复的ConBee I和RaspBee的测试版本。
希望它会带来一些改进，以便在发生错误时发现新路线。
对于测试，我认为如果它只运行几天/几周会很好，我们将看看灯光是否仍然停止响应单播。在这种情况下，请尝试使指示灯仍然对组命令作出反应或完全静音。
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF
谢谢@manup ，刚刚安装了它。让我们看看它会带来什么。
尽管我希望这会带来一些改进，但是您对DeConz固件忽略记录的路由（由于鬃毛到一对路由）的感觉如何？总的来说，我已经看到记录的路由比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到Garage的下一次通信是：

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

确实，在短时间内序列号不应该相等，我将检查代码，好像缺少增量。
这是ConBee II的第一个测试固件
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_R21_0x26520700.bin.GCF
现在，将其移植回ConBee I / RaspBee固件，将很快上线。

该固件不适用于我。它显示我所有的设备都已加入，但没有建立网格。 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

该固件不适用于我。

同样，Rasperry Pi 4B，deCONZ 2.05.74，ConBee II。小型测试网络，带有Trådri中继器，Trådfri插头，XBee，Trådfri调光器，2个Trådfri运动传感器（新旧）以及Trådri开/关开关。网关似乎没有从任何设备发送或接收任何流量。在系统日志中看到USB断开连接。闪回4A后，一切再次变得笨拙。
日志文件

ebaauw 于 2020-02-25

刚刚再次闪烁以进行测试：

GUI中没有任何行（让它运行15分钟）
USB连接似乎稳定
UBISYS C4和D1开关仍然有效
Tradfri按钮不

cs42 于 2020-02-25

@ebaauw日志显示协调器仅看到此版本的两个邻居。

也许是网络规模。我目前在这里只有40台设备。此固件版本还有其他两个更改，可能是原因：增加的消息缓冲区大小（据我所知，超出顶部会稍稍减小）和稍低的TX功率设置。

我准备删除这些设置的另一个版本，看看效果是否更好。

您使用USB延长线，还是直接连接了ConBee II？

manup 于 2020-02-25

对我来说，它可以在Raspbee上正常工作...

djwlindenaar 于 2020-02-25

在RaspBee和ConBee 1上，新版本中仅包含Route修复程序（不同的固件）。

manup 于 2020-02-25

日志显示协调员仅看到此版本的两个邻居。

是的，两个终端设备在GUI中显示为邻居。 Kinda很奇怪，因为他们在降级ConBee II固件后显示已连接到另一个路由器。

您使用USB延长线，还是直接连接了ConBee II？

自从我知道它以来就直接连接了它。连接到Pi上的USB-2端口，并将XBee连接到另一个USB-2端口； USB-3上没有任何内容。除将ConBee II配置为路由器（请参阅＃2463）外，连接一直稳定。

在RaspBee和ConBee 1上，新版本中仅包含Route修复程序（不同的固件）。

还没有尝试过。将不得不等到以后...

ebaauw 于 2020-02-25

我看到很多配置报告数据包。经过一番搜索后，似乎每隔半小时就会定期发送一次。这些配置报告请求定期重复的原因是什么？
@ebaauw ，我是否正确记得您对宜家协调员的行为进行了许多此类调查？它也这样做吗？

我注意到de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

djwlindenaar 于 2020-02-26

我发现有关DeConz的路由行为的另一点证据忽略了多对一的路由记录。这导致一些路由器不得不以“老式”的方式弄清楚路由。
（请注意，我在数据包117130中存在一些干扰：：wink :)

根据DeConz的说法， badkamer ledstrip的路线以On/Off light 36 ，这显然不知道如何到达那里。因此，它开始了一条路线发现，并最终发现（几乎没有，我可以）到达ledstrip本身。返回路径通过Gang 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）一次只能检查一件事。

manup 于 2020-02-26

每次尝试更新到最新固件时，都会出现此错误。有什么提示吗？
rich710 @ RichHassPc01 ：〜$ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13（c）德累斯顿电子技术有限公司
重新启动设备/ dev / ttyACM1（ConBee II）
deCONZ固件版本26490700
R21B18引导程序
版本：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，但是当flasher尝试重启我的ConbeeII时，我仍然陷入困境。
rich710 @ RichHassPc01 ：〜$ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
rich710的[sudo]密码：
GCFFlasher V3_13（c）德累斯顿电子技术有限公司
重新启动设备/ 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）德累斯顿电子技术有限公司
路径供应商产品展示序列号| 类型
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | 康比II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | 通用FTDI
rich710 @ RichHassPc01 ：〜$ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13（c）德累斯顿电子技术有限公司
重新启动设备（ConBee II）

2139：错误：uart重置失败，请重试
rich710 @ RichHassPc01 ：〜$

rich710se 于 2020-02-26

或者，您也可以尝试以下操作：

拔下ConBee II
GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
再次插入ConBee II

manup 于 2020-02-26

-t参数使GCFFlasher尝试等待一分钟以处理更新。

manup 于 2020-02-26

它可以更新Windows中的固件，当我使用ubuntu将其插入NUC时，它再次连接。但是，一小时后，它刚刚连接到我的4个节点。
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似乎经常检测到ConBee II。仍然没有交通。
日志文件

编辑为了使您幽默，我断开了XBee的连接，并使用10厘米USB延长线连接了ConBee II：没有变化。

ebaauw 于 2020-02-26

再次尝试使用ConBee II固件：
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF
此版本的TX电源设置为0x264a0700。缓冲区仍然很大（但根据映射，它们应该很好地适合RAM）一次只能检查一件事。

测试了您的新版本，但10分钟后仍未显示任何链接...使用稳定的固件，大约2分钟后会显示网络中的所有正常（路由器）链接。宜家按钮可立即使用，而测试固件完全不可用。

cs42 于 2020-02-26

嗯，怪异的，感谢您对此进行测试。接下来，我将尝试减小缓冲区大小，如前所述。
我仍然想知道为什么它在我的设置中起作用。从上面的屏幕截图中，我只能说我的终端设备比路由器多。

manup 于 2020-02-26

刷新固件后，

jurriaan 于 2020-02-26

这是带有路由错误修复的ConBee I和RaspBee的测试版本。

在我的Pi 3B +测试系统上似乎运行良好。将等到这个周末才能升级我的生产网络。

ebaauw 于 2020-02-26

@ebaauw ，我是否正确记得您对宜家协调员的行为进行了许多此类调查？它也这样做吗？

我增加了对大多数Trådfri设备的支持，但是我无法嗅探到Trådfri集线器的ZigBee通信。它仅使用触摸链接配对，而我还没有尝试捕获它来恢复网络密钥。也就是说，假设一切皆有可能。

ebaauw 于 2020-02-26

自从发布新固件以来，我一直在40个节点设置中的conbee 1摇杆上运行新的固件，并且运行良好，没有任何问题！（在图片中，未连接的节点电量不足或未供电）

感谢所有涉及故障排除和更新代码的人员。非常感谢！ <3

tubalainen 于 2020-02-27

不为我工作。网格中几乎没有连接。重新启动后已等待约20分钟。

Raspberry Pi 3 Model B修订版1.2
康比二世
版本2.05.74
版本26530700

77个节点

3连接
1个TRÅDFRI开/关开关
1小米多传感器
1飞利浦调光器开关
我可以从philips调光器开关触发事件。
这些具有连接功能的设备与Conbee手柄非常接近。棍子位于车库中。我的车库里有一些没有连接的灯泡。

没有连接
许多宜家灯泡，E27和GU10
很多小米多传感器
宜家很多TRÅDFRI遥控器
和其他节点。

日志
2月27日09:29:06 raspberrypi systemd [1]：启动了deCONZ：ZigBee网关-GUI / REST API。
2月27日09:29:06 raspberrypi deCONZ [7204]：libEGL警告：DRI2：验证失败
2月27日09:29:06 raspberrypi deCONZ [7204]：libpng警告：iCCP：已知错误的sRGB配置文件

降级到264A0700时，它将直接开始构建网格。

danielkihlgren 于 2020-02-27

@ebaauw ，我是否正确记得您对宜家协调员的行为进行了许多此类调查？它也这样做吗？
我增加了对大多数Trådfri设备的支持，但是我无法嗅探到Trådfri集线器的ZigBee通信。它仅使用触摸链接配对，而我还没有尝试捕获它来恢复网络密钥。也就是说，假设一切皆有可能。

对，对不起应该检查git怪。其中提到宜家网关的行为的代码实际上是在通过48d2c39a267b5c6d025577eed7530be27932aa2c介绍@manup ...

@manup ，您是否确实确定宜家网关经常重新配置报告此属性的属性？为什么需要重新配置；是否需要定期提醒灯光？

djwlindenaar 于 2020-02-27

将Conbee I升级到Beta FW和deCONZ .74

网格立即生成，看起来非常漂亮！

非常感谢@djwlindenaar 。您无所事事，发现如此严重的错误，给我留下了深刻的印象。当然还要感谢@manup修复它们...

mvjt 于 2020-02-27

Conbee I和.74也是如此。将宜家FW升级到2.3.007（其他一些版本是2.x）。
重大改进！还没有辍学！

非常感谢您在此线程以及以后的工作中做出的所有贡献，开发，调试，测试。

我在此过程中发现的一些信息：
正常的组ON-OFF可以快速运行，但是在调用场景（时间淡入之后）并再次将其关闭（<10sec）后，灯光仅在GUI中熄灭（无论新旧gui），然后其中一些重新点亮（在gui中）分组，而所有物理灯泡仍保持点亮状态。在第二次或第三次按下OFF后，它们有时会变黑。

固件升级后还原/重建场景并不罕见
但是，无论我建立一个新场景还是尝试修复一个旧场景，其行为都保持不变。正常的开关不会受到影响。

我发现当我稍等一会儿，它照常工作。假设15到20秒。然后灯照常熄灭。我猜想像deconz get一样混乱，就像你关灯直到它消失一样。

似乎我们增加了延迟，直到每个光状态都被报告回来并且场景召回以deconz完成或成功报告为止，以便该组中的其他操作可以按预期进行。现在，这似乎需要更长的时间。在此期间-您不得（通过;））-开关熄灭。这并不重要。

realwax 于 2020-02-27

我进行了进一步测试。我们的行为有所改变。以前，当以给定速度更改bri时，或者场景的过渡时间较长时，可以用新命令中断。即使仍执行了上一个操作，下一个命令也已排队。现在迷路了。例如，落地灯是由运动传感器操作的。在它们消失之前，我先将它们调暗并等待10秒钟，然后再关闭它们。当我触发动作并在场景消失时回想场景时，命令丢失了。在此之前，它已排队等待执行。这是由于。 74或新固件？谢谢

realwax 于 2020-02-28

我的Conbee II没有在beta版上构建网格。我唯一能想到的与“正常”设置不同的是将通道设置为25。回到264a0700修复了该问题

helto4real 于 2020-02-28

@realwax ，我认为您是在遇到Trådfri固件错误，请参阅＃2068。您可以通过在GUI中发出一个过渡时间更长的命令，然后发出第二条命令来轻松地验证这一点。

在此之前，它已排队等待执行。

您是否更新了灯光固件？您确定使用的是同一盏灯吗？ REST API插件向灯光发送命令后就不会跟踪过渡时间。

ebaauw 于 2020-02-28

@ebaauw谢谢您带领我朝着正确的方向前进。宜家表示要在其发布日志中包含网络和稳定性方面的改进，因此我将TRÅDFRILampe E14 WS蛋白石400lm升级到固件2.3.007（最新）。我认为这可以缓解其中的一些问题。我不知道宜家如何在自己的桥梁上实现成功，因为这是一个很大的可用性问题。现在，正如您在另一期杂志中所述，我必须加快转换时间。我从第一天开始就经历过这种情况，但情况变得更糟。现在，它不仅会影响场景的召回效果，而且会影响更长的过渡过程中的任何变化，这是新的……我该怎么办？闪回较旧的固件几乎是不可行的，因为这是与deconz的斗争。谢谢你Erik。

realwax 于 2020-02-28

我不知道宜家如何在自己的桥梁上实现成功，因为这是一个很大的可用性问题。

Trådfri集线器的活动性远不如deCONZ网关或Hue桥。 Trådfri控制器（开关，调光器以及运动传感器）直接控制灯光。 Trådfri指示灯会通过状态更改将推送通知发送到集线器。该中心仅在其应用中需要/使用。它可能会发出一些警报，但没有规则来处理按钮事件或其他任何花哨的事情。

我不确定Trådfri应用程序是否支持指定更长的过渡时间，但是我所见过的控制器不支持。您可能无法从控制器发送命令的速度快于灯光的默认过渡时间。而且，如果您偶尔这样做，您可能会认为您没有完全按下按钮。

ebaauw 于 2020-02-28

👍1

@ebaauw，我明白了。我仍然感到困惑的是，我可以在1秒钟内（开-关-开）打开和关闭一组E14（提供某种光的迪斯科舞厅;））！但是，一旦我按deconz中的一个场景调用按钮，我就不能这样做，并且行为变得很奇怪。这就是我怀疑宜家的错的地方。为什么我可以很快地打开和关闭，但是一旦我想起一个场景，我至少被卡住5-10秒？

精确测量的时间（20次尝试）：
8组E14
组ON->组OFF-切换时间1秒
调用场景->打开-> OFF直到10-12秒才响应！

我知道召回会产生更多的流量，每个灯泡都会收到更多消息，但相差10秒？即使当我为整个组更改bri和ct时，我都可以在一秒钟内将其关闭，但是再次召回就像冻结。我认为这似乎是个deconz问题，不是吗？

我可以录像。 ;）也许我在这里缺乏知识，然后请原谅我缺乏理解，但由于某种原因我感到沮丧，这很麻烦。

realwax 于 2020-02-28

恐怕我对场景还是有些困惑。像组一样，它们在ZigBee中不作为对象存在，它们只是设备（指示灯）用来存储状态的数字。在现场召回时，将传输该编号，并且每个设备都从其非易失性存储器恢复状态。

模糊的部分是，并非所有设备在存储场景时似乎都能正确存储其状态：色温是臭名昭著的。我还看到了一些有趣的东西，它们在灯光仍在过渡时存储场景。在这种情况下， /scenes资源与存储在灯光上的状态不同步，从而导致API反映资源状态而不是实际的灯光状态，该状态只会在下次灯光下更新轮询。通常，过渡时间是在调用场景时指定的，但看起来它也处于存储状态。

我已经编写了生产网络的脚本（使用ph ），因此可以轻松地重新创建它。我很难以可预测的方式编写场景脚本。我最终设置了灯光状态，休眠了几秒钟，等待状态稳定下来，存储了场景，然后再次休眠了几秒钟，等待状态被存储了。

您可以尝试重新创建场景，但不能保证...

ebaauw 于 2020-02-28

👍1

我可以从第一天开始重现不同步的主题。我习惯于去整理和不时重新配置场景。现在真的更糟了。目前，我需要从deconz采购到iobroker，以重建在那里的所有场景。但这是很多工作。希望这可以解决。我可以提出一个问题吗？使用场景时灯光不再可靠...-我也尝试重新创建。除了已经存在的场景外，我昨天还进行了“测试”场景，但是它没有显示其他行为。

realwax 于 2020-02-28

不确定是否相关，但是在将我的Conbee I升级到beta固件并将deCONZ升级到.74之后，花了一天的时间，现在deCONZ失去了与Conbee的连接。几年前从未经历过...但是我想提一提...日志刚刚说明了重试以一遍又一遍地连接...重新启动deCONZ解决了它...

mvjt 于 2020-02-28

我只是试图重新创建一个组，所有场景...在创建过程中，有太多错误。使用Phoscon和“ ALL”灯泡时，场景值无法正确存储。即使已配置的指示灯也显示出您想要的内容，但调用却没有。即使您进行相同的设置，也必须自己控制每个灯。特别是，旧的GUI必须用于纠正错误存储的颜色的色温错误。在场景“工作”之前，您必须经过几次，也许在场景配置过程中打开和关闭灯光，以便正确存储它。我在这里没有太多技术细节，但是我想鼓励大家在线程中测试场景，创建，存储，调用并在调用后关闭。我认为这与宜家的灯泡弄得一团糟，而且情况变得更糟...可能是与宜家有关，但我怀疑其他一切以及直接的群组控制是否像deconz一样具有吸引力。

现在，我将固件回滚/降级到1.x，看看它是否更好。我会报告。

realwax 于 2020-02-28

好。回到绘图板。昨天2宜家照明灯请假了，直到上电后才回来。并不是说已修复的错误不是错误。他们是。只是不是导致问题的原因。

我正在更深入地研究属性报告。我想知道是否每30分钟（1800s）重复配置属性报告是否导致轻固件的挂断。
我注意到这段代码似乎并没有明确处理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

编号时间源发送Dev接收Dev目标禁用默认响应信息
208134 10h 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL：报告属性，Seq：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：默认响应，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.

编号时间源发送Dev接收Dev目标禁用默认响应信息
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL：配置报告，Seq：41
207949 10h 43m 8.481帮派1帮派1 DeConz DeConz False ZCL：配置报告响应，Seq：41
207951 10h 43m 8.485帮派1帮派1 DeConz 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 43m 8.493帮派1帮派1 DeConz DeConz APS：Ack，Dst Endpt：1，Src Endpt：1


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

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

djwlindenaar 于 2020-02-29

❤1

我注意到这段代码似乎没有明确处理rq.maxinterval == 0。现在如何正确处理这种情况有些困难，因为rq.maxinterval == 0意味着指示灯只会报告更改，因此在这种情况下没有“好的”超时时间……也许当前的实现很好，尽管我想知道是否存在更好的主意。

是的，REST API插件检查属性报告是否正常运行。如果没有，它将尝试重新配置它，而且我认为它也将回退到轮询设备。

我做了一些实验，包括要求IKEA灯定期报告ONOFF和LEVEL，而不是仅在进行更改时报告。指示灯会定期愉快地报告其状态，因此这可能是避免上述问题的可接受方法。当然要正确验证。

我认为我们在相当长的一段时间内都使用了该设置。由于某些Trådfri固件将挂起（需要重新启动光），因此更改了它，同时对邻居表的轮询频率降低了，不再轮询状态。我怀疑报告设置是否确实导致了固件崩溃。

ZCL数据包中有一个位，指示是否应发送Disable Default Response 。

当设置Disable Default Response位时，我认为发送默认响应不会带来太大危害。当未设置该位时不发送默认响应会造成危害，因为等待响应的设备可能会推断协调器不再可访问并最终离开网络。

ebaauw 于 2020-02-29

ZCL数据包中有一个位，指示是否应发送Disable Default Response 。
当设置Disable Default Response位时，我认为发送默认响应不会带来太大危害。当未设置该位时不发送默认响应会造成危害，因为等待响应的设备可能会推断协调器不再可访问并最终离开网络。

@ebaauw ，的确如此。这就是重点。 deCONZ无法发送Default Response来回复Configure Reporting Response 。宜家灯正以Default Response要求Configure Reporting Response 。
因此，正如您所说，这可能是原因，再加上每半小时Configure Reporting Request ，宜家灯会熄灭。

djwlindenaar 于 2020-02-29

只是提醒：
宜家灯泡（E27＆GU10 v1）有时会变得不可达，并且在连接到HUE桥时也需要重新启动电源，因此特定问题并非Conbee I / II独有
在我的HUE桥上的16个E27和12个GU10中，我大概每1-2周就“挂”一个灯泡。有时更长，有时更快。在过去的一年半中，最新的HUE固件版本改善了此问题。

olemr 于 2020-02-29

@all您正在使用哪个Tradfri固件版本？

您使用的是1.x还是2.x？他们使用2.x引入了zigbee 3.0。我升级到2.x，麻烦开始了。 E14灯泡。我注意到有关网络速度和连接性的改进。但是有两件事让我叹息了20个灯泡。“软启动”不再起作用了。灯泡打开时不会褪色。场景无法像以往那样工作。准确地说，在调用场景后需要等待一段时间，然后关闭灯光或调用下一个场景。

我很感谢您分享的版本经验，以及似乎没有给出的2.x版本的deconz“完美无瑕”功能。

有建议吗？ FW v。？除了丢失的连接问题和宜家FW本身的连接问题之外，似乎deconz可以更好地处理1.x。

谢谢！

realwax 于 2020-03-01

我在用：

带有0x26340500固件的Conbee 1
Deconz版本2.05.73（在Debian上使用marthoc docker容器）
约60个节点，主要是宜家Trådfri
Conbee 1（协调器）未安装在我200平方米的房屋中央。该系统严重依赖漫游和网格划分。
Conbee 1摇杆安装在0.5米长的USB延长线上，并安装在计算机所处机架的侧面，以便为RF信号留出更多空间。

自从Conbee 1 Sticks固件升级（发布之日）以来，deconz一直在发挥作用！没什么问题。

tubalainen 于 2020-03-01

昨天将我的生产网络（RPi 3B +，stretch，RaspBee）升级到2.05.74和0x26340500。似乎稳定，除了以下问题。

不知道是否相关，但是今天早上到我的lumi.curtain窗帘控制器的路线丢失了。控制器的报告仍将到达网关。重启控制器电源后，该路线将无法恢复。在协调器再次到达之前，我必须打开网络并重新启动控制器。

另外，启动deCONZ后，我的其中一个Eurotronic Spirit散热器阀无法到达deCONZ，但仍在发送报告。像往常一样，对TRV进行动力循环可将其重新带回。

这次我没有机会进行任何深入的调查，但是这两种设备从一开始就存在问题，偶尔会出现这些症状。我的宜家Fyrtur百叶窗也一样。如果遇到更多问题，我将继续监视情况并报告。

ebaauw 于 2020-03-01

@tubalainen
您在tradfri灯泡上使用哪种固件？就我所测试的而言，即使在此线程中，就丢失连接问题而言也是如此。我的结果是，此处采取的步骤改进了在Conbee 1上使用1.x操作的tradfri灯泡的操作。但是20的e14与tradfri fw 2.3.x组成的网络是一团糟。定时，场景卡住，deconz得到，灯光开始闪烁（丢失？）..如上所述。我认为这是要讨论并提及的问题，以便提出宜家fw的明确建议以用于良好体验。也许已经有一篇git文章了。但是根据我的经验不要升级

因此，从我的角度以及测试和闪烁的时间来看。感谢您对宜家fws 1.x的改进！ 2.x运行时是否可以缓解当前问题？否则，当前无法通过ikea升级到zigbee 3。似乎行为已更改，必须对在deconz中的操作进行调整。这可能由@ebaauw来判断或处理？

干杯
祝你周日愉快😊

realwax 于 2020-03-01

@realwax
我试图将所有实体升级为最新的固件。这是我所有（当前活动的）节点的列表。

同意将所有“运动部件”都弄得一团糟，试图找出问题的根本原因。

tubalainen 于 2020-03-01

@tubalainen

谢谢您的清单。

着眼于路由器（灯泡），我发现您在E14上操作2.3.007。您能重现我的问题清单吗？ https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
当我不知道将固件自动升级到2.3.x时，我的网络与1.x和2.x混合使用的情况不是很好。我手动升级到2.3.x，然后变得更糟。（网络速度更快，但可用性却大打折扣，并且灯泡掉线了）所以我可以建议您，如果e14上的灯泡出现闪烁，或者屏幕上出现“滞后”，将它们降级到1.2 ...我希望获得“官方” /我们的专业人士在此发表专业声明。我非常确定曾经有一次deconz处理1.2的问题得到了改善。我觉得这也需要针对2.3.x完成，否则宜家会自己弄乱它。很难说，因为我不深入代码。

realwax 于 2020-03-01

👍1

@realwax
我正在使用deconz的otau功能及其固件更新脚本来下载fw文件。
我不知道为什么E14没有更新...哼。

您是如何“手动”更新/降级灯泡的？

好吧。一切正常，大部分路由工作由F27 2.3.x的E27和Jormen和FLOALT面板驱动程序完成。

tubalainen 于 2020-03-01

@tubalainen
有趣的是您没有遇到这个问题。也许是因为网格大小。我在2.3.007的那20个e14上有23个灯泡。我停用了自动otau，因为它使我无法使用新固件。通过Gui，您可以使用更新按钮降级。首先选择合适的固件，再按更新，然后再按一次。表单状态已暂停->排队->空闲->开始固件更新（百分比）。有时会挂起。有时需要重新启动。有时电源循环就足够了。有时您需要将灯泡拉近协调器。

realwax 于 2020-03-01

似乎行为已更改，必须对在deconz中的操作进行调整。这可能由@ebaauw来判断或处理？

不知道你的意思在这里。我处理了控制器的ZLL和ZB3固件（Trådfri远程控制器和Trådfri无线调光器）之间的一些差异，请参阅＃2485。这是ZigBee堆栈中的APS级别，由REST API插件处理。

本主题中的路由问题在NWK级别，由设备固件处理。像这里的其他所有人一样，我无权访问固件源。即使我愿意，也无能为力，因为我不知道NWK和MAC层的详细信息。

ebaauw 于 2020-03-01

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
确切地说。我在这里用20个E14 2.3.007网格包括了我的发现。某些功能消失了，场景召回几乎使该组中的所有内容混乱了10至15秒。我不知道这只是固件相关还是deconz相关。这就是我要应对的变化。因此，对于日常操作，我认为2.3.007不可行。给出的可用性示例：旋转phoscon中配置的简单场景开关后，如果不小心按下（意味着要等待场景旋转），将无法再使用。在1.x中，使用2.3.x的一切都很快而且很好，但是它卡住了。

realwax 于 2020-03-01

谢谢@manup ，刚刚安装了它。让我们看看它会带来什么。
尽管我希望这会带来一些改进，但是您对DeConz固件忽略记录的路由（由于鬃毛到一对路由）的感觉如何？总的来说，我已经看到记录的路由比DeConz固件所使用的路由更具逻辑性。
尽管我可以想象启用源路由是一项艰巨的任务，但DeConz固件仍可以（应该？）使用路由记录数据包中的信息将第一跳更新为设备。也许只是检查到协调器的最后一跳是否与路由表中存储的内容匹配，否则，请使路由表中的条目无效。我不确定是否可以用记录的路由中的最后一跳替换条目，因为沿途的设备可能会忽略该信息，但是至少它可以通过DeConz固件为该节点启动新的路由发现。
你怎么看待这件事？
奇怪的是，固件应该已经使用这些路由记录来建立新的路由，需要在此处检查代码，但是如果我的存储服务正确，那是在不久前启用的。

@manup ，您有时间找这个吗？今天早上，我发现了一种情况，我给电源灯（IKEA）上电，距离协调员4跳。介于两者之间的路由器（也是宜家）以某种方式决定不再知道通往该指示灯的路线。我实际上看到该灯在路由其他灯，报告链接状态并响应deCONZ的Network Address Request时很高兴地工作。最后一个发生是因为这些消息是在网络上广播的消息。
但是，介于两者之间的路由器会静默丢弃应路由到此指示灯的任何单播帧。当然，该路由器不应默默地丢弃它们，然后，再次，deCONZ应该能够抵抗这种不良行为。
同时，信号灯确实很高兴地将路线记录消息发送到deCONZ，到达并被deCONZ忽略。

我认为在这种情况下，应该有一些逻辑可以触发deCONZ重新考虑其路线。特别是，当它检测到未回复ZCL请求时。最终导致光被标记为僵尸。标记为僵尸的发现实际上确实引起了ligtht的答复。也许当发现僵尸开始时，它也将使可用的任何路由信息无效。但更好的是，即使在没有回复几个ZCL请求时（可能已经在第一个或第二个请求上），如果路由早已失效，则该路由也会无效。

你怎么看待这件事？

djwlindenaar 于 2020-03-01

这个新固件无法解决我的问题。

我在单独的Pi和Home Assistant上使用Raspbee（在NUC上运行），并具有appx。 25 tradfri灯。 GU10通常每3人一组使用。

我遇到一个很大的问题，一个照明灯组中的单个灯反应迟钝，需要重新启动电源。宜家FW v1和将灯泡升级到2.3.007之后都发生了这种情况。

解决方案是将我的配置从将HASS中的灯分组到在Phoscon中定义灯组并将Phoscon组作为HASS中的单个灯进行更改。进行此更改后，我已经运行了几个月没有问题。

我确实希望能够在HASS中进行分组，所以我将Raspbee升级到0x26340500，将Deconz升级到2.05.74，并将配置更改回使用HASS中的灯光组。运行了一周后，灯泡已经过时了3或4次，现在又重新使用Phoscon组。

aherbjornsen 于 2020-03-03

我认为在这种情况下，应该有一些逻辑可以触发deCONZ重新考虑其路线。特别是，当它检测到未回复ZCL请求时。最终导致光被标记为僵尸。标记为僵尸的发现实际上确实引起了ligtht的答复。也许当发现僵尸开始时，它也将使可用的任何路由信息无效。但更好的是，即使在没有回复几个ZCL请求时（可能已经在第一个或第二个请求上），如果路由早已失效，则该路由也会无效。

我仍在使用新固件，并测试包括路由记录在内的一些内容，希望本周使其联机。

你怎么看待这件事？

很好，我需要在此处检查核心和REST-API插件代码，因为我认为当没有收到APS级别ACK时，固件应该已经降低了路由“质量”。 APS ACK是在ZCL / APS请求中可选设置的标志，通常会被禁用以降低网络流量。因此，一个粗略的想法是，如果插件检测到单播请求导致超时，则应启用APS ACK。

也许其中一部分已经到位，需要检查代码。

但是，介于两者之间的路由器会静默丢弃应路由到此指示灯的任何单播帧。当然，该路由器不应默默地丢弃它们，然后，再次，deCONZ应该能够抵抗这种不良行为。

触发新路线发现后，指示灯应会拾取一条新路线。因此，目标应该是尽快检测到断开的路由（希望APS ACK能够解决问题）并触发路由发现。

用于状态的状态机已经在deCONZ核心中（这导致广播NWK地址请求），这在单跳链接的情况下起作用，并且对于确实根据传入命令拾取路由的灯也起作用（对广播）。广播很不错，因为它也考虑更改为NWK地址，因为包含了MAC地址。如果没有收到答复，我将尝试发送启用了APS ACK的单播作为下一步。

manup 于 2020-03-03

不幸的是，昨天我也不得不重新启动IKEA E27灯泡（白色1000LM，v1固件）。它仅对组作出反应，而对单播命令不起反应。似乎问题尚未解决:(

（是的，我正在使用v74和RaspBee的Beta固件）

timbru31 于 2020-03-04

请参阅上面的注释，接下来的更改可能有助于恢复路由。

manup 于 2020-03-04

你怎么看待这件事？
很好，我需要在此处检查核心和REST-API插件代码，因为我认为当没有收到APS级别ACK时，固件应该已经降低了路由“质量”。 APS ACK是在ZCL / APS请求中可选设置的标志，通常会被禁用以降低网络流量。因此，一个粗略的想法是，如果插件检测到单播请求导致超时，则应启用APS ACK。
也许其中一部分已经到位，需要检查代码。

看起来即使设置了APS ACK请求位，deCONZ也不会对丢失的ack做任何事情（仅重试一次，然后什么也没有...）

BTW 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地址请求），这在单跳链接的情况下起作用，并且对于确实根据传入命令拾取路由的灯也起作用（对广播）。广播很不错，因为它也考虑更改为NWK地址，因为包含了MAC地址。如果没有收到答复，我将尝试发送启用了APS ACK的单播作为下一步。

实际上， 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从未达到Tuin linksvoor 2 ，因为它被houtlamp 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％确定。

tubalainen 于 2020-03-06

在使用固件1.2.221的Tradfir E14上的Conbee 1上使用.74和26340500运行几天后，可以报告：

尽管我只有一个灯泡在4天之内丢失了，但是从掉出网络的角度来看，宜家的灯变得更加稳定。我还发现，如果您对运行在E14 fw 1.2.221上的由deconz操作的zigbee网络感到无所适从。我通过发送每秒更改了bri的单个请求来运行一个脚本，以减轻负担。这样，我很快就失去了4个灯泡。但是无论如何谁想要那个;）

仍未解决：
我仍然遇到的问题和担忧是Tradfri FW 2.3.x运行不正常，或者不能与deconz一起很好地实施。留在tradfri fw 1.2.x而不使用zigbee 3.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并没有如所提到的问题中所述失去可用性。我无法想象我是唯一遇到这种差异的人。

我现在已经以德语向德累斯顿电子技术支持小组发送了一封电子邮件，以提高对此的认识，因为我了解到有些人是爱好爱好者，因为@ebaauw在另一线程中明确指出。我认为大多数开发人员都是德累斯顿电子承包商。非常抱歉您的误解，并感谢您的贡献。我对现在的官方答复很好奇。

realwax 于 2020-03-06

👍1

Conbee II固件现在是否也已修复？我只在发行中看到了ConbeeI。谢谢大家的辛勤工作。

helto4real 于 2020-03-07

👍1

然后，这再次是由于deCONZ没有将路线记录选择为新路线而引起的。

@djwlindenaar原来是我的

如果我没记错的话，当时的问题是我们有一个大约150个节点的大型混合网络，并且路由记录似乎无法正常工作。返回的新路径无法正常工作。但是，该代码可能已与NWK状态命令错误代码的其他修补程序一起使用。

我现在将其还原，因此路由记录应将路由更新为更好的路径。

喜欢Zigbee规范中的那一段：

ZigBee路由器或ZigBee协调器可以维护路由表。表3-66中显示了应存储在ZigBee路由表条目中的信息。建议对路由表条目进行老化和报废，以便从不再使用的条目中回收表空间；但是，这超出了本规范的范围。

基本上，这意味着每个堆栈处理路由老化的方式都不同。

因此，我已经检查了它在我们的情况下如何工作。在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）点，因为例如一条非常新的路线或一条不经常使用的路线会因具有良好链接的完全不相关的高性能节点而退化，例如每隔几秒钟轮询一次的Philips Hue灯就会触发器（2）通常将其乘以大型网络中的灯光数量。更不用说活动的OTA更新了。

我认为更改（2）不降级（规范化）所有路由条目是安全的，但仅更改与成功传输相关的255条顶级路由是安全的。这样可以防止松动的路由工作正常，但不经常使用，并且在第一次NWK传输失败时被删除。

明天，我将使用这些更改来构建新的固件，也可能适用于ConBee II。

manup 于 2020-03-07

👍5

我现在将其还原，因此路由记录应将路由更新为更好的路径。

好的听起来不错。我期待测试！

喜欢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传输实际上仅意味着下一跳，因为NWK仅检查802.15.4 MAC ACK。因此，要检查端到端传输是否正常，我们必须依靠APS ack。那是对的吗？它在BitCloud中以这种方式工作吗？
另外：如果未设置APS层中的确认请求位，是否认为该发送成功（因为没有确认确认），并且是否增加了该路由条目的“速率”？因为如果这样的话，我们可能不总是一直请求APS层ACK，这使我们无法自拔。

如果仅基于NWK故障，则这将无助于中间路由器行为异常的情况，我们需要添加其他逻辑以考虑到APS层ACK尚未到达。可能基于适当的逻辑来检测“僵尸”路由器，但首先要使该路由的路由表条目无效。

djwlindenaar 于 2020-03-08

可用于ConBee I和RaspBee I的固件版本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点）
修复路由记录不会更新路由的下一跳，请注意，此操作现在可以工作，但前提是当路由记录时当前路由成本更高
使用启用的APS ACK修复失败的APS请求不会降低路由

我现在在看ConBee II代码，看是否可以在何处应用这些修补程序。消除0x26520700和0x26530700并将其基于当前稳定的0x264a0700。

我没有真正理解规则2的逻辑。这似乎是一种穷人的老龄化版本。如果所有节点看到的流量都差不多，那行得通，但是确实，如果不平衡（我认为这很普遍），它将出问题。
我注意到ZStack在其路由表中的状态字节旁边使用了一个实际的expiryTime字段。

完全同意，这是固定的，因此当速率达到最大值时，只有成功传输的路径才能正常化。过期计时器处理此问题的方法可能是另一种选择，但有其自身的陷阱。我认为采用“费率”方式应该可以很好地工作，而不取决于网络的大小和时间。

如果仅基于NWK故障，则这将无助于中间路由器行为异常的情况，我们需要添加其他逻辑以考虑到APS层ACK尚未到达。可能基于适当的逻辑来检测“僵尸”路由器，但首先要使该路由的路由表条目无效。

似乎是这种情况，并且确实表现不佳的路由器（如果路由器不发送带有路由故障的NWK状态命令），则可能会使无效的路由保持活动状态。现在，此问题已在0x26350500中修复，但它依赖于启用APS ACK的命令。哪个应该可以并且可以由deCONz和REST-API插件控制。

manup 于 2020-03-08

👍1

可用于ConBee I和RaspBee I的固件版本0x26350500。

闪烁了，现在测试。

现在，此问题已在0x26350500中修复，但它依赖于启用APS ACK的命令。

您如何应对丢失的ACK？您将rate值减半（与NWK传输失败相同还是更多/不同）？因为我认为与失败的NWK传输相比，丢失的APS ACK应该被视为更为严重。否则，在路由器行为异常的情况下，成功的NWK传输可能会使rate增加的幅度大于丢失的APS ACK所导致的幅度。

djwlindenaar 于 2020-03-08

您如何应对丢失的ACK？与NWK传输失败相比，您将速率值减半还是更多/不同？因为我认为与失败的NWK传输相比，丢失的APS ACK应该被视为更为严重。否则，在路由器行为异常的情况下，成功的NWK传输可能会增加速率，而丢失的APS ACK会使速率降低更多。

我也这么认为，这就是这种情况：

NWK传输正MAC ACK rate + 1
没有APS ACK rate = rate / 4

因此费率下降得很快，可能有点太激进了， rate / 2足够了，但是让我们看看它是如何工作的。

manup 于 2020-03-08

👍1

真好我将运行它并报告。

当前，还通过每隔几秒钟将单播消息（OnOffwithLevel）发送到距离网格很远的灯光来进行压力测试。

顺便说一句，我还更改了其余的插件代码，以在所有消息中请求APS ACK。

djwlindenaar 于 2020-03-08

我使用家庭助理在Rpi 3B +上运行Deconz
目前与Conbee I和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 s标志：0x7
19：24：46：764 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：25：10：547 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：25：15：749当前频道25
19：25：15：782设备TTL 3860 s标志：0x7
19：25：33：885 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：25：49：411 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：26：12：765 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：26：12：765节点0x000D6FFFFEB1C9FF的最大传输错误，最近一次被邻居看到25秒
19：26：15：742当前频道25
19：26：15：774设备TTL 3800 s标志：0x7
19：26：48：221 0x000D6FFFFEB1C9FF错误APSDE-DATA。确认：任务上为0xA7
19：26：48：221节点0x000D6FFFFEB1C9FF的最大传输错误，最近一次被邻居发现60秒
19：27：03：845 9毫秒内保存的节点状态
19789：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版本。
我想使用官方的Home Assistant Deconz加载项帮助测试，不确定如何将其更新为Beta固件。（官方更新为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的决策过程进行一些深入了解，以是/否接受route record消息中的路由，这将很有帮助。

---编辑了以下内容，因为我的推理存在缺陷。现在希望不是：wink：-

话虽如此， deCONZ使用的路由实际上比直接通信到Tuin linksvoor 2更加可靠。这使我想知道并研究多对一路由。我想也许是Raspbee的发射功率不理想...
这是我的理由：

多对一路由是基于广播的接收
与常规路由处理不同，传入和传出路径的最大成本被视为下一跳的成本
现在，如果路由器或协调器在发送（高TX功率）方面比在接收（低RX灵敏度）方面要好得多，这可能会导致多对一路由无法很好地工作。

我注意到的一个相关点是，deCONZ似乎对路由表中的传入成本非常（非常）乐观。当Tuin linksvoor 2直接向deCONZ Tuin linksvoor 2发送消息时，它总是需要重试。现在，如果我查看路由表，我将看到以下内容，并且我不希望以4的传入成本进行困难的传输。请注意，基本上，路由表中的所有项目的传入成本都比传出成本低得多。

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

因此，如果deCONZ对传入成本不太乐观，那么我们可能会看到更好的路由行为。或者，如果我们将发送功率提高到更加平衡（入站和出站的成本相近）
或者，如果我们降低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

更新：仍然很强大！

我认为我从未见过如此稳定的网络。现在，我已经更改了各种规则，以使用单播而不是组。现在已经两周了，但0盏IKEA灯却不见了。

（希望我现在不纠结）

请注意，我确实更改了REST插件以对所有请求都请求APS确认。

djwlindenaar 于 2020-03-20

我也在经历一个大大改善的网络。不是100％。偶尔会有灯泡无响应，但是当我手动更换宜家灯泡时，它确实有响应。我还看到灯泡的状态现在与物理状态一样。
但是，我的一个欧司朗灯泡像宜家灯泡以前那样反应迟钝。积极的是，它没有宜家那样严厉的行为。

希望可以被其他人确认或发现发现。

PeterRemnemark 于 2020-03-20

我正在运行Conbee 1，FW 26350500和Deconz 2.05.75。
这是我最近几周的经历

效果更好，但不是100％
我的一些IKEA E27TRÅDFRI灯泡E27 WS蛋白石980lm带固件2.3.007，有时无法回答OFF命令
我可以尝试再次将其关闭，并且通常可以正常工作（无需重启电源）

tubalainen 于 2020-03-21

@djwlindenaar不错！ .75版本中是否包含针对REST API的APS修复程序？就是这样，我知道这是否可以解释以前的帖子中的一些区别...

mvjt 于 2020-03-21

不，这不对。我什至还没有创建请求请求。这样，您可以自己构建它。我今天或明天都会这样做。
我也可以共享内置的rest API插件，但是我只有一个用于raspberry 3。

@tubalainen ，我将检查是否可以通过APS ack进行解释。我也没有2.3宜家灯。

可能是deCONZ中的重试行为存在问题。我需要为此做一个实验，或者可能已经在嗅探日志中了。

如果您可以嗅闻，闻一下这种现象将有所帮助。我可以帮助您分析。

djwlindenaar 于 2020-03-21

昨天将我的生产网络（RPi 3B +，stretch，RaspBee）升级到2.05.74和0x26340500。似乎稳定，除了以下问题。
不确定是否相关，但是今天早上到我的lumi.curtain窗帘控制器的路线丢失了。控制器的报告仍将到达网关。重启控制器电源后，该路线将无法恢复。在协调器再次到达之前，我必须打开网络并重新启动控制器。
另外，启动deCONZ后，我的其中一个Eurotronic Spirit散热器阀无法到达deCONZ，但仍在发送报告。像往常一样，对TRV进行动力循环可将其重新带回。
这次我没有机会进行任何深入的调查，但是这两种设备从一开始就存在问题，偶尔会出现这些症状。我的宜家Fyrtur百叶窗也一样。如果遇到更多问题，我将继续监视情况并报告。

客观地记录这些间歇性问题非常困难，但是我的确给人的印象是0x26350500在这里带来了改进。除了上面提到的设备，我的网络非常稳定。我有一些TRV无法从网关访问，但是大多数情况（仅？）在重新启动deCONZ之后。在过去的三周中，我认为FYRTUR或窗帘控制器都不会出现MIA。

请注意，我确实更改了REST插件以对所有请求都请求APS确认。

我确实在GUI的_Network Settings_中启用了APS Acks，但是我不确定这是否仅适用于GUI发送的消息，也适用于REST API插件。

ebaauw 于 2020-03-21

如果要使用上面的pull请求运行，还可以签出我的fork并进行构建：djwlindenaar / deconz-rest-plugin

djwlindenaar 于 2020-03-21

据我所知， @ebaauw仅适用于从GUI发送的命令

我有一个连续不断的嗅探器，而不是出现问题时的挂钟时间。通常使用该信息，我可以很容易地找到数据包...

顺便说一句，我已经将很多规则（尤其是那些经常触发的规则）切换为单播。到目前为止，效果很好。另外，在过去的两个星期中，我一直在运行一盏IKEA灯，不断改变亮度（每4秒左右一次）。那也还好。

djwlindenaar 于 2020-03-21

好吧...我只是在日志中发现了一些时髦的东西。我发现我关闭后再打开电源的灯都不会报告其属性。我以为自己正在遇到另一个错误，但我没有，尽管从某种意义上说我认为我们可能还是想将其视为一个错误。

正如我提到的，我运行了一个脚本，每隔几秒钟就更改一次灯光级别。认为这可能会加剧宜家灯的问题。原来，这会重置d->idleLastActivity计数器，从而阻止运行任何空闲任务。包括配置属性报告：rofl：

djwlindenaar 于 2020-03-21

您是说IKEA灯在重启后会丢失其绑定和属性报告配置吗？

ebaauw 于 2020-03-21

看起来...他们不应该吗？

djwlindenaar 于 2020-03-21

我现在的问题是，由于我将设置升级到.75和50500，所以我的Docker容器每周至少丢失一次Conbee。重新启动容器会使事情再次发生...非常烦人

mvjt 于 2020-03-21

@djwlindenaar ，不，我不认为他们应该这样做。我见过的大多数设备都将这些设置保存在非易失性存储器中。我想ZigBee标准为这两种行为留有余地。

ebaauw 于 2020-03-21

不幸的是，虽然我的宜家灯泡运行得更好，但是一段时间后，我的一个小米传感器（圆形温度传感器）却没有反应。我会尝试在接下来的几天里嗅一些证据。

timbru31 于 2020-03-22

我正在运行Conbee 1，FW 26350500和Deconz 2.05.75。
这是我最近几周的经历
效果更好，但不是100％
我的一些IKEA E27TRÅDFRI灯泡E27 WS蛋白石980lm带固件2.3.007，有时无法回答OFF命令
我可以尝试再次将其关闭，并且通常可以正常工作（无需重启电源）

@tubalainen嗨，我注意到与2.3.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灯泡上

昨天早晨，两个E27灯（FW为2.3倍）没有关闭。

tubalainen 于 2020-03-23

@tubalainen您使用组命令还是单播命令？（即通过REST API，通过/ groups /或/ lights /设置状态）

我认为，只要灯光可以到达，实际上单播命令就更可靠。如果以某种方式错过了组广播命令，则不会重试。重试单播命令几次，直到交付为止。

djwlindenaar 于 2020-03-23

@tubalainen您使用组命令还是单播命令？（即通过REST API，通过/ groups /或/ lights /设置状态）
我认为，只要灯光可以到达，实际上单播命令就更可靠。如果以某种方式错过了组广播命令，则不会重试。重试单播命令几次，直到交付为止。

我使用家庭助理和RESt api。不知道家庭助理做什么...

tubalainen 于 2020-03-23

就我而言，它是带有deconz插件和Phoscon的iobroker。使用igroup时出现问题。群组场景撤回会触发无法关闭该群组，无法快速更改为其他群组场景设置或无法正确关闭的情况，尤其是在场景撤回后的15秒内。似乎deconz之前忙于该命令，或者2.3.x fw bulbs冻结（我怀疑）。尚无法在zigbee级别进行调试，以获得更好的理解。 deconz的分组功能是在uni cast命令中翻译的虚拟图层还是通过gui / zigbee中可用的分组选项完成的虚拟图层？最重要的是，我使用内置的分组功能，否则我将需要在iobroker中构建此虚拟层，并且没有理由使用分组功能。因此，如果是分组...与fw 1.2.x而不是2.3.x的区别是100％。发生了什么变化？是zigbee 2为什么它们的行为有所不同。

@tubalainen是的，这是很多工作，因为您可能需要不时重启或拉近灯泡。我用20 e14 tradfri做了两次。您应该看到巨大的进步。您是否注意到带有2.3..x的灯泡没有打开软灯。（淡入）和1.2.x一样吗？

但是只要手指交叉，即可复制更多内容，因此ikeas fw 2.3.x将可以在deconz中使用，因为我们需要及时升级。或更换灯泡。尽管zigbee 2也会很好。

谢谢大家的努力！

realwax 于 2020-03-24

@realwax @djwlindenaar @manup

昨晚一盏灯没有按预期的方式熄灭（宜家E27，固件版本为2.3.x）。我测试了如何改变没有关闭的灯的亮度，它立即变为我选择的亮度设置。更改亮度后的瞬间，灯光突然对关闭命令也反应良好。

我现在个人更改了Home Assistant中的所有自动化设置，以首先更改亮度，等待2秒钟，然后发送关闭命令。

到目前为止成功率达100％。

希望这可以为调查提供线索。

编辑：始终是距离协调（Conbee摇杆）最远的灯，无法关闭。（表明由于频段的性质必须啮合）

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

任何更新？我真的很想把整个房子换成我的Conbee II，但目前非常不稳定。我的色相效果很好，Conbee II没那么多🥺

EGruno 于 2020-04-01

👍1

到目前为止，我对RaspBee FW 0x26350500的最新deCONZ .75的体验非常好。

我的设备：
4xTradfri 980lu WS照明灯-固件2.3.007
17xTradfri 1000lu WS灯-固件2.0.023
3xTradfri插头-FW 2.0.022
3xTradfri圆形遥控器E1810-固件2.3.014
4个Aqara THP传感器

morfei1 于 2020-04-02

找到了另一个使宜家灯泡固件崩溃的固件。（我认为可以在deConz中修复）

今天早上我看到一盏灯没有回应。最后的通信如下所示。

看起来deConz确实收到了组成员身份响应，但是不知何故deConz没有收到灯发送的APS ACK（确认获取组成员身份请求）（我也没有看到MAC ACK）。结果，deConz重新发送了请求。该请求在ZCL中具有相同的编号，这会使轻型固件崩溃。

我猜想deConz会在相应的Response到达后立即考虑已确认该请求，而避免提出另一个请求。对？是否有用于该插件的API，可以调用该API取消请求？ @manup？

请注意，也可以通过不为这些请求请求APS ACK来解决此特定错误，这是当前REST API插件中的默认设置。

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

使用0x26350500运行v2.05.75已有两周了。它似乎比以前的版本稳定一些，但是我仍然偶尔会丢失通往Eurotronic Spirit TRV，Fyrtur百叶窗和小米lumi.curtain窗帘控制器的路线。后者是路由器；其他是终端设备。所有TRV都具有相同的硬件/固件版本，但是某些TRV的使用频率比其他TRV高。症状是一致的：设备继续向协调器发送报告，但是来自协调器的命令只会导致未得到响应的_Route Request_。

当前，嗅探和分析最常丢失的TRV的流量。沿途使用两个Hue灯，报告以三跳的形式到达协调员。我还捕获了一个从TRV到路途第一盏灯的_Data Request_，因此TRV似乎很高兴这是它的父级。来自TRV的OTAU集群的匹配描述符请求未得到答复。父级在其_Link Status_中报告下一个指示灯，但不在TRV中报告（因为它是终端设备？）。

_Link Quality Response_消息显示一个包含20个条目的邻居表，但TRV不在其中。小米门传感器（一直稳定）是。奇怪的是协调器，但是从TRV到协调器的报告是通过另一个路由器（也在邻居表中）转发的。
好的，现在协调器也包含在_Link Status_中，并且TRV的下一个报告将直接转发给协调器。

重新打开TRV的电源。 TRV发送MAC _Data Request_到（以前的）父节点；路由器以_Rejoin Response_作为响应，将TRV的旧NWK地址作为新地址传递。然后，TRV广播_Device Announcement_（向父级广播MAC单播；父级作为MAC广播转发）。 TRV向父设备发送_End Device Timeout Request_。父级向协调器发送_Update Device_，通知其TRV已安全地重新加入。父级现在还向协调器的_Route Request_发送_Route Reply_。在下一个_Link Quality Response_序列中，包含TRV。

我将继续保持嗅探器运行，希望赶上TRV再次失踪的时刻。

可能相关的注解：我的一个innr SP120智能插头仍然认为它是“色相”按钮的父级，在添加支持的同时，我短暂地加入了我的生产网络。从那以后，该按钮已经连接到我的测试网络了几个星期，并且我已经对电源插头进行了多次循环上电。我是否需要恢复出厂设置以使其忘记丢失的孩子？

ebaauw 于 2020-04-04

@manup ，很长时间了，因为任何代码和信息都将进行更新。您能否给我们提供有关您的团队在稳定性问题上的进展的最新信息，如果您也敢于按预期的时间表进行工作，请告诉我们。

osos 于 2020-04-05

👍5

我在deConz的路由行为中发现了另一个问题。

在这种情况下，deConz尝试通过Tuin linksvoor 3将消息路由到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

您的描述听起来像我的经历。我有一个更好的网络（conbee 1）和最新的固件。但是仍然会出现反应迟钝的灯泡，过一会儿又会反应迟钝。
我没有运行Home Assistant所提供的任何普通命令或设置，也没有运行灯泡的通常时间表。虽然，内部灯泡在白天（开/关或亮度）变化，而我的外部灯泡一天仅改变树次。有时无响应的灯泡很快就会恢复，如果我发出命令，它就会响应。很少（但确实如此），它需要更长的时间，或者我需要重启电源。

PeterRemnemark 于 2020-04-11

@djwlindenaar再次出色。非常感谢你！您是否正在与IKEA共享IKEA FW中的错误发现？

@djwlindenaar ：

当然，该指示灯（IKEA）应该表现出来并以一条失败消息作为响应，但是它不会，并且我们无法更改。

mvjt 于 2020-04-13

好吧，我没有。也许@manup可以对这样做的成功率发表评论，因为我相信他已尝试与宜家联系。
另外，我没有使用他们的最新固件。

也许联系硅实验室是一个更好的主意，因为这正是宜家的基础。我不确定这些错误是源于Ember代码还是宜家定制...

djwlindenaar 于 2020-04-13

@djwlindenaar您也可以尝试通过reddit进行联系： https : //www.reddit.com/user/TRADFRI他们在那里很活跃。

@manup有关Conbee II固件的新闻吗？

jurriaan 于 2020-04-13

将固件降级到0x264a0700我无法再连接到Conbee II。尝试降级为0x264a0700以及一些确实很旧的固件，刷新效果很好，但无法连接。任何建议如何重置Conbee II摇杆？

Adminiuga 于 2020-04-21

@manup有更新吗？我是否应该寻找除deConz之外的其他东西，或者正在解决该问题的工作？请给一个生命的迹象sign

EGruno 于 2020-04-24

我只是希望在尝试测试固件后让我的Conbee II重新工作...

Adminiuga 于 2020-04-24

@djwlindenaar您身边有任何更新吗？您的修复程序仍然是一个稳定的网络吗？

很高兴看到您的PR被

JBS5 于 2020-05-04

👍2

@djwlindenaar您身边有任何更新吗？您的修复程序仍然是一个稳定的网络吗？
很高兴看到您的PR被

@ JBS5我对这种情况感到满意。

对于我的网络，它显然已有改善。但是，我仍然看到宜家灯中的错误有时使deCONZ感到困惑。

关键是，有时IKEA路由器会静默丢弃某个路由的数据包。这种静默掉落是非法的，但是deCONZ应该通过找到一条新路线来对此做出反应，而事实并非如此。

看起来对deCONZ固件的更改确实可以改善这种情况，但是对于这些情况仍需要添加一些内容。当然，缺少APS ACK应该立即触发新的路由查找。

请注意， @ manup确实提到了源路由可以解决此问题，我认为在这种情况下尤其如此，因为这意味着我们不依赖网络中的路由器知道如何路由到远程节点。

我相信宜家灯中的错误是由于某些表无法容纳到远程节点的所有路由所致。因此，静默丢弃不知道其路由的任何数据包。

djwlindenaar 于 2020-05-05

谢谢@djwlindenaar。
正如前一阵子@manup在这里评论的那样，您是否知道前面提到的源路由将实现什么？

JBS5 于 2020-05-07

这是固件中需要进行的更改。我不隶属于deCONZ，所以我无法评论这种可能性...

@manup ？

导致我考虑离开deCONZ进入我的家庭网络...

djwlindenaar 于 2020-05-07

👍3

@djwlindenaar ，您正在考虑哪些替代方案？目前，我对Conbee II的稳定性没有印象。

EGruno 于 2020-05-07

这是固件中需要进行的更改。我不隶属于deCONZ，所以我无法评论这种可能性...
@manup ？
导致我考虑离开deCONZ进入我的家庭网络...

Zigbee2MQTT是不是做得更好呢？

lubbertkramer 于 2020-05-09

是的而已。

我实际上不知道这样做是否更好。请注意，那里使用的固件由芯片制造商提供。这些固件不是开源的。因此，如果他们遇到固件问题，则可能比deCONZ所受的支持还少。
另一方面，这些固件的配置是开源的。他们也已经支持源路由。

djwlindenaar 于 2020-05-09

芯片制造商仅提供SDK，如果您愿意，可以下载SDK，Simple Studio的试用版并自行编译固件。 Z2M确实提供了对固件所做的更改补丁。

Adminiuga 于 2020-05-09

大家好

抱歉，花了很长时间，这是ConBee II的新固件，该固件已移植了AVR固件0x26350500的所有路由修补程序。此外，它还改进了启动功能，以防止设备静音。（我们仍在测试各种情况，以永久解决启动问题）。

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

该版本可能是即将发布的deCONZ 2.05.76版本的一部分，ConBee I和RaspBee I版本0x26350500固件将通过更新按钮进行安装。

manup 于 2020-05-10

👍8

谢谢，@ manup。在我的测试网络上安装了此版本，它似乎可以正常工作。不同于52和53，至少可以控制设备。测试网络太小，无法检查此版本是否改进了路由。

ebaauw 于 2020-05-10

即使刷新了新固件， @ manup deCONZ仍然无法连接到ConBee II。有这个问题一段时间了。

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

这是GCFFlasher 3.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错误。

很高兴它现在可以正常工作，谢谢！我已经看到一个有问题的设备可以立即加入网络。因此，我希望该固件可以解决一些问题:)

jurriaan 于 2020-05-10

很高兴它现在可以工作。刚与大学讨论过有关引导加载程序的问题。版本2.05来自2019年的第一批ConBee II（约3500个），在某些情况下此版本有点粗糙。自2019年7月以来，我们发布了2.07，其中包含一些对看门狗处理的修复。

RaspBee II中已经有一个正在开发的新引导加载程序3.x，它具有更健壮的设计和协议来解决2.x版本的问题。

当前，我们不使用GCFFlasher更新ConBee II引导程序。我们尚未推出该功能，因为如果在修改启动向量表的那一刻引导加载程序更新被中止，则有一个微妙的机会使设备变砖。但是我认为我们可以通过使用ARM硬故障处理程序来解决这一问题。这个想法是，如果引导加载程序更新失败并触发了硬故障处理程序，则它可以检查引导加载程序是否有效，如果失败，它将跳入应用程序，在该应用程序中可以再次尝试进行引导加载程序更新。我们已经对硬故障处理程序进行了一些测试，这些测试看起来很有希望，但是要准备公开发布还需要一些时间。

manup 于 2020-05-11

👍4

你好

我今天用新固件刷新了，但是我仍然看到类似以下的日志：

0x000D6FFFFE540E7C错误APSDE-DATA。确认：任务上为0xA7

有关系吗

MartinTerp 于 2020-05-11

0xA7指示尚未提供APS ACK。我想这可能有多种原因。

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，是的，绝对是这样，我需要在本周内赶上本期的评论。如果我的记忆对我有益，那么已经有更多的想法可以改善其余的问题。

嗨，Manup，我可能正在劫持该线程，因此，请忽略。我在家庭助理上有一个Conbee ii，它运行良好，直到一个月左右。到那时，我所有的小米传感器都将变得不可靠，无法实现自动化。我有一些已经使用了两年的德累斯顿fls-pp控制器。这些连接到LED灯条，并用于偶尔断开网络连接，强制重新启动以使其重新启动。我最终将它们从我的Conbee网络中删除，然后整个网络稳定了。我离开了几天，然后重新引入了一个能工作数小时的设备，然后通宵达旦，我的Zigbee网络出现故障，直到关闭德累斯顿控制器，我才能使所有开关/传感器恢复在线。不知道为什么，对我而言，使用德累斯顿控制器现在会破坏我的Zigbee网络。我只是这个问题的新手，所以不确定是否有帮助/相关性，但是我一直在寻找有关此问题的评论，并在此线程上发生，因此以为我将自己的经验融为一体，以防万一。现在，我只是从网络中删除它们-不值得他们给我带来的头痛！
干杯

greybags 于 2020-05-21

嗨， @ djwlindenaar，是的，绝对是这样，我需要在本周内赶上本期的评论。如果我的记忆对我有益，那么已经有更多的想法可以改善其余的问题。
@manup ，可以肯定，我认为关键问题仍然是deCONZ仍然顽固地保留不起作用的路线。
我相信来自异常行为和受影响的光线的消息都会不断（通过其他路由）进入，并且固件会误解为好像无效路由仍在工作。如果未收到ACK，则deCONZ也倾向于很快放弃APS层请求。我认为它应该更持久和/或在重试过程中启动路由发现。
最后，我现在坚信源路由将消除路由器行为异常的主要问题。因此，如果您能够实现这一点，我们将处在更好的位置。我准备帮助/测试/调试...

由于路由问题，我决定迁移到zigbee2mqtt（最烦人的是偶尔需要重新配对宜家/小米）。我将在几周后在这里发布我的发现...

mvjt 于 2020-05-21

上周一，在我的Conbee I上刷新固件0x26350500（并将deCONZ更新为2.05.76）后，不幸的是GU10脱机了。

在VNC中，它有点灰色：

Phoscon：

在利用新固件版本中的路由修复功能之前，是否需要对所有指示灯进行强电供电？

JBS5 于 2020-05-27

@ JBS5 ，我认为不需要在固件升级后重新打开灯的电源（除非它们在升级前已关闭，否则它们不会神奇地恢复……）。
可能是由于以下事实：尽管有所改进，但我们仍未完全解决路由问题；请参阅我以前的帖子。

djwlindenaar 于 2020-05-28

@djwlindenaar谢谢。我明白。

就其价值而言，因为它与以前的固件具有相同的行为：

GU10标记为不可用后，它仍在响应组命令。几天后，两个电池供电的设备（Aqara运动传感器和小米/霍尼韦尔烟雾探测器）也都脱机了。 GU10仍在响应组命令。

GU10重新通电后，两节电池供电的设备也立即恢复在线。
因此，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以便对某些命令（例如控制命令）进行重试，但这只是一个。

堆栈本身可以配置为进行多次APS重试，直到放弃为止。但这会弄乱很多事情，并长时间阻塞队列。我认为最好考虑在REST-API中更细化。

最后，我现在坚信源路由将消除路由器行为异常的主要问题。因此，如果您能够实现这一点，我们将处在更好的位置。我准备帮助/测试/调试...

从理论上讲，源路由是解决所有问题的圣杯：)

但是在现实世界中，许多网关都不使用它（有吗？），这意味着大多数产品要么不支持源路由，要么未经测试。恕我直言，使其在混合网络中工作的机会非常低。但是，距离我在该级别上比较各种网关已有一段时间了。当今对哪些网关使用哪种路由方法有一个概述。

manup 于 2020-05-29

👍3

当今对哪些网关使用哪种路由方法有一个概述。

很乐意帮助测试/嗅探Hue桥接器（第2代和第1代），Inrr网关，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以便对某些命令（例如控制命令）进行重试，但这只是一个。
堆栈本身可以配置为进行多次APS重试，直到放弃为止。但这会弄乱很多事情，并长时间阻塞队列。我认为最好考虑在REST-API中更细化。

堆栈确实重试了一些，我记得如果没有记错的话，它会尝试三次。在我看来，您可以在该代码段中添加一个行为以使关联的路由无效，然后重试一次或两次。或者，也许您可以在堆栈内部有一个回调来实现该行为。那应该引起路线发现，对吗？

最后，我现在坚信源路由将消除路由器行为异常的主要问题。因此，如果您能够实现这一点，我们将处在更好的位置。我准备帮助/测试/调试...
从理论上讲，源路由是解决所有问题的圣杯：)
但是在现实世界中，许多网关都不使用它（有吗？），这意味着大多数产品要么不支持源路由，要么未经测试。恕我直言，使其在混合网络中工作的机会非常低。但是，距离我在该级别上比较各种网关已有一段时间了。当今对哪些网关使用哪种路由方法有一个概述。

老实说，我对这个问题不是很担心。在源路由的情况下，路由器的行为非常简单。尤其是将其与自行路由所需的行为进行比较时。基本上，路由器中NWK层要做的唯一一件事就是检查源路由是否已启用，从数据包中读取下一跳并将其返回给MAC层。没有表，没有内存，没有错。我不确定是否针对zigbee认证检查了基本行为，但可以肯定的是，与常规路由相比，它比zigbee更为简单，而且出错的可能性也要小得多。

我的期望是协调员很少会实现它，因为复杂性在于协调员固件中。实际上，也很少有（消费者）zigbee实现专注于可从此路由模式中受益的大型网络。

最后，我认为这是混合网络的最佳路由模式，因为常规路由取决于路由器的个别实现，尤其是链路质量指示不明确的情况。由于源路由非常简单（=实施错误的可能性很小），因此我相信在常规路由行为之前。

所以...话虽如此，如果您可以提供固件，我准备为您进行测试。我在打麻将上，嗅探器已准备就绪。

djwlindenaar 于 2020-05-30

最后，我认为这是混合网络的最佳路由模式，因为常规路由取决于路由器的个别实现，尤其是链路质量指示不明确的情况。由于源路由非常简单（=实施错误的可能性很小），因此我相信在常规路由行为之前。

吻-对我来说很有意义。

ebaauw 于 2020-05-30

堆栈确实重试了一些，我记得如果没有记错的话，它会尝试三次。在我看来，您可以在该代码段中添加一个行为以使关联的路由无效，然后重试一次或两次。或者，也许您可以在堆栈内部有一个回调来实现该行为。那应该引起路线发现，对吗？

如果我正确理解已经发生的代码，那么问题在于，由于其他因素（正在调查中），路由似乎仍然有效。

老实说，我对这个问题不是很担心。在源路由的情况下，路由器的行为非常简单。尤其是将其与自行路由所需的行为进行比较时。基本上，路由器中NWK层要做的唯一一件事就是检查源路由是否已启用，从数据包中读取下一跳并将其返回给MAC层。没有表，没有内存，没有错。我不确定是否针对zigbee认证检查了基本行为，但可以肯定的是，与常规路由相比，它比zigbee更为简单，而且出错的可能性也要小得多。

我只能代表我通过认证（FLS镇流器）带来的基于BitCloud的产品。在认证过程中，从未对它们进行源路由测试。我不确定在编译时是否在堆栈中启用了它。请注意，大多数堆栈都配置为使用最少的必需功能进行编译以节省空间。

我个人很少使用/测试过的功能的经验，无论它们在理论上多么简单，都总是存在错误。例如，对于FLS，我们必须修复示例BitCloud堆栈应用程序中的大量错误。我知道飞利浦还为他们的某些产品在BitCloud堆栈中进行了大量改进。

我的期望是协调员很少会实现它，因为复杂性在于协调员固件中。实际上，也很少有（消费者）zigbee实现专注于可从此路由模式中受益的大型网络。

由于固件对整个网络拓扑或闪存空间没有足够的了解，因此需要在deCONZ REST-API插件或新的路由器插件中实现复杂性。为此，可以使用源路由选项扩展deCONZ::ApsDataRequest ，以std::vector<quint16>保存路径的nwk地址。

我对由此带来的复杂性没有一个很好的了解，当前由网状路由处理。需要至少并大规模考虑以下任务：

网络拓扑的递归查询（Mgmt_Lqi_req）。多数民众赞成，这很容易，它已经适用于网格路由，并且可以适用于源路由。
节点下电。在这里，一些逻辑需要选择备用路由，如果它们的链接也断开了，那么这可能也不起作用。
节点再次上电。
更改nwk地址的节点。
终端设备改变父母。
终端设备加入后，在多跳网络中，如果不查询网络，我们就不会知道父设备。

我们还不知道的是：

所有路由器都支持源路由吗？
是否有使用源路由的商业网关？在这里，我们需要嗅探流量并查看NWK标头，它们包含源路由并设置了相应的标志。
对于支持源路由的设备，其工作情况如何？

manup 于 2020-05-31

我只能代表我通过认证（FLS镇流器）带来的基于BitCloud的产品。在认证过程中，从未对它们进行源路由测试。我不确定在编译时是否在堆栈中启用了它。请注意，大多数堆栈都配置为使用最少的必需功能进行编译以节省空间。

我不熟悉它的工作原理，但是堆栈是否也通过了某种方式的认证？

我个人很少使用/测试过的功能的经验，无论它们在理论上多么简单，都总是存在错误。例如，对于FLS，我们必须修复示例BitCloud堆栈应用程序中的大量错误。我知道飞利浦还为他们的某些产品在BitCloud堆栈中进行了大量改进。
我的期望是协调员很少会实现它，因为复杂性在于协调员固件中。实际上，也很少有（消费者）zigbee实现专注于可从此路由模式中受益的大型网络。
由于固件对整个网络拓扑或闪存空间没有足够的了解，因此需要在deCONZ REST-API插件或新的路由器插件中实现复杂性。为此，可以使用源路由选项扩展deCONZ::ApsDataRequest ，以std::vector<quint16>保存路径的nwk地址。

我不明白这句话。源路由完全在堆栈的NWK级别处理。 bitcloud堆栈应具有一些编译时（或运行时可能性较小）标志，以启用源路由。根据协调器每隔几分钟发送一次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.

我相信这些都是由bitcloud堆栈中的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级别处理。 bitcloud堆栈应具有一些编译时（或运行时可能性较小）标志，以启用源路由。根据协调器每隔几分钟发送一次MTORR，基于我们已经存在于网络中的路由记录消息，有一个源路由表由堆栈保持最新状态。

基本上，对于网络中的每个设备，通过MTORR知道到协调器的路由
协调器通过“路由记录”消息了解到每个设备的每个（完整）路由。无需分析，只需将RR消息的复制粘贴到源路由表中

参见zigbee规范第3.6.3.5.4章和第3.6.3.3章

啊，您是对的，愚蠢的我，我在某种程度上用一般节点发现（facepalm）误解了它。
堆栈确实可以找出很多适当的路由记录命令，但是我已经遇到了没有发送任何命令的情况，请参见下文。

今天，我已经尝试了许多配置，似乎源路由可以工作，但仅当禁用网状路由且对于之前发送路由记录命令的设备有效。

我的飞利浦Hue运动传感器出现问题，并发送广播NWK地址请求以获取网关NWK地址。在这种情况下，没有路由记录帧被优先发送（我认为是由于广播）。由于禁用了网状路由，因此网关未启动路由发现，因此未建立与传感器的通信。

当在源路由旁边启用网状路由时，尽管两者均已启用，但似乎不再使用源路由。

我需要做更多的测试，我认为当路由缓存中已经有路由记录条目时，应避免进行网状路由发现。代码非常复杂，我需要在这里进行更深入的研究。

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

这是同时启用网格和源路由的固件（路由记录表大小为32）。您可以尝试一下，但是正如我较小的网络源路由中所提到的那样，该配置并未触发。

manup 于 2020-06-03

👍2

我在覆盆子上，所以不能测试那个。您也可以为此创建一个吗？
我想知道我们是否可以通过一种静态路由来解决此问题，该静态路由可以在启动时上传到固件，或者可能确实基于其他信息。
另外，在更改源路由后，您是否修理了该设备？想知道终端设备是否需要某种交互才能识别MTOR和源路由。当然，当他们的接收器关闭时，他们不会收到广播的MTOR消息。
顺便说一句，我确实看到我的小米终端设备在嗅探中发送了路线记录...

djwlindenaar 于 2020-06-03

我已经带领上述固件运行了一整夜。似乎在启用网状路由的情况下也使用了源路由，但是很少。从大约仅2个数据包<5使用了源路由。

我在覆盆子上，所以不能测试那个。您也可以为此创建一个吗？

不确定，如果可能，我需要检查ConBee I和RaspBee I使用的其他堆栈配置。

我想知道我们是否可以通过一种静态路由来解决此问题，该静态路由可以在启动时上传到固件，或者可能确实基于其他信息。

是的，我认为应该可以将路由以某种方式注入到路由缓存中。但是当我们回到上面提到的问题时，要保持路线。无论如何，为了测试目的和固定网络，它将提供一种有用的方式来配置路由。

另外，在更改源路由后，您是否修理了该设备？想知道终端设备是否需要某种交互才能识别MTOR和源路由。

不，我只是更新了固件，没有修复-收到路由记录命令后不久就建立了源路由。

顺便说一句，我确实看到我的小米终端设备在嗅探中发送了路线记录...

宜家似乎也适用于此，我想对飞利浦和其他品牌设备进行更多测试，以获取更多详细信息，说明如何将各种设备与源路由一起使用。

manup 于 2020-06-04

👍1

如果我们可以使其适用于Raspbee，我也可以进行测试。

SwoopX 于 2020-06-04

我已经带领上述固件运行了一整夜。似乎在启用网状路由的情况下也使用了源路由，但是很少。从大约仅2个数据包<5使用了源路由。

有趣！当使用源路由以及它是否可以以某种方式受到影响/调整时，能够很好地了解决策逻辑。

我在覆盆子上，所以不能测试那个。您也可以为此创建一个吗？
不确定，如果可能，我需要检查ConBee I和RaspBee I使用的其他堆栈配置。

会很好...

我想知道我们是否可以通过一种静态路由来解决此问题，该静态路由可以在启动时上传到固件，或者可能确实基于其他信息。
是的，我认为应该可以将路由以某种方式注入到路由缓存中。但是当我们回到上面提到的问题时，要保持路线。无论如何，为了测试目的和固定网络，它将提供一种有用的方式来配置路由。

同意

另外，在更改源路由后，您是否修理了该设备？想知道终端设备是否需要某种交互才能识别MTOR和源路由。
不，我只是更新了固件，没有修复-收到路由记录命令后不久就建立了源路由。

想知道这对飞利浦设备是否有帮助...

djwlindenaar 于 2020-06-04

大家好，我已经运行Z2M源路由固件24小时（仅允许5个直接连接）。我有约35台设备。它工作正常，但我注意到从默认固件迁移到SR固件后，Hue设备需要重新启动电源。宜家和小米自动重新上台。也许这可以解释您看到的部分Hue行为？

mvjt 于 2020-06-06

你好
我使用宜家固件2.3.050和Conbee I上最新的deconz beta和最新固件对TRADFRI灯泡E14 WS蛋白石400lm进行了重新测试。我可以确定灯泡和通讯性能得到了改善。现在，场景调用，打开/关闭，淡入和淡出效果更好，但是还存在问题。

＃2518此处记录的问题已基本解决。似乎组命令（不是phoscon gui）工作得更好。第2518章封闭

我已经注意到，如果不通过人工而不是现场进行更改，则有时需要多次触发更改CT才能成功。

出现的新问题＃2892是，如果在一个组中调用了一个场景，并且所有的灯泡都已打开（由于该场景），后来又打开了该组中的另一个场景，只打开了几个灯泡（由场景定义）记得，应该关闭的“不需要的”灯泡会保持打开状态。
此外，如果关闭组，则仅关闭当前定义的场景灯泡，而之前的其他灯泡（该组中的先前场景）保持打开状态。他们需要先执行几个关闭命令。
此问题已在此处进行了描述，但可以肯定地存在于API中，因为使用Phoscon或api本身不会产生任何影响。 https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

附加说明：使用2020年2月5日发布的最新ikea fw 2.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的源路由固件版本的新闻吗？我期待测试：)
我第一次启用它的尝试以可怕的编译时错误结束：/尚未弄清楚是什么原因，并希望以某种方式进行编译。

Hmmmm听起来不太好...

djwlindenaar 于 2020-06-21

@manup ，有什么进展吗？

djwlindenaar 于 2020-07-03

@ manup ，

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

最新的问题是什么？

我有大约20个白色光谱GU10（第一代）连接到Hue桥，作为我的Zigbee网络合理化的一部分，我想将我的所有设备迁移到Deconz。

色相非常稳定，但是灯光仍然不时离线（例如，每周一次，一个灯光离线）。我只需要重新启动灯泡即可使它们恢复活力。

Deconz或多或少稳定？

ReX1983 于 2020-08-14

没有Deconz不会更稳定，我也有大约40个宜家灯，有时有些不在线

salopette 于 2020-08-14

❤1

@salopette我没有那个经验。您介意打开一个单独的问题吗？有日志吗？

Mimiix 于 2020-08-14

@Mimiix此问题与离线的灯光有关。为什么要开新刊？

JBS5 于 2020-08-14

同样在这里。灯光仍然偶尔会离线。但是随着时间的推移，它有了很大的改进。当我于2018年开始使用deCONZ时，我几乎每天都要对宜家灯进行电源重启。我最经常在FLOALT面板上遇到此问题，但这也是距我的Conbee Stick最远的距离。

peer69 于 2020-08-14

@ JBS5因为我们对该用户的设置一无所知。没有版本，没有日志，没有安装信息。我们无法确定他的问题是否与此有关。

在没有任何信息的情况下添加评论在这种情况下无济于事。这就是为什么我想要单独的问题，所以我们有一个更好的概述。

我曾经私下要求@manup对此进行调查并确定其优先级。

Mimiix 于 2020-08-14

@djwlindenaar一直在深入研究。我怀疑检查其他用户设置是否可以解决宜家灯通常存在的问题。我宁愿专注于现有的调查，也不愿进行其他调查。

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周。在这里等待过时的机器人;）

Pmed @manup今天早上再次。得到了以下回应：

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周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。

那么现在2-3周过去了，预计到达时间是多少

lubbertkramer 于 2020-09-04

👍2 👎1

@lubbertkramer在这里请合理，这个过时的机器人是个玩笑。 @Mimiix之前所做的唯一承诺是在有可用更新时共享更新，因此询问当前状态是完全有效的。现在，对于ETA来说，没有人承诺，我也不会，因为这很复杂。据我所知，manup在谈论令人讨厌的事情时，很遗憾，一天之内无法解决所有问题，只有经过相当长的时间才能显示出来，或者会产生一些无法预料的副作用。

因此，从这种意义上讲，请耐心等待，让大家继续努力（顺便说一下，这仍然是休假时间）。说到下一个版本，大约需要1.5周的时间来举手并询问一些消息。

SwoopX 于 2020-09-04

👍1

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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来说，没有人承诺，我也不会，因为这很复杂。据我所知，manup在谈论令人讨厌的事情时，很遗憾，一天之内无法解决所有问题，只有经过相当长的时间才能显示出来，或者会产生一些无法预料的副作用。
因此，从这种意义上讲，请耐心等待，让大家继续努力（顺便说一下，这仍然是休假时间）。说到下一个版本，大约需要1.5周的时间来举手并询问一些消息。

我认为，在2-3周过去了3周而没有采取后续行动的情况下，让人们通过沟通或许诺而不发表“笑话”更为合理。由于缺乏后续/沟通，已经做了很多调查并在此处回复的用户已经继续前进。

那么回到问题上，关于此问题的最新信息是什么？

lubbertkramer 于 2020-09-04

👍2 👎1

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少

当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。

所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。

_成为您想在这个世界上看到的变化_

Mimiix 于 2020-09-05

❤1 👎1

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_

没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。

现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？

lubbertkramer 于 2020-09-05

👎1 👍1

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_
没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。
现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？

我所拥有的就是我所说的。请让我建议您控制自己的情绪。我了解您的愤怒，但不尊重别人无济于事。我不接受任何火红的味道。保持话题性和民间性。我只是解释一下我的观点是什么，为什么我会像以前那样做。

如果您想提出投诉的问题，请成为我的客人。只是不要在本期中这样做。

Mimiix 于 2020-09-06

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_
没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。
现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？
我所拥有的就是我所说的。请让我建议您控制自己的情绪。我了解您的愤怒，但不尊重别人无济于事。我不接受任何火红的味道。保持话题性和民间性。我只是解释一下我的观点是什么，为什么我会像以前那样做。
如果您想提出投诉的问题，请成为我的客人。只是不要在本期中这样做。

这个问题唯一的尴尬是手册，而德累斯顿显然无法解决这个问题。 Conbee是一种商业产品，随之而来的是责任。这就是为什么我们许多人已经将deCONZ / Conbee留给TI芯片和Z2M的原因，自那以后它一直在完美工作。

mvjt 于 2020-09-06

👍3

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_
没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。
现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？
我所拥有的就是我所说的。请让我建议您控制自己的情绪。我了解您的愤怒，但不尊重别人无济于事。我不接受任何火红的味道。保持话题性和民间性。我只是解释一下我的观点是什么，为什么我会像以前那样做。
如果您想提出投诉的问题，请成为我的客人。只是不要在本期中这样做。

同样，您没有回答或更新多次询问的状态，唯一要做的就是继续进行脱位讨论，在该讨论中您可能已经按照每篇文章的结尾进行了更新。您正在吹嘘开发会议中的直接联系/邀请，因此您应该尽快了解此问题的状态，并可以在此处更新所有阅读用户。

因此，再次发布更新或停止发布offtopic，我想这是您作为社区主持人的工作，而不是保持offtopic讨论活跃:)

一般公告：
我只是私下与@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

一个新的依赖者将在不到一周的时间内到来。我建议保持冷静
等一下看看新的变化会带来什么

我有很多tradfri的工作已经一年有余了。
最近，我开始只用一个Tradfri灯有问题
开始大约每15分钟掉落并连接到网格。 15分钟
可达，无法到达15分钟。做了大量测试以发现问题。
猜猜是什么...问题是什么？不是来自deCONZ，而是我的WiFi
直放站时间表已引起人们的关注。

不确定问题是否总是与deCONZ有关，有时与问题无关。

2020年9月6日，星期日，lubbertkramer [email protected]写道：

@ JBS5 https://github.com/JBS5还没有3周。等待过时的机器人
这里 ;）
Pmed @manup https://github.com/manup今天早上再次。得到了
以下回应：
最近几天一直在搜寻固件，以调查重新启动问题并发现一些讨厌的错误。
它还将包含一些路由更改，希望在即将发布的版本中能够解决。
在下一个稳定版本之后，将进行调试增强。
我要求提供ETA，而他目前正在接受。
好吧，您对社区做出了承诺，所以他们对您的支持是正常的
兑现承诺，21天/ 7天= 3周
那么当这个问题已经存在时，隐藏在stalebot后面很la脚
自2019年2月起开始活跃。当您想成为德累斯顿的代言人时
像这样操作或让@manup https://github.com/manup处理:)
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。
我绝不是发言人，我在这里伸出脖子来拿东西
排序方式与我有直接关系。我用来跟踪的过时机器人
问题，我确实收到了通知。我希望manup能回到我身边，
如果时间跨度过时，过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果你做了我为
社区，您会比这更了解。还要补充一点，不是
我一生中没有其他事情要做。
成为您想在这个世界上看到的改变
没有人要求或强迫您成为用户的中间人，所以再次
而不是燃烧和改变花朵的力量将这个问题保留为
发言人或返回问题和最新的intel。
已过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个” =少付钱）。无论有无假期，都无法解决。
有人（我曾多次）说过，当客户遇到大问题时，官方支持是如何工作的。
暂无记录：ZHA在1-2周内将正式支持Silabs EZSP所有版本的堆栈协议，因此我认为，最好用Sonoff Zigbee Bridge或Elelabs-ELU013 / ELR023投入资金，然后再获得更多RF和SoC电源DE产品和社区的更好支持。
但是我在等待所有DE产品的RIP之前等待deCONZ REST-API版本2。

MattWestb 于 2020-09-06

@ JBS5还没有3周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_
没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。
现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？
我所拥有的就是我所说的。请让我建议您控制自己的情绪。我了解您的愤怒，但不尊重别人无济于事。我不接受任何火红的味道。保持话题性和民间性。我只是解释一下我的观点是什么，为什么我会像以前那样做。
如果您想提出投诉的问题，请成为我的客人。只是不要在本期中这样做。
同样，您没有回答或更新多次询问的状态，唯一要做的就是继续进行脱位讨论，在该讨论中您可能已经按照每篇文章的结尾进行了更新。您正在吹嘘开发会议中的直接联系/邀请，因此您应该尽快了解此问题的状态，并可以在此处更新所有阅读用户。
因此，再次发布更新或停止发布offtopic，我想这是您作为社区主持人的工作，而不是保持offtopic讨论活跃:)
一般公告：
我只是私下与@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周。在这里等待过时的机器人;）
Pmed @manup今天早上再次。得到了以下回应：
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后面是la脚的事情。
那么现在2-3周过去了，预计到达时间是多少
当您这样行事时，我不会把这个问题抛在后面。我绝不是发言人，我是在这里伸出脖子来整理我有直接关系的东西。我使用过时的漫游器来跟踪问题，并且确实收到了通知。我希望manup可以回到我身边，如果时限过去了，那台过时的漫游器会帮助我提醒。
所以不，它不是藏在它后面的“ lam草”。如果您做了我为社区所做的事情，那么您会比这更清楚。另外要补充一点，这并不是说我生活中没有其他事情要做。
_成为您想在这个世界上看到的变化_
没有人要求或强迫您成为用户的中间人，因此不要再发火和改变花力，而是让该问题成为发言人，或者回到问题和最新的情报上。
现在已经过了2-3个星期，而您已在3个多星期前发布为一般公告，那么后续措施是什么？
我所拥有的就是我所说的。请让我建议您控制自己的情绪。我了解您的愤怒，但不尊重别人无济于事。我不接受任何火红的味道。保持话题性和民间性。我只是解释一下我的观点是什么，为什么我会像以前那样做。
如果您想提出投诉的问题，请成为我的客人。只是不要在本期中这样做。
同样，您没有回答或更新多次询问的状态，唯一要做的就是继续进行脱位讨论，在该讨论中您可能已经按照每篇文章的结尾进行了更新。您正在吹嘘开发会议中的直接联系/邀请，因此您应该尽快了解此问题的状态，并可以在此处更新所有阅读用户。
因此，再次发布更新或停止发布offtopic，我想这是您作为社区主持人的工作，而不是保持offtopic讨论活跃:)
一般公告：
我只是私下与@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在我再次问他之后告诉我的。我不能强迫任何人做某事。周末过后我再问。
这将是对您的评论的一般性最后警告。 在这里，下一个话题外的话题是锁定这个问题，直到有更多消息为止。

那是一个答案，所以当我正确阅读时，我们可以期望本周晚些时候提供更详细的答案，因为已经过去了将近4个星期，而不是@manup通过您传达的2-3个一般性公告，即更新将是有空

@Mimiix如果您看到关闭这个问题的冲动已经接近两年了，并且从非常支持和专用的用户那里获得了大量信息而又没有解决方案，那么我不是可以阻止您的人，这取决于您是社区发言人：）

lubbertkramer 于 2020-09-06

👍1

@lubbertkramer我说了锁，没有关闭。

这样，我将锁定此问题。 我将在几天后或Manuel在这里回复时解锁。

Mimiix 于 2020-09-06

再次嗨，你猜想是时候更新这个问题了。

但是首先要说的是，如果有人要责备这里，那就是我，只有我。我了解这种挫折感，但是这里对@Mimiix毫无礼貌，所以让我们成为平民吧，如果不是对他来说，他在这个社区中所取得的一切，我将没有时间去做。在deCONZ核心和固件中，并进行错误修复和改进。过去比较容易，但是由于整个过程像疯了似的，待办事项列表，支持电话和电子邮件都像疯了一样增长，而重启循环错误是我个人的地狱。多亏了主持人以及所有出色的开发人员和贡献者，现在情况看起来更好了，一次解决了更深层次的问题。

进度更新

（下一个版本的预览）

我已经对源路由进行了很多测试，并尝试了本期的发现和各种嗅探器日志。根据传入的“路由记录”命令，花费大量时间使“自动”源路由可靠地工作。基本上，大多数采用源路由的实现都是这样做的，例如zigbee2mqtt的源路由固件。有时这种方法行得通，但是基于混合路径中的路由记录跃点从邻居那里看到的LQI / RSSI值，如何/是否选择（并保留）源路由似乎存在更大的动态，这很棘手。因为堆栈和硬件上的差异。如果人们在节点之间移动并且门被打开和关闭，链接质量也可能非常动态，这同样会影响路由。

因此，我尝试了配置指向目标节点的固定源路由的想法。在许多情况下，只有一部分网络存在路由问题，在这里指定固定的源路由可能会有所帮助，其中：

可以根据每个节点选择指定源路由。
每个跃点都应始终通电。
路径中的跃点位置应该合理。在某些情况下，与自动算法可以算出的结果相比，用户可能有一个更好的计划，即数据包应该路由到何处。

为此，已将固件协议扩展为根据每个APS请求提供源路由。可以配置多少个源路由没有限制，固件只需要在请求和ACK中保留一些即可。

deCONZ会自动计算出路由上的每个跃点是否可达，并且仅在这种情况下才使用源路由。
在后台，为源路由配置了节点的MAC地址，以抵抗NWK地址更改。

创建固定的源路由

在deCONZ gui中，选择所有跃点，同时按住CTRL（多选），从协调器（源）开始到目标节点。 重要的是，源和目的地之间至少要有一跳。
右键单击目标节点以打开上下文菜单。
选择“添加源路径”。

这将创建新的源路由，通过蓝线将其可视化，红色结束标记指向目标节点。

（在以后的版本中，可以指定备用的备用路由，但是我需要为此找到一个好的用户界面。）

删除源路由：在目标节点上下文菜单中选择“删除源路由”。

该路线将用于下一个请求：

这可以很好地工作，并允许在需要时手动覆盖路由，也应该方便进行测试。
当前，这仅在通过GUI配置时才有效，但以后也应通过REST-API使用。

这会解决所有问题吗？

不太可能，但是它应该改善到目的地的路由（无法在节点上配置路由）。请注意，固定的源路由仅适用于路由器，因为终端设备倾向于更改父路由，并且源路由不再起作用，在这种情况下，自动源路由可能会更好。

什么时候发布？

很快，在下一个2.05.81版本中，我在该版本的待办事项列表上有以下（相当轻）的项目：

在数据库中存储/恢复源路由。
修复NWK安全计数器的处理，以修复不同ConBee / RaspBee之间的备份并重新启动没有任何工作的bug。
让GCFFlasher验证固件在更新后是否正在运行。

manup 于 2020-09-06

❤10

因此，通过@manup他的回答，已经给出了答案。 请保持主题和主题。

Mimiix 于 2020-09-07

再次嗨，你猜想是时候更新这个问题了。
进度更新
（下一个版本的预览）
我已经对源路由进行了很多测试，并尝试了本期的发现和各种嗅探器日志。根据传入的“路由记录”命令，花费大量时间使“自动”源路由可靠地工作。基本上，大多数采用源路由的实现都是这样做的，例如zigbee2mqtt的源路由固件。有时这种方法行得通，但是基于混合路径中的路由记录跃点从邻居那里看到的LQI / RSSI值，如何/是否选择（并保留）源路由似乎存在更大的动态，这很棘手。因为堆栈和硬件上的差异。如果人们在节点之间移动并且门被打开和关闭，链接质量也可能非常动态，这同样会影响路由。
因此，我尝试了配置指向目标节点的固定源路由的想法。在许多情况下，只有一部分网络存在路由问题，在这里指定固定的源路由可能会有所帮助，其中：
可以根据每个节点选择指定源路由。
每个跃点都应始终通电。
路径中的跃点位置应该合理。在某些情况下，与自动算法可以算出的结果相比，用户可能有一个更好的计划，即数据包应该路由到何处。
为此，已将固件协议扩展为根据每个APS请求提供源路由。可以配置多少个源路由没有限制，固件只需要在请求和ACK中保留一些即可。
deCONZ会自动计算出路由上的每个跃点是否可达，并且仅在这种情况下才使用源路由。
在后台，为源路由配置了节点的MAC地址，以抵抗NWK地址更改。
创建固定的源路由
在deCONZ gui中，选择所有跃点，同时按住CTRL（多选），从协调器（源）开始到目标节点。 重要的是，源和目的地之间至少要有一跳。
右键单击目标节点以打开上下文菜单。
选择“添加源路径”。
这将创建新的源路由，通过蓝线将其可视化，红色结束标记指向目标节点。
（在以后的版本中，可以指定备用的备用路由，但是我需要为此找到一个好的用户界面。）
删除源路由：在目标节点上下文菜单中选择“删除源路由”。
该路线将用于下一个请求：
这可以很好地工作，并允许在需要时手动覆盖路由，也应该方便进行测试。
当前，这仅在通过GUI配置时才有效，但以后也应通过REST-API使用。
这会解决所有问题吗？
不太可能，但是它应该改善到目的地的路由（无法在节点上配置路由）。请注意，固定的源路由仅适用于路由器，因为终端设备倾向于更改父路由，并且源路由不再起作用，在这种情况下，自动源路由可能会更好。
什么时候发布？
很快，在下一个2.05.81版本中，我在该版本的待办事项列表上有以下（相当轻）的项目：
在数据库中存储/恢复源路由。
修复NWK安全计数器的处理，以修复不同ConBee / RaspBee之间的备份并重新启动没有任何工作的bug。
让GCFFlasher验证固件在更新后是否正在运行。

感谢您的详细答复，我想我们很多人都在等待像上面这样的答复，因为社区为解决此问题而付出了辛勤的工作，而您作为开发人员正在做。

我有几个后续问题：

上述内容何时才能作为Beta /稳定版的更新提供？
关于conbee 1/2和Raspbee，上述工作方式会有所不同吗？还是全部相同？
对于2.05.81更新，您提到待办事项列表上有相当（较轻）的项目，我们何时可以期待该更新（也许是向该git添加路线图的主意？）

lubbertkramer 于 2020-09-07

嗨@lubbertkramer

我可以回答数字1：预计在每月的15日（Windows构建会在几天后）发布2.05.81版。我已经在Discord的较早版本中将其发布，但是我只是认为Github并非如此。我会将其添加到自述文件中！我的错！

编辑：做了readme.md文件的请求请求。我不确定稳定通道的运行方式，有一点需要澄清。

Mimiix 于 2020-09-07

👍3

关于conbee 1/2和Raspbee，上述工作方式会有所不同吗？还是全部相同？

它应该工作相同，现在我已将代码移植到RaspBee I / ConBee I，并且以相同的方式使用了源路由。

我目前有一个奇怪的情况，一个IKEA中继器插头还活着，但不想与网络的其余部分一起玩。
发送给它的命令（带有和不带有源路由）将被静默忽略。

转发器发送其NWK链接状态帧，但报告并清空邻居列表：

来自协调器以及以中继器为父级的OSRAM传感器的命令将被忽略。像许多小米设备一样，该传感器不会尝试自动寻找新的父对象...糟糕的情况：

这种情况现在已经运行了两天，还没有找到恢复中继器的方法。中继器的重启可能会解决此问题，但是我现在将其保持这种状态，以查看是否可以通过空中解决该问题。

manup 于 2020-09-11

👍2

Tradfri USB中继器或Tradfri插头有问题吗？

morfei1 于 2020-09-11

在这种情况下，它是插件，我不确定它是否是最新版本，需要稍后进行检查。

manup 于 2020-09-11

可以检查吗？我有3个Tradfri插头运行了大约1.5年的最新FW坚如磐石。如果我开始使用新Beta遇到麻烦，则必须延迟更新。

谢谢！

morfei1 于 2020-09-11

这是来自基本群集的数据，请注意，该问题最初是两天前在我的家庭网络中发生的，当时该家庭当时没有新固件。

manup 于 2020-09-11

看来您正在使用最新的固件。我希望是这样，因为宜家的FW ...

包含tradfri更改日志的网页已关闭，以检查最新固定的固件。

morfei1 于 2020-09-11

最新的固件文件现在在线：

这些都启用了源路由，最大值为 32条源路由，其中最早的条目将自动被较新的条目替换。以后的版本中可能会增加该数量，但是应该已经可以正常使用了。
如果存在源路由和“正常”路由条目，则首选源路由。这是非标准的，但效果更好。
该固件对串行协议的鲁棒性进行了总体改进。
ConBee II和RaspBee II改进了帧计数器处理能力，以缓解在重启后网络似乎丢失的问题，直到帧计数器再次达到其旧值为止。

manup 于 2020-09-14

❤7 🚀3 👍2

@manup我是否为ConBee删除了version命令ID 0x0D固件？我对此命令不再有任何反应

Adminiuga 于 2020-09-15

@Adminiuga @manup关于固件的事情：请使用＃3260。

Mimiix 于 2020-09-15

最新的固件文件现在在线：
康比II
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF
RaspBee II
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_RaspBeeII_0x26650700.bin.GCF
RaspBee I和ConBee I
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26370500.bin.GCF
这些都启用了源路由，最大值为 32条源路由，其中最早的条目将自动被较新的条目替换。以后的版本中可能会增加该数量，但是应该已经可以正常使用了。
如果存在源路由和“正常”路由条目，则首选源路由。这是非标准的，但效果更好。
该固件对串行协议的鲁棒性进行了总体改进。
ConBee II和RaspBee II改进了帧计数器处理能力，以缓解在重启后网络似乎丢失的问题，直到帧计数器再次达到其旧值为止。

如何刷新此固件（我使用marthoc的deCONZ Docker映像）？

我已经下载了文件（ConBee II），但是手动更新说明不适用于marthoc的deCONZ Docker映像，并且marthoc的deCONZ指南不允许使用映像中未包含的固件（并且该文件未列出）可用）。

ReX1983 于 2020-09-18

如何刷新此固件（我使用marthoc的deCONZ Docker映像）？

我只是将USB加密狗插入Windows笔记本电脑，然后从那里进行操作，完成后再回到Synology NAS中。

frlarsendeloitte 于 2020-09-19

👍1

如何刷新此固件（我使用marthoc的deCONZ Docker映像）？
我只是将USB加密狗插入Windows笔记本电脑，然后从那里进行操作，完成后再回到Synology NAS中。

是否有Windows实用程序来刷新固件？如果是这样，您可以共享链接吗？

ReX1983 于 2020-09-19

如何刷新此固件（我使用marthoc的deCONZ Docker映像）？
我只是将USB加密狗插入Windows笔记本电脑，然后从那里进行操作，完成后再回到Synology NAS中。
是否有Windows实用程序来刷新固件？如果是这样，您可以共享链接吗？

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

salopette 于 2020-09-19

👍1

因此，我尝试了配置指向目标节点的固定源路由的想法。在许多情况下，只有一部分网络存在路由问题，在这里指定固定的源路由可能会有所帮助，其中：
可以根据每个节点选择指定源路由。
每个跃点都应始终通电。
路径中的跃点位置应该合理。在某些情况下，与自动算法可以算出的结果相比，用户可能有一个更好的计划，即数据包应该路由到何处。

这会解决所有问题吗？
不太可能，但是它应该改善到目的地的路由（无法在节点上配置路由）。请注意，固定的源路由仅适用于路由器，因为终端设备倾向于更改父路由，并且源路由不再起作用，在这种情况下，自动源路由可能会更好。

只是为了澄清...如果我不手动配置任何新的静态源路由，此新固件是否可以修复（或至少改善）宜家设备的随机断开连接？还是从此更新中受益的唯一方法是手动设置那些容易失去连接的设备的路由？

ReX1983 于 2020-09-19

如果没有手动设置路由，则如果设备对其进行升级（如IKEA设备），则会自动进行源路由。
因此，与以前的固件相比，如果已知此类路由，则将对这些设备使用路由。

如果它确实有助于保持开放状态，那么如果任何对旧固件经常有问题的人可以报告是否有任何更改，那将是很好的。

在我的测试网络中，固件运行良好，并且如嗅探器日志所示经常使用源路由。这并不意味着太多，因为即使没有源路由，我的网络也非常可靠。

manup 于 2020-09-20

我有21盏灯（4-980lu WS，17-1000lu WS），3个插头和3个（5个按钮）宜家圆形遥控器。所有这些都在最新的宜家FW上。在过去的大约1.5年中，我从未与他们发生过不稳定的情况。 Nighter与任何先前的deCONZ版本或FW发行版或当前版本无关。我正在使用最新的RaspBee FW 0x26370500运行稳定的.81，并且aslo在使用它们的最后一周没有遇到任何问题。

我猜....（也许我不太正确）宜家没有一般性问题，但特定于设置。有许多不同的因素会影响其在deCONZ中的行为和性能，以及总体而言。

morfei1 于 2020-09-21

👍1

我认为大多数问题都与宜家GU10灯有关。随着时间的流逝，稳定性已大大改善，但在2018年底我开始工作时一团糟。在过去的三个月中，我平均每两周需要重新启动30 GU10之一的电源。

peer69 于 2020-09-21

👍2

我认为大多数问题都与宜家GU10灯有关。随着时间的流逝，稳定性已大大改善，但在2018年底我开始工作时一团糟。在过去的三个月中，我平均每两周需要重新启动30 GU10之一的电源。

可能。据我所知，GU10还没有收到像宜家其他灯一样的固件更新。最近，我们在不和谐频道中进行了讨论。运行GU10宜家灯的用户会遇到这种行为。无论我们尝试了什么，似乎都无法解决他的问题。他甚至与我们分享了自己购买宜家Tradfri Hub的经历，即使使用Ikea Hub和GU10 light / s，他也有同样的糟糕经历。

所以，我想宜家要为这类灯发布新的固件来解决/解决这个问题只是时间问题。

morfei1 于 2020-09-21

我想知道@djwlindenaar是否已更新到最新的deCONZ和固件并能够分享他的经验？ :)

JBS5 于 2020-09-21

😄1

其实还没有...我还没来得及升级。另外，我也没有时间切换到z2mqtt，所以好消息是我将升级到新固件，并且如果有什么可报告的，我会报告。

djwlindenaar 于 2020-09-21

如果它确实有助于保持开放状态，那么如果任何对旧固件经常有问题的人可以报告是否有任何更改，那将是很好的。

我已于2天前更新到最新固件，此后，我的小米墙壁开关（ctrl_neutral2，11-25-2017）一次切换了3次。我以前从未遇到过这样的问题。

它通过1.3.009上的Tradfri灯泡E27 CWS连接到协调器。

此外，与这个问题并不严格相关，但是我从未设法通过Deconz（社区容器）获得OTA更新。

我有Tradfri灯泡：

E.27 CWS在1.3.009
1.2.214上的E14 W
1.2.248上的无线调光器
17 * GU10 WS on 1.2.221

我可以看到下载了Trafri OTA文件，但没有任何反应。我该怎么办？

供参考，这是容器的启动方式：

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这里与此问题无关。请另开一期。我认为您应该在Docker版本库中发布。 https://github.com/marthoc/docker-deconz

Mimiix 于 2020-09-21

审核说明：

在这里一切都弄不清之前，我想在这里设置一个范围。

与原始问题有关的任何事情：在此问题中，宜家灯偶尔会失去连接。

与固件有关的任何其他问题都可以在此处发布

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

@ ReX1983看看OTA插件如何工作https://github.com/dresden-elektronik/deconz-ota-plugin并更新您的设备。
抱歉，这是一个宜家设备通信问题。

MattWestb 于 2020-09-21

@ morfei1 @ peer69
我可以证实，这不仅是由GU10灯泡引起的。很长一段时间以来，我的系统中都没有GU10，因此一直存在路由和连接丢失的问题。

.82版本发布后，conbee 1上的新固件出现了一些初始问题。
但是现在，在网络网格稳定下来并重新通电几次之后，它在过去的几天里一直坚如磐石。

我很笨，我决定将所有灯泡上的固件都更新到最新版本（OTAU），以便在将来出现问题时可以有一个更好的基准。祝我好运。会让你们及时了解进展情况。

tubalainen 于 2020-09-21

👍2 🎉1

@tubalainen您是否在使用HA插件？

morfei1 于 2020-09-21

@tubalainen您是否在使用HA插件？

不会，我在Docker的Debian上使用HA Core-所以我也使用https://github.com/marthoc/docker-deconz stand-a-lone docker软件包。它们都使用dresten提供的.deb文件，因此它们应该工作相同。我不确定deconz HA附加组件中是否包含OTAU插件...。

tubalainen 于 2020-09-21

👍1

到目前为止，我只是对我的观察有所了解；

我的宜家GU-10（仅23个）只有问题，我使用的是Home assistant，它通过rest api连接到deconz（码头工人），我可以看到HA将事件成功触发deconz。

当我使用HA打开时，17个灯泡中的17个灯泡一个接一个地接在彼此之间（紧接在另一个之后），但HA认为它们是打开的。
但是，如果我在deconz中进行分组。将所有灯都放在该组中，并告诉HA打开该组，但尚未出现任何问题，所有灯都将打开。

使用固件：0x26650700我没有看到任何改善（除了出于某种原因我不得不重新配对那17个灯泡，甚至在重新配对之后我也遇到了同样的问题）

可能是对rest-api的限制吗？

MartinTerp 于 2020-09-21

😕1 👍1

@MartinTerp ，如果您一次对每个设备使用单个命令，而不是对一个组使用一个命令，它将失败，也许不是每次都会失败，但是在大多数情况下，应该执行某项操作的随机设备不会这样做。

我的解决方法是命令之间延迟5秒。例如
如果我想在23:00的bri：127和ct：454切换我的卧室灯，并且在我的走廊上，我给其中一个房间延迟5秒。如果我不延迟，它将随机地无法完成其中一个房间或两个房间的完整命令。我对此做了很多实验。它类似于宜家（Ikea）错误，无法同时处理开关的颜色和亮度。

我不知道这到底是什么，deconz错误，zigbee限制或宜家FW错误。也许是因为我不了解Zigbee的工作原理，但是5秒的延迟对我来说总是有效的。

通常，我总是使用：一次尽可能少地命令或延迟使用。这样就可以保持通道清洁。

如您所知，如果您需要一次切换多个组/灯光，总是最好创建一个新的phoscon组，在其中包括这些灯组，然后向它们发送单个组命令。您可以有许多不同的组，包括同一盏灯。我们不限于每个灯只使用一组。如果您不希望在phoscon中有很多群组，那么延迟是您最好的朋友。

morfei1 于 2020-09-21

👍1

@ morfei1我正在使用类似的解决方法，并且在大多数情况下，所有命令之间的延迟为5秒。
@MartinTerp除了IKEA-Tradfri灯以外，我在其他设备上也遇到了此问题，例如，欧司朗智能插头和灯条。我想这可能是由于问题的Tradfri-Lights没有转发命令引起的。

githtz 于 2020-09-21

👍1

但是它不应该是这样吗？
现在脚本以1秒的延迟将它们按1-by-1开启，应该能够处理吗？

MartinTerp 于 2020-09-21

😕1

@ morfei1 @MartinTerp

我还使用了延迟+，每次触发的自动化操作我都会两次从家庭助理发送和关闭命令。

现在，我删除了.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-其余插件/问题/ 1261＃issuecomment -696046160

请遵守这些规则。 如果需要，请公开其他问题。

Mimiix 于 2020-09-23

所以这是我的反馈，我已经升级到最新的固件和deconz api。我从HA运行网络。

我大约有72个节点，其中大多数是IKEA GU10灯。升级后，我注意到有两个不同的GU10在两个不同的日期“死亡”，唯一的恢复方法是重启电源。 GU10使用夹具1.2.217和1.2.221。我将尝试将它们全部升级到相同版本。

donnib 于 2020-09-23

我只有4个GU10，我想它们是从第一个发布的版本开始，在最新的ota版本上运行。就可访问性而言，这些从来没有问题，只是在固件更新较轻之后，我的场景就混乱了。

manup 于 2020-09-23

我刚刚有一个宜家TRADFRI灯泡E14 W op / ch 400lm版本1.2.214停止响应。该灯已经在不同的deconz固件上执行了很多次。现在，我正在使用deconz 26370500和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正在
宜家在不同的硬件（PSU / LED驱动器）上使用相同的固件映像，并且在“用户数据”中为不同的硬件设置了不同的设置（并且型号ID存储在其中）。因此，一个固件可以在一种硬件（E14）上正常运行，而在另一种硬件（GU10 / E27）上存在问题。
区别在于，宜家GW以ZLL模式运行（在Zigbee PRO上），而不是拉动设备状态，仅侦听设备在网络中发送的状态更改（ala Zigbee PRO / ZB3标准），并将它们与HUE和其他协调员正在从设备中获取状态的供应商（不是ZB3行为）会使网络一团糟。
我有最旧的IKEA RGBW和一个运行良好的旧更新（1.X）固件上的E27蛋白石WW，以及一堆运行良好的新ZB3 GU10 WS。我的骨干网大约有10个宜家的IKEA插头，它们保持了网络通信的稳定，而且我的Xioami传感器也可以正常工作。
我的感觉是，与网络布局相结合并避免出现一些有问题的设备（例如OSRAM Outdoor Plug一直在破坏包装并丢失孩子）的同时，硬件和固件也不再是一个普遍的问题。

MattWestb 于 2020-10-01

@manup我只能说对于我的系统来说，新固件比以前更糟了。无论是源路由还是现在的路由，我现在每天都要扎一两个灯泡，并需要重启。我什至看到我的飞利浦色相灯泡之一卡住了，但是不需要重启。我不知道这些问题是否是由我在其上运行的旧固件引起的，但是由于卡住了，我又无法升级。 :(

donnib 于 2020-10-06

我想知道是否有人知道较新的GU10还是有问题？我听说有更新的设备运行zigbee 3.0，我的妻子对这些问题不满意，因此如果有帮助，我可以更改所有设备？

donnib 于 2020-10-08

👀1

我今天早晨挂灯。我认为这是较新的之一。

指示灯未对任何命令作出反应，显示为脱机。重新启动并不能解决问题。我必须重置并将其重新添加到网络。

githtz 于 2020-10-08

@ JBS5 @djwlindenaar @lubbertkramer与该问题相比，对最新固件有任何反馈吗？

Mimiix 于 2020-10-12

我可以补充一点，在48个小时内，我对本主题所要解决的问题以及以前遇到的问题没有任何疑问。

但是，需要添加以下内容

每天晚上用deconz重新启动容器
将分组从家庭助理移至deconz / phoscon进行处理。

尽管有更好的体验，但在进行上述更改之前，我的灯泡反应迟钝，但到目前为止还不是。

PeterRemnemark 于 2020-10-12

@Mimiix ，这还

使我烦恼的是，网络感觉更加缓慢。从按下按钮到打开灯（通常）之间的时间比以前更长。现在也要打开灯并更改亮度，这是一个两步过程，介于两者之间。我仍然需要查看嗅探日志以检查是什么原因造成的。可能这与源路由的更改无关，但是您就可以了。

我确实有一盏灯没有反应，但是我也没有分析这种情况，所以很难告诉发生了什么。

djwlindenaar 于 2020-10-17

👍2

我的E27宜家灯泡已集体停止合作。
到目前为止，动力循环已经为其中一些工作了。 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插座，两个都使用最新的固件。

当时我唯一要做的就是将KADRILJ百叶窗运到远方，然后再运回，但这可能完全无关。

打开嗅探器会显示相同的问题：

设备仍会定期发送NWK链接状态命令。
但是总是带有一个空列表，似乎它们忽略了所有周围的路由器；
它们在MAC级别上对输入的命令进行ACK。
他们确实响应信标请求并发送信标，但这是他们给出的唯一“答复”。

不知何故，宜家设备上的Zigbee堆栈似乎部分由于NWK和APS层及以上崩溃而崩溃，或者传入的NWK缓冲区已满且从未释放。

我尝试通过发送以下命令使设备恢复活动：

ZDP退出并重新加入；
NWK退出并重新加入（较低级别）。

两者都在MAC级别被ACK，否则将被忽略。

然后，我尝试使用有效条目来伪造协调器NWK链接状态命令，该命令指示设备具有正常的入站和出站链接成本（3/3），希望该设备在其邻居表中接收到该协调器。 ...也不起作用。

不幸的是，似乎没有一种方法可以解决这种情况，而IKEA设备却进入了这种死机状态。通过一些论坛查看该行为可以在各种网关和底层Zigbee堆栈中看到。这很有趣，因为例如Hue桥不执行任何花哨的Zigbee内容，例如查询邻居表或绑定和报告，但仍然会发生错误。

宜家需要做的是至少实现一个看门狗，以检查NWK和APS组件是否仍在运行，并让设备触发看门狗重新启动。这不会修复该错误，但至少会在发生该问题时使设备保持功能。

manup 于 2020-10-24

👀1 👍1

@manup您是带有诊断群集的旧E27
也许在几个星期之间，那里的柜台是否正在发生变化，可能会很有趣。
它无法解决问题，但是提示固件不要拖延。
良好的观察和结论曼德！

我认为Silabs只能为那里最大的客户之一做更多的bug搜索；-)

MattWestb 于 2020-10-24

嗨，这让我感到困惑，因为自几个月前我使用ZZH迁移到Z2M以来，我还没有看到这个问题。方程中可能还有其他变量。如果其他已经做过相同举动的人可以确认，那将是很棒的。

mvjt 于 2020-10-24

👍1

@mvjt您是否将Rasp / CornBee与Z2M或其他协调器一起使用？
不同的Zigbee堆栈以不同的方式工作，并且可能会产生/产生不同的问题。

编辑：对不起，我看到ZZH =新的TI协调员。
deCONZ NCP =爱特梅尔/ Microchip
宜家设备/ NCP = Sirlabs EFR32 / EZSP

我可以确认HA / ZHA / Zigpy / Bellows与IKEA ICC-1-A模块作为IKEA路由器以及宜家和小米以及小米和NO OSRAM或小米路由器的终端设备的协调器，可以很好地工作。

MattWestb 于 2020-10-24

@MattWestb是的，E27具有诊断群集，但我尚未对其重新上电以使其保持在错误状态。通过从我的其他宜家灯中读取群集属性，属性报告全部不可用：/

至少在过去，我看到的问题也发生在TI CC253X上，在该问题的结尾提到了CC26X2R1，但这是一月份的情况，它可能同时有所改善。 https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

通常，它可能不是Silabs的错误，也可能是应用程序层中的一些自定义内容。我认为最近的Hue设备也使用Silabs。在Hue桥上至少有TI和Microchip版本。

这真是一件令人讨厌的事情，在许多情况下，该错误可能根本不会发生，或者仅在几个月后才发生，在其他网络中，它的发生间隔要小得多。我猜想网络的运行方式以及定期关闭的灯受到的影响也较小，这也很重要。

manup 于 2020-10-24

@manup我有一种情况可以很好地解决您的“宜家问题”。
如果已设置网络，则网络以一个网络密钥开头，并且安全框架计数器开始计时。如果您很长时间没有进行网络改革或滚动网络密钥，则计数器将停止运行，因为它已达到最大值0xFFFFFFFF（32位）并且无法增加。
然后，由于帧计数器错误，但网络下面的层仍在正常工作，因此设备将抛出进入zigbee层的所有数据。
我不知道一种方法可以使设备的安全框架计数器稳定下来。我认为这不可能在Wireshark中看到（思考=不知道）。

指向此问题的是未重置的早期配对设备的停顿速度更快。
在计数器停止运行之前，较新的配对/重置设备运行时间更长。
与一台不那么“交流”的设备相比，向一台设备发送指令也使它的停顿更快。

它建议定期在ZB3网络中滚动网络密钥以确保其安全，然后还重置安全帧计数器，以使其不会停止。
一些信息AN1233：Zigbee安全性2.1.6网络安全框架计数器。

这是一次疯狂的头脑风暴，但它可能是长期运行网络后问题来临的方式。

一种测试是尝试滚动网络密钥，“运行中”的设备必须在相当长的时间内正常运行，但是必须重置/重新启动停滞的设备才能从零启动安全帧计数器。

MattWestb 于 2020-10-25

嗯，非常确定，滚动网络密钥将删除所有小错误。

Adminiuga 于 2020-10-25

错误的200％确保他们没有更新并离开网络（以前没有ZB3的网络）！

@Adminiuga您是否尝试在EZSP上滚动网络密钥？
我发现结果很有趣！

MattWestb 于 2020-10-25

尚未尝试滚动网络密钥。实际上，知道有多少实施会定期滚动密钥会很有趣。
但我可以确认，pan-id更改有可能使小米掉线的几率很高，例如5分之4

Adminiuga 于 2020-10-25

我看到一些安全渗透测试，从街道上嗅探出Pan-ID，并在数月之间回溯数次，并且没有一家大型照明供应商（此处未命名）在一年后没有滚动网络密钥（维也纳的Mariahilferstraße）），因此您更有可能拥有权利（代理人）。

MattWestb 于 2020-10-25

如果且仅当安全框架计数器在解决问题，然后对所有实际的zigbee 3设备执行相同的操作，然后在“基本设备行为规范”中对其进行定义，并在旧版LL中进行推荐，但很可能不这样做zigbee PRO（旧的HA和LL）设备或未经认证的设备（未命名.... mi）。
然后最好是“手动”每年滚动一次或两次网络密钥，并且不需要拆除房屋来重置设备中的内置设备更多次，然后它们就会停滞并重新设置/重新加入通常不会被使用的旧小米传感器。集成在房屋结构中，易于重置（通常打开连接并按下按钮，它们就可以连接）。
Menny“中国Zigbee 3”在电源重置后抛出“旧的”安全框架计数器，并使用其邻居中第一个到达的软件包中的一个新的（已经看到，然后测试tasmotas zigbee 3问题，然后在重新启动时错误地重置了NCP计数器）因此，它们仅是重新供电，然后又恢复了。

MattWestb 于 2020-10-26

去年我们还进行了一些测试，没有网关可以旋转网络密钥。如规范中所述，这是在递增网络密钥号时重置NWK安全帧计数器的唯一方法。我也担心所有设备都支持此功能，通常几乎从未使用过的功能没有经过良好测试。我真的希望我错了，它适用于大多数设备。

在任何情况下，复位帧计数器对于网关来说都是最重要的，因为在接下来的几年中，帧计数器的传出命令，光和传感器数量最多。当前这不是问题，但是在大型网络中到达网关计数器后，将在2-3年内成为一个问题。为此，我们已经计划检查网络密钥的旋转以及密钥编号和帧计数器重置是否正常工作。

无论如何，这里的问题是不同的，网关的帧计数器和处于错误状态的指示灯仍然很好并且很低。

manup 于 2020-10-26

👀1 👍1

@djwlindenaar，我想知道您有任何新发现，因为您不仅可以像我一样报告灯已再次脱机，还可以从技术上分析发现。非常感谢您的发现和见解。 :)

JBS5 于 2020-11-08

好吧，感谢您的赞赏……老实说，我对当前的网络稳定性并不完全满意。自从更新到最新的deconz固件以来，它确实下降了。在过去的几周中，有些灯离线了，在升级之前很长一段时间都没有发生这种情况。我确实使用了可对IKEA灯具进行常规属性报告的补丁程序，但在当前情况下尚未应用

尽管对此进行分析很有趣，但这对我来说是一种业余爱好，现在对房子的一些改造已完全占用了我的时间。我看看是否可以花点时间...

djwlindenaar 于 2020-11-08

👍3 👀1

好吧，感谢您的赞赏……老实说，我对当前的网络稳定性并不完全满意。自从更新到最新的deconz固件以来，它确实下降了。

我也有同样的负面经历。现在，我的大多数小米设备（主要是Aqara墙壁开关）在一天中经常离线，并在几分钟后恢复工作（我想这是由于以下事实：如果小米设备未收到对设备请求的响应，则会重新启动。来自协调器的时间集群的属性）。

ReX1983 于 2020-11-11

新的v2.5.88版本可能会改善这种情况。在这里，宜家的报告配置得到了简化，因此状态转换不会用报告轰炸网络。在状态转换之前，每个属性的报告速度非常快。

manup 于 2020-11-13

👍4

新的v2.5.88版本可能会改善这种情况。在这里，宜家的报告配置得到了简化，因此状态转换不会用报告轰炸网络。在状态转换之前，每个属性的报告速度非常快。

听起来很有希望:)我猜想状态开关也是开/关吗？还是主要是亮度或色彩模式改变？
此更改需要/建议的最低固件版本吗？

JBS5 于 2020-11-13

仅亮度和所有颜色特定的属性，例如colorX，colorY和色温。
对于固件，我总是建议使用最新的0x26660700（对于ConBee II和RaspBee II）。

manup 于 2020-11-13

新的v2.5.88版本可能会改善这种情况。在这里，宜家的报告配置得到了简化，因此状态转换不会用报告轰炸网络。在状态转换之前，每个属性的报告速度非常快。

@manup ，我认为此更新还解决了Aqara设备的稳定性问题。谢谢

ReX1983 于 2020-11-14

🎉1 👍1

新的v2.5.88版本可能会改善这种情况。在这里，宜家的报告配置得到了简化，因此状态转换不会用报告轰炸网络。在状态转换之前，每个属性的报告速度非常快。
@manup ，我认为此更新还解决了Aqara设备的稳定性问题。谢谢

不幸的是问题（＃3605）仍然存在，我太早得出结论了

ReX1983 于 2020-11-15

Deconz-rest-plugin: 宜家灯偶尔会断开连接

最有用的评论

所有493条评论

似乎其他宜家灯泡也正在引起麻烦。

进度更新

创建固定的源路由

这会解决所有问题吗？

什么时候发布？

进度更新

创建固定的源路由

这会解决所有问题吗？

什么时候发布？

康比II

RaspBee II

RaspBee I和ConBee I

康比II

RaspBee II

RaspBee I和ConBee I

这会解决所有问题吗？

相关问题