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

[Carsten K.]

RESPEKT !!!

Ich habe "openjdk-*" entfernt und dann den Installer neu gestartet (vorher noch mal "remove").
GLIBC habe ich auf den ursprünglichen Wert gesetzt.

Im Output kam dann:

Code Auswählen Erweitern

...
Downloading signal-cli 0.9.2...done
Unpacking ...
Downloading native libraries...done
Updating native libs for amd64-glibc2.28-0.9.2
updating: libzkgroup.so (deflated 75%)
updating: libsignal_jni.so (deflated 75%)
done
...

Ganz herzliches Danke Schön,
Carsten

[Adimarantis]

Update 3.3 im SVN und ab morgen über update:

- Neues favorite Feature für Remote Befehle welches hauptsächlich das notify im Wiki (Danke an weini) direkt implementiert
- Retry/Reconnect beim Start (max. 3 mal in 10s Abständen) für den Fall das FHEM schneller startet als signal-cli (beim reboot)
- kleinere Fixes und Schönheitsreparaturen

Jörg

[kroman]

Hallo Jörg,

zuallererst möchte ich mich herzlich für dein Modul bedanken!
Da ich Signal bei den messengern bevorzuge, habe ich große Freude damit und nun auch endlich FHEM darauf umgestellt.

Ich hätte ein paar Ideen/Vorschläge, mal sehen was du dazu sagst.
Der letzte update ist installiert und attribute sind wie folgt gesetzt:

Code Auswählen Erweitern


attr signalbot allowedPeer xxx
attr signalbot authDev googleauth
attr signalbot authTimeout 300
attr signalbot cmdFavorite fav
attr signalbot cmdKeyword /
attr signalbot defaultPeer xxx
attr signalbot favorites -set d_autooff off;; set d_autooff on


1. Wenn allowedPeer gesetzt ist, bekommt man wie ja in der commandref beschrieben anhand von events nicht mit, falls jemand der eigentlich nicht soll, Nachrichten schickt. Ist vielleicht etwas übertrieben, aber siehst du eine Möglichkeit bzw. hast du Lust die readings z.B. msgSenderAttacker und msgTextAttacker einzubauen? Perfekt wäre noch ein attribute z.b. informaboutAttack welches dann gleich beide readings Richtung defaultPeer schickt. Da muss aber nicht sein, kann man auch mit notify machen.

2. Ich habe auch mal allowedPeer gelöscht und das selber in einem notify abgehandelt. Dabei ist mir aufgefallen, dass msgSender auf den Namen gesetzt wird, welchen der jeweilige user bei sich selber konfiguriert hat. Wenn mich jemand belästigt, nutzt mir der Name wenig, die Telefonnr. wäre gefragt. Mit get contacts kann ich nachschauen ich weiß, aber in einem reading wäre praktischer, um sie direkt verarbeiten zu können. Falls du in Betracht ziehst 1. umzusetzen, wäre das hier auch ein Thema.

3. Wenn der client nicht authentifiziert ist und "/fav" schickt, kommt keine Antwort. Ich denke die Favoriten könnte man ohne Authentifizierung verraten. Perfekt wiederrum wär ein attribute z.b. sendFavWoAuth oder so. Denn es kann ja auch Favoriten geben, die keine Authentifizierung erfordern und diese müsste man sich ansonsten merken. Toll wäre auch eine Markierung in den gesendeten Favoriten ob authentifizierungspflichtig oder nicht ähnlich wie bei get favorites.

4. Generell gibt es kein feedback bei Nachrichten ohne cmdKeyword oder ungültigem googleauth code. Irgendein feedback wäre gut, damit man weiß, dass alles läuft. Ev. ein attribute dummyResponse oder etwas fix implementieren.

5. Bei Telegram hatte ich manche Favoriten welche aus mehreren commandos bestanden, z.B. set a_steckdose_dlanpoe on; sleep 90; set kamera cmd 2. Ich denke du splittest das reading anhand ; somit wird es schwierig. Ich werde wohl dummy und notify verwenden müssen.

6. Eine Nachricht am client wäre schön, wenn der authTimeout abläuft.


Ich hoffe ich nerve dich damit nicht zu sehr

Gruß,
Christian

[Adimarantis]

1. Wenn allowedPeer gesetzt ist, bekommt man wie ja in der commandref beschrieben anhand von events nicht mit, falls jemand der eigentlich nicht soll, Nachrichten schickt. Ist vielleicht etwas übertrieben, aber siehst du eine Möglichkeit bzw. hast du Lust die readings z.B. msgSenderAttacker und msgTextAttacker einzubauen? Perfekt wäre noch ein attribute z.b. informaboutAttack welches dann gleich beide readings Richtung defaultPeer schickt. Da muss aber nicht sein, kann man auch mit notify machen.

Könnte ich mir generell schon vorstellen. Da würde ich dann aber alle Fälle zusammenlegen: not allowed, not authorized etc.

2. Ich habe auch mal allowedPeer gelöscht und das selber in einem notify abgehandelt. Dabei ist mir aufgefallen, dass msgSender auf den Namen gesetzt wird, welchen der jeweilige user bei sich selber konfiguriert hat. Wenn mich jemand belästigt, nutzt mir der Name wenig, die Telefonnr. wäre gefragt. Mit get contacts kann ich nachschauen ich weiß, aber in einem reading wäre praktischer, um sie direkt verarbeiten zu können. Falls du in Betracht ziehst 1. umzusetzen, wäre das hier auch ein Thema.

Im Falle von (1) die Nummer anzuzeigen macht sicher Sinn damit man sich nicht hinter einem Namen verstecken kann der ggf. nicht eindeutig ist.
In msgSender würde ich das nicht tun - da geht es ja um die Lesbarkeit.
Prinzipiell kannst du durch ein "set contact" einen eigenen Namen übergeben, um vor Änderungen sicher zu sein. Ich habe allerdings gerade festgestellt, dass dies in signal-cli 0.9.2 nicht funktioniert und man trotzdem immer den vom Anwender hinterlegten Namen bekommt. In signal-cli 0.10.0 scheint das aber zu gehen.

3. Wenn der client nicht authentifiziert ist und "/fav" schickt, kommt keine Antwort. Ich denke die Favoriten könnte man ohne Authentifizierung verraten. Perfekt wiederrum wär ein attribute z.b. sendFavWoAuth oder so. Denn es kann ja auch Favoriten geben, die keine Authentifizierung erfordern und diese müsste man sich ansonsten merken. Toll wäre auch eine Markierung in den gesendeten Favoriten ob authentifizierungspflichtig oder nicht ähnlich wie bei get favorites.

Das sehe ich kritisch. Die Befehlsliste gibt potentiell sensible Informationen preis, welche dann "jeder" auflisten könnte.
Ich wollte ursprünglich einfach die Ausgabe des "get favorites" auch in Signal ausgeben - auf dem Handy ist das aber extrem unübersichtlich.
Einfacher Workaround für beides:
Einfach das erste favorite so definieren:[full]-get SignalBot favorites
Dann bekommt man mit "/fav full" oder "/fav 1" alle Details - und zwar ohne Authentifizierung

4. Generell gibt es kein feedback bei Nachrichten ohne cmdKeyword oder ungültigem googleauth code. Irgendein feedback wäre gut, damit man weiß, dass alles läuft. Ev. ein attribute dummyResponse oder etwas fix implementieren.

Ja, das ist nicht ganz konsistent. Dazu müsste der Code allerdings etwas stärker umgebaut werden. An der Stelle im Code die die Attribute abtestet weiss ich teilweise noch gar nicht ob das ein Fehler ist, weil es noch weitere Alternativen gibt. Über den Signal Kanal würde ich jetzt aber tendenziell gar nicht mehr Meldungen zurücksenden - je mehr Infos ein "Angreifer" bekommt, je motivierter könnte er sein rumzuprobieren. Könnte mir aber vorstellen entsprechend was in "lasterr" zu schreiben.

5. Bei Telegram hatte ich manche Favoriten welche aus mehreren commandos bestanden, z.B. set a_steckdose_dlanpoe on; sleep 90; set kamera cmd 2. Ich denke du splittest das reading anhand ; somit wird es schwierig. Ich werde wohl dummy und notify verwenden müssen.

Ich hatte eigentlich vor das möglichst kompatibel zu Telegram zu machen. Den Aspekt habe ich wohl übersehen. Muss ich mir nochmal ansehen. Könnte allerdings bedeuten, das eine Änderung dann nicht mehr kompatibel ist.

6. Eine Nachricht am client wäre schön, wenn der authTimeout abläuft.

Jein - ich kann mir auch vorstellen, dass dies irgendwann nervt.

Gruß,
Jörg

[weini]

3. Wenn der client nicht authentifiziert ist und "/fav" schickt, kommt keine Antwort. Ich denke die Favoriten könnte man ohne Authentifizierung verraten. Perfekt wiederrum wär ein attribute z.b. sendFavWoAuth oder so. Denn es kann ja auch Favoriten geben, die keine Authentifizierung erfordern und diese müsste man sich ansonsten merken. Toll wäre auch eine Markierung in den gesendeten Favoriten ob authentifizierungspflichtig oder nicht ähnlich wie bei get favorites.

Das sehe ich kritisch. Die Befehlsliste gibt potentiell sensible Informationen preis, welche dann "jeder" auflisten könnte.
Ich wollte ursprünglich einfach die Ausgabe des "get favorites" auch in Signal ausgeben - auf dem Handy ist das aber extrem unübersichtlich.
Einfacher Workaround für beides:
Einfach das erste favorite so definieren:[full]-get SignalBot favorites
Dann bekommt man mit "/fav full" oder "/fav 1" alle Details - und zwar ohne Authentifizierung

Ich möchte hier auch nochmal in die selbe Kerbe hauen (wie schon per PN): Eine Möglichkeit, die Favoriten ohne Authentifizierung aufzulisten würde ich sehr begrüßen.
Die Inhalte sind aus meiner Sicht nicht so kritisch. Es ist ja nicht so, dass die Infos öffentlich zugänglich sind. So lange wir Signal als Provider vertrauen, ist die Abschottung über "allowedPeer" hinreichend.
Der geschilderte Workaround ist eine gute Option. Ich stolpere aber oft drüber, dass ich bei seltener Nutzung die Syntax nicht mehr genau weiß. Da ist "/fav" dann einfach eingängiger als "/fav full".

[Adimarantis]

Da ist "/fav" dann einfach eingängiger als "/fav full".

Wie wärs dann mit /fav list
Ich glaube sich das zu merken ist zumutbar Und dann mache ich für Leute mit mehr Sicherheitsbedenken kein Scheunentor auf.

Zu den restlichen Punkten:
- Telegrambot unterteilt Befehlsketten mit ;; - das habe ich jetzt in einer Testversion schon eingebaut und klappt so.

- Ich mache die Konfiguration jetzt etwas einfacher: der authTimeout hat jetzt den default 300 (will man das Feature temporär abschalten, kann man es auf 0 setzen, was vorher default war). Das authDevice wird jetzt auch automatisch gesetzt, wenn man das cmdKeyword definiert und wenn es fehlt gibt es eine Meldung in lastError wenn ein Befehl ohne authDevice empfangen wird. Über Signal gibt es aber keine Rückmeldung, da muss man schon ins Device schauen.

- allowedPeer/Authorisierungsfehler:
Weitere readings einzuführen finde ich unübersichtlich. Ich habe das jetzt ebenfalls in lastError abgebildet - auch darauf kann man Notfalls ein NOTIFY legen und entsprechend parsen (immer mit Nummer statt Kontaktnamen):
Ignored message due to allowedPeer by +49...:message
Invalid token sent by +49...:message
Unauthorized command request by +49...:message
Zusätzlich landet die selbe Nachricht ab verbose=2 im Logfile

Mit dem Release warte ich jetzt noch ein wenig. Aktueller Stand im github:
https://github.com/bublath/FHEM-Signalbot/blob/main/50_Signalbot.pm

[Kohle77]

Hallo,
ich bin jetzt endlich umgezogen und habe jetzt ein neues Problemchen.

Code Auswählen Erweitern


VERSION Signalbot:3.2 signal-cli:0.9.0 Protocol::DBus:0.19
model Raspbian GNU/Linux 10 (buster)


Wenn ich einen sudo reboot now mache startet der dbus-org.asamk.Signal.service nicht mehr.
Das config file ist vorhanden:

Code Auswählen Erweitern


pi@raspberrypi:/etc/dbus-1/system.d $ cat org.asamk.Signal.conf
<?xml version="1.0"?> <!--*-nxml-*-->
        <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
          "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

        <busconfig>
          <policy user="signal-cli">
                  <allow own="org.asamk.Signal"/>
                  <allow send_destination="org.asamk.Signal"/>
                  <allow receive_sender="org.asamk.Signal"/>
          </policy>

          <policy context="default">
                  <allow send_destination="org.asamk.Signal"/>
                  <allow receive_sender="org.asamk.Signal"/>
          </policy>
        </busconfig>



aber der service läuft nicht:

Code Auswählen Erweitern


pi@raspberrypi:/etc/dbus-1/system.d $ sudo systemctl status dbus-org.asamk.Signal.service
? signal.service - Send secure messages to Signal clients
   Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Sat 2022-01-15 05:20:55 CET; 81ms ago
  Process: 494 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=143)
Main PID: 494 (code=exited, status=143)

Jan 15 05:19:13 raspberrypi systemd[1]: Starting Send secure messages to Signal clients...
Jan 15 05:20:54 raspberrypi systemd[1]: signal.service: Start operation timed out. Terminating.
Jan 15 05:20:55 raspberrypi systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Jan 15 05:20:55 raspberrypi systemd[1]: signal.service: Failed with result 'timeout'.
Jan 15 05:20:55 raspberrypi systemd[1]: Failed to start Send secure messages to Signal clients.


Mache ich dann mit dem script ein test:

Code Auswählen Erweitern


pi@raspberrypi:~ $ sudo ./signal_install.sh test
You chose the following option: test

Start signal-cli service
Checking installation via dbus-send command...success
Sending a message via perl Protocol::DBus...reply received


und der service läuft danach auch wieder

Code Auswählen Erweitern


pi@raspberrypi:~ $ sudo systemctl status dbus-org.asamk.Signal.service
? signal.service - Send secure messages to Signal clients
   Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2022-01-15 05:22:30 CET; 6min ago
Main PID: 1412 (java)
    Tasks: 32 (limit: 2059)
   CGroup: /system.slice/signal.service
           +-1412 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.0.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.69.jar:/opt/signal/lib/argparse4j-0.9.0.jar:/opt/signal/lib/dbus-java-3.3.0.jar:/opt/signal/lib/slf4j-

Jan 15 05:21:19 raspberrypi systemd[1]: Starting Send secure messages to Signal clients...
Jan 15 05:22:30 raspberrypi signal-cli[1412]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_49xxxxxxxxx
Jan 15 05:22:30 raspberrypi systemd[1]: Started Send secure messages to Signal clients.


Jetzt noch ein reinit aus der FHEM GUI und alles läuft wieder.
Stellt sich die Frage warum der service nach einem reboot nicht startet?

Da hier auch über features gesprochen wird. Wäre es möglich das script zur installation zu ändern um einfach ein backup zu machen das man auf einer neuen installation mit restore einfach restoren kann?

Gruß
Christian

[Adimarantis]

Wenn es nur nach dem reboot passiert ist dein Raspberry evtl. so beschäftigt, dass er innerhalb des standard 90s timeout nicht hoch kommt.
Da hatten wir weiter vorne im Thread schon mal einen Tipp wie man den erhöht.

Edit: Ich hab den Hinweis jetzt im Wiki Troubleshooting ergänzt.

Dass mit dem Backup/Restore sollte kein großes Problem sein.

[Adimarantis]

Weitere updates auf Github: https://github.com/bublath/FHEM-Signalbot

- Installer unterstützt backup/restore und einen "experimental" modus mit dem signal-cli 0.10.0 inklusive Java17 installiert werden kann
- Favorites Attribut wird jetzt im "Editor" bearbeitet und ignoriert "newlines" damit das bei längeren Listen übersichtlicher editiert werden kann
- Die Fehlerbehandlung für unauthorisierte Anfragen ist etwas konsistenter

Rückmeldungen wären schön bevor ich die Version freigebe

Jörg

[weini]

Auf die Gefahr hin, dass ich mich unbeliebt mache: 
Ich habe heute Vormittag einen Patch gebaut, mit dem man über ein "-" Präfix bei cmdFavorites steuern kann, ob die Favoriten ohne GoogleAuth aufgelistete werden können.
Der Patch wurde gegen die Version 3.3.4 gebaut und getestet. Jörg ist einfach zu schnell für micht mit den Versionen.

@Jörg: Vielleicht kannst du mal kurz draufschauen, es passt aus meiner Sicht zu deinem Konzept und besteht nur aus wenigen Zeilen. Wenn du ablehnst, dann gebe ich endgültig Ruhe

VG,
weini

[Adimarantis]

Da ist einer aber sehr hartnäckig.

Guckst du GitHub.

Außerdem, habe ich mir gedacht, dass die Rückgabe von Werten sicher ein häufiger Use Case sein könnte.
Daher geht jetzt auch sowas:

Code Auswählen Erweitern


[temp]print Im Wohnzimmer sind es [dht11_5:temperature] °C;
oder auch als Perl

Code Auswählen Erweitern

[temp]{my $var=ReadingsVal("dht11_5","temperature",0);;return $var;;}

Ist aber noch nicht gut durchgetestet.

[Adimarantis]

Immer noch nur auf Github:
Hauptsächlich technische Umbauten und Aufräumarbeiten (teilweise Vorbereitungen auf signal-cli 0.10+)
Aber auch ein kleines neues Feature:

Die Favoriten sind ja nicht die einzige Möglichkeit etwas auszuführen, sondern es geht ja auch mit Notify/DOIF. Hier stellt sich aber immer die Frage, wem soll man antworten.
Dazu ein neues "set" Kommando "reply"
Schickt eine Nachricht an den Empfänger (primär Gruppe, sonst Einzelempfänger) von dem die letzte Nachricht kam.

[kroman]

Jetzt war ich gerade mit dem Testen der vorletzten Version fertig. Folgendes gibt es zu berichten:

- bzgl. msgSender != allowedPeer kann ich mit lastError etwas anfangen. Es wird auch die Telefonnr. und nicht der Name angezeigt, danke.

Code Auswählen Erweitern

define n_signalbot_lasterror notify signalbot:lastError:.* {
my $error = (split 'lastError: ', $EVENT)[1];
if ($error =~ m/^Ignored message due to allowedPeer by/) {
fhem ("set signalbot send \@xxx $error");
}
}


- wenn der authTimeout abläuft, wir das reading msgAuth nicht auf 0 gesetzt. Das passiert erst, wenn vom client etwas kommt. Somit kann man darauf nicht reagieren.

- weini's Idee mit "attr signalbot cmdFavorite -fav" funktioniert nicht, wenn cmdKeyword ungleich "=" ist, also mit meinem "/" z.B. funktioniert es nicht.

- mehrere commandos in einem Favoriten funktioniert

- die Länge eines Favoriten auf den client geschickt scheint begrenzt zu sein.
Bei attr signalbot favorites 123456789012345678901234567890 kommt folgendes an:

Code Auswählen Erweitern

Defined favorites:

ID [Alias] Command
1 1234567890123456789012...


- wenn der 1. Favorit mit "-" versehen ist, wird das nicht angezeigt, wird aber ohne Authentifizierung ausgeführt.

Code Auswählen Erweitern


attr signalbot favorites -set dummy1 on; -set dummy2 on; -set dummy2 on

Defined favorites:

ID [Alias] Command
1 set dummy1 on
2  -set dummy2 on
3  -set dummy2 on


[Adimarantis]

- wenn der authTimeout abläuft, wir das reading msgAuth nicht auf 0 gesetzt. Das passiert erst, wenn vom client etwas kommt. Somit kann man darauf nicht reagieren.

Das msgAuth gehört ja zu Message und kann für verschiedene Sender unabhängig sein. Es zeigt also nicht den Zustand "gerade authorisiert" an, sondern ob zum Zeitpunkt als die letzte Message empfangen wurde, der jeweilige Absender authorisiert war, daher wäre ein Event bei Ablauf nicht korrekt

- die Länge eines Favoriten auf den client geschickt scheint begrenzt zu sein.

That's a feature: Die Favoriten können ja durch Befehlsverkettung etc. sehr lang werden - daher schneide ich sie so ab, dass es auf dem Handy lesbar bleibt. Vollständig sieht man es über get favorites

- wenn der 1. Favorit mit "-" versehen ist, wird das nicht angezeigt, wird aber ohne Authentifizierung ausgeführt.

Hier ist der Fehler ein anderer: Du hast Leerzeichen vor dem "-" womit sie unwirksam und als Teil des Befehls geparsed werden. Ich zeige das "-" eigentlich gar nicht an.
Das wird auch mit "get favorites" klar dargestellt und funktioniert auch nicht. Aktuell findet keinerlei Überprüfung des Attributs statt - aber "get favorites" zeigt ganz gut, ob alles richtig interpretiert wird. Eine Fehlerprüfung wäre evtl. noch ein ToDo

- weini's Idee mit "attr signalbot cmdFavorite -fav" funktioniert nicht, wenn cmdKeyword ungleich "=" ist, also mit meinem "/" z.B. funktioniert es nicht.

Das kann ich zumindest in meiner aktuellen Version (und da hab ich länger nichts mehr geändert) nicht nachvollziehen. Nur zur Sicherheit: Das greift nur für die Auflistung ("/fav")

[weini]

Also bei mir funktionert cmdFavorites mit "-" Prefix auch, wenn ich ein anderes cmdKeyword verwende.

@kroman: Kannst du mal testen, ob es ggf. am "/" liegt. Nicht dass der eine Sonderfuktion in Perl hat...