Ah ja, das ist heiß 
vor allem, weil du mir gesagt hast, dass die Daten von Node-RED kommen, also du die Sendehäufigkeit kontrollierst?
Man muss wirklich reduzieren, du malträtierst Gladys unnötig!
Also … nachdem ich genauer hingeschaut habe, habe ich mich selbst in die Irre geführt, als ich den Verbrauch gemessen habe… aber eigentlich handelt es sich um ein Gerät, das den Verbrauch meines Boilers messen soll.
Daher hat das nichts mit der Solaredge-API zu tun (ich hatte überprüft, ich checke alle Minuten, also nichts Besonderes).
Und seit einiger Zeit habe ich nicht verstanden, warum es nicht mehr funktioniert hat… Tatsächlich kommt der Spam von ihm!
Ich werde es also einfach löschen und sehen, was ohne ihn passiert.
Wir werden später sehen, wie man es wieder ins Netzwerk integriert 
Vielen Dank für deine Hilfe, ich warte ab, was passiert, bevor ich das Thema als erledigt markiere !! 
Gut, wenn wir es gefunden haben! 
Überprüfe auch die anderen Sensoren, um sicherzugehen, dass es wirklich nur dieser eine ist, der Probleme macht. Nach den Werten, die du gepostet hattest, schien es tatsächlich nur dieser eine zu sein.
Ja, und was mich stutzig gemacht hat, ist, dass ich normalerweise den Signalstärke-Verlauf deaktiviere und jetzt spammt er auch damit!
PS: Es sind jetzt 10 Minuten her, seit ich die Gerätelöschung gestartet habe… und ich bin erst bei 30% der gelöschten Zustände ^^
Das reinigt das reinigt 
Das ist gut, jetzt werde ich beobachten und meine Datenbank nochmal testen, falls ich den geringsten Zweifel habe
Falsche Freude… Gladys Plus war heute Morgen wieder offline. Ich kann erst heute Abend nachschauen.
Aber ich weiß ehrlich gesagt nicht, wonach ich suchen soll.
Hyperradikaler Vorschlag: den ZigBee2MQTT-Container manuell für 24 Stunden anhalten…
Ich könnte es mir vorstellen, auch wenn es recht umständlich ist.
Das Problem: Manchmal funktioniert alles für 48 / 72 Stunden…
Also müsste ich z2m für 5 Tage ausschalten, um sicherzugehen, dass ich einen längeren Zeitraum abdecke!
Oh Mist, schade. Kannst du trotzdem die vollständigen Logs von Gladys anschauen?
Mich interessiert alles, was um Socket disconnected client side. Trying to reconnect... herum passiert.
Ein bisschen extrem, oder?
Und was die Szenen angeht, hast du vielleicht kürzlich eine Szene hinzugefügt, die Probleme verursachen könnte?
Da ich im Urlaub bin, werde ich warten, bis ich zurück bin, um mich wieder damit zu beschäftigen.
Zum Glück habe ich einen VPN, um meinen Container von hier aus neu zu starten!
Hier ist eine lange Logdatei, die ich absichtlich vollständig belassen habe, falls es beim Debuggen hilft:
https://pastey.nasdoury.ovh/view/9zbRDyE/raw
Ich sehe mehrere Probleme mit Abbrüchen, von denen einer nicht von einer erneuten Verbindung gefolgt wird.
Allerdings verstehe ich absolut nicht, woher das kommen könnte.
Übrigens, ist es normal, dass mein Gladys Plus, der seit etwa 24 Stunden getrennt ist, derzeit einen RAM-Verbrauch von über 1 GB hat?
Wenn ich Gladys neu starte, sinkt der Wert auf etwa 250 MB.
Ich frage nur für den Fall!
Hallo @guim31, danke für die zusätzlichen Infos
Ich sehe schon, dass alle Abmeldungen auf Internetausfälle zurückzuführen sind, sogar der Ping zu healthcheck scheitert:
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,
Überall Telegram-Fehler:
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
Ich sehe, dass die Fehler in der Regel 1 Minute dauern und die Instanz sich dann theoretisch wieder verbindet:
2024-07-30T11:06:04.150166443Z 2024-07-30T13:06:04+0200 <info> index.js:884 (Socket.<anonymous>) Gladys Gateway: connected in websockets
Aber in diesem Fall ist es seltsam, dass Telegram die Verbindung nach der erneuten Verbindung von Gladys Plus nicht wiederhergestellt hat 
Tatsächlich müsste man verstehen, was bei dir in Bezug auf das Netzwerk nicht funktioniert. Warum diese Unterbrechungen? Und kommt es wirklich wieder?
Ja, das ist normal, wenn deine Instanz sich abmeldet, speichert « socket.io » (die WebSocket-Bibliothek, die wir verwenden) alle Nachrichten, die an Gladys Plus gesendet werden sollen, im Puffer, bis Gladys Plus sich wieder verbindet (siehe → Offline behavior | Socket.IO)
Das führt zu einer Ansammlung von Nachrichten im RAM.
PS: Ich denke, es wäre vielleicht gut, eine Timeout-Funktion für die über Websocket gesendeten Nachrichten einzurichten, um zu verhindern, dass sie sich im RAM ansammeln. Nach 30 Sekunden bringt es nichts mehr, eine Websocket-Anfrage zu behalten ^^
Aber ich glaube nicht, dass das die Lösung für dein Problem ist
Ah, als ich alle Changelogs der socket.io-Bibliothek durchgelesen habe, bin ich auf einige interessante Dinge gestoßen:
Zuvor führte eine Trennung während des Wartens auf eine Bestätigung
zu einem Speicherleak, da die Bestätigung nie empfangen wurde
und der Handler für immer im Speicher blieb.
Das könnte erklären, warum der RAM-Verbrauch stark ansteigt und dieser Bug möglicherweise verhindert, dass sich socket.io neu verbindet, wenn zu viele Anfragen während der Trennung angesammelt werden.
Ich denke, ich werde mir notieren, socket.io auf der Frontend-Seite von Gladys Plus und auf dem Gladys-Server zu aktualisieren, das könnte das Problem mit der erneuten Verbindung beheben!
(Das wird deine Internetverbindungsprobleme allerdings nicht lösen, also würde ich an deiner Stelle trotzdem weiter investigieren ^^)
Danke @pierre-gilles für all diese Informationen.
Von meiner Seite denke ich, dass ich gefunden habe, was mein Netzwerk gestört hat!!
Ich habe kürzlich einen Switch hinzugefügt, um zusätzliche Geräte in meinem Wohnzimmer anzuschließen… und es stellt sich heraus, dass dieser Switch als DHCP-Server konfiguriert war (obwohl ich dachte, dass dies nicht der Fall war, also habe ich es nicht einmal überprüft).
Ich bin mir fast sicher, dass meine Abbrüche daher kamen, denn ich hatte sogar bemerkt, dass mein Fernseher (Freebox-Kanäle oder IPTV) in letzter Zeit zu häufig unterbrochen wurde.
Mit dem und deinen Untersuchungen werden wir auf dem neuesten Stand sein, ich werde hier zurückkommen und Neuigkeiten geben
Bis hierhin lief alles besser: keine Abmeldung… und dann: mein Instance ist wieder getrennt.
Ich starte Gladys neu, aber heute Morgen wieder getrennt.
Hier sind weitere Logs, die mir nicht viel mehr zu sagen scheinen.
Ich werde dieses Problem mit Telegram untersuchen, das ich nicht verstehe (aber ich werde nicht mit Fehlermeldungen überschwemmt wie früher… vielleicht gibt es manchmal Verbindungsfehler?).
Jetzt ist mein Instance getrennt, aber der RAM liegt bei etwa 600 MB, nichts Extremes, denke ich.
Du hast sicherlich geschaut, aber ist dein zweiter DHCP-Server zufällig nicht wieder aktiv geworden?
Ich habe ihn glatt aus meinem Netzwerk geworfen
@guim31 Ich sehe jede Menge Fehler:
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
Und auch das:
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
Bist du sicher, dass deine Netzwerkprobleme behoben sind? Wenn Telegram Probleme hat, sich wieder zu verbinden, hast du meiner Meinung nach immer noch Probleme.