[geklärt] MQTT_GENERIC_BRIDGE per subscription nutzen, um slave-Geräte...

[Beta-User]

Kurz zu meinem ursprünglichen Ansatz:
Mit den aktuellen Versionen der Module sollte das doch jetzt funktionieren, oder?
(So wie ich das in dem anderen Thread verstanden habe, müßte die von außen kommende Message doch eigentlich nicht nur beim MQTT2_DEVICE  -db16 auch bei der Generic-Bridge landen und dann dort an deren Client weitergegeben werden).

Klappt leider in der Praxis bisher nicht. Hängt das an der Reihenfolge in der cfg oder ist es "nur noch" ein Konfigruationsproblem? (die diversen Schreibvarianten mit und ohne "/" vorneweg hatte ich ausprobiert).
Gerne hänge ich noch lists an, wenn das erforderlich sein sollte. Was die Reihenfolge angeht: MQTT2_SERVER ist Nr. 378, MQTT2_zigbee_0x90fd9ffffe65db16 NR 380, zigbee_0x90fd9ffffe0bcd51 NR 381 und die Generic-Bridge Nr. 407 (ein Client wird angezeigt).

Wollte nur kurz fragen, ob das grundsätzlich gehen kann, bevor ich da tiefer einsteige...

[rudolfkoenig]

Mit MQTT2_DEVICE alleine sollte es funktionieren (wenn nicht, mir melden).
Mit MQTT_GENERIC_DEVICE tippe ich auf nein, weil hexenmeister es auf die neue Verteilungsmethode anpassen muss, und evtl. noch mehr pruefen/fixen darf.
Und er meinte, er kommt erst in eine Woche dazu.

[Beta-User]

Danke für die Rückmeldung, das hilft mir erst mal, hatte fast vermutet, dass es da noch einer Anpassung bedarf, das eilt nicht.

Und klar: das "Master"-MQTT2_DEVICE funktioniert ordnungsgemäß. Auch das andere MQTT2-"Slave"-Device ist ok, wenn ich es direkt schalte.
Nur der zusätzliche "Slave"-Pfad über die MQTT_GENERIC_BRIDGE am "Slave-Device" will nicht.

Dann warte ich mal, bis hexenmeister das gefixt hat .

@Beide: Klasse Sache, dass ihr da zusammen jetzt einen Weg gefunden habt!

[LudgerR]

ad #29

Schön, dass dies nun implementiert und freigeschaltet werden kann.  Zunächst werde ich auf MQTT2_CLIENT und mosquitto bleiben, um auch Dateien z.B. IP-Cam  snapshots ans MQTT Frontend schicken zu können.

Eine Frage noch.

Ich publishe alle Readings meiner 13 FHTs per MQTT.  Im ersten Anlauf hatte ich den Eindruck das mit dem Republishing (MQTT2 client und mosquitto) Response time Probleme auftauchten, d.h. Das Schalten meiner Shelly/Sonoff und ESP Geräte mittels mqttSubscripe und mqttPublish (Rückkanal) dauerte wesentlich länger, als direkt vom mgtt Dasboard über den Broker und somit ohne Fhem . Da nun eine sehr große Anzahl an inbound-counts in der MQTT_Generic-Bridge auftauchte  vermutete ich hier die Ursache.

Und nun die Frage:   

Wie stark belastet das ungefilterte Republishing von Sensorenwerten die Performance. In der Mehrzahl der Fälle kann die MQTT2_GENERIC_BRIDGE mit diesen topics ja nichts anfangen?

Im MQTT2_CLIENT hatte ich gehofft mit setByTheProgram  im subscriptions Attribute nur die Topics zu subscriben,  die tatsächlich von den MQTT_Devices einschließlich MQTT_GENERIC_BRIDGE aktuell verwendet werden zu begrenzen.
Dies ist mir  jedoch nicht gelungen. 

[rudolfkoenig]

Wie stark belastet das ungefilterte Republishing von Sensorenwerten die Performance.

Ist halt ein Event mehr, was durch FHEM wandert. Da man nicht so haeufig ein Set ausloest, duerfte das vernachlaessigbar sein.

Weiterhin werden die Events erst nach der Benachrichtigung der "richtigen" MQTT-Clients generiert => rePublish wird bei einem einzigen Schalt-Befehl keine Auswirkung haben.