MQTT2-Module - Praxisbeispiele - Versionsgeschichte

TomLee: /* Einfache Payload */ Ersatzwert für unbekannte Werte ergänzt

2026-03-27T13:08:12Z

Einfache Payload: Ersatzwert für unbekannte Werte ergänzt

← Nächstältere Version		Version vom 27. März 2026, 15:08 Uhr
Zeile 686:		Zeile 686:
	Einen Wert mappen:		Einen Wert mappen:
	<pre>		<pre>
	attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}		attr DEVICE readingList <your topic>:.* {my %map=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}\|\|$EVENT}}
	</pre>		</pre>

Otto123: /* Autostart von sonos2mqtt mit FHEM */

2025-09-07T07:10:45Z

Autostart von sonos2mqtt mit FHEM

← Nächstältere Version		Version vom 7. September 2025, 09:10 Uhr
Zeile 452:		Zeile 452:

	==== Autostart von sonos2mqtt mit FHEM ====		==== Autostart von sonos2mqtt mit FHEM ====
	Der Code startet sowohl das ~~sonso2mqtt~~ Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.		Der Code startet sowohl das sonos2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.
	<syntaxhighlight lang="perl">		<syntaxhighlight lang="perl">
	define n_pm2_sonos notify global:INITIALIZED\|n_pm2_sonos:start "pm2 -s start sonos2mqtt"		define n_pm2_sonos notify global:INITIALIZED\|n_pm2_sonos:start "pm2 -s start sonos2mqtt"

TomLee: Beispiel ergänzt: numerische Werte runden

2024-11-15T14:15:30Z

Beispiel ergänzt: numerische Werte runden

← Nächstältere Version		Version vom 15. November 2024, 16:15 Uhr
Zeile 677:		Zeile 677:
	<pre>		<pre>
	attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }		attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }
			</pre>
			Numerische Werte zuvor runden :
			<pre>
			attr DEVICE readingList <your topic>:.* { my $h=json2nameValue($EVENT,'XXX');; map { $h->{$_}=round($h->{$_}) if(looks_like_number($h->{$_})) } keys %{$h};; $h }
	</pre>		</pre>

	~~Oder auch einen~~ Wert ~~umzubenennen wenn die JSON-Payload nur ein Objekt beinhaltet~~:		==== Einfache Payload ====
			Einen Wert mappen:
	<pre>		<pre>
	attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}		attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}

Beta-User: Typo korrigiert

2024-10-27T06:23:33Z

Typo korrigiert

← Nächstältere Version		Version vom 27. Oktober 2024, 08:23 Uhr
Zeile 637:		Zeile 637:
	=== bridgeRegexp ===		=== bridgeRegexp ===
	[[Datei:Mqtt2 server.png\|300px\|thumb\|left\|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz\|RNTyp=y\|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.		[[Datei:Mqtt2 server.png\|300px\|thumb\|left\|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz\|RNTyp=y\|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
	Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung\|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle ~~einem einem~~ MQTT2_DEVICE zugewiesen.		Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung\|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle ein und demselben MQTT2_DEVICE zugewiesen.

	=== Ständig neue Devices? ===		=== Ständig neue Devices? ===

Otto123: /* Setup im System */

2024-04-01T09:07:50Z

Setup im System

← Nächstältere Version		Version vom 1. April 2024, 11:07 Uhr
Zeile 379:		Zeile 379:
	Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.		Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.

	Eine Beschreibung aller Startparameter für sonos2mqtt findet man [https://svrooij.io/sonos2mqtt~~/getting-started.html~~ in der offiziellen Doku].		Eine Beschreibung aller Startparameter für sonos2mqtt findet man [https://svrooij.github.io/sonos2mqtt in der offiziellen Doku].

	Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!		Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!

Sailor: /* Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server */

2022-11-24T20:26:06Z

Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server

← Nächstältere Version		Version vom 24. November 2022, 22:26 Uhr
Zeile 549:		Zeile 549:
	Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag [[FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle]].		Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag [[FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle]].

	Die darin beschriebenen Dateien, das cacert.pem sowie den server~~-cert~~.p12 - Container müsst ihr nun an euer Mobiltelefon senden.		Die darin beschriebenen Dateien, das cacert.pem sowie den server.p12 - Container müsst ihr nun an euer Mobiltelefon senden.

	=== Definition in FHEM ===		=== Definition in FHEM ===
Zeile 598:		Zeile 598:
	** TLS aktivieren		** TLS aktivieren
	** CA-Zertifikat: cacert.pem		** CA-Zertifikat: cacert.pem
	** Client-Zertifikat: server~~-cert~~.p12		** Client-Zertifikat: server.p12
	** Passwort fuer Client-Zertifikat: Passwort für den server~~-cert~~.p12 - Container		** Passwort fuer Client-Zertifikat: Passwort für den server.p12 - Container

	Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.		Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.

Sailor: /* owntracks auf dem Smartphone konfigurieren */ Neue Anleitung fuer den internen - direkten Zugang

2022-11-24T20:11:06Z

owntracks auf dem Smartphone konfigurieren: Neue Anleitung fuer den internen - direkten Zugang

@@ Zeile 489: / Zeile 489: @@
 Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.
-== Owntracks GPS Tracking in FHEM ==
+== Owntracks GPS Tracking in FHEM über MQTT - Cloud ==
 Das hier gezeiget Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)
@@ Zeile 509: / Zeile 509: @@
 ** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
 ** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
-* Sicherheit -> TLS aktivieren
+* Sicherheit ->
 === Definition in FHEM ===
 Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.<syntaxhighlight lang="perl">
@@ Zeile 536: / Zeile 537: @@
 </syntaxhighlight>Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.
 == Allgemeine Hinweise ==
 === MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===

Beta-User: Milight: Klarstellung, dass die Hardware an sich funktional sein muss und nicht zwingend alles empfangen werden kann.

2022-07-19T13:57:06Z

Milight: Klarstellung, dass die Hardware an sich funktional sein muss und nicht zwingend alles empfangen werden kann.

← Nächstältere Version		Version vom 19. Juli 2022, 15:57 Uhr
Zeile 250:		Zeile 250:
	== Milight-Bridge ==		== Milight-Bridge ==
	=== Vorbemerkung ===		=== Vorbemerkung ===
	Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel.		Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel. Allerdings lassen sich manche MiLight-Geräte nicht an die Bridge anlernen, und es werden auch nicht alle Fernbedienungs-Typen voll unterstützt.
	Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.		Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
	Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist.		Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist und die zu steuernden Leuchtmittel mit dem Hub bereits verbunden (gepairt) sind bzw. entsprechende Fernbedienungs-Signale empfangen werden können (bei vorhandenem pairing eines Leuchtmittels an die Fernbedienung).
	Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.		Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

Otto123: /* Verwendung des Docker Containers */ Link zur Original Doku eingefügt

2022-04-09T11:36:25Z

Verwendung des Docker Containers: Link zur Original Doku eingefügt

← Nächstältere Version		Version vom 9. April 2022, 13:36 Uhr
Zeile 476:		Zeile 476:

	=== Verwendung des Docker Containers ===		=== Verwendung des Docker Containers ===
			Ergänzend zur [https://svrooij.io/sonos2mqtt/getting-started.html#run-sonos2mqtt-in-docker Original Doku:]

	Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:		Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:
	<syntaxhighlight lang="perl">		<syntaxhighlight lang="perl">

No Legend: /* pulseTime */ Workaround für Deaktivierung der PulseTime bei normalen Befehlen hinzu

2022-03-16T05:50:41Z

pulseTime: Workaround für Deaktivierung der PulseTime bei normalen Befehlen hinzu

← Nächstältere Version		Version vom 16. März 2022, 07:50 Uhr
Zeile 101:		Zeile 101:
	on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}		on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
	Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.		Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

			Da nach dem ersten pulseTime setzten, diese immer benutzt wird, kann man mit einem kleine Workaround das Device normal arbeiten lassen. Dafür wird bei jedem anderem Befehl, aus der PulseTime, der Timer deaktiviert.
			Hierfür machen wir uns zu nutzen, dass man mehrere Befehle gleichzeitig an Tasmota senden kann (backlog). Ob diese Lösung auch mit anderen MQTT Firmwares funktioniert, kann ich nicht sagen. Es wurde lediglich mit Tasmota getestet.
			Wir senden also, bevor wir den eigentlich Tasmota Befehl zum Ein- oder Ausschalten schicken, einen Befehl zum deaktivieren des Timers: "pulseTime 0"
			Hier ein Beispiel: (das entsprechende device "DEV_611F3E" muss gegen das eigene ersetzt werden)
			off:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 0
			on:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 1
			toggle:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 2

	=== zigbee2tasmota ===		=== zigbee2tasmota ===