Deconz-rest-plugin: As luzes IKEA ocasionalmente perdiam a conexão

O mesmo aqui com 2.05.58. Um Tradfri GU10 parece não ser responsável atm:

Aconteceu comigo com uma faixa de luz matiz alguns dias antes, então eu não suponho nenhum problema específico da IKEA. Os dispositivos precisam ser energizados e voltar ao normal depois disso. Ainda irritante em alguns casos, principalmente para meus painéis FLOALT que são alimentados diretamente e não têm um interruptor de parede para acioná-los.

1. Alguma pista do porquê?

O plugin REST API marca uma luz como inacessível, quando não recebe uma resposta por algumas vezes ao consultar a luz para seu estado. A causa de não receber uma resposta é, em ordem de probabilidade:
uma. A energia da luz foi cortada (por exemplo, por um interruptor de parede do século 20);
b. A rede Zigbee apresenta um soluço (por exemplo, devido a interferência de rádio ou problemas de roteamento na malha). Nesse caso, a luz ainda reage aos comandos do grupo;
c. O firmware da luz caiu.

1. É possível restaurar a conexão sem desconectar / conectar a energia?

Em a) ec): não. Em b): sim.

O plugin REST API marca a luz como alcançável, quando recebe uma mensagem dela. Ligar a luz faz com que ela envie uma mensagem de _Anúncio do dispositivo_. Em b), normalmente, a luz volta espontaneamente, quando a próxima votação for bem-sucedida. Você também pode selecionar o nó na GUI deCONZ e pressionar 0 .

O mesmo problema também na versão 2.05.59.

Eu também tenho esse problema, mesmo depois de atualizar para 2.05.59. Hoje foi uma das minhas três luzes externas "desaparecida".
Suas lâmpadas Tradfri são três.

@ebaauw Obrigado pela sua explicação.

uma. A energia da luz foi cortada (por exemplo, por um interruptor de parede do século 20);

Não há interruptores de parede disponíveis para essas luzes, então não consigo desconectar a energia acidentalmente.

b. A rede Zigbee apresenta um soluço (por exemplo, devido a interferência de rádio ou problemas de roteamento na malha). Nesse caso, a luz ainda reage aos comandos do grupo;

As luzes não reagem aos comandos de grupo quando a conexão é perdida (as luzes são atribuídas a um Hue Dimmer no aplicativo Phoscon e não respondem no Hue Dimmer quando a conexão é perdida).

c. O firmware da luz caiu.

O firmware 1.2.214 está instalado em todos os meus pontos IKEA GU10. Tenho mais de 20 deles e uma luz aleatória fica offline, digamos, uma em 2-3 semanas.

Você pode tentar a versão mais recente deCONZ com https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

Tive a mesma experiência duas vezes nos últimos meses com duas lâmpadas IKEA E14 diferentes (IKEA fw 1.2.214).
O ciclo de energia funcionou nas duas vezes para mim.

c. O firmware da luz caiu.

Quando as luzes não reagem nem mesmo aos comandos do grupo, parece que houve um travamento do firmware.

2.05.59 adaptou os parâmetros do gateway IKEA para configurar relatórios de estado de luz. Principalmente na esperança de não acionar nenhum bug usando uma configuração que a própria IKEA não testa. Nota lateral que a mudança fará com que não sejam mais usados ​​temporizadores para relatórios no dispositivo.

A nova configuração será aplicada assim que uma luz for desligada e ligada.

Ainda enviamos algumas solicitações de manutenção, como associação de grupo e consultas a tabelas vizinhas, e podemos restringi-las ainda mais se a estabilidade não melhorar com 2.05.59.

Lembre-se de que também pode haver a possibilidade de um bug no firmware leve, que não está relacionado a nenhuma solicitação enviada pelo gateway.

c. O firmware da luz caiu.

Quando as luzes não reagem nem mesmo aos comandos do grupo, parece que houve um travamento do firmware.

2.05.59 adaptou os parâmetros do gateway IKEA para configurar relatórios de estado de luz. Principalmente na esperança de não acionar nenhum bug usando uma configuração que a própria IKEA não testa. Nota lateral que a mudança fará com que não sejam mais usados ​​temporizadores para relatórios no dispositivo.

A nova configuração será aplicada assim que uma luz for desligada e ligada.

Ainda enviamos algumas solicitações de manutenção, como associação de grupo e consultas a tabelas vizinhas, e podemos restringi-las ainda mais se a estabilidade não melhorar com 2.05.59.

Lembre-se de que também pode haver a possibilidade de um bug no firmware leve, que não está relacionado a nenhuma solicitação enviada pelo gateway.

+1 em "não necessariamente relacionado ao deconz, mas sim à rede Zigbee ou fabricante FW" em correlação com a interpretação do padrão Zigbee nos fabricantes FW.

Acabei de atualizar para 2.05.59 e após reiniciar o deconz a mesma luz não pode ser alcançada novamente. Pressionar 0 no gui não o traz de volta. Qualquer outra luz funciona. No meu caso, isso também pode ser um problema com a própria luz.

@ peer69 @ thomas70 Você @manup em https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -463948127?

A nova configuração será aplicada assim que uma luz for desligada e ligada.

Boa dica, não fiz isso. Por enquanto, tive que voltar para .58 por outro motivo (alta carga de CPU tornando o gateway não-reativo), tentarei isso mais tarde hoje com .59 novamente e ligue todas as luzes ikea.

Eu também estou tendo esse problema, aconteceu duas vezes para a mesma luz GU 10. Atualmente executando 2.05.59, e desliguei as luzes após a atualização.

Esqueci de acrescentar que às vezes parece que é a mesma lâmpada que continua falhando. Há um tempo tive problemas com outra lâmpada, e seria sempre aquela para parar de reagir.

Depois de desligar e ligar minhas lâmpadas IKEA voltaram. Mas meu painel IKEA FLOALT WS ainda está offline

Estou enfrentando o mesmo problema e já faz um bom tempo, e diria que 0,59 realmente piorou as coisas para mim. Tenho 80 nós, dos quais 32 são luzes e interruptores Trådfri, 5 são luzes Hue e o resto são diferentes dispositivos Xiaomi alimentados por bateria, como temperatura, movimento, detector de fumaça, etc. Cada tipo de dispositivo deixou de responder pelo menos uma vez, no meu caso não são apenas as luzes Trådfri, mas no momento estou apenas tendo problemas com as luzes Trådfri e Hue.

A questão é que passei todas as luzes através de uma ponte Hue e os sensores Xiaomi através do gateway Xiaomi mais cedo e então eles estavam todos sólidos, então eu não acho que o firmware do dispositivo é o culpado no meu caso, a menos que seja causado por a mudança nas circunstâncias.

Eu tenho seis luzes Trådfri GU10 em um local que funcionavam perfeitamente antes, mas depois da atualização para .59 e vários ciclos de energia depois, elas agora estão quase completamente sem resposta e provavelmente terei que reiniciá-las. O que é estranho é que essa falta de resposta também parece estar "se movendo" de diferentes luzes, dependendo de quais luzes têm energia. Se eu cortar a energia de algumas das luzes que não respondem, pode demorar um pouco e, de repente, é alguma outra luz que não quer funcionar corretamente. Talvez haja alguma compensação em algum lugar que esteja quebrando as coisas?

A questão é que passei todas as luzes através de uma ponte Hue e os sensores Xiaomi através do gateway Xiaomi mais cedo e então eles estavam todos sólidos, então eu não acho que o firmware do dispositivo é o culpado no meu caso, a menos que seja causado por a mudança nas circunstâncias.

Interessante, você também tinha todas as 32 luzes Ikea na rede Hue? Estou perguntando porque a ponte Hue usa apenas pesquisa e não configura relatórios de atributos.

Você também tem dispositivos de roteador como as luzes Hue ou Ikea na rede Xiaomi?

Eu tenho seis luzes Trådfri GU10 em um local que funcionavam perfeitamente antes, mas depois da atualização para .59 e vários ciclos de energia depois, elas agora estão quase completamente sem resposta e provavelmente terei que reiniciá-las. O que é estranho é que essa falta de resposta também parece estar "se movendo" de diferentes luzes, dependendo de quais luzes têm energia. Se eu cortar a energia de algumas das luzes que não respondem, pode demorar um pouco e, de repente, é alguma outra luz que não quer funcionar corretamente. Talvez haja alguma compensação em algum lugar que esteja quebrando as coisas?

Hmm, isso é muito ruim, eu realmente me pergunto como isso acontece, 2.05.59 é muito mais "familiar" com as luzes Ikea do que nas versões anteriores. A configuração está acontecendo agora como o gateway Ikea faz.

Quando uma luz deixa de responder, você pode selecionar o nó em deCONZ e pressionar 0 se ficar responsivo / amarelo novamente, a luz não precisa ser desligada e ligada. Observe que a luz se tornando um zumbi neste caso será corrigida em breve, isso pode acontecer em uma determinada constelação de rede atualmente.

A propósito, as perguntas de sempre:

• Qual versão de firmware você está usando?
• RaspBee ou ConBee?
• Se ConBee você usa um cabo de extensão usb?

Demorou um pouco mais do que o esperado, mas agora tudo parece estar funcionando bem novamente. Pelo menos por agora, pelo que posso dizer.

Reinicializei o servidor e também desliguei todas as luzes da rede elétrica para ter certeza de que buscavam a configuração mais recente, mas, apesar disso, demorou algumas horas antes que o problema fosse embora, então fui um pouco prematuro em minha suposição de que o problema permaneceu, pois não funcionou imediatamente.

Interessante, você também tinha todas as 32 luzes Ikea na rede Hue? Estou perguntando porque a ponte Hue usa apenas pesquisa e não configura relatórios de atributos.

Sim, mais ou menos. Eu tinha 31 luzes Ikea na rede Hue, bem como as luzes Hue. O 32º dispositivo Ikea é a tomada que eu não tinha comprado na época.

Você também tem dispositivos de roteador como as luzes Hue ou Ikea na rede Xiaomi?

Não, apenas sensores alimentados por bateria

Quando uma luz deixa de responder, você pode selecionar o nó em deCONZ e pressionar 0 se ficar responsivo / amarelo novamente, a luz não precisa ser desligada e ligada. Observe que a luz se tornando um zumbi neste caso será corrigida em breve, isso pode acontecer em uma determinada constelação de rede atualmente.

Eu tentei várias vezes antes, sem nenhum efeito. E quanto ao hardware e configuração, estou usando um ConBee com cabo de extensão USB e 262F0500. Como tudo parece estar funcionando bem para mim agora, essas informações podem não ser úteis no momento, mas tentarei não tirar conclusões precipitadas e deixar a rede funcionar por alguns dias para ter certeza de que o problema não Retorna.

Tenho corrido 0,59 desde o fim de semana passado e ainda perco luzes Ikea aleatórias. (16 lâmpadas E27 na fachada da casa.)
A lâmpada FW é a mesma que as outras ainda no Ikea Gateway.
Usando ConBee com 262F0500 FW.
No final de semana passado, eu também comprei uma ponte HUE e estava prestes a começar a mover as luzes quando notei a nota de lançamento 'Sob o capô' para 0,59. Decidi adiar, mas vou reconsiderar este próximo fim de semana.
Deconz ainda será meu melhor controlador Xiaomi / mi Cube de escolha. Ainda não perdi um gesto.

Tenho corrido 0,59 desde o fim de semana passado e ainda perco luzes Ikea aleatórias. (16 lâmpadas E27 na fachada da casa.)
A lâmpada FW é a mesma que as outras ainda no Ikea Gateway.
Usando ConBee com 262F0500 FW.
No final de semana passado, eu também comprei uma ponte HUE e estava prestes a começar a mover as luzes quando notei a nota de lançamento 'Sob o capô' para 0,59. Decidi adiar, mas vou reconsiderar este próximo fim de semana.
Deconz ainda será meu melhor controlador Xiaomi / mi Cube de escolha. Ainda não perdi um gesto.

Eu tenho a mesma situação aqui, 16 luzes IKEA, 2 tomadas de controle IKEA, um plug Heiman e um plug innr e alguns sensores Xiaomi (sensores de cubo / porta / sensor de movimento). Nunca tive problemas com os dispositivos não IKEA. No entanto, atualmente, tenho problemas quase diários em que uma luz IKEA cai da rede

Eu uso um Conbee com um cabo de extensão USB no firmware 0x26300500 e deCONZ .59

Minhas luzes estão funcionando bem há algum tempo, mas alguns dias atrás minha lâmpada Trådfri E14 de repente parou de responder. Um ciclo de energia depois, ele voltou à vida.

Hoje foi a vez de um dos GU10 cair. É fisicamente muito próximo ao E14 mencionado anteriormente, então não tenho certeza se é uma coincidência ou não. O GU10 pode muito bem ter sido roteado através do E14, embora todas as minhas luzes estejam dentro do alcance da ConBee.

Selecionar os nós e pressionar 0 em deCONZ não faz nada. Eu também tentei reiniciar o contêiner deCONZ e enquanto redireciona a rede na inicialização, ele não conecta nenhuma rota para aquela lâmpada específica. Qual seria a melhor abordagem aqui para prosseguir com a solução de problemas?

12 dias depois, outro GU10 se torna inacessível e não se conectará novamente sem um ciclo de energia.

Fico feliz em compartilhar todas as informações necessárias para entrar neste problema.

O mesmo aqui, ontem após 6 dias de conexão impecável, perdi uma das minhas lâmpadas Tradfri .. ligar / desligar e resetar não ajudou. Ainda está amarelo em deConz, mas não é possível conectar ou controlar.

O mesmo aqui. Depois de alguns dias sem qualquer problema, duas das minhas lâmpadas GU10 Tradfri pararam de responder. Consegui trazer um deles de volta à vida pressionando 0 na GUI, mas tive que usar o PowerCycle para o outro.
Felizmente, isso só parece acontecer com dispositivos GU10 atm, meus painéis FLOALT ainda não tiveram problemas (na minha configuração, eles só podem ser circulados através do disjuntor).

O problema continuou para mim também. Já experimentei mais 3-4 lâmpadas GU10 perdendo a conexão, bem como uma das minhas Hue E27 e um sensor de porta Xiaomi (ímã). Algumas luzes começaram a funcionar novamente após um ciclo de energia, outras não. Pressionar 0 não faz nada.

Também é digno de nota que o sensor Xiaomi começou a funcionar novamente depois que desliguei e liguei um GU10 adjacente e sem resposta, então suponho que o sensor estava passando por aquela luz, mas não deveria redirecionar automaticamente se houver algum problema de conexão?

Mesmo problema aqui. Ontem eu atualizei para a versão mais recente .59 agora algumas luzes Ikea não respondem

Olá, você pode dar mais informações sobre a rede total, como tamanho da rede e outros dispositivos alimentados por rede?

Reorganizei minha rede doméstica há alguns dias, agora incluindo:

• 5x IKEA WS GU10 (firmware 1.2.221, código do produto LED1537R6GU10EU)
  Com endereço mac 0x000b57ff ..... (lote mais antigo)
• 2x IKEA regulável E27 (firmware 1.2.214)
• 1 luz IKEA E14 WS (firmware 1.2.221)
• 1 repetidor IKEA (firmware 2.0.019)
• 1x tomada IKEA (firmware 2.0.019)
• 1x OSRAM GU 10
• 1 lâmpada de cor OSRAM E27
• 1 ficha OSRAM
• 1 lâmpada colorida Hue E27
• 1 lâmpada lux regulável Hue E27

deCONZ 2.05.59; Firmware ConBee 0x26300500 (mas 0x262f0500 também serve).

Tenho 4 lp FLS-PP, mas agora estão desligados para teste, pois atuam como repetidores de sinal muito fortes.

Com sensores e switches, o tamanho total da rede é 55.
Todas as luzes estão sempre ligadas e até agora mostram zero interrupções.

Aqui estão algumas especificações mais detalhadas da minha rede, se puderem ser de alguma ajuda. Ainda estou executando 2.05.59 com 262F0500 e um cabo de extensão para o ConBee. Como mencionado acima, após a primeira atualização para 2.05.59 e desligando e ligando todos os dispositivos alimentados pela rede elétrica e aguardando algumas horas, a rede ficou perfeita por quase uma semana, então parece que vai demorar um pouco até que os problemas comecem a aparecer. Infelizmente, o problema reapareceu e um ciclo completo de energia de todos os dispositivos alimentados pela rede elétrica, bem como uma reinicialização deCONZ, não resolve mais o problema. Também parece que o problema está vagando de um dispositivo para outro, porque às vezes uma luz pode não responder por um tempo e depois se conserta.

Hoje cedo eu tive um problema em que o Trådfri E14 não respondia, assim como um Hue E27. Depois de desligar e ligar o E27, o E14 também voltou à vida sem que eu sequer tocasse nele. O mesmo vale para os GU10s que não respondem que parecem estar trocando de lugar de vez em quando, então há pelo menos dois GU10s que não respondem todos os dias, mas nem sempre são as mesmas luzes, então alguns começam a trabalhar enquanto outros quebram e vice-versa.

Minha rede atualmente consiste nos seguintes 80 dispositivos, incluindo ConBee e os dispositivos alimentados pela rede elétrica são alimentados 24 horas por dia, 7 dias por semana.

Alimentado pela rede

| Quantidade | Tipo | Firmware |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 regulável | 1.2.214 |
| 4 Espectro branco Trådfri GU10 | 1.2.217 |
| 1 | Trådfri E14 opal regulável | 1.2.217 |
| 1 | Tomada de controle Trådfri | 1.4.020 |
| 3 | Matiz E27 Branco e Cor A19 | 1.29.0_r21169 |
| 2 | Hue E14 White ambiance LTW012 | 1.29.0_r21169 |

Alimentado por bateria

Quantidade | Tipo | Firmware
--------- | ------ | -----------
1 | Interruptor liga / desliga Trådfri | 1.4.018
10 Multisensor Xiaomi Aqara (temp / hum / pres) | 20161129
3 | Sensor de movimento Xiaomi Aqara (movimento / lux) | 20170627
4 Sensor de água Xiaomi Aqara | 20170721
1 | Sensor de movimento Hue | 6.1.0.18912
11 | Sensor de contato Xiaomi Aqara | 20161128
8 Xiaomi / Honeywell sensor de fumaça | N / D

Na semana passada, o deconz parecia funcionar bem, mas ontem tive outra lâmpada IKEA (espectro branco) perdendo a conexão com o deconz. Mesmo desligando e ligando novamente não ajudou. Tive que reiniciar o deconz para que funcionasse novamente de alguma forma.

Eu tenho uma rede com lâmpadas IKEA, uma tomada Heiman e alguns sensores Xiaomi.

Algumas especificações da minha rede zigbee:

Firmware Conbee 262F0500 com cabo de extensão em um NUC.
deCONZ 2.05.55 no Docker, então a primeira coisa que tenho que fazer é atualizar para 2.05.59, eu acho.

Powered (24/7)

| Quantidade | Tipo | Firmware |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 white | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 white | 1.2.214 |
| 21x | Tradfri GU10 regulável | 1.2.214 |
| 3x | Osram Smart + socket | 1.04.12 |

Alimentado por bateria

| Quantidade | Tipo | Firmware |
| ------------- | ------------- | ------------- |
| 3x | Hue Dimmer Switch | 5.45.1.17846 |
| 1x | Switch inteligente Aqara | 20180525 |
| 1x | Switch inteligente Aqara | 20161128 |
| 1x | Interruptor sem fio duplo Aqara | 20170411 |
| 1x | TRADFRI remoto | 1.2.214 |
| 6x | Multisensor Aqara | 20161129 |
| 10x | Aqara contactensor | 20161128 |
| 5x | Sensor de movimento Aqara | 20170627 |
| 1x | Sensor de vazamento Aqara | 20170721 |
| 1x | Sensor de vibração Aqara | 20180130 |

Alguma atualização para a versão atual? Estou executando 0,60 há 3 dias e nenhuma luz perdeu a conexão ainda.

Infelizmente eu já perdi a conexão com uma lâmpada branca Tradfri E27 normal em .60 e o firmware mais recente.

Isso é uma má notícia ... se bem entendi, os intervalos de votação foram alterados para 0,60 para serem menos agressivos. Uma pesquisa agressiva que fez com que a luz desligasse fez todo o sentido para mim, uma pena que não parece ser a solução para o nosso problema.

Ontem desliguei todos os dispositivos com energia elétrica e atualizei para 2.05.60 e 26320500 antes de ligá-los novamente, apenas para jogar pelo seguro. As luzes então funcionaram bem por cerca de 24 horas, mas apenas alguns minutos atrás, percebi que um dos meus GU10 havia parado de responder. Felizmente, ele voltou à vida alguns minutos depois, sem nenhuma interação manual da minha parte, então talvez a rede estivesse apenas obstruída.

@ JBS5 Eu recomendaria atualizar o 4x Tradfri E27 white em 1.1.1.0-5.7.2.0 para uma versão de firmware recente. Se bem me lembro, esta ainda é a primeira versão.

@jurriaan qual versão tem sua lâmpada branca Tradfri E27?

Isso é uma má notícia ... se bem entendi, os intervalos de votação foram alterados para 0,60 para serem menos agressivos.

Sim, basicamente muito semelhante ao gateway IKEA. Agora, a única diferença restante é a consulta periódica das tabelas vizinhas (que é usada para exibir as linhas da rede em malha).

Isso pode ser desativado clicando no ícone CRE no deCONZ e desmarque "Roteadores e Coordenador".
Pode valer a pena um teste.

No Reddit havia um post mencionando que o gateway IKEA deveria em teoria suportar até 100 dispositivos, mas que não é testado muito bem. Seria interessante saber qual é o tamanho normal da rede que a equipe IKEA testa.

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

Você provavelmente pode ter 100 dispositivos conectados ao seu Gateway. Isso não foi testado adequadamente por nós, por isso não garantimos isso. Mas o limite técnico é 100, e tenho visto pessoas que têm 100 dispositivos com nenhum ou apenas pequenos problemas.

As novas versões do Gateway suportarão a mesma quantidade de dispositivos (oficialmente 50). Você pode adicionar outro Gateway ao seu sistema se quiser dobrar isso.

@ JBS5 Eu recomendaria atualizar o 4x Tradfri E27 white em 1.1.1.0-5.7.2.0 para uma versão de firmware recente. Se bem me lembro, esta ainda é a primeira versão.

Essas lâmpadas E27 com o firmware antigo não falharam durante os últimos 6 meses, enquanto outras ...

Muito interessante, que tal o E27 na versão 1.2.214?

Muito interessante, que tal o E27 na versão 1.2.214?

Eles perderam a conexão apenas uma vez nos últimos meses.

Já se passaram algumas semanas desde que o último GU10 perdeu a conexão, enquanto ainda estou usando o deCONZ 2.05.55 e o firmware 262F0500 no Conbee.

Eu também tenho esse problema. Apenas nós Ikea, (43, principalmente luzes). Não tenho nenhum conhecimento sobre o zigbee, mas como não vi mencionado: minha rede parece mais estável com OTAU desabilitado. Outro dia, também mudei as preferências de rede para menos segura. Não me lembro qual, mas depois disso não perdi nenhuma luz.

Depois de alguns dias sem qualquer problema, vários GU10 pararam de responder.
Outro problema pode não estar relacionado, mas uma luz Osram também perdeu a conexão. Mesmo que ainda fosse mostrado na GUI e parecesse engrenar, eu não conseguia mais controlar. Tive que deletar a luz e relê-la, foi atribuído outro Light No, mas recuperou o nome anterior logo após adicioná-lo. Não tenho ideia do que está acontecendo aqui, mas é um pouco mais de manutenção do que eu gostaria de ver na minha configuração.

@ peer69 você também tentou
Você está em 2.05.60? Você também pode fornecer mais alguns detalhes sobre sua rede, quantas luzes e dispositivos alimentados pela rede elétrica?

@manup eu
Nesse ínterim, esse problema voltou, mesmo após a redefinição de fábrica e também afetou outra luz OSRAM. Por enquanto, estou me livrando das duas únicas luzes da OSRAM em minha rede e as substituindo por lâmpadas coloridas. Posso oferecer alguns testes com as luzes ORSAM, mas precisaria de algum tempo para isso.

Estou executando 2.05.60. Atualmente, existem 57 nós conectados à rede, dos quais 27 dispositivos são alimentados por rede. Eu uso 13 IKEA GU10, 1 IKEA FLOALT Panel, 2 IKEA E14, 3 OSRAM Smart + Plugs, 3 lâmpadas E14 matiz, 5 lâmpadas E27 matiz, 1 matiz lightstrip.

Eu também tive que fazer um ciclo de alimentação de alguns IKEA GU10 nos últimos dias, que se tornaram insensíveis. Depois do ciclo de alimentação, tudo voltou ao normal e não vejo um padrão. Tenho lâmpadas com vários GU10 e não mais do que um GU10 que deixou de responder ao mesmo tempo, apesar de serem sempre controlados como um grupo.

No momento, estou de volta à estaca zero. Agora eu regularmente tenho 2 ou 3 luzes que não respondem, mas alternam entre luzes diferentes, então às vezes elas funcionam e às vezes não, dependendo de quais outras luzes estão online. O problema parece estar em cascata porque quando eu desligo fisicamente algumas luzes cortando a energia para elas, isso muda o problema para outras luzes.

Também perdi alguns sensores de temperatura Xiaomi, bem como sensores de porta e um botão liga / desliga IKEA, mas eles não voltam, então provavelmente precisam ser emparelhados para começar a trabalhar novamente.

As coisas funcionaram bem imediatamente após um ciclo de energia total, como observei antes, mas alguns dias depois as luzes começaram a ficar sem resposta novamente e tem sido assim por algumas semanas. Na época em que aconteceu pela primeira vez, um convidado acidentalmente desconectou o E14 por várias horas, então não tenho certeza se ele é completamente não relacionado ou se distúrbios inesperados na malha zigbee fizeram o roteamento enlouquecer. Visto que, aparentemente, não sou o único com esses problemas, acho que pode ter sido apenas uma coincidência.

Eu realmente gosto do conceito de ter todos os meus dispositivos zigbee em uma única malha, mas estou quase no ponto em que inicializo os antigos gateways Hue e Xiaomi e coloco o ConBee em uma gaveta, o que realmente não quero fazer por vários outros motivos. Alguém tem dicas para solucionar problemas adicionais que possam me ajudar a identificar exatamente o que está acontecendo e como resolver?

Um dos meus pontos IKEA GU10 agora também não responde.

No sniffer, vejo que ainda está um pouco "ativo" e envia mensagens NWK Link Status, mas obviamente pensa que está sozinho na rede (Link Status Count: 0).

Ele não responde a comandos unicast, mas envia o relatório de atributo ZCL periodicamente do modelid.

Farejando há cerca de 2 horas, não tenho certeza de quando parou de responder e se está relacionado, mas o número de sequência ZCL do relatório é baixo:

Vou fazer mais alguns testes e não vou fazer o ciclo de alimentação por um tempo.

Minha tomada Tradri agiu muito estranho hoje também e funcionou em círculos de reinicialização, nunca tinha tido antes.

Acabei de notar que um segundo IKEA GU10 também é um led ambulante, com os mesmos sintomas do outro.

Ambos os dispositivos não respondem à solicitação de endereço unicast, groupcast ou ZCP nwk (pressionando 0).
Eles enviam comandos de status de link NWK vazios.

O segundo GU10 também enviou solicitações ZCL OTA Query Next Image.

Parece que a resposta não vem.

Apenas um palpite, mas eu acho que as luzes nos buffers estão bloqueadas e é por isso que nada é recebido e processado. Os out-buffers ainda estão funcionando, portanto, o firmware é capaz de enviar relatórios e consultas ota.

Seria bom se eles implementassem algo como uma verificação de saúde simples para que o firmware possa reiniciar depois de um tempo, se a camada mac estiver funcionando (comandos são recebidos), mas as camadas nwk e aps permanecerem silenciosas.

Eu também tenho esse problema, mesmo depois de atualizar para 2.05.59. Hoje foi uma das minhas três luzes externas "desaparecida".
Suas lâmpadas Tradfri são três.

fora do assunto. Como você encontra sua luz em tudo isso? Lol. Eu tenho uma configuração semelhante e estava tipo ... nããão hora para isso

por semelhante, quero dizer + - 50 dispositivos

+ - 50 está bem. Uma de nossas redes de teste tem +180 dispositivos com deCONZ em um Raspberry Pi 1, isso é divertido :)

Temos alguns planos para adicionar melhor filtro / classificação ao deCONZ para simplificar a localização de dispositivos, atualmente é muito complicado em uma determinada contagem de dispositivos.

As luzes ainda estão presas.

Uma observação interessante: desliguei o pai de um sensor de movimento Philips Hue (um Hue Lux) para que ele precise procurar um novo pai. O sensor agora tenta se reunir por meio de uma das luzes IKEA GU10 presas.

A luz responde com um comando Sair (com Reingressar). Portanto, ele processou o pedido de reingresso!

Infelizmente, o sensor de movimento Hue é teimoso e tenta voltar para a luz GU10 presa para sempre, em vez de procurar um pai melhor.

No entanto, a parte interessante aqui é que a luz IKEA travada responde à solicitação de reingresso, talvez ela também processe solicitações de Saída NWK, que podem ser uma base de uma solução alternativa para colocar a luz em um estado de funcionamento novamente.

Correção, o sensor de movimento Hue não é muito teimoso; após alguns minutos, o sensor selecionou outro pai ativo (bom).

No entanto, a parte interessante aqui é que a luz IKEA travada responde à solicitação de reingresso, talvez ela também processe solicitações de Saída NWK, que podem ser uma base de uma solução alternativa para colocar a luz em um estado de funcionamento novamente.

Eu testei isso, mas infelizmente não funcionou. Enquanto as luzes estiverem paradas, elas não processarão a Saída NWK com solicitação de reingresso.

Atualmente, só posso concluir que a IKEA precisa consertar o problema raiz da luz presa ou implementar algum tipo de watchdog + verificação de integridade para camadas NWK / APS do firmware.

Ainda não se sabe o que exatamente faz com que a luz vá para este estado - tempestade de transmissão, certos comandos, problemas de roteamento ...?

Vou encaminhar minhas descobertas e os logs do farejador para a IKEA, espero que eles possam usá-los para rastrear o problema.

Então, @manup , qual é a prática recomendada para reingressar em uma luz IKEA presa?

Para mim, um ciclo de energia da luz funciona claramente melhor

@manup Eu acho que se você não sabe como fazer o paciente melhorar, você deveria tentar piorar. Portanto, bombardeie uma luz com causas potenciais para travamentos e veja o que acontece.
Além disso, essas luzes não são baseadas na pilha Ember? Talvez haja equipes de suporte ou fóruns que possam lançar uma luz (trocadilho intencional).

Escrito para a IKEA, eles respondem a solicitações de suporte como essas? Ou devemos nos unir para ganhar alguma atenção?

Para mim, um ciclo de energia da luz funciona claramente melhor

Nem tanto para mim ...
O reinício do Conbee é a única coisa que o corrige temporariamente.
E então o mesmo, ou mais frequentemente, outra luz IKEA fica presa depois de um tempo ...
Sempre apenas uma luz! É tão estranho ... E irritante ...: /

@manup Awesome! Obrigado por investigar isso!

Também encaminhei este tópico para a equipe IKEA Tradfri via Reddit. Acabei de receber uma resposta deles dizendo que eles encaminharam as informações. Esperamos que eles possam usar isso para melhorar seu firmware ou encontrar uma solução para esse problema :)

Parece que há um novo firmware para o gateway tradfri chegando nos próximos dias, que visa especialmente o suporte para HomeKit. Pode haver um novo firmware para as lâmpadas também.

@ peer69 Esta é a versão de firmware mais recente:

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

Apenas as atualizações são:

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

Portanto, focado principalmente nas tomadas / gateway.

Hoje, uma das minhas lâmpadas coloridas apresentou exatamente o mesmo problema. Tive que fazer um ciclo de alimentação para que ele respondesse novamente.

Alguma novidade para quem atualiza o deCONZ e o firmware da Conbee?

Até agora, 1 ou 2 GU10s ficarão offline em 2 a 4 semanas. Mais ou menos esporadicamente, mas a bicicleta motorizada é irritante porque não tenho um interruptor de força em alguns lugares.

Acabei de atualizar o firmware para 0x26330500, então vamos ver.

Infelizmente, hoje um dos meus GU10 está indisponível.
Usando deCONZ 2.05.64 com firmware 26330500 no Conbee.

Acho que foi concluído que este é um problema de lâmpada FW, como vemos exatamente o mesmo problema em um Philips HUE Bridge. Notei no aplicativo Trådfri, seção de notas de lançamento, uma menção a uma lâmpada CT v2. Talvez seja mesmo relacionado a HW de lâmpada?

Não tive problemas com 2.05.65 até agora.

Mesmo, não enfrento esse problema há semanas

Eu tive a mesma coisa com a última versão do deconz até agora .. troquei algumas lâmpadas alguns dias atrás. Eu só tive que desligá-lo manualmente e ligar novamente uma dessas lâmpadas para que ele voltasse a responder.

Alguns GU10 e uma lâmpada E27 ficaram fora do ar há alguns dias. Somente o ciclo de energia os traz de volta online

Talvez relevante: isso aconteceu durante minhas férias, quando nenhuma luz mudou por um ou dez dias.

Firmware 26330500 com deCONZ 2.05.64

Que tal esse problema para aqueles que disseram que não tiveram nenhum problema por algumas semanas atrás?

Eu ainda tenho esse problema. Às vezes, nenhum deles fica off-line e, do nada, um GU10 fica off-line e, alguns dias depois, outro ..

Pelo que posso ver, ainda não há um novo firmware disponível para o Tradfri GU10.

Eu ainda tenho esse problema também. Como, para mim, os comandos de grupo ainda funcionam na maior parte do tempo, mesmo que eu não consiga controlar a luz como um único dispositivo, eu os uso em meus scripts de interruptores de parede como uma solução alternativa.

Os comandos de grupo também funcionam para mim, mas apenas algumas vezes. Depois disso, a luz fica acesa ou apagada e não responde mais. Nem mesmo ao usar um Dimmer Hue vinculado.

O mesmo para mim. Tenho a impressão de que o problema está atrasado, mais do que resolvido.
Também resolvi o problema com o uso de comandos de grupo.

Percebo pela maneira como algumas luzes parecem muito mais suscetíveis a esse problema. Você reconhece isso?

@djwlindenaar É difícil dizer, mas acho que metade dos 25+ GU10 nunca teve esse problema e tenho certeza de que alguns tiveram o problema várias vezes.

@ peer69 @djwlindenaar O comando group continua funcionando? Hoje, um GU10 ficou offline e nem mesmo respondeu a um comando de grupo da primeira vez (comando de grupo de deCONZ e um Hue Dimmer vinculado).

O comando de grupo geralmente continua funcionando, mas me lembro de uma ocasião em que tive que desligar e ligar uma luz. Também me lembro de uma vez em que ele não respondeu por um tempo e, sem qualquer ação, voltou a responder mais tarde.

Todas as vezes, mais cedo ou mais tarde, também um comando de grupo falhou e teve que girar a luz.

O que você quer dizer com um tempo? Algumas horas ou alguns dias?

Não tenho certeza, provavelmente horas, talvez um dia. Eu simplesmente esqueci disso por um tempo, mas percebi que estaria de volta na próxima vez que eu usasse a luz.
Estava relacionado a uma regra acionada por movimento, então ...

Esperei cerca de 2 dias quando um GU10 ficou offline no início desta semana, mas não voltou. Foi necessário um ciclo de alimentação, o GU10 não era nem um pouco quente.

Agora, eu tenho uma luz GU10 que ficou offline, mas não volta a ficar online após um ciclo de energia. Também pressionar 0 no VNC não resolve este problema.

Além disso, um comando de grupo ou interruptor Hue DImmer vinculado não é mais capaz de ligar / desligar a luz.

Começando na noite passada, eu tenho no corredor 4 luzes ikea que se apagam após x tempo por um temporizador (Assistente doméstico) agora 1 das 4 luzes continua acesa e não pode ser desligada pelo Assistente doméstico / Deconz. Está offline de acordo com Deconz e não voltou em 7 horas. Vou tentar fazer um ciclo de força e ver se isso resolve.

A luz não funciona: lâmpada TRÅDFRI E27 opala 1000lm com versão 1.2.214
Luzes de trabalho: lâmpada TRÅDFRI E27 opala 1000lm com versão 1.2.214
Firmware: 26330500
Deconz: V2_05_69

Acredito que haja um problema de hardware com as lâmpadas de espectro branco Ikea Trafri GU10. Também na minha configuração (gateway Ikea conectado via API local ao Home Assistant), pelo menos metade das minhas 17 lâmpadas fica offline a cada dois dias. A única solução é desligar e ligar as lâmpadas.

Este pode ser o motivo pelo qual a Ikea lançou uma nova versão de hardware que executa uma versão diferente do firmware (2. * em vez de 1. *).

Pelo que eu sei, não há nenhuma nova atualização de firmware para a versão antiga, isso pode ser um sinal de algo relacionado ao hardware.

Não tenho certeza de qual é a garantia, mas estou planejando pedir a substituição pela nova versão.

Acredito que haja um problema de hardware com as lâmpadas de espectro branco Ikea Trafri GU10. Também na minha configuração (gateway Ikea conectado via API local ao Home Assistant), pelo menos metade das minhas 17 lâmpadas fica offline a cada dois dias. A única solução é desligar e ligar as lâmpadas.

Este pode ser o motivo pelo qual a Ikea lançou uma nova versão de hardware que executa uma versão diferente do firmware (2. * em vez de 1. *).

Pelo que eu sei, não há nenhuma nova atualização de firmware para a versão antiga, isso pode ser um sinal de algo relacionado ao hardware.

Não tenho certeza de qual é a garantia, mas estou planejando pedir a substituição pela nova versão.

Não tenho certeza se está relacionado a apenas um tipo, porque estou usando o branco quente GU10, não o espectro branco.

Tive o mesmo problema com dois IKEA GU 10 WW hoje. A ciclagem de energia não ajudou. Ajudou a dar força e reiniciar o deconz. Talvez algum problema na mesa do vizinho? Ambas as luzes estão em um grupo de dois e sempre controladas como um grupo.

Que coincidência isso estar acontecendo em várias instalações hoje em dia ... Ou algo mais está acontecendo?

@ peer69

Qual versão do firmware deCONZ e conbee você está usando?

Estou usando:
deCONZ V2_05_66
Firmware 26330500

Mesmo firmware aqui. deCONZ Versão 2.05.69.

E outro branco quente Tradfri GU10 perde a conexão.

Existem arquivos de firmware mais novos no branch de teste, mas não sei se eles corrigem os problemas ou causam novos problemas, talvez até danos.

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 Estas são para luzes GU10 de espectro branco e, eu acho, para a nova versão? https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Talvez 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed possa ser usado para eles. Vou testá-lo em uma das minhas luzes reguláveis ​​IKEA E27, espero que o pior caso seja travar, mas não queimar :)

Tentei atribuir o arquivo manualmente, mas a lâmpada não detectou a atualização (não inicia).

Apenas um 'eu também' sobre isso. Minha casa inteira é Tradfri e depois de reiniciar meu servidor hoje perdi toda a rede pela 3ª vez em poucos dias. A ciclagem de energia não fez diferença. Eu só tenho Tradfri em minha casa, então não tenho mais nada para comparar. Tenho uma mistura de branco e27, cor e27 e GU10. A única resolução que encontrei foi reinicializar as lâmpadas e começar tudo do zero - infelizmente, isso não é sustentável.

Firmware da Conbee: 264A0700
Firmware leve: 1.2.214

Fico feliz em ajudar com qualquer diagnóstico, mas preciso devolver a maior parte da minha casa ao portal da Tradfri para que minha família possa acender e apagar as luzes. Vou deixar algumas lâmpadas disponíveis.

Acabei de perceber uma, talvez, adição interessante a este problema.

Várias salas estão equipadas com vários pontos Tradfri GU10 e a maioria das salas com um Hue Dimmer Switch, com uma ligação direta aos GU10s na sala criada ao adicioná-los ao grupo Hue Dimmer Switch no aplicativo Phoscon.

• Apenas o GU10 com ligação direta com um switch Hue Dimmer fica offline de vez em quando e precisa de um ciclo de energia para voltar a ficar online.
• GU10s sem ligação direta com um switch Hue Dimmer não ficam offline.

Não parece ser o caso para mim. Até agora, apenas as lâmpadas Hue parecem ser bastante resistentes. Todos os tipos de dispositivos IKEA (GU10, E14, painel FLOALT) e dispositivos Osram (lâmpadas, lighstrips e postes de jardim) que eu possuo falharam. Especialmente os dispositivos Osram falham completamente, o ciclo de energia não faz nada. Eles devem ser removidos e reparados, o que é uma dor para esses dispositivos.

Passei alguns dias pensando em substituir todos os meus dispositivos zigbee por dispositivos para a minha instalação KNX muito cara depois que vários dispositivos falharam e a migração para um stick Conbee II também falhou, provavelmente por causa de um zll-db um tanto corrompido. Em seguida, optei por uma abordagem radical para configurar tudo do zero. Reinicializei o gateway e reparei todos os dispositivos. Quanto aos dispositivos IKEA, isso era muito mais fácil do que costumava ser. No passado, eu tinha que movê-los para perto do gateway, reiniciá-los várias vezes, usar o touchlink para fazê-los responder - nada disso desta vez. Acabei de reiniciar as lâmpadas e eles emparelharam sem problemas. Ainda assim, fazer isso para 70 dispositivos era uma dor e alguns sensores xiaomi tornavam isso um pouco mais difícil do que as coisas do ikea. Mas já me faz pensar que posso ter uma rede mais estável agora. No entanto, nada falhou, mas direi se isso acontecer.

Já faz um tempo desde que atualizei meu raspbee, minha versão antiga tinha problemas com a leitura da temperatura das luzes, então decidi atualizar para o firmware mais recente e o deCONZ mais recente. Tem apenas 2 luzes (OSRAM 73674). 1 luz (provavelmente aleatória) perde a conexão após alguns minutos com o último deCONZ e tenho que desligar manualmente e ligar novamente. A única versão que consegui encontrar capaz de ler as temperaturas e não perder as luzes foi deconz-2.04.40-qt5.deb, que é muito antiga, mas funciona para o meu uso básico.

Ultimamente também acontece muito mais comigo com a cor única IKEA GU10. Meio que um pé no saco. No entanto, os nós não ficam vermelhos para mim, apenas acinzentados. Eles reagirão ao pressionamento de botões remotos, mas não por meio de Phoscon ou HA.

O deCONZ ainda atualiza o estado da luz quando você os controla pelo controle remoto?

Isso normalmente acontece quando deCONZ perdeu o caminho para a lâmpada. A lâmpada ainda está na rede, pode alcançar o gateway e receber transmissões. No entanto, o gateway não pode alcançar a luz por meio do unicast. Como solução alternativa, você pode usar comandos /groups vez de /lights , então deCONZ enviará transmissões.

Ainda estou tendo o mesmo problema ocasionalmente (~ uma vez por semana) com meu controlador de cortina Xiaomi (que é um roteador ZigBee). O _Anúncio do dispositivo_ após desligar e ligar o dispositivo faz com que deCONZ reaprenda a rota.

Esses problemas de roteamento foram introduzidos com o suporte para a descoberta de roteamento usada pelas luzes Trådfri, então 2.04.40 parece certo.

@ebaauw Quando uma luz fica indisponível, os comandos de grupo funcionam para mim, mas apenas por um tempo limitado. Depois disso, a luz fica acesa ou apagada e não responde mais a um comando de grupo. Usando um Hue Dimmer Switch vinculado (vinculação criada adicionando as luzes ao grupo criado por padrão quando um Hue Dimmer Switch é emparelhado no aplicativo Phoscon).

O deCONZ ainda atualiza o estado da luz quando você os controla pelo controle remoto?

Isso normalmente acontece quando deCONZ perdeu o caminho para a lâmpada. A lâmpada ainda está na rede, pode alcançar o gateway e receber transmissões. No entanto, o gateway não pode alcançar a luz por meio do unicast. Como solução alternativa, você pode usar comandos /groups vez de /lights , então deCONZ enviará transmissões.

Vou verificar essas sugestões na próxima vez. Mas sim, eles geralmente voltam quando eu cortei a energia por alguns minutos. Btw eu uso o controle remoto "disco de hóquei" IKEA.

Ainda estou tendo o mesmo problema ocasionalmente (~ uma vez por semana) com meu controlador de cortina Xiaomi (que é um roteador ZigBee). O _Anúncio do dispositivo_ após desligar e ligar o dispositivo faz com que deCONZ reaprenda a rota.

Esses problemas de roteamento foram introduzidos com o suporte para a descoberta de roteamento usada pelas luzes Trådfri, então 2.04.40 parece certo.

Hmm, não sei, tem sido tão ruim para mim há tanto tempo. Eu o mantive atualizado continuamente.

Hmm, não sei, tem sido tão ruim para mim há tanto tempo.

É um problema intermitente. Não fui capaz de reproduzi-lo à vontade, consulte # 849. Na verdade, todas as minhas regras para controlar as luzes são baseadas em /groups ações, portanto, nunca percebi o problema antes, até obter o controlador de cortina.

Quando uma luz fica indisponível, os comandos de grupo funcionam para mim, mas apenas por um tempo limitado. Depois disso, a luz fica acesa ou apagada e não responde mais a um comando de grupo.

Eu teorizaria que a luz decide sair da rede, quando não recebe ACKs do gateway por seus relatórios de atributos por um longo tempo.

Eu teorizaria que a luz decide sair da rede, quando não recebe ACKs do gateway por seus relatórios de atributos por um longo tempo.

Para mim, isso acontece também com luzes que foram ligadas ou desligadas apenas alguns minutos / horas antes.

Como postado algumas respostas acima, a maioria das minhas luzes GU10 são ligadas a um Hue Dimmer Switch (3-8 em uma sala com um Hue Dimmer Switch próprio). Alguns não estão, e estão online há meses. Nunca um deles ficou indisponível. Coincidência ou não .. O que você acha disso @ebaauw?

a maioria das minhas luzes GU10 são ligadas a um interruptor Hue Dimmer

Isso parece improvável. Você criou uma ligação no painel _Bind Dropbox_ na GUI deCONZ do interruptor do dimmer para a luz?

Observe que "vinculação" em termos ZigBee significa: criar uma entrada na tabela de vinculação do dispositivo para qual endereço ZigBee enviar comandos do cluster vinculado. Eu acho que os clusters (cliente!) _OnOff_ e _Level Control_ do seu interruptor dimmer estão vinculados a um grupo (pelo plugin deCONZ REST API). Este grupo está listado no recurso ZHASwitch em config.group . Em seguida, a luz foi adicionada a este grupo. Os grupos ZigBee são mais como endereços multicast, então provavelmente é mais correto dizer que a luz se inscreveu em mensagens para este grupo.

Em teoria, suponho, o firmware leve poderia ter um bug, fazendo com que travasse durante o processamento de comandos recebidos por um grupo. Eu não acho que isso seja provável, no entanto. Eu verificaria quão próximas (quantos saltos na rede ZigBee) as luzes estão do RaspBee / ConBee e / ou se todas as luzes têm o mesmo hardware e revisão de firmware. A IKEA parece estar lançando novas versões ZigBee 3.0 (ZHA) de todos os seus dispositivos.

a maioria das minhas luzes GU10 são ligadas a um interruptor Hue Dimmer

Isso parece improvável. Você criou uma ligação no painel _Bind Dropbox_ na GUI deCONZ do interruptor do dimmer para a luz?

Observe que "vinculação" em termos ZigBee significa: criar uma entrada na tabela de vinculação do dispositivo para qual endereço ZigBee enviar comandos do cluster vinculado. Eu acho que os clusters (cliente!) _OnOff_ e _Level Control_ do seu interruptor dimmer estão vinculados a um grupo (pelo plugin deCONZ REST API). Este grupo está listado no recurso ZHASwitch em config.group . Em seguida, a luz foi adicionada a este grupo. Os grupos ZigBee são mais como endereços multicast, então provavelmente é mais correto dizer que a luz se inscreveu em mensagens para este grupo.

Não, eu não criei um binding no painel _Bind Dropbox_ na GUI deCONZ.

Você quer dizer que adicionar luzes a esses grupos no aplicativo Phoscon não cria uma ligação entre o controle remoto e as luzes? Presumi que sim, porque alternar as luzes adicionadas com o Hue Dimmer Switch correspondente também é possível quando meu contêiner docker deCONZ ou NUC inteiro está offline.

Ok, agora tenho um bulp que não responde. Estava acinzentado em bth deCONZ e Phoscon.

Ele reagiu a comandos remotos e também quando movi o controle deslizante no modo "grupo" no Phoscon,

O deCONZ ainda atualiza o estado da luz quando você os controla pelo controle remoto?

Não no início, pois estava esmaecido.

Em seguida, tentei "redefinir o nó selecionado" no deCONZ e, por alguns minutos, não ficou mais acinzentado, embora não tivesse mais o botão de rádio do cluster no deCONZ.

Ainda respondia apenas aos comandos remotos e de grupo, mas agora o estado claro foi atualizado.

Depois de um tempo, tornou-se acinzentado novamente no Phoscon.

Em seguida, tentei desligar a energia por alguns minutos. Não ajudou.

Uma situação interessante ocorreu esta noite:

Uma das luzes GU10 brancas quentes da Tradfri está desligada novamente há algumas horas. O Hue Dimmer Switch que está ligado a 8 GU10s, incluindo aquele que está offline agora, liga / desliga, de acordo com deconz, GU10 offline. Estranho o suficiente, apenas aquele.
Os outros GU10s não respondem ao switch Hue Dimmer ligado.

Alternar o grupo com a API restante irá ligar / desligar todas as luzes, incluindo o GU10 offline.

Quando um GU10 ficou offline antes, o Hue Dimmer Switch vinculado liga / desliga todas as luzes no grupo, incluindo o, de acordo com o deconz, o GU10 offline (mais cedo ou mais tarde, de acordo com deconz, o GU10 offline também para de ouvir os comandos do grupo ou).

Isso poderia ser útil?

\ Edit: O 'Nome' deste GU10 offline no deCONZ via VNC está vazio.

Ao preencher novamente, não está definido (nunca fiz isso aqui, normalmente no aplicativo Phoscon):

Ainda amarelo:

Pressionar '0' ou 'Redefinir nó selecionado' não coloca o GU10 novamente online.

Edição 2 : Cerca de 24 horas depois que o GU10 ficou offline, o GU10 não está mais respondendo ao Hue Dimmer Switch ligado, conforme descrito antes. Nenhuma das luzes GU10 do grupo não está respondendo agora. O nó na GUI deCONZ ainda está amarelo, mas o nome está em cinza.
Depois de dar energia à luz GU10 off-line, todas as 8 luzes no grupo, incluindo a que estava off-line, estão respondendo ao interruptor Hue Dimmer ligado novamente.

@manup Este comportamento / situação é bastante diferente de antes, talvez isso possa ajudar a encontrar a causa?

Acabei de perceber uma, talvez, adição interessante a este problema.

Várias salas estão equipadas com vários pontos Tradfri GU10 e a maioria das salas com um Hue Dimmer Switch, com uma ligação direta aos GU10s na sala criada ao adicioná-los ao grupo Hue Dimmer Switch no aplicativo Phoscon.

• Apenas o GU10 com ligação direta com um switch Hue Dimmer fica offline de vez em quando e precisa de um ciclo de energia para voltar a ficar online.
• GU10s sem ligação direta com um switch Hue Dimmer não ficam offline.

Infelizmente, um dos meus Tradfri GU10 warmwhite sem um Hue Dimmer Switch está offline desde ontem.

Ainda me perguntando por que alguns pontos GU10 (mesmo branco quente) _nunca_ estão offline.
\ Edit : Também um GU10 que ficou online por meses, está offline desde ontem.

Comprei um Tradfri Hub na semana passada e emparelhei todos os pontos GU10 de um quarto com ele. Vamos ver o que acontece nas próximas semanas ..

Luzes aleatórias no meu sistema começaram a não responder depois que eu adicionei quatro interruptores IKEA liga / desliga ao meu sistema (para as luzes da janela de natal) ... As tomadas estão espalhadas por toda a minha casa. Pelo menos uma das luzes do meu sistema precisa ser desligada e ligada por dia.

Posso fornecer qualquer tipo de registro ou informação para facilitar a solução de problemas?

@tubalainen O que você quer dizer com não responsivo? Eles estão respondendo sozinhos ou precisam de um ciclo de energia?

@tubalainen O que você quer dizer com não responsivo? Eles estão respondendo sozinhos ou precisam de um ciclo de energia?

Eles são listados como "online" (não esmaecidos) e fazem parte da malha de acordo com minha imagem, mas quando alternados no Home Assistant (ou via phoscon) nada acontece. Para fazê-los funcionar novamente, preciso fazer um ciclo de energia.

Existe algum progresso nisso? Está ficando um pouco ridículo com minhas luzes GU10 ficando cinza :(

Acho que vi alguém mencionar o controlador de cortina ou o botão liga / desliga. Na verdade, me ocorreu que os problemas pioraram muito na época em que comprei as cortinas FYRTUR. Este também foi o primeiro botão ikea que adicionei à rede ... Não sei ...

Não tenho interruptores de parede liga / desliga Tradfri ou cortinas IKEA aqui e tenho o problema.

Tive esse problema durante o verão. Meus GU10s desistiam o tempo todo. Eu atualizei todos os meus GU10s para o software de "teste" mais recente e estou executando sem problemas por quase dois meses.

No fim de semana passado, adicionei algumas novas lâmpadas E27 e agora várias das minhas GU10s estão caindo de novo.

Tive esse problema durante o verão. Meus GU10s desistiam o tempo todo. Eu atualizei todos os meus GU10s para o software de "teste" mais recente e estou executando sem problemas por quase dois meses.

No fim de semana passado, adicionei algumas novas lâmpadas E27 e agora várias das minhas GU10s estão caindo de novo.

Quais lâmpadas GU10 você tem e qual firmware instalou?

Comprei um Tradfri Hub na semana passada e emparelhei todos os pontos GU10 de um quarto com ele. Vamos ver o que acontece nas próximas semanas ..

Quando usei o gateway Tradfri, tinha lâmpadas que não respondiam quase todos os dias (espectro branco Tradfri GU10, primeira geração). Mudei para a ponte Philips Hue e o problema parecia ter desaparecido, mas após 2 semanas uma lâmpada deixou de responder (como de costume, um ciclo de energia resolveu o problema).

Não sei por que e como a ponte Hue funciona melhor com as lâmpadas Tradfri, mas me parece que o verdadeiro problema são as lâmpadas.

Não possuo um único GU10 e ainda tenho o problema.

Diga-me como posso ajudar com logs, etc., para tentar resolver isso.
Parece leve (meu palpite aqui) que alguns nós "adormecem" e não acordam na primeira tentativa de acordá-los?

Isso é um problema apenas quando há vários saltos de nó na malha? Para mim, é bastante conseqüente quando há mais de um salto para o conbee. Novamente, apenas um sentimento. Não confirmado.

Eu tenho 8 GU-10 com cerca de 18 meses. Um deles ficou cinza uma vez nesse período. Eles estão todos na mesma sala que o bastão de conbee. Eu tenho umas lâmpadas de 980lm de 3 anos. O mais distante do gw que salta via gu 10 fica cinza talvez uma vez a cada quinze dias.
@tubalainen pode estar no

Ao lado daquele que está ficando cinza, eu tenho um Osram que nunca deu errado.

Sim, @tubalainen pode ter uma pista. Na verdade, tenho colocado meus GU10s cinza em um soquete de lâmpada em um cabo que uso ao adicionar novas luzes e, quando estão lá, muitas vezes voltam à vida. Mas então, quando eu os coloco de volta em seus lugares, eles estão fora novamente. Não é 100% consistente que eles voltem, mas ainda pode ser uma coisa cúmplice.

Aqui está outra pista potencial. Eu nunca tive nenhuma lâmpada ficando cinza (em mais de um ano de tempo de atividade com 8 lâmpadas IKEA), mas então eu atualizei o plugin deconz do Home Assistant de 3.8 para 3.9 e em dois dias eu tinha duas GU10 ficando cinza, restaurou um backup da versão 3.8 do plugin e não houve problemas desde então. O estranho é que os plugins 3.8 e 3.9 usam a mesma versão de deconz (se o log de alterações estiver completo). No entanto, mesmo em Phoscon, as lâmpadas eram inacessíveis. Isso tudo é bastante estranho, mas suponho que a versão 3.9 do plugin faz algum tipo de solicitação de desconexão que torna as lâmpadas IKEA instáveis.

Eu não uso HA e ainda sofro com o problema. Comprei um novo GU10 e agora troco todas as lâmpadas que ficam cinza mais de uma vez. Qualquer lâmpada que eu substituí ainda não ficou cinza novamente. Pode ser um problema de hardware, pode não, mas parece que não teremos uma solução tão cedo.

Eu tenho problemas semelhantes. Alguns dos nós de luz não respondem aos comandos e se tornam cinza. O estranho é que se eu enviar comandos de grupo, o mesmo nó de luz responde perfeitamente todas as vezes.

Eu tenho problemas semelhantes. Alguns dos nós de luz não respondem aos comandos e se tornam cinza. O estranho é que se eu enviar comandos de grupo, o mesmo nó de luz responde perfeitamente todas as vezes.

Um comando de grupo continua funcionando depois, digamos, alguns dias / mais de uma semana?
No meu caso: mais cedo ou mais tarde a luz também deixa de ouvir os comandos do grupo.

Eu tenho problemas semelhantes. Alguns dos nós de luz não respondem aos comandos e se tornam cinza. O estranho é que se eu enviar comandos de grupo, o mesmo nó de luz responde perfeitamente todas as vezes.

Um comando de grupo continua funcionando depois, digamos, alguns dias / mais de uma semana?
No meu caso: mais cedo ou mais tarde a luz também deixa de ouvir os comandos do grupo.

Sim, parece funcionar bem com o tempo também. Mas eu tenho uma teoria do que está errado. Quando os nós de luz são encaminhados através da lâmpada TRADFRI E27 WS opala 1000lm, os problemas ocorrem. Então ontem eu desliguei os dois que tinha na minha rede. Desde então, tudo parece funcionar perfeitamente.

Tenho lâmpada TRADFRI GU10 WS 400lm, lâmpada TRADFRI E14 CWS opala 600lm e lâmpada TRÅDFRI E27 CWS opala 600lm. Eles não parecem causar nenhum problema.

Pode estar relacionado com o firmware Trådfri mais antigo. Luzes mais recentes vêm com firmware mais recente, mas não acho que a IKEA publicou um firmware atualizado para todas as luzes de primeira geração. Não tenho nenhum ponto Trådfri GU10, mas a lâmpada CWS recebeu uma atualização de firmware. Minha lâmpada regulável de 1000lm não; Não tenho certeza sobre a lâmpada do espectro branco.

Pode estar relacionado com o firmware Trådfri mais antigo. Luzes mais recentes vêm com firmware mais recente, mas não acho que a IKEA publicou um firmware atualizado para todas as luzes de primeira geração. Não tenho nenhum ponto Trådfri GU10, mas a lâmpada CWS recebeu uma atualização de firmware. Minha lâmpada regulável de 1000lm não; Não tenho certeza sobre a lâmpada do espectro branco.

Minha lâmpada TRADFRI GU10 WS 400lm está no mesmo firmware, 2.0.022. Eles não parecem causar problemas (ainda :))

Pode estar relacionado com o firmware Trådfri mais antigo. Luzes mais recentes vêm com firmware mais recente, mas não acho que a IKEA publicou um firmware atualizado para todas as luzes de primeira geração. Não tenho nenhum ponto Trådfri GU10, mas a lâmpada CWS recebeu uma atualização de firmware. Minha lâmpada regulável de 1000lm não; Não tenho certeza sobre a lâmpada do espectro branco.

Concordo. A primeira versão das lâmpadas Ikea (em 1. * firmware) tinha algum bug de software / hardware que não afeta as segundas iterações (em 2. *).

Infelizmente, parece que a Ikea não suporta mais a versão original e não fornecerá nenhuma atualização de firmware. Ao mesmo tempo não é possível devolver as lâmpadas e trocar por novas (já tentei, no Reino Unido).

Pode estar relacionado com o firmware Trådfri mais antigo. Luzes mais recentes vêm com firmware mais recente, mas não acho que a IKEA publicou um firmware atualizado para todas as luzes de primeira geração. Não tenho nenhum ponto Trådfri GU10, mas a lâmpada CWS recebeu uma atualização de firmware. Minha lâmpada regulável de 1000lm não; Não tenho certeza sobre a lâmpada do espectro branco.

Concordo. A primeira versão das lâmpadas Ikea (em 1. * firmware) tinha algum bug de software / hardware que não afeta as segundas iterações (em 2. *).

Infelizmente, parece que a Ikea não suporta mais a versão original e não fornecerá nenhuma atualização de firmware. Ao mesmo tempo não é possível devolver as lâmpadas e trocar por novas (já tentei, no Reino Unido).

Eu tenho lâmpadas cws em 1.3.009. Eles não parecem causar problemas.

Atualizar:

Parece que outras lâmpadas IKEA também estão causando problemas.

Aqui estão minhas lâmpadas IKEA. Até agora é apenas a lâmpada TRADFRI E27 WS opala 1000lm que está causando problemas. Eles agora estão desconectados e as coisas parecem funcionar. Mas eu posto uma atualização se estou recebendo novos erros.

Parece que não tenho nenhum dispositivo 2.x.
Alguns GU10 funcionam bem, outros não. Comecei a substituir os defeituosos por outros "novos" que comprei alguns meses depois. Eles parecem executar o mesmo firmware, embora haja um número "1808-S" impresso no soquete, enquanto os "mais recentes" têm "1729-S".
Troquei 3 lâmpadas até agora e nenhum problema novo ocorreu por 2 semanas. Não tive apenas o problema com o GU10, mas também com um painel FLOALT que não substituí.

Parece que não tenho nenhum dispositivo 2.x. Alguns GU10 funcionam bem, outros não. Comecei a substituir os defeituosos por outros "novos" que comprei alguns meses depois. Eles parecem executar o mesmo firmware, embora haja um número "1808-S" impresso no soquete, enquanto os "mais recentes" têm "1729-S". Troquei 3 lâmpadas até agora e nenhum problema novo ocorreu por 2 semanas. Não tive apenas o problema com o GU10, mas também com um painel FLOALT que não substituí.

Interessante! Vou dar uma olhada nas minhas lâmpadas para ver se há algum tipo de correlação.

Parece que um dos meus nós foi afetado pelo problema novamente. Ainda tenho alguns nós IKEA na rede, então farei alguns testes para ver se consigo tirar algumas conclusões.

Tenho lâmpada TRADFRI GU10 WS 400lm, lâmpada TRADFRI E14 CWS opala 600lm e lâmpada TRÅDFRI E27 CWS opala 600lm. Eles não parecem causar nenhum problema.

Parece que depois que a malha foi ativada por um tempo, até mesmo os outros dispositivos IKEA estão causando problemas e os nós param para responder aos comandos. Até mesmo outros nós IKEA podem ser afetados, para mim parece que os problemas começam a aparecer e os nós são roteados através de um nó IKEA.

Há alguma atividade planejada para analisar isso? Vou mover todos os meus dispositivos IKEA para o meu gateway hue enquanto isso é resolvido.

os nós param para responder aos comandos.

Tem certeza que é esse o caso? Você confirmou isso ao farejar o tráfego do ZigBee? Os outros nós não reagem mais aos interruptores sem fio que controlam as luzes sem passar pelo gateway? Eles não reagem mais aos comandos do grupo?
Na minha experiência, o problema é que o gateway não conhece mais a rota para os outros nós, portanto, os comandos unicast do gateway nunca alcançam os outros nós. Os próprios nós estão respondendo muito bem, eles simplesmente não recebem nada para responder.

Até mesmo outros nós IKEA podem ser afetados, para mim parece que os problemas começam a aparecer e os nós são roteados através de um nó IKEA.

O (não?) Nó de roteamento IKEA de alguma forma interrompe a rota de e / ou descoberta de rota pelo gateway para os outros nós.

Há alguma atividade planejada para analisar isso?

Você terá que pedir suporte à dresden elektronik. O roteamento é gerenciado pelo firmware RaspBee / ConBee (e o programa central deCONZ?). Não há nada que possamos fazer sobre isso no plug-in da API REST.

Comprei um Tradfri Hub na semana passada e emparelhei todos os pontos GU10 de um quarto com ele. Vamos ver o que acontece nas próximas semanas ..

Talvez seja um pouco cedo para dizer, mas há 29 dias mudei todos os Tradfri GU10s (8x warmwhite - 1.2.214) de uma sala para um Tradfri Hub, e nenhum deles parou de responder até agora.

Talvez seja um pouco cedo para dizer, mas há 29 dias mudei todos os Tradfri GU10s (8x warmwhite - 1.2.214) de uma sala para um Tradfri Hub, e nenhum deles parou de responder até agora.

Eu esperava que sim. O problema não é tanto causado por dispositivos de um único fabricante, mas pela interação entre dispositivos de fabricantes diferentes, interpretando o padrão ZigBee de forma diferente. É por isso que a maioria dos hubs / gateways / bridges só oferece suporte a seus próprios dispositivos. Um experimento mais interessante seria conectar os pontos Trådfri a à ponte Hue ou ao gateway OSRAM.

Além disso, oito luzes em uma única sala provavelmente resultarão em uma conexão direta entre o hub e cada luz: todas as conexões de salto único. Problemas de roteamento aparecem apenas em redes maiores, com mais dispositivos do que entradas em uma tabela de vizinhos (normalmente cerca de 20); e / ou com dispositivos fisicamente fora do alcance do hub.

os nós param para responder aos comandos.

Tem certeza que é esse o caso? Você confirmou isso ao farejar o tráfego do ZigBee? Os outros nós não reagem mais aos interruptores sem fio que controlam as luzes sem passar pelo gateway? Eles não reagem mais aos comandos do grupo?
Na minha experiência, o problema é que o gateway não conhece mais a rota para os outros nós, portanto, os comandos unicast do gateway nunca alcançam os outros nós. Os próprios nós estão respondendo muito bem, eles simplesmente não recebem nada para responder.

Não tenho experiência ou equipamento para farejar o tráfego. Você provavelmente está correto sobre como o problema está se comportando. Meus nós respondem aos comandos do grupo o tempo todo. O problema é (se eu entendi) que os comandos unicast nunca alcançam seu destino.

Contanto que eu apenas envie comandos de grupo, tudo parece funcionar muito bem.

Até mesmo outros nós IKEA podem ser afetados, para mim parece que os problemas começam a aparecer e os nós são roteados através de um nó IKEA.

O (não?) Nó de roteamento IKEA de alguma forma interrompe a rota de e / ou descoberta de rota pelo gateway para os outros nós.

Há alguma atividade planejada para analisar isso?

Você terá que pedir suporte à dresden elektronik. O roteamento é gerenciado pelo firmware RaspBee / ConBee (e o programa central deCONZ?). Não há nada que possamos fazer sobre isso no plug-in da API REST.

Sim, enviei um e-mail para eles, mas não obtive nenhuma resposta além de algum checklist.

Talvez seja um pouco cedo para dizer, mas há 29 dias mudei todos os Tradfri GU10s (8x warmwhite - 1.2.214) de uma sala para um Tradfri Hub, e nenhum deles parou de responder até agora.

Eu esperava que sim. O problema não é tanto causado por dispositivos de um único fabricante, mas pela interação entre dispositivos de fabricantes diferentes, interpretando o padrão ZigBee de forma diferente. É por isso que a maioria dos hubs / gateways / bridges só oferece suporte a seus próprios dispositivos. Um experimento mais interessante seria conectar os pontos Trådfri a à ponte Hue ou ao gateway OSRAM.

Além disso, oito luzes em uma única sala provavelmente resultarão em uma conexão direta entre o hub e cada luz: todas as conexões de salto único. Problemas de roteamento aparecem apenas em redes maiores, com mais dispositivos do que entradas em uma tabela de vizinhos (normalmente cerca de 20); e / ou com dispositivos fisicamente fora do alcance do hub.

Fiz isso para garantir que não esteja relacionado ao firmware 1.2.214 do GU10 antigo, que é muito mencionado aqui como uma possível causa (e possível motivo para fazer uma nova versão do GU10).
Talvez em relação a conectado através de outro roteador.

Vou considerar emparelhar minhas outras luzes GU10 (também warmwhite 1.2.214) com o Hub Tradfri (também as do 2º andar / 3º andar)

Existe algum progresso nisso? Está ficando um pouco ridículo com minhas luzes GU10 ficando cinza :(

Acho que vi alguém mencionar o controlador de cortina ou o botão liga / desliga. Na verdade, me ocorreu que os problemas pioraram muito na época em que comprei as cortinas FYRTUR. Este também foi o primeiro botão ikea que adicionei à rede ... Não sei ...

Eu não tive o botão liga / desliga fyrtur na rede desde a minha última postagem e não houve interrupções nesse período. Pode ser uma coincidência ...?

Existe algum progresso nisso? Está ficando um pouco ridículo com minhas luzes GU10 ficando cinza :(
Acho que vi alguém mencionar o controlador de cortina ou o botão liga / desliga. Na verdade, me ocorreu que os problemas pioraram muito na época em que comprei as cortinas FYRTUR. Este também foi o primeiro botão ikea que adicionei à rede ... Não sei ...

Eu não tive o botão liga / desliga fyrtur na rede desde a minha última postagem e não houve interrupções nesse período. Pode ser uma coincidência ...?

Não, não tenho cortinas Tradfri on / off ou Tradfri e tenho esse problema.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Fechado acidentalmente este problema. Reabrindo.

Um experimento mais interessante seria conectar os pontos Trådfri a à ponte Hue ou ao gateway OSRAM.

Tive o mesmo problema com as lâmpadas Trådfri (primeira geração) conectadas ao hub Trådfri. O problema desapareceu completamente quando mudei todas as lâmpadas para uma ponte Hue.

Aliás - ainda estou convencido de que a primeira geração de lâmpadas Trådfri está grampeada, mas a ponte Hue lida com as luzes de maneira diferente (notei que às vezes as luzes ficam fora de sincronia por uma fração de segundo quando conectadas a Hue - nunca aconteceu com Trådfri )

a ponte Hue lida com as luzes de maneira diferente (notei que às vezes as luzes ficam fora de sincronia por uma fração de segundo quando conectadas a Hue - nunca aconteceu com Trådfri).

Na configuração Hue, as luzes são controladas apenas pela ponte Hue: interruptores e sensores sem fio enviam notificações para a ponte, acionando regras que controlam as luzes. A ponte prevê o estado da luz e atualiza seu cache antecipadamente ao enviar comandos para as luzes. Ele controla as luzes periodicamente para validar / atualizar o estado em cache.

Na configuração Trådfri, as luzes são controladas diretamente por comandos de interruptores e sensores sem fio. As luzes então enviam um relatório com o estado atualizado para o hub.

Ao controlar luzes conectadas a uma ponte Hue diretamente de interruptores ou sensores sem fio (Trådfri), você verá um atraso porque a ponte Hue não configura relatórios de atributo sobre as luzes. Quanto mais luzes em sua rede, maior será o atraso, pois a votação passa por mais luzes.

Ao conectar lâmpadas Hue a um hub Trådfri e controlar essas luzes diretamente de interruptores ou sensores sem fio (Trådfri), o estado do hub nunca será atualizado, pois as luzes Hue não geram relatórios de atributos e o hub Trådfri não faz pesquisas.

Observe que essas diferenças estão no nível do aplicativo, bem dentro do controle do plugin REST API. O roteamento está em um nível inferior na pilha ZigBee.

Agora, todos os nós do meu roteador IKEA foram movidos para a minha hue bridge. Ainda tenho o mesmo problema na minha rede. Portanto, suspeito que seja outra coisa que o esteja causando. E, novamente, afeta os nós que são roteados e não têm link direto com o gateway.

Agora, todos os nós do meu roteador IKEA foram movidos para a minha hue bridge. Ainda tenho o mesmo problema na minha rede. Portanto, suspeito que seja outra coisa que o esteja causando. E, novamente, afeta os nós que são roteados e não têm link direto com o gateway.

O mesmo problema com as luzes Tradfri que agora estão emparelhadas com a ponte Hue?

@ebaauw o problema de roteamento deve aparecer quando uma luz está conectada à ponte diretamente E por meio de um roteador ou apenas quando não está diretamente conectada à ponte?

Agora, todos os nós do meu roteador IKEA foram movidos para a minha hue bridge. Ainda tenho o mesmo problema na minha rede. Portanto, suspeito que seja outra coisa que o esteja causando. E, novamente, afeta os nós que são roteados e não têm link direto com o gateway.

O mesmo problema com as luzes Tradfri que agora estão emparelhadas com a ponte Hue?

Tenho apenas 3 lâmpadas emparelhadas. Mas nenhum problema que eu tenha notado.

@ebaauw o problema de roteamento deve aparecer quando uma luz está conectada à ponte diretamente E por meio de um roteador ou apenas quando não está diretamente conectada à ponte?

Em minha rede, minha expectativa é que problemas com comandos perdidos estão afetando nós que são roteados por outros nós e não diretamente com o gateway. Tenho os mesmos problemas agora, mesmo quando nenhuma lâmpada IKEA está conectada.

Eu tinha um nó (1) sem link direto para o gateway. Ele não respondeu (ou, como ebaauw mencionou, talvez eles nunca cheguem ao nó devido a problemas de roteamento) aos comandos unicast. Quando desliguei o nó (2), ele foi roteado através do nó (1), conseguiu uma rota direta para o gateway e começou a funcionar perfeitamente.

o problema de roteamento deve aparecer quando uma luz é conectada diretamente à ponte E por meio de um roteador ou apenas quando não está diretamente conectada à ponte?

Não existem "conexões" no ZigBee. Cada roteador mantém uma tabela de vizinhos de dispositivos próximos, que pode alcançar diretamente (no nível MAC). As linhas na GUI deCONZ nada mais são do que uma representação gráfica dessas tabelas vizinhas (na medida em que deCONZ as leu).

Quando um roteador precisa enviar uma mensagem a um dispositivo que não está em sua tabela vizinha, ele envia a solicitação a um roteador vizinho, para que ele possa encaminhá-la. A mensagem única no nível NWK é retransmitida em vários saltos no nível MAC. O RaspBee / ConBee (nesta perspectiva) é apenas outro roteador. Afaik um dispositivo final apenas envia mensagens para seu roteador pai.

Portanto, quando uma luz está na tabela vizinha do RaspBee / ConBee, nenhuma descoberta de rota está envolvida, independentemente de a luz ser a tabela vizinha de outros roteadores. Quando não é, o RaspBee / ConBee precisa descobrir qual roteador vizinho sabe como alcançar a luz. Se a luz estiver a vários saltos de distância, cada roteador no caminho para ela recursivamente precisa fazer o mesmo.

Receio que os detalhes não saibam, mas há várias maneiras de fazer essa descoberta de rota. Quando os roteadores no caminho entre o gateway e a lâmpada usam maneiras diferentes, as coisas podem dar errado. O gateway pode acabar enviando a mensagem para o roteador vizinho errado (que não sabe como alcançar a luz), ou o gateway pode não saber como alcançar a luz e não enviará nenhuma mensagem. As mensagens unicast geralmente devem ser respondidas com um ACK, então o gateway marcará um dispositivo como inacessível quando não receber o ACK. Obviamente, não há como saber se a mensagem original ou o ACT foi perdido (o dispositivo remoto precisa saber a rota até o gateway para enviar o ACK).

Mensagens de difusão (usadas por comandos de grupos) não usam nenhum roteamento; eles são simplesmente retransmitidos no nível MAC por todos os roteadores. Embora sejam muito confiáveis, eles consomem muita largura de banda da rede. Além disso, eles não são respondidos por um ACK.

Em minha rede, minha expectativa é que problemas com comandos perdidos estão afetando nós que são roteados por outros nós e não diretamente com o gateway. Tenho os mesmos problemas agora, mesmo quando nenhuma lâmpada IKEA está conectada.

Portanto, para problemas de roteamento, você precisa de uma rede que seja grande o suficiente para que os dispositivos não apareçam na tabela de roteamento do RaspBee / ConBee. Ou porque o número de dispositivos excede o tamanho da tabela de roteamento ou porque os dispositivos remotos estão fisicamente fora do alcance do RaspBee / ConBee e só podem ser alcançados por outros roteadores. Suponho que vários saltos piorariam o problema.

Mais uma vez, não é tanto culpa da IKEA, mas sim de diferentes fabricantes que usam maneiras diferentes e um tanto incompatíveis de fazer descoberta de rotas. Especialmente com rotas de vários saltos, há muito que pode ser contornado no firmware RaspBee / ConBee.

Eu tinha um nó (1) sem link direto para o gateway. Ele não respondeu (ou, como ebaauw mencionou, talvez eles nunca cheguem ao nó devido a problemas de roteamento) aos comandos unicast. Quando desliguei o nó (2), ele foi roteado através do nó (1), conseguiu uma rota direta para o gateway e começou a funcionar perfeitamente.

Mais uma vez, temo que os detalhes se perdem em mim, mas posso pensar em vários cenários que podem causar esse comportamento. O RaspBee / ConBee deseja enviar uma mensagem para node2 ou node1, não recebe um ack, conclui que node2 está inacessível e o remove de sua tabela vizinha. A mesa agora tem espaço para uma nova entrada, que é usada para node1.

Mais uma vez, não é tanto culpa da IKEA, mas sim de diferentes fabricantes que usam maneiras diferentes e um tanto incompatíveis de fazer descoberta de rotas. Especialmente com rotas de vários saltos, há muito que pode ser contornado no firmware RaspBee / ConBee.

Isso me parece que a abordagem de uma plataforma ZigBee de vários fornecedores está condenada por design até que um padrão mais completo seja estabelecido e seguido. Ainda estou meio bloqueado agora, pois não quero usar vários gateways que provavelmente não funcionariam no meu ambiente de qualquer maneira (por exemplo, para sensores que não podem ser alcançados diretamente pelo gateway se eu remover as lâmpadas que atuam atualmente como roteadores).

Isso me parece que a abordagem de uma plataforma ZigBee de vários fornecedores está condenada

Certamente espero que não, mas é definitivamente desafiador. O tamanho parece importar aqui: se sua rede for pequena o suficiente, você pode não ter esses problemas de roteamento. Além disso, se o centro (geográfico) de sua rede consistir em roteadores de fornecedores compatíveis, alguns roteadores menos compatíveis na borda de sua rede provavelmente não farão diferença (já que eles não são roteados para alcançar outros dispositivos).

Substituí minhas lâmpadas OSRAM, Trådfri e innr (que estavam causando problemas) por lâmpadas Hue. Agora tenho 104 nós, 51 roteadores e 53 dispositivos finais. 2/3 dos roteadores são luzes Hue. O único roteador que se torna inacessível (mas ainda envia relatórios) é o controlador de cortina Xiaomi. 20 dos dispositivos finais são Hue, 20 Xiaomi, 8 Eurotronic Spirit e 5 IKEA. O Espírito Eurotronic e IKEA Fyrtur estão me causando problemas regularmente (eles são expulsos por seus pais, mas não encontram um novo pai - novamente inacessível pelo gateway, mas ainda enviando relatórios), os outros parecem bem. Para todos os dispositivos, desligar e ligar a alimentação geralmente resolve a situação, mas às vezes preciso abrir a rede ao desligar e ligar o dispositivo.

Tenho considerado dividir minha rede, não por fornecedor, mas por andar ou lado da rua versus parte de trás da minha casa. Isso é muito trabalhoso e estou relutante em fazê-lo, até que tenha uma melhor compreensão do que está causando os problemas em detalhes e que configuração pode impedir que eles ocorram.

@ebaauw , pensando no que você falou no post acima, seria interessante considerar uma espécie de preferência pela tabela de roteamento deCONZ. Podemos considerar roteadores em 'lista negra' que não sejam preferíveis como primeiro salto. Se você puder construir sua rede para conter roteadores "bons" suficientes, então o primeiro salto será sempre através deles e o segundo salto alcançará todos os outros dispositivos na rede.
Essa não seria uma solução definitiva, mas permitiria redes muito maiores (geográficas e número de dispositivos), sempre passando por roteadores 'preferenciais'.

Outro pensamento: como sabemos quais chips são usados ​​pela IKEA (Silabs EFR32, motor gecko) e sabemos (de várias fontes na rede) que eles usam o motor zigbee fornecido pela Silabs, podemos considerar duas ações.

1. Analisamos a forma como o motor silabs faz o roteamento e daí derivamos o que está causando esse problema
2. Nós construímos uma versão personalizada do firmware da lâmpada com base no mesmo mecanismo silabs, corrigimos o problema e descobrimos uma maneira de instalar esse firmware por OTA

Ambos exigiriam acesso ao SDK da Silabs, o que eu não faço. É alguém ativo aqui que faz ..? Não estou ansioso para desembolsar US $ 500 para o kit de desenvolvimento que inclui o SDK. Talvez a Dresden Electronics esteja disposta a fazer isso?

meus 2 cts (ficando bastante frustrado com as conexões perdidas ocasionalmente).

Podemos considerar roteadores em 'lista negra' que não sejam preferíveis como primeiro salto.

Nós não. Teria que ser implementado no firmware RaspBee / ConBee, suponho. Não é uma má ideia, mas não tenho ideia de como isso é viável, dadas as limitações de tamanho no dispositivo EEPROM e NVRAM. @manup , o que você acha disso?

1. Nós construímos uma versão personalizada do firmware da lâmpada com base no mesmo mecanismo silabs, corrigimos o problema e descobrimos uma maneira de instalar esse firmware por OTA

Isso está muito além do meu conhecimento atual e, francamente, da minha ambição - faço isso por um hobby. Tenho brincado com o XBee para ver se consigo escrever um aplicativo ZigBee (meu objetivo final seria smartify minhas venezianas), mas nunca olhei para os níveis mais baixos da pilha ZigBee, onde ocorre o encaminhamento .

Nós não. Teria que ser implementado no firmware RaspBee / ConBee, suponho. Não é uma má ideia, mas não tenho ideia de como isso é viável, dadas as limitações de tamanho no dispositivo EEPROM e NVRAM. @manup , o que você acha disso?

Acho que considero @manup parte do We;)

Isso está muito além do meu conhecimento atual e, francamente, da minha ambição - faço isso por um hobby. Tenho brincado com o XBee para ver se consigo escrever um aplicativo ZigBee (meu objetivo final seria smartify minhas venezianas), mas nunca olhei para os níveis mais baixos da pilha ZigBee, onde ocorre o encaminhamento .

Eu concordo, para mim também é um hobby, mas espero que alguém conheça melhor esses detalhes.

Tenho feito algo semelhante usando placas CC2530 e estou planejando zigbeeify meu sistema de sprinklers (não posso aceitar, tenho que caminhar pelo jardim para ligar / desligar manualmente certos sprinklers :)) Consegui compilar um firmware zigbee para minha placa CC2530 que se conecta à rede deCONZ como uma luz liga / desliga. As válvulas que pretendo usar têm um mecanismo de travamento, portanto, exigem um sinal específico para trocar, portanto, tive que criar meu próprio firmware ...

Nós não. Teria que ser implementado no firmware RaspBee / ConBee, suponho. Não é uma má ideia, mas não tenho ideia de como isso é viável, dadas as limitações de tamanho no dispositivo EEPROM e NVRAM. @manup , o que você acha disso?

A pilha Zigbee no firmware tem um parâmetro para controlar se uma rota deve ser usada em vez de um link direto com base em sua qualidade (RSSI / LQI). Isso já deve funcionar muito bem e foi ajustado ao longo dos anos.

Um outro caminho pode ser uma abordagem mais geral para controlar as tabelas de roteamento de todos os dispositivos.

Nota: Você pode consultar a tabela de roteamento de um roteador selecionando-o e pressionando a tecla R , as rotas do próximo salto serão mostradas em azul.

Atualmente, quando a rede Zigbee é aberta, todos os roteadores podem ser um nó pai, pois Mgmt_Permit_Joining_req é enviado como broadcast. No entanto, se enviarmos essa solicitação como unicast apenas para um determinado roteador, um novo dispositivo só poderá ingressar por meio desse único dispositivo. Isso pode ser útil para dispositivos finais da Xiaomi, que muitas vezes ficam com seus pais. Para outros dispositivos de adesão, como roteadores e, por exemplo, dispositivos finais Philips Hue, isso não ajudará muito, pois eles são livres para selecionar novos pais e rotas por conta própria.

O (novo) Mgmt_NWK_IEEE_Joining_List_req na especificação Zigbee R22 também parece interessante:

O comando Mgmt_NWK_IEEE_Joining_List_req é fornecido como um mecanismo para obter a lista de endereços IEEE que devem ingressar na rede. Isso permite que o roteador local filtre as Solicitações de Beacon Avançado e responda apenas aos dispositivos que estão se conectando.

Sem os beacons, os dispositivos nem mesmo tentariam se conectar a um determinado roteador. Mas não estou ciente de quão bem essa solicitação é suportada pelos roteadores disponíveis atualmente.

Uma solução mágica pode ser usar o roteamento de origem, onde o gateway fornece a rota completa dentro de cada quadro, mas nunca vi isso ser usado por qualquer produto de consumo ou gateway e, portanto, acho que pode não ser (ou mal) suportado pelos roteadores atuais. Pode valer a pena tentar.

Nota: Você pode consultar a tabela de roteamento de um roteador selecionando-o e pressionando a tecla R , as rotas do próximo salto serão mostradas em azul.

Legal, eu não sabia disso. Existe uma visão geral de todas as teclas / comandos suportados pela GUI? É possível reverter as linhas azuis antes de consultar o próximo nó? Parece não funcionar para o RaspBee / ConBee em si?

A tabela de roteamento é diferente da tabela vizinha? Farejando, só vejo mensagens ZDP _Link Quality Request_ e _Link Quality Response_, relatando a tabela de vizinhos. Isso significa que as linhas para um nó que não são coloridas em azul são as rotas de "entrada"?

@manup , de fato uma visualização interessante

Uma solução mágica pode estar usando o roteamento de origem

Bem ... valeria a pena tentar, eu acho. Parece-me que, na minha rede, as luzes IKEA mais afectadas são as que estão mais distantes do coordenador. Tenho suspeitado que algo relacionado ao roteamento está causando os problemas, como @ebaauw mencionou.
Eu estaria disposto a testar algo assim para você. Embora eu tenha que admitir que perder as conexões não é muito confiável, o teste pode ser difícil.

Eu estava pensando mais no sentido de o coordenador ser seletivo sobre qual roteador selecionar para o primeiro salto. Se pudermos encontrar roteadores que funcionem bem com os dispositivos IKEA (talvez sejam os roteadores IKEA), rotear todos os pacotes por meio deles deve tornar as coisas mais robustas. Não tenho certeza se você pode enganar o processo de descoberta de rota para preferir um determinado roteador para o primeiro salto, mas provavelmente você pode comentar sobre isso, @manup

Nota: Você pode consultar a tabela de roteamento de um roteador selecionando-o e pressionando a tecla R , as rotas do próximo salto serão mostradas em azul.

Legal, eu não sabia disso. Existe uma visão geral de todas as teclas / comandos suportados pela GUI? É possível reverter as linhas azuis antes de consultar o próximo nó? Parece não funcionar para o RaspBee / ConBee em si?

Se alguém quiser listar todos os combos-chave e o que eles fazem, ficarei feliz em limpá-los e escrever uma página wiki.

Legal, eu não sabia disso. Existe uma visão geral de todas as teclas / comandos suportados pela GUI?

Descritor do nó de solicitação = 1
Request Power Descriptor = 2
Solicitar endereço Nwk = 0
Solicitar tabela de roteamento = R
Solicitar licença de gerenciamento = L (com reingressar, não use com luzes innr!)
Solicitar pontos de extremidade ativos = 7
Solicitar descritores simples = 8
Atualizar = F5 / Cmd-R
Excluir = Delete / Backspace
Dispositivo de gateway Annce = A (não tão útil)

É possível reverter as linhas azuis antes de consultar o próximo nó?

Ainda não, foi apenas uma adição rápida e suja para ver as rotas :)
Talvez adicionar outra chave como Shift-R para limpar as rotas de um nó seja útil?

Parece não funcionar para o RaspBee / ConBee em si?

Infelizmente RaspBee I / ConBee I não suporta o comando ZDP relacionado, ele funciona com ConBee II.

A tabela de roteamento é diferente da tabela vizinha? Farejando, só vejo mensagens de solicitação de qualidade de link ZDP e resposta de qualidade de link, relatando a tabela de vizinhos.

Estas são duas tabelas separadas, geralmente a tabela de roteamento contém apenas rotas para nós que não são diretamente alcançáveis ​​e estão sujeitos à tabela vizinha (nós de 1 salto).

Para nós que estão na tabela de vizinhos (e têm um sinal forte), nenhuma descoberta de rota é necessária. A própria tabela de vizinhos é construída principalmente usando comandos de status de link NWK de 1 salto.

Isso significa que as linhas para um nó que não são coloridas em azul são as rotas de "entrada"?

As linhas não azuis (verde / laranja / amarelo) representam apenas a tabela de vizinho de 1 salto. As linhas azuis são rotas de saída para algum destino e representam apenas o próximo salto (não a rota completa) na visualização atual, o endereço NWK de destino não é mostrado, mas provavelmente há impressões de depuração.

Nós não. Teria que ser implementado no firmware RaspBee / ConBee, suponho. Não é uma má ideia, mas não tenho ideia de como isso é viável, dadas as limitações de tamanho no dispositivo EEPROM e NVRAM. @manup , o que você acha disso?

A pilha Zigbee no firmware tem um parâmetro para controlar se uma rota deve ser usada em vez de um link direto com base em sua qualidade (RSSI / LQI). Isso já deve funcionar muito bem e foi ajustado ao longo dos anos.

Um outro caminho pode ser uma abordagem mais geral para controlar as tabelas de roteamento de todos os dispositivos.

Nota: Você pode consultar a tabela de roteamento de um roteador selecionando-o e pressionando a tecla R , as rotas do próximo salto serão mostradas em azul.

Função realmente útil! Ontem liguei minha lâmpada TRÅDFRI GU10 WS 400lm (7 lâmpadas) com firmware 2.0.022. Hoje os problemas voltaram, apareceu em uma lâmpada TRÅDFRI E27 CWS opala 600lm com firmware 1.3.009. Graças a esta função pude ver que a lâmpada E27 foi passada através das GU10. Desliguei todo o GU10 e como mágica o E27 começou a funcionar novamente.

Portanto, está ficando claro que o roteamento através do Innr e do IKEA está causando problemas. Comecei a mover lâmpadas Innr e IKEA para o meu gateway de matiz. Parece que as lâmpadas philips são bons roteadores e não estão causando problemas.

Então, fiz uma pequena experiência enquanto reposicionava minhas luzes na sala de estar. Tirei dois roteadores e reposicionei uma luz. Et voila, uma luz se transformou em zumbi, mas não completamente. Ele se comporta exatamente como eu vi com as luzes IKEA, que ocasionalmente perdem a conexão.

A luz IKEA está listada como inacessível, mas ainda responde aos comandos do grupo. Além disso, como ainda é conhecido por vários outros roteadores, parece que eles relataram ter visto a luz (é 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

e

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

Às vezes, parece que a comunicação é possível:

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

às vezes não:

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

Há muito pouca informação sobre o que está errado. O que significa o status 0xA7 ..?

Alguma informação adicional que possa ajudar a descobrir o que está acontecendo?

Então, fiz uma pequena experiência enquanto reposicionava minhas luzes na sala de estar. Tirei dois roteadores e reposicionei uma luz. Et voila, uma luz se transformou em zumbi, mas não completamente. Ele se comporta exatamente como eu vi com as luzes IKEA, que ocasionalmente perdem a conexão.

A luz IKEA está listada como inacessível, mas ainda responde aos comandos do grupo. Além disso, como ainda é conhecido por vários outros roteadores, parece que eles relataram ter visto a luz (é 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

e

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

Às vezes, parece que a comunicação é possível:

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

às vezes não:

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

Há muito pouca informação sobre o que está errado. O que significa o status 0xA7 ..?

Alguma informação adicional que possa ajudar a descobrir o que está acontecendo?

Isso soa como uma réplica exata dos meus problemas!

O que significa o status 0xA7 ..?

Veja aqui: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Desligou a luz

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

E parece feliz relatando seu status

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

então:

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

ele para de funcionar. até .. 2 minutos depois

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

Acho que preciso arranjar um farejador de zigbee para descobrir o que está acontecendo no ar.

depois disso, parou de funcionar novamente, um pouco mais permanente desta vez.

O que significa o status 0xA7 ..?

Veja aqui: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Obrigado por isso! de alguma forma é o que eu esperava ...

Tentei emparelhar minha lâmpada TRÅDFRI GU10 WS 400lm (7 lâmpadas) com minha ponte Philips Hue. Várias outras lâmpadas na rede tornaram-se indisponíveis e a lâmpada TRÅDFRI GU10 WS 400lm teve o mesmo comportamento que com Deconz, resposta no comando de grupo, mas não responde em unicast.

A lâmpada TRÅDFRI GU10 WS 400lm parece ter algum tipo de problema. Vou fazer alguns testes se são lâmpadas individuais ou todas elas que não estão funcionando.

Agora fiz alguns testes. Minha conclusão é que, na verdade, são as lâmpadas individuais que estão fazendo com que a rede pare de responder. Apareceram amêndoas instantaneamente na Hue Bridge e a coisa começou a funcionar novamente assim que eu desliguei. Portanto, de 7 lâmpadas, 3 são afetadas . Vou relatar se encontrar alguns novos problemas.

@MikaelHoogen , qual versão das lâmpadas e do firmware você tem?

Eu vi esse problema na v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS e todos os 3 painéis FLOALT nos gateways Ikea, HUE e DeCONZ no último ano e meio.
Estou convencido de que este é um problema de HW. É totalmente aleatório qual nó morre.
Aqui na Noruega, todos os produtos eletrônicos têm garantia de 2 anos. Vou tentar abrir um tíquete e ouvir o que dizem.
Em relação ao FLOALT. Há alguns meses, a Ikea estava fazendo uma liquidação sobre eles. Talvez fosse para se livrar de todo o v1?
Alguém viu um FLOALT v2 por aí? (com o driver sy5882, talvez?)

Eu vi esse problema na v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS e todos os 3 painéis FLOALT nos gateways Ikea, HUE e DeCONZ no último ano e meio.
Estou convencido de que este é um problema de HW. É totalmente aleatório qual nó morre.
Aqui na Noruega, todos os produtos eletrônicos têm garantia de 2 anos. Vou tentar abrir um tíquete e ouvir o que dizem.
Em relação ao FLOALT. Há alguns meses, a Ikea estava fazendo uma liquidação sobre eles. Talvez fosse para se livrar de todo o v1?
Alguém viu um FLOALT v2 por aí? (com o driver sy5882, talvez?)

É também o que venho tentando dizer há algum tempo. Tenho problemas apenas com lâmpadas Trådfri v1. A ponte Philips Hue ajuda, mas ainda assim os nós se tornam inacessíveis de vez em quando.

Há alguns dias, decidi substituir todas as 12 lâmpadas IKEA GU10 pela nova versão (branco quente).
Isso tornou o problema ainda pior. Agora também estou perdendo o ambiente de branco Hue GU10 e a cor Hue E14.

Tenho usado deConz e IKEA light desde o início, quando eles foram lançados. Tenho cerca de 70 nós em minha rede. A maioria delas sendo luzes IKEA. Eu também tenho alguns Philips Hue (4 luzes) e um Osram. Sensores Tenho poucos sensores de movimento Ikea e muitos sensores de movimento Xiaomi.

Eu tenho executado com esta configuração por um bom tempo e não passa um dia sem que uma das outras luzes fique presa, então eu preciso desligar e ligar. Minha esposa não está feliz e eu também não. Estou muito perto de abandonar todos os dispositivos zigbee e simplesmente ir para as luzes da velha escola. Simplesmente não funciona. muito decepcionante. Eu me pergunto se outras pessoas veem os mesmos problemas usando luzes puras Philips ou Osram ou é apenas IKEA que é uma porcaria?

Tenho usado deConz e IKEA light desde o início, quando eles foram lançados. Tenho cerca de 70 nós em minha rede. A maioria delas sendo luzes IKEA. Eu também tenho alguns Philips Hue (4 luzes) e um Osram. Sensores Tenho poucos sensores de movimento Ikea e muitos sensores de movimento Xiaomi.

Eu tenho executado com esta configuração por um bom tempo e não passa um dia sem que uma das outras luzes fique presa, então eu preciso desligar e ligar. Minha esposa não está feliz e eu também não. Estou muito perto de abandonar todos os dispositivos zigbee e simplesmente ir para as luzes da velha escola. Simplesmente não funciona. muito decepcionante. Eu me pergunto se outras pessoas veem os mesmos problemas usando luzes puras Philips ou Osram ou é apenas IKEA que é uma porcaria?

Observando todas as pessoas com exatamente os mesmos problemas neste tópico, os fabricantes do deconz não conseguem descobrir qual é o problema com as luzes IKEA, ele cheira e parece um problema de firmware IKEA.

Muitos usuários estão tendo problemas semelhantes, mesmo com o hub IKEA. Portanto, acho que esse não é um problema exclusivo relacionado ao deconz. No entanto, se alguém pudesse consertar isso, "consertar / encontrar uma solução alternativa" seriam os caras aqui! <3

Tenho exatamente o mesmo problema com a família e com a configuração.

É triste :( especialmente que até mesmo os novos que vendem hoje ainda têm esses problemas. Simplesmente não entendo. Tenho o meu de 2017, então você deve esperar que eles tenham resolvido o problema agora. Terei que considerar a remoção de todos Não pode ser consertado aqui, @manup disse antes que isso é um problema no firmware do dispositivo, então é apenas a IKEA que pode consertar isso e, uma vez que ainda não o fizeram, não há esperança.

Deconz versão 2.05.69
Firmware Conbee II 264A0700

Não é 100% perfeito e as falhas que percebi são lâmpadas E27 Ikea (Rev1).
Quando eu tinha essas luzes Ikea com minha ponte Philips Hue, elas eram sólidas como uma rocha, então provavelmente eu as movo de volta para Hue e mantenho essa malha Zigbee puramente CC2531 (firmware do roteador) e sensores Xiaomi.
Eu também tenho uma lâmpada Innr (E14) e uma SP120, mas ainda estão ok com Deconz.

Estou usando o Home Assistant e o Deconz para controlar cerca de 20 lâmpadas Ikea (e vários outros sensores). As lâmpadas são principalmente GU10s que são agrupadas por 3 pontos para uma luz.

Estou usando essa configuração há mais de 15 meses e, desde este verão, tive problemas com uma ou mais lâmpadas presas e precisando de um ciclo de alimentação, ou mesmo sendo removidas e adicionadas novamente à rede Zigbee. Sempre foram GU10s que foram definidos em um grupo leve em HASS.

Algumas semanas atrás, criei grupos para minhas luzes no Phoscon e comecei a fazer referência a esses grupos no HASS.

Depois disso, não tive nenhum problema com lâmpadas presas e precisando de um ciclo de energia. O único problema que vejo é que, ao desligar todas as luzes internas de uma vez, às vezes um grupo inteiro Phoscon / Deconz permanece aceso.

Para mim, isso parece um problema com a API Deconz e possivelmente com o manuseio de várias lâmpadas em rápida sucessão sobre ela.

Eu também tive problemas com dispositivos Ikea (lâmpadas e, recentemente, também o controle remoto Symfonisk) ficando indisponíveis e exigindo emparelhamento novamente com deCONZ. Eu carrego essas questões por 6 meses ou mais, eu acredito. Não há muito a acrescentar mais do que acho que acontece com mais frequência ultimamente. Não tenho lâmpadas GU10, apenas várias E27 e E14 (e vários controles remotos). Parece que certos dispositivos são mais propensos a cair (talvez dependendo de como eles se encaixam ou algo semelhante). Tenho aproximadamente 20 dispositivos com um alcance máximo de 5 m do Conbee I com o FW / Phoscon / deCONZ mais recente.

Eu também tive problemas com dispositivos Ikea (lâmpadas e, recentemente, também o controle remoto Symfonisk) ficando indisponíveis e exigindo emparelhamento novamente com deCONZ. Eu carrego essas questões por 6 meses ou mais, eu acredito. Não há muito a acrescentar mais do que acho que acontece com mais frequência ultimamente. Não tenho lâmpadas GU10, apenas várias E27 e E14 (e vários controles remotos). Parece que certos dispositivos são mais propensos a cair (talvez dependendo de como eles se encaixam ou algo semelhante). Tenho aproximadamente 20 dispositivos com um alcance máximo de 5 m do Conbee I com o FW / Phoscon / deCONZ mais recente.

Experimente Deconz versão 2.05.69. Bastante estável para mim com Ikea, Innr e Xiaomi

Tenho um problema semelhante e tíquete aberto https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Diria que quando o downgrade para a versão 2.05.67 fez minha rede muito mais estável do que nunca. Tinha algumas lâmpadas que não respondiam, mas as mesmas duas e podiam viver com elas. Ontem tudo funcionou conforme o esperado.

Parece ser um problema com uma mistura de todas as peças possíveis e, claro, torna-o difícil de encontrar. No entanto, a versão deconz parece ser uma parte importante de ter uma solução estável ou não.

Eu também tive problemas com dispositivos Ikea (lâmpadas e, recentemente, também o controle remoto Symfonisk) ficando indisponíveis e exigindo emparelhamento novamente com deCONZ. Eu carrego essas questões por 6 meses ou mais, eu acredito. Não há muito a acrescentar mais do que acho que acontece com mais frequência ultimamente. Não tenho lâmpadas GU10, apenas várias E27 e E14 (e vários controles remotos). Parece que certos dispositivos são mais propensos a cair (talvez dependendo de como eles se encaixam ou algo semelhante). Tenho aproximadamente 20 dispositivos com um alcance máximo de 5 m do Conbee I com o FW / Phoscon / deCONZ mais recente.

Experimente Deconz versão 2.05.69. Bastante estável para mim com Ikea, Innr e Xiaomi

Vou tentar isso, assim como o

Algumas semanas atrás, criei grupos para minhas luzes no Phoscon e comecei a fazer referência a esses grupos no HASS.

Então eu finalmente consegui meu hardware de farejamento e também hackeei um pouco o Wireshark para mostrar os nomes de todos os endereços ieee802.15.4 (o que torna muito mais fácil ler o que está acontecendo).

De qualquer forma, meu conhecimento sobre zigbee não é muito forte, então possivelmente estou fazendo perguntas estúpidas. No entanto, estive examinando alguns registros de farejamento e espero que possamos ver algo que explica o comportamento fragmentado das lâmpadas ikea.

Veja o log abaixo. Isso parece um comportamento 'normal'? Ambas as luzes envolvidas são luzes Ikea. Primeiro DeConz envia um pedido para a 'Garagem', encaminhando através do 'Zolder'. Em seguida, 'Zolder' tenta transmiti-lo para a 'Garagem', mas parece falhar (por quê?) E é repetido 20 vezes em uma sucessão muito rápida (a maioria dentro de 3 ms). Finalmente 'Zolder' desiste e envia uma falha de link de volta para DeConz.

Deve ser tão agressivo na tentativa de transmissão?

Além disso: percebi que DeConz fica feliz em enviar solicitações ao Garage por meio do Zolder, embora o link esteja claramente falhando. DeConz faz isso mesmo quando Garage não está mais no relatório de status do link de Zolder. Além disso, se às vezes o Garage estiver no relatório de status do link de Zolder, terá um custo de 7 para entrada e saída. Na verdade, a rota da garagem para DeConz não é por Zolder ...
Por que o DeConz continua roteando pelo Zolder mesmo depois de uma mensagem de falha de link?

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

Ok, passei algum tempo lendo a documentação do ZigBee dos silabs (os IKEAs são baseados em chips silabs).
Aparentemente, o comportamento da nova tentativa é exatamente como descrito nos documentos.

Isso deixa a questão de por que DeConz insiste em usar essa rota. O custo do link é alto, há uma resposta de Link Failure e ainda assim essa rota é utilizada. Por quê..?
(e melhores rotas estão disponíveis ...)

Insights muito úteis @djwlindenaar, embora eu não seja capaz de ajudá-lo neste nível. Isso confirma um pouco minhas suspeitas. Eu tinha uma rede de trabalho decente (com downgrade de software) até que tive um corte de energia acidental e toda a casa foi apagada.

Depois disso, estou de volta e acho que tenho caminhos ruins novamente.

Outra coisa. Como o deconz define os estados mesmo se o dispositivo real não responder? Parece que uma lâmpada está acesa nas interfaces, mas física está desligada (ainda ligada). Às vezes funciona para ligá-lo novamente (via software), às vezes funciona com o ciclo de energia, mas frequentemente não responde mesmo após um ciclo de energia. A mesma lâmpada pode responder de repente novamente após algum tempo

Um comportamento mais interessante (eu mostro as mesmas luzes, mas isso está acontecendo em outros lugares da minha rede também)

• DeConz envia many-to-one route Route Request pacotes. O resultado é que qualquer dispositivo fará primeiro uma descoberta de rota. Isso deve alimentar o concentrador (coordenador) com informações sobre como chegar a esse dispositivo. Parece que DeConz ignora esta informação para seu roteamento ...

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

Esse último pacote contém informações sobre como chegar à Oficina:

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

Mas o próximo pedido para o Garage é enviado novamente através do 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

Eu não ficaria surpreso que esse comportamento tenha algo a ver com o comportamento da luz IKEA escamosa.

@manup , você poderia comentar sobre isso? A sua afirmação de que o Source Routing ajudaria, faz muito sentido.
Como alternativa, espero que usar o formulário de informações do Registro de Rota para atualizar a tabela de roteamento de DeConz já seja uma grande melhoria ...
Ou precisamos descobrir por que DeConz deseja continuar usando uma rota que relata problemas de link / tem altos custos de roteamento em comparação com uma alternativa.

Outra observação ... Os dois dispositivos de retransmissão no pacote acima são ambos plugues Xiaomi. Eles nunca são consultados quanto à qualidade do link. Por quê?
Será que DeConz está usando as informações na resposta de qualidade do link para construir sua tabela de rotas e, portanto, ignora os roteadores bastante válidos? Com boa qualidade de link para algumas das minhas infelizes luzes IKEA ...

Só vejo esse comportamento para dispositivos ikea ou um comportamento geral para ignorar a rota ideal? Acho que você tem um número decente de dispositivos ikea?

Não tenho certeza, preciso verificar isso. Boa pergunta.

Tenho um grande número de lâmpadas Ikea, sim.

Na minha opinião, isso explica grande parte do comportamento que vimos com as luzes IKEA inacessíveis. Embora seja apenas uma hipótese, por enquanto, a ser verificada.

Olhando para várias outras rotas e vejo o mesmo comportamento.

Vejo apenas que os dispositivos da Xiaomi não são questionados quanto à qualidade do link de todas as outras marcas. Eu acho que isso é algum tipo de lista negra ..?

Exemplo de outro comportamento de roteamento:

De DeConz, sempre:
DeConz --> WC Lamp --> Badkamer Ledstrip

A rota de retorno muda frequentemente após uma solicitação de rota muitos para um. Observe que, do ponto de vista geográfico, tudo isso faz sentido ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Para a luz da garagem, vejo de DeConz:
DeConz --> Zolder Noord Lamp --> Garage (rota muito instável ..!)

Rota de retorno que vejo:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Agora, quando eu olho para a tabela nos relatórios de status do link, a rota acima das rotas da garagem para DeConz faz sentido:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz custo total: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz custo total: 4

de DeConz para Garage não:
DeConz --> Zolder Noord Lamp --> Garage custo total: 12 (com base no custo de entrada de DeConz para a lâmpada Zolder Noord)

@manup , você poderia elaborar o algoritmo de custo da rota em uso? Por que isso faz sentido?

Mais algumas análises hoje ...
Em minhas postagens anteriores, você viu que a luz da minha garagem passa pela minha luz Zolder. Ambas as lâmpadas IKEA. O link de rádio de Zolder para Garage está no limite de seu alcance, por isso falha com frequência.

Hoje, embora a luz da garagem responda a comandos de grupo, ela não responde a comandos unicast. Na verdade, às vezes sim e às vezes não. Este é um comportamento que deve ser familiar para aqueles que leram / contribuíram com este tópico.

Posso encontrar isso nos registros de farejamento. Às vezes, a luz Zolder é capaz de se comunicar com a garagem e às vezes não. Sempre que o Zolder light não consegue se comunicar com o Garage, ele informa o seguinte:

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]

Este pacote deve dizer ao DeConz para começar a encontrar outra rota para chegar à Oficina, mas isso não acontece. O próximo pacote enviado para o Garage é novamente roteado pelo Zolder. Para mim, esse é um bug que deve ser resolvido.
Este próximo pacote para Garagem é recebido pela luz Zolder, mas essa luz nem tenta enviá-lo para a Garagem. Talvez seja um comportamento do firmware IKEA que não é bom, mas a causa raiz do problema é a recusa da DeConz em encontrar um caminho alternativo.
Eu acho que se uma rota não estiver disponível por um período prolongado de tempo, talvez a luz da garagem esteja sem ACKs em um nível superior ao do protocolo 802.15.4 e isso pode fazer com que o firmware se desconecte ou até mesmo trave. E eu concordo que não deveria, mas a causa raiz do problema é DeConz se recusar a encontrar um novo caminho para a luz da garagem.

Hoje fiz um experimento para fazer com que DeConz encontrasse outra rota para a luz da garagem, então desconectei a fonte da luz Zolder e olhei para as toras de cheiro. Depois de algumas tentativas, DeConz percebe que Zolder se foi e vai em frente para encontrar uma rota alternativa para a garagem. Em seguida reconecto Zolder e depois de anunciar sua presença também para Zolder, uma nova rota é encontrada. DeConz (ainda) não volta a encaminhar o Garage através de Zolder.

O engraçado é que na nova situação, DeConz agora fala diretamente com o Garage light, sem roteadores no meio.
Zolder agora é alcançado através de uma rota através de 2 outros roteadores (embora obviamente fosse alcançável diretamente pelo DeConz), então me parece que alguma tabela (tabela vizinha?) Está cheia dentro do firmware de roteamento DeConz.

Talvez isso esteja relacionado à sua recusa em criar uma nova rota em resposta a uma rota com falha ..?

@manup , eu agradeceria qualquer comentário seu sobre os posts acima. Ou, pelo menos, deixe-me saber como contribuir para uma solução (além de procurar a causa raiz).

Gostaria de ajudar a criar uma solução para esses problemas, pois eles me incomodam. Se você der acesso ao código-fonte do firmware, posso contribuir diretamente (mesmo que não seja de código aberto). Não me importo de ajudar a Dresden Elektronik dessa forma :)

Excelente trabalho realizado! 💪🏼
Espero que possamos chamar a atenção dos desenvolvedores para consertar isso. Parece que você tem uma boa configuração e processo, portanto, uma correção poderia ser verificada de forma bastante “fácil”.
Eu entendo agora o comportamento que vi e que chamo de “autocura” e por que algumas lâmpadas de repente estão funcionando.

Bom trabalho @djwlindenaar, espero que @manup possa dar uma olhada nisso.

@manup algum comentário?

Obrigado por este tópico e trabalho. Estou executando 20 firmware de atualização de lâmpada ikea e um ano de idade. Eu experimentei congelamentos de queda ou perda de lâmpada desde o início, mas não muito frequente. Piorou com atualizações posteriores de desconz. Eu verifiquei minha rede otimizada em ambiente compactado 2.4. A lâmpada continua caindo diariamente e tornando os botões ou sensores inúteis, pois eles ainda são roteados por meio dessas lâmpadas e, portanto, não enviam nenhum movimento de dados. Preciso desligar e ligar tornando os sensores disponíveis novamente, pois as lâmpadas começam a direcioná-los novamente. Espero que isso chame mais atenção. Isso é frustante.

Outra observação ... Os dois dispositivos de retransmissão no pacote acima são ambos plugues Xiaomi. Eles nunca são consultados quanto à qualidade do link. Por quê?
Será que DeConz está usando as informações na resposta de qualidade do link para construir sua tabela de rotas e, portanto, ignora os roteadores bastante válidos? Com boa qualidade de link para algumas das minhas infelizes luzes IKEA ...

A consulta da tabela de vizinhos (também conhecida como ZDP Mgmt_Lqi_req) foi desabilitada para dispositivos Xiaomi, pois eles não responderam a essas consultas após um tempo e suspeitei que um erro no firmware poderia acionar algum estado inválido ou pior.

Assim, o principal driver para limitar certas solicitações é evitar erros no firmware do dispositivo final e imitar de perto o comportamento do gateway do fornecedor relacionado, alguns dos resultados da investigação podem ser encontrados em https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / End-device-Polling

Como uma observação lateral, as consultas às tabelas vizinhas são usadas apenas para construir a apresentação da malha visual e não afetam a operação da rede ou as tabelas de roteamento.

Então eu finalmente consegui meu hardware de farejamento e também hackeei um pouco o Wireshark para mostrar os nomes de todos os endereços ieee802.15.4 (o que torna muito mais fácil ler o que está acontecendo).

De qualquer forma, meu conhecimento sobre zigbee não é muito forte, então possivelmente estou fazendo perguntas estúpidas. No entanto, estive examinando alguns registros de farejamento e espero que possamos ver algo que explica o comportamento fragmentado das lâmpadas ikea.

Veja o log abaixo. Isso parece um comportamento 'normal'? Ambas as luzes envolvidas são luzes Ikea. Primeiro DeConz envia um pedido para a 'Garagem', encaminhando através do 'Zolder'. Em seguida, 'Zolder' tenta transmiti-lo para a 'Garagem', mas parece falhar (por quê?) E é repetido 20 vezes em uma sucessão muito rápida (a maioria dentro de 3 ms). Finalmente 'Zolder' desiste e envia uma falha de link de volta para DeConz.

Deve ser tão agressivo na tentativa de transmissão?

Além disso: percebi que DeConz fica feliz em enviar solicitações ao Garage por meio do Zolder, embora o link esteja claramente falhando. DeConz faz isso mesmo quando Garage não está mais no relatório de status do link de Zolder. Além disso, se às vezes o Garage estiver no relatório de status do link de Zolder, terá um custo de 7 para entrada e saída. Na verdade, a rota da garagem para DeConz não é por Zolder ...
Por que o DeConz continua roteando pelo Zolder mesmo depois de uma mensagem de falha de link?

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

Boa pegada! Aqui, eu suspeito que o firmware deCONZ deve lidar com esse erro e tentar encontrar uma nova rota. Vou verificar o firmware se este caso está funcionando e como. Posso imaginar que a rota foi realmente descartada, mas se uma nova mensagem for recebida pela mesma rota. Por exemplo, devido a um relatório de atributo ZCL da luz, a entrada é mantida viva.

As rotas podem ser estabelecidas apenas recebendo qualquer comando de um quadro de entrada. Mas se o último salto não mantiver o salto anterior (o que geralmente acontece), o caminho de volta pelo mesmo salto não funcionará. Suas descobertas podem refletir exatamente esse caso.

Obrigado.

Nesse caso, nunca há uma mensagem da luz da Garagem recebida por Zolder. Portanto, eu não esperaria que DeConz continuasse usando a rota. Veja minhas outras postagens ...

Código de status: Falha de link fora da árvore (0x02)

Parece que temos um vencedor. Verifiquei a origem da pilha Zigbee (R21, ConBee II) e esse código de status foi completamente ignorado. : -O Preciso verificar a pilha do AVR Zigbee também, provavelmente o mesmo problema aí.

Como correção, gostaria de lidar com esse código da mesma forma que o status "Nenhuma rota disponível" é tratado, que é apenas para liberar a entrada de rota e deixar a pilha descobrir uma nova.

Você também tem um pacote completo do comando que foi enviado anteriormente do coordenador para a luz IKEA? Seria interessante se o bit de descoberta de rota foi definido.

Aqui está a seção da especificação Zigbee sobre o que deve acontecer neste caso particular:

Ao receber um quadro de comando de status de rede por um roteador que é o destino pretendido do comando, onde o campo de código de status da carga útil do quadro de comando tem um valor de 0x01 ou 0x02 indicando uma falha de link, a camada NWK removerá a entrada da tabela de roteamento correspondente ao valor do campo de endereço de destino da carga útil do quadro de comando, se houver, e informar a próxima camada superior da falha usando o NLME-NWK-STATUS.indication usando o mesmo código de status.

Portanto, a correção acima deve funcionar aqui para 0x02, 0x01 também não é tratada. Vou adicionar isso também.

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

Ótimo @manup! Você mencionou o Conbee II. Essa correção também funcionará para o Conbee I?

Sim, eu tenho apenas as fontes de pilha usadas por ConBee I e RaspBee. O mesmo problema aqui, vou preparar novas versões de firmware para teste até terça-feira. Seria legal receber algum feedback se isso resolver pelo menos os problemas de roteamento da IKEA.

Observe que há também outros problemas que não serão corrigidos por isso, como as lâmpadas IKEA ficarem completamente silenciosas e nem mesmo ouvirem o elenco do grupo.

Fechado acidentalmente este problema ... Reaberto. Que bom que estamos progredindo nisso.

Eu acho que @djwlindenaar é quem pode dar algum feedback depois que o novo firmware estiver disponível, porque o hardware de farejamento é necessário para isso?

Você também tem um pacote completo do comando que foi enviado anteriormente do coordenador para a luz IKEA? Seria interessante se o bit de descoberta de rota foi definido.

Não tenho certeza se entendi sua pergunta. Que pacote você está procurando? E para qual luz (Garagem ou Zolder)?

Sim, eu tenho apenas as fontes de pilha usadas por ConBee I e RaspBee. O mesmo problema aqui, vou preparar novas versões de firmware para teste até terça-feira. Seria legal receber algum feedback se isso resolver pelo menos os problemas de roteamento da IKEA.

Observe que há também outros problemas que não serão corrigidos por isso, como as lâmpadas IKEA ficarem completamente silenciosas e nem mesmo ouvirem o elenco do grupo.

Vou testar com certeza. Embora possa levar algum tempo para se chegar a uma conclusão, porque às vezes não há problema por muito tempo ...

Eu estava pensando que talvez haja algo desencadeando esse comportamento de ficar completamente silencioso. Já vi isso acontecer na semana passada, mas ainda não tive tempo de examinar os registros do farejador.

Estou no Raspbee aliás.

Sim, eu tenho apenas as fontes de pilha usadas por ConBee I e RaspBee. O mesmo problema aqui, vou preparar novas versões de firmware para teste até terça-feira. Seria legal receber algum feedback se isso resolver pelo menos os problemas de roteamento da IKEA.

Avise-nos, tenho muito esse problema e poderia testar, embora não esteja fazendo nenhuma cheirada.

Observe que há também outros problemas que não serão corrigidos por isso, como as lâmpadas IKEA ficarem completamente silenciosas e nem mesmo ouvirem o elenco do grupo.

Você se refere ao problema de que o software (deconz) informa e define um estado, mas a lâmpada em si não responde ou altera o estado? Talvez o problema não seja a mesma gravidade se resolvermos o problema de roteamento.

Obrigado por olhar para isso, muito apreciado!

Sim, eu tenho apenas as fontes de pilha usadas por ConBee I e RaspBee. O mesmo problema aqui, vou preparar novas versões de firmware para teste até terça-feira. Seria legal receber algum feedback se isso resolver pelo menos os problemas de roteamento da IKEA.

Observe que há também outros problemas que não serão corrigidos por isso, como as lâmpadas IKEA ficarem completamente silenciosas e nem mesmo ouvirem o elenco do grupo.

Obrigado manup! Vou atualizar para o novo fw assim que estiver disponível e fornecer atualizações.

Esse problema também pode estar relacionado ao problema de controle das persianas Ikea Fyrtur?

Outro que me parece estranho. @manup , isso também pode ser um problema?

Eu vejo muitas dessas sequências. Comecei a investigar isso, porque esta é a última comunicação do houtlamp antes de parar de responder. DeConz configura 2 itens de relatório de atributo e quase ao mesmo tempo solicita associações de grupo. Nos logs de DeConz, isso se parece com a figura abaixo.

Gostaria de saber se existe um bug na seleção do número de sequência ou talvez seja permitido (não sei) e esse comportamento está acionando um bug no firmware do Tradfri. Há uma solicitação com o número 215 e duas solicitações com o número 216. Será que temos algum tipo de condição de corrida em que o tratamento das solicitações pelo firmware tradfri está causando vazamento de memória ou travamento devido às duas solicitações com o mesmo número quase ao mesmo tempo? Shoud DeConz tem duas solicitações com o mesmo número de sequência?

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 ar, isso parece: (parece que não estou vendo todos os pacotes pelo ar, o que é estranho, pois o farejador está bem ao lado do raspbee. Talvez eles sejam enviados tão rápido que se perdem em um estouro de buffer ou algo assim o farejador)

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

Na verdade, os números de sequência não devem ser iguais neste curto espaço de tempo, vou verificar o código, parece que falta um incremento.

Aqui está o primeiro firmware de teste para ConBee II

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

Agora, a portabilidade de volta para o firmware ConBee I / RaspBee estará online em breve.

E aqui está a versão de teste para ConBee I e RaspBee com a correção de erro de rota.
Espero que traga algumas melhorias para descobrir uma nova rota quando o erro acontecer.

Para teste, acho que seria bom se ele apenas rodasse por alguns dias / semanas e veremos se as luzes ainda param de responder aos unicasts. Neste caso, tente se as luzes ainda reagem aos comandos do grupo ou se silenciam completamente.

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

Para teste, acho que seria bom se ele apenas rodasse por alguns dias / semanas e veremos se as luzes ainda param de responder aos unicasts. Neste caso, tente se as luzes ainda reagem aos comandos do grupo ou se silenciam completamente.

E quando ele reage aos comandos do grupo, espere alguns dias para verificar se ele continua reagindo aos comandos do grupo. No meu caso, quando as luzes estão reagindo apenas aos comandos do grupo, mais cedo ou mais tarde elas ficam completamente silenciosas.

E quando ele reage aos comandos do grupo, espere alguns dias para verificar se ele continua reagindo aos comandos do grupo. No meu caso, quando as luzes estão reagindo apenas aos comandos do grupo, mais cedo ou mais tarde elas ficam completamente silenciosas.

Eu também já vi isso no passado, talvez eles façam isso, já que nenhum unicasts é recebido mais, o tempo dirá.

@manup Esse problema pode estar relacionado? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Talvez sim, pelo menos o estado alcançável também se tornaria falso quando a rota fosse interrompida. Mas isso também pode ser causado por outros motivos.

Reparei que existe um firmware mais recente para algumas lâmpadas ikea. O log de alterações indica melhorias na rede / conectividade e gerenciamento de falhas. Estou atualizando 20 lâmpadas ... fornecerei atualizações se for útil.

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

Pena que não contém datas de lançamento ...

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

Pena que não contém datas de lançamento ...

Parece que foi lançado porque consegui baixar o firmwas 2.3.007 descrito nas notas de lançamento.

Deve ter sido por volta de janeiro https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

não um programador dela. Acho que não devo instalar o r21 no conbee 2 e esperar? Este é um firmware beta?

Um pouco fora do tópico: também novo firmware para o dimmer Trådfri, atualizando-o para ZB3. Com referência cruzada # 2485, teremos o mesmo problema para o dimmer ... Espero que o sensor de movimento do modelo antigo seja o próximo ...

E aqui está a versão de teste para ConBee I e RaspBee com a correção de erro de rota.
Espero que traga algumas melhorias para descobrir uma nova rota quando o erro acontecer.

Para teste, acho que seria bom se ele apenas rodasse por alguns dias / semanas e veremos se as luzes ainda param de responder aos unicasts. Neste caso, tente se as luzes ainda reagem aos comandos do grupo ou se silenciam completamente.

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

Obrigado, @manup , acabei de instalar. Vamos ver o que isso trará.

Embora eu espere que isso traga alguma melhoria, como você se sente sobre o firmware DeConz ignorando as rotas gravadas (devido ao roteamento mane-to-one)? Em geral, tenho visto que as rotas gravadas são muito mais lógicas do que as usadas pelo firmware DeConz.
Embora eu possa imaginar que habilitar o roteamento de origem seja um grande trabalho, o firmware DeConz poderia (deveria?) Ainda usar as informações do pacote de registro de rota para atualizar o primeiro salto para um dispositivo. Talvez apenas verifique se o último salto para o coordenador corresponde ao que está armazenado na tabela de roteamento e, caso contrário, invalide a entrada na tabela de roteamento. Não tenho certeza se está OK substituir a entrada com o último salto da rota gravada, uma vez que os dispositivos ao longo do caminho provavelmente ignoram as informações, mas pelo menos poderia iniciar uma nova descoberta de rota para aquele nó pelo firmware DeConz.

O que você pensa sobre isso?

Eu instalei o firmware no meu raspbee, (eu tenho 73 nós, principalmente ikea), relatarei as descobertas.

Na verdade, os números de sequência não devem ser iguais neste curto espaço de tempo, vou verificar o código, parece que falta um incremento.

@manup , talvez para ajudá-lo a identificar o problema, vi esse problema novamente hoje. Parece estar relacionado a 2 ações de configuração de relatórios muito próximas. A segunda seq: 183, neste caso, é diferente da que relatei antes.

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

O problema do número de sequência deve ser corrigido no 2.05.74, que está sendo construído agora e estará disponível em algumas horas.

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

E aqui está a versão de teste para ConBee I e RaspBee com a correção de erro de rota.
Espero que traga algumas melhorias para descobrir uma nova rota quando o erro acontecer.
Para teste, acho que seria bom se ele apenas rodasse por alguns dias / semanas e veremos se as luzes ainda param de responder aos unicasts. Neste caso, tente se as luzes ainda reagem aos comandos do grupo ou se silenciam completamente.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Obrigado, @manup , acabei de instalar. Vamos ver o que isso trará.

Embora eu espere que isso traga alguma melhoria, como você se sente sobre o firmware DeConz ignorando as rotas gravadas (devido ao roteamento mane-to-one)? Em geral, tenho visto que as rotas gravadas são muito mais lógicas do que as usadas pelo firmware DeConz.
Embora eu possa imaginar que habilitar o roteamento de origem seja um grande trabalho, o firmware DeConz poderia (deveria?) Ainda usar as informações do pacote de registro de rota para atualizar o primeiro salto para um dispositivo. Talvez apenas verifique se o último salto para o coordenador corresponde ao que está armazenado na tabela de roteamento e, caso contrário, invalide a entrada na tabela de roteamento. Não tenho certeza se está OK substituir a entrada com o último salto da rota gravada, uma vez que os dispositivos ao longo do caminho provavelmente ignoram as informações, mas pelo menos poderia iniciar uma nova descoberta de rota para aquele nó pelo firmware DeConz.

O que você pensa sobre isso?

Hmm estranho o firmware já deveria usar esses Registros de Rota para estabelecer novas Rotas, preciso checar o código aqui, mas se minha memória me atende direito isso foi habilitado há um tempo.

O que você pensa sobre isso?

Hmm estranho o firmware já deveria usar esses Registros de Rota para estabelecer novas Rotas, preciso checar o código aqui, mas se minha memória me atende direito isso foi habilitado há um tempo.

Bem, eu tenho essas coisas acontecendo com Zolder e Garage (de uma série de posts anteriores) e tenho este comportamento:

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

O registro da rota mostrou:

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

A próxima comunicação de DeConz para Garage:

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

Portanto, claramente não está assumindo o controle das gravações de rota.

O que percebi neste momento foi que, assim que desliguei Zolder , DeConz imediatamente foi capaz de encontrar uma nova rota. Então, talvez algumas das tabelas relacionadas ao roteamento estejam cheias dentro do firmware DeConz. Isso poderia ser verdade? Qual o tamanho das tabelas de vizinho / roteamento no firmware? Uma tabela cheia pode estar bloqueando a adoção de novas gravações de rota?

Sucesso! Posso confirmar que o comportamento agora é que, após uma falha de link fora da árvore, a descoberta da rota realmente começa.

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

O problema do número de sequência deve ser corrigido no 2.05.74, que está sendo construído agora e estará disponível em algumas horas.

33d8a8b

"swversion": "2.5.74",

: smile: Obrigado @manup ótimo tempo de resposta: 1st_place_medal:

Aguarde a atualização para 2.05.74 ou use http://phoscon.de/app para mostrar o aplicativo Phoscon. Acabamos de ver que uma página offline do gateway é mostrada em algumas páginas onde não deveria, reconstruindo agora cerca de 2 horas.

Na verdade, os números de sequência não devem ser iguais neste curto espaço de tempo, vou verificar o código, parece que falta um incremento.

Aqui está o primeiro firmware de teste para ConBee II

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

Agora, a portabilidade de volta para o firmware ConBee I / RaspBee estará online em breve.

Este FW não funciona para mim. Mostra todos os meus dispositivos como unidos, mas nenhuma malha é construída. Nem as conexões são mostradas na GUI, nem qualquer mudança do Phoscon funcionou (2.05.74). Atualizou o Conbee II de volta para 264A0700 e tudo funciona como esperado ...

Hmm estranho quanto tempo demorou?
Estou executando este firmware em várias configurações agora sem problemas até agora.

Hmm estranho quanto tempo demorou?
Estou executando este firmware em várias configurações agora sem problemas até agora.

Alguns minutos. Já vi algumas atividades em alguns dispositivos (pontos azuis), mas não há construção de links. E a mudança não funcionou de todo. Devo testar por mais tempo?

Pode demorar um pouco até que a malha seja construída, mas você deve ver linhas depois de 5 a 10 minutos.

Este FW não funciona para mim.

O mesmo aqui, Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Pequena rede de teste com repetidor Trådri, plugue Trådfri, XBee, dimmer Trådfri, 2 sensores de movimento Trådfri (antigos e novos) e interruptor liga / desliga Trådri. O gateway não parece enviar nem receber tráfego de nenhum dispositivo. Vendo desconexões USB no syslog. Tudo está ótimo de novo, depois de voltar para 4A.
log.gz

Acendeu novamente para testar:

• sem linhas na GUI (deixe funcionar por 15 minutos)
• Conexão USB parece estável
• Os interruptores UBISYS C4 e D1 ainda funcionam
• Botões Tradfri não

@ebaauw o log mostra que o coordenador vê apenas dois vizinhos com esta versão.

Talvez seja o tamanho da rede. Atualmente, tenho apenas 40 dispositivos ligados aqui. Esta versão do firmware tem duas outras mudanças que podem ser a causa, tamanho do buffer de mensagem aumentado (um pouco mais do que eu posso dizer, irá reduzir isso novamente) e uma configuração de potência TX ligeiramente mais baixa.

Vou preparar outra versão com essas configurações removidas para ver se funciona melhor.

Você usa um cabo de extensão USB ou o ConBee II está conectado diretamente?

Para mim, funciona bem no Raspbee ...

No RaspBee e no ConBee 1, apenas a correção de rota está incluída na nova versão (firmware diferente).

o log mostra que o coordenador vê apenas dois vizinhos com esta versão.

Sim, dois dos dispositivos finais foram mostrados como vizinhos na GUI. Meio estranho, porque eles se mostraram conectados a outro roteador após fazer o downgrade do firmware do ConBee II.

Você usa um cabo de extensão USB ou o ConBee II está conectado diretamente?

Ele está conectado diretamente desde que eu o recebi. Para uma porta USB-2 no Pi, com o XBee conectado à outra porta USB-2; nada em USB-3. A conexão está estável, exceto quando configurei o ConBee II como roteador (consulte # 2463).

No RaspBee e no ConBee 1, apenas a correção de rota está incluída na nova versão (firmware diferente).

Ainda não tentei isso. Terá que esperar até mais tarde ...

Vejo muitos pacotes de relatórios de configuração. Depois de um pouco de pesquisa, parece que eles são enviados periodicamente a cada meia hora. Qual é o motivo pelo qual essas solicitações de relatório de configuração são repetidas periodicamente?
@ebaauw , lembro bem que você fez muitas dessas investigações sobre o comportamento do coordenador da IKEA? Ele também faz isso?

Notei em de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

Encontrei outro indício sobre o comportamento de roteamento de DeConz ignorando os registros de rota muitos-para-um. Isso está fazendo com que alguns roteadores tenham que descobrir o roteamento da maneira 'antiquada'.
(note que tenho alguma interferência devellish no pacote 117130: wink :)

A rota de badkamer ledstrip , segundo DeConz, começa com o On/Off light 36 que obviamente não sabe como chegar lá. Então ele começa uma descoberta de rota e finalmente descobre que pode (mal, eu acho) alcançar o próprio ledstrip . O caminho de retorno é por Gang 1

Parece que On/Off light 36 esquece cerca de Badkamer ledstrip toda vez que uma solicitação de rota muitos-para-um é processada ...

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

próxima comunicação:

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

Outra tentativa no firmware ConBee II:

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

Esta versão possui as configurações de potência TX de 0x264a0700. Os buffers ainda são grandes (mas de acordo com o mapa eles deveriam caber perfeitamente na RAM) para verificar apenas uma coisa por vez.

Recebo este erro sempre que tento atualizar para o firmware mais recente. Alguma dica por quê?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reinicializar o dispositivo / dev / ttyACM1 (ConBee II)
versão de firmware deCONZ 26490700
Bootloader R21B18
Vers: 2.05
construção: 22 de março de 2019
piscando 161378 bytes: | ================================ |
verificar: .
A atualização do Flash falhou, CRC inválido. Por favor, tente novamente.
rich710 @ RichHassPc01 : ~ $

Você verificou a soma MD5 do arquivo baixado? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Sim, eu verifiquei e baixei várias vezes, até tentei reverter para o firmware antigo, e deu certo, até agora. Agora estou preso com este erro, reiniciei meu NUC várias vezes, mas ainda estou preso quando o pisca-pisca tenta reiniciar meu ConbeeII.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] senha para rich710:
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reinicializar o dispositivo / dev / ttyACM1 (ConBee II)

2139: Erro: falha na redefinição do uart, verifique a nova tentativa

Percebi que você usa ttyACM1, quando usa

GCFFlasher -l

Ele mostrará o número de série.
Você pode usá-lo para fornecer um nome de dispositivo mais estável no comando.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(substitua pelo número de série do seu dispositivo)

Desculpe, não funcionou, talvez eu deva movê-lo para minha máquina Windows e tentar
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Caminho | Vendedor | Produto | Serial | Tipo
----------------- + -------- + --------- + ------------ + -------
/ dev / ttyACM1 | 0x1CF1 | 0x0030 | DE1964163 | ConBee II
/ dev / ttyUSB0 | 0x0403 | 0x6001 | A1YV35M2 | FTDI genérico
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresden elektronik ingenieurtechnik gmbh
Reinicializar dispositivo (ConBee II)

2139: Erro: falha na redefinição do uart, verifique a nova tentativa
rich710 @ RichHassPc01 : ~ $

Ou isso ou como alternativa, você pode tentar seguir:

• Desconecte o ConBee II
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Conecte o ConBee II novamente

Os parâmetros -t permitem que o GCFFlasher tente por um minuto processar a atualização.

Funcionou para atualizar o firmware no windows, e quando liguei no meu NUC com o ubuntu novamente ele se conectou. MAS, depois de uma hora, ele acabou de se conectar a 4 nodos meus ..: S

Outra tentativa no firmware ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

Não há mais desconexões USB, mas deCONZ parece detectar novamente o ConBee II com bastante frequência. Ainda sem tráfego.
log.gz

EDITAR Para te agradar, desliguei o XBee e usei um cabo de extensão USB de 10cm para ligar o ConBee II: sem alterações.

Outra tentativa no firmware ConBee II:

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

Esta versão possui as configurações de potência TX de 0x264a0700. Os buffers ainda são grandes (mas de acordo com o mapa eles deveriam caber perfeitamente na RAM) para verificar apenas uma coisa por vez.

Teste sua nova versão, mas após 10 minutos ainda não há link mostrado ... Com o FW estável, todos os links (roteadores) bons na rede são exibidos após cerca de 2 minutos. O botão de pressão IKEA funciona imediatamente, enquanto com o firmware de teste não funciona de todo.

Hmm assustador, obrigado por testar isso. Em seguida, tentarei diminuir os tamanhos do buffer, conforme mencionado antes.
Ainda me pergunto por que está funcionando em minha configuração. Pela captura de tela acima, só posso dizer que tenho mais dispositivos finais do que roteadores.

@manup teve os mesmos problemas após atualizar o firmware, mas pressionar reboot device em deconz / restarting deconz fez os links voltarem.

E aqui está a versão de teste para ConBee I e RaspBee com a correção de erro de rota.

Parece funcionar bem no meu sistema de teste Pi 3B +. Vou esperar até este fim de semana antes de atualizar minha rede de produção.

@ebaauw , lembro bem que você fez muitas dessas investigações sobre o comportamento do coordenador da IKEA? Ele também faz isso?

Eu adicionei suporte para a maioria dos dispositivos Trådfri, mas não consegui detectar nenhum tráfego ZigBee de / para o hub Trådfri. Ele usa apenas emparelhamento de touchlink, e ainda não tentei capturar isso para recuperar a chave de rede. Isto é, supondo que seja possível.

Tenho executado o novo FW no conbee 1 stick em minha configuração de ~ 40 nós desde o lançamento do novo firmware e tem funcionado muito bem sem problemas! (Na imagem, os nós não conectados estão sem bateria ou sem energia)

Obrigado a todos os envolvidos que resolveram os problemas e atualizaram o código. É MUITO apreciado! <3

Não está funcionando para mim. Quase nenhuma conexão na rede. Esperou cerca de 20 minutos após o reinício.

Raspberry Pi 3 Modelo B Rev 1.2
Conbee II
versão 2.05.74
versão 26530700

77 nós

3 Conexão com
1 interruptor liga / desliga TRÅDFRI
1 multissensor Xiaomi
1 interruptor dimmer Philips
Consigo acionar eventos com o interruptor do dimmer da Philips.
Estes que possuem conexões estão bem próximos do stick de Conbee. O stick encontra-se na garagem. Tenho algumas lâmpadas na garagem que não têm ligações.

Sem conexão com
Muitas lâmpadas ikea, tanto E27 quanto GU10
Muitos sensores múltiplos da Xiaomi
Muito controle remoto Ikea TRÅDFRI
E outros nós.

Histórico
27 de fevereiro 09:29:06 raspberrypi systemd [1]: Iniciado deCONZ: ZigBee gateway - GUI / REST API.
27 de fevereiro 09:29:06 raspberrypi deCONZ [7204]: aviso libEGL: DRI2: falha ao autenticar
27 de fevereiro 09:29:06 raspberrypi deCONZ [7204]: aviso libpng: iCCP: perfil sRGB incorreto conhecido

Ao fazer o downgrade para 264A0700, ele começa a construir a malha diretamente.

@ebaauw , lembro bem que você fez muitas dessas investigações sobre o comportamento do coordenador da IKEA? Ele também faz isso?

Eu adicionei suporte para a maioria dos dispositivos Trådfri, mas não consegui detectar nenhum tráfego ZigBee de / para o hub Trådfri. Ele usa apenas emparelhamento de touchlink, e ainda não tentei capturar isso para recuperar a chave de rede. Isto é, supondo que seja possível.

Certo, desculpe. Deveria ter verificado a culpa do git. O código que menciona o comportamento do gateway IKEA foi apresentado em 48d2c39a267b5c6d025577eed7530be27932aa2c por @manup ...

@manup , você realmente identificou que o gateway IKEA reconfigura o atributo relatando isso com frequência? Por que a reconfiguração seria necessária; a luz precisa ser lembrada regularmente?

Conbee I atualizado para beta FW e deCONZ .74

Mesh constrói imediatamente e parece muito bom!

Muito obrigado a @manup também, é claro, por corrigi-los ...

Conbee I e .74 também. Ikea FW atualizado para 2.3.007 (alguns outros 2.x).
Melhoria importante! Ainda não há desistências!

Um grande obrigado a todos contribuindo, desenvolvendo, depurando, testando neste tópico e além.

Algo que descobri no processo:
O grupo normal ON-OFF funciona - rápido, mas depois de chamar uma cena (após fade no tempo) e desligá-la novamente (<10seg), as luzes se apagam apenas na GUI (independentemente da interface antiga ou nova). Então, algumas delas voltam a acender (no gui) no grupo enquanto TODAS as lâmpadas físicas permanecem acesas. Depois de pressionar uma segunda ou terceira vez em OFF, às vezes escurecem.

Não é incomum restaurar / reconstruir cenas após uma atualização de firmware
Mas, independentemente de eu construir uma nova cena ou tentar consertar uma mais antiga, o comportamento permanece o mesmo. Ligar-desligar normal não é afetado.

Descobri que funciona normalmente quando espero um pouco mais. Digamos 15-20 segundos. Em seguida, as luzes se apagam como de costume. Presumo que o deconz fique confuso como acontece quando você apaga uma luz até que apareça.

Parece que temos um aumento de atraso até que cada estado de luz seja reportado de volta e a recuperação da cena seja feita em deconz ou reportada com sucesso, então outras ações naquele grupo funcionam como desejado. Isso parece demorar um pouco mais agora. Dentro deste período - você não deve (passar;)) - desligar as luzes. Isso não é crítico.

Eu testei um pouco mais. Temos uma mudança de comportamento. Anteriormente quando um bri era alterado com uma determinada velocidade, ou uma cena tinha um tempo de transição maior, era possível interromper com um novo comando. Mesmo a ação anterior ainda foi executada, o próximo comando foi colocado na fila. Agora está perdido. Por exemplo, minhas luzes de piso são operadas por sensor de movimento. Antes que eles saiam, eu os escurece e espero por 10 segundos antes de desligá-los. Quando eu acionei o movimento e recuperei a cena enquanto eles estavam desaparecendo, o comando foi perdido. Antes disso, ele era colocado na fila e executado em seguida. Isso é devido a. 74 ou o novo firmware? obrigado

Meu Conbee II não construiu mesh na versão beta. A única coisa que posso pensar que pode ser diferente das configurações "normais" é definir o canal para 25. Voltar para 264a0700 consertou

@realwax , acho que você está encontrando um bug de firmware Trådfri, consulte # 2068. Você pode verificar isso facilmente emitindo um comando com um tempo de transição mais longo na GUI e, em seguida, emitindo um segundo comando.

Antes disso, ele era colocado na fila e executado em seguida.

Você atualizou o firmware leve? Tem certeza de que está usando a mesma luz? O plug-in da API REST não controla o tempo de transição depois de enviar um comando à luz.

@ebaauw Obrigado por me guiar na direção certa. Como a IKEA declarou incluir melhorias de rede e estabilidade em seu releaselog, eu atualizo meu TRÅDFRI Lampe E14 WS opal 400lm para o firmware 2.3.007 (mais recente). Achei que isso poderia amenizar alguns desses problemas. Eu me pergunto como a IKEA faz o truque em sua própria ponte, porque esse é um grande problema de usabilidade. Agora preciso buscar tempos de transição mais rápidos, conforme você declarou na outra edição. Sinto isso desde o primeiro dia, mas piorou. Agora isso não afeta apenas os fades de recall de cena, mas afeta qualquer mudança com uma transição mais longa e isso é novo ... O que posso fazer? Voltar para o fw mais antigo é quase impossível, porque é uma luta com o deconz. Obrigado Erik.

Eu me pergunto como a IKEA faz o truque em sua própria ponte, porque esse é um grande problema de usabilidade.

O hub Trådfri é muito menos ativo que o gateway deCONZ ou a ponte Hue. Os controladores Trådfri (interruptores, dimmers, mas também seus sensores de movimento) controlam as luzes diretamente. As luzes Trådfri enviam notificações push para o hub com mudanças de estado. O hub é necessário / usado apenas para seu aplicativo. Ele pode executar alguns alarmes, mas nenhuma regra para lidar com eventos de botão ou qualquer coisa complicada.

Não tenho certeza se o aplicativo Trådfri suporta a especificação de tempos de transição mais longos, mas os controladores que vi não. Você provavelmente não será capaz de enviar comandos dos controladores mais rápido do que o tempo de transição padrão das luzes. E se você fizer isso ocasionalmente, provavelmente acha que não pressionou totalmente o botão.

@ebaauw entendo. O que ainda me intriga é o fato de que posso ligar e desligar um grupo de E14 (fornecendo algum tipo de disco leve;)) em 1 segundo (liga-desliga-liga) funciona! Mas assim que eu aperto um botão de recall de cena em deconz, eu não consigo e o comportamento fica estranho. É aqui que eu duvido que seja culpa da IKEA. Por que posso ligar e desligar muito rapidamente, mas assim que me lembro de uma cena, fico preso por pelo menos 5 a 10 segundos?

Tempos medidos com precisão (20 tentativas):
grupo de 8 E14
grupo LIGADO -> grupo DESLIGADO - tempos de troca 1 segundo
chamar cena -> ligar -> DESLIGAR sem responder até 10-12 segundos!

Eu entendo que com um recall mais tráfego é gerado e cada lâmpada recebe mais mensagens, mas uma diferença de 10 segundos? Mesmo quando eu mudo bri e ct para um grupo inteiro, posso desligá-lo em um segundo, mas, novamente, uma chamada é como um congelamento. Acho que isso parece ser um problema de desconexão, não é?

Eu posso gravar em vídeo. ;) Talvez eu esteja com falta de conhecimento aqui, então peço desculpas por apresentar minha falta de entendimento, mas estou de alguma forma frustrado porque é uma luta ...

Acho que ainda estou um pouco confuso sobre as cenas. Como grupos, eles não existem como um objeto no ZigBee, são apenas um número sob o qual um dispositivo (luz) armazena um estado. Em uma chamada de cena, o número é transmitido e cada dispositivo restaura o estado de sua memória não volátil.

A parte difusa é que nem todos os dispositivos parecem armazenar seu estado corretamente ao armazenar a cena: a temperatura da cor é notória a esse respeito. Também vi coisas engraçadas armazenando a cena enquanto a luz ainda está em transição. Nesse caso, o recurso /scenes está fora de sincronia com o estado armazenado na luz, fazendo com que a API reflita o estado do recurso em vez do estado real da luz, que só será atualizado na próxima vez que a luz for pesquisado. Normalmente, o tempo de transição é especificado ao chamar a cena, mas parece que também está no estado armazenado.

Eu fiz um script da configuração da minha rede de produção (usando ph ), para que possa recriá-la facilmente. Tive muita dificuldade em fazer o roteiro da criação de cenas de uma forma previsível. Acabei configurando os estados de luz, dormindo por alguns segundos, esperando que os estados se acomodassem, armazenando a cena e, novamente, dormindo alguns segundos, esperando que o estado fosse armazenado.

Você pode tentar recriar sua cena, mas sem garantias ...

Eu poderia reproduzir o tópico fora de sincronia desde o primeiro dia. Estava acostumado a desconfigurar e a necessidade de reconfigurar a cena de vez em quando. Agora é realmente pior. Atualmente, eu precisaria terceirizar de deconz para iobroker e reconstruir todas as minhas cenas lá. Mas isso dá muito trabalho. Espero que isso seja corrigido. Posso criar um problema? As luzes não são mais confiáveis ​​ao usar cenas ... - Tento recriar também. Eu fiz uma cena de "teste" ontem além das já existentes, mas não mostrou nenhum outro comportamento.

Não tenho certeza se está relacionado, mas depois de atualizar meu Conbee I para o beta-firmware e deCONZ para .74 demorou um dia e agora deCONZ perdeu a conexão com o Conbee. Nunca experimentei isso nos anos anteriores ... Mas eu queria mencionar ... O log acaba de declarar novas tentativas de conexão com ele repetidamente ... Reiniciar deCONZ resolveu ... (usando o contêiner docker)

Eu apenas tentei recriar um grupo, todas as cenas ... No processo de criação tem muita coisa errada. Ao usar o Phoscon e a seleção de lâmpadas "ALL", os valores das cenas não são armazenados corretamente. Mesmo as luzes configuradas mostram o que você deseja, uma rechamada não. Você deve controlar cada luz por conta própria, mesmo quando usa as mesmas configurações. Particularmente, o antigo gui deve ser usado para corrigir erros de temperatura de cores de cores armazenadas incorretamente. Até que uma cena "funcione", você precisa repassar isso algumas vezes, talvez ligando e desligando as luzes durante o processo de configuração da cena para que seja armazenada corretamente. Não tenho muitos detalhes técnicos aqui, mas quero dar coragem a todos vocês no tópico para testar cenas, criação, armazenamento, recall e desligamento após um recall. Acho que isso é complicado com as lâmpadas IKEA e fica pior ... Pode ser com a IKEA, mas eu duvido, pois tudo o mais e o controle de grupo direto funcionam como um encanto com o deconz.

Vou agora fazer rollback / downgrade do firmware para 1.x e ver se funciona melhor. Vou relatar de volta.

ESTÁ BEM. De volta à prancheta. Ontem, 2 luzes IKEA tiraram licença, apenas para voltarem depois de um ciclo de alimentação. Não estou dizendo que os bugs corrigidos não eram bugs. Eles foram. Só não aqueles que estão causando o problema.

Eu estava examinando mais profundamente a coisa do relatório de atributos. Eu queria saber se a configuração repetitiva do relatório de atributo a cada 30 minutos (1800) está causando os bloqueios do firmware leve.
Eu percebi esse trecho de código que não parece lidar com rq.maxinterval == 0 explicitamente. Agora, como lidar adequadamente com este caso é um pouco difícil, uma vez que rq.maxinterval == 0 significa que a luz reportará apenas uma mudança, então não há um 'bom' tempo limite para esse caso ... Talvez a implementação atual esteja bem, embora Eu me pergunto se uma ideia melhor pode existir.

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

Não. Fonte de Tempo Transmitir Dev Receber Destino Desativar Informações de Resposta Padrão
208134 10h 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL: Atributos de relatório, 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: Resposta Padrão, 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.

Não. Fonte de Tempo Transmitir Dev Receber Destino Desativar Informações de Resposta Padrão
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL: Configure Reporting, Seq: 41
207949 10h 43m 8.481 Gang 1 Gang 1 DeConz DeConz False ZCL: Configure Reporting Response, Seq: 41
207951 10h 43m 8.485 Gang 1 Gang 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 Gang 1 Gang 1 DeConz DeConz APS: Ack, Dst Endpt: 1, Src Endpt: 1

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

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

Percebi esse trecho de código que não parece lidar com rq.maxinterval == 0 explicitamente. Agora, como lidar adequadamente com este caso é um pouco difícil, já que rq.maxinterval == 0 significa que a luz irá apenas reportar uma mudança, então não há um 'bom' tempo limite para esse caso ... Talvez a implementação atual esteja bem, embora Eu me pergunto se existe uma ideia melhor.

Sim, o plugin REST API verifica se o relatório de atributos está funcionando. Se não, ele tenta reconfigurá-lo e, acho que também volta a pesquisar o dispositivo.

Fiz alguns experimentos, incluindo pedir às luzes IKEA para relatar ONOFF e NÍVEL periodicamente, em vez de apenas quando uma alteração é feita. As luzes relatam seu status periodicamente, de modo que pode ser uma maneira aceitável de evitar o problema acima. Para ser verificado corretamente, é claro.

Acho que corremos com essa configuração por algum tempo. Ele foi alterado, junto com a pesquisa menos frequente das tabelas vizinhas e não mais pesquisando o estado, porque parte do firmware Trådfri travava (exigindo um ciclo de energia da luz). Duvido que a configuração do relatório tenha realmente contribuído para o travamento do firmware.

Há um bit no pacote ZCL que determina se ele deve ou não ser enviado Disable Default Response .

Não acho que enviar a resposta padrão causaria tanto dano, quando Disable Default Response bit está definido. Não enviar a resposta padrão quando o bit não estiver definido causará danos, pois o dispositivo que está aguardando a resposta pode concluir que o coordenador não está mais acessível e, eventualmente, sair da rede.

Há um bit no pacote ZCL que determina se ele deve ou não ser enviado Disable Default Response .

Não acho que enviar a resposta padrão causaria tanto dano, quando Disable Default Response bit está definido. Não enviar a resposta padrão quando o bit não estiver definido causará danos, pois o dispositivo que está aguardando a resposta pode concluir que o coordenador não está mais acessível e, eventualmente, sair da rede.

@ebaauw , de fato. Esse é exatamente o ponto. deCONZ falha em enviar Default Response em resposta a Configure Reporting Response . Acontece que as luzes IKEA estão solicitando Default Response por Configure Reporting Response .
Portanto, como você diz, esse pode ser o motivo, juntamente com os Configure Reporting Request cada meia hora, para que as luzes IKEA se apaguem.

Apenas um lembrete:
As lâmpadas Ikea (E27 e GU10 v1) ocasionalmente tornam-se inacessíveis e precisam de um ciclo de energia quando conectadas a uma ponte HUE, de modo que esse problema específico não é exclusivo do Conbee I / II
De 16 E27 e 12 GU10 em minha ponte HUE, eu diria que uma lâmpada 'trava' a cada 1-2 semanas, aproximadamente. Às vezes mais, às vezes mais rápido. Este problema melhorou com os últimos lançamentos de firmware HUE no último ano e meio.

@all Qual versão de firmware Tradfri você está usando?

Você está no 1.x ou 2.x? Com o 2.x, eles introduziram o zigbee 3.0. Eu atualizei para 2.xe o problema começou. Lâmpadas E14. Notei melhorias em relação à velocidade e conectividade da rede. Mas duas coisas me fizeram rolar para trás 20 lâmpadas suspirar O "soft on" não estava mais funcionando. Lâmpadas acesas sem fade in. As cenas não funcionavam como antes. Precisamente falando, depois de chamar uma cena, um tempo de espera antes de desligar a luz ou chamar o próximo szene foi necessário, caso contrário, o deconz ficou assíncrono e ressincronizou para ligar enquanto a lâmpada não fazia nada.

Agradeço a sua experiência compartilhada com as versões e desconsidere a 'perfeição' com a 2.x que parece não ter sido fornecida.

Existe uma recomendação? FW v.? Além do problema de conexão perdida e os problemas de conexão no próprio fw da Ikea, parece que o deconz pode lidar com 1.x melhor.

Obrigado!

Estou usando:

• Conbee 1 com firmware 0x26340500
• Deconz versão 2.05.73 (usando marthoc docker container no Debian)
• ~ 60 nós, principalmente IKEA Trådfri
• Conbee 1 (coordenador) NÃO está instalado centralmente na minha casa de 200 metros quadrados. O sistema depende muito de roaming e malha.
• O stick Conbee 1 é instalado em um cabo de extensão USB de 0,5 metros e montado na lateral da prateleira onde o computador reside para ter mais espaço livre para os sinais de RF.

Desde a atualização (no mesmo dia do lançamento) do firmware do Conbee 1 stick, o deconz tem funcionado perfeitamente! Sem problemas, nunca.

Atualizei minha rede de produção (RPi 3B +, stretch, RaspBee) para 2.05.74 e 0x26340500 ontem. Parece estável, exceto pelos problemas abaixo.

Não tenho certeza se relacionado, mas a rota para meu controlador de cortina lumi.curtain foi perdida esta manhã. Os relatórios do controlador ainda alcançariam o gateway. A rota não seria restaurada ao desligar e ligar o controlador. Eu tive que abrir a rede e desligar e ligar o controlador, antes que o coordenador pudesse alcançá-lo novamente.

Além disso, uma das válvulas do meu radiador Eurotronic Spirit estava inacessível pelo deCONZ depois de iniciar o deCONZ, embora ainda enviasse relatórios. Desligar e ligar o TRV trouxe de volta, como sempre.

Não tive a oportunidade de fazer nenhuma investigação aprofundada desta vez, mas ambos os dispositivos têm sido problemáticos desde o início, exibindo esses sintomas de vez em quando. O mesmo vale para a minha cortina IKEA Fyrtur. Vou continuar a monitorar a situação e relatar se encontrar mais problemas.

@tubalainen
Qual firmware você está usando em suas lâmpadas tradfri? Isso faz diferença até mesmo neste tópico em relação ao problema de conexão perdida, tanto quanto testei. Meus resultados são que as medidas tomadas aqui melhoraram a operação de lâmpadas tradfri operadas 1.x no Conbee 1. Mas uma rede de 20 e14 com tradfri fw 2.3.x é uma bagunça. Timings, cenas travadas, deconz get, luz começa a piscar (perdido?), .. como relatado acima. Acho que este é um ponto a ser discutido e mencionado para fazer uma recomendação clara do ikea fw para usar para uma boa experiência. Talvez já haja um artigo do git. Mas, por experiência própria, não atualize 😅

Então, do meu ponto de vista e horas de testes e flashes. Obrigado pelo aperfeiçoamento do ikea fws 1.x! É possível mitigar os problemas atuais quando o 2.x é operado? Caso contrário, não será possível atualizar para o zigbee 3 com o ikea atualmente. Parece que o comportamento mudou e operá-los em deconz deve ser adaptado. Isso provavelmente para @ebaauw julgar ou lidar com isso?

Felicidades
Tenha um bom domingo 😊

@realwax
Tentei atualizar o FW todas as minhas entidades para o FW mais recente. Aqui está minha lista de todos os nós (atualmente ativos).

Concordou em bagunçar todas as "partes móveis" ao mesmo tempo tentando descobrir a causa raiz dos problemas.

@tubalainen

Obrigado por sua lista.

Olhando especialmente para os roteadores (lâmpadas), vejo que você opera 2.3.007 em seus E14s. Você pode reproduzir minha lista de problemas. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Como eu não sabia da atualização automática do fw para 2.3.x, minha rede estava misturada com 1.xe 2.x não era muito boa. Eu atualizei manualmente para 2.3.xe então piorou. (Rede mais rápida, mas dran de usabilidade massiva e, quedas de lâmpadas piscando) Então, eu posso recomendar se você tiver lâmpadas piscando em seu e14 ou "laggyness" em scences rebaixá-los para 1,2 ... Eu estaria interessado em obter um "oficial" / declaração profissional de nossos pro devs aqui sobre isso. Eu tenho certeza que houve um tempo em que o deconz foi tratado de maneira semelhante e foi melhorado. Eu sinto que isso precisa ser feito para 2.3.x também ou o Ikea bagunçou sozinho. É difícil dizer, pois não me aprofundo no código

@realwax
Estou usando o recurso otau do deconz e seu script de atualização de firmware para baixar os arquivos fw.
Não sei porque os E14s não são atualizados ... huhum.

Como você atualizou / rebaixou "manualmente" as lâmpadas?

Bem bem. Tudo funciona bem e a maior parte do roteamento é feito pelo E27s com fw 2.3.xe os drivers de led do painel Jormen e FLOALT.

@tubalainen
É interessante que você não tenha esses problemas. Talvez seja por causa do tamanho da malha. Eu tenho 23 lâmpadas daquele 20 e14 em 2.3.007. Desativei o otau automático porque ele atrapalhou minha usabilidade com o novo firmware. Via Gui você pode fazer o downgrade com o botão de atualização. Escolha primeiro o firmware adequado, pressione atualizar e talvez novamente. O status do formulário pausado vai para -> na fila -> inativo -> iniciar atualização de firmware (porcentagem). Às vezes, ele trava. Às vezes, é necessário reiniciar. Às vezes, um power cyle é o suficiente. Às vezes você precisa trazer a lâmpada para mais perto do coordenador.

Parece que o comportamento mudou e operá-los em deconz deve ser adaptado. Isso provavelmente para @ebaauw julgar ou lidar com isso?

Não sei o que você quer dizer aqui. Lidei com algumas diferenças entre o firmware ZLL e ZB3 para os controladores (controle remoto Trådfri e dimmer sem fio Trådfri), consulte o nº 2485. Isso está no nível APS na pilha ZigBee e gerenciado pelo plugin REST API.

Os problemas de roteamento deste tópico estão no nível NWK, que é tratado pelo firmware do dispositivo. Como todos aqui, não tenho acesso às fontes de firmware. Mesmo se eu quisesse, não há nada que eu pudesse fazer, pois não conheço os detalhes das camadas NWK e MAC.

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Precisamente falando. Incluí minhas descobertas com 20 E14 2.3.007 mesh aqui. Alguns recursos se foram e a recuperação da cena bagunça tudo por 10 a 15 segundos naquele grupo. Não sei se isso é apenas relacionado ao firmware ou ao deconz. Isso é o que eu quis dizer com mudança. Portanto, para operação diária, considero 2.3.007 como proibido. Exemplo de usabilidade dado: Um simples switch girando cenas configurado em phoscon não funciona mais quando não é pressionado com cuidado, o que significa que depois de uma rotação de cena deve esperar. Enquanto em 1.x tudo é rápido e bom com 2.3.x ele travou.

Obrigado, @manup , acabei de instalar. Vamos ver o que isso trará.
Embora eu espere que isso traga alguma melhoria, como você se sente sobre o firmware DeConz ignorando as rotas gravadas (devido ao roteamento mane-to-one)? Em geral, tenho visto que as rotas gravadas são muito mais lógicas do que as usadas pelo firmware DeConz.
Embora eu possa imaginar que habilitar o roteamento de origem seja um grande trabalho, o firmware DeConz poderia (deveria?) Ainda usar as informações do pacote de registro de rota para atualizar o primeiro salto para um dispositivo. Talvez apenas verifique se o último salto para o coordenador corresponde ao que está armazenado na tabela de roteamento e, caso contrário, invalide a entrada na tabela de roteamento. Não tenho certeza se está OK substituir a entrada com o último salto da rota gravada, uma vez que os dispositivos ao longo do caminho provavelmente ignoram as informações, mas pelo menos poderia iniciar uma nova descoberta de rota para aquele nó pelo firmware DeConz.
O que você pensa sobre isso?

Hmm estranho o firmware já deveria usar esses Registros de Rota para estabelecer novas Rotas, preciso checar o código aqui, mas se minha memória me atende direito isso foi habilitado há um tempo.

@manup , você encontrou algum tempo para olhar isso? Esta manhã, encontrei uma situação em que reiniciei uma luz (IKEA) que estava a 4 saltos de distância do coordenador. De alguma forma, um roteador intermediário (também IKEA) decidiu que não sabia mais a rota para essa luz. Na verdade, vejo a luz fazendo seu trabalho felizmente ao direcionar para outras luzes, relatando o status do link e respondendo a Network Address Request de deCONZ. Essa última só está acontecendo porque são mensagens de broadcast na rede ..!
No entanto, o roteador intermediário está descartando silenciosamente todos os quadros unicast que deveria rotear para esta luz. Este roteador, é claro, não deve descartá-los silenciosamente; então, novamente, o deCONZ deve ser robusto contra esse mau comportamento.
Enquanto isso, a luz também envia mensagens de registro de rota para deCONZ, que chegam e são ignoradas por deCONZ.

Acho que deve haver alguma lógica que deve acionar o deCONZ para reconsiderar suas rotas neste caso. Principalmente quando detecta que as requisições ZCL não estão sendo respondidas. O que no final faz com que a luz seja marcada como zumbi. A descoberta que segue a marcação como zumbi, na verdade, leva a uma resposta da luz. Talvez quando uma descoberta de um zumbi é iniciada, ela também deva invalidar todas as informações de rota disponíveis. Mas melhor ainda, se já antes, a rota é invalidada quando algumas solicitações ZCL não são respondidas (provavelmente já na primeira ou segunda delas).

O que você pensa sobre isso?

Este novo firmware não resolveu meu problema.

Eu uso um Raspbee em um Pi separado e um Home Assistant (rodando em um NUC) e tenho appx. 25 luzes tradfri. Principalmente GU10 usado em grupos de 3.

Eu tive grandes problemas com luzes individuais em um grupo de luz ficando sem resposta e precisando de um ciclo de energia para voltar novamente. Isso aconteceu com o Ikea FW v1 e depois de atualizar as lâmpadas para 2.3.007.

A solução foi mudar minha configuração de agrupar as luzes em HASS para definir grupos de luzes em Phoscon e referenciar os grupos Phoscon como luzes únicas em HASS. Depois dessa mudança, estou rodando sem problemas há alguns meses.

Eu quero ser capaz de fazer o agrupamento em HASS, então atualizei meu Raspbee para 0x26340500 e Deconz para 2.05.74 e mudei minha configuração de volta para usar grupos leves em HASS. Depois de fazer isso por uma semana, tive lâmpadas quebrando 3 ou 4 vezes, e agora estou voltando a usar grupos Phoscon novamente.

Acho que deve haver alguma lógica que deve acionar o deCONZ para reconsiderar suas rotas neste caso. Principalmente quando detecta que as requisições ZCL não estão sendo respondidas. O que no final faz com que a luz seja marcada como zumbi. A descoberta que segue a marcação como zumbi, na verdade, leva a uma resposta da luz. Talvez quando uma descoberta de um zumbi é iniciada, ela também deva invalidar todas as informações de rota disponíveis. Mas melhor ainda, se já antes, a rota é invalidada quando algumas solicitações ZCL não são respondidas (provavelmente já na primeira ou segunda delas).

Ainda estou no novo firmware e testo algumas coisas, incluindo os registros de rota, espero colocá-lo online esta semana.

O que você pensa sobre isso?

Esse é um bom ponto, preciso verificar o código do núcleo e do plugin REST-API aqui, pois acho que o firmware já deve degradar a "qualidade" da rota quando nenhum ACK de nível de APS for recebido. O APS ACK é um sinalizador que é definido opcionalmente nas solicitações ZCL / APS e geralmente é desativado para reduzir o tráfego de rede. Portanto, uma ideia aproximada é que devemos habilitar APS ACK se o plug-in detectar que solicitações unicast levam a tempos limite.

Talvez parte disso já esteja em vigor, é necessário verificar o código.

No entanto, o roteador intermediário está descartando silenciosamente todos os quadros unicast que deveria rotear para esta luz. Este roteador, é claro, não deve descartá-los silenciosamente; então, novamente, o deCONZ deve ser robusto contra esse mau comportamento.

A luz deve pegar uma nova rota assim que a descoberta de uma nova rota for acionada. Portanto, o objetivo deve ser detectar a rota interrompida o mais rápido possível (espero que o APS ACK resolva o problema) e acionar a descoberta da rota.

A máquina de estado para isso já está em vigor no núcleo deCONZ (isso é o que leva à transmissão de solicitação de endereço NWK), isso funciona no caso de links de um salto e para luzes que pegam rotas com base em comandos de entrada (a resposta ao transmissão). A transmissão é boa, pois também respeita o endereço NWK alterado porque o endereço MAC está incluído. Vou tentar enviar um unicast com APS ACK ativado como a próxima etapa, caso nenhuma resposta seja recebida.

Infelizmente, ontem tive que desligar e ligar uma lâmpada IKEA E27 (branca 1000LM, firmware v1) também. Ele apenas reagia ao grupo, mas não aos comandos unicast. Parece que o problema ainda não foi corrigido :(

(e sim, estou no v74 e no firmware beta para RaspBee)

Veja os comentários acima, as próximas mudanças podem ajudar a recuperar o roteamento.

O que você pensa sobre isso?

Esse é um bom ponto, preciso verificar o código do núcleo e do plugin REST-API aqui, pois acho que o firmware já deve degradar a "qualidade" da rota quando nenhum ACK de nível de APS for recebido. O APS ACK é um sinalizador que é definido opcionalmente nas solicitações ZCL / APS e geralmente é desativado para reduzir o tráfego de rede. Portanto, uma ideia aproximada é que devemos habilitar APS ACK se o plug-in detectar que solicitações unicast levam a tempos limite.

Talvez parte disso já esteja em vigor, é necessário verificar o código.

Parece que mesmo quando o bit de solicitação APS ACK está definido, deCONZ não faz nada com o ack ausente (apenas uma nova tentativa e depois nada ...)

BTW houtlamp 2 é quem está descartando os pacotes direcionados a 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

No entanto, o roteador intermediário está descartando silenciosamente todos os quadros unicast que deveria rotear para esta luz. Este roteador, é claro, não deve descartá-los silenciosamente; então, novamente, o deCONZ deve ser robusto contra esse mau comportamento.

A luz deve pegar uma nova rota assim que a descoberta de uma nova rota for acionada. Portanto, o objetivo deve ser detectar a rota interrompida o mais rápido possível (espero que o APS ACK resolva o problema) e acionar a descoberta da rota.

A máquina de estado para isso já está em vigor no núcleo deCONZ (isso é o que leva à transmissão de solicitação de endereço NWK), isso funciona no caso de links de um salto e para luzes que pegam rotas com base em comandos de entrada (a resposta ao transmissão). A transmissão é boa, pois também respeita o endereço NWK alterado porque o endereço MAC está incluído. Vou tentar enviar um unicast com APS ACK ativado como a próxima etapa, caso nenhuma resposta seja recebida.

Na verdade, o houtlamp 2 nunca vê uma resposta à transmissão address request . As mensagens para deCONZ são roteadas por tuin linksvoor 3 , então mesmo se houtlamp 2 pegasse essa rota, nunca teria a chance. Isso é novamente causado por deCONZ não pegar route record como uma nova rota.

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]

Agora Tuin linksvoor 2 envia uma resposta à transmissão de network address request e é bem-sucedido, mas o APS ACK de deCONZ nunca atinge Tuin linksvoor 2 , já que é descartado por houtlamp 2 . Então, ele é reenviado algumas vezes antes de desistir. Isso terá uma boa chance de bagunçar Tuin linksvoor 2 .

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

Conbee 1 + fw mais recente + .74 não está jogando 100%.
Teve alguns acertos / erros. Parece funcionar melhor com 0,73 para mim, mas não 100%.

Então, de volta à prancheta. Ainda não está 100% ok com o novo (beta) Conbee 1 fw.

Depois de alguns dias de operação com .74 e 26340500 no Conbee 1 no Tradfir E14 com firmware 1.2.221 pode relatar que:

A luz IKEA tornou-se mais estável em termos de queda da rede, embora eu só tivesse uma lâmpada que se perdeu em 4 dias. Também descobri que se você estressar sua rede zigbee operada por deconz rodando em E14 fw 1.2.221. Eu executei um script diminuindo o brilho enviando solicitações únicas com o bri alterado a cada segundo. Assim perdi 4 lâmpadas muito rápido. Mas quem quer isso de qualquer maneira;)

Ainda não resolvido:
O problema e a preocupação que ainda tenho é que o Tradfri FW 2.3.x não está funcionando bem ou não está bem implementado para ser usado com o deconz. Não há problema em permanecer no tradfri fw 1.2.x e não no zigbee 3.0. Mas chegará um momento em que isso não poderá ser evitado. Ou as lâmpadas novas serão degradadas mais, eu temo.
Eu descobri que um grupo de 2 a 3 lâmpadas não mostra esse problema tão mal quanto um grupo de 4 a 8 lâmpadas.
Eu relatei minha descoberta aqui e fico feliz e grato se for descoberto. Tentei aumentar a conscientização aqui https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
pois posso reproduzir esse problema simplesmente piscando todas as minhas lâmpadas para 2.3.xe espero que você também possa fazer isso.

Resumindo - faz diferença sobre qual firmware Tradfri é usado e do qual estamos falando. Há uma enorme diferença na usabilidade e problema experimentado e operação com deconz. Enquanto os fws 1.2.x mais provavelmente são mais antigos e funcionam perfeitamente ao lado dos conhecidos dropouts, 2.3.x não perdeu a usabilidade, conforme descrito no problema levantado. Não consigo imaginar que eu seja o único a experimentar essa diferença nos FWs.

Agora enviei um e-mail para o suporte da dresden elektronik em alemão para aumentar a conscientização sobre isso, pois entendi que alguns de vocês são entusiastas do hobby, como @ebaauw deixou claro em outro tópico. Achei que a maioria dos desenvolvedores são contratados dresden elektronik. Desculpe pelo equívoco e obrigado por suas contribuições. Estou curioso sobre a resposta oficial agora.

O firmware do Conbee II também foi corrigido agora? Eu vi apenas Conbee I no lançamento. A propósito, obrigado a todos pelo seu trabalho árduo.

Isso é novamente causado por deCONZ não pegar o registro de rota como uma nova rota.

@djwlindenaar acabou que eu sou o culpado aqui, eu verifiquei os commits de código do Route Record no repositório de pilha (ConBee I e RaspBee I). Em 2018, eu adicionei uma "correção" (ou pensei que sim) para um problema semelhante que apenas desabilitou a atualização do endereço do próximo salto em um registro de rota de entrada.

Se não me falha a memória, o problema na época era que tínhamos uma grande rede mista em torno de 150 nós e os registros de rota aparentemente não funcionavam corretamente. O novo caminho de volta não estava funcionando corretamente. No entanto, o código pode ter funcionado com a outra correção dos códigos de erro do comando de status NWK.

Eu reverto isso agora, então o registro da rota deve atualizar a rota para o melhor caminho.

Adoro esse parágrafo da especificação Zigbee:

Um roteador ZigBee ou coordenador ZigBee pode manter uma tabela de roteamento. As informações que devem ser armazenadas em uma entrada da tabela de roteamento ZigBee são mostradas na Tabela 3-66. O vencimento e aposentadoria das entradas da tabela de roteamento para reivindicar novamente o espaço de tabela de entradas que não estão mais em uso é uma prática recomendada; está, entretanto, fora do escopo desta especificação.

O que basicamente significa que cada pilha lida com o envelhecimento da rota de maneira diferente.

Portanto, verifiquei como funciona no nosso caso. No Bitcloud Zigbee, as rotas de pilha têm uma "taxa" de rota, que inicialmente é 1.

1. Em uma transmissão NWK bem-sucedida, a taxa é incrementada se estiver abaixo do máximo que é
   (1 << 8) - 1 = 255
2. Em uma transmissão NWK bem-sucedida, se o máximo de 255 for atingido, todas as entradas da tabela de roteamento serão "normalizadas"
   rate = (rate >> 1) + 1 (efetivamente dividido por 2, com um mínimo de 1)
3. Em uma transmissão NWK com falha, a taxa da entrada de rota relacionada é definida como:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. Em muitas transmissões com falha, a taxa torna-se 0 e a rota é removida

Isso significa que um link superior será degradado como:

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

Portanto, são necessários 8 comandos com falha até que uma entrada seja removida e a descoberta seja iniciada novamente.
Isso é muito bom em redes normais, especialmente quando elas crescem para 50 .. 100 nós, uma rota não deve ser descartada muito cedo.

O que me preocupa é o ponto (2) porque, por exemplo, uma rota muito nova ou que não seja usada, que muitas vezes seria degradada por nós de alto desempenho completamente não relacionados com bons links, por exemplo, uma luz Philips Hue que é consultada a cada poucos segundos. o gatilho (2) frequentemente multiplica isso pelo número de luzes em uma grande rede. Sem mencionar as atualizações OTA ativas.

Acho que é seguro alterar (2) para não degradar (normalizar) todas as entradas de rota, mas apenas a rota 255 principal relacionada à transmissão bem-sucedida. Isso deve evitar a perda de rotas que funcionaram bem, mas não foram usadas com frequência e foram removidas na primeira transmissão NWK com falha.

Vou construir um novo firmware com essas mudanças amanhã, também um para ConBee II provavelmente o mesmo se aplica lá.

Eu reverto isso agora, então o registro da rota deve atualizar a rota para o melhor caminho.

OK parece bom. Estou ansioso para testar!

Adoro esse parágrafo da especificação Zigbee:

Sim, acho que esse tipo de especificação está nos dificultando fazer com que todos os fornecedores coexistam bem. :sorriso:

No Bitcloud Zigbee, as rotas de pilha têm uma "taxa" de rota, que inicialmente é 1.

Eu realmente não entendo a lógica por trás da regra 2. Parece uma espécie de versão de envelhecimento do homem pobre. O que funciona muito bem se todos os nós veem uma quantidade semelhante de tráfego, mas de fato, se estiver desequilibrado (o que eu acho que é bastante comum), vai dar errado.
Percebi que o ZStack está usando um campo expiryTime real em sua tabela de roteamento, próximo a um byte status .

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

Como isso realmente funciona?
Se não me engano, uma transmissão NWK com falha na verdade significa apenas o próximo salto, uma vez que o NWK só verifica o 802.15.4 MAC ACK. Portanto, para verificar se a transmissão de ponta a ponta está OK, devemos confiar no APS ack. Isso é correto? Funciona assim no BitCloud?
Além disso: se o bit de solicitação de confirmação na camada APS não estiver definido, isso é considerado uma transmissão bem-sucedida (uma vez que não se espera nenhum reconhecimento) e isso está aumentando a "taxa" dessa entrada de rota? Porque, se for o caso, podemos estar atirando no próprio pé por não solicitar ACK da camada APS o tempo todo.

Se for baseado apenas em falhas NWK, isso não ajudará na situação de um roteador intermediário estar se comportando mal e precisamos adicionar lógica adicional para levar em conta que a camada APS ACK não está chegando. Provavelmente com base em uma lógica semelhante para detectar roteadores 'zumbis', mas primeiro invalidando a entrada da tabela de rotas para essa rota.

A versão de firmware 0x26350500 para ConBee I e RaspBee I está disponível para teste.

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

• Como 0x26340500, todos os erros de rota de status NWK são tratados
• Corrigir degradação de rota injusta (consulte o ponto 2. em https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Corrigir registros de rota não atualizou o próximo salto de uma rota, observe que agora funcionará, mas apenas se o custo da rota atual for maior quando o registro da rota
• A correção de solicitações APS com falha com APS ACK ativado não degradou a rota

Agora estou procurando no código do ConBee II para ver se e onde essas correções podem ser aplicadas. Descartando 0x26520700 e 0x26530700 e baseando-o no 0x264a0700 estável atual.

Eu realmente não entendo a lógica por trás da regra 2. Parece uma espécie de versão de envelhecimento do homem pobre. O que funciona muito bem se todos os nós veem uma quantidade semelhante de tráfego, mas de fato, se estiver desequilibrado (o que eu acho que é bastante comum), vai dar errado.
Percebi que o ZStack está usando um campo expiryTime real em sua tabela de roteamento, próximo a um byte de status.

Concordo totalmente, isso agora foi corrigido para que apenas a rota de uma transmissão bem-sucedida seja normalizada quando a taxa atingir o máximo. A forma de cronômetro expirado de lidar com isso pode ser outra opção, mas tem suas próprias armadilhas em escala. Acho que a forma de "taxa" deve funcionar muito bem, sem depender do tamanho da rede e do tempo.

Se for baseado apenas em falhas NWK, isso não ajudará na situação de um roteador intermediário estar se comportando mal e precisamos adicionar lógica adicional para levar em conta que a camada APS ACK não está chegando. Provavelmente com base em uma lógica semelhante para detectar roteadores 'zumbis', mas primeiro invalidando a entrada da tabela de rotas para essa rota.

Esse parecia ser o caso e, de fato, roteadores com comportamento incorreto, que não enviam comandos de status NWK com falhas de rota, poderiam manter uma rota morta viva. Isso agora foi corrigido em 0x26350500, mas depende de comandos habilitados para APS ACK. O que deve estar bem e pode ser controlado por deCONz e o plugin REST-API.

A versão de firmware 0x26350500 para ConBee I e RaspBee I está disponível para teste.

Mostrou, agora testando.

Isso agora foi corrigido em 0x26350500, mas depende de comandos habilitados para APS ACK.

O que você faz em resposta a um ACK ausente? Você divide o rate pela metade, igual a uma transmissão NWK com falha ou mais / diferente? Porque eu acho que um APS ACK ausente deve ser considerado mais grave em comparação com uma transmissão NWK com falha. Caso contrário, novamente no caso de um roteador com comportamento incorreto, as transmissões NWK bem-sucedidas podem aumentar rate mais do que os APS ACKs ausentes diminuem.

O que você faz em resposta a um ACK ausente? Você divide o valor da taxa da mesma forma que com uma transmissão NWK com falha ou mais / diferente? Porque eu acho que um APS ACK ausente deve ser considerado mais grave em comparação com uma transmissão NWK com falha. Caso contrário, novamente no caso de um roteador com comportamento incorreto, as transmissões NWK bem-sucedidas podem aumentar a taxa mais do que os APS ACKs ausentes diminuem.

Eu pensei o mesmo, aqui está o que está acontecendo nesse caso:

• Transmissão NWK MAC ACK positivo rate + 1
• Sem APS ACK rate = rate / 4

Portanto, a taxa cai rapidamente, pode ser um pouco agressivo demais e rate / 2 é o suficiente, mas vamos ver como funciona na prática.

Agradável. Vou executá-lo e apresentar um relatório.

Atualmente também teste de estresse enviando mensagens unicast (OnOffwithLevel) para uma luz que está bem longe na malha, a cada poucos segundos.

Btw eu também mudei o código do plugin restante para solicitar APS ACK em todas as mensagens.

Estou executando o Deconz em um Rpi 3B + usando o Home Assistant
Atualmente executando 2.05.75 com Conbee I e 26330500

Percebi esta noite que algumas luzes não foram acesas.
Tentei ligá-los manualmente, veja o log abaixo.
Verificada a malha VNC, faz parte da rede mesh mas não reage a nada.
Este nó é uma chave liga / desliga de saída Tradfri.

Coisa estranha aqui:
_ POSSO ligar o interruptor ao habilitar o grupo Deconz em vez do interruptor individual._

19: 23: 58: 979 atraso no envio da solicitação 57 dt 0 ms para 0x000D6FFFFEB1C9FF, ep: 0x01 cluster: 0x0004 onAir: 1
19: 24: 15: 744 Canal atual 25
19: 24: 15: 776 Sinalizadores do dispositivo TTL 3920 s: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirm: 0xA7 na tarefa
19: 25: 10: 547 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirmar: 0xA7 na tarefa
19: 25: 15: 749 Canal atual 25
19: 25: 15: 782 Sinalizadores do dispositivo TTL 3860 s: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirm: 0xA7 na tarefa
19: 25: 49: 411 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirm: 0xA7 na tarefa
19: 26: 12: 765 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirm: 0xA7 na tarefa
19: 26: 12: 765 erros máximos de transmissão para o nó 0x000D6FFFFEB1C9FF, visto pela última vez pelos vizinhos 25 s
19: 26: 15: 742 Canal atual 25
19: 26: 15: 774 Sinalizadores de 3800 s do dispositivo TTL: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF erro APSDE-DATA.confirm: 0xA7 na tarefa
19: 26: 48: 221 erros máximos de transmissão para o nó 0x000D6FFFFEB1C9FF, visto pela última vez pelos vizinhos 60 s
19: 27: 03: 845 estado de nó salvo em 9 ms
19: 27: 33: 634 sync () em 29789 ms

As últimas correções estão em 26350500 ...

@djwlindenaar Estou prendendo a respiração, aguardando o resultado do seu teste :-)

Por enquanto, tudo bem. Posso ver o deCONZ trocando de rota com alegria. :sorriso:

As últimas correções estão em 26350500 ...

Desculpe, interpretou mal a versão FW.
Quero ajudar no teste, usando o complemento Deconz do Home Assistant oficial, não tenho certeza de como atualizá-lo para um firmware beta. (atualizações oficiais são OTA)

Caro @manup , algum status sobre a atualização do Conbee ii fw?

@manup , parece que não há ação para Many-to-One Route Failure (0x0c) . Eu esperaria que o deCONZ fizesse novamente um MTORR (a menos que um já esteja em andamento). Eu recebo essas mensagens regularmente.

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

@manup , parece que route record nem sempre é assumido pela deCONZ. Por exemplo:

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

A luz Tuin linksvoor 2 está enviando diretamente para deCONZ , mas o caminho de deCONZ é através de vários saltos ...
Seria útil se você pudesse dar algumas dicas sobre o processo de tomada de decisão em deCONZ para sim / não aceitar a rota da mensagem route record .

--- editei os itens abaixo, pois havia uma falha no meu raciocínio. Agora, espero que não: wink: ---

Dito isso, a rota usada por deCONZ é na verdade muito mais confiável do que a comunicação direta com Tuin linksvoor 2 . Isso me fez pensar e examinar o roteamento muitos para um. Estou pensando que talvez a potência de transmissão do Raspbee não seja ideal ...
Este é o meu raciocínio:

• O roteamento muitos para um é baseado no recebimento de transmissões
• Ao contrário do tratamento de rota normal, o máximo de custos de caminho de entrada e saída é considerado o custo para o próximo salto
• Agora, se um roteador ou coordenador é muito melhor na transmissão (alta potência TX) do que na recepção (baixa sensibilidade RX), isso pode fazer com que o roteamento muitos para um não funcione muito bem.

Um ponto relacionado que notei é que deCONZ parece ser (muito) otimista sobre o custo de entrada em sua tabela de rota. Quando Tuin linksvoor 2 envia uma mensagem para deCONZ diretamente, ele precisa de várias tentativas, o tempo todo. Agora, se eu olhar a tabela de rotas, vejo o seguinte e não esperaria uma transmissão difícil com um custo de entrada de 4. Observe que basicamente todos os itens na tabela de rotas têm um custo de entrada muito menor do que o custo de saída.

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

Portanto, se deCONZ fosse menos otimista sobre o custo de entrada, poderíamos estar vendo um comportamento melhor da rota. Ou se aumentássemos a potência TX para ser mais equilibrado (custo semelhante para entrada e saída)
Ou se diminuirmos a potência TX de deCONZ, eu espero que ele precise rotear mais saltos (o custo de 7 dispositivos sairia da tabela de rotas), mas também será mais fácil para as mensagens de entrada serem recebidas.

Lista total da mensagem de status do link 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

Desculpe o atraso. Status: ainda estamos trabalhando duro na nova versão e ainda rastreando bugs no firmware que parecem ser mais complexos do que pensávamos. Algo no manuseio da nvram parece estar errado. Também estamos tentando resolver os problemas de inicialização / enumeração de usb.

Vou postar atualizações aqui assim que estiverem disponíveis.

Atualização: ainda está forte!

Acho que nunca vi uma rede tão estável. Já mudei várias regras para usar unicast em vez de grupos. Agora, por 2 semanas e 0 luzes IKEA desapareceram.

(Espero não azarar agora)

Observe que eu mudei o plug-in REST para solicitar ack APS para todas as solicitações.

Também estou experimentando uma rede muito melhorada. Mas não 100%. Ocasionalmente, algumas lâmpadas não responderam, mas quando alterei manualmente a lâmpada IKEA, ela respondeu. Também vejo que o estado da lâmpada é agora igual ao estado físico.
No entanto, uma das minhas lâmpadas Osram teve um comportamento irresponsivo como as lâmpadas ikea tinham antes. O lado positivo é que não é um comportamento tão severo como o da ikea.

Espero que isso possa ser confirmado por outros ou descobertas identificadas.

Estou executando o Conbee 1, com FW 26350500 e Deconz 2.05.75.
Esta é minha experiência nas últimas semanas

• Funciona melhor, mas não 100%
• Algumas das minhas lâmpadas IKEA E27 TRÅDFRI E27 WS opal 980lm com fw 2.3.007 às vezes não respondem aos comandos OFF
• Posso apenas tentar desligá-los novamente e geralmente funciona (não há necessidade de desligar e ligar)

@djwlindenaar nice! A sua correção de APS para a API REST está incluída na versão .75? Só para saber se isso poderia explicar algumas diferenças nos posts anteriores ...

Não, não é. Eu nem mesmo criei uma solicitação de pull para ele. Com isso, você pode construí-lo sozinho. Vou fazer isso hoje ou amanhã.
Também posso compartilhar o plug-in da API Rest construído, mas só tenho o do raspberry 3.

@tubalainen , vou verificar se isso pode ser explicado com o APS ack. Além disso, não tenho luzes 2.3 IKEA.

Possivelmente, há um problema com o comportamento de nova tentativa em deCONZ. Eu precisaria fazer um experimento para isso ou talvez já esteja nos logs de detecção.

Se você pode cheirar, cheirar esse fenômeno ajudaria. Posso ajudar a analisar se você não puder.

Atualizei minha rede de produção (RPi 3B +, stretch, RaspBee) para 2.05.74 e 0x26340500 ontem. Parece estável, exceto pelos problemas abaixo.
Não tenho certeza se relacionado, mas o caminho para o meu controlador de cortina lumi.curtain foi perdido esta manhã. Os relatórios do controlador ainda alcançariam o gateway. A rota não seria restaurada ao desligar e ligar o controlador. Eu tive que abrir a rede e desligar e ligar o controlador, antes que o coordenador pudesse alcançá-lo novamente.
Além disso, uma das válvulas do meu radiador Eurotronic Spirit estava inacessível pelo deCONZ depois de iniciar o deCONZ, embora ainda enviasse relatórios. Desligar e ligar o TRV trouxe de volta, como sempre.
Não tive a oportunidade de fazer nenhuma investigação aprofundada desta vez, mas ambos os dispositivos têm sido problemáticos desde o início, exibindo esses sintomas de vez em quando. O mesmo vale para a minha cortina IKEA Fyrtur. Vou continuar a monitorar a situação e relatar se encontrar mais problemas.

É muito difícil registrar esses problemas intermitentes de forma objetiva, mas tenho a impressão de que 0x26350500 trouxe melhorias aqui. Tirando os dispositivos mencionados acima, minha rede é muito estável. Alguns TRVs ficaram inacessíveis do gateway, mas principalmente (apenas?) Após reiniciar o deCONZ. Não acho que o FYRTUR nem o controlador de cortina desapareceram nas últimas três semanas.

Observe que eu mudei o plug-in REST para solicitar ack APS para todas as solicitações.

Eu tenho APS Acks habilitado em _Network Settings_ na GUI, mas não tenho certeza se isso se aplica apenas às mensagens enviadas pela GUI, ou também ao plugin REST API.

Se você deseja executar com a solicitação pull acima, também pode verificar meu fork e compilá-lo: djwlindenaar / deconz-rest-plugin

@ebaauw , pelo que eu posso dizer, isso só se aplica aos comandos enviados da GUI

Eu tenho um farejador funcionando continuamente e não acerto o tempo quando um problema acontece. Normalmente, com essa informação, consigo encontrar os pacotes com bastante facilidade ...

BTW, mudei muitas das minhas regras (especialmente aquelas que são acionadas com frequência) para unicast. Até agora está funcionando muito bem. Além disso, tenho executado uma luz IKEA continuamente alterando o brilho (a cada 4 segundos ou mais) nas últimas 2 semanas. Esse também ainda está bem.

bem ... Acabei de notar algo estranho em meus logs. Descobri que nenhuma das luzes que liguei e desliguei estaria relatando seus atributos. Achei que estava descobrindo outro bug, mas não estava, embora, de certa forma, possamos querer considerar isso um bug de qualquer maneira.

Como mencionei, eu tinha um script em execução para alterar o nível de uma luz a cada dois segundos. Pensar que isso pode estar acelerando os problemas com as luzes IKEA. Acontece que isso zera o contador d->idleLastActivity , o que impede que qualquer tarefa ociosa seja executada. Incluindo a configuração do atributo reporting: rofl:

Você está dizendo que as luzes IKEA perdem suas ligações e configuração de relatório de atributo após um ciclo de energia ?!

Parece que ... Eles não deveriam ..?

Meu problema agora é que, desde que atualizei minha configuração para 0,75 e 50500, meu contêiner docker está perdendo o Conbee pelo menos uma vez por semana. Reiniciar o contêiner faz as coisas funcionarem novamente ... MUITO chato

@djwlindenaar , não, acho que não deveriam. A maioria dos dispositivos que já vi mantém essas configurações em memória não volátil. Suponho que o padrão ZigBee deixa espaço para ambos os comportamentos.

Embora minhas lâmpadas IKEA estejam funcionando muito melhor agora, infelizmente, um dos meus sensores Xiaomi (sensor redondo de temperatura) deixa de responder depois de um tempo. Tentarei reunir algumas evidências cheirando nos próximos dias.

Estou executando o Conbee 1, com FW 26350500 e Deconz 2.05.75.
Esta é minha experiência nas últimas semanas

• Funciona melhor, mas não 100%
• Algumas das minhas lâmpadas IKEA E27 TRÅDFRI E27 WS opal 980lm com fw 2.3.007 às vezes não respondem aos comandos OFF
• Posso apenas tentar desligá-los novamente e geralmente funciona (não há necessidade de desligar e ligar)

@tubalainen Oi, notei o comportamento diferente do ikea com firmware 2.3.x em comparação com 1.2.x também. Tentei resolver o problema, mas não recebi atenção. Eu rebaixei minhas lâmpadas para 1.2.xe funciona maravilhosamente bem agora. Em 2.3.x. Você não pode desligar após uma recalibração de cena por um período de tempo. Normal on off funcionou. Comportamento estranho. Talvez você queira testar e contribuir aqui. cheers https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

Você está dizendo que as luzes IKEA perdem suas ligações e configuração de relatório de atributo após um ciclo de energia ?!

Infelizmente, eles perdem suas ligações após um ciclo de energia, o código foi adaptado há algum tempo para resolver isso. As vinculações e a configuração serão restauradas depois que uma luz for desligada e ligada e também se nenhum relatório for recebido por um certo tempo, o processo iniciará para restaurá-los.

@realwax será reduzido para 1.2.x em todas as minhas lâmpadas E27 e reportará de volta. (leva algum tempo :)).

Ontem duas luzes E27 (com 2,3x FW) não apagaram durante a seqüência matinal.

@tubalainen você usa comandos de grupo ou comandos unicast? (ou seja, por meio da API REST, defina o estado por meio de / groups / ou / lights /)

Acho que, desde que as luzes sejam alcançáveis, os comandos unicast são mais confiáveis. Se um comando de transmissão em grupo for perdido de alguma forma, ele não será repetido. Os comandos Unicast são repetidos algumas vezes ou até serem entregues.

@tubalainen você usa comandos de grupo ou comandos unicast? (ou seja, por meio da API REST, defina o estado por meio de / groups / ou / lights /)

Acho que, desde que as luzes sejam alcançáveis, os comandos unicast são mais confiáveis. Se um comando de transmissão em grupo for perdido de alguma forma, ele não será repetido. Os comandos Unicast são repetidos algumas vezes ou até serem entregues.

Eu uso o Home Assistant e a API RESt. Não sei o que o Home Assistant faz ...

No meu caso é iobroker com plug-in de deconz e Phoscon ... Então descanse API. Os problemas aparecem ao usar igroups. Uma chamada de cena de grupo aciona que o grupo não pode ser desligado, nem alterado rapidamente para outras configurações de cena de grupo ou desligado de forma adequada, especialmente em até 15 segundos após a chamada de cena. Parece que deconz está ocupado com o comando antes, ou 2.3.x fw congelamento de lâmpadas (o que eu duvido). Ainda não é possível depurar no nível zigbee para obter uma melhor compreensão. O recurso de agrupamento de deconz é uma camada virtual que é traduzida em comandos uni cast ou é feito por meio de opções de agrupamento disponíveis no gui / zigbee? Resumindo, eu uso a função de grupo integrada, caso contrário, precisaria criar essa camada virtual no iobroker e não há motivo, pois o recurso de agrupamento é bom. Portanto, se for o agrupamento ... Qual é a diferença, pois parece 100% com fw 1.2.xe não com 2.3.x. O que mudou? É zigbee 2 porque eles se comportam de forma diferente.

@tubalainen Sim, dá muito trabalho, pois pode ser necessário reiniciar de vez em quando ou trazer algumas lâmpadas para mais perto. Eu fiz isso duas vezes com 20 e14 tradfri. Você deve ver uma grande melhoria. Você percebe que suas lâmpadas com 2.3..x não amolecem. (fade in) mais e 1.2.x fazer?

MAS dedos cruzados para que mais possam reproduzi-lo, então o ikeas fw 2.3.x ficará operacional no deconz, pois haverá um ponto no tempo que precisaremos atualizar. Ou substitua as lâmpadas. Embora o zigbee 2 também seja bom.

Obrigado a todos por seus esforços!

@realwax @djwlindenaar @manup

Na noite anterior, uma luz não apagou como deveria (IKEA E27 com fw 2.3.x). Testei alterar o brilho daquela luz que não desligou e mudou instantaneamente para a configuração de brilho que escolhi. Momentos após alterar o brilho, a luz de repente respondeu bem também ao comando de desligar.

Agora, pessoalmente, mudei todas as minhas automações no Home Assistant para primeiro alterar o brilho, aguarde 2 segundos e envie o comando de desligamento.

Até agora, 100% de taxa de sucesso.

Espero que isso possa ser uma pista para a investigação.

EDIT: São sempre as luzes que estão mais distantes da coordenação (o stick de Conbee) que não se apagam. (luzes que devido à natureza da banda de frequência tem que se encaixar)

Ei pessoal!

Só queria falar sobre meus problemas ...
Depois de ter problemas de estabilidade com meu stick ConBee II, verifiquei a versão do firmware. Era 26530700. Fiz então o downgrade para 264a0700 e, depois disso, nenhum aplicativo consegue ver o stick. Eu tentei o HomeAssistant e o deCONZ. O sistema operacional do host identifica o stick OK e GCFFlasher funciona.

Ei pessoal!

Só queria falar sobre meus problemas ...
Depois de ter problemas de estabilidade com meu stick ConBee II, verifiquei a versão do firmware. Era 26530700. Fiz então o downgrade para 264a0700 e, depois disso, nenhum aplicativo consegue ver o stick. Eu tentei o HomeAssistant e o deCONZ. O sistema operacional do host identifica o stick OK e GCFFlasher funciona.

Depois de fazer o downgrade para 26490700, tudo parece estar funcionando novamente ... Malha Zigbee estável por 24 horas agora ....

Alguma atualização? Eu realmente quero mudar minha casa inteira para o meu Conbee II, mas no momento ela está muito instável. Minha tonalidade funciona perfeitamente, Conbee ii nem tanto 🥺

Minha experiência com o deCONZ .75 mais recente com RaspBee FW 0x26350500 é muito boa até agora.

Meus dispositivos:
4x Luzes Tradfri 980lu WS - FW 2.3.007
Luzes 17xTradfri 1000lu WS - FW 2.0.023
Plugues 3xTradfri - FW 2.0.022
3xTradfri Round Remotes E1810 - FW 2.3.014
4xsensores Aqara THP

Encontrou outro que trava o firmware da lâmpada IKEA. (e acho que pode ser corrigido no deConz)

Eu vi uma luz não respondendo esta manhã. A última comunicação é mostrada abaixo.

Parece que deConz recebe a resposta de associação de grupo, mas de alguma forma o APS ACK (reconhecendo a solicitação de associação de grupo Get) enviado pela luz não é recebido por deConz (eu também não vejo um MAC ACK). Como resultado, deConz reenvia a solicitação. Este pedido tem o mesmo número no ZCL, o que trava o firmware leve.

Acho que a deConz pode considerar o pedido confirmado assim que a resposta correspondente chegar e evitar colocar outro pedido. Direito? Existe uma API para o plugin que pode ser chamada para cancelar uma solicitação? @manup?

Observe que esse bug específico também é contornado ao não solicitar o APS ACK para essas solicitações, que é o padrão no plug-in da API REST atual.

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

Executando v2.05.75 com 0x26350500 por algumas semanas agora. Parece um pouco mais estável do que as versões anteriores, mas ainda estou perdendo ocasionalmente o caminho para meus TRVs Eurotronic Spirit, minha persiana Fyrtur e meu controlador de cortina Xiaomi lumi.curtain . O último é um roteador; os outros são dispositivos finais. Todos os TRVs têm a mesma versão de hardware / firmware, mas alguns vão para MIA com mais frequência do que outros. Os sintomas são consistentes: o dispositivo continua a enviar relatórios ao coordenador, mas os comandos do coordenador resultam apenas em uma _Solicitação de rota_ sem resposta.

Atualmente farejando e analisando o tráfego do TRV que desaparece com mais frequência. Os relatórios chegam ao coordenador em três saltos, usando duas luzes Hue ao longo do caminho. Eu também capturei uma _Solicitação de dados_ do TRV para a primeira luz do caminho, então o TRV parece feliz por ser seu pai. As solicitações do descritor de correspondência do TRV para o cluster OTAU ficam sem resposta. O pai relata a próxima luz em seu _Link Status_, mas não o TRV (porque é um dispositivo final?).

As mensagens _Link Quality Response_ mostram uma tabela vizinha de 20 entradas, mas a TRV não está entre elas. Um sensor de porta Xiaomi (que tem estado estável desde sempre) é. O coordenador é estranho, mas o relatório do TRV para o coordenador foi retransmitido por outro roteador (que também está na tabela de vizinhos).
Ok, agora o coordenador também está incluso no _Estado do Link_ e o próximo relatório do TRV é encaminhado diretamente para o coordenador.

Desligou e religou o TRV. O TRV envia uma _Solicitação de dados_ MAC para o pai (anterior); o roteador responde com uma _Rejoin Response_ passando o endereço NWK antigo do TRV como novo endereço. O TRV então transmite o _Anúncio do dispositivo_ (unicast MAC para o pai; o pai encaminha como uma transmissão MAC). O TRV envia uma _Solicitação de tempo limite do dispositivo final_ ao pai; o pai envia um _Atualizar Dispositivo_ para o coordenador informando que o TRV se reuniu com segurança. O pai agora também envia uma _Reposta de rota_ para a _Solicitação de rota_ do coordenador. Na próxima sequência _Link Quality Response_, o TRV é incluído.

Vou manter o farejador funcionando, com sorte para pegar o momento em que o TRV vai faltar novamente.

Em uma nota possivelmente relacionada: um dos meus plugues inteligentes innr SP120 ainda pensa que é o pai do botão Hue, que eu rapidamente uni à minha rede de produção enquanto adicionava suporte. O botão já foi adicionado à minha rede de teste por algumas semanas, e desliguei o plugue várias vezes. Preciso redefinir o plugue de fábrica para esquecer a criança perdida?

@manup , muito tempo desde qualquer atualização tanto no código quanto nas informações sobre o que está acontecendo. Você poderia nos dar uma atualização sobre o progresso de suas equipes sobre os problemas de estabilidade e se você ousar também um cronograma previsto.

Encontrei outro problema no comportamento de roteamento do deConz.

Nesse caso, deConz tenta rotear a mensagem para Hal lamp por meio de Tuin linksvoor 3 . Mas olhando para o relatório Link Status de Tuin linksvoor 3 ele não sabe sobre Hal lamp . E aparentemente também não sabe como chegar por meio de roteamento. Claro que aquela luz (IKEA) deveria se comportar e responder com uma mensagem de falha, mas não o faz e não podemos mudar isso.
No entanto, deConz conclui que o Hal lamp é um zumbi sem qualquer tentativa de encontrar uma nova rota para essa luz. Não tenho certeza de como isso interage com o (novo) código de roteamento, mas de alguma forma ele não degradou essa rota rápido o suficiente para evitar que fosse sinalizado como zumbi. (BTW realmente não é, veja a seguir ...)

Isso causou um problema temporário que se resolveu após alguns minutos (o que é totalmente inaceitável). Porque Hal lamp decide enviar um relatório de atributo, para o qual não recebe um APS ACK e, portanto, inicia um processo Route Request . Só agora, depois de concluído, deConz muda sua rota para Hal lamp e a comunicação é retomada normalmente.

Eu me pergunto quanto tempo teria demorado se a luz não decidisse enviar uma mensagem para deConz. (Observe que, em minha rede, estou executando as luzes IKEA com relatórios regulares de atributos para clusters On / Off e Level a cada 5 minutos)

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

Sua descrição parece com o que eu experimento. Tenho uma rede muito melhor (conbee 1) com fw mais recente. Mas ainda obtém lâmpadas que não respondem, que depois de algum tempo ficam responsivas novamente.
Não executo nenhum comando ou configuração extra ordinária do que o Home Assistant e minha programação normal para lâmpada. Embora, as lâmpadas internas mudem durante o dia (liga / desliga ou brilho), enquanto as lâmpadas externas apenas mudam os tempos das árvores em um dia. Às vezes, as lâmpadas que não respondem voltam bem rápido e, se eu emitir um comando, elas respondem. Raramente, mas acontece, leva muito mais tempo ou tenho que desligar e ligar.

@djwlindenaar ótimo trabalho novamente. Muito obrigado! Você está compartilhando suas descobertas de bugs no IKEA FW com a IKEA?

@djwlindenaar :

Claro que aquela luz (IKEA) deveria se comportar e responder com uma mensagem de falha, mas não o faz e não podemos mudar isso.

Bem, eu não tenho. Talvez @manup possa comentar sobre a taxa de sucesso de fazer isso, pois acredito que ele tentou entrar em contato com a IKEA.
Além disso, não estou usando o firmware mais recente.

Talvez entrar em contato com laboratórios de silício seja uma ideia melhor, já que é nisso que se baseia o material da IKEA. Não tenho certeza se os bugs têm origem no código Ember ou na personalização IKEA ...

@djwlindenaar Você também pode tentar https://www.reddit.com/user/TRADFRI Eles são muito ativos lá.

@manup Alguma novidade para o firmware do Conbee II?

depois de fazer o downgrade do firmware para 0x264a0700 não consigo mais me conectar ao Conbee II. Tentei fazer o downgrade para 0x264a0700 e alguns firmwares muito antigos também, o flash funciona bem, mas não consegue se conectar. Algum conselho sobre como reiniciar o stick Conbee II?

@manup alguma atualização? Devo procurar algo diferente de deConz ou está em andamento para resolver os problemas? Por favor, dê um sinal de vida 🤗

Eu só desejo que meu Conbee II funcione novamente depois de tentar o firmware de teste ...

@djwlindenaar Alguma atualização de sua parte? Ainda é uma rede estável com suas correções?

É bom ver que seu PR foi mesclado por @manup :)

@djwlindenaar Alguma atualização de sua parte? Ainda é uma rede estável com suas correções?

É bom ver que seu PR foi mesclado por @manup :)

@ JBS5 Estou meio satisfeito com a situação.

Claramente melhorou para minha rede. No entanto, ainda vejo os bugs nas luzes IKEA confundindo deCONZ às vezes.

O ponto principal é que às vezes um roteador IKEA descarta pacotes silenciosamente para uma determinada rota. Essa queda silenciosa é ilegal, mas deCONZ deve reagir a ela encontrando uma nova rota e não o faz.

Parece que as alterações no firmware deCONZ melhoram a situação, mas ainda há algo a acrescentar para essas situações. Com certeza, a ausência de um APS ACK deve desencadear imediatamente uma nova descoberta de rota.

Observe que @manup mencionou que o roteamento de origem poderia resolver o problema e acredito que isso seja especialmente verdadeiro neste caso, pois significa que não dependemos de roteadores na rede saberem como rotear para um nó remoto.

Eu acredito que o bug nas luzes IKEA é o resultado de alguma tabela não ser capaz de conter todas as rotas para nós remotos. Assim, descartando silenciosamente qualquer pacote para o qual não conheça a rota.

Obrigado @djwlindenaar.
Como @manup comentou aqui há algum tempo, você tem alguma pista se o roteamento de fonte mencionado é algo que será implementado?

Essa é uma mudança que precisa acontecer no firmware. Não sou afiliado à deCONZ, então não posso comentar sobre a probabilidade ...

@manup ?

Isso _está_ me fazendo pensar em mudar de deCONZ para minha rede doméstica ...

@djwlindenaar , quais alternativas você está considerando? Atualmente, não estou impressionado com a estabilidade do meu Conbee II.

Essa é uma mudança que precisa acontecer no firmware. Não sou afiliado à deCONZ, então não posso comentar sobre a probabilidade ...

@manup ?

Isso _está_ me fazendo pensar em mudar de deCONZ para minha rede doméstica ...

Zigbee2MQTT faz isso melhor ou você não quis dizer isso com a alternativa?

Sim. É isso aí.

Na verdade, não sei se isso funciona melhor. Observe que os firmwares usados ​​são fornecidos pelos fabricantes de chips. Esses firmwares não são de código aberto. Portanto, se eles tiverem um problema de firmware, você provavelmente terá menos suporte do que deCONZ ...
Por outro lado, a configuração desses firmwares é open source. Também já oferecem suporte ao roteamento de origem.

O fabricante do chip fornece apenas SDK, se você estiver inclinado a fazer o download do SDK, a versão de teste do Simplicity Studio e compilar o firmware você mesmo. O Z2M fornece patches de alterações feitas no firmware.

Olá juntos,

Desculpas por ter demorado tanto, aqui está o novo firmware para ConBee II que portou todas as correções de roteamento do firmware AVR 0x26350500. Além disso, ele melhorou a inicialização para evitar que o dispositivo fique silencioso. (Ainda estamos testando vários casos para corrigir o problema de inicialização para sempre).

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

Esta versão provavelmente fará parte do próximo lançamento deCONZ 2.05.76, o firmware ConBee I e RaspBee I versão 0x26350500 será criado para ser instalado por meio do botão de atualização.

Obrigado, @manup. Instalei esta versão na minha rede de teste e parece funcionar. Pelo menos dispositivos podem ser controlados, ao contrário de 52 e 53. A rede de teste é muito pequena para verificar se esta versão melhora o roteamento.

@manup deCONZ ainda não se conecta ao ConBee II, mesmo depois de atualizar o novo firmware. Tive esse problema por um tempo.

@manup Eu tentei piscar algumas vezes, mas continuo recebendo este erro:

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.

Este é o GCFFlasher 3.13?

Aqui está o registro da minha atualização:

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

Sim, era 3.13, funciona agora que reiniciei o sistema completo. Estranho, apenas reconectar o ConBee II não funcionou, mas reiniciar sim ...

Realmente estranho, a verificação do CRC é feita diretamente no aparelho, fico imaginando como isso pode acontecer.

@manup Eu até tentei atualizar o firmware antigo (várias versões) e 9600 baudrate. Todos resultaram no mesmo erro CRC.

Feliz que funcione agora, obrigado! Já vi um dispositivo problemático que se conectou à rede imediatamente. Espero que este firmware conserte alguns problemas :)

Ainda bem que agora funciona. Acabei de discutir com as faculdades sobre o bootloader. A versão 2.05 foi do primeiro lote de ConBee II em 2019 (cerca de 3500 pcs), esta versão é um pouco grosseira em alguns casos. Desde julho de 2019, enviamos 2.07 com algumas correções para o manuseio do watchdog.

Há um novo bootloader 3.x em desenvolvimento que já faz parte do RaspBee II, ele possui um design e protocolo mais robusto para corrigir os problemas da versão 2.x.

Atualmente não atualizamos o bootloader ConBee II com GCFFlasher. Não implementamos isso, pois há uma chance sutil de bloquear o dispositivo se a atualização do bootloader for abortada no momento em que a tabela de vetores de inicialização for modificada. Mas acho que podemos descobrir isso usando o manipulador de falhas físicas ARM. A ideia é que se a atualização do carregador de inicialização falhou e o gerenciador de falha de hardware é acionado, ele pode verificar se o carregador de inicialização é válido e se isso falhar, ele irá saltar para o aplicativo, onde a atualização do carregador de inicialização pode ser tentada novamente. Fizemos alguns testes com o gerenciador de falhas que parecem promissores, mas levará algum tempo até que esteja pronto para lançamento ao público.

Oi

Eu acendi o novo firmware hoje, mas ainda estou vendo logs como:

0x000D6FFFFE540E7C erro APSDE-DATA.confirm: 0xA7 na tarefa

Isso está relacionado?

0xA7 indica que um APS ACK não foi fornecido onde deveria. Acho que isso pode ter vários motivos.

Olá @manup , bom ouvir de você novamente. Você também tem algum tempo para discutir mais detalhadamente os problemas de roteamento restantes? E esperançosamente resolvê-los?

Oi de novo,

Ainda estou tendo problemas em que algumas luzes não reagem aos comandos (liga / desliga / escurece) e realmente não tenho ideia do motivo, pensei que tinha algo a ver com esse problema, mas agora não tenho certeza se é?

Ainda recebo muitos erros como o que postei há 4 dias.

contagem de código
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
total 76

Tenho 26 dispositivos postando esses erros HOJE, parece que piorou um pouco com 0x26580700

Alguém pode me dizer se isso está relacionado a esse problema de roteamento? ou eu deveria abrir um problema com o meu problema

Observe que parece que só acontece ao enviar fx. "ligado" para ~ 20 luzes "ao mesmo tempo"

Olá @manup , bom ouvir de você novamente. Você também tem algum tempo para discutir mais detalhadamente os problemas de roteamento restantes? E esperançosamente resolvê-los?

Olá @djwlindenaar sim, absolutamente, preciso acompanhar os comentários desta edição durante a semana. Se não me falha a memória, já havia mais ideias para melhorar as questões restantes.

Olá @djwlindenaar sim, absolutamente, preciso acompanhar os comentários desta edição durante a semana. Se não me falha a memória, já havia mais ideias para melhorar as questões restantes.

@manup , claro, acho que a questão principal ainda é que a deCONZ ainda é teimosa em manter uma rota que não funciona.
Eu acredito que as mensagens tanto do mau comportamento quanto da luz afetada continuam chegando (por alguma outra rota) e isso é mal interpretado pelo firmware como se a rota que não estava funcionando ainda estivesse funcionando. Além disso, o deCONZ tende a desistir das solicitações da camada APS muito rapidamente se nenhum ACK for recebido. Acho que deveria ser mais persistente e / ou iniciar uma descoberta de rota como parte do processo de nova tentativa.

Finalmente, agora estou convencido de que o roteamento de origem eliminaria o principal problema de roteadores com comportamento inadequado. Então, se você pudesse implementar isso, estaríamos em um lugar muito melhor. Estou pronto para ajudar / testar / depurar ...

Olá @manup , bom ouvir de você novamente. Você também tem algum tempo para discutir mais detalhadamente os problemas de roteamento restantes? E esperançosamente resolvê-los?

Olá @djwlindenaar sim, absolutamente, preciso acompanhar os comentários desta edição durante a semana. Se não me falha a memória, já havia mais ideias para melhorar as questões restantes.

Olá Manup, posso estar sequestrando este tópico, então desconsidere. Eu tenho um Conbee ii no Home Assistant e estava funcionando muito bem até cerca de um mês atrás. Nesse ponto, todos os meus sensores Xiaomi se tornariam automações de interrupção não confiáveis. Eu tenho alguns controladores fls-pp dresden que tenho há alguns anos. Eles são conectados a tiras de LED e usados ​​para desligar esporadicamente a rede, forçando uma reinicialização para religá-los. Eu finalmente removi todos eles da minha rede Conbee e imediatamente toda a rede ficou estável. Deixei-o alguns dias e reintroduzi um que funcionou por algumas horas e depois durante a noite minha rede Zigbee falhou e eu não pude colocar todos os meus interruptores / sensores on-line novamente até desligar o controlador de Dresden. Não tenho ideia do porquê, mas para mim, usar os controladores dresden agora quebra minha rede zigbee. Eu sou apenas um novato nisso, então não tenho certeza se isso é útil / relevante, mas eu estava procurando por algum comentário sobre isso e encontrei este tópico, então pensei em jogar minha experiência na mistura para o caso. Por enquanto, estou apenas removendo-os da minha rede - não vale a pena a dor de cabeça que eles estavam me dando!
Felicidades

Olá @djwlindenaar sim, absolutamente, preciso acompanhar os comentários desta edição durante a semana. Se não me falha a memória, já havia mais ideias para melhorar as questões restantes.

@manup , claro, acho que a questão principal ainda é que a deCONZ ainda é teimosa em manter uma rota que não funciona.
Eu acredito que as mensagens tanto do mau comportamento quanto da luz afetada continuam chegando (por alguma outra rota) e isso é mal interpretado pelo firmware como se a rota que não estava funcionando ainda estivesse funcionando. Além disso, o deCONZ tende a desistir das solicitações da camada APS muito rapidamente se nenhum ACK for recebido. Acho que deveria ser mais persistente e / ou iniciar uma descoberta de rota como parte do processo de nova tentativa.

Finalmente, agora estou convencido de que o roteamento de origem eliminaria o principal problema de roteadores com comportamento inadequado. Então, se você pudesse implementar isso, estaríamos em um lugar muito melhor. Estou pronto para ajudar / testar / depurar ...

Decidi mudar para zigbee2mqtt devido aos problemas de roteamento (o mais irritante é a necessidade de emparelhar novamente o Ikea / Xiaomi ocasionalmente). Postarei minhas descobertas aqui em algumas semanas ...

Depois de atualizar o firmware 0x26350500 em meu Conbee I (e atualizar deCONZ para 2.05.76) na segunda-feira passada, infelizmente um GU10 ficou offline.

No VNC é um pouco cinza:

Foscon:

É necessário energizar todas as luzes antes que elas aproveitem a correção de roteamento na nova versão do firmware?

@ JBS5 , não acho que seja necessário
Provavelmente é devido ao fato de que, embora melhorado, não estamos completamente livres de problemas de roteamento; veja meu (s) post (s) anterior (es).

@djwlindenaar Obrigado. Compreendo.

Vale a pena, porque é o mesmo comportamento do firmware anterior:

Depois que o GU10 foi marcado como indisponível, ele ainda estava respondendo aos comandos do grupo. Depois de alguns dias, 2 dispositivos alimentados por bateria (sensor de movimento Aqara e detector de fumaça Xiaomi / Honeywell) também ficaram offline. O GU10 ainda estava respondendo aos comandos do grupo.

Depois de desligar e ligar o GU10, também os 2 dispositivos alimentados por bateria voltaram a ficar online imediatamente.
Então, depois que o GU10 ficou offline, demorou alguns dias até que um dispositivo alimentado por bateria usando o GU10 específico, já que o roteador também ficou offline.

@ JBS5 , sim, parece um comportamento típico. Na verdade, não há nada de errado com essa luz GU10. É que o deCONZ perdeu sua maneira de se comunicar diretamente com ele. Depois de algum tempo, isso também faz com que seus dispositivos finais fiquem offline, pois eles também não recebem nenhum feedback do deCONZ. Finalmente, quando o GU10 fica com falta de pacotes de rede, ele fica offline de verdade.

Provavelmente na fase em que ele ainda está respondendo aos comandos do grupo, você poderá desligar e ligar outro roteador, o que aparentemente está bom, e o GU10 se recuperará. Esse outro roteador não está funcionando bem e o deCONZ não está respondendo bem à situação.
Portanto, não fique com raiva do GU10;)

Olá @djwlindenaar sim, absolutamente, preciso acompanhar os comentários desta edição durante a semana. Se não me falha a memória, já havia mais ideias para melhorar as questões restantes.

@manup , claro, acho que a questão principal ainda é que a deCONZ ainda é teimosa em manter uma rota que não funciona.

Hmm, as rotas devem ser degradadas e descartadas após várias transmissões com falha. O firmware mais recente degradará toda vez que um erro for relatado no APS-DATA.confirm (como erro de roteamento ou nenhum APS-ACK recebido).

Eu acredito que as mensagens tanto do mau comportamento quanto da luz afetada continuam chegando (por alguma outra rota) e isso é mal interpretado pelo firmware como se a rota que não estava funcionando ainda estivesse funcionando.

Essa é uma dica muito boa, vou verificar. explicaria por que as rotas não morrem. Acho que a única maneira sensata de avaliar uma rota deve ser baseada em transmissões bem-sucedidas.

Além disso, o deCONZ tende a desistir das solicitações da camada APS muito rapidamente se nenhum ACK for recebido. Acho que deveria ser mais persistente e / ou iniciar uma descoberta de rota como parte do processo de nova tentativa.

deCONZ não faz nenhuma descoberta de rota, tudo isso é feito pela pilha Zigbee. Podemos estender a REST-API para fazer novas tentativas para alguns comandos (como comandos de controle), mas esta é uma tentativa difícil.

A própria pilha pode ser configurada para fazer várias tentativas de APS até desistir. Mas isso pode atrapalhar muitas coisas e bloquear a fila por muito tempo. Acho que é melhor considerar isso mais refinado na REST-API.

Finalmente, agora estou convencido de que o roteamento de origem eliminaria o principal problema de roteadores com comportamento inadequado. Então, se você pudesse implementar isso, estaríamos em um lugar muito melhor. Estou pronto para ajudar / testar / depurar ...

Em teoria, o roteamento de origem é o Santo Graal para consertar tudo :)

Mas no mundo real, muitos gateways não o usam (usa algum?), O que significa que a maioria dos produtos não oferece suporte ao roteamento de origem ou não foi testado com ele. As chances de IMHO de fazê-lo funcionar em redes mistas são muito baixas. Mas já faz um tempo que eu comparei vários gateways nesse nível. Seria interessante ter uma visão geral atual sobre quais gateways usam qual abordagem de roteamento hoje em dia.

Seria interessante ter uma visão geral atual sobre quais gateways usam qual abordagem de roteamento hoje em dia.

Fico feliz em ajudar a testar / farejar a ponte Hue (geração 2 e geração 1), gateway innr, hub IKEA e gateway OSRAM Lightly Home, mas preciso de algumas informações sobre a configuração de teste a ser usada (quantos roteadores, dispositivos finais, distâncias entre eles , ...) e o que procurar.

Z-Stack FW é um exemplo de FW que oferece / usa roteamento de origem e o recomenda para redes maiores. Mas também vi alguns comentários de que não funciona muito bem para o CC2351 mais fraco.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Além disso, o deCONZ tende a desistir das solicitações da camada APS muito rapidamente se nenhum ACK for recebido. Acho que deveria ser mais persistente e / ou iniciar uma descoberta de rota como parte do processo de nova tentativa.

deCONZ não faz nenhuma descoberta de rota, tudo isso é feito pela pilha Zigbee. Podemos estender a REST-API para fazer novas tentativas para alguns comandos (como comandos de controle), mas esta é uma tentativa difícil.

A própria pilha pode ser configurada para fazer várias tentativas de APS até desistir. Mas isso pode atrapalhar muitas coisas e bloquear a fila por muito tempo. Acho que é melhor considerar isso mais refinado na REST-API.

A pilha faz algumas tentativas, lembro que tenta três vezes, se não me engano. Parece-me que você poderia adicionar um comportamento a esse trecho de código para invalidar a rota associada e tentar novamente uma ou duas vezes. Ou talvez você possa ter um retorno de chamada dentro da pilha para implementar esse comportamento. Isso deve provocar uma descoberta de rota, certo?

Finalmente, agora estou convencido de que o roteamento de origem eliminaria o principal problema de roteadores com comportamento inadequado. Então, se você pudesse implementar isso, estaríamos em um lugar muito melhor. Estou pronto para ajudar / testar / depurar ...

Em teoria, o roteamento de origem é o Santo Graal para consertar tudo :)

Mas no mundo real, muitos gateways não o usam (usa algum?), O que significa que a maioria dos produtos não oferece suporte ao roteamento de origem ou não foi testado com ele. As chances de IMHO de fazê-lo funcionar em redes mistas são muito baixas. Mas já faz um tempo que eu comparei vários gateways nesse nível. Seria interessante ter uma visão geral atual sobre quais gateways usam qual abordagem de roteamento hoje em dia.

Para ser honesto, não estou muito preocupado com esse problema. O comportamento dos roteadores no caso de roteamento de origem é extremamente simples. Especialmente se você comparar isso com o comportamento necessário para fazer o roteamento por conta própria. Basicamente, a única coisa que a camada NWK em um roteador deve fazer é verificar se o roteamento de origem está habilitado, ler o próximo salto do pacote e devolvê-lo à camada MAC. Sem tabelas, sem memória, nada a fazer de errado. Não tenho certeza se o comportamento básico é verificado para a certificação zigbee, mas com certeza é muito mais simples e há muito menos chance de bugs do que o roteamento normal.

Minha expectativa é que poucos coordenadores implementem, pois a complexidade está no firmware do coordenador. Além disso, muito poucas implementações de zigbee (consumidor) estão realmente focadas em redes maiores que se beneficiariam deste modo de roteamento.

Finalmente, eu diria que este é o melhor modo de roteamento para redes mistas, porque o roteamento normal depende das implementações individuais dos roteadores e especialmente das indicações de qualidade de link mal especificadas. Como o roteamento de origem é tão simples (= baixa chance de implementações ruins), eu confiaria nisso antes do comportamento de roteamento normal.

Então ... dito isso, estou pronto para testá-lo para você se você puder fornecer um firmware. Estou em um raspbee, meu farejador está pronto para ir.

Finalmente, eu diria que este é o melhor modo de roteamento para redes mistas, porque o roteamento normal depende das implementações individuais dos roteadores e especialmente das indicações de qualidade de link mal especificadas. Como o roteamento de origem é tão simples (= baixa chance de implementações ruins), eu confiaria nisso antes do comportamento de roteamento normal.

KISS - faz muito sentido para mim.

A pilha faz algumas tentativas, lembro que tenta três vezes, se não me engano. Parece-me que você poderia adicionar um comportamento a esse trecho de código para invalidar a rota associada e tentar novamente uma ou duas vezes. Ou talvez você possa ter um retorno de chamada dentro da pilha para implementar esse comportamento. Isso deve provocar uma descoberta de rota, certo?

Se entendi bem o código que já está acontecendo, o problema é que as rotas parecem se manter vivas devido a outros fatores (sob investigação).

Para ser honesto, não estou muito preocupado com esse problema. O comportamento dos roteadores no caso de roteamento de origem é extremamente simples. Especialmente se você comparar isso com o comportamento necessário para fazer o roteamento por conta própria. Basicamente, a única coisa que a camada NWK em um roteador deve fazer é verificar se o roteamento de origem está habilitado, ler o próximo salto do pacote e devolvê-lo à camada MAC. Sem tabelas, sem memória, nada a fazer de errado. Não tenho certeza se o comportamento básico é verificado para a certificação zigbee, mas com certeza é muito mais simples e há muito menos chance de bugs do que o roteamento normal.

Só posso falar pelos produtos baseados em BitCloud que comprei através da certificação (reatores FLS). No processo de certificação, eles nunca foram testados para roteamento de origem. Não tenho certeza se ele foi habilitado na pilha em tempo de compilação. Observe que a maioria das pilhas são configuradas para serem compiladas com os recursos mínimos necessários para um espaço seguro.

Minha experiência pessoal com recursos raramente usados ​​/ testados, não importa o quão simples sejam em teoria, é que eles sempre têm bugs. Por exemplo, para o FLS, tivemos que corrigir muitos bugs no aplicativo de pilha BitCloud de exemplo. Eu sei que a Philips também fez muitas melhorias na pilha do BitCloud para alguns de seus produtos.

Minha expectativa é que poucos coordenadores implementem, pois a complexidade está no firmware do coordenador. Além disso, muito poucas implementações de zigbee (consumidor) estão realmente focadas em redes maiores que se beneficiariam deste modo de roteamento.

A complexidade precisa ser implementada no plugin deCONZ REST-API ou em um novo plugin do roteador, uma vez que o firmware não tem visão suficiente sobre toda a topologia da rede nem o espaço flash. Para esse propósito, deCONZ::ApsDataRequest poderia ser estendido com uma opção de rota de origem na forma de std::vector<quint16> contendo os endereços nwk de uma rota.

Não tenho uma boa visão geral da complexidade que isso traz, que atualmente é tratada pelo roteamento de malha. As seguintes tarefas devem ser consideradas no mínimo e em escala:

• Consulta recursiva da topologia da rede (Mgmt_Lqi_req). Essa é a mais fácil, já funciona para roteamento de malha e pode ser adaptada para rotas de origem.
• Os nós estão desligados. Aqui, alguma lógica precisa selecionar rotas alternativas, o que também pode não funcionar se seus links também forem quebrados.
• Os nós são ligados novamente.
• Nós mudando o endereço nwk.
• Dispositivos finais mudando de pais.
• Unindo dispositivos finais, em redes multi-hop não conhecemos o pai sem consultar a rede.

O que ainda não sabemos:

• Todos os roteadores oferecem suporte ao roteamento de origem?
• Existem gateways comerciais que usam roteamento de origem? Aqui, precisamos detectar o tráfego e examinar os cabeçalhos NWK que contêm as rotas de origem e têm os respectivos sinalizadores definidos.
• Para os dispositivos que oferecem suporte ao roteamento de origem, ele funciona bem?

Só posso falar pelos produtos baseados em BitCloud que comprei através da certificação (reatores FLS). No processo de certificação, eles nunca foram testados para roteamento de origem. Não tenho certeza se ele foi habilitado na pilha em tempo de compilação. Observe que a maioria das pilhas são configuradas para serem compiladas com os recursos mínimos necessários para um espaço seguro.

Não estou familiarizado como isso funciona, mas as pilhas também não são certificadas?

Minha experiência pessoal com recursos raramente usados ​​/ testados, não importa o quão simples sejam em teoria, é que eles sempre têm bugs. Por exemplo, para o FLS, tivemos que corrigir muitos bugs no aplicativo de pilha BitCloud de exemplo. Eu sei que a Philips também fez muitas melhorias na pilha do BitCloud para alguns de seus produtos.

Minha expectativa é que poucos coordenadores implementem, pois a complexidade está no firmware do coordenador. Além disso, muito poucas implementações de zigbee (consumidor) estão realmente focadas em redes maiores que se beneficiariam deste modo de roteamento.

A complexidade precisa ser implementada no plugin deCONZ REST-API ou em um novo plugin do roteador, uma vez que o firmware não tem visão suficiente sobre toda a topologia da rede nem o espaço flash. Para esse propósito, deCONZ::ApsDataRequest poderia ser estendido com uma opção de rota de origem na forma de std::vector<quint16> contendo os endereços nwk de uma rota.

Eu não entendo essa afirmação. O roteamento de origem é completamente controlado no nível NWK da pilha. A pilha do bitcloud deve ter algum sinalizador de tempo de compilação (ou menos provável de tempo de execução) para habilitar o roteamento de origem. Existe uma tabela de rotas fonte que é mantida atualizada pela pilha, baseada nas mensagens do Registro de Rota que já estão em nossa rede devido ao MTORR enviado pelo coordenador a cada poucos minutos.

• Basicamente, para cada dispositivo da rede a rota para o coordenador é conhecida por meio de MTORRs
• O coordenador conhece cada rota (completa) para cada dispositivo através das mensagens do Registro de Rota. Nenhuma análise é necessária, apenas uma cópia da mensagem RR na tabela de rota de origem

Veja a especificação do zigbee, capítulo 3.6.3.5.4 e capítulo 3.6.3.3

Não tenho uma boa visão geral da complexidade que isso traz, que atualmente é tratada pelo roteamento de malha. As seguintes tarefas devem ser consideradas no mínimo e em escala:

* 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.

Acredito que tudo isso seja tratado pela camada NWK dentro da pilha do bitcloud. Deve ser tão simples quanto ajustar alguns sinalizadores de tempo de compilação (semelhante a habilitar o comportamento MTOR)

O que ainda não sabemos:

* Do all routers support source routing?

Eu esperava que sim, uma vez que isso faz parte da especificação básica do zigbee da camada NWK. Não tenho certeza, mas não vi nenhum comentário de que o suporte ao roteamento de origem seja opcional. É semelhante ao comportamento do MTOR, que já usamos em nossa rede.

* 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.

Não conheço este, também não sabe o que isso nos dirá?

* For the devices which support source routing, how well does it work?

Se você pudesse construir um firmware com o roteamento de origem habilitado, aprenderemos rapidamente. Deve haver apenas alguns sinalizadores de tempo de compilação para habilitá-lo no bitcloud.

Zigbee2MQTT também está habilitado para alguns firmwares de coordenador e eu ainda não (após uma rápida pesquisa no Google) encontrei nenhum problema com roteadores específicos que não funcionam bem com o roteamento de origem habilitado.

Não estou familiarizado como isso funciona, mas as pilhas também não são certificadas?

Sim, mas durante a certificação são habilitadas configurações específicas que podem não ser habilitadas nos produtos posteriormente.

Eu não entendo essa afirmação. O roteamento de origem é completamente controlado no nível NWK da pilha. A pilha do bitcloud deve ter algum sinalizador de tempo de compilação (ou menos provável de tempo de execução) para habilitar o roteamento de origem. Existe uma tabela de rotas fonte que é mantida atualizada pela pilha, baseada nas mensagens do Registro de Rota que já estão em nossa rede devido ao MTORR enviado pelo coordenador a cada poucos minutos.

Basicamente, para cada dispositivo da rede a rota para o coordenador é conhecida por meio de MTORRs
O coordenador conhece cada rota (completa) para cada dispositivo através das mensagens do Registro de Rota. Nenhuma análise é necessária, apenas uma cópia da mensagem RR na tabela de rota de origem

Veja a especificação do zigbee, capítulo 3.6.3.5.4 e capítulo 3.6.3.3

Ah, você está certo, boba, eu de alguma forma interpretei mal com descoberta de nó geral (facepalm).
A pilha pode de fato descobrir muitas coisas devido aos comandos de registro de rota, mas já me deparei com um caso em que nenhum foi enviado, veja abaixo.

Hoje eu tentei muitas configurações, parece que o roteamento de origem funciona meio que, mas apenas quando o roteamento em malha está desabilitado e para dispositivos que enviam comandos de registro de rota antes.

Meu sensor de movimento Philips Hue causa problemas e envia solicitações de endereço NWK de transmissão para obter o endereço NWK do gateway. Neste caso, nenhum quadro de registro de rota foi enviado prioritariamente (acho que por causa da transmissão). Como o roteamento mesh foi desabilitado, o gateway não iniciou uma descoberta de rota e, portanto, a comunicação com o sensor não foi estabelecida.

Quando o roteamento em malha é habilitado próximo ao roteamento de origem, parece que o roteamento de origem não é mais usado, embora ambos estejam habilitados.

Preciso fazer mais testes, acho que a descoberta de rota de malha deve ser evitada quando já houver entradas de registro de rota no cache de rota. O código é bastante complexo, preciso me aprofundar aqui.

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

Aqui está o firmware que possui o roteamento de malha e fonte habilitado (tamanho da tabela de registro de rota de 32). Você pode tentar, mas como mencionado em minha fonte de rede menor, o roteamento não foi acionado nessa configuração.

Estou no raspbee I, então não posso testar esse. Você poderia criar um para isso também?
Estou me perguntando se poderíamos contornar esse problema com uma espécie de rota estática que possamos carregar para o firmware na inicialização ou talvez com base em alguma outra informação.
Além disso, você reparou este dispositivo após a mudança para o roteamento de origem? Querendo saber se há alguma interação necessária para um dispositivo final reconhecer MTOR e o roteamento de origem está em uso. É claro que eles não recebem as mensagens MTOR de transmissão quando o receptor está desligado.
A propósito, eu vi meus dispositivos finais Xiaomi enviarem o registro da rota na minha detecção ...

Eu conduzi acima do firmware executado durante a noite. Parece que o roteamento de origem também é usado com o roteamento em malha habilitado, mas muito raramente. De ca. 2 milhões de pacotes apenas <5 usaram uma rota de origem.

Estou no raspbee I, então não posso testar esse. Você poderia criar um para isso também?

Não tenho certeza, preciso verificar a outra configuração de pilha usada por ConBee I e RaspBee I, se possível.

Estou me perguntando se poderíamos contornar esse problema com uma espécie de rota estática que possamos carregar para o firmware na inicialização ou talvez com base em alguma outra informação.

Sim, acho que deveria ser possível injetar rotas no cache de rotas de alguma forma. Mas quando voltarmos às minhas preocupações mencionadas acima, para manter as rotas. De qualquer forma, para fins de teste e redes fixas, seria uma maneira útil de configurar o roteamento.

Além disso, você reparou este dispositivo após a mudança para o roteamento de origem? Querendo saber se há alguma interação necessária para um dispositivo final reconhecer MTOR e o roteamento de origem está em uso.

Não, acabei de atualizar o firmware, sem reparo - as rotas de origem foram estabelecidas logo após o recebimento dos comandos de registro de rota.

A propósito, eu vi meus dispositivos finais Xiaomi enviarem o registro da rota na minha detecção ...

A IKEA parece se encaixar aqui também, eu gostaria de fazer mais testes com dispositivos Philips e de outras marcas para obter mais detalhes de como vários dispositivos podem ser usados ​​com roteamento de fonte.

Eu também poderia intervir para testar se podemos fazer funcionar para o Raspbee.

Eu conduzi acima do firmware executado durante a noite. Parece que o roteamento de origem também é usado com o roteamento em malha habilitado, mas muito raramente. De ca. 2 milhões de pacotes apenas <5 usaram uma rota de origem.

Interessante! Seria bom obter uma visão da lógica de tomada de decisão quando uma rota de origem é usada e se ela pode ser influenciada / ajustada de alguma forma.

Estou no raspbee I, então não posso testar esse. Você poderia criar um para isso também?

Não tenho certeza, preciso verificar a outra configuração de pilha usada por ConBee I e RaspBee I, se possível.

Seria ótimo...

Estou me perguntando se poderíamos contornar esse problema com uma espécie de rota estática que possamos carregar para o firmware na inicialização ou talvez com base em alguma outra informação.

Sim, acho que deveria ser possível injetar rotas no cache de rotas de alguma forma. Mas quando voltarmos às minhas preocupações mencionadas acima, para manter as rotas. De qualquer forma, para fins de teste e redes fixas, seria uma maneira útil de configurar o roteamento.

Acordado

Além disso, você reparou este dispositivo após a mudança para o roteamento de origem? Querendo saber se há alguma interação necessária para um dispositivo final reconhecer MTOR e o roteamento de origem está em uso.

Não, acabei de atualizar o firmware, sem reparo - as rotas de origem foram estabelecidas logo após o recebimento dos comandos de registro de rota.

Querendo saber se isso ajudaria para o dispositivo Philips ...

Olá pessoal, estou rodando o firmware Z2M Source Routing há 24 horas (permite apenas 5 conexões diretas). Tenho cerca de 35 dispositivos. Funciona bem, mas notei que os dispositivos Hue precisam de um ciclo de energia para reconectar depois que mudei do FW padrão para o firmware SR. Ikea e Xiaomi se reconectaram automaticamente. Talvez isso possa explicar partes do comportamento do Hue que você está vendo?

Oi,
Testei novamente minha lâmpada TRADFRI E14 WS opal 400lm com firmware ikea 2.3.050 e a versão beta e o firmware mais recente do Conbee I. Posso confirmar as lâmpadas e a comunicação melhorou. Recuperar cenas, ligar / desligar, aumentar e diminuir o brilho agora funcionam melhor, mas ainda há um problema.

Os problemas documentados aqui # 2518 foram resolvidos em sua maioria. Parece que os comandos de grupo (fora do phoscon gui) funcionam ainda melhor. # 2518 fechado

Percebi ainda que a troca de TC às vezes precisa ser acionada mais de uma vez para o sucesso se trocada manualmente, não por cena.

Um novo problema # 2892 que aparece é que se dentro de um grupo uma cena é recuperada e todas as lâmpadas pertencentes estão sendo ligadas (devido à cena) e, posteriormente, outra cena naquele grupo com apenas algumas lâmpadas acesas (definido pela cena) é lembrado, as lâmpadas "indesejadas" que deveriam desligar permanecem acesas.
Além disso, se você desligar o grupo, apenas as lâmpadas da cena definida no momento desligam e as outras anteriores (cena anterior do grupo) permanecem ligadas. Eles precisam de vários comandos off antes de partir.
O problema é descrito aqui, mas está na API com certeza, pois não faz nenhuma diferença se usar o Phoscon ou a própria api. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

observação adicional: usando a versão mais recente do ikea fw 2.3.050 em 20.5.2020

Versão de lançamento: 1.12.1
20 de maio de 2020
Novos recursos e mudanças em acessórios:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Corrigido o estado ligado desligado após a atualização OTA

Obrigado por sua melhoria contínua e trabalho despendido.

@manup , alguma novidade para a versão do firmware da rota de origem do conbee I? Estou ansioso para testar isso :)

@manup , alguma novidade para a versão do firmware da rota de origem do conbee I? Estou ansioso para testar isso :)

Minha primeira tentativa de habilitá-lo terminou em uma terrível confusão de erros de tempo de compilação: / Ainda não descobri qual é a causa e espero fazer com que compile de alguma forma.

@manup , alguma novidade para a versão do firmware da rota de origem do conbee I? Estou ansioso para testar isso :)

Minha primeira tentativa de habilitá-lo terminou em uma terrível confusão de erros de tempo de compilação: / Ainda não descobri qual é a causa e espero fazer com que compile de alguma forma.

Hmmmm não parece ótimo ... @manup , adoraria ajudar, mas não tenho acesso a esse código.

@manup , algum progresso?

@manup , pssst! 😁

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Ainda acontecendo. @manup algum progresso e / ou atualização sobre este problema?

@djwlindenaar @ JBS5 Pedi uma atualização ao @manup .

Sim, ainda é um problema - embora muito menos do que antes.

Quais são as novidades sobre o assunto?

Eu tenho cerca de 20 GU10 de espectro branco (primeira geração) conectado a uma ponte Hue e como parte da minha racionalização de rede zigbee, eu queria migrar todos os meus dispositivos para Deconz.

O matiz é bastante estável, mas as luzes ainda ficam desligadas de vez em quando (por exemplo, uma vez por semana uma luz fica desligada). Só preciso reiniciar as lâmpadas para reanimá-los.

Deconz é mais ou menos estável?

Não Deconz não é mais estável, eu também tenho cerca de 40 lâmpadas Ikea e às vezes algumas ficam offline

@salopette Eu não tenho essa experiência. Você se importaria de abrir uma edição separada? Algum registro?

@Mimiix Este problema é sobre luzes que

O mesmo aqui. As luzes ainda ficam desligadas de vez em quando. Mas melhorou muito com o tempo. Quando comecei a usar o deCONZ em 2018, tive que dar energia às minhas luzes ikea quase diariamente. Costumo ter esse problema com um painel FLOALT, mas esta também é a luz mais distante do meu Conbee Stick.

@ JBS5 Porque não sabemos nada sobre a configuração deste usuário. Sem versão, sem registros, sem informações sobre a configuração. Não estamos em posição de determinar se o problema dele está relacionado a isso.

Adicionar comentários sem qualquer informação não está ajudando neste caso. É por isso que quero edições separadas para termos uma visão geral melhor.

Certa vez, estou pedindo a @manup em particular para examinar isso e priorizá-lo.

@djwlindenaar está se aprofundando nisso. Duvido que inspecionar a configuração de outro usuário possa fazer qualquer coisa sobre um problema que parece existir em geral com as luzes do ikea. Eu preferiria me concentrar na investigação existente do que iniciar outra.

Aviso geral:

Acabei de falar com @manup em particular sobre isso. Ele me disse o seguinte:

`` `Que o firmware receberá uma atualização em relação aos problemas de roteamento, e a nova rede deve ajudar a recriar os problemas (o que não era possível antes).
Meu plano é que este próximo firmware esteja disponível nas próximas 2-3 semanas.

Algumas alterações já foram feitas, mas ainda não são públicas.
`` `

Manterei vocês todos informados.

Aviso geral:

Acabei de falar com @manup em particular sobre isso. Ele me disse o seguinte:

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.

Manterei vocês todos informados.

3 semanas depois, alguma atualização sobre isso?

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)

Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)

Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)

Qual é o ETA agora, as 2-3 semanas se passaram

@lubbertkramer Por favor, seja razoável aqui, o bot obsoleto era uma piada. A única promessa que @Mimiix fez anteriormente é compartilhar atualizações assim que algumas estiverem disponíveis, então é perfeitamente válido perguntar sobre o status atual. Agora, para o ETA, nada foi prometido e eu entendo que nada será, pois isso é algo complexo. Como eu sei manup quando falo de coisas desagradáveis, infelizmente não é nada que possa ser resolvido em um dia, só aparece depois de um tempo considerável ou desenvolve alguns efeitos colaterais imprevistos.

Então, nesse sentido, por favor, seja paciente e deixe os caras trabalharem nisso (ainda é tempo de férias, a propósito). Falando no próximo lançamento, demora 1,5 semanas para levantar a mão e pedir novidades.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)

Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Problemas de reinicialização não estão relacionados a este problema, eu acho?
E sobre as alterações de roteamento e os aprimoramentos de depuração mencionados? Essas melhorias de depuração estão relacionadas a este problema?

E essas mudanças de roteamento são baseadas nas descobertas do @djwlindenaar ou o @manup já pode ser mais específico?

@lubbertkramer Por favor, seja razoável aqui, o bot obsoleto era uma piada. A única promessa que @Mimiix fez anteriormente é compartilhar atualizações assim que algumas estiverem disponíveis, então é perfeitamente válido perguntar sobre o status atual. Agora, para o ETA, nada foi prometido e eu entendo que nada será, pois isso é algo complexo. Como eu sei manup quando falo de coisas desagradáveis, infelizmente não é nada que possa ser resolvido em um dia, só aparece depois de um tempo considerável ou desenvolve alguns efeitos colaterais imprevistos.

Então, nesse sentido, por favor, seja paciente e deixe os caras trabalharem nisso (ainda é tempo de férias, a propósito). Falando no próximo lançamento, demora 1,5 semanas para levantar a mão e pedir novidades.

Eu acho que é mais do que razoável fazer com que as pessoas cumpram comunicações ou promessas sem fazer "piadas" quando 2-3 semanas se passaram por 3 semanas sem acompanhamento. Os usuários que investigaram muito e responderam aqui já se mudaram por falta de acompanhamento / comunicação.

Então, de volta ao assunto, quais são as informações mais recentes sobre este assunto?

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)

Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)

Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.

Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.

_Seja a mudança que você deseja ver neste mundo_

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.

Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.

_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.

As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.
_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.

As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter suas emoções sob controle. Eu entendo sua raiva, mas ser desrespeitoso não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.

Se você quiser começar um problema para reclamar, por favor, fique à vontade. Apenas não faça isso nesta edição.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.
_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.
As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter suas emoções sob controle. Eu entendo sua raiva, mas ser desrespeitoso não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.

Se você quiser começar um problema para reclamar, por favor, fique à vontade. Apenas não faça isso nesta edição.

O único constrangimento nesta questão é manup e Dresden obviamente não é capaz de consertar este problema. O Conbee é um produto comercial e com isso vêm responsabilidades. É por isso que muitos de nós já trocamos o deCONZ / Conbee pelo chip TI e Z2M, que tem funcionado perfeitamente desde então.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.
_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.
As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter suas emoções sob controle. Eu entendo sua raiva, mas ser desrespeitoso não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.

Se você quiser começar um problema para reclamar, por favor, fique à vontade. Apenas não faça isso nesta edição.

E novamente, você não está respondendo ou atualizando o status que é solicitado muitas vezes e a única coisa que você está fazendo é prosseguir com uma discussão offtopic onde você já poderia ter feito uma atualização conforme solicitado no final de cada postagem. Você está se gabando de conexões / convites diretos nas reuniões de desenvolvimento, portanto, você deve estar atualizado sobre o status desse problema e pode atualizar todos os usuários leitores aqui.

Então, mais uma vez, poste uma atualização ou pare de postar offtopic, acho que é seu trabalho como moderador da comunidade, em vez de manter viva a discussão offtopic :)

Aviso geral:

Acabei de falar com @manup em particular sobre isso. Ele me disse o seguinte:

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.

Manterei vocês todos informados.

As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento, o que nós, usuários, podemos esperar?

Um novo reliese está para chegar em menos de uma semana. Sugiro manter a calma
e espere para ver o que as novas mudanças trarão

Tenho muitos tradfri trabalhando sem problemas por mais de um ano.
Recentemente, comecei a ter problemas com apenas uma das minhas luzes Tradfri
começou a cair e se conectar à malha a cada 15 minutos. 15min
alcançável, 15 min não alcançável. Fiz muitos testes para encontrar o problema.
Adivinha o quê .... o problema era? Não era de deCONZ, mas meu WiFi
repetidor agendar um resently colocado nele.

Não tenha tanta certeza de que os problemas estão sempre relacionados a DECONZ, às vezes não.

No domingo, 6 de setembro de 2020, 11h38, lubbertkramer [email protected] escreveu:

@ JBS5 https://github.com/JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto
aqui ;)
Pmed @manup https://github.com/manup esta manhã novamente. Tenho o
seguinte resposta:

Tenho rastreado o firmware nos últimos dias para investigar os problemas de reinicialização e encontrei alguns bugs desagradáveis.
Ele também conterá algumas mudanças de roteamento, espero que isso seja divulgado no próximo lançamento.

Os aprimoramentos de depuração seguirão após a próxima versão estável.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles te segurem
a essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando este problema já está
ativo desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden
aja como tal ou deixe apenas @manup https://github.com/manup lidar com isso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim.
Eu não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para conseguir coisas
classificado como eu tenho uma conexão direta. O bot obsoleto que uso para rastrear
problemas e recebo a notificação. Espero que o Manup volte para mim e
se o tempo passou, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fez o que eu fiz para o
comunidade, você saberia melhor do que isso. Além disso, para adicionar isso, não é isso
Não tive outras coisas para fazer na vida.
Seja a mudança que você quer ver neste mundo

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez
em vez de flamejar e mudar o flower power, deixe este problema como
spokeperson ou volte ao problema e às informações mais recentes.
As 2-3 semanas se passaram, as quais você postou como anúncio geral por
mais de 3 semanas agora, então qual é o acompanhamento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter seu
emoções sob controle. Eu entendo sua raiva, mas sendo desrespeitoso
não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e
Civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.

Se você quiser começar um problema para reclamar, por favor, fique à vontade. Só não
faça isso nesta edição.

E novamente, você não está respondendo ou atualizando o status que é solicitado
muitas vezes e a única coisa que você está fazendo é seguir em frente com um offtopic
discussão em que você já poderia ter feito uma atualização conforme solicitado no final
de cada postagem. Você está se gabando de conexões / convites diretos em
as reuniões de desenvolvimento, então você deve estar atualizado sobre o status de
este problema e poderia atualizar todos os usuários de leitura aqui.

Então, mais uma vez, poste uma atualização ou pare de postar offtopic :)

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 e @Mimiix Esperamos que o próximo lançamento
E como alguns dizem (e eu muitas vezes) é como funciona o suporte oficial do que os clientes com grandes problemas.
Não oficialmente: em 1 a 2 semanas o ZHA terá suporte oficial para Silabs EZSP em todas as versões de seus protocolos de pilha, então acho que um Sonoff Zigbee Bridge ou Elelabs-ELU013 / ELR023 é melhor investir e obter mais potência de RF e SoC do que os produtos DE e melhor suporte da comunidade.
Mas estou esperando pelo deCONZ REST-API versão 2 antes de permitir o RIP de todos os produtos DE.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.
_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.
As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter suas emoções sob controle. Eu entendo sua raiva, mas ser desrespeitoso não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.
Se você quiser começar um problema para reclamar, por favor, fique à vontade. Apenas não faça isso nesta edição.

E novamente, você não está respondendo ou atualizando o status que é solicitado muitas vezes e a única coisa que você está fazendo é prosseguir com uma discussão offtopic onde você já poderia ter feito uma atualização conforme solicitado no final de cada postagem. Você está se gabando de conexões / convites diretos nas reuniões de desenvolvimento, portanto, você deve estar atualizado sobre o status desse problema e pode atualizar todos os usuários leitores aqui.

Então, mais uma vez, poste uma atualização ou pare de postar offtopic, acho que é seu trabalho como moderador da comunidade, em vez de manter viva a discussão offtopic :)

Aviso geral:
Acabei de falar com @manup em particular sobre isso. Ele me disse o seguinte:

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.

Manterei vocês todos informados.

As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento, o que nós, usuários, podemos esperar?

Para responder diretamente à sua pergunta: Isso é o que @manup me disse depois que perguntei novamente. Não posso forçar ninguém a fazer algo. Vou perguntar de novo depois do fim de semana.

Este será um último aviso geral sobre seus comentários. O próximo comentário fora do tópico aqui é bloquear esse problema até que haja mais notícias.

@ JBS5 Ainda não há 3 semanas. Esperei pelo bot obsoleto aqui;)
Pmed @manup esta manhã novamente. Recebi a seguinte resposta:

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.

Eu pedi um ETA e ele está no momento.

Bem, você fez uma promessa para a comunidade, então é normal que eles cumpram essa promessa, 21 dias / 7 dias = 3 semanas
então é ridículo se esconder atrás do stalebot quando esta questão já está ativa desde fevereiro de 2019. Quando você quiser ser o porta-voz de Dresden, aja como tal ou deixe apenas @manup cuidar disso :)
Qual é o ETA agora, as 2-3 semanas se passaram

Não tenho problema em deixar esse problema para trás quando você age assim. Não sou de forma alguma um porta-voz, estou arriscando meu pescoço aqui para resolver as coisas, pois tenho uma conexão direta. O bot obsoleto que uso para controlar os problemas e recebo a notificação. Espero que o manup volte para mim e se o prazo passar, o bot obsoleto me ajuda a lembrar.
Então não, não é "chato" se esconder atrás disso. Se você fizesse o que eu fiz pela comunidade, você saberia melhor do que isso. Além disso, não é que eu não tenha tido outras coisas para fazer na vida.
_Seja a mudança que você deseja ver neste mundo_

Ninguém está pedindo ou forçando você a ser o intermediário como usuário, então, mais uma vez, em vez de inflamar e mudar o flower power, deixe este problema como porta-voz ou volte ao assunto e às informações mais recentes.
As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento?

Tudo que eu tinha era o que mencionei. Por favor, deixe-me aconselhá-lo a manter suas emoções sob controle. Eu entendo sua raiva, mas ser desrespeitoso não está ajudando. Eu não aceito qualquer tipo de fogo aqui. Mantenha-o no tópico e civil. Eu apenas explico quais são meus argumentos e por que faço as coisas da maneira que faço.
Se você quiser começar um problema para reclamar, por favor, fique à vontade. Apenas não faça isso nesta edição.

E novamente, você não está respondendo ou atualizando o status que é solicitado muitas vezes e a única coisa que você está fazendo é prosseguir com uma discussão offtopic onde você já poderia ter feito uma atualização conforme solicitado no final de cada postagem. Você está se gabando de conexões / convites diretos nas reuniões de desenvolvimento, portanto, você deve estar atualizado sobre o status desse problema e pode atualizar todos os usuários leitores aqui.
Então, mais uma vez, poste uma atualização ou pare de postar offtopic, acho que é seu trabalho como moderador da comunidade, em vez de manter viva a discussão offtopic :)

Aviso geral:
Acabei de falar com @manup em particular sobre isso. Ele me disse o seguinte:

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.

Manterei vocês todos informados.

As 2-3 semanas se passaram e você postou como anúncio geral há mais de 3 semanas, então, qual é o seguimento, o que nós, usuários, podemos esperar?

Para responder diretamente à sua pergunta: Isso é o que @manup me disse depois que perguntei novamente. Não posso forçar ninguém a fazer algo. Vou perguntar de novo depois do fim de semana.

Este será um último aviso geral sobre seus comentários. O próximo comentário fora do tópico aqui é bloquear esse problema até que haja mais notícias.

Isso é quase uma resposta, então quando eu li corretamente podemos esperar uma resposta mais detalhada no final desta semana, porque quase 4 semanas se passaram em vez das 2-3 que @manup comunicou através de você como um anúncio geral de que a atualização seria acessível

@Mimiix se você vê a necessidade de encerrar este problema que está quase aberto há dois anos com muitas informações de usuários muito solidários e dedicados sem uma solução, então não sou a pessoa que pode impedi-lo, isso é com você como comunidade porta-voz :)

@lubbertkramer Eu disse Lock, não feche.

E com isso, vou travar esse problema. Vou desbloquear em alguns dias ou quando o Manuel responder aqui.

Olá, novamente, acho que é mais do que hora para uma atualização sobre o problema.

Mas antes de mais nada, se alguém é culpado aqui sou eu e só eu. Eu entendo a frustração, mas não há espaço para ser indelicado aqui com

Atualização de progresso

(Antevisão para o próximo lançamento)

Tenho testado muito com o roteamento de origem e experimentei as descobertas deste problema e vários logs de sniffer. Gaste muito tempo para que o roteamento de origem "automático" funcione de maneira confiável, com base nos comandos de registro de rota recebidos. O que é basicamente o que a maioria das implementações com roteamento de sourcing faz - como o firmware de roteamento de origem para zigbee2mqtt. Isso funciona às vezes, mas parece haver uma dinâmica maior em como / se uma rota de origem é escolhida (e mantida) com base nos valores LQI / RSSI que um salto de registro de rota vê de seus vizinhos, em redes mistas isso é complicado porque as diferenças na pilha e hardware. A qualidade do link também pode ser bastante dinâmica se as pessoas se moverem entre os nós e as portas forem abertas e fechadas, o que infelizmente afeta o roteamento também.

Portanto, experimentei a ideia de configurar rotas de origem fixa em direção a um nó de destino. Em muitos casos, apenas uma parte da rede tem problemas de roteamento, aqui pode ser benéfico especificar uma rota de origem fixa onde:

• As rotas de origem podem ser especificadas opcionalmente por nó.
• Cada salto deve sempre ser alimentado.
• As posições de salto ao longo do caminho devem ser razoáveis. Em alguns casos, um usuário pode ter um plano melhor para onde os pacotes devem ser roteados do que o algoritmo automático é capaz de descobrir.

Para fazer isso, o protocolo do firmware foi estendido para fornecer opcionalmente uma rota de origem por solicitação APS. Não há limite de quantas rotas de origem podem ser configuradas, o firmware só precisa manter algumas na memória para as solicitações e o ACK.

deCONZ descobre automaticamente se cada salto na rota é alcançável e somente nesse caso usa a rota de origem.
Nos bastidores, as rotas de origem são configuradas com endereços MAC dos nós para serem resistentes a alterações de endereço NWK.

Criação de uma rota de origem fixa

• Na gui deCONZ, selecione todos os saltos enquanto segura CTRL (seleção múltipla), começando do coordenador (origem) até o nó de destino. Importante: deve haver pelo menos um salto entre a origem e o destino.
• Clique com o botão direito no nó de destino para abrir o menu de contexto.
• Selecione "Adicionar rota de origem".

Isso criará a nova rota de origem, visualizada pela linha azulada, as marcas finais vermelhas até o nó de destino.

(Em versões posteriores, será possível especificar rotas alternativas, mas preciso descobrir uma boa interface do usuário para isso.)

Para remover uma rota de origem: Selecione "Remover rota de origem" no menu de contexto do nó de destino.

A rota será usada para a próxima solicitação:

Isso funciona muito bem e permite a substituição manual do roteamento, se necessário, e também deve ser útil para testes.
Atualmente, isso só funciona quando configurado via GUI, mas deve estar disponível via REST-API mais tarde.

Isso vai consertar tudo?

Improvável, mas deve melhorar o roteamento para destinos (o roteamento nos próprios nós não pode ser configurado). Observe que as rotas de origem fixa são boas apenas para roteadores, uma vez que os dispositivos finais tendem a mudar o pai e a rota de origem não funcionaria mais; neste caso, o roteamento de origem automático pode funcionar melhor.

Quando isso será lançado?

Em breve, na próxima versão 2.05.81, tenho os seguintes itens (bastante leves) na lista de tarefas para a versão:

• Armazenar / restaurar rotas de origem no banco de dados.
• Corrigir o manuseio do contador de segurança NWK para consertar o backup entre diferentes ConBee / RaspBee e reiniciar o bug.
• Deixe o GCFFlasher verificar se o firmware está sendo executado após a atualização.

Assim, com @manup sua resposta, uma resposta foi dada. Por favor, permaneça no tópico e no assunto.

Olá, novamente, acho que é mais do que hora para uma atualização sobre o problema.

Atualização de progresso

(Antevisão para o próximo lançamento)

Tenho testado muito com o roteamento de origem e experimentei as descobertas deste problema e vários logs de sniffer. Gaste muito tempo para que o roteamento de origem "automático" funcione de maneira confiável, com base nos comandos de registro de rota recebidos. O que é basicamente o que a maioria das implementações com roteamento de sourcing faz - como o firmware de roteamento de origem para zigbee2mqtt. Isso funciona às vezes, mas parece haver uma dinâmica maior em como / se uma rota de origem é escolhida (e mantida) com base nos valores LQI / RSSI que um salto de registro de rota vê de seus vizinhos, em redes mistas isso é complicado porque as diferenças na pilha e hardware. A qualidade do link também pode ser bastante dinâmica se as pessoas se moverem entre os nós e as portas forem abertas e fechadas, o que infelizmente afeta o roteamento também.

Portanto, experimentei a ideia de configurar rotas de origem fixa em direção a um nó de destino. Em muitos casos, apenas uma parte da rede tem problemas de roteamento, aqui pode ser benéfico especificar uma rota de origem fixa onde:

• As rotas de origem podem ser especificadas opcionalmente por nó.
• Cada salto deve sempre ser alimentado.
• As posições de salto ao longo do caminho devem ser razoáveis. Em alguns casos, um usuário pode ter um plano melhor para onde os pacotes devem ser roteados do que o algoritmo automático é capaz de descobrir.

Para fazer isso, o protocolo do firmware foi estendido para fornecer opcionalmente uma rota de origem por solicitação APS. Não há limite de quantas rotas de origem podem ser configuradas, o firmware só precisa manter algumas na memória para as solicitações e o ACK.

deCONZ descobre automaticamente se cada salto na rota é alcançável e somente nesse caso usa a rota de origem.
Nos bastidores, as rotas de origem são configuradas com endereços MAC dos nós para serem resistentes a alterações de endereço NWK.

Criação de uma rota de origem fixa

• Na gui deCONZ, selecione todos os saltos enquanto segura CTRL (seleção múltipla), começando do coordenador (origem) até o nó de destino. Importante: deve haver pelo menos um salto entre a origem e o destino.
• Clique com o botão direito no nó de destino para abrir o menu de contexto.
• Selecione "Adicionar rota de origem".

Isso criará a nova rota de origem, visualizada pela linha azulada, as marcas finais vermelhas até o nó de destino.

(Em versões posteriores, será possível especificar rotas alternativas, mas preciso descobrir uma boa interface do usuário para isso.)

Para remover uma rota de origem: Selecione "Remover rota de origem" no menu de contexto do nó de destino.

A rota será usada para a próxima solicitação:

Isso funciona muito bem e permite a substituição manual do roteamento, se necessário, e também deve ser útil para testes.
Atualmente, isso só funciona quando configurado via GUI, mas deve estar disponível via REST-API mais tarde.

Isso vai consertar tudo?

Improvável, mas deve melhorar o roteamento para destinos (o roteamento nos próprios nós não pode ser configurado). Observe que as rotas de origem fixa são boas apenas para roteadores, uma vez que os dispositivos finais tendem a mudar o pai e a rota de origem não funcionaria mais; neste caso, o roteamento de origem automático pode funcionar melhor.

Quando isso será lançado?

Em breve, na próxima versão 2.05.81, tenho os seguintes itens (bastante leves) na lista de tarefas para a versão:

• Armazenar / restaurar rotas de origem no banco de dados.
• Corrigir o manuseio do contador de segurança NWK para consertar o backup entre diferentes ConBee / RaspBee e reiniciar o bug.
• Deixe o GCFFlasher verificar se o firmware está sendo executado após a atualização.

Obrigado pela resposta detalhada, acho que muitos de nós estamos esperando por uma resposta como a acima por causa de todo o trabalho árduo que a comunidade está fazendo para esse problema e você está fazendo como desenvolvedor.

Várias perguntas de acompanhamento que eu tenho:

• Quando o item acima estará disponível como uma atualização em beta / estável?

• Haverá uma diferença em como acima funcionará em relação ao conbee 1/2 e ao Raspbee ou será tudo igual?

• Para a atualização 2.05.81 você mencionou ter itens bastante (leves) na lista de tarefas, quando podemos esperar essa atualização (talvez seja uma ideia adicionar um roteiro para este git?)

Olá @lubbertkramer

Eu posso responder o número 1: a versão 2.05.81 seria esperada no dia 15 do mês (Windows build alguns dias depois). Coloquei isso no anúncio no início do Discord, mas percebi que não é o caso do Github. Vou adicionar isso ao readme! Foi mal!

Editar: fez uma solicitação de pull do arquivo readme.md. Não tenho certeza de como o canal estável está funcionando, o que precisa ser esclarecido um pouco.

Haverá uma diferença em como acima funcionará em relação ao conbee 1/2 e ao Raspbee ou será tudo igual?

Deve funcionar da mesma forma, agora transferi o código para RaspBee I / ConBee I e as rotas de origem são usadas lá da mesma maneira.

Atualmente, tenho um caso curioso em que um plugue repetidor IKEA está ativo, mas não deseja interagir com o resto da rede.
Os comandos enviados para ele (com e sem rotas de origem) são ignorados silenciosamente.

O repetidor envia seus quadros de status de link NWK, mas relatórios e lista de vizinhos vazia:

Os comandos do coordenador, bem como um sensor OSRAM do qual o repetidor é o pai são ignorados. O sensor, como muitos dispositivos Xiaomi, não tenta encontrar um novo pai automaticamente ... situação ruim:

Este cenário é executado há dois dias, não encontrei uma forma de recuperar o repetidor. Talvez um ciclo de energia do repetidor resolva o problema, mas vou mantê-lo assim por enquanto para ver se pode ser resolvido de alguma forma via ar.

Há algum problema com o repetidor USB Tradfri ou com o plugue Tradfri?

Nesse caso foi o plug, não tenho certeza se está na versão mais recente, preciso verificar isso mais tarde.

É possível verificar? Eu tenho 3 plugues Tradfri executando o FW mais recente sólido por cerca de 1,5 ano. Se eu começar a ter problemas com eles com o novo beta, terei que atrasar a atualização.

Obrigado!

Aqui estão os dados do cluster básico, observe que o problema ocorreu pela primeira vez há dois dias na minha rede doméstica que não tinha o novo firmware na época.

Parece que você está no FW mais recente como meus plugues. Espero que seja, por causa do antigo FW Ikea ...

A página da web com o log de alterações tradfri está fora do ar, para verificar o que o FW mais recente corrigiu.

Os arquivos de firmware mais recentes estão online agora:

ConBee II

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

RaspBee II

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

RaspBee I e ConBee I

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

• Eles têm o roteamento de origem habilitado com no máx. 32 rotas de origem, onde as entradas mais antigas são substituídas automaticamente por outras mais recentes. O valor provavelmente será aumentado em versões posteriores, mas já deve funcionar bem.
• Se houver uma rota de origem e uma entrada de rota "normal", a rota de origem será preferida. Isso não é padrão, mas parece funcionar melhor.
• O firmware tem melhorias gerais para robustez do protocolo serial.
• O ConBee II e o RaspBee II tiveram um tratamento de contador de frames aprimorado, para mitigar problemas em que, após um ciclo de energia, a rede poderia parecer perdida até que o contador de frames voltasse ao seu valor antigo.

@manup fez firmware para ConBee. Eu deixei cair version id de comando 0x0D ? Não estou mais recebendo resposta a este comando

@Adminiuga @manup Coisas sobre o firmware: Use # 3260.

Os arquivos de firmware mais recentes estão online agora:

ConBee II

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

RaspBee II

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

RaspBee I e ConBee I

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

• Eles têm o roteamento de origem habilitado com no máx. 32 rotas de origem, onde as entradas mais antigas são substituídas automaticamente por outras mais recentes. O valor provavelmente será aumentado em versões posteriores, mas já deve funcionar bem.
• Se houver uma rota de origem e uma entrada de rota "normal", a rota de origem será preferida. Isso não é padrão, mas parece funcionar melhor.
• O firmware tem melhorias gerais para robustez do protocolo serial.
• O ConBee II e o RaspBee II tiveram um tratamento de contador de frames aprimorado, para mitigar problemas em que, após um ciclo de energia, a rede poderia parecer perdida até que o contador de frames voltasse ao seu valor antigo.

Como faço para atualizar este firmware (eu uso a imagem deCONZ Docker do marthoc)?

Baixei o arquivo (ConBee II), mas as instruções de atualização manual não se aplicam à imagem deCONZ Docker do marthoc e o guia para deCONZ do marthoc não permite o uso de um firmware não incluído na imagem (e este arquivo não está listado como disponível).

Como faço para atualizar este firmware (eu uso a imagem deCONZ Docker do marthoc)?

Simplesmente conecto o dongle USB em um laptop Windows e o faço de lá e de volta ao meu Synology NAS quando terminar.

Como faço para atualizar este firmware (eu uso a imagem deCONZ Docker do marthoc)?

Simplesmente conecto o dongle USB em um laptop Windows e o faço de lá e de volta ao meu Synology NAS quando terminar.

Existe um utilitário do Windows para atualizar o firmware? Se sim, você poderia compartilhar o link?

Como faço para atualizar este firmware (eu uso a imagem deCONZ Docker do marthoc)?

Simplesmente conecto o dongle USB em um laptop Windows e o faço de lá e de volta ao meu Synology NAS quando terminar.

Existe um utilitário do Windows para atualizar o firmware? Se sim, você poderia compartilhar o link?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

Portanto, experimentei a ideia de configurar rotas de origem fixa em direção a um nó de destino. Em muitos casos, apenas uma parte da rede tem problemas de roteamento, aqui pode ser benéfico especificar uma rota de origem fixa onde:

• As rotas de origem podem ser especificadas opcionalmente por nó.
• Cada salto deve sempre ser alimentado.
• As posições de salto ao longo do caminho devem ser razoáveis. Em alguns casos, um usuário pode ter um plano melhor para onde os pacotes devem ser roteados do que o algoritmo automático é capaz de descobrir.

Isso vai consertar tudo?

Improvável, mas deve melhorar o roteamento para destinos (o roteamento nos próprios nós não pode ser configurado). Observe que as rotas de origem fixa são boas apenas para roteadores, uma vez que os dispositivos finais tendem a mudar o pai e a rota de origem não funcionaria mais; neste caso, o roteamento de origem automático pode funcionar melhor.

Só para esclarecer ... este novo firmware vai consertar (ou pelo menos melhorar) a desconexão aleatória dos dispositivos Ikea se eu não configurar manualmente nenhuma nova rota de origem estática? Ou a única maneira de se beneficiar dessa atualização é definir manualmente as rotas desses dispositivos que tendem a perder a conexão?

Sem as rotas de configuração manual, o roteamento de origem automático ocorre se os dispositivos os promoverem (como os dispositivos IKEA fazem).
Portanto, em comparação com a origem do firmware anterior, o roteamento será usado para esses dispositivos se essa rota for conhecida.

Se realmente ajuda permanecer aberto, seria bom se alguém que tinha problemas regulares com o firmware anterior pudesse relatar se algo mudou.

Em minhas redes de teste, o firmware funciona muito bem e as rotas de origem são usadas frequentemente, conforme indicado pelos logs do sniffer. Isso não significa muito, pois mesmo sem o roteamento de origem, minhas redes eram bastante sólidas.

Tenho 21 luzes (4 - 980lu WS, 17 - 1000lu WS), 3 plugues e 3 (5 botões) controles remotos redondos da Ikea. Todos eles nos últimos FWs da Ikea. Nunca experimentei instabilidade com eles nos últimos cerca de 1,5 ano. Nighter com qualquer uma das versões anteriores deCONZ ou FW, nem com a atual. Estou executando o 0,81 estável com o RaspBee FW 0x26370500 mais recente e também não tive problemas durante a última semana de uso.

Eu acho ... (talvez eu não esteja certo) Ikea não tem um problema geral, mas a configuração é específica. Existem muitos fatores diferentes que podem afetar seu comportamento e desempenho no deCONZ e em geral.

Acho que a maioria dos problemas ocorreu com as lâmpadas Ikea GU10. A estabilidade melhorou muito com o tempo, mas estava uma bagunça no final de 2018 quando comecei. Eu tive que ligar / desligar um dos 30 GU10 a cada duas semanas, em média, para o lançamento / firmware dos últimos três meses.

Acho que a maioria dos problemas ocorreu com as lâmpadas Ikea GU10. A estabilidade melhorou muito com o tempo, mas estava uma bagunça no final de 2018 quando comecei. Eu tive que ligar / desligar um dos 30 GU10 a cada duas semanas, em média, para o lançamento / firmware dos últimos três meses.

Poderia ser. O GU10 não recebeu atualização FW como outras luzes da Ikea, pelo que eu sei. Recentemente, nós o discutimos nos canais de discórdia. Um usuário executando luzes GU10 Ikea experimenta tal comportamento. Não importando o que tentamos, nada parece resolver seus problemas. Ele até compartilhou conosco que comprou um Ikea Tradfri Hub e também teve a mesma experiência ruim, mesmo com o Ikea Hub e a luz / s GU10.

Então, eu acho que é uma questão de tempo a Ikea lançar um novo FW para este tipo de luzes para talvez resolver / corrigir este problema ....

Gostaria de saber se @djwlindenaar já atualizou para o deCONZ e o firmware mais recentes e pode compartilhar suas experiências? :)

Na verdade, ainda não ... Ainda não achei tempo para atualizar. Além disso, não encontrei tempo para mudar para z2mqtt, então a boa notícia é que irei atualizar para o novo firmware e se houver algo a relatar, farei.

Se realmente ajuda permanecer aberto, seria bom se alguém que tinha problemas regulares com o firmware anterior pudesse relatar se algo mudou.

Eu atualizei para o firmware mais recente 2 dias atrás e, desde então, um dos meus interruptores de parede Xiaomi (ctrl_neutral2, 11-25-2017) alternou sozinho 3 vezes. Eu nunca tive esse problema antes.

Ele é conectado ao coordenador por meio de uma lâmpada Tradfri E27 CWS em 1.3.009.

Além disso, não estritamente relacionado a este problema, mas nunca consegui obter uma atualização OTA com Deconz (contêiner de comunidade).

Eu tenho as lâmpadas Tradfri:

• E27 CWS em 1.3.009
• E14 W em 1.2.214
• Dimmer sem fio em 1.2.248
• 17 * GU10 WS em 1.2.221

Posso ver os arquivos do Trafri OTA baixados, mas nada acontece. O que devo fazer?

Para referência, é assim que o contêiner é iniciado:

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 Isso não está relacionado a esse problema aqui afaik. Abra um problema separado. Acho que você deve postar no repositório de versões do Docker. https://github.com/marthoc/docker-deconz

Nota de moderação:

Antes que tudo se misture aqui, gostaria de definir um escopo aqui.

Qualquer coisa relacionada ao problema original: luzes IKEA que ocasionalmente perdem a conexão são permitidos neste problema.

Qualquer outro problema relacionado ao firmware pode ser postado aqui

Na verdade, ainda não ... Ainda não achei tempo para atualizar. Além disso, não encontrei tempo para mudar para z2mqtt, então a boa notícia é que irei atualizar para o novo firmware e se houver algo a relatar, farei.

@ JBS5 , seu gatilho ajudou;)

Acabei de instalar o firmware e o deCONZ .deb mais recente. Até agora posso confirmar que o roteamento de origem funciona, claro que nenhuma conclusão sobre a estabilidade ainda. Vou mantê-lo informado

ZigBee Network Layer Data, Dst: 0x0ea4, Src: DeConz
    Frame Control Field: 0x0608, Frame Type: Data, Discover Route: Suppress, Security, Source Route Data
    Destination: 0x0ea4[0x0ea4]
    Source: 0x0000[DeConz]
    Radius: 10
    Sequence Number: 190
    [Extended Source: dresden-_ff:ff:00:c4:9a (00:21:2e:ff:ff:00:c4:9a)]
    [Origin: 366]
    Source Route, Length: 2
        Relay Count: 2
        Relay Index: 1
        Relay 1: 0xc803[0xc803]
        Relay 2: 0xf1e5[0xf1e5]
    ZigBee Security Header

@ ReX1983 Veja como o plugin OTA está funcionando https://github.com/dresden-elektronik/deconz-ota-plugin e atualizando seus dispositivos.
Desculpe, mas é um problema de comunicação do dispositivo IKEA.

@ morfei1 @ peer69
Posso confirmar que não é causado apenas pelas lâmpadas GU10. Tive problemas de roteamento e perda de conexão por um longo tempo sem GU10 no meu sistema.

Tive alguns problemas iniciais após o lançamento do .82 com o novo firmware no meu conbee 1.
Mas agora, depois que a malha de rede se estabilizou e alguns ciclos de energia, ela está sólida como uma rocha nos últimos dias.

Como sou idiota, decidi atualizar para o firmware mais recente (OTAU) em todas as minhas lâmpadas para ter uma melhor linha de base para começar se houver problemas futuros. Me deseje sorte. Manterá vocês informados sobre o progresso.

@tubalainen você está usando um complemento HA?

@tubalainen você está usando um complemento HA?

Não, eu uso HA Core no Debian no docker - então eu também uso https://github.com/marthoc/docker-deconz pacote docker stand-a-lone. Ambos usam o arquivo .deb fornecido por dresten, portanto, devem funcionar de forma idêntica. Não tenho certeza se o plugin OTAU está incluído no add-on deconz HA ....

apenas contribuindo com minhas observações até agora;

Eu só tenho problemas com meu Ikea GU-10 (23 deles), e eu uso o assistente Home, que se conecta ao deconz (docker) através da API restante, e posso ver o HA disparando os eventos para deconz com sucesso.

Quando eu uso o HA para ligar, 17 lâmpadas, uma a uma (uma após a outra), talvez 3 das 17 lâmpadas acendam, mas o HA as vê como ligadas.
MAS, se eu fizer um grupo no deconz. coloque todas as luzes naquele grupo e diga ao HA para ligar aquele grupo, ainda não houve nenhum problema, todas as luzes estão acesas.

Usando o firmware: 0x26650700 não vi nenhuma melhoria (exceto por algum motivo, tive que emparelhar aquelas 17 lâmpadas e, mesmo depois de emparelhar, tive os mesmos problemas)

é uma limitação no resto-api talvez?

@MartinTerp , se você usar um único comando para cada dispositivo por vez, em vez de 1 comando para um grupo, ele falhará, talvez não todas as vezes, mas na maioria das vezes, dispositivos aleatórios que supostamente fazem algo não farão isso.

Minha solução para isso é um atraso de 5 segundos entre os comandos. Por exemplo
Se eu quiser desligar as luzes do meu quarto às 23:00 às bri: 127 e ct: 454, e também no meu corredor, dou 5 segundos de atraso para uma das salas. Se eu não colocar o atraso, ele irá falhar aleatoriamente ao completar o comando completo para um dos quartos ou talvez para ambos. Eu experimento muito com isso. É algo parecido com o bug da Ikea, ele não consegue mudar a cor e o brilho ao mesmo tempo.

Eu não sei o que exatamente é isso, um bug deconz, uma limitação do zigbee em geral ou um bug Ikea FW. Talvez seja minha falta de conhecimento de como funciona o zigbee, mas o atraso de 5s sempre funciona para mim.

Como regra geral, sempre uso: lixe o mínimo de comandos que puder de cada vez ou use um atraso. Assim, você mantém o canal limpo.

Se você precisa alternar muitos grupos / luzes de uma vez, como você percebeu, é sempre melhor criar um novo grupo phoscon, incluir esses grupos de luzes nele e enviar um único comando de grupo para eles. Você pode ter muitos grupos diferentes, incluindo a mesma luz. Não estamos limitados a apenas usar um grupo por luz. Se você não gosta de ter muitos grupos em Foscon, então o atraso é seu melhor amigo.

@ morfei1 Estou usando uma solução alternativa semelhante e funciona na maioria das vezes com um atraso de 5 segundos entre todos os comandos.
@MartinTerp Eu também tive esse problema com outros dispositivos além das luzes IKEA-Tradfri, por exemplo, os Smart Plugs e Light Strips OSRAM. Acho que é possível, embora o problema tenha sido causado por alguns erros do Tradfri-Lights que não encaminharam os comandos.

Mas não é para ser assim, certo?
no momento em que o script os ativa 1 por 1 com atraso de 1 segundo, ele DEVE ser capaz de lidar com isso?

@ morfei1 @MartinTerp

Eu também costumava usar atrasos + que envio comandos liga e desliga do assistente de casa duas vezes por automação acionada.

Agora removi os atrasos e os comandos de repetição desde 0,82.

Tenho certeza de que não é necessário um atraso de 5 segundos. Acho que isso não era necessário com alguma versão anterior, mas não apostaria nisso, pois minha rede cresceu desde então. Talvez 82 (não tentei com atraso reduzido ainda) ou versões futuras irão melhorar este comportamento.

@ morfei1 @githtz @tubalainen @martinterp

Poderíamos ter uma discussão sobre como atualizar os firmwares do dispositivo em outro lugar?

Não estamos tratando de atualizar o firmware?

Quando li corretamente a questão do envio de vários comandos, onde nem todos chegam é diferente. Este é provavelmente mais um problema com o agendador de tarefas.

Sugiro abrir um problema separado para isso, como "Nem todas as luzes reagem ao enviar comandos unicast para várias luzes".

O problema aqui é mais sobre quando as luzes estão completamente perdidas e não podem ser alcançadas, o que pode estar relacionado ao roteamento.

Editado por Mimiix

Editado por Mimiix

@inconsx @ ReX1983 Achei que estava claro em https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 e https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # issuecomment -696046160

Cumpra essas regras. Abra questões separadas, se desejar.

Então, aqui está meu feedback, eu atualizei para o firmware mais recente e a API deconz. Eu executo minha rede de HA.

Tenho cerca de 72 nós, a maioria deles são luzes IKEA GU10. Após a atualização, notei dois GU10 diferentes que "morreram" em dois dias diferentes, a única maneira de recuperá-lo é desligar e ligar novamente. O GU10 usa o acessório 1.2.217 e 1.2.221. Vou tentar atualizá-los todos para a mesma versão.

Tenho apenas 4 GU10, acho que são da primeira versão lançada, rodando na versão mais recente do ota. Nunca tive problemas com estes em termos de acessibilidade, apenas minhas cenas ficaram bagunçadas após a atualização do firmware light.

Acabei de ver uma das minhas lâmpadas IKEA TRADFRI E14 W op / ch 400lm Versão 1.2.214 parar de responder. Esta lâmpada já fez isso muitas vezes e em diferentes firmwares de deconz. No momento, estou usando deconz 26370500 e 2.05.82.

Tenho apenas 4 GU10, acho que são da primeira versão lançada, rodando na versão mais recente do ota. Nunca tive problemas com estes em termos de acessibilidade, apenas minhas cenas ficaram bagunçadas após a atualização do firmware light.

Você notou uma melhora na estabilidade com essas lâmpadas GU10 após a atualização para 2.3.050? Agora estou em 0x26650700 e desde a atualização para 2.3.050 (de 17 lâmpadas) parece que minha rede está muito mais estável. Os dispositivos não ficam offline durante a noite e meus botões / interruptores Aqara funcionam nas primeiras tentativas. Agora são 4 dias, muito cedo para dizer.

Tenho apenas 4 GU10, acho que são da primeira versão lançada

Na verdade, existem versões mais baratas do IKEA GU10 (apenas W). Eles nunca foram atualizados para o software 2.x e ainda estão em execução no 1.2.214. E esses foram os mais problemáticos. Eu pessoalmente desisti e agora eles estão funcionando perfeitamente com o hub IKEA.

Acho que @antonbo está se aproximando do curso do problema.
A IKEA está usando as mesmas imagens de firmware com hardware diferente (unidades de PSU / LED) e tem configurações diferentes nos "dados do usuário" para hardware diferente (e o ID do modelo é armazenado nele). Portanto, um firmware pode funcionar bem em um hardware (E14) e ter problemas em outros (GU10 / E27).
Uma diferença é que o IKEA GW está rodando no modo ZLL (no Zigbee PRO) e não está puxando o status do dispositivo, apenas escuta as mudanças de status que os dispositivos estão enviando na rede (ala Zigbee PRO / padrão ZB3) e os mistura com HUE e outros fornecedores que o coordenador está puxando status dos dispositivos (comportamento não ZB3) podem bagunçar a rede.
Eu tenho o IKEA RGBW mais antigo e um E27 Opal WW no antigo firmware atualizado (1.X) que está funcionando bem e um monte de ZB3 GU10 WS que está funcionando muito bem. Meu backbone tem cerca de 10 plugues IKEA que estão mantendo a comunicação de rede estável e também meus sensores Xioami estão funcionando bem com todos eles.
Minha sensação é que não é um problema geral mais HW e talvez FW em combinação com o layout de rede e evitando alguns dispositivos problemáticos (como o OSRAM Outdoor Plug que está corrompendo pacotes e perdendo filhos o tempo todo).

@manup só posso dizer que para o meu sistema o novo firmware o tornou muito pior do que antes. Seja o roteamento da fonte ou o que é, agora tenho a cada dia uma ou duas lâmpadas presas e preciso desligar e ligar. Eu até vi uma das minhas lâmpadas de matiz Philips presa, mas isso não exigia ciclo de energia. Não sei se os problemas são causados ​​pelo firmware antigo que estou executando, mas também não consigo atualizar, pois ele travou. :(

Eu me pergunto se alguém sabe se o GU10 mais recente ainda tem problemas ou não tem? Ouvi dizer que dispositivos mais novos executam o zigbee 3.0, minha esposa não está feliz com esses problemas, então eu poderia mudar todos eles se isso ajudar?

Eu tive uma luz pendurada esta manhã. Eu acho que é um dos mais novos.

A luz não reagiu a nenhum comando, foi mostrada como offline. Um ciclo de alimentação não corrigiu o problema. Tive que redefinir e adicionar novamente à rede.

@ JBS5 @djwlindenaar @lubbertkramer Algum comentário sobre os firmwares mais recentes em comparação com este problema?

Posso acrescentar que, por 48 horas, não tive problemas sobre o que esse tópico está abordando e o que experimentei anteriormente.

No entanto, é necessário adicionar o seguinte

• reinicie o contêiner com deconz todas as noites
• mudou o agrupamento de Home-Assistant para deconz / phoscon para manipular.

Eu tinha algumas lâmpadas menos responsivas antes das mudanças acima, embora uma experiência melhor, mas não agora.

@Mimiix , bem, é um pouco cedo para dizer.

O que me incomoda é que a rede parece muito mais lenta. O tempo entre o pressionamento de um botão e o acendimento da luz (por meio de uma regra) é maior do que antes. Também acender a luz e alterar o brilho agora é um processo de duas etapas com algum tempo intermediário. Ainda preciso examinar os logs de detecção para verificar o que está causando isso. Provavelmente isso não tem nada a ver com a mudança no roteamento de origem, mas aí está.

Tive uma luz que parou de responder, mas também não analisei essa situação, é difícil dizer o que aconteceu.

Minhas lâmpadas E27 Ikea pararam coletivamente para cooperar.
Até agora, a ciclagem de energia funcionou para alguns deles. 3 ainda não voltaram. Acho que tenho que adicioná-los novamente ... :(

Firmware: 26610700
Versão: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Isso parece não ter relação com o problema abordado neste problema. Abra um problema separado :)

O sintoma parece o mesmo para mim: as lâmpadas parando de responder sem motivo aparente.

Como acabei de dizer: isso parece não relacionado. abra um problema separado. Sempre podemos determinar depois que isso está relacionado. Eu mantenho um navio firme neste assunto.

Sim, também acho que está relacionado. Depois de alguns meses sem o bug, ontem tive o problema novamente com dois dispositivos, um (muito antigo) IKEA E27 e a tomada IKEA mais recente, ambos com firmware recente.

A única coisa que fiz na época foi transportar uma persiana KADRILJ para fora do alcance e depois de volta, mas isso pode não ter nenhuma relação.

Ligar o farejador mostra o mesmo problema:

• Os dispositivos ainda enviam comandos de status de link NWK periodicamente;
• Mas sempre com uma lista vazia, parece que eles ignoram todos os roteadores ao redor;
• Eles ACK comandos de entrada no nível MAC;
• Eles reagem aos Pedidos de Beacon e enviam um Beacon, mas essa é a única "resposta" que dão.

De alguma forma, parece que a pilha Zigbee nos dispositivos IKEA travou parcialmente para as camadas NWK e APS e acima ou talvez os buffers NWK de entrada estejam cheios e nunca foram liberados.

Tentei reativar os dispositivos enviando:

• ZDP Saia com reingresso;
• NWK Saia com reingresso (nível inferior).

Ambos são reconhecidos no nível MAC, mas são ignorados.

Em seguida, tentei falsificar os comandos NWK Link Status do coordenador com uma entrada válida que indica que o dispositivo tem custo de link de entrada e saída funcionando (3/3) na esperança de que o dispositivo detecte o coordenador em sua tabela de vizinhos. ... também não funcionou.

Infelizmente, não parece haver uma maneira de contornar a situação depois que aconteceu e o dispositivo IKEA entra neste estado quase morto. Olhando em alguns fóruns, o comportamento pode ser visto com todos os tipos de gateways e pilhas Zigbee subjacentes. O que é interessante, já que, por exemplo, a ponte Hue não faz nada de especial no Zigbee, como consultar tabelas vizinhas ou ligações e relatórios e, ainda assim, o bug ocorre.

O que a IKEA precisa fazer é pelo menos implementar um Watchdog que verifica se os componentes NWK e APS ainda estão operando e permite que o dispositivo acione o watchdog para reinicializar. Isso não resolveria o bug, mas pelo menos manteria o dispositivo funcional quando isso acontecer.

@manup Você tem o velho E27 um LL com cluster de diagnóstico?
Talvez seja interessante olhar se algo está acontecendo com os contadores lá com algumas semanas entre.
Ele não consegue resolver o problema, mas dá uma dica de que o firmware não está lento.
Boa observação e conclusões mande !!

Acho que a Silabs está conseguindo um pouco mais de caça a bugs para um de seus maiores clientes ;-)

Olá, isso me confunde, pois desde que mudei para o Z2M usando o ZZH, há alguns meses, não vejo esse problema. Talvez haja alguma outra variável na equação. Seria ótimo se outra pessoa que fez o mesmo movimento pudesse confirmar.

@mvjt Você está usando Rasp / CornBee com Z2M ou algum outro coordenador?
Diferentes pilhas de zigbee estão funcionando de maneiras diferentes e podem ter / causar problemas diferentes.

Edit: Desculpe, vejo ZZH = novo coordenador de TI.
deCONZ NCP = Atmel / Microchip
Dispositivos IKEA / NCP = Sirlabs EFR32 / EZSP

Posso confirmar que HA / ZHA / Zigpy / Bellows funciona muito bem com "Billy EZSP" = módulo IKEA ICC-1-A como coordenador com roteadores IKEA e dispositivos finais de IKEA e Xiaomi e SEM roteadores OSRAM ou Xiaomi.

@MattWestb Sim, o E27 tem o cluster de diagnóstico, mas ainda não desliguei e desliguei a alimentação para mantê-lo no estado de erro. Ao ler os atributos do cluster de minhas outras luzes IKEA, os atributos relatam que todos estão indisponíveis: /

Pelo menos no passado, o problema que estou vendo aconteceu também com o TI CC253X e no final do problema o CC26X2R1 é mencionado, mas esse era o estado em janeiro, ele pode ter melhorado enquanto isso. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Pode não ser um bug Silabs em geral, também pode ser algum material personalizado na camada do aplicativo. Acho que os dispositivos Hue recentes também usam Silabs. Da ponte Hue, existem pelo menos versões TI e Microchip por aí.

É uma coisa realmente desagradável, em muitos casos o bug pode nem acontecer ou só depois de alguns meses, em outras redes acontece em intervalos bem menores. Eu acho que também é significativo como as redes são operadas e que as luzes que são desligadas regularmente são menos afetadas.

@manup Tenho um cenário que está passando muito bem no seu "problema IKEA".
Se você configurou sua rede, ela começa com uma chave de rede e o contador de quadros de segurança começa a funcionar. Se você não tiver reformado a rede ou rolado a chave de rede por muito tempo, o contador está travando porque está chegando ao máximo de 0xFFFFFFFF (32 bits) e não pode aumentar.
Em seguida, o dispositivo está jogando todos os dados que chegam na camada zigbee porque o contador de quadros está errado, mas a camada de rede ainda está funcionando normalmente.
O problema não conheço um método para obter a posição do contador de quadros de segurança dos dispositivos. Acho que não é possível ver no Wireshark (pensar = não saber).

O que está apontando para isso é que os primeiros dispositivos emparelhados que não foram redefinidos estão parando mais rápido.
Dispositivos emparelhados / redefinidos mais novos funcionam por mais tempo antes que o contador pare.
Os comandos do Mutch para um dispositivo também estão tornando-o mais rápido do que um dispositivo que não é tão "comunicativo".

É recomendado rolar a chave de rede regularmente na rede ZB3 para mantê-la segura e também redefinir o Contador de quadros de segurança para que não seja interrompido.
Algumas informações AN1233: Zigbee Security 2.1.6 O Network Security Frame Counter.

É um brainstorming selvagem, mas pode ser que o problema esteja surgindo depois de muito tempo executando a rede.

Um teste é tentar rolar a chave de rede e o dispositivo "vivo" funcionou bem por um bom tempo, mas o travado deve ser reiniciado / religado para iniciar o Contador de quadros de segurança do zero.

Hrm, tenho certeza de que a rolagem da chave de rede eliminará todos os xiaomis.

Errado 200% seguro que não está atualizando e saindo da rede (os antigos não ZB3) !!!

@Adminiuga Você está tentando rolar a chave de rede no EZSP?
Acho interessante o resultado !!!

Ainda não tentei rolar a chave de rede. Na verdade, seria interessante saber quantas implementações rolam a chave regularmente.
Mas posso confirmar que a mudança de pan-id tem chances muito altas de xiaomis cair, como 4 em 5 chances

Tenho visto alguns testes de penetração de segurança que têm farejado o pan-ID da rua e voltando várias vezes com alguns meses entre e nenhum do grande fornecedor de luz (não nomeado aqui) não estava lançando a chave de rede após um ano (Mariahilferstraße em Wien ), então você provavelmente está certo (agen).

Se e somente se for o contador de quadro de segurança que está causando o problema, então está fazendo o mesmo para todos os dispositivos zigbee 3 reais, então está definido na "Especificação de comportamento do dispositivo base" e recomendado na antiga LL, mas muito provavelmente não sem Dispositivos zigbee PRO (HA e LL antigos) ou dispositivos não certificados (sem nome .... mi).
Então é melhor "manualmente" passar as chaves de rede ou duas vezes por ano e não precisa demolir a casa para redefinir dispositivos embutidos mais vezes na boca do que eles estão parando e reiniciando / reintegrando sensores Xiaomi antigos que normalmente não estão sendo integrado na estrutura da casa e sendo mais fácil de zerar (normalmente abre entrando e apertando o botão e está se conectando).
Menny "chinese Zigbee 3" está jogando o "velho" contador de quadro de segurança após a reinicialização de energia e usando um novo do primeiro pacote que chega de seus vizinhos (percebi que depois de testar os problemas do tasmotas zigbee 3, o contador NCPs foi redefinido incorretamente na reinicialização) então eles são apenas repower e estão de volta.

Também fizemos alguns testes no ano passado, nenhum gateway girou a chave de rede. Conforme descrito na especificação, essa é a única maneira de redefinir o contador de quadros de segurança NWK ao incrementar o número da chave de rede. Também compartilho a preocupação de que isso seja suportado por todos os dispositivos, geralmente recursos que quase nunca são usados ​​não são bem testados. Eu realmente espero que esteja errado aqui e funcione para a maioria dos dispositivos.

Em qualquer caso, redefinir o contador de quadros é o mais importante para o gateway, pois ele tem o maior número de comandos de saída, luzes e sensores devem funcionar nos próximos anos. Atualmente, isso não é um problema, mas se torna um em 2 a 3 anos, quando o contador do gateway é alcançado em redes maiores. Para isso já temos planos de verificar se a rotação da chave de rede, bem como o número da chave e o reset do contador de frames funcionam.

De qualquer forma, o problema aqui é diferente, os contadores de quadros do gateway e as luzes em estado de erro ainda estão bons e bastante baixos.

@djwlindenaar Gostaria de saber se você tem novas descobertas, já que é capaz de analisar tecnicamente suas descobertas, além de apenas relatar que uma lâmpada ficou desligada novamente, como eu posso fazer. Suas descobertas e percepções são muito apreciadas. :)

Bem, obrigado pela apreciação ... Para ser honesto, não estou totalmente feliz com a estabilidade da rede atual. Caiu desde a atualização para o firmware deconz mais recente. Algumas luzes ficaram offline nas últimas semanas, quando isso não aconteceu por muito tempo antes da atualização. Corri com os patches que permitem relatórios regulares de atributos para luzes IKEA, que ainda não apliquei na situação atual

Embora seja divertido analisar isso, é um hobby para mim e agora meu tempo está totalmente ocupado por algumas reformas na casa. Vou ver se consigo arranjar algum tempo para isso ...

Bem, obrigado pela apreciação ... Para ser honesto, não estou totalmente feliz com a estabilidade da rede atual. Caiu desde a atualização para o firmware deconz mais recente.

Estou tendo a mesma experiência negativa. Agora, a maioria dos meus dispositivos Xiaomi (principalmente interruptores de parede Aqara) ficam offline com frequência durante o dia e voltam a funcionar após alguns minutos (suponho que isso se deva ao fato de os dispositivos Xiaomi serem reiniciados se não receberem uma resposta ao pedido do atributos do cluster Time do coordenador).

O novo release v2.5.88 pode melhorar a situação. Aqui, a configuração dos relatórios IKEA foi suavizada para que as transições de estado não bombardeiem a rede com relatórios. Antes, durante a transição de estado, cada atributo era relatado em um ritmo muito rápido.

O novo release v2.5.88 pode melhorar a situação. Aqui, a configuração dos relatórios IKEA foi suavizada para que as transições de estado não bombardeiem a rede com relatórios. Antes, durante a transição de estado, cada atributo era relatado em um ritmo muito rápido.

Parece promissor :) Também on / off é uma transição de estado, eu acho? Ou principalmente mudanças de modo de brilho ou cor?
Qualquer versão mínima de firmware necessária / recomendada para esta mudança?

Apenas o brilho e todos os atributos específicos de cores, como colorX, colorY e temperatura de cor.
Para firmware, eu sempre recomendo o mais recente 0x26660700 (no caso de ConBee II e RaspBee II).

O novo release v2.5.88 pode melhorar a situação. Aqui, a configuração dos relatórios IKEA foi suavizada para que as transições de estado não bombardeiem a rede com relatórios. Antes, durante a transição de estado, cada atributo era relatado em um ritmo muito rápido.

@manup , acho que esta atualização resolveu também os problemas de estabilidade com os dispositivos Aqara. obrigado

O novo release v2.5.88 pode melhorar a situação. Aqui, a configuração dos relatórios IKEA foi suavizada para que as transições de estado não bombardeiem a rede com relatórios. Antes, durante a transição de estado, cada atributo era relatado em um ritmo muito rápido.

@manup , acho que esta atualização resolveu também os problemas de estabilidade com os dispositivos Aqara. obrigado

Infelizmente o problema (# 3605) ainda está aqui, tirei conclusões precipitadas