# ToDo 2 — Anbindung

## Ziel der Verbesserung

Die Anbindung soll zuverlässig werden: WebSocket-Eingaben, Steuerlogik und Sender müssen klar verbunden und sauber orchestriert sein.

Dieses ToDo konzentriert sich auf die technische Integration der Komponenten, nicht auf G-Code-Parsing oder Konfiguration.
## Paket 1: Start/Orchestrierung

- [x] `startRobot.js` als Orchestrator behandeln
  - Erzeugung und Verbindung der Module
  - keine Geschäftslogik im Start-Skript
- [x] Bindung der WebSocket-Eingabe an die Steuerlogik
  - `InputWS.js` empfängt Nachrichten
  - Delegation an den Parser / Controller
- [x] Sauberes Fehler- und Status-Reporting beim Start
  - fehlende Zertifikate
  - fehlende Senderverbindungen

## Paket 2: Sender-Schicht (Option C)

- [x] Sender-Interface definieren
  - `connect()`
  - `send(command)`
  - `getStatus()`
  - `disconnect()`
- [x] `TelnetSenderGRBL` als konkrete Implementierung
  - async `connect()`-Methode
  - eindeutiger Verbindungsstatus, nicht nur `this.tSocket`
  - reconnect/backoff-Strategie (→ `FluidNCClient.js` hat eine funktionierende Reconnect-Logik, die als Referenz dienen kann)
  - saubere Fehlerlogs
  - **Bug:** `close`-Event-Handler nutzt falsche `this`-Bindung — siehe `doc/ToDo_8_Bugs.md` Bug 1
- [x] Sender-Schicht testbar und austauschbar machen
  - später können andere Sender als `TelnetSenderGRBL` angehängt werden

## Paket 3: Status- und Info-Anbindung

- [x] `InfoServer.js` meldet nicht nur Weboberfläche, sondern auch Senderstatus
- [x] `/api/status` erweitert um Senderverbindungen und Health-Informationen
- [x] `/api/position` liefert aktuelle Roboterposition unabhängig von laufenden Verbindungen

## Hinweis

- Parsing, Konfiguration, Datei-Management und Tests werden getrennt in eigenen `doc/ToDo_*.md`-Dateien behandelt.
- Event-basierte Architektur ist aktuell nicht vorgesehen; die Umsetzung folgt Option A mit einer klaren Sender-Interface-Schicht.
- Die Entscheidung Telnet vs. FluidNC-WebSocket (siehe `robot/fluidnc/FluidNCClient.js`) sollte hier fallen — `FluidNCClient` ist bidirektional und hat Reconnect-Logik, was `ToDo_9` (Hardware-Feedback-Loop) direkt ermöglicht.