Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[hexenmeister]

Hier noch ein Beispiel mit Onewire. Die Hardware ist ein ESP mit ESPEasy drauf.

Code Auswählen Erweitern

defmod HA_Heizung dummy
attr HA_Heizung alias Heizung Temperaturen
attr HA_Heizung group Warmwasser
attr HA_Heizung icon sani_buffer_temp_all
attr HA_Heizung mqttDefaults base={"haus/anschlussraum"}
attr HA_Heizung mqttSubscribe Fernwaerme-Ruecklauf-Gesamt:topic={"$base/heizung/Fernwaerme_Ruecklauf_Gesamt/temperature"}\
Fernwaerme-Ruecklauf-Heizung:topic={"$base/heizung/Fernwaerme_Ruecklauf_Heizung/temperature"}\
Fernwaerme-Ruecklauf-Warmwasser:topic={"$base/heizung/Fernwaerme_Ruecklauf_Warmwasser/temperature"}\
Fernwaerme-Vorlauf-Warmwasser:topic={"$base/heizung/Fernwaerme_Vorlauf_Warmwasser/temperature"}\
Fernwaerme-Vorlauf_Heizung:topic={"$base/heizung/Fernwaerme_Vorlauf_Heizung/temperature"}\
Kaltwasser-Anschluss:topic={"$base/heizung/Kaltwasser_Anschluss/temperature"}\
Warmwasser-Entnahme:topic={"$base/heizung/Warmwasser_Entnahme/temperature"}\
Warmwasser-Rueckfluss:topic={"$base/heizung/Warmwasser_Rueckfluss/temperature"}\
Warmwasser-Speicher:topic={"$base/heizung/Warmwasser_Speicher/temperature"}\
Warmwasser-Speicher-Oben:topic={"$base/heizung/Warmwasser_Speicher_Oben/temperature"}\
rssi:topic={"$base/system/RSSI"}
attr HA_Heizung room Heizung

[bmwfan]

Habe auf MQTT zur MQTT_Generic_Bridge auf RPI03 und RPI02 umgestellt. Läuft seit 3 Tagen ohne jede Probleme.

Ich wollte als nächstes den eBUS meiner Vaillant Heizung anschliessen. Dazu gibt es ein Modul, das inzwischen mit MQTT funktioniert und ein Template von Rudolf.
Siehe Links: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#eBus und https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate

So wie ich das verstehe, allerdings nur mit MQTT2-Device. Das bedeutet, dass ich für den eBUS zusätzlich zur Generic-Bridge ein MQTT2-Device definieren muss, auf das ich dann das Template anwenden kann? Das Device stört dann auch nicht die 1-Wire Übertragung über MQTT?

Grüße Jürgen

[Beta-User]

Ich wollte als nächstes den eBUS meiner Vaillant Heizung anschliessen. Dazu gibt es [...]

Im Prinzip müßte das auch in der "alten" MQTT-Welt gehen, aber die Datenstrukturen, die der ebus-Dämon liefert, sind nicht ganz trivial (m.E. jedenfalls).

Vorschlag: Du kannst auch die subscriptions von MQTT2_CLIENT so einschränken, dass nur ebus-Nachrichten durchkommen, dann kannst du da autocreate auf complex stellen und erst mal sehen, was das so anlegt.

Wenn du dann noch Lust dazu hast, kannst du das ja nach "MQTT-alt" übersetzen .

Grundsätzlich wäre ich an einem Erfahrungsbericht sehr interessiert, wie das geklappt hat, dann würde ich das ggf. als Tipp noch ins Wiki zu dem ebus-Teil aufnehmen. (Bitte dann aber in der Heizungs-Abteilung, da gibt es einen Thread, der sich mit den ebus-templates befaßt).

[hexenmeister]

GenericBridge kann vollständig andere MQTT-DEVICE/BRIDGE-Module funktional ersetzen. Man muss aber die Datenstrukturen kennen und per Hand anlegen. Evtl. wirklich temporär mit zusätzlichen MQTT2_CLIENT und MQTT2_DEVICE Daten sammeln und dann subscribe-attribute für GenericBridge erstellen.

[hexenmeister]

Sehr interessant wäre es natürlich trotzdem, warum Bridge in Deiner Konstellation mit MQTT2* nicht stabil läuft... 

[Beta-User]

Sehr interessant wäre es natürlich trotzdem, warum Bridge in Deiner Konstellation mit MQTT2* nicht stabil läuft... 

Das ist in der Tat ein interessanter Punkt.

GenericBridge kann vollständig andere MQTT-DEVICE/BRIDGE-Module funktional ersetzen. Man muss aber die Datenstrukturen kennen und per Hand anlegen. Evtl. wirklich temporär mit zusätzlichen MQTT2_CLIENT und MQTT2_DEVICE Daten sammeln und dann subscribe-attribute für GenericBridge erstellen.

Na ja, da man im Ergebnis sowieso "irgendein" Device braucht, um die ganzen gesammelten Daten "dranzuhängen", kann man auch gleich MQTT2_DEVICE nehmen. Das "Problem" ist ja nur, dass sich autocreate und die GenericBridge nach meinem Kenntnisstand nicht wirklich gut vertragen.
ABER: man kann die Subscriptions in MQTT2_CLIENT ja derart einschränken, dass "sonst nichts" durchkommt außer den ebus-Geschichten. Dann sollte es mit autocreate eigentlich "ungefährlich" sein, oder habe ich was am Prinzip nicht verstanden?

[hexenmeister]

Kann man natürlich. Ich mag eher Dummies, scheint mit transparenter und leichtgewichtiger, ist aber eine reine Geschmackssache.
Paralleler Einsatz von zwei IO-Typen wäre sicher nicht das gelbe vom Ei. Höchtens zum 'Abgucken' der Paramter, dann einmal alles richtig mit der Bridge einstellen und nie wieder Ärger mit autocreate-Magik

[Beta-User]

Paralleler Einsatz von zwei IO-Typen wäre sicher nicht das gelbe vom Ei. Höchtens zum 'Abgucken' der Paramter, dann einmal alles richtig mit der Bridge einstellen und nie wieder Ärger mit autocreate-Magik

Zwischenzeitlich habe ich darüber auch etwas nachgedacht und finde das jetzt noch weniger dramatisch. Der CLIENT verhält sich ggf. dem mosquitto doch im Prinzip auch nicht anders als - sagen wir ein tasmota-Gerät , nur dass er halt (wie z.B. wie mosquitto_sub auch) über dieselbe IP kommt wie die weiteren MQTT-IOs. Das gilt jedenfalls ab dem Moment, an dem man die subscriptions entsprechend setzt.

Das Eingrenzen der Subscription ist essentiell, aber außer dem, dass der User da Unsinn treiben kann, wenn er das löscht, kann ich jetzt keinen Punkt mehr erkennen, der gegen diese Lösung spräche.

Und ein MQTT2_DEVICE ist m.E. eigentlich auch nur ein leicht modifizierter dummy - kein Grund, letzteren für transparenter zu halten; die Syntax ist halt leicht anders, aber auch nicht schwer, jedenfalls nach meinem persönlichen Eindruck (der aber zugegebenermaßen mit Erfahrung damit gefärbt ist) leichter, als das in die Generic-Bridge-Sprache zu übersetzen.
Jeder halt, wie er es gewohnt ist...

[hexenmeister]

Der (aus meiner Sicht wichtiger) Vorteil der alten MQTT-IO ist die Tatsache, dass die Subscribtions automatisch verwaltet werden. Es wird immer nur das bestellt, was auch gebraucht wird.

[mba]

Hallo hexenmeister,

ich nutze die MQTT_GENERIC_BRIDGE in Verbindung mit dem MQTT2_CLIENT und würde gerne einige readings vom publish ausschliessen (ro-Counter00 bis 09).
Laut Commandref sollte das mit dem Bridge Attribut globalDeviceExclude und/oder globalTypeExclude funktionieren.
Das funktioniert bei mir aber nicht, ich habe folgende Konstellationen ausprobiert.

Code Auswählen Erweitern


attr bridge globalTypeExclude ModbusAttr:ro-Counter00 ModbusAttr:ro-Counter01 ModbusAttr:ro-Counter02
attr bridge globalDeviceExclude mbSlave01:ro-Counter00 mbSlave01:ro-Counter01 mbSlave01:ro-Counter02


das ganze Device zu filtern funktioniert, aber eben nicht auf readings ebene

Code Auswählen Erweitern


attr bridge globalTypeExclude ModbusAttr:*
attr bridge globalDeviceExclude mbSlave01:*


auch das habe ich versucht, aber dadurch wird nur der Wert entfernt, veröffentlicht wird trotzdem, obwohl laut CommandRef "Ist der Rueckgabewert undef, dann wird das Setzen/Ausfuehren unterbunden."

Code Auswählen Erweitern


attr mbSlave01 state:topic={"$base/state"} *:topic={"$base/r/$name"} *:atopic={"$base/a/$name"} ro-Counter00|ro-Counter01|ro-Counter02:expression={$reading=undef}
oder
attr mbSlave01 state:topic={"$base/state"} *:topic={"$base/r/$name"} *:atopic={"$base/a/$name"} ro-Counter00|ro-Counter01|ro-Counter02:expression={undef}


mache ich da was falsch?

Grüße Marco

[hexenmeister]

Moin!

Das ging früher schon mal, müsste ich testen. Umzugsbegingt komme ich in den nächsten paar Wochen leider nicht dazu. Bis dahin wäre eine Lösung, die gewünschten Readings direkt anbieten anstatt *. Ist eh sicherer. 

vg
Alexander

[Maui]

Moin Alex,

da ich grad zwangsweise meine eine FHEM-Instanz neu aufsetzen muss (blöde SD-Karte  ) stolpere ich mal wieder über expandJSON.
Gibt es da mittlerweile von dir neue Bemühungen bzgl. JSON? Oder ist expandJSON da immer noch das schnelle Maß der Dinge?

Gruß
Maui

[hexenmeister]

Hi!

Die oft angefragte JSON-Unterstützung kann einfach mit Hilfe von 'expression' realisiert werden. Dafür eignet sich eine in fhem.pl bereits vorhandene Methode: json2nameValue. Als Parameter soll $message verwendet werden.

Beispiel:
attr <dev> mqttSubscribe json:topic=/XTEST/json json:expression={json2nameValue($message)}

Grüße
Alexander

[frankreed]

Hallo,

ich möchte gerne mein Gast-WLAN über MQTT ein- und aussschalten können. Dazu habe ich folgendes definiert:

Code Auswählen Erweitern


defmod rp_FB_GWLAN1 readingsProxy FritzBox:box_guestWlan
attr rp_FB_GWLAN1 devStateIcon on:it_wifi@green:off off:it_wifi@red:on
attr rp_FB_GWLAN1 event-on-change-reading .*
attr rp_FB_GWLAN1 mqttPublish state:topic={"fhem2mqtt/guestwlan/state"}
attr rp_FB_GWLAN1 mqttSubscribe state:stopic=mqtt2fhem/guestwlan/state/set state:qos=2
attr rp_FB_GWLAN1 room Wohnzimmer
attr rp_FB_GWLAN1 setFn {($CMD eq "on")?"guestWlan on":"guestWlan off"}
attr rp_FB_GWLAN1 setList on off


Beim Klicken in FHEM wird auch brav der state an den Broker "gepublished", nur das mit dem subscribe will nicht. Egal was ich sende, der on bzw. off Befehl wird nicht angenommen und der state ändert sich nicht.
Kann mir mal jemand einen Schubs geben, wie der mqttsubscribe aussehen müsse und was genau ich an den Broker schicken müsste, damit das Device umschaltet?
Danke im Voraus.
Frank

[OdfFhem]

@frankreed

Mein Attribut fürs Schalten sieht vereinfacht so aus:

Code Auswählen Erweitern


attr <device> mqttSubscribe state:stopic={"$base/$device/$reading/set"}


Folglich fehlt bei Deinem mqttSubscribe die geschweifte Klammer samt den Anführungszeichen. Das Attribut müsste eher so aussehen - vorausgesetzt der MQTT-Pfad stimmt ansonsten:

Code Auswählen Erweitern


attr rp_FB_GWLAN1 mqttSubscribe state:stopic={"mqtt2fhem/guestwlan/state/set"} state:qos=2