MQTT2_CLIENT: VerständnisFrage zu setByTheProgram im subscriptions Attribut

Begonnen von LudgerR, 19 Januar 2019, 13:42:47

Vorheriges Thema - Nächstes Thema

LudgerR

Frage zu MQTT2_CLIENT:   setByTheProgram  im subscription Attribute

Ich habe eine Verständisfrage zu dem Parameter setByTheProgram

Was passiert, wenn ich


attr MQTT2_Client  subscriptions  setByTheProgram


definiere?

Werden alle meine Subscription Definitionen des   MQTT_GENERIC_BRIDGE devices  und alle readingList Subscriptionen der MQTT2_DEVICE(s) gesammelt und als Filter verwendet.

Irgenwie stehe ich auf dem Schlauch. 

Um nicht von unnötigen Sensorenwerten, die ich per mqttPublish ans mqtt Frontend schicke, geflutet zu werden habe ich mir bisher einen Filter selbst gewählt, der diese Payloads ausfiltert.
Eigentlich benötigte ich einen Exclude.(Könnte ich natürlich machen, indem ich ein passendes MQTT2_DEVICE mit entsprechender ReadingsList anlege).

Was ist die beste Vorgehensweise um unnötigen Inbound Traffic von der MQTT_GENERIC_BRIDGE heraus zu filtern? Meine payloads  fuer die mqtt Stromschalter (Sonoff, ESP, Shelly) sollen möglichst nicht darunter leiden (d.h. möglichst kurze Feedback Zeiten für den Rückkanal).

Man könnte solch eine Exkludierung - / Limitierungsfilter auch an der GENERIC_BRIDGE festmachen und somit auch im Zusammenspiel mit MQTT2_SERVER verwenden.

Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

hexenmeister

Dieses Attribut definiert subscriptions, die bei dem MQTT-Broker angemeldet werden. Default ist #, also 'sende mir alles'.
Die Einstellung 'setByTheProgram' erlaubt der GenericBridge die dort verwendeten (und nur diese) Subscriptions zu setzen. Im allgemeinen wird dabei eine Mischung von MQTT2_DEVICEs und GenericBridge nicht mehr sinnvoll, da die MQTT2_DEVICEs keine Nachrichten bekommen, die nicht auch die GenericBridge kennt.

Exclude gibt es bei MQTT nicht, es wird nur das gesendet, was bestellt wurde.

Somit ist 'nein' die Antwort auf deine Frage
ZitatWerden alle meine Subscription Definitionen des   MQTT_GENERIC_BRIDGE devices  und alle readingList Subscriptionen der MQTT2_DEVICE(s) gesammelt und als Filter verwendet.

Exclude an der Bridge hat mit Subscriptions rein gar nichts zu tun.

Mir ist nicht klar, wieso bzw. unter welchen Umständen deine fhem-Instanz mit Nachrichten geflutet wird.

ZitatWas ist die beste Vorgehensweise um unnötigen Inbound Traffic von der MQTT_GENERIC_BRIDGE heraus zu filtern? Meine payloads  fuer die mqtt Stromschalter (Sonoff, ESP, Shelly) sollen möglichst nicht darunter leiden (d.h. möglichst kurze Feedback Zeiten für den Rückkanal).

Was meinst Du mit 'inbount Traffic' und 'heraus'? Ist das nicht ein Widerspruch?
Damit Bridge keine unnötigen Nachrichten sendet, sollte man nur diejenige definieren, die man auch braucht.
Am besten niemals 'globalPublish'  verwenden, es sei denn, man weiß wirklich genau was man tut!

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

LudgerR

Zunächst bzgl.  setByTheProgram


defmod MQTT2_FHEM_Server MQTT2_CLIENT localhost:1883
attr MQTT2_FHEM_Server autocreate 0
attr MQTT2_FHEM_Server room SYSTEM
attr MQTT2_FHEM_Server subscriptions setByTheProgram SH/XX/#
attr MQTT2_FHEM_Server verbose 4

setstate MQTT2_FHEM_Server opened
setstate MQTT2_FHEM_Server 2019-01-20 11:20:10 started


Im ausgeXten Fall siehe oben werden die folgenden mqttSubscribe Definitionen nicht ausgeführt.



defmod MQTT2_ESPClient59 MQTT2_DEVICE ESPClient59
    :
attr MQTT2_ESPClient59 mqttSubscribe state:set-topic={"SH/EG/E2/licht/ESP_59/cmd"}




defmod MQTT2_DVES_E55C02 MQTT2_DEVICE DVES_E55C02

attr MQTT2_DVES_E55C02 IODev MQTT2_FHEM_Server

attr MQTT2_DVES_E55C02 mqttPublish state:topic={"SH/EG/E2/licht/sonoff-7170/state"}
attr MQTT2_DVES_E55C02 mqttSubscribe state:set-topic={"SH/EG/(E2|ALL)/licht/(sonoff-7170|ALL)/cmd"}



Ändere ich das subscriptions Attribut auf



attr MQTT2_FHEM_Server subscriptions setByTheProgram SH/EG/#



funktioniert alles wie gewünscht.

Was (mache ich | ist) falsch?


und mit



attr MQTT2_FHEM_Server subscriptions setByTheProgram



werden die set-topic Definitionen auch nicht ausgeführt
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)

LudgerR

19:05 Uhr

Leider war meine unten gegebenen Findings nicht richtig !!!

Mit setByTheProgram komme ich nicht klar.   Ohne zusätzliche Einträge im Attribut subscriptions Funktioniert das Schalten der Geräte mittels mqttSubscribe und Rückkanal über mqttPublish nicht.

Ist die Verwendung von setByTheProgram  mit weiteren SubscriptionsEinträgen zulässig?


-------------------------------------------------------------
-------------------------------------------------------------
Gebe mir selbst mal die Antwort:

Das Literal setByTheProgram  muss der einzige Wert im subscriotions Attribute sein. Zusätzliche Topics kann man nicht angeben.

Unglücklicherweise habe ich den Fall mit 


attr MQTT2_FHEM_Server subscriptions setByTheProgram



nur mit dem zweiten Device


defmod MQTT2_DVES_E55C02 MQTT2_DEVICE DVES_E55C02

attr MQTT2_DVES_E55C02 IODev MQTT2_FHEM_Server

attr MQTT2_DVES_E55C02 mqttPublish state:topic={"SH/EG/E2/licht/sonoff-7170/state"}
attr MQTT2_DVES_E55C02 mqttSubscribe state:set-topic={"SH/EG/(E2|ALL)/licht/(sonoff-7170|ALL)/cmd"}



getestet, der nicht funktionierte.


Der etwas komplexere Substription-Definition wird anscheinend bei Verwendung von setByTheProgram nicht unterstützt.
Bei expliziter Angabe im subcriptions Attribut  als SH/EQ/#  wird die Auflösung in entsprechende  Subscriptions wunschgemäß durchgeführt.

Bleibt die Frage  warum  unter "setByTheProgram"  das obige Konstrukt nicht unterstützt wird.

Meine anderen Überlegungen hinsichtlich Filterungen sind somit obsolet.
Fhem/mosquitto/zigbee2mqtt  on PI 3+ , 2xCUNO, 13xFHT, EM1000 WZ/GZ, FS20,AMAD,SONOS, MQTT (Sonoff/Shelly),Buderus GB-112,CanOverEthernet(UVR67/CIM)