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

Loxone 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.

Loxone im Einsatz? Dann schau dir unseren LoxKurs an und profitiere von unserem Wissen!

Verpasse keine Inhalte mehr! Trage dich in den Newsletter ein und folge uns auf Facebook.

Was ist ein Affiliate-Link? Wenn du auf einen Affiliate-Link klickst und √ľber diesen Link einkaufst, bekomme ich vom betreffenden Online-Shop oder Anbieter eine Provision, was mich u.A. bei den laufenden Kosten den Blogs unterst√ľtzt. F√ľr dich ver√§ndert sich der Preis nicht.

Jörg

hat meintechblog.de ins Leben gerufen, um seine Technikbegeisterung und Erkenntnisse zu teilen. Er veröffentlicht regelmäßig Howtos in den Bereichen Smart Home und Home Entertainment. Mehr Infos

54 Gedanken zu „TUL-Stick als KNX-IP-Gateway auf dem Raspberry Pi einrichten mit knxd“

  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. :D

    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://www.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. 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.

  17. 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?

  18. 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

  19. 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

  20. 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.

  21. 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

  22. 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.

    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

  23. 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?

Schreibe einen Kommentar

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