MQTT Verständnisprobleme - mqttSubscribe

[bismosa]

Hallo!

Ich versuche mich in das Thema MQTT einzuarbeiten...aber so ganz verstehe ich das nicht...der Anfang ist schwer. Oder ich mache ihn mir schwer...
Mein Ziel ist es zwei FHEM Instanzen zu verbinden. Ich benötige eine bidirektionale Kommunikation, da sich die zweite Instanz um IOs kümmern soll.

Das habe ich bereits mit FHEM2FHEM realisiert. (Siehe Link ) Ich mache jetzt erstmal einige tests um herauszufinden, welches für mich der "bessere" Weg ist. Außerdem habe ich mein Sammelsorium an MQTT auf meinem Produktivsystem noch nie verstanden...da wird es mal Zeit sich in das Thema einzuarbeiten...
Als großen Vorteil ggü. FHEM2FHEM sehe ich das Retain bei MQTT. Dann hat man auch aktuelle Werte, wenn mal die Hauptinstanz kurz nicht verfügbar ist. (Sollte eigentlich nicht vorkommen, da beide auf dem gleichen System nur mit unterschiedlichen Konfigurationen läuft, aber zum lernen ist es gut geeignet)

Derzeit nutze ich den FHEM eigenen MQTT2 Server:

Code Auswählen Erweitern

defmod MQTT2_FHEM_Server MQTT2_SERVER 1883 global
Diesen möchte ich dann aber auf Mosquitto ändern, da es in FHEM wohl Schwierigkeiten mit dem Retain geben kann und dies standardmäßig aus gutem Grund abgeschaltet ist. Dann nutze ich lieber einen extra Dienst...dann hat dies auch keine Auswirkung auf FHEM.

Auf meiner 2. FHEM Instanz habe ich nun:
Broker:

Code Auswählen Erweitern

defmod myBroker MQTT2_CLIENT 127.0.0.1:1883
attr myBroker clientId myBrokerIO
attr myBroker clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr myBroker subscriptions setByTheProgram
   
MQTT_GENERIC_BRIDGE:

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric globalDefaults base=FHEMIO/MqttGenericBridge2

setstate mqttGeneric 2024-10-19 11:45:20 IODev myBroker
setstate mqttGeneric 2024-10-19 12:43:20 attrTemplateVersion 20211208_MQTT
setstate mqttGeneric 2024-10-19 12:48:27 device-count 1
setstate mqttGeneric 2024-10-19 11:45:20 incoming-count 0
setstate mqttGeneric 2024-10-19 13:34:00 outgoing-count 5109
setstate mqttGeneric 2024-10-19 13:34:00 transmission-state outgoing publish sent
setstate mqttGeneric 2024-10-19 11:45:20 updated-reading-count 0
setstate mqttGeneric 2024-10-19 11:45:20 updated-set-count 0

dazu habe ich dann noch ein Device auf der 2. Instanz, bei dem ich

Code Auswählen Erweitern

attr Firmata_OUT mqttPublish value:topic={"$base/$device/$name"}
gesetzt habe. Zum testen wird der Wert im sekundentakt neu gesetzt.

der Publish funktioniert nun auch einwandfrei:

Code Auswählen Erweitern

FHEMIO/MqttGenericBridge2/Firmata_OUT/value on
FHEMIO/MqttGenericBridge2/Firmata_OUT/value off
FHEMIO/MqttGenericBridge2/Firmata_OUT/value on
FHEMIO/MqttGenericBridge2/Firmata_OUT/value off


Auf der Hauptinstanz habe ich nun neben dem Server ein MQTT2_DEVICE (Siehe Link ):

ein MQTT2_DEVICE mit bridgeRegexp versehen, was aus jedem MQTT topic:message ein clientId generieren kann, und damit das Zuordnen zum richtigen MQTT2_DEVICE ermoeglicht. Alles was bridgeRegexp nicht verteilen kann, landet beim ersten MQTT2_DEVICE.

Code Auswählen Erweitern

defmod MQTT2_myMqttServer MQTT2_DEVICE
attr MQTT2_myMqttServer bridgeRegexp myBrokerIO:FHEMIO/MqttGenericBridge2/([A-Za-z0-9_]*)/.*:.* "mgb2_$1"\

Nun wurde mir durch Autocreate auch sofort ein neues MQTT2_DEVICE angelegt:

Code Auswählen Erweitern

defmod MQTT2_mgb2_Firmata_OUT MQTT2_DEVICE mgb2_Firmata_OUT
attr MQTT2_mgb2_Firmata_OUT readingList FHEMIO/MqttGenericBridge2/Firmata_OUT/value:.* value
attr MQTT2_mgb2_Firmata_OUT room MQTT2_DEVICE

Soweit so gut.
1.) die readingList ist angegeben mit
FHEMIO/MqttGenericBridge2/Firmata_OUT/value:.* value
Beim MQTT2_DEVICE mit bridgeRegexp "MQTT2_myMqttServer" (den Devicenamen muss ich noch unbedingt anpassen)
myBrokerIO:FHEMIO/MqttGenericBridge2/.....

Warum muss bei der einen die clientId mit angegeben werden und beim anderen nicht?

2.) Nun möchte ich kein MQTT2_DEVICE verwenden sondern nur ein Reading in z.B. einem DOIF verwenden.
Dies versuche ich nun schon die ganze Zeit über das Attribut mqttSubscribe in meiner Hauptinstanz zu erreichen.
In der Hauptinstanz habe ich dafür ebenfalls eine generic_bridge eingerichtet:

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric globalDefaults sub:base=mqttGeneric/set pub:base=mqttGeneric

Aber es ist egal, wie ich versuche das Attribut mqttSubscribe zu setzen...es kommt kein Reading an:

Code Auswählen Erweitern

value:stopic={"FHEMIO/MqttGenericBridge2/Firmata_OUT/value"}

Könnt ihr mir bitte etwas Starthilfe geben? 

Gruß
Bismosa

[bismosa]

Hallo!

       
Ich habe gerade ein shutdown restart gemacht. Nun funktioniert es mit
   
value:topic={"FHEMIO/MqttGenericBridge2/Firmata_OUT/value"}

Keine Ahnung was da los war 
Fehler 30...das Problem sitzt 30cm vor dem Bildschirm 

Frage 1 bleibt aber immer noch bestehen.

Dann kann ich mich nun weiter damit beschäftigen.

Vielleicht mal was generelles zur Doku:
Die Doku ist wirklich klasse! Vielen Dank an alle fleißigen! Wenn man das "System" erstmal verstanden hat, ist es auch wirklich logisch!

Was mir anfangs nicht klar wurde (ich hoffe das ich das nicht immer noch falsch verstanden habe):
- Nutzt man nur den FHEM MQTT2-Server, braucht man nichts weiteres. Per Autocreate werden die MQTT2-DEVICE bereits angelegt und auch ein publish ist schon möglich.
- Nutzt man einen externen MQTT Server (Mosquitto), benötigt man den MQTT2_CLIENT (der dann fast das gleiche abbildet wie der FHEM MQTT2-Server)
- Der Eintrag "MQTT (Modul)" (https://wiki.fhem.de/wiki/MQTT) hatte mich verwirrt. Ich dachte anfangs, das ich das benötige (wer nicht bis zum Ende liest ist halt doof)
- Autocreate ist beim MQTT2_CLIENT standardmäßig deaktiviert
- MQTT_GENERIC_BRIDGE wird nur benötigt, wenn man in anderen nicht MQTT Geräten in FHEM die entsprechende Steuerung benötigt

Dazu kommt dann halt, das man versucht vieles durch googeln bzw. Forumssuche zu finden...hier finden sich natürlich auch immer veraltete Beispiele...das verwirrt dann zusätzlich.


Gruß
Bismosa

[TomLee]

Dazu kommt dann halt, das man versucht vieles durch googeln bzw. Forumssuche zu finden...hier finden sich natürlich auch immer veraltete Beispiele...das verwirrt dann zusätzlich.

Hallo,

deine Erkenntnisse die Du hier teilst sind schon richtig, wenn Du da weiter "eintauchst" sind vmtl. auch nur noch wenige Fragen offen, die hier im Forum nicht schon Thema waren.
Darum halt, mMn., nur die veralteten Beispiele.

Gruß Thomas

[bismosa]

Hallo!
Natürlich nur die veralteten Beispiele. Die aktuellen sind da schon oft sehr gut!
Wenn man nicht so tief im Thema ist, ist es oft schwierig festzustellen, das etwas schon wieder "veraltet" ist...
Vielleicht wird ChatGPT in Zukunft ja noch ein bisschen schlauer. Die ein oder andere Frage konnte ich mir damit auch beantworten.
Z.B. hatte ich Anfangs den Mosquitto laufen. Hier hatte ich dann (wegen der fehlenden clientId) arge Probleme mich mit 2 FHEM Instanzen zu verbinden. 

Gruß
Bismosa

[Beta-User]

Mosquitto laufen. Hier hatte ich dann (wegen der fehlenden clientId) arge Probleme

? Habe Schwierigkeiten, den Zusammenhang zu sehen... Sowohl MQTT (altes IO) wie MQTT2_CLIENT benutzen - wie alles, was sich mit einem MQTT-Server verbinden will - eine ClientId .

Diesen möchte ich dann aber auf Mosquitto ändern, da es in FHEM wohl Schwierigkeiten mit dem Retain geben kann und dies standardmäßig aus gutem Grund abgeschaltet ist. Dann nutze ich lieber einen extra Dienst...dann hat dies auch keine Auswirkung auf FHEM.

Dir ist aber schon klar, dass auch mit Mosquitto per default kein retain-Wert einen Serverneustart überlebt? (zumindest war das früher so). 
MAn. löst "retain" in der Regel nicht so viele Probleme wie man vermuten könnte. Irgendwo gab es mal einen Thread, der sich mit "sende bei reconnect" des MQTT2_CLIENT befasst hatte. Ist zwar auch nicht ohne weiteres der Problemlöser für alle Fälle, aber imo gefühlt "besser" als jede retain-Lösung...

[bismosa]

? Habe Schwierigkeiten, den Zusammenhang zu sehen... Sowohl MQTT (altes IO) wie MQTT2_CLIENT benutzen - wie alles, was sich mit einem MQTT-Server verbinden will - eine ClientId

Jup. Und die ist gleich dem Device-Namen in FHEM. Zwei Instanzen...gleicher Name...und schon wundert man sich, das beide sich nicht mehr richtig connecten können 

Dir ist aber schon klar, dass auch mit Mosquitto per default kein retain-Wert einen Serverneustart überlebt?

Serverneustart nicht. Das ist mir klar. Einen FHEM (Instanz) Neustart jedoch schon.

Bin mir aber noch nicht schlüssig, ob ich wirklich den Mosquitto verwende. Das ist halt etwas komplizierter in der Einrichtung...und das nur für retain....
retain kann ja auch gefährlich werden. Wenn noch ein alter Stand im retain ist, und dann ungewollt Aktionen ausgelöst werden.
Der FHEM MQTT2-Server ist da schon richtig gut 

Im Test klappen beide Varianten bei mir mittlerweile. Weitere tests folgen, müssen aber aufgrund Zeitmangels ein paar Wochen verschoben werden 

Gruß
Bismosa

[Beta-User]

Bin mir aber noch nicht schlüssig, ob ich wirklich den Mosquitto verwende. Das ist halt etwas komplizierter in der Einrichtung...und das nur für retain....

MAn. bringt dir retain schlicht keinen Vorteil: Solange der MQTT-Server läuft, haben beide FHEM-Instanzen aktuelle Daten. Werden die sauber beendet, paßt alles auch nach einem Neustart wieder.
Ausnahme: alles, was zwischen Beendigung und Neustart der jeweils einen Instanz auf der anderen passiert. Ist aber m.E. auch nicht wesentlich anders mit Mosquitto: solange der weg ist, fehlen halt auch Daten...
Keine Ahnung, ob F2F das besser kann...