Mit ETS und KNXnet/IP Routing über eibd auf den KNX

[mkoegler]

Hier jetzt die logs eines fehlerhaften Programmierversuchs über KNXnet/IP Routing von 2 Rechnern. Einmal vom Server und einmal vom Monitoring Client.

Es handelt sich jeweils um den aktuellen eibd au dem pu-Branch, gestartet wie folgt:

Server:

/usr/local/bin/eibd -t1023 -D -i -S -T -R usb:4:2:1:0 > server.log

Monitoring Client:

/usr/local/bin/eibd -t1023 -i ip: > monitor.log

Vielleicht kann man jetzt sehen, ob das Programmierproblem an der ETS, der Schnittstelle oder am eibd liegt.

So ist das Sinnlos. Es ist längst klar, das die "problematischen Daten" von der USB Schnittstelle kommen. Die offene Frage ist, ob die USB Schnittstelle oder etwas am Bus die Daten in die Verbindung einschleust.

Um das zu klären, muss der Busmonitor nicht im KNXnet/IP Bereich, sondern am KNX Bus selbst gesetzt werden.

Mit deiner BCU1 Schnittstelle (+ bcu1driver) müßte man folgendes als parallels Monitoring machen:

/usr/local/bin/eibd -t1023 -i bcu1:/dev/eibX > monitor.log

+

busmonitor1 ip:127.0.0.1

Wichtig ist, das busmonitor1 durchläuft, damit der EIBD im Busmonitor-Betrieb bleibt.

[jonofe]

Mit deiner BCU1 Schnittstelle (+ bcu1driver) müßte man folgendes als parallels Monitoring machen:

/usr/local/bin/eibd -t1023 -i bcu1:/dev/eibX > monitor.log

+

busmonitor1 ip:127.0.0.1

Wichtig ist, das busmonitor1 durchläuft, damit der EIBD im Busmonitor-Betrieb bleibt.

Jetzt hab ichs kapiert und genau so gemacht.


Hier die Logs dazu!

[mkoegler]

Jetzt hab ichs kapiert und genau so gemacht.

Hier die Logs dazu!

Danke, das ist was ich wollte. Nach einer ersten Auswertung sollte die USB Schnittstelle OK sein. Die unbekannten Packete treten auch auf den Bus auf.

Im Prinzip heisst das, programmiertes Gerät ist fehlerhaft oder ein anderes Gerät (auch Linen/Bereichskoppler) stört den Bus (Ich tippe eher auf zweiteres, da es lt. deinen Aussagen bei mehreren Geräten auftritt).

Was mir aufgefallen, das BUSY Meldungen am Bus liegen. Irgendetwas scheint nicht mitzukommen.

Wenn du den Störenfried finden willst, bleibt nichts anderes übrig, als Teile des Busses/Geräte abzuklemmen und zu schauen, ob die Programmierfehler verschwinden.

[makki]

Ich hatte ähnlich Phänomene mit Busy und daraus resultierenden Problemen schon zweimal mit alten, offenbar defekten LK (als LV).
Beim programmieren via iETS/HS ist das vorher nur nie aufgefallen, weil die Telegrammratenbegrenzung aktiviert war, bei vollgas via eibd knirschte es dann..

Makki

[jonofe]

okay, dann werde ich das mal überprüfen.
Ich habe in meiner Anlage 2 alte LK's verbaut (4 TE), vielleicht sind das ja die Übeltäter.

Bei eibd kann man keine Telegrammratenbegrenzung aktivieren, oder?
würde das ggf. das Problem lösen? Oder würden die unbekannten Telegramme auch dann die Programmierung stören?

[jonofe]

Das wars!

Nach dem ich den LK von meiner Innenlinie einfach mal von der Datenschiene genommen habe, lassen sich sogar die Gira TS2+ stabil programmieren.
Werde mich jetzt mal nach 2 aktuellen LK's umschaun.

Danke für deine Geduld und den tollen Support.

[mkoegler]

Bei eibd kann man keine Telegrammratenbegrenzung aktivieren, oder?
würde das ggf. das Problem lösen? Oder würden die unbekannten Telegramme auch dann die Programmierung stören?

Theoretisch könnte man etwas im EIBD einbauen, das nach jeden Telegramm x-ms Pause gemacht werden. Es würde aber nur die Auftrittswahrscheinlichkeit senken, da ja ein anderes Gerät parallel die Buslast erhöhen könnte.

Jendenfalls auch Danke für das Finden von ein paar Schwachstellen im EIBD.

[makki]

140-1AB02 ? (oder baugleiche OEM der Insta)
Die Dinger hat echt der Teufel gesehen.

Ich hab da auch einen Verdacht: Da ist ja eine 1/2AA 3V Lithium-Batterie drin; Die ist zwar was man so liest nur für den Betrieb als LK relevant damit die Filtertabellen gespeichert werden, aber einen Versuch wärs Wert ?
Hatte aber noch keine Zeit/Lust, weil ich noch Ersatz griffbereit hatte..

Von einer Telegrammratenbegrenzug halte ich jetzt weniger, das doktert ja nur am Symptom ohne die Ursache zu beheben..

Makki

[jonofe]

Ja das sind Insta-LK's. Allerdings verwende ich sie als Linienkoppler und die Filtertabellen werden auch gespeichert. Daher sollten die Batterien auf jeden Fall noch funktionieren. Die Frage ist nur, ob evtl. nicht doch die über die Jahre abfallende Spannung vielleicht doch Auswirkungen hat.

@mkoegler: kann man eigentlich an den obskuren Telegrammen erkennen, wer sie sendet? also z.B. die physikalische Quell-Adresse und ggf. ne Gruppenadresse als Ziel? Oder ist es nur Müll?

[mkoegler]

@mkoegler: kann man eigentlich an den obskuren Telegrammen erkennen, wer sie sendet? also z.B. die physikalische Quell-Adresse und ggf. ne Gruppenadresse als Ziel? Oder ist es nur Müll?

Der "offizielle" Sender ist das Gerät, das programmiert wird.

Mein Gefühl ist, das während der Übertragung eine regulären Telegrams der Bus auf einen anderen Pegel gezogen wird (EIB ist ja ein shared medium), so das etwas anderes am Bus herauskommt.

@makki: Ein Siemens 140-1AB02 hat bei dir Probleme gemacht?

[mkoegler]

140-1AB02 ? (oder baugleiche OEM der Insta)
Die Dinger hat echt der Teufel gesehen.

Ich hab da auch einen Verdacht: Da ist ja eine 1/2AA 3V Lithium-Batterie drin; Die ist zwar was man so liest nur für den Betrieb als LK relevant damit die Filtertabellen gespeichert werden, aber einen Versuch wärs Wert ?
Hatte aber noch keine Zeit/Lust, weil ich noch Ersatz griffbereit hatte..

Ich habe jemanden von Siemens auf diese Sache aufmerksam gemacht.
Die Vermutung geht dahin, das der LK keine Filtertablle (mehr) enthält (Die Tabelle liegt bei diesen Modell in einen batteriegepufferten RAM).
Ohne Filtertablle wird alles weitergeleitet. Wenn Addressen darunter sind, die im EIB Segment auf keinem Gerät definiert sind, werden Wiederholungen produziert.
Wenn viele Wiederholungen zusammenkommen, gehen dann die Puffer im LK über und er sendet das BUSY.

Demnach müßte ein Neuprogrammieren des LKs Abhilfe schaffen (zumindestens so lange, bis das RAM seine Daten wieder vergisst).

[makki]

Ich hatte die ja nur als LV in Betrieb und auch als solche parametriert, neuprogrammieren hat auch nichts geholfen, was gegen die Batterie-These spricht..
AFAIR so etwa ab 6 tps kam nur noch Busy..
Hab jetzt mal aufgeschraubt, die Lithium-Batterie hat aber satte 3.24V, für das vermutete Produktionsdatum (Aufdruck S3897) ganz schön ordentlich..
Wenn mal viel Zeit ist werd ich die Teile nochmal in einer kontrollierten Testumgebung ausprobieren, aber sie waren auch aus der Bucht und hätten wenn ich das richtig lese nach gut 12J dann auch ihre Schuldigkeit getan

Makki

[teichsta]

Hallo Zusammen,

hole den Thread mal gerade wieder hoch :-)

- Server: eibd -i -D -s -R -T usb:
- Windows-PC: ETS per KNXnet/IP Routing auf eibd auf den Server
- Linux PC: eibd -i ip:
- Linux PC: vbusmonitor1 ip:localhost

Habe gerade meinen eibd auch mit der Option -R gestartet, weil ich mir davon eine höhere Stabilität mit der Calimero-Lib (Java KNX-Kram) erhoffe. Ich schaffe es aber nicht die Verbindung per ROUTING hinzubekommen. TUNNEL läuft ...

Ich erhalte die Fehlermeldung "invalid routing multicast /192.168.1.100". Die ETS meldet "Failed to open driver". Ist die Multicast-Adresse eine andere, als die des Servers auf dem der eibd läuft? Bzw. muss ich meinem Ubuntu-Server irgendwie beibringen, dass er auch auf Multicast-Anfragen reagiert (ist für mich etwas Neuland)?

Danke für jede Hilfe!

[Bodo]

ch erhalte die Fehlermeldung "invalid routing multicast /192.168.1.100".

Hoi

Du musst die Standard Routing Adresse 224.0.23.12 nehmen.
Port 3671 evtl.

[teichsta]

Du musst die Standard Routing Adresse 224.0.23.12 nehmen

das war's ... merci vielmals!!