Hallo,
Signalbot ist eine Neuentwicklung eines Signal Messenger Moduls sehr ähnlich zu SiSi. Es ist parallel dazu entstanden und verfolgt intern ein paar andere Implementierungsansätze, verwendet aber letztendlich die selbe Kommunikationsschnittstelle (über DBus nach signal-cli).
Inzwischen habe ich auch einiges an Code und Ideen von SiSi und Telegrambot (danke die jeweiligen Autoren) übernommen und es gibt eine direkte Integration mit Babble.
Es gibt auch ein Installationsscript für Ubuntu and Raspbian, was Einsteigern die Verwendung erleichtern soll (die Installation von signal-cli hat seine Tücken).
Bitte alles weitere der dem Wiki unter https://wiki.fhem.de/wiki/Signalbot entnehmen oder in die Commandref (nur englisch) schauen.
Gruß,
Jörg
Moin Jörg,
bei einen Neustart kommt FHEM bei mir nicht mehr hoch. Es bricht mit dieser Zeile ab:
Can't use string ("") as a HASH ref while "strict refs" in use at ./FHEM/50_Signalbot.pm line 463.
Wenn ich in der fhem.cfg das Device auskommentiere, starte FHEM wieder. Wenn ich das Device dann mit defmod SIGNAL Signalbot
attr SIGNAL DbLogExclude .*
attr SIGNAL defaultPeer #Smarthome
attr SIGNAL devStateIcon .*Connected:ios-on-green .*Disconnected:ios-NACK
attr SIGNAL group 00 Adapter
attr SIGNAL room 75 SIGNAL,SYSTEM
setstate SIGNAL Connected anlege läuft FHEM normal und alles ist gut. Wenn ich neu starte hängt es wieder. Hast du eine Idee, woran das liegen könnte?
Gruss
Enno
Hallo Enno,
Den Effekt kann ich bei mir nicht nachvollziehen. Eventuell eine race condition weil dein System schneller ist.
Ich habe jetzt noch einen Test eingebaut der verhindert, dass die entsprechende Funktion aufgerufen wird, falls FHEM noch nicht vollständig oben ist (wobei das eigentlich gar nicht passieren sollte). Probier mal das update im ersten Post.
Jörg
Habs gefunden. Mich hatte irritiert dass der Fehler bei dir beim Startup kam. Du scheinst da sofort eine Gruppen Message rauszuballern.
Das Problem trat auf wenn eine Gruppennachricht an eine unbekannte Gruppe (nach einem Neustart erstmal alle) verschickt wird.
Update oben.
Gruß,
Jörg
Ich hatte gestern noch ein wenig mit Babble herumexperimentiert und mal testweise einen direkten Support dafür eingebaut.
Vorgehensweise:
Attribut babblePeer: Nur wenn die Message von diesem Sender kam wird Babble angeworfen
Attribut babbleDev: Der Name der definierten babble Device (nicht babbleDevice, weil es sonst einen Konflikt mit dem Babble Attribut gibt) - Todo: da es normalerweise nur ein Device gibt, könnte Signalbot das evtl. sogar selbst finden
Beispiel Config:
Device "out_temp" mit babbleDevice="Temperatur", room="Draußen", verb="Sagen", Ziel="Status", Aktion="set SignalBot send @$PARM0 Die Temperatur draußen ist [out_temp:temperature] Grad"
Frage: "Wie ist die Temperatur Draußen"
Antwort: "Die Temperatur draußen ist 1.0 Grad"
Die Antwort (in $PARM0) geht wahrscheinlich immer an den babblePeer (eigentlich an den Absender in der Prio Gruppe,Sender,babblePeer , aber das dürfte am Ende immer der babblePeer sein).
Damit Gruppen und Kontakte hier redundant verwendet werden können, akzeptiert Signalbot jetzt auch @#Gruppe als Gruppenamen (also wie bei SiSi). Ein einzelnes "#" geht natürlich immer noch.
Bekannte Probleme: Sonderzeichen (hier das "ß" gehen auf dem Weg über Babble irgendwie kaputt. Das ist evtl. noch eine Umwandlung notwendig.
Viel Spass bei Testen. Anregungen von erfahrenen Babble Nutzern willkommen.
Jörg
Zur Info: ich habe eine/die FHEM-Wiki Seite für Signalbot (https://wiki.fhem.de/wiki/Signalbot) angelegt.
Zunächst mal nur Basisinformationen; werde das spätestens dann erweitern, wenn ich (für demnächst geplant) beginne, das Modul aktiv zu benutzen. Darf aber gern (-> Wiki) gern auch von anderen erweitert (korrigiert sowieso) werden.
Peter
Zitat von: Adimarantis am 01 Februar 2021, 00:06:10
Habs gefunden.
Habe die Version von 17:00 Uhr heute eingespielt. Reboot und FHEM startet wieder. Fehler scheint behoben :) Super!
Gruss
Enno
Moin
ich habe Babble wie folgt eingebunden:
Ein DOIF reagiert auf alle reinkommende Nachrichten. als letztes DOELSEIF steht:
DOELSEIF ([SIGNAL:msgText] and [?SIGNAL:msgGroupName] eq "Smarthome")(setreading SIGNAL myGroup Smarthome,set Babble doit [SIGNAL:msgText])
Im Babble Device habe ich folgende Atribute gesetzt:
attr Babble confirmFunc {fhem('set SIGNAL send #'.ReadingsVal('SIGNAL','myGroup',0).' '.('OK'))}
attr Babble helpFunc {fhem('set SIGNAL send #'.ReadingsVal('SIGNAL','myGroup',0).' '.('$HELP'))}
Beispiel Config:
Device "out_temp" mit babbleDevice="Temperatur", room="Draußen", verb="Sagen", Ziel="Status",
Aktion="{fhem('set SIGNAL send #'.ReadingsVal('SIGNAL','myGroup',0).(' Die Temperatur im Garten beträgt '.ReadingsVal('out_temp','temperature',0).' Grad'))}"
Gruss
Enno
Hi Enno,
Das DOIF könntest du dir halt jetzt evtl. sparen
Babble Config:
draußen:
sagen:
status set SignalBot send @$PARM0 Die Temperatur draußen ist [out_temp:temperature] Grad
confirmFunc {fhem("set SignalBot send \@$PARM0 Ok!")}
helpFunc {fhem("set SignalBot send \@$PARM0 $HELP")}
und im Signalbot eben entsprechend babblePeer und babbleDev setzen. Vorallem auch den Umweg über Readingsval und myGroup.
Zu diskutieren wäre hier evtl. was in PARM0 (und PARM1, PARM2 ...) an Infos mitgeliefert werden soll.
Aktuell kann halt babblePeer nur einen Wert enthalten - ich denke das müsste für eine flexible Nutzung eher eine Liste werden.
Jörg
Zitat von: Adimarantis am 01 Februar 2021, 20:18:52
Das DOIF könntest du dir halt jetzt evtl. sparen
Rom und die vielen Wege. Deshalb liebe ich FHEM 8)
Jetzt werde ich mir erst einmal die formatierte Ausgabe der Nachrichten in Signal vorknöpfen. Zeilenumbrüche z.B. Stand glaube ich im alten SiSi Faden eine Lösung.
Gruss
Enno
Neu:
Nachdem die Installation nicht gerade einfach ist, habe ich ein bash script geschrieben, dass diesen Vorgang weitgehend automatisieren sollte (sollte für aktuelle Ubuntu x86 und Rasberry armv71 Versionen funktionieren - möglicherweise auch für andere Debian basierte Systeme).
sudo ./signal_install.sh
Das Script bietet eine Reihe von Optionen die im Script erläutert werden (Doku folgt wenn es besser getestet ist) und fragt üblicherweise nach bevor es etwas tut. Wichtig ist am Anfang bei PHONE= die Nummer einzutragen mit der das System verknüpft werden soll, da es auch durch den Registrierungs- bzw. Linkprozess führt.
Ich hab es erfolgreich auf meinem X86 Ubuntu System laufen lassen (mit link Option) und meine bestehende Raspberry Config hat es wie geplant nicht verändert.
Kommandozeilen Optionen:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
Das Script prüft auch auf fehlende Pakete und installiert diese mit "apt-get install" und erzeugt Verzeichnisse und User.
Mein Ubuntu war ziemlich "vanilla", also hoffe ich die meisten Abhängigkeiten gefunden zu haben, wenn was fehlen sollte, bitte Bescheid geben - natürlich auch bei sonstigen Fehlern und Verbesserungsvorschlägen
Die nativen arm libraries (schon für die nächste signal-cli version vorbereitet) werden aktuell von meiner Homepage nachgeladen. Vielleicht haben die FHEM admins hier eine Möglichkeit diese auf einen geeigneten Platz zu legen.
Ich hoffe dies ist hilfreich für alle die bisher vor einer Installation zurückgeschreckt sind.
Jörg
Hallo Jörg,
erst mal DANKE für Deine tolle "Modernisierung" von Signal
als Laie gesprochen.
Hatte meine vor langer Zeit installierte SiSi gelöscht und Dein Modul
neu aufgesetzt.
Einige Stunden hat mich aus dem Wiki die richtige Lösung für die Pfade
zur Konfigurationsdatei gekostet....
>=0.6.1
$HOME/.local/share/signal-cli/data/
hierbei musste ich /data/ weg lassen, bin halt Laie :(
Später hat zwar der Empfang in FHEM geklappt aber nicht das raus senden.
Kam leider nicht um einen Neustart des Rechners umhin trotz reload und start der Module.
Nur mal so als Stolperfallen.
Toll das DU jetzt ein script geschrieben hast, hätte ich mal noch einen Tag gewartet ;) aber
eben nebenbei noch was gelernt.
Traue mich jetzt aber erst mal nicht nochmal neu anzufangen.
Dein Modul wertet für mich die Funktionalität von FHEM nochmal stark auf!
Viele Grüße
Hans-Jürgen
Trau dich :)
Falls das Script noch nicht 100% läuft, dann funktioniert schlimmstenfalls signal-cli hinterher immer noch nicht. Ein Risiko fürs restliche System würde ich ausschließen.
Jörg
Zitat von: Adimarantis am 02 Februar 2021, 23:04:52
Trau dich :)
Moin Jörg,
ich teste es nachher mal. Als "root" das Script starten nehme ich an als User "fhem" und der Pfad bei mir "/opt/fhem"...
Ich werde berichten.
Gruss
Enno
Hi Enno,
das Script muss halt mit einem "sudo"-berechtigten User gestartet werden (und läuft dann unter root).
Die Voreinstellung im Script zielen auf eine Systeminstallation mit eigenem user, directory etc. und können gefahrlos beibehalten werden (oder natürlich auf deine aktuelle Installation angepasst werden). Startverzeichnis ist sonst irrelevant.
Eine bereits bestehende Registrierung müsste man ggf. in das neue Verzeichnis umkopieren (Rechte/Owner setzen nicht vergessen), aber am saubersten wäre wohl eine Neu-Registrierung - besonders weil ich das noch nicht richtig getestet habe :)
Falls bei der Registrierung eine Meldung kommt von wegen "locked" und "waiting", dann in einer anderen shell parallel "sudo service signal stop" ausführen, da der Systemprozess die config blockiert. Falls das Problem tatsächlich besteht sollte das wohl noch ins Script.
Danach dann wieder "sudo service signal start"
Jörg
Moin Jörg,
ich habe eine VM mit FHEM gestartet. Dann meine Festnetznummer (habe ich im Log gelöscht) registriert. Ich habe aber keinen Anruf bekommen, der mir die SMS vorliest. Hier mal das Log:
root@Test:~# sh signal.sh
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: fhem
Signal-cli Install directory: /opt/fhem
Signal config storage: /var/lib/fhem
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49yyyyyy
Your configuration
Linux Test 5.4.78-2-pve #1 SMP PVE 5.4.78-2 (Thu, 03 Dec 2020 14:26:17 +0100) x86_64 x86_64 x86_64 GNU/Linux
has not been tested, continue at own risk
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
!!! Everything needs to run with sudo !!!
Proceed (Y/n)? signal.sh: 432: read: arg count
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...installing (haveged)done
Checking for java...installing (default-jre)done
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...installing (qrencode)done
Checking for pkg-config...installing (pkg-config)done
Checking for dbus devel...installingdone
Checking for Net:DBus...Can't locate Net/DBus.pm in @INC (you may need to install the Net::DBus module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at /tmp/signal400.tmp line 5.
BEGIN failed--compilation aborted at /tmp/signal400.tmp line 5.
Installing latest NET::DBus...done
Checking user fhem ...found
Checking for /opt/fhem...found
Checking for /var/lib/fhem...created
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.7.4...uid=998(fhem) gid=20(dialout) groups=20(dialout)
done
Unpacking ...
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf.../etc/dbus-1/system.d/org.asamk.Signal.conf installed
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service.../usr/share/dbus-1/system-services/org.asamk.Signal.service installed
Checking for /etc/systemd/system/signal.service.../etc/systemd/system/signal.service installed
Created symlink /etc/systemd/system/dbus-org.asamk.Signal.service -> /etc/systemd/system/signal.service.
Registering for +49yyyy
Receive registration code for +49yyyyyyyyyy by (S)MS or (V)oice (s/v)? signal.sh: 331: read: arg count
Unknown option , exiting
Die Registrierung hat erst mal nicht geklappt.
Gruss
Enno
Hi Enno,
Danke. Deine Shell verhält sich etwas anders. In der Hauptsache hat er deine Eingabe nicht erkannt.
Update im ersten Post.
Mich besorgt mehr die Net::DBus installation (erstmal irrelevant für die Registrierung)
ist das ein logfile /tmp/signal_install.log - dann hätte ich das gerne.
Jörg
ok, mit der neuen Version fragt das Script schon mal. Ich kann eingeben, alles läuft durch, allerdings noch kein Anruf mit dem Code. Daher habe ich an der Postion an der ich den Code eingeben müsste abgebrochen. Hier das /tmp/signal_install.log
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 03 Feb 2021 08:17:03 GMT
Running install for module 'Net::DBus'
Checksum for /root/.cpan/sources/authors/id/D/DA/DANBERR/Net-DBus-1.2.0.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring D/DA/DANBERR/Net-DBus-1.2.0.tar.gz with Makefile.PL
Warning: prerequisite Test::CPAN::Changes 0 not found.
Warning: prerequisite Test::Pod 0 not found.
Warning: prerequisite Test::Pod::Coverage 0 not found.
Warning: prerequisite XML::Twig 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::DBus
Writing MYMETA.yml and MYMETA.json
DANBERR/Net-DBus-1.2.0.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for D/DA/DANBERR/Net-DBus-1.2.0.tar.gz
---- Unsatisfied dependencies detected during ----
---- DANBERR/Net-DBus-1.2.0.tar.gz ----
Test::CPAN::Changes [requires]
Test::Pod [requires]
Test::Pod::Coverage [requires]
XML::Twig [requires]
Running install for module 'Test::CPAN::Changes'
2BChecksum for /root/.cpan/sources/authors/id/H/HA/HAARG/CPAN-Changes-0.400002.tar.gz ok
Configuring H/HA/HAARG/CPAN-Changes-0.400002.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for CPAN::Changes
Writing MYMETA.yml and MYMETA.json
HAARG/CPAN-Changes-0.400002.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for H/HA/HAARG/CPAN-Changes-0.400002.tar.gz
HAARG/CPAN-Changes-0.400002.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'Test::Pod'
Checksum for /root/.cpan/sources/authors/id/E/ET/ETHER/Test-Pod-1.52.tar.gz ok
Configuring E/ET/ETHER/Test-Pod-1.52.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Test::Pod
Writing MYMETA.yml and MYMETA.json
ETHER/Test-Pod-1.52.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for E/ET/ETHER/Test-Pod-1.52.tar.gz
ETHER/Test-Pod-1.52.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'Test::Pod::Coverage'
Checksum for /root/.cpan/sources/authors/id/N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz ok
Configuring N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz with Makefile.PL
Warning: prerequisite Pod::Coverage 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Test::Pod::Coverage
Writing MYMETA.yml and MYMETA.json
NEILB/Test-Pod-Coverage-1.10.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz
---- Unsatisfied dependencies detected during ----
---- NEILB/Test-Pod-Coverage-1.10.tar.gz ----
Pod::Coverage [requires]
Running install for module 'Pod::Coverage'
Checksum for /root/.cpan/sources/authors/id/R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz ok
Configuring R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz with Makefile.PL
Warning: prerequisite Devel::Symdump 2.01 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Pod::Coverage
Writing MYMETA.yml and MYMETA.json
RCLAMP/Pod-Coverage-0.23.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz
---- Unsatisfied dependencies detected during ----
---- RCLAMP/Pod-Coverage-0.23.tar.gz ----
Devel::Symdump [requires]
Running install for module 'Devel::Symdump'
Checksum for /root/.cpan/sources/authors/id/A/AN/ANDK/Devel-Symdump-2.18.tar.gz ok
Configuring A/AN/ANDK/Devel-Symdump-2.18.tar.gz with Makefile.PL
Require Devel::Symdump from the local tarball.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Devel::Symdump
Writing MYMETA.yml and MYMETA.json
ANDK/Devel-Symdump-2.18.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for A/AN/ANDK/Devel-Symdump-2.18.tar.gz
ANDK/Devel-Symdump-2.18.tar.gz
make -- NOT OK
No such file or directory
RCLAMP/Pod-Coverage-0.23.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Pod-Coverage-0.23-5
RCLAMP/Pod-Coverage-0.23.tar.gz
Has already been prepared
Running make for R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz
Warning: Prerequisite 'Devel::Symdump => 2.01' for 'RCLAMP/Pod-Coverage-0.23.tar.gz' failed when processing 'ANDK/Devel-Symdump-2.18.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
RCLAMP/Pod-Coverage-0.23.tar.gz
make -- NOT OK
No such file or directory
NEILB/Test-Pod-Coverage-1.10.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Test-Pod-Coverage-1.10-5
NEILB/Test-Pod-Coverage-1.10.tar.gz
Has already been prepared
Running make for N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz
Warning: Prerequisite 'Pod::Coverage => 0' for 'NEILB/Test-Pod-Coverage-1.10.tar.gz' failed when processing 'RCLAMP/Pod-Coverage-0.23.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
NEILB/Test-Pod-Coverage-1.10.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'XML::Twig'
Checksum for /root/.cpan/sources/authors/id/M/MI/MIROD/XML-Twig-3.52.tar.gz ok
Configuring M/MI/MIROD/XML-Twig-3.52.tar.gz with Makefile.PL
Warning: prerequisite XML::Parser 2.23 not found.
Checking if your kit is complete...
Looks good
updated prereqs in META.json
Generating a Unix-style Makefile
Writing Makefile for XML::Twig
Writing MYMETA.yml and MYMETA.json
MIROD/XML-Twig-3.52.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for M/MI/MIROD/XML-Twig-3.52.tar.gz
---- Unsatisfied dependencies detected during ----
---- MIROD/XML-Twig-3.52.tar.gz ----
XML::Parser [requires]
Running install for module 'XML::Parser'
Checksum for /root/.cpan/sources/authors/id/T/TO/TODDR/XML-Parser-2.46.tar.gz ok
Configuring T/TO/TODDR/XML-Parser-2.46.tar.gz with Makefile.PL
Couldn't find your C compiler
Compilation failed in require at Makefile.PL line 4.
BEGIN failed--compilation aborted at Makefile.PL line 4.
Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
TODDR/XML-Parser-2.46.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
MIROD/XML-Twig-3.52.tar.gz
Has already been unwrapped into directory /root/.cpan/build/XML-Twig-3.52-5
MIROD/XML-Twig-3.52.tar.gz
Has already been prepared
Running make for M/MI/MIROD/XML-Twig-3.52.tar.gz
Warning: Prerequisite 'XML::Parser => 2.23' for 'MIROD/XML-Twig-3.52.tar.gz' failed when processing 'TODDR/XML-Parser-2.46.tar.gz' with 'writemakefile => NO '/usr/bin/perl Makefile.PL INSTALLDIRS=site' returned status 512'. Continuing, but chances to succeed are limited.
MIROD/XML-Twig-3.52.tar.gz
make -- NOT OK
No such file or directory
DANBERR/Net-DBus-1.2.0.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Net-DBus-1.2.0-5
DANBERR/Net-DBus-1.2.0.tar.gz
Has already been prepared
Running make for D/DA/DANBERR/Net-DBus-1.2.0.tar.gz
Warning: Prerequisite 'Test::CPAN::Changes => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'HAARG/CPAN-Changes-0.400002.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'Test::Pod => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'ETHER/Test-Pod-1.52.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'Test::Pod::Coverage => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'NEILB/Test-Pod-Coverage-1.10.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'XML::Twig => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'MIROD/XML-Twig-3.52.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
DANBERR/Net-DBus-1.2.0.tar.gz
make -- NOT OK
Gruss
Enno
Hi Enno,
ok, auf die schnelle sehe ich schon mal, das er sich beschwert, dass kein C-Compiler auf dem system ist. Kannst du mal einen nachinstallieren (gcc?)? (sollte ich dann wohl mit in die dependencies einbauen).
Wie ist die Bildschirmausgabe bei der Registrierung?
Jörg
ok apt install gcc dann noch mal gestartet. Hier die Ausgabe in der Konsole. Der Anruf mit dem Code fehlt immernoch. root@Test:~# sh signal.sh
signal.sh: 19: source: not found
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: fhem
Signal-cli Install directory: /opt/fhem
Signal config storage: /var/lib/fhem
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49yyyyy
Your configuration
Linux Test 5.4.78-2-pve #1 SMP PVE 5.4.78-2 (Thu, 03 Dec 2020 14:26:17 +0100) x86_64 x86_64 x86_64 GNU/Linux
has not been tested, continue at own risk
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
!!! Everything needs to run with sudo !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for dbus devel...available
Checking for Net:DBus...Can't locate Net/DBus.pm in @INC (you may need to install the Net::DBus module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 /usr/local/lib/site_perl) at /tmp/signal4358.tmp line 5.
BEGIN failed--compilation aborted at /tmp/signal4358.tmp line 5.
Installing latest NET::DBus...done
Checking user fhem ...found
Checking for /opt/fhem...found
Checking for /var/lib/fhem...found
Checking for existing signal-cli installation...found
Checking signal-cli version...uid=998(fhem) gid=20(dialout) groups=20(dialout)
signal-cli 0.7.4
signal.sh: 208: [: signal-cli 0.7.4: unexpected operator
Update to current version (y/N)? y
Proceed with signal cli installation
Downloading signal-cli 0.7.4...done
Unpacking ...
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
Registering for +49yyyyyy
Receive registration code for +49yyyyy by (S)MS or (V)oice (s/v)? v
Registering +4951170035840 with Voice call
Stopping Signal service to get exclusive access to configuration
Captcha invalid or required for verification (null)
You should get a call or SMS now providing a 6 digit code
Enter this code here:
und hier das Log:
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 03 Feb 2021 08:17:03 GMT
Running install for module 'Net::DBus'
Checksum for /root/.cpan/sources/authors/id/D/DA/DANBERR/Net-DBus-1.2.0.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring D/DA/DANBERR/Net-DBus-1.2.0.tar.gz with Makefile.PL
Warning: prerequisite Test::CPAN::Changes 0 not found.
Warning: prerequisite Test::Pod 0 not found.
Warning: prerequisite Test::Pod::Coverage 0 not found.
Warning: prerequisite XML::Twig 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Net::DBus
Writing MYMETA.yml and MYMETA.json
DANBERR/Net-DBus-1.2.0.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for D/DA/DANBERR/Net-DBus-1.2.0.tar.gz
---- Unsatisfied dependencies detected during ----
---- DANBERR/Net-DBus-1.2.0.tar.gz ----
Test::CPAN::Changes [requires]
Test::Pod [requires]
Test::Pod::Coverage [requires]
XML::Twig [requires]
Running install for module 'Test::CPAN::Changes'
Checksum for /root/.cpan/sources/authors/id/H/HA/HAARG/CPAN-Changes-0.400002.tar.gz ok
Configuring H/HA/HAARG/CPAN-Changes-0.400002.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for CPAN::Changes
Writing MYMETA.yml and MYMETA.json
HAARG/CPAN-Changes-0.400002.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for H/HA/HAARG/CPAN-Changes-0.400002.tar.gz
HAARG/CPAN-Changes-0.400002.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'Test::Pod'
Checksum for /root/.cpan/sources/authors/id/E/ET/ETHER/Test-Pod-1.52.tar.gz ok
Configuring E/ET/ETHER/Test-Pod-1.52.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Test::Pod
Writing MYMETA.yml and MYMETA.json
ETHER/Test-Pod-1.52.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for E/ET/ETHER/Test-Pod-1.52.tar.gz
ETHER/Test-Pod-1.52.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'Test::Pod::Coverage'
Checksum for /root/.cpan/sources/authors/id/N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz ok
Configuring N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz with Makefile.PL
Warning: prerequisite Pod::Coverage 0 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Test::Pod::Coverage
Writing MYMETA.yml and MYMETA.json
NEILB/Test-Pod-Coverage-1.10.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz
---- Unsatisfied dependencies detected during ----
---- NEILB/Test-Pod-Coverage-1.10.tar.gz ----
Pod::Coverage [requires]
Running install for module 'Pod::Coverage'
Checksum for /root/.cpan/sources/authors/id/R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz ok
Configuring R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz with Makefile.PL
Warning: prerequisite Devel::Symdump 2.01 not found.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Pod::Coverage
Writing MYMETA.yml and MYMETA.json
RCLAMP/Pod-Coverage-0.23.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz
---- Unsatisfied dependencies detected during ----
---- RCLAMP/Pod-Coverage-0.23.tar.gz ----
Devel::Symdump [requires]
Running install for module 'Devel::Symdump'
Checksum for /root/.cpan/sources/authors/id/A/AN/ANDK/Devel-Symdump-2.18.tar.gz ok
Configuring A/AN/ANDK/Devel-Symdump-2.18.tar.gz with Makefile.PL
Require Devel::Symdump from the local tarball.
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Devel::Symdump
Writing MYMETA.yml and MYMETA.json
ANDK/Devel-Symdump-2.18.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for A/AN/ANDK/Devel-Symdump-2.18.tar.gz
ANDK/Devel-Symdump-2.18.tar.gz
make -- NOT OK
No such file or directory
RCLAMP/Pod-Coverage-0.23.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Pod-Coverage-0.23-2
RCLAMP/Pod-Coverage-0.23.tar.gz
Has already been prepared
Running make for R/RC/RCLAMP/Pod-Coverage-0.23.tar.gz
Warning: Prerequisite 'Devel::Symdump => 2.01' for 'RCLAMP/Pod-Coverage-0.23.tar.gz' failed when processing 'ANDK/Devel-Symdump-2.18.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
RCLAMP/Pod-Coverage-0.23.tar.gz
make -- NOT OK
No such file or directory
NEILB/Test-Pod-Coverage-1.10.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Test-Pod-Coverage-1.10-2
NEILB/Test-Pod-Coverage-1.10.tar.gz
Has already been prepared
Running make for N/NE/NEILB/Test-Pod-Coverage-1.10.tar.gz
Warning: Prerequisite 'Pod::Coverage => 0' for 'NEILB/Test-Pod-Coverage-1.10.tar.gz' failed when processing 'RCLAMP/Pod-Coverage-0.23.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
NEILB/Test-Pod-Coverage-1.10.tar.gz
make -- NOT OK
No such file or directory
Running install for module 'XML::Twig'
Checksum for /root/.cpan/sources/authors/id/M/MI/MIROD/XML-Twig-3.52.tar.gz ok
Configuring M/MI/MIROD/XML-Twig-3.52.tar.gz with Makefile.PL
Warning: prerequisite XML::Parser 2.23 not found.
Checking if your kit is complete...
Looks good
updated prereqs in META.json
Generating a Unix-style Makefile
Writing Makefile for XML::Twig
Writing MYMETA.yml and MYMETA.json
MIROD/XML-Twig-3.52.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- OK
Running make for M/MI/MIROD/XML-Twig-3.52.tar.gz
---- Unsatisfied dependencies detected during ----
---- MIROD/XML-Twig-3.52.tar.gz ----
XML::Parser [requires]
Running install for module 'XML::Parser'
Checksum for /root/.cpan/sources/authors/id/T/TO/TODDR/XML-Parser-2.46.tar.gz ok
Configuring T/TO/TODDR/XML-Parser-2.46.tar.gz with Makefile.PL
Expat must be installed prior to building XML::Parser and I can't find
it in the standard library directories. Install 'expat-devel' (or
'libexpat1-dev') package with your OS package manager. See 'README'.
Or you can download expat from:
http://sourceforge.net/projects/expat/
If expat is installed, but in a non-standard directory, then use the
following options to Makefile.PL:
EXPATLIBPATH=... To set the directory in which to find libexpat
EXPATINCPATH=... To set the directory in which to find expat.h
For example:
perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include
Note that if you build against a shareable library in a non-standard location
you may (on some platforms) also have to set your LD_LIBRARY_PATH environment
variable at run time for perl to find the library.
No 'Makefile' created TODDR/XML-Parser-2.46.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
MIROD/XML-Twig-3.52.tar.gz
Has already been unwrapped into directory /root/.cpan/build/XML-Twig-3.52-2
MIROD/XML-Twig-3.52.tar.gz
Has already been prepared
Running make for M/MI/MIROD/XML-Twig-3.52.tar.gz
Warning: Prerequisite 'XML::Parser => 2.23' for 'MIROD/XML-Twig-3.52.tar.gz' failed when processing 'TODDR/XML-Parser-2.46.tar.gz' with 'writemakefile => NO -- No 'Makefile' created
'. Continuing, but chances to succeed are limited.
MIROD/XML-Twig-3.52.tar.gz
make -- NOT OK
No such file or directory
DANBERR/Net-DBus-1.2.0.tar.gz
Has already been unwrapped into directory /root/.cpan/build/Net-DBus-1.2.0-2
DANBERR/Net-DBus-1.2.0.tar.gz
Has already been prepared
Running make for D/DA/DANBERR/Net-DBus-1.2.0.tar.gz
Warning: Prerequisite 'Test::CPAN::Changes => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'HAARG/CPAN-Changes-0.400002.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'Test::Pod => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'ETHER/Test-Pod-1.52.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'Test::Pod::Coverage => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'NEILB/Test-Pod-Coverage-1.10.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
Warning: Prerequisite 'XML::Twig => 0' for 'DANBERR/Net-DBus-1.2.0.tar.gz' failed when processing 'MIROD/XML-Twig-3.52.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited.
DANBERR/Net-DBus-1.2.0.tar.gz
make -- NOT OK
No such file or directory
Danke Enno.
Das Net::DBus Problem muss ich mir nach der Arbeit mal in Ruhe anschauen.
Zur Registrierung:
Anscheinend verlangt Signal bei dir ein Captcha - könnte an der VM liegen, oder daran, dass du evtl. ein VPN benutzt (oder einfach Zufall).
Im aktuellen signal-cli Entwicklungsbaum gibt es einen Patch der es ermöglicht Captchas zu übergeben. Leider nicht in der aktuelle 0.7.4 Release - d.h. hier ist erstmal Sackgasse, außer du schaffst es durch Änderungen an deinem Netzwerk zu verhindern, dass Signal ein Captcha will.
Aber immerhin wissen wir jetzt das es sowas gibt und ich kann gleich mal schauen das ich das abfange, eine Info dazu gebe und die Lösung mit der nächsten signal-cli Version unterstütze.
Gruß,
Jörg
Enno, noch was:
Es sieht so aus, als wäre dein System ziemlich "nackt" was Pakete angeht. Daher schlägt wahrscheinlich auch das DBus install fehl.
Kannst du mal folgendes machen:
apt list --installed >installed.txt
und die Datei installed.txt anhängen.
Außerdem bitte noch die Ausgabe von
cat /etc/os-release
Danke,
Jörg
Hallo Joerg,
bei der Installation von Net:DBus bekomme ich folgende meldung, hier der gesamte log. Muss ich irgendwas setzten?
user@inuc:/opt/fhem/FHEM$ sudo cpan install -f Net:DBus
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Wed, 03 Feb 2021 11:29:03 GMT
Running install for module 'Net::DBus'
Checksum for /root/.cpan/sources/authors/id/D/DA/DANBERR/Net-DBus-1.2.0.tar.gz ok
'YAML' not installed, will not store persistent state
Configuring D/DA/DANBERR/Net-DBus-1.2.0.tar.gz with Makefile.PL
cannot run pkg-config to check dbus version at Makefile.PL line 8.
Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
DANBERR/Net-DBus-1.2.0.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK
user@inuc:/opt/fhem/FHEM$
cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Danke, für das neue Modul.
Ich versuche auch schon länger den Signal-cli zum laufen zu bekomme.
Jetzt setze ich auf Dein Modul.
Ich nutzen einen Pi 3 mit Docker mein Testsystem, Produktion ist auf einen Pi4 4GB
Auszug von cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Datei mit den installierten Paketen ist angehangen.
Was ich nur installiert habe, Java 11
wget https://download.bell-sw.com/java/11.0.10+9/bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
sudo apt-get install -qqy --no-install-recommends ./bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
sudo apt-get install systemd
Script Start
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for dbus devel...available
Checking for Net:DBus...Can't locate Net/DBus.pm in @INC (you may need to install the Net::DBus module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at /tmp/signal16303.tmp line 5.
BEGIN failed--compilation aborted at /tmp/signal16303.tmp line 5.
Installing latest NET::DBus...done
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.7.4
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
Failed to connect to bus: No such file or directory
Created symlink /etc/systemd/system/dbus-org.asamk.Signal.service → /etc/systemd/system/signal.service.
Failed to connect to bus: No such file or directory
Registering for +49xxxx
Receive registration code for +493xxxxx by (S)MS or (V)oice (s/v)? v
Registering +493xxxxx with Voice call
Stopping Signal service to get exclusive access to configuration
signal: unrecognized service
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource17469578394760016723.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Captcha invalid or required for verification (null)
You should get a call or SMS now providing a 6 digit code
Enter this code here:
Das war es, kein Anruf oder sonstiges.
Mich wundert diese Fehlermeldung Captcha invalid or required for verification (null)
Hast Du eine Idee?
Danke
apt list --installed >installed.txt
Listing...
accountsservice/groovy-updates,groovy-security,now 0.6.55-0ubuntu13.2 amd64 [installed]
adduser/groovy,now 3.118ubuntu2 all [installed]
alsa-topology-conf/groovy,now 1.2.3-1 all [installed,automatic]
alsa-ucm-conf/groovy-updates,now 1.2.2-1ubuntu5.1 all [installed,automatic]
anacron/groovy,now 2.3-29 amd64 [installed,automatic]
apparmor/groovy,now 3.0.0-0ubuntu1 amd64 [installed]
apt-utils/groovy-updates,now 2.1.10ubuntu0.2 amd64 [installed]
apt/groovy-updates,now 2.1.10ubuntu0.2 amd64 [installed]
at-spi2-core/groovy,now 2.38.0-2 amd64 [installed,automatic]
base-files/groovy,now 11ubuntu14 amd64 [installed]
base-passwd/groovy,now 3.5.47 amd64 [installed]
bash-completion/groovy,now 1:2.11-2ubuntu1 all [installed]
bash/groovy,now 5.0-6ubuntu2 amd64 [installed]
bind9-dnsutils/groovy,now 1:9.16.6-3ubuntu1 amd64 [installed]
bind9-host/groovy,now 1:9.16.6-3ubuntu1 amd64 [installed]
bind9-libs/groovy,now 1:9.16.6-3ubuntu1 amd64 [installed]
binutils-common/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
binutils-x86-64-linux-gnu/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
binutils/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
bsdextrautils/groovy,now 2.36-3ubuntu1 amd64 [installed]
bsdutils/groovy,now 1:2.36-3ubuntu1 amd64 [installed]
busybox-static/groovy-updates,now 1:1.30.1-4ubuntu9.1 amd64 [installed]
bzip2/groovy,now 1.0.8-4ubuntu2 amd64 [installed]
ca-certificates-java/groovy,now 20190405ubuntu1 all [installed,automatic]
ca-certificates/groovy-updates,groovy-security,now 20210119~20.10.1 all [installed]
command-not-found/groovy,now 20.10.1 all [installed]
console-setup-linux/groovy,now 1.195ubuntu2 all [installed]
console-setup/groovy,now 1.195ubuntu2 all [installed]
coreutils/groovy,now 8.32-3ubuntu1 amd64 [installed]
cpio/groovy,now 2.13+dfsg-3 amd64 [installed]
cpp-10/groovy,now 10.2.0-13ubuntu1 amd64 [installed]
cpp/groovy,now 4:10.2.0-1ubuntu1 amd64 [installed]
cron/groovy,now 3.0pl1-136ubuntu1 amd64 [installed]
dash/groovy,now 0.5.10.2-7 amd64 [installed]
dbus/groovy,now 1.12.20-1ubuntu1 amd64 [installed]
debconf-i18n/groovy,now 1.5.74 all [installed]
debconf/groovy,now 1.5.74 all [installed]
debianutils/groovy,now 4.11.2 amd64 [installed]
default-jre-headless/groovy,now 2:1.11-72 amd64 [installed,automatic]
default-jre/groovy,now 2:1.11-72 amd64 [installed]
diffutils/groovy,now 1:3.7-3ubuntu1 amd64 [installed]
dirmngr/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
distro-info-data/groovy-updates,groovy-security,now 0.44ubuntu1.3 all [installed]
dmidecode/groovy,now 3.2-3 amd64 [installed]
dmsetup/groovy,now 2:1.02.167-1ubuntu3 amd64 [installed]
dosfstools/groovy,now 4.1-2build1 amd64 [installed]
dpkg/groovy,now 1.20.5ubuntu2 amd64 [installed]
e2fsprogs/groovy,now 1.45.6-1ubuntu1 amd64 [installed]
ed/groovy,now 1.16-1 amd64 [installed]
eject/groovy,now 2.36-3ubuntu1 amd64 [installed]
fhem/now 6.0.23659 all [installed,local]
file/groovy,now 1:5.38-5 amd64 [installed]
findutils/groovy,now 4.7.0-1ubuntu2 amd64 [installed]
fontconfig-config/groovy,now 2.13.1-2ubuntu3 all [installed]
fonts-dejavu-core/groovy,now 2.37-2 all [installed]
fonts-dejavu-extra/groovy,now 2.37-2 all [installed,automatic]
friendly-recovery/groovy,now 0.2.41 all [installed]
ftp/groovy,now 0.17-34.1.1 amd64 [installed]
fuse/groovy,now 2.9.9-3 amd64 [installed]
gcc-10-base/groovy,now 10.2.0-13ubuntu1 amd64 [installed]
gcc-10/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
gcc/groovy,now 4:10.2.0-1ubuntu1 amd64 [installed]
gettext-base/groovy,now 0.19.8.1-10build1 amd64 [installed]
gir1.2-glib-2.0/groovy,now 1.66.1-1 amd64 [installed]
gnupg-l10n/groovy-updates,now 2.2.20-1ubuntu1.1 all [installed,automatic]
gnupg-utils/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gnupg/groovy-updates,now 2.2.20-1ubuntu1.1 all [installed]
gpg-agent/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpg-wks-client/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpg-wks-server/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpg/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpgconf/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpgsm/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed,automatic]
gpgv/groovy-updates,now 2.2.20-1ubuntu1.1 amd64 [installed]
grep/groovy,now 3.4-1 amd64 [installed]
groff-base/groovy,now 1.22.4-5 amd64 [installed]
gzip/groovy-updates,now 1.10-2ubuntu1.1 amd64 [installed]
haveged/groovy,now 1.9.8-4ubuntu3 amd64 [installed]
hdparm/groovy,now 9.58+ds-5 amd64 [installed]
hostname/groovy,now 3.23 amd64 [installed]
info/groovy,now 6.7.0.dfsg.2-5 amd64 [installed]
init-system-helpers/groovy,now 1.58 all [installed]
init/groovy,now 1.58 amd64 [installed]
install-info/groovy,now 6.7.0.dfsg.2-5 amd64 [installed]
ipmiutil/groovy,now 3.1.6-1 amd64 [installed]
iproute2/groovy,now 5.7.0-1ubuntu1 amd64 [installed]
iptables/groovy-updates,now 1.8.5-3ubuntu2.20.10.2 amd64 [installed]
iputils-ping/groovy,now 3:20200821-2 amd64 [installed]
iputils-tracepath/groovy,now 3:20200821-2 amd64 [installed]
irqbalance/groovy,now 1.7.0-1 amd64 [installed]
isc-dhcp-client/groovy,now 4.4.1-2.1ubuntu9 amd64 [installed]
isc-dhcp-common/groovy,now 4.4.1-2.1ubuntu9 amd64 [installed]
iso-codes/groovy,now 4.5.0-1 all [installed]
java-common/groovy,now 0.72 all [installed,automatic]
kbd/groovy,now 2.0.4-4ubuntu4 amd64 [installed]
keyboard-configuration/groovy,now 1.195ubuntu2 all [installed]
kmod/groovy,now 27+20200310-2ubuntu1 amd64 [installed]
language-selector-common/groovy,now 0.211 all [installed]
less/groovy,now 551-2 amd64 [installed]
libaccountsservice0/groovy-updates,groovy-security,now 0.6.55-0ubuntu13.2 amd64 [installed]
libacl1/groovy,now 2.2.53-8 amd64 [installed]
libalgorithm-diff-perl/groovy,now 1.19.03-2 all [installed,automatic]
libalgorithm-diff-xs-perl/groovy,now 0.04-6 amd64 [installed,automatic]
libapparmor1/groovy,now 3.0.0-0ubuntu1 amd64 [installed]
libapt-pkg6.0/groovy-updates,now 2.1.10ubuntu0.2 amd64 [installed]
libargon2-1/groovy,now 0~20171227-0.2build20.10.0 amd64 [installed]
libasan6/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libasn1-8-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libasound2-data/groovy-updates,now 1.2.3.2-1ubuntu3.1 all [installed,automatic]
libasound2/groovy-updates,now 1.2.3.2-1ubuntu3.1 amd64 [installed,automatic]
libassuan0/groovy,now 2.5.3-7.1 amd64 [installed,automatic]
libatk-bridge2.0-0/groovy,now 2.38.0-1 amd64 [installed,automatic]
libatk-wrapper-java-jni/groovy,now 0.38.0-1 amd64 [installed,automatic]
libatk-wrapper-java/groovy,now 0.38.0-1 all [installed,automatic]
libatk1.0-0/groovy,now 2.36.0-0ubuntu1 amd64 [installed,automatic]
libatk1.0-data/groovy,now 2.36.0-0ubuntu1 all [installed,automatic]
libatm1/groovy,now 1:2.5.1-4 amd64 [installed]
libatomic1/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libatspi2.0-0/groovy,now 2.38.0-2 amd64 [installed,automatic]
libattr1/groovy,now 1:2.4.48-5 amd64 [installed]
libaudit-common/groovy,now 1:2.8.5-3ubuntu1 all [installed]
libaudit1/groovy,now 1:2.8.5-3ubuntu1 amd64 [installed]
libauthen-sasl-perl/groovy,now 2.1600-1 all [installed,automatic]
libavahi-client3/groovy,now 0.8-3ubuntu1 amd64 [installed,automatic]
libavahi-common-data/groovy,now 0.8-3ubuntu1 amd64 [installed,automatic]
libavahi-common3/groovy,now 0.8-3ubuntu1 amd64 [installed,automatic]
libbinutils/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
libblkid1/groovy,now 2.36-3ubuntu1 amd64 [installed]
libbrotli1/groovy,now 1.0.9-2 amd64 [installed]
libbsd0/groovy,now 0.10.0-1 amd64 [installed]
libbz2-1.0/groovy,now 1.0.8-4ubuntu2 amd64 [installed]
libc-bin/groovy,now 2.32-0ubuntu3 amd64 [installed]
libc-dev-bin/groovy,now 2.32-0ubuntu3 amd64 [installed,automatic]
libc6-dev/groovy,now 2.32-0ubuntu3 amd64 [installed,automatic]
libc6/groovy,now 2.32-0ubuntu3 amd64 [installed]
libcap-ng0/groovy,now 0.7.9-2.2 amd64 [installed]
libcap2-bin/groovy,now 1:2.43-1 amd64 [installed]
libcap2/groovy,now 1:2.43-1 amd64 [installed]
libcbor0.6/groovy,now 0.6.0-0ubuntu3 amd64 [installed]
libcc1-0/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libcgi-fast-perl/groovy,now 1:2.15-1 all [installed,automatic]
libcgi-pm-perl/groovy,now 4.50-1 all [installed,automatic]
libclone-perl/groovy,now 0.45-1 amd64 [installed,automatic]
libcom-err2/groovy,now 1.45.6-1ubuntu1 amd64 [installed]
libcommon-sense-perl/groovy,now 3.75-1build2 amd64 [installed,automatic]
libcrypt-dev/groovy,now 1:4.4.16-1ubuntu1 amd64 [installed,automatic]
libcrypt1/groovy,now 1:4.4.16-1ubuntu1 amd64 [installed]
libcryptsetup12/groovy,now 2:2.3.3-1ubuntu6 amd64 [installed]
libctf-nobfd0/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
libctf0/groovy,now 2.35.1-1ubuntu1 amd64 [installed,automatic]
libcups2/groovy,now 2.3.3-3ubuntu1 amd64 [installed,automatic]
libdata-dump-perl/groovy,now 1.23-1 all [installed,automatic]
libdb5.3/groovy,now 5.3.28+dfsg1-0.6ubuntu3 amd64 [installed]
libdbd-sqlite3-perl/groovy,now 1.66-1 amd64 [installed,automatic]
libdbi-perl/groovy,now 1.643-2 amd64 [installed,automatic]
libdbus-1-3/groovy,now 1.12.20-1ubuntu1 amd64 [installed]
libdbus-1-dev/groovy,now 1.12.20-1ubuntu1 amd64 [installed]
libdebconfclient0/groovy,now 0.252ubuntu1 amd64 [installed]
libdevice-serialport-perl/groovy,now 1.04-3build6 amd64 [installed,automatic]
libdevmapper1.02.1/groovy,now 2:1.02.167-1ubuntu3 amd64 [installed]
libdns-export1110/groovy,now 1:9.11.19+dfsg-1ubuntu1 amd64 [installed]
libdpkg-perl/groovy,now 1.20.5ubuntu2 all [installed,automatic]
libdrm-amdgpu1/groovy,now 2.4.102-1ubuntu1 amd64 [installed]
libdrm-common/groovy,now 2.4.102-1ubuntu1 all [installed]
libdrm-intel1/groovy,now 2.4.102-1ubuntu1 amd64 [installed]
libdrm-nouveau2/groovy,now 2.4.102-1ubuntu1 amd64 [installed]
libdrm-radeon1/groovy,now 2.4.102-1ubuntu1 amd64 [installed]
libdrm2/groovy,now 2.4.102-1ubuntu1 amd64 [installed]
libedit2/groovy,now 3.1-20191231-1 amd64 [installed]
libelf1/groovy-updates,now 0.181-1ubuntu0.1 amd64 [installed]
libencode-locale-perl/groovy,now 1.05-1 all [installed,automatic]
libestr0/groovy,now 0.1.10-2.1build1 amd64 [installed]
libexpat1/groovy,now 2.2.9-1build1 amd64 [installed]
libext2fs2/groovy,now 1.45.6-1ubuntu1 amd64 [installed]
libfastjson4/groovy,now 0.99.8-2build1 amd64 [installed]
libfcgi-perl/groovy,now 0.79-1 amd64 [installed,automatic]
libffi8ubuntu1/groovy,now 3.4~20200819gead65ca871-0ubuntu3 amd64 [installed]
libfido2-1/groovy,now 1.4.0-2 amd64 [installed]
libfile-fcntllock-perl/groovy,now 0.22-3build4 amd64 [installed,automatic]
libfile-listing-perl/groovy,now 6.04-1 all [installed,automatic]
libfont-afm-perl/groovy,now 1.20-2 all [installed,automatic]
libfontconfig1/groovy,now 2.13.1-2ubuntu3 amd64 [installed]
libfontenc1/groovy,now 1:1.1.4-1 amd64 [installed]
libfreetype6/groovy-updates,groovy-security,now 2.10.2+dfsg-3ubuntu1 amd64 [installed]
libfribidi0/groovy,now 1.0.8-2 amd64 [installed]
libfuse2/groovy,now 2.9.9-3 amd64 [installed]
libgcc-10-dev/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libgcc-s1/groovy,now 10.2.0-13ubuntu1 amd64 [installed]
libgcrypt20/groovy,now 1.8.5-5ubuntu2 amd64 [installed]
libgdbm-compat4/groovy,now 1.18.1-5.1 amd64 [installed,automatic]
libgdbm6/groovy,now 1.18.1-5.1 amd64 [installed]
libgif7/groovy,now 5.1.9-1 amd64 [installed,automatic]
libgirepository-1.0-1/groovy,now 1.66.1-1 amd64 [installed]
libgl1-mesa-dri/groovy-updates,now 20.2.6-0ubuntu0.20.10.1 amd64 [installed]
libgl1/groovy,now 1.3.2-1 amd64 [installed]
libglapi-mesa/groovy-updates,now 20.2.6-0ubuntu0.20.10.1 amd64 [installed]
libglib2.0-0/groovy,now 2.66.1-2 amd64 [installed]
libglib2.0-data/groovy,now 2.66.1-2 all [installed]
libglvnd0/groovy,now 1.3.2-1 amd64 [installed]
libglx-mesa0/groovy-updates,now 20.2.6-0ubuntu0.20.10.1 amd64 [installed]
libglx0/groovy,now 1.3.2-1 amd64 [installed]
libgmp10/groovy,now 2:6.2.0+dfsg-6ubuntu1 amd64 [installed]
libgnutls30/groovy,now 3.6.15-4ubuntu2 amd64 [installed]
libgomp1/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libgpg-error0/groovy,now 1.38-2 amd64 [installed]
libgssapi-krb5-2/groovy-updates,groovy-security,now 1.17-10ubuntu0.1 amd64 [installed]
libgssapi3-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libhavege2/groovy,now 1.9.8-4ubuntu3 amd64 [installed,automatic]
libhcrypto4-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libheimbase1-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libheimntlm0-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libhogweed6/groovy,now 3.6-2 amd64 [installed]
libhtml-form-perl/groovy,now 6.07-1 all [installed,automatic]
libhtml-format-perl/groovy,now 2.12-1 all [installed,automatic]
libhtml-parser-perl/groovy,now 3.73-1 amd64 [installed,automatic]
libhtml-tagset-perl/groovy,now 3.20-4 all [installed,automatic]
libhtml-tree-perl/groovy,now 5.07-2 all [installed,automatic]
libhttp-cookies-perl/groovy,now 6.08-1 all [installed,automatic]
libhttp-daemon-perl/groovy,now 6.12-1 all [installed,automatic]
libhttp-date-perl/groovy,now 6.05-1 all [installed,automatic]
libhttp-message-perl/groovy,now 6.25-1 all [installed,automatic]
libhttp-negotiate-perl/groovy,now 6.01-1 all [installed,automatic]
libhx509-5-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libice6/groovy,now 2:1.0.10-1 amd64 [installed]
libicu67/groovy,now 67.1-4 amd64 [installed]
libidn2-0/groovy,now 2.3.0-1 amd64 [installed]
libio-html-perl/groovy,now 1.001-1 all [installed,automatic]
libio-socket-ssl-perl/groovy,now 2.067-1 all [installed,automatic]
libip4tc2/groovy-updates,now 1.8.5-3ubuntu2.20.10.2 amd64 [installed]
libip6tc2/groovy-updates,now 1.8.5-3ubuntu2.20.10.2 amd64 [installed]
libisc-export1105/groovy,now 1:9.11.19+dfsg-1ubuntu1 amd64 [installed]
libisl22/groovy,now 0.22.1-1 amd64 [installed]
libitm1/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libjpeg-turbo8/groovy,now 2.0.3-0ubuntu2 amd64 [installed,automatic]
libjpeg8/groovy,now 8c-2ubuntu8 amd64 [installed,automatic]
libjson-c5/groovy,now 0.15-1 amd64 [installed]
libjson-perl/groovy,now 4.02000-2 all [installed,automatic]
libjson-xs-perl/groovy,now 4.020-1build1 amd64 [installed,automatic]
libk5crypto3/groovy-updates,groovy-security,now 1.17-10ubuntu0.1 amd64 [installed]
libkeyutils1/groovy,now 1.6.1-2ubuntu1 amd64 [installed]
libkmod2/groovy,now 27+20200310-2ubuntu1 amd64 [installed]
libkrb5-26-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libkrb5-3/groovy-updates,groovy-security,now 1.17-10ubuntu0.1 amd64 [installed]
libkrb5support0/groovy-updates,groovy-security,now 1.17-10ubuntu0.1 amd64 [installed]
libksba8/groovy,now 1.4.0-2 amd64 [installed,automatic]
liblcms2-2/groovy,now 2.9-4 amd64 [installed,automatic]
libldap-2.4-2/groovy-updates,groovy-security,now 2.4.53+dfsg-1ubuntu1.2 amd64 [installed,automatic]
libldap-common/groovy-updates,groovy-security,now 2.4.53+dfsg-1ubuntu1.2 all [installed,automatic]
libllvm11/groovy,now 1:11.0.0-2 amd64 [installed]
liblmdb0/groovy,now 0.9.24-1 amd64 [installed]
liblocale-gettext-perl/groovy,now 1.07-4 amd64 [installed]
liblsan0/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
liblwp-mediatypes-perl/groovy,now 6.04-1 all [installed,automatic]
liblwp-protocol-https-perl/groovy,now 6.09-1 all [installed,automatic]
liblz4-1/groovy,now 1.9.2-2 amd64 [installed]
liblzma5/groovy,now 5.2.4-1ubuntu1 amd64 [installed]
libmagic-mgc/groovy,now 1:5.38-5 amd64 [installed]
libmagic1/groovy,now 1:5.38-5 amd64 [installed]
libmailtools-perl/groovy,now 2.21-1 all [installed,automatic]
libmaxminddb0/groovy-updates,groovy-security,now 1.4.2-0ubuntu1.20.10.1 amd64 [installed]
libmnl0/groovy,now 1.0.4-3 amd64 [installed]
libmount1/groovy,now 2.36-3ubuntu1 amd64 [installed]
libmpc3/groovy,now 1.2.0~rc1-1 amd64 [installed]
libmpfr6/groovy,now 4.1.0-3 amd64 [installed]
libncurses6/groovy,now 6.2-1 amd64 [installed]
libncursesw6/groovy,now 6.2-1 amd64 [installed]
libnet-http-perl/groovy,now 6.19-1 all [installed,automatic]
libnet-smtp-ssl-perl/groovy,now 1.04-1 all [installed,automatic]
libnet-ssleay-perl/groovy,now 1.88-2ubuntu1 amd64 [installed,automatic]
libnetfilter-conntrack3/groovy,now 1.0.8-1 amd64 [installed]
libnetplan0/groovy-updates,now 0.101-0ubuntu3~20.10.1 amd64 [installed]
libnettle8/groovy,now 3.6-2 amd64 [installed]
libnewt0.52/groovy,now 0.52.21-4ubuntu2 amd64 [installed]
libnfnetlink0/groovy,now 1.0.1-3build1 amd64 [installed]
libnftnl11/groovy,now 1.1.7-1 amd64 [installed]
libnpth0/groovy,now 1.6-2 amd64 [installed,automatic]
libnsl-dev/groovy,now 1.3.0-0ubuntu3 amd64 [installed,automatic]
libnsl2/groovy,now 1.3.0-0ubuntu3 amd64 [installed]
libnspr4/groovy,now 2:4.27-1 amd64 [installed,automatic]
libnss-nis/groovy,now 3.1-0ubuntu4 amd64 [installed]
libnss-nisplus/groovy,now 1.3-0ubuntu4 amd64 [installed]
libnss-systemd/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
libnss3/groovy,now 2:3.55-1ubuntu3 amd64 [installed,automatic]
libntfs-3g883/groovy,now 1:2017.3.23AR.3-3ubuntu2 amd64 [installed]
libnuma1/groovy,now 2.0.12-1build1 amd64 [installed]
libp11-kit0/groovy-updates,groovy-security,now 0.23.21-2ubuntu0.1 amd64 [installed]
libpam-cap/groovy,now 1:2.43-1 amd64 [installed]
libpam-modules-bin/groovy,now 1.3.1-5ubuntu6 amd64 [installed]
libpam-modules/groovy,now 1.3.1-5ubuntu6 amd64 [installed]
libpam-runtime/groovy,now 1.3.1-5ubuntu6 all [installed]
libpam-systemd/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
libpam0g/groovy,now 1.3.1-5ubuntu6 amd64 [installed]
libparted2/groovy-updates,now 3.3-4ubuntu0.20.10.1 amd64 [installed]
libpcap0.8/groovy,now 1.9.1-4 amd64 [installed]
libpci3/groovy,now 1:3.7.0-2 amd64 [installed]
libpciaccess0/groovy,now 0.16-1 amd64 [installed]
libpcre2-8-0/groovy,now 10.34-7 amd64 [installed]
libpcre3/groovy,now 2:8.39-13 amd64 [installed]
libpcsclite1/groovy,now 1.9.0-1 amd64 [installed,automatic]
libperl5.30/groovy,now 5.30.3-4 amd64 [installed,automatic]
libpipeline1/groovy,now 1.5.3-1 amd64 [installed]
libplymouth5/groovy-updates,now 0.9.5-0ubuntu2.1 amd64 [installed]
libpng16-16/groovy,now 1.6.37-3 amd64 [installed]
libpolkit-gobject-1-0/groovy,now 0.105-29 amd64 [installed]
libpopt0/groovy,now 1.18-1 amd64 [installed]
libprocps8/groovy,now 2:3.3.16-5ubuntu2 amd64 [installed]
libpsl5/groovy,now 0.21.0-1.1ubuntu1 amd64 [installed]
libpython3-stdlib/groovy,now 3.8.6-0ubuntu1 amd64 [installed]
libpython3.8-minimal/groovy,now 3.8.6-1 amd64 [installed]
libpython3.8-stdlib/groovy,now 3.8.6-1 amd64 [installed]
libqrencode4/groovy,now 4.0.2-2 amd64 [installed,automatic]
libquadmath0/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libreadline8/groovy,now 8.0-4 amd64 [installed]
libroken18-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libsasl2-2/groovy,now 2.1.27+dfsg-2ubuntu1 amd64 [installed]
libsasl2-modules-db/groovy,now 2.1.27+dfsg-2ubuntu1 amd64 [installed]
libseccomp2/groovy,now 2.4.3-1ubuntu4 amd64 [installed]
libselinux1/groovy,now 3.1-2 amd64 [installed]
libsemanage-common/groovy,now 3.1-1 all [installed]
libsemanage1/groovy,now 3.1-1 amd64 [installed]
libsensors-config/groovy,now 1:3.6.0-2ubuntu1 all [installed]
libsensors5/groovy,now 1:3.6.0-2ubuntu1 amd64 [installed]
libsepol1/groovy,now 3.1-1 amd64 [installed]
libslang2/groovy,now 2.3.2-5 amd64 [installed]
libsm6/groovy,now 2:1.2.3-1 amd64 [installed]
libsmartcols1/groovy,now 2.36-3ubuntu1 amd64 [installed]
libsqlite3-0/groovy,now 3.33.0-1 amd64 [installed]
libss2/groovy,now 1.45.6-1ubuntu1 amd64 [installed]
libssl1.1/groovy-updates,groovy-security,now 1.1.1f-1ubuntu4.1 amd64 [installed]
libstdc++6/groovy,now 10.2.0-13ubuntu1 amd64 [installed]
libsystemd0/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
libtasn1-6/groovy,now 4.16.0-2 amd64 [installed]
libtext-charwidth-perl/groovy,now 0.04-10 amd64 [installed]
libtext-diff-perl/groovy,now 1.45-1 all [installed,automatic]
libtext-iconv-perl/groovy,now 1.7-7 amd64 [installed]
libtext-wrapi18n-perl/groovy,now 0.06-9 all [installed]
libtimedate-perl/groovy,now 2.3300-1 all [installed,automatic]
libtinfo6/groovy,now 6.2-1 amd64 [installed]
libtirpc-common/groovy,now 1.2.6-1build1 all [installed]
libtirpc-dev/groovy,now 1.2.6-1build1 amd64 [installed,automatic]
libtirpc3/groovy,now 1.2.6-1build1 amd64 [installed]
libtry-tiny-perl/groovy,now 0.30-1 all [installed,automatic]
libtsan0/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libtypes-serialiser-perl/groovy,now 1.0-1 all [installed,automatic]
libubsan1/groovy,now 10.2.0-13ubuntu1 amd64 [installed,automatic]
libuchardet0/groovy,now 0.0.7-1 amd64 [installed]
libudev1/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
libunistring2/groovy,now 0.9.10-4 amd64 [installed]
libunwind8/groovy,now 1.3.2-2 amd64 [installed]
liburi-perl/groovy,now 1.76-2 all [installed,automatic]
libusb-1.0-0/groovy,now 2:1.0.23-2build1 amd64 [installed]
libuuid1/groovy,now 2.36-3ubuntu1 amd64 [installed]
libuv1/groovy,now 1.38.0-2ubuntu2 amd64 [installed]
libvulkan1/groovy,now 1.2.141.0-1 amd64 [installed]
libwind0-heimdal/groovy,now 7.7.0+dfsg-2 amd64 [installed,automatic]
libwrap0/groovy,now 7.6.q-30 amd64 [installed]
libwww-perl/groovy,now 6.47-1 all [installed,automatic]
libwww-robotrules-perl/groovy,now 6.02-1 all [installed,automatic]
libx11-6/groovy,now 2:1.6.12-1 amd64 [installed]
libx11-data/groovy,now 2:1.6.12-1 all [installed]
libx11-xcb1/groovy,now 2:1.6.12-1 amd64 [installed]
libxau6/groovy,now 1:1.0.9-0ubuntu1 amd64 [installed]
libxaw7/groovy,now 2:1.0.13-1 amd64 [installed]
libxcb-dri2-0/groovy,now 1.14-2 amd64 [installed]
libxcb-dri3-0/groovy,now 1.14-2 amd64 [installed]
libxcb-glx0/groovy,now 1.14-2 amd64 [installed]
libxcb-present0/groovy,now 1.14-2 amd64 [installed]
libxcb-shape0/groovy,now 1.14-2 amd64 [installed]
libxcb-sync1/groovy,now 1.14-2 amd64 [installed]
libxcb-xfixes0/groovy,now 1.14-2 amd64 [installed]
libxcb1/groovy,now 1.14-2 amd64 [installed]
libxcomposite1/groovy,now 1:0.4.5-1 amd64 [installed]
libxcursor1/groovy,now 1:1.2.0-2 amd64 [installed]
libxdamage1/groovy,now 1:1.1.5-2 amd64 [installed]
libxdmcp6/groovy,now 1:1.1.3-0ubuntu1 amd64 [installed]
libxext6/groovy,now 2:1.3.4-0ubuntu1 amd64 [installed]
libxfixes3/groovy,now 1:5.0.3-2 amd64 [installed]
libxft2/groovy,now 2.3.3-0ubuntu1 amd64 [installed]
libxi6/groovy,now 2:1.7.10-1 amd64 [installed]
libxinerama1/groovy,now 2:1.1.4-2 amd64 [installed]
libxkbfile1/groovy,now 1:1.1.0-1 amd64 [installed]
libxml2/groovy,now 2.9.10+dfsg-5build1 amd64 [installed]
libxmu6/groovy,now 2:1.1.3-0ubuntu1 amd64 [installed]
libxmuu1/groovy,now 2:1.1.3-0ubuntu1 amd64 [installed]
libxpm4/groovy,now 1:3.5.12-1 amd64 [installed]
libxrandr2/groovy,now 2:1.5.2-0ubuntu1 amd64 [installed]
libxrender1/groovy,now 1:0.9.10-1 amd64 [installed]
libxshmfence1/groovy,now 1.3-1 amd64 [installed]
libxt6/groovy,now 1:1.2.0-1 amd64 [installed]
libxtables12/groovy-updates,now 1.8.5-3ubuntu2.20.10.2 amd64 [installed]
libxtst6/groovy,now 2:1.2.3-1 amd64 [installed]
libxv1/groovy,now 2:1.0.11-1 amd64 [installed]
libxxf86dga1/groovy,now 2:1.1.5-0ubuntu1 amd64 [installed]
libxxf86vm1/groovy,now 1:1.1.4-1build1 amd64 [installed]
libxxhash0/groovy-updates,now 0.8.0-1ubuntu1.20.10.1 amd64 [installed]
libyaml-0-2/groovy,now 0.2.2-1 amd64 [installed]
libzstd1/groovy,now 1.4.5+dfsg-4 amd64 [installed]
linux-libc-dev/groovy-updates,groovy-security,now 5.8.0-41.46 amd64 [installed,automatic]
locales/groovy,now 2.32-0ubuntu3 all [installed]
login/groovy,now 1:4.8.1-1ubuntu6 amd64 [installed]
logrotate/groovy,now 3.14.0-4ubuntu5 amd64 [installed]
logsave/groovy,now 1.45.6-1ubuntu1 amd64 [installed]
lsb-base/groovy,now 11.1.0ubuntu2 all [installed]
lsb-release/groovy,now 11.1.0ubuntu2 all [installed]
lshw/groovy-updates,now 02.18.85-0.3ubuntu2.20.10.1 amd64 [installed]
lsof/groovy-updates,now 4.93.2+dfsg-1ubuntu0.20.10.1 amd64 [installed]
ltrace/groovy,now 0.7.3-6.1ubuntu2 amd64 [installed]
man-db/groovy,now 2.9.3-2 amd64 [installed]
manpages-dev/groovy,now 5.08-1 all [installed,automatic]
manpages/groovy,now 5.08-1 all [installed]
mawk/groovy,now 1.3.4.20200120-2 amd64 [installed]
mime-support/groovy,now 3.64ubuntu1 all [installed]
mount/groovy,now 2.36-3ubuntu1 amd64 [installed]
mtr-tiny/groovy,now 0.93-2 amd64 [installed]
nano/groovy,now 5.2-1 amd64 [installed]
ncurses-base/groovy,now 6.2-1 all [installed]
ncurses-bin/groovy,now 6.2-1 amd64 [installed]
net-tools/groovy,now 1.60+git20180626.aebd88e-1ubuntu2 amd64 [installed]
netbase/groovy,now 6.1 all [installed]
netcat-openbsd/groovy,now 1.217-2ubuntu1 amd64 [installed]
netplan.io/groovy-updates,now 0.101-0ubuntu3~20.10.1 amd64 [installed]
networkd-dispatcher/groovy,now 2.0.1-1 all [installed]
ntfs-3g/groovy,now 1:2017.3.23AR.3-3ubuntu2 amd64 [installed]
openjdk-11-jre-headless/groovy-updates,groovy-security,now 11.0.9.1+1-0ubuntu1~20.10 amd64 [installed,automatic]
openjdk-11-jre/groovy-updates,groovy-security,now 11.0.9.1+1-0ubuntu1~20.10 amd64 [installed,automatic]
openssh-client/groovy,now 1:8.3p1-1 amd64 [installed]
openssh-server/groovy,now 1:8.3p1-1 amd64 [installed]
openssh-sftp-server/groovy,now 1:8.3p1-1 amd64 [installed]
openssl/groovy-updates,groovy-security,now 1.1.1f-1ubuntu4.1 amd64 [installed]
parted/groovy-updates,now 3.3-4ubuntu0.20.10.1 amd64 [installed]
passwd/groovy,now 1:4.8.1-1ubuntu6 amd64 [installed]
pci.ids/groovy,now 0.0~2020.07.21-1 all [installed]
pciutils/groovy,now 1:3.7.0-2 amd64 [installed]
perl-base/groovy,now 5.30.3-4 amd64 [installed]
perl-modules-5.30/groovy,now 5.30.3-4 all [installed,automatic]
perl-openssl-defaults/groovy,now 5 amd64 [installed,automatic]
perl/groovy,now 5.30.3-4 amd64 [installed,automatic]
pinentry-curses/groovy,now 1.1.0-4build1 amd64 [installed,automatic]
pkg-config/groovy,now 0.29.2-1ubuntu1 amd64 [installed]
plymouth-theme-ubuntu-text/groovy-updates,now 0.9.5-0ubuntu2.1 amd64 [installed]
plymouth/groovy-updates,now 0.9.5-0ubuntu2.1 amd64 [installed]
postfix/groovy,now 3.5.6-1 amd64 [installed]
powermgmt-base/groovy,now 1.36 all [installed]
procps/groovy,now 2:3.3.16-5ubuntu2 amd64 [installed]
psmisc/groovy,now 23.3-1 amd64 [installed]
publicsuffix/groovy,now 20200729.1725-1 all [installed]
python-apt-common/groovy-updates,groovy-security,now 2.1.3ubuntu1.3 all [installed]
python3-apt/groovy-updates,groovy-security,now 2.1.3ubuntu1.3 amd64 [installed]
python3-commandnotfound/groovy,now 20.10.1 all [installed]
python3-dbus/groovy,now 1.2.16-3 amd64 [installed]
python3-distro-info/groovy,now 0.23ubuntu1 all [installed]
python3-distupgrade/groovy-updates,now 1:20.10.14 all [installed]
python3-gdbm/groovy,now 3.8.6-1 amd64 [installed]
python3-gi/groovy,now 3.38.0-1 amd64 [installed]
python3-minimal/groovy,now 3.8.6-0ubuntu1 amd64 [installed]
python3-netifaces/groovy,now 0.10.4-1ubuntu4 amd64 [installed]
python3-pkg-resources/groovy,now 49.3.1-2 all [installed]
python3-update-manager/groovy-updates,now 1:20.10.4 all [installed]
python3-yaml/groovy,now 5.3.1-2 amd64 [installed]
python3.8-minimal/groovy,now 3.8.6-1 amd64 [installed]
python3.8/groovy,now 3.8.6-1 amd64 [installed]
python3/groovy,now 3.8.6-0ubuntu1 amd64 [installed]
qrencode/groovy,now 4.0.2-2 amd64 [installed]
readline-common/groovy,now 8.0-4 all [installed]
rpcbind/groovy,now 1.2.5-9 amd64 [installed,automatic]
rpcsvc-proto/groovy,now 1.4.2-0ubuntu4 amd64 [installed,automatic]
rsync/groovy,now 3.2.3-2ubuntu1 amd64 [installed]
rsyslog/groovy,now 8.2006.0-2ubuntu1 amd64 [installed]
sed/groovy,now 4.7-1ubuntu1 amd64 [installed]
sensible-utils/groovy,now 0.0.13 all [installed]
shared-mime-info/groovy,now 2.0-1 amd64 [installed]
sqlite3/groovy,now 3.33.0-1 amd64 [installed,automatic]
ssh/groovy,now 1:8.3p1-1 all [installed]
ssl-cert/groovy,now 1.0.39 all [installed]
strace/groovy,now 5.5-3ubuntu1 amd64 [installed]
sudo/groovy-updates,groovy-security,now 1.9.1-1ubuntu1.1 amd64 [installed]
systemd-sysv/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
systemd-timesyncd/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
systemd/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
sysvinit-utils/groovy,now 2.96-3ubuntu1 amd64 [installed]
tar/groovy-updates,groovy-security,now 1.30+dfsg-7ubuntu0.20.10.1 amd64 [installed]
tcpdump/groovy,now 4.9.3-6 amd64 [installed]
telnet/groovy,now 0.17-41.2build1 amd64 [installed]
time/groovy,now 1.7-25.1build2 amd64 [installed]
tzdata/groovy-updates,groovy-security,now 2021a-0ubuntu0.20.10 all [installed]
ubuntu-advantage-tools/groovy,now 24.4 amd64 [installed]
ubuntu-keyring/groovy,now 2020.06.17.1 all [installed]
ubuntu-minimal/groovy,now 1.459 amd64 [installed]
ubuntu-release-upgrader-core/groovy-updates,now 1:20.10.14 all [installed]
ubuntu-standard/groovy,now 1.459 amd64 [installed]
ucf/groovy,now 3.0043 all [installed]
udev/groovy-updates,now 246.6-1ubuntu1.1 amd64 [installed]
ufw/groovy,now 0.36-7 all [installed]
update-manager-core/groovy-updates,now 1:20.10.4 all [installed]
usb.ids/groovy,now 2020.08.26-1 all [installed]
usbutils/groovy,now 1:012-2 amd64 [installed]
util-linux/groovy,now 2.36-3ubuntu1 amd64 [installed]
uuid-runtime/groovy,now 2.36-3ubuntu1 amd64 [installed]
vim-common/groovy,now 2:8.2.0716-3ubuntu2 all [installed]
vim-tiny/groovy,now 2:8.2.0716-3ubuntu2 amd64 [installed]
wget/groovy,now 1.20.3-1ubuntu1 amd64 [installed]
whiptail/groovy,now 0.52.21-4ubuntu2 amd64 [installed]
x11-apps/groovy,now 7.7+8 amd64 [installed]
x11-common/groovy,now 1:7.7+19ubuntu15 all [installed]
x11-session-utils/groovy,now 7.7+4 amd64 [installed]
x11-utils/groovy,now 7.7+5 amd64 [installed]
x11-xkb-utils/groovy,now 7.7+5 amd64 [installed]
x11-xserver-utils/groovy,now 7.7+8 amd64 [installed]
xauth/groovy,now 1:1.1-0ubuntu1 amd64 [installed]
xbase-clients/groovy,now 1:7.7+19ubuntu15 all [installed]
xdg-user-dirs/groovy,now 0.17-2ubuntu2 amd64 [installed]
xinit/groovy,now 1.4.1-0ubuntu2 amd64 [installed]
xkb-data/groovy,now 2.29-2 all [installed]
xxd/groovy,now 2:8.2.0716-3ubuntu2 amd64 [installed]
xz-utils/groovy,now 5.2.4-1ubuntu1 amd64 [installed]
zlib1g/groovy,now 1:1.2.11.dfsg-2ubuntu4 amd64 [installed]
und
root@Test:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
Gruss
Enno
Danke für die Logfiles, das wird wohl ein iterativer Prozess, besonders mit den Net:DBus Abhängigkeiten. Ich versuche die jetzt soweit ich sie identifizieren kann per "apt install" vorzuinstallieren.
Bitte mit dem hier angehängten Script nochmal probieren und mir das /tmp/signal_install.log zukommen lassen, wenn es noch nicht geht.
@Bafh: Mach mal ein ein
sudo ./signal_install.sh remove
und probiere ob eine Neuinstallation die Meldung
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource17469578394760016723.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
verschwinden lässt. Da hatte noch was in der "Rapsi" Erkennung nicht funktioniert.
Wegen CAPTCHA:
Das muss ein neues "Feature" von Signal sein und wird wahrscheinlich getriggert wenn man aus einer VM kommt. Wird von signal-cli derzeit noch nicht unterstützt.
Habe jetzt dazu einen Hinweis eingebaut.
Workaround:
- Auf einem anderen System probieren und versuchen ob die Registrierung kopiert werden kann (not tested)
- Bereits bestehende Device (Smartphone) linken
Jörg
ok, hier die Fehlermeldung auf der Konsole mit dem neuen Script:
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for gcc...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...installing (libcpan-changes-perl)done
Checking for /usr/lib/arm-linux-gnueabihf/libexpat.a...installing (libexpat1-dev)Failed to install /usr/lib/arm-linux-gnueabihf/libexpat.a
und hier das Log:
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
libcpan-changes-perl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 32.0 kB of archives.
After this operation, 125 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/universe amd64 libcpan-changes-perl all 0.400002-1 [32.0 kB]
Fetched 32.0 kB in 0s (208 kB/s)
Selecting previously unselected package libcpan-changes-perl.
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 29729 files and directories currently installed.)
Preparing to unpack .../libcpan-changes-perl_0.400002-1_all.deb ...
Unpacking libcpan-changes-perl (0.400002-1) ...
Setting up libcpan-changes-perl (0.400002-1) ...
Processing triggers for man-db (2.9.3-2) ...
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
libexpat1-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 116 kB of archives.
After this operation, 867 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 libexpat1-dev amd64 2.2.9-1build1 [116 kB]
Fetched 116 kB in 0s (811 kB/s)
Selecting previously unselected package libexpat1-dev:amd64.
(Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 29749 files and directories currently installed.)
Preparing to unpack .../libexpat1-dev_2.2.9-1build1_amd64.deb ...
Unpacking libexpat1-dev:amd64 (2.2.9-1build1) ...
Setting up libexpat1-dev:amd64 (2.2.9-1build1) ...
Gruss
Enno
Hallo Jörg,
also das Script mit remove ausgeführt.
Neuinstallation
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +493xxx
Your configuration
Linux 6f3985224938 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux
has not been tested, continue at own risk
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
!!! Everything needs to run with sudo !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...installing (haveged)E: Unable to locate package haveged
done
Checking for java...installing (default-jre)E: Unable to locate package default-jre
done
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...installing (qrencode)E: Unable to locate package qrencode
done
Checking for pkg-config...available
Checking for gcc...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...installing (libcpan-changes-perl)E: Unable to locate package libcpan-changes-perl
Failed to install /usr/share/perl5/Test/CPAN/Changes.pm
root@6f3985224938:/opt/fhem#
hier die signal_install.log
root@6f3985224938:/opt/fhem# more /tmp/signal_install.log
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Reading package lists...
Building dependency tree...
Reading state information...
Reading package lists...
Building dependency tree...
Reading state information...
Reading package lists...
Building dependency tree...
Reading state information...
Reading package lists...
Building dependency tree...
Reading state information...
root@6f3985224938:/opt/fhem#
Bin verwirrt.
Ich werde morgen mal, alles ohne Docker aufzusetzen und ggf alle Daten zu kopieren.
Gebe hier bescheid.
Moin Jörg,
ich habe einen Container mit FHEM und den gleichen Einstellungen wie das Testsystem laufen. Dort habe ich signal-cli laufen und auch die Nummer registriert. Das ging ohne CAPTCHA. Entweder ist das in den letzten 4 Tagen eingeführt worden oder es liegt doch noch an irgend etwas anderem. Ausser der IP ist ja alles identisch. Ok, vielleicht nicht ganz, ich hatte auf der Telefonnummer schon mal ein Signal App registriert. Mal schauen, ob ich das von einem Handy ordentlich löschen kann und werde es dann noch mal mit deinem Script versuchen.
Gruss
Enno
Zitat von: BAfH am 03 Februar 2021, 16:02:11
Bin verwirrt.
Ich auch etwas. Ist das das selbe System? Schaut jetzt anders aus als vorher. Ich glaube außerdem nicht, dass man diese Installation im Docker laufen lassen kann, da ja ein Systemservice aufgesetzt wird und systemweite Pakete installiert werden.
FHEM kann dann später wahrscheinlich im Docker laufen, aber signal-cli muss ins Hauptsystem.
Zitat von: ennoich habe einen Container mit FHEM und den gleichen Einstellungen wie das Testsystem laufen. Dort habe ich signal-cli laufen und auch die Nummer registriert. Das ging ohne CAPTCHA. Entweder ist das in den letzten 4 Tagen eingeführt worden oder es liegt doch noch an irgend etwas anderem. Ausser der IP ist ja alles identisch. Ok, vielleicht nicht ganz, ich hatte auf der Telefonnummer schon mal ein Signal App registriert. Mal schauen, ob ich das von einem Handy ordentlich löschen kann und werde es dann noch mal mit deinem Script versuchen.
Das Captcha muss es schon länger geben. Der Diskussionsthread bei signal-cli reicht zurück nach 2019 - aber vielleicht wird das jetzt häufiger getriggert. Meine Test VM unter Ubuntu mit einer komplett neuen Nummer fragt auch nach einem Captcha.
Grundsätzlich müsste man die Registrierung auf jedem Linux System auch mit jedem Standarduser ohne große Installation machen können.
Einfach:
wget https://github.com/AsamK/signal-cli/releases/download/v0.7.4/signal-cli-0.7.4.tar.gz
tar xf signal-cli-0.7.4.tar.gz
cd signal-cli-0.7.4
bin/signal-cli -u +49xxxxxx register --voice
bin/signal-cli -u +49xxxxxx receive
Dann sollte in ~/.local/share/signal-cli ein Verzeichnis "data" aufgetaucht sein.
Das dann auf dem Ziel-PC in /var/lib/signal-cli kopieren.
Nicht vergessen ein
chown -R signal-cli: data zu machenDanach kann das Verzeichnis signal-cli-0-7.4 und ~/.local/share/signal-cli wieder gelöscht werden und alles wieder restlos weg sein.
Wie gesagt - theoretisch - hab nicht getestet ob diese Daten irgendwie an das System geknüpft sind - Erfahrungsberichte willkommen.
Jörg
Ich vermute mal, dass das install-script nicht in einem "gedockerten" fhem funktioniert.
Was muss ich anstellen, damit ich Signal auch im docker container verwenden kann, ohne mich allzu weit von Standard-FHEM-Docker zu entfernen?
Die apt-packages kann man ja leicht hinzufügen...
Da muss ich zugeben zu wenig Docker Know How zu haben.
Aber was spricht generell dagegen, signal-cli einfach im System zu installieren wie viele andere Services auch. Das beißt sich doch nicht mit einem FHEM Standard Container - ich gehe jetzt mal davon aus, das der Container wirklich nur FHEM beinhaltet und z.B. nicht den systemd und andere Linux Kernprozesse. signal-cli hängt sich an den system dbus (den z.B. auch X verwendet) - um das in einen Container zu bekommen, müsste eben wahrscheinlich der ganze systemd in den Container und ehe du schaust hast du eigentlich ein komplettes Linux drin bevor das wirklich funktioniert (korrigiert mich wenn ich falsch liege - wie gesagt habe ich nur theoretisches Container Wissen)
Das eigentliche Signalbot Modul kommt ja dann in den Container und kommuniziert eben mit signal-cli als System Service. Also FHEM bleibt sauber gekapselt.
Jörg
Hallo Jörg,
habe mich mal getraut und die alte Installation gelöscht.
Auf meinem Ubuntu Server habe ich in Deinem Script die Telefonnummer eingetragen
und in /opt/fhem gestartet mit vorher sudo su.
Leider hänge ich jetzt auch wie alle anderen auf einmal mit Captcha invalid or required for verification (null)
fest ?
Gruß
Hans-Jürgen
Ich habe es nicht getestet, doch die captcha Problematik sollte sich wohl so lösen lassen:
https://github.com/AsamK/signal-cli/blob/master/man/signal-cli.1.adoc#register
Zum Thema Captchas
Wie von kroman bereits gefunden gibt es tatsächlich was, hat mich nur eine Weile gekostet zu verstehen wie man an den Captcha String kommt und es im Script einzubauen.
Das Script erkennt jetzt ob ein Captcha benötigt wird und fragt dann nach dem Captcha Token.
Dieses bekommt man wie folgt:
Seite https://signalcaptchas.org/registration/generate.html aufrufen.
Dabei ist es wahrscheinlich unerheblich von wo (hab es erfolgreich aus meinem Windows Host gemacht und in meinen Linux VM Guest eingetragen) - schätzungsweise ist es einfach zeitlich begrenzt gültig.
Im Developermode (F12) und nach erfolgreichem Lösen des Captchas (wenn der Bildschirm leer bleibt, ist es auch erfolgreich gelöst) macht der Browser ein redirect auf signalcaptcha://
Das versteht der Browser aber nicht und macht gar nichts.
Der String steht aber bei Firefox in der Console (recht einfach zu finden), beim Chrome muss man auf Network gehen, mit Ctrl+R refreshen und dann in der Spalte "Name" nach einem kryptischen String suchen. Das dieser mit signalcaptcha anfängt sieht man erst im Tooltip da der Anfang abgeschnitten wird.
Anbei Screenshots von Firefox und Chrome zum besseren Verständnis.
Diesen String (ohne signalcaptcha://) dann in die shell pasten und dann ist der Käse hoffentlich gegessen.
Gruß,
Jörg
Morgen
Thema, Signal-Cli im Docker hier steht eine Menge.
https://forum.fhem.de/index.php/topic,84996.msg1123368.html#msg1123368 (https://forum.fhem.de/index.php/topic,84996.msg1123368.html#msg1123368)
Ich habe das Dockerfile noch abgeändert um die aktuelle Java 11 Umgebung zu bekommen
ARG BASE_IMAGE="fhem/fhem"
ARG BASE_IMAGE_TAG="latest"
FROM ${BASE_IMAGE}:${BASE_IMAGE_TAG}
ARG L_SIGNAL_CLI="0.7.4"
# Install base environment
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends \
cpanminus \
build-essential \
wget \
shared-mime-info \
default-jre-headless \
libunixsocket-java \
dbus \
libnet-dbus-perl \
shared-mime-info \
haveged \
# default-jdk \
net-tools \
nano \
systemd \
hping3 \
wakeonlan \
&& wget https://download.bell-sw.com/java/11.0.10+9/bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& apt-get install -qqy --no-install-recommends ./bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& cpanm \
Net::DBus \
Lirc::Client \
Crypt::Cipher::AES \
&& rm -rf /root/.cpanm \
&& wget https://github.com/AsamK/signal-cli/releases/download/v${L_SIGNAL_CLI}/signal-cli-${L_SIGNAL_CLI}.tar.gz \
&& tar xf signal-cli-${L_SIGNAL_CLI}.tar.gz -C /opt \
# && mv /opt/fhem/signal-cli-"${L_SIGNAL_CLI}" /opt/fhem/signal-cli \
# && ln -sf /opt/fhem/signal-cli/bin/signal-cli /usr/local/bin/ \
&& ln -sf /opt/signal-cli-${L_SIGNAL_CLI}/bin/signal-cli /usr/local/bin/ \
&& apt-get purge -qqy \
build-essential \
cpanminus \
subversion \
&& apt-get autoremove -qqy && apt-get clean \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY ./src/pre-start.sh /pre-start.sh
#COPY ./src/000_fhem-nopasswd /etc/sudoers.d/
COPY ./src/org.asamk.Signal.service /usr/share/dbus-1/system-services/
COPY ./src/org.asamk.Signal.conf /etc/dbus-1/system.d/
ADD https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm /fhem/FHEM/32_SiSi.pm
RUN mkdir /run/dbus
#RUN mkdir /opt/fhem/signal-cli
RUN mkdir /opt/signal-cli
RUN chmod +x /pre-start.sh
VOLUME [ "/opt/signal-cli" ]
Das läuft soweit alles stabil, nur halt die Registrierung nicht, werde etwas spätr mal die Registrierung nicht im Docker laufen lassen.
Hi BafH,
Eine Dockervariante wäre natürlich eine feine Alternative (wie gesagt kenne ich mich auf dem Gebiet nicht sehr aus).
Wenn du das soweit rund am laufen hast, sollten wir die config und Anleitung hier mit aufnehmen.
Wenn signal-cli im Docker läuft sollte das mit der Registrierung jetzt mit dem Captcha Trick durchaus auch im Docker gehen (musst halt meinen Docker check aus dem Script rausnehmen).
Wir können diesen Docker check auch gerne verwenden, um stattdessen Schritte der Installation wegzulassen oder abzuändern die mit Docker so nicht klappen oder unötig sind.
Jörg
Hallo Jörg,
hast Du Gut hinbekommen, mit dem Script und captchas, musste zwar mehr mal versuchen
und funktioniert jetzt soweit alles wieder.
Empfangen ging gleich nach der Installation aber zum raus senden musste ich noch mal wie früher auch noch mal rebooten.
Error sending message:org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
Ist ja nicht weiter schlimm, werde mich mal dann ans benutzen mit FHEM machen.
Gruß
Hans-Jürgen
Nachdem es erste positive Rückmeldungen gibt, habe ich das Script wieder im ersten Post geupdated.
Noch neu dazu gekommen:
sudo ./signal_install.sh name
zum Setzen eines Namens und Avatar Bildes.
Meiner heißt jetzt FHEM und hat das FHEM logo.
Frage an alle Mitstreiter:
Das mit den Captchas ist ja gerade im Chrome ziemlich umständlich. Soweit ich weiß sollte es in Chrome möglich sein einen Protocol Handler zu schreiben (als Plugin oder einfach Script?) der auf das "signalcaptcha://" Protokoll reagiert. Das Teil sollte einfach ein Fenster aufmachen und den Rest dieser "URL" anzeigen (die Kür wäre ein "copy" Button). Kennt sich da jemand aus?
Jörg
Hallo Jörg,
Danke für Deine Mühe und Geduld ;)
Ich habe jetzt Dein neues Script zuerst im Docker gestartet, sofort kam der Hinweis, bitte nicht hier
Also gestartet , 1 Versuch
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49...
You seem to be on a Raspberry pi with armv7l
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
name : set or change Signal user name and/or avatar picture
!!! Everything needs to run with sudo !!!
Proceed (Y/n)?
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for gcc...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...available
Checking for /usr/include/expat.h...available
Checking for /usr/share/doc-base/libxml-parser-perl...available
Checking for Net::DBus...V found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.7.4...done
Unpacking ...
Removing native x86 since you're on Raspberry.../home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 261: zip: Kommando nicht gefunden.
/home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 262: zip: Kommando nicht gefunden.
done
Downloading native armv71 libraries...
done
mv: der Aufruf von stat für 'signal-cli-0.7.4' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
done
Changing file ownership ...done
chown: Zugriff auf '/opt/signal' nicht möglich: Datei oder Verzeichnis nicht gefunden
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
/home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 362: cd: /opt/signal/bin: Datei oder Verzeichnis nicht gefunden
Registering for +49....
Receive registration code for +49.... by (S)MS or (V)oice (s/v)? v
Registering +49.... with Voice call
Stopping Signal service to get exclusive access to configuration
You should get a call or SMS now providing a 6 digit code
Enter this code here:^C
Aufgrund der Fehlermeldung, habe ich nochmal das Paket per Hand installiert
sudo apt install libnet-dbus-perl
Setup nochmal gestartet.This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49...
You seem to be on a Raspberry pi with armv7l
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
name : set or change Signal user name and/or avatar picture
!!! Everything needs to run with sudo !!!
Proceed (Y/n)?
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for gcc...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...available
Checking for /usr/include/expat.h...available
Checking for /usr/share/doc-base/libxml-parser-perl...available
Checking for Net::DBus...V found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.7.4...done
Unpacking ...
Removing native x86 since you're on Raspberry.../home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 261: zip: Kommando nicht gefunden.
/home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 262: zip: Kommando nicht gefunden.
done
Downloading native armv71 libraries...
done
mv: der Aufruf von stat für 'signal-cli-0.7.4' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
done
Changing file ownership ...done
chown: Zugriff auf '/opt/signal' nicht möglich: Datei oder Verzeichnis nicht gefunden
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
/home/pi/fhem-docker/fhemtest/core/signal_install.sh: Zeile 362: cd: /opt/signal/bin: Datei oder Verzeichnis nicht gefunden
Registering for +49...
Receive registration code for +49... by (S)MS or (V)oice (s/v)? v
Registering +49... with Voice call
Stopping Signal service to get exclusive access to configuration
You should get a call or SMS now providing a 6 digit code
Enter this code here:^C
Scheinbar kann wird das Verzeichnis /opt/signal-cli nicht finden auszug der ls-l /opt/
drwx--x--x 4 root root 4096 Feb 25 2019 containerd
drwxr-xr-x 5 root root 4096 Feb 13 2020 culfw-code
drwxr-xr-x 3 root root 4096 Mär 27 2019 docker
drwxr-xr-x 3 root root 4096 Mai 16 2019 eff.org
drwxr-xr-x 30 root root 4096 Mai 16 2019 letsencrypt
drwxr-xr-x 4 root root 4096 Jan 19 17:31 signal-cli-0.7.4
drwxr-xr-x 6 root root 4096 Feb 25 2019 vc
Ich teste weiter...
EDIT 04.02.2021
Ich habe das Verzeichnis umbenannt
/opt/signal-cli-0.7.4/ nach /opt/signal/
Script ausgeführt
sudo /home/pi/fhem-docker/fhemtest/core/signal_install.sh register
Ausgabe
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49....
You seem to be on a Raspberry pi with armv7l
Your chose the following option: register
Proceed (Y/n)?
Registering for +49...
Receive registration code for +49... by (S)MS or (V)oice (s/v)? v
Registering +49... with Voice call
Stopping Signal service to get exclusive access to configuration
*** Signal requires a CAPTCHA , use any browser to go to:
*** https://signalcaptchas.org/registration/generate.html
*** Solve the captcha there (might also just be an empty page) then press F12
*** On Chrome go to Network, press Ctrl+R, look into the 'name' column of the table
*** On Firefox Go to console
*** Now find the name starting with signalcaptcha://
*** copy that string with out the signalcaptcha:// (right click -> copy link adress)
Paste it here:03AGdBq26U4ZfaeGGl6ZJwyXhLjsH06zmiGujQnOgXXwn1sYeFR3rg23yQR-cDq1lbrj2cuQvhgTddZK6adDHiIFUH9T82VNBkAKTDLfOkv3soezPJlfP5e6tEa1TSvSkQ3ve7nRMvzuVUgU5mXWgAYzTMvV9GSHGgSOtk1Gf-DFCJuM_0IfC7tbUTbQEfUnPeSm0jVCvGz5ObuSjatK_WvYcgVMS6FknjkhFTgxFFua5p5bOkG0ns0hiZKRpkbs5IrfYtJKu8nyYh4qrYDViRt-Ls6B6rgbOy6vLtDlqRQ74HphHAP2pGSkYktAI2178kks7KpikyoJXSOq8av0cW3QWrQNr_qT1S-OuTD6fQPXRh-FCh66qs5PL7xclLKQrGR0rYgw-d1nuye6btlex4Ntn-mqjqNbLmvXnaghE7sNNCB9qfmjYpFfwjGQfl-yK1n2-9YptYhfz0nikMIQk1SUADez6nafLaTtmRTn_jA17pXDQEMyBllwkJS550IKsIsoyebnEgZH7I
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource13240667167908782314.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Captcha invalid or required for verification (null)
You should get a call or SMS now providing a 6 digit code
Enter this code here:
Ich bleibe dran...
EDIT 04.02.2021 13:27
Der Fehler war vor dem Rechner
Paste it here:03AGdBq26YhrxOoDwrOQmlC0zMyjWVRHHgaB7NsM-ghEubtMQv9DNNzbXFmPo_aLKlCoksqulUkBvjU0SlSBAvLWYU6f3WYaLnxZ7Zg7kFpBy_gecfpY1kZAfi9CTwtunc0LQ0FlNNk4Tlp9bmb1idKr4Eg7NLcy5DyTmu-xQZu4-iW9_pXWWTkg6_R7D7BP31XFkWxnRLpdjJGWLQmLCVHrl7QaKWDZMToe5_bDXRGxsugxshRwHdtGTfqeMr3ENmP93KjZp-o2tqiwXx25G1EJaPHm_ls-w-EOVixZuUyj6wXYnGvgff9aRpAVODcz1VvRUksqAVJMxMNXqSZ9Spv1aHAsueQJL1HPfMUpsZUIXo8Au3PiMKWk5EsQj6urr3vVT7UoO-296vzLHaeOv3j-lp7j3SKEBYhhO7Co5xC9951sNAJO8HNqEGwaU_BL2zswIgM9S81FrkMp6ZbypViblE_OKMdrtFtJj8W79yYKfDtDEM4vLdkZQXhj28V6T_jc4YqsAk7bpf
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource16809914347475085492.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
You should get a call or SMS now providing a 6 digit code
Enter this code here:823604
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource2348828536329969407.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
checking and receiving
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource17703472415363542522.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Restarting signal service
Aufgrund deines Tests noch auf Vorhandensein von "zip" geprüft.
Das mit dem zip ist essentiell für die nativen arm libraries für die V2 Gruppen.
Das mit dem Pfadnamen verstehe ich nicht ganz. Bei dir schlägt genau der Befehl fehl:
mv: der Aufruf von stat für 'signal-cli-0.7.4' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Liegt das am Docker? Evtl. musst du statt /opt einen anderen Pfad nehmen? Denn vorhanden war es ja wohl doch.
Kannst du jetzt nochmal testen? (update erster Post)
Danke.
Jörg
Bin jetzt auf den produktiven Pi gegangen.
Vermutlich, war der Test Pi schon total verbogen... :-)
Script ausgeführt...
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49...
You seem to be on a Raspberry pi with armv7l
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations
join : Join current number to an existing group (invite by group link)
name : set or change Signal user name and/or avatar picture
!!! Everything needs to run with sudo !!!
Proceed (Y/n)?
Checking for /usr/lib...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for wget...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...installing (qrencode)done
Checking for pkg-config...available
Checking for gcc...available
Checking for zip...installing (zip)done
Checking for /usr/include/dbus-1.0/dbus/dbus.h...installing (libdbus-1-dev)done
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...installing (libcpan-changes-perl)done
Checking for /usr/include/expat.h...available
Checking for /usr/share/doc-base/libxml-parser-perl...available
Checking for Net::DBus...Installing latest NET::DBus...done
Checking user signal-cli ...Lege Benutzer »signal-cli« an ...
Lege neue Gruppe »signal-cli« (1001) an ...
Lege neuen Benutzer »signal-cli« (1001) mit Gruppe »signal-cli« an ...
Erstelle Home-Verzeichnis »/home/signal-cli« ...
Kopiere Dateien aus »/etc/skel« ...
created
Checking for /opt...found
Checking for /var/lib/signal-cli...created
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.7.4...done
Unpacking ...
Removing native x86 since you're on Raspberry...deleting: libzkgroup.so
done
Downloading native armv71 libraries...
done
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf.../etc/dbus-1/system.d/org.asamk.Signal.conf installed
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service.../usr/share/dbus-1/system-services/org.asamk.Signal.service installed
Checking for /etc/systemd/system/signal.service.../etc/systemd/system/signal.service installed
Created symlink /etc/systemd/system/dbus-org.asamk.Signal.service → /etc/systemd/system/signal.service.
Registering for +49...
Receive registration code for +49...by (S)MS or (V)oice (s/v)? v
Registering +49...with Voice call
Stopping Signal service to get exclusive access to configuration
*** Signal requires a CAPTCHA , use any browser to go to:
*** https://signalcaptchas.org/registration/generate.html
*** Solve the captcha there (might also just be an empty page) then press F12
*** On Chrome go to Network, press Ctrl+R, look into the 'name' column of the table
*** On Firefox Go to console
*** Now find the name starting with signalcaptcha://
*** copy that string with out the signalcaptcha:// (right click -> copy link adress)
Paste it here:03AGdBq2449zF-u8hXauaf4pOWx_j6gXSP-N9awi6EEVebOMM7gIceeDAeY4q5tTkcvC2rxZpFfXEVZ8nZnTa2Sit-ecZOBTo5LSMb72M_2K1dCRBWgu6YN_ovBD-4syC9jI-vi-XhDCcNaSJ-mRUgOsZfQ3BV-qWto1dwmUsyeMY-AppBTew0yc5uS_FrROBNpfhDN_meBsMe5IxII-JMj9kXPtEILw5clapudywUnCe2RyJwmbZT1uxnXcw_iB4GgGaYdV1SNkq5HVwtZGCg-CwnHvlgw_oV3Rw9P8KtLzIjDkQlgYx_IVdAu0OWATWBxnKyWdVeOVDej_y7JdtKdapHfehSdiOO9vpHH66ppzNI_oMhAESW6hWDehVfsvzZ1N5IpytnrJ8HrppYdAglFp_K1uNCNjZNT2gm39wGEhyCOopTpoXtw10tNZHgxV-HwIt7xuH_5zpZE1UqIgfbwuzJE_QRIPfqTi9hPFcOTRKrFLKK0_u4VNXtH1ddLANV5r3ydjsA7ddb
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
You should get a call or SMS now providing a 6 digit code
Enter this code here:799389
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
checking and receiving
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Restarting signal service
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49...
Sending a message from command line to +4915127663691
Stopping Signal service to get exclusive access to configuration
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
1612445295229
Sending a message from via dbus to +49...
method return time=1612445309.579792 sender=:1.430 -> destination=:1.431 serial=6 reply_serial=2
int64 1612445308279
Restarting signal service
If the recipient got the messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
Nachricht ist angekommen.
Was wären die nächsten Schritte:
- Kopieren des Verzeichnis Data in ~/.local/share/signal-cli ein Verzeichnis "data" nach /var/lib/signal-cli (im Docker oder auf dem Host) kopieren.
- chown -R signal-cli: data zu machen
- https://forum.fhem.de/index.php/topic,118370.msg1128815.html#msg1128815
soweitso gut... Nur bei mir gibt es kein ~/.local/share/signal-cli scheinbar hat Dein Super Script alles schon erledigt?
pi@FHEM:~ $ sudo ls -l /var/lib/signal-cli/data/
insgesamt 24
-rw------- 1 signal-cli signal-cli 17008 Feb 4 14:28 +49...
drwx------ 3 signal-cli signal-cli 4096 Feb 4 14:28 +49....d
Jetzt werde ich das mal im FHEM Docker einbauen
EDIT 04.02.2021 15:04
Ich habe die Schritte gemäß Wikihttps://wiki.fhem.de/wiki/SiSi#Einbindung_des_FHEM-Moduls (https://wiki.fhem.de/wiki/SiSi#Einbindung_des_FHEM-Moduls)
Durchgeführt geändert wurde 32_sisi.pm gegen 50_Signalbot.pm
Im Fhem
define SignalMessenger Signalbotausgeführt siehe Log
2021.02.04 15:01:54.182 1: define SignalMessenger Signalbot: 1Nur das Device ist nicht vorhanden???
???
Zitatsoweitso gut... Nur bei mir gibt es kein ~/.local/share/signal-cli scheinbar hat Dein Super Script alles schon erledigt?
Natürlich :)
Was mich jetzt noch irritiert ist
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroupEigentlich sollte es jetzt eine
-rwxr-xr-x 1 root root 681524 Jan 31 09:41 /usr/lib/libzkgroup.so
geben.
Schaust du mal und auch ob alle permissions stimmen?
Das hat jetzt bei der Registrierung nicht gestört, wird es aber, wenn du in FHEM mit Gruppen arbeitest.
Jörg
Zitat von: BAfH am 04 Februar 2021, 14:52:03
Nur das Device ist nicht vorhanden???
reload 50_Signalbot
oder
shutdown restart
gemacht?
Edit: und mit
list SignalMessengerkommt nichts?
Jörg
Nein, die Datei ist nicht vorhanden.
pi@FHEM:~ $ sudo ls -l /usr/lib/lib*
lrwxrwxrwx 1 root root 16 Nov 11 2016 /usr/lib/libident.so.0 -> libident.so.0.22
-rw-r--r-- 1 root root 7976 Nov 11 2016 /usr/lib/libident.so.0.22
lrwxrwxrwx 1 root root 20 Mai 24 2012 /usr/lib/libsigc-1.2.so.5 -> libsigc-1.2.so.5.0.7
-rw-r--r-- 1 root root 23724 Mai 24 2012 /usr/lib/libsigc-1.2.so.5.0.7
-rw-r--r-- 1 root root 16500 Aug 29 2016 /usr/lib/libsupp.a
Ja, ich habe FHEM Update und Restart.
Log
2021.02.04 15:18:00.812 1: PERL WARNING: Subroutine Signalbot_Initialize redefined at ./FHEM/50_Signalbot.pm line 29.
2021.02.04 15:18:00.815 1: PERL WARNING: Subroutine Signalbot_Set redefined at ./FHEM/50_Signalbot.pm line 50.
2021.02.04 15:18:00.816 1: PERL WARNING: Subroutine Signalbot_Get redefined at ./FHEM/50_Signalbot.pm line 175.
2021.02.04 15:18:00.819 1: PERL WARNING: Subroutine Signalbot_message_callback redefined at ./FHEM/50_Signalbot.pm line 180.
2021.02.04 15:18:00.820 1: PERL WARNING: Subroutine Signalbot_receipt_callback redefined at ./FHEM/50_Signalbot.pm line 253.
2021.02.04 15:18:00.820 1: PERL WARNING: Subroutine Signalbot_sync_callback redefined at ./FHEM/50_Signalbot.pm line 268.
2021.02.04 15:18:00.821 1: PERL WARNING: Subroutine Signalbot_disconnect redefined at ./FHEM/50_Signalbot.pm line 283.
2021.02.04 15:18:00.823 1: PERL WARNING: Subroutine Signalbot_setup redefined at ./FHEM/50_Signalbot.pm line 327.
2021.02.04 15:18:00.824 1: PERL WARNING: Subroutine Signalbot_Read redefined at ./FHEM/50_Signalbot.pm line 395.
2021.02.04 15:18:00.825 1: PERL WARNING: Subroutine Signalbot_getContactName redefined at ./FHEM/50_Signalbot.pm line 407.
2021.02.04 15:18:00.825 1: PERL WARNING: Subroutine Signalbot_translateContact redefined at ./FHEM/50_Signalbot.pm line 426.
2021.02.04 15:18:00.826 1: PERL WARNING: Subroutine Signalbot_translateGroup redefined at ./FHEM/50_Signalbot.pm line 439.
2021.02.04 15:18:00.826 1: PERL WARNING: Subroutine Signalbot_getNumber redefined at ./FHEM/50_Signalbot.pm line 461.
2021.02.04 15:18:00.827 1: PERL WARNING: Subroutine Signalbot_Refreshgroups redefined at ./FHEM/50_Signalbot.pm line 480.
2021.02.04 15:18:00.828 1: PERL WARNING: Subroutine Signalbot_sendMessage redefined at ./FHEM/50_Signalbot.pm line 498.
2021.02.04 15:18:00.829 1: PERL WARNING: Subroutine Signalbot_sendGroupMessage redefined at ./FHEM/50_Signalbot.pm line 521.
2021.02.04 15:18:00.829 1: PERL WARNING: Subroutine Signalbot_Execute redefined at ./FHEM/50_Signalbot.pm line 549.
2021.02.04 15:18:00.830 1: PERL WARNING: Subroutine Signalbot_Attr redefined at ./FHEM/50_Signalbot.pm line 559.
2021.02.04 15:18:00.830 1: PERL WARNING: Subroutine Signalbot_Notify redefined at ./FHEM/50_Signalbot.pm line 600.
2021.02.04 15:18:00.831 1: PERL WARNING: Subroutine Signalbot_Define redefined at ./FHEM/50_Signalbot.pm line 615.
2021.02.04 15:18:00.832 1: PERL WARNING: Subroutine Signalbot_Init redefined at ./FHEM/50_Signalbot.pm line 636.
2021.02.04 15:18:00.832 1: PERL WARNING: Subroutine Signalbot_Catch redefined at ./FHEM/50_Signalbot.pm line 655.
2021.02.04 15:18:00.832 1: PERL WARNING: Subroutine Signalbot_State redefined at ./FHEM/50_Signalbot.pm line 664.
2021.02.04 15:18:00.832 1: PERL WARNING: Subroutine Signalbot_Undef redefined at ./FHEM/50_Signalbot.pm line 670.
2021.02.04 15:18:00.833 1: PERL WARNING: Subroutine SignalBot_replaceCommands redefined at ./FHEM/50_Signalbot.pm line 683.
2021.02.04 15:18:00.834 1: PERL WARNING: Subroutine SignalBot_IdentifyStream redefined at ./FHEM/50_Signalbot.pm line 757.
2021.02.04 15:18:15.545 1: define Signal Signalbot: 1
Nur das Device ist nicht vorhanden.
Hab jetzt extra noch mal bei mir die Device gelöscht und neu angelegt.
Funktioniert alles gut, am Modul selbst kanns nicht liegen.
Mich irritiert das keine Fehlermeldungen kommen.
Welchen verbose level hat bei dir "global"?
Sollte mindestens 1 sein damit man was sieht.
Edit:
Eigentlich kanns nur an fehlenden Perl Abhängigkeiten liegen.
Mal folgendes Script im fhem context ausführen:
#!/usr/bin/perl -w
use strict;
use warnings;
use Net::DBus;
use Net::DBus::Reactor;
use Scalar::Util qw(looks_like_number);
use File::Temp qw( tempfile tempdir );
use Text::ParseWords;
use Encode;
print $Net::DBus::VERSION."\n";
Das sollte alle Abhängigkeiten abprüfen, die Signalbot derzeit hat und gibt die DBus Version aus (benötigt: 1.2.0)
Jörg
War mal eine Runde um den Block, ganzen Tag Homeoffice.
- Also das Verbose Level ist 3
- Dein Script ausgeführt ohne Fehler Version ist 1.2.0
- FHEM System restart
Hab nochmal die 50_Signalbot.pm runtergeladen und ins System kopiert und das Device neudefiniert
2021.02.04 16:46:34.356 1: PERL WARNING: Subroutine Signalbot_Initialize redefined at ./FHEM/50_Signalbot.pm line 29.
2021.02.04 16:46:34.359 1: PERL WARNING: Subroutine Signalbot_Set redefined at ./FHEM/50_Signalbot.pm line 50.
2021.02.04 16:46:34.360 1: PERL WARNING: Subroutine Signalbot_Get redefined at ./FHEM/50_Signalbot.pm line 175.
2021.02.04 16:46:34.363 1: PERL WARNING: Subroutine Signalbot_message_callback redefined at ./FHEM/50_Signalbot.pm line 180.
2021.02.04 16:46:34.364 1: PERL WARNING: Subroutine Signalbot_receipt_callback redefined at ./FHEM/50_Signalbot.pm line 253.
2021.02.04 16:46:34.364 1: PERL WARNING: Subroutine Signalbot_sync_callback redefined at ./FHEM/50_Signalbot.pm line 268.
2021.02.04 16:46:34.365 1: PERL WARNING: Subroutine Signalbot_disconnect redefined at ./FHEM/50_Signalbot.pm line 283.
2021.02.04 16:46:34.368 1: PERL WARNING: Subroutine Signalbot_setup redefined at ./FHEM/50_Signalbot.pm line 327.
2021.02.04 16:46:34.369 1: PERL WARNING: Subroutine Signalbot_Read redefined at ./FHEM/50_Signalbot.pm line 395.
2021.02.04 16:46:34.369 1: PERL WARNING: Subroutine Signalbot_getContactName redefined at ./FHEM/50_Signalbot.pm line 407.
2021.02.04 16:46:34.370 1: PERL WARNING: Subroutine Signalbot_translateContact redefined at ./FHEM/50_Signalbot.pm line 426.
2021.02.04 16:46:34.370 1: PERL WARNING: Subroutine Signalbot_translateGroup redefined at ./FHEM/50_Signalbot.pm line 439.
2021.02.04 16:46:34.371 1: PERL WARNING: Subroutine Signalbot_getNumber redefined at ./FHEM/50_Signalbot.pm line 461.
2021.02.04 16:46:34.372 1: PERL WARNING: Subroutine Signalbot_Refreshgroups redefined at ./FHEM/50_Signalbot.pm line 480.
2021.02.04 16:46:34.373 1: PERL WARNING: Subroutine Signalbot_sendMessage redefined at ./FHEM/50_Signalbot.pm line 498.
2021.02.04 16:46:34.374 1: PERL WARNING: Subroutine Signalbot_sendGroupMessage redefined at ./FHEM/50_Signalbot.pm line 521.
2021.02.04 16:46:34.375 1: PERL WARNING: Subroutine Signalbot_Execute redefined at ./FHEM/50_Signalbot.pm line 549.
2021.02.04 16:46:34.376 1: PERL WARNING: Subroutine Signalbot_Attr redefined at ./FHEM/50_Signalbot.pm line 559.
2021.02.04 16:46:34.376 1: PERL WARNING: Subroutine Signalbot_Notify redefined at ./FHEM/50_Signalbot.pm line 600.
2021.02.04 16:46:34.377 1: PERL WARNING: Subroutine Signalbot_Define redefined at ./FHEM/50_Signalbot.pm line 615.
2021.02.04 16:46:34.378 1: PERL WARNING: Subroutine Signalbot_Init redefined at ./FHEM/50_Signalbot.pm line 636.
2021.02.04 16:46:34.378 1: PERL WARNING: Subroutine Signalbot_Catch redefined at ./FHEM/50_Signalbot.pm line 655.
2021.02.04 16:46:34.379 1: PERL WARNING: Subroutine Signalbot_State redefined at ./FHEM/50_Signalbot.pm line 664.
2021.02.04 16:46:34.379 1: PERL WARNING: Subroutine Signalbot_Undef redefined at ./FHEM/50_Signalbot.pm line 670.
2021.02.04 16:46:34.380 1: PERL WARNING: Subroutine SignalBot_replaceCommands redefined at ./FHEM/50_Signalbot.pm line 683.
2021.02.04 16:46:34.382 1: PERL WARNING: Subroutine SignalBot_IdentifyStream redefined at ./FHEM/50_Signalbot.pm line 757.
sobald das Define eingebe, auch im FHEM WEB erhalte ich nur die 1
2021.02.04 16:48:54.212 1: define Signal Signalbot: 1Ich hatte ja, Dein signal_install.sh Script nicht im FHEM Container gestartet...
Könnte etwas fehlen? Nein, Das Perl Script hätte sonst gemeckert...
Hallo Thorben,
sorry steige jetzt bei den ganzen Posts nicht mehr durch
Zitatsobald das Define eingebe, auch im FHEM WEB erhalte ich nur die 1
dies hatte ich vor 3 Tagen bei der installation nach WIKI zu SiSi auch wenn der Pfad zur config nicht stimmt,
eventuell im Deinen Post um u.a. 13.08. Uhr Deine Telefonnummer unkenntlich machen? Nur mal so.
Gruß
Hans-Jürgen
Es sollte eigentlich eine Fehlermeldung geben wenn was nicht stimmt.
Wenn der einfach mit "1" abbricht, dann ist irgendwas faul - und wenn es nur mein Errorhandling ist.
Bei ersten Init ist die config der Nummer erstmal egal - das wird erst beim Senden relevant - aber der Dbus Service muss sauber laufen - da gibts aber Fehlermeldungen - eventuell wurden die aber nicht sauber durchgereicht. Hab ich jetzt ein bisschen überarbeitet.
Meine Logs sind fast alle auf loglevel 5 - wenn du mehr sehen willst musst du wohl global auf 5 stellen, da beim define ja der eigene verbose level noch gar nicht existiert.
Mein "define" Code war außerdem weitgehend copy&paste und enthält teils unötige Dinge.
Ich hange mal eine Version an, die dort etwas aufgeräumt ist und etwas mehr logging enthält.
Versuch mal die mit verbose=5 in global laufen zu lassen (wird halt ein langes logfile, aber die relevanten Zeilen lassen sich ja raus-"greppen".
Gruß,
Jörg
Moin Jörg,
Erfolg! Das Script läuft durch, die Nummer lässt sich mit der Anleitung wie man an das Captchas findet registrieren. Jetzt habe ich nur noch das Problem, dass der Net::DBus nicht geht. Ich habe bei meinem Produktiv System das -f glaube ich weggelassen...
root@Test:/opt/fhem/FHEM# cpan install -f Net:DBus
[....]
make -- NOT OK
No such file or directory
Mit apt-get install build-essentiall danach klappt das cpan install -f Net:DBus
aber: * 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 Thu 2021-02-04 19:34:07 UTC; 3min 3s ago
Process: 6129 ExecStart=/opt/fhem/signal/bin/signal-cli --config /var/lib/fhem -u +49yyyyyyy daemon --system (code=exited, status=2)
Main PID: 6129 (code=exited, status=2)
Feb 04 19:34:07 Test signal-cli[6129]: ERROR DaemonCommand - Dbus command failed
Feb 04 19:34:07 Test signal-cli[6129]: org.freedesktop.dbus.exceptions.DBusException: Connection ":1.29" is not allowed to own the service "org.asamk.Signal" due to security policies in the configuratio>
Feb 04 19:34:07 Test signal-cli[6129]: at org.freedesktop.dbus.connections.impl.DBusConnection.requestBusName(DBusConnection.java:481)
Feb 04 19:34:07 Test signal-cli[6129]: at org.asamk.signal.commands.DaemonCommand.handleCommand(DaemonCommand.java:68)
Feb 04 19:34:07 Test signal-cli[6129]: at org.asamk.signal.App.handleLocalCommand(App.java:209)
Feb 04 19:34:07 Test signal-cli[6129]: at org.asamk.signal.App.init(App.java:165)
Feb 04 19:34:07 Test signal-cli[6129]: at org.asamk.signal.Main.main(Main.java:43)
Feb 04 19:34:07 Test systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Feb 04 19:34:07 Test systemd[1]: signal.service: Failed with result 'exit-code'.
Feb 04 19:34:07 Test systemd[1]: Failed to start Send secure messages to Signal clients
Gruss
Enno
Hallo Enno,
Das mit dem "build-essential" hört sich vielversprechend an. Ich werde nämlich langsam wahnsinnig die möglichen Packages für fehlende Perl Module zu finden (die bei mir alle da waren).
Habe ich gleich mal integriert.
Ich denke dein anderes Problem habe ich auch gefunden. An einer Stelle steht noch fest "signal-cli" als user und du nimmst ja einen anderen. (Immer diese Anwender mit Sonderlocken ;) )
Lass mal dieses Script laufen.
Gruß,
Jörg
... und wieder einen Schritt weiter. Signal Device lässt sich anlegen:
Internals:
FD 4
FUUID 601c5c7a-f33f-5579-5374-8be64b9007bed36d
NAME SIGNAL
NOTIFYDEV global
NR 14
NTFY_ORDER 50-SIGNAL
STATE Connected
TYPE Signalbot
helper:
msignal 1
rsignal 3
ssignal 2
timer 0
Attributes:
defaultPeer +49yyyy
room Signal
aber beim Senden folgende Fehlermeldung im Log:
Error sending message:org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
Empfang klappt aber...
Hallo Enno,
Da wäre jetzt wahrscheinlich das syslog hilfreich.
Wobei ich selbst am Anfang mal das Problem hatte, das ich nicht empfangen aber senden konnte (oder wars anders rum?) - und die Lösung war einfach: Reboot
Hast du das schon probiert?
Jörg
Hallo Enno,
blindes Huhn wie ich findet auch mal ein Korn ;)
wie ich auch schon geschrieben hatte Neustart.
Gruß
Hans-Jürgen
Moin Jörg,
ist doch kein Windows ;) - Aber klar, habe einen Reboot gemacht. Senden geht nicht, Empfangen schon.
Syslog hier:
Feb 4 20:37:36 Test systemd-sysctl[52]: Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
Feb 4 20:37:36 Test systemd-sysctl[52]: Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
Feb 4 20:37:36 Test keyboard-setup.sh[55]: Couldn't get a file descriptor referring to the console
Feb 4 20:37:36 Test systemd-sysctl[52]: Couldn't write 'fq_codel' to 'net/core/default_qdisc', ignoring: No such file or directory
Feb 4 20:37:36 Test keyboard-setup.sh[57]: Couldn't get a file descriptor referring to the console
Feb 4 20:37:36 Test systemd[1]: Starting Flush Journal to Persistent Storage...
Feb 4 20:37:36 Test keyboard-setup.sh[58]: Couldn't get a file descriptor referring to the console
Feb 4 20:37:36 Test systemd[1]: Finished Create Static Device Nodes in /dev.
Feb 4 20:37:36 Test systemd[1]: Condition check resulted in Rule-based Manager for Device Events and Files being skipped.
Feb 4 20:37:36 Test systemd[1]: Starting Network Service...
Feb 4 20:37:36 Test systemd[1]: Finished Flush Journal to Persistent Storage.
Feb 4 20:37:36 Test dbus-daemon[102]: [system] AppArmor D-Bus mediation is enabled
Feb 4 20:37:36 Test systemd[1]: Finished Hold until boot process finishes up.
Feb 4 20:37:36 Test systemd[1]: Started Console Getty.
Feb 4 20:37:36 Test systemd[1]: Condition check resulted in Container Getty on /dev/tty0 being skipped.
Feb 4 20:37:36 Test systemd[1]: Started Container Getty on /dev/tty1.
Feb 4 20:37:36 Test systemd[1]: Started Container Getty on /dev/tty2.
Feb 4 20:37:36 Test systemd[1]: Reached target Login Prompts.
Feb 4 20:37:36 Test systemd[1]: Condition check resulted in Set console scheme being skipped.
Feb 4 20:37:36 Test systemd[1]: Finished Terminate Plymouth Boot Screen.
Feb 4 20:37:36 Test ipmiutil_wdt[109]: Starting ipmiutil_wdt:
Feb 4 20:37:36 Test ipmiutil_wdt[133]: Cannot map memory.
Feb 4 20:37:36 Test ipmiutil_wdt[133]: Cannot open an IPMI driver: /dev/imb, /dev/ipmi0, /dev/ipmi/0,
Feb 4 20:37:36 Test ipmiutil_wdt[133]: #011 or direct driverless.
Feb 4 20:37:36 Test ipmiutil_wdt[109]: /usr/share/ipmiutil/ipmiutil_wdt: 49: ipmiutil_wdt: not found
Feb 4 20:37:36 Test systemd[1]: ipmiutil_wdt.service: Main process exited, code=exited, status=127/n/a
Feb 4 20:37:36 Test systemd[1]: ipmiutil_wdt.service: Failed with result 'exit-code'.
Feb 4 20:37:36 Test accounts-daemon[99]: started daemon version 0.6.55
Feb 4 20:37:36 Test systemd[1]: Started Accounts Service.
Feb 4 20:37:36 Test systemd[1]: Started OpenBSD Secure Shell server.
Feb 4 20:37:36 Test systemd[1]: Started User Login Management.
Feb 4 20:37:36 Test networkd-dispatcher[105]: No valid path found for iwconfig
Feb 4 20:37:36 Test networkd-dispatcher[105]: No valid path found for iw
Feb 4 20:37:36 Test systemd[1]: Started Dispatcher daemon for systemd-networkd.
Feb 4 20:37:36 Test systemd[1]: Started FHEM Home Automation.
Feb 4 20:37:36 Test systemd[1]: e2scrub_reap.service: Succeeded.
Feb 4 20:37:36 Test systemd[1]: Finished Remove Stale Online ext4 Metadata Check Snapshots.
Feb 4 20:37:36 Test postfix/postfix-script[261]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Feb 4 20:37:36 Test postfix/postfix-script[297]: starting the Postfix mail system
Feb 4 20:37:36 Test postfix/master[299]: daemon started -- version 3.5.6, configuration /etc/postfix
Feb 4 20:37:36 Test systemd[1]: Started Postfix Mail Transport Agent (instance -).
Feb 4 20:37:36 Test systemd[1]: Starting Postfix Mail Transport Agent...
Feb 4 20:37:36 Test systemd[1]: Finished Postfix Mail Transport Agent.
Feb 4 20:37:36 Test systemd[1]: Reached target Multi-User System.
Feb 4 20:37:36 Test systemd[1]: Reached target Graphical Interface.
Feb 4 20:37:36 Test systemd[1]: Starting Update UTMP about System Runlevel Changes...
Feb 4 20:37:36 Test systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Feb 4 20:37:36 Test systemd[1]: Finished Update UTMP about System Runlevel Changes.
Feb 4 20:37:36 Test systemd[1]: Startup finished in 1.254s.
Feb 4 20:37:36 Test systemd[1]: dmesg.service: Succeeded.
Feb 4 20:37:37 Test systemd-networkd[66]: eth0: Gained IPv6LL
Feb 4 20:39:27 Test dbus-daemon[102]: [system] Reloaded configuration
Feb 4 20:39:27 Test systemd[1]: Reloading.
Feb 4 20:39:27 Test systemd[1]: /lib/systemd/system/dbus.service:12: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
Feb 4 20:39:27 Test systemd[1]: /lib/systemd/system/plymouth-start.service:17: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
Feb 4 20:39:27 Test systemd[1]: Reloading.
Feb 4 20:39:27 Test systemd[1]: /lib/systemd/system/dbus.service:12: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
Feb 4 20:39:27 Test systemd[1]: /lib/systemd/system/plymouth-start.service:17: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
Feb 4 20:39:27 Test systemd[1]: Started Run anacron jobs.
Feb 4 20:39:27 Test systemd[1]: Reloading D-Bus System Message Bus.
Feb 4 20:39:27 Test anacron[1153]: Anacron 2.3 started on 2021-02-04
Feb 4 20:39:27 Test anacron[1153]: Normal exit (0 jobs run)
Feb 4 20:39:27 Test systemd[1]: anacron.service: Succeeded.
Feb 4 20:39:27 Test dbus-daemon[102]: [system] Reloaded configuration
Feb 4 20:39:27 Test dbus-send[1155]: method return time=1612471167.410032 sender=org.freedesktop.DBus -> destination=:1.9 serial=3 reply_serial=2
Feb 4 20:39:27 Test systemd[1]: Reloaded D-Bus System Message Bus.
Feb 4 20:42:03 Test systemd[1]: Starting Send secure messages to Signal clients...
Feb 4 20:42:07 Test signal-cli[1364]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal
Feb 4 20:42:07 Test systemd[1]: Started Send secure messages to Signal clients.
Feb 4 20:42:52 Test systemd[1]: Stopping Send secure messages to Signal clients...
Feb 4 20:42:52 Test systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Feb 4 20:42:52 Test systemd[1]: signal.service: Failed with result 'exit-code'.
Feb 4 20:42:52 Test systemd[1]: Stopped Send secure messages to Signal clients.
Feb 4 20:43:01 Test systemd[1]: Starting Send secure messages to Signal clients...
Feb 4 20:43:05 Test signal-cli[1490]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal
Feb 4 20:43:05 Test systemd[1]: Started Send secure messages to Signal clients.
Feb 4 20:43:06 Test signal-cli[1490]: Envelope from: +49yyyy (device: 1)
Feb 4 20:43:06 Test signal-cli[1490]: Timestamp: 1612471379349 (2021-02-04T20:42:59.349Z)
Feb 4 20:43:06 Test signal-cli[1490]: Got receipt.
Feb 4 20:43:06 Test signal-cli[1490]: Envelope from: +49yyy (device: 1)
Feb 4 20:43:06 Test signal-cli[1490]: Timestamp: 1612471379349 (2021-02-04T20:42:59.349Z)
Feb 4 20:43:06 Test signal-cli[1490]: Got receipt.
Feb 4 20:43:07 Test signal-cli[1490]: Envelope from: +49yyy (device: 1)
Feb 4 20:43:07 Test signal-cli[1490]: Timestamp: 1612471385722 (2021-02-04T20:43:05.722Z)
Feb 4 20:43:07 Test signal-cli[1490]: Got receipt.
Feb 4 20:45:05 Test systemd[1]: fhem.service: Succeeded.
Feb 4 20:45:05 Test systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Feb 4 20:45:05 Test systemd[1]: Stopped FHEM Home Automation.
Feb 4 20:45:05 Test systemd[1]: Starting FHEM Home Automation...
Feb 4 20:45:05 Test systemd[1]: Started FHEM Home Automation.
Feb 4 20:48:32 Test systemd[1]: fhem.service: Main process exited, code=exited, status=11/n/a
Feb 4 20:48:32 Test systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 4 20:48:33 Test systemd[1]: fhem.service: Scheduled restart job, restart counter is at 2.
Feb 4 20:48:33 Test systemd[1]: Stopped FHEM Home Automation.
Feb 4 20:48:33 Test systemd[1]: Starting FHEM Home Automation...
Feb 4 20:48:33 Test systemd[1]: Started FHEM Home Automation.
Feb 4 20:48:42 Test systemd[1]: fhem.service: Main process exited, code=exited, status=11/n/a
Feb 4 20:48:42 Test systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 4 20:48:42 Test systemd[1]: fhem.service: Scheduled restart job, restart counter is at 3.
Feb 4 20:48:42 Test systemd[1]: Stopped FHEM Home Automation.
Feb 4 20:48:42 Test systemd[1]: Starting FHEM Home Automation...
Feb 4 20:48:42 Test systemd[1]: Started FHEM Home Automation.
Feb 4 20:49:30 Test signal-cli[1490]: Feb 04, 2021 8:49:30 PM okhttp3.internal.platform.Platform log
Feb 4 20:49:30 Test signal-cli[1490]: WARNING: A connection to https://textsecure-service.whispersystems.org/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
Feb 4 20:50:44 Test signal-cli[1490]: Feb 04, 2021 8:50:44 PM okhttp3.internal.platform.Platform log
Feb 4 20:50:44 Test signal-cli[1490]: WARNING: A connection to https://textsecure-service.whispersystems.org/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
Feb 4 20:52:12 Test signal-cli[1490]: Feb 04, 2021 8:52:12 PM okhttp3.internal.platform.Platform log
Feb 4 20:52:12 Test signal-cli[1490]: WARNING: A connection to https://textsecure-service.whispersystems.org/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
Feb 4 20:52:35 Test systemd[1]: Starting Cleanup of Temporary Directories...
Feb 4 20:52:35 Test systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Feb 4 20:52:35 Test systemd[1]: Finished Cleanup of Temporary Directories.
Feb 4 20:54:06 Test signal-cli[1490]: Envelope from: unknown source
Feb 4 20:54:06 Test signal-cli[1490]: Timestamp: 1612472045219 (2021-02-04T20:54:05.219Z)
Feb 4 20:54:06 Test signal-cli[1490]: Sent by unidentified/sealed sender
Feb 4 20:54:06 Test signal-cli[1490]: Sender: ?Enno
Feb 4 20:54:06 Test signal-cli[1490]: Detke? +49yyyyy (device: 1)
Feb 4 20:54:06 Test signal-cli[1490]: Message timestamp: 1612472045219 (2021-02-04T20:54:05.219Z)
Feb 4 20:54:06 Test signal-cli[1490]: Body: Tree
Feb 4 20:54:06 Test signal-cli[1490]: Profile key update, key length:32
Feb 4 20:55:33 Test systemd[1]: fhem.service: Main process exited, code=exited, status=11/n/a
Feb 4 20:55:33 Test systemd[1]: fhem.service: Failed with result 'exit-code'.
Feb 4 20:55:33 Test systemd[1]: fhem.service: Scheduled restart job, restart counter is at 4.
Feb 4 20:55:33 Test systemd[1]: Stopped FHEM Home Automation.
Feb 4 20:55:33 Test systemd[1]: Starting FHEM Home Automation...
Feb 4 20:55:33 Test systemd[1]: Started FHEM Home Automation.
Feb 4 20:55:58 Test signal-cli[1490]: Feb 04, 2021 8:55:58 PM okhttp3.internal.platform.Platform log
Feb 4 20:55:58 Test signal-cli[1490]: WARNING: A connection to https://textsecure-service.whispersystems.org/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
Feb 4 21:01:09 Test systemd[1]: Received SIGRTMIN+3.
Feb 4 21:01:09 Test systemd[1]: Removed slice system-modprobe.slice.
Feb 4 21:01:09 Test systemd[1]: Stopped target Graphical Interface.
Feb 4 21:01:09 Test systemd[1]: Stopped target Multi-User System.
Feb 4 21:01:09 Test systemd[1]: Stopped target Login Prompts.
Feb 4 21:01:09 Test systemd[1]: Stopped target RPC Port Mapper.
Feb 4 21:01:09 Test systemd[1]: Stopped target Timers.
Feb 4 21:01:09 Test systemd[1]: anacron.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Trigger anacron every hour.
Feb 4 21:01:09 Test systemd[1]: apt-daily-upgrade.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Daily apt upgrade and clean activities.
Feb 4 21:01:09 Test systemd[1]: apt-daily.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Daily apt download activities.
Feb 4 21:01:09 Test systemd[1]: e2scrub_all.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Periodic ext4 Online Metadata Check for All Filesystems.
Feb 4 21:01:09 Test systemd[1]: logrotate.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Daily rotation of log files.
Feb 4 21:01:09 Test systemd[1]: man-db.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Daily man-db regeneration.
Feb 4 21:01:09 Test systemd[1]: motd-news.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Message of the Day.
Feb 4 21:01:09 Test systemd[1]: systemd-tmpfiles-clean.timer: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Daily Cleanup of Temporary Directories.
Feb 4 21:01:09 Test systemd[1]: Stopped target System Time Synchronized.
Feb 4 21:01:09 Test systemd[1]: Stopped target System Time Set.
Feb 4 21:01:09 Test systemd[1]: Reached target Unmount All Filesystems.
Feb 4 21:01:09 Test systemd[1]: Stopping Accounts Service...
Feb 4 21:01:09 Test systemd[1]: Stopping Console Getty...
Feb 4 21:01:09 Test systemd[1]: Stopping Container Getty on /dev/tty1...
Feb 4 21:01:09 Test systemd[1]: Stopping Container Getty on /dev/tty2...
Feb 4 21:01:09 Test systemd[1]: Stopping Regular background program processing daemon...
Feb 4 21:01:09 Test systemd[1]: Stopping D-Bus System Message Bus...
Feb 4 21:01:09 Test systemd[1]: Stopping FHEM Home Automation...
Feb 4 21:01:09 Test systemd[1]: Stopping Dispatcher daemon for systemd-networkd...
Feb 4 21:01:09 Test systemd[1]: Condition check resulted in Show Plymouth Halt Screen being skipped.
Feb 4 21:01:09 Test systemd[1]: plymouth-quit.service: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Terminate Plymouth Boot Screen.
Feb 4 21:01:09 Test systemd[1]: postfix.service: Succeeded.
Feb 4 21:01:09 Test systemd[1]: Stopped Postfix Mail Transport Agent.
Feb 4 21:01:09 Test systemd[1]: Stopping Postfix Mail Transport Agent (instance -)...
Feb 4 21:07:32 Test systemd-sysctl[52]: Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
Feb 4 21:07:32 Test systemd-sysctl[52]: Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
Feb 4 21:07:32 Test keyboard-setup.sh[55]: Couldn't get a file descriptor referring to the console
Feb 4 21:07:32 Test systemd-sysctl[52]: Couldn't write 'fq_codel' to 'net/core/default_qdisc', ignoring: No such file or directory
Feb 4 21:07:32 Test keyboard-setup.sh[57]: Couldn't get a file descriptor referring to the console
Feb 4 21:07:32 Test systemd[1]: Starting Flush Journal to Persistent Storage...
Feb 4 21:07:32 Test keyboard-setup.sh[58]: Couldn't get a file descriptor referring to the console
Feb 4 21:07:32 Test systemd[1]: Finished Create Static Device Nodes in /dev.
Feb 4 21:07:32 Test systemd[1]: Condition check resulted in Rule-based Manager for Device Events and Files being skipped.
Feb 4 21:07:32 Test systemd[1]: Starting Network Service...
Feb 4 21:07:32 Test pidof[65]: can't read from 60/stat
Feb 4 21:07:32 Test systemd[1]: Finished Permit User Sessions.
Feb 4 21:07:32 Test systemd[1]: Finished Hold until boot process finishes up.
Feb 4 21:07:32 Test systemd[1]: Started Console Getty.
Feb 4 21:07:32 Test systemd[1]: Condition check resulted in Container Getty on /dev/tty0 being skipped.
Feb 4 21:07:32 Test systemd[1]: Started Container Getty on /dev/tty1.
Feb 4 21:07:32 Test systemd[1]: Started Container Getty on /dev/tty2.
Feb 4 21:07:32 Test systemd[1]: Reached target Login Prompts.
Feb 4 21:07:32 Test systemd[1]: Condition check resulted in Set console scheme being skipped.
Feb 4 21:07:32 Test systemd[1]: Finished Terminate Plymouth Boot Screen.
Feb 4 21:07:32 Test ipmiutil_wdt[109]: Starting ipmiutil_wdt:
Feb 4 21:07:32 Test systemd[1]: Started OpenBSD Secure Shell server.
Feb 4 21:07:32 Test ipmiutil_wdt[136]: Cannot map memory.
Feb 4 21:07:32 Test ipmiutil_wdt[136]: Cannot open an IPMI driver: /dev/imb, /dev/ipmi0, /dev/ipmi/0,
Feb 4 21:07:32 Test ipmiutil_wdt[136]: #011 or direct driverless.
Feb 4 21:07:32 Test ipmiutil_wdt[109]: /usr/share/ipmiutil/ipmiutil_wdt: 49: ipmiutil_wdt: not found
Feb 4 21:07:32 Test systemd[1]: ipmiutil_wdt.service: Main process exited, code=exited, status=127/n/a
Feb 4 21:07:32 Test systemd[1]: ipmiutil_wdt.service: Failed with result 'exit-code'.
Feb 4 21:07:32 Test accounts-daemon[99]: started daemon version 0.6.55
Feb 4 21:07:32 Test systemd[1]: Started Accounts Service.
Feb 4 21:07:33 Test systemd[1]: Started User Login Management.
Feb 4 21:07:33 Test networkd-dispatcher[105]: No valid path found for iwconfig
Feb 4 21:07:33 Test networkd-dispatcher[105]: No valid path found for iw
Feb 4 21:07:33 Test systemd[1]: Started Dispatcher daemon for systemd-networkd.
Feb 4 21:07:33 Test systemd[1]: Started FHEM Home Automation.
Feb 4 21:07:33 Test systemd[1]: e2scrub_reap.service: Succeeded.
Feb 4 21:07:33 Test systemd[1]: Finished Remove Stale Online ext4 Metadata Check Snapshots.
Feb 4 21:07:33 Test dbus-daemon[102]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.service' requested by ':1.6' (uid=998 pid=175 comm="/usr/bin/perl fhem.pl fhem.cfg " label="unconfined")
Feb 4 21:07:33 Test systemd[1]: Starting Send secure messages to Signal clients...
Feb 4 21:07:33 Test postfix/postfix-script[280]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Feb 4 21:07:33 Test postfix/postfix-script[323]: starting the Postfix mail system
Feb 4 21:07:33 Test postfix/master[325]: daemon started -- version 3.5.6, configuration /etc/postfix
Feb 4 21:07:33 Test systemd[1]: Started Postfix Mail Transport Agent (instance -).
Feb 4 21:07:33 Test systemd[1]: Starting Postfix Mail Transport Agent...
Feb 4 21:07:33 Test systemd[1]: Finished Postfix Mail Transport Agent.
Feb 4 21:07:33 Test systemd[1]: Reached target Multi-User System.
Feb 4 21:07:33 Test systemd[1]: Reached target Graphical Interface.
Feb 4 21:07:33 Test systemd[1]: Starting Update UTMP about System Runlevel Changes...
Feb 4 21:07:33 Test systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
Feb 4 21:07:33 Test systemd[1]: Finished Update UTMP about System Runlevel Changes.
Feb 4 21:07:34 Test systemd-networkd[66]: eth0: Gained IPv6LL
Feb 4 21:07:37 Test systemd[1]: dmesg.service: Succeeded.
Feb 4 21:07:38 Test signal-cli[219]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal
Feb 4 21:07:38 Test dbus-daemon[102]: [system] Successfully activated service 'org.asamk.Signal'
Feb 4 21:07:38 Test systemd[1]: Started Send secure messages to Signal clients.
Feb 4 21:07:38 Test systemd[1]: Startup finished in 6.077s.
root@Test:/var/log#
Gruss
Enno
Hi Enno,
mit der Meldung kann ich rein gar nichts anfangen und Google findet auch nichts hilfreiches.
Lass uns nochmal eingrenzen obs am FHEM/perl liegt oder am Service selbst
Dann nutzen wir doch einfach mal den vorsorglich eingebauten Selbsttest des Installations Scripts:
sudo ./signal_install.sh test
Der probiert erst eine reine command line message und dann eine DBus message via "dbus_send" Programm.
Wenn der Empfänger beide Nachrichten bekommt, stimmt wohl noch was nicht mit deiner FHEM/Perl Installation.
Jörg
Moin Jörg,
die beiden Nachrichten gehen raus. Der Test wird ja auch durchgeführt, wenn das Script alles installiert. Der Teil funktioniert. Ich vermute auch, dass bei FHEM und Perl irgend etwas fehlt.
root@Test:~# sh signal.sh test
signal.sh: 19: source: not found
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: fhem
Signal-cli Install directory: /opt/fhem
Signal config storage: /var/lib/fhem
Signal version: 0.7.4
System library path: /usr/lib
Phone number to be used: +49yyyy
Your configuration
Linux Test 5.4.78-2-pve #1 SMP PVE 5.4.78-2 (Thu, 03 Dec 2020 14:26:17 +0100) x86_64 x86_64 x86_64 GNU/Linux
has not been tested, continue at own risk
Your chose the following option: test
Proceed (Y/n)? y
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49ZZZ
Sending a message from command line to +49ZZZ
Stopping Signal service to get exclusive access to configuration
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
1612506645289
Sending a message from via dbus to +49ZZZZ
method return time=1612506652.600001 sender=:1.9 -> destination=:1.10 serial=7 reply_serial=2
int64 1612506651551
Restarting signal service
If the recipient got the messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
Gruss
Enno
Hi Enno,
das ist doch schon mal gut.
Dann kann eigentlich nur das Net::DBus durch die vielen "halben" Versuche der Installation irgendein Problem haben.
Mach das nochmal ohne -f und schau wo es abbricht bzw. google mal wie man eine Deinstallation und erneute installation macht.
Am Ende braucht man das -f , aber das ist erst beim Selbsttest, die eigentliche Insallation muss ohne -f funktionieren.
EDIT: Und lass mich mal suchen, ich hab irgendwo noch ein Testscript, das nur mit Perl und NET:Dbus läuft - aber außerhalb von FHEM, dann können wirs richtig eingrenzen.
Jörg
Guten Morgen,
Danke, Hans-Jürgen die Telefonnummer ist mir durchgerutscht, habe ich geändert.
So ich habe die neue 50_Signalbot.pm installiert, Reload und dann define... Absturz
2021.02.05 08:40:10.699 1: PERL WARNING: Subroutine Signalbot_Get redefined at ./FHEM/50_Signalbot.pm line 176.
2021.02.05 08:40:10.700 1: PERL WARNING: Subroutine Signalbot_message_callback redefined at ./FHEM/50_Signalbot.pm line 181.
2021.02.05 08:40:10.701 1: PERL WARNING: Subroutine Signalbot_receipt_callback redefined at ./FHEM/50_Signalbot.pm line 254.
2021.02.05 08:40:10.701 1: PERL WARNING: Subroutine Signalbot_sync_callback redefined at ./FHEM/50_Signalbot.pm line 269.
2021.02.05 08:40:10.702 1: PERL WARNING: Subroutine Signalbot_disconnect redefined at ./FHEM/50_Signalbot.pm line 284.
2021.02.05 08:40:10.703 1: PERL WARNING: Subroutine Signalbot_setup redefined at ./FHEM/50_Signalbot.pm line 328.
2021.02.05 08:40:10.704 1: PERL WARNING: Subroutine Signalbot_Read redefined at ./FHEM/50_Signalbot.pm line 396.
2021.02.05 08:40:10.704 1: PERL WARNING: Subroutine Signalbot_getContactName redefined at ./FHEM/50_Signalbot.pm line 408.
2021.02.05 08:40:10.704 1: PERL WARNING: Subroutine Signalbot_translateContact redefined at ./FHEM/50_Signalbot.pm line 427.
2021.02.05 08:40:10.704 1: PERL WARNING: Subroutine Signalbot_translateGroup redefined at ./FHEM/50_Signalbot.pm line 440.
2021.02.05 08:40:10.705 1: PERL WARNING: Subroutine Signalbot_getNumber redefined at ./FHEM/50_Signalbot.pm line 462.
2021.02.05 08:40:10.705 1: PERL WARNING: Subroutine Signalbot_Refreshgroups redefined at ./FHEM/50_Signalbot.pm line 481.
2021.02.05 08:40:10.706 1: PERL WARNING: Subroutine Signalbot_sendMessage redefined at ./FHEM/50_Signalbot.pm line 499.
2021.02.05 08:40:10.706 1: PERL WARNING: Subroutine Signalbot_sendGroupMessage redefined at ./FHEM/50_Signalbot.pm line 522.
2021.02.05 08:40:10.707 1: PERL WARNING: Subroutine Signalbot_Execute redefined at ./FHEM/50_Signalbot.pm line 550.
2021.02.05 08:40:10.707 1: PERL WARNING: Subroutine Signalbot_Attr redefined at ./FHEM/50_Signalbot.pm line 560.
2021.02.05 08:40:10.707 1: PERL WARNING: Subroutine Signalbot_Notify redefined at ./FHEM/50_Signalbot.pm line 601.
2021.02.05 08:40:10.708 1: PERL WARNING: Subroutine Signalbot_Define redefined at ./FHEM/50_Signalbot.pm line 616.
2021.02.05 08:40:10.708 1: PERL WARNING: Subroutine Signalbot_Catch redefined at ./FHEM/50_Signalbot.pm line 659.
2021.02.05 08:40:10.709 1: PERL WARNING: Subroutine Signalbot_State redefined at ./FHEM/50_Signalbot.pm line 668.
2021.02.05 08:40:10.709 1: PERL WARNING: Subroutine Signalbot_Undef redefined at ./FHEM/50_Signalbot.pm line 674.
2021.02.05 08:40:10.710 1: PERL WARNING: Subroutine SignalBot_replaceCommands redefined at ./FHEM/50_Signalbot.pm line 687.
2021.02.05 08:40:10.710 1: PERL WARNING: Subroutine SignalBot_IdentifyStream redefined at ./FHEM/50_Signalbot.pm line 761.
org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
/entry.sh: line 621: kill: (12397) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (12397) - No such process
10/entry.sh: line 625: kill: (12397) - No such process
9/entry.sh: line 625: kill: (12397) - No such process
8/entry.sh: line 625: kill: (12397) - No such process
7/entry.sh: line 625: kill: (12397) - No such process
6/entry.sh: line 625: kill: (12397) - No such process
5/entry.sh: line 625: kill: (12397) - No such process
4/entry.sh: line 625: kill: (12397) - No such process
3/entry.sh: line 625: kill: (12397) - No such process
2/entry.sh: line 625: kill: (12397) - No such process
mit Restart..
Zitat von: Adimarantis am 05 Februar 2021, 08:23:54
Mach das nochmal ohne -f und schau wo es abbricht bzw. google mal wie man eine Deinstallation und erneute installation macht.
Ich habe den Container als Vorlage "nackt" nur mit Ubuntu und FHEM da kann ich jederzeit starten:-). Geht los....
sudo cpan install -f Net:DBusbricht ab mit Fehlermeldung:
Files=109, Tests=71, 3 wallclock secs ( 0.16 usr 0.09 sys + 2.57 cusr 0.48 csys = 3.30 CPU)
Result: FAIL
Failed 104/109 test programs. 32/71 subtests failed.
make: *** [Makefile:837: test_dynamic] Error 2
MIROD/XML-Twig-3.52.tar.gz
one dependency not OK (XML::Parser); additionally test harness failed
make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports MIROD/XML-Twig-3.52.tar.gzsudo apt install xml-twig-tools und dann läuft es durch. "Test ok"
Signal in FHEM definiert, keine Fehlermeldung, Nachricht gesendet => ok, Nachricht empfangen => ok!
Herzlichen Glückwunsch! Es läuft! Ich habe fertig!Gruss
Enno
Prima, dann nehme ich das Paket noch in die Abhängigkeiten.
Jörg
Hallo,
habe mal etwas weiter getestet.
FHEM im Dock auf Raspberry PI 4
- das Script signale_install.sh mit abgeschalteter Docker Prüfung im Docker Container als root gestartet
- Das Script lief fehlerfrei durch, Signal Nachricht konnte gesendet werden
- In der Docker Console al fhem signal-cli ausgeführt, Nachricht konnte gesendet werden
- im FHEM reload 50_Signalbot.pm ausgeführt
- im FHEM define Signal Signalbot ausgeführt, Fehler mit Reboot
FHEM reload 50_Signalbot.pm
2021.02.05 16:06:48.364 1: PERL WARNING: Subroutine Signalbot_Initialize redefined at ./FHEM/50_Signalbot.pm line 29.
2021.02.05 16:06:48.367 1: PERL WARNING: Subroutine Signalbot_Set redefined at ./FHEM/50_Signalbot.pm line 50.
2021.02.05 16:06:48.368 1: PERL WARNING: Subroutine Signalbot_Get redefined at ./FHEM/50_Signalbot.pm line 176.
2021.02.05 16:06:48.369 1: PERL WARNING: Subroutine Signalbot_message_callback redefined at ./FHEM/50_Signalbot.pm line 181.
2021.02.05 16:06:48.370 1: PERL WARNING: Subroutine Signalbot_receipt_callback redefined at ./FHEM/50_Signalbot.pm line 254.
2021.02.05 16:06:48.371 1: PERL WARNING: Subroutine Signalbot_sync_callback redefined at ./FHEM/50_Signalbot.pm line 269.
2021.02.05 16:06:48.371 1: PERL WARNING: Subroutine Signalbot_disconnect redefined at ./FHEM/50_Signalbot.pm line 284.
2021.02.05 16:06:48.373 1: PERL WARNING: Subroutine Signalbot_setup redefined at ./FHEM/50_Signalbot.pm line 328.
2021.02.05 16:06:48.374 1: PERL WARNING: Subroutine Signalbot_Read redefined at ./FHEM/50_Signalbot.pm line 396.
2021.02.05 16:06:48.374 1: PERL WARNING: Subroutine Signalbot_getContactName redefined at ./FHEM/50_Signalbot.pm line 408.
2021.02.05 16:06:48.375 1: PERL WARNING: Subroutine Signalbot_translateContact redefined at ./FHEM/50_Signalbot.pm line 427.
2021.02.05 16:06:48.375 1: PERL WARNING: Subroutine Signalbot_translateGroup redefined at ./FHEM/50_Signalbot.pm line 440.
2021.02.05 16:06:48.375 1: PERL WARNING: Subroutine Signalbot_getNumber redefined at ./FHEM/50_Signalbot.pm line 462.
2021.02.05 16:06:48.376 1: PERL WARNING: Subroutine Signalbot_Refreshgroups redefined at ./FHEM/50_Signalbot.pm line 481.
2021.02.05 16:06:48.376 1: PERL WARNING: Subroutine Signalbot_sendMessage redefined at ./FHEM/50_Signalbot.pm line 499.
2021.02.05 16:06:48.377 1: PERL WARNING: Subroutine Signalbot_sendGroupMessage redefined at ./FHEM/50_Signalbot.pm line 522.
2021.02.05 16:06:48.377 1: PERL WARNING: Subroutine Signalbot_Execute redefined at ./FHEM/50_Signalbot.pm line 550.
2021.02.05 16:06:48.378 1: PERL WARNING: Subroutine Signalbot_Attr redefined at ./FHEM/50_Signalbot.pm line 560.
2021.02.05 16:06:48.379 1: PERL WARNING: Subroutine Signalbot_Notify redefined at ./FHEM/50_Signalbot.pm line 601.
2021.02.05 16:06:48.379 1: PERL WARNING: Subroutine Signalbot_Define redefined at ./FHEM/50_Signalbot.pm line 616.
2021.02.05 16:06:48.380 1: PERL WARNING: Subroutine Signalbot_Init redefined at ./FHEM/50_Signalbot.pm line 636.
2021.02.05 16:06:48.380 1: PERL WARNING: Subroutine Signalbot_Catch redefined at ./FHEM/50_Signalbot.pm line 659.
2021.02.05 16:06:48.380 1: PERL WARNING: Subroutine Signalbot_State redefined at ./FHEM/50_Signalbot.pm line 668.
2021.02.05 16:06:48.381 1: PERL WARNING: Subroutine Signalbot_Undef redefined at ./FHEM/50_Signalbot.pm line 674.
2021.02.05 16:06:48.382 1: PERL WARNING: Subroutine SignalBot_replaceCommands redefined at ./FHEM/50_Signalbot.pm line 687.
2021.02.05 16:06:48.383 1: PERL WARNING: Subroutine SignalBot_IdentifyStream redefined at ./FHEM/50_Signalbot.pm line 761.
org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
2021.02.05 16:10:03.971 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
/entry.sh: line 621: kill: (23895) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (23895) - No such process
10/entry.sh: line 625: kill: (23895) - No such process
9/entry.sh: line 625: kill: (23895) - No such process
8/entry.sh: line 625: kill: (23895) - No such process
7/entry.sh: line 625: kill: (23895) - No such process
6/entry.sh: line 625: kill: (23895) - No such process
5/entry.sh: line 625: kill: (23895) - No such process
4/entry.sh: line 625: kill: (23895) - No such process
3/entry.sh: line 625: kill: (23895) - No such process
2/entry.sh: line 625: kill: (23895) - No such process
1/entry.sh: line 625: kill: (23895) - No such process
0/entry.sh: line 632: kill: (23895) - No such process
Automatic restart ...
/entry.sh: line 645: kill: (23895) - No such process
Running /pre-start.sh script ...
Starting DBus System Daemon
Starting signal-cli
Wait 5 to give signal-cli time to come up
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource14840447632239917888.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
ERROR App - User +49quelle is not registered.
Preparing configuration ... done
Starting FHEM ...
org.freedesktop.DBus.Error.Spawn.ChildExited dieser Fehler scheint auf den DBUS zu zeigen.
Und warum sagt er, meine Rufnummer wäre nicht registriert?
Hat jemand eine Idee...
by the way, ich erstelle das Dockerfile wie folgt
ARG BASE_IMAGE="fhem/fhem"
ARG BASE_IMAGE_TAG="latest"
FROM ${BASE_IMAGE}:${BASE_IMAGE_TAG}
ARG L_SIGNAL_CLI="0.7.4"
# Install base environment
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends \
cpanminus \
build-essential \
wget \
shared-mime-info \
# default-jre-headless \
libunixsocket-java \
dbus \
libnet-dbus-perl \
shared-mime-info \
haveged \
# default-jdk \
net-tools \
nano \
systemd \
hping3 \
wakeonlan \
&& wget https://download.bell-sw.com/java/11.0.10+9/bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& apt-get install -qqy --no-install-recommends ./bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& cpanm \
Net::DBus \
Lirc::Client \
Crypt::Cipher::AES \
&& rm -rf /root/.cpanm \
&& wget https://github.com/AsamK/signal-cli/releases/download/v${L_SIGNAL_CLI}/signal-cli-${L_SIGNAL_CLI}.tar.gz \
&& tar xf signal-cli-${L_SIGNAL_CLI}.tar.gz -C /opt \
# && mv /opt/fhem/signal-cli-"${L_SIGNAL_CLI}" /opt/fhem/signal-cli \
# && ln -sf /opt/fhem/signal-cli/bin/signal-cli /usr/local/bin/ \
&& ln -sf /opt/signal-cli-${L_SIGNAL_CLI}/bin/signal-cli /usr/local/bin/ \
&& apt-get purge -qqy \
build-essential \
cpanminus \
subversion \
&& apt-get autoremove -qqy && apt-get clean \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY ./src/pre-start.sh /pre-start.sh
#COPY ./src/000_fhem-nopasswd /etc/sudoers.d/
COPY ./src/org.asamk.Signal.service /usr/share/dbus-1/system-services/
COPY ./src/org.asamk.Signal.conf /etc/dbus-1/system.d/
ADD https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm /fhem/FHEM/32_SiSi.pm
RUN mkdir /run/dbus
#RUN mkdir /opt/fhem/signal-cli
RUN mkdir /opt/signal-cli
RUN chmod +x /pre-start.sh
VOLUME [ "/opt/signal-cli" ]
Moin BAfH,
bis du sicher dass der Dienst läuft? Was sagt dir sudo systemctl status signal.service
Gruss
Enno
Hallo Bafh,
startest du den service? Ich sehe jetzt das signal.service file nirgends. Zeigt der --config Parameter auf das richtige Verzeichnis und ist es les/schreibbar für den User?
Außerdem (aber das ist schon ein Schritt weiter) fehlt dir noch die libzkgroup.so für Raspberry. Die muss irgendwo in den library path z.B. /usr/lib und aus dem zkgroup....jar rausgelöscht sein (was mein Script bei erkannter Raspberry Installation automatisch macht)
Jörg
Zitat von: enno am 05 Februar 2021, 16:24:16
Moin BAfH,
bis du sicher dass der Dienst läuft? Was sagt dir sudo systemctl status signal.service
Gruss
Enno
Zeigt mir folgendes....
root@FHEM:/opt/fhem# sudo systemctl status signal.service
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
der DBUS wirdmit dem pre-start.sh Script gestartet
#!/bin/bash
export NUMBER="${NUMBER:-"undef"}"
export SLEEPTIME="${SLEEPTIME:-"10s"}"
if [ $NUMBER != "undef" ]; then
if [ -s /var/run/dbus/pid ]; then
rm /var/run/dbus/pid
fi
echo "Starting DBus System Daemon"
dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket
echo "Starting signal-cli"
/usr/local/bin/signal-cli -u $NUMBER --config /opt/fhem/signal-cli daemon --system &
echo "Wait $SLEEPTIME to give signal-cli time to come up"
sleep $SLEEPTIME
fi
starte ich den Befehl per Hand
root@FHEM:/opt/fhem# sudo systemctl status signal.service
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
root@FHEM:/opt/fhem# dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket
dbus-daemon[23194]: Failed to start message bus: The pid file "/run/dbus/pid" exists, if the message bus is not running, remove this file
EDIT
Frage ich den Dienst mit sudo service ab
oot@FHEM:/opt/fhem# sudo service dbus status
[ ok ] dbus is running.
Liegt wohl am DBUS. Mit der libzkgroup.so wollte ich anschließend klären....
Ja, aus dem Docker heraus, kann man das mit dem "service" wohl nicht machen, deshalb der Ansatz signal-cli einfach als Hintergrundprozess im -daemon --system zu starten - was anderes macht systemd am Ende auch nicht
Ich denke dein Augenmerk sollte auf den Parametern "-u" und "--config" liegen - stimmen die so? Und ist das Verzeichnis (und alles darin) aus dem Docker les/schreibbar? ist die richtige Config drin (Verzeichnis data, welches dann ein File mit der Nummer enthält)
Jörg
So, für alle Dockerfreunde folgende grobe Anleitung
-Verzeichnis fhem und fhem/core erstellen
-Fhem.tgz nach fhem/core auspacken
cd fhem
docker-compose.yml erstellen:
version: '2'
services:
fhem:
build: .
restart: always
stdin_open: true
tty: true
ports:
- "8083:8083"
- "7072:7072"
volumes:
- ./fhem/core/:/opt/fhem/
networks:
- fhem-network
#devices:
# - "/dev/ttyUSB0:/dev/ttyUSB0"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
networks:
fhem-network:
driver: bridge
Dockerfile erstellen:
ARG BASE_IMAGE="fhem/fhem"
ARG BASE_IMAGE_TAG="latest"
FROM ${BASE_IMAGE}:${BASE_IMAGE_TAG}
ARG L_SIGNAL_CLI="0.7.4"
# Install base environment
VOLUME [ "/opt/signal-cli" ]
#Docker Check ("exit" in Zeile 28 im script rausnehmen!
copy signal_install.sh in fhem/core
test.pl in fhem/core erstellen
#!/usr/bin/perl -w
use strict;
use warnings;
use Net::DBus;
my @attachment =();
my @recipients=("+491xxxx");
my $bus = Net::DBus->system();
my $service = $bus->get_service("org.asamk.Signal");
my $object = $service->get_object("/org/asamk/Signal");
my $retcode = $object->sendMessage("Testmessage from DBUS-Perl",\@attachment,\@recipients);
print "return timestamp:".$retcode."\n";
sudo docker-compose up -d
sudo docker exec -ti fhem-docker_fhem_1 /bin/bash
Im container: (als root) (# Zeilen weglassen, sind nur meine Notizen)
#make apt-get work at all by fetching the repository and upgrading it
apt-get update
apt-get upgrade
#get an editor
apt-get install vim
#Container check deaktivieren!
./signal_install.sh system
./signal_install.sh install
mkdir /run/dbus
dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket &
scp -r user@hostname:/var/lib/signal-cli /var/lib
# Oder an dieser Stelle: ./signal_install.sh register
cd /var/lib
chown -R signal-cli: signal-cli
sudo -u signal-cli /opt/signal/bin/signal-cli -u +49xxxxxx --config /var/lib/signal-cli daemon --system &
# Warten bis der Java Prozess läuft - das kann sehr lange dauern!!!
ps -ef | grep java
# Perl script von oben
perl test.pl
# Klappt oft erst beim zweiten mal
perl test.pl
Wie es dann mit FHEM weitergeht habe ich nicht probiert und auch nicht wie man das automatisiert.
Danke an BaFh für die Vorarbeit.
Gruß
Jörg
Hallo Jörg,
bei mir kommen das Reading "msgSender" nicht. Hier mal der Log5, nachdem ich ein 'P' an mein fhem Signalbot geschickt habe (und ein pong zurueckschicke), und das list vom Device.
Was mache ich falsch?
2021.02.05 23:28:35 5: Signal: Message from : P processed
2021.02.05 23:28:35 5: Signal: Read from Dbus done
2021.02.05 23:28:36 3: SignalBefore parse:@+4917212345678 pong:
2021.02.05 23:28:36 5: Signal: sendMessage called for +4917212345678::pong
2021.02.05 23:28:36 5: Signal: Signalbot_receive_callback 1234567890123 +4917212345678
2021.02.05 23:28:36 5: Signal: Read from Dbus done
2021.02.05 23:28:37 5: Signal: Signalbot_receive_callback 1234567890123 +4917212345678
2021.02.05 23:28:37 5: Signal: Read from Dbus done
2021.02.05 23:28:39 5: Signal: Signalbot_receive_callback 1234567890123 +4917212345678
2021.02.05 23:28:39 5: Signal: Read from Dbus done
Internals:
CFGFN
DEF
FD 29
FUUID abcdef-1234-1234-1234-1234ejgrynv
NAME Signal
NOTIFYDEV global
NR 3610
NTFY_ORDER 50-Signal
STATE Connected
TYPE Signalbot
READINGS:
2021-02-05 11:48:02 contactList +4917212345678=
2021-02-05 23:28:35 msgAttachment
2021-02-05 23:28:35 msgGroupName
2021-02-05 23:28:35 msgSender
2021-02-05 23:28:35 msgText P
2021-02-05 23:28:35 msgTimestamp 05-02-2021 23:28:34
2021-02-05 23:28:35 prevMsgAttachment
2021-02-05 23:28:35 prevMsgGroupName
2021-02-05 23:28:35 prevMsgSender
2021-02-05 23:28:35 prevMsgText Dies ist ein Test
2021-02-05 23:28:35 prevMsgTimestamp 05-02-2021 13:03:30
2021-02-05 23:28:36 sentMsg pong
2021-02-05 23:28:39 sentMsgRecipient
2021-02-05 23:28:39 sentMsgTimestamp 05-02-2021 23:28:36
helper:
msignal 4
rsignal 6
ssignal 5
timer 0
contacts:
+4917212345678
Attributes:
allowedPeer +4917212345678
defaultPeer +4917212345678
event-on-update-reading msgText
room Messages
verbose 5
webCmd reconnect
Hi Jamo,
ich glaube der msgSender kommt sehr wohl, wird aber in den Kontaktnamen übersetzt und ist schlicht und ergreifend leer.
Bist du sicher das der Sender einen Nickname hat?
Ich gebe allerdings zu, dass ein leerer Nickname die Übersetzung etwas "ad absurdum" führt.
Probiere daher mal diese Version, die bei leerem Namen wieder die Nummer nehmen sollte.
Jörg
Wichtiger Hinweis zum Thema Datenschutz!
In den Logfiles und "list" devices stehen überall eure Telefonnummern drin. Schaut euch dringend vorangegange Posts an und löscht die ggf. raus.
Besonders das "list" ist da noch tückischer, da es eure komplette Kontaktliste und daher die Nummern eurer Freunde und Bekannten beinhalten kann.
Daher ein "list" nur nach gewissenhafter Bearbeitung posten!
Jörg
ZitatHi Jamo,
ich glaube der msgSender kommt sehr wohl, wird aber in den Kontaktnamen übersetzt und ist schlicht und ergreifend leer.
Bist du sicher das der Sender einen Nickname hat?
Ich gebe allerdings zu, dass ein leerer Nickname die Übersetzung etwas "ad absurdum" führt.
Probiere daher mal diese Version, die bei leerem Namen wieder die Nummer nehmen sollte.
Jörg
Hallo Jörg,
diese Version, die bei leerem Namen wieder die Nummer nehmen sollte, funktioniert. DANKE!
Willst Du die neue Version in den ersten Post schieben?
Mit dem Nick: Nein, ich habe mein Adressbuch nicht geöffnet, aber in Signal Vornamen und Namen eingetragen. Wo finde ich denn den Nick in iOS, wo kann ich den eintragen?
Danke Jamo, aufgrund deiner Meldung habe ich wieder was gelernt, daher ist es jetzt auch ein größeres Update geworden:
Diese Nicknames sind keine Eigenschaft der Profils sondern jeder Client (in dem Fall signal-cli) hält seine eigenen private Liste. Ich hatte in meinem Profil wohl irgendwie einen Nickname für meine Handynummer und bin einfach davon ausgegangen das dies vom Profil kommt. Falsch gedacht. Das klappt nur bei gelinkten Accounts - da bekommt man die Kontakte die man auch auf dem Handy bereits hat.
Es gibt jetzt ein
set SignalBot setContact <Nummer> <Name>
Damit kann jeder sein internes Kontaktbuch pflegen.
Damit es einen FHEM Neustart überlebt noch ein
set saveContacts
Außerdem ist in dieser Version (erster Post) das Umlauthandling etwas verbessert. Ich hoffe mir sind keine Bugs reingerutscht.
Wie man an die Realnames kommt weiss ich nicht. Das Dbus Interface von signal-cli unterstützt aber einfach viele Funktionen (noch) nicht.
Gruß,
Jörg
Hi Jörg!
Tolle Sache, der SignalBot. Ich bin seit vielen Jahren TelegramBot-Nutzer, würde aber gern auf Signal umstellen.
Hast du vor, das Favorite-Handling von TelegramBot ebenfalls im SignalBot anzubieten?
Ein weiteres Killerfeature wäre aus meiner Sicht die Verknüpfung mit GoogleAuth, so dass man bei FHEM Befehlen ein TOTP Token mitsendet und das entsprechend geprüft wird. Das kann TelegramBot auch nicht native, es lässt sich aber über ein notify nachrüsten. Besser wäre natürlich eine direkte Integration, bei der man für bestimmte Befehle die zusätzliche Authentifizierung über TOTP verlangt.
Viele Grüße,
weini
Moin Jörg,
habe die neue Version eingebaut. Läuft ohne Fehlermeldung! Danke!
Gruss
Enno
Zitat von: weini am 06 Februar 2021, 12:50:36
Hast du vor, das Favorite-Handling von TelegramBot ebenfalls im SignalBot anzubieten?
Um Befehle automatisiert auszuführen habe ich die Verknüfung mit dem Babble Modul eingebaut. Der kann erstens mal sehr flexibel unterschiedliche Formulierungen erkennen und zweitens muss man dann das Rad nicht zweimal erfinden. Auf den ersten Blick hat der Telegrambot Entwickler da ganz schön Aufwand reingesteckt.
Ich lasse mich gerne davon überzeugen, was der Vorteil gegenüber Babble ist (oder potentiell auch "talk") ist.
Zitat
Ein weiteres Killerfeature wäre aus meiner Sicht die Verknüpfung mit GoogleAuth, so dass man bei FHEM Befehlen ein TOTP Token mitsendet und das entsprechend geprüft wird. Das kann TelegramBot auch nicht native, es lässt sich aber über ein notify nachrüsten. Besser wäre natürlich eine direkte Integration, bei der man für bestimmte Befehle die zusätzliche Authentifizierung über TOTP verlangt.
Kannst du mir dazu mehr Infos geben? Was ist der Anwendungsfall und wie schauen deine notifys aus die sowas simulieren?
Gruß,
Jörg
Habe mich heute mal an die Dokumentation gemacht und die Wiki Seite aktualisiert:
https://wiki.fhem.de/wiki/Signalbot
Wer selbst Zugriff hat, darf gerne mithelfen/korrigieren. Sonst auch Vorschläge auch hier im Threads.
Danke,
Jörg
Liebe Docker-Freunde,
Anbei jetzt ein Install Script, welches auch im Docker laufen sollte.
Das kann jetzt ein mit docker-compose neu erzeugter sein, wie im vorangegangenen Post beschrieben, sollte aber auch mit bestehenden FHEM containern funktionieren.
Einfach interaktiv als root laufen lassen. Sofern bereits eine Registry besteht, für alle Fälle je mit den Argumenten install, system und test ausführen.
Danach laufen im Hintergrund sowohl der dbus-daemon als auch der signal-cli daemon.
Logfiles und Fehler landen in /var/log/dbus.log bzw. dbus.err und signal.log/signal.err
@Thorben: In deiner letzten Nachricht war eine Fehlermeldung drin. Die sollte jetzt durch ein geändertes Config File verschwinden. Wegen deinem zkgroup Fehler, bitte nochmal das /opt/signal-cli Verzeichnis löschen damit eine Neuinstallation erfolgt. Da ging bei dir ja mal wegen fehlendem "zip" Tool schief - vielleicht ist der Wurm immer noch drin.
Das Script hat jetzt auch den Perl Test eingebaut - sendet also jetzt auf 3 Arten (auch ohne Docker) - wenn die alle passen, dann sollte FHEM auch gehen.
Falls der fertig installierte Container neu gestartet wird, dann einfach
./signal_install.sh start
aufrufen. Damit werden die beiden Daemons bei Bedarf (und nur dann) nachgestartet.
Bitte mal durchtesten (wenn jemand kann/mag auch die normale Installation), damit ich es sicher in den ersten Post verschieben kann.
Gruß,
Jörg
Zitat von: Adimarantis am 06 Februar 2021, 19:28:45
Bitte mal durchtesten (wenn jemand kann/mag auch die normale Installation), damit ich es sicher in den ersten Post verschieben kann.
Moin Jörg,
ich bekomme folgende Meldung:
signal_install.sh: 372: Syntax error: "(" unexpected (expecting "fi")Gruss
Enno
Hallo Jörg,
wegen den umlauten:
Wenn ich aus fhem die folgende Message an mein iPhone schicke, bekomme ich im reading "sentMsg" folgendes, obwohl in Signal selber (also auf dem iPhone) die Umlaute alle OK sind:
set Signal send ae=ä, ue=ü, oe=ö, sz=ß
sentMsg ae=�, ue=�, oe=�, sz=�
Zitat von: enno am 06 Februar 2021, 20:11:01
ich bekomme folgende Meldung:
signal_install.sh: 372: Syntax error: "(" unexpected (expecting "fi")
Probiers mal jetzt.
Jörg
Zitat von: Jamo am 06 Februar 2021, 20:23:34
sentMsg ae=�, ue=�, oe=�, sz=�
Alles klar. Hab ich gefixed, ist dann beim nächsten Update dabei.
Jörg
Zitat von: Adimarantis am 06 Februar 2021, 22:01:27
Probiers mal jetzt.
signal_install.sh: 375: Syntax error: "(" unexpected (expecting "fi")... so muss Schneeschaufelngehen am Tag 1 der Schneekatastrophe in Niedersachsen 8) Wenn ich mich nicht mehr melde, bin ich in einer Schneewehe versackt... oder Signal läuft nicht mehr...
Gruss
Enno
Zitat von: enno am 07 Februar 2021, 09:27:34
... so muss Schneeschaufelngehen am Tag 1 der Schneekatastrophe in Niedersachsen
Hier (auch in Niedersachsen) ist es -4°C, windig, aber von Niederschlag seit Freitag, 17 Uhr, weit und breit keine Spur.
Wenn ich diesen Pull-Request richtig verstehe, wäre es möglich (demnächst, oder jetzt?) via tcp-sockets mit dem cli-service mithilfe von json-strings zu kommunizieren.
https://github.com/AsamK/signal-cli/pull/419/commits (https://github.com/AsamK/signal-cli/pull/419/commits)
Das hätte dann auch den Charme, dass man den signal-cli Teil extern, oder auch in einem separaten Container laufen lassen kann.
Denn ich möchte eigentlich mein FHEM im "geschützten" Docker belassen und nicht den Host-Modus verwenden.
Wäre das eine interessante Variante?
oder gibt es das schon?
Habe noch das dazu gefunden:
https://github.com/Matteljay/signal-cli/wiki/Socket-IPC (https://github.com/Matteljay/signal-cli/wiki/Socket-IPC)
Die Socket Variante scheint ein fork zu sein der aktuell als Pull request ansteht.
Im aktuellen main (den habe ich mir testweise schon mal übersetzt, daher weiss ich auch das ab der nächsten Version zwei native libraries benötigt werden) ist anscheinend noch nichts drin.
Wir sollten das auf jeden Fall beobachten. Der Socket Branch unterstützt ein "getContacts", dass mir beim Dbus fehlt - dafür fehlen wieder ein paar andere Services. Da braucht denke ich noch etwas Reife und sollte erst voll im main etabliert sein, bevor wir da was machen.
Wegen signal-cli im extra Container war ich schon am überlegen, ob es da Optionen gibt. Letztendlich muss man aus dem Container irgendwie eine Verbindung mit dem streaming socket /var/run/dbus/system_bus_socket aufbauen. Dann darf aber wahrscheinlich auch der dbus-daemon nicht im Container laufen. Das müsste sich jemand mit deutlich mehr Linux System und Container Know How ansehen, als ich mitbringe.
Netstat:
unix 2 [ ACC ] STREAM HÖRT 12185 - /var/run/dbus/system_bus_socket
Ich finde ja die signal-cli Installation etwas tricky aber eigentlich nicht sehr invasiv. Die lässt sich sowohl native als auch im Container sehr einfach wieder entfernen, sofern einen die abhängigen Pakete nicht stören, aber das sind ja auch offizielle Installer (apt, cpan) - sollte man auch wegbekommen.
Jörg
Hi Enno,
kann es sein, das du das Script unter "sh" statt "bash" laufen hast?
Den Fehler kriege ich nur wenn ich das Konstrukt unter "sh" laufen lasse.
Wahrscheinlich sollte ich noch eine "bash" Abhängigkeit einbauen und beenden, wenn das Script nicht in der bash läuft.
EDIT: Einfacher check auf bash inkl. Nachinstallation eingebaut.
Jörg
Zitat von: Adimarantis am 07 Februar 2021, 11:01:32
kann es sein, das du das Script unter "sh" statt "bash" laufen hast?
Richtig vermutet! Bisher ging es immer mit sh. Ok, ich teste noch mal als bash.... und geht.
Gruss vom DAU ::)
Hallo zusammen. Ich habe hier die Installation mit dem Skript auch mal durchgezogen, ganz normal auf einem Pi. Senden und Empfangen mit normalen Usern funktioniert auch gut.
Probleme gibt es aber noch mit Gruppen. Ich hab mal eine Gruppe FHEM eingerichtet, da kann ich auch normale User hinzufügen. Bei meinem fhem User hat Singal zuerst gemeckert, wegen angeblich nicht aktueller Version V2 bei signal-cli. Nach Löschung und nochmaliger Neueinrichtung auf dem Pi mit dem neuesten Version von hier meckert Signal nicht mehr und schickt eine Einladung raus wenn ich meinen fhem User zu der Gruppe hizufügen will, im SignalBot sehe ich dann auch "joinedGroups FHEM".
Wenn ich aber eine Nachricht an die Gruppe senden will kommt:
Error sending message:org.asamk.Signal.Error.GroupNotFound: User is not a member in group: FHEM (...)
im Logfile
2021.02.07 12:23:47 3: SignalBot: Before parse:#FHEM Teststring:
2021.02.07 12:23:47 5: SignalBot: sendGroupMessage called for FHEM::Teststring
Also hab ich mal versucht unter signal-cli die Einladung anzunehmen:
sudo -u fhem signal-cli updateGroup -n FHEM
Soll jedenfalls laut Doku so gehen.
Dort kommt dann:
OpenJDK Server VM warning: You have loaded library /tmp/resource17792002454964883349.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
ERROR App - User +49xxxxxxxxxx is not registered.
Die Telefonummer funbktioniert ja, daher wundert mich die letzte Meldung. Und die lbzkgroup Dateien liegen in /usr/lib
Irgendwie fällt mir gerade da nichts mehr ein.
Zitat von: Adimarantis am 07 Februar 2021, 10:56:27
Die Socket Variante scheint ein fork zu sein der aktuell als Pull request ansteht.
Im aktuellen main (den habe ich mir testweise schon mal übersetzt, daher weiss ich auch das ab der nächsten Version zwei native libraries benötigt werden) ist anscheinend noch nichts drin.
Wir sollten das auf jeden Fall beobachten. Der Socket Branch unterstützt ein "getContacts", dass mir beim Dbus fehlt - dafür fehlen wieder ein paar andere Services. Da braucht denke ich noch etwas Reife und sollte erst voll im main etabliert sein, bevor wir da was machen.
Wegen signal-cli im extra Container war ich schon am überlegen, ob es da Optionen gibt. Letztendlich muss man aus dem Container irgendwie eine Verbindung mit dem streaming socket /var/run/dbus/system_bus_socket aufbauen. Dann darf aber wahrscheinlich auch der dbus-daemon nicht im Container laufen. Das müsste sich jemand mit deutlich mehr Linux System und Container Know How ansehen, als ich mitbringe.
Netstat:
unix 2 [ ACC ] STREAM HÖRT 12185 - /var/run/dbus/system_bus_socket
Ich finde ja die signal-cli Installation etwas tricky aber eigentlich nicht sehr invasiv. Die lässt sich sowohl native als auch im Container sehr einfach wieder entfernen, sofern einen die abhängigen Pakete nicht stören, aber das sind ja auch offizielle Installer (apt, cpan) - sollte man auch wegbekommen.
Jörg
Hier hat auch schon jemand eine REST API für den signal-cli gebaut und es gibt einen "fertigen" Docker Container dazu.
https://github.com/bbernhard/signal-cli-rest-api (https://github.com/bbernhard/signal-cli-rest-api)
Das wäre natürlich jetzt ein völlig anderer Ansatz bei der Kommunikation zwischen signal-cli und FHEM.
Zitat von: sinus61 am 07 Februar 2021, 12:30:26
Die Telefonummer funbktioniert ja, daher wundert mich die letzte Meldung. Und die lbzkgroup Dateien liegen in /usr/lib
Schau mal ob
unzip -v /opt/signal/lib/zkgroup-java-0.7.0.jar
Noch eine "libzkgroup.so" enthält. Die muss raus damit die /usr/lib version verwendet wird. Das hätte das script eigentlich mit
zip -d zkgroup-java-0.7.0.jar libzkgroup.somachen sollen.
Wenn die noch drin ist - hast du noch logs von der Installation? Würde mich interessieren was da nicht geklappt hat.
Jörg
Zitat von: Papaloewe am 07 Februar 2021, 12:32:10
Hier hat auch schon jemand eine REST API für den signal-cli gebaut und es gibt einen "fertigen" Docker Container dazu.
https://github.com/bbernhard/signal-cli-rest-api (https://github.com/bbernhard/signal-cli-rest-api)
Das wäre natürlich jetzt ein völlig anderer Ansatz bei der Kommunikation zwischen signal-cli und FHEM.
Von dem Docker Container könnte man sicher was für unsere Installation hier was abgucken. Kommt mir jetzt aber nochmal eine Stufe komplexer vor, da man mit der REST API nochmal etwas dazwischenbaut. Also seid mir nicht böse, aber ich finde wir haben einen praktikablen und stabilen Weg und ich werde da jetzt keine Energie in Alternativen stecken.
Wie zuvor beschrieben höchstens wenn der signal-cli main branch was interessantes einführt.
Gruß,
Jörg
Hallo Jörg,
dickes Dankeschön für Deine tolle Arbeit und die Geduld. Es läuft.
Ich kann jetzt sauber Nachrichten senden und empfangen.
Top, habe gerade getestet, Nachrichten von FHEM an mein Phone zu senden abhängig vom Device State. Passt.
Bin gerade dabei, ein Notify zu erstellen um auf ankommende Nachrichten zu reagieren.
Nutze diesen Post https://forum.fhem.de/index.php/topic,84996.msg906042.html#msg906042 (https://forum.fhem.de/index.php/topic,84996.msg906042.html#msg906042)
Da habe ich noch etwas zu tun.
Jut, gerade kommt wohl der Schnee hier bei uns in Brandenburg an, naja Schnee ist es nicht.... ;)
Also ich bin am Zuge.
Bis später
Zitat von: Adimarantis am 07 Februar 2021, 12:37:48
Noch eine "libzkgroup.so" enthält. Die muss raus damit die /usr/lib version verwendet wird.
Die ist raus. Allerdings hatte ich die libs manuell kopiert, weil die nicht da waren. Hab gerade mal die remove Option genutzt und neu installiert, da fiel mir das wieder ein. Im Skript hast Du am Anfang $LIBPATH definiert, beim Installieren und Entfernen dann aber $LIBDIR benutzt. Hab das mal angepasst, dann läuft alles durch.
Allerdings nützt es nichts, es kommt weiter der Fehler:
OpenJDK Server VM warning: You have loaded library /tmp/resource17792002454964883349.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
ERROR App - User +49xxxxxxxxxx is not registered.
Mit der User funktioniert das wie gesagt trotzdem, nur mit einer Gruppe geht es nicht, der User lässt sich da nicht mit reinnehmen.
Zitat von: sinus61 am 07 Februar 2021, 14:12:55
Im Skript hast Du am Anfang $LIBPATH definiert, beim Installieren und Entfernen dann aber $LIBDIR benutzt.
Tatsächlich. Ich hätte zuletzt hauptsächlich unter meiner X86 VM gestestet....
Korrigiert.
Die Signal Gruppen funktionieren leider ohne die library nicht.
Lass uns mal schauen ob er die Library anzieht:
sudo ldconfig -v | grep libzkgroup.so
Eigentlich muss /usr/lib da drin sein, vielleicht stimmen aber die Rechte nicht?
Ansonsten fällt mir nur noch ein ob du irgendwo anders im System noch ein zkgroup.jar hast, das er anzieht, wo die .so noch drin ist?
EDIT: Und du bist schon auf einem Raspberry unter armv71 oder?
Jörg
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
libzkgroup.so -> libzkgroup.so
und ja
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 4
Laut Doku sucht libsignal in java.library.path wenn die lib nicht im jar Paket ist. Wo könnte man denn erkennen was da angegeben ist?
Ok, /usr/lib/ ist da mit drin wenn man "java -XshowSettings:properties" aufruft.
Hi sinus61,
Also laut deiner Fehlermeldung findet er eine lib.so - aber eben die falsche. Ich hab meine mal testweise gelöscht, dann kommt eine andere Fehlermeldung.
1. Check: Haben wir die selbe Library:
ls -l /usr/lib/libzkgroup.so
-rw-r--r-- 1 root root 681524 Feb 2 17:24 /usr/lib/libzkgroup.so
2. Check: Schaut das jar consistent wie meins aus:
ls -l /opt/signal/lib/zkgroup-java-0.7.0.jar
-rw-r--r-- 1 signal-cli signal-cli 34682 Feb 7 15:24 /opt/signal/lib/zkgroup-java-0.7.0.jar
3. Check welches .jar nimmt er (Voraussetzung Service läuft)
ps -ef | grep zkgroup
Da müsste irgendwo der volle Pfad opt/signal/lib/zkgroup-java-0.7.0.jar drinstehen
4. Check gibt es irgendwo noch eine andere .so
sudo find / -name libzkgroup.so 2>/dev/null
5. Check gibt es noch irgendwo ein anderes jar
sudo find / -name zkgroup-java-0.7.0.jar 2>/dev/null
Und dann bin ich mit meinem Latein wirklich am Ende...
Jörg
Hallo,
na dem shutdown restart hängt mein FHEM.
Folgende Meldung im Log
2021.02.07 16:47:57.676 3: Mosquitto device opened
Operation "ne": no method found,
left argument in overloaded package Net::DBus::Error,
right argument has no overloaded magic at ./FHEM/50_Signalbot.pm line 385.
Das ist der letzte Stand des 50_Signalbot.pm.
Wenn ich das Docker Image lösche und neu erstelle, ist die Registrierung auch weg???
Ich schaue mal
dann nichts mehr... Was könnte hier helfen?
Hi Thorben,
Wahrscheinlich ist dein Dbus und/oder signal-cli daemon nicht oben.
Leider ist da wohl noch ein Bug in meinem Fehlerhandling - dazu kannst du mal di angehängte Version probieren. Die sollte zumindest einen Fehler ausspucken statt FHEM zu blockieren.
Wenn du das neuste Installscript als root mit dem Parameter "start" aufrufst, dann werden die beiden Dienste gestartet, wenn nötig.
Jörg
Also ich habs immer noch nicht hin bekommen.
Zitat
dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:"Test message via DBus" array:: string:+49xxxxxxxxx
funktioniert
vom FHEM aus
Zitatset SIGNAL send @+4917xxxxxxxx Hallo Signal
Error sending message:org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
geht irgendwie nicht. FHEM und Rechner mehrfach neu gestartet, hilft aber nix 🤷🏻♂️
gibts Ideen was ich Debugger kann? FHEM-Log gibt nichts her.
Zitat von: Adimarantis am 07 Februar 2021, 15:32:29
Also laut deiner Fehlermeldung findet er eine lib.so - aber eben die falsche.
Danke für die Unterstützung, jetzt hab ich es. Ich hatte ja schon vorab mal mit SiSi angefangen und da gab es /opt/fhem/signal-cli. Gelöscht und der Fehler ist weg.
Der Fehler mit "is not registered" bestand noch weiter, das hab ich mit dem Skript auch mit remove und install und register nicht gelöst bekommen, sondern einmal direkt it signal-cli gemacht. Damit läuft das auch. Braucht vielleicht nicht weiter erforscht werden, wenn sonst keiner das Problem hat.
Mit den Gruppen läuft es trotzdem noch nicht ganz rund, muss ich noch mal austesten.
Hallo Jörg,
habe den Container neu erstellt.
Befehl ausgeführtsudo -u signal-cli /opt/signal/bin/signal-cli -u +49festnetz --config /var/lib/signal-cli daemon --system &
folgende Rückmeldung
root@FHEM:/opt/fhem#
[1] 24857
root@FHEM:/opt/fhem# /opt/signal/bin/signal-cli: 41: cd: can't cd to /opt/fhem
OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource7942281494445111559.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
ERROR App - Error while checking account +49festnetz: Authorization failed!
[1]+ Exit 2 sudo -u signal-cli /opt/signal/bin/signal-cli -u +4festnetz --config /var/lib/signal-cli daemon --system
root@FHEM:/opt/fhem#
Dein Test Script gibt folgenden Fehlerorg.freedesktop.DBus.Error.Spawn.FileInvalid: Cannot do system-bus activation with no user
Gepüft ist das der User signal-cli Zugriff hat:
drwxr-xr-x 3 signal-cli signal-cli 4096 Feb 7 17:53 signal-cli
/usr/share/dbus-1/system-services/org.asamk.Signal.service
/etc/dbus-1/system.d/org.asamk.Signal.conf
Reinit bringt
2021.02.07 18:24:58.407 3: Signal: Error while initializing Dbus:org.freedesktop.DBus.Error.Disconnected: Connection is closed
Zitat von: frust am 07 Februar 2021, 17:45:29
gibts Ideen was ich Debugger kann? FHEM-Log gibt nichts her.
Im neusten Install Script wird mit dem Argument "test" noch auf eine dritte Methode (aus Perl) gesendet. Geht das?
Die Frage ist auch von wann deine Scripten/Module sind. ggf. nochmal das Neuste aus dem ersten Post holen und laufen lassen.
Jörg
Zitat von: BAfH am 07 Februar 2021, 18:40:38
Dein Test Script gibt folgenden Fehlerorg.freedesktop.DBus.Error.Spawn.FileInvalid: Cannot do system-bus activation with no user
Das ist eigentlich mit dem aktuellen Installer gefixed und die Datei org.asamk.Signal.service
hat jetzt eine zusätzliche Zeile mit "User=signal-cli"
Mit der Zeile müsste der Service starten.
das "can't cd" hatte ich auch, das macht nichts.
Am Besten halt die Services mit
./signal_install.sh startstarten.
Du hast außerdem anscheinend auch wieder die falsche lib.so
Schmeiss doch das /opt/signal nochmal weg und lass es vom Script neu bauen (argument: install) - aber bitte nochmal den Neusten holen.
Jörg
Guten Abend,
eine kurze Frage, wird ein Zeilenumbruch auch mit \n gemacht, wie bei anderen Modulen?👀 Achja die installtion hat super geklappt, es hat nur noch das modul libimage-librsvg-perl für SVG_plots gefehlt.
Mfg
Zitat von: mspa am 07 Februar 2021, 20:40:59
eine kurze Frage, wird ein Zeilenumbruch auch mit \n gemacht, wie bei anderen Modulen?
Aktuell geht das nur aus Perl (also z.B. im DOIF):
{fhem("set SignalBot send \@Joerg Zeile 1".chr(10)."Zeile2");}Habs aber schon ausprobiert. Eine Erweiterung die "\n" in ein echtes Newline übersetzt ist einfach. Kommt dann ins nächste update.
Man muss dann allerdings "\\n" machen um das "\" zu escapen.
Zitat
Achja die installtion hat super geklappt, es hat nur noch das modul libimage-librsvg-perl für SVG_plots gefehlt.
Danke. Nehme ich mit in den Installer auf.
Jörg
In Perl geht das mit \n aber auch so:
$txt = " $eventDesc\n $onset\n $expires\n $description\n";
fhem ("set SignalBot send $txt");
Stimmt. Geht sogar direkt. Zu kompliziert gedacht.
{fhem("set SignalBot send \@Joerg Zeile 1\nZeile2");}
Nur in FHEM klappt das durch das pre-processing für eingebaute Readings ala [device:reading] irgendwie nicht.
Das muss ich mir noch in Ruhe anschauen.
Vielleicht kann man das "\\n" auch irgendwie umgehen, damit es via Perl und FHEM gleich funktioniert indem ich das bereits vorher in Chr(10) konvertiere.
Jörg
Morgen,
so ich war wieder aktiv.
Ich habe genau nach Anleitung, den Dockercontainer neu erstellt.
hier eine kurze Aufstellung.
1. Alten Container gelöscht
docker rm -f fhem-docker_fhem_1
docker rmi -f fhem-docker_fhem
2. Neuen Container erstellen
Dockerfile
ARG BASE_IMAGE="fhem/fhem"
ARG BASE_IMAGE_TAG="latest"
FROM ${BASE_IMAGE}:${BASE_IMAGE_TAG}
ARG L_SIGNAL_CLI="0.7.4"
# Install base environment
VOLUME [ "/opt/signal-cli" ]
Kommando
docker-compose up -d
3. FHEM startet
4. Kommando apt-get update
5. Editor apt-get install nano
6. Kommando ./signal_install.sh system
hier kommen teilweise Fehler
npacking unzip (6.0-23+deb10u2) over (6.0-23+deb10u1) ...
Errors were encountered while processing:
/tmp/apt-dpkg-install-33B4nC/00-tzdata_2021a-0+deb10u1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
done
Checking for haveged...installing (haveged)E: Sub-process /usr/bin/dpkg returned an error code (1)
Extracting templates from packages: 100%jre)
E: Sub-process /usr/bin/dpkg returned an error code (1)
done
Checking for qrencode...installing (qrencode)E: Sub-process /usr/bin/dpkg returned an error code (1)
done
Checking for zip...installing (zip)E: Sub-process /usr/bin/dpkg returned an error code (1)
done
Checking for Net::DBus...Can't locate Net/DBus.pm in @INC (you may need to install the Net::DBus module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at /tmp/signal16413.tmp line 5.
BEGIN failed--compilation aborted at /tmp/signal16413.tmp line 5.
Installing latest NET::DBus...done
Checking user signal-cli ...Adding user `signal-cli' ...
Adding new group `signal-cli' (1001) ...
Adding new user `signal-cli' (1001) with group `signal-cli' ...
Creating home directory `/home/signal-cli' ...
Copying files from `/etc/skel' ...
created
7. Kommando ./signal_install.sh install
Ausgabe
Checking for /opt...found
Checking for /var/lib/signal-cli...created
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.7.4...done
Unpacking ...
Removing native x86 since you're on Raspberry...deleting: libzkgroup.so
done
Downloading native armv7l libraries...
done
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf.../etc/dbus-1/system.d/org.asamk.Signal.conf installed
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service.../usr/share/dbus-1/system-services/org.asamk.Signal.service installed
10. Kommando dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket &
11. Kommando scp -r pi@192.168.10.50:/var/lib/signal-cli /var/lib
12. Kommando chown -R signal-cli: signal-cli
13. Kommando sudo -u signal-cli /opt/signal/bin/signal-cli -u +49festnetz --config /var/lib/signal-cli daemon --system &
Ausgabe [1] 8649
nach einer gewissen Zeit kommt
root@FHEM:/var/lib# ERROR App - Error while checking account +49festnetz: Authorization failed!
14. Kommando ps -ef | grep java Keine Ausgabe nur der Prozess selbst
15. Testscript perl signal_test.pl
Ausgabe org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
Frage ich die Prozess dbus ab root@FHEM:/opt/fhem# ps -ef | grep dbus
message+ 8148 1 0 09:42 ? 00:00:00 dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket
message+ 31542 8148 0 10:05 ? 00:00:00 dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket
root 31543 31542 0 10:05 ? 00:00:00 /usr/lib/dbus-1.0/dbus-daemon-launch-helper org.freedesktop.systemd1
root 31577 9615 0 10:05 pts/1 00:00:00 grep dbus
Könnte es am Fehler während der Installation
Sub-process /usr/bin/dpkg returned an error code (1)
liegen.
Meine Umgebung
Linux FHEM 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Kernel
5.4.72-v7l+
Ich teste mal weiter....
Hi Thorben,
Um das von a-z zu testen, wollte ich mr jetzt noch ein vollautomatisertes Script für eine FHEM/signa-cli Docker Umgebung bauen. Sollte eigentlich nicht so wild sein, braucht aber noch Zeit (zum Bauen, aber auch um noch ein paar Dinge über Docker zu lernen).
Wenn du es also nicht zu eilig hat, warte mal auf das :) In der Arbeit geht's gerade auch ein bisschen rund.
Jörg
Hi Jörg,
kein Problem, ich taste mich auch gerade mal ran. Teste weiter, verschiedene Docker den es lief ja mal.
Ich bin auch gerade aktiv im Job.. Wir sind jung und brauchen das Geld.
Also pass auf Dich auf.
Thorben
Ich hab gerade mal über das Thema Favoriten nachgedacht, die ich in Telegram genutzt habe. Babble ist mir für diesen Zweck zu umständlich.
Ich hab mir für den Zweck ein Notify angelegt. Ein "/" schickt einen Text mit den Favoriten zurück, mit "/1" usw. wird dann der jeweilige Favorit ausgeführt.
Vielleicht kann es ja jemand als Anregung gebrauchen.
SignalBot:msgText:./.* {
my $favs = "/1 = Verkehr\n/2 = Warnungen\n/3 = Aussentemperatur\n/4 = Kamera";
if ($EVTPART1 eq "/") {
fhem('set $NAME send "@[$NAME:msgSender]" '.$favs);
}
elsif ($EVTPART1 eq "/1") {
fhem('set $NAME send "@[$NAME:msgSender]" '.Verkehrsinfo_GetData('A27'));
}
elsif ($EVTPART1 eq "/2") {
DWD_Alert("DWD_Wetter");
}
elsif ($EVTPART1 eq "/3") {
fhem('set $NAME send "@[$NAME:msgSender]" Aussentemperatur: [au_Wetterstation:temperature]');
}
elsif ($EVTPART1 eq "/4") {
fhem("get Cam1 image");
fhem("sleep 1;set $NAME send '@[$NAME:msgSender]' &/opt/fhem/www/snapshots/Cam1_snapshot.jpg");
}
}
Zitat von: Adimarantis am 06 Februar 2021, 14:43:45
Um Befehle automatisiert auszuführen habe ich die Verknüfung mit dem Babble Modul eingebaut. Der kann erstens mal sehr flexibel unterschiedliche Formulierungen erkennen und zweitens muss man dann das Rad nicht zweimal erfinden. Auf den ersten Blick hat der Telegrambot Entwickler da ganz schön Aufwand reingesteckt.
Ich lasse mich gerne davon überzeugen, was der Vorteil gegenüber Babble ist (oder potentiell auch "talk") ist.
Kannst du mir dazu mehr Infos geben? Was ist der Anwendungsfall und wie schauen deine notifys aus die sowas simulieren?
Sorry für die späte Antwort, ich hatte keine Benachrichtiungen mehr bekommen.
Favoriten:
Ich finde es sehr komfortabel, für mich wichtige Funktionen schnell mit einem Kürzel zu erreichen. Bei Babble werden die Eingaben ja eher länger. Kurz ein fav3 und ich habe die aktuellen Temperaturen oder ein fav5 und ich bekomme ein Foto der Wifi-Cam zugesandt. Über die Fav-Menü Funktion vom TelegramBot wird das ganze dann noch komfortabler. Ich weiß nur nicht, ob man so etwas mit Signal überhaupt machen kann.
Notify:
Den TelegramBot habe ich so konfiguriert, dass er nur Befehle via "trigger" ausführt. Normale "set" sind erst mal verboten. Einen "set" Befehl erkennt aber das notify. Das prüft dann zusätzlich, ob eine Zahl mit übergeben wurde und validiert die via GoogleAuth.
Das notify sieht so aus (steht irgendwo auch im über 100 Seite langen TelegramBot Thread):
defmod ntf_telegramBot notify telegramBot:msgText.* {\
my $msgpeer = ReadingsVal("telegramBot", "msgPeerId", "");;\
my @evtparts = split(" ",$EVENT);;\
\
# Reading-Namen entfernen\
shift @evtparts;;\
# das Token steht vor dem Befehl\
my $GivenToken = shift @evtparts;;\
my $FhemCmd = join " ", @evtparts;;\
my $cmdKeyword = AttrVal("telegramBot", "cmdKeyword", undef);;\
my $cmdFavorites = AttrVal("telegramBot", "cmdFavorites", undef);;\
my @favarray;;\
my $favno;;\
\
# nur verarbeiten, wenn das Token nur aus Zahlen besteht -> sonst ist es verm. ein reguläres Kommando für das Bot-Modul\
if ($GivenToken =~ /^\d+$/) {\
Log3("ntf_telegramBot",4,"ntf_telegramBot: EVENT: $EVENT");;\
Log3("ntf_telegramBot",3,"ntf_telegramBot: FhemCmd: $FhemCmd");;\
\
# prüfe ob die Zeichenfolge von eben einen gültigen Token ergibt\
my $GAuthResult = gAuth("googleAuth",$GivenToken);;\
Log3("ntf_telegramBot",3,"ntf_telegramBot: googleAuth Token: $GivenToken result: $GAuthResult");;\
\
# ggf. Favoriten auflösen\
if (substr($FhemCmd, 0, length($cmdFavorites)) eq $cmdFavorites) {\
$favno = int(substr($FhemCmd, length($cmdFavorites)));;\
@favarray = split(";;",AttrVal("telegramBot", "favorites", ""));;\
$FhemCmd = $favarray[$favno-1];;\
# wenn ein Alias definiert ist, dann den Befehlsteil aus dem Favoriten extrahieren\
if (index($FhemCmd, "=") >= 0) {\
$FhemCmd = substr($FhemCmd, index($FhemCmd, "=")+1);;\
}\
Log3("ntf_telegramBot",3,"ntf_telegramBot: FhemCmd after favorite substitution: $FhemCmd");;\
}\
\
#Prüfung, dass der aktuelle peer in der Liste der cmdRestrictPeer ist. Achtung: es wird auf die PeerId geprüft, username funktioniert nicht\
if ( index(AttrVal("telegramBot", "cmdRestrictedPeer", $msgpeer), $msgpeer) >= 0 and $GAuthResult eq '1') {\
Log3("ntf_telegramBot",4,"ntf_telegramBot: execute cmd");;\
fhem($FhemCmd);;\
}\
}\
}
Zitat von: weini am 08 Februar 2021, 23:06:09Bei Babble werden die Eingaben ja eher länger.
Moin,
das ist richtig, aber, ich kann meine zweiten Hälfte nicht davon überzeugen, sich Kürzel zu merken. Daher nutze ich auf dem Handy die Möglichkeit, den Text zu sprechen, umzuwandeln und dann zu schicken. "Mach das Radio an", "Schalt das Radio ein" oder "Schalt das Radio bitte an". Die Ansage muss halbwegs passen und Signal und Babble machen dann den Rest.
Gruss
Enno
Das diese Favorites mit einem Notify einfach zu realisieren sind, hat ja sinus61 oben gezeigt. Ich würde das ja eher mit einem DOIF machen, aber das ist Geschmackssache. Daher bin ich nach wie vor nicht davon überzeugt das Rad nochmal zu erfinden.
Was allerdings sinnvoll sein könnte wäre ein "babbleExclude" Parameter. Wenn dieses Zeichen (oder Zeichenkette) am Anfang der Nachricht steht, dann wird Babble nicht aufgeufen. So könnte man z.B. das "/" oder "fav" etc. ausnehmen und per Notify behandeln, alles andere geht immer noch an die Sprachanalyse.
Was meint ihr?
So einen Marker brauche ich auch in umgekehrte Richtung für die Rive Dateien um ggf. die Umlaute anders zu kodieren. Der Babble Autor hat in seinen Rivescript Dateien eine spezielle Kodierung verwendet und kodiert das in Babble um. Ich habe aber jetzt die Beispiele von TALKTOME ausprobiert, die "normale" Umlaute enthalten, und dann kommt nach Babble Müll raus. Mit einer speziellen Markierung im "send" der "helpFunc" erkenne ich das aktuell und korrigiere das wieder (generell darf man das aber nicht machen).
Alternativ könnte ich mir noch ein "sendutf8" vorstellen, das dürfte aber die meisten eher verwirren. Da wäre ein versteckter Marker meiner Ansicht nach besser.
Jörg
Wegen Docker, habt ihr mal mit Julian gesprochen?
Sein Docker-Container (https://github.com/fhem/fhem-docker) bietet doch schon einiges an Anpassungsmöglichkeiten.
Eventuell könnte man die Installation für signal-cli nach /post-init.sh, /docker/post-init.sh auslagern und mit Julian besprechen, dass man nur sowas wie
-e install_signal_bot=true
setzen muss und dann automatisch der entsprechende Installationsprozess ausgeführt wird?
Dabei habe ich vor allem die User im Hinterkopf, die zwar einen normalen Docker-Container hochfahren, aber selber nichts mit composer usw. anlegen können.
Zitat von: kjmEjfu am 09 Februar 2021, 09:54:21
Sein Docker-Container (https://github.com/fhem/fhem-docker) bietet doch schon einiges an Anpassungsmöglichkeiten.
Ich bastele gerade an einem Script das "from scratch" einen FHEM/signal-cli Container per script (natürlich auch mit docker-compose uns so) anlegt.
Ist jetzt mehr ein Lernprojekt für mich, da ich viele Prinzipien von Docker noch nicht ganz verstehe. Vom dem Projekt oben gucke ich da bereits ein wenig ab. Meins basiert jetzt auf dem standard "ubuntu/latest" und ist dadurch sehr schlank (250 MB vs. 1.6 GB von fhem docker, der einen haufen Zeug reinpackt, dass nicht jeder braucht).
Eine Problematik hier ist die Erstellung der Registry. Kann man irgendwie ein interaktives Script per "RUN" im Dockerfile ausführen?
Dadurch müsste man die Registrierung erstmal außerhalb vom Container machen und im Rahmen des compose Prozesses reinkopieren (geht natürlich, stellt aber schon wieder eine Hürde dar)
Aktuell kämpfe ich noch ein wenig mit der Persistenz. Wie stellt man sicher das mit "apt-get install" installierte Pakete erhalten bleiben. Nahezu das ganze Filesystem als "volume" zu definieren kommt mir nicht zielführend vor. Naja.. wie gesagt, Lernprojekt.
Jörg
Schön, dass es eine Lösung für dei Favoriten gibt.
Mittelfristig würde ich es schön finden, wenn das Modul selbst Favoriten unterstützen würde. Die notify Konstruktion erhöht nicht eben die Wartbarkeit.
Aber bzgl. Priorisierung bin ich fein, das ist am Anfang nicht das dringendeste auf der Welt, wenn es einen funktionireneden Workaround gibt.
Just my 2 cents, Entscheidung liegt natürlich beim Autor ;)
Zitat von: enno am 09 Februar 2021, 07:24:20
das ist richtig, aber, ich kann meine zweiten Hälfte nicht davon überzeugen, sich Kürzel zu merken.
Gibt da sicher unterschiedliche Anforderungen. Für Zuhause hab ich für sowas meine Echos, mit denen ich reden kann. Unterwegs, im Büro oder im Zug würde ich nicht sowas im mein Handy sagen wollen. Da sind mir ein paar Kürzel zum eintippen lieber.
Ich bin aber mit der Notify Lösung zufrieden. Da ist das mit den verschiedenen Befehlen einfacher, als wenn das in einem Modul eingibt, wo dann alles mögliche escaped werden muss oder so. Im notify weiss ich besser wie ein Befehl aussehen muss.
Zitat von: sinus61 am 09 Februar 2021, 13:42:53
dann alles mögliche escaped werden muss oder so. Im notify weiss ich besser wie ein Befehl aussehen muss.
Ich steuer das über
ein DOIF. Die Shortcuts werden als erstes abgefragt und ganz am Schluss kommt Babble. So kann ich die Abkürzung nehmen und wenn davon nichts passt, kommt noch die Schleife über Babble, die ganz zum Schluss auch noch ausgibt, wenn gar nichts verstanden wurde. Vor Babble habe ich noch einen DOELSEIF Zweig, der "set" und andere nicht gewünschte Befehle abfängt. Dadurch benötige ich die "babbleExclude" die Jörg vorschlägt für mich nicht.
Gruss
Enno
Ich habe weiter getestet, jetzt läuft es bei mir im Docker.
Mein Weg:
1. Mit Docker-compose p -d Container erstellen
2. nach dem Start in der Console wie bei Jörg beschrieben
2.1 apt-get update
2.2 Container check im Script deaktivieren!
2.3 ./signal_install.sh system
2.4 ./signal_install.sh install
2.5 dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket &
2.6 Registrierung der Rufnummer
2.6.1 ./signal_install.sh register oder copy vom Sicherungspfad
2.6.2 cp -r /opt/fhem/signal-cli /var/lib
2.7 cd /var/lib
2.8 chown -R signal-cli: signal-cli
2.9 Starten sudo -u signal-cli /opt/signal/bin/signal-cli -u +49xxx --config /var/lib/signal-cli daemon --system &
Angelehnt an diesen Post, Danke Michel
https://forum.fhem.de/index.php/topic,84996.msg1124412.html#msg1124412 (https://forum.fhem.de/index.php/topic,84996.msg1124412.html#msg1124412)
Nutze ich dieses Dockerfile
ARG BASE_IMAGE="fhem/fhem"
ARG BASE_IMAGE_TAG="latest"
FROM ${BASE_IMAGE}:${BASE_IMAGE_TAG}
ARG L_SIGNAL_CLI="0.7.4"
# Install base environment
RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get install -qqy --no-install-recommends \
cpanminus \
build-essential \
wget \
shared-mime-info \
# default-jre-headless \
libunixsocket-java \
dbus \
libnet-dbus-perl \
shared-mime-info \
haveged \
# default-jdk \
net-tools \
nano \
systemd \
hping3 \
wakeonlan \
&& wget https://download.bell-sw.com/java/11.0.10+9/bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& apt-get install -qqy --no-install-recommends ./bellsoft-jdk11.0.10+9-linux-arm32-vfp-hflt.deb \
&& cpanm \
Net::DBus \
# Lirc::Client \
Crypt::Cipher::AES \
&& rm -rf /root/.cpanm \
&& apt-get purge -qqy \
build-essential \
cpanminus \
subversion \
&& apt-get autoremove -qqy && apt-get clean \
&& rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
COPY ./src/pre-start.sh /pre-start.sh
RUN mkdir /run/dbus
RUN chmod +x /pre-start.sh
Auszug aus der docker-compose.yml
services:
fhem:
build: fhem
privileged: true
restart: always
ports:
- "1884:1884"
- "8083:8083"
- "8084:8084"
- "7072:7072"
- "8090:8090"
volumes:
- ./fhem/core/:/opt/fhem/
network_mode: host
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
- "/dev/ttyUSB1:/dev/ttyUSB1"
environment:
FHEM_UID: 1000
FHEM_GID: 1000
TIMEOUT: 10
RESTART: 1
TELNETPORT: 7072
TZ: Europe/Berlin
NUMBER: "+49xxxx"
SLEEPTIME: "5"
depends_on:
- "mysql"
- "mqtt"
das Script pre-start.sh sieht wie folgt aus#!/bin/bash
export NUMBER="${NUMBER:-"undef"}"
export SLEEPTIME="${SLEEPTIME:-"10s"}"
SIGNALUSER=signal-cli
if [ $NUMBER != "undef" ]; then
echo -n "Checking user $SIGNALUSER ..."
if id "$SIGNALUSER" &>/dev/null; then
echo 'found'
else
adduser --disabled-password --gecos none $SIGNALUSER
echo 'created'
fi
if [ -s /var/run/dbus/pid ]; then
rm /var/run/dbus/pid
fi
echo "Starting DBus System Daemon"
dbus-daemon --system --address=unix:path=/run/dbus/system_bus_socket &
echo "Starting signal-cli"
#/usr/local/bin/signal-cli -u $NUMBER --config /opt/fhem/signal-cli daemon --system &
sudo -u signal-cli /opt/signal/bin/signal-cli -u $NUMBER --config /var/lib/signal-cli daemon --system &
echo "Wait $SLEEPTIME to give signal-cli time to come up"
sleep $SLEEPTIME
fi
Das Script pre-script.sh wird bei jedem Start des Conatiners ausgeführt. Setzt für mich den Rest, siehe Log
Running /pre-start.sh script ...
Checking user signal-cli ...Adding user `signal-cli' ...
Adding new group `signal-cli' (1001) ...
Adding new user `signal-cli' (1001) with group `signal-cli' ...
The home directory `/home/signal-cli' already exists. Not copying from `/etc/skel'.
created
Starting DBus System Daemon
Starting signal-cli
Wait 5 to give signal-cli time to come up
/opt/signal/bin/signal-cli: 41: cd: can't cd to /opt/fhem
Preparing configuration ... done
Starting FHEM ...
Ich weiß ist sicherlich nicht so elegant, aber läuft. Ich bleibe weiter am Ball.
Hi Thorben,
bin mit meiner Lösung auch schon weiter.
Tricky ist halt, was macht man im Dockerfile (so es es persitent im Image ist) und was im Script.
Und dann eben auch: Wo macht man die Registrierung?
Bis auf ein paar Kleinigkeiten die ich noch verbessern möchte, habe ich auf jeden Fall schon mal ein Script, das ein blankes FHEM basierend auf dem standard Ubuntu Image hochzieht.
die Verzeichnisse für fhem und die signal-cli registry liegen dabei außerhalb des Containers damit sie erhalten bleiben. Der Rest ist weitgehend ins Image gebacken und bleibt auch nach einem "docker rm" des Containers erhalten, so dass ein erneuter Start (bei dem man sowohl fhem config als auch signal-cli registry vorher austauschen könnte) flott vonstatten geht.
Natürlich werden jetzt Module die Abhängigkeiten außerhalb von FHEM oder spezielle Perl Module brauchen nicht berücksichtigt. Da muss man dann das Dockerfile ergänzen, bzw. vielleicht eine Konfiguration anbieten, in der man weitere "apt install" oder einfach RUN Befehle einfach ergänzen kann.
Gruß,
Jörg
Hallo,
ich habe versucht, signal-cli über das Script zu installieren. Dabei ist mir aufgefallen, dass die Registrierung nur über Voice ging, SMS brach mit einer Fehlermeldung ab:
Receive registration code for +49xxxxxxxxxx by (S)MS or (V)oice (s/v)? s
Registering +49xxxxxxxxxx with SMS
Unknown option , exiting
Mit Eingabe von "v" statt "s" ging dann die Voice-Registrierung. Nach Abschluss war allerdings die Verknüpfung der Signal-App auf meinem Telefon und der Nummer aufgehoben. Wahrscheinlich hatte ich hier einen Denkfehler und hätte stattdessen mit "link" nur meine Nummer verknüpfen sollen. Das habe ich dann im zweiten Schritt gemacht, und der FHEM-Server taucht unter "Gekoppelte Geräte" auf. Allerdings kann ich mir mit der "test"-Option keine Nachricht auf das Telefon schicken lassen. Oder kann ich keine Testnachricht an mich selber schicken?
Viele Grüße,
Daniel
Edit: Jetzt habe ich es hinbekommen. Diesmal habe ich meine Festnetznummer genommen und erfolgreich registriert. Die Tücke war, dass nun noch im Systemd-Script die Nummer per Hand geändert werden musste :-)
Hallo Daniel,
ich vermute mal, Du solltest eine neue Rufnummer (z.B. Dein Festnetz) im Signal registrieren. Damit erzeugst Du einen "neuen" Empfänger.
So habe ich das gelöst. Mit Deiner Lösung doppelst Du nur deinen Signal Account.
Habe im Wiki einen Hinweis auf die Link Option und Folgen einer Registrierung eingefügt.
Die "SMS" Option wird in der nächsten Release gefixed (den Pfad hatte ich nie probiert).
Um eine neue Nummer zu hinterlegen, kann man übrigens getrost das Script einfach neu starten (komplett oder Argument "install") - dann wird man gefragt ob man die Config anpassen möchte.
Jörg
Hallo Jörg,
ich habe im Systemd-Script noch eine Änderung vorgenommen. Hintergrund ist, dass auf meinem System der signal.service nach einem Neustart nicht automatisch mitstartete. So sieht meine Install-Section jetzt aus:
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
Jetzt wird der Dienst nach einem Systemneustart mit gestartet.
Ansonsten: Das Script ist echt gut, die Installation hat bis auf die Unschärfe mit der Rufnummerregistrierung einwandfrei bei mir funktioniert. Ich nutze es auf einem RPi4 mit Raspbian Buster.
Viele Grüße,
Daniel
Danke fürs Feedback.
Die "WantedBy" Anregung habe ich jetzt mal einfach übernommen - du hast es ja getestet :)
Siehe erster Post zu weiteren Updates im Script.
Jörg
Hier mal meine erste Version eines Docker Installers. Getestet habe ich das bisher nur in einer Ubuntu x86 VM (also keine Ahnung ob das mit Raspberry geht).
Grundidee:
- Das Script basiert auf dem Ubuntu/latest docker image
- Am Anfang des Scripts kann man wie üblich die Telefonnummer festlegen
- Außerdem lassen sich dort weitere Pakete konfigurieren (Beispiele z.B. für logdb enthalten, aber noch nicht getestet)
- Es wird ein neues Dockerimage fhem/signal erstellt, worauf der Container "fhem_signal" dann läuft
- Die Verzeichnisse für FHEM und signal-befinden sich außerhalb des Containers, damit Änderungen erhalten bleiben
- Dadurch ist es auch möglich dem Container bestehende FHEM Installationen sowie signal-cli configs mitzugeben
Voraussetzungen:
- Setzen der Variablen am Anfang vom Script: PHONE=zu verwendende Telefonnummer, FHEMUSER=existierende User in der Host Umgebung, FHEMGROUP= existerende Grupppe in der Host Umgebung
- Standardverzeichnis ist ~/fhem
- Bestehende FHEM Umgebung nach ~/fhem/fhem-6.0 oder vom Script eine aktuelle Version von fhem.de installieren lassen
- Bestehende Signal Config (z.B. aus /var/log/signal-cli nach ~/fhem/signal kopieren oder eine neue Registrierung vornehmen
- Script mit "sudo -E ./fhem_signal_docker_install.sh" starten (wenn vorher ein export PHONE=+49xxxx gemacht wurde, sorgt da -E dafür das es auch verwendet wird)
Der Rest ist selbsterklärend. Die initiale Erstellung des Image kann aber eine Weile dauern (schon auf dem PC, auf einem Raspberry wahrscheinlich ewig...)
Wird der Container mal beendet kann er mit
cd ~/fhem
docker-compose up -d
wieder gestartet werden.
mit "sudo -E ./fhem_signal_docker_install.sh remove" wird die Dockerumgebung aufgeräumt und der erstellte Container sowie das Image gelöscht (falls man nochmal ganz neu starten möchte, was z.B. notwendig ist, wenn man weitere Pakete für Module braucht). Da FHEM und signal aber außerhalb liegen, sollten diese davon unberührt bleiben.
Da ich ein rechter Docker "newbie" bin, kann es sein das nicht alles ideal gelöst ist. Anregungen willkommen.
Ich setze bewusst nicht auf dem fhem-docker Projekt (Image fhem/fhem) auf, da mir da zuviel drin ist, was ich nicht brauche.
Übrigens sollte hier nur eine exklusiv verwendete Festnetznummer verwendet werden. Mit eine gelinkten Nummer hatte ich kein Glück, das gab es Fehlermeldungen und er hat nichts empfangen. Andersherum hat meine kopierte Config vom Produktivsystem, zu Fehlern auf dem Produktivsystem geführt. Signal-cli scheint also nicht gut damit zurecht zu kommen wenn es zwei gleiche Empfänger gibt.
Jörg
Hallo,
ein paar Tage lief alles aber jetzt kommen keine Nachrichten mehr. Ubuntu ist aktuell. Fhem läuft. Hab gerade auch noch die aktuellsten Files gezogen und installiert (50_... und signal_install.sh).
von der sh get es mittels:
dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:"Test message via DBus" array:: string:+49xxx
via script (signal_install.sh test) geht es auch.
aber in Fhem mittels set signal send @blabla text geht es nicht mehr (wie gesagt bis vor kurzem lief es) sondern es kommt folgende Fehlermeldung:
Error sending message:org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
im Log steht auch nicht wirklich viel hilfreiches (verbose ist auf 5):
2021.02.14 17:45:03 3: signal: Before parse:@Nummer Sensoren:
2021.02.14 17:45:03 5: signal: sendMessage called for Nummer::Sensoren
Was könnte das sein? Wie kann ich weiter suchen?
Danke und viele Grüße
Marco
Zitat von: MarcoE am 14 Februar 2021, 17:46:47
Was könnte das sein? Wie kann ich weiter suchen?
Du könntest mal sehen was im /var/log/syslog steht - da schreibt signal-cli eine Menge rein.
Eventuell einfach mal ein "shutdown restart" von FHEM. Sollte zwar nicht sein, aber mal sehen.
Habe gerade auch noch ein update von Signalbot veröffentlich, das u.a. auch ein paar Feinheiten in der Fehlerbehandlung verbessert.
Jörg
Update V1.2 von Signalbot:
Ich habe jetzt jetzt mal alles an Funktionen die signal-cli über Dbus unterstützt in Signalbot eingebaut (zumindest die, die ich sinnvoll fand).
Leider gehen ja eine Menge Sachen (noch) nicht über das Interface.
Neu:
- block #gruppe oder contact : Serverseitiges blockieren (wogegen allowedPeer erst bei FHEM blocked)
- unblock #gruppe oder contact: Vorheriges "block" rückgängig machen
- createGroup gruppenname : Neue Gruppe erstellen
- invite gruppenname contact1,contact2.... : Kontakte in Gruppe einladen
- updateGroup gruppenname neuername : Name der Gruppe ändern
Und bevor jemand fragt - wer eine Gruppe verlassen möchte oder aktiv einer beitreten, muss das CLI bemühen - das gibt's nicht über DBus.
Außerdem gibt es jetzt ein Attribut "babbleExclude" welches ein RegEx von Nachrichten ist, die nicht nach "babble" gehen sollen (z.B. "^/" schickt keine Nachrichten die mit "/" anfangen nach Babble - Events werden aber ausgelöst)
Achso, ein paar keine Bugfixes bzw. abfangen von weiteren Fehlerfällen sind auch noch drin.
Viel Spass beim Testen.
Jörg
Signal-Cli update 0.8.0:
signal-cli wurde heute auf eine neue offizielle Version aktualisiert.
Wer die Installation aktualisieren will einfach den neusten Installer aus dem ersten Post holen und mit
sudo -E ./signal_install.sh
starten. Dies ist gefahrlos möglich, ohne Nachfrage wird nichts geändert/aktualisiert. Insbesondere kann die Frage nach der Registrierung verneint werden um dann ganz normal den Test mit der bestehenden Registrierung zu machen.
Parameter "-E" ist nötig falls die Telefonummer mit
export PHONE=+49xxxxx
gesetzt war. In diesem Fall ist keine Veränderung des Scripts notwendig.
Das Script installiert auch die weitere native Library für Raspberry - aber jetzt werden diese im .jar aktualisiert und nicht mehr nach /usr/lib kopiert. Außerdem gibt es jetzt eine Platz auf fhem.de (Danke Rudi) von dem die beiden lib.so geladen werden.
Ich habe bereits ein wenig mit der neuen Version "gespielt" und erstmal keine Auffälligkeiten entdeckt. Wer aber auf eine stabile Umgebung angewiesen ist, sollte vielleicht auf weitere Tests von "early adopters" warten. Bitte eure Erfahrungen hier posten.
Danke,
Jörg
Hallo,
Zitat von: Adimarantis am 14 Februar 2021, 17:51:49
Du könntest mal sehen was im /var/log/syslog steht - da schreibt signal-cli eine Menge rein.
Eventuell einfach mal ein "shutdown restart" von FHEM. Sollte zwar nicht sein, aber mal sehen.
Habe gerade auch noch ein update von Signalbot veröffentlich, das u.a. auch ein paar Feinheiten in der Fehlerbehandlung verbessert.
Jörg
hm- jetzt geht es wieder ohne das ich wissentlich etwas verändert hätte. Dann installiere ich auf jeden Fall mal die updates und beim nächsten Problem suche ich weiter.
Viele Grüsse
Marco
Moin Jörg,
irgend etwas fehlt bei meinem System. Ich bekomme eine Fehlermeldung wenn ich sudo ./signal_install.sh starte. Ich habe mal gegoogelt, aber noch keine Lösung gefunden... sudo: ./signal_install.sh: command not found
nun starte ich halt mit sudo bash signal_install.sh
Damit läuft es durch aber:Sending a message via dbus-send command
method return time=1613385994.085536 sender=:1.73 -> destination=:1.74 serial=6 reply_serial=2
int64 1613385993121
Sending a message via perl Net::DBus
org.asamk.Signal.Error.Failure: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
Gruss
Enno
Hallo Enno,
Zwei Dinge sind wichtig damit das geht
1.) Du hast die bash in "/bin/bash" installiert (das script fordert dies in der ersten Zeile mit #!/bin/bash an)
2.) Das script hat "x" Rechte (ggf. chmod u+x machen)
Jörg
Moin,
ich habe dann mal chmod u+x signal_install.sh nachgeholt. Und nun läuft das Script durch und das Device lässt sich in FHEM definieren und funktioniert. Bei mir unter dem SIGNALUSER=fhem und in /opt/fhem .
Ich glaube jetzt habe ich alle Fettnäpfchen durch ;D
Gruss
Enno
Hallo Adimarantis,
ich bin gerade über diesen Thread gestolpert und habe auch schon die Wiki überflogen.
Bisher nutze ich SiSi für die Signal Integration in FHEM (nur Senden).
Nun möchte ich auf dein Modul umsteigen (mehr Möglichkeiten, neuer und wird gepflegt).
Wie ist hier die beste Vorgehens weise für einen Umstieg von SiSi auf Signalbot?
Das alte System Rückbauen und dann das neue installieren oder hast du einen besseren Weg (wäre vielleicht ganz hilfreich in der Wiki)?
VG
Olli
Zitat von: octek0815 am 16 Februar 2021, 18:07:41
(wäre vielleicht ganz hilfreich in der Wiki)?
Gute Idee - neues Kapitel eingefügt. Schau mal ob das verständlich ist.
Jörg
Zitat von: Adimarantis am 16 Februar 2021, 18:33:30
Gute Idee - neues Kapitel eingefügt. Schau mal ob das verständlich ist.
Jörg
Das ging ja schnell. Leider ist mir das nicht so verständlich.
Hier würde eine etwas detaillierterer Umstiegs Leitfaden helfen.
Folgende Fragen hätte ich:
- Ich nutze mit SiSi eine Festnetznummer. Wie steige ich auf dein Modul und kann diese Nr. weiter nutzen?
- Muss ich eine Konfigurationsdatei sichern und wo muss ich dann diese hin kopieren wenn ich dein Installationsscript nutze?
- Rückbau (möchte ungern irgendwelche Leichen von der SiSi Installation zurücklassen.
Dann wäre noch das Thema Umzug auf ein neues System, was muss für dein Modul gesichert und wiederhergestellt werden?
VG
Olli
Ok. Bevor ich das zweimal schreibe noch mehr Wiki updates.
Wie du Umstieg und Umzug kombinierst kannst du daraus denke ich ableiten :)
Jörg
Guten Morgen Jörg,
danke für die tolle Arbeit und Geduld.
Habe gerade bei mir alles mit den Neuen Script getestet. #läuft
Habe auch keine Probleme mehr nach dem Reboot.
Gruß Thorben
Zitat von: Adimarantis am 16 Februar 2021, 20:16:02
Ok. Bevor ich das zweimal schreibe noch mehr Wiki updates.
Wie du Umstieg und Umzug kombinierst kannst du daraus denke ich ableiten :)
Jörg
Hallo Jörg,
der Umstieg hat nun mit deiner Anleitung im Wiki gut funktioniert.
Es gab lediglich Probleme mit dem Ersetzen der folgenden Dateien:
- /etc/dbus-1/system.d/org.asamk.Signal.conf
- /usr/share/dbus-1/system-services/org.asamk.Signal.service
- /etc/systemd/system/signal.service
Das Script erkennt zwar einen Unterschied und fragt nach ob diese ersetzt werden sollen, tut es aber dann nicht.
Beim Test scheitert dann das Starten von signal.service (es wird dann auch nur eine Nachricht versendet).
Auch ein erneutes ausführen des Scripts ändert nichts daran.
Ich habe die drei Dateien dann manuell gelöscht und das Installationsscript erneut laufen lassen.
Dann hat es funktioniert und der Test läuft durch und verschickt die drei Test Nachrichten.
Vielen Dank für Deine Arbeit!
Viele Grüße
Olli
Hi Olli,
Zitat von: octek0815 am 17 Februar 2021, 08:44:34
Das Script erkennt zwar einen Unterschied und fragt nach ob diese ersetzt werden sollen, tut es aber dann nicht.
Das ist mir jetzt ein Rätsel. Du weisst natürlich jetzt nicht mehr wie Rechte/Besitzer der Dateien gesetzt waren?
Ich habe mal kurz alle erdenklichen krummen Rechte ausprobiert, aber mit "sudo" klappt ein "cp" immer.
Du hast du schon die Nachfrage mit "y" bestätigt? Da steht zwar ein grosses "Y", das soll aber heissen, das dies der default bei "return" ist.
Jörg
Zitat von: Adimarantis am 17 Februar 2021, 10:17:35
Hi Olli,
Das ist mir jetzt ein Rätsel. Du weisst natürlich jetzt nicht mehr wie Rechte/Besitzer der Dateien gesetzt waren?
Ich habe mal kurz alle erdenklichen krummen Rechte ausprobiert, aber mit "sudo" klappt ein "cp" immer.
Du hast du schon die Nachfrage mit "y" bestätigt? Da steht zwar ein grosses "Y", das soll aber heissen, das dies der default bei "return" ist.
Jörg
Hallo Jörg,
nee, die Rechte weiß ich nicht mehr (Dateien sind ja weg).
Habe natürlich mit "Y" beantwortet, könnte das große "Y" das Problem gewesen sein?
VG
Olli
Hi Olli.
Ja :)
Und ich habe gerade geschaut, ist die einzige Stelle im Script die dann "falsch" testet (sonst geht das "if" immer auf den nicht-default, also Kleinbuchstabenfall). Patche ich dann mal das er "y" und "Y" akzeptiert.
Tja, jeder User findet einen neuen Fehler.
Jörg
Zitat von: Adimarantis am 17 Februar 2021, 10:24:09
Hi Olli.
Ja :)
Und ich habe gerade geschaut, ist die einzige Stelle im Script die dann "falsch" testet (sonst geht das "if" immer auf den nicht-default, also Kleinbuchstabenfall). Patche ich dann mal das er "y" und "Y" akzeptiert.
Tja, jeder User findet einen neuen Fehler.
Jörg
Nur so wird es dann auch gut!
Zitat von: Adimarantis am 17 Februar 2021, 10:24:09
Tja, jeder User findet einen neuen Fehler.
Ein bisschen Spass macht es dir hoffentlich trotzdem. Dickes Lob mal so zwischendurch für deinen Einsatz! Ich freue mich über jeden, der von Whatsapp und Telegram den Weg zu Signal findet 8)
Gruss von einem glücklichen User
Enno
Umfrage: Welche Funktionalitäten fehlen noch?
Welche potentiellen Erweiterungen haltet ihr noch für sinnvoll in Signalbot?
Wie schon erwähnt gibt es ja gewisse Limitierungen im Interface zu Signal. Hier habe ich aktuell aber schon einen Pull-Request laufen um eine Erweiterung in die nächste Version zu bekommen, die es ermöglicht den eigenen Namen und sein Avatarbild zu ändern. Weitere (z.B. Kontaktliste holen, Abfragen ob ein Kontakt/Gruppe geblockt ist) sind in Überlegung. Entsprechend der Funktionalitäten die hier allgemein als sinnvoll erachtet werden, würde ich dann gewisse Interfaceerweiterungen priorisieren. Vielleicht gibt es aber auch Ideen die man direkt implementieren kann.
Bald kann man wieder mehr draußen machen und dann wird meine Zeit für solche Themen knapper (Projekte im Garten stehen an). Also lieber jetzt noch das ein oder andere reinbringen.
Gruß,
Jörg
Moin Jörg,
das was ich brauche geht. Wenn ich mir noch was wünschen dürfte, dann ist es eine Vereinfachung der Eingabe für Zeilenumbrüche:
https://forum.fhem.de/index.php/topic,118370.msg1130178.html#msg1130178
Über Umwege geht es, aber eine Vereinfachung...
Von Readingsgroup direkt zu schicken hatte ich auch schon mal geträumt, aber das ist wohl eher unrealistisch.
Gruss
Enno
Hi Enno,
die Zeilenumbrüche gehen doch jetzt schon ganz normal mit "\n", oder was meinst du?
Das mit dem "direkt aus Readingsgroup" verstehe ich jetzt nicht ganz -bin mir aber nicht sicher ob das etwas ist das ich unterstützen kann oder eher Readingsgroup eine Erweiterung bräuchte.
Jörg
@weini und andere Interessierte:
Ich hab mir mal deine Idee von vor einer Weile mit dem GoogleAuth angeschaut.
Folgendes hab ich jetzt mal eingebaut (noch nicht ganz fertig, aber mal zum Diskutieren vom Konzept):
Attribute: commandKeyword, authTimeout und authDev (wird automatisch mit vorhandener GoogleAuth device gesetzt).
Beispiel commandKeyword: =
Man sendet dann =<authtoken>
Wenn korrekt, dann ist der aktuelle Sender für authTimeout Sekunden berechtigt Befehle zu senden - ebenfalls mit "=" am Anfang - ein Token im Befehl wird in diesem Zeitraum nicht benötigt. Die Berechtigung erlischt automatisch nach diesem Zeitraum. Kann auch von mehreren Nutzern (individueller Zeitraum) genutzt werden.
Eventuelle Rückmeldungen/Fehler bzw. eine Bestätigung geht per PM an den Absender.
Eine Einschränkung der Befehle oder zusätzliche Beschränkung des Absenders habe ich jetzt nicht eingebaut - braucht man das?
Jörg
Zitat von: Adimarantis am 19 Februar 2021, 21:40:53
die Zeilenumbrüche gehen doch jetzt schon ganz normal mit "\n", oder was meinst du?
ok, das hatte ich überlesen und falsch getestet: "\n" in DOIF klappt. Erledigt!
Zum Readingsgroup: Ich habe z.B, ein Readingsgroup, das mir alle Batterien anzeigt (https://wiki.fhem.de/wiki/ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt)
Dieses "Bild" würde ich gerne einfach so per Signal schicken ;) Das scheint aber nicht so einfach machbar zu sein. Das Thema wurde auch schon mal im Forum kurz in Verbindung mit Telegram angefragt: https://forum.fhem.de/index.php?topic=81826.0
Gruss
Enno
Hi Enno,
Kurz mal geschaut, da bräuchte man dann tatsächlich einen HTML -> JPEG Konverter. Der in den Threads referenzierte wird nicht mehr unterstützt. Signal selbst unterstützt auch kein HTML. Letztendlich wäre das eine Sache für ein Extra Modul, welches man dann wie die SVG's mit dem &() Syntax aufruft. Das gehört m.E. nicht individuell in ein Modul eingebaut sondern als generische Funktionalität extra. In der Hauptsache müsste man dazu einen "headless" Browser oder Service finden. Hab auf die Schnelle da sogar im Internet Services gefunden, die scheinen aber zumindest teilweise kostenpflichtig zu sein und man dann nie weiß wie lange es die gibt und ob sich die API ändert. Das nächste Problem ist, das z.B. bei deinen Batterien Verweise auf Bilder/Icons enthalten sind. Die müsste man bei einem Webservice mitschicken - also ggf. ein zip hochladen. Du siehst, das führt ziemlich weit.
Ich fände so eine Übersicht ohnehin unübersichtlich am Handy. Für meine zig Homematic Geräte habe ich das einfach so in einem DOIF gelöst:
([SignalBot:msgText] eq "Status") (
{ my $group = "[SignalBot:msgGroupName]";
my $reply = "@"."[SignalBot:msgSender]";
if ($group ne "") {
$reply="#$group";
}
my $text= "Batterie: [d_ccu:battery_list],[d_ccu:voltage_list] \nOffen:[d_ccu:lock_list] \nNicht erreichbar: [d_ccu:unreach_list]";
fhem "set SignalBot send $reply $text";
})
Einfach kompakt die Liste der Problemgeräte.
Gruß,
Jörg
Hallo Jörg,
vielen Dank für Dein Modul und Script zum SignalBot. Habe es nach Wiki installiert, lief problemlos durch (Debian Buster auf Zotac MiniPC). Registrierung auf eine Festnetznummer per voice.
Nun bin ich dabei, meine fhem-messages von Telegram auf Signal umzuziehen. Signal kann ja leider kein fett, kursiv, code etc, aber damit kann ich leben und es scheint bei Signal auf der Todo-list zu stehen. Was ich gerne nutze sind die Smilies/Emojys, wie bei https://wiki.fhem.de/wiki/TelegramBot#Versand_von_Emojis_.28Smileys.29 (https://wiki.fhem.de/wiki/TelegramBot#Versand_von_Emojis_.28Smileys.29) beschrieben. Das klappt auch, also die empfangenen Messages haben die Smilies dabei, es gibt aber eine Perlwarning:
PERL WARNING: Wide character in print at fhem.pl line 1000.
Da muss irgendwie dem Teil, der das Smilie transportiert/druckt mitgeteilt werden, dass es ein utf8 codiertes Zeichen ist. Vielleicht kannst Du da ja etwas erreichen, damit die Warning nicht mehr kommt.
Weiterhin bekomme ich im Log bei jedem Versand so etwas:
2021.02.21 15:06:01.625 3: mySignalBot: Before parse:\@Empfaenger Text:
Empfaenger und Text je nach message.
Ist das nur eine Anzeige im Log, dass etwas verschickt wurde?
Edit: gerade getestet, wird bei verbose 2 nicht mehr ausgegeben.
Nochmal vielen Dank. Bis jetzt kann SignalBot alles, was ich brauche. Nutze es eigentlich nur, damit fhem mir verschiedene Mitteilungen macht, und da Abfragen recht simpel sind werde ich mir da ein paar einbauen (Statusbericht oder Spritpreis z.B., das spart dann unterwegs den VPN anwerfen und die Oberfläche starten).
Gruß
Sany
Ich habe auch für die Meldungen die per Signal kommen meist ein Emoji dabei. Die schicke ich mir vorher aus Signal an Fhem, kopiere die dann da und füge sie direkt in meine Notifys ein. Eine Fehlermeldung sehe ich da nicht in Log.
Für Textformatierung kann man als Workaround z.B. https://yaytext.com nehmen. Text dort einfügen und in der gewünschten Formatierung ins Notify übernehmen. Allerdings wird sowas wie [Device:Reading] nicht mehr erkannt.
Also ich bekomme die
PERL WARNING: Wide character in print at fhem.pl line 992.
erstens nur einmalig und zweitens nur wenn das logging eingeschaltet ist (verbose=3+) und FHEM entsprechend versucht die Smileys ins Log zu schreiben (was trotzdem klappt)
@sinus61: Klasse Tipp mit dem https://yaytext.com/ - da kriegt man wirklich so ziemlich alles dargestellt was man möchte, obwohl Signal das native (noch) nicht kann.
Da kann man denke ich nicht viel machen.
Testversion mit GoogleAuth
Wer mag, bitte mal probieren.
Vorrausetzung ist ein GoogleAuth device und entsprechend aktivierter App wie hier beschrieben: https://forum.fhem.de/index.php?topic=64791.0
Im Signalbot sind dann folgende Attribute zu definieren:
cmdKeyword = Zeichen oder Zeichenkette die einen Befehl einleitet - in meinem Beispiel hier das "=" Zeichen
authTimeout = Anzahl der Sekunden die eine Authentifizierung Gültigkeit behalten soll
authDev = der Name der GoogleAuth Device. Wird automatisch beim Setzen von "authTimeout" auf die erste gefundene Device vom Typ "GoogleAuth" gesetzt
Jetzt einfach das 6-stellige Token aus der Google Authenticator App kopieren und
=123456
senden. Sofern alles ok ist bekommt man die Bestätigung das man jetzt für xx Sekunden Zugriff hat.
alternativ kann man auch gleich den ersten Befehl senden
=123456 set Lampe1 aus
Solange der "Countdown" läuft werden jetzt beliebige Befehle mit
=set Lampe1 an
akzeptiert.
Die Befehle triggern keine Events und tauchen auch nicht in der Message History auf. Vielleicht sollte ich hier noch ein Reading "lastCommand" befüllen. Das kann ja dann ruhig triggern da andere Notifys wohl eher auf "msgText" horchen werden.
Jörg
Zitat von: Adimarantis am 20 Februar 2021, 00:18:48
Eine Einschränkung der Befehle oder zusätzliche Beschränkung des Absenders habe ich jetzt nicht eingebaut - braucht man das?
Erst mal finde ich es super cool, dass du die Idee aufgegriffen hast. 1000 Dank dir!
Ja, das macht aus meiner Sicht viel vom Mehrwert aus:
- einfache Sachen wie Temperaturen abfragen will ich komfortabel haben
- für sensible Dinge wie Rollos hoch oder Türe auf wünscht ich mir die zusätzliche Sicherheit, da kommt GoogleAuth ins Spiel
Aus meiner Sicht ist eine Whitelist (welche Befehle dürfen ohne GoogleAuth laufen) besser als eine Blacklist.
Ich sehe schon, ich muss jetzt endlich mal testen. Ich versuche, im Verlauf der Woche zu starten und gebe dann Rückmeldung.
LG, weini
ZitatAlso ich bekomme die
Code: [Auswählen]
PERL WARNING: Wide character in print at fhem.pl line 992.
erstens nur einmalig und zweitens nur wenn das logging eingeschaltet ist (verbose=3+) und FHEM entsprechend versucht die Smileys ins Log zu schreiben (was trotzdem klappt)
@sinus61: Klasse Tipp mit dem https://yaytext.com/ - da kriegt man wirklich so ziemlich alles dargestellt was man möchte, obwohl Signal das native (noch) nicht kann.
Da kann man denke ich nicht viel machen.
Hallo Jörg,
danke für die Antwort. Ich habe die Warnmeldung auch nur bei verbose 3 oder höher. Habs jetzt auf 2 gestellt, das tut es so für mich.
Jetzt bin ich gerade am kämpfen mit der Einrichtung einer Gruppe (XYZ). Habe 2 Handys mit eigenem Signal und die Instanz auf fhem (heißt hier fhem). Wenn ich es richtig verstehe starte ich die Gruppeneinrichtung von fhem aus. Die anderen Teilnehmer müssen dann die Einladung annehmen. Korrekt bis hier?
Leider kommt bei einem Handy (iOS) da eine Meldung, die mir nicht weiterhilft:
Error in invite:org.asamk.Signal.Error.Failure: Cannot join a V2 group as self does not have a versioned profile(also der Fehler wird in fhem angezeigt, nach schicken des invite)
Wenn ich dann an die Gruppe (fhem + 1 Handy) etwas schicke kommt:
Error sending message:org.asamk.Signal.Error.GroupNotFound: User is not a member in group: XYZ (Zahlen/Buchstabensalat passwort/Kennung??)Schaue ich im Handy, welches sich verbinden ließ, die Gruppeninfo an, bekomme ich:
Zitatfhem hat die Gruppe aktualisiert
fhem ist der Gruppe beigetreten
Gruppenname lautet jetzt "XYZ"
Diese Gruppe wurde auf eine Gruppe neuen Typs aktualisiert
Ein Mitglied konnte der Gruppe neuen Typs nicht hinzugefügt werden und wurde daher eingeladen, beizutreten.
(Mehr erfahren): u.a. dieses Mitglied muss eine Einladung zum erneuten Gruppenbeitritt annehmen und wird bis dahin keine Gruppennachrichten erhalten:
fhem
Beim iOS-Handy könnte es evtl. an einer Einstellung liegen, da muss ich mal schauen (habs nicht so mit äpple), aber bei den andern Problemen komme ich nicht weiter.
Die Fehlersuche im Wiki habe ich mal angeschaut und durchgearbeitet, aber die Fehler bei mir äußern sich ja etwas anders, die Dateien sind jeweils nur einmal vorhanden im Zusammenhang mit signal-Verzeichnissen. Das Installscript habe ich nochmals laufen lassen, (bis auf die Regisitrierung): alle Punkte sind erfolgreich und am Ende erhalte ich die 3 Messages.
Was kann ich tun?
Danke schon mal.
Sany
Hi Sany,
erstmal ein wenig Theorie:
Signal hat vor eine Weile so genannte "V2" Gruppen eingeführt. Da wurde wohl einiges an Funktionalität verbessert. Um mit diesen Gruppen zu arbeiten, braucht man zwingend eine native library (libzkgroup.so). Ohne diese, findet ein Fallback auf V1 Gruppen statt.
Gruppen müssen nicht zwingend aus Signalbot erstellt werden. Man kann "fhem" auch ganz normal in eine Gruppe einladen.
Was bei dir jetzt passiert ist: Dein System findet die library nicht und macht daher nur V1 Gruppen. Diese konntest du auch Erstellen und Leute einladen. Nur als diese neuen Mitglieder beigetreten sind, wurde die Gruppe in V2 umgewandelt und da dein System das nicht kann, fliegst du raus.
Fazit: Die Suche geht weiter, warum findet dein System die Library nicht? Hast du auch schon mit dem neusten Installscript auf signal-cli 0.8.0 upgegradet? Ab dann gibt es nämlich sogar zwei libraries und dann geht ohne gar nichts mehr - da wundert mich nämlich warum du nur GroupV2 Probleme hat.
Was für ein System hast du? (Betriebssystem. Architektur?)
Jörg
Zitat von: weini am 21 Februar 2021, 21:05:19
- einfache Sachen wie Temperaturen abfragen will ich komfortabel haben
Um sowas komfortabel zu haben, würde ich halt mit Notify/DOIF arbeiten und spezifische Befehle anbieten. Über "allowedPeer" findet hier ja eine grundsätzliche Einschränkung statt. Mit GoogleAuth ist es halt so eine Art Administratorzugang.
Freie FHEM Befehle - auch mit einer Einschränkung über eine Whitelist - ohne Absicherung anzubieten halte ich jetzt grundsätzlich für bedenklich.
Jörg
Also die Einschränkung via allowedPeer soll natürlich immer greifen.
Wenn GoogleAuth konfiguriert ist, dann solle der Standard sein, dass ein Token übergeben werden muss.
Über eine GoogleAuth Whitelist könnte man aber Befehle definieren, für die kein GoogleAuth Token notwendig ist.
PS: Meine grundsätzliche Installation läuft übrigens, jetzt geht es ans Ausprobieren und Feinschleifen....
ZitatFazit: Die Suche geht weiter, warum findet dein System die Library nicht? Hast du auch schon mit dem neusten Installscript auf signal-cli 0.8.0 upgegradet? Ab dann gibt es nämlich sogar zwei libraries und dann geht ohne gar nichts mehr - da wundert mich nämlich warum du nur GroupV2 Probleme hat.
Was für ein System hast du? (Betriebssystem. Architektur?)
Hallo Jörg,
ich habe das vorgestern zum ersten Mal installiert, dazu vorher das system upgedated (Debian Buster auf x86 Zotac MiniPC) und die Dateien vom Forum frisch heruntergeladen, also Script-Version 1.5.
Schon mal Danke für die Theoriestunde, dann erklärt sich das Verhalten ja.
Sany
Hi Sany,
kannst du mal den /opt/signal Ordner löschen und die Installation nochmal machen.
Dann bitte das /tmp/signal_install.log und die Bildschirmausgabe posten (Telefonnummern vorher unkenntlich machen).
Aktuell kann ich mir nur noch vorstellen, das mein Script dein System versehentlich als Raspberry identifiziert und diese Libraries installiert - was dann unter X86 nicht mehr funktioniert.
Jörg
Zitatkannst du mal den /opt/signal Ordner löschen und die Installation nochmal machen.
Dann bitte das /tmp/signal_install.log und die Bildschirmausgabe posten (Telefonnummern vorher unkenntlich machen).
die Bildschirmausgabe:
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.0
System library path: /usr/lib
Phone number to be used: +49yyyyyy
Your configuration
Linux ZotacFHEM 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
has not been tested, continue at own risk
This will update system packages, install signal-cli and help to register with Signal service
To do this rather step by step use the command line arguments or just proceed to do system,install,register:
system : prepare required system package (except signal-cli) - make sure you ran this before you do anything else!
install : install signal-cli and setup as dbus system service
register : register a NEW number with Signal
link : link an EXISTING number with Signal (e.g. you Smartphone)
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
join : Join current number to an existing group (invite by group link)
name : set or change Signal user name and/or avatar picture
start : Start the signal-cli service (or respective docker processes)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for pkg-config...available
Checking for gcc...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/perl5/Test/CPAN/Changes.pm...available
Checking for /usr/include/expat.h...available
Checking for /usr/share/doc-base/libxml-parser-perl...available
Checking for /usr/share/doc/libtemplate-perl...available
Checking for /usr/share/doc/libxml-xpath-perl...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libxml-twig-perl...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for Net::DBus...V1.2.0 found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.8.0...done
Unpacking ...
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
Your device +49yyyyyyyy is already configured, do want to run through registration again?
Continue (y) or skip (N)?n
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49xxxxxxx
Sending a message from command line to +49xxxxxx
Stopping signal-cli service
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
1613983968341
Start signal-cli service
Sending a message via dbus-send command
method return time=1613983980.192610 sender=:1.82 -> destination=:1.83 serial=7 reply_serial=2
int64 1613983978861
Sending a message via perl Net::DBus
return timestamp:1613983980678
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEMund das log:
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"wie gesagt, script läuft ohne Fehlermeldungen durch.
Sany
Hi Sany,
das schaut wirklich alles gut aus. Vor allem hätten da jetzt schon Fehlermeldungen drin sein müssen wegen V2groups etc. - schaut so aus als hätte er die Libraries zumindest im interaktiven Modus gefunden.
Schon mal rebooted?
Dann schau mal was nach dem Reboot und Versuchen etwas an Gruppen zu senden oder zu Empfangen in /var/log/syslog steht
grep signal-cli /var/log/syslog
Falls da nur was von "Binärdatei" kommt (war bei mir so - wahrscheinlich wegen Emojis oder Umlauten) dann workaround
strings /var/log/syslog | grep signal-cli
Jörg
ZitatDann schau mal was nach dem Reboot und Versuchen etwas an Gruppen zu senden oder zu Empfangen in /var/log/syslog steht
So, rebootet und ausprobiert:
Erst mal das 2te handy vom ersten aus in die Gruppe eingefügt. Das ging. Dann der Versuch, von fhem aus an die Gruppe zu senden:
Im fhem-log:
2021.02.22 11:39:01.716 3: mySignalBot: Before parse:#StCpt Test7:
2021.02.22 11:39:01.716 5: mySignalBot: sendGroupMessage called for StCpt::Test7
2021.02.22 11:39:01.716 5: mySignalBot: getGroup StCpt
2021.02.22 11:39:35.404 5: mySignalBot: Read from Dbus doneim syslog steht davon gar nichts. Dort sind nur Einträge, wenn ich an einzelne Handys was schicke oder von denen nach fhem.
Ich habe dann eine neue Gruppe von einem Handy aus begonnen und das andere Handy und fhem eingeladen. Auch da kommt der Hinweis, dass fhem keine Nachrichten empfangen kann, solange es den Einladungslink nicht bestätigt hat. In der Gruppeninfo taucht es auch nicht auf.
Im Syslog steht dazu:
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Envelope from: unknown source
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Timestamp: 1613990762609 (2021-02-22T10:46:02.609Z)
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Sent by unidentified/sealed sender
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Sender: "S" +49yyyyyy (device: 1)
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Message timestamp: 1613990762609 (2021-02-22T10:46:02.609Z)
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Group info:
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Id: eZQk9LmtNqXXXXXXXXXXXXXXXXXXXXXXXhmSPUHVpGA=
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Name: CptSt
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Revision: 1
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Master key length: 32
Feb 22 11:46:05 ZotacFHEM signal-cli[546]: Has signed group change: trueDann habe ich das Installscript mit join gestartet und den Einladungslink übergeben. Das ergibt das Folgende:
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.0
System library path: /usr/lib
Phone number to be used: +49xxxxxxxxxx
Your configuration
Linux ZotacFHEM 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
has not been tested, continue at own risk
Your chose the following option: join
Please enter the uri link (created share group link, looking like https://signal.group/......
Group:https://signal.group/#CjQzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzPreV7Ic (geändert)
Stopping signal-cli service
If you get a 'in use, waiting' message, then stopping of system Signal service did not succeed. Press Ctrl-C and try again
java.io.IOException: Cannot join a V2 group as self does not have a versioned profile
at org.asamk.signal.manager.helper.GroupHelper.joinGroup(GroupHelper.java:274)
at org.asamk.signal.manager.Manager.sendJoinGroupMessage(Manager.java:864)
at org.asamk.signal.manager.Manager.joinGroup(Manager.java:856)
at org.asamk.signal.commands.JoinGroupCommand.handleCommand(JoinGroupCommand.java:49)
at org.asamk.signal.App.handleLocalCommand(App.java:211)
at org.asamk.signal.App.init(App.java:169)
at org.asamk.signal.Main.main(Main.java:43)
Failed to send message: Cannot join a V2 group as self does not have a versioned profile
Start signal-cli service
If the recipient got the messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEMMessages kamen keine....
Nach refreshGroups erscheint aber die neue Gruppe in fhem. Nur kann ich nicht dorthin senden (gleicher Fehler: Error sending message:org.asamk.Signal.Error.GroupNotFound: User is not a member in group: CptSt (eZQk9zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzHVpGA=)
Hi Sany,
in der signal-cli Doku habe ich folgendes gefunden:
To be able to join a v2 group the account needs to have a profile (can be created with the updateProfile command
Probier mal den Installer mit dem "name" Argument zu starten und einen Namen für dein Profil zu definieren.
Jörg
hat fast geklappt:
Your chose the following option: name
Please are name for your Signal User with number +49yyyyyyyyyy (You have to update the name if you want to set a picture!)
Name:abcdefgh
Please provide a filename to a picture to be used as avatar for your user (press return to keep unchanged)
File:
Stopping signal-cli service
If you get a 'in use, waiting' message, then stopping of system Signal service did not succeed. Press Ctrl-C and try again
Update profile error: /home/steff (Is a directory)
Stopping signal-cli service
Your profile has been updated
habe das script mit sudo im home-Verzeichnis gestartet.
Hi Sany,
Ok. Da ist noch ein Bug im Script.
Nimm doch einfach mal
/opt/fhem/www/images/default/fhemicon.png
als File - dann kriegst das das nette FHEM logo also Avatarbild.
Bei leeren Eingaben stimmt meine Abfrage im Script nicht.
Jörg
gibt noch nen Fehler...
Please provide a filename to a picture to be used as avatar for your user (press return to keep unchanged)
File:/opt/fhem/www/images/default/fhemicon.png
File /home/steff//opt/fhem/www/images/default/fhemicon.png was not found
irgendwie hängt er den home-Pfad davor
Probiers mal damit. Ich hoffe der Fehler ist hier gefixed
Success!!
Script lief durch, konnte dann vom Handy aus den fhem in die Gruppe aufnehmen und dann von fhem Nachrichten in die Gruppe schicken.
Prima, das wars!
Gruß
Sany
Prima, dann nehme ich das am Besten mal ins Wiki auf und das Setzen eines Namens sollte Teil des Standardablaufs nach der Registrierung im Script werden
P.S. Ein "updateProfile" aus FHEM ist in Vorbereitung. Dazu braucht man aktuell aber eine beta-version von signal-cli (also quasi 0.8.1)
Jörg
Hallo Jungs,
nachdem ich seitens Signal die Aufvorderung bekommen habe meine Smarthome Gruppe auf v2 hochzurüsten und mein Signal-Cli Client angeblich einer der Member ist, die nicht mit v2 Gruppen zurechtkommt, habe ich mein Signal-Cli auf 0.8.0 aktualisiert.
Im Zuge dessen musste ich heute feststellen, dass SiSi nicht mehr aktuell ist, sondern Signalbot.
Dieses Modul wollte ich natürlich gleich aktivieren und beginn damit net-dbus zu aktualisieren.
Allerdings brach mir die Installation mit folgender Fehlermeldung ab....
cpan install -f Net::DBus
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/root/.cpan/Metadata'
Database was generated on Mon, 22 Feb 2021 12:29:03 GMT
Running install for module 'Net::DBus'
Checksum for /root/.cpan/sources/authors/id/D/DA/DANBERR/Net-DBus-1.2.0.tar.gz ok
Configuring D/DA/DANBERR/Net-DBus-1.2.0.tar.gz with Makefile.PL
DBus >= 1.3.0 is required
Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site]
DANBERR/Net-DBus-1.2.0.tar.gz
/usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OKNAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionicdbus/bionic-updates,bionic-security,now 1.12.2-1ubuntu1.2 amd64 [installiert]
libdbus-1-3/bionic-updates,bionic-security,now 1.12.2-1ubuntu1.2 amd64 [installiert]
libdbus-glib-1-2/bionic,now 0.110-2 amd64 [Installiert,automatisch]
libnet-dbus-perl/bionic,now 1.1.0-4build2 amd64 [installiert]
libqt5dbus5/bionic-updates,bionic-security,now 5.9.5+dfsg-0ubuntu2.5 amd64 [Installiert,automatisch]
python-dbus/bionic,now 1.2.6-1 amd64 [Installiert,automatisch]
python3-dbus/bionic,now 1.2.6-1 amd64 [installiert]Mich macht vorallem fogendes stutzig ....
ZitatDBus >= 1.3.0 is required
Welche aktuelle Debian oder Ubuntu Version hat denn eine Dbus Version größer/gleich 1.3 ?
Oder jage ich irgendwelchen Geistern hinterher ?
Hat jemand eine Idee ?
Gruß
Rubinho
Hi Rubinho,
Das 1.3.0 hatte mich auch schon mal verwirrt. Das sind einfach Abhängigkeiten in der Installation.
Da kann ich wieder nur empfehlen mein Install Script zu verwenden, das alles auflöst - gibt extra eine Sektion im Wiki dazu wie man von SiSi umsteigt und seine Konfiguration behält.
Gruß,
Jörg
Zitat von: Adimarantis am 21 Februar 2021, 20:15:08
Testversion mit GoogleAuth
Wer mag, bitte mal probieren.
So, habe jetzt erfolgreich die GoogleAuth Integration getestet, funktioniert super! Dabei habe ich jetzt auch das Prinzip verstanden. Finde ich soweit Klasse. Was mir noch fehlt, sollte via DOIF/notify machbar sein.
Meine Wunschliste wäre:
- "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
Vorsicht, dass die Attributnamen nicht zu lang werden. Bin mir nicht sicher, wo da das Limit ist.
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.
VG,
weini
Hi Adimarantis
Danke für die Info.
Nach änfänglichen Problemen, konnte ich mittels Script die notwenigen fehlenden Pakete installieren.
Nun läuft das Modul.
Eine Frage noch zum Script... ich wollte in meine HomeAutomation Gruppe joinen, was nicht funktioniert hat, da ich meinem Profil keinen Namen verpasst hatte.
Darauf hin versuchte ich meinem Profil einen Namen zu verpassen, was allerdings auch nicht funktionierte und mit folgender Fehlermeldung terminierte...
ZitatUpdate profile error: /home/fhem (Is a directory)
SIGNALPATH=/opt/fhem
SIGNALUSER=fhem
LIBPATH=/usr/lib
SIGNALVERSION="0.8.0"
SIGNALVAR=/opt/fhem/.local/share
DBSYSTEMD=/etc/dbus-1/system.d
DBSYSTEMS=/usr/share/dbus-1/system-services
SYSTEMD=/etc/systemd/system
LOG=/tmp/signal_install.log
TMPFILE=/tmp/signal$$.tmp
VIEWER=eog
DBVER=1.2.0
OPERATION=$1Was könnte das sein ?
---Edit---
Ich hab den Namen manuell direkt via signal-cli angelegt, danach hat das joinen funktioniert.
Zitat von: weini am 22 Februar 2021, 18:45:58
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.
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.
Zitat von: rubinho am 22 Februar 2021, 18:46:45
Update profile error: /home/fhem (Is a directory)
Den Fehler hatten wir heute schon mal - war nur noch nicht dazu gekommen den Installer zu updaten. Ist jetzt geschehen (V1.6)
Jörg
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
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.
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.
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?
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
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
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
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?
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
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
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.
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.
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
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
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
Die Fehlermeldung ist normal. Das ist etwas von der Funktionalität für die nächste signal-cli Version, die schon eingebaut ist. Wird aber ignoriert und sollte trotzdem normal funktionieren.
Geht es denn jetzt?
Jörg
Leider nein, gleiche Fehlermeldung.
Error sending message:org.freedesktop.dbus.exceptions.DBusExecutionException: Error Executing Method org.asamk.Signal.sendMessage: Unknown version: 0
Zitat von: Adimarantis am 28 Februar 2021, 08:09:15
In der Version ist auch dein msgAuth Feature drin.
Vielen Dank dir!
Leider scheint es bei mir noch nicht wie geplant zu funktionieren. Ich habe für meine allowedPeers jeweils Contacts/Nicknames definiert.
Habe mir deinen Code angesehen: Kann es sein, dass der Vergleich aktuell nur funktioniert, wenn der msgSender die Telefonnummer und nicht den Kontaktnamen enthält?
Ich würde gerne mit der Telefonnummer testen, aber wie bekomme ich eigentlich die via "setContact" erstellte Zuordnung des Nicknames wieder entfernt?
VG,
weini
PS: also bei mir bleibt msgAuth grundsätzlich 0, auch wenn ich mich erfolgreich authentifiziert habe
Jetzt ist mir bei der Durchsicht deines Codes noch etwas aufgefallen:
Für das Handling von "Commands" (via Signalbot_command) berücksichtigst du die allowedPeers nicht. Das hatte ich eigentlich nicht so gedacht. "allowedPeer" sollte erst einmal generell den Zugriff regeln.
Denkst du, du könntest das noch anpassen?
VG,
weini
Hi Weini,
Du hast erstmal recht - da wird falsch geprüft wenn Contacts Namen haben. Wenn du schon im Code bist:
Zeile 457 ändern: ($sender -> $source)
if (defined $hash->{helper}{auth}{$source}) { $auth=$hash->{helper}{auth}{$source}; }
Ich hatte das alllowedPeer vs. GoogleAuth als alternative gesehen. Wer für GoogleAuth authentifiziert ist, sollte doch keine weitere Einschränkung brauchen.
Da befürchte ich auch Missverständnisse von Users ("bei mir geht GoogleAuth nicht! - Ach, da muss ich allowedPeer auch noch setzen?....")
Jörg
Hi Jörg!
Auch mit der Änderung bleibt msgAuth bei mir immer auf 0. Reload habe ich natürlich gemacht.
Ich hatte GoogleAuth nicht als Alternative sondern als Zusatz zu allowedPeer gesehen. Ohne allowedPeer würde ich ein Messenger Modul nicht betreiben. Wenn jeder Nachrichten schicken kann und irgendwo ein Sicherheitsabfrage im Modul ausgetrickst werden kann, dann ist alles offen. Für mich bringt GoogleAuth die erweiterte Sicherheit, wo ich dem Messenger Service nicht vertraue. Wenn bei Signal jemand durch welchen Umstand auch immer z. b. die Sender-Telefonnummer faken könnte, dafür will ich dann GoogleAuth zur erweiterten Absicherung.
VG,
weini
Kurzes Update zu msgAuth:
Es wird jetzt korrekt aktualisiert, wenn ich eine normale Nachrich (kein Command) sende, nachdem vorher via Command und Token authentifiziert wurde.
Was aber aus meiner Sicht sinnvoller wäre ist, wenn msgAuth schon aut 1 gehen würde, wenn man z. B. via "=934943" den GoogleAuth Code übermittelt.
VG,
weini
PS: Jetzt hab ich etwas zu schnell geschossen, im Prinzip passt das ja so. Ich muss erst wissen, ob eine Authentifizierung aktiv ist, wenn ein normaler Text geschickt wird. So hatten wir es vor ein paar Tagen ja auch diskutiert. Mea culpa, das passt also wunderbar.
Zitat von: weini am 28 Februar 2021, 20:43:25
Ich hatte GoogleAuth nicht als Alternative sondern als Zusatz zu allowedPeer gesehen. Ohne allowedPeer würde ich ein Messenger Modul nicht betreiben. Wenn jeder Nachrichten schicken kann und irgendwo ein Sicherheitsabfrage im Modul ausgetrickst werden kann, dann ist alles offen. Für mich bringt GoogleAuth die erweiterte Sicherheit, wo ich dem Messenger Service nicht vertraue. Wenn bei Signal jemand durch welchen Umstand auch immer z. b. die Sender-Telefonnummer faken könnte, dafür will ich dann GoogleAuth zur erweiterten Absicherung.
Muss ich mir nochmal überlegen. Grundsätzlich ja kein Problem - man müsste nur den test auf das Kommando in den Zweig nach allowedPeer Test verschieben.
Ich würde übrigens als allowedPeer möglichst nur Telefonnummern nehmen. Es kommt nämlich demnächst eine Änderung die den Profilnamen als Klarnamen liefert wenn kein Kontakt gesetzt ist. Der Kontakt hat zwar Vorrang, aber wenn man vergisst einen Kontaktnamen zu setzen, dann könnte jemand einfach seinen Profilnamen so ändern wie dein allowedPeer und schon ist er drin.
Jörg
Hallo zusammen,
zuerst von mir ein Dankeschön für das Entwickeln von Signalbot.
Ich habe mir über den Link auf dem ersten Post von dem Thema die Files gezogen und Signalbot auch installiert bekommen.
Jedoch bekomme ich keine Verifizierung meiner Rufnummer hin.
Weder SMS/Voice noch Handy/Festnetznummer funktionieren.
Die CLI sagt mir, ich würde den Code per Sprache/SMS bekommen, jedoch kommt bei mir nicht an.
Hier der Output:
=======================================================
pi@raspberrypi:~ $ sudo -E ./signal_install.sh register
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.0
System library path: /usr/lib
Phone number to be used: +49722xxx
You seem to be on a Raspberry pi with armv7l
Your chose the following option: register
Registering for +49722xxx
Receive registration code for +49722xxx by (S)MS or (V)oice (s/v)? v
Registering +49722xxxx with Voice call
Stopping signal-cli service
You should get a call or SMS now providing a 6 digit code
===================================================
Beim Googeln bin ich auf folgenden Eintrage gestoßen:
https://github.com/AsamK/signal-cli/issues/300
Kennt ihr das Problem?
Im Syslog finde ich auch keine Einträge wenn ich ein Grap auf singal-cli mache.
Viele Grüße
Hi Kaufi,
Brich mal an der Stelle ab und schau ob du unter /tmp/signal*.tmp logdateien findest.
Was steht da drin?
Wenn soweit alles installiert ist, kannst du auch mal
sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49xxxx register --voice
direkt ausführen (was anderes macht das Script auch nicht). Dann siehst du eventuelle Fehlermeldungen die das Script versteckt.
Jörg
Hallo Jörg,
vielen Dank für das tolle Modul und das dazugehörige Install-Skript!
Es hat alles auf Anhieb funktioniert. ;)
Jetzt brauche ich den Telegram-Bot nur noch für Dialoge einspannen...
Da ich vieles mit msg push [...] umgesetzt habe hier noch meine Anpassungen an ROOMMATE
und im globalMsg-Device:
ROOMMATE:
msgContactPush signalbot:@Sebastian
globalMsg:
msgCmdPush set %DEVICE% send %MSG%
Ich weiß das ist nur sehr rudimentär - aber für meinen Anwendungsfall ausreichend.
Vielleicht setzt du dich mal mit loredo (Maintainer von globalMsg) in Verbindung. Die Vorbereitungen sind laut
get routeCmd push
bereits vorhanden:
Signalbot
Priority Normal:
Default Values:
Priority High:
Priority Low:
SiSi
Priority Normal:
set %DEVICE% %SiSi_MTYPE% @%RECIPIENT% %MSG%
Default Values:
RECIPIENT = [EMPTY]
SiSi_MTYPE = message
Priority High:
set %DEVICE% %SiSi_MTYPE% @%RECIPIENT% %MSG%
Default Values:
SiSi_MTYPE = message
RECIPIENT = [EMPTY]
Priority Low:
set %DEVICE% %SiSi_MTYPE% @%RECIPIENT% %MSG%
Default Values:
SiSi_MTYPE = message
RECIPIENT = [EMPTY]
VG Sebastian
Hi Sebastian,
ich hab mal einen Post dazu im Thread von Loredo losgelassen.
Ich meine das ich da gar nichts machen muß, aber so richtig hab ich mich nicht damit beschäftigt. Ich muss mir das msg Modul auch nochmal genauer ansehen. Hab selber viele DOIFs mit Benachrichtigungen und auch eine rudimentäre Anwesenheitserkennung über "Presence" via Handy MAC Adressen auf der Fritzbox. Kannst du mir (evtl. per PM) mal ein paar Beispiele geben, welche Anwendungsfälle du da konfiguriert hast und wie? Gerade geht alle Zeit in die Komplettüberarbeitung von Signalbot inkl. pull requests für signal-cli drauf, da will ich mich gerade nicht mühsam einlesen :)
Jörg
Zitat von: Adimarantis am 01 März 2021, 08:53:20
Hi Sebastian,
ich hab mal einen Post dazu im Thread von Loredo losgelassen.
Ich meine das ich da gar nichts machen muß, aber so richtig hab ich mich nicht damit beschäftigt. Ich muss mir das msg Modul auch nochmal genauer ansehen. Hab selber viele DOIFs mit Benachrichtigungen und auch eine rudimentäre Anwesenheitserkennung über "Presence" via Handy MAC Adressen auf der Fritzbox. Kannst du mir (evtl. per PM) mal ein paar Beispiele geben, welche Anwendungsfälle du da konfiguriert hast und wie? Gerade geht alle Zeit in die Komplettüberarbeitung von Signalbot inkl. pull requests für signal-cli drauf, da will ich mich gerade nicht mühsam einlesen :)
Jörg
Ja gerne. PN geht gleich raus...
VG Sebastian
Hi Jörg!
Bin gerade nochmal über etwas gestolpert:
Über die "Commands" löse ich bei mir via "trigger" ein Notify aus. Aus diesem möchte ich nun z. B. das Bild einer Webcam zurückschicken. Dafür brauche ich aber den Zugriff auf auf das "msgSender" Reading, um das Bild zurücksenden zu können.
Da wäre es schon wichtig, wenn die Readings auch aktualisiert werden, wenn ein "Command" reinkommt.
VG, weini
PS: Wenn du das
Zitat von: Adimarantis am 28 Februar 2021, 21:32:15
Muss ich mir nochmal überlegen. Grundsätzlich ja kein Problem - man müsste nur den test auf das Kommando in den Zweig nach allowedPeer Test verschieben.
umsetzen würdest, dann wäre die Aktualisierung der Readings quasi ein Abfallprodukt... ;)
Hab die letzten Fehlermeldungen nicht verfolgt - bei mir steigt signal-cli (0.8.0) seit heute früh immer aus.
Error sending message:org.asamk.Signal.Error.Failure: java.util.concurrent.ExecutionExcep
tion: java.lang.AssertionError: Unknown version: 0
https://github.com/AsamK/signal-cli/issues/552 (https://github.com/AsamK/signal-cli/issues/552)
Scheint ein Problem zu geben. Kann's selbst aber gerade nicht mit dem Master-Branch testen.
Just for your information...
Zitat von: Adimarantis am 28 Februar 2021, 23:21:40
Hi Kaufi,
Brich mal an der Stelle ab und schau ob du unter /tmp/signal*.tmp logdateien findest.
Was steht da drin?
Wenn soweit alles installiert ist, kannst du auch mal
sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49xxxx register --voice
direkt ausführen (was anderes macht das Script auch nicht). Dann siehst du eventuelle Fehlermeldungen die das Script versteckt.
Jörg
Hi Jörg,
Danke für den Tipp.
Ich habe gesehen, dass meine Java-Version zu alt war. Habe dann mittels wget http://download.bell-sw.com/java/14+36/bellsoft-jdk14+36-linux-arm32-vfp-hflt-full.deb und sudo apt-get install ./bellsoft-jdk14+36-linux-arm32-vfp-hflt-full.deb eine neue Version installiert. Nun läuft: openjdk version "14" 2020-03-16
Nun bekomme ich leider folgenden Fehler:
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
ERROR App - Error loading or creating state file: Incorrect file format: expected parameter password not found
Hast Du das schonmal gesehen?
Viele Grüße
Kaufi
Hi Kaufi,
Der V2 Fehler ist im Wiki dokumentiert, aber evtl. liegt das an deiner Java Installation. Standardmässig nehme ich eine andere Version.
Ich würde vorschlagen, dass du alle Java Pakete mal entfernst und dann Java nochmal über das Script installierst. Das Script checkt nur ob Java da ist, aber evtl. haben manche Versionen Probleme. Am Besten auch das /opt/signal Verzeichnis vorher auch nochmal löschen und neu installieren lassen.
Jörg
Zitat von: Hausautomat am 01 März 2021, 22:12:44
Scheint ein Problem zu geben. Kann's selbst aber gerade nicht mit dem Master-Branch testen.
Ich hatte das auch als einer meiner Kontakte Signal neu installiert hatte. Schau mal in diesen (geschlossenen) Bug - da steht wie man es auch mit der aktuellen Version wieder hinkriegt falls es das ist.
https://github.com/AsamK/signal-cli/issues/530
Jörg
Zitat von: Adimarantis am 02 März 2021, 09:11:23
Hi Kaufi,
Der V2 Fehler ist im Wiki dokumentiert, aber evtl. liegt das an deiner Java Installation. Standardmässig nehme ich eine andere Version.
Ich würde vorschlagen, dass du alle Java Pakete mal entfernst und dann Java nochmal über das Script installierst. Das Script checkt nur ob Java da ist, aber evtl. haben manche Versionen Probleme. Am Besten auch das /opt/signal Verzeichnis vorher auch nochmal löschen und neu installieren lassen.
Jörg
Hallo Jörg,
vielen Dank für den Hinweis.
Ich habe neben /opt/signal auch /var/lib/signal-cli gelöscht und damit hat sich das Problem mit dem Statefile erledigt.
Das mit den libzkgroup habe ich leider immer noch, obwohl ich /opt/signal bereits mehrfach gelöscht habe.
Hier die Ausgaben gemäßt dem Wiki:
sudo ldconfig -v | grep libzkgroup.so
ldconfig: Path `/lib/arm-linux-gnueabihf' given more than once
ldconfig: Path `/usr/lib/arm-linux-gnueabihf' given more than once
ldconfig: /lib/arm-linux-gnueabihf/ld-2.24.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
==> Was genau soll mir diese Ausgabe sagen? ;)
sudo find / -name libzkgroup.so 2>/dev/null
/tmp/libzkgroup.so
=> Diese Datei habe ich in libzkgroup.so.bak umbenannt, kam jedoch wieder nach dem ich das Installfile erneut habe laufen lassen.
Selbiges gilt für:
sudo find / -name zkgroup-java-*.jar 2>/dev/null
/opt/signal/lib/zkgroup-java-0.7.0.jar
Was könnte ich hier falsch machen?
Schaut das bei dir auch so aus? (bis aufs Datum natürlich)?
unzip -v zkgroup-java-0.7.0.jar | grep libzkgroup.so
681524 Defl:N 303713 55% 2021-02-12 22:17 f8690f9d libzkgroup.so
ls -l zkgroup-java-0.7.0.jar
-rw-r--r-- 1 signal-cli signal-cli 338549 Feb 21 12:04 zkgroup-java-0.7.0.jar
Zitat von: Adimarantis am 02 März 2021, 21:51:53
Schaut das bei dir auch so aus? (bis aufs Datum natürlich)?
unzip -v zkgroup-java-0.7.0.jar | grep libzkgroup.so
681524 Defl:N 303713 55% 2021-02-12 22:17 f8690f9d libzkgroup.so
ls -l zkgroup-java-0.7.0.jar
-rw-r--r-- 1 signal-cli signal-cli 338549 Feb 21 12:04 zkgroup-java-0.7.0.jar
Hi Jörg,
die erste Zeile ja:
pi@raspberrypi:/opt/signal/lib $ unzip -v zkgroup-java-0.7.0.jar | grep libzkgroup.so
681524 Defl:N 303713 55% 2021-02-12 22:17 f8690f9d libzkgroup.soBei der zweiten Abfrage habe ich jedoch eine andere Dateigröße
pi@raspberrypi:/opt/signal/lib $ ls -l zkgroup-java-0.7.0.jar
-rw-r--r-- 1 signal-cli signal-cli 338593 Mar 2 21:25 zkgroup-java-0.7.0.jarViele Grüße
Signalbot V2 Beta Test, Update zu signal-cli 0.8.1Warum gibt es nach so kurzer Zeit schon eine V2?
- Durch ein Problem mit Net::DBus habe ich mich entschieden auf Protocol::DBus umzustellen
- Dadurch musste fast die Hälfte des bisherigen Codes umgeschrieben werden
- Parallel dazu habe ich ein wenig beim signal-cli Projekt mitgearbeitet und einige neue Funktionen eingebracht, die gestern mit der Version 0.8.1 released wurden
- Durch die Masse an Änderungen suche ich erstmal Beta-Tester bevor ich die Version freigebe. Sie ist schon recht gut getestet und läuft seit gestern auch in meiner Produktivumgebung, hat aber sicher noch Bugs.
Welche Vorteile habe ich von dieser Version?
- Es sind viele neue Funktionen bezüglich Handhabung von Gruppen und Kontakten hinzugekommen
- Die ganze Kommunikation läuft jetzt weitgehend asynchron, d.h. FHEM wird nicht blockiert während es auf die Bestätigung wartet, dass z.B. ein "send" korrekt rausgegangen ist (die Rückantwort war schon immer asynchron)
- Dadurch werden die Fehler meistens nicht mehr direkt ausgegeben sondern stehen im "lastError" reading
- Die GoogleAuth Erweiterungen sind natürlich auch mit drin
- Gruppen und Kontakte werden gleich am Anfang aktualisiert. Sollte ein refresh nötig sein, wird dies jetzt immer in den neuen "get" Funktionen gemacht.
- Und natürlich ganz zuletzt: Der potentielle Fehler der das "send" auf manchen System kaputt gemacht hat, ist damit gefixed
- Wer Probleme mit der bisherigen Version hat, sollte es auch wagen diese zu probieren
Details zu den neuen Funktionen in der inline Doku.
Wie steige ich um?
- Einfach den neuen Installer laufen lassen und das neue 50_Signalbot.pm in FHEM kopieren
- Im Installer kann dann die Registrierung natürlich übersprungen werden, ich würde aber auf jeden Fall mal den Test laufenlassen
- Das alte Device in FHEM kann bestehen bleiben, sauberer wäre aber es neu anzulegen (hauptsächlich weil es ein paar Readings nicht mehr gibt, die kann man aber natürlich per deletereading auch von Hand löschen)
- In FHEM auf jeden Fall ein "shutdown restart"
Kann ich wieder zurück wenn es nicht klappt?
- Ja, das sollte grundsätzlich möglich sein. Das alte Net::DBus wird aktuell nicht de-installiert, so dass man eigentlich nur das 50_Signalbot.pm austauschen muss.
- Auf signal-cli 0.8.1 kann man auch mit der alten Version bleiben, es enthält hauptsächlich Erweiterungen und Fixes, ist aber kompatibel
Known issues:
Der Fehler: "Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null" kann ignoriert werden. Er tritt auf wenn mit Profilen ohne Namen (bei Kommunikationspartnern) gearbeitet wird. Ein Fix wird es wohl erst mit der nächsten signal-cli Version geben. Am Besten dafür sorgen dass alle Kontakte auch in ihrem Profil (das ist nicht setContact!) einen Namen gesetzt haben.
7.3.21: Update 2.02-beta (einige Signalbot enhancements, Installer testet jetzt korrekt mit Protocol::DBus)
Gruß,
Jörg
Zitat von: kaufi88 am 03 März 2021, 09:38:26
Bei der zweiten Abfrage habe ich jedoch eine andere Dateigröße
Das besorgt mich jetzt nicht sehr, aber vielleicht kannst du die mal irgendwo hochladen, damit ich die vergleichen (oder sogar mal auf meinem Testsystem einspielen) kann. Bisher sehe ich nicht warum es nicht funktionieren sollte.
Jörg
Ich habe signal-cli 0.8.1 und die Signalbot V2 beta nun installiert - auf den ersten Blick klappt es.
Meine Sendeproblematik war auch mit der vorherigen Signalbot-Version aber mit der signal-cli 0.8.1 schon behoben.
2021.03.03 12:37:09.075 5: Signal: Init:
2021.03.03 12:37:09.075 4: Signal: Protocol::DBus version found 0.16
2021.03.03 12:37:09.786 5: Signal: ASync Dbus Call: version Args:empty
2021.03.03 12:37:09.798 5: Signal: My Dbus Name is :1.51
2021.03.03 12:37:09.819 5: Signal: ASync Calling: version Args:0.8.1
2021.03.03 12:37:09.820 5: Signal: ASync Dbus Call: listNumbers Args:empty
2021.03.03 12:37:09.831 5: Signal: ASync Calling: listNumbers Args:Protocol::DBus::Type::Array=ARRAY(0x5612ad48c658)
2021.03.03 12:37:09.831 5: Signal: Sync Dbus Call: getContactName Args:+49x1
2021.03.03 12:37:09.838 4: Signal: Sync Error for: getContactName
2021.03.03 12:37:09.846 5: Signal: Sync Dbus Call: getContactName Args:+49x2
2021.03.03 12:37:09.848 5: Signal: Sync Dbus Call: getContactName Args:+49x3
2021.03.03 12:37:59.760 3: Signal: Before parse:Test:
2021.03.03 12:37:59.761 4: Signal: sendMessage called for +49123456789::Test
2021.03.03 12:37:59.761 5: Signal: ASync Dbus Call: sendMessage Args:Test,ARRAY(0x5612ad4f2160),ARRAY(0x5612ad4f2208)
2021.03.03 12:38:01.246 5: Signal: ASync Calling: sendMessage Args:1614771479778
2021.03.03 12:38:02.588 5: Signal: Sync Callback: ReceiptReceived Args:1614771479778,+49123456789
2021.03.03 12:38:02.588 5: Signal: Signalbot_receive_callback 1614771479778 +49123456789
Zitat von: Ralli am 03 März 2021, 12:42:46
Ich habe signal-cli 0.8.1 und die Signalbot V2 beta nun installiert - auf den ersten Blick klappt es.
Schon zu hören.
Vielleicht noch ein Nachtrag zum Thema Logging/verbose. Das habe ich jetzt ein wenig systematischer abgestuft
verbose = 5: Internes logging (Funktionsaufrufe und Parameter) - braucht man normalerweise nicht oder nur bei Bedarf (debugging) einschalten
verbose = 4: Warnings und besonders wichtige Funktionsaufrufe - In der Betaphase sicher gut
verbose = 3: Fehlermeldungen , wichtige Meldungen (nicht nicht zwangsläufig fatal sind) - Auch im Normalbetrieb manchmal hilfreich
verbose = 1: Schwerwiegende Fehler - Reicht für den produktiven Betrieb
Gruß,
Jörg
Den ersten Bug habe ich schon selber gefunden :)
Durch den asynchronen Mechanismus hatte ich Bilder schneller gelöscht als verschickt.
Update im oberen Post.
Jetzt hatte sich in dem Fix für die Bilder doch glatt ein böser Fehler eingeschlichen der zu einem FHEM restart führen kann.
Dafür ist im update oben auch noch enthalten, dass die interne Gruppenliste (und das joinedGroups) bei einer Änderung der Gruppe (join,leave,rename..) aktualisiert wird.
Guten morgen Jörg,
bin jetzt auch auf die v2 Beta gegangen, funktioniert soweit, ich habe auch das versenden von Bildern getestet. Danke für das Modul.
2 Fragen:
- Kannst Du evtl eine Versionsnummer mit in die Internals mit aufnehmen? Dann weiss man ob man wirklich mit der 2.0 Beta spricht oder nicht doch mit der alten version
- Kann man das NET:DBUS auch wieder löschen, ohne sich irgendwas kaputtzuschiessen, und wenn ja - wie?
Beste Gruesse, Jamo!
Hi Jamo,
Perl Module lassen sich wohl nur mit dem "cpanminus" Befehl deinstallieren. Das müsstest du dann möglicherweise erst installieren (sudo apt-get install cpanminus)
Dann sollte das mit
sudo cpanm --uninstall Net::DBus
gehen. Das deinstalliert aber nur den inhalt der Verzeichnisse
/usr/local/lib/arm-linux-gnueabihf/perl/5.28.1/Net/DBus*
/usr/local/man/man3/Net::DBus*
Wenn du cpanm nicht sowieso auf deinem System hast, musst du dafür so viele neue Pakete installieren, dass das sicher nicht lohnt. Da ist ein "rm" wahrscheinlich besser
Desweiteren braucht man wohl diese Pakete nicht mehr:
sudo apt remove libexpat1-dev libxml-parser-perl libtemplate-perl libxml-xpath-perl xml-twig-tools
sudo apt autoremove
Außerdem wird "gcc" für die Net::DBus installation installiert. Wer den nicht braucht, kann den auch gefahrlos entfernen.
Eventuell noch weitere, aber da muss ich noch Experimente mit der Dockerumgebung machen.
Versionsnummer: Ja, macht Sinn. Signal-Cli ist da ja auch inzwischen drin - wobei das dann beides wohl eher in die internal readings gehört. Vielleicht einfach ein String mit allen Versionsnummer damits nicht so viele Zeilen gibt.
Jörg
Hallo Jörg,
danke, ich habe die Verzeichnisse jetzt manuell entfernt. Das "sudo apt remove libexpat1-dev libxml-parser-perl libtemplate-perl libxml-xpath-perl xml-twig-tools" entferne dann doch noch einige andere Pakete, die woanders gebraucht werden.
Versionsnummer: Danke, das ist prima und würde Dir wahrscheinlich auch helfen, wenn einer einen Fehler meldet.
Beste Grüsse, Jamo
Zitat von: Adimarantis am 03 März 2021, 10:24:05
Signalbot V2 Beta Test, Update zu signal-cli 0.8.1
Der Fehler: "Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null" kann ignoriert werden. Er tritt auf wenn mit Profilen ohne Namen (bei Kommunikationspartnern) gearbeitet wird. Ein Fix wird es wohl erst mit der nächsten signal-cli Version geben. Am Besten dafür sorgen dass alle Kontakte auch in ihrem Profil (das ist nicht setContact!) einen Namen gesetzt haben.
Gruß,
Jörg
Hallo Jörg,
hier auch soweit alles bene. Musste allerdings neu registrieren. Und hab demzufolge auch den o.g. Fehler bekommen.
Aber sonst alles OK.
Um den Hinweis von Jamo aufzunehmen: Du könntest auch die Version von 50_Signalbot.pm als INTERNAL zur
Verfügung stellen. Dann hast du wirklich alles Infos wenn es mal bei jemandem hakt.
VG Sebastian
Hallo Jörg,
habe auch gleich mal die Beta2 probiert, installer läuft ohne Probleme durch (habe NICHT neu registriert)....(ok, nachdem ich die TelNr. im Script geändert hatte gings dann. Muss ich mich dran gewöhnen...)
Ich habe jetzt gerade den Bilderversand getestet, aber das klappt nicht. Es kommt gar nichts an, im lastError Reading steht:
Error in sendMessage:/tmp/signalbot1614874881.61289.jpg: /tmp/signalbot1614874881.61289.jpg (No such file or directory)
und mit verbose5 steht das im Log:
2021.03.04 17:21:21.612 3: mySignalBot: Before parse:@S &/opt/fhem/www/snapshots/CamEinfahrt_snapshot.jpg:
2021.03.04 17:21:21.616 4: mySignalBot: sendMessage called for S:/tmp/signalbot1614874881.61289.jpg:
2021.03.04 17:21:21.617 5: mySignalBot: ASync Dbus Call: sendMessage Args:,ARRAY(0x5559addc1a58),ARRAY(0x5559acc1a098)
2021.03.04 17:21:21.623 4: mySignalBot: ASync Error for: sendMessageSieht nach Deiner Fehlerbeschreibung
ZitatDen ersten Bug habe ich schon selber gefunden :)
Durch den asynchronen Mechanismus hatte ich Bilder schneller gelöscht als verschickt.
Update im oberen Post.
aus,
ich nutze die neuesete SignalBot.pm (55190bytes, Mar 3 12:45) und Neustart ist gemacht.
Gruß
Sany
@Sany: Das mit dem Bilder muss eigentlich gehen. Ich habe jetzt die Version im Post mit derjenigen ersetzt die Versionsnummern anzeigt. Bitte nochmal aktualisieren.
Im internal Reading VERSION muss dann 2.0.1-beta stehen. (ich mach jetzt mal Unterschritte in der Hoffnung das die 2.1 dann Release wird).
@binford: Neuregistrierung sollte eigentlich nicht nötig sein. Die Fehlermeldung kommt übrigens dann, wenn ANDERE in Signal keinen Profilnamen gesetzt haben, sollte aber weg sein, wenn man diesem Anwender mit setContact einen eigenen Kontaktnamen gibt.
Jörg
@Jörg,
Bild schicken klappt jetzt wieder. Und vielen Dank für die VERSION-Anzeige:
VERSION Signalbot:2.0.1-beta signal-cli:0.8.1 Protocol::DBus:0.16
macht es übersichtlicher :)
Viele Grüße
Sany
Und noch eine Bitte:
Bitte die aktuellen Versionen immer im ersten Beitrag verlinken, nicht mittendrin - mittendrin am besten überall raus holen.
Zitat von: Adimarantis am 04 März 2021, 18:05:25
@binford: Neuregistrierung sollte eigentlich nicht nötig sein. Die Fehlermeldung kommt übrigens dann, wenn ANDERE in Signal keinen Profilnamen gesetzt haben, sollte aber weg sein, wenn man diesem Anwender mit setContact einen eigenen Kontaktnamen gibt.
Moin Jörg,
doch ich musste neu registrieren. Komisch... :o
Heute morgen habe ich die letzte Version eingespielt:
VERSION
Signalbot:2.0.1-beta signal-cli:0.8.1 Protocol::DBus:0.16 Danach eine Nachricht an mich:
sentMsg hallo 2021-03-05 08:20:13Und kurze Zeit später wieder der Fehler:
lastError Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null
2021-03-05 08:21:03Die Nachricht geht ganz normal durch und der Peer ist bekannt und hat einen Namen und alles...
Was mir noch aufgefallen ist: In der Signal App hatte ich nur meinen Vornamen + ein Emoji gesetzt.
Der Nachname war leer. Vielleicht liegts daran...
Jetzt muss ich nur noch meine nextcloud Two-Factor App auf Signal umstellen und dann kann Telegram
in Rente gehen ;)
VG Sebastian
Hi Sebastian,
Zitat von: binford6000 am 05 März 2021, 08:32:33
Der Nachname war leer. Vielleicht liegts daran...
Der Fall ist eigentlich explizit in signal-cli abgebildet... wobei gestest hab ichs nicht.
Wenn du verbose 5 machst, dann solltest du bei einem "get contacts all" folgende Zeilen im Logfile sehen:
2021.03.02 22:23:59 5: SignalBot: Sync Dbus Call: getContactName Args:+49xxxxxxxx
2021.03.02 22:23:59 4: SignalBot: Sync Error for: getContactNameJeweils die Zeile vor dem "Sync Error" sollte dir sagen, welche Nummer Probleme macht. Wenn du dann ein setContact machst um der Nummer einen Namen zu geben, sollte das Problem eigentlich weg sein.
Ich diskutiere mit dem signal-cli Author gerade einen Fix für das Problem, aber wir sind uns noch nicht einig :) Hilft aber unmittelbar eh nichts, weil es dann erst in die 0.8.2 kommen würde.
Jörg
Hier die Ausgabe:
2021.03.05 13:17:14 5: signalbot: Sync Dbus Call: listNumbers Args:empty
2021.03.05 13:17:14 5: signalbot: Sync Dbus Call: isContactBlocked Args:+49...
2021.03.05 13:17:14 5: signalbot: Sync Dbus Call: isContactBlocked Args:+49...
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: getGroupIds Args:empty
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: getGroupName Args:ARRAY(0x563c26fe1690)
2021.03.05 13:17:19 5: found group Tigers
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: isMember Args:ARRAY(0x563c26fe1690)
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: isGroupBlocked Args:ARRAY(0x563c26fe1690)
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: getGroupMembers Args:ARRAY(0x563c27605db0)
2021.03.05 13:17:19 5: signalbot: Sync Dbus Call: getContactName Args:+49...
2021.03.05 13:17:19 4: signalbot: Sync Error for: getContactName
Und die passende Fehlermeldung:
lastError Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null 2021-03-05 13:17:19
Weder die Kontakte noch die Gruppe ist natürlich blocked...
Wie gesagt funktioniert auch alles soweit.
Hallo Jörg!
Bin immer mehr beindruckt von deiner Geschwindigkeit und Qualität!
Ich habe auf die Beta-2 mit signal-cli 0.8.1 umgestellt. Bei der Intallation (sudo signal_install.sh system) wurde bei mir das "Protocol dBus" Perl Modul nicht installiert. Bin mir nicht sicher, ob das hätte passieren sollen. Die Fehlermeldung im FHEM Modul ist aber sehr klar, insofern war die Nachinstallation kein Problem.
1000 Dank dir für das generelle Refactoring, so dass auch Commands jetzt die Readings aktualisieren und vor allem grundsätzlich der allowedPeer geprüft wird.
Ich habe ein generisches notify aufgebaut, dass die Differenzierung von authorisierten und nicht-authorisierten Commands abbildet und zusätzlich eine Favoritendefinition erlaubt. Dazu nutze ich user-defined Attribute auf dem signalblot Device.
Ich kann den Code neben einer Beschreibung entweder hier posten oder im Wiki-Artikel als ergänzenden Use Case mit aufnehmen. Wäre dir letzteres recht?
VG,
weini
Zitat von: weini am 06 März 2021, 11:07:26
Bin immer mehr beindruckt von deiner Geschwindigkeit und Qualität!
Danke für die Blumen.
Zitat
Ich kann den Code neben einer Beschreibung entweder hier posten oder im Wiki-Artikel als ergänzenden Use Case mit aufnehmen. Wäre dir letzteres recht?
Da können wir gerne ein Kapitel im Wiki machen - alles was längerfristig interessant ist, sollte dort landen - im Thread findet man hinterher nichts mehr.
Jörg
Hi Jörg!
Habe den Wiki Eintrag ergänzt. Bitte gerne um Feedback, wenn etwas überarbeitet werden soll.
VG,
weini
Hallo Jörg,
die Beta läuft bei mir stabil, nichts dran auszusetzen, alle Messages kommen wie gewünscht. (Manchmal auf dem Handy etwas später, vermute das liegt am Powermanagement (Android), muss ich noch ergründen.
Was mir noch aufgefallen ist sind Zeilenumbrüche:
Wenn ich direkt im Signabot-Device oder z.B. aus einem DOIF heraus ein
set signalBot send Zeile1\nZeile2\nZeile3\nZeile4 sende wird nur der erste Zeilenumbruch durchgeführt, bei allen danach steht dann ein n mit im Text.
Wenn ich z.B. in einem DOIF erst einer Variablen den Text zuweise und dann sende kommt alles wie gewünscht in mehreren Zeilen. Irgendwo geht da der Escape-backslash verloren.
Ansonsten: tolles Modul, kommt sicher bald ins fhem-update ;)
Viele Grüße :)
Sany
Kleines Update 2.02-beta im Original Post : https://forum.fhem.de/index.php/topic,118370.msg1136873.html#msg1136873
- Mehrere \n im send sollten jetzt korrekt funktionieren
- Verbesserung der Formatierung vom getGroup (lange Gruppennamen werden abgeschnitten, lange Memberlisten umgebrochen)
- Experimenteller Support für mehrere Accounts
- Kleinere Fixes
Anmerkung zu den Multi-Accounts:
Wenn man mehrere Nummern unter signal-cli definiert und beim Start des Daemons den -u Parameter weglässt, dann werden alle Accounts unter speziellen DBus-Pfaden aktiv. Achtung: Der Standard-Pfad funktioniert dann aber gar nicht mehr und damit ging bisher Signalbot auch nicht.
Jetzt kann man für diesen Fall die Telefonnummer an das "define" anhängen und sogar mehrere Instanzen erzeugen die auf unterschiedliche Nummern hören.
Ich hoffe das ich da noch Änderungen in signal-cli einbringen kann, die das Verhalten etwas deterministischer machen (z.B. dann eine Master Instanz, die zwar nicht verbunden ist, aber gewisse Grundfunktionalität wieder Auflistung der Accounts und möglichst sogar die Registrierung anbietet).
Gruß,
Jörg
kurze Rückmeldung zu 2.02beta:
- installer läuft problemlos durch
- mehrere zeilenumbrüche funktionieren wie gewünscht.
die anderen Änderungen treffen für mich nicht zu.
Viele Grüße und vielen Dank
Sany
Hallo!
Finde ich ganz klasse, hat gleich mal Pushbullet ersetzt! Viel schneller&zuverlässiger&einfacher - wenns einmal installiert ist. Das Script ist auch gut, aber bei mir wollte es ein Captcha - vermutlich weil österreichische IP aber deutsche Telefonnummer. Reine Spekulation natürlich.
Aaber: seit ich die Beta 2.0.1 installiert habe ist der Speicherverbrauch auch von fhem selber (also nicht nur die knapp 400 mb durch die cli) deutlich gestiegen. Hat meinen Raspi 3 mit den standard 100Mb Swap File verlässlich in den Tod getrieben (zwischen 13-15 Minuten nach Reboot). Mit 1024 Mb Swap war es viel besser, hat ca 3h durchgehalten. Dann ist mir der Geduldsfaden gerissen und ich hab 8GB Swap angelegt, seither ist Ruhe...
Nur so als Feedback und potentielle Hilfe für andere
Lg
Matthias
Zitat von: Mad-at am 08 März 2021, 16:44:45
seit ich die Beta 2.0.1 installiert habe ist der Speicherverbrauch auch von fhem selber (also nicht nur die knapp 400 mb durch die cli) deutlich gestiegen.
Das ist seltsam. Ich hätte hier sogar einen umgekehrten Trend erwartet.
Mein Produktivsystem (FHEM+PiVCCU+ffmpeg IPcam Prozess+signal-cli+pi-hole) läuft auf meinem Pi4 mit 1.0/4.0 GB RAM - der 100MB! Swap ist zwar voll, aber sagt ja nichts.
Mein Testsystem (FHEM+signal-cli) hat aktuell 570MB/4.0GB RAM und 0/100MB Swap. Der Raspi 3 hat doch 1GB, oder? D.h. der sollte das schon noch packen.
Beide laufen seit 11 Tagen ohne reboot (da hatte ich mal wieder alle Updates laufen lassen).
Also ich kann dein Speicherproblem nicht wirklich nachvollziehen. Hat sonst noch jemand Erfahrungswerte dazu?
Jörg
Ja der hat 1GB
Aber ehrlicherweise: der arme Pi muss auch bei mir mehr als nur FHEM stemmen: emonhub, Pihole und unbound laufen auch.
Trotzdem ja, finde es auch strange. Ich hatte v1 aber auch nicht sehr lange laufen bis ich Deine beta entdeckt habe, vielleicht wärs unter der auch aufgelaufen? Keine Ahnung.
Also wenn ich bei mir auf den Speicher schaue, dann ist FHEM ferner liefen beim Speicherverbrauch. Das deckt sich mit meiner Vermutung das Signalbot von V1 auf V2 eigentlich eher sogar weniger Speicher braucht (und definitiv weniger als SiSi weil es keinen fork() Prozess braucht).
Ganz vorne ist allerdings signal-cli - und das ist ja ein Java Prozess - und Java bedient sich gerne großzügig und räumt nur auf wenn es muss.
Du könntest mal probieren, ob du Java den Speicherhunger abgewöhnst indem du den maximalen Heap beschränkst.
Das geht mit z.B. mit
-Xmx256m
Keine Ahnung wie weit man da runtergehen kann bevor es "Out of Memory" gibt, aber eigentlich sollte signal-cli nicht so wahnsinnig viel brauchen.
Dazu musst du
/etc/systemd/system/signal.service
editieren und die Zeile mit Environment z.B. so ändern:
Environment="SIGNAL_CLI_OPTS=-Xms2m -Xmx256m"
Kannst das ja mal versuchen auszureizen und hier posten wie weit man das treiben kann.
Jörg
Ok, werds ausprobieren! Merci!
Moin Jörg,
Signalbot:2.0.2-beta signal-cli:0.8.1 Protocol::DBus:0.16
Ich habe komplett neu installiert und registriert. Alles ohne Probleme. Funktioniert wie vorher auch schon. Speicher beobachte ich auch mal mit einem Auge. Das Problem mit den Zeilenumbrüchen hatte ich auch. Hatte da aber den Fehler bei mir gesucht nun ist es aber auch gelöst :)
Gruss
Enno
Hallo Jörg,
als erstes vielen Dank für das tolle Modul, ich habe dieses von Anfang an auf 2 von einander unabhängigen Instanzen laufen.
Vor ein paar Tagen bin ich mit der ersten Intstanz zu der Beta 2.0.2 gewechselt und diese läuft absolut problemlos, da habe ich auch die zweite Instanz umgestellt.
Die zweite instanz hat leider nur einige Stunden funktioniert, seit gestern bekomme ich keine messages über Signalbot mehr.
Das Device hat eine Fehlermeldung
Error in sendMessage:java.net.ConnectException: Failed to connect to textsecure-service.whispersystems.org/2001:0:0:0:0:0:453f:b88f:443
Und im Log mit Verbose 5 ist nur folgendes zu sehen:
2021.03.17 20:11:15 3: Signal: Before parse:Test:
2021.03.17 20:11:15 4: Signal: sendMessage called for +49********::Test
2021.03.17 20:11:15 5: Signal: ASync Dbus Call: sendMessage Args:Test,ARRAY(0x55ed19b70bf8),ARRAY(0x55ed19b70ca0)
2021.03.17 20:12:25 4: Signal: ASync Error for: sendMessage
Hier ein List des Devices:
Internals:
FD 42
FUUID 6021287d-f33f-69d4-45c7-7481c476484bec0d
NAME Signal
NOTIFYDEV global
NR 221
NTFY_ORDER 50-Signal
STATE Connected
TYPE Signalbot
VERSION Signalbot:2.0.2-beta signal-cli:0.8.1 Protocol::DBus:0.16
Helper:
DBLOG:
lastError:
logdb:
TIME 1615983145.86363
VALUE Error in sendMessage:java.net.ConnectException
READINGS:
2021-02-08 20:04:12 joinedGroups
2021-03-17 20:12:25 lastError Error in sendMessage:java.net.ConnectException: Failed to connect to textsecure-service.whispersystems.org/2001:0:0:0:0:0:453f:b88f:443
2021-03-17 20:11:15 sentMsg Test
2021-03-17 05:59:10 sentMsgRecipient XXXXXXX
2021-03-17 20:11:15 sentMsgTimestamp pending
helper:
init :1.67
signalpath /org/asamk/Signal
version 801
attachments:
contacts:
+49********* XXXXXX
Attributes:
allowedPeer +49*********
defaultPeer +49*********
devStateIcon .*Connected:fa_comments@green .*Disconnected:fa_comments@red
room Kommunikation
verbose 5
Was kann ich da tun?
Gruß
Alex
Zitat von: Nighthawk am 17 März 2021, 13:28:49
Was kann ich da tun?
Schaut erstmal eher nach einem signal-cli Problem aus. Ein paar Ansätze:
1. Hast du unterschiedliche Nummern registriert (mit einer kopierten Registrierung wird es nicht funktionieren)
2. In der Fehlermeldung ist eine IPV6 Adresse. Ich wüsste zwar nicht das signal-cli damit ein Problem hat, aber kannst du prüfen ob die beiden Systeme bzgl. IPV4 vs IPV6 anders konfiguiert sind?
3. Schau mal ins /var/log/syslog ob da irgendwas aufschlussreiches steht
4. Starte mal das Install Script mit Option "test" ob die 3 tests auf der Ebene funktionieren
Gruß,
Jörg
Hallo Jörg,
danke für deine Rückmeldung.
Zu 1. auf dem Problemsystem ist nur eine Nummer registriert, diese hatte ich auf dem gleichen System vorher mit der ersten Version des Signalbot am laufen und es hat ja auch einige Stunden mit der Beta 2.0.2 funktioniert.
Zu 2. der Unterschied der Systeme ist, das funktionierende sitzt hiter einer Fritzbox, das mit Aussetzer sitzt hinter einem größeren Server mit NAT.
Zu 3. die Logs schaue ich mir nachher noch genauer an.
Zu 4. der Test hatte nach der Installation auf Anhieb funktioniert, ich füher es heute nochmal aus und schau mal was da passiert.
Gruß
Alex
Hallo Jörg,
im Syslog sind nur die 2 folgenden Einträge zu finden:
signal-cli[1579]: WARN Manager - Failed to get sender certificate, ignoring: java.net.ConnectException: Failed to connect to textsecure-service.whispersystems.org/2001:0:0:0:0:0:4a75:b29a:443
signal-cli[1579]: WARN Manager - Failed to retrieve profile, ignoring: java.util.concurrent.TimeoutException
Seltsam ist, dass es manchmal von alleine wieder funktioniert (hat den ganze Freitag tadellos seinen Dienst verrichtet) und dann schlagartig wieder nicht.
Gruß
Alex
Moin,
nachdem mir auffiel seit ein paar Tagen keine Nachrichten mehr per Signalbot zu bekommen habe ich die aktuellen Dateien signalbot und installer mir wieder geholt und danach signal_install.sh mit system, install und test aufgerufen.
Bei Test bekam ich folgenden output:
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.0
System library path: /usr/lib
Phone number to be used: +49623XXXXX
You seem to run Ubuntu on x86_64
Your chose the following option: test
Please enter the number (+49...) of somebody that you can send a test message to
Number:+4915114139958
Sending a message from command line to +4915YYYY
Stopping signal-cli service
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
Failed to send/receive message (Assertion): Unknown version: 0
java.lang.AssertionError: Unknown version: 0
at org.whispersystems.signalservice.internal.push.PushTransportDetails.getPaddedMessageBody(PushTransportDetails.java:45)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.encrypt(SignalServiceCipher.java:94)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:1729)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:1689)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1534)
at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:316)
at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1417)
at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1345)
at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1008)
at org.asamk.signal.dbus.DbusSignalImpl.sendMessage(DbusSignalImpl.java:90)
at org.asamk.signal.commands.SendCommand.handleCommand(SendCommand.java:134)
at org.asamk.signal.commands.DbusCommand.handleCommand(DbusCommand.java:14)
at org.asamk.signal.App.handleLocalCommand(App.java:211)
at org.asamk.signal.App.init(App.java:169)
at org.asamk.signal.Main.main(Main.java:43)
If you use an Oracle JRE please check if you have unlimited strength crypto enabled, see README
Start signal-cli service
Sending a message via dbus-send command
Error org.freedesktop.dbus.exceptions.DBusExecutionException: Error Executing Method org.asamk.Signal.sendMessage: Unknown version: 0
Sending a message via perl Net::DBus
org.freedesktop.dbus.exceptions.DBusExecutionException: Error Executing Method org.asamk.Signal.sendMessage: Unknown version: 0
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
(die xxx und yyy sind natürlich richtige Nummern die auch funktionieren).
Das unterliegende ubuntu ist aktuell.
Was könnte da falsch laufen?
Viele Grüße
Marco
Zitat von: Nighthawk am 21 März 2021, 13:12:00
Failed to connect to textsecure-service.whispersystems.org/2001:0:0:0:0:0:4a75:b29a:443
Also für mich schaut das nach einem generellen Verbindungsproblem zum Signal Server aus. Check bei Problemen mal ob du textsecure-service.whispersystems.org anpingen kannst. Das ist irgendwo auf der System/Netzwerkebene und meiner Meinung nach kein Problem von signal-cli oder Signalbot.
Jörg
Zitat von: MarcoE am 22 März 2021, 10:17:26
Failed to send/receive message (Assertion): Unknown version: 0
Haben deine Profile einen Usernamen (set updateProfile ...) , so einen Fehler habe ich meine ich schon gesehen, wenn die Nummer keinen definierten Namen hat.
Du bist noch auf der alten signal-cli Version - vielleicht solltest du probieren auf 0.8.1 und Signalbot V2-beta zu gehen (werde ich demnächst ohne große Änderungen als nicht-beta releasen, muss nur noch mal dazu kommen zu testen, welche Pakete der Installer jetzt wirklich braucht)
Jörg
Hallo,
Zitat von: Adimarantis am 22 März 2021, 10:57:16
Haben deine Profile einen Usernamen (set updateProfile ...) , so einen Fehler habe ich meine ich schon gesehen, wenn die Nummer keinen definierten Namen hat.
Du bist noch auf der alten signal-cli Version - vielleicht solltest du probieren auf 0.8.1 und Signalbot V2-beta zu gehen (werde ich demnächst ohne große Änderungen als nicht-beta releasen, muss nur noch mal dazu kommen zu testen, welche Pakete der Installer jetzt wirklich braucht)
Jörg
Der Fehler tritt schon auf shell Ebene auf. bei signal_install test. Oder gibt es da auch einen updateProfile?
Ich bin auf der Version die hier auf Seite 1 (für 50_Signalbot) verlinkt ist. Was muß ich noch updaten? Oder woher bekomme ich neueres?
Viele Grüße
Marco
Beta release ist hier: https://forum.fhem.de/index.php/topic,118370.msg1136873.html#msg1136873
Sobald ich dazu komme es endgültig zu releasen, kommt die in den ersten Post.
Das Script hat eine Option "name" mit der man von dort den Namen setzen kann.
Nachdem die Beta jetzt schon lange genug bei mir und anderen im Einsatz ist habe ich die neue Version (nahezu unverändert) als V2.1 im ersten Post freigegeben.
Ich hoffe mir sind da keine last-minute Schnitzer reingekommen. Derzeit bin ich leider anderweitig sehr beschäftigt und weiß auch nicht wann ich dazu komme die Anleitung im Wiki upzudaten (Hilfe erwünscht :) )
Gruß,
Jörg
Hallo,
Zitat von: Adimarantis am 22 März 2021, 18:12:11
Beta release ist hier: https://forum.fhem.de/index.php/topic,118370.msg1136873.html#msg1136873
Sobald ich dazu komme es endgültig zu releasen, kommt die in den ersten Post.
Das Script hat eine Option "name" mit der man von dort den Namen setzen kann.
Danke! Habe nun auf die beta umgestellt. Jetzt im Moment funktioniert es- ich hoffe es bleibt so.
Viele Grüße
Marco
Hallo Joerg,
leider bekomme ich keinen Hacken an das Problem.
Vor der Umstellung auf Beta 2 und 0.8.1 hat Signalbot klaglos seinen Dienst verrichtet.
Ich würde gerne testen ob es tatsächlich an der Umstellung liegt und nicht an einer potentiell veränderten Netzwerkstruktur.
Was müsste ich genau tun (neben dem zurückkopieren der 50_Signalbot.pm) um auf NET::DBUS zurückzukehren ?
Gruß
Alex
Hi Alex,
der Fehler liegt eindeutig auf der Ebene signal-cli/signal - wenn Signalbot oder das Net::DBus/Protocol::Dbus schon ein Problem hätte, würdest du nichts im syslog finden.
Ich kann jetzt nur vaage vermuten, dass irgendwas mit der Registrierung nicht stimmt.
Eventuell mal komplett den Inhalt von /var/lib/signal-cli löschen und mit dem Installer die Nummer neu registrieren.
Jörg
Hallo Jörg,
eine falsche, oder defekte Registrierung würde doch dazu führen dass es gar nicht funktioniert, in meinem Fall funktioniert es immer mal wieder für einige Stunden und dann wieder nicht.
Ich fürchte das wird an der "brutalen" NAT liegen hinter der ich sitze, leider habe ich auf diese absolut keinen Einfluss :-(
Gruß
Alex
Zitat von: Adimarantis am 03 März 2021, 12:25:26
Das besorgt mich jetzt nicht sehr, aber vielleicht kannst du die mal irgendwo hochladen, damit ich die vergleichen (oder sogar mal auf meinem Testsystem einspielen) kann. Bisher sehe ich nicht warum es nicht funktionieren sollte.
Jörg
Hallo Jörg,
ich hatte die letzten Tagen viel um die Ohren und konnte jetzt die Feiertage nutzen.
Heute habe ich dann die neuste Version von Dir installiert, habe auch gesehen dass er Singal-CLI 0.81 herunterladen hat.
Jedoch habe ich das selbige Problem.
Die Datei zkgroup-java-0.7.0.jar wurde auch angefasst. Du findest diese hier: http://www.intespa.de/zkgroup-java-0.7.0.jar
Hier noch die Ausgabe vom Install-Skript:
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.1
System library path: /usr/lib
Phone number to be used: +49xxxx
You seem to be on a Raspberry pi with armv7l
This will update system packages, install signal-cli and help to register with Signal service
[....]
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for qrencode...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for Protocol::DBus...V0.16 found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.8.0
Update to current version (y/N)? y
Proceed with signal cli installation
Downloading signal-cli 0.8.1...done
Unpacking ...
Downloading native armv7l libraries...
done
Updating native x86 since you're on Raspberry...updating: libzkgroup.so (deflated 55%)
updating: libsignal_jni.so (deflated 53%)
done
done
Changing file ownership ...done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
11c11
< ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli -u "+49zzzzzzzzz" daemon --system
---
> ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli -u "+49xxxx" daemon --system
/etc/systemd/system/signal.service differs, update (Y/n)?
n
/etc/systemd/system/signal.service left untouched
You already seem to have a device configured, add +49xxxx additionally?
Continue (y) or skip (N)?N
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49174yyyyyyyyyyyyy
Sending a message from command line to +49174yyyyyyyyyyyyyyy
Stopping signal-cli service
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Invalid username (phone number), make sure you include the country code.
Start signal-cli service
Sending a message via dbus-send command
method return time=1617526008.746986 sender=:1.2620 -> destination=:1.2621 serial=5 reply_serial=2
int64 1617526007446
Sending a message via perl Protocol::DBus
Message received
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
pi@raspberrypi:/tmp $ cd /opt/signal/lib
Folgende Datei habe ich Dir hochgeladen:
pi@raspberrypi:/tmp $ sudo find / -name zkgroup-java-*.jar 2>/dev/null
/opt/signal/lib/zkgroup-java-0.7.0.jar
Viele Grüße & Danke
Kaufi
Hi Kaufi,
Inhaltlich ist dein .jar mit meinem identisch. Seltsamerweise stimmt die Dateigröße des komprimierten .jar nicht überein, was jetzt aber nicht unbedingt was heißen muss. (evtl. verhält sich ja "zip" beim re-pack nicht deterministisch)
Ich hänge mal meine Version an. Probiere die mal aus.
Gruß,
Jörg
Zitat von: Adimarantis am 04 April 2021, 21:01:27
Hi Kaufi,
Inhaltlich ist dein .jar mit meinem identisch. Seltsamerweise stimmt die Dateigröße des komprimierten .jar nicht überein, was jetzt aber nicht unbedingt was heißen muss. (evtl. verhält sich ja "zip" beim re-pack nicht deterministisch)
Ich hänge mal meine Version an. Probiere die mal aus.
Gruß,
Jörg
Hallo Jörg,
vielen Dank für Dein File.
Hat leider auch nicht zum Erfolg geführt.
Kann es evtl. an der Java-Version liegen?
Diese hier hab ich installiert:
pi@raspberrypi:/tmp $ java -version
openjdk version "11.0.3" 2019-04-16 LTS
OpenJDK Runtime Environment Zulu11.31+16-CA (build 11.0.3+7-LTS)
OpenJDK Client VM Zulu11.31+16-CA (build 11.0.3+7-LTS, mixed mode)
Grüße
Kaufi
Hi Kaufi,
kann natürlich grundsätzlich an Java liegen. Bei mir ist folgendes installiert:
pi@raspberrypi4:~ $ java --version
openjdk 11.0.9.1 2020-11-04
OpenJDK Runtime Environment (build 11.0.9.1+1-post-Raspbian-1deb10u2)
OpenJDK Server VM (build 11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode)
Jörg
Ich habe jetzt das Wiki entsprechend der V2 überarbeitet: https://wiki.fhem.de/wiki/Signalbot
Verbesserungsvorschläge willkommen (oder wer Schreibrechte hat, darf kleine Korrekturen gerne selbst vornehmen).
Jörg
Hi Jörg,
fhem stürzt reproduzierbar wegen Signal bei mir ab, mit folgendem Eintrag im Log (verbose 5):
Ich hatte mal Babble benutzt, habe aber babble bei mir vor 2 Tagen wieder gelöscht. Die attribute im Signal hatte ich aber stehen lassen, liegts daran?
Dann müsste evtl noch ein check rein, ob es das babble device wirklich gibt, falls die Attribute gesetzt sind.
PS: Nach Löschen der babble attribute stürzt fhem nicht mehr ab, also lag es daran.
2021.04.08 09:38:57 5: Starting notify loop for Signal, 1 event(s), first is msgText: L
2021.04.08 09:38:57 5: BatterieWechsel: not on any display, ignoring notify
2021.04.08 09:38:57 5: Batteriestatus: not on any display, ignoring notify
2021.04.08 09:38:57 5: Triggering Signal_n
2021.04.08 09:38:57 4: Signal_n exec {mySignal_n($NAME,$EVENT)}
2021.04.08 09:38:57 5: Cmd: >{mySignal_n($NAME,$EVENT)}<
2021.04.08 09:38:57 3: [mySignal_n] N=Signal, E=msgText: L, input=l, sender=+4915123456789, words=1
2021.04.08 09:38:57 5: Cmd: >set Signal send @+4915123456789 Usage: \"Cxx 2FAToken\"<
2021.04.08 09:38:57 5: End notify loop for Signal
Undefined subroutine &main::Babble_DoIt called at ./FHEM/50_Signalbot.pm line 565.
2021.04.08 09:38:57 0: SONOS0: Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch...
2021.04.08 09:40:28 1: Including fhem.cfg
List:
Internals:
FD 54
NAME Signal
NOTIFYDEV global
NR 3290
NTFY_ORDER 50-Signal
STATE Connected
TYPE Signalbot
VERSION Signalbot:2.1 signal-cli:0.8.1 Protocol::DBus:0.16
READINGS:
2021-03-04 18:13:01 joinedGroups
2021-04-08 09:40:40 lastError Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null
2021-03-23 12:55:52 msgAttachment
2021-03-23 12:55:52 msgAuth 0
2021-03-23 12:55:52 msgGroupName
2021-03-23 12:55:52 msgSender Hans Jamo
2021-03-23 12:55:52 msgText RR123456789DE
2021-03-23 12:55:52 msgTimestamp 23-03-2021 12:55:50
2021-03-23 12:55:52 prevMsgAttachment
2021-03-23 12:55:52 prevMsgGroupName
2021-03-23 12:55:52 prevMsgSender Hans Jamo
2021-03-23 12:55:52 prevMsgText C02
2021-03-23 12:55:52 prevMsgTimestamp 14-03-2021 21:58:20
2021-04-02 11:43:52 sentMsg wall_e: Docked
2021-04-05 20:15:07 sentMsgRecipient Hans Jamo
2021-04-05 20:15:07 sentMsgTimestamp 02-04-2021 11:43:52
helper:
init :1.6445
signalpath /org/asamk/Signal
version 801
contacts:
+4915123456789 Hans Jamo
Attributes:
allowedPeer +4915123456789
babbleDev Babble
babbleExclude ^p$|^P$|^c|^C
babblePeer +4915123456789
defaultPeer +4915123456789
doLog 1
event-on-update-reading msgText
room Messages
userattr doLog:0,1
verbose 0
webCmd reconnect
Hi Jamo,
Zitat von: Jamo am 08 April 2021, 09:44:09
Dann müsste evtl noch ein check rein, ob es das babble device wirklich gibt, falls die Attribute gesetzt sind.
PS: Nach Löschen der babble attribute stürzt fhem nicht mehr ab, also lag es daran.
ja, das ist nachvollziehbar. Perl mag das gar nicht wenn man eine nicht-existierende Funktion aufruft.
Check habe ich eingefügt, aber da das eher ein "corner case" ist, werde ich erstmal weitere Änderungen aufsammeln bevor ich ein Update poste.
Jörg
Ich habe gerade auf die neueste Version aktualisiert (Austausch des Moduls). Nach dem FHEM-Neustart wurde ich aufgefordert, Protocol::Dbus zu installieren, was ich dann mit cpan install Protocol::DBus gemacht habe. Die Funktionalität ist weiterhin gegeben, allerdings habe ich nun folgenden Fehler in den Device Readings:
lastError: Error in version:The method `org.asamk.Signal.version' does not exist on this object.
Sobald ich z. B. ein "get contacts all" eingebe, erscheint ein Popup: Signal-cli 0.8.1+ required for this functionality.
Das Versenden von Nachrichten funktioniert aber weiterhin. Habe ich etwas falsch gemacht, oder ist das eventuell ein Bug in der neuesten Version?
Viele Grüße,
Daniel
Hast du auch den aktuellen Installer laufen lassen um signal-cli zu updaten?
Jörg
Stimmt, das habe ich glatt vergessen - ich hatte die FHEM-Instant komplett aktualisiert und dabei "mal eben" das Modul aktualisiert. Ich habe jetzt den aktuellen Installer heruntergeladen und die Funktionen "system" und "install" genutzt. Danach wurde die Meldung in FHEM nicht mehr angezeigt. Meine bestehende Config wurde vom Installer einwandfrei übernommen. :D
Viele Grüße,
Daniel
Erst einmal ein großes Danke für die Entwicklung dieses Moduls!
Ich hatte Schwierigkeiten bei Installation auf einem RPI3 mit Raspbian/Debian "Stretch" (ja ich weiß, das ist nicht mehr aktuell):
Die signal-cli Installation mit dem Installationsskript signal_install.sh hat nicht vollständig funktioniert. Ich habe mir letztendlich damit geholfen, dass ich von https://github.com/DutchForeigner/signal-cli_rpi (https://github.com/DutchForeigner/signal-cli_rpi) das für den RPI fertig gebaute Signal-cli v0.8.1 (zkgroup-java-0.7.1.jar ist bereits integriert) über die fehlgeschlagene Installation kopiert habe. Vielleicht ist das für das Installationsskript interessant?
Hallo Jörg,
ich hatte SiSi installiert, das aber nach einem simplen Neustart des Servers nicht mehr funktionierte. Ich hatte daraufhin alles, was mit SiSi zu hat, deinstalliert. Im Wiki hatte ich gelesen, dass SiSi nicht mehr weiterentwickelt wird, so habe ich mich etwas später entschlossen, dein Modul Signalbot zu installieren, und zwar mit sudo -E ./signal_install.sh.
Mein Server:
Your configuration
Linux HPT610 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
has not been tested, continue at own risk
Die Installation lief auch im wesentlichen durch bis auf 2 Besonderheiten:
- ich hatte meine bei der Installation von SiSi registrierte Festnetznummer angegeben, sowohl in der Installationdatei, als auch bei der Abfrage in der Installation
- das zweite ist folgender Text, der während der Installation gezeigt wurde:
...
Stopping signal-cli service
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
No input data.
Reading account data
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
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.
done
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49MeineMobilnummer
Sending a message from command line to +49MeineMobilnummer
Stopping signal-cli service
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
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.
Sending a message via dbus-send command
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Sending a message via perl Protocol::DBus
Error getting message
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
Ein list meines Devices:
Internals:
CFGFN
FD 23
FUUID 60983278-f33f-e986-bab0-35aae0950916cc12
NAME Signal
NOTIFYDEV global
NR 1232
NTFY_ORDER 50-Signal
STATE Connected
TYPE Signalbot
READINGS:
2021-05-09 21:26:21 lastError Error in sendMessage:Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
2021-05-09 21:25:56 sentMsg Hallo, hier ist Fhem.
2021-05-09 21:25:56 sentMsgTimestamp pending
helper:
init :1.13
signalpath /org/asamk/Signal
attachments:
bm:
Signalbot_Attr:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:06:15
max 0.000128030776977539
tot 0.000437021255493164
mAr:
set
Signal
group
Push
Signalbot_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:05:28
max 0.068789005279541
tot 0.068789005279541
mAr:
HASH(0x559d1337dc20)
Signal Signalbot
Signalbot_Get:
cnt 13
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:05:57
max 6.00814819335938e-05
tot 0.000626087188720703
mAr:
HASH(0x559d1337dc20)
Signal
?
Signalbot_Notify:
cnt 10
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:05:36
max 7.70092010498047e-05
tot 0.00048518180847168
mAr:
HASH(0x559d1337dc20)
HASH(0x559d0774ae98)
Signalbot_Read:
cnt 9
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:10:05
max 0.107939004898071
tot 0.559039354324341
mAr:
HASH(0x559d1337dc20)
Signalbot_Set:
cnt 40
dmx -1000
dtot 0
dtotcnt 0
mTS 09.05. 21:25:03
max 0.0134880542755127
tot 0.0284733772277832
mAr:
HASH(0x559d1337dc20)
Signal
reinit
Attributes:
defaultPeer +49MeineMobilnummer
group Push
icon im_bullhorn
verbose 5
signal.service scheint nicht zu laufen, er lässt sich auch nicht starten:
pi@HPT610:/opt/fhem/FHEM$ sudo 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 Sun 2021-05-09 21:25:56 CEST; 3min 26s ago
Process: 28276 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +492143103913 daemon --system (code=exited, status=1/FAILURE)
Main PID: 28276 (code=exited, status=1/FAILURE)
May 09 21:25:56 HPT610 signal-cli[28276]: at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
May 09 21:25:56 HPT610 signal-cli[28276]: at java.security.AccessController.doPrivileged(Native Method)
May 09 21:25:56 HPT610 signal-cli[28276]: at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
May 09 21:25:56 HPT610 signal-cli[28276]: at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
May 09 21:25:56 HPT610 signal-cli[28276]: at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
May 09 21:25:56 HPT610 signal-cli[28276]: at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
May 09 21:25:56 HPT610 signal-cli[28276]: at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
May 09 21:25:56 HPT610 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
May 09 21:25:56 HPT610 systemd[1]: signal.service: Failed with result 'exit-code'.
May 09 21:25:56 HPT610 systemd[1]: Failed to start Send secure messages to Signal clients.
pi@HPT610:/opt/fhem/FHEM$ sudo systemctl start signal.service
Job for signal.service failed because the control process exited with error code.
See "systemctl status signal.service" and "journalctl -xe" for details.
pi@HPT610:/opt/fhem/FHEM$
Hast du eine Idee, was hier schief gelaufen ist, und was ich tun müsste, um es zum Laufen zu bringen?
Viele Grüße Gisbert
Hallo Jörg,
mein Problem scheint wohl mit Java 8 und 11 zusammenzuhängen.
Meine Unifi-Installation bzw. der Unifi-Controller für mein Netzwerk verlangt nach Java 8, signal-cli verlangt nach Java 11.
Ich hab Java 11 installiert:
sudo apt install default-jre
Diese Java-Versionen scheine ich auf meinem Server zu haben:
pi@HPT610:~$ dpkg -l | grep "oracle\|openjdk"
ii openjdk-11-jre:amd64 11.0.11+9-1~deb10u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:amd64 11.0.11+9-1~deb10u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-1~deb9u1-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
Es ändert aber nichts an der Tatsache, dass ich diese Fehlermeldung bekomme, da offensichtlich Java 8 anstelle von 11 genommen wird:
Stopping signal-cli service
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
Hast du eine Idee, wie ich hier vorgehen kann?
Viele Grüße Gisbert
Hi Gisbert,
Check mal die Reihenfolge in deiner $PATH, was zuerst kommt wird genommen.
Du könntest auch die richtige Version im Startscript unter /opt/signal/bin hardcoden (mit absolutem Pfad)
Jörh
Hallo Jörg,
ich bekomme das bei $PATH:
pi@HPT610:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
pi@HPT610:~$
Kannst damit was anfangen?
/opt/signal/bin hardcoden (mit absolutem Pfad):
Gerne, dann benötige ich aber konkrete Vorgaben, da ich weder Linux noch Perl gut genug kann. Gleiches gilt für $PATH.
Viele Grüße Gisbert
Edit:
Ich hab den Pfad /opt/signal/bin vorne in PATH eingetragen und dann versucht signal.service zu starten, was aber nicht gelang.
Edit2:
$JAVA_HOME, welches in signal-cli steht, liefert das:
pi@HPT610:/opt/signal/bin$ echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
Hi Gisbert,
so sollte es aussehen:
pi@raspi400:~ $ which java
/usr/bin/java
pi@raspi400:~ $ java -version
openjdk version "11.0.9.1" 2020-11-04
OpenJDK Runtime Environment (build 11.0.9.1+1-post-Raspbian-1deb10u2)
OpenJDK Server VM (build 11.0.9.1+1-post-Raspbian-1deb10u2, mixed mode)
Mein $JAVA_HOME ist leer, dadurch dass deins aber gesetzt ist, nimmt er die entsprechende Version dort.
sofern
/usr/bin/java -version
bei dir die richtige Version ausgibt, sollte es reichen die $JAVA_HOME nicht zu setzen - wo auch immer das bei dir passiert (.bashrc) oder zumindest im .bashrc vom signal-cli Benutzer zu überschreiben (export JAVA_HOME=)
Jörg
Hallo Jörg,
ich kann das liefern:
pi@HPT610:/opt/signal/bin$ which java
/usr/bin/java
pi@HPT610:/opt/signal/bin$ java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-1~deb9u1-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
pi@HPT610:/opt/signal/bin$
sowie:
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
dpkg -l | grep "oracle\|openjdk" liefert:
ii openjdk-11-jre:amd64 11.0.11+9-1~deb10u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:amd64 11.0.11+9-1~deb10u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
Damit kommt Signal - wie vermutet - nicht zurecht.
Womit wir beim zweiten Teil deines letzten Satzes sind, den ich aber ohne Hilfe nicht umsetzen kann.
Viele Grüße Gisbert
Dann hat sich Java8 wohl als dein primäres Java eingenistet.
Dein System via Forum remote zu debuggen ist jetzt wirklich mühsam. Ein letzter Tipp - sonst suche dir bitte Hilfe von einem Linux Admin, denn das alles hat mit Signal nicht wirklich etwas zu tun.
Ich denke, dass du signal-cli dazu bringen kannst, die korrekte Java Version zu verwenden, indem du $JAVA_HOME vor dem Aufruf auf das Verzeichnis von Java11 setzt.
Den genauen Pfad bei dir kenne ich jetzt nicht, aber wahrscheinlich sowas wie
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/
Testen kannst du das dann erst mal mit dem Install Script (mit der "test" option"), musst bei Erfolg aber diese Zeile auch ins .bashrc des signal-cli users einfügen.
Gruß,
Jörg
Zitat von: Adimarantis am 13 Mai 2021, 09:15:06
Dann hat sich Java8 wohl als dein primäres Java eingenistet.
Dein System via Forum remote zu debuggen ist jetzt wirklich mühsam. Ein letzter Tipp - sonst suche dir bitte Hilfe von einem Linux Admin, denn das alles hat mit Signal nicht wirklich etwas zu tun.
Ich denke, dass du signal-cli dazu bringen kannst, die korrekte Java Version zu verwenden, indem du $JAVA_HOME vor dem Aufruf auf das Verzeichnis von Java11 setzt.
Den genauen Pfad bei dir kenne ich jetzt nicht, aber wahrscheinlich sowas wie
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/
Testen kannst du das dann erst mal mit dem Install Script (mit der "test" option"), musst bei Erfolg aber diese Zeile auch ins .bashrc des signal-cli users einfügen.
Hallo Jörg,
es ist aber auch zu verflixt, auch diese Möglichkeit wird mit immer dem gleichen Fehler quittiert. Ich habe auch noch andere Ratschläge ausprobiert - nichts führt zum Erfolg.
Ich wundere mich nur, dass ich anscheinend der einzige (lebende) Anwender bin, der gleichzeitig einen UniFi-Controller und Signal auf einem Server unter Debian10 installiert hat bzw. es möchte.
Trotzdem vielen Dank.
Ich gebe nur zwischenzeitlich auf, denn Aufgeben ist ja bekanntlich keine Option.
Viele Grüße
Gisbert
Hallo Jörg,
hallo zusammen,
vielleicht interessiert euch die Lösung, wenn man unbedingt wegen des UniFi-Controllers Java 8 behalten muss.
Die Lösung war, dass ich es irgendwie geschafft habe, den Standard bei Java von 8 auf 11 zu ändern.
Informationen gibt es dazu in dieser Datei:
/usr/lib/jvm/java-11-openjdk-amd64/docs/README.alternatives
Wenn man den folgenden Befehl ausgeführt hat, dann ist Java 11 die primäre Installation von Java.
sudo update-java-alternatives --auto
java -version
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.11+9-post-Debian-1deb10u1, mixed mode, sharing)
Dannach war es ein Kinderspiel, die Signalbot-Installation durchzuführen.
UniFi benutzt nach wie vor noch Java 8, das ist anscheinend dort hart verlinkt, was ja auch Sinn macht, wenn UniFi nur mit Java 8 funktioniert.
Ich habe auf diesem Weg einiges gelernt, wenn auch nicht wirklich verstanden, aber immerhin.
Nochmals vielen Dank und viele Grüße
Gisbert
Guten Abend,
wollte mal den Signalbot testen. Meine FHEM Installation läuft in einem Docker Container.
Die Installation scheint soweit durchzulaufen, jedoch bekomme ich beim register keinen Anruf.
Dann habe ich den register Aufruf direkt mit der signal-cli aufgerufen. Dann bekomme ich die Meldung, dass die libzkgroup library fehlt.
Jedoch habe ich bisher keinen Ansatz gefunden, wie ich das in einer Container-Installation lösen kann. Bisher habe ich das nur in Zusammenhang mit einem RasPi gefunden.
Kann mir da einer helfen?
Danke und Gruß,
Stephan
Update des Installers auf V2.2
Enthält nur Versionsupdates der Pakete signal-cli (auf 0.8.3) und Protocol::DBus (auf 0.17).
Wenn alles funktioniert, sehe ich keinen zwingenden Grund für dieses Update.
Siehe Changelogs ob es sich für euch lohnt:
https://github.com/AsamK/signal-cli/blob/master/CHANGELOG.md
https://metacpan.org/release/Protocol-DBus
Um das Update durchzuführen, einfach Installer laufen lassen (Registrierung auslassen, aber Test durchführen, da das gleich den Service neu startet).
In FHEM ist ein "shutdown restart" nötig um die neue Protocol::DBus Version anzuziehen - sonst reicht ein "reinit" für signal-cli.
Soweit ich sehe mussten die ARM libraries nicht aktualisiert werden - bei mir lief nach dem Update zumindest alles wie gewohnt, habe aber keinen sehr ausführlichen Test gemacht.
Gruß,
Jörg
Zitat von: kabakakao am 13 Mai 2021, 20:11:47
Jedoch habe ich bisher keinen Ansatz gefunden, wie ich das in einer Container-Installation lösen kann. Bisher habe ich das nur in Zusammenhang mit einem RasPi gefunden.
Läuft der Container auch auf einem Raspi? Dann finden sich die native libraries (die vom install script automatisch eingebunden werden) unter https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/
Dieser Teil des Installers kümmert sich darum die x86 libraries durch ARM (Raspian Buster) zu ersetzen:
wget -qN https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/libzkgroup.so
wget -qN https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/libsignal_jni.so
zip -u $SIGNALPATH/signal/lib/zkgroup-java-*.jar libzkgroup.so
zip -u $SIGNALPATH/signal/lib/signal-client-java-*.jar libsignal_jni.soWenn das ganze auf x86 unter Ubuntu laufen darf, habe ich mir mal ein Script zur Containererstellung gebaut (siehe Anhang) - habs aber schon länger nicht mehr getestet, daher ohne Gewähr und eher als Anregung.
Jörg
Zitat von: Gisbert am 13 Mai 2021, 18:44:03
Die Lösung war, dass ich es irgendwie geschafft habe, den Standard bei Java von 8 auf 11 zu ändern.
Informationen gibt es dazu in dieser Datei:
/usr/lib/jvm/java-11-openjdk-amd64/docs/README.alternatives
Wenn man den folgenden Befehl ausgeführt hat, dann ist Java 11 die primäre Installation von Java.
sudo update-java-alternatives --auto
Schön das du eine Lösung gefunden hast. Ich bin leider derzeit ziemlich mit anderen Themen unter Wasser und kann mich nicht sehr tief in solche Problemstellungen einarbeiten.
Jörg
Zitat von: Adimarantis am 13 Mai 2021, 20:29:54
Läuft der Container auch auf einem Raspi? Dann finden sich die native libraries (die vom install script automatisch eingebunden werden) unter https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/
Dieser Teil des Installers kümmert sich darum die x86 libraries durch ARM (Raspian Buster) zu ersetzen:
wget -qN https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/libzkgroup.so
wget -qN https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signallibs_armv7l/libsignal_jni.so
zip -u $SIGNALPATH/signal/lib/zkgroup-java-*.jar libzkgroup.so
zip -u $SIGNALPATH/signal/lib/signal-client-java-*.jar libsignal_jni.so
Wenn das ganze auf x86 unter Ubuntu laufen darf, habe ich mir mal ein Script zur Containererstellung gebaut (siehe Anhang) - habs aber schon länger nicht mehr getestet, daher ohne Gewähr und eher als Anregung.
Jörg
Danke für die schnelle Antwort. Der Container läuft auf meiner QNAP. Ist auch ein ARM system. Kann ich die library sonst irgendwie auf dem system bauen?
Zitat von: kabakakao am 13 Mai 2021, 20:39:47
Danke für die schnelle Antwort. Der Container läuft auf meiner QNAP. Ist auch ein ARM system. Kann ich die library sonst irgendwie auf dem system bauen?
Vielleicht funktionieren die libraries ja sogar?
Sonst sehe ich noch zwei Optionen:
1.) Du baust den Container basierend auf einem Raspian Buster image - dann sollten sie eigentlich gehen?
2.) Du versuchst dich im Eigenbau. Eine Anleitung dazu gibts im signal-cli Wiki: https://github.com/AsamK/signal-cli/wiki/Provide-native-lib-for-libsignal
Jörg
Hallo Jörg,
ich hätte eine Nachricht, die ein Apostroph enthält, so in der Art ... Gisbert's ...
Ich bekomme dann folgenden log-Eintrag, und die Nachricht wird nicht verschickt:
Specify either a message text or an attachment
Kann man das Apostroph maskieren, und wenn ja, wie?
Viele Grüße Gisbert
Edit: Ich hab eine Lösung gefunden, ein Backslash vor dem Apostroph: ... Gisbert\'s ... liefert ... Gisbert's ...
Hallo,
bin weder aus diesem Thema hier noch aus der Doku zu msg (msgConfig) (Wiki) schlau geworden, wie ich msg als Nachrichtenzentrale mit Signalbot einsetzen kann. Signalbot läuft bei mir.
Hat jemand bitte ein list von einer funktionierenden Konfiguration für mich?
Danke
Boris
Hallo Boris,
aus der Erinnerung heraus kann ich sagen, dass du Java 11 benötigst. Da ich auf dem gleichen Linuxsystem einen UniFi-Controller habe, der zwingend Java 8 benötigt, musste ich erst dieses Problem lösen. Falls es hierzu Fragen gibt, dann helfe ich gerne.
Ansonsten ist die Wiki-Anleitung mithilfe des Installationskriptes aus meiner Sicht nachvollziehbar und funktioniert.
Hier ist meine (simple) Definition in Fhem:
define Signal Signalbot
attr Signal defaultPeer +49...MeineHandynummer
Ein list ist schwierig, da viele persönliche Informationen enthalten sind.
Falls noch Fragen sind, dann melde dich gerne.
Viele Grüße Gisbert
Zitat von: Gisbert am 01 Juni 2021, 16:28:06
Falls noch Fragen sind, dann melde dich gerne.
Danke, Gisbert, für Deine Unterstützung.
Ich habe mich missverständlich ausgedrückt. Der Signalbot läuft bei mir einwandfrei. Installation gemäß Wiki lief am Schnürchen.
Mit fehlt der Ansatz, msg über Signalbot Nachrichten versenden zu lassen. msg unterstützt von Hause aus verschiedene Messenger-Devices aber eben nicht Signalbot. Es gibt bei msg die Möglichkeit, die Kommandos von Hand zu Fuß zu definieren. Und da wollte ich gerne ein list von einen msg-Device, das so konfiguriert ist, dass es Signalbot benutzt.
Viele Grüße
Boris
Hallo Boris,
bei mir funktioniert in einem DOIF folgender Ausführungsteil:
(set Signal send Das Fenster in Gisbert\'s Zimmer steht offen. Die Temperatur beträgt [Temp.OG:Gisbert]°C.)
Meinst du etwas in der Art? Anscheinend gibt es in Signal (von Fhem aus) mehrere Möglichkeiten Nachrichten zu versenden. Ich erhalte dann auf meinem Handy, auf der die App Signal läuft (*man bemerke die Namensgleichheit *Ironie Ende), die obige Nachricht, alles nach "send".
Bei der Einrichtung werden 3 Nachrichten von der Linuxebene zum Handy geschickt, siehe beigefügter Screenshot. Wenn du diese Nachrichten empfangen hast, dann ist die Einrichtung auf dem Server und auf dem Handy in Ordnung.
Viele Grüße Gisbert
Ich hatte im thread von "msg" schon mal nachgefragt ob Loredo Signalbot integrieren kann:
https://forum.fhem.de/index.php/topic,39983.msg1136318.html#new
Leider ist auf dem Forum keine Aktivität. Aber wenn mehr Leute Interesse bekunden, vielleicht hilft das ja?
Ich persönlich habe die Sache bei mir nicht weiter probiert und kann daher leider keine passende Config liefern.
Jörg
Zitat von: Adimarantis am 01 Juni 2021, 22:04:26
Leider ist auf dem Forum keine Aktivität. Aber wenn mehr Leute Interesse bekunden, vielleicht hilft das ja?
Habe es mal getan.
Zitat von: Dr. Boris Neubert am 31 Mai 2021, 19:03:57
Hallo,
bin weder aus diesem Thema hier noch aus der Doku zu msg (msgConfig) (Wiki) schlau geworden, wie ich msg als Nachrichtenzentrale mit Signalbot einsetzen kann. Signalbot läuft bei mir.
Hat jemand bitte ein list von einer funktionierenden Konfiguration für mich?
Danke
Boris
Hallo,
evtl. verstehe ich was falsch, aber ist es vielleicht das was gesucht wird?
https://wiki.fhem.de/wiki/SiSi#Zusammenspiel_mit_den_Modulen_Msg_und_Roommate (https://wiki.fhem.de/wiki/SiSi#Zusammenspiel_mit_den_Modulen_Msg_und_Roommate)
VG Dieter
Hallo,
FHEM läuft bei mit unter Ubuntu x86 habe Signal-cli installiert und eine Nummer registriert aber der Service startet nicht
root@ubuntu-FHEM:/home/user# sudo systemctl start signal.service
Job for signal.service failed because the control process exited with error code.
See "systemctl status signal.service" and "journalctl -xe" for details.
root@ubuntu-FHEM:/home/user# sudo 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 Sat 2021-06-05 00:50:53 CEST; 8s ago
Process: 2712536 ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49"MeineNR." --config /opt/fhem/.local/share/signal-cli/data daemon --syste>
Main PID: 2712536 (code=exited, status=1/FAILURE)
Jun 05 00:50:53 ubuntu-FHEM systemd[1]: Starting Send secure messages to Signal clients...
Jun 05 00:50:53 ubuntu-FHEM signal-cli[2712536]: User +49"meineNr." is not registered.
Jun 05 00:50:53 ubuntu-FHEM systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Jun 05 00:50:53 ubuntu-FHEM systemd[1]: signal.service: Failed with result 'exit-code'.
Jun 05 00:50:53 ubuntu-FHEM systemd[1]: Failed to start Send secure messages to Signal clients.
Aber es kommt kein FEhler
Mache ich "sudo -u fhem signal-cli -u <RegistrierteNummer> send -m "Greetings from FHEM!" <Empfängernummer>" natürlich mit den richtigen Nr. funktioniert es ...........
root@ubuntu-FHEM:/home/user# sudo -E ./signal_install.sh
sudo: ./signal_install.sh: Befehl nicht gefunden
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Edit
der Signal.service läuft jetzt, user=fhem in root getauscht und dem Pfad der Config beibehalten
Problem erledigt, man sollte das script Signal_install.sh mit chmod -x auch ausführbar machen ;-)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Zitat von: dk3572 am 02 Juni 2021, 20:56:25
https://wiki.fhem.de/wiki/SiSi#Zusammenspiel_mit_den_Modulen_Msg_und_Roommate (https://wiki.fhem.de/wiki/SiSi#Zusammenspiel_mit_den_Modulen_Msg_und_Roommate)
Ich denke, dass ist es, was ich suche. Ich muss es noch ausprobieren. Danke, Dieter.
Zitat von: Dr. Boris Neubert am 07 Juni 2021, 17:23:02
Ich denke, dass ist es, was ich suche. Ich muss es noch ausprobieren. Danke, Daniel.
Gern geschehen, und für den Daniel drück ich mal ein Auge zu ;) ;D
VG Dieter
Eine vermutlich einfache Frage für Zwischendurch:
Wie kann ist das Modul Signalbot anweisen, auch Umlaute zu empfangen (Senden klappt prinzipiell)?
Hier mal ein Beispiel aus meinem Listing, bei dem aus Temperatur Küche halt Temperatur K�che wurde.
Gibt es generelle Eisntellungen, die hinsichtlich Umnlauten zu beachten sind?
Gruß und Dank für eine fachkundige Antwort,
Heiko
FUUID xxx
NAME SignalBot
NOTIFYDEV global
NR 382
NTFY_ORDER 50-SignalBot
STATE Connected
TYPE Signalbot
READINGS:
2021-04-29 08:16:23 joinedGroups
2021-06-09 17:29:45 lastError Error in sendMessage:Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
2021-06-10 13:21:57 msgAttachment
2021-06-10 13:21:57 msgAuth 0
2021-06-10 13:21:57 msgGroupName
2021-06-10 13:21:57 msgSender Heiko
2021-06-10 13:21:57 msgText Temperatur K�che
...
Attributes:
defaultPeer +4915150036845
group Signal
room IT
Hi Heiko,
In die Richtung habe ich das wohl nie probiert.
Anbei mal ein quick fix den ich aber nicht weiter getestet habe (außer dass ich damit Umlaute jetzt hoffentlich in alle Richtungen korrekt kriege). Wäre schön wenn du den auf "Herz und Nieren" testen kannst (ist nur eine Zeile die eine utf8 Umwandlung der eingehenden Message macht).
Bei der Gelegenheit habe ich auch noch zwei andere Kleinigkeiten gefunden und gefixt.
Jörg
Getestet, geht, FETTES DANKE für den schnellen Support!
Hier mein Listung, das zeigt, dass die Umlaute nun gut aufgenommen werden (sowohl im "msgText" als auch im "sentMsg"-Reading sind die Umlaute nun da):
FD 4
FUUID xxx
NAME SignalBot
NOTIFYDEV global
NR 382
NTFY_ORDER 50-SignalBot
STATE Connected
TYPE Signalbot
VERSION Signalbot:2.1a signal-cli:0.8.1 Protocol::DBus:0.16
READINGS:
2021-04-29 08:16:23 joinedGroups
2021-06-10 17:02:26 lastError Error in getContactName:Error Executing Method org.asamk.Signal.getContactName: null
2021-06-10 17:30:23 msgAttachment
2021-06-10 17:30:23 msgAuth 0
2021-06-10 17:30:23 msgGroupName
2021-06-10 17:30:23 msgSender Heiko
2021-06-10 17:30:23 msgText Rolläden
2021-06-10 17:30:23 msgTimestamp 10-06-2021 17:30:24
2021-06-10 17:30:23 prevMsgAttachment
2021-06-10 17:30:23 prevMsgGroupName
2021-06-10 17:30:23 prevMsgSender Heiko
2021-06-10 17:30:23 prevMsgText [b]Temperatur Küche[/b]
2021-06-10 17:30:23 prevMsgTimestamp 10-06-2021 17:30:11
2021-06-10 17:30:23 sentMsg Die Rolläden haben die folgende Position
- Wohnzimmer Tür links: 0%
- Wohnzimmer Tür rechts: 0%
- Wohnzimmer Fenster: 0%
- Küche Fenster: 0%
(0% = offen, 100% = geschlossen)
2021-06-10 17:30:24 sentMsgRecipient xxx
2021-06-10 17:30:24 sentMsgTimestamp 10-06-2021 17:30:23
helper:
init :1.33938
signalpath /org/asamk/Signal
version 801
auth:
contacts:
+49xxx xxx
+49xxx xxx
Attributes:
defaultPeer +49xxx
group Signal
room IT
Gruß
Heiko
Zitat von: dk3572 am 07 Juni 2021, 19:08:13
und für den Daniel drück ich mal ein Auge zu ;) ;D
Sorry Dieter, hatte während des Schreibens eine Unterbrechung durch einen Daniel und da sind bei mir die Ds durcheinander geraten... :o
Danke Heiko, ich habe die Änderung (und noch einen weiteren kleinen Fix) als v2.2 am Anfang des Threads aktualisert.
Jörg
Zitat von: Adimarantis am 10 Juni 2021, 22:41:38
Danke Heiko, ich habe die Änderung (und noch einen weiteren kleinen Fix) als v2.2 am Anfang des Threads aktualisert.
Jörg
Hallo Jörg,
kommt das Update automatisch per Fhem, oder was muss ich genau beachten?
Viele Grüße Gisbert
Signalbot ist kein offizielles Modul (was hauptsächlich daran liegt, dass es für sich alleine nicht funktioniert und den Installer und andere Abhängigkeiten benötigt).
Daher findet sich immer im ersten Post dieses Threads die aktuelle Version inkl. eines kurzen Changelog.
Jörg
Hallo Jörg,
Zitat von: Adimarantis am 11 Juni 2021, 14:57:10
Signalbot ist kein offizielles Modul (was hauptsächlich daran liegt, dass es für sich alleine nicht funktioniert und den Installer und andere Abhängigkeiten benötigt).
es gibt ja eine Menge Module, die zusätzlich zu der Software, die standardmäßig beim Betriebssystem/bei der Distribution dabei ist, Nachinstallationen verlangen und sich dennoch großer Popularität erfreuen (Alexa, Tradfri) und im Standard mitverteilt werden. Eine gute, verständliche und leicht nachvollziehbare Doku ist das A und O. Beim Signalbot macht es die Doku leicht, die restliche Software zu installieren. Die Infos oder zumindest der Verweis aufs Wiki sollte in der Commandref sein.
Ich fände es gut, wenn Signalbot als Standard-Modul für Signal in die offizielle Modul-Verteilung käme.
Viele Grüße
Boris
Hi. Wie ist der Stand der Dinge?
Ist das Skript inzwischen ausgereift?
Ich würde Boris Vorschlag ebenfalls befürworten.
Schönen Abend.
Werde ich mir mal anschauen, wenn ich wieder mehr Luft habe. Derzeit gehts mit Arbeit und privaten Projekten ziemlich rund.
Jörg
Klar. Ist verständlich.
Aber trotzdem erstmal Dankeschön für deine Arbeit ;)
Hallo,
das Skript läuft bei mir durch.
Aber ich bekommen weder einen Anruf noch eine SMS - auch nach einer Stunde warten tut sich nix ...
Update:
Es funktioniert nicht mit Festnetznummern!
Mit einer Mobilnummerfunktioniert es!
Hallo Remo,
es funktioniert grundsätzlich auch mit Fetznetznummern. Das habe ich dreimal erfolgreich durchgeführt.
Beim ersten Mal hatte ich jedoch dasselbe Erlebnis. Es kommt einfach kein Rückruf. Recherche hat ergeben, dass es damals an einem Serverproblem (Überlastung?) lag. Eine Woche später ging es bei einem erneuten Registrierungsversuch, ohne dass ich etwas dazu getan hätte.
Viele Grüße
Boris
Hallo Boris.
Danke für den Hinweis.
Ich hatte es allerdings über drei Wochen mit insgesamt vier Anläufen versucht.
Bisher ohne Erfolg. Wann war denn deine erfolgreiche Registrierung mit einer Festnetznummer?
Vor Kurzem?
Ich würde es gerne noch einmal versuchen wollen.
BTW:
Kann man über das Skript auch wieder Nummern unregistern?
Liebe Grüße
Hallo,
Festnetz geht definitiv. Ich habe nur Festnetznummern registriert. Wenn kein Anruf kommt - wird ein Captcha verlangt? Bevor dies nicht gelöst wurde, gibt es auch keinen Anruf.
Nummer zu "de-registrieren" ist nicht nötig. Eine erneute Registrierung überschreibt die vorherige.
Jörg
Hallo.
Gerade nochmals versucht.
Captcha klappt.
Bei einer Mobilfunknummer kommt sofort nach eingabe des Captcha-Hashes die SMS.
Bei Festnetz passiert nix.
Werder Anruf noch wird mir die SMS vorgelesen...
EDIT:
Jetzt hat es auf einmal funktioniert.
Captcha ok.
SMS kam als Anruf (Festnetz beim Provider aufs Handy weitergeleitet) ok.
Keine Ahnung - Habe nix anders gemacht als vorher ...
Hallo zusammen,
erst einmal vielen Dank für die ganzen Mühen & Arbeit! Stelle mein Setup gerade von SiSi auf den Signalbot um. Zu meinem Problem: Die Skriptausführung bricht mit einem Fehler ab:
./signal_install.sh: 406: ./signal_install.sh: Syntax error: "(" unexpected (expecting "fi")
Ich nutze das Docker Image nicht, also habe ich die folgende Stelle
#398 stop_service() {
#399 if [ -z "$DOCKER" ]; then
#400 echo "Stopping signal-cli service"
#401 service signal stop
#402 else
#403 SIGSERVICE=`ps -eo pid,command | grep $SIGNALVAR | grep -v grep`
#404 if [ -n "$SIGSERVICE" ]; then
#405 echo "Stopping signal-cli daemon for Docker"
#406 >> ARRAY=($SIGSERVICE)
#407 PID=${ARRAY[0]}
#408 kill $PID
#409 fi
#410 fi
#411 }
wie folgt angepasst:
stop_service() {
echo "Stopping signal-cli service"
service signal stop
}
Dann habe ich folgenden Fehler bekommen:
./signal_install.sh: 659: ./signal_install.sh: Syntax error: "(" unexpected (expecting "fi")
Auch hier dasselbe Spiel. Dieser Block
#651 if [ -z "$DOCKER" ]; then
#652 systemctl daemon-reload
#653 systemctl disable signal.service
#654 systemctl reload dbus.service
#655 else
#656 DBDAEMON=`ps -eo pid,command | grep dbus-daemon | grep -v grep`
#657 if [ -n "$DBDAEMON" ]; then
#658 echo "Stopping dbus daemon for Docker"
#659 >> ARRAY=($DBDAEMON)
#660 PID=${ARRAY[0]}
#661 kill $PID
#662 fi
#663 fi
wird zu
systemctl daemon-reload
systemctl disable signal.service
systemctl reload dbus.service
Dann klappt die Ausführung, allerdings beschwert sich das Skript, dass die Ausführung, die ich so ausführe (vielleicht ist das sh das Problem? Ein Aufruf ohne vorangestelltes sh mit sudo -E ./signal_install.sh liefert aber sudo: ./signal_install.sh: command not found)
$ sudo -E sh ./signal_install.sh
nicht mit bash erfolgt:
[...]
Checking for zip...available
This script requires bash for some functions. Check if bash is installed.
Checking for bash...available
Please re-run using bash
Die default shell ist aber bash:
$ finger $USER|grep -oP 'Shell: \K.*'
/bin/bash
Der Aufruf explizit mit bash funktioniert:
$ /bin/bash ./signal_install.sh
Zum Schluss scheint das Verschicken von Nachrichten noch nicht zu klappen, aber da schaue ich noch weiter rein.
[...]
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.
Sending a message via dbus-send command
Error org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Sending a message via perl Protocol::DBus
Error getting message
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
== Update ==
Das Skript lief nun erfolgreich durch. Vermutlich trat der vorherige Fehler auf, weil ich die Option -E weggelassen hatte. Mit Angabe von -E und der Pflege der Nummer in ~/.bash_profile lief das Skript erfolgreich durch und ich konnte meinen Account verlinken. :)
Viele Grüße,
Jascha
Hallo zusammen,
ich habe mit dem Installationsskript den Signal Client soweit am laufen (Der Test schickt 3 Meldungen, die auch auf der Gegenseite ankommen). Leider kann ich aber kein Signal Device in FHEM anlegen, obwohl Protocol::DBus installiert ist. Ich halte nur folgende Meldung im Log:
2021.06.29 14:10:57.055 1: Define init_done: SignalClient Signalbot
2021.06.29 14:10:57.055 1: SignalClient: Init: Please make sure that Protocol::DBus is installed, e.g. by 'sudo cpan install Protocol::DBus'
2021.06.29 14:10:57.055 1: define SignalClient Signalbot: Please make sure that Protocol::DBus is installed, e.g. by 'sudo cpan install Protocol::DBus'
root@rpi:/home/xxx# cpan install Net:DBus
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Tue, 29 Jun 2021 09:29:03 GMT
Net::DBus is up to date (1.2.0).
root@rpi:/home/xxx# cpan install Protocol::DBus
Loading internal logger. Log::Log4perl recommended for better logging
Reading '/root/.cpan/Metadata'
Database was generated on Tue, 29 Jun 2021 09:29:03 GMT
Protocol::DBus is up to date (0.17).
Wie stehen die Chancen die Datei "50_Signalbot.pm" standardmäßig mit aufzunehmen, ohne,
dass diese manuell abgelegt werden muss?
Zitat von: acw81 am 29 Juni 2021, 14:18:50
Leider kann ich aber kein Signal Device in FHEM anlegen, obwohl Protocol::DBus installiert ist. Ich halte nur folgende Meldung im Log:
Wenn das Script under root geht, aber unter deinem fhem user das Perl Modul nicht gefunden wird, dann überprüfe mal das Environment des Users (besonders hinsichtlich Perl).
Alle Pfade korrekt? Alle notwendigen Variablen gesetzt? Gruppenzugehörigkeit passt?
Jörg
Zitat von: remo am 29 Juni 2021, 17:10:04
Wie stehen die Chancen die Datei "50_Signalbot.pm" standardmäßig mit aufzunehmen, ohne,
dass diese manuell abgelegt werden muss?
Wie schon weiter oben gesagt: Wenn ich wieder mehr Zeit habe. Wenn ich das jetzt so aufnehme, dann werden sich zig Leute beschweren das es nicht "out of the box" funktioniert. D.h. da muss die Fehlerbehandlung (Script nicht gelaufen) weiter verbessert werden mit konkreten Hinweisen wo das Skript zu funden ist etc.
Jörg
Zitat von: remo am 28 Juni 2021, 11:50:53
Hallo.
Gerade nochmals versucht.
Captcha klappt.
Bei einer Mobilfunknummer kommt sofort nach eingabe des Captcha-Hashes die SMS.
Bei Festnetz passiert nix.
Werder Anruf noch wird mir die SMS vorgelesen...
EDIT:
Jetzt hat es auf einmal funktioniert.
Captcha ok.
SMS kam als Anruf (Festnetz beim Provider aufs Handy weitergeleitet) ok.
Keine Ahnung - Habe nix anders gemacht als vorher ...
Ich verstehe es nicht.
Frisches System. Wollte eine weitere Nummer registrieren:
Selbes Ding: Captcha ok - kein Anruf/SMS ......
Scheint mir ein großes Glücksspiel zu sein :-\
EDIT:Nach ca. 18 Versuchen mit --remove und Neuinstallation hat es nun funktioniert.
Der Captcha-Hash sah aber auch etwas anders aus - mehr Zeichen - als bei den 17 anderen Versuchen.
Vielleicht mehrere Captchas lösen bevor man den Hash wieder einfügt?!
Testen werde ich das jetzt nicht - bin froh, dass das jetzt erstmal funktioniert hat.
Erstmal... besten Dank für die Arbeit so ein Skript und ein entsprechendes Modul zu erstellen. :)
Ich hatte es die letzten Tagen auch mal versucht auf meinen Raspberry1 zu installieren und es lief auch bis zur Eingabe des 6-Digit-Signal-Codes durch - ohne allerdings die Captcha-Abfrage anzuzeigen. Es kam auch kein SMS Code bzw. Anruf an - mehrmals mit verschiedenen Nummer getestet.
Jetzt nehme ich an, dass die entsprechenden SO-Files (libsignal_jni.so/libzkgroup.so) wohl nicht (korrekt) auf meinen Raspberry (armv6l) laufen, da in der Beschreibung nur von armv7l die Rede ist (was mindestens einen Raspberry2 voraussetzt). Richtig?
Auch die JNI-API (hier 52) scheint wohl zu niedrig zu sein, oder? (Leider sind bis jetzt alle meine Versuche ein Java11 auf den Raspberry1 zu installieren gescheitert).
Deshalb schätze ich mal, dass ich mit meinen Raspberry1 den Signalbot nicht nutzen kann, oder besteht noch irgendwie Hoffnung?
Danke.. viele Grüße...
Mit einem Raspberry1 hast du da wohl wirklich schlechte Karten.
Wie du richtig bemerkt hast sind die Libraries für armv7l und als OS wird auch "Buster" vorraus gesetzt.
Die beiden libraries zu übersetzen braucht außerdem sehr viel Resourcen. Mein Raspi4 mit 4GB Speicher schwitzt da schon sehr. Mit 512MB sehe ich da keine Chance.
Also höchste Zeit fürs Upgrade auf einen Raspi4 :) Kost ja nicht die Welt.
Jörg
Hallo,
kurze Rückmeldung von heute:
Ubuntu 20.04 Server auf Proxmox.
Wenn ich kapiert hätte, dass man die Nummer im Skript hinterlegen muss, dann hätte es beim ersten Durchlauf schon geklappt (das werde ich highlighten im Wiki, sobald ich meine Zugangsdaten dazu finde).
Festnetznummer per Voiceaktivierung.
Das Captcha-Ding mit Chrome war etwas fummlig, das sieht nicht so ganz aus, wie auf dem Screenshot, aber man findet es.
Der Key ist schon sehr sehr lang.
Vielen Dank, super Arbeit, liest sich mega kompliziert, war dann aber sehr einfach für mich als Anwender.
Endlich kann ich alle erreichen und nicht nur die Jabbernerds der Familie (mich).
Philipp
Hallo,
ich hatte mir irgendwie, mein FHEM zerschossen, jedenfalls ging Signal nicht mehr.
Also zum Test, habe ich einen "jungfreulichen" Dockercontainer für FHEM erstellt.
Dein Script gestartet.
Bis zur Registrierung lief alles gut. Nur ich wurde nie nach einen captcha gefragt.
hier das Install Log des Scriptes (fehlt)
upps, ich denke mal das LOG ist zu groß und hat den Post gecrasht.
Auszug eine /tmp/signal12345.log Temp files
./signal-cli: 39: cd: can't cd to ./..
./signal-cli: 41: cd: can't cd to /opt/fhem/signal/bin
Error: Could not find or load main class org.asamk.signal.Main
Caused by: java.lang.ClassNotFoundException: org.asamk.signal.Main
Im FHEM Log
2021.07.14 15:39:45.666 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/50_Signalbot.pm line 1256.
connect(unix:path=/var/run/dbus/system_bus_socket): Connection refused at /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm line 144.
Starte ich die Registrierung per signal-cli läuft alles prima inkl Captcha Abfrage.
Dockerfile gemäß WiKi
Wo kann ich nicht suchen? Danke
Zitat von: Adimarantis am 06 Juli 2021, 20:39:07
Also höchste Zeit fürs Upgrade auf einen Raspi4 :) Kost ja nicht die Welt.
Update auf Raspi4 durchgeführt - SignalBot läuft wie am Schnürchen ;D
Nochmal: besten Dank für das tolle Modul!
Ich habe von Telegram auf Signal umgestellt und das Modul läuft sofort stabil. Außerdem habe ich laut dem Freezemon viel weniger Freezes.
Von mir auch besten Dank für das Modul. :)
@BAfH
Hattest du das Problem lösen können?
EDIT:
Ok es scheint mit den librarys und Version 0.8.4.1 noch nicht alles zu stimmen. In der Version am Anfang von diesem Thread steht noch .8.3. damit geht es.
Ich sehe aktuell in der 0.8.4.1 keine wichtigen Fixes/Updates und habe mich aus Zeitmangel auch nicht tiefer damit beschäftigt.
Richtig ist aber, das diese Version neuere native libraries für den Raspi benötigt.
Wer es ausprobieren will, findet hier die passenden:
https://github.com/bublath/FHEM-Signalbot/tree/main/armv7l-0.8.4 (https://github.com/bublath/FHEM-Signalbot/tree/main/armv7l-0.8.4)
Ich hab das auf meinem Testsystem laufen und es scheint zu funktionieren, ist aber nicht tiefgehender getestet.
Sonst bitte weiter 0.8.3 verwenden, was ja auch der Standard des Installationskripts ist.
Gruß,
Jörg
Also Signal-cli läuft mit DBUS und Perl, doch beim define Signal Signalbot stürzt FHEM ab. Ich verwende ich angepasste Docker Version. Der DBUS läuft als root und nicht mit einem extra Benutzer. Vielleicht liegt es ja daran?!
O::Framed::X::EmptyRead: Got empty read; EOF?
==> X::Tiny::create('IO::Framed::X', 'EmptyRead') (called in /usr/local/share/perl/5.28.1/IO/Framed/Read.pm at line 95)
==> IO::Framed::Read::_expand_read_buffer(IO::Framed=HASH(0x6480da8), '65536') (called in /usr/local/share/perl/5.28.1/IO/Framed/Read.pm at line 117)
==> IO::Framed::Read::read_until(IO::Framed=HASH(0x6480da8), '
') (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Authn.pm at line 252)
==> Protocol::DBus::Authn::_read_line(Protocol::DBus::Authn=HASH(0x64fe4d0)) (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Authn.pm at line 99)
==> (eval)(Protocol::DBus::Authn=HASH(0x64fe4d0)) (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Authn.pm at line 96)
==> Protocol::DBus::Authn::go(Protocol::DBus::Authn=HASH(0x64fe4d0)) (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm at line 105)
==> Protocol::DBus::Client::initialize(Protocol::DBus::Client=HASH(0x653fc58)) (called in ./FHEM/50_Signalbot.pm at line 653)
==> main::Signalbot_setup(HASH(0x5e06a48)) (called in ./FHEM/50_Signalbot.pm at line 1241)
==> main::Signalbot_setPath(HASH(0x5e06a48), undef) (called in ./FHEM/50_Signalbot.pm at line 1294)
==> main::Signalbot_Init(HASH(0x5e06a48), 'Signal Signalbot') (called in ./FHEM/50_Signalbot.pm at line 1268)
==> main::Signalbot_Define(HASH(0x5e06a48), 'Signal Signalbot') (called in fhem.pl at line 3894)
==> main::CallFn('Signal', 'DefFn', HASH(0x5e06a48), 'Signal Signalbot') (called in fhem.pl at line 2127)
==> main::CommandDefine(HASH(0x5f28cc0), 'Signal Signalbot', 'define') (called in fhem.pl at line 1265)
==> main::AnalyzeCommand(HASH(0x5f28cc0), 'define Signal Signalbot', 'ACC') (called in fhem.pl at line 1116)
==> main::AnalyzeCommandChain(HASH(0x5f28cc0), 'define Signal Signalbot') (called in ./FHEM/01_FHEMWEB.pm at line 2775)
==> main::FW_fC('define Signal Signalbot', '') (called in ./FHEM/01_FHEMWEB.pm at line 1006)
==> main::FW_answerCall('/fhem&fw_id=101&room=Unsorted&fwcsrf=csrf_145788320052560&cmd=define+Signal+Signalbot') (called in ./FHEM/01_FHEMWEB.pm at line 598)
==> main::FW_Read(HASH(0x5f28cc0)) (called in fhem.pl at line 3894)
==> main::CallFn('WEBtablet_192.168.0.103_50335', 'ReadFn', HASH(0x5f28cc0)) (called in fhem.pl at line 773)
...propagated at /usr/local/share/perl/5.28.1/Protocol/DBus/Authn.pm, line 153
Hi,
das Modul lief schon sehr gut.
Allerdings bekomme ich jetzt folgenden Fehler ausgespuckt:
Error in version:Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Und es funktioniert nichts mehr.
Was kann man tun?
Thx und bis denn
SouzA
Edit:
Bei z.B. "get Signalbot contacts all" kommt
Signal-cli 0.8.1+ required for this functionality
aber es ist
STATE Connected
??
Wie gesagt, es hat schon funktioniert!
Edit 2:
Habe das install-script noch mal ausgeführt.
Jetzt funktioniert es wieder?!
Zitat von: SouzA am 28 Juli 2021, 06:56:06
Signal-cli 0.8.1+ required for this functionality
Wenn die Abfrage der Version fehlschlägt, dann vermutet Signalbot dass signal-cli V0.8.0 hat (da es da noch keine Versionsabfrage gab) und blockiert manche neuere Funktionen.
Schön das es nach dem Install wieder geht. Dieses einfach nochmal auszuführen ist generell ein guter Ansatz. Wo und warum da vorher der Wurm drin war, lässt sich natürlich so nicht sagen.
Jörg
Zitat von: Che007 am 27 Juli 2021, 21:51:29
Also Signal-cli läuft mit DBUS und Perl, doch beim define Signal Signalbot stürzt FHEM ab. Ich verwende ich angepasste Docker Version. Der DBUS läuft als root und nicht mit einem extra Benutzer. Vielleicht liegt es ja daran?!
Der Fehler liegt irgendwo tief in den Abhängigkeiten des Protocol::Dbus Moduls. Ich kann da nur vermuten, das dieses oder eine der vielen Abhängigkeiten in deiner Docker installation nicht oder nicht korrekt installiert sind.
Ein Quercheck wäre mit der Test-Funktion des install scripts zu machen. Dort wird auf 3 Arten (u.a. auch über Perl/Dbus) eine Nachricht abgesetzt - erstmal ganz ohne Signalbot. Das sollte eigentlich mit root funktionieren (lässt man ja mit sudo laufen). Wenn das auch nicht geht, dann musst du dir mal ansehen wie du Protocol::Dbus installierst und ob alle Abhängigkeiten vorhanden sind.
Jörg
Danke Jörg für die Antwort.
Die 3 Sendetests funktionieren.
Ist wohl alles ein wenig seltsam. FHEM startet. Ich definiere Signalbot - FHEM stürzt mit der o.g. Fehlermeldung ab. FHEM startet neu. Signalbot wurde nicht angelegt. Definiere ich es noch einmal klappt es. Ich kann senden etc.
Nur nach einem Neustart kommt FHEM nicht hoch, wegen o.g. Fehler.
Auch das verzögerte Anlegen des Signalbots hilft nicht.
Leider habe ich keine Idee mehr wo ich ansetzen soll.
Kannst du mal versuchen den FHEM start zu verzögern?
Eventuell ist irgendwas noch nicht bereit.
Allerdings müsste ich dann dringend den FHEM Absturz abfangen. Das sollte nicht sein. Schaue ich mir bei Gelegenheit mal an.
Ja hatte ich bereits versucht.
Hatte nach DBus und Signal-Cli start eine Pause von 5 Minuten eingebaut.
Wobei ich auch nach 1 Tag laufenden Diensten und FHEM mal den Signalbot angelegt habe und es trotzdem abgestürzt ist.
Es funktioniert nur, wenn das fhem/fhem Docker Image nach dem Absturz wieder hoch kommt und ich das Gerät dann anlegen. Weiß Gott wieso?!
Morgen,
sorry für die späte Rückmeldung, die Arbeit hat mir keinen Freiraum gelassen.
Ich habe heute den FHEM Test Container:
- gestoppt mit docker rm Containerid -f
- Image gelöscht mit docker rmi Imageid -f
- Conatiner start mit docker-compuse up -d
Das Script geändert auf Version 0.8.3 und über die signal_install.sh in der Console als root gestartet.
Alles wurde soweit installiert, das Install Log hänge ich an, was mir aufgefallen.
Checking for Protocol::DBus...Can't locate Protocol/DBus.pm in @INC (you may need to install the Protocol::DBus module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at /tmp/signal10137.tmp line 5.
BEGIN failed--compilation aborted at /tmp/signal10137.tmp line 5.
Installing latest Protocol::DBus...done
Checking user signal-cli ...Adding user `signal-cli' ...
Adding new group `signal-cli' (1001) ...
Adding new user `signal-cli' (1001) with group `signal-cli' ...
Creating home directory `/home/signal-cli' ...
Copying files from `/etc/skel' ...
created
Checking for /opt/fhem...found
Checking for /var/lib/signal-cli...created
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Downloading signal-cli 0.8.3...done
Unpacking ...
Downloading native armv7l libraries...
done
Updating native x86 since you're on Raspberry...updating: libzkgroup.so (deflated 55%)
updating: libsignal_jni.so (deflated 53%)
done
done
Changing file ownership ...done
No device configuration found, starting process for +493338703585
Continue (y) or skip (N)?y
You can either
(r) register a new device (if that device is already registered e.g. to a smartphone that will be removed)
(l) link to an already registered device (both device will get the messages)
It is recommended to register a new device e.g. a land-line for usage with FHEM
register or link (r/l)r
Registering for +49xxx
Receive registration code for +49xxx by (S)MS or (V)oice (s/v)? v
Registering +49xxx with Voice call
You should get a call or SMS now providing a 6 digit code
Enter this code here:^C
Nichts passiert also Abbruch
in der Signal TMP Log finde ich folgendes
./signal-cli: 39: cd: can't cd to ./..
./signal-cli: 41: cd: can't cd to /opt/fhem/signal/bin
Error: Could not find or load main class org.asamk.signal.Main
Caused by: java.lang.ClassNotFoundException: org.asamk.signal.Main
Der PI ist auf aktuellem Stand.
Hat noch jemand eine Idee, wo ich was suchen oder drehen kann.
Danke
Das Problem habe ich auch, wenn ich das Skript nicht als root laufen lassen, bzw. wenn der signal-cli User benutzt wird.
Ich habe das Skript angepasst, dass alles als root gemacht wird, also ohne extra User.
Du hast ja so recht, machmal ist man auch noch blind... ::)
Danke für den Hinweis.
Zitat von: Che007 am 29 Juli 2021, 10:53:22
Das Problem habe ich auch, wenn ich das Skript nicht als root laufen lassen
Nur, was mir aufgefallen ist, signal-install.sh fragt nie nach einen Chapta
Ich habe anschließend das signal-cli manuell gestartet, das Chapta geholt
cd /opt/fhem/signal/bin
./signal-cli -u +49xxxx register --voice --captcha CHAPTA
Anruf erfolgte
./signal-cli -u +49xxx verify CODEokay, Test mittels
./opt/fhem/signal/bin/signal-cli -u +49xxx send -m "Test FHEM TEST" +49yyy
funktioniert auch, Nachricht empfangen
Anschließend des
./signal_install.sh test
You seem to run in a docker environment. Warning: This is experimental
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt/fhem
Signal config storage: /var/lib/signal-cli
Signal version: 0.8.3
System library path: /usr/lib
Phone number to be used: +49festnetz
You seem to be on a Raspberry pi with armv7l
Your chose the following option: test
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49mobil
Sending a message from command line to +49mobil
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
sudo: unknown user: signal-cli
sudo: unable to initialize policy plugin
Waiting for dbus to become ready..running
Starting signal-cli daemon for Docker
Waiting for signal-cli to become ready........................................Nichts passiert..
Container restart. Keine Änderung.
Das wundert mich auch
sudo: unknown user: signal-cliWas habe ich übersehen oder vergessen....
Zitat von: Che007 am 29 Juli 2021, 10:53:22
Das Problem habe ich auch, wenn ich das Skript nicht als root laufen lassen, bzw. wenn der signal-cli User benutzt wird.
Ich habe das Skript angepasst, dass alles als root gemacht wird, also ohne extra User.
Hast Du da nur im Script was geändert?
#!/bin/bash
SCRIPTVERSION="$Id:2.2$"
# Author: Adimarantis
# License: GPL
#Install script for signal-cli
if [ -z "$PHONE" ]; then
PHONE="+49festnetz"
fi
SIGNALPATH=
/optSIGNALUSER=
signal-cliLIBPATH=/usr/lib
SIGNALVERSION="0.8.3"
SIGNALVAR=/var/lib/$SIGNALUSER
DBSYSTEMD=/etc/dbus-1/system.d
DBSYSTEMS=/usr/share/dbus-1/system-services
SYSTEMD=/etc/systemd/system
LOG=/tmp/signal_install.log
TMPFILE=/tmp/signal$$.tmp
VIEWER=eog
DBVER=0.17
OPERATION=$1
wie sieht dein Dockerfile aus?
Hi,
mein Signalbot versendet noch Nachrichten.
Bei "get Signalbot contacts all" oder "get Signalbot groups all" kommt die Fehlermeldung
Signal-cli 0.8.1+ required for this functionality
Wie gesagt, Messages werden versendet.
Ich bitte um Hilfe.
Vielen Dank!
Bis denn
SouzA
Zitat von: SouzA am 04 August 2021, 05:21:34
Signal-cli 0.8.1+ required for this functionality
SouzA
Dann ist entweder eine veraltete Signal-Cli version installiert oder der "Versionscheck" beim Start ist fehlgeschlagen.
Folgende Dinge kannst du probieren (jede für sich kann bereits helfen)
- Einfach mal ein "set reinit" machen, dann sollte der Versioncheck wiederholt werden
- FHEM restart
- Install Script nochmal laufen lassen (mit Kommandozeilen Option "install" - und nochmal FHEM restart
Wenn das alles nichts hilft mal verbose level hoch und logfiles sammeln, ggf. auch vom syslog.
Jörg
Zitat von: Adimarantis am 04 August 2021, 13:08:20
Dann ist entweder eine veraltete Signal-Cli version installiert oder der "Versionscheck" beim Start ist fehlgeschlagen.
Folgende Dinge kannst du probieren (jede für sich kann bereits helfen)
- Einfach mal ein "set reinit" machen, dann sollte der Versioncheck wiederholt werden
- FHEM restart
- Install Script nochmal laufen lassen (mit Kommandozeilen Option "install" - und nochmal FHEM restart
Wenn das alles nichts hilft mal verbose level hoch und logfiles sammeln, ggf. auch vom syslog.
Jörg
Moin,
danke für Antwort.
Punkt 1. "reinit" hat schon geholfen.
Thx und bis denn
SouzA
Ich habe nochmal einiges probiert.
Vor jede Versuch habe ich immer das Image gelöscht und alles neu erstellen lassen.
Das signal_install.sh läuft jetzt so sauber durch. Das ich meine Rufnummer registrieren kann und eine , wirklich nur einen Testnachricht versenden kann.
Hier ein Auszug
root@e7a4044dfc19:/opt/fhem# ./signal_install.sh test
You seem to run in a docker environment. Warning: This is experimental
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settigns are correct:
Signal-cli User: root
Signal-cli Install directory: /opt/fhem
Signal config storage: /var/lib/root
Signal version: 0.8.3
System library path: /usr/lib
Phone number to be used: +49festnetz
You seem to be on a Raspberry pi with armv7l
Your chose the following option: test
Please enter the number (+49...) of somebody that you can send a test message to
Number:+49mobil
Sending a message from command line to +49mobil
If you get a 'in use, waiting' message, skip by pressing CTRL-C - this is normal when system service is already up and running
1628080015204
Waiting for dbus to become ready..running
Starting signal-cli daemon for Docker
Waiting for signal-cli to become ready...................................................running
Sending a message via dbus-send command
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.asamk.Signal was not provided by any .service files
Sending a message via perl Protocol::DBus
Error getting message
If the recipient got all three messages, your setup looks healthy and you're ready to go to set up Signalbot in FHEM
Im FHEM sehe ich nur setstate Signal 2021-08-04 14:27:21 lastError Error in version:The name org.asamk.Signal was not provided by any .service files
Hat jemand eine Idee, was ich noch ändern kann. Danke
Zitatsetstate Signal 2021-08-04 14:27:21 lastError Error in version:The name org.asamk.Signal was not provided by any .service files
Hat jemand eine Idee, was ich noch ändern kann. Danke
Steht was im syslog? Der Service oder Dbus läuft nicht.
das syslog im Docker habe ich nicht gefunden.
Starte ich den Container sehe ich im Log
2021.08.05 09:16:10.787 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/50_Signalbot.pm line 1256.
connect(unix:path=/var/run/dbus/system_bus_socket): Connection refused at /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm line 144.
Nach einem Restart ist kein Prozess DBUS zu sehen
root@e7a4044dfc19:/opt/fhem# service dbus status
[FAIL] dbus is not running ... failed!
gefunden in der /var/log/signal.err
root@e7a4044dfc19:/opt/fhem# more /var/log/signal.err
INFO DaemonCommand - Exported dbus object: /org/asamk/Signal
ERROR DaemonCommand - Dbus command failed
org.freedesktop.dbus.exceptions.DBusException: Connection ":1.9" is not allowed to own the service "org.asamk.Signal" due to security policies in the configuration file
at org.freedesktop.dbus.connections.impl.DBusConnection.requestBusName(DBusConnection.java:469)
at org.asamk.signal.commands.DaemonCommand.handleCommand(DaemonCommand.java:70)
at org.asamk.signal.App.handleLocalCommand(App.java:211)
at org.asamk.signal.App.init(App.java:171)
at org.asamk.signal.Main.main(Main.java:51)
Dbus command failed
root@e7a4044dfc19:/opt/fhem#
Hilft das weiter.
Zitat von: BAfH am 05 August 2021, 09:51:02
root@e7a4044dfc19:/opt/fhem# service dbus status
[FAIL] dbus is not running ... failed!
Dann ist es ja ziemlich eindeutig. Deine Docker Umgebung hat kein DBus - wahrscheinlich sind die erforderlichen Pakete nicht installiert.
Ich hänge mal mein Docker Install Script an - da kannst du abschauen welche Pakete ich installiere.
Da ich selbst keine Docker-Installation verwende, kann ich jetzt nicht garantieren, das das Script noch funktioniert. Das war nur mal ein Test - soweit ich mich erinnere aber ein erfolgreicher.
Jörg
Guten Morgen.
Ich wollte mir gerade mal Signalbot installieren. Soweit haben alle Schritte geklappt und versenden von Nachrichten ausserhalb von FHEM klappt auch.
Jedoch bekomme ich vom Modul folgenden Fehler:
ZitatError in version:/org/asamk/Signal is not an object provided by this process
Installiert habe ich die Version 0.8.5 von signal-cli.
Anfangs hatte ich das Problem, das libsignal-client nicht gefunden wurde. (https://github.com/AsamK/signal-cli/issues/643). Nach einem Update auf Bullseye läuft die signal-cli aber.
Edit:
Es scheint noch ein Fehler im Dbus vorzuliegen. Ich bekomme folgenden Fehler:
Zitatorg.freedesktop.dbus.exceptions.DBusException: Connection ":1.5" is not allowed to own the service "org.asamk.Signal" due to security policies in the configuration file
konnte ich schon lösen. Bei mir läuft signal-cli unter dem user fhem. Das musste ich in den Configdateien anpassen.
Ok, hat sich erledigt. Jetzt läuft alles. Es lag letztendlich an Berechtigungsproblemen.
Hallo zusammen.
Nachdem ich über den Sommer ein großes "nicht-IT" Projekt realisiert habe, bin ich jetzt wieder dran am Signabot weiterzuentwickeln.
Daher möchte ich mal kurz einen Ausblick geben, was gerade geplant ist:
Eine aktuelle Änderung in signal-cli (die der Autor dankenswerterweise auf meine Anregung aufgenommen hat) wird wohl ab Version 0.8.6 ermöglichen den Service ohne vorherige Registrierung einer Nummer zu starten. D.h. das Installationsscript kann dahingehend vereinfacht werden, dass es eine "blanke" signal-cli Installation zur Verfügung stellt und alles weitere (Nummern linken oder registrieren) aus FHEM heraus geht. Dies ist für mich ein entscheidender Schritt um SignalBot später ins automatische Update aufzunehmen. Hierbei ist es dann auch möglich zwischen mehreren Nummern zu wechseln (vielleicht um auf einer Nummer mitzuhören und eine andere zum Senden zu verwenden).
Meine aktuelle Beta-Version kann schon zwischen Nummern wechseln und auch einen QR Code anzeigen um FHEM zu einer bestehenden Signal App auf dem Smartphone dazuzulinken.
Ein großes Problem ist wie schon im Script, dass die feste Registrierung ein Captcha erfordert. Hier habe ich nach wie vor keinen guten Weg gefunden das Token automatisiert auszulesen (da braucht man wohl einen handler im Browser der auf "signalcapcha://" hört. Wer da Ahnung hat bitte melden.
Sonst wird es wohl darauf rauslaufen, dass ich den Link zum Captcha zwar zum Anklicken anzeigen kann, man aber nach wie vor gleich umständlich das Token suchen und per Copy&Paste einfügen muss. Immerhin kann der Anwender etwas schöner durch die Prozedur geführt werden, als im Script.
Die signal-cli API unterstützt inzwischen noch ein paar weitere Aktionen wie das Löschen von Nachrichten und schicken on "Reactions" (also z.B. eine empfangene Nachricht mit "Daumen hoch" zu markieren) aber da sehe ich eigentlich keinen sinnvollen Anwendungsfall in FHEM - korrigiert mich wenn ich da falsch liege - und plane nicht das einzubauen.
Ich hoffe ich kriege die Änderungen einigermassen Rückwärtskompatibel hin.
Möglicherweise werde ich aber die neuste signal-cli Version "erzwingen" müssen und man muss ggf. einmalig nach dem Update die korrekte Nummer in FHEM definieren (nicht neu registrieren).
Gruß,
Jörg
Zitat von: Adimarantis am 29 August 2021, 23:26:39
Ein großes Problem ist wie schon im Script, dass die feste Registrierung ein Captcha erfordert. Hier habe ich nach wie vor keinen guten Weg gefunden das Token automatisiert auszulesen (da braucht man wohl einen handler im Browser der auf "signalcapcha://" hört. Wer da Ahnung hat bitte melden.
Ich habe mal etwas ähnliches (Token auslesen, 2FA automatisieren) experimentell für den Amazon-Music Login geskriptet und dafür Selenium/Webdriver (https://www.selenium.dev/documentation/webdriver/) verwendet.
Das war allerdings in Python, ob und wie ein Perl-Support vorhanden is, habe ich nicht recherchiert.
Das ganze ist/war aber ziemlich hakelig (sobald es eine Änderung auf der Webseite gibt, muss man sein Skripting wieder anpassen) und der Installationsaufwand für Selenium/Webdriver für ein FHEM-Modul dürfte auch nicht unerheblich sein.
Ich habe mithilfe des signal-cli Forums tatsächlich eine Lösung für Windows gefunden. Der Plan ist dynamisch eine Registry Datei zur Verfügung zu stellen mit der das dann vollautomatisch abläuft.
Für Linux muss es da auch was geben (Stichwort xdg-utils) aber da muss ich noch mal stöbern.
Hier schon mal ein Preview wie das aussehen kann.
Hallo,
das angekündigte Update ist quasi fertig. Es müsste nur noch besser getestet werden.
Das Problem dabei ist, dass die signal-cli Version die dazu nötig ist, derzeit noch nicht released ist und mein Pull Request auf GitHub schon eine Weile auf approval wartet.
Wenn jemand ganz viel Lust hat das Ganze mal auf Herz und Nieren zu testen, könnte ich meine Version (für Raspberry Pi, wenn nötig auch für Ubuntu/Debian X86) zusammenzippen und zur Verfügung stellen.
Bei Interesse per PM melden.
Sobald die nächste signal-cli version (hoffentlich inklusive meiner Patches) released ist, können wir in die öffentliche Beta gehen.
Jörg
Hallo Adimarantis,
vielen Dank für dieses Modul.
Nachdem das Modul SiSi Ende August bei mir plötzlich nicht mehr funktionierte, bin ich auf Signalbot (inklusive Neuregistrierung) umgestiegen. Probleme hatte ich nur beim Auslesen des Captchas mit meinem Standardbrowser Firefox - mit Edge hat es aber funktioniert.
In meiner Automation benutzte ich häufig den FHEM-Befehl msg, um Signal-Nachrichten zu versenden. Mit Signalbot ist dies zur Zeit nicht möglich. Deshalb meine Bitte: Könntest du parallel zu "set Signalbor send" auch "set Signabot msg" einpflegen, damit msg weiterhin benutzt werden kann. Ich habe es so bei mir umgesetzt:
27a28
> "msg" => "textField",
131c132
< if ( $cmd ne "send") {
---
> if ( $cmd ne "send" and $cmd ne "msg") {
207c208
< } elsif ( $cmd eq "send") {
---
> } elsif ( $cmd eq "send" || $cmd eq "msg") {
Vielen Dank
Mal sehen, ich möchte eigentlich die "set" Liste möglichst kurz halten und das "msg" wäre eben ein redundanter Eintrag.
Ich weiss, Telegrambot hat z.B. eine ganze Liste solcher "Aliase". Ich hatte mich eben beim Erstellen des Moduls auf "send" festgelegt.
Grundsätzlich liesse sich hier eine bestehenden Automatisierung per find&replace im fhem.cfg (msg->send) ja recht schnell umstellen.
Findet die Einführung von "msg" als alias für "send" noch weitere Unterstützer? Am Besten einfach den Beitrag "hochvoten" - das ist übersichtlicher als lauter Antworten.
Ich warte aber ohnehin noch das die neue signal-cli Version veröffentlicht wird. Vorher werde ich kein Update machen.
Mit der neuen Version wird das mit den Captchas dann übrigens einfacher. Ich habe inzwischen eine Automatisierung wenn der Browser unter Windows läuft und für Linux zumindest für den Firefox.
Jörg
Ich beschäftige mich jetzt zum ersten Mal mit dem msg-Framework und wollte auch primär Signalbot nutzen (dessen Einrichtung prima geklappt hat). Vielleicht täuche ich mich, aber aus meiner Sicht braucht es keine Unterstützung für msg, da ich einfach msgCmdPush entsprechend mit "send" setze:
attr globalMsg msgCmdPush set %DEVICE% send @%RECIPIENT% %MSG%
Erstmal nur stumpf adaptiert. Aber wie gesagt, lasse mich hier als Newbie auch gerne eines besseren belehren.
Flachzanges Lösungsvorschlag funktioniert!! Wieder etwas gelernt. Besten Dank.
Ich bin mir nicht sicher, ob es vielleicht zu OffTopic ist, aber ich denke schon, dass es eine Spezialiät von Signalbot. Ich möchte gerne über msg eine Nachricht an alle Hausbewohner schicken. Die Nachricht soll aber nicht einzeln an jeden geschickt werden, sondern an eine Signal-Gruppe, in der alle drin sind. FHEM ist bereits Teildieser Gruppe und ich kann Nachrichten an diese Gruppe schicken.
Wie kann ich nun über
Zitatmsg @Hausbewohner Hier Text
die Nachricht in genau diese Gruppe schicken ohne dass ich die Gruppe msg-Befehl direkt erwähne?
Ich habe es bereits versucht mit
Zitatattr Hausbewohner msgContactPush Signalbot:#"Smart Home"
Hausbewohner ist das RESIDENTS device
Signalbot ist das Signalbot Device
"Smart Home" ist die entsprechende Signal-Gruppe.
Danke!
Hilft das vielleicht:
Setze das Attribut defaultPeer auf #gruppenname
Dann kannst du ein "send" ohne weitere Angaben (nur mit dem Nachrichtentext) machen und es landet in der entsprechenden Gruppe.
Gruß.
Jörg
Danke für die schnelle Antwort. Das funktioniert und ist sicherlich ein Workaround geht dann aber leider auch am msg-Konzept vorbei. Der für mich entscheidende Punkt ist, wie msg mit Signalbot interagiert und bei Gruppen scheint das irgendwie zu haken bzw. ich habe ich noch nicht verstanden, wie es funktioniert. Für Einzelempfänger funktioniert es mit
attr globalMsg msgContactPush Signalbot:+49175xxxxxx
Hab mich mit dem "msg" Modul jetzt noch kaum beschäftigt, aber es schaut mir nicht so aus als ob da eine Unterscheidung für Einzelempfänger und Gruppen vorgesehen ist.
Was aber auf jeden Fall geht, ist generell an Gruppen statt Einzelempfänger zu schicken:
attr globalMsg msgCmdPush set %DEVICE% send #%RECIPIENT% %MSG%
attr globalMsg msgContactPush Signalbot:testgruppe
klappt bei mir.
Wenn das "#" Zeichen für msgContactPush eingesetzt wird, dann sehe ich im Logfile noch nicht mal den Versuch Signalbot aufzurufen. "msg" kann da die Device vom Recipient nicht sauber trennen:
msg globalMsg: ID=1631471291.47571.1 TYPE=push ROUTE=SignalBot:#testgruppe STATUS=UNDEFINED PRIORITY=0 TITLE='' 'test'
Wenn ich es aber wie oben konfiguriere kommt korrekt:
msg globalMsg: ID=1631471759.65634.1 TYPE=push ROUTE=SignalBot RECIPIENT=testgruppe STATUS=OK PRIORITY=0 TITLE='' MSG='test'
und ich erhalte auch die Nachricht in meiner Gruppe.
Gruß,
Jörg
Beta Test Signalbot V3
Es ist soweit. Signal-cli 0.9.0 ist released - leider ohne meine Änderungsvorschläge, wofür ich jetzt ein paar Workarounds bauen musste, was aber für die Funktionalität selbst keine große Rolle spielt.
Da mit dieser Version geplant ist ins reguläre FHEM update zu gehen, liegt das jetzt als tgz Archiv mit voller Verzeichnisstruktur bei.
Einfach als user "fhem" im fhem home (also überlicherweise /opt/fhem) entpacken:
tar xf SignalbotV3beta1.tgz
Ausgepackt wird das Modul nach FHEM sowie ein paar Hilfsdateien und der Installer nach www/signal
Testszenarien:
- An sich sollte Signalbot nach einem "shutdown restart" weiter funktionieren (ist ja auch nötig falls jemand Signalbot schon verwendet und nicht mitkriegt, dass "update" seine alte Version überschrieben hat). Hier sollten aber im Modul deutliche Hinweise auf das entsprechende signal-cli update angezeigt werden
- Nachdem der Installer gelaufen ist (dann bitte "shutdown restart" oder zumindest "set reinit") ist der Normalfall wahrscheinlich, dass man genau eine Nummer registriert hat. Signalbot sollte das erkennen und diese automatisch als Standard übernehmen
- Sollten mehrere Nummern registriert sein, dann muss erst mit "set account" eine davon ausgewählt werden oder eine weitere Nummer registriert werden.
- Wenn noch gar nichts registriert ist gibt es fast den selben Hinweis, nur das jetzt zwingend mit "set register" der Registrierungsprozess gestartet werden muss. Das könnt ihr testen indem ihr mit
sudo mv /var/lib/signal-cli/data /var/lib/signal-cli/data.org
die alte Registrierung wegschiebt ("sudo service signal restart" nicht vergessen).
- Grundsätzlich ist es kein Problem die selbe Nummer testweise nochmal zu registrieren (ich würde allerdings vorsichtshalber die neue Registrierung auch weiter verwenden, anstatt die alte wiederherzustellen)
Sonst will ich jetzt gar nicht gross mehr Anleitung geben, da der Registrierungsprozess wie eine Art "Wizard" geführt wird und damit hoffentlich selbsterklärend ist.
Bitte ruhig kreuz und quer rumprobieren. Ich hab sicher nicht alle möglichen Fehlerfälle und Benutzereingaben abgedeckt. Wenn was auffällt bitte mit Loglevel 5 nachstellen und posten (oder per PM, dann braucht ihr nicht zwangsweise die Telefonnummer rauszulöschen - ich gelobe die PM nach Durchsicht zu löschen und die Nummern nicht für Werbezwecke zu verwenden :) )
Gruß,
Jörg
Bei mir hängt sich install.sh auf...
ZitatLinux fhem-fhem0 4.4.180+ #41890 SMP Fri Jun 25 02:37:14 CST 2021 x86_64 GNU/Linux
has not been tested, continue at own risk
This will update system packages, install or uninstall signal-cli
system : prepare required system package (except signal-cli)
install : install signal-cli and setup as dbus system service
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
start : Start the signal-cli service (or respective docker processes)
all : Run system, install, start and test (default)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Running in Docker, performing apt update/upgrade...Hit:1 https://deb.nodesource.com/node_10.x buster InRelease
Hit:2 https://cdn-aws.deb.debian.org/debian buster InRelease
Hit:3 https://cdn-aws.deb.debian.org/debian-security buster/updates InRelease
Hit:4 https://cdn-aws.deb.debian.org/debian buster-updates InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
done
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for Protocol::DBus...V0.19 found
Checking user signal-cli ...Adding user `signal-cli' ...
Adding new group `signal-cli' (1000) ...
Adding new user `signal-cli' (1000) with group `signal-cli' ...
The home directory `/home/signal-cli' already exists. Not copying from `/etc/skel'.
created
Checking for /opt/fhem...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.9.0
signal-cli matches target version...ok
Starting dbus daemon for Docker
Waiting for dbus to become ready..running
Starting signal-cli daemon for Docker
Waiting for signal-cli to become ready..........
...ab hier geht es nicht mehr weiter. Das Docker Protokoll sagt: "connect(unix:path=/var/run/dbus/system_bus_socket): Connection refused at /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm line 144."
Guten Morgen,
ich habe gerade das Script auf einer frischen FHEM-Installation getestet. Die Installation endet mit folgender Fehlermeldung:
Checking for /etc/systemd/system/signal.service.../etc/systemd/system/signal.service installed
Created symlink /etc/systemd/system/dbus-org.asamk.Signal.service -> /etc/systemd/system/signal.service.
Created symlink /etc/systemd/system/multi-user.target.wants/signal.service -> /etc/systemd/system/signal.service.
Start signal-cli service
Checking installation via dbus-send command...Error org.freedesktop.dbus.errors.UnknownMethod: The method `org.asamk.Signal.isRegistered' does not exist on this object.
Sending a message via perl Protocol::DBus...Error getting reply
Jedoch scheint danach alles zu laufen:
Internals:
CFGFN
FD 4
FUUID 614182f1-f33f-df6c-5561-a013bf20afb00d4a
NAME mySignalbot
NOTIFYDEV global
NR 20
NTFY_ORDER 50-mySignalbot
STATE Connected to /org/asamk/Signal/_49XXX
TYPE Signalbot
VERSION Signalbot:3.0beta signal-cli:0.9.0 Protocol::DBus:0.19
READINGS:
2021-09-15 05:26:46 account +49XXX
2021-09-15 05:21:54 joinedGroups
2021-09-15 05:26:46 lastError ok
2021-09-15 05:27:25 sentMsg Testnachricht
2021-09-15 05:27:31 sentMsgRecipient +49XXXX
2021-09-15 05:27:31 sentMsgTimestamp 15-09-2021 05:27:25
helper:
accounts 1
captcha 03AGdBq25E6cM1xMWWUjx606UtWg-zTIotfkfVhhiK6C-ecHDU22b2xmx-s3HKMrZXc-S9brXQO7JOPPwSk9tdnpw-UWchtsQcYyPkgtd8XF54cMqeIHms79zJjQ1J0-Imwwxun_j2cu8Ap8TA7tljLxunHowQP7Lq1HiukUXST6x8jxph7PBRv0eA3YDcrfqkxFPwVzcd-_XVRvLgFLfZeZxxQ1cnA7Z1dYAv2PUCWWY4PQVzNMPzgKaO9UEXDIlUdql7Z69NMy5I9ok7vU5CRZk09IcuP3-tkmRsaZ7L6wlCTbylTiLfr3xJ2D9_YxAHoSFzOrPOTlYzYhVCofjHyimW688koDh1Vqsxm0L2IQpVS4r-w3eZSs_yDk4qix8_L31SgND4B3k8kfIQ3mJrUTwuUDzlN37M696P1c_Vo_zg0qRfAgyzd3JIWwqTsj5_HpRb3o9nHJh-
init :1.34
multi 1
qr
register
signalpath /org/asamk/Signal/_49XXX
verification
version 900
contacts:
+49XXX
+49XXX
Attributes:
registerMethod Voice
Edit:
Übrigens funktioniert die Captcha-Abfrage über den Browser nicht, da ich ein csrf-Error erhalte:
2021.09.15 05:24:54 3: FHEMWEB WEB CSRF error: ne csrf_YYYYYYYYYYYYYY for client WEB_172.16.40.10_46764 / command set mySignalbot captcha signalcaptcha://03AGdBq26R30L-rSsjsYpeD-aLGiODeDZYVlwwtcDhcyLpik916fUwIZoKhcZJ2QirST2eQzxV7-rIm95qF0Y4l1HEO5zrFfoHV6pSRqQrRWuiiPNeKs2TmH5Exsp5WnUSshrkIH65ZnJ5S8ag_0MQu9nrDNhSi1VqkjjkQMFJ4riV0eszG96xdnB7BN8gyfgdHiqmgQdnrFtpbiNUBxxgu-srnoXYO5dn43whg5XmjMLpXjYLKb8Ckbu1sz18JqzQg9TvXqUuUdy0z422KelQl_85VhiOkSeX9d85fj83K49YdPoqIQ94QB0eHHjaTYERlYsl7XhAC-sbdJaeZQCpnar-ww8GAZG1Sx5B8Q7GR0C3NGxHwNnwKM-UO_I39EYx_Uv4Z6uvEp07-e3GE7T0ZEbKjTuH3M0GR7R-iONfmXJIv5Fi78bVw81ElNjDGJjOi9yV6oGwVGD_. For details see the csrfToken FHEMWEB attribute.
ZitatChecking installation via dbus-send command...Error org.freedesktop.dbus.errors.UnknownMethod: The method `org.asamk.Signal.isRegistered' does not exist on this object.
Sending a message via perl Protocol::DBus...Error getting reply
Das kann ignoriert werden. Da habe ich im Rahmen des workaround (weil meine Änderung in signal-cli noch nicht akzeptiert wurden) vergessen auf eine andere test-funktion umzustellen.
Zitat...ab hier geht es nicht mehr weiter. Das Docker Protokoll sagt: "connect(unix:path=/var/run/dbus/system_bus_socket): Connection refused at /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm line 144."
Hmm.. ok - den Docker-spezifischen Teil habe ich nicht getestet, muss ich mir ansehen. Danke.
Jörg
Hi Jörg,
sudo -u $SIGNALUSER ./signal-cli --config $SIGNALVAR -u $PHONE daemon --system >/var/log/signal.log 2>/var/log/signal.err &
Liefert
./signal-cli: 39: cd: can't cd to ./..
./signal-cli: 41: cd: can't cd to /opt/fhem/signal/bin
Error: Could not find or load main class org.asamk.signal.Main
Caused by: java.lang.ClassNotFoundException: org.asamk.signal.Main
Ich verstehe leider nicht, warum der Verzeichniswechsel nicht von statten gehen kann.
$PHONE ist ein Überbleibsel von der Vorversion?
Meine Dockerinstallation (extra script) installiert signal-cli unterhalb vom fhem in /opt/fhem/signal
Die Standardinstallation unter /opt/signal
Einfach so funktioniert das ist.
Das "-u" ist zwar wirklich ein Überbleibsel, würde aber erstmal nichts ausmachen solange $PHONE die korrekte Telefonnummer enthält.
Wenn du unter Docker eine Standardinstallation machen willst, dann musst die am Anfang vom Script die Dockererkennung entfernen. Das ist aber alles nicht supported.
Docker würde ich mir in einem weiteren Schritt ansehen, wenn ich weiss, dass die normale Installation sauber läuft.
Jörg
ZitatÜbrigens funktioniert die Captcha-Abfrage über den Browser nicht, da ich ein csrf-Error erhalte:
Ok, das habe ich bei mir deaktiviert (ich glaube das hat mit IFTTT damals Probleme gemacht - aber das verwende ich inzwischen nicht mehr)
Sollte eigentlich möglich sein das Token in die generierten .reg bzw. mime Files zu integrieren. Nachteil ist natürlich, das man nach jeden FHEM Neustart diese Files neu installieren muss.
Muss ich mir ansehen.
Jörg
Um die Installation zu vereinfachen experimentiere ich gerade mit Debian packages.
Letztendlich ist dann das Installer Script nicht mehr notwendig sondern es muss nur Protocol::DBus von cpan installiert werden:
sudo cpan install Protocol::DBus
Sowie der signal-cli service über apt für Ubuntu (20.04+ , für 18.04 passt die glibc version nicht)
sudo apt-get install -f ~/signal-cli-dbus_0.9.0-1_amd64.deb
bzw. für Raspberry (Buster)
sudo apt-get install -f ~/signal-cli-dbus_0.9.0-1_armhf.deb
Die Packages liegen jetzt erstmal testweise auf meinem Google Drive. Evtl. lege ich die dann zukünftig auf das FHEM SVN oder es hat jemand eine bessere Idee.
amd64:
https://drive.google.com/file/d/1R3H8lghA452kevxbhu7q8O492gc7LmMc/view?usp=sharing
Armhf:
https://drive.google.com/file/d/1s-ykv5LCtlol9mMJf9SWX32orld8HDOT/view?usp=sharing
Damit sollte es auch recht einfach sein ein bestehendes FHEM Docker Installationsscript zu erweitern:
RUN cpan install -f Protocol::DBus
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y -f ~/signal-cli-dbus_0.9.0-1_amd64.deb
Im Docker hab ich das jetzt noch nicht getestet aber auf meinem Raspberry bzw. meiner Ubuntu VM läuft das soweit.
Die Abhängigkeiten zu Dbus and Java sollten eigentlich von apt-get aufgelöst werden, aber es ist möglich, das ich noch nicht alle Abhängigkeiten erfasst habe.
Jörg
Update für das csrf Token Problem.
Wenn FHEM ein csrf Token verwendet, wird dieses jetzt im jeweiligen .reg / .desktop file mitgeneriert.
Wichtig: Sofern ein zufälliges Token verwendet wird, muss dieses dann neu geholt und installiert werden, wenn FHEM neu gestartet wurde.
Getestet habe ich das bisher aus Zeitgründen nur für zufälliges Token (=Attribut in FHEMWEB nicht gesetzt) und Windows.
Hallo Jörg,
ZitatEvtl. lege ich die dann zukünftig auf das FHEM SVN oder es hat jemand eine bessere Idee.
D.h. derzeit kommen Updates noch nicht per Fhem update, sehe ich das richtig?
Für mich ist jeder Updateprozess in Ordnung, solange ich ihn nachvollziehen und mit meinem beschränkten Wissen ausführen kann.
Wenn du soweit bist, dass Updates per Fhem oder sonstwie eingespielt werden können, wäre es schön, wenn du einen Fahrplan für die Anwender bereithalten könntest, die dein nützliches Modul jetzt schon nutzen.
Viele Grüße Gisbert
Hallo Gisbert,
richtig, bisher geht noch nichts über FHEM Update - da möchte ich erst noch etwas mehr Test Feedback und ein paar Kleinigkeiten bezüglich der Ablage der Files sind auch noch zu klären.
Es wird auf jeden Fall so ablaufen, dass du als "alter" Anwender keine Probleme bekommst. Das dann verteilte Modul ist rückwärtskompatibel mit deiner jetzigen Umgebung.
Es wird dich aber "nerven" auf die neuere signal-cli Version zu gehen - welche aber nur zwingend für die neuen Features erforderlich ist. Alle Hinweise erscheinen in FHEM, so dass auch Anwender die hier nicht ständig mitlesen die notwendigen Infos haben.
Gruß,
Jörg
Release Candidate: Signalbot V3
Sofern keine signifikanten Bugs gefunden werden, plane ich diese Version demnächst per Update zur Verfügung zu stellen.
Zur Installation einfach das Modul ersetzen und entweder "shutdown restart" oder "reload 50_Signalbot" (dann aber bitte "set reinit").
Das Modul funktioniert weiter mit älteren signal-cli Versionen, wird sich aber beschweren, dass ihr ein Update auf 0.9.0 machen sollt. Der Update Prozess ist im Modul beschrieben.
Das Modul lädt selbstständig das aktuelle Installer script nach ~fhem/www/signal von https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/ oder per Download link im Modul.
Dieses dann wie gewohnt mit
sudo ./signal_install.sh
ausführen. Ist aber einiges schlanker und benötigt keine Angabe der Telefonnummer mehr. Diese wird übernommen bzw. im Modul konfiguriert und registriert.
Alternativ findet ihr unter https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signal-cli-packages/ auch Debian packages (siehe README).
Diese installieren aber nur signal-cli - d.h. fehlende Perl Module oder andere FHEM spezifische Abhängigkeiten müssen ggf. nachinstalliert werden.
Docker wird für signal-cli nicht unterstützt. Ein im Docker installiertes FHEM wird wahrscheinlich Probleme haben mit dem DBus zu kommunizieren. Dazu muss man denke ich /run/dbus/system_bus_socket im FHEM container sichtbar machen und eben signal-cli mit apt (außerhalb vom Docker) installieren. Wer das Modul bereits in einem Container betreibt, sollte dieses aber auch nach dem Update weiter betreiben können. Sofern auch signal-cli geupdated werden soll muss das manuell erfolgen (bin und lib austauschen, signal-service script ohne -u )
Neue Funktionen sind mit älteren signal-cli Versionen ausgeblendet und ohnehin hauptsächlich für die Registrierung interessant.
Englische Anleitung im Modul ist angepasst. Wiki folgt wenn ich Zeit habe (das möchte ich noch aktualisieren, bevor ich das Modul per Update verteile).
Dann bin ich mal gespannt auf Rückmeldungen.
Gruß,
Jörg
Ich habe es gerade mal schnell gemacht. Zwei Anmerkungen:
1) Das Skript muss in der Regel noch ausführbar gemacht werden "chmod +x"
2) Ich musste nach dem Beenden des Skripts signal.service einmal neustarten, damit Version 0.90 geladen wird.
Ansonsten keine Auffälligkeiten wahrgenommen.
Grundsätzlich: Vielen Dank!
Danke für die Rückmeldung.
Das Installerscript hat beim "upgrade" den Service nur gestartet (aber nicht neu gestartet - ist wohl versehentlich bei den Aufräumarbeiten rausgefallen). Sollte jetzt wieder der Fall sein.
Wenn signal_install.sh nach www/signal geladen wird, werde ich jetzt das +x setzen. Beim normalen "Download" funktioniert das natürlich nicht, daher hab ich den Hinweis jetzt im Wiki https://wiki.fhem.de/wiki/Signalbot ergänzt. Dort habe ich übrigens jetzt schon die V3 updates weitgehend eingepflegt.
Wer mag, darf gerne mal Querlesen und Verbesserungsvorschläge geben.
Auf meiner TODO liste steht noch die Docker Installation zu reparieren und zu testen..... (steht momentan überall als "unsupported")
Hallo Adimarantis,
ich benutze gerade noch die folgenden Versionen: Signalbot:2.2 signal-cli:0.8.1 Protocol::DBus:0.19
Jetzt moechte ich auf die Signalbot:3.0 Version updaten, aber ich bekomme die 0.9.0 von signal-cli nicht installiert,
Die Ubuntu versionen mit dem .deb package installieren nicht (der signal service started nicht), für Buster habe ich die falsche Architekur.
Wie kann ich die 0.9.0 von signal-cli installieren?
jamo@inuc:~$ uname -r
4.19.0-17-amd64
jamo@inuc:~$ cat /etc/debian_version
10.10
jamo@inuc:~$ cat /proc/version
Linux version 4.19.0-17-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-3 (2021-07-18)
Ich habe gesucht und gelesen das man sich bestimmte libraries selber compilieren muss, aber die vorgehensweise ist unterschiedlich und ich traue mir nicht zu das zu machen ohne mir mein System zu zerschiessen.
Kannst Du oder jemand anderes helfen? Danke!
Debian 10.10 scheint glibc-2-28 zu verwenden,das hab ich tatsächlich leider nicht im Programm.
Im Prinzip ist es kein Hexenwerk die beiden Libraries selber zu übersetzen.
Ich gehe jetzt davon, dass signal-cli per install script oder apt installiert wurde (egal welches).
Erstmal brauchst du "rust":
sudo curl https://sh.rustup.rs -sSf | sh
Dann die zkgroup libs übersetzen:
git clone git@github.com:signalapp/zkgroup.git
cd ffi/java
make
Da kommt am Schluss ein Fehler, den kann man aber ignorieren, wenn die library erfolgreich erzeugt wurde.
libzkgroup.so aus target/release/ nach /opt/signal/lib kopieren
Die libsignal-client übersetzen:
git clone git@github.com:signalapp/libsignal-client.git
cd java
./build_jni.sh desktop
libsignal_jni.so aus target/release/ nach /opt/signal/lib kopieren
Libraries ersetzen:
cd /opt/signal/lib
sudo -u signal-cli zip -u signal-client-java-*.jar libsignal_jni.so
sudo -u signal-cli zip -u zkgroup-java-*.jar libzkgroup.so
Dann service neu starten
sudo service signal start
Und dann läuft die Sache hoffentlich.
Jörg
Hallo Joerg,
danke erstmal, sehr hilfreich. Die Dateien sind soweit compiliert nach deiner Anleitung, aber jetzt bekomme ich:
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 Wed 2021-09-22 22:32:41 CEST; 9s ago
Process: 24416 ExecStart=/opt/fhem/signal/bin/signal-cli --config /var/lib/signal-cli -u +491234567890 daemon --system (code=exited, status=1/FAILURE)
Main PID: 24416 (code=exited, status=1/FAILURE)
Sep 22 22:32:41 inuc systemd[1]: Starting Send secure messages to Signal clients...
Sep 22 22:32:41 inuc signal-cli[24416]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource1448454141144256459.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource1448454141144256459.so)
Sep 22 22:32:41 inuc signal-cli[24416]: Missing required native library dependency: libsignal-client
Sep 22 22:32:41 inuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Sep 22 22:32:41 inuc systemd[1]: signal.service: Failed with result 'exit-code'.
Sep 22 22:32:41 inuc systemd[1]: Failed to start Send secure messages to Signal clients.
Das sieht nach unlösbarem Problem aus, oder? Was ich gegoogled habe muss ich noch was kompilieren, oder gcc upgraden....
Eine kurze Recherche sagt, dass GLIBC 2.29 erst ab Kernel 4.20 dabei ist. Buster fährt noch mit 4.19. Eine Möglichkeit wäre es mit einem Backport-Kernel zu testen.
Compiliert wurde anscheinend für glibc 2.29 - nur findet der die nicht (und ich hätte eigentlich 2.28 erwartet)
was sagt den
ldd --version
@Flachzange: Wenn auf dem selben System compiliert wird, dann würde ich eigentlich erwarten dass das zusammenpasst.
ldd --version
ldd (Debian GLIBC 2.28-10) 2.28
Hi Jamo,
also da ist dann irgendwas faul in deinem System. ldd schaut ok aus, aber warum übersetzt er dann für 2.29? Hast du schon mal ein einfaches Programm übersetzt und geschaut ob das läuft? Alle Pakete aktuell?
Vielleicht solltest du einfach auf Debian 11 updaten, falls da generell ein Wurm drin ist.
Jörg
Hallo Joerg,
danke erstmal aber ich verstehe das nicht. Vielleicht kannst Du mir das nochmal erklären.
Bevor ich die beiden libraries laut deiner Anleitung übersetzt habe, habe ich mit sudo apt install ./signal-cli-dbus_0.9.0-1_glibc2.31_amd64.deb die beiden Ubuntu pakete installiert (manchmal funktionieren ja die Ubuntu auch für Debian).
Was meinst Du mit ''warum übersetzt er dann für 2.29''? ''Was'' habe ich mit 2.29 übersetzt, und kann ich das wieder entfernen und nochmal übersetzten?
Er meckert ja nicht die beiden Dateien 'libsignal_jni.so' und 'libzkgroup.so' an, die ich als einzige kopiert habe, sondern /lib/x86_64-linux-gnu/libm.so.6. Die ist bei mir von May 2019 und zeigt auf
lrwxrwxrwx 1 root root 12 May 1 2019 /lib/x86_64-linux-gnu/libm.so.6 -> libm-2.28.so
Danke erstmal.
Bevor ich die beiden libraries laut deiner Anleitung übersetzt habe, habe ich mit sudo apt install ./signal-cli-dbus_0.9.0-1_glibc2.31_amd64.deb die beiden Ubuntu pakete installiert (manchmal funktionieren ja die Ubuntu auch für Debian).
Ich fürchte damit hast du dein System inkonsistent gemacht.
Schmeiss das wieder runter und installiere vorsichtshalber die passende glibc (2.28) nochmal
Dann nochmal libraries compilieren.
Hallo Jörg,
TADA TADA!
Signalbot:3.0beta3 signal-cli:0.9.0 Protocol::DBus:0.19
Nachdem ich deinem Rat gefolgt bin, und nochmal compiliert habe, habe ich gemerkt, das ich beim ersten Mal die Libraries gar nicht ersetzt hatte:
cd /opt/signal/lib
sudo -u signal-cli zip -u signal-client-java-*.jar libsignal_jni.so
sudo -u signal-cli zip -u zkgroup-java-*.jar libzkgroup.so
Nachdem ich das jetzt gemacht hatte, funktionierts.
DANKE Dir für die Geduld und die Erklärungen.
Letzte Frage(n):
Ich bekomme im FHEM-Modul folgende Meldung: Signal-cli is running in single-mode, please consider starting it without -u parameter (e.g. by re-running the installer)
Deswegen habe ich in /etc/systemd/system/signal.service unter ExecStart den -u parameter geloescht, aber das funktioniert nicht. Ich bekomme folgendes:
1) Liegts daran das der user fhem ist, und nicht signal-cli?
2) Was heisst genau "single-mode"? Im Wiki finde ich nichts.... Was ist der Vorteil/Nachteil für mich?
3) Im Log erscheint folgende Fehlermeldung: PERL WARNING: Use of uninitialized value $multi in numeric eq (==) at ./FHEM/50_Signalbot.pm line 1638.
4) Ich kann die kompilierten Libraries für Debian 10/amd64 zur Verfügung stellen, falls das für jemanden anderes nützlich ist. Bitte melden.
jamo@inuc:/opt/fhem/FHEM$ sudo 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 Thu 2021-09-23 13:11:48 CEST; 10s ago
Process: 11890 ExecStart=/opt/fhem/signal-cli/bin/signal-cli +4912123456789 --config /opt/fhem/.local/share/signal-cli daemon --system (code=exited, status=1/
Main PID: 11890 (code=exited, status=1/FAILURE)
Sep 23 13:11:48 inuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Sep 23 13:11:48 inuc systemd[1]: signal.service: Failed with result 'exit-code'.
Sep 23 13:11:48 inuc systemd[1]: Failed to start Send secure messages to Signal clients.
Die Telefonnummer gehört zum "-u" Parameter und muss auch weg.
Single Mode heisst du hast eine dedizierte Nummer. Das ist quasi die alte Art und Weise.
Jetzt kann man zwischen mehreren Nummer wechseln. Hat erstmal keinen Nachteil für dich, außer der nervigen Meldung :)
Die Libraries kannst du mir gerne irgendwo zur Verfügung stellen, dann mach ich damit noch ein .deb Paket
Fehlermeldung schau ich mir an - da hab ich wohl einen Fall noch nicht richtig behandelt, sollte aber an der Stelle erstmal harmlos sein.
Jörg
Hallo Jörg,
danke nochmal, hier die beiden Libraries.
Danke Jamo,
(edit: Dateien umgezogen, da svn.fhem.de dafür der falsche Platz war)
unter http://fhem.bublath.de/ finden sich somit aktuell 4 Varianten von .deb packages.
- Raspbian Buster
- Ubuntu 18.04
- Ubuntu 20.04
- Debian Buster
Bitte beachten, dass diese Packages nur den Betrieb von signal-cli sicherstellen sollen und ggf. trotzdem Perl Module für Signalbot auf dem System fehlen könnten.
Ich habe jetzt auch mein Docker Script wieder aktualisert und etwas getested. Es ist im Wiki: https://wiki.fhem.de/wiki/Signalbot (https://wiki.fhem.de/wiki/Signalbot) verlinkt und beschrieben.
Ein paar Tage Test möchte ich noch abwarten, dann werde ich das Modul über Update verteilen.
Jörg
Ich würde gerne die Gelegenheit nutzen mich für das Modul zu bedanken. Es läuft wirklich gut und die Doku im Wiki ist vorbildlich. Auch die kleinen Extras wie das "Command-Notify" mit GoogleAuth sind klasse.
Drei kleinere Verbesserungsvorschläge, die weitestgehend kosmetischer Natur sind:
1) Unterstützung für Gruppen im Command Notify. Wenn die Nachricht aus einer Gruppe kam, soll sie auch zurück in die Gruppe (command-Notify:14)
my $msgGroup = ReadingsVal("Signalbot", "msgGroupName", "");
my $msgSender = ReadingsVal("Signalbot", "msgSender", "");
if ($msgGroup ne "") {$msgSender = "#" . $msgGroup;}
elsif (substr($msgSender, 0, 1) ne "+") { $msgSender = "@" . $msgSender }
2) Verhinderung einer Perl Warning, wenn man nur den favprefix schickt (command-Notify:26)
# ggf. Favoriten auflösen
if ($favPrefix && substr($msgText, 0, length($favPrefix)) eq $favPrefix) {
$favno = $favPrefix eq $msgText ? 0 : int(substr($msgText, length($favPrefix)));
@favarray = split(";", AttrVal("Signalbot", "favList", undef));
3) UTF-8 Encoding im Log (50_Signalbot.pm:345)
Log3 $hash->{NAME}, 3 , $hash->{NAME}.": Before parse:" . encode_utf8($fullstring) . ":";
Wenn Blödsinn gerne ignorieren.
Gruß
Chris
Hi Chris,
Schau ich mir mal an.
Die Favoriten im Wiki sind "Fremdcode" von @Weini.
Wenn die Nachfrage nach dem Feature größer wird, müsste man wohl mal darüber nachdenken, wie man das integriert.
Jörg
Hi Chris!
Danke dir für die Anmerkungen. Ich habe 1) & 2) jetzt bei mir eingebaut und möchte ein wenig testen. Wenn keine Probleme auftreten, dann übernehme ich das so ins Wiki.
weini
Punkte 1) & 2) sind jetzt im notify code im Wiki enthalten.
@Flachzange: Vielen Dank dir!
Ich habe das Modul soeben ins SVN gepushed. Sollte ab morgen über UPDATE verfügbar sein.
Habe von einer manuellen Installation (mit anderen Pfaden) mithilfe des Installations-Skriptes neu installiert und erfolgreich meinen registrierten Account da hinein migriert; außerdem aus dem SVN die neue Signalbot.pm geholt und eingebaut.
Läuft. Danke für deine Arbeit!
erstmal danke für das Modul, es läuft fantastisch :)
nur falls es mal jemand braucht
um z.B. eine Test- oder alte Nummer (bei mir nach Rufnummerwechsel) deregistrieren will
sudo service signal stop
cd /opt/signal/bin
sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +49xxxx unregister --delete-account
sudo service signal start
und dann noch ein
set reinit
das heisst ich habe vorsichtshalber noch unter /var/lib/signal-cli/data
noch den entsprechenden Ordner/Datei entfernt
keine Ahnung ob das nötig gewesen wäre
aber ich dachte mir sicher ist sicher
Grundsätzlich dürfte es reichen unter /var/lib/signal-cli die Daten für die entsprechende Nummer zu löschen.
Kann sein das dann auf dem Signal Server noch "Reste" übrigbleiben, aber da eine erneute Registrierung die alte überschreibt, ist das unbedenklich.
Die von @Brause beschriebene Option ist natürlich noch sauberer.
Es gibt bereits einen pull-request um die unregister Funktion auch über DBus zur Verfügung zu stellen. Außerdem gibt es weitere Funktionen wie z.B. eine Registrierung mit einer PIN zu schützen, die bereits commited sind. Sobald diese diese Änderungen in die nächste offzielle signal-cli Release einfliessen, kann ich sie gerne auch per Signalbot zur Verfügung stellen.
Jörg
Hallo Jörg,
ich habe eine Installation laufen.
Wenn ich in Fhem ein generelles Update (update all) mache, dann wird dein Modul jetzt auch erneuert.
Muss ich dann noch irgendetwas machen, bzw. berücksichtigen als "Alt"-User?
Ich zögere etwas, da ich nicht weiß, ob und wieviel Zeit ich anschließend benötige, bis es wieder läuft.
Viele Grüße Gisbert
Hallo Gisbert,
Über "Update all" sollte das Modul erst morgen drin sein (ich glaube morgends um 7 läuft der Job der Änderungen übernimmt).
Aber gründsätzlich:
- Du musst erstmal nichts machen. Das Modul wird sich zwar in der Detailseite über die veraltete signal-cli Version beschweren, wird aber weiter seinen Dienst verrichten
- Auch nachdem du die signal-cli Version auf 0.9.0 per Script (nach Neustart/Reinit des Moduls unter www/signal zu finden) aktualisiert hast, musst du nichts weiter tun
- Wenn du auf Nummer sicher gehen willst, dann sichere dir vorher die alte 50_Signalbot.pm Datei weg. Falls irgendwas nicht geht, kannst du damit das Update rückgängig machen
Die meisten Änderungen betreffen neue Nutzer, die jetzt die Registrierung bequem aus Signalbot heraus machen können. Alles andere ist eigentlich unverändert geblieben.
Gruß,
Jörg
Zitat von: Gisbert am 27 September 2021, 20:11:29
Ich zögere etwas, da ich nicht weiß, ob und wieviel Zeit ich anschließend benötige, bis es wieder läuft.
Moin Gisbert,
ich habe mir die aktuelle Version eben aus dem SVN geholt. Kommt sonst morgen nach 8:00 Uhr. Habe den Installer laufen lassen und FHEM neu gestartet. Danach war alles als wenn nichts passiert wäre. Super! Danke an Jörg!
VERSION
Signalbot:3.0 signal-cli:0.9.0 Protocol::DBus:0.19Gruss
Enno
Hallo Jörg,
hallo Enno,
der Umstieg war tatsächlich sehr einfach.
Ein ganz dickes Lob für Jörg, erstens für das Modul und zweitens für den reibungslosen Updateprozess, der nun in Fhem integriert ist.
Viele Grüße Gisbert
Hallo,
bei mir lief bereits die Vorgänger Version erfolgreich.
Jetzt wollte ich auf die neue Version updaten.
Leider ohne Erfolg.
dieter@intelnuc:~$ sudo ./signal_install.sh
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.0
System library path: /usr/lib
You seem to run Ubuntu on x86_64
This will update system packages, install or uninstall signal-cli
system : prepare required system package (except signal-cli)
install : install signal-cli and setup as dbus system service
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
start : Start the signal-cli service (or respective docker processes)
all : Run system, install, start and test (default)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? Y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for /usr/share/perl5/URI.pm...available
Checking for Protocol::DBus...V0.19 found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.9.0
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
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.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Sending a message via perl Protocol::DBus...Error getting reply
Kann jemand weiter helfen?
Danke und Gruß
Dieter
Hallo Dieter,
was sagen denn
systemctl status signal.service
journalctl -xe
Zitat von: Ralli am 01 Oktober 2021, 10:34:50
Hallo Dieter,
was sagen denn
systemctl status signal.service
journalctl -xe
Hallo und danke für deine Unterstützung.
● 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 2021-10-01 09:09:26 CEST; 1h 26min ago
Process: 7125 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1
Main PID: 7125 (code=exited, status=1/FAILURE)
Okt 01 09:09:25 intelnuc systemd[1]: Starting Send secure messages to Signal clients...
Okt 01 09:09:26 intelnuc signal-cli[7125]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource5225696170
Okt 01 09:09:26 intelnuc signal-cli[7125]: Missing required native library dependency: libsignal-client
Okt 01 09:09:26 intelnuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Okt 01 09:09:26 intelnuc systemd[1]: signal.service: Failed with result 'exit-code'.
Okt 01 09:09:26 intelnuc systemd[1]: Failed to start Send secure messages to Signal clients.
Und hier noch ein Auszug aus dem syslog
Oct 1 09:08:35 intelnuc systemd[1]: Created slice User Slice of dieter.
Oct 1 09:08:35 intelnuc systemd[1]: Starting User Manager for UID 1000...
Oct 1 09:08:35 intelnuc systemd[1]: Started Session 171 of user dieter.
Oct 1 09:08:35 intelnuc systemd[6529]: Failed to open directory /home/dieter/.config/systemd/user, ignoring: Permission denied
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on REST API socket for snapd user session agent.
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on GnuPG network certificate management daemon.
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 1 09:08:35 intelnuc systemd[6529]: Reached target Timers.
Oct 1 09:08:35 intelnuc systemd[6529]: Reached target Paths.
Oct 1 09:08:35 intelnuc systemd[6529]: Listening on GnuPG cryptographic agent and passphrase cache.
Oct 1 09:08:35 intelnuc systemd[6529]: Reached target Sockets.
Oct 1 09:08:35 intelnuc systemd[6529]: Reached target Basic System.
Oct 1 09:08:35 intelnuc systemd[6529]: Reached target Default.
Oct 1 09:08:35 intelnuc systemd[6529]: Startup finished in 25ms.
Oct 1 09:08:35 intelnuc systemd[1]: Started User Manager for UID 1000.
Oct 1 09:08:35 intelnuc kernel: [143421.730633] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:36 intelnuc kernel: [143422.729781] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:37 intelnuc kernel: [143423.738776] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:37 intelnuc kernel: [143423.944778] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:38 intelnuc kernel: [143424.741773] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:39 intelnuc kernel: [143425.954770] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:41 intelnuc kernel: [143427.970761] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:42 intelnuc kernel: [143428.765757] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:43 intelnuc kernel: [143429.768746] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:45 intelnuc kernel: [143431.781624] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:45 intelnuc kernel: [143431.991735] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:47 intelnuc kernel: [143433.784728] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:48 intelnuc kernel: [143434.784725] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:50 intelnuc kernel: [143436.794719] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:51 intelnuc kernel: [143437.806663] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:53 intelnuc kernel: [143439.814705] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:55 intelnuc kernel: [143441.821615] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:56 intelnuc kernel: [143442.830686] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:57 intelnuc systemd[1]: Reloading.
Oct 1 09:08:58 intelnuc systemd[1]: Reloading.
Oct 1 09:08:58 intelnuc systemd[1]: Reloading D-Bus System Message Bus.
Oct 1 09:08:58 intelnuc dbus-daemon[1000]: Unknown group "power" in message bus configuration file
Oct 1 09:08:58 intelnuc dbus-daemon[1000]: [system] Reloaded configuration
Oct 1 09:08:58 intelnuc dbus-send[6832]: method return time=1633072138.327776 sender=org.freedesktop.DBus -> destination=:1.417 serial=3 reply_serial=2
Oct 1 09:08:58 intelnuc systemd[1]: Reloaded D-Bus System Message Bus.
Oct 1 09:08:58 intelnuc kernel: [143445.043482] Bluetooth: hci0: advertising data len corrected
Oct 1 09:08:59 intelnuc systemd[1]: Starting Send secure messages to Signal clients...
Oct 1 09:09:00 intelnuc signal-cli[6868]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource11115342621250009503.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource11115342621250009503.so)
Oct 1 09:09:00 intelnuc signal-cli[6868]: Missing required native library dependency: libsignal-client
Oct 1 09:09:00 intelnuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Oct 1 09:09:00 intelnuc systemd[1]: signal.service: Failed with result 'exit-code'.
Oct 1 09:09:00 intelnuc systemd[1]: Failed to start Send secure messages to Signal clients.
Oct 1 09:09:00 intelnuc dbus-daemon[1000]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.service' requested by ':1.418' (uid=0 pid=6919 comm="dbus-send --system --type=method_call --print-repl" label="unconfined")
Oct 1 09:09:00 intelnuc systemd[1]: Starting Send secure messages to Signal clients...
Oct 1 09:09:00 intelnuc kernel: [143446.856500] Bluetooth: hci0: advertising data len corrected
Oct 1 09:09:01 intelnuc kernel: [143447.864508] Bluetooth: hci0: advertising data len corrected
Oct 1 09:09:01 intelnuc signal-cli[6920]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource10138519067502167.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource10138519067502167.so)
Oct 1 09:09:01 intelnuc signal-cli[6920]: Missing required native library dependency: libsignal-client
Oct 1 09:09:01 intelnuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Oct 1 09:09:01 intelnuc systemd[1]: signal.service: Failed with result 'exit-code'.
Oct 1 09:09:01 intelnuc systemd[1]: Failed to start Send secure messages to Signal clients.
Da passt was mit den Librarys nicht:
Oct 1 09:09:01 intelnuc signal-cli[6920]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource10138519067502167.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource10138519067502167.so)
Oct 1 09:09:01 intelnuc signal-cli[6920]: Missing required native library dependency: libsignal-client
sudo apt-get install -y build-essential
Zitat von: Ralli am 01 Oktober 2021, 11:37:28
Da passt was mit den Librarys nicht:
Oct 1 09:09:01 intelnuc signal-cli[6920]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource10138519067502167.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource10138519067502167.so)
Oct 1 09:09:01 intelnuc signal-cli[6920]: Missing required native library dependency: libsignal-client
sudo apt-get install -y build-essential
sudo apt-get install -y build-essential
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
build-essential ist schon die neueste Version (12.4ubuntu1).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Mmh. Ubuntu 12? Wenn ja, ein wenig alt. Da bin ich raus, wie die GLIBC 2.29 da nachgezogen werden kann.
Zitat von: Ralli am 01 Oktober 2021, 12:03:12
Mmh. Ubuntu 12? Wenn ja, ein wenig alt. Da bin ich raus, wie die GLIBC 2.29 da nachgezogen werden kann.
Es ist natürlich kein Ubuntu 12 sondern Ubuntu 18.04.6 LTS
Für Ubuntu 18, hol dir http://fhem.bublath.de/signal-cli-dbus_0.9.0-1_glibc2.27_amd64.deb
und installier es mit
sudo apt install ./signal-cli-dbus_0.9.0-1_glibc2.27_amd64.deb
dann
sudo service signal start
dann sollte es eigentlich klappen.
Gruß,
Jörg
Zitat von: Adimarantis am 01 Oktober 2021, 12:35:03
Für Ubuntu 18, hol dir http://fhem.bublath.de/signal-cli-dbus_0.9.0-1_glibc2.27_amd64.deb
und installier es mit
sudo apt install ./signal-cli-dbus_0.9.0-1_glibc2.27_amd64.deb
dann
sudo service signal start
dann sollte es eigentlich klappen.
Gruß,
Jörg
Das hat geholfen.
Vielen Dank und schönes Wochenende.
Ich noch mal.
Wie kann man einen auf diese Weise erstellten Account wieder löschen?
Das Löschen des Accounts hatten wir schon mal:
https://forum.fhem.de/index.php/topic,118370.msg1176692.html#msg1176692
Zitat von: Adimarantis am 01 Oktober 2021, 14:44:43
Das Löschen des Accounts hatten wir schon mal:
https://forum.fhem.de/index.php/topic,118370.msg1176692.html#msg1176692
Sorry, wohl überlesen.
Hat funktioniert, vielen Dank.
Das signal_install script ist jetzt umgebaut, dass es nicht nur X86 und ARM unterscheidet sondern auch die glibc.
Jetzt sollten automatisch alle Systeme mit X86 und glibc2.27, glibc2.28 und glibc2.31 sowie ARM und glibc2.28 erkannt und korrekt installiert werden, sofern sie "apt" unterstützen.
Sollten neue Kombinationen auftauchen, gibt es im Wiki eine Sektion die erklärt wie die native libraries zu übersetzen sind.
Diese dann gerne hier posten, dann nehme ich sie in den Installer auf
Zu Erinnerung: Der installer wird bei jedem "set reinit" oder FHEM Neustart in www/signal aktualisiert - ist also auf diesem Weg immer sofort verfügbar
Jörg
Hi,
was muss ich auf einem Raspi bei dem Befehl updateProfile für einen Pfad eingeben, wenn ich dem SignalBot ein Avatar in Signal verpassen will?
Krieg da immer eine Fehlermeldung, dass das Bild nicht gefunden wird....
Vielen Dank! :D
Bis denn
SouzA
Pfade sollten hier immer relativ zum $HOME des fhem users sein.
Außerdem muss der user natürlich auch Leserechte auf die Datei haben (wenn du sie z.B. in /tmp legst, was auch gehen sollte).
Danke für die Antwort.
Allerdings bin ich zu blöd dafür...
Das Logo "FHEM_Logo.png" liegt in /tmp. Leserechte für alle.
Wie muß jetzt konkret der Pfad aussehen? Bitte! :D
Thx und bis denn
SouzA
Also eigentlich einfach "/tmp/FHEM_Logo.png"
Aber vielleicht passt ja irgendwas anderes nicht - was steht denn im Logging?
Es gibt z.B. noch eine 2MB Begrenzung für die Bildgröße.
Hi,
::)
man sollte die eckigen Klammern weg lassen.... :o ;D
Sorry und Thx
SouzA
Hallo Jörg,
es kommt bei meiner Fhem-Installation regelmäßig vor, dass Fhem ungeplant ohne mein bewusstes Dazutun sich selbst neu startet oder neu gestartet wird. Frequenz: 2mal die Woche bis 1mal alle 2 Wochen.
Ich habe folgenden Befehl auf der Linuxebene eingegeben:
sudo grep fhem /var/log/syslog
und erhalte folgendes Ergebnis:
Oct 5 12:01:33 HPT610 systemd[1]: fhem.service: State 'stop-sigterm' timed out. Killing.
Oct 5 12:01:33 HPT610 systemd[1]: fhem.service: Killing process 2276467 (perl) with signal SIGKILL.
Oct 5 12:01:33 HPT610 systemd[1]: fhem.service: Failed with result 'signal'.
Es gibt hier eine sprachliche Übereinstimmung mit "signal", ich weiß aber nicht, ob dies etwas mit deinem Modul zu tun hat.
Viele Grüße Gisbert
Hi Gisbert!
Ich bin jetzt nicht Jörg, aber trotzdem sehr sicher das hier das Linux "signal" gemeint ist. Das dürfte nichts mit dem Signal Modul zu tun haben.
Entstehen die Logs durch ein bewusstes Herunterfahren / Neustarten von FHEM oder "einfach so"?
Hast du im FHEM Log zu diesem Zeitpunkt irgendwelche Auffälligkeiten gesehen?
Falls du eine vom Standard abweichende Definition für den FHEM systemd Service hast, dann wäre der Output von sudo systemctl cat fhem.service mal interessant.
VG, weini
Weini war schneller :)
Vielleicht noch als Nachtrag:
Das Logfile deutet eigentlich darauf hin, dass jemand ein "service fhem stop" probiert, FHEM aber nicht reagiert und daher dann gekillt wird.
Die Namensgebung von "Signal" macht es manchmal schwer spezfische Infos zum Signal Messenger zu finden, da der Begriff wie man sieht viel häufiger in einem anderen Kontext verwendet wird.
Jörg
Hallo weini,
hallo Jörg,
den Fhem-logfile muss ich dann noch untersuchen.
Hier ein Auszug aus der fhem.service:
sudo systemctl cat fhem.service
# /etc/systemd/system/fhem.service
# $Id: fhem.service 16001 2018-01-26 11:54:41Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
#WatchdogSec=120s
#StartLimitInterval=5min
#StartLimitBurst=4
#StartLimitAction=reboot-force
[Install]
WantedBy=multi-user.target
Ist der Inhalt so sinnvoll?
Viele Grüße Gisbert
Die Servicedefinition sieht ok aus. Ich wollte nur wissen, ob irgendwelche Limits definiert sind, auf deren Basis systemd den FHEM service ggf. abschießen würde.
Das ist aber nicht der Fall.
Hallo Jörg,
eines vorweg, ich bin ganz neu im Forum und weiß nicht ob das hier der richtige Ort ist einen eventuellen Bug im Modul zu melden.
Danke für das tolle Modul! Ich nutze Signalbot (Signalbot:3.0 signal-cli:0.9.0 Protocol::DBus:0.19) in Kombination mit Babble (ohne Chatbot) wie im Wiki beschrieben. Der Weg von Signal nach Babble funktionierte ohne Probleme, allerdings habe ich nie eine Antwort von Babble in Signal bekommen. Der Grund dafür war das der Empfänger nicht richtig angegeben war. Die Variable $PARM0 wurde von Signalbot immer als # übergeben. Ich konnte eine Ursache und eine Lösung dafür finden. In Zeile 686 in 50_Signalbot.pm steht:
$replyPeer="#".$groupIdRegex if defined $groupIdRegex;
Da diese alle vorherigen replyPeer Ermittlungen überschreibt und es wohl vorkommen kann, das die $groupIdRegex definiert aber leer ist, ergibt sich der replyPeer = #. Ich habe diese wie folgt geändert und das Problem damit umgangen:
$replyPeer="#".$groupIdRegex if (defined $groupIdRegex && $groupIdRegex ne "");
Schau doch mal ob ich da einen Denkfehler habe oder ob dass tatsächlich ein Fehler ist.
Viele Grüße
globalcow
Hi globalcow,
Da hast du wirklich einen Bug entdeckt.
Das Problem liegt sogar noch etwas tiefer: Dadurch das ich weiter oben irgendwann ein "quotemeta" eingebaut habe, ist der Fall "undefined" bei allen 3 Tests gar nicht möglich (nach quotemeta wird aus undef anscheinend ein leerer String). D.h. richtig ist hier immer der Tests auf Leerstring.
Gruß,
Jörg
Beim Testen der Änderungen ist mir noch eine Unschönheit beim "invite" Kommando aufgefallen. Änderungen sind im svn eingecheckt und morgen über update verfügbar (Version 3.1)
Achtung Ich hatte mein Testsystem auf signal-cli 0.9.1 upgedated und dabei feststellen müssen, das eine für Signalbot wichtige Funktion für die Handhabung von Kontakten nicht mehr funktioniert. Daher enthält das aktuelle Update auch gleich eine Warnung, falls jemand 0.9.1. installiert haben sollte, wieder auf 0.9.0 zu gehen.
Jörg
Hallo,
ich hab auf meinem RaspberryPi 3B ein Update des FHEM-Moduls und von signal-cli auf 0.9.0 gewagt.
Dazu hab ich das script in fhem/www/signal verwendet.
Während die Installation prinzipiell fehlerfrei von statten ging, hab ich jetzt das Problem dass der signal-cli service nicht startet, weil er in einen Timeout rennt:
KyleK@raspberrypi:~fhem/www/signal master ⚡$ sudo ./signal_install.sh test
You chose the following option: test
Start signal-cli service
Job for signal.service failed because a timeout was exceeded.
See "systemctl status signal.service" and "journalctl -xe" for details.
Checking installation via dbus-send command...Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Sending a message via perl Protocol::DBus...Error getting reply
journal-ctl:
Oct 25 22:43:25 raspberrypi 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 1164.
Oct 25 22:44:55 raspberrypi systemd[1]: signal.service: Start operation timed out. Terminating.
Oct 25 22:44:56 raspberrypi systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Das Default-Timeout ist 90 Sekunden, wenn ich das im Systemd-Skript anhebe via:
TimeoutSec=200
dann scheint es zu klappen.
Zitat von: KyleK am 25 Oktober 2021, 23:11:39
Das Default-Timeout ist 90 Sekunden, wenn ich das im Systemd-Skript anhebe via:
TimeoutSec=200
dann scheint es zu klappen.
Das Starten von signal-cli dauert schon etwas - sind viele .jar Files die eingebunden werden müssen. Wobei 90s schon sehr viel sind.
Auf meinem Rapsi4 mal gemessen:
pi@raspi400:~ $ time sudo service signal restart
real 0m47,562s
user 0m0,025s
sys 0m0,077s
Und das ist ja dann die Summe aus stop und start. Wobei ein Raspi3 natürlich potentiell langsamer ist und wenn dann noch eine langsamere SD-Karte dazu kommt - möglich dass es die Zeit reisst. Was kommt da bei dir raus?
Ich gehe mal davon aus, du hast die signal.service Datei so erweitert?
....
BusName=org.asamk.Signal
TimeoutSec=200
[Install]
....Das könnte ich schon ins Install Script aufnehmen. Möchte aber nicht zu hoch gehen - daher die Frage nach deinem Timing.
Jörg
Laut log hat bei mir der Aufstart 159 Sekunden gedauert.
Allerdings konnte ich diese Zeit seitdem nicht mehr reproduzieren. Jetzt gehts immer schneller als das.
Vielleicht wurde beim Update auf 0.9.0 irgendwas migriert, und es hat deshalb so lange gedauert.
Hallo zusammen,
erstmal vielen Dank für das neue Modul. Ich habe es versucht irgendwie in meinem Setup hinzubekommen, bin aber letztendlich gescheitert.
Ich habe lange Zeit SISI genutzt, das ging aber vor ein paar Monaten einfach nicht mehr und daher bin ich auf dieses neue Modul aufmerksam geworden.
Zu meinem Setup:
Ich nutze FHEM in einem Docker container. Hierzu habe ich bisher vermieden ein eigenes Image zu bastlen, sondern fahre mit dem Basis Image ganz gut https://github.com/fhem/fhem-docker.
Hier gibt es ja auch möglichkeiten über ENVs APT,NPM,CPAN etc .. nachzuinstallieren. Ebenso gibt es ja die start-scripte pre-init.sh , post-init.sh, pre-start.sh etc ..
Damals habe ich es geschafft SISI per dBUS zum laufen zu bekommen. Meine Signal-Cli data hatte ich natürlich in ein geeignetes Verzeichnis in den Container genmounted, um so bei einem Neustart nicht immer die Nummer neu registrieren zu müssen.
Es gibt hier ja auch ein docker install script. Dies nutzt so wie ich das verstehe aber nicht das "offizielle" basis image von FHEM. Geht das gar nicht damit, da evtl. dass release hier nicht passt ? Debian 10.
Hat es jemand hinbekommen SIGNALBOT zum laufen zu bekommen in einem Docker Image das auf fhem/fhem basiert ? Würde mich über Informationen über die entsprechenden Teile die nötig sind in den start-scripten freuen.
Danke,
Axxl
Moin Jörg,
habe seit zwei Tagen das Problem, dass Signalbot zwar noch sendet, aber nichts empfängt. das Script habe ich durchlaufen lassen es sagt bei allen Punkten ok.
sudo ./signal_install.sh
amd64-glibc2.33-0.9.0 is an unsupported combination - signal-cli binary libraries might not work
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.0
System library path: /usr/lib
System architecture: amd64
System GLIBC version: 2.33
This will update system packages, install or uninstall signal-cli
system : prepare required system package (except signal-cli)
install : install signal-cli and setup as dbus system service
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
start : Start the signal-cli service (or respective docker processes)
all : Run system, install, start and test (default)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? Y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for /usr/share/perl5/URI.pm...available
Checking for Protocol::DBus...V0.19 found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.9.0
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
Start signal-cli service
Checking installation via dbus-send command...success
Sending a message via perl Protocol::DBus...reply received
Wenn ich jetzt in Fhem versuche meine Nummer zu registrieren kommt bei der Eingabe des Captchas die Fehlermeldung " Incorrect captcha - e.g. needs to start with signalcaptcha:// "
Hast du eine Idee wie ich das Captchas hin bekomme?
Gruss
Enno
PS: in /var/log/syslog habe ich folgende Meldungen: Nov 11 10:18:05 FHEM signal-cli[132]: Envelope from: unknown source
Nov 11 10:18:05 FHEM signal-cli[132]: Timestamp: 1636461752110 (2021-11-09T12:42:32.110Z)
Nov 11 10:18:05 FHEM signal-cli[132]: Sent by unidentified/sealed sender
Nov 11 10:18:05 FHEM signal-cli[132]: Exception: org.whispersystems.libsignal.InvalidMessageException: invalid message Message decryption failed (ProtocolInvalidMessageException)
Nov 11 10:18:05 FHEM signal-cli[132]: No message content
Nov 11 10:18:26 FHEM signal-cli[132]: Envelope from: unknown source
Nov 11 10:18:26 FHEM signal-cli[132]: Timestamp: 1636461752110 (2021-11-09T12:42:32.110Z)
Nov 11 10:18:26 FHEM signal-cli[132]: Sent by unidentified/sealed sender
Nov 11 10:18:26 FHEM signal-cli[132]: Exception: org.whispersystems.libsignal.InvalidMessageException: invalid message Message decryption failed (ProtocolInvalidMessageException)
Nov 11 10:18:26 FHEM signal-cli[132]: No message content
Nov 11 10:18:39 FHEM signal-cli[132]: Envelope from: unknown source
Nov 11 10:18:39 FHEM signal-cli[132]: Timestamp: 1636461195217 (2021-11-09T12:33:15.217Z)
Nov 11 10:18:39 FHEM signal-cli[132]: Sent by unidentified/sealed sender
Nov 11 10:18:39 FHEM signal-cli[132]: Exception: org.whispersystems.libsignal.InvalidMessageException: invalid message Message decryption failed (ProtocolInvalidMessageException)
Nov 11 10:18:39 FHEM signal-cli[132]: No message content
Zitat von: Axxl am 11 November 2021, 09:48:08
Es gibt hier ja auch ein docker install script. Dies nutzt so wie ich das verstehe aber nicht das "offizielle" basis image von FHEM. Geht das gar nicht damit, da evtl. dass release hier nicht passt ? Debian 10.
Ich habe meine Docker Variante zwar auf Ubuntu basiert, aber Debian 10 sollte genauso gehen, habe mich aber nicht weiter mit dem "offizellen" Image beschäftigt.
Mit etwas Docker Know How sollte es möglich sein, aus meinem Script die relevanten Teile (Pakete, Scripte) zu übernehmen.
Leider kann ich dazu aber aktuell keine grosse Hilfestellung geben.
Zitat von: enno am 11 November 2021, 09:50:00
Hast du eine Idee wie ich das Captchas hin bekomme?
Welchen Ansatz nimmst du? Hast du die Methode mit der Windows Registry (Power Shell script) verwendet?
Letztendlich braucht die "set captcha" Methode den vollen String "signalcaptcha://......." von der Signal Captcha web site.
Zitat
Nov 11 10:18:05 FHEM signal-cli[132]: Exception: org.whispersystems.libsignal.InvalidMessageException: invalid message Message decryption failed (ProtocolInvalidMessageException)
Vielleicht ist hier wirklich eine art "Re-registrierung" notwendig - habe ich aber bei mir noch nie gesehen und meine Umgebung läuft schon ewig ohne neue Registrierung.
Lass uns erstmal versuchen dass deine Registrierung durchläuft.
Ich habe alle Versionen die im Wiki stehen durch. Ich bin mit Linux unterwegs. Windows habe ich hier nicht im Angebot.
- Mit Firefox: signalcaptcha.desktop runterladen und nach ~/.local/share/applications/signalcaptcha.desktop kopiert und mit xdg-mime default signalcaptcha.desktop x-scheme-handler/signalcaptcha (alles mit dem Desktop User) aktiviert
Die Seite wird aufgerufen und meldet den Fehler "Incorrect captcha - e.g. needs to start with signalcaptcha://"
- Mit Chrome alles über "F12" und Console kopiert und in "set SIGNAL captcha signalcaptcha://1234xdfr..." gleiche Fehlermeldung
Gruss
Enno
Steht ein Fehler im "lasterr"?
Es ist nicht zwangsläufig der String falsch, sondern er lehnt ihn evtl. aus irgendwelchen Gründen ab.
Irgendwo gab es auch noch den Hinweis, dass potentiell eine andere Captcha Seite verwendet werden könnte:
https://signalcaptchas.org/challenge/generate.html
Probier das mal.
Moin Jörg,
ich habe den Register Vorgang direkt in der Console gemacht. Soweit so gut. senden klappt, aber es kommen immer noch keine Nachrichten mehr rein. Ich vermute es liegt am "signal-cli". Hier hatte einer auch so ein Problem. https://github.com/AsamK/signal-cli/issues/290
Wenn ich in der Console starte: sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +4912345 receive
Bekomme ich folgende Meldungen im Sekundentakt: Envelope from: unknown source
Timestamp: 1636451210012 (2021-11-09T09:46:50.012Z)
Sent by unidentified/sealed sender
Exception: org.whispersystems.libsignal.InvalidMessageException: invalid message Message decryption failed (ProtocolInvalidMessageException)
No message content
Ich suche mal weiter....
Gruss
Enno
Du könntest mal versuchen signal-cli 0.9.2. zu installieren. Einfach im Install script die Version ändern.
Wird bereits unterstützt aber bisher habe ich keine Notwendigkeit gesehen das Update zu verbreiten
VERSION Signalbot:3.1 signal-cli:0.9.2 Protocol::DBus:0.19
Senden geht, empfangen nicht. Wenn ich eine Nachricht gesendet habe steht das Reading "sentMsgTimestamp" auf "pending". Soll das so?
Gruss
Enno
Hallo Jörg,
habe jetzt alles noch mal per Konsole gemacht:
sudo service signal stop
sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +49... register --voice --captcha signalcaptcha://03AGdB...
sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +49... verify 123457
sudo service signal start
und nun geht es wieder. Die Eingabe über FHEM und dein Modul des Captcha klappt bei mir warum auch immer nicht. Nach dem Verify war alles wieder im Lot. Jetzt hat das Reading "sentMsgTimestamp" auch einen richtigen Wert "11-11-2021 14:40:08"
Gruss
Enno
Hallo,
ich habe da mal ein problem. Ich verwende:
Signalbot:3.1 signal-cli:0.9.0 Protocol::DBus:0.19
Nun habe ich mir ein DOIF gebaut in dem ich mit Perl ein if , elseif und else benutze.
Der if und elseif zweig funktioniert da dort ja der Empfänger mit \@+491... angegeben wird.
Jetzt komme ich aber zu meinem Problem. In dem else Zweig möchte ich eine Nachricht an einer Gruppe schicken die ja mit #gruppenname angeschrieben wird aber ich möchte auch der Wert einer variable aus Perl $var in dem text mitschicken.
else {fhem ("set SigBot send #9-Eidenmuellers Morgen hat $val Geburtstag") }
bekomme aber den Fehler Specify either a message text or an attachment
Hab schon etliche variationen ausprobiert und bin jetzt einfach ratlos.
Gruß
Christian
Hallo Christian,
ich habe bei mir testweise mal ein DOIF gebaut, das hoffentlich deinem Anwendungsfall entspricht:
(false) {
my $val="duda";
if ($val eq "ich") {
fhem ("set SignalBot send #1-testgruppe Ich bins")
} else {
fhem ("set SignalBot send #1-testgruppe Hallo $val")
}
}
Dachte erst es liegt vielleicht an dem Gruppennamen (mit "9-....") aber wenn ich "set cmd_1" mache, dann kriege ich wie erwartet "Hallo duda" auf meinem Handy.
Überprüfe doch mal anhand des Beispiels ob wirklich alles korrekt ist und als nächstens mal verbose=5 und ins logfle schauen.
Jörg
Hallo Jörg,
ich habe folgendes:
([09:00] and [Geburtstagsliste:t_001_daysleft] == 1)
( {my $val= ReadingsVal ('Geburtstagsliste','t_001_summary','');;
my $t= ReadingsVal ('Geburtstagsliste','t_001_description','');;
my $rec= substr("$t",0,1);;
if (($rec eq "m") || ($rec eq "M")) {fhem ("set SignalBot send \@+491........... Morgen hat $val Geburtstag") }
elsif (($rec eq "c") || ($rec eq "C")) {fhem ("set SignalBot send \@+491........ Morgen hat $val Geburtstag") }
else {fhem ("set SignalBot send #Gruppe Morgen hat $val Geburtstag") }
})
DOELSEIF ([06:00])
Im reading des DOIF erhalte ich:
{my $val= ReadingsVal ('Geburtstagsliste','t_001_summary','');; my $t= ReadingsVal ('Geburtstagsliste','t_001_description','');; my $rec= substr("$t",0,1);; if (($rec eq "m") || ($rec eq "M")) {fhem ("set SignalBot send \@+49.......... Morgen hat $val Geburtstag") } elsif (($rec eq "c") || ($rec eq "C")) {fhem ("set SignalBot send \@+491........... Morgen hat $val Geburtstag") } else {fhem ("set SignalBot send #Gruppe Morgen hat $val Geburtstag") } }: Specify either a message text or an attachment
Verbose 5 ist gesetzt im DOIF und das Log sagt:
2021.11.21 09:00:00 3: set SigBot send #Gruppe Morgen hat Heint Test '64 Geburtstag : Specify either a message text or an attachment
2021.11.21 09:00:00 2: diGeburtstag: {my $val= ReadingsVal ('Geburtstagsliste','t_001_summary','');; my $t= ReadingsVal ('Geburtstagsliste','t_001_description','');; my $rec= substr("$t",0,1);; if (($rec eq "m") || ($rec eq "M")) {fhem ("set SignalBot send \@+491............ Morgen hat $val Geburtstag") } elsif (($rec eq "c") || ($rec eq "C")) {fhem ("set SignalBot send \@+491....... Morgen hat $val Geburtstag") } else {fhem ("set SignalBot send #Gruppe Morgen hat $val Geburtstag") } }: Specify either a message text or an attachment
Ich denke es muss irgendwie mit dem # zusammenhängen da dies in Perl ja als Kommentar gilt.
Die anderen beiden IF und ELSEIF funktionieren da dort ja kein # darin vorkommt. Musste aber das @ dort auch maskieren (so nennt man das glaube ich).
Das maskieren des # hilft aber nicht.
Habe im else also im ELSE ...set SignalBot send \#Gruppe ....
Der Fehler ist aber der gleiche.
Mache ich " in den ELSE zweig:
([09:20] and [Geburtstagsliste:t_001_daysleft] == 1)
( {my $val= ReadingsVal ('Geburtstagsliste','t_001_summary','');;
my $t= ReadingsVal ('Geburtstagsliste','t_001_description','');;
my $rec= substr("$t",0,1);;
if (($rec eq "m") || ($rec eq "M")) {fhem ("set SignalBot send \@+4917xxxxxxxx Morgen hat $val Geburtstag") }
elsif (($rec eq "c") || ($rec eq "C")) {fhem ("set SignalBot send \@+4916xxxxxxx Morgen hat $val Geburtstag") }
else {fhem ("set SignalBot send \#Gruppe Morgen hat $val Geburtstag") }
})
DOELSEIF ([06:00])
bekomme ich die Meldung Morgen hat $val Geburtstag. d.h. statt dem Wert der variable $val bekomme ich den Namen $val geschickt.
Habe aber jetzt dein Beispiel mal erstellt.
{
my $val="duda";
if ($val eq "ich") {
fhem ("set SignalBot send #9-Gruppe Ich bins")
} else {
fhem ("set SignalBot send #9-Gruppe Hallo $val")
}
}
Was mir dabei aufgefallen ist das du nur einfache ; verwendest und ich immer ;;
Dein Beispiel funktioniert und ich bekomme die Nachricht Hallo duda.
Ich verstehe es einfach nicht.
Gruß
Christian
Zitat von: Kohle77 am 21 November 2021, 09:32:12
Verbose 5 ist gesetzt im DOIF und das Log sagt:
2021.11.21 09:00:00 3: set SigBot send #Gruppe Morgen hat Heint Test '64 Geburtstag : Specify either a message text or an attachment
Es scheint das '64 zu sein - das führt zu unausgeglichenen Quotes.
Hab das mal in mein Beispiel eingebaut und kriege es mit normalen Quotes plus Escape zum Laufen:
(false) {
my $val="'duda";
if ($val eq "ich") {
fhem ("set SignalBot send #1-testgruppe Ich bins")
} else {
fhem ("set SignalBot send #1-testgruppe \"Hallo $val\"")
}
}
Hallo,
daran habe ich noch die Gedacht. Nur damit ich es richtig verstehe.
Wenn also in dem reading t_001_summary steht Vorname Nachname 'xx wobei das xx das Jahr ist steht dann in der Variable $val eben "Vorname Nachname 'xx" und das ' könnte probleme machen. Wenn ich das 'xx einfach auf 19xx ändere sollte es auch kein Problem geben da es eben keine ' zeichen mehr gibt. Muss ich mal Probieren. Melde mich wenn ich es testen konnte.
Gruß
Christian
Hi,
Juhu ich konnte es schon testen. Wenn ich statt dem 'xx eben 19xx benutze dann funktioniert es.
Hab das else auch mal in:
else {fhem ("set SigBot send \#9-Gruppe Morgen hat $val\" Geburtstag") was aber das Problem nicht löst da das ' Zeichen mitten in $val steht.
Vielen Dank nochmal für die Hilfe.
Gruß
Christian
Hallo in die Runde!
Ich habe auf meinen beiden FHEM-Installationen Signalbot und signal-cli auf die aktuellen Versionen gezogen:
Signalbot:3.1 signal-cli:0.9.0 Protocol::DBus:0.19
Senden funktioniert einwandfrei und superschnell.
Jedoch habe ich beim Empfang Probleme. Entweder die Nachrichten kommen extrem spät (> 15 min.) in FHEM an, oder gar nicht.
signal-cli schreibt jedoch alle 3-4 Sekunden folgenden Eintrag in /var/log/syslog:
Nov 22 21:01:14 rpi4SSD signal-cli[26337]: - 1637509531464 (2021-11-21T15:45:31.464Z)
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Envelope from: unknown source
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Timestamp: 1637526532740 (2021-11-21T20:28:52.740Z)
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Sent by unidentified/sealed sender
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Sender: +43XXXXXXXXXXX (device: 1)
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Server timestamps: received: 1637526532932 (2021-11-21T20:28:52.932Z) delivered: 1637611258989 (2021-11-22T20:00:58.989Z)
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Received a receipt message
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: When: 1637526532740 (2021-11-21T20:28:52.740Z)
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Is delivery receipt
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: Timestamps:
Nov 22 21:01:17 rpi4SSD signal-cli[26337]: - 1637509394221 (2021-11-21T15:43:14.221Z)
Ich hab' signal-cli bereits mehrmals entfernt und den ganzen Prozess (signal_install.sh & Registrierung) neu durchgeführt, Ergebnis ist leider immer dasselbe. :(
Hat eventuell jemand eine Idee, wo ich noch nach Fehlern suchen könnte?
Vielen Dank und liebe Grüße!
Simon
hi Simon,
Dass er ständig ins syslog schreibt ist schon mal nicht normal (wenn keine Nachrichten kommen).
Wenn du signal-cli neu installiert hast, hast du dann auch mal /var/lib/signal-cli/ komplett gelöscht, bevor du neu installiert hast?
Wenn der Wurm in der Config ist, dann hilft die Neuinstallation (und ggf. Neuregistrierung) eventuell nichts.
Weitere debug versuche wären dann, das Problem einzugrenzen, als erstmal den Service beenden und nur mit der signal-cli Kommandozeile verschiedene Tests( senden/empfangen) zu machen.
Dann mit laufendem Service, aber ohne FHEM mit dbus-send etc. von der Kommandozeile, dann mit Perl ohne FHEM.
Aber eins nach dem anderen. Wenn du da nicht weiter kommst, müsste ich auch erstmal die Befehle raussuchen.
Jörg
Hi,
Befehle zum senden aus der command line habe ich z.B. hier gefunden:
https://wiki.fhem.de/wiki/SiSi (https://wiki.fhem.de/wiki/SiSi)
z.B. sudo -u fhem signal-cli -u <RegistrierteNummer> send -m "Greetings from FHEM!" <Empfängernummer>
dbus senden sudo -u fhem dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:<Nachricht> array:string: string:<EmpfängerNummer>
Signal CLI über D-BUS sudo -u fhem signal-cli --dbus-system send -m "<Nachricht>" <EmpfängerNummer>
Denke es gibt auch befehle im messages zu empfangen.
Gruß
Christian
Hi!
Erstmals danke für Eure Antworten!
ZitatWenn du signal-cli neu installiert hast, hast du dann auch mal /var/lib/signal-cli/ komplett gelöscht, bevor du neu installiert hast?
Ja, das Verzeichnis habe ich vor der Neuinstallation gelöscht.
Ich habe jetzt nochmal installiert, dabei kam es zu folgendem Fehler:
Job for signal.service failed because a timeout was exceeded.
signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Tue 2021-11-23 09:11:29 CET; 16s ago
Process: 7913 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=143)
Main PID: 7913 (code=exited, status=143)
Nov 23 09:09:59 rpi4 systemd[1]: Starting Send secure messages to Signal clients...
Nov 23 09:11:29 rpi4 systemd[1]: signal.service: Start operation timed out. Terminating.
Nov 23 09:11:29 rpi4 systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Nov 23 09:11:29 rpi4 systemd[1]: signal.service: Failed with result 'timeout'.
Nov 23 09:11:29 rpi4 systemd[1]: Failed to start Send secure messages to Signal clients.
Ich habe die Registrierung manuell durchgeführt, das lief ohne Probleme:
sudo ./signal-cli --config /var/lib/signal/ -u +43XXXXXXXX register --voice --captcha signalcaptcha://03AGd...
sudo ./signal-cli --config /var/lib/signal/ -u +43XXXXXXXX verify XXXXXX
Danach:
sudo ./signal-cli --config /var/lib/signal -u +43XXXXX send -m "Test" +43XXXXXX
INFO Manager - The Signal protocol expects that incoming messages are regularly received.
1637656517378
Die Nachricht ist auch angekommen.
Beim Senden über dbus, folgende Fehlermeldung:
sudo ./signal-cli --dbus-system send -m "Hallo" +43XXXXXXX
Failed to send message: Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms) (DBusExecutionException)
Ich befürchte fast, dass ich durch die ganzen Neu-Installationen mehr zerschossen, als gerettet habe... :-\
Liebe Grüße!
Simon
Das mit dem timeout hatten wir schon mal bei sehr langsamen Systemen.
Siehe hier:
https://forum.fhem.de/index.php/topic,118370.msg1182313/topicseen.html#msg1182313
Versuch mal wie beschrieben den timeout zu erhöhen.
Hallo Jörg,
Du hattest Recht, mit erhöhtem Timeout startet der Service, jedoch benötigt er wirklich sehr lange dafür. In der Zeit lastet java auch den Prozessor zu 100% aus:
time sudo service signal restart
real 2m35.914s
user 0m0.028s
sys 0m0.085s
Jetzt hätte ich erneut eine komplette Neu-Installation versucht, aber scheitere am Captcha. Weder über den Registry-Hack noch direkt über die cli wird der Token angenommen. Eventuell habe ich's heute übertrieben.
Ich versuch's dann morgen nochmal und suche weiter.
Vielen Dank einstweilen.
LG
Simon
Hallo zusammen!
Kleines Update:
Auf beiden FHEM-Instanzen nochmal alles komplett neu gemacht, inkl. der Tipps aus der Fehlerbehandlung im Wiki.
Die Konten von beiden Rufnummern bei Signal gelöscht und neu erstellt.
Nur habe ich dieses Mal beide Nummern verlinkt, statt über signal-cli oder fhem registriert.
Hilft aber leider auch nichts. Kurz nach der Neuinstallation hat es zwar funktioniert, aber nach ein paar Minuten ging es nicht mehr.
Ich habe soeben nochmal den service neu gestartet, jetzt schreibt er innerhalb von 1 Sekunden > 500 Zeilen ins syslog, immer mit demselben Inhalt (man beachte auch die total abweichenden Timestamps!):
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Envelope from: unknown source
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Timestamp: 1637771944834 (2021-11-24T16:39:04.834Z)
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Sent by unidentified/sealed sender
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Sender: "XXXXXXXXX" +43XXXXXXXXXXX (device: 2)
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Server timestamps: received: 1637771945043 (2021-11-24T16:39:05.043Z) delivered: 1637776740730 (2021-11-24T17:59:00.730Z)
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Received a receipt message
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: When: 1637771944834 (2021-11-24T16:39:04.834Z)
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Is delivery receipt
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: Timestamps:
Nov 24 18:59:00 rpi4SSD signal-cli[5422]: - 1637766524727 (2021-11-24T15:08:44.727Z)
Jetzt habe ich eigentlich alles versucht, was mir eingefallen ist.
Hat vielleicht noch jemand einen Tipp für mich?
Vielen Dank und liebe Grüße!
Simon
Das läuft auf einem Raspi4, korrekt?
Welche OS/Kernel Version? Alle Pakete aktuell?
Welche Java Version wird verwendet?
java --version
openjdk 11.0.12 2021-07-20
Du kannst auch mal probieren auf signal-cli 0.9.2. zu updaten (nicht das ich mir viel davon verspreche, aber mir fällt sonst nicht mehr viel ein) - dazu einfach im Installer script
SIGNALVERSION="0.9.2"
und nochmal drüberinstallieren lassen.
Hey!
ZitatDas läuft auf einem Raspi4, korrekt?
Korrekt.
ZitatWelche OS/Kernel Version? Alle Pakete aktuell?
Alles Pakete aktuell. Kernel 5.10.63-v7l+
ZitatDu kannst auch mal probieren auf signal-cli 0.9.2. zu updaten (nicht das ich mir viel davon verspreche, aber mir fällt sonst nicht mehr viel ein) - dazu einfach im Installer script
Das habe ich bereits versucht, jedoch klappt dann gar nichts mehr.
Ich konnte mein Problem mittlerweile etwas eingrenzen.
Bei Registrierung von 2 Nummern in 2 Signalbots funktioniert das Senden an einzelne Nummern normal.
Problematisch wird es in folgenden Fällen:
1.) Eine Gruppe mit meinem Handy und den beiden Signalbots: Senden an meine Nummer klappt von beiden Signalbots aus. Auch ich kann in die Gruppe senden, und die Nachricht wird von beiden empfangen. Wenn jedoch ein Signalbot eine Nachricht in die Gruppe schickt, wir er von Empfangsbestötigungen (receipt messages) des anderen überflutet.
2.) Mein 2. Versuch war, eine Nummer am Samrtphone zu registrieren, und beide Signalbots mit dieser Nummer zu verlinken. Wenn ich damit eine Gruppe bilde funktioniert das Senden zu und von meiner Nummer einwandfrei. Wenn jedoch ein Signalbot eine Nachricht in die Gruppe sendet, bekomme ich das zwar auf mein Handy, der andere Bot bekommt sie jedoch nicht.
Eine Nachricht vom Signalbot an die eigene Nummer, führt wieder zu der Überflutung mit Empfangsbestätigungen.
Ich habe in der Signal-CLI-Doku gelesen, dafür wäre eine eigene Option gedacht (--note-to-self), aber die ist im Modul nicht integriert.
Grundgedanke des Setups ist, dass ich von meinem Handy aus mit beiden FHEM-Instanzen reden kann, aber die beiden sollten sich auch untereinander unterhalten können.
LG
Simon
Hi Simon,
Grundsätzliches:
Jeder signal-cli Instanz sollte nur mit einer Nummer verbunden sein. Einen ähnlichen Fehler ("message storm") hatte ich auch mal - ich glaube eben mit einer kopierten Registrierung - konnte das aber letztendlich nicht mehr nachstellen. Da heutzutage eigentlich jeder DSL Anschluss mit 3 Rufnummern kommt, bzw. man bei einigen Anbietern kostenlose VOIP Nummern registrieren kann, sollte es machbar sein, jeder Instanz eine eigene Nummer zu geben.
Wenn du trotzdem noch Probleme hast, und ein klar nachstellbares Szenario, mach bitte einen Bug auf der signal-cli github Seite auf.
Grundsätzlich könnte man noteToSelf in SignalBot zur Verfügung stellen - inwiefern das dein Problem löst, solltest du aber erstmal auf der Kommandozeile (dbus-send) ausprobieren. Verlinkte Devices sind ganz nett zum Ausprobieren, meiner Meinung nach aber keine Lösung für den produktiven Einsatz.
Die nächste Frage ist, wofür du zwei Instanzen benötigst. Sofern es sich um zwei Raspi's im selben Netz handelt, würde ich eher dazu raten mit nur einer Instanz und FHEM2FHEM zu arbeiten. FHEM2FHEM unterstützt seit kurzem auch remote Kommandos, so dass du bequem von der zweiten Instanz ein "set Remote_FHEM cmd set SignalBot send ...." machen kannst. Auf Messages vom Signalbot reagieren kannst du ebenfalls ganz einfach indem du sie mit FHEM2FHEM abonnierst.
Ich habe noch folgenden Bug-Report zu 0.9.0 bzgl. eines "message storm" gefunden:
https://github.com/AsamK/signal-cli/issues/777
Das müsste demnach in 0.9.2 behoben sein. Kannst du näher ausführen was "klappt gar nichts mehr" mit 0.9.2. bedeutet? Ich hab das zwar bisher nur auf meiner Test-Instanz laufen (Raspi400), dort aber schon seit Wochen ohne Probleme. Falls ich noteToSelf einbauen sollte, würde ich gerne auf 0.9.2 gehen (oder sogar höher, falls es bis dahin ein neues Release gibt).
Gruß,
Jörg
Moin Jörg,
kurze Rückmeldung von mir. Ich habe ja seit dem 11.11. bei mir 0.9.2 laufen. Ohne Probleme absolut stabil.
Gruss
Enno
Wie mache ich am einfachsten ein Update?
Ich hab diese Version:
VERSION Signalbot:3.1 signal-cli:0.9.0 Protocol::DBus:0.19
Aktuell sehe ich keinen Vorteil darin ein update von signal-cli zu machen, daher verwendet der Installer nach wie vor V0.9.0
Wer es dennoch machen möchte, das Installerscript unter ~fhem/www/signal wie folgt editieren:
SIGNALVERSION="0.9.2"
und nochmal drüberinstallieren lassen.
Aktuell warte ich auf das nächste Update. Die aktuelle Entwicklerversion auf Github verwendet bereits die neuste signal-client library, die zkgroup integriert, wodurch nur noch eine, statt zwei native libraries übersetzt werden müssen. Was ich auch verfolge ist das neue RPC Feature. Eventuell könnte es damit Sinn machen sich von Dbus zu verabschieden. Mit RPC sollte es z.B. einfacher sein, signal-cli in einen komplett eigenen Container zu verfrachten, aber das wäre wieder eine größere Umstellung für die ich erst Zeit finden müsste und über dessen Mehrwert ich mir nicht so sicher bin.
Inzwischen wurde auch das Dbus Interface deutlich aufgebohrt, insbesondere gibt es mehr Funktionen für die Verwaltung von Gruppen. Ich möchte Signalbot aber nicht blind mit diesen Funktionen überfrachten, wenn es keinen konkreten Anwendungsfall aus FHEM heraus gibt (viele neue Funktionen zielen eher auf die interaktive Anwendung).
Wer aber mal stöbern und Vorschläge machen möchte findet die Auflistung der Funktionen hier:
https://github.com/AsamK/signal-cli/blob/master/man/signal-cli-dbus.5.adoc
Hallo Adimarantis,
vielen Dank für die Erklärungen der nächsten Schritte.
Mein Anliegen war eher praktischer Natur aus Sicht eines (unbedarften) Users. Das Script habe ich runter geladen, jetzt hat es die Rechte pi:pi und chmod steht auf 644. Was muss da geändert werden, und wie wird das Skript aufgerufen, mit dem Dateinamen oder wie sonst?
Viele Grüße Gisbert
Das Script wird immer automatisch bei FHEM Start bzw. "reinit" runtergeladen, aktualisiert und auch per chmod ausführbar gemacht. Natürlich in dem Fall üblicherweise unter dem fhem User. Dann einfach z.B. mit vi oder nano editieren und wieder abspeichern. Wenn ich offiziell eine neue Version freigebe, reicht eben dann auch ein "reinit" und das neuste Skript steht wieder unter www/signal
Ausgeführt wird das dann wie üblich mit
sudo ./signal_install.sh
Wie gesagt, solange niemand Probleme hat, die explizit auf die signal-cli Version zurückzuführen sind oder Signalbot Funktionen eine neue Version benötigt, werde ich auch keine neue Version freigeben. "Never touch a running system" - um so weniger verschiedenen Installationen im Umlauf sind, um so leichter ist es Support zu leisten.
Verständlich, dann gedulde ich mich, bis du eine neue Version frei gibst.
Hallo Adimarantis,
zumindest unter Debian 10, muss man für 0.9.2 anscheinend auch wieder die Libraries neu kompilieren. Also lass ich lieber auch erstmal alles beim alten, bis Du eine neue Version freigibst.
Grüsse und danke für die tolle Unterstützung und das Modul!
Ja, die Debian 10 libs hab ich noch nicht gebaut - hab meine VM versehentlich auf 11 upgedated :)
Darfst dich aber gerne freiwillig melden. Für das nächste Update werd ich schauen dass ich die VM nochmal baue...
Jörg
Hallo Joerg,
freiwillig und sehr gerne! Nur zur Info, ich bekomme folgende Fehlermeldung im FHEM Signal Modul, und Messages werden nicht verschickt (funktioniert also nicht)
Error in sendMessage:Error Executing Method org.asamk.Signal.sendMessage: 'void org.signal.client.internal.Native.keepAlive(java.lang.Object)'
Was habe ich gemacht:
- auf https://github.com/signalapp/zkgroup gibt es noch keine neuen Libraries für 0.9.2, also habe ich die vorher kompilierten Dateien (Antwort #381 in diesem Thread) libsignal_jni.so und libzkgroup.so von 0.9.0 nach 0.9.2 kopiert"
cd /opt/fhem/signal-cli-0.9.2/lib/
sudo cp ../../signal-cli-0.9.0/lib/libsignal_jni.so .
sudo cp ../../signal-cli-0.9.0/lib/libzkgroup.so .
Dann die libraries ersetzt:
sudo -u fhem zip -u signal-client-java-*.jar libsignal_jni.so
sudo -u fhem zip -u zkgroup-java-*.jar libzkgroup.so
Neustart und check:
sudo systemctl restart signal.service
jamo@inuc:/opt/fhem$ systemctl status 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 Mon 2021-11-29 20:10:32 CET; 4s ago
Main PID: 32436 (java)
Tasks: 49 (limit: 4915)
Memory: 160.1M
CGroup: /system.slice/signal.service
└─32436 java -Xms2m -classpath /opt/fhem/signal-cli-0.9.2/lib/signal-cli-0.9.2.jar:/opt/fhem/signal-cli-0.9.2/lib/lib.jar:/opt/fhem/signal-cli-0.9.2/lib/bcprov-jdk15on-1.69.jar:/opt/fhem/signal-cli-0.9.2/l
lines 1-8/8 (END)
jamo@inuc /opt/fhem$ java --version
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Debian-2deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.12+7-post-Debian-2deb10u1, mixed mode, sharing)
jamo@inuc:/opt/fhem$ ldd --version
ldd (Debian GLIBC 2.28-10) 2.28
jamo@inuc:/opt/fhem$ uname -r
4.19.0-17-amd64
jamo@inuc:/opt/fhem$ cat /etc/debian_version
10.11
jamo@inuc:/opt/fhem$ cat /proc/version
Linux version 4.19.0-17-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-3 (2021-07-18)
FHEM neu gestartet:VERSION
Signalbot:3.1 signal-cli:0.9.2 Protocol::DBus:0.19
Wenn ich dann eine Message schicke, bekomme ich obigen Fehler und textmessages werden nicht verschickt. Bin jetzt wieder auf 0.9.0, das funktioniert stabil.
Hi Jamo,
anscheinend ist der aktuelle Stand des Source Code nicht mehr kompatibel (durch den merge libsignal und zkgroup) - da müsste man wahrscheinlich auf einen älteren Stand/Branch gehen.
Lohnt aber den Aufwand nicht. Lass uns auf die nächste signal-cli release warten, die bereits auf das neue library layout aufsetzen wird.
Jörg
So machen wir das! Danke nochmal, das Signal Modul läuft super.
Ich könnte mal Hilfe gebrauchen.
Die signal Installation in fhem ist ohne Probleme durchgalaufen,
Jetzt möchte ich eine Nummer registrieren, scheiter aber immer am captcha
192.168.111.200:8083/fhem?cmd=set signal captcha signalcaptcha://03AGdBq24ZS4yjw_zcj6YQbxRYbbFd4I2OFljTggSwzEy3FEtWJZFPsI5RX8KCSjB0HXjJy2A3jn4CwyPMoXqoyxeUISE10qluFRuoCUW3BCDhwWH8zt5fUVDyR5Zxg0S1WYdrYWp536-z2TzVMFNTmcbj5auBd_QuesSq9-TDbO9l1yJVx5lxRnzaI5GstWNNk9duQyXLjfO1zyywVWEARklXN1SgitxvW69SZnxZzEzPOav_bQ4Ira_QlU_RpGELi3Q1oNV9KbWEVXNS5Pa0l2WsmRUyWFLK1fzRzVCO-XJAbiGcfvEhbSbMii2vThnKEnh9bm6i28RFHMS09AC86eZM-fvxaltceCVsI9-A3tkpFYtzDIsBkO5n6_k8Xn1OB2ZBbMqKqanJuHFlTBse6hO0SmHpr4btUtTTut6vXfss8fAzLRBxpDlLkAzUpzyZFLbHu7mUmDX6NfXID-dI6E7atiGv0OMuSw
Egal, wie ich es versuche manuell oder automatisiert über powershell.
Es öffnet sich in jedem Fall ein neues Fenster mit:
Incorrect captcha - e.g. needs to start with signalcaptcha://
Obwohl der captch string ja mit signalcaptcha:// beginnt.
Ich hoffe, jemand hat einen Tip für mich. Ich drehe mich immer nur im Kreis und komme nicht weiter.
Gruß LuGu
Ich hatte das Phänomen auch beim letzten mal.
Abhilfe war - glaube ich - alles komplett über die Eingabezeile in der Weboberfläche einzugeben:
set signal captcha signalcaptcha://03AGdBq24ZS4yjw_zcj6YQbxR.....
Gruß
Danny
Moin LuGu,
ich habe es damals auch über ssh direkt in der Konsole erledigt.
sudo service signal stop
cd /opt/signal/bin/
sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +49 12456 register --voice --captcha signalcaptcha://03AG....
sudo -u signal-cli ./signal-cli --config /var/lib/signal-cli -u +49 12456 verify 12345
sudo service signal start
und dann in FHEM weiter.
Gruss
Enno
Nachdem das anscheinend doch öfter passiert, sollten wir dem mal auf den Grund gehen - eigentlich gibt es keinen Grund warum es aus FHEM nicht geht, wenn es von der Konsole funktioniert.
Ein Tipp war ja schon mal eine andere Webseite zu verwenden:
https://signalcaptchas.org/challenge/generate.html
Sonst doch bitte mal verbose=5 und den entsprechenden Ausschnitt aus dem Logfile.
Zitat von: Adimarantis am 30 November 2021, 20:07:05
Nachdem das anscheinend doch öfter passiert, sollten wir dem mal auf den Grund gehen - eigentlich gibt es keinen Grund warum es aus FHEM nicht geht, wenn es von der Konsole funktioniert.
Ein Tipp war ja schon mal eine andere Webseite zu verwenden:
https://signalcaptchas.org/challenge/generate.html
Sonst doch bitte mal verbose=5 und den entsprechenden Ausschnitt aus dem Logfile.
Danke euch für die Antworten.
Die alternative Website und auch die Eingabe in der fhem command line hatte ich schon getestet.
Dann werde ich es noch mal loglevel 5 versuchen und dann mit der Shell weiter testen.
Gruß LuGu
Ich habe das Problem jetzt nachstellen können:
Es scheint dann aufzutreten, wenn man eine Nummer registriert, die schon mal registriert war, also im Verzeichnis /var/lib/signal-cli/data dafür bereits Konfigurationsdaten vorliegen.
Bei mir hat es geholfen die +49xxxxx Datei und das +49xxxxx.d Verzeichnis der entsprechenden Nummer zu löschen.
Kann das wer bestätigen?
Edit: Die Methode von enno scheint auch zu helfen - das Problem ist spezifisch für DBus - passiert also auch wenn man mit "dbus-send" auf der Kommandozeile arbeitet (ist also erstmal kein Fehler von Signalbot selbst)
Jörg
Zitat von: Adimarantis am 30 November 2021, 22:28:12
Ich habe das Problem jetzt nachstellen können:
Es scheint dann aufzutreten, wenn man eine Nummer registriert, die schon mal registriert war, also im Verzeichnis /var/lib/signal-cli/data dafür bereits Konfigurationsdaten vorliegen.
Bei mir hat es geholfen die +49xxxxx Datei und das +49xxxxx.d Verzeichnis der entsprechenden Nummer zu löschen.
Kann das wer bestätigen?
Edit: Die Methode von enno scheint auch zu helfen - das Problem ist spezifisch für DBus - passiert also auch wenn man mit "dbus-send" auf der Kommandozeile arbeitet (ist also erstmal kein Fehler von Signalbot selbst)
Jörg
Moin Jörg,
das Löschen der Einträge hat leider auch nichts gebracht.
2021.12.01 10:34:04 5: signal: Init: signal Signalbot
2021.12.01 10:34:04 4: signal: Protocol::DBus version found 0.19
2021.12.01 10:34:04 5: signal Setting number to default
2021.12.01 10:34:05 5: signal: Sync Dbus Call: version Args:empty
2021.12.01 10:34:05 5: signal: Sync Dbus Call: isRegistered Args:empty
2021.12.01 10:34:05 4: signal: Sync Error for: isRegistered
2021.12.01 10:34:05 5: signal: Sync Dbus Call: listAccounts Args:empty
2021.12.01 10:34:05 5: signal: My Dbus Name is :1.286
2021.12.01 10:35:00 5: signal: Sync Dbus Call: register Args:+49xxxxx,0
2021.12.01 10:35:01 4: signal: Sync Error for: register
2021.12.01 10:37:13 5: signal: Sync Dbus Call: registerWithCaptcha Args:+49xxxxx,0,03AGdBq26G3DtKGHF5b7WxN1-VE_yMlsadya4WiisQf3rryTufRgL4JjX-4YrRgi0p9JFTeUwbmaX2ayyBl_jSc9YyhHYE-zlGnEqUEeNjfUuXScNxIf_tIN5Xrl-_bAMimDIB5WpLfbhF4bUOOsrp3HaeA4NWUEdaDYoyuHMmw7kS7KTBs395mDoQTSbFF9g2zOXt3CVCXTY39ic9c6zjHlOmgsZE7wlUdNEq1VHctNwQb_HbBQd4MfWC1A4YRKsg_bx5QDQ9HPAQ7uXv0y4LSIuix8R2ZpaD5KoOdv8wuc6jQs0y9ZedzyAWyplXC4jw10IGhk959Hp-WmkfopMz68KSXJcTzVopMqIiAUWYO1wNuVj7EUVVmZx9u9EJZNQtAEZTTrtdT0R8vFEDz_a5ubnaugmZ5V64l-5EABT5zpQCaMnvKekj3-Zmsmt09wNa-PXEx74r0qXZx_oOIQYNMTvzOR7mvSc-tQ
Mache ich was in der Reihenfolge falsch?
1. set register +49xxxxx
2. set captcha signalcaptcha://03AGdBq26G3DtKGHF5b ...
Gruß LuGu
Hmm, da knallt es ja schon vorher (Sync Error for....).
Kannst du nach jedem Schritt (und gleich nach FHEM Start) mal schauen was im reading "lastErr" steht?
Zitat von: Adimarantis am 01 Dezember 2021, 10:59:20
Hmm, da knallt es ja schon vorher (Sync Error for....).
Kannst du nach jedem Schritt (und gleich nach FHEM Start) mal schauen was im reading "lastErr" steht?
fhem Start: No account registered - use set account to connect to an existing registration, link or register to get a new account
2021.12.01 11:02:54 5: signal: Init: signal Signalbot
2021.12.01 11:02:54 4: signal: Protocol::DBus version found 0.19
2021.12.01 11:02:54 5: signal Setting number to default
set register: Error in register:Captcha required for verification
2021.12.01 11:05:35 5: signal: Sync Dbus Call: register Args:+49xxxxxxxxx,0
2021.12.01 11:05:36 4: signal: Sync Error for: register
set captcha: Error in register:Captcha required for verification
2021.12.01 11:07:35 5: signal: Sync Dbus Call: registerWithCaptcha Args:+49xxxxxxxxx,0,03AGdBq27mng8c17REZ9v9SII3zZD8jIRY0f4ajyb6CNw2ka2cDeH5eV8Fqpb_yjLqf89fWbwK4Wm-d7pafZRtb8apRxYid1ZMP5kQoghv9n_v1Bx2KLWRIYDdiAqDbb7jcVouPOWyJziQkz9zfYFzjXLkKep3GiAFoWDciZawbq-8AfM8AViUYyQNmnYYXe9wiXGPLrP6J9G8Yoxx4JVNC_0SeN2CAX0zluGpvaNuHD6bb0UytVSfZRhiOUDZncRvGw4DTQrMXmPmA3rhCE6N_WCL3VQvcXswQZpma5hsPo0tOSG0ZdEHYA5F8rqQVW3YiTeoAAjToUWIXKCnQ7JUt8Ij4aOepsV1bRtp54FkTSIn1ZN7uu9uf9LBe_Mo9zO7BxlYQbDWHWltEJldot2AVAG3-CbFsHta8ADyc8jHPrG380vjgtjefk5mH5EqTwwxsySaOwN2C-w2S1JG2Ccl4lyIT1SQ0nK5TA
Ist ne Festnetznummer die ich zu registrieren versuche.
Was mir jetzt nur auffällt: Du scheinst SMS Registrierung zu machen (ist default).
Bei Festnetz willst du aber wahrscheinlich eher angerufen werden, also
attr signal registerMethod Voice
Erklärt aber immer noch nicht warum diese "Incorrect captcha" Meldung kommt - oder hast du die beim letzten Mal gar nicht bekommen?
Ja, ich hatte es mit SMS und Voice versucht. Vorher hatte ich getestet, was bei einer SMS an die Festnetzummer passier. Die SMS wurde vorgelesen.
Die Registrierung hat aber in beiden Fällen nicht funktioniert.
Ich habe es jetzt in fhem aufgegeben und es über die shell nach dem Tip von enno gemacht.
Das hat auf Anhieb geklappt.
Danke für eure Unterstützung.
Ich habe das Wiki Troubleshooting entsprechend mit dem Workaround von enno ergänzt und einen Bug für signal-cli aufgemacht.
Leider scheint das in manchen Fällen derzeit die einzige Lösung zu sein.
Update signal-cli 0.9.2
Nachdem ich festgestellt habe, dass die nächste signal-cli Version auch von Java 11 auf Java 17 updaten wird, habe ich mich dazu entschlossen jetzt signal-cli 0.9.2 als vorerst letzte signal-cli version freizugeben. Heisst leider auch dass es wohl erstmal keinen Fix für das weiter oben beschriebene Captcha Problem geben wird.
Wer updaten will holt mit "reinit" das neueste Script nach www/signal und führt es mit
sudo ./signal_install.sh
aus.
Sofern eine Warnung "[....] is an unsupported combination - signal-cli binary libraries might not work" kommt, sollte die Installation abgebrochen werden.
Es gibt aktuell aber keinen zwingenden Grund für das Update - V0.9.0 kann getrost weiter verwendet werden.
Hintergrund zu der Java Version:
In Debian bzw. Raspian "Buster" ist nur openJDK11 verfügbar. Es gibt zwar Java17, aber derzeit nicht offiziell über "apt install".
Java17 ist erst mit Debian "Bullseye" (11.x) offiziell verfügbar. Inzwischen ist zwar auch das entsprechende Raspberry OS basierend auf "Bullseye" verfügbar, es wird aber geraten eine Neuinstallation zu machen - und wer macht das mit einem Heimautomatisierungssystem, wenn sonst alles läuft.
Mittelfristig werde ich mir anschauen, ob neue signal-cli Versionen interessant genug sind, um den Aufwand zu betreiben, den Installer um eine "private" Java Version zu ergänzen bzw. "Bullseye" zu unterstützen. Ihr seht aber schon - die Platformabhängigkeiten werden immer komplexer.
@Jamo: Ich denke ich habe den richtigen Branch dafür gefunden um die Debian 10 libs zu übersetzen, hab diese aber nicht getestet. Wäre schön wenn du das überprüfen könntest.
Jörg
Hallo Jörg,
ich hab den update-Prozess durchlaufen, ist auch ordentlich durchgelaufen, bekomme aber diese Info im Device:
VERSION Signalbot:3.1 signal-cli:0.9.0 Protocol::DBus:0.19
Das Modul habe ich auch noch per reload erneuert.
Viele Grüße Gisbert
Ein nicht beabsichtigter Fhem-Neustart hat dazu geführt, dass jetzt die richtige Signal-Version angezeigt wird.
Hi,
ich hatte gestern versucht, erstmalig Signal zu installieren. Das hat leider nicht geklappt...
Vor einigen Monaten war ich schonmal an einem völlig veralteten Betriebssystem gescheitert, weswegen ich dann mein Raspberry mal komplett neu aufgesetzt habe und nun "Linux raspi3 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l" läuft.
Außer fhem und Samba habe ich auch nichts besonderes noch installiert.
Dann habe ich mich an den Wiki-Beitrag und das install-script gehalten. Als erstes fiel mir dann "armhf-glibc2.31-0.9.0 is an unsupported combination" auf, habe aber weiter gemacht, weil ich dachte, ich habe doch die neuesten Pakete.
Nunja, bei start signal-cli service blieb er dann (wie erwarten?) hängen:
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.
OpenJDK Server VM warning: You have loaded library /tmp/resource3715067888090005771.so which might have disabled stack guard. The VM wi>
Dez 04 22:37:53 raspi3 signal-cli[2232]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Damit bin ich wohl beim "Standard-Fehler" auf Raspberrys wie im zweiten Eintrag der FAQ beschrieben. Das Löschen von /opt/signal hat aber nichts gebracht. Der erste der "weiteren Tests" zeigt dann auch tatsächlich Treffer:
sudo ldconfig -v | grep libzkgroup.so
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.31.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
Ich bin in Linux nicht so zu Hause, dass ich dieses Ergebnis nun selbst beheben könnte.
Daher nun meine Fragen,
* bin ich nach dem "unsupported combination" überhaupt noch richtig davor? Wie könnte ich eine supported combination hinkriegen?
* wie kann ich die mehrfach angegebenen Pfade beheben?
* im Wiki war es für mich nicht klar, ob ich vor oder nach dem Skript, den Signalbot in fhem definieren muss.. Wann muss das geschehen?
Danke für Hinweise,
Gruß Volker
Hi Volker,
Du bist dann schon auf "bullseye".
Dafür habe ich mangels eigenem System, leider die nativen Libs noch nicht übersetzt.
Diese hängen von der verwendeten glibc Version ab und die muss exakt stimmen, sonst gibt es beim Start einen Fehler.
Ich hab vor mein Testsystem demnächst auf bullseye zu ziehen, dann kann ich das machen.
Oder magst du dich dran probieren?
Jörg
Hallo Jörg,
ich hab Debian 11 und Signal läuft bei mir, auch das gestrige Update. Wenn du sagst wo, was und wie ich nachschauen soll, dann mach ich das gerne.
Viele Grüße Gisbert
Zitat von: Gisbert am 05 Dezember 2021, 09:49:22
ich hab Debian 11 und Signal läuft bei mir, auch das gestrige Update. Wenn du sagst wo, was und wie ich nachschauen soll, dann mach ich das gerne.
Debian 11 auf Intel Architektur geht (das ist sogar die Standard Version die bei signal-cli dabei ist) - das Problem von Volker ist Raspian "Bullseye" (abgeleitet von Debian 11) auf dem Raspberry mit ARM Architektur.
Aber Danke für das Angebot.
Zitat von: Adimarantis am 04 Dezember 2021, 19:32:38
Update signal-cli 0.9.2
...
@Jamo: Ich denke ich habe den richtigen Branch dafür gefunden um die Debian 10 libs zu übersetzen, hab diese aber nicht getestet. Wäre schön wenn du das überprüfen könntest.
Jörg
Hallo Jörg,
ja Du hast den richtigen Branch für die Debian 10 libs gefunden, es funktioniert. DANKE! ! !
Hallo Jörg,
danke für die Info. Im wiki klingt der Prozess zum Übersetzen der Libraries ganz einfach ;-) Daher habe ich es mal versucht, bin aber grandios gescheitert...
Rust hat noch geklappt, aber beim Clonen des Codes von github fingen die Probleme mit "Permission denied (publickey)" an. Muss man da zwingend ein Account anlegen? Naja, ich habe mir dann das zip-file runtergeladen und auf den Raspberry (entpackt) kopiert. Leider meldete dann das make zwischendurch ein paarmal "thread 'rustc' panicked at ...", "note: the compiler unexpectedly panicked. this is a bug." und endete mit
query stack during panic:
end of query stack
error: could not compile `cfg-if`
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:7: native_library] Fehler 101
Eine library wurde dann leider auch nicht erzeugt.
Habe dann fertige libraries gesucht und wohl auch gefunden, jedenfalls lief schließlich das install-script ohne Fehler durch, das Captcha ließ sich mit den Anweisungen in fhem besiegen und ich habe dann meine erste Nachricht auf meinem Handy empfangen :)
Den Rest probiere ich in den nächsten Tagen weiter - Danke und Gute Nacht für heute!
Das Übersetzen der libs kann manchmal problematisch sein.
Das Projekt setzt auf pre-releases des rust compilers und ich hatte das Problem auch schon mal, weil der Compiler für ARM kaputt war.
Außerdem muss man noch aufpassen, dass man nicht mehr die neusten Versionen übersetzen darf, sondern auf ältere Tags zurückgehen muss.
Wo hast du die übersetzten libs für ARM Bullseye gefunden? Sofern diese sicher funktionieren kann ich die in den Installer aufnehmen.
Um einen besseren Überblick über die verwendeten Linux Distros zu bekommen, habe ich eine neue Version 3.2 von Signalbot released, die in das interne reading "model" eben diese Info schreibt (z.B. Raspbian GNU/Linux 10 (buster) ).
Damit taucht das dann in https://fhem.de/stats/statistics.html auf.
Um das Reading nach dem update zu füllen ist ein "shutdown restart" nötig.
Um es zu senden ein "fheminfo send".
Um es dann regelmässig bei Updates zu senden, wäre "attr global sendStatistics onUpdate" zu setzen. Wäre schön wenn das jeder aktivieren könnte um einen besseren Überblick zu bekommen.
Jörg
Hallo,
mal also Hinweis. Der Link https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signal-cli-packages (https://svn.fhem.de/fhem/trunk/fhem/thirdparty/signal-cli-packages) in diesem Text:
ZitatAlternatively go to FHEM SVN thirdparty and download the matching Debian package
Install with e.g. sudo apt install ./signal-cli-dbus_0.9.0-1_buster_armhf.deb (./ is important to tell apt this is a file)
funktioniert nicht.
Gruß
Christian
Hallo,
ich have eine Rapi mitOperating System: Raspbian GNU/Linux 10 (buster)
Kernel: Linux 5.10.63-v7+
Architecture: armv71
Ich habe mit wget https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/signal_install.sh das install script herunter geladen.
Mit chmod a+x signal_install das script ausführbar gemacht und mit den default Einstellungen gestartet.
Also mit sudo ./signal_install
Ja ich hatte ursprünglich mal SiSi am laufen.
Als Fehler bekomme ich:
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
This will update system packages, install or uninstall signal-cli
<----snipped---->
Start signal-cli service
Job for signal.service failed because a timeout was exceeded.
See "systemctl status signal.service" and "journalctl -xe" for details.
Checking installation via dbus-send command...Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Sending a message via perl Protocol::DBus...Error getting reply
output von systemctl zeigt aber an das Signal wohl läuft:
pi@FHEM:~ $ systemctl status 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 Tue 2021-12-07 12:39:42 CET; 3min 18s ago
Main PID: 13495 (java)
Tasks: 15 (limit: 2059)
CGroup: /system.slice/signal.service
+-13495 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.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.1.jar:/opt/signal/lib/slf4j
Dez 07 12:38:36 FHEM2021 systemd[1]: Starting Send secure messages to Signal clients...
Dez 07 12:39:42 FHEM2021 systemd[1]: Started Send secure messages to Signal clients.
Was muss ich den genau entfernen von der alten SiSi installation?
Gruß
Christian
Hi Christian,
Möglicherweise hat der Start von signal-cli einfach nur zu lange gedauert (und daher schlägt der Selbsttest fehl). Das hatten wir gerade auf Raspberrys teilweise schon.
Wenn du mit
ps -ef | grep signal-cli
den entsprechenden Java Prozess findest, sollte eigentlich alles ok sein.
Du kannst auch den Test vom Script einfach mal manuell durchführen
dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.version
Wenn alles klappt sollte er die signal-cli version zurückliefern.
Dann sollte es unter FHEM eigentlich auch funktionieren.
Möglicherweise macht es doch Sinn den service timeout generell (auf einen Wert höher als der default) zu setzen.
Ein vorherige SiSi Installation sollte eigentlich nicht stören.
Jörg
Hallo,
als erstes habe ich mal nach dem wicki https://wiki.fhem.de/wiki/Signalbot#Registrierung (https://wiki.fhem.de/wiki/Signalbot#Registrierung)
sudo find / -name libzkgroup.so 2>/dev/null
sudo find / -name zkgroup-java-*.jar 2>/dev/null
sudo find / -name libsignal_jni.so 2>/dev/null
sudo find / -name signal-client-java-*.jar 2>/dev/null
gemacht und alle files die ich gefunden habe mit sudo rm /path/to/file/name diese gelöscht.
Danach das ./signal_install.sh ausgeführt.
Das device in FHEM angelegt und die nummer registriert.
Hab dann sogar nochmal cpan install -f Protocol::DBus gemacht
pi@FHEM2021:~ $ systemctl status 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 Tue 2021-12-07 14:25:54 CET; 26s ago
Main PID: 3498 (java)
Tasks: 32 (limit: 2059)
CGroup: /system.slice/signal.service
+-3498 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.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.1.jar:/opt/signal/lib/slf4j-
Dez 07 14:25:04 FHEM2021 systemd[1]: Starting Send secure messages to Signal clients...
Dez 07 14:25:54 FHEM2021 signal-cli[3498]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_4960.......
auch der dbus scheint zu laufen
pi@FHEM2021:~ $ 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 Tue 2021-12-07 14:25:54 CET; 5min ago
Main PID: 3498 (java)
Tasks: 32 (limit: 2059)
CGroup: /system.slice/signal.service
+-3498 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.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.1.jar:/opt/signal/lib/slf4j-
Dez 07 14:25:04 FHEM2021 systemd[1]: Starting Send secure messages to Signal clients...
Dez 07 14:25:54 FHEM2021 signal-cli[3498]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_4960.......
Das Ergebniss vom Test:
dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.version
method return time=1638884204.249008 sender=:1.82 -> destination=:1.85 serial=6 reply_serial=2
string "0.9.2"
Auch dieser Test läuft:
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
Versuche ich nun aus der FHEM GUI eine Nachricht zu schicken mit set SigBot send @+4916....... Das ist ein Test um 14:40
Sehe ich in der GUI lastError
lastError Error in sendMessage:Message recipient disconnected from message bus without replying
Natürlich war Verbose auf 5 gesetzt und im log finde ich
2021.12.07 14:41:09 3: SigBot: Before parse:@+4916...... Das ist ein Test um 14:41:
2021.12.07 14:41:09 4: SigBot: sendMessage called for +4916.......::Das ist ein Test um 14:41
2021.12.07 14:41:09 5: SigBot: ASync Dbus Call: sendMessage Args:Das ist ein Test um 14:41,ARRAY(0x7efcf38),ARRAY(0x8d5f840)
2021.12.07 14:41:09 5: msgConfig globalMsg: called function msgConfig_Set()
2021.12.07 14:41:11 4: SigBot: ASync Error for: sendMessage
Zitat von: Kohle77 am 07 Dezember 2021, 14:46:37
lastError Error in sendMessage:Message recipient disconnected from message bus without replying
Den Fehler hatte ich heute auch mit 0.9.2 direkt nach einem FHEM Restart - nach einem reinit gings dann wieder. Probier das mal.
Hab vorher noch nie gesehen.
Hi,
ich habe mal einen reboot gemacht. Ergebnis:
sudo 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: signal) since Tue 2021-12-07 15:14:16 CET; 19s ago
Process: 530 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=killed, signal=ABRT)
Main PID: 530 (code=killed, signal=ABRT)
Dez 07 15:14:16 FHEM2021 signal-cli[530]: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
Dez 07 15:14:16 FHEM2021 signal-cli[530]: #
Dez 07 15:14:16 FHEM2021 signal-cli[530]: # An error report file with more information is saved as:
Dez 07 15:14:16 FHEM2021 signal-cli[530]: # /tmp/hs_err_pid530.log
Dez 07 15:14:16 FHEM2021 signal-cli[530]: #
Dez 07 15:14:16 FHEM2021 signal-cli[530]: # If you would like to submit a bug report, please visit:
Dez 07 15:14:16 FHEM2021 signal-cli[530]: # Unknown
Dez 07 15:14:16 FHEM2021 signal-cli[530]: #
Gruß
Christian
Hmm, was sagt denn
systemctl status signal.service
und
journalctl -xe
Hi,
hab signal mal gestartet mit
sudo systemctl start signal.service
danach war der service active (running)
Jetzt in FHEM in der GUI ein reinit und alles sah ok aus.
Mit set SigBot ... versucht eine message zu schicken but Fehler:
lastError Error in sendMessage:Message recipient disconnected from message bus without replying
und der Dienst läuft danach nicht mehr.
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: signal) since Tue 2021-12-07 15:40:19 CET; 4min 38s ago
Process: 2042 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=killed, signal=ABRT)
Main PID: 2042 (code=killed, signal=ABRT)
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # An error report file with more information is saved as:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # /tmp/hs_err_pid2042.log
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # If you would like to submit a bug report, please visit:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # Unknown
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 systemd[1]: signal.service: Main process exited, code=killed, status=6/ABRT
Dez 07 15:40:19 FHEM2021 systemd[1]: signal.service: Failed with result 'signal'.
und journalctl -xe
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # A fatal error has been detected by the Java Runtime Environment:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # SIGSEGV (0xb) at pc=0x7650136c, pid=2042, tid=2162
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # JRE version: OpenJDK Runtime Environment (11.0.12+7) (build 11.0.12+7-post-Raspbian-2deb10u1)
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # Java VM: OpenJDK Server VM (11.0.12+7-post-Raspbian-2deb10u1, mixed mode, serial gc, linux-)
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # Problematic frame:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # V [libjvm.so+0x25a36c]
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # An error report file with more information is saved as:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # /tmp/hs_err_pid2042.log
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # If you would like to submit a bug report, please visit:
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: # Unknown
Dez 07 15:40:19 FHEM2021 signal-cli[2042]: #
Dez 07 15:40:19 FHEM2021 systemd[1]: signal.service: Main process exited, code=killed, status=6/ABRT
Gruß
Christian
So ein "harter" Absturz in Java kann eigentlich nur mit den native libs zusammenhängen.
Hab gerade bei mir geschaut und das hatte ich heute morgen auch - aber komischerweise nur heute morgen (dafür 4 mal innerhalb von 5 Minuten), obwohl das System schon Tage auf der 0.9.2 läuft. Seitdem wieder kein Problem obwohl diverse Messages gesendet und empfangen wurden.
Probier mal auf 0.9.0 zurückzugehen (einfach im signal_install.sh die Version editieren und drüber laufen lassen).
Hi,
nachdem ändern der Version und einfach drüber installieren zeigt systemctl status signal.client:
Dez 07 17:53:56 FHEM2021 systemd[1]: Starting Send secure messages to Signal clients...
Dez 07 17:54:05 FHEM2021 signal-cli[7056]: OpenJDK Server VM warning: You have loaded library /tmp/resource6692934069678612009.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dies is ja schon im Wicki beschrieben.
Also habe ich ein remove mit Version 0.9.2 und zur Sicherheit 0.9.0 laufen lassen.
Das device in FHEM gelöscht.
Jetzt nochmal mit:
sudo find / -name libzkgroup.so 2>/dev/null
sudo find / -name zkgroup-java-*.jar 2>/dev/null
sudo find / -name libsignal_jni.so 2>/dev/null
sudo find / -name signal-client-java-*.jar 2>/dev/null
alles abgesucht aber nichts gefunden.
Im install script wieder die 0.9.0 eingetragen und mit
sudo ./signal_install.sh
das ganze installiert.
Aber auch da startet der signal.service nicht.
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
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 Tue 2021-12-07 18:05:20 CET; 1min 17s ago
Process: 7861 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1/FAILURE)
Main PID: 7861 (code=exited, status=1/FAILURE)
Dez 07 18:05:09 FHEM2021 systemd[1]: Starting Send secure messages to Signal clients...
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: OpenJDK Server VM warning: You have loaded library /tmp/resource2366696904404504317.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: WARN ServiceConfig - Failed to call libzkgroup: /tmp/resource2366696904404504317.so: /tmp/resource2366696904404504317.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word width
Dez 07 18:05:19 FHEM2021 signal-cli[7861]: WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Dez 07 18:05:20 FHEM2021 signal-cli[7861]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource479949972762061985.so: /tmp/resource479949972762061985.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word wi
Dez 07 18:05:20 FHEM2021 signal-cli[7861]: Missing required native library dependency: libsignal-client
Dez 07 18:05:20 FHEM2021 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Dez 07 18:05:20 FHEM2021 systemd[1]: signal.service: Failed with result 'exit-code'.
Dez 07 18:05:20 FHEM2021 systemd[1]: Failed to start Send secure messages to Signal clients.
journalctl -xe bringt diese Fehler:
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: OpenJDK Server VM warning: You have loaded library /tmp/resource2366696904404504317.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Dez 07 18:05:18 FHEM2021 signal-cli[7861]: WARN ServiceConfig - Failed to call libzkgroup: /tmp/resource2366696904404504317.so: /tmp/resource2366696904404504317.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word width
Dez 07 18:05:19 FHEM2021 signal-cli[7861]: WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Dez 07 18:05:20 FHEM2021 signal-cli[7861]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource479949972762061985.so: /tmp/resource479949972762061985.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word wi
Dez 07 18:05:20 FHEM2021 signal-cli[7861]: Missing required native library dependency: libsignal-client
Dez 07 18:05:20 FHEM2021 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit signal.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Dez 07 18:05:20 FHEM2021 systemd[1]: signal.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service has entered the 'failed' state with result 'exit-code'.
Dez 07 18:05:20 FHEM2021 systemd[1]: Failed to start Send secure messages to Signal clients.
-- Subject: A start job for unit signal.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 2493 and the job result is failed.
Dez 07 18:05:34 FHEM2021 dbus-daemon[362]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Dez 07 18:05:34 FHEM2021 sudo[7616]: pam_unix(sudo:session): session closed for user root
Gruß
Christian
Hi,
ich bin da über noch etwas gestolpert.
sudo ldconfig -v | grep libzkgroup.so
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
und
sudo ldconfig -v | grep libsignal_jni.so
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
Ist das normal oder meinst du dieses Ergebnis mit dem im wicki beschriebenen "Da die libraries in .jar files eingebettet sind, darf hier keine gefunden werden."
Gruß
Christian
Was du beim ldconfig siehst ist wahrscheinlich normal - das ist stderr output welches vom grep nicht weggefiltert wird. Die libs die wir brauchen findet er nicht - das passt.
Allerdings ist bei dir noch irgendwas mit den libs/jars nicht in Ordnung.
Um alles sauber zu kriegen - lösch mal komplett /opt/signal und dann nochmal signal_install.sh ausführen.
Jörg
Edit: Obwohl, das Script das eigentlich sowieso schon macht....
Hallo,
also mal geschaut was ich in /opt finde und die beiden removed:
/opt $ ls
fhem fhem2 gradle-7.2 signal signal-cli_source vc zkgroup-0.7.4
/opt $ sudo rm -r signal
/opt $ sudo rm -r signal-cli_source
Das Ergebniss ist:
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 Wed 2021-12-08 07:30:57 CET; 33s ago
Process: 2881 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1/FAILURE)
Main PID: 2881 (code=exited, status=1/FAILURE)
Mit systemctl status signal.service bekomme ich das:
Dez 08 07:30:46 FHEM systemd[1]: Starting Send secure messages to Signal clients...
Dez 08 07:30:56 FHEM signal-cli[2881]: OpenJDK Server VM warning: You have loaded library /tmp/resource14856610907052668369.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dez 08 07:30:56 FHEM signal-cli[2881]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Dez 08 07:30:56 FHEM signal-cli[2881]: WARN ServiceConfig - Failed to call libzkgroup: /tmp/resource14856610907052668369.so: /tmp/resource14856610907052668369.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word widt
Dez 08 07:30:56 FHEM signal-cli[2881]: WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Dez 08 07:30:57 FHEM signal-cli[2881]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource4834344169808386157.so: /tmp/resource4834344169808386157.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word
Dez 08 07:30:57 FHEM signal-cli[2881]: Missing required native library dependency: libsignal-client
Dez 08 07:30:57 FHEM systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Dez 08 07:30:57 FHEM systemd[1]: signal.service: Failed with result 'exit-code'.
Dez 08 07:30:57 FHEM systemd[1]: Failed to start Send secure messages to Signal clients.
Das journalctl -xe liefert dies:
journalctl -xe
-- The job identifier is 3611.
Dez 08 07:30:32 FHEM signal-cli[2818]: OpenJDK Server VM warning: You have loaded library /tmp/resource15504035341442631258.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dez 08 07:30:32 FHEM signal-cli[2818]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Dez 08 07:30:32 FHEM signal-cli[2818]: WARN ServiceConfig - Failed to call libzkgroup: /tmp/resource15504035341442631258.so: /tmp/resource15504035341442631258.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word widt
Dez 08 07:30:33 FHEM signal-cli[2818]: WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Dez 08 07:30:34 FHEM signal-cli[2818]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource13299115370021254553.so: /tmp/resource13299115370021254553.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture wor
Dez 08 07:30:34 FHEM signal-cli[2818]: Missing required native library dependency: libsignal-client
Dez 08 07:30:35 FHEM systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit signal.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Dez 08 07:30:35 FHEM systemd[1]: signal.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service has entered the 'failed' state with result 'exit-code'.
Dez 08 07:30:35 FHEM systemd[1]: Failed to start Send secure messages to Signal clients.
-- Subject: A start job for unit signal.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 3611 and the job result is failed.
Dez 08 07:30:39 FHEM kernel: Voltage normalised (0x00000000)
Dez 08 07:30:46 FHEM dbus-daemon[362]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Dez 08 07:30:46 FHEM dbus-daemon[362]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.service' requested by ':1.81' (uid=0 pid=2880 comm="perl /tmp/signal2607.tmp ")
Dez 08 07:30:46 FHEM 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 3677.
Dez 08 07:30:56 FHEM signal-cli[2881]: OpenJDK Server VM warning: You have loaded library /tmp/resource14856610907052668369.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Dez 08 07:30:56 FHEM signal-cli[2881]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Dez 08 07:30:56 FHEM signal-cli[2881]: WARN ServiceConfig - Failed to call libzkgroup: /tmp/resource14856610907052668369.so: /tmp/resource14856610907052668369.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word widt
Dez 08 07:30:56 FHEM signal-cli[2881]: WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Dez 08 07:30:57 FHEM signal-cli[2881]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource4834344169808386157.so: /tmp/resource4834344169808386157.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: architecture word
Dez 08 07:30:57 FHEM signal-cli[2881]: Missing required native library dependency: libsignal-client
Dez 08 07:30:57 FHEM systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit signal.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Dez 08 07:30:57 FHEM systemd[1]: signal.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service has entered the 'failed' state with result 'exit-code'.
Dez 08 07:30:57 FHEM systemd[1]: Failed to start Send secure messages to Signal clients.
-- Subject: A start job for unit signal.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 3677 and the job result is failed.
Dez 08 07:31:11 FHEM dbus-daemon[362]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Dez 08 07:31:11 FHEM sudo[2605]: pam_unix(sudo:session): session closed for user root
Gruß
Christian
Hi Christian,
Ich denke ich hab das Problem gefunden: Der Installer hatte einen Fehler und hat ausgerechnet für die Kombination arm 0.9.0 die libs gar nicht upgedated (was so ein "," ausmachen kann). Sorry for that. (Wäre daran zu sehen gewesen das er sich über "unsupported combination" mockiert hat)
Hol dir vom svn oder per "reinit" bitte das neuste signal_install.sh, passe es wieder für 0.9.0 an, und dann sollte es hoffentlich klappen.
Für 0.9.2 habe ich eine Idee - muss ich erst probieren. Die libs werden mit experimentellen Rust compiler Versionen übersetzt und ich erinnere mich, dass es da Probleme für ARM gab, als ich die entsprechend libs gebaut hab. Ich musste die Compiler Version ändern, damit es überhaupt ging. Evtl. war trotzdem noch ein Wurm drin. Ich hab die jetzt mal neu (neuerer Compiler) übersetzt und probiere ob das so läuft, wenn das bei mir stabil läuft, aktualisiere ich es und du kannst die 0.9.2 nochmal probieren.
Fürs erste aber hoffe ich die 0.9.0 läuft bei dir jetzt.
Jörg
Hi,
erstmal danke für die Hilfe.
Ich bekomme einen Fehler das der Signal Service nicht gestartet werden kann während der installation.
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for /usr/share/perl5/URI.pm...available
Checking for Protocol::DBus...V0.19 found
Checking user signal-cli ...found
Checking for /opt...found
Checking for /var/lib/signal-cli...created
Checking for existing signal-cli installation...not found
Proceed with signal cli installation
Stopping signal-cli service
Downloading signal-cli 0.9.0...done
Unpacking ...
Downloading native libraries...done
Updating native libs for armhf-glibc2.28-0.9.0
updating: libzkgroup.so (deflated 72%)
updating: libsignal_jni.so (deflated 73%)
done
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf.../etc/dbus-1/system.d/org.asamk.Signal.conf installed
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service.../usr/share/dbus-1/system-services/org.asamk.Signal.service installed
Checking for /etc/systemd/system/signal.service.../etc/systemd/system/signal.service installed
Created symlink /etc/systemd/system/dbus-org.asamk.Signal.service ? /etc/systemd/system/signal.service.
Created symlink /etc/systemd/system/multi-user.target.wants/signal.service ? /etc/systemd/system/signal.service.
Start signal-cli service
Job for signal.service failed because a timeout was exceeded.
See "systemctl status signal.service" and "journalctl -xe" for details.
Checking installation via dbus-send command...Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Sending a message via perl Protocol::DBus...reply received
Checked ich die beiden services scheint org.asamk.Signal.service nicht zu laufen
pi@FHEM:~ $ sudo systemctl status org.asamk.Signal.service
Unit org.asamk.Signal.service could not be found.
aber der Signal Service läuft:
pi@FHEM:~ $ sudo systemctl status 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 Wed 2021-12-08 10:26:59 CET; 2min 12s ago
Main PID: 1846 (java)
Tasks: 16 (limit: 2059)
CGroup: /system.slice/signal.service
+-1846 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-
Dez 08 10:26:17 FHEM systemd[1]: Starting Send secure messages to Signal clients...
Dez 08 10:26:59 FHEM systemd[1]: Started Send secure messages to Signal clients.
hab mal noch einen shutdown -h now , power removed und wieder angestöpselt, jetzt scheint es zu laufen.
Danke
Christian
Zitat von: Adimarantis am 07 Dezember 2021, 11:17:44
Wo hast du die übersetzten libs für ARM Bullseye gefunden? Sofern diese sicher funktionieren kann ich die in den Installer aufnehmen.
Ich habe die libs bei https://github.com/bublath/FHEM-Signalbot (https://github.com/bublath/FHEM-Signalbot) gefunden und dann die
armhf-glibc2.28-0.9.0 ausgesucht.
Hinterher fiel mir auf, dass es nicht gclib2.31 ist, aber es funktionert trotzdem :)
VERSION Signalbot:3.2 signal-cli:0.9.0 Protocol::DBus:0.19
model Raspbian GNU/Linux 11 (bullseye)
Linux raspi3 5.10.63-v7+ #1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l
Ein Update auf 0.9.2 verschiebe ich aber erstmal, bevor es da vielleicht doch Komplikationen zwischen den Versionen gibt. Das selbstkompilieren habe ich dann auch wieder aufgegeben ;-)
Die Statistik kannte ich noch gar, ist ja spannend, was sich in fhem bei mir inzwischen angesammelt hat. Von nun an sende ich es mit jedem Update :)
Gruß Volker
Hi,
eine weitere Frage habe ich noch, wo ich gerade über eine Benachrichtigung mit einem DOIF sitze.
Ich möchte den Zeitstempel eines Readings mit in die Signal-Nachricht übernehmen.
[out_temp:temperature] gibt mir logischerweise den Inhalt des Readings wieder.
[out_temp:temperature:t] funktioniert in fhem über die Befehlszeile, aber nicht im DOIF. DOIF kennt das t nicht.
[out_temp:temperature:sec] funktioniert im DOIF, liefert aber nur die vergangenen Sekunden
({ReadingsTimestamp('out_temp,'temperature',0)}) funktioniert nicht, obwohl ich das im DOIF für Benachrichtungen per Email so verwendet habe.
Kann mir hier jemand ein Tipp geben? Gibt es im Signalbot eine eigene Unterstützung für die Zeitstempel oder wäre das eher ein Thema für DOIF?
Hi Volker,
Interessant, dass das mit den buster libs auf bullseye funktioniert. Hätte ich jetzt nicht erwartet.
Zitat von: vaulie am 08 Dezember 2021, 23:23:18
eine weitere Frage habe ich noch, wo ich gerade über eine Benachrichtigung mit einem DOIF sitze.
Ich möchte den Zeitstempel eines Readings mit in die Signal-Nachricht übernehmen.
Diese Verschachtelungen können mitunter extrem tricky werden.
Viele Wege führen nach Rom, aber eine Idee wäre, dass du den Signal Aufruf komplett im Perl Mode einbettest und dir den Timestamp vorher in eine Variable holst:
{ my $ts=ReadingsTimestamp('out_temp','temperature',0);
fhem("set SignalBot send \@Joerg Hi $ts");
}Jörg
Hallo,
leider bin ich mich den Einträgen hier nicht weiter gekommen und möchte meine Frage nun so stellen:
Ich nutze den SignalBot in FHEM und das klappt auch wunderbar Danke für das "Modul" - sehr hilfreich!
Parallel dazu habe ich signal-cli auch in Skripten direkt auf meinem Debian12-Server verwendet, indem ich folgendes aufrufen:
/opt/signal/bin/signal-cli --dbus-system send -m "Backup Sharkoon Duply (incremental) --> Sharkoon\Seagate: keine Fehler." +49151xxxxxxx
Das hat auch immer wunderbar funktioniert, bis ich festgestellt habe, dass er mir den folgenden Fehler rausgibt:
The method `org.asamk.Signal.getSelfNumber' does not exist on this object.
Ich hoffe, das mir jemand den entsprechenden Tipp geben kann, wie ich signal-cli, auf das ja am Ende SignalBot aus FHEM auch zugreift, wieder zum Laufen bekomme.
Ich bekomme leider nicht raus, wie SignalBot aus FHEM auf signal-cli zugreift, sonst könnte ich mir den funktionierenden Aufruf für die Kommando-Zeile daraus ableiten...
Gruß
Heiko
Hallo Heiko,
Ganz verstehe ich deine Konfiguration nicht. Aber ich treffe jetzt mal die Annahme das du die FHEM signal-cli installation einfach mitverwenden willst und es sich um keine eigenständige Installation handelt.
Ich denke dein Grundproblem ist, das deine eigene Konfigurationsnummer nicht mit angibst (-u parameter) - weiss aber nicht ob das überhaupt so geht, seitdem die Hauptinstanz von signal-cli im Registermodus läuft (also mit gar keiner Nummer verknüpft ist).
In diesem Fall würde ich einfach mit dbus-send arbeiten, da viel schlanker zum starten als signal-cli
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_xxxxxx org.asamk.Signal.sendMessage string:Hallo array:string: string:+49yyyy
Wobei org/asamk/Signal/_xxxxxx genau das ist was in Signalbot als "connected to" steht.
Jörg
Edit: Habe das jetzt mal im Wiki ergänzt. Dabei ist mir eingefallen, dass eine weitere Methode natürlich noch wäre einfach FHEM per telnet anzusteuern und den entsprechenden "set" Befehl für Signalbot abzusetzen.
Top, genau das habe ich gesucht. Danke für den zielführenden Hinweis, Jörg!
Das einzige, was ich nun noch brauchte, war das Hinzufügen von Attachments, was sich aber mit folgendem Code lösen ließ:
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_xxxxxx org.asamk.Signal.sendMessage string:Hallo array:string:'/path/to/attachment1','/path/to/attachment2' string:+49yyyy
Das findet sich so auch in der GitHub-Doku von signal-cli https://github.com/AsamK/signal-cli/blob/master/man/signal-cli-dbus.5.adoc#examples (https://github.com/AsamK/signal-cli/blob/master/man/signal-cli-dbus.5.adoc#examples)
Wenn man das noch in der .bashrc des Linux-Systems den folgenden Alias anlegt
alias signal='function _(){ dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_49xxxxx org.asamk.Signal.sendMessage string:$1 array:string:$2 string:$3; }; _'
... dann kann man einfach in Konsole mit
signal 'Hallo Welt' '/home/user/attachment.dat' +49yyyy
... die Befehlslänge abkürzen.
Mit wurde geholfen, also Danke!
Gruß, Heiko
Native library updates:
Ich habe jetzt die Raspberry libraries für "buster" neu übersetzt und getestet und für "bullseye" hinzugefügt (nur für signal-cli 0.9.2). Das signal_install.sh im svn ist entsprechend aktualisert und wird über "reinit" nach www/signal geladen.
Hallo,
leider bekomme ich beim Senden einer Nachricht an einen bekannten Kontakt (wird in der Liste aufgeführt) die folgende Meldung:
Error in sendMessage:1639294521628
Failed to send message:
Untrusted Identity for "+49175xxxxxxx"
Aber meine Frage ist, wie ich den Kontakt in die verifizieren kann?
Ich finde im SignalBot-Interface leider keine Option dafür.
Für Hilfe wäre ich Dankbar!
Gruß,
Heiko
Hallo Heiko,
das kann meines Wissens passieren, wenn dein Kommunikationspartner Signal auf seinem Handy neu installiert hat. Dies wird als mögliches Sicherheitsrisiko eingestuft und du musst der Nummer explizit wieder vertrauen, wofür es sogar extra einen Prozess gibt, bei dem man Sicherheitscodes vergleichen muss.
Das DBus interface hat dafür leider (noch) keine Option.
Es gibt hier zwei Möglichkeiten:
1. Man könnte signal-cli so starten, das immer vertraut wird. Dazu muss man in den startup den Parameter
--trust-new-identities always
einfügen. Da bin ich jetzt ein wenig hin- und hergerissen das über den Installer zum Standard zu machen - hat ja auch einen Grund dass das normalerweise geprüft wird
2. Über die Kommandozeile gibt es eine Option einer Nummer zu vertrauen. Dazu muss allerdings der daemon kurzfristig beendet werden (es kann immer nur einer auf die Konfiguration zugreifen):
sudo service signal stop
sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49<Eigene Nummer> trust -a +49<zu vertrauende Nummer>
sudo service signal start
Ich hab jetzt den Fall selber nicht und kann nicht überprüfen ob das hilft. Wenn alles klappt nehme ich das ins Wiki auf.
"-a" heisst hier übrigens, dass der Nummer (mit dem aktuellen Code) blind vertraut wird. Normalerweise muss man hier sogar noch einen Sicherheitscode übergeben.
Jörg
Hallo Jörg,
über Deinen zweiten Vorschlag war ich erfolgreich und diesen halte ich auch für den sinnvollen Weg - zumindest in meinem Fall.
Habe es auch mit "-a" ausprobiert.
Laut Dokumentation von signal-cli (https://github.com/AsamK/signal-cli/blob/master/man/signal-cli.1.adoc#examples (https://github.com/AsamK/signal-cli/blob/master/man/signal-cli.1.adoc#examples)) wäre der Befehl mit Verwendung der Sicherheitsnummer dann wohl:
sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49<Eigene Nummer> trust -v <Sicherheitsnummer> +49<zu vertrauende Nummer>
Passt vielleicht im FHEMWiki unter "Troubleshooting/FAQ".
Gruß & Dank
Heiko
PS: Dort fand ich auch gerade den Abschnitt "Versenden von Nachrichten ohne FHEM". Damit hätte ich mir meine ursprüngliche Frage auch selbst beantworten können :-X. Ich Blindfisch.
Zitat von: heiko.ne am 12 Dezember 2021, 10:37:08
PS: Dort fand ich auch gerade den Abschnitt "Versenden von Nachrichten ohne FHEM". Damit hätte ich mir meine ursprüngliche Frage auch selbst beantworten können :-X. Ich Blindfisch.
Der Abschnitt ist erst Aufgrund deiner Frage drin ;)
Coole Sache.
Sehr überschaubar die Ersteinrichtung.
Nur eine Frage:
wie setze ich einen Avatar und einen Namen?
Gruß
set updateProfile <new name> [&<avatar picture>]
Das Bild muss ein für FHEM lesbarer Dateiname sein und sollte kleiner 2MB sein.
Jörg
Danke für die Rückmeldung.
Aber es kommt ein Fehler:
Error in updateProfile:Error Executing Method org.asamk.Signal.updateProfile: Could not initialize class org.signal.zkgroup.internal.Native
Gruß
Also bei mir funktioniert es.
Grundsätzlich zum Bild: Am Besten absoluter Pfad (z.B. /opt/fhem/xxx.png) und der User signal-cli muss die Datei auch lesen können.
Der Fehler deutet aber eher auf ein Installationsproblem mit der nativen zkgroup library hin.
Da müsste dann eigentlich auch etwas im syslog stehen wenn der Service gestartet wird. Außerdem solltest du dann eigentlich auch Probleme mit der Verwendung von Gruppen haben.
Was für ein Linux verwendest du (was steht in "model")?
Jörg
Gruppen verwende ich nicht.
Model: Debian GNU/Linux 11 (bullseye)
Die Installation hab ich gemäß Anleitung durchgeführt.
Es funktioniert auch nicht wenn ich NUR den Namen setzen möchte.
Hallo Adimarantis,
ich habe den gleichen Fehler bei set userProfile, wenn ich versuche meinem fhem Account einen Namen zu geben.
Log:
2021.12.22 21:30:05 4 signal: ASync Dbus Call: updateProfile Args:myName,,,,0
2021.12.22 21:30:05 4: signal: ASync Error for: updateProfile
Reading lastError:
Error in updateProfile:Error Executing Method org.asamk.Signal.updateProfile: Could not initialize class org.signal.zkgroup.internal.Native 2021-12-22 21:30:05
Nach einem reinit steht folgendes im Log:
2021.12.22 21:54:44 5: Disconnected and cleaned up
2021.12.22 21:54:44 5: signal: Sync Dbus Call: version Args:empty
2021.12.22 21:54:44 5: signal: Sync Dbus Call: isRegistered Args:empty
2021.12.22 21:54:44 4: signal: Sync Error for: isRegistered
2021.12.22 21:54:44 5: signal: Sync Dbus Call: listAccounts Args:empty
2021.12.22 21:54:44 5: signal: ASync Dbus Call: listNumbers Args:empty
2021.12.22 21:54:44 5: signal: My Dbus Name is :1.82
Das "Error for: isRegistred" irritiert mich, denn die Kommunikation zw. fhem und meinem Handy funktioniert ohne Probleme.
Gruß LuGu
Guten Morgen.
Kann ich so bestätigen.
Habe das selbe Verhalten.
Gruß
Hi LuGu,
bist auf dem selben OS wie remo? Evtl. stimmt da dann was mit den native Libraries nicht (ich verwende die Kombi selbst nicht produktiv). Zumindest die Dateigröße von zkgroup passte nicht.
Im Falle von Debian 11 (auch @remo) bitte mal /opt/signal löschen und signal_install.sh nochmal laufen lassen. Ich hoffe dass es dann funktioniert.
Der "isRegistered" Fehler ist normal. Leider hat der signal-cli Author meinen PR nicht übernommen der diese Funktion konsistent zur Verfügung stellt, daher nehme ich das Fehlen dieser Funktion als Indikator. Muss mir vielleicht noch was besseres überlegen, aber normalerweise sieht man das ja nicht.
Jörg
Moin Jörg,
ja, bei mir läuft auch Debian 11. Nachdem ich deinen Hinweis befolgt habe, gibt es keine Fehlermeldung mehr.
Ich komme aber glaube ich mit den Parametern für updateProfile noch nicht klar.
Nach einem:
send updateProfile myName &/opt/fhem/www/images/myAvatar.png
habe ich diese Logeinträge:
2021.12.23 10:27:59 4: signal: updateProfile Avatar /opt/fhem/www/images/myAvatar.png
2021.12.23 10:27:59 5: signal: ASync Dbus Call: updateProfile Args:myName,,,/opt/fhem/www/images/myAvatar.png,0
Die myAvar.png wird übernommen, kann ich auf der Gegenseite (Handy) sehen.
Ich kann aber nicht erkennen, dass der Account Name übernommen wurde.
Ist mein Aufruf updateProfile falsch?
Gruß LuGu
Hi LuGu,
Das ist so schon richtig. Eventuell erscheint die Änderung nicht sofort in Signal.
Hast du schon eine Nachricht gesendet?
Bei mir steht zumindest im 1:1 Chat auf dem Handy dann "<alter name> hat den Profilnamen zu <neuer name> geändert" - die Aktualisierung in der Übersicht dauert aber möglicherweise länger.
Jörg
Hat funktioniert.
Besten Dank und schöne Weihnachten!
Hast Rech Jörg. Ich war nur zu ungeduldig.
Funktioniert alles.
Danke!
Gruß LuGu
Hallo,
ich musste mein System wegen eines Crashs neu aufsetzen, leider bekomme ich Signalbot absolut nicht mehr zum Laufen.
Das System ist ein X64 Ubunutu 21.10.
Signal ohne DBus funktioniert ohne Probleme, versuche ich aber Signal über Dbus zu nutzen, bekomme ich immer eine Fehlermeldung:
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_49XXXXXXXX org.asamk.Signal.sendMessage string:Hallo array:string: string:+49YYYYYYYYYYY
Error org.freedesktop.dbus.errors.UnknownObject: /org/asamk/Signal/_XXXXXXXX is not an object provided by this process.
Der Test aus dem Installscript läuft problemlos durch:
sudo ./signal_install.sh test
amd64-glibc2.34-0.9.2 is an unsupported combination - signal-cli binary libraries might not work
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
Wie bekomme ich das ganze wieder ans Laufen?
Ich stelle jetzt mal Vermutungen an:
1. Du schreibst Neuinstallation - hast du komplett neu installiert oder irgendwelche alten Dateien "gerettet" und übernommen?
-> In dem Fall wäre zu prüfen ob du eine alte /etc/systemd/system/signal.service hast die noch den "-u Nummer" Parameter drin hat. Das Installscript sollte das eigentlich überschreiben - aber nur wenn du es erlaubst.
2. Wenn du den Inhalt von /var/lib/signal-cli nicht gerettet hast, dann fehlt dir die Registrierung.
-> Dann müsstest du die Nummer in FHEM erneut registrieren (das passiert jetzt nicht mehr über das Script sondern benutzergeführt)
Desweiteren kannst du mal in /var/log/system schauen ob da irgendwelche Fehlermeldungen beim signal service start drinstehen - da du ja eine "unsupportete" libc Version hast. Da allerdings der grundlegende Test funktioniert, scheint das eher nicht dein Problem zu sein - besonders wenns vorher mal ging
Wie schaut das Ganze bei dir überhaupt in FHEM aus? Welche Meldungen bekommst du dort?
Es handelt sich um ei e komplette Neuinstallation, das einzige was mit rübergenommen wurde war der fhem Ordner.
Registrierung wurde neu durchgeführt, ich schrieb ja, ohne dbus klappt das Senden und Empfangen ja.
Die Fehlermeldung im FHEM ist die gleiche:
Error in sendMessage:/org/asamk/Signal/_xxxxxxxxs not an object provided by this process.
Gruß
Alex
Hi Alex,
Steht in /var/log/syslog irgendwas davon, dass er Probleme mit den native libraries hat?
Was kannst du in FHEM machen (wenn die Registrierung geklappt hat, muss ja grundsätzlich was gehen)?
Was kommt bei get accounts, get contacts, get groups und so?
Hat die Registrierung wirklich geklappt? Du könntest mal den service stoppen und dann nur über Kommandozeile mit
sudo -u signal-cli /opt/signal/bin/signal-cli --verbose --config /var/lib/signal-cli -u +49<regnummer> send +49<Empfänger> -m Hallo
probieren ob alles passt, bzw. was du dann für Fehlermeldungen siehst.
Jörg
Hallo Jörg,
im Syslog ist leider nicht all zu viel drin:
Dec 26 08:47:17 fhem systemd[1]: Stopping Send secure messages to Signal clients...
Dec 26 08:47:17 fhem systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Dec 26 08:47:17 fhem systemd[1]: signal.service: Failed with result 'exit-code'.
Dec 26 08:47:17 fhem systemd[1]: Stopped Send secure messages to Signal clients.
Dec 26 08:47:17 fhem systemd[1]: signal.service: Consumed 3min 42.014s CPU time.
.Dec 26 08:47:31 fhem dbus-daemon[714]: Unknown group "power" in message bus configuration file
Dec 26 08:47:31 fhem dbus-daemon[714]: [system] Reloaded configuration
Dec 26 08:47:35 fhem dbus-daemon[714]: Unknown group "power" in message bus configuration file
Dec 26 08:47:35 fhem dbus-daemon[714]: [system] Reloaded configuration
Dec 26 08:47:56 fhem dbus-daemon[714]: Unknown group "power" in message bus configuration file
Dec 26 08:47:56 fhem dbus-daemon[714]: [system] Reloaded configuration
Dec 26 08:48:01 fhem dbus-daemon[714]: Unknown group "power" in message bus configuration file
Dec 26 08:48:02 fhem systemd[1]: Reloading D-Bus System Message Bus.
Dec 26 08:48:02 fhem dbus-daemon[714]: [system] Reloaded configuration
Dec 26 08:48:02 fhem dbus-daemon[714]: Unknown group "power" in message bus configuration file
Dec 26 08:48:02 fhem dbus-daemon[714]: [system] Reloaded configuration
Dec 26 08:48:02 fhem dbus-send[757363]: method return time=1640504882.464535 sender=org.freedesktop.DBus -> destination=:1.24051 serial=3 reply_serial=2
Dec 26 08:48:02 fhem systemd[1]: Reloaded D-Bus System Message Bus.
Dec 26 08:48:03 fhem systemd[1]: Starting Send secure messages to Signal clients...
.
.
Dec 26 08:48:25 fhem systemd[1]: Started Send secure messages to Signal clients.
Diese Meldungen kommen bei neustarten des DBus Services bzw bei neustarten des Signal Services.
Das Senden ohne DBus geht fehlerfrei durch :
signal-cli --config /var/lib/signal-cli -u +49XXXXXXXXXXX send -m "Hallo Signal ;-)" +49************
1640523826275
Das mit DBus endet wie gehabt in der Fehlermeldung:
signal-cli -c /var/lib/signal-cli -u +49XXXXXXXXXXX --dbus-system send +49************ -m "Signal-CLI funktioniert mit DBus"
/org/asamk/Signal/_49XXXXXXXXXXX is not an object provided by this process.
Gruß
Alex
Zitat von: Adimarantis am 26 Dezember 2021, 12:43:00
Was kannst du in FHEM machen (wenn die Registrierung geklappt hat, muss ja grundsätzlich was gehen)?
Was kommt bei get accounts, get contacts, get groups und so?
Sonst deutet das Fehlerbild eigentlich darauf hin, dass der service falsch gestartet wurde (mit -u Parameter statt ohne).
Was kommt denn bei
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal org.asamk.Signal.sendMessage string:Hallo array:string: string:+49YYYYYYYYYYY
Error org.freedesktop.dbus.errors.UnknownMethod: The method `org.asamk.Signal.sendMessage' does not exist on this object.
Schick mal die Ausgabe von
dbus-send --system --dest=org.asamk.Signal --type=method_call --print-reply /org/asamk/Signal org.freedesktop.DBus.Introspectable.Introspect
method return time=1640543407.921723 sender=:1.24834 -> destination=:1.25655 serial=14 reply_serial=2
string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/org/asamk/Signal">
<interface name="org.asamk.SignalControl">
<method name="version" >
<arg type="s" direction="out"/>
</method>
<method name="register" >
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.Failure" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.InvalidNumber" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.RequiresCaptcha" />
<arg type="s" direction="in"/>
<arg type="b" direction="in"/>
</method>
<method name="verify" >
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.Failure" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.InvalidNumber" />
<arg type="s" direction="in"/>
<arg type="s" direction="in"/>
</method>
<method name="link" >
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.Failure" />
<arg type="s" direction="in"/>
<arg type="s" direction="out"/>
</method>
<method name="registerWithCaptcha" >
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.Failure" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.InvalidNumber" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.RequiresCaptcha" />
<arg type="s" direction="in"/>
<arg type="b" direction="in"/>
<arg type="s" direction="in"/>
</method>
<method name="verifyWithPin" >
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.Failure" />
<annotation name="org.freedesktop.DBus.Method.Error" value="org.asamk.SignalControl.Error.InvalidNumber" />
<arg type="s" direction="in"/>
<arg type="s" direction="in"/>
<arg type="s" direction="in"/>
</method>
<method name="listAccounts" >
<arg type="ao" direction="out"/>
</method>
</interface>
<interface name="org.freedesktop.DBus.Introspectable">
<method name="Introspect" >
<arg type="s" direction="out"/>
</method>
</interface>
<interface name="org.freedesktop.DBus.Peer">
<method name="Ping" >
</method>
<method name="GetMachineId" >
<arg type="s" direction="out"/>
</method>
</interface>
</node>"
Dann hast du anscheinend keine Nummer registriert (zumindest nicht vollständig) sonst würde da am Schluss sowas kommen:
</interface>
<node name="_49xxxxxxxxx"/>
</node>"
Entsprechend dürften dir auch in FHEM mit "get accounts" keine Nummern angezeigt werden.
Was kommt denn bei
sudo ls /var/lib/signal-cli/data
?
Wenn es da für deine registrierte Nummer kein Verzeichnis gibt, dann kennt DBus/FHEM sie auch nicht.
Du hast mal gesagt das send ohne DBus geht - hast du die Nummer direkt mit signal-cli manuell registriert und diese mit dem lokalen User statt mit signal-cli und --config /var/lib/signal-cli registriert?
Dann stünde die Registrierung in ~/.local/share/signal-cli/data
Das kannst du dann mit sudo signal-cli ins richtige Verzeichnis kopieren, dann Neustart vom Service und es müsste gehen.
Jörg
Hallo Jörg,
als erstes mal danke für deine aufopferungsvolle Hilfsbereitschaft, erst Recht an soch einem Tag!
Die Registrierung habe ich mit dem FHEM Ordner mitgesichert (war vorher auch das Homeverzeichnis des Users fhem).
Die Daten habe ich natürlich rüberkopiert nach /var/lib/signal-cli/data.
der Ausagbe ist erwartungsgemäß:
+49XXXXXXXX +49XXXXXXXX.d
Gruß
Alex
Stimmen die Zugriffrechte (Besitzer signal-cli)?
Fakt ist dass er die Registrierung irgendwie nicht findet.
Im Zweifelsfall löschen und neu registrieren.
Ich werde morgen nochmal versuchen neu zu registrieren.
Danke Dir.
Gruß
Alex
Bevor du das machst, versuch wirklich erstmal die Rechte zu korrigieren:
cd /var/lib/signal-cli
sudo chown -R signal-cli *
sudo chmod -R 700 *
sudo service signal restart
Die Verzeichnisse müssen (1) für signal-cli lesbar sein, aber (2) nicht für andere.
Jörg
Vielen Dank für die hilfreiche Anleitung, hat alles out-of-the-box bei einem Raspberry (Linux raspfhem 5.10.63-v7+ #1459) geklappt, inklusive Festnetz-Anruf und Captcha.
Eine Sache war komisch. Als ich "update" gemacht habe, wurde 50_Signalbot.pm bei mir nicht hinzugefügt. Das kann aber auch an meiner lokalen Installation liegen, die ist ziemlich alt. Ich habe das dann händisch eingefügt, aus dem SVN.
Hallo Jörg,
nach der Neuregistrierung läuft es nun, vielen Dank für deinen Support!
Gruß
Alex
Guten Abend,
der Signalbot funktioniert wirklich gut. Ich habe allerdings ein Problem bei Versenden von attachments (gplot) bei Verwendung der configdb. Er findet das File nicht (das ja in der configdb liegt). Ist das nicht implementiert oder mache ich etwas falsch?
Viele Grüße
Guido
Also ich glaube nicht dass das was mit der configDB zu tun hat. Die plotAsPng Funktion liefert einen Stream - die Datei schreibt erst SignalBot (nach /tmp)
Wie machst du das denn?
So etwa sollte es eigentlich klappen:
set SignalBot send @Joerg &({plotAsPng(\"SVG_Temp\")})
wobei SVG_Temp der Name des SVG devices ist.
Danke für das Feedback,
ich habe das Problem gefunden bei Nutzung der configdb.
Wenn man ' statt " benutzt, funktioniert das Schicken vom Filesystem, aber nicht von der configdb.
Das hier funktioniert also bei der configDB und im Filesystem:
set SignalBot send @Joerg &({plotAsPng(\"SVG_Temp\")})
Das funktioniert nur im Filesystem (also nicht bei configDB
set SignalBot send @Joerg &({plotAsPng(\'SVG_Temp\')})
Ich verstehe trotzdem nicht warum das bei configDB einen Unterschied macht.
Wenn ich das richtig verstehe "überschreibt" configDB den attr Befehl (und andere). Wenn du configDB auf loglevel 4 setzt sollte sowas wie "configdb: attr ...." bzw. configdb: fileimport ..." etc. rausschreiben. Wäre interessant was da im Fall ' anders ist als bei "
Danke für anzweifeln, und leider stimmt das auch.
Fehler war ein anderer :-[
Ich hatte ein Leerzeichen zwischen \' und dem Filenamen... - also das Kommando unten ist falsch.
set signalBot send &({plotAsPng(\' SVG_FileLog_Bezug_Haus_Strom_aktuell_1\')})
Hallo Jörg,
vielen Dank für deine super Arbeit!
Ich hätte die Frage ob man irgendwie den Namen und das Avatar Bild nachträglich setzen kann - oder muss man dann alles mit der Option "name" neu installieren?
Danke und viele Grüße
Kasi
Zitat von: Adimarantis am 04 Februar 2021, 11:02:04
Nachdem es erste positive Rückmeldungen gibt, habe ich das Script wieder im ersten Post geupdated.
Noch neu dazu gekommen:
sudo ./signal_install.sh name
zum Setzen eines Namens und Avatar Bildes.
Meiner heißt jetzt FHEM und hat das FHEM logo.
Frage an alle Mitstreiter:
Das mit den Captchas ist ja gerade im Chrome ziemlich umständlich. Soweit ich weiß sollte es in Chrome möglich sein einen Protocol Handler zu schreiben (als Plugin oder einfach Script?) der auf das "signalcaptcha://" Protokoll reagiert. Das Teil sollte einfach ein Fenster aufmachen und den Rest dieser "URL" anzeigen (die Kür wäre ein "copy" Button). Kennt sich da jemand aus?
Jörg
Das geht jetzt mit "set updateProfile"
Da muss ich wohl mal den ersten Post aufräumen - ist nicht mehr aktuell.
Jörg
:) Super, vielen Dank für die schnelle Antwort!
Beste Grüße
Kasi
Zitat von: Adimarantis am 05 Januar 2022, 15:37:09
Das geht jetzt mit "set updateProfile"
Da muss ich wohl mal den ersten Post aufräumen - ist nicht mehr aktuell.
Jörg
Halllo Zusammen,
ich habe Probleme mit dem Registrierungsprozess.
Ich verwenden den automatisierten Prozess mit dem Windows Registry-File im Firefox. Es kommt das Captcha, dann der Power-Shell-Dialog und dann kommt "Fehler: Verbindung unterbrochen", wenn fhem mit "set signalbot captcha signalcaptcha..." aufgerufen wird.
Im fhem log kommt "FHEMWEB SSL/HTTPS error: SSL accept attempt failed error:1408F09C:SSL routines:ssl3_get_record:http request..."
Wenn ich die Regstrierung neu starte, das gleiche. Auch wenn ich aus der URL das "set signalbot captcha signalcaptcha..." kopiere und in der fhem console eingebe, funktioniert es nicht. Fhem sagt als lastError "Invalid Captcha". Inzwischen kommt aber ein "Rate limit exceeded", vermutlich zu oft die Registrierung probiert.
Versionen sind "Signalbot:3.2 signal-cli:0.9.2 Protocol::DBus:0.19". State ist "Connected to /org/asamk/Signal", account "none".
Jemand eine Idee, was man tun kann?
Hast du irgendwelche besonderen Settings in FHEMWEB?
Ansonsten schau bitte mal ins Wiki https://wiki.fhem.de/wiki/Signalbot unter Troubleshooting. Das sind ein paar Ansätze beschrieben.
Wie du schon richtig vermutest wirst du aber etwas warten müssen, bis du es erneut probieren kannst.
danke, ich habe mal Logging angestellt, die Registrierungsdaten wie unter Troubleshootign erläutert gelöscht und auch die Registrierung manuell probiert, leider weiterhin ohne Erfolg.
2022.01.09 15:05:29.684 5: signalbot: Sync Dbus Call: registerWithCaptcha Args:+49xxx,0,xxx
2022.01.09 15:05:30.439 4: signalbot: Sync Error for: registerWithCaptcha
Die zu registrierende Nummer ist eine Festnetznummer.
Im syslog steht:
Jan 9 15:05:56 signal-cli[25983]: Jan. 09, 2022 3:05:56 NACHM. okhttp3.internal.platform.Platform log
Jan 9 15:05:56 signal-cli[25983]: WARNUNG: A connection to https://chat.signal.org/ was leaked. Did you forget to close a response body? To see where this was allocated, set the OkHttpClient logger level to FINE: Logger.getLogger(OkHttpClient.class.getName()).setLevel(Level.FINE);
Bekomme immer wieder den Fehler "invalid captcha".
Sisi hatte ich nie.
FhemWeb hat außer https 1, longpoll 1, Closeconn 1 keine besonderen Einstellungen. Die registry habe ich an https angepasst, aber das spielt ja für die manuelle Registrierung keine Rolle und die ging ja auch nicht.
Hat jemand eine Idee?
Jetzt klappt es. Ich hatte vergessen registrationMethod auf Voice zu setzen, da Festnetznummer...
Modul läuft bestens. Endlich kann ich von telegram auf signal umstellen.
Vielen Dank für die Bereitstellung des Moduls und die Hilfe.
Hi Ihr Wissenden,
ich mache gerade das Upgrade von SiSi auf Signalbot.
SiSi wurde entfernt.
OS-upgrade auf buster durchgeführt.
Installation (0.9.2) über signal_install.sh:
- ./signal_install.sh remove (wegen evtl. Relikten)
- ./signal_install.sh system
- ./signal_install.sh install
- ./signal_install.sh test => Fehler
systemctl status signal.service => WARN ServiceConfig - Failed to call libsignal-client
FHEM sagt "signal-cli v0.9.0+ required" (ich vermute, dass ist ein Nebeneffekt, weil der Service nicht startet).
Wie kann ich diesen Fehler beheben?
Vielen Dank im Voraus,
Carsten
root@...-vm:/opt/fhem/www/signal# 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 Sun 2022-01-09 16:13:12 CET; 1min 21s ago
Process: 13349 ExecStart=/opt/fhem/signal/bin/signal-cli --config /opt/fhem/.local/share daemon --system (code=exited, status=1/FAILURE)
Main PID: 13349 (code=exited, status=1/FAILURE)
Jan 09 16:13:11 ...-vm systemd[1]: Starting Send secure messages to Signal clients...
Jan 09 16:13:12 ...-vm signal-cli[13349]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource12544258437177110165.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource12544258437177110165.so)
Jan 09 16:13:12 ...-vm signal-cli[13349]: Missing required native library dependency: libsignal-client
Jan 09 16:13:12 ...-vm systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Jan 09 16:13:12 ...-vm systemd[1]: signal.service: Failed with result 'exit-code'.
Jan 09 16:13:12 ...-vm systemd[1]: Failed to start Send secure messages to Signal clients.
Da stimmt irgendwas mit den native libraries nicht.
Kommt bei ./signal_install.sh irgendeine Meldung zwecks "unsupported combination" ?
"buster" hat eigentlich glibc2.28 - dein system beschwert sich aber wegen 2.29 (hat buster die evtl. kürzlich geupdated? Oder ist durch dein Upgrade ein Wurm drin?)
Was kommt bei
ldd --version
?
Du könntest evtl. probieren ob die 2.31 von bullseye geht - dazu die Zeile
GLIBC=`ldd --version | grep -m1 -o '[0-9]\.[0-9][0-9]' | head -n 1`
ändern in
GLIBC=2.31
Vorher /opt/signal löschen und dann ./signal_install.sh (ohne paramter) laufen lassen.
ldd meldet
ldd (Debian GLIBC 2.28-10) 2.28
Ich hab's auf 2.31 konfiguriert. In der Ausgabe kommt dann:
Downloading signal-cli 0.9.2...done
Unpacking ...
Downloading native libraries...done
Updating native libs for amd64-glibc2.31-0.9.2
updating: libzkgroup.so (deflated 62%)
updating: libsignal_jni.so (deflated 75%)
done
Vor dem Install habe ich zur Sicherheit noch ein "signal_install.sh remove" abgesetzt...
Ich kann leider nicht ausschließen, dass ich durch das Upgrade was Falsches ("2.29") reinbekommen habe :(
Beim Service-Start kommt:
WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource10719490676299380055.so: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/resource10719490676299380055.so)
Schmeiss mal alles was du an Java auf der Kiste hast runter und lass dann den Installer nochmal neu laufen (/opt/signal wieder löschen und die Änderung auf 2.31 rückgängig).
Der Installer installiert die Standard Java version wenn er keine findet, die sollte eigentlich passen - außer du hast irgendeine andere Abhängigkeit von einer speziellen Java Version.
libc scheint ja zu passen, also vermute ich eher was mit Java
RESPEKT !!! ;D
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:
...
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
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
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:
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
Zitat von: kroman am 14 Januar 2022, 08:59:01
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.
Zitat von: kroman am 14 Januar 2022, 08:59:01
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.
Zitat von: kroman am 14 Januar 2022, 08:59:01
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
Zitat von: kroman am 14 Januar 2022, 08:59:01
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.
Zitat von: kroman am 14 Januar 2022, 08:59:01
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.
Zitat von: kroman am 14 Januar 2022, 08:59:01
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
ZitatZitat3. 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".
Zitat von: weini am 14 Januar 2022, 11:54:20
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
Hallo,
ich bin jetzt endlich umgezogen und habe jetzt ein neues Problemchen.
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:
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:
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:
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
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
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.
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
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
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:
[temp]print Im Wohnzimmer sind es [dht11_5:temperature] °C;
oder auch als Perl
[temp]{my $var=ReadingsVal("dht11_5","temperature",0);;return $var;;}
Ist aber noch nicht gut durchgetestet.
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.
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.
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:
Defined favorites:
ID [Alias] Command
1 1234567890123456789012...
- wenn der 1. Favorit mit "-" versehen ist, wird das nicht angezeigt, wird aber ohne Authentifizierung ausgeführt.
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
Zitat- 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
Zitat- 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
Zitat- 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
Zitat- 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")
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...
ZitatDas 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
Alles klar
ZitatThat'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
Okay
ZitatDas 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")
Komisch, jetzt funktioniert es mit "/" auf, k.A. was ich da vorher gemacht habe.
ZitatHier 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
Okay, das war das Leerzeichen, alles klar.
Ich versuche gerade signatbot ans laufen zu bekommen.
Unter FHEM ist es installiert.
Der Dienst läuft.
Den QR Code habe ich abgescannt. Meine Nummer ist registriert.
Ich hänge bei dem letzten Schritt mit dem Capture.
Der reg Hack ist ausgeführt. Die Powershell CLI kommt hoch, ich löse das capture.
aber FHEM meldet nur zurück:
Incorrect captcha - e.g. needs to start with signalcaptcha://
Aber das stimmt nicht der string beginnt damit.
Es kommt immer der selbe string auch wenn ich fhem neustarte bzw. warte.
Gibt's da noch eine Trick?
@Basti-K
Hast du es mal im mit einem Browser versucht und mit F12 den Entwickler Modus geschaltet und dort in die Console geschaut (benutze chrome)?
Habe allerdings kein reg hack installiert.
Gruß
Christian
Den "link" Flow habe ich schon länger nicht mehr getested. Da ist ein Fehler in der Benutzerführung.
Du brauchst nämlich gar kein Captcha dafür.
Workaround:
1. QR Code abscannnen
2. set reinit
3. set signalAccount <Handynummer>
Falls die Handynummer bei "set signalAccount" nicht auftaucht ggf. FHEM neu starten. In meiner aktuellen Testversion geht das, aber da hab ich dran geschraubt.
Dann sollte es klappen, dass du Nachrichten sowohl mit dem Handy als auch FHEM empfängst und "als Handy" Nachrichten versenden kannst.
Allerdings ist die empfohlende Variante für produktive Nutzung der Weg eine neue Nummer über "register" zu registrieren.
Gruß,
Jörg
Wenn ich den QR Code it dem Handy (und bestätige) bekomme ich die Rückmeldung Netzwerkfehler.
Auf dem Handy ist kein Gerät verknüpft. (Android 10)
In fehm steht in den Readings aber meine Handynummer.
Reinit
Erzeugt:
lastError Error in listNumbers:/org/asamk/Signal/_491726259061 is not an object provided by this process.
. set signalAccount wird mir gar nicht angeboten.
Fhem bzw. den ganzen Pi hab ich schon neu gestartet. Automatisch startet signal-cli nicht. da muss man nachhelfen. ist das normal?
edit: Ich hab das device noch mal gelöscht und neu angelegt.
dann den QR Code gescannt. Eine Kurze Rückmeldung: Gerät freigeschaltet, aber unter gekoppelte Geräte erscheint nichts auf dem Handy/app.
Unter fehm kommt auch nichts wenn man auf get accounts klicke.
Will ich noch mal den QR Code scannen erscheint gerät nicht gefunden.
ZitatAutomatisch startet signal-cli nicht. da muss man nachhelfen. ist das normal?
Schau dazu bitte mal ins Wiki -> Troubleshooting: https://wiki.fhem.de/wiki/Signalbot#Troubleshooting_.2F_FAQ
Wenn signal-cli nicht läuft sind deine Fehlermeldungen normal. Auch hier sollte nachdem signal-cli manuell nachgestartet wurde ein "set reinit" helfen.
Wer liefert "Netzwerkfehler"?
Ich habe den Flow jetzt mal ein wenig verbessert. Bitte probier mal die aktuelle Testversion auf https://github.com/bublath/FHEM-Signalbot
Leider gibt es derzeit keinen "Trigger" bei einem erfolgreichen Link. Es hilft also immer nur kurz warten und set reinit.
Guten Morgen.
,,Netzwerkfehler" erscheint auf dem Handy. Nachdem man den QR Code ein zweites mal scannt.
Ich habe mit das aktuelle Git Repo gezogen und install neu gestartet. (die pm hat das datum von heute, sollte die richtige sein)
Das Modul wurde auch in fhem ausgetauscht.
Aber leider das gleiche in grün.
Nun bekomme ich nicht mal mehr meine Nummer unter Accounts angezeigt.
QR Code wird erkannt, aber es kommt dennoch keine Verknüpfung zu Stande.
Wo finde ich mehr debungs infos die ich anliefern kann?
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for /usr/share/perl5/URI.pm...available
Checking for Protocol::DBus...V0.19 found
Checking user signal-cli ...found
Checking system Java version ... 11.0
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.9.2
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
Start signal-cli service
Checking installation via dbus-send command...success
Sending a message via perl Protocol::DBus...reply received
Deine Installation schaut erstmal gut aus.
Um alles sauber zu haben (du hast ja sonst nichts registriert, oder?) evtl. noch
sudo rm -r /var/lib/signal-cli/data
service signal restart
und FHEM "shutdown restart"
Bei mir klappt dann
- link
- qrcode scannen
- im Handy approven
- 1 Minute warten
- set reinit
einwandfrei. Die Nummer wird dann mit der Github Version automatisch erkannt.
Weitere logs:
Im Signalbot verbose=5 setzen und schauen was im fhem log kommt
Fehlermeldungen von signal-cli könnten in
sudo grep signal-cli /var/log/syslog
stehen
danke für deine Antwort und besonders für deine Arbeit.
ich bin dahinter gekommen. Bzw. hab's geschafft.
ich hab das Verzeichnis /var/lib/signal-cli/data manuell gelöscht,
./signalinstall.h remove bzw danach install durchgeführt.
vielleicht war der der erste Schritt überflüssig und remove hatte es auch erledigt. falls nicht würde ich vorschlagen das dies mit in die Routine kommt.
Zitat von: Adimarantis am 15 Januar 2022, 18:35:33
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:
[temp]print Im Wohnzimmer sind es [dht11_5:temperature] °C;
oder auch als Perl
[temp]{my $var=ReadingsVal("dht11_5","temperature",0);;return $var;;}
Ist aber noch nicht gut durchgetestet.
Habe das jetzt bei mir umgestellt: Sehr cool, spart mir einen Sack notifies und dummies.
Beim Auflisten der Favoriten sind mir dabei noch zwei Kleinigkeiten aufgefallen:
- Umlaute im Aliastext werden nicht korrekt dargestellt. Wobei die Frage ist, ob man das braucht...
- Wenn die Perl-Variante wie oben beschrieben genutzt wird, dann wird der Aliastext nicht angezeigt, da passt wohl die Regex nicht mehr.
Hallo Adimarantis,
ich hab das Update per SVN auf die Version 3.3 durchgeführt; alles lief anscheinend glatt, ohne dass ich etwas davon bemerkt habe. Das Modul funktioniert anstandslos.
TYPE Signalbot
VERSION Signalbot:3.3 signal-cli:0.9.2 Protocol::DBus:0.19
model Debian GNU/Linux 11 (bullseye)
Viele Grüße und vielen Dank
Gisbert
Zitat von: weini am 17 Januar 2022, 12:22:16
- Umlaute im Aliastext werden nicht korrekt dargestellt. Wobei die Frage ist, ob man das braucht...
- Wenn die Perl-Variante wie oben beschrieben genutzt wird, dann wird der Aliastext nicht angezeigt, da passt wohl die Regex nicht mehr.
Danke - das ist trivial zum fixen - kommt dann im release
Leider war meine Freude von kurzer Dauer. Nach einem Test reboot kommt der service nicht mehr hoch.
pi@FHEM:~/FHEM-Signalbot $ sudo systemctl status signal.service status
Unit status.service could not be found.
● signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Mon 2022-01-17 14:11:40 CET; 18min ago
Process: 12276 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=143)
Main PID: 12276 (code=exited, status=143)
Jan 17 14:10:10 FHEM systemd[1]: Starting Send secure messages to Signal clients...
Jan 17 14:11:40 FHEM systemd[1]: signal.service: Start operation timed out. Terminating.
Jan 17 14:11:40 FHEM systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Jan 17 14:11:40 FHEM systemd[1]: signal.service: Failed with result 'timeout'.
Jan 17 14:11:40 FHEM systemd[1]: Failed to start Send secure messages to Signal clients.
Den Timeout hatte ich schon höher gestellt aber ich glaube das scheint nichts damit zu tun zu haben?!
Schau mal bitte ob dir der Tipp mit dem Timeout in signal.service aus dem Wiki etwas hilft.
Ich hatte das selber zwar noch nicht, aber es gibt Hinweise, dass der Start von signal-cli nach einem Reboot manchmal länger dauert als systemd zu Warten gewillt ist.
Jörg
Leider nein, hab ich probiert.
Ich hab etwas gegooglet.
https://qastack.com.de/server/695849/services-remain-in-failed-state-after-stopped-with-systemctl
l
ZitatSie sollten dies unterdrücken können, indem Sie den Beendigungscode als Beendigungsstatus "Erfolgreich" in die Unit-Datei einfügen:
[Service]
SuccessExitStatus=143
Wo soll die die Unit Datei sein? oder ich das die falsche Spur?
edit: Versuch macht Klug.
Ich hab das File gefunden.
der dienst läßt sich nun wieder manuell starten über:
sudo ./signal_install.sh start
Einen erfolgreichen Start vorzugaukeln, wenn das gar nicht stimmt, ist IMHO der falsche Ansatz.
Nur nochmal zur Sicherheit:
An selbiger Stelle TimeoutSec=200 anzufügen bringt nichts?
Wenn du nach dem reboot syslog nach signal-cli greps, findest du da was?
ich weiß nicht warum aber (erst) die Änderung in der Config bracht das gewünschte Verhalten.
auch nach dem Reboot läuft der Dienst nun im Auto Start. bzw. startet tatsächlich.
Den Time-out Eintrag hatte ich schon drin und er ist immer noch drin.
im syslog stehen keine Fehler oder Warnungen.
Dafür alle Dialoge die man/ich auch auf dem Handy getätigt hart.
Hallo zusammen,
Ich möchte für den SignalBot einen Autoresponder schreiben, da ich für Fhem unsere Festnetznummer verwende und verhindern möchte, dass Freunde aus Versehen an das FHEM System eine Nachricht schreiben und ich die nicht lese...
Über ein Notify reagieren ist kein Problem, aber ich bekomme die Zieladressen nicht zusammengebaut.
Ich teigiger auf msgText und die Absenderadresse teht ja in msgSender.
Wenn nun der Name in msgSender ein Leerzeichen enthält wird es schwierig...
Ich hatte erwartet, dass es mit $EVTPART1." ,,.$EVTPART2 geht, aber das wird nicht ersetzt...
Hat jemand eine. top für mich?
Vielen Dank und Grüße Michael
Ich nehme da lieber DOIF - da ist man einfach flexibler.
Aber eventuell hilft dir auch die aktuelle Testversion auf Github (siehe ein paar Posts vorher) zu nehmen.
Die führt das neue Feature "reply" ein. Damit wird die Nachricht automatisch an den letzten Absender geschickt. Dann fällt der Teil deines Problems schon mal weg :)
Werde die Version dann wohl heute oder morgen auch über Update freigeben.
Jetzt ist mir gerade nochmal ein Umlaute-Fehler aufgefallen:
Nach der Umstellung auf die "inline-Perl Syntax" bei den Favoriten kommen dort die Umlaute, die mein Perlcode als Ergebnis liefert auch nicht korrekt in Signal an.
Getestet mit der Version, die du vor 10 Minuten auf Github gestellt hast (ich werde schneller) ;)
Ändere mal Zeile
691: Signalbot_sendMessage($hash,$sender,"",$error); -> Signalbot_sendMessage($hash,$sender,"",decode_utf8($error));
Bin gerade ausnahmsweise nicht im Homeoffice und komme an meine Entwicklungsumgebung nicht dran :)
Funktioniert!
Danke dir vielmals!
Jetzt auch im SVN und morgen als update - Version 3.4:
- Neues Kommando "set reply" - schickt Nachricht an letzten Absender
- Einige Verbesserung an den Favoriten (perl modus. "print" Kommando, Sonderzeichen)
- Bessere Nutzerführung für "set link"
- Installer: backup/restore Funktion
Vorbereitungen für signal-cli 0.10.1+:
- Neues Kommando "set deleteContact"
- Installer: "experimental" Option zur Installation von signal-cli 0.10.1 und Java 17
Wird aktuell nur für Raspberry "bullseye" unterstützt, sollte aber auch auf aktuellen x86 Debian/Ubuntu Systemen gehen (trotz Meldung "not supported")
Sofern kein Java17 vorhanden ist, wird die Binary Distribution von adoptium.net geladen und nach /opt/java installiert.
Jörg
Hallo Jörg,
ich hab Java 17 erfolgreich auf Debian Bullseye installiert:
pi@HPT610:~$ java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-Debian-1deb11u2)
OpenJDK 64-Bit Server VM (build 17.0.1+12-Debian-1deb11u2, mixed mode, sharing)
Was mache ich mit der Java 11-Installation, bzw. wie kann ich sie entfernen?
pi@HPT610:~$ sudo update-java-alternatives --list
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.17.0-openjdk-amd64 1711 /usr/lib/jvm/java-1.17.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
Java 8 brauche ich zwingend für den UniFi-Controller, der auf gleichen Installation läuft; d.h. Java 8 muss erhalten bleiben.
Viele Grüße Gisbert
Java17 ist nur für die experimentelle signal-cli 0.10.1 Nutzung. Dafür gibt es keinen Support.
Für den normalen Produktiven Support bleibt signal-cli 0.9.2 mit Java 11 weiter der Standard.
Ich baue zwar schon 0.10+ Features ein, die sind aber dann einfach deaktiviert. Es wird sicher noch eine Weile dauern bis der Java 17 OS support breiter wird (insbesondere auf Raspberry) und die 0.10+ so interessant oder sogar notwendig wird.
Hallo Jörg,
vielen Dank für die Klarstellung.
Da dein Modul anscheinend mit Java 17 funktioniert, kann ich dann bei dieser Version bleiben? Wenn ja, soll ich Java 11 dann deinstallieren, und wie geht das dann?
Viele Grüße Gisbert
Ich hab signal-cli 0.9.2 nie mit Java17 probiert, aber wenn es geht....
Entfernen sollte wohl sowas wie
apt remove openjdk-11-jdk
oder
apt remove openjdk-11-jre
sein.
Im Prinzip mal ein
apt list | grep openjdk | grep -i install
und alles mit 11 runterwerfen.
Wenn aber dann was nicht geht, ist mein einziger Rat schon jetzt: Java11 installieren :)
Hallo zusammen,
Vielen Dank für das neue Feature ,,send response"!!
Ich habe es leider zu spät gesehen und es über ein Notify gelöst.
Falls das mal jemand braucht....
define Signal_Autoresponder notify SignalBot_:msgSender:.* set SignalBot send '@[SignalBot:prevMsgSender]' 'Hallo [SignalBot:prevMsgSender], Du hast eine Nachricht an unsere Festnetznummer geschrieben. Die lesen wir nicht, da dies die Haussteuerung ist. Bitte schreib an unsere Handynummern. Vielen Dank.'
Viele Grüße Michael
Preview V3.5 auf GitHub:
https://github.com/bublath/FHEM-Signalbot/blob/main/50_Signalbot.pm
-Vereinfachung des Versendens von SVG Plots
-Versenden von DOIF Widgets
Man kann in dieser Version statt eines Dateinamens oder der Perl Funktion für SVG (was ja durchaus Probleme bereiten kann bis man raus hat, wie man escapen muss) einfach den FHEM Device Namen angeben, also
send @Joerg &SVG_Aussentemperatur
Sofern der "Dateiname" eines Attachments dem Namen eines FHEM Devices mit Typ SVG entspricht wird die plotAsPng Funktion gleich intern von SignalBot aufgerufen.
SVG nimmt mit Komma getrennt noch optional einen "zoom" und "offset" welches sich aber auf die Datenselektion und nicht auf die Größe bezieht (die muss im Device definiert werden).
Zoom= "hour","qday","day","week","month","year","10years","20years"
Offset beschreibt wie oft mit den Pfeiltasten geblättert wird (positiv vorwärts, negativ zurück).
Wenn man also einen Plot vom vorherigen Tag möchte, wäre das
send @Joerg &SVG_Aussentemperatur,day,-1
Das DOIF Device kann ja mit uiTable inzwischen ganz nette Widgets darstellen. Die finde ich teilweise schicker als SVGs - z.B. der aktuelle Benzinpreis mit kurzer Historie ist praktisch (siehe Beispiel im Anhang) - und um so praktischer wenn man einfach per Signal eine Nachricht nach Hause schreibt. Nur kommt man schwer an die Bilder dran.
Dazu habe ich jetzt einen Hack geschrieben (vielleicht stellt Damian ja auch mal eine echte API zur Verfügung) - d.h. natürlich auch das die Gefahr besteht, dass es für zukünfte DOIF Versionen angepasst werden muss. Als erstes kommt wieder der Devicenamen der vom Typ DOIF sein muss. Das uiTable Attribut muss natürlich in diesem DOIF ebenfalls existieren.
Syntax:
send @Joerg &DI_Benzin #Erstes Widget in DOIF Attribut uiTable
send @Joerg &DI_Benzin,3 #Drittes Widget
send @Joerg &DI_Benzin,id=3 #Drittes Widget
send @Joerg &DI_Benzin,dev=Tankstelle #Erstes Widget, welches Werte aus dem Device "Tankstelle" abfragt
send @Joerg &DI_Benzin,dev=Tankstelle,val=Benzin #Erstes Widget, welches Werte aus dem Device "Tankstelle" mit Reading "Benzin" abfragt
send @Joerg &DI_Benzin,id=3,zoom=0.5,sizex=600,sizey=300 #Änderung der Größe und Zoom
Im Attribut "uiTable" von DOIF kann man ja lange Listen von Widgets hinterlegen. Wenn es wenige sind, dann ist durchzählen meist einfacher, doch mit der Gefahr, dass der Index bei Änderungen ändert. Daher kann man auch mit Device und/oder Reading das richtige Widget identifizieren (bei mehreren Darstellungen des selben Readings ist es dann aber immer das Erste).
Mit zoom und size kann potentiell die Darstellung in Signal verbessert werden (der Preview schneidet vielfach etwas ab). Wenn zoom alleine verwendet wird, dann ist das Resultat leider entweder abgeschnitten oder kleiner als das Bild, da ich keinen einfachen Weg gefunden habe, die Größe analog zum Zoomfaktor anzupassen. Meist nicht notwendig
Wer mehrere Plots/Widgets in einer Nachricht verschicken möchte, verwendet wie bei normalen Anhängen einfach mehrfach die "&" Option.
Edit: Bei Verwendung innerhalb eines DOIF muss das "&DI_Benzin,3" in Anführungszeichen gesetzt werden, da DOIF das Komma als Trenner zwischen mehreren Kommandos verwendet. Sollte ich doch einen anderen Trenner für die Parameter verwenden?
Moin Jörg,
habe mir V3.5 installiert. Das Thema mit den DOIF Widgets klang interessant. Habe leider übersehen, dass ich das nicht in "uiTable" habe, sondern als "uiState" Bsp:{package ui_Table;
$TABLE='text-align:center';
}
#card([Helios_KWL:v00102:col24],"Lüftung","vent_ventilation",0,4,120,0,"Stufe",undef,"0","100,1,1,1,1,1,160","1,1,1,20","50,50,50,40,50,40")
card ([Helios_KWL:v00102:col24],undef,"vent_ventilation",0,4,120,0,"Stufe",90,0,"90,1,1,1,0","1,1,1,20","50,50,50,40,50,40")
So kann ich das in Floorplan anzeigen. Deine Funktion in Signalbot klappt damit aber leider nicht....
Gruss
Enno
Hallo Enno,
da kommen jetzt zwei Dinge zusammen:
1. Du hast einen Fehler in der Definition - Kommentare müssen mit zwei ## gemacht werden - so wie es ist dürftest du sogar Fehler im Logfile finden (von DOIF selbst)
2. Ich hatte zwar einen "Fallback" auf uiState vorgesehen (wenn es kein uiTable gibt), aber nie getestet - ging natürlich nicht.
Für Punkt zwei habe ich den Fallback in GitHub jetzt repariert und außerdem den Parameter "state" eingebaut der die Verwendung von uiState statt uiTable erzwingt.
Jörg
Moin Jörg,
den Kommentar im DOIF habe ich gelöscht. Hatte keine Fehlermeldung deshalb und hat eigentlich immer angezeigt ist aber überflüssig, hatte ich nur vergessen zu löschen. Deine neue Version habe ich eingebaut. Jetzt klappt es. Super! Danke!
Gruss
Enno
Version 3.5 eingecheckt und im Wiki dokumentiert.
Installer mit "experimental" Option auf signal-cli 0.10.2 geupdated. Sollte jetzt auch eigentlich für alle üblichen Systeme funktionieren.
Wegen der Spezial Java17 Installation bleibt aber 0.9.2 die offizielle Version. Die Version 0.9.0 wird jetzt nicht mehr unterstützt.
Gibt es irgendwo Tipps, wie man Text mit Hervorhebungen/Kursiv/Code etc versendet? Telegram hatte so eine API, da konnte man den HTML-Mode auswählen. Hier habe ich nichts dergleichen gefunden, auch nicht in der Beschreibung des Devices.
Siehe Wiki:
Tipp zu den Formatierungen: Auf z.B. https://yaytext.com/ kann man sich seine UTF8 Kodierungen erstellen und nach FHEM per copy&paste einfügen. Vorrausetzung dürfte sein, dass die "locale" des Systems auf UTF8 eingestellt ist
Das hatte ich gelesen - aber das gilt ja nur für statischen Text, der während der Programmierung bereits feststeht. Wenn ich zB Logeinträge senden will, wie kann ich die etwa im Codestil formatieren, wenn sie ursprünglich nicht in diesem Stil vorliegen?
Hast du ein Beispiel wie du das bei Telegram machst? Hab jetzt auf die schnelle im Wiki nichts dazu gefunden.
signal-cli hat keinen html mode den ich hier nutzen könnte, das müsste man mit Utf-8 simulieren.
Ich habe eine Variable $nachricht erzeugt, in der die zehn letzten Logeinträge stehen und sende dann
fhem("set TelegramBot silentmsg <code>".$nachricht."</code> ")
Die werden dann in Codeformatierung dargestellt.
Dies scheint ein Telegram spezifisches Feature zu sein - habe jetzt im Code von TelegramBot nichts gefunden, dass darauf schliessen lässt, das es bereits dort umgewandelt wird.
Für Signal gab es wohl mal Diskussionen Markdown wie *bold* oder 'code' zu unterstützen, das ist aber wohl (noch) nicht implementiert. Auch von signal-cli ist mir keine Unterstützung bekannt, habe aber mal im Projekt nachgefragt.
Ich habe jetzt auf Anhieb auch keine Perl library gefunden die html->unicode oder markdown->unicode konvertiert. Wenn da jemand Ideen hat, kann ich mir das gerne anschauen.
Das selber "from scratch" zu implementieren, wäre zu viel Aufwand und mir fehlt da auch das Detailwissen.
D.h. aktuell sehe ich keinen Weg das zu unterstützen.
Ich wusste nicht, dass das seit sechs Jahren (!) diskutiert wird:
https://community.signalusers.org/t/font-styling-for-signal-messages-e-g-using-markdown/612 (https://community.signalusers.org/t/font-styling-for-signal-messages-e-g-using-markdown/612)
Sieht nach einem echten Problem aus.
<edit> Also wenn man das in Perl hinbekommt, dann sendet Signal den Text im richtigen Format, siehe Bild.
Es gibt irgendein Problem beim Senden der uiDOIF-Bilder,
(process:19447): librsvg-WARNING **: 12:44:12.220: RsvgHandle could not read or parse the SVG; did you check for errors
during the loading stage?
(process:19447): GdkPixbuf-CRITICAL **: 12:44:12.220: gdk_pixbuf_save_to_callbackv: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
Bei mir stürzt FHEM sofort ab, startet neu und dabei erscheinen beim Starten keine Fehlermeldungen. Das Bild, das ich senden will, kann ich aber sehen:
Internals:
DEF ##
FUUID 61f572ec-f33f-1115-d518-121fa3a93e31674a
FVERSION 98_DOIF.pm:0.253860/2021-12-28
MODEL FHEM
NAME uiDOIF
NOTIFYDEV BresserTemeo_1,global,Viessmann2,Wasserzaehler_IEC_01
NR 477
NTFY_ORDER 50-uiDOIF
STATE initialized
TYPE DOIF
VERSION 25386 2021-12-28 22:19:25
READINGS:
2022-01-30 12:41:54 cmd 0
2022-01-30 12:41:54 mode enabled
2022-01-30 12:41:54 state initialized
Regex:
accu:
collect:
BresserTemeo_1:
collect:
temperature_at ^BresserTemeo_1$:^temperature_at:
Viessmann2:
collect:
Durchschnitt_WW ^Viessmann2$:^Durchschnitt_WW:
Wasserzaehler_IEC_01:
collect:
Verbrauch ^Wasserzaehler_IEC_01$:^Verbrauch:
uiTable:
BresserTemeo_1:
uiDOIF_uiTable_c_0_0_0_0:
temperature_at ^BresserTemeo_1$:^temperature_at:
Viessmann2:
uiDOIF_uiTable_c_1_0_0_0:
Durchschnitt_WW ^Viessmann2$:^Durchschnitt_WW:
Wasserzaehler_IEC_01:
uiDOIF_uiTable_c_2_0_0_0:
Verbrauch ^Wasserzaehler_IEC_01$:^Verbrauch:
collect:
BresserTemeo_1 temperature_at:
24:
dim 72
hours 24
last_v 5.0
max_value 6.5
max_value_slot 25
max_value_time 1643488296
min_value 5.0
min_value_slot 71
min_value_time 1643543217
name BresserTemeo_1
reading temperature_at
time 1643543217
value 5.0
times:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643488296
1643488932
undef
1643491904
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643519429
undef
undef
undef
undef
undef
undef
1643527488
undef
1643529982
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643542658
1643543217
values:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
6.5
6.3
undef
5.0
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
5.0
undef
undef
undef
undef
undef
undef
5.0
undef
5.0
undef
undef
undef
undef
undef
undef
undef
undef
undef
5.0
5.0
Viessmann2 Durchschnitt_WW:
12:
dim 72
hours 12
last_v 56.1
max_value 56.75
max_value_slot 58
max_value_time 1643535433
min_value 30.85
min_value_slot 66
min_value_time 1643540177
name Viessmann2
reading Durchschnitt_WW
time 1643543297
value 55.85
times:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643519477
1643520017
1643520617
1643521397
1643521852
1643522597
1643523557
1643523677
1643524757
1643525357
1643525957
1643526257
1643526797
1643527298
1643528237
1643528777
1643529377
1643529982
1643530637
1643531297
1643531837
1643532437
1643533157
1643533614
1643534297
1643534897
1643535433
1643536157
1643536697
1643537357
1643537957
1643538377
1643538617
1643539665
1643540177
1643540875
1643541437
undef
1643542694
1643543297
values:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
34.35
31.95
31.95
32.05
32
31.9
32.05
31.95
34
44.45
52.05
55
54.05
53.45
52.75
47.1
54.45
55.4
54.4
53.7
53.05
52.35
51.2
50.8
41.3
54.4
56.75
56.3
54.95
44.9
31.15
30.9
31.15
31.25
30.85
39.6
40.15
undef
56.1
55.85
Wasserzaehler_IEC_01 Verbrauch:
24:
dim 72
hours 24
last_v 0
max_value 29
max_value_slot 63
max_value_time 1643534151
min_value 0
min_value_slot 70
min_value_time 1643542658
name Wasserzaehler_IEC_01
reading Verbrauch
time 1643543316
value 1
times:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643488497
1643489844
1643490114
1643491904
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1643519479
1643520054
1643521279
1643522476
1643524208
1643524967
1643526426
1643528381
1643528663
1643530102
1643530856
1643532817
1643534151
1643534592
1643536187
1643537379
1643538417
1643540352
1643541356
1643542658
1643543316
values:
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
0
7
0
0
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
undef
1
0
0
0
1.0099999999984
0
0.990000000001601
15
0
1
0
12
29
0
6
27.0099999999984
0
4
25
0
1
helper:
DEVFILTER ^global$|^Viessmann2$|^BresserTemeo_1$|^Wasserzaehler_IEC_01$
NOTIFYDEV global|Viessmann2|BresserTemeo_1|Wasserzaehler_IEC_01
globalinit 1
last_timer 0
sleeptimer -1
perlblock:
uiTable:
dev Wasserzaehler_IEC_01
header
package package ui_Table;
reading Verbrauch
table:
0:
0:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'uiDOIF_uiTable_c_0_0_0_0',card(::ReadingValDoIf($hash,'BresserTemeo_1','temperature_at','','col24'),"Außen",undef,-10,45,undef,undef,"°C",\&temp_hue,"1","130,,,,,1,200"),"")
1:
0:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'uiDOIF_uiTable_c_1_0_0_0',card(::ReadingValDoIf($hash,'Viessmann2','Durchschnitt_WW','','col12'),"Warmwasser",undef,20,65,undef,undef,"°C",\&warmwasser_hue,"1","130,,,,,1,200"),"")
2:
0:
0:
0 package ui_Table;::DOIF_Widget($hash,$reg,'uiDOIF_uiTable_c_2_0_0_0',card(::ReadingValDoIf($hash,'Wasserzaehler_IEC_01','Verbrauch','','col24'),"Wasser,fill:darkblue",undef,0,undef,240,240,"l",undef,"1","130,,1,,,1,200"),"")
Attributes:
uiTable {package ui_Table;
sub warmwasser_hue {
my($farbe)=@_;
return ($farbe > 39 ? 0 : 240);
}
}
card([BresserTemeo_1:temperature_at:col24],"Außen",undef,-10,45,undef,undef,"°C",\&temp_hue,"1","130,,,,,1,200")
card([Viessmann2:Durchschnitt_WW:col12],"Warmwasser",undef,20,65,undef,undef,"°C",\&warmwasser_hue,"1","130,,,,,1,200")
card([Wasserzaehler_IEC_01:Verbrauch:col24],"Wasser,fill:darkblue",undef,0,undef,240,240,"l",undef,"1","130,,1,,,1,200")
Sieht jemand, was ich falsch mache?
Es scheint an den leeren Komma Feldern im letzten Parameter zu liegen:
card([Viessmann2:Durchschnitt_WW:col12],"Warmwasser",undef,20,65,undef,undef,"°C",\&warmwasser_hue,"1","130,,,,,1,200")
Wenn ich da immer eine 0 reinschreibe, dann geht es.
Ich kann dir nicht sagen warum. Das SVG schaut in beiden Fällen OK aus und wird ja angezeigt. Allerdings ist die Library zum Umwandeln schon ewig alt - vielleicht verträgt die etwas nicht, das offziell erlaubt ist.
Der FHEM Neustart ist natürlich auch nicht schön. Da fehlt noch ein Fehlercheck, das baue ich noch ein.
Hmm, hat bei mir nicht gereicht. Ich habe jetzt
card([BresserTemeo_1:temperature_at:col24],"Außen",undef,-10,45,undef,undef,"°C",\&temp_hue,"1","130,0,0,0,0,1,200")
card([Viessmann2:Durchschnitt_WW:col12],"Warmwasser",undef,20,65,undef,undef,"°C",\&warmwasser_hue,"1","130,0,0,0,0,1,200")
card([Wasserzaehler_IEC_01:Verbrauch:col24],"Wasser,fill:darkblue",undef,0,undef,240,240,"l",undef,"1","130,0,1,0,0,1,200")
und dennoch einen Absturz.
Ja, hab auch noch weiter probiert und irgendwie immer noch Probleme mit deinen Beispielen.
Irgendwie scheint es trotzdem an dem letzten Parameter zu liegen. Wenn ich den weglasse, dann geht es.
card([BresserTemeo_1:temperature_at:col24],"Außen",undef,-10,45,undef,undef,"°C",\&temp_hue,"1")
Für weitere Experimente nimmt bitte die Version von GitHub
https://github.com/bublath/FHEM-Signalbot/blob/main/50_Signalbot.pm
Da sollte es zumindest keinen FHEM Restart mehr geben, sondern eine Fehlermeldung
In der Tat
Error: Converting SVG to PNG for package ui_Table;card(::ReadingValDoIf($hash,'BresserTemeo_1','temperature_at','','col24'),"Außen",undef,-10,45,undef,undef,"°C",\&temp_hue,"1","130,0,0,0,0,1,200");
Da versuche ich mal weiter zu spielen.
Ich glaubt ich habs: Es ist der Halbring
# <hring>: 1 für Halbringdarstellung,
Ich kann nur vermuten das dafür SVG Befehle verwendet werden, die die alte Library nicht verdaut.
Bingo. Das war es.
Zitat von: andies am 30 Januar 2022, 11:04:09
<edit> Also wenn man das in Perl hinbekommt, dann sendet Signal den Text im richtigen Format, siehe Bild.
Ich habe ein wenig gespielt. An sich ist das einfach, wenn man den tr-Befehl nimmt. In die erste Klammer den Logfile im Original, in der zweiten Klammer dieselben Buchstaben im Monospace,
$nachricht =~ tr/abcdefghijklmnopqrstuvwyz 01456789= -:ABCDEFGHIKLMPQRSTUVW/𝚊𝚋𝚌𝚍𝚎𝚏𝚐𝚑𝚒𝚓𝚔𝚕𝚖𝚗𝚘𝚙𝚚𝚛𝚜𝚝𝚞𝚟𝚠𝚢𝚣 0𝟷𝟺𝟻𝟼𝟽𝟾𝟿= -:𝙰𝙱𝙲𝙳𝙴𝙵𝙶𝙷𝙸𝙺𝙻𝙼𝙿𝚀𝚁𝚂𝚃𝚄𝚅𝚆/;
fhem("set SignalBot send \@Andreas ".$nachricht."");
Blöderweise klappt das nicht vollumfänglich :P
Ich glaube das gibt ein Problem damit, dass der erste Teil deines tr normale characters (8-Bit) sind und der zweite Teil Unicode (16-bit).
Das verdaut er nicht richtig und macht Unsinn. Sieht man auch an der Fehlermeldung:
PERL WARNING: Replacement list is longer than search list
So scheint er das besser auf die Reihe zu kriegen:
$nachricht =~ tr/a-zA-Z0-9/\x{1D68A}-\x{1D6A3}\x{1D670}-\x{1D689}\x{1D7F6}-\x{1D7FF}/;
Jörg
Edit: Mit Zahlen
Hm, bei mir erscheint das nicht. Wenn ich das ausgebe, sehe ich den Fonts im Web (siehe Screenshot), aber er kommt bei mir in Signal nicht an.
<edit> Das scheinen die Zeilenvorschübe in $nachricht zu sein. Wenn ich nur die erste Zeile herausnehme, klappt es. Die müssen also anscheinend maskiert werden? Komisch, beim normalen Fonts war das nicht nötig. Wie ersetze ich die denn?</edit>
Merkwürdig. Wenn ich den Text ohne Fontsänderung voranstelle, geht es durch, siehe Screenshot. Das ist ja wie bei irgendwelchen Ausgrabungen, man probiert und schaut und mal findet man was.
<edit> Einfach eine \n an den Anfang und es geht durch. Danke!!</edit>
Thema Schriftarten nochmal - hab da mal folgendes gebaut. Kann zum Testen nach myUtils, dann einfach mit toUnicode("bold","Dies ist ein Test") aufrufen. Ansatz war das möglichst generisch zu lösen und im Source Code selbst nur ASCII zu verwenden.
Überlege das in Signalbot einzubauen, die Frage ist nur mit welcher Syntax.
Eher html Tags wie <b>bold</b> <code>monospace</code> ....
oder so Markdowns wie _bold_ 'code'
oder einfach nur als API um es in eigenen Scripten/DOIF aufzurufen
my $nachricht = toUnicode("italic","Dies ist ein Test 123");
fhem("set SignalBot reply $nachricht ok?");
#Converts normal ASCII into unicode with a special font or style
sub toUnicode {
my ($font,$str) = @_;
if ($font eq "underline") {
$str =~ s/./$&\x{332}/g;
return $str;
}
if ($font eq "strikethrough") {
$str =~ s/./$&\x{336}/g;
return $str;
}
my %uc = (
"bold" => [0x1d41a,0x1d400,0x1d7ce],
"italic" => [0x1d44e,0x1d434,0x30],
"bold-italic" => [0x1d482,0x1d468,0x30],
"script" => [0x1d4b6,0x1d49c,0x30],
"fraktur" => [0x1d51e,0x1d504,0x30],
"square" => [0x1f130,0x1f130,0x30],
"mono" => [0x1d68a,0x1d670,0x30],
);
#Special handling for characters missing in some fonts
my %sp = (
0x1d455 => 0x1d629, #italic h -> italic sans-serif h
0x1d4ba => 0x1d452, #script e -> serif e
);
return undef if (! defined $uc{$font});
my $rep=chr($uc{$font}[0])."-".chr($uc{$font}[0]+25).chr($uc{$font}[1])."-".chr($uc{$font}[1]+25).chr($uc{$font}[2])."-".chr($uc{$font}[2]+9);
$_=$str;
eval "tr/a-zA-Z0-9/$rep/";
return undef if $@;
my $rep2="";
$rep="";
foreach my $val (keys %sp) {
$rep.=chr($val);
$rep2.=chr($sp{$val});
}
eval "tr/$rep/$rep2/";
return undef if $@;
print $_."\n";
return $_;
}
Solange sich die Leute von Signal selbst nicht einig sind, würde ich kein Markup o.Ä. verwenden, das muss dann am Ende wieder aufwendig rückgängig gemacht werden. Allerdings bin ich auch kein Profi und weiß nicht wie solche Sachen üblicherweise laufen.
Wenn Signal das nativ einführen sollte, dann widerspricht sich das erstmal nicht.
Ich würde ja den Text vorher parsen und in Unicode umwandeln und so schicken - ist das selbe wie copy&paste - das funktioniert auch noch wenn Signal das einführt.
Komisch wird es nur wenn Signal was anderes einführt und sich das widerspricht, dann wären neue Nutzer verwirrt warum manches anders aussieht.
Und wenn man es wieder entfernt (das ist an sich kein Problem) dann sind alte Nutzer verwirrt, weil die Sachen plötzlich anders rauskommen.
Ist wahrscheinlich ein Grund warum da seit 6 Jahren diskutiert wird - es gibt keinen Standard und je nachdem von welchem anderen Programm man kommt, ist man andere Dinge gewohnt.
Zum Beispiel GitHub: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
Und Whatsapp: https://faq.whatsapp.com/general/chats/how-to-format-your-messages/?lang=de
Wogegen Telegram eher auf html style geht: https://core.telegram.org/api/entities
So, ich mache jetzt einfach mal einen Vorschlag - Testversion dazu https://github.com/bublath/FHEM-Signalbot
Ich hab das jetzt mal optional gemacht. Es gibt ein Attribut "formatting" mit folgenden Optionen:
none - keine Ersetzungen
html - Nur Ersetzungen mit html-artigen tags (<b>text</b>)
markdown - Nur Ersetzungen mit markdown-artigen tags (_text_)
both - Beide Ersetzungen aktiv
Achtung: Markdown braucht vor und nachdem Wort ein Leerzeichen um versehentliche Ersetzungen zu verhindern (also "dies ist _underlined_ !" - dagegen "dies ist _underlined_!" geht nicht. Eine Variante wäre das mit doppelten Zeichen zu machen __underline__ **bold** dann ist das Risiko einer Fehlersetzung geringer
Syntax/Beispiele:
U̲n̲t̲e̲r̲s̲t̲r̲i̲c̲h̲e̲n̲e̲r̲ ̲T̲e̲x̲t̲ ̲1̲2̲3̲ - <u>text</u> / _text_
D̶u̶r̶c̶h̶g̶e̶s̶t̶r̶i̶c̶h̶e̶n̶e̶r̶ ̶T̶e̶x̶t̶ ̶1̶2̶3̶ - <s>text</s> / ~text~
𝐅𝐞𝐭𝐭𝐞𝐫 𝐓𝐞𝐱𝐭 𝟏𝟐𝟑 - <b>text</b> / *bold*
𝐾𝑢𝑟𝑠𝑖𝑣𝑒𝑟 𝑇𝑒𝑥𝑡 𝘩 123 - <i>text</i>
𝑭𝒆𝒕𝒕𝒆𝒓 𝒌𝒖𝒓𝒔𝒊𝒗𝒆𝒓 𝑻𝒆𝒙𝒕 123 - <bi>text</bi>
𝓢𝓬𝓻𝓲𝓹𝓽 𝓣𝓮𝔁𝓽 123 - <script>text</script>
𝕱𝖗𝖆𝖐𝖙𝖚𝖗 𝕿𝖊𝖝𝖙 123 - <fraktur>text</fraktur>
🅂🅀🅄🄰🅁🄴 🅃🄴🅇🅃 123 - <square>text</square>
𝙼𝚘𝚗𝚘𝚜𝚙𝚊𝚌𝚎 𝚃𝚎𝚡𝚝 123 - <code>text</code> / ``text``
Zitat von: Adimarantis am 01 Februar 2022, 18:37:03
html - Nur Ersetzungen mit html-artigen tags (<b>text</b>)
ich teste mal mit dieser Einstellung....
Moin,
wenn ich eine Nachricht mit dem Zeilenumbruch \n schicken möchte, geht es nicht. Ohne \n klappt es. Einen Zeilenumbruch <br> mag er auch nicht....
Gruss
Enno
Setze mal einen einfachen Text vor den Zeilenumbruch oder gar als erstes einen Zeilenumbruch, dann ging es bei mir durch
Vorschlag zur Hilfe:
<li><b>formatting</b><br>
<a id="Signalbot-attr-formatting"></a>
The "formatting" attribute has the following four options that allow highlighting:
<ul>
<li>none - no replacements </li>
<li>html - replacements are enabled here with HTML-type tags (e.g. for bold <b> is bold </b>)</li>
<li>markdown - replacements are enabled by markdown-like tags (e.g. _for italic_)</li>
<li>both - both methods are possible here</li>
</ul>
It must be noted that markdowns require a space before and after the word to prevent accidental replacements (so possible is "this is _underlined_ !", but not "this is _underlined_!").
</li>
Das mit dem Zeilenumbruch:
Ist das in einem DOIF? Da muss man es nämlich escapen (\\n). Habt ihr ein spezfisches Beispiel was nicht geht? Ich kann das jetzt nicht nachvollziehen.
Das mit dem <br> als \n Alternative werde ich noch einbauen (für den html mode) - dann gibt es wegen escapen auch keine Probleme mehr
Hier das DOIF vereinfacht aber damit wird das Problem klar: defmod di_Test DOIF ([Testdummy:state] eq "on")(set SIGNAL send <i>Text Zweite Zeile</i>)
Ergebnis: Cursiv so wie es sein soll. Mit Zeilenumbruch: defmod di_Test DOIF ([Testdummy:state] eq "on")(set SIGNAL send <i>Text \nZweite Zeile</i>) oder auch mit \\n klappt nicht.
Gruss
Enno
Jetzt hab ichs verstanden...
Fix auf github und auch <br> sollte jetzt gehen
Markdown hab ich jetzt auf doppelte Zeichen (__ ~~ **) geändert - das mit dem Pflichtleerzeichen fand ich nicht gut
Jörg
Moin Jörg,
set SIGNAL send <i>Text <br>Zweite Zeile</i>
Klappt! Super, gefallen mir sehr gut die neuen Möglichkeiten.
Gruss
Enno
Als nächstes brauchen wir noch Ersetzungen für Emojis :)
Ich würde ja gerne bei Bedarf den Inhalt eines Textfile schicken :) Also nicht als Anhang, sondern direkt als Text lesbar 8)
set SIGNAL send §/opt/fhem/log/fhem.log
Zur Zeit importiere ich mir das als Reading in ein Dummy und schicke dann die Reading in einem DOIF.
Gruss
Enno
Ich lasse mir immer die letzten 20 Zeilen der letzten beiden Tage schicken
sub LogFileEintraegeSenden(){
# Datum holen
my $datum = POSIX::strftime("%Y-%m",localtime(time));
my $today_log = POSIX::strftime("%Y.%m.%d",localtime(time));
my $yesterday_log = POSIX::strftime("%Y.%m.%d",localtime(time-24*60*60));
my $nachricht = "";
my ($err, @nachrichtenliste) = FileRead({FileName => "/opt/fhem/log/fhem-$datum.log", ForceType => "file"});
if ($err) {
$nachricht = "Fehler beim Lesen der Logdatei /opt/fhem/log/fhem-$datum.log: $err";
} else {
# Eintraege mit anderem Datum entfernen
my @datatosend;
if (@nachrichtenliste > 19) {
@datatosend = @nachrichtenliste[-20..-1];
} else {
@datatosend = @nachrichtenliste;
}
foreach my $nachrichtenzeile(@datatosend){
$nachrichtenzeile =~ s/[;&><]//g; ##Semikolon entfernen, siehe https://core.telegram.org/bots/api#markdown-style
#Log3(undef, 0, "substr= ".substr($nachrichtenzeile, 0, 10))."#";
#Log3(undef, 0, "today= ".$today_log)."#";
if ((substr($nachrichtenzeile, 0, 10) eq $today_log) or (substr($nachrichtenzeile, 0, 10) eq $yesterday_log)){
$nachricht .= substr($nachrichtenzeile, 11)."\n";
}
}
}
fhem("set SignalBot send \@Andreas &uiDOIF,1 &uiDOIF,2 &uiDOIF,3") ;
$nachricht =~ tr/a-zA-Z0-9/\x{1D68A}-\x{1D6A3}\x{1D670}-\x{1D689}\x{1D7F6}-\x{1D7FF}/;
fhem("set SignalBot send \@Andreas Logfile\n".$nachricht);
}
Neue Testversion mit Emoticons auf GitHub inklusive einer "get" Funktion die die Syntax anzeigt.
Du kannst durchaus ein Textfile schicken.
Ungünstig ist nur die Endung ".log" - da ist zumindest auf meinem Handy keine App verknüpft die Textfiles anzeigen kann.
Mit ".txt" funktioniert es aber gut und dann öffnet er z.B. Chrome
Mit dem FHEM log gibt es da noch ein Problem - es ist wahrscheinlich zu lang - ich war da nur mit sehr kleinen Files erfolgreich.
Also z.B. ein
system("tail -1000 ~fhem/log/fhem-2022-02.log >/tmp/tmp.txt")
ausführen und dann /tmp/tmp.txt verschicken - dann kriegt du die letzen 1000 Zeilen vom FHEM log. Das funktioniert bei mir noch.
Ich habe den Vorschlag von Andies aufgegriffen und für mich verkürzt da ich mit den Umlauten keine Probleme hatte:
sub LogFileEintraegeSenden(){
my $nachricht = "";
my ($err, @nachrichtenliste) = FileRead({FileName => "/opt/fhem/log/fhem.log", ForceType => "file"});
if ($err) {
$nachricht = "Fehler beim Lesen der Logdatei /opt/fhem/log/fhem.log: $err";
} else {
my @datatosend;
@datatosend = @nachrichtenliste;
foreach my $nachrichtenzeile(@datatosend){
$nachrichtenzeile =~ s/[;&><]//g; ##Semikolon entfernen, siehe https://core.telegram.org/bots/api#markdown-style
$nachricht .= substr($nachrichtenzeile, 11)."<br>";
}
}
fhem("set SIGNAL send LOG<br><code>".$nachricht."</code>");
}
Dann im DOIF { LogFileEintraegeSenden() } aufrufen. Ist deutlich eleganter als meine alte Variante.
Damit klappt es, die Log sind bei mir im Normalfall aber auch nicht besonders lang.
Gruss
Enno
Emoticons funktioniert bei mir, wenn ich Attribut formatting both stehen habe. Bei HTML allein natürlich nicht :D
Gruss
Enno
Hallo liebe Leute,
erst einmal vielen Dank für dieses tolle Modul.
Dennoch habe ich dazu nun einmal eine Frage.
Folgendes sendet mir den Alias des auslösenden Devices auf Signal:
(set Signalbot send @SouzA {(AttrVal("$DEVICE","alias",""))})
Wenn ich aber
(set Signalbot send @SouzA Irgendeintext zum Beispiel {(AttrVal("$DEVICE","alias",""))} mit Gemüse)
Dann kommt nur
Irgendeintext zum Beispiel
in Signal an.
Wie kriege ich es hin, dass der ALIAS mit dem Text zu Signal gesendet wird?
Vielen Dank für eine kurze Rückmeldung.
Thx und bis denn
SouzA
Hast du dazu noch etwas mehr Kontext (das komplette Device oder zumindest genug, dass ich das bei mir nachbauen kann?)
Wo führst du das aus?
Das Problem dürfte sein, das $DEVICE zum Zeitpunkt der Auswertung nicht (mehr) gesetzt ist.
Zitat von: Adimarantis am 06 Februar 2022, 20:50:02
Hast du dazu noch etwas mehr Kontext (das komplette Device oder zumindest genug, dass ich das bei mir nachbauen kann?)
Wo führst du das aus?
Das Problem dürfte sein, das $DEVICE zum Zeitpunkt der Auswertung nicht (mehr) gesetzt ist.
Öhm... was soll ich sagen?
Habe es gerade noch mal getestet. Jetzt geht es auf einmal? Obwohl ich !!nix!! an den Netzwerken geändert habe! ????
Kein Plan, was jetzt anders ist als vorher....
Sorry, ich ziehe alles zurück und behaupte das Gegenteil.
Mit dem nicht gesetzten Device hat es nix zu tun... die waren definitiv gesetzt.
Das waren gesetzte SPS-Ausgänge... die gehen nicht einfach wieder weg.
Thx und bis denn
SouzA
Version 3.7 mit Formatierungen und Emoticons ist jetzt über Update verfügbar.
Bitte unbedingt "update all" und "shutdown restart" machen, da die Formatierungssfunktionen in lib/FHEM/Text/Unicode.pm ausgelagert wurden und diese nur so korrekt eingebunden werden.
Aktiviert wird die Funktion über das "formatting" Attribut. Details zur Syntax bekommt man mit "get uniCode".
Jörg
Das Modul hat ja wirklich Super-Fortschritte gemacht und mit dem Install-Script ist es nach meiner Erfahrung auch super-einfach geworden, es zu aktivieren.
In der Praxis stoße ich aber dann auf ein Verständnisproblem:
Dieses Doif (bei dem ich den Vergleichsoperaator jetzt zum Testen extra verdreht habe)
defmod DI_Tiefkuehl DOIF {if ([T_Tiefkuehltruhe:temperature] < -10) {fhem_set "Signal send \@XX Temperaturproblem Kuehltruhe: [T_Tiefkuehltruhe:temperature] Grad"}}
sendet diese Nachricht:
Temperaturproblem Kuehltruhe: ::ReadingValDoIf(HASH(0x6480108),T_Tiefkuehltruhe,temperature) Grad
es wird der Aufruf von Device:Reading nicht aufgelöst.
Was mache ich falsch. Verschiedene Maskierungen habe ich schon versucht, ohne Erfolg.
Signalbot ist auf der neuesten, per Repository erhältlichen Version.
Christian
Ersetzungen in DOIF sind tricky wenn man sie zu sehr verschachtelt.
Viele Wege führen nach Rom, z.B. indem du das Reading aus den Anführungszeichen rausholst:
defmod DI_Tiefkuehl DOIF {if ([T_Tiefkuehltruhe:temperature] < -10) {fhem_set "Signal send \@XX Temperaturproblem Kuehltruhe:".[T_Tiefkuehltruhe:temperature]." Grad"}}
oder es erst in eine Variable schreibst:
defmod DI_Tiefkuehl DOIF {if ([T_Tiefkuehltruhe:temperature] < -10) {my $var=[T_Tiefkuehltruhe:temperature]; fhem_set "Signal send \@XX Temperaturproblem Kuehltruhe: $var Grad"}}
Oh, wie einfach und letzendlich doch logisch.
Funzt!
Danke vielmals für die schnelle Hilfe
Christian
Zitat von: cwagner am 11 Februar 2022, 22:35:59
Oh, wie einfach und letzendlich doch logisch.
Funzt!
Danke vielmals für die schnelle Hilfe
Christian
Oder
(
[Temp_Kuehlfach:temperature] >= 8
or
[Temp_Gefrierfach:temperature] >= -10
)
(set Signalbot send @XX $DEVICE wird zu warm oder ist ausgefallen! [$DEVICE:temperature]°C )
DOELSE Bis denn
SouzA
Richtig, die ganze Bandbreite auch von $EVENTS oder $EVENT kann man benutzen, da kann man sehr schöne Überwachungen stricken und vor allem: die ganze Warn-DOIFs in eins zusammenfassen.
Diese Vereinfachung ohne Anführung scheint mir aber nicht im DOIF-Perlmodus zu funktionieren.
Vielen Dank für den weiteren Tipp
Christian
Zitat von: cwagner am 12 Februar 2022, 22:53:43
Richtig, die ganze Bandbreite auch von $EVENTS oder $EVENT kann man benutzen, da kann man sehr schöne Überwachungen stricken und vor allem: die ganze Warn-DOIFs in eins zusammenfassen.
Diese Vereinfachung ohne Anführung scheint mir aber nicht im DOIF-Perlmodus zu funktionieren.
Vielen Dank für den weiteren Tipp
Christian
Keine Ahnung, was du mit DOIF-Perlmodus meinst...
Bei mir verschickt fhem so Nachrichten.
Bis denn
SouzA
Deine Schreibweise ist das klassische DOIF "define Test DOIF (Bedingung/Ereignis) (Aktion(en))". Beim Betrieb wird dies in Perl übersetzt.
Der Perlmodus von DOIF ist eine Variante, bei der nach Definition der Code direkt in Perl übersetzt wird, was Geschwindigkeitsvorteile bringt: define Test_Perl DOIF {if (Bedingung/Ereignis) {Aktion(en)}}
Herzliche Grüße
Christian
Zitat von: cwagner am 13 Februar 2022, 14:52:20
Deine Schreibweise ist das klassische DOIF "define Test DOIF (Bedingung/Ereignis) (Aktion(en))". Beim Betrieb wird dies in Perl übersetzt.
Der Perlmodus von DOIF ist eine Variante, bei der nach Definition der Code direkt in Perl übersetzt wird, was Geschwindigkeitsvorteile bringt: define Test_Perl DOIF {if (Bedingung/Ereignis) {Aktion(en)}}
Herzliche Grüße
Christian
Um was für Geschwindigkeitsvorteile sprechen wir da? 0,1s 0,5s..?
Ich schreib meine Doifs immer so... Aus dem einfachen Grund, weil Perl gruselig ist... (für mich! 😁). Hätte es das DOIF in fhem so nicht gegeben, hätte ich mich mit was anderem beschäftigt.
Sorry, das müsste jetzt aber ein anderes Thema sein.
Aber danke für deine Erklärung. War mit so nicht bewußt, dass es das in Doif gibt, weil es dadurch schneller geht.
Bis denn
SouzA
Hallo Zusammen,
hier nur die Info das ich seit neustem eine Meldung von dem Modul beim Starten von FHEM im Log finde:
PERL WARNING: binmode() on unopened filehandle LOG at ./FHEM/50_Signalbot.pm line 939
Danke für den Hinweis. Stellt kein Problem dar. Da sich gerade ohnehin was mit dem Unicode Handling in FHEM tut, nehm ich die Zeile wahrscheinlich sowieso wieder raus.
Hallo Zusammen,
auf die Gefahr hin, mich komplett zum Deppen zu machen, jedoch aus Verzweiflung, möchte ich mich nun doch mit einer Frage an Euch wenden:
Ich habe den Signalbot prima zum Laufen bekommen und kann problemlos Nachrichten von FHEM versenden.
Ich möchte mit dem SignalBot gern die Telegram-Anbindung ersetzen. Was mir nun überhaupt nicht gelingt, ist FHEM-Befehle vom Handy an das FHEM zu senden.
Natürlich kommen die Nachrichten im FHEM an, sie stehen im Reading msgText. Allerdings ist das auch alles, was passiert, ein im Text enthaltener FHEM Befehl wird nicht ausgeführt.
Muss man dafür noch etwas spezielles einstellen ?
Ich hatte die Doku so verstanden, dass man ein "AllowedPeer" setzen sollte, weil sonst jeder Nachrichten an das FHEM senden kann, also habe ich das getan.
Ein GoogleAuth-Device habe ich nicht eingerichtet. Ich habe zwar gelesen, dass das geht, allerdings nicht erkennen können, das die Verwendung zwingend ist.
Hat da jemand eventuell einen kleinen Tipp, was ich übersehe ?
Eine eingehende Nachricht sieht im Event Monitor so aus:
2022-03-28 16:08:45 Signalbot SignalBot msgAttachment:
2022-03-28 16:08:45 Signalbot SignalBot msgTimestamp: 28-03-2022 16:08:45
2022-03-28 16:08:45 Signalbot SignalBot msgText: set EG_SD_Flur toggle
2022-03-28 16:08:45 Signalbot SignalBot msgSender: Markus
2022-03-28 16:08:45 Signalbot SignalBot msgGroupName:
2022-03-28 16:08:45 Signalbot SignalBot msgAuth: 0
Vielen Dank schon mal, viele Grüße
Markus
Zum einen brauchst du trotzdem immer ein cmdKeyword.
Da es allerdings sehr riskant ist, ohne Authentifizierung Kommandos auszuführen, gibt es dafür nur zwei Möglichkeiten:
1.) Du baust ein notify/DOIF welches auf das Event mit dem msgText wartet und dann entsprechend Befehle ausführt
2.) Du definierst Favoriten die mit "-" als "braucht keine Authentifzierung" markiert sind. Dies benötigt trotzdem eine authDevice - auch wenn du sie nicht verwendest.
Aus Sicherheitsgründen werden keine beliebigen Kommandos ohne Authentifizierung durchgereicht.
Jörg
Guten Morgen,
danke Jörg, nun habe ich es verstanden.
Und natürlich hast du Recht damit, dass es sehr riskant ist, einfach alles von jedem auszuführen.
Viele Grüße
Markus
Erst mal: Vielen Dank für das Modul. Bisher habe ich es nicht gebraucht, jetzt schon. Das Thema hier verfolge ich von Anfang an, bisher gab es aber keinen Grund den "Aufwand" in den Umstieg von SiSi zu stecken. Ich wollte auch schon mal schreiben, wieso hat jemand mit einer Hand voll Beiträgen im Forum schon ein eigenes Modul ;), aber dafür ist es jetzt auch viel zu spät.
Vor ein paar Tagen ist mir aufgefallen, dass ich über SiSi schon länger keine Nachrichten mehr versenden konnte (empfangen ging noch). Da war dann klar, da keine Zeit mehr rein zu stecken, sondern das neue Modul zu verwenden. Das lange Warten hat sich aber dadurch ausgezahlt, dass das Skript alles ohne Probleme erledigt, daher der Aufwand oben in Anführungszeichen.
Mein einziges Problem war, dass die Registrierung meiner Nummer nicht übernommen wurde. Ich war mir nicht ganz sicher, was man aus dem Abschnitt "Umstieg von SiSi" im Wiki alles machen muss, wenn man erst mal parallel installieren will oder wie ich direkt komplett umsteigen. Beispielsweise soll im Skript SIGNALVAR=/opt/fhem/.local/share gesetzt werden, 3 Zeilen weiter wird aber das enthaltene Unterverzeichnis signal-cli verschoben. Also ich denke, da habe ich was falsch gemacht.
Aber egal, auch die erneute Registrierung ist durch das Skript einfach. Ich musste nur die Registry-Anpassung für Windows übernehmen, vorher ist immer die Signal-App beim Öffnen der Capcha-Seite aufgegangen.
Da SiSi auf einer inzwischen sehr alten signal-cli version basiert, denke ich, dass die signal-cli "registry" einfach nicht mehr abwärts-kompatibel ist und daher eine erneute Registrierung jetzt umumgänglich wird. Werde den Hinweis ins Wiki aufnehmen.
Ich musste meine SD Karte am Raspi ersetzen. Hier kurz meine Erfahrung bei Neuinstallation. Ich habe das Raspi OS neu aufgesetzt und ein FHEM backup eingespielt, bei dem Signal schon lief. Dann das signal_install.sh laufen lassen.
Die 64Bit Bullseye geht nicht. Bibliotheken passen nicht.
Das Protocol::DBus wurde nicht automatisch installiert.
Manuell habe ich
cpan install -f Protocol::DBus
zwei mal ausgeführt, bis es installiert war. Beim ersten mal lief signal_install.sh wieder nicht durch. (beim damaligen Umstieg von SiSi war es auch mehrfach nötig)
Dann die Nummer registrieren. Dabei kam kein Captcha in der Firefox Console. Habe dann wie https://forum.fhem.de/index.php/topic,118370.msg1128941.html#msg1128941 die Captcha Seite aufgerufen und raus kopiert.
Danach lief es! :)
Vielleicht hilft die Info jemandem bei der Installation.
Freue mich, dass es das Modul gibt!
Ja, für 64-Bit bräuchte man extra libraries. Mangels Umgebung kann ich die aktuell nicht anbieten. Die Platformabhängigkeit von signal-cli ist hier etwas lästig.
Wenn jemand eine Idee hat, wie man abfragt ob das OS 32 oder 64 bit ist, kann ich da zumindest einen Test/Hinweis einbauen.
Mit der Protocol::DBus installation hatte ich noch nie Probleme. Wäre interessant ob da irgendwelche Fehlermeldungen gekommen sind.
Bezüglich der Captcha Seite gibt es bei signal-cli inzwischen den Hinweis, dass man alternativ diese nehmen sollte:
https://signalcaptchas.org/challenge/generate.html
Da es aber dann manuell mit der original Seite doch geklappt hat (vielleicht auch weil mehrfach versucht?), war es das wohl eher nicht.
Zitat von: Adimarantis am 01 April 2022, 15:03:07
Wenn jemand eine Idee hat, wie man abfragt ob das OS 32 oder 64 bit ist, kann ich da zumindest einen Test/Hinweis einbauen.
Ich hoffe ich blamiere mich jetzt nicht, aber der Befehl mit dem man die architekur im OS abfrägt ist "arch"
Dann bekommst du mit einem 64bit OS und normalen Intel/AMD CPUs "x86_64", oder bei ARM CPUs (Raspi) "aarch64" als Output.
Ich hoffe das ist, was du wissen willst.
Aber nun zu meinem Thema:
Ich hatte zum Wochenende einen Totalausfall bei Signal-CLI (0.8.2)/Signalbot. (Weiß nicht wer jetzt letztendlich verantwortlich war, vermutlich ich ;D )
Am 31.3, hörte Signal auf zu senden. (Ohne mein zutun)
Das erste was ich dann gemacht habe, war ein Update von Fhem. - Kein Erfolg.
Dann hab ich versucht Signal-Cli upzudaten. Ich wollte natürlich auf die neueste Version (0.10.4.2) updaten, was mir aber nicht gelungen ist.
Dein Script macht momentan nur 0.10.4 mit. Allerdings war das auch nicht nachhaltig erfolgreich.
Nachdem ich meine Nummer mit der v0.10.4 registriert hatte, hatte ich Probleme die Nummer wieder mit meiner Gruppe zu verbinden. Autojoin und der Joingroup funktionierte nicht.
Und das schlimmste war, dass nach jeden Neustart des Systems, oder des Dbus, meine Nummer nicht mehr registriert war.
Erst ein Downgrade auf v0.9.2 brachte die Lösung. Jetzt funktioniert erstmal wieder alles, auch ein Groupjoin.
Ich habe keine Ahnung, ob das bekannte Probleme, oder persönliche Probleme mit der v0.10.x sind.
Gruß
Rubinho
Bei mir sendet der Bot, auch heute wieder:
Internals:
FD 33
FVERSION 50_Signalbot.pm:?/2022-02-02
NAME SignalBot
NOTIFYDEV global
NR 463
NTFY_ORDER 50-SignalBot
STATE Connected to /org/asamk/Signal/_49XXXXXXXX
TYPE Signalbot
VERSION Signalbot:3.6 signal-cli:0.9.2 Protocol::DBus:0.19
model Raspbian GNU/Linux 10 (buster)
READINGS:
2022-02-15 20:21:40 account +49XXXXXXXXXX
2022-02-15 20:21:40 accountName FHEM
2021-12-26 21:43:31 joinedGroups
2022-02-15 20:21:40 lastError ok
2021-12-26 22:18:29 msgAttachment
2021-12-26 22:18:29 msgAuth 0
2021-12-26 22:18:29 msgGroupName
2021-12-26 22:18:29 msgSender XXXXXX
2021-12-26 22:18:29 msgText Test4
2021-12-26 22:18:29 msgTimestamp 26-12-2021 22:18:28
2021-12-26 22:18:29 prevMsgAttachment
2021-12-26 22:18:29 prevMsgGroupName
2021-12-26 22:18:29 prevMsgSender XXXXXXXXX
2021-12-26 22:18:29 prevMsgText Alle klar, erledigt
2021-12-26 22:18:29 prevMsgTimestamp 26-12-2021 22:10:52
2022-04-04 06:20:28 sentMsg Logfile
𝟷𝟿:𝟷𝟼:𝟹𝟿 𝟷: 𝙷𝙼𝚄𝙰𝚁𝚃𝙻𝙶𝚆 𝚆𝙻𝙰𝙽_𝙷𝚖𝚄𝙰𝚁𝚃 𝚍𝚒𝚍 𝚗𝚘𝚝 𝚛𝚎𝚜𝚙𝚘𝚗𝚍 𝚏𝚘𝚛 𝚝𝚑𝚎 𝟷. 𝚝𝚒𝚖𝚎, 𝚛𝚎𝚜𝚎𝚗𝚍𝚒𝚗𝚐
𝟷𝟿:𝟷𝟼:𝟺𝟸 𝟷: 𝙷𝙼𝚄𝙰𝚁𝚃𝙻𝙶𝚆 𝚆𝙻𝙰𝙽_𝙷𝚖𝚄𝙰𝚁𝚃 𝚍𝚒𝚍 𝚗𝚘𝚝 𝚛𝚎𝚜𝚙𝚘𝚗𝚍 𝚏𝚘𝚛 𝚝𝚑𝚎 𝟸. 𝚝𝚒𝚖𝚎, 𝚛𝚎𝚜𝚎𝚗𝚍𝚒𝚗𝚐
𝟷𝟿:𝟷𝟼:𝟺𝟻 𝟷: 𝙷𝙼𝚄𝙰𝚁𝚃𝙻𝙶𝚆 𝚆𝙻𝙰𝙽_𝙷𝚖𝚄𝙰𝚁𝚃 𝚍𝚒𝚍 𝚗𝚘𝚝 𝚛𝚎𝚜𝚙𝚘𝚗𝚍 𝚏𝚘𝚛 𝚝𝚑𝚎 𝟹. 𝚝𝚒𝚖𝚎, 𝚛𝚎𝚜𝚎𝚗𝚍𝚒𝚗𝚐
𝟷𝟿:𝟸𝟽:𝟻𝟷 𝟷: 𝙷𝙼𝚄𝙰𝚁𝚃𝙻𝙶𝚆 𝚆𝙻𝙰𝙽_𝙷𝚖𝚄𝙰𝚁𝚃 𝚍𝚒𝚍 𝚗𝚘𝚝 𝚛𝚎𝚜𝚙𝚘𝚗𝚍 𝚏𝚘𝚛 𝚝𝚑𝚎 𝟷. 𝚝𝚒𝚖𝚎, 𝚛𝚎𝚜𝚎𝚗𝚍𝚒𝚗𝚐
2022-04-04 06:20:40 sentMsgRecipient XXXXXX
2022-04-04 06:20:40 sentMsgTimestamp 04-04-2022 06:20:30
helper:
accounts 1
init :1.2711
multi 1
signalpath /org/asamk/Signal/_49XXXXXXXXXX
version 902
accountlist:
+49XXXXXXXXXXX
contacts:
+49XXXXXXXXXCC FHEM
Allerdings mache ich wirklich selten Updates. Scheint eine frühere Version zu sein, bei mir.
Ich hatte neulich auch einen Ausfall. Hier hat aber ein "sudo service signal restart" gereicht.
Aktuell läuft bei mir signal-cli 0.10.4 soweit aber stabil. Auch das angesprochene autojoin haut bei mir hin.
Es gibt aber sicher einen guten Grund warum es die Hotfixes 0.10.4.1 und 0.10.4.2 gibt. Leider hat mir der signal-cli Author hier ein Bein gestellt, da meine ganze "Versionsverwaltung" auf 3 Versionsmerkmale ausgelegt ist. Daher habe ich vor das Update der Skripten auszusitzen bis eine 0.10.5 oder 0.11.0 rauskommt.
Inzwischen gibt es für "bullseye" auch offiziell Java17 (auch auf dem Raspi), so dass ich den Support für dieses OS auf signal-cli 0.10+ heben werde (statt "experimental").
Das "arch" verwende ich ohnehin schon - d.h. die Warnung "unsupported" müsste Karl-Heinz eigentlich bekommen haben :)
War mir mangels Testsystem nur nicht sicher ob da dann was anderes drinsteht. Unter 32-Bit steht ja nicht "aarch64" sondern "armv7l" (auch bei meinem Raspi4) drin.
Ja, unsupported stand da. Es läuft aber trotzdem weiter und meckert erst am Schluß, dass es nicht geht. 8)
Es gab auch bei anderen Modulen Probleme mit 64bit. Über Signal bin ich erst drauf gekommen.
Guten Abend,
Was eigentlich nur ein paar kleine Updates werden sollten, hat jetzt dazu geführt, dass ich einige Teile massiv umgebaut habe.
Daher würde ich jetzt ein paar Unerschrockene suchen, die ein wenig testen um sicherzugehen, dass ich nichts "verschlimmbessert" habe.
Die aktualiserte Version findet ihr erstmal nur auf GitHub: https://github.com/bublath/FHEM-Signalbot
Was ist neu?
Mit signal-cli 0.10+
- viele neue Gruppenfunktionen wie add/removeMembers, add/removeAdmins, deleteGroup, Gruppendetails ...
- Zweistufige "set" Menüführung für Gruppen und Kontakt Befehle (d.h. man wählt erst set group und dann z.B. addMembers anstatt eine riesenlange "set" Liste zu haben). Dieses Feature benötigt das aktuellste FHEMWEB daher vorher FHEM updaten
Generell:
- Eine "send message" Box, damit man den "send" Befehl nicht ständig in der "set" Liste suchen muss (in der er ja leider auch nicht an erster Stelle steht) - siehe Screenshot
- Durchgehende Unterstützung des FHEM Unicode Modus (global->encoding=unicode)
- Überarbeitung von Rückmeldungen in Fehlerfällen
Da ich aktuell nur mit signal-cli 0.10.4 getestet habe, wäre es insbesondere interessant ob ich unter 0.9.2 irgendwas kaputt gemacht habe.
Hallo,
meine Tochter hat ein neues Handy, und Signal neu installiert, aber weiterhin die alte Mobilnummer. Wenn ich jetzt aus fhem heraus eine Message an ihre Nummer sende, bekomme ich folgenden Fehler als reading in Signal:
lastError
Error in sendMessage:112345678976
Failed to send message:
Untrusted Identity for "+4915012345678"
Was muss ich tun?
Dazu steht was im Wiki unter Troubleshooting
Ich mache ja sehr selten updates, aber letztens ging SignalBot nicht mehr und da musste ich ran. War am Ende auch kein Problem. Ich hatte diese Fehlermeldung im Log
2022.04.10 08:49:44 1: reload: Error:Modul 50_Signalbot deactivated:
Can't locate FHEM/Text/Unicode.pm in @INC (you may need to install the FHEM::Text::Unicode module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
BEGIN failed--compilation aborted at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
2022.04.10 08:49:44 0: Can't locate FHEM/Text/Unicode.pm in @INC (you may need to install the FHEM::Text::Unicode module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
BEGIN failed--compilation aborted at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
Und dann habe ich ein Unterverzeichnis FHEM/Text angelegt und dort Unicode.pm abgelegt. War das die richtige Vorgehensweise? Das Unterverzeichnis ist bei mir nämlich leer.
Müsste ich weitere Bibliotheken einspielen? Bisher läuft ja anscheinend bei mir alles:
2022.04.10 09:05:22 3: SignalBot: Before parse:@XXXXXX Test:
2022.04.10 09:05:22 4: SignalBot: sendMessage called for XXXXXX::Test
2022.04.10 09:05:22 5: SignalBot: ASync Dbus Call: sendMessage Args:Test,ARRAY(0x8074058),ARRAY(0x8074100)
2022.04.10 09:05:26 5: SignalBot: ASync Calling: sendMessage Args:XXXXXX
2022.04.10 09:05:27 5: SignalBot: Sync Callback: ReceiptReceived Args:XXXXXX,+491XXXXXX
2022.04.10 09:05:27 5: SignalBot: Signalbot_receive_callback XXXXXX +491XXXXXX
2022.04.10 09:05:27 5: SignalBot: Sync Callback: ReceiptReceived Args:XXXXXX,+491XXXXXX
2022.04.10 09:05:27 5: SignalBot: Signalbot_receive_callback XXXXXX +491XXXXXX
und
Internals:
CFGFN
FD 58
FUUID 62528168-f33f-1115-5f0f-30b84c5f03f76435
NAME SignalBot
NOTIFYDEV global
NR 569
NTFY_ORDER 50-SignalBot
STATE Connected to /org/asamk/Signal/_493XXXXXXX
TYPE Signalbot
VERSION Signalbot:3.7 signal-cli:0.9.2 Protocol::DBus:0.19
model Raspbian GNU/Linux 10 (buster)
READINGS:
2022-04-10 09:04:10 account +493XXXXXXX
2022-04-10 09:04:10 accountName FHEM
2022-04-10 09:04:10 lastError ok
2022-04-10 09:05:22 sentMsg Test
2022-04-10 09:05:27 sentMsgRecipient XXXXXXX
2022-04-10 09:05:27 sentMsgTimestamp 10-04-2022 09:05:22
helper:
accounts 1
init :1.109
multi 1
signalpath /org/asamk/Signal/_493XXXXXXX
version 902
accountlist:
+493XXXXXXX
contacts:
+491XXXXXXX XXXXXXX
+491XXXXXXX XXXXXXX
+493XXXXXXX FHEM
Attributes:
allowedPeer XXXXXXX,XXXXXXX
authDev GoogleAuth
defaultPeer XXXXXXX
registerMethod Voice
Zitat von: andies am 10 April 2022, 09:11:09
Und dann habe ich ein Unterverzeichnis FHEM/Text angelegt und dort Unicode.pm abgelegt. War das die richtige Vorgehensweise? Das Unterverzeichnis ist bei mir nämlich leer.
Das ist ok. Ein "update all" sollte das aber eigentlich automatisch machen - ich nehme mal an du hast nur ein selektives Update gemacht.
Sonst musst du aktuell nichts updaten.
Zitat von: Adimarantis am 09 April 2022, 13:29:35
Dazu steht was im Wiki unter Troubleshooting
Hallo Adimarantis,
danke das hat gut funktioniert! Wahrscheinlich habe ich mit Google nicht nach den richtigen Schlagwörtern gesucht. Danke auch nochmal fuer das tolle Modul und den mehr als guten Support!
Beste Grüsse!
Preview Signalbot 3.8 / signal-cli 0.10.5 / Installer 3.8
Ich habe jetzt grundlegende Tests sowohl mit signal-cli 0.9.2 und 0.10.5 durchgeführt, bevor ich aber nicht ein paar Rückmeldungen bekomme dass alles funktioniert, möchte ich die Version noch nicht über "update" freigeben, daher immer noch nur unter https://github.com/bublath/FHEM-Signalbot
Relevant ist 50_Signalbot.pm und signal_install.sh
Wer erstmal nur signal-cli updaten will, kann dies mit dem neuen Installer machen. Ein Update von Signalbot ist nicht zwingend erforderlich.
Neu:
- Wenn Java17 als Paket verfügbar ist (Debian/Raspbian Bullseye+) oder irgendwie im System installiert ist (JAVA_HOME gesetzt oder "java --version" antwortet mit Version 17) dann wird automatisch signal-cli 0.10.5 installiert. Achtung beim Umstieg von 0.9.2 auf 0.10.5: Die Konfiguration ist nicht rückwärtskompatibel. Es ist also ratsam davon ein Backup anzulegen (installer mit der option "backup" starten). Installer mit "sudo -E" starten wenn ein eigenes JAVA_HOME gesetzt ist.
- Extra "send message" Button
- Mehr Funktionen werden jetzt asychron (im Hintergrund) ausgeführt
- Verbesserte Fehler/Logmeldungen
- set Befehlsliste versteckt weitere Funktionen, wenn diese gerade nicht sinnvoll sind (z.B. captcha, verify)
Nur mit signal-cli 0.10.5: (Achtung, benötigt aktuelles FHEMWEB - insbesondere fhemweb.js)
- neue Gruppenfunktionen zur Mitgliederverwaltung, Löschen von Gruppen, Gruppeninfo
- Zweistufiges "set" Konzept für "group" und "contact" um die "set" Liste übersichtlicher zu gestalten
Hallo Adimarantis,
ich komme von Debian Buster, d.h. ich kann dann nicht auf signal-cli 0.10.5 updaten, korrekt?
lsb_release -d && uname -r
Description: Debian GNU/Linux 10 (buster)
4.19.0-18-amd64
java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14+9-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.14+9-post-Debian-1deb10u1, mixed mode, sharing)
Kann ich denn das neue 50_Signalbot.pm installieren, ohne das udpate von signal-cli auf 0.10.5 ?
Hallo Jamo,
den neuen Signalbot kannst du trotzdem installieren. Wäre ich sogar sehr interessiert daran, ob wirklich alles noch mit signal-cli 0.9.2. funktioniert.
Um signal-cli 0.10.5 auch auf Buster zu installieren gibt es zwei Möglichkeiten:
1. Du suchst dir selber eine Java17 Runtime, installierst diese und setzt JAVA_HOME entsprechend -> dann: sudo -E ./signal_install.sh
2. Du startest den Installer mit der Option "experimental", dann versucht der Installer eine entsprechende Runtime zu installieren
Jörg
Moin Jörg,
habe mir 50_Signalbot.pm und signal_install.sh heruntergeladen und gestartet. Keine Fehlermeldungen, alles läuft wie vorher :)
Mein System ist Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.19 model Debian GNU/Linux 11 (bullseye) auf NUK in Proxmox Container und openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.2+8-Debian-1deb11u1, mixed mode, sharing)
Gruss
Enno
Guten morgen Jörg,
hier dito, läuft wie vorher, keine Auffälligkeiten. Allerdings benutze ich auch nur die Message funktion auf das Handy, und die Funktion um Kommandos an Signal zu schicken, das habe ich beides probiert. Aber keine Gruppen/Mitglieder oder sonst was.
VERSION
Signalbot:3.8 signal-cli:0.9.2 Protocol::DBus:0.19
Zitat von: Adimarantis am 14 April 2022, 08:27:44
1. Du suchst dir selber eine Java17 Runtime, installierst diese und setzt JAVA_HOME entsprechend -> dann: sudo -E ./signal_install.sh
sudo -E ./install_signal.shoder?
Nein, das scheinen zwei verschiedene Versionen zu sein. Die gerade genannte ist die neuere.
Ich habe eine Fehlermeldung, die ich auf den Versand von SVG mit Signal zurückführe:
(process:14355): librsvg-WARNING **: 06:10:01.173: RsvgHandle could not read or parse the SVG; did you check for errors during the loading stage?
Es gibt aber keine Fehlermeldung beim loading stage?
PS
librsvg-2.so.2 -> librsvg-2.so.2.44.10
Hallo andies,
Passiert das bei allen SVGs oder nur bei bestimmten?
Ist FHEM aktuell (insbesondere SVG und FHEMWEB)?
Wie lautet dein Aufruf genau?
Ich kann das bei mir nicht nachvollziehen (selbe libsvg version)
Letztendlich ruft Signalbot hier nur eine Funktion im SVG Modul auf, und das erledigt alles weitere. Daran wurde zuletzt in Version 3.5 was an der Parameterübergabe geändert, ansonsten ist das schon immer gleich.
Jörg
Der Fehler tritt bei mir nicht mehr auf :o
Vorführeffekt? Weiß der Teufel.
Hallo Jörg,
wenn ich mein defmod di_Solar DOIF {}
attr di_Solar uiState {package ui_Table;;\
$TABLE='text-align:center';;\
}\
card([[KG_HK_Sicherungsschrank_Shelly3EM:emeter_3_power:col],[DB_Solar_Shelly:relay_sum_power:col]],"Strom W","",-500,500,120,0,["Verbrauch","Solar"],[(-500,120,0,120,500,60,1000,0)],"2","115,,1,1,,1",",,1,6")
mit set SIGNAL send &di_Solar versuche zu verschicken, bekomme ich folgende Fehlermeldung:
Error: Converting SVG to PNG for package ui_Table;card([::ReadingValDoIf($hash,'KG_HK_Sicherungsschrank_Shelly3EM','emeter_3_power','','col'),::ReadingValDoIf($hash,'DB_Solar_Shelly','relay_sum_power','','col')],"Strom W","",-500,500,120,0,["Verbrauch","Solar"],[(-500,120,0,120,500,60,1000,0)],"2","115,,1,1,,1",",,1,6"); und im Log steht:
(process:15306): librsvg-CRITICAL **: 16:10:30.772: Handle could not read or parse the SVG; did you check for errors during the loading stage?
Bei anderen ui_Table funktioniert es ohne Fehlermeldung. Vermutlich ist der Fehler im DOIF, aber die Graphik wird im Browser angezeigt.
Gruss
Enno
Hi enno
Siehe Wiki, vielleicht ist es das:
Achtung: Es gibt einen bekannten Fehler, dass die SVG library die Halbring-Darstellung in der uiTable card nicht verdaut und diese daher nicht verwendet werden kann
Jörg
Zitat von: Adimarantis am 15 April 2022, 18:17:12
Achtung: Es gibt einen bekannten Fehler, dass die SVG library die Halbring-Darstellung in der uiTable card nicht verdaut und diese daher nicht verwendet werden kann
Die Erklärung würde bei mir passen. Ist Halbring-Darstellung. Dann baue ich mal um :)
Gruss
Enno
Hallo Jörg,
ich versuche aktuell einen Dockercontainer mit der fhem_signal_docker_install.sh,
dabei bekomme ich immer folgende Fehlermeldung, mit der ich leider nichts anfangen kann:
Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "./entry.sh": permission denied: unknown
Weisst Du wie man das Problem in den Griff bekommen kann?
Gruß
Alex
Mit der Docker Installation habe ich schon lange nichts mehr gemacht (da ich das selbst nicht im Einsatz habe).
Rein von der Fehlermeldung würde ich vermuten, dass das Script entry.sh keine execute permissions hat oder dem falschen User gehört.
Habe leider aktuell nicht die Bandbreite das selber nachzustellen.
Die beiden Vermutungen hatte ich auch, es passt aber alles :(
Vielleicht wird entry.sh ja auch ausgeführt und "permissions denied" passiert darin.
Der Installer hat sich ziemlich geändert. Zum einen ist er vielleicht nicht mehr kompatibel und der wird im Script gestartet:
./signal_install.sh start >/tmp/start.log 2>/tmp/start.err
Kommst du evtl. an start.log und start.err dran - vielleicht steht da etwas. Ausserdem die Rechte von signal_install.sh mal kontrollieren.
leider nein, der Container wird ja dadurch nicht gestartet.
Hallo zusammen,
ich kann irgendwie keiner Gruppe beitreten. wenn ich es versuche kommt nur
Error in joinGroup:Failure: StatusCode: 400
Verbose 5
groupjoin https://signal.group/#GRUPPENCODE
2022.04.29 13:31:09 5: mySignalbot: Dbus Call sync:0 joinGroup(s) /org/asamk/Signal/_49MEINE_NUMMER Args:https://signal.group/#GRUPPENCODE
2022.04.29 13:31:10 4: mySignalbot: Dbus Error for: joinGroup (details in reading lasterr)
Wie kann ich dies noch weiter analysieren? Im syslog steht nix dazu.
Infos:
Ich nutze signal mit einer Festnetznummer.
VERSION Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.19
model Ubuntu 20.04.4 LTS
defmod mySignalbot Signalbot
attr mySignalbot autoJoin yes
attr mySignalbot babbleDev myBabble
attr mySignalbot babblePeer XXXXXXXXX
attr mySignalbot defaultPeer +49XXXXXXXXX
attr mySignalbot registerMethod Voice
attr mySignalbot room Signalbot,hidden
attr mySignalbot showtime 1
setstate mySignalbot 0
setstate mySignalbot 2022-04-29 13:18:03 account +49XXXXXXXXXX
setstate mySignalbot 2022-04-29 13:18:03 accountName YYYYYYYYYY
setstate mySignalbot 2022-04-29 13:20:29 joinedGroups
setstate mySignalbot 2022-04-29 13:27:26 lastError Error in joinGroup:Failure: StatusCode: 400
setstate mySignalbot 2022-04-29 13:19:12 msgAttachment
setstate mySignalbot 2022-04-29 13:19:12 msgAuth 0
setstate mySignalbot 2022-04-29 13:19:12 msgGroupName
setstate mySignalbot 2022-04-29 13:19:12 msgSender XXXXXXX
setstate mySignalbot 2022-04-29 13:19:12 msgText https://signal.group/#GRUPPENCODE
setstate mySignalbot 2022-04-29 13:19:12 msgTimestamp 29-04-2022 13:19:12
setstate mySignalbot 2022-04-29 13:21:55 sentMsg Test
setstate mySignalbot 2022-04-29 13:21:59 sentMsgRecipient XXXXXXXX
setstate mySignalbot 2022-04-29 13:21:59 sentMsgTimestamp 29-04-2022 13:21:55
setstate mySignalbot 2022-04-29 13:20:25 state 0
Nachtrag:
List of known groups:
Group |Active|Blocked|Members
FHEM |no |no |Mein_Benutzername
Hast du schon mal probiert ob du FHEM in die Gruppe einladen kannst? Oder ist es dass was du probierst?
Vielleicht darf FHEM der Gruppe ja ohne Einladung nicht beitreten.
Ja ich versuche FHEM einzuladen. Ich habe die Gruppe am Handy erstellt und einen Einladungslink per Signal an FHEM gesendet. In der Gruppe steht er auch als eingeladen drin, aber noch nicht als beigetreten. FHEM ist in signal nicht geblockt oder sowas. Ich habe es mit Autojoin und manuellem Join versucht.
Es liegt auch nicht an der Version von Signalbot, da es mit der Version aus dem normalen Kanal auch schon so war. Daher habe ich heute die 10.5 installiert.
Nachrichten senden und empfangen funktioniert natürlich.
Hab das bei mir mal durchgespielt. Gruppe am Handy erstellt, FHEM eingeladen, nach einem "get groups" wird die Gruppe mit active=yes gelistet. Nachricht an die Gruppe senden erfolgreich. Scheint alles zu gehen (aktuelle Version von github mit signal-cli 10.5)
signal-cli schreibt eigene Fehlermeldungen nach /var/log/syslog. Am Besten ein
tail -f /var/log/syslog | grep signal-cli
und dann die entsprechenden Aktionen durchführen. Vielleicht gibt das mehr Aufschluss.
Zitat von: Nighthawk am 21 April 2022, 11:40:25
ich versuche aktuell einen Dockercontainer mit der fhem_signal_docker_install.sh,
dabei bekomme ich immer folgende Fehlermeldung, mit der ich leider nichts anfangen kann:
Error response from daemon: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "./entry.sh": permission denied: unknown
Ich habe mir heute mal die Dockerinstallation etwas angesehen. Ich hatte den Fehler oben auch, da das execute Recht der entry.sh im fhem-6.x Verzeichnis fehlte. Daher habe ich das Script jetzt angepasst und dabei auch ein paar weitere Anpassungen vorgenommen, damit es jetzt mit signal-cli 0.10.5 , Fhem-6.1 etc. funktionieren sollte.
Neues Docker Script unter: https://github.com/bublath/FHEM-Signalbot
In dem Zuge habe ich die Signalbot Version von Github und den signal-installer der 0.10.5 offziell unterstützt ins SVN eingecheckt.
Zitat von: Adimarantis am 30 April 2022, 19:13:35
Hab das bei mir mal durchgespielt. Gruppe am Handy erstellt, FHEM eingeladen, nach einem "get groups" wird die Gruppe mit active=yes gelistet. Nachricht an die Gruppe senden erfolgreich. Scheint alles zu gehen (aktuelle Version von github mit signal-cli 10.5)
signal-cli schreibt eigene Fehlermeldungen nach /var/log/syslog. Am Besten ein
tail -f /var/log/syslog | grep signal-cli
und dann die entsprechenden Aktionen durchführen. Vielleicht gibt das mehr Aufschluss.
Wenn ich einen
set group join https://signal.group/#XXXXXX mache kommt nichts im Syslog. Senden und Empfangen steht was drin.
ping signal.group geht vom FHEM-Server aus.
wget https://signal.group/#XXXXXX auch
Guten Morgen Adimarantis,
ich hab heute morgen 50-Signalbot.pm upgedated und Fhem neu gestartet. Ich erhalte folgende Version in meinem Signal-Devise:
VERSION Signalbot:3.8 signal-cli:0.9.2 Protocol::DBus:0.19
Hab ich was falsch gemacht, bzw. was hab ich falsch gemacht?
Viele Grüße Gisbert
Zitat von: Gisbert am 01 Mai 2022, 08:43:26
VERSION Signalbot:3.8 signal-cli:0.9.2 Protocol::DBus:0.19
Das ist erstmal völlig in Ordnung. Der Installer updated signal-cli nur wenn Java 17 offiziell unterstützt wird, was bei Debian/Raspban ab 11 (Bullseye) oder Ubuntu 20 der Fall sein sollte.
Wer ein älteres System (z.B. Debian "buster") hat, kann mit
sudo ./signal_install.sh experimentaleine alternative Runtime holen lassen. So "experimentell" ist das nicht mehr - mein Produktivsystem auf Raspian Buster läuft schon geraume Zeit so.
Zitat von: DigiNecro am 01 Mai 2022, 02:20:28
Wenn ich einen set group join https://signal.group/#XXXXXX mache kommt nichts im Syslog. Senden und Empfangen steht was drin.
ping signal.group geht vom FHEM-Server aus. wget https://signal.group/#XXXXXX auch
Ich konnte dein Problem bei mir jetzt Nachstellen. Bei mir hatte sich was mit den signal-cli Service verhakt. Einladung über GroupLink ging auch nicht, da ich keine Messages empfangen konnte und eben auch nichts im syslog stand. Ein
sudo service signal restarthat dann geholfen. Danach ging eigentlich alles wie es soll. Warum signal-cli in diesen Zustand geraten ist, kann ich leider nicht nachvollziehen.
Zitat von: Adimarantis am 01 Mai 2022, 10:44:46
Das ist erstmal völlig in Ordnung. Der Installer updated signal-cli nur wenn Java 17 offiziell unterstützt wird, was bei Debian/Raspban ab 11 (Bullseye) oder Ubuntu 20 der Fall sein sollte.
Wer ein älteres System (z.B. Debian "buster") hat, kann mit
sudo ./signal_install.sh experimental
eine alternative Runtime holen lassen. So "experimentell" ist das nicht mehr - mein Produktivsystem auf Raspian Buster läuft schon geraume Zeit so.
Mein Fhem läuft auf bullseye, wurde aber auch nicht geupdatet.
VERSION
Signalbot:3.8 signal-cli:0.9.2 Protocol::DBus:0.19
model
Debian GNU/Linux 11 (bullseye)
Habe ich was falsch gemacht, muss ich noch etwas anderes aktualisieren. Ein
sudo ./signal_install.shhat auch nichts gebracht.
Gruß LuGu
Euer signal_install.sh hat schon die Versionsnummer 3.8?
#!/bin/bash
#$Id:$
SCRIPTVERSION="3.8"
....
Ansonsten mal
sudo apt install openjdk-17-jdk-headless
ggf. auch alle openjdk-11 Pakete mit apt remove entfernen, die bei
apt list | grep openjdk-11 | grep -i install
auftauchen, bzw. wenn Java11 erhalten bleiben soll mit
sudo update-alternatives --config java
auf Java17 umschalten.
Zitat von: Adimarantis am 01 Mai 2022, 22:05:26
Euer signal_install.sh hat schon die Versionsnummer 3.8?
#!/bin/bash
#$Id:$
SCRIPTVERSION="3.8"
....
Sorry ich hatte vergessen, das script zu aktualisieren.
Danke für den schnellen Support.
VERSION Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.19
model Debian GNU/Linux 11 (bullseye)
Gruß LuGu
Zitat von: Adimarantis am 01 Mai 2022, 11:04:33
Ich konnte dein Problem bei mir jetzt Nachstellen. Bei mir hatte sich was mit den signal-cli Service verhakt. Einladung über GroupLink ging auch nicht, da ich keine Messages empfangen konnte und eben auch nichts im syslog stand. Ein
sudo service signal restart
hat dann geholfen. Danach ging eigentlich alles wie es soll. Warum signal-cli in diesen Zustand geraten ist, kann ich leider nicht nachvollziehen.
Nachdem privat was sehr schönes passiert ist, komm ich gerade nicht mehr zum Testen, aber danke dir! Ich schau mir das bald wieder an.
Zitat von: Adimarantis am 30 April 2022, 23:20:10
Ich habe mir heute mal die Dockerinstallation etwas angesehen. Ich hatte den Fehler oben auch, da das execute Recht der entry.sh im fhem-6.x Verzeichnis fehlte. Daher habe ich das Script jetzt angepasst und dabei auch ein paar weitere Anpassungen vorgenommen, damit es jetzt mit signal-cli 0.10.5 , Fhem-6.1 etc. funktionieren sollte.
Neues Docker Script unter: https://github.com/bublath/FHEM-Signalbot
In dem Zuge habe ich die Signalbot Version von Github und den signal-installer der 0.10.5 offziell unterstützt ins SVN eingecheckt.
Ich mich an der Docker-Installation auf RPI versucht, allerdings scheitert die Installation:
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Err:2 http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Err:3 http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Err:4 http://ports.ubuntu.com/ubuntu-ports jammy-security InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
Reading package lists...
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://ports.ubuntu.com/ubuntu-ports jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://ports.ubuntu.com/ubuntu-ports jammy InRelease' is not signed.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-updates/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-updates/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://ports.ubuntu.com/ubuntu-ports jammy-updates InRelease' is not signed.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-backports/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-backports/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://ports.ubuntu.com/ubuntu-ports jammy-backports InRelease' is not signed.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-security/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2012-cdimage.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: http://ports.ubuntu.com/ubuntu-ports/dists/jammy-security/InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg are ignored as the file is not readable by user '_apt' executing apt-key.
W: GPG error: http://ports.ubuntu.com/ubuntu-ports jammy-security InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 871920D1991BC93C
E: The repository 'http://ports.ubuntu.com/ubuntu-ports jammy-security InRelease' is not signed.
ERROR: Service 'fhem' failed to build: The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive apt-get update -y && DEBIAN_FRONTEND=noninteractive apt-get install -y base-files locales apt-utils sudo' returned a non-zero code: 100
Irgendeine Idee? Verstehe ich das richtig: Das Script installiert docker, docker-compose usw. wenn noch nicht vorhanden. Dann wird ein Ubuntu Docker-Container erstellt und im Container Signal + FHEM installiert? Was genau versucht das Script denn von den Ubuntu-Servern herunterzuladen?
Gruß Jonas
Docker-compose installiert mit "apt" im Container weitere Pakete - die kommen dann von Ubuntu - ist ja schliesslich dann ein Ubuntu System.
Auf dem Raspberry habe ich das bsiher aber noch nicht probert, nur auf einen X86 Server - gut möglich dass da einiges nicht geht.
Hab es mal auf meinem Raspi400 laufen lassen und bin deutlich weiter gekommen, aber durchlaufen tut es nicht.
Auf dem Raspi würde ich wirklich die normale Installation empfehlen. Das mit dem Docker ist eine Spielerei, da fehlt mir sowohl das Know How als auch die Zeit das vollständig zu supporten.
Danke für die Antwort! Dann werde ich nochmal die direkte Installation auf dem Pi versuchen.
Gruß Jonas
Guten Morgen,
habe Signalbot kürzlich auf den neuesten Stand gebracht (Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.19) sowie einige Messages per markdown formatiert. Danach ist mir aufgefallen, dass ich immer eine PerlWarning im Log habe, wenn ich "Save config" klicke.
Ich habe dann den hier https://forum.fhem.de/index.php/topic,105257.msg991907.html#msg991907 (https://forum.fhem.de/index.php/topic,105257.msg991907.html#msg991907) gezeigten Weg genommen und herausgefunden, es liegt an meinem SignalBot-Device. Etwas herumprobieren hat noch ans Licht gebracht, dass die Warning immer kommt, wenn im Reading "sentMsg" irgendswas steht, was per markdown formatiert ist. Ich nutze im Moment nur markdown.
Ist nicht wirklich wichtig, aber vielleicht doch nur ein kleiner Bug.
Gruß
Sany
Hallo zusammen,
ich bin angetan vom SignalBot Modul :D. Herzlichen Dank dafür!
Die Installation und Registrierung hat direkt geklappt und ich habe keine Fehler bekommen.
Zitat
FHEM auf dem aktuellen Stand fhem.pl:v6.1-s26096/2022-05-29
Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.22
Debian GNU/Linux 11 (bullseye)
Grundsätzlich funktioniert das Modul auch. Nur habe ich die Unschönheit, dass nach einem FHEM Neustart kein Nachrichtenversand möglich ist, da das Modul keine Contacts mehr kennt. Ein "list SignalBot" zeigt auch, dass scheinbar keine Contacts mehr da sind. Erst ein "get SignalBot contacts all" macht die vorher hinzugefügten Kontakte wieder bekannt und SignalBot funktioniert wieder einwandfrei.
Im Log bekomme ich beim Neustart diese Fehler...
Zitat
2022.05.31 10:48:38 1: PERL WARNING: Use of uninitialized value $version in numeric lt (<) at ./FHEM/50_Signalbot.pm line 169.
2022.05.31 10:48:38 1: PERL WARNING: Use of uninitialized value $version in numeric ge (>=) at ./FHEM/50_Signalbot.pm line 177.
Ob das mit dem Problem zu tun hat kann ich nicht einschätzen.
Weder hier im Forum noch im Wiki habe ich etwas zu diesem Problem gefunden. Daher bin ich für Ideen oder Ratschläge dankbar.
Grüße,
E-J-D
Ich habe dieselbe Beobachtung gemacht. Allerdings habe ich die Kontakte immer manuell nachgetragen.
Ich kann/muss das auch bestätigen.
Gruß LuGu
Ich denke das ist eine race-condition mit dem Start des signal-cli service.
Das Abfragen der Versionsnummer geht schief, wenn FHEM schneller oben ist als signal-cli.
Ein "set reinit" sollte dann eigentlich auch helfen.
Allerdings hatte ich für den Fall eigentlich was eingebaut (retry mit Verzögerung), aber das scheint wohl nicht wie geplant zu funktionieren.
Muss ich mir bei Gelegenheit mal anschauen.
Jörg
Nope... "set SignalBot reinit" reicht zumindest bei mir nicht aus. Habe es zweimal mit einem "FHEM restart" probiert. Den Rechner selbst habe ich nicht neugestartet. Der SignalBot konnte immer erst wieder senden nachdem ich "get SignalBot contacts all" ausgeführt habe. Dafür habe ich eben beim Neustart im Log noch diese Fehler bekommen:
Zitat
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $args[0] in join or string at ./FHEM/50_Signalbot.pm line 214.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $groupname in pattern match (m//) at ./FHEM/50_Signalbot.pm line 1397.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $rec in concatenation (.) or string at ./FHEM/50_Signalbot.pm line 1613.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $rec in pattern match (m//) at ./FHEM/50_Signalbot.pm line 1614.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $rec in string eq at ./FHEM/50_Signalbot.pm line 1625.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $rec in concatenation (.) or string at ./FHEM/50_Signalbot.pm line 1627.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $groupname in concatenation (.) or string at ./FHEM/50_Signalbot.pm line 1433.
2022.05.31 14:02:55 1: PERL WARNING: Use of uninitialized value $args[0] in join or string at ./FHEM/50_Signalbot.pm line 1238.
Im Vergleich zu vorhin habe ich den SignalBot Accountnamen gesetzt und eine Empfängergruppe erstellt. Die Fehler könnten auch damit zusammenhängen.
Wie vorhin aber schon, läuft alles wunderbar, wenn die Contacts wieder mit "get SignalBot contacts all" in Erinnerung gerufen wurden.
Kann ich bestätigen ein "set SignalBot reinit" hilft nicht, ein "get SignalBot contacts all" schon.
Gruß LuGu
Kriege ich nicht reproduziert. Sogar wenn ich signal-cli beende (service stop signal) und einen "shutdown restart" von FHEM mache, dann kommt alles (mit Verzögerung) sauber hoch.
Etwas irritiert bin ich allerdings davon, dass die Fehler z.B. im "set" command passieren.
Kann es sein, dass ihr bereits unmittelbar beim FHEM Start schon "set" Befehle mit Signalbot macht - zu einer Zeit da die Initialisierung möglicherweise noch gar nicht abgeschlossen ist?
Da liegt möglicherweise die Schwachstelle. Sowas müsste ich wohl blockieren.
Mal ein schneller Hack um zu sehen ob dass das Problem ist.
Bitte mal ausprobieren. "set" und "get" funktionieren jetzt erst wenn erfolgreich eine Versionsnummer eingelesen wurde.
Nope, leider das gleiche Ergebnis.
Vielleicht hilft ein "list Signal" mit den Details weiter? Dies ist ein List nach dem FHEM restart ohne "get contacts all".
Zitat
Internals:
FD 52
FUUID 61a90d5e-f33f-3c07-c2ec-acbba20f6f0ab3c9
FVERSION 50_Signalbot.pm:?/2022-05-31 UNSTABLE
NAME Signal
NOTIFYDEV global
NR 654
NTFY_ORDER 50-Signal
STATE Connected to /org/asamk/Signal/_49xxxxxxxxxxxxx
TYPE Signalbot
VERSION Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.22
eventCount 1
model Debian GNU/Linux 11 (bullseye)
READINGS:
2022-05-31 22:38:55 account +49xxxxxxxxxxxxx
2022-05-31 22:38:55 accountName FHEM-XXXX
2022-05-31 16:11:09 joinedGroups FHEM-XXXX
2022-05-31 22:38:55 lastError ok
2022-05-30 09:58:23 msgAttachment
2022-05-30 09:58:23 msgAuth 0
2022-05-30 09:58:23 msgGroupName
2022-05-30 09:58:23 msgSender XXXX
2022-05-30 09:58:23 msgText XXXX
2022-05-30 09:58:23 msgTimestamp 30-05-2022 09:58:23
2022-05-30 09:58:23 prevMsgAttachment
2022-05-30 09:58:23 prevMsgGroupName
2022-05-30 09:58:23 prevMsgSender XXXX
2022-05-30 09:58:23 prevMsgText XXXX
2022-05-30 09:58:23 prevMsgTimestamp 01-04-2022 17:31:35
2022-05-31 22:19:43 sentMsg xxxx
2022-05-31 22:20:48 sentMsgRecipient xxxx
2022-05-31 22:20:48 sentMsgTimestamp 31-05-2022 22:19:43
helper:
accounts 1
init 1
multi 1
signalpath /org/asamk/Signal/_49xxxxxxxxxxx
version 1005
accountlist:
+49xxxxxxxxxxxxx
attachments:
Attributes:
defaultPeer xxxxx
devStateIcon Connected.*to.*49xxxxxxxxxxxxx:control_on_off@green
group Gateway
icon message_mail
registerMethod Voice
room 91_Gateways
Dies ist ein "list Signal" nach dem FHEM restart MIT "get contacts all".
Zitat
Internals:
FD 52
FUUID 61a90d5e-f33f-3c07-c2ec-acbba20f6f0ab3c9
FVERSION 50_Signalbot.pm:?/2022-05-31 UNSTABLE
NAME Signal
NOTIFYDEV global
NR 654
NTFY_ORDER 50-Signal
STATE Connected to /org/asamk/Signal/_49xxxxxxxxxxxxx
TYPE Signalbot
VERSION Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.22
eventCount 1
model Debian GNU/Linux 11 (bullseye)
READINGS:
2022-05-31 22:38:55 account +49xxxxxxxxxxxxx
2022-05-31 22:38:55 accountName FHEM-XXXX
2022-05-31 16:11:09 joinedGroups FHEM-XXXX
2022-05-31 22:38:55 lastError ok
2022-05-30 09:58:23 msgAttachment
2022-05-30 09:58:23 msgAuth 0
2022-05-30 09:58:23 msgGroupName
2022-05-30 09:58:23 msgSender XXXX
2022-05-30 09:58:23 msgText XXXX
2022-05-30 09:58:23 msgTimestamp 30-05-2022 09:58:23
2022-05-30 09:58:23 prevMsgAttachment
2022-05-30 09:58:23 prevMsgGroupName
2022-05-30 09:58:23 prevMsgSender XXXX
2022-05-30 09:58:23 prevMsgText XXXX
2022-05-30 09:58:23 prevMsgTimestamp 01-04-2022 17:31:35
2022-05-31 22:19:43 sentMsg xxxx
2022-05-31 22:20:48 sentMsgRecipient xxxx
2022-05-31 22:20:48 sentMsgTimestamp 31-05-2022 22:19:43
helper:
accounts 1
init 1
multi 1
signalpath /org/asamk/Signal/_49xxxxxxxxxxx
version 1005
accountlist:
+49xxxxxxxxxxxxx
attachments:
contacts:
+49XXXXXXXXXX YYYYY
+49XXXXXXXXXX ZZZZZ
+49XXXXXXXXXX CCCCC
+49XXXXXXXXXX WWWWW
+49xxxxxxxxxxxxx FHEM-XXXX
Attributes:
defaultPeer XXXX
devStateIcon Connected.*to.*49xxxxxxxxxxxxx:control_on_off@green
group Gateway
icon message_mail
registerMethod Voice
room 91_Gateways
Der Fehler sieht übrigens so (schlicht) aus:
Zitat
Unknown recipient XXX
Nach wie vor muss ein "get Signal contacts all" her. Dann geht wieder alles.
Im "list" kann ich erstmal (außer dass die contacts fehlen) nichts auffälliges entdecken.
Ist jetzt wenigstens das
2022.05.31 10:48:38 1: PERL WARNING: Use of uninitialized value $version in numeric lt (<) at ./FHEM/50_Signalbot.pm line 169.
2022.05.31 10:48:38 1: PERL WARNING: Use of uninitialized value $version in numeric ge (>=) at ./FHEM/50_Signalbot.pm line 177.
weg?
An dieser Stelle wäre ein verbose=5 und der entsprechende Logfile Auszug hilfreich. Muss irgendwas mit dem Ablauf zu tun haben.
Zitat von: Adimarantis am 01 Juni 2022, 07:22:57
Im "list" kann ich erstmal (außer dass die contacts fehlen) nichts auffälliges entdecken.
Aber das ist ja genau das Problem. Nach einem fehm restart hat signal keine contacts mehr. Die muss man erst wieder mit get contacts all reinholen.
Vielleicht liegt es daran, wo die contacts abgelegt werden, so dass sie bei fhem restart verloren gehen?
Gruß LuGu
Es ist richtig, dass FHEM die contacts nicht speichert, da diese von signal-cli bereits gespeichert werden.
Beim Neustart sollten diese eigentlich geholt werden, was aber augenscheinlich nicht (mehr) passiert.
Muss ich mir in Ruhe anschauen. Ich hab da einen Verdacht (hatte in den letzten Version was umgebaut).
Ich hatte mich jetzt erstmal auf die Fehlermeldungen fokussiert.
@Adimarantis
Danke, kein Steress. Man hat ja im Moment ein workaround.
Hauptsache das Problem ist erkannt.
Gruß LuGu
Hallo zusammen,
ich habe heute versucht eine andere Rufnummer zu registrieren aber scheitere irgendwie immer wieder.
Jedes mal wenn ich den captcha Link einfüge erscheint in fhem die Fehlermeldung "Incorrect captcha - e.g. needs to start with signalcaptcha:// " Er beginnt aber mit signalcaptcha....allerdings sieht der Link nun irgendwie anders aus als gewohnt und beginnt so signalcaptcha://signal-recaptcha-v2.6....
In den Readings steht unter last error "Error in registerWithCaptcha:MismatchedInputException No content to map due to end-of-input
at [Source: (FileInputStream); line: 1, column: 0]"
(Signalbot:3.8 signal-cli:0.9.0 Protocol::DBus:0.19)
Hat irgendjemand eine Idee?
Grüße Thomas
Zitatbeginnt so signalcaptcha://signal-recaptcha-v2.6....
Interessant. Da hat sich wohl irgendetwas geändert.
Mir fällt auf, dass du auf einer recht alten signal-cli version (0.9.0) bist.
Zumindest 0.9.2 ist auch ohne Java Update möglichlich.
Ich kann das aktuell nicht ausprobieren, aber wenn sich da bei Signal etwas geändert hat, befürchte ich fast, dass eine neuere Version von signal-cli benötigt wird.
Eventuell kannst du auf signal-cli 0.10.5 updaten (braucht halt Java 17) und sehen ob es dort unterstützt wird.
Es gibt inzwischen sogar signal-cli 0.10.7 aber dafür müsste ich erst die libraries übersetzten, also hoffe ich das 0.10.5 damit geht.
Kurze Rückmeldung dazu:
Nach einem Update auf Java 17 und Signalbot:3.8 signal-cli:0.10.5 Protocol::DBus:0.19 hat es funktioniert.
Mit der signal-cli 0.9.2 funktioniert es auch nicht!
Also muss man zwingend auf Java 17 und signal-cli 0.10.5 updaten, damit die Registrierung funktioniert.
Danke für die Unterstützung
Hallo zusammen,
ich brauche da mal etwas Hilfe...
Ich hatte das ganze Thema schon einmal laufen, nach einem Stromausfall muss ich mich aber offensichtlich neu registrieren.
Durch die geaenderte Form der Captcha Rueckmeldung kann ich die Version 0.9.2 wohl nicht mehr verwenden.
Das install-Script das aktuell in Contrib liegt ist allerdings kaputt, da hat jemand Zeilen eingefuegt um zu markieren was geaendert werden muesste, aber nicht als Kommentar markiert.
Aber selbst wenn ich das auskommentiere kann ich die Version 0.10.5 nicht herunterladen...
Habe aber keinen Plan warum, der zusammengebaute Pfad fuer den Download sieht in meinen Augen so aus als ob er funktionieren sollte...
Vielen Dank und Gruesse
Michael
@Elektron: siehe meinen Post ...
Java 17 installieren und dann ging es ootb
Hat jemand einen Link, wie man das auf einem Raspberry (buster) macht? 17 ist da wohl nicht mit ausgeliefert.
z.Bsp. so:
https://u-labs.de/portal/aktuelles-java-17-11-und-weitere-ueber-die-paketverwaltung-mit-liberica-jdk-auf-dem-raspberry-pi-und-x86-linux-systemen-installieren/
Danke, java17 habe ich jetzt. Allerdings ist mir noch nicht klar, wie ich Signal-Cli 0.10 installiere. Hier
https://packaging.gitlab.io/signal-cli/installation/standalone/ (https://packaging.gitlab.io/signal-cli/installation/standalone/)
Sind einige Apps genannt, aber ich bin mir unsicher, ob ich meine Installation nicht dabei zerstöre.
Noch eine Ergänzung zu #698: Wenn ich die Version 3.8 des Installationsskriptes nehme, wird mir Java 11 wieder installiert:
Zeile 27: /bin/java: Datei oder Verzeichnis nicht gefunden
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
Using Java version: 11.0. <==== vorher deinstalliert!!!
This will update system packages, install or uninstall signal-cli
system : prepare required system package (except signal-cli)
install : install signal-cli and setup as dbus system service
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
start : Start the signal-cli service (or respective docker processes)
all : Run system, install, start and test (default)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...installing (default-jre)
PS
java --version
openjdk 17.0.1 2021-10-19 LTS
OpenJDK Runtime Environment (build 17.0.1+12-LTS)
OpenJDK Server VM (build 17.0.1+12-LTS, mixed mode)
Hallo Adimarantis,
ich hab das Installationsskript laufen lassen, da das Modul nicht mehr funktioniert hat.
Beim Installieren kam diese Frage:
10a11
> Environment="JAVA_HOME="
/etc/systemd/system/signal.service differs, update (Y/n)?
Die habe ich mit Y (=ja) beantwortet.
Jetzt steht in signal.services drin:
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME="
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
insbesondere: Environment="JAVA_HOME="
Da ich auf dem selben Server den UniFi-Controller laufen lasse, der zwingend Java8 benötigt, musste ich einige Klimmzüge machen, damit die neuere Java17-Version für Signal und andererseits die Java8-Version für UniFi zur Verfügung steht.
Meine Frage lautet:
Was müsstet des eigentlich üblicherweise bei Environment="JAVA_HOME=" stehen?
Viele Grüße Gisbert
Edit: Falls ein User den Inhalt der signal.services Datei posten könnte, wäre das auch herzlich willkommen.
Moin,
beim Raspi:
Environment="JAVA_HOME=/usr/lib/jvm/bellsoft-java17-arm32-vfp-hflt"
Also der Pfad zur Java Installion.
Grüße Thomas
Was mache ich, wenn ich da keine Java17 Installation habe
/usr/lib/jvm $ ls
default-java java-1.11.0-openjdk-armhf java-11-openjdk-armhf
Angeblich ist aber Java17 installiert:
$ java --version
openjdk 17.0.1 2021-10-19 LTS
OpenJDK Runtime Environment (build 17.0.1+12-LTS)
OpenJDK Server VM (build 17.0.1+12-LTS, mixed mode)
Hallo andies,
ich hab mir mal folgenden Befehl notiert und bekomme dieses Ergebnis:
dpkg -l | grep "oracle\|openjdk"
ii openjdk-17-jdk:amd64 17.0.3+7-1~deb11u1 amd64 OpenJDK Development Kit (JDK)
ii openjdk-17-jdk-headless:amd64 17.0.3+7-1~deb11u1 amd64 OpenJDK Development Kit (JDK) (headless)
ii openjdk-17-jre:amd64 17.0.3+7-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-17-jre-headless:amd64 17.0.3+7-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
Ohne Gewähr und auf eigenes Risiko (ich hab den Befehl irgendwo aufgeschnappt und verstehe nicht, was er genau macht).
Viele Grüße Gisbert
Da wird nur aufgelistet, was man hat:
dpkg -l | grep "oracle\|openjdk"
ii openjdk-11-jre:armhf 11.0.15+10-1~deb10u1 armhf OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:armhf 11.0.15+10-1~deb10u1 armhf OpenJDK Java runtime, using Hotspot JIT (headless)
Ich will ja Nr 17 installieren, habe das aber angeblich schon installiert.
ZitatIch will ja Nr 17 installieren, habe das aber angeblich schon installiert.
Du hast 17.0.1 (wenn überhaupt) installiert. Mit meinem profunden Halbwissen würde ich auf 17.0.3 versuchen upzugraden.
Dein Wort in Gottes Gehör: Nur wie mache ich das so, dass es in JAVA_HOME erscheint ???
Idealerweise ist Java so installiert, dass Java 17 Standard ist - insbesondere für den User "signal-cli"
Alternativ in
/etc/systemd/system/signal.service
die Zeile
[Service]
...
Environment="JAVA_HOME=<dein Java Pfad>"
ExecStart=.....
einfügen und den Service neu starten.
Irgendwas passt immer noch nicht. Inzwischen habe ich den Pfad richtig eingestellt
sudo systemctl status 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-06-18 21:57:27 CEST; 3min 48s ago
Main PID: 1747 (java)
Tasks: 31 (limit: 2060)
CGroup: /system.slice/signal.service
└─1747 /home/pi/.sdkman/candidates/java/17.0.1-librca/bin/java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.jar:/opt/signal/lib/lib.jar
Jun 18 21:56:11 raspfhem systemd[1]: Starting Send secure messages to Signal clients...
Jun 18 21:57:27 raspfhem signal-cli[1747]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_493039831419
Jun 18 21:57:27 raspfhem systemd[1]: Started Send secure messages to Signal clients.
und das heißt, Java Version 17 läuft. Aber wenn ich signal_install.sh laufen lasse, erhalte ich nach wie vor
sudo ./signal_install.sh
./signal_install.sh: Zeile 27: /bin/java: Datei oder Verzeichnis nicht gefunden
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
Using Java version: 11.0 <====== DAS IST FALSCH
This will update system packages, install or uninstall signal-cli
In Zeile 27 steht
JVER=`$JAVA_HOME/bin/java --version | grep -m1 -o '[0-9][0-9]\.[0-9]'
Liegt das am Pfad? JAVA_HOME lautet ja bei mir sinngemäß
/home/pi/.sdkman/candidates/java/17.0.1-librca
PS
printenv JAVA_HOME
/home/pi/.sdkman/candidates/java/current
Auch ein anderer Pfad hat nicht geholfen, bei
sudo systemctl status 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-06-18 22:19:35 CEST; 51s ago
Main PID: 2126 (java)
Tasks: 33 (limit: 2060)
CGroup: /system.slice/signal.service
└─2126 /home/pi/.sdkman/candidates/java/current/bin/java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.jar:/opt/signal/lib/lib.jar:/opt/
Jun 18 22:19:13 raspfhem systemd[1]: Starting Send secure messages to Signal clients...
Jun 18 22:19:35 raspfhem signal-cli[2126]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_493039831419
Jun 18 22:19:35 raspfhem systemd[1]: Started Send secure messages to Signal clients.
wieder das gleiche Ergebnis
sudo ./signal_install.sh
./signal_install.sh: Zeile 27: /bin/java: Datei oder Verzeichnis nicht gefunden
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
Using Java version: 11.0
This will update system packages, install or uninstall signal-cli
Hallo andies,
da ich Java8 für UniFi benötige, musste ich verhindern, dass UniFi die aktuelle Java-Version nimmt.
Dazu habe ich in der Datei .bashrc in der 1. Zeile ergänzt:
export JAVA_HOME=
Damit nimmt UniFi die Version 8 und Signal die aktuell installierte Version. Es kann sein, dass noch eine 2. Sache eingestellt werden muss, dass müsste ich aber extra nachschauen.
Probier's mal (ohne Gewähr auf Erfolg), ich warte auf eine Rückmeldung und schau ggf. nach.
Viele Grüße Gisbert
Hallo zusammen,
ich habe jetzt entsprechend der letzten Posts hier meine JAVA Version auf 17 aktualisiert, die neue signal_install.sh heruntergeladen und signal installiert. Das ging ziemlich gut. Leider lässt sich der signal-Service aber nicht starten:
● 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 Mon 2022-06-20 13:37:43 CEST; 7min ago
Process: 10419 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=2)
Main PID: 10419 (code=exited, status=2)
CPU: 15.709s
Jun 20 13:37:43 fhempi signal-cli[10419]: at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:59)
Jun 20 13:37:43 fhempi signal-cli[10419]: at com.fasterxml.jackson.databind.ObjectMapper._initForReading(ObjectMapper.java:4765)
Jun 20 13:37:43 fhempi signal-cli[10419]: at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4667)
Jun 20 13:37:43 fhempi signal-cli[10419]: at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3666)
Jun 20 13:37:43 fhempi signal-cli[10419]: at org.asamk.signal.manager.storage.recipients.RecipientStore.load(RecipientStore.java:59)
Jun 20 13:37:43 fhempi signal-cli[10419]: ... 28 more
Jun 20 13:37:43 fhempi systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 20 13:37:43 fhempi systemd[1]: signal.service: Failed with result 'exit-code'.
Jun 20 13:37:43 fhempi systemd[1]: Failed to start Send secure messages to Signal clients.
Jun 20 13:37:43 fhempi systemd[1]: signal.service: Consumed 15.709s CPU time.
Hat jemand eventuell eine Idee?
Vielen Dank!
Das schaut fast nach einem Problem mit der Config aus. Eventuell war der Versionssprung zu hoch?
Du könntest im Script die Version mal auf 0.10.4 stellen und neu installieren.
Um zu prüfen ob es wirklich die Config ist, mal den Inhalt vom Order /var/lib/signal-cli woanders wegsichern und sehen um er dann zumindest unregistriert startet
Jörg
Hallo Jörg,
ohne Config startet er leider auch nicht. Mit 10.04 hat er zumindest eine andere Fehlermeldung:
● 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 Mon 2022-06-20 18:45:47 CEST; 41s ago
Process: 15480 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1/FAILURE)
Main PID: 15480 (code=exited, status=1/FAILURE)
CPU: 12.847s
Jun 20 18:45:08 fhempi systemd[1]: Starting Send secure messages to Signal clients...
Jun 20 18:45:15 fhempi signal-cli[15480]: OpenJDK 32-Bit Server VM warning: You have loaded library /tmp/resource13041507136788151969.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Jun 20 18:45:15 fhempi signal-cli[15480]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Jun 20 18:45:15 fhempi signal-cli[15480]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource13041507136788151969.so: /tmp/resource13041507136788151969.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: can't load AMD >
Jun 20 18:45:15 fhempi signal-cli[15480]: Missing required native library dependency: libsignal-client
Jun 20 18:45:47 fhempi systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Jun 20 18:45:47 fhempi systemd[1]: signal.service: Failed with result 'exit-code'.
Jun 20 18:45:47 fhempi systemd[1]: Failed to start Send secure messages to Signal clients.
Jun 20 18:45:47 fhempi systemd[1]: signal.service: Consumed 12.847s CPU time.
Da stimmen jetzt die native libraries nicht.
Mal /opt/signal löschen und neu installieren, damit nichts durcheinanderkommt. "downgrade" ist nicht getestet
Hallo Jörg,
ich habe signal jetzt über das Script einmal deinstalliert und neu installiert. Jetzt funktioniert es.
Eigentlich hätte ich das gleich so machen sollen :/
Ich hab über Signalbot eine Festnetznummer registriert und kann auch Nachrichten senden und Empfangen, würde aber gerne den accountName auf irgendwas mit FHEM-* setzen. Geht das? Im Moment ist das Reading leer.
[Update] Hab es gefunden: set updateProfile
Zitat von: andies am 10 April 2022, 09:11:09
Ich mache ja sehr selten updates, aber letztens ging SignalBot nicht mehr und da musste ich ran. War am Ende auch kein Problem. Ich hatte diese Fehlermeldung im Log
2022.04.10 08:49:44 1: reload: Error:Modul 50_Signalbot deactivated:
Can't locate FHEM/Text/Unicode.pm in @INC (you may need to install the FHEM::Text::Unicode module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
BEGIN failed--compilation aborted at ./FHEM/50_Signalbot.pm line 31, <$fh> line 3450.
...
Das hab ich nun auch, nach einem "update all".
Wo finde ich den die "Unicode.pm"?
Im SVN gibts doch nicht mal das Verzeichnis Text - oder bringe ich hier gerade was durcheinander?
Update all sollte die unicode.pm eigentlich auch holen.
Ist unter lib:
https://svn.fhem.de/trac/browser/trunk/fhem/lib/FHEM/Text/Unicode.pm
Danke für den Tipp, da habe ich die Datei dann auch gefunden.
Ich glaube, bei mir ist bei irgendeinem Update was schief gelaufen und es wurde nur halb durchgeführt. Dann war der Signalbot dann fort und die Fehlermeldung richtig, da die Datei wohl gefehlt hat. Und als das Update dann ganz durchlief war es logischeweise zu spät.
Jetzt wieder geholt, updatehinweis kam rein, genau nach Anleitung, d.h. skript aus dem www-Verzeichnis laufen lassen, geupdatet - alles klappt.
Schon immer wieder beeindruckend - danke!
Zitat von: Gisbert am 19 Juni 2022, 13:14:02
Dazu habe ich in der Datei .bashrc in der 1. Zeile ergänzt:
export JAVA_HOME=
Damit nimmt UniFi die Version 8 und Signal die aktuell installierte Version. Es kann sein, dass noch eine 2. Sache eingestellt werden muss, dass müsste ich aber extra nachschauen.
Danke, das hat mit der Java-Version geklappt, endlich
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
Using Java version: 11.0 <====== HIER
Aber wieso installiert er nach wie vor 0.9.2? Zwischendrin wurde ich gefragt
Checking for /etc/systemd/system/signal.service...found
11c11
< Environment="JAVA_HOME=/home/pi/.sdkman/candidates/java/current"
---
> Environment="JAVA_HOME="
/etc/systemd/system/signal.service differs, update (Y/n)?
Y
/etc/systemd/system/signal.service updated
Start signal-cli service
Checking installation via dbus-send command...success
Sending a message via perl Protocol::DBus...reply receivedaber ich habe nachher immer noch 0.9.2?
Das Script erkennt Java 11.0 und erlaubt damit nur die installation von 0.9.2 das ja die 0.10.x Java 17 benötigt.
Du musst deine Umgebung so konfigurieren, dass
java --version
als Version 17.0 ausgibt (und den Installer dann mit sudo -E starten, damit das Environment übernommen wird).
Alternativ kannst du den Installer mit
sudo ./signal-install.sh experimental
starten, dann installiert er eine private Java 17 version nach /opt/java
Bingo - danke. Das "Minus E" war das entscheidende. Jetzt habe ich endlich auch 10.5.
Zitat von: fettgu am 04 Januar 2022, 21:48:42
ich habe das Problem gefunden bei Nutzung der configdb.
Wenn man ' statt " benutzt, funktioniert das Schicken vom Filesystem, aber nicht von der configdb.
Ich habe ein ähnlich gelagertes Problem. Ich habe ein Bild
Internals:
DEF DbLog:SVG_DbLog_Wasserzaehler_1:CURRENT
FUUID 5f64e557-f33f-1115-4639-875d9eb9fbaf5acd
FVERSION 98_SVG.pm:0.258760/2022-03-23
GPLOTFILE SVG_DbLog_Wasserzaehler_1
LOGDEVICE DbLog
LOGFILE CURRENT
NAME WasserPlot
NR 387
STATE initialized
TYPE SVG
Attributes:das ich aber nicht per SignalBot versenden kann. Ich habe probiert
&({plotAsPng("Wasserplot")}) => File not found: Bareword "Wasserplot" not allowed while "strict subs" in use at (eval 17977) line 1.
&({plotAsPng('Wasserplot')}) => keine Reaktion
&({plotAsPng(\"Wasserplot\")}) => keine Reaktion
&({plotAsPng(\'Wasserplot\')}) => auch hier kommt nichts an
Was mache ich falsch?
probier mal einfach
send @Empfänger &Wasserplot
Nachdem das mit dem "Escapen" immer wieder zu Verwirrung geführt hat, hatte ich vor einer Weile eingebaut, dass er bei & SVG und DOIF Devices erkennt und automatisch die entsprechende Chart sendet. Es gibt noch optionale Parameter dazu - siehe dazu im Wiki: https://wiki.fhem.de/wiki/Signalbot#Details_zum_Versenden_von_Plots:
Super, das klappt! Jetzt habe ich noch ein Problem, das schon in
https://forum.fhem.de/index.php/topic,116138.15.html (https://forum.fhem.de/index.php/topic,116138.15.html)
diskutiert wurde. Fehlende Farben, siehe Anhang.
Update 3.9:
-Installer (und pre-compiled libs) auf signal-cli 0.10.9 angepasst - ein update von signal-cli ist aber nicht zwingend erforderlich
-Installer: Verbesserte Erkennung von eigener Java17 Installation in /opt/java
-Signalbot: Bug behoben, der Kontakte bei Neustart nicht synchroniert hat
Gerade ins SVN eingecheckt, ab morgen per update
Jörg
Vorerst vielen Dank für das neue Modul und auch für die Installationsscripte - insbesondere für die Docker-Installation.
Ich habe es auf einem nackten Raspy-Testsystem probiert und bin leider einige Male über die eigenen Füße gestolpert.
Daher hier etwas feedback.
In fhem_signal_docker_install.sh Zeile 308-317 scheint mir der else-Zweig zu fehlen. Ohne einer bestehenden FHEM Installation wird auch keine neue installiert und man hat nachher gar kein FHEM.
Die erstellte entry.sh wird in fhem_signal_docker_install.sh Zeile 351 an ihren richtigen Platz kopiert. Ich sehe aber keine Stelle wo sie executeable gemarkt wird. Der Start des Containers geht bei mir daher mit permission denied schief.
Der Automatismus für die Captcha Eingabe ist genial, hat aber 2 Stolperfallen im Registry-Hack.
Unter Docker wird mir die nichterreichbare interne Dockeradresse (z.b. 192.168.48.2 - also Rechner-IP und nicht die IP der Anfrage-URL) im Hack eingetragen.
Der Registry-Hack funktioniert wegen der CSRF Absicherung nur für die laufende FHEM Session, muss also nach einem FHEM Neustart wieder neu geholt und in die Registry eingetragen werden. Da wäre vlt ein Hinweis 'immer neu durchführen' hilfreich.
LG Michael
Hallo Michael,
Die Docker Installation wird von mir mangels eigener Nutzung leider nicht so aktiv gewartet. Teilweise aus Zeitmangel (läuft ja doch eine Weile), teils weil ich mich mit Docker im Detail nicht so gut auskenne.
Du darfst aber gerne unter github.com/bublath einen Pull Request für Verbesserungen machen. Wenns gut ausschaut übernehme ich sie dann auch ins FHEM SVN.
ok, schau ich mir an.
Hat es einen Grund, warum du den Docker selbst baust und nicht den aktuellen fhem/fhem vom gitprojekt nimmst? Mit dem scheint signal_docker_install.sh auf wenige Zeilen zu schrumpfen. Bin mit dem Test noch nicht durch, da es im signal_install.sh auch noch ein Docker Problem gibt, das mich wirft.
LG Michael
Keinen besonderen Grund.
War halt mehr ein Übungsprojekt um mal einen Container von Grund auf zu bauen.
Mein Ansatz war signal-cli als eigenständigen Container zu bauen. Also unabhängig von FHEM.
Eine Integration in den FHEM Container könnte evtl. auch die Dbus Kommunikation vereinfachen.
Gruß,
Jörg
Ich habe jetzt (vorerst nur für den raspberry) eine Extension für den original fhem-docker auf github gestellt (https://github.com/holoarts/fhem-signal-docker.git (https://github.com/holoarts/fhem-signal-docker.git)). Das sind nur 6 kleine Files und mit einem docker-compose up -d hat man nach etwas Wartezeit :) ein laufendes fhem mit deinem signalbot. Mit allen Vorteilen des original Docker images.
Wäre fein, wenn das der eine oder die andere aus der Community testen könnte.
LG Michael
Hallo zusammen,
ich habe SIGNAL auf eine RasPi 3 installiert und kann es mit einer Festnetznummer problemlos nutzen.
Ich möchte auf einem 2. RasPi zu der gleichen Festnetznummer einen Signal link erstellen. Geht so etwas überhaupt?
Warum möchte ich das: Ich habe eine Festnetznummer die ich für Signal benutzen will, aber es soll auf 2 FHEM Instanzen gesendet und empfangen werden. Oder brauche ich dazu eine 2. Festnetznummer?
Danke
Rein technisch wäre das machbar. Ist nur nicht implementiert. Man kann ja per link Funktion ein bestehendes Handy Account verknüpfen.
Es fehlt jetzt nur die Funktion einen entsprechenden qr code ( oder eher eine ASCII version davon) mit der anderen FHEM Instanz einzulesen.
Möglicherweise ein interessantes Feature, müsste ich mir bei Gelegenheit ansehen.
Ich habe das bei mir so gelöst, dass die zweite FHEM Instanz per FHEM2FHEM verbunden ist. Dann kann man sowohl Events mithören, als auch per cmd entsprechende set Befehle über den SignalBot auf der anderen Instanz ausführen.
Das mit der 2. Instanz würde ich über MQTT lösen, aber ich fände es gut wenn die beiden Signal-Funktionen weitgehend unabhängig (sie funktionieren auch wenn die andere nicht geht) Meldungen absetzen können. Bei mir soll die eine Instanz die sein, die in Normalfall kommuniziert, und die andere soll "nur" Systemfehler melden und damit auch melden können wenn die andere nicht mehr funktioniert. Gibt es eine manuellen Weg die "ASCII Version de QR" in der anderen Instanz einzulesen?
Danke
Ich habe versucht zu verstehen wie ein Link-Device zu erstellen funktioniert. Ich komme jedoch über die cli (signal-cli) nicht wirklich ans Ziel.
Wenn ich mir auf dem fhem der linked Device werden soll den QR Code anzeigen lasse, aus diesem QR Code den Teil sgnl://linkdevice?uuid=XX=pub_key=XXXX herausnehme und dann versuche auf dem gleichen System
./signal-cli addDevice --uri "sgnl://linkdevice?uuid=XX=pub_key=XXXX"
erhalte ich die Fehlermeldung No local users found, you first need to register or link an account.
Habe ich einen Denkfehler?
Ich hab das auch gerade mal probiert und testweise ein "addDevice" in Signalbot eingebaut.
Funktioniert dann so:
Auf dem "neuen" System (keine Nummer registriert) ein "set link" ausführen.
In meiner Testversion wird jetzt die URI für addDevice zusammen mit dem QRCode angezeigt.
Auf dem bereits registrierten System ein "addDevice" mit dieser URI durchführen.
Ein Weilchen warten, und dann ein "set reinit" auf dem neuen System. Dort sollte jetzt unter "set signalAccount" die Nummer des anderen Systems auftauchen.
Entsprechend setzen und man ist verbunden.
Leider bin ich auf zwei Probleme gestossen, die möglicherweise auch auf signal-cli Seite liegen (hab dazu auch mal ein Issue auf Github aufgemacht):
- Die gelinkte Instanz kann nur senden aber nicht empfangen
- Die gelinkte Instanz bekommt keine Gruppeninfos (wohl aber die Kontaktliste)
Dies ist ausdrücklich nur eine Testversion als "proof of concept".
Gruß,
Jörg
Zitat von: holoarts am 06 August 2022, 13:14:16
Ich habe jetzt (vorerst nur für den raspberry) eine Extension für den original fhem-docker auf github gestellt (https://github.com/holoarts/fhem-signal-docker.git (https://github.com/holoarts/fhem-signal-docker.git)). Das sind nur 6 kleine Files und mit einem docker-compose up -d hat man nach etwas Wartezeit :) ein laufendes fhem mit deinem signalbot. Mit allen Vorteilen des original Docker images.
Wäre fein, wenn das der eine oder die andere aus der Community testen könnte.
LG Michael
Hi Michael,
super Timing :) Ich möchte aktuell meine FHEM-Installation von einem dedizierten Intel NUC auf einen zentralen Server mit Containern umziehen (also x86). Ich habe mich erstmal am offiziellen FHEM image orientiert, bis mir eingefallen ist, dass es da mit signal-cli einen besonderen Kandidaten gab.
Jetzt sind das praktisch auch meine ersten Gehversuche mit Containern, aber ich denke die Grundzüge verstanden zu haben. Eigene Images habe ich noch nicht erstellt. Was wäre jetzt (ganz grob) ein Best-Practice-Ansatz, um Dein Image auf x86 umzubauen und bei mir zu laden? Gerne auch per PM, falls das zu Offtopic hier wird. Mir geht es hier erstmal vor allem um den Docker-Image-Teil.
Danach muss ich dann mal schauen, wie ich das bei mir importiert bekomme. Auf meinem Server läuft ein Truenas Scale, das eigentlich nur images aus Repositories zieht.
Gruß
Chris
Edit: Habe mich da heute Abend mal reingelesen und das Image für x64 gebaut. Startet und sieht erstmal gut aus. Teste in den nächsten Tagen mal weiter.
Hi Chris,
freut mich, dass du meine Erweiterung brauchen kannst.
Da das original fhem/fhem Image x86 kann, ist vermutlich nur in meinem Dockerfile der Link https://github.com/bublath/FHEM-Signalbot/raw/main/armhf-glibc2.31-0.10.9/libsignal_jni.so durch https://github.com/bublath/FHEM-Signalbot/raw/main/amd64-glibc2.28-0.10.9/libsignal_jni.so. Das hast du vermutlich ohnehin schon gemacht.
Ich habe leider kein Testenvironment dafür zur Verfügung.
Zu Truenas Scale kann ich leider nichts beitrage.
LG Michael
Ja, genau ich habe nur die Library getauscht (auch wenn ich natürlich erstmal die falsche Version gegriffen hatte). Der Container läuft jetzt auch und Signal sendet auch fleißig. Mir war nur erstmal gar nicht klar, wie ich da jetzt meinen eigenen Container bauen muss, aber das war eine vergleichsweise flache Lernkurve!
Danke nochmal. Das hat meinen Umstieg auf Docker massiv erleichert.
Danke natürlich an dieser Stelle nochmal an Jörg für das super Plugin, was hier seit Monaten gute Dienste verrichtet.
Zitat von: Adimarantis am 08 August 2022, 18:29:27
Ich hab das auch gerade mal probiert und testweise ein "addDevice" in Signalbot eingebaut.
...
- Die gelinkte Instanz kann nur senden aber nicht empfangen
Das scheint bei mir nach einem sauberen reinit jetzt doch zu funktionieren. Gruppeninfos ist wohl ein bekanntes Problem.
Update 3.10:
Neue Funktionen (nur unter signal-cli 0.10+)
set addDevice : Fügt eine andere (FHEM) Instanz als "Mitbenutzer" zur aktuellen Nummer hinzu. Der URI Code dazu wird auf der anderen Device mit "set link" erzeugt. Die zweite Device kann sowohl senden als auch empfangen, was bei der Event Bearbeitung zu beachten ist, damit es kein Durcheinander gibt.
set removeDevice: Entfernt eine "linked device". Argument ist die Device ID die man über "get devices" erhält.
get devices: Listet all gelinkten Devices auf, wobei #1 üblicherweise die Hauptdevice ist
Geänderte Funktionen:
set link : Hat nun einen optionalen Parameter um einen Namen festzulegen (der dann bei "get devices") sichtbar wird.
Hallo Adimarantis,
ich halte den Signalbot immer auf dem laufenden Stand und ich erinnere mich, dass es diese Woche auch noch lief.
Durch deine Ankündigung von gestern abend habe ich in das Device reingeschaut und folgendes gesehen:
signal-cli v0.9.0+ required.
Please use installer to install or update
Note: The installer only supports Debian based Linux distributions like Ubuntu and Raspberry OS
and X86 or armv7l CPUs
You can download the installer here or your www/signal directory and run it with
sudo ./signal_install.sh
Hinweis: der link unter "here" funktioniert nicht.
Ich hab die Installationsdatei runtergeladen: https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/ (https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/) und ausgeführt.
Ich erhalte folgende Fehlermeldung:
Checking system Java version ... Unrecognized option: --version
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Installing openjdk-17-jre-headless...Unrecognized option: --version
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
failed
Warum hat das noch kürzlich laufende Device/Modul seinen Geist aufgegeben und warum funktioniert der Installer nicht?
Grund gefunden.
Wegen des Unifi-Controllers muss ich Java 8 benutzen. Ich benötige für Signal aber Java 17. Aus einem Grund, den ich nicht weiß, wurde die primäre Java-Installation auf die Version 8 gesetzt:
java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-1~deb9u1-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
Java 17 ist aber installiert:
sudo update-java-alternatives --list
java-1.17.0-openjdk-amd64 1711 /usr/lib/jvm/java-1.17.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64
Mit folgendem Befehl wird Java 17 die primäre Version:
sudo update-java-alternatives --auto
java -version
openjdk version "17.0.4" 2022-07-19
OpenJDK Runtime Environment (build 17.0.4+8-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 17.0.4+8-Debian-1deb11u1, mixed mode, sharing)
Damit läuft die Signal-Installation sauber durch und Signal funktioniert wieder :) :) :)
Noch eine kleine Ergänzung für Unifi-Controller Geschädigte:
Man muss in der .bashrc (liegt im Home-Verzeichnis des Users) in der 1. Zeile folgendes ergänzen:
export JAVA_HOME=
Damit wird kein Pfad für Java angegeben. Unifi kommt damit anscheinend zurecht, da Java 8 dort hardgecodet ist.
Viele Grüße Gisbert
Hallo, erst einmal Danke für die Implementierung der Funktion AddDevice
ICH WAR DER FEHLER!! Copy Paste hat nicht funktioniert. Das Modul funktioniert!
Ich habe das versucht zu nutzen, bin aber auf einen Fehler gestoßen.
Auf dem System auf dem ich addDevice durchführen will bekomme ich den Fehler: Error in addDevice:Failure: NotFoundException Add device link failed. [404] Not found
Im verbose 5 Log bekomme ich das folgende
2022.08.23 10:12:36 3: CORESECURE.SIGNAL: AddDevice for sgnl://linkdevice?uuid=XXX&pub_key=YYY returned:
2022.08.23 10:12:58 5: CORESECURE.SIGNAL: Dbus Call sync:1 addDevice(s) /org/asamk/Signal/_49999999 Args:sgnl://linkdevice?uuid=XXX&pub_key=YYY
2022.08.23 10:12:58 4: CORESECURE.SIGNAL: Dbus Error for: addDevice (details in reading lasterr)
2022.08.23 10:12:58 3: CORESECURE.SIGNAL: AddDevice for sgnl://linkdevice?uuid=XXX&pub_key=YYY returned:
Bin ich der Fehler, oder gibt es eine Idee.
Danke
Guten Abend,
Ich möchte auf meiner Raspberry von SISI auf Signalbot umsteigen. Muss ich dafür irgendwas von SISI erst entfernen, bevor ich das Sognalbot script zur Neuinstallation ausführe?
@oelkanne: Ich bin nach der Anleitung unter Punkt "Umstieg von SiSi" im Wiki vorgegangen ...
https://wiki.fhem.de/wiki/Signalbot (https://wiki.fhem.de/wiki/Signalbot)
@tomcat.x
In der WIKI wird von einer einfachen Migration abgeraten. Deshalb wollte ich SIGNALBOT "frisch" installieren (mit dem Script). Unklar ist mir jedoch, ob oder wie ich das alte SISI vorher entfernen kann.
Die alte Registrierung in der Uralt-Version von signal-cli die SiSi verwendet ist nicht mehr kompatibel. Daher solltest du die Nummer von vorne registrieren.
Im Prinzip überschreibt die Signalbot Installation alle aktiven Komponenten von SiSi, so dass eine händische Deinstallation nicht notwendig sein sollte. Nur das SiSi Device in FHEM muss vorher manuell gelöscht werden.
Du kannst ja mal berichten ob du Probleme hattest.
Mir fällt dabei wieder ein, dass ich vor kurzem die Nummer neu registrieren musste und dann darüber gestolpert bin, dass sowohl beim Link als auch in der Registry-Datei für Windows die IP-Adresse (statt Servername) und "http" stand, was nicht so gut funktioniert, wenn fhem nur über https erreichbar ist ;-). Gestartet habe ich das im Browser, wo ich fhem mit https über den Namen aufrufe. Wird das von irgendwo gezogen, wo ich es ändern könnte?
Also das reg file kannst du ja editieren bevor du es in Windows einliest.
Mit den http vs https hast du wohl recht. Ich gehe mal davon aus, dass dazu das Attribut HTTPS in FHEMWEB auf 1 gesetzt wird.
Das kann ich abfragen und entsprechend http oder https verwenden.
Natürlich könnte ich statt der IP auch den Hostname verwenden, aber das setzt voraus, dass der im lokalen Netz überall bekannt ist, wovon ich nicht zwingend ausgehen kann, daher nehme ich hier lieber die IP.
Das führt dann mit https wahrscheinlich zu einer "unsicheren Verbindung", aber das kann mal ja hier einmalig ignorieren (oder wie gesagt eben das reg file editieren).
Oder kann ich im https Fall davon ausgehen dass "hostname -f" mir den korrekten Namen gibt und dass dann immer funktionert?
Mein FHEM Setup ist im lokalen Netz ohne HTTPS - bei mir ist nginx vorgeschaltet und der übernimmt die ganze Absicherung, daher bin ich auf das Problem noch nicht gestossen.
Zitat von: Adimarantis am 04 September 2022, 19:26:18
Also das reg file kannst du ja editieren bevor du es in Windows einliest.
Ja, klar. Im Browser fällt einem das halt direkt auf, in der Reg-Datei nur, wenn man sich die mal anschaut.
Zitat von: Adimarantis am 04 September 2022, 19:26:18
Ich gehe mal davon aus, dass dazu das Attribut HTTPS in FHEMWEB auf 1 gesetzt wird.
Ja, genau.
Zitat von: Adimarantis am 04 September 2022, 19:26:18
Das führt dann mit https wahrscheinlich zu einer "unsicheren Verbindung", aber das kann mal ja hier einmalig ignorieren
Je nach Browser muss man eine Ausnahme definieren, wobei ich damit glaube ich auch schon bei manchen Browser Probleme hatte. Also besser Adresse und reg Datei manuell anpassen.
Zitat von: Adimarantis am 04 September 2022, 19:26:18
Oder kann ich im https Fall davon ausgehen dass "hostname -f" mir den korrekten Namen gibt und dass dann immer funktionert?
Hm, also bei mir wohl nicht ;-) Muss ich mal schauen, die Domain fehlt.
Also insgesamt nicht so einfach das mal schnell umzusetzen. Braucht man ja auch nicht ständig.
Danke.
ZitatJa, klar. Im Browser fällt einem das halt direkt auf, in der Reg-Datei nur, wenn man sich die mal anschaut.
Jetzt steh' ich bisschen auf dem Schlauch. Das mit der reg Datei ist klar, da hab ich schon einen Patch der je nach Setting in FHEMWEB http oder https macht, aber was meinst du mit "Browser"?
"hostname -f" sollte ja eben den "fully qualified" hostname ausgeben, aber das muss eben sauber konfiguriert sein. Bei unseren Kisten in der Arbeit passt das, aber bei selbstkonfigurierten Systemen ist das eher nicht der Fall.
Dazu kommt, dass bei der Verschlüsselung ja der Name ausschlaggebend ist, der im Zertifikat vergeben ist. Bei meiner Nginx Konfiguration hat das mit dem eigentlichen Hostnamen gar nichts zu tun (und nutzt noch dazu andere Ports).
Einzig halbwegs praktikable Lösung wäre mich also das in einem Attribut zu definieren - aber das machst du auch erst, wenn es zum ersten Mal schiefgegangen ist, und ob du dann die reg Datei editierst oder das Attribut setzt ist fast schon egal.
Puh, ist schon wieder ein Momentchen her, aber im Verlauf der Registrierung wird doch ein Link angezeigt, auf den man Klicken muss und die reg Datei sorgt dann nur dafür, dass dabei das richtige passiert, nämlich die PowerShell aufgerufen wir (oder so ;-)
Der Hostname passt bei mir zum Zertifikat, nur am Ergebnis von "hostname -f" bin ich noch dran. Wird auch mit "hostname" gesetzt, aber das will ich in einer ruhigen Minute machen, falls danach was nicht funktioniert.
Hallo Adimarantis,
ich benötige 2 Java-Versionen, die aktuelle für Signal, welche auch die primäre Java-Installation ist, und Java 8 für den Unifi-Controller.
Soweit so gut, es läuft alles perfekt. Gelegentlich, vermutlich nach einem Serverstart - ist derzeit nur eine Vermutung, "vergisst" Debian, dass JAVA 17 die primäre Installation ist. Damit läuft dann Signal nicht. Alles weiter nicht schlimm, da es einfach gefixt werden kann, bis auf den Umstand, dass ich nicht mit bekomme, wenn der obige Fall eintritt.
Hast du eventuell eine Idee, wie ein notify oder DOIF in Fhem aussehen müsste, wenn Signal nicht verbunden ist? Das könnte man ggf. noch abhängig vom Serverstart machen (letzteres hab ich schon umgesetzt). Was mir fehlt ist ein Event bei Signal, welches die nicht vorhandene Verbindung anzeigt.
Viele Grüße Gisbert
Also ich habe auf meinem Raspi (da noch unter "buster") standardmässig Java11.
D.h. wenn ich mich normal einlogge zeigt
java --version
openjdk 11.0.16 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Raspbian-1deb10u1)
OpenJDK Server VM (build 11.0.16+8-post-Raspbian-1deb10u1, mixed mode)
signal-cli geht aber trotzdem, da im /etc/systemd/system/signal.service das JAVA_HOME entsprechend auf /opt/java geändert wird, wo mein Java17 installiert ist.
Das sollte das Install Script eigentlich so einrichten. Wenn das so konfiguriert ist, sollte der Neustart eigentlich kein Problem mehr sein.
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME=/opt/java"
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
Hallo Adimarantis,
interessant, danke dir für diesen Hinweis.
Ich werde versuchen das umzusetzen, bin mir nur noch nicht sicher, ob ich es auf Anhieb hinbekomme.
Viele Grüße Gisbert
ich bin gerade dabei alles von meinem Raspi auf mein Synology NAS umzuziehen, wobei das letzte, was nun noch fehlt, der Signalbot ist (USB-to-Serial etc. läuft und MQTT ist ja auch sehr problemlos).
Weil der Separate Docker-Container nicht in Frage kommt, weil das Skript auf meinem Synology nicht läuft, dachte ich nun, dass ich einfach den Signalbot in dem FHEM-Container installiere. "sudo cpan install Protocol::DBus" hat auch funktioniert, allerdings hat das dazu geführt, dass nun FHEM gar nicht mehr startet mit der folgenden Fehlermeldung
connect(unix:path=/var/run/dbus/system_bus_socket): No such file or directory at /usr/local/share/perl/5.28.1/Protocol/DBus/Client.pm line 144.
Ich habe dann mal versucht, den DBus von Hand zu starten, damit er den Socket anlegt, was auch nicht geklappt hat.
Nachdem ich nun so ziemlich alles zum Laufen gebracht habe, wäre es schade, wenn's am Signalbot scheitert, vielleicht hat hier jemand eine pfiffige Idee, wie ich den Signalbot in meinem Dockercontainer (oder anderweitig) auf dem Synology NAS 918+ zum Laufen kriege?
Liest sich als wenn eine Library fehlt. Dbus im Container nach installieren ist ja auch nur bedingt hilfreich. Es muss ja persistiert werden.
Hast Du mal die Variante mit diesem Docker-Image (https://forum.fhem.de/index.php/topic,118370.msg1230534.html#msg1230534) versucht? Das funktioniert bei mir gut.
Hallo Adimarantis,
ich hab in /etc/systemd/system/signal.service folgendes eingetragen (bei mir liegt Java 17 dort):
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Ich hab dann den Server auf dem Fhem, Signal und der Unifi-Controller (und noch einiges mehr) läuft, neu gestartet.
Es läuft erstaunlicherweise alles.
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
java -version
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Debian-1deb11u1, mixed mode, sharing)
dpkg -l | grep "oracle\|openjdk"
ii openjdk-11-jre-headless:amd64 11.0.16+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-17-jdk:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK)
ii openjdk-17-jdk-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK) (headless)
ii openjdk-17-jre:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-17-jre-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
rc openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
Der Unifi-Controller lief erst nicht richtig und hat nach Java 11 verlangt, hab das dann installiert.
Anscheinend sind jetzt alle Services glücklich.
Viele Grüße Gisbert
Posts vom 31.8 – 3.September: Umstieg von SISI nach Signalbot
Hallo,
Ich habe mich jetzt getraut.
Installation ging mit dem Skript problemlos :)
Auch die erneute Registrierung der Festnetznummer über Capcha, ... klappte :)
Nun habe ich folgendes Problem:
Ich kann von meinen Handy auf FHEM (Festnetznummer) senden. Diese Nachrichten werden in FHEM angezeigt :)
Aber es gehen keine Nachrichten aus FHEM raus. ☹
Habe ich etwas übersehen oder mache ich etwas grundsätzliches falsch?
Es gibt keine Fehlermeldung; hier meine raw definition und das log.
Ein
set Signal_MSG send @+49xxxx gesedet aus FHEM(Festnetz)
liefert im Logfile:
2022.09.25 18:31:40 3 : Signal_MSG: Before parse:@+49xxxx gesedet aus FHEM(Festnetz):
Das reading sentMsgTimestamp bleibt auf pending....
Raw definition:
defmod Signal_MSG Signalbot
attr Signal_MSG defaultPeer +49xxxx
attr Signal_MSG room Monitoring
setstate Signal_MSG Connected to /org/asamk/Signal/_49xx
setstate Signal_MSG 2022-09-25 18:11:53 account +49xx
setstate Signal_MSG 2022-09-25 18:11:53 accountName
setstate Signal_MSG 2022-09-25 14:49:25 joinedGroups
setstate Signal_MSG 2022-09-25 18:11:53 lastError ok
setstate Signal_MSG 2022-09-25 18:29:20 msgAttachment
setstate Signal_MSG 2022-09-25 18:29:20 msgAuth 0
setstate Signal_MSG 2022-09-25 18:29:20 msgGroupName
setstate Signal_MSG 2022-09-25 18:29:20 msgSender 5b79b958-2c00-4b9f-9676-cf92cc83075c
setstate Signal_MSG 2022-09-25 18:29:20 msgText Noch ne Nachricht von meinem Handy
setstate Signal_MSG 2022-09-25 18:29:20 msgTimestamp 25-09-2022 18:29:17
setstate Signal_MSG 2022-09-25 18:29:20 prevMsgAttachment
setstate Signal_MSG 2022-09-25 18:29:20 prevMsgGroupName
setstate Signal_MSG 2022-09-25 18:29:20 prevMsgSender 5b79b958-2c00-4b9f-9676-cf92cc83075c
setstate Signal_MSG 2022-09-25 18:29:20 prevMsgText Gesendet von meinem Handy
setstate Signal_MSG 2022-09-25 18:29:20 prevMsgTimestamp 25-09-2022 18:28:35
setstate Signal_MSG 2022-09-25 18:31:40 sentMsg gesedet aus FHEM(Festnetz)
setstate Signal_MSG 2022-09-25 18:19:22 sentMsgRecipient 5b79b958-2c00-4b9f-9676-cf92cc83075c
setstate Signal_MSG 2022-09-25 18:31:40 sentMsgTimestamp pending
Ergänzungen:
root@rpi3-fhem:~# java -version
openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Raspbian-2deb10u1)
OpenJDK Server VM (build 11.0.12+7-post-Raspbian-2deb10u1, mixed mode)
INTERNALS
STATE Connected to /org/asamk/Signal/_49xx
VERSION Signalbot:3.10 signal-cli:0.9.2 Protocol::DBus:0.22
Model Raspbian GNU/Linux 10 (buster)
Zitat von: Flachzange am 25 September 2022, 13:55:34
Liest sich als wenn eine Library fehlt. Dbus im Container nach installieren ist ja auch nur bedingt hilfreich. Es muss ja persistiert werden.
Hast Du mal die Variante mit diesem Docker-Image (https://forum.fhem.de/index.php/topic,118370.msg1230534.html#msg1230534) versucht? Das funktioniert bei mir gut.
Das hatte ich nicht gefunden. Sehr hiflreich, vielen Dank!
edit: Ich habe zwischenzeitlich einmal das Git-Projekt geklont, die Dockerfile.x86 in Dockerfile umbenannt und Verzeichnisse angelegt, die in der docker-compose.yml verlinkt werden. Das bauen klappt auch soweit, es geht aber bei dem Image nicht weiter als "Starting signal_cli" und "Waiting for signal-cli to become read".
Um dem auf den Grund zu gehen, habe ich einmal den Befehl für den Start von signal-cli abgesetzt:
sudo -u fhem /opt/signal/bin/signal-cli --config /var/lib/signal-cli/data daemon --systemDabei kommt dann die Fehlermeldung
"Failed to read local accounts list" heraus, mit der ich nicht so viel anfangen kann. Klar, es gibt noch keine Accounts, weil das Ding gerade sauber neu aufgesetzt wurde. Ich weiß leider nicht wirklich weiter, wie ich das Teil zum Laufen bekommen soll und wäre dementsprechend sehr für noch ein wenig Hilfe dankbar!
Eventuell ein Zugriffsproblem auf /var/lib/signal-cli/data ?
Verzeichnis nicht lesbar/schreibbar für signal-cli oder gar nicht existent?
@oelkanne: kannst du mal verbose=5 einstellen und sehen ob was interessantes im Log steht?
Außerdem schreibt signal-cli in /var/log/syslog evtl. noch logs.
Versenden von Nachrichten ohne FHEM wie im Wiki beschrieben geht?
https://wiki.fhem.de/wiki/Signalbot#Versenden_von_Nachrichten_ohne_FHEM
@Adimarantis: Ersteinmal vielen Dank für deine Unterstützung!
Versenden von Nachrichten ohne FHEM (geht nicht)
root@rpi3-fhem:~# dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_49xx org.asamk.Signal.sendMessage string:Hallo array:string: string:+49xxxx
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
syslog:
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: Exception in thread "DBus Worker Thread-2" java.lang.NullPointerException
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.messages.Message.appendone(Message.java:569)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.messages.Message.append(Message.java:841)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.errors.Error.<init>(Error.java:87)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.errors.Error.<init>(Error.java:27)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.errors.Error.<init>(Error.java:98)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.connections.AbstractConnection.handleException(AbstractConnection.java:703)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at org.freedesktop.dbus.connections.AbstractConnection$2.run(AbstractConnection.java:843)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
Sep 27 19:04:33 rpi3-fhem signal-cli[446]: #011at java.base/java.lang.Thread.run(Thread.java:829)
fhemlog mit verbose 5:
2022.09.27 19:16:26 3 : Signal_MSG: Before parse:@+49xxxx gesedet aus FHEM(Festnetz):
2022.09.27 19:16:26 4 : Signal_MSG: sendMessage called for +49xxxx::gesedet aus FHEM(Festnetz)
2022.09.27 19:16:26 5 : Signal_MSG: Dbus Call sync:0 sendMessage(sasas) /org/asamk/Signal/_49xx Args:gesedet aus FHEM(Festnetz),ARRAY(0x6439120),ARRAY(0x5eeb0e8)
Zitat von: Adimarantis am 27 September 2022, 16:59:05
Eventuell ein Zugriffsproblem auf /var/lib/signal-cli/data ?
Verzeichnis nicht lesbar/schreibbar für signal-cli oder gar nicht existent?
oh man, das ist etwas peinlich. chown fhem:fhem hatte ich zwar gemacht, aber nicht mehr an die Permissions gedacht, die ich nun mal auf angepasst habe. Danke, dass du mir die Augen geöffnet hast :)
@oelkanne:
Ok, dann ist der FHEM/Signalbot Teil schon mal nicht die Ursache.
Nächster Test wäre dann, ob signal-cli von der Kommandozeile direkt funktioniert.
Ich habe dazu eine Beschreibung ins Wiki eingefügt (wo auch das mit Dbus steht).
@Adimarantis
der sysntax scheint nicht zu passen
root@rpi3-fhem:~# sudo service signal status
● signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-09-28 18:33:05 CEST; 4s ago
Main PID: 1673 (java)
Tasks: 32 (limit: 2200)
Memory: 89.9M
CGroup: /system.slice/signal.service
└─1673 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.9.2.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.69.ja
Sep 28 18:31:47 rpi3-fhem systemd[1]: Starting Send secure messages to Signal clients...
Sep 28 18:33:05 rpi3-fhem signal-cli[1673]: INFO DaemonCommand - Exported dbus object: /org/asamk/Signal/_49xx
Sep 28 18:33:05 rpi3-fhem systemd[1]: Started Send secure messages to Signal clients.
root@rpi3-fhem:~# sudo service signal stop
root@rpi3-fhem:~# sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49xx send -m "testmessage" +49xxxx
Benutzung: signal-cli [-h] [-v] [--verbose] [--config CONFIG] [-u USERNAME] [-o {plain-text,json}]
[--service-environment {live,sandbox}] [--trust-new-identities {always,on-first-use,never}] [--dbus |
--dbus-system]
{addDevice,block,daemon,getUserStatus,joinGroup,jsonRpc,link,listContacts,listDevices,listGroups,listIdentities,quitGroup,receive,register,remoteDelete,removeDevice,removePin,send,sendContacts,sendReaction,sendReceipt,sendSyncRequest,sendTyping,setPin,submitRateLimitChallenge,trust,unblock,unregister,updateAccount,updateConfiguration,updateContact,updateGroup,updateProfile,uploadStickerPack,verify}
...
signal-cli: Fehler: nicht berücksichtigte Argumente: '-c'
root@rpi3-fhem:~#
verändert liefert:
root@rpi3-fhem:~# sudo -u signal-cli /opt/signal/bin/signal-cli -u +49xx send -m "testmessage" +49xxxx
User +49xx is not registered.
und
root@rpi3-fhem:~# sudo -u fhem /opt/signal/bin/signal-cli -u +49xx send -m "testmessage" +49xxxx
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by com.fasterxml.jackson.databind.util.ClassUtil (file:/opt/signal/lib/jackson-databind-2.9.9.2.jar) to constructor java.util.Optional()
WARNING: Please consider reporting this to the maintainers of com.fasterxml.jackson.databind.util.ClassUtil
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
INFO ManagerImpl - The Signal protocol expects that incoming messages are regularly received.
Error while checking account +49xx: [401] Authorization failed!
root@rpi3-fhem:~#
Du verwendest noch 0.9.2. richtig?
Vielleicht ging da "-c" noch nicht - probier mal "--config"
Wenn es allerdings ein signal-cli Problem sein sollte, dann wirst du mit der alten Version sowieso Pech haben. Da kannst du kein Bug Ticket mehr aufmachen.
Du solltest dir überlegen Java17 und signal-cli 0.10+ zu installieren.
Ja, ist noch 0.9.2
mit --config
root@rpi3-fhem:~# sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49xx send -m "testmessage" +49xxxx
Failed to send message: null (UnregisteredUserException)
Dann geh ich erst mal wieder zurück.
Vielen Dank für deine Mühe!
Grüße
Oelkanne
Das schaut so aus, als wäre der Empfänger nicht korrekt registriert (falsche Nummer?)
..Nummer ist richtig.
Ich kann von verschiedenen Handys zur Raspberry senden. Aber es geht nicht umgegehrt.
Hallo zusammen,
bei mir hat heute ohne Fremdeinwirkung Signalbot/signal-cli aufgehört zu arbeiten. Mir ist es nur aufgefallen, da meine Nachrichten vom Handy an signal-cli nicht ankamen. Dann den umgekehrten Weg getestet, der aber auch nicht funktionierte. Im lasterror Reading stand grob so etwas wie "Keine Verbindung zum Ziel möglich". Von dem Fehler bei einer GroupMessage konnte ich noch einen Screenshot machen.
Nach einem Server-Neustart konnte signalbot die Nummer gar nicht anmelden und meldet sich wie beim initialen Start. Im signal.err sehe ich jetzt folgendes:
ZitatMultiAccountManager - Ignoring +49xxxxxxxx: Error while checking account ++49xxxxxxxx: StatusCode: 499 (AccountCheckException)
ZitatInternals:
FD 15
FUUID 613c63f7-f33f-fd7e-6ada-9e7d51101d69eb3e
NAME Signalbot
NOTIFYDEV global
NR 353
NTFY_ORDER 50-Signalbot
STATE Connected to /org/asamk/Signal
TYPE Signalbot
VERSION Signalbot:3.10 signal-cli:0.10.9 Protocol::DBus:0.22
eventCount 2
model Debian GNU/Linux 11 (bullseye)
Helper:
DBLOG:
account:
logdb:
TIME 1665075173.77501
VALUE none
joinedGroups:
logdb:
TIME 1665075173.77501
VALUE
lastError:
logdb:
TIME 1665075173.77501
VALUE No account registered - use set account to connect to an existing registration, link or register to get a new account
READINGS:
2022-10-06 18:52:53 account none
2022-10-02 12:06:45 accountName FHEM
2022-10-06 18:52:53 joinedGroups
2022-10-06 18:52:53 lastError No account registered - use set account to connect to an existing registration, link or register to get a new account
2022-10-05 14:33:51 msgAttachment
2022-10-05 14:33:51 msgAuth 0
2022-10-05 14:33:51 msgGroupName SmartHome
2022-10-05 14:33:51 msgSender Sarah
2022-10-05 14:33:51 msgText fav2
2022-10-05 14:33:51 msgTimestamp 05-10-2022 14:33:50
2022-10-05 14:33:51 prevMsgAttachment
2022-10-05 14:33:51 prevMsgGroupName SmartHome
2022-10-05 14:33:51 prevMsgSender Sarah
2022-10-05 14:33:51 prevMsgText fav2
2022-10-05 14:33:51 prevMsgTimestamp 05-10-2022 12:46:51
2022-10-06 18:10:46 sentMsg Kontakte offen: Kontakt_Haus_EG_Eingang_Kueche
2022-10-05 23:53:19 sentMsgRecipient Sarah
2022-10-06 18:10:46 sentMsgTimestamp pending
helper:
accounts 0
init 1
multi 1
qr
register
signalpath /org/asamk/Signal
verification
version 1009
accountlist:
Attributes:
authDev googleAuth
authTimeout 300
cmdKeyword /
cmdKeywordNoAuth -
cmdPatternNoAuth get .*;trigger .*;getstate .*
favList ...
favPrefix fav
room Messaging
userattr cmdKeywordNoAuth cmdPatternNoAuth favPrefix favList
Hat da jemand eine Idee?
Kann ich auch bei mir auch nachvollziehen.
Ich vermute, dass es einen mismatch zwischen signal-cli version und dem Signal Server gibt.
In signal-cli 0.11.2 hat asamK einen neue Fehlermeldung für "signal-cli outdated" eingeführt - deutlicher Hinweis darauf, das es hier wohl Probleme gibt/gab.
Ich teste mal ob ein upgrade auf v0.11.2 das Problem behebt und melde mich wieder.
Jörg
Also ich hab auch heute keine Nachrichten mehr erhalten.
Als erstes wollte ich mit der 0.10.2er Version ein Reregister durchführen, was aber nicht mehr funktioniert hat.
Danach hatte ich signal-cli auf 0.11.2 geupdatet, danach konnte ich per cli ein Register durchführen.
Allerdings hatte ich beim Signalbot vergessen ein Reinit zu machen, und er wollte immer noch ein Captcha haben.
Nach dem Reinit war natürlich mein Register flöten gegangen und jetzt kann ich mich nicht mehr registrieren, wegen zu vielen Versuchen (Failed to register: [413] Rate limit exceeded: 413) :'(
Weiß jeman wie lange man für einen neuen Versuch waren muss?
Gruß
Rubinho
So, hab bei mir das update auf V0.11.2 jetzt auch geschafft (musste die libraries für Raspberry erst neu übersetzen, was eine Weile dauert).
Nach set reinit, set signalAccount war ich wieder online.
Ich arbeite mich jetzt noch durch die restlichen Architekturen und stelle dann die libraries und ein neues Install script online.
Damit dürfte die Version 0.9.2. die noch Java11 unterstützt leider Geschichte sein und es bleibt nur eine entsprechende Java17 Installation zu machen.
Gibt es einen besonderen Trick, wie man auf 11.2 kommt? Ich hatte 10.2 und beim update komme ich nicht weiter:
Okt 06 20:57:54 raspfhem signal-cli[10672]: at org.asamk.signal.App.buildArgumentParser(App.java:106)
Okt 06 20:57:54 raspfhem signal-cli[10672]: at org.asamk.signal.Main.main(Main.java:54)
Okt 06 20:57:54 raspfhem signal-cli[10672]: Caused by: java.lang.ClassNotFoundException: org.asamk.signal.manager.api.NotPrimaryDeviceException
Okt 06 20:57:54 raspfhem signal-cli[10672]: at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
Okt 06 20:57:54 raspfhem signal-cli[10672]: at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
Okt 06 20:57:54 raspfhem signal-cli[10672]: at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
Okt 06 20:57:54 raspfhem signal-cli[10672]: ... 3 more
Okt 06 20:57:54 raspfhem systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Okt 06 20:57:54 raspfhem systemd[1]: signal.service: Failed with result 'exit-code'.
Okt 06 20:57:54 raspfhem systemd[1]: Failed to start Send secure messages to Signal clients.
Zitat von: Adimarantis am 06 Oktober 2022, 20:28:16Ich arbeite mich jetzt noch durch die restlichen Architekturen und stelle dann die libraries und ein neues Install script online.
Damit dürfte die Version 0.9.2. die noch Java11 unterstützt leider Geschichte sein und es bleibt nur eine entsprechende Java17 Installation zu machen.
Super. Dank Dir. Gerne die libs schon mal pushen, sollte es mit dem Skript länger dauern.
Update auf signal-cli 0.11.2
Dieses Update ist zwingend erforderlich, da sich anscheinend intern etwas beim Signal Server verändert hat.
Ich habe zwar Signalbot auch aktualisiert, aber neu ist nur dass er bei Versionen <0.11.2 meckert. Es ist nur ein signal-cli update notwendig.
Vorgehensweise:
1. in FHEM
set reinit
Sollte das aktuelle Install script nach www/signal laden - zur Kontrolle: SCRIPTVERSION="3.10"
2. in der Shell im Verzeichnis www/signal
sudo -E ./signal_install.sh
Installation durchführen, alte signal-cli version überschreiben.
Achtung an alle V0.9.2 und Java11 Nutzer - update auf Java17 ist notwendig!
3. wieder in FHEM
set reinit
Sollte das Account nicht mehr gesetzt sein, mit
set signalAccount <nummer>
neu setzen.
Danach sollte eigentlich alles wieder funktionieren.
Zitat von: Adimarantis am 06 Oktober 2022, 21:38:49
Update auf signal-cli 0.11.2
Danach sollte eigentlich alles wieder funktionieren.
Super! Geht wieder :) Danke!
Gruss
Enno
Yay. Läuft auch bei mir wieder nachdem ich diverse Docker-Issues überwunden habe. Danke für den schnellen Fix @Jörg
Bei mir funktioniert es leider nicht.
Im Anschluss an sudo -E ./signal_install.sh
Kommt irgendwann
ZitatJob 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.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Im Detail passt passen die anderen Meldungen. Es scheint irgendwie mit "Failed to activate service 'org.asamk.Signal'" zusammenzuhängen.
Zitatsystemctl 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 Thu 2022-10-06 22:59:51 CEST; 34s ago
Process: 3422 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=2)
Main PID: 3422 (code=exited, status=2)
Okt 06 22:59:51 myfhem signal-cli[3422]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Okt 06 22:59:51 myfhem signal-cli[3422]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Okt 06 22:59:51 myfhem signal-cli[3422]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.jav
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.App.init(App.java:191)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.Main.main(Main.java:60)
Okt 06 22:59:51 myfhem systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Okt 06 22:59:51 myfhem systemd[1]: signal.service: Failed with result 'exit-code'.
Okt 06 22:59:51 myfhem systemd[1]: Failed to start Send secure messages to Signal clients.
Zitatpi@myfhem:/opt/fhem/www/signal $ journalctl -xe
Okt 06 22:59:51 myfhem signal-cli[3422]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Okt 06 22:59:51 myfhem signal-cli[3422]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.jav
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.App.init(App.java:191)
Okt 06 22:59:51 myfhem signal-cli[3422]: at org.asamk.signal.Main.main(Main.java:60)
Okt 06 22:59:51 myfhem systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit signal.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 2.
Okt 06 22:59:51 myfhem systemd[1]: signal.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service has entered the 'failed' state with result 'exit-code'.
Okt 06 22:59:51 myfhem systemd[1]: Failed to start Send secure messages to Signal clients.
-- Subject: A start job for unit signal.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 949 and the job result is failed.
Okt 06 23:00:04 myfhem dbus-daemon[362]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Okt 06 23:00:04 myfhem sudo[2709]: pam_unix(sudo:session): session closed for user root
Okt 06 23:01:57 myfhem dhcpcd[629]: eth0: Router Advertisement from fe80::de39:6fff:fecb:5811
Viele Grüße
Guido
Moin, bei mir läufts auch wieder, allerdings nur durch die Hintertür.
Mir ist es einfach nicht gelungen über Fhem/Signalbot ein Register durchzuführen.
Signalbot akzeptierte das Captcha (signalcaptcha://signal-recaptcha-v2.6...) einfach nicht. Es kam die typische Fehlermeldung "Incorrect captcha - e.g. needs to start with signalcaptcha:// "
Ich musste die Registrierung wieder über CLI machen. Jetzt funktioniert das versenden der Nachrichten wieder, allerdings steht jetzt bei Signalbot oben "signal-cli v0.9.0+ required"
Obwohl alles funktioniert, meint wohl Signalbot dass ich kein Signal-Cli installiert habe (Oder war das schon immer so? ::) )
Eventuell liegt es aber auch daran, dass ich das Register über CLI durchgeführt habe, oder es liegt an der neuen signal-cli Version.
Das hier spuckt Signalbot als Version aus.... Signalbot:3.10 signal-cli:Protocol::DBus::Type::Array=ARRAY(0x5606d9929278) Protocol::DBus:0.22
Gruß
Rubinho
Zitatallerdings steht jetzt bei Signalbot oben "signal-cli v0.9.0+ required
Das hatte ich auch. Nach einem
set reinit war es weg
@fettgu:
Von welcher signal-cli version hast du geupdated? Vielleicht ist deine config zu alt und er hat den Umstieg nicht geschafft. Dann wäre die alte config unter /var/lib/signal-cli am Besten ganz zu löschen und die Nummer neu zu registrieren.
Eventuell gibt ein Test rein auf der Kommandozeile mehr Aufschluss:
sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49<registrierte Nummer> send -m "testmessage" +49<Empfänger>
Unter welchem OS und welcher HW bist du?
cat /etc/os-release
uname -a
arch
@rubinho:
Sehr seltsam. Er bekommt für die Version ein Array statt einem String - daher meint er du bist auf Version 0
Die Grundfunktionalität sollte glaube ich da sein, aber einige set/get Befehle werden deaktiviert wenn die Version nicht stimmt.
Aber vielleicht hilft ja ein Neustart?
Wenn nicht, an dich die selbe Frage wie oben nach OS und Architektur.
Also bei mir hat das update leider auch nicht richtig geklappt, der Service startet nicht mehr.
sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49<registrierte Nummer> send -m "testmessage" +49<Empfänger>
liefert
[codeError loading state file for user +49<registrierte Nummer>: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null (NullPointerException)][/code]
Ich nutze einen Raspi 4 mit
pi@raspiX:~/.config $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
kein Docker.
Java17 wurde vom Install Skript installiert. Darf die alte Java11 daneben zusätzlich installiert bleiben?
Gleiches Problem: Trotz der hier angegebenen Lösungsansätze startet der Service nicht mehr:
Okt 07 12:08:18 dell signal-cli[7860]: ERROR MultiAccountManager - Failed to load +49meineNummerhier: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null (NullPointerException)
Okt 07 12:08:18 dell signal-cli[7860]: java.lang.NullPointerException: Cannot invoke "org.whispersystems.signalservice.api.push.ServiceId.toByteArray()" because "serviceId" is null
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.storage.identities.IdentityKeyStore.loadIdentity(IdentityKeyStore.java:197)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.storage.identities.IdentityKeyStore.saveIdentity(IdentityKeyStore.java:61)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.storage.SignalAccount.setPniIdentityKeyPair(SignalAccount.java:1365)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:406)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:182)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:93)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:65)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Okt 07 12:08:18 dell signal-cli[7860]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:73)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.App.init(App.java:191)
Okt 07 12:08:18 dell signal-cli[7860]: at org.asamk.signal.Main.main(Main.java:60)
Okt 07 12:08:18 dell systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit signal.service has exited.
░░
░░ The process' exit code is 'exited' and its exit status is 2.
Okt 07 12:08:18 dell systemd[1]: signal.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit signal.service has entered the 'failed' state with result 'exit-code'.
Okt 07 12:08:18 dell systemd[1]: Failed to start Send secure messages to Signal clients.
░░ Subject: A start job for unit signal.service has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit signal.service has finished with a failure.
░░
░░ The job identifier is 1775 and the job result is failed.
Okt 07 12:08:18 dell systemd[1]: signal.service: Consumed 5.376s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit signal.service completed and consumed the indicated resources.
Irgendwas scheint mit dem zugrunde liegenden Service nicht ok. Hat jemand eine Idee, wie man Abhilfe schaffen kann?
Gruß, Heiko
Ich befürchte, dass die vorgenannten Probleme von einem zu großen Versionssprung bei signal-cli kommen.
Die Konfigurationsdaten wurden mit der Zeit erweitert und sind wahrscheinlich nur bis zu einem gewissen Punkt rückwärtskompatibel.
Man könnte jetzt vielleicht nach und nach neuere signal-cli versionen installieren und anstarten in der Hoffnung, dass die Config dabei migriert wird.
Aber ich denke es wird das Beste sein alle Daten unter /var/lib/signal-cli zu löschen (bzw. auch wegzusichern) und die Nummer neu zu registrieren.
Ok danke, sehe ich mir gleich mal an.
Was mir gerade noch aufgefallen ist:
pi@raspi1:~/.config $ systemctl cat signal.service
# /etc/systemd/system/signal.service
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME="
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
Die Environment-Zeile für JAVA_HOME kommt mir komisch vor, soll das wirklich so sein?
Re Java Version:
Wenn ich Testweise Java11 verwende bekomme ich folgenden Fehler:
/opt/signal/bin/signal-cli --version
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
Daher gehe ich mal davon aus, das euere Fehler nicht auf eine falsche Java Version zurückzuführen sind.
Der Eintrag
Environment="JAVA_HOME="
führt einfach dazu, dass JAVA_HOME auf leer gesetzt wird, womit der System Standard angezogen wird.
Auf meinem "buster" system mit eigener Java version schaut es dann so aus:
Environment="JAVA_HOME=/opt/java"
Oh Mann, hier mal ein dummer Tipp (oder guter Tipp für dumme User?): Man darf das Installations-Script natürlich nicht einfach (in der alten Version) neu aufrufen, sondern muss es vorher neu in das Verzeichnis runterladen, in dem man es ausführt. Vielleicht passiert das nur mir, aber die Fehlermeldungen passen zu einigen aus den vorherigen Beiträgen.
Zitat von: Adimarantis am 07 Oktober 2022, 07:16:01
@rubinho:
Sehr seltsam. Er bekommt für die Version ein Array statt einem String - daher meint er du bist auf Version 0
Die Grundfunktionalität sollte glaube ich da sein, aber einige set/get Befehle werden deaktiviert wenn die Version nicht stimmt.
Aber vielleicht hilft ja ein Neustart?
Wenn nicht, an dich die selbe Frage wie oben nach OS und Architektur.
Habe gerade ein Update auf Signalbot 3.11 durchgeführt und danach ein restart von Fhem.
Jetzt wird wieder alles erkannt. Was jetzt die Lösung war kann ich nicht sagen. Ist mir aber auch egal ;D
PS.
Mein OS ist Ubuntu 22.04 64bit Arch ist x86_64
signal-cli-0.11.3 ist vor 2 Stunden bereitgestellt worden.
Installer update 3.11
Der Author von signal-cli hat gerade signal-cli 0.11.3 veröffentlicht.
Dort ist ein Commit enthalten der "Fix update from old versions without PNI" heisst.
Möglicherweise ist das der Grund warum so viele Probleme mit der Config hatten und ihre Nummer neu registrieren mussten.
Da diese Version die selben native libraries verwendet, habe ich einen schnellen Patch des Installers online gestellt, der 0.11.3 mit den 0.11.2 libs installiert.
Vielleicht erspart das einigen die noch nicht upgedated haben die erneute Registrierung.
Vorgehen wie gehabt: "set reinit" um den neuen Installer nach www/signal zu laden, mit "sudo -E ./signal_install.sh" ausführen.
Anmerkung:
- Der neue Installer updated Dbus auf 0.22 - das kann etwas dauern
- Die signal.service Datei bekommt ein paar Änderungen, die race conditions beim Neustart verhindern sollen. Muss man nicht unbedingt übernehmen.
Wunderbar, zwei Updates innerhalb 24 Stunden. So bleibt man in Übung :D
Das neue Update auf 11.3 hat das Problem bei mir gelöst, ich kann jetzt wunderbar mit der "alten" Konfiguration weitermachen.
Vielen Dank für die Unterstützung!
Zitat von: Adimarantis am 07 Oktober 2022, 19:25:47
Installer update 3.11
Der Author von signal-cli hat gerade signal-cli 0.11.3 veröffentlicht.
Leider macht das Update von signal-cli die Installation auf Ubuntu 18.04 LTS kaputt. Die fertigen Packages wollen alle glibc >= 2.28, im System steckt 2.27. Die alternative Repo für die libsignal_jni, siehe https://github.com/exquo/signal-libs-build/ funktioniert seit Monaten nicht mehr. Selber kompilieren der libsignal-client Library hängt sich mit einem cmake Fehler weg, weil die Version die --parallel Option, die Rust verwendet, noch nicht unterstützt. Und der Patch für die cmake Rust lib, der das korrigiert, ist noch nicht in das Haupt Repository übernommen worden. Dependency Hell vom feinsten.
Ich habs gerade echt soo satt. >:(
Zitat von: weini am 07 Oktober 2022, 19:38:46
Das neue Update auf 11.3 hat das Problem bei mir gelöst, ich kann jetzt wunderbar mit der "alten" Konfiguration weitermachen.
Vielen Dank für die Unterstützung!
Das hat's bei mir auch gebracht. Alles geht wieder!
Ich sage "herzlichen Dank" für den Support.
Gruß, Heiko
@sukram:
Das Cmake --parallel Problem hatte ich auch unter Raspbian Buster.
Dafür habe ich mir die aktuelle cmake version geholt und drüberkopiert - dann hats geklappt.
Schau mal unter
https://apt.kitware.com/
Da scheint es apt packages für Ubuntu 18.04 zu geben.
Probiere ich später vielleicht selber. Falls du eine entsprechende library übersetzt bekommst, nehme ich sie gerne in mein repository/installer auf.
wie habt ihr das update von signal-cli gemacht? mit signal_install.sh?
@sukram: gerade festgestellt, das meine amd64-2.28 eigentlich ein 2.27 ist. Probier die lib einfach.
Ich übersetze gerade noch eine echte 2.28 - zum Glück funktionieren 2.27 binaries üblicherweise auch mit glib2.28
@FhemPiUser: lies bitte mal ein paar Posts zurück, das ist wirklich oft genug beschrieben
sorry, danke. Update hat nach Anleitung geklappt.
Zitat von: Adimarantis am 07 Oktober 2022, 20:26:39
@sukram: gerade festgestellt, das meine amd64-2.28 eigentlich ein 2.27 ist. Probier die lib einfach.
Ich übersetze gerade noch eine echte 2.28 - zum Glück funktionieren 2.27 binaries üblicherweise auch mit glib2.28
Ich glaube, das hat funktioniert ;D Vielen DANK! Das hat mir den Abend gerettet 8)
Okt 07 20:50:21 gpa systemd[1]: Starting Send secure messages to Signal clients...
-- Subject: Unit signal-cli.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit signal-cli.service has begun starting up.
Okt 07 20:50:33 gpa signal-cli[3521]: INFO DaemonCommand - Starting daemon in multi-account mode
Okt 07 20:50:33 gpa signal-cli[3521]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket to connect to unix:path=/var/run/dbus/system_bus_so
Okt 07 20:50:34 gpa systemd[1]: Started Send secure messages to Signal clients.
-- Subject: Unit signal-cli.service has finished start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit signal-cli.service has finished starting up.
--
-- The start-up result is RESULT.
Okt 07 20:50:34 gpa signal-cli[3521]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
Hallo Adimarantis,
bei mir bricht die Installation nach Eingabe von
sudo -E ./signal_install.sh
mit folgendem Eintrag ab (vorher set reinit in Fhem ausgeführt):
Checking system Java version ... ./signal_install.sh: line 282: /usr/lib/jvm/java-8-openjdk-amd64/jre//bin/java: No such file or directory
Installing openjdk-17-jre-headless...failed
Ich kann noch folgende Informationen liefern:
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
dpkg -l | grep "oracle\|openjdk"
ii openjdk-11-jre-headless:amd64 11.0.16+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-17-jdk:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK)
ii openjdk-17-jdk-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK) (headless)
ii openjdk-17-jre:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-17-jre-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
rc openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
nano /etc/systemd/system/signal.service liefert:
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
Wo muss ich ansetzen, um Signal upzudaten?
Viele Grüße Gisbert
Zu allem Überfluss habe ich mir auch Signal in Fhem zerschossen:
Your registration for +492143103913 requires a Captcha to succeed.
Ich kann aber kein Captcha erzeugen, die PoweShell ist schneller zu als man kucken kann.
Danke @Adimarantis
Das neue Installationsskript hat es gelöst. Ich habe sonst nichts gemacht.
Zur Ausgangslage
sudo -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -u +49xxx send -m "testmessage" +49xyz
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
pi@myfhem:~ $ uname -a
Linux myfhem 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
Viele Grüße
Guido
Hallo Adimarantis,
ich habe ein Problem mit Captcha.
Sobald ich den Link ausführe, öffnet sich die PowerShell, nur um kurz danach wieder zu schließen.
Im Browser steht dann das:
ZitatFehler: Verbindung unterbrochen
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website könnte vorübergehend nicht erreichbar sein, versuchen Sie es bitte später nochmals.
Wenn Sie auch keine andere Website aufrufen können, überprüfen Sie bitte die Netzwerk-/Internetverbindung.
Wenn Ihr Computer oder Netzwerk von einer Firewall oder einem Proxy geschützt wird, stellen Sie bitte sicher, dass Firefox auf das Internet zugreifen darf.
Die URL sieht dann so aus:
Zitathttp://192.168.1.46:8083/fhem?cmd= Signa captcha signalcaptcha://signal-recaptcha-v2.6LfBXs0bAAAAAAjkDyyI1Lk5gBAUWfhI_bIyox5W.registration.03AIIukzhM8yfqB066HwlWwhcPlsNtCUzUPiowgpg2iJLvpgJOvQaT4F2DDDRUDS751kV_bmyQaJIAADWy7b1wo_dyncQut1XRuWqmsZCQv5yggWCEyxqPuszUrv0OUc2nanVxWKrccY3bS2t7w6ifk0tvmmeHF-tRNYOvSSDcjP0toD_7JT2-FA4FydXacKNPAooFgDsHXGED64WP8mLrlrV4D-OVzYorOrd_amvsXu-3SvFn-4pPZElY7xq2iwENia3lsjC71rlwZIuV8PDjtHM-OSmdn1nYbgBbR4wucbHKff3xLibDLiiYHWPewvlagbh2ieTMx8EhvGBZVoWwel7aYUQshAeToROKdTdEEHZbCjAso4pPlIK0bXjtgOSV4kIQ9WjMD4qC5JP4ydhs18vD9aCwQQJg_XqMK5oqPUpqTYzFoKNQVSCZgkDF3h_fXxKkh5Y_DOCqYzTApK_woXKLw1BeShyONPPbrJPyiuFm4rabmCU9ecYQ0ZFNbeyw77J7J2whCOOMkN9MqD9ZTdWEP3oY5odTLoyqfmjNgILHW09G_sa1BGt5A6H6VUn-olHucNsSiIXN2DgCFontXvi8G5yqGY9oqIXWi4xPpNF9ThH5e-hMAHN744-z82S4OQiL8kmA3I9OnuzfWc3w04pdeaeDBL6KNZxwG2fuxeGkusltTBchJDFQYC9ZmejCkyXrsD0t6FYh-CBOrRTWDJyOf9B8QYXeBa5FrnAhOlAnE121qJeDWspqLu3E6TpYfG0LcUox3gJ4VdCerH0-cvHBvFnziKVXZhM7-wMCCaVd5LuQKSDbF-xZE7tRAzWJuy_iXdmdZ1wHFs4TiIId9-LrDr4k7uGYjIdSoI1uLK8h1HAXsKB6I5rnc2mihxjIoeefWsSBYEqDvZ5AMF7shxCdB-H-5liCs1miG4HRXgW-KwDoGn0Ef7x35hZ8BGF3G73cvrvwC7R_tdf2kWMBP7AYr3AokPmKNSrnPTLOyaBUGxjaIgJPtcPfrFPxU0EdCU795lPQmbxVemteQvBdsKagaCo3pf1u4OXDecaStGswjdht-Esu-3_aWDMN9uEQMUom0ShTio1SDQ4oK4O34mHUHQLKy63UF5IMhJlxm4VnV39EspoymiVrKicGIdHD2yTFiLhwlrBsmOrygJTrFwuB9VNeGvxoY1UQoNYifekTg3yHXd6MMe7OLjiN2wrEUDit103XdJraCpV98PHGWYWDxGcppZ6wXrxrXSrX_LwcCKCsxpOIi2U&fwcsrf=csrf_559413525547127
F12/Konsole ist komplett leer.
Ich hänge an dieser Stelle, was kann ich tun?
Viele Grüße Gisbert
@Gisbert:
Mach bitte vor der Installation
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
Du bringst mein Script durcheinander, weil er feststellt dass du Java17 auf deinem System hast, es aber nicht Default ist.
Zum Captcha. Das ist grundsätzlich ja erstmal ok, die Powershell macht ja das F12 und copy & paste überflüssig, allerdings:
http://192.168.1.46:8083/fhem?cmd= Signa captcha signalcaptc....
Da sollte eigentlich "...cmd=set Signaldevice captcha signal....." stehen, wobei "Signaldevice" der Name deines FHEM Device ist - wie heisst das denn bei dir, vielleicht springt da die Ersetzung versehentlich falsch an?
Zumindest kannst du probieren die URL entsprechend zu editieren - dann sollte es eigentlich gehen.
Edit: Schau dir mal die Datei www/signal/signalcaptcha.reg an, ob das dort vernünftig aussieht (%%20 sind Leerzeichen)
Hallo Adimarantis,
nachdem ich
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64ausgeführt hatte, und das Captcha erneut ausgeführt hatte, läuft Signal wieder :)
Ich kann wieder Nachrichten versenden, die auch ankommen.
www/signal/signalcaptcha.reg sieht so aus, mein Signaldevice heißt unglücklicherweise "Signal" (ich werde das aber jetzt ändern etwas individuelles):
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\signalcaptcha]
@="URL:signalcaptcha"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\signalcaptcha\shell]
[HKEY_CLASSES_ROOT\signalcaptcha\shell\open]
[HKEY_CLASSES_ROOT\signalcaptcha\shell\open\command]
@="powershell.exe Start-Process -FilePath ( $('http://192.168.1.46:8083/fhem?cmd=set%%20Signal%%20captcha%%20'+($('%1')+$('&fwcsrf=csrf_559413525547127') -replace '^(.*)/&','$1&') ) )"Im Signaldevice steht noch:
Zitatsignal-cli v0.11.2+ required.
Please use installer to install or update
Note: The installer only supports Debian based Linux distributions like Ubuntu and Raspberry OS
and X86 or armv7l CPUs
You can download the installer here or your www/signal directory and run it with
sudo ./signal_install.sh
Das steht unter Internals:
ZitatVERSION Signalbot:3.11 signal-cli:Protocol::DBus::Type::Array=ARRAY(0x55eb815c1518) Protocol::DBus:0.22
Viele Grüße und allerliebsten Dank
Gisbert
Das Problem mit der Versionen hatte schon jemand. Dort hatte ein Neustart geholfen.
Zitat von: Adimarantis am 08 Oktober 2022, 09:17:51
Das Problem mit der Versionen hatte schon jemand. Dort hatte ein Neustart geholfen.
Das hat geholfen :) :) :)
@Adimarantis
Ich muss mal wieder das Thema Docker ansprechen.
Jedes mal wenn Signal irgendwas ändert wird dieser Thread schlagartig akiv und oftmals muss du viele Fragen doppelt beantworten.
Wäre es nicht sinnvoller das ganze signal-cli Gedöns in einen Container zu stecken und mittels Signalbot den Container aussteuern. (Ich weiß du bist da dran)
Mit dem Container hättest du eine homogene Umgebung und würde vielfältige Probleme reduzieren. Du könntest auch auf den fertigen Container signal-cli-rest-api (https://github.com/bbernhard/signal-cli-rest-api) zurückgreifen.
Damit könnte man einen zentralen Signal Server aufbauen das von mehreren Systemen genutzt werden kann.
Nur so als Vorschlag.
ZitatWäre es nicht sinnvoller das ganze signal-cli Gedöns in einen Container zu stecken und mittels Signalbot den Container aussteuern.
Na klasse, und was machen die, die keine Container haben, u.a. weil sie es gerade mal geschafft haben einen Raspi oder einen Server mit Debian einzurichten?
Bitte versteht mich nicht falsch, ich stelle keine Forderungen, denn ich nutze das, was Adimarantis in seiner Freizeit uns zur Verfügung stellt, sehr gerne.
Eine Lösung, die auch die mitnimmt, die sich mit Linux nicht sehr gut auskennen, würde mir besser gefallen.
Viele Grüße Gisbert
Umstieg von SISI nach Signalbot
@Gisbert
...gerade mal geschafft haben einen Raspi oder einen Server mit Debian einzurichten...Eine Lösung, die auch die mitnimmt, die sich mit Linux nicht sehr gut auskennen, würde mir besser gefallen.
Da kann ich dir gar nicht genug zustimmen!. Ich gehöre zu dieser Gruppe und bin sehr froh dass ihr Profis soche wie mich abholt und mitnimmt.
@Adimarantis
Deine Srciptversion 3.12 mit signal-cli:0.11.3 und java 17 löste auch mein Problem mit den ausgehenden Nachrichten.
Deshald: Umstieg (Raspberry Pi3 mit Buster) von SISI nach Signalbot funktioniert mit dem Script vollständig!
Viele Grüße und ein super dickes DANKESCHÖN!
Zitat von: Gisbert am 10 Oktober 2022, 18:02:38
Na klasse, und was machen die, die keine Container haben, u.a. weil sie es gerade mal geschafft haben einen Raspi oder einen Server mit Debian einzurichten?
Windows installieren und irgendetwas anderes als FHEM benutzen? Mal ernsthaft: Wenn es nicht Container sind, die Dich abhängen, dann ist die nächste Technologie. Container haben eigentlich nichts mit Linux zu tun, auch wenn sie da natürlich vornehmlich auftreten und ehrlich gesagt sollte es Dir damit sogar viel leichter fallen ein lauffähiges FHEM schnell zu deployen.
Zitat von: Gisbert am 10 Oktober 2022, 18:02:38
Eine Lösung, die auch die mitnimmt, die sich mit Linux nicht sehr gut auskennen, würde mir besser gefallen.
Ist die Lösung nicht eher, sich mehr mit Linux vertraut zu machen? Adimarantis macht hier einen Mordsjob und hat eine mehr oder wenige out-of-the-box-Lösung geschaffen, aber es wird aufgrund von so vielen Faktoren immer wieder Probleme geben, bei denen man selber "Hand anlegen" muss und auch zumindest in groben Zügen verstehen, was da so im Hintergrund passiert. Ich bin auch wahrlich kein Profi, aber mit der Zeit muss man sich einfach etwas reinfuchsen.
Und der Vorschlag rubinho schlägt ja genau in diese Kerbe. Ich bin mir nicht sicher, ob er die viele Kommentare und Nachfragen nach so einem Update verhindert hätte, aber damit könnte man zumindest einfach und schnelle einen Fix für die breite Masse bereitstellen ohne dass jeder selber das Update händisch durchführt.
@Gisbert
Meine Intension war/ist ja die Sache für alle Beteiligten einfacher zu machen.
Mir ist auch klar, dass die meiste Arbeit an Adimarantis hängen würde, sofern er dies machen würde.
Auch kenne ich nicht alle Fallstricke die mit einem Umstieg auf Docker verbunden sind. Allerdings sehe ich, seitdem ich mich mit Docker auseinandersetze die enormen Vorteile. Man muss sich keine Gedanken mehr über Abhängikeiten, Versionsunterschiede oder Wechselwirkungen machen.
Ja Adimarantis Script funktioniert in der Regel auf einem frischen System tadelos, aber bei eingefahrenen Systemen kann es das ein oder andere Mal zu Problemen kommen auf die Adimarantis keinen Einfluss hat.
Und ehrlich, ein Docker mitsamt eines Containers aufzusetzen ist nicht komplizierter, wie das Ausführen des bisherigen Scriptes.
Wie schon geschrieben, es soll nur ein Denkanstoß sein um es auf Dauer einfacher zu machen, nicht komplizierter.
Wenn die Realisierung zu kompliziert ist, oder entscheidende Nachteile dadurch entstehen, kann ich auch sehr gut mit der vorhandenen Lösung leben.
Gruß
Rubinho
Hi,
irgendwie habe ich meine Signalbot installation zerschossen :-(
Also dachte ich mir ich lade mir das neuste install script auf meinen PI aber dort bekomme ich dann folgenden Fehler:
ZitatChecking user fhem ...found
Downloading Java from adoptium...successful
Unpacking ...tar (child): OpenJDK17U-jre__linux_hotspot_17.0.4.1_1.tar.gz: Funktion open fehlgeschlagen: Datei oder Verzeichnis nicht gefunden
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
mv: der Aufruf von stat für 'jdk*' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
rm: das Entfernen von 'OpenJDK17U-jre__linux_hotspot_17.0.4.1_1.tar.gz' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
done
./signal_install.sh: Zeile 305: /opt/java/bin/java: Datei oder Verzeichnis nicht gefunden
./signal_install.sh: Zeile 330: /opt/java/bin/java: Datei oder Verzeichnis nicht gefunden
Error: Java found, but Java 17.0 required
Something went wrong that this script cannot resolved - please fix manually
Zitatpi@raspberrypi:~ $ whoami
pi
pi@raspberrypi:~ $
ZitatPRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Ich starte das install script mit
sudo ./signal_install.shWenn ich die Passage in dem script richtig verstehe wird java nach /opt heruntergeladen aber ich kann dort nichts sehen was java betrifft.... :(
Gruß
Christian
Was gibt bei dir der Befehl
arch
aus?
Das Script erwartet hier entweder armv7l or x86_64 - und hat wohl leider keine Fehlerbehandlung wenn das nicht zutrifft.
Da du auf einem Raspi bist, kannst du mal testweise bei Zeile 175 (nach GLIBC=) einfügen
ARCH=armhf
ARCHJ=arm
Eventuell tuts dann erstmal.
Zitat von: Adimarantis am 06 Oktober 2022, 21:38:49
Update auf signal-cli 0.11.2
Dieses Update ist zwingend erforderlich, da sich anscheinend intern etwas beim Signal Server verändert hat.
Ich habe zwar Signalbot auch aktualisiert, aber neu ist nur dass er bei Versionen <0.11.2 meckert. Es ist nur ein signal-cli update notwendig.
Vorgehensweise:
1. in FHEM
set reinit
Sollte das aktuelle Install script nach www/signal laden - zur Kontrolle: SCRIPTVERSION="3.10"
2. in der Shell im Verzeichnis www/signal
sudo -E ./signal_install.sh
Installation durchführen, alte signal-cli version überschreiben.
Achtung an alle V0.9.2 und Java11 Nutzer - update auf Java17 ist notwendig!
3. wieder in FHEM
set reinit
Sollte das Account nicht mehr gesetzt sein, mit
set signalAccount <nummer>
neu setzen.
Danach sollte eigentlich alles wieder funktionieren.
Funktioniert! Top! Danke!
Habe 5 Tage gebraucht um zu merken, dass etwas nicht stimmt.
Auch bei mir hat es super geklappt - danke für die schnelle Arbeit der Anpassung. Im Hilfetext des Moduls steht noch als Aufruf des Scriptes zum update sudo ./signal_install.sh, also der Parameter -E nicht genannt wird. Ich kann nicht beurteilen, ob die damit verlangte Erhaltung der User-Umgebung zwingend notwendig für den Erfolg des Scripte ist.
Herzliche Grüße
Christian
Danke für den Hinweis. Werd ich updaten.
Das "-E" ist wichtig für Leute die ein eigenes JAVA_HOME gesetzt haben - sonst wird das Environment nicht über sudo weitergegeben.
Moin,
ich versuche gerade die Stellschraube zu finden, um Umlaute (UTF-8) in Plots (plotAsPng) richtig dargestellt zu bekommen. Wenn ich mit send @Joerg &SVG_MYSQL_1 den Plot FHEM_02.jpg sende, kommen die Umlaute nicht an. Ergebnis in Signal siehe FHEM_01.jpg. An welcher "Schraube" muss ich drehen, damit die Sonderzeichen im Plot richtig ankommen. Sonderzeichen mit Signal als Text gesendet kommen richtig an. Es muss also irgendwo in der Funktion plotAsPng bei mir nicht stimmen. Ideen?
Die SVG_MYSQL_1.gplot:
# Created by FHEM/98_SVG.pm, 2022-10-11 20:39:53
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Umlaute öäü und Emojis
set ytics
set y2tics
set grid
set ylabel ""
set y2label ""
#MYSQL DG_HM_Wetterstation:temperature
plot "<IN>" using 1:2 axes x1y2 title 'ö ä ü ' ls l0 lw 1 with lines
Gruss
Enno
Hi Enno,
da hilft es FHEM komplett auf Unicode umzustellen:
attr global encoding unicode
Achtung:
- Das Ändern dieses Attributs führt zu einem sofortigen FHEM Neustart (ohne Nachfrage)
- Nicht alle Module unterstützen Unicode schon sauber - es kann also sein, dass du das Problem für SVG zwar löst, es dir aber woanders auf die Füße fällt
Ich fahre meine FHEM Umgebung bereits seit längerem mit dieser Einstellung. Von den Modulen die ich verwende, weiss ich nur das PROPLANTA Probleme hat (das hab ich mir gepatched). Es gibt aber natürlich noch 100+ Module die ich nicht verwende.
Jörg
Zitat von: Adimarantis am 11 Oktober 2022, 21:39:47
- Nicht alle Module unterstützen Unicode schon sauber - es kann also sein, dass du das Problem für SVG zwar löst, es dir aber woanders auf die Füße fällt
ok, das wird eine grössere OP:
2022.10.11 22:18:40.936 1: PERL WARNING: UTF-8 "\xED\xAE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.936 1: PERL WARNING: UTF-8 "\xB7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.936 1: PERL WARNING: UTF-8 "\x87" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.936 1: PERL WARNING: UTF-8 "\xC7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xBF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\x85" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\x94" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xA0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xB6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\x8D" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xAC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xE1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xAB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.937 1: PERL WARNING: UTF-8 "\xC6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\x96" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xB1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xE5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xA7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xA1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\x88" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xDF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xB3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.938 1: PERL WARNING: UTF-8 "\xF8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\x84" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\xFF\xAC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\xA9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\xF5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\xFC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.939 1: PERL WARNING: UTF-8 "\xA4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xA6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xBC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xA8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xF5\xBF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xD7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xEA\xB8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.940 1: PERL WARNING: UTF-8 "\xD4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.941 1: PERL WARNING: UTF-8 "\xC1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.941 1: PERL WARNING: UTF-8 "\xEC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.941 1: PERL WARNING: UTF-8 "\xE0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.941 1: PERL WARNING: UTF-8 "\xED\xB0\xBE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.942 1: PERL WARNING: UTF-8 "\xC2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5844.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xAB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\x90" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xA6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xD1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xC1\xB0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xB1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\x83" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xC0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.943 1: PERL WARNING: UTF-8 "\xD6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\xC4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x85" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x80" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x97" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x94" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x9C" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\xA4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\xC7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\x84" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\xB0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.944 1: PERL WARNING: UTF-8 "\xEA\xB1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xFD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\x93" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xAC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xDF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xA5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xB6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xAE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\x92" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xFA" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xEC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xD8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.945 1: PERL WARNING: UTF-8 "\xD7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xDC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xC2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\x9B" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xC8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xFA\x86" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xE3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xEA" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\x89" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.946 1: PERL WARNING: UTF-8 "\xD0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xE5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xC1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xBF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\x8A" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xDD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xED\xB1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xA3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xED" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\x88" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.947 1: PERL WARNING: UTF-8 "\xFA\x9C\xB0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xFC\x90" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\x9A" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\x82" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xB3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xBB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xDB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xF0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\xB4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.948 1: PERL WARNING: UTF-8 "\x96" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xF5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\x8E" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xF3\x88" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xDA" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xFE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xFF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\x8D" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xA2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xE2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.949 1: PERL WARNING: UTF-8 "\xEA\x9E" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\x95" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xDE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xD9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xEB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xAF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xAD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xB2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.950 1: PERL WARNING: UTF-8 "\xA0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xE4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xE8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\x81" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xCA" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xF7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xC9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xF3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xE9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.951 1: PERL WARNING: UTF-8 "\xCF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xF9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xF2" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xF4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xB7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xB9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xFB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xE1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\xD5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.952 1: PERL WARNING: UTF-8 "\x8B" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xF9\xB3" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xE0" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xC5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xBD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xA9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xD4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.953 1: PERL WARNING: UTF-8 "\xE6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xA8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xF8\x8D" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xF4\xB9\x98" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xFC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\x9D" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xBE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\xC6" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.954 1: PERL WARNING: UTF-8 "\x87" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xEB\x83" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xF2\x80" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xEA\xA9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xF6\xB5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xC1\x88" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xB5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xCE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.955 1: PERL WARNING: UTF-8 "\xAA" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xC1\x95" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xF8\xB9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\x99" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xEE" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xE2\xAD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xEF" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.956 1: PERL WARNING: UTF-8 "\xA1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\xF1" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\xCB" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\x86" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\x8F" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\xF5\x92" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.957 1: PERL WARNING: UTF-8 "\xE4\xA8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\xE0\x9E\x91" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\xA7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\xF5\x9F" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\xE7" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\xE5\xB9" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.958 1: PERL WARNING: UTF-8 "\x9E" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.959 1: PERL WARNING: UTF-8 "\xF8" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.959 1: PERL WARNING: UTF-8 "\xE8\xA5" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.960 1: PERL WARNING: UTF-8 "\xCD" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.960 1: PERL WARNING: UTF-8 "\xBC" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.960 1: PERL WARNING: UTF-8 "\xF1\xA6\x94" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.960 1: PERL WARNING: UTF-8 "\xF0\x86" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:40.960 1: PERL WARNING: UTF-8 "\xFC\x9F\xB4" does not map to Unicode at fhem.pl line 1405, <$fh> line 5850.
2022.10.11 22:18:41.494 1: PERL WARNING: UTF-8 "\xFC" does not map to Unicode at fhem.pl line 1405, <$fh> line 9664.
2022.10.11 22:18:41.496 1: PERL WARNING: UTF-8 "\xFC" does not map to Unicode at fhem.pl line 1405, <$fh> line 9701.
Ich muss erst mal wieder zurück stellen und mich schlau machen, warum FHEM mit "unicode" nicht mehr startet.
Gruss
Enno
Hi,
sorry ich war gestern unterwegs.
Der
arch Befehl liefert bei mir
Zitataarch64
Hab es mal angepasst auf:
GLIBC=`ldd --version | grep -m1 -o '[0-9]\.[0-9][0-9]' | head -n 1`
IDENTSTR=$ARCH-glibc$GLIBC-$LIBRARYVERSION
KNOWN=("amd64-glibc2.27-0.11.2" "amd64-glibc2.28-0.11.2" "amd64-glibc2.31-0.11.2" "armhf-glibc2.28-0.11.2" "armhf-glibc2.31-0.11.2" "aarch64")
Aber der Fehler bleibt.
Ein
Zitatjava -version
ergibt
Zitatopenjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment (build 11.0.12+7-post-Raspbian-2deb10u1)
OpenJDK Server VM (build 11.0.12+7-post-Raspbian-2deb10u1, mixed mode)
Was nicht Java 17 ist, oder?
Hab auf einem alten Image beim install script (3.1) diese Meldung (using signal 0.9.0) noch erhalten:
Zitataarch64-glibc2.28-0.9.0 is an unsupported combination - signal-cli binary libraries might not work
Kann ich das irgendwie beheben?
Gruß
Christian
Hi Christian,
Du hast anscheinend das 64 bit OS auf deinem Raspi. Möglicherweise müsste man dafür die Libraries spezifisch übersetzen. Allerdings habe ich aktuell nur 32 bit Systeme bei mir am Laufen.
Ich weiss nicht ob das Rückwärtskompatibel ist.
Deine Änderung am Script passt so nicht.
Der einfachste Hack wäre
if [ $ARCH = "armv7l" ]; then
nach
if [ $ARCH = "aarch64" ]; then
Schau mal ob das was bringt.
Jörg
Hi Jörg,
hab die Änderung gemacht.
ZitatChecking for /etc/systemd/system/signal.service...found
3,4c3,4
< Requires=dbus.socket
< After=dbus.socket
---
> Requires=dbus.socket network-online.target
> After=dbus.socket network-online.target
6d5
< After=network-online.target
10a10,11
> Environment="JAVA_HOME=/opt/java"
> ExecStartPre=/bin/sleep 10
14d14
< Timeout=200
/etc/systemd/system/signal.service differs, update (Y/n)?
y
/etc/systemd/system/signal.service updated
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
Schaue ich mir das journalctl -xe an habe ich:
Zitat
<--- A start job for unit signal.service has begun execution.
--
-- The job identifier is 1375.
Okt 13 10:23:13 raspberrypi signal-cli[13768]: OpenJDK Server VM warning: You have loaded library /tmp/resource5379853924653732243.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Okt 13 10:23:14 raspberrypi signal-cli[13768]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Okt 13 10:23:14 raspberrypi signal-cli[13768]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource5379853924653732243.so: /tmp/resource5379853924653732243.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: can't load AM
Okt 13 10:23:14 raspberrypi signal-cli[13768]: Missing required native library dependency: libsignal-client
Okt 13 10:23:15 raspberrypi systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit signal.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Okt 13 10:23:15 raspberrypi systemd[1]: signal.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service has entered the 'failed' state with result 'exit-code'.
Okt 13 10:23:15 raspberrypi systemd[1]: Failed to start Send secure messages to Signal clients.
-- Subject: A start job for unit signal.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 1375 and the job result is failed.
Okt 13 10:23:21 raspberrypi dbus-daemon[351]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
Okt 13 10:23:21 raspberrypi sudo[13178]: pam_unix(sudo:session): session closed for user root
Gruß
Christian
Hab ich befürchtet - aarch64 ist nicht mit armhf kompatibel.
Mal sehen, ich hab noch einen Raspi als Ersatz rumliegen, evtl. kann ich den für 64bit aufsetzen und eine Version bauen.
Kann aber 1-2 Wochen dauern bis ich dazu komme.
Alternativ könntest du versuchen die Library selber zu bauen.
Was wir brauchen ist das hier:
https://github.com/signalapp/libsignal
Erfordert halt eine ganze Reihe von zusätzlichen apt Paketen die installiert werden müssen. Falls du dich versuchen willst und Probleme hast, können wir das ja per PM weiterdiskutieren.
Ich habe 64bit raspbian bullseye im Einsatz und diese lib für libsignal v0.20.0 gebaut, siehe Anhang.
War schon ziemlich ein Gemurkse...
Nur der Vollständigkeit halber:
Ich habe hier https://github.com/agileek/hassio-addons/tree/master/signal/root/ext/libraries/libsignal-client/v0.20.0 noch jemanden gefunden der die Libs bereitstellt - die am64 Version geht auf meinen armbian (aarch64) ...
Hi,
ok kannst du mir auch sagen was man damit macht?
Danke
Christian
Die Frage ist mit welcher glibc das gebaut ist. Wahrscheinlich mit 2.31, was auch bei der bullseye Variante von kroman der Fall sein dürfte.
Da aber "buster" auf 2.28 ist, vermute ich, dass diese libraries nicht funktionieren.
@Kohle77: Ich kann den Installer zwar dafür anpassen, aber ich fürchte das bringt dir nur was, wenn du auf bullseye updatest.
Zitat von: Kohle77 am 13 Oktober 2022, 12:35:03
ok kannst du mir auch sagen was man damit macht?
Wenn du das skript verwendest, kann ich dir das nicht sagen.
Ich habe signal-cli manuell installiert, da das skript ja nicht funktioniert hat.
Ich habe die lib an 2 Stellen gebraucht:
1. hier ausgetauscht:
zip -d /opt/fhem/signal-cli/signal-cli-0.11.2/lib/libsignal-client-0.20.0.jar libsignal_jni.so
zip /opt/fhem/signal-cli/signal-cli-0.11.2/lib/libsignal-client-0.20.0.jar libsignal_jni.so
2. und hierhin kopiert wo java sie findet:
sudo cp libsignal_jni.so /usr/lib
Zitat von: Adimarantis am 13 Oktober 2022, 14:01:52
Die Frage ist mit welcher glibc das gebaut ist.
Wenn ich nur wüßte, wie man das nachschaut.
Ich habe mir die lib von kroman mal angeschaut und laut objdump sind keine Abhängigkeiten >glibc2.28 drin - vielleicht geht das ja.
Anbei eine angepasste Installerversion, die die Library von kroman einbaut.
Außerdem verwendet sie die für aarch64 passende Java Version (bitte /opt/java vor der Installation löschen)
Bitte mal testen ob das funktioniert.
Hi,
habe mit:
cd /opt/
sudo rm -r javadas Verzeichnis gelöscht und das neue script vorbereitet (chmod etc.)
Ergebnis:
- Im install log steht nichts was einen Fehler betrifft
- In der SSH Session sehe ich das
ZitatChecking user signal-cli ...found
Downloading Java from adoptium...successful
Unpacking ...done
./new_signal_install.sh: Zeile 309: /opt/java/bin/java: Datei oder Verzeichnis nicht gefunden
./new_signal_install.sh: Zeile 334: /opt/java/bin/java: Datei oder Verzeichnis nicht gefunden
Error: Java found, but Java 17.0 required
Something went wrong that this script cannot resolved - please fix manually
Gruß
Christian
Moin Jörg,
attr global encoding unicode
bringt mein FHEM zum Erliegen. Da die gesendeten SVG durch Signal die einzigen Probleme bei mir mit Umlauten sind lasse ich es erstmal bei den Standardeinstellungen in "global". Stellt sich mir die Frage, warum plotAsPng mit Signal die Umlaute in SVG zerstückelt und die gleichen SVG als RSS Download richtig angezeigt werden. Gibt es im Modul irgendwo eine Einstellung, mit der ich "rumspielen" kann? @charset "UTF-8"; im CSS bringt nichts.
Gruss
Enno
Einstellen kannst du da nicht viel.
Man könnte damit rumspielen eine zusätzliche Konvertierung im Modul zu machen.
Zeile 2171:
$svg=plotAsPng($sname,@special);
Danach noch ein
$svg=encode_utf8($svg)
oder
$svg=decode_utf8($svg)
Je nachdem in welche Richtung es "falsch" ist.
Hallo Adimrantis
Zitat von: Adimarantis am 13 Oktober 2022, 14:22:11
Anbei eine angepasste Installerversion, die die Library von kroman einbaut.
Bitte mal testen ob das funktioniert.
Habe dieses Installationsscript verwendet und es funzt grandios!
Text senden, Gruppe einrichten habe ich getestet
Durch den Rest muss ich mich noch durchkauen... ;D
Gruß
Sailor
Zitat von: Adimarantis am 12 Dezember 2021, 09:53:45
sudo service signal stop
sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49<Eigene Nummer> trust -a +49<zu vertrauende Nummer>
sudo service signal start
Hallo Jörg, das klappt bei mir nicht:
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0Ich habe schon gelesen, dass anscheinend die Java-Versionen unterschiedlich sind. Ich habe derzeit
java --version
openjdk 17.0.1 2021-10-19 LTS
OpenJDK Runtime Environment (build 17.0.1+12-LTS)
OpenJDK Server VM (build 17.0.1+12-LTS, mixed mode)sowie
apt list --installed | grep jre
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
default-jre-headless/oldstable,now 2:1.11-71+b1 armhf [Installiert,automatisch]
default-jre/oldstable,now 2:1.11-71+b1 armhf [installiert]
openjdk-11-jre-headless/oldstable,now 11.0.16+8-1~deb10u1 armhf [Installiert,automatisch]
openjdk-11-jre/oldstable,now 11.0.16+8-1~deb10u1 armhf [Installiert,automatisch]Anscheinend muss man eine Umgebungsvariable setzen, ich habe etwas von
echo $JAVA_HOME
/home/pi/.sdkman/candidates/java/current
gelesen, kam aber da nicht weiter. Hat jemand eine Idee?
Probier mal
sudo -E -u signal-cli ..
Ein herzerfrischendes Moin vom "achtern Diek" vorweg
Mal eine blöde Frage
{fhem "set SignalBot send \@Empfaenger Erste Zeile\nZweite Zeile\nDritte Zeile"}
sorgt auf dem Handy ganz brav für:
Erste Zeile
Zweite Zeile
Dritte Zeile
Gibt es noch Codes wie man Fettdruck, Kursiv, Unterstrichen, Durchgestrichen oder gar mittig zentriert hinbekommt?
Die Standard - Verfahren wie
*FETT* = FETT
_Kursiv_ - Kursiv
~Durchgestrichen~ = Durchgestrichen
'''MONO''' = MONO
funktionieren leider nicht.
NACHTRAG: Wer lesen kann ist klar im Vorteil: https://fhem.de/commandref.html#Signalbot Atribute formating
attr SignalBot formatting html
{fhem "set SignalBot send \@Empfaenger <b>Bold</b>\n<u>Underlined</u>\n<s>Strikethrough</s>\n<i>Italic</i>"}
Gruß
Sailor
Ein herzerfrischendes Moin vom "achtern Diek" vorweg.
Ich habe mir wiederholt vom Mobiltelefon aus an den SignalBot das Feuer-Emoticon zu gesendet und jedes mal startet sich fhem neu.
Ist das ein Bug oder ein Feature? :o
Gruß
Sailor
Ein herzerfrischendes Moin vom "achtern Diek" vorweg.
Ich habe mir wiederholt vom Mobiltelefon aus an den SignalBot das Feuer-Emoticon zu gesendet und jedes mal startet sich fhem neu.
Ist das ein Bug oder ein Feature? :o
Kann auch sein, dass dies mit DbLog in Verbindung steht weil es dort das Zeichen nicht mag.
Wide character in subroutine entry at .//FHEM/93_DbLog.pm line 2438.
Ist der letzte Eintrag im Log
Gruß
Sailor
Moin Sailor,
ich bekomme wenn ich :fire: vom Mobile zu FHEM sende nur die Meldung:
PERL WARNING: Wide character in print at fhem.pl line 1641.
PERL WARNING: Wide character in print at ./FHEM/95_Babble.pm line 1254.
weil mein DOIF als letzten Versuch alles was nicht sofort erkannt wird dort hin schickt. Einen Absturz schaffe ich damit aber nicht. Ich habe aber auch kein DBLog im Einsatz.
Gruss
Enno
Bei mir funktioniert das einwandfrei - in beide Richtungen.
Ich habe sogar mein FHEM testweise wieder auf
attr global encoding bytestream
gestellt.
Vielleicht liegt das eher an der locale Einstellung eurer Systeme?
Mein system ist auf
>locale
LANG=de_DE
LANGUAGE=de_DE.UTF-8
[....]
LC_ALL=de_DE.UTF-8
eingestellt.
Und ich verwende DBlog.
Jörg
@enno: Nochmal zu deinem SVG Umlaut Problem.
mein "patch" war da wohl ein Schnellschuss (ich war unterwegs) - an der Stelle sind es schon Binärdaten.
Müsste man in der 98_SVG.pm patchen:
....
$svgdata =~ s/\.SVGplot\./\./g if(AttrVal($svgName, "plotAsPngFix", 0));
$svgdata = decode_utf8($svgdata);
eval {
require Image::LibRSVG;
....
Also die Zeile mit dem decode_utf8 dort entsprechend einfügen.
Dann klappen bei mir Umlaute sowohl im Titel als auch der Legende.
Ich check mal mit Rudi ob er das generell so patchen kann.
Jörg
Moin Jörg,
habe deinen Vorschlag gleich eingebaut und "98_SVG.pm" auf "exclude_from_update" gesetzt. Sieht gut aus. :) Bei den anderen Funktionen (z.B. 02_RSS.pm ) in denen plotAsPng wohl genutzt wird habe ich bis jetzt mit der Änderung in 98_SVG.pm auch keine Probleme gesehen. Vielen Dank für den Lösungsansatz.
Gruss
Enno
Zitat von: Adimarantis am 14 Oktober 2022, 20:55:01
Probier mal
sudo -E -u signal-cli ..
Klappt schon mal ohne Java-Fehlermeldung (stand ja auch hier: https://forum.fhem.de/index.php/topic,118370.msg1226778.html#msg1226778 (https://forum.fhem.de/index.php/topic,118370.msg1226778.html#msg1226778)), blöderweise bekomme ich
Invalid account (phone number), make sure you include the country code.Ich habe genommen
sudo -E -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49(meineNummer) trust -a +49(andereNummer)<edit>
Die Fehlermeldung ist jetzt eine andere beim senden
Error in sendMessage:Failure:
Failed to send message:
Unregistered user "+49dieNummer"
1665823XXXXX
Da ist irgendwas bei mir faul
The user +49152XXXX is not registered.
und der ist registriert. OK, ich suche mal weiter.
Gefunden, läuft alles. Danke!
Zitat von: enno am 15 Oktober 2022, 10:25:40
habe deinen Vorschlag gleich eingebaut und "98_SVG.pm" auf "exclude_from_update" gesetzt. Sieht gut aus. :) Bei den anderen Funktionen (z.B. 02_RSS.pm ) in denen plotAsPng wohl genutzt wird habe ich bis jetzt mit der Änderung in 98_SVG.pm auch keine Probleme gesehen. Vielen Dank für den Lösungsansatz.
Du kannst dein exclude wieder rausnehmen - Rudi hat den Fix schon eingecheckt :)
Moin Jörg,
vielen Dank für den wieder sehr schnellen Service. Nun sehen die bunten Bilder noch schöner auf dem Handy aus ;D
Wo ich gerade dabei bin, für mein Problem ReadingsGroup zu verschicken, habe ich mir auch eine Lösung zusammengebastelt:
Zitat von: enno am 20 Februar 2021, 15:04:01
Zum Readingsgroup: Ich habe z.B, ein Readingsgroup, das mir alle Batterien anzeigt (https://wiki.fhem.de/wiki/ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt)
Dieses "Bild" würde ich gerne einfach so per Signal schicken ;) Das scheint aber nicht so einfach machbar zu sein. Das Thema wurde auch schon mal im Forum kurz in Verbindung mit Telegram angefragt: https://forum.fhem.de/index.php?topic=81826.0
Mit dem Tool https://wkhtmltopdf.org/ erzeuge ich mir png und schicke mir dann die Bilder mit Signal. Hier mal ein Bsp. DOIF
defmod di_Fenster_offen_warnung DOIF ([KWL_Variablen:Offene_Fenster] >= 1 and [KWL_Variablen:MinRaumTemperature] <= 14)("wkhtmltoimage --quality 70 --crop-w 740 --crop-x 00 --height 600 http://192.168.1.245:8083/fhem/floorplan/SCREEN2 /opt/fhem/www/images/HAUS.png 2>&1 >/dev/null")(set SIGNAL send &/opt/fhem/www/images/HAUS.png)
attr di_Fenster_offen_warnung do always
attr di_Fenster_offen_warnung wait 0,5Vielleicht kann es jemand gebrauchen.
Gruss
Enno
Hi,
die registrierung hat bei mir auch nicht funktioniert aber es lag daran das ich mir irgendwie das system zerschossen hatte (das command arch auf dem pi lieferte kein armv71 sondern ein 64 bit os).
Hab es neu aufgesetzt und dann ging es.
Gruß
Christian
Nachdem signal-cli 0.11.4 keine neuen Libraries braucht, habe ich die Version im Installer dafür entsprechend angepasst. ("set reinit" um die lokale Version zu aktualisieren)
Wer mag kann gerne updaten. Wer keine akuten Probleme hat, braucht aber nicht.
Kurze (dumme?)Frage:
Wenn ich signal-cli auf eine neue Version updaten will(/muss - da ja zwingend v0.11.2 nach den letzen 50_Signalbot.pm-Update vom Okt2022 vorausgesetzt wird) - kann ich dann "einfach" die neue Version des "signal_install.sh" herunterladen und ausführen? Bleiben dann meine Einstellungen erhalten oder werden dieser überschrieben? (Wenn letzteres der Fall ist - kann ich diese irgendwie zuvor sicher und später zurückspielen?)
Besten Dank schonmal..
@_Niemand_
Es gibt options schalter für die signal_install.sh. Siehe https://wiki.fhem.de/wiki/Signalbot#Installation (https://wiki.fhem.de/wiki/Signalbot#Installation) in der Tabelle unter
ZitatDas Script hat mehrere Optionen um Teilfunktionen direkt auszuführen, diese sind:
also mit
sudo -E ./signal-install.sh backup wird ein Backup erstellt und mit restore wieder hergestellt.
Was da allerdings genau gesichert wird kann ich auch nicht sagen.
Gruß
Christian
Der aktuelle Installer wird immer automatisch bei einem "set reinit" oder FHEM Neustart nach www/signal geladen.
Es werden lediglich benötigte Softwareupdates gemacht - dazu werden auch Versionsstände überprüft. D.h. man könnte den Installer auch einfach "auf Verdacht" laufen lassen und er würde dann einfach gar nichts machen (außer Versions- und Funktionschecks).
Der Installer ändert keine Einstellungen.
Die Optionen backup und restore sind dazu da die Einstellungen (Registrierung, Kontakte ...) in eine tar.gz Archivdatei zu sichern und ggf. wieder zurückzuschreiben.
Üblicherweise ist dies dazu gedacht, wenn man eine Installation auf ein neues System umziehen will, kann aber natürlich auch dazu genutzt werden um vor einem Update eine Sicherung zu ziehen.
Besten Dank fürs schnelle Feedback.
Ich habe jetzt mal das Skript (ohne Parameter) laufen lassen und zuvor ein "backup" gemacht (was ich aber nachher nicht benötigt habe).
Nachdem das Skript fertig war (und einen Neustadt des Systems) funktioniert tatsächlich alles wieder ;D
Einzig bei den Kontakten (get contacts) tauchten plötzlich manche Empfängernummer doppelt auf - einmal mit "Name" und einmal nur mit der Nummer. Ich habe dann einfach die "nur Nummern" Einträge manuell rausgelöscht. Jetzt sieht die Liste wieder sauber aus ;)
Gude,
habs heute endlich mal geschafft, Signalbot in betrieb zu nehmen.
Die Anleitung ist mega geil, dass man quasi im FHEM geführt wird, was man machen muss.
Dazu hätt ich aber noch ein paar Anmerkungen: auf der Captcha-seite ist nicht die Line "Status", sondern die Column "Status gemeint. Und dann muss man die Line mit (cancelled) finden, da ein mal! draufklicken (beim Doppelklick öffnet er ein neues Tab und schreibt den Captcha in die Leiste) und den captcha kopieren. Der rest war ziemlich geil, vor allen die Browser-erkennung.
Vielen vielen Dank! Ich bin echt immer noch begeistert, dass es so ein userfreundliches Modul in FHEM gibt ;)
Zitatset signalbot send #test gruppe Mülltonne rausstellen : Unknown group test please check or refresh group list
Wenn der Gruppenname ein Leerzeichen hat, gibts da eine Lösung für?
Das steht (für Kontakte) sogar im Wiki
set signalbot send "#test gruppe" Mülltonne rausstellen
Wegen der Captcha Beschreibung muss ich bei Gelegenheit mal selber wieder eine Registrierung durchführen. Da scheinen nicht auch ein paar Dinge geändert zu haben.
Ich habe seit einiger Zeit freezes bei meinem Raspberry und heute festgestellt, dass es mit sehr hoher Wahrscheinlichkeit an signal-cli liegt. Hat auch jemand anders diese Beobachtung gemacht oder ist das meine Installation?
Meinst du jetzt von signal-cli selbst oder von Signalbot?
Zweiteres würde mich etwas überraschen, das die meisten Aufrufe von Signalbot an signal-cli asynchron sind, d.h. nicht auf ein Ergebnis warten, sondern dies später wieder als Event bekommen.
Woran merkst du das?
Nein, nicht vom Signalbot. Ich suche seit etwa vier Wochen, wieso mein FHEM manchmal über Minuten still steht. Weder stacktrace noch freezemon haben irgend etwas gebracht. Dann hatte ich durch Zufall mal terminal offen und konnte mit top sehen, was da los war: loadAverage von 50 (sonst 0,3) und an erster Stelle signal-cli.
Vermutlich gibt es ab und an Probleme mit den Signal-Servern, die das verursachen? Da leider mein FHEM dann still steht, werden ich wohl das cli erstmal deaktivieren.
signal-cli braucht als Java Prozess eine ganze Menge Speicher.
Wieviel Speicher hat dein Raspi? Ich lasse mein FHEM mit piVCCU, pi-hole und signal-cli eben auf einem 4GB Raspi4 laufen und da sehe ich keine Probleme.
Wenn die Kommunikation vom Signal Server hängt, sollte der Prozess normalerweise im Wait State sein, da dies im Betriebssystem abläuft. Die load sollte deswegen nicht hochgehen.
Aber eben eventuell wenn die Kiste vor lauter swappen nicht dazu kommt alles abzuarbeiten.
Sonst kannst du auch mal ins syslog schauen, ob das irgendwas ungewöhnliches steht, wenn die Kiste hängt.
Pi-hole ist eine Idee, das schaue ich mir mal an. Syslog hatte nix mitgeteilt. Danke!
Hallo!
Ich bekomme bei der Registrierung mit der Option --voice immer den Anruf "We are sorry, an application error has occured".
Hatte das schon mal jemand oder irgend eine Idee für mich?
Hab's sowohl über FHEM Signalbot wie auch über signal-cli versucht.
Das Captcha hat sicher gestimmt, sonst bekommt man nämlich den Fehler "Invalid captcha given."
Vielen Dank!
Markus
Nachdem das anscheinend sonst noch niemandem passiert ist (allerdings regstriert man sich ja auch nicht ständig neu), die Frage an Markus ob dies evtl. ein temporäres Problem war und jetzt wieder geht?
Hallo zusammen,
ich versuche die ganze Zeit erfolglos, signal mit msg zu verbinden (ich möchte meine Benachrichtigung über ROOMMATES weiter benutzten).
"attr globalMsg msgCmdPush set %DEVICE% msg @%RECIPIENT% %MSG%" habe ich gemacht, beim ROOMMATE-Device (z Bsp. "rr_martin" steht imt Attribute "msgContactPush" drin:"signalbot:+49152xx".
Allerdings kommt dann bei "msg push @rr_martin Textnachricht" im Log die Meldung
" msg rr_martin: ID=1670162417.8699.1 TYPE=push ROUTE=signalbot RECIPIENT=+49152XXXX STATUS=UNAVAILABLE PRIORITY=0 TITLE='' 'testnachricht'"
Wenn ich die Nachricht direkt mit
"set signalbot send @+49152xxx Testmessage"
schicke klappt alle.
Ich steh auf dem Schlauch und bin für jeden Tipp Dankbar.
Viele Grüße
Martin
Hi Martin,
schau mal, ob Dir das hier weiterhilft: https://forum.fhem.de/index.php/topic,39983.msg1175491.html#msg1175491
Gruß
Chris
Zitat von: Martin W am 04 Dezember 2022, 15:05:24
attr globalMsg msgCmdPush set %DEVICE% msg @%RECIPIENT% %MSG%
Müsste das nicht
attr globalMsg msgCmdPush set %DEVICE% send %RECIPIENT% %MSG%heißen?
Und bei rr_martin
msgContactPush Signalbot:@+49152xx?
drhirn hat Recht. Das darfst Du in jedem Fall mal anpassen. Mein Beitrag bezog sich auf die Problematik mit Gruppen, da "msg" die Raute nicht kennen wollte.
Zitat von: drhirn am 04 Dezember 2022, 15:25:37
Müsste das nicht
attr globalMsg msgCmdPush set %DEVICE% send %RECIPIENT% %MSG%
heißen?
Und bei rr_martin
msgContactPush Signalbot:@+49152xx
?
Danke für den Tipp/die Tipps. Leider bleibt die Fehlermeldung identisch. Ich habe den Eindruck, dass die Nachricht überhaupt nicht bis zum device "signalbot" durchgereicht wird, dort ändert sich nämlich in den Readings nichts und im Log taucht auch nichts vom signalbot auf. Wenn ich die Nachricht direkt mit
"set signalbot send @+49152xxx Testmessage"
schicke taucht im Log ein Eintrag mit
"signalbot: Before parse:@+49152xxxx text:"
auf.
Kannst du bitte mal von globalMsg und rr_martin die ganze Definition her her kopieren (Telefonnummer natürlich maskieren). Das geht, wenn du ganzen unten auf der Seite des Devices auf "copy for forum.fhem.de" klickst und den Inhalt der Zwischenablage dann hier zwischen code-Tags wieder einfügst.
Sehr gerne.
define rr_martin ROOMMATE haus_residents
attr rr_martin DbLogExclude *
attr rr_martin alias Status
attr rr_martin comment Auto-created by haus_residents
attr rr_martin devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown:home
attr rr_martin group martin
attr rr_martin icon people_sensor
attr rr_martin msgContactPush signalbot:@+49152xxxx
attr rr_martin room Residents
attr rr_martin rr_autoGoneAfter 12
attr rr_martin rr_realname group
attr rr_martin sortby 1
attr rr_martin webCmd state
# DEF haus_residents
# DURATIONTIMER 1670181599.62384
# FUUID 6339726b-f33f-abb9-57b1-c97e933d3fd54f87
# FVERSION 20_ROOMMATE.pm:0.195330/2019-06-02
# NAME rr_martin
# NOTIFYDEV global,
# NR 125
# NTFY_ORDER 50-rr_martin
# READY 1
# RESIDENTGROUPS haus_residents
# STATE home
# SUBTYPE adult
# TYPE ROOMMATE
# eventCount 982
# OLDREADINGS:
# READINGS:
# 2022-12-04 13:08:55 durTimerAbsence 00:00:00
# 2022-12-04 13:08:55 durTimerAbsence_cr 0
# 2022-12-04 20:18:59 durTimerPresence 07:10:04
# 2022-12-04 20:18:59 durTimerPresence_cr 430
# 2022-10-02 13:13:48 durTimerSleep 00:00:00
# 2022-10-02 13:13:48 durTimerSleep_cr 0
# 2022-12-04 20:18:53 fhemMsgPush text
# 2022-12-04 20:18:53 fhemMsgPushGw signalbot:UNAVAILABLE
# 2022-12-04 20:18:53 fhemMsgPushPrio 0
# 2022-12-04 20:18:53 fhemMsgPushState 0
# 2022-12-04 20:18:53 fhemMsgPushTitle -
# 2022-12-04 20:18:53 fhemMsgState 0
# 2022-12-04 20:18:53 fhemMsgStateTypes push:0
# 2022-12-04 13:08:55 lastArrival 2022-12-04 13:08:55
# 2022-12-04 13:03:21 lastDeparture 2022-12-04 13:03:21
# 2022-12-04 13:08:55 lastDurAbsence 00:05:34
# 2022-12-04 13:08:55 lastDurAbsence_cr 6
# 2022-12-04 13:03:21 lastDurPresence 00:01:43
# 2022-12-04 13:03:21 lastDurPresence_cr 2
# 2022-12-04 13:03:21 lastLocation home
# 2022-12-04 13:03:21 lastMood calm
# 2022-12-04 13:08:55 lastState gone
# 2022-12-04 13:08:55 location home
# 2022-12-04 13:08:55 mood calm
# 2022-12-04 13:08:55 presence present
# 2022-12-04 13:08:55 state home
# 2022-10-02 13:13:48 wayhome 0
# TIMER:
# rr_martin_DurationTimer:
# HASH rr_martin
# MODIFIER DurationTimer
# NAME rr_martin_DurationTimer
#
setstate rr_martin home
setstate rr_martin 2022-12-04 13:08:55 durTimerAbsence 00:00:00
setstate rr_martin 2022-12-04 13:08:55 durTimerAbsence_cr 0
setstate rr_martin 2022-12-04 20:18:59 durTimerPresence 07:10:04
setstate rr_martin 2022-12-04 20:18:59 durTimerPresence_cr 430
setstate rr_martin 2022-10-02 13:13:48 durTimerSleep 00:00:00
setstate rr_martin 2022-10-02 13:13:48 durTimerSleep_cr 0
setstate rr_martin 2022-12-04 20:18:53 fhemMsgPush text
setstate rr_martin 2022-12-04 20:18:53 fhemMsgPushGw signalbot:UNAVAILABLE
setstate rr_martin 2022-12-04 20:18:53 fhemMsgPushPrio 0
setstate rr_martin 2022-12-04 20:18:53 fhemMsgPushState 0
setstate rr_martin 2022-12-04 20:18:53 fhemMsgPushTitle -
setstate rr_martin 2022-12-04 20:18:53 fhemMsgState 0
setstate rr_martin 2022-12-04 20:18:53 fhemMsgStateTypes push:0
setstate rr_martin 2022-12-04 13:08:55 lastArrival 2022-12-04 13:08:55
setstate rr_martin 2022-12-04 13:03:21 lastDeparture 2022-12-04 13:03:21
setstate rr_martin 2022-12-04 13:08:55 lastDurAbsence 00:05:34
setstate rr_martin 2022-12-04 13:08:55 lastDurAbsence_cr 6
setstate rr_martin 2022-12-04 13:03:21 lastDurPresence 00:01:43
setstate rr_martin 2022-12-04 13:03:21 lastDurPresence_cr 2
setstate rr_martin 2022-12-04 13:03:21 lastLocation home
setstate rr_martin 2022-12-04 13:03:21 lastMood calm
setstate rr_martin 2022-12-04 13:08:55 lastState gone
setstate rr_martin 2022-12-04 13:08:55 location home
setstate rr_martin 2022-12-04 13:08:55 mood calm
setstate rr_martin 2022-12-04 13:08:55 presence present
setstate rr_martin 2022-12-04 13:08:55 state home
setstate rr_martin 2022-10-02 13:13:48 wayhome 0
define globalMsg msgConfig
attr globalMsg comment FHEM Global Configuration for command 'msg'
attr globalMsg group Global
attr globalMsg msgCmdPush set %DEVICE% send %RECIPIENT% %MSG%
attr globalMsg msgType text
attr globalMsg room Alarmanlage,Server
attr globalMsg stateFormat fhemMsgState
attr globalMsg verbose 3
# CFGFN
# FUUID 638c7c97-f33f-abb9-8895-7a5ebf206398f254
# FVERSION 75_msgConfig.pm:0.189950/2019-03-22
# NAME globalMsg
# NOTIFYDEV TYPE=(Jabber|TelegramBot|yowsup)
# NR 5821
# NTFY_ORDER 50-globalMsg
# STATE initialized
# TYPE msgConfig
# eventCount 1
# Helper:
# DBLOG:
# fhemMsgState:
# logdb:
# TIME 1670151319.6102
# VALUE initialized
# READINGS:
# 2022-12-04 11:55:19 fhemMsgState initialized
#
setstate globalMsg initialized
setstate globalMsg 2022-12-04 11:55:19 fhemMsgState initialized
Gruß Martin
Tja, gerade auch ratlos. Kannst du noch die "signalbot" Definition posten bitte?
Und probier mal: msg push @rr_martin 1 Textnachricht
Bei mir sieht derselbe Befehl, den du auch absetzt, im Log so aus:
msg rr_XXX: ID=167024xxx TYPE=push ROUTE=Signalbot RECIPIENT=@+49xxx STATUS=OK PRIORITY=0 TITLE='Nachricht von FHEM' MSG='Textnachricht'
Also irgendwas hat's bei dir mit der Priorität. Kannst ja mal folgendes bei globalMsg probieren:
attr globalMsg msgPriorityPush 1
***edit***
Sehe gerade in deinem Roommate-Device
2022-12-04 20:18:53 fhemMsgPushGw signalbot:UNAVAILABLE
Das ist natürlich schlecht. Heißt das Signalbot-Device wirklich "signalbot"? Ich bleib dabei, her mit der Definition des Devices ;)
Zitat von: drhirn am 05 Dezember 2022, 13:07:37
Und probier mal: msg push @rr_martin 1 Textnachricht
Bei mir sieht derselbe Befehl, den du auch absetzt, im Log so aus:
msg rr_XXX: ID=167024xxx TYPE=push ROUTE=Signalbot RECIPIENT=@+49xxx STATUS=OK PRIORITY=0 TITLE='Nachricht von FHEM' MSG='Textnachricht'
Also irgendwas hat's bei dir mit der Priorität. Kannst ja mal folgendes bei globalMsg probieren:
attr globalMsg msgPriorityPush 1
Hat leider keine Auswirkung.
Zitat von: drhirn am 05 Dezember 2022, 13:07:37
***edit***
Sehe gerade in deinem Roommate-Device
2022-12-04 20:18:53 fhemMsgPushGw signalbot:UNAVAILABLE
Das ist natürlich schlecht. Heißt das Signalbot-Device wirklich "signalbot"? Ich bleib dabei, her mit der Definition des Devices ;)
Ja, er heißt wirklich "signalbot" :)
define signalbot Signalbot
attr signalbot registerMethod Voice
attr signalbot room Alarmanlage,Server
attr signalbot showtime 1
# FD 4
# FUUID 61b74507-f33f-abb9-a6b0-2326e2283f6cc132
# NAME signalbot
# NOTIFYDEV global
# NR 108
# NTFY_ORDER 50-signalbot
# STATE 0
# TYPE Signalbot
# VERSION Signalbot:3.11 signal-cli:0.11.4 Protocol::DBus:0.22
# eventCount 4
# model Raspbian GNU/Linux 11 (bullseye)
# Helper:
# DBLOG:
# account:
# logdb:
# TIME 1670210837.00059
# VALUE +496329xxxxxx
# joinedGroups:
# logdb:
# TIME 1670229098.16383
# VALUE Zuhause
# lastError:
# logdb:
# TIME 1670210837.00059
# VALUE ok
# READINGS:
# 2022-12-05 04:27:16 account +496329xxxxx
# 2022-12-05 04:27:16 accountName
# 2022-12-05 09:31:38 joinedGroups Zuhause
# 2022-12-05 04:27:16 lastError ok
# 2022-11-13 22:40:07 msgAttachment
# 2022-11-13 22:40:07 msgAuth 0
# 2022-11-13 22:40:07 msgGroupName
# 2022-11-13 22:40:07 msgSender Martin W.
# 2022-11-13 22:40:07 msgText Zur�ck
# 2022-11-13 22:40:07 msgTimestamp 13-11-2022 22:40:04
# 2022-12-05 09:59:07 sentMsg Fenster im Bad oben noch offen!!
# 2022-12-05 09:59:14 sentMsgRecipient martin
# 2022-12-05 09:59:14 sentMsgTimestamp 05-12-2022 09:59:07
# 2021-12-13 20:49:14 state 0
# helper:
# accounts 1
# init 1
# lasterr Error in version:Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
# multi 1
# signalpath /org/asamk/Signal/_496329989295
# version 1104
# accountlist:
# +4963299xxxx
# contacts:
# +4915206xxxxxx martin
# +4917660xxxxxx vera
# +4963299xxxxxx
# groups:
# 113 253 133 152 238 212 203 75 255 37 233 189 185 239 95 184 168 90 183 78 145 138 27 235 77 74 122 35 214 215 49 162:
# active 1
# blocked 0
# name Zuhause
#
setstate signalbot 0
setstate signalbot 2022-12-05 04:27:16 account +496329xxxxx
setstate signalbot 2022-12-05 04:27:16 accountName
setstate signalbot 2022-12-05 09:31:38 joinedGroups Zuhause
setstate signalbot 2022-12-05 04:27:16 lastError ok
setstate signalbot 2022-11-13 22:40:07 msgAttachment
setstate signalbot 2022-11-13 22:40:07 msgAuth 0
setstate signalbot 2022-11-13 22:40:07 msgGroupName
setstate signalbot 2022-11-13 22:40:07 msgSender Martin W.
setstate signalbot 2022-11-13 22:40:07 msgText Zur�ck
setstate signalbot 2022-11-13 22:40:07 msgTimestamp 13-11-2022 22:40:04
setstate signalbot 2022-12-05 09:59:07 sentMsg Fenster im Bad oben noch offen!!
setstate signalbot 2022-12-05 09:59:14 sentMsgRecipient martin
setstate signalbot 2022-12-05 09:59:14 sentMsgTimestamp 05-12-2022 09:59:07
setstate signalbot 2021-12-13 20:49:14 state 0
Bin leider gerade etwas überfragt. Und testen ist schwer, weil mal schnell ein Signalbot-Device auf einer Testinstanz aufsetzen geht leider nicht so einfach.
Wenn du folgendes einträgst
attr globalMsg msgContactPush signalbot:@+49152xxxx
solltest du einfach mit
msg Test
Nachrichten an die obige Nummer verschicken können. Das hilft, Tippfehler zu vermeiden.
Und dann kannst du ja noch bei globalMsg verbose auf 5 stellen und schauen, ob noch irgendwie interessante Meldungen im Log auftauchen.
Hallo,
ich hatte wohl eine Uralt Version die mitterweile nicht mehr lief und habe nun SignalBot neu eingerichtet. Nur über die Captchas komme ich nicht weg. Das Captcha sieht gut aus: signalcaptcha://signal-recaptcha-v2.6LfBXs0bAAAAAAjkDyyI1Lk5gBAUWfhI_bIyox5W.registration.03AE...
Aber FHEM liefert folgenden Fehler:
Incorrect captcha - e.g. needs to start with signalcaptcha://
Wo kann ich da noch weitersuchen?
Viele Grüße
Marco
Hi Marco,
was steht denn im reading "lasterr".
Ich wollte gerade mal auf meinem Testsystem einfach eine erneute Registrierung durchprobieren und er hat sich beschwert, dass "Account already in use".
Das Captcha an sich hätte bei mir funktioniert.
Hallo,
Zitat von: Adimarantis am 05 Dezember 2022, 17:37:20
was steht denn im reading "lasterr".
Tja- du hast völlig recht: da hätte ich gleich mal schauen sollen: 413 Rate limit exceeded. Ich hatte es wohl zu häufig versucht. Heute morgen ging es auf Anhieb.
Vielen Dank!
Gibt es noch weitere Erkenntnisse zum Thema "msg"?
Ich verwende das selber nicht, und kann da wenig beitragen, würde aber gerne dazu etwas ins Wiki übernehmen, wenn mir jemand eine Zusammenfassung schreiben kann.
Der einzige (schon zitierte) Tipp war ja, dass man statt "#" auch "@#" für Gruppen verwenden kann, was msg akzeptieren sollte.
Hab mir den "msg" source mal angesehen - da gibt es in msgConfig noch eine Sektion die spezifisch für TelegramBot ist, was allerdings eingehende Messages auswertet. Ich weiss nicht wo das gebraucht ist, ist kann das aber gerne für SignalBot erweitern und hier posten, falls es jemand ausprobieren möchte.
Eingehende Nachrichten gehen ja so auch schon. Oder was genau meinst du mit "auswertet"?
Einige Device typen werden in msgConfig für Notify registriert:
TYPE=(Jabber|TelegramBot|yowsup)
da könnte man SignalBot aufnehmen.
Im Falle eines Notify wertet dann eine Routine erhaltene Nachrichten aus.
Wenn ich den Code richtig lese, ist wohl das einzige was passiert, dass das reading fhemMsgRcv im Device des Empfängers (roommates?) die erhaltene Nachricht hinterlegt wird. Keine Ahnung wozu das dann gut ist.
Ausserdem werden in msgSchema.pm noch Device spezifische Dinge definiert. Da könnte man den TelegramBot Teil für Signalbot kopieren. Scheint irgendwelche Defaultbefehle festzulegen:
'SignalBot' => {
'Normal' => 'set %DEVICE% %SignalBot_MTYPE% %RECIPIENT% %MSG%',
'High' => 'set %DEVICE% %SignalBot_MTYPE% %RECIPIENT% %MSG%',
'Low' => 'set %DEVICE% %SignalBot_MTYPE% %RECIPIENT% %MSG%',
'defaultValues' => {
'Normal' => {
'RECIPIENT' => '',
'SignalBot_MTYPE' => 'send',
},
'High' => {
'RECIPIENT' => '',
'SignalBot_MTYPE' => 'send',
},
'Low' => {
'RECIPIENT' => '',
'SignalBot_MTYPE' => 'send',
},
},
},
Zitat von: Adimarantis am 07 Dezember 2022, 14:44:10
Einige Device typen werden in msgConfig für Notify registriert:
TYPE=(Jabber|TelegramBot|yowsup)
da könnte man SignalBot aufnehmen.
Ach so, Notify. Ja, warum eigentlich nicht.
Wir haben ein neues Handy erhalten und sind dann in die Situation gekommen, dass wir den Fehler
ZitatUntrusted Identity for "+49xxxxxxx"
erhalten haben. Das ist aber nur aufgefallen, weil Signalbot/signal-cli keine Nachrichtem auch von einem anderen Gerät keine Nachrichten mehr entgegengenommen hat.
Nachdem ich der betroffenen Nummer wieder vertraut habe, hat Signalbot/signal-cli wieder alle Nachrichten von allen Geräten angenommen.
Ist das ein nachvollziehbares/gewolltes Verhalten oder ein Fehler?
Gruß
Chris
Moin Chris,
normal, siehe https://wiki.fhem.de/wiki/Signalbot#Troubleshooting_.2F_FAQ vorletzter Punkt.
Gruss
Enno
Ja, das kenne ich. Der spannende Punkt ist, aber warum dann von anderen Geräten auch keine Nachrichten mehr empfangen werden können, obwohl nur das eine untrusted ist.
Das sollte eigentlich nicht so sein. Waren das "persönliche Nachrichten" oder in einer Gruppe/Kanal?
Könnte mir nur vorstellen, dass er generell den Nachrichten der ganzen Gruppe nicht vertraut, wenn ein Teilnehmer nicht vertrauenswürdig ist, fände ich aber trotzdem seltsam.
Leider gibt es nach wie vor kein DBus Interface für "trust", wodurch man das immer zu Fuss über die Kommandozeile machen muss.
Also nochmal zusammenfassend:
Gerät A: keine Änderung / trusted
Gerät B: untrusted
FHEM: Signalbot / keine Änderung
Gruppe 1: besteht aus beiden Geräten und FHEM
Senderichtung FHEM => Gerät A: funktioniert weiterhin
Senderichtung FHEM => Gerät B: Fehlermeldung "untrusted identity"
Senderichtung FHEM => Gruppe 1: Gerät A empfängt, Gerät B nicht. Keine Fehlermeldung
Senderichtung Gerät A => FHEM: Kein Empfang und keine Empfangsbestätigung im Gerät A
Senderichtung Gerät B => FHEM: Kein Empfang und keine Empfangsbestätigung im Gerät B
Senderichtung Gruppe 1 / Gerät A => FHEM: Kein Empfang und keine Empfangsbestätigung im Gerät A
Senderichtung Gruppe 1 / Gerät B => FHEM: Kein Empfang und keine Empfangsbestätigung im Gerät B
Zufällig hat sich meine Tochter gerade ein neues Handy geleistet, da konnte ich die Szenarien selbst durchprobieren.
Bei mir hat aber alles wie erwartet geklappt, d.h.
- Kein Empfang vom neuen Handy
- Fehler bei Versand an neues Handy - egal ob direkt oder Gruppe - alle anderen Gruppenmitglieder haben die Nachricht aber erhalten - Fehlermeldung in Signalbot spezifisch für neues Handy
- Versand und Empfang mit allen anderen funktioniert weiter
Nach Herstellung des Trust, entsprechend alles wieder ok.
Warum das bei dir Auswirkungen auf andere Teilnehmer hatte, kann ich leider nicht nachvollziehen und hatte evtl. noch andere Ursachen.
Ok, danke fürs Prüfen. Bei mir gab es einen klaren Zusammenhang zum Trust. Danach ging es wieder.
Hi Gisbert,
ich habe aktuell das gleiche Problem, dass mein Unifi Controller nicht mehr läuft, weil er nach der Installation von Signal Cli über den symbolischen Link unter /usr/bin/java auf die 17 Version zugreift. Bei mir läuft das auf einem Raspberry mit Rasbian (Debian Bullseye). Jetzt wollte ich es eigentlich erreichen, dass entweder Signal-Cli auf die richtige Java Version werweist und ich den symbolischen Link anpasse oder Unifi auf den Java8-SDK zugreift (wäre mir am liebsten). Leider bin ich da noch nicht weitergekommen. Es gibt zwar bei Google den Hinweis, dass man unter /etc/init.d/unifi den JAVA_HOME Pfad anpassen soll, bei mir gibt es den aber in der Datei nicht.
Danke schon im voraus.
Viele Grüsse
Marcus
Zitat von: Gisbert am 15 Juni 2022, 10:50:47
Hallo Adimarantis,
ich hab das Installationsskript laufen lassen, da das Modul nicht mehr funktioniert hat.
Beim Installieren kam diese Frage:
10a11
> Environment="JAVA_HOME="
/etc/systemd/system/signal.service differs, update (Y/n)?
Die habe ich mit Y (=ja) beantwortet.
Jetzt steht in signal.services drin:
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME="
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
insbesondere: Environment="JAVA_HOME="
Da ich auf dem selben Server den UniFi-Controller laufen lasse, der zwingend Java8 benötigt, musste ich einige Klimmzüge machen, damit die neuere Java17-Version für Signal und andererseits die Java8-Version für UniFi zur Verfügung steht.
Meine Frage lautet:
Was müsstet des eigentlich üblicherweise bei Environment="JAVA_HOME=" stehen?
Viele Grüße Gisbert
Edit: Falls ein User den Inhalt der signal.services Datei posten könnte, wäre das auch herzlich willkommen.
Hallo Marcus,
ich kopiere hier, was ich mir notiert hab, vielleicht hilft es dir und du kannst ebenfalls Signal und Unifi auf dem selben Rechner laufen lassen.
Zitat25.09.2022 Signal, UniFi:
https://forum.fhem.de/index.php/topic,118370.msg1236491.html#msg1236491 (https://forum.fhem.de/index.php/topic,118370.msg1236491.html#msg1236491)
In /etc/systemd/system/signal.service folgendes eintragen (bei mir liegt Java 17 dort):
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Ich hab dann den Server auf dem Fhem, Signal und der Unifi-Controller (und noch einiges mehr) läuft, neu gestartet.
Es läuft erstaunlicherweise alles.
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
In der Datei .bashrc diese Zeile auskommentieren:
# export JAVA_HOME=
java -version
openjdk version "11.0.16" 2022-07-19
OpenJDK Runtime Environment (build 11.0.16+8-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.16+8-post-Debian-1deb11u1, mixed mode, sharing)
dpkg -l | grep "oracle\|openjdk"
ii openjdk-11-jre-headless:amd64 11.0.16+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
ii openjdk-17-jdk:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK)
ii openjdk-17-jdk-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Development Kit (JDK) (headless)
ii openjdk-17-jre:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT
ii openjdk-17-jre-headless:amd64 17.0.4+8-1~deb11u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
rc openjdk-8-jre-headless:amd64 8u232-b09-1~deb9u1 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
Der Unifi-Controller lief erst nicht richtig und hat nach Java 11 verlangt, hab das dann installiert.
Zitat08.10.2022 Signalbot
Bevor das Installationsscript durchgeführt wird, bitte folgendes ausführen:
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
Ansonsten wird die Java 11 benutzt und das Installationsskript bricht ab.
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
echo $JAVA_HOME
/usr/lib/jvm/java-17-openjdk-amd64
Viele Grüße Gisbert
HI Gisbert,
danke für die schnelle Antwort. Die Installation der Signal-CLI habe ich leider mit Standard-Parametern durchgeführt, so dass auch JAVA 17 standardmäßig verwendet wird. Mitterlweile habe ich aber ebenfalls den JAVA_HOME Path in der signal.service Datei auf diese Version gesetzt. Der Service startet damit auch und ich kann auch weiterhin Mitteilungen schicken. Leider habe ich es noch nicht geschafft den Unifi-Service wieder zum Laufen zu bekommen. Ich hatte bei einer Google Suche irgendwo gefunden, dass es damit funktionieren soll:
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-armhf/
export PATH=$PATH:$JAVA_HOME/bin
Das hat aber nichts gebracht und bei java --version kam immer noch die 17 er Version. Anschließend habe ich es mit
sudo update-alternatives --config java
versucht. Da kam dann
Es gibt 3 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen)
Auswahl Pfad Priorität Status
------------------------------------------------------------
* 0 /usr/lib/jvm/java-17-openjdk-armhf/bin/java 1711 automa tischer Modus
1 /usr/lib/jvm/java-11-openjdk-armhf/bin/java 1111 manuel ler Modus
2 /usr/lib/jvm/java-17-openjdk-armhf/bin/java 1711 manuel ler Modus
3 /usr/lib/jvm/java-8-openjdk-armhf/jre/bin/java 1081 manuel ler Modus
Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:
und ich konnte die 11er Version auswählen. Ein java --version bringt dann auch die richtige Rückmeldung und der symbolische link unter /usr/bin/java verweist dann auch auf as richtige JDK. Leider bringt Unifi immer noch die gleiche Fehlermeldung und ich bin mir nicht sicher was hier der automatische und der manuelle Modus bedeutet.
Was meinst du denn mit der Anpassung der .bashrc Datei? Bei mir gibt es ein .bashrc. Skript in jedem HOME Verzeichnis (pi/root). Soll das da eingefügt werden?
Danke.
echo $JAVA_HOME
/usr/lib/jvm/java-8-openjdk-amd64/jre/
In der Datei .bashrc diese Zeile auskommentieren:
# export JAVA_HOME=
Hallo Marcus,
ich kann dir leider nicht mehr sagen als das, was ich mir notiert hatte. Falls ich wieder ein Problem haben sollte, dann ist das der Wiedereinstieg in das entsprechende Thema, mehr nicht.
Viele Grüße Gisbert
Hallo,
einfach eine export JAVA_HOME Zeile im start script signal-cli einfügen
##############################################################################
export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-armhf"
# Attempt to set APP_HOME
# Resolve links: $0 may be a link
app_path=$0
Grüße,
Jörg
Hallo Jörg,
Der Signal Dienst läuft mit der Einstellung, aktuell bekomme ich es nur nicht so hin, dass Debian standardmäßig das Java 11 verwendet bzw. zumindest das der Unifi Controller diese Version verwendet ;-) Ist vermutlich ganz einfach, aber da fehlen mir die LInux-Kenntnisse.
Viele Grüsse
Marcus
Zitat von: berniie am 02 Januar 2023, 11:13:17
Hallo,
einfach eine export JAVA_HOME Zeile im start script signal-cli einfügen
##############################################################################
export JAVA_HOME="/usr/lib/jvm/java-17-openjdk-armhf"
# Attempt to set APP_HOME
# Resolve links: $0 may be a link
app_path=$0
Grüße,
Jörg
Hi Martin,
ich habe das gleiche Problem wie du und verstehe nicht warum das nicht funktioniert. Hast du das mittlerweile gelöst? Bei mir steht im Log:
023.01.08 13:54:04 5: msg globalMsg: msgType lookup for globalMsg:
2023.01.08 13:54:04 5: msg globalMsg: Adding to @typesOr: push
2023.01.08 13:54:04 5: msg globalMsg: Adding to @type: push
2023.01.08 13:54:04 5: msg globalMsg: Checking for available routes (triggered by type push)
2023.01.08 13:54:04 5: msg globalMsg: screen route check result: ROUTE_UNAVAILABLE
2023.01.08 13:54:04 5: msg globalMsg: light route check result: ROUTE_UNAVAILABLE
2023.01.08 13:54:04 5: msg globalMsg: audio route check result: ROUTE_UNAVAILABLE
2023.01.08 13:54:04 5: msg globalMsg: push route check result: ROUTE_AVAILABLE
2023.01.08 13:54:04 5: msg globalMsg: mail route check result: ROUTE_UNAVAILABLE
2023.01.08 13:54:04 4: msg globalMsg: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2023.01.08 13:54:04 5: msg globalMsg: Trying to send message via gateway Signalbot to recipient @+49157XXXXXXXXX
2023.01.08 13:54:04 5: msg globalMsg: Determined default title:
2023.01.08 13:54:04 5: msg globalMsg: msgSchema: replacing %RECIPIENT% and $RECIPIENT by ''
2023.01.08 13:54:04 5: msg globalMsg: msgSchema: replacing %Signalbot_MTYPE% and $Signalbot_MTYPE by 'send'
2023.01.08 13:54:04 3: msg globalMsg: ID=1673182444.53797.1 TYPE=push ROUTE=Signalbot RECIPIENT=@+49157XXXXXXXX STATUS=UNAVAILABLE PRIORITY=0 TITLE='FHEM' 'test'
2023.01.08 13:54:04 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:04 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:04 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:05 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:19 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:19 5: msgConfig globalMsg: called function msgConfig_Set()
2023.01.08 13:54:19 5: msgConfig globalMsg: called function msgConfig_Get()
Danke.
VG
Marcus
P.S. Habe den Raspi neu aufgesetzt, nun läuft Unifi und Signal mit der jeweiligen Java Version.
Zitat von: Martin W am 05 Dezember 2022, 13:44:13
Hat leider keine Auswirkung.
Ja, er heißt wirklich "signalbot" :)
define signalbot Signalbot
attr signalbot registerMethod Voice
attr signalbot room Alarmanlage,Server
attr signalbot showtime 1
# FD 4
# FUUID 61b74507-f33f-abb9-a6b0-2326e2283f6cc132
# NAME signalbot
# NOTIFYDEV global
# NR 108
# NTFY_ORDER 50-signalbot
# STATE 0
# TYPE Signalbot
# VERSION Signalbot:3.11 signal-cli:0.11.4 Protocol::DBus:0.22
# eventCount 4
# model Raspbian GNU/Linux 11 (bullseye)
# Helper:
# DBLOG:
# account:
# logdb:
# TIME 1670210837.00059
# VALUE +496329xxxxxx
# joinedGroups:
# logdb:
# TIME 1670229098.16383
# VALUE Zuhause
# lastError:
# logdb:
# TIME 1670210837.00059
# VALUE ok
# READINGS:
# 2022-12-05 04:27:16 account +496329xxxxx
# 2022-12-05 04:27:16 accountName
# 2022-12-05 09:31:38 joinedGroups Zuhause
# 2022-12-05 04:27:16 lastError ok
# 2022-11-13 22:40:07 msgAttachment
# 2022-11-13 22:40:07 msgAuth 0
# 2022-11-13 22:40:07 msgGroupName
# 2022-11-13 22:40:07 msgSender Martin W.
# 2022-11-13 22:40:07 msgText Zur�ck
# 2022-11-13 22:40:07 msgTimestamp 13-11-2022 22:40:04
# 2022-12-05 09:59:07 sentMsg Fenster im Bad oben noch offen!!
# 2022-12-05 09:59:14 sentMsgRecipient martin
# 2022-12-05 09:59:14 sentMsgTimestamp 05-12-2022 09:59:07
# 2021-12-13 20:49:14 state 0
# helper:
# accounts 1
# init 1
# lasterr Error in version:Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
# multi 1
# signalpath /org/asamk/Signal/_496329989295
# version 1104
# accountlist:
# +4963299xxxx
# contacts:
# +4915206xxxxxx martin
# +4917660xxxxxx vera
# +4963299xxxxxx
# groups:
# 113 253 133 152 238 212 203 75 255 37 233 189 185 239 95 184 168 90 183 78 145 138 27 235 77 74 122 35 214 215 49 162:
# active 1
# blocked 0
# name Zuhause
#
setstate signalbot 0
setstate signalbot 2022-12-05 04:27:16 account +496329xxxxx
setstate signalbot 2022-12-05 04:27:16 accountName
setstate signalbot 2022-12-05 09:31:38 joinedGroups Zuhause
setstate signalbot 2022-12-05 04:27:16 lastError ok
setstate signalbot 2022-11-13 22:40:07 msgAttachment
setstate signalbot 2022-11-13 22:40:07 msgAuth 0
setstate signalbot 2022-11-13 22:40:07 msgGroupName
setstate signalbot 2022-11-13 22:40:07 msgSender Martin W.
setstate signalbot 2022-11-13 22:40:07 msgText Zur�ck
setstate signalbot 2022-11-13 22:40:07 msgTimestamp 13-11-2022 22:40:04
setstate signalbot 2022-12-05 09:59:07 sentMsg Fenster im Bad oben noch offen!!
setstate signalbot 2022-12-05 09:59:14 sentMsgRecipient martin
setstate signalbot 2022-12-05 09:59:14 sentMsgTimestamp 05-12-2022 09:59:07
setstate signalbot 2021-12-13 20:49:14 state 0
Moin,
ich weiß jetzt nicht, ob es besser gewesen wäre mein Problem mit Signalbot hier zu platzieren, aber ich finde es ziemlich unübersichtlich alles in einem Thread zu verwursten. Daher hab ich einen eigenen Thread geöffnet.
Vielleicht hat ja jemand eine Idee zu meinem Problem und fühlt sich eingeladen :
"Signalbot/signal-cli Integration kaputt bzw. Neuinstallation schlägt fehl"
https://forum.fhem.de/index.php/topic,131566.0.html (https://forum.fhem.de/index.php/topic,131566.0.html)
Viele Grüße
Chris
Das Signalbot einfach allgemein unter "Unterstützende Dienste" läuft, ist es eher Glücksache wenn mir ein Post außerhalb dieses Threads auffällt (für den ich Notifications bekomme).
Daher am Besten zumindest einen kurzen Post hier, oder eine PM um meine Aufmerksamkeit zu bekommen. Das eigentliche Thema können wir dann gerne im neuen Thread abarbeiten.
Jörg
Update 3.12 (ab morgen per update, jetzt schon im SVN):
- Um die Zusammenarbeit mit "msg" zu verbessern wird jetzt das reading "state" entsprechend gesetzt. Für alle die es noch nicht mitbekommen haben: Für "msg" gibt es jetzt ein Update, wodurch Signalbot sauber unterstützt wird.
- Die "register" Funktion würde vom Ablauf her etwas überarbeitet. Insbesondere wird jetzt erkannt, wenn eine Nummer eigentlich schon registriert war und z.B. mit "unregister" deaktiviert wurde. In dem Fall wird jetzt kein Captcha mehr verlangt.
- Die Dokumentation in der Benutzerführung zum Captcha wurde aktualisiert und vereinfacht, da es inzwischen ja leichter geworden ist, den Captcha-Link zu kopieren
- Eine "unregister" Funktion wurde konsistenzhalber (insbesondere um "register" zu testen") als versteckte Funktion eingebaut. Sehe ich aber keinen sinnvollen Anwendungsfall, daher nur direkt mit "set" Befehl in der Kommandozeile verwendbar.
- Hat jetzt mit Signalbot direkt nichts zu tun, ist aber hier eingebaut: Für alle FTUI3 Nutzer evtl. interessant: Als Erweiterung des Verschickens von DOIF uiTables gibt es jetzt auch Funktionen mit denen die SVG Daten zur Darstellung auf einer Website extrahiert werden können. Mehr dazu unter https://forum.fhem.de/index.php/topic,129898.0.html
Zitat von: Adimarantis am 16 Januar 2023, 19:48:56
Für alle die es noch nicht mitbekommen haben: Für "msg" gibt es jetzt ein Update, wodurch Signalbot sauber unterstützt wird.
Auf was konkret beziehst du dich da? Die "state"-Geschichte?
Ich hab ein Update gemacht und bekomme folgenden Fehler:
Undefined subroutine &main::readingsBulkupdate called at ./FHEM/50_Signalbot.pm line 1227.
Weiter fährt FHEM dann auch nicht mehr hoch
Mist. Tippfehler. Ich mach heute noch einen Hotfix dazu.
Bis dahin kannst du es selbst patchen. es muss readingsBulkUpdate (mit grossem "U") heissen.
Sorry.
Danke! Läuft wieder :)
Hallo zusammen,
Ich steige gerade von Telegrambot auf den Signalbot um. Ist sowieso mein Standard Messenger und sicher dazu. :-) Da macht es nur Sinn auch den Chatbot auf Signal um zubauen. siehe Thread https://forum.fhem.de/index.php/topic,51425.0.html (https://forum.fhem.de/index.php/topic,51425.0.html)
Grundsätzlich funktioniert das auch sehr gut, nur werden mir die Menüpunkte als Text angezeigt, sprich "/hauptmenu" steht als reiner Text bzw. Rückgabewert in der Signalnachricht. Was muß denn eingestellt oder angepasst werden, dass die Befehle auch als Shortcuts also klickbar übergeben werden?
danke und gruß
adrian
Hi Adrian,
meines Wissens gibt es bei Signal keine Buttons so wie bei Telegram. Falls ich mich irre und mir jemand beschreiben kann, wie man Buttons in Messages einbettet werde ich das gerne in Signalbot einbauen.
Gruß,
Jörg
Hallo!
Kleiner Fehler, welche mir aufgefallen ist:
Wenn der DBus nicht funktioniert (irgendwie will gerade der Dienst nicht starten (status=203/EXEC)) und der Hinweis des Moduls eingeblendet wird:
signal-cli v0.11.2+ required.
Please use installer to install or update
Note: The installer only supports Debian based Linux distributions like Ubuntu and Raspberry OS
and X86 or armv7l CPUs
You can download the installer here or your www/signal directory and run it with
sudo ./signal_install.sh
Dann funktioniert der Link des Installer-sh nicht. Er sieht beim Maus-über gut aus, läd aber dann nur die FHEM-Seite herunter.
Getestet mit Firefox & Chrome.
Wenn schon beim Thema...
Ich habe es geschafft meine laufende Installation bei einer Aktualisierung zu zerschießen und komm nicht darauf wo das Problem liegt:
Beim Dienststart bekomme ich den Fehler
Jan 29 12:04:55 SVL01 systemd[1]: Starting Send secure messages to Signal clients...
Jan 29 12:05:05 SVL01 systemd[101895]: signal.service: Failed to execute /opt/fhem/signal/bin/signal-cli: Permission denied
Jan 29 12:05:05 SVL01 systemd[101895]: signal.service: Failed at step EXEC spawning /opt/fhem/signal/bin/signal-cli: Permission denied
Jan 29 12:05:05 SVL01 systemd[1]: signal.service: Main process exited, code=exited, status=203/EXEC
Jan 29 12:05:05 SVL01 systemd[1]: signal.service: Failed with result 'exit-code'.
Jan 29 12:05:05 SVL01 systemd[1]: Failed to start Send secure messages to Signal clients.
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket network-online.target
After=dbus.socket network-online.target
Wants=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
### Neu aus Skript
Environment="JAVA_HOME=$JAVA_HOME"
ExecStartPre=/bin/sleep 10
###
ExecStart=/opt/fhem/signal/bin/signal-cli --config /opt/fhem/.local/share daemon --system
User=fhem
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
$ ls -la /opt/fhem/signal/bin/
insgesamt 24
-rwxr-xr-x 1 fhem dialout 9236 Jan 29 11:51 signal-cli
-rw-r-xr-x 1 fhem dialout 3916 Jan 29 11:51 signal-cli.bat
Ich habe mir schon das Installationsskript angeschaut, aber konnte keine gravierende Abweichung sehen.
(SELinux habe ich nicht (wissendlich) aktiv, da der Dienst für FHEM ähnlich läuft. Kein audit.log, kein Befehl sestatus vorhanden.)
Was sagt denn ein
ls -l /opt/fhem/signal/bin/signal-cli
Könntest auch mal das versuchen
ExecStart=/opt/fhem/signal/bin/signal-cli --config /opt/fhem/.local/share daemon --system
User=root
Könnte sein, dass der User fhem keine Rechte am dbus subsystem hat
Zitat von: berniie am 29 Januar 2023, 19:34:02
Was sagt denn ein
Ergebnis:
ls -l /opt/fhem/signal/bin/signal-cli
~$ ls -l /opt/fhem/signal/bin/signal-cli
-rwxr-xr-x 1 fhem dialout 9236 Jan 29 11:51 /opt/fhem/signal/bin/signal-cli
Zitat von: berniie am 29 Januar 2023, 19:37:50
Könntest auch mal das versuchen
ExecStart=/opt/fhem/signal/bin/signal-cli --config /opt/fhem/.local/share daemon --system
User=root
Könnte sein, dass der User fhem keine Rechte am dbus subsystem hat
Ergebnis:
Jan 29 20:39:16 SVL01 signal-cli[133001]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket to connect to unix:path=/var/run/dbus/system_bus_socket
Jan 29 20:39:16 SVL01 signal-cli[133001]: Dbus command failed, maybe signal-cli dbus daemon is already running: org.freedesktop.dbus.errors.AccessDenied: Connection ":1.202" is not allowed to own the service "org.asamk.Signal">
Jan 29 20:39:16 SVL01 systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
root mag er auf andere Weise nicht...
Gibt es einen speziellen Grund signal-cli unter "fhem" laufen zu lassen. Wahrscheinlich von SiSi umgestiegen?
Der Installer ist standardmässig dafür ausgerichtet eine komplett eigene signal-cli installation unter /opt/signal unter dem user signal-cli einzurichten.
Mein Rat wäre signal-cli komplett runterzuwerfen und mit dem Installer komplett neu zu installieren. Dann sollten alle Rechte, Verzeichnisse etc. optimal aufeinander abgestimmt sein.
Die Registrierung (wenn nicht schon vorhanden) nach /var/lib/signal-cli - aber sicherstellen, dass die Rechte passen (user/gruppe signal-cli).
Man kann deine abweichende Installation sicherlich hinbekommen, aber der Aufwand rentiert sich eher nicht.
Nein, gibt keinen besonderen Grund.
Werde es mal versuchen.
Läuft wieder - Danke
Habe den Rückbau gemacht und per Skript installiert. (Hatte aber keinen Unterschied zu meiner Installation gesehen)
Hatte es damals so gelassen, weil es nur den Kontext zu FHEM gab und dort auch die Anmeldedaten lagen.
Schaut noch einer auf den nicht funktionierenden lokalen Link?
Da hat sich wohl irgendwas am Verhalten von FHEMWEB geändert. Jetzt muss noch ein fhem in die URL (vor www).
Ändere ich bei Gelegenheit. Ebenso wie die Fehlermeldung wenn Dbus nicht funktioniert.
Testversion auf Github: https://github.com/bublath/FHEM-Signalbot/blob/main/50_Signalbot.pm
Ja, bei dieser Version läßt sich das Installationsskript herunterladen und man kann immer noch Nachrichten versenden ;)
Hallo, habe den Signalbot installiert und kann mir über die fhem Oberfläche Nachrichten senden.
Frage mich nun wie ich über 99_myutils eine Nachricht senden kann.
{fhem("set Signal send @+49xxxxxx test")}
funktioniert nicht ..
{fhem("set Signal send @+49xxx test");;} ?
Die Telefonnummer solltest du in Posts übrigens möglichst unkenntlich machen.
Hallo,
so funktioniert es auch nicht. Habe folgendes in die 99_myUtils eingetragen:
sub TestSignal()
{
fhem("set Signal send @+49XXXXXXX Test Signal aus 99_myUtils.pm");;
}
Wenn ich diese über die fhem Commandline aufrufe {TestSignal ()} bekomme ich folgendes in fhem angezeigt.
Not enough arguments. Specify a Recipient, a GroupId or set the defaultPeer attribute
Im fhem log steht folgendes:
2023.02.16 09:01:27 3: Signal: Before parse:1549171xxxxxx Test Signal aus 99_myUtils.pm:
2023.02.16 09:01:27 3: set Signal send 1549171xxxxxx Test Signal aus 99_myUtils.pm : Not enough arguments. Specify a Recipient, a GroupId or set the defaultPeer attribute
Kann es sein das es Probleme mit dem @ Zeichen gibt, da meines Wissens in Perl das @ Zeichen für ein Array steht.
Dann teste mal folgendes
sub TestSignal()
{
fhem("set Signal send \@+49XXXXXXX Test Signal aus 99_myUtils.pm");
}
In Perl braucht man nur ein Semikolon zum Abschluss einer Befehlszeile.
Danke .. so funktioniert es .. \@ war die Lösung ..
Hallo Zusammen,
ich habe mein Handy gewechselt (SIM bzw. Handynr ist gleich geblieben) und seit dem das Problem, dass ich keine Nachrichten mehr von fhem signalbot auf diesem Handy (als contact) empfange, weil der Nummer nicht mehr vertraut wird. Andere Handys (contacts) empfangen aber noch Nachrichten.
In fhem SignalBot-Device wird Folgendes als lastError angezeigt
Error in sendMessage:Untrusted identity:
Failed to send message:
Untrusted Identity for "+4917abc"
xyz
Wenn ich die Lösung gemäß FAQ SignalBot FhemWiki (https://wiki.fhem.de/wiki/Signalbot#Installation (https://wiki.fhem.de/wiki/Signalbot#Installation)) umsetze, bekomme ich folgende Fehlermeldung:
> sudo service signal stop
> sudo -E -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49xyz trust -a +4917abc
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
+49xyz ist die eigene Nummer (bei mir Festnetz), +4917abc (die Nummer vom alten/neuen Handy)
Jemand eine Idee, wie ich das lösen kann?
Check mal welche Java version er aus deiner Kommandozeile verwendet. Wahrscheinlich hast du noch Java 11 oder so und das ist bei dir Standard.
Signal-cli benötigt Java 17. Evtl. musst du den Pfad / JAVA_HOME anpassen.
Vielen Dank, habe tatsächlich java 11:
> $ java --version
openjdk 11.0.18 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Raspbian-1deb10u1)
OpenJDK Server VM (build 11.0.18+10-post-Raspbian-1deb10u1, mixed mode)
Ich finde aber auch kein Java 17 für Buster über apt-get. Hat da jemand einen Tipp?
Richtig - dort ist leider kein Java17 über apt verfügbar.
Deswegen installiert der Installer eine "eigene" Version nach /opt/java
export JAVA_HOME=/opt/java
sollte es eigentlich tun.
ahh, läuft, vielen Dank!
Macht es Sinn das java17-Thema mit in den FAQ im Wiki aufzunehmen, damit der nächste nicht drüber stolpert?
Ja. Danke für die Anregung.
Wiki aktualisiert.
Hallo! Irgendwie "vergisst" Signal mit einem Neustart des Systems die Telefonnummer mit der es registriert ist. (Das passiert nicht bei "shutdown restart".) Wenn ich dann die Registrierung mit der altbekannten Telefonnummer starte ist sofort alles wieder da - ohne dass ich die Registrierung druchlaufen müsste. Tue mich ein wenig schwer mit der Fehlersuche, hat jemand eine Idee?
Ich verwende Signalbot:3.12 signal-cli:0.11.4 Protocol::DBus:0.22
Danke & Lg
Matthias
Das hört sich so an, als würde die lokale Registrierung unter /var/lib/signal-cli nach dem Neustart zurückgesetzt.
Beim Signal Server bist du ja noch registriert - deswegen braucht es auch keine vollständige Registrierung.
Ein Szenario wäre z.B. wenn du signal-cli in einem Container laufen hast, aber /var/lib/signal-cli im "flüchtigen" Teil liegt und somit nach jedem Neustart des Containers wieder auf Anfang ist.
Danke, das war ja schnell!
FHEM läuft als Dienst auf einem ganz normalen Raspbian Buster...
Das (vergessene Registrierung) passiert bei mir jedesmal, falls ich meinen linux server (Intel NUC) neu boote (sudo shutdown -r). Wahrscheinlich das Szenario was Adimarantis beschrieben hat. Dann hilft immer ein 'sudo service signal restart', danach ist immer alles OK. Bei einem fhem restart tritt das nicht auf.
Ich verwende auch Signalbot:3.12 signal-cli:0.11.4 Protocol::DBus:0.22
Ist kein Problem, solange ich weiss wie es zu loesen ist.
Das sollte eigentlich nicht vorkommen. Eventuell ist das irgendeine race condition beim Start der Services.
Ich kenne da bei mir nur den Fall, dass bei reinem WLAN die Schnittstelle zu lange brauchte um verfügbar zu sein. Dadurch ist signal-cli nicht korrekt gestartet. Hierzu habe ich ein
ExecStartPre=/bin/sleep 10in der /etc/systemd/system/signal.service eingefügt. Das ist aber inzwischen in der Standardinstallation so definiert.
Vielleicht ist das bei Jamo ein ähnliches Problem? Da könntest du mal versuchen das hochzustellen, bzw. Abhängigkeiten ("Wants") einzufügen. Signalbot wartet auf die Verfügbarkeit von signal-cli und macht timergesteuert mehrere Retries, sollte also eigentlich robust für eine Verzögerung sein.
Das Problem von Mad-at hört sich anders an, aber es wäre natürlich interessant ob ein service restart oder einfach ein Signalbot reinit in FHEM das Problem ohne erneute Registrierung lösen kann. Oder auch ob "get accounts" die Nummer bereits auflistet, dann müsste ein "set signalAccount" reichen - sollte aber natürlich trotzdem nicht nötig sein.
Wenn das alles nicht hilft, mal den Inhalt /var/lib/signal-cli vor und nach dem Neustart vergleichen. Sollte eigentlich weitgehend gleich sein. Wenn da nach dem Neustart bereits das Verzeichnis mit deiner Telefonnummer fehlt, dann ist bei deinem System was im argen.
/var/lib/signal-cli verändert sich beim Reboot nicht. Es gehört signal-cli, nur signal-cli hat Schreib und Lese Rechte. Das /data Unterverzeichnis enthält die korrekten Informationen - Telefonnummer ist also vor und nach Reboot da.
"get signalAccount" liefert nach dem Reboot eine leere Liste.
Last error: "No account registered - use set account to connect to an existing registration, link or register to get a new account"
Der Vollständigkeit halber: ein service fhem restart behebt das Problem bei mir nicht.
Danke!
Der Tipp war
service signal restart
Ups :o
Sorry, ja natürlich, lesen ist manchmal nicht so leicht...
Äh, also service signal restart alleine bringt nichts, service fhem restart auch nicht, zuerst ein service signal restart gefolgt von einem service fhem restart funktioniert. Was mich zur vermutlichen Diagnose führt: auf dem Raspberry läuft auch der unbound dns server. Könnte mir vorstellen dass es da eine race condition gibt.
Das sleep 10 steht schon drin. Kann ich da einfügen dass systemd auf die Verfügbarkeit der Name Resolution warten muss? Ich hab das schonmal für fhem versucht aber nie hinbekommen, falls Du da Erfahrung hast wär ich um einen Tipp dankbar.
Dann reicht sicher in FHEM auch ein "set Signalbot reinit"
Ich kenne jetzt deinen Service nicht, daher kann ich dir höchstens die ungefähre Richtung weisen.
In /etc/systemd/system/signal.service steht ja sowas wie
Requires=dbus.socket network-online.target
After=dbus.socket network-online.targetDamit ist z.B. festgelegt, dass der signal-cli service erst startet, wenn dbus läuft und das Netzwerk online ist.
Du müsstest also rausfinden mit welchem "Requries/After" dein DNS resolver abgeprüft werden kann.
Danke!
Habe jetzt mal ganz hemdsärmelig folgendes gemacht:
ExecStartPre=/bin/sh -c 'until host google.com; do sleep 1; done'
...funktioniert O:-) :)
Hi
I have a problem. I just installed a fresh Raspberry installation (32 bit, 2023-02-21) installed fhem 6.1 and updated it.
When I try to install signal with the signal_install.sh I get the error:
Checking for Protocol::DBus...V0.22 found
Checking user signal-cli ...found
Checking for Java 17.0...successful
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.11.4
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
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
The systemctl gives me:
A start job for unit signal.service has begun execution.
░░
░░ The job identifier is 5316.
mrt 29 22:53:18 Rasp18-11 signal-cli[6829]: OpenJDK Client VM warning: You have loaded library /tmp/resource3109705241956656131.so which might have disabled stack guard. The VM will try to fix the stack guard now.
mrt 29 22:53:18 Rasp18-11 signal-cli[6829]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
mrt 29 22:53:18 Rasp18-11 signal-cli[6829]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource3109705241956656131.so: /tmp/resource3109705241956656131.so: verkeerde ELF-klasse: ELFCLASS64 (Possible cause: can't load AARCH64 .so on a ARM platform)
mrt 29 22:53:18 Rasp18-11 signal-cli[6829]: Missing required native library dependency: libsignal-client
mrt 29 22:53:20 Rasp18-11 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ An ExecStart= process belonging to unit signal.service has exited.
░░
I have no idea what is happening or how to solve it. Anybody has a hint?
Thanks
The most common reason why the native library can't be loaded is the Java version.
signal-cli requires Java17, but the Raspberry PI still only ships Java11.
To solve this the install script is downloading and installing a third party Java17 build to /opt/java
However your installer log indicates that the installer has found Java17.
If you already have Java17 on your system it could still be that it is not active for the signal-cli user.
You could try
sudo -u signal-cli java --versionif that is showing Java11 you need to make sure that JAVA_HOME is set to the Java17 installation in /etc/systemd/system/signal.service
There should already be a line
Environment="JAVA_HOME="
that you need to extend with the correct path.
Zitat von: Adimarantis am 30 März 2023, 07:33:13The most common reason why the native library can't be loaded is the Java version.
signal-cli requires Java17, but the Raspberry PI still only ships Java11.
To solve this the install script is downloading and installing a third party Java17 build to /opt/java
However your installer log indicates that the installer has found Java17.
If you already have Java17 on your system it could still be that it is not active for the signal-cli user.
You could try
sudo -u signal-cli java --version
Thanks for your suggestion. Unfortunately
sudo -u signal-cli java --version
gives:
openjdk 17.0.6 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Raspbian-1deb11u1rpt1)
OpenJDK Client VM (build 17.0.6+10-Raspbian-1deb11u1rpt1, mixed mode, emulated-client)
So there must be another problem.
If I run
signal_install.sh system
that is fine
signal_install.sh install
is fine
But
signal_install.sh test
gives errors:
You chose the following option: test
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
sudo journalctl -xe
gives me:
-- A start job for unit signal.service has finished with a failure.
--
-- The job identifier is 4553 and the job result is failed.
mrt 31 21:14:20 Rasp18-11 systemd[1]: signal.service: Consumed 3.224s CPU time.
-- Subject: Resources consumed by unit runtime
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit signal.service completed and consumed the indicated resources.
mrt 31 21:14:28 Rasp18-11 dbus-daemon[386]: [system] Failed to activate service 'org.asamk.Signal': timed out (service_start_timeout=25000ms)
systemctl status signal.service
gives:
* 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 2023-03-31 21:14:20 CEST; 14min ago
Process: 16886 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Process: 16893 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=1/FAILURE)
Main PID: 16893 (code=exited, status=1/FAILURE)
CPU: 3.224s
mrt 31 21:14:03 Rasp18-11 systemd[1]: Starting Send secure messages to Signal clients...
mrt 31 21:14:16 Rasp18-11 signal-cli[16893]: OpenJDK Client VM warning: You have loaded library /tmp/resource1073912741712660700.so which might have disabled stack guar>
mrt 31 21:14:16 Rasp18-11 signal-cli[16893]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
mrt 31 21:14:16 Rasp18-11 signal-cli[16893]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource1073912741712660700.so: /tmp/resource107391274171266070>
mrt 31 21:14:16 Rasp18-11 signal-cli[16893]: Missing required native library dependency: libsignal-client
mrt 31 21:14:20 Rasp18-11 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
mrt 31 21:14:20 Rasp18-11 systemd[1]: signal.service: Failed with result 'exit-code'.
mrt 31 21:14:20 Rasp18-11 systemd[1]: Failed to start Send secure messages to Signal clients.
mrt 31 21:14:20 Rasp18-11 systemd[1]: signal.service: Consumed 3.224s CPU time.
I hope this gives a clue and you can give me an idea where to look.
Btw. I would add "rm /tmp/signal_install.log" at the start of signal_install.sh
Current you get errors when you start once signal_install.sh without sudo and restart it with sudo.
addition
/opt/signal/lib/libsignal-client-0.20.0.jar
is present.
-rw-r--r-- 1 signal-cli signal-cli 8984638 31 mrt 21:49 libsignal-client-0.20.0.jar
Looks ok to me
Hi!
I have exactly the same problem after an apt upgrade today.
I am on debian bullseye on a raspberry pi.
BR
Hi
It seems a posting of mine got lost.
In short the signal-client*.so in the current libsignal-client-0.20.0.jar is, according to "file -L" a 64 bit version. But my raspbian is the recommended 32 bit version. In October the signal-client*.so version was a 32 bit version and that worked.
uname -m reports my system as aarch64.
I hope this helps.
{HT}
If "uname -m" reports aarch64, but you're on a 32-bit raspberry (where I would expect armv7l), you probably found the root cause.
To remedy, please download
https://github.com/bublath/FHEM-Signalbot/blob/main/armhf-glibc2.28-0.11.2/libsignal_jni.so
then you need to update it with
sudo -u signal-cli zip -u /opt/signal/lib/libsignal-client-*.jar libsignal_jni.so
You could probably also hardcode the architecture in the signal_install.sh script line 164:
ARCH=`arch`
to
ARCH=armv7ldelete /opt/signal and run the installer again.
I can reproduce the problem after updating my Raspberry.
Apparently the Kernel gets updated to 64 bits now, while the remaining runtime remains 32 bit.
This causes "arch" to return aarch64 while all the software still expects 32 bits.
I have added another check in the installer, that hopefully detects this.
If somebody has a real 64 bit system, I would appreciate a crosscheck - especially if
getconf LONG_BIT
really returns 64 in those cases.
Please try the new installer from
https://raw.githubusercontent.com/bublath/FHEM-Signalbot/main/signal_install.sh
You still should remove /opt/signal before retrying.
Let me know if this works better, then I'll push it to svn
hi!
unfortunately both solutions lead to this:
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: OpenJDK Client VM warning: You have loaded library /tmp/sqlite-3.39.3.0-fe930b41-57ad-4202-9059-4ab4130e9aa9-libsqlitejdbc.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: Failed to load native library:sqlite-3.39.3.0-fe930b41-57ad-4202-9059-4ab4130e9aa9-libsqlitejdbc.so. osinfo: Linux/aarch64
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: java.lang.UnsatisfiedLinkError: /tmp/sqlite-3.39.3.0-fe930b41-57ad-4202-9059-4ab4130e9aa9-libsqlitejdbc.so: /tmp/sqlite-3.39.3.0-fe930b41-57ad-4202-9059-4ab4130e9aa9-libsqlitejdbc.so: wrong ELF class: ELFCLASS64 (Possible cause: can't load AARCH64 .so on a ARM platform)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.lang.Runtime.load0(Runtime.java:755)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.lang.System.load(System.java:1953)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.loadNativeLibrary(SQLiteJDBCLoader.java:280)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.extractAndLoadLibraryFile(SQLiteJDBCLoader.java:237)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:350)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:68)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.core.NativeDB.load(NativeDB.java:63)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:278)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:65)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:19)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.createConnection(JDBC.java:104)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.connect(JDBC.java:77)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:121)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:359)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:201)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:470)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:561)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:100)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:81)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.getHikariDataSource(Database.java:101)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.initDatabase(Database.java:32)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.AccountDatabase.init(AccountDatabase.java:32)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getAccountDatabase$38(SignalAccount.java:1233)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getAccountDatabase(SignalAccount.java:1231)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getRecipientStore$30(SignalAccount.java:1206)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getRecipientStore(SignalAccount.java:1203)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getProfileStore(SignalAccount.java:1210)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:404)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:183)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:93)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:65)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:73)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.init(App.java:191)
Apr 01 17:50:01 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.Main.main(Main.java:60)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: ERROR HikariPool - HikariPool-1 - Exception during pool initialization.
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: java.sql.SQLException: Error opening connection
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:281)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:65)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:19)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.createConnection(JDBC.java:104)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.connect(JDBC.java:77)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:121)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:359)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:201)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:470)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:561)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:100)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:81)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.getHikariDataSource(Database.java:101)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.initDatabase(Database.java:32)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.AccountDatabase.init(AccountDatabase.java:32)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getAccountDatabase$38(SignalAccount.java:1233)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getAccountDatabase(SignalAccount.java:1231)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getRecipientStore$30(SignalAccount.java:1206)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getRecipientStore(SignalAccount.java:1203)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getProfileStore(SignalAccount.java:1210)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:404)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:183)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:93)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:65)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:73)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.init(App.java:191)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.Main.main(Main.java:60)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: Caused by: java.lang.Exception: No native library found for os.name=Linux, os.arch=aarch64, paths=[/org/sqlite/native/Linux/aarch64:/usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib]
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:375)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:68)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.core.NativeDB.load(NativeDB.java:63)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:278)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: ... 47 common frames omitted
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: ERROR MultiAccountManager - Failed to load +4xxxxxxxx: Failed to initialize pool: Error opening connection (PoolInitializationException)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Error opening connection
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.throwPoolInitializationException(HikariPool.java:596)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:582)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:100)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:81)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.getHikariDataSource(Database.java:101)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.Database.initDatabase(Database.java:32)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.AccountDatabase.init(AccountDatabase.java:32)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getAccountDatabase$38(SignalAccount.java:1233)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getAccountDatabase(SignalAccount.java:1231)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.lambda$getRecipientStore$30(SignalAccount.java:1206)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getOrCreate(SignalAccount.java:1645)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getRecipientStore(SignalAccount.java:1203)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.getProfileStore(SignalAccount.java:1210)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.migrateLegacyConfigs(SignalAccount.java:404)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:183)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:93)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:65)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:73)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.handleMultiLocalCommand(App.java:309)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.App.init(App.java:191)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.asamk.signal.Main.main(Main.java:60)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: Caused by: java.sql.SQLException: Error opening connection
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:281)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:65)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:28)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:19)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.createConnection(JDBC.java:104)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.JDBC.connect(JDBC.java:77)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:121)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:359)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:201)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:470)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:561)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: ... 37 more
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: Caused by: java.lang.Exception: No native library found for os.name=Linux, os.arch=aarch64, paths=[/org/sqlite/native/Linux/aarch64:/usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib]
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:375)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:68)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.core.NativeDB.load(NativeDB.java:63)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:278)
Apr 01 17:50:02 fhem.sweethome.net signal-cli[1554]: ... 47 more
Apr 01 17:50:02 fhem.sweethome.net systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Hi
I tried your procedure on a clean, fresh installed, system and it worked.
A few notes:
- line 39 calls java before it is installed. This gives an error message
- if you run the script first without sudo it gives errors afterwards. I would place
if [ ! $(id -u) = 0 ] ; then
# the script needs to be executed with sudo (or root)
echo "Please run $0 with sudo"
exit 1
fi
in the top of the script
- I used
# aarch64 can be 32 or 64 bits. It is assumed you are running a 32 bit OS if ls is a 32bit program.
if [ $(file -L /usr/bin/ls | grep -c 32-bit) ] ; then
to detect 32 or 64 bit after aarch64 was detected. But your solution seems to work too.
I used "signal_install.sh restore" to restore the account from another installation on another raspberry. It seems that does not work. Is there a way to copy the account to a new installation?
mfg
{HT}
Hi Tamash
I have the impression you didn´t remove the old installation.
I would use:
Zitat- ./signal_install.sh remove
to remove the installation
Zitat- rm -r /opt/signal
to remove libs etc which where previous installed
I have problems with registering an account.
If I follow the procedure I get in the chromium console:
Navigeren naar 'signalcaptcha://signal-hcaptcha.30b01b46-d8c9-4c30-bbd7-9719acfe0c10.registration.P1_eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.hKdwYXNza2V5xQPQoCt_Ev66wdrP0DlpNEp54VnOWigpXaUDgFlK2SsuDEeIYD4aoBh8ySQKiKV_0Mvfb6WzhvgOJNZf3FNFvfP0UhpO0yeDtvTtwXO4bNwdZpXVRCpY91MtAH06VV0xuu1zI441tVjeoFO4m4s5j-v_weOAFv3xNxy_PRQWbuA7qP97Hey3gcI8MZUq0YaeAuDgGDeJQNr1Q9r3daVc8eKT6DfPXRzTr5t_OFQUJiMOf_zSEyagNUsGcl64inETnhlIfYnGkwzGV102rIdgG_oFHwwezd6KIW066OW4xFf8E2ZRXtrPeWF6n_7qr-6x4ZUqkNOGLbvAEyJetvfLwGcYvbO-uvDUFHqgfiZcDyuH7m5n_pquLrqStvcSrtcINy5EgBAl9Dx6hJhMMU7DqVkX3oubzFxQ5RI2nXV3sEo78Lpg1GeN7kPSeEpDtXL0TdghAFURzkkRDujg_OJ8NyIqWSGhE5Rr_L15F7eS5uDborSVDaZQU2493fKdm1uC9SsiW39aJZmWCs9q-JrEXzOWgqswKFTHvPvCrZkfXB9YeO5wMZNevmad06vpdPe9WK8hxq1d-63ox2GMpDBvFzbvVL2GE4QWgKC0nQ9Y47k4MNTjowJcBv5gfQRTEuVrf80dDsCWfZrEXkWuNWFy_DuB7HFVTnvbac0sI0wtzkc0jjXYJQRUs4XDDQcvA-Gm_wcN_TmCrABA32fLrk-h0w-tFm5VY7qceKkPONk2xvpa6cZZbHStRVVTJhL8iKRYpAANw39Zt-Fvu0NVhzgoU04RNEV9nt5OYvY82sX4ZaWzgjddQOv-JlTkyqcbQlGKwdXZ6fboUHssTphdgXo-p6iUHsDzlcLSN2hZDe0UsqfdK9EzlsQ5eXcYalclPWeMi25SBaNA5BSeuPyLwcvASC3N_h8y5naN_qFlqRlrsBe_EDPSpmOCkWBbLP7fqcZySZ9Fn9PVJrGPwEOG0j_4REaP-_SycF3pDTV2XcPZNWyKqaHuxDCZ8NCul18vlTRLuWCgQqaP93arUEdXGM4GId_kPM7QX-NH8wVvEMeObYw3gxEJplps6BIMWr7m2eKSWyROI55zDg-6NULtUW3DpJCVsOmXW7MFwC7ovYRDMaW5mWHW0ZKtiwKnjZtLWY2gfiM6shBYDncCUbBGuHhPH-UOfH3lnR5YrC6PylNH7RHSfptdFOpVUggWD7Nup1TOo51tj1ZxYmpFDgAqgxHcHs8_s4s9uPd5YfOfietOrUnS2UmHIBVL9x-d7Eocez0HrvrzUlFHbsqDx5VDB9_OZyKUu6NleHDOZChnIKhzaGFyZF9pZM4DMYNvonBkAA.LtelNz0jIcBybdTYYE1jvIdqtFMJn_RaUQhtosrRqSY' is voorkomen vanwege een onbekend protocol.
(the captcha is a bit changed before posting.)
So I guess I should enter
signalcaptcha://signal-hcaptcha.30b01b46-d8c9-4c30-bbd7-9719acfe0c10.registration.P1_eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.hKdwYXNza2V5xQPQoCt_Ev66wdrP0DlpNEp54VnOWigpXaUDgFlK2SsuDEeIYD4aoBh8ySQKiKV_0Mvfb6WzhvgOJNZf3FNFvfP0UhpO0yeDtvTtwXO4bNwdZpXVRCpY91MtAH06VV0xuu1zI441tVjeoFO4m4s5j-v_weOAFv3xNxy_PRQWbuA7qP97Hey3gcI8MZUq0YaeAuDgGDeJQNr1Q9r3daVc8eKT6DfPXRzTr5t_OFQUJiMOf_zSEyagNUsGcl64inETnhlIfYnGkwzGV102rIdgG_oFHwwezd6KIW066OW4xFf8E2ZRXtrPeWF6n_7qr-6x4ZUqkNOGLbvAEyJetvfLwGcYvbO-uvDUFHqgfiZcDyuH7m5n_pquLrqStvcSrtcINy5EgBAl9Dx6hJhMMU7DqVkX3oubzFxQ5RI2nXV3sEo78Lpg1GeN7kPSeEpDtXL0TdghAFURzkkRDujg_OJ8NyIqWSGhE5Rr_L15F7eS5uDborSVDaZQU2493fKdm1uC9SsiW39aJZmWCs9q-JrEXzOWgqswKFTHvPvCrZkfXB9YeO5wMZNevmad06vpdPe9WK8hxq1d-63ox2GMpDBvFzbvVL2GE4QWgKC0nQ9Y47k4MNTjowJcBv5gfQRTEuVrf80dDsCWfZrEXkWuNWFy_DuB7HFVTnvbac0sI0wtzkc0jjXYJQRUs4XDDQcvA-Gm_wcN_TmCrABA32fLrk-h0w-tFm5VY7qceKkPONk2xvpa6cZZbHStRVVTJhL8iKRYpAANw39Zt-Fvu0NVhzgoU04RNEV9nt5OYvY82sX4ZaWzgjddQOv-JlTkyqcbQlGKwdXZ6fboUHssTphdgXo-p6iUHsDzlcLSN2hZDe0UsqfdK9EzlsQ5eXcYalclPWeMi25SBaNA5BSeuPyLwcvASC3N_h8y5naN_qFlqRlrsBe_EDPSpmOCkWBbLP7fqcZySZ9Fn9PVJrGPwEOG0j_4REaP-_SycF3pDTV2XcPZNWyKqaHuxDCZ8NCul18vlTRLuWCgQqaP93arUEdXGM4GId_kPM7QX-NH8wVvEMeObYw3gxEJplps6BIMWr7m2eKSWyROI55zDg-6NULtUW3DpJCVsOmXW7MFwC7ovYRDMaW5mWHW0ZKtiwKnjZtLWY2gfiM6shBYDncCUbBGuHhPH-UOfH3lnR5YrC6PylNH7RHSfptdFOpVUggWD7Nup1TOo51tj1ZxYmpFDgAqgxHcHs8_s4s9uPd5YfOfietOrUnS2UmHIBVL9x-d7Eocez0HrvrzUlFHbsqDx5VDB9_OZyKUu6NleHDOZChnIKhzaGFyZF9pZM4DMYNvonBkAA.LtelNz0jIcBybdTYYE1jvIdqtFMJn_RaUQhtosrRqSY
in the captcha field.
I then always get the message
ZitatIncorrect captcha - e.g. needs to start with signalcaptcha://
This looks a bit as if there is still a compatibility issue.
Do I make a mistake?
mfg
{HT}
After trying for a while to get my Raspi400 working again after the 64bit upgrade, I decided to force it to 32bit again, setting
arm_64bit=0in /boot/config.txt
Probably that mix between 64Bit Kernel and 32Bit binaries causes a lot of issues.
I continued to have issues with the sqlite not finding the appropriate native library.
Even tried compiling a new native libsignal-client library, but that did not work either as this mixed up system still created 32bit libs.
The whole business with 32 vs 64 bit might also be the issue you're facing with moving your configuration.
Probably the account.db file in /var/lib/signal-cli has a binary dependency. Not sure if there is a tool to convert it.
For your registration problem: Do you have more data (e.g. from the FHEM logfile or lasterr reading)?
I hope this does not get messed up as well with this strange mix of 32 and 64 bit.
In a nutshell: I really recommend switching back to 32bit kernels as described above. Then your backup config should also work again.
Hi
Unfortunately the new script seems to have a problem.
When I use
- signal_install backup
- signal_install restore
I get an error
Zitat● 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 Sat 2023-04-01 20:39:26 CEST; 15s ago
Process: 7186 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, status=2)
Main PID: 7186 (code=exited, status=2)
CPU: 4.593s
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: Caused by: java.lang.Exception: No native library found for os.name=Linux, os.arch=aarch64,
paths=[/org/sqlite/native/Linux/aarch64:/usr/java/packages/lib:/usr/lib/arm-linux-gnueabihf/jni:
/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib]
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:375)
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:68)
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: at org.sqlite.core.NativeDB.load(NativeDB.java:63)
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:278)
apr 01 20:39:25 Rasp18-11 signal-cli[7186]: ... 47 more
apr 01 20:39:26 Rasp18-11 systemd[1]: signal.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
apr 01 20:39:26 Rasp18-11 systemd[1]: signal.service: Failed with result 'exit-code'.
apr 01 20:39:26 Rasp18-11 systemd[1]: Failed to start Send secure messages to Signal clients.
apr 01 20:39:26 Rasp18-11 systemd[1]: signal.service: Consumed 4.593s CPU time.
So for my understanding it seems to be necessary to have an aarch64 32 bit library.
See also https://en.wikipedia.org/wiki/AArch64
I am installing/testing on a Raspberrypi 4 with a 1,8 Ghz processor.
I hope this can be solved.
mfg
{HT}
Hi Adimarantis
Thanks for your work. Is there a specific place in config.txt to place the line arm_64bit=0 ?
I understand more and more what might be the problem of the instability of my production raspberry :)
The backup I had of signal-cli settings was corrupt so that was the reason why the accounts where not registered I guess. With a correct backup I see the problems of the aarch64 library. Having the corrupt part of the accounts in my installation may be the issue why I could not register.
I wonder if it is the time to switch to the 64 bit version of Raspbian. Anybody running FHEM etc on 64 bit?
I just put it at the very end of the config.txt
There are people that do run 64 bit already. That's why this experimental aarch64 support was included.
The required library was provided by the person running that kind of system. I don't have one on my own.
I'm currently in the process of compiling the updated libs for signal-cli 0.11.7 and will publish the updated installer shortly.
That however won't work with 64bit as I don't know how to compile the library.
Zitat von: Adimarantis am 01 April 2023, 21:30:51I just put it at the very end of the config.txt
There are people that do run 64 bit already. That's why this experimental aarch64 support was included.
The required library was provided by the person running that kind of system. I don't have one on my own.
I'm currently in the process of compiling the updated libs for signal-cli 0.11.7 and will publish the updated installer shortly.
That however won't work with 64bit as I don't know how to compile the library.
arm_64bit=0 seems to solve my problems. My accounts are recognized and I can send a message. The update of signal_install.sh seems not to be necessary.
Unfortunately I won't be the last with this problem.
If I can help with testing I am willing to do so
Thanks for all your work and help
I guess I will try a 64 bit installation in the coming days.
mfg
{HT}
So jetzt wieder zurück auf Deutsch.
Habe den Hinweis für die Umstellung zurück auf 32 Bit für Bullseye Raspberrys im Wiki dokumentiert.
Der Installer (wird mit "set reinit" neu geladen) wurde aktualisiert um signal-cli 0.11.7 mit der entsprechenden Native Library zu installieren. Für "echte" 64-Bit Raspberries wird weiter nur 0.11.2 unterstützt.
Ein update ist aber nicht zwingend erforderlich - es gibt aktuell keine mir bekannten neuen Funktion oder Fixes die für die FHEM Nutzung relevant sein sollten.
Vielen Dank.
Durch diese Änderungen funktioniert signal wieder.
Ist das ein generelles Problem bei 64Bit?
Ich nutze
Linux Debian 4.19.269-1 (2022-12-20) x86_64
lsb_release -d
Description: Debian GNU/Linux 10 (buster)
Registrierung einer Nummer schlägt mit dem Captcha fehl.
Der Link mit einer auf dem Handy genutzten Nummer funktioniert.
Muss ich da die Version 0.11.2 nutzen?
Unter X86 war das schon immer 64 Bit.
Das ist ein Problem mit der halbherzigen 64 Bit Migration bei den Raspberries.
Inzwischen habe ich mir auch eine SD Karte mit dem offiziellen 64 Bit Raspian installiert und da funktioniert alles wieder wie es soll.
Ob es ein generelles Problem mit der Registrierung gibt, habe ich aktuell nicht getestet (das macht man ja nicht ständig).
In Zweifelsfall würde ich auf jeden Fall mal ein Update von signal-cli fahren (einfach den Installer mit "set reinit" aktualisieren und erneut durchlaufen lassen - sollte dann 0.11.7 installieren). Manchmal ändert sich was an der API und ältere Versionen haben Probleme.
Hmmm back again :-)
I tried a raspberry 64 bit installation and it seems to work but if I don´t receive messages.
When I run a test I get:
sudo /opt/fhem/www/signal/signal_install.sh test
You chose the following option: test
Start signal-cli service
Checking installation via dbus-send command...unexpected reply
method return time=1680446771.026133 sender=:1.62 -> destination=:1.63 serial=5 reply_serial=2 string "0.11.2"
Sending a message via perl Protocol::DBus...reply received
Any idea what could be wrong?
mfg
{HT}
Just tried the whole thing:
- Plain Raspian 64 lite installation on my Raspberry 400
- Installed fhem6.2.deb
- Created Signalbot device
- Used most current signal_install.sh to Install signal-cli 0.11.7
- Signalbot reinit -> Signalbot correctly showed signal-cli version, no account
Tried to copy /var/lib/signal-cli from my previous installation, however it somehow did not work, but I guess I used a too old backup that did not convert the config to 0.11.7 (there was no accounts.json which seems to be new in 0.11.7)
So I just started to register a number again, which worked as expected.
Could not send messages from the new Instance. (got an error that the recipient is not registered, though it was), however I could send messages TO the new instance and when I used the reply feature I could answer. I guess this is due to missing trust, that was created by re-registering. Once I sent a message from another device to the newly registered signal-cli instance and confirmed that it's ok that the device was changed, it started to work again in both directions.
In a nutshell: Only problems were the (expected) security issues with trust - apart from that all is working fine.
Hi
After the upgrade from 0.11.2 to 0.11.7 it works now on raspberry pi 64 bit.
For me a backup from 0.11.3 and a restore to my new installation worked.
Thanks for your work
mfg
{HT}
Hallo,
mich hat auch das letzte Update von Bullseye auf meinem Raspberry erwischt, so dass die Fehlermeldugn erschienen ist. Ich habe dann auch am Ende der /boot/config.txt die Zeile arm_64bit=0 eingefügt, so dass zumindest die Fehlermeldung beim Starten des Dienstes weg ist ;-)
root@fhem:~# systemctl status signal
● signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-04-12 07:47:24 CEST; 6min ago
Process: 614 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 988 (java)
Tasks: 37 (limit: 4915)
CPU: 12.182s
CGroup: /system.slice/signal.service
└─988 /usr/lib/jvm/java-17-openjdk-armhf/bin/java -Xms2m -classpath /opt/signal/lib/signal-cli-0.11.4.jar:/opt/signal/lib/lib.j>
Apr 12 07:46:59 fhem systemd[1]: Starting Send secure messages to Signal clients...
Apr 12 07:47:19 fhem signal-cli[988]: WARN MultiAccountManager - Ignoring +4961172389578: User is not registered. (NotRegisteredException)
Apr 12 07:47:23 fhem signal-cli[988]: INFO DaemonCommand - Starting daemon in multi-account mode
Apr 12 07:47:23 fhem signal-cli[988]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket to connect to unix:path>
Apr 12 07:47:24 fhem systemd[1]: Started Send secure messages to Signal clients.
Apr 12 07:47:24 fhem signal-cli[988]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
lines 1-16/16 (END)
Leider werden aber keine Nachrichten mehr verschickt. Bei Verbose 5 kommt folgendes:
[pre]2023.04.12 07:51:50 3: Signalbot: Before parse:@Marcus Test:
2023.04.12 07:51:50 4: Signalbot: sendMessage called for Marcus::Test
2023.04.12 07:51:50 5: Signalbot: Dbus Call sync:0 sendMessage(sasas) /org/asamk/Signal/_49XXX Args:Test,ARRAY(0x3e1a700),ARRAY(0x3e1a7a8)
2023.04.12 07:51:50 5: Signalbot: DBus callback: sendMessage Args:168127871005[/pre]
Das Device sieht folgendermaßen aus:
define Signalbot Signalbot
attr Signalbot DbLogExclude .*
attr Signalbot defaultPeer #Family
attr Signalbot event-on-change-reading .*
attr Signalbot group Netzwerk
attr Signalbot registerMethod Voice
attr Signalbot room Kommunikation
attr Signalbot showtime 1
attr Signalbot verbose 5
# FD 20
# FUUID 63c6ed5e-f33f-0756-da09-4c3476463cab5039
# NAME Signalbot
# NOTIFYDEV global
# NR 57
# NTFY_ORDER 50-Signalbot
# STATE Connected to /org/asamk/Signal/_49XXX
# TYPE Signalbot
# VERSION Signalbot:3.12 signal-cli:0.11.4 Protocol::DBus:0.22
# model Raspbian GNU/Linux 11 (bullseye)
# .attraggr:
# .attreocr:
# .*
# .attrminint:
# READINGS:
# 2023-04-12 07:47:56 account +49XXX
# 2023-04-12 07:47:56 accountName Home
# 2023-04-12 07:44:11 joinedGroups Family
# 2023-04-12 07:47:56 lastError ok
# 2023-04-12 07:51:50 sentMsg Test
# 2023-04-12 07:51:50 sentMsgTimestamp pending
# 2023-04-12 07:47:56 state Connected to /org/asamk/Signal/_XXX
# helper:
# accounts 1
# init 1
# multi 1
# signalpath /org/asamk/Signal/_XXX
# version 1104
# accountlist:
# +4961172389577
# attachments:
# contacts:
# +49XXX Marcus
# +49XXX XXX
# +49XXX XXX
# +49XXX Home
#
setstate Signalbot Connected to /org/asamk/Signal/_XXX
setstate Signalbot 2023-04-12 07:47:56 account +XXX
setstate Signalbot 2023-04-12 07:47:56 accountName Home
setstate Signalbot 2023-04-12 07:44:11 joinedGroups Family
setstate Signalbot 2023-04-12 07:47:56 lastError ok
setstate Signalbot 2023-04-12 07:51:50 sentMsg Test
setstate Signalbot 2023-04-12 07:51:50 sentMsgTimestamp pending
setstate Signalbot 2023-04-12 07:47:56 state Connected to /org/asamk/Signal/_49XXX
Was ist denn besser? Updaten und/oder Nummer neu registrieren?
Funktioniert das Problemlos, wenn man eine bestehende Nummer registriert?
Bei Neuinstallation vorher mit remove alles entfernen oder kann man einfach mit install drüber installieren ?
Die Nummer einfach nochmal neu zu registrieren hat keine Nachteile. Üblicherweise brauchts dann auch gar kein Captcha etc. mehr.
Kannst du Nachrichten empfangen?
Evtl. ist da auch nur ein "trust" Problem.
Sowas hatte ich nach meinen Tests - nachdem ich einmal eine Nachricht in Richtung Signalbot geschickt hatte, gings auch wieder in die andere Richtung.
Das war es tatsächlich. Ich konnte Nachrichten empfangen und danach auch wieder senden. Danke für die Hilfe.
Hi
I checked the wifi and the forum for an answer, but no luck.
I was trying to send a signal message to my friend and get and error. To make it easier, if I do this from the cli:
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_xxxxxxxxxx org.asamk.Signal.sendMessage string:Hallo array:string: string:+xxxxxxxxx
Error org.asamk.Signal.Error.Failure: Failure:
Failed to send message:
Unregistered user "+xxxxxxxx"
nnnnnnnnnnnn
:The numbers are correct and it works fine if I message to my own smartphone.
I see my number in var/lib/signal-cli/data/+xxxxxx.d
How can I add the number of my friend so I can send her a message too?
Thanks for a hint where I can find how to solve this.
{HT}
I have been seeing similar errors in cases when there was no trusted connection (so in this case: Your friend does not trust your signal-cli)
One thing that helped in my case was first sending a message the other way round (have your friend send something to signal-cli).
You could also use the commands to establish trust and exchange fingerprints.
Let me know if that helps. The "unregistered user" is misleading and we should probably open an issue with signal-cli to provide a better error message, if it really is the trust issue.
Hi
First sending a message from my friends phone did not help.
ExecStart=/opt/signal/bin/signal-cli --trust-new-identities=always --config /var/lib/signal-cli daemon --system
in signal-service didn´t help either.
Is there somewhere a link/hint how to establish trust? (in German is no problem (for reading))
{HT}
info:
/var/lib/signal-cli $ sudo -E -u signal-cli /opt/signal/bin/signal-cli -c /var/lib/signal-cli -a +xxxxxxxxx send -m "testmessage" +xxxxxxx
User +xxxxxxxx is not registered.
Doesn´t help either
As described in the (German) Wiki https://wiki.fhem.de/wiki/Signalbot you can establish trust by
sudo -E -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +49<Eigene Nummer> trust -a +49<zu vertrauende Nummer>
What happens when your friend sends a message to signal-cli? Do you receive it? Does he get an error?
Hi
I tried this already. No luck
sudo -E -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli -u +ooooooooooo trust -a +ffffffffff
The user +ffffffffff is not registered.
If my friend sends a message, it seems to work well. In fhem I can see the message send from my friends phone.
However early today the my friends phone give the double hook as a sign it was read. At the moment it gives only a single hook.
Any ideas?
As the problem seems to appear totally independant of FHEM, I suggest to open an issue with signal-cli at
https://github.com/AsamK/signal-cli/issues
As I have briefly seen the same behavior in my tests, I believe you're after a bug in signal-cli and as the problem is persistent with your installation, you should be the one to report it.
I checked the commit messages from signal-cli 0.11.7 to the current 0.11.8 and don't see anything that sounds related to your problem, but you probably should try it with 0.11.8 first.
I just checked and 0.11.8 uses the same native library, so you can just edit the installer to
SIGNALVERSION="0.11.8"and it should update your installation without issues.
Nachdem ich das jetzt kurz bei mir getestet habe, ist der Installer jetzt offiziell auf signal-cli 0.11.8 aktualisiert.
Hi
Just to inform you, I updated to 0.11.8 without problems.
My main problem is not changed. I am searching on the signal-cli info before filing a bugreport.
{HT}
Es gibt eine Möglichkeit signal-cli komplett als eine ausführbare Datei zu übersetzen.
Anleitung siehe
https://github.com/AsamK/signal-cli/blob/master/README.md#user-content-building-a-native-binary-with-graalvm-experimental
Ist aber nur für echte 64Bit (amd64, aarch64) möglich.
Auf dem Raspberry ist das aufgrund des immensen Speicherbedarfs nicht ganz so einfach. Wen es interessiert, ich habe ein entsprechendes (gezipptes) Binary mal hier hochgeladen
http://bublath.de/signal-cli.zip
Angeblich ist das dann performanter und braucht weniger Speicher (wobei das executable 110MB hat, aber kein eigenes Java mehr braucht)
Hi
I am lost.
I removed /opt/signal and used the current signal_install.sh.
The script says:
LIBRARYVERSION="0.22.0"
However if I run signal-cli with verbose options it reports:
INFO LibSignal - [libsignal]: rust/bridge/jni/src/logging.rs:156: Initializing libsignal version:0.20.0
The developer of signal-cli tells me I should upgrade to libsignal version: 0.22.0
How can I do that?
{HT}
Moin,
ist es möglich die registrierte Rufnummer zu ändern?
Grüße
Olli
@HarryT:
Hmmm not sure - maybe I made a mistake with the versions for aarch64
Check out this site:
https://github.com/exquo/signal-libs-build/releases/tag/libsignal_v0.22.2
It automatically builds the library for a couple of platforms. I'm actually considering using this source in the future, instead of building them myself.
sudo to the signal-cli user, then go to /opt/signal-cli/lib
copy the lib.so there
to update the embedded library execute:
zip -u libsignal-client-*.jar libsignal_jni.sothen restart the service.
Zitat von: octek0815 am 28 April 2023, 07:34:51ist es möglich die registrierte Rufnummer zu ändern?
Du kannst mehrere Nummer registrieren und zwischen diesen wechseln (set signalAccount)
Theoretisch kannst du die alte Nummer mit der versteckten Option "set unregister" (geht nur über Eingabezeile) entfernen - dadurch wird sie aber auch nur lokal entfernt - beim Signal Server bleibt die Registrierung m.E. erhalten.
Du kannst sogar mehrere Instanzen von Signalbot haben die dann auf verschiedene Nummern hören.
Hi
The version on https://github.com/exquo/signal-libs-build/releases/tag/libsignal_v0.22.2 worked on aarch64. And it solved my issue.
Thanks for your work and your help.
ps the tar.gz file contains libsignal_jni.so and not lib.so
{HT}
Zitat von: Adimarantis am 28 April 2023, 08:40:26Zitat von: octek0815 am 28 April 2023, 07:34:51ist es möglich die registrierte Rufnummer zu ändern?
Du kannst mehrere Nummer registrieren und zwischen diesen wechseln (set signalAccount)
Theoretisch kannst du die alte Nummer mit der versteckten Option "set unregister" (geht nur über Eingabezeile) entfernen - dadurch wird sie aber auch nur lokal entfernt - beim Signal Server bleibt die Registrierung m.E. erhalten.
Du kannst sogar mehrere Instanzen von Signalbot haben die dann auf verschiedene Nummern hören.
Alles klar, vielen Dank.
Hallo,
ich habe heute OS-Updates eingespielt, und danach startet signal-cli nicht mehr :(
Signal-cli ist die aktuellste Version:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.11.8 (libsignal-client v0.22.0)
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.28
Using Java version: /opt/java/bin/java
Native Java 17.0 no (current version:17.0)
Java bleibt mit einem Fehler hängen:
Failed to load native library:sqlite-3.41.2.1-dd6d22dc-38df-4e7c-9249-a1f400e18711-libsqlitejdbc.so. osinfo: Linux/aarch64
java.lang.UnsatisfiedLinkError: /tmp/sqlite-3.41.2.1-dd6d22dc-38df-4e7c-9249-a1f400e18711-libsqlitejdbc.so: /tmp/sqlite-3.41.2.1-dd6d22dc-38df-4e7c-9249-a1f400e18711-libsqlitejdbc.so: wrong ELF class: ELFCLASS64 (Possible cause: can't load AARCH64 .so on a ARM platform)
Hat noch Jemand Probleme mit dem Dienst, oder bin ich der Einzige?
Viele Grüße,
Daniel
Siehe letzter FAQ Eintrag im Wiki
Danke, genau das war es! Mit dem Eintrag in der /boot/config.txt und einem anschließenden Neustart läuft signal-cli wieder.
Nur für das Wiki: ich habe noch Buster im Einsatz - offenbar wurde hier erst im April umgestellt, letzten Monat ging es noch nach den OS-Updates.
Viele Grüße,
Daniel
Hallo,
seit Kurzem hat mein signal-Prozess in "top" immer 100% CPU, womit der Load des Raspberries auf >2 steigt. Fhem und auch Signalbot in Fhem funktionieren aber (wenn auch langsam). Die CPU Auslastung des fhem-Prozesses ist normal.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5322 signal-+ 20 0 378764 92096 18836 S 100,0 9,2 9:57.45 java
Ein Neustart des Prozesses mit "sudo service signal restart" und auch ein Neustarten des Raspberries hat keine Abhilfe geschaffen.
Im syslog ist nichts auffälliges zu finden bis auf eine Warnung "No profile name set":
May 7 09:50:41 rasp3fhem systemd[1]: Starting Send secure messages to Signal clients...
May 7 09:51:12 rasp3fhem signal-cli[5322]: INFO DaemonCommand - Starting daemon in multi-account mode
May 7 09:51:13 rasp3fhem signal-cli[5322]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket to connect to unix:path=/var/run/dbus/system_bus_socket
May 7 09:51:14 rasp3fhem systemd[1]: Started Send secure messages to Signal clients.
May 7 09:51:14 rasp3fhem signal-cli[5322]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
May 7 09:55:01 rasp3fhem CRON[6016]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
May 7 09:59:59 rasp3fhem signal-cli[5322]: WARN ManagerImpl - No profile name set. When sending a message it's recommended to set a profile name wit the updateProfile command. This may become mandatory in the future.
Unter /opt/signal/lib sind folgende lib-Versions:
-rw-r--r-- 1 signal-cli signal-cli 17536 Jan 2 1970 annotations-13.0.jar
-rw-r--r-- 1 signal-cli signal-cli 121908 Jan 2 1970 argparse4j-0.9.0.jar
-rw-r--r-- 1 signal-cli signal-cli 5867298 Jan 2 1970 bcprov-jdk15on-1.70.jar
-rw-r--r-- 1 signal-cli signal-cli 306047 Jan 2 1970 dbus-java-core-4.2.1.jar
-rw-r--r-- 1 signal-cli signal-cli 7864 Jan 2 1970 dbus-java-transport-native-unixsocket-4.2.1.jar
-rw-r--r-- 1 signal-cli signal-cli 161902 Jan 2 1970 HikariCP-5.0.1.jar
-rw-r--r-- 1 signal-cli signal-cli 75717 Jan 2 1970 jackson-annotations-2.13.4.jar
-rw-r--r-- 1 signal-cli signal-cli 374895 Jan 2 1970 jackson-core-2.13.4.jar
-rw-r--r-- 1 signal-cli signal-cli 1536894 Jan 2 1970 jackson-databind-2.13.4.jar
-rw-r--r-- 1 signal-cli signal-cli 19936 Jan 2 1970 jsr305-3.0.2.jar
-rw-r--r-- 1 signal-cli signal-cli 4716 Jan 2 1970 jul-to-slf4j-2.0.3.jar
-rw-r--r-- 1 signal-cli signal-cli 1509405 Jan 2 1970 kotlin-stdlib-1.6.20.jar
-rw-r--r-- 1 signal-cli signal-cli 200631 Jan 2 1970 kotlin-stdlib-common-1.6.20.jar
-rw-r--r-- 1 signal-cli signal-cli 23898 Jan 2 1970 kotlin-stdlib-jdk7-1.6.20.jar
-rw-r--r-- 1 signal-cli signal-cli 17773 Jan 2 1970 kotlin-stdlib-jdk8-1.6.20.jar
-rw-r--r-- 1 signal-cli signal-cli 687037 Jan 2 1970 lib.jar
-rw-r--r-- 1 signal-cli signal-cli 365199 Jan 2 1970 libphonenumber-8.12.54.jar
-rw-r--r-- 1 signal-cli signal-cli 9040106 Okt 7 2022 libsignal-client-0.20.0.jar
-rw-r--r-- 1 signal-cli signal-cli 266201 Jan 2 1970 logback-classic-1.4.3.jar
-rw-r--r-- 1 signal-cli signal-cli 576787 Jan 2 1970 logback-core-1.4.3.jar
-rw-r--r-- 1 signal-cli signal-cli 782603 Jan 2 1970 okhttp-4.10.0.jar
-rw-r--r-- 1 signal-cli signal-cli 345115 Jan 2 1970 okio-jvm-3.2.0.jar
-rw-r--r-- 1 signal-cli signal-cli 704122 Jan 2 1970 protobuf-javalite-3.21.7.jar
-rw-r--r-- 1 signal-cli signal-cli 11369 Jan 2 1970 reactive-streams-1.0.3.jar
-rw-r--r-- 1 signal-cli signal-cli 2648536 Jan 2 1970 rxjava-3.0.13.jar
-rw-r--r-- 1 signal-cli signal-cli 384533 Jan 2 1970 signal-cli-0.11.3.jar
-rw-r--r-- 1 signal-cli signal-cli 2070647 Jan 2 1970 signal-service-java-2.15.3_unofficial_61.jar
-rw-r--r-- 1 signal-cli signal-cli 61409 Jan 2 1970 slf4j-api-2.0.3.jar
-rw-r--r-- 1 signal-cli signal-cli 12718409 Jan 2 1970 sqlite-jdbc-3.39.3.0.jar
Ein "sudo -E ./signal_install.sh test" gibt Folgendes zurück:
You chose the following option: test
Start signal-cli service
Checking installation via dbus-send command...unexpected reply
method return time=1683448496.418892 sender=:1.331 -> destination=:1.333 serial=5 reply_serial=2 string "0.11.3"
Sending a message via perl Protocol::DBus...reply received
Jemand eine Idee, wie ich die Ursache herausfinden und beheben kann?
P.S. Das Profil habe ich versucht wie im Wiki beschrieben mit "sudo -E ./signal_install.sh name" zu setzen, hat aber nicht geklappt. "arch" gibt "armv7l" zurück. und "JAVA_HOME" ist auf die Java17-Installation (openjdk 17.0.1 2021-10-19) gesetzt. System ist Raspian Buster, welches genau wie fhem auf aktuellem Stand ist.
Ich sehe da jetzt auch nichts ungewöhnliches.
Wie schaut denn dein Gesamtsystem aus? Hast du z.B. noch genug freies RAM?
Du könntest auf jeden Fall mal versuchen das logging zu erhöhen und das in ein extra Logfile zu schreiben. Siehe
https://github.com/AsamK/signal-cli/blob/master/man/signal-cli.1.adoc
Das mit dem Profile darf nichts ausmachen. Das sollte aber übrigens inzwischen auch aus FHEM heraus gehen (set updateProfile).
ok, danke. Ich versuche es mal mit dem Logging.
Die Version von signal scheint nicht die Neueste zu sein. Oder hilft es einfach nochmal mit dem install-Skript neu drüber zu installieren?
RAM ist soweit ich das sehen kann ok, schwankt aber. Free zeigt:
total used free shared buff/cache available
Mem: 999036 391120 187540 6700 420376 539220
Swap: 0 0 0
...
total used free shared buff/cache available
Mem: 999036 313792 264872 6700 420372 616552
Habe jetzt nochmal mit dem "sudo -E ./signal_install.sh" drüber installiert bzw. auf signal-cli:0.11.8 aktualisiert, aber leider weiterhin 100% CPU...
Prozess sieht so aus:
signal-+ 5287 1 99 12:42 ? 00:00:40 /opt/java/bin/java -Xms2m -classpath /opt/signal/lib/signal-cli-0.11.8.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.70.jar:/opt/signal/lib/signal-service-java-2.15.3_unofficial_68.jar:/opt/signal/lib/jackson-module-kotlin-2.14.2.jar:/opt/signal/lib/jackson-annotations-2.14.2.jar:/opt/signal/lib/jackson-core-2.14.2.jar:/opt/signal/lib/jackson-databind-2.14.2.jar:/opt/signal/lib/argparse4j-0.9.0.jar:/opt/signal/lib/dbus-java-transport-native-unixsocket-4.3.0.jar:/opt/signal/lib/jul-to-slf4j-2.0.7.jar:/opt/signal/lib/logback-classic-1.4.6.jar:/opt/signal/lib/dbus-java-core-4.3.0.jar:/opt/signal/lib/HikariCP-5.0.1.jar:/opt/signal/lib/slf4j-api-2.0.7.jar:/opt/signal/lib/logback-core-1.4.6.jar:/opt/signal/lib/protobuf-javalite-3.22.2.jar:/opt/signal/lib/sqlite-jdbc-3.41.2.1.jar:/opt/signal/lib/jsr305-3.0.2.jar:/opt/signal/lib/okhttp-4.10.0.jar:/opt/signal/lib/okio-jvm-3.3.0.jar:/opt/signal/lib/kotlin-stdlib-jdk8-1.8.0.jar:/opt/signal/lib/libphonenumber-8.12.54.jar:/opt/signal/lib/libsignal-client-0.22.0.jar:/opt/signal/lib/r java-3.0.13.jar:/opt/signal/lib/kotlin-reflect-1.5.32.jar:/opt/signal/lib/kotlin-stdlib-jdk7-1.8.0.jar:/opt/signal/lib/kotlin-stdlib-1.8.0.jar:/opt/signal/lib/reactive-streams-1.0.3.jar:/opt/signal/lib/kotlin-stdlib-common-1.8.0.jar:/opt/signal/lib/annotations-13.0.jar org.asamk.signal.Main --config /var/lib/signal-cli daemon --system
Die config unter /etc/systemd/system/signal.service sieht so aus:
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket network-online.target
After=dbus.socket network-online.target
Wants=network-online.target
[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
Environment="JAVA_HOME=/opt/java"
ExecStartPre=/bin/sleep 10
ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
User=signal-cli
BusName=org.asamk.Signal
[Install]
WantedBy=multi-user.target
Alias=dbus-org.asamk.Signal.service
Oder ist die Java Version "17.0.1 2021-10-19" zu alt? Ich finde aber auch kein Update mit apt-get für mein altes Raspian OS Buster...
Ich habe jetzt nochmal mit "sudo -E ./signal_install.sh remove" alles gelöscht und mit "sudo -E ./signal_install.sh" mit anschließendem restore der config alles neu installiert mit dem nativen Java17. Trotzdem nimmt weiterhin der signal-Prozess 100% CPU...
Wenn ich alles neu installiere ohne die config zu restoren, dann bleibt der signal-Prozess unter 100%.
Ich versuche jetzt die config neu aufzubauen und mich neu zu registrieren. Jedoch nach Abarbeiten des Captchas und Powershell (oder manuellem copy&paste des links in fhem) die Fehlermeldung "Error with captcha:Error in registerWithCaptcha:RateLimitException [429] Rate limit exceeded: 429".
Kann hier jemand helfen?
Da hilft meines Wissen nur warten
selbst nach 10 Stunden Warten kommt diese Meldung.
Error with captcha:Error in registerWithCaptcha:RateLimitException [429] Rate limit exceeded: 429
Ist das normal?
War während deiner Wartezeit signal-cli aktiv? Nicht das der selbständig immer wieder was sendet und damit die Verbindung weiter zuballert. Stopp mal den Service und lass den ein paar Stunden aus.
Hier noch ein Hinweis dazu im signal-cli Projekt:
https://github.com/AsamK/signal-cli/issues/1225
Evtl. zwischendrin mal SMS probieren (oder Voice - je nachdem was du probiert hast)
Hat leider nicht geklappt mit der registrierung, immer kam rate limit fehler. Habe stattdessen config mit skript restored und dann die verzeichnisse datw/attachment gelöscht und dann ging es ohne 100% cpu auslastung.
es gab auch 2 merkwürdige und unbekannte kontakte unter ,,get contacts all". evtl haben die etwas mit der 100% cpu last zu tun.
Löschen kann man die kontakte scheinbar nicht, dahe habe die habe ich dann geblockt, aber kommt mir etwas komisch vor...
Gerade das Löschen von "kaputten" Kontakten scheint seitens signal-cli nicht zu funktionieren. So einen habe ich auch drin. Hab dazu einen Bug bei signal-cli aufgemacht.
Selbst wenn der Kontakt gelöscht wird, dann bleibt er als "identity" gespeichert die Nummer bleibt bei getContacts weiter sichtbar - nur der Name ist dann weg. Ist nicht so ganz konsistent gelöst - könnte man auch als Bug sehen.
Update Installer auf signal-cli 0.11.10
Die libsignal_jni.so wird jetzt von https://github.com/exquo/signal-libs-build geholt. Das hat den Vorteil dass diese dort automatisch generiert werden und meist sogar noch neuere Versionen als die benötigte zur Verfügung stellen (z.B. schon 0.24.0 - benötigt wird 0.23.1)
Bitte noch für X86 und AARCH64 testen - selber hab ich das jetzt nur für ARMV7 gemacht. Gebt Bescheid, wenn es wider erwarten Probleme mit den anderen Architekturen gibt.
Wenn ich also gerade mal nicht dazu komme den Installer upzudaten, sollte jeder einfach
SIGNALVERSION="0.11.10"
LIBRARYVERSION="0.23.1"entsprechend anpassen können.
Die aktuelle signal-cli Versionsnummer findet man unter
https://github.com/AsamK/signal-cli/releases
Um die passende Libraryversion rauszufinden, muss man im ausgepackten signal-cli nachschauen, welche Version die Datei
lib/libsignal-client-0.xx.x.jarhat, und diese Versionsnummer eintragen.
Einige Unicode Formatierung von Text sind möglich und funktionieren prima. Ist es auch möglich Hyperlinks / URLs über das Modul zu formatieren und versenden, so dass sie direkt beim Empfänger angeklickt werden können?
Sorry, ist erledigt. Das ging nur nicht in Kombination mit Markups.
FHEM ist mir heute abgestürzt, weil ich im laufenden Betrieb dbus neugestartet habe:
$ sudo systemctl restart dbus
FHEM wurde mit dieser Logmessage beendet (fuhr aber dank systemctl automatisch wieder hoch):
Protocol::DBus::X::SurpriseShutdown: The D-Bus connection closed unexpectedly!
==> X::Tiny::create('Protocol::DBus::X', 'SurpriseShutdown') (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Parser.pm at line 29)
==> Protocol::DBus::Parser::get_message(Protocol::DBus::Parser=HASH(0x6eaf100)) (called in /usr/local/share/perl/5.28.1/Protocol/DBus/Peer.pm at line 69)
==> Protocol::DBus::Peer::get_message(Protocol::DBus::Client=HASH(0x6e9ff30)) (called in /opt/fhem/FHEM/50_Signalbot.pm at line 1426)
==> main::Signalbot_Read(HASH(0x5ee6640)) (called in fhem.pl at line 3980)
==> main::CallFn('Signal', 'ReadFn', HASH(0x5ee6640)) (called in fhem.pl at line 784)
Vielleicht kann man das im Modul irgendwie abfangen und einen Absturz verhindern?
(Nicht dass ich jetzt regelmäßig dbus auf der Kommandozeile neustarten würde :) )
Das Problem konnte ich nachstellen.
Habe eine aktualisierte Version eingecheckt die den Fehler abfängt und Signalbot neu initialisiert.
Hallo zusammen,
meine Signal-cli Installation hat sich wohl zerlegt. Leider kann ich nicht genau sagen, ob es bei einem Update passiert ist.
Auch eine alte Version (11.2) bekomme ich nicht mehr installiert. Hat jemand einen Tip für mich?
Auf dem Alten raspi-3 mit 32-bit raspbian hat das update auf V-11.10 einwandfrei geklappt.
Gruß Thomas
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
aarch64
Openjdk ist Version 17.0.6
/var/log/syslog:
Jun 19 21:58:30 rpi4 dbus-daemon[1532]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.service' requested by ':1.15' (uid=0 pid=2194 comm="perl /tmp/signal1959.tmp ")
Jun 19 21:58:30 rpi4 systemd[1]: Starting Send secure messages to Signal clients...
Jun 19 21:58:43 rpi4 signal-cli[2198]: OpenJDK Client VM warning: You have loaded library /tmp/resource16174790641101377256.so which might have disabled stack guard. The VM will try to fix the stack guard now.
Jun 19 21:58:43 rpi4 signal-cli[2198]: It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Jun 19 21:58:43 rpi4 signal-cli[2198]: WARN ServiceConfig - Failed to call libsignal-client: /tmp/resource16174790641101377256.so: /tmp/resource16174790641101377256.so: falsche ELF-Klasse: ELFCLASS64 (Possible cause: can't load AMD 64 .so on a ARM platform)
Jun 19 21:58:43 rpi4 signal-cli[2198]: Missing required native library dependency: libsignal-client
Jun 19 21:58:53 rpi4 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Jun 19 21:58:53 rpi4 systemd[1]: signal.service: Failed with result 'exit-code'.
Jun 19 21:58:53 rpi4 systemd[1]: Failed to start Send secure messages to Signal clients.
Jun 19 21:58:53 rpi4 systemd[1]: signal.service: Consumed 3.526s CPU time.
Schau dir mal den letzten Eintrag im Wiki Troubleshooting an
https://wiki.fhem.de/wiki/Signalbot#Troubleshooting_/_FAQ
Hallo zusammen,
leider habe auch ich seit gestern ein Problem.
Nach einem Absturz des Servers startete signal nicht mehr und der Status im FHEM ist immer disconnected.
Wie es aussah, war die registrierung durch den Absturz korrumpiert gewesen, also alles nochmal mit dem Script entfernt und neuinstalliert und die Nummer neu registriert
Signal läuft und es ist möglich über die Kommandozeile Nachrichten zu verschicken.
sudo systemctl status signal
● signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; preset: enabled)
Active: active (running) since Sun 2023-06-25 12:28:38 CEST; 6min ago
Process: 8591 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 8592 (java)
Tasks: 27 (limit: 19022)
Memory: 90.9M
CPU: 6.030s
CGroup: /system.slice/signal.service
└─8592 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.11.10.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.70.jar:/opt/signal/lib/signal-service-java-2.15.3_unofficial_70.jar:/opt/signal/lib/jackson-module-kotlin-2.15.0.jar:/opt/signal/lib/jackson-annotations-2.15.0.jar:/opt/signal/lib/jackson-core-2.15.0.jar:/opt/signal/lib/jackson-databind-2.15.0.jar:/opt/signal/lib/argparse4j-0.9.0.jar:/opt/signal/lib/dbus-java-transport-native-unixsocket-4.3.0.jar:/opt/signal/lib/jul-to-slf4j-2.0.7.jar:/opt/signal/lib/logback-classic-1.4.7.jar:/opt/signal/lib/dbus-java-core-4.3.0.jar:/opt/signal/lib/HikariCP-5.0.1.jar:/opt/signal/lib/slf4j-api-2.0.7.jar:/opt/signal/lib/logback-core-1.4.7.jar:/opt/signal/lib/protobuf-javalite-3.23.0.jar:/opt/signal/lib/sqlite-jdbc-3.41.2.1.jar:/opt/signal/lib/fastdoubleparser-0.8.0.jar:/opt/signal/lib/jsr305-3.0.2.jar:/opt/signal/lib/okhttp-4.10.0.jar:>
Jun 25 12:28:26 FHEM systemd[1]: Starting signal.service - Send secure messages to Signal clients...
Jun 25 12:28:37 FHEM signal-cli[8592]: INFO DaemonCommand - Starting daemon in multi-account mode
Jun 25 12:28:38 FHEM signal-cli[8592]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket for address unix:path=/var/run/dbus/system_bus_socket
Jun 25 12:28:38 FHEM systemd[1]: Started signal.service - Send secure messages to Signal clients.
Jun 25 12:28:38 FHEM signal-cli[8592]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
Dbus läuft eigentlich auch:
sudo systemctl status dbus
● dbus.service - D-Bus System Message Bus
Loaded: loaded (/lib/systemd/system/dbus.service; static)
Active: active (running) since Sun 2023-06-25 12:28:25 CEST; 6min ago
TriggeredBy: ● dbus.socket
Docs: man:dbus-daemon(1)
Main PID: 8584 (dbus-daemon)
Tasks: 1 (limit: 19022)
Memory: 732.0K
CPU: 19ms
CGroup: /system.slice/dbus.service
└─8584 @dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Jun 25 12:28:25 FHEM systemd[1]: Starting dbus.service - D-Bus System Message Bus...
Jun 25 12:28:25 FHEM dbus-daemon[8584]: [system] AppArmor D-Bus mediation is enabled
Jun 25 12:28:25 FHEM systemd[1]: Started dbus.service - D-Bus System Message Bus.
Jun 25 12:28:25 FHEM dbus-daemon[8584]: [system] Activating via systemd: service name='org.asamk.Signal' unit='dbus-org.asamk.Signal.service' requested by ':1.0' (uid=1000 pid=136 comm="/usr/bin/perl fhem.pl fhem.cfg" label="unconfined")
Jun 25 12:28:38 FHEM dbus-daemon[8584]: [system] Successfully activated service 'org.asamk.Signal'
Aber es ist nicht möglich über Dbus Nachrichten zu versenden:
signal-cli --dbus send -m "Message" +49***
INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket for address unix:path=/run/user/1000/bus
signal-cli DBus daemon not running on session bus: The name org.asamk.Signal was not provided by any .service files
Und im FHEM ist das Device immer disconnected.
Hier nocht das signal_install.log:
PRETTY_NAME="Ubuntu 23.04"
NAME="Ubuntu"
VERSION_ID="23.04"
VERSION="23.04 (Lunar Lobster)"
VERSION_CODENAME=lunar
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=lunar
LOGO=ubuntu-logo
Was mache ich falsch?
Zitat von: Adimarantis am 20 Juni 2023, 22:32:04Schau dir mal den letzten Eintrag im Wiki Troubleshooting an
Das habe ich gemacht und auch umgestellt. Trotzdem funktionierte es nicht. Erst nach einem remove, Neuinstallation und restore geht es jetzt wieder. Leider zickt Nextcloud nun rum, dass es ein 32 bit OS ist.
Hat wirklich keiner eine Idee, ich verzweifele an dem Thema gerade.
Also was ich auf die schnelle schon mal sehe:
Dein Test
signal-cli --dbus send -m "Message" +49***macht aus mehreren Gründen (falscher Bus, der dbus parameter ist dazu da signal-cli als daemon und nicht als client zu verwenden .....) keinen Sinn.
Ich empfehle da als test eher das "dbus-send" Kommando, beschrieben im Wiki unter https://wiki.fhem.de/wiki/Signalbot#Versenden_von_Nachrichten_ohne_FHEM
Ubuntu dürfte ein echtes 64-bit System - der zitierte Workaround ist für Raspberry auf Arm. Ich schätze mal du bist auf x86?
Jetzt kann ich aber in deinen Logs (bis auf deinen vom Ansatz her falschen Testversuch) keine Fehler erkennen. Da wäre jetzt eher in Blick ins syslog und ins fhem log angesagt.
Hallo Jörg,
danke für den Hinweis, mein Problem lag an einem Durcheinander der Profile.
Habe ich nun geradegebogen und es läuft jetzt.
Hallo,
im Sommer letzten Jahres hatte ich Signalbot mit signal-cli erfolgreich am Laufen. Zwischenzeitliche Updates (FHEM, Signal, Betriebssystem) haben etwas kaputtgemacht und nun muss ich signal-cli wieder zum Laufen bekommen. Im Troubleshooting-Abschnitt im Wiki hatte ich für mich nichts zutreffendes ausmachen können.
Linux vserver 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux
FHEM aktuell
Alles mit dem aktuellen ./signal_install.sh aus www/signal installiert.
Service startet nicht. Ausgabe von
# sudo -u signal-cli /opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system
WARN LegacyRecipientStore2 - Failed to load recipient store
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2$Storage` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (FileInputStream); line: 2, column: 3]
at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:67)
at com.fasterxml.jackson.databind.DeserializationContext.reportBadDefinition(DeserializationContext.java:1915)
at com.fasterxml.jackson.databind.DatabindContext.reportBadDefinition(DatabindContext.java:414)
at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1360)
at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1424)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4825)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3809)
at org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2.migrate(LegacyRecipientStore2.java:30)
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:647)
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:187)
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:92)
at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:64)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:72)
at org.asamk.signal.App.handleMultiLocalCommand(App.java:316)
at org.asamk.signal.App.init(App.java:198)
at org.asamk.signal.Main.main(Main.java:60)
ERROR MultiAccountManager - Failed to load +49REDACTED: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2$Storage` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (FileInputStream); line: 2, column: 3] (RuntimeException)
java.lang.RuntimeException: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2$Storage` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (FileInputStream); line: 2, column: 3]
at org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2.migrate(LegacyRecipientStore2.java:91)
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:647)
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:187)
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:92)
at org.asamk.signal.manager.SignalAccountFiles.lambda$initMultiAccountManager$1(SignalAccountFiles.java:64)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1707)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.Nodes$CollectorTask.doLeaf(Nodes.java:2183)
at java.base/java.util.stream.Nodes$CollectorTask$OfRef.doLeaf(Nodes.java:2193)
at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:686)
at java.base/java.util.stream.Nodes.collect(Nodes.java:328)
at java.base/java.util.stream.ReferencePipeline.evaluateToNode(ReferencePipeline.java:111)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:570)
at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616)
at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622)
at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627)
at org.asamk.signal.manager.SignalAccountFiles.initMultiAccountManager(SignalAccountFiles.java:72)
at org.asamk.signal.App.handleMultiLocalCommand(App.java:316)
at org.asamk.signal.App.init(App.java:198)
at org.asamk.signal.Main.main(Main.java:60)
Caused by: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2$Storage` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
at [Source: (FileInputStream); line: 2, column: 3]
at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:67)
at com.fasterxml.jackson.databind.DeserializationContext.reportBadDefinition(DeserializationContext.java:1915)
at com.fasterxml.jackson.databind.DatabindContext.reportBadDefinition(DatabindContext.java:414)
at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1360)
at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1424)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4825)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3809)
at org.asamk.signal.manager.storage.recipients.LegacyRecipientStore2.migrate(LegacyRecipientStore2.java:30)
... 25 more
Mein avatars und data liegen unter /var/lib/signal-cli/. Es funktioniert aber auch nicht, wenn ich sie nach /home/signal-cli/ kopiere (und den User auf signal-cli:signal-cli setze).
Es war schon letztes Jahr für mich das größte Problem, den richtigen Ablageort herauszufinden. Der scheint von Version zu Version zu wechseln./var/lib/signal-cli/ scheint richtig zu sein, weil das im Befehl auch so angegeben ist.
Was muss ich richtig machen?
Viele Grüße
Boris
Mit welcher signal-cli Version wurde deine Konfiguration denn zum letzten mal erfolgreich verwendet?
signal-cli hat irgendwann (ab 0.10.x glaube ich) von eine Textdatei basierten Konfiguration auf eine Datenbank umgestellt.
Gut möglich, dass ein zu großer Versionsschritt die Config nicht mehr ordnungsgemäß migrieren kann.
Du könntest dann mühselig versuchen Zwischenversionen zu installieren um die Config zu migrieren.
Ich schätze aber, dass es schneller und sicherer ist, alles unter /var/lib/signal-cli zu löschen und die Telefonnummer sauber neu zu registrieren.
Man verliert dabei eigentlich nichts wichtiges.
Zitat von: Adimarantis am 01 Juli 2023, 18:19:38Mit welcher signal-cli Version wurde deine Konfiguration denn zum letzten mal erfolgreich verwendet?
signal-cli hat irgendwann (ab 0.10.x glaube ich) von eine Textdatei basierten Konfiguration auf eine Datenbank umgestellt.
Gut möglich, dass ein zu großer Versionsschritt die Config nicht mehr ordnungsgemäß migrieren kann.
Danke für die Info. Ich hatte signal-cli letzten Sommer/Herbst noch am Laufen. Da war die aktuelle Version schon 0.10.x.
ZitatDu könntest dann mühselig versuchen Zwischenversionen zu installieren um die Config zu migrieren.
Ich schätze aber, dass es schneller und sicherer ist, alles unter /var/lib/signal-cli zu löschen und die Telefonnummer sauber neu zu registrieren.
Man verliert dabei eigentlich nichts wichtiges.
Am besten registriere ich neu. Allerdings muss ich dafür erstmal wieder ein Haustelefon aktivieren - wir haben zwar noch eine Telefonnummer aber die wird nicht mehr benutzt.
Bei meiner Hausautomation komme ich immer vom Hundertsten ins Tausendste :(
@ Boris
nur zur Info, seit Kurzem muss man bei Festnetz erst mit SMS registrieren, dann ~1min warten und erst dann mit voice.
Danke @nighthawk.
Ich scheitere derzeit mit einem Rate Limit exceeded beim Captcha.
Ich versuche es morgen wieder.
Hallo,
ich habe soeben wieder versucht, einen Code für ein gelöstes Captcha zu erhalten. Ich ende wieder mit
Error with captcha:Error in registerWithCaptcha:RateLimitException [429] Rate limit exceeded: 429
Ich habe es sowohl im FHEM-Webinterface unter Linux als auch unter Windows, jeweils mit Firefox, und auch durch Eingabe des signal-captcha-Links auf der Console per
./signal-cli -u +49........ register --captcha signal-hcaptcha......
versucht. Ich bekomme immer wieder nur diese Meldung.
Wie komme ich jetzt noch weiter?
Viele Grüße
Boris
Probierst du es mit "Voice"?
Es gibt wohl ein Problem, dass man Nummern erst mit SMS anfragen muss (auch wenn das bei Festnetz meist keinen Sinn macht).
Wenn man dann 1 Minute später Voice probiert geht es üblicherweise
Zitat von: Adimarantis am 03 Juli 2023, 17:32:26Probierst du es mit "Voice"?
Es gibt wohl ein Problem, dass man Nummern erst mit SMS anfragen muss (auch wenn das bei Festnetz meist keinen Sinn macht).
Wenn man dann 1 Minute später Voice probiert geht es üblicherweise
Ich habe den data-Ordner gelöscht, den Service und FHEM neu gestartet, und die Registrierung mit Methode SMS versucht. Ich benutze die Browserintegration unter Windows, löse das Captcha, lasse den Befehl in FHEM (set ... captcha) ausführen, und... nix passiert, weißes Browser-Fenster. FHEM sagt weiterhin, dass ich ein Captcha lösen soll.
Mittlerweile bekomme ich auf ein nacktes
root@vserver:/opt/signal/bin# ./signal-cli -u +49.......registerauf der Konsole schon die Rate-Limit-Exceeded-Meldung.
Der Signal-Captcha-Link enthält hinten ein
&fwcsrf=csrf_10265255619415.... Wird das bei der Automation weggeschnippelt?
Die Automatisierung hängt das csrf extra an - das sollte von FHEM eigentlich korrekt interpretiert (also auch wieder entfernt) werden.
Du kannst im "list" vom Device nachsehen wie er es empfangen hat. Da gibt es eine helper variable die das Captcha speichert.
Auf der Konsole solltest es ja wirklich dann gehen. Eben erst mit SMS, dann mit Voice. Hast du evtl. alternative Nummern die du probieren kannst?
Wenn das da schon fehlschlägt, evtl. mal bei signal-cli nachfragen: https://github.com/AsamK/signal-cli/issues
Danke für die Ermutigung. Ich habe die erste Hürde genommen.
Zunächst habe ich den Signal-Dienst gestoppt, mit dem Script www/signal/signall_install.sh remove die Installation entfernt, /var/lib/signal-cli ist leer, das Signal-Device in FHEM gelöscht, die Konfiguration gespeichert, und FHEM neugestartet. Danach habe ich mit dem Script Signal wieder installiert. Das war wahrscheinlich nicht nötig, aber ich wollte ausgehend von einem sauberen Stand der Anleitung folgen.
Der Weg über Anlage eines SignalBot-Device in FHEM mit Captcha-Automation (Windows) hat viele Fehlerquellen. Nach einer Registrierung und Lösen des Captchas wird die Firefoxseite aufgerufen mit dem cmd in der URL. Auch wenn ich diese Zeile nochmal mit Enter abschicke, wird das Captcha nicht in FHEM übernommen (Helper-Variable captcha unbelegt). In der URL steht &fwcsrf=csrf_10265255619415... Ich bin dann auf Chrome als Standardbrowser ausgewichen und habe das Captcha erneut gelöst. Die Ausführung des cmd im URL gibt einen Fehler (vergessen, invalid URL oder so). Das Captcha kommt in FHEM nicht an.
Ich habe daher den Weg über die Kommandozeile gewählt wie in der signal-cli-Anleitung auf Github beschrieben. Das Captcha habe ich in Chrome gelöst, die automatische Übergabe per cmd an FHEM abgebrochen und die URL hinter dem Link "Signal öffnen" kopiert. Diese enthält übrigens nicht &fwcsrf=csrf_10265255619415.... Das Captcha habe ich dann an signal-cli übergeben. Ich habe dasselbe Captcha gleich danach nochmal an signal-cli übergeben mit --voice zusätzlich. Der Anruf kam, hat den Verification Code vorgelesen, ich konnte per signal-cli erfolgreich verifizieren. Das ganze habe ich aber auch zweimal machen müssen, bis es ohne Status 504 oder rate limit exceeded durchlief.
Ich kann jetzt per signal-cli erfolgreich Nachrichten senden.
FHEM erkennt die Registrierung aber nicht, auch nicht nach Neustart des Signal-Service. Ich meine, dass es an der DBUS-Integration hängt.
# systemctl status signal
● signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2023-07-06 18:56:45 CEST; 12s ago
Process: 965558 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 965564 (java)
Tasks: 31 (limit: 4684)
Memory: 89.9M
CPU: 2.618s
CGroup: /system.slice/signal.service
└─965564 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.11.10.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.70.jar:/opt/signal/>
Jul 06 18:56:34 vserver systemd[1]: Starting Send secure messages to Signal clients...
Jul 06 18:56:45 vserver signal-cli[965564]: WARN MultiAccountManager - Ignoring +49MEINENUMMER: User is not registered. (NotRegisteredException)
Jul 06 18:56:45 vserver signal-cli[965564]: INFO DaemonCommand - Starting daemon in multi-account mode
Jul 06 18:56:45 vserver signal-cli[965564]: INFO TransportBuilder - Using transport dbus-java-transport-native-unixsocket for address unix:path=/var/run/dbus/s>
Jul 06 18:56:45 vserver systemd[1]: Started Send secure messages to Signal clients.
Jul 06 18:56:45 vserver signal-cli[965564]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
NotRegisteredException wird gemeldet und ein Neustart des Dienstes behebt das nicht.
Das Problem habe ich im Troubleshooting-Abschnitt im Wiki nicht gesehen.
Der dbus-send-Befehl im Wiki läuft auf eine Fehlermeldung. Dazu habe ich noch eine Frage:
Kommt in
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_xxxxxx org.asamk.Signal.sendMessage string:Hallo array:string: string:+49yyyy der Unterstrich hin und sieht der Mittelteil dann so
/org/asamk/Signal/_+49MEINENUMMER aus? Das connected to in FHEM kann ich ja nicht ablesen, weil nichts connected ist.
Ich bräuchte hier bitte nochmal Hilfe.
Ich bekomme folgenden log Eintrag:
Unknown callback ReceiptReceivedV2
Hat jemand einen Tip für mich?
@Boris:
Statt die Automatisierung zu verwenden (muss ich mal wieder testen, vieleicht klemmt es da), wäre es wohl am Besten gewesen das Captcha per Copy&Paste in den "set captcha" Befehl zu kopieren. Das csrf token wird wie gesagt nur für die Automatierung angehängt, sofern du das in deiner FHEM Instanz nutzt. Daher muss das .reg File auch immer aktuell neu eingespielt werden.
Als du das mit der Kommandozeile gemacht hat, was hast du als Speicherort für die Config angegeben? (--config Parameter)
Wenn du nichts angibts landet die Config nämlich in
$HOME/.local/share/signal-cliwogegen die FHEM installation sie unter
/var/lib/signal-cliIn dem Fall kopiere das "data" Verzeichnis einfach an die richtige Stelle (vorher den signal service stoppen).
Wichtig auch noch, dass noch die Zugriffsrechte anpasst:
chown -R signal-cli:signal-cli /var/lib/signal-cli
Dann sollte es eigentlich funktionieren. Wenn du jetzt den signal service wieder startest und in FHEM ein "reinit" machst (evtl. noch ein get accounts), dann solltest du in "set signalAccount" deine Nummer auswählen können.
Jörg
Zitat von: berniie am 07 Juli 2023, 12:24:02Unknown callback ReceiptReceivedV2
Alles gut, das ist einfach nicht implementiert - wird aber auch nicht benötigt.
Du solltest vielleicht verbose runtersetzen. Solange es keine Probleme gibt, sollte 1 - allerhöchstens 3 reichen. Diese Nachricht kommt bei 4.
Zitat von: Adimarantis am 07 Juli 2023, 13:23:57@Boris:
Statt die Automatisierung zu verwenden (muss ich mal wieder testen, vieleicht klemmt es da), wäre es wohl am Besten gewesen das Captcha per Copy&Paste in den "set captcha" Befehl zu kopieren. Das csrf token wird wie gesagt nur für die Automatierung angehängt, sofern du das in deiner FHEM Instanz nutzt. Daher muss das .reg File auch immer aktuell neu eingespielt werden.
...
In dem Fall kopiere das "data" Verzeichnis einfach an die richtige Stelle (vorher den signal service stoppen).
Ich tat wie mir geheißen wurde. Und es funktioniert. Vielen Dank, Jörg.
Jetzt kann ich mich mit den Benachrichtigungen über MSG-Modul herumschlagen :-)
Ich finde den Ansatz über das FHEMWEB-GUI und die Automatisierung den Hausautomatisierern einen einfachen Zugang zu verschaffen, sehr gut. Allein, ich bin über vielfältige Hürden gestrauchelt:
- Dass man Festnetztelefone erst mit SMS und dann erst mit Voice registrieren muss.
- Dass die Automation nicht das Captcha setzt.
- Dass möglicherweise(!) Firefox aktuell nicht geht aber Chrome.
- Dass man bei manueller Registrierung noch an die Verschiebung der Konfiguration vom Verzeichnis des verwendeten Users auf /var/lib/signal-cli denken muss, wobei die bei mir existierenden Verzeichnisse /home/signal-cli und /opt/signal die Möglichkeiten, sich zu verirren, noch vergrößeren.
- An Neustart vom Service und reinit zu denken, war mir jederzeit bewusst, kann aber für andere eine Hürde sein.
- Irritiert hat mich noch die Medung im FHEMWEB-GUI, dass Signalbot unbedingt signal-cli v0.11.. erwartet, obwohl ich das installiert hatte.
Das ist keine Kritik an Deiner Arbeit oder an Signalbot. Ich wüsste auch nicht, wie ich es besser machen kann. Allenfalls noch an der Doku im Wiki arbeiten und den Ablauf und die Stolperfallen ausführlich beschreiben.
Zitat von: Dr. Boris Neubert am 06 Juli 2023, 19:20:42Kommt in
dbus-send --system --type=method_call --print-reply --dest=org.asamk.Signal /org/asamk/Signal/_xxxxxx org.asamk.Signal.sendMessage string:Hallo array:string: string:+49yyyy der Unterstrich hin und sieht der Mittelteil dann so
/org/asamk/Signal/_+49MEINENUMMER aus? Das connected to in FHEM kann ich ja nicht ablesen, weil nichts connected ist.
Das beantworte ich jetzt selbst: das _ ersetzt das +
Es sieht im Mittelteil also so aus:
/org/asamk/Signal/_49MEINENUMMER
Hallo Boris,
danke für dein Feedback. Ich habe ein paar Updates im Wiki gemacht. Die "-c" Option für die Config stand eigentlich schon drin :)
Wie gesagt muss ich die Automatisierung nochmal testen. Leider ist halt der Grund für die Captchas ja genau "bösartige" Automatierungen auszubremsen, was es jetzt nicht unbedingt trivial macht eine "gutartige" Automatierung zu realisieren.
Freut mich zumindest, dass du letztendlich Erfolg hattest.
Jörg
Hallo!
Ich versuche gerade meine Signal Anbindung wieder zum laufen zu bringen. Ich hatte eine zu alte signal-cli Version. Diese habe ich jetzt auf 0.11.11 upgedatet und dann versucht, meine (Festnetz-)Nummer wieder zu registrieren. Mit signal-cli -u <+49...> register --voice hat es nicht geklappt, da ein Captcha nötig war. Dieses habe ich über https://signalcaptchas.org/registration/generate generiert und dann mit signal-cli -u <+49...> register --voice --captcha 'signal-hcaptcha.5f...' verwendet. Leider bekomme ich dann nur die Fehlermeldung "Failed to register: [429] Rate limit exceeded: 429 (RateLimitException)". Ich hab es bisher zwar ein paar Mal probiert, das letze mal aber mehrere Stunden pause zwischen zwei Versuchen gelassen. Was könnte ich noch machen?
Gruß,
Reiner
Zitat von: reibuehl am 07 August 2023, 09:25:22Ich versuche gerade meine Signal Anbindung wieder zum laufen zu bringen. Ich hatte eine zu alte signal-cli Version. Diese habe ich jetzt auf 0.11.11 upgedatet und dann versucht, meine (Festnetz-)Nummer wieder zu registrieren. Mit signal-cli -u <+49...> register --voice hat es nicht geklappt, da ein Captcha nötig war. Dieses habe ich über https://signalcaptchas.org/registration/generate generiert und dann mit signal-cli -u <+49...> register --voice --captcha 'signal-hcaptcha.5f...' verwendet. Leider bekomme ich dann nur die Fehlermeldung "Failed to register: [429] Rate limit exceeded: 429 (RateLimitException)". Ich hab es bisher zwar ein paar Mal probiert, das letze mal aber mehrere Stunden pause zwischen zwei Versuchen gelassen. Was könnte ich noch machen?
Voice-Anmeldung ist extrem wiggelig. Ich habe das vor drei Wochen durchgemacht, siehe die unmittelbar vorausgehenden Beiträge in diesem Thema hier.
Da ich zig Fehlerstellen im Prozess hatte, kann ich nicht sagen, was am Ende geholfen hat. Aber Du solltest erst die Registrierung mit SMS versuchen. Wenn Du Glück hast, ruft Dich der Automat Deines Telefonieproviders an und liest Dir die SMS vor. Ansonsten versuchst Du es danach erneut mit --voice. Zur Sicherheit solltest Du auch einen Tag zwischen dem Erhalt der Fehlermeldung wegen Rate limit und dem neuen Versuch vergehen lassen.
Das "rate limit exceeded" scheint leider ein hartnäckiges Problem zu sein. Siehe
https://github.com/AsamK/signal-cli/issues?q=rate+limit+exceeded
Es gibt da ein paar Tipps, das meiste ist aber nur Spekulation und "Trial+Error" - aber vielleicht hilft irgendwas davon.
P.S. Ich sehe, dass bei Signal-Cli gerade ein deutlicher Versionssprung der native Library eingecheckt wurde. Vielleicht behebt die ja auch was. Da müssen wir aber wohl noch auf das offizielle release warten - oder signal-cli selber bauen.
Neue Version Signalbot V3.15Benötigt signal-cli V0.12 für einige der neuen Funktionen. Dazu nach dem FHEM update einfach signal_install.sh (V3.18) starten + "set reinit"
Verfügbar auf SVN und ab morgen, 12.8. per update
Was ist neu?
- get identityDetails:
Zeigt Informationen bezüglich des Vertrauensstatus (Trust) eines Kontakts, sowie einen QR Code womit FHEM als "trusted" mit der Signal App verifziert werden kann - get chat
Zeigt eine kleine History (maximal 20 Zeilen) der Nachrichten die mit einer Person oder einer Gruppe verschickt wurden
Diese ist "flüchtig", geht also durch einen Neustart etc. verloren - set trust <all oder Kontakt>
Setzt den Trust eines Kontakts oder aller Kontakte auf "TRUSTED_UNVERIFIED". Damit wird z.B. nach dem Wechsel des Smartphone sichergestellt, dass man mit diesem Kontakt uneingeschränkt kommunizieren kann - set trustVerified <Kontakt> <Sicherheitsnummer>
Setzt den Trust eines Kontakts auf "TRUSTED_VERIFIED". Dazu ist die Sicherheitsnummer für den jeweiligen Kontakt anzugeben. Wer auf Nummer sicher gehen will lässt sich die von dem jeweiligen Kontakt auf einem vetrautem Kanal zukommen (oder tippt sie vom Telefon ab). Die Nummer ist aber symetrisch, d.h. "get identityDetails" zeigt diese auch an - kann man also auch per copy + paste von dort nehmen, wenn man sich sicher ist
Die Optionen befüllen die entsprechenden Pulldowns überlicherweise mit bekannten Kontakten und schränken die Liste auf sinnvolle Kontakte ein (z.B. zeigt "set trust" keine Kontakte an, denen schon vertraut wird). Manchmal muss man die Seite neu laden, damit die Pulldowns Änderungen korrekt reflektieren.
Durch die Möglichkeit die Identität des Kommunikationspartners zweifelsfrei zu validieren, ergibt sich die Option dies für die Remote Kommandos zu nutzen. Wenn das Attribut "authTrusted" auf "yes" steht, dann dürfen Kontakte die "TRUSTED_VERIFIED" sind, Kommandos nach FHEM schicken ohne sich per GoogleAuth zu authentifizieren.
Da eine Weile seit dem letzten Update vergangen ist, sind sicher einige andere kleinere Änderungen eingeflossen. Lasst mich wissen falls ihr noch Fehler findet - bei so einem grossen Update sind wahrscheinlich noch welche drin.
Jörg
Hallo Jörg,
danke für deine Arbeit.
Update bei mir erfolgreich.
Hallo,
ich habe signalbot mit aktueller Version installiert.
Versenden von Nachrichten funktioniert.
Empfangen leider nicht.
Im Log-File konnte ich nichts in der Richtung sehen.
In den Readings kommt auch nichts an.
Wo könnte ich suchen?
Grüße
Carsten
Schon alles nochmal durchgestartet (signal-cli, FHEM)?
Steht was in /var/log/syslog - da sollte signal-cli selbst protokollieren?
Wie ist der "trust" Status des Absenders (get identityDetails) ?
Wenn der "UNTRUSTED" mal zumindest ein "set trust all" machen.
Selbsttest geht (sudo signal_install.sh test)?
Auf meinem Raspi's läuft alles, daher denke ich nicht das dies ein grundsätzliches Problem mit der Version ist. X86 hab ich aber nicht getestet.
@Adimarantis
Danke für deine tolle Arbeit.
Auf x86 bei mir keine Probleme.
Gruß LuGu
Vielen Dank für die weiterführenden Testschritte !!!
Zitat von: Adimarantis am 13 August 2023, 11:37:01Schon alles nochmal durchgestartet (signal-cli, FHEM)?
ja
Zitat von: Adimarantis am 13 August 2023, 11:37:01Steht was in /var/log/syslog - da sollte signal-cli selbst protokollieren?
Sent by unidentified/sealed senderZitat von: Adimarantis am 13 August 2023, 11:37:01Wie ist der "trust" Status des Absenders (get identityDetails) ?
Wenn der "UNTRUSTED" mal zumindest ein "set trust all" machen.
get signal signal identityDetails klappt nicht. ich wüsste nicht, welcher Wert bei "get identityDetails <group>" für
<group> gesetzt werden sollte. Mit der Ziel-Telefonnummer klappt es nicht.
set signal trust all liefert
not implemented.
Zitat von: Adimarantis am 13 August 2023, 11:37:01Selbsttest geht (sudo signal_install.sh test)?
Scheint fehlerfrei zu laufen. Am Ende kommt "
...received".
???
Hallo Carsten,
das "<group>" ist ein copy&paste Dokumentationsfehler, natürlich ist hier die Telefonnummer gefragt. Die Liste sollte eigentlich vorbefüllt sein - außer du hast mehr als 20 Kontakte, dann lasse ich das Textfeld.
Ist dein signal-cli denn wirklich auf 0.12.0 geupdated? Sonst funktionieren nämlich die neuen Funktionen nicht.
Das "unidentified/sealed sender" deutet für mich ziemlich auf ein "trust" issue hin.
Jörg
Hallo Jörg,
ich habe am Freitag wieder Zeit zum weitermachen.
Die CLI-Version ist 0.12.0:
ZitatDEBUG org.asamk.signal.App - Starting signal-cli 0.12.0
Danke,
Carsten
Hallo Jörg,
ich habe beim restart des signal service folgenden "version `GLIBC_2.33' not found" Fehler, der allerdings mit meinem Betriebssystem zusammenhängt.
Eine Google suche bringt tausende Ergebnisse, aber ich moechte mir nichts kaputtmachen, vielleicht hast Du eine Idee:
Aug 16 18:37:12 inuc signal-cli[2674622]: WARN Manager - Failed to call libsignal-client: /tmp/16915875883731263645libsignal_jni.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/16915875883731263645libsignal_jni.so)
jamo@inuc:/opt/fhem$ lsb_release -d && uname -r
Description: Debian GNU/Linux 11 (bullseye)
5.10.0-23-amd64
jamo@inuc:/opt/fhem$ arch
x86_64
jamo@inuc:/opt/fhem uname -a
Linux inuc 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/LinuxSignal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.12.0 (libsignal-client v0.30.0)
System library path: /usr/lib
System architecture: amd64
System GLIBC version: 2.31
Using Java version: java
Native Java 17.0 yes (current version:)
Das Problem ist bekannt und es gibt dazu schon ein paar Post auf github, z.B.
https://github.com/AsamK/signal-cli/issues/1247
Leider besteht der Author von signal-cli darauf immer mit relativ neuen OS Versionen zu compilieren. Aktuell wohl mit Ubuntu 22.04 welches bereits GLIBC 2.34 verwendet. Dadurch sind die Binaries nicht rückwärtskompatibel.
Mein Installer holt allerdings die Libraries von https://github.com/exquo/signal-libs-build und die Binaries dort verwenden maximal glibc 2.28 was funktionieren sollte. Hab das gerade selbst auf meiner Ubuntu 20.04 getested (glibc2.31) und signal-cli funktioniert dort (wenn mit dem Installer installiert, welcher die Library eben austauscht).
Hast du denn den Installer fürs upgrade verwendet? Denn wenn du einfach nur signal-cli vom https://github.com/AsamK/signal-cli nimmst und drüber installierst, dann erklärt sich der Fehler
Danke Danke, das wars!
Habe die Libraries wie Du geschrieben hast ausgetauscht, und jetzt ist alles bene:VERSION Signalbot:3.15 signal-cli:0.12.0 Protocol::DBus:0.22Ich habe den Installer nicht benutzt. Damals, als ich von SiSi wechselte, wurde meine Architektur glaube ich, noch nicht unterstützt. Seitdem mache ich alle Updates immer manuell. Ich überlege aber ständig auf deinen Installer zu wechseln, habe aber Angst vor einer re- Registrierung, falls es evtl nicht klappt. Vor allem wenn ich hier manchmal über die Schwierigkeiten einiger User mit der Registrierung lese.
Danke nochmal und beste Grüsse!
Hi Jörg,
leider immer noch kein Erfolg.
Ich habe jetzt signal-cli 0.12.0 neu installiert (debian bullseye). "signal-cli test" hat funktioniert.
Ich kann über "/opt/bin/signal-cli" senden und empfangen.
Problem: Signal-Bot hat Reading lastError: "No account registered - use set account to connect to an existing registration, link or register to get a new account".
Allerdings ist beim "Set"-Button lediglich link, register und reinit verfügbar.
Wenn ich jetzt in FHEM ein "register" ausführe, kommt danach die Captcha-Anfrage. Beim Captcha-Befehl kommt dann die Meldung mit dem Code 829 (too many requests?).
weiß gerade nicht weiter :-[
Carsten
Moin Jörg,
seit dem letzten Update bekomme ich bei jedem Senden einen Eintrag ins Log geschrieben. Ich habe schon Verbose 0 gestellt, aber trotzdem. Kann das aus dem Update stammen? Sonst funktioniert alles normal.
Smarthome::
Smarthome:Enno:
Smarthome:Enno:
Smarthome::
Gruss
Enno
Hallo Enno und Jörg,
ist bei mir auch so seit dem letzten (großen) Update. Nur dass in der Logzeile einfach nur
:+4915xxxxxxxxx:
steht, und zwar immer dann, wenn FHEM über Signal eine Nachricht verschickt hat.
@Enno,
da hab ich ein paar Debugausgaben vergessen. Update ist unterwegs. Danke.
Bei der Gelegenheit auch gleich den Installer auf signal-cli 0.12.1 aktualisiert.
@Carsten,
wenn du ohne FHEM Nachrichten empfangen und senden kannst - wie rufst du das ganze denn auf? Wenn du nicht spezfisch angibst, dass die Configdaten von /var/lib/signal-cli genommen werden, dann landen sie in $HOME/.local/share/signal-cli/
Du scheinst ja dann eine funktionierende Config zu haben. Wenn du die an die richtige Stelle kopierst dann sollte die für FHEM auch funktionieren.
Jörg
Moin Jörg,
Update gemacht und auch gleich signal-cli 0.12.1 aktualisiert. Sieht gut aus, sprich keine Einträge mehr im Log. Danke!
Gruss
Enno
Dito
Zitat von: Adimarantis am 29 August 2023, 21:13:36@Carsten,
wenn du ohne FHEM Nachrichten empfangen und senden kannst - wie rufst du das ganze denn auf? Wenn du nicht spezfisch angibst, dass die Configdaten von /var/lib/signal-cli genommen werden, dann landen sie in $HOME/.local/share/signal-cli/
Du scheinst ja dann eine funktionierende Config zu haben. Wenn du die an die richtige Stelle kopierst dann sollte die für FHEM auch funktionieren.
Jörg
Lieber Jörg,
genau wie Du es beschrieben hast. Ich hatte unwissend eine Konfiguration unter $HOME/.local/share/signal-cli/.
Die habe ich dann nach /var/lib/signal-cli übertragen - jetzt klappt's wieder.
Ganz herzlichen Dank !!!
Ich habe in meiner SignalBot Installation noch eine kleine Unschönheit: Umlaute werden nicht korrekt dargestellt, wenn der Text durch eine Perl-Funktion generiert wird.
Meine Version ist nicht ganz aktuell.
Signalbot:3.12 signal-cli:0.11.3 Protocol::DBus:0.22Sollte sich hier in den letzten Monaten etwas getan haben, dann würde ich notfalls updaten.
Ich nutze Favoriten, wo ich den Perl Code wie folgt aufrufe:
[Einkaufsliste]-{listEinkaufsliste;;}
Wie muss ich den von listEinkaufsliste zurückgegebenen Text in der Perl Funktion konvertieren, so dass die Umlaute korrekt dargestellt werden?
Versuch mal
decode_utf8();
oder
encode_utf8();
Version sollte egal sein.
Jörg
Perfekt, decode_utf8 war die Lösung!
Danke dir, Jörg
Hallo zusammen,
nach einigen Versuchen habe ich es geschafft, auf meiner Festnetznummer einen Verification Code vorgelesen zu bekommen.
Jetzt sagt mir das Modul aber:
ZitatlastError: No account registered - use set account to connect to an existing registration, link or register to get a new account
Die Datei /var/lib/signal-cli/data/accounts.json sieht so aus:
{
"accounts" : [ {
"path" : "254180",
"environment" : "LIVE",
"number" : "+49403....",
"uuid" : null
} ],
"version" : 2
}und hier mein Device:
Internals:
CFGFN
FD 108
FUUID 65104ba0-f33f-d929-3c63-5047a7c682ebe45c
NAME SIGNAL
NOTIFYDEV global
NR 901
NTFY_ORDER 50-SIGNAL
STATE disconnected
TYPE Signalbot
VERSION Signalbot:3.16 signal-cli:0.12.1 Protocol::DBus:0.22
eventCount 55
model Debian GNU/Linux 11 (bullseye)
READINGS:
2023-09-28 11:40:11 account none
2023-09-28 11:40:11 joinedGroups
2023-09-28 11:40:11 lastError No account registered - use set account to connect to an existing registration, link or register to get a new account
2023-09-28 11:40:11 state disconnectedWie kann ich dem Modul mein Account beibringen?
set SIGNAL account +49403... geht schon mal nicht :(
Bin für jeden Tipp dankbar,
Alex
Nur um sicher zu gehen; Du hast schon "set verify" mit dem Code gemacht?
Dann mal sicherheitshalber:
set reinitund dann
get accountsDa sollte dann eigentlich ein Fenster aufgehen, dass deine Nummer listet
Spätestens jetzt sollte das Pulldown von
set signalAccount
mit deiner Nummer vorbefüllt sein
Jörg
Hallo Jörg,
am "set verify" scheitere ich schon (bzw. immer wieder).
Zwar bekomme ich den Anruf auf mein Festnetz, kann den Code dann aber nicht über das Pulldown eintragen (s. Screenshot 1). Auch der Befehl
set SIGNAL verify 123456 läuft ins leere...
Hier die Schritte die ich durchgeführt haben:
- Installation mit deinem Skript aus dem Wiki
- Anlegen des Device
define SIGNAL Signalbot - Attribut auf SMS setzten:
attr SIGNAL registerMethod SMS - Nummer registrieren
- Captcha erzeugen und über set + Pulldown eingeben
- ca. 60 sek warten und während dessen auf
attr SIGNAL registerMethod Voice umstellen - wenn ich dann "set register" ausführe, kommt sofort der Anruf mit dem Verify-Code
- kann den "set verify" Befehl leider nicht ausführen... :(
Wenn ich versuche, mich direkt mit der Option Voice zu registrieren, kommt leider kein Anruf.
Was habe ich da falsch gemacht?
Alex
Ok, tricky.
Vielleicht kommt da was im flow durcheinander da du gewisse Schritte doppelt ausführst, da voice nicht geht.
Und dann lässt Signalbot dich das verify nicht eintragen.
Um das zu checken, probier mal die beigefügt Version.
Der einzige Unterschied ist, dass der "set verify" (über Befehl, pulldown wird weiter nicht gehen) auch an signal-cli weitergereicht wird, wenn Signalbot eigentlich meint, das er zum falschen Zeitpunkt im Flow kommt.
Danach auf jeden Fall wie vorher beschrieben reinit, get accounts etc. - wenn das klappt muss ich mir ansehen wo der Flow durcheinander kommt.
Jörg
Hallo Jörg,
danke für deine Bemühung!
Nach diversen Fehlermeldungen:
ZitatregisterWithCaptcha:InvalidTransportModeException StatusCode: 400
oder
ZitatregisterWithCaptcha:RegistrationRetryException StatusCode: 429
habe ich meine Verifizierung direkt auf der Console (mit ./signal-cli) ausführen können. Vielleicht hat es auch geholfen, dass ich mein Pi.Hole zeitweise deaktiviert habe :-[
Dann ein "set reinit" und schon läuft es. ;D
Nochmal vielen Dank für deine schnellen Antworten!
Viele Grüße,
Alex
Das Update auf signal-cli 0.12.2 ist verfügbar.
Dazu mit "set reinit" den Installer unter www/signal aktualisieren und mit
sudo -E ./signal_install.shausführen.
Das Update dürfte nicht zwingend notwendig sein, bei Problemen aber bitte erst updaten, dann posten.
Hallo in die Runde,
ich bin aktuell dabei meinen Raspberry 4 auf einen Dell Wyse 5070 zu migrieren.
Der Dell hat eine frische Proxmox Installation mit "aktuell" nur einer VM.
Dort soll Docker mit folgenden Containern laufen:
- FHEM
- MQTT
- mySQL
- ZigBee2MQTT
- Nextcloud
- BitWarden
- EcoDMS
- UnifiEcoDMS
- Trefik
- Portainer
Aktuell bin ich dabei den FHEM Container mit Signal aufzusetzen. Dazu nutze ich das Script was hier beschrieben wird. https://wiki.fhem.de/wiki/Signalbot#Installation_im_Docker_Container (https://wiki.fhem.de/wiki/Signalbot#Installation_im_Docker_Container)
Leider ohne Erfolg. Habe dann diesen Post (https://forum.fhem.de/index.php?topic=118370.msg1230534#msg1230534) gefunden.
Dieses File gibt es nicht mehr
RUN wget -qN https://github.com/bublath/FHEM-Signalbot/raw/main/amd64-glibc2.31-0.11.2/libsignal_jni.soIrgendwo im Netz gefunden
-rw-r----- 1 root root 5033072 Okt 13 13:28 libsignal_jni.soZeile aus kommentiert, jetzt kommt ein Fehler bei
RUN zip -u /opt/signal/lib/libsignal-client-*.jar libsignal_jni.so
ERROR: failed to solve: process "/bin/sh -c zip -u /opt/signal/lib/libsignal-client-*.jar libsignal_jni.so" did not complete successfully: exit code: 12
ERROR: Service 'fhem' failed to build : Build failed
Zeile auch aus kommentiert, Image wird erstellt. Start soweit okay, bis auf
connect(unix:path=/var/run/dbus/system_bus_socket): No such file or directory at /usr/local/share/perl/5.32.1/Protocol/DBus/Client.pm line 144.Hat noch jemand eine Idee...
Danke
Alles was ich zum Thema Docker probiert habe, war immer mal wieder ein "trial and error".
Das Problem ist, dass die Kommnunikation zwischen FHEM Signalbot und signal-cli über DBUS erfolgt. DBUS verwendet filesystem unix sockets. Ich habe keine Ahnung ob es möglich ist so einen socket zwischen Containern nutzbar zu machen. Denn die Beste Lösung wäre eigentlich einen reinen signal-cli Container zu machen, anstatt das alles mit in den FHEM Container reinzupfrimeln (was mangels besserem Wissen mein Ansatz war). Ein kurzes googlen zeigt, das es da schon Möglichkeiten gibt, die ich aber auf Anhieb auch nicht wirklich verstehe. Ich bin kein so grosser Freund davon Applikationen in einzelne Container zu verpacken und habe mich daher damit auch wirklich nur mal am Rande beschäftigt.
Wenn du also wirklich Signalbot mit in einen FHEM Container packen willst, dann müssen da einfach alle Pakete rein die das signal_install.sh script installiert plus eine eigene Instanz von Dbus.
Die native Library die du suchst hole ich inzwischen von einer automatisch aktualierten Seite (siehe auch signal_install.sh oder direkt auf https://github.com/exquo/signal-libs-build). Das Docker install habe ich dahingehend (mangels Verwendung) nie angepasst.
Eleganter würde es wenn man das mal von Dbus auf RPC umstellt. Diese Option gab es noch nicht, als ich mit Signalbot angefangen habe, aber dafür gibt es sogar ein eigenes signal-cli Docker Projekt: https://github.com/bbernhard/signal-cli-rest-api
Ich habe mir aber noch nicht angeschaut, ob RPC alles abbildet und wie aufwändig eine Umstellung wäre. RPC zwischen Containern sollte eigentlich kein Problem sein - dann kann man wirklich einfach einen signal-cli Container machen.
Jörg
Das Update auf signal-cli 0.12.3 ist verfügbar.
Dazu mit "set reinit" den Installer unter www/signal aktualisieren und mit
sudo -E ./signal_install.shausführen.
Das Update dürfte nicht zwingend notwendig sein, bei Problemen aber bitte erst updaten, dann posten.
Ich muss für meinen Messenger bei Null anfangen, weil ich mich vom Telegram Bot verabschiedet habe. Das Wiki ist für den Signalbot nach wie vor aktuell und vollständig oder gibts ein anderes HowTo Schritt für Schritt Anleitung oder ähnliches?
Das Wiki sollte aktuell sein (Installation in Kapitel 2). Sollte etwas unklar oder falsch sein, lass es mich wissen.
Grundsätzlich übernimmt die Installation der 3rd Party Komponenten ein Shell Script - im Idealfall muss du nur dieses ausführen und alles wird korrekt eingerichtet.
In FHEM dann nur das Device eirichten, und der restliche Prozess wird im Modul interaktiv geführt.
Jörg
Hallo,
Habe auch etwas Probleme mit dem Signalbot, länger nicht genutzt mal alles auf den aktuellen Stand gebracht, aber ich bekomme meine Festnetznummer nicht registiert.
Ich bleib immer beim Captcher hengen "Error with captcha:Error in registerWithCaptcha:RegistrationRetryException StatusCode: 429"
root@ubuntu-FHEM:/home/user# systemctl status 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 Wed 2023-10-25 23:34:48 CEST; 8min ago
Process: 885 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 1075 (java)
Tasks: 30 (limit: 9426)
Memory: 202.9M
CGroup: /system.slice/signal.service
└─1075 java -Xms2m -classpath /opt/signal/lib/signal-cli-0.12.3.jar:/opt/signal/lib/lib.jar:/opt/signal/lib/bcprov-jdk15on-1.70.jar:/opt/signal/lib/signal-service-java-2.15.3_unoffic>
Okt 25 23:34:37 ubuntu-FHEM systemd[1]: Starting Send secure messages to Signal clients...
Okt 25 23:34:48 ubuntu-FHEM signal-cli[1075]: WARN MultiAccountManager - Ignoring +49xxxxxxxx: User is not registered. (NotRegisteredException)
Okt 25 23:34:48 ubuntu-FHEM signal-cli[1075]: INFO DaemonCommand - Starting daemon in multi-account mode
Okt 25 23:34:48 ubuntu-FHEM systemd[1]: Started Send secure messages to Signal clients.
Okt 25 23:34:48 ubuntu-FHEM signal-cli[1075]: INFO DaemonCommand - DBus daemon running on SYSTEM bus: org.asamk.Signal
Habe es jetzt mal mir einem anderen Handy über QR Code gekoppelt, das ging.
Wie kann ich das wieder entkoppeln und es die Tage dann noch mal mit Festnetz testen?
Es gibt die (versteckte) Option "set unregister <nummer>"
Die habe ich aber soweit abgesichtert, dass sie nur funktioniert, wenn <nummer> mit dem aktuellen Account (reading account) übereinstimmt.
Musst du also evtl. mit "setreading" tricksen.
Ich bin mir aber nicht sicher ob das nötig ist. Normalerweise kann man eine Nummer jederzeit erneut registrieren. Probleme beim Captcha wurden allerdings schon häufiger berichtet (meist mit RateLimitExceeded).
Hier wird vielfach empfohlen erstmal mit SMS zu registrieren (auch wenn das beim Festnetz ins Leere geht) und dann ein paar Minuten später nochmal mit Voice.
Es gibt auch wieder eine neue signal-cli version. Werde schauen das ich den Installer entsprechend aktualisiere.
Guten Abend,
kurzes Feedback, ich bekomme es nicht zum laufen. Habe soweit alles versucht, nur ohne Erfolg.
Zitat von: Adimarantis am 20 Oktober 2023, 15:08:50Wenn du also wirklich Signalbot mit in einen FHEM Container packen willst, dann müssen da einfach alle Pakete rein die das signal_install.sh script installiert plus eine eigene Instanz von Dbus.
Die native Library die du suchst hole ich inzwischen von einer automatisch aktualierten Seite (siehe auch signal_install.sh oder direkt auf https://github.com/exquo/signal-libs-build). Das Docker install habe ich dahingehend (mangels Verwendung) nie angepasst.
Ich bekomme immer den Fehler
connect(unix:path=/var/run/dbus/system_bus_socket): No such file or directory at /usr/local/share/perl/5.32.1/Protocol/DBus/Client.pm line 144.Ich breche jetzt mal, ab. Habe ich halt kein Signal-Cli ging ja bis jetzt auch.
Habe mir einen Signal Docker Container installiert mit dem Image
bbernhard/signal-cli-rest-apiwerden mal versuchen, mir aktiv Nachrichten mittels REST-API zu senden.
Danke Jörg für Deine Hilfe und deine Arbeit
Hallo,
ich hatte seit einem halben Monat das Problem, dass SignalBot zwar connected ist, aber keine Nachrichten mehr beim Empfänger ankamen.
Jetzt habe ich mal das update mit
sudo -E ./signal_install.shdurchgeführt. Danach kein connect mehr.
Danach stand im Device in fhem:
signal-cli v0.11.2+ required.
Please use installer to install or update
Note: The installer only supports Debian based Linux distributions like Ubuntu and Raspberry OS
and X86 or armv7l CPUs
You can download the installer here or your www/signal directory and run it with
sudo ./signal_install.sh
sudo ./signal_install.sh
./signal_install.sh: Zeile 22: [: =: Einstelliger (unärer) Operator erwartet.
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.9.2
System library path: /usr/lib
System architecture: armhf
System GLIBC version: 2.31
This will update system packages, install or uninstall signal-cli
system : prepare required system package (except signal-cli)
install : install signal-cli and setup as dbus system service
test : run a basic test if everything is installed and registered correctly
remove : Remove signal-cli and all configurations (will be archived)
start : Start the signal-cli service (or respective docker processes)
all : Run system, install, start and test (default)
!!! Everything needs to run with sudo/root !!!
Proceed (Y/n)? y
Checking for /usr/lib...found
Checking for /etc/dbus-1...found
Checking for /etc/dbus-1/system.d...found
Checking for /usr/share/dbus-1...found
Checking for /usr/share/dbus-1/system-services...found
Checking for /etc/systemd/system...found
Checking for /run/dbus...found
Checking for apt-ftparchive...available
Checking for wget...available
Checking for sudo...available
Checking for haveged...available
Checking for java...available
Checking for diff...available
Checking for dbus-send...available
Checking for cpan...available
Checking for zip...available
Checking for /usr/include/dbus-1.0/dbus/dbus.h...available
Checking for /usr/share/build-essential/essential-packages-list...available
Checking for /usr/share/doc/libimage-librsvg-perl...available
Checking for /usr/share/perl5/URI.pm...available
Checking for Protocol::DBus...Installing latest Protocol::DBus...done
Checking user signal-cli ...found
Checking system Java version ... 17.0
Checking for Java in /opt/java ... 17.0
Java version mismatch - version 11.0 required
Download from adoptium.net (this can take a while) ...successful
Unpacking ...done
Checking for /opt...found
Checking for /var/lib/signal-cli...found
Checking for existing signal-cli installation...found
Checking signal-cli version...signal-cli 0.9.2
signal-cli matches target version...ok
Checking for /etc/dbus-1/system.d/org.asamk.Signal.conf...found
Checking for /usr/share/dbus-1/system-services/org.asamk.Signal.service...found
Checking for /etc/systemd/system/signal.service...found
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.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
unexpected reply
Sending a message via perl Protocol::DBus...Error getting reply
Jetzt habe ich nur noch ein disconnected vom SignalBot.
Kann mir da jemand helfen?
Thx und bis denn
SouzA
Welches Installerscript verwendest du? Ich befürchte das ist uralt, da es allein schon in Bezug auf die Java Versionen falsch arbeitet und scheinbar eine uralte signal-cli Version installieren will.
Aktuell ist Version 3.22
Wird eigentlich bei jedem Neustart/set reinit in www/signal aktualisiert.
Findest du im Zweifelsfall auch im svn:
https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/signal_install.sh
Hi,
Danke für die Antwort.
Wie finde ich heraus, welche Version des installer-scripts das ist?
Thx und bis denn
SouzA
cat /opt/fhem/www/signal/signal_install.sh | grep SCRIPTVERSION
Zitat von: Ralli am 06 November 2023, 11:55:18cat /opt/fhem/www/signal/signal_install.sh | grep SCRIPTVERSION
Das ist jetzt ein wenig komisch...
pi@fhemRasPi4:~ $ cat /opt/fhem/www/signal/signal_install.sh | grep SCRIPTVERSIO N
SCRIPTVERSION="3.22"
pi@fhemRasPi4:~ $
Und nu?
Bis denn
SouzA
@Ralli
Sorry hab ich voll vergessen:
Vielen Dank für Deine Antwort! :D
Dann führst du das falsche Script aus.
Bevor du
sudo -E ./signal_install.shausführst, solltest natürlich
cd /opt/fhem/www/signalmachen.
Wahrscheinlich führst du ein uraltes Script aus, dass zufällig in deinem aktuellen Verzeichnis liegt
Zitat von: Adimarantis am 07 November 2023, 07:50:07Dann führst du das falsche Script aus.
Bevor du
sudo -E ./signal_install.shausführst, solltest natürlich
cd /opt/fhem/www/signalmachen.
Wahrscheinlich führst du ein uraltes Script aus, dass zufällig in deinem aktuellen Verzeichnis liegt
Hi,
::) Ok, so hat das Update funktioniert. Sorry, das hatte ich verpeilt.
Allerdings kommen immer noch keine Nachrichten bei mir an. Keine direkten und auch keine in eine Gruppe.
Die Contacts sind vorhanden und über get contacts werden die Angezeigt. Bei den Gruppen ebenso.
Von meinem Handy aus an fhem passiert auch nichts. Obwohl connected!
Im folgenden Reading steht allerdings immer folgendes:
sentMsgTimestamp pendingDie Namensänderung des Accounts funktioniert und wird direkt am Account und in der Gruppe dargestellt (sichtbar auf meinem Handy).
Neue Gruppen erstellen scheint zu funktionieren, das wird zumindest im Device dargestellt. Einladen in die neue Gruppe geht aber nicht.
Hat jemand eine Idee, warum das von einen auf den anderen Tag nicht mehr funktioniert?
Thx und bis denn
SouzA
Schau mal ob sich die Kontakte gegenseitig vertrauen. Also sowohl dein Handy dem FHEM als auch umgekehrt.
Am Handy in die Details des FHEM Kontakts, Sicherheitsnummer anzeigen und als verifiziert markieren.
In FHEM set trustVerified für die Handynummer und mit dessen Sicherheitsnummer.
Damit man die Sicherheitsnummer nicht abtippgen muss, kann man diese auch mit get identityDetails anzeigen lassen, grob vergleichen und per copy&paste in den set Befehl übernehmen.
Ich habe das Gefühl Signal wird immer anspruchsvoller wenn es darum geht sicherzustellen, das der Kommunikationspartner auch der ist, für den er sich ausgibt. Zumindest hatte ich mit einzelnen Kontakten auch schon das Problem, dass Nachrichten nur einseitig versendet/empfangen wurden und konnte das Problem dann mit der vollständigen Herstellung des gegenseitigen Vertrauens beheben.
Zitat von: Adimarantis am 08 November 2023, 08:59:26Schau mal ob sich die Kontakte gegenseitig vertrauen. Also sowohl dein Handy dem FHEM als auch umgekehrt.
Am Handy in die Details des FHEM Kontakts, Sicherheitsnummer anzeigen und als verifiziert markieren.
In FHEM set trustVerified für die Handynummer und mit dessen Sicherheitsnummer.
Damit man die Sicherheitsnummer nicht abtippgen muss, kann man diese auch mit get identityDetails anzeigen lassen, grob vergleichen und per copy&paste in den set Befehl übernehmen.
Ich habe das Gefühl Signal wird immer anspruchsvoller wenn es darum geht sicherzustellen, das der Kommunikationspartner auch der ist, für den er sich ausgibt. Zumindest hatte ich mit einzelnen Kontakten auch schon das Problem, dass Nachrichten nur einseitig versendet/empfangen wurden und konnte das Problem dann mit der vollständigen Herstellung des gegenseitigen Vertrauens beheben.
Omg!
Das war's! Da wär ich jetzt im Leben nicht drauf gekommen.
Vielen Dank für den Tip und Deine Unterstützung.
Beidseitig das vertrauen hergestellt und es läuft wieder!
Thx und bis denn
SouzA
Wunderbar. Dazu stand zwar schon ein Hinweis im Wiki, aber der war nicht sonderlich ausführlich und war für deinen Fall evtl. nicht klar genug.
Ich habe das Wiki jetzt etwas ausführlicher ergänzt.
Hallo zusammen,
ich hätte da eine Verständnis Frage. Signalbot und Fhem laufen soweit, das Modul ist betriebsbereit und im disconnected state.
Eine Nummer kann ich auch über das Modul erfolgreich in aktivieren.
Nun würde ich gerne auf einer anderen Fhem Installation, keine Nummer registrieren, sondern nur ein bereits Registriertes Handy verknüpfen (link).
Mit
/opt/signal/bin/signal-cli --config /var/lib/signal-cli link -n NAME > /tmp/signal.txt&kann ich auch ein bereits Registriertes Handy mit signal-cli verknüpfen.
cat /var/lib/signal-cli/data/accounts.json
{
"accounts" : [ {
"path" : "123456",
"environment" : "LIVE",
"number" : "+491234567890",
"uuid" : "f54..."
} ],
"version" : 2
Kann ich nun Signalbot ohne Registrierung einer anderen Nummer verwenden?
Mache ich evtl. etwas falsch?
VG,
Mikka
PS.: Von der Kommandozeile kann ich Nachrichten mit signal-cli an andere Signal Nutzer senden.
Du kannst entweder dein Handy oder schlicht und ergreifend die bereits bestehende FHEM Instanz verküpfen.
Lies dazu mal
https://wiki.fhem.de/wiki/Signalbot#link_%3CName%3E
bzw.
https://wiki.fhem.de/wiki/Signalbot#addDevice_%3Cdevice_URI%3E
das brauchst du nicht von der Kommandozeile aus zu tun, sondern geht alles direkt aus Signalbot.
Hab das schon lange nicht mehr verwendet und daher kurz mal getestet.
Der Versuch mein Handy zu registrieren, ist erst fehlgeschlagen (Signal meldete nach dem Scannen des QR-Codes erfolg, aber FHEM war weder in Signal als gekoppeltes Gerät eingetragen, noch war das Handy für Signalbot sichtbar)
Lag aber anscheinend daran, dass ich das früher schon mal gekoppelt hatte, und die Nummer noch unter /var/lib/signal-cli/data eingetragen war. Nachdem ich diese Überreste entfernt und signal-cli neugestartet hatte, ging es dann.
Was auf Anhieb geklappt hat, war die zweite FHEM Instanz zur ersten hinzufügen.
Schaut mal ob du mit der Beschreibung zurecht kommt - muss man vielleicht noch etwas ausbauen und meinen Fehlerfall erwähnen.
Hi Adimarantis,
hatte zunächst von Fhem aus mit link probiert, wollte irgendwie nicht. Dann von der Kommandozeile wo es anschließend geklappt hat.
Habe nun /var/lib/signal-cli/data gelöscht und erneut aus Fhem probiert, siehe da es klappt nun *juppie*.
Vielen dank für deine schnelle Antwort und den Support hier!
Evtl. war ich zu ungeduldig nachdem ich die Neue Handynummer mit der Signalapp registriert habe und dann mit Fhem verknüpfen wollte.
Werde das ganze die Tage mit einer weiteren Nummer ausprobieren und mich erneut melden ob es auf Anhieb klappt mit ein wenig warten zwischendurch.
Schönes Wochenende!
Der Author von signal-cli hat gestern signal-cli 0.12.5 veröffentlicht.
Dazu folgender Hinweis: Diese Version benötigt jetzt Java 21, welches meines Wissen auf keinem der gängigen RaspberryOS/Debian/Ubuntu Systemem per "apt" Installation verfügbar ist. Leider wurden die Proteste meinerseits (und anderer Anwender) ignoriert (siehe https://github.com/AsamK/signal-cli/issues/1365 )
Ich werde daher bis auf weiteres die signal-cli Version nicht mehr updaten.
Es kommt sicher die Zeit wenn entweder Java 21 auf den meisten Systemen standardmässig vorhanden ist, oder aber signal-cli 0.12.4 nicht mehr ordnungsgemäß mit den Signal Servern kommunizieren kann. Dann plane ich wieder (wie schon für Java 17 auf älternen Systemen) eine Downloadfunktion für eine Java 21 Binärdistribution.
Aktuell sehe ich dafür aber keinen Anlass
Hi
I have Signalbot:3.16 signal-cli:0.12.4 Protocol::DBus:0.22 in FHEM on a Raspberry 3B.
With TOP I can see that the user signal-bot with java uses a lot of cpu. Something between 24% and 75%
This looks unusual high to me when nothing is send or received in signal.
Is this normal?
{HT}
It might be that the problem starts on my android device which reports that the signal app crashes often.
Also I reduced the time the messages should be kept in signal on my android phone.
At least signal-bot is now a lot less cpu consuming.
A known issue?
{HT}
I'm not aware of any specific issue. My Raspberry mostly idles though I have a lot more things on it than signal-cli.
One thing you might want to watch is the memory consumption. One reason I switched to a Raspberry 4 was that it has the 4GB RAM version.
With all the tools I had on it, it started swapping on my Raspi3, which can easily cause performance issues. And signal-cli (Java) is not very memory friendly - when I just checked htop showed 372M of memory for signal-cli alone.
If memory is the issue, you could start restricting the memory the Java VM is allowed to use. For that edit /etc/systemd/system/signal.service
change the line with the SIGNAL OPTS and add a -Xmx option
Environment="SIGNAL_CLI_OPTS=-Xms2m -Xmx256M"
After changing the file you should probably make the systemctrl daemon reload the file and restart the service
sudo systemctl daemon-reload
sudo systemctl restart signal
I can't exactly tell you how low you can go without impacting signal-cli's functionalty. 256M like in my example should probably be ok, but still too high for your system, while I probably would not go below 128M (and that might already be too low).
Restricting the memory will force Java to invoke its garbage collector more often, but that should still take less performance than swapping.
Gesundes neues Jahr für Euch,
ich habe es einfach nicht hinbekommen, Signal im FHEM Docker Container zu installieren.
Ist auch egal, bin ja flexibel.
Also ich habe eine Eigene VM nur mit FHEM auf gesetzt:
* Ubuntu 20.04.6 LTS
* Signal Version 0.12.4
Wo ist mein Problem???
Ich habe alles soweit sauber installiert, wenn ich im FHEM meine Rufnummer registrieren möchte kommt der Fehler:
Error with captcha:Error in registerWithCaptcha:RegistrationRetryException StatusCode: 429Registriere ich ohne FHEM, läuft der Prozess sauber durch.
Habe anschließend das Script ./signal_install.sh remove und alle Verzeichniss von Signal gelöscht.
Anschließend ./signal_install.sh und der Versuch im FHEM zu registriert immer dieser Fehler...
Hab hier Error 429 (https://github.com/bbernhard/signal-cli-rest-api/issues/441) was gefunden.
Hat jemand eine Idee?
Danke
Verstehe ich leider auch nicht. Im Prinzip werden über FHEM die selben API-Funktionen aufgerufen wie von dir geschildert. Nur eben nicht über die REST-API, sondern über DBus.
Das hat historische Gründe, da es die REST-API noch nicht gab, als ich mit Signalbot gestartet bin. Ich habe auch noch nicht geprüft ob die REST-API alle Funktionen zur Verfügung stellt, die ich aktuell verwende.
Ich hatte schon mal überlegt, ob man Signalbot nicht auf REST-API umstellen sollte. Dann wäre das Thema Docker deutlich einfach zu handhaben, da es ja schon ein Docker Image gibt, das signal-cli mit REST-API zur Verfügung stellt. Wäre auch geschickt für das aktuelle Problem mit Java 21 - das könnte man dann einfach mit ins Docker Image packen.
Leider wäre das ein ziemlicher Aufwand und würde erfordern Signalbot in Teilen komplett umzuschreiben.
Bei DBus ist das leider nicht so trivial, weil die Kommunikation nicht über einen TCP/IP Socket läuft wie bei REST, sondern über ein file handle - und wie man das aus einem Docker Image raus exportiert übersteigt mein Know How.
Danke für die schnelle Antwort.
Was mich nur wundert, das der Error 429 eigentlich immer auf "Too Many Requests " hindeutet...
Kann es sein, das hier während der Registrierung was geblockt wird?
Dieser Fehler 429 (https://github.com/bbernhard/signal-cli-rest-api/issues/441) nutzt die REST-API und hat auch das Problem.
Hallo!
Ich muss nach einem System Umzug nun meine Signal Nummer neu einrichten. Signal-cli läuft. Aber wenn ich die captcha Adresse nach dem Lösen in FHEM paste, bekomme ich eine leere Webpage geliefert mit "Error 400".
Leider lässt er sich trotz Verbose 5 auch nicht weiter dazu aus, die letzte Meldung im Log ist dass ein Captcha gelöst werden muss.
Wie könnte ich die Problemlösung angehen?
Schwer zu sagen. Weitere Infos werden eventuell von signal-cli ins syslog geschrieben.
Alternativ zu der geführten Registrierung in FHEM könntest du noch die Registrierung manuell in der Kommandozeile vornehmen, wie sie im Wiki unter Troubleshooting beschrieben ist.
Wenn es dort Fehler gibt, dann ist klar, dass es rein mit signal-cli zu tun hat, und du kannst schauen ob es auf deren github Seite Lösungen gibt.
Hallo! Vielen lieben Dank! Ich habe die Lösung schließlich gefunden. Ich hatte initial auf eigene Faust die Java 21 abhängige neueste signal-cli installiert. Die hatte ich nicht deinstalliert bevor ich das mit dem Modul mitgelieferte installations script laufen hab lassen, weil ich mir gedacht hab der räumt ja eh auf. Ende vom Lied: alles runter inklusive purge und dann sauber das install script laufen gelassen, bingo. Sorry for the mess...
Vorweg: Ich nutze nicht das Update-Skript, weil ich eine Frickel-Lösung im Container habe, die eigentlich sehr gut funktioniert. So lange jedenfalls bis man vom Server ausgeperrt wird, weil die Version zu alt ist.... Das hatte ich heute Nacht.
Ich bin dann auf signal-cli 0.12.7 von hier:https://github.com/AsamK/signal-cli/releases/
Die passende libsignal 0.36.1 von hier: https://github.com/exquo/signal-libs-build/releases
Signalbot läuft wieder.
Vielleicht hilft es jemandem...
Zitat von: Flachzange am 30 Januar 2024, 21:37:54Frickel-Lösung im Container
Guten Morgen, kannst Du Deine Frickel-Lösung beschrieben. So das ich sie nachstellen kann.
Danke
Hi,
bei mir ist die Registrierung verloren gegangen, auch ein Restore aus den alten Daten funktioniert leider nicht. Wenn ich die Nummer nun erneut registrieren will, kommt nach lösen des Captchas die folgende Fehlermeldung:
Error with captcha:Error in registerWithCaptcha:DeprecatedVersionException StatusCode: 499
Ich habe auch noch mal das Installationsskript mit der Option "install" aufgerufen, aber leider hat das auch nichts gebracht. Wenn ich wie im Wiki beschrieben eine Registrierung aus der Shell probiere, kommt der gleiche status code. Hier mal die Versionen:
Signalbot:3.16 signal-cli:0.11.4 Protocol::DBus:0.22
Hat jemand eine Idee woran das liegen könnte?
Danke.
VG
Marcus
Hallo,
habe die Lösung gefunden. Die neu Version des Installationsskript heruntergeladen, dieses hat die signal-cli auf 0.12.4 aktualisiert. Danach konnte ich mit einem Restore die alten Daten wiederherstellen
Grüsse
Marcus
Zitat von: BAfH am 01 Februar 2024, 09:47:43Zitat von: Flachzange am 30 Januar 2024, 21:37:54Frickel-Lösung im Container
Guten Morgen, kannst Du Deine Frickel-Lösung beschrieben. So das ich sie nachstellen kann.
Danke
Siehe hier: https://forum.fhem.de/index.php?msg=1230890
Das Repo von holoarts ist nur nicht aktuell. Da müsstest Du selber Hand anlegen. Alternativ anbei mein aktuelles Dockerfile
Zitat von: Flachzange am 30 Januar 2024, 21:37:54...
Ich bin dann auf signal-cli 0.12.7 von hier:https://github.com/AsamK/signal-cli/releases/
Die passende libsignal 0.36.1 von hier: https://github.com/exquo/signal-libs-build/releases
Signalbot läuft wieder.
Vielleicht hilft es jemandem...
ja, danke, das hat mir geholfen! Läuft mit Signalbot 3.16 unter Java 17
Ich habe den /opt/fhem/signal-cli-0.12.7/lib/libsignal-client-0.36.1.jar durch den passende libsignal 0.36.1 von https://github.com/exquo/signal-libs-build/releases ersetzt.
VERSION Signalbot:3.16 signal-cli:0.12.7 Protocol::DBus:0.22jamo@inuc:/opt/fhem$ java --version
openjdk 17.0.1 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-39)
OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing)
Mittlerweile ist die Zeit gekommen, mein Ubuntu 18.04 in Rente zu schicken. Das Image hat 3 Festplatten und 2 Rechner überlebt :))
Der Grund: glibc 2.27. Bisher konnte ich mit tricksen noch die alte 0.11.x Version am leben halten, jetzt bekomme ich aber keine passende libsignal_jni.so mehr - die wollen alle die glibc2.28 sehen. Und selber compilieren ist mir für das alte Stück zu viel Aufwand. Zumal das auf dem Intel Atom D525 eine Weile dauern würde...
Wahrscheinlich werde ich wieder zu Debian gehen, Ubuntu hats bei mir u.a. mit der Werbung in apt und motd sowie der ganzen Cloudseuche in der Server-minimal-installation (passt nicht mehr ohne Kopfstände auf eine 4GB CF Disk) verbockt.
Hat jemand das aktuelle Debian 12.4 am Start?
Debian sollte eigentlich kein Problem sein.
Auf 11 hab ichs schon probiert und auf dem Raspberry hab ich auch schon Bookworm laufen, was ja auf Debian 12 basiert.
Zitat von: sukram am 03 Februar 2024, 20:31:55Hat jemand das aktuelle Debian 12.4 am Start?
Moin
ja bei mir läuft 12.4 auf einem NUC als CT unter Proxmox. Ich habe das Script von Jörg genutzt und bin nach der Beschreibung im Wiki vorgegangen. Capatcha ist etwas hakelig, der Rest easy.
Gruss
Enno
Mein Signalbot war seit Montag disconnected. Warum auch immer. War der Meinung, er ist nicht registriert.
Ich hab daher mal ein Update gemacht und versuche gerade, die Festnetznummer neu zu registrieren. Das schlägt aber immer mit:
Error with captcha:Error in registerWithCaptcha:RegistrationRetryException StatusCode: 429
fehl. Kein Unterschied, ob ich das via FHEM oder Kommandozeile mache.
Ich hab mal das data-Verzeichnis gelöscht und es nochmal versucht. Aber keine Chance.
Hat jemand eine Ahnung, was da los ist?
Dankeschön!
Also vermutlich weil Deine signal-cli zu alt war (siehe auch einige Beiträge zuvor) Genaueres im Log, z.B. signal.err. Sobald Du ein Update gemacht hast, also wirklich das Update-Skript sollte es out of the box wieder laufen. Neu-Registrierung eher nicht notwendig. Also zuerst bitte mal die Version von signal-cli und signal.err prüfen.
signal-cli 0.12.4Ein Fehler-Log finde ich leider nirgends.
Zitat von: drhirn am 04 Februar 2024, 15:37:34signal-cli 0.12.4
Das passt.
Zitat von: drhirn am 04 Februar 2024, 15:37:34Ein Fehler-Log finde ich leider nirgends.
/var/log/signal.err
Der Fehler oben sieht nach "zu oft versucht aus". Ich würde einfach die alten Daten wieder zurückkopieren und mal ein paar Stunden warten. Also auch ohne neuer Registrierung.
Nicht zu oft, der gleiche Fehler kommt auch wenn man primär versucht mit voice zu authentifizieren. 1x mit sms (also das attribut löschen, nicht sms als Attribut, das kennt er nicht) - das schlägt natürlich fehl weil du nichts bekommst - und dann nochmal mit voice. Dann wirds gehen.
Hallo, genau diesen Fehler bekomme ich auch.
Bis jetzt keine Lösung oder anderes..
Zitat von: BAfH am 08 Januar 2024, 12:41:38Hab hier Error 429 (https://github.com/bbernhard/signal-cli-rest-api/issues/441) was gefunden.
Hat jemand eine Idee?
Danke
Lieber Thorben,
das bedeutet Du hast es wie in meinem Post über Deinem beschrieben bereits einmal mit Authentifikation per sms versucht (steht übrigens auch gebau so als Lösung in dem Link den Du gepostet hast: " The link above claims that Failed to register: [429] Rate limit exceeded: 429 (RateLimitException) might be an error if you are not doing this correctly (first use voice=false, then wait, then voice=true).")
und bekommst dann trotzdem beim voice versuch Error 429?
Lg
Matthias
Hallo Matthias,
natürlich nicht. ::)
Ich versuchte meine Festnetznummer zu registrieren.
Habe jetzt meine Mobilfunknummer mittels SMS sauber registriert.
Also wieder zurück auf Festnetz.
Festnetznummer mittels Voice -> 429
Festnetznummer mittels SMS -> 429
Festnetznummer mittels Voice -> der Anruf kommt und die Nummer ist sauber registriert.
Jetzt habe ich Signal im Docker Container mit meiner Festnetznummer am laufen.
Danke
Danke
Seit 0 Uhr UTC gab es heute wieder:
ZitatWARN MultiAccountManager - Ignoring +49....: signal-cli version is too old for the Signal-Server, please update. (AccountCheckException)
Die Entwickler scheinen dann signal-cli 0.12.8 etwas hektisch noch heute Nacht nachgeschoben zu haben. Damit läuft es dann wieder.
Das blöde ist nur: 12.8 braucht JRE 21. Und das wird bei Debian nicht ausgeliefert. Demnach sollten jetzt einige auf Raspian aufbauende FHEM/signal Installationen über Nacht stumm geworden sein.
"DeprecatedVersionException StatusCode: 499"
Also bei mir läuft es mit JRE 17 (Debian x86)
Edit: das Changelog gibt das irgendwie auch nicht her: https://github.com/AsamK/signal-cli/compare/v0.12.7...v0.12.8
Du hast aber auch die libsignal verändert. Bei mir hat es jedenfalls nicht funktioniert - Adimarantis hat hier irgendwo geschrieben dass es JRE 21 braucht- und das steht ja auch so auf den Git Seiten von signal-cli. Lass mich aber gerne eines Besseren belehren!
Edit: du müsstest das Changelog von 12.4 auf 12.8 vergleichen. Das mit dem modul mitgelieferte Script installiert 12.4
Jup, ich scheitere gerade auch an der libsignal
Ich hatte auch
DeprecatedVersionException StatusCode: 499
Letzter Stand:
Mein Signal im Docker Container läuft. O:-)
Meine Umgebung Proxmox mit einer Maschine Ubuntu 22.04 inklusiver installierter openjdk-21-jre-headless, weiter mit Docker.
Mein Dockerfile für FHEM
FROM ghcr.io/fhem/fhem-docker:3-bullseye
MAINTAINER holoarts<holoarts@yahoo.com>
ENV DEBIAN_FRONTEND noninteractive
ENV TERM xterm
# Install dependencies
RUN apt-get update
RUN apt-get -q -y install openjdk-17-jre-headless
RUN apt-get -q -y install zip
RUN apt-get clean && apt-get autoremove
WORKDIR "/tmp"
RUN wget -qN https://github.com/AsamK/signal-cli/releases/download/v0.12.8/signal-cli-0.12.8.tar.gz -O signal-cli-0.12.8.tar.gz
RUN tar zxf signal-cli-0.12.8.tar.gz
RUN mv signal-cli-0.12.8 /opt/signal
RUN wget -qN https://github.com/exquo/signal-libs-build/releases/download/libsignal_v0.36.1/libsignal_jni.so-v0.36.1-x86_64-unknown-linux-gnu.tar.gz
RUN tar zxf libsignal_jni.so-v0.36.1-x86_64-unknown-linux-gnu.tar.gz
RUN zip -u /opt/signal/lib/libsignal-client-*.jar libsignal_jni.so
RUN rm -f signal-cli-0.12.8.tar.gz libsignal_jni.so
RUN cpan install Protocol::DBus
COPY org.asamk.Signal.conf /etc/dbus-1/system.d/org.asamk.Signal.conf
COPY org.asamk.Signal.service /usr/share/dbus-1/system-services/org.asamk.Signal.service
COPY pre-start.sh /docker/
# End Dockerfile
Im FHEM sehe ich die Version
Signalbot:3.16 signal-cli:0.12.8 Protocol::DBus:0.22
Danke für die Unterstützung.
Zitat von: Mad-at am 06 Februar 2024, 09:34:11Edit: du müsstest das Changelog von 12.4 auf 12.8 vergleichen. Das mit dem modul mitgelieferte Script installiert 12.4
Nein, ich war auf 12.7:
Zitat von: Flachzange am 30 Januar 2024, 21:37:54Ich bin dann auf signal-cli 0.12.7 von hier:https://github.com/AsamK/signal-cli/releases/
Die passende libsignal 0.36.1 von hier: https://github.com/exquo/signal-libs-build/releases
Damit braucht es bei mir kein JRE 21
Kann ich bestätigen. Ich hab signal-cli jetzt mal deinstalliert, weil ich's nicht mehr zum Laufen bekommen habe. Dann mittels signal_install.sh wieder installiert, davor aber die aktuellsten Versionen im Script eingesetzt. signal-cli 0.12.8 und libsignal 0.36.1. Das klappt. Mit JRE 17.
Hänge jetzt aber wieder bei der RegistrationRetryException.
Morgen nächster Versuch
Sorry, ich glaube wir reden aneinander vorbei(?)
Zitat von: Flachzange am 06 Februar 2024, 10:27:22Zitat von: Mad-at am 06 Februar 2024, 09:34:11Edit: du müsstest das Changelog von 12.4 auf 12.8 vergleichen. Das mit dem modul mitgelieferte Script installiert 12.4
Nein, ich war auf 12.7:
Ich verstehe schon dass es mit der neuen lib klappt. Ich meinte nur, dass das mit dem FHEM script (das was im www/signal-cli Ordner liegt) installierte signal-cli 12.4 halt mit jre 17 läuft und Adimarantis einmal geschrieben hatte er wird das nicht auf eine höhere signal-cli version updaten weil die höheren Versionen JRE21 brauchen.
Zitat von: Adimarantis am 22 November 2023, 08:13:32Der Author von signal-cli hat gestern signal-cli 0.12.5 veröffentlicht.
Dazu folgender Hinweis: Diese Version benötigt jetzt Java 21, [...]
Somit wollte ich nur zum Ausdruck bringen dass jeder der signal-cli über das Modul installiert hat jetzt wohl selber Hand anlegen muss und Deine Konfiguration übernehmen muss
Da aus irgendwelchen Gründen keine Messages mehr rausgingen, habe ich kurzerhand Signalbot entfernt (signal_install.sh remove); SIGNALVERSION="0.12.8" und LIBRARYVERSION="0.39.3" in das Skript eingetragen; dann neu installiert.
So weit so gut.
Dann in FHEM die Telefonnummer registriert (set Signal_MSG register +49xxxx). Captcha aufgerufen, rauskopiert und in FHEM eingefügt (set Signal_MSG captcha signalcaptcha://signal-hcaptcha.xxxxx).
Dann bekomme ich die Fehlermeldung :"Error in registerWithCaptcha:Account is already in use"
Klar, die Nummer bestand ja bereits. Ich dachte bei "set register xx" wird diese gelöscht und neu angelegt. Das scheint nicht (mehr) der Fall zu sein.
Wie kann man hier weiter vorgehen?
Zitat von: oelkanne am 06 Februar 2024, 14:30:29SIGNALVERSION="0.12.8" und LIBRARYVERSION="0.39.3"
Warum 0.39.3? Sollte es nicht 0.36.1 sein?
Hat aber nichts mit deinem Problem zu tun.
War einfach die Neueste: https://github.com/AsamK/signal-cli/releases
Hab jetzt nochmal alles deinstaliert und mit LIBRARYVERSION="0.36.1" probiert. Auch hier ist die Installtion erfolgreich, aber gleiche Fehlermeldung nach der Captchaeingabe "Error in registerWithCaptcha:Account is already in use"
Bei mir kommt " Deserialization failure in zkgroup" :o
Zitat von: Mad-at am 06 Februar 2024, 16:19:59Bei mir kommt " Deserialization failure in zkgroup" :o
Dann passt die libsignal nicht
Weitere Versuche zu "Error in registerWithCaptcha:Account is already in use"
Habe noch den versteckten Befehl "unregister" in FHEM ausgeführt. (Post 1085)
Meldung: "No account registered - use set account to connect to an existing registration, link or register to get a new account"
Dann habe ich noch versucht mein Handy zu registrieren – Nach Captcha Eingabe gleiche Fehlermeldung wie bei Festnetz: "Error in registerWithCaptcha:Account is already in use"
Hab auch seit heute früh keine Benachrichtigungen mehr erhalten und in FHEM wird angemerkt, dass keine Nummer registriert sei. Ich nutze FHEM auf einem Raspi mit Buster und Java 17. Bei mir stand in der /var/log/syslog, dass die Version von signal-cli zu alt für die Kommunikation mit dem Server sei.
Folgendes hat bei mir sofort funktioniert:
1. in der signal_install.sh folgende Zeilen ändern:
SIGNALVERSION="0.12.8"
LIBRARYVERSION="0.36.1"
2. ./signal_install.sh install aufrufen
3. in FHEM ein Reconnect des Moduls
Anschließend konnte ich direkt wieder Nachrichten verschicken.
Achtung, beim Aktualisieren wird die signal_install.sh wieder mit den alten Werten überschrieben.
Ärgerlich ist es, wenn man dem augenscheinlichen Hinweis gefolgt ist und die Nummer versucht, neu zu registrieren und jetzt im Freischaltprozess hängt :-(
Viele Grüße,
Daniel
Nach 2-3x re und deinstallieren hat es in dieser Konfiguration dann auch bei mir wieder geklappt
Zitat von: Deekay2000 am 06 Februar 2024, 17:45:06Hab auch seit heute früh keine Benachrichtigungen mehr erhalten und in FHEM wird angemerkt, dass keine Nummer registriert sei. Ich nutze FHEM auf einem Raspi mit Buster und Java 17. Bei mir stand in der /var/log/syslog, dass die Version von signal-cli zu alt für die Kommunikation mit dem Server sei.
Moin Daniel,
haben wie von dir beschrieben das Update gemacht, nachdem mein Signal auch nicht mehr reagiert hat. Bin jetzt bei
Signalbot:3.16 signal-cli:0.12.8 Protocol::DBus:0.22
Debian GNU/Linux 12 (bookworm)Gruss
Enno
Zitat von: Deekay2000 am 06 Februar 2024, 17:45:06Folgendes hat bei mir sofort funktioniert:
1. in der signal_install.sh folgende Zeilen ändern:
SIGNALVERSION="0.12.8"
LIBRARYVERSION="0.36.1"
Danke schön, hat bei mir auch funktioniert. Ist mir erst gar nicht aufgefallen, dass Signal-cli nicht mehr funktionierte.
Signalbot stand schön als "connected to" da, aber die Message blieb im Status pending stehen.
Viele Grüße
Thomas
Zitat von: drhirn am 06 Februar 2024, 12:44:19Hänge jetzt aber wieder bei der RegistrationRetryException.
Morgen nächster Versuch
Keine Chance, ich komm da nicht drüber. Irgend wer eine Idee?
Ich hab jetzt auch schon versucht, den Ordner "data" aus einem Backup wieder her zustellen. Ändert auch nichts.
selbes Problem hier (RegistrationRetryException), hat irgendwer eine Lösung ?
Sorry, auf die Gefahr hin mich zu wiederholen: ihr habt beide schon versucht zuerst via sms und dann erst per voice zu authentifizieren? Das gilt auch für Festnetz. Siehe post #1125 & #1126
Per SMS bekomme ich:
Failed to register: StatusCode: 502 (ExternalServiceFailureException)bzw.
Error with captcha:Error in registerWithCaptcha:ExternalServiceFailureException StatusCode: 502
Zitat von: Deekay2000 am 06 Februar 2024, 17:45:06Hab auch seit heute früh keine Benachrichtigungen mehr erhalten und in FHEM wird angemerkt, dass keine Nummer registriert sei. Ich nutze FHEM auf einem Raspi mit Buster und Java 17. Bei mir stand in der /var/log/syslog, dass die Version von signal-cli zu alt für die Kommunikation mit dem Server sei.
Folgendes hat bei mir sofort funktioniert:
1. in der signal_install.sh folgende Zeilen ändern:
SIGNALVERSION="0.12.8"
LIBRARYVERSION="0.36.1"
2. ./signal_install.sh install aufrufen
3. in FHEM ein Reconnect des Moduls
Anschließend konnte ich direkt wieder Nachrichten verschicken.
Achtung, beim Aktualisieren wird die signal_install.sh wieder mit den alten Werten überschrieben.
Ärgerlich ist es, wenn man dem augenscheinlichen Hinweis gefolgt ist und die Nummer versucht, neu zu registrieren und jetzt im Freischaltprozess hängt :-(
Viele Grüße,
Daniel
Hat auch bei mir funktioniert.
Ich brauchte nicht mal Punkt 3.
Direkt als das install-script den DBUS-Check gemacht hat, sprang auch FHEM wieder an.
Signalbot:3.16 signal-cli:0.12.8 Protocol::DBus:0.22
Debian GNU/Linux 12 (bookworm)
DANKE
Ich hab jetzt diverse Festnetznummern versucht. Bei allen bin ich gescheitert. Auch mit "zuerst SMS, dann Voice".
Hat erst funktioniert, als ich wirklich eine Mobilfunknummer genommen habe und da die Registrierung via SMS abschließen konnte.
puh, das ist aber echt doof. Ich möchte definitv NICHT meine Handynummer im Signalbot nutzen. Hat noch irgendwer einen Trick auf Lager ? Ein Wechsel der Registrierung zu SMS und dann wieder zu Voice hat auch bei mir nicht funktioniert.
Ich habe jetzt mal das offizielle signal_install Script mit signal-cli 0.12.8 geupdated, wie es schon einige getan haben.
Bei mir scheint das nach wie vor mit JDK 17 zu funktionieren, obwohl der Autor von signal-cli auf JDK 21 geupdated hat. Evtl. verwendet er aktiv noch eine JDK21 features oder aber nur an Stellen die nicht häufig oder von Signalbot gar nicht verwendet werden.
Das ist aber definitiv nur eine Notlösung, die immerhin besser ist als wenn gar nichts mehr geht. Ich kann nicht ausschliessen, das es bei bestimmten Funktionen Probleme gibt.
JDK 21 ist leider ein ziemliches Dilemma: Für X86 and aarch64 kann ich das Script um ein Download der Binaries von Adoptium erweitern. Spannend wird es für Raspberries die noch nicht voll auf 64 Bit umgestellt haben. Adoptium liefert für armv7 keine Binaries. Kennt jemand eine Binary Distribution die JDK 21 für ARM zur Verfügung stellt?
Zitat von: nitzerebb am 07 Februar 2024, 13:24:09puh, das ist aber echt doof. Ich möchte definitv NICHT meine Handynummer im Signalbot nutzen. Hat noch irgendwer einen Trick auf Lager ? Ein Wechsel der Registrierung zu SMS und dann wieder zu Voice hat auch bei mir nicht funktioniert.
Mir ist heute morgen eingefallen, dass ich ja noch eine Prepaid-SIM rumliegen hatte. Das ist überhaupt eine gute Lösung, wenn man was billiges findet. Man muss ja nur 1x aufladen. Bzw., wenn man auf Nummer sicher gehen will, einfach 1x im Jahr.
HoT bietet in Österreich z.B. einen SmartHome Tarif um 19,90.-/Jahr.
Zitat von: Deekay2000 am 06 Februar 2024, 17:45:06Folgendes hat bei mir sofort funktioniert:
1. in der signal_install.sh folgende Zeilen ändern:
SIGNALVERSION="0.12.8"
LIBRARYVERSION="0.36.1"
2. ./signal_install.sh install aufrufen
3. in FHEM ein Reconnect des Moduls
Anschließend konnte ich direkt wieder Nachrichten verschicken.
Achtung, beim Aktualisieren wird die signal_install.sh wieder mit den alten Werten überschrieben.
Ärgerlich ist es, wenn man dem augenscheinlichen Hinweis gefolgt ist und die Nummer versucht, neu zu registrieren und jetzt im Freischaltprozess hängt :-(
Hat bei mir perfekt funktioniert mit der aktuellen install.
- aktuelle signal_install.sh von https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/signal_install.sh (https://svn.fhem.de/fhem/trunk/fhem/contrib/signal/signal_install.sh) heruntergeladen
- sudo -E ./signal_install.sh
- in Fhem im Modul set reinit
LG
Alex
Hallo,
mir ist gestern aufgefallen das Signal bei mir auch nicht mehr funktioniert.
Nach der deinstallation mit dem script und installation + reboot des Raspi läuft der Service wieder.
Jetzt hänge ich wieder an der registrierung per Voice bzw dem Captacha weil ich ja under /var/lib/signal-cli/data die alter registrierung schon gelöscht habe.
Meldung nach dem einfügen Captacha (copy des links des Buttons "Signal Öffnen", hoffe das ist richtig):
Error with captcha:Error in registerWithCaptcha:MismatchedInputException No content to map due to end-of-input
at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1]
Hat dazu vielleicht einer eine idee?
Danke
Update installer 3.23: OpenJDK21 support
Nachdem signal-cli jetzt ja offiziell OpenJDK21 erfordert, holt sich der Installer jetzt entsprechende Binary Distributionen und installiert diese nach /opt/java
Für aarch64 (Raspberry mit 64 Bit OS), x86 and x64 ist die Quelle https://adoptium.net/temurin/releases/?arch=any&version=21
Für armv7l (Raspberry mit 32 Bit OS) gab es nirgends eine Binärdistribution. Ich habe jetzt über die letzten Tage eine eigene Version übersetzt. Da man dazu immer die aktuelle oder vorhergehende JDK version braucht und die letzte erhältliche Version JDK17 war, musste ich mich langsam hochhangeln -> JDK18 -> JDK19 -> JDK20 -> JDK21
Zumindest aarch64 (auf "bookworm") und armv7l (auf "buster") habe ich selbst getestet. Bitte die x86 Fraktion das auch mal probieren.
Jörg
Zitat von: Kohle77 am 14 Februar 2024, 10:49:28weil ich ja under /var/lib/signal-cli/data die alter registrierung schon gelöscht habe.
Kein Backup? Sollte eigentlich immer noch funktionieren?
Sonst nur die Geschichte mit "erst SMS, 1-2 Minuten warten, dann Voice"
Jörg
Hallo Jörg,
nach einem Backup müsste ich mal suchen.
Hab den Reg Key installiert, auf sms umgestellt, nummer registriert und auf den Captcha link geklickt.
Die Bilder angeklickt das ich ein Mensch bin und es öffnet sich auch die Powershell aber die Meldung in FHEM bleibt die gleiche.
Ich warte einfach mal noch ein Tag und versuche es dann nochmal.
Christian
Hallo,
nach einigem probieren hat das mit der erneuten Registrierung wieder funktioniert.
Woran es jetzt genau lag kann ich nicht mehr sagen. Hab es mit dem script deinstalliert, wieder installiert, mal mit dem user fhem gestartet usw.
Jetzt läuft es auf alle Fälle wieder.
Gruß
Christian
@Adimarantis
Wie viele andere hier auch in den letzten Wochen habe ich heute erst bemerkt, dass der Signal-Bot nicht mehr verbunden war, vermutlich weil Version zu alt.
Ein Update via Install-Script hat ohne Probleme funktioniert, auch musste ich nicht neu registrieren, die alten Daten haben eindwandfrei funktioniert.
Was mich aber wundert: FHEM hat in den letzten Wochen definitiv versucht, Nachrichten via Signal zu versenden. Die sind natürlich nicht angekommen, weil der Service nicht verbunden war. Aber im FHEM Log gab es hierzu keine Einträge.
Ich habe das vorhin nochmal getestet, und verbose auf 5 gedreht, und dann mit einem nicht vergundenen Service versucht eine Nachrich aus FHEM an mein Handy zu senden.
Die kommt natürlich nicht an, aber im Log gibt's auch keine Fehlermeldung.
Ins FHEM-Log schau ich öfters rein (all 1-2 Tage), auf die einzelnen Module schau ich aber nicht so oft.
Wäre es nicht sinnvoll, im Falle eines Disconnects (beim Versenden einer Nachricht) eine entsprechende Fehlermeldung im Log auszugeben?
Dann wäre mir das Problem schon viel eher aufgefallen.
Viele Grüße,
Frank
Hallo Frank,
hier ist das Problem, dass die Verbindung zu Signal mehrstufig ist: FHEM -> signal-cli -> Signal
Die Verbindung von FHEM zu signal-cli hat immer funktioniert - nur dass alle Nachrichten "pending" (Reading sentMsgTimestamp) blieben, weil signal-cli sie nicht an Signal losbekommen hat. Fehler hierzu fanden sich dann nicht im FHEM log sondern im syslog.
Jetzt bin ich mir nicht sicher aus welchen Gründen eine Nachricht noch "pending" sein kann (Handy aus?) - sonst könnte man hier wohl mit einem Check ansetzen, der schaut wie alt das Reading ist, wenn es auf pending steht und nach einem Timeout vom Fehlerfall ausgehen.
Ich schicke mir täglich einen kleinen Report (Batteriesstatus), so dass mir relativ bald aufgefallen ist, dass diese Nachricht ausblieb.
Jörg
Ich kann's jetzt leider nicht mehr nachprüfen, da ich das Update eingespielt habe, und jetzt wieder alles geht.
Aber ich bin mir ziemlich sicher dass das FHEM-Device "Signalbot", das ich verwende, im Status "disconnected" war.
Und in dem Fall sollte doch das Modul einen Fehler-Log produzieren können, wenn dann "send message" ausgeführt wird, oder?
So, den Urlaub mal sinnvoll genutzt. Auf meinem zweiten IPC habe ich jetzt Debian 12 eingespielt und Signal fast sofort zum laufen bekommen (die Registrierung in /var/lib/signal-cli... vom alten System einfach kopiert).
Danke! Funktioniert!
Pro Tipp: Der Aufruf über
~# sh signal-install.sh crasht mit einem Bash Fehler:
root@axiom:~# sh signal_install.sh
signal_install.sh: 44: [: unexpected operator
signal_install.sh: 55: source: not found
This script will help you to install signal-cli as system dbus service
and prepare the use of the FHEM Signalbot module
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.12.8 (libsignal-client v0.36.1)
System library path: /usr/lib
System architecture: amd64
System GLIBC version: 2.36
Using Java version: /opt/java/bin/java
Native Java 21.0 no (current version:21.0)
signal_install.sh: 510: Syntax error: "(" unexpected (expecting "fi")
Das könnte man evtl. am Anfang abfangen und auf die richtige Syntax hinweisen.
Ich denke ich könnte schon abtesten ob jemand das Script "illegaler Weise" mit der falschen Shell gestartet hat - wobei ja die erste Zeile
#!/bin/basheine starke Indikation ist, dass der Bug hier vor der Tastatur sitzt :)
Woran könnte es liegen das bei der Registrierung einer Festnetznummer Fehler 429 kommt? Einfach mehrmals probieren?
Danke für das install Skript
Es stand hier https://github.com/AsamK/signal-cli/wiki/Quickstart das man sich erst normal registieren soll und nach 60 Sekunden mit dem Attribut Voice. Ich erhalte auch eine PIN per Telefon, in FHEM ist dann jedoch das verify nicht mehr zu sehen.
Und per Kommandozeile bekomme ich beim verifiy ein 404
Zitat von: tavoc am 22 Februar 2024, 14:39:11Ich erhalte auch eine PIN per Telefon, in FHEM ist dann jedoch das verify nicht mehr zu sehen
Dass verify weg ist sollte eigentlich nicht sein. Die Funktion ist aber höchstens ausgeblendet und ein 'set ... verify ...' sollte trotzdem gehen
Zitat von: Adimarantis am 22 Februar 2024, 09:11:31Ich denke ich könnte schon abtesten ob jemand das Script "illegaler Weise" mit der falschen Shell gestartet hat - wobei ja die erste Zeile
#!/bin/basheine starke Indikation ist, dass der Bug hier vor der Tastatur sitzt :)
Mir war bis eben nicht bewusst, dass Debian gar nicht Bash sondern Dash als Standard für /bin/usr/sh benutzt :o Nach >10 Jahren ubuntu vergisst man dieses und jenes
Hallo Adimirantis,
kann es sein, das die libsignal_jni.so von https://github.com/exquo/signal-libs-build/releases/download/libsignal_v0.39.2/libsignal_jni.so-v0.39.2-x86_64-unknown-linux-gnu.tar.gz noch mit Java 17 kompiliert ist?
Ich bekomme folgende Fehlermeldung, wenn ich die einzelnen Schritte händisch ausführe (Sorry, ich mache aus historischen Gründen immer alles manuell):
Feb 22 14:10:28 inuc systemd[1]: Stopping Send secure messages to Signal clients...
Feb 22 14:10:29 inuc systemd[1]: signal.service: Main process exited, code=exited, status=143/n/a
Feb 22 14:10:29 inuc systemd[1]: signal.service: Failed with result 'exit-code'.
Feb 22 14:10:29 inuc systemd[1]: Stopped Send secure messages to Signal clients.
Feb 22 14:10:29 inuc systemd[1]: signal.service: Consumed 4min 59.291s CPU time.
Feb 22 14:10:29 inuc systemd[1]: Starting Send secure messages to Signal clients...
Feb 22 14:10:29 inuc signal-cli[175600]: Error: LinkageError occurred while loading main class org.asamk.signal.Main
Feb 22 14:10:29 inuc signal-cli[175600]: #011java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
Feb 22 14:10:29 inuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Feb 22 14:10:29 inuc systemd[1]: signal.service: Failed with result 'exit-code'.
Feb 22 14:10:29 inuc systemd[1]: Failed to start Send secure messages to Signal clients.
Was habe ich gemacht:
die letzte signal-cli 0.13.0 von hier:https://github.com/AsamK/signal-cli/releases/
Die passende libsignal 0.39.2 von hier: https://github.com/exquo/signal-libs-build/releases
also
https://github.com/AsamK/signal-cli/releases/download/v0.13.0/signal-cli-0.13.0.tar.gz
https://github.com/exquo/signal-libs-build/releases/download/libsignal_v0.39.2/libsignal_jni.so-v0.39.2-x86_64-unknown-linux-gnu.tar.gz ausgepackt, und dann nach /opt/fhem/signal-cli-0.13.0/lib verschoben
Dann in /opt/fhem/signal-cli-0.13.0/lib ein "sudo zip -uj libsignal-client-0.39.2.jar libsignal_jni.so" ausgeführt
Architektur und OS:
fhem@inuc:~$ lsb_release -d && uname -r
Description: Debian GNU/Linux 11 (bullseye)
5.10.0-28-amd64
fhem@inuc:~$ arch
x86_64
fhem@inuc:~$
Java Major class file version
22 66
21 65
20 64
19 63
18 62
17 61
16 60
Feb 22 14:10:29 inuc signal-cli[175600]: #011java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0Das lese ich eher anders rum: Du versuchst eine Java 21 Klasse mit Java 17 auszuführen.
Schau mal das JAVA_HOME in deinem signal.service File an, ob das auf eine Java 21 Installation zeigt.
Jörg
Hallo Jörg,
danke das war es, in /etc/systemd/system/signal.service wat der Pfad falsch gesetzt. Jetzt stolpere ich wieder über den `GLIBC_2.33' not found Fehler den ich auch früher schon mal hatte, hast DU noch eine Idee? https://forum.fhem.de/index.php?topic=118370.msg1284304#msg1284304
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-02-23 13:22:52 CET; 13s ago
Process: 273185 ExecStart=/opt/fhem/signal-cli/bin/signal-cli --config /opt/fhem/.local/share/signal-cli daemon --system (code=exited, status=1/FAILURE)
Main PID: 273185 (code=exited, status=1/FAILURE)
CPU: 2.269s
Feb 23 13:22:51 inuc systemd[1]: Starting Send secure messages to Signal clients...
Feb 23 13:22:52 inuc signal-cli[273185]: WARN Manager - Failed to call libsignal-client: /tmp/11068233081262817106libsignal_jni.so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /tmp/11068233081262817106libsignal_jni.so)
Feb 23 13:22:52 inuc signal-cli[273185]: Missing required native library dependency: libsignal-client
Feb 23 13:22:52 inuc systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
Feb 23 13:22:52 inuc systemd[1]: signal.service: Failed with result 'exit-code'.
Feb 23 13:22:52 inuc systemd[1]: Failed to start Send secure messages to Signal clients.
Feb 23 13:22:52 inuc systemd[1]: signal.service: Consumed 2.269s CPU time.
fhem@inuc:~$ ldd --version
ldd (Debian GLIBC 2.31-13+deb11u8) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
fhem@inuc:~$
Hi Jamo,
also da weiss ich jetzt echt nicht was du da verpfriemelt hast.
Habe gerade testweise auf meiner x86_64 Debian 10 (glibc 2.28) VM den Installer durchlaufen lassen und signal-cli kam ordentlich hoch.
Der Installer musste dabei fast alles Nachinstallieren, da auf der VM noch gar nix drauf war.
Vielleicht doch besser nicht von Hand? Im Installer steckt das ganze Know How, was man braucht und wie es zusammenpasst.
Jörg
Hallo Jörg,
danke, sorry und mea Culpa. Ich habe jetzt alles nochmal gemacht, und jetzt gehts.
Ich kann Dir keine privaten e-mail schreiben, aber falls Du irgendwo eine Spendenbox hast, dann lass es mich wissen, ich würde mcih gerne für deinen Suport erkenntlich zeigen.
Beste Grüsse, Jamo
Signalbot:3.16 signal-cli:0.13.0 Protocol::DBus:0.22
Hi
My installation kept disconnected. So I tried a new installation. In a not so smart moment I decided to change the default answer for upgrading from n to Y.
After restoring the settings the signal bot connected correctly, however after a reboot of my raspberry signalbot kept disconnected.
My systemctl gives now:
feb 23 16:58:23 Debi12-12 signal-cli[24384]: Error: LinkageError occurred while loading main class org.asamk.signal.Main
feb 23 16:58:23 Debi12-12 signal-cli[24384]: java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
feb 23 16:58:23 Debi12-12 systemd[1]: signal.service: Main process exited, code=exited, status=1/FAILURE
The install script gives me:
Please verify that these settings are correct:
Signal-cli User: signal-cli
Signal-cli Install directory: /opt
Signal config storage: /var/lib/signal-cli
Signal version: 0.13.0 (libsignal-client v0.39.2)
System library path: /usr/lib
System architecture: aarch64
System GLIBC version: 2.36
Using Java version: /opt/java/bin/java
Native Java 21.0 no (current version:21.0)
This will update system packages, install or uninstall signal-cli
I already tried removing the installation and reinstall. And I removed /opt/signal and tried a new install.
Any idea how I can get it solved?
Thanks
Hi Harry,
yes, I just had the same issue, pls see https://forum.fhem.de/index.php?msg=1304410
Jörg helped out and explained that it is needed to set $JAVA_HOME in /etc/systemd/system/signal.service to your Java21 install directory, e.g. in your case it should be Environment="JAVA_HOME= /opt/java"
Hope that helps
Best regards, Jamo
Thanks Jamo
However I already "fixed" it by reinstallig with
SIGNALVERSION="0.12.8"
LIBRARYVERSION="0.36.1"
However if I send a message now, I don´t receive it on my smartphone and it stays "pending"
The deamon is running correct and the logging doesn´t give an error.
What can be wrong and how to solve that?
Hi Harry,
I had the same 'pending' two weeks time ago, but I do not recall how I fixed it. Did you try a "set signal reinit"?
Hi Jamo
Thanks for your suggestion.
Yes indeed, I tried "reinit" but that didn´t change anything as far I can see.
More suggestions??
{HT}
Did you check syslog? It might be that 0.12.8 also is too old now, but you would only see that message in syslog. Unfortunately Signalbot has not way of knowing. In that case message staying on "pending" is expected.
signal-cli 0.12.8 seems to still have tolerated running Java 17, that's why it seems to work.
However you should update to 0.13.0 and Java 21. I recommend to run the current Installer (3.24) and let it also replace all system configuration files, which should make sure the JAVA_HOME is set correctly.
Your error message clearly indicates that your signal-cli is still trying to use Java 17
Ich habe jetzt ein kleines Update eingecheckt:
1. Es wird jetzt mittels Timer geprüft ob Nachrichten tatsächlich versendet werden. Default ist 60s (plus 5s Karenz) - kann über das Attribute "sendTimeout" verändert werden. Auswirkungen sind lediglich ein Logfile Eintrag mit loglevel 1 ("Timeout in sendMessage - check your syslog for signal-cli issues") und ein Eintrag in lastErr. Lasst mich wissen ob es hier "false positives" gibt.
2. Es gibt jetzt ein verstecktes "set" Kommando "rateLimit" mit dem eine rateLimitChallenge gesendet werden kann. Diese benötigt 2 Parameter - eine "Challenge" und ein Captcha. Leider weiss ich nicht wie diese "Challenge" aussieht und wie man sie findet (ich hatte den "rate limit exceeded" Fall selbst noch nicht). Deswegen nur versteckt - also über Befehlszeile "set ... rateLimit <challenge> <captcha>" - im Dropdown erscheint er nicht. Falls jemand rausfindet wie und ob das funktioniert, kann ichs gerne dokumentieren.
Für alle die an oben genannten Punkten nicht interessiert sind, bringt das Update keinen Mehrwert.
Jörg
Hi
I removed the alt installation and reinstalled the newest version with version 0.13. And finally changed in /etc/systemd/system/signal.service the line "Environment="JAVA_HOME=" to "Environment="JAVA_HOME=/opt/java".
Unfortunately that was not enough.
Then I used
"set SignalBot trust +316xxxxxx"
this did the trick.
Strange as after this I can send a message to my wifes phone without trusting it first.
Maybe may phone was blocked because I tried so often to range my phone without luck?
So it seems to work again now.
Btw If you install the newest version it works until you reboot. You have to change signal.service to point to the correct java version, but the error I get in fhem is:
signal-cli v0.11.2+ required.
Please use installer to install or update
Note: The installer only supports Debian based Linux distributions like Ubuntu and Raspberry OS
and X86 or armv7l CPUs
You can download the installer here or your www/signal directory and run it with
sudo ./signal_install.sh
Maybe it is better to change this in a message that you have to change signal.service to point to the correct java version.
Anyway, thanks all for the help and advice.
{HT}
Ich habe folgendes Problem:
Wenn ich das Installationsscript laufen lasse wird der signal service gestartet und scheint normal zu laufen.
Wenn ich versuche meinen Account neu zu registrieren schlägt dies fehl mit "Account in use"
Wenn ich versuche den Signal Service neu zu starten zeigt mir ein "service signal status" folgende Fehlermeldung:
signal-cli[6250]: Caused by: org.sqlite.NativeLibraryNotFoundException: No native library found for os.name=Linux, os.arch=aarch64, paths=[/org/sqlite/native/Linux/aarch64:/usr/java/packages/lib:/lib:/usr/lib]
Denke das hängt vielleicht zusammen. Warum kommt diese Fehlermeldung?
Ich vermute mal du hast einen Raspberry mit 64-Bit Kernel aber alle anderen Pakete noch unter 32-Bit.
Das passiert leider z.B. bei Buster ganz von selber wenn man seine normalen updates macht.
Da kommt Java leider durcheinander.
Abhilfe schafft den Kernel auf 32 Bit umzustellen:
In /boot/config.txt die Zeile
arm_64bit=0
anhängen und neu starten.
Sollte ich wohl ins Wiki aufnehmen.
Danke,
denke das ist mein Problem. Werde es mal testen ggf auch kpl. auf 64 Bit updaten
So hier noch einmal eine Rückmeldung zu meinem Problem
ZitatIch habe folgendes Problem:
Wenn ich das Installationsscript laufen lasse wird der signal service gestartet und scheint normal zu laufen.
Wenn ich versuche meinen Account neu zu registrieren schlägt dies fehl mit "Account in use"
Wenn ich versuche den Signal Service neu zu starten zeigt mir ein "service signal status" folgende Fehlermeldung:
Code Auswählen
signal-cli[6250]: Caused by: org.sqlite.NativeLibraryNotFoundException: No native library found for os.name=Linux, os.arch=aarch64, paths=[/org/sqlite/native/Linux/aarch64:/usr/java/packages/lib:/lib:/usr/lib]
Denke das hängt vielleicht zusammen. Warum kommt diese Fehlermeldung?
Es liegt an der Mischung von 64Bit Kernel und 32Bit Betriebssystem, bei reinen 32Bit oder 64Bit geht es.
Ein weiteres Problem war, wie bei vielen die Registrierung.
Nach vielen versuchen mit Firefox habe ich es dann einmal mit Chromium versucht und es hat sofort nach folgendem Schema funktioniert:
Signalbot auf SMS stellen reinit
1. Register ausführen
2. Signalbot auf voice umstellen
3. Register erneut ausführen
4. Es kommt ein Anruf mit der Nummer
5. captcha Prozedur durchführen
6. verify mit der erhaltenen Nummer
dann dauert es etwas bis es neu geladen ist.
Vielen Dank!
alles war offline seit langem und ich kam nicht dazu, nachzuschauen.
Dann wollte ich es fixen und es las sich kompliziert. Daraufhin habe ich es ewig verschoben und gewartet, bis Frau+Kind mal ein Wochenende fort sind.
Und am Ende musste ich nur das install-Script laufen lassen.
Mega. Nochmal vielen Dank!
Danke, jetzt funktioniert alles. Es hat geholfen im Browser den Redirect Link des Captchas zu nehmen.
Jetzt aber noch eine ganz dumme Frage. Normale Nachrichten senden klappt super.
Wie sende ich jetzt ein Reading oder ein Wert mit?
Z.b. ReadingsVal("myStromzaehler","solar",0)
oder [Device:temperature]
Bei mir wird es immer nur als Text interpretiert. Egal ob ich es zusätzlich in () oder mit &() einklammere oder direkt [Device:temperature] schreibe.
set Signalbot send Test [Device:temperature]
Zitat von: tavoc am 03 März 2024, 18:13:54set Signalbot send Test [Device:temperature]
Also bei geht ein set Signalbot send @xxxxx [Device:temp] wenn ich es als vollständigen Befehl absetze.
In der "send message" Box geht es aber nicht, irgendwie wird das anders verarbeitet. Muss ich mal anschauen.
Guten Morgen,
klappt leider auch nicht direkt aus der Kommandozeile.
Z.b.set Signalbot send @+491767xxxx [ZB_Keller_Leak_server:battery]
sendet mir nur den Text [ZB_Keller_Leak_server:battery]
Verstehe ich jetzt nicht. Klappt bei mir einwandfrei. Hab jetzt extra nochmal versucht dein Szenario so genau wie möglich nachzustellen (senden an Nummer statt Alias, Device mit Unterstrichen).
Kannst du mal verbose auf 5 stellen und den Ausschnitt aus dem Logfile schicken?
Ich habe im Device Signalbot verbose auf 5 gestellt.
Wenn ich in der Konsole von FHEM folgendes eingebe (habe nur meine Handynummer hier ausgexxxxt:
set Signalbot send @+491767087xxxx [ZB_Keller_Leak_server:battery]
Dann steht im Eventlog:
24-03-04 08:29:02 Signalbot Signalbot sentMsg: [ZB_Keller_Leak_server:battery]
2024-03-04 08:29:02 Signalbot Signalbot sentMsgTimestamp: pending
2024.03.04 08:29:02 5: Signalbot: Dbus Call sync:0 sendMessage(sasas) /org/asamk/Signal/_493065833xxx Args:[ZB_Keller_Leak_server:battery],ARRAY(0x559a9ca4f0),ARRAY(0x559bd673d8)
2024.03.04 08:29:02 5: Signalbot: DBus callback: sendMessage Args:1709537342748
2024.03.04 08:29:22 5: Signalbot: Sync Callback: ReceiptReceived Args:1709537225325,+491767087xxxx
2024.03.04 08:29:22 5: Signalbot: Signalbot_receive_callback 1709537225325 +491767087xxxx
2024-03-04 08:29:22 Signalbot Signalbot sentMsgRecipient: MR
2024-03-04 08:29:22 Signalbot Signalbot sentMsgTimestamp: 04-03-2024 08:27:05
2024.03.04 08:29:22 4: Signalbot: Unknown callback ReceiptReceivedV2
2024.03.04 08:29:22 5: Signalbot: Sync Callback: ReceiptReceived Args:1709537291201,+491767087xxxx
2024.03.04 08:29:22 5: Signalbot: Signalbot_receive_callback 1709537291201 +491767087xxxx
2024-03-04 08:29:22 Signalbot Signalbot sentMsgRecipient: MR
2024-03-04 08:29:22 Signalbot Signalbot sentMsgTimestamp: 04-03-2024 08:28:11
2024.03.04 08:29:22 4: Signalbot: Unknown callback ReceiptReceivedV2
2024.03.04 08:29:22 5: Signalbot: Sync Callback: ReceiptReceived Args:1709537342748,+491767087xxxx
2024.03.04 08:29:22 5: Signalbot: Signalbot_receive_callback 1709537342748 +491767087xxxx
2024-03-04 08:29:22 Signalbot Signalbot sentMsgRecipient: MaR
2024-03-04 08:29:22 Signalbot Signalbot sentMsgTimestamp: 04-03-2024 08:29:02
2024.03.04 08:29:22 4: Signalbot: Unknown callback ReceiptReceivedV2
2024.03.04 08:29:23 5: Signalbot: Sync Callback: ReceiptReceived Args:1709537342748,+491767087xxxx
2024.03.04 08:29:23 5: Signalbot: Signalbot_receive_callback 1709537342748 +491767087xxxx
2024-03-04 08:29:23 Signalbot Signalbot sentMsgRecipient: MR
2024-03-04 08:29:23 Signalbot Signalbot sentMsgTimestamp: 04-03-2024 08:29:02
2024.03.04 08:29:23 4: Signalbot: Unknown callback ReceiptReceivedV2
und hier ein List vom Device Signalbot
Internals:
FD 92
FUUID 65e464fe-f33f-aca1-10d8-c6292e6fb99e7e1a
NAME Signalbot
NOTIFYDEV global
NR 282
NTFY_ORDER 50-Signalbot
STATE Connected to /org/asamk/Signal/_493065833xxx
TYPE Signalbot
VERSION Signalbot:3.16 signal-cli:0.13.0 Protocol::DBus:0.22
eventCount 173
model Ubuntu 22.04.4 LTS
READINGS:
2024-03-03 17:13:07 account +493065833xxx
2024-03-03 17:13:07 accountName
2024-03-03 13:12:14 joinedGroups
2024-03-03 18:08:41 lastError Unknown command 21.58, try help.
2024-03-04 08:29:02 sentMsg [ZB_Keller_Leak_server:battery]
2024-03-04 08:29:23 sentMsgRecipient MR
2024-03-04 08:29:23 sentMsgTimestamp 04-03-2024 08:29:02
2024-03-03 17:13:07 state Connected to /org/asamk/Signal/_493065833xxx
helper:
accounts 1
captcha
init 1
multi 1
qr
register
signalpath /org/asamk/Signal/_493065833xxx
verification
version 1300
accountlist:
+493065833xxx
chat:
+491767087xxxx <b>Me</b> (03-03-2024 18:02): v SVG_FileLog_myStromzaehler_1
<b>Me</b> (03-03-2024 18:08): [MQTT2_zigbee_ZB_Flur_Temperatur:temperature]
<b>Me</b> (03-03-2024 18:08): ([MQTT2_zigbee_ZB_Flur_Temperatur:temperature])
<b>Me</b> (03-03-2024 18:09): erf [MQTT2_zigbee_ZB_Flur_Temperatur:temperature]
<b>Me</b> (03-03-2024 18:10): er {ReadingsVal(myStromzaehler,solar,0)}
<b>Me</b> (04-03-2024 07:12): Guten Morgen
<b>Me</b> (04-03-2024 07:52): [ZB_Keller_Leak_server:battery]
<b>Me</b> (04-03-2024 07:54): [ZB_Keller_Leak_server:battery]
<b>Me</b> (04-03-2024 08:27): [ZB_Keller_Leak_server:battery]
<b>Me</b> (04-03-2024 08:28): [ZB_Keller_Leak_server:battery]
<b>Me</b> (04-03-2024 08:29): [ZB_Keller_Leak_server:battery]
491767087xxxx <b>Me</b> (04-03-2024 07:54): [ZB_Keller_Leak_server:battery]
contacts:
+49176708xxxx MR
+493065833xxx
groups:
identities:
+491767087xxxx:
SafetyNumber 133855679780075312413006794488561300111667367044606964026401
TrustLevel TRUSTED_UNVERIFIED
+493065833xxx:
SafetyNumber 133855679780075312413006794488133855679780075312413006794488
TrustLevel TRUSTED_VERIFIED
Attributes:
defaultPeer +491767087xxxx
room Keller
verbose 5
Du siehst mich ratlos.
Den Effekt kann ich nur produzieren, wenn Device Name oder Reading nicht existieren.
Interessant finde ich folgendes:
2024-03-03 18:08:41 lastError Unknown command 21.58, try help.Ich schätze mal 21.58 war die Temperatur die du senden wolltest - er hat sie zumindest bei einem der passenden Versuche aus dem Chat Protokoll
<b>Me</b> (03-03-2024 18:08): [MQTT2_zigbee_ZB_Flur_Temperatur:temperature]
<b>Me</b> (03-03-2024 18:08): ([MQTT2_zigbee_ZB_Flur_Temperatur:temperature])als Kommando interpretiert. Wenn du es schaffst den Fall nochmal nachzustellen und ein Logfile zu erstellen?
Wie schaut es eigentich aus, wenn du das aus einem DOIF heraus aufrufst?
Hallo,
ich habe das gleiche Problem das nur der Text übermittelt wird aber nicht die Werte.
Welchen Browser/OS verwendet ihr?
Vielleicht liegts daran - ich verwende Chrome unter Windows zum Testen.
Edit: Noch eine Idee um zu sehen ob es überhaupt am Signalbot liegt.
Erzeugt mal ein Dummy und weist euer reading dort zu, also
define dummy dummy
set dummy [device:reading]
Danach sollte im dummy der Inhalt des Readings stehen.
Zitat von: Medel am 03 März 2024, 11:21:11Ein weiteres Problem war, wie bei vielen die Registrierung.
Nach vielen versuchen mit Firefox habe ich es dann einmal mit Chromium versucht und es hat sofort nach folgendem Schema funktioniert:
Signalbot auf SMS stellen reinit
1. Register ausführen
2. Signalbot auf voice umstellen
3. Register erneut ausführen
4. Es kommt ein Anruf mit der Nummer
5. captcha Prozedur durchführen
6. verify mit der erhaltenen Nummer
dann dauert es etwas bis es neu geladen ist.
Danke für den Tipp mit Chrome!!!
Ich hatte auch mit Firefox seit Wochen erfolglos probiert, Signal wieder ans Laufen zu bekommen. Mit Chrome lief die Registrierung sofort durch :)
Ich benutze Linux und Chromium.
real.png
Du hast recht, es scheint ein anderes Problem zu sein.
Habe jetzt den Hinweis mit Chrome und den Ablauf oben ins Wiki aufgenommen
Noch ein kleines update von mir:
Die Prozedur war bei mir leicht anders, nur falls sich jemand wundert. (Windows/Chrome)
1. Signalbot auf SMS stellen
2. Register ausführen
3. Captcha durchlaufen
4. Signalbot auf voice stellen
5. Register erneut ausführen
6. Captcha durchlaufen
7. Es kommt ein Anruf mit der Nummer
8. verify mit der erhaltenen Nummer
Wichtig war dann noch das Anlegen eines Profils (set updateProfile ...)!
Sonst ging mit der aktuellen Version keine Message raus. In der Vergangenheit (bis Januar) brauchte ich das Profil nicht.
Hallo,
ich verwende Edge auf Win11.
Wenn ich ein Dummy anlege und dem einen Wert gebe, dann geht es da:
define test dummy
set test [MQTT2_zigbee_ZB_Flur_Temperatur:temperature]
dann habe ich da die richtige Temperatur drin.
Komischerweise geht heute auch ein
set Signalbot send [MQTT2_zigbee_ZB_Flur_Temperatur:temperature] in der Kommandozeile. Keine Ahnung warum
Zitat von: KarlHeinz2000 am 07 März 2024, 08:11:25Wichtig war dann noch das Anlegen eines Profils (set updateProfile ...)!
Sonst ging mit der aktuellen Version keine Message raus. In der Vergangenheit (bis Januar) brauchte ich das Profil nicht.
Danke - das mit dem updateProfile habe ich noch im Wiki ergänzt.
Zitat von: ironalf am 06 März 2024, 13:11:20Ich benutze Linux und Chromium.
[url="https://forum.fhem.de/index.php?action=dlattach;attach=176767;type=preview;file"]real.png[/url]
Du hast recht, es scheint ein anderes Problem zu sein.
Habe das Problem gefunden. Bei dieser FHEM-Installation hatte ich featurelevel noch auf 5.6 gesetzt :(
Hallo,
ich versuche gerade, Signalbot zum ersten Mal zu installieren.
signal-cli ist auf raspberrypi4 erfolgreich installiert.
Register mit Rufnummer habe ich gestartet.
Ich scheitere beim Captcha. Ich kann es im Browser erfolgreich ausführen und bekomme als Link signalcaptcha://signal-hcaptcha.5fad97ac-7xxxxxx (signalcaptcha://signal-hcaptcha.5fad97ac-7xxxxxx)
Füge ich diesen Link in
set Signalbot captcha
ein, bekomme ich die Fehlermeldung
Error in registerWithCaptcha:VerificationMethoNotAvailableException Invalid verification method
Das passiert bei Ausführen des Captcha in Firefox und Brave unter Linux und in Firefox und Edge in Windows.
Ich habe in diesem Artikel und auch sonst keinen Hinweis zu diesem Fehler gefunden. Daher hoffe ich, dass mir jemand einen Tipp geben kann, was die Ursache des Fehlers ist.
Vielen Dank im voraus
Matthias
Nachdem sich Probleme bei der Registrierung in letzter Zeit häufen, habe ich selbst mal wieder versucht eine Festnetznummer zu registrieren.
Der Fehler "registerWithCaptcha:VerificationMethoNotAvailableException Invalid verification method" scheint jetzt immer zu kommen, wenn man versucht sich sofort mit "Voice" zu registrieren. Man muss erst "SMS" nehmen und dann ca. 1 Minute später ist "Voice" auch möglich. Mal sehen ob ich hier die Benutzerführung in Signalbot verbessern kann, damit da keiner mehr reinstolpert.
Soweit aber die Theorie, ich bekomme selbst immer eine "invalid captcha" Meldung - egal ob aus SignalBot heraus oder direkt in der Kommandozeile.
Daher habe ich jetzt mal ein Issue bei signal-cli aufgemacht.
Signal befindet sich in der ständigen Weiterentwicklung und signal-cli ist kein offizieller Bestandteil. Daher kommt es leider immer wieder vor, dass Änderungen in Signal Probleme in signal-cli verursachen. Möglicherweise ist dies so ein Fall und wir müssen aktuell auf ein Update von signal-cli warten.
Ich habe zunächst mal ein Update von FHEM gemacht, es gibt aber keine neuere Version vom Signalbot-Modul.
Dann habe ich auf registerMethod SMS umgestellt und eine neue Registrierung versucht. Bei Eintragung des Captcha-Links kommt jetzt eine etwas andere Fehlermeldung:
Error with captcha:Error in registerWithCaptcha:ExternalServiceFailureException StatusCode: 502
Könnte es evtl. daran liegen, dass ein signal-hcaptcha erzeugt wird, während das Beispiel im Registrierungsassistenten signal-recaptcha-v2.6 aufführt? Evtl. hat Signal ja die Captcha-Methode geändert und signal-cli kennt das noch nicht?
Matthias
Zitat von: matkoh am 16 März 2024, 12:12:27Ich habe zunächst mal ein Update von FHEM gemacht, es gibt aber keine neuere Version vom Signalbot-Modul.
In Signalbot sind meistens keine Änderungen notwendig, da das Interface zu signal-cli recht stabil bleibt.
ZitatError with captcha:Error in registerWithCaptcha:ExternalServiceFailureException StatusCode: 502
Das schaut jetzt mehr nach einem Verbindungfehler aus. Evtl. später nochmal probieren.
ZitatKönnte es evtl. daran liegen, dass ein signal-hcaptcha erzeugt wird, während das Beispiel im Registrierungsassistenten signal-recaptcha-v2.6 aufführt? Evtl. hat Signal ja die Captcha-Methode geändert und signal-cli kennt das noch nicht?
Nein. Mein Beispiel im Hilfstext ist veraltet. Das Captcha wird direkt an Signal weitergereicht - und was Signal erwartet sollte ja mit der Signal-eigenen Captcha Seite übereinstimmen. Das wird m.E. (im Hintergrund) auch von der Mobile App so verwendet.
Wichtig ist noch dass die aktuelle signal-cli version (0.13.1) verwendet wird.
Also, ich habe gerade nochmal die Registrierung mit der aktuellen Development Version (0.13.2-SNAPSHOT) probiert und es hat jetzt geklappt.
Allerdings sahen die Captchas auch etwas anders aus (signal-hcaptcha.5fad97ac-7d06-4e44-b18a-b950b20148ff.challenge...) (gestern stand statt "challenge" der String "registration") - was ja nichts mit der installierten Version zu tun hat.
@matkoh: Kannst du es nochmal probieren um festzustellen ob es ein Versionsproblem ist (dann musst du wohl auf das 0.13.2 update warten) oder nur ein temporäres Problem mit den Captchas war.
Es scheint ein temporäres Problem gewesen zu sein. Ich konnte jetzt den Captcha eingeben und bekam keine Fehlermeldung.
Allerdings scheint sich jetzt etwas verhakt zu haben:
Ich hatte zuletzt registerMethod = SMS gewählt, habe nach Eingabe des Captcha aber keine SMS erhalten. Ich habe als Festnetznummer eine Sipgate-Nummer angegeben, vielleicht liegt es daran. Ich habe es gerade auch mit meiner normalen Telekom-Festnetznummer versucht, da kommt auch keine SMS.
Dann habe ich die registerMethod auf Voice geändert und ein neues register durchgeführt. Dann bekomme ich direkt einen Anruf mit Durchgabe des Codes ohne Captcha. Allerdings habe ich dann keine Möglichkeit verify zu wählen, das steht nicht zur Verfügung.
Wie kann ich die Registrierung mit Voice komplett durchführen?
Matthias
War dein Ablauf: set register, set captcha - und dann gab es kein verifiy?
Sollte eigentlich nicht sein, aber dass verify ausgeblendet wird, ist rein zur Übersichtlichkeit.
Du kannst trotzdem ein "set Signalbot verify <pin>" oben in der Kommandozeile durchführen.
Der Ablauf unterscheidet sich je nach registerMethod:
SMS:
set register
set captcha
- nichts mehr, keine SMS
Voice:
set register
Anruf mit Durchsage PIN
kein verify möglich, set Signalbot verify funktioniert auch nicht.
Gerade habe ich es nochmal versucht mit Voice:
set register
set captcha -> Error with captcha:Error in registerWithCaptcha:VerificationMethoNotAvailableException Invalid verification method
Jetzt scheint wieder Captcha nicht zu gehen. Ich versuche es weiter.
Matthias
Dass ein erneutest Register mit "voice" dann gleich einen Anruf zur Folge hat, hätte ich jetzt nicht erwartet.
Wie lange hast du zwischen SMS und Voice gewartet?
Bietet evtl. die Möglichkeit das im Hintergrund zu automatisieren.
Fürs erste wird dadurch wohl der Ablauf in Signalbot durcheinandergebracht.
Als Quick Fix, versuche es mit der angehängten Version. Die macht bei "register" keinen Aufruf von signal-cli mehr, so das du zwingend "set captcha" machen musst, womit der Ablauf wieder passen sollte, und "set verify" verfügbar sein sollte. (so hat es bei mir zumindest geklappt)
Wenn ich mehr Zeit habe, könnte ich vielleicht den Ablauf so abändern, dass bei "Voice" automatisch erstmal "SMS" gemacht wird, dann muss man das Captcha eingeben und als nächstes wartet dann Signalbot 60s und triggert dann den Anruf (ohne Captcha, welches anscheinend dann irgendwie noch gültig ist). Mal sehen...
Mit der angehängten Version hat die Registrierung funktioniert:
registerMethod = SMS
set register
set captcha
1 Minute warten
registerMethon = Voice
set register
set captcha
Anruf mit Durchgabe PIN
set verify
- Connected to /org/asamk/Signal/_49xxxxx
Seltsamerweise kommen aus FHEM gesandte Nachrichten auf dem Smartphone nicht an. Vom Smartphone an FHEM gesandte Nachrichten werden im Signalbot aber angezeigt.
Kann mir da auch noch jemand einen Tipp geben?
Matthias
Da hilft meistens den "trust" herzustellen
Es scheint ein Problem mit meiner Installation von signal-cli zu geben:
/opt/signal/bin $ ./signal-cli
Fehler: Beim Laden der Klasse org.asamk.signal.Main ist ein LinkageError aufgetreten
java.lang.UnsupportedClassVersionError: org/asamk/signal/Main has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
Die Java-Version 21 ist installiert:
/opt/java/bin/java --version
openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)
wird aber nicht verwendet:
sudo update-alternatives --config java
Es gibt 1 Auswahlmöglichkeit für die Alternative java (welche /usr/bin/java bereitstellt).
Auswahl Pfad Priorität Status
------------------------------------------------------------
* 0 /usr/lib/jvm/java-17-openjdk-arm64/bin/java 1711 automatischer Modus
1 /usr/lib/jvm/java-17-openjdk-arm64/bin/java 1711 manueller Modus
Ich vermute, dass das die Ursache für die Sendeprobleme sind. Seltsamerweise kann der Signalbot Nachrichten vom Smartphone empfangen und mit reply auch antworten. Aber Senden an @+49xxxxx geht nicht.
Wenn ich
set Signalbot trust all
eingebe, kommt
not implemented
Ich gehe davon aus, dass ich zunächst die neu installierte Java-Version für signal-cli zuordnen muss. Aber bisher gelingt mir das nicht.
Matthias
Das Senden von Nachrichten funktioniert jetzt!
Ich habe in diesem Post ein paar Seiten zurückgeblättert und bin auf ähnliche Probleme gestoßen. Mit
set Signalbot trust +49xxxx
in der FHEM-Kommandozeile kann der Trust hergestellt werden, was mit
set Signalbot trust all
nicht funktioniert. Danach kann ich Nachrichten von Signalbot an das Smartphone senden.
In /etc/systemd/system/signal.service ist übrigens
Environment="JAVA_HOME=/opt/java"
gesetzt, der Fehler zur Java-Version kommt beim Aufruf von signal-cli trotzdem - hat aber scheinbar nichts mit dem Sendeproblem zu tun.
Matthias
Wenn du signal-cli von der Kommandozeile probierst muss
export JAVA_HOME=/opt/java gesetzt sein - sonst nimmt er möglicherweise trotzdem das falsche.
Moin Adimarantis
Ich mus mich jetzt leider auch um Hilfe bitten.
Ich habe das letzte Installer-Script aus dem /opt/fhem/contrib verwendet (SCRIPTVERSION="3.26") ausgefuehrt, welches die Installation ohne Fehler übernimmt.
Doch nach wie vor unter "Voice" nur die Fehlermeldung
"Error with captcha:Error in registerWithCaptcha:VerificationMethodNotAvailableException Invalid verification method "
unter "SMS" die folgende Fehlermeldung:
"Error with captcha:Error in registerWithCaptcha:RegistrationRetryException StatusCode: 429 "
Ich habe nebenbei den SIGNAL - Client auf meinem Linux - Rechner laufen, welcher sich sofort nach lösen des Captchas öffnet.
Ich hoffe das Captcha "verbraucht" sich dadurch nicht.
Gruß
Sailor
Das ist natürlich möglich. Erzeuge das Captcha doch einfach auf einem anderen Rechner und kopiere ihn ins "set ... captcha".
Also wie beschrieben, erst SMS, 1 Minute warten, dann nochmal (neues Captcha) mit Voice.
Hallo Adimarantis
Zitat von: Adimarantis am 26 März 2024, 20:32:25Das ist natürlich möglich. Erzeuge das Captcha doch einfach auf einem anderen Rechner und kopiere ihn ins "set ... captcha".
Also wie beschrieben, erst SMS, 1 Minute warten, dann nochmal (neues Captcha) mit Voice.
Danke für den Tipp!
Also, das war ja 'ne Nummer!
Ich beschreibe mal Schritt für Schritt was letztendlich zum Erfolg geführt hat:
1. Den neusten Installer heruntergeladen: http://svn.fhem.de/fhem/trunk/fhem/contrib/signal/signal_install.sh
2. Rechte vergeben und als sudo ausgeführt.
3. Signal Desktop deinstallieren.
4. Alten SignalBot in fhem gelöscht und neu angelegt.
5. Attribut "registerMethod" auf "SMS" gesetzt.
6. Den Befehl "set myBotti register +49301234567" ausgeführt.
7. Captcha ausgeführt und mittel "set myBotti setCaptcha ..." implementiert.
7. Was zu trinken geholt.
8. Attribut "registerMethod" auf "Voice" gesetzt
9. Den Befehl "set myBotti register +49301234567" ausgeführt.
10. Den Anruf weggedrückt, da kein Menüpunkt "verify" vorhanden war.
11. Den Befehl "set myBotti register +49301234567" nochmal ausgeführt.
12. Captcha ausgeführt und mittel "set myBotti setCaptcha ..." implementiert.
13. Anruf entgegengenommen und Nummer von der Tante mit eindeutigen ADHS-Syptomen aufgeschrieben.
14. Den Code mit "set myBotti verify 1234567" bestätigt.
Funzt!
Wat'n Aufriss!
Gruss
Sailor
Ja, irgendwie wird das immer schlimmer mit den Sicherheitsmechanismen.
Ich habe mich jetzt mal hingesetzt und versucht das so weit möglich zu automatisieren.
Keine Ahnung ob sich jemand findet, der es mal probieren will. Das Ganze ist extrem umständlich zum Testen und ich habe jetzt nur den häufigsten Fall (Registrierung mit Voice) durchgetestet.
Die angehängt Version funktioniert jetzt so:
1. set register +49xxxxxx (mit registerMethod=Voice)
Es erscheint eine Seite die darüber aufklärt wie man ein Captcha bekommt und einen drauf hinweist, dass man bei Voice 60s Sekunden warten muss
2. set captcha signalcaptcha://xxxxxx
Es erscheint eine neue Seite mit dem Hinweis das es 60s Sekunden dauern wird, bis man einen Anruf kriegt und den Code mit set verify eingeben muss
Intern sendet Signalbot das Captcha erst mit SMS, setzt einen Timer auf 60s und sendet es erneut mit Voice. Das scheint zu funktionieren, da die Captchas eine Weile gültig bleiben und nicht kontrolliert wird, wenn man das selbe Captcha 2x verwendet.
3. Man kriegt den Anruf und macht set verify
Dann sollte soweit alles abgeschlossen sein und man ist registriert.
Wenn es jemand probieren will, vielleicht mit einer zweiten Festnetznummer, bzw. man kann seine eigenen Nummer rauswerfen - leider gar nicht so einfach:
Ich hatte mit folgender Prozedur Erfolg:
set Signalbot unregister +49xxxxxx
Dann in der Shell - am besten gleich mit "sudo bash", da das Verzeichnis geschützt ist.
cd /var/lib/signal-cli/data
service signal stop
Datei "accounts.json" editieren und den Abschnitt mit der entsprechenden Nummer rauslöschen
Unter "path" steht der Dateiname für die eigentlichen Daten. Zum aufräumen diese Datei und das zugehörige Verzeichnis (mit ".d") löschen.
service signal start
Jetzt sollte die Nummer zuverlässig entfernt sein und man kann sie erneut registrieren.
Hab das erfolgreich paar mal hintereinander gemacht.
Gerne probieren, was passiert wenn man was falsch macht oder SMS probiert - da sind sicher noch Fehler im Ablauf drin.
Moin tosammen
Habe mir mal erlaubt offiziell das Signal Messenger Logo ins repository unter fhem/www/images/fhemSVG/signal_messenger.svg aufnehmen zu lassen.
Damit haben wir jetzt ein anständiges icon fuer den SignalBot.
Gruß
Sailor
Moin Adimarantis
Zitat von: Adimarantis am 28 März 2024, 17:52:47Wenn es jemand probieren will, vielleicht mit einer zweiten Festnetznummer, bzw. man kann seine eigenen Nummer rauswerfen - leider gar nicht so einfach:
Ich bin froh, dass es läuft.
Aber ich gehe davon aus, das sich der Nächste mit Problemen nicht lange auf sich warten lassen wird.
Dann haben wir ja ganz automatisch unseren unfreiwilligen Freiwilligen. :o
Gruß
Sailor
Nice :)
Dann setze ich das doch einfach standardmäßig im "define" als icon (sofern nicht schon gesetzt)
Hab die Version mit verbesserter Registrierung jetzt mal eingecheckt, nachdem ich den SMS flow auch testen konnte (V3.19).
Das Icon wird jetzt auch automatisch gesetzt, wenn keins vorhanden.
Hallo,
ich habe mich jetzt auch mal daran versucht, allerdings bekomme ich es nicht zum Laufen...
Eigentlich habe ich alles nach Anleitung von Adimarantis vom 28.03. gemacht und es scheint auch alles geklappt zu haben, aber die Connected Info sieht komisch aus und wenn ich etas sende bleibt es beim pending.
Hat jemand einen Tipp was ich vielleicht falsch mache / ändern muss?
Danke.
1.png
Hallo Adimarantis,
ich möchte einen Zeilenumbruch beim state hinzufügen.
Prinzipiell gelingt dies durch das Attribut stateFormat:
attr mySignal stateFormat {my $_state; $_state = ReadingsVal('mySignal','state',''); $_state =~ s/to /to \n/g; $_state;}Leider wird das state einzeilig angezeigt, wobei STATE zweizeilig ist:
STATE Connected to
/org/asamk/Signal/_49XXXXXXXXXX
Vielleicht ist bei der Erklärung zu stateFormat ein Hinweis auf das unerwartete Ergebnis zu finden:
stateFormat
Modifies the STATE of the device, shown by the list command or in the room overview in FHEMWEB.
If not set, its value is taken from the state reading.
If set, then every word in the argument is replaced by the value of the reading
if such a reading for the current device exists.
If the value of this attribute is enclosed in {}, then it is evaluated.
This attribute is evaluated each time a reading is updated.
The "set magic" described here is also applied.
Note: some FHEM modules are setting STATE directly (against the guidelines),
in this case the attribute may not work as expected.
Kannst du dir das bei Gelegenheit mal anschauen?
Viele Grüße Gisbert
Hallo Gisbert,
das hat doch nichts mit dem Modul von Adimarantis zu tun, deine Formatierung für den Zeilenumbruch für stateformat ist falsch.
Mit "<br>" bekommst Du einen Zeilenumbruch:
{my $_state = ReadingsVal('mySignal','state',''); $_state =~ s/to /to <br>/g; return $_state;}
Zitat von: Jippy am 30 März 2024, 12:55:41Hallo,
ich habe mich jetzt auch mal daran versucht, allerdings bekomme ich es nicht zum Laufen...
Eigentlich habe ich alles nach Anleitung von Adimarantis vom 28.03. gemacht und es scheint auch alles geklappt zu haben, aber die Connected Info sieht komisch aus und wenn ich etas sende bleibt es beim pending.
Hat jemand einen Tipp was ich vielleicht falsch mache / ändern muss?
Danke.
Komischerweise geht es jetzt...
Bin gerade nach Hause gekommen, "sentMsgTimestamp" war immer noch pending... einfach noch mal eine neue Message geschickt und die ist angekommen :-*
Jetzt noch 4x versucht, alle angekommen, eine hat zwar 2 Minuten gebraucht aber egal, damit kann ich leben...
Trotzdem noch mal die Frage ob die Anzeige "Connected to /org/asamk/Signal/_49xxxxxxxxx" korrekt ist?
Ja das ist korrekt. Intern verwendet signal-cli den "_" an vielen Stellen, da das "+" in Pfadnamen Probleme bereitet.
Schau evtl. noch das sich die Kommunikationspartner gegenseitig vertrauen (siehe Wiki) - vielleicht gehts dann zügiger.
2 Minuten ist seltsam, sollte normalerweise innerhalb von Sekunden gehen - außer dein Rechner ist überlastet (und swapped z.B. signal-cli ständig raus und rein wegen zuwenig Speicher)
ZitatMit "<br>" bekommst Du einen Zeilenumbruch:
Hallo Jamo,
mit <br> funktioniert es tatsächlich, aber \n sollte doch bei Perl auch funktionieren.
Wie dem auch sei - ich hab jetzt eine Lösung.
Viele Grüße Gisbert
Zitat von: Gisbert am 30 März 2024, 20:14:02ZitatMit "<br>" bekommst Du einen Zeilenumbruch:
Hallo Jamo,
mit <br> funktioniert es tatsächlich, aber \n sollte doch bei Perl auch funktionieren.
Wie dem auch sei - ich hab jetzt eine Lösung.
Viele Grüße Gisbert
Hallo Gisbert,
die STATE Anzeige im Web Frontend ist aber HTML formatiert, deswegen <br>.
Jetzt habe ich noch mal eine Frage...
Kann man die STATE Anzeige "Connected to /org/asamk/Signal/_49xxxxxxxxx" durch ein Icon ersetzen?
Ich habe es mit dem Attribut devStateIcon "Connected.to./org/asamk/Signal/_49xxxxxxxxx: 10px-kreis-gruen" bzw. "Connected.*: 10px-kreis-gruen" versucht, das funktioniert aber nicht.
Zitat von: Jippy am 31 März 2024, 12:25:26Jetzt habe ich noch mal eine Frage...
Kann man die STATE Anzeige "Connected to /org/asamk/Signal/_49xxxxxxxxx" durch ein Icon ersetzen?
Ich habe es mit dem Attribut devStateIcon "Connected.to./org/asamk/Signal/_49xxxxxxxxx: 10px-kreis-gruen" bzw. "Connected.*: 10px-kreis-gruen" versucht, das funktioniert aber nicht.
Das geht dann so:
Connected.to..org.asamk.Signal._XXXXXXX:10px-kreis-gruen
Wie wärs damit:
attr SignalBot devStateIcon { my $status_img = "10px-kreis-gruen";;;; my $status_txt = ReadingsVal($name, "state", "disconnected");;;; if (!$status_txt =~ /Connected.*/) { $status_img = "10px-kreis-rot";;;;} my $restart_icon = "<a href=\"/fhem?cmd.dummy=set $name reinit&XHR=1\" title=\"Reinit\">".FW_makeImage("control_reboot")."</a>";;;; "<div> <a>".FW_makeImage($status_img, $status_txt)."</a> ".$restart_icon." ".$status_txt."</div>" }
Hallo Adimarantis
Zitat von: Adimarantis am 01 April 2024, 12:50:49Wie wärs damit:
attr SignalBot devStateIcon { my $status_img = "10px-kreis-gruen";;;; my $status_txt = ReadingsVal($name, "state", "disconnected");;;; if (!$status_txt =~ /Connected.*/) { $status_img = "10px-kreis-rot";;;;} my $restart_icon = "<a href=\"/fhem?cmd.dummy=set $name reinit&XHR=1\" title=\"Reinit\">".FW_makeImage("control_reboot")."</a>";;;; "<div> <a>".FW_makeImage($status_img, $status_txt)."</a> ".$restart_icon." ".$status_txt."</div>" }
Ich glaube das kannste auch als Standard reinsetzen, sofern Attribut nicht gesetzt.
Gruss
Sailor
Hallo alle zusammen,
ich moechte mit Signal einen http link verschicken, also sowas wie
<a href=/opt/fhem/www/Pics/bild.jpg>BILD</a> , so das ich in der Signal message nur den link "BILD" angezeigt bekomme. Leider funktioniert das nicht, ich bekomme mit set Signal send Bitte auf BILD klicken <a href=/opt/fhem/www/Pics/bild.jpg>BILD</a> nur den Textstring angezeigt. Im Wiki finde ich unter den formatierungen auch nichts. Kann jemand helfen, oder geht das nicht?
Hallo Jamo
Zitat von: Jamo am 08 April 2024, 13:21:53Hallo alle zusammen,
ich moechte mit Signal einen http link verschicken,
Leider funktioniert das nicht
Der SignalBot kann nur versenden was du auch auf dem Handy erstellen könntest.
Wenn du es auf dem Handy kannst, sende es an deinen fhem - SignalBot und schau dir den empfangenen Code an.
Gruß
Sailor
Hi Adimaratis
Wie kann ich den Standard - Pfad für empfangene Bilder von "/var/lib/signal-cli/attachments/" auf "/home/pi/Pictures" oder ein anderes ändern?
Kann man das ggf mit einem Attribut lösen?
Gruß
Sailor
@Jamo: Ich frage mich was jetzt eigentlich der Anwendungfall ist.
Wenn man einen http link verschickt, der einen absoluten lokalen Pfad enthält, dann kann man den auf den Handy sowieso nicht lesen - die Datei ist ja auf den Handy gar nicht vorhanden.
Bilder kann man aber mit Signalbot sehr wohl verschicken, einfach mit
set Signalbot send @handy Bild: &/opt/fhem/www/Pics/bild.jpgWarum dann einen http link?
Was übrigens grundsätzlich einwandfrei funktioniert:
set Signalbot send @handy http://google.de
@Sailor:
Ich weiss jetzt nicht auf Anhieb ob man nur das attachment Verzeichnis verlegen kann. Ich glaube das ist eine Einheit mit der restlichen Konfiguration.
Du kannst es dir doch aber einfach "herbeilinken"
ln -s /var/lib/signal-cli/attachments/ pictures
Zitat von: Adimarantis am 08 April 2024, 16:09:56@Jamo: Ich frage mich was jetzt eigentlich der Anwendungfall ist.
Wenn man einen http link verschickt, der einen absoluten lokalen Pfad enthält, dann kann man den auf den Handy sowieso nicht lesen - die Datei ist ja auf den Handy gar nicht vorhanden.
Bilder kann man aber mit Signalbot sehr wohl verschicken, einfach mit
set Signalbot send @handy Bild: &/opt/fhem/www/Pics/bild.jpgWarum dann einen http link?
Was übrigens grundsätzlich einwandfrei funktioniert:
set Signalbot send @handy http://google.de
Hallo Adimarantis,
erstmal danke, und ja da habe ich Dich in die Irre geführt, es ist ein Link auf eine externe Webseite, sowas wie https://www.microsoft.com/de-de/berlin/veranstaltungen/fast-forward-ai/renderingassets/og-image.jpg, das sieht einfach haesslich aus weil so lang. Schoener waere es wenn es wie bei HTML einen kurzschreibweise geben würde, wo dann der eigentliche Link dahinter liegt.
Beste Grüsse, Jamo
Hallo Jamo
Zitat von: Jamo am 08 April 2024, 21:26:13erstmal danke, und ja da habe ich Dich in die Irre geführt, es ist ein Link auf eine externe Webseite, sowas wie https://www.microsoft.com/de-de/berlin/veranstaltungen/fast-forward-ai/renderingassets/og-image.jpg, das sieht einfach haesslich aus weil so lang. Schoener waere es wenn es wie bei HTML einen kurzschreibweise geben würde, wo dann der eigentliche Link dahinter liegt.
Ich bezweifle, dass die Signal-APP aus Sicherheits-Aspekten heraus die Darstellung von <html> zulassen wird.
Es ist ja ein Messenger und kein Browser.
Ansonsten gibt es doch die Möglichkeit Kurzlinks zu erstellen wie beispielsweise mit "https://t1p.de/".
(Disclaimer: Ich habe keine Kenntnisse hinsichtlich der Seriosität der genannten website)
Gruß
Sailor
Man könnte sich vorstellen, dass Signalbot auf ein &http://somesite.com/bild.jpg so reagiert, dass er eine lokale Kopie des Bildes zieht und dieses dann per Signal verschickt.
Da sind wir halt dann wieder bei den Sicherheitsaspekten. Will man wirklich, dass eine Datei "irgendwo" aus dem Internet auf die lokale Platte kopiert wird und dann verschickt wird.
Zitat von: Adimarantis am 09 April 2024, 09:38:24Da sind wir halt dann wieder bei den Sicherheitsaspekten.
Will man wirklich, dass eine Datei "irgendwo" aus dem Internet auf die lokale Platte kopiert wird und dann verschickt wird?
Lieber nicht!
Wenn, dann soll der User sich Gedanken machen, was heruntergeladen wird und dann anschließend von seinem Rechner aus das Bild versenden oder den Link, welcher dann beim Empfänger in den Browser geschoben wird.
Gruss
Sailor
Hallo zusammen!
Erstmal danke für das tolle Modul, läuft bei mir einwandfrei.
Jetzt bin ich dabei, einige automatisierte Nachrichten zu verschicken, habe aber ein (Luxus-)Problem bei der Formatierung.
Normalen Text in Festbreitenschrift ist kein Problem mit <code/>.
Wenn ich jedoch dazwischen berechnete Werte habe, dann greifen diese Tags nicht, wie hier zb:
$message = $message . "<code>" . sprintf("%02d", $j) . "" . ":00 - " . sprintf("%02d", $j + 1) . ":00 --> " . sprintf("%.2f", @values[$j]) . " ct/kWh </code>" . "<br>";
Wennn ich diesen ganzen Pack sende, wird nur der letzte Textteil (ct/kWh) formatiert. <tt> und Markdown-Style habe ich auch schon versucht -> selbes Problem.
Hat hier jemand einen Tipp für mich?
Liebe Grüße!
Simon
Kann ich bei manuell fabrizierten Beispielen nicht nachstellen.
Kannst das fertige $message mal irgendwo ausgeben oder verbose von Signalbot hochstellen und posten wie das aussieht?
Aber sicher doch. Hier das Log, die message ist ohnehin enthalten:
2024.04.17 17:29:46 1: message: <tt>Heutige Strompreise:</tt> <br><code>00:00 - 01:00 11.84 ct/kWh </code><br><code>01:00 - 02:00 14.81 ct/kWh </code><br><code>02:00 - 03:00 19.86 ct/kWh </code><br><code>03:00 - 04:00 20.68 ct/kWh </code><br><code>04:00 - 05:00 17.25 ct/kWh </code><br><code>05:00 - 06:00 13.04 ct/kWh </code><br><code>06:00 - 07:00 11.95 ct/kWh </code><br><code>07:00 - 08:00 13.10 ct/kWh </code><br><code>08:00 - 09:00 12.05 ct/kWh </code><br><code>09:00 - 10:00 11.64 ct/kWh </code><br><code>10:00 - 11:00 11.25 ct/kWh </code><br><code>11:00 - 12:00 11.99 ct/kWh </code><br><code>12:00 - 13:00 12.12 ct/kWh </code><br><code>13:00 - 14:00 16.44 ct/kWh </code><br><code>14:00 - 15:00 21.00 ct/kWh </code><br><code>15:00 - 16:00 18.02 ct/kWh </code><br><code>16:00 - 17:00 14.30 ct/kWh </code><br><code>17:00 - 18:00 12.40 ct/kWh </code><br><code>18:00 - 19:00 11.47 ct/kWh </code><br><code>19:00 - 20:00 11.05 ct/kWh </code><br><code>20:00 - 21:00 10.78 ct/kWh </code><br><code>21:00 - 22:00 10.23 ct/kWh </code><br><code>22:00 - 23:00 10.16 ct/kWh </code><br><code>23:00 - 24:00 10.52 ct/kWh </code><br>
2024.04.17 17:29:46 3: Signal: Before parse:#Smarthome <tt>Heutige Strompreise:</tt> <br><code>00:00 - 01:00 11.84 ct/kWh </code><br><code>01:00 - 02:00 14.81 ct/kWh </code><br><code>02:00 - 03:00 19.86 ct/kWh </code><br><code>03:00 - 04:00 20.68 ct/kWh </code><br><code>04:00 - 05:00 17.25 ct/kWh </code><br><code>05:00 - 06:00 13.04 ct/kWh </code><br><code>06:00 - 07:00 11.95 ct/kWh </code><br><code>07:00 - 08:00 13.10 ct/kWh </code><br><code>08:00 - 09:00 12.05 ct/kWh </code><br><code>09:00 - 10:00 11.64 ct/kWh </code><br><code>10:00 - 11:00 11.25 ct/kWh </code><br><code>11:00 - 12:00 11.99 ct/kWh </code><br><code>12:00 - 13:00 12.12 ct/kWh </code><br><code>13:00 - 14:00 16.44 ct/kWh </code><br><code>14:00 - 15:00 21.00 ct/kWh </code><br><code>15:00 - 16:00 18.02 ct/kWh </code><br><code>16:00 - 17:00 14.30 ct/kWh </code><br><code>17:00 - 18:00 12.40 ct/kWh </code><br><code>18:00 - 19:00 11.47 ct/kWh </code><br><code>19:00 - 20:00 11.05 ct/kWh </code><br><code>20:00 - 21:00 10.78 ct/kWh </code><br><code>21:00 - 22:00 10.23 ct/kWh </code><br><code>22:00 - 23:00 10.16 ct/kWh </code><br><code>23:00 - 24:00 10.52 ct/kWh </code><br>:
2024.04.17 17:29:46 4: Signal: sendGroupMessage called for Smarthome::𝙷𝚎𝚞𝚝𝚒𝚐𝚎 𝚂𝚝𝚛𝚘𝚖𝚙𝚛𝚎𝚒𝚜𝚎:
00:00 - 01:00 11.84 𝚌𝚝/𝚔𝚆𝚑
01:00 - 02:00 14.81 𝚌𝚝/𝚔𝚆𝚑
02:00 - 03:00 19.86 𝚌𝚝/𝚔𝚆𝚑
03:00 - 04:00 20.68 𝚌𝚝/𝚔𝚆𝚑
04:00 - 05:00 17.25 𝚌𝚝/𝚔𝚆𝚑
05:00 - 06:00 13.04 𝚌𝚝/𝚔𝚆𝚑
06:00 - 07:00 11.95 𝚌𝚝/𝚔𝚆𝚑
07:00 - 08:00 13.10 𝚌𝚝/𝚔𝚆𝚑
08:00 - 09:00 12.05 𝚌𝚝/𝚔𝚆𝚑
09:00 - 10:00 11.64 𝚌𝚝/𝚔𝚆𝚑
10:00 - 11:00 11.25 𝚌𝚝/𝚔𝚆𝚑
11:00 - 12:00 11.99 𝚌𝚝/𝚔𝚆𝚑
12:00 - 13:00 12.12 𝚌𝚝/𝚔𝚆𝚑
13:00 - 14:00 16.44 𝚌𝚝/𝚔𝚆𝚑
14:00 - 15:00 21.00 𝚌𝚝/𝚔𝚆𝚑
15:00 - 16:00 18.02 𝚌𝚝/𝚔𝚆𝚑
16:00 - 17:00 14.30 𝚌𝚝/𝚔𝚆𝚑
17:00 - 18:00 12.40 𝚌𝚝/𝚔𝚆𝚑
18:00 - 19:00 11.47 𝚌𝚝/𝚔𝚆𝚑
19:00 - 20:00 11.05 𝚌𝚝/𝚔𝚆𝚑
20:00 - 21:00 10.78 𝚌𝚝/𝚔𝚆𝚑
21:00 - 22:00 10.23 𝚌𝚝/𝚔𝚆𝚑
22:00 - 23:00 10.16 𝚌𝚝/𝚔𝚆𝚑
23:00 - 24:00 10.52 𝚌𝚝/𝚔𝚆𝚑
2024.04.17 17:29:46 5: Signal: getGroup Smarthome
2024.04.17 17:29:46 5: Signal: Dbus Call sync:0 sendGroupMessage(sasay) /org/asamk/Signal/_4367xxxxxxxxx Args:𝙷𝚎𝚞𝚝𝚒𝚐𝚎 𝚂𝚝𝚛𝚘𝚖𝚙𝚛𝚎𝚒𝚜𝚎:
00:00 - 01:00 11.84 𝚌𝚝/𝚔𝚆𝚑
01:00 - 02:00 14.81 𝚌𝚝/𝚔𝚆𝚑
02:00 - 03:00 19.86 𝚌𝚝/𝚔𝚆𝚑
03:00 - 04:00 20.68 𝚌𝚝/𝚔𝚆𝚑
04:00 - 05:00 17.25 𝚌𝚝/𝚔𝚆𝚑
05:00 - 06:00 13.04 𝚌𝚝/𝚔𝚆𝚑
06:00 - 07:00 11.95 𝚌𝚝/𝚔𝚆𝚑
07:00 - 08:00 13.10 𝚌𝚝/𝚔𝚆𝚑
08:00 - 09:00 12.05 𝚌𝚝/𝚔𝚆𝚑
09:00 - 10:00 11.64 𝚌𝚝/𝚔𝚆𝚑
10:00 - 11:00 11.25 𝚌𝚝/𝚔𝚆𝚑
11:00 - 12:00 11.99 𝚌𝚝/𝚔𝚆𝚑
12:00 - 13:00 12.12 𝚌𝚝/𝚔𝚆𝚑
13:00 - 14:00 16.44 𝚌𝚝/𝚔𝚆𝚑
14:00 - 15:00 21.00 𝚌𝚝/𝚔𝚆𝚑
15:00 - 16:00 18.02 𝚌𝚝/𝚔𝚆𝚑
16:00 - 17:00 14.30 𝚌𝚝/𝚔𝚆𝚑
17:00 - 18:00 12.40 𝚌𝚝/𝚔𝚆𝚑
18:00 - 19:00 11.47 𝚌𝚝/𝚔𝚆𝚑
19:00 - 20:00 11.05 𝚌𝚝/𝚔𝚆𝚑
20:00 - 21:00 10.78 𝚌𝚝/𝚔𝚆𝚑
21:00 - 22:00 10.23 𝚌𝚝/𝚔𝚆𝚑
22:00 - 23:00 10.16 𝚌𝚝/𝚔𝚆𝚑
23:00 - 24:00 10.52 𝚌𝚝/𝚔𝚆𝚑
,ARRAY(0x616e768),ARRAY(0x6148aa0)
2024.04.17 17:29:47 5: Signal: DBus callback: sendGroupMessage Args:1713367786990
2024.04.17 17:29:49 5: Signal: Sync Callback: ReceiptReceived Args:1713367786990,+4367xxxxxxxx
2024.04.17 17:29:49 5: Signal: Signalbot_receive_callback 1713367786990 +4367xxxxxxxx
Und letztendlich geht es darum das die Zahlen nicht so richtig in monospace dargestellt werden?
Das liegt daran, dass ich wohl damals für die meisten Zahlen im Unicode nicht die richtigen Seiten gefunden habe.
Nach etwas Recherche finde ich für monospace Zahlen bei 0x1d7f6
Hab ein Update für Unicode.pm in svn eingecheckt.
Hi!
Vielen Dank für Deine Unterstützung.
Ich habe die Änderung (manuell) durchgeführt. Sollte ein 'update all' oder 'update Unicode.pm' nicht die Änderungen ziehen?
Auf jeden Fall funktioniert es jetzt wie erwartet, vielen Dank nochmal!
Schöne Grüße!
Simon