Schaltverzögerung Weinzierl 730

[schuma]

Ich kann auch mit KNXD im Netzwerk über die ETS keine Physikalischen Adressen mehr vergeben.
Habe ich gestern festgestellt nachdem ein neuer Aktor einziehen sollte.

Wenn ich den Pi mit KNXD abziehe, kann ich wieder die Adressen schreiben.

Könnte das was mit der Sache zu tun haben? Ich meine das da evtl. mehr im Argen ist?


Edit: Das hat sich erledigt. War wohl nur temporär so...

[fuxl66]

Vielleicht hat Smurf eine Idee woher dieses Verhalten kommen könnte?!

[fuxl66]

Dieses Problem hab ich aber nur wenn ich send-delay verwende. Ohne tritt das Problem erst gar nicht auf.....
ich glaub ich muss mal ein andres Interface testen.

[schuma]

Ok, das hat dann aber nichts mit dem Send-delay zu tun.
30mSek sind ja nicht so lange...

Ich habe da 70mSek stehen und das Funktioniert einwandfrei (Klickgeschwindigkeit)
Nur hier geht es um ein Problem, das nach längerem nicht nutzen, beim ersten Klick das Schalten verzögert ist. Das habe ich auch so.
Es fühlt sich an, als ob das System aus einem Standby wieder aufwacht und dann schaltet. Danach ist alles wieder normal.

[fuxl66]

Das sind zwei verschiedene Dinge!
Was anderes ist es, wenn man auf eine Taste drückt (ein Signal) und es passiert erstmal nichts.

ich verwende den conf Eintrag mit einem --send-delay. Es klappt wie erwartet beim ersten Signal, aber es passiert nichts (deutlich verzögert) beim zweiten Signal.

[schuma]

Das sind zwei verschiedene Dinge!
Wenn man Signale mit einer Verzögerung von 30mSek sendet ist es klar, dass das Hundertste Signal ein paar Sekunden später rausgeht.
Das sollte aber in real kein Problem darstellen.
Was anderes ist es, wenn man auf eine Taste drückt (ein Signal) und es passiert erstmal nichts.
Und das ist jetzt wohl mit dem alten Config Eintrag behoben.
Die Frage die sich jetzt stellt, kann sich das jemand erklären warum es mit dem Ini Eintrag nicht so richtig klappt?

[fuxl66]

Bei mir klappt es ebenfalls mit deinem Eintrag. Das normale schalten klappt ohne jegliche Verzögerung, jedoch werden bei diversen Logiken mit vielen Schaltvorgängen in Serie viele Telegramme verschluckt.
Deshalb gibt es, meiner Meinung nach den Eintrag "--send-delay=30" sobald ich diesen verwende kommt es zum beschriebenen Verhalten, dafür werden aber keine Telegramme verschluckt.
Hat jemand eine Lösung dafür bzw. ein Interface, dass kein --send-delay benötigt?
Boomer55 hast du keine Problem mit Logiken und verschluckten Telegrammen?

[Boomer55]

Hallo zusammen.

Bei mir ist es in der Tat so, dass seit oben beschriebener Umstellung gestern alles wieder funktioniert wie es soll.

Schöne Grüsse,
Markus

[Boomer55]

Mal ne blöde Frage:
Kann es eventuell mit der Konfiguration über die neue "knxd.ini" zusammenhängen? Hab jetzt mal auf die ursprüngliche " knxd.conf" mit folgendem Eintrag "KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -b ipt:XXX.XXX.XXX.XX" umgestellt und bisher läufts wieder... mal schauen, wie lange ;-)

[Boomer55]

Hallo.

Weinzierl Linemaster 760 und MDT SCN-IP000.02.
Mit beiden getestet und bei beiden das selbe Verhalten.

Beste Grüsse,
Markus

[fuxl66]

Boomer55 welches Interface verwendes du?

P.S.: Hast du beim NUC auch ein --send-delay in Verwendung? Ohne funktioniert es nämlich bei mir auch aber dann werden Telegramme verschluckt.

[Boomer55]

Hallo.

Werde bei mir Groupswrite in dem Fall auch als nächstes mal testen und morgen Bescheid geben.
Am Interface kann es auf jeden Fall nicht liegen, da auf meinem NUC und selben Interface alles normal funktioniert.

Beste Grüsse,
Markus

[fuxl66]

An SmartVISU liegt es aber scheinbar nicht denn mit knxtool groupswrite ip:localhost 1/0/170 1 lässt sich dieses Verhalten genauso nachstellen.
Ich bin jedenfalls ratlos was ich noch machen soll. Warum haben dieses Problem nur einige wenige?

[Boomer55]

Gleiches Verhalten bei mir auf Raspberry 2 mit Image von Onkelandy. Hab jetzt parallel nen Intel NUK aufgesetzt und dort funktioniert alles mit SmarthomeNG 1.3, SmartVISU 2.8 und knxd 0.14 - bin daher nicht sicher, ob es wirklich an knxd liegt, da Daten vom Bus normal zurückkommen...

[fuxl66]

hab jetzt auch das Image von Onkelandy --> Image getestet.
Folgende knxd.ini

[B.ipt]
driver = ipt
filters = C.pace
ip-address = 192.168.0.23
[C.pace]
delay = 30
filter = pace
[main]
addr = 1.1.75
client-addrs=1.1.76:8
cache = D.cache
connections = B.ipt
systemd = systemd
background = true

Exat gleiches Verhalten. Erster Schaltvorgang sofort, zweiter deutlich verzögert.
Und das bei jedem ersten Schaltvorgang nach ca. 2min Pause.

Liegt es am Interface?