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

[Che007]

Hallo zusammen,

ich habe seit heute auch das Problem, dass ich Nachrichten senden kann, aber empfangen werden keine mehr.
Ich habe wie KeyleK mal auf Version 014.4.1 aktualisiert, aber das Empfangen geht leider weiterhin nicht.

EDIT:
lt github signal-cli in 0.14.5 gefixt.

Ja in der install-signal Datei auf 0.14.5 ändern, damit geht es!

[enno]

Moin,

ich hatte auch das Problem, dass nur Senden, aber kein Empfang ging. Ich habe wie im Script vermerkt auf den Seite die "latest Version" genommen.

Code Auswählen Erweitern

SIGNALVERSION="0.14.5"
#Check for latest valid version at https://github.com/AsamK/signal-cli/releases
LIBRARYVERSION="0.96.0"
#Check for latest valid version at https://github.com/exquo/signal-libs-build/releases
Dann das Script gestartet und alles lief wieder.

Gruss
  Enno

[Adimarantis]

Kann ich ebenfalls so nachvollziehen. Danke enno und Che007
Neues signal_install.sh für 0.14.5 ist eingecheckt

Gruß,
Jörg

[Flachzange]

Hallo Adimarantis,

ich bin jetzt seit Jahren Nutzer von signalbot und es stellt ein elementares Element meiner FHEM-Installation dar. Bisher hat es mich nicht sonderlich gestört, dass Umlaute, Sonderzeichen etc in den Readings falsch codiert dargestellt wurden. Es war vermeintlich kosmetisch, z.B.

Code Auswählen Erweitern

Wetter: Aktuell Dach: 17.1�C (gef�hlt: 17.1�C).
Das ist so lange kosmetisch wie die Nachricht keine "wide (unicode) characters" enthält. Durch ein paar Copy-&-Paste-Aktionen ist mir aber genau das passiert. Es wurden Unicode Wide Characters verschickt. Das funktionierte auch erstmal. Gleiches passiert übrigens, wenn man per Signal ein Emoji an FHEM schickt.

Jetzt passiert aber folgendes: Diese Wide Characters stehen nativ Unicode-codiert in den Readings von Signalbot, weil du das scheinbar vorher für das Verschicken über signal-cli so brauchst. Das scheint aber nicht den FHEM-Konventionen zu entsprechen, welches immer UTF-8-codierte readings erwartet. Entsprechend fällt configDB bei mir auf die Nase mit

Code Auswählen Erweitern

Wide character in subroutine entry at configDB.pm line 444.
2026.06.09 23:59:55 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=configDB;host=192.168.5.36;port=3306 at configDB.pm line 444
Das führt unmittelbar zu einem FHEM-Crash und Neustart und ist daher zu vermeiden

Randnotiz: Das passiert immer dann, wenn configDB WriteStatefile() aufruft.

Du kannst dir vorstellen, dass man bei der Fehlermeldung die berühmte Nadel im Heuhaufen sucht. Es hat mich somit eine Weile gebraucht bis ich herausgefunden habe, dass es nicht die Device-Definitionen mit den Wide-Characters sind, sondern die Readings von Signalbot, die nicht in UTF-8, sondern Unicode codiert sind. Hintergrund ist nämlich, dass configDB nicht nur die Device-Definitionen speichert, sondern natürlich auch die aktuellen Reading-Werte persistiert.

Bottom line: Mindestens die msg-Readings von Signalbot müssen UTF-8-codiert sein und nicht Unicode. Möglicher Lösungsvorschlag anbei. Ich habe das bei mir erfolgreich getestet und auch Unicode Wide Characters machen nun keine Probleme mehr. Netter Nebeneffekt: Die Codierungsfehler in den Readings sind auch behoben.

Gruß
Chris

[Adimarantis]

Schau ich mir mal bei Gelegenheit an.
Läuft dein FHEM unter unicode (global->encoding = unicode)?

Jörg

[Flachzange]

Läuft dein FHEM unter unicode (global->encoding = unicode)?

Nein, kein unicode gesetzt (was ja default wäre).

[Adimarantis]

Mein System läuft unter Unicode.
Habe aber keine ConfigDB
Wäre halt interessant ob die Probleme mit Unicode auch bestehen und ob dein Patch damit sauber funktioniert.

[Flachzange]

Wäre halt interessant ob die Probleme mit Unicode auch bestehen

Vermutlich würde es funktionieren, wenn es auf Unicode steht, aber das ist halt eben nicht Standard,

und ob dein Patch damit sauber funktioniert.
 

In diese Falle passiert das, was heute passiert: das Reading wird in Unicode geschrieben:

Code Auswählen Erweitern

return $value if $unicodeEncoding;
configDB braucht es für diesen Test eigentlich nicht. Wenn global unicode=unicode gesetzt ist, müsste configDB ja auch funktionieren. Das Problem ist hier die Mischung aus UTF-8 und Unicode.

[Adimarantis]

Ok. Auf den ersten Blick schaut der Patch vernünftig aus. Solche Umwandlungen habe ich ja schon an mehr Stellen ohne Garantie auf Vollständigkeit.
Probiere ich bei Gelegenheit aus und werde es wohl aufnehmen.

Danke.