50_SSChatBot - Integration des Synology Chat Servers

Begonnen von DS_Starter, 25 November 2019, 07:56:56

Vorheriges Thema - Nächstes Thema

DS_Starter

ZitatOT: Schade ist, dass Synology für sowas so halbgare APIs anbietet. Da gibt es keine echte Konsistenz.
Da hast du recht. Gerade für Chat gibt es keine echte API so wie man sie für den Calender oder die Surveillance Station findet.

Ich habe noch etwas weiter geforscht. Meiner Meinung nach geht das Löschen von Posts nur für solche Beiträge die ein echter (eingeloggter) User gepostet hat. Und er kann auch nur seine eigenen Beitrage löschen.
Das bedeutet, ich müsste zunächst das Modul so erweitern, dass es nicht nur als ein Bot agieren kann, sondern als "normaler" User mit Login/Logout Prozeduren usw.
Man müsste demnach die Webanwendung des Chat zumindest in Teilen nachbauen.

Das ist schon eine etwas größere Maßnahme, aber sicher sehr interessant.
Mit curl es wäre sicherlich auch möglich einen Befehl abzusetzen. Aber auch damit hat man das grundsätzliche Problem zunächst ein Login auszuführen um an die benötigten Daten (Cookie, X-SYNO-TOKEN) zu kommen.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

marvin78

Ok. So wichtig ist es dann ggf. auch nicht. Ich überlege gerade, ob ich zumindest den Buttons, die ich eigentlich zeitgesteuert löschen möchte, einen Parameter mitgeben kann, der dafür sorgt, dass er nur einmal verwendet werden kann... Ich habe eine myutils extra für die Kommunikation mit dem Bot, das könnte dort dann überprüft werden. Wenn ich mal Zeit habe, schaue ich mir diesen Weg an.

SeppiDeluxe

#242
Hallo in die Runde,

ich gebe noch auf ... aber gehe den Schritt ins Forum. Seit exakt 10 Tagen (habe das schon für meine Suche als Anhaltspunkt genommen) empfange ich in meinem Bot keine Nachrichten mehr.

Die Analysen haben ergeben. Das der richtig Token verwendet wird und ich den folgenden Fehler erhalte.  2023.05.01 16:33:58 4: SeppiChat - Data returned: <html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>

Kopieren die URL und führe sie im Browser aus ist alles im Device bekomme ich dann als Antwort:

Error
malformed JSON string received
2023-05-01 16:42:49
Errorcode
9000
2023-05-01 16:42:49
QueueLength
9
2023-05-01 16:33:58
state
Error
2023-05-01 16:42:49

Wobei ich denke das er nur mit dem 400 nichts anfangen kann.

Device bereits neu angelegt etc. Keine Verbesserung und ich habe auch keine Idee mehr.

Danke für Anregungen und Impulse

Ergänzung: Benutze die DSM 7.2 Beta mit dem entsprechenden Chat Beta Modul. Iat vielleicht nicht unwichtig, da ich nicht weiss wie im pm Modul die URL Abfrage läuft.  Außerdem passt die Installation der Beta vor ca. 10 Tagen sehr gut zu den LOGS und dem Start der Probleme.

DS_Starter

Du kannst davon ausgehen, dass es an dem Dienst auf der Synology liegt. Der Fehler 400 Bad Request kommt vom NGINX auf der Syno der das aufgerufene Ziel nicht ansprechen kann.

Läuft der Chat Server auf der Syno ?
Arbeitest du mit HTTP oder HTTPS ?
Möglicherweise geht nur noch HTTPS.

Mal so nebenbei. Bei Beta-Releases muss man immer mit Problemen rechnen. Würde ich auf meinem Live-System nie machen. Ich selbst bin immer noch auf DSM 6.2.4.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

SeppiDeluxe

Danke für die Rückmeldung. War auch meine erste Vermutung.
Was mich stutzig macht, ist das Verhalten auf den zwei Wegen. Soll heißen, kopiere ich die URL aus dem Log (inkl. Transparentem Token) geht der Aufruf und erzeugt eine Nachricht. In der internen Kommunikation FHEM —> Synology kommt der Fehler.

Das macht mich stutzig.

BETA-Risiko ist einkalkuliert ;-)

DS_Starter

Das ist in der Tat merkwürdig.
Da ich es aber mit meiner Version nicht nachstellen kann, bleiben nur Vermutungen.

Eine wäre noch dass die Syno die IP deines FHEM Servers gesperrt hat. Allerdings käme dann wohl eine anderer Fehlercode.
Kannst ja mal die aufgerufene URL und die Antwort im Log posten (evtl. PN). Vllt. fällt mir etwas auf.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

joj

#246
Einen schönen Nachmittag!

Ich habe heute den Fehler gemacht und meine Synology auf den ReleaseCandidate DSM 7.2-64551 upgedated. Seither funktioniert leider das Senden Nachrichten aus FHEM an den SynoChatBot nicht mehr. Synology unterstützt in dieser Version Node.js v11 nicht mehr, vielleicht die Ursache...?

Anbei das LOG:

2023.05.05 13:29:16 4: SynChatBot - ####################################################
2023.05.05 13:29:16 4: SynChatBot - ###        start Chat operation sendItem   
2023.05.05 13:29:16 4: SynChatBot - ####################################################
2023.05.05 13:29:16 4: SynChatBot - API hashvalues already set - ignore get apisites
2023.05.05 13:29:16 4: SynChatBot - botToken read from RAM: ********
2023.05.05 13:29:16 4: SynChatBot - start SendQueue entry index "4" (sendItem) for operation.
2023.05.05 13:29:16 5: SynChatBot - HTTP-Call will be done with httptimeout: 20 s
2023.05.05 13:29:16 4: SynChatBot - Call-Out: https://192.168.0.2:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "test1234","user_ids": [6]}
2023.05.05 13:29:16 4: SynChatBot - Data returned: <html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>

Wenn ich die Call-Out URL selbst zusammenbaue (meinen Token einfüge) und in einen Browser kopiere, wird allerdings eine Nachricht an den SynoChatBot geschickt.

Zusätzlich bekomme ich in FHEM folgende Readings:

Error
malformed JSON string received

Errorcode
9000


Vielleicht hätte jemand einen Hinweis für mich? Ich habe bereits die Firewall der Synology abgeschaltet und ein paar mal neu gebooted, ebenso FHEM, leider ohne Erfolg.

Viele Grüße!
Jürgen

DS_Starter

Hallo joj, SeppiDeluxe,

möglicherweise müsst ihr im DSM 7.2 etwas einstellen.
Seht euch mal die Seite:

https://www.blackvoid.club/dsm-7-2-public-beta-is-live/

an. Es gibt einen Abschnitt "New notification options". Schaut das mal durch, könnte sein dass dort unter "webhook" das Chat ausgewählt werden muss.

Ansonsten bliebe noch der Weg den Synology Support anzuschreiben. Möglicherweise gibt es Änderungen die in das Modul einfließen müssten. Kann mir aber nicht vorstellen was es sein sollte wenn ich eure Meldungen lese.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

joj

Hallo DS_Starter,
besten Dank für den Hinweis, ich melde mich, falls ich hier weiterkomme...!

Beste Grüße!

joj

#249
Hallo DS_Starter,
ich bin bis dato nicht wirklich weitergekommen, Zeit ist Luxus... ;)

Ich habe zumindest auf meiner Syno das AccessLogging für nginx aufgedreht und habe folgende Zeile gesehen, wenn FHEM an den SynoChatBot etwas schickt...

IP-FHEM-SERVER - - [12/May/2023:10:27:14 +0200] "GET /webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token=\x22HIER-STEHT-DER-TOKEN\x22&payload={\x22text\x22: \x22test123\x22,\x22user_ids\x22: [6]} HTTP/1.0" 400 150 "-" "-" "-"

Zum Vergleich die URL aus dem FHEM-VerboseLog:
[url="https://ip-der-syno:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="HIER-STEHT-DER-TOKEN"&payload="]https://ip-der-syno:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="HIER-STEHT-DER-TOKEN"&payload=[/url]{"text": "test1234","user_ids": [6]}

Ein Puzzlestück mehr, vielleicht kannst du damit schon etwas anfangen...Jedenfalls vielen Dank!




DS_Starter

ZitatZeit ist Luxus..
Wem sagst du das ...

Naja, es ist etwas müßig zu puzzeln und bei der nächsten Gelegenheit wieder auf die Nase zu fallen. (Zeit ist Luxus ..  ;)  )
Ich werde ein Frage an Synology stellen was geändert wurde bzw. wie der Aufruf angepasst werden muß.

Mal schauen ob/was Syno antwortet.
Evtl. brauche ich noch mehr Infos wenn die Fragen stellen.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

SeppiDeluxe

Ich habe eure Vorschläge noch nicht vollständig ausgetestet. Was nach wie vor auffällt / funktioniert, ist aus dem FHEM Log (verbose 5) die URL C&P zu übernehmen und im Browser direkt aufzurufen. Die Nachricht geht durch ohne irgendeinen Fehler und erzeugt wie erwartet einen Text im Bot.

Von daher nehme ich an das die Beta irgendwas zwischen dem FHEM Kommandoaufruf und der API moniert. Ich werde heute und morgen noch etwas Zeit reinstecken.

DS_Starter

Habe eine Meldung bei Syno aufgemacht ... mal schauen.

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Synology hat schon geantwortet und würde sich das Ganze mal auf dem System anschauen wollen:

ZitatHello Mr. Maaz,
Thank you for contacting Synology Technical Support.

Please allow us to remotely access the affected NAS.
During the remote access, we will investigate what is triggering the behavior.

For a description of how to enable remote access and how to securely share the data with us, please refer to the separate form you received.

Please note:
To protect the privacy of our customers, all submitted remote access information is automatically deleted after the ticket is resolved.
Also, the remote access settings on your Synology product will be automatically disabled after a certain period of time.

Please let us know if you have any concerns about sharing this access with us.

Mit freundlichen Grüßen / Best Regards,

Wolfgang Maier
Technical Support Engineer

Nun ist es für mich nicht möglich, da ich ja noch auf DSM 6 bin.
Würde sich einer von euch dafür engagieren ?`

Wenn ja, würde ich mit demjenigen mal telefonieren (oder PM) um das Vorgehen abzusprechen.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Guten Morgen,

wenn ihr im Device verbose 5 setzt, kommen im Log auch die detaillierten Informationen von HttpUtils:

2023.05.18 08:08:53.550 4: SynChatBot - ####################################################
2023.05.18 08:08:53.550 4: SynChatBot - ###         start Chat operation sendItem   
2023.05.18 08:08:53.551 4: SynChatBot - ####################################################
2023.05.18 08:08:53.551 4: SynChatBot - API hashvalues already set - ignore get apisites
2023.05.18 08:08:53.555 4: SynChatBot - botToken read from RAM: ********
2023.05.18 08:08:53.556 4: SynChatBot - start SendQueue entry index "3" (sendItem) for operation.
2023.05.18 08:08:53.556 5: SynChatBot - HTTP-Call will be done with httptimeout: 10 s
2023.05.18 08:08:53.557 4: SynChatBot - Call-Out >GET<: https://192.168.2.10:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "Test","user_ids": [4]}
2023.05.18 08:08:53.558 3: HttpUtils url=https://192.168.2.10:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "Test","user_ids": [4]} NonBlocking via https
2023.05.18 08:08:53.558 2: IP: 192.168.2.10 -> 192.168.2.10
2023.05.18 08:08:53.591 3: HttpUtils request header:
GET /webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "Test","user_ids": [4]} HTTP/1.0
Host: 192.168.2.10:5001
User-Agent: fhem
Accept-Encoding: gzip,deflate
Accept: application/json

2023.05.18 08:08:53.690 2: https://192.168.2.10:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "Test","user_ids": [4]}: HTTP response code 200
2023.05.18 08:08:53.691 3: HttpUtils https://192.168.2.10:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "Test","user_ids": [4]}: Got data, length: 83
2023.05.18 08:08:53.692 3: HttpUtils response header:
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 18 May 2023 06:08:53 GMT
Content-Type: application/json; charset="UTF-8"
Connection: close
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
2023.05.18 08:08:53.693 5: SynChatBot - JSON returned: {
  'data' => {
              'fail' => undef,
              'succ' => {
                          'user_id_post_map' => {
                                                  '4' => '34359741618'
                                                }
                        }
            },
  'success' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
}

2023.05.18 08:08:53.716 4: SynChatBot - Opmode "sendItem" finished successfully, Sendqueue index "3" deleted.

Ihr müsst bitte den Token durch "secret" ausblenden.
Vielleicht sieht man dann mehr. Ich könnte mir vorstellen, dass HttpUtils etwas am Call "anpasst" was im Browser nicht gemacht wird und deswegen mit dem Browser Aufruf funktioniert.
Das beantwortet natürlich nicht die Diskrepanz im Verhalten zwischen DSM 6.2 und DSM 7.2.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter