Neues Modul: 70_Jabber.pm

Begonnen von BioS, 18 Januar 2014, 11:51:20

Vorheriges Thema - Nächstes Thema

Nobody0815

#300
Zitat von: dora71 am 01 März 2022, 16:19:17

Hier die Liste:

  • Modul auf non-blocking umbauen (falls der XMPP-Server nicht erreichbar ist)
  • Integration des disable Attributs
  • OMEMO-Verschlüsselung integrieren
  • Abhängigkeit von alten Paketen entfernen / aktualisieren
  • Möglichkeit der Übermittlung von Dateien, vornehmlich Bilder
Grüße vom Rhein
Rainer
Ich schließe mich dem Dank an und würde mich auch sehr darüber freuen oder gibt es eine alternative wie Matrix?
Wäre toll - Danke!

Gruß
Andre

Edit:
Signal ist für mich eine alternative - wenn auch nicht perfekt (Matrix oder Jabber wären meine Favoriten) aber brauchbar und ich werde es versuchen.
https://wiki.fhem.de/wiki/Signalbot

Christian.

#301
Aktuell ist jabber.de wegen eines DDoS-Angriffs nicht erreichbar. Das Modul blockiert deshalb wieder die gesamte FHEM-Installation, wie bereits in den Jahren 2021 und 2018 gemeldet.

Man kann das Jabber-Modul leider nicht deaktivieren oder inaktiv schalten. Als Workaround hat bei mir nur geholfen, das Jabber-Modul mittels delete zu entfernen.

Aus meiner Sicht ist es problematisch, dass das Modul blockierend programmiert ist. Hat das Modul keinen aktiven Maintainer? Ich finde es ausgesprochen unglücklich, dass eine FHEM-Installation durch externe Faktoren derart beeinträchtigt werden kann.

Es wäre aus meiner Sicht sinnvoll, wenn das Modul asynchron - also nicht-blockierend - arbeiten würde, um bei solchen unvermeidbaren Ausfällen nicht die gesamte FHEM-Instanz zu blockieren. Es wäre auch hilfreich, wenn man den Verbindungsaufbau über einen Schalter temporär deaktivieren könnte, ohne das Modul entfernen zu müssen.

Edit: Zur Diagnose habe ich die Datei jabberdebug.log angehängt. Auch wenn im Modul das Attribut verbose = 5 gesetzt ist, enthält das FHEM-Log keine anderen Einträge als
2022.08.30 07:15:55 1: Perfmon: possible freeze starting at 07:15:45, delay is 10.091
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee

mdosch

#302
Ich habe mir mein eigenes tool go-sendxmpp geschrieben, das ich für diverse Benachrichtigungen nutze u.a. auch für FHEM: https://forum.fhem.de/index.php?topic=93892.0

Ich habe mir ein kleines wrapperscript geschrieben, das ich von FHEM aufrufe und das wartet bis der server erreichbar ist und dann die Nachricht raus schickt. Soweit ich das beurteilen kann blockiert der Scriptaufruf FHEM nicht, zumindest ist mir da nichts aufgefallen.

Mein wrapperscript sieht so aus:

#! /bin/bash

CONNECTIVITY=false

if nc -zw1 mdosch.de 5222
then
        CONNECTIVITY=true
fi

while  [ $CONNECTIVITY == false ]
do
        sleep 60
        if nc -zw1 mdosch.de 5222
        then
                CONNECTIVITY=true
        fi
done

echo "$@" | go-sendxmpp EMPFÄNGER1 EMPFÄNGER2


mdosch.de und 5222 müssen natürlich durch den verwendeten server und port ausgetauscht werden.

Nachtrag:
Go-sendxmpp kann auch Bilder verschicken (flag --http-upload). OMEMO kann es leider nicht, das ist mir zu kompliziert als dass ich das einbauen würde. Das würde ich nur verhunzen. Go-sendxmpp kann aber die neue PGP-Verschlüsselung (Ox), die leider noch nicht ganz fertig ist (noch keine Ünterstützung für Dateitransfers und Gruppenchats) und bisher nur von wenigen clients unterstützt wird (profanity und Gajim).

dickdickerson

Mein Internet funktioniert aktuell nicht und da ist mir wieder mal die Abhängigkeit aufgefallen, die ich bisher nicht auflösen konnte.
Ursache für das Blocking des kompletten FHEM ist bei mir auch das jabber-Modul. Rausgefunden habe ich es mit apptime, das ich bis eben noch nicht kannte.
Anstatt das device aber komplett zu löschen, habe ich als Workaround folgendes gesetzt:

attr xmpp PollTimer 999999999999999

Das funktioniert bisher.

Ggf. lässt sich das auch mit einem Ping-Check nach Extern automatisieren, sofern der nicht auch blockt ;-)

dora71

Hallo zusammen und allen hier im Forum ein gutes neues Jahr 2023.

Ich gebe das Jabber Modul immer noch nicht auf, da es eigentlich alle Funktionen enthält, die ich brauche.

Hauptmanko ist ja das blockierende Verhalten des Moduls.

Interessanterweise habe ich festgestellt, dass im Jabber Modul zumindest das Blocking Modul (was ja blocking verhindern soll) geladen wird, weshalb es im Wiki auch unter den Modulen gelistet ist, s. https://wiki.fhem.de/wiki/Blocking_Call#Module.2C_die_Blocking.pm_verwenden

Allerdings habe ich nirgendwo einen BlockingCall() Aufruf im Modul gefunden  :o oder habe ich etwas übersehen?

Wenn man sich dieses Modul anschaut, würde es dann (im ersten Schritt) reichen, die Funktion Jabber_CheckConnection($) mit einem BlockingCall() zu versehen?

Sehr gerne würde ich helfen, diesen Zustand zu beseitigen, habe aber sehr begrenzte Ahnung von Perl und/oder dem BlockingCall.

Bin aber gerne bereit, helfend mit dabei zu sein, falls sich mindestens noch ein "Jemand" findet, dem es genauso am Herzen liegt wie mir.

Würde mich freuen, wenn das hier ein erster (oder weiterer) Anstoß für eine Weiterentwicklung des Moduls ist.

Neujahrsgrüße

Rainer

Joesky

Ist das Modul tot? Lohnt es sich nicht es zu installieren?
_______________
FREI STATT BAYERN

dora71

Zitat von: Joesky am 14 Februar 2024, 15:30:28Ist das Modul tot?
Es wird zumindest nicht mehr aktiv weiterentwickelt  :(
Ich habe es aber immer noch in Nutzung und bin auch soweit zufrieden damit. Solange Dein XMPP Server stabil läuft, gibt es auch kein Problem mit dem Modul.
Es gibt noch andere Möglichkeiten, falls es nur um die Übermittlung von Nachrichten via XMPP/Jabber geht.
Zum Beispiel ein Shell-Script aufrufen, welches go-sendxmpp aufruft.

Allerdings kann das Modul ja auch auf ankommende Nachrichten reagieren.

Sich das Modul anzuschauen lohnt sich auf jeden Fall.

Joesky

Ich hab das Modul gestern ausprobiert: Die Versionen der Bibliotheken ist höher als im Wiki angegeben und das FHEM startet (deswegen?) öfter von selbst neu durch. Und auch wenn mein XMPP Server stabil läuft, ist das mögliche blockieren der FHEM Instanz ein no go. Schade.
_______________
FREI STATT BAYERN

Christian.

#308
In jüngster Vergangenheit ist es erneut öfter vorgekommen, dass die blockierenden Aufrufe des Jabber-Moduls die gesamte FHEM-Instanz unbrauchbar gemacht haben. Bei Ausfall des Jabber-Servers meldet perfmon Freezes von zunächst 10 Sekunden, im Laufe der Zeit bis zu 120 Sekunden. Irgendwann ist FHEM dann nicht mehr ansprechbar und muss von außen neu gestartet werden.

Ein Wechsel des Jabber-Servers hat das Problem in der Praxis leider nicht gelöst, weil auch der neue Server hin und wieder ausfällt. Im Gegenteil, nach dem Server-Wechsel tritt zusätzlich ein File-Leak auf, das sich mit folgendem Kommando überwachen lässt:
netstat -ap 2>/dev/null | grep xmpp.*CLOSE_WAIT | wc -l | tr -d "\n"
Das Kommando liefert die Anzahl der offenen Jabber-Handles. Im Laufe eines Monats schaukeln die sich bis ~1000 hoch, bis die FHEM-Instanz nicht mehr reagiert. Dieses Problem lässt sich nur durch einen regelmäßigen und rechtzeitigen Neustart von FHEM im Griff behalten.

Wegen dieser Probleme habe ich mich trotz des Umstellungsaufwandes für einen Wechsel des Moduls entschieden. Ich versende und empfange jetzt alle Benachrichtigungen mittels MQTT über den Signal-Messenger mit Hilfe des Projektes signal-mqtt.

Danke an die Autoren des Jabber-Moduls, das mir jahrelang geholfen hat. Ohne aktiven Maintainer kann ich es wegen der beschriebenen Probleme aber nicht mehr empfehlen.
Raspberry Pi 3 mit FHEM; Arduino Nano mit ConfigurableFirmata (S0-Stromzähler); nanoCUL (MAX!); SIGNALduino (RXB6, 433 MHz); eBus; RS485 & D0 (SolarView); DVB-T (Thermo-/Hygrometer); Z-Wave; ZigBee