Schaltverzögerung Weinzierl 730

[fuxl66]

Hallo,

Ich habe aktuell einen Pi3 mit Raspian Stretch und SH.py 1.3 neu aufgesetzt. Dazu KNXD 0.14.18-1 am Laufen, mit folgendem knxd.conf Eintrag.

KNXD_OPTS="-e 0.0.5 -E 0.0.6:8 -c  --send-delay=30 -b ipt:192.168.0.23"

Grundsätzlich funktioniert die Kommunikation und ich kann auch via SmartVISU schalten.
mit der Option "--send-delay=30" werden auch keine Telegramme verschluckt. Ohne diesen Eintrag ist das der Fall.

Schalte ich allerdings einige Minuten nichts mit der Visu hängt/verzögert sich der Schaltbefehl deutlich (ca. 10-15sek). Schalte ich zb ein Licht gleich im Anschluss wieder ein und sofort wieder aus, klappt das Problemlos.

Es scheint, als ob KNXD in eine Art standby schaltet und beim ersten schalten erst wieder aus dem standby hochgeholt werden muss.
Ist so ein Verhalten bekannt, bzw. wie kann ich dieses Problem lösen?

Hoffe jemand kann mir helfen.

mfg
Markus

[Asterix3]

Hallo Markus,

Das gleiche Phänomen habe ich auch. Konnte allerdings noch nicht herausfinden woran es liegt.

Gruß

Steff

[fuxl66]

Hast du das das selbe Interface wie ich im Einsatz? (Weinzierl 730)

[schuma]

Das gleiche bei mir.
Ist aber ein MDT IP interface 0.1

Auch PI3. Ich hatte dann mal die WLAN/BT ausgeschaltet. Damit wurde es besser ist aber immer noch manchmal vorhanden.

[Asterix3]

Nö, hab ne ABB IPS/S2.1

[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?

[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]

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]

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]

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.

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

Beste 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 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

[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?

[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?