KNX/EIB Zugriff mit NSLU2 + USB + eibd

[putsche74]

Hallo liebe EIB-Gemeinde,

ich lese hier schon länger mit und habe durch dieses Forum schon viele Anregungen und Tips gefunden.

Ich versuche zur Zeit den (Dauer-)Zugriff auf mein EIB-Projekt von einem XP-Rechner auf eine stromsparendere
Variante zu verlagern. Hierzu habe ich noch eine NSLU2, die ich mit eibd bestückt habe und zwar mit der
(armel-)debian-Variante von http://www.auto.tuwien.ac.at/.
So weit so gut, ich erhalte allerdings wenn ich mit finknxusb die Geräte-ID (meiner Gira-USB)
ermitteln möchte keine Information.

:~ # findknxusb
Possible addresses for KNX USB devices:
:~ #

cat /proc/bus/usb/devices zeigt die Schnittstelle an:

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=135e ProdID=0022 Rev= 1.02
S: Manufacturer=Gira Giersiepen GmbH & Co. KG
S: Product=KNX-USB Data Interface
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 50mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=02(O) Atr=03(Int.) MxPS= 64 Ivl=2ms


Meine Frage nun: kann irgendjemand bestätigen schon einmal den Zugriff mit NSLU2 + USB hinbekommen zu haben (damit ich nicht etwas probiere was faktisch gar nicht geht?) und ist
evtl. an der Stelle hängengeblieben?

Danke und Viele Grüße

Thorsten

[makki]

Mal ganz blind: evtl. eine libusb-Geschichte..

Du düftest da mit NSLU2 nicht der erste sein, hab da aber keine persönliche Erfahrung; der lsusb sieht ja gut aus, versuch einfach mal usb:2:2:1 (für diesen Fall, bus:dev:config)

Falls das nicht geht und mkoegler das hier nicht sieht, mal mit Details auf die bcusdk-devel Liste posten..

Makki

[odysee_2002]

Hallo,

ich betreibe eibd mit linknx + webknx seit1 Jahr ohne Probleme an einer Siemens USB schnittstelle an einer NSLU2.
Man darf nur kein Package mit SMTP Unterstützung installieren, sonst gibt es
den "Segment fault".
Ich kann sogar via Ethernet und NSLU2 Geräte programmieren.
Kosten: 50€ und viel Zeit.

Gruß

[putsche74]

Hallo Odysee,

danke für Deine Antwort. Unter welcher Firmware hast Du das ganze laufen
(debian, unslung...) und aus welcher Quelle den eibd? Für debian auf armel-Plattform fand ich war es gar nicht so einfach, eine "fertige" Quelle zu finden.

Grüße

Thorsten

[mkoegler]

:~ # findknxusb
Possible addresses for KNX USB devices:
:~ #

cat /proc/bus/usb/devices zeigt die Schnittstelle an:

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=135e ProdID=0022 Rev= 1.02
S: Manufacturer=Gira Giersiepen GmbH & Co. KG
S: Product=KNX-USB Data Interface
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 50mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
E: Ad=02(O) Atr=03(Int.) MxPS= 64 Ivl=2ms

Ich würde einen Umstieg auf die Versionen aus den GIT Repository empfehlen. Es wird eine neuere libusb verwendet, die bei "merkwürdigen" Verhalten auf nicht x86 Plattformen schon ein paar Mal besser funktioniert hat.

[odysee_2002]

Hallo,

ich verwende unslung 6.10
Gibt es unterNSLU2-Linux - Unslung / HomePage browse
Eibd:
eibd - 0.0.3-4 - The eibd daemon is a central component of the BCU SDK.
linknx - 0.0.1.26-2 - KNX home automation platform

Läuft alles prima!

Gruß

[EIBman]

Hallo,

so ich hab' es jetzt auch hinbekommen, mein NSLU2 im lokalen Netz samt Unslung (v6.1-beta) & EIBD (0.0.3) zum Laufen zu kriegen. Per SSH auf dem NSLU2 eingehängt unter dann auf dem NSLU2

groupwrite ip:127.0.0.1 x/y/z 0|1

funzt wunderbar (entsprechendes Licht geht aus bzw. an).

Der EIBD-Daemon auf dem NSLU2 wird wie folgt gestartet:

usbport=$(findknxusb | /bin/sed -e '1 d' -e 's/device //' | /usr/bin/cut -d':' -f1-2) eibd -d -D -S -T -i usb:$usbport

So weit so gut.

Wenn ich nun aber auf einem anderen (Linux-)Rechner EIBD als Daemon starte (nutze Gentoo mit EIBD-eBuild 0.0.4, frisch kompiliert) und dort den Daemon analog starte, aber mit der NSLU2-IP-Adresse anstelle der USB-Adresse als URL, also per

eibd -d -D -S -T -i ip:192.168.1.77

dann klappt

groupwrite ip:127.0.0.1 x/y/z 0|1

vom Remote-PC nicht:

Open failed: Connection refused

.

Bei

groupwrite ip:192.168.1.77 x/y/z 0|1

gibt es auf dem Remote-PC zwar keine Fehlermeldung, aber passieren tut auch nichts (hätte das gleiche Ergebnis wie direkt vom NSLU2 aus erwartet).

ETS3 in einer VirtualBox auf demselben Remote-PC samt lokalen LAN mit KNXnet/IP klappt auch nicht (weder manuell noch automatisch kann keine Verbindung zum EIB aufgebaut werden); ein Ping auf den NSLU2-Router funzt aber. Ports sind alle offen, da ich im Moment lediglich im Lokalen Netzwerk herumexperimentiere.

Bin am Ende meines dürftigen Lateins...

Habt Ihr eine Ahnung, was ich falsch mache?

Besten Dank und Grüße,
Stefan

[makki]

auf dem zweiten:
ipt:192.168.1.77

Makki

[EIBman]

Danke.

Zwar gibt es jetzt keine Fehlermeldung mehr vom Remote-PC per

groupwrite ip:127.0.0.1 x/y/z 0|1

und als Antwort ein

Send request

aber das entsprechende Licht bleibt weiterhin unberührt (geht weder an noch aus).

Gibt es evtl. ein Rechteproblem? Auf dem NSLU2? Oder auf dem Remote-PC?


Kleine Ergänzung: Nun funktioniert das groupwrite auch nicht mehr auf der NSLU2. Ich sehe zwar einen Write via groupsocketlistener, aber passieren tut nichts.

[EIBman]

Okay, den ersten Fehler habe ich gefunden:

Für ein simples 1-bittiges Objekt muss man groupswrite anstelle von groupwrite verwenden, was auch erklärt warum es scheinbar anfangs am NSLU2 funktioniert hat und dann plötzlich nicht mehr...

Aus lauter Verzweiflung habe ich mal das bcusdk bzw. eibd aus den Sourcen auf dem NSLU2 compiliert. Dabei gab es einen kleinen Fehler in usbi.h, der sich aber leicht korrigieren ließ. PATH_MAX war nicht definiert. Ein simples

#define PATH_MAX 4096

schaffte Abhilfe.

Nun gut

group[B]s[/B]write ip:127.0.0.1 x/y/z 0|1

funktioniert also - auf dem NSLU2 und dem Remote-PC (mit ipt:... anstelle von ip:...)

Nicht funktionieren tut aber nach wie vor eine Verbindung in ETS3, welches auf dem Remote-PC in einer WinXP-VirtualBox läuft:

(1)
KNXnet/IP mit IP 192.168.1.77 (ist die IP des NSLU2s) oder 127.0.0.1 mit oder ohne NAT auf Port 3671 klappen nicht Unicast-Test und genereller Verbindungstest schlagen fehl.

(2)
KNXnet/IP Routing liefert beim generellen Verbindungstest ein OK, aber weder Busmonitor noch das Lesen/Schreiben von Werten funktioneren.

Der Trace lauf der NSLU2 von EIBD liefert auch keinerlei Schreibanfragen auf die probierten Gruppenadressen.

[mkoegler]

Der EIBD-Daemon auf dem NSLU2 wird wie folgt gestartet:

usbport=$(findknxusb | /bin/sed -e '1 d' -e 's/device //' | /usr/bin/cut -d':' -f1-2) eibd -d -D -S -T -i usb:$usbport

Nur ein Tip: Wenn sich der EIBD ein Interface aus den Output von findknxusb selbst aussuchen darf (zB weil nur eins angeschlossen ist), kannst du gleich

eibd -d -D -S -T -i usb:

schreiben.

[mkoegler]

Dabei gab es einen kleinen Fehler in usbi.h, der sich aber leicht korrigieren ließ. PATH_MAX war nicht definiert. Ein simples

#define PATH_MAX 4096

schaffte Abhilfe.

Danke für den Hinweis. Workaround ist im GIT. Meinen Nachforschungen nach zu Urteilen, deutet das auf ein Toolchain Problem hin.

Nicht funktionieren tut aber nach wie vor eine Verbindung in ETS3, welches auf dem Remote-PC in einer WinXP-VirtualBox läuft:

(1)
KNXnet/IP mit IP 192.168.1.77 (ist die IP des NSLU2s) oder 127.0.0.1 mit oder ohne NAT auf Port 3671 klappen nicht Unicast-Test und genereller Verbindungstest schlagen fehl.

(2)
KNXnet/IP Routing liefert beim generellen Verbindungstest ein OK, aber weder Busmonitor noch das Lesen/Schreiben von Werten funktioneren.

Der Trace lauf der NSLU2 von EIBD liefert auch keinerlei Schreibanfragen auf die probierten Gruppenadressen.

Unicast Test von der ETS wird nur vom EIBD aus den pu branch bestanden.
Bezüglich ETS auf Virtual Box kann ich nur zu folgenden raten:
* EIBD EIBnet/IP Server testen (zB indem man sich mit einen anderen EIBD dorthin verbindet und/oder mit "eibnetsearch -" danach sucht)
* Firewalls während der Fehlersuche abdrehen
* Schauen, das die Netzeinbindung von der Virtual Box kein NAT macht (dh so ist, wie wenn der virtuelle Rechner direkt im LAN wäre)

Kann die ETS den EIBD EIBnet/IP Tunneling Server finden?

[EIBman]

Danke für den Hinweis. Workaround ist im GIT. Meinen Nachforschungen nach zu Urteilen, deutet das auf ein Toolchain Problem hin.

Toolchainproblem auf der NSLU2 ist gut möglich, die Definition steht normalerweise in der limits.h, die aber auf dem NSLU2 nicht zu finden ist (jedenfalls finde ich sie nicht...). Ein ifndef + define in der usbi.h wäre glaube ich gut.

Unicast Test von der ETS wird nur vom EIBD aus den pu branch bestanden.

Okay, das hatte ich auch schon gelesen. Habe es nur der Vollständigkeit halber nochmal erwähnt. GIT habe ich auf dem NSLU2 noch nicht am laufen; jedenfalls schaffe ich es nicht, das bcusdk-Repository auszuchecken. Das wird aber an meiner Unkenntnis bzgl. GIT liegen.

Bezüglich ETS auf Virtual Box kann ich nur zu folgenden raten:
* EIBD EIBnet/IP Server testen (zB indem man sich mit einen anderen EIBD dorthin verbindet und/oder mit "eibnetsearch -" danach sucht)

Wie geschrieben läuft eibd samt USB-EIB-Verbindung auf dem NSLU2 mit "eibd -d -D -S -T -i usb:...". "-S" sollte ja den EIBnet/IP Server starten und per "-D" auch für andere auffindbar machen, oder nicht?
Kann ich mir "-T" eigentlich sparen?
Wofür wird eigentlich "-i" benötigt?

Führe ich "eibnetsearch -" auf dem NSLU2 direkt durch, so erhalte ich folgendes:

Asking 224.0.23.12 at port 3671 from port 3672
Answer from 192.168.1.77 at port 3671
Medium: 2
State: 0
Addr: 0.0.0
InstallID: 0
Serial: 00 00 00 00 00 00
Multicast-Addr: 224.0.23.12
MAC: 00 00 00 00 00 00
Name: eibd
Service 2 Version 1
Service 4 Version 1

Keine Ahnung, was mir das konkret sagt, aber sieht erstmal für mich nicht fehlerhaft aus, oder?

Nun zurück zum Remote-/Desktop-PC (der also keine eigene direkte EIB-Verbindung hat und den NSLU2-EIBD KNXnet/IP Server für die Verbindung nutzen soll).

Ist EIBD mit "-d -D -S -T -i ipt:192.168.1.77" gestartet also mit dem/obigen NSLU2-EIBD KNXnet/IP Server verbunden, so ergibt "eibnetsearch -" folgendes:

Asking 224.0.23.12 at port 3671 from port 3672
IP initialisation failed

Ist EIBD nicht auf dem Remote-/Desktop-PC gestartet, so ist die Ausgabe wie oben direkt auf dem NSLU2 ausgeführt. Ich gehe also davon aus, dass EIBD auf dem Remote-/Desktop-PC nicht gestartet sein darf, oder? Jedenfalls nicht mit den angegebenen Parametern (?).

Muss ich EIBD dann mit anderen Parametern aufrufen? Wo muss EIBD dann laufen? Auf dem Linux Host (also dem eigentlichen OS auf dem Remote-/Desktop-PC) oder auf dem VirtualBox Windows XP Guest? Letzteres wäre zumindedt für mich leicht schwierig, da ich noch nie eine Compiler-Toolchain auf einem Windows-PC erstellt habe.

* Firewalls während der Fehlersuche abdrehen

Alle Filter und Firewalls sind deaktiviert und alles ist zumindest intern offen wie ein riesen großes "Scheunentor".

* Schauen, das die Netzeinbindung von der Virtual Box kein NAT macht (dh so ist, wie wenn der virtuelle Rechner direkt im LAN wäre)

NAT habe ich deaktiviert bzw. die Netzwerkverbindung auf Bridged umgestellt (Guest auswählen > "Ändern" > "Netzwerk" und dann uf Bridged gehen und den entsprechenden Adapter auf dem Host auswählen, der verwendet werden soll). Jetzt hat der VirtualBox Windows XP Guest eine eigene IP im lokalen Netzwerk und entsprechend das gleiche Subnetz. Linux Host und NSLU2 können auch per Kommandozeile angepingt werden.

Kann die ETS den EIBD EIBnet/IP Tunneling Server finden?

Leider kann ich nicht mehr ganz folgen bzw. verstehe die Unterschiede nicht mehr (bin leider kein Netzwerk-Profi). Ich versuche deshalb mal zu erklären, was ich gemacht habe und was geht/nicht geht (sozusagen als HowTo wie es funktionieren könnte, für die Nachwelt...):

(1) Lokales Netzwerk 192.168.1.0, Subnet-Mask 255.255.255.0, Clients sind entweder per Kabel oder aber per WLAN angeschlossen.

(2) NSLU2 mit direkter EIB-USB-Anbindung und IP 192.168.1.77 im lokalen Netzwerk, OS Unslung 6.1-beta, EIBD 0.0.4, EIBD gestartet mit Parameter "-d -D -S -T -i usb:...", "groupswrite ip:192.168.1.77 x/y/z 0|1" sowie "groupswrite ip:127.0.0.1 x/y/z 0|1" direkt auf dem NSLU2 funktionieren, sprich grundsätzlich sollte der EIB-Zugriff also klappen. "eibnetsearch -" liefert oben angeführtes Ergebnis.

(3) Remote-/Desktop-PC mit (W)LAN-Verbindung zum NSLU2 bzw. mit IP 192.168.1.198 im lokalen Netzwerk, OS Gentoo/Linux, EIBD 0.0.4, ...

(3.1) ... EIBD gestartet mit Parameter "-d -D -S -T -i ipt:192.168.1.77",
(3.1.1) "groupswrite ip:192.168.1.77 x/y/z 0|1" von hier funktioniert
Ich nehme an, dass in diesem Fall direkt mit dem NSLU2-EIBD KNXnet/IP Server kommuniziert wird, korrekt?
(3.1.2) "groupswrite ip:127.0.0.1 x/y/z 0|1" von hier funktioniert.
Ich nehme an, dass in diesem Fall via lokaler EIBD-Instanz mit dem NSLU2-EIBD KNXnet/IP Server kommuniziert wird, korrekt?
(3.1.3) "eibnetsearch -" schlägt mit o.a. Fehlermeldung fehl. Vielleicht weil nun 2 EIB-"Server" im Netz sind?

(3.2) ... EIBD nicht gestartet,
(3.2.1) "groupswrite ip:192.168.1.77 x/y/z 0|1" von hier funktioniert
(3.2.2) "groupswrite ip:127.0.0.1 x/y/z 0|1" von hier funktioniert nicht bzw. führt zur Fehlermeldung, was aber m.E. auch nicht verwunderlich ist, denn schließlich läuft lokal ja auch keine EIBD-Instanz mehr.
(3.2.3) "eibnetsearch -" liefert identisches Ergebnis zu "eibnetsearch -" auf dem NSLU2 (vgl. o.) -> funktioniert also (?).
(3.2.4) VirtualBox Windows XP Guest mit Bridged Network und IP im lokalen Netzwerk 192.168.1.51, EIBD in Windows läuft nicht, keine TCP/IP-Paket-Filterung (alle Ports offen) und keine Firewall aktiv, ETS3 Professional Version 3.0f (Build 00990), Menü "Extras" > "Optionen..." > Tab "Kommunikation" > Button "Schnittstelle konfigurieren", neue "KNXnet/IP"-Verbidnung, eibd auf 192.168.1.77 wird (nun) automatisch gefunden, Port 3671, kein NAT-Modus --> mit OK bestätigt und dann im Optionen-/Kommunikation-Dialog auf Button "Test" --> Ergebnis: OK --> Gruppenmonitor, Gruppenadr.-Werte lesen/schreiben, etc. funzen... Jippie! Nicht funzen tut der Busmonitor mit der LAN-Verbindung.

Einzig verbleibendes Probelm (habe aber irgendwo schonmal gelesen, dass das "normal" sein soll): Nach einiger Zeit bricht die Verbidnung zusammen. Healing: Menü "Extras" > "Optionen..." > Tab "Kommunikation" > Button "Test" (selbiges muss auch initial beim Starten von ETS einmal gemacht werden)

Zu meinem besseren Verständnis würde ich das mit dem Tunneling auch gern noch verstehen :-D

Danke und Grüße,
Stefan

[EIBman]

Nur ein Tip: Wenn sich der EIBD ein Interface aus den Output von findknxusb selbst aussuchen darf (zB weil nur eins angeschlossen ist), kannst du gleich

eibd -d -D -S -T -i usb:

schreiben.

Ja, danke; klappt auch!

[mkoegler]

Wie geschrieben läuft eibd samt USB-EIB-Verbindung auf dem NSLU2 mit "eibd -d -D -S -T -i usb:...". "-S" sollte ja den EIBnet/IP Server starten und per "-D" auch für andere auffindbar machen, oder nicht?
Kann ich mir "-T" eigentlich sparen?
Wofür wird eigentlich "-i" benötigt?

-i ist für groupwrite & Co (EIBD Proktoll).
-T aktiviert das KNXnet/IP Tunneling Protokol - du willst es garantiert nicht abdrehen.

Führe ich "eibnetsearch -" auf dem NSLU2 direkt durch, so erhalte ich folgendes: .....

Ist OK.

Nun zurück zum Remote-/Desktop-PC (der also keine eigene direkte EIB-Verbindung hat und den NSLU2-EIBD KNXnet/IP Server für die Verbindung nutzen soll).

Ist EIBD mit "-d -D -S -T -i ipt:192.168.1.77" gestartet also mit dem/obigen NSLU2-EIBD KNXnet/IP Server verbunden, so ergibt "eibnetsearch -" folgendes:
....
Ist EIBD nicht auf dem Remote-/Desktop-PC gestartet, so ist die Ausgabe wie oben direkt auf dem NSLU2 ausgeführt. Ich gehe also davon aus, dass EIBD auf dem Remote-/Desktop-PC nicht gestartet sein darf, oder? Jedenfalls nicht mit den angegebenen Parametern (?).

Auf OK. ipt (dh KNXnet/IP Client) und eibnetsearch auf einen Rechner schlagen sich, da beide das selbe Port als einen Defaultwert haben. Bei Bedarf könnte man es umstellen, ist hier unnötig.

Jedenfalls ist damit festgestellt, das der EIBD korrekt ins Netzwerk eingebunden ist.

Muss ich EIBD dann mit anderen Parametern aufrufen? Wo muss EIBD dann laufen? Auf dem Linux Host (also dem eigentlichen OS auf dem Remote-/Desktop-PC) oder auf dem VirtualBox Windows XP Guest? Letzteres wäre zumindedt für mich leicht schwierig, da ich noch nie eine Compiler-Toolchain auf einem Windows-PC erstellt habe.

Auf Windows brauchts du in deinen Fall keinen EIBD. EIBD PArameter passen.

NAT habe ich deaktiviert bzw. die Netzwerkverbindung auf Bridged umgestellt (Guest auswählen > "Ändern" > "Netzwerk" und dann uf Bridged gehen und den entsprechenden Adapter auf dem Host auswählen, der verwendet werden soll). Jetzt hat der VirtualBox Windows XP Guest eine eigene IP im lokalen Netzwerk und entsprechend das gleiche Subnetz. Linux Host und NSLU2 können auch per Kommandozeile angepingt werden.

Damit hast du ein Problem besteitigt. NAT macht bei KNXnet/IP oft Probleme.

Zu deiner Frage, was ich mit den Tunneling gemeint habe:
Das "eibd auf 192.168.1.77 wird (nun) automatisch gefunden" geht.

Bezüglich Busmonitor:

Add (3.1.1) - Anfrage geht direkt ans NSLU (übers EIBD Protkoll)
Add (3.1.2) - Anfrage geht an lokalen EIBD via EIBD Prokoll von von dort per KNXnet/IP zum NSLU
Add (3.1.3) - wie oben erwähnt, eibnetsearch + eibd mit ipt: auf einen Rechner schlagen sich ohne Umkonfiguration. eibnetsearch auf dritten Rechner würde beide finden.
Add (3.2.4) ETS geht als. EIBD nicht aus den GIT geht nur als Gruppenbusmonitor. EIBD aus den GIT unterstützt den Busmonitor Modus (Daten entsprechen aber nur den vbusmonitor vom EIBD)

Ich hoffe ich habe keine Frage übersehen.