MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate)

[Beta-User]

Hallo zusammen,

nachdem sich (v.a.) in letzter Zeit die Anfragen gehäuft haben, die Titel trugen wie
- Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE (mit einer sehr guten Darstellung von @gadget im 2. Beitrag!)
- MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen
- Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone?
- Fhem von Android steuern mit MQTT
- Zwei FHEMs mit MQTT2 verbinden?
- Status Rücklesen Dummy (ebenfalls Loxone-Anbindung)
- Node-Red als Frontend (ok, der ist schon älter, aber jüngst wieder aufgegriffen worden)

haben Rudi, hexenmeister und meinereiner etwas an der MQTT_GENERIC_BRIDGE gebastelt, so dass zum einen die Zusammenarbeit mit MQTT2_CLIENT und MQTT2_SERVER mit diesem Querschnittsmodul verbessert wird, zum anderen hat hexenmeister auch die Anregung aufgegriffen, AttrTemplate-support einzubauen.

Viele werden attrTemplate vermutlich schon von MQTT2_DEVICE oder einem der anderen Module her kennen, die das supporten.

Der Grundgedanke von AttrTemplate ist der, (sinnvolle) Vorschläge für die Konfiguration von Devices zu machen, um damit v.a. den Usern das Leben zu erleichtern, die sich nicht unbedingt vertieft mit jedem Modul und/oder jeder Untiefe diverser firmwares (oder externer Dienste) auseinandersetzen wollen.

In diesem Thread hier soll es daher darum gehen, gewisse - v.a. auch aus Sicht der bisherigen Nutzer der MQTT_GENERIC_BRIDGE sinnvolle - Standards so in attrTemplate-Form zu gießen, dass nachfolgende Generationen von Usern es einfacher haben. Ergo baue ich auch auf die Rückmeldung derjenigen, die hier Erfahrung haben - ich habe die nämlich z.B. nicht, was die optimale Übergabe von Daten an Abnehmer wie Homeassistant oder NodeRed angeht.

Gerade die zu Beginn des NodeRed-Thread zu findende "SYS_MQTT"-notify-Lösung scheint eine Art "Ur-Vater" vieler  Klone zu sein, der nach wie vor in den Weiten des Internets zu finden sind, obwohl vermutlich alle der damals Beteiligten zwischenzeitlich die deutlich sichere Lösung MQTT_GENERIC_BRIDGE verwenden... 

Wie dem auch sei:

Ziel ist es, einen Satz attrTemplate als eine sinnvolle Möglichkeit anzubieten. Dass man alles auch immer irgendwie anders machen kann, steht dabei außer Frage, niemand MUSS es so machen, und optimalerweise ist das ganze so aufgebaut, dass jeder User es auf einfache Weise auf seine Bedürfnisse anpassen kann, falls er das für erforderlich ansieht.

Im Moment scheinen mir folgende Dinge sinnvoll bzw. notwendig:
- Es muss verschiedene Topics für die Sende- und Empfangsrichtung geben;
- Der Device-Name in FHEM sollte im Topic auftauchen.

Beides kann man dadurch bewerkstelligen, indem man in dem MQTT_GENERIC_BRIDGE-Device globale Einstellungen vornimmt, z.B.:

Code: [Auswählen]

attr <mqtt_generic_bridge-devicename> globalDefaults sub:base={"FHEM/MQTT_2FHEM/$device"} pub:base={"FHEM/FHEM_2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0

Code: [Auswählen]

attr <mqtt_generic_bridge-devicename> globalDefaults sub:base={"FHEM/set2FHEM/$device"} pub:base={"FHEM/$device"} pub:qos=0 sub:qos=2 retain=0

Code: [Auswählen]

attr myMGB globalDefaults sub:base={"myMGB/command/$device"} pub:base={"myMGB/$device"} pub:qos=0 sub:qos=2 retain=0Damit stellen sich die ersten Fragen:
- Soll $device über globalDefaults/base in den Topic vercoded werden, oder soll das erst in den einzelnen Devices der Fall sein (und damit dort ggf. der Gesamt-Topic leichter anzupassen sein)
- sollte der Name der MQTT_GENERIC_BRIDGE (per default) im Topic auftauchen oder nicht?
- soll es einen Topic-Anteil für die Senderichtung geben, der "fromFHEM" signalisiert, oder reicht für den Status jeweils der kurze Topic...

Damit das ganze nicht zu akademisch wird, anbei auch eine attrTemplate-File für die, die das ausprobieren wollen.

Da oft zu lesen ist "ich will einfach alle Readings in MQTT haben", gibt's dafür (unabhängig von meinen persönlichen Vorbehalten gegenüber solchen pauschalen Vorgehensweisen) auch ein attrTemplate, das das (auf Einzel-Device-Basis!) erledigt. Das attrTemplate fragt dann nach dem Device-Namen (devspec sollte möglich sein), von dem man alle Readings nach MQTT bringen will, wenn man an der MQTT_GENERIC_BRIDGE folgenden Befehl absetzt:

Code: [Auswählen]

set myMGB attrTemplate mgb_send_all_readings
Dazu (vorläufig) die .template aus dem Anhang laden und (mit den passenden Rechten!) unter fhem/FHEM/lib/AttrTemplate abspeichern. (In FHEMWEB) dann diesen Befehl absetzen:

Code: [Auswählen]

{AttrTemplate_Initialize()}
In der mittleren Perspektive wäre dann zu klären, wie man bestimmte Dinge ggf. vereinheitlicht, so dass z.B. verschiedene Heizkörper-Thermostate dann via MQTT sich "gleich anfühlen", wenn man sie über diesen Weg nach MQTT bringt. Wer Popcorn liebt, kann dazu hier schon was nachlesen bzw. ggf. auch (als Tester) Vorschläge machen: DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module.

Wer sich erst orientieren muss: Es gibt einen sehr guten Thread mit vielen Beispielen von hexenmeister. Wer sich neu einarbeiten will, sollte hier eigentlich schon mal viel "Baumaterial" finden.

Bin dann mal auf eure Rückmeldungen gespannt!

Grüße, Beta-User

PS: in der via svn verteilten attrTemplate-File "general_use" sind noch ein paar Vorläuferversionen drin. Die bitte löschen, sonst kommt das in Konflikt; dazu kann auch das 2. file aus dem Anhang verwendet werden...

[OiledAmoeba]

Moin,

kommt gerade recht. Ich habe gerade dieses Jahr mit HomeAssistant angefangen. Keine Angst, ich bleibe FHEM treu. Kein anderes System ist (mMn) auch nur annähernd so leistungsfähig. Außerdem liebe ich Konsole (ich bin pervers, ich weiß ;-))
Mir meiner Frau gefällt aber der WAF beim "Klicki-Bunti"-HomeAssistant besser.

FHEM läuft bei mir auf mehreren Servern, benannt als "fhem-" und dann das letzte Oktett der IPv4 (ohne führende Null). Also z.b. fhem-88 oder fhem-45. Das habe ich auch als "base" gesetzt, so finde ich die Entität in HA schnell wieder. Anschließend sende ich den FHEM-Devicenamen. Unter diesem Namen lege ich auch das Device in HA an.

Das Badezimmerfenster auf Server 88 sendet open/closed also unter dem Topic "fhem-88/bz_Fenster/state". Für den WAF wird in HA über customize: aus binary_sensor.bz_Fenster dann das Badezimmerfenster.
Rückmeldungen kommen unter "homeassistant/$device/$name". Darauf hören alle FHEMs und picken sich dann die Nachrichten raus, die für sie sind.

In der FHEM-Bridge habe ich dafür also eine vierte Version:

Code: [Auswählen]

attr mqtt globalDefaults sub:base={"homeassistant/$device"} pub:base={"fhem-88/$device"} pub:qos=0 sub:qos=2 retain=0So spare ich mir den Unterschlüssel "command". Sind nur ein paar Bytes, aber immerhin ;-)

Aus meiner Sicht erscheint mir dieser Aufbau logisch. Wobei ich gerade überlege, ob es Sinn macht, die Rückmeldungen noch auf verschiedene base-Namen zu teilen, so dass jedes FHEM nur auf "sein" Topic reagiert, aber die Rechenzeitersparnis zum Filtern steht sicherlich nicht in einem sinnvollen Verhältnis zum zu erwartenden manuellen Aufwand...

[Beta-User]

Danke für deine Rückmeldung, das hat mir schon mal in ein paar Punkten weitergeholfen!

Ziehe daraus mal folgende Schlüsse:
1. Auf den Gedanken, $device in den global defaults abzuhandeln scheinen noch mehr Leute gekommen zu sein, ebenso auf die Idee, da gleich pub und sub für $base zu splitten;
2. Das ganze sollte von der Topic-Struktur her eher kurz gefasst sein, auf unnötige Zeichen kann man auch gut verzichten;
3. "command" scheint nicht zu gefallen;
4. "FHEM" als hartvercodetes Element ist ggf. irgendwie Ballast, das sollte irgendwie "dynamischer" sein.

ad 1.
Das hake ich dann erst mal ab, falls sich nicht noch jemand mit guten Argumenten zu Wort meldet .

ad 3.
Von daher tendiere ich jetzt dazu, da schlicht ein "set" in den Topic einzubauen. Das hat auch den weiteren Vorteil, dass es vermutlich für Neueinsteiger intuitiver zu verstehen ist, wie die Topics dann auf der anderen Seite zusammenzubauen sind, außerdem dürfte es für die einfacher umzubauen sein, die heute dieses SYS_MQTT (z.B. von Loxone aus) verwenden, weil man dann dort einfach nur ein paar kleinere Änderungen an Topic/payload beim publish ändern muss.

ad 2.
MAn. braucht man eigentlich gar keinen separaten "/state"-Pfad, diesen Teil kann man sich also streng genommen auch sparen.

ad 4.
Dynamisch (ohne Abfrage) kann man es machen, wenn man den Namen der MQTT_GENERIC_BRIDGE nimmt. Die ist jedenfalls innerhalb einer Installation eindeutig.

Da auf diese Weise sowieso (fast) alles änderbar ist, ist das auch kein Problem, wenn jemand Doppelungen im Namen bei mehreren Installationen hätte, er kann das ja (einmalig) an zentraler Stelle ändern, und wenn die ersten Schritte gemacht sind, ist es vermutlich auch einigermaßen nachvollziehbar, wie alles zusammenhängt.

Ergo habe ich jetzt eine Version ins svn geschubst, die ganz schlicht folgendes macht:

Code: [Auswählen]

attr DEVICE globalDefaults sub:base={"DEVICE/set/$device"} pub:base={"DEVICE/$device"} pub:qos=0 sub:qos=2 retain=0DEVICE wird - wie üblich - durch den Namen der aufrufenden Instanz ersetzt, also der MQTT_GENERIC_BRIDGE. Dann käme in diesem Beispiel ("-" geht nicht als Device-Name):

Code: [Auswählen]

defmod fhem_88 MQTT_GENERIC_BRIDGE
attr fhem_88 globalDefaults sub:base={"fhem_88/set/$device"} pub:base={"fhem_88/$device"} pub:qos=0 sub:qos=2 retain=0
Dabei war der Gedanke, dass typischerweise die Kommandos an FHEM (deutlich) seltener sind als Infos über Änderungen an Readings.

Kommt ab morgen per update, bzw. wer heute noch Testen und Rückmeldung geben will, bekommt die aktuellen Versionen via:

Code: [Auswählen]

{ Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template") }
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) }
EDIT: Formatierung

[ToKa]

Hallo zusammen,

ich nutze MGB um Daten vom meinem PI mit fhem (SCADA) auf meine zweite Instanz von fhem (smarthome) mit MD2 zur Darstellung weiterzugeben und umgekehrt Steuerbefehle zu senden.

Dazu sieht meine Konfiguration wie folgt aus:

Code: [Auswählen]

attr ZS_zs_CO_MQTT_Generic_Bridge globalDefaults retain=1 base=scada/haus sysbase=scada/sys remoteBase=smarthome/haus
attr ZS_zs_CO_MQTT_Generic_Bridge globalPublish *:resendOnConnect=last

Für mein Zwave Eurotronic Spirits sind dann folgende Attribute gepflegt:

Code: [Auswählen]

attr E4_az_THKV_Heizkoerper_Wand mqttDefaults floorID={substr $device,0,2} roomID={substr $device,3,2} devName={substr $device,6}
attr E4_az_THKV_Heizkoerper_Wand mqttForward none
attr E4_az_THKV_Heizkoerper_Wand mqttPublish desired-temp|temperature|setpointTemp|reportedState|thermostatMode|battery|batteryPercent|batteryState|lastActivity:topic={"$base/$floorID/$roomID/$devName/$reading"}
attr E4_az_THKV_Heizkoerper_Wand mqttSubscribe thermostatSetpointSet:stopic={"$remoteBase/$floorID/$roomID/$devName/desired-temp"}\
state:stopic={"$remoteBase/$floorID/$roomID/$devName/cmd"}

lastActivity ist ein Userreading, über das ich ermittle, welche Aktion zuletzt ausgelöst wurde (Temperatur, Ventil,...)

für eine Zwave Qubino (Goap) ZMNHADx Flush 1 Relay zur Steuerung eines Wandspots sind folgende Attribute gepflegt:

Code: [Auswählen]

attr E1_fl_US_Wandspot mqttDefaults floorID={substr $device,0,2} roomID={substr $device,3,2} devName={substr $device,6}
attr E1_fl_US_Wandspot mqttForward none
attr E1_fl_US_Wandspot mqttPublish energy|power|reportedState|state:topic={"$base/$floorID/$roomID/$devName/$reading"}
attr E1_fl_US_Wandspot mqttSubscribe state:stopic={"$remoteBase/$floorID/$roomID/$devName/cmd"}

Meine Fibaro Steckdosen und anderen Leuchten sehen ähnlich aus.

Viele Grüße
Torsten

[Beta-User]

 
Das Thema scheint ja doch einige zu interessieren...

Danke auch für diese Rückmeldung!

Fragen/Anmerkungen von meiner Seite dazu:
Die Kombination

Code: [Auswählen]

attr ZS_zs_CO_MQTT_Generic_Bridge globalDefaults retain=1 [...]
attr ZS_zs_CO_MQTT_Generic_Bridge globalPublish *:resendOnConnect=last
dürfte wohl der "eigentliche default" aller derjenigen sein, die sich "nur gelegentlich" mit dem "externen Client-System" auf den MQTT-Server aufschalten (auch wenn es hier ein weiteres FHEM ist).
Werde das mal im Hinterkopf behalten und ggf. als per RADIO-option auswählbares setting anbieten (anstatt "retain=0").

Was mich im Moment noch zögern läßt: Meinem Bauchgefühl nach wären diese Settings unpassend, wenn sie auf der Gegenseite zu finden sind, Anweisungen sollte man ggf. mit dem richtigen QoS-Level versenden, aber nie mit retain-flag (wir hatten hier einige wenige Fälle, wo dann der Rollladen nachts hoch ist, weil mosquitto oder FHEM neu gestartet ist).

Weitere Rückmeldungen wären also hilfreich...

Ansonsten sind die Bridge-Defaults ähnlich, nur dass eben pup:/sub: hier auf einer anderen Ebene auseinanderdividiert werden.
@ToKa: Würdest du zustimmen, wenn ich den Teil als "Geschmacksfrage" interpretiere?
(dort, wo man die in den Beispielen nicht genutzte "sysbase" braucht, könnte man es auch direkt dort hinschreiben?).

Was den Spirit angeht, ist der (wie manches andere ZWave-Device) "speziell"; ich würde das ggf. nochmal separat aufgreifen, aber dazu neigen, nur das "setpointTemp" noch mit einem pub:-Ausdruck nach desired-temp (also in Senderichtung) zu mappen, dann ist es egal, was am ZWDongle eingestellt ist (?, und: Wer kein ZWave hat, sollte das überlesen...).

Das "mqttForward none" werde ich mir nochmal gesondert ansehen müssen, bei meinen ersten Spirit-Tests hatte ich eigentlich den Eindruck, dass man es auf dem default lassen könnte (all). Kann aber auch sein, dass das damit zusammenhängt, dass ich nur temperature und desired-temp ausgewählt hatte, aber bei dem anderen machst du das ja auch so:

Code: [Auswählen]

attr E4_az_THKV_Heizkoerper_Wand mqttForward none
attr E1_fl_US_Wandspot mqttForward none
Was mich noch interessieren würde. Mit

Code: [Auswählen]

attr E4_az_THKV_Heizkoerper_Wand mqttDefaults floorID={substr $device,0,2} roomID={substr $device,3,2} devName={substr $device,6}
attr E4_az_THKV_Heizkoerper_Wand mqttPublish [...]:topic={"$base/$floorID/$roomID/$devName/$reading"}
baust du ja einen sauber nach Etagen,  Räumen etc. aufgegliederten Topic zusammen.
Wenn man sich das dann mit einem "normalen Client" ansieht, ist das hilfreich, weil man dann mit MQTT-wildcards z.B. nur den Traffic für einen bestimmten Raum ansehen kann, um ihn zu analysieren.

Für FHEM/M2D ist das eigentlich völlig egal.

ABER: findet sich der $device-Teil schon in $base, kann man das später deutlich schlechter in diese Richtung umbauen.
Neige daher dazu, das zum Anlass zu nehmen und $device dann doch erst in den Attributen bei den einzelnen Devices einzubauen und aus der globalen Einstellung aus.

(EDIT: direkt erledigt)

Oder würdest du dir diesen Zusatzaufwand heute schenken?

Auch hier wären wieder Meinungen gefragt...

[rudolfkoenig]

Anweisungen sollte man ggf. mit dem richtigen QoS-Level versenden, aber nie mit retain-flag

Meine Meinung:
- retain sollte man gruendlich ueberlegen: zusaetzlich zu merkwuerdigen Nebeneffekten ist es auch eine Performance-Bremse. Der MQTT Server muss alle Nachrichten abspeichern, und alle neuen Verbindungen bekommen diese Daten erzaehlt (was zu den Nebeneffekten fuehrt).
- QoS:1 ist im Zusammenhang mit UDP sinnvoll (UDP wird von keinem der MQTT-FHEM-Module unterstuetzt), TCP liefert einem die gleiche Funktionalitaet auch mit QoS:0. QoS:2 ist noetig, wenn die MQTT Nachrichten Teil einer Transaktion sind, mit FHEM geht sowas nicht.

[Beta-User]

Hmm, Danke für die Rückmeldung.

Die technischen Hintergründe sind terra incognita für mich, macht aber nichts; werde das dann für den nächsten update ganz ohne Aussagen dazu so vormerken:

Code: [Auswählen]

attr DEVICE globalDefaults sub:base={"DEVICE/set"} pub:base={"DEVICE"}
Wird vermutlich einige geben, die unbedingt (auch an der falschen Stelle) retain haben wollen, aber hier geht es ja um "gute Praxis", und da bin ich auch der Meinung, dass weniger an der Stelle mehr ist. Von daher wird es auch eher keine RADIO-option geben, um das anzuschalten.

[OT] Ich habe mir jetzt mal die hier genannte Quelle reingezogen und auch die Doku bei loxberry, die dann da am Ende auch verlinkt ist.

Der einzige Grund, warum ich versuche das Modul MQTT zu installieren ist, dass hier ebenfalls verwendet wird.

Meine Befürchtung: Solange von Einsteigern versucht wird, diese Art Anleitung nachzubauen, werden wir hier das zweifelhafte Vergnügen haben, immer wieder zu erklären, dass andere Wege eigentlich besser wären...

Meine Bitte (v.a. an eventuell mitlesende Loxone-User): Es wäre nett, wenn ihr dafür sorgen würdet, dass der Autor dieses Blog-Beitrags (bzw. auch der Wiki-Artikel@Loxone) ggf. mal hier vorbeischaut (oder ggf. auf andere Weise Kontakt aufnimmt), damit wir das gemeinsam auf einen sichereren, aber weiterhin einsteigerfreundlichen Weg bringen können?
Erst danach kann man ihm ernsthaft den Vorwurf machen, dass es unverantwortlich ist, in 2021 noch Lösungen zu bewerben, die er mal mit Stand 2017 hier aus dem Forum geholt hat...

Danke schonmal,
[/OT]

Beta-User

[OiledAmoeba]

Moin,

ich quote mal nicht, wäre eh ein Fullquote ;-)

Zu retain bin ich voll bei Rudi. Spontan fällt mir da wirklich nur Connect/Disconnect/LastWill des Brokers als wirklich sinnvolle Anwendung ein. Oder vielleicht noch Sicherheits-IoT wie "Rauchmelder zuletzt ausgelöst"

@Rudi: Wie meinst Du das mit QoS bei FHEM in deinem letzten Satz? Soll das heißen, dass die gesamte mqtt-Kommunikation in FHEM (durch den TCP-Stack) quasi mit QoS:1 läuft? (Quasi, weil kein Acknowledgement durch mqtt, dafür aber Transportsicherheit durch TCP)
Ist QoS:2 (senden/empfangen) gar nicht möglich? Das /könnte/ dann ja im schlimmsten Fall dazu führen, dass ein Counter mehrfach zählt oder ein CUL zuviele Sendeaufträge bekommt...

[rudolfkoenig]

MQTT2 implementiert QoS:0 und QoS:1 (PUBACK), QoS:2 Nachrichten (PUBREC, PUBREL, PUBCOMP) werden als "Unhandled packet" protokolliert, und die Verbindung wird geschlossen.

[Beta-User]

Hmm, soweit ich den Code verstehe, macht das 00_MQTT.pm anders (#585ff).

Hat das Nebenwirkungen mit dem Schließen der Verbindung? (Vermutlich mind. Log-Einträge)...

Falls da Handlungsbedarf besteht, sollten wir das ggf. in dem anderen Thread mit hexenmeister klären. Oder werfen die M2-IO's sowieso derartige, aus ihrer Sicht überflüssige Dinge aus dem publish und man muss "nur" irgendwo (wo?) darauf hinweisen? (Es scheint ja user zu geben, die es genau wissen wollen, und für die wäre es ggf. dann wichtig zu wissen, dass sie besser 00_MQTT.pm verwenden sollten...?)

[ToKa]

Fragen/Anmerkungen von meiner Seite dazu:
Die Kombination

Code: [Auswählen]

attr ZS_zs_CO_MQTT_Generic_Bridge globalDefaults retain=1 [...]
attr ZS_zs_CO_MQTT_Generic_Bridge globalPublish *:resendOnConnect=last
dürfte wohl der "eigentliche default" aller derjenigen sein, die sich "nur gelegentlich" mit dem "externen Client-System" auf den MQTT-Server aufschalten (auch wenn es hier ein weiteres FHEM ist).
Werde das mal im Hinterkopf behalten und ggf. als per RADIO-option auswählbares setting anbieten (anstatt "retain=0").

Was mich im Moment noch zögern läßt: Meinem Bauchgefühl nach wären diese Settings unpassend, wenn sie auf der Gegenseite zu finden sind, Anweisungen sollte man ggf. mit dem richtigen QoS-Level versenden, aber nie mit retain-flag (wir hatten hier einige wenige Fälle, wo dann der Rollladen nachts hoch ist, weil mosquitto oder FHEM neu gestartet ist).

Mein SCADA System ist das führende System, hier wird alles gemessen (z.B. Temperatur) und die gültigen Zustände (z.B. Lampe aus) gespeichert, deshalb retain=1.

Danke für den Hinweis mit qos - hatte ich so bislang nicht auf dem Radar.

Ansonsten sind die Bridge-Defaults ähnlich, nur dass eben pup:/sub: hier auf einer anderen Ebene auseinanderdividiert werden.
@ToKa: Würdest du zustimmen, wenn ich den Teil als "Geschmacksfrage" interpretiere?
(dort, wo man die in den Beispielen nicht genutzte "sysbase" braucht, könnte man es auch direkt dort hinschreiben?).

Ja, stimme Dir zu.

Das "mqttForward none" werde ich mir nochmal gesondert ansehen müssen, bei meinen ersten Spirit-Tests hatte ich eigentlich den Eindruck, dass man es auf dem default lassen könnte (all). Kann aber auch sein, dass das damit zusammenhängt, dass ich nur temperature und desired-temp ausgewählt hatte, aber bei dem anderen machst du das ja auch so:

Code: [Auswählen]

attr E4_az_THKV_Heizkoerper_Wand mqttForward none
attr E1_fl_US_Wandspot mqttForward none

Ich hatte anfänglich ohne "none" ein Ping Pong zwischen den Systemen. So funktioniert es jedenfalls für mich ohne Probleme.

Was mich noch interessieren würde. Mit

Code: [Auswählen]

attr E4_az_THKV_Heizkoerper_Wand mqttDefaults floorID={substr $device,0,2} roomID={substr $device,3,2} devName={substr $device,6}
attr E4_az_THKV_Heizkoerper_Wand mqttPublish [...]:topic={"$base/$floorID/$roomID/$devName/$reading"}
baust du ja einen sauber nach Etagen,  Räumen etc. aufgegliederten Topic zusammen.
Wenn man sich das dann mit einem "normalen Client" ansieht, ist das hilfreich, weil man dann mit MQTT-wildcards z.B. nur den Traffic für einen bestimmten Raum ansehen kann, um ihn zu analysieren.

Für FHEM/M2D ist das eigentlich völlig egal.

ABER: findet sich der $device-Teil schon in $base, kann man das später deutlich schlechter in diese Richtung umbauen.
Neige daher dazu, das zum Anlass zu nehmen und $device dann doch erst in den Attributen bei den einzelnen Devices einzubauen und aus der globalen Einstellung aus.

Oder würdest du dir diesen Zusatzaufwand heute schenken?

Diese Lösung ist für mich am übersichtlichsten, da auch meine Devicenamen diesem Schema folgen und somit die Zuordnung immer direkt erkennbar ist. Der Aufwand ist ja fast einmalig und über copy/paste leicht zu übertragen. Wenn das über ein Template käme, sogar geschenkt

Viel Grüße
Torsten

[ToKa]

MQTT2 implementiert QoS:0 und QoS:1 (PUBACK), QoS:2 Nachrichten (PUBREC, PUBREL, PUBCOMP) werden als "Unhandled packet" protokolliert, und die Verbindung wird geschlossen.

Jetzt verwirrt Ihr mich aber mit qos... Laut Doku unterstützt M2C qos ≤ 1 und MGB qos ≤ 2.

Ich habe einen mosquitto als Broker zwischen den fhem Instanzen, aber es bringt ja dann nichts qos in fhem zu benutzen.

Bei retain muss ich halt schon wissen, was ich will und tue. Mit dem mosquitto habe ich keine Performance Probleme.

[herr.vorragend]

Werden bei euch die Templates eigentlich hinter "set xyz attrTemplate" als Dropdown angezeigt?
Das devspec-Filter (filter:TYPE=MQTT_GENERIC_BRIDGE) sollte eigentlich ja passen. Also TYPE ist ein MGB. Aber ist habe dort nur ein leeres Textfeld.

[hexenmeister]

Werden bei euch die Templates eigentlich hinter "set xyz attrTemplate" als Dropdown angezeigt?

Nö, bei mir auch nicht

[Beta-User]

Sorry, da hatte ich gestern eine nicht Linux-Zeilenumbruch-konforme Version eingecheckt.

Seit eben ist eine im svn, bei der zum einen das weg ist und dann auch qos nicht gestetzt.

Bekommt man ab sofort mit

Code: [Auswählen]

{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", "FHEM/lib/AttrTemplate/mqtt_generic_bridge.template", sub(){ AttrTemplate_Initialize() }) }Und ab morgen per update.
@ToKa:

Wg. des pinpong: Welcher GW-Type war das? Die sub/pub-topics waren da vermutlich auch schon unterschiedlich, oder?

(zum Rest vermutlich später)