MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate)

[ToKa]

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

[Beta-User]

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...

[ToKa]

MGB auf der einen Instanz und M2C auf der anderen Instanz.

[rudolfkoenig]

Jetzt 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:

if 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.

Mit 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.

[hexenmeister]

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.

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.

[ToKa]

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/

QoS 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.

Use 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.

[OiledAmoeba]

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.

[ToKa]

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

[hexenmeister]

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).

[ToKa]

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

[hexenmeister]

solange 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...

[ToKa]

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.

[hexenmeister]

Das ist klar, man muss natürlich beides umstellen. Z. B auf MQTT + MGB.

[herrmannj]

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

[hexenmeister]

Bei qos1 wäre ich dabei. Bei qos1 nicht mehr. Das liegt auf einem höheren Level, als Transportsicherheit.

Edit:... bei qos2 nicht mehr...