Ruben hat geschrieben: ↑12. Nov 2021 21:40
Ok, an deiner Antwort merke ich wie viel mir noch an Wissen fehlt.
Wissen ist Macht, nichts wissen macht auch nichts...
Ruben hat geschrieben: ↑12. Nov 2021 21:40
das heißt, wir haben mit dem hochrutschen des Eintrages dem Mosquitto erlaubt auch über ein Socket zu kommunizieren und den Eintrag "Starting in local only mode. Connections will only be possible from clients running on this machine." damit umgangen.
Nein. Es ist schlicht so, dass der Eintrag offensichtlich zwingend oben in der Datei stehen muss. Ich könnnte mir vorstellen, dass die Konfigurationsdatei zeilenweise eingelesen wird und nach dem Einlesen der Zeile umgehend entsprechende Maßnahmen eingeleitet werden. Der listener kommt dann schlicht zu einem Zeitpunkt, wo es schon zu spät ist, diese Konfiguration anzupassen.
Das mit dem Socket hat nichts mit IP zu tun, das ist eine andere Kommunikationsform, so wie wenn Du statt ein Telefonat zu führen, einen Zettel auf den Küchentisch legst.
Ruben hat geschrieben: ↑12. Nov 2021 21:40
Jetzt können also alle dem Port zuhören?
Gilt das dann jetzt auch für das senden, also das entgegennehmen von Daten die von Geräten außerhalb des Pi kommen?
da der Eintrag listener 1883 soviel wie zuhörer bedeutet.
würde denken, dass nun alles funktionieren sollte?
Ja, wenn Du mit mqtt.fx eine Verbindung zum Broker herstellen kannst, ist diese auf jeden Fall bidirektional.
mqtt ist für m2m optimiert, mit der Ergänzung, dass auch Menschen beteiligt sein sollen (sonst könnte man ja einfach irgendwelche Bytes hin und her schicken). Der Client (alle mqtt Programme außer mosquitto) verbindet sich mit dem Broker (mosquitto ist der Broker). Der Client teilt mit, welche Topics er abonnieren will. Ist eines der Topics retained (das heißt, der Broker speichert das aktuelle Payload) so wird das Payload vom Broker an den Client gesendet. Der Broker führt eine Liste, in der vermerkt ist, welche Clients auf welche Topics abonniert sind. Sendet ein Client ein Payload auf ein Topic, prüft der Broker, an welche Clients er das Payload übertragen muss und tut das. Ist das Topic als retained gekennzeichnet, speichert der Broker das Payload in seiner Datenbank.
Die Kommunikation über mqtt ist also eine sehr simple Sache. Natürlich gibt es diverse Dinge, die das Leben komplizierter machen, man kann z.B. definieren, ob eine Message einfach so versendet wird oder ob der Broker sicherstellt, dass diese auch am Ziel eingetroffen ist. Letzteres ist naturgemäß wesentlich zeitaufwändiger als Ersteres. Weiterhin gibt es die Clientüberwachung. Der Broker prüft ständig die Verbindung zu allen Clients. Sobald eine Verbindung abreißt, sendet der Broker den letzten Willen des Clients aus (LWT, LastWill_and_Testament). Der Client setzt das LWT beim Verbindungsaufbau und beschreibt es anschließend mit einer anderen Payload. Also z.B. wird LWT auf Offline gesetzt und anschließend Online gesendet. Damit erhalten alle Clients, die dieses LWT Topic abonniert haben die Nachricht, dass der Client Online ist. Fährt der Client runter oder bricht der Kontakt ab, erfahren alle Clients, die das LWT abonniert haben umgehend, dass der Client nun Offline ist.
Das LWT ist natürlich auch nur ein Topic, der Name ist ebenso frei konfigurierbar wie sein Inhalt. LWT hat sich aber eingebürgert.
