Ankündigung

Einklappen
Keine Ankündigung bisher.

Grundlagen zum knxd (mit Installationsanleitung! Vor dem Schreiben lesen!)

Einklappen
Dieses Thema ist geschlossen.
X
Das ist ein wichtiges Thema.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Grundlagen zum knxd (mit Installationsanleitung! Vor dem Schreiben lesen!)

    knxd ist ein Programm, das KNX-Pakete zwischen verschiedenen Schnittstellen und Programmen weiterleiten kann.

    In diesem Thema findet ihr grundlegende Informationen zu Einrichtung und Konfiguration. Bitte erst lesen, dann verstehen, und dann eine Frage stellen.

    Den Sourcecode der "stabilen" Version findet ihr hier: https://github.com/knxd/knxd/tree/stable

    Dort gibt es auch eine Installationsanleitung und den Bugtracker (auf englisch).
    Wenn du nicht weißt, ob ein Problem ein Fehler im knxd ist oder nicht: bitte erst hier fragen.
    Zuletzt geändert von Smurf; 23.02.2017, 09:29.
    DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

    #2
    Optionen

    Der knxd versteht ziemlich viele Optionen (und bis zur Einführung einer Konfigurationsdatei wird das auch so bleiben). Wichtig: Optionen werden der Reihe nach abgearbeitet! Was er alles versteht, steht in der Onlinehilfe, die man mit "knxd --help" abfragen kann.
    • Allgemeine Einstellungen


    Darunter fallen zB die Einstellungen, welche Protokolldaten ausgegeben werden (-t XXX).

    Dieser Bereich wird mit den Optionen "-e 9.9.1" und "-E 9.9.2:8" abgeschlossen. Die Busadressen sind willkürlich gewählt und müssen bei euch natürlich frei sein. "-e" ist die eigene Adresse des knxd; -E ist der Adressbereich, der automatisch Programmen zugewiesen wird, die sich mit dem knxd verbinden. Dazu später mehr.

    Danach folgen
    • Verbindungs-spezifische Einstellungen


    Der knxd kennt eine Reihe von Wegen, mit KNX-Geräten oder -Programmen zu reden. Die Abfolge ist immer
    • erst Optionen, die die darauffolgende Verbindung (und nur die) in irgendeiner Weise modifizieren (die können natürlich fehlen)
    • dann die Option, welche Art Verbindung es sein soll


    Verbindungsarten
    • lokale Hardware

    Dafür brauchen wir die Option "-b typ:Parameter…", also zB "-b tpuarts:/dev/ttyKNX1". Welche Typen der knxd kennt und welche Parameter sie brauchen, steht in der Hilfe.
    • Hardware im Netzwerk

    Für solche Geräte gibt es ein standardisiertes Tunnel-Protokoll. Die Option lautet vollständig "-B single --send-delay=70 -b ipt:192.168.1.33" (oder welche IP-Adresse oder welcher Hostname auch immer euer Interface hat). Die Verbindung läuft über UDP-Port 3671.
    Das "-B single" braucht man bei manchen dieser Teile, weil sie davon ausgehen, dass sich über sie nur ein einzelner Client anschließt statt eines ganzen KNX-Netzes; der knxd muss folglich die Hardwareadressen verstecken. Das ist vor Allem dann relevant, wenn man Geräte programmieren will.
    Den "--send-delay=70" braucht man bei vielen dieser Interfaces, wenn sie sich bei vielen gleichzeitigen Anfragen verschlucken. Symptom: die Visualisierung startet, fragt 20 Geräte nach ihrem Status, und bekommt nur von 20 eine Antwort.
    • Multicast

    Manche dieser Schnittstellen sind vollwertige knx-Router, die das lokale Netzwerk so behandeln wie ein drahtgebundenes KNX. Mit "-b ip:" kann man dem knxd sagen, dass er auch Multicast betreiben soll. Bei einigen Routern muss man diese Funktion erst mit der ETS konfigurieren.

    Ein Router, der auch Tunnel ist, darf nicht gleichzeitig mit "-b ipt:" und mit "-b ip:" angesprochen werden. In diesem Fall ist Multicast vorzuziehen. (Das funktioniert aber nur im lokalen Netzwerk. Schlimmer: manche ältere WLAN-Router können kein Multicast.)
    • knxd-fähige Programme

    Für die Kommunikation mit dem knxd gibt es ein eigenes Protokoll. Manche Programme verstehen das. Mit der Option "-u" sagt man dem knxd, dass er unter "/run/knx" einen Unix-Socket zur Verfügung stellen soll, über den sich die mit ihm unterhalten können.

    Wenn das Programm nicht auf demselben Rechner läuft, dann ist mit einem Unix-Socket nicht geholfen; mit "-i" öffnet man einen TCP-Socket auf Port 6720, über den auch Programme übers Netz mit dem knxd reden können.

    Eines dieser Programme ist "knxtool", mit dem man auf den KNX-Bus schreiben oder aktuelle Werte abrufen kann.
    • Standard-KNX-Programme

    So wie man mit "-b ipt:" mit einem Tunnel-Interface oder mit "-b ip:" mit einem Router im lokalen Netz reden kann, so kann der knxd diese Dienste auch selbst bereitstellen. Dazu gibt es die Optionen "-D -T -R -S". Letztere öffnet den eigentlichen Mutlicast-Port. Die anderen drei modifizieren das -S und sagen ihm, was es tun soll und darf:
    "-D" erlaubt das Antworten auf Anfragen vom Typ "welche Router gibt es denn im lokelan Netz?"
    "-R" aktiviert den Multicast-Router.
    "-T" aktiviert den Tunnel-Server.

    Achtung: "-R" und "-b ip:" dürfen nicht gleichzeitig verwendet werden. (Zumindest nicht mit derselben Multicast-Adresse.) Wer eine IP-Schnittstelle hat, die routet und tunnelt, darf auch nicht gleichzeitig "-R" und "-b ip:" verwenden.
    • … und sonst:

    Group Cache: Der knx-Bus ist nicht dafür gedacht, dass jemand regelmäßig kommt und ein Gerät fragt, welchen Zustand es gerade hat – dazu ist die Datenrate zu niedrig. Stattdessen soll das Gerät bitte eine Nachricht schicken, sobald sich der Zustand ändert. Damit nun eine Visualisierung o.Ä. beim Neustart trotzdem erfahren kann, welchen Zustand die verwalteten Geräte haben, gibt es im knxd einen Zwischenspeicher, den man mit der Option "-c" aktiviert. Der speichert die letzte Nachricht auf allen Gruppenadressen (und damit den Gerätezustand). Die Visu kann das abfragen und auf neue Nachrichten reagieren, ohne selber Busteilnehmer zu sein.

    DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

    Kommentar


      #3
      Fehlersuche

      Option der Wahl zum Fehlersuchen ist "-f9 -t 1022". Die 1022 ist eine Bitmaske, kann man auch hexadezimal angeben (hier: 0xffe). Welche Bits was bedeuten, steht in den Sourcen; außerdem steht in jeder geloggten Zeile, welches Bit für sie verntwortlich ist. Generell ist Bit 0 am hardware-nähesten (deshalb hier auch aus, weil man es fast nie braucht).

      '-t' ist sowohl generisch (dann kommt sie am Anfang, d.h. vor der '-e'-Option) als auch schnittstellenspezifisch (vor dem entsprechenden -b/-i/-u/-S). Damit kann man selektiv nur die Logs einschalten, die (hoffentlich) relevant sind.

      Wo finde ich die Logs?

      Das hängt davon ab, ob auf deinem Rechner systemd läuft und wie er konfiguriert ist. Mit systemd und Journal kann man alles, was der knxd seit dem letzten Neustart von sich gegeben hat, so aufrufen:
      Code:
      journalctl -u knxd.service -b
      Mit "-n100" statt "-b" liefert er die letzten 100 Zeilen, und mit "-f" schreibt er in Echtzeit mit was der knxd gerade so von sich gibt.

      Ohne systemd, oder mit einem systemd das ohne Logging konfiguriert ist, findet man die Logs entweder irgendwo unter /var/log, zB in /var/log/messages oder /var/log/syslog … oder gar nicht. Dann muss man den knxd anhalten und manuell starten.

      Kleiner Exkurs zum Logging:
      Ein Rechner mit einer SD-Karte, wie der Raspberrry Pi, sollte unbedingt nur ins RAM protokollieren, weil er sonst über kurz oder lang die SD-Karte schrottet. Dazu schreibt man in die /etc/systemd/journald.conf:

      Code:
      Storage=volatile
      ForwardToSyslog=no
      Danach am besten neustarten.

      Was mache ich mit den Logs?

      Aufmerksam lesen. In den meisten Fällen erledigt sich das Problem von selber.

      Wenn das nichts hilft: hier ein neues Thema aufmachen und fragen. Mehr als zehn Zeilen Log bitte nicht direkt hier einstellen, sondern in einen Pastebin kopieren. Hier direkt reinkopierte Logs unbedingt zwischen CODE-Tags setzen (das ist im erweiterten Editor die '#'-Taste), sonst sind sie unleserlich.
      DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

      Kommentar


        #4
        Start des knxd
        • Ohne systemd

        Unter Debian finden sich die Optionen in "/etc/default/knxd", mit "/etc/init.d/knxd start" o.Ä. sollte es loslaufen. Start beim Systemstart:
        Code:
        update-rc.d knxd defaults
        Nicht vergessen: /etc/default/knxd anpassen: die Zeile "START_KNXD=no" auf "START_KNXD=yes" ändern.
        • Mit systemd

        Mit systemd ist das Ganze ein bisschen kompizierter, aber dafür kann der systemd auch mehr.

        Socket-Aktivierung
        Die Optionen "-u" und "-i" werden unter systemd nicht benötigt, weil die entsprechenden Ports bereits vom systemd offen gehalten und an den knxd weitergegeben werden. Das hat den Vorteil, dass man nicht auf die Reihenfolge achten muss, in der die diversen Programme gestartet werden. Zum "Ausgleich" kann man den knxd nicht mehr ohne Weiteres manuell laufen lassen. (Will man aber auch nicht – vor Allem, weil die Debug-Ausgaben unter systemd im Journal landen statt im Nirvana.)

        Start:
        Code:
        systemctl start knxd.socket
        systemctl start knxd.service
        Stop:
        Code:
        systemctl stop knxd.socket
        systemctl stop knxd.service
        Auto-Start beim Systemstart:
        Code:
        systemctl enable knxd.service
        DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

        Kommentar


          #5
          Quellen, Versionen, compilieren, installieren
          Siehe https://github.com/knxd/knxd

          Dort findet der geneigte Leser eine README-Datei mit ausführlicher Anleitung für Debian/Jessie.

          Die aktuelle Entwicklung findet im "master"-Zweig statt. Außerdem gibt es die Zweige "stable" (v0.12) und "oldstable" (v0.10).
          Für den produktiven Einsatz verwendet bitte den "stable"-Zweig:

          Code:
              git clone https://github.com/knxd/knxd.git
              cd knxd
              git checkout stable ## oder v0.12
          Die alte, auf pthsem basierende Version ist "v0.10" oder "oldstable".
          Aktuelle Entwicklung findet im "master"-Zweig (oder einem Feature-Zweig) statt; der ist für den allgemeinen Konsum eher ungeeignet.

          Zum Wechseln auf einen anderen Zweig tut man dies:
          Code:
          git fetch
          git checkout stable ## oder welcher auch immer
          git pull
          In Folge will man auf die aktuelle Version in diesem Zweig updaten, das geht mit
          Code:
          git pull
          "Fremde" Installationsskripte
          Meine ehrliche Meinung: die im Netz verfügbaren "wie installiere ich den eibd/knxd"-Skripte sind zum Großteil veraltet. Das erkennt man daran, dass das Skript
          • "pthsem" herunterlädt und installiert
          • nicht den "stable"-Zweig verwendet
          • systemd nicht erwähnt,/etc/rc.local modifiziert, …
          • "make install" aufruft oder Dinge direkt nach /usr/local o.Ä. kopiert, statt den Paketmanager des Systems zu verwenden

          Ich behaupte nicht, dass das, was ich hier und in den knxd-Sourcen schreibe, die eierlegende Wollmilchsau ist, aber:
          wenn in den Quellen etwas steht, das nicht funktioniert oder unklar ist, dann kippt das bitte bei mir ein (ich höre zu…). Verweist bitte auf die "offizielle" Anleitung, statt etwas zu stricken, das nach ein paar Monaten nicht mehr funktioniert. Bringt den Menschen vor dem Bildschirm soweit, dass er/sie versteht was er/sie da tut, statt irgendwas am System zu ändern, das dieses bei einem Abbruch in einem halbdefinierten Zustand hinterlässt – den man, wenn man zum Fehlersuchen kommt, erstmal wieder aufräumen muss.

          Danke.
          Zuletzt geändert von Smurf; 04.02.2017, 12:41.
          DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

          Kommentar


            #6
            In eigener Sache

            Die Arbeit an knxd und überhaupt mit dem KNX-Protokoll ist nichts, das man mal eben aus dem Ärmel schüttelt – das braucht Zeit, und dedizierte Hardware zum Testen. Einen frei verfügbaren Ersatz für die ETS5 gibt es auch nicht. (Das würde ich gerne ändern … leider sind die Dateien verschlüsselt …)

            Als aktueller Haupt-Autor des knxd würde ich mich freuen, vom einen oder anderen User ein bisschen unterstützt zu werden, sei es finanziell oder mit Hardware"spenden".
            Ich kann eine Rechnung stellen (mit Umsatzsteuer), wenn gewünscht.

            Wer Hardware spenden will: bitte nachfragen!
            Zuletzt geändert von Smurf; 19.09.2018, 16:32.
            DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

            Kommentar


              #7
              Zitat von Smurf Beitrag anzeigen
              Einen frei verfügbaren Ersatz für die ETS5 gibt es auch nicht. (Das würde ich gerne ändern … leider sind die Dateien verschlüsselt …)
              Bist Du Dir da sicher?

              Zumindest die .knxproj Dateien der ETS4 sind unverschlüsselte ZIP-Dateien.

              Allerdings sind diese signiert, so dass ETS sich weigert, modifizierte Dateien zu laden.

              Kommentar


                #8
                Ich meinte die Produktdateien (.knxprod und Konsorten).
                Inzwischen habe ich aber die Passwörter.
                DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

                Kommentar


                  #9
                  Das alte gute Botanische? Sollte sicher hier im Forum irgendwo sicher zu finden sein...
                  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


                    #10
                    Das, und lateinische Miezekatzen.
                    DistKV, Home Assistant, 1wire, KNX, Python, Asterisk, SMD-Lötkolben

                    Kommentar


                      #11
                      Danke für diese wunderbare Zusammenstellung von Infos. Ich beschäftige mich erstmals mit knxd und bin für derlei geballtes Wissen sehr dankbar!

                      Kommentar

                      Lädt...
                      X