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

[Adimarantis]

Also ich hab das mal kurz durchgespielt:
Wenn du der letzte in der Gruppe bist, dann kannst du mit "set ... group quit <groupname>" die Gruppe verlassen.
Sie bleibt dann in "get groups" sichtbar, aber dann kannst du "group delete <groupname"> machen und sie verschwindet endgültig.

[Sailor]

Moin!

Also ich hab das mal kurz durchgespielt:
Wenn du der letzte in der Gruppe bist, dann kannst du mit "set ... group quit <groupname>" die Gruppe verlassen.
Sie bleibt dann in "get groups" sichtbar, aber dann kannst du "group delete <groupname"> machen und sie verschwindet endgültig.

DAS hat geholfen! Danke!

Vorschlag: Den Befehl "groupquit" mit in die setList aufnehmen.

Gruß
    Sailor

[Aeroschmelz]

[SOLVED]
Nach Update auf die aktuelle Version geht das wieder!

Hallo,

mir ist gerade aufgefallen, dass das senden eines definierten uiTable wie z.B.

Code Auswählen Erweitern

send @Marcus &Di_Sprit


oder eines SVG Plots 

Code Auswählen Erweitern

send @Joerg &SVG_Aussentemperatur


zumindest bei mir nicht mehr funktioniert. Alles andere funktioniert weiterhin. Kann das jemand bestätigen? Im Log erscheint bei Verbose 5 kein Fehler:

Code Auswählen Erweitern

2024.10.10 19:25:36 3: Signalbot: Before parse:@Marcus &Di_Sprit:
2024.10.10 19:25:36 4: Signalbot: Attachment matches device Di_Sprit of type DOIF
2024.10.10 19:25:36 4: Signalbot: sendMessage called for Marcus:/tmp/signalbot1728581136.92653.png:
2024.10.10 19:25:36 5: Signalbot: Dbus Call sync:0 sendMessage(sasas) /org/asamk/Signal/_4961172389577 Args:,ARRAY(0x7ec1a40),ARRAY(0x82ea5b0)
2024.10.10 19:25:37 5: Signalbot: DBus callback: sendMessage Args:1728581137550

Habe aber eine relativ alte Version:

Code Auswählen Erweitern

Internals:
[code]   FD         17
   FUUID     
   NAME       Signalbot
   NOTIFYDEV  global
   NR         57
   NTFY_ORDER 50-Signalbot
   STATE      Connected to /org/asamk/Signal/_4961172389577
   TYPE       Signalbot
   VERSION    Signalbot:3.20 signal-cli:0.12.8 Protocol::DBus:0.22
   eventCount 341
   model      Raspbian GNU/Linux 11 (bullseye)

Kann es eventuell daran liegen?

VG
Marcus

[Adimarantis]

Schau mal ins Wiki unter Troubleshooting.
Was du probieren kannst:
- Kannst du denn vom Handy an FHEM senden?
- "Trust" herstellen
- Nachricht von der Kommandozeile senden

[enno]

Moin Marcus,

hatte nach einem Update das gleiche Problem. Es wurde unter anderem Java aktuallisiert. Nachdem ich das hier https://wiki.fhem.de/wiki/Signalbot#Installation beschriebene Script

Code Auswählen Erweitern

signal_install.shohne Parameter durchlaufen lassen habe, wurde meine Javaversion bemengelt. Als das korrigiert wurde lief alles wieder.

Gruss
  Enno

[nitzerebb]

Hallo zusammen,

ich verzweifle aktuell mit dem Update vom Signalbot auf 0.13.6
Das Ganze läuft auf Debian:

Code Auswählen Erweitern

root@SRV03:~# lsb_release -d && uname -r
Description:    Debian GNU/Linux 11 (bullseye)
5.10.0-31-amd64

Signalbot & Co. betreibe ich aktuell in diesen Versionen:
Signalbot:3.19 signal-cli:0.13.1 Protocol::DBus:0.22

Das Update versuche ich ganz normal über das neueste "signal_install.sh" Skript.
Ich habe auch schon die Libraries versucht zu "downgraden", wie z.B. im Beitrag 1281 beschrieben (LIBRARYVERSION="0.52.0"), leider bleibt alles erfolglos.
Das Skript endet immer damit, dass der Service nicht mehr startet:

Code Auswählen Erweitern

Start signal-cli service
Job for signal.service failed because the control process exited with error code.
See "systemctl status signal.service" and "journalctl -xe" for details.
Checking installation via dbus-send command...Error org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
unexpected reply

Sending a message via perl Protocol::DBus...Error getting reply


Code Auswählen Erweitern

root@SRV03:~# systemctl status signal.service
● signal.service - Send secure messages to Signal clients
     Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2024-11-01 19:44:19 CET; 18s ago
    Process: 1869983 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
    Process: 1870043 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1/FAILURE)
   Main PID: 1870043 (code=exited, status=1/FAILURE)
        CPU: 2.061s

Nov 01 19:44:07 SRV03 systemd[1]: Starting Send secure messages to Signal clients...
Nov 01 19:44:18 SRV03 signal-cli[1870043]: SLF4J(I): Connected with provider of type [ch.qos.logback.classic.spi.LogbackServiceProvider]
Nov 01 19:44:19 SRV03 signal-cli[1870043]: WARN  Manager - Failed to call libsignal-client: /tmp/libsignal14356183373830739431/libsignal_jn>
Nov 01 19:44:19 SRV03 signal-cli[1870043]: Missing required native library dependency: libsignal-client
Nov 01 19:44:19 SRV03 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Nov 01 19:44:19 SRV03 systemd[1]: signal.service: Failed with result 'exit-code'.
Nov 01 19:44:19 SRV03 systemd[1]: Failed to start Send secure messages to Signal clients.
Nov 01 19:44:19 SRV03 systemd[1]: signal.service: Consumed 2.061s CPU time.


Code Auswählen Erweitern

root@SRV03:~# journalctl -xe
 Defined-By: systemd
 Support: https://www.debian.org/support

 The unit systemd-localed.service has successfully entered the 'dead' state.
Nov 01 12:03:03 SRV03 systemd[1]: systemd-hostnamed.service: Succeeded.
 Subject: Unit succeeded
 Defined-By: systemd
 Support: https://www.debian.org/support

 The unit systemd-hostnamed.service has successfully entered the 'dead' state.
Nov 01 12:03:07 SRV03 dbus-daemon[678]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Nov 01 12:03:17 SRV03 dbus-daemon[678]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.servic>
Nov 01 12:03:17 SRV03 systemd[1]: Starting Send secure messages to Signal clients...
 Subject: A start job for unit signal.service has begun execution
 Defined-By: systemd
 Support: https://www.debian.org/support

 A start job for unit signal.service has begun execution.

 The job identifier is 1172.
Nov 01 12:03:25 SRV03 sudo[1549]: pam_unix(sudo:session): session closed for user root

Hat jemand ne Idee, was ich falsch mache ?
Bin für jeden Tipp dankbar

Vielen Dank vorab
Gruss Jan

[Adimarantis]

Versuch mal eine Nachricht von der Kommandozeile zu versenden um zu sehen welchen Fehler du bekommst. Siehe https://wiki.fhem.de/wiki/Signalbot#Versenden_von_Nachrichten_ohne_FHEM

Liegt ziemlich sicher an dem zitierten Problem mit der glibc. Ich schätze mal ein Upgrade auf Debian 12 kommt nicht in Frage?

[Adimarantis]

Habs in meiner Debian 11 VM auch mal probiert und sehe das selbe Problem. Defintiv das glibc Thema. Inzwischen bringt da auch ein Downgrade mit dem Script nichts, weil die library jetzt libsignal_jni_amd64.so (also mit amd64) heisst und anscheinend jetzt auch libraries für Mac und Windows mit ausgeliefert werden (womit die lib jetzt 41MB hat). Leider nicht für Raspberry.

Ich hab mal auf Debian 11 die lib für amd64 übersetzt. Dieses File bitte runterladen und in /opt/signal/lib ersetzen:
http://bublath.de/libsignal-client-0.58.2.jar

Achtung das ist jetzt bereits für signal-cli 0.13.9 - install Script ist eingecheckt und kann mit "reinit" aktualisiert werden. Also erst aktualisieren, Fehler ignorieren, Datei ersetzen und nochmal "service signal start" - dann läufts hoffentlich wieder.

Wird immer schwieriger den Support für "ältere" Systeme aufrechtzuerhalten. Signal-cli unterstützt halt generall nur die neusten Distributionen und Java Versionen. Wenn ich mal viel Zeit habe, muss ich mir anschauen, ob man das ganze nicht von DBUS auf REST-API umstellen kann. Dann kann signal-cli in einem separaten Container (da gibt es schon einen vorgefertigten) laufen - oder auf einem anderen System, was die ganze Prozedur flexibler machen sollte.

[nitzerebb]

Habs in meiner Debian 11 VM auch mal probiert und sehe das selbe Problem. Defintiv das glibc Thema. Inzwischen bringt da auch ein Downgrade mit dem Script nichts, weil die library jetzt libsignal_jni_amd64.so (also mit amd64) heisst und anscheinend jetzt auch libraries für Mac und Windows mit ausgeliefert werden (womit die lib jetzt 41MB hat). Leider nicht für Raspberry.

Ich hab mal auf Debian 11 die lib für amd64 übersetzt. Dieses File bitte runterladen und in /opt/signal/lib ersetzen:
http://bublath.de/libsignal-client-0.58.2.jar

Achtung das ist jetzt bereits für signal-cli 0.13.9 - install Script ist eingecheckt und kann mit "reinit" aktualisiert werden. Also erst aktualisieren, Fehler ignorieren, Datei ersetzen und nochmal "service signal start" - dann läufts hoffentlich wieder.

Wird immer schwieriger den Support für "ältere" Systeme aufrechtzuerhalten. Signal-cli unterstützt halt generall nur die neusten Distributionen und Java Versionen. Wenn ich mal viel Zeit habe, muss ich mir anschauen, ob man das ganze nicht von DBUS auf REST-API umstellen kann. Dann kann signal-cli in einem separaten Container (da gibt es schon einen vorgefertigten) laufen - oder auf einem anderen System, was die ganze Prozedur flexibler machen sollte.

Danke, das hat funktioniert !!!
Läuft wieder

[privat58]

Hallo,
nachdem Signal unter fhem nicht mehr funktionierte (es wurde nur noch Text verschickt und keine Bilder mehr)
hatte ich alles gelöscht und mit dem script signal_install.sh wieder installiert. Leider hatte ich es erst mit einer älteren Version des skriptes probiert und war damit gescheitert. Mit dem Script unter /opt/fhem/www/signal/ ging das installieren problemlos.
Registriert habe ich auf der Kommandozeile (über fhem bin ich beim captcha gescheitert) und ich kann problemlos Nachrichten als Text auf der Kommandozeile versenden.
Von fhem geht aber nichts und Signal meldet nur disconnected.
Betriebssystem ist Ubuntu auf einem NUC.
Kann mir eventuell jemand auf die Sprünge helfen?
Danke

[weini]

Ich hab mal auf Debian 11 die lib für amd64 übersetzt.

D. h., für Raspbian müsste ich selbst übersetzen, korrekt? Oder ist die jar für amd64 und arm64 identisch?

[Adimarantis]

@Weini: Arm64 (aarch64) und amd64 (x86) sind zwei komplett unterschiedliche Architekturen und nicht kompatibel.

D.h. ja - wenn dein Raspberry noch unter Raspbian 10 läuft, dann müsste man dafür die library neu übersetzen. Da ich inzwischen auch mein Produktivsystem auf Bookworm hochgezogen habe, habe ich auf die Schnelle kein solches System mehr zur Hand.
Ich hatte auch bereits andere Pakete (z.b. Node) die einfach nicht mehr auf meinem alten (allerdings "Buster") System liefen und habe mich deshalb für den schmerzhaften Weg entschieden gleich auf die neuste Version zu gehen um auch komplett auf 64 Bit umzustellen.

[weini]

Ich bin auf Debian 11, aber das läuft vermutlich aufs selbe raus.
Prüfe jetzt gerade ein In-Place Upgrade auf 12, das wäre sicher die sinnvollste Variante...

[Adimarantis]

@Privat58: Da bräuchte ich schon mehr Infos.
Eine Sache die man z.B. schnell falsch machen kann, ist wenn man auf der Kommandozeile nicht unter dem signal-cli User arbeitet und /var/lib/signal-cli als Verzeichnis für die Config angibt. Dann landet nämlich alles in einer lokalen Registrierung. Die kann man aber unter Anpassung der Rechte kopieren (vorher service stoppen).
Mehr logfiles, verwendete Kommandos etc. wären hilfreich um das Problem einzugrenzen.

[privat58]

@Adimarantis
und genau das war das Problem. Da hatte ich nicht beachtet.
Jetzt funktioniert alles wieder.
Vielen Dank