MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate)

[ToKa]

Achtung!

Wir reden hier über unterschiedliche OSI Schichten. TCP auf Schicht 4 und mqtt auf 7.

[herrmannj]

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

[rudolfkoenig]

Ich bin bereit QoS:2 fuer die MQTT2-IODevs zu implementieren, wenn jemand mir einen realen Fall zeigt, wo man nicht ohne auskommt.

[ToKa]

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.

[ToKa]

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) und es muss nicht gleich die Ölpipeline oder die Gasturbine sein, die abgeschalten werden soll.

[rudolfkoenig]

Meinst Du

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.

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?

[Beta-User]

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:

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?