Hallo zusammen,
ich arbeite gerade an einem Modul zur Integration des Synology Chat Servers mit FHEM. Es funktioniert bereits sehr gut für Nachrichten FHEM -> Chat.
Zum Senden von Nachrichten Chat -> FHEM gibt man im Chat Server eine Webadresse an, die durch den Chat Server im Sendefall aufgerufen und durch POST Nutzdaten ergänzt wird.
Zum Test habe ich ein FHEMWEB definiert und im Chat eingetragen:
http://fhemtest.myds.me:8084
Wenn ich nun ein "huhu" im Chat absetze, erscheint im Log mit verbose 4:
2019.11.26 23:38:07.768 4: WEBphone_192.168.2.10_51532 POST /&token=6MyQRHenNXI3w2ttSESi4a5aXnAx6aSR6NPpZdPTRFtKITKanbJN1krt20SNn2rK&user_id=4&username=Heiko&post_id=64424509449&thread_id=0×tamp=1574807887740&text=huhu; BUFLEN:0
Die Kommunikation funktioniert also.
Nun meine konkrete Frage. Was wäre ein Weg diese durch FHEMWEB empfangenen Daten abzugreifen und in einem Device (dem im FHEM definierten Chat-Device) aufzubereiten und als Readings zur Verfügung zu stellen ?
Irgendwie fehlt mir gerade die Phantasie und bräuchte eine Anregung bzw. Wegweisung von euch. Vielleicht gibt es auch schon einen ähnlichen Anwendungsfall den ich mir anschauen könnte.
Danke und LG,
Heiko
Du kannst dir dazu mal das HP1000 Modul ansehen.
Ich glaube mich zu erinnern das im MQTT2_Serrver Modul von Rudi auch ein Webhook verwendet wird.
Habe mich geirrt, er baut einen eigenen TCP Server Socket auf. Sorry
Grüße
Guten Morgen,
danke für eure Antworten. Werde mir heute Abdend das HP1000 mal zu Gemüte führen.
LG,
Heiko
@Julian, beim Thema HP1000 fällt mir auch noch ein, dass es in einem Thread ein Thema mit dem DbLog_Split gab/gibt -> https://forum.fhem.de/index.php/topic,103752.0.html
Weiß nicht ob du das gesehen hattest.
LG
ZitatWas wäre ein Weg diese durch FHEMWEB empfangenen Daten abzugreifen und in einem Device (dem im FHEM definierten Chat-Device) aufzubereiten und als Readings zur Verfügung zu stellen ?
Mir faellt Folgendes ein:
- wenn man den Inhalt der URL nicht beliebig formatieren kann, oder mehr Kontrolle haben will: eine FWEXT Funktion in FHEM implementieren. Beispiele dafuer gibt es etliche, 30+ Module verwenden das Verfahren.
- sonst kann man Readings direkt setzen mit "http://host:port/fhem?cmd=setreading device readingname readingvalue&XHR=1&fwcsrf=XXX" wobei XXX entweder passend gesetzt, oder per csrfToken abgeschaltet werden muss.
- alternativ ruft man mit der obigen Methode statt setreading eine Perl-Funktion per {} auf, oder man definiert ein eigenes FHEM-Befehl.
Danke für die zusätzlichen Infos Rudi.
Ich denke mit den jetzt vorhandenen Hilfen / Hinweisen komme ich weiter.
Sonst melde ich mich nochmal.
Grüße,
Heiko
Danke eurer Hilfe habe ich den Empfang/Parsing nun mit Hilfe eines FWEXT implementieren können.
Funktioniert ausgezeichnet.
Allerdings gibt es noch eine Frage fwcsrf-Parameter.
Ich habe die Webinstanz mit einem csrfToken definiert:
Internals:
CONNECTS 7
CSRFTOKEN 5de17731
DEF 8086 global
FD 17
FUUID 5de17731-f33f-b178-dcef-5d7a8a155b544602
FVERSION 01_FHEMWEB.pm:0.205400/2019-11-19
NAME WEBSSChatBot
NR 621
NTFY_ORDER 50-WEBSSChatBot
PORT 8086
STATE Initialized
TYPE FHEMWEB
READINGS:
2019-11-29 21:01:28 state Initialized
Attributes:
closeConn 1
csrfToken 5de17731
room Chat1
stylesheetPrefix default
verbose 4
webname sschat
Der Webhook ist ebenfalls mit dem Parameter &fwcsrf versehen:
http://fhemtest.myds.me:8086/sschat/outchat?botname=SynChatBot&fwcsrf=5de17731
Das klappt natürlich erwartungsgemäß ausgezeichnet.
Jetzt habe ich den Parameter &fwcsrf im Webbhook bewußt auf einen falschen Wert gesetzt (&fwcsrf=5de177345) um zu sehen ob die Verbindung abgewiesen wird, was ich nun erwarten würde.
Trotzdem nimmt die Webinstanz die Verbindung an und funktioniert genauso:
Zitat
2019.11.29 21:23:42.988 4: Connection accepted from WEBSSChatBot_192.168.2.10_39246
2019.11.29 21:23:42.989 4: WEBSSChatBot_192.168.2.10_39246 POST /sschat/outchat?botname=SynChatBot&fwcsrf=5de177345&token=U6FOMH9IgT22ECJceaIW0fNwEi7VfqWQFPMgJQUJ6vpaGoWZ1SJkOGP7zlVIscCp&user_id=4&username=Heiko&post_id=34359738457&thread_id=0×tamp=1575059022945&text=Test%20mit%20falschem%20csrfToken; BUFLEN:0
Müßte die Verbindung nicht abgewiesen werden oder habe ich ein falsches Verständnis ?
Die CSRF-Token Pruefung erfolgt (offensichtlich) nicht fuer die FWEXT Module.
Ob das ein Fehler ist, oder nicht, ist vmtl. Diskussionswuerdig.
Ich würde jetzt im Sinn der Einheitlichkeit ebenfalls für eine Prüfung plädieren. Allerdings kann ich den Ausmaß einer solchen Ausweitung nicht abschätzen, d.h. ob dadurch unerwünschte Probleme an anderer Stelle auftreten würden.
Für den vorliegenden Einsatzfall wäre es (für mich) nicht so relevant und ist wohl eher eine etwas globalere Betrachtung.
Dann lassen wir es erstmal so, ich bin z.Zt. nicht motiviert, 30+ Module durchzutesten, und bei Problemen fuer die Loesung zu sorgen.
Das HP1000 Modul käme definitiv nicht mit einer Änderung zurecht, da man die Geräte, von denen der Webhook geschickt wird, nicht anpassen kann.
Ja, bitte so lassen wie es ist. Bitte. Es steht ja jedem Modulautor frei die Prüfung selber durchzuführen.