TUL-Stick als KNX-IP-Gateway auf dem Raspberry Pi einrichten mit knxd

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

KNX ist für mich nach wie vor DER Standard in Sachen Hausautomatisierung – insbesondere wenn es um eine kabelgebundene, professionelle Installation mit maximaler (Anbieter-)Flexibilität geht. Um die über das “grüne Kabel” angeschlossenen Geräte einrichten und danach über das Heimnetz ansteuern zu können, benötigt man sinnvollerweise ein KNX-IP-Gateway, welches als Vermittler zwischen den Welten auftritt.

Die günstigste und meiner Meinung nach gleichzeitig flexibelste Option ist dabei die Nutzung eines TUL-Stick, welcher per USB bspw. an den Raspberry Pi angestöpselt und mit der Freeware knxd dazu bewegt wird, genau diese Aufgabe zu übernehmen. Wie diese Konfiguration im Detail aussieht, damit der TUL auch in ETS als vollwertiges KNX-IP-Gateway genutzt werden kann, ist Inhalt des nachfolgenden Blogpost.

knxd als Weiterentwicklung von eibd

Vor mehr als vier Jahren hatte ich dieses Prozedere und die Grundlagen bereits im Artikel KNX/EIB-Gateway in FHEM einbinden ausführlich beschrieben. Damals kam zu diesem Zweck noch die Software eibd zum Einsatz, welche in der Zwischenzeit weiterentwickelt wurde und jetzt unter dem Namen knxd (GitHub-Link) zur Verfügung steht. Treibende Kraft hinter dem Ganzen ist dabei Matthias Ulrichs aka smurfix, der sich in obigem Blogpost bereits mehrfach per Kommentar zu Wort gemeldet und bei Fragen Hilfestellung geleistet hat. Vielen Dank dafür Matthias!

2015, also knapp ein Jahr nach Veröffentlichung des Blogposts hat mich Matthias dann bereits auf seine Weiterentwicklung aufmerksam gemacht, welche ich mir eigentlich zeitnah ansehen wollte. Aber wie es oft so ist, gehen andere Dinge vor und plötzlich vergehen ein paar Jahre.

TUL-Stick als KNX-Gateway – Warum?

Wer meinen Smart-Home-Werdegang etwas mitverfolgt hat, wird vielleicht nachvollziehen können, weshalb ich viele KNX-Komponenten im Neubau installiert habe, sich aber vielleicht dennoch fragen, warum ich neben dem Loxone Miniserver, welcher bereits eine KNX-Schnittstelle eingebaut hat und dem zusätzlich verbauten WEINZIERL 730 KNX IP Interface (Affiliate-Link) noch ein weiteres Gateway benötige.

Für mich gibt es gleich mehrere Gründe:

  • Mit nur wenigen Klicks lassen sich die zentralen Einstellungen des Gateways (z.B. KNX-Gruppenadresse) ändern und so bspw. unterschiedliche KNX-Adressbereiche über ETS ansprechen. -> Perfekt für Tests
  • Der TUL-Stick wird in meinem Fall direkt an einen RPI angestöpselt, welcher sowieso bereits im Schaltschrank werkelt. Hier könnte ich sogar gleich mehrere TUL-Sticks betreiben, ohne auch nur eine zusätzliche Teilungseinheit im Schrank zu verlieren. (Ja, in meinem Schaltschrank ist nicht mehr allzu viel Platz – auch wenn es schon das größte Modell von Hager ist.)
  • Das teure Weinzierl KNX-IP-Interface wird im Grunde obsolet, da es bisher sowieso nur zum Programmieren der Geräte per ETS genutzt wurde. -> Diesen Zweck erfüllt knxd in Kombination mit dem TUL-Stick mit Links (Es werden durch den Rauswurf des Weinzierl-Adapters sogar wieder zwei TE im Schaltschrank frei.)
  • Da der RPI das gesamte KNX-Netz monitoren und per NodeRED künftig Teil einer KNX-Fallback-Lösung werden soll (also falls der Loxone Miniserver ausfallen sollte), bildet die direkte Verbindung zwischen RPI und TUL-Stick quasi einen Single-Point-Of-Failure. Die mir vorschwebende Lösung sollte selbst dann noch funktionieren, wenn bspw. neben dem Miniserver auch noch ein zentraler Netzwerkswitch zusammenbricht. Würde ich dafür stattdessen ein KNX-IP-Interface nutzen, würde in diesem Fehlerfall nichts mehr gehen.
  • Der TUL-Stick ist um Welten günstiger als jedes andere KNX-Gateway. Selbst wenn man einen neuen Raspberry Pi (Affiliate-Link) erwirbt, bleibt man weit unter den Kosten eines regulären KNX-IP-Interfaces. Außerdem lag der TUL-Stick nach meinen damaligen Tests bisweilen eh nur ungenutzt in der Schublade.

TUL-Stick flashen

Voraussetzung ist ein TUL-Stick von Basware (offizieller Name ist “TPUART USB Modul” bzw. “TUL-OEM”), welcher erstmal mit der passenden Software geflasht werden muss. Wie das geht, habe ich schon im Blogpost KNX/EIB-Gateway in FHEM einbinden beschrieben. Der Vollständigkeit halber hier nochmal die notwendigen Schritte:

Den TUL-Stick erstmal per USB an den RPI mit laufendem Raspbian-Betriebssystem (Raspbian Stretch Lite) anschließen und direkt beim Einstecken den kleinen weißen Programmierknopf an der Unterseite des TUL gedrückt halten.

Alle nachfolgenden Schritte erfolgen dann direkt über die Konsole am einloggten RPI:

Erstmal wird das benötigte Paket dfu-programer installiert, welches für die gleich anstehende Programmierung notwendig ist:

sudo apt-get -y install dfu-programmer

Jetzt wird die Firmware heruntergeladen (lustigerweise die selbe wie vor vier Jahren), der TUL-Stick programmiert und das System neugestartet. Damit das schneller geht, sind nachfolgend alle Befehle mit && verknüpft, die dann nacheinander ausgeführt werden:

wget -O TPUARTtransparent.hex http://busware.de/tiki-download_file.php?fileId=54 && sudo dfu-programmer atmega32u4 erase && sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex && sudo dfu-programmer atmega32u4 reset && sudo reboot

Hat alles geklappt, signalisiert eine ab sofort beim Einstecken kurz grün blinkende LED am TUL-Stick dessen Betriebsbereitschaft. Hängt das KNX-Netz zusätzlich bereits an den entsprechenden beiden Klemmen des TUL, leuchtet weiterhin eine rote LED am TUL-Stick.

Alle Infos gibt es auch nochmal auf der busware-Seite selbst, auf welcher der Stick inkonsistenterweise als “TUL – TPUART USB light” bezeichnet wird. Geht es nur mir so oder führen solche vom Hersteller inkonsequent genutzten Bezeichnungen auch bei euch oftmals für Verwirrung?

TUL-Stick mit dauerhaft gültigem Namen einbinden

Ist der TUL-Stick per USB eingesteckt, wird er vom System gewöhnlich automatisch unter /dev/ttyACM0 eingebunden. Wenn noch weitere USB-Sticks angeschlossen werden, kann es jedoch spätestens beim nächsten Neustart zu Problemen kommen, da sich die Bootreihenfolge und damit auch die Durchzählziffer am Ende des Mountpoints ändern kann. Deshalb sollte in jedem Fall ein dauerhaft gültiger Name bzw. Link erzeugt werden, damit der Stick – egal was sonst noch angeschlossen wird – immer unter der selben “Kennung” erreichbar ist. Dazu werden drei Dinge benötigt: Seriennummer, Hersteller-ID und Produkt-ID.

Mit dem Befehl

ls -la /dev/serial/by-id/

sollte sich der angeschlossene TUL-Stick zu erkennen geben. In meinem Fall erfolgt die Rückmeldung vom System:

lrwxrwxrwx 1 root root 13 Jul 16 06:41 usb-busware.de_TPUART_transparent_85330323834351C030C0-if00 -> ../../ttyACM0

Entsprechend ist der Stick derzeitig per /dev/ttyACM0 ansprechbar.

In obiger Rückmeldung ist praktischerweise auch bereits die Seriennummer enthalten, welche wir gleich noch brauchen werden: 85330323834351C030C0

Alternativ lässt sich die Seriennummer auch über den Befehl

udevadm info -a -n /dev/ttyACM0 | grep '{serial}' | head -n1

ausgeben:

ATTRS{serial}==”85330323834351C030C0″

Nun brauchen wir noch die Hersteller- und Produktkennung. Diese lauten beim TUL-Stick gewöhnlich: 03eb und 204b

Um auf Nummer Sicher zu gehen, lassen sich diese Daten auch direkt vom Stick auslesen:

udevadm info -a -n /dev/ttyACM0 | grep '{idVendor}' | head -n1

sollte die Hersteller-ID ausspucken:

ATTRS{idVendor}==”03eb”

Und der Befehl

udevadm info -a -n /dev/ttyACM0 | grep '{idProduct}' | head -n1

sollte die Produkt-ID anzeigen:

ATTRS{idProduct}==”204b”

Alternativ lassen sich diese Werte auch über den Befehl

lsusb

kontrollieren:

Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project

Jetzt fehlt nur noch die Erweiterung der gewöhnlich noch unbeschriebenen Datei  /etc/udev/rules.d/99-usb-serial.rules

sudo nano /etc/udev/rules.d/99-usb-serial.rules

mit dem Eintrag:

SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="85330323834351C030C0", SYMLINK+="knx", OWNER="knxd"

Wichtig ist dabei die Angabe des “SYMLINK”, also des Einhängepunkts, welcher hier “knx” lautet. Das Device wird später also unter /dev/knx erreichar sein. Dann noch die Angabe des “OWNER” als “knxd”, sodass der später genutzte knxd-Dienst auch den notwendigen Zugriff auf den TUL-Stick erhält.

Die Datei jetzt mit STRG + o speichern und den nano-Editor mit STRG + x schließen.

Zum Abschluss am besten noch ein Restart des Systems mit:

sudo reboot

Sobald das System wieder verfügbar ist, lässt sich die neu generierte Verklinkung prüfen mit:

ls -la /dev/knx

Das sollte dann so aussehen:

lrwxrwxrwx 1 root root 7 Jul 15 16:31 /dev/knx -> ttyACM0

knxd installieren und einrichten

Da knxd einige Abhängigkeiten zu anderen Paketen besitzt, müssen diese erstmal nachinstalliert werden:

sudo apt-get update && sudo apt-get -y install git-core build-essential debhelper libusb-1.0-0-dev dh-systemd libev-dev libfmt3-dev autotools-dev autoconf automake libtool libusb-1.0-0-dev base-files base-files cmake

Mit sehr großer Wahrscheinlichkeit spuckt obiger Befehl mindestens eine Fehlermeldung aus und/oder bricht ab, ohne alle Pakete komplett zu installieren. Das liegt einfach daran, dass je nach verwendetem Linux-Betriebssystem bzw. Betriebssystem-Version andere Pakete verfügbar bzw. aktuell sind. In diesem Fall einfach beim nächsten Schritt weitermachen. Denn dort wird dann auch angezeigt, welche Pakete noch fehlen, sodass diese dann Schritt für Schritt nachinstalliert werden können.

Erstmal wird knxd von GitHub gezogen und für die Installation vorbereitet:

git clone https://github.com/knxd/knxd.git
cd knxd
git checkout master
dpkg-buildpackage -b -uc

Sofern noch notwendige Pakete fehlen (was sehr wahrscheinlich ist), erfolgt jetzt direkt eine Meldung, welche dies sind. Die angezeigten Paketnamen werden jetzt – am besten schrittweise – nachinstalliert mit:

sudo apt-get -y install ANGEZEIGTER_PAKETNAME

Jetzt kann man einfach nochmal den Befehl “dpkg-buildpackage -b -uc” absetzen und hoffen, dass alle notwendigen Pakete vorhanden sind. Falls nicht, müssen die noch fehlenden Pakete eben auch noch nachinstalliert werden. Ich musste das Vorgehen selbst einige Male wiederholen, bis die dann mehrere Minuten dauernde Paketerstellung auch tatsächlich ausgeführt werden konnte.

Hat das funktioniert, fehlt noch die Installation der fertig kompilierten Software:

cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb

Jetzt muss “nur” noch die Konfigurationsdatei unter /etc/knxd.conf mit den korrekten Daten gefüttert werden, damit der TUL-Stick als Gateway agieren kann:

sudo nano /etc/knxd.conf

Die bereits eingetragene Zeile KNXD_OPTS=“-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip: wird erstmal mit einer führenden # auskommentiert.

Danach wird die Datei ergänzt um den Eintrag:

KNXD_OPTS="-e 1.0.1 -E 1.0.200:10 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"

Wer eine abweichende physikalische Adresse (hier: 1.0.1) oder andere reservierte Client-Adressen (hier: 1.0.200 – 1.0.209) benötigt, passt den Code entsprechend an. Was die ganzen Optionen bedeuten, lässt sich mit dem Befehl

knxd --help

herausfinden. Ist man mit dem Ausdruck zufrieden, kann die Datei mit STRG + o gespeichert und der nano-Editor mit STRG + x geschlossen werden.

Insgesamt war es trotz recht ausführlicher Dokumentation der knxd-Projektseite für mich nicht so einfach überhaupt eine funktionierende Konfiguration mit dem TUL-Stick zum Laufen zu bekommen. Für Experten sicherlich das einfachste der Welt, für mich war es schon etwas fummelig. Vermutlich wird mir auch gleich jemand an den Hals springen (vielleicht sogar Matthias selbst), dass ich die Optionen in obigem Ausduck nicht korrekt benutze. Ich bin gespannt und warte schon mal auf Feedback. 😉

Eigentlich sollte der knxd-Dienst beim nächsten Neustart automatisch gestartet werden, aber es kann an dieser Stelle auch nicht schaden die systemd-Einträge nochmal manuell zu aktivieren:

sudo systemctl enable knxd.service && sudo systemctl enable knxd.socket

Zum Schluss noch ein Neustart mit

sudo reboot

und sobald das System wieder verfügbar ist, kann der ordnungsgemäße Betrieb mit

systemctl status knxd.socket

und

systemctl status knxd.service

geprüft werden. Hat alles geklappt, wird bei jedem Befehl ein “grüner Dot” angezeigt, gefolgt von weiteren Informationen mit dem Inhalt “Active: active (running)

Auch sollte der Adapter jetzt als KNX-Schnittstelle in ETS zur Verfügung stehen, um KNX-Komponenten zu programmieren bzw. den Bus zu monitoren. Lustigerweise kann damit neben dem “Gruppenmonitor” auch der “Busmonitor” genutzt werden, mit dem oben angesprochenen WEINZIERL 730 KNX IP Interface (Affiliate-Link) funktioniert das übrigens nicht. (“Die Schnittstelle unterstützt nicht den Busmonitor-Modus.”) Wobei mir als Laie ohnehin nicht ersichtlich ist, was der grundlegende Unterschied zwischen Gruppen- und Busmonitor ist bzw. warum man beide benötigt.

Wenn der knxd-Adapter in ETS ausgewählt und der Gruppen- bzw Busmonitor gestartet wird, lässt sich jetzt noch das Senden eines KNX-Telegramms testen, indem bspw. die Gruppenadresse 1/0/0 über folgenden Terminalbefehl auf 1 (Ein) gesetzt wird:

knxtool groupswrite ip:localhost 1/0/0 1

Direkt nach dem Absenden der KNX-Mitteilung sollte diese im ETS-Busmonitor auftauchen.

Aus meinem täglichen Leben

Wer sich vielleicht abschließend fragt, warum man bei der ganzen Konkurrenz heutzutage noch auf den streckenweise schon sehr altbacken wirkende KNX-Standard setzen sollte, kann ich nur sagen: ES FUNKTIONIERT – ZUVERLÄSSIGST! Alle KNX-Komponenten in meinem Neubau – und das sind nicht wenige – arbeiten bereits über ein Jahr im Dauerbetrieb und das ohne jeglichen Ausfall. Und ich spiele wirklich viel an der Installation herum. Dabei hätte ich nicht im Ansatz damit gerechnet, dass der Loxone Miniserver als zentrale Steuereinheit des gesamten Systems die zig hundert eingepflegten KNX-Gruppenadressen so easy handelt, sodass man im täglichen Gebrauch keinerlei spürbare Verzögerung wahrnimmt. Gefühlt befindet man sich hier im zweistelligen ms-Bereich, was absolut verschmerzbar ist.

Das Parametrieren über die ETS ist für mich vermutlich das Nervigste an KNX, was mich echt langweilt. Bis man sich durch die teilweise ellenlangen Settings gewühlt hat, um die passenden Einstellungen zu finden, vergeht meist einige Zeit. Und das anschließende Neuprogrammieren eines einzigen Gerätes dauert neben dem normalen “Busbetrieb” oft mehr als eine Minute. Gähn. Dafür kann man so ziemlich alles genau so einstellen, wie man möchte – maximale Flexibilität eben. Aus diesen Gründen habe ich vermutlich mittlerweile auch eine Art Hassliebe zu KNX entwickelt – Es nervt irgendwie, aber ohne könnte ich es mir auch nicht mehr wirklich vorstellen. Alleine die brachiale Anbietervielfalt mit einer Vielzahl unterschiedlicher Gerätetypen ist für mich einfach überzeugend. Wo sonst findet man bspw. kabelgebundene Bewegungsmelder mit vier getrennten Präsenzzonen, die noch dazu Helligkeit und Temperatur erfassen? Mehr Infos im Blogpost Operation Smart Home – Präsenzzonen für eine vollautomatische Beleuchtung sinnvoll nutzen.

Nachdem mein TUL-Stick also knapp vier Jahre ungenutzt in der Schublade lag, wird er nun seinen festen Platz am Raspberry Pi im Schaltschrank finden. Neben der Programmierung von KNX-Komponenten über die ETS-Software wird er künftig alle für mich relevanten KNX-Telegramme monitoren und über Node-RED in der Lage sein, selbst Nachrichten in den KNX-Bus zu schicken.

Damit möchte ich Fallback-Schaltbefehle beim Ausfall oder beim Neustart des Loxone Miniservers (dauert bei meiner überladenen Konfiguration mit 5k+ Elementen schon knapp drei Minuten) realisieren. Dann kann man über die KNX-Glastaster weiterhin noch fallback-mäßig alle Rollos/Jalousien und einen Teil der Beleuchtung steuern, da in jedem Raum mindestens eine Lampe per KNX-Dimmer angesteuert werden kann. Wer sich dafür interessiert, kann ja gerne einen Kommentar hinterlassen. Vielleicht stricke ich dann einen separaten Beitrag daraus, sobald die Umsetzung abgeschlossen ist.

56 Kommentare
  1. hi jörg,
    ich habe den artikel gerade erst überflogen und werde ihn mir später genauer zu gemüte führen.
    kurze frage am rande: funktioniert das ganze mit dem knxd plugin des loxberry?
    lg

    1. Hi Herbert,
      ich verstehe es so, dass das LoxBerry-Plugin (https://www.loxwiki.eu/plugins/servlet/mobile?contentId=13303891#content/view/13303891) die hier beschriebene Installation von knxd direkt übernimmt und gleichzeitig noch die Möglichkeit bietet die gewünschten Parameter über das LoxBerry-Interfacd zu pflegen. Das macht es aus Anwendersicht natürlich noch einfacher. Ob man damit aber irgendwelche Einschränkungen hat, weiss ich jedoch nicht.

      Grüße
      Jörg

  2. Hallo Jörg,
    was KNX betrifft. kann ich Dir nur zustimmen. Bei mir läuft das Ganze schon über 20 Jahre. Habe mich vor ca. 3 Jahre in FHEM eingearbeitet und auch den TUL eingebunden. Die Programmierung mit der ETS ist seitdem für mich wesentlich einfacher geworden, hatte vorher noch eine RS 232 Schnittelle zur Programmierung. Das wurde immer mehr zu einem Problem, da es kaum noch Geräte gibt mit dieser Schnittstelle und die ganzen Adapter USB auf RS 232 haben nie richtig funktioniert.
    Lese immer gerne deine Beiträge!!!

    Gruß Erich

    1. Hi Erich,
      über 20 Jahre ist nen Wort. 🙂 Gibts wohl nicht viele Leute, die damals schon im Privatbereich in weiser Voraussicht auf KNX gesetzt haben. In jedem Fall eine sehr gute Entscheidung – und ich hoffe, dass deine Installation noch mindestens weitere 20 Jahre schafft.

      Würde mich sehr freuen, wenn du hier weiterhin am Ball bleibst!

      Grüße
      Jörg

  3. Hi Jörg,
    über den letzten Absatz bin ich gedanklich gestolpert, heisst das, dass du in knx keine Logik hast und alles in Loxone programmiert ist? Ich habe erst alles in knx programmiert, Loxone nutze ich nur für erweiterte Logik, Visu und für 1-wire.
    Der knx-Stick ist interessant, ich werde mal schauen, ob man Loxone nicht auch durch einen Raspi ersetzen kann, quasi als Fallback 😉
    Grüße Chris

    1. Hi Chris,
      absolut richtig. Die KNX-Komponenten sind untereinander nicht verknüpft (bis auf gaaaanz wenige Aufnahmen). Um die gesamte Logik kümmert sich stattdessen Loxone, da ich das gefühlt um Welten einfacher, flexibler und vorallem bei komplexeren Logiken übersichtlicher finde. An die grafische Programmierung der Loxone Config kommt meiner Meinung nach einfach nichts ran. Deshalb verwalte ich hier auch alle Regeln. Dazu wird es in absehbarer Zeit übrigens auch einen Videokurs geben, zu dem man sich hier vormerken kann:

      Grüße
      Jörg

    2. Hi,

      ich denke das ist eine Philosophiefrage.
      Ich z.B. kombiniere alle Geräte einer Systemumgebung so, dass die Minimalfunktionen immer funktionieren.
      So bleibt die Heizung zu Hause (Homematic) und die Beleuchtung im Büro (KNX, seit über 13 Jahren) funktionsfähig auch wenn die erweiterten rechnergesteuerten Funktionen nicht mehr funktionieren.

      Und so schwer ist eine KNX Programmierung auch nicht. Man muss sich nur mit den Gruppenadressen anfreunden.

      Grüße

      Stefan

  4. Hallo Jörg,
    super Beiträge !!! Fange gerade an, micht mit KNX + Loxone für mein zukünftiges Haus in Nürnberg zu beschäftigen. Beleuchtung soll über 24V DMX gehen. Versuche es so wie Du aufzuziehen. Loxone soll das Hirn sein und KNX führt aus.
    Gerade wollte ich mich für Deinen Video-Kurs anmelden aber ein Fehler poppte auf (An error has happened while performing a request, please try again later.).

    1. Hi Bernd,
      bitte nochmal versuchen, der Server hat gerade ein paar Updates gemacht…

      Grüße
      Jörg

      PS: Wann gehts bei dir los? Wünsche dir schon mal viel Erfolg bei der Umsetzung! Ist ein weiter Weg, bis alles genau so läuft, wie man es sich vorstellt. Weiss ich aus eigener Erfahrung. 😀

    2. Hallo nochmal,
      jetzt hat die Anmeldung geklappt. War wohl schlechtes Timing von mir 🙂

      Nachdem ich mich jetzt seit Januar mit dem Bauamt herumschlage, ob und wie ich jetzt dann doch 2 Volletagen bauen darf, hoffe ich inständig, zumindest dieses Jahr noch das Loch buddeln zu dürfen.

      Aber: Die Hoffnung stirbt zuletzt.

      Zumindest nutze ich die Wartezeit zum Lernen und Forschen. Hat auch was für sich. Deine Berichte sind auf jeden Fall Super-Interessant!

      Grüße,
      Bernd

    3. Sehe dich auf der Anmeldeliste, perfekt!
      Wollte auch eigentlich 2 Volletagen, was aber auch nicht zulässig war. Im Endeffekt ist es jetzt ein Staffelgeschoss geworden, also Fläche des OG ist weniger als 3/4 des EG und zählt damit auch mit hohen Wänden (Kniestock ist bei uns auf der niedrigen Pultdachseite knapp 2 Meter) nicht als Vollgeschoss. Vielleicht ist das ja auch noch eine Alternative, sofern das Bauamt bei dir nicht mitspielen will.

      Grüße und viel Erfolg
      Jörg

  5. Hallo Jörg,
    veilen Dank für deinen super Blog. Ich habe in meinem Haus seit 12 Jahren den KNX am laufen und bisher nur zwei Aktorausfälle, wo ein Kanal nicht mehr sauber wahr. ( Das liegt wahrscheinlich daran, dass ich alles nur gebraucht gekauft habe) Ich benutze Fhem nun seit 2 Jahren und bin immer dankbar über jede sinvolle Umsetzung die ich überehmen kann. Den TUL stick werde ich bestellen , sobald ich das Projekt mit dem JEELINK und den Temperatursensoren im Haus eingebunden habe.
    Prima , dass du dein Know How hier einfach für alle zur Verfügung stellst.
    Vielen Dank

  6. Hat jemand Langzeit Erfahrungen für die Parametrierung über die ETS mit dem TUL Stick? Auf der github Seite von knxd steht nur: “ETS programming has not yet been tested”.

  7. Erfolgt die Einbindung in FHEM weiterhin über: “define EIB TUL tul:/dev/ttyACM0@57600 1.1.255” ?

    Ich kriege danach die folgende Fehlermeldung: “CUL: Can’t open /dev/ttyAMA0: Permission denied”

    Im Terminal getestet:
    Befehl: ls -la /dev/knx
    Ausgabe: lrwxrwxrwx 1 root root 7 Oct 27 19:18 /dev/knx -> ttyACM0

    Befehl: ls -lha dev/ttyAMA0
    Ausgabe: ls: cannot access ‘dev/ttyAMA0’: No such file or directory

    Kann man daran mein Problem erkennen?

    Woran erkennt man, ob die Adresse 1.1.255 noch nicht vergeben ist?

    Grüße
    Kaste

    1. Hallo Kaste,
      eine serielle Schnittstelle kann nur von einem Gerät geöffnet werden. Deshalb benutzt man auch den knxd, der mehrere Kanäle ermöglicht und exklusiv auf die serielle Schnittstelle und den TPUART zugreift. Eine mögliche Konfiguration in FHEM ist: define KNX TUL eibd:127.0.0.1 1.2.204 . Dabei arbeitet FHEM auf der physikalischen Adresse 1.2.204 und der TUL steckt am gleichen Server wie FHEM. Man muss natürlich eine physikalische Adresse aus dem Bereich nehmen, den man vorher in der knxd.conf konfiguriert hat (Parameter -E). Durch den knxd kann man die ETS parallel zu FHEM betreiben. knxd vergibt der ETS automatisch eine andere physikalische Adresse aus dem angegebenen Bereich.

  8. Hallo Jörg,
    ich habeHW: PI2, TUL-Stick
    Betriebssystem: Jessi; knxd installiert

    Befehl: ls -la /dev/knx zeigt:
    Ausgabe: lrwxrwxrwx 1 root root 7 Oct 27 19:18 /dev/knx -> ttyACM0

    Oben habe ich nicht gefunden, wie man den TUL-Stick jetzt bei FHEM einbindet; deswegen habe ich auf die alte Beschreibung von Dir zurückgegriffen und in der fhem.cfg eingegeben: define EIB TUL tul:/dev/ttyACM0@57600 1.1.255

    Das Logfile zegt mir aber:
    CUL: Can’t open /dev/ttyAMA0: Permission denied

    bzw.
    DeviceOverview EIB Initialized
    Internals
    AckLineDef
    Clients :KNX:EIB:
    DEF tul:/dev/ttyACM0@57600 1.1.255
    DevType TPUART
    DeviceAddress 011ff
    DeviceName tul:/dev/ttyACM0@57600
    FD 8
    NAME EIB
    NR 14
    PARTIAL
    REFUSED
    STATE Initialized
    TYPE TUL

    Kann man daran erkennen, wo bei mir der Fehler liegt bzw. was ich machen soll?

    1. Hallo Kaste,
      konntest Du Dein Problem inzwischen lösen?
      Ich habe das selbe Problem beim Umstieg von einem KNX/IP Gateway auf den TUL-Stick. M.E. fehlt der Aufruf von knxd in der fhem.cfg

      TUL:
      define EIB TUL tul:/dev/ttyACM0@57600 1.1.255

      KNX/IP Gateway:
      define KNX TUL knxd:localhost 1.1.255

      Grüsse Mario

  9. Hallo zusammen,
    an erster Stelle vielen Dank für den Blog.
    Ich habe ein Raspberry Pi 3 B+ mit dem TUL-Stick von busware.de.
    Alles nach obiger Anleitung installiert.
    Dazu noch das BT-Modul ausgeschalten:
    /boot/config.txt
    dtoverlay=pi3-miniuart-bt
    und die seriellen Schnittstellen nur auf tty1 gesetzt:
    /boot/cmdline.txt
    console=tty1

    !Der TUL-Stick ist NICHT am Bus angeschlossen!

    Mein Problem, dass der knxd.service immer wieder gestartet und abgestürzt ist mit diesen Einträgen in /etc/knxd.conf :
    START_KNXD=YES
    KNXD_OPTS=”-e 1.0.1 -E 1.0.2:8 -t 0xffc -f 9 -DTRS -c -b tpuarts:/dev/ttyKNX1

    Ändere ich diese in:
    KNXD_OPTS=”-t1023 -e 1.0.1 -E 1.0.2:8 -c -DTRS -u /tmp/eib ipt:127.0.0.1″
    erscheint das Interface in ETS5.

    Kann das sein, dass der obere Eintrag nur mit angeschlossener Busleitung (rote LED aktiv) funktioniert?

    1. Hallo djskydriver,
      ich habe Deine Anfrage leider jetzt erst gelesen. Du hast sie aber bereits selbst beantwortet. Der TPUART auf dem TUL ist galvanisch vom Rest getrennt (das weiße Teil ist der Optokoppler). Dadurch kann der TPUART nur initialisiert werden, wenn Busspannung angeschlossen ist. Ohne die Rückmeldungen während der Initialisierung startet der knxd nicht.

  10. Hallo,
    ich benutze ein Raspberry Pi 3 B+ mit dem TUL-Stick von Busware.de.

    Ich habe alles nach deiner Anleitung installiert.

    Wenn ich den KNXD manuell starte mit:

    sudo systemctl start knxd.socket
    sudo systemctl start knxd.service

    Und danach den Status von beiden Abfrage, dann sieht es bei mir aus wie in deinem Screenshot. Wenn ich dann aber noch einmal den Status vom knxd.service abfrage, dann bekomme ich folgende Info:

    pi@raspberrypi:~ $ systemctl status knxd.service
    ● knxd.service – KNX Daemon
    Loaded: loaded (/lib/systemd/system/knxd.service; enabled; vendor preset: enabled)
    Active: activating (auto-restart) (Result: exit-code) since Sat 2018-11-10 09:54:12 CET; 6s ago
    Process: 974 ExecStart=/usr/bin/knxd $KNXD_OPTS (code=exited, status=1/FAILURE)
    Main PID: 974 (code=exited, status=1/FAILURE)

    Nov 10 09:54:12 raspberrypi systemd[1]: knxd.service: Unit entered failed state.
    Nov 10 09:54:12 raspberrypi systemd[1]: knxd.service: Failed with result ‘exit-code’.

    Was mache ich falsch ?

    1. Hallo Frank,

      Ich habe gestern alles installiert und habe denselben Fehler wie du. Bist du das inzwischen weiter gekommen?

      Viele Grüße
      Markus

    2. Hallo Frank, Hallo Markus,

      ich habe den gleichen Fehler. Habt ihr eine Lösung für das Problem gefunden?

      Viele Grüße,
      Tobias

    3. Ich hatte denselben Fehler. Der TUL Stick muss mit Bus-Spannung versorgt werden, um zu starten. Danach funktionierte der knxd.service direkt mit den Parametern
      KNXD_OPTS=”-e 1.0.1 -E 1.0.200:10 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx”

  11. Hallo Kaste,

    bist Du mit Deinem Problem weiter gekommen?
    Habe den gleichen Fall; will von KNX/IP Gateway auf TUL Stick umsteigen.
    KNXD läuft; aber wie erfolgt bei TUL Def in fhem mit
    define KNX TUL tul:/dev/ttyACM0@57600 1.1.255
    die Verbindung zum KNXD?

    Gruss Mario

    1. Hallo Mario,

      bei mir klappt es. Anbei meine Einstellungen:

      HW: PI3, Busware TUL-Stick
      Betriebssystem: Jessi; knxd 0.14.25 installiert

      sudo nano /etc/knxd.conf
      KNXD_OPTS=”-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx1″

      sudo nano /etc/udev/rules.d/70-knxd.rules

      ACTION==”add”, SUBSYSTEM==”tty”, ATTRS{idVendor}==”03eb”, ATTRS{idProduct}==”204b”, KERNELS==”1-1.3″, SYMLINK+=”knx1″, OWNER=”knxd”

      sudo nano /etc/udev/rules.d/99-usb-serial.rules
      => Kein Einträge hier nötig!

      fhem.cfg
      define KNX TUL knxd:localhost 0.0.2

      Ich hoffe, es klappt damit auch bei Dir!!!
      Gruss Axel

    2. Hallo Kaste,

      ja das war hilfreich.

      Entsprechend:
      https://meintechblog.de/2018/07/tul-stick-als-knx-ip-gateway-auf-dem-raspberry-pi-einrichten-mit-knxd/#more-13612

      habe ich die Einträge allerdings hier vorgenommen (bei Dir keine Einträge bzw. in 70-knxd.rules):

      sudo nano /etc/udev/rules.d/99-usb-serial.rules

      Aus fhem heraus kann ich damit auf den KNX schreiben und auch lesen. Über die ETS (KNX Programmiersoftware) auf dem PC (USB Schnittstelle) muss ich allerdings feststellen, dass Telegramme auf dem Bus jetzt vervierfacht werden d.h., der TUL -Stick vervielfältigt die Telegramme irgendwie. Wenn ich den Stick vom KNX trenne, kommen die Telegramme auf dem KNX normal einfach an. Dem muss ich auf den Grund gehen; soviel Buslast will ich vermeiden.

      Eine Frage noch, die Adressen mit Option -e 0.0.1 und 0.0.2-8 sind die (phys.) Geräteadressen, mit denen der TUL Stick auf den KNX sendet.
      sudo nano /etc/knxd.conf
      KNXD_OPTS=”-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx1″

      Was ist dann die 0.0.2, mit der knxd in der fhem.cfg definiert wird?

      fhem.cfg
      define KNX TUL knxd:localhost 0.0.2

      Gruss
      Mario

    3. Hallo Kaste,

      wegen der Telegrammvervielfältigung durch den TUL Stick auf dem KNX habe ich jetzt mal den knxd komplett deaktiviert und den TUL Stick nur so eingebunden:

      fhem.cfg
      define KNX TUL tul:/dev/ttyACM0@57600 1.1.255

      Lesen und Schreiben von fhem aus auf den KNX funktioniert; Telegramme kommen alle nur einfach. Das passt so für mich. Ich habe gelesen, dass der knxd aber benötigt wird, wenn man mit der ETS über den TUL Stick KNX Geräte programmieren will; ist bei mir nicht der Fall.

      Grüsse und schöne Weihnachten
      Mario

  12. schön, dass es geklappt hat. Ich habe keine Ahnung, warum es bei mir mit localhost 0.0.2 funktioniert. Aber wenn es funzt, lässt man es natürlich mit diesen Einstellungen laufen.
    Dir auch schöne Weihnachten
    Axel

    1. Hallo Kaste,
      -E0.0.2:8 in den knxd-Einstellungen bedeutet, dass Geräte wie ETS und FHEM die Adressen 0.0.2 und die sieben darauf folgenden (also insgesamt acht) physikalischen Adressen für den Buszugriff nutzen können. Es können also acht Geräte den knxd im Tunnelingmodus nutzen.

  13. Hallo Jörg,
    gute Anleitung. Ein wichtiger Hinweis: Der TPUART auf dem TUL, dem ROT und auch dem PIM TPUART wird vom KNX-Bus mit Spannung versorgt. Der Raspi ist vom Bus galvanisch getrennt. Daher muss der Bus angeschlossen sein, damit der knxd den TPUART finden und initialisieren kann. Ansonsten startet der knxd nicht.
    Gruß Frank

  14. ich habe mit regem Interesse den Blog gelesen.
    Nun zur Frage:
    Wie viele Geräte kann man da maximal anschließen?
    Ist es nicht sinnvoll, 2 Raspberries fertig zu machen, um den Innen- und Außenbereich zu trennen (Datensicherheit)?

    1. Der KNX-Standard erlaubt 64 Geräte pro Linie. Das hängt aber vom Stromverbrauch der einzelnen Geräte und vom Netzgerät ab. Als Richtwert gilt 10mA pro Gerät. Mehrere Linien werden über Linienkoppler verbunden. Diese können auch so konfiguriert werden, dass sie nur bestimmte Gruppenadressen routen. Dadurch kann man eine Innen-Linie und eine Außen-Linie so miteinander verbinden, dass ein Angreifer nicht an einem Bewegungsmelder sniffert und nach einiger Zeit mit den so gewonnenen Erkenntnissen mein Haus durcheinander bringt.
      Es lassen sich natürlich auch mehrere Linien jeweils mit einem Raspi und FHEM ausstatten. Die Server lassen sich dann über Telnet miteinander verbinden. Nicht so elegant aber viel preiswerter.

  15. Hallo,

    Kann nur sagen super Artikel. Toll beschrieben. Es hat (fast) auf Anhieb funktioniert.
    (Nur bei einer Stelle hab ich das abschliessende ” vergessen).
    Danke & super

  16. Hallo,

    den GIT Befehl “git checkout master” muss man jetzt ändern auf “git checkout deb”, damit es funktioniert. Sonst war die Installation völlig problemlos. Danke!

    1. Ist dieses Setup mit dem PI noch aktuell oder gibt es mittlerweile neuere/bessere/einfachere/günstige Lösungen um zu einem KNX-IP interface zu kommen?

      Ich suche einerseits was um mein KNX System mit ETS umzuprogrammieren, anderseits eine Lösung um KNX mit Tuya(offline)/Bluetooth zu koppeln.

      LG Robert

  17. Es scheint eine neuere Version der TPUARTtransparent.hex auf der busware seite verfügbar zu sein.
    Der neue link ist: http://files.busware.de/TUL/Transparent/TPUARTtransparent.hex
    anstelle des im script verwendeten links: http://busware.de/tiki-download_file.php?fileId=54
    ich habe beide Dateien geladen und der Diff ist deutlich (was nichts heißen muss). Weis jemand wie man auf der busware seite Versionshinweise findet?

    1. Hallo Marc,
      ich würde mir über die Software-Versionen keine Gedanken machen. Der Mega32U4 auf dem TUL arbeitet als USB2Seriell-Wandler. Da dürfte es also keine wesentlichen Unterschiede geben. Wie der Name sagt, werden die Daten transparent durchgereicht. Bastler können es auch hiermit versuchen: https://www.voltus.de/?cl=details&anid=6d587e3f46216269029d510de0d89711&gclid=Cj0KEQiAsrnCBRCTs7nqwrm6pcYBEiQAcQSznOidojOhpmDjXMMDLTrgq73c7CDLHDBy8FA6e6v6Ou8aAqvO8P8HAQ . Ein paar Hintergründe und die Beschaltung gibt es hier: https://www.konnekting.de/konnekting-lernen/l1-knx-mit-arduino/ . Die BCU, ein USB-Wandler und, nicht vergessen, eine galvanische Trennung und fertig ist die KNX-Anbindung.

  18. Hallo Jörg, vielen Dank für die ausführliche Anleitung. Ich habe mir bereits vor Monaten den TUL-Stick gekauft und wollte Ihn nun flashen. Doch leider ist die Busware-Seite aktuell down. Kannst Du mir vllt die Datei TPUARTtransparent.hex zur Verfügung stellen?

  19. git checkout master
    Funktioniert nicht mehr da die branches im repository umbenannt wurden:
    stattdessen jetzt
    git checkout main
    verwenden.

  20. einen Hinweis noch. Wer dies auf einem Raspberry durchführt sollte statt
    git checkout master bzw. git checkout main für die korregierte version
    git checkout debian verwenden
    und im Anschluss
    # now build+install knxd
    sh knxd/install-debian.sh

  21. Hallo Jörg
    Interessante lösung..
    Gibt es Erfahrungen wie Stabil und Vernünftig das ganze läuft im Vergleich zu einer echten IP Schnittstelle ?
    Ich habe schon mal den Loxone Miniserver als KNX IP Schnittstelle eingesetzt und das lief grottenschlecht.
    bei größeren Programmiervorgängen wurde immer wieder mit fehler abgebrochen. Also das kann mit einer echten KNX IP Schnittstelle nicht mithalten 🙂
    würde mich über einen Input über deine Erfahrungen freuen

    lg Georg

    1. Bei mir läuft das auf drei Servern an drei Standorten mit FHEM seit Jahren einwandfrei. Aktuell habe ich einen Raspi mit knxd und einem Selbstbau-KNX-Netzteil als Zentrale für eine Insel vorbereitet. Der knxd soll hier als Router die Daten des restlichen Netzes aus dem WLAN bekommen. Wenn das läuft kann ich sicher noch genaueres sagen. Ich bin aber sehr zuversichtlich.
      Schau doch mal im knx-user-forum nach. Dort ist auch der Entwickler des knxd aktiv.

      Gruß Frank

    2. Hi Georg,
      der Miniserver ist ja nicht KNX-zertifiziert, entsprechend funktioniert das auch nur so lala als ETS-Gateway. Die KNXD-Lösung lief bei mir immer stabil. Mittlerweile setze ich aber ein “normales” IP-Gateway ein – weil es sonst unbenutzt in der Ecke rumfliegen würde.

      Viele Grüße
      Jörg

  22. Hallo Jörg,

    Vielen Dank für den tollen Beitrag, auch wenn dieser schon etwas älter ist.
    Wie Du in Deinem Beitrag erwähnt hast, gibt es einige tolle Produkte mit KNX Standard, welche es so mit anderen Bus Schnittstellen nicht gibt.
    Für mein Eigenheim interessiere ich mich für Präsenzmelder sowie die MDT Glastaster. Nur möchte ich mein SmartHome nicht mit KNX aufbauen, sondern bei ioBroker bleiben. Nun zu meiner Frage, kann ich mit dem Busware TPUART Stick sowie ein KNX Netzteil, ein minimal KNX Netz aufbauen, welches mit der kostenlosen ETS5 Demo Software konfiguriert wird. Dann die Sensoren & Aktoren von KNX so programmieren, dass ich diese direkt im ioBroker verwenden kann?

    Vielen Dank im Voraus,

    Gruss Thomas

    1. Hi Thomas,
      kurze Antwort: Klar! 🙂
      Für kleinere (Test-)Installationen brauchst du noch nichtmal ein KNX-Netzteil. Nimm einfach ein 24V, welches man mit Drehschalter auf 28-30V hochstellen kann und gut ist.

      Viele Grüße
      Jörg

      Update: Und ja stimmt, man braucht dann noch eine KNX-Drossel für paar Euro… Hatte ich ganz vergessen. Danke Frank für deine Info! Im Endeffekt sind KNX-Netzteile auch nicht mehr so mega teuer. Dann entgeht man potenziellen Problemen – insb. bei größeren Installationen.

  23. Hallo Jörg,
    das mit dem KNX-Netzteil ist nicht ganz so einfach, allerdings auch nicht viel komplizierter. Ich nutze ein 24V/15W Netzteil, entweder das SNT RS 15 24 oder das EPS-15-24, das auch in ein 4TE-Hutschienengehäuse passt. Dahinter benötigt man aber noch eine Drossel. Hier habe ich immer die CAF 0,6-100 verwendet. Es geht aber auch mit der CAF 0,6-56. Eventuell geht es aber auch noch kleiner, ich hatte nur keine Lust, es auszuprobieren.
    Zur Erläuterung: Die KNX-Geräte benötigen Spannungen ab etwa 23V bis 30V. Die genaue Spannung ist also nicht so interessant. Da die Geräte ihre Betriebsspannung aus dem Bus beziehen, gibt es natürlich einen Spannungsabfall auf der Leitung. Die Netzteile haben ein Poti, dass man einfach nur ganz aufdreht und dann passt das. Die Datenbits auf dem Bus werden als Impulse übertragen. Da Netzteile eine möglichst glatte Ausgangsspannung liefern sollen, flachen sie die Datenimpulse ab. Deshalb die Drossel zwischen Netzteil und Bus. Es gibt auch Leute, die experimentieren mit Widerständen. Warum? Die Drossel kostet kaum etwas und funktioniert.
    KNX-Netzteile haben übrigens einen verdrosselten und einen unverdrosselten Ausgang, letzterer für KNX-Geräte, die eine zusätzliche Betriebsspannung benötigen.

    Gruß Frank

  24. Bei 10 mA pro KNX-Gerät hält sich der Spannungsabfall in engen Grenzen.

    Das Problem ist eher: die Busteilnehmer sind inzwischen clever geworden. Manche messen sogar den Spannungsabfall, den ihre Impulse generieren, auf dass er nicht zu groß werde … oder zu klein. Wenn dein 24V-Netzteil gut ist, wird es superschnell darauf reagieren und gegensteuern. Das wiederum quittiert der Busteilnehmer evtl. damit, dass er den Betrieb einstellt. Außerdem kommen seine Impulse nicht beim Empfänger an, weil der dessen vom Netzteil kompensiertes 100mV-Popelsignal nicht von einer Störung unterscheiden kann.

    OK. Du klemmst dir eine Drossel auf die Leitung. Jetzt kommt Problem 2: die Spannungsabsenkung während des Signals bedeutet mehr Strom durch die Drossel, und der muss irgendwo hin. Du bekommst somit eine unkontrollierte Spannungsspitze. Folgerung: nur mit ner Drossel ist es nicht getan.

    Kauf lieber ein KNX-Netzteil. So teuer sind die nicht.

    1. Ok, hatte vergessen, dass ich auch noch jeweils einen 47 Ohm Widerstand über die Drossel lege. Ich finde, dass ca. 150€ plus minus für ein KNX-Netzteil ziemlich heftig ist. Der Spannungsabfall summiert sich. Zum einen gibt es auch Geräte, die dem Bus mehr als 10mA entnehmen. Das entspricht durchaus den Spezifikationen. Die entsprechenden Schaltkreise (z.B. NCN5120) sind entsprechend einstellbar. Des weiteren befindet sich am Ende einer mehreren Meter langen Busleitung ja nicht unbedingt nur ein Gerät, so dass sich die Betriebsströme addieren. Wenn man nun mit 24V arbeitet, dann sinkt die Spannung schnell auf weniger als 23V und die Geräte steigen aus. Solche Fehler sind schwer zu finden und deshalb sehr ärgerlich.
      Mit der ETS5-Demosoftware ist die Anzahl der Geräte je Projekt begrenzt. Wenn man entsprechend viele Projekte anlegt, dann ist das Arbeiten schwierig und umständlich, aber durchaus auch für mehr Geräte machbar. Für ein paar Präsenzmelder und Glastaster aber kein Problem.

  25. Hallo,
    vielen Dank für dein ausführliches Turtorial. Ich Plane meine erste KNX Anlage.

    Der Raspberry soll mir zunächst als IP Schnittstelle dienen um die Anlage später zu programmieren,
    Funktioniert deine Anleitung auch mit diesem Produkt?:
    https://shop.busware.de/product_info.php/cPath/1_34/products_id/83

    Gruß Jonas

    1. Hallo Jonas,
      Der ROT benutzt die eingebaute serielle Schnittstelle des RasPi. Diese ist aber bei den neuen Modellen per Software realisiert, weil der Hardware-UART für Bluetooth verwendet wird. Du musst also zunächst Bluetooth deaktivieren und die Schnittstelle umschreiben. Dann kannst du die Schnittstelle unter ttyAMA0 ansprechen.

      Gruß Frank

  26. Hallo Jörg,
    vielen Dank für den interessanten Artikel.

    Ich nutze z.Zt. Homematic, bin aber von der Haptik der Schalter sehr enttäuscht. Da ich während meiner Weiterbildung auch gleich den “KNX Schein” gemacht habe, bietet es sich ja an dieses System zu verbauen. Glücklicherweise tut sich gerade etwas auf dem KNX-RF Markt, ideal für meine Nachrüstung.

    Ich müsste an dem TUL-Stick einen Medienkoppler anschließen um funken zu können. Kann ich statt dem TUL-Stick mit Medienkoppler auch gleich einen KNX-RF Programmierstick an den PI anschließen?

  27. > sudo apt-get update && sudo apt-get -y install git-core build-essential debhelper libusb-1.0-0-dev dh-systemd libev-dev libfmt3-dev autotools-dev autoconf automake libtool libusb-1.0-0-dev base-files base-files cmake

    Das ist mittlerweile höherer Unfug. Außer “git” ist im ersten Schritt gar nix zu installieren. Siehe README.

Schreibe einen Kommentar zu Matthias U Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen