Deconz-rest-plugin: Las luces de IKEA ocasionalmente perdían la conexión

Lo mismo aquí con 2.05.58. Un Tradfri GU10 parece ser un cajero automático irresponsable:

También me pasó con una franja de luz de tono unos días antes, así que supongo que no habrá ningún problema específico de IKEA. Los dispositivos deben reciclarse y volver a funcionar normalmente. Todavía es molesto en algunos casos, principalmente para mis paneles FLOALT que se alimentan directamente y no tienen un interruptor de pared para encenderlos.

1. ¿Alguna pista por qué?

El complemento de la API REST marca una luz como inalcanzable, cuando no recibe una respuesta un par de veces al sondear la luz por su estado. La causa de no recibir respuesta es, en orden de probabilidad:
a. Se ha cortado la energía de la luz (por ejemplo, mediante un interruptor de pared del siglo XX);
segundo. La red Zigbee tiene un problema (por ejemplo, debido a interferencias de radio o problemas de enrutamiento en la malla). En este caso, la luz todavía reacciona a los comandos del grupo;
C. El firmware de la luz se ha bloqueado.

1. ¿Es posible restablecer la conexión de otro modo que luego desconecte / conecte la energía?

En a) yc): no. En b): sí.

El complemento de la API REST marca la luz como accesible cuando recibe un mensaje de ella. Encender la luz hace que envíe un mensaje de _ Anuncio del dispositivo_. En b), por lo general, la luz vuelve espontáneamente, cuando la siguiente encuesta tiene éxito. También puede seleccionar el nodo en la GUI deCONZ y presionar 0 .

El mismo problema también en la versión 2.05.59.

También tengo este problema, incluso después de actualizar a 2.05.59. Hoy fue una de mis tres luces exteriores "desaparecida".
Sus bombillas Tradfri las tres.

@ebaauw Gracias por tu explicación.

a. Se ha cortado la energía de la luz (por ejemplo, mediante un interruptor de pared del siglo XX);

No hay interruptores de pared disponibles para estas luces, por lo que no puedo desconectar accidentalmente la energía.

segundo. La red Zigbee tiene un problema (por ejemplo, debido a interferencias de radio o problemas de enrutamiento en la malla). En este caso, la luz todavía reacciona a los comandos del grupo;

Las luces no reaccionan a los comandos de grupo cuando se pierde la conexión (las luces se asignan a un atenuador de tonos en la aplicación Phoscon y no responden en el atenuador de tonos cuando se pierde la conexión).

C. El firmware de la luz se ha bloqueado.

El firmware 1.2.214 está instalado en todos mis puntos IKEA GU10. Tengo más de 20 de ellos y una luz aleatoria se apaga, digamos una en las 2-3 semanas.

Puede probar la última versión de deCONZ con https://github.com/dresden-elektronik/deconz-rest-plugin/commit/48d2c39a267b5c6d025577eed7530be27932aa2c.

Tuve la misma experiencia dos veces los últimos meses con dos bombillas IKEA E14 diferentes (IKEA fw 1.2.214).
El ciclo de potencia funcionó las dos veces para mí.

C. El firmware de la luz se ha bloqueado.

Cuando las luces no reaccionan ni siquiera a los comandos de grupo, parece que se ha producido un fallo del firmware.

2.05.59 ha adaptado los parámetros de la puerta de enlace de IKEA para configurar los informes del estado de la luz. Principalmente con la esperanza de no activar ningún error mediante el uso de una configuración que IKEA no prueba. Tenga en cuenta que el cambio hará que ya no se utilicen temporizadores para informar sobre el dispositivo.

La nueva configuración se aplicará una vez que se apague y encienda una luz.

Seguimos enviando algunas solicitudes de mantenimiento como membresía de grupo y consultas de tablas vecinas a las luces, y podríamos restringirlas aún más si la estabilidad no mejora con 2.05.59.

Tenga en cuenta que también puede existir la posibilidad de que haya un error en el firmware ligero que no esté relacionado con ninguna solicitud que envíe la puerta de enlace.

C. El firmware de la luz se ha bloqueado.

Cuando las luces no reaccionan ni siquiera a los comandos de grupo, parece que se ha producido un fallo del firmware.

2.05.59 ha adaptado los parámetros de la puerta de enlace de IKEA para configurar los informes del estado de la luz. Principalmente con la esperanza de no activar ningún error mediante el uso de una configuración que IKEA no prueba. Tenga en cuenta que el cambio hará que ya no se utilicen temporizadores para informar sobre el dispositivo.

La nueva configuración se aplicará una vez que se apague y encienda una luz.

Seguimos enviando algunas solicitudes de mantenimiento como membresía de grupo y consultas de tablas vecinas a las luces, y podríamos restringirlas aún más si la estabilidad no mejora con 2.05.59.

Tenga en cuenta que también puede existir la posibilidad de que haya un error en el firmware ligero que no esté relacionado con ninguna solicitud que envíe la puerta de enlace.

+1 en "no necesariamente relacionado con deconz sino con la red Zigbee o el FW del fabricante" en correlación con la interpretación estándar de Zigbee en el FW del fabricante.

Acabo de actualizar a 2.05.59 y después de reiniciar deconz no se puede volver a alcanzar la misma luz. Presionar 0 en la interfaz gráfica de usuario no lo devuelve. Cualquier otra luz funciona. En mi caso, esto también podría ser un problema con la luz en sí.

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

La nueva configuración se aplicará una vez que se apague y encienda una luz.

Buena pista, no he hecho eso. Por ahora tuve que volver a .58 por otra razón (alta carga de la CPU que hace que la puerta de enlace no responda), intentaré esto más tarde hoy con .59 nuevamente y apagar y encender todas las luces de ikea.

También tengo este problema, sucedió dos veces con la misma luz GU 10. Actualmente ejecuto 2.05.59, y apagué y apagué las luces después de la actualización.

Olvidé agregar que a veces parece que es la misma bombilla la que sigue fallando. Hace un tiempo tuve problemas con otra bombilla, y siempre sería esa la que dejaba de reaccionar.

Después del ciclo de energía, volvieron mis bombillas IKEA. Pero mi panel WS de IKEA FLOALT todavía está desconectado

Estoy experimentando este mismo problema y lo he estado haciendo durante bastante tiempo, y diría que .59 en realidad empeoró las cosas para mí. Tengo 80 nodos de los cuales 32 son luces e interruptores Trådfri, 5 son luces Hue y el resto son diferentes dispositivos Xiaomi que funcionan con baterías, como temperatura, movimiento, detector de humo, etc. Cada tipo de dispositivo no ha respondido al menos una vez, así que en mi caso no son solo las luces Trådfri, sino que en ese momento solo tengo problemas con las luces Trådfri y Hue.

El caso es que pasé todas las luces a través de un puente Hue y los sensores Xiaomi a través de la puerta de enlace Xiaomi antes y luego todos eran sólidos como una roca, así que no creo que sea el firmware del dispositivo el culpable en mi caso, a menos que sea causado por el cambio de circunstancias.

Tengo seis luces Trådfri GU10 en una ubicación que funcionaban perfectamente antes, pero después de la actualización a .59 y varios ciclos de encendido después, ahora casi no responden por completo y probablemente tendré que restablecerlas. Lo extraño es que esta falta de respuesta también parece estar "moviéndose" de diferentes luces dependiendo de qué luces tengan energía. Si corto la energía de algunas de las luces que no responden, puede llevar un tiempo y luego, de repente, es otra luz que no quiere funcionar correctamente. ¿Quizás hay alguna compensación en algún lugar que está rompiendo cosas?

El caso es que pasé todas las luces a través de un puente Hue y los sensores Xiaomi a través de la puerta de enlace Xiaomi antes y luego todos eran sólidos como una roca, así que no creo que sea el firmware del dispositivo el culpable en mi caso, a menos que sea causado por el cambio de circunstancias.

Interesante, ¿también tenías las 32 luces de Ikea en la red Hue? Lo pregunto porque el puente Hue solo usa sondeos y no configura informes de atributos.

¿También tenías dispositivos enrutadores como las luces Hue o Ikea en la red Xiaomi?

Tengo seis luces Trådfri GU10 en una ubicación que funcionaban perfectamente antes, pero después de la actualización a .59 y varios ciclos de encendido después, ahora casi no responden por completo y probablemente tendré que restablecerlas. Lo extraño es que esta falta de respuesta también parece estar "moviéndose" de diferentes luces dependiendo de qué luces tengan energía. Si corto la energía de algunas de las luces que no responden, puede llevar un tiempo y luego, de repente, es otra luz que no quiere funcionar correctamente. ¿Quizás hay alguna compensación en algún lugar que está rompiendo cosas?

Hmm, eso es bastante malo. Realmente me pregunto cómo sucede esto, 2.05.59 es más "familiar" para las luces de Ikea que las versiones anteriores. La configuración ahora está sucediendo como lo hace la puerta de enlace de Ikea.

Cuando una luz deja de responder, puede seleccionar el nodo en deCONZ y presionar 0 si vuelve a responder / amarillo nuevamente, no es necesario apagar y encender la luz. Tenga en cuenta que la luz que se convierte en zombi en este caso se solucionará pronto, esto puede suceder en una determinada constelación de red actualmente.

Por cierto las preguntas habituales:

• ¿Qué versión de firmware estás usando?
• ¿RaspBee o ConBee?
• Si usa ConBee, ¿usa un cable de extensión USB?

Tomó un tiempo más de lo esperado, pero ahora todo parece estar funcionando bien nuevamente. Al menos por ahora por lo que puedo decir.

Reinicié el servidor y también apagué y volví a encender todas las luces de la red para asegurarme de que obtuvieran la última configuración, pero a pesar de esto, pasaron un par de horas antes de que el problema desapareciera, así que fui un poco prematuro al suponer que el problema persistió, ya que no funcionó de inmediato.

Interesante, ¿también tenías las 32 luces de Ikea en la red Hue? Lo pregunto porque el puente Hue solo usa sondeos y no configura informes de atributos.

Sí, más o menos. Tenía 31 luces Ikea en la red Hue, así como las luces Hue. El dispositivo 32 de Ikea es la salida del interruptor que no había comprado en ese entonces.

¿También tenías dispositivos enrutadores como las luces Hue o Ikea en la red Xiaomi?

No, solo sensores alimentados por batería

Cuando una luz deja de responder, puede seleccionar el nodo en deCONZ y presionar 0 si vuelve a responder / amarillo nuevamente, no es necesario apagar y encender la luz. Tenga en cuenta que la luz que se convierte en zombi en este caso se solucionará pronto, esto puede suceder en una determinada constelación de red actualmente.

Intenté esto varias veces antes sin ningún efecto. Y en cuanto al hardware y la configuración, estoy usando un ConBee con cable de extensión USB y 262F0500. Dado que todo parece estar funcionando bien para mí ahora, esta información puede no ser de utilidad en este momento, pero intentaré no sacar conclusiones precipitadas y dejar que la red funcione durante unos días para asegurarme de que el problema no regreso.

He estado corriendo .59 desde el fin de semana pasado y todavía pierdo luces de Ikea al azar. (16 bombillas E27 en la fachada de la casa).
Bulb FW es el mismo que otros que se encuentran todavía en el Ikea Gateway.
Usando ConBee con 262F0500 FW.
El fin de semana pasado también compré un puente HUE y estaba a punto de comenzar a mover las luces cuando noté la nota de lanzamiento 'Bajo el capó' para .59. Decidió posponer, pero reconsiderará este próximo fin de semana.
Deconz seguirá siendo mi mejor controlador Xiaomi / mi Cube de elección. Aún no he perdido un gesto.

He estado corriendo .59 desde el fin de semana pasado y todavía pierdo luces de Ikea al azar. (16 bombillas E27 en la fachada de la casa).
Bulb FW es el mismo que otros que se encuentran todavía en el Ikea Gateway.
Usando ConBee con 262F0500 FW.
El fin de semana pasado también compré un puente HUE y estaba a punto de comenzar a mover las luces cuando noté la nota de lanzamiento 'Bajo el capó' para .59. Decidió posponer, pero reconsiderará este próximo fin de semana.
Deconz seguirá siendo mi mejor controlador Xiaomi / mi Cube de elección. Aún no he perdido un gesto.

Tengo la misma situación aquí, 16 luces IKEA, 2 salidas de control IKEA, un enchufe Heiman y un enchufe innr y algunos sensores Xiaomi (sensores de cubo / puerta / sensor de movimiento). Nunca tuve problemas con los dispositivos que no son de IKEA. Sin embargo, actualmente tengo problemas casi diarios en los que una luz IKEA se cae de la red

Utilizo un Conbee con un cable de extensión USB en el firmware 0x26300500 y deCONZ .59

Mis luces han estado funcionando bien durante un tiempo, pero hace un par de días, mi bombilla Trådfri E14 de repente dejó de responder. Un ciclo de energía más tarde volvió a la vida.

Hoy era el momento de que abandonara uno de los GU10. Está físicamente muy cerca del E14 mencionado anteriormente, por lo que no estoy seguro de si es una coincidencia o no. Es muy posible que el GU10 se haya enrutado a través del E14 a pesar de que todas mis luces están dentro del rango de ConBee.

Seleccionar los nodos y presionar 0 en deCONZ no hace nada. También intenté reiniciar el contenedor deCONZ y, aunque redirige la red al inicio, no conecta ninguna ruta a esa bombilla específica. ¿Cuál sería el mejor enfoque aquí para continuar con la solución de problemas?

12 días después, otro GU10 se vuelve inalcanzable y no se volverá a conectar sin un ciclo de energía.

Feliz de compartir cualquier información que sea necesaria para abordar este problema.

Lo mismo aquí, ayer después de 6 días de conexión impecable, perdí una de mis bombillas Tradfri. Encender / apagar y reiniciar no ayudaron. Todavía es amarillo en deConz pero no puedo conectarlo ni controlarlo.

Igual que aquí. Después de algunos días sin ningún problema, hoy dos de mis lámparas GU10 Tradfri dejaron de responder. Pude revivir uno de ellos presionando 0 en la GUI, pero tuve que apagar y encender el otro.
Afortunadamente, esto solo parece suceder en los cajeros automáticos de los dispositivos GU10, mis paneles FLOALT aún no han tenido problemas (en mi configuración, solo se pueden reciclar con el disyuntor).

El problema ha continuado para mí también. Ahora he experimentado que 3-4 bombillas GU10 más pierden la conexión, así como una de mis Hue E27 y un sensor de puerta Xiaomi (imán). Algunas luces han comenzado a funcionar nuevamente después de un ciclo de energía, otras no. Presionar 0 no hace nada.

También es digno de mención que el sensor Xiaomi comenzó a funcionar nuevamente después de apagar y encender un GU10 adyacente y que no responde, así que supongo que el sensor estaba enrutando a través de esa luz, pero ¿no debería redirigirse automáticamente si hay algún problema de conexión?

El mismo problema aquí. Ayer actualicé a la última versión .59 ahora un par de luces de Ikea no responden

Hola, ¿puede darnos más información sobre la red total, como el tamaño de la red y otros dispositivos alimentados por la red?

He reorganizado mi red doméstica hace unos días, ahora incluye:

• 5x IKEA WS GU10 (firmware 1.2.221, código de producto LED1537R6GU10EU)
  Con dirección mac 0x000b57ff ..... (lote más antiguo)
• 2x IKEA regulable E27 (firmware 1.2.214)
• 1x luz IKEA E14 WS (firmware 1.2.221)
• 1x repetidor IKEA (firmware 2.0.019)
• 1x salida IKEA (firmware 2.0.019)
• 1x OSRAM GU 10
• 1x bombilla de color OSRAM E27
• 1x enchufe OSRAM
• 1x bombilla de color Hue E27
• 1x bombilla lux regulable Hue E27

deCONZ 2.05.59; Firmware de ConBee 0x26300500 (pero 0x262f0500 también está bien).

Tengo 4x FLS-PP lp, pero ahora están apagados para probarlos, ya que actúan como repetidores de señal muy fuertes.

Con sensores e interruptores, el tamaño total de la red es 55.
Todas las luces están siempre encendidas y hasta ahora muestran cero cortes.

Aquí hay algunas especificaciones más detalladas de mi red si puede ser de alguna ayuda. Todavía estoy ejecutando 2.05.59 con 262F0500 y un cable de extensión para el ConBee. Como se mencionó anteriormente, después de actualizar por primera vez a 2.05.59 y apagar y encender todos los dispositivos con alimentación de red y esperar un par de horas, la red estuvo impecable durante casi una semana, por lo que parece pasar un tiempo hasta que los problemas comiencen a aparecer. Desafortunadamente, el problema reapareció y un ciclo de energía completo de todos los dispositivos alimentados por la red, así como un reinicio de deCONZ, ya no resuelve el problema. También parece que el problema es deambular de un dispositivo a otro porque a veces una luz puede no responder por un tiempo y luego se arregla sola.

Hoy temprano tuve un problema en el que el Trådfri E14 no respondía, así como un Hue E27. Después de un ciclo de energía del E27, el E14 volvió a la vida también sin que yo lo tocara. Lo mismo ocurre con los GU10 que no responden que parecen estar intercambiando lugares de vez en cuando, por lo que hay al menos dos GU10 que no responden todos los días, pero no siempre son las mismas luces, por lo que algunos comienzan a funcionar mientras que otros se rompen y viceversa.

Actualmente, mi red consta de los siguientes 80 dispositivos, incluido ConBee, y los dispositivos con alimentación de red funcionan las 24 horas del día, los 7 días de la semana.

Alimentado por red

| Cantidad | Tipo | Firmware |
| ---------- | ------ | ------------- |
| 30 | Trådfri GU10 regulable | 1.2.214 |
| 4 | Trådfri GU10 espectro blanco | 1.2.217 |
| 1 | Trådfri E14 ópalo regulable | 1.2.217 |
| 1 | Salida de control Trådfri | 1.4.020 |
| 3 | Hue E27 Blanco y Color A19 | 1.29.0_r21169 |
| 2 | Hue E14 White ambiance LTW012 | 1.29.0_r21169 |

Bateria cargada

Cantidad | Tipo | Firmware
--------- | ------ | -----------
1 | Interruptor de encendido / apagado Trådfri | 1.4.018
10 | Multisensor Xiaomi Aqara (temperatura cuadrada / zumbido / presión) | 20161129
3 | Sensor de movimiento Xiaomi Aqara (movimiento / lux) | 20170627
4 | Sensor de agua Xiaomi Aqara | 20170721
1 | Sensor de movimiento Hue | 6.1.0.18912
11 | Sensor de contacto Xiaomi Aqara | 20161128
8 | Sensor de humo Xiaomi / Honeywell | N / A

La semana pasada, deconz pareció funcionar bastante bien, pero ayer tuve otra bombilla IKEA (espectro blanco) que perdió la conexión con deconz. Incluso apagarlo y encenderlo de nuevo no ayudó. Tuve que reiniciar deconz para que volviera a funcionar de alguna manera.

Tengo una red con principalmente bombillas IKEA, una salida Heiman y bastantes sensores Xiaomi.

Algunas especificaciones de mi red zigbee:

Firmware Conbee 262F0500 con cable de extensión en un NUC.
deCONZ 2.05.55 en Docker, así que lo primero que tengo que hacer es actualizar a 2.05.59, supongo.

Alimentado (24/7)

| Cantidad | Tipo | Firmware |
| ------------- | ------------- | ------------- |
| 4x | Tradfri E27 blanco | 1.1.1.0-5.7.2.0 |
| 2x | Tradfri E27 blanco | 1.2.214 |
| 21x | Tradfri GU10 regulable | 1.2.214 |
| 3x | Toma Osram Smart + | 1.04.12 |

Bateria cargada

| Cantidad | Tipo | Firmware |
| ------------- | ------------- | ------------- |
| 3x | Interruptor de atenuación de tono | 5.45.1.17846 |
| 1x | Interruptor inteligente Aqara | 20180525 |
| 1x | Interruptor inteligente Aqara | 20161128 |
| 1x | Interruptor inalámbrico doble Aqara | 20170411 |
| 1x | TRADFRI remoto | 1.2.214 |
| 6x | Multisensor Aqara | 20161129 |
| 10x | Sensor de contacto de Aqara | 20161128 |
| 5x | Sensor de movimiento Aqara | 20170627 |
| 1x | Sensor de fugas Aqara | 20170721 |
| 1x | Sensor de vibración Aqara | 20180130 |

¿Alguna actualización sobre esto para la versión actual? He estado funcionando .60 durante 3 días y ninguna luz ha perdido la conexión todavía.

Desafortunadamente, ya perdí la conexión con una bombilla blanca Tradfri E27 normal en .60 y el firmware más reciente.

Esas son malas noticias ... si entiendo correctamente, los intervalos de votación se han cambiado en .60 para ser menos agresivos. El sondeo agresivo que provocó que una luz se cuelgue tenía mucho sentido para mí, lástima que esto no parece ser la solución a nuestro problema.

Ayer apagué la alimentación de todos los dispositivos alimentados por la red y los actualicé a 2.05.60 y 26320500 antes de encenderlos nuevamente, solo para ir a lo seguro. Luego, todas las luces funcionaron bien durante aproximadamente 24 horas, pero hace solo unos minutos noté que uno de mis GU10 había dejado de responder. Afortunadamente, volvió a la vida unos minutos después sin ninguna interacción manual de mi parte, por lo que quizás la red estaba obstruida.

@ JBS5 Recomendaría actualizar el 4x Tradfri E27 blanco en 1.1.1.0-5.7.2.0 a una versión de firmware reciente. Si mal no recuerdo, esta sigue siendo la primera versión.

@jurriaan ¿Qué versión tiene tu bombilla blanca Tradfri E27?

Esas son malas noticias ... si entiendo correctamente, los intervalos de votación se han cambiado en .60 para ser menos agresivos.

Sí, básicamente, es muy similar a la puerta de enlace de IKEA. Ahora la única diferencia que queda es la consulta periódica de las tablas vecinas (que se utiliza para mostrar las líneas de la red de malla).

Esto se puede desactivar haciendo clic en el icono CRE en deCONZ y desmarcando "Enrutadores y coordinador".
Podría valer la pena una prueba.

En Reddit, hubo una publicación que mencionaba que la puerta de enlace IKEA debería admitir en teoría hasta 100 dispositivos, pero que no se ha probado muy bien. Sería interesante saber cuál es el tamaño de red habitual que prueba el equipo de IKEA.

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

Probablemente podría tener 100 dispositivos conectados a su Gateway. Esto no lo probamos adecuadamente, por lo que no lo garantizamos. Pero el límite técnico es 100, y he visto personas que tienen 100 dispositivos con problemas menores o ninguno.

Las nuevas versiones de Gateway admitirán la misma cantidad de dispositivos (oficialmente 50). Puede agregar otro Gateway a su sistema si desea duplicarlo.

@ JBS5 Recomendaría actualizar el 4x Tradfri E27 blanco en 1.1.1.0-5.7.2.0 a una versión de firmware reciente. Si mal no recuerdo, esta sigue siendo la primera versión.

Esas bombillas E27 con el firmware antiguo no fallaron durante los últimos 6 meses, mientras que otras sí ...

Muy interesante, ¿qué tal el E27 en la versión 1.2.214?

Muy interesante, ¿qué tal el E27 en la versión 1.2.214?

Perdieron la conexión solo una vez en los últimos meses.

Han pasado unas semanas desde que el último GU10 perdió la conexión, mientras sigo usando deCONZ 2.05.55 y el firmware 262F0500 en el Conbee.

También tengo este problema. Solo nodos de Ikea, (43, principalmente luces). No tengo conocimiento sobre zigbee, pero como no lo he visto mencionado: mi red parece más estable con OTAU deshabilitado. El otro día también cambié las preferencias de red a menos seguras. No recuerdo cuál, pero después de eso no he perdido ninguna luz.

Después de algunos días sin ningún problema, varios GU10 han dejado de responder.
Otro problema puede no estar relacionado, pero una luz Osram también perdió la conexión. A pesar de que todavía se mostraba en la GUI y parecía encajar, no pude controlarlo más. Tuve que eliminar la luz y leerla, se le asignó otro No de luz pero recuperó su nombre anterior poco después de agregarlo. No tengo idea de lo que está sucediendo aquí, pero esto es un poco más de mantenimiento del que me gustaría ver para mi configuración.

@ peer69 , ¿también intentaste
¿Estás en 2.05.60? ¿También puede proporcionar algunos detalles más sobre su red, cuántas luces y dispositivos alimentados por la red?

@manup Hice un ciclo de encendido de la luz. Varias veces. Fue controlable durante unos 10 segundos después de un ciclo de energía, pero luego dejó de responder nuevamente (luces rojas parpadeando en la GUI).
Mientras tanto, este problema volvió a aparecer incluso después del restablecimiento de fábrica y también afectó a otra luz OSRAM. Por ahora, me he estado deshaciendo de las únicas dos luces OSRAM en mi red y las reemplacé con bombillas de tono. Puedo ofrecer algunas pruebas con las luces ORSAM, pero necesitaría algo de tiempo para eso.

Estoy ejecutando 2.05.60. Actualmente hay 57 nodos conectados a la red de los cuales 27 dispositivos están alimentados por la red. Yo uso 13 IKEA GU10, 1 IKEA FLOALT Panel, 2 IKEA E14, 3 OSRAM Smart + Plugs, 3 bombillas de tono E14, 5 bombillas de tono E27, 1 tira de luz de tono.

También tuve que apagar y encender algunos IKEA GU10 en los últimos días que no respondieron. Después del ciclo de energía, todo vuelve a la normalidad y no veo un patrón. Tengo lámparas con varios GU10 y no más de un GU10 que no responden al mismo tiempo a pesar de que siempre se controlan como grupo.

Por el momento estoy de vuelta al punto de partida. Ahora regularmente tengo 2-3 luces que no responden, pero salta entre diferentes luces, por lo que a veces funcionan y otras no, dependiendo de qué otras luces estén en línea. El problema parece estar en cascada porque cuando apago físicamente algunas luces al cortarles la energía, cambia el problema a otras luces.

También perdí un par de sensores de temperatura Xiaomi, así como sensores de puerta y un interruptor de encendido / apagado de IKEA, pero no vuelven a aparecer, por lo que probablemente deban volver a emparejarse para comenzar a funcionar nuevamente.

Las cosas funcionaron bien inmediatamente después de un ciclo de energía total, como señalé anteriormente, pero unos días después las luces comenzaron a dejar de responder nuevamente y ha sido así durante un par de semanas. Cuando sucedió la primera vez que un invitado desconectó accidentalmente el E14 durante varias horas, no estoy seguro de si no tiene ninguna relación o si las perturbaciones inesperadas de la malla zigbee hicieron que la ruta se volviera loca. Dado que aparentemente no soy el único con estos problemas, creo que puede haber sido solo una coincidencia.

Realmente me gusta el concepto de tener todos mis dispositivos zigbee en una sola malla, pero estoy casi en el punto en el que inicio las antiguas pasarelas Hue y Xiaomi y pongo el ConBee en un cajón, lo que realmente no quiero hacer. por varias otras razones. ¿Alguien tiene algún consejo para solucionar más problemas que pueda ayudarme a identificar exactamente lo que está sucediendo y cómo resolverlo?

Uno de mis puntos IKEA GU10 ahora tampoco responde.

En el rastreador veo que todavía está algo "vivo" y envía mensajes NWK Link Status, pero obviamente piensa que está solo en la red (Link Status Count: 0).

No responde a los comandos de unidifusión, pero envía periódicamente el informe de atributos ZCL del modelid.

Olfateando desde ~ 2 horas, no estoy seguro de cuándo dejó de responder y si está relacionado, pero el número de secuencia de ZCL del informe es bajo:

Haré algunas pruebas más y no lo apagaré por un tiempo.

Mi toma de corriente Tradri también actuó realmente extraño hoy y funcionó en círculos de reinicio, nunca antes había tenido esta.

Acabo de notar que un segundo IKEA GU10 también tiene los mismos síntomas que el otro.

Ambos dispositivos no responden a solicitudes de dirección unicast, groupcast ni ZCP nwk (presionando 0).
Envían comandos de estado de enlace NWK vacíos.

El segundo GU10 también envió solicitudes ZCL OTA Query Next Image.

Parece que la respuesta no llega.

Solo una suposición salvaje, pero creo que las luces en búfer están bloqueadas y es por eso que no se recibe ni se procesa nada. Los búferes externos siguen funcionando, por lo que el firmware puede enviar informes y consultas ota.

Sería bueno si implementaran algo como una simple verificación de estado para que el firmware pueda reiniciarse después de un tiempo, si la capa mac está funcionando (se reciben los comandos) pero las capas nwk y aps permanecen en silencio.

También tengo este problema, incluso después de actualizar a 2.05.59. Hoy fue una de mis tres luces exteriores "desaparecida".
Sus bombillas Tradfri las tres.

fuera de contexto. ¿Cómo encuentras tu luz en todo esto? Lol. Tengo una configuración similar y pensé ... no hay tiempo para esto

por similar me refiero a + - 50 dispositivos

+ - 50 está bien. Una de nuestras redes de prueba tiene +180 dispositivos con deCONZ en una Raspberry Pi 1, eso es divertido :)

Tenemos algunos planes para agregar un mejor filtro / clasificación a deCONZ para simplificar la búsqueda de dispositivos, actualmente es realmente engorroso con un cierto número de dispositivos.

Las luces todavía están atascadas.

Una observación interesante: apagué el padre de un sensor de movimiento Philips Hue (un Hue Lux) para que necesite buscar un nuevo padre. El sensor ahora intenta volver a unirse a través de una de las luces IKEA GU10 atascadas.

La luz responde con un comando Salir (con Volver a unirse). ¡Así que procesó la solicitud de reincorporación!

Lamentablemente, el sensor de movimiento Hue es terco e intenta volver a unirse a la luz GU10 atascada para siempre, en lugar de buscar un mejor padre.

Sin embargo, la parte interesante aquí es que la luz IKEA atascada responde a la solicitud de reincorporación, tal vez también procesa las solicitudes NWK Leave, que podrían ser la base de una solución alternativa para que la luz vuelva a funcionar.

Corrección, el sensor de movimiento Hue no es demasiado terco; después de unos minutos, el sensor seleccionó otro padre que funcionaba (bueno).

Sin embargo, la parte interesante aquí es que la luz IKEA atascada responde a la solicitud de reincorporación, tal vez también procesa las solicitudes NWK Leave, que podrían ser la base de una solución alternativa para que la luz vuelva a funcionar.

Probé esto, pero lamentablemente no funciona. Mientras las luces estén bloqueadas, no procesarán la solicitud NWK Leave with rejoin.

Actualmente, solo puedo concluir que IKEA necesita solucionar el problema de raíz de la luz que se atasca o implementar algún tipo de control de vigilancia + verificación de estado para las capas NWK / APS del firmware.

Todavía se desconoce qué causa exactamente que la luz entre en este estado: tormenta de transmisión, ciertos comandos, problemas de enrutamiento ...

Enviaré mis hallazgos y registros de rastreo a IKEA, con la esperanza de que puedan usarlos para rastrear el problema.

Entonces, @manup , ¿cuál es la mejor práctica para volver a unir una luz IKEA atascada?

Para mí, un ciclo de energía de la luz funciona mejor

@manup Supongo que si no sabes cómo mejorar al paciente, deberías intentar empeorarlo. Entonces, bombardee una luz con posibles causas de encierros y vea qué sucede.
Además, ¿estas luces no se basan en la pila Ember? Tal vez haya equipos de soporte o foros que puedan arrojar algo de luz (juego de palabras).

Wrt a IKEA, ¿responden a solicitudes de soporte como estas? ¿O deberíamos unirnos para llamar la atención?

Para mí, un ciclo de energía de la luz funciona mejor

No es mucho para mi...
Un reinicio de Conbee es lo único que lo arregla temporalmente.
Y luego la misma, o más a menudo, otra luz IKEA se atasca después de un tiempo ...
¡Siempre una sola luz! Es tan extraño ... e irritante ...: /

@manup ¡Impresionante! ¡Gracias por mirar en esto!

También envié este hilo al equipo de IKEA Tradfri a través de Reddit. Acabo de recibir una respuesta de ellos diciendo que han enviado la información. Esperemos que puedan usar esto para mejorar su firmware o encontrar una solución para este problema :)

Parece que en los próximos días habrá un nuevo firmware para la puerta de enlace tradfri que se dirige especialmente al soporte de HomeKit. También puede haber un nuevo firmware para las bombillas.

@ peer69 Esta es la última versión de firmware:

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

Solo las actualizaciones son:

• 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-bombilla-ws-2.0.022.ota.ota.signed
• 159699-2.1-TRADFRI-control-remoto-1.2.223.ota.ota.signed

Así que principalmente se centró en los puntos de venta / puerta de enlace.

Hoy una de mis bombillas de tono mostró exactamente el mismo problema. Tuve que reciclarlo para volver a responder.

¿Alguna noticia para quién actualiza deCONZ y el firmware del Conbee?

Hasta ahora, 1 o 2 GU10 se desconectarán en 2-4 semanas. Es algo esporádico, pero el ciclo de energía es molesto porque no tengo un interruptor de energía en algunos lugares.

Acabo de actualizar el firmware a 0x26330500, así que veamos.

Desafortunadamente, hoy uno de mis GU10 no está disponible.
Usando deCONZ 2.05.64 con firmware 26330500 en el Conbee.

Creo que se llegó a la conclusión de que se trata de un problema de FW de bombilla, ya que vemos exactamente el mismo problema en un puente HUE de Philips. Noté en la sección Notas de la versión de la aplicación Trådfri, una mención de una bombilla CT v2. ¿Quizás incluso esté relacionado con el HW de la bombilla?

Hasta ahora no he tenido problemas con 2.05.65.

Igual, no me he enfrentado a este problema desde hace semanas.

Tuve lo mismo con la última versión de deconz hasta ahora ... cambié algunas lámparas hace unos días. Solo tuve que apagarlo manualmente y encender nuevamente una de estas lámparas para que respondiera nuevamente.

Algunos GU10 y una bombilla E27 se desconectaron hace unos días. Solo el ciclo de potencia los vuelve a poner en línea.

Quizás relevante: esto sucedió durante mis vacaciones cuando no hubo luces encendidas durante uno o diez días.

Firmware 26330500 con deCONZ 2.05.64

¿Qué tal este tema para aquellos que dijeron que no tenían ningún problema durante unas semanas hace un par de semanas?

Todavía tengo este problema. A veces, ninguno de ellos se desconecta y, de repente, un GU10 está desconectado y, unos días después, otro ...

Por lo que puedo ver, todavía no hay nuevo firmware disponible para Tradfri GU10.

También tengo este problema. Como, para mí, los comandos de grupo todavía funcionan la mayor parte del tiempo, incluso si no puedo controlar la luz como un solo dispositivo, los uso en mis scripts de interruptor de pared como una solución.

Los comandos grupales también me funcionan, pero solo unas pocas veces. Después de eso, la luz sigue encendida o apagada y ya no responde. Ni siquiera cuando se usa un atenuador de tono enlazado.

Lo mismo para mi. Tengo la impresión de que el problema se ha retrasado, más que resuelto.
También he solucionado el problema del uso de comandos de grupo.

Por cierto, noto que algunas luces parecen mucho más susceptibles a este problema. ¿Reconoces esto?

@djwlindenaar Es difícil de decir, pero supongo que la mitad de los 25+ GU10 que tengo nunca han tenido este problema y estoy seguro de que algunos tuvieron el problema varias veces.

@ peer69 @djwlindenaar ¿El comando de grupo sigue funcionando? Hoy, un GU10 se desconectó y ni siquiera respondió a un comando de grupo la primera vez (comando de grupo de deCONZ y un atenuador Hue enlazado).

El comando de grupo generalmente sigue funcionando, pero recuerdo una ocasión en la que tuve que apagar y encender una luz. También recuerdo una vez que no respondió por un tiempo y sin ninguna acción comencé a responder nuevamente más tarde.

Todas las veces, tarde o temprano, también falló un comando de grupo y tuvo que apagar y encender la luz.

¿A qué te refieres con un rato? ¿Unas horas o unos días?

No estoy seguro, probablemente horas, quizás un día. Lo olvidé por un tiempo, pero noté que volvería la próxima vez que use la luz.
Estaba relacionado con una regla provocada por el movimiento, así que ...

Esperó aproximadamente 2 días cuando un GU10 se desconectó a principios de esta semana, pero no regresó. Se necesitaba un ciclo de energía, el GU10 no estaba caliente en absoluto.

Ahora, tengo una luz GU10 que se desconectó, pero no se vuelve a conectar después de un ciclo de energía. Además, presionar 0 en VNC no resuelve este problema.

Además, un comando de grupo o un interruptor Hue DImmer enlazado ya no pueden encender / apagar la luz.

A partir de anoche tengo en el pasillo 4 luces de ikea que se apagan después de x tiempo por un temporizador (Home Assistant) ahora 1 de las 4 luces permanece encendida y no puede ser apagada por Home Assistant / Deconz. Está desconectado según Deconz y no se ha reincorporado en 7 horas. Intentaré encender y apagar y ver si funciona.

La luz no funciona: Bombilla TRÅDFRI E27 ópalo 1000lm con versión 1.2.214
Funcionamiento de luces: Bombilla TRÅDFRI E27 ópalo 1000lm con versión 1.2.214
Firmware: 26330500
Deconz: V2_05_69

Creo que hay un problema de hardware con las bombillas de espectro blanco Ikea Trafri GU10. También en mi configuración (puerta de enlace de Ikea conectada a través de la API local a Home Assistant) al menos la mitad de mis 17 bombillas se desconecta cada dos días. La única solución es apagar y encender las bombillas.

Esta podría ser la razón por la que Ikea ha lanzado una nueva versión de hardware que ejecuta una versión diferente del firmware (2. * en lugar de 1. *).

Hasta donde yo sé, no hay una nueva actualización de firmware para la versión anterior, esto podría ser un signo de algo relacionado con el hardware.

No estoy seguro de cuál es la garantía, pero planeo solicitar un reemplazo con la nueva versión.

Creo que hay un problema de hardware con las bombillas de espectro blanco Ikea Trafri GU10. También en mi configuración (puerta de enlace de Ikea conectada a través de la API local a Home Assistant) al menos la mitad de mis 17 bombillas se desconecta cada dos días. La única solución es apagar y encender las bombillas.

Esta podría ser la razón por la que Ikea ha lanzado una nueva versión de hardware que ejecuta una versión diferente del firmware (2. * en lugar de 1. *).

Hasta donde yo sé, no hay una nueva actualización de firmware para la versión anterior, esto podría ser un signo de algo relacionado con el hardware.

No estoy seguro de cuál es la garantía, pero planeo solicitar un reemplazo con la nueva versión.

No estoy seguro de si está relacionado con un solo tipo, porque estoy usando el GU10 blanco cálido, no el espectro blanco.

Hoy tuve el mismo problema con dos IKEA GU 10 WW. El ciclo de potencia no ayudó. Ayudó a apagar y encender deconz. ¿Quizás algún problema con la mesa del vecino? Ambas luces están en un grupo de dos y siempre controladas como grupo.

Qué casualidad que esto esté pasando en varias instalaciones estos días ... ¿O está pasando algo más?

@ peer69

¿Qué versión de firmware deCONZ y conbee está utilizando?

Estoy usando:
deCONZ V2_05_66
Firmware 26330500

El mismo firmware aquí. deCONZ Versión 2.05.69.

Y otro Tradfri GU10 blanco cálido pierde su conexión.

Hay archivos de firmware más nuevos en la rama de pruebas, pero no sé si solucionan los problemas o causan nuevos problemas, tal vez incluso dañen.

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 Estos son para luces GU10 de espectro blanco y, supongo, ¿para la nueva versión? https://www.ikea.com/nl/nl/p/tradfri-led-lamp-gu10-400-lumen-draadloos-dimbaar-warm-wit-60420041/

Quizás el 10046695-1.1-TRADFRI-light-unified-w-2.1.022.ota.ota.signed pueda usarse para ellos. Lo probaré en una de mis luces regulables IKEA E27, con suerte, el peor de los casos es un accidente pero no que se queme :)

Intenté asignar el archivo manualmente, pero la bombilla no detecta la actualización (no se inicia).

Solo un 'yo también' en esto. Toda mi casa es Tradfri y después de reiniciar mi servidor hoy perdí toda la red por tercera vez en tantos días. El ciclo de potencia no ha marcado la diferencia. Solo tengo a Tradfri en mi casa, así que no tengo nada más con lo que comparar. Tengo una mezcla de blanco e27, color e27 y GU10. La única solución que he encontrado es restablecer las bombillas y comenzar todo desde cero; lamentablemente, esto no es sostenible.

Firmware de Conbee: 264A0700
Firmware ligero: 1.2.214

Feliz de ayudar con cualquier diagnóstico, pero necesito volver a poner la mayor parte de mi casa en la puerta de enlace Tradfri para que mi familia pueda encender y apagar las luces. Dejaré un par de lámparas disponibles.

Me acabo de dar cuenta de una adición, tal vez, interesante a este número.

Varias habitaciones están equipadas con múltiples puntos Tradfri GU10 y la mayoría de las habitaciones con un interruptor de atenuación de tono, con un enlace directo a los GU10 en la habitación creada al agregarlos al grupo de interruptores de atenuación de tono en la aplicación Phoscon.

• Solo los GU10 con un enlace directo con un interruptor de atenuación de tono se desconecta de vez en cuando y necesitan un ciclo de energía para volver a conectarse.
• Los GU10 sin un enlace directo con un interruptor de atenuación de tono no se desconectan.

No parece ser el caso para mí. Hasta ahora, solo las bombillas Hue parecen ser bastante resistentes. Todo tipo de dispositivos IKEA (GU10, E14, FLOALT Panel) y dispositivos Osram (bombillas, tiras de luz y postes de jardín) que tengo han fallado. Especialmente los dispositivos Osram fallan por completo, el ciclo de energía no hace nada. Tienen que ser removidos y reparados, lo cual es un dolor para estos dispositivos.

Pasé algunos días pensando en reemplazar todos mis dispositivos zigbee con dispositivos para mi instalación KNX demasiado costosa después de que varios dispositivos fallaron y la migración a un dispositivo Conbee II también falló probablemente debido a un zll-db algo corrupto. Luego tomé el enfoque radical para configurar todo desde cero. Reinicié la puerta de enlace y reparé todos los dispositivos. En cuanto a los dispositivos IKEA, esto fue mucho más fácil de lo que solía ser. En el pasado, tenía que moverlos cerca de la puerta de enlace, restablecerlos varias veces, usar el enlace táctil para que respondieran, nada de eso esta vez. Acabo de restablecer las bombillas y se emparejaron sin ningún problema. Aún así, hacer esto para 70 dispositivos fue una molestia y algunos sensores xiaomi lo hicieron un poco más difícil que las cosas de ikea. Pero ya me hace pensar que ahora podría tener una red más estable. Sin embargo, nada ha fallado, pero te lo diré si lo hace.

Ha pasado un tiempo desde que actualicé mi raspbee, mi versión anterior tenía problemas para leer la temperatura de las luces, así que decidí actualizar al último firmware y al último deCONZ. Tengo solo 2 luces (OSRAM 73674). 1 luz (probablemente aleatoria) pierde la conexión después de unos minutos con el último deCONZ y tengo que apagar y encender manualmente. La única versión que pude encontrar que podía leer temperaturas y no perdía luces fue deconz-2.04.40-qt5.deb, que es muy antigua, pero funciona para mi uso básico.

Últimamente me pasa mucho más a mí también con el color único IKEA GU10. Una especie de dolor en el trasero. Sin embargo, los nodos no se vuelven rojos para mí, solo están atenuados. Reaccionarán a las pulsaciones de botones remotos, pero no a través de Phoscon o HA.

¿DeCONZ aún actualiza el estado de las luces cuando las controlas desde el control remoto?

Esto suele ocurrir cuando deCONZ ha perdido la ruta hacia la lámpara. La lámpara aún está en la red, puede alcanzar la puerta de enlace y recibe transmisiones. Sin embargo, la puerta de enlace no puede alcanzar la luz a través de unidifusión. Como solución alternativa, puede usar /groups comandos en lugar de /lights , por lo que deCONZ envía transmisiones en su lugar.

Todavía tengo el mismo problema ocasionalmente (~ una vez a la semana) con mi Xiaomi Curtain Controller (que es un enrutador ZigBee). El _Aviso del dispositivo_ después de apagar y encender el dispositivo hace que deCONZ vuelva a aprender la ruta.

Estos problemas de enrutamiento se introdujeron con el soporte para el descubrimiento de enrutamiento utilizado por las luces Trådfri, por lo que 2.04.40 suena correcto.

@ebaauw Cuando una luz no está disponible, los comandos de grupo funcionan para mí, pero solo por un tiempo limitado. Después de eso, la luz sigue encendida o apagada y ya no responde a un comando de grupo. Usando un interruptor de atenuación de tono enlazado (enlace creado al agregar las luces al grupo creado de forma predeterminada cuando se empareja un interruptor de atenuación de tono en la aplicación Phoscon).

¿DeCONZ aún actualiza el estado de las luces cuando las controlas desde el control remoto?

Esto suele ocurrir cuando deCONZ ha perdido la ruta hacia la lámpara. La lámpara aún está en la red, puede alcanzar la puerta de enlace y recibe transmisiones. Sin embargo, la puerta de enlace no puede alcanzar la luz a través de unidifusión. Como solución alternativa, puede usar /groups comandos en lugar de /lights , por lo que deCONZ envía transmisiones en su lugar.

Revisaré estas sugerencias la próxima vez. Pero sí, por lo general vuelven, corté la energía durante un par de minutos. Por cierto, uso el mando a distancia "hockey puck" de IKEA.

Todavía tengo el mismo problema ocasionalmente (~ una vez a la semana) con mi Xiaomi Curtain Controller (que es un enrutador ZigBee). El _Aviso del dispositivo_ después de apagar y encender el dispositivo hace que deCONZ vuelva a aprender la ruta.

Estos problemas de enrutamiento se introdujeron con el soporte para el descubrimiento de enrutamiento utilizado por las luces Trådfri, por lo que 2.04.40 suena correcto.

Hmm, no creo que esto haya sido tan malo para mí durante tanto tiempo. Lo he mantenido actualizado continuamente.

Hmm, no creo que esto haya sido tan malo para mí durante tanto tiempo.

Es un problema intermitente. No he podido reproducirlo a voluntad, vea el n. ° 849. De hecho, todas mis reglas para controlar las luces se basan en acciones /groups , por lo que nunca noté el problema antes, hasta que obtuve el controlador de cortina.

Cuando una luz no está disponible, los comandos de grupo funcionan para mí, pero solo por un tiempo limitado. Después de eso, la luz sigue encendida o apagada y ya no responde a un comando de grupo.

Teorizaría que la luz decide abandonar la red cuando no recibe ACK de la puerta de enlace para sus informes de atributos durante un tiempo prolongado.

Teorizaría que la luz decide abandonar la red cuando no recibe ACK de la puerta de enlace para sus informes de atributos durante un tiempo prolongado.

Para mí, esto sucede también con las luces que estaban encendidas o solo unos minutos / horas antes.

Como publiqué algunas respuestas arriba, la mayoría de mis luces GU10 están unidas a un interruptor de atenuación de tono (3-8 en una habitación con un interruptor de atenuación de tono propio). Algunos no lo están, y están en línea desde hace meses. Ninguno de ellos dejó de estar disponible. Coincidencia, o no ... ¿Qué opinas de esto @ebaauw?

la mayoría de mis luces GU10 están unidas a un interruptor de atenuación de tono

Eso parece poco probable. ¿Creó un enlace en el panel _Bind Dropbox_ en la GUI de deCONZ desde el regulador de intensidad hasta la luz?

Tenga en cuenta que "vinculación" en términos de ZigBee significa: crear una entrada en la tabla de vinculación del dispositivo a qué dirección ZigBee enviar comandos desde el clúster vinculado. Creo que los clústeres (cliente!) _OnOff_ y _Level Control_ de su regulador de intensidad están vinculados a un grupo (por el complemento deCONZ REST API). Este grupo aparece en el recurso ZHASwitch en config.group . A continuación, la luz se ha agregado a este grupo. Los grupos de ZigBee son más como direcciones de multidifusión, por lo que probablemente sea más correcto decir que la luz se ha suscrito a los mensajes de este grupo.

En teoría, supongo, el firmware ligero podría tener un error, haciendo que se cuelgue mientras procesa los comandos recibidos a través de un grupo. Sin embargo, no creo que esto sea probable. Miraría qué tan cerca (cuántos saltos sobre la red ZigBee) están las luces de la RaspBee / ConBee y / o si todas las luces tienen la misma revisión de hardware y firmware. IKEA parece estar lanzando nuevas versiones ZigBee 3.0 (ZHA) de todos sus dispositivos.

la mayoría de mis luces GU10 están unidas a un interruptor de atenuación de tono

Eso parece poco probable. ¿Creó un enlace en el panel _Bind Dropbox_ en la GUI de deCONZ desde el regulador de intensidad hasta la luz?

Tenga en cuenta que "vinculación" en términos de ZigBee significa: crear una entrada en la tabla de vinculación del dispositivo a qué dirección ZigBee enviar comandos desde el clúster vinculado. Creo que los clústeres (cliente!) _OnOff_ y _Level Control_ de su regulador de intensidad están vinculados a un grupo (por el complemento deCONZ REST API). Este grupo aparece en el recurso ZHASwitch en config.group . A continuación, la luz se ha agregado a este grupo. Los grupos de ZigBee son más como direcciones de multidifusión, por lo que probablemente sea más correcto decir que la luz se ha suscrito a los mensajes de este grupo.

No, no creé un enlace en el panel de _Bind Dropbox_ en la GUI de deCONZ.

¿Quiere decir que agregar luces a estos grupos en la aplicación Phoscon no crea un vínculo entre el control remoto y las luces? Supuse que sí, porque también es posible cambiar las luces agregadas con el interruptor de atenuación de tono correspondiente cuando mi contenedor docker deCONZ o todo el NUC está desconectado.

Ok, ahora tengo un bulp que no responde. Estaba atenuado en bth deCONZ y Phoscon.

Reaccionó a los comandos remotos y también cuando moví el control deslizante en el modo "grupo" en Phoscon,

¿DeCONZ aún actualiza el estado de las luces cuando las controlas desde el control remoto?

No al principio, ya que estaba atenuado.

Luego intenté con "restablecer el nodo seleccionado" en deCONZ, y luego, durante unos minutos, ya no se atenuó a pesar de que ya no tenía el botón de radio de clúster en deCONZ.

Todavía solo respondió a comandos remotos y grupales, pero ahora se actualizó el estado de la luz.

Después de un tiempo, volvió a atenuarse en Phoscon.

Luego intenté cortar la energía durante unos minutos. No ayudó.

Esta noche ocurrió una situación interesante:

Una de las luces GU10 blancas cálidas de Tradfri ha vuelto a estar desconectada desde hace unas horas. El interruptor de atenuación Hue, que está vinculado a 8 GU10, incluido el que ahora está fuera de línea, enciende / apaga, según deconz, GU10 fuera de línea. Bastante extraño, solo ese.
Los otros GU10 no responden al interruptor de atenuación Hue enlazado.

Al cambiar el grupo con el resto de la API, se encenderán / apagarán todas las luces, incluida la GU10 sin conexión.

Cuando un GU10 se desconectó antes, el interruptor de atenuación Hue enlazado enciende / apaga todas las luces del grupo, incluido, según tot deconz, GU10 desconectado (tarde o temprano, según deconz, el GU10 desconectado también deja de escuchar los comandos del grupo ya sea).

¿Podría ser útil esto?

\ Editar: El 'Nombre' de este GU10 sin conexión en deCONZ a través de VNC está vacío.

Al completar esto nuevamente, no está configurado (nunca lo hice aquí, normalmente en la aplicación Phoscon):

Todavía amarillo tampoco:

Al presionar '0' o 'Restablecer nodo seleccionado' no se vuelve a poner el GU10 en línea.

Edición 2 : Aproximadamente 24 horas después de que el GU10 se desconectó, el GU10 ya no responde al interruptor de atenuación Hue enlazado como se describió anteriormente. Ninguna de las luces GU10 del grupo no responde ahora. El nodo en deCONZ GUI sigue siendo amarillo pero el nombre está en gris.
Después de apagar y encender la luz GU10 fuera de línea, las 8 luces del grupo, incluida la que estaba fuera de línea, están respondiendo nuevamente al interruptor de atenuación Hue enlazado.

@manup Este comportamiento / situación es bastante diferente al anterior, ¿tal vez esto pueda ayudar a encontrar la causa?

Me acabo de dar cuenta de una adición, tal vez, interesante a este número.

Varias habitaciones están equipadas con múltiples puntos Tradfri GU10 y la mayoría de las habitaciones con un interruptor de atenuación de tono, con un enlace directo a los GU10 en la habitación creada al agregarlos al grupo de interruptores de atenuación de tono en la aplicación Phoscon.

• Solo los GU10 con un enlace directo con un interruptor de atenuación de tono se desconecta de vez en cuando y necesitan un ciclo de energía para volver a conectarse.
• Los GU10 sin un enlace directo con un interruptor de atenuación de tono no se desconectan.

Desafortunadamente, uno de mis Tradfri GU10 warmwhite sin un interruptor de atenuación Hue enlazado está fuera de línea desde ayer.

Todavía me pregunto por qué algunos puntos GU10 (el mismo blanco cálido) están _nunca_ fuera de línea.
\ Editar : También un GU10 que estuvo en línea durante meses, está fuera de línea desde ayer.

Compré un Tradfri Hub el fin de semana pasado y emparejé todos los lugares GU10 de una habitación con él. Veamos qué pasa en las próximas semanas.

Las luces aleatorias en mi sistema comenzaron a no responder después de que agregué cuatro interruptores de encendido / apagado de IKEA a mi sistema (para las luces de las ventanas de Navidad) ... Los enchufes están distribuidos en toda mi casa. Al menos una de mis luces en mi sistema debe apagarse y encenderse por día.

¿Puedo proporcionar algún tipo de registros o información para facilitar la resolución de problemas?

@tubalainen ¿A qué te refieres con no receptivo? ¿Están respondiendo por sí mismos o necesitan un ciclo de energía?

@tubalainen ¿A qué te refieres con no receptivo? ¿Están respondiendo por sí mismos o necesitan un ciclo de energía?

Están listados como "en línea" (no en gris) y son parte de la malla de acuerdo con mi imagen, pero cuando se activan en Home Assistant (oa través de phoscon) no sucede nada. Para que vuelvan a funcionar, necesito apagar y encender.

¿Hay algún progreso en esto? Se está volviendo un poco ridículo con mis luces GU10 en gris :(

Creo que vi a alguien mencionar el controlador de cortina o el interruptor de encendido / apagado. De hecho, se me ocurre que los problemas empeoraron mucho cuando me compré las persianas FYRTUR. Este también fue el primer botón de ikea que agregué a la red ... no ...

No tengo interruptores de pared Tradfri on / off o cortinas IKEA aquí y tengo el problema.

Tuve este problema durante el verano. Mis GU10 se desconectaban todo el tiempo. Actualicé todos mis GU10 al último software de "prueba" y he estado funcionando sin problemas durante casi dos meses.

El fin de semana pasado agregué un par de nuevas bombillas E27 y ahora varias de mis GU10 se están cayendo todo el tiempo nuevamente.

Tuve este problema durante el verano. Mis GU10 se desconectaban todo el tiempo. Actualicé todos mis GU10 al último software de "prueba" y he estado funcionando sin problemas durante casi dos meses.

El fin de semana pasado agregué un par de nuevas bombillas E27 y ahora varias de mis GU10 se están cayendo todo el tiempo nuevamente.

¿Qué bombillas GU10 tiene y qué firmware instaló?

Compré un Tradfri Hub el fin de semana pasado y emparejé todos los lugares GU10 de una habitación con él. Veamos qué pasa en las próximas semanas.

Cuando usé la puerta de enlace Tradfri, tenía bombillas que no respondían casi todos los días (espectro blanco Tradfri GU10, primera generación). Cambié al puente Philips Hue y el problema pareció desaparecer, pero después de 2 semanas, una bombilla dejó de responder (como de costumbre, un ciclo de encendido resolvió el problema).

No estoy seguro de por qué y cómo funciona mejor el puente Hue con las bombillas Tradfri, pero me parece que el problema real son las bombillas.

No tengo un solo GU10 y todavía tengo el problema.

Por favor, dígame cómo puedo ayudar con los registros, etc. para intentar resolver esto.
¿Parece ligero (mi suposición aquí) que algunos nodos "se duermen" y no se despiertan al primer intento de despertarlos?

¿Es esto solo un problema cuando hay varios saltos de nodo en la malla? Para mí, es bastante consecuente cuando hay más de un salto en la conbee. De nuevo, solo un sentimiento. No confirmado.

Tengo 8 GU-10 de unos 18 meses. Uno de ellos se ha vuelto gris una vez en ese tiempo. Están todos en la misma habitación que el palo de conbee. Tengo unas bombillas de 980lm de 3 años. El más alejado del salto gw a través de un gu 10 se vuelve gris tal vez una vez cada quince días.
@tubalainen podría estar en algo.

Junto al que se está volviendo gris, tengo un Osram que nunca se ha estropeado.

Sí, @tubalainen podría tener una pista. De hecho, he estado colocando mis GU10 grises en un portalámparas en un cable que uso cuando agrego nuevas luces y cuando están adentro, muchas veces simplemente vuelven a la vida. Pero luego, cuando los pongo de nuevo en su lugar, están fuera de nuevo. No es 100% consistente que regresen, pero aún podría ser una cómplice.

Aquí hay otra pista potencial. Nunca he tenido ninguna lámpara que se vuelva gris (en más de un año de tiempo de actividad con 8 lámparas IKEA), pero luego actualicé el complemento deconz Home Assistant de 3.8 a 3.9 y en dos días tuve dos GU10 que se volvieron grises restauró una copia de seguridad de la versión 3.8 del complemento y no ha habido problemas desde entonces. Lo extraño es que el complemento 3.8 y 3.9 usa la misma versión deconz (si el registro de cambios está completo). Sin embargo, incluso en Phoscon, las lámparas eran inaccesibles. Todo esto es bastante extraño, pero supongo que la versión 3.9 del complemento hace algún tipo de solicitud de desconz que hace que las lámparas IKEA sean inestables.

No uso HA y todavía sufro el problema. Compré algunos ne GU10 y ahora reemplazo todas las lámparas que se vuelven grises más de una vez. Cualquier lámpara que haya reemplazado todavía no se volvió gris nuevamente. Puede ser un problema de hardware, puede que no, pero parece que no tendremos una solución pronto.

Tengo problemas similares. Algunos de los nodos de luz no responden a los comandos y se vuelven grises. Lo extraño es que si envío comandos grupales, el mismo nodo de luz responde perfectamente cada vez.

Tengo problemas similares. Algunos de los nodos de luz no responden a los comandos y se vuelven grises. Lo extraño es que si envío comandos grupales, el mismo nodo de luz responde perfectamente cada vez.

¿Sigue funcionando un comando de grupo después de, digamos, unos días o más de una semana?
En mi caso: tarde o temprano la luz también deja de escuchar los comandos del grupo.

Tengo problemas similares. Algunos de los nodos de luz no responden a los comandos y se vuelven grises. Lo extraño es que si envío comandos grupales, el mismo nodo de luz responde perfectamente cada vez.

¿Sigue funcionando un comando de grupo después de, digamos, unos días o más de una semana?
En mi caso: tarde o temprano la luz también deja de escuchar los comandos del grupo.

Sí, también parece funcionar bien con el tiempo. Pero tengo una teoría de lo que está mal. Cuando los nodos de luz se enrutan a través de la bombilla TRADFRI E27 WS opal 1000lm, se producen problemas. Así que ayer apagué los dos que tenía en mi red. Desde entonces todo parece funcionar a la perfección.

Tengo bombilla TRADFRI GU10 WS 400lm, bombilla TRADFRI E14 CWS opal 600lm y bombilla TRÅDFRI E27 CWS opal 600lm. No parecen causar ningún problema.

Podría estar relacionado con el firmware Trådfri anterior. Las luces más recientes vienen con firmware más reciente, pero no creo que IKEA haya publicado un firmware actualizado para todas las luces de primera generación. No tengo ningún spot Trådfri GU10, pero por bombilla CWS recibí una actualización de firmware. Mi bombilla regulable de 1000 lm no lo hizo; No estoy seguro de la bombilla del espectro blanco.

Podría estar relacionado con el firmware Trådfri anterior. Las luces más recientes vienen con firmware más reciente, pero no creo que IKEA haya publicado un firmware actualizado para todas las luces de primera generación. No tengo ningún spot Trådfri GU10, pero por bombilla CWS recibí una actualización de firmware. Mi bombilla regulable de 1000 lm no lo hizo; No estoy seguro de la bombilla del espectro blanco.

Mi bombilla TRADFRI GU10 WS 400lm tiene el mismo firmware, 2.0.022. No parecen causar problemas (todavía :))

Podría estar relacionado con el firmware Trådfri anterior. Las luces más recientes vienen con firmware más reciente, pero no creo que IKEA haya publicado un firmware actualizado para todas las luces de primera generación. No tengo ningún spot Trådfri GU10, pero por bombilla CWS recibí una actualización de firmware. Mi bombilla regulable de 1000 lm no lo hizo; No estoy seguro de la bombilla del espectro blanco.

Estoy de acuerdo. La primera versión de las bombillas Ikea (en el firmware 1. *) tenía algún error de software / hardware que no afecta las segundas iteraciones (en 2. *).

Lamentablemente, parece que Ikea ya no admite la versión original y no proporcionará ninguna actualización de firmware. Al mismo tiempo, no es posible devolver las bombillas y cambiarlas por otras nuevas (lo he probado en el Reino Unido).

Podría estar relacionado con el firmware Trådfri anterior. Las luces más recientes vienen con firmware más reciente, pero no creo que IKEA haya publicado un firmware actualizado para todas las luces de primera generación. No tengo ningún spot Trådfri GU10, pero por bombilla CWS recibí una actualización de firmware. Mi bombilla regulable de 1000 lm no lo hizo; No estoy seguro de la bombilla del espectro blanco.

Estoy de acuerdo. La primera versión de las bombillas Ikea (en el firmware 1. *) tenía algún error de software / hardware que no afecta las segundas iteraciones (en 2. *).

Lamentablemente, parece que Ikea ya no admite la versión original y no proporcionará ninguna actualización de firmware. Al mismo tiempo, no es posible devolver las bombillas y cambiarlas por otras nuevas (lo he probado en el Reino Unido).

Tengo bombillas cws en 1.3.009. No parecen causar problemas.

Actualizar:

Parece que otras bombillas de IKEA también están causando problemas.

Aquí están mis bombillas IKEA. Hasta ahora, solo la bombilla TRADFRI E27 WS opal 1000lm está causando problemas. Ahora están desconectados y las cosas parecen funcionar. Pero publico una actualización si recibo nuevos errores.

Parece que no tengo ningún dispositivo 2.x.
Algunos GU10 funcionan bien, otros no. Comencé a reemplazar los defectuosos por unos "nuevos" que compré unos meses después. Parecen ejecutar el mismo firmware, aunque hay un número "1808 -S" impreso en el zócalo, mientras que los "más nuevos" tienen "1729-S".
Reemplacé 3 bombillas hasta ahora y no ocurrieron nuevos problemas durante 2 semanas. No solo tuve el problema con GU10 sino también con un Panel FLOALT que no reemplacé.

Parece que no tengo ningún dispositivo 2.x. Algunos GU10 funcionan bien, otros no. Comencé a reemplazar los defectuosos por unos "nuevos" que compré unos meses después. Parecen ejecutar el mismo firmware, aunque hay un número "1808 -S" impreso en el zócalo, mientras que los "más nuevos" tienen "1729-S". Reemplacé 3 bombillas hasta ahora y no ocurrieron nuevos problemas durante 2 semanas. No solo tuve el problema con GU10 sino también con un Panel FLOALT que no reemplacé.

¡Interesante! Echaré un vistazo a mis bombillas para ver si existe algún tipo de correlación.

Parece que uno de mis nodos se ha visto afectado por el problema nuevamente. Todavía tengo algunos nodos de IKEA en la red, así que haré algunas pruebas para ver si puedo sacar algunas conclusiones.

Tengo bombilla TRADFRI GU10 WS 400lm, bombilla TRADFRI E14 CWS opal 600lm y bombilla TRÅDFRI E27 CWS opal 600lm. No parecen causar ningún problema.

Parece que después de que la malla ha estado activa por un tiempo, incluso los otros dispositivos IKEA están causando problemas y los nodos dejan de responder a los comandos. Incluso otros nodos de IKEA pueden verse afectados, me parece que los problemas comienzan a aparecer y luego los nodos se enrutan a través de un nodo de IKEA.

¿Hay alguna actividad planeada para analizar esto? Moveré todos mis dispositivos IKEA a mi puerta de enlace hue mientras esto se resuelve.

los nodos se detienen para responder a los comandos.

¿Estás seguro de que este es el caso? ¿Ha confirmado esto olfateando el tráfico de ZigBee? ¿Los otros nodos ya no reaccionan a los interruptores inalámbricos que controlan las luces sin pasar por la puerta de enlace? ¿Ya no reaccionan a los comandos del grupo?
En mi experiencia, el problema es que la puerta de enlace ya no conoce la ruta a los otros nodos, por lo que los comandos de unidifusión de la puerta de enlace nunca llegan a los otros nodos. Los propios nodos responden bien, simplemente no reciben nada a lo que responder.

Incluso otros nodos de IKEA pueden verse afectados, me parece que los problemas comienzan a aparecer y luego los nodos se enrutan a través de un nodo de IKEA.

El (¿no?) Nodo de enrutamiento de IKEA de alguna manera rompe la ruta desde y / o el descubrimiento de ruta por la puerta de enlace a los otros nodos.

¿Hay alguna actividad planeada para analizar esto?

Tendrás que pedir ayuda a dresden elektronik. El enrutamiento lo maneja el firmware RaspBee / ConBee (¿y el programa central deCONZ?). No podemos hacer nada al respecto en el complemento de la API REST.

Compré un Tradfri Hub el fin de semana pasado y emparejé todos los lugares GU10 de una habitación con él. Veamos qué pasa en las próximas semanas.

Tal vez sea un poco pronto para decirlo, pero hace 29 días moví todos los Tradfri GU10 (8x warmwhite - 1.2.214) de una habitación a un Tradfri Hub, y ninguno de ellos dejó de responder hasta ahora.

Tal vez sea un poco pronto para decirlo, pero hace 29 días moví todos los Tradfri GU10 (8x warmwhite - 1.2.214) de una habitación a un Tradfri Hub, y ninguno de ellos dejó de responder hasta ahora.

Yo lo esperaba. El problema no es tanto causado por dispositivos de un solo fabricante, como por la interacción entre dispositivos de diferentes fabricantes, interpretando el estándar ZigBee de manera diferente. Es por eso que la mayoría de los hubs / gateways / bridges solo admiten sus propios dispositivos. Un experimento más interesante sería conectar los puntos de Trådfri a con el puente Hue o la puerta de enlace OSRAM.

Además, ocho luces en una sola habitación probablemente darán como resultado una conexión directa entre el concentrador y cada luz: todas las conexiones de un solo salto. Los problemas de enrutamiento aparecen solo con redes más grandes, con más dispositivos que entradas en una tabla vecina (generalmente alrededor de 20); y / o con dispositivos físicamente fuera del alcance del concentrador.

los nodos se detienen para responder a los comandos.

¿Estás seguro de que este es el caso? ¿Ha confirmado esto olfateando el tráfico de ZigBee? ¿Los otros nodos ya no reaccionan a los interruptores inalámbricos que controlan las luces sin pasar por la puerta de enlace? ¿Ya no reaccionan a los comandos del grupo?
En mi experiencia, el problema es que la puerta de enlace ya no conoce la ruta a los otros nodos, por lo que los comandos de unidifusión de la puerta de enlace nunca llegan a los otros nodos. Los propios nodos responden bien, simplemente no reciben nada a lo que responder.

No tengo experiencia ni equipo para olfatear el tráfico. Probablemente tenga razón sobre cómo se está comportando el problema. Mis nodos responden a los comandos de grupo todo el tiempo. El problema es (si lo entiendo) que los comandos de unidifusión nunca llegan a su destino.

Siempre y cuando solo envíe comandos de grupo, todo parece funcionar bastante bien.

Incluso otros nodos de IKEA pueden verse afectados, me parece que los problemas comienzan a aparecer y luego los nodos se enrutan a través de un nodo de IKEA.

El (¿no?) Nodo de enrutamiento de IKEA de alguna manera rompe la ruta desde y / o el descubrimiento de ruta por la puerta de enlace a los otros nodos.

¿Hay alguna actividad planeada para analizar esto?

Tendrás que pedir ayuda a dresden elektronik. El enrutamiento lo maneja el firmware RaspBee / ConBee (¿y el programa central deCONZ?). No podemos hacer nada al respecto en el complemento de la API REST.

Sí, les envié un correo electrónico, pero no obtuve ninguna respuesta además de una lista de verificación.

Tal vez sea un poco pronto para decirlo, pero hace 29 días moví todos los Tradfri GU10 (8x warmwhite - 1.2.214) de una habitación a un Tradfri Hub, y ninguno de ellos dejó de responder hasta ahora.

Yo lo esperaba. El problema no es tanto causado por dispositivos de un solo fabricante, como por la interacción entre dispositivos de diferentes fabricantes, interpretando el estándar ZigBee de manera diferente. Es por eso que la mayoría de los hubs / gateways / bridges solo admiten sus propios dispositivos. Un experimento más interesante sería conectar los puntos de Trådfri a con el puente Hue o la puerta de enlace OSRAM.

Además, ocho luces en una sola habitación probablemente darán como resultado una conexión directa entre el concentrador y cada luz: todas las conexiones de un solo salto. Los problemas de enrutamiento aparecen solo con redes más grandes, con más dispositivos que entradas en una tabla vecina (generalmente alrededor de 20); y / o con dispositivos físicamente fuera del alcance del concentrador.

He hecho esto para asegurarme de que no está relacionado con el firmware 1.2.214 del antiguo GU10, que se menciona mucho aquí como una posible causa (y una posible razón para hacer una nueva versión del GU10).
Quizás en relación con conectado a través de otro enrutador.

Consideraré emparejar mis otras luces GU10 (también blancas cálidas 1.2.214) con el Tradfri Hub también (también las del piso 2de / 3th)

¿Hay algún progreso en esto? Se está volviendo un poco ridículo con mis luces GU10 en gris :(

Creo que vi a alguien mencionar el controlador de cortina o el interruptor de encendido / apagado. De hecho, se me ocurre que los problemas empeoraron mucho cuando me compré las persianas FYRTUR. Este también fue el primer botón de ikea que agregué a la red ... no ...

No he tenido el interruptor de encendido / apagado de fyrtur en la red desde mi última publicación y no tuve abandonos en ese tiempo. ¿Podría ser una coincidencia ...?

¿Hay algún progreso en esto? Se está volviendo un poco ridículo con mis luces GU10 en gris :(
Creo que vi a alguien mencionar el controlador de cortina o el interruptor de encendido / apagado. De hecho, se me ocurre que los problemas empeoraron mucho cuando me compré las persianas FYRTUR. Este también fue el primer botón de ikea que agregué a la red ... no ...

No he tenido el interruptor de encendido / apagado de fyrtur en la red desde mi última publicación y no tuve abandonos en ese tiempo. ¿Podría ser una coincidencia ...?

No, no tengo ninguna cortina Tradfri on / off o Tradfri y tengo este problema.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -562299982

Se cerró accidentalmente este problema. Reapertura.

Un experimento más interesante sería conectar los puntos de Trådfri a con el puente Hue o la puerta de enlace OSRAM.

Tuve el mismo problema con las bombillas Trådfri (primera generación) conectadas al concentrador Trådfri. El problema desapareció por completo cuando moví todas las bombillas a un puente Hue.

Por cierto, todavía estoy convencido de que la primera generación de bombillas Trådfri tiene micrófonos, pero el puente Hue maneja las luces de manera diferente (he notado que en algún momento las luces se desincronizan durante una fracción de segundo cuando se conectan a Hue, nunca sucedió con Trådfri ).

el puente Hue maneja las luces de manera diferente (he notado que en algún momento las luces se desincronizan durante una fracción de segundo cuando se conectan a Hue, nunca sucedió con Trådfri).

En la configuración de Hue, las luces solo están controladas por el puente Hue: los interruptores y sensores inalámbricos envían notificaciones al puente, lo que activa reglas que controlan las luces. El puente predice el estado de la luz y actualiza su caché por adelantado cuando envía comandos a las luces. Sondea las luces periódicamente para validar / actualizar el estado en caché.

En la configuración de Trådfri, las luces se controlan directamente mediante comandos de interruptores y sensores inalámbricos. Luego, las luces envían un informe con el estado actualizado al concentrador.

Al controlar las luces conectadas a un puente Hue directamente desde interruptores o sensores inalámbricos (Trådfri), verá un retraso porque el puente Hue no configura los informes de atributos en las luces. Cuantas más luces haya en su red, mayor será la demora, ya que el sondeo pasa por más luces.

Al conectar las bombillas Hue a un concentrador Trådfri y controlar esas luces directamente desde interruptores o sensores inalámbricos (Trådfri), el estado del concentrador nunca se actualizará, ya que las luces Hue no generan informes de atributos y el concentrador Trådfri no realiza sondeos.

Tenga en cuenta que estas diferencias se encuentran en el nivel de la aplicación, dentro del control del complemento de la API REST. El enrutamiento se encuentra en un nivel inferior en la pila ZigBee.

Ahora todos los nodos de mi enrutador IKEA se mueven a mi puente de tono. Todavía tengo el mismo problema en mi red. Entonces sospecho que es algo más lo que lo está causando. Y nuevamente afecta a los nodos que están enrutados y no tienen un enlace directo a la puerta de enlace.

Ahora todos los nodos de mi enrutador IKEA se mueven a mi puente de tono. Todavía tengo el mismo problema en mi red. Entonces sospecho que es algo más lo que lo está causando. Y nuevamente afecta a los nodos que están enrutados y no tienen un enlace directo a la puerta de enlace.

¿El mismo problema con las luces Tradfri que ahora están emparejadas con el puente Hue?

@ebaauw ¿ Debería aparecer el problema de enrutamiento cuando una luz está conectada al puente directamente Y a través de un enrutador, o solo cuando no está conectada directamente al puente?

Ahora todos los nodos de mi enrutador IKEA se mueven a mi puente de tono. Todavía tengo el mismo problema en mi red. Entonces sospecho que es algo más lo que lo está causando. Y nuevamente afecta a los nodos que están enrutados y no tienen un enlace directo a la puerta de enlace.

¿El mismo problema con las luces Tradfri que ahora están emparejadas con el puente Hue?

Solo tengo 3 bombillas emparejadas. Pero no hay problemas que haya notado.

@ebaauw ¿ Debería aparecer el problema de enrutamiento cuando una luz está conectada al puente directamente Y a través de un enrutador, o solo cuando no está conectada directamente al puente?

En mi red, mi experiencia es que los problemas con los comandos perdidos afectan a los nodos que se enrutan a través de otros nodos y no directamente con la puerta de enlace. Ahora tengo los mismos problemas incluso cuando no hay bombillas IKEA conectadas.

Tenía un nodo (1) sin enlace directo a la puerta de enlace. No respondió (o como mencionó ebaauw, tal vez nunca lleguen al nodo debido a problemas de enrutamiento) a los comandos de unidifusión. Cuando apagué el nodo (2), se enrutó a través del nodo (1) obtuvo una ruta directa a la puerta de enlace y comenzó a funcionar perfectamente.

¿Debería aparecer el problema de enrutamiento cuando una luz está conectada al puente directamente Y a través de un enrutador, o solo cuando no está conectada directamente al puente?

No existen las "conexiones" en ZigBee. Cada enrutador mantiene una tabla de vecinos de dispositivos cercanos, a la que se puede acceder directamente (a nivel MAC). Las líneas en la GUI de deCONZ no son más que una representación gráfica de estas tablas vecinas (en la medida en que deCONZ las haya leído).

Cuando un enrutador necesita enviar un mensaje a un dispositivo que no está en su tabla vecina, envía la solicitud a un enrutador vecino para que puedan reenviarlo. El mensaje único a nivel NWK se retransmite a través de múltiples saltos a nivel MAC. El RaspBee / ConBee (en esta perspectiva) es solo otro enrutador. Afaik un dispositivo final solo envía mensajes a su enrutador principal.

Entonces, cuando hay una luz en la tabla vecina de RaspBee / ConBee, no se involucra ningún descubrimiento de ruta, independientemente de si esa luz es la tabla vecina de otros enrutadores. Cuando no lo es, RaspBee / ConBee necesita averiguar qué enrutador vecino sabe cómo alcanzar la luz. Si la luz está a varios saltos de distancia, cada enrutador en el camino hacia ella de forma recursiva debe hacer lo mismo.

Me temo que no entiendo los detalles, pero hay varias formas de hacer este descubrimiento de ruta. Cuando los enrutadores en la ruta entre la puerta de enlace y la lámpara utilizan formas diferentes, las cosas pueden salir mal. Es posible que la puerta de enlace termine enviando el mensaje al enrutador vecino incorrecto (que no sabe cómo llegar a la luz), o que la puerta de enlace no sepa cómo llegar a la luz y no envíe ningún mensaje. Los mensajes de unidifusión generalmente deben responderse con un ACK, por lo que la puerta de enlace marcará un dispositivo como inaccesible cuando no reciba el ACK. Por supuesto, no hay forma de saber si se perdió el mensaje original o el ACT (el dispositivo remoto necesita conocer la ruta a la puerta de enlace para enviar el ACK).

Los mensajes de difusión (utilizados por los comandos de grupos) no utilizan ningún enrutamiento; son simplemente retransmitidos a nivel MAC por todos los enrutadores. Si bien son muy confiables, consumen mucho ancho de banda de red. Además, no son respondidos por un ACK.

En mi red, mi experiencia es que los problemas con los comandos perdidos afectan a los nodos que se enrutan a través de otros nodos y no directamente con la puerta de enlace. Ahora tengo los mismos problemas incluso cuando no hay bombillas IKEA conectadas.

Entonces, para problemas de enrutamiento, necesita una red que sea lo suficientemente grande para que los dispositivos no aparezcan en la tabla de enrutamiento de RaspBee / ConBee. Ya sea porque la cantidad de dispositivos excede el tamaño de la tabla de enrutamiento, o porque los dispositivos remotos están físicamente fuera del alcance de RaspBee / ConBee y solo se puede acceder a ellos a través de otros enrutadores. Supongo que varios saltos empeorarían el problema.

Nuevamente, no es tanto culpa de IKEA como de diferentes fabricantes que utilizan formas diferentes y algo incompatibles para hacer el descubrimiento de rutas. Especialmente con las rutas de varios saltos, hay mucho que se puede solucionar en el firmware RaspBee / ConBee.

Tenía un nodo (1) sin enlace directo a la puerta de enlace. No respondió (o como mencionó ebaauw, tal vez nunca lleguen al nodo debido a problemas de enrutamiento) a los comandos de unidifusión. Cuando apagué el nodo (2), se enrutó a través del nodo (1) obtuvo una ruta directa a la puerta de enlace y comenzó a funcionar perfectamente.

Nuevamente, me temo que no entiendo los detalles, pero puedo pensar en múltiples escenarios que causarían este comportamiento. El RaspBee / ConBee quiere enviar un mensaje al nodo2 o al nodo1, no recibe un ack, concluye que el nodo2 es inalcanzable y lo elimina de su tabla vecina. La tabla ahora tiene espacio para una nueva entrada, que se usa para el nodo1.

Nuevamente, no es tanto culpa de IKEA como de diferentes fabricantes que utilizan formas diferentes y algo incompatibles para hacer el descubrimiento de rutas. Especialmente con las rutas de varios saltos, hay mucho que se puede solucionar en el firmware RaspBee / ConBee.

Esto me suena a que el enfoque de una plataforma ZigBee de múltiples proveedores está condenado por diseño hasta que se establezca y se siga un estándar más completo. Aún así, estoy un poco bloqueado en este momento, ya que no quiero usar múltiples puertas de enlace que probablemente no funcionarían en mi entorno de todos modos (por ejemplo, para sensores a los que la puerta de enlace no puede acceder directamente si elimino las bombillas que actualmente actúan como enrutadores).

Esto me parece que el enfoque de una plataforma ZigBee de múltiples proveedores está condenado

Seguramente espero que no, pero definitivamente es un desafío. El tamaño parece importar aquí: si su red es lo suficientemente pequeña, es posible que no se encuentre con estos problemas de enrutamiento en absoluto. Además, si el centro (geográfico) de su red consiste en enrutadores de proveedores compatibles, algunos enrutadores menos compatibles en el borde de su red probablemente no importarán (ya que no están enrutados para llegar a otros dispositivos).

Reemplacé mis bombillas OSRAM, Trådfri e innr (que estaban causando problemas) por bombillas Hue. Ahora tengo 104 nodos, 51 enrutadores y 53 dispositivos finales. 2/3 de los enrutadores son luces Hue. El único enrutador que se vuelve inalcanzable (pero que aún envía informes) es el controlador de cortina Xiaomi. 20 de los dispositivos finales son Hue, 20 Xiaomi, 8 Eurotronic Spirit y 5 IKEA. El Eurotronic Spirit e IKEA Fyrtur me están causando problemas con regularidad (sus padres los expulsan, pero no encuentran un nuevo padre, nuevamente inalcanzable por la puerta de enlace, pero aún envían informes), los demás parecen estar bien. Para todos los dispositivos, el ciclo de energía generalmente soluciona la situación, pero a veces necesito abrir la red cuando reinicia el dispositivo.

He estado considerando dividir mi red, no por proveedor, sino por piso o lado de la calle frente a la parte trasera de mi casa. Esto es mucho trabajo y soy reacio a hacerlo, hasta que tenga una mejor comprensión de qué está causando los problemas en detalle y qué configuración podría evitar que sucedan.

@ebaauw , pensando en lo que dijo en la publicación anterior, sería interesante considerar una especie de preferencia por la tabla de enrutamiento deCONZ. ¿Podríamos considerar la inclusión de enrutadores en una "lista negra" que no son preferibles como primer salto? Si puede construir su red para contener suficientes enrutadores 'buenos', entonces el primer salto siempre sería a través de ellos y el segundo salto alcanzaría todos los demás dispositivos de la red.
Esa no sería una solución definitiva, pero permitiría redes mucho más grandes (geográficas y en número de dispositivos) mientras siempre pasa por enrutadores "preferidos".

Otro pensamiento: dado que sabemos qué chips utiliza IKEA (Silabs EFR32, motor gecko) y sabemos (de varias fuentes en la red) que utilizan el motor zigbee proporcionado por Silabs, podríamos considerar dos acciones.

1. Analizamos la forma en que el motor silabs realiza el enrutamiento y de ahí derivamos qué está causando este problema.
2. Creamos una versión personalizada del firmware de la lámpara basada en el mismo motor de silabs, solucionamos el problema y encontramos una manera de instalar OTA ese firmware

Ambos requerirían acceso al SDK de Silabs, que yo no. ¿Hay alguien activo aquí que haga ...? No tengo ganas de desembolsar $ 500 por su kit de desarrollo que incluye el SDK. ¿Quizás Dresden Electronics está dispuesta a hacer eso?

mis 2 cts (estoy bastante frustrado con las conexiones perdidas ocasionalmente).

¿Podríamos considerar la inclusión de enrutadores en una "lista negra" que no son preferibles como primer salto?

Nosotros no. Tendría que implementarse en el firmware RaspBee / ConBee, supongo. No es una mala idea en mi humilde opinión, pero no tengo ni idea de lo factible que es esto, dadas las limitaciones de tamaño en la EEPROM y la NVRAM del dispositivo. @manup , ¿qué opinas de esto?

1. Creamos una versión personalizada del firmware de la lámpara basada en el mismo motor de silabs, solucionamos el problema y encontramos una manera de instalar OTA ese firmware

Esto está mucho más allá de mi conocimiento actual y, francamente, mi ambición: hago esto por un pasatiempo. He estado jugando con XBee para ver si puedo escribir una aplicación ZigBee (mi objetivo final sería smartificar mis persianas venecianas), pero nunca he mirado en los niveles inferiores de la pila ZigBee, donde se realiza el enrutamiento. .

Nosotros no. Tendría que implementarse en el firmware RaspBee / ConBee, supongo. No es una mala idea en mi humilde opinión, pero no tengo ni idea de lo factible que es esto, dadas las limitaciones de tamaño en la EEPROM y la NVRAM del dispositivo. @manup , ¿qué opinas de esto?

Supongo que considero a @manup parte de We;)

Esto está mucho más allá de mi conocimiento actual y, francamente, mi ambición: hago esto por un pasatiempo. He estado jugando con XBee para ver si puedo escribir una aplicación ZigBee (mi objetivo final sería smartificar mis persianas venecianas), pero nunca he mirado en los niveles inferiores de la pila ZigBee, donde se realiza el enrutamiento. .

Estoy de acuerdo, para mí también es un pasatiempo, sin embargo, espero que alguien esté más informado sobre estos detalles.

He estado haciendo algo similar usando placas CC2530 Estoy planeando zigbeeificar mi sistema de rociadores (no puedo aceptar que tengo que caminar por el jardín para encender / apagar manualmente ciertos rociadores :)) He podido compilar un Firmware zigbee para mi placa CC2530 que se une a la red deCONZ como luz de encendido / apagado. Las válvulas que planeo usar tienen un mecanismo de enganche, por lo que requieren una señal específica para cambiar, por lo tanto, tuve que crear mi propio firmware ...

Nosotros no. Tendría que implementarse en el firmware RaspBee / ConBee, supongo. No es una mala idea en mi humilde opinión, pero no tengo ni idea de lo factible que es esto, dadas las limitaciones de tamaño en la EEPROM y la NVRAM del dispositivo. @manup , ¿qué opinas de esto?

La pila Zigbee en el firmware tiene un parámetro para controlar si se utilizará una ruta en lugar de un enlace directo en función de su calidad (RSSI / LQI). Esto ya debería funcionar bastante bien y se modificó a lo largo de los años.

Una ruta adicional podría ser un enfoque más general para controlar las tablas de enrutamiento de todos los dispositivos.

Nota: Puede consultar la tabla de enrutamiento de un enrutador seleccionándolo y presionando la tecla R , las rutas del siguiente salto se mostrarán en azul.

Actualmente, cuando se abre la red Zigbee, todos los enrutadores pueden ser un nodo principal, ya que Mgmt_Permit_Joining_req se envía como transmisión. Sin embargo, si enviamos esta solicitud como unidifusión solo a un determinado enrutador, un nuevo dispositivo solo puede unirse a través de este dispositivo. Esto podría ser útil para los dispositivos finales de Xiaomi que a menudo se adhieren a sus padres. Para otros dispositivos de unión como enrutadores y, por ejemplo, dispositivos finales Philips Hue, esto no ayudará mucho, ya que son libres de seleccionar nuevos padres y rutas por su cuenta.

El (nuevo) Mgmt_NWK_IEEE_Joining_List_req en la especificación Zigbee R22 también parece interesante:

El comando Mgmt_NWK_IEEE_Joining_List_req se proporciona como un mecanismo para obtener la lista de direcciones IEEE que se espera que se unan a la red. Esto permite que el enrutador local filtre las solicitudes de balizas mejoradas y solo responda a los dispositivos que se unen.

Sin balizas, los dispositivos ni siquiera intentarían unirse a un determinado enrutador. Pero no sé qué tan bien esta solicitud es compatible con los enrutadores disponibles actualmente.

Una bala de plata podría estar usando el enrutamiento de origen donde la puerta de enlace proporciona la ruta completa dentro de cada marco, pero nunca he visto esto utilizado por ningún producto de consumo o puerta de enlace y supongo que, por lo tanto, podría no ser (o no) compatible con los enrutadores actuales Aunque podría valer la pena intentarlo.

Nota: Puede consultar la tabla de enrutamiento de un enrutador seleccionándolo y presionando la tecla R , las rutas del siguiente salto se mostrarán en azul.

Genial, no lo sabía. ¿Existe una descripción general de todas las teclas / comandos admitidos por la GUI? ¿Es posible revertir las líneas azules antes de consultar el siguiente nodo? ¿No parece funcionar para RaspBee / ConBee en sí?

¿La tabla de enrutamiento es diferente de la tabla vecina? Oler, solo veo los mensajes ZDP _Link Quality Request_ y _Link Quality Response_, que informan de la tabla vecina. ¿Significa esto que las líneas a un nodo que no son de color azul son las rutas "entrantes"?

@manup , de hecho una visualización interesante

Una bala de plata podría estar usando el enrutamiento de origen

Bueno ... supongo que valdría la pena intentarlo. Me parece que, en mi red, las luces de IKEA más afectadas son las que están a mayor distancia del coordinador. He sospechado que algo relacionado con el enrutamiento está causando los problemas, como mencionó @ebaauw .
Estaría dispuesto a probar algo como esto para ti. Sin embargo, debo admitir que perder las conexiones no es muy confiable, por lo que las pruebas pueden ser difíciles.

Pensaba más en el sentido de que el coordinador era selectivo sobre qué enrutador seleccionar para el primer salto. Si podemos encontrar enrutadores que funcionen bien con los dispositivos IKEA (tal vez esos sean los enrutadores IKEA), enrutar todos los paquetes a través de ellos debería hacer las cosas más sólidas. No estoy seguro de poder engañar al proceso de descubrimiento de rutas para que prefiera un determinado enrutador para el primer salto, pero probablemente pueda comentar sobre eso, @manup

Nota: Puede consultar la tabla de enrutamiento de un enrutador seleccionándolo y presionando la tecla R , las rutas del siguiente salto se mostrarán en azul.

Genial, no lo sabía. ¿Existe una descripción general de todas las teclas / comandos admitidos por la GUI? ¿Es posible revertir las líneas azules antes de consultar el siguiente nodo? ¿No parece funcionar para RaspBee / ConBee en sí?

Si alguien quiere enumerar todas las combinaciones clave y lo que hacen, estaré feliz de limpiarlo y escribir una página wiki.

Genial, no lo sabía. ¿Existe una descripción general de todas las teclas / comandos admitidos por la GUI?

Solicitar descriptor de nodo = 1
Solicitar descriptor de potencia = 2
Solicitar dirección Nwk = 0
Solicitar tabla de enrutamiento = R
Request Mgmt Leave = L (con reincorporación, ¡no lo use con luces internas!)
Solicitar puntos finales activos = 7
Solicitar descriptores simples = 8
Actualizar = F5 / Cmd-R
Eliminar = Delete / Backspace
Dispositivo de puerta de enlace Annce = A (no es tan útil)

¿Es posible revertir las líneas azules antes de consultar el siguiente nodo?

Todavía no, fue solo una adición rápida y sucia para ver rutas :)
¿Quizás sea útil agregar otra clave como Shift-R para borrar las rutas de un nodo?

¿No parece funcionar para RaspBee / ConBee en sí?

Desafortunadamente, RaspBee I / ConBee no es compatible con el comando ZDP relacionado, funciona con ConBee II.

¿La tabla de enrutamiento es diferente de la tabla vecina? Oler, solo veo los mensajes de solicitud de calidad de enlace de ZDP y respuesta de calidad de enlace, que informan de la tabla vecina.

Estas son dos tablas separadas, por lo general, la tabla de enrutamiento solo contiene rutas a nodos que no son directamente accesibles y están sujetos a la tabla vecina (nodos de 1 salto).

Para los nodos que están en la tabla de vecinos (y tienen una señal fuerte) no se necesita descubrimiento de ruta. La tabla vecina en sí se construye principalmente utilizando comandos de estado de enlace NWK de 1 salto.

¿Significa esto que las líneas a un nodo que no son de color azul son las rutas "entrantes"?

Las líneas que no son azules (verde / naranja / amarillo) solo representan la tabla vecina de 1 salto. Las líneas azules son rutas de salida a algún destino y representan solo el siguiente salto (no la ruta completa) en la vista actual, la dirección NWK de destino no se muestra, pero es probable que haya impresiones de depuración.

Nosotros no. Tendría que implementarse en el firmware RaspBee / ConBee, supongo. No es una mala idea en mi humilde opinión, pero no tengo ni idea de lo factible que es esto, dadas las limitaciones de tamaño en la EEPROM y la NVRAM del dispositivo. @manup , ¿qué opinas de esto?

La pila Zigbee en el firmware tiene un parámetro para controlar si se utilizará una ruta en lugar de un enlace directo en función de su calidad (RSSI / LQI). Esto ya debería funcionar bastante bien y se modificó a lo largo de los años.

Una ruta adicional podría ser un enfoque más general para controlar las tablas de enrutamiento de todos los dispositivos.

Nota: Puede consultar la tabla de enrutamiento de un enrutador seleccionándolo y presionando la tecla R , las rutas del siguiente salto se mostrarán en azul.

¡Función realmente útil! Ayer encendí mi bombilla TRÅDFRI GU10 WS 400lm (7 bombillas) con firmware 2.0.022. Hoy volvieron los problemas, apareció en una bombilla TRÅDFRI E27 CWS opal 600lm con firmware 1.3.009. Gracias a esta función pude ver que la bombilla E27 pasaba por las GU10. Apagué todo el GU10 y, como por arte de magia, el E27 volvió a funcionar.

Por lo tanto, está bastante claro que el enrutamiento a través de Innr e IKEA están causando problemas. Empecé a mover las bombillas Innr och IKEA a mi puerta de enlace de tonos. Parece que las bombillas Philips son buenos enrutadores y no causan problemas.

Entonces, hice un pequeño experimento mientras reposicionaba mis luces en la sala de estar. Quité dos enrutadores y volví a colocar una luz. Et voila, una luz se ha vuelto zombi, pero no del todo. Se comporta exactamente como he visto con las luces IKEA que ocasionalmente pierden conexión.

La luz de IKEA aparece como inaccesible, pero aún responde a los comandos del grupo. Además, dado que todavía es conocido por varios otros enrutadores, parece que informan haber visto la luz (es 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

y

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

A veces, parece que la comunicación es posible:

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

a veces no:

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

Hay muy poca información sobre lo que va mal. ¿Qué significa el estado 0xA7 ...?

¿Alguna información adicional que pueda ayudar a averiguar qué está sucediendo?

Entonces, hice un pequeño experimento mientras reposicionaba mis luces en la sala de estar. Quité dos enrutadores y volví a colocar una luz. Et voila, una luz se ha vuelto zombi, pero no del todo. Se comporta exactamente como he visto con las luces IKEA que ocasionalmente pierden conexión.

La luz de IKEA aparece como inaccesible, pero aún responde a los comandos del grupo. Además, dado que todavía es conocido por varios otros enrutadores, parece que informan haber visto la luz (es 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

y

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

A veces, parece que la comunicación es posible:

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

a veces no:

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

Hay muy poca información sobre lo que va mal. ¿Qué significa el estado 0xA7 ...?

¿Alguna información adicional que pueda ayudar a averiguar qué está sucediendo?

¡Esto suena como una réplica exacta de mis problemas!

¿Qué significa el estado 0xA7 ...?

Vea aquí: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

Apagó y apagó la 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

Y parece estar informando felizmente su estado

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

luego:

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

deja de funcionar. hasta .. 2 minutos después

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

Supongo que necesito conseguirme un rastreador de zigbee para averiguar qué está sucediendo en el aire.

después de esto dejó de funcionar nuevamente, algo más permanente esta vez.

¿Qué significa el estado 0xA7 ...?

Vea aquí: https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Zigbee-Error-Codes-in-the-Log

¡Gracias por eso! de alguna manera es lo que esperaba ...

Intenté emparejar mi bombilla TRÅDFRI GU10 WS 400lm (7 bombillas) con mi puente Philips Hue. Varias otras bombillas en la red dejaron de estar disponibles y la bombilla TRÅDFRI GU10 WS 400lm tuvo el mismo comportamiento que con Deconz, respuesta en comando de grupo pero no respuesta en unidifusión.

La bombilla TRÅDFRI GU10 WS 400lm parece tener algún tipo de problema. Haré algunas pruebas si se trata de bombillas induviduales o todas ellas no funcionan.

Ahora he hecho algunas pruebas. Mi conclusión es que, de hecho, son las bombillas individuales las que hacen que la red deje de responder. Aparecieron limones instantáneamente en el puente Hue y la cosa comenzó a funcionar de nuevo tan pronto como los apagué. Entonces, de 7 bombillas, 3 se ven afectadas . Informaré si encuentro algunos problemas nuevos.

@MikaelHoogen , ¿qué versión de las bombillas y el firmware tienes?

He visto este problema en v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS y los 3 paneles FLOALT en las pasarelas Ikea, HUE y DeCONZ durante el último año y medio.
Estoy convencido de que se trata de un problema de hardware. Es totalmente aleatorio qué nodo muere.
Aquí en Noruega todos los dispositivos electrónicos tienen menos de 2 años de garantía. Intentaré abrir un ticket y escuchar lo que dicen.
Respecto al FLOALT. Hace unos meses, Ikea estaba realizando una venta de liquidación. ¿Quizás eso fue para deshacerse de todos los v1?
¿Alguien ha visto un FLOALT v2 por ahí? (¿con el controlador sy5882 quizás?)

He visto este problema en v1 E27 WS 980lm, GU10 WS 400lm, E27 CWS 600lm, E15 WS y los 3 paneles FLOALT en las pasarelas Ikea, HUE y DeCONZ durante el último año y medio.
Estoy convencido de que se trata de un problema de hardware. Es totalmente aleatorio qué nodo muere.
Aquí en Noruega todos los dispositivos electrónicos tienen menos de 2 años de garantía. Intentaré abrir un ticket y escuchar lo que dicen.
Respecto al FLOALT. Hace unos meses, Ikea estaba realizando una venta de liquidación. ¿Quizás eso fue para deshacerse de todos los v1?
¿Alguien ha visto un FLOALT v2 por ahí? (¿con el controlador sy5882 quizás?)

Eso es también lo que he estado tratando de decir durante bastante tiempo. Solo tengo problemas con las bombillas Trådfri v1. El puente Philips Hue ayuda, pero los nodos siguen siendo inalcanzables de vez en cuando.

Hace un par de días decidí reemplazar las 12 bombillas IKEA GU10 con la nueva versión (blanco cálido).
Eso empeoró aún más este problema. Ahora también estoy perdiendo el ambiente blanco Hue GU10 y el color Hue E14.

He estado usando deConz e IKEA Light desde el principio cuando salieron. Tengo alrededor de 70 nodos en mi red. La mayoría de ellas son luces de IKEA. También tengo algunos Philips Hue (4 luces) y un Osram. Sensores Tengo pocos movimientos Ikea y muchos sensores de movimiento Xiaomi.

He estado funcionando con esta configuración durante bastante tiempo y no pasa un día comprando sin que las luces se atasquen, así que necesito apagar y encender. Mi esposa no está emocionada y yo tampoco. Estoy muy cerca de deshacerme de todos los dispositivos zigbee y simplemente ir a las luces simples de la vieja escuela. Simplemente no funciona. muy decepcionante. Me pregunto si otros ven los mismos problemas usando luces Philips u Osram puras o ¿es solo IKEA eso es una mierda?

He estado usando deConz e IKEA Light desde el principio cuando salieron. Tengo alrededor de 70 nodos en mi red. La mayoría de ellas son luces de IKEA. También tengo algunos Philips Hue (4 luces) y un Osram. Sensores Tengo pocos movimientos Ikea y muchos sensores de movimiento Xiaomi.

He estado funcionando con esta configuración durante bastante tiempo y no pasa un día comprando sin que las luces se atasquen, así que necesito apagar y encender. Mi esposa no está emocionada y yo tampoco. Estoy muy cerca de deshacerme de todos los dispositivos zigbee y simplemente ir a las luces simples de la vieja escuela. Simplemente no funciona. muy decepcionante. Me pregunto si otros ven los mismos problemas usando luces Philips u Osram puras o ¿es solo IKEA eso es una mierda?

Al observar a todas las personas que tienen exactamente los mismos problemas en este hilo y los fabricantes de deconz no pueden averiguar cuál es el problema con las luces de IKEA, huele y parece un problema de firmware de IKEA.

Muchos usuarios tienen problemas similares incluso con el centro de IKEA. Así que supongo que este no es un problema único relacionado con deconz. Sin embargo, si alguien pudiera arreglar esto, "parchearlo / encontrar una solución", ¡serían los chicos de aquí! <3

Tengo exactamente el mismo problema tanto con la familia como con la configuración.

Es triste :( especialmente que incluso los nuevos que venden hoy todavía tienen estos problemas. Simplemente no entiendo. Tengo el mío de 2017, por lo que es de esperar que ya hayan solucionado el problema. Tendré que considerar eliminar todo No se puede arreglar aquí, @manup ha dicho antes que este es un problema en el firmware del dispositivo, por lo que solo IKEA puede solucionarlo y, dado que aún no lo han hecho, no hay esperanza.

Deconz versión 2.05.69
Firmware 264A0700 de Conbee II

No es 100% perfecto y los abandonos que noté son bombillas E27 Ikea (Rev1).
Cuando tenía estas luces Ikea con mi puente Philips Hue, eran sólidas como una roca, así que probablemente las mueva de regreso a Hue y mantengo esta malla Zigbee puramente CC2531 (firmware del enrutador) y sensores Xiaomi.
También tengo una bombilla Innr (E14) y una SP120, pero todavía están bien con Deconz.

Estoy usando Home Assistant y Deconz para controlar unas 20 bombillas Ikea (y una serie de otros sensores). Las bombillas son principalmente GU10 que están agrupadas por 3 focos en una luz.

He estado usando esta configuración durante más de 15 meses y, desde este verano, he tenido problemas con una o más bombillas que se atascan y necesitan un ciclo de energía, o incluso que se quitan y se vuelven a agregar a la red Zigbee. Siempre fueron GU10 que se definieron en un grupo ligero en HASS.

Hace unas semanas creé grupos para mis luces en Phoscon y comencé a hacer referencia a estos grupos en HASS.

Después de eso, no he tenido un solo problema con las bombillas que se atascan y necesitan un ciclo de energía. El único problema que veo es que cuando apago todas las luces de mi interior a la vez, algunas veces todo un grupo Phoscon / Deconz permanece encendido.

Para mí, esto parece un problema con la API de Deconz y posiblemente el manejo de múltiples bombillas en rápida sucesión sobre ella.

También he tenido problemas con los dispositivos Ikea (bombillas y últimamente también el control remoto Symfonisk) que no están disponibles y requieren volver a emparejarse con deCONZ. Creo que llevo estos problemas durante 6 meses. No hay mucho que añadir más de lo que creo que ocurre con más frecuencia últimamente. No tengo bombillas GU10, solo varias E27 y E14 (y varios mandos a distancia). Parece que ciertos dispositivos son más propensos a fallar (tal vez dependiendo de cómo encajen o similar). Tengo aproximadamente 20 dispositivos con un alcance máximo de 5 m del Conbee I con el último FW / Phoscon / deCONZ.

También he tenido problemas con los dispositivos Ikea (bombillas y últimamente también el control remoto Symfonisk) que no están disponibles y requieren volver a emparejarse con deCONZ. Creo que llevo estos problemas durante 6 meses. No hay mucho que añadir más de lo que creo que ocurre con más frecuencia últimamente. No tengo bombillas GU10, solo varias E27 y E14 (y varios mandos a distancia). Parece que ciertos dispositivos son más propensos a fallar (tal vez dependiendo de cómo encajen o similar). Tengo aproximadamente 20 dispositivos con un alcance máximo de 5 m desde el Conbee I con el último FW / Phoscon / deCONZ.

Pruebe la versión 2.05.69 de Deconz. Bastante estable para mí con Ikea, Innr y Xiaomi

Tengo un problema similar y un boleto abierto https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2256#issue -543476970

Diría que cuando se degradó a la versión 2.05.67, mi red fue mucho más estable que nunca. Tenía algunas bombillas que entraron en estado irresponsable, pero las mismas dos y podrían vivir con ellas. Ayer todo funcionó como se esperaba.

Parece ser un problema con una combinación de todas las partes posibles y, por supuesto, hace que sea difícil de encontrar. Sin embargo, la versión deconz parece ser una parte importante de tener una solución estable o no.

También he tenido problemas con los dispositivos Ikea (bombillas y últimamente también el control remoto Symfonisk) que no están disponibles y requieren volver a emparejarse con deCONZ. Creo que llevo estos problemas durante 6 meses. No hay mucho que añadir más de lo que creo que ocurre con más frecuencia últimamente. No tengo bombillas GU10, solo varias E27 y E14 (y varios mandos a distancia). Parece que ciertos dispositivos son más propensos a fallar (tal vez dependiendo de cómo encajen o similar). Tengo aproximadamente 20 dispositivos con un alcance máximo de 5 m desde el Conbee I con el último FW / Phoscon / deCONZ.

Pruebe la versión 2.05.69 de Deconz. Bastante estable para mí con Ikea, Innr y Xiaomi

Intentaré eso así como el

Hace unas semanas creé grupos para mis luces en Phoscon y comencé a hacer referencia a estos grupos en HASS.

Así que finalmente obtuve mi hardware de rastreo y también he pirateado un poco Wireshark para mostrar los nombres de todas las direcciones ieee802.15.4 (lo que hace que sea mucho más fácil leer lo que está sucediendo).

De todos modos, mi conocimiento de las cosas de zigbee no es muy fuerte, así que posiblemente esté haciendo preguntas estúpidas. Sin embargo, he estado revisando algunos registros de olfateo y espero que podamos ver algo que explique el comportamiento escamoso de las luces de ikea.

Vea el registro a continuación. ¿Parece un comportamiento "normal"? Ambas luces involucradas son luces de Ikea. Primero, DeConz envía una solicitud al 'Garage', enrutando a través del 'Zolder'. Luego, 'Zolder' intenta transmitirlo al 'Garage', pero parece fallar (¿por qué?) Y se vuelve a intentar 20 veces en una sucesión muy rápida (la mayoría están dentro de los 3 ms). Finalmente, 'Zolder' se rinde y envía una falla de enlace a DeConz.

¿Debería ser así de agresivo al reintentar la transmisión?

Además: me doy cuenta de que DeConz sigue enviando solicitudes a Garage a través de Zolder, aunque el enlace claramente falla. DeConz incluso hace esto cuando Garage ya no está en el informe de estado de enlace de Zolder. Además, si a veces Garage está en el informe de estado de enlace de Zolder, tiene un costo de 7 tanto entrante como saliente. En realidad, la ruta de Garage a DeConz no es a través de Zolder ...
¿Por qué DeConz sigue enrutando a través de Zolder incluso después de un mensaje de falla de enlace?

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, he pasado algún tiempo leyendo la documentación de silabs ZigBee (los IKEA se basan en chips de silabs).
Aparentemente, el comportamiento de reintento es exactamente como se describe en los documentos.

Eso deja la pregunta de por qué DeConz insiste en usar esta ruta. El costo del enlace es alto, hay una respuesta de Link Failure y aún se utiliza esa ruta. Por qué..?
(y hay mejores rutas disponibles ...)

Ideas muy útiles

Después de eso, estoy de regreso y creo que tengo malas rutas nuevamente.

Otra cosa. ¿Cómo es que deconz establece los estados incluso si el dispositivo real no responde? Parece que hay una bombilla encendida en las interfaces, pero físicamente está apagada (todavía encendida). A veces funciona para volver a encenderlo (a través del software), a veces funciona con un ciclo de energía, pero a menudo no responde en absoluto incluso después de un ciclo de energía. La misma bombilla puede volver a responder repentinamente después de un tiempo

Algún comportamiento más interesante (muestro las mismas luces, pero esto también está sucediendo en otros lugares de mi red)

• DeConz envía many-to-one route Route Request paquetes. El resultado es que cualquier dispositivo primero hará un descubrimiento de ruta. Se supone que esto alimenta al concentrador (coordinador) con información sobre cómo llegar a ese dispositivo. Parece que DeConz ignora esta información por su enrutamiento ...

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

Ese último paquete tiene información sobre cómo llegar al garaje:

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

Pero la próxima solicitud a Garage se envía nuevamente a través del 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

No me sorprendería que este comportamiento tenga algo que ver con el comportamiento de luz escamosa de IKEA.

@manup , ¿podrías comentar sobre esto? Su afirmación de que el enrutamiento de origen ayudaría tiene mucho sentido.
Alternativamente, espero que usar la información del Registro de ruta para actualizar la tabla de enrutamiento de DeConz podría ser una gran mejora ...
O necesitamos averiguar por qué DeConz quiere seguir usando una ruta que informa problemas de enlace / tiene altos costos de enrutamiento en comparación con una alternativa.

Otra observación ... Los dos dispositivos de retransmisión en el paquete anterior son ambos enchufes Xiaomi. Nunca se les pregunta por la calidad del enlace. ¿Por qué?
¿Podría ser que DeConz esté usando la información en la Respuesta de calidad del enlace para construir su tabla de rutas y, por lo tanto, ignora los enrutadores bastante válidos? Con buena calidad de enlace a algunas de mis descontentas luces IKEA ...

¿Solo ve este comportamiento para dispositivos ikea o un comportamiento general para ignorar la ruta óptima? ¿Supongo que tienes una cantidad decente de dispositivos ikea?

No estoy seguro, necesito comprobarlo. Buena pregunta.

Tengo una gran cantidad de bombillas Ikea, sí.

En mi opinión, esto explica gran parte del comportamiento que hemos visto con las luces inalcanzables de IKEA. Aunque solo es una hipótesis por ahora, por verificar.

Mirando en varias otras rutas y veo el mismo comportamiento.

Solo veo que los dispositivos Xiaomi no son consultados por Calidad de enlace, todas las demás marcas sí. ¿Supongo que esto es una especie de lista negra ...?

Ejemplo de otro comportamiento de enrutamiento:

Desde DeConz, siempre:
DeConz --> WC Lamp --> Badkamer Ledstrip

La ruta de retorno cambia a menudo después de una solicitud de ruta de varios a uno. Tenga en cuenta que desde un punto de vista geográfico, todos estos tienen sentido ...
Badkamer Ledstrip --> WC Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> DeConz
Badkamer Ledstrip --> Zoldertrap Lamp --> DeConz
Badkamer Ledstrip --> Gang 1 --> Zoldertrap Lamp --> DeConz

Para la luz del garaje, veo de DeConz:
DeConz --> Zolder Noord Lamp --> Garage (ruta muy inestable ...!)

Ruta de regreso que veo:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz

Ahora, cuando miro la tabla en los informes de estado del enlace, la ruta anterior va de Garage a DeConz tiene sentido:
Garage --> Kerstverlichting --> On/Off Light 36 --> DeConz costo total: 4
Garage --> Kerstverlichting --> HK Zoutlamp --> DeConz costo total: 4

de DeConz a Garage no:
DeConz --> Zolder Noord Lamp --> Garage costo total: 12 (basado en el costo de entrada de DeConz a Zolder Noord Lamp)

@manup , ¿podría

Un poco más de análisis hoy ...
En mis publicaciones anteriores, has visto que la luz de mi garaje se enruta a través de mi luz Zolder. Ambas bombillas IKEA. El enlace de radio de Zolder a Garage está justo al borde de lo que puede alcanzar, por lo que falla a menudo.

Hoy en día, aunque la luz del garaje responde a los comandos de grupo, no responde a los comandos de unidifusión. En realidad, a veces lo hace y otras no. Este es un comportamiento que debería ser familiar para aquellos que han leído / contribuido a este hilo.

Puedo encontrar esto en los registros de olfateo. A veces, la luz Zolder puede comunicarse con Garage y otras no. Cada vez que Zolder Light no puede comunicarse con Garage, informa esto:

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 paquete debería indicarle a DeConz que comience a buscar otra ruta para llegar a Garage, pero eso no sucede. El siguiente paquete enviado a Garage se enruta nuevamente a través de Zolder. Para mí, ese es un error que debe resolverse.
El siguiente paquete para Garage es recibido por la luz Zolder, pero esa luz ni siquiera intenta enviarlo al Garage. Tal vez este sea un comportamiento del firmware de IKEA que no es bueno, pero la causa principal del problema es la negativa de DeConz a encontrar una ruta alternativa.
Creo que si una ruta no está disponible durante un período prolongado de tiempo, tal vez la luz del garaje esté hambrienta de ACK a un nivel más alto que el protocolo 802.15.4 y eso puede hacer que el firmware se desconecte o incluso se bloquee. Y estoy de acuerdo en que no debería, pero la causa principal es que DeConz se niega a encontrar una nueva ruta hacia la luz del garaje.

Hoy hice un experimento para que DeConz encontrara otra ruta hacia la luz del garaje, así que desconecté la red eléctrica de la luz Zolder y miré los registros de olfateo. Después de algunos intentos, DeConz se da cuenta de que Zolder se ha ido y sigue adelante para encontrar una ruta alternativa a Garage. A continuación vuelvo a conectar Zolder y tras anunciar su presencia también para Zolder se encuentra una nueva ruta. DeConz no vuelve (todavía) a enrutar Garage a través de Zolder.

Lo curioso es que, en la nueva situación, DeConz ahora habla directamente con la luz del garaje, sin enrutadores intermedios.
Ahora se llega a Zolder a través de una ruta a través de otros 2 enrutadores (aunque, obviamente, DeConz puede acceder directamente a él), por lo que me parece que alguna tabla (¿tabla vecina?) Está llena dentro del firmware de enrutamiento de DeConz.

¿Quizás esto esté relacionado con su negativa a crear una nueva ruta en respuesta a una ruta fallida ..?

@manup , agradecería cualquier comentario de usted sobre las publicaciones anteriores. O al menos déjeme saber cómo contribuir a una solución (además de buscar la causa raíz).

Me gustaría ayudar a crear una solución para estos problemas, ya que me molestan. Si me da acceso al código fuente del firmware, puedo contribuir directamente (incluso si no es de código abierto). No me importa ayudar a Dresden Elektronik de esa manera :)

¡Excelente trabajo hecho! 💪🏼
Espero que podamos llamar la atención de los desarrolladores para solucionar este problema. Parece que tiene una buena configuración y proceso, por lo que una solución podría ser verificada de manera bastante “fácil”.
Ahora entiendo el comportamiento que he visto al que me he referido como "autocuración" y por qué algunas bombillas de repente están funcionando.

Buen trabajo @djwlindenaar espero que @manup pueda ver esto.

@manup algún comentario?

Gracias por este hilo y trabajo. Yo mismo estoy ejecutando 20 firmware de actualización de bombilla ikea y un año. Experimenté caídas congeladas o pérdida de bombilla desde el principio, pero no con demasiada frecuencia. Empeoró con las actualizaciones posteriores de deconz. Revisé mi red optimizada en un entorno empaquetado 2.4. Aún así, la bombilla se apaga a diario y los botones o sensores son inútiles, ya que aún se enrutan a través de estas bombillas y, por lo tanto, no envían ningún movimiento de datos. Necesito apagar y encender los sensores para que estén disponibles nuevamente cuando las bombillas comiencen a enrutarlos nuevamente. Con suerte, esto atrae más atención. Es frustrante.

Otra observación ... Los dos dispositivos de retransmisión en el paquete anterior son ambos enchufes Xiaomi. Nunca se les pregunta por la calidad del enlace. ¿Por qué?
¿Podría ser que DeConz esté usando la información en la Respuesta de calidad del enlace para construir su tabla de rutas y, por lo tanto, ignora los enrutadores bastante válidos? Con buena calidad de enlace a algunas de mis descontentas luces IKEA ...

La consulta de la tabla vecina (también conocida como ZDP Mgmt_Lqi_req) se deshabilitó para los dispositivos Xiaomi ya que no responden a estas consultas después de un tiempo y sospeché que un error en el firmware podría desencadenar algún estado no válido o peor.

Por lo tanto, el factor principal para limitar ciertas solicitudes es evitar errores en el firmware del dispositivo final e imitar de cerca el comportamiento de la puerta de enlace del proveedor relacionado; algunos de los resultados de la investigación se pueden encontrar en https://github.com/dresden-elektronik/deconz-rest -plugin / wiki / End-device-Polling

Como nota al margen, las consultas de la tabla vecina solo se utilizan para crear la presentación de malla visual y no afectan la operación de la red ni las tablas de enrutamiento.

Así que finalmente obtuve mi hardware de rastreo y también he pirateado un poco Wireshark para mostrar los nombres de todas las direcciones ieee802.15.4 (lo que hace que sea mucho más fácil leer lo que está sucediendo).

De todos modos, mi conocimiento de las cosas de zigbee no es muy fuerte, así que posiblemente esté haciendo preguntas estúpidas. Sin embargo, he estado revisando algunos registros de olfateo y espero que podamos ver algo que explique el comportamiento escamoso de las luces de ikea.

Vea el registro a continuación. ¿Parece un comportamiento "normal"? Ambas luces involucradas son luces de Ikea. Primero, DeConz envía una solicitud al 'Garage', enrutando a través del 'Zolder'. Luego, 'Zolder' intenta transmitirlo al 'Garage', pero parece fallar (¿por qué?) Y se vuelve a intentar 20 veces en una sucesión muy rápida (la mayoría están dentro de los 3 ms). Finalmente, 'Zolder' se rinde y envía una falla de enlace a DeConz.

¿Debería ser así de agresivo al reintentar la transmisión?

Además: me doy cuenta de que DeConz sigue enviando solicitudes a Garage a través de Zolder, aunque el enlace claramente falla. DeConz incluso hace esto cuando Garage ya no está en el informe de estado de enlace de Zolder. Además, si a veces Garage está en el informe de estado de enlace de Zolder, tiene un costo de 7 tanto entrante como saliente. En realidad, la ruta de Garage a DeConz no es a través de Zolder ...
¿Por qué DeConz sigue enrutando a través de Zolder incluso después de un mensaje de falla de enlace?

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

¡Buena atrapada! Aquí sospecho que el firmware deCONZ debería manejar este error y volver a intentar encontrar una nueva ruta. Verificaré el firmware si se maneja este caso y cómo. Puedo imaginarme que la ruta se descarta en realidad, pero si se recibe un nuevo mensaje a través de la misma ruta. Por ejemplo, debido a un informe de atributo ZCL de la luz, la entrada simplemente se mantiene viva.

Las rutas pueden establecerse simplemente recibiendo cualquier comando de una trama entrante. Pero si el último salto no mantiene el salto anterior (lo que suele hacer), el camino de regreso a través del mismo salto no funcionará. Sus hallazgos podrían reflejar exactamente ese caso.

Gracias.

En este caso, nunca se recibe un mensaje de la luz del garaje a través de Zolder. Por lo tanto, no esperaría que DeConz siguiera usando la ruta. Ver mis otras publicaciones ...

Código de estado: Fallo de enlace sin árbol (0x02)

Parece que obtuvimos un ganador, he verificado la fuente de la pila de Zigbee (R21, ConBee II) y este código de estado se ignora por completo. : -O También es necesario comprobar la pila AVR Zigbee, probablemente el mismo problema allí.

Como solución, me gustaría manejar este código de la misma manera que se maneja el estado "No hay ruta disponible", que es solo para liberar la entrada de ruta y dejar que la pila descubra una nueva.

¿Tiene también un paquete completo del comando que fue enviado previamente por el coordinador a la luz de IKEA? Sería interesante si se configurara el bit de descubrimiento de ruta.

Aquí está la sección de la especificación de Zigbee sobre lo que debería suceder en este caso particular:

Al recibir una trama de comando de estado de red por parte de un enrutador que es el destino previsto del comando donde el campo de código de estado de la carga útil de la trama de comando tiene un valor de 0x01 o 0x02 que indica una falla de enlace, la capa NWK eliminará la entrada de la tabla de enrutamiento correspondiente al valor del campo de dirección de destino de la carga útil de la trama de comando, si existe, e informar a la siguiente capa superior de la falla usando la indicación NLME-NWK-STATUS usando el mismo código de estado.

Entonces, la solución anterior debería funcionar aquí para 0x02, 0x01 tampoco se maneja, lo agregaré también.

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

¡Genial @manup! Mencionaste el Conbee II. ¿Esta solución también funcionará para el Conbee I?

Sí, solo tengo las fuentes de pila utilizadas por ConBee I y RaspBee. El mismo problema aquí, cocinaré nuevas versiones de firmware para probar hasta el martes. Sería genial recibir comentarios si eso resuelve al menos los problemas de enrutamiento de IKEA.

Tenga en cuenta que también hubo otros problemas que no se solucionarán con esto, como las bombillas de IKEA que se quedan completamente en silencio y ni siquiera escuchan los lanzamientos grupales.

Se cerró accidentalmente este problema ... Reabierto. Genial que estemos progresando en esto.

Supongo que @djwlindenaar es el que puede dar algunos comentarios después de que el nuevo firmware esté disponible porque se necesita el hardware de rastreo para esto.

¿Tiene también un paquete completo del comando que fue enviado previamente por el coordinador a la luz de IKEA? Sería interesante si se configurara el bit de descubrimiento de ruta.

No estoy seguro de entender tu pregunta. ¿Qué paquete buscas? ¿Y a qué luz (Garage o Zolder)?

Sí, solo tengo las fuentes de pila utilizadas por ConBee I y RaspBee. El mismo problema aquí, cocinaré nuevas versiones de firmware para probar hasta el martes. Sería genial recibir comentarios si eso resuelve al menos los problemas de enrutamiento de IKEA.

Tenga en cuenta que también hubo otros problemas que no se solucionarán con esto, como las bombillas de IKEA que se quedan completamente en silencio y ni siquiera escuchan los lanzamientos grupales.

Lo probaré seguro. Aunque puede llevar algún tiempo llegar a una conclusión porque a veces no hay problema durante mucho tiempo ...

Estaba pensando que tal vez hay algo que desencadena ese comportamiento de quedar completamente en silencio. Tuve esto sucediendo la semana pasada, pero aún no tuve tiempo para revisar los registros de rastreo.

Estoy en Raspbee por cierto.

Sí, solo tengo las fuentes de pila utilizadas por ConBee I y RaspBee. El mismo problema aquí, cocinaré nuevas versiones de firmware para probar hasta el martes. Sería genial recibir comentarios si eso resuelve al menos los problemas de enrutamiento de IKEA.

Háganos saber, tengo mucho este problema y podría probar, aunque no olfateé.

Tenga en cuenta que también hubo otros problemas que no se solucionarán con esto, como las bombillas de IKEA que se quedan completamente en silencio y ni siquiera escuchan los lanzamientos grupales.

¿Se refiere esto al problema de que el software (deconz) informa y establece un estado, pero la bombilla en sí no responde o cambia el estado? Tal vez el problema no sea de la misma gravedad si concretamos el problema del enrutamiento.

Gracias por investigar esto, ¡muy apreciado!

Sí, solo tengo las fuentes de pila utilizadas por ConBee I y RaspBee. El mismo problema aquí, cocinaré nuevas versiones de firmware para probar hasta el martes. Sería genial recibir comentarios si eso resuelve al menos los problemas de enrutamiento de IKEA.

Tenga en cuenta que también hubo otros problemas que no se solucionarán con esto, como las bombillas de IKEA que se quedan completamente en silencio y ni siquiera escuchan los lanzamientos grupales.

¡Gracias manup! Actualizaré al nuevo fw en cuanto esté disponible y proporcionaré actualizaciones.

¿Este problema también podría estar relacionado con el problema del control de las persianas Ikea Fyrtur?

Otro que me parece extraño. @manup , ¿podría esto ser un problema también?

Veo muchas de este tipo de secuencias. Comencé a investigar esto, porque esta es la última comunicación de houtlamp antes de que deje de responder. DeConz configura 2 elementos de informes de atributos y casi al mismo tiempo solicita membresías de grupos. En los registros de DeConz, esto se ve a continuación.

Me pregunto si hay un error al seleccionar el número de secuencia o tal vez está permitido (no lo sé) y este comportamiento está provocando un error en el firmware de Tradfri. Hay una solicitud con el número 215 y dos solicitudes con el número 216. ¿Podría ser que tengamos algún tipo de condición de carrera en la que el manejo de las solicitudes por parte del firmware tradfri esté causando una pérdida de memoria o que se cuelgue debido a las dos solicitudes? con el mismo número casi al mismo tiempo? ¿Debió DeConz tener dos solicitudes con el mismo número de secuencia?

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

En el aire, esto se ve así: (parece que no veo todos los paquetes en el aire, lo cual es extraño ya que el rastreador está justo al lado del raspbee. Tal vez se envíen tan rápido que se pierdan en un desbordamiento de búfer o algo en el rastreador)

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

De hecho, los números de secuencia no deberían ser iguales en este corto tiempo, revisaré el código, parece que falta un incremento.

Aquí está el primer firmware de prueba para ConBee II

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

Ahora, la transferencia de esto al firmware ConBee I / RaspBee estará en línea en breve.

Y aquí está la versión de prueba para ConBee I y RaspBee con la solución de error de ruta.
Espero que traiga algunas mejoras para descubrir una nueva ruta cuando ocurra el error.

Para las pruebas, creo que sería bueno si solo se ejecuta durante unos días / semanas y veremos si las luces aún dejan de responder a los unicasts. En este caso, intente si las luces aún reaccionan a los comandos del grupo o se quedan completamente en silencio.

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

Para las pruebas, creo que sería bueno si solo se ejecuta durante unos días / semanas y veremos si las luces aún dejan de responder a los unicasts. En este caso, intente si las luces aún reaccionan a los comandos del grupo o se quedan completamente en silencio.

Y cuando reacciona a los comandos de grupo, espere unos días para verificar que sigue reaccionando a los comandos de grupo. En mi caso, cuando las luces solo reaccionan a los comandos del grupo, tarde o temprano se quedan completamente en silencio.

Y cuando reacciona a los comandos de grupo, espere unos días para verificar que sigue reaccionando a los comandos de grupo. En mi caso, cuando las luces solo reaccionan a los comandos del grupo, tarde o temprano se quedan completamente en silencio.

También he visto esto en el pasado, tal vez lo hagan porque ya no se reciben unidifusiones, el tiempo lo dirá.

@manup ¿Podría estar relacionado este problema? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1657

Tal vez sí, al menos el estado alcanzable también se volvería falso cuando la ruta se interrumpa. Pero esto también puede deberse a otras razones.

He notado que hay un firmware más nuevo para algunas bombillas de ikea. El registro de cambios indica una mejora en la red / conectividad y la administración de fallas. Estoy actualizando 20 bombillas ... proporcionaré actualizaciones si es útil.

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

Lástima que no contenga fechas de lanzamiento ...

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

Lástima que no contenga fechas de lanzamiento ...

Parece que se lanzó ya que pude descargar la firma que se describe en las notas de la versión 2.3.007.

Debe haber sido alrededor de enero https://www.iphone-ticker.de/ikea-home-smart-homekit-und-bridge-update-verfuegbar-152574/

no un programador de ella. Supongo que no debería instalar r21 en conbee 2 y esperar. ¿Este es un firmware beta?

Un poco fuera de tema: también nuevo firmware para el atenuador Trådfri, actualizándolo a ZB3. Referencia cruzada # 2485, tendremos el mismo problema para el atenuador ... Espero que el sensor de movimiento del modelo antiguo sea el siguiente ...

Y aquí está la versión de prueba para ConBee I y RaspBee con la solución de error de ruta.
Espero que traiga algunas mejoras para descubrir una nueva ruta cuando ocurra el error.

Para las pruebas, creo que sería bueno si solo se ejecuta durante unos días / semanas y veremos si las luces aún dejan de responder a los unicasts. En este caso, intente si las luces aún reaccionan a los comandos del grupo o se quedan completamente en silencio.

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

Gracias, @manup , lo acabo de instalar. Veamos qué traerá.

Aunque espero que esto traiga alguna mejora, ¿cómo se siente acerca de que el firmware DeConz ignora las rutas grabadas (debido al enrutamiento mane-to-one)? En general, he visto que las rutas registradas son mucho más lógicas que las que usa el firmware DeConz.
Aunque puedo imaginar que habilitar el enrutamiento de origen es un gran trabajo, el firmware DeConz podría (¿debería?) Usar la información del paquete de registro de ruta para actualizar el primer salto a un dispositivo. Tal vez solo verifique si el último salto al coordinador coincide con lo que está almacenado en la tabla de enrutamiento y, si no es así, invalide la entrada en la tabla de enrutamiento. No estoy seguro de si está bien reemplazar la entrada con el último salto de la ruta registrada, ya que los dispositivos a lo largo del camino probablemente ignoren la información, pero al menos podría iniciar un nuevo descubrimiento de ruta para ese nodo mediante el firmware DeConz.

¿Qué piensas sobre esto?

He instalado el firmware en mi raspbee (tengo 73 nodos en su mayoría ikea), informaré los resultados.

De hecho, los números de secuencia no deberían ser iguales en este corto tiempo, revisaré el código, parece que falta un incremento.

@manup , tal vez para ayudarlo a identificar el problema, vi ese problema nuevamente hoy. Parece estar relacionado con 2 acciones de configuración de informes muy juntas. La segunda seq: 183 en este caso es diferente a la que reporté 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

El problema del número de secuencia debería solucionarse en 2.05.74, que se está construyendo ahora y estará disponible en unas pocas horas.

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

Y aquí está la versión de prueba para ConBee I y RaspBee con la solución de error de ruta.
Espero que traiga algunas mejoras para descubrir una nueva ruta cuando ocurra el error.
Para las pruebas, creo que sería bueno si solo se ejecuta durante unos días / semanas y veremos si las luces aún dejan de responder a los unicasts. En este caso, intente si las luces aún reaccionan a los comandos del grupo o se quedan completamente en silencio.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_Rpi_0x26340500.bin.GCF

Gracias, @manup , lo acabo de instalar. Veamos qué traerá.

Aunque espero que esto traiga alguna mejora, ¿cómo se siente acerca de que el firmware DeConz ignora las rutas grabadas (debido al enrutamiento mane-to-one)? En general, he visto que las rutas registradas son mucho más lógicas que las que usa el firmware DeConz.
Aunque puedo imaginar que habilitar el enrutamiento de origen es un gran trabajo, el firmware DeConz podría (¿debería?) Usar la información del paquete de registro de ruta para actualizar el primer salto a un dispositivo. Tal vez solo verifique si el último salto al coordinador coincide con lo que está almacenado en la tabla de enrutamiento y, si no es así, invalide la entrada en la tabla de enrutamiento. No estoy seguro de si está bien reemplazar la entrada con el último salto de la ruta registrada, ya que los dispositivos a lo largo del camino probablemente ignoren la información, pero al menos podría iniciar un nuevo descubrimiento de ruta para ese nodo mediante el firmware DeConz.

¿Qué piensas sobre esto?

Hmm, extraño, el firmware ya debería usar estos registros de ruta para establecer nuevas rutas, necesito verificar el código aquí, pero si mi memoria me atiende correctamente, esto se habilitó hace un tiempo.

¿Qué piensas sobre esto?

Hmm, extraño, el firmware ya debería usar estos registros de ruta para establecer nuevas rutas, necesito verificar el código aquí, pero si mi memoria me atiende correctamente, esto se habilitó hace un tiempo.

Bueno, hice esto con Zolder y Garage (de varias publicaciones) y obtuve este comportamiento:

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

El registro de ruta mostró:

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

La siguiente comunicación de DeConz a Garage hace:

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

Así que claramente no se está haciendo cargo de las grabaciones de la ruta.

Lo que noté en este momento fue que, tan pronto como apagué Zolder , DeConz inmediatamente pudo encontrar una nueva ruta. Entonces, tal vez algunas de las tablas relacionadas con el enrutamiento estén llenas dentro del firmware DeConz. ¿Podría ser esto cierto? ¿Qué tamaño tienen las tablas de enrutamiento / vecino en el firmware? ¿Podría una tabla completa estar bloqueando la adopción de nuevas grabaciones de ruta?

¡Éxito! Puedo confirmar que el comportamiento es ahora que después de una falla de enlace que no es de árbol, el descubrimiento de rutas comienza de hecho.

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

El problema del número de secuencia debería solucionarse en 2.05.74, que se está construyendo ahora y estará disponible en unas pocas horas.

33d8a8b

"swversion": "2.5.74",

: smile: Gracias @manup gran tiempo de respuesta: 1st_place_medal:

Espere la actualización a 2.05.74 o use http://phoscon.de/app para mostrar la aplicación Phoscon. Acabamos de ver que una página de puerta de enlace sin conexión se muestra en algunas páginas donde no debería, reconstruyéndose ahora ~ 2 horas.

De hecho, los números de secuencia no deberían ser iguales en este corto tiempo, revisaré el código, parece que falta un incremento.

Aquí está el primer firmware de prueba para ConBee II

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

Ahora, la transferencia de esto al firmware ConBee I / RaspBee estará en línea en breve.

Este FW no me funciona. Muestra todos mis dispositivos como unidos, pero no se construye ninguna malla. Ni las conexiones se muestran en la GUI, ni tampoco funcionó ningún cambio desde Phoscon (2.05.74). Volvió a flashear el Conbee II a 264A0700 y todo funciona de nuevo como se esperaba ...

Hmm, extraño, ¿cuánto tiempo duró?
Estoy ejecutando este firmware en varias configuraciones ahora sin problemas hasta ahora.

Hmm, extraño, ¿cuánto tiempo duró?
Estoy ejecutando este firmware en varias configuraciones ahora sin problemas hasta ahora.

Unos minutos. He visto algunas actividades en algunos dispositivos (puntos azules) pero no se han creado enlaces. Y el cambio no funcionó en absoluto. ¿Debería probar durante más tiempo?

Puede tomar un tiempo hasta que la malla se construya, pero debería ver líneas después de 5 a 10 minutos.

Este FW no me funciona.

Lo mismo aquí, Rasperry Pi 4B, deCONZ 2.05.74, ConBee II. Pequeña red de prueba con repetidor Trådri, enchufe Trådfri, XBee, atenuador Trådfri, 2 sensores de movimiento Trådfri (antiguos y nuevos) e interruptor Trådri On / Off. Gateway no parece enviar ni recibir tráfico de ningún dispositivo. Ver USB se desconecta en el syslog. Todo vuelve a ser perfecto, después de volver a 4A.
log.gz

Solo volvió a parpadear para probar:

• sin líneas en la GUI (déjelo funcionar durante 15 minutos)
• La conexión USB parece estable
• Los interruptores UBISYS C4 y D1 siguen funcionando
• Los botones de Tradfri no

@ebaauw el registro muestra que el coordinador ve solo dos vecinos con esta versión.

Quizás sea el tamaño de la red. Actualmente solo tengo 40 dispositivos alimentados aquí. Esta versión de firmware tiene otros dos cambios que podrían ser la causa, un aumento en el tamaño del búfer de mensajes (un poco por encima de lo que puedo decir, lo reducirá nuevamente) y una configuración de potencia de TX ligeramente más baja.

Prepararé otra versión con estas configuraciones eliminadas para ver si funciona mejor.

¿Utiliza un cable de extensión USB o el ConBee II está conectado directamente?

Para mí funciona bien en Raspbee ...

En RaspBee y ConBee 1 solo se incluye la corrección de ruta en la nueva versión (firmware diferente).

el registro muestra que el coordinador ve solo dos vecinos con esta versión.

Sí, dos de los dispositivos finales se mostraron como vecinos en la GUI. Un poco extraño, porque se mostraron conectados a otro enrutador después de degradar el firmware de ConBee II.

¿Utiliza un cable de extensión USB o el ConBee II está conectado directamente?

Ha estado conectado directamente desde que lo obtuve. A un puerto USB-2 en el Pi, con el XBee conectado al otro puerto USB-2; nada en USB-3. La conexión ha sido estable, excepto cuando configuré el ConBee II como enrutador (ver # 2463).

En RaspBee y ConBee 1 solo se incluye la corrección de ruta en la nueva versión (firmware diferente).

No lo he probado todavía. Tendré que esperar hasta más tarde ...

Veo muchos paquetes de informes de configuración. Después de buscar un poco, parece que estos se envían periódicamente cada media hora. ¿Cuál es la razón por la que estas solicitudes de informes de configuración se repiten periódicamente?
@ebaauw , ¿recuerdo correctamente que hiciste muchas de estas investigaciones sobre el comportamiento del coordinador de IKEA? ¿También hace eso?

Me di cuenta en de_web_plugin_private.h

#define IDLE_ATTR_REPORT_BIND_LIMIT 1800

Encontré otra evidencia con respecto al comportamiento de enrutamiento de DeConz ignorando los registros de ruta de muchos a uno. Está provocando que algunos enrutadores tengan que averiguar el enrutamiento a la manera "antigua".
(tenga en cuenta que tengo algunas interferencias devellish en el paquete 117130: guiño :)

La ruta de badkamer ledstrip , según DeConz, comienza con el On/Off light 36 que obviamente no sabe cómo llegar. Entonces comienza un descubrimiento de ruta y finalmente descubre que puede (apenas, creo) alcanzar el ledstrip sí mismo. La ruta de retorno es a través de Gang 1

Parece que On/Off light 36 olvida de Badkamer ledstrip cada vez que se procesa una solicitud de ruta de muchos a uno ...

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 comunicación:

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

Otro intento con el firmware de ConBee II:

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

Esta versión tiene la configuración de potencia TX de 0x264a0700. Los búferes siguen siendo grandes (pero según el mapa deberían caber bien en la RAM) para verificar solo una cosa a la vez.

Recibí este error cada vez que intento actualizar al firmware más reciente. ¿Alguna pista por qué?
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26530700.bin.GCF
GCFFlasher V3_13 (c) dresde elektronik ingenieurtechnik gmbh
Reiniciar dispositivo / dev / ttyACM1 (ConBee II)
Versión de firmware deCONZ 26490700
Cargador de arranque R21B18
Vers: 2.05
construcción: 22 de marzo de 2019
intermitente 161378 bytes: | ============================== |
verificar:.
Error al actualizar Flash, CRC no válido. Inténtalo de nuevo.
rich710 @ RichHassPc01 : ~ $

¿Ha verificado la suma MD5 del archivo descargado? (http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF.md5)

Sí, lo he verificado y descargado varias veces, incluso intenté volver al firmware anterior y todo salió bien, hasta ahora. Ahora estoy atascado con este error, he reiniciado mi NUC varias veces pero todavía estoy atascado cuando el flasher intenta reiniciar mi ConbeeII.
rich710 @ RichHassPc01 : ~ $ sudo GCFFlasher_internal -d / dev / ttyACM1 -f deCONZ_ConBeeII_0x26490700.bin.GCF
[sudo] contraseña para rich710:
GCFFlasher V3_13 (c) dresde elektronik ingenieurtechnik gmbh
Reiniciar dispositivo / dev / ttyACM1 (ConBee II)

2139: Error: no se pudo restablecer uart, verificar reintentar

Noté que usa ttyACM1, cuando usa

GCFFlasher -l

Mostrará el número de serie.
Puede usarlo para proporcionar un nombre de dispositivo más estable en el comando.

GCFFlasher_internal -sn DE1948474 -f deCONZ_ConBeeII_0x26530700.bin.GCF

(reemplácelo con el número de serie de su dispositivo)

Lo siento, no funcionó, tal vez debería moverlo a mi máquina con Windows e intentar
rich710 @ RichHassPc01 : ~ $ GCFFlasher_internal -l
GCFFlasher V3_13 (c) dresde elektronik ingenieurtechnik gmbh
Camino | Proveedor | Producto | Serie | 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) dresde elektronik ingenieurtechnik gmbh
Reiniciar dispositivo (ConBee II)

2139: Error: no se pudo restablecer uart, verifique el reintento
rich710 @ RichHassPc01 : ~ $

O eso o como alternativa, puede intentar lo siguiente:

• Desenchufe el ConBee II
• GCFFlasher_internal -t 60 -sn DE1964163 -f deCONZ_ConBeeII_0x26530700.bin.GCF
• Conecta el ConBee II de nuevo

Los parámetros -t permiten que GCFFlasher intente durante un minuto procesar la actualización.

Funcionó para actualizar el firmware en Windows, y cuando lo conecté a mi NUC con ubuntu nuevamente se conectó. PERO, después de una hora, se acaba de conectar a 4 om mis nodos ..: S

Otro intento con el firmware de ConBee II: http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26530700.bin.GCF

No más desconexiones USB, pero deCONZ parece volver a detectar el ConBee II con bastante frecuencia. Todavía no hay tráfico.
log.gz

EDITAR Para complacerlo, desconecté el XBee y usé un cable de extensión USB de 10 cm para conectar el ConBee II: sin cambios.

Otro intento con el firmware de ConBee II:

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

Esta versión tiene la configuración de potencia TX de 0x264a0700. Los búferes siguen siendo grandes (pero según el mapa deberían caber bien en la RAM) para verificar solo una cosa a la vez.

Probó su nueva versión, pero después de 10 minutos todavía no se muestra ningún enlace ... Con el FW estable, todos los enlaces buenos (enrutadores) en la red se muestran después de aproximadamente 2 minutos. El botón pulsador de IKEA funciona de inmediato, mientras que con el firmware de prueba no funciona en absoluto.

Hmm espeluznante, gracias por probar esto. A continuación, intentaré reducir los tamaños de búfer como se mencionó anteriormente.
Todavía me pregunto por qué está funcionando en mi configuración. De la captura de pantalla anterior solo puedo decir que tengo más dispositivos finales que enrutadores.

@manup tuvo los mismos problemas después de actualizar el firmware, pero presionar reiniciar dispositivo en deconz / reiniciar deconz hizo que los enlaces volvieran.

Y aquí está la versión de prueba para ConBee I y RaspBee con la solución de error de ruta.

Parece funcionar bien en mi sistema de prueba Pi 3B +. Esperaré hasta este fin de semana antes de actualizar mi red de producción.

@ebaauw , ¿recuerdo correctamente que hiciste muchas de estas investigaciones sobre el comportamiento del coordinador de IKEA? ¿También hace eso?

Agregué soporte para la mayoría de los dispositivos Trådfri, pero no he podido rastrear ningún tráfico ZigBee hacia / desde el concentrador Trådfri. Solo usa emparejamiento de enlace táctil, y todavía tengo que intentar capturarlo para recuperar la clave de red. Es decir, asumiendo que sea posible.

He estado ejecutando el nuevo FW en el dispositivo conbee 1 en mi configuración de ~ 40 nodos desde el lanzamiento del nuevo firmware y ha funcionado muy bien sin problemas. (En la imagen, los nodos no conectados están sin batería o sin energía)

Gracias a todos los involucrados que solucionaron el problema y actualizaron el código. ¡Es TAN apreciado! <3

No funciona para mi. Casi no hay conexiones en la red. Ha esperado unos 20 minutos después de reiniciar.

Raspberry Pi 3 Modelo B Rev 1.2
Conbee II
versión 2.05.74
versión 26530700

77 nodos

3 Conexión a
1 interruptor de encendido / apagado TRÅDFRI
1 sensor múltiple Xiaomi
1 regulador de intensidad Philips
Puedo activar eventos desde el regulador de intensidad de Philips.
Estos que tienen conexiones están bastante cerca del palo Conbee. El palo se encuentra en el garaje. Tengo unas bombillas en el garaje que no tienen conexiones.

Sin conexión a
Muchas bombillas de ikea, tanto E27 como GU10
Muchos sensores múltiples de Xiaomi
Muchos mandos a distancia Ikea TRÅDFRI
Y otros nodos.

Registros
27 de febrero 09:29:06 raspberrypi systemd [1]: iniciado deCONZ: puerta de enlace ZigBee - API GUI / REST.
27 de febrero 09:29:06 raspberrypi deCONZ [7204]: advertencia de libEGL: DRI2: no se pudo autenticar
27 de febrero 09:29:06 raspberrypi deCONZ [7204]: advertencia de libpng: iCCP: perfil sRGB incorrecto conocido

Al degradar a 264A0700, comienza a construir la malla directamente.

@ebaauw , ¿recuerdo correctamente que hiciste muchas de estas investigaciones sobre el comportamiento del coordinador de IKEA? ¿También hace eso?

Agregué soporte para la mayoría de los dispositivos Trådfri, pero no he podido rastrear ningún tráfico ZigBee hacia / desde el concentrador Trådfri. Solo usa emparejamiento de enlace táctil, y todavía tengo que intentar capturarlo para recuperar la clave de red. Es decir, asumiendo que sea posible.

Bien, lo siento. Debería haber comprobado la culpa de git. El código que menciona el comportamiento de la puerta de enlace de IKEA fue introducido en 48d2c39a267b5c6d025577eed7530be27932aa2c por @manup ...

@manup , ¿de verdad identificó que la puerta de enlace IKEA reconfigura el atributo que informa esto a menudo? ¿Por qué sería necesaria una reconfiguración? ¿Es necesario recordar la luz con regularidad?

Conbee I actualizado a beta FW y deCONZ .74

¡La malla se construye de inmediato y se ve muy bien!

Muchas gracias a @manup también, por supuesto, por arreglarlos ...

Conbee I y .74 también. Se actualizó Ikea FW a 2.3.007 (algunos otros 2.x).
¡Gran mejora! ¡Sin abandonos todavía!

Un gran agradecimiento a todos los que contribuyeron, desarrollaron, depuraron y probaron en este hilo y más allá.

Algo que descubrí en el proceso:
El encendido / apagado del grupo normal funciona: rápido, pero después de recuperar una escena (después del desvanecimiento en el tiempo) y apagarla nuevamente (<10 segundos), las luces solo se apagan en la GUI (independientemente de la interfaz gráfica antigua o nueva) Luego, algunas de ellas vuelven a encenderse (en la interfaz gráfica de usuario) en el grupo mientras TODAS las bombillas físicas siguen encendidas. Después de presionar OFF por segunda o tercera vez, a veces se apagan.

No es raro restaurar / reconstruir escenas después de una actualización de firmware
Pero independientemente de si construyo una nueva escena o trato de arreglar una más antigua, el comportamiento sigue siendo el mismo. El encendido-apagado normal no se ve afectado.

Descubrí que funciona como de costumbre cuando espero un poco más. Digamos 15-20 segundos. Luego, las luces se apagan como de costumbre. Supongo que Deconz se confunde como lo hace cuando apagas una luz hasta que se apaga.

Parece que obtuvimos un aumento de la demora hasta que se informa cada estado de luz y la recuperación de la escena se realiza en deconz o se informa con éxito para que otras acciones en ese grupo funcionen como se desee. Esto parece tardar un poco más ahora. Dentro de este período, no debe (pasar;)) - apagar las luces. Esto no es crítico.

Probé un poco más. Tenemos un cambio de comportamiento. Anteriormente, cuando se cambiaba un bri con una velocidad determinada, o una escena tenía un tiempo de transición más largo, era posible interrumpir con un nuevo comando. Incluso se realizó la acción anterior, el siguiente comando se puso en cola. Ahora está perdido. Las luces de suelo Egmy funcionan con sensores de movimiento. Antes de que se apaguen, los atenúo y espero 10 segundos antes de apagarlos. Cuando activé el movimiento y recuerdo la escena mientras se desvanecen, el comando se pierde. Antes de eso, se puso en cola y se ejecutó después. ¿Es esto debido a. 74 o el nuevo firmware? Gracias

Mi Conbee II no construyó mesh en la versión beta. Lo único que puedo pensar que podría ser diferente de la configuración "normal" es establecer el canal en 25. Volviendo a 264a0700 lo solucionó

@realwax , creo que está experimentando un error de firmware Trådfri, consulte el n. ° 2068. Puede verificar esto fácilmente emitiendo un comando con un tiempo de transición más largo en la GUI y luego emitiendo un segundo comando.

Antes de eso, se puso en cola y se ejecutó después.

¿Actualizaste el firmware de la luz? ¿Estás seguro de que estás usando la misma luz? El complemento de la API REST no realiza un seguimiento del tiempo de transición una vez que ha enviado un comando a la luz.

@ebaauw Gracias por guiarme en la dirección correcta. Como IKEA declaró para incluir mejoras de red y estabilidad en su registro de lanzamiento, actualizo mi TRÅDFRI Lampe E14 WS opal 400lm al firmware 2.3.007 (más reciente). Pensé que podría aliviar algunos de estos problemas. Me pregunto cómo IKEA hace el truco en su propio puente porque este es un gran problema de usabilidad. Ahora tengo que buscar tiempos de transición más rápidos, como dijo en el otro número. Experimento esto desde el día 1 pero empeoró. Ahora no solo afecta los desvanecimientos de recuperación de escenas, sino que afecta cualquier cambio con una transición más larga y eso es nuevo ... ¿Qué puedo hacer? Volver al firmware anterior es casi imposible, porque es una lucha con deconz. Gracias Erik.

Me pregunto cómo IKEA hace el truco en su propio puente porque este es un gran problema de usabilidad.

El centro de Trådfri es mucho menos activo que la puerta de enlace deCONZ o el puente Hue. Los controladores Trådfri (interruptores, atenuadores, pero también sus sensores de movimiento) controlan las luces directamente. Las luces Trådfri envían notificaciones push al concentrador con cambios de estado. El concentrador solo se necesita / se usa para su aplicación. Puede ejecutar algunas alarmas, pero no hay reglas para manejar eventos de botón ni nada sofisticado.

No estoy seguro de si la aplicación Trådfri admite la especificación de tiempos de transición más largos, pero los controladores que he visto no lo hacen. Probablemente no podrá enviar comandos desde los controladores más rápido que el tiempo de transición predeterminado de las luces. Y si lo hace en alguna ocasión, probablemente piense que no presionó completamente el botón.

@ebaauw ya veo. Lo que todavía me desconcierta es el hecho de que puedo encender y apagar un grupo de E14 (proporcionando una especie de discoteca ligera;)) en 1 segundo (encendido-apagado-encendido) ¡funciona! Pero tan pronto como presiono un botón de recuperación de escena en deconz, no puedo y el comportamiento se vuelve extraño. Aquí es donde dudo que de alguna manera sea culpa de IKEA. ¿Por qué puedo encender y apagar muy rápido, pero tan pronto como recuerdo una escena me quedo atascado al menos durante 5-10 segundos?

Tiempos medidos con precisión (20 intentos):
grupo de 8 E14
grupo ON -> grupo OFF - tiempos de conmutación 1 segundo
recordar escena -> encender -> APAGAR ¡no responde hasta 10-12 segundos!

Entiendo que con un retiro se genera más tráfico y cada bombilla recibe más mensajes, pero ¿una diferencia de 10 segundos? Incluso cuando cambio bri y ct para todo un grupo, puedo apagarlo en un segundo, pero una vez más, una recuperación es como una congelación. Creo que esto parece ser un problema de deconz, ¿no es así?

Puedo grabarlo en video. ;) Tal vez me falta conocimiento aquí, entonces por favor discúlpeme presentando mi falta de comprensión, pero de alguna manera estoy frustrado porque es una lucha ...

Me temo que todavía estoy un poco confundido acerca de las escenas. Como los grupos, no existen como un objeto en ZigBee, son solo un número bajo el cual un dispositivo (luz) almacena un estado. En la recuperación de una escena, se transmite el número y cada dispositivo restaura el estado de su memoria no volátil.

La parte difusa es que no todos los dispositivos parecen almacenar su estado correctamente al almacenar la escena: la temperatura de color es notoria en este sentido. También he visto cosas divertidas almacenando la escena mientras la luz todavía está en transición. En ese caso, el recurso /scenes está sincronizado con el estado almacenado en la luz, lo que hace que la API refleje el estado del recurso en lugar del estado real de la luz, que solo se actualizará la próxima vez que se encienda la luz. encuestado. Normalmente, el tiempo de transición se especifica al recuperar la escena, pero parece que también está en el estado almacenado.

He escrito la configuración de mi red de producción (usando ph ), por lo que puedo volver a crearla fácilmente. Me costó mucho escribir un guión para la creación de escenas de una manera predecible. Terminé configurando los estados de luz, durmiendo por un par de segundos, esperando que los estados se establecieran, almacenando la escena y nuevamente durmiendo un par de segundos, esperando que se almacenara el estado.

Puede intentar recrear su escena, pero no hay garantías ...

Podría reproducir el tema desincronizado desde el primer día. Estaba acostumbrado a desconfigurar y a la necesidad de reconfigurar la escena de vez en cuando. Ahora es realmente peor. Actualmente necesitaría buscar desde deconz a iobroker y reconstruir todas mis escenas allí. Pero esto es mucho trabajo. Ojalá esto se solucione. ¿Puedo crear un problema? Las luces ya no son confiables cuando se usan escenas ... - Intento recrear también. Ayer hice una escena de "prueba" además de las ya existentes, pero no mostró ningún otro comportamiento.

No estoy seguro si está relacionado, pero después de actualizar mi Conbee I al firmware beta y deCONZ a .74, tomó un día y ahora deCONZ perdió la conexión con el Conbee. Nunca experimenté esto en años antes ... Pero quería mencionarlo ... El registro acaba de indicar reintentos de conectarse con él una y otra vez ... El reinicio de deCONZ lo resolvió ... (usando el contenedor de la ventana acoplable)

Intenté recrear un grupo, todas las escenas ... En el proceso de creación hay muchas cosas que van mal. Cuando se usa Phoscon y la selección de bombillas "TODAS", los valores de las escenas no se almacenan correctamente. Incluso las luces configuradas muestran lo que deseaba, una recuperación no. Tienes que controlar cada luz por sí misma incluso cuando optas por la misma configuración. En particular, se debe utilizar la interfaz gráfica de usuario antigua para corregir errores de temperatura de color de colores almacenados incorrectamente. Hasta que una escena "funcione", tienes que repasar eso un par de veces, tal vez encendiendo y apagando las luces mientras estás en el proceso de configuración de la escena para que se almacene correctamente. No tengo muchos detalles técnicos aquí, pero quiero animarlos a todos en el hilo para que prueben escenas, creación, almacenamiento, recuperación y desconexión después de una recuperación. Creo que esto está estropeado con las bombillas de IKEA y empeora ... Puede que sea con IKEA, pero dudo que todo lo demás y el control de grupo directo funcione a la perfección con deconz.

Ahora revertiré / degradaré el firmware a 1.xy veré si funciona mejor. Informaré de vuelta.

OKAY. De vuelta a la mesa de dibujo. Ayer, 2 luces de IKEA se ausentaron, solo para volver después de encender un ciclo. No digo que los errores que se corrigieron no eran errores. Ellos eran. Simplemente no los que causan el problema.

Estaba investigando más profundamente el tema de los informes de atributos. Me preguntaba si la configuración repetitiva de los informes de atributos cada 30 minutos (1800) está causando los bloqueos del firmware ligero.
Noté este fragmento de código que no parece manejar rq.maxinterval == 0 explícitamente. Ahora, cómo manejar correctamente este caso es un poco difícil, ya que rq.maxinterval == 0 significa que la luz solo informará un cambio, por lo que no hay un tiempo de espera 'bueno' para ese caso ... Tal vez la implementación actual esté bien, aunque Me pregunto si puede existir una idea mejor.

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

No. Hora Fuente Transmitir Dev Recibir Dev Destino Deshabilitar Información de respuesta predeterminada
208134 10h 43m 23.151s Gang 1 Gang 1 DeConz DeConz False ZCL: Atributos del informe, 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 ZCL verdadero: Respuesta predeterminada, 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.

No. Hora Fuente Transmitir Dev Recibir Dev Destino Deshabilitar Información de respuesta predeterminada
207941 10h 43m 8.422 DeConz DeConz Gang 1 Gang 1 True ZCL: Configurar informes, Seq: 41
207949 10h 43m 8.481 Grupo 1 Grupo 1 DeConz DeConz Falso ZCL: Configurar respuesta de informe, secuencia: 41
207951 10h 43m 8.485 Grupo 1 Grupo 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 Grupo 1 Grupo 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())

Noté este fragmento de código que no parece manejar rq.maxinterval == 0 explícitamente. Ahora, cómo manejar correctamente este caso es un poco difícil, ya que rq.maxinterval == 0 significa que la luz solo informará un cambio, por lo que no hay un tiempo de espera 'bueno' para ese caso ... Tal vez la implementación actual esté bien, aunque Me pregunto si puede existir una idea mejor.

Sí, el complemento de la API REST verifica que el informe de atributos esté funcionando. Si no es así, intenta reconfigurarlo y, creo que también recurre al sondeo del dispositivo.

Hice algunos experimentos, incluido pedirle a las luces de IKEA que informaran ONOFF y LEVEL periódicamente en lugar de solo cuando se realiza un cambio. Las luces informan alegremente su estado periódicamente, por lo que puede ser una forma aceptable de evitar el problema anterior. Para ser verificado correctamente por supuesto.

Creo que corrimos con esa configuración durante bastante tiempo. Se cambió, junto con un sondeo menos frecuente de las tablas vecinas y ya no se sondearon el estado, porque parte del firmware Trådfri se colgaría (requiriendo un ciclo de energía de la luz). Dudo que la configuración de informes haya contribuido realmente al bloqueo del firmware.

Hay un poco en el paquete ZCL que dicta si debe enviarse o no Disable Default Response .

No creo que enviar la respuesta predeterminada sea tan perjudicial cuando se establece Disable Default Response bit. No enviar la respuesta predeterminada cuando el bit no está configurado puede ser perjudicial, ya que el dispositivo que espera la respuesta podría concluir que el coordinador ya no es accesible y eventualmente dejar la red.

Hay un poco en el paquete ZCL que dicta si debe enviarse o no Disable Default Response .

No creo que enviar la respuesta predeterminada sea tan perjudicial cuando se establece Disable Default Response bit. No enviar la respuesta predeterminada cuando el bit no está configurado puede ser perjudicial, ya que el dispositivo que espera la respuesta podría concluir que el coordinador ya no es accesible y eventualmente dejar la red.

@ebaauw , de hecho. Ese es exactamente el punto. deCONZ no envía un Default Response en respuesta a un Configure Reporting Response . Sucede que las luces de IKEA están solicitando un Default Response por Configure Reporting Response .
Entonces, como dices, esa puede ser la razón, junto con los Configure Reporting Request cada media hora, para que las luces de IKEA se apaguen.

Simplemente un recordatorio:
Las bombillas Ikea (E27 y GU10 v1) ocasionalmente se vuelven inalcanzables y también necesitan un ciclo de energía cuando se conectan a un puente HUE, por lo que ese problema en particular no es exclusivo de Conbee I / II
De 16 E27 y 12 GU10 en mi puente HUE, diría que una bombilla 'cuelga' cada 1-2 semanas, aproximadamente. A veces más, a veces más rápido. Este problema mejoró con las últimas versiones de firmware de HUE durante el último año y medio.

@all ¿Qué versión de firmware de Tradfri está utilizando?

¿Estás en 1.xo 2.x? Con la 2.x introdujeron zigbee 3.0. Actualicé a 2.xy comenzaron los problemas. Bombillas E14. Noté mejoras con respecto a la velocidad y la conectividad de la red. Sin embargo, dos cosas me hicieron rodar hacia atrás 20 bombillas suspiro El "suave en" ya no funcionaba. Las bombillas se encendían sin un fundido de entrada. Las escenas no funcionaban como solían hacerlo. Hablando con precisión después de recordar una escena, se necesitaba un tiempo de espera antes de apagar la luz o recordar la siguiente escena, de lo contrario, deconz se volvió asíncrono y se volvió a sincronizar mientras que la bombilla no hizo nada.

Agradezco su experiencia compartida con versiones y deconz 'impecabilidad' con 2.x que parece no estar dado.

¿Hay alguna recomendación? FW v.? Además del problema de pérdida de conexión y los problemas de conexión en el propio fw de Ikea, parece que deconz puede manejar 1.x mejor.

¡Gracias!

Estoy usando:

• Conbee 1 con firmware 0x26340500
• Deconz versión 2.05.73 (usando marthoc docker container en Debian)
• ~ 60 nodos, principalmente IKEA Trådfri
• Conbee 1 (coordinador) NO está instalado centralmente en mi casa de 200 metros cuadrados. El sistema depende en gran medida de la itinerancia y el mallado.
• El dispositivo Conbee 1 se instala en un cable de extensión USB de 0,5 metros y se monta en el lateral del estante donde reside la computadora para tener más espacio libre para las señales de RF.

Desde la actualización (el mismo día que se lanzó) del firmware de los sticks de Conbee 1, deconz ha estado funcionando como un encanto . No hay problemas en absoluto.

Ayer actualicé mi red de producción (RPi 3B +, stretch, RaspBee) a 2.05.74 y 0x26340500. Parece estable, excepto por los problemas siguientes.

No estoy seguro si está relacionado, pero la ruta a mi controlador de cortina lumi.curtain se perdió esta mañana. Los informes del controlador aún llegarían a la puerta de enlace. La ruta no se restauraría al apagar y encender el controlador. Tuve que abrir la red y apagar y encender el controlador, antes de que el coordinador lo alcanzara nuevamente.

Además, deCONZ no pudo alcanzar una de mis válvulas de radiador Eurotronic Spirit después de iniciar deCONZ, mientras seguía enviando informes. Apagar y encender el TRV lo trajo de vuelta, como de costumbre.

No tuve la oportunidad de hacer una investigación profunda esta vez, pero ambos dispositivos han sido problemáticos desde el principio, mostrando estos síntomas de vez en cuando. Lo mismo para mi persiana IKEA Fyrtur. Continuaré monitoreando la situación e informaré si tengo más problemas.

@tubalainen
¿Qué firmware está utilizando en sus bombillas tradfri? Esto hace una diferencia incluso en este hilo con respecto al problema de pérdida de conexión por lo que probé. Mis resultados son que los pasos tomados aquí mejoraron el funcionamiento de las bombillas tradfri operadas con 1.x en Conbee 1. Pero una red de 20 e14 con tradfri fw 2.3.x es un desastre. Tiempos, escenas atascadas, deconz se pone, la luz comienza a parpadear (¿se pierde?), .. como se informó anteriormente. Creo que este es un punto a discutir y mencionar para hacer una recomendación clara de ikea fw para usar en una buena experiencia. Quizás ya haya un artículo de git. Pero por mi experiencia no actualizo 😅

Así que desde mi punto de vista y horas de pruebas y flasheo. ¡Gracias por la mejora de ikea fws 1.x! ¿Es posible mitigar los problemas actuales cuando se opera 2.x? De lo contrario, no será posible actualizar a zigbee 3 con ikea actualmente. Parece que el comportamiento ha cambiado y su funcionamiento en deconz debe adaptarse. ¿Esto probablemente para que @ebaauw juzgue o trate?

Salud
Que tengas un buen domingo 😊

@realwax
He intentado actualizar FW todas mis entidades al último FW. Aquí está mi lista de todos los nodos (actualmente activos).

Estuvo de acuerdo en el lío con todas las "partes móviles" al mismo tiempo tratando de precisar la raíz de los problemas.

@tubalainen

Gracias por tu lista.

Mirando especialmente a los enrutadores (bombillas), veo que opera 2.3.007 en sus E14. ¿Puede reproducir mi lista de problemas? https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Como no tenía conocimiento de la actualización automática de fw a 2.3.x, mi red se mezcló con 1.xy 2.x no muy bien. Actualicé manualmente a 2.3.xy luego empeoró. (La red es más rápida pero la usabilidad masiva dran y, las bombillas parpadean) Así que puedo recomendar si experimentas bombillas parpadeantes en tu e14 o "lagness" en los escenarios rebajarlas a 1.2 ... Me interesaría obtener un "oficial" / declaración profesional de nuestros desarrolladores profesionales aquí sobre esto. Estoy bastante seguro de que hubo un momento en el que deconz se trató con 1.2 de manera similar y se mejoró. Siento que esto también debe hacerse para 2.3.x o Ikea lo estropeó por sí mismo. Es difícil de decir ya que no profundizo en el código.

@realwax
Estoy usando la función otau de deconz y su script de actualización de firmware para descargar los archivos fw.
No sé por qué los E14 no están actualizados ... ehum.

¿Cómo actualizó / degradó "manualmente" las bombillas?

Bien bien. Todo funciona bien y la mayor parte del enrutamiento lo hacen los E27 con fw 2.3.xy los controladores LED del panel Jormen y FLOALT.

@tubalainen
Es interesante que no experimente esos problemas. Quizás sea por el tamaño de la malla. Tengo 23 bombillas de ese 20 e14 en 2.3.007. Desactivé el otau automático porque estropeó mi usabilidad con el nuevo firmware. A través de Gui, puede degradar con el botón de actualización. Elija el firmware adecuado primero, presione actualizar y tal vez nuevamente. El estado del formulario en pausa pasa a -> en cola -> inactivo -> iniciar actualización de firmware (porcentaje). A veces se cuelga. En algún momento es necesario reiniciar. A veces, un ciclo de energía es suficiente. A veces es necesario acercar la bombilla al coordinador.

Parece que el comportamiento ha cambiado y su funcionamiento en deconz debe adaptarse. ¿Esto probablemente para que @ebaauw juzgue o trate?

No estoy seguro de a qué te refieres aquí. Manejé algunas diferencias entre el firmware ZLL y ZB3 para los controladores (control remoto Trådfri y atenuador inalámbrico Trådfri), ver # 2485. Esto se encuentra en el nivel APS en la pila ZigBee y se maneja mediante el complemento API REST.

Los problemas de enrutamiento de este tema se encuentran en el nivel NWK, que es manejado por el firmware del dispositivo. Como todos los demás aquí, no tengo acceso a las fuentes de firmware. Incluso si lo hiciera, no habría nada que pudiera hacer, ya que no conozco los detalles de las capas NWK y MAC.

@ebaauw
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
Precisamente hablando. Incluí mis hallazgos con 20 E14 2.3.007 mesh aquí. Algunas funciones se han ido y la recuperación de escenas lo estropea todo durante 10 a 15 segundos en ese grupo. No sé si esto solo está relacionado con el firmware o con la deconz. Esto es a lo que me refería con el cambio. Entonces, para el funcionamiento diario, veo 2.3.007 como no válido. Ejemplo de usabilidad dado: Un simple interruptor giratorio de escenas configurado en phoscon ya no funciona cuando no se presiona con cuidado, es decir, después de una rotación de escena para esperar. Mientras que en 1.x todo es rápido y bueno, con 2.3.x se atasca.

Gracias, @manup , lo acabo de instalar. Veamos qué traerá.
Aunque espero que esto traiga alguna mejora, ¿cómo se siente acerca de que el firmware DeConz ignora las rutas grabadas (debido al enrutamiento mane-to-one)? En general, he visto que las rutas registradas son mucho más lógicas que las que usa el firmware DeConz.
Aunque puedo imaginar que habilitar el enrutamiento de origen es un gran trabajo, el firmware DeConz podría (¿debería?) Usar la información del paquete de registro de ruta para actualizar el primer salto a un dispositivo. Tal vez solo verifique si el último salto al coordinador coincide con lo que está almacenado en la tabla de enrutamiento y, si no es así, invalide la entrada en la tabla de enrutamiento. No estoy seguro de si está bien reemplazar la entrada con el último salto de la ruta registrada, ya que los dispositivos a lo largo del camino probablemente ignoren la información, pero al menos podría iniciar un nuevo descubrimiento de ruta para ese nodo mediante el firmware DeConz.
¿Qué piensas sobre esto?

Hmm, extraño, el firmware ya debería usar estos registros de ruta para establecer nuevas rutas, necesito verificar el código aquí, pero si mi memoria me atiende correctamente, esto se habilitó hace un tiempo.

@manup , ¿encontraste algo de tiempo para mirar esto? Esta mañana encontré una situación en la que apagué y apagué una luz (IKEA) que estaba a 4 saltos del coordinador. De alguna manera, un enrutador intermedio (también IKEA) decidió que ya no conocía la ruta hacia esta luz. De hecho, veo la luz haciendo felizmente su trabajo en el enrutamiento de otras luces, informando el estado del enlace y respondiendo a Network Address Request de deCONZ. ¡Esto último está sucediendo solo porque esos son mensajes difundidos en la red ...!
Sin embargo, el enrutador en el medio está dejando caer silenciosamente cualquier marco de unidifusión que debería enrutar a esta luz. Este enrutador, por supuesto, no debería dejarlos caer silenciosamente, por otra parte, deCONZ debería ser robusto contra este mal comportamiento.
Mientras tanto, la luz envía felizmente mensajes de registro de ruta a deCONZ, que llegan y son ignorados por deCONZ.

Creo que debería haber alguna lógica que debería hacer que deCONZ reconsidere sus rutas en este caso. Especialmente, cuando detecta que las solicitudes de ZCL no están siendo respondidas. Lo que al final lleva a que la luz se marque como zombi. El descubrimiento que sigue a la marca como zombi en realidad conduce a una respuesta de la luz. Tal vez cuando se inicia un descubrimiento de un zombi, también debería invalidar cualquier información de ruta disponible. Pero mejor aún, si ya antes, la ruta se invalida cuando no se responde a un par de solicitudes de ZCL (probablemente ya en la primera o la segunda de ellas).

¿Qué piensas sobre esto?

Este nuevo firmware no solucionó mi problema.

Utilizo un Raspbee en un Pi y Home Assistant separados (que se ejecutan en un NUC) y tengo appx. 25 luces tradfri. Principalmente GU10 se usa en grupos de 3.

Tuve grandes problemas con luces individuales en un grupo de luces que no respondían y necesitaban un ciclo de energía para volver a encender. Esto sucedió tanto con Ikea FW v1 como después de actualizar las bombillas a 2.3.007.

La solución fue cambiar mi configuración de agrupar las luces en HASS a definir grupos de luces en Phoscon y hacer referencia a los grupos Phoscon como luces individuales en HASS. Después de este cambio he estado funcionando sin problemas durante un par de meses.

Quiero poder hacer la agrupación en HASS, así que actualicé mi Raspbee a 0x26340500 y Deconz a 2.05.74 y cambié mi configuración de nuevo para usar grupos de luz en HASS. Después de ejecutar esto durante una semana, las bombillas se han quedado obsoletas 3 o 4 veces, y ahora estoy volviendo a usar grupos Phoscon nuevamente.

Creo que debería haber alguna lógica que debería hacer que deCONZ reconsidere sus rutas en este caso. Especialmente, cuando detecta que las solicitudes de ZCL no están siendo respondidas. Lo que al final lleva a que la luz se marque como zombi. El descubrimiento que sigue a la marca como zombi en realidad conduce a una respuesta de la luz. Tal vez cuando se inicia un descubrimiento de un zombi, también debería invalidar cualquier información de ruta disponible. Pero mejor aún, si ya antes, la ruta se invalida cuando no se responde a un par de solicitudes de ZCL (probablemente ya en la primera o la segunda de ellas).

Todavía estoy en el nuevo firmware y pruebo algunas cosas, incluidos los registros de ruta, espero que esté en línea esta semana.

¿Qué piensas sobre esto?

Ese es un buen punto, necesito verificar el código del complemento principal y REST-API aquí, ya que creo que el firmware debería degradar la "calidad" de la ruta ya cuando no se recibe ningún ACK de nivel APS. El APS ACK es un indicador que se establece opcionalmente en las solicitudes ZCL / APS y, a menudo, se deshabilita para reducir el tráfico de la red. Entonces, una idea aproximada es que deberíamos habilitar APS ACK si el complemento detecta que las solicitudes de unidifusión provocan tiempos de espera.

Quizás parte de esto ya esté en su lugar, es necesario verificar el código.

Sin embargo, el enrutador en el medio está dejando caer silenciosamente cualquier marco de unidifusión que debería enrutar a esta luz. Este enrutador, por supuesto, no debería dejarlos caer silenciosamente, por otra parte, deCONZ debería ser robusto contra este mal comportamiento.

La luz debería tomar una nueva ruta tan pronto como se active el descubrimiento de una nueva ruta. Por lo tanto, el objetivo debe ser detectar la ruta rota lo más rápido posible (con suerte, APS ACK hará el truco) y activar el descubrimiento de la ruta.

La máquina de estado para eso ya está en su lugar en el núcleo deCONZ (esto es lo que lleva a la transmisión de la solicitud de dirección NWK) esto funciona en el caso de enlaces de un salto y para luces que recogen rutas basadas en comandos entrantes (la respuesta a la transmitir). La transmisión es agradable ya que también respeta el cambio a la dirección NWK porque se incluye la dirección MAC. Intentaré enviar una unidifusión con APS ACK habilitado como siguiente paso en caso de que no se reciba respuesta.

Desafortunadamente, ayer también tuve que apagar y encender una bombilla IKEA E27 (White 1000LM, firmware v1). Solo reaccionó al grupo, pero no a los comandos de unidifusión. Parece que el problema aún no se ha solucionado :(

(y sí, estoy en v74 y el firmware beta para RaspBee)

Vea los comentarios anteriores, los próximos cambios pueden ayudar a recuperar el enrutamiento.

¿Qué piensas sobre esto?

Ese es un buen punto, necesito verificar el código del complemento principal y REST-API aquí, ya que creo que el firmware debería degradar la "calidad" de la ruta ya cuando no se recibe ningún ACK de nivel APS. El APS ACK es un indicador que se establece opcionalmente en las solicitudes ZCL / APS y, a menudo, se deshabilita para reducir el tráfico de la red. Entonces, una idea aproximada es que deberíamos habilitar APS ACK si el complemento detecta que las solicitudes de unidifusión provocan tiempos de espera.

Quizás parte de esto ya esté en su lugar, es necesario verificar el código.

Parece que incluso cuando se establece el bit de solicitud APS ACK, deCONZ no hace nada con el ack faltante (solo un reintento y luego nada ...)

Por cierto, houtlamp 2 es el que suelta los paquetes dirigidos 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

Sin embargo, el enrutador en el medio está dejando caer silenciosamente cualquier marco de unidifusión que debería enrutar a esta luz. Este enrutador, por supuesto, no debería dejarlos caer silenciosamente, por otra parte, deCONZ debería ser robusto contra este mal comportamiento.

La luz debería tomar una nueva ruta tan pronto como se active el descubrimiento de una nueva ruta. Por lo tanto, el objetivo debe ser detectar la ruta rota lo más rápido posible (con suerte, APS ACK hará el truco) y activar el descubrimiento de la ruta.

La máquina de estado para eso ya está en su lugar en el núcleo deCONZ (esto es lo que lleva a la transmisión de la solicitud de dirección NWK) esto funciona en el caso de enlaces de un salto y para luces que recogen rutas basadas en comandos entrantes (la respuesta a la transmitir). La transmisión es agradable ya que también respeta el cambio a la dirección NWK porque se incluye la dirección MAC. Intentaré enviar una unidifusión con APS ACK habilitado como siguiente paso en caso de que no se reciba respuesta.

En realidad, el houtlamp 2 nunca ve una respuesta a la transmisión address request . Los mensajes a deCONZ se enrutan a través de tuin linksvoor 3 , por lo que incluso si houtlamp 2 recogiera esa ruta, nunca tendrá la oportunidad. Esto se debe nuevamente a que deCONZ no recoge el route record como una nueva ruta.

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]

Ahora Tuin linksvoor 2 envía una respuesta a la transmisión network address request y tiene éxito, pero el APS ACK de deCONZ nunca llega a Tuin linksvoor 2 , ya que se reduce en houtlamp 2 . Entonces se vuelve a enviar un par de veces antes de darse por vencido. Eso tendrá una buena posibilidad de estropear 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 + último fw + .74 no está jugando al 100%.
Tuve bastantes aciertos / errores. Parece funcionar mejor con .73 para mí, pero no al 100%.

Así que volvamos a la mesa de dibujo. Todavía no está 100% bien con el nuevo (beta) Conbee 1 fw.

Después de un par de días de funcionamiento con .74 y 26340500 en Conbee 1 en Tradfir E14 con firmware 1.2.221 se puede informar que:

La luz de IKEA se volvió más estable en términos de abandono de la red, aunque solo tuve una bombilla que se perdió en 4 días. También descubrí que si te estresas mucho con tu red zigbee operada por deconz que se ejecuta en E14 fw 1.2.221. Ejecuté un script que se desvanecía en una bombilla enviando solicitudes individuales con bri cambiado cada segundo. De esa manera perdí 4 bombillas muy rápido. Pero quién quiere eso de todos modos;)

Aún sin resolver:
El problema y la preocupación que todavía tengo es que Tradfri FW 2.3.x no está funcionando bien o no está bien implementado para usarse con deconz. Está bien permanecer en tradfri fw 1.2.xy no ir a zigbee 3.0. Pero habrá un momento en el que no se podrá evitar. O me temo que las bombillas nuevas se degradarán más.
Descubrí que un grupo de 2-3 bombillas no muestra ese problema tan mal como un grupo de 4-8 bombillas.
Informé mi hallazgo aquí y estoy feliz y agradecido si lo recogen. Intenté crear conciencia aquí https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518
ya que puedo reproducir este problema simplemente poniendo toda mi bombilla a 2.3.xy espero que tú también puedas hacerlo.

En pocas palabras: hace una diferencia sobre qué firmware tradfri se usa y del que estamos hablando. Existe una gran diferencia en la usabilidad y el problema experimentado y el funcionamiento con deconz. Si bien es más probable que los fws 1.2.x sean más antiguos y funcionen como un encanto junto a los abandonos conocidos, 2.3.x no ha perdido usabilidad como se describe en el problema planteado. No puedo imaginar que soy el único que experimenta esta diferencia en los FW.

Ahora he enviado un correo electrónico al soporte de dresden elektronik en alemán para crear conciencia sobre esto, ya que entendí que algunos de ustedes son entusiastas del hobby, como @ebaauw dejó en claro en otro hilo. Creo que la mayoría de los desarrolladores son contratistas de dresden elektronik. Perdón por el error y gracias por sus contribuciones. Tengo curiosidad por la respuesta oficial ahora.

¿El firmware de Conbee II también está arreglado ahora? Solo vi a Conbee I en el comunicado. Gracias a todos por su arduo trabajo por cierto.

Esto se debe nuevamente a que deCONZ no recoge el registro de ruta como una nueva ruta.

@djwlindenaar resulta que soy yo el culpable, he comprobado que el código de registro de ruta se confirma en el repositorio de la pila (ConBee I y RaspBee I). En 2018, agregué una "solución" (o eso pensé) para un problema similar que simplemente deshabilitó la actualización de la dirección del siguiente salto en un registro de ruta entrante.

Si mi memoria no me falla, el problema en ese momento era que teníamos una gran red mixta de alrededor de 150 nodos y los registros de ruta aparentemente no funcionaban correctamente. El nuevo camino de regreso no funcionaba correctamente. Sin embargo, el código podría haber funcionado con la otra solución de los códigos de error del comando de estado del NWK.

Revierto esto ahora, por lo que el registro de ruta debería actualizar la ruta a la mejor ruta.

Me encanta ese párrafo de la especificación Zigbee:

Un enrutador ZigBee o un coordinador ZigBee pueden mantener una tabla de enrutamiento. La información que se almacenará en una entrada de la tabla de enrutamiento de ZigBee se muestra en la Tabla 3-66. La antigüedad y el retiro de las entradas de la tabla de enrutamiento para volver a reclamar el espacio de la tabla de las entradas que ya no se utilizan es una práctica recomendada; sin embargo, está fuera del alcance de esta especificación.

Lo que básicamente significa que cada pila maneja el envejecimiento de la ruta de manera diferente.

Así que he comprobado cómo funciona en nuestro caso. En Bitcloud Zigbee, las rutas de la pila tienen una "tasa" de ruta, que inicialmente es 1.

1. En una transmisión NWK exitosa, la tasa se incrementa si está por debajo del máximo que es
   (1 << 8) - 1 = 255
2. En una transmisión NWK exitosa, si se alcanza el máximo de 255, todas las entradas de la tabla de enrutamiento se "normalizan"
   rate = (rate >> 1) + 1 (dividido efectivamente por 2, con un mínimo de 1)
3. En una transmisión NWK fallida, la velocidad de la entrada de ruta relacionada se establece como:
   rate -= (rate / 2) > 0 ? rate / 2 : 1
4. En demasiadas transmisiones fallidas, la tasa se vuelve 0 y la ruta se elimina

Esto significa que un enlace superior se degradará como:

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

Por lo tanto, se necesitan 8 comandos fallidos hasta que se elimina una entrada y se inicia el descubrimiento nuevamente.
Eso está bastante bien en redes normales, especialmente cuando crecen a 50 ... 100 nodos, una ruta no debe descartarse demasiado pronto.

Lo que me preocupa es el punto (2) porque, por ejemplo, una ruta muy nueva o una que no se usa que a menudo se degradaría por nodos de alto rendimiento completamente no relacionados con buenos enlaces, por ejemplo, una luz Philips Hue que se sondea cada pocos segundos. trigger (2) a menudo multiplica eso por el número de luces en una red grande. Sin mencionar las actualizaciones activas de OTA.

Creo que es seguro cambiar (2) para no degradar (normalizar) todas las entradas de ruta, sino solo la ruta principal 255 relacionada con la transmisión exitosa. Esto debería evitar perder rutas que funcionaron bien pero no se usaron con frecuencia y se eliminaron en la primera transmisión NWK fallida.

Construiré un nuevo firmware con estos cambios mañana, también uno para ConBee II probablemente lo mismo se aplica allí.

Revierto esto ahora, por lo que el registro de ruta debería actualizar la ruta a la mejor ruta.

OK suena bien. ¡Estoy deseando probar!

Me encanta ese párrafo de la especificación Zigbee:

Sí, supongo que este tipo de especificación nos está dificultando conseguir que todos los proveedores coexistan bien. :sonreír:

En Bitcloud Zigbee, las rutas de la pila tienen una "tasa" de ruta, que inicialmente es 1.

Realmente no entiendo la lógica detrás de la regla 2. Parece una especie de versión pobre del envejecimiento. Lo cual funciona bastante bien si todos los nodos ven una cantidad similar de tráfico, pero de hecho, si está desequilibrado (lo que creo que es bastante común), saldrá mal.
Noté que ZStack está usando un campo expiryTime real en su tabla de enrutamiento, al lado de un byte status .

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

¿Cómo funciona este realmente?
Si no me equivoco, una transmisión NWK fallida en realidad significa solo el siguiente salto, ya que NWK solo verifica el 802.15.4 MAC ACK. Entonces, para verificar si la transmisión de extremo a extremo está bien, debemos confiar en APS ack. ¿Es eso correcto? ¿Funciona de esta manera en BitCloud?
Además: si el bit de solicitud de confirmación en la capa APS no está establecido, ¿se considera una transmisión exitosa (ya que no se espera ninguna confirmación) y eso aumenta la "tasa" de esa entrada de ruta? Porque si es así, podríamos estar disparándonos en el pie al no solicitar ACK de capa APS todo el tiempo.

Si solo se basa en fallas de NWK, entonces esto no ayudará a la situación de que un enrutador intermedio se está portando mal y necesitamos agregar lógica adicional para tener en cuenta que los ACK de la capa APS no llegan. Probablemente basado en una lógica similar para detectar enrutadores 'zombies', pero primero invalidando la entrada de la tabla de rutas para esa ruta.

La versión de firmware 0x26350500 para ConBee I y RaspBee I está disponible para pruebas.

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

• Como 0x26340500, todos los errores de ruta de estado de NWK se manejan
• Corrija la degradación de la ruta injusta (consulte el punto 2. en https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-596142584)
• Los registros de ruta fija no actualizaron el siguiente salto de una ruta, tenga en cuenta que esto ahora funcionará, pero solo si el costo de la ruta actual es mayor cuando el registro de ruta
• Corregir las solicitudes APS fallidas con APS ACK habilitado no degradó la ruta

Ahora estoy buscando en el código de ConBee II para ver si se pueden aplicar estas correcciones y dónde. Descartando 0x26520700 y 0x26530700 y basando esto en el 0x264a0700 estable actual.

Realmente no entiendo la lógica detrás de la regla 2. Parece una especie de versión pobre del envejecimiento. Lo cual funciona bastante bien si todos los nodos ven una cantidad similar de tráfico, pero de hecho, si está desequilibrado (lo que creo que es bastante común), saldrá mal.
Noté que ZStack está usando un campo expiryTime real en su tabla de enrutamiento, junto a un byte de estado.

Totalmente de acuerdo, esto ahora está arreglado, por lo que solo la ruta de una transmisión exitosa se normaliza cuando la tasa alcanza el máximo. La forma de manejar esto con el temporizador vencido podría ser otra opción, pero tiene sus propias trampas a escala. Creo que tener la forma de "tasa" debería funcionar bastante bien sin depender del tamaño de la red y el tiempo.

Si solo se basa en fallas de NWK, entonces esto no ayudará a la situación de que un enrutador intermedio se está portando mal y necesitamos agregar lógica adicional para tener en cuenta que los ACK de la capa APS no llegan. Probablemente basado en una lógica similar para detectar enrutadores 'zombies', pero primero invalidando la entrada de la tabla de rutas para esa ruta.

Este parecía ser el caso y, de hecho, los enrutadores que se comportan mal, que no envían comandos de estado NWK con fallas de ruta, podrían mantener viva una ruta muerta. Esto ahora está arreglado en 0x26350500 pero se basa en los comandos habilitados para APS ACK. Lo cual debería estar bien y puede ser controlado por deCONz y el complemento REST-API.

La versión de firmware 0x26350500 para ConBee I y RaspBee I está disponible para pruebas.

Lo brilló, ahora probando.

Esto ahora está arreglado en 0x26350500 pero se basa en los comandos habilitados para APS ACK.

¿Qué haces en respuesta a un ACK perdido? ¿Reduce a la mitad el rate igual que con una transmisión NWK fallida o más / diferente? Porque creo que un APS ACK faltante debería contarse como más grave en comparación con una transmisión NWK fallida. De lo contrario, nuevamente en el caso de un enrutador que no funcione correctamente, las transmisiones NWK exitosas pueden aumentar el rate más que los ACK APS faltantes lo reducen.

¿Qué haces en respuesta a un ACK perdido? ¿Reduce a la mitad el valor de la tasa igual que con una transmisión NWK fallida o más / diferente? Porque creo que un APS ACK faltante debería contarse como más grave en comparación con una transmisión NWK fallida. De lo contrario, nuevamente, en el caso de un enrutador que se comporte mal, las transmisiones NWK exitosas pueden aumentar la velocidad más que los ACK APS faltantes la reducen.

Pensé lo mismo, esto es lo que está sucediendo en ese caso:

• Transmisión NWK positiva MAC ACK rate + 1
• Sin APS ACK rate = rate / 4

Entonces, la tasa cae bastante rápido, puede ser un poco demasiado agresiva y rate / 2 es suficiente, pero veamos cómo funciona en la práctica.

Agradable. Lo ejecutaré e informaré.

Actualmente también se realizan pruebas de estrés enviando mensajes de unidifusión (OnOffwithLevel) a una luz que está bastante lejos en la malla, cada pocos segundos.

Por cierto, también cambié el resto del código del complemento para solicitar APS ACK en todos los mensajes.

Estoy ejecutando Deconz en un Rpi 3B + usando Home Assistant
Actualmente ejecutando 2.05.75 con Conbee I y 26330500

Noté que esta noche algunas luces no estaban encendidas.
Intenté activarlos manualmente, consulte el registro a continuación.
Verificada la malla VNC, es parte de la red de malla pero no reacciona a nada.
Este nodo es un interruptor de salida de encendido / apagado de Tradfri.

Algo extraño aquí:
_ PUEDO poner el interruptor cuando habilito el grupo Deconz en lugar del interruptor individual ._

19: 23: 58: 979 retrasar el envío de la solicitud 57 dt 0 ms a 0x000D6FFFFEB1C9FF, ep: 0x01 cluster: 0x0004 onAir: 1
19: 24: 15: 744 Canal actual 25
19: 24: 15: 776 Dispositivo TTL 3920 indicadores s: 0x7
19: 24: 46: 764 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 25: 10: 547 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 25: 15: 749 Canal actual 25
19: 25: 15: 782 Dispositivo TTL 3860 s banderas: 0x7
19: 25: 33: 885 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 25: 49: 411 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 26: 12: 765 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 26: 12: 765 errores de transmisión máximos para el nodo 0x000D6FFFFEB1C9FF, visto por última vez por los vecinos 25 s
19: 26: 15: 742 Canal actual 25
19: 26: 15: 774 Dispositivo TTL 3800 s banderas: 0x7
19: 26: 48: 221 0x000D6FFFFEB1C9FF error APSDE-DATA.confirm: 0xA7 en la tarea
19: 26: 48: 221 errores de transmisión máximos para el nodo 0x000D6FFFFEB1C9FF, visto por última vez por los vecinos 60 s
19: 27: 03: 845 estado de nodo guardado en 9 ms
19: 27: 33: 634 sincronización () en 29789 ms

Las últimas correcciones están en 26350500 ...

@djwlindenaar Estoy conteniendo la respiración esperando los resultados de tu prueba :-)

Hasta aquí todo bien. Puedo ver a deCONZ felizmente cambiando de ruta. :sonreír:

Las últimas correcciones están en 26350500 ...

Lo siento, leyó mal la versión FW.
Quiero ayudar con las pruebas, utilizando el complemento oficial Home Assistant Deconz, no estoy seguro de cómo actualizar este a un firmware beta. (las actualizaciones oficiales son OTA)

Estimado @manup , ¿algún estado en la actualización de fw de Conbee ii?

@manup , parece que no hay ninguna acción en Many-to-One Route Failure (0x0c) . Espero que deCONZ vuelva a hacer un MTORR (a menos que ya haya uno en progreso). Recibo estos mensajes con regularidad.

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 todavía no siempre es asumido por deCONZ. Por ejemplo:

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

La luz Tuin linksvoor 2 se envía directamente a deCONZ , pero la ruta desde deCONZ es a través de varios saltos ...
Sería útil si pudiera dar una idea del proceso de toma de decisiones en deCONZ para aceptar la ruta del mensaje route record si / no.

--- Edité los siguientes elementos, porque había un error en mi razonamiento. Ahora, con suerte, no: guiño: ---

Dicho esto, la ruta que utiliza deCONZ es en realidad mucho más confiable que la comunicación directa a Tuin linksvoor 2 . Esto me hizo preguntarme y analizar el enrutamiento de varios a uno. Estoy pensando que tal vez la potencia de transmisión del Raspbee no sea la ideal ...
Este es mi razonamiento:

• El enrutamiento muchos a uno se basa en la recepción de transmisiones
• A diferencia del manejo de ruta normal, el costo máximo de ruta entrante y saliente se toma como el costo del siguiente salto
• Ahora bien, si un enrutador o el coordinador es mucho mejor para transmitir (alta potencia de TX) que para recibir (baja sensibilidad de RX), esto puede llevar a que el enrutamiento de muchos a uno no funcione muy bien.

Un punto relacionado que noté es que deCONZ parece ser (muy) optimista sobre el costo de entrada en su tabla de ruta. Cuando Tuin linksvoor 2 envía un mensaje a deCONZ directamente, necesita muchos reintentos, todo el tiempo. Ahora, si miro en la tabla de rutas, veo lo siguiente, y no esperaría una transmisión difícil a un costo de entrada de 4. Tenga en cuenta que básicamente todos los elementos de la tabla de rutas tienen un costo de entrada mucho más bajo que el costo de salida.

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

Entonces, si deCONZ fuera menos optimista sobre el costo de entrada, es posible que estemos viendo un mejor comportamiento de la ruta. O si aumentamos la potencia TX para que sea más equilibrada (costo similar para la entrada y la salida)
O si redujéramos la potencia de TX de deCONZ, espero que necesite enrutar más saltos (los dispositivos de costo 7 desaparecerían de la tabla de enrutamiento), pero también será más fácil recibir los mensajes entrantes.

Lista total del mensaje de estado del enlace 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

Perdón por el retraso. Estado: todavía estamos trabajando duro en la nueva versión y seguimos rastreando errores en el firmware que parecen ser más complejos de lo que pensamos. Algo en el manejo de nvram parece estar mal. También estamos buscando resolver los problemas de enumeración / inicio de USB.

Publicaré actualizaciones aquí tan pronto como estén disponibles.

Actualización: ¡sigue siendo fuerte!

No creo que haya visto la red tan estable. Ahora he cambiado varias reglas para usar unidifusión en lugar de grupos. Ahora durante 2 semanas y 0 luces IKEA desaparecieron.

(Espero no maldecirlo ahora)

Tenga en cuenta que cambié el complemento REST para solicitar APS ack para todas las solicitudes.

También estoy experimentando una red mucho mejor. Aunque no al 100%. Ha habido focos ocasionales que no respondieron, pero cuando alteré manualmente el foco de IKEA respondió. También veo que el estado de la bombilla es ahora el mismo que el estado físico.
Sin embargo, una de mis bombillas Osram tuvo un comportamiento irresponsable como las bombillas ikea antes. Lo positivo es que no es un comportamiento tan severo como lo hizo el ikea.

Espero que esto pueda ser confirmado por otros o por hallazgos identificados.

Estoy ejecutando Conbee 1, con FW 26350500 y Deconz 2.05.75.
Esta es mi experiencia las ultimas semanas

• Funciona mejor pero no al 100%
• Algunas de mis bombillas IKEA E27 TRÅDFRI E27 WS opal 980lm con fw 2.3.007 a veces no responden a los comandos de apagado
• Puedo intentar apagarlos nuevamente y generalmente funciona (no es necesario apagar y encender)

@djwlindenaar ¡agradable! ¿Su corrección de APS para la API REST está incluida en la versión .75? Solo para saber si eso podría explicar algunas diferencias en publicaciones anteriores ...

No, no es. Ni siquiera he creado una solicitud de extracción para ello. Con eso puedes construirlo tú mismo. Lo haré hoy o mañana.
También puedo compartir el complemento de API de descanso integrado, pero solo tengo el de raspberry 3.

@tubalainen , comprobaré si eso se puede explicar con el reconocimiento de APS. Además, no tengo luces 2.3 IKEA.

Posiblemente, hay un problema con el comportamiento de reintento en deCONZ. Necesitaría hacer un experimento para eso o tal vez ya esté en los registros de rastreo.

Si puedes oler, es útil obtener un olfato de ese fenómeno. Puedo ayudar a analizar si no puedes.

Ayer actualicé mi red de producción (RPi 3B +, stretch, RaspBee) a 2.05.74 y 0x26340500. Parece estable, excepto por los problemas siguientes.
No estoy seguro de si está relacionado, pero la ruta a mi controlador de cortina lumi.curtain se perdió esta mañana. Los informes del controlador aún llegarían a la puerta de enlace. La ruta no se restauraría al apagar y encender el controlador. Tuve que abrir la red y apagar y encender el controlador, antes de que el coordinador lo alcanzara nuevamente.
Además, deCONZ no pudo alcanzar una de mis válvulas de radiador Eurotronic Spirit después de iniciar deCONZ, mientras seguía enviando informes. Apagar y encender el TRV lo trajo de vuelta, como de costumbre.
No tuve la oportunidad de hacer una investigación profunda esta vez, pero ambos dispositivos han sido problemáticos desde el principio, mostrando estos síntomas de vez en cuando. Lo mismo para mi persiana IKEA Fyrtur. Continuaré monitoreando la situación e informaré si tengo más problemas.

Es muy difícil registrar estos problemas intermitentes de manera objetiva, pero tengo la impresión de que 0x26350500 ha traído mejoras aquí. Aparte de los dispositivos mencionados anteriormente, mi red es muy estable. He tenido algunos TRV que se vuelven inalcanzables desde la puerta de enlace, pero principalmente (¿solo?) Después de reiniciar deCONZ. No creo que el FYRTUR ni el controlador de cortina se hayan perdido durante las últimas tres semanas.

Tenga en cuenta que cambié el complemento REST para solicitar APS ack para todas las solicitudes.

Tengo APS Acks habilitado en la _Configuración de red_ en la GUI, pero no estoy seguro de si esto se aplica solo a los mensajes enviados por la GUI, o también al complemento REST API.

Si desea ejecutar con la solicitud de extracción anterior, también puede verificar mi bifurcación y compilar eso: djwlindenaar / deconz-rest-plugin

@ebaauw , por lo que puedo decir, esto solo se aplica a los comandos enviados desde la GUI

Tengo un rastreador funcionando continuamente y no la hora del reloj de pared cuando ocurre un problema. Por lo general, con esa información puedo encontrar los paquetes con bastante facilidad ...

Por cierto, he cambiado muchas de mis reglas (especialmente las que se activan con frecuencia) a unidifusión. Hasta ahora eso funciona muy bien. También he estado ejecutando una luz IKEA que cambia continuamente el brillo (cada 4 segundos aproximadamente) durante las últimas 2 semanas. Ese también está bien.

bueno ... acabo de notar algo raro en mis registros. Descubrí que ninguna de las luces que apagué y apagué reportaría sus atributos. Pensé que estaba en otro error, pero no lo estaba, aunque de alguna manera creo que podríamos considerar esto como un error de todos modos.

Como mencioné, tenía un script en ejecución para cambiar el nivel de una luz cada dos segundos. Pensando que esto puede estar acelerando los problemas con las luces de IKEA. Resulta que esto restablece el contador d->idleLastActivity , lo que evita que se ejecuten las tareas inactivas. Incluida la configuración del informe de atributos: rofl:

¿Estás diciendo que las luces IKEA pierden sus enlaces y la configuración de informes de atributos después de un ciclo de energía?

Parece que ... ¿No deberían ...?

Mi problema ahora es que, desde que actualicé mi configuración a .75 y 50500, mi contenedor Docker pierde el Conbee al menos una vez a la semana. El reinicio del contenedor hace que las cosas vuelvan a funcionar ... MUY molesto

@djwlindenaar , no, no creo que deban hacerlo. La mayoría de los dispositivos que he visto mantienen estas configuraciones en la memoria no volátil. Supongo que el estándar de ZigBee deja espacio para cualquier comportamiento.

Si bien mis bombillas IKEA funcionan mucho mejor ahora, desafortunadamente, uno de mis sensores Xiaomi (sensor de temperatura redondo) no responde después de un tiempo. Intentaré reunir algunas pruebas olfateando en los próximos días.

Estoy ejecutando Conbee 1, con FW 26350500 y Deconz 2.05.75.
Esta es mi experiencia las ultimas semanas

• Funciona mejor pero no al 100%
• Algunas de mis bombillas IKEA E27 TRÅDFRI E27 WS opal 980lm con fw 2.3.007 a veces no responden a los comandos de apagado
• Puedo intentar apagarlos nuevamente y generalmente funciona (no es necesario apagar y encender)

@tubalainen Hola, noté el comportamiento diferente de ikea con firmware 2.3.x en comparación con 1.2.x también. Traté de abordarlo pero no obtuve atención. Bajé mis bombillas a 1.2.xy ahora funciona como un encanto. En 2.3.x. No se puede apagar después de recuperar una escena durante un período de tiempo. Normal encendido apagado trabajado. Comportamiento extraño. Quizás quieras probar y contribuir aquí. salud https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2518

¿Estás diciendo que las luces IKEA pierden sus enlaces y la configuración de informes de atributos después de un ciclo de energía?

Desafortunadamente, pierden sus ataduras después de un ciclo de energía, el código se adaptó hace un tiempo para abordar eso. Los enlaces y la configuración se restaurarán después de apagar y encender una luz, también si no se reciben informes durante un tiempo, el proceso se activará para restaurarlos.

@realwax se degradará a 1.2.x en todas mis bombillas E27 e informará. (toma algo de tiempo :)).

Ayer, dos luces E27 (con 2.3x FW) no se apagaron durante la secuencia de la mañana.

@tubalainen ¿usa comandos de grupo o comandos de unidifusión? (es decir, a través de la API REST, establezca el estado a través de / groups / o / lights /)

Creo que mientras las luces estén accesibles, los comandos de unidifusión son más confiables. Si un comando de transmisión de grupo se pierde de alguna manera, no se vuelve a intentar. Los comandos de unidifusión se reintentan varias veces o hasta que se entregan.

@tubalainen ¿usa comandos de grupo o comandos de unidifusión? (es decir, a través de la API REST, establezca el estado a través de / groups / o / lights /)

Creo que mientras las luces estén accesibles, los comandos de unidifusión son más confiables. Si un comando de transmisión de grupo se pierde de alguna manera, no se vuelve a intentar. Los comandos de unidifusión se reintentan varias veces o hasta que se entregan.

Utilizo Home Assistant y la API RESt. No sé lo que hace Home Assistant ...

En mi caso es iobroker con deconz plug in y Phoscon ... Así que rest API. Los problemas aparecen al usar igroups. Una recuperación de escena de grupo desencadena que el grupo no se puede apagar, ni cambiar rápidamente a otros ajustes de escena de grupo o ser apagado correctamente, especialmente dentro de los 15 segundos posteriores a la recuperación de escena. Parece que deconz está ocupado con el comando antes, o las bombillas 2.3.x fw se congelan (lo cual dudo). Todavía no se pueden depurar en el nivel de zigbee para obtener una mejor comprensión. ¿La función de agrupación de deconz es una capa virtual que se traduce en comandos uni cast o se realiza mediante las opciones de agrupación disponibles en la interfaz gráfica de usuario / zigbee? En pocas palabras, uso la función de grupo incorporada, de lo contrario, necesitaría construir esta capa virtual en iobroker y no hay ninguna razón, ya que la función de agrupación es buena. Entonces, si es la agrupación ... ¿Cuál es la diferencia, ya que parece 100% con fw 1.2.xy no con 2.3.x. ¿Qué cambió? ¿Es Zigbee 2 por qué se comportan de manera diferente?

@tubalainen Sí, eso es mucho trabajo, ya que es posible que deba reiniciar de vez en cuando o acercar algunas bombillas. Lo hice dos veces con 20 e14 tradfri. Debería ver una gran mejora. ¿Observa que sus bombillas con 2.3..x no se encienden suavemente? (fade in) más y 1.2.x hacer?

PERO los dedos cruzados para que más personas puedan reproducirlo, por lo que ikeas fw 2.3.x estará operativo en deconz, ya que habrá un momento en el que debemos actualizar. O reemplace las bombillas. Aunque zigbee 2 también estaría bien.

¡Gracias por todos tus esfuerzos!

@realwax @djwlindenaar @manup

Anoche una luz no se apagó como debería (IKEA E27 con fw 2.3.x). Probé para cambiar el brillo en esa luz que no se apagaba y cambió instantáneamente a la configuración de brillo que elegí. Momentos después de cambiar el brillo, la luz de repente respondió bien también al comando de apagado.

Personalmente, ahora he cambiado todas mis automatizaciones en Home Assistant para cambiar primero el brillo, esperar 2 segundos y luego enviar el comando de apagado.

Hasta ahora 100% de tasa de éxito.

Espero que esto pueda ser una pista para la investigación.

EDITAR: Siempre son las luces las que están más lejos de la coordinación (el palo de Conbee) las que no se apagan. (luces que debido a la naturaleza de la banda de frecuencia tiene que engranar)

¡Hey gente!

Solo quería lanzar mis problemas ...
Después de tener problemas de estabilidad con mi dispositivo ConBee II, verifiqué la versión del firmware. Era 26530700. Luego bajé a 264a0700, y después de eso, ninguna aplicación puede ver el dispositivo. He probado HomeAssistant y deCONZ. El sistema operativo del host identifica el stick OK y funciona GCFFlasher.

¡Hey gente!

Solo quería lanzar mis problemas ...
Después de tener problemas de estabilidad con mi dispositivo ConBee II, verifiqué la versión del firmware. Era 26530700. Luego bajé a 264a0700, y después de eso, ninguna aplicación puede ver el dispositivo. He probado HomeAssistant y deCONZ. El sistema operativo del host identifica el stick OK y funciona GCFFlasher.

Después de rebajar a 26490700 todo parece estar funcionando de nuevo ... Malla Zigbee estable durante 24 horas ahora ...

¿Alguna actualización? Tengo muchas ganas de cambiar toda mi casa a mi Conbee II, pero en este momento es muy inestable. Mi tono funciona perfectamente, Conbee ii no tanto 🥺

Mi experiencia con el último deCONZ .75 con RaspBee FW 0x26350500 es muy buena hasta ahora.

Mis dispositivos:
Lámparas 4xTradfri 980lu WS - FW 2.3.007
Lámparas 17xTradfri 1000lu WS - FW 2.0.023
Enchufes 3xTradfri - FW 2.0.022
3xTradfri Round Remotos E1810 - FW 2.3.014
4 sensores THP Aqara

Encontré otro que bloquea el firmware de la bombilla IKEA. (y creo que se puede arreglar en deConz)

Vi una luz que no respondía esta mañana. La última comunicación se muestra a continuación.

Parece que deConz recibe la Respuesta de Membresía de Grupo, pero de alguna manera el APS ACK (reconociendo la Solicitud de Membresía de Grupo de Obtener) enviado por la luz no es recibido por deConz (tampoco veo un MAC ACK). Como resultado, deConz reenvía la solicitud. Esta solicitud tiene el mismo número en la ZCL, lo que bloquea el firmware de la luz.

Supongo que deConz podría considerar la solicitud reconocida tan pronto como llegue la Respuesta correspondiente y evitar poner otra solicitud. ¿Correcto? ¿Existe una API para el complemento a la que se pueda llamar para cancelar una solicitud? @¿ser valiente?

Tenga en cuenta que este error específico también se soluciona al no solicitar el APS ACK para estas solicitudes, que es el predeterminado en el complemento de API REST actual.

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

Ejecutando v2.05.75 con 0x26350500 durante un par de semanas. Parece un poco más estable que las versiones anteriores, pero ocasionalmente sigo perdiendo la ruta hacia mis TRV Eurotronic Spirit, mi persiana Fyrtur y mi controlador de cortina Xiaomi lumi.curtain . Este último es un enrutador; los otros son dispositivos finales. Todos los TRV tienen la misma versión de hardware / firmware, pero algunos pasan MIA con más frecuencia que otros. Los síntomas son consistentes: el dispositivo continúa enviando informes al coordinador, pero los comandos del coordinador solo dan como resultado una _Route Request_ sin respuesta.

Actualmente rastreando y analizando el tráfico del TRV que se pierde con mayor frecuencia. Los informes llegan al coordinador en tres saltos, utilizando dos luces Hue en el camino. También capturé un _Data Request_ del TRV a la primera luz en ruta, por lo que el TRV parece feliz de que este sea su padre. Las solicitudes de descriptor de coincidencia del TRV para el clúster OTAU no reciben respuesta. El padre informa la siguiente luz en su _Link Status_, pero no el TRV (¿porque es un dispositivo final?).

Los mensajes _Link Quality Response_ muestran una tabla vecina de 20 entradas, pero el TRV no se encuentra entre ellos. Un sensor de puerta Xiaomi (que se ha mantenido estable desde siempre) lo es. Curiosamente también lo es el coordinador, pero el informe del TRV al coordinador se transmitió a través de otro enrutador (que también está en la tabla de vecinos).
Bien, ahora el coordinador también está incluido en el _Link Status_ y el próximo informe de la TRV se envía directamente al coordinador.

Apagó y apagó el TRV. El TRV envía una MAC _Data Request_ al (anterior) padre; el enrutador responde con un _Rejoin Response_ pasando la antigua dirección NWK del TRV como nueva dirección. El TRV luego transmite el _Device Announcement_ (unidifusión MAC al padre; el padre reenvía como una transmisión MAC). El TRV envía una _Solicitud de tiempo de espera del dispositivo final_ al padre; el padre envía un _Dispositivo de actualización_ al coordinador informándole que el TRV se ha reincorporado de forma segura. El padre ahora también envía una _Route Reply_ a la _Route Request_ del coordinador. En la siguiente secuencia _Link Quality Response_, se incluye el TRV.

Mantendré el rastreador en funcionamiento, con suerte para captar el momento en que el TRV se pierde nuevamente.

En una nota posiblemente relacionada: uno de mis enchufes inteligentes innr SP120 todavía cree que es el padre del botón Hue, al que me uní brevemente a mi red de producción mientras agregaba soporte. Desde entonces, el botón se ha unido a mi red de prueba durante un par de semanas, y he encendido y apagado el enchufe varias veces. ¿Necesito restablecer de fábrica el enchufe para que se olvide del niño perdido?

@manup , mucho tiempo desde cualquier actualización tanto en el código como en la información sobre lo que está sucediendo. ¿Podría darnos una actualización sobre el progreso de su equipo en los problemas de estabilidad y, si se atreve, también un cronograma esperado?

Encontré otro problema en el comportamiento de enrutamiento de deConz.

En este caso, deConz intenta enrutar el mensaje a Hal lamp través de Tuin linksvoor 3 . Pero mirando el informe Link Status de Tuin linksvoor 3 no se sabe acerca de Hal lamp . Y al parecer tampoco sabe cómo llegar a él a través del enrutamiento. Por supuesto, esa luz (IKEA) debería comportarse y responder con un mensaje de falla, pero no es así y no podemos cambiar eso.
Sin embargo, deConz concluye que el Hal lamp es un zombi sin ningún intento de encontrar una nueva ruta hacia esa luz. No estoy seguro de cómo interactúa eso con el (nuevo) código de enrutamiento, pero de alguna manera no degradó esa ruta lo suficientemente rápido como para evitar que se marque como zombi. (Por cierto, realmente no lo es, mira a continuación ...)

Esto provocó un problema temporal que se resolvió solo después de unos minutos (que por supuesto es completamente inaceptable). Porque el Hal lamp decide enviar un informe de atributo, para el cual no recibe un APS ACK y por lo tanto inicia un proceso Route Request . Solo ahora, después de que esto se haya completado, deConz cambia su ruta a Hal lamp y la comunicación se reanuda normalmente.

Me pregunto cuánto tiempo habría tardado si la luz no hubiera decidido enviar un mensaje a deConz. (Tenga en cuenta que en mi red estoy ejecutando las luces IKEA con informes de atributos regulares para clústeres de encendido / apagado y nivel 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

Tu descripción suena como lo que experimento. Tengo una red mucho mejor (conbee 1) con el último fw. Pero aún así, las bombillas no responden y después de un tiempo vuelven a responder.
No ejecuto ningún comando o configuración extra ordinaria que los que proporciona Home Assistant y mi horario habitual para la bombilla. Aunque, las bombillas interiores cambian durante el día (encendido / apagado o brillo) donde mis bombillas exteriores solo cambian la hora de los árboles en un día. A veces, las bombillas que no responden se recuperan bastante rápido y, si emito un comando, responde. Rara vez, pero sucede, lleva mucho más tiempo o tengo que apagar y encender.

@djwlindenaar gran trabajo de nuevo. ¡Muchas gracias! ¿Estás compartiendo tus hallazgos de errores en IKEA FW con IKEA?

@djwlindenaar :

Por supuesto, esa luz (IKEA) debería comportarse y responder con un mensaje de falla, pero no es así y no podemos cambiar eso.

Bueno, no lo he hecho. Tal vez @manup pueda comentar sobre la tasa de éxito de hacer esto, ya que creo que ha intentado ponerse en contacto con IKEA.
Además, no estoy usando su último firmware.

Tal vez contactar a los laboratorios de silicio sea una mejor idea, ya que en eso se basa el material de IKEA. No estoy seguro si los errores provienen del código Ember o de la personalización de IKEA ...

@djwlindenaar También puede intentar comunicarse a través de reddit: https://www.reddit.com/user/TRADFRI Son bastante activos allí.

@manup ¿ Alguna novedad para el firmware de Conbee II?

después de volver a degradar el firmware a 0x264a0700 ya no puedo conectarme a Conbee II. Intenté degradar a 0x264a0700 y algunos firmwares realmente antiguos también, el flasheo funciona bien pero no se puede conectar. ¿Algún consejo sobre cómo reiniciar el stick Conbee II?

@manup alguna actualización? ¿Debo buscar algo más que deConz o se está trabajando para resolver los problemas? Por favor da una señal de vida 🤗

Solo deseo que mi Conbee II vuelva a funcionar después de probar el firmware de prueba ...

@djwlindenaar ¿ Alguna actualización de su lado? ¿Sigues siendo una red estable con tus arreglos?

Es bueno ver que su PR se fusionó con @manup :)

@djwlindenaar ¿ Alguna actualización de su lado? ¿Sigues siendo una red estable con tus arreglos?

Es bueno ver que su PR se fusionó con @manup :)

@ JBS5 Estoy medianamente satisfecho con la situación.

Claramente ha mejorado para mi red. Sin embargo, todavía veo los errores en las luces de IKEA que confunden a deCONZ a veces.

El punto clave es que, a veces, un enrutador IKEA suelta paquetes en silencio para una ruta determinada. Esta caída silenciosa es ilegal, pero deCONZ debería reaccionar encontrando una nueva ruta y no lo hace.

Parece que los cambios en el firmware deCONZ mejoran la situación, pero todavía hay algo que agregar para estas situaciones. Por supuesto, la ausencia de un APS ACK debería desencadenar inmediatamente una nueva búsqueda de ruta.

Tenga en cuenta que @manup mencionó que el enrutamiento de origen podría resolver el problema y creo que esto es especialmente cierto en este caso, ya que significa que no dependemos de que los enrutadores de la red sepan cómo enrutar a un nodo remoto.

Creo que el error en las luces de IKEA es el resultado de que alguna tabla no puede contener todas las rutas a los nodos remotos. Por lo tanto, descarta silenciosamente cualquier paquete para el que no conoce la ruta.

Gracias @djwlindenaar.
Como hace un tiempo que @manup comentó aquí, ¿tiene alguna pista si el enrutamiento de origen mencionado es algo que se implementará?

Este es un cambio que debe ocurrir en el firmware. No estoy afiliado a deCONZ, por lo que no puedo comentar sobre la probabilidad ...

@manup ?

Me está haciendo pensar en dejar deCONZ para mi red doméstica ...

@djwlindenaar , ¿qué alternativas estás considerando? Actualmente no estoy impresionado con la estabilidad de mi Conbee II.

Este es un cambio que debe ocurrir en el firmware. No estoy afiliado a deCONZ, por lo que no puedo comentar sobre la probabilidad ...

@manup ?

Me está haciendo pensar en dejar deCONZ para mi red doméstica ...

¿Zigbee2MQTT hace esto mejor o no quiso decir eso con la alternativa?

Si. Eso es.

De hecho, no sé si eso hace un mejor trabajo. Tenga en cuenta que los firmwares utilizados allí los proporcionan los fabricantes de chips. Esos firmwares no son de código abierto. Entonces, si tienen un problema de firmware, probablemente te quedes con menos soporte que deCONZ ...
Por otro lado, la configuración de estos firmwares es de código abierto. También son compatibles con el enrutamiento de origen.

El fabricante de chips solo proporciona SDK, si lo desea, puede descargar SDK, la versión de prueba de simplicity studio y compilar el firmware usted mismo. Z2M proporciona parches de cambios que hicieron al firmware.

Hola juntos,

Disculpas por haber tardado tanto, aquí está el nuevo firmware para ConBee II que ha portado todas las correcciones de enrutamiento del firmware AVR 0x26350500. Además, ha mejorado el inicio para evitar que el dispositivo se quede en silencio. (Todavía estamos probando varios casos para solucionar el problema de arranque para siempre).

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

Esta versión probablemente será parte de la próxima versión deCONZ 2.05.76, el firmware ConBee I y RaspBee I versión 0x26350500 se instalará mediante el botón de actualización.

Gracias, @manup. Instalé esta versión en mi red de prueba y parece funcionar. Se pueden controlar al menos dispositivos, a diferencia de los de 52 y 53. La red de prueba es demasiado pequeña para comprobar si esta versión mejora el enrutamiento.

@manup deCONZ todavía no se conecta a ConBee II, incluso después de actualizar el nuevo firmware. Tuve este problema por un tiempo.

@manup Intenté flashearlo varias veces, pero sigo recibiendo este error:

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.

¿Es este GCFFlasher 3.13?

Aquí está el registro de mi actualización:

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

Sí, fue 3.13, funciona ahora que reinicié el sistema completo. Extraño, solo volver a conectar el ConBee II no funcionó, pero reiniciar sí ...

De hecho, es extraño, la verificación de CRC se realiza directamente en el dispositivo, me pregunto cómo puede suceder esto.

@manup Incluso intenté actualizar el firmware antiguo (múltiples versiones) y 9600 baudios. Todos resultaron en el mismo error CRC.

Feliz de que funcione ahora, ¡gracias! Ya vi un dispositivo problemático que se unió a la red de inmediato. Así que espero que este firmware solucione algunos problemas :)

Me alegro de que funcione ahora. Acabo de hablar con las universidades sobre el gestor de arranque. La versión 2.05 fue del primer lote de ConBee II en 2019 (alrededor de 3500 unidades), esta versión es un poco tosca en algunos casos. Desde julio de 2019, enviamos 2.07 con algunas correcciones al manejo del perro guardián.

Hay un nuevo gestor de arranque 3.x en desarrollo que ya es parte de RaspBee II, tiene un diseño y un protocolo mucho más robustos para solucionar los problemas de la versión 2.x.

Actualmente no actualizamos el cargador de arranque ConBee II con GCFFlasher. No lo hemos implementado ya que existe una posibilidad sutil de bloquear el dispositivo si la actualización del cargador de arranque se cancela en el momento en que se modifica la tabla de vectores de inicio. Pero creo que podemos resolver esto usando el manejador de fallas duras ARM. La idea es que si la actualización del cargador de arranque falla y se activa el controlador de fallas, puede verificar si el cargador de arranque es válido y si falla, saltará a la aplicación, donde la actualización del cargador de arranque se puede intentar nuevamente. Hemos realizado algunas pruebas con el controlador de fallas duras que parecen prometedoras, pero llevará algún tiempo hasta que esté listo para su lanzamiento público.

Hola

Actualicé con el nuevo firmware hoy, pero sigo viendo registros como:

0x000D6FFFFE540E7C error APSDE-DATA.confirm: 0xA7 en la tarea

¿Está esto relacionado?

0xA7 indica que no se ha proporcionado un APS ACK donde debería haber estado. Supongo que eso podría deberse a varias razones.

Hola @manup , me tuyas nuevamente. ¿Tiene también algo de tiempo para discutir más a fondo los problemas de enrutamiento restantes? ¿Y con suerte resolverlos?

Hola de nuevo,

Todavía tengo problemas en los que algunas luces no reaccionan a los comandos (encendido / apagado / tenue), y realmente no tengo idea de por qué, pensé que tenía algo que ver con este problema, pero ahora no estoy seguro de si es así.

Sigo recibiendo muchos errores como el que publiqué hace 4 días.

recuento de código
0xA7 29
0xAE 31
0xD0 1
0xE1 1
0xE9 14
total 76

Tengo 26 dispositivos que publican estos errores HOY, parece que ha empeorado un poco con 0x26580700

¿Alguien puede decirme si esto está relacionado con este problema de enrutamiento? o debería abrir un problema con mi problema

Tenga en cuenta que parece que solo sucede cuando se envía fx. "encendido" a ~ 20 luces "al mismo tiempo"

Hola @manup , me tuyas nuevamente. ¿Tiene también algo de tiempo para discutir más a fondo los problemas de enrutamiento restantes? ¿Y con suerte resolverlos?

Hola @djwlindenaar, sí, absolutamente, necesito ponerme al día con los comentarios en este número durante la semana. Si mi memoria no me sirve bien, ya había más ideas para mejorar los problemas restantes.

Hola @djwlindenaar, sí, absolutamente, necesito ponerme al día con los comentarios en este número durante la semana. Si mi memoria no me sirve bien, ya había más ideas para mejorar los problemas restantes.

@manup , claro, creo que la cuestión clave sigue siendo que deCONZ sigue siendo terco en retener una ruta que no funciona.
Creo que siguen llegando mensajes tanto del mal comportamiento como de la luz afectada (a través de alguna otra ruta) y el firmware lo malinterpreta como si la ruta que no funciona todavía funciona. Además, deCONZ tiende a renunciar a las solicitudes de la capa APS con bastante rapidez si no se recibe ningún ACK. Creo que debería ser más persistente y / o iniciar un descubrimiento de ruta como parte del proceso de reintento.

Por último, ahora estoy convencido de que el enrutamiento de origen eliminaría el problema principal del mal funcionamiento de los enrutadores. Entonces, si pudieras implementar eso, estaríamos en un lugar mucho mejor. Estoy listo para ayudar / probar / depurar ...

Hola @manup , me tuyas nuevamente. ¿Tiene también algo de tiempo para discutir más a fondo los problemas de enrutamiento restantes? ¿Y con suerte resolverlos?

Hola @djwlindenaar, sí, absolutamente, necesito ponerme al día con los comentarios en este número durante la semana. Si mi memoria no me sirve bien, ya había más ideas para mejorar los problemas restantes.

Hola Manup, es posible que esté secuestrando este hilo, así que si es así, ignórelo. Tengo un Conbee ii en Home Assistant y funcionaba muy bien hasta hace aproximadamente un mes. En ese momento, todos mis sensores Xiaomi se convertirían en automatizaciones de ruptura poco confiables. Tengo algunos controladores dresden fls-pp que he tenido durante un par de años. Estos están conectados a tiras de LED y se utilizan para desconectarse esporádicamente de la red, lo que obliga a reiniciar para volver a encenderlos. Finalmente los eliminé todos de mi red Conbee e inmediatamente toda la red quedó estable. Lo dejé unos días y luego volví a introducir uno que funcionó durante unas horas y, durante la noche, mi red Zigbee falló y no pude volver a conectar todos mis interruptores / sensores hasta que apagué el controlador de Dresden. No tengo idea de por qué, pero para mí, usar los controladores de dresden ahora rompe mi red zigbee. Solo soy un novato en esto, así que no estoy seguro de si esto es útil / relevante, pero estaba buscando comentarios sobre esto y me encontré con este hilo, así que pensé en poner mi experiencia en la mezcla por si acaso. Por ahora solo los estoy eliminando de mi red, ¡no vale la pena el dolor de cabeza que me estaban dando!
Salud

Hola @djwlindenaar, sí, absolutamente, necesito ponerme al día con los comentarios en este número durante la semana. Si mi memoria no me sirve bien, ya había más ideas para mejorar los problemas restantes.

@manup , claro, creo que la cuestión clave sigue siendo que deCONZ sigue siendo terco en retener una ruta que no funciona.
Creo que siguen llegando mensajes tanto del mal comportamiento como de la luz afectada (a través de alguna otra ruta) y el firmware lo malinterpreta como si la ruta que no funciona todavía funciona. Además, deCONZ tiende a renunciar a las solicitudes de la capa APS con bastante rapidez si no se recibe ningún ACK. Creo que debería ser más persistente y / o iniciar un descubrimiento de ruta como parte del proceso de reintento.

Por último, ahora estoy convencido de que el enrutamiento de origen eliminaría el problema principal del mal funcionamiento de los enrutadores. Entonces, si pudieras implementar eso, estaríamos en un lugar mucho mejor. Estoy listo para ayudar / probar / depurar ...

He decidido cambiar a zigbee2mqtt debido a los problemas de enrutamiento (lo más molesto es la necesidad de volver a emparejar Ikea / Xiaomi de vez en cuando). Publicaré mis hallazgos aquí en algunas semanas ...

Después de actualizar el firmware 0x26350500 en mi Conbee I (y actualizar deCONZ a 2.05.76) el lunes pasado, desafortunadamente un GU10 se desconectó.

En VNC es un poco gris:

Foscón:

¿Es necesario apagar y encender todas las luces antes de que aprovechen la corrección de enrutamiento en la nueva versión de firmware?

@ JBS5 , no creo que sea necesario
Probablemente se deba al hecho de que, aunque mejorado, no estamos completamente libres de problemas de enrutamiento; ver mis publicaciones anteriores.

@djwlindenaar Gracias. Entiendo.

Por lo que vale, porque tiene el mismo comportamiento que con el firmware anterior:

Después de que el GU10 se marcó como no disponible, todavía respondía a los comandos del grupo. Después de unos días, 2 dispositivos alimentados por batería (sensor de movimiento Aqara y detector de humo Xiaomi / Honeywell) también se desconectaron. El GU10 seguía respondiendo a los comandos de grupo.

Después de apagar y encender el GU10, también los 2 dispositivos alimentados por batería volvieron a estar en línea de inmediato.
Entonces, después de que el GU10 se desconectó, pasaron unos días hasta que un dispositivo con batería que usaba el GU10 específico como enrutador se desconectara.

@ JBS5 , sí, eso suena como un comportamiento típico. En realidad, no hay nada de malo en esa luz GU10. Es solo que deCONZ perdió la forma de comunicarse directamente con él. Después de un tiempo, esto también hace que sus dispositivos finales se desconecten, ya que tampoco reciben ningún comentario de deCONZ. Finalmente, cuando el GU10 se queda lo suficientemente hambriento de paquetes de red, se desconecta de verdad.

Probablemente en la fase en la que todavía está respondiendo a los comandos del grupo, podrá apagar y encender otro enrutador, lo que aparentemente está bien, y el GU10 se recuperará. Ese otro enrutador en realidad no está funcionando bien y deCONZ no está respondiendo bien a la situación.
Así que no te enojes con el GU10;)

Hola @djwlindenaar, sí, absolutamente, necesito ponerme al día con los comentarios en este número durante la semana. Si mi memoria no me sirve bien, ya había más ideas para mejorar los problemas restantes.

@manup , claro, creo que la cuestión clave sigue siendo que deCONZ sigue siendo terco en retener una ruta que no funciona.

Hmm, las rutas deberían degradarse y descartarse después de varias transmisiones fallidas. El último firmware se degradará cada vez que se informe un error en el APS-DATA.confirm (como un error de enrutamiento o no se recibió APS-ACK).

Creo que siguen llegando mensajes tanto del mal comportamiento como de la luz afectada (a través de alguna otra ruta) y el firmware lo malinterpreta como si la ruta que no funciona todavía funciona.

Esa es una muy buena pista, lo comprobaré. explicaría por qué las rutas no morirán. Creo que la única forma sensata de valorar una ruta debería basarse en transmisiones exitosas.

Además, deCONZ tiende a renunciar a las solicitudes de la capa APS con bastante rapidez si no se recibe ningún ACK. Creo que debería ser más persistente y / o iniciar un descubrimiento de ruta como parte del proceso de reintento.

deCONZ no hace ningún descubrimiento de ruta, todo esto es manejado por la pila Zigbee. Podemos extender la REST-API para hacer reintentos para algunos comandos (como los comandos de control), pero este es un problema.

La pila en sí podría configurarse para realizar múltiples reintentos APS hasta que se rinda. Pero esto puede estropear muchas cosas y bloquear la cola durante mucho tiempo. Creo que es mejor considerarlo más detallado en la REST-API.

Por último, ahora estoy convencido de que el enrutamiento de origen eliminaría el problema principal del mal funcionamiento de los enrutadores. Entonces, si pudieras implementar eso, estaríamos en un lugar mucho mejor. Estoy listo para ayudar / probar / depurar ...

En teoría, el enrutamiento de origen es el santo grial para arreglarlo todo :)

Pero en el mundo real, muchas puertas de enlace no lo usan (¿alguna?), Lo que significa que la mayoría de los productos no admiten el enrutamiento de origen o no se probaron con él. En mi humilde opinión, las posibilidades de que funcione en redes mixtas son muy bajas. Pero ha pasado un tiempo desde que comparé varias puertas de enlace en ese nivel. Sería interesante tener una visión general actual sobre qué pasarelas utilizan qué enfoque de enrutamiento en la actualidad.

Sería interesante tener una visión general actual sobre qué pasarelas utilizan qué enfoque de enrutamiento en la actualidad.

Me complace ayudar a probar / detectar el puente Hue (gen 2 y gen 1), innr gateway, IKEA hub y OSRAM Lightly Home gateway, pero necesito información sobre qué configuración de prueba usar (cuántos enrutadores, dispositivos finales, distancias entre ellos , ...) y qué buscar.

Z-Stack FW es un ejemplo de FW que ofrece / usa enrutamiento de origen y lo recomienda para redes más grandes. Pero también he visto algunos comentarios de que no funciona muy bien con el CC2351 más débil.

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

Además, deCONZ tiende a renunciar a las solicitudes de la capa APS con bastante rapidez si no se recibe ningún ACK. Creo que debería ser más persistente y / o iniciar un descubrimiento de ruta como parte del proceso de reintento.

deCONZ no hace ningún descubrimiento de ruta, todo esto es manejado por la pila Zigbee. Podemos extender la REST-API para hacer reintentos para algunos comandos (como los comandos de control), pero este es un problema.

La pila en sí podría configurarse para realizar múltiples reintentos APS hasta que se rinda. Pero esto puede estropear muchas cosas y bloquear la cola durante mucho tiempo. Creo que es mejor considerarlo más detallado en la REST-API.

La pila hace algunos reintentos, recuerdo que lo intenta tres veces, si no me equivoco. Me parece que podría agregar un comportamiento en ese fragmento de código para invalidar la ruta asociada y volver a intentarlo una o dos veces. O tal vez pueda tener una devolución de llamada dentro de la pila para implementar ese comportamiento. Eso debería provocar un descubrimiento de ruta, ¿verdad?

Por último, ahora estoy convencido de que el enrutamiento de origen eliminaría el problema principal del mal funcionamiento de los enrutadores. Entonces, si pudieras implementar eso, estaríamos en un lugar mucho mejor. Estoy listo para ayudar / probar / depurar ...

En teoría, el enrutamiento de origen es el santo grial para arreglarlo todo :)

Pero en el mundo real, muchas puertas de enlace no lo usan (¿alguna?), Lo que significa que la mayoría de los productos no admiten el enrutamiento de origen o no se probaron con él. En mi humilde opinión, las posibilidades de que funcione en redes mixtas son muy bajas. Pero ha pasado un tiempo desde que comparé varias puertas de enlace en ese nivel. Sería interesante tener una visión general actual sobre qué pasarelas utilizan qué enfoque de enrutamiento en la actualidad.

Para ser honesto, no estoy muy preocupado por este tema. El comportamiento de los enrutadores en caso de enrutamiento de origen es extremadamente simple. Especialmente si lo comparas con el comportamiento requerido para hacer el enrutamiento ellos mismos. Básicamente, lo único que tiene que hacer la capa NWK en un enrutador es verificar si el enrutamiento de origen está habilitado, leer el siguiente salto del paquete y devolverlo a la capa MAC. Sin mesas, sin memoria, nada que hacer mal. No estoy seguro de si se verifica el comportamiento básico para la certificación zigbee, pero seguro que es mucho más simple y hay muchas menos posibilidades de errores que el enrutamiento normal.

Mi expectativa es que pocos coordinadores lo implementen, porque la complejidad está en el firmware del coordinador. Además, muy pocas implementaciones de zigbee (de consumo) se centran realmente en las redes más grandes que se beneficiarían de este modo de enrutamiento.

Finalmente, diría que este es el mejor modo de enrutamiento para redes mixtas, porque el enrutamiento normal depende de las implementaciones individuales de los enrutadores y especialmente de las indicaciones de calidad del enlace mal especificadas. Dado que el enrutamiento de origen es tan simple (= pocas posibilidades de malas implementaciones), confiaría en eso antes del comportamiento de enrutamiento normal.

Entonces ... habiendo dicho esto, estoy listo para probarlo por usted si pudiera proporcionar un firmware. Estoy en un raspbee, mi sniffer está listo para funcionar.

Finalmente, diría que este es el mejor modo de enrutamiento para redes mixtas, porque el enrutamiento normal depende de las implementaciones individuales de los enrutadores y especialmente de las indicaciones de calidad del enlace mal especificadas. Dado que el enrutamiento de origen es tan simple (= pocas posibilidades de malas implementaciones), confiaría en eso antes del comportamiento de enrutamiento normal.

KISS - tiene mucho sentido para mí.

La pila hace algunos reintentos, recuerdo que lo intenta tres veces, si no me equivoco. Me parece que podría agregar un comportamiento en ese fragmento de código para invalidar la ruta asociada y volver a intentarlo una o dos veces. O tal vez pueda tener una devolución de llamada dentro de la pila para implementar ese comportamiento. Eso debería provocar un descubrimiento de ruta, ¿verdad?

Si entiendo correctamente el código que ya está sucediendo, el problema es que las rutas parecen mantenerse vivas debido a otros factores (bajo investigación).

Para ser honesto, no estoy muy preocupado por este tema. El comportamiento de los enrutadores en caso de enrutamiento de origen es extremadamente simple. Especialmente si lo comparas con el comportamiento requerido para hacer el enrutamiento ellos mismos. Básicamente, lo único que tiene que hacer la capa NWK en un enrutador es verificar si el enrutamiento de origen está habilitado, leer el siguiente salto del paquete y devolverlo a la capa MAC. Sin mesas, sin memoria, nada que hacer mal. No estoy seguro de si se verifica el comportamiento básico para la certificación zigbee, pero seguro que es mucho más simple y hay muchas menos posibilidades de errores que el enrutamiento normal.

Solo puedo hablar por los productos basados ​​en BitCloud que traje a través de la certificación (balastos FLS). En el proceso de certificación nunca se probaron para el enrutamiento de origen. No estoy seguro de si estaba habilitado en la pila en tiempo de compilación. Tenga en cuenta que la mayoría de las pilas están configuradas para compilarse con las características mínimas necesarias para proteger el espacio.

Mi experiencia personal con características que rara vez se usan / prueban, sin importar cuán simples sean en teoría, es que siempre tienen errores. Por ejemplo, para FLS, tuvimos que corregir toneladas de errores en la aplicación de pila BitCloud de ejemplo. Sé que Philips también hizo muchas mejoras en la pila de BitCloud para algunos de sus productos.

Mi expectativa es que pocos coordinadores lo implementen, porque la complejidad está en el firmware del coordinador. Además, muy pocas implementaciones de zigbee (de consumo) se centran realmente en las redes más grandes que se beneficiarían de este modo de enrutamiento.

La complejidad debe implementarse en el complemento deCONZ REST-API o en un nuevo complemento de enrutador, ya que el firmware no tiene suficiente información sobre toda la topología de la red ni el espacio flash. Para ese propósito, deCONZ::ApsDataRequest podría ampliarse con una opción de ruta de origen en forma de std::vector<quint16> que contenga las direcciones nwk de una ruta.

No tengo una buena descripción general de la complejidad que esto trae, que actualmente se maneja mediante el enrutamiento de malla. Las siguientes tareas deben considerarse como mínimo y a escala:

• Consulta recursiva de topología de red (Mgmt_Lqi_req). Esa es la más fácil, esto ya funciona para el enrutamiento de malla y podría adaptarse a las rutas de origen.
• Los nodos están apagados. Aquí, algo de lógica necesita seleccionar rutas alternativas, que también pueden no funcionar si sus enlaces también están rotos.
• Los nodos se vuelven a encender.
• Nodos que cambian la dirección nwk.
• Dispositivos finales que cambian de padres.
• Los dispositivos finales se unen, en las redes de varios saltos, no conocemos al padre sin consultar la red.

Lo que aún no sabemos:

• ¿Todos los enrutadores admiten el enrutamiento de origen?
• ¿Existen pasarelas comerciales que utilicen enrutamiento de origen? Aquí tenemos que rastrear el tráfico y mirar los encabezados NWK que contienen las rutas de origen y tienen sus respectivos indicadores establecidos.
• Para los dispositivos que admiten el enrutamiento de origen, ¿qué tan bien funciona?

Solo puedo hablar por los productos basados ​​en BitCloud que traje a través de la certificación (balastos FLS). En el proceso de certificación nunca se probaron para el enrutamiento de origen. No estoy seguro de si estaba habilitado en la pila en tiempo de compilación. Tenga en cuenta que la mayoría de las pilas están configuradas para compilarse con las características mínimas necesarias para proteger el espacio.

No estoy familiarizado con cómo funciona esto, pero ¿las pilas también están certificadas de alguna manera?

Mi experiencia personal con características que rara vez se usan / prueban, sin importar cuán simples sean en teoría, es que siempre tienen errores. Por ejemplo, para FLS, tuvimos que corregir toneladas de errores en la aplicación de pila BitCloud de ejemplo. Sé que Philips también hizo muchas mejoras en la pila de BitCloud para algunos de sus productos.

Mi expectativa es que pocos coordinadores lo implementen, porque la complejidad está en el firmware del coordinador. Además, muy pocas implementaciones de zigbee (de consumo) se centran realmente en las redes más grandes que se beneficiarían de este modo de enrutamiento.

La complejidad debe implementarse en el complemento deCONZ REST-API o en un nuevo complemento de enrutador, ya que el firmware no tiene suficiente información sobre toda la topología de la red ni el espacio flash. Para ese propósito, deCONZ::ApsDataRequest podría ampliarse con una opción de ruta de origen en forma de std::vector<quint16> que contenga las direcciones nwk de una ruta.

No entiendo esta declaración. El enrutamiento de origen se maneja completamente a nivel NWK en la pila. La pila de bitcloud debe tener algún indicador de tiempo de compilación (o tiempo de ejecución menos probable) para habilitar el enrutamiento de origen. Hay una tabla de ruta de origen que se mantiene actualizada por la pila, basada en los mensajes de registro de ruta que ya están en nuestra red debido al MTORR enviado por el coordinador cada pocos minutos.

• Básicamente para cada dispositivo en la red, la ruta al coordinador se conoce a través de MTORR
• El coordinador conoce cada ruta (completa) a cada dispositivo a través de los mensajes de registro de ruta. No se necesita ningún análisis, solo una copia del mensaje RR en la tabla de ruta de origen

Consulte el capítulo 3.6.3.5.4 y el capítulo 3.6.3.3 de

No tengo una buena descripción general de la complejidad que esto trae, que actualmente se maneja mediante el enrutamiento de malla. Las siguientes tareas deben considerarse como mínimo y a 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.

Creo que todos estos son manejados por la capa NWK dentro de la pila de bitcloud. Debería ser tan simple como ajustar algunos indicadores de tiempo de compilación (similar a habilitar el comportamiento MTOR)

Lo que aún no sabemos:

* Do all routers support source routing?

Yo lo esperaba, ya que esto es parte de la especificación básica de zigbee de la capa NWK. No puedo estar seguro, pero no vi ningún comentario de que admitir el enrutamiento de origen sea opcional. Es similar al comportamiento de MTOR, que ya usamos en nuestra red.

* 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.

No lo sé, ¿tampoco sabes qué nos dirá eso?

* For the devices which support source routing, how well does it work?

Si pudiera hacer una compilación del firmware con el enrutamiento de origen habilitado, aprenderemos rápidamente. Deberían ser solo unos pocos indicadores de tiempo de compilación para habilitarlo en bitcloud.

Además, Zigbee2MQTT lo tiene habilitado para algunos firmwares de coordinadores y todavía no encontré ningún problema (después de un rápido google) con enrutadores específicos que no funcionan bien con el enrutamiento de origen habilitado.

No estoy familiarizado con cómo funciona esto, pero ¿las pilas también están certificadas de alguna manera?

Sí, pero durante la certificación se habilitan configuraciones específicas que pueden no habilitarse en los productos más adelante.

No entiendo esta declaración. El enrutamiento de origen se maneja completamente a nivel NWK en la pila. La pila de bitcloud debe tener algún indicador de tiempo de compilación (o tiempo de ejecución menos probable) para habilitar el enrutamiento de origen. Hay una tabla de ruta de origen que se mantiene actualizada por la pila, basada en los mensajes de registro de ruta que ya están en nuestra red debido al MTORR enviado por el coordinador cada pocos minutos.

Básicamente para cada dispositivo en la red, la ruta al coordinador se conoce a través de MTORR
El coordinador conoce cada ruta (completa) a cada dispositivo a través de los mensajes de registro de ruta. No se necesita ningún análisis, solo una copia del mensaje RR en la tabla de ruta de origen

Consulte el capítulo 3.6.3.5.4 y el capítulo 3.6.3.3 de especificaciones de zigbee

Ah, tienes razón, tonto de mí. De alguna manera lo malinterpreté con el descubrimiento general de nodos (facepalm).
De hecho, la pila puede descubrir muchos comandos de registro de ruta debido, pero ya me encontré con un caso en el que no se envió ninguno, ver más abajo.

Hoy he probado muchas configuraciones, parece que el enrutamiento de origen funciona, pero solo cuando el enrutamiento en malla está deshabilitado y para dispositivos que envían comandos de registro de ruta antes.

Mi sensor de movimiento Philips Hue causa problemas y envía solicitudes de dirección NWK de transmisión para obtener la dirección NWK de la puerta de enlace. En este caso, no se enviaron cuadros de registro de ruta a un priorato (creo que debido a la transmisión). Dado que el enrutamiento de malla se deshabilitó, la puerta de enlace no inició un descubrimiento de ruta y, por lo tanto, no se estableció la comunicación con el sensor.

Cuando el enrutamiento de malla está habilitado junto al enrutamiento de origen, parece que el enrutamiento de origen ya no se usa, aunque ambos están habilitados.

Necesito hacer más pruebas, creo que el descubrimiento de rutas de malla debe evitarse cuando ya hay entradas de registro de ruta en la memoria caché de ruta. El código es bastante complejo, necesito profundizar aquí.

deCONZ_ConBeeII_0x26600700_many2one.bin.zip

Aquí está el firmware que tiene habilitado el enrutamiento de origen y de malla (tamaño de tabla de registro de ruta de 32). Puede intentarlo, pero como se mencionó en mi enrutamiento de origen de red más pequeño no se activó en esa configuración.

Estoy en raspbee I, así que no puedo probar eso. ¿Podrías crear uno para eso también?
Me pregunto si podríamos solucionar este problema con una especie de ruta estática que podamos cargar en el firmware al inicio o tal vez basándonos en alguna otra información.
Además, ¿reparó este dispositivo después del cambio al enrutamiento de origen? Se pregunta si se necesita alguna interacción para que un dispositivo final reconozca MTOR y el enrutamiento de origen está en uso. Por supuesto, no reciben los mensajes MTOR de transmisión cuando su receptor está apagado.
Por cierto, vi que mis dispositivos finales Xiaomi enviaban el registro de ruta en mi olfateo ...

He dirigido el firmware anterior durante la noche. Parece que el enrutamiento de origen también se usa con el enrutamiento en malla habilitado, pero muy raramente. Desde ca. 2 millones de paquetes solo <5 utilizaron una ruta de origen.

Estoy en raspbee I, así que no puedo probar eso. ¿Podrías crear uno para eso también?

No estoy seguro, necesito verificar la otra configuración de pila utilizada por ConBee I y RaspBee I si es posible.

Me pregunto si podríamos solucionar este problema con una especie de ruta estática que podamos cargar en el firmware al inicio o tal vez basándonos en alguna otra información.

Sí, creo que debería ser posible inyectar rutas en el caché de rutas de alguna manera. Pero cuando volvamos a mis preocupaciones mencionadas anteriormente para mantener las rutas. De todos modos, para propósitos de prueba y redes fijas, proporcionaría una forma útil de configurar el enrutamiento.

Además, ¿reparó este dispositivo después del cambio al enrutamiento de origen? Se pregunta si se necesita alguna interacción para que un dispositivo final reconozca MTOR y el enrutamiento de origen está en uso.

No, acabo de actualizar el firmware, sin reparación: las rutas de origen se establecieron poco después de recibir los comandos de registro de ruta.

Por cierto, vi que mis dispositivos finales Xiaomi enviaban el registro de ruta en mi olfateo ...

IKEA parece encajar aquí también, me gustaría hacer más pruebas con Philips y otros dispositivos de la marca para obtener más detalles sobre cómo se pueden usar varios dispositivos con el enrutamiento de origen.

También podría intervenir para probar si podemos hacer que funcione para Raspbee.

He dirigido el firmware anterior durante la noche. Parece que el enrutamiento de origen también se usa con el enrutamiento en malla habilitado, pero muy raramente. Desde ca. 2 millones de paquetes solo <5 utilizaron una ruta de origen.

¡Interesante! Sería bueno tener una idea de la lógica de la toma de decisiones cuando se usa una ruta de origen y si se puede influenciar / ajustar de alguna manera.

Estoy en raspbee I, así que no puedo probar eso. ¿Podrías crear uno para eso también?

No estoy seguro, necesito verificar la otra configuración de pila utilizada por ConBee I y RaspBee I si es posible.

Sería genial...

Me pregunto si podríamos solucionar este problema con una especie de ruta estática que podamos cargar en el firmware al inicio o tal vez basándonos en alguna otra información.

Sí, creo que debería ser posible inyectar rutas en el caché de rutas de alguna manera. Pero cuando volvamos a mis preocupaciones mencionadas anteriormente para mantener las rutas. De todos modos, para propósitos de prueba y redes fijas, proporcionaría una forma útil de configurar el enrutamiento.

Convenido

Además, ¿reparó este dispositivo después del cambio al enrutamiento de origen? Se pregunta si se necesita alguna interacción para que un dispositivo final reconozca MTOR y el enrutamiento de origen está en uso.

No, acabo de actualizar el firmware, sin reparación: las rutas de origen se establecieron poco después de recibir los comandos de registro de ruta.

Me pregunto si ayudaría para el dispositivo Philips ...

Hola chicos, he estado ejecutando el firmware Z2M Source Routing durante 24 horas (solo permite 5 conexiones directas). Tengo ~ 35 dispositivos. Funciona bien, pero he notado que los dispositivos Hue necesitan un ciclo de energía para volver a conectarse después de que pasé del firmware predeterminado al firmware SR. Ikea y Xiaomi se volvieron a conectar automáticamente. ¿Quizás esto pueda explicar partes del comportamiento de Hue que estás viendo?

Hola,
Volví a probar mi bombilla TRADFRI E14 WS opal 400lm con el firmware de ikea 2.3.050 y la última versión beta de deconz y el firmware más reciente en mi Conbee I. Puedo confirmar que las bombillas y la comunicación han mejorado. La recuperación de escenas, el encendido / apagado, la aparición y desaparición gradual ahora funcionan mejor, pero queda un problema.

Los problemas documentados aquí # 2518 se han resuelto en su mayoría. Parece que los comandos de grupo (fuera de la interfaz gráfica de usuario de phoscon) funcionan aún mejor. # 2518 cerrado

Todavía he notado que el cambio de CT a veces debe activarse más de una vez para tener éxito si se cambia a mano, no a escena.

Un nuevo problema # 2892 que aparece es que si dentro de un grupo se recuerda una escena y se encienden todas las bombillas correspondientes (debido a la escena) y luego otra escena en ese grupo con solo unas pocas bombillas encendidas (definido por escena) Se recuerda, las bombillas "no deseadas" que deben apagarse permanecen encendidas.
Además, si apaga el grupo, solo se apagan las bombillas de escena definidas actualmente y las otras de antes (escena anterior del grupo) permanecen encendidas. Necesitan varios comandos de apagado antes de irse.
El problema se describe aquí, pero está en la API con seguridad, ya que no hace ninguna diferencia si se usa Phoscon o la propia API. https://github.com/dresden-elektronik/phoscon-app-beta/issues/52

nota adicional: utilizando la última versión de ikea fw 2.3.050 el 20.5.2020

Versión de lanzamiento: 1.12.1
20 de mayo de 2020
Nuevas funciones y cambios en Accesorios:
WS 1.0 (E14, E27, GU10) V-2.3.050.
Se corrigió el estado de encendido y apagado después de la actualización de OTA.

Gracias por su mejora continua y el trabajo realizado.

@manup , ¿alguna novedad sobre la versión de firmware de la ruta de origen de conbee I? Estoy deseando probar eso :)

@manup , ¿alguna novedad sobre la versión de firmware de la ruta de origen de conbee I? Estoy deseando probar eso :)

Mi primer intento de habilitarlo terminó en un horrible desastre en el tiempo de compilación: / Aún no he descubierto cuál es la causa y espero que se compile de alguna manera.

@manup , ¿alguna novedad sobre la versión de firmware de la ruta de origen de conbee I? Estoy deseando probar eso :)

Mi primer intento de habilitarlo terminó en un horrible desastre en el tiempo de compilación: / Aún no he descubierto cuál es la causa y espero que se compile de alguna manera.

Hmmmm no suena muy bien ... @manup , me encantaría ayudar, pero no tengo acceso a ese código.

@manup , ¿algún progreso?

@manup , pssst! 😁

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

Sigue pasando. @manup ¿ algún progreso y / o actualización sobre este tema?

@djwlindenaar @ JBS5 Le pedí a @manup una actualización.

Sí, sigue siendo un problema, aunque mucho menos que antes.

¿Qué es lo último sobre el tema?

Tengo alrededor de 20 GU10 de espectro blanco (primera generación) conectados a un puente Hue y, como parte de la racionalización de mi red zigbee, quería migrar todos mis dispositivos a Deconz.

El tono es bastante estable, pero las luces aún se desconectan de vez en cuando (por ejemplo, una vez a la semana una luz se desconecta). Solo necesito reiniciar las bombillas para resucitarlas.

¿Deconz es más o menos estable?

No Deconz no es más estable, también tengo unas 40 lámparas Ikea y algunas veces se desconectan

@salopette No tengo esa experiencia. ¿Le importaría abrir un número aparte? ¿Algún registro?

@Mimiix Este problema se trata de luces que se desconectan. ¿Por qué abrir un nuevo número?

Igual que aquí. Las luces todavía se desconectan de vez en cuando. Pero ha mejorado mucho con el tiempo. Cuando comencé a usar deCONZ en 2018, tuve que apagar y encender mis luces ikea casi a diario. La mayoría de las veces experimento este problema con un panel FLOALT, pero también es la luz más alejada de mi Conbee Stick.

@ JBS5 Porque no sabemos nada sobre la configuración de este usuario. Sin versión, sin registros, sin información sobre la configuración. No estamos en condiciones de determinar si su problema está relacionado con esto.

Agregar comentarios sin ninguna información no ayuda con esto en un caso. Es por eso que quiero problemas separados para que tengamos una mejor visión general.

Una vez le pedí a @manup en privado que investigara esto y lo priorizara.

@djwlindenaar ha estado investigando profundamente. Dudo que inspeccionar la configuración de otro usuario pueda hacer algo sobre un problema que parece existir en general con las luces de ikea. Prefiero concentrarme en la investigación existente que en iniciar otra.

Anuncio general:

Acabo de hablar con @manup en privado sobre esto. Me dijo lo siguiente:

`` Que el firmware recibirá una actualización con respecto a los problemas de enrutamiento, y la nueva red debería ayudar a recrear los problemas (lo que no era posible antes).
Mi plan es que este próximo firmware esté disponible dentro de las próximas 2-3 semanas.

Algunos cambios ya están hechos, pero aún no son públicos.
''

Los mantendré informados.

Anuncio general:

Acabo de hablar con @manup en privado sobre esto. Me dijo lo siguiente:

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.

Los mantendré informados.

3 semanas después, ¿alguna actualización sobre esto?

@ JBS5 Aún no han

Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

@ JBS5 Aún no han

Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)

Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

@lubbertkramer Por favor, sea razonable aquí, el robot rancio era una broma. La única promesa que hizo @Mimiix anteriormente es compartir actualizaciones una vez que algunas estén disponibles, por lo que es perfectamente válido preguntar sobre el estado actual. Ahora para la ETA, no se ha prometido ninguno y tengo entendido que no lo será, ya que esto es un asunto complejo. Como sé manup cuando hablo de cosas desagradables, desafortunadamente no es nada que pueda resolverse en un día, solo se muestra después de un tiempo considerable o desarrolla algunos efectos secundarios imprevistos.

Entonces, en ese sentido, tenga paciencia y deje que los chicos trabajen en eso (por cierto, todavía es tiempo de vacaciones). Cuando se habla del próximo lanzamiento, es en 1,5 semanas para levantar la mano y pedir noticias.

@ JBS5 Aún no han

Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Los problemas de reinicio no están relacionados con este problema, supongo.
¿Qué pasa con los cambios de enrutamiento y las mejoras de depuración mencionadas? ¿Están esas mejoras de depuración relacionadas con este problema?

¿Y esos cambios de enrutamiento se basan en los hallazgos de @djwlindenaar o @manup ya puede ser más específico?

@lubbertkramer Por favor, sea razonable aquí, el robot rancio era una broma. La única promesa que hizo @Mimiix anteriormente es compartir actualizaciones una vez que algunas estén disponibles, por lo que es perfectamente válido preguntar sobre el estado actual. Ahora para la ETA, no se ha prometido ninguno y tengo entendido que no lo será, ya que esto es un asunto complejo. Como sé manup cuando hablo de cosas desagradables, desafortunadamente no es nada que pueda resolverse en un día, solo se muestra después de un tiempo considerable o desarrolla algunos efectos secundarios imprevistos.

Entonces, en ese sentido, tenga paciencia y deje que los chicos trabajen en eso (por cierto, todavía es tiempo de vacaciones). Cuando se habla del próximo lanzamiento, es en 1,5 semanas para levantar la mano y pedir noticias.

Creo que es más razonable hacer que las personas cumplan con las comunicaciones pasadas o las promesas sin hacer "bromas" cuando han pasado de 2 a 3 semanas por 3 semanas sin seguimiento. Los usuarios que han investigado mucho y han respondido aquí ya han avanzado debido a la falta de seguimiento / comunicación.

Entonces, volviendo al tema, ¿cuál es la información más reciente sobre este tema?

@ JBS5 Aún no han

Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)

Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.

Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.

_Sé el cambio que quieres ver en este mundo_

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.

Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.

_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.

Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.
_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.

Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga sus emociones bajo control. Entiendo tu enojo, pero ser irrespetuoso no ayuda. No acepto ninguna flama aquí. Mantenlo en el tema y civilizado. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.

Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no lo hagas en este número.

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.
_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.
Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga sus emociones bajo control. Entiendo tu enojo, pero ser irrespetuoso no ayuda. No acepto ninguna flama aquí. Mantenlo en el tema y civilizado. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.

Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no lo hagas en este número.

La única vergüenza en este tema es manup y, obviamente, Dresde no es capaz de solucionar este problema. Conbee es un producto comercial y eso conlleva responsabilidades. Es por eso que muchos de nosotros ya hemos dejado deCONZ / Conbee por el chip TI y Z2M, que ha estado funcionando a la perfección desde entonces.

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.
_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.
Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga sus emociones bajo control. Entiendo tu enojo, pero ser irrespetuoso no ayuda. No acepto ninguna flama aquí. Mantenlo en el tema y civilizado. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.

Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no lo hagas en este número.

Y nuevamente, no está respondiendo ni actualizando el estado que se le pide muchas veces y lo único que está haciendo es continuar con una discusión fuera de tema en la que ya podría haber dado una actualización como se solicita al final de cada publicación. Se jacta de las conexiones / invitaciones directas en las reuniones de desarrollo, por lo que debe estar al tanto del estado de este problema y podría actualizar a todos los usuarios lectores aquí.

Una vez más, publique una actualización o deje de publicar fuera de tema, supongo que ese es su trabajo como moderador de la comunidad en lugar de mantener viva la discusión fuera de tema :)

Anuncio general:

Acabo de hablar con @manup en privado sobre esto. Me dijo lo siguiente:

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.

Los mantendré informados.

Han pasado las 2-3 semanas que ha publicado como un anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento, qué podemos esperar los usuarios?

Una nueva reliese está a punto de llegar en menos de una semana. Sugiero mantener la calma
y espera a ver qué traerán los nuevos cambios

Tengo muchos tradfri's trabajando sin problemas durante más de un año.
Recientemente, comencé a tener problemas con solo una de mis luces Tradfri
comenzó a caer y conectarse a la malla aproximadamente cada 15 minutos. 15 minutos
alcanzable, 15 min no alcanzable. Hice muchas pruebas para encontrar el problema.
Adivina qué .... ¿el problema era? No era de deCONZ sino mi WiFi
programa de repetidor una vez que lo puso.

No esté tan seguro de que los problemas siempre están relacionados con deCONZ, a veces no.

El domingo, 6 de septiembre de 2020, 11:38 lubbertkramer [email protected] escribió:

@ JBS5 https://github.com/JBS5 Aún no han pasado 3 semanas. Esperé por el robot rancio
aquí ;)
Pmed @manup https://github.com/manup esta mañana nuevamente. Consiguió el
siguiente respuesta:

He estado rastreando el firmware los últimos días para investigar los problemas de reinicio y encontré algunos errores desagradables.
También contendrá algunos cambios de enrutamiento, espero sacarlo con la próxima versión.

Las mejoras de depuración seguirán después de la próxima versión estable.

Pedí una ETA y él está en este momento.

Bueno, hiciste una promesa a la comunidad, así que es normal que te abrazen.
a esa promesa, 21 días / 7 días = 3 semanas
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está
activo desde febrero de 2019. Cuando quiera ser el portavoz de Dresde
actúa como tal o deja que @manup https://github.com/manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así.
De ninguna manera soy un portavoz, estoy sacando el cuello aquí para conseguir cosas
ordenado porque tengo una conexión directa. El robot obsoleto que uso para realizar un seguimiento
problemas y recibo la notificación. Espero que Manup vuelva a mí y
si pasó el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por el
comunidad, usted sabría mejor que eso. También para agregar eso, no es que
No he tenido otras cosas que hacer en la vida.
Sé el cambio que quieres ver en este mundo

Nadie te pide ni te obliga a ser el intermediario como usuario, así que una vez más
en lugar de flamear y cambiar el poder de las flores, deje este problema como
portavoz o volver al tema y la información más reciente.
Han pasado las 2-3 semanas que ha publicado como anuncio general por
más de 3 semanas ahora, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga su
emociones bajo control. Entiendo tu enfado, pero siendo irrespetuoso
no está ayudando. No acepto ninguna flama aquí. Mantenlo en el tema y
civil. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.

Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no
hazlo en este número.

Y nuevamente, no responde ni actualiza el estado que se le pregunta
muchas veces y lo único que estás haciendo es seguir adelante con un tema diferente
discusión en la que ya podría haber dado una actualización como se solicitó al final
de cada publicación. Te jactas de las conexiones directas / invitaciones en
las reuniones de desarrollo, por lo que debe estar al tanto del estado de
este problema y podría actualizar a todos los usuarios de lectura aquí.

Así que, una vez más, publique una actualización o deje de publicar fuera del tema :)

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment-687726432 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AO4LI5G32N546L6GKHSHISLSENDABANCNFSM4GXPM2DA
.

@ morfei1 y @Mimiix Se miras cómo está funcionando el lanzamiento por parte de DE ("15th" = poco antes de que te paguen). Y no se sabe si una solución es estar con o sin vacaciones.
Y algunos han dicho (y yo muchas veces) que es cómo funciona el soporte oficial y que los clientes tienen grandes problemas.
Extraoficialmente: ZHA estará en 1-2 semanas con el soporte oficial para Silabs EZSP en todas las versiones de sus protocolos de pila, así que creo que un Sonoff Zigbee Bridge o Elelabs-ELU013 / ELR023 es mejor invertir el dinero y obtener más potencia de RF y SoC que los productos DE y un mejor apoyo de la comunidad.
Pero estoy esperando la versión 2 de deCONZ REST-API antes de dejar que todos los productos DE RIP.

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.
_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.
Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga sus emociones bajo control. Entiendo tu enojo, pero ser irrespetuoso no ayuda. No acepto ninguna flama aquí. Mantenlo en el tema y civilizado. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.
Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no lo hagas en este número.

Y nuevamente, no está respondiendo ni actualizando el estado que se le pide muchas veces y lo único que está haciendo es continuar con una discusión fuera de tema en la que ya podría haber dado una actualización como se solicita al final de cada publicación. Se jacta de las conexiones / invitaciones directas en las reuniones de desarrollo, por lo que debe estar al tanto del estado de este problema y podría actualizar a todos los usuarios lectores aquí.

Una vez más, publique una actualización o deje de publicar fuera de tema, supongo que ese es su trabajo como moderador de la comunidad en lugar de mantener viva la discusión fuera de tema :)

Anuncio general:
Acabo de hablar con @manup en privado sobre esto. Me dijo lo siguiente:

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.

Los mantendré informados.

Han pasado las 2-3 semanas que ha publicado como un anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento, qué podemos esperar los usuarios?

Para responder a su pregunta directamente: Eso es lo que me dijo @manup después de que le

Esta será una última advertencia general sobre sus comentarios. El siguiente comentario fuera del tema aquí es bloquear este problema hasta que haya más noticias.

@ JBS5 Aún no han
Pmed @manup esta mañana nuevamente. Obtuve la siguiente respuesta:

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.

Pedí una ETA y él está en este momento.

Bueno, le hiciste una promesa a la comunidad, por lo que es normal que te cumplan esa promesa, 21 días / 7 días = 3 semanas.
entonces es poco convincente esconderse detrás del stalebot cuando este problema ya está activo desde febrero de 2019. Cuando quieras ser el portavoz de Dresde, actúa como tal o deja que @manup se encargue de esto :)
Entonces, ¿cuál es la ETA ahora que han pasado las 2-3 semanas?

No tengo ningún problema en dejar este tema atrás cuando actúas así. De ninguna manera soy un portavoz, estoy arriesgando mi cuello aquí para arreglar las cosas ya que tengo una conexión directa. El bot obsoleto que utilizo para realizar un seguimiento de los problemas y recibo la notificación. Espero que Manup vuelva a mí y, si pasa el tiempo, el robot obsoleto me ayuda a recordar.
Así que no, no es "patético" esconderse detrás de él. Si hicieras lo que hice por la comunidad, sabrías mejor que eso. Además, para agregar eso, no es que no haya tenido otras cosas que hacer en la vida.
_Sé el cambio que quieres ver en este mundo_

Nadie te está pidiendo u obligando a ser el intermediario como usuario, así que una vez más, en lugar de flamear y cambiar el poder de las flores, deja este tema como portavoz o vuelve al tema y a la información más reciente.
Han pasado las 2-3 semanas que ha publicado como anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento?

Todo lo que tenía era lo que mencioné. Permítame aconsejarle que mantenga sus emociones bajo control. Entiendo tu enojo, pero ser irrespetuoso no ayuda. No acepto ninguna flama aquí. Mantenlo en el tema y civilizado. Solo explico cuáles son mis argumentos y por qué hago las cosas como lo hago.
Si desea iniciar un problema para quejarse, sea mi invitado. Simplemente no lo hagas en este número.

Y nuevamente, no está respondiendo ni actualizando el estado que se le pide muchas veces y lo único que está haciendo es continuar con una discusión fuera de tema en la que ya podría haber dado una actualización como se solicita al final de cada publicación. Se jacta de las conexiones / invitaciones directas en las reuniones de desarrollo, por lo que debe estar al tanto del estado de este problema y podría actualizar a todos los usuarios lectores aquí.
Una vez más, publique una actualización o deje de publicar fuera de tema, supongo que ese es su trabajo como moderador de la comunidad en lugar de mantener viva la discusión fuera de tema :)

Anuncio general:
Acabo de hablar con @manup en privado sobre esto. Me dijo lo siguiente:

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.

Los mantendré informados.

Han pasado las 2-3 semanas que ha publicado como un anuncio general en más de 3 semanas, entonces, ¿cuál es el seguimiento, qué podemos esperar los usuarios?

Para responder a su pregunta directamente: Eso es lo que me dijo @manup después de que le

Esta será una última advertencia general sobre sus comentarios. El siguiente comentario fuera del tema aquí es bloquear este problema hasta que haya más noticias.

Esa es una respuesta un poco, así que cuando leí correctamente, podemos esperar una respuesta más detallada a finales de esta semana porque han pasado casi 4 semanas en lugar de las 2-3 que @manup había comunicado a través de usted como anuncio general de que la actualización sería disponible

@Mimiix si ve la necesidad de cerrar este problema que está casi abierto durante dos años con mucha información de usuarios muy solidarios y dedicados sin una solución, entonces no soy la persona que puede detenerlo, eso depende de usted como comunidad. portavoz:)

@lubbertkramer Dije Bloquear, no cerrar.

Y con eso, bloquearé este problema. Lo desbloquearé en unos días o cuando Manuel responda aquí.

Hola de nuevo, creo que ya es hora de recibir una actualización sobre el problema.

Pero lo primero es lo primero, si alguien tiene la culpa aquí soy yo y solo yo. Entiendo la frustración, pero no hay lugar para ser descortés con

Progreso de la actualización

(Vista previa para la próxima versión)

He estado probando mucho con el enrutamiento de origen y experimenté con los hallazgos de este problema y varios registros de rastreo. Dedique mucho tiempo a que el enrutamiento de origen "automático" funcione de manera confiable, según los comandos de registro de ruta entrantes. Que es básicamente lo que hacen la mayoría de las implementaciones con enrutamiento de origen, como el firmware de enrutamiento de origen para zigbee2mqtt. A veces funciona, pero parece haber una dinámica mayor sobre cómo / si se elige (y se mantiene) una ruta de origen en función de los valores de LQI / RSSI que un salto de registro de ruta ve de sus vecinos, en redes mixtas esto es complicado debido a las diferencias en la pila y el hardware. La calidad del enlace también puede ser bastante dinámica si las personas se mueven entre los nodos y las puertas se abren y cierran, lo que lamentablemente también afecta el enrutamiento.

Por lo tanto, experimenté con la idea de configurar rutas de origen fijas hacia un nodo de destino. En muchos casos, solo una parte de la red tiene problemas de enrutamiento, aquí puede ser beneficioso especificar una ruta de origen fija donde:

• Las rutas de origen se pueden especificar opcionalmente por nodo.
• Cada salto siempre debe estar alimentado.
• Las posiciones de los saltos a lo largo del camino deben ser razonables. En algunos casos, un usuario puede tener un mejor plan hacia dónde se deben enrutar los paquetes que lo que el algoritmo automático puede averiguar.

Para hacer eso, el protocolo de firmware se ha extendido para proporcionar opcionalmente una ruta de origen por solicitud de APS. No hay límite en la cantidad de rutas de origen que se pueden configurar, el firmware solo necesita mantener algunas en la memoria para las solicitudes y el ACK.

deCONZ determina automáticamente si cada salto en la ruta es accesible y solo en ese caso usa la ruta de origen.
Las rutas de origen entre bastidores se configuran con direcciones MAC de los nodos para resistir los cambios de dirección NWK.

Crear una ruta de origen fija

• En la interfaz gráfica de usuario de deCONZ, seleccione todos los saltos mientras mantiene presionada la tecla CTRL (selección múltiple) comenzando desde el coordinador (fuente) hasta el nodo de destino. Importante, debe haber al menos un salto entre el origen y el destino.
• Haga clic derecho en el nodo de destino para abrir el menú contextual.
• Seleccione "Agregar ruta de origen".

Esto creará la nueva ruta de origen, visualizada por la línea azulada, las marcas rojas finales al nodo de destino.

(En versiones posteriores, será posible especificar rutas alternativas de respaldo, pero necesito encontrar una buena interfaz de usuario para eso).

Para eliminar una ruta de origen: Seleccione "Eliminar ruta de origen" en el menú contextual del nodo de destino.

La ruta se utilizará para la siguiente solicitud:

Esto funciona bastante bien y permite la sobrescritura manual del enrutamiento si es necesario, también debería ser útil para las pruebas.
Actualmente, esto solo funciona cuando se configura a través de GUI, pero también debería estar disponible a través de REST-API más adelante.

¿Esto arreglará todo?

Es poco probable, pero debería mejorar el enrutamiento hacia los destinos (el enrutamiento en los nodos en sí no se puede configurar). Tenga en cuenta que las rutas de origen fijas son buenas solo para enrutadores, ya que los dispositivos finales tienden a cambiar el padre y la ruta de origen ya no funcionaría, en este caso, el enrutamiento de origen automático podría funcionar mejor.

¿Cuándo saldrá?

Pronto, en la próxima versión 2.05.81, tendré los siguientes elementos (bastante ligeros) en la lista de tareas pendientes para la versión:

• Almacenar / restaurar rutas de origen en la base de datos.
• Arregle el manejo del contador de seguridad NWK para arreglar la copia de seguridad entre diferentes ConBee / RaspBee y reiniciar nada funciona.
• Deje que GCFFlasher verifique que el firmware se esté ejecutando después de la actualización.

Entonces, con @manup su respuesta, se ha dado una respuesta. Manténgase en el tema y en el tema.

Hola de nuevo, creo que ya es hora de recibir una actualización sobre el problema.

Progreso de la actualización

(Vista previa para la próxima versión)

He estado probando mucho con el enrutamiento de origen y experimenté con los hallazgos de este problema y varios registros de rastreo. Dedique mucho tiempo a que el enrutamiento de origen "automático" funcione de manera confiable, según los comandos de registro de ruta entrantes. Que es básicamente lo que hacen la mayoría de las implementaciones con enrutamiento de origen, como el firmware de enrutamiento de origen para zigbee2mqtt. A veces funciona, pero parece haber una dinámica mayor sobre cómo / si se elige (y se mantiene) una ruta de origen en función de los valores de LQI / RSSI que un salto de registro de ruta ve de sus vecinos, en redes mixtas esto es complicado debido a las diferencias en la pila y el hardware. La calidad del enlace también puede ser bastante dinámica si las personas se mueven entre los nodos y las puertas se abren y cierran, lo que lamentablemente también afecta el enrutamiento.

Por lo tanto, experimenté con la idea de configurar rutas de origen fijas hacia un nodo de destino. En muchos casos, solo una parte de la red tiene problemas de enrutamiento, aquí puede ser beneficioso especificar una ruta de origen fija donde:

• Las rutas de origen se pueden especificar opcionalmente por nodo.
• Cada salto siempre debe estar alimentado.
• Las posiciones de los saltos a lo largo del camino deben ser razonables. En algunos casos, un usuario puede tener un mejor plan hacia dónde se deben enrutar los paquetes que lo que el algoritmo automático puede averiguar.

Para hacer eso, el protocolo de firmware se ha extendido para proporcionar opcionalmente una ruta de origen por solicitud de APS. No hay límite en la cantidad de rutas de origen que se pueden configurar, el firmware solo necesita mantener algunas en la memoria para las solicitudes y el ACK.

deCONZ determina automáticamente si cada salto en la ruta es accesible y solo en ese caso usa la ruta de origen.
Las rutas de origen entre bastidores se configuran con direcciones MAC de los nodos para resistir los cambios de dirección NWK.

Crear una ruta de origen fija

• En la interfaz gráfica de usuario de deCONZ, seleccione todos los saltos mientras mantiene presionada la tecla CTRL (selección múltiple) comenzando desde el coordinador (fuente) hasta el nodo de destino. Importante, debe haber al menos un salto entre el origen y el destino.
• Haga clic derecho en el nodo de destino para abrir el menú contextual.
• Seleccione "Agregar ruta de origen".

Esto creará la nueva ruta de origen, visualizada por la línea azulada, las marcas rojas finales al nodo de destino.

(En versiones posteriores, será posible especificar rutas alternativas de respaldo, pero necesito encontrar una buena interfaz de usuario para eso).

Para eliminar una ruta de origen: Seleccione "Eliminar ruta de origen" en el menú contextual del nodo de destino.

La ruta se utilizará para la siguiente solicitud:

Esto funciona bastante bien y permite la sobrescritura manual del enrutamiento si es necesario, también debería ser útil para las pruebas.
Actualmente, esto solo funciona cuando se configura a través de GUI, pero también debería estar disponible a través de REST-API más adelante.

¿Esto arreglará todo?

Es poco probable, pero debería mejorar el enrutamiento hacia los destinos (el enrutamiento en los nodos en sí no se puede configurar). Tenga en cuenta que las rutas de origen fijas son buenas solo para enrutadores, ya que los dispositivos finales tienden a cambiar el padre y la ruta de origen ya no funcionaría, en este caso, el enrutamiento de origen automático podría funcionar mejor.

¿Cuándo saldrá?

Pronto, en la próxima versión 2.05.81, tendré los siguientes elementos (bastante ligeros) en la lista de tareas pendientes para la versión:

• Almacenar / restaurar rutas de origen en la base de datos.
• Arregle el manejo del contador de seguridad NWK para arreglar la copia de seguridad entre diferentes ConBee / RaspBee y reiniciar nada funciona.
• Deje que GCFFlasher verifique que el firmware se esté ejecutando después de la actualización.

Gracias por la respuesta detallada, creo que muchos de nosotros estamos esperando una respuesta como la anterior debido a todo el arduo trabajo que la comunidad está haciendo para este problema y usted como desarrollador.

Varias preguntas de seguimiento que tengo:

• ¿Cuándo estará disponible arriba como actualización en beta / estable?

• ¿Habrá una diferencia en cómo funcionará lo anterior con respecto a conbee 1/2 y Raspbee o será todo lo mismo?

• Para la actualización 2.05.81 mencionas tener elementos bastante (ligeros) en la lista de tareas pendientes, ¿cuándo podemos esperar esa actualización (¿tal vez sea una idea agregar una hoja de ruta a este git?)

Hola @lubbertkramer

Puedo responder el número 1: la versión 2.05.81 se esperaría el día 15 del mes (compilación de Windows unos días después). Lo coloqué en un anuncio anteriormente en Discord, pero pensé que no es el caso de Github. ¡Agregaré eso al archivo Léame! ¡Culpa mía!

Editar: Hizo una solicitud de extracción del archivo readme.md. No estoy seguro de cómo se está ejecutando el canal estable que deba aclararse un poco.

¿Habrá una diferencia en cómo funcionará lo anterior con respecto a conbee 1/2 y Raspbee o será todo lo mismo?

Debería funcionar igual, ahora he transferido el código a RaspBee I / ConBee I y las rutas de origen se usan allí de la misma manera.

Actualmente tengo un caso curioso en el que un enchufe repetidor IKEA está vivo pero no quiere jugar con el resto de la red.
Los comandos que se le envían (con y sin rutas de origen) se ignoran en silencio.

El repetidor envía sus tramas de estado de enlace NWK, pero informa y lista de vecinos vacía:

Se ignoran los comandos del coordinador y del sensor OSRAM del que el repetidor es el padre. El sensor, como muchos dispositivos Xiaomi, no intenta encontrar un nuevo padre automáticamente ... mala situación:

Este escenario se ejecuta desde hace dos días, no he encontrado una manera de recuperar el repetidor. Quizás un ciclo de energía del repetidor solucione el problema, pero lo mantendré así por ahora para ver si se puede resolver de alguna manera por vía aérea.

¿Hay algún problema con el repetidor USB Tradfri o el enchufe Tradfri?

En este caso fue el enchufe, no estoy seguro de si es la última versión, necesito verificar esto más tarde.

¿Es posible comprobarlo? Tengo 3 enchufes Tradfri que funcionan con el último FW sólido como una roca durante aproximadamente 1,5 años. Si empiezo a tener problemas con ellos con la nueva beta, tendré que retrasar la actualización.

¡Gracias!

Aquí están los datos del clúster básico, tenga en cuenta que el problema ocurrió por primera vez hace dos días en mi red doméstica que no tenía el nuevo firmware en ese momento.

Parece que está en el último FW como mis enchufes. Espero que sea, por el viejo FW de Ikea ...

La página web con el registro de cambios de tradfri está inactiva, para comprobar qué ha corregido el último FW.

Los archivos de firmware más recientes están en línea ahora:

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 y ConBee I

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

• Estos tienen el enrutamiento de origen habilitado con máx. 32 rutas de origen, donde las entradas más antiguas se reemplazan automáticamente por otras más nuevas. Es probable que la cantidad aumente en versiones posteriores, pero ya debería funcionar bien.
• Si existe una ruta de origen y una entrada de ruta "normal", se prefiere la ruta de origen. Esto no es estándar pero parece funcionar mejor.
• El firmware tiene mejoras generales para la solidez del protocolo serial.
• ConBee II y RaspBee II mejoraron el manejo del contador de cuadros, para mitigar los problemas en los que, después de un ciclo de energía, la red podría haber parecido perdida hasta que el contador de cuadros vuelva a alcanzar su valor anterior.

@manup hizo firmware para ConBee. Dejé caer version id de comando 0x0D ? Ya no recibo respuesta a este comando

@Adminiuga @manup Aspectos sobre el firmware: utilice # 3260.

Los archivos de firmware más recientes están en línea ahora:

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 y ConBee I

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

• Estos tienen el enrutamiento de origen habilitado con máx. 32 rutas de origen, donde las entradas más antiguas se reemplazan automáticamente por otras más nuevas. Es probable que la cantidad aumente en versiones posteriores, pero ya debería funcionar bien.
• Si existe una ruta de origen y una entrada de ruta "normal", se prefiere la ruta de origen. Esto no es estándar pero parece funcionar mejor.
• El firmware tiene mejoras generales para la solidez del protocolo serial.
• ConBee II y RaspBee II mejoraron el manejo del contador de cuadros, para mitigar los problemas en los que, después de un ciclo de energía, la red podría haber parecido perdida hasta que el contador de cuadros vuelva a alcanzar su valor anterior.

¿Cómo actualizo este firmware (uso la imagen deCONZ Docker de marthoc)?

He descargado el archivo (ConBee II) pero las instrucciones de actualización manual no se aplican a la imagen de deCONZ Docker de marthoc y la guía para deCONZ de marthoc no permite usar un firmware no incluido en la imagen (y este archivo no está listado según esté disponible).

¿Cómo actualizo este firmware (uso la imagen deCONZ Docker de marthoc)?

Simplemente conecto el dongle USB a una computadora portátil con Windows y lo hago desde allí y de nuevo a mi Synology NAS cuando está listo.

¿Cómo actualizo este firmware (uso la imagen deCONZ Docker de marthoc)?

Simplemente conecto el dongle USB a una computadora portátil con Windows y lo hago desde allí y de nuevo a mi Synology NAS cuando está listo.

¿Existe una utilidad de Windows para actualizar el firmware? Si es así, ¿podría compartir el enlace?

¿Cómo actualizo este firmware (uso la imagen deCONZ Docker de marthoc)?

Simplemente conecto el dongle USB a una computadora portátil con Windows y lo hago desde allí y de nuevo a mi Synology NAS cuando está listo.

¿Existe una utilidad de Windows para actualizar el firmware? Si es así, ¿podría compartir el enlace?

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually#update -in-windows

Por lo tanto, experimenté con la idea de configurar rutas de origen fijas hacia un nodo de destino. En muchos casos, solo una parte de la red tiene problemas de enrutamiento, aquí puede ser beneficioso especificar una ruta de origen fija donde:

• Las rutas de origen se pueden especificar opcionalmente por nodo.
• Cada salto siempre debe estar alimentado.
• Las posiciones de los saltos a lo largo del camino deben ser razonables. En algunos casos, un usuario puede tener un mejor plan hacia dónde se deben enrutar los paquetes que lo que el algoritmo automático puede averiguar.

¿Esto arreglará todo?

Es poco probable, pero debería mejorar el enrutamiento hacia los destinos (el enrutamiento en los nodos en sí no se puede configurar). Tenga en cuenta que las rutas de origen fijas son buenas solo para enrutadores, ya que los dispositivos finales tienden a cambiar el padre y la ruta de origen ya no funcionaría, en este caso, el enrutamiento de origen automático podría funcionar mejor.

Solo para aclarar ... ¿este nuevo firmware va a arreglar (o al menos mejorar) la desconexión aleatoria de los dispositivos Ikea si no configuro manualmente ninguna nueva ruta de fuente estática? ¿O la única forma de beneficiarse de esta actualización es configurar manualmente las rutas de aquellos dispositivos que tienden a perder la conexión?

Sin rutas de configuración manual, el enrutamiento de origen automático tiene lugar si los dispositivos las promueven (como lo hacen los dispositivos IKEA).
Por lo tanto, en comparación con el enrutamiento de origen de firmware anterior, se utilizará para estos dispositivos si se conoce dicha ruta.

Si realmente ayuda, permanece abierto, sería bueno que alguien que haya tenido problemas con el firmware anterior pueda informar si algo ha cambiado.

En mis redes de prueba, el firmware funciona bastante bien y las rutas de origen se utilizan con frecuencia, como lo indican los registros del rastreador. Eso no significa mucho, ya que incluso sin el enrutamiento de origen, mis redes eran bastante sólidas.

Tengo 21 luces (4 - 980lu WS, 17 - 1000lu WS), 3 enchufes y 3 mandos a distancia redondos (5 botones) de Ikea. Todos ellos en los últimos FW de Ikea. Nunca he experimentado inestabilidad con ellos durante los últimos 1,5 años aproximadamente. Nighter con cualquiera de las versiones anteriores de deCONZ o lanzamientos de FW ni con la actual. Estoy ejecutando .81 estable con la última RaspBee FW 0x26370500, y tampoco he tenido ningún problema durante la última semana de uso.

Supongo ... (tal vez no estoy del todo en lo cierto) Ikea no tiene un problema general, pero su configuración es específica. Hay muchos factores diferentes que pueden afectar su comportamiento y desempeño en deCONZ y en general.

Creo que la mayoría de los problemas ocurrieron con las lámparas Ikea GU10. La estabilidad había mejorado enormemente con el tiempo, pero fue un desastre a fines de 2018 cuando comencé. Tuve que apagar y encender uno de 30 GU10 cada dos semanas en promedio durante los últimos tres meses de versión / firmware.

Creo que la mayoría de los problemas ocurrieron con las lámparas Ikea GU10. La estabilidad había mejorado enormemente con el tiempo, pero fue un desastre a fines de 2018 cuando comencé. Tuve que apagar y encender uno de 30 GU10 cada dos semanas en promedio durante los últimos tres meses de versión / firmware.

Podría ser. El GU10 no ha recibido actualización de FW como otras luces de Ikea, hasta donde yo sé. Recientemente, lo discutimos en los canales de discordia. Un usuario que ejecuta las luces GU10 Ikea experimenta este comportamiento. No importa lo que intentemos, nada parece resolver sus problemas. Incluso compartió con nosotros que compró un Ikea Tradfri Hub y también tuvo la misma mala experiencia, incluso con el Ikea Hub y las luces GU10.

Entonces, supongo que es cuestión de tiempo que Ikea lance un nuevo FW para este tipo de luces para tal vez resolver / solucionar este problema ...

Me pregunto si @djwlindenaar ya se ha actualizado a la última versión de deCONZ y firmware y puede compartir sus experiencias. :)

En realidad, todavía no ... No encontré tiempo todavía para actualizar. Además, no encontré tiempo para cambiar a z2mqtt, por lo que la buena noticia es que actualizaré al nuevo firmware y, si hay algo que informar, lo haré.

Si realmente ayuda, permanece abierto, sería bueno que alguien que haya tenido problemas con el firmware anterior pueda informar si algo ha cambiado.

Actualicé al último firmware hace 2 días y desde entonces uno de mis interruptores de pared Xiaomi (ctrl_neutral2, 11-25-2017) se alteró por sí solo 3 veces. Nunca antes había tenido tal problema.

Se conecta al coordinador mediante una bombilla Tradfri E27 CWS en 1.3.009.

Además, no está estrictamente relacionado con este problema, pero nunca logré obtener una actualización OTA con Deconz (contenedor comunitario).

Tengo las bombillas Tradfri:

• E27 CWS en 1.3.009
• E14 W en 1.2.214
• Atenuador inalámbrico en 1.2.248
• 17 * GU10 WS en 1.2.221

Puedo ver los archivos de Trafri OTA descargados, pero no sucede nada. ¿Qué tengo que hacer?

Como referencia, así es como comienza el contenedor:

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 Esto no está relacionado con este problema aquí afaik. Abra un problema por separado. Creo que debería publicar en el repositorio de la versión de Docker. https://github.com/marthoc/docker-deconz

Nota de moderación:

Antes de que todo se mezcle aquí, me gustaría establecer un alcance aquí.

Todo lo relacionado con el problema original: en este problema se permite que las luces de IKEA pierdan conexión ocasionalmente.

Cualquier otro problema relacionado con el firmware se puede publicar aquí

En realidad, todavía no ... No encontré tiempo todavía para actualizar. Además, no encontré tiempo para cambiar a z2mqtt, por lo que la buena noticia es que actualizaré al nuevo firmware y, si hay algo que informar, lo haré.

@ JBS5 , tu gatillo ayudó;)

Acabo de instalar el firmware y el último deCONZ .deb. Hasta ahora puedo confirmar que el enrutamiento de origen funciona, por supuesto, aún no hay conclusiones sobre la estabilidad. Te mantendré 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 Mira cómo funciona el complemento OTA https://github.com/dresden-elektronik/deconz-ota-plugin y actualiza tus dispositivos.
Lo siento, pero es un problema de comunicación del dispositivo IKEA.

@ morfei1 @ peer69
Puedo confirmar que no solo es causado por las bombillas GU10. Tuve problemas de enrutamiento y pérdida de conexión durante mucho tiempo sin GU10 en mi sistema.

Tuve algunos problemas iniciales después del lanzamiento .82 con el nuevo firmware en mi conbee 1.
Pero ahora, después de que la malla de la red se estabilizó y algunos ciclos de energía, ha sido sólida durante los últimos días.

Tan tonto como soy, decidí actualizar al último firmware (OTAU) en todas mis bombillas para tener una mejor línea de base para comenzar si hay problemas futuros. Deséame suerte. Los mantendrá informados sobre el progreso.

@tubalainen, ¿estás en el complemento HA?

@tubalainen, ¿estás en el complemento HA?

No, utilizo HA Core en Debian en la ventana acoplable, por lo que también uso el paquete https://github.com/marthoc/docker-deconz stand-a-lone docker. Ambos usan el archivo .deb proporcionado por dresten, por lo que deberían funcionar de manera idéntica. No estoy seguro de si el complemento OTAU está incluido en el complemento deconz HA ...

solo aportando mis observaciones hasta ahora;

Solo tengo problemas con mi Ikea GU-10 (23 de ellos), y uso el asistente de inicio, que se conecta a deconz (docker) a través del resto de la API, y puedo ver a HA disparando los eventos para deconz con éxito.

Cuando uso HA para encender, 17 bombillas, una por una (una después de la otra), tal vez 3 de las 17 dosis se encienden, pero HA las ve como encendidas.
PERO, si hago un grupo en deconz. ponga todas las luces en ese grupo y dígale a HA que encienda ese grupo, todavía no ha habido ningún problema, todas las luces se encienden.

Usando firmware: 0x26650700 no he visto ninguna mejora (aparte de que tuve que volver a emparejar esas 17 bombillas por alguna razón, e incluso después de volver a emparejar tuve los mismos problemas)

¿Es una limitación en el rest-api quizás?

@MartinTerp , si usa un solo comando para cada dispositivo a la vez, en lugar de 1 comando para un grupo, fallará, tal vez no siempre, pero la mayoría de las veces un dispositivo aleatorio que se supone que debe hacer algo no lo hará.

Mi solución para esto es un retraso de 5 segundos entre comandos. Por ejemplo
Si quiero encender las luces de mi dormitorio a las 23:00 en bri: 127 y ct: 454, y también en mi pasillo, le doy 5 segundos de retraso a uno de los de la habitación. Si no pongo el retraso, fallará aleatoriamente al completar el comando completo para una de las habitaciones o tal vez para ambas. Experimento mucho con esto. Es algo similar al error de Ikea, no puede manejar el cambio de color y brillo al mismo tiempo.

No sé qué es exactamente esto, un error deconz, una limitación de zigbee en general o un error de Ikea FW. Tal vez sea mi falta de conocimiento de cómo funciona zigbee, pero el retraso de 5 segundos siempre funciona para mí.

Como regla general, siempre uso: lije los comandos más pequeños que pueda a la vez o use un retraso. Por lo tanto, mantiene limpio el canal.

Si necesita cambiar muchos grupos / luces a la vez, como habrá notado, siempre es mejor crear un nuevo grupo de foscon, incluir estos grupos de luces en él y enviarles un comando de grupo único. Puede tener muchos grupos diferentes, incluida la misma luz. No estamos limitados a usar un solo grupo por luz. Si no le gusta tener muchos grupos en phoscon, entonces el retraso es su mejor amigo.

@ morfei1 Estoy usando una solución similar y funciona la mayor parte del tiempo con un retraso de 5 segundos entre todos los comandos.
@MartinTerp También he tenido este problema con otros dispositivos además de las luces IKEA-Tradfri, por ejemplo, los enchufes inteligentes y las tiras de luz OSRAM. Supongo que es posible, aunque el problema fue causado por algunos Tradfri-Lights con errores que no reenviaron los comandos.

Pero no se supone que sea así, ¿verdad?
en el momento en que el script los enciende 1 por 1 con un retraso de 1 segundo, ¿DEBERÍA poder manejar eso?

@ morfei1 @MartinTerp

También solía usar retrasos + que envío comandos de encendido y apagado desde el asistente doméstico dos veces por automatización activada.

Ahora he eliminado los retrasos y los comandos de repetición desde .82.

Estoy bastante seguro de que no se supone que necesite un retraso de 5 segundos. Creo que esto no era necesario con alguna versión anterior, pero no apostaría por ello ya que mi red ha crecido desde entonces. Quizás 82 (aún no lo he probado con retraso reducido) o versiones futuras mejorarán este comportamiento.

@ morfei1 @githtz @tubalainen @martinterp

¿Podríamos tener la discusión sobre cómo actualizar los firmwares de dispositivos en otros lugares?

¿No nos ocupamos de actualizar el firmware?

Cuando lo leo correctamente, los problemas de enviar múltiples comandos, donde no todos pasan, son diferentes. Es probable que esto sea más un problema con el programador de tareas.

Sugeriría abrir un problema separado para eso, como "No todas las luces reaccionan cuando se envían comandos de unidifusión a varias luces".

El problema aquí es más sobre cuándo las luces se pierden por completo y no son accesibles en absoluto, lo que puede estar relacionado con el enrutamiento.

Redactado por Mimiix

Redactado por Mimiix

@inconsx @ ReX1983 Pensé que estaba claro en https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1261#issuecomment -696541484 y https://github.com/dresden-elektronik/deconz- rest-plugin / issues / 1261 # issuecomment -696046160

Cumpla con estas reglas. Abra problemas separados si lo desea.

Así que aquí están mis comentarios, he actualizado al último firmware y la api deconz. Ejecuto mi red desde HA.

Tengo alrededor de 72 nodos, la mayoría de ellos son luces IKEA GU10. Después de la actualización, noté dos GU10 diferentes que "murieron" dos días diferentes, la única forma de recuperarlo es apagar y encender. El GU10 usa el accesorio de 1.2.217 y 1.2.221. Intentaré actualizarlos todos a la misma versión.

Solo tengo 4 GU10, creo que estos son de la primera versión lanzada, que se ejecutan en la última versión de ota. Nunca tuve un problema con estos en términos de accesibilidad, solo mis escenas se estropearon después de la actualización ligera del firmware.

Acabo de tener una de mis bombillas IKEA TRADFRI E14 W op / ch 400lm Versión 1.2.214 que dejó de responder. Esta lámpara ha hecho esto muchas veces y en diferentes firmwares deconz. Ahora mismo estoy usando deconz 26370500 y 2.05.82.

Solo tengo 4 GU10, creo que estos son de la primera versión lanzada, que se ejecutan en la última versión de ota. Nunca tuve un problema con estos en términos de accesibilidad, solo mis escenas se estropearon después de la actualización ligera del firmware.

¿Ha visto una mejora en la estabilidad con estas bombillas GU10 después de la actualización a 2.3.050? Ahora estoy en 0x26650700 y desde la actualización a 2.3.050 (de 17 bombillas) parece que mi red es mucho más estable. Los dispositivos no se desconectan de la noche a la mañana y mis botones / interruptores Aqara funcionan en los primeros intentos. Ahora son 4 días, tan pronto para decirlo.

Solo tengo 4 GU10, creo que estos son de la primera versión lanzada

En realidad, hay una versión más barata de IKEA GU10 (solo W). Nunca se han actualizado al software 2.xy todavía se ejecutan en 1.2.214. Y estos fueron los más problemáticos. Personalmente, me rindo y ahora funcionan sin problemas con IKEA Hub.

Creo que @antonbo se está acercando al curso del problema.
IKEA utiliza las mismas imágenes de firmware con hardware diferente (unidades PSU / LED) y tiene diferentes configuraciones en los "datos de usuario" para hardware diferente (y el ID del modelo se almacena en él). Entonces, un firmware puede funcionar bien en un hardware (E14) y tener problemas en otros (GU10 / E27).
Una diferencia es que IKEA GW se ejecuta en modo ZLL (en Zigbee PRO) y no extrae el estado del dispositivo, solo escucha los cambios de estado que los dispositivos envían a la red (estándar Zigbee PRO / ZB3) y los mezcla con HUE y otros Los proveedores que el coordinador extrae el estado de los dispositivos (no el comportamiento de ZB3) pueden causar un desastre en la red.
Tengo el IKEA RGBW más antiguo y un E27 Opal WW con firmware antiguo actualizado (1.X) que funciona bien y un montón de ZB3 GU10 WS nuevo que funciona muy bien. Mi columna vertebral tiene alrededor de 10 enchufes IKEA que mantienen la comunicación de red estable y también mis sensores Xioami funcionan bien con todos ellos.
Mi sensación es que no es un problema general más HW y quizás FW en combinación con el diseño de la red y evitando algunos dispositivos problemáticos (como OSRAM Outdoor Plug que está corrompiendo paquetes y perdiendo niños todo el tiempo).

@manup Solo puedo decir que para mi sistema el nuevo firmware lo ha hecho mucho peor que antes. Ya sea el enrutamiento de la fuente o lo que es, ahora tengo cada día una o dos bombillas atascadas y necesito un ciclo de energía. Incluso he visto una de mis bombillas de tono de Philips atascadas, pero no requirió un ciclo de encendido. No sé si los problemas ahora son causados ​​por el firmware anterior que estoy ejecutando en ellos, pero tampoco puedo actualizar porque se atascó. :(

Me pregunto si alguien sabe si el GU10 más nuevo todavía tiene problemas o no los tiene. Escuché que los dispositivos más nuevos ejecutan zigbee 3.0, mi esposa no está contenta con estos problemas, así que podría cambiarlos todos si ayuda.

Tuve una luz colgante esta mañana. Creo que es uno de los más nuevos.

La luz no reaccionó a ningún comando, se mostró como fuera de línea. Un ciclo de energía no solucionó el problema. Tuve que restablecerlo y volver a agregarlo a la red.

@ JBS5 @djwlindenaar @lubbertkramer ¿ Algún comentario sobre los últimos firmwares en comparación con este problema?

Puedo agregar que durante 48 horas no he tenido ningún problema sobre lo que aborda este tema y lo que he experimentado anteriormente.

Sin embargo, es necesario agregar lo siguiente

• reinicie el contenedor con deconz todas las noches
• movió la agrupación de Home-assistant a deconz / phoscon para manejar.

Tenía algunas bombillas menos sensibles antes de los cambios anteriores, aunque fue una mejor experiencia, pero no a partir de ahora.

@Mimiix , bueno, es un poco pronto para decirlo.

Lo que me molesta es que la red se siente mucho más lenta. El tiempo entre presionar un botón y el encendido de la luz (a través de una regla) es más largo que antes. También encender la luz y cambiar el brillo ahora es un proceso de dos pasos con un tiempo intermedio. Todavía necesito mirar los registros de rastreo para verificar qué está causando esto. Probablemente esto no tenga nada que ver con el cambio al enrutamiento de origen, pero ahí lo tienes.

Tenía una luz que no respondía, pero tampoco he analizado esa situación, por lo que es difícil saber qué sucedió.

Mis bombillas E27 Ikea se han detenido colectivamente para cooperar.
Hasta ahora, el ciclo de potencia ha funcionado para algunos de ellos. 3 aún no han vuelto. Supongo que tengo que volver a agregarlos ... :(

Firmware: 26610700
Versión: 2.05.84 / 14.9.2020
(Raspbee2)

@umrath Esto parece no tener relación con el problema abordado en este número. Abra un problema separado :)

El síntoma me parece muy similar: las lámparas dejan de responder sin motivo aparente.

Como acabo de decir: esto parece no tener relación. por favor abra un problema separado. Siempre podemos determinar después que esto está relacionado. Mantengo una nave estricta sobre este tema.

Sí, también creo que está relacionado. Después de unos meses sin el error, ayer volví a tener el problema con dos dispositivos, un IKEA E27 (muy antiguo) y la salida IKEA más nueva, ambos con firmware reciente.

Lo único que hice en ese momento fue transportar una persiana KADRILJ fuera del alcance y luego regresar, pero esto podría no tener ninguna relación.

Encender el rastreador muestra el mismo problema:

• Los dispositivos aún envían periódicamente comandos de estado de enlace NWK;
• Pero siempre con una lista vacía, parece que ignoran todos los enrutadores circundantes;
• Aceptan los comandos entrantes a nivel MAC;
• Reaccionan a las solicitudes de balizas y envían una baliza, pero esa es la única "respuesta" que dan.

De alguna manera, parece que la pila Zigbee en los dispositivos IKEA se bloquea en parte por las capas NWK y APS y superiores o tal vez los búferes NWK entrantes están llenos y nunca se liberan.

Traté de devolver la vida a los dispositivos enviando:

• ZDP Salir con reincorporación;
• NWK Salir con reincorporación (nivel inferior).

Ambos reciben ACK a nivel MAC, pero de lo contrario se ignoran.

Luego intenté falsificar los comandos de estado del enlace NWK del coordinador con una entrada válida que indica que el dispositivo tiene un costo de enlace entrante y saliente en funcionamiento (3/3) con la esperanza de que el dispositivo recoja al coordinador en su tabla vecina. ... tampoco funcionó.

Desafortunadamente, no parece haber una manera de solucionar la situación después de que sucedió y el dispositivo IKEA entra en este estado mayoritariamente muerto. Al mirar a través de algunos foros, el comportamiento se puede ver con todo tipo de puertas de enlace y pilas de Zigbee subyacentes. Lo cual es interesante ya que, por ejemplo, el puente Hue no hace nada elegante de Zigbee como consultar tablas vecinas o enlaces e informes y aún así se produce el error.

Lo que IKEA debe hacer es implementar al menos un perro guardián que verifique que los componentes NWK y APS aún estén funcionando y deje que el dispositivo active el perro guardián para que se reinicie. Esto no solucionaría el error, pero al menos mantendría el dispositivo funcional cuando suceda.

@manup ¿Es usted viejo E27 one LL con clúster de diagnóstico?
Quizás sea interesante ver si algo está sucediendo con los contadores allí con algunas semanas entre ellos.
No puede solucionar el problema, pero da un indicio de que el firmware no está fallando.
Buenas observaciones y conclusiones mande !!

Creo que Silabs tiene un poco más de búsqueda de errores que hacer para uno de los clientes más grandes ;-)

Hola, esto me confunde ya que desde que me mudé a Z2M usando el ZZH hace algunos meses no he visto este problema. Quizás haya alguna otra variable en la ecuación. Sería genial si alguien más que haya hecho el mismo movimiento pudiera confirmarlo.

@mvjt ¿Está usando Rasp / CornBee con Z2M o algún otro Coordinador?
Diferentes pilas de zigbee funcionan de diferentes maneras y pueden tener / generar diferentes problemas.

Editar: Lo siento, veo ZZH = nuevo coordinador de TI.
deCONZ NCP = Atmel / Microchip
Dispositivos IKEA / NCP = Sirlabs EFR32 / EZSP

Puedo confirmar que HA / ZHA / Zigpy / Bellows funciona muy bien con el módulo "Billy EZSP" = IKEA ICC-1-A como coordinador con enrutadores IKEA y dispositivos finales de IKEA y Xiaomi y SIN enrutadores OSRAM o Xiaomi.

@MattWestb Sí, el E27 tiene el clúster de diagnóstico, pero aún no lo he encendido para mantenerlo en estado de error. Al leer los atributos del clúster de mis otras luces de IKEA, los atributos informan que todos no están disponibles: /

Al menos en el pasado, el problema que veo sucedió también con TI CC253X y al final del problema se menciona el CC26X2R1, pero ese era el estado en enero en el que podría haber mejorado mientras tanto. https://github.com/Koenkk/zigbee2mqtt/issues/2032#issuecomment -547483373

Puede que no sea un error de Silabs en general, también podría ser algo personalizado en la capa de aplicación. Creo que los dispositivos Hue recientes también usan Silabs. Desde el puente Hue hay al menos versiones de TI y Microchip.

Es algo realmente desagradable, en muchos casos el error puede no ocurrir en absoluto o solo después de unos meses, en otras redes ocurre en intervalos mucho más pequeños. Supongo que también es importante cómo se operan las redes y que las luces que se apagan regularmente se ven menos afectadas.

@manup Tengo un escenario que está pasando muy bien en su "problema de IKEA".
Si ha configurado su red, comienza con una clave de red y el contador de tramas de seguridad comienza a funcionar. Si no ha reformado la red o ha cambiado la clave de la red durante mucho tiempo, el contador se detiene porque ha llegado al máximo de 0xFFFFFFFF (32 bits) y no puede aumentar.
Luego, el dispositivo arroja todos los datos que ingresan en la capa zigbee porque el contador de cuadros es incorrecto pero la capa inferior a la red sigue funcionando normalmente.
El problema es que no conozco un método para obtener la posición del contador de marcos de seguridad de los dispositivos. Creo que no es posible verlo en Wireshark (pensar = no saber).

Lo que apunta a esto es que los primeros dispositivos emparejados que no se restablecen se estancan más rápido.
Los dispositivos emparejados / reiniciados más nuevos funcionan durante más tiempo antes de que el contador se detenga.
Los comandos de Mutch a un dispositivo también hacen que se atasque más rápido que un dispositivo que no es tan "comunicativo".

Se recomienda rodar la clave de red de forma regular en la red ZB3 para mantenerla segura y luego también restablecer el contador de tramas de seguridad para que no se atasque.
Alguna información AN1233: Zigbee Security 2.1.6 El contador de tramas de seguridad de red.

Es una gran lluvia de ideas, pero puede ser que el problema venga después de mucho tiempo en funcionamiento de la red.

Una prueba es intentar rodar la clave de red y el dispositivo "vivo" estuvo funcionando bien durante bastante tiempo, pero el bloqueado debe reiniciarse / volverse a unir para iniciar el contador de tramas de seguridad desde cero.

Hrm, estoy bastante seguro de que al rodar la clave de red, se eliminarán todos los xiaomis.

¡¡¡200% incorrecto seguro de que no se actualizan y salen de la red (los antiguos no ZB3) !!!

@Adminiuga ¿Está intentando rodar la clave de red en EZSP?
Me parece interesante el resultado !!!

No intenté rodar la clave de red. En realidad, sería interesante saber cuántas implementaciones lanzan la clave de forma regular.
Pero puedo confirmar que el cambio de pan-id tiene muchas posibilidades de que caiga xiaomis, como 4 de cada 5 posibilidades

He visto algunas pruebas de penetración de seguridad que tienen olfateo de Pan-ID de la calle y regresan varias veces con algunos meses entre y no, el gran proveedor de luz (no nombrado aquí) no estaba transfiriendo la clave de red después de un año (Mariahilferstraße en Wien ) por lo que es muy probable que tenga derecho (agen).

Si y solo si es el contador de tramas de seguridad el que está causando el problema, entonces está haciendo lo mismo para todos los dispositivos zigbee 3 reales, entonces se define en la "Especificación de comportamiento del dispositivo base" y se recomienda en la antigua LL, pero muy probablemente no sin dispositivos zigbee PRO (antiguos HA y LL) o dispositivos no certificados (sin nombre .... mi).
Entonces es mejor "manual" enrollar las claves de red o dos veces al año y no es necesario demoler la casa para restablecer los dispositivos incorporados más veces en la boca, luego se estancan y se restablecen / se vuelven a unir sensores antiguos de Xiaomi que normalmente no se están haciendo. integrados en la estructura de la casa y siendo más fáciles de volver a colocar (normalmente se abren uniendo y presionando el botón y se están conectando).
Menny "chinese Zigbee 3" está lanzando el contador de marcos de seguridad "antiguo" después de reiniciar la energía y usando uno nuevo del primer paquete que llega de sus vecinos (he visto que luego de probar los problemas de tasmotas zigbee 3, el contador NCP se reinició incorrectamente al reiniciar) por lo que son solo repotenciación y están de vuelta.

También hicimos algunas pruebas el año pasado, ninguna puerta de enlace rotaba la clave de red. Como se describe en la especificación, esa es la única forma de restablecer el contador de tramas de seguridad NWK al incrementar el número de clave de red. También comparto la preocupación de que esto sea compatible con todos los dispositivos, por lo general, las características que casi nunca se usan no están bien probadas. Realmente espero estar equivocado aquí y funciona para la mayoría de los dispositivos.

En cualquier caso, restablecer el contador de tramas es lo más importante para la puerta de enlace, ya que tiene la mayor cantidad de comandos salientes, las luces y los sensores deberían estar bien durante los próximos años. Actualmente, esto no es un problema, pero se convierte en uno en 2 a 3 años cuando se alcanza el contador de puerta de enlace en redes más grandes. Para eso, ya tenemos planes para verificar si funciona la rotación de la clave de red, así como el número de clave y el restablecimiento del contador de cuadros.

De todos modos, el problema aquí es diferente, los contadores de tramas de la puerta de enlace y las luces en estado de error aún están bien y bastante bajos.

@djwlindenaar Me pregunto si tiene algún hallazgo nuevo, ya que puede analizar técnicamente sus hallazgos además de informar que una lámpara se ha desconectado nuevamente, como puedo hacer. Agradecemos enormemente sus hallazgos e ideas. :)

Bueno, gracias por el agradecimiento ... Para ser honesto, no estoy del todo satisfecho con la estabilidad actual de la red. Se cayó desde que se actualizó al último firmware deconz. Algunas luces se apagaron en las últimas semanas, donde esto no sucedió durante mucho tiempo antes de la actualización. Ejecuté con los parches que permiten informes de atributos regulares para las luces de IKEA, que aún no apliqué en la situación actual

Aunque es divertido analizar esto, es un pasatiempo para mí y ahora mi tiempo está totalmente ocupado por algunas remodelaciones de la casa. Veré si puedo dedicar un poco de tiempo ...

Bueno, gracias por el agradecimiento ... Para ser honesto, no estoy del todo satisfecho con la estabilidad actual de la red. Se cayó desde que se actualizó al último firmware deconz.

Estoy teniendo la misma experiencia negativa. Ahora la mayoría de mis dispositivos Xiaomi (principalmente interruptores de pared Aqara) se desconectan con frecuencia durante el día y vuelven a funcionar después de unos minutos (supongo que esto se debe al hecho de que los dispositivos Xiaomi se reinician si no reciben una respuesta a la solicitud del atributos del clúster de tiempo del coordinador).

La nueva versión v2.5.88 podría mejorar la situación. Aquí, la configuración de informes de IKEA se suavizó para que las transiciones de estado no bombardeen la red con informes. Antes, durante la transición de estado, todos los atributos se informaron a un ritmo muy rápido.

La nueva versión v2.5.88 podría mejorar la situación. Aquí, la configuración de informes de IKEA se suavizó para que las transiciones de estado no bombardeen la red con informes. Antes, durante la transición de estado, todos los atributos se informaron a un ritmo muy rápido.

Suena prometedor :) Supongo que también hay una transición de estado activada / desactivada. ¿O principalmente cambios de modo de brillo o color?
¿Alguna versión mínima de firmware necesaria / recomendada para este cambio?

Solo brillo y todos los atributos específicos de color como colorX, colorY y temperatura de color.
Para el firmware, siempre recomendaría el último 0x26660700 (en el caso de ConBee II y RaspBee II).

La nueva versión v2.5.88 podría mejorar la situación. Aquí, la configuración de informes de IKEA se suavizó para que las transiciones de estado no bombardeen la red con informes. Antes, durante la transición de estado, todos los atributos se informaron a un ritmo muy rápido.

@manup , creo que esta actualización también resolvió los problemas de estabilidad con los dispositivos Aqara. Gracias

La nueva versión v2.5.88 podría mejorar la situación. Aquí, la configuración de informes de IKEA se suavizó para que las transiciones de estado no bombardeen la red con informes. Antes, durante la transición de estado, todos los atributos se informaron a un ritmo muy rápido.

@manup , creo que esta actualización también resolvió los problemas de estabilidad con los dispositivos Aqara. Gracias

Desafortunadamente, el problema (# 3605) todavía está aquí, me apresuré a sacar conclusiones demasiado pronto