Neues Modul: Signalbot (Integration für den Signal Messenger) via signal-cli

Begonnen von Adimarantis, 31 Januar 2021, 19:16:19

Vorheriges Thema - Nächstes Thema

Adimarantis

Zitat von: weini am 22 Februar 2021, 18:59:54
Ist es korrekt, dass wenn ich die Gruppe als "allowedPeer" anlegen, dann Nachrichten zugelassen sind, die von der Gruppe aus versandt werden? Es werden aber keine Nachrichten akzeptiert, die von Mitgliedern der Gruppe an den Bot versandt werden. Das hätte ich anders erwartet, scheint aber so zu sein.
Ja, das ist korrekt.
Finde ich aber grundsätzlich auch richtig. Einen PM ist halt was anderes als eine Gruppennachricht. Daher ist allowedPeer auch eine Liste.
Wird das bei Telegram anders interpretiert (hab ich jetzt nicht nachgeschaut)?

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Zitat von: weini am 22 Februar 2021, 18:45:58

  • "commandKeywordUnauthorized": Analog zu commandKeyword, aber es wird kein GoogleAuth getriggert/verlangt (z. B. "#")
  • "commandPatternUnauthorized": Gibt eine Liste von Prefixen an, die über das obige Keyword ausgeführt werden dürfen (z. B. "trigger,get" bedeutet, dass "#trigger sendLichtStatus" zulässig ist)
  • "commandPattern": das selbe für die Befehle, die via GoogleAuth authorisiert werden müssen
Ich finde das aktuell zu kompliziert. Zu viele verwirrende Einstellungen über die man den Überblick verliert. Da vertrete ich lieber weiter den Ansatz: Alles weitere über notify/DOIF
Zitat
Irgendetwas scheint mit den Signal Gruppen gerade nicht optimal zu laufen. Mein erster Versuch, eine Gruppe "ABC" anzulegen hat dazu geführt, dass diese Gruppe nun zwar dem Bot User zugeordnet ist, aber mit "active: false". So kann ich sie nicht mehr löschen. Nun konnte ich sie zwar ein zeites mal mit gleichem Namen anlegen, dann kann ich sie aber nicht als "allowedPeer" nutzen. Ist aber nicht dramatisch, ich komme auch gut ohne die Gruppen aus.
Das Erstellen und Löschen von Gruppen in Signal ist mir auch noch ein Mysterium. Über das signal-cli Interface bekommt man Gruppen irgendwie nicht mehr richtig los. Selbst in der App ist es schwierig Gruppen loszuwerden (Block&Leave und dann Delete). Über das Interface geht das gar nicht.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

weini

Zitat von: Adimarantis am 22 Februar 2021, 20:07:02
Alles weitere über notify/DOIF
Alles gut, dann baue ich mir das so auf!

Zitat von: Adimarantis am 22 Februar 2021, 19:53:52
Wird das bei Telegram anders interpretiert (hab ich jetzt nicht nachgeschaut)?
Kann ich nicht sagen, bei Telegram habe ich nicht mit Gruppen gearbeitet. Bin nur durch Zufall drüber gestolpert.

weini

Eine Sache wäre noch gut, wenn man sich selbst mit den DOIFs weiterhilft:
Könntest du noch ein Reading spendieren,  das als 0/1 anzeigt, ob GoogleAuth gerade authentifiziert ist, also innerhalb des mit authTimeout definierten Zeitraums?

Adimarantis

Zitat von: weini am 22 Februar 2021, 22:42:46
Eine Sache wäre noch gut, wenn man sich selbst mit den DOIFs weiterhilft:
Könntest du noch ein Reading spendieren,  das als 0/1 anzeigt, ob GoogleAuth gerade authentifiziert ist, also innerhalb des mit authTimeout definierten Zeitraums?
Gibt es natürlich bereits als internal (siehst du mit "list"). Das Problem ist nur: Da sich ja potentiell mehrere Anwender zu unterschiedlichen Intervallen authentifizieren können, ist das nicht einfach ein Flag, sondern ein Name=Value Hash pro Telefonnummer.
Wie soll man das darstellen? Ein Reading mit der Liste der aktuell authentifizierten Nummern? Dann musst du immer vergleichen ob der Sender in der Liste ist.
Ist natürlich deine Sache, aber bevor du jetzt die Funktionalität 1:1 nachzubilden versuchst, würde ich mich fragen, was ich erreichen will und ob es keinen einfacheren Weg gibt.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

weini

Hi Jörg!
Guter Punkt, die Info macht natürlich nur in Kombination mit dem "Sender" Sinn.
Ich hatte auf die Internals geachtet, aber nur auf die, die im Webinterface dargestellt werden. Komme ich aus einem DOIF an die Infos dran, die im List unter "helper" aufgeführt werden?

Ansonsten könnte ich mir zwei Varianten vorstellen:

  • Ein Reading (oder sichtbares Internal) mit dem Namen des Senders (ggf. plus ein Prefix) und einem 0/1 Indikator.
  • Ein zusätzliches Reading "msgAuthenticated". Das wird immer dann gefüllt, wenn eine Message empfangen wird (also wenn msgText gefüllt wird) und gibt dann ebenfalls über 0/1 an, ob für den betreffenden Sender gerade GoogleAuth aktiv ist

Es geht mir bei dem Thema nicht darum, etwas aus TelegramBot 1:1 zu überführen. Ich überlege nur, wie ich im DOIF an die Info drankomme, ob der Sender sich authentifiziert hat.

LG, weini

Adimarantis

Hi Weini,

Die erste Variante wird schnell unübersichtlich und kompliziert zum Auswerten. Das zweite könnte gehen. Hat halt potentiell eine Race condition (wenn zwischen dem Trigger des events und bis du das Reading auswertest eine neue Message gekommen ist).
Muss ich mir mal anschauen.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

weini

Den Trigger würde ich auf "msgText" setzen. Das DOIF sollte also anziehen, wenn eine neue Nachricht reinkommen. Dann würde ich eine Fallunterscheidung nach "msgAuthenticated" = 0/1 machen und entsprechen agieren.
Da sollte aus meiner Sicht keine Race-Condition auftreten können.

Gibt es eigentlich einen Grund, warum du "msgText" nicht aktualisierst, wenn ein Kommando mit dem "cmdKeyword" als Prefix reinkommt?

Adimarantis

Zitat von: weini am 23 Februar 2021, 08:17:49
Gibt es eigentlich einen Grund, warum du "msgText" nicht aktualisierst, wenn ein Kommando mit dem "cmdKeyword" als Prefix reinkommt?

Ja, das ist eigentlich Absicht, da der Befehl ja schon abgehandelt wird und nicht noch weitere Events erzeugen muss
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Adimarantis

Hat eigentlich irgendjemand schon den Effekt gehabt das jedes "send" mit einer "NotFound" Fehlermeldung quittiert wird, aber das Empfangen von Nachrichten funktioniert?
Betrifft nur das Senden an Einzelempfänger. Gruppen sind davon nicht betroffen.
Passiert bei mir nur auf einem komplett neu installierten Raspi 400.
Das scheint ein Bug in der Net::DBus library zu sein. Leider ist die schon sehr alt und der Author reagiert nicht mehr wirklich.

Falls zumindest jemand dieses Problem hat, nicht verzweifeln, es könnte tatsächlich ein seltsamer Bug sein.
Ich habe dazu einen Workaround implementiert, suche aber noch nach einer richtigen Lösung (z.B. was anderes als Net::Dbus zu nehmen), daher werde ich die Version erstmal nur auf Anfrage posten und schauen das ich das noch runder bekomme. Das Problem sollte übrigens SiSi genauso betreffen, ich verstehe aber nicht warum sich dieses eine System (bei quasi identischer Installation) anders verhält, daher wäre es interessant ob das noch jemand hat.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Hausautomat

Moin Jörg,

erstmal herzlichen Dank für die Reimplementierung - heute habe ich endlich das lang ersehten fhem-update (nebst ansible setup dafür) und auch den Umstieg auf Signalbot geschafft. Bestehende Registrierung konnte (naturgemäß) behalten bleiben. Dabei war Dein Install-Script extrem hilfreich, um die signal-cli mit den passenden beiden arm-Libraries zu aktualisieren. Hat mir das lokale Compilieren erspart :)

Die Gruppen bleiben scheinbar immer "in der Liste", sind aber nicht aktiv. Der Umstieg auf die V2-Gruppen war etwas holprig, da ist die signal-cli-Doku etwas, sagen wir ambivalent/dürftig.

Zu Deiner Frage der Fehlermeldung: Nein, die Meldung habe ich hier beim Testen nicht gesehen. Vielleicht hilft die folgendes (mit verbose=5 auf Signalbot):

2021.02.27 18:41:35 3: Signal: Before parse:@+49176xxxxxxxx &/opt/fhem/log/store/EinfahrtCam/EinfahrtCam1_snapshot.jpg testing:

2021.02.27 18:41:35 5: Signal: sendMessage called for +49176xxxxxxxx:/tmp/signalbot1614447695.38293.jpg:testing
2021.02.27 18:41:46 5: Signal: Signalbot_receive_callback 1614447703663 +49176xxxxxxxx
2021.02.27 18:41:46 5: Signal: Read from Dbus done
2021.02.27 18:41:47 5: Signal: Signalbot_receive_callback 1614447703663 +49176xxxxxxxx
2021.02.27 18:41:47 5: Signal: Read from Dbus done


Die Leerzeile taucht genau so im Log auf.

Adimarantis

Schön das es so gut geklappt hat.

Ja das mit den Gruppen in ein Chaos. Das ist insgesamt in Signal etwas gewöhnungsbedürftig und in signal-cli erst recht.
Ich versuche zur Zeit ein paar updates in die nächste signal-cli Version reinzubekommen, damit man z.B. das Attribut "active" bei einer Gruppe abfragen kann (was so viel heisst das man nicht mehr drin ist) und auch aktiv FHEM Gruppen beitreten/verlassen etc. kann. Mal sehen ob das akzeptiert wird.

Bleibt zu hoffen dass der angesprochene Fehler nur mein System betrifft. Ich arbeite aber gerade an einem größeren Update bei dem ich auf ein anderes Framework umstelle das wie ich finde ein paar Vorteile bezüglich des "blocking" (oder eben gerade nicht-blocking) von FHEM während länger dauernden signal-cli Aufrufen hat (und diesen Bug nicht hat). Mal sehen - ein paar Nüsse sind da noch zu knacken.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Ralli

Zitat von: Adimarantis am 25 Februar 2021, 21:44:56
Hat eigentlich irgendjemand schon den Effekt gehabt das jedes "send" mit einer "NotFound" Fehlermeldung quittiert wird, aber das Empfangen von Nachrichten funktioniert?

Hallo Jörg,

ja, ich.


2021.02.28 06:07:21.690 5: Signal: Message Callback
2021.02.28 06:07:21.702 5: Signal: Message from +49123456789 : Test processed
2021.02.28 06:07:21.702 5: Signal: Read from Dbus done
2021.02.28 06:09:59.840 3: Signal: Before parse:Test:

2021.02.28 06:09:59.840 5: Signal: sendMessage called for +49123456789::Test


Error sending message:org.freedesktop.dbus.exceptions.DBusExecutionException: Error Executing Method org.asamk.Signal.sendMessage: Unknown version: 0
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

Adimarantis

Ok, dann poste ich die Version mal hier. Ich nenn sie jetzt mal Beta, wobei da noch keine wilden Änderungen drin sind (bzw. sind diese inaktiv).

Falls das genannte Problem beim Senden an Einzelkontakte auftritt, bitte mal das Attribut "workaround" auf 1 setzen und schauen ob das hilft.

@Weini: In der Version ist auch dein msgAuth Feature drin.

Die neue Version mit dem neuen Dbus Framework macht Fortschritte, aber da ist noch viel Arbeit. Teilweise ändert sich da die Programmlogik erheblich.

Jörg
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Ralli

Danke.


021.02.28 08:58:00.135 5: Signal: Init:
2021.02.28 08:58:00.147 5: Signal: Added message signal 1
2021.02.28 08:58:00.147 5: Signal: Added sync signal 2
2021.02.28 08:58:00.147 5: Signal: Added receipt signal 3
2021.02.28 08:58:00.147 5: Signal: Initializing Dbus with filehandle 13
no introspection data available for method 'version' in object '/org/asamk/Signal', and object is not cast to any interface at /usr/lib/x86_64-linux-gnu/perl5/5.30/Net/DBus/RemoteObject.pm line 467.

0.8.00
Gruß,
Ralli

Proxmox 8.1 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.6.20240316) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa