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

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

Vorheriges Thema - Nächstes Thema

fredje

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.

frober

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.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

fredje


FhemPiUser

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) 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?

Adimarantis

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

FhemPiUser

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?

Adimarantis

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)


FhemPiUser

Macht es Sinn das java17-Thema mit in den FAQ im Wiki aufzunehmen, damit der nächste nicht drüber stolpert?

Adimarantis

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

Mad-at

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

Adimarantis

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Mad-at

Danke, das war ja schnell!
FHEM läuft als Dienst auf einem ganz normalen Raspbian Buster...

Jamo

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.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Adimarantis

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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)