Ankündigung

Einklappen
Keine Ankündigung bisher.

Cometvisu 11.0 Portainer Timberwolf - Protokollfehler Backend invalid response

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

    Cometvisu 11.0 Portainer Timberwolf - Protokollfehler Backend invalid response

    Hallo Zusammen,

    haben mir eben den 11.0 Cometvisu Container gezogen. Irgendwie scheint aber was schief zu laufen. Sobald ich meine Visu öffnen will, kommt foldende Fehlermeldung:

    CV_Fehler.PNG

    Hatte vorher schon erfolgreich mit der Dev. Version gearbeitet. Kann mir da mal bitte jemand helfen?
    Was ist das Backend? :-) Wo kann ich das was einstellen?

    Danke!
    VG
    Tobias

    #2
    Moin,
    selbes Verhalten taucht bei mir mit der 0.11.0 auf.
    Cometvisu 10.2 läuft auf demselben system einwandfrei.
    Primäres System ist Raspbian, Fallbacksystem ist Synology (native).
    CometVisu 0.10.2 (0.11.0 im Test), EIBD auf RaspberryPi A, sowie auf SYNOLOGY DSM 6.2 nativ mit linknx.

    Kommentar


      #3
      Keine Ahnung ob es daran liegt, aber eine wesentliche Änderung zwischen 10 und 11 ist, dass sich der Pfad der Konfig geändert hat. Habt ihr dies beim Mount beachtet? Genaueres ist in der Doku zu finden.

      Gruß Oliver

      Kommentar


        #4
        Erstmal muss man hier zwischen CometVisu im Docker Container oder eben nicht unterscheiden. In Sachen Docker + Timberwolf kann ich leider nicht viel helfen. Sieht jetzt für mich so aus als ob vielleicht der KNXD im Container nicht mehr läuft? Ändert ein Neustart des Containers was an der Situation?

        Und ganz allgemein kann man sich die Kommunikation der CometVisu mit dem Backend in der Netzwerkkonsole des Browsers ganz gut anschauen. Da muss es immer erst ein "login"-Request geben (beim "default"-Backend müsste der Pfad "cgi-bin/l" enthalten), wenn der ok ist folgt eine (oder mehrere) "read"-requests (cgi-bin/r). Bei beiden können Protokollfehler auftreten, also bitte genau auf die Fehlermeldung achten.

        eutelli Wenn Du eine funktionierende 0.10.2 auf dem selben System hast, kann Du die Requests prima vergleichen. Irgendwo muss es da Unterschiede geben.

        Der geänderte Pfad der Config-Dateien hat mit diesen Requests nichts zu tun, wenn die Config nicht gefunden wurde kommt eine andere Fehlermeldung.
        Gruß
        Tobias

        Kommentar


          #5
          So ein Fehler passiert typischer Weise wenn der knxd nicht richtig läuft. Z.B. weil der Port falsch ist oder schon belegt ist.
          TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

          Kommentar


            #6
            danke,
            Pfade sind korrekt,
            Cgi-bin ist auch vollständig.
            Portprobleme hatte ich bis dato nicht, aber das werde ich beobachten, sofern mir dieses möglich ist. Eventuell wird der Pi der ersten Generation jetzt doch zu langsam.
            Ich werde mir die Requestdaten genauer anschauen, vergleichen und mauell anstoßen. Ist aber nach fast 20 Jahren ständiger Aufrüsteng doch schon sehr umfangreich geworden ;-)
            P.S. Danke für die Arbeit , die ihr die letzten Jahre verichtet habt.
            CometVisu 0.10.2 (0.11.0 im Test), EIBD auf RaspberryPi A, sowie auf SYNOLOGY DSM 6.2 nativ mit linknx.

            Kommentar


              #7
              Problem bei mir gelöst.

              DEFEKT:https://WEBSERVERNAME/cgi-bin/r?i=un...ESSION&a=4/3/0.....
              KORREKT:https://WEBSERVERNAME/cgi-bin/r?i=11...ESSION&a=4/3/0...

              Mit Wireshark festgestellt, das i=undefined war und ich damit das backend nicht Aufrufen konnte.

              Das Releaseverzeichnis im Webserver gelöscht und neu installiert, visu_config.xml neu hinkopiert und es läuft.
              Jetzt geht es auf beiden Systemen. Leider habe ich das defekte Verzeichnis nicht gesichert, um Unterschiede zu finden.

              Grüße
              CometVisu 0.10.2 (0.11.0 im Test), EIBD auf RaspberryPi A, sowie auf SYNOLOGY DSM 6.2 nativ mit linknx.

              Kommentar


                #8
                Zitat von Chris M. Beitrag anzeigen
                So ein Fehler passiert typischer Weise wenn der knxd nicht richtig läuft. Z.B. weil der Port falsch ist oder schon belegt ist.
                Hi Chris,

                wie gesagt die die 11er Dev Version läuft ja schon.
                Ich habe jetzt eine zweiten, parallelen Container, für die 0.11.0 (latest) angelegt und jetzt habe ich diese Probleme.

                Wo kann ich denn den Port des knxd ändern? Oder wo kann ich nachvollziehen, dass dieser schon belegt ist? Bin leider nicht wirklich ein Profi :-)

                CV_ports.PNG

                Ist dies hier der relevante Port (gelber Kreis)?
                Wie man sieht habe ich mir nun im CometVisuTest Container auch die "latest" Version gezogen. Jetzt geht es?
                Der untere Container zeigt aber immer noch den Fehler.

                Danke!
                VG
                Tobias

                Kommentar


                  #9
                  Zitat von eutelli Beitrag anzeigen
                  Mit Wireshark festgestellt, das i=undefined war und ich damit das backend nicht Aufrufen konnte.
                  Sehr seltsam, da ich so ein Problem vorher noch nie gesehen habe. Aber ein "i=undefined" darf nicht passieren, habe es daher als Bug in https://github.com/CometVisu/CometVisu/issues/902 aufgenommen.
                  TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                  Kommentar


                    #10
                    Zitat von DeLaDope Beitrag anzeigen
                    Wo kann ich denn den Port des knxd ändern? Oder wo kann ich nachvollziehen, dass dieser schon belegt ist? Bin leider nicht wirklich ein Profi :-)
                    Das geht hier:
                    http://www.cometvisu.org/CometVisu/d...des-containers
                    Sollte der Port von 3700 abweichen, so ist die Umgebungsvariable KNX_INTERFACE entsprechend anzupassen, in diesem Beispiel auf den Wert iptn:172.17.0.1:3674.
                    TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                    Kommentar


                      #11
                      Hi,

                      die 3700 passt fürs Interface. Kann ich diese mehrfach vergeben? Also für beide Container das selbe KNX Interface?
                      Der Timberwolf kann noch parallel mehrere Tunel zum KNX aufmachen, oder hat das damit nichts zu tun?

                      Danke!
                      VG

                      Kommentar


                        #12
                        In den Containern kannst Du den Port so oft vergeben wie Du willst - die Frage ist nämlich eine andere: wie viele Verbindungen akzeptiert dieser Port?

                        So wie ich es verstanden habe (bin da aber kein Experte): wenn ein eibd/knxd diesen Port bereit stellt, so sind mehrere Verbindungen möglich. Wenn es ein Timberwolf macht, so ist nur eine Verbindung möglich. (Und die größeren TWS, die mehrere Tunnel bereit stellen, stellen diese unter unterschiedlichen Portnummern bereit)
                        TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

                        Kommentar


                          #13
                          Ok. Dann müsste ich mal im Elabnet Forum nachfragen oder? Danke Chris! Schönen Abend noch! VG

                          Kommentar

                          Lädt...
                          X