Sí, voy a cambiar el nivel de registro.
¿Por qué haces 400 solicitudes por minuto? ¿Tienes cientos de dispositivos?
¡En el rango es genial, de hecho! 
Creo saber de dónde viene esto, de hecho cada vez que se publica un nuevo valor de sensor, Gladys debe verificar que ninguna escena debe ser activada.
Actualmente, lo que se hace es que cada vez que se recibe un valor de sensor, Gladys recorre cada escena existente y verifica si la escena valida o no la condición. Es un simple forEach síncrono que, por lo tanto, es bloqueante.
En términos de complejidad, es O(n), cuanto más escenas haya que recorrer, más tiempo llevará. Sobre todo en tu caso, con 400 solicitudes por minuto (6.6 solicitudes/segundo), hay muchas iteraciones de bucle 
Por curiosidad, ¿cuántas escenas tienes?
Tenía esta limitación en mente y había creado una issue en GitHub para solucionarlo: Each Node.js event should trigger a O(1) function, not O(n) · Issue #803 · GladysAssistant/Gladys · GitHub
En resumen, la idea sería encontrar una manera de almacenar las escenas en RAM de manera diferente, en un formato donde pudiéramos verificar si una escena es válida en un simple 0(1), al menos para los eventos de tipo « nuevo estado del dispositivo »
Utilizo la red Zigbee para hacer ambilight con mis lámparas, y por eso envía muchas solicitudes 
Incluso logré hacer que mi red Zigbee se estrellara.
Por lo tanto, he reducido el número de solicitudes, pero Gladys sigue teniendo problemas.
Actualmente solo tengo una escena que es un disparo programado.
Me pregunté si no sería porque Gladys registra cada nuevo valor en la base de datos.
¿Estás en un SSD o en una tarjeta SD?
Efectivamente, Gladys registra los valores en la base de datos y si estás en una tarjeta SD puede convertirse en el factor limitante.
De manera general, recomiendo encarecidamente los SSD para una instalación que dure a largo plazo.
El sistema operativo del Raspberry gira en una tarjeta SD, pero los datos de Gladys están guardados en un disco duro conectado por USB3 en el Raspberry.
¿Un disco duro con platos? Depende de la velocidad del disco, pero si intentas escribir continuamente a 6 req/segundo + leer, las consultas se pondrán en espera y notarás ralentizaciones en Gladys.
¿Cómo has configurado tu ambilight?
Efectivamente, no creo que sea una buena idea registrar datos en cada cambio de estado, además de que tu base de datos se volverá enorme.
Sí, los buenos viejos discos duros 
Tengo un servidor Express que emula la API de Philips Hue y luego envía MQTT a Zigbee. Para transmitir la pantalla uso Hyperion NG.
También lo creo, digamos, dejo que funcione 1 hora, ni siquiera puedo imaginar la cantidad de registros realizados 
¿Y Gladys recibe los eventos porque Zigbee2mqtt devuelve los valores a Gladys?
Sí, parece que Gladys escucha los dispositivos registrados en la integración Zigbee2mqtt (como el dispositivo Hue Play, por ejemplo).
Por lo tanto, todos los valores recibidos por Zigbee y que se registran en Gladys son luego recibidos por Gladys.
La ruta es:
Hypérion → Api Philips (Express) → Zigbee2Mqtt → Dispositivo && Gladys
¡Ah, ya veo!
Ya estás seguro de que es la mejor práctica golpear tanto la API de Philips Hue? (¿A nivel de vida útil de las bombillas, red Zigbee y demás?)
No conozco bien Zigbee2mqtt, no sé si es posible desactivar en Zigbee2mqtt el envío de eventos a Gladys, dejo que @cicoub13 te responda sobre eso.
Hum…en fin de cuentas, solo he recreado lo que hace Philips a través de su software Hue Sync, que permite proyectar las luces de tu pantalla en las lámparas. Habrá que ver cómo evoluciona con el tiempo, efectivamente.
Creo que sería mejor añadir un botón para desactivar el registro de los valores antiguos.
O sí, desactivar el envío de eventos, pero creo que aún así hay que poder comunicarse con Zigbee2mqtt en ambos sentidos.
Ya existe en Gladys la posibilidad de no registrar el historial de un sensor (no está en la interfaz de usuario del servicio Zigbee2mqtt, pero es una funcionalidad presente en el núcleo de Gladys), pero en tu caso no cambiará nada, ya que en todos los casos se registra el último valor (para poder mostrar el último valor en el panel de control, simplemente).
Si dejamos la posibilidad de dejar de escribir absolutamente todos los valores, cuando muestres tu panel de control, el valor mostrado será falso.
Efectivamente, siempre habrá una parte del problema, pero al menos la base de datos no se sobrecargará, ¿no?
¡Efectivamente!
Sería necesario añadir en la interfaz del servicio Zigbee2mqtt un interruptor « guardar el historial de valores », que corresponda al atributo « keep_history » de la tabla « device_feature ».
Cf código: Gladys/server/models/device_feature.js at master · GladysAssistant/Gladys · GitHub
¿Quieres encargarte del desarrollo @JeuFore?
@cicoub13 puede ayudarte a entender la estructura de la integración Zigbee2mqtt si necesitas ayuda, es quien más ha trabajado en ello
@cicoub13 He tenido un corte de energía
Al reiniciar, ya no hay z2m / mqtt
2021-06-22T14:20:11+0200 <warn> service.start.js:44 (Service.start) Unable to start service zigbee2mqtt Error: (HTTP code 301) unexpected -
at /src/server/node_modules/docker-modem/lib/modem.js:301:17
at getCause (/src/server/node_modules/docker-modem/lib/modem.js:331:7)
at Modem.buildPayload (/src/server/node_modules/docker-modem/lib/modem.js:300:5)
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:275:14)
at IncomingMessage.emit (events.js:388:22)
at endReadableNT (internal/streams/readable.js:1336:12)
at processTicksAndRejections (internal/process/task_queues.js:82:21) {
reason: undefined,
statusCode: 301,
json: <Buffer >
}
2021-06-22T14:20:11+0200 <error> index.js:20 (process.<anonymous>) uncaughtException catched: uncaughtException
2021-06-22T14:20:11+0200 <error> index.js:21 (process.<anonymous>) Error: getaddrinfo ENOTFOUND containers
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:67:26) {
errno: -3008,
code: 'ENOTFOUND',
syscall: 'getaddrinfo',
hostname: 'containers'
}
Todo está bien en Docker
Home Assistant no tiene ningún problema de conexión con el mismo servidor mqtt.
No entiendo por qué me encuentro en este estado inestable.
Me di cuenta porque la caja « Temperature in room » no tenía datos recientes
Imposible configurar el servicio (el dongle está configurado)
Mucha información, pero si necesitas algo más, no dudes en pedírmelo
EDIT: Tuve que reiniciar mi servidor (físico), eso resolvió mi problema, probablemente fue la librería dockerode la que causó el problema
Seguramente podré liberarme en los próximos días, así que ¿por qué no echarle un vistazo más de cerca?
Hola. La temperatura de las bombillas ahora está gestionada (con un deslizador bonito).
¿Podrías actualizar la imagen cicoub13/gladys:dev-zigbee2mqtt y probar de nuevo (spoiler: lo he probado y funciona muy bien)?
Debería llegar pronto a la versión disponible para todos 
Hola,
Vale, probaré la imagen este fin de semana. Pero tengo una pequeña pregunta, ¿alguien tiene problemas para crear los contenedores Zigbee a través de Gladys 
?