Ankündigung

Einklappen

Hinweis

Die Forenregeln wurden überarbeitet (Stand 7.11.22). Sie sind ab sofort verbindlich. Wir bitten um Beachtung.
Mehr anzeigen
Weniger anzeigen

eibd(war bcusdk) Fork -> knxd

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

    Hallo Marc,

    mit der Adresse 0.0.0 bewegt man sich schon außerhalb des Standards.

    Zitate:
    Zitat von 03_02_06 Communication Medium KNX IP v01.00.01 AS.pdf
    In general a KNXnet/IP Router may be used as a Line Coupler or a Backbone Coupler. The Individual Address has the format x.y.0, with x = 1 to 15 and y = 0 to 15.
    Zitat von 03_05_03 Configuration Procedures v01.05.02 AS.pdf
    This is a Coupler with Individual Address.
    This is a not allowed Situation.
    Aber ignorieren wir das mal. Die Sublinie eines IP-Routers mit Adresse 0.0.0 ist dann logischerweise der Backbone 0.0, mit Medientyp TP. Eine Hauptlinie gibt es nicht.

    Gruß, Klaus

    Kommentar


      0.0.0 ist Topologisch und in eibd/knxd schlicht falsch, es gibt auch bereits einen Issue dafür.
      @Jan: vielen Dank für die Hinweise!!

      Makki
      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
      -> Bitte KEINE PNs!

      Kommentar


        Zitat von Klaus Gütter Beitrag anzeigen
        Aber ignorieren wir das mal. Die Sublinie eines IP-Routers mit Adresse 0.0.0 ist dann logischerweise der Backbone 0.0, mit Medientyp TP. Eine Hauptlinie gibt es nicht.
        ok.

        Einen Router auf 0.x.0 gibt es dann ja generell nicht.
        Sind dann Netzwerkkoppler (Weltenkoppler) "illegal" oder wird das am Namen festgemacht?


        Zitat von makki Beitrag anzeigen
        0.0.0 ist Topologisch und in eibd/knxd schlicht falsch, es gibt auch bereits einen Issue dafür.
        Daher ja die Frage.
        BR
        Marc

        Kommentar


          Zitat von saft6luck Beitrag anzeigen
          Einen Router auf 0.x.0 gibt es dann ja generell nicht.
          Doch, erlaubt ist ein IP-Backbone mit durch IP-Router angekoppelten Linien 0.1 bis 0.15.

          Zitat von saft6luck Beitrag anzeigen
          Sind dann Netzwerkkoppler (Weltenkoppler) "illegal" oder wird das am Namen festgemacht?
          Je nun; "illegal" würde ich nicht direkt sagen. Mit Weltenkopplern verlässt man wohl den Bereich, der im KNX Standard definiert ist. Daher gibt es da auch unterschiedliche Ansichten, was das genau sein soll.

          Aus meiner Sicht muss ein "Weltenkoppler" nicht nur Gruppenadressen filtern, sondern ggf. auch address translation machen - und unicasts und broadcasts keinesfalls weiterleiten - und den HopCount neu auf 6 setzen - und möglicherweise die Quelladresse ändern. In diesen Sinne ist seine Position in der Topologie eigentlich egal.

          Es gibt aber auch im Markt Geräte, die eigentlich IP-Router sind, sich zu einem "Weltenkoppler" wandeln, wenn sie die Adresse 0.0.0 bekommen.

          Gruß, Klaus

          Kommentar


            Zitat von Klaus Gütter Beitrag anzeigen
            Doch, erlaubt ist ein IP-Backbone mit durch IP-Router angekoppelten Linien 0.1 bis 0.15.
            Das widerspricht aber irgendwie deinem Zitat von vorher, oder?

            Je nun; "illegal" würde ich nicht direkt sagen. Mit Weltenkopplern verlässt man wohl den Bereich, der im KNX Standard definiert ist. Daher gibt es da auch unterschiedliche Ansichten, was das genau sein soll.
            Also ist ein IP-Router bzw. sein Profil nicht für die 0.0.0 vorgesehen. Technisch kann er natürlich auf der 0.0.0 platziert werden, er muss dann aber ein "Weltenkoppler" oder was auch immer werden.

            Was darf denn laut KNX Standard auf die 0.0.0? Ist das eine noch zu definierende Position in der Topologie oder ist nur nicht festgelegt, welches Gerät dort positioniert werden kann bzw. gibt es keines?

            Aus meiner Sicht muss ein "Weltenkoppler" nicht nur Gruppenadressen filtern, sondern ggf. auch address translation machen - und unicasts und broadcasts keinesfalls weiterleiten - und den HopCount neu auf 6 setzen - und möglicherweise die Quelladresse ändern. In diesen Sinne ist seine Position in der Topologie eigentlich egal.
            Ja, klingt schlüssig. (Egal heißt aber auch, 0.0.0 ist eigentlich ok?)

            Die erweiterten Funktionen muss aber nicht notwendigerweise der Weltenkoppler erledigen, oder?
            Auch ein nachgeschalteter PC kann diese Funktionen übernehmen, wie es die Hersteller der Router vorgesehen hatten.

            Es gibt aber auch im Markt Geräte, die eigentlich IP-Router sind, sich zu einem "Weltenkoppler" wandeln, wenn sie die Adresse 0.0.0 bekommen.
            Erfüllen die dann aber überhaupt eines deiner Kriterien an Weltenkoppler? Wird die Filtertabelle von der ETS5 überhaupt bedient?
            BR
            Marc

            Kommentar


              Stresstests

              Zitat von makki Beitrag anzeigen
              Aber für banale Dinge/Fehler wären automatische Tests schon hilfreich..
              Hmm. Man nehme drei (verschiedene) KNX/USB- oder KNX/Seriell-Adapter und schreibe ein Testprogramm, das jeweils einen mit Nachrichten bombardiert und verifiziert, dass diese bei den beiden anderen ankommen. (Mit Bestätigungen.) Zusätzlich generiere man mit einem µC ein paar zufällige Busstörungen.

              Nicht allzu schwierig, das. Ich könnte ein solches Testsystem an meinem Test/Build-Rechner anklemmen und dem Ganzen einmal Netzteil+Drossel und einen busware-Adapter spendieren. Und Microcontroller liegen hier auch zur Genüge herum.

              Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)
              DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

              Kommentar


                Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)
                Ich könnte bei mir in der Firma auch so einen Testaufbau machen. Wir haben 4/5 USB Adapter da liegen. Ich bekomme auch bald ein USB-TPuart adapter. Mit welchem man schöne Fehler am Bus generieren kann. Haben auch noch einiges an andere KNX Hardware herumliegen.

                Kommentar


                  Zitat von Elwedritsche Beitrag anzeigen
                  Kleiner Tipp: 1) Das "Echo" vom TP-UART ist die Basis für die L_Data.conf, also die Information darüber, was aus einem L_Data.req am Ende auf dem Bus geworden ist (abweichende Definition der Crtl Field (1/2) Flags für L_Data.conf im Gegensatz zu L_Data.req beachten).
                  Ich halte den TPUARTS Code im knxd eh für problematisch. Da wird meiner Meinung nach einiges nicht so richtig behandelt. Ich möchte da aber fürs erste nicht viel ändern.
                  Über das Control field hab ich mir für den Fix auch schon gedanken gemacht. Eigentlich sollte das etwas unschärfer verglichen werden, oder? Bitmaske müsste wohl 0xFC sein. Sonst sollte das ursprüngliche Problem damit behoben sein, ohne das Verhalten sonst zu beeinflussen.

                  Zitat von Smurf Beitrag anzeigen
                  Nicht allzu schwierig, das. Ich könnte ein solches Testsystem an meinem Test/Build-Rechner anklemmen und dem Ganzen einmal Netzteil+Drossel und einen busware-Adapter spendieren. Und Microcontroller liegen hier auch zur Genüge herum.

                  Wer mag sich noch beteiligen? Mit nur einem Adapter geht das nicht. ;-)
                  Zitat von p3root Beitrag anzeigen
                  Ich könnte bei mir in der Firma auch so einen Testaufbau machen. ... Haben auch noch einiges an andere KNX Hardware herumliegen.
                  Ich könnte auch ein Testsystem zur Verfügung stellen. Netzteil, Drossel, FT12-Interface, TPUARTS Interface und ein sparsammer Server hab ich hier. Ich kann das gerne so einrichten, dass ihr da über ssh dran arbeiten könnt.

                  Wir sollten nur planen wie das umgesetzt werden soll. Für unit tests sollte ein entsprechendes framework verwendet werden. Ich bin da offen für alles. Hab mal boost für verwendet und sonst verschieden wo ich nicht mal mehr die namen kenne. Eines war speziell zum testen von IP basierten Protokollen. Vielleicht kennt da ja jemend was passendes.

                  Kommentar


                    Nachdem ich länger flach gelegen habe bin ich heute endlich mal dazu gekommen OSX 10.10 in einer VM zu installieren und dort den knxd noch einmal zu übersetzen.

                    Ich dokumentiere das gerne, wie und wo wäre das denn am zweckmäßigsten, zur Zeit habe ich nur eine Stichwortliste? Da wäre dann auch die Frage, in welcher Granularität dokumentiert werden soll. Reicht z.B. $PATH muss "/opt/local/bin" enthalten oder soll das detailliert beschrieben werden?

                    Außerdem schlage ich zwei kleine Änderungen am Code vor, damit er unter OSX ohne Änderungen übersetzbar ist:

                    1. bootstrap.sh
                    Code:
                    #!/bin/sh
                    
                    LIBTOOLIZE="libtoolize";
                    
                    if [[ $OSTYPE == *"darwin"* ]]
                    then
                      LIBTOOLIZE="glibtoolize";
                    fi
                    
                    $LIBTOOLIZE --copy --force --install && \
                    	aclocal --force && \
                    	autoheader && \
                    	automake --add-missing --copy --force-missing && \
                    	autoconf
                    2. src/libserver/eibnetserver.cpp

                    #include <malloc.h> durch folgenden Code ersetzen:

                    Code:
                    #ifdef __APPLE__
                    #include <malloc/malloc.h>
                    #else
                    include <malloc.h>
                    #endif

                    Kommentar


                      Code:
                      #!/bin/sh
                      if [[ $OSTYPE == *"darwin"* ]]
                      Das Konstrukt mit "[[" ist nicht POSIX-konform. Du willst /bin/bash. Oder ein Konstrukt mit case…esac.
                      DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

                      Kommentar


                        Hast recht, auf dem MAC klappt das mit /bin/sh, daher ist es mir nicht aufgefallen.

                        Also z.B. so:

                        #!/bin/sh

                        case "$OSTYPE" in
                        *"darwin"*) LIBTOOLIZE="glibtoolize" ;;
                        * ) LIBTOOLIZE="libtoolize";;
                        esac

                        $LIBTOOLIZE --copy --force --install && \
                        aclocal --force && \
                        autoheader && \
                        automake --add-missing --copy --force-missing && \
                        autoconf

                        Kommentar


                          Zitat von Jockel Beitrag anzeigen
                          Ich dokumentiere das gerne, wie und wo wäre das denn am zweckmäßigsten, zur Zeit habe ich nur eine Stichwortliste?
                          Entweder im wiki oder im code z.B. doc/INSTALL.macos

                          Zitat von Jockel Beitrag anzeigen
                          Da wäre dann auch die Frage, in welcher Granularität dokumentiert werden soll. Reicht z.B. $PATH muss "/opt/local/bin" enthalten oder soll das detailliert beschrieben werden?
                          Ja, meiner Meinung nach reicht das. Es sollte ja eher eine Anleitung sein für jemeand der sich mit dem System schon auskennt und auf der Kommandozeile arbeiten kann. Wichtiger ist es eher auf typische Fehler (und deren Behebung) hinzuweisen. Z.B. was vorher installiert werden muss.

                          Zitat von Jockel Beitrag anzeigen
                          1. bootstrap.sh
                          das ist eigentlich nur als unterstützung für die Entwicklung gedacht. In einem Release wird configure schon enthalten sein. Man kann die tools auch einfach sirekt aufrufen, ist nur etwas aufwendig wenn man das häufiger macht (wegen änderungen an autoconf dateien, oder wenn man öffters auf einen sauberen branch wechselt). Falls vorhanden kann stattdessen auch einfach "autoreconf --force --install" verwendet werden. Es darf aber auch gerne jemand arbeit ins bootstrap.sh skript stecken ...

                          Zitat von Jockel Beitrag anzeigen
                          2. src/libserver/eibnetserver.cpp
                          #include <malloc.h> durch folgenden Code ersetzen:
                          Das ist der falsche weg. Wenn dann über configure auf header testen und entsprechend verwenden.
                          Hier halte ich das aber für einen Fehler. malloc.h sollte gar nicht verwendet werden. Einfach mal ganz rausnehmen. Falls da doch eine Funktion verwendet wird, sollte das geändert werden. Ich denke aber eher das der header versehentlich eingebunden wird.

                          Kommentar


                            Hallo zusammen,

                            ich würde euch gerne unterstützen, beispielsweise testen auf Ubuntu. Einen für automake 1.14 notwendigen patch hab' ich schon auf Github in die Issues gestellt.

                            Grundsätzlich würde ich mir langfristig wünschen, wenn knxd client Verbindungen optional per SSL verschlüsseln würde.

                            Außerdem würde ich mir für die 'tools' wünschen, wenn sie immer wiederkehrende (und feststehende) Parameter aus einer config Datei lesen könnten:

                            Code:
                            groupreadresponse 8/0/1
                            wenn in der .knxdtools config folgendes eingetragen ist
                            Code:
                            # knxdtools config file, Jan 2015
                            
                            url=ip:127.0.0.1
                            Viele Grüße,

                            Klaus

                            Kommentar


                              Zitat von LittleKNX Beitrag anzeigen
                              Außerdem würde ich mir für die 'tools' wünschen, wenn sie immer wiederkehrende (und feststehende) Parameter aus einer config Datei lesen könnten:
                              Mir wäre eine entsprechende Umgebungsvariable lieber. Das lässt sich flexibler handhaben.
                              Code:
                              > export KNXURL=local:/tmp/eib
                              > knxgroupreadresponse 4/7/11
                              Max

                              Kommentar


                                ... ist auch ok, wenn so lange die Anzahl der Parameter gering bleibt.

                                Kommentar

                                Lädt...
                                X