Mosquitto und MQTT2_SERVER parallel

Begonnen von Jojo11, 06 November 2025, 16:11:21

Vorheriges Thema - Nächstes Thema

Jojo11

Hallo,

ich verwende einen MQTT2_SERVER über Port 1883 und einen Mosquitto auf dem selben Gerät über Port 1888, angebunden mit MQTT2_CLIENT. Einige Devices verwenden Port 1888, andere Port 1883. Soweit funktioniert das wunderbar.
Nun habe ich beobachtet, dass die Readings eines MQTT2_DEVICE, welches über 1883 angebunden ist, sich ändern, sobald ich den MQTT2_CLIENT auf Port 1888 aktiviere.
Die MQTT Pakete von extern kommen alle 5 Minuten, aber sobald sie korrekt in Readings angezeigt werden, werden sie einige Sekunden später auf 0 gesetzt, ohne dass neue Pakete von extern kommen. Deaktiviere ich den MQTT2_CLIENT, bleiben sie unverändert.
Kann ich diese beiden Umgebungen nicht parallel verwenden sondern muss mich für eine entscheiden?

schöne Grüße
Jo

Beta-User

#1
Das geht schon.

Aber man muss (für publish) sicher stellen, dass das richtige IO verwendet wird und - das dürfte (mal wieder keine Info zu den Geräten...) hier das Problem sein - die Topics dürfen nicht gleich sein.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Jojo11

#2
Danke für den Schubs in die richtige Richtung. Die IODevs sind korrekt gesetzt aber die topics muss ich nochmal überprüfen. Es sollte nicht aber könnte sein, dass es da Überschneidungen gibt  ::)

[update]
Sehr interessant. Es handelt sich um ein Fahrzeug, dessen Daten ich mit volvo2mqtt auslese. Mit MQTT Explorer schaue ich mir beide Ports an und empfange auf beiden die Daten. Vergleiche ich den Kilometerstand, so hinkt die Geister-Instanz ein paar km zurück - das müssen etwas ältere Daten sein. Wenn ich volvo2mqtt stoppe, kommen über den richtigen Port keine Daten mehr, aber die Geisterdaten kommen nach wie vor (über den mosquitto). Keine Ahnung, wer die sendet, aber ich mache mich mal auf die Suche...
Glaub "persistence true" schaue ich mir mal genauer an.

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Jojo11

#4
Das wollte ich mir auch als nächstes anschauen. Immerhin habe ich den Sender auf dem 1883er Port jetzt stoppen können durch das Löschen des persistance cashs - da waren wohl noch von früheren Tests ein paar Daten. Aber die Werte flippen immer noch nach ein paar Sekunden.

Was mich wundert: Im MQTT explorer ändern sich die Werte nicht sondern sind exakt so wie sie sein sollten. Als ob fhem die Werte nachträglich ändert.

Beta-User

Klingt immer noch nach retain (iVm. Reconnects).
Oder fhem hängt.

Nachträglich irgendwo Daten wiederherzustellen ist jedenfalls keine übliche Funktion der MQTT-Module :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

betateilchen

Der Irrglaube mit dem retain-Flag liegt darin, dass viele Anwender nicht verstehen, dass ein topic, das mit retain-Flag gesendet wird und ein gleiches topic, das ohne retain gesendet wird, für mosquitto zwei verschiedene Datensätze sind.

Das topic mit dem retain flag wird vom Server so lange bei jedem connect verschickt, bis es auf dem Server gelöscht wird. Egal, wie oft das topic inzwischen auch ohne retain verschickt wurde.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!