WebSocket-Client
Modus, in dem sich das Gateway als Client per Outbound-Verbindung mit dem Endpoint eines externen Streaming-Servers (ws / wss) verbindet und die gepushten Nachrichten in Echtzeit empfängt.
| Situation | Welcher Modus ist zu verwenden |
|---|---|
| Ein externes IT-System sendet Werte per REST POST | HTTP-Push |
| Ein externer Streaming-Server liefert Werte per WebSocket | WebSocket-Client (diese Seite) |
| Werte einer betriebsinternen PLC werden direkt gelesen | Modbus / OPC-UA usw. |
Eingabewerte im Registrierungsformular
| Eingabefeld | Was wird eingetragen | Beispiel |
|---|---|---|
| IP-Adresse | Host des WebSocket-Servers | 192.168.10.99, stream.example.com |
| Port | Port des WebSocket-Servers (Standard: ws=80, wss=443) | 8765, 443 |
| PATH | Endpoint-Pfad (Standard /) | /stream/v1 |
| TLS | Verwendung von wss | false (ws) / true (wss) |
| SUBSCRIBE MESSAGE | Nachricht, die unmittelbar nach dem Verbindungsaufbau einmalig gesendet wird (optional) | {"op":"subscribe","topic":"line1.tempC"} |
| Erfassungsintervall | Intervall, in dem das Gateway die zwischengespeicherten Werte abholt (ms) | 1000 |
Tatsächliche Verbindungs-URL: <scheme>://<host>:<port><PATH> (z. B. ws://192.168.10.99:8765/stream/v1)
PLC-Adressnotation des Tags — 4-Mode-JSON
Wenn die vom Server gesendeten Nachrichten JSON sind, werden die Werte mit demselben 4-Mode-Decoder wie bei MQTT / Apache Kafka extrahiert.
Angenommen, der Server pusht Folgendes:
{"tempC": 25.7, "humid": 40.2, "running": true, "meta":{"unit":"degC"}}
| Modus | PLC-Adresse des Tags | Empfangener Wert |
|---|---|---|
| KEY (top-level) | tempC | 25.7 |
| KEY | humid | 40.2 |
| KEY | running | true |
| PATH (JSON Pointer) | :$.meta.unit | degC |
| RAW | _raw_ oder :_raw_ (oder leeres Feld) | Gesamte Nachricht |
| SCALAR | (wenn die Nachricht kein JSON ist) _raw_ | Nachricht unverändert |
WebSocket ist ein einzelner Kanal, daher entfällt der Topic-Teil — den vorderen Teil von : leer lassen oder einfach nur den Key verwenden.
Wenn es sich nicht um JSON handelt oder die gesamte Nachricht unverändert übernommen werden soll, _raw_ oder ein leeres Feld verwenden.
Häufige Anwendungsfälle
| Fall | Vorgehen |
|---|---|
| Cloud-Streaming-Broker (Echtzeitkurse, Wechselkurse, Wetter usw.) | Die vom Server gepushten JSON-Keys unverändert als Tag registrieren |
| ROS 2 / rosbridge_server | Verbindung über den WebSocket von rosbridge → Empfang der Topic-Nachrichten |
| Betriebsinternes eigenes Streaming-Gateway | Üblicherweise unverschlüsseltes ws 8080 / 8765 — tls=false |
| Externes Security-SaaS (Zertifikat erforderlich) | wss 443 — tls=true |
| Server verlangt einen Subscribe-Handshake | Vereinbarten Payload in SUBSCRIBE MESSAGE eintragen |
Häufige Probleme und Lösungen
| Symptom | Ursache | Lösung |
|---|---|---|
| Keine Werte kommen an | Server pusht keine Nachrichten | Mit wscat -c ws://<host>:<port><path> direkt empfangen und prüfen, ob Zeilen in der Konsole erscheinen |
| Keine Werte kommen an | Subscribe-Nachricht nicht konfiguriert (obwohl vom Server gefordert) | Serverhandbuch prüfen und SUBSCRIBE MESSAGE eintragen |
[WS] connect 실패: timeout | Firewall / Port / DNS | Prüfen, ob der Port blockiert ist und ob mit telnet / nc eine TCP-Verbindung möglich ist |
[WS] connect 실패: handshake | Fehler bei Path- / TLS-Konfiguration | URL <scheme>://<host>:<port><path> direkt verifizieren |
| TLS-Zertifikatsfehler | Selbstsigniertes Zertifikat (self-signed) | Im Produktivbetrieb offizielles Zertifikat empfohlen. Übergangsweise Systemadministrator um Aufnahme in cacerts bitten |
| Werte einzelner JSON-Keys sind leer | Nachrichtenformat ist kein JSON | Zunächst mit _raw_ empfangen und das Format prüfen |