Eigene WebSocket Nachrichten

Hallo,

Ich habe eine Webseite die über WebSocket mit Symcon kommuniziert und ein selbstgeschriebenes Modul. Ist es möglich in dem Modul eine Nachricht über WebSocket zu versenden? Und wenn ja, wie?

Wer ist Client und wer Server?
Symcon kann als IO Websocket Client und ja, da kannst du wie immer über den Datenaustausch senden/empfangen.
Michael

Symcon ist in dem Fall der Server

D.h. du hast einen Webhook in Symcon, an welchen du die Daten empfängst?
Dann benutze doch einfach die Funktionen für das WebHook-Control :slight_smile:

Michael

Ich muss das Thema nochmal nach vorne holen, da ich irgendwie auf dem Schlauch stehe. Über welchen Kanal/ javascript-Befehl kann ich die Nachricht beim Client empfangen? Ich war davon ausgegangen, dass das über den WebSocket funktioniert. Da sehe ich die Nachricht aber nicht.
Normalerweise nutze ich

var connection = new WebSocket('wss://127.0.0.1:3777/wfc/12345/api/', [encodeURIComponent(btoa('webfront:webfrontpw'))]);

habe aber alternativ auch

var connection = new WebSocket('wss://127.0.0.1:3777/api/', [encodeURIComponent(btoa('email:fernzugriffpw'))]);

probiert. Ich finde die gesendete Nachricht aber nicht im Datenstrom. Was muss ich tun?

Grüße
Jürgen

ich habe mir jetzt mit einem leeren WebFront und

WFC_SendNotification($webFrontID, "VM_UPDATE", json_encode($msg),"",1);

geholfen. Das funktioniert soweit sehr gut. Dennoch würde mich interessieren, wie der Befehl

WC_PushMessage(12345, "/hook/test/", "Hallo Welt");

gedacht ist. Wie man damit sendet, ist ja gut beschrieben und das funktioniert auch. Aber wie kann ich die Nachricht am Hook-Client empfangen? @paresy kannst du das kurz erläutern?

Grüße
Jürgen

Na der Client muss sich auch auf /hook/test verbinden und nicht auf die Symcon API.
Michael

Das heißt auf

var connection = new WebSocket('wss://127.0.0.1:3777/hook/test/', []);

(also ohne api und ohne Passwort)? Das muss ich gleich nochmal ausprobieren. Auf /hook/test war ich gekommen, hatte da aber noch /api/ angehängt und dann kam da nichts…
Danke
Jürgen

Ja. Der webhook ist davon unabhängig.
Eine Authentifizierung muss man selbst realisieren.
Beispiel dazu gibt es ja in der Symcon Doku des webhook.
Michael

Ja, die webhook-Authentifizierung habe ich umgesetzt. Das ist kein Problem. Beim WebSocket hätte ich keine Idee, wie das funktionieren könnte….

prima, Daten kommen an. :smiley: Dann fehlt nur die Umsetzung des Passworts für den WebSocket.

Kannst du mir da auf die Sprünge helfen?
Grüße
Jürgen

Habe es mit dem websocket nie getestet. Allerdings sollte es wie bei der http Authentifizierung gehen.
Wobei ich jetzt nicht weiß, woher das Script wissen soll ob es eine neue Verbindung ist, oder eine bestehende.

Michael

ja genau. Die Authentifizierung muss beim Anmelden des Clients an den WebSocket passieren. Da müsste es einen Befehl, wie

WC_SetPassCode(12345, "/hook/test/","ganzGeheim");

geben. Den kenne ich aber nicht. @paresy gibt es da etwas, oder könntest du so einen Befehl ergänzen?

Grüße
Jürgen

Ne, wieso?
Der Client sendet die Zugangsdaten und im Script hier dem Webhook musst du das auswerten.
Die werden auch nur beim Verbindungsaufbau vom Client gesendet. Danach ist es ja eine stehende Verbindung.
Die Frage ist halt, wie kannst du im Script erkennen ob die Verbindung neu ist (also mit Zugangsdaten) oder vorhanden (keine Ahnung was dann in $_SERVER steht).
Michael

das ist ja cool. Mit welchem Befehl kann ich die lesen?

Schau mal hier:

Michael

sorry, das habe ich jetzt nochmals intensiv durchgelesen. Aber zum Absichern des WebSockets finde ich da nichts. Jeder, der möchte, kann sich auf den Kanal draufschalten und die Nachrichten vom Server empfangen.

So ca in der Mitte…

Ein Beispiel wie eine automatische Authentifizierung über das Modul Control verwirklicht wurde.
Als Nutzername wurde „Symcon“ und als Passwort wurde „passwort“ gewählt.

das ist für den WebHook, aber nicht für den WebSocket

Ja, ich würde aber erwarten das beim Verbindungsaufbau auch das Verarbeitungsskript getriggert wird (was aktuell nicht passiert) und nicht nur beim Datenempfang.
@paresy Warum kann man hier nicht eingreifen und z.B. Clients mit header('HTTP/1.0 401 Unauthorized'); abwerfen, bevor Symcon das Upgrade der Connection bestätigt?

Michael