OpenMQTTGateway - Versionsgeschichte

DasQ: /* Links */ ergänzt

2024-03-15T15:10:41Z

Links: ergänzt

← Nächstältere Version		Version vom 15. März 2024, 17:10 Uhr
Zeile 78:		Zeile 78:
	== Links ==		== Links ==
	* {{Link2Forum\|Topic=103737\|LinkText=Thread zur Entwicklung der attrTemplate für MQTT2_DEVICE}}		* {{Link2Forum\|Topic=103737\|LinkText=Thread zur Entwicklung der attrTemplate für MQTT2_DEVICE}}
			* {{Link2Forum\|Topic=126366\|LinkText=OpenMQTTGateway support thread - im Speziellen: BT/BTLE}}

	== Hinweise ==		== Hinweise ==

Beta-User: Änderung im Hinlick auf die Integration der BT-reading- und setList im GW

2022-03-30T11:33:10Z

Änderung im Hinlick auf die Integration der BT-reading- und setList im GW

← Nächstältere Version		Version vom 30. März 2022, 13:33 Uhr
Zeile 1:		Zeile 1:
	~~{{Baustelle}}~~

	== Einführung ==		== Einführung ==
	[https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.		[https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.
Zeile 8:		Zeile 6:
	Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.		Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.

	Mit <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU</code> wird dieses Gerät als zentrales Empfangsgerät konfiguriert, das dann über die ''bridgeRegexp'' die eingehenden Informationen ~~(ggf.~~ nicht ~~nur~~ BTLE) jeweils in separate MQTT2_DEVICE-Instanzen verteilt.		Mit <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU</code> wird dieses Gerät als zentrales Empfangsgerät konfiguriert, das dann über die ''bridgeRegexp'' die eingehenden Informationen zu allem, was nicht BTLE ist jeweils in separate MQTT2_DEVICE-Instanzen verteilt.

	Erst wenn dieses Device konfiguriert wurde, werden weitere attrTemplate geladen, die dann im Folgenden Verwendung finden.		Erst wenn dieses Device konfiguriert wurde, werden weitere attrTemplate geladen, die dann im Folgenden Verwendung finden.

	== OpenMQTTGateway und BTLE ==		== OpenMQTTGateway und BTLE ==
	=== ~~oMQTTgw_BT~~ ===		=== OpenMQTTGateway_MCU ===
	Eine der genannten bridgeRegexp sorgt zunächst dafür, dass alle von irgendeinem OpenMQTTGwateway empfangenen BTLE-Informationen an ein weiteres zentrales Gerät weitergegeben werden, das als ClientID ''oMQTTgw_BT'' ~~erhält.~~		{{Hinweis\|Das ältere attrTemplate ''oMQTTgw_BT'' ist nicht mehr erforderlich!}}
	~~Dieses ist seinerseits ist auch nur eine Art Zwischen~~- oder ~~Sammeldevice. In ihm landen~~ einfach alle Infos, die ~~alle OMG~~ im Lauf eines Tages so einsammeln. Damit dies einigermaßen überschaubar bleibt, werden regelmäßig alle Readings (bis auf wenige Ausnahmen wie ''associatedWith'') gelöscht, die älter sind als 24 Stunden~~, wenn man das mit dem BT-scanner-attrTemplate konfiguriert~~ Dabei ~~hilft "scanner",~~ die ~~eingehenden Infos~~ so ~~vorzuverarbeiten~~, dass man ~~sieht~~, was eigentlich zusammengehört.		In diesem Device landen - sofern man keine whitelist- oder blacklist setzt - einfach alle BT-Infos, die das Gateway im Lauf eines Tages so einsammeln. Damit dies einigermaßen überschaubar bleibt, werden regelmäßig alle diesbezüglichen Readings (bis auf wenige Ausnahmen wie ''associatedWith'') gelöscht, die älter sind als 24 Stunden. Dabei werden die JSON-Daten so aufbereitet, dass man erkennen kann, was eigentlich jeweils mit einer bestimmten BT-Kennung zusammengehört.
	Daneben kann man eben ein paar BT-spezifische Befehle absetzen, ~~die nicht auf ein bestimmtes BT~~-~~Gerät bezogen sind, sondern auf das GW. Man könnte diesen Teil auch auf das MCU-attrTemplate "umziehen", dann aber optional, weil ja nicht alle OMG überhaupt~~ BT-~~Optionen haben müssen~~...		Daneben kann man eben ein paar BT-spezifische Befehle absetzen, insbesondere white- und blacklists anlegen oder direkte Befehle an einzelne BT-Geräte versenden (wie z.B. ein "SwitchBot"-Gerät)...
	~~MAn. sollte man jedenfalls so oder so auch dieses~~ "~~scanner~~"-~~Zwischendevice haben und die dortigen Readings ggf~~. ~~einfach im laufenden Betrieb ignorieren~~.

	Erst die weiteren (BT-) Geräte, die man dann (mit Hilfe ~~des scanners~~) erstellt, indem man mit dem passenden attrTemplate die BT-Adresse angibt, sind dann die eigentlichen Nutz-Devices. Anders als sonst bei MQTT2_DEVICE gewohnt, werden diese weiteren Instanzen von MQTT2_DEVICE nicht automatisch erstellt, sondern können nur halbautomatisiert erstellt werden, indem man das passende attrTemplate anwendet und diesem die passende BT-ID mitteilt.		Erst die weiteren (BT-) Geräte, die man dann (mit Hilfe der Readings am Gatewas) erstellt, indem man mit dem passenden attrTemplate die BT-Adresse angibt, sind dann die eigentlichen Nutz-Devices. Anders als sonst bei MQTT2_DEVICE gewohnt, werden diese weiteren Instanzen von MQTT2_DEVICE nicht automatisch erstellt, sondern können nur halbautomatisiert erstellt werden, indem man das passende attrTemplate anwendet und diesem die passende BT-ID mitteilt.

	Beispiel für z.B. einen ''MiFlora''-Sensor: <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor</code>		Beispiel für z.B. einen ''MiFlora''-Sensor: <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor</code>
	Es folgt die Anfrage der zum gewünschten Gerät gehörenden BT-ID; diese kann man den ~~Readings aus ''oMQTTgw_BT''~~ entnehmen. Entsprechend verfährt man für andere Geräte.		Es folgt die Anfrage der zum gewünschten Gerät gehörenden BT-ID; diese kann man den Reading am Gateway entnehmen. Entsprechend verfährt man für andere Geräte.

	=== Anwendungsbeispiele ===		=== Anwendungsbeispiele ===

Beta-User: BT-Thermostate ergänzt

2022-01-20T09:35:45Z

BT-Thermostate ergänzt

← Nächstältere Version		Version vom 20. Januar 2022, 11:35 Uhr
Zeile 25:		Zeile 25:

	=== Anwendungsbeispiele ===		=== Anwendungsbeispiele ===

			==== Temperatur und Luftfeuchtigkeit ====
			Es werden diverse Temperatur- und Luftfeuchtesensoren unterstützt, u.A. praktisch alle Xiaomi-Cleargrass und Mijia. Für die LYWSD03MMC kann dabei eine [https://github.com/pvvx/ATC_MiThermometer alternative Firmware] aufgespielt werden.

	==== Anwesenheitserkennung mit Gigaset Keeper G-Tag ====		==== Anwesenheitserkennung mit Gigaset Keeper G-Tag ====
	'''Zielsetzung:'''		'''Zielsetzung:'''
Zeile 86:		Zeile 90:
	[[Kategorie:Bluetooth]]		[[Kategorie:Bluetooth]]
	[[Kategorie:433MHz]]		[[Kategorie:433MHz]]
			[[Kategorie:Temperatursensoren]]

Beta-User: /* oMQTTgw_BT */

2021-11-15T08:08:34Z

oMQTTgw_BT

← Nächstältere Version		Version vom 15. November 2021, 10:08 Uhr
Zeile 15:		Zeile 15:
	=== oMQTTgw_BT ===		=== oMQTTgw_BT ===
	Eine der genannten bridgeRegexp sorgt zunächst dafür, dass alle von irgendeinem OpenMQTTGwateway empfangenen BTLE-Informationen an ein weiteres zentrales Gerät weitergegeben werden, das als ClientID ''oMQTTgw_BT'' erhält.		Eine der genannten bridgeRegexp sorgt zunächst dafür, dass alle von irgendeinem OpenMQTTGwateway empfangenen BTLE-Informationen an ein weiteres zentrales Gerät weitergegeben werden, das als ClientID ''oMQTTgw_BT'' erhält.
	Dieses ist seinerseits ist auch nur eine Art Zwischen- oder Sammeldevice. Da landen einfach alle Infos, die alle OMG im Lauf eines Tages so einsammeln, ~~alle 24h~~ werden alle Readings ~~_bis auf_~~ associatedWith gelöscht, wenn man das mit dem BT-scanner-attrTemplate konfiguriert ~~- weil sich sonst unendlich viel Müll ansammelt, den keiner braucht...~~ Dabei hilft "scanner", die eingehenden Infos so vorzuverarbeiten, dass man sieht, was eigentlich zusammengehört.		Dieses ist seinerseits ist auch nur eine Art Zwischen- oder Sammeldevice. In ihm landen einfach alle Infos, die alle OMG im Lauf eines Tages so einsammeln. Damit dies einigermaßen überschaubar bleibt, werden regelmäßig alle Readings (bis auf wenige Ausnahmen wie ''associatedWith'') gelöscht, die älter sind als 24 Stunden, wenn man das mit dem BT-scanner-attrTemplate konfiguriert Dabei hilft "scanner", die eingehenden Infos so vorzuverarbeiten, dass man sieht, was eigentlich zusammengehört.
	Daneben kann man eben ein paar BT-spezifische Befehle absetzen, die nicht auf ein bestimmtes BT-Gerät bezogen sind, sondern auf das GW. Man könnte diesen Teil auch auf das MCU-attrTemplate "umziehen", dann aber optional, weil ja nicht alle OMG überhaupt BT-Optionen haben müssen...		Daneben kann man eben ein paar BT-spezifische Befehle absetzen, die nicht auf ein bestimmtes BT-Gerät bezogen sind, sondern auf das GW. Man könnte diesen Teil auch auf das MCU-attrTemplate "umziehen", dann aber optional, weil ja nicht alle OMG überhaupt BT-Optionen haben müssen...
	MAn. sollte man jedenfalls so oder so auch dieses "scanner"-Zwischendevice haben und die dortigen Readings ggf. einfach im laufenden Betrieb ignorieren.		MAn. sollte man jedenfalls so oder so auch dieses "scanner"-Zwischendevice haben und die dortigen Readings ggf. einfach im laufenden Betrieb ignorieren.

Ph1959de: Ph1959de verschob die Seite OpenMQTTGateway-MQTT nach OpenMQTTGateway, ohne dabei eine Weiterleitung anzulegen: Redundante Info entfernt

2020-12-14T11:09:39Z

Ph1959de verschob die Seite OpenMQTTGateway-MQTT nach OpenMQTTGateway, ohne dabei eine Weiterleitung anzulegen: Redundante Info entfernt

← Nächstältere Version	Version vom 14. Dezember 2020, 13:09 Uhr
(kein Unterschied)

Beta-User: 433MHz-Abschnitt eingefügt

2020-12-14T08:59:51Z

433MHz-Abschnitt eingefügt

← Nächstältere Version		Version vom 14. Dezember 2020, 10:59 Uhr
Zeile 70:		Zeile 70:

	Damit sind auch alle nötigen Schritte erfolgt. Der Status der [[structure]] '''Anwesenheit''' kann dann für weitere Auswertungen genutzt werden.		Damit sind auch alle nötigen Schritte erfolgt. Der Status der [[structure]] '''Anwesenheit''' kann dann für weitere Auswertungen genutzt werden.

			== OpenMQTTGateway und 433MHz ==
			{{Link2Forum\|Topic=103737\|LinkText=Thread zur Verwendung als 433MHz-Interface}} mit ''rolling code''

Beta-User am 14. Dezember 2020 um 08:55 Uhr

2020-12-14T08:55:54Z

← Nächstältere Version		Version vom 14. Dezember 2020, 10:55 Uhr
Zeile 81:		Zeile 81:
	[[Kategorie:IP Components]]		[[Kategorie:IP Components]]
	[[Kategorie:MQTT]]		[[Kategorie:MQTT]]
			[[Kategorie:Bluetooth]]
			[[Kategorie:433MHz]]

Ph1959de: Nur Kleinigkeiten

2020-12-14T08:43:13Z

Nur Kleinigkeiten

← Nächstältere Version		Version vom 14. Dezember 2020, 10:43 Uhr
Zeile 4:		Zeile 4:
	[https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.		[https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.

	Setzt man einen ESP32 ein, genügt hierzu das blanke Board ohne Zusatzhardware, es kann eine vorkompilierte ~~firmware~~ geflasht werden (USB-Seriell-Wandler erforderlich).		Setzt man einen ESP32 ein, genügt hierzu das blanke Board ohne Zusatzhardware, es kann eine vorkompilierte Firmware geflasht werden (USB-Seriell-Wandler erforderlich).

	Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.		Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.
Zeile 32:		Zeile 32:

	===== Anlegen des OpenMQTTGateway in FHEM: =====		===== Anlegen des OpenMQTTGateway in FHEM: =====
	Via autocreate wie oben beschrieben oder manuell:		Via [[autocreate]] wie oben beschrieben oder manuell:
	defmod MQTT2_OpenMQTTGateway_ESP32_BLE MQTT2_DEVICE OpenMQTTGateway_ESP32_BLE		defmod MQTT2_OpenMQTTGateway_ESP32_BLE MQTT2_DEVICE OpenMQTTGateway_ESP32_BLE

Zeile 38:		Zeile 38:

	===== Anlegen der einzelnen G-Tags als MQTT2 Device =====		===== Anlegen der einzelnen G-Tags als MQTT2 Device =====

	Die zu verwendenden MAC-Adressen der G-Tags sollten bereits bekannt sein und werden ohne Trennzeichen angegeben. z.B. '''FFFFC424A123'''.		Die zu verwendenden MAC-Adressen der G-Tags sollten bereits bekannt sein und werden ohne Trennzeichen angegeben. z.B. '''FFFFC424A123'''.

Zeile 45:		Zeile 44:
	set MQTT2_OpenMQTTGateway_ESP32_BLE attrTemplate OpenMQTTGateway_BT_gtag <MAC Adresse>		set MQTT2_OpenMQTTGateway_ESP32_BLE attrTemplate OpenMQTTGateway_BT_gtag <MAC Adresse>

	Im Raum MQTT2_DEVICE taucht jetzt ein neues Device '' OMG_<MAC Adresse>'' auf. Diesem wurde per Template ein Temperatur Icon zugewiesen. Dieses kann leicht über ''Select icon'' am unteren Rand der Device-Übersicht geändert werden.		Im Raum MQTT2_DEVICE taucht jetzt ein neues Device ''OMG_<MAC Adresse>'' auf. Diesem wurde per Template ein Temperatur Icon zugewiesen. Dieses kann leicht über ''Select icon'' am unteren Rand der Device-Übersicht geändert werden, alternativ über die Attribute:
	~~Alternativ~~ über die Attribute:

	attr OMG_<MAC Adresse> icon gtag_kontur		attr OMG_<MAC Adresse> icon gtag_kontur

	Wem die Bezeichnung OMG_<Mac Adresse> zur unübersichtlich ist, kann das Device umbenennen oder über die Attribute auch ein ~~Alias~~ zuweisen.		Wem die Bezeichnung OMG_<Mac Adresse> zur unübersichtlich ist, kann das Device umbenennen oder über die Attribute auch ein alias zuweisen.

	===== Anlegen der Presence Devices =====		===== Anlegen der Presence Devices =====
Zeile 60:		Zeile 58:

	===== Zusammenfassen der einzelnen Anwesenheiten in einer ''structure'' =====		===== Zusammenfassen der einzelnen Anwesenheiten in einer ''structure'' =====
	Dies ist nur notwendig, sofern mehr als ein Tag verwendet wird. ~~[[Structure\|Zur Beschreibung von structure geht es hier lang.]]~~		Dies ist nur notwendig, sofern mehr als ein Tag verwendet wird.

	defmod Anwesenheit structure <identifier> <MAC Adresse 1>_presence <room> <MAC Adresse 2>_presence		defmod Anwesenheit structure <identifier> <MAC Adresse 1>_presence <room> <MAC Adresse 2>_presence

	''<identifier>'' ist ein Gruppierungsmerkmal unter dem die Anwesenheiten der Tags angelegt wurden.		''<identifier>'' ist ein Gruppierungsmerkmal, unter dem die Anwesenheiten der Tags angelegt wurden.

	Wichtig für die Funktion sind noch folgenden Attribute:		Wichtig für die Funktion sind noch folgenden Attribute:
Zeile 71:		Zeile 69:
	attr Anwesenheit clientstate_priority present absent		attr Anwesenheit clientstate_priority present absent

			Damit sind auch alle nötigen Schritte erfolgt. Der Status der [[structure]] '''Anwesenheit''' kann dann für weitere Auswertungen genutzt werden.
	Damit sind auch alle nötigen Schritte erfolgt. Der Status der structure '''Anwesenheit''' kann dann für weitere Auswertungen genutzt werden.




	== Links ==		== Links ==
	* {{Link2Forum\|Topic=103737\|LinkText=Thread zur Entwicklung der attrTemplate für MQTT2_DEVICE}}		* {{Link2Forum\|Topic=103737\|LinkText=Thread zur Entwicklung der attrTemplate für MQTT2_DEVICE}}

	== Hinweise ==		== Hinweise ==
	<references />		<references />

	[[Kategorie:Interfaces]]		[[Kategorie:Interfaces]]
	[[Kategorie:IP Components]]		[[Kategorie:IP Components]]
	[[Kategorie:MQTT]]		[[Kategorie:MQTT]]

Beta-User: erste Version

2020-12-13T20:44:02Z

erste Version

Neue Seite

{{Baustelle}}

== Einführung ==
[https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] ist eine firmware für ESP8266 bzw. ESP32, mit der sich neben verschiedenen Sensoren (BME280 u.a.) auch Infrarot- und 433MHz-Signale empfangen und senden lassen. In FHEM steht derzeit hauptsächlich die Auswertung diverser BLE-Geräte im Vordergrund.

Setzt man einen ESP32 ein, genügt hierzu das blanke Board ohne Zusatzhardware, es kann eine vorkompilierte firmware geflasht werden (USB-Seriell-Wandler erforderlich).

Sobald man die Zugangsdaten zum MQTT2_SERVER eingetragen hat, sollte ein entsprechendes MQTT2_DEVICE-Gerät automatisch erstellt werden.

Mit <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU</code> wird dieses Gerät als zentrales Empfangsgerät konfiguriert, das dann über die ''bridgeRegexp'' die eingehenden Informationen (ggf. nicht nur BTLE) jeweils in separate MQTT2_DEVICE-Instanzen verteilt.

Erst wenn dieses Device konfiguriert wurde, werden weitere attrTemplate geladen, die dann im Folgenden Verwendung finden.

== OpenMQTTGateway und BTLE ==
=== oMQTTgw_BT ===
Eine der genannten bridgeRegexp sorgt zunächst dafür, dass alle von irgendeinem OpenMQTTGwateway empfangenen BTLE-Informationen an ein weiteres zentrales Gerät weitergegeben werden, das als ClientID ''oMQTTgw_BT'' erhält.
Dieses ist seinerseits ist auch nur eine Art Zwischen- oder Sammeldevice. Da landen einfach alle Infos, die alle OMG im Lauf eines Tages so einsammeln, alle 24h werden alle Readings _bis auf_ associatedWith gelöscht, wenn man das mit dem BT-scanner-attrTemplate konfiguriert - weil sich sonst unendlich viel Müll ansammelt, den keiner braucht... Dabei hilft "scanner", die eingehenden Infos so vorzuverarbeiten, dass man sieht, was eigentlich zusammengehört.
Daneben kann man eben ein paar BT-spezifische Befehle absetzen, die nicht auf ein bestimmtes BT-Gerät bezogen sind, sondern auf das GW. Man könnte diesen Teil auch auf das MCU-attrTemplate "umziehen", dann aber optional, weil ja nicht alle OMG überhaupt BT-Optionen haben müssen...
MAn. sollte man jedenfalls so oder so auch dieses "scanner"-Zwischendevice haben und die dortigen Readings ggf. einfach im laufenden Betrieb ignorieren.

Erst die weiteren (BT-) Geräte, die man dann (mit Hilfe des scanners) erstellt, indem man mit dem passenden attrTemplate die BT-Adresse angibt, sind dann die eigentlichen Nutz-Devices. Anders als sonst bei MQTT2_DEVICE gewohnt, werden diese weiteren Instanzen von MQTT2_DEVICE nicht automatisch erstellt, sondern können nur halbautomatisiert erstellt werden, indem man das passende attrTemplate anwendet und diesem die passende BT-ID mitteilt.

Beispiel für z.B. einen ''MiFlora''-Sensor: <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor</code>
Es folgt die Anfrage der zum gewünschten Gerät gehörenden BT-ID; diese kann man den Readings aus ''oMQTTgw_BT'' entnehmen. Entsprechend verfährt man für andere Geräte.

=== Anwendungsbeispiele ===
==== Anwesenheitserkennung mit Gigaset Keeper G-Tag ====
'''Zielsetzung:'''

Die Anwesenheit von Gigaset Keeper Tags soll mittels [https://docs.openmqttgateway.com/ OpenMQTTGateway] erkannt werden.
Der Anwesenheitsstatus dieser Tags kann dann zur einem Status '''Anwesenheit''' zusammengefasst werden und für weitere Auswertungen genutzt werden.

===== Anlegen des OpenMQTTGateway in FHEM: =====
Via autocreate wie oben beschrieben oder manuell:
defmod MQTT2_OpenMQTTGateway_ESP32_BLE MQTT2_DEVICE OpenMQTTGateway_ESP32_BLE

''MQTT2_OpenMQTTGateway_ESP32_BLE'' ist hier der Name des MQTT2 Device und kann frei gewählt werden.

===== Anlegen der einzelnen G-Tags als MQTT2 Device =====

Die zu verwendenden MAC-Adressen der G-Tags sollten bereits bekannt sein und werden ohne Trennzeichen angegeben. z.B. '''FFFFC424A123'''.

Folgende Zeile wird für jeden einzelnen Tag ausgeführt.

set MQTT2_OpenMQTTGateway_ESP32_BLE attrTemplate OpenMQTTGateway_BT_gtag <MAC Adresse>

Im Raum MQTT2_DEVICE taucht jetzt ein neues Device '' OMG_<MAC Adresse>'' auf. Diesem wurde per Template ein Temperatur Icon zugewiesen. Dieses kann leicht über ''Select icon'' am unteren Rand der Device-Übersicht geändert werden.
Alternativ über die Attribute:

attr OMG_<MAC Adresse> icon gtag_kontur

Wem die Bezeichnung OMG_<Mac Adresse> zur unübersichtlich ist, kann das Device umbenennen oder über die Attribute auch ein Alias zuweisen.

===== Anlegen der Presence Devices =====
Folgende Zeile wird für jeden einzelnen Tag ausgeführt.

defmod <MAC Adresse>_presence PRESENCE function { my $maxage = AttrVal("OMG_<MAC Adresse>","maxPresenceAge","300");;;; ReadingsAge("OMG_<MAC Adresse>","last_IO","100000") < $maxage ? 1 : 0 }

Wichtig ist hier, dass der DEVICE_NAME angegeben wird, in diesem Fall ''OMG_<MAC Adresse>''.

===== Zusammenfassen der einzelnen Anwesenheiten in einer ''structure'' =====
Dies ist nur notwendig, sofern mehr als ein Tag verwendet wird. [[Structure|Zur Beschreibung von structure geht es hier lang.]]

defmod Anwesenheit structure <identifier> <MAC Adresse 1>_presence <room> <MAC Adresse 2>_presence

''<identifier>'' ist ein Gruppierungsmerkmal unter dem die Anwesenheiten der Tags angelegt wurden.

Wichtig für die Funktion sind noch folgenden Attribute:

attr Anwesenheit clientstate_behavior relative
attr Anwesenheit clientstate_priority present absent

Damit sind auch alle nötigen Schritte erfolgt. Der Status der structure '''Anwesenheit''' kann dann für weitere Auswertungen genutzt werden.

== Links ==
* {{Link2Forum|Topic=103737|LinkText=Thread zur Entwicklung der attrTemplate für MQTT2_DEVICE}}
== Hinweise ==
<references />
[[Kategorie:Interfaces]]
[[Kategorie:IP Components]]
[[Kategorie:MQTT]]