Ankündigung

Einklappen
Keine Ankündigung bisher.

kein Programmieren möglich; knxd läuft aber

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

    kein Programmieren möglich; knxd läuft aber

    Hallo zusammen,

    ich kann keine physikalische Adresse programmieren. Zum Testen verwende ich einen 8fach-Taster von MDT.


    KNXD scheint aber zu laufen?!

    Im Detail: knxd.service und knxd.socket laufen, in der ETS sehe ich die Schnittstelle (Test = ok), in der ETS funktioniert der Busmonitor, per knxtool groupswrite geschriebene Telegramme sehe ich auch im Busmonitor.


    /etc/knxd.conf
    KNXD_OPTS="-e 1.1.1 -E 1.1.2:9 -D -T -S -b ipt:192.168.0.70"

    Wobei das die IP-Adresse des RasPi ist.

    Den Programmierknopf drücke ich, LED leuchtet rot. Mittlerweile habe ich auch schon den Taster neu verkabelt, um das auszuschließen.

    Woran könnte es liegen?

    Vielen Dank für eure Hilfe,
    Thomas
    Angehängte Dateien

    #2
    Ich kann auch seit neustem über den knxd mit dem BAOS Modul 838 nicht mehr Programmieren.
    Openhab funktioniert damit sehr gut, im ETS funktionieren die ganzen BUS Monitor Funktionen, nur Programmieren geht nicht.
    Ich Programmiere über den noch Vorhandenen KNX-Router. Wobei der eigentlich ersetzt werden sollte.
    --
    Gruß
    Lothar

    Kommentar


      #3
      Zitat von ettoretti Beitrag anzeigen
      /etc/knxd.conf
      KNXD_OPTS="-e 1.1.1 -E 1.1.2:9 -D -T -S -b ipt:192.168.0.70"

      Wobei das die IP-Adresse des RasPi ist.
      Wenn 192.168.0.70 die IP des RasPi ist, wie soll denn knxd mit dem Bus verbunden sein? An diese Stelle gehört die IP eines KNX Interface, welches mindestens einen Tunnel unterstützt. Wenn es sich um einen KNX Router handelt wäre "-b ip:" (ohne IP) korrekt.

      EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail

      Kommentar


        #4
        Danke für eure Unterstützung!

        Ich versuche einen Busware USB Interface (TUL) am RasPi 3 zum laufen zu bringen.


        Nach Recherche glaube ich, dass der korrekte Eintrag sein müsste:

        Code:
        KNXD_OPTS="-e 1.1.1 -E 1.1.1:8 -D -T -R -S -b tpuarts:/dev/knx1"

        Im Vorfeld habe ich dazu dev/knx1 anhand der offiziellen Anleitung hinzugefügt
        https://github.com/knxd/knxd#adding-...-usb-interface

        Code:
        sudo nano /etc/udev/rules.d/70-knxd.rules
        ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", KERNELS=="1-1.1.2", SYMLINK+="knx1", OWNER="knxd"

        Folgender Post war schlüssig, was meint ihr?
        ipt ist für eine IP Tunnel Verbindung, also zB wenn der knxd mit Hilfer einer IP Schnittstelle auf den Bus zugreifen soll. Du willst ja gerade, dass der knxd den TPUART benutzt, also darf als Schnittstelle definitive kein "ipt:IP" stehen, sondern "tpuarts:/dev/DEIN-DEVICE". Für letzteres empfielt sich eine udev Regel, die nicht nur die Rechte wie nötig setzt, sondern ggf (mehrere ACM devices) auch einen eindeutigen Namen vergibt. Alles erklärt hier: https://github.com/knxd/knxd#adding-...-usb-interface
        https://knx-user-forum.de/forum/%C3%...31#post1126431


        leider mag es trotzdem noch nicht klappen.

        Was denkt ihr, woran könnte es liegen?

        knxd status.PNG

        Kommentar


          #5
          ist der User der knxd startet auch mitglied von der Gruppe dialout?
          --
          Gruß
          Lothar

          Kommentar


            #6
            ich habe das versucht jetzt zu recherchieren, user pi ist in der Gruppe dialout. Siehe Anhang.

            Vielleicht hängt es wirklich an der Verknüpfung /dev/knx1, hier scheint irgendetwas nicht zu funktionieren?

            Angehängte Dateien

            Kommentar


              #7
              Hallo,

              ich habe jetzt meinen RasPi 3 neu aufgesetzt (letzte Raspbian Stretch), knxd frisch installiert und mich strikt an die github-Anleitung gehalten.


              Leider noch immer ohne Erfolg.

              Was ich beobachten kann: die grüne LED am TUL-Stick leuchtet für ~ 2 Sekunden, erlischt wieder für ~5 Sekunden, usw.
              In den zwei Sekunden, in denen die LED grün leuchtet, gibt mir zumindest die Service-Abfrage eine vernünftige Antwort.

              Kann sich das jemand erklären? Was kann ich machen?
              Angehängte Dateien

              Kommentar


                #8
                @ettoretti
                bist du dir sicher, das knxd als User pi läuft?

                Bei mir läuft der knxd unter dem User knxd.
                Deshalb habe ich in der /etc/group den knxd auch dem dialout zugeordnet.

                Code:
                cat /etc/group |grep dial
                dialout:x:20:pi,knxd
                Das ist zwar sehr großzüge verteilte Rechte, aber ist für mich einfacher als die udev Regel. Wobei bei dir due UDEV-Regel wohl funktioniert.
                Hast du den USB-Stick an einem USB-Hub mit 5v Speisung, nicht das der Strom vom RPI nicht reicht den Stick zu versorgen.
                --
                Gruß
                Lothar

                Kommentar


                  #9
                  Der Strom vom Pi sollte für den Stick mehr als ausreichen – den "interessanten" Teil holt sich der Stick vom KNX-Bus.

                  Generell sollte man sich für den Dauerbetrieb eines RasPi immer ein Netzteil mit 5.1V (nicht 5V!) und min 2.5A holen, und ggf. über Kühlkörper(chen) nachdenken. Damit gehören sämtliche Stabilitätsprobleme der Vergangenheit an.

                  "Erlaubt" sind 5% Toleranz (nach oben … theoretisch auch nach unten, praktisch kann man das vergessen), mithin 5.25V.
                  1wire, KNX, OpenHAB, Python, Asterisk, SMD-Lötkolben

                  Kommentar


                    #10
                    Hi.
                    Leider muss ich mich auch noch mal zu dem initialen Thema melden. "Keine Programmierung mit knxd"

                    Ich bin erst gestern auf den knxd umgestiegen, habe bisher immer noch den alten eibd genutzt. Da es damit in der Vergangenheit immer mal wieder Probleme gab und ich mal ein wenig spielen wollte bin ich auf den knxd umgestiegen.

                    Smurf Erst mal vielen DANKE für deine Arbeit diesbezüglich.

                    Ich denke, es ist bei mir auch nur ein config Proglem. Ich nutze ein MDT USB-Interfacht am knxd. Das ganze läuft in einem Docker Container. Soweit klappt auch alles. Sowohl die Homebridge als auch openHab laufen ohne Probleme. Auch in der ETS werden die Interfaces angezeigt und können über die Busmonitor genutzt werden. Möchte ich jetzt jedoch ein Gerät programmieren, bekomme ich eine Fehlermeldung:
                    "Programmierung fehlgeschlagen, Gerät antwortet nicht."

                    Da ich mich mit dem neuen ini file noch nicht auseinander gesetzt habe nutze ich noch die alten Parameter.
                    /usr/bin/knxd -t 65535 -D -T -R -S -i -u --eibaddr=1.1.128 -E 1.1.200:5 usb:

                    Wie ihr seht habe ich schon den LOG - Level voll aufgedreht, doch ich als Laie kann auf Anhieb leider nichts erkennen.

                    Vielen Dank für die Hilfe.
                    Gruß
                    bb
                    Zuletzt geändert von bigblue1735; 09.11.2018, 16:14.

                    Kommentar


                      #11
                      HI bigblue1735: Die knxd.ini kann sehr einfach erstellt werden. Man muss knxd durch knxd_args ersetzrn.

                      Code:
                      /usr/lib//knxd_args -t 65535 -D -T -R -S -i -u --eibaddr=1.1.128 -E 1.1.200:5 usb:
                      In einem anderen Beitrag habe ich gelesen, das ein Parameter "single" sehr wichtig ist.

                      Code:
                      filters = D.pace,single
                      [D.pace]
                      delay = 30
                      filter = pace
                      Diese Parameter wird in dem Beitrag erwähnt.
                      Ich wünsche dir noch viel Erfolg.

                      Zuletzt geändert von Smurf; 10.11.2018, 19:05. Grund: Sektion D.pace repariert
                      --
                      Gruß
                      Lothar

                      Kommentar


                        #12
                        Äh, ja. Allerdings sollte man die Argumentreihenfolge beachten, sonst kann's schiefgehen. Im Klartext:
                        * globale Debug-Optionen und so
                        * -e und -E
                        * für jeden Treiber:
                        * erst die Optionen die den Treiber betreffen
                        * dann -S oder -b… oder …
                        * dann die Optionen für die vom systemd übergebenen Sockets
                        1wire, KNX, OpenHAB, Python, Asterisk, SMD-Lötkolben

                        Kommentar

                        Lädt...
                        X