¡Ah sí, eso es intenso 
! Sobre todo porque me dijiste que los datos venían de Node-RED, así que eres tú quien controla la frecuencia de emisión, ¿no?
¡Realmente hay que reducirlo! Ahora mismo estás machacando a Gladys sin necesidad.
Entonces… después de mirar más de cerca me equivoqué al leer la medida del consumo… pero en realidad se trata de un dispositivo que está diseñado para medir el consumo de mi calentador de agua.
Por lo tanto, al final no tiene nada que ver con la API de Solaredge (lo había verificado, lo reviso cada minuto, así que nada del otro mundo).
Y durante mucho tiempo no entendía por qué ya no funcionaba… ¡En realidad, el spam viene de él!
Por lo tanto, simplemente lo voy a eliminar y ver qué pasa sin él.
Ya veremos más adelante para volver a integrarlo en la red 
¡Muchas gracias por tu ayuda, esperaré a ver qué pasa antes de marcar el tema como resuelto!! 
¡Mejor aún si lo hemos encontrado! 
Verifica también los otros sensores para asegurarte de que es el único que tiene problemas. Según los valores que publicaste, parecía ser el único.
Sí, y más aún, lo que me hizo sospechar fue que normalmente desactivo el historial de la intensidad de la señal y ahora también me está saturando con eso.
PD: Llevó 10 minutos eliminando el dispositivo… y solo he eliminado el 30% de los estados ^^
¡Purga, purga! 
Vale, ahora voy a observar y re-probar mi base de datos si tengo la menor duda
Falsa alegría… Gladys Plus se desconectó de nuevo esta mañana. No podré investigar hasta esta noche.
Por otro lado, no sé qué buscar, la verdad.
Propuesta hiper radical: detener manualmente el contenedor ZigBee2MQTT durante 24 horas…
Puedo considerarlo, aunque es bastante restrictivo.
El problema: a veces pasa que durante 48 / 72 horas todo funciona…
¡Así que tendría que desconectar z2m durante 5 días para asegurarme de cubrir un período lo suficientemente largo!
¡Vaya, qué pena! ¿Puedes mirar los logs completos de Gladys de todos modos?
Lo que me interesa es todo lo relacionado con Socket disconnected client side. Trying to reconnect...
Un poco extremo, ¿no?
¿Y en cuanto a las escenas, no has añadido alguna escena que pueda causar problemas últimamente?
Como estoy de vacaciones, voy a esperar a volver para volver a sumergirme en esto.
Mientras tanto, afortunadamente tengo un VPN para poder reiniciar mi contenedor desde aquí.
Aquí tienes un largo archivo de registros, lo he dejado intencionalmente completo por si puede ayudar a depurar:
https://pastey.nasdoury.ovh/view/9zbRDyE/raw
Veo varios problemas de desconexiones, uno de los cuales no es seguido de una reconexión.
El problema es que no entiendo de dónde puede venir.
Por otro lado, ¿es normal que actualmente, con mi Gladys Plus desconectado durante unas 24 horas, el uso de la RAM en mi NUC sea de más de 1 GB?
Cuando reinicio Gladys, baja a unos 250 MB.
¡Pregunto por si acaso!
Hola @guim31, gracias por la información adicional
Ya noto que todas las desconexiones se deben a pérdidas de Internet, incluso vemos que el ping a healthcheck falla:
2024-07-30T11:05:05.614060982Z 2024-07-30T13:05:05+0200 <warn> index.js:914 (Socket.<anonymous>) Socket desconectado del lado del cliente. Intentando reconectar...
2024-07-30T11:05:22.432354725Z 2024-07-30T13:05:22+0200 <warn> scene.executeActions.js:37 (executeAction) AxiosError: getaddrinfo EAI_AGAIN hc-ping.com
2024-07-30T11:05:22.432399450Z at Function.AxiosError.from (/src/server/node_modules/axios/lib/core/AxiosError.js:89:14)
2024-07-30T11:05:22.432406693Z at RedirectableRequest.handleRequestError (/src/server/node_modules/axios/lib/adapters/http.js:518:25)
2024-07-30T11:05:22.432411380Z at RedirectableRequest.emit (node:events:529:35)
2024-07-30T11:05:22.432415768Z at ClientRequest.eventHandlers.<computed> (/src/server/node_modules/follow-redirects/index.js:14:24)
2024-07-30T11:05:22.432420731Z at ClientRequest.emit (node:events:517:28)
2024-07-30T11:05:22.432457075Z at TLSSocket.socketErrorListener (node:_http_client:501:9)
2024-07-30T11:05:22.432463594Z at TLSSocket.emit (node:events:517:28)
2024-07-30T11:05:22.432468263Z at emitErrorNT (node:internal/streams/destroy:151:8)
2024-07-30T11:05:22.432472552Z at emitErrorCloseNT (node:internal/streams/destroy:116:3)
2024-07-30T11:05:22.432476961Z at processTicksAndRejections (node:internal/process/task_queues:82:21) {
2024-07-30T11:05:22.432481377Z hostname: 'hc-ping.com',
2024-07-30T11:05:22.432485603Z syscall: 'getaddrinfo',
2024-07-30T11:05:22.432489776Z code: 'EAI_AGAIN',
2024-07-30T11:05:22.432493912Z errno: -3001,
Errores de Telegram por todas partes:
2024-07-30T11:07:03.225446331Z 2024-07-30T13:07:03+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Error de sondeo de Telegram, código = EFATAL, mensaje = EFATAL: Error: connect ETIMEDOUT 212.27.38.252:443
Veo que los errores duran generalmente 1 minuto, y teóricamente la instancia se reconecta después:
2024-07-30T11:06:04.150166443Z 2024-07-30T13:06:04+0200 <info> index.js:884 (Socket.<anonymous>) Gladys Gateway: conectado en websockets
Pero en este caso, lo extraño es que Telegram aún no ha recuperado la conexión después de la reconexión de Gladys Plus 
En realidad, lo que hay que entender es qué no funciona en tu red. ¿Por qué estas interrupciones? ¿Y realmente vuelve a funcionar?
Sí, es normal. Cuando tu instancia se desconecta, « socket.io » (la biblioteca de websocket que usamos) almacena en el búfer todos los mensajes para enviar a Gladys Plus hasta que Gladys Plus se reconecte (ver → Offline behavior | Socket.IO)
Esto genera un paquete de mensajes en la RAM que se acumulan.
PD: Creo que sería buena idea poner un tiempo de espera en los mensajes enviados por WebSocket para evitar que se acumulen en la RAM. Después de 30 segundos, ya no sirve de nada mantener una solicitud WebSocket ^^
Pero bueno, no creo que sea la solución a tu problema
Ah, al leer todos los changelogs de la librería socket.io, me encontré con cosas interesantes:
Antes, si te desconectabas mientras esperabas un reconocimiento,
se producía una fuga de memoria, ya que el reconocimiento nunca se recibía
y el controlador permanecía en la memoria para siempre.
Esto podría explicar por qué el uso de RAM aumenta mucho, y quizás este error impida que socket.io se reconecte si acumulas demasiadas solicitudes durante la desconexión.
Creo que voy a anotarme actualizar socket.io en el lado del cliente Gladys Plus y en el lado del servidor Gladys, ¡esto podría resolver este problema de reconexión!
(esto no resolverá tus problemas de pérdida de conexión a Internet, por lo que si fuera tú, seguiría investigando de todos modos ^^)
Gracias @pierre-gilles por toda esta información.
Por mi parte, creo que he encontrado lo que estaba perturbando mi red !!
Recientemente añadí un switch para conectar dispositivos adicionales en mi sala de estar… y resulta que este switch estaba configurado como servidor DHCP (cuando estaba convencido de que no, por lo que ni siquiera lo había verificado).
Estoy casi seguro de que mis desconexiones venían de ahí, ya que incluso había notado que mi TV (canales de la Freebox o IPTV) se cortaban con demasiada frecuencia últimamente.
Entre esto y tus investigaciones, vamos a estar en la cima, volveré aquí para dar noticias
Hasta aquí todo iba mejor: sin desconexión… y de repente, mi instancia se ha desconectado de nuevo.
Reinicio Gladys, desconectado de nuevo esta mañana.
Aquí hay otros registros que no me parecen que me digan mucho más, la verdad.
Voy a investigar este problema con Telegram que no entiendo (pero ya no me están inundando de errores como antes… ¿quizá a veces hay errores de conexión?)
Ahora mismo mi instancia está desconectada, pero la RAM está alrededor de 600Mo, no es nada extremo, creo.
Seguramente has mirado, pero, ¿tu segundo servidor DHCP no se ha reactivado por casualidad?
Lo he borrado directamente de mi red
@guim31 Veo muchos errores:
2024-08-06T01:12:21.980588980Z 2024-08-06T03:12:21+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
2024-08-06T01:12:22.309015994Z 2024-08-06T03:12:22+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
2024-08-06T01:12:22.640530705Z 2024-08-06T03:12:22+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
2024-08-06T01:12:22.969901142Z 2024-08-06T03:12:22+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
2024-08-06T01:12:23.300108257Z 2024-08-06T03:12:23+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
2024-08-06T01:12:23.630625049Z 2024-08-06T03:12:23+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = ETELEGRAM, message = ETELEGRAM: 502 Bad Gateway
Y también esto:
2024-08-06T01:05:51.211667212Z 2024-08-06T03:05:51+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = EFATAL, message = EFATAL: Error: read ECONNRESET
¿Estás seguro de que tus problemas de red están resueltos? Si Telegram tiene problemas para reconectarse, creo que aún tienes problemas.