Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[Billy]

Kann leider nichts dazu sagen. eventMap ist ja genau dafür da, warum das bei HM-Device nicht funktioniert müsste man in einem entsprechenden Forum-Zweig fragen.
Ansonsten könnte man das mit der Bridge mit hilfe von 'expression' (s. Commandref) schon bewerkstelligen. Auch wenn das nicht dafür gedacht war.

Danke, mit 'expression' geht was ich möchte. Deckt sich ja auch mit diesem thread.
Frage: Syntax MQTT_GENERIC_BRIDGE value-mapping
https://forum.fhem.de/index.php/topic,93188.msg857849.html#msg857849

mit

Code Auswählen Erweitern

state:topic=fhem/status/alarm/test_2 state:expression={($value eq 'off')?'stop':'on'} komme ich zum gewünschten Ergebnis!
EDIT: Wie kann ich hier noch das retain flag setzten? ist mir nicht gelungen.

Mit diesem publish

Code Auswählen Erweitern

state:topic=fhem/status/alarm/test_2 state:retain=1 state:expression={($value eq 'off')?'stop':'on'}
funktioniert auch retain! Super!!!

Billy

[hexenmeister]

Dein Problem scheint gelöst zu sein. Freut mich

[christiantf]

Ehrlich gesagt, halte ich so ein globales 'Setzen' für etwas gefählich, man kann sich damit schnell Sicherheitslücken 'einbauen'.

Den Sicherheitsaspekt kann ich nicht teilen - das ist genauso sicher/unsicher wie wenn ich den Status per HTTP setze. Ist halt nur ein anderes Protokoll, läuft genauso mit Authentifizierung usw.

Vielleicht kann mir trotzdem jemand weiterhelfen um ein Device einzeln zu setzen:

Per Eingabe würde ich die HS100 aktivieren mit:
set Kueche_HS100 on

Geben tut's on und off, und das würde ich per MQTT senden.

Wie würde dazu das mqttSubscribe aussehen?

Code Auswählen Erweitern


attr lb_mosquitto mqttSubscribe state:stopic={"command/fhem/Kueche_HS100"} state:expression={Kueche_HS100=$value}

... hätte ich probiert, aber FHEM reagiert nicht darauf nicht.

Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.

lg, Christian

[Billy]

Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.

lg, Christian

Kennst du das? --> Anwendungsfälle und Beispiele für MQTT_GENERIC_BRIDGE
https://forum.fhem.de/index.php/topic,91642.msg841368.html#msg841368
Vielleicht hilfts es dir!

@Hexenmeister --> Der Thread ist leider nur schwer zu finden. Die Idee mit eingängigen Beispielen hat mir schon öfters geholfen.
                              Du solltest vielleicht in der Überschrift "Anwendungsfälle und Beispiele für MQT_GENERIC_BRIDGE" das MQT in MQTT ändern.
dann findet man das leichter.

[christiantf]

@Billy Jetzt kenn ich's

Jetzt hab ich

Code Auswählen Erweitern


attr Kueche_HS100 mqttSubscribe state:stopic=command/fhem/Kueche_HS100

Sollte das richtig sein? Funktionieren tut's leider nicht. Sollte man im Log nicht irgendwas sehen, dass FHEM das Topic subscribed?
Es ist einfach so, als wäre die Zeile nicht da. Im MQTT-Spy sehe ich mein Publish mit mosquitto_pub an command/fhem/Kueche_HS100 = on, ich bekomme auch alle anderen Readings von der Generic_Bridge, aber meine Subscription wird ignoriert.

Vielleicht könnte jemand die konkrete Lösung posten. Wenn ich's einmal gesehen hab, versteh ich's hoffentlich!

[Beta-User]

Mach mal noch testweise einen "/" vor das command.

[christiantf]

Mach mal noch testweise einen "/" vor das command.

Unüblich, und funktioniert leider auch nicht - hab's in allen Kombinationen durchprobiert (mit/ohne / in FHEM, und mit/ohne / im mosquitto_pub).
Müsste ich das Subscribe des Topics im Log sehen?

[Beta-User]

Unüblich, [...]

Dachte ich auch, aber bei meinen (leider auch - aus anderen Gründen) erfolglosen Tests (mit MQTT2_SERVER) hatte ich wenigstens mit mosquitto_sub den Eindruck, dass das "einen Client mehr" erzeugt, und auch die Beispiele in der cref haben oft ein "einleitendes "/".

@hexenmeister:
Hat es einen Grund, dass das in dem eher unüblichen Format in der commandref steht bzw. sollte man irgendwie erläutern, wann man das warum benötigt?

[Dersch]

Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.

[Billy]

Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.

Das war für mich zuerst auch ungewöhnlich.

Die MQTT_GENERIC_BRIDGE versorgt bestehende Devices mit MQTT Attributen. Wo es kein Device gibt, musst du ein Dummy definieren und an der
MQTT_GENERIC_BRIDGE anmelden.
Vorteil du hast bei allen Devices das gleiche Umfeld und bekommst mit get mqttGeneric devinfo alle Mqtt Devices in einer Übersicht.

Übrigens ist ein MQTT_DEVICE nichts anderes als ein Dummy mit mqtt Attributen.

Hoffe das hilft.

[Dersch]

Ah ok vielen Dank ! Dann tüftel ich mal weiter um es endlich komplett zu verstehen und Fhem2fhem ersetze

[Beta-User]

Ich finde es immer noch ungewöhnlich.

@hexenmeister: Sollte man nicht neuerdings empfehlen, alles, was nicht in FHEM direkt als Gerät über ein anderes Modul vorhanden ist (CUL_HM usw.) als MQTT2_DEVICE anzulegen?

Hintergrund: Man braucht "irgendwas" dafür, und nach meiner bisherigen Erfahrung gehört MQTT2_DEVICE zu den Geräten, die am einfachsten optisch ansprechend zu konfigurieren sind.

Man braucht halt (ggf. zusätzlich) ein MQTT2-IO (Client, wenn man weiter mosquitto/ext. Broker im Einsatz hat)....

[Billy]

Zitat Hexenmeister am: 16 November 2018 hier:
https://forum.fhem.de/index.php/topic,91984.msg859281/topicseen.html#msg859281

Ich sehe eigentlich keine Notwendigkeit sowohl die Bridge als auch MQTT2_DEVICE gleichzeitig zu verwenden.
Bridge kann ja das andere komplett ersetzen und auch vice-versa. Die Frage ist nur, wie man es haben möchte.

Hat sich da was verändert? Bei mir deckt die Bridge eigentlich alles ab.

[Beta-User]

Zum Hintergrund nochmal:
Im Kern ist das Protokoll sehr simpel, alle Lösungen funktionieren irgendwie, die Mischung MQTT2-IO+Gen.-Bridge ist noch etwas hakelig, aber das dürfte eine Frage der Zeit sein.

Wer heute in MQTT einsteigt, sollte (und das ist wohl auch hexenmeisters heutige Tendenz, anders als evtl. noch vor ein paar Wochen) nativ MQTT sprechendes Zeug mit einem MQTT2-IO in FHEM einbinden und MQTT2_DEVICE nutzen. Das ist schlicht und ergreifend für Neulinge am einfachsten zu konfigurieren (funktional und optisch), JSON ist kein Thema und auch die Sendeseite ist da sehr flexibel, was das Basteln nahezu beliebiger Formate angeht.

Die "Lücke" dabei ist die "ver-MQTT-ung" von Nicht-MQTT-Devices. Das kann die Bridge am universellsten, nur eben mit der Einschränkung, dass die nicht zusammen mit autocreate an einem MQTT2-IO genutzt werden kann.
Im Moment ist das die einzige Einschränkung, es dürfte aber auch nur eine Frage der Zeit sein, bis diese behoben ist.

Es gibt aber weder einen Grund, irgendwas umzubauen, schon gleich nicht, wenn man _irgendeinen_ Weg verstanden hat, wie man zu einem bestimmten Ergebnis kommt. Und auch die Aussage ist ok, dass man mit den alten Wegen (fast) alles abdecken kann.

Wer allerdings irgendwann Verschlüsselung will, braucht dann ein MQTT2-IO (es sei denn, das kommt irgendwann auch bei MQTT(1), was ich aber ehrlich gesagt im Moment nicht glaube).

[christiantf]

Ich hab's jetzt mit Telnet gemacht.
mqttSubscribe funktioniert bei mir nicht, oder die Beispiele (genau genommen Syntaxangaben) sind zu unklar, um das korrekt einzurichten.
Es gibt im Forum leider auch kein Beispiel, wo jemand mqttSubscribe mit einem konkreten Device erfolgreich gemacht hat.