MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

[jonofe]

Vielleicht sollte das mal in einem anderen Thread fortgesetzt werden. Geht ja inzwischen eher grundsätzlich um Containerization als um die MQTT LBS.

[starwarsfan]

Hallo miteinander

Hm, kann es sein dass "yum install gcc" eine alte version des GCC installiert?

Möglich ist bekanntlich alles...

Mann könnte mal das file patchen und ein "
#include <stdint.h>" einfügen.

Na dann lass mal hören, an welcher Stelle.

Anderer Ansatz:
Man könnte Edomi als Stack aufsetzen und dedizierte Container für MQTT, MySQL etc. erstellen. Wenn schon Docker, dann richtig Docker
Dann könnte man auf nen fertigen MySQL Container setzen und kann die services einzeln updaten.

Lass Dich nicht aufhalten, ich bin dann aber raus. Mein Ziel ist, dass sich Edomi im Container möglichst identisch zur Blech-Version verhält, um den Wartungsaufwand möglichst gering zu halten. Und so eng wie Edomi mit dem System "verheiratet" ist, wird das ein derber Umbau. Insbesondere hinsichtlich der automatischen Backups, der LBS-Integration und dem User-Support hier.

Vielleicht sollte das mal in einem anderen Thread fortgesetzt werden. Geht ja inzwischen eher grundsätzlich um Containerization als um die MQTT LBS.

Bzgl. dem was DerSeppel angerissen hat, definitiv. Das Build-Problem hat zwar nicht direkt etwas mit Containerization zu tun aber kann durchaus auch separat behandelt werden.

[givemeone]

Hallo Zusammen,
MQTT selbst ist für mich leider recht neu. Ich habe hier alle 45S gelesen, jedoch dazu nichts entdeckt.
Ich benutze den LBS19001051 und bin sehr happy damit.
Jedoch habe ich einen Anwendungsfall, für den ich hier keine Lösung finde.
Für einen gewissen Fall erhalte ich ausschließlich bei AUSFALL einer Heizung Alternativwerte (Temperaturen, etx) per MQTT.
Das klappt auch, da der Sender die Werte nur sendet, wenn die Hauptheizung keine Werte liefert.
Jedoch bei jedem Edomi-Start, werden sämtliche Werte
die mit "edomi/set/internal/###" am Server liegen geholt und geschrieben.
Kann ich irgendwie verhindern, dass dieser den ersten Wert beim Start von Edomi(oder eben beim aktivieren des LBS) übernimmt?
Danach soll alles so bleiben wie es aktuell ist.

sG
Joe

[givemeone]

Man könnte Edomi als Stack aufsetzen und dedizierte Container für MQTT, MySQL etc. erstellen. Wenn schon Docker, dann richtig Docker
Dann könnte man auf nen fertigen MySQL Container setzen und kann die services einzeln updaten.

Wo kommt diese Philosophie noch her?
Docker selbst ist davon abgegangen! https://docs.docker.com/develop/deve...est-practices/

[jonofe]

Jedoch bei jedem Edomi-Start, werden sämtliche Werte
die mit "edomi/set/internal/###" am Server liegen geholt und geschrieben.

Das hab ich nicht verstanden? Meinst du mir "Server" den Broker?
Der Publish Server sendet auf edomi/status/#.
edomi/set/# sollte zum Subscribe Server gehören.
Mir ist nicht klar, was du machen möchtest...

[givemeone]

Servus.
Bei jedem Edomi-Start verbindet sich ja dieser LBD "Subscribe server" mit dem Publish-Server.
Letzterer hat ja noch Werte gespeichert.
Wenn Edomi nun startet, werden vom Publish Server alle Edomi-MQTT Objekte angefragt und
alle Werte innerhalb von Edomi gesetzt.
Die Ojekte am MQTT-Server sind ja wie beschrieben mit "edomi/set/internal/1234" hinterlegt.

Ich möchte nun verhindern, dass beim Edomi-Start die Variable 1234 direkt initialisiert wird,
da meine Daten am Publish-Server per Definition "alt" sind! Dieser ist deaktiviert und aktiviert sich nur beim Ausfall
des Hauptgerätes.
Ich möchte gerne, dass diese Variablen in Edomi von dem LBS erst geschrieben/aktualisiert werden, wenn Edomi schon läuft und sie sich am
Publish-Server ändern. Es soll also nur rein der erste Wert beim Edomi-Start ignoriert werden.

[jonofe]

Der Publish Server published auf edomi/status/#
der Subscribe Server subscribed auf edomi/set/# und edomi/get/#
Da sollte per Default nix passieren.

[givemeone]

Nein. Die ErsatzHeizung selbst published auf edomi/set/#.
Wenn sie jedoch nicht aktiv sind, sind die Werte in edomi/set/# teilweise seehr alt!

Darum hätte ich gerne, dass bei einem Edomi-Start diese NICHT gelesen/übernommen werden, sondern erst, wenn dort nach dem Edomi-Start
neue Werte eintreffen.

[seppelp]

Sind bei den Nachrichten der ErsatzHeizung Retained Flags gesetzt? Wenn diese nicht gesetzt sind, sollten die Nachrichten auch nicht bei einem Neustart wieder in Edomi erscheinen.

Hier unter "Retained Messages" auf https://mosquitto.org/man/mqtt-7.html nachzulesen.

[jonofe]

Sie werden nicht gelesen. Set Werte werden vom Broker gepublished, wenn er sie von einem Client bekommt. Das geht auch nicht anders.
Das von dir beschriebene Verhalten kann eigentlich nur auftreten, wenn deine Heizung mit gesetztem Retain Flag published.
Befehle auf edomi/set/... sollten nie mit gesetztem Retain Flag gepublished werden.

[givemeone]

Tatschlich haben manche das Retain-Flag, andere nicht.
Danke für die Spur, muss jetzt prüfen, wo das her kommt.
Die Heizung bietet das in der Oberfläche nicht an....

[DerSeppel]

Wo kommt diese Philosophie noch her?
Docker selbst ist davon abgegangen! https://docs.docker.com/develop/deve...est-practices/

Das wird für diesen Thread zu spezifisch denke ich. Aber 1) ist mir das neu, verfolge Docker nicht so im Detail, 2) lese ich das aus dem Link so nicht raus. Ich vermute du verweist auf "Decouple applications"? Da steht doch genau das: Nur ein Prozess pro Container.

[vento66]

Darf ich auch mal ein Problem haben? Bei mir sendet der Publish Server V1.3 keine Daten von KNX GA, auch nicht wenn in der Notitz MPUB drinnsteht. interne KO werden versendet. Gibts da noch einen Trick?

[jonofe]

Darf ich auch mal ein Problem haben?

Ausnahmsweise

Bei mir sendet der Publish Server V1.3 keine Daten von KNX GA, auch nicht wenn in der Notitz MPUB drinnsteht. interne KO werden versendet. Gibts da noch einen Trick?

Schau ich mir mal an...

[jonofe]

Ich konnte das Problem reproduzieren. Es war ein Fehler im Matching der KNX GAs.
Mit der Version 1.4 sollte es jetzt hoffentlich funktionieren.