README und Testkonfiguration für lokalen Simulationsaufbau aktualisieren

README.md

@@ -159,11 +159,13 @@ Die gemeinsame Client-Architektur ist bereits auf eine
 plattformabhängige Implementierung der virtuellen seriellen
 Schnittstelle vorbereitet.
 
-Die Windows-Implementierung der virtuellen seriellen Schnittstelle ist
+Unter Windows wird dieselbe gemeinsame Client- und Konfigurationslogik
-noch nicht vollständig implementiert.
+verwendet. Für Tests können vorhandene virtuelle COM-Port-Verbindungen
+verwendet werden.
 
-Der spätere Windows-Client soll dieselbe gemeinsame Client- und
+Mit Version `v0.0.11` wurde der Windows-Client mit funktionierender
-Konfigurationslogik verwenden.
+Fyne-GUI sowie der automatischen Übertragung der konfigurierten Rotor-
+Startbytes praktisch getestet.
 
 ## Server
 
@@ -414,6 +416,227 @@ vollständigen Bytebereich von `0x00` bis `0xFF` geprüft.
 Dabei wurde die bidirektionale Übertragung aller 256 möglichen Bytewerte
 erfolgreich getestet.
 
+## Vollständiger Simulationsaufbau auf einem Ubuntu-PC
+
+Der komplette Datenweg kann für Entwicklung und Tests auf einem einzigen
+Ubuntu-PC ausgeführt werden. Dazu laufen gleichzeitig drei Programme:
+
+1. `rs2322tcp-pty-test` als simuliertes Rotorgerät
+2. `rs2322tcp-server` mit `configs/server-test.json`
+3. `rs2322tcp-client`
+
+Der Datenweg ist:
+
+```text
+Testprogramm oder Hersteller-Software
+              │
+              ▼
+      /dev/ttyUSB100
+              │
+              ▼
+       rs2322tcp-client
+              │ TCP
+              ▼
+       rs2322tcp-server
+              │
+              ▼
+          /dev/pts/N
+              │
+              ▼
+   rs2322tcp-pty-test
+   simuliertes Rotorgerät
+```
+
+### 1. PTY-Simulator starten
+
+In einem ersten Terminal:
+
+```bash
+cd ~/rs2322tcp
+go run ./cmd/rs2322tcp-pty-test
+```
+
+Beispiel:
+
+```text
+rs2322tcp-pty-test
+Port: /dev/pts/1
+Modus: Rotor-Simulation mit Echo-Fallback
+Warte auf Daten ...
+```
+
+Der ausgegebene PTY-Pfad wird im nächsten Schritt benötigt.
+
+Der Simulator hält Master und Slave während seiner gesamten Laufzeit geöffnet.
+Bei der bekannten Rotor-Anfrage wird automatisch die konfigurierte Rotor-Antwort
+gesendet. Alle anderen Daten werden als Echo zurückgegeben.
+
+### 2. Testkonfiguration des Servers anpassen
+
+In `configs/server-test.json` wird der Rotor auf den aktuell vom Simulator
+ausgegebenen PTY-Slave gesetzt.
+
+Beispiel:
+
+```json
+{
+    "id": "rotor",
+    "name": "Antennenrotor",
+    "serial_port": "/dev/pts/1",
+    "baud_rate": 600,
+    "data_bits": 8,
+    "parity": "none",
+    "stop_bits": 1
+}
+```
+
+Die PTY-Nummer ist nicht dauerhaft fest. Nach jedem neuen Start des
+PTY-Simulators muss der tatsächlich ausgegebene `/dev/pts/N`-Pfad geprüft und
+gegebenenfalls manuell in `server-test.json` eingetragen werden.
+
+Im Echtbetrieb wird hier wieder ein fester Hardware-Port verwendet, zum Beispiel:
+
+```text
+/dev/ttyUSB0
+```
+
+Die serverseitige Zuordnung bleibt bewusst manuell und fest konfiguriert, weil
+mehrere unterschiedliche Hardwaregeräte gleichzeitig am Server angeschlossen
+sein können.
+
+### 3. Server starten
+
+In einem zweiten Terminal:
+
+```bash
+cd ~/rs2322tcp
+go run ./cmd/rs2322tcp-server -config ./configs/server-test.json
+```
+
+Beispiel:
+
+```text
+rs2322tcp-server dev
+Control-Server gestartet auf [::]:5000
+Geräte: 3
+```
+
+### 4. Server-Monitor als Sniffer
+
+Ist in der Server-Konfiguration
+
+```json
+"serial_monitor": true
+```
+
+gesetzt, protokolliert der Server den übertragenen Datenverkehr. Im
+Simulationsaufbau werden dadurch unter anderem die Richtungen
+
+```text
+TCP RX
+SERIAL TX
+SERIAL RX
+TCP TX
+```
+
+sichtbar.
+
+Ein typischer Ablauf ist:
+
+```text
+TCP RX     57 00 00 00 00 00 00 00 00 00 00 1F 20
+SERIAL TX  57 00 00 00 00 00 00 00 00 00 00 1F 20
+SERIAL RX  57 07 01 06 00 01 03 06 02 00 01 20
+TCP TX     57 07 01 06 00 01 03 06 02 00 01 20
+```
+
+Der Server arbeitet damit gleichzeitig als Monitor beziehungsweise Sniffer für
+den übertragenen seriellen Datenverkehr.
+
+### 5. Client-Konfiguration für den lokalen Test
+
+Für den lokalen Test kann `configs/client.json` beispielsweise so aussehen:
+
+```json
+{
+    "server": {
+        "address": "127.0.0.1",
+        "port": 5000
+    },
+    "virtual_port_range": {
+        "first": 100,
+        "last": 199
+    },
+    "virtual_ports": [
+        {
+            "port": "/dev/ttyUSB100",
+            "remote_device": "rotor",
+            "startup_bytes": "57 00 00 00 00 00 00 00 00 00 00 1F 20"
+        }
+    ]
+}
+```
+
+Der öffentliche virtuelle Port `/dev/ttyUSB100` muss vorher wie im Abschnitt
+zur manuellen Einrichtung der virtuellen Ports einmalig angelegt worden sein.
+
+### 6. Client starten
+
+In einem dritten Terminal:
+
+```bash
+cd ~/rs2322tcp
+go run ./cmd/rs2322tcp-client
+```
+
+Nach erfolgreichem Verbindungsaufbau werden die konfigurierten `startup_bytes`
+automatisch zum zugeordneten Rotor übertragen.
+
+Der Server-Monitor muss dann den vollständigen Ablauf
+
+```text
+TCP RX -> SERIAL TX -> SERIAL RX -> TCP TX
+```
+
+zeigen.
+
+Damit ist der gesamte Datenweg vom virtuellen Client-Port über TCP zum
+simulierten Rotor und wieder zurück geprüft.
+
+### 7. Virtuellen Port direkt testen
+
+Eine Antwort kann beispielsweise mit
+
+```bash
+cat /dev/ttyUSB100 | xxd -g 1
+```
+
+beobachtet werden.
+
+In einem zweiten Terminal kann eine Rotor-Anfrage gesendet werden:
+
+```bash
+printf '\x57\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1f\x20' > /dev/ttyUSB100
+```
+
+Der Rückweg erfolgt über denselben vollständigen Datenpfad zurück zu
+`/dev/ttyUSB100`.
+
+### Hinweis zu `/dev/pts/N`
+
+`/dev/pts/N` wird in diesem Aufbau ausschließlich als temporärer Test-Port
+für den PTY-Simulator verwendet. Die Nummer ist nicht dauerhaft und kann sich
+nach einem Neustart des Simulators ändern.
+
+Im produktiven Betrieb sind die serverseitigen Geräte dagegen echte,
+fest angeschlossene Hardware-Schnittstellen, beispielsweise:
+
+```text
+/dev/ttyUSB0
+/dev/ttyUSB1
+/dev/ttyUSB3
+```
+
 ## Diagnose und Logging
 
 Für Debugging und Diagnose soll eine Protokollierung des übertragenen
@@ -423,8 +646,9 @@ Insbesondere soll eine Darstellung der übertragenen Bytes möglich sein,
 um Probleme bei der Kommunikation zwischen Hersteller-Software und Gerät
 analysieren zu können.
 
-Während der Entwicklung kann `socat` als zusätzliches Werkzeug für Tests
+Für die Linux-PTY-Funktion und den beschriebenen Simulationsaufbau wird
-und Diagnose eingesetzt werden.
+`rs2322tcp` ohne `socat` betrieben. Die benötigten PTYs werden direkt aus Go
+erzeugt.
 
 ## Hardwaretest mit SPID Rot2Prog
 
@@ -659,8 +883,8 @@ Für die Entwicklung existiert zusätzlich das separate Testprogramm:
 ~/rs2322tcp-pty-test
 ```
 
-Es erzeugt unter Linux ein PTY, setzt den Slave in den Raw Mode und zeigt
+Es erzeugt unter Linux ein PTY, setzt den Slave in den Raw Mode und stellt
-den Namen des Slave-Gerätes an.
+eine simulierte serielle Gegenstelle bereit.
 
 Beispiel:
 
@@ -782,8 +1006,11 @@ git status
 ```text
 rs2322tcp/
 ├── cmd/
+│   ├── com0com-test/
 │   ├── rs2322tcp-client/
+│   ├── rs2322tcp-client-test/
 │   ├── rs2322tcp-device-sim/
+│   ├── rs2322tcp-pty-test/
 │   └── rs2322tcp-server/
 ├── configs/
 ├── docs/

configs/client.json

@@ -1,6 +1,6 @@
 {
     "server": {
-        "address": "192.168.178.229",
+        "address": "127.0.0.1",
         "port": 5000
     },
     "virtual_port_range": {

configs/server-test.json

@@ -6,7 +6,7 @@
 
     "hardware_error_response": "ERROR - HARDWARE NOT AVAILABLE",
 
-    "serial_monitor": true,
+    "serial_monitor": false,
 
     "devices": [
         {
@@ -21,7 +21,7 @@
         {
             "id": "rotor",
             "name": "Antennenrotor",
-            "serial_port": "/dev/pts/0",
+            "serial_port": "/dev/pts/1",
             "baud_rate": 600,
             "data_bits": 8,
             "parity": "none",