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

[jonofe]

Hallo zusammen,

ich habe mal probiert, ob es möglich ist über KNXnet/IP Routing mit der ETS über einen eibd, der lokal mit einer KNX-USB-Schnittstelle kommuniziert den KNX anzusprechen:

ETS ---> eibd -D -i -S -R usb: ---> Siemens USB REG ---> KNX

Die ETS 3.0f läuft unter WinXP SP3, der eibd in der aktuellen GIT Version auf einem Fedora 11.

Auf der WinXP Maschine ist die Multicast Route vorhanden. Den Linksys Switch habe ich für Multicast auf "Durchzug" gestellt und der eibd wurde wie o.g. auf dem Linux Server gestartet.

In der ETS habe ich KNXnet/IP Routing konfiguriert auf Port 3671 und die Ethernetschnittstelle ausgewählt.

Die Kommunikation funktioniert insoweit, als dass der Gruppenmonitor funktioniert und auch der Busmonitor/Projekt-Busmonitor, sowie die Gruppenkommunikation (Senden und Lesen von Gruppeadressen). Allerdings ist diese Verbindung nicht stabil. Wenn ich Last auf den Bus gebe, dann ich nach 3000-5000 Telegrammen Schluss. Der eibd Zeit zwar in den Logs, dass er weiterhin läuft und auch die Buskommunikation mitbekommt, aber die ETS gibt auf. Es hilft dann nur noch die Verbindung in der ETS neu zu starten. Was überhaupt nicht funktioniert ist die Kommunikation mit den Geräten, wie z.B.

• Geräteinfo auslesen
• Gerät programmieren

I.d.R. kommt dann der Fehler, dass das Gerät nicht gefunden werden kann. Im Wireshark (auf beiden Seiten) kann ich allerdings beobachten, dass eine Kommunikation stattfindet, allerdings sind meiner Kenntnisse von KNXnet/IP Routing Protokoll nicht ausreichend, um daraus entsprechende Schlüsse abzuleiten.

Hat jemand diese Kombination schon mal erfolgreich ausprobiert?

Übrigens funktioniert bei mir auch die Programmierung über KNXnet/IP Tunneling mit dem eibd nicht zuverlässig. Solche Geräte wie der Gira TS2+ lassen sich nicht programmieren. Gibt es hierzu schon eine Lösung?

[mkoegler]

Die Kommunikation funktioniert insoweit, als dass der Gruppenmonitor funktioniert und auch der Busmonitor/Projekt-Busmonitor, sowie die Gruppenkommunikation (Senden und Lesen von Gruppeadressen). Allerdings ist diese Verbindung nicht stabil. Wenn ich Last auf den Bus gebe, dann ich nach 3000-5000 Telegrammen Schluss. Der eibd Zeit zwar in den Logs, dass er weiterhin läuft und auch die Buskommunikation mitbekommt, aber die ETS gibt auf. Es hilft dann nur noch die Verbindung in der ETS neu zu starten. Was überhaupt nicht funktioniert ist die Kommunikation mit den Geräten, wie z.B.

• Geräteinfo auslesen
• Gerät programmieren

I.d.R. kommt dann der Fehler, dass das Gerät nicht gefunden werden kann. Im Wireshark (auf beiden Seiten) kann ich allerdings beobachten, dass eine Kommunikation stattfindet, allerdings sind meiner Kenntnisse von KNXnet/IP Routing Protokoll nicht ausreichend, um daraus entsprechende Schlüsse abzuleiten.

Hat jemand diese Kombination schon mal erfolgreich ausprobiert?

Übrigens funktioniert bei mir auch die Programmierung über KNXnet/IP Tunneling mit dem eibd nicht zuverlässig. Solche Geräte wie der Gira TS2+ lassen sich nicht programmieren. Gibt es hierzu schon eine Lösung?

Routing ist simpl: Jeder schickt seine Telegram-Daten per Multicast zu allen Kommunikationspartern.
"eibd -i ip: &" "vbusmonitor1 ip:127.0.0.1" auf einen dritten PC könnte man als alternatives Monitoring für KNXnet/IP Routing Netzwerk probieren.
Wenn der EIBD weiterhin KNXnet/IP Routing Telegramme verschickt und nichts mehr von der ETS kommt, dürtfte bei der ETS etwas hängen. Wenn das wirklich der Fall ist, kann wahrscheinlich nur die Konnex helfen.

Bezüglich der Programmierprobleme:
Wenn ich einen Trace (Ausgabe von eibd mit -t1023 in eine Datei umgeleitet) vom Programmiervorgang bekomme, kann ich einmal schauen, ob etwas beim Transfer über den EIBD schief geht.

[jonofe]

Routing ist simpl: Jeder schickt seine Telegram-Daten per Multicast zu allen Kommunikationspartern.
"eibd -i ip: &" "vbusmonitor1 ip:127.0.0.1" auf einen dritten PC könnte man als alternatives Monitoring für KNXnet/IP Routing Netzwerk probieren.

Das hab ich mal gemacht.
Ich habe also:

eibd -i ip

auf dem 3. PC gestartet und kann auf demselben PC auch mit

groupswrite ip:localhost x/y/z <value>

erfolgreichen mit dem KNX komunizieren (per KNXnet/IP Routing) zum eibd auf meinem Linux Server.

Allerdings bleibt das vbusmonitor ip:localhost völlig stumm. Sollte dort nicht der gesammte KNX Traffic erscheinen?

Per Wireshark hab ich auf dem Server geprüft, dass multicas gesendet und auch vom 3. PC empfangen werden. Aber irgendwas stört scheinbar die Multicast Pakete vom Server zum PC. Oder? Woran kann das liegen?
Auf dem ETS PC habe ich ja zumindest für eine gewisse Zeit die Gruppenkommunikation gesehen. Muss ich auf dem Linux-PC noch irgendetwas einstellen, damit er Multicast Pakete verarbeitet. In den Logs erscheinen keine Fehlermeldungen.

Das mit der Aufzeichnung einer Programmierung werden ich morgen machen und dann posten oder per email zusenden.

[mkoegler]

Allerdings bleibt das vbusmonitor ip:localhost völlig stumm. Sollte dort nicht der gesammte KNX Traffic erscheinen?

Per Wireshark hab ich auf dem Server geprüft, dass multicas gesendet und auch vom 3. PC empfangen werden. Aber irgendwas stört scheinbar die Multicast Pakete vom Server zum PC. Oder? Woran kann das liegen?
Auf dem ETS PC habe ich ja zumindest für eine gewisse Zeit die Gruppenkommunikation gesehen. Muss ich auf dem Linux-PC noch irgendetwas einstellen, damit er Multicast Pakete verarbeitet. In den Logs erscheinen keine Fehlermeldungen.

Meine erste Vermutung wäre, das eine Firewall am 3. PC aktiv ist.

[jonofe]

Bingo! Obwohl mir das iptables-init-Skript gesagt hatte, dass der Service gestopptsein, waren noch Regeln aktiv. Nach dem löschen aller FW-Regeln, funktioniert nun der vbusmonitor1 über KNXnet/IP-Routing.
Ich gebe jetzt gerade mal mit

while [ 1 ]; do usleep 100000;groupread ip:localhost 1/1/31; done

ein wenig Last auf den Bus. (20 Telegramme/Sekunde).

Scheint sehr stabil zu laufen. Ich werde jetzt mal parallel die ETS mit einklinken und schauen, ob der Gruppenmonitor wieder aussteigt während der vbusmonitor weiterläuft.

Ich werde dann danach das Programmierproblem mal reproduzieren und ein LOG dazu aufzeichen. Ich werde sowohl für die KNXnet/IP-Tunneling als auch für die KNXnet/IP-Routing Verbindung machen.

[jonofe]

Wie ich es vermutet habe, steigt der Busmonitor der ETS dann irgendwann aus. Jetzt waren es 10700 Telegramme. Ein einfaches STOP und dann wieder START klicken im Busmonitor der ETS lässt ihn dann wieder weiterlaufen.

Der vbusmonitor1 hingegen läuft problemlos weiter.

Warum erscheinen eigentlich die Telegramme, die ich über den vbusmonitor1 sende zweimal im Busmonitor, einmal mit Routingzähler 7 und einmal mit 5?

LPDU: BC 00 01 09 1F F1 00 00 A5 :L_Data low from 0.0.1 to 1/1/31 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
LPDU: BC 00 01 09 1F D1 00 00 85 :L_Data low from 0.0.1 to 1/1/31 hops: 05 T_DATA_XXX_REQ A_GroupValue_Read
LPDU: BC 01 0B 09 1F D1 00 41 CF :L_Data low from 0.1.11 to 1/1/31 hops: 05 T_DATA_XXX_REQ A_GroupValue_Response (small) 01

Dies gilt sowohl für den Busmonitor der ETS als auch für den vbusmonitor1, von dem das Log hier stammt.

[mkoegler]

Warum erscheinen eigentlich die Telegramme, die ich über den vbusmonitor1 sende zweimal im Busmonitor, einmal mit Routingzähler 7 und einmal mit 5?

Dies gilt sowohl für den Busmonitor der ETS als auch für den vbusmonitor1, von dem das Log hier stammt.

Mich irritiert der Satz, das es auch für den Busmonitor der ETS gilt.
Wenns nur der vbusmonitor1 wäre, hätte ich eine Theorie.
Womit ist die ETS verbunden?

Ich müßte das nächste Wochen einmal nachstellen - alternativ würde mir ein -t1023 Output von den beiden EIBDs auch weiter helfen.

[makki]

Bzgl. Bus/Gruppenmonitor: der in der ETS kachelt - soweit zumindest meine Erfahrung mit KNXnet/IP Routing - halt einfach definitiv ohne Not irgendwann zwischen 0,5 bis max 72h ab.
Vielleicht ein Feature (die Konnex sieht jedenfalls auf Anfrage keinen Bug), der eibd sendet definitiv weiter. Da fällt mir zur ETS nur ein: the lights are on but nobody's home upstairs

Makki

[jonofe]

Mich irritiert der Satz, das es auch für den Busmonitor der ETS gilt.
Wenns nur der vbusmonitor1 wäre, hätte ich eine Theorie.
Womit ist die ETS verbunden?

Ich müßte das nächste Wochen einmal nachstellen - alternativ würde mir ein -t1023 Output von den beiden EIBDs auch weiter helfen.

Die ETS und der vbusmonitor1 sind mit dem zentralen eibd verbunden, der direkt über eine usb-Schnittstelle auf den KNX zugreift, also so:

- 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

Ich habe allerdings noch folgendes bei meinen Aufzeichnungen festgestellt:

Wenn ich den eibd starte und mit <Strg-C> beende, erhalte ich jedes mal ein Segmentation Fault. Dies passiert aber nur beim beenden.

Ich habe pth und eibd aus dem GIT. Beides habe ich mit --prefix=/opt/eibd kompiliert. /opt/eibd/lib habe ich dann in die /etc/ld.so.conf/pthsem.conf eingetragen.

ldd /opt/eibd/bin/eibd

ergibt dann:

ldd /opt/eibd/bin/eibd
        linux-gate.so.1 =>  (0xffffe000)
        libpthsem.so.20 => /opt/eibd/lib/libpthsem.so.20 (0xb7f30000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4df05000)
        libm.so.6 => /lib/libm.so.6 (0x48b41000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4ded8000)
        libc.so.6 => /lib/libc.so.6 (0x489c7000)
        /lib/ld-linux.so.2 (0x489a3000)

Ich werde jetzt mal die Logs schreiben für das Programmierproblem.

[jonofe]

Im Anhang die Logs bzgl. der doppelten Telegramme im vbusmonitor1 und Busmonitor der ETS. Diese erscheinen jeweils mit Routingzähler 05 und 07.

Es handelt sich dabei ausschließlich um die Telegramme, welche ich auf dem eibd Client lossende, d.h. die READ_VALUE_REQ Telegramme. Die Antworten kommen nur einmal mit Routingzähler 05.

[jonofe]

Und hier nun die Logs bzgl. der nicht reproduzierbaren Ergebnisse beim Programmieren über Tunneling eines einfachen Geräts.

- Siemens AP Taster

Manchmal ist dei Programmierung erfolgreich und manchmal erfolgt nach ca. 80-90% der Programmierung der Fehler "Gerät antwortet nicht".

Es ein jeweils ein Logfile für den erfolgreichen Fall und für den Fehlerfall angehängt.

Bei komplexen Geräten wie dem TS2+ von Gira gibt es immer eine Fehlermeldung. Allerdings kommt diese dann aus dem Plugin und im ETS Fortschrittfenster erscheint dann "Unbekannter Fehler". Wären diese Logs auch noch interessant?

Übrigens: Wenn ich den eibd neu starte, dann muss ich die ETS danach schließen und wieder neu öffnen, ansonsten kann sie mit dem neu gestarteten eibd nicht kommunizieren. Ist das normal? Oder ein BUG in der ETS?

[jonofe]

Und hier noch mal das eibd Log für eine Programmierung des Siemens AP Tasters über Routing. Egal welches Gerät ich versuche zu programmieren, es scheitert schon bei der Verbindung zum Gerät. Der ETS Fehler ist dann:

Das Gerät mit der phys. Adresse x.y.z kann nicht gefunden werden.

Im konkreten Fall des angehängten Logs ist es die Adresse 0.1.101.

Beim Routing will ich nicht ausschließen, dass es noch ein Problem bei mir im Netz gibt, aber zumindest der Gruppenmonitor und der Busmonitor funktionieren ja zeitweise über Routing.

[mkoegler]

Erst einmal danke für die Logs. Mir ist jetzt klar, was schief geht (eibd am Server schickt die Nachricht aus KNXnet/IP Routing noch einmal ins KNXnet/IP Routing Netzwerk). Die Korrektur von den Problem wird etwas dauern, da es komplizierter ist.

Wenn ich den eibd starte und mit <Strg-C> beende, erhalte ich jedes mal ein Segmentation Fault. Dies passiert aber nur beim beenden.

Ich habe das Problem noch nie gesehen (sowohl pu als auch master branch).

Zur Eingrenzung:

- "gdb eibd"
- "run <eibd parameter>"
[tun, was man sonst im Betrieb tut]
- <Strg-C>
- "signal SIGINT"
Entwerder beendet sich der EIBD jetzt ohne Fehler oder es kommt die Melung über einen Segmentation fault. Dann bitte "bt" ausführen.

[mkoegler]

Und hier noch mal das eibd Log für eine Programmierung des Siemens AP Tasters über Routing. Egal welches Gerät ich versuche zu programmieren, es scheitert schon bei der Verbindung zum Gerät. Der ETS Fehler ist dann:

Das Gerät mit der phys. Adresse x.y.z kann nicht gefunden werden.

Im konkreten Fall des angehängten Logs ist es die Adresse 0.1.101.

In dem Fall ist der EIBD Schuld. Das NAT für Routing ist unvollständig/fehlerhaft implementiert (Korrektur wird ziemlich kompliziert werden).

Workaround: Gibt der ETS die Addresse 0.0.0, dann sollte es funktionieren.

[mkoegler]

Und hier nun die Logs bzgl. der nicht reproduzierbaren Ergebnisse beim Programmieren über Tunneling eines einfachen Geräts.

- Siemens AP Taster

Manchmal ist dei Programmierung erfolgreich und manchmal erfolgt nach ca. 80-90% der Programmierung der Fehler "Gerät antwortet nicht".

Es ein jeweils ein Logfile für den erfolgreichen Fall und für den Fehlerfall angehängt.

Bei komplexen Geräten wie dem TS2+ von Gira gibt es immer eine Fehlermeldung. Allerdings kommt diese dann aus dem Plugin und im ETS Fortschrittfenster erscheint dann "Unbekannter Fehler". Wären diese Logs auch noch interessant?

Über sie Schnittstelle kommt im Fehlerfall ein Packet mit "unbekannten" Inhalt: "Unknown TPDU: 9D", das auch an die ETS weitergeleitet wird.
Das dürfte die ETS aus den Tritt bringen. Ich kann es nicht mit der KNX Spezifikation erklären.

Im Prinzip gibt es zwei Möglichkeiten:
* Die Schnittstelle generiert es
* Das programmierte Gerät generiert es

Wenn es eine zweite Busschnittstelle gibt, würde ich einen zweiten EIBD darüber auf den Bus hängen und mit den busmonitor1 das Programmieren parallel mitschneiden.

Bei einen Abbruch sollte beim EIBD über die USB Schnittstelle (Typ?) das "Unknown TPDU: 9D" auftauchen. Wenn es gleichzeitig im Busmonitor auftaucht, dann macht das Gerät Problem, sonst die Schnittstelle.
Für weitere Analysen müßte ich die beiden Logs eines fehlerhaften Programmiervorgangs analysieren.

Übrigens: Wenn ich den eibd neu starte, dann muss ich die ETS danach schließen und wieder neu öffnen, ansonsten kann sie mit dem neu gestarteten eibd nicht kommunizieren. Ist das normal? Oder ein BUG in der ETS?

Dürfte eher ein ETS Bug sein. Auf bcusdk-list gab es auch einmal einen ähnlichen Fall, wo der Falcon (=KNX Stack der ETS) den Restart vom EIBD nicht verarbeiten konnte. Im Prinzip ist das bei einen echten KNXnet/IP Router ja ein Sonderfall (wer dreht ab/auf, während die ETS daran hängt) und dürfte daher nicht viel Aufmerksamkeit bekommen haben. Im Trace vonseinerzeit war nichts zu erkennen, wo man auf EIBD Seite her hätte nachbessern können - die ETS wollte einfach nicht mehr.