Ankündigung

Einklappen
Keine Ankündigung bisher.

MQTT API Server und MQTT Clients - LBS19001051 - LBS19001054

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    Kommentar


      Hallo miteinander

      Zitat von DerSeppel Beitrag anzeigen
      Hm, kann es sein dass "yum install gcc" eine alte version des GCC installiert?
      Möglich ist bekanntlich alles...


      Zitat von DerSeppel Beitrag anzeigen
      Mann könnte mal das file patchen und ein "
      #include <stdint.h>" einfügen.
      Na dann lass mal hören, an welcher Stelle.


      Zitat von DerSeppel Beitrag anzeigen
      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.


      Zitat von jonofe Beitrag anzeigen
      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.
      Kind regards,
      Yves

      Kommentar


        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

        Kommentar


          Zitat von DerSeppel Beitrag anzeigen
          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/

          Kommentar


            Zitat von givemeone Beitrag anzeigen
            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...

            Kommentar


              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.

              Kommentar


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

                Kommentar


                  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.

                  Kommentar


                    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.
                    Grüße
                    Sebastian

                    Kommentar


                      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.
                      Zuletzt geändert von jonofe; 03.05.2021, 07:46.

                      Kommentar


                        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....

                        Kommentar


                          Zitat von givemeone Beitrag anzeigen

                          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.

                          Kommentar


                            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?
                            Mfg Micha
                            Ich sage ja nicht, das wir alle dummen Menschen loswerden müssen, aber könnten wir nicht einfach alle Warnhinweise entfernen und den Dingen ihren Lauf lassen?

                            Kommentar


                              Zitat von vento66 Beitrag anzeigen
                              Darf ich auch mal ein Problem haben?
                              Ausnahmsweise

                              Zitat von vento66 Beitrag anzeigen
                              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...

                              Kommentar


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

                                Kommentar

                                Lädt...
                                X