50_SSChatBot - Integration des Synology Chat Servers

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

Vorheriges Thema - Nächstes Thema

DS_Starter

ZitatLeider finde ich keine Lösung, wie ich in einem DOIF oder notify aus den beiden Readings des dummy Device, den eigentlichen (set ........] String zusammenbauen kann.

Bei DOIF weiß ich es nicht, aber mit einem notify / at ist es recht einfach mit Perl möglich.
In beiden Modulen kannst du ja Code in {} angeben und ausführen lassen.
Hier mal nur eine prinzipielle Anregung die man natürlich nicht so verwenden kann. Nur das Prinzip:


define ssc.not notify  Dummy:Reading2.*
{
    my $str1 = ReadingsVal ("Dummy", "Reading1", "");
    my $str2 = ReadingsVal ("Dummy", "Reading2", "");
    my $str  = $str1.' '.$str2;
    fhem ("set ...... $str");
    .....
}


Dabei sollen Reading1 und Reading2 die von dir erwähnten Readings sein. Wenn du z.B. auf Reading2 triggerst wird der Prozess in Gang gesetzt sobald du dieses Reading mit deinem DOIF "gefüllt" hast.

VG
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

rohlande

#196
Hallo Heiko

Danke für das notify Beispiel im perl Stil.
Habe das DOIF und das notify verglichen.
Beide laufen. Es kommt folgender Sring im Output cmd des dummy heraus(siehe Anhang).
List des DOIF:
Internals:
   DEF        (([Set_tmp_value:cmd_device_flg] eq "true") && ([Set_tmp_value:cmd_value_flg] eq "true"))
(set [Set_tmp_value:cmd_device] [Set_tmp_value:cmd_value])
(setreading Set_tmp_value cmd_out [Set_tmp_value:cmd_device] [Set_tmp_value:cmd_value])
DOELSE

   FUUID      61b9c1f7-f33f-cb6b-eee9-756268a2af870a18
   FVERSION   98_DOIF.pm:0.252950/2021-12-04
   MODEL      FHEM
   NAME       SEND_SET_cmd
   NOTIFYDEV  Set_tmp_value,global
   NR         490
   NTFY_ORDER 50-SEND_SET_cmd
   STATE      cmd_1
   TYPE       DOIF
   VERSION    25295 2021-12-04 18:13:39
   READINGS:
     2021-12-16 08:04:29   Device          Set_tmp_value
     2021-12-16 08:04:29   cmd             1.2
     2021-12-16 08:04:29   cmd_event       Set_tmp_value
     2021-12-16 08:04:29   cmd_nr          1
     2021-12-16 08:04:29   cmd_seqnr       2
     2021-12-16 08:04:27   e_Set_tmp_value_cmd_device_flg true
     2021-12-16 08:04:29   e_Set_tmp_value_cmd_value_flg true
     2021-12-16 08:04:09   mode            enabled
     2021-12-16 08:04:29   state           cmd_1
   Regex:
     accu:
     collect:
     cond:
       Set_tmp_value:
         0:
           cmd_device_flg ^Set_tmp_value$:^cmd_device_flg:
           cmd_value_flg ^Set_tmp_value$:^cmd_value_flg:
   attr:
     cmdState:
     wait:
     waitdel:
   condition:
     0          (::ReadingValDoIf($hash,'Set_tmp_value','cmd_device_flg') eq "true") && (::ReadingValDoIf($hash,'Set_tmp_value','cmd_value_flg') eq "true")
   do:
     0:
       0          set [Set_tmp_value:cmd_device] [Set_tmp_value:cmd_value]
       1          setreading Set_tmp_value cmd_out [Set_tmp_value:cmd_device] [Set_tmp_value:cmd_value]
     1:
       0         
   helper:
     DEVFILTER  ^global$|^Set_tmp_value$
     NOTIFYDEV  global|Set_tmp_value
     event      cmd_value_flg: true
     globalinit 1
     last_timer 0
     sleeptimer -1
     timerdev   Set_tmp_value
     timerevent cmd_value_flg: true
     triggerDev Set_tmp_value
     timerevents:
       cmd_value_flg: true
       cmd_out: SW_Bettlicht Dimmer 21
     timereventsState:
       cmd_value_flg: true
       cmd_out: SW_Bettlicht Dimmer 21
     triggerEvents:
       cmd_value_flg: true
       cmd_out: SW_Bettlicht Dimmer 21
     triggerEventsState:
       cmd_value_flg: true
       cmd_out: SW_Bettlicht Dimmer 21
   internals:
   perlblock:
   readings:
     all         Set_tmp_value:cmd_device_flg Set_tmp_value:cmd_value_flg
   trigger:
   uiState:
   uiTable:
Attributes:
   DbLogExclude .*
   alias      SEND_SET_cmd
   event-on-change-reading .*
   room       Logik
/code]

List des notify:

[code]Internals:
   DEF        Set_tmp_value:cmd_value_flg.*
{
my $str1 = ReadingsVal ("Set_tmp_value", "cmd_device", "");
my $str2 = ReadingsVal ("Set_tmp_value", "cmd_value", "");
my $str  = ($str1.' '.$str2);
fhem ("set SW_Bettlicht $str");
fhem ("setreading Set_tmp_value cmd_out $str");
}
   FUUID      61baca4a-f33f-cb6b-8d2f-d397b3e5bb43a3f1
   FVERSION   91_notify.pm:0.252310/2021-11-15
   NAME       ssc.not
   NOTIFYDEV  Set_tmp_value
   NR         491
   NTFY_ORDER 50-ssc.not
   REGEXP     Set_tmp_value:cmd_value_flg.*
   STATE      inactive
   TRIGGERTIME 1639638113.68538
   TYPE       notify
   READINGS:
     2021-12-16 08:03:59   state           inactive
     2021-12-16 08:01:53   triggeredByDev  Set_tmp_value
     2021-12-16 08:01:53   triggeredByEvent cmd_value_flg: true
Attributes:
   DbLogExclude .*
   alias      ssc.not
   event-on-change-reading .*
   room       Logik
   verbose    5


Jetzt kommt das Große ABER.

Sobald ich jetzt versuche im EVENT Monitor das Ereignis zu triggern(ich drücke den Button welcher folgenden Inhalt an den ChatBot sendet [ "value": "TH_Buero desired-temp",]
Erhalte ich im Browser Fenster einen FHEM disconnect für 5 sec. und auch keine Event Information.
Auch wird nichts ins Log geschrieben.
Ich bin etwas verwirrt was hier Fhem so blockiert.
Das macht es schwierig jetzt einzugrenzen ob es DOIF, notify, SSChatBot ist welcher dies verursacht.

UPDATE:

ich bin irretiert.... Nach einem Neustart des Docker und senden einer Wunschteperatur via o.g Struktur, wurde nach ca.  1min Laufzeit, die gewünschte Temp. im Device auch übernommen.
Das hatte ich so seit Gestern nicht gesehen.

Aber wie gesagt, was ich völlig komische finde ist der Lost Connect im "eventMonitor" Fenster in Fhem.

VG denny
HostSystem: Synology DS918 | FHEM im Docker Version: 6.0-s22528_v2.2.4 (dedizierte IP Adresse) | MQTT_Broker auf DS918 NAS | MQTT_FHEM | TASMOTA_DEVICE | SSChatBot | SSCam | LaMetric | FBAHAHTTP | CUL | SONOS | HUEBridge (deCONZ) Zigbee | FB_CALLMONITOR | InfluxDBLogger

marvin78

Zitat von: DS_Starter am 29 November 2021, 17:33:54
Meine Synology ist übrigens nicht im Internet zu erreichen, sondern auschließlich via VPN.

Wie nutzt du dann zuverlässig den Chat?

rohlande

ich gehe davon aus, dass Heiko dazu dauerhaft die VPN Verbindung Seitens der mobilen Endgeräte oder Rechner dazu herstellt.
Nutzt Du den VPN Server der Syno? oder den z.B einer FritzBox?

Ich habe bei mir beide VPN Varianten am Android und IPhone Devices dazu aktiv.

VG denny
HostSystem: Synology DS918 | FHEM im Docker Version: 6.0-s22528_v2.2.4 (dedizierte IP Adresse) | MQTT_Broker auf DS918 NAS | MQTT_FHEM | TASMOTA_DEVICE | SSChatBot | SSCam | LaMetric | FBAHAHTTP | CUL | SONOS | HUEBridge (deCONZ) Zigbee | FB_CALLMONITOR | InfluxDBLogger

marvin78

Keine Fritzbox. Unifi.

Mir geht es um die Zuverlässigkeit. VPN bricht in Deutschland schonmal ab, niemand merkt es und es kommen keine Nachrichten.

rohlande

Okay... Kann ich zwar nicht nachvollziehen aber die VPn Client's verbinden sich doch neu in der Regel!
Zumindest bei mir.
Habe VPNCilla und OPENVPN im Einsatz als Client auf IPhone | Windows | Android....
Gehst Du über dyndns?

Vg Denny
HostSystem: Synology DS918 | FHEM im Docker Version: 6.0-s22528_v2.2.4 (dedizierte IP Adresse) | MQTT_Broker auf DS918 NAS | MQTT_FHEM | TASMOTA_DEVICE | SSChatBot | SSCam | LaMetric | FBAHAHTTP | CUL | SONOS | HUEBridge (deCONZ) Zigbee | FB_CALLMONITOR | InfluxDBLogger

DS_Starter

#201
Hallo Marvin,

ZitatWie nutzt du dann zuverlässig den Chat?
Ich nutze die QuickConnect ID über Synology. Das bedarf keiner Portöffnung von außen.

@Denny,
Zitat
Erhalte ich im Browser Fenster einen FHEM disconnect für 5 sec. und auch keine Event Information.
....
Ich bin etwas verwirrt was hier Fhem so blockiert.
Die Meldung bezieht sich auf die FHEMWEB Verbindung. Es wird nichts blockiert, nur FHEMWEB hat in dem
Moment keine Verbindung zum FHEM Server bzw. hat  diese abbaut. Deshalb siehst du auch keine Events etc.
Aber der Befehl wird im Server ausgeführt.

Ich kann mir jetzt nicht vorstellen woran das liegen könnte in diesem Kontext.
Erster Tipp wäre mal einen Standard  Style (f11) im FHEMWEB zu verwenden um ein evtl. Problem an dieser Stelle auszuschließen.

Grüße,
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

marvin78

Zitat von: DS_Starter am 16 Dezember 2021, 20:38:59
Hallo Marvin,
Ich nutze die QuickConnect ID über Synology. Das bedarf keiner Portöffnung von außen.


Stimmt. Aber es geht dann doch wieder über eine Cloud, von der man abhängig ist. Zugegeben etwas weniger, als bei Alternativen, wie Telegram und Co.

DS_Starter

ZitatAber es geht dann doch wieder über eine Cloud, von der man abhängig ist.
Stimmt auch wieder.  ;)
Allerdings habe ich mit openVPN, welches ich ebenfalls auf den Mobildevices nutze, gute Erfahrungen gemacht.
In den Einstellungen gibt es unter "Connection Timeout" den Schalter "Continously retry", sodass immer wieder versucht wird eine Verbindung herzustellen.
Mein Mailplus login läuft über VPN. Das Login vom Chat brauche ich einfach nur umzustellen.
Das mache ich mal ...
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

rohlande

Aber warum machst du alles via vpn? Ich habe z.b eine feste IP und bei Strato eine Domain...   Alles dann via https / SSL auf 443.  Mailserver / etc ...
HostSystem: Synology DS918 | FHEM im Docker Version: 6.0-s22528_v2.2.4 (dedizierte IP Adresse) | MQTT_Broker auf DS918 NAS | MQTT_FHEM | TASMOTA_DEVICE | SSChatBot | SSCam | LaMetric | FBAHAHTTP | CUL | SONOS | HUEBridge (deCONZ) Zigbee | FB_CALLMONITOR | InfluxDBLogger

DS_Starter

ZitatAber warum machst du alles via vpn? Ich habe z.b eine feste IP und bei Strato eine Domain...
Naja weil ich so wenig wie möglich externe Dienste einbinden möchte. VPN erschien mir der komfortabelste Weg dazu (für mich). Und funktioniert ja auch tadellos mit dem VPN-Server der Syno.
Aber das wird jetzt OT für SSChatBot.  ;)

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

Nicht OT: Ich habe beim Chatbot ständig Timeouts, wenn ich etwas aus FHEM sende (oder abfrage). Das Versenden einer Nachricht dauert rund 45 Sekunden (timeout steht auf 60). Kein Problem in die Gegenrichtung. Keine Verzögerung messbar. Gibt es hier ähnliche Erfahrungen?

Zur Einordnung: Die RS 1221+ langweilt sich. 32GB RAM bekomme ich nichtmal mit vielen VMs voll. Alle anderen Dienste, wie Surveillance und Co. zeigen, auch im Zusammenhang mit FHEM und deinen Modulen, keine solchen Sympthome.

Beispiel-Reverse-Log

2021.12.17 08:39:38.140 2: DeepThoughtChatBot - ERROR - "chatUserlist" SendQueue index "1" not executed. Restart SendQueue in 5 s (retryCount 1).
2021.12.17 08:39:38.126 2: DeepThoughtChatBot - ERROR message: read from https://10.1.10.10:5001 timed out
2021.12.17 08:39:34.416 3: DeepThoughtChatBot - SSChatBot "DeepThoughtChatBot" for URL /outchat registered
2021.12.17 08:39:34.416 4: DeepThoughtChatBot - Operation "chatUserlist (idx: 1)" is still running. Next operation start postponed

        };
          'channel' => ''
          'retryCount' => 0,
          'userid' => '',
          'fileUrl' => '',
          'attachment' => '',
          'method' => 'user_list',
          'text' => '',
          'opmode' => 'chatUserlist',
$VAR1 = {
2021.12.17 08:39:34.415 5: DeepThoughtChatBot - Add Item to queue - Index 1:
2021.12.17 08:39:18.115 4: DeepThoughtChatBot - Call-Out: https://10.1.10.10:5001/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=user_list&token="<secret>"
2021.12.17 08:39:18.115 5: DeepThoughtChatBot - HTTP-Call will be done with httptimeout: 20 s
2021.12.17 08:39:18.115 4: DeepThoughtChatBot - start SendQueue entry index "1" (chatUserlist) for operation.
2021.12.17 08:39:18.114 4: DeepThoughtChatBot - botToken read from RAM: ********
2021.12.17 08:39:18.114 4: DeepThoughtChatBot - API hashvalues already set - ignore get apisites
2021.12.17 08:39:18.114 4: DeepThoughtChatBot - ####################################################
2021.12.17 08:39:18.114 4: DeepThoughtChatBot - ###         start Chat operation chatUserlist   
2021.12.17 08:39:18.114 4: DeepThoughtChatBot - ####################################################

DS_Starter

Kann ich bei mir nicht bestätigen. Läuft mit dem Default timeout und sehr schnell in der Kommunikation.
Aber wir hatten das schon mal thematisiert. Schau mal unter #165 ff.

Hier ein Test zum Vergleich (einfacher Textversand FHEM-> Chatserver)


2021.12.17 13:09:39.768 5: SynChatBot - Add Item to queue - Index 6:
{
  'attachment' => '',
  'userid' => 4,
  'channel' => '',
  'method' => 'chatbot',
  'text' => 'test',
  'opmode' => 'sendItem',
  'retryCount' => 0,
  'fileUrl' => ''
}

2021.12.17 13:09:39.769 4: SynChatBot - ####################################################
2021.12.17 13:09:39.770 4: SynChatBot - ###         start Chat operation sendItem   
2021.12.17 13:09:39.770 4: SynChatBot - ####################################################
2021.12.17 13:09:39.770 4: SynChatBot - API hashvalues already set - ignore get apisites
2021.12.17 13:09:39.771 4: SynChatBot - botToken read from RAM: ********
2021.12.17 13:09:39.771 4: SynChatBot - start SendQueue entry index "6" (sendItem) for operation.
2021.12.17 13:09:39.772 5: SynChatBot - HTTP-Call will be done with httptimeout: 20 s
2021.12.17 13:09:39.772 4: SynChatBot - Call-Out: http://192.168.2.10:5000/webapi/entry.cgi?api=SYNO.Chat.External&version=2&method=chatbot&token="<secret>"&payload={"text": "test","user_ids": [4]}
2021.12.17 13:09:40.073 5: SynChatBot - JSON returned: {
  'data' => {
              'fail' => undef,
              'succ' => {
                          'user_id_post_map' => {
                                                  '4' => '68719495823'
                                                }
                        }
            },
  'success' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' )
}

2021.12.17 13:09:40.081 4: SynChatBot - Opmode "sendItem" finished successfully, Sendqueue index "6" deleted.
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

Naja. Wie gesagt. Die RS langweilt sich. Alle anderen Antwortzeiten sind sagenhaft schnell.

Ich gehe also von einem Problem mit Synology Chat aus.

marvin78

Zitat von: Wiesel am 29 November 2021, 14:45:18

der Übeltäter scheint das "permission denied" zu sein. In der Datei "/tmp/login_fail.list" ist meine öffentliche IP (+ kryptische zeichen) enthalten.


Das ist ein guter Hinweis. Sobald ein Eintrag in dieser Datei ist bzw. die Datei vorhanden ist (tatsächlich egal, was für ein Eintrag es ist), ist die Antwortzeit unterirschisch. Welches Tool schreibt Einträge dorthin? Das muss ich mal rausfinden. Der gewöhnliche fail2ban der Syno ist es offenbar nicht.