EIBD und USB

[mkoegler]

Nein, zur Zeit hängt alles an einer Linie und ich habe keinerlei Koppler im Einsatz.

Ist ein Atom 330 mit 2 GB RAM unter OpenSuse 11.2. Mit laufendem MH liegt die CPU Last bei 10% oder weniger. Sonst hat der Rechner im Moment auch nicht viel zu tun. Da laufen zwar noch Postfix, Dovecot und Samba aber zum Zeitpunkt des Tests ohne Zugriffe und ohne eingehende Mails. Ich glaube also nicht, daß es daran liegt. Zumal ich das Problem schon länger beobachte.

Ich wollte Probleme am Rechner nur ausschliessen. Mit der Konfiguration würde ich keine Problem erwarten.

Alles was der EIBD vom Interface bekommt, landet auch im vbusmonitor. Damit bleibt nur mehr das Interface als Problemquelle.

Start den EIBD einmal ohne GroupCache, KNXnet/IP Server und sonstige Clients und starte nur busmonitor1 als einzigen Client.
Es müßten alle Schaltbefehle ohne Wiederholung auftauchen, gefolgt von einen ACK. Wiederholungen, NACK oder BUSY sind ein Zeichen, das etwas mit der Installation nicht stimmt.

[Jockel]

Ich hab den eibd jetzt mit den Parametern --daemon, --pid-file, --listen-tcp usb: und den busmonitor mit busmonitor1 ip:localhost gestartet.

Danach die besagte Lampe 10x ein- und ausgeschaltet. Dabei hat der busmonitor 9x das Ein- und 10x das Aus-Telegramm aufgezeichnet.

Das deckt sich auch mit meiner Beobachtung aus der Vergangenheit, auch da sind mir immer nur die fehlenden "Ein" Telegramm, aber nie "Aus" aufgefallen.

In der Summe ist das Ergbniss deutlich besser als vorher, da sind wesentlich mehr Ein-Telegramme verloren gegangen.

Resends gab es übrigens nicht und die Lampe hat in allen Fällen korrekt geschaltet.

[mkoegler]

Danach die besagte Lampe 10x ein- und ausgeschaltet. Dabei hat der busmonitor 9x das Ein- und 10x das Aus-Telegramm aufgezeichnet.

Das deckt sich auch mit meiner Beobachtung aus der Vergangenheit, auch da sind mir immer nur die fehlenden "Ein" Telegramm, aber nie "Aus" aufgefallen.

In der Summe ist das Ergbniss deutlich besser als vorher, da sind wesentlich mehr Ein-Telegramme verloren gegangen.

Resends gab es übrigens nicht und die Lampe hat in allen Fällen korrekt geschaltet.

Wenn nach jeden Empfangen Telegram auch noch ein ACK gekommen ist, ist busseitig auch alles in Ordnung. Dein Interface "schluckt" die Telegramme.

Falls ein ETS vorhanden ist, kann man das Ergebniss mit den ETS Busmonitor verifizieren. Mich würde es wundern, wenn es anders wäre.

[Jockel]

Wenn nach jeden Empfangen Telegram auch noch ein ACK gekommen ist, ist busseitig auch alles in Ordnung. Dein Interface "schluckt" die Telegramme.

Nachdem ich noch mal ein wenig herumgespielt habe gehe i9ch auch davon aus, daß auf dem Bus alles OK ist.

Fragt sich, warum das Interface die Telegramme verschluckt und was man dagegen tun kann. Als Workarround hab ich das Rückmeldeobjekt des Aktors aktiviert, jetzt hab ich keine Probleme mehr mit dem Empfang in MH. Schön finde ich die Lösung aber nicht.

Interessant ist ja, das immer nur das "Ein" Telegramm unterschlagen wurde und das auch der Busmonitor ein Telegramm nicht gesehen hat.

Der zweite Punkt der auffällt ist, daß im Busmonitor nur sehr wenige Telegramme unterschlagen werden (1 von 10), im MisterHouse die "Ein" Telegramme nur sehr sporadisch ankommen. Das spricht doch eigentlich dafür, daß zumindest nicht nur in der USB-Schnittstelle ein Problem begraben liegt.

[Pauker]

Ich kenne auch die Eigenart von Misterhouse Telegramme zu unterschlagen.

Den eibd und die Schnittstelle habe ich über den Gruppenmonitor der ETS ausschließen können:
Gruppenmonitor parallel zu Misterhouse an den eibd und in der ETS sind die Telegramme da und in Misterhouse nicht.

Mh hat wohl ein Timing Problem, denn bei mir liegt es vermutlich an der Menge von Telegrammen. Zumindest lässt sich der Fehler hier an besten beobachten. Wenn ich meine 17 Rollläden zeitgleichen öffne kommen die Statusmeldungen der Aktoren nicht vollständig in MH an.

Daher meine Frage:

Wie stark sendet MH wenn die Lampe eingeschaltet wird?
Wie viel ist auf dem Bus zu der zeit los?

Die Parameter der mh.ini:

eib_send_interval

[mkoegler]

Interessant ist ja, das immer nur das "Ein" Telegramm unterschlagen wurde und das auch der Busmonitor ein Telegramm nicht gesehen hat.

Der zweite Punkt der auffällt ist, daß im Busmonitor nur sehr wenige Telegramme unterschlagen werden (1 von 10), im MisterHouse die "Ein" Telegramme nur sehr sporadisch ankommen. Das spricht doch eigentlich dafür, daß zumindest nicht nur in der USB-Schnittstelle ein Problem begraben liegt.

Persönlich würde mir nichts einfallen, wo etwas im EIBD verschwinden könnte. Alles was das OS bekommt, sieht der EIBD auch. Wenn Telegramme im Rechner verschwinden, müßten diese alle Typen betreffen.

Für mich sieht es eher aus, wie wenn Telegramme mit bestimmten Bitmustern häufiger verschwinden (Im Busmonitor haben die Telegramme Timing-Informationen, daher sind sie unterschiedlicher).

Dein Interface besteht, wenn ich richtig recheriert habe, aus einer BCU und einen USB Interface Applikationsmodul. Die meisten solchen Interfaces verwenden PEI16 zwischen BCU und Applikationsmodul.
Die Implementierung einer zuverlässigen PEI16 Ansteuerung ist eine Herausforderung (vgl. BCU1 Kernel Treiber).

[Jockel]

Dein Interface besteht, wenn ich richtig recheriert habe, aus einer BCU und einen USB Interface Applikationsmodul.

Ja genau. leider hab ich im Moment auch keinen Zugriff auf ein anderes Interface. Vielleicht werde ich dann aber doch bei der demnächst anstehenden Aufrüstung noch ein IP-Interface dazu nehmen.

Persönlich würde mir nichts einfallen, wo etwas im EIBD verschwinden könnte. Alles was das OS bekommt, sieht der EIBD auch. Wenn Telegramme im Rechner verschwinden, müßten diese alle Typen betreffen.

Ja, das ganze ist etwas merkwürdig. Wie schpon gesagt, bei allen Tests haben immer nur die "Ein" Telegramme gefehlt, da glaube ich nicht an einen Zufall. Und die "Verschwindenshäufigkeit" war beim Busmonitor deutlich geringer als im MH.

An der Buslast liegt es definitiv nicht, zu der Zeit war auf dem Bus sonst absolut nichts los. Ich könnet auch noch mal ausführlicher andere GAs testen, bislang meine ich das sich das Problem auf eine GA von einem Taster beschränkt.

Wenn ich noch was zum Debuggen beitragen kann mache ich das natürlich gerne.

[Ottorino]

Hallo,

ich muss das Thema nochmal aufnehmen, da seit heute morgen mein eibd nicht mehr funktioniert :-(

Hintergrund:
Aus diversen Gründen habe ich mein Debian-Server per dist-upgrade auf die aktuelle Testing-Version (Squeeze) aktualisiert. Das lief soweit auch reibungslos durch - die KNX/USB-Schnittstelle wird korrekt eingebunden:

dmesg
[ 6.650121] usb-storage: device found at 2
[ 6.650142] usb-storage: waiting for device to settle before scanning
[ 6.756745] usb 2-2: new full speed USB device using uhci_hcd and address 3
[ 6.953929] usb 2-2: New USB device found, idVendor=145c, idProduct=1330
[ 6.953959] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6.953986] usb 2-2: Product: KNX-USB Interface (Flush mounted)
[ 6.954008] usb 2-2: Manufacturer: Busch-Jaeger Elektro GmbH
[ 6.956804] usb 2-2: configuration #1 chosen from 1 choice
[ 7.100209] usb 4-2: new full speed USB device using uhci_hcd and address 2
[ 7.164721] usbcore: registered new interface driver hiddev
[ 7.180407] generic-usb 0003:145C:1330.0001: hiddev0,hidraw0: USB HID v1.01 Device [Busch-Jaeger Elektro GmbH KNX-USB Interface (Flush mounted)] on usb-0000:00:11.2-2/input0
[ 7.180560] usbcore: registered new interface driver usbhid
[ 7.180585] usbhid: v2.6:USB HID core driver


Danach funktionierte allerdings eibd und findknxusb nicht mehr:

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

homeserver:~# eibd -S usb:2:3
initialisation of the backend failed
homeserver:~#


Also habe ich aus dem GIT das aktuelle BCUSDK wie am Anfang dieses Threads beschrieben geladen und zuerst pthsem und dann eibd kompiliert. Pthsem lief ohne Fehler bis make install durch.
EIBD bricht bei make mit folgendem Fehler ab:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../../eibd/libserver -I../../common -I/usr/local/include -g -O2 -fno-rtti -fno-exceptions -MT findknxusb.o -MD -MP -MF .deps/findknxusb.Tpo -c -o findknxusb.o findknxusb.cpp
mv -f .deps/findknxusb.Tpo .deps/findknxusb.Po
/bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -fno-rtti -fno-exceptions -o findknxusb findknxusb.o libusb.a -lpthsem
libtool: link: g++ -g -O2 -fno-rtti -fno-exceptions -o findknxusb findknxusb.o libusb.a /usr/lib/libpthsem.so
libusb.a(linux_usbfs.o): In function `clock_gettime':
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
collect2: ld returned 1 exit status
make[3]: *** [findknxusb] Fehler 1
make[3]: Leaving directory `/home/frank/bcusdk/eibd/usb'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/frank/bcusdk/eibd'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/frank/bcusdk'
make: *** [all] Fehler 2


Per Google ist dazu nichts zu finden. Hat jemand eine Idee?


PS: Ach ja - lsusb ergibt
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 145c:1330
Bus 002 Device 002: ID 1058:1001 Western Digital Technologies, Inc. External Hard Disk [Elements]
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 0bc2:2101 Seagate RSS LLC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Danke im Voraus!

[bss]

Welche gcc version hast Du auf Deinem Rechner installiert ?

Ich hatte auch seltsames beobachtet als ich versucht habe unter Fedora 12 zu kompilieren.

Mit Fedora 8 und Centos 5.2 hatte ich kein Problem, ich habe festgestellt dass dort gcc 4.1.x verwendet wird und bei Fedora 12 wars dann ein 4.2.x or 4.4.x ( jedenfalls höher ).

Edit : gcc version gibts mit "gcc -v"

[Ottorino]

es ist gcc 4.4.4 (Debian 4.4.4-1)

Kernel
2.6.32-3-486

[bss]

Dann würde ich mal versuchen an einen 4.1.x compiler ran zu kommen, ich bin sicher es funktioniert dann ( alternativ könnte ein compiler experte auch sagen welche switches nötig sind ... ).

Wie gesagt : Ich hatte es nicht geschafft und hatte dann ein CentOS 5.2 installiert und damit compiliert, dann die RPMs gebaut und das ganze dann unter Fedora 12 installiert - lief prima. Nur eben am compilieren selbst bin ich gescheitert.

[Ottorino]

Das hat leider nicht funktioniert:
# export CC=gcc-4.1
# echo $CC
gcc-4.1

und dann ./configure und make erneut durchgeführt

-> Ergebnis:
.
.
libusb.a(linux_usbfs.o): In function `clock_gettime':
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
collect2: ld returned 1 exit status
make[3]: *** [findknxusb] Fehler 1
make[3]: Leaving directory `/home/frank/bcusdk/eibd/usb'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/frank/bcusdk/eibd'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/frank/bcusdk'
make: *** [all] Fehler 2

[bss]

Ähm ... Mit setzen einer Variablen mit ner Compiler Versionsnummer ändert sich die Compiler Version als solche im allgemeinen nicht ... Wäre ja noch schöner wenn man updates/downgrades einfach so mit ner Variablen machen könnte ...

"which gcc" wird noch immer den gleichen nehmen und damit ist "gcc -v" auch noch immer das gleiche ... :

# export CC="gcc-4.0"
# echo $CC
gcc-4.0
# gcc -v
Es werden eingebaute Spezifikationen verwendet.
Ziel: i386-redhat-linux
Konfiguriert mit: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux
Thread-Modell: posix
gcc-Version 4.1.2 20070925 (Red Hat 4.1.2-33)
# which gcc
/usr/lib/ccache/gcc

Du musst das Ding schon wirklich installieren - alternativ den Link umbiegen auf die entsprechende Version :

# ls -l $(which gcc)
lrwxrwxrwx 1 root root 16 15. Nov 2007 /usr/lib/ccache/gcc -> ../../bin/ccache
# ls -l /usr/bin/ccache
-rwxr-xr-x 1 root root 40688 2. Okt 2007 /usr/bin/ccache

Im Zweifel ne virtuelle Maschine installieren ( z.B. VirtualBox ) und dann da drin ein OS parallel installieren - eines mit der richtigen Compiler Version. Da ich mein CentOS leider wieder platt gemacht habe kann ich Dir nicht sagen welche Version dort drin ist, aber ganz sicher funktioniert es mit der Version die bei CentOS 5.2 dabei ist ... und das ist ja nur ein download weit weg.

[mkoegler]

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

usbfs gemounted?

Also habe ich aus dem GIT das aktuelle BCUSDK wie am Anfang dieses Threads beschrieben geladen und zuerst pthsem und dann eibd kompiliert. Pthsem lief ohne Fehler bis make install durch.
EIBD bricht bei make mit folgendem Fehler ab:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../../eibd/libserver -I../../common -I/usr/local/include -g -O2 -fno-rtti -fno-exceptions -MT findknxusb.o -MD -MP -MF .deps/findknxusb.Tpo -c -o findknxusb.o findknxusb.cpp
mv -f .deps/findknxusb.Tpo .deps/findknxusb.Po
/bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -fno-rtti -fno-exceptions -o findknxusb findknxusb.o libusb.a -lpthsem
libtool: link: g++ -g -O2 -fno-rtti -fno-exceptions -o findknxusb findknxusb.o libusb.a /usr/lib/libpthsem.so
libusb.a(linux_usbfs.o): In function `clock_gettime':
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
/home/frank/bcusdk/eibd/usb/linux_usbfs.c:56: undefined reference to `pth_int_time'
collect2: ld returned 1 exit status
make[3]: *** [findknxusb] Fehler 1
make[3]: Leaving directory `/home/frank/bcusdk/eibd/usb'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/frank/bcusdk/eibd'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/frank/bcusdk'
make: *** [all] Fehler 2

Ich wüprde sagen, das du unter /usr/ ein pthsem 2.0.7 und unter /usr/local ein pthsem 2.0.8 installiert hast - beim Compilieren werden beide verwendet :-(

Meine Empfehlung ist, schaue das am System nur mehr ein pthsem 2.0.8 installiert ist.
Da 2.0.8 schon offiziell released ist (inkl. diversen Binary packages auf meiner Homepage), braucht man nicht mehr die GIT Version.

PS:
Die Version unter /usr/local wird man los, indem man im pthsem build directory

make uninstall

ausführt.

[mkoegler]

Dann würde ich mal versuchen an einen 4.1.x compiler ran zu kommen, ich bin sicher es funktioniert dann ( alternativ könnte ein compiler experte auch sagen welche switches nötig sind ... ).

Wie gesagt : Ich hatte es nicht geschafft und hatte dann ein CentOS 5.2 installiert und damit compiliert, dann die RPMs gebaut und das ganze dann unter Fedora 12 installiert - lief prima. Nur eben am compilieren selbst bin ich gescheitert.

GCC version ist egal - bcusdk gibt es in meinen Ubuntu ppa für die Ubuntu Distributionen der letzten Jahr - da werden alle möglichen GCC Versionen verwendet.

Ich bin mir nichts bewusst, was einen Build unter Fedora 12 im Wege sollte.