Ankündigung

**udo1toni** · 12.03.2017, 16:50

Zum 1. Problem: Wie kommst Du auf den knx-Bus? serielle Schnittstelle, USB, oder IP-Interface? jede der drei Varianten kommt ohne knxd (bzw. ehemals eibd) aus. es kann natürlich trotzdem gute Gründe für den Einsatz von knxd geben.
In der Datei /etc/default/knx richtest Du ein, mit welchen Optionen der Dienst knxd starten soll. Ob die Parameter in Ordnung sind, kann ich Dir nicht sagen, weil ich ja keine Ahnung habe, welche Schnittstelle Du einsetzt.
Wenn die Werte soweit richtig sind, musst Du mit

Code:

sudo systemctl start knxd.service

knxd starten, oder, falls der Dienst schon gestartet war, die Konfiguration neu einlesen lassen, im Zweifel mit dem Kommando restart statt start.

Aber bitte nur, wenn Du knxd auch wirklich brauchst!!!

2. Problem
Nein, wenn Du das knx Binding über Paper UI installiert hast, wurde die Datei schon von openHAB erzeugt, und zwar im Verzeichnis /etc/openhab2/services/, am besten editierst Du die schon vorhandene Datei, statt selbst eine anzulegen, damit vermeidest Du Tippfehler (z.B. localip statt localIp).

Wenn Du eine eibnet/ip-Schnittstelle verwendest , ist ip die Adresse der eibnet/ip-Schnittstelle, localIp ist die Adresse des Rechners, auf dem openHAB läuft. Zusätzlich zu ignorelocalevents=true musst Du noch eine gültige busaddr setzen (also die, die von der ip-Schnittstelle verwendet wird, um Nachrichten von openHAB auf den Bus zu schicken). In der knx.cfg findest Du noch alle anderen Parameter, die man setzen kann, jeweils mit einer Erläuterung, wozu der Parameter gut ist. Kommentare werden mit einem # eingeleitet, dementsprechend muss das # entfernt werden, wenn Du einen Parameter auch wirklich setzen willst.

Wenn Du soweit bist, kannst Du im Log nachschauen, ob die Schnittstelle schon läuft (nicht über Paper UI, da 1.x-Binding), entweder über die karaf Konsole oder direkt in openhab.log (im Verzeichnis /var/log/openhab2/)

Da es sich bei knx um ein 1.x Binding handelt, läuft die Konfiguration exakt wie bei openHAB1 ab, also über *.items Dateien (die erzeugst Du in /etc/openhab2/items/).
Ein Item steht dabei für eine bestimmte Funktion, also z.B. ein Lichtschalter. In der knx Welt gibt es mindestens eine GA, auf die der Aktor reagiert. Eventuell gibt es noch eine Rückmeldung über den Schaltzustand, oder auch weitere GA, weil ein Aktor auch auf mehrere GA reagieren kann. So ein Item sieht dann so aus:

Code:

Switch MySwitch "Mein Licht ist [%s]" <light> {knx="1/1/0+1/1/2+<1/1/1"}

Diese Zeile erzeugt ein Item MySwitch, welches beim Start von openHAB auf der GA 1/1/1 den Zustand des Aktors abfragt (das <-Symbol). Wenn das Item z.B. über die UI geschaltet wird, sendet es ausschließlich über die GA 1/1/0 den Schaltbefehl 1 oder 0 (innerhalb openHAB sind das die Status ON und OFF). Falls openHAB auf den GA 1/1/0, 1/1/1 oder 1/1/2 ein Telegramm empfängt, ändert es den Zustand des Items entsprechend.
Welche Items möglich sind und wie man sie korrekt konfiguriert, kannst Du unter https://github.com/openhab/openhab1-...ki/KNX-Binding nachlesen.
Wenn Du diese per Datei angelegten Items zu sehen bekommen möchtest, musst Du außerdem noch eine Sitemap anlegen und in einer der UIs (nicht Paper UI) aufrufen.
In obigem Fall wäre die Zeile

Code:

Switch item=MyItem

ausreichend, um eine entsprechende Zeile in Basic UI oder Classic UI zu erzeugen - allerdings fehlt dann noch das Gerüst drumherum, wie eine Sitemap aussieht findest Du unter https://github.com/openhab/openhab1-...on-of-Sitemaps

Aufgerufen wird diese Sitemap dann, indem Du z.B. die Basic UI öffnest. http://ip.des.Raspberry.pi:8080/basi...emap=mysitemap öffnet die
Sitemap /etc/openhab2/sitemaps/mysitemap.sitemap

**Chriko** · 12.03.2017, 17:30

Wow, erstmal vielen Dank für deine ausführliche Antwort.
Ich nutze eine IP Schnittstelle (Siemens N148/22). Ich bin einfach davon ausgegangen, dass die Visualisierung, wie auch nachher die Einbindung von Alexa, bzw. die Steuerung durch Alexa, knxd voraussetzen. Liege ich damit falsch?
Ich habe das openhabian image genutzt und darüber auch direkt in der config knxd installiert. Muss der knxd dann dennoch als Service gestartet werden oder ist das in dem Image nicht schon integriert? Jedenfalls,wenn ich knxd manuell starte und danach mit Groupswrite versuche das ganze zu testen, kommt "Open failed: Connection refused"

Ansonsten ist das genau das was ich gesucht habe. Vielen Dank für deine Mühe. Werde das jetzt mal alles testen. Du bist mein Held

**udo1toni** · 12.03.2017, 17:38

openHAB ist nicht auf knxd angewiesen, wenn Du cometvisu über openHAB ansteuerst, brauchst Du dazu ebenfalls kein knxd

**Chriko** · 12.03.2017, 18:34

Danke dir vielmals. Funktioniert endlich alles soweit. Abgesehen von der Alexa Anbindung. Da werden im Moment noch keine Devices gefunden. Aber mal schauen. Das werde ich wohl irgendwie schaffen

edit: und auch das funktioniert jetzt

Bin dir echt sehr dankbar.

**staehler** · 13.03.2017, 20:44

Zitat von udo1toni Beitrag anzeigen

openHAB ist nicht auf knxd angewiesen, wenn Du cometvisu über openHAB ansteuerst, brauchst Du dazu ebenfalls kein knxd

udo1toni Ich wusste gar nicht, dass OH selbst mit KNX kommunizieren kann, bisher hatte ich immer eibd laufen. Danke schon mal für den Tipp :-)
Jetzt habe ich das gleich mal ohne eibd probiert, also mit

Code:

#ip=
serialPort=/dev/ttyS0

/dev/ttyUSB0 gibt bei mir nicht.

Mit dem serialPort=/dev/ttyS0 bekomme ich von OH2 diese Fehlermeldung

Code:

2017-03-13 20:22:43.331 [ERROR] [nx.internal.connection.KNXConnection] - Error connecting to KNX bus: The serial FT1.2 KNX connection requires the RXTX libraries to be available, but they could not be found!
2017-03-13 20:22:43.331 [WARN ] [nx.internal.connection.KNXConnection] - Initial connection to KNX bus failed!

Weißt Du, was ich falsch mache? Wie komme ich an diese RXTX library?

Zunächst hing eibd an /dev/bus/usb/002/002. Nachdem ich das USB Kabel gezogen und in den gleichen Port gesteckt hatte, hing der neu gestartete eibd an /dev/bus/usb/002/003.
Wie finde ich heraus, welches Device openhab verwenden soll?

dmesg spuckt folgendes aus:

Code:

[426822.290424] hid-generic 0003:147B:5120.0005: hiddev0,hidraw0: USB HID v1.01 Device [ABB STOTZ-KONTAKT GmbH KNX-USB Interface (MDRC)] on usb-0000:00:1d.1-2/input0
[426822.684837] hid-generic 0003:147B:5120.0006: hiddev0,hidraw0: USB HID v1.01 Device [ABB STOTZ-KONTAKT GmbH KNX-USB Interface (MDRC)] on usb-0000:00:1d.1-2/input0
[426822.684933] bcuaddrtab[6240]: segfault at fffffffb3a93cb98 ip 000000000041f77c sp 000000000162f120 error 5 in bcuaddrtab[400000+2e000]
[427545.957550] usb 2-2: USB disconnect, device number 2
[427560.340623] usb 2-2: new full-speed USB device number 3 using uhci_hcd
[427560.527830] usb 2-2: New USB device found, idVendor=147b, idProduct=5120
[427560.527839] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[427560.527844] usb 2-2: Product: KNX-USB Interface (MDRC)
[427560.527848] usb 2-2: Manufacturer: ABB STOTZ-KONTAKT GmbH
[427560.537802] hid-generic 0003:147B:5120.0007: hiddev0,hidraw0: USB HID v1.01 Device [ABB STOTZ-KONTAKT GmbH KNX-USB Interface (MDRC)] on usb-0000:00:1d.1-2/input0

Danke schon mal und viele Grüße
Michael

**udo1toni** · 14.03.2017, 17:11

Oh, da fragst Du den Falschen, ich habe hier eine IP-Schnittstelle. Was die Numerierung der Ports betrifft, müsstest Du vermutlich eine udev-Regel erstellen, damit dein Device immer den selben Namen zugewiesen bekommt. Wie das genau funktioniert, kann ich Dir aber auch nicht verraten, ich hab das bisher nur einmal genutzt, und da habe ich irgendwo was kopiert und ohne Verstand angepasst...

Wenn Du bisher eibd verwendet hast, kannst Du ja auch ohne Probleme dabei bleiben, das hat auch den Vorteil, dass Du die Schnittstelle ohne Klimmzüge von ETS aus nutzen kannst (nicht vollkommen unabhängig von openHAB, aber meist parallel, und zur Not kann man openHAB mal kurz anhalten, falls z.B. die Programmierung eines Busteilnehmers nicht klappen will.

**staehler** · 15.03.2017, 08:53

udo1toni
Das kit den udev_Regeln habe ich mir eben angeschaut, das sollte ich hinkriegen ;-)

Das mit der ETS ist natürlich ein guter Grund bei eibd zu bleiben. Ein Grund auf das KNX Handling von OH zu gehen, wäre für mich eine hoffentlich bessere Verlässlichkeit. Wir hatten hier schon mal über dieses Thema diskutiert und so wie ich Dich verstehe, hast Du auch ab und zu diese Aussetzer (KNX Telegramme werden verschluckt).
Nachdem Du eine IP Schnittstelle im Einsatz hast, wirst Du vermutlich auch keinen eibd/knxd dazwischen haben, oder? Also liegen diese manchmal verschluckten KNX Telegramme bei Dir nicht am eibd sondern an was anderem.
Denkst Du trotzdem, das OH-KNX könnte eine Besserung bringen? Immerhin ist das in Weiterentwicklung, während eibd schon seit Jahren nicht mehr entwickelt wird. knxd ist leider (zumindest bei mir) noch sehr viel unzuverlässiger - komischerweise. Grundsätzlich funktioniert der zwar, aber diese Verschlucker sind noch viel öfter.

Ich würde mal behaupten, dass bei mir alle ein-zwei Tage irgendein Ding beim Einsatz von eibd nicht ein oder ausgeschaltet wurde. Das nervt schon ziemlich und ich möchte das loswerden oder zumindest reduzieren.

**udo1toni** · 15.03.2017, 14:01

Dass Telegramme nicht bei openHAB ankommen, habe ich glücklicherweise bisher nicht beobachten können, dass einzelne Telegramme nicht auf den Bus geschickt werden, tritt bei mir normalerweise nach 1 bis 2 Wochen Betriebszeit auf. Und es sind ausschließlich Rollläden betroffen, die als openHAB-Gruppen angesteuert werden (openHAB verschickt an jeden Aktorkanal ein eigenes Telegramm). Das sieht dann so aus, dass ab und zu ganz bestimmte Läden nicht mit fahren, es sind dann immer die selben Läden, z.B. immer der 2. Laden in der Küche, oder immer der 3. Laden im Wohnzimmer. Wenn das System zwischendurch neu gestartet wurde, ist es dann vielleicht immer der 2. Laden im 2. Kinderzimmer, oder der 6. Laden im Wohnzimmer (Fenster auf zwei Fronten

schön hell, aber meine Frau kotzt, wenn es ans Putzen geht...)

Für mich sehen diese Telegrammverluste danach aus, dass das knx Binding die Anfragen nicht zwischenspeichert und dann ab einer bestimmten Menge zeitgleicher (oder zeitnaher) Anfragen einfach Telegramme weg lässt.

**staehler** · 15.03.2017, 15:04

Danke für die Info, dann werde ich es mal mit den KNX-Binding ohne eibd versuchen.
Meine Rollos steuere ich, wenn eine größere Menge zu fahren ist, per KNX-Szene im Aktor selbst. Mein Aktor gibt das her, so dass ich halt eine Szene "Nacht" oder "Kino" oder " Guten Morgen" oder "Abschattung" habe. Die funktionieren eigentlich ganz gut.

**udo1toni** · 15.03.2017, 15:24

Ja, Szenen habe ich dafür auch schon genutzt, die Gruppenbildung von openHAB erschien mir halt recht elegant (ich muss keine weiteren Items mit knx Adressen anlegen...) und im Prinzip sollte die Steuerung ja auch ohne knx Szenen zuverlässig funktionieren. Ich hatte auch schon überlegt, nach 60 Sekunden durch die Gruppe die Status zu prüfen und nicht gefahrene Läden nachzutriggern, aber ich bin faul...

Ankündigung

OH2, knxd und Knx Binding für Blöde

OH2, knxd und Knx Binding für Blöde

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar