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 (https://forum.fhem.de/index.php/topic,115279.0.html) (mit einer sehr guten Darstellung von @gadget im 2. Beitrag!)
- MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen (https://forum.fhem.de/index.php/topic,117423.0.html)
- Bidirektionale Kommunikation FHEM-Loxone: was wird benötigt FHEM -> Loxone? (https://forum.fhem.de/index.php/topic,117745.msg1121502.html#msg1121502)
- Fhem von Android steuern mit MQTT (https://forum.fhem.de/index.php/topic,117630.0.html)
- Zwei FHEMs mit MQTT2 verbinden?
(https://forum.fhem.de/index.php/topic,91015.msg834979.html#msg834979)- Status Rücklesen Dummy (https://forum.fhem.de/index.php/topic,109192.msg1031413.html#msg1031413) (ebenfalls Loxone-Anbindung)
- Node-Red als Frontend (https://forum.fhem.de/index.php/topic,78512.0.html) (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 (https://forum.fhem.de/index.php/topic,117737.0.html) 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.:
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=0attr <mqtt_generic_bridge-devicename> globalDefaults sub:base={"FHEM/set2FHEM/$device"} pub:base={"FHEM/$device"} pub:qos=0 sub:qos=2 retain=0attr myMGB globalDefaults sub:base={"myMGB/command/$device"} pub:base={"myMGB/$device"} pub:qos=0 sub:qos=2 retain=0
Damit 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:
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:
{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 (https://forum.fhem.de/index.php/topic,117933.0.html).
Wer sich erst orientieren muss: Es gibt einen sehr guten Thread mit vielen Beispielen (https://forum.fhem.de/index.php/topic,91642.msg841367.html#msg841367) 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...
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: 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...
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:
attr DEVICE globalDefaults sub:base={"DEVICE/set/$device"} pub:base={"DEVICE/$device"} pub:qos=0 sub:qos=2 retain=0
DEVICE 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):
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:
{ 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
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:
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:
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:
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
:)
Das Thema scheint ja doch einige zu interessieren...
Danke auch für diese Rückmeldung!
Fragen/Anmerkungen von meiner Seite dazu:
Die Kombination
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:
attr E4_az_THKV_Heizkoerper_Wand mqttForward none
attr E1_fl_US_Wandspot mqttForward none
Was mich noch interessieren würde. Mit
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...
ZitatAnweisungen 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.
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:
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.
Zitat von: cmonty14 am 21 Januar 2021, 08:54:06
Der einzige Grund, warum ich versuche das Modul MQTT zu installieren ist, dass hier (https://ownsmarthome.de/2020/05/07/loxone-mit-raspberry-pi-mqtt-fhem-aufbohren/) 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
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...
MQTT2 implementiert QoS:0 und QoS:1 (PUBACK), QoS:2 Nachrichten (PUBREC, PUBREL, PUBCOMP) werden als "Unhandled packet" protokolliert, und die Verbindung wird geschlossen.
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...?)
Zitat von: Beta-User am 22 Januar 2021, 12:40:29
:)
Fragen/Anmerkungen von meiner Seite dazu:
Die Kombination
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.
Zitat
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.
Zitat
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:
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.
Zitat
Was mich noch interessieren würde. Mit
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
Zitat von: rudolfkoenig am 22 Januar 2021, 14:55:13
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.
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.
Zitat von: herr.vorragend am 23 Januar 2021, 09:51:21
Werden bei euch die Templates eigentlich hinter "set xyz attrTemplate" als Dropdown angezeigt?
Nö, bei mir auch nicht :(
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
{ 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)
Hallo Beta-User,
was meinst Du mit GW-Type? Habe es mal ausprobiert und mqttForward none rausgenommen. Bislang hat sich beim Schalten bzw. Übertragen von Werten kein Ping-Ping mehr ergeben. Vielleicht war da wirklich am Anfang in meinen Einstellungen ein Fehler.
setpointTemp habe ich jetzt bei mir rausgenommen, da desired-temp völlig ausreicht.
VG
Torsten
Zitat von: ToKa am 23 Januar 2021, 11:00:58
was meinst Du mit GW-Type?
MQTT2_SERVER, MQTT oder MQTT2_CLIENT.
Aber wenn es (jetzt) auch so geht, hat sich die Frage (hoffentlich) erledigt.
@hexenmeister: Aus gegebenem Anlass habe ich mal versucht, einen HM-LC-BL1PBU-FM einzubinden. Mit pct kein Problem, aber irgendwie ist "state" komisch, wohl weil CUL_HM (neuderings?) state als setter nicht mag. Vielleicht schaust du mal in den Nebenthread HM-LC-Bl1PBU-FM via MQTT steuern, da schreibe ich gleich noch was, aber insgesamt stellt sich mit die Frage, ob man "state" nicht eine Sonderbehandlung zukommen lassen müßte?
(Allgemein wäre mein Ziel, on/off/stop/up und down als state-Setter für Rollläden reinzubasteln, nur pct als setter finde ich nur bedingt intuitiv, aber vermutlich übersehe ich was...).
EDIT: hat sich erledigt, Userfehler...
MGB auf der einen Instanz und M2C auf der anderen Instanz.
ZitatJetzt verwirrt Ihr mich aber mit qos... Laut Doku unterstützt M2C qos ≤ 1 und MGB qos ≤ 2.
Wenn die Daten bei MGB ueber M2C gesendet werden, dann ist die qos Einstellung in MGB wirkungslos.
Einstellen kann man qos=1 mit qosMaxQueueLength in M2C. Was das bewirkt, siehe commandref:
Zitatif set to a nonzero value, messages are published with QoS=1, and are kept in a memory-only buffer until acknowledged by the server. If there is no connection to the server, up to <number> messages are queued, and resent when the connection is esablished.
Ob eine Vergleichbare Pufferung bei dem "alten" MQTT Modul gibt, weiss ich nicht.
Und welche weiteren Vorteile bei qos=2 existieren, wuesste ich auch gerne.
ZitatMit dem mosquitto habe ich keine Performance Probleme.
Das mag schon sein, dass Du jetzt damit keine Probleme hast. Wenn das aber Voreinstellung wird oder in irgendwelchen Wikis drin steht, dann habe ich (als Support) damit demnaechst welche.
Zitat von: rudolfkoenig am 23 Januar 2021, 12:30:25
Ob eine Vergleichbare Pufferung bei dem "alten" MQTT Modul gibt, weiss ich nicht.
Ist schon lange her, als ich die Module "geerbt" habe und auch schon länger nicht reingeschaut, aber ich bin relativ sicher, dass diesen Mechanismus es dort auch gibt. Incl. QOS2 Unterstützung. Muss ich mal bei Gelegenheit austesten.
Zitat von: rudolfkoenig am 23 Januar 2021, 12:30:25
Und welche weiteren Vorteile bei qos=2 existieren, wuesste ich auch gerne.
Zum Beispiel bei Zählern, oder Toggle-Schaltern, könnte das wichtig sein, wenn die Verbindung nicht 100% zuverlässig ist. Damit wäre sichergestellt, dass die Nachricht ankommt und auch nur einmal. Ansonsten kann der Zustand nicht sicher garantiert werden. Zuhause vermutlich meist entbehrlich, bei kritischen Anwendungen dagegen ein Muss.
Da mir qos bis gestern neu war, fand ich die Beschreibung sehr gut:
https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ (https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/)
ZitatQoS 2 - exactly once
QoS 2 is the highest level of service in MQTT. This level guarantees that each message is received only once by the intended recipients. QoS 2 is the safest and slowest quality of service level. The guarantee is provided by at least two request/response flows (a four-part handshake) between the sender and the receiver. The sender and receiver use the packet identifier of the original PUBLISH message to coordinate delivery of the message.
ZitatUse QoS 2 when ...
It is critical to your application to receive all messages exactly once. This is often the case if a duplicate delivery can harm application users or subscribing clients. Be aware of the overhead and that the QoS 2 interaction takes more time to complete.
Wie Hexenmeister schon schreibt, ist das bei kritischen Anwendungen notwendig. Ob fhem bzw. andere Anwendungen, die per mqtt angebunden bei qos=1 mit den ggf. mehrfacher Übertragung zu recht kommen, ist auch eine spannende Frage.
@Rudi: Ich hatte nicht die Erwartungshaltung, dass meine Einstellungen zum Template werden, sondern wollte nur etwas zur Frage von Beta-User beitragen.
QoS war bisher für mich recht uninteressant, da bisher über MQTT2_SERVER nur mit zigbee2mqtt gesprochen wurde.
Da ich jetzt aber auch (auf einem anderen Gerät) HomeAssistant zur Visualisierung und rudimentären Steuerung aufbaue, wird es plötzlich interessant, da Befehle, die von HA an FHEM laufen nur einmal ausgeführt werden sollen/dürfen.
Befehl an Rollo: Fahre 10%. Ohne QoS könnten 20, 30, 40 Prozent draus werden, wenn der Befehl mehr als einmal bei FHEM eingeliefert wird. Oder das Rollo fährt gar nicht, weil der Befehl verloren gegangen ist.
Oder es lutscht das HomeMatic-Sendekontingent leer, weil der Befehl an den CUL mehrfach bei FHEM eingeht.
Zukünftig wäre es zudem noch interessant, weil eine externe (vermutlich über GSM angebundene) Instanz zur Teichsteuerung per MQTT verbunden werden soll. Da hängen dann auch Pegel-/Magnetschalter und EnergyCounter dran, hier wäre QoS:2 sehr interessant um ein Überlaufen des Teichs, bzw. falsche Energieverbräuche, durch fehlende oder doppelte Befehle zu verhindern.
Gelöst hab ich es jetzt soweit, dass ich (vorerst) MQTT2_SERVER durch MQTT mit mosqitto ersetzt habe.
@ToKa:
Bei FHEM ist es mir noch nicht aufgefallen, aber bei zigbee2mqtt schon. Zumindest habe ich jetzt eine Erklärung, warum manchmal ZigBee-Befehle mehrfach an die Lampen gesendet wurden, das aber nur passierte, wenn der Befehl nicht aus FHEM kam. Zuerst hatte ich diyHue in Verdacht, aber vermutlich war es eine Kommunikationsstörung gepaart mit fehlender QoS (diyHue läuft bei mir auf einem WLAN-Device). Ist mir nicht mehr aufgefallen, seit ich mosquitto statt FHEM als Server verwende.
Zitat von: OiledAmoeba am 24 Januar 2021, 00:41:47
Gelöst hab ich es jetzt soweit, dass ich (vorerst) MQTT2_SERVER durch MQTT mit mosqitto ersetzt habe.
Ich lese immer die MQTT2 Module anstelle der MQTT Module verwendet werden? Oder ist das für einen Einsatz mit MGB als IODev, mosquitto und qos=2 die bessere Lösung, statt MGB, mosquitto und M2C als IODev? Wie sieht es dann mit MQTT als IODev für M2D in meinem Fall auf der Gegenseite aus?
VG
Torsten
Zitat von: ToKa am 24 Januar 2021, 13:18:17
Ich lese immer die MQTT2 Module anstelle der MQTT Module verwendet werden? Oder ist das für einen Einsatz mit MGB als IODev, mosquitto und qos=2 die bessere Lösung, statt MGB, mosquitto und M2C als IODev? Wie sieht es dann mit MQTT als IODev für M2D in meinem Fall auf der Gegenseite aus?
Wenn Du qos2 wirklich(!) brauchst, dann kommst Du aktuell wohl nicht an MQTT + Mosquitto vorbei. MQTT2_CLIENT/_SERVER unterstützen qos2 (noch?) nicht.
Sonst gilt generell die Empfelung MQTT2-Module zu nutzen.
MQTT_GENERIC_BRIDGE unerstützt das setzen von qos2, ausführen muss das jedoch das IO.
Altes MQTT-IO mit M2D funktioniert nicht (und wird auch nie).
Hallo Hexenmeister,
danke für die Klarstellung. Aktuell kein wirklicher Bedarf und solange auf der Empfangsseite in fhem keine Unterstützung von qos=2 da ist, auch ja in meinem Szenario gar nicht realisierbar.
VG
Torsten
Zitat von: ToKa am 25 Januar 2021, 10:36:14solange auf der Empfangsseite in fhem keine Unterstützung von qos=2 da ist, auch ja in meinem Szenario gar nicht realisierbar.
Naja, mit dem alten Modul geht das eigentlich schon...
Jein, da die zweite fhem Instanz M2D nutzt kommt ja nur M2C als IODev in Frage und da geht ja maximal qos=1. qos=2 macht ja aber nur Sinn (sofern man es braucht) wenn Sender und Empfänger qos=2 können / nutzen.
Das ist klar, man muss natürlich beides umstellen. Z. B auf MQTT + MGB.
Qos 2 macht bei aktueller Implementierung eigentlich keinen Sinn. Das kommt aus der Ecke anderer Verbindungswege (SMS, Udp usw). In einem TCP/IP Netzwerk ist es normerweise nur Ballast
Bei qos1 wäre ich dabei. Bei qos1 nicht mehr. Das liegt auf einem höheren Level, als Transportsicherheit.
Edit:... bei qos2 nicht mehr...
Achtung!
Wir reden hier über unterschiedliche OSI Schichten. TCP auf Schicht 4 und mqtt auf 7.
Schon klar. Ich relativiere mein Aussage: subjektive Meinung ;)
Mir ist aber bisher kein (praktischer) Einsatz in einem Heimnetz eingefallen. TCP stellt die Zustellung sicher (oder verwirft). Ja, irgendwo an einer 800km Ölpipeline mit Mobilfunk Anbindung (oder schlimmer), ja.
Im Zweifelsfall retain für Zustände. Events (Lichtschalter) muss ich doch, nach wlan Ausfall zb, nicht 5h später (exakt einmal) noch zustellen. Aber ok, mag andere Ansichten geben
Ich bin bereit QoS:2 fuer die MQTT2-IODevs zu implementieren, wenn jemand mir einen realen Fall zeigt, wo man nicht ohne auskommt.
Retain hilft Dir aber nur, wenn der Empfänger wieder online ist und vom Broker mit den Daten versorgt wird. Falls Dein Sender keine Verbindung zum Broker hat oder der ausgefallen ist, hilft Dir die Absicherung auf der Transportebene über TCP nichts. Das kann nur auf der Anwendungsebene über MQTT abgefangen werden.
Zitat von: rudolfkoenig am 25 Januar 2021, 18:16:16
Ich bin bereit QoS:2 fuer die MQTT2-IODevs zu implementieren, wenn jemand mir einen realen Fall zeigt, wo man nicht ohne auskommt.
Hallo Rudi,
es sind auch im Smarthome Szenarien denkbar (siehe https://forum.fhem.de/index.php/topic,117987.msg1125150.html#msg1125150 (https://forum.fhem.de/index.php/topic,117987.msg1125150.html#msg1125150)) und es muss nicht gleich die Ölpipeline oder die Gasturbine sein, die abgeschalten werden soll.
Meinst Du
ZitatOhne QoS könnten 20, 30, 40 Prozent draus werden, wenn der Befehl mehr als einmal bei FHEM eingeliefert wird. Oder das Rollo fährt gar nicht, weil der Befehl verloren gegangen ist.
Das hoert sich erstmal hypothetisch und nicht praktisch an. Wenn doch praktisch (dafuer haette ich gerne ein Beleg), dann wuerde ich es instinktiv als kaputte Implementierung einstufen: wieso wiederholt man bei einer stehenden TCP-Verbindung die gleiche Meldung?
Um wieder etwas zum eigentlichen Thema zurückzukommen...
Hier mal ein erster Versuch, das etwas zu strukturieren und zusammenzufassen, was wir bisher hier so ventiliert haben:
Zitat von: Beta-User am 27 Januar 2021, 12:59:33
allerdings sollten dann machen "Standards" beachtet werden (bzw. das, was dazu werden könnte:
- $base (aus den globalen Vorgaben) sollte jetzt doch ohne den $device-Anteil auskommen
- alle Setter gehen nach subscribe-$base ("xyz"/set) (festgelegt über ein globales Attribut an der MGB, wobei "xyz" das ist, was in publish-Richtung $base heißt)
- alles, was state betrifft, geht dann über $base/$device direkt, alles andere über $base/$device/$name
- dann sollte man für alles, was irgendwie "Standard" ist, auch standardisierte Benennungen verwenden. Vorschlag:
-- pct für (fast) alles, was 0-100 ist (bzw. bei ZWave: 0-99) (das würde hier bedeuten, einen mqttAlias zu verwenden "dim=pct")
(Ausnahme: actuator/valve (?) bei Thermostaten etc., slatLevel (?) für Lamellendrehung)
-- brightness für alles, was in 0-255 einzustellen ist
-- desired-temp für die Soll-Temperatur,
-- temperature für gemessene Temperatur.
[...]
Falls jemand sich die Frage stelle, was das ggf. bringt: So kann man
- im Bedarfsfall einfach das Gerät (gegen ein völlig anderes) tauschen, paßt die (standardisierten!) Attribute an (ggf. über attrTemplate), und alles funktioniert von MQTT aus weiter wie bisher;
- in der yaml für alle Device-Typen denselben "Grundtypus" verwenden, man muss nur den Namen anpassen, und man kann sich auch hier zwischen den Usern einfacher austauschen...
(Ist nur ein Vorschlag...)
Falls jemand das nachvollziehen will:
- Den ersten Teil (Vorgaben für $base in publish- und subscribe-Richtung) kann man schon jetzt via attrTemplate an der MGB einstellen;
- für Thermostat-Geräte der TYPE MAX, CUL_HM und ZWave gibt es attrTemplate, die das - bis auf valve/actuator - umsetzen. Da würde mich interessieren, wie das Ding "auf MQTT" benannt werden soll?
- was pct und "state"-Anweisungen angeht, findet sich zumindest schon mal was zu einem CUL_HM-Rollladen. Bei Gelegenheit "normalisiere" ich noch einen ZWave (erst mal ohne Lamellen).
Fragen dazu bzw. andere Vorschläge?