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

    #46
    vento66: MQTT Subscribe Server v0.4 sollte nun auch JSON als Payload verarbeiten können.

    Kommentar


      #47
      Hi jonofe ,

      ich habe gerade den Publish Server LBS v0.2 in Betrieb genommen. Der Mosquitto läuft in einer eigenen VM. Habe ihn auch erfolgreich getestet mit der MQTT App auf dem iPhone und sowohl mosquitto_pub als auch mosquitto_sub.

      Wenn ich nun EDOMI bzw den LBS starte, erhalte ich alle paar Sekunden folgende Meldung im mosquitto.log

      Code:
      New connection from [IP-VON-EDOMI] on port 1883.
      Socket error on client <unknown>, disconnecting.
      Hast Du einen Tipp für mich?

      Vielen Dank für Deine Mühe.

      Grüße

      Matthias

      Kommentar


        #48
        Das kannst du ignorieren. Zur Optimierung mache ich vor dem Publish einen kurzen Check, ob der Broker verfügbar ist, d.h. einfach Connect zu Port 1883 und direkt wieder Disconnect. Dadurch erscheint das im Mosquitto Log.

        Kommentar


          #49
          Alles klar, läuft sehr geschmeidig. Jetzt brauch ich nur noch nen geeigneten Client für iOS.

          Danke Dir!

          Kommentar


            #50
            Zitat von vento66 Beitrag anzeigen
            Broker und Edomi auf einer Maschine zu jeder Menge seq-counter Fehler führen. Da sind deine LBS aber scheinbar unschuldig, da es mit einem externen Broker funktioniert
            vento66 Micha, welche Art von KNX Anbindung verwendest du im Zusammenhang mit den MQTT LBS? Und welche Hardware für den EDOMI Server hast du im Einsatz? Auch wenn ich den MQTT Broker und Node-Red auf einem RPi betreibe, habe ich immer noch vereinzelt SeqCounter Errors (ca. einen pro Stunde). Mein Edomi System läuft als Virtualbox VM mit 4GB Speicher und KNX via eibd und KNX USB Interface. Frage mich, ob an der KNX Anbindung oder an der Performance des EDOMI Servers schrauben muss...

            Kommentar


              #51
              jonofe Hi André!
              Pah jetzt musste ich erst mal nachschauen. Die MQTT LBS laufen auf einem Testsystem in einer VM in xenserver mit 4 Kernen und 2 GB RAM. Dort läuft auch der eibd. Edomi greift über eibd und einen Enertex Router auf den KNX zu. Eibd hab ich eigentlich immer auf dem Edomi Rechnern mitlaufen. Wenn ich mal Zeit habe ziehe ich die LBS auf das Lifesystem um. Das ist dann ein Apu2c4 mit installierten eibd
              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


                #52
                Okay, ich denke ich werde auch mal einen KNX Router auf meine Einkaufsliste schreiben. Mein eibd läuft auch meinem EDOMI Produktionssystem. Da greift also das DEV und das Produktionssystem drauf zu. Auf dem Produktionssystem gibts keinerlei Fehler. Deutet für mich eher drauf hin, dass ich mein DEV System eher mal upgraden sollte oder genau wie du planst, die LBS auf das Produktionssystem umziehen. Das ist ein NUC (Celeron), der ausschließlich EDOMI macht.

                Kommentar


                  #53
                  Ich hoffe, dass die Probleme mit den SeqCounter Errors nun gelöst sind. Ich habe das Timing der Kommunikation zwischen dem MySQL Trigger Skript und dem MQTT Broker optimiert, so dass nun hoffentlich keine Folge-Timing-Probleme bei der KNX Kommunikation mehr auftreten. Bei mir funktioniert dies zumindet mit aktiviertem MQTT Publish Server und einem MQTT Subscribe Client der $SYS/# subscribed bislang problemlos. Und diese beiden LBS erzeugen schon eine ganze Menge Traffic auf dem MQTT Broker.

                  Hier sind die vier Updates der MQTT LBS zu finden:

                  MQTT Publish Server LBS 19001051 v0.3
                  MQTT Subscribe Server LBS 19001052 v0.5
                  MQTT Publish Client LBS 19001053 v0.2
                  MQTT Subscribe Client LBS 19001054 v0.2.1

                  Feedback natürlich gerne hier, insbesondere, ob noch Probleme mit den Sequence Counter Fehlern auftreten.

                  Viel Spaß damit ....

                  Kommentar


                    #54
                    Hallo jonofe ,
                    der 19001053 v0.2 wirft mit diese Fehler ins Fehler-Logg und füllt über Nacht den RAM auf über 90%.
                    Ob die alte Version betroffen war kann ich nicht sagen, da ich Diese nicht installiert hatte.
                    Ich habe aktuell 4 dieser Bausteine parallel im Einsatz.

                    Code:
                     [TABLE="border: 0, cellpadding: 0, cellspacing: 0"]
                    [TR]
                    [TD]2017-06-13 08:59:43[/TD]
                     			[TD]881160[/TD]
                     			[TD]?[/TD]
                     			[TD]7085[/TD]
                     			[TD]Exception: The connection was lost.[/TD]
                     			[TD]EXCEPTION[/TD]
                     		[/TR]
                    [TR]
                    [TD]2017-06-13 09:18:03[/TD]
                     			[TD]878699[/TD]
                     			[TD]?[/TD]
                     			[TD]30611[/TD]
                     			[TD]Exception: The connection was lost.[/TD]
                     			[TD]EXCEPTION[/TD]
                     		[/TR]
                    [TR]
                    [TD]2017-06-13 09:36:23[/TD]
                     			[TD]939007[/TD]
                     			[TD]?[/TD]
                     			[TD]21683[/TD]
                     			[TD]Exception: The connection was lost.[/TD]
                     			[TD]EXCEPTION[/TD]
                     		[/TR]
                    [TR]
                    [TD]2017-06-13 09:54:43[/TD]
                     			[TD]910233[/TD]
                     			[TD]?[/TD]
                     			[TD]12762[/TD]
                     			[TD]Exception: The connection was lost.[/TD]
                     			[TD]EXCEPTION[/TD]
                     		[/TR]
                    [/TABLE]
                    Gruß
                    Wolfgang
                    Gruß Wolfgang
                    __________________________________________________ ____
                    HS

                    Kommentar


                      #55
                      Der 53er ist eigentlich der LBS, der die wenigsten Probleme bereiten sollte, da dieser ja nur aufgerufen wird, wenn er getriggert wird, d.h. immer nur einmalig durchläuft und sich dann beendet, also kein Daemon, der Speicher fressen kann. Das Speicherproblem würde ich jetzt erstmal woanders vermuten.
                      Die o.g. Fehler können natürlich auftreten, wenn die Verbindung verloren geht. Stehen die im Log des 53er Bausteins?

                      Kommentar


                        #56
                        Nein im Log vom 53 stehen keine Fehler, diese Fehler stehen im EDOMI Fehler-Log, ich hab jetzt mal die Logik Seite mit dem 53er deaktiviert und beobachte.
                        Begonnen hat das "Speicherfressen" mit dem gleichzeitigen Update aller MQTT Bausteine. Ich beobachte jetzt mal weiter.
                        Gruß Wolfgang
                        __________________________________________________ ____
                        HS

                        Kommentar


                          #57
                          Geht denn die Anzahl der PHP Prozesse hoch?

                          EDIT: Habe mir die Änderungen im Publish Client noch mal angeschaut. Außer des TLS Statements ist eigentlich gar nichts im eigentlich Ablauf hinzugekommen. Und wenn TLS ausgeschaltet ist, dann sollte kein Unterschied bestehen.
                          Zuletzt geändert von jonofe; 13.06.2017, 18:27.

                          Kommentar


                            #58
                            Nochmal eine allgemeine Anmerkung zu der Timing/SeqError Problematik.
                            Ich frage mich ja ernsthaft, wie es passieren kann, dass sowas wie diese MySQL Trigger z.B. bei meinem Celeron G3900-System für Probleme bei der Edomi-KNX-Kommunikation sorgen kann (ist ja ein extra Prozess). Für mich deutet es wirklich daraufhin, dass da etwas in PHP 5.3 im Argen liegt.
                            Ich meinem anderen Thread hatte ich ja bzgl. der SeqErrors auch festgestellt, dass es irgendwie an der Art der Systemlast liegt.


                            Kommentar


                              #59
                              Zitat von Nanosonde Beitrag anzeigen
                              Nochmal eine allgemeine Anmerkung zu der Timing/SeqError Problematik.
                              Ich frage mich ja ernsthaft, wie es passieren kann, dass sowas wie diese MySQL Trigger z.B. bei meinem Celeron G3900-System für Probleme bei der Edomi-KNX-Kommunikation sorgen kann (ist ja ein extra Prozess). Für mich deutet es wirklich daraufhin, dass da etwas in PHP 5.3 im Argen liegt.
                              Ich meinem anderen Thread hatte ich ja bzgl. der SeqErrors auch festgestellt, dass es irgendwie an der Art der Systemlast liegt.

                              Nach dem letzten Update sind bei mir keine SeqCounterErrors mehr aufgetreten. Das Problem lag aus meiner Sicht im Skripts welches von der MySQL Trigger Procedure aufgerufen wird. Mosquitto-PHP benötigt zur Abarbeitung jeglicher Kommandos einen oder mehrere Aufruf der loop() Funktion. Der Timeout der Loop Funktion stand auf 1 Sekunden. Da mir nicht wirklich klar ist, wieviele loop() Aufrufe notwendig sind, hatte ich je 3 spendiert. Nach der Anpassung des Timeouts auf 100ms, habe ich keinen SeqCounter Error mehr gehabt. Vermutlich hat MySQL auf die Abarbeitung des Scripts gewartet und wenn die loop() in den 1s Timeout gelaufen ist und inzwischen KNX Telegramme ankamen ist vermutlich das Timingproblem aufgetreten.

                              Hat noch jemand nach dem letzten Update SequenceCounter Fehler, die durch MQTT ausgelöst wurden?

                              Kommentar


                                #60
                                Hi,

                                ich hatte vor 3 Tagen einen Stromausfall, leider noch ohne USV. Da EDOMI danach nicht mehr sauber lief (keine Kommunikation, etc) habe ich das letzte Backup über die Oberfläche eingespielt.

                                Allerdings funktioniert der MQTT Publish Server seitdem nicht mehr. Ich habe die V 0.3 eingespielt und die komplette Setup-Routine noch einmal durchgeführt. Es scheint so als ob nicht mal ein Connect-Versuch zum Broker unternommen wird, das LOG dort ist leer.

                                Habe die Logikseite einmal gelöscht und neu erstellt. Trotz Log-Level 8 wird überhaupt kein LOG erstellt.

                                Kann ich abgesehen von dem Individual-Log noch irgendwo nach Fehlermeldungen des LBS suchen?

                                Grüße

                                Matthias

                                Kommentar

                                Lädt...
                                X