# ToDo 10 — Verbindungsverlust erkennen und anzeigen

## Problem

Wenn der Telnet-Server (oder später die WS-Verbindung) wegbricht — kein Strom, Netzwerkausfall, Firewall-Drop — wird das weder im Container-Log noch auf der Info-Webseite angezeigt. Die Status-Seite zeigt dauerhaft „alles grün", obwohl kein Sender mehr erreichbar ist.

Die Ursache: TCP-Sockets können „still sterben". Der Socket ist auf Node.js-Seite noch offen, das `close`-Event feuert nicht (z. B. bei Firewall-Drop oder Netzwerk-Timeout), und der aktuelle Health-Check in `InfoServer.js` prüft nur `tSocket != null` — das bleibt `true`.

## Abgrenzung zu anderen ToDos

| ToDo | Thema | Überschneidung |
|---|---|---|
| **ToDo_2** | Reconnect-Strategie, Sender-Interface, `state`-Property | Fundament — ToDo_10 baut darauf auf und ergänzt den Watchdog |
| **ToDo_5** | Health-Checks in `/api/status` | Dort angelegt; ToDo_10 füllt die fehlende Tiefe |
| **ToDo_9** | Timeout bei ausbleibenden GRBL-`ok`-Antworten | Ergänzend: ToDo_9 = Protokoll-Ebene, ToDo_10 = Verbindungs-Ebene |

**Was hier neu ist:** aktiver Watchdog-Heartbeat (auch bei scheinbar offenem Socket), vollständige State-Machine mit sichtbarem Reconnect-Zyklus, und UI-Visualisierung in `public/app.js` — das deckt kein anderes ToDo ab.

**Voraussetzung:** ToDo_2 muss abgeschlossen sein (`state`-Property und Sender-Interface existieren).

---

## Hinweis: Das Problem betrifft Telnet und WebSocket gleichermaßen

Das „stille Sterben" ist kein Telnet-spezifisches Problem — es ist ein TCP-Problem. WebSocket läuft ebenfalls über TCP und hat dieselbe Schwachstelle, wenn kein aktiver Keepalive verwendet wird.

Der Unterschied liegt im verfügbaren Gegenmittel:

| Transport | Klasse | Mechanismus |
|---|---|---|
| **Telnet** | `TelnetSenderGRBL.js` | Applikations-Watchdog: Timer + Schreib-Probe (kein Protokoll-Support) |
| **WebSocket** | `WSSenderGrbl.js` | WebSocket Ping/Pong (RFC 6455, Protokollebene) — sauberer und standardisiert; aktuell **nicht** aktiviert |

`WSSenderGrbl.js` verwaltet das `ws`-WebSocket-Objekt direkt und hat bereits eine State-Machine (`state`, `reconnectAttempt`, `reconnectTimer`). Die Reconnect-Logik bei `close`- und `error`-Events ist implementiert. Was noch fehlt, ist der aktive Ping/Pong-Heartbeat für den Fall des stillen TCP-Todes.

`FluidNCClient.js` ist ein älterer, paralleler Ansatz und wird von `WSSenderGrbl.js` **nicht** verwendet.

---

## Paket 1: Watchdog im Sender

`WSSenderGrbl.js` hat bereits State-Machine und Reconnect-Logik. Offen bleibt:

- [ ] Aktiven Heartbeat einführen — nicht nur auf das `close`-Event warten
  - **WebSocket (`WSSenderGrbl.js`):** WebSocket Ping/Pong aktivieren — `ws.ping()` alle 30 s, bei ausbleibendem Pong Verbindung als tot markieren und Reconnect auslösen
  - **Telnet (`TelnetSenderGRBL.js`):** Timer + applikationsseitige Schreib-Probe, da kein Protokoll-Support
  - erkennt „stille" Socket-Tode, bei denen kein `close`-Event feuert
- [ ] State-Machine im Sender konsolidieren
  - Zustände: `connected` | `connecting` | `reconnecting` | `disconnected`
  - `reconnectAttempt` (Zähler) und `reconnectDelay` (aktuelle Wartezeit) als Properties
  - bei Verbindungsverlust: `state` → `disconnected`, Reconnect-Zyklus starten (1 min / 2 min Intervall)
- [ ] Fehlerzustand und Reconnect-Fortschritt loggbar machen
  - im Container-Log erkennbar: welcher Sender, welcher Zustand, nächster Versuch wann

## Paket 2: Status-API vertiefen

- [ ] `InfoServer.js` `/api/status` liefert echten Sender-Zustand aus der State-Machine
  - nicht mehr nur `tSocket != null`, sondern `sender.getStatus()` mit `state`, `reconnectAttempt`, `lastSeen`
  - bei `disconnected` oder `reconnecting`: `health`-Summary auf `degraded` setzen
- [ ] `lastSeen`-Timestamp pro Sender führen
  - wann wurde zuletzt erfolgreich gesendet oder eine Antwort empfangen?
  - hilft Diagnose: Sender tot seit X Sekunden

## Paket 3: UI-Visualisierung

- [ ] `public/app.js` wertet den Sender-Status aus `/api/status` aus
  - Farb-Indikator pro Sender: grün / gelb (reconnecting) / rot (disconnected)
  - bei `reconnecting`: Anzeige von Versuchs-Nummer und nächstem Retry-Zeitpunkt
- [ ] Statuswechsel sofort sichtbar machen
  - `/api/status` wird periodisch (z. B. alle 10 s) abgefragt oder per WebSocket-Push aktualisiert

## Betroffene Dateien

- `robot/TelnetSenderGRBL.js` (oder künftiger Sender) — Watchdog-Logik, State-Machine
- `server/InfoServer.js` — tieferer Status-Abruf via `getStatus()`
- `public/app.js` — Visualisierung des Verbindungszustands
- `startRobot.js` — keine Änderung erwartet, Sender-Interface bleibt gleich