MQTT Einführung - Versionsgeschichte

Beta-User: Kategorie ergänzt

2019-06-28T12:30:40Z

Kategorie ergänzt

← Nächstältere Version		Version vom 28. Juni 2019, 14:30 Uhr
Zeile 1:		Zeile 1:
	#WEITERLEITUNG [[MQTT]]		#WEITERLEITUNG [[MQTT]]
	[[Kategorie:MQTT\|~~Einführung_Teil_1~~]]		[[Kategorie:MQTT\|Einführung]]

Beta-User: Kategorie ergänzt

2019-06-28T12:30:01Z

Kategorie ergänzt

← Nächstältere Version		Version vom 28. Juni 2019, 14:30 Uhr
Zeile 1:		Zeile 1:
	#WEITERLEITUNG [[MQTT]]		#WEITERLEITUNG [[MQTT]]
	[[Kategorie:MQTT\|~~Einführung Teil 1~~]]		[[Kategorie:MQTT\|Einführung_Teil_1]]

Beta-User: Kategorie ergänzt

2019-06-28T12:29:12Z

Kategorie ergänzt

← Nächstältere Version		Version vom 28. Juni 2019, 14:29 Uhr
Zeile 1:		Zeile 1:
	#WEITERLEITUNG [[MQTT]]		#WEITERLEITUNG [[MQTT]]
	[[Kategorie:MQTT\|Einführung]]		[[Kategorie:MQTT\|Einführung Teil 1]]

Beta-User: Kategorie ergänzt

2019-06-28T12:28:39Z

Kategorie ergänzt

← Nächstältere Version		Version vom 28. Juni 2019, 14:28 Uhr
Zeile 1:		Zeile 1:
	#WEITERLEITUNG [[MQTT]]		#WEITERLEITUNG [[MQTT]]
			[[Kategorie:MQTT\|Einführung]]

Beta-User: Weiterleitung eingerichtet

2019-06-28T11:43:47Z

Weiterleitung eingerichtet

← Nächstältere Version		Version vom 28. Juni 2019, 13:43 Uhr
Zeile 1:		Zeile 1:
	#WEITERLEITUNG [[~~FHEM~~]]		#WEITERLEITUNG [[MQTT]]

Beta-User: Weiterleitung eingerichtet

2019-06-28T11:42:38Z

Weiterleitung eingerichtet

Änderungen zeigen

Beta-User: Teile von "MQTT" übernommen

2019-06-24T11:59:59Z

Teile von "MQTT" übernommen

Änderungen zeigen

Beta-User: Security-Hinweis eingefügt.

2019-06-24T09:50:59Z

Security-Hinweis eingefügt.

← Nächstältere Version		Version vom 24. Juni 2019, 11:50 Uhr
Zeile 6:		Zeile 6:
	Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.		Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

	Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher Broker genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass es die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den ~~Broker~~ vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt.		Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass es die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicehrung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

	Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:		Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:

Beta-User: Gerät und Device durch Teilnehmer ersetzt

2019-06-24T09:44:29Z

Gerät und Device durch Teilnehmer ersetzt

← Nächstältere Version		Version vom 24. Juni 2019, 11:44 Uhr
Zeile 6:		Zeile 6:
	Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.		Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

	Bei MQTT findet die nachrichtenbasierte Kommunikation ~~nur~~ zwischen ~~den Geräten~~ (~~Devices) auf~~ der einen ~~Seite und dem~~ MQTT-Server (Broker) ~~auf~~ der anderen ~~Seite statt. Die Geräte kommunizieren nicht direkt untereinander~~. Wenn also ein ~~Klient~~ (Client) Daten von einem bestimmten ~~Gerät~~ (~~Device~~) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass es die Nachrichten dieses ~~Gerätes (Devices)~~ abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den Broker vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt.		Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher Broker genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass es die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den Broker vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt.

	Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:		Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:

Beta-User: ClientID eingefügt

2019-06-24T08:57:51Z

ClientID eingefügt

← Nächstältere Version		Version vom 24. Juni 2019, 10:57 Uhr
Zeile 9:		Zeile 9:

	Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:		Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
			*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
	*Topic - das ist die Adresse des endgültigen Empfängers. Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.		*Topic - das ist die Adresse des endgültigen Empfängers. Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
	*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.		*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.