Ah oui la c’est chaud 
surtout que tu m’as dis que la donnée venait de Node-RED donc c’est toi qui contrôle la fréquence d’émission ?
Faut vraiment réduire, là tu tabasse inutilement Gladys !
Alors … après avoir regardé de plus près je m’étais induit moi-même en erreur en lisant la mesure de la consommation… mais en fait il s’agit d’un appareil qui est sensé mesurer la consommation de mon chauffe eau.
Donc finalement rien à voir avec l’API Solaredge (j’avais vérifié, je check toutes les minutes, donc rien de transcendant).
Et depuis pas mal de temps je comprenais pas parce qu’il ne fonctionnait plus… En fait c’est bien de lui que vient le spam !
Je vais donc tout bêtement le supprimer et voir ce qui se passe sans lui.
On verra plus tard pour le re-intégrer au réseau 
Merci beaucoup pour ton aide, j’attends de voir ce que ça donne avant de passer le sujet en résolu !! 
1 « J'aime »
Tant mieux si on a trouvé ! 
Vérifie aussi les autres capteurs aussi pour être sûr que c’est bien le seul qui pose problème, après d’après les valeurs que tu avais posté ça avait bien l’air d’être le seul
Oui d’autant que ce qui m’a mis la puce à l’oreille c’est que d’habitude je désactive l´historique de l’ intensité du signal et là il spamme aussi avec ça !
PS : ça fait 10 minutes que j’ai lancé la suppression de l’appareil… et j’en suis à seulement 30% des états supprimés ^^
1 « J'aime »
Ça purge ça purge 
1 « J'aime »
C’est bon, maintenant je vais observer et re-tester ma BDD si j’ai le moindre doute
1 « J'aime »
Fausse joie… Gladys Plus était déconnecté de nouveau ce matin. Je je pourrai investiguer que ce soir.
Par contre je ne sais pas quoi chercher à vrai dire.
Proposition hyper radicale : arrêter manuellement le container ZigBee2MQTT pendant 24h…
Je peux l’envisager même si c’est assez contraignant.
Le problème : il arrive parfois que pendant 48 / 72h tout fonctionne…
Donc faudrait que je coupe z2m pendant 5 jours pour être sûr de couvrir une période assez longue !
Aïe dommage, tu peux quand même regarder les logs complètes de Gladys ?
Ce qui m’intéresse c’est tout ce qui est autour de Socket disconnected client side. Trying to reconnect...
Un peu extrême quand même
Et niveau scène, tu n’as pas ajouté une scène qui poserait problème par hasard récemment ?
1 « J'aime »
Étant en vacances je vais attendre de revenir pour me replonger là dedans.
En attendant heureusement que j’ai un vpn pour pouvoir faire redémarrer mon container depuis ici !
1 « J'aime »
Voila un long fichier de logs, je l’ai laissé volontairement entier si cela peut aider à débuguer :
https://pastey.nasdoury.ovh/view/9zbRDyE/raw
Je vois plusieurs problèmes de déconnexions, dont un qui n’est pas suivi d’une reconnexion.
Sauf que je ne comprends absolument pas d’où cela peut venir.
Par ailleurs est-il normal que là actuellement, mon Gladys Plus étant déconnecté depuis 24h environ, l’utilisation de la RAM sur mon NUC est de plus d’1 Go ?
Lorsque je redémarre Gladys cela retombe à 250Mo environ.
Je demande au cas où !
Salut @guim31, merci pour les infos supplémentaires
Déjà je remarque que toutes les déconnections sont dûs à des pertes internet, on voit même le ping vers healthcheck échouer :
2024-07-30T11:05:05.614060982Z 2024-07-30T13:05:05+0200 <warn> index.js:914 (Socket.<anonymous>) Socket disconnected client side. Trying to reconnect...
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,
Des erreurs Telegram dans tous les sens:
2024-07-30T11:07:03.225446331Z 2024-07-30T13:07:03+0200 <warn> message.connect.js:19 (TelegramBot.<anonymous>) Telegram polling error, code = EFATAL, message = EFATAL: Error: connect ETIMEDOUT 212.27.38.252:443
Je vois que les erreurs durent 1 minute en général, et théoriquement l’instance se reconnecte ensuite :
2024-07-30T11:06:04.150166443Z 2024-07-30T13:06:04+0200 <info> index.js:884 (Socket.<anonymous>) Gladys Gateway: connected in websockets
Sauf que dans ce cas là, ce qui est étrange c’est que Telegram n’a toujours pas retrouvé la connection à posteriori de la reconnection de Gladys Plus 
En fait ce qu’il faudrait comprendre, c’est qu’est-ce qui ne marche pas chez toi en terme de réseau ? Pourquoi ces coupures ? Et est-ce que ça revient vraiment ?
Oui c’est normal, quand ton instance se déconnecte, « socket.io » (la librairie de websocket qu’on utilise) stocke en buffer tous les messages à envoyer à Gladys Plus jusqu’à que Gladys Plus se reconnecte ( Cf → Offline behavior | Socket.IO )
Ce qui fait un paquet de message en RAM qui s’accumulent.
PS: Je me dis que ça serait peut-être bien de mettre un timeout sur les messages envoyés en Websocket pour justement éviter que ça s’accumule en RAM, au bout de 30 secondes ça sert plus à rien de garder une requête websocket ^^
Mais bon je pense pas que ça soit la solution à ton problème
1 « J'aime »
Ah, en lisant tous les changelog de la lib socket.io, je suis tombé sur des trucs intéressants :
Previously, getting disconnected while waiting for an acknowledgement
would create a memory leak, as the acknowledgement was never received
and the handler would stay in memory forever.
Ca pourrait expliquer pourquoi l’usage RAM augmente beaucoup, et peut-être que ce bug empêcherait à socket.io de se reconnecter si tu accumule trop de requête lors de la déconnexion.
Je pense que je vais me noter de mettre à jour socket.io côté front Gladys Plus et côté serveur Gladys, ça pourrait résoudre ce souci de reconnexion !
(ca ne résoudra pas tes problèmes de pertes de connexion internet en revanche, donc si j’étais toi je continuerais à investiguer quand même ^^)
1 « J'aime »
Merci @pierre-gilles pour toutes ces informations.
De mon coté je pense que j’ai trouvé ce qui perturbait mon réseau !!
J’ai récemment ajouté un switch pour connecter des appareils supplémentaires dans mon salon… et il s’avère que ce switch était configuré en serveur DHCP (alors que j’étais persuadé que non, donc je n’avais même pas vérifié).
Je suis quasiment sûr que mes déconnexions venaient de là, car j’avais même remarqué que ma TV (chaines de la Freebox ou IPTV) coupaient de manière trop fréquentes ces derniers temps.
Entre ça et tes investigations, on va être au top, je reviendrai ici donner des nouvelles
2 « J'aime »
Jusqu’à hier tout allait mieux : pas de decconexion… et patatras, mon instance est déconnectée de nouveau.
Je redémarre Gladys, re-déconnecté ce matin.
Voici d’autres logs qui ne m’apprennent pas grand chose de plus j’ai l’impression.
Je vais investiguer ce problème avec Telegram que je ne comprends pas (mais je ne suis pas spammé d’erreurs comme avant… peut etre qu’il arrive d’avoir des erreurs de connexion de temps en temps ?).
Là mon instance est déconnectée, mais la RAM n’est qu’à 600Mo environ, pas non plus un truc trop extrême je pense.
Tu as sûrement regardé mais, ton deuxième serveur DHCP ne s’est pas réactivé par hasard ?
Je l’ai carrément viré de mon réseau
1 « J'aime »
@guim31 Je vois plein d’erreurs:
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
Et aussi du:
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
Tu es sûr que tes soucis de réseaux sont résolus ? Si telegram a des soucis pour se reconnecter, tu as encore des soucis à mon avis