Neues Modul für "(Si)gnal - (Si)cherer Messenger" [32_SiSi.pm]

Begonnen von Quantum, 26 Februar 2018, 14:32:42

Vorheriges Thema - Nächstes Thema

nOerkH

so es läuft jetzt erstmal wieder (auch mit normaler Reaktionszeit)

scheinbar muss man seinen "Kontakten" nach einer neuen Registrierung der Nummer wieder vertrauen?

sudo -u fhem signal-cli -u +43xxxxxxxx listIdentities
gab folgenden Output:
+43yyyyyyyy: TRUSTED_UNVERIFIED Added: Fri Jun 21 23:04:17 CEST 2019 Fingerprint: *hex-value*  Safety Number: *hex-value*
+43zzzzzzzzz: TRUSTED_UNVERIFIED Added: Sat Jun 22 14:01:05 CEST 2019 Fingerprint: *hex-value*  Safety Number: *hex-value*


anschließend habe ich beiden Einträgen mit
sudo -u fhem signal-cli -u +43xxxxxxxx trust -v "*hex-value*" +43yyyyyyyy

wieder vertraut, jetzt läuft es wieder, ich berichte in ein paar Tagen.

Danke jedenfalls für die Rückmeldung

obi

Hallo,
ich habe folgendes Problem mit signal-cli.
Nach einer gewissen Laufzeit hat der Signal Prozess 100% CPU Auslastung auf einem Debian System. Starte ich den Server neu ist wieder alles OK. Senden und Empfangen funktioniert zu diesem Zeitpunkt.
Hat jemand auch so was beobachtet?

Quantum

Hallo obi,

welcher Prozess verursacht die 100% Auslastung? "Signal_tx" ist der Prozess, den das SiSi-Modul erzeugt um im Hintegrund arbeiten zu können. Oder ist es ein signal-cli Prozess ?
Dieser nennt sich aber zumeist "java"

Läuft deine FHEM Instanz in dieser Zeit stabil, oder stürzt sie ab und an unkontrolliert ab (Mit automatischem neustart durch einen Watchdog) ? Gibt es mehr als nur einen Signal_tx Prozess nach einiger Zeit ?

Freundliche Grüße
Quantum

obi

#123
Hallo Quantum,
seit lägerem hatte ich nun wieder das Problem.
Des gibt den Signal_tx Prozess mehrmals mit insgesamt 100% CPU Auslastung (siehe Screenshot).
Ich habe eine Watchdog eingerichtet. Dieser wird aber nicht aktiv. Fhem an sich läuft ohne abzustürzen. Nur mit entsprechendem Delay, da die CPU ausgelastet ist.
In den Log-Dateien usw. ist nichts zu finden. Die Funktionalität ist auch gegeben.
Irgendeinen Zusammenhang welcher zu dem Problem führt läst sich nicht erkennen.
Wenn ich den Signal_tx Dienst kille hängt sich fhem auf. Nach einem neuen Start von Fhem ist alles wieder OK.

obi

Hallo,

ich hatte nun wieder mein Problem mit den mehrmals vorandenen Signal_tx Prozessen. Ich habe nun herausgefunden, dass Fhem durch meinen Watchdog neu gestartet wird (Ursache unklar, nichts im Log zu sehen). Dies führt dann dazu, dass Signal_tx entsprechend nochmal zusätzlich gestartet wird. Ich ändere nun mein Watchdog-Script, dass alle Signal Prozesse auch beendet werden. Dies sollte das Problem lösen.

@Quantum: Eventuell könntest du ja in dein Modul einbauen, dass beim Fhemstart/Modulstart noch vorhandene Prozesse beendet werden?

VG Obi

Hausautomat

Muss doch auch nochmal ein Danke loswerden. @Quantum + die Wiki-Schreiber: MERCI!

Läuft wunderbar, Einrichtung hat bei aufmerksamen Lesen einwandfrei geklappt. Klasse. :)

Nur eins:
Bei mir läuft signal-cli als Daemon auf'm Raspi unter dem Benutzer fhem, soweit alles gut.
Wenn ich nun auf der command line etwa eine Nummer verifizieren möchte, geht das mit signal-cli nicht, da der daemon die config-datei blockiert.
Also erstmal als root "systemctl stop signal.service", dann als fhem das signal-cli Kommando absetzen und jetzt nicht vergessen, mit "systemctl start signal.service" als root den Daemon wieder starten.

Hausautomat

Zwei Anmerkungen noch:

1. Eher meiner Dusseligkeit zuzuschreiben, trotzdem, falls es jemand gebrauchen kann. Mein Raspi hatte standardmäßig IPv6 aktiviert, im Heimnetz ist es jedoch noch nicht aktiviert. Das führt bei den RR-Servern von signal.org dazu, dass erratisch die Verbindung per IPv6 versucht wird - und scheitert. Ein

echo "1" > /proc/sys/net/ipv6/conf/all/disable_ipv6

hilft.
Zu erkennen ist es daran, dass an der Fehlermeldung "java.net.ConnectException: Failed to connect to cdn.signal.org/2600:9000:21f3:1200:1d:4f32:50c0:93a1:443" (IPv6)

2. Folgenden Fehler / Warnung finde ich im syslog (nicht fhem-log):

Dec 25 19:51:55 fhempi signal-cli[3010]: Dec 25, 2019 7:51:55 PM okhttp3.internal.platform.Platform log
Dec 25 19:51:55 fhempi signal-cli[3010]: WARNING: A connection to https://cdn.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);


Nach erster kurzer Recherche sieht es mir eher nach einem Problem in der signal-cli Implementation aus, als dem Modul. Das Modul spricht ja nur via dbus mit dem signal-cli daemon. Ist das sonst schon jemandem aufgefallen?

enno

Moin,

ich nutze Signal jetzt schon seit einem Jahr ohne große Probleme. Was aber noch nicht gut klappt, sind senden von mehreren Nachrichten innerhalb einer Minute. Wenn ich die erste Nachricht schicke, ist Signal etwa. 40-50 Sek blockiert. Wenn ich innerhalb dieser Zeit eine weitere Nachricht senden möchte, wird diese verschluckt und im log erscheint eine Fehlermeldung, dass Signal erst gestartet werden muss.

Hat das Problem noch jemand? Wenn ja, gibt es einen einfachen Workaround.

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

darkness

#128
Hey,

habe es gerade mal getestet. Ich kann Nachrichten direkt hintereinander senden (benutzte dazu noch das msg-modul, also msg @Empänger). Klappt ohne Probleme.

Gruß

Internals:
   FD         208
   FUUID      5c52a6d2-f33f-ed18-53c4-7410e57cac717dc0
   NAME       SignalCLI
   NR         715
   NTFY_ORDER 50-SignalCLI
   OBJECT     /org/asamk/Signal
   PID        8893
   SERVICE    org.asamk.Signal
   STATE      Connected
   TYPE       SiSi
   VERSION    1.1.1
   sentMsgRecipient +49
   sentMsgResult SUCCESS
   sentMsgText test
   READINGS:
     2019-12-26 02:00:44   msgAttachment   NONE
     2019-12-26 02:00:44   msgGroupId      NONE
     2019-12-26 02:00:44   msgGroupName    NONE
     2019-12-26 02:00:44   msgSender       +49
     2019-12-26 02:00:44   msgText         Bild
     2019-12-26 02:00:44   msgTimestamp    2019-12-26 02:00:47
     2019-12-26 02:00:44   prevMsgAttachment NONE
     2019-12-26 02:00:44   prevMsgGroupId  NONE
     2019-12-26 02:00:44   prevMsgGroupName NONE
     2019-12-26 02:00:44   prevMsgSender   +49
     2019-12-26 02:00:44   prevMsgText     TEXT
     2019-12-26 02:00:44   prevMsgTimestamp 2019-12-19 16:24:17
Attributes:
   enable     yes
   room       develop

drhirn

Hier auch. Drei Nachrichten direkt hintereinander (so schnell ich halt tippen konnte ;) ). Kamen alle anstandslos in Sekundenbruchteilen an.

Hugendubel01

Guten Tag Zusammen,

ich habe die Installationsanleitung abgearbeitet. Es klapt alles bis zu dem Punkt "Anschließend wird noch die lokale CommandRef aktualisiert:"
Hier erhalte ich bei der Ausführung des Befehls mehrere Fehlermeldungen mit denen ich (Anfänger) nichts anfangen kann.
Vielleicht kann mir jemand von euch weiterhelfen?

pi@Pi4B-FHEM:/opt/fhem $ sudo /usr/bin/perl contrib/commandref_join.pl
*** EN SISPM line 543: div with attributes (apart from class) is not allowed
*** EN FHEM/70_SISPM.pm: Unbalanced div (1, last line ok: 542)
*** EN FHEM/73_UpsPico.pm: negative tagcount for td, line 1189
*** EN FHEM/73_UpsPico.pm: negative tagcount for tr, line 1190
*** EN WifiLight line 3975: table with attributes (apart from class) is not allowed
*** EN FHEM/32_WifiLight.pm: Unbalanced table (1, last line ok: 3974)
*** DE FHEM/73_UpsPico.pm: negative tagcount for td, line 1369
*** DE FHEM/73_UpsPico.pm: negative tagcount for tr, line 1370
*** DE WifiLight line 4620: table with attributes (apart from class) is not allowed
*** DE FHEM/32_WifiLight.pm: Unbalanced table (1, last line ok: 4619)
pi@Pi4B-FHEM:/opt/fhem $

h002

Kann man über das Modul auch SVGs versenden?

So was wie
msg &{plotAsPng('SVG_dbLog_3')}
scheint nicht so funktionieren.

Danke :-)

enno

Einfacher FHEM Anwender auf Intel®NUC

h002

#133
Ich konnte es mit einer Sub lösen.


sub saveSVGToPNG(@){
my ($plotName) = @_;
open FILE, "> /opt/fhem/fhem_png_plots/$plotName.png";
binmode FILE;
print FILE plotAsPng($plotName);
close FILE;
fhem("msg \&/opt/fhem/fhem_png_plots/$plotName.png");
}


Aufruf der Sub mit dem jeweiligen SVG-Device

{saveSVGToPNG("SVG_dbLog_1")}


h002

Zitat von: enno am 15 September 2020, 19:49:52
Moin,

Ich habe das nur über den Umweg https://wiki.fhem.de/wiki/RSS geschafft.

Gruss
  Enno
Hast du hier das Bild ebenfalls zwischengespeichert oder die url wie z.B. http://fhem:8083/fhem/rss/rssFeed.png  versendet?