Rainer's Blogseiten

Monocles Chat 2.x

2026-05-19T00:00:00+00:00

Auf meinem PeerTube (Technik)Kanal werden im Laufe der Zeit Kurzvideos mit Tipps zu Monocles Chat erscheinen. Diesen findet man unter https://clip.place/c/dora71_channel/videos</a> </blockquote>

Da die Entwicklung von Monocles Chat zur Zeit rasant voranschreitet, kann es passieren, dass die nachfolgenden Kniffe nicht mehr oder anders funktionieren </blockquote>

Fehler und Funktionswünsche werden zur Zeit hier gesammelt (Englisch), bitte klicken</a> </blockquote>

das Kontroll-Kästchen bei "Chat anschließend löschen" nach Auswahl von "Verlauf löschen" ist jetzt neu standardmäßig deaktiviert. Das ist von Vorteil, wenn man bestimmte Chats z. B. als Monitoring Feedback benutzt und ab und an mal aufräumen will, ohne den Chat zu zerstören</li>
Zitate können nicht verändert werden zum Schutz des Zitierten, Originalzitate sieht man an dem Namen des Zitierten</li>
wird auf eine Frage direkt darunter geantwortet, wird die Frage nicht zitiert</li>
ein Kurzvideo über die Besonderheiten von Zitaten bei Monocles Chat findet man hier: https://clip.place/w/9qSAkzA5norbabSGVh9bHF</a></li>
Das rote offene Schloss in der rechten oberen Ecke bei einem 1:1 Chat warnt vor einem unverschlüsselten Chat</li>
Sobald in einem Chat etwas geschrieben wurde, kann durch einen langen Druck auf die "Senden" Taste (die mit dem Pfeil) oder je nach Einstellung die Büroklammer-Taste die Nachricht später gesendet werden. Die Umsetzung erfolgt im Client, d. h. zum Sendezeitpunkt muss der Client online sein. Ansonsten erfolgt das Senden beim nächsten Onlinegehen des Clients.</li>
ebenso kann über dieses Kontextmenü auf WebXDC Anwendungen zugegriffen werden (Widget wählen)</li>
die Chatraumsuche erfolgt über "Bleistifticon" - "+" - "Channels entdecken". Hier ist die Suche eine globale Suche. Falls man in die Eigenschaften eines Gruppenchats geht, kann man hier unter dem Punkt "Space durchsuchen" andere öffentliche Gruppenchats finden, die auf dem gleichen Server liegen wie der Gruppenchat.</li>
Unter der Suche in den Kontakten sind "Tags" anklickbar und dienen als Filter (z. B. Channels zeigt nur Gruppenchats an)</li>
Tags kann man für jeden Kontakt (direkter Chat oder Gruppenchat) vergeben, auch mehrere sind möglich, Namen können beliebig vergeben werden</li>
In den "Einstellungen" unter "Benutzeroberfläche" kann man eine Seitenleiste aktivieren. Damit lässt sich der angezeigte Verlauf beeinflussen, auch sehr nützlich bei mehreren Accounts!</li>
Ein Wisch nach links archiviert einen Chat, dieses Verhalten kann im Einstellungsmenü aus- und eingeschaltet werden</li>
Reaktionen sendet man durch einen kurzen Klick auf eine Nachricht, dann kann man sie auswählen. Erscheinen direkt unter der Nachricht</li>
Sprachnachrichten können auf einen Klick auf die Zeit pausiert werden</li>
die ":" Funktion zum Aufruf von Stickern kann man deaktivieren</li>
der versteckte Speicher kann bei jedem Chat separat deaktiviert werden</li> </ul>

OMEMO Verschlüsselung

2026-05-19T00:00:00+00:00

Die zur Zeit gängigste Verschlüsselung bei XMPP ist OMEMO</a>, nachfolgend sollen ein paar Besonderheiten im Zusammenhang mit OMEMO aufgelistet werden

für jede XMPP Adresse (auch JID = Jabber ID genannt) wird ein OMEMO Schlüssel pro Gerät und pro Client erstellt, d. h. nutze ich die gleiche XMPP Adresse auf einem Smartphone einmal mit Monocles Chat und gleichzeitig mit Conversations, so habe ich für dieses Konto schon 2 OMEMO Schlüssel. Ebenso werden 2 unterschiedliche Schlüssel erstellt, wenn 2 Geräte mit einem Konto und z. B. Conversations benutzt wird</li>

das gleiche gilt, wenn ein schon bestehendes Konto auf einem neuen Gerät eingerichhtet wird, auch hier werden neue Schlüssel erstellt, es sei denn, man spielt ein Backup von einer vorhandenen Installation ein</li>

sollte man schon länger einen Client mit OMEMO benutzt haben und möchte jetzt auf einen anderen Client wechseln, so wird das zum Verlust der alten Nachrichten führen. Die Nachrichten sind zwar noch vorhanden, können aber wegen dem neuen Schlüssel nicht mehr decodiert werden. Abhilfe schafft hier nur die Mitnahme des alten Schlüssels mittels Backup und Restore. Dabei sollten aber niemals beide Clients gleichzeitig online sein.</li>

Nutzt man mehrere Geräte, so kann man auch seine eigenen Schlüssel verifizieren (meistens mit Hilfe eines QR-Codes). Einmal verifizierte Schlüssel werden auf die anderen Geräte übertragen (bei 3 und mehr Geräten)</li>

kommen neue Schlüssel hinzu, so müssen diese bei einem verschlüsselten Gruppenchat (MUC) erneut an die Gesprächspartner ausgeliefert werden. Hierzu sollten alle Gesprächspartner online sein, da die Schlüssel der Gesprächspartner online abgerufen werden</li> </ul>

XMPP Links

2026-05-19T00:00:00+00:00

XMPP Blog https://eversten.net</a></li>
XMPP Grundwissen und sehr neutrale Betrachtung von XMPP bei freie Messenger</a></li> </ul>

UnifiedPush via XMPP einrichten

2026-03-17T00:00:00+00:00

Einleitung</h3>
Um UnifiedPush</a> auf einem Endgerät wie Smartphone oder Tablet nutzen zu könnnen, muss ein sogenannter UnifiedPush Distributor (eine App, die die Nachrichten entgegennimmt und an die jeweiligen Client Apps ausliefert) installiert sein.
Unter Android gibt es die Möglichkeit, hierfür die (sowie schon vorhandenen) XMPP-Clients wie z. B. Conversations, Snikket oder Monocles Chat zu nutzen. Die Einrichtung ist unkompliziert und soll im Nachfolgenden beschrieben werden.
Es gibt insgesamt 4 Komponenten, die zum erfolgreichen Übermitteln und Anzeigen der UnifiedPush Nachrichten erforderlich sind:

die Quelle, wo die Nachricht erzeugt wird, diese kann man im Normalfall nicht ändern und wird hier nur zum besseren Verständnis aufgeführt.</li>
einen UnifiedPush Server, welcher zum ersten einen http Endpunkt für die Quelle bereitstellt und zum zweiten die Nachrichten an die verschiedenen Distributoren weiterverteilt. Da da in diesem Beispiel über XMPP erfolgen soll, kann so ein UnifiedPush Server als Modul eines Prosody-Servers</a> oder eines ejabberd Servers</a> bereitgestellt sein. Fragt im Zweifel bei Eurem XMPP Provider nach, ob er diesen Dienst anbietet.</li>
der UnifiedPush Distributor (= Verteiler) übernimmt auf dem jeweiligen Endgerät die Entgegennahme der Nachricht vom UnifiedPush Server und verteilt diese auf die Clients, wo sie dann verarbeitet (angezeigt) werden</li>
die Clients: UnifiedPush funktioniert z. B. zusammen mit DAVx5 (zum Synchronisieren von Terminen und Kontakten), mit FOSS Warn (Warnapp zur Anzeige von weltweiten Katastrohphen- oder Warnmeldungen), Fedilab (Client für Mastodon) und einigen mehr. Die Liste mit unterstützenden Apps findet ihr hier</a></li> </ol>
Aktivierung</h3>

Als erstes richtet Ihr Euch den Distributor ein. Bei den Android XMPP Clients findet Ihr das in den Einstellungen ziemlich unten unter dem Punkt "Unified Push Verteiler". Dort wählt Ihr als nächstes den Push-Server aus. WICHTIG: Das muss der Server sein, auf dem Euer XMPP-Konto liegt, über welches Ihr UnifiedPush Nachrichten empfangen wollt. Hier wird nur die XMPP-Domain akzeptiert, keine komplette http-Adresse. Danach unter dem Punkt XMPP-Konto Euer XMPP-Konto auswählen, welches Ihr für die Push-Nachrichten verwenden wollt. Ob ein separates Konto dafür sinnvoll ist, vermag ich an dieser Stelle nicht zu sagen.</li>
Jetzt folgen die Clients: In der Regel werden die Clients den eingerichteten Distributor selbstständig erkennen: Entweder wird dieser direkt benannt oder mit seiner "Kennung" (z. B. eu.siacs.conversations). Bei mehreren Distributoren ist der richtige auszuwählen.</li>
Fertig zum Empfang. Solltet Ihr nicht sicher sein, ob das jetzt auch funktioniert, gibt es noch eine Test-App von UnfiedPush. Diese nennt sich UP-App und kann zum Testen des Setups benutzt werden.</li> </ol>
Specials - good to know</h3>

Die Push Nachrichten werden auf ihrem Weg verschlüsselt</li>
Die HTTP Endpunkt Adresse des UnifiedPush Servers sieht in der Regel sehr kryptisch aus (z. B. https://xmpp-server.exmple.net/push/v3.local.LwEXbb4......). Diese ist z. B. in der UP-App sichtbar.</li>
Bei DAVx5 ist zuerst in den Einstellungen der letzte Punkt Integration - UnifiedPush auszuwählen. Dort wird der Distributor eingetragen. Danach klickt man weiter bis in die Eigenschaften eines Kalenders oder der Kontakte. Bei korrekter Einrichtung muss hier ein Eintrag "Push-Unterstützung: Server bietet Push-Unterstützung" zu finden sein. Falls nicht, einmal den roten Punkt "Liste aktualisieren" anwenden und nochmals in den Details dann kontrollieren.</li> </ol>
Viel Spaß beim Pushen!

Asterisk - Blindentelefon

2026-03-01T00:00:00+00:00

Ziel dieses Projektes war, eine Möglichkeit für seheingeschränkte oder blinde Menschen zu schaffen, eine beliebige Telefonnumer nur durch Ansage der Ziffern anrufen zu können. Wichtig war mir dabei die interne Sprachverarbeitung, was durch den Vosk Server auch umsetzbar war (bis auf den Initialbefehl "Alexa, schalte Telefon ein"). Um das Projekt zu realisieren, wurden die vorhandenen Möglichkeiten betrachtet und miteinander verknüpft. Benötigt werden:

1 Amazon Echo Gerät</li>
1 FHEM Server mit alexa-fhem Anbindung</li>
1 Vosk-Server zur Spracherkennung (im Docker Container)</li>
1 Asterisk Server zur Verwaltung der Telefonie</li>
1 Telefon, welches an Asterisk angebunden ist (bei mir ein analoges Telefon mit Fritzbox 7170)</li> </ul>

Nachfolgend einige Aspekte, die zu berücksichtigen sind. Eine komplette Lösung möchte ich hier nicht vorstellen, da diese individuell sehr unterschiedlich aussehen kann.

Der "Umweg" über Alexa (bzw. dem Amazon Echo Gerät) und FHEM wurde nur gewählt, um eine automatische Wahl initiieren zu können: Anhand des Befehls "Alexa, schalte Telefon ein" wird in FHEM ein Gerätedummy auf "ein" gestellt. Dieser Vorgang triggert ein notify, welches dann das AMI-Script aufruft, damit das Telefon klingelt und nach Abnahme des Höreres eine Verbindung zu der Spracherkennungs-"Durchwahl" herstellt. Wichtig ist im Endeffekt nur, dass das AMI-Script aufgerufen wird, egal wie</li>
Eine Direktwahl mit Hilfe der Fritzbox ist zwar möglich, aber erst nach 30 Sekunden Wartezeit, das war mir viel zu lang, erspart aber den Umweg über FHEM mit AMI-Script und Alexa</li>
der Vosk-Server für die Spracherkennung läuft bei mir auf einer separaten Maschine auf bare metal in einem Docker Container im gleichen Netzwerk wie der Asterisk Server. Dadurch bleibt der Asterisk-Server schön schlank und hat auch unter Last keinen großen Leidensdruck.</li>
Anfänglich habe ich das (selbst kompilierte) Modul vosk-asterisk genutzt. Das musste ich aber aufgeben, da es bei verschiedenen Eingangscodecs den Asterisk Server zum Absturz brachte</li>
aktuell zeichnet Asterisk die Sprache auf (mittels RECORD Befehl), danach überträgt ein AGI-Script (Python) die Datei zum Vosk Server und wandelt nach Rückmeldung die erhaltenen geschriebenen Zahlen in Ziffern um.</li>
Spracherkennung: Hier muss man wirklich ein wenig "rumspielen" uns den speziellen Anwendungsfall betrachten. Unterschiedliche Endgeräte als Eingabe haben sehr unterschiedliche Spracherkennungen zur Folge. Für meine Bedürfnisse funktioniert es gut. Eventuell kann der Asterisk AGC Befehl im Dialplan für mehr Kompatibilität mit verschiedenen Endgeräten sorgen, genauso wie die Anpassung des RECORD Befehls bezüglich Stilleerkennung und maximaler Aufzeichnungsdauer. Im Zweifel hilft auch eventuell eine Analyse der aufgenommenen Sprachdatei.</li> </ul>

Cheerlights 2.0

2025-12-29T00:00:00+00:00

Es ist nun schon einige Jahre her, dass ich mir das letzte Mal das CheerLights Projekt unter https://cheerlights.com</a> angesehen und für meine Zwecke benutzt hatte. Seitdem werkelt es nun still und leise (bei Bedarf) vor sich hin.

Vielleicht kommt in 2026 mal wieder ein wenig neuer Schwung in meine Projekte, falls sich ein paar Leute finden, die genau so viel Spaß an dem Projekt haben wie ich. Dann wird es mal einen Basteltag bei der Trolug</a> geben.
Angefangen habe ich bereits damit, mir einen Bot zu schreiben, der via XMPP</a> die Cheerlights Farbe beeinflussen kann. Die Überschrift hier zeigt übrigens auch die aktuelle Farbe der Cheerlights an.
Mal sehen, wo die Reise so weiter hingeht ... to be continued

Demoautomat - Froscon 2025

2025-08-31T00:00:00+00:00

Auch dieses Jahr (sowie schon das Jahr davor) hat der Demo-Automat seinen Zweck erfüllt und jede Menge neugierige Blicke auf sich gezogen. Alle Workshops und Demos waren an beiden Tagen gut besucht, was uns die Motivation gibt, nächstes Jahr mit den Themen weiter zu machen.
Aber auch Verbesserungspotenzial haben wir erkannt und können das eine oder andere bestimmt bis nächstes Jahr umsetzen:

Einbau eines weiteren Tasters zum ordnungsgemäßen Herunterfahren des Gerätes ohne Hilfe eines externen Gerätes</li>
Umbau der Stromversorgung auf USB-C (während der FroSCon gab am Sonntag das Netzteil seinen Geist auf und niemand hatte Ersatz)</li>
NodeRed - Rückmeldungen der LEDs noch nicht 100% sauber implementiert</li>
nochmaliger Austausch der roten LED auf eine stärker leuchtende LED</li>
mehr Zeit für die einzelnen Themen</li>
Anpassung der XMPP-Räume auf den XMPP-Server der TroLUG</li> </ul>

Demoautomat - 2025

2025-07-05T00:00:00+00:00

Nach längerer "Ruhezeit" des Demoautomaten galt es, diesen wieder "fit" zu machen für die diesjährige FrOSCon</a>. Nach einem Upgrade der Basis-Software mussten einige Software Umbauten stattfinden. So werden die GPIOs des PIs mittlerweile anders angesprochen und das XMPP-Modul von NodeRed lief alles andere als stabil und wurde entfernt. An dessen Stelle tritt ein node.js-Script, welches die Nachrichten aus einem XMPP Gruppenchat auf ein MQTT-Topic umsetzt.
Die Auswertung der Chat Nachrichten übernimmt FHEM komplett. Die GPIO-Steuerung direkt aus NodeRed heraus war wegen der Änderung der GPIO-Bibliothek auch nicht mehr möglich, so dass auch diese Aufgabe jetzt FHEM zufällt. Die Auswertung des Tasters übernimmt ebenfalls FHEM.
Für die Aussendung der XMPP-Nachricht an den Gruppenchat wird das Kommandozeilen-Tool go-sendxmpp</a> eingesetzt.
Als Erweiterung zum Vorjahr gibt es ab sofort auch eine Webseite, über die sich Nachrichten für das Display (PicoTweet) absetzen lassen.

Monocles Chat 1.7.9

2025-06-23T00:00:00+00:00

Ein gutes Video, um Monocles Chat nach dem Herunterladen einzurichten, findet man hier: https://clip.place/w/qKLU4hNHYSpQj3kAEnWEDZ</a> </blockquote>

Da die Entwicklung von Monocles Chat zur Zeit rasant voranschreitet, kann es passieren, dass die nachfolgenden Kniffe nicht mehr oder anders funktionieren </blockquote>

Fehler und Funktionswünsche werden zur Zeit hier gesammelt (Englisch), bitte klicken</a> </blockquote>

rechts wischen auf einer Nachricht macht diese zum Zitat im Eingabefeld</li>
langer Druck auf das Anlagen- /Senden-Symbol fügt ein /me in die Nachricht ein</li>
In einem Chatraum (MUC) kommt man durch Klick auf den Namen in die Eigenschaften des Chatraums</li>
klickt man in den Raumeigenschaften auf "Zugehörige Chats", werden alle öffentlichen Chaträume auf dem gleichen Server angezeigt (falls die Raumsuche auf "Lokaler Server" eingestellt ist)</li>
1:1 Chats und Chaträume können über das Burger Menü (die 3 Punkte oben rechts) auf den Startbildschirm gelegt werden</li>
ein einzelner : öffnet die Sticker, gesucht werden können Sticker z. B. mit :racoon</code></li>
der aktuelle Kartenserver, um einen Standort in der Vorschau angezeigt zu bekommen, liegt hier: https://staticmap.monocles.eu/map.png Es reicht aber, einen eventuell vorhanden Eintrag in den Einstellungen zu löschen, dann wird diese Adresse als default genommen (Einstellungen - Sicherheit - Kartenserver)</li>
ab sofort werden ad-hoc Kommandos richtig unterstützt</li>
Falls in den Einstellungen - Experteneinstellungen der Schalter "Zeige Thread Icon" aktiviert ist, kann man in Gruppenchats einen Filter setzen (links im Eingabefeld) und schreibt dann mit dieser Zusatzmarkierung in den Chat. Möchte man das Symbol ändern, klickt man entweder im Eingabefeld auf das Symbol und wählt ein anderes aus. Wahlweise kann man im Chatverlauf auch auf einen Beitrag mit einem entsprechenden Symbol klicken, dann werden die nächsten Beiträge mit diesem Chatsymbol geschrieben. Klickt man lange auf einen Chateintrag mit einem Thread Symbol, so wird im Kontextmenü angeboten, dass man nur diesen Thread angezeigt bekommt und man hat damit eine Filteroption. Sehr nützlich bei großen Chaträumen, wo viele Themen parallel laufen.</li> </ul>
Asterisk - SMS 2025-05-29T00:00:00+00:00 Wer IP Telefone an seinem Asterisk nutzt (Softphones oder feststehende IP Telefone), der hat auch die Möglichkeit, sich gegenseitig Kurznachrichten (ähnlich SMS) zu schicken. Wichtig zu wissen ist, dass es nur die Übertragung nur dann erfolgreich ist, wenn der Empfänge auch online ist. Eine Zwischenspeicherung zum späteren Versand ist (hier) nicht vorgesehen. Nachfolgend die Konfiguration auf Asterisk-Seite. Angefangen wird in der pjsip.conf Datei. Hier muss für jede Nebenstelle (extension), welche Nachrichten empfangen können soll, der Kontext festgelegt werden, auf den wir uns später in der extensions.conf beziehen werden. Sinnvollerweise deklariert man den einmal in einem Template, so dass alle Nebenstellen dann davon profitieren können ... oder man macht sich die Mühe und schreibt es in die Konfiguration jeder Nebenstelle. Die Direktive, die wir brauchen, lautet: message_context=textmessages</code> Das war in der pjsip-Konfiguration schon alles. Als nächstes geht es in unseren Dialplan, also in die extensions.conf: Hier wird es etwas aufwändiger. Erst einmal das komplette Code-Snippet: [textmessages] exten => _6XXX,1,Gosub(send-text,s,1,(${EXTEN})) [send-text] exten => s,1,NoOp(Sending Text To: ${ARG1}) exten => s,n,NoOp(Message from: ${MESSAGE(from)}) exten => s,n,NoOp(Message to: ${MESSAGE(to)}) exten => s,n,NoOp(Message body: ${MESSAGE(body)}) exten => s,n,Set(SENDER=${CUT(CUT(CUT(MESSAGE(from),@,1),<,2),:,2)}) exten => s,n,NoOp(Sender: ${SENDER}) exten => s,n,MessageSend(pjsip:${ARG1},${SENDER}) exten => s,n,NoOp(Message send status: ${MESSAGE_SEND_STATUS}) exten => s,n,GotoIf($["${MESSAGE_SEND_STATUS}" = "SUCCESS"]?success:failed) exten => s,n(success),Hangup() exten => s,n(failed),Set(MESSAGE(body)=SMS-Fehler zum Empfänger ${ARG1}: ${MESSAGE_SEND_STATUS}) exten => s,n,MessageSend(pjsip:${SENDER},${ARG1}) exten => s,n,Hangup()</code></pre> Erklärung: Zuerst brauchen wir die "Überschrift" bzw. Referenz aus unserer pjsip.conf Datei und deklarieren den neuen Abschnitt mit "textmessages". Hier folgt eine einfache Verzweigung mittels Gosub in den Unterabschnitt send-text und dort in die Extension s, Startnummer 1. Mittels der Variablen (${EXTEN}) wird die Zielrufnummer übergeben und steht als ${ARG1} zur Verfügung. Da ich 4-stellige Nebenstellen-Nummern, beginnend mit 6 vergeben habe, steht 6XXX für die feste 6 am Anfang gefolgt von 3 beliebigen Ziffern. Im Abschnitt send-text werden erst einmal 4 Informationszeilen zur Kontrolle im Log ausgegeben, die den Empfänger, den Absender und den eigentlichen Inhalt der Nachricht enthalten. Mithilfe der CUT-Funktion wird als Nächstes der Absender aus den MESSAGE(from) Funktion herausgeschnitten und danach zur Kontrolle im Log ausgegeben. Jetzt erfolgt der eigentliche Versand der Nachricht mittels der Funktion MessageSend(pjsip:${ARG1},${SENDER}). Die folgenden Zeilen werten aus, ob die Übertragung erfolgreich war oder nicht. Falls sie das war, wird der Block mit einem Hangup() Befehl einfach beendet. Falls nicht, gibt es eine Rückmeldung, ebenfalls per Kurznachricht, an den Absender mit einer Fehlermeldung. Nachfolgend war das Softphone 6004 ausgeschaltet, die Fehlermeldung zeigt sich dann wie folgt: Getestet habe ich die Funktion mit dem Softphone "Sipnetic" und einem festen Apparat "fanvil X6U". Hier ist zu beachten, dass das Fanvil nur für reine Textübermittlung geeignet ist. Bei 2 Softphones können auch z. B. Smileys übertragen werden. Der Asterisk ist hierbei KEIN Hinderungsgrund. Am Schluß ein kleiner Eindruck einer empfangenen Kurznachricht auf dem "fanvil" Telefon, gesendet von der Nebenstelle 6001: Rein theoretisch sollte man so auch SMS aus dem Festnetz empfangen können. Das habe ich aber noch nicht probiert und ich bin mir nicht sicher, ob es das überhaupt noch gibt und von den Providern unterstützt wird. Nützlich ist die Funktion z. B. falls man auf dem Smartphone eine komplizierte Internet-Adresse dem Gegenüber mitteilen will, hierfür aber keine eMail schicken kann oder will und es zum Buchstabieren zu kompliziert ist ... oder einfach nur als netter Bonus :-) Nachtrag: SMS im Festnetz werden bei der deutschen Telekom seit 01.03.2023 nicht mehr unterstützt :-( s. hier</a> Browser Zugänge zu Hilfe-Chats 2025-05-11T00:00:00+00:00 folgende Zugänge sind direkt über einen Internetbrowser nutzbar</h3> Zugang zum Hilfe Chat für XMPP-Newbies: xmpp:newbies@muc.xmpp.dohdom.de?join</a></li> Zugang zum Chat der Troisdorfer Linux User Group (TroLUG) xmpp:trolug@conference.jabb3r.org?join</a></li> Zugang zum Chat der Dulcimerfreunde xmpp:dulcimerfreunde@muc.xmpp.dohdom.de?join</a></li> werden Gruppenchats bei yaxim.org</a> gehostet, so erhalten diese automatisch einen (anonymen) WebChat Zugang unter der Adresse: https://yaxim.org/chat/#mucname@chat.yax.im</li> direktes Feedback zu diesen Seiten kannst Du ganz unten rechts über "Feedback via XMPP" geben</li> </ul> XMPP Gruppenchats 2025-05-11T00:00:00+00:00 Hier findet Ihr eine Übersicht für deutschsprachige XMPP Gruppenchats (auch MUC = Multi User Chat). Politik bleibt absichtlich außen vor, hierfür gibt es schon genug Medien zum Austausch. Ergänzungen nehme ich gerne am Ende der Seite ganz unten rechts über den Support Chat entgegen. Die vorgeschlagenen MUCs sollten schon eine gewisse Mitgliederanzahl haben und ebenso keine illegalen Inhalte bereitstellen. Ist schon ein XMPP-Client installiert, sollte ein Klick auf den Link genügen, um in den Chatraum zu gelangen. Wenn nicht, dann schnell zu den weiteren einstiegsfreundlichen XMPP-Seiten</a> wechseln, sich ein Chatkonto zulegen und einen der vielen XMPP Clients installieren ;-) allgemeine Themen</h3> selbst aufgenommene Naturbilder</a>, Sprachen: DE und EN</li> Umwelt und Naturschutz</a></li> Ausflugsziele in Deutschland</a></li> Flohmarkt von privat an privat</a></li> Kochrezepte</a></li> Speisesaal - kochen,essen,schlemmen</a></li> Literatur Café 7 - Treffpunkt (nicht nur) für Künstler</a></li> Produkt-Empfehlungen</a></li> </ul> Hobbies</h3> GeocachingDE - finde den Schatz</a></li> Openstreetmap DE - Weltkarte</a></li> Dulcimerfreunde</a>, Homepage: https://dulcimerforum.de</a></li> Ultralight Backpacking</a>, Sprachen: DE und EN</li> Brettspiele</a></li> </ul> Technik-Themen</h3> selbstgebaute Technik, Heimautomation, Telefonieserver</a></li> Troisdorfer Linux User Group TroLUG</a>, Homepage: https://trolug.de/de/</a></li> Linux Mint User</a></li> devLUG - virtuelle Linux User Group</a>, Homepage: https://codeberg.org/devlug</a></li> KODI</a></li> Android MUC</a></li> digitales Basteln</a></li> Künstliche Intelligenz</a></li> </ul> XMPP spezifisch</h3> XMPP Newbies - nicht nur für Neueinsteiger</a>, Sprachen: DE und EN</li> </ul> Uptime Kuma Benachrichtigungen via XMPP 2025-04-25T00:00:00+00:00 Uptime Kuma unterstützt zwar schon jede Menge Messenger und sonstige Dienste, um Benachrichtigungen an zuständige Personen weiterzuleiten, leider gibt es aber (noch) keine native Auswahl für Jabber/XMPP. Hier behelfen wir uns mit einem Trick: Das Verfahren läuft, wie bei Proxmox auch, über sogenannte Webhooks. Das heißt, Voraussetzung ist ein XMPP-Server Betreiber, der auch über eine HTTP Schnittstelle verfügt (weitere Erklärung siehe hier</a>), mir bekannt sind z. B. Hot Chilli</a> oder monocles.de</a>. Ist das sichergestellt, sollte man als Nächstes eine base64-codierte Version seines XMPP-Zugangs, welchen man als Absender für die Nachrichten nehmen möchte (bestehend aus der XMPP-Adresse und dem dazugehörigen Kennwort), erzeugen. Die Anleitung hierfür unter einem Linux Betriebssystem steht auch in dem Artikel zu Benachrichtigungen von Proxmox</a>. Für leidgeplagte Win* User gibt es laut Stackoverflow</a> einen Powershell Befehl, der die gleiche Arbeit leistet (nicht getestet!): powershell "[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(\"sender@server.de:geheimespasswort\"))"</code></pre> Sind diese Voraussetzungen erfüllt, geht es in die Verwaltungsoberfläche von Uptime Kuma</a>. Dort findet man nach einem erfolgreichen Login in sein Administrator Konto oben rechts ein Pulldown-Menü mit dem Punkt Einstellungen</code>. Hier wählt man den Punkt Benachrichtigungen</code> aus und klickt anschließend auf Benachrichtigung einrichten</code>. Aus der sehr langen Liste von Benachrichtigungsdiensten wählt man dann "Webhook" aus und erhält folgende (noch auszufüllende) Maske: Jetzt muss nur noch aus dem Beispiel die XMPP-Anbieter-Adresse richtig gesetzt werden, der Empfänger richtig eingestellt werden und bei den zusätzlichen Headern die oben generierte base64 Zeichenkette eingetragen werden. Danach bietet Uptime Kuma ganz unten die Möglichkeit, den soeben erstellten Webhook direkt zu testen. Das sollte zur Überprüfung auch gemacht werden, bevor dann im letzten Schritt das Ganze abgespeichert wird. Als letztes muss diese Benachrichtigungsmethode dann noch mindestens 1 Monitor zugewiesen werden und das war's! Falls alles in Ordnung war, könnte das Resultat so wie oben aussehen! Die erste Nachricht war der Test der Benachrichtigung. Die folgenden Meldungen war der simulierte Ausfall und anschließender Neustart eines Docker Containers. Viel Spaß beim Nachbau und gerne Rückmeldung dazu direkt hier im blogeigenen Chat ganz unten rechts auf jeder dieser Seiten zu finden. Nachfolgend noch eine Anleitung, wenn der Webhook nicht an einen Prosody Server, sondern an einen ejabberd Server geschickt wird (danke an Stephan für die Ergänzung). Auf dem ejabberd-Server muss http-api aktiviert sein und die ejabberd.yml um Folgendes ergänzt werden: listen: - ip: 127.0.0.1 port: 5580 module: ejabberd_http tls: false request_handlers: /api: mod_http_api modules: mod_http_api: {} acl: alert_sender: user: alerts@example.org api_permissions: "uptime-kuma": who: access: allow: acl: alert_sender what: - send_message</code></pre> In den Einstellungen bei Uptime Kuma ist Folgendes zu ändern: Die URL ändert sich zu: http://127.0.0.1:5580/api/send_message</code> (falls die Konfiguration von ejabberd.yml so ist wie oben beschrieben, sonst ggf. Port und Adresse anpassen). Da ejabberd den Sender und Empfänger nicht automatisch aus der URL extrahieren kann, muss bei Uptime Kuma der Anforderungstext wie folgt aussehen (custom bzw. benutzerdefinierter body): { "type": "chat", "from": "uptimekuma@beispiel.de", "to": "user@beispiel.de", "subject": "", "body": {{ msg | json }} }</code></pre> Die Konfiguration funktioniert so natürlich nur, solange Uptime Kuma und ejabberd auf der gleichen Maschine laufen, ansonsten sind die Adressparameter entsprechend zu ändern. Falls kein eigener XMPP-Server vorhanden ist, bitte bei Eurem XMPP-Provider nachfragen, was dieser für eine Serversoftware nutzt und ob die entsprechenden Konfigurationen vorliegen oder ihn lieb bitten, diese einzupflegen. Proxmox Benachrichtigungen via XMPP 2025-02-10T00:00:00+00:00 Da Proxmox seit einiger Zeit auch sogenannte "Webhooks" beherrscht, ist es relativ einfach, sich per XMPP Benachrichtigungen von Proxmox schicken zu lassen. Voraussetzung: Ihr nutzt einen XMPP-Anbieter, der auch eine HTTP-Schnittstelle für XMPP bereitstellt (z. B. Hot Chilli</a> oder monocles.de</a> bzw. monocles.eu</a>). Im Zweifel Euren Anbieter fragen. Benutzt dieser einen Prosody-Server, so heißt das entsprechende Modul, auf dem auch diese Anleitung beruht, mod_post_msg</a> Die Einrichtung erfolgt im Proxmox GUI über das Rechenzentrum</code>. Hier wählt man ziemlich weit unten den Punkt Benachrichtigungen</code> aus. Dort befinden sich dann zwei Unterpunkte, von denen wir uns den ersten genauer ansehen. Dieser lautet Benachrichtigungsziele</code>. Nach Anklicken des Punktes Hinzufügen</code> öffnet sich ein Pulldown-Menü, aus dem wir den Punkt Webhook</code> auswählen. Nun erfolgt die eigentliche Bearbeitung. Als erstes vergibt man dem Webhook einen Namen. Hier muss darauf geachtet werden, dass dieser keine Leerzeichen enthält, da sonst die Bearbeitung nicht abgeschlossen wird. Die Methode belassen wir auf POST. Das Häkchen bei Aktivieren sollte auch gesetzt sein. Jetzt erfolgt die Eingabe der Zieladresse, bei hot-chilli lautet diese: https://jabber.hot-chilli.net:5281/msg/</code>. Nutzt Ihr monocles.de oder monocles.eu als Provider, dann lautet die Zieladresse: https://monocles.de/msg/</code> bzw. https://monocles.eu/msg/</code>. Dann brauchen wir 2 Header, die wir im darauf folgenden Feld setzen. Der erste hat als Schlüssel Content-Type</code> und als Wert application/json</code>. Der zweite hat als Schlüssel Authorization</code> und erhält als Wert Basic base64-encoded-username:password</code>. Das Wort Basic wird so in den Wert geschrieben. Unter Linux bekommt man den darauf folgenden Wert in der Kommandozeile mit dem Befehl echo -n "benutzer@xmpp-server.de:strenggeheimespasswort" | base64</code>. Der Benutzer, der hier eingetragen wird, ist der Sender der Nachricht. Das jetzt folgende Feld heißt body</code> und beinhaltet Informationen im JSON-Format (wir haben ja als Content-Type json ausgewählt). Das sieht zum Beispiel jetzt so aus: { "to": "empfaenger@xmpp-server.de", "type": "chat", "body": "{{ title }}\n{{ severity }}\n{{ timestamp }}\n{{ message }}", }</code></pre> Der Wert von to</code> enthält die komplette XMPP-Empfängeradresse. type</code> sollte auf chat</code> belassen werden und im body</code> verbirgt sich die eigentliche Nachricht, die der Empfänger bekommen soll. Die jeweils doppelt geschweiften Klammern beinhalten Variablen, die beim Verschicken einer Benachrichtigung durch die jeweiligen Ereignisse ersetzt werden. Welche es davon alle gibt, kann man sich über die Hilfe links unten anzeigen lassen. Abschließend kann man noch einen Kommentar vergeben, der dann in der Übersicht auftaucht, damit man diese Benachrichtigungsart von anderen Arten besser unterscheiden kann. Danach kann die Eingabe auf einen Klick auf OK beendet werden und damit ist die XMPP-Benachrichtigung fertig. Falls alles richtig gemacht wurde, kann man jetzt in der Übersicht das neu erstellte Benachrichtigungsziel durch Anklicken auswählen und im Auswahlmenü einen Test ausführen lassen. Nach einer weiteren Bestätigung sollte man dann eine Testbenachrichtigung erhalten. Damit wäre die Konfiguration des Benachrichtigungsziels abgeschlossen. Im letzten Schritt muss noch festgelegt werden, bei welcher Art der Benachrichtigung die XMPP-Benachrichtigung versendet werden soll. Da ich bei mir noch keine Benachrichtigung per eMail konfiguriert hatte, lasse ich mich einfach bei allen Vorfällen benachrichtigen. Hierzu ändert man einfach den default-matcher</code> ab, indem man auf der Registerkarte Benachrichtigungsziele</code> das eben erstellte Benachrichtigungsziel (mit)auswählt. Neuer Anker Wechselrichter 2025-01-31T00:00:00+00:00 Nachdem ich mich letztes Jahr so oft darüber geärgert hatte, dass die Mindestabgabe in das Hausnetz 150 Watt beträgt und ich dadurch einiges des mühsam gesammelten Ertrags wieder verschenken musste, habe ich mich nun doch dazu entschlossen, den Wechselrichter passend zur Solarbank zu kaufen. Nun ist zwar der Januar nicht gerade repräsentativ, aber ich konnte doch die rückeingespeiste Leistung gut reduzieren. Jetzt muss ich nur noch schauen, wie ich die Logik meiner Heimautomation entsprechend gestalte, um ein Optimum herauszuholen. Der Wechselrichter "tickt" doch etwas anders als das vorherige Modell. allgemeine XMPP Tricks 2024-12-21T00:00:00+00:00 21.12.2024 (last update) In einem XMPP-Account können noch Zusatzinformationen wie z. B. die E-Mail Adresse oder die Homepage hinterlegt werden. Nicht alle Clients unterstützen die Anzeige und/oder das Editieren. Monocles Chat erlaubt die Anzeige der Informationen, in dem man in die Chatdetails eines 1:1 Chat geht. Die eigenen Informationen trägt man in den Kontodetails ein. Editieren kann z. B. auch Conversejs</a>.</li> ebenso kann man in den Details seines Accounts seine Präsenz setzen und einen Kommentar dazu schreiben (Bsp: Status abwesend, Kommentar: bin in einer Konferenz)</li> ein /me</code> am Anfang einer Nachricht wird ersetzt durch den Nicknamen (falls vom Client unterstützt) Bsp: /me ist interessiert -> MeinNick ist interessiert</li> in einem Multi User Chat (MUC) kann man durch Klicken auf das Profilbild/Avatar eines Nutzers ihm eine private Nachricht zukommen lassen (falls erlaubt) So stört man den Chat nicht und kann an bestimmte Leute gezielt Rückfragen stellen</li> da XMPP ein dezentrales/verteiltes Netzwerk ist, gibt es MUCs auf (nahezu) jedem Server. Sollte dieser Server einmal neu starten müssen, so wird man unter Umständen aus dem Gruppenchat "geworfen" (technisches Problem). Nach einem erneuten Verbinden sollte alles wieder da sein. Überprüfen kann man die uptime eines Servers über den 1:1 Chat mit magicbot@magicbroccoli.de</code> (unverschlüsselt) und dem Befehl !uptime <Servername></code> Hierbei ist Servername mit dem zu überprüfenden Server zu ersetzen, z. B. xmpp.dohdom.de</li> es gibt einige Bots, die einen Befehl an einem vorausgehenden Ausrufezeichen erkennen, z. B. !uptime</code></li> Möchte man einen 1:1 Chat jemandem weitergeben und gleichzeitig einen bestimmten Namen für diesen Chat vergeben, so geht das mit folgender Syntax: xmpp:ich@irgendwo.ser.ver?add;name=Anzeigename</code></li> möchte man einen Zugang ohne XMPP-Konto (z. B. für einen Support-Chat), so geht das nur mit einem anonymen Zugang. Dieser muss auf dem Server des Chats separat erstellt werden und der Server muss dies auch unterstützen</li> wenn man Bekannte in einen Chatraum einlädt, "fallen" diese direkt in den Raum rein, ohne dass sie selbst tätig werden müssen (im Gegensatz zum reinen Link verschicken)</li> Die Clients gajim oder profanity können die Komponenten eines XMPP-Servers auflisten (z. B. transports, anonyme Zugänge)</li> Einen Einladungslink (z. B. für eine eMail-Signatur) kann man so erstellen: https://xmpp.link/#eigene@xmpp.adresse Dabei die eigene XMPP-Adresse hinter das #-Zeichen setzen. Dies ist nur eine Einladung für einen Chat und erstellt kein Konto auf einem XMPP-Server!</li> </ul> SMS2XMPP Gateway 2024-07-14T00:00:00+00:00 Neulich kam mir beim Stöbern mal wieder die Idee, eine alte Hardware neu zu nutzen. Ich habe schon seit Ewigkeiten einen Mobilfunk Stick für das 3G Netz (ja richtig, 3G), welcher schon länger bei mir keine Verwendung mehr findet. Der Stick ist ein Huawei E160E (damals gab es den u. a. bei n24 für den Internet Zugang). Durch die Fusion von Sipgate</a> und simquadrat und da ich schon seit Ewigkeiten einen (jetzt) Sipgate Basic Account habe, gab es irgendwann mal eine Mobilfunknummer kostenlos zur SIP-Rufnummer dazu. Auch die lag bei mir bisher mehr oder weniger brach. Bei genauerem Studium hatte ich festgestellt, dass man sich kostenlos SIM-Karten bestellen kann. Also, mal das Internet bemüht und festgestellt, dass es mit Hilfe von den smstools</a> (vorpaketiert für Debian) ohne große Anstrengungen möglich ist, SMS empfangen und versenden zu können. Zuerst wollte ich den modemmanager benutzen, bin aber letztendlich bei den smstools hängen geblieben. Eine Langzeit Zuverlässigkeitsaussage habe ich zwar noch nicht, aber bisher werkelt der Stick prima vor sich hin. Da es wohl am Schwierigsten sein soll, das jeweilige Modem zu initialisieren, stelle ich hier meine Konfiguration zur Verfügung. Vielleicht kann es der eine oder die andere brauchen :-) devices = GSM1 outgoing = /var/spool/sms/outgoing checked = /var/spool/sms/checked incoming = /var/spool/sms/incoming logfile = /var/log/smstools/smsd.log infofile = /var/run/smstools/smsd.working pidfile = /var/run/smstools/smsd.pid outgoing = /var/spool/sms/outgoing checked = /var/spool/sms/checked failed = /var/spool/sms/failed incoming = /var/spool/sms/incoming sent = /var/spool/sms/sent stats = /var/log/smstools/smsd_stats loglevel = notice smart_logging = yes receive_before_send = no autosplit = 3 decode_unicode_text = yes eventhandler = /usr/local/bin/sms2xmpp.sh [GSM1] init = AT+CPMS="ME","ME","ME" device = /dev/serial/by-id/usb-HUAWEI_Technology_HUAWEI_Mobile-if00-port0 incoming = yes baudrate = 115200 keep_open = yes cs_convert = yes memory_start = 0 check_memory_method = 3 report = no rtscts = no report_device_details = yes signal_quality_ber_ignore = yes</code></pre> Hier einige Besonderheiten: der Init-Befehel ist wohl von GSM-Modem zu GSM-Modem unterschiedlich und nach einigem Suchen und Probieren war der oben gegebene mein Schlüssel zu den SMS</li> das Device nehme ich absichtlich NICHT als /dev/ttyUSB0, da sich diese Bezeichnung schon mal ändern kann, z. B. nach Neustarts oder beim Plugin neuer Hardware</li> der Stick meldet 2 Modems an, bei mir funktioniert nur das erste, ein Switch ist nicht erforderlich (wegen zusätzlich integriertem Massenspeicher), das machen anscheinend aktuelle Kernels von alleine</li> die Weiterverarbeitung passiert bei mir in der Datei /usr/local/bin/sms2xmpp.sh</code> die sich unter der Option eventhandler einstellen lässt. Hier ist wichtig zu wissen, dass der erste Parameter, der übergeben wird, das Ereignis darstellt (z. B. RECEIVED für SMS empfangen) und der zweite Parameter, der übergeben wird, den Pfad zur gespeicherten SMS beinhaltet.</li> </ul> Wie die Weiterverarbeitung in der Datei /usr/local/bin/sms2xmpp.sh</code> aussehen könnte, dafür gibt es hier</a> ein sehr einfaches Beispiel, was man als Startbasis nehmen kann. In meinem Falle nehme ich noch einige Daten mehr mit hinzu und sende das Ganze via go-sendxmpp</a> an meine XMPP Adresse. Eine winzige (bauartbedingte) Unannehmlichkeit gibt es noch: Die eingebaute grüne LED des Sticks blinkt regelmäßig im 2-3 Sekundentakt 1x auf. Der Stick sollte daher wenn möglich nicht im Schlafzimmer verbaut werden. Ansonsten bin ich ziemlich zufrieden mit der Lösung. Hier das Ergebnis: Der erste Anbau erfolgte an einem Raspberry Pi Model 1B, musste aber aufgrund eines fehlenden aktiven USB-Hubs aber wieder verworfen werden, da der Stick soviel Energie aus dem USB-Port zieht, dass der Pi beim Einstecken neu startet. Das war so für mich nicht zu gebrauchen. Sendemäßig habe ich diese Lösung noch nicht implementiert, da noch nicht gebraucht. Demoautomat - der Umzug 2024-07-11T00:00:00+00:00 Endlich ist der Demo-Automat in ein richtiges Zuhause umgezogen. Das Gehäuse ist natürlich komplett geschlossen, allerdings sieht man so schön die "inneren Werte". Asterisk - Konfig dt. Telekom 2024-06-19T00:00:00+00:00 Die Konfiguration, um einen Dt. Telekom Magenta Zuhause Anschluss über den Asterisk an's Laufen zu bekommen, beruht, im Gegensatz zur an anderer Stelle beschriebenen Sipgate Konfiguration, nicht auf der PJSIP-Wizard Datei, sondern wird komplett in der pjsip.conf Datei hinterlegt. Ob eine funktionierende Konfiguration mit dem Wizard erstellt werden kann, habe ich nicht ausprobiert, sollte aber grundsätzlich möglich sein. Wie schon in der Konfiguration bei Sipgate erwähnt, sollte für jede registrierte Rufnummer ein eigener Transport definiert werden. Wie bei jedem Trunk (d. h. Verbindung zu einem Telefonanbieter) und pjsip bei Asterisk gibt es 6 verschiedene Definitonsbereiche. Diese lauten: transport (Transportweg)</li> registration (Registrierung beim Provider)</li> auth (Authentifizierung)</li> endpoint (Eigenschaften für ankommende u. abgehende Gespräche)</li> aor</li> identify (Sicherheit, um unberechtigte SIP-Anfragen zu unterbinden)</li> </ul> Nachfolgend meine (anonymisierte) Konfiguration für die virtuelle Rufnummer 0228-123456: [transport-telekom-tls-1] type = transport protocol = tls bind = 0.0.0.0:0 local_net=192.168.2.0/24 ca_list_file = /etc/ssl/certs/ca-certificates.crt method = tlsv1_2 verify_server = yes allow_reload = no tos = 0xb8 cos = 3 ;==== Templates ==== [regt](!) retry_interval = 60 fatal_retry_interval = 0 forbidden_retry_interval = 10 max_retries = 10000 expiration = 660 auth_rejection_permanent = yes line = yes [endpt](!) context = telekom-in disallow = all allow = g722,alaw,ulaw send_connected_line=false from_domain = tel.t-online.de language = de user_eq_phone = no t38_udptl = no t38_udptl_ec = none fax_detect = no trust_id_inbound = no t38_udptl_nat = no direct_media = no rewrite_contact = yes rtp_symmetric = yes dtmf_mode = rfc4733 tos_audio=0xb8 rtp_timeout=120 media_encryption = sdes [telekom_123456_reg](regt) type = registration transport = transport-telekom-tls-1 outbound_auth = telekom_123456_auth server_uri = sip:tel.t-online.de client_uri = sip:+49228123456@tel.t-online.de contact_user = +49228123456 endpoint = telekom_123456 [telekom_123456_auth] type = auth auth_type = userpass password = irgend:etwas-0001@tel.t-online.de username = +49228123456 [telekom_123456](endpt) type = endpoint transport = transport-telekom-tls-1 message_context = messaging outbound_auth = telekom_123456_auth aors = telekom_123456_aor from_user = +49228123456 contact_user = +49228123456 [telekom_123456_aor] type = aor contact = sip:+49228123456@tel.t-online.de qualify_frequency=240 remove_existing=yes [telekom_123456_identify] type = identify endpoint = telekom_123456 match = tel.t-online.de</code></pre> Nachfolgend noch ein paar Hinweise: Solange die Registrierung am heimischen Anschluss (zu dem die Rufnummern gehören) erfolgt, ist das Passwort in der in der auth-Sektion tatsächlich egal, da die Telekom hier einen anderen Weg zur Überprüfung des Benutzers benutzt. Die Gesprächsverschlüsselung erkennt man an der Option media_encryption = sdes</code>. Diese gilt, genau wie bei der Sipgate-Konfiguration auch, zwischen Asterisk und (in diesem Falle) der Telekom und darf nicht mit einer Ende-zu-Ende Verschlüsselung verwechselt werden! Auch hier gilt: local_net ist auf das lokale Netz anzupassen, der Pfad für die ca_list_file Datei ist evtl. auch anzupassen (das ist die Datei, in der sämtliche Zertifizierungsstellen aufgeführt sind). Die Sektionen regt und endpt sind wieder Vorlagen (Templates), um sich entsprechende (sich wiederholende) Einträge bei den einzelnen Rufnummern sparen zu können. Als Codecs benutze ich G722 (das entspricht HD-Voice) sowie alaw (das ist die Generation vor HD-Voice, normale Gesprächsqualität) sowie ulaw (ob das von Telekom unterstützt wird, weiß ich nicht, da es immer schon vorher eine Einigung auf G722 gibt). Bei Problemen lohnt es sich immer mal, auf der Asterisk Kommandozeile den SIP-Logging einzuschalten. Für PJSIP geht das mit dem Befehl pjsip set logger on</code>. Dabei ist zu beachten, dass es bei mehreren Rufnummern durchaus einige Logging-Meldungen gibt, so dass entsprechende Meldung erst zugeordnet werden müssen. Sobald man die gewünschten Informationen hat, kann das Logging mit pjsip set logger off</code> wieder beendet werden. Asterisk - Konfig Sipgate 2024-06-16T00:00:00+00:00 Bei der Konfiguration für Sipgate habe ich mich für den Weg über die pjsip_wizard.conf Datei entschieden. Dieser Weg ist etwas übersichtlicher als die klassische PJSIP-Konfiguration. Als erstes müssen wir einen eigenen Transport erstellen (das sollte man bei TLS für jede registrierte Rufnummer / jedes registrierte Konto machen). Diese habe ich in eine eigene Datei ausgelagert und pjsip-tls-transports.conf genannt. Diese Datei muss dann in der pjsip.conf eingebunden werden mittels dem Befehl #include pjsip-tls-transports.conf</code>. Der Inhalt sieht wie folgt aus, das lokale Netz mit local_net ist natürlich anzupassen, ggf. auch der Pfad zur Datei, die sämtliche ca-Zertifikate enthält: [transport-sipgate-tls] type = transport protocol = tls bind = 0.0.0.0:0 local_net=192.168.2.0/24 ca_list_file = /etc/ssl/certs/ca-certificates.crt method = tlsv1_2 verify_server = yes allow_reload = no tos = 0xb8 cos = 3</code></pre> Die Datei pjsip_wizard.conf wurde für sipgate um folgendes ergänzt: [trunk_defaults](!) type = wizard sends_auth = yes sends_registrations = yes endpoint/allow_subscribe = no endpoint/allow = !all,g722,alaw endpoint/rewrite_contact = yes endpoint/rtp_symmetric = true endpoint/direct_media = no endpoint/language = de aor/qualify_frequency = 30 registration/expiration = 1800</code></pre> Dieser Abschnitt ist ein sogenanntes Template (oder eine Vorlage), auf der man sämtliche anderen Konten aufbauen kann, ohne sich mit den Anweisungen wiederholen zu müssen. Erkennbar ist dies an dem (!) hinter der Konfigurations-Definition. Nachfolgend die Konfiguration für ein sipgate-Konto. Die Kontodaten müssen natürlich angepasst werden, ebenso der entsprechende Kontext, in dem ankommende Gespräche abgefangen werden sollen. Die benutzten Server-Bereiche in der Identify-Sektion konnte ich den Hilfeseiten von Sipgate entnehmen. Zu beachten ist, dass ankommende Gespräche in die s-Extension fallen, sobald das Konto über den PJSIP-Wizard erstellt worden ist. Ob man dies gezielt ändern kann, weiß ich nicht. Die Sipgate-Konfiguration "erbt" die Einstellungen des Abschnitts trunk_defaults ;==== sipgate Config ==== [sipgate](trunk_defaults) transport = transport-sipgate-tls endpoint/context = sipgate-in remote_hosts = sipgate.de accepts_registrations = no endpoint/send_rpid = yes endpoint/send_pai = yes endpoint/from_user = sipgate-benutzername endpoint/from_domain = sipgate.de client_uri_pattern = sip:sipgate-benutzername@sip.sipgate.de server_uri_pattern = sip:sip.sipgate.de contact_pattern = sip:sipgate.de endpoint/force_rport = true endpoint/incoming_call_offer_pref = remote outbound_auth/username = sipate-benutzername@sipgate.de outbound_auth/password = sipgate-sip-passwort endpoint/outbound_proxy = sip:sip.sipgate.de\;lr aor/outbound_proxy = sip:sip.sipgate.de\;lr registration/outbound_proxy = sip:sip.sipgate.de\;lr identify/match = 217.10.64.0/20,217.116.112.0/20,212.9.32.0/19 endpoint/disallow = all endpoint/allow = g722,ulaw,alaw endpoint/media_encryption = sdes</code></pre> Wie man erkennen kann, ist die Medien-Verschlüsselung mittels sdes aktiviert. Mit dieser Konfiguration sollte es nun möglich sein, Transport- und Gesprächsverschlüsselung über sipgate einzurichten. ACHTUNG: Die Gesprächsverschlüsselung gilt nur bis zum Endpunkt bei sipgate. Es ist noch keine Ende-zu-Ende Verschlüsselung!!! Vorstellung Asterisk 2024-06-13T00:00:00+00:00 Eigenschaften meines Asterisk Servers:</h3> Verbindung zu 2 weiteren Asterisk Instanzen via IAX2 Protokoll</li> integrierte Blacklist zur Abwehr von Spam Anrufen, Hinzufügen oder Löschen von Nummern per Kurzwahl möglich (PIN-geschützt)</li> "Sonderbehandlung" für erkannte SPAM-Anrufe</li> Ein Testfax kann mit einer Kurzwahl an eine beliebige Nummer geschickt werden</li> ein Fax kann per eMail geschickt werden (PDF oder PNG/JPG möglich)</li> 2 feste aussenliegende Nebenstellen sowie mobile Nebenstellen</li> teilweise Integration in meine Heimautomation mit FHEM</li> Benachrichtigungen mittels XMPP über entgangene Anrufe und erhaltene SPAM-Anrufe</li> Transport- und Gesprächsverschlüsselung zu Sipgate und Deutsche Telekom Trunks</li> Morsetrainer</li> diverse Radiostreams und Podcasts</li> Wettervorhersage anhand der Postleitzahl</li> testweise Kurzwahlen zu xmpp-Adressen für Audiocalls</li> Anbindung von sip2sip und antisip</li> Blindentelefon (seit 27.02.2026)</li> </ul> Einbindung in die Heimautomation 2024-05-18T00:00:00+00:00 Nach einiger Bastel- und Programmierarbeit bin ich mit dem derzeitigen Stand meiner Auswertemöglichkeiten doch recht zufrieden. Mir ist es gelungen, nicht nur die Einspeisung ins Hausnetz zu monitoren, sondern auch den Ladezustand der Solarbank, die Solareinspeisung und die Abgabe an den Wechselrichter zu erfassen. Das Ganze fliesst in meiner Heimautomation FHEM</a> zusammen und sieht so aus: Zusätzlich gibt es jeden Tag um 22:00 Uhr (natürlich per XMPP</a>) eine Energiebilanz für den Tag, woraus auch der Nettoertrag sowie der Monatsertrag ersichtlich wird. Jetzt darf noch ein bisschen mehr die Sonne scheinen und dann ist das Projekt zuerst einmal abgeschlossen. Speicher reintegriert 2024-04-03T00:00:00+00:00 Nachdem mir die Tiefenentladung der Solarbank im Winter keine Ruhe gelassen hat und auch noch zusätzlich laut Anker App ein Firmware Update anstand, habe ich den Speicher doch früher als geplant wieder in mein System reintegriert. Nachdem mit der alten Firmware der Speicher trotz 1 Tag Niedrigladung (mit ca. 30W) auf 0% blieb, half ein kurzer Blick ins Internet und ein gewagter Reset (beide Knöpfe der Powerbank mind. 15 Sekunden drücken) ... und schon änderte sich die Ladezahl. Im WLAN ist der Speicher trotz Reset geblieben. Jetzt konnte ich das Firmware Update einspielen. Dabei habe ich die Erfahrung gemacht, dass die Anker App sowohl Bluetooth als auch Standort Zugriff braucht und dass das Smartphone nicht wie beschrieben so nah wie möglich an die Solarbank gebracht wird, sondern es mit ca. 30 - 50cm Abstand wesentlich besser funktionierte. Insgesamt brauchte ich 2 Anläufe, aber dann war die neue Firmware installiert. Nach der Installation der Firmware zeigte mein Speicher allerdings wieder 0% Ladung. Beim nächsten Ladezyklus konnte ich den Ladezustand dann aber wachsen sehen (danke liebe Sonne). Bisherige Erkenntnisse des Ladeverhaltens der Solarbank Bei Solar-Einspeisungen bis ca. 50 Watt geht die komplette Energie in die Solarbank.</li> Bei Solar-Einspeisungen bis ca. 150 Watt geht die komplette Energie ins Hausnetz, die Solarbank lädt gar nicht.</li> Bei Solar-Einspeisungen größer 200 Watt wird die Energie aufgeteilt, das Prinzip ist noch unklar, ich habe Ladeleistungen zwischen 30W und 300 Watt gesehen, evtl. hängt das von dem momentanen Batteriestand ab.</li> </ul> Bisherige Erkenntnisse zum Entladeverhaltens der Solarbank leider hat es Anker immer noch nicht geschafft, eine Entladeleistung < 150W auf die Beine zu stellen, sehr traurig</li> bei Abgabe von 150W über 3 Stunden entlädt sich die Batterie um ca. 20% (gemessen von 40% auf 19%)</li> </ul> Allgemein kann ich aber jetzt schon sagen (so wie voriges Jahr schon festgestellt), dass mir Anker zu wenig Optionen bietet, das Lade-/Entladeverhalten feinkörniger zu steuern. Eine Mindestentladung von 150W halte ich persönlich für zu hoch, um nur die Grundlast abzudecken (was nachts, wo der Speicher ja hauptsächlich gebraucht wird, meistens der Fall ist). Auch der "Energienutzungsplan" ist mir viel zu unflexibel. Normalerweise müsste ich jeden Tag die App anpacken, schauen, wieviel im Speicher ist, und demnach meinen Plan ändern. Sehr unflexibel und auch nicht wirklich automatisierbar. Da ist noch viel Luft zum Nachbessern. Als nächstes erfolgt die weitere Beobachtung und Optimierung der Heimautomation (und des Benutzerverhaltens) um möglichst wenig Energie wieder an den Betreiber zurück zu verschenken. Bei Balkonkraftwerken wird dieses nämlich im Allgemeinen nicht vergütet. Solarmodule 2024-03-30T00:00:00+00:00 Jetzt ist es endlich soweit: Nachdem die passende Halterung gefunden wurde, konnten die beiden Solarpanels in ihre endgültige Position gebracht werden. Das ging gut, auch wenn es etwas gedauert hatte. So einfach wie ein Bild aufhängen ist es allerdings nicht. Die nächste Woche werde ich jetzt erst einmal die Ertragsänderung beobachten und mich darüber freuen (solange es das Wetter zulässt), danach erfolgt die (Re)Inegration des Speichers ... jetzt erstmal das Ganze analysieren und optimieren. Demoautomat - Rasppi Tausch 2024-03-23T00:00:00+00:00 Heute habe ich das "Herz" der Schaltung, den Raspberry Pi 1B gegen einen Raspberry Pi Zero W ausgetauscht. Der Vorteil: durch den gleichen Chipsatz brauchte kein neues System auf eine neue SD-Karte aufgespielt werden, die Konfigurationen konnten 1:1 übernommen werden. Und jetzt kann der Raspberry Pi via WLAN angebunden werden. Das Fallback funktioniert über eine USB-Netzwerkkarte. Balkonkraftwerk - Formalitäten 2024-03-11T00:00:00+00:00 Hier bedarf es 2 Anmeldungen. Die erste erfolgt beim lokalen Netzbetreiber (in meinem Falle der Syna), die zweite erfolgt bei der Bundesnetzagentur im sogenannten Marktstammdatenregister. Beides geht recht problemlos. Bei mir bestand die Syna darauf, einen 2-Richtungs-Zähler einzubauen (allerdings ohne Mehrkosten zum bisherigen digitalen Zähler, der auch schon beide Richtungen anzeigen konnte, allerdings nur in Summe). Nachtrag vom 16.05.2026: Mittlerweile ist keine Anmeldung mehr beim lokalen Netzbetreiber erforderlich, die Meldung im Marktstammdatenregister soll auch einfacher geworden sein und ist die einzige Anmeldung, die noch erforderlich ist. Anfangs Ertrag 2024-03-10T00:00:00+00:00 Da die Module zur Zeit noch mehr als suboptimal positioniert sind, kann ich (noch) keine verlässlichen Angaben hierzu machen. Bisher gelang es mir "lediglich", eine Maximalleistung von etwas über 200W zu erzielen. Gemessen wird das Ganze am Einspeisepunkt mit einem Shelly Leistungsmesser. Das war witzigerweise in der kälteren Jahreszeit. Jetzt, wo die Sonne wieder höher steigt, habe ich noch mit zusätzlicher Verschattung zu kämpfen, wodurch ich die 200W Peak zur Zeit nicht mehr erzielen kann. Die bisherige maximale Ausbeute von einem Tag lag bei 0,45 kWh ... laut Werbung des Herstellers sollen bis zu 400 kWh pro Jahr möglich sein. Da ist noch VIEL Luft nach oben. Die anfänglichen Versuche mit dem Speicher habe ich im Moment abgebrochen, da bei der kleinen Ausbeute sich der Speicher im Moment nicht lohnt. Die ganze erzeugte Energie wird nämlich dann nur dazu gebraucht, den Speicher zu laden. Das wird sich jetzt mit zunehmender Helligkeit und dem optimalen Platz für die Solarpanels (hoffentlich) ändern. Anfangsschwierigkeiten 2024-03-09T00:00:00+00:00 Das größte Hindernis welches zur Zeit immer noch besteht ist, dass es so gut wie keine Halterungen für die Solarmodule gibt, welche an einem "normalen" Balkon, bestehend aus reiner Brüstung ohne Handlauf und von außen einer "nackten Wand" ähnelnd, zu bekommen sind. Nach intensiver Suche sind wir zwar bei einer Firma fündig geworden, leider passen die Abmaße aber nicht zu unseren Solarmodulen. Es wird wohl eine Eigenbaulösung werden, und ich versuche, hier darüber zu berichten. Balkonkraftwerk - Start 2024-03-09T00:00:00+00:00 Meine Konfiguration</h2> Hier möchte ich meine gesammelten Erfahrungen mit meinem Balkonkraftwerk weitergeben, um anderen Leuten Mut zu machen, dieses Projekt auch in Angriff zu nehmen (oder auch nicht)?! Gekauft wurde das Balkonkraftwerk Ende September 2023. Das Komplettset besteht aus 2 Glas-Glas Modulen (je ca. 25 kg Lebendgewicht) der Firma Jolywood Typ JW-HD108N-420W mit je 420W Peak Leistung, einem Hoymiles Wechselrichter HMS 800W (max. 800 Watt, Ausgangsleistung einstellbar) sowie einem Speicher der Firma Anker, Typ Solix Solarbank mit 1,6 kWh Speicherkapazität. Nach einiger Beobachtungszeit muss ich hier noch hinzufügen, dass ich die beste Sonneneinstrahlung erst ab ca. 11:45 Uhr bekomme und am späten Nachmittag bzw. Abends mit 1 Verschattungen durch einen Baum zu kämpfen habe. Dies muss natürlich bei den Erträgen mit berücksichtigt werden. Trotzdem bin ich jetzt, nach gut 1,5 Monaten im "Endausbau" doch schon recht zufrieden. Transports 2024-02-18T00:00:00+00:00 XMPP bietet die Möglichkeit, mit Hilfe sogenannter Transports</a> Nachrichten in andere (meistens proprietäre) Netze wie z. B. WhatsApp, Telegram, Signal, etc. senden und empfangen zu können. Die Einrichtung dieser Möglichkeit ist im Nachfolgenden beschrieben. Es gibt aktuell zwei große Softwares, die diese Transporte ermöglichen: Spectrum2</a></li> Slidge</a></li> </ul> Diese können selber gehostet werden, müssen es aber nicht. Ein öffentlicher XMPP-Provider, welcher beide Transports anbietet, ist z. B. hot-chilli.im</a>. Voraussetzungen</h3> ein Benutzerkonto des jeweiligen Netzes (z. B. Telegram)</li> ein (angemeldeter) Client des jeweiligen Zielnetzes</li> ein (beliebiger) XMPP Client, für Spectrum2 muss dieser ad-hoc Kommandos unterstützen</li> </ul> so geht es los</h3> Um herauszufinden, ob ein XMPP-Provider Transports anbietet, und wenn ja, welche, kann man mit Hilfe eines entsprechenden XMPP Clients wie z. B. Gajim - grafisch</a> oder profanity - konsolenbasiert</a> eine so genannte "Service Discovery" (disco) durchführen. Bei profanity lautet der entsprechende Befehl, um den Server von hot-chilli.net zu durchsuchen: /disco items hot-chilli.net</code></pre> und es erscheinen (unter anderem) folgende Zeilen: whatsapp.jabber.hot-chilli.net, (Hot-Chilli WhatsApp Transport) whatsapp.hot-chilli.im, (Hot-Chilli WhatsApp Transport (Slidge Test))</code></pre> Diese Adressen sollte man sich merken, da diese im Folgenden gebraucht werden, um den Transport nutzen zu können. ... und jetzt?</h3> Die weitere Vorgehensweise hängt jetzt vom zu nutzenden Transport ab. Da die Benutzung von slidge aus meiner Sicht einfacher ist, wird diese hier weiter beschrieben: Es wird ein 1:1 Chat im XMPP Client geöffnet, und zwar zur oben gezeigten Adresse (im Beispiel whatsapp.hot-chilli.im). Meistens erfolgt eine Warnung, dass das eine Domain ist und keine Chatadresse in der Form name@provider.org, das kann man aber ignorieren. Sollte der gewählte XMPP Client dies nicht unterstützen, bleibt nur das Ausweichen auf einen anderen Client. Die eigentliche Kommunikation erfolgt grundsätzlich unverschlüsselt. Nun kann man entweder mit ad-hoc Kommandos weiterarbeiten (diese werden z. B. durch Gajim oder Monocles Chat unterstützt), bei slidge hat man jedoch den Vorteil, dass man auch den normalen Chat nutzen kann. Gibt man hier z. B. help</code> ein, so erscheint ein kleines Hilfemenü und danach weiß man, dass man mit dem Befehl register</code> sich am Gateway registrieren kann. Das weitere Vorgehen hängt jetzt vom Zielnetz ab. Man wird vom slidge-Chat jedoch geleitet, was verlangt wird. Aufbau der Adressen anhand von WhatsApp und Telegram</h3> Grundsätzlich können Gruppen und Kontakte synchronisiert werden. Diese Kontakte erscheinen dann in der Kontaktliste und brauchen nicht mehr, wie nachfolgend beschrieben, gesucht zu werden. WhatsApp</h4> Die WhatsApp-Adressen sehen unter slidge in XMPP z. B. wie folgt aus: +4915112341234@whatsapp.hot-chilli.im</code> Dabei ist der erste Teil die Telefonnummer des Kontaktes bei WhatsApp, der Teil nach dem "@" entspricht der Transport-Domain. Telegram</h4> Eine Telegram-Adresse für einen 1:1 Chat sieht in XMPP z. B. wie folgt aus: 321056789@telegram.hot-chilli.im</code> Dabei ist die Nummer vor dem @ die ID des Chatpartners auf Telegram. Diese kann man mit z. B. mit Bots herausfinden. Eine Telegram-Adresse für einen Gruppenchat sieht in XMPP z. B. so aus: group-1004567890123@telegram-hot-chilli.im</code> Hierbei entspricht die Nummer vor dem "@" der Gruppenchat Nummer. Vor- und Nachteile von Transports</h3> Vorteile</h4> es wird nur 1 Client benötigt, um in verschiedenen Netzen unterwegs zu sein</li> für die Gegenseite ist kein Unterschied zu sehen, dass die Kommunikation über ein Transport erfolgt</li> man kann auf mehreren Endgeräten die Nachrichten des Zielnetzwerkes empfangen</li> Transports können auch genutzt werden, um automatisiert Nachrichten an Empfänger zu schicken, die in anderen Netzwerken zu Hause sind. Somit reicht es, sich mit der automatisierten Versendung von Nachrichten über das XMPP Netzwerk auseinanderzusetzen</li> </ul> Nachteile</h4> die Ende-zu-Ende Verschlüsselung (sofern aktiviert) geht durch den Transport verloren. Die Transportverschlüsselung ist davon unberührt</li> nicht alle Funktionen des Zielnetzwerks sind möglich (bedingt durch unterschiedliche Netzwerkaufbauten)</li> bei verschiedenen Netzen ist weiterhin ein Client des Zielnetzwerks für erneute Identifikation erforderlich (z. B. bei WhatsApp in Form eines QR-Codes, der im WhatsApp Client eingescannt werden muss ca. alle 2-3 Wochen)</li> im Punkt Datenschutz gelten die gleichen Voraussetzungen wie im Zielnetzwerk</li> für die Anzahl der Accounts gelten die gleichen Voraussetzungen wie im Zielnetzwerk</li> </ul> persönliches Fazit</h4> Wenn es unumgänglich ist, mit bestimmten Kommunikationspartnern über die (proprietären) Netze zu kommunizieren, sind Transports ein gutes Mittel, um den Kontakt zu halten. Vorzuziehen wäre jedoch ein kompletter Umstieg auf das XMPP Netzwerk. Demoautomat - 2024 2024-02-13T00:00:00+00:00 Softwaremäßig ist nun ein Stand erreicht, der locker ausreichen sollte, verschiedene Vorträge zu füllen und an dem auch Einiges gezeigt werden kann. Folgendes ist nun möglich: beim Start wird im Display die IP-Adresse des Rasppi angezeigt für wechselnde Netzwerkaufbauten</li> Ausgabe von Wetterdaten in einen XMPP Chatraum</li> Ansprechen des Displays mittels einem XMPP Chatraum (Mini Tweet)</li> Automatische Speicherung der Tweets inklusive Autor (nickname) in eine SQLite Datenbank</li> Abfrage der Datenbank (die letzten x Tweets sowie des "Top Tweeters") mittels XMPP MUC</li> die LEDs können mit einem Befehl aus XMPP heraus gesteuert werden</li> beim Druck des Tasters wird in einem XMPP Chatraum eine Nachricht ausgegeben</li> Anzeige verschiedener Daten auf dem NodeRed Dashboard</li> </ul> Folgende Software kommt zum Einsatz: Betriebssystem: DietPi</a> (Debian bookworm basiert)</li> SQLite</a> Datenbank</li> Node-Red</a> für die Verknüpfungen von und zu XMPP und zur Datenbank sowie der Darstellung verschiedener Werte</li> FHEM</a> als Backend zum Ansprechen des LCD Displays und Anzeige der eigenen IP Adresse</li> für den Datentransfer wird das XMPP-Protokoll</a> benutzt sowie MQTT</a> zur Übertragung der Werte zwischen Node-Red und FHEM</li> </ul> Probleme / TODOs</h5> das größte (und bisher einzige) Problem ist die unstabile XMPP-Implementierung bei NodeRed, wodurch häufiger der NodeRed Dienst beendet wird. Ob das an der Hardware oder der XMPP-Implementierung oder beidem liegt, bleibt noch zu klären</del> erledigt</li> TODO: Umlaute richtig auf dem LCD darstellen</li> TODO: Aufbau eines kleinen Netzwerks mit Router, um unabhängig von verschiedenen Vor-Ort-Netzwerken zu sein</del> erledigt</li> TODO: Gehäusebau für Raspberry Pi, Breadboard, LCD-Display, 3 LEDs und 1 Taster</del> erledigt</li> TODO: Gibt es mehr als 1 Top-Poster (mit gleich vielen Tweets) wird nur einer ausgegeben</li> </ul> Demoautomat - Erweiterung I 2024-02-06T00:00:00+00:00 Da LEDs alleine zwar schon schön, aber noch nicht cool sind, habe ich noch ein 16x2 LCD Display via I²C-Bus an den Raspberry Pi angeflanscht. Problem hierbei: Das Display lässt sich nicht direkt über NodeRed ansteuern. Da wir ja auch die Möglichkeiten von Heim-Automation(en) zeigen möchten, entschied ich mich, dass NodeRed die gewünschten Infos zuerst über MQTT herausgibt. Da FHEM mittlerweile einen eingebauten MQTT-Server zur Verfügung stellen kann und über FHEM die Ansteuerung des Displays ziemlich problemlos funktioniert, ist der Rest des Weges bis zum Display in FHEM realisiert. Damit ist es jetzt möglich, Mini-Tweets auf das Display über XMPP zu schicken. Dabei ist die Logik so intelligent, dass sie den Nickname des Autors erkennt. Eine Stromsparschaltung in Form eines "watchdogs" deaktiviert die Hintergrundbeleuchtung automatisch nach 3 Minuten, es sei denn, vorher kommt ein neuer Tweet an. Die Anschaltung mithilfe eines Pegelwandlers habe ich nach folgendem Tutorial realisiert: Raspberry Pi Tutorial</a> Asterisk - Client Konfiguration 2024-01-17T00:00:00+00:00 Mit der nachfolgenden Konstellation ist es mir gelungen, verschlüsselte Telefonate zu führen, unabhängig vom angebundenen Netz (Mobilfunk, Heimnetz hinter NAT, Freifunk, lokales Netz) Vorbereitung</h3> Portweiterleitungen im Router auf die IP des Asterisk-Servers 1 SIP-Port (TCP), der in der pjsip.conf unter Transport steht (hier: 5088)</li> pro Gespräch 2 UDP Ports für die Gesprächsdaten, diese sind in der rtp.conf anzugeben</li> </ul> </li> Zertifikate über let's encrypt besorgen, um den Server über TLS ansprechen zu können</li> </ul> pjsip.conf</h3> 1. Transportverschlüsselung (TLS)</h4> [transport-tls] type=transport protocol=tls bind=192.168.178.23:5088 cert_file=/etc/asterisk/certs/asterisk.cert priv_key_file=/etc/asterisk/certs/asterisk.key method=tlsv1_2 local_net = 192.168.178.0/24 local_net = 127.0.0.1/32 external_media_address=123.234.123.23 external_signaling_address=123.234.123.23</code></pre> cert_file: Let's encrypt Fullchain Datei für den DynDNS-Namen</li> priv_key_file: Let's encrypt Key Datei für den DynDNS-Namen</li> bind: Adresse des Asterisk, gefolgt von dem Port, auf den Clients connecten sollen</li> local_net: Hier kommt das lokale Netz sowie das localhost Netz rein</li> external_*: die aktuelle externe IP-Adresse des Anschlusses, muss durch ein Script automatisch bei IP-Wechsel geändert werden</li> </ul> 2. Gesprächsverschlüsselung / Client-Konfiguration</h4> ; ==== Templates ==== [ext-srtp](!) media_encryption=sdes media_encryption_optimistic=yes disallow=all allow=g722,ulaw,opus rewrite_contact=yes direct_media=no force_rport=yes rtp_symmetric=yes</code></pre> Diese Vorlage wird für alle Clients, die nachher verschlüsselt arbeiten sollen, 1x erstellt media_encryption: wir wollen RSTP mit SDES machen</li> media_encryption_optimistic: falls die Gegenseite keine Gesprächsverschlüsselung unterstützt, trotzdem verbinden ohne Gesprächs-Verschlüsselung</li> disallow, all: Hier kommen die Codecs rein, die die Clients nachher nutzen sollen, in der hier angegebenen Reihenfolge wird abgearbeitet (G722 zuerst, dann u-LAW, dann Opus)</li> rewrite_contact: Interne Adressen werden durch die externe ersetzt (wichtig für NAT)</li> direct_media: Clients können nur über Asterisk den Stream schicken, nicht untereinander</li> force_rport, rtp_symmetric: Nutze die in der rtp.conf angegebenen RTP-Ports</li> </ul> 3. Rest der Client-Konfiguration</h4> ; ==== Teilnehmer ==== [1000](ext-srtp) type=endpoint context=from-internal callerid="Tester 1" auth=1000 aors=1000 [1000] type=auth auth_type=userpass password=strenggeheim username=1000 [1000] type=aor max_contacts=2</code></pre> Der Rest der Client-Konfiguration ist identisch zum nicht-verschlüsselten Client. Dabei entspricht die 1000 der "Nebenstellennummer". Wichtig ist, die Vorlage (ext-srtp) dahinter zu setzen, damit das Template aus der vorherigen Sektion übernommen wird. Der Rest ist die Authentifizierung sowie die Anzahl der maximal gleichzeitigen Registrierungen. Demoautomat - der Start 2024-01-17T00:00:00+00:00 Auf der diesjährigen FrOSCon (2024) hat sich die TroLUG</a> vorgenommen, auch präsent zu sein. Mit diesem Projekt wollen wir zeigen, dass man Heim-Automation und XMPP prima verknüpfen kann. Die Hardware Grundlage bildet ein Raspberry Pi, 3 LEDs in den Ampelfarben sowie ein Taster als Eingang. Als Steuerprogramm haben wir uns für Node Red entschieden. Jedes gute Projekt braucht erst mal eine Skizze für die Hardwareverdrahtung: (Android) Telefon Softclients 2023-12-19T00:00:00+00:00 Diese Tabelle ist vom Stand 19.12.2023 und gibt meine persönlichen Erfahrung speziell in Bezug auf die Transport- und Gesprächsverschlüsselung wider. Den aktuellen Stand finde ich nicht sehr befriedigend. Mein aktueller Favorit ist Sipnetic, vom GUI her ist Zoiper klar vorne, aber für Verschlüsselung leider nur abgehend brauchbar. </blockquote> Clientname</th> Plattform</th> Tauglichkeit / Auffälligkeiten</th></tr></thead> Zoiper 2.22.3</td> Android</td> gut konfigurierbar, abgehende Gespräche funktionieren einwandfrei, ankommende Gespräche funktionieren gar nicht und werfen je nach Gegenseite unterschiedliche Fehlermeldungen. Sobald die Gesprächsverschlüsselung entfernt wird, funktionieren beide Richtungen.</td></tr> SessionTalk 6.1</td> Android</td> Funktioniert ankommend und abgehend ohne Probleme, GUI ist Geschmackssache</td></tr> Sipnetic/1.0.52</td> Android</td> Anfangs hatte die Registrierung genau 1x funktioniert, danach nicht mehr, warum weiß ich nicht. Derzeit funktioniert sie wieder und es funktionieren abgehende und ankommende Gespräche. Schickeres GUI als SessionTalk. Läuft sowohl auf Handy als auch auf Tablet. Manchmal werden Gespräche nicht als beendet erkannt. Gut: Man erkennt auf Anhieb die Transportverschlüsselung und während des Gesprächs die Gesprächsverschlüsselung</td></tr> LinPhone 5.1.4</td> Android</td> Trotz erfolgreichem Verbindungsaufbaus werden im Asterisk CLI Warnungen bzgl. des Zertifikat-Handshakes geworfen. GUI stark gewöhnungsbedürftig. Gut: In der rechten oberen Ecke sieht man während des Gesprächs, ob Verschlüsselung aktiviert ist</td></tr> baresip+</td> Android</td> hier ist mir die Konfiguration nicht gelungen</td></tr> </td> </td> </td></tr> </tbody></table>

XMPP spezifisch</h3>

XMPP Newbies - nicht nur für Neueinsteiger</a>, Sprachen: DE und EN</li> </ul>

WhatsApp</h4>
Die WhatsApp-Adressen sehen unter slidge in XMPP z. B. wie folgt aus: `+4915112341234@whatsapp.hot-chilli.im</code> Dabei ist der erste Teil die Telefonnummer des Kontaktes bei WhatsApp, der Teil nach dem "@" entspricht der Transport-Domain.</p>`

persönliches Fazit</h4>
Wenn es unumgänglich ist, mit bestimmten Kommunikationspartnern über die (proprietären) Netze zu kommunizieren, sind Transports ein gutes Mittel, um den Kontakt zu halten. Vorzuziehen wäre jedoch ein kompletter Umstieg auf das XMPP Netzwerk.</p>

Rainer's Blogseiten

Monocles Chat 2.x

OMEMO Verschlüsselung

XMPP Links

UnifiedPush via XMPP einrichten

Asterisk - Blindentelefon

Cheerlights 2.0

Demoautomat - Froscon 2025

Demoautomat - 2025

Monocles Chat 1.7.9

Asterisk - SMS

Browser Zugänge zu Hilfe-Chats

XMPP Gruppenchats

Uptime Kuma Benachrichtigungen via XMPP

Proxmox Benachrichtigungen via XMPP

Neuer Anker Wechselrichter

allgemeine XMPP Tricks

SMS2XMPP Gateway

Demoautomat - der Umzug

Asterisk - Konfig dt. Telekom

Asterisk - Konfig Sipgate

Vorstellung Asterisk

Einbindung in die Heimautomation

Speicher reintegriert

Solarmodule

Demoautomat - Rasppi Tausch

Balkonkraftwerk - Formalitäten

Anfangs Ertrag

Anfangsschwierigkeiten

Balkonkraftwerk - Start

Transports

Demoautomat - 2024

Demoautomat - Erweiterung I

Asterisk - Client Konfiguration

pjsip.conf</h3>

Demoautomat - der Start

(Android) Telefon Softclients

Clientname</strong></th>	Plattform</strong></th>	Tauglichkeit / Auffälligkeiten</strong></th></tr></thead>
Zoiper 2.22.3</td>	Android</td>	gut konfigurierbar, abgehende Gespräche funktionieren einwandfrei, ankommende Gespräche funktionieren gar nicht und werfen je nach Gegenseite unterschiedliche Fehlermeldungen. Sobald die Gesprächsverschlüsselung entfernt wird, funktionieren beide Richtungen.</td></tr>
SessionTalk 6.1</td>	Android</td>	Funktioniert ankommend und abgehend ohne Probleme, GUI ist Geschmackssache</td></tr>
Sipnetic/1.0.52</td>	Android</td>	Anfangs hatte die Registrierung genau 1x funktioniert, danach nicht mehr, warum weiß ich nicht. Derzeit funktioniert sie wieder und es funktionieren abgehende und ankommende Gespräche. Schickeres GUI als SessionTalk. Läuft sowohl auf Handy als auch auf Tablet. Manchmal werden Gespräche nicht als beendet erkannt. Gut: Man erkennt auf Anhieb die Transportverschlüsselung und während des Gesprächs die Gesprächsverschlüsselung</td></tr>
LinPhone 5.1.4</td>	Android</td>	Trotz erfolgreichem Verbindungsaufbaus werden im Asterisk CLI Warnungen bzgl. des Zertifikat-Handshakes geworfen. GUI stark gewöhnungsbedürftig. Gut: In der rechten oberen Ecke sieht man während des Gesprächs, ob Verschlüsselung aktiviert ist</td></tr>
baresip+</td>	Android</td>	hier ist mir die Konfiguration nicht gelungen</td></tr>
</td>	</td>	</td></tr> </tbody></table>

Rainer's Blogseiten

Monocles Chat 2.x

OMEMO Verschlüsselung

XMPP Links

UnifiedPush via XMPP einrichten

Asterisk - Blindentelefon

Cheerlights 2.0

Demoautomat - Froscon 2025

Demoautomat - 2025

Monocles Chat 1.7.9

Asterisk - SMS

Browser Zugänge zu Hilfe-Chats

XMPP Gruppenchats

XMPP spezifisch</h3> XMPP Newbies - nicht nur für Neueinsteiger</a>, Sprachen: DE und EN</li> </ul>

Uptime Kuma Benachrichtigungen via XMPP

Proxmox Benachrichtigungen via XMPP

Neuer Anker Wechselrichter

allgemeine XMPP Tricks

SMS2XMPP Gateway

Demoautomat - der Umzug

Asterisk - Konfig dt. Telekom

Asterisk - Konfig Sipgate

Vorstellung Asterisk

Einbindung in die Heimautomation

Speicher reintegriert

Solarmodule

Demoautomat - Rasppi Tausch

Balkonkraftwerk - Formalitäten

Anfangs Ertrag

Anfangsschwierigkeiten

Balkonkraftwerk - Start

Transports

Voraussetzungen</h3> ein Benutzerkonto des jeweiligen Netzes (z. B. Telegram)</li> ein (angemeldeter) Client des jeweiligen Zielnetzes</li>

WhatsApp</h4> Die WhatsApp-Adressen sehen unter slidge in XMPP z. B. wie folgt aus: +4915112341234@whatsapp.hot-chilli.im</code> Dabei ist der erste Teil die Telefonnummer des Kontaktes bei WhatsApp, der Teil nach dem "@" entspricht der Transport-Domain.</p>

persönliches Fazit</h4> Wenn es unumgänglich ist, mit bestimmten Kommunikationspartnern über die (proprietären) Netze zu kommunizieren, sind Transports ein gutes Mittel, um den Kontakt zu halten. Vorzuziehen wäre jedoch ein kompletter Umstieg auf das XMPP Netzwerk.</p>

Demoautomat - 2024

Demoautomat - Erweiterung I

Asterisk - Client Konfiguration

pjsip.conf</h3>

Demoautomat - der Start

(Android) Telefon Softclients

XMPP spezifisch</h3>

XMPP Newbies - nicht nur für Neueinsteiger</a>, Sprachen: DE und EN</li> </ul>

WhatsApp</h4>
Die WhatsApp-Adressen sehen unter slidge in XMPP z. B. wie folgt aus: `+4915112341234@whatsapp.hot-chilli.im</code> Dabei ist der erste Teil die Telefonnummer des Kontaktes bei WhatsApp, der Teil nach dem "@" entspricht der Transport-Domain.</p>`

persönliches Fazit</h4>
Wenn es unumgänglich ist, mit bestimmten Kommunikationspartnern über die (proprietären) Netze zu kommunizieren, sind Transports ein gutes Mittel, um den Kontakt zu halten. Vorzuziehen wäre jedoch ein kompletter Umstieg auf das XMPP Netzwerk.</p>