WebSocket via DevIO?

[Dr. Boris Neubert]

Schalte mich mal ein mit Verweis auf https://forum.fhem.de/index.php?topic=111718.new#new

Die Änderung an HttpUtils.pm in Revision 22027 vom 25.05.2020 führt dazu, dass Kalender von Nextcloud nicht mehr abgerufen werden können. Dreht man HttpUtils.pm auf Revision 21529 zurück, ist alles wieder gut (bei sonst aktuellem FHEM).

Soll ich auf einen Patch warten, der sich aus diesem Thema hier wohl noch ergeben wird, oder soll ich mit ins Debugging einsteigen?

[KölnSolar]

Websocket funktioniert mit der vorgeschlagenen Änderung noch..

@Rudi: Danke für Deine Erweiterungen. Ich nimmersatt hab dann noch ein weiteres Problem. Der TLS-Aufbau macht Probleme. Das hatte ich vorher durch den SSL-Parameter SSL_verify_mode=>0 umgangen. Da wir uns ja im lokalen Netz bewegen, fand ich das iO. Würde das automatisch berücksichtigt, wenn es ein attr SSLargs im device gäbe ?  Hatten wir das nicht bei irgendeinem Modul ? Ich finds aber nicht, sonst würde ich es mal ausprobieren...

[rudolfkoenig]

@Boris: ich wuerde gerne ein Response-Header sehen.
@KölnSolar: per Voreinstellung ist SSL_verify_mode 0. DevIo.pm reicht aber ab sofort $hash->{sslargs} weiter, damit kann man es ueberschreiben und weitere SSL Parameter setzen.

[KölnSolar]

Bin zwar nicht Boris, aber hab dann versucht zu unterstützen. Im Header findet sich ein Connection: Upgrade, Keep-Alive
Also meinen Vorschlag

Scheinbar ist im Fehlerfall Connection:\s*Upgrade im Header enthalten. Für den Zweck der Änderung(für DevIo mit websocket), müsste stattdessen Upgrade:\s*websocket in Zeile 698 geändert werden und den Fehler verhindern.

umsetzen ?

[rudolfkoenig]

Danke fuer den Link, habe HttpUtils.pm geaendert.
Ich wollte dein Vorschlag nicht ignorieren, sondern vorher den Problemfall selbst verstehen.

[KölnSolar]

Mit dem SamsungAV komme ich noch nicht so richtig weiter. Tw. liegt es an mir  , das gucke ich mir heute Abend in Ruhe mal über Wireshark an. Mir fehlt aber auch eine Info, die der TV im Rahmen des websocket-Aufbaus schickt. Nach der websocket-Bestätigungsresponse schickt er sofort eine weitere response, die das wichtige UserToken enthält. Das wird mir aber nicht über die ReadFn angeboten. Ich spekuliere, dass das möglicherweise im response-frame mitgeschickt wird. Zum Verständnis, was ich früher gemacht habe

$socket = IO::Socket::SSL->new(PeerAddr=>"$dev:$port", SSL_verify_mode=>0,Timeout=>2, Blocking=>1, ReuseAddr=>1);
.
.
wenn erfolgreich, Aufbau des Headers mit zwischengespeichertem UserToken(ohne lehnt der TV die Verbindung ab)
.
.
syswrite $socket, $webclient_header;
.
.
sysread $socket, my $buf, 10240;
(bei Erfolg, wird die "first" response eingelesen)
.
.
.
sysread $socket, $buf, 10240;
(hier bekam ich mit der "second" response per JSON das UserToken
.
.
websocket Aufbau erfolgreich u. es kann der Befehl an den TV gesendet werden

im Log sah das dann so aus

2020.06.05 11:37:32 5: [SamsungAV] Fernseher send to TV: GET /api/v2/channels/samsung.remote.control?name=unwichtig==&token=UserToken HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localIP:8002
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13


2020.06.05 11:37:32 5: [SamsungAV] Fernseher first websocket response: HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=


2020.06.05 11:37:32 5: [SamsungAV] Fernseher Statusbytes of second websocket response: 817e0115
2020.06.05 11:37:32 5: [SamsungAV] Fernseher data of second websocket response: {"data":{"clients":[{"attributes":{"name":"unwichtig","token":"UserToken"},"..."}

2020.06.05 11:37:32 4: [SamsungAV] Fernseher sending 1
2020.06.05 11:37:32 5: [SamsungAV] Fernseher send payload: {"method":"ms.remote.control","params":{"TypeOfRemote":"SendRemoteKey","DataOfCmd":"KEY_1","Option":"false","Cmd":"Click"}}

Wobei das damals wider besseren Wissens "Statusbytes of second websocket response" genannte, nach heutigem Kenntnisstand die framing bytes der response sind, also FIN=0x01,Opcode=0x01,nicht maskiert,Länge > 125, 16bit-payloadlength. Aber dann hätte ich die doch per ReadFn angeboten bekommen müssen ?
Ne Idee, wo es hängt ?

Grüße Markus

[rudolfkoenig]

Aber dann hätte ich die doch per ReadFn angeboten bekommen müssen ?
Ne Idee, wo es hängt ?

Ja.
Nein. :/

[Dr. Boris Neubert]

Danke fuer den Link, habe HttpUtils.pm geaendert.
Ich wollte dein Vorschlag nicht ignorieren, sondern vorher den Problemfall selbst verstehen.

Gerade wurde bestätigt, dass das Calendar-Modul nun wieder auf Nextcloud-Kalender zugreifen kann.

Danke für die Anpassung, Rudi.

Ich melde mich aus diesem Thema ab.

Viele Grüße
Boris

[HomeAuto_User]

@Rudi 

Danke fuer den Link, habe HttpUtils.pm geaendert.
Ich wollte dein Vorschlag nicht ignorieren, sondern vorher den Problemfall selbst verstehen.

Hallo,
seit der Änderung habe ich ein sehr eigenartiges Verhalten.

Meine SIGNALduino Devices welche bis gestern mit

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600
definiert waren bringen seit dem Update heute einen FHEM Crash hervor.

Wenn ich diese nun auf die DEF

Code Auswählen Erweitern

/dev/ttyUSB0@57600
ändere geht dies vorübergehend aber 2 Devices bei mir haben die selbe ID. (daher DEF bei path)

LANGE suchte ich die URSACHE und ich habe nun auch im SVN gesehen die HttpUtils.pm wurde geändert und seit dem heutigen Update ist das Verhalten.
Bis gestern ging es.

Nun versuchte ich die DEF auf

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600
zurück zu ändern aber ich erhalte nun einen RETURN aus dem HttpUtils.pm Modul 

Code Auswählen Erweitern

    return "$hash->{displayurl}: malformed or unsupported URL";

Kurzum

Code Auswählen Erweitern

  if($hash->{url} !~ /
      ^(http|https):\/\/                # $1: proto
       (([^:\/]+):([^:\/]+)@)?          # $2: auth, $3:user, $4:password
       ([^:\/]+|\[[0-9a-f:]+\])         # $5: host or IPv6 address
       (:\d+)?                          # $6: port
       (\/.*)$                          # $7: path
    /xi) {
    return "$hash->{displayurl}: malformed or unsupported URL";
  }

akzeptiert nicht die Eingabe

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600.

Ich erbitte einen Blick darüber.

MfG

EDIT: Sorry, fand auch nun https://forum.fhem.de/index.php/topic,111832.msg1061157.html#msg1061157

[CoolTux]

@Rudi 
Hallo,
seit der Änderung habe ich ein sehr eigenartiges Verhalten.

Meine SIGNALduino Devices welche bis gestern mit

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600
definiert waren bringen seit dem Update heute einen FHEM Crash hervor.

Wenn ich diese nun auf die DEF

Code Auswählen Erweitern

/dev/ttyUSB0@57600
ändere geht dies vorübergehend aber 2 Devices bei mir haben die selbe ID. (daher DEF bei path)

LANGE suchte ich die URSACHE und ich habe nun auch im SVN gesehen die HttpUtils.pm wurde geändert und seit dem heutigen Update ist das Verhalten.
Bis gestern ging es.

Nun versuchte ich die DEF auf

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600
zurück zu ändern aber ich erhalte nun einen RETURN aus dem HttpUtils.pm Modul 

Code Auswählen Erweitern

    return "$hash->{displayurl}: malformed or unsupported URL";

Kurzum

Code Auswählen Erweitern

  if($hash->{url} !~ /
      ^(http|https):\/\/                # $1: proto
       (([^:\/]+):([^:\/]+)@)?          # $2: auth, $3:user, $4:password
       ([^:\/]+|\[[0-9a-f:]+\])         # $5: host or IPv6 address
       (:\d+)?                          # $6: port
       (\/.*)$                          # $7: path
    /xi) {
    return "$hash->{displayurl}: malformed or unsupported URL";
  }

akzeptiert nicht die Eingabe

Code Auswählen Erweitern

/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.3:1.0-port0@57600.

Ich erbitte einen Blick darüber.

MfG

Das sollte mit der Version von DevIO von heute Mittag Rum behoben sein. Teste mal aus dem SVN

https://forum.fhem.de/index.php/topic,111832.0.html

[HomeAuto_User]

Das sollte mit der Version von DevIO von heute Mittag Rum behoben sein. Teste mal aus dem SVN

https://forum.fhem.de/index.php/topic,111832.0.html

Danke für den Hinweis.
Nach dem manuellem laden aus dem SVN geht es erstmal wieder. Diese Datei kommt dann mit Sicherheit erst morgen mit dem SVN update.

[KernSani]

Hallo Rudi & Markus,
hatte leider vergangene Woche wenig Zeit mich dem Thema zu widmen, aber ihr habt ganze Arbeit geleistet. Funktioniert bei mir jetzt problemlos Vielen Dank und *Daumen hoch*!
Einen kleinen Schönheitsfehler habe ich noch. Die Regex in folgender Zeile:

Code Auswählen Erweitern


elsif($dev =~ m,^(ws:|wss:)?([^/:]+):([0-9]+)(.*?)$,) {# TCP or websocket

verlangt zwingend, dass ein port mitgegeben wird. In meinem Fall kommt die Websocket-URL aus einer vorhergehenden Abfrage (ohne Port), was dazu führt, dass ich die URL erst zerlegen und wieder zusammenbauen muss (damit kann ich Leben, aber schöner wär's, wenn der Port aus dem Protokoll abgeleitet würde, wenn nicht mitgegeben).
Protokoll ist bei mir "wss". DevIO macht daraus "https" -> funktioniert trotzdem, ich bin mir aber nicht sicher, ob das in allen Fällen so ist, aber so lange niemand meckert
Grüße,
Oli

[KölnSolar]

Standard-Ports sind ja meines Wissens wie bei http/https 80/443.

Mein Fehler war, dass ich in einem bestehenden Modul einen kompletten URL(also DeviceName mit  wss://....) hatte und daher das Ganze ziemlich daneben lief.
Ob man die beiden slash noch mit reinnehmen sollte ?  Zumindest ich schreib die immer aus Gewohnheit. Und im Fehlerfall guckt man auf alles Mögliche, aber dem Kopf fallen die "überzähligen" // nicht auf.

Ansonsten klappt das bei mir nun auch mit dem SamsungAV. Ich habe einen gefühlten Performance-Gewinn.  (Verbindung ist nun dauerhaft offen u. wird nicht mehr bei jedem Modul-Aufruf neu aufgebaut)
Ich kämpfe noch mit dem Problem, dass der TV beim ausschalten kein close schickt. DevIo "merkt" also nicht, dass die Verbindung flöten gegangen ist(das selbe passiert natürlich, wenn hart per Funksteckdose abgeschaltet wird). Da alle 6s ein Ping vom TV kommt, hab ich mir einen workaround über einen internaltimer in der ReadFn geschrieben. Der setzt ein beliebiges write ab u. dann reagiert DevIo. Den internaltimer setze ich zeitlich so, dass er in der Regel(online) nicht ausgeführt, sondern über die ReadFN vorher gelöscht u. erneuert wird.

Gibt es dazu eine bessere Lösung, wenn das System/DevIo selber nicht merkt, dass die Verbindung geschlossen wurde ? isOpen funktioniert ja dann auch nicht als Prüfung.

Grüße Markus

[rudolfkoenig]

Es gibt DevIO_Ping, die prueft aber nicht, ob die andere Seite rechtzeitig Pong geliefert hat.
Bei einem ausgeschalteten Geraet muesste aber das OS dadurch merken, dass die Verbindung zu ist, und das per ReadFn/DevIo_SimpleRead auch an FHEM mitteilen.
=> Ein regelmaessiges, aus dem Modul aufgerufenes DevIO_Ping ist vmtl. eine bessere Loesung.

[KölnSolar]

Danke, probier ich aus....