[erledigt] MQTT_GENERIC_BRIDGE - Optimierungen für MQTT2-IO-Module

[Beta-User]

clientOrder am M2_CLIENT passend setzen.

[herr.vorragend]

Verstehe ich nicht. Habe ich doch bereits. Erst die MGB dann das M2D.

[Beta-User]

Hmmm, also...

Hatte das mit der clientOrder irgendwie gestern auf dem Handy übersehen, sorry.

Wenn ich das richtig deute, wird das Device "hmdevice" aber durchaus geschalten, oder?
Das "Problem" ist nur, dass zusätzlich dieser Eintrag in der readingList erscheint?

Wenn das das Thema ist, kannst du entweder
- meinen "forceNEXT"-Patch testen und ggf. "bewerben" (das verhindert in der Standardeinstellung, dass M2D noch was von messages sieht, die die MGB verwerten kann), oder
- deine bridgeRegexp ergänzen, dass der "fhem/"-Topic-Zweig nach "" umgeleitet wird. Damit würde dann (wie bisher auch schon im Wiki dargestellt) autocreate für diese Messages nicht mehr durchschlagen.

Ergänzend:
- Vermutlich macht es Sinn, den "homeassistant"-Zweig, der jetzt in der readingList auftaucht auch noch mit einer bridgeRegexp in ein eigenes Device zu schicken. Das scheint was separates zu sein...
- Nach meinem persönlichen Geschmacksempfinden würde ich "state"-Anweisungen auch ohne "$name"-Anteil im Topic versenden. Siehe dazu meinen Wiki-stub zu MQTT_GENERIC_BRIDGE. Das wäre dann:

Code Auswählen Erweitern

attr hmdevice mqttSubscribe :stopic={"$base/$device"}

[herr.vorragend]

Wenn ich das richtig deute, wird das Device "hmdevice" aber durchaus geschalten, oder?
Das "Problem" ist nur, dass zusätzlich dieser Eintrag in der readingList erscheint?

Nein, es wird auch nicht geschaltet. Und das verstehe ich nicht, weil dies noch vor wenigen Tagen bei unveränderter Konfiguration funktionierte.
Klar, es erscheint auch in der readingList, aber das wäre erst meine zweite Frage gewesen.

Wenn das das Thema ist, kannst du entweder
- meinen "forceNEXT"-Patch testen und ggf. "bewerben" (das verhindert in der Standardeinstellung, dass M2D noch was von messages sieht, die die MGB verwerten kann), oder
- deine bridgeRegexp ergänzen, dass der "fhem/"-Topic-Zweig nach "" umgeleitet wird. Damit würde dann (wie bisher auch schon im Wiki dargestellt) autocreate für diese Messages nicht mehr durchschlagen.

Schaue ich mir an, wenn die Basis wieder funktioniert.

Ergänzend:
- Vermutlich macht es Sinn, den "homeassistant"-Zweig, der jetzt in der readingList auftaucht auch noch mit einer bridgeRegexp in ein eigenes Device zu schicken. Das scheint was separates zu sein...

Ich habe in den letzten Tagen bestimmt mehr als 500 MQTT-Devices gelöscht und wieder neu anlegen lassen, weil ich aktuell noch spiele.
Um es später hübsch zu machen, wäre dein Vorschlag in der Tat eine gute Idee. Für Mosquitto habe ich auch bereits ein $SYS-Device angelegt.

- Nach meinem persönlichen Geschmacksempfinden würde ich "state"-Anweisungen auch ohne "$name"-Anteil im Topic versenden. Siehe dazu meinen Wiki-stub zu MQTT_GENERIC_BRIDGE. Das wäre dann:

Code Auswählen Erweitern

attr hmdevice mqttSubscribe :stopic={"$base/$device"}

OK

[Beta-User]

Hmm, für den "Verlust" in der MGB habe ich im Moment keine Erklärung, vorausgesetzt, du hast die letzte Version von M2_CLIENT am Start, wovon ich aber ausgehe, du hast ja die Diskussion hier und anderswo wohl verfolgt.

Aber wenn das M2D beliefert wird, _müßte_ das eigentlich ab dem IO passen, und die Reihenfolge wäre auch (ab der 2. Message) wohl egal...

Vielleicht noch eine Sache. Da das "Klartext" ist, müßte auch die einfachere Variante klappen (die weiteren Einstellungen braucht man wohl auch nicht):

Code Auswählen Erweitern

attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
So stellt es (vom Prinzip her) btw. auch die aktuelle attrTemplate-Version ein. Das mit dem "Einklammern" war nur wegen des $device-Teils erforderlich gewesen, wenn ich's richtig verstanden habe. (Dürfte aber mit dem Problem nichts zu tun haben).

[herr.vorragend]

Oh man, ist mir das nun peinlich.
Es funktionieren nur CUL_HM-Geräte nicht.
Die mögen kein :

Code Auswählen Erweitern

set hmdevice state on

Nachtrag:
Auch wieder quatsch. Mein stopic sah zuvor wie folgt aus:

Code Auswählen Erweitern

attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe :stopic={"$base/$device/$name"}

So geht es:

Code Auswählen Erweitern

attr hmdevice mqttPublish *:topic={"$base/$device/$name"}
attr hmdevice mqttSubscribe state:stopic={"$base/$device/$name"}

Keine Ahnung woher die falschen Wert kommen. Obwohl ich alle Geräte gleichermaßen mit den Attributen versorgt habe, fehlen bei alle CUL_HM die richtigen mqttSubscribe-Werte. Die Z-Wave-Geräte sehen korrekt aus. Egal, hauptsache es klappt nun.

[hexenmeister]

@hexenmeister:
Falls du dich mit dem Hinweis auf my $foo = $bar if $baz; # UNDEFINED! beschäftigen willst: In https://github.com/rejoe2/fhem_MQTT_GENERIC_BRIDGE/commit/6fd40496772d7f2d3046c953409698193aadbd23 wäre mein noch nicht intensiv getesteter Versuch zu finden, die betreffenden Stellen auf "offiziell zulässige" Weise zu notieren.

Übernommen. Danke für den Patch!

[hexenmeister]

@hexenmeister:
Hab's jetzt alles nochmal zusammengeschoben, patch anbei, jetzt sollten auch die <li>-Elemente in der commandref wieder ausgeglichen sein .
Bei der Gelegenheit: Ist es nach wie vor richtig, dass mqttAlias nur in publish-Richtung funktioniert? (Ist/war mir bisher entgangen...)

Habe auch übernommen, danke für deine Arbeit!

[Beta-User]

Autsch, habe grade gemerkt, dass da das "-r" noch drin war...

Das ist leider ein Fehler, kannst du diese eine Zeile wieder auf den alten Stand bringen, bitte?

Code Auswählen Erweitern

2469    $topic ='-r $topic' if $retain;
Sollte wieder diesen Stand haben:

Code Auswählen Erweitern

$topic.=':r' if $retain;

[hexenmeister]

Autsch, habe grade gemerkt, dass da das "-r" noch drin war...

Habe ich doch die Änderung gesehen und mich etwas gewundet, da ich jedoch MQTT2 nicht (produktiv) verwende... Sorry, hätte testen sollen.
Ist wieder zurückgerollt.

[Beta-User]

Anbei noch weitere Vorschläge zur commandref (DE und EN). Kann sein, dass die Zeilennummern etwas verschoben sind, bitte melden, wenn du die komplette Datei benötigst.

[Beta-User]

...und noch ein Nachtrag, betreffend "id" statt "name" als Anker und Antw:Online Attributhilfe für ähnliche Attribute duplizieren/übernehmen (Ich hoffe, mich nirgends verzählt und die Anker alle erwischt zu haben).

[hexenmeister]

Ubernommen. Vielen Dank für die Korrekturen