Programmieren mit ETS5 und knxd 0.14.18 geht nicht?

[Morg]

Hallo,

ich habe seit einiger Zeit den knxd 0.14.18 laufen und musste jetzt zum ersten Mal Geräte programmieren. Ich werde aus dem Verhalten nicht ganz schlau bzw. tue mich schwer, den Fehler einzugrenzen.

ETS sagt mir, dass die Medientypen des aktuellen Subnetzes (IP) und der aktuellen Linie (TP) nicht übereinstimmen. Das kann ich ignorieren oder ändern (ich wüsste aber nicht, wie ich das ändern soll. Die Linie muss ja TP bleiben, und das aktuelle Subnetz ist über den knxd definiert...?)

Dann bekomme ich keinen Fortschritt angezeigt und nach ein paar Sekunden bricht die Programmierung ab mit dem Hinweis, dass das Gerät nicht in angemessener Zeit geantwortet habe.

Wenn ich den knxd beende und per ETS direkt das IP-Interface anspreche, geht es problemlos.

Das Interface ist ein MDT SCN-IP000.01.

Muss ich das der aktuellen knxd-Version zurechnen (ergo derzeit keine Abhilfe) oder mache ich mit der ETS ggf. etwas falsch?

Der Versuch, knxd master (wie im Wiki beschrieben) oder stable (wie hier im Forum beschrieben) auf dem RasPi zu kompilieren, scheitert mit verschiedenen Meldungen in libfmt, ein make bzw. make clean && make im libfmt-Ordner schlägt mit wieder anderen Meldungen fehl. Details bei Bedarf.

[Nachtrag] - Busmonitor und Gruppenmonitor gehen per ETS über den knxd.

[Morg]

Nachdem ich jetzt das Problem mit der libfmt behoben bzw. umgangen habe und die aktuelle Version 0.14.24-3 aus dem master-Zweig läuft, hat sich nichts geändert - es geht "alles" (Betrieb über sh.py / knxd / IP-Interface, Busmonitor, Gruppenmonitor) bis auf Programmieren.

Hilft dieser Log-Auszug ggf? (wird mehrfach wiederholt, dann Timeout)

Layer 0 [ 6:server/Server        167.047] Recv(021): 06 10 04 20 00 15 04 01 09 00 11 00 B0 60 00 00 11 11 01 43 00
Layer 2 [20:router.pace_/router  167.047] out 1/2: delay for 0.017 sec
Layer 0 [ 6:server/Server        167.048] Send(010): 06 10 04 21 00 0A 04 01 09 00
Layer 0 [ 6:server/Server        167.048] Send(017): 06 10 05 30 00 11 29 00 B0 50 00 07 11 11 01 43 00
Layer 0 [ 6:server/Server        167.049] Dropped(017): 06 10 05 30 00 11 29 00 B0 50 00 07 11 11 01 43 00
Layer 0 [ 6:server/Server        167.049] Send(021): 06 10 04 20 00 15 04 01 09 00 2E 00 B0 60 00 00 11 11 01 43 00
Layer 0 [ 6:server/Server        167.056] Recv(010): 06 10 04 21 00 0A 04 01 09 00
Layer 2 [20:router.pace_/router  167.064] delay done
Layer 0 [ 6:server/Server        170.052] Recv(021): 06 10 04 20 00 15 04 01 0A 00 11 00 B0 60 00 00 11 11 01 43 00
Layer 2 [20:router.pace_/router  170.052] out 1/2: delay for 0.017 sec
Layer 0 [ 6:server/Server        170.052] Send(010): 06 10 04 21 00 0A 04 01 0A 00
Layer 0 [ 6:server/Server        170.053] Send(017): 06 10 05 30 00 11 29 00 B0 50 00 07 11 11 01 43 00
Layer 0 [ 6:server/Server        170.053] Dropped(017): 06 10 05 30 00 11 29 00 B0 50 00 07 11 11 01 43 00
Layer 0 [ 6:server/Server        170.053] Send(021): 06 10 04 20 00 15 04 01 0A 00 2E 00 B0 60 00 00 11 11 01 43 00
Layer 0 [ 6:server/Server        170.060] Recv(010): 06 10 04 21 00 0A 04 01 0A 00
Layer 2 [20:router.pace_/router  170.069] delay done
Layer 0 [ 6:server/Server        173.067] Recv(020): 06 10 04 20 00 14 04 01 0B 00 11 00 B0 60 00 00 11 11 00 81
Layer 2 [20:router.pace_/router  173.067] out 1/1: delay for 0.016 sec
Layer 0 [ 6:server/Server        173.068] Send(010): 06 10 04 21 00 0A 04 01 0B 00
Layer 0 [ 6:server/Server        173.068] Send(016): 06 10 05 30 00 10 29 00 B0 50 00 07 11 11 00 81
Layer 0 [ 6:server/Server        173.069] Dropped(016): 06 10 05 30 00 10 29 00 B0 50 00 07 11 11 00 81
Layer 0 [ 6:server/Server        173.069] Send(020): 06 10 04 20 00 14 04 01 0B 00 2E 00 B0 60 00 00 11 11 00 81
Layer 0 [ 6:server/Server        173.074] Recv(010): 06 10 04 21 00 0A 04 01 0B 00
Layer 0 [ 6:server/Server        173.081] Recv(016): 06 10 02 09 00 10 01 00 08 01 C0 A8 02 0B C7 26
Layer 0 [ 6:server/Server        173.081] Send(008): 06 10 02 0A 00 08 01 00
Layer 2 [20:router.pace_/router  173.084] delay done

[larsrosen]

Ist die PID vom KNXD vorm programmieren und nach dem Programmieren noch die selbe?

Ich kann mit den neueren KNXD gar nicht mehr programmieren, da jedesmal wenn eine Flut an telegrammen kommt( programmieren oder Visu start) der prozess KNXD abstürzt.

[Morg]

Oh, Visu läuft problemlos, und alle paar Minuten schaufelt die Heizung eine Latte an Informationen über den Bus. Beim letzten Test nach Neukompilieren der neuesten Version (s.o.) lief der knxd im Vordergrund, da hätte ich ja gesehen, wenn er abschmiert. Das Log oben ist fast 10x so lang mit denselben Nachrichten, das geht am Stück durch. Also nein, knxd stürzt nicht ab.

Welche Version läuft denn bei dir?

[Smurf]

Befehlszeile bzw. INI-Datei bitte.

[Morg]

In dem Fall hatte ich den knxd mit knxd /etc/knxd.ini gestartet... das System läuft mit systemd; sowohl kndx.service als auch knxd.socket hatte ich vorher gestoppt.

INI-Datei beinhaltet

 [B.tcp]
 server = knxd_tcp
 [C.ipt]
 driver = ipt
 filters = D.pace
 ip-address = 192.168.2.232
 [D.pace]
 delay = 30
 filter = pace
 [debug-server]
 name = mcast:knxd
 trace-mask = 0x5
 [main]
 addr = 0.0.1
 client-addrs = 0.0.2:8
 cache = A.cache
 connections = server,B.tcp,C.ipt
 systemd = systemd
 [server]
 debug = debug-server
 discover = true
 router = router
 server = ets_router
 tunnel = tunnel:w

[Harry01]

Ist zwar schon bisschen älter, aber da ich das selbe Problem hatte:
Hier ist die Lösung:

unter C.ipt muss stehen:
filters = D.pace,single

[pakka]

unter C.ipt muss stehen:
filters = D.pace,single

gilt auch für ip: Verbindung per multicast?
bei mir spuckt der Konverter nur kurz und knapp Folgendes aus:

[A.unix]
path = /tmp/eib
server = knxd_unix
systemd-ignore = false
[B.ip]
driver = ip
[main]
addr = 1.1.1
client-addrs = 1.1.2:8
connections = A.unix,B.ip
systemd = systemd

[Smurf]

Ja, "ip:" macht auch Mutlticast, und zwar (im Gegensatz zu "-RS") "billig" d.h. ohne auf Anfragen bez. Server oder Autodiscovery oder Tunnel etc. zu reagieren.

"single" ist eigentlich nur für "ipt:" sinnvoll. Der Hintergrund: der Server, den man mit "ipt:" ansteuert, vergibt dem knxd eine (physische) Adresse. Der "single"-Filter ersetzt nun beim Senden an diesen Server alle Absenderadressen durch diese. Das ist eigentlich (fast) egal, falls dieser Server nicht aggressiv filtert – wird aber beim Programmieren benötigt, weil da die Antworten auch physisch adressiert sind und ihren Weg zurück finden müssen. (Der Filter setzt dann die Ursprungsadresse wieder ein.)

"single" ist nicht Default, weil der Server auch ein knxd o.Ä. sein könnte, der nicht filtert und sich die verwendeten Adressen unabhängig von der vergebenen Client-Adresse merkt.