- √ - Brauche Hilfe bei eibd und USB in VirtualBox

[mkoegler]

Nur aus Interesse: Wofür verwendest Du den pu branch üblicherweise?

master ist der Hauptentwicklungszweig. Alles was zum Releasezeitpunkt drinnen ist, wird Teil der nächsten Release. Ist in der Regel auch besser getestet und es sollte nichts wegfallen.

pu ist aus der Notwendigkeit entstanden, Code zu veröffentlichen, der (noch) nicht in master passt. Der Code muss nur Lizenzmässig OK sein, keine offensichtlichen Fehler enthalten und compilieren. Irgendwann wandern dann die Patches von pu nach master bzw. werden gedroppt.
pu wird auch rebased.

[makki]

pu heisst glaube ich "proposed update", also eher "Beta zum testen".
Das ist beim eibd aber kaum schlimm, wenn ich automake & co irgendwie überlebe verwende ich nur das aus pu..

Makki

[Jockel]

Habs übersetzt und kurz getestet, auf den ersten Blickm sieht es gut aus! Ich werde jetzt mal zu der Version wechseln und sie weiter beobachten.

Nur aus Interesse: Wofür verwendest Du den pu branch üblicherweise?

[mkoegler]

Ja genau, Busankoppler ist der 6120 U-102 von BJ. Allerdings ist bei mir die Schnittstelle ständig auf dem BCU aufgesteckt und auch mit dem Rechner verbunden. Das Fehlerverhalten läßt sich nur durch Neustart des Rechners reproduzieren, ohne das eine der Verbindungen getrennt würde.

Im pu branch (SourceForge - bcusdk/bcusdk/shortlog) habe ich einen Fix commited, der helfen sollte. Bitte ausprobieren.

[Jockel]

Wenn ich die Datenblätter im Internet richtig deute, ist es also eine USB Schnittstelle, die auf eine BCU gesteckt wird.

Ja genau, Busankoppler ist der 6120 U-102 von BJ. Allerdings ist bei mir die Schnittstelle ständig auf dem BCU aufgesteckt und auch mit dem Rechner verbunden. Das Fehlerverhalten läßt sich nur durch Neustart des Rechners reproduzieren, ohne das eine der Verbindungen getrennt würde.


Folgendes hab ich jetzt noch mal mit der eibd Version aus dem Repository getestet:

1. Neustart des Rechners, danach eibd gestartet (der bekannte Fall):
Der erste Start des eibd bricht mit der bekannten Meldung ab, beim zweiten Start direkt danach ist alles OK

2. Neustart des Rechners, danach Schnittstelle von Busankoppler abgezogen und aufgesteckt:
Erster Start bricht mit der bekannten Meldung ab, beim zweiten Start ist alles OK

3. Danach Schnittstelle wieder vom Busankoppler abgezogen (kein Neustart, hat also direkt vorher funktioniert):
Erster Start bricht mit der bekannten Meldung ab, beim zweiten Start ist alles OK

4. Danach Schnittstelle vom USB getrennt (kein Neustart) und wiederum eibd gestartet
Klappt direkt beim ersten Start problemlos.

Wie schon vermutet hat der Aufruf von findknxusb vor dem ersten Start des eibd keine Auswirkungen auf das Verhalten. Auch längeres warten hat keine Auswirkung. Bislang war es so, daß die Schnittstelle nach dem ersten Startversuch bei allen weiteren Starts - bis zum Neustart des Rechners - problemlos funktioniert hat, da müßte ich das Langzeitverhalten aber noch mal beobachten.

Sollen wir diese Diskussion eigentlich mal woanders hin verlagern (z.B. auf die Mailingliste), zu dem Thema des Threads paßt sie ja nicht mehr so gut.

[mkoegler]

Eine Busch-Jaeger 6133, findknxusb meldet dazu noch "(Busch-Jaeger Elektro GmbH:KNX-USB Interface (Flush mounted)".

Wenn ich die Datenblätter im Internet richtig deute, ist es also eine USB Schnittstelle, die auf eine BCU gesteckt wird.

Beim ersten Zugriff darauf scheint die Schnittelle die BCU noch nicht erkannt zu haben und liefert zurück, das keine EMI Version unterstützt wird.

Ansich sollte das Verhalten mit Ab/Anstecken der Schnittstelle auch reproduzierbar sein:
* Wenn man (als User mit entsprechenden Zugriffsberechtigungen) "eibd -i -t0123 usb:" kurz nach den Anstecken startet, geht es dann?
* Hilft es, wenn man länger vor den Start vom EIBD wartet?
* Macht es einen Unterschied, ob die Schnittstelle vor den An/Abstecken verwendbar war (dh. die BCU gefunden hatte)?

[Jockel]

Die zweite AP ist als Bridge konfiguriert. Ich kann ja bei Gelegenheit auch mal mit die TCP/IP Pakete mitloggen, die die ETS verschickt!

Du hast auch recht, der Threadtitel ist falsch. Das liegt daran, daß hier nach einem ähnlich gelagertem Problem gefragt wurde, ich kann aber natürlich auch gerne einen eigenen Thread aufmachen.

Was für eine USB Schnittstelle ist es denn?

Eine Busch-Jaeger 6133, findknxusb meldet dazu noch "(Busch-Jaeger Elektro GmbH:KNX-USB Interface (Flush mounted)".

[mkoegler]

Der Server an dem die USB-Schnittstelle angeschlossen ist hängt an einem Switch, [...]Die Datenrate zwischen PC und Server liegt dabei bei rund 2-3 MByte/s (das ganze wird etwas einfacher, sobald mal alle Kabel liegen). Die Firewalls auf Server und PC hab ich für die Tests probehalber deaktiviert, beide Rechner hängen mit statischen IPs im gleichen Subnetz und sind dem DNS bekannt.

Ich setze ja keine Virtualisierung ein. Die ETS läuft auf einem PC mit Windows XP Prof., nur der eibd auf einem zweiten PC mit Linux.

Das mit der Virtualisierung habe ich durch den Titel angenommen.
Wenn die WLAN Access-Points zusammen wie ein Repeater wirken, sollte Netzwerkmässig alles OK sein.
Wenn sie wie eine Bridge wirken, kann es sein, das die Bridge erst lernen muss, was für Geräte im Netzwerk sind (zB in dem sie Daten über sie verschicken). Das betrifft aber nur die Suchfunktionen bzw. KNXnet/IP Routing. Der Aufbau einer Tunneling Verbindung sollte bei einer Bridge immer gehen, wenn die ETS die IP vom Partner kennt.

Ich hab eben den Rechner noch mal neu gestartet und es getestet. Die Logs sind angehängt. Beim ersten Start des eibd kommt es zu einer Fehlermeldung (Start1.txt), beim zweiten Start des eibd (Start2.txt) ist alles OK, meine Vermutung das erst der Aufruf von findknxusb die Schnittstelle initialisiert war also falsch. Das gleiche Verhalten habe ich übrigens wenn ich dem eibd die Auswahl der Schnittstelle überlasse. Ist auch reproduzierbar, hab es jetzt noch zwei mal ausprobiert. Nach dem ersten Start kann ich den eibd übrigens beliebig häufig ohne Fehlermeldung starten.

Was für eine USB Schnittstelle ist es denn?

Beim ersten Aufruf liefert die Schnittstelle zurück, das sie keine EMI Version unterstützt => der EIBD kann nichts auf den Bus schicken => Abbruch.

[Jockel]

Lt. Trace baut die ETS eine KNXnet/IP Verbindung erfolgreich auf. Nach 8 Sekunden beendet die ETS die Verbindung wieder.

Das ist so auch OK. Ich hab das Programmieren des Tasters beim Erscheinen des Dialogs abgebrochen, vorher versucht die ETS ja schon die Busverbindung aufzubauen und im Fehlerfall kam es da schon zur Meldung.

Wie schaut eigentlich die Netzwerk-Verbindung zwischen den beiden System aus?

Der Server an dem die USB-Schnittstelle angeschlossen ist hängt an einem Switch, der Switch wiederum an einem weiterem Switch an dem ein WLAN AP hängt (der aber nicht als Router fungiert). Der Programmier-PC wiederum hängt an einem zweiten WLAN AP der als Client fungiert. Die Datenrate zwischen PC und Server liegt dabei bei rund 2-3 MByte/s (das ganze wird etwas einfacher, sobald mal alle Kabel liegen). Die Firewalls auf Server und PC hab ich für die Tests probehalber deaktiviert, beide Rechner hängen mit statischen IPs im gleichen Subnetz und sind dem DNS bekannt.

Siehe SourceForge.net: BCU SDK with eibd: bcusdk-list

Danke, hatte ich noch nicht gesehen!

ein, es nimmt keine Initialisierungen vor. Wenn man die Auswahl der KNX USB Schnittstelle den EIBD überlässt [eine "zufällige" aus der Liste, die findknxusb ausgeben würde], kann man direkt

Ich hab eben den Rechner noch mal neu gestartet und es getestet. Die Logs sind angehängt. Beim ersten Start des eibd kommt es zu einer Fehlermeldung (Start1.txt), beim zweiten Start des eibd (Start2.txt) ist alles OK, meine Vermutung das erst der Aufruf von findknxusb die Schnittstelle initialisiert war also falsch. Das gleiche Verhalten habe ich übrigens wenn ich dem eibd die Auswahl der Schnittstelle überlasse. Ist auch reproduzierbar, hab es jetzt noch zwei mal ausprobiert. Nach dem ersten Start kann ich den eibd übrigens beliebig häufig ohne Fehlermeldung starten.

PS: Mein Gefühl geht in die Richtung, das die Virtualisierungsoftware Probleme macht.

Ich setze ja keine Virtualisierung ein. Die ETS läuft auf einem PC mit Windows XP Prof., nur der eibd auf einem zweiten PC mit Linux.

Ich hab aber auch die ETS in Verdacht. Jedenfalls ist das Verhalten absolut reproduzierbar, die Verbindung kann erst aufgabeut werden, wenn ein mal der Konfigurationsdialog mit OK bestätigt wurde. Ist ja eigentlich nicht schlimm, nur nervig und man wüßte halt gerne, was die Ursache ist...

[mkoegler]

Den eibd gestartet (eibd -t1023 -D -T -S -i -u usb:2:2:1:0 > test1), danach die ETS geöffnet, in der Gebäudeansicht einen einen Sensor ausgewählt und aus dem Kontextmenü "Programmieren" gewählt. Danach kam in der ETS die Fehlermeldung "Busverbindung konnte nicht hergestellt werden". Danach den eibd mit Ctrl-C beendet.

Lt. Trace ist kein Request über KNXnet/IP hereingekommen.

Wie Test 1, nur vor dem Menüpunkt "Programmieren" ein mal den Einstellungsdialog für die Busverbindung aufgerufen und mit OK bestätigt (ohne Änderungen vorzunehmen). Damit gab es dann keinen Fehler. Beendet nachdem das Programmierfenster erschien.

Lt. Trace baut die ETS eine KNXnet/IP Verbindung erfolgreich auf. Nach 8 Sekunden beendet die ETS die Verbindung wieder.

Von der EIBD Seite her ist kein Problem zu erkennen. Die empfangen Daten von der ETS verstossen auch nicht die KNX Spezifikation - bei den gewählten Funktionen würde ich mir mehr Packete von der ETS erwarten.

Wie schaut eigentlich die Netzwerk-Verbindung zwischen den beiden System aus?

Bei pthsem aus dem git (die 2.0.7 reicht ja für den eibd aus dem Repository nicht) meldet aclocal jetzt aber

acinclude.m4:93: warning: underquoted definition of AC_ENABLESUBDIR
acinclude.m4:93:   run info '(automake)Extending aclocal'
acinclude.m4:93:   or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
aclocal: couldn't open directory `m4': Datei oder Verzeichnis nicht gefunden

Siehe SourceForge.net: BCU SDK with eibd: bcusdk-list

Sobald ich pthsem übersetzt bekomme probiere ich das ganze auch noch mal mit dem aktuellem eibd.

Neuerer EIBD wird in dem Fall oben mitgeloggten Fällen nichts helfen.

Nach was am Rande: Nimmt findknxusb eigentlich initialisierungen an der USB-Schnittstelle vor? Eben gab es beim starten des eibd bei Initialisieren der Schnittstelle einen Fehler, bis ich noch mal findknxusb aufgerufen habe (Die Adresse der Schnittstelle am Bus war aber unverändert).

Nein, es nimmt keine Initialisierungen vor. Wenn man die Auswahl der KNX USB Schnittstelle den EIBD überlässt [eine "zufällige" aus der Liste, die findknxusb ausgeben würde], kann man direkt

eibd [...] usb:

aufrufen.

PS: Mein Gefühl geht in die Richtung, das die Virtualisierungsoftware Probleme macht.

[Jockel]

Ein -t1023 Output vom Fehler (bitte komplett in eine Datei umgeleitet) würde mir mehr sagen.

Ich hab das ganze jetzt noch mal mit Debugausgaben wiederholt, die Ausgaben sind angehängt.

Test 1:
Den eibd gestartet (eibd -t1023 -D -T -S -i -u usb:2:2:1:0 > test1), danach die ETS geöffnet, in der Gebäudeansicht einen einen Sensor ausgewählt und aus dem Kontextmenü "Programmieren" gewählt. Danach kam in der ETS die Fehlermeldung "Busverbindung konnte nicht hergestellt werden". Danach den eibd mit Ctrl-C beendet.

Test 2:
Wie Test 1, nur vor dem Menüpunkt "Programmieren" ein mal den Einstellungsdialog für die Busverbindung aufgerufen und mit OK bestätigt (ohne Änderungen vorzunehmen). Damit gab es dann keinen Fehler. Beendet nachdem das Programmierfenster erschien.

aclocal -I m4...

Danke, beim bcusdk haut das jetzt hin. Bei pthsem aus dem git (die 2.0.7 reicht ja für den eibd aus dem Repository nicht) meldet aclocal jetzt aber

acinclude.m4:93: warning: underquoted definition of AC_ENABLESUBDIR
acinclude.m4:93:   run info '(automake)Extending aclocal'
acinclude.m4:93:   or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
aclocal: couldn't open directory `m4': Datei oder Verzeichnis nicht gefunden

Ist wahrscheinlich nur eine Kleinigkeit, aber wie schon geschrieben, mit dem Thema hab ich mich noch nnicht beschäftigt.

Sobald ich pthsem übersetzt bekomme probiere ich das ganze auch noch mal mit dem aktuellem eibd.


Nach was am Rande: Nimmt findknxusb eigentlich initialisierungen an der USB-Schnittstelle vor? Eben gab es beim starten des eibd bei Initialisieren der Schnittstelle einen Fehler, bis ich noch mal findknxusb aufgerufen habe (Die Adresse der Schnittstelle am Bus war aber unverändert).

Kann ich noch mal ausprobieren sobald ich den rechner noch mal starte.

[mkoegler]

In der ETS (3.0f) habe ich eine KNXnet/IP (nicht KNXnet/IP Routing) Verbindung konfiguriert, IP-Adresse des Servers angegeben und den Port 3671 belassen. Der Haken bei NAT ist deaktiviert. Das Verhalten ist absolut reproduzierbar: Ein mal den Einstellungsdialog öffnen (nicht mal den Tab mit der Verbindung) und mit OK bestätigen reicht, danach funktioniert alles.

Ein -t1023 Output vom Fehler (bitte komplett in eine Datei umgeleitet) würde mir mehr sagen. Es hat sicher nichts mit der Distribution zu tun. Entweder ist es ein ETS Bug oder ein (vielleicht schon in der GIT Version gefixter) EIBD Bug.

Wo wir grade dabei sind: Wie muß ich eigentlich die Version aus dem Repository übersetzen? Hab mich bislang nicht mit autoconf & Co. beschäftigt und bekomme beim generieren des configure Skripts immer Fehler.

Bezüglich autoconf&Co: Die Befehlsfolge steht in der BCUSDK Dokumentation, Chapter Usage&Installation:

aclocal -I m4
autoheader
automake -a --foreign
autoconf

[Jockel]

Welche Version hast du verwendet ? Ich weiss nichtmehr genau wo&wann, aber das kommt mir bekannt vor.. Welche Distro? für Debian/Ubuntu hätt ich was mit 100%, ich nutze die ETS seit nunmehr 1J über nichts anderes..

Auf meinem Server läuft OpenSuse 11.2, der PC mit der ETS unter Windows XP. Übersetzt habe ich den EIBD mit
./configure --enable-onlyeibd --enable-usb --enable-eibnetipserver, gestartet mit eibd -D -T -S -d -i -u usb:2:2:1:0

In der ETS (3.0f) habe ich eine KNXnet/IP (nicht KNXnet/IP Routing) Verbindung konfiguriert, IP-Adresse des Servers angegeben und den Port 3671 belassen. Der Haken bei NAT ist deaktiviert. Das Verhalten ist absolut reproduzierbar: Ein mal den Einstellungsdialog öffnen (nicht mal den Tab mit der Verbindung) und mit OK bestätigen reicht, danach funktioniert alles.


Wo wir grade dabei sind: Wie muß ich eigentlich die Version aus dem Repository übersetzen? Hab mich bislang nicht mit autoconf & Co. beschäftigt und bekomme beim generieren des configure Skripts immer Fehler.


Danke schon mal für die Hilfe!

Jockel

[makki]

..mit der ETS auf die eibd Verbindung "Unicast Test failed"!

Und auch der kosmetische Fehler ist seit vorgestern gefixed
(indirektes Ack an mkoegler)

Bei der Programmierung über die ETS hatte ich das komische Phänomen, daß ich den Konfigurationsdialog nach jedem Start der SW noch einmal öffnen und mit OK schließen mußte ohne dort Änderungen vorzunehmen. (Der eibd lief die ganze Zeit durch.) Vorher konnte die ETS keine Verbindung zum Bus aufbauen, danach klappte es jedes mal problemlos.

Habt Ihr da vielleicht irgendwelche Ideen?

Welche Version hast du verwendet ? Ich weiss nichtmehr genau wo&wann, aber das kommt mir bekannt vor.. Welche Distro? für Debian/Ubuntu hätt ich was mit 100%, ich nutze die ETS seit nunmehr 1J über nichts anderes..

Makki

[Jockel]

Hab heute auch endlich mal den eibd bei mir eingerichtet.

Bei der Programmierung über die ETS hatte ich das komische Phänomen, daß ich den Konfigurationsdialog nach jedem Start der SW noch einmal öffnen und mit OK schließen mußte ohne dort Änderungen vorzunehmen. (Der eibd lief die ganze Zeit durch.) Vorher konnte die ETS keine Verbindung zum Bus aufbauen, danach klappte es jedes mal problemlos.

Habt Ihr da vielleicht irgendwelche Ideen?