MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[seppelp]

Wie lange sollte es zwischen einer Änderung einer KNX-Gruppenadresse und dem MQTT Publish dauern? Sowohl mit dem Publish Server (v1.4), als auch dem Publish Client (v0.8) habe ich eine Verzögerung von ca. 15 Sekunden zwischen einer Änderung des Wertes in Edomi und dem Empfang im MQTT Explorer.

Im Log sieht es so aus, als ob die Nachricht erst gesendet wird wenn die Verbindung wieder getrennt wird.

2021-05-15 16:35:39	902493	22395	debug	LBS19001053 [v0.8]: Publish: wled/buero/schreibtisch|86 - (428)
2021-05-15 16:35:39	939641	26140	debug	EXE19001053 [v0.8]: MQTT Publish Client started (428)
2021-05-15 16:35:40	041218	26140	debug	EXE19001053 [v0.8]: Publishing topic: wled/buero/schreibtisch with payload: 86 and qos: 1 and retain: 1 (428)
2021-05-15 16:35:55	254800	26140	debug	EXE19001053 [v0.8]: MQTT Publish Client ended (428)

Was könnte der Grund für die Verzögerung sein?

[vento66]

Dauert 100ms. Die kommt sofort an.

[seppelp]

Danke für die Rückmeldung.

Habe jetzt mal mosquitto auf der Edomi Maschine installiert, jetzt funktioniert es sofort. Entweder hat mein anderer Broker (mosquitto im Docker) ein Problem mit dem Zugriff von Edomi - bei anderen Clienten funktioniert es sofort - oder irgendetwas ist falsch eingestellt.

Nutzt jemand die Bausteine mit einem Broker auf einem anderen Host?

[saegefisch]

Zur Info: Ich nutze zwar nicht den Server-LBS aus dem MQTT-Fundus von André, aber Publish Client und Subscribe Client. Damit habe ich die Werte unmittelbar auf dem Broker.
Der Broker (mosquitto) läuft bei mir als Docker-Container auf einem völlig anderen Server. Ich kann in meinem Kontext keine Verzögerung erkennen.

[trollmar]

Zur Info: Ich nutze zwar nicht den Server-LBS aus dem MQTT-Fundus von André, aber Publish Client und Subscribe Client. Damit habe ich die Werte unmittelbar auf dem Broker.
Der Broker (mosquitto) läuft bei mir als Docker-Container auf einem völlig anderen Server. Ich kann in meinem Kontext keine Verzögerung erkennen.

Dito. exakt gleiche config. wollte den Broker auch nicht auf dem edomi Host

[NorbertB]

Bei mir läuft der Broker auf dem Raspi, ich habe auch keine spürbaren Verzögerungen.

[vento66]

jonofe könntest Du dem Subscribe Client noch einen Ausgang spendieren, der die Verbindung zum MQTT Server ausgibt? Ist bestimmt nur eigene Paranoia, aber ich würde gerne auf den Ausfall der Verbindung reagieren können.

[seppelp]

Danke für eure Rückmeldungen. Ich konnte das Problem beheben. Ich hatte die Broker Adresse mit dem Hostnamen und nicht mit der IP angegeben. Mit eingetragener IP-Adresse im LBS funktioniert es ohne nennenswerte Verzögerung mit mosquitto im Docker Container.

[jonofe]

Das spricht aber vermutlich für ein Problem mit deinem DNS, dass du dir mal näher anschauen solltest.

[jonofe]

jonofe könntest Du dem Subscribe Client noch einen Ausgang spendieren, der die Verbindung zum MQTT Server ausgibt? Ist bestimmt nur eigene Paranoia, aber ich würde gerne auf den Ausfall der Verbindung reagieren können.

In Version 0.9 gibt es jetzt einen Ausgang A7, an dem die Exceptions bzgl. der Kommunikation zum Broker ausgegeben werden.
Durch kurzzeitiges Stoppen des Brokers lässt sich dies testen.

[saegefisch]

ich löse das bisher immer mit einem Watchdog hinter den tatsächlichen Werten (A6). Was nützt eine vermeintliche Verbindung, wenn nix mehr kommt; die tatsächlichen Lieferung von Werten/"Nutzlast" find' ich sicherer. Oder ein LBS gibt ein (UNIX-)TS aus, wenn er erfolgreich Daten bekam, um statt an die Werte daran Watchdogs zu hängen mit Eskalation Warn-Mail, Versuch Selbstheilung (re-trigger), Alarm-Mail.

Ein zusätzlicher formatierbarer TS ist dann noch Komfort, damit man sich den nicht noch bauen muss. Auf einer Übersichtsseite sehe ich dann alle TS letzte Lieferungen aller Prozess/Systeme (MQTT, ModBus, erfolgreiche Pings,...)

Daher wäre mir das am LBS lieber gewesen als Exceptions...da scheint mir die erforderliche Logik aufwändiger...aber schön, dass es so wunderbar viele unterschiedliche Lösungen gibt...kann man sich ja alles selber ableiten...divers ist klasse!

[vento66]

Ich hatte mir das schon umgebaut, und an den Stellen, wo der LBS eine Exeption wirft, den Conection Ausgang auf 0 gesetzt. Nach erfolgreicher Verbindung geht der auf 1. Ist mir irgendwie sympathischer, oder ich verstehe das gerade ziemlich falsch. Ich hab mir die neue Version aber noch nicht angeschaut.

[saegefisch]

wenn das 0 oder 1 - dann ist das auch fein. Ich nahm an, es gibt da jetzt echte Exception-Infos... hab's mir auch noch nicht angeschaut.
Wollte nur mal einen anderen Ansatz in den Ring werfen. Dann hat man mehr Optionen, die für sich passende heraus zu suchen...

[jonofe]

könntest Du dem Subscribe Client noch einen Ausgang spendieren, der die Verbindung zum MQTT Server ausgibt?

den Conection Ausgang auf 0 gesetzt. Nach erfolgreicher Verbindung geht der auf 1. Ist mir irgendwie sympathischer,

Oder ein LBS gibt ein (UNIX-)TS aus

Ein zusätzlicher formatierbarer TS ist dann noch Komfort

Jedem Tierchen sein Pläsierchen

edomi.PNG

[saegefisch]

Hallo André,
da haben wir uns missverstanden, sorry. Ich wollte Dir keine Aufwand machen.
Das ist zwar lieb und hilfreich für die Zukunft, aber war gar nicht nötig und auch nicht als Bitte/Aufforderung gemeint, weil ich eine laufende Lösung hinter A6 seit längerem aktiv habe und prima läuft.

Es sollte nur eine Bereicherung/Info sein, wie man die Verfügbarkeit auf unterschiedliche Weisen prüfen kann.

Nun ist's aber gemacht und sage "Danke"!

VG,
Carsten