knxd (0.14) an sich läuft.. aber ETS will nicht

[Brick]

Hat hier keine eine Idee dazu ?? noch irgendwelche Logs ?

Gruß Martin

[speedy2day]

Hallo zusammen,

ich habe leider keine Lösung, aber genau das gleiche Problem: Ich kann mit der ETS (v5.6.1) die Geräte am Bus nicht parametrieren und auch keine physikalischen Adressen setzen.

Hier ein paar Daten zu meinem System:
Hardware: Raspberry Pi 2 Model B
OS: Raspbian Stretch Lite (29.11.2017)
Kernel: 4.9.59+
knxd-Version: 0.14.19-2
TPUART-Hardware: Siemens 5WG1 117-2AB12 (per Digital-Isolator ADUM1201 an UART des RPi)

Ich hab die systemd-services erst mal disabled, so dass kein Autostart mehr erfolgt und starte den knxd dann manuell über folgenden Aufruf:

sudo knxd -t 1023 -e 1.1.124 -E 1.1.125:10 -b tpuarts:/dev/ttyKNX1 -D -T -R -S -u -i

Die ETS5 findet sowohl eine IP-Routing-Schnittstelle (IP: 224.0.23.12) als auch eine IP-Tunneling-Schnittstelle (IP:192.168.178.30:3671).
Egal welche Schnittstelle ich auswähle, das Parametrieren hängt immer mit der Meldung "Bitte Parametrierknopf drücken" (obwohl ich natürlich den Parametrierknopf gedrückt habe).

Der Log macht zu dieser Zeit folgendes:

Layer 0 [10:server/Server       85.092] Recv(021): 06 10 04 20 00 15 04 01 1A 00 11 00 B0 E0 00 00 00 00 01 01 00
Layer 8 [31:tunnel/1.1.126      85.092] TUNNEL_REQ
Layer 8 [30:tunnel/ConnC        85.093] found addr 1.1.126
Layer 1 [10:server/Server       85.093] Send(004): 04 01 1A 00
Layer 6 [21:router/ConnC        85.093] sending, send_more clear
Layer 1 [10:server/Server       85.093] Send(011): 29 00 B0 D0 11 7E 00 00 01 01 00
Layer 2 [23:router.pace_/router 85.093] out 1/2: delay for 0.017 sec
Layer 6 [ 4:A.tpuarts/Conn      85.093] sending, send_more clear
Layer 0 [ 7:A.tpuarts/log       85.093] Send L_Data system from 1.1.126 to 0/0/0 hops: 05 T_DATA_XXX_REQ A_IndividualAddress_Read
Layer 0 [ 9:A.tpuarts/log       85.093] Send(018): 80 B0 81 11 82 7E 83 00 84 00 85 D1 86 01 87 00 48 F0
Layer 6 [30:tunnel/ConnC        85.094] is OK
Layer 6 [21:router/ConnC        85.094] still waiting
Layer 6 [ 1:main                85.094] wait L
Layer 1 [10:server/Server       85.095] Send(015): 04 01 1A 00 2E 00 B0 E0 00 00 00 00 01 01 00
Layer 0 [10:server/Server       85.095] Send(010): 06 10 04 21 00 0A 04 01 1A 00
Layer 0 [10:server/Server       85.095] Send(017): 06 10 05 30 00 11 29 00 B0 D0 11 7E 00 00 01 01 00
Layer 0 [10:server/Server       85.096] Dropped(017): 06 10 05 30 00 11 29 00 B0 D0 11 7E 00 00 01 01 00
Layer 0 [10:server/Server       85.096] Send(021): 06 10 04 20 00 15 04 01 1A 00 2E 00 B0 E0 00 00 00 00 01 01 00
Layer 0 [10:server/Server       85.099] Recv(010): 06 10 04 21 00 0A 04 01 1A 00
Layer 8 [31:tunnel/1.1.126      85.099] TUNNEL_ACK
Layer 2 [23:router.pace_/router 85.110] delay done
Layer 6 [21:router/ConnC        85.110] sendNext called, send_more set
Layer 6 [30:tunnel/ConnC        85.110] is OK
Layer 6 [21:router/ConnC        85.110] is OK
Layer 6 [10:server/Server       85.110] is OK
Layer 6 [ 4:A.tpuarts/Conn      85.110] still waiting
Layer 0 [ 9:A.tpuarts/log       85.116] Recv(008): B0 11 7E 00 00 D1 01 00
Layer 8 [ 6:A.tpuarts/LowF      85.116] state: wait > wait_more
Layer 0 [ 9:A.tpuarts/log       85.119] Recv(001): F0
Layer 8 [ 6:A.tpuarts/LowF      85.119] state: wait_more > wait
Layer 0 [ 9:A.tpuarts/log       85.121] Recv(001): 8B
Layer 0 [ 7:A.tpuarts/log       85.122] send_Next
Layer 6 [ 4:A.tpuarts/Conn      85.122] sendNext called, send_more set
Layer 6 [30:tunnel/ConnC        85.122] is OK
Layer 6 [21:router/ConnC        85.122] is OK
Layer 6 [10:server/Server       85.122] is OK
Layer 6 [ 4:A.tpuarts/Conn      85.122] is OK
Layer 6 [15:B.unix/local        85.122] is OK
Layer 6 [18:C.tcp/inet          85.123] is OK
Layer 6 [ 1:main                85.123] OK
Layer 6 [ 2:main/L              85.123] OK L
Layer 0 [ 9:A.tpuarts/log       85.160] Recv(008): B0 11 7E 00 00 E1 01 40
Layer 8 [ 6:A.tpuarts/LowF      85.160] state: wait > wait_more
Layer 0 [ 7:A.tpuarts/log       85.160] Known Addr 0/0/0: yes
Layer 0 [ 6:A.tpuarts/LowF      85.160] SendAck 11
Layer 0 [ 9:A.tpuarts/log       85.160] Send(001): 11
Layer 0 [ 9:A.tpuarts/log       85.163] Recv(001): 80
Layer 1 [ 6:A.tpuarts/LowF      85.163] RecvLP(009): B0 11 7E 00 00 E1 01 40 80
Layer 0 [ 7:A.tpuarts/log       85.163] Recv L_Data system from 1.1.126 to 0/0/0 hops: 06 T_DATA_XXX_REQA_IndividualAddress_Response
Layer 8 [30:tunnel/ConnC        85.163] found addr 1.1.126
Layer 3 [ 4:A.tpuarts/Conn      85.164] Packet not from 30:tunnel: L_Data system from 1.1.126 to 0/0/0 hops: 06 T_DATA_XXX_REQA_IndividualAddress_Response
Layer 8 [ 6:A.tpuarts/LowF      85.164] state: wait_more > wait

Bei manchen Versuchen sehe ich auch die Zeile

Layer 8 [ 1:main                87.559] unknown addr 1.1.126

Obwohl der Aktor den ich parametrieren möchte, die 1.1.128 bekommen soll und die ETS5 mir als ihre Adresse 1.1.127 angibt. Keine Ahnung, warum hier immer die 1.1.126 steht.

Hier mal noch meine Ausgabe von sudo netstat -anp | grep knxd. Müsste da nicht ne lokale IP drin stehen?

tcp        0      0 0.0.0.0:6720            0.0.0.0:*               LISTEN      1863/knxd
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           1863/knxd
unix  2      [ ACC ]     STREAM     HÖRT         15950    1863/knxd            /run/knx

Wenn die Profis zur Analyse mehr Daten benötigen, versuche ich gerne, die zu generieren...

Vielen Dank an dieser Stelle schon mal für die viele Arbeit, die in so ein Projekt wie knxd fließt (Coding und Support)!

Gruß, Sebastian

[speedy2day]

Hallo nochmal,

nachdem ich in diesem Thread gelesen habe, dass es mit der v0.11.18 klappen könnte, hab ich mir diese Version des knxd mal installiert.

Und siehe da, hiermit klappt das Programmieren der Adresse und der Applikation, wenn ich in der ETS die IP-Routing-Schnittstelle nutze.
Kurz mal mit "sudo knxtool on local:/run/knx 1.1.128" den Test gemacht und der Aktor schaltet tatsächlich ein und aus.

Auf lange Sicht sollte die aktuelle Version natürlich auch funktionieren... Also wenn ich was testen soll, gerne melden.

Gruß, Sebastian

[Tru]

Auf lange Sicht sollte die aktuelle Version natürlich auch funktionieren... Also wenn ich was testen soll, gerne melden.
Gruß, Sebastian

Ich muss zuerst sagen, dass ich im Thema nicht ganz sattelfest bin und auch gar keine ETS besitze um das selbst zu überprüfen. Aber es ist zuerst mal zu sagen, dass es fundamentale Erweiterungen in der aktuellen Version gegenüber v0.11 gibt, die es natürlich zu berücksichtigen gibt.

Wenn ich es richtig in Erinnerung habe, übernahm der alte knxd für jeden seiner IP-Clients am Bus einfach seine eigene physikalische Adresse - also quasi ein NAT für die physikalischen Adressen aller IP-Clients hinter seiner eigenen physikalischen Adresse. Wenn die ETS so über den knxd mit dem Bus kommuniziert, sieht der Bus die ETS somit als den knxd und antwortet dort hin und der knxd schickt es weiter an seinen IP-Client sprich ETS.

Da wird die Begrenzung klar: es ist so nur möglich einen einzigen IP-Client korrekt bedienen zu können. Deshalb nach meinem Verständnis die Erweiterung in den neuen knxd-Versionen. Da gibt man mit -E an, welche physikalischen Adressen der knxd an seine IP-Clients flexibel und dynamisch zuteilen darf. Und diese Adressen dürfen natürlich am Bus nicht besetzt sein. Und da glaube ich machst du in deinem Beispiel einen entscheidenden Fehler: die Adresse 1.1.128 gehört jetzt dem knxd für einen IP-Client, da kannst du nicht ein Gerät damit programmieren - denn die knxd-Adressen dürfen sich mit Geräten natürlich nicht überlappen.

Ich glaube mich auch wage erinnern zu können, dass ich mal aufgeschnappt habe, dass die ETS nicht damit umgehen kann, dass sie vom knxd eine physikalische Adresse dynamisch zugewiesen bekommt und sich diese von Request zu Request möglicherweise noch ändert. Das sollte irgendwie mit dem Paramater single eingeschränkt werden können.

Man möge mich gerne korrigieren, wenn ich mich täusche.

[speedy2day]

Hallo Tru ,

vielen Dank für deine Hinweise. Das macht natürlich Sinn mit der Adresse! Ich war bisher immer davon augegangen, ich müsste die Adresse des Aktors (oder eines anderen KNX/TP-Teilnehmers) gerade genau so wählen, dass sie im Bereich des -E Parameters liegt.

Aber es macht ja Sinn, dass der knxd den KNXnet/IP-Teilnehmern (die sich ja per TCP oder UDP verbinden) aus diesem Pool eine Adresse vergibt um auch vom TP-Medium aus angesprochen werden zu können.

Vielleicht liegt ja da schon das Problem und ich komme so mit der knxd Version v0.14.19-2 weiter. Werde es morgen mal probieren.

Gruß, Sebastian

[speedy2day]

Es scheint tatsächlich so, als wäre mein Problem gelöst.
Nachdem ich jetzt wieder auf Version v0.14.19-2 umgestiegen bin, und dem Aktor eine Adresse außerhalb des im Parameter "-E" für den knxd zur Verfügung gestellen Adressbereiches zugewiesen habe (habe für den Aktor jetzt die 1.1.2 verwendet), lässt dieser sich per ETS sowohl die physikalische Adresse als auch die Applikation aufspielen.

Vielen Dank Tru für den Hinweis!

Brick : Wenn ich das richtig sehe, hast du ja versucht, eine Adresse 1.2.xxx zu programmieren, also ein Gerät aus einer anderen Linie. Evtl. gibt es hier ein ähnliches Problem und die Adresse deines Gerätes muss mit 1.1.xxx starten!? Wenn du einen Linienkoppler einsetz, könnten vielleicht auch dort gesetze Filter das Problem sein...
Viel Erfolg beim Weitertesten, und nicht aufgeben! ;-)

[Brick]

Hi speedy2day .. ich hab gar keinen Linienkoppler...
Es geht ja schon los, das ich nicht mal den Busmonitor abfragen kann, wenn ich nur auf KNXnet/IP einstelle.. zum Programmieren
komm ich da ja eigentlich erst gar nicht.. wenn ich auf KNXnet/IP mit Routing einstelle dann geht zwar der Busmonitor... aber hier
findet er eben keine Geräte... kann das gern mal probiern, ob er da welche aus der gleichen Linie findet.. moment.. habs grad probiert..
Gerät mit 1.1.10 hat er nicht gefunden..

Jemand noch eine andere Idee ? oder ein Log das ich noch anlegen kann ?

[Brick]

Soo... gerade noch mal einen Versuch gemacht.. ham mal KNXD 11.18 installiert... hmm. was soll ich sagen..
Die ETS funktioniert mir ihr wieder.. .leider zickt dann EDOMI rum (langsam, ständig Read Requests, best.
GA's lassen sich nicht ansprechen usw.) ... und da mir das schon eher wichtiger ist,
läuft halt jetzt wieder der EIBD...

wenn das so weiter geht, komm ich wohl um einen Hardwarerouter nicht rum..

Gruß Martin

[Smurf]

wenn das so weiter geht, komm ich wohl um einen Hardwarerouter nicht rum..

Oder um einen Smurf, der endlich mal Zeit hat, ein paar knxd-Bugs nachzujagen. :-/

[Brick]

Also Smurf, ich kann dir gern behilflich sein, bezüglich tests und logs... grundsätzlich eilt es nicht,
also wenn du dich da dran setzen willst (wenn du Zeit hast) meld dich einfach.. ich hab die
Versionen 11.18 und 14.19 noch als VM laufen.. da kann ich jederzeit umschalten ..

Gruß Martin