KNX/EIB-Gateway in FHEM einbinden

IM EINSATZ?

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

Viele Smart Home-Nutzer werden mit ihrer FHEM-Installation vornehmlich per Funk angebundene Sensoren und Aktoren nutzen, die von Herstellern wie HomeMatic (Affiliate-Link) oder FS20 (Affiliate-Link) stammen.

FHEM unterstützt darüber hinaus jedoch eine Vielzahl weiterer Protokolle, um auch kabelgebundene Geräte z.B. über den in professionellen Installationen genutzten KNX-Bus zu integrieren. In diesem ersten KNX-Howto soll dabei einführend erklärt werden, wie sich KNX-Komponenten an FHEM grundsätzlich mit zwei verschiedenen Arten von KNX-Gateways einbinden lassen, um die Steuerung über FHEM und damit bspw. auch über ein Smartphone realisieren zu können.

Als mögliche “Bus-Koppler” – also Gateways zwischen FHEM und KNX – ist einmal der TUL-Stick von Busware zu nennen, welcher den KNX-Bus per USB anbindet und zum anderen ein KNX-Lan-Gateway (egal welcher Anbieter), wie bspw. die ABB IPS/S2.1 EIB/KNX IP-Schnittstelle, REG (Affiliate-Link), welche die KNX-Anbindung über das Netzwerk ermöglicht. Da es den Artikel mehr als sprengen würde, wird an dieser Stelle erstmal vorausgesetzt, dass bereits eine funktionierende KNX-Infrastruktur vorhanden ist. Im nachfolgenden Artikel KNX-Aktor in 10 Schritten mit ETS5 programmieren wird dann detailiert beschrieben, wie eine KNX-Infrastruktur aufgebaut werden kann.
Durch die Nutzung des TUL-Stick ergeben sich einige Vorteile für den Anwender. Zum einen ist er mit unter 100€ günstiger als ein KNX-Lan-Gateway (ca. ab 150€), für dessen Betrieb zusätzlich noch ein Netzteil benötigt wird. Zum anderen ist die Firmware des TUL-Stick so ausgelegt, dass es direkt ohne Umwege über EIBD (Erläuterung weiter unten) in die FHEM-Konfiguration eingebunden werden kann. (Auf der anderen Seite benötigt er jedoch EIBD, um mit der Konfigurationssoftware ETS4 mit nachfolgend beschriebenem Setup kommunizieren zu können.)

Als Nachteil des TUL-Stick hat sich bisher herausgestellt, dass der FHEM-Server eine hohe CPU-Auslastung generiert (Neustart des FHEM-Servers notwendig), wenn bei getrenntem KNX-Bus versucht wird einen entsprechenden Schaltbefehl über den TUL-Stick von FHEM aus zu den KNX-Komponenten abzusetzen. Evtl. lässt sich in diesem Fall die Verbindung auch ohne einen kompletten Neustart des Systems neu initiieren, hier fehlt mir aber das notwendige Hintergrundwissen. In Foren liest man zudem, dass es sich als schwierig gestalten soll, den TUL-Stick dazu zu bewegen mit der kommerziellen ETS4-Software (Downloadinformationen) zu interagieren, welche zwingend benötigt wird, um KNX-Sensoren und -Aktoren initial zu programmieren. Hier kann ich aber Entwarnung geben, auch das funktioniert mit dem hier vorgestellten Howto über den später beschriebenen “Umweg” mit EIBD problemlos.

Update vom 12.01.2015: Die Version ETS5 Lite, mit welcher sich bis zu 20 KNX-Komponenten verwalten lassen, gibt es preislich reduziert für 60€. Das dafür benötigte KNX-Benutzerkonto lässt sich hier anlegen. Weitere Informationen zur Lizenz gibt es noch im Kommentar von Hardy.

Es sind auch andere Konfigurationen bzw. Kombinationen denkbar, nachfolgende Konfigurationen haben sich jedoch bei mir bewährt. Insgesamt wurde darauf geachtet, dass in jedem Fall eine Verbindung über das jeweilige Gateway sowohl mit FHEM als auch mit ETS4 (wenn auch nicht gleichzeitig) hergestellt werden kann, damit die KNX-Sensoren und -Aktoren sowohl geschaltet (mit FHEM) als auch initial konfiguriert/programmiert (mit ETS4) werden können:

1. Direkter Betrieb des TUL-Stick am USB-Anschluss des FHEM-Servers (z.B. an einem RPI mit wheezy oder Intel NUC mit Ubuntu):

  • Anbindung des TUL-Stick in FHEM: Direkt möglich
  • Remote-Anbindung des TUL-Stick in ETS4 (läuft auf einem externen Windowsrechner): Über EIBD (Schnittstellensoftware) realisierbar

2. Betrieb des TUL-Stick am USB-Anschluss eines über das Netzwerk angebundenen zusätzlichen unixbasierten Servers (z.B. an einem RPI mit wheezy-Image):

  • Remote-Anbindung des  TUL-Stick in FHEM: Über EIBD (Schnittstellensoftware) realisierbar
  • Remote-Anbindung des TUL-Stick in ETS4: Über EIBD (Schnittstellensoftware) realisierbar

3. Betrieb eines KNX-Lan-Gateways (z.B. ABB IPS/S2.1 EIB/KNX IP-Schnittstelle, REG (Affiliate-Link)) über das LAN-Netzwerk:

  • Remote-Anbindung des KNX-Lan-Gateways in FHEM: Über EIBD (Schnittstellensoftware) realisierbar
  • Remote-Anbindung des KNX-Lan-Gateways in ETS4: Direkt möglich

Da für jede der Konfigurationsmöglichkeiten mindestens ein Mal der Betrieb der EIBD-Schnittstellensoftware (Freeware) notwendig ist, wird dessen Installation zuerst beschrieben. (Wer auf EIBD komplett verzichten möchte, benötigt sowohl den TUL-Stick als Schnittstelle zu FHEM als auch ein KNX-Lan-Gateway als Schnittstelle zu ETS4.) EIBD dient kurz gesagt als Schnittstellensoftware zwischen dem physischen Gateway und dem eigentlichen KNX-Bus und dient dabei quasi als Übersetzer zwischen den verwendeten Protokollen (mehr Informationen zu EIBD).

EIBD unter wheezy/Ubuntu installieren

Folgende Installationsschritte wurden bisher erfolgreich mit einem RPI mit wheezy und einem Intel NUC mit Ubuntu mit vorhandener FHEM-Installation durchgeführt. Wenn EIBD auf einem “externen” unixbasierten Server installiert werden soll, der bspw. räumlich getrennt betrieben werden soll, ist natürlich die Installation von FHEM dort nicht notwendig.

Als erstes wird eine Terminalverbindung zum gewünschten Host aufgebaut, auf welchem EIBD installiert werden soll. (Wer sich noch nicht sicher ist, auf welchem System nun EIBD installiert werden soll, sollte sich die Anleitung am besten einmal ganz bis zum Ende durchlesen, evtl. wird es dann ja klarer.) Dazu am Mac in die Spotlight-Suche (auf dem Desktop die Lupe oben rechts) “Terminal” eingeben und den entsprechenden Treffer auswählen. Unter Windows kann das Tool PuTTY (Direktdownload) genutzt werden.

Mit nachfolgendem Befehl erfolgt der Terminallogin auf dem hier verwendeten RPI unter wheezy. Dabei Benutzername (hier: pi) und IP austauschen.

ssh pi@192.168.177.6

Nach dem Drücken der Enter-Taste kommt eine Abfrage, die mit “yes” -> Enter bestätigt wird. Dann noch das gewählte Passwort eingeben und mit Enter bestätigen. Erhält man den Fehler “Host key verification failed.”, muss der Befehl “ssh-keygen -R 192.168.177.6” eingegeben und wiederholt obiger Login-Befehl ausgeführt werden.

Da wir EIBD selbst kompilieren müssen, benötigen wir erstmal das dafür benötigte Werkzeug, welches mit nachfolgendem Befehl installiert wird:

sudo apt-get install build-essential make -y

Danach werden die beiden benötigten Pakete bcusdk und pthsem heruntergeladen und entpackt:

wget -O /tmp/bcusdk_0.0.5.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/eib/bcusdk_0.0.5.tar.gz && tar -xvf bcusdk_0.0.5.tar.gz && wget -O /tmp/pthsem_2.0.8.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/pth/pthsem_2.0.8.tar.gz && tar -xvf pthsem_2.0.8.tar.gz

Update vom 09.02.2017: Mittlerweile hat sich die Installationsroutine geändert. Details dazu im Kommentar von Matthias. Danke für den Hinweis!

Nun wird zum Superuser gewechselt, um die benötigten Berechtigungen zu erhalten:

sudo su

Mit nachfolgendem Befehl wird das Paket pthsem für das System kompiliert und installiert:

cd /tmp/pthsem-2.0.8 && ./configure && make && make install

Analog dazu der Befehl für das zweite Paket bcusdk:

cd /tmp/bcusdk-0.0.5 && export LD_LIBRARY_PATH=/usr/local/lib && ./configure --with-pth=yes --without-pth-test --enable-onlyeibd --enable-eibnetip --enable-eibnetiptunnel --enable-eibnetipserver --enable-tpuarts && make && make install

Der Superuser wird nun wieder verlassen mit:

exit

Abschließend muss noch die dynamische Bibliothek geladen werden:

echo "/usr/local/lib" | sudo tee -a /etc/ld.so.conf.d/bcusdk.conf && sudo ldconfig

Das war es an dieser Stelle bereits mit der Installation von EIBD. Wie der Dienst manuell bzw. direkt bei einem Systemneustart gestartet wird, wird an späterer Stelle beschrieben.

TUL-Stick am RPI flashen

Der TUL-Stick wird standardmäßig ohne Software ausgeliefert und muss erstmal mit der passenden Firmware bespielt werden (weiterführende Informationen dazu gibt es im FHEMWiki und unter Busware).

Also erstmal den TUL-Stick per USB an den RPI (z.B. wheezy) bzw. Intel NUC (z.B. Ubuntu) anschließen und direkt beim Einstecken den kleinen weißen Programmierknopf an dessen Unterseite gedrückt halten. Ich habe dabei festgestellt, dass der RPI beim Einstecken des TUL-Stick automatisch einen Neustart durchführt, sobald der Stick angeschlossen wird (mein iMac hingegen bleibt hingegen einfach an, wenn er dort eingesteckt wird). Also nicht beirren lassen und warten bis der RPI wieder neu gebootet ist, nochmal per Terminal einloggen und mit nachfolgenden Befehlen weitermachen.

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

sudo apt-get install dfu-programmer

Jetzt wird die Firmware heruntergeladen, der TUL-Stick programmiert und das System neugestartet:

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 dauerhaft grün leuchtende LED am TUL-Stick dessen Betriebsbereitschaft. Hängt das KNX-Netz zusätzlich bereits an den entsprechenden beiden Klemmen des TUL-Stick, so leuchtet weiterhin eine rote LED am TUL-Stick.

TUL-Stick in FHEM einbinden (lokaler Betrieb)

Soll der TUL-Stick nach dem erfolgreichen Flashen direkt per USB am FHEM-Server betrieben werden, genügt es, wenn dieser mit nachfolgendem Eintrag in die fhem.cfg eingebunden wird (die physikalische Adresse 1.1.255 muss dabei geändert werden, wenn bereits ein KNX-Gerät im Bus diese Adresse besitzt):

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

TUL-Stick in FHEM einbinden (externer Betrieb)

Soll der TUL-Stick – aus welchen Gründen auch immer – an einem externen Linux-Rechner per USB angeschlossen werden, kann dieser auch über das Netzwerk in der FHEM-Installation über die Nutzung von EIBD integriert werden.

Voraussetzung ist dabei, dass EIBD (wie oben beschrieben) auf dem externen Linux-Rechner installiert wurde, an welchem der TUL-Stick angeschlossen werden soll. Zusätzlich muss sichergestellt werden, dass EIBD automatisch nach dem Neustart des Systems auf externen Linux-Rechner gestartet wird, damit der Dienst auch zur Verfügung steht und der TUL-Stick über das Netzwerk erreichbar ist.

Dazu wird folgender Eintrag in die als crontab externen Linux-Rechners hinzugefügt. Dazu wird erst die Datei mit dem nano-Editor geöffnet:

sudo nano /etc/crontab

Und dann folgender Eintrag in einer neue Zeile ergänzt.

@reboot         root    eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing tpuarts:/dev/ttyACM0

Mit ctrl+o und Enter werden die Änderungen gespeichert und mit ctrl+x wird der Editor wieder verlassen. Jetzt noch ein “sudo reboot” und nach dem Neustart sollte der EIBD-Dienst erfolgreich gestartet werden.

Jetzt noch die fhem.cfg vom FHEM-Server mit nachfolgendem Eintrag ergänzen (als IP-Adresse – hier 192.168.177.91 – muss natürlich die Adresse vom externen Linux-Rechner eingetragen werden, an welchem der TUL-Stick angeschlossen ist und EIBD läuft:

define KNX TUL eibd:192.168.177.91 1.1.255

KNX-Lan-Gateway in FHEM einbinden

Wenn ein KNX-Lan-Gateway (z.B. ABB IPS/S2.1 EIB/KNX IP-Schnittstelle, REG (Affiliate-Link)) in FHEM eingebunden werden soll, muss zwingend auch EIBD genutzt werden, so dass FHEM über EIBD mit dem KNX-Lan-Gateway kommunizieren kann. Wurde EIBD auf dem FHEM-Server installiert, muss hier die crontab entsprechend angepasst werden, damit der EIBD-Dienst beim Hochfahren des FHEM-Servers mit gestartet wird. Dazu wird erst die Datei mit dem nano-Editor geöffnet:

sudo nano /etc/crontab

Und dann folgender Eintrag in einer neue Zeile ergänzt. Die IP am Ende des Befehls ist die IP-Adresse des KNX-Lan-Gateways und muss dabei natürlich jeder inidviduell anpassen:

eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.177.93

Mit ctrl+o und Enter werden die Änderungen gespeichert und mit ctrl+x wird der Editor wieder verlassen. Jetzt noch ein “sudo reboot” und nach dem Neustart sollte der EIBD-Dienst erfolgreich gestartet werden.

Jetzt noch die fhem.cfg vom FHEM-Server mit nachfolgendem Eintrag ergänzen:

define KNX TUL eibd:localhost 1.1.255

Und das KNX-Lan-Gateway ist erfolgreich eingebunden.

TUL-Stick zum Programmieren von KNX-Komponenten in ETS4 nutzen

Der TUL-Stick soll dabei weiterhin am Linux-Rechner angesteckt bleiben und über EIBD für die ETS4-Software an einem Windows-Rechner zum Programmieren von KNX-Komponenten zur Verfügung gestellt werden. Theoretisch kann der TUL-Stick auch direkt per USB an den Windows-Rechner angeschlossen werden. Hier werden aber zusätzliche Treiber benötigt, die teilweise (je nach Windows-Version) gar nicht oder schwierig zum Laufen zu bringen sind.

Der TUL-Stick wird automatisch in ETS4 erkannt, wenn er über EIBD zur Verfügung gestellt wird (die Schritte für das automatische Starten des EIBD-Services bei einem Neustart – wie oben beschrieben – sind dabei nicht notwendig). Wenn der TUL-Stick dabei per USB direkt am FHEM-Server hängt, muss sein define-Eintrag kurz mit einer angeführten Raute (#define EIB TUL tul:/dev/ttyACM0@57600 1.1.255) aus der fhem.cfg auskommentiert und FHEM am besten mit “shutdown restart” neugestartet werden, damit EIBD mit dem Ausführen folgenden Terminalbefehls beim Start des EIBD-Services auf den TUL-Stick zugreifen kann:

eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing tpuarts:/dev/ttyACM0

KNX-Lan-Gateway zum Programmieren von KNX-Komponenten in ETS4 nutzen

KNX-Lan-Gateways wie die ABB IPS/S2.1 EIB/KNX IP-Schnittstelle (Affiliate-Link) werden automatisch von ETS4 erkannt und müssen nur über EIBD eingebunden werden, wenn sie in FHEM zur Steuerung von KNX-Komponenten genutzt werden sollen.

Über FHEM einen KNX-Aktor schalten

Erkennt FHEM Schaltvorgänge über das eingebundene KNX-Gateway, so werden entsprechende Geräte per autocreate der fhem.cfg automatisch hinzugefügt. Aktoren lassen sich natürlich auch manuell über deren “virtuelle” Gruppenadresse/logische Adresse (hier 0/0/1 – theoretisch bis 13/7/255) in die fhem.cfg einbinden. Das sieht dann bspw. so aus:

define WZ.Tischlampe EIB 0/0/1
attr WZ.Tischlampe IODev KNX
attr WZ.Tischlampe room Wohnzimmer

Nach dem Speichern der Konfiguration kann der Aktor bereits über FHEM geschaltet werden. Daneben sind auch neben Ein-Aus-Aktoren (wie dem ABB SA/S4.6.1 EIB/KNX Schaltaktor, 6A, REG, 4-fach (Affiliate-Link)) weitere KNX-Sensoren und -Aktoren über zusätzliche Modellattribute einbindbar.

Tempertaursensor:

define WZ.Temperatur EIB 0/0/2
attr WZ.Temperatur model tempsensor
attr WZ.Temperatur IODev KNX
attr WZ.Tempeartur room Wohnzimmer

Heizungsventil:

define WZ.Heizung EIB 0/0/3
attr WZ.Heizung model percent
attr WZ.Heizung IODev KNX
attr WZ.Heizung room Wohnzimmer

Aus meinem täglichen Leben

Ich habe lange überlegt, ob ich mir KNX “antun” soll, da das System im Vergleich zu anderen Systemen wie HomeMatic oder FS20 insgesamt schwieriger handhabbar/programmierbar ist, die Hardwareinstallation zudem durch die kabelgebundene Ansteuerung wesentlich aufwändiger ist (jeder Verbraucher muss mit dem zweiadrigen KNX-Buskabel angebunden werden) und die Komponenten insgesamt auch ein gutes Stück teurer sind. Sieht man auf der anderen Seite aber das Potenzial eines weitgehend autonom agierenden professionellen Bussystems, bei dem alle Komponenten eine gewisse “Grundintelligenz” besitzen und auch beim Ausfall einer übergeordneten Steuereinheit (in diesem Fall FHEM) weiterhin direkt miteinander kommunizieren und komplexere Schaltvorgänge auslösen können, bereue ich den Einstieg in die Welt von KNX bisher in keinster Weise.

Hinzu kommt, dass mittlerweile über 200 Firmen verschiedenste Sensoren und Aktoren anbieten, die durch das einheitliche KNX-Protokoll komplett zueinander kompatibel sind und somit so gut wie alle denkbaren Anwendungsgebiete eines Smart Homes abdecken können. Ein guter Onlineshop mit großer Auswahl für KNX-Komponenten scheint mir dabei übrigens voltus zu sein. Die Anbindung per FHEM mit dem TUL-Stick oder einem KNX-Lan-Gateway wie der ABB IPS/S2.1 EIB/KNX IP-Schnittstelle (Affiliate-Link) ist dabei natürlich das Tüpfelchen auf dem i, womit erweiterte Szenarien bspw. zum Energiesparen oder zur Überwachung mit Hilfe von FHEM absolut flexibel realisiert werden können. Wie KNX grundsätzlich funktioniert und wie Geräte über die ETS4-Software initial programmiert werden müssen, um sie nachfolgend auch in FHEM ansteuern zu können, folgt bald in einem weiteren Blogbeitrag in der KNX-Reihe.

Affiliate-Links

[easyazon_image align=”none” height=”110″ identifier=”B000UW91MQ” locale=”DE” src=”https://meintechblog.de/wordpress/wp-content/uploads/2015/06/41ZWp8juWxL.SL110.jpg” tag=”meintechblog-140601-21″ width=”69″][easyazon_image align=”none” height=”110″ identifier=”B001BCU78G” locale=”DE” src=”https://meintechblog.de/wordpress/wp-content/uploads/2015/06/41t0ow2bMHL.SL110.jpg” tag=”meintechblog-140601-21″ width=”71″][easyazon_image align=”none” height=”69″ identifier=”B008PT4GGC” locale=”DE” src=”https://meintechblog.de/wordpress/wp-content/uploads/2015/06/41h0dWmbv8L.SL1101.jpg” tag=”meintechblog-140601-21″ width=”110″]

132 Kommentare
  1. Hallo Jörg,

    erstmal herzlichen Dank für diesen tollen Blogeintrag! Ich habe bei mir auch fhem auf einem RaspberryPi und ebenfalls ein ABB IPS/S2.1 KNX/IP Gateway (Affiliate-Link) im Einsatz. Leider wird dieses Gateway von ETS4 bei mir nicht automatisch erkannt, in der Herstellerdokumentation findet sich leider nur eine Anleitung zur Konfiguration unter ETS3. Vielleicht hast Du noch einen Tipp für mich wie man die Einbindung des Gateways in ETS4 manuell durchführen kann?

    Herzlichen Dank für Deine Hilfe, freundliche Grüße
    Kurt

    1. Hi Kurt,
      wenn du die IP-Adresse deines IP-Gateways kennst, kannst du diese manuell in ETS4 eingeben, dann sollte es funktionieren. Um die IP-Adresse herauszufinden, kannst du diese normalerweise in deinem Router (z.B. Fritzbox unter Heimnetz) ausfindig machen, sofern das IP-Gateway eine Netzwerkadresse per DHCP erhält oder eine statische IP-Adresse im korrekten Netzwerkbereich hat. Wenn das IP-Gateway aber irgendwann mal eine statische IP-Adresse (z.B. 192.168.177.2) zugewiesen bekommen hat, die sich nicht im aktuellen Netzwerkbereich des DHCP-Servers (z.B. 192.168.1.x) befindet, funktioniert das aber bspw. nicht. Dann müsstest du die genaue Adresse des IP-Gateways zwingend kennen und die IP-Adresse deines ETS4-Rechners manuell in den selben Bereich bringen, um diesen ansprechen zu können. Im Notfall könnte man das IP-Gateway natürlich auch auf die Werkseinstellung zurücksetzen, dann sollte automatisch per DHCP eine korrekte Adresse zugewiesen werden. In diesem Fall müsste man dem IP-Gateway aber über ETS4 wieder eine passende KNX-Gruppenadresse zuweisen, um mit den KNX-Komponenten sprechen zu können… Aber vielleicht hilft dir diese Info ja schon mal weiter. Wenn du noch Hilfe benötigst, meld dich einfach wieder.
      Grüße
      Jörg

  2. Hallo Jörg,

    besten Dank für Deine schnelle Hilfe, nach dem 3ten aus-/einschalten des KNX/IP-Gateways hat die DHCP IP-Adresszuweisung endlich funktioniert 😉

    Freundliche Grüße,
    Kurt

  3. Hallo Jörg,

    ich habe das Problem, das ich keine Verbindung zu meinem KNX-LAN-Gateway bekomme.
    Ich verwende das Interface von Weinzierl IP 730. Mit der ETS3 bekomme ich eine Verbindung.

    Der Logfile des FHEM-Servers siehe wie folgt aus.

    2014.07.25 01:06:18 1: Including fhem.cfg
    2014.07.25 01:06:19 3: telnetPort: port 7072 opened
    2014.07.25 01:06:19 3: TUL opening tul device eibd:localhost
    2014.07.25 01:06:19 3: Can’t connect to eibd:localhost: Connection refused
    2014.07.25 01:06:21 3: WEB: port 8083 opened
    2014.07.25 01:06:21 3: WEBphone: port 8084 opened
    2014.07.25 01:06:21 3: WEBtablet: port 8085 opened
    2014.07.25 01:06:22 1: Including ./log/fhem.save
    2014.07.25 01:06:22 1: usb create starting
    2014.07.25 01:06:24 3: Opening CUL device /dev/ttyAMA0
    2014.07.25 01:06:24 3: Setting CUL baudrate to 38400
    2014.07.25 01:06:24 3: CUL device opened
    2014.07.25 01:06:24 3: Opening TCM310 device /dev/ttyAMA0
    2014.07.25 01:06:24 3: Setting TCM310 baudrate to 57600
    2014.07.25 01:06:25 3: TCM310 device opened
    2014.07.25 01:06:25 1: usb create end

    Hätte du einen Rat für mich?

    Gruß Michael

    1. “Can’t connect to eibd:localhost: Connection refused” spricht wohl schwer dafür, dass FHEM nicht auf den EIB-Daemon (eibd) zugreifen kann. Bitte mal den entsprechenden Eintrag in der fhem.cfg überprüfen und evtl. nachsehen, ob der EIB-Daemon (eibd) korrekt gestartet wird. Hoffe das hilft dir weiter…
      Jörg

    2. Hallo Michael,

      ich habe heute Abend auch mal den Versuch gestartet eine Ubuntu VM aufzusetzen und den FHEM an meinen KNX Bus dranzuhängen. Installation Dank des Super Blogs hier problemlos. Ich verwende eine KNX-IP Interface von Jung. Ich hatte den gleichen Fehler wie Du. Ich habe dann mal den EIBD von der Konsole gestartet, das ging problemlos. Ich habe dann den Eintrag in der Crontab geprüft, weil scheinbar der Dienst beim Reboot nicht startet. Ich habe den Eintrag über den Nano Editor mittels SSH und Putty über Copy und Paste reinkopiert. Scheinbar geht dabei folgendes “@reboot root ” verloren, weshalb der Dienst nicht startet. Einfach nochmal mit nano editieren und das fehlende Stück ergänzen, dann über sudo reboot neustarten. Dann ist die KNX Schnittstelle im FHEM verfügbar. Ich hoffe das hilft und ist nicht zu spät. 🙂

      Beste Grüße
      Marcel

  4. Hallo Jörg,

    super Anleitung, hat unter ubuntu auch super funktioniert. Jetzt hab ich’s noch unter cygwin probiert, config, make, makeinstall von bcusdk und pthsem sind durchgelaufen, aber Verbindung bekomme ich leider keine:

    $ eibd -t 1023 -S -D -R -T -i –no-tunnel-client-queuing ipt:192.168.15.147
    Layer 2(800205C8,54024967) Open
    Layer 0(800587E8,54024967) Open
    Layer 0(800587E8,54024967) Openend
    Layer 2(800205C8,54024967) Opened
    Layer 3(80078C30,54024967) Open
    Layer 8(800588C8,54024967) OpenInetSocket 6720
    Layer 8(800588C8,54024967) InetSocket opened
    Layer 8(80099018,54024967) Open
    Layer 0(80099088,54024967) Open
    Layer 0(80099088,54024967) Openend
    Layer 0(80099088,54024967) Close
    Layer 1(800587E8,54024967) Send(020): 08 01 C0 A8 0F 86 0E 58 08 01 C0 A8 0F 86 0E 58 04 04 02 00
    Layer 0(800587E8,54024967) Send(026): 06 10 02 05 00 1A 08 01 C0 A8 0F 86 0E 58 08 01 C0 A8 0F 86 0E 58 04 04 02 00
    initilization of the EIBnet/IP server failed

    Über die ETS4 kann ich auf das IP Gateway (Weinzierl 730) ohne Probleme zugreifen. Auch mit Smartphone und OSX über mediola a.i.o. remote.

    Kann es an bereits bestehenden Verbindungen zum IP Gateway liegen (ETS4, Smartphone und OSX über mediola a.i.o. remote)? Aber das Gateway kann doch bis zu 5 Verbindungen, und ETS4 und mediola a.i.o. remote funktionieren auch parallel…

    Bin dankbar für jeden Hinweis!

    Viele Grüße, Jan

  5. Hallo,

    habe fast alles zum Laufen bekommen. Vielen Dank für die tolle Beschreibung.

    Ich bekomme nur den Eibd nur nicht zum Autostart.

    Hat sonst noch jemand das Problem?

    Mir ist noch aufgefallen, dass dieser Befehl bei mir nicht geht:
    wget -O /tmp/bcusdk_0.0.5.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/eib/bcusdk_0.0.5.tar.gz && tar -xvf bcusdk_0.0.5.tar.gz && wget -O /tmp/pthsem_2.0.8.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/pth/pthsem_2.0.8.tar.gz && tar -xvf pthsem_2.0.8.tar.gz

    Beim Entpacken wird aus dem Unterstrich ein Bindestrich

    Gruß Tobi

    1. Laut deiner Anleitung soll ja der Teil dafür sein das Eibd automatisch startet:

      eibd -t 1023 -S -D -R -T -i –no-tunnel-client-queuing ipt:192.168.177.93

      Mit ctrl+o und Enter werden die Änderungen gespeichert und mit ctrl+x wird der Editor wieder verlassen. Jetzt noch ein “sudo reboot” und nach dem Neustart sollte der EIBD-Dienst erfolgreich gestartet werden.

      Nach einem Reboot muss ich aber den Befehl per Putty ausführen damit Eibd startet.

    2. Hi,

      der Eintrag hat nichts in der crontab verloren. Die crontab ist fuer
      periodisch sich wiederholende Aufgaben, nicht zum Starten von Prozessen beim Booten. Fuer den eibd gehoert IMHO ein Script
      in /etc/init.d und eine symlink darauf in /etc/rcX.d, wobei X fuer die Nummer des Runlevels steht, in dem eibd laufen soll.
      Ok, jetzt haben wir November, Dein Post ist vom September, also hast Du’s wahrscheinlich schon.
      Gruesse
      Rop.

    3. Hi,

      vielen Dank!!! Du hast mich auf den richtigen weg gebracht.

      init.d war das Zauberwort. Und da ich einen IP Router habe muss ich den Eibd mit andern Parameter starten. Die genau lösung gibt’s hier:
      http://knx-user-forum.de/knx-eib-forum/26873-eibd-und-ko-gateway-2.html

    4. Hi,

      sorry für meine Nachfragen.

      Ich habe leider immer noch nicht herausgefunden,
      a) wie man EIBD manuell starten kann.
      b) was ich genau, jetzt wo eintragen muss, damit der Autostart funktioniert. In der Antwort vom Gast vom 16.11.2014 steht: “Fuer den eibd gehoert IMHO ein Script in /etc/init.d und eine symlink darauf in /etc/rcX.d, wobei X fuer die Nummer des Runlevels steht, in dem eibd laufen soll.”
      Was genau muss ich dort als Script und finde rcX,d eintragen. Meine Konfiguration ist Rasperry 2, FHEM und TUL-Stick. Freundliche Grüsse Axel

  6. Hallo,
    vielen Dank für den super Beitrag!
    Es sind ja jetzt schon ein paar Monate her seit dieser Blog entstanden ist. Mich würde interessieren, ob bereits eine Tendenz in Sachen Stabilität und Performance des TUL-Sticks abzusehen ist.

    Viele Grüße
    Simon

    1. Hallo Simon,
      bzgl. Stabilität kann ich leider nur bedingt Auskunft geben, da ich den TUL immer nur testweise in Betrieb genommen habe. Während dieser Zeit lief er aber tadellos und ohne Probleme.
      Grüße
      Jörg

  7. Hello, I’m trying to use Fhem with KNX and Z-WAVE. KNX works and Z-WAVE too but … my aim is interconnect a device z-wave with the knx bus. By example, i have a blind actuator zwave. fhem is able to use it perfectly. I have created a fake knx device to represent my zwave blind actuator. With a rule in the fhem i am able to send a command from knx a transmit it to zwave device (KNX_store1:off.* set zw_store1 off) but i’m not capable to send zwave device status to knx… i don’t know how proceed. If i invert the command i have a loop ! Could you help me with that ? Thanks.

  8. Hallo Jörg,

    bei mir läuft seit ca. 1 Jahr der Raspberry Pi in Verbindung mit der ROT-Extension von Busware, um auf meine EIB-Installation zuzugreifen. Zusätzlich steuert der Raspi noch über die CUL433 meine Baumarkt Geräte-Steckdosen. Verwaltet wird alles von FHEM.

    Probleme? Keine.

  9. Hallo Jörg,

    vielen Dank für diese super Anleitung. ich habe nur an einer Stelle kleines Problemchen und zwar die Archive werden nicht in /tmp/ sondern in /etc/ entpackt. So musste ich etwas suchen. Nach der Installation erscheint auf der Webseite von Fhem leider die Meldung:
    TUL
    KNX disconnected;
    Ich nutze den KNX-Gateway ABB IPS/S2.1
    ich kann mein Bussystem auch nicht ansteuern. Was habe ich falsch gemacht?

    Vielen Dank im Voraus

    Gruß

    Marek

    1. @marek: hast du TUL und KNX-Gateway ABB IPS/S2.1 gleichzeitig im einsatz? beide greifen auf den KNX bus zu, benötigen tust Du aber nur einen von beiden. Mit TUL brauchst Du kein Gateway, mit Gateway kein TUL. Hats Du das beachtet?

      @Jörg: erwähnenswert ist, das die ETS4 bzw ETS5 Software nach einem kleinen KNX Campus jedem als LITE Version mit 20KNX Komponenten zur Verfügung steht.

    2. http://wbt5.knx.org/
      man bekommt einen 140€ gutschein für ets5 lite, somit kostet dann 60€ für 20KNX Komponenten. zu ets4 zeiten gabs die lite version umsonst nachdem ecampus.

    3. Habe jetzt mal die Online-Lernumgebung absolviert und ETS5 Lite bestellt. Die Kosten inkl. Gutschein belaufen sich insgesamt auf 89,25€, da zu den 60€ noch 15€ für den USB-Stick und Versandkosten sowie 14.25€ MwSt. hinzukommen.
      Bin gespannt, welche Verbesserungen die neue Version beinhaltet.

  10. Hallo Jörg,
    erst einmal vielen Dank für deinen Blog und deine tollen Beiträge, die mir mittlerweile schon sehr oft geholfen haben. 🙂
    Ich habe einen raspberry pi auf dem mein fhem läuft, und einen tul von busware (direkt am raspberry angeschlossen) mit dem ich auf meine knx Installation zugreifen.
    Nun möchte ich auch mit ETS 4 (von meinem Windows laptop aus) meinen bus programmieren.
    Habe gestern nach deiner Anleitung schon einiges hin bekommen. Beispielsweise kann ich in ETS mit dem busmonitor befehle die z.b. von Lichtschalter kommen auslesen. Mehr geht aber nicht 🙁 eine Verbindung oder Programmierung eines Schalters bricht ab, weil ETS sich mit dem gerät nicht verbinden kann?! Aber der busmonitor z.b. funktioniert ja = Verbindung besteht?!?
    Als nächstes ist mir aufgefallen, dass durch das ausklammern mittels # des TUL in der fhem config ich (natürlich) mit fhem nichts mehr steuern kann, bis ich die # wieder lösche. Ist das normal bzw. ist hier ein Parallelbetrieb von eibd und funktionierenden fhem nicht möglich? Gleichzeitig steigt nach dem löschen der # die cpu-last des raspberry auf 100%, es hilft nur ein Neustart um dann wieder mit fhem arbeiten zu können.

    So, ich hoffe du hast evtl den ein oder anderen Tipp für mich 🙂
    Vielen dank

    1. Hi Hermann,
      ein Parallelbetrieb mit einem TUL-Stick, um gleichzeitig über ETS4 und FHEM auf den KNX-Bus zuzugreifen, funktioniert nicht. Die entsprechende Passage im Blogpost habe ich einmal fett markiert, damit man das nicht so leicht überliest. Du musst also erst einmal deine TUL-Config in der fhem.cfg mit einer Raute am Zeilenbeginn auskommentieren und FHEM neustarten, bevor du den Zugriff per ETS4 aufbaust. Dann sollte die Konfiguration über ETS4 auch funktionieren. Entsprechend musst du vorgehen, um den TUL-Stick dann wieder in FHEM nutzen zu können. Also die Verbindung zu ETS4 trennen (ETS4 schließen), die Auskommentierung in der fhem.cfg wieder entfernen und FHEM nochmals neustarten. Hoffe damit kommst du weiter!
      Grüße und viel Erfolg
      Jörg

  11. zum KNX LAN Gateway:
    Eine feste IP Adressvergabe des LAN Gateway kann mit einem direkt verbundenen ETS5 nicht erfolgen, hierfür ist ein KNX USB oder eine weiteres KNX LAN Gateway erforderlich(also nur DHCP Betrieb möglich).

  12. Kann es sein, dass eibd mit einem raspberry 2 Probleme hat bzw. nicht funktioniert? Bin heute von meinem b+ auf den 2’er umgezogen und eibd scheint nicht zu funktionieren.
    Vorher ging es einwandfrei. Meine Config: Raspberry mit fhem und eibd; am raspberry hängt direkt über usb der busware TUL; mit ETS 4 kann (konnte) ich über WLan auf meinen BUS zugreifen und programmieren.

    Habe zur Sicherheit nochmal alles kompiliert bzw. installiert (eibd) ….lief einwandfrei durch.
    Da der raspberry 2 so schnell ist 😉 konnte ich nur kurz während dem kompilieren irgendwo aufschnappen, dass eine unbekannte cpu/ARM verwendet wird (kanns leider nicht genauer wiedergeben)

    1. …hat sich erledigt.
      Habe nochmals alles nach obiger Anleitung durchgeführt und nun funktioniert es wieder 🙂

  13. Hi Jörg,
    letztendlich hat deine Anleitung mich motiviert eibd auf einem Raspberry B+ mit einem Merten USB Interface zu installieren.
    Ich habe ein ETS5, die den eibd erkannt hat. Ich kann Geräte Programmieren, das ist alles kein Problem.
    Veruche ich über die ETS einen Befehl zu senden, dann geschieht nichts.
    Im Monitor kann ich allerdings sehen, das der Befehl “raus” geht, aber mit Quelle 0.0.0. Ich denke da ist das Problem.
    Auch ein groupswrite vom Raspberry führt zu keinem Ergebnis (am KNX Bus), aber im Busmonitor zur selben Quelle 0.0.0.
    Hast du da einen Tipp für mich?

  14. Moin Jörg,

    vielen Dank für den Post. Durch diesen Post, die Verständliche Weise in der du geschrieben hast und den vielen Infos habe ich mich entschlossen FHEM in Kombination mit EIB/KNX in meine Wohnung einzubauen. Allerdings mag ich die ganzen Funktaster nicht, drum möchte ich via EIB/KNX Sensor (4 fach) die Aktoren Steuern.

    Ich benötige im Wohnzimmer 4 Aktorausgänge, möchte somit einen 4 fach Taster/Sensor von Busch Jäger ect. einbinden.

    Kann ich die Tastsignale am Bus (Taster * Busankoppler) durch FHEM auslesen?

    gruß Marcus

  15. Zum eibd: es gibt jetzt einen Fork, der knxd heißt und der ein paar weniger Bugs hat. Könntest du bitte stattdessen auf den verweisen? http://github.com/knxd/knxd

    Der Daemon heißt jettzt knxd, die Argumente musst du etwas umsortieren: das -S muss *nach* -D -R -T angegeben werden. Startskripte für Debian (mit und ohne systemd) liefet der knxd mit, das Herumkritzeln in der crontab entfällt. Stattdessen muss man /etc/default/knxd (ohne system) bzw. /etc/knxd.conf (mit systemd) anfassen.

    “sudo su” ist irgendwie doppelt gemoppelt, zumal so manche kleine Debian-Installation gar kein /bin/su mehr *hat*. “sudo bash” bitte.

    1. Hi Matthias,
      danke für deine Anmerkungen!
      Habe mich schon lange nicht mehr mit eibd auseinandergesetzt, da ich meine Komponenten mittlerweile direkt per KNX-Gateway am Loxone Miniserver anbinde. Werde mir das aber mit FHEM und knxd die kommenden Tage/Wochen genauer im Rahmen eines Kundenprojekts ansehen. Denke ich schreibe dann direkt einen neuen Blogpost, sonst wird evtl. etwas unübersichtlich.
      Würde mich dann wieder über Feedback von dir freuen!

      Grüße
      Jörg

  16. Hallo Jörg

    kannst du mir weiterhelfen habe folgendes Problemchen
    meine EIB/KNX installation läuft über ein Tul stick, den habe ich nach dieser Anleitung installiert , leider kommen immer die gleichen meldungen im log dadurch wird die log Datei extrem groß nach drei Tagen ist meine fhem-2015-09.log bereits 80MB groß

    2015.08.31 15:21:41 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.08.31 15:21:41 3: TUL EIB refused message: 9c11644204e300800d28
    2015.08.31 15:21:41 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.08.31 15:21:41 3: TUL EIB refused message: 9c11644204e300800d28
    2015.08.31 15:21:41 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.08.31 15:21:41 3: TUL EIB refused message: 9c11644204e300800d28
    2015.08.31 15:21:43 3: Control Byte 0x94 does not match expected mask 0xB0
    2015.08.31 15:21:43 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.08.31 15:21:43 3: Control Byte 0x94 does not match expected mask 0xB0
    2015.08.31 15:21:43 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.08.31 15:21:43 3: Control Byte 0x94 does not match expected mask 0xB0
    2015.08.31 15:21:43 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.08.31 15:21:43 3: Control Byte 0x9c does not match expected mask 0xB0

    woran kann das liegen ???

    1. Hallo Eugen,
      für mich sieht das so aus, als wäre der entsprechende test im FHEM-Modul falsch. Da steht (beim mir in Datei FHEM/00_TUL.pm Zeile 747):

      if(($ctrl & 0xB0)!=0xB0)

      Die entsprechende Codestelle im knxd sieht ganz anders aus, da steht stattdessen (auf FHEM übersetzt):

      if(($ctrl & 0xD0)!=0x90)

      Ersetz diese Zeile doch mal und schau nach ob das was bringt.

  17. Hallo Matthias

    Nein leider hat es nichts gebracht, habe immer noch die Meldungen kann das eventuell sein das der Tul fehlerhaft geflascht wurde

    2015.09.03 19:58:02 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.09.03 19:58:02 3: Control Byte 0x94 does not match expected mask 0xB0
    2015.09.03 19:58:02 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.09.03 19:58:02 3: Control Byte 0x94 does not match expected mask 0xB0
    2015.09.03 19:58:02 3: TUL EIB refused message: 9411224000e50080000004f6
    2015.09.03 19:58:02 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:02 3: TUL EIB refused message: 9c11224001e5008000000000
    2015.09.03 19:58:02 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:02 3: TUL EIB refused message: 9c11224001e5008000000000
    2015.09.03 19:58:02 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:02 3: TUL EIB refused message: 9c11224001e5008000000000
    2015.09.03 19:58:03 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:03 3: TUL EIB refused message: 9c11224300e5008000039518
    2015.09.03 19:58:03 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:03 3: TUL EIB refused message: 9c11224300e5008000039518
    2015.09.03 19:58:03 3: Control Byte 0x9c does not match expected mask 0xB0
    2015.09.03 19:58:03 3: TUL EIB refused message: 9c11224300e5008000039518
    2015.09.03 19:58:03 3: Control Byte 0x9c does not match expected mask 0xB0

  18. ?? Sehen wir uns mal die Bits an:

    0x94 == 10010100
    0xD0 == 11010000
    Resultat: 10010000 == 0x90

    Mit anderen Worten: die Zeile hat so gefälligst zu funktionieren, d.h. deine Änderung war irgendwie falsch. Hast du die richtige Datei angefasst? die richtige Zeile editiert? FHEM neu gestartet? Dich evtl. vertippt / übersehen dass ich ZWEI Buchstaben geändert habe? Usw.

  19. Hi Leute kann mir jemand weiterhelfen

    Wenn mein Tul-Stick eingesteckt ist und ich dem Raspi neustarte ist meine Fhem Oberfläche nicht mehr erreichbar (oder Stromausfall ).
    Wenn ich mein Raspi neustarten will muss ich zuerst den Tul ausstecken und einstecken sobald Fhem geladen ist sonst läuft er nicht

  20. Nimm mal deine Konfig auseinander. Irgendwas versucht auf /dev/ttyACM0 zuzugreifen und fliegt auf die Nase, wenn es da tatsächlich was findet.

    Oder FHEM manuell starten mit gestecktem Stick und die Logs anschauen. Vorher auf Quasselmodus stellen.

  21. Hi Matthias

    die Datei /dev/ttyACM0 ist nicht vorhanden kannst du es mir bitte mehr erläutern wie ich das anstellen soll ( bin noch ziemlich unerfahren )

    Bin ich eigentlich der einzige bei dem der Stick Probleme macht ?

  22. Moin Moin,
    vielen Dank für den Post. Durch diesen Post, die Verständliche Weise in der du geschrieben hast und den vielen Infos habe ich mich entschlossen FHEM in Kombination mit EIB/KNX in meine Wohnung einzubauen. Allerdings mag ich die ganzen Funktaster nicht, drum möchte ich via EIB/KNX Sensor (4 fach) die Aktoren Steuern.
    Ich benötige im Wohnzimmer 4 Aktorausgänge, möchte somit einen 4 fach Taster/Sensor von Busch Jäger ect. einbinden.
    Kann ich die Tastsignale am Bus (Taster * Busankoppler) durch FHEM auslesen?
    gruß Marcus

  23. @Eugen: die Datei ist nicht “leer”, das ist ein Gerät. Sie existiert, das reicht. Ändert nichts daran dass irgendwas das Ding ausliest und dabei auf die Nase fliegt. Stell FHEM auf Debugmodus und provoziere den Fehler, dann wirst du im Log hoffentlich finden was kaputt ist.

    @Marcus: Klar kannst du!

  24. Hallo zusammen,
    möchte mich erst mal für die tollen Beschreibungen auf dieser Seite bedanken.
    Mein Problem, das ich momentan habe, ist das selbe wie @eugen, mein FHEM starte nur noch ohne TUL, der Fehler tritt auf nachdem ich ein Update in FHEM gemacht habe. Gibt es da eine Lösung?
    Gruß Erich

  25. Hallo,

    hat jemand den FHEM schon mit dem IP-Router IPR/S 2.1 von ABB gekoppelt? die ETS-KNX Programmierung läuft. Mit “eibd -t 1023 -S -D -R -T -i –no-tunnel-client-queuing ipt:2.168.1.240” bekomme ich auch Meldungen auf der Konsole, aber der FHEM sagt immer “KNX disconnected”

    1. Hallo Georg,

      gleiches Problem habe ich auch. Hast Du schon eine Lösung gefunden?
      Ich bin erst seit dieser Woche mit FHEM unterwegs und komme momentan nicht weiter. Woran sieht man eigentlich das eibd läuft?

    2. Hi,
      würde euch gerne helfen. Da ich aber aktuell alle KNX-Komponenten direkt über den Loxone Miniserver angebunden habe und somit den Weg über FHEM nicht mehr einsetze, kann ich leider keinen Input geben. Hoffe ihr kommt bald zum Ziel! Evtl. hilft euch ja auch das FHEM-Forum weiter…

      Grüße und viel Erfolg
      Jörg

  26. “Läuft KNXD” kann man feststellen durch “knxtool groupswrite local: 1/2/3 1” (Einschalten der Lampe mit der Gruppenadresse 1/2/3) oder “knxtool groupsocketlisten local:” (Bus beobachten, damit man rausbekommt welche Adresse die doofe Leuchte überhaupt hat).

  27. Hallo Matthias,

    ich habe nun mittlerweile das KNXD halbwegs am laufen. Halbwegs deshalb, weil ich zwar die KNX-Befehle vom Bus empfangen kann aber ich kann nicht auf den Bus senden.
    Ich hatte bei der Installation Probleme mit dem neuen “jessie”. Da lies sich KNXD nicht fehlerfrei installieren. Daraufhin dann nochmal mit wheezy neu aufgesetzt, wobei die Installation durchlief. Allerdings nun mit dem obigen Problem. Vielleicht weißt du da weiter und kannst mir einen Rat geben.

    Gruß Gerhard

    1. “Da ließ sich KNXD nicht fehlerfrei installieren.” ist keine Fehlerbeschreibung, mit der ich was anfangen kann. Du gehst ja auch nicht zum Autofritzen und fragst ihn “mein Auto fährt nicht, was soll ich machen”. Bitte Protokoll der Terminalsitzung o.Ä.

      Zum Senden: selbes Thema. Wie hast du den knxd konfiguriert, wie sieht deine Infrastruktur aus, etc.pp.

  28. Hallo Matthias,
    Vielen Dank für Deine schnelle Antwort. Entschuldige bitte meine schlechte Beschreibung! Habe aber die KNX-Kommunikation mittlerweile hinbekommen. Allerdings nach einem Neustart des Raspi startet KNXD nicht automatisch obwohl ich in der “/etc/default/knxd” die Eintragungen START_KNXD=YES und DAEMON_ARGS=”-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.0.234″ entsprechend abgeändert habe.
    nach Neustart:
    pi@raspberrypi ~ $ /etc/init.d/knxd status
    [FAIL] knxd is not running … failed!

    Wenn ich den letzten Befehl der Einrichtung (sudo dpkg -i knxd_*.deb knxd-tools_*.deb) nochmal aufrufe läuft KNXD wieder problemlos.
    wie bekomme ich einen Autostart von KNXD zustande?

    Gruß Gerhard

  29. Du brauchst den knxd nicht neu installieren, “/etc/init.d/knxd start” reicht aus. Autostart geht eigentlich mit einem Symlink in /etc/rc3.d (oder rc2.d, je nachdem was in deiner /etc/inittab steht). Existiert der?

    Wenn ja: mach sämtliche Debuggingoptionen an (-f9 -t1023 -d/tmp/knxd.log) und starte den Pi neu, dann wird er dir hoffentlich in diesem Log verraten wieso er sich auf die Nase legt.

  30. Hallo Matthias,
    ich bin halt in diesem System nicht beheimatet…
    Das mit dem “/etc/init.d/knxd start” habe ich auch schon probiert. Da bekomme ich allerdings immer folgende Meldung:
    pi@raspberrypi ~ $ /etc/init.d/knxd start
    E00000016: OpenLocalSocket /tmp/eib: bind: Address already in use
    initialisation of the knxd unix protocol failed: Address already in use

    welche nicht zum Ziel führt und welche ich auch nicht interpretieren kann

    Gruß Gerhard

    1. In dem Fall läuft der knxd doch schon, also wo liegt das Problem? siehe Ausgabe von “ps”.
      Wenn er trotzdem nicht tut, dann “restart” statt” start”.

  31. Hallo Matthias,
    habe das ganze nochmal neu begonnen. Dabei bin ich bis zu folgenden Punkten gekommen:
    pi@raspberrypi:~ $ tar xzf pthsem_2.0.8.tar.gz
    pi@raspberrypi:~ $ cd pthsem-2.0.8
    pi@raspberrypi:~/pthsem-2.0.8 $ dpkg-buildpackage -b -uc
    dpkg-buildpackage: source package pthsem
    dpkg-buildpackage: source version 2.0.8
    dpkg-buildpackage: source distribution unstable
    dpkg-buildpackage: source changed by Martin Koegler
    dpkg-buildpackage: host architecture armhf
    dpkg-source –before-build pthsem-2.0.8
    dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7) cdbs
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)

    Bei Knxd war das Problem an gleicher Stelle:

    pi@raspberrypi:~ $ cd knxd
    pi@raspberrypi:~/knxd $ dpkg-buildpackage -b -uc
    dpkg-buildpackage: source package knxd
    dpkg-buildpackage: source version 0.10.10-1
    dpkg-buildpackage: source distribution unstable
    dpkg-buildpackage: source changed by Matthias Urlichs
    dpkg-buildpackage: host architecture armhf
    dpkg-source –before-build knxd
    dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7.0.0) autotools-dev autoconf automake libtool libpthsem-dev libpthsem20 libusb-1.0-0-dev (>= 1.0.10) libsystemd-daemon-dev (>= 200) | base-files (<< 8) dh-systemd | base-files (<< 8)
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)

    Das passiert aber nur unter Jessie. Bei Wheezy läuft die Installation problemlos durch. Was muss man hier anders machen?

    Gruß Gerhard

    1. > dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 7) cdbs

      Was du dagegen tun musst, steht in der Anleitung, nämlich:

      apt-get install debhelper cdbs

  32. Hallo Matthias,
    Danke für die Info. Der erste Teil mit pthsem_2.0.8.tar ist nun problemlos durchgelaufen. Bei KNXD kam folgende Fehlermeldung:

    pi@raspberrypi:~/knxd $ dpkg-buildpackage -b -uc
    dpkg-buildpackage: source package knxd
    dpkg-buildpackage: source version 0.10.10-1
    dpkg-buildpackage: source distribution unstable
    dpkg-buildpackage: source changed by Matthias Urlichs
    dpkg-buildpackage: host architecture armhf
    dpkg-source –before-build knxd
    dpkg-checkbuilddeps: Unmet build dependencies: libsystemd-daemon-dev (>= 200) | base-files (<< 8) dh-systemd | base-files (<< 8)
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)

    Gleicher Befehl ist unter Wheezy durchgelaufen.
    Das sind halt Probleme, welche ein Anfänger hat!

    Gruß
    Gerhard

  33. Hallo Matthias,
    erst mal vielen Dank für Deine Antworten.
    Bin jetzt mit der Installation durch, habe aber leider noch keine Funktion.
    Das Schreiben auf den Bus sieht zwar fehlerfrei aus, aber es geht nichts raus.
    pi@raspberrypi:~ $ knxtool groupswrite ip: 0/4/12 1
    Send request
    -keine Reaktion auf dem Bus
    Dann habe ich mal grouplisten probiert und sogar was vom Bus gelesen:
    pi@raspberrypi:~ $ knxtool grouplisten ip: 0/4/12
    Write from 1.2.216: 01
    Write from 1.2.216: 00
    Write from 1.2.216: 01
    Write from 1.2.216: 00

    In Fhem werden keine Busteilnehmer eingelesen. Nur die Aktionen welche ich beim Testen ausgelöst habe werden in der fhem.cfg angezeigt

    pi@raspberrypi:~ $ /etc/init.d/knxd status
    ● knxd.service – KNX Daemon
    Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
    Active: active (running) since Tue 2015-12-22 20:17:04 CET; 16min ago
    Main PID: 465 (knxd)
    CGroup: /system.slice/knxd.service
    └─465 /usr/bin/knxd -u /tmp/eib -b ip:

    beim Versuch den knxd zu stoppen kommt folgendes:

    pi@raspberrypi:~ $ /etc/init.d/knxd stop
    [….] Stopping knxd (via systemctl): knxd.serviceFailed to stop knxd.service: Access denied
    Warning: Stopping knxd.service, but it can still be activated by:
    knxd.socket
    failed!

    Keine Ahnung wie ich weiter machen soll…

    Gruß
    Gerhard

  34. Hallo Matthias,
    ich habe gerade noch festgestellt, daß nach dem Neustart keine Bus-Kommunikation stattfindet. Auch nicht das was vorher noch ging s.o.
    Nach Neustart steht eine Betriebszeit von 1h und 11min des knxd

    pi@raspberrypi:~ $ /etc/init.d/knxd status
    ● knxd.service – KNX Daemon
    Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
    Active: active (running) since Tue 2015-12-22 22:17:04 CET; 1h 11min ago
    Main PID: 455 (knxd)
    CGroup: /system.slice/knxd.service
    └─455 /usr/bin/knxd -u /tmp/eib -b ip:

    bin schon am verzweifeln!

    Gruß
    Gehard

    1. > /usr/bin/knxd -u /tmp/eib -b ip:

      Hast du überhaupt einen multicast-fähigen KNX-Gateway in deinem Netz? Du hast die Frage, wie deine sonstige Infrastruktur aussieht, bisher kreativ überlesen. 😛

  35. vor dem Neustart war eine Laufzeit von 10min angezeigt. Direkt nach dem Start (Spannung weggenommen) stand die Zeit auf 1h 11min und dann auch kein lesen vom Bus mehr, was vorher noch ging!

  36. mein Gateway zum KNX ist ein Siemens N148/22 – sollte denke ich, gehen!
    der raspi ist ein 2 B mit installiertem Jessie
    Mit Wheezy hat die Komunikation ja auch schon mal funktioniert. Allerdings auch nur direkt nach der Installation – da auch nach einem Neustart das KNXD nicht mehr gestartet werden konnte. Deshalb habe ich es jetzt nochmal mit Jessie probiert.

  37. Hallo frohe Weihnachten euch allen
    ich hätte wieder ein mal ein paar Fragen
    ich habe in meinem Haus S0 Sensoren an Gas/Wasser/ Strom angeschlossen und alles über KNX am laufen der
    Gaszähler hat 1 Impuls pro 0,001m³
    Wasserzähler hat 1 Impuls pro Litter
    Stromzähler hat 1 Impuls pro 1W

    jetzt zur meiner Frage
    kann mir jemand helfen einen Verbrauchszähler für Tag /Monat/Jahr zu erstellen ich würde gerne

    ich würde gerne in einem SVG Plot erstellen wo zwei vergleiche dieser Monat und letzter Monat dargestellt werden

    und zur meiner zweiten frage da die Sensoren sehr fein eingestellt sind senden sie sehr viele Daten an fhem alle par Sekunden ein an aus wie soll ish sie besser parametrieren als Schaltsensor oder Impulszähler

  38. Danke erstmal für die super Anleitung. Ich bin da gerade komplett durchgegangen, habe ein MDT Ip Interface und will das per Lan an an den Raspi hängen. Installation läuft gut durch. Jedoch wenn ich EIDB mit

    eibd -t 1023 -S -D -R -T -i –no-tunnel-client-queuing ipt:192.168.1.10

    starte, kommt folgender Auszug:

    root@raspberrypi:~# eibd -t 1023 -S -D -R -T -i –no-tunnel-client-queuing ipt:192.168.1.10
    Layer 7(00000000,56BDC496) EIBD should not run as root
    W00000001: EIBD should not run as root
    Layer 2(01BCB988,56BDC496) Open
    Layer 0(01BCBE50,56BDC496) Open
    Layer 0(01BCBE50,56BDC496) Close
    initialisation of the backend failed
    root@raspberrypi:~#

    Hatte jemand was ähnliches, wo ist der Fehler, und vor allem wie kann ich es lösen? Danke vorab 😉

    1. (a) eibd ist Steinzeit, du willst knxd. (Achtung: Flag-Reihenfolge ist wichtig, neu: -DRTS statt -SDRT).
      (b) wenn das nicht hilft: strace ist dein Freund.

    2. http://github.com/knxd/knxd

      Der Unterschied? systemd-Dateien für Jessie, diverse Bugs behoben, ein bisschen modernisiert und umgebaut, mehrere Backends gleichzeitig, ein Haufen Fehlermeldungen ergänzt; die Testversion kann außerdem dynamisch KNX-Adressen vergeben und Antworten zustellen ohne sie an alle angeschlossenen Busse zu blasen.

    3. Hallo Matthias,

      dein Tip war Gold wert. Jetzt läuft das Teil wieder, wenngleich ich noch ein paar Fehlermeldungen in FHEM erhalte, das bügle ich aber auch noch hin.

      Was habe ich gemacht: Grundsätzlich habe ich mich an folgende Anleitung gehalten:

      http://www.fhemwiki.de/wiki/Knxd

      Beim Punkt 4a habe ich dann den Aufruf mit der geänderten Flag-Reihenfolge eingegeben, also:

      DAEMON_ARGS=”-u /tmp/eib -u /var/run/knx -D -R -T -S -i -b ipt:192.168.188.XX”

      Das wars. Einzig in Fhem wie bereits geschrieben wird versucht die Verbindung zweimal zu öffnen, warum auch immer. Den Fehler muss ich noch suchen wenn mal etwas Zeit ist 😉

      Danke nochmals für den super Tipp!

  39. Hallo Matthias,

    weißt Du zufällig, ob das KNX-IP Interface von Jung mit KNXD läuft bzw. wie es parametrisiert wird?

    Vielen Dank vorab.

    VG Marcel

    1. Ich wüsste nicht, warum es nicht laufen sollte. Wenn du mir sagst, wo ich die ETS-Datei für das Ding herbekomme, kann ich mal draufschauen, wie es wahrscheinlich eingestellt gehört, um mit knxd zu reden.

  40. Hallo Matthias,

    vielen Dank schonmal vorab. Die ETS-Datei gibt es direkt auf der Herstellerseite bei Jung:
    http://www.jung.de/de/online-katalog/71966800/

    Bei der Schaltfläche Info auf den Pfeil klicken, dann kann man die ETS Dateien und die Handbücher downloaden.

    Beste Grüße
    Marcel

  41. Hallo Matthias,

    ich hab hier auch ein kleines Problem. Ich probiere schon sein ein paar Tagen die 6 Richtigen zu finden. Ich habe Jessie auf dem Raspberry 2 laufen, KNXD installiert und es läuft generell auch. Ich kann Daten vom Bus empfangen (MDT IP Interface) aber ich kann nichts senden. Jedesmal wenn ich den Parameter -i irgendwo rein stecke kommt der Fehler das der Socket bereits belegt sei, wobei ich schon in einem anderen Forum gelesen habe das sei normal und man möge das -i einfach weglassen. Funken tut es leider nur in eine Richtung. Mein Aufruf:

    knxd -t1023 -f9 -D -R -T -S –no-tunnel-client-queuing ipt:192.168.1.10

    Beste Grüße
    Sandra

    1. Du sollst den -i-Parameter genau dann weglassen, wenn du den knxd von systemd starten lässt (was du tun solltest). Der hat nämlich den Socket offen und reicht ihn an “seinen” knx weiter.

      D.h.:
      * /etc/knx.conf editieren
      * systemd daemon-reload
      * systemd start knxd.socket
      * systemd restart knx.service

      und schon tut das. Willst du ihn per Hand starten, zum Rumspielen, machst du umgekehrt

      * systemd stop knxd.socket
      * systemd stop knxd.service

      (dieselbe Reihenfolge. Das ist Absicht).

    2. Aber genau da liegt doch irgendwo der Hund begraben und ich finde es nicht. Den i-Parameter habe ich eh draußen, sonst geht ja eh nichts. Was am Bus läuft bekomme ich ja auch schon mit, nur senden kann ich nicht.

      Nachdem ich folgendes zusätzlich in die /ets/knxd.conf eingetragen habe (/etc/knx.conf gibt es nicht):

      * systemctl daemon-reload
      * systemd start knxd.socket
      * systemctl restart knxd.service

      (systemd gibts bei mir auch nicht, ich vermute du dachtest an systemctl?)

      ändert sich leider nichts an dem Verhalten. Empfangen ja, senden nein.

      Danke für die Tipps!
      Beste Grüße
      Sandra

  42. Kommando zurück: Ich konnte den Fehler eingrenzen: Von der Konsole geht auch das Senden. Nur Fhem kann nicht senden (aber empfangen). Sprich der Fehler liegt vermutlich in der Config dort.

    1. Fein. Dann muss ich jetzt auch nicht herausfinden, wieso dieses Blog darauf besteht, meine (ausführliche) Antwort mit INVALID DATA ERROR ablehnen zu wollen. :-/

    2. @Jörg: War anscheinend ein Cookie-Problem. Die Fehlermeldung ist an der Stelle grob irreführend.

  43. Hallo,
    hab knxd zum laufen gebracht. Will das Interface von MDT nutzen.

    Leider kann ich weder was auf dem Bus mithören noch senden.

    Wie muss die Config aussehen?

    Gruß
    Nils

  44. Hi Jörg,

    auch hier wieder Respekt!
    Tolle Anleitung….

    Eine Bitte: das Copy+Paste der “&&” Verknüpfungen funktioniert nicht immer, Laien erkennen das nicht und achten nicht auf evtl. aufkommende Fehler.
    Bitte ein Befehl pro Zeile – dann müsste es bei jedem klappen.

    Eine Frage:
    Nach Deiner Anleitung haben wir es geschafft den raspi per LAN an ein Weinzierl Interface IP 730 zu bekommen.
    Das was da gelausccht wird ist interessant, nur die Aktoren wollen uns nicht kennen – lediglich das Ansprechen über Sensoradressen funktioniert bestens….
    Rolläden fahren runter und rauf, das Garagentor bewegt sich 😉
    Aber, ich bekomme es nicht hin, eibd als Daemon (Systemdienst) zu starten.
    Es bleibt lediglich der manuelle Start im Vordergrund, wie auch aus der rc.local heraus. Dann bekommt man schön alles am Bildschirm angezeigt, jedoch die Haupt-Konsole ist somit nicht mehr zu verwenden.

    Wer hat das wie als Deamon funktionierend zum Laufen gebracht?

    Danke & Gruß,

    Jimly

    1. Hi Jimly,
      was genau ist das Problem mit dem “&&”? Würde die Befehle ungerne aufsplitten, da es sind recht viele einzelne Kommandos werden. Evtl. kann ich ja einen Hinweis im Blogpost zum genauen Problem schreiben!?

  45. Hi Jörg,

    ich habe selbst festgestellt und auch bei meinem Spezi beobachtet (Windows-Bediener):
    Kopiert man den Inhalt der Befehlsboxen und fügt diese Befehle dann unter Putty oder Kitty auf dem RasPI ein, so werden oft verkettete Befehle falsch ausgeführt, da vermutlich das && nicht gleich das && ist!
    Trennt man diese Befehlskette in einzelne Befehle, so funktioniert alles problemlos bei der Installation, ohne Fehler!
    Warum das so ist – weiss ich nicht, bin selbst unter Linux ein Newbie.

  46. Hallo

    ich hab ein problem mit meiner knx und fhem steuerung und zwar habe ich von merten das ip-gateway (Merten MEG6500-0113)das zum programiern von meinen Aktoren und sensoren wunderbar geklappt hat, die Fhem anbindung über eibd und das gateway funktioniert auch wunderbar, nur sobald ich das gateway an mein knx anschliese funktionieren meine schaltsensoren nicht mehr ordentlich. Sobald ich ich das gateway vom netz nehme gaht alles wieder einwandfrei.

    hat jemand ne idee oder einen ämlichen fehler???

    1. Das klingt sehr nach einem Zyklus im Bus. Wahrscheinlich multicasten zwei Geräte, die sich auch anderweitig erreichen können.

      Das sollte man UNBEDINGT vermeiden. Ich würde das IP-Netz immer als “Buskabel” betrachten und direkte Unterhaltungen zwischen IP-Geräten vermeiden, wenn irgend möglich.

      Erschwerend kommt hinzu, dass der eibd bescheuert programmiert war: Buspakete haben einen Zähler, wenn der auf Null steht wird das Paket weggeschmissen statt weitergeleitet. Außer der Zähler steht auf Maximum, dann wird er (laut KNX-Spezifikation — meiner Meinung nach grober Unfug) nicht heruntergezählt. Dreimal darfst du raten, auf was der eibd diesen Zähler stellt …

      Der aktuelle knxd ignoriert den “bei Maximalwert nicht runterzählen”-Teil dieser Idee und versendet seine Pakete regelkonform (eins weniger als das Maximum), so dass ein Zyklus zwar noch störend ist, dir aber den Bus nicht kaputtmacht.

  47. Hallo Matthias,

    Viellen dank für schnell Antwort und sorry wenn ich blöde fragen stelle bin aber in der sache noch blutiger Anfänger. Muss aber wirklichen sagen das mir eure seite echt gut gefällt und mir in machen dingen auch schon sehr weitergeholfen hat.

    Wenn ich dich richtig verstanden habe meinst du ich hab eine Ringleitung, so das sich das IP-Netz (Verbindung aller Geräte mit dem Buskabel) in beide Richtungen (über zwei leitungen)unterhalten können.

    Ich bekomme leider des Knxd auf meinem Ubuntu server nicht zum laufen.
    hab mich strickt an die vorgeben von http://www.fhemwiki.de/wiki/Knxd gehalten aber immer bei dpkg-buildpackage -b -uc kommt der fehler:

    dpkg-checkbuilddeps: Nicht erfüllte Bauabhängigkeiten: pkg-config
    dpkg-buildpackage: Warnung: Bauabhängigkeiten/-konflikte nicht erfüllt; Abbruch
    dpkg-buildpackage: Warnung: (Verwenden Sie -d, um sich darüber hinwegzusetzen.)

    setz ich dann das -d dahinter kommt dieser Fehler:

    configure: exit 2
    dh_auto_configure: ./configure –build=i686-linux-gnu –prefix=/usr –includedir=${prefix}/include –mandir=${prefix}/share/man –infodir=${prefix}/share/info –sysconfdir=/etc –localstatedir=/var –libexecdir=${prefix}/lib/knxd –disable-maintainer-mode –disable-dependency-tracking –enable-usb –enable-eibnetip –enable-eibnetiptunnel –enable-eibnetipserver –enable-groupcache –enable-ft12 –enable-pei16s –enable-ncn5120 –enable-tpuarts –enable-dummy returned exit code 2
    make[1]: *** [override_dh_auto_configure] Fehler 25
    make[1]: Verzeichnis »/home/breit/knxd« wird verlassen
    make: *** [build] Fehler 2
    dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2

    und jetzt gehen mir so langsam die Ideen aus.

    1. >> dpkg-checkbuilddeps: Nicht erfüllte Bauabhängigkeiten: pkg-config

      Äh, dann installier halt pkg-config ?!?

      Im Übrigen löst du mit dem Ersetzen des eibd durch den knxd dein Problem nicht — du hast immer noch irgendwo einen Zyklus in deiner Busstruktur.

    2. Hallo Matthias,

      kannst du mir des mit dem Zyklus im Bussystem nochmal näher beschreiben??
      Ich komm nicht drauf was du damit meinst.

      Ich hab meine komplette Verkabelung nochmal gecheckt, hab ne baumstrucktur mir keinem ring irgendwo.

    3. Es reicht, wenn du gleichzeitig mit einem KNX/IP-Gateway direkt (ipt:) und mit Multicast (-S oder ip:) redest und der Gateway auch multicast kann. Dann hast du zwei IP-Verbindungen zu diesem Adapter, einmal direkt und einmal via Multicast. Schon hast du verloren.

      Sieh deinem Netzwerk einfach mal auf die Finger währenddessen; Wireshark ist dein Freund. (Auf demselben Rechner laufen lassen wie der knxd, sonst siehst du die direkten Pakete zum Gateway nicht.)

  48. Habt ihr eine Idee, wie ich 3 unabhängige KNX Gateways mit eibd ansprechen kann.
    Eines ist ja kein Problem (aus /etc/rc.local auf dem Raspberry):
    /usr/local/bin/eibd -S -D -R -T -i6300 –no-tunnel-client-queuing ipt:192.168.178.78 &

    entweder mit -i oder mit -i[port] funktioniert es in Ankopplung in FHEM (define KNX TUL eibd:192.168.178.68:6300 1.1.250).
    Wie könnte ich 3 eibd starten, die auf unterschiedlichen Ports lesen/schreiben

    Danke für gute Ideen…

    1. Nimm den knxd und verpasse ihm alle drei Schnittstellen, im Gegensatz zum eibd kann der das.

      Wenn das drei separate KNX-Netze sein müssen, wegen überlappender Adressen: wozu brauchst du in deiner Situation überhaupt Multicast? wahrscheinlich gar nicht. Lass das -SDRT weg und fertig.

  49. Erstmal danke für die Hilfe.
    So, habe die eibd Einträge rausgenommen, nach Anleitung den KNXD installiert und konfiguriert in der /etc/default/knxd : (DAEMON_ARGS=”-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.178.77″)
    knxd startet nach reboot und wird in FHEM korrekt eingebunden, zugriff auf Sensoren funktioniert. Bis dahin wars einfach 🙂
    Aber wie mache ich das nun mit 3 Gateways mit drei unterschiedlichen IP Adressen?

    1. Wo liegt das Problem? Du hast drei Gateways, du schreibst drei “-b ipt:BLA”-Einträge in die Konfiguration (einer pro Gateway), fertig.

      Disclaimer: Das geht natürlich nur wenn du keine überlappenden Adressen auf diesen drei Bussen hast.
      Wenn du tatsächlich drei 100% getrennte KNX-Busse brauchst, dann musst du die Datei zweimal kopieren, meinetwegen nach knxd1 und knxd2, und darin natürlich den Port und die Pfade zu den Sockets anpassen. Dasselbe machst du mit den Startdateien in /etc/rc.d, die musst du dann noch anpassen und mit “update-rc.d” aktivieren.
      Unter Jessie mit systemd ist es ein bisschen einfacher, da kann man /lib/systemd/system/knxd.service nach /etc/systemd/system/knxd1 bzw. knxd2 .socket+.service kopieren und entsprechend ändern.

      Ehrlich gesagt: wenn du überlappende Adressen hast, dann sag deinem Elektriker oder wer auch immer das fabriziert hat, er soll das reparieren. Sowas gehört sich nicht. Und saubere Adressierung macht das Leben um Einiges einfacher.

      Oder du ergänzst knxd um Adressübersetzung. Leider ist das ein bisschen mehr Aufwand …

  50. Nee, die 3 Busse sind räumlich getrennt und deshalb mit 3 Interfaces (daher die drei IP Adressen. Die schaen aber alle, ebenso wie der Rasppi und andere Geräte in ein Klasse c Teilnetz) versehen. Die KNX Adressen überlagern sich nicht, im ersten Raum habe ich die 1.1.xxx, im zweiten die 1.2.xxx und im dritten die 1.3.xxx

    Danke für die Info, in Sachen eibd bzw. knxd bin ich “noch” ein Dummy. Da dachte ich mir, ich frage mal jemand, der sich damit auskennt.

    1. Alles klar, kein Thema, dann schreib da drei -b-Einträge rein und du bist fertig.

      Letztes Jahr um die Zeit hätte das noch nicht funktioniert. 😉

  51. Hi Matthias,

    habe die /etc/default/knxd erweitert in
    DAEMON_ARGS=”-u /tmp/eib -u /var/run/knx -i -b ipt:192.168.178.77 -b ipt:192.168.178.211 -b ipt:192.168.178.212″

    bei einem stop und start des knxd bekomme ich aber nun folgendes:

    pi@raspi2 ~ $ sudo /etc/init.d/knxd stop
    pi@raspi2 ~ $ sudo /etc/init.d/knxd start
    E00000038: cannot bind to address: Address already in use
    initialisation of backend ‘ipt:192.168.178.211’ failed: Address already in use
    pi@raspi2 ~ $

    Was habe ich falsch gemacht ???

    1. Nix. Das ist ein Bug, der die rote Fahne schwenkt wenn man mehr als ein ipt: hat. Workaround: -b ipt:ROUTER_A:3671:3672 -b ipt:ROUTER_B:3671:3673 -b ipt:ROUTER_C:3671:3674

  52. Hallo,
    Kann ich damit auch Loxone über den KNX IP-Gateway steuern ?
    Wenn ich die EIB Bausteine verwende und keine KNX Verkabelung habe?
    Mit freundlichen Grüßen Sebastian

  53. Hallo Matthias,

    danke für den Workaround. Ok, knxd lässt sich nun ohne diese Fehlermeldung starten.
    Passt.
    Aber wie differenziere ich nun in der fhem.cfg die verschienenen Gatways?
    Wäre folgendes korrekt?

    # KNX
    #define KNX TUL eibd:localhost 1.1.250
    define KNX TUL knxd:192.168.178.68 1.1.250
    define KNXx TUL knxd:192.168.178.211 1.2.250
    define KNXy TUL knxd:192.168.178.212 1.3.250

    1. Gar nicht. Sobald du mit dem knxd alles zusammenhängst, hast du eine KNX-Installation, nicht drei. “eibd:localhost” passt folglich immer noch.

      Ja, das heißt dass sämtliche Nachrichten an Gruppenadressen jetzt an alle Busse gehen. Im Normalfall ist das keinerlei Problem. Dem knxd beizubringen, welche Nachrichten wo hin sollen, wäre eine gute Idee und von der Programmierung her auch keine große Sache, es muss halt nur jemand tatsächlich einbauen …

  54. Ok,

    verstehe ich das korrekt, dass in der fhem.cfg nur noch folgendes stehen muss:

    # KNX
    define KNX TUL eibd:localhost

    Und die Kommunikation auf dem KNX Bus geht an alle Gatways, aber aufgrund der unterschiedlichen Linien passt die Kommunikation dann nur auf Linie 11.x, 1.2.x oder 1.3.x

    1. Genau. Wenn die Gatways Nachrichten, die nicht für “ihre” Linien gedacht sind, rausfiltern, dann ist das gut, ansonsten sollten der zusätzliche Traffic nicht weiter stören.
      Adressfilter im knxd gibt’s irgendwann dieses Jahr …

  55. Hallo Matthias,

    sorry, muss nochmal nachhaken.
    habe in der fhem.cfg nun folgende zeile drin: “define KNX TUL eibd:localhost”

    Das Logfile von FHEM zeigt nach einem neustart aber nun folgendes:
    “2016.03.21 12:57:10 1: configfile: wrong syntax: define TUL []”

    Ist doch eigentlich nichts falsch, oder? “line def in hex” sollte doch optional sein????

    Hast du eine gute Idee, was falsch sein könnte ?

    1. Sorry, mit knxd:localhost gehts auch nicht, vor allem das knxd: mag fhem gar nicht
      2016.03.21 14:37:32 3: TUL opening KNX device knxd:localhost
      2016.03.21 14:37:32 1: knxd:localhost protocol is not supported

  56. Hallo
    Ich hätte eine Frage
    Auf meinem fhem System passieren komische Sachen hatte vor längerer Zeit meine EIB Geräte angelegt,
    jetzt habe ich ein fhem update gemacht und jetzt werden mir zusätzlich knx Geräte erzeugt wie kommt das wie kann ich das abstellen sonnst ist alles doppelt und wieder alle Geräte ungepflegt

  57. guten Abend euch allen,

    ich wollte heute mein EIBD gegen das neue KNXD Updaten aber nach der Installation geht knxd und wenn ich dann Restart oder Start eingeben kommt diese Fehler Meldung.

    breit@HomeServer:~$ /etc/init.d/knxd start
    [….] Starting knxd (via systemctl): knxd.serviceJob for knxd.service failed because a configured resource limit was exceeded. See “systemctl status knxd.service” and “journalctl -xe” for details.
    failed!

    1. “See “systemctl status knxd.service” for details bedeutet, dass du genau diesen Befehle ausführen sollst und uns dann mitteilen darfst, was er dir zu diesem Problem sagt.

      Das ist eigentlich selbsterklärend.

    2. Danke für die Schnelle Hilfe.

      Dann kommt das hier.

      breit@HomeServer:~$ systemctl status knxd.service
      ● knxd.service – KNX Daemon
      Loaded: loaded (/lib/systemd/system/knxd.service; disabled; vendor preset: en
      Active: activating (auto-restart) (Result: resources) since Fr 2016-07-15 09:

      Jul 15 09:08:09 HomeServer systemd[1]: Stopped KNX Daemon.
      Jul 15 09:08:09 HomeServer systemd[1]: knxd.service: Failed to load environment
      Jul 15 09:08:09 HomeServer systemd[1]: knxd.service: Failed to run ‘start’ task:
      Jul 15 09:08:09 HomeServer systemd[1]: Failed to start KNX Daemon.
      Jul 15 09:08:09 HomeServer systemd[1]: knxd.service: Unit entered failed state.
      Jul 15 09:08:09 HomeServer systemd[1]: knxd.service: Failed with result ‘resourc
      lines 1-10/10 (END)

  58. Hallo ich möchte meinen Flur mit einer warm weißen LED indirekt beleuchten (ca. 20 Meter). Mein Elektriker empfiehlt mir ein Netzteil Mean Well PWM-120-24. Dazu ein Casambi CBU-ASD Modul. Davon habe ich vorher noch nichts gehört. Ich selber habe FHEM, HUE, Homematic. Wie kann ich das bei mir einbinden, zum ein-und ausschalten und vor allem zum dimmen? Der Elektriker meint mit den Homematic Modulen kann ich das Netzteil nicht steuern.

  59. Also als erstes muss ich hier mal ein richtig dolles LOB aussprechen. Diese Anleitung die hier vorhanden ist und die die zum einrichten des PI gewesen war, sind absolute klasse.
    Das sich allerdings einiges getan hat und scheinbar ein Zugrift nicht mehr per EIBD odern KNXD laufen soll, habe ich als absoluter Neuling in Bereich PI, dass Problem, dass ich ab der Zeile der zu installierenden Komponenten:

    wget -O /tmp/bcusdk_0.0.5.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/eib/bcusdk_0.0.5.tar.gz && tar -xvf bcusdk_0.0.5.tar.gz && wget -O /tmp/pthsem_2.0.8.tar.gz http://www.auto.tuwien.ac.at/~mkoegler/pth/pthsem_2.0.8.tar.gz && tar -xvf pthsem_2.0.8.tar.gz

    so meine Problemchen …..

    Kann mir jemand weiterhelfen wie ich nun die Anbindung über eine IP Router vornehmen kann und was ich wie installieren muss ?

    Wäre Super wenn die aktuelle Anleitung auf den neuen Stand gebracht würde.
    Danke vielmals an dieser Stelle.

    1. Steht alles im README vom knxd … pthsem wird inzwischen nicht mehr benötigt.

      https://github.com/knxd/knxd/tree/stable

      Es wäre nett, wenn die Anleitung darauf verweisen würde, statt veraltete Infos zu verbreiten. Danke.

  60. Hallo allseits,

    ich kämpfe seit vergangenem Wochenende mit folgendem Problem.

    Auf dem Raspi2 läuft das aktuelle Jessie. Nach Anleitung das knxd Modul installiert (besten Dank dafür 🙂 )

    Läuft:
    pi@raspberrypi:~ $ /etc/init.d/knxd status
    ● knxd.service – KNX Daemon
    Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
    Active: active (running) since So 2017-02-05 12:32:19 CET; 59s ago
    Main PID: 1002 (knxd)
    CGroup: /system.slice/knxd.service
    └─1002 /usr/bin/knxd -e 0.0.1 -b ipt:192.1xx.xxx.xx ==> IPAdresse von IP_Schnittestelle

    im Fhem mit define ein Device angelegt

    Läuft, aber ist nur initialisiert… ?

    KNX

    Initialized
    Internals
    AckLineDef

    Clients

    :KNX:EIB:
    DEF
    EIBD:192.168.XXX.XXX 0.0.1 ==> Localhost vom Raspi2
    DeviceAddress

    0001
    DeviceName

    EIBD:192.168.XXX.XXX
    NAME

    KNX
    NR

    2
    PARTIAL

    STATE

    Initialized
    TYPE

    TUL

    Im Logfile im Fhem steht:
    13:07:39 0: Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
    please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
    As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.
    2017.02.05 13:07:39 3: TUL opening KNX device EIBD:192.168.178.56
    2017.02.05 13:07:39 1: EIBD:192.168.XXX.XXX protocol is not supported
    2017.02.05 13:07:39 3: TUL device opened

    ==> Ist die Schnittstelle jetzt offen und sollte befehle annehmen, oder geht es auf Grund des falschen Protokolles nicht ??

    Wie bekomme ich das richtige Protokoll geladen? Fhem ist geupdatet.

    Woher bekomme ich die EIBADRESSE die vermutlich nicht 0.0.1 (standart) ist.
    Verwendet wird eine BUSCH&Jäger 6186/32 IP-Schnittstelle, die an einem Router angeschlossen ist.

    habe verschiedene Foren durchlesen, aber jetzt komme ich nicht mehr weiter.

    Danke für eure Hilfe/ Supoort !!

    Grüße

    Axel

  61. Hallo allerseits,

    ich hab knxd gemäß der Anleitung knxd auf einem Rasp2 installiert.

    sieht soweit auch gut aus.
    pi@raspberrypi:~ $ /etc/init.d/knxd status
    ● knxd.service – KNX Daemon
    Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
    Active: active (running) since So 2017-02-05 16:37:12 CET; 54s ago
    Main PID: 1029 (knxd)
    CGroup: /system.slice/knxd.service
    └─1029 /usr/bin/knxd -e 1.0.1 -b ipt:192.168.XXX.XXX

    Ich bekomme aber beim absetzten eines groupswrite Befehls
    knxtool groupswrite local: 2/1/20 1

    die Fehlermeldung
    Connect failed: Connection reset by peer

    im Fhem habe ich im FileLog folgende Meldung:

    Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
    please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
    As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.
    2017.02.05 16:50:31 3: TUL opening KNX device EIBD:192.168.178.56
    2017.02.05 16:50:31 1: EIBD:192.168.178.56 protocol is not supported

    Während das Device Initialized ist.

    Kann mir jemand weiterhelfen, Div. Fopren github, fhem etc. schon durchforstet.

    Danke

    1. Hi Stephan, der TUL-Stick ist oben im Text direkt verlinkt. Hier aber nochmal für dich: http://shop.busware.de/product_info.php/cPath/1/products_id/59

      Grüße
      Jörg

Schreibe einen Kommentar zu Jimly Antworten abbrechen

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

Das könnte dir auch gefallen