Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054
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.
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...
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.
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!
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.
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 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.
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
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.
Zuletzt geändert von saegefisch; 16.05.2021, 00:27.
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?
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.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: