knxd F00000035: Send while buffer not empty

[misa]

Bin zurück gewechselt auf die aktuelle 0.12.x Version. Hier tritt das problem nicht auf.

Weitere Beobachtung unter 0.14.x: Wenn knxd läuft mit knxd -e 0.0.1 -E 0.0.2:8 -i -DTS -b usb:
und ich knxtool vbusmonitor1 ip: verwende, beendet sich knxd, wenn ich das bus-tool verlasse.

[Smurf]

Danke. Der Crash ist in der aktuellen v0.14 behoben.

[JulianGloeckle]

Guten Abend.

ich habe mich nach längerer (Sommer-) Pause auch wieder dran gemacht, das Projekt Smarthome anzugehen.
Mein aktuelles Setup ist ein Raspberry 3B+, per USB mit einer Jung KNX-USB Schnittstelle verbunden.
KNXD hab ich in der Version 0.14.25 installiert.
Homebridge ebenfalls in der aktuellen Version.

Leider bekomme ich ebenfalls den in diesem Thread beschriebenen Fehler mit "Send while buffer not empty".
Reproduzieren kann ich das sehr schnell:

- System starten
- Lampe einschalten über homekit: funktioniert
- Lampe ausschalten: Fehler

Ich muss also nicht mal besonders viele Schaltbefehle in kurzer Zeit machen.
Ich habe versucht, die in diesem Thread empfohlenen Parameter zum logging zu beachten.

Meine aktuelle Config unter /etc/knxd.conf:
KNXD_OPTS="-e 4.0.1 -E 4.0.2:8 -f9 -B log -t1023 -u /tmp/eib -DTRS -b usb:"

ein journalctl -u knxd --since "1 min ago" ergibt folgende Ausgabe:

-- Logs begin at Wed 2018-10-03 09:41:11 CEST, end at Wed 2018-10-24 19:09:33 CEST. --
Oct 24 19:08:42 raspberrypi systemd[1]: knxd.service: Service hold-off time over, scheduling restart.
Oct 24 19:08:42 raspberrypi systemd[1]: Stopped KNX Daemon.
Oct 24 19:08:42 raspberrypi systemd[1]: Starting KNX Daemon...
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 0 [13:log/A.unix       0.000] State setup
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 3 [10:A.unix/local     0.000] registerLink: 10:A.unix
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 3 [10:A.unix/local      0.034] Start: cfg:A.unix
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 5 [10:A.unix/local      0.035] down => >up
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 8 [10:A.unix/local      0.035] OpenLocalSocket /tmp/eib
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 8 [10:A.unix/local      0.035] LocalSocket opened
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 5 [10:A.unix/local      0.035] >up => up
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 4 [10:A.unix/local      0.035] up
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 5 [10:A.unix/local      0.035] Started
Oct 24 19:08:42 raspberrypi knxd[917]: Layer 4 [10:A.unix/local      0.035] up
Oct 24 19:08:42 raspberrypi systemd[1]: Started KNX Daemon.
Oct 24 19:09:29 raspberrypi systemd[1]: Stopping KNX Daemon...
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 4 [10:A.unix/local        46.839] Stopping
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 5 [10:A.unix/local        46.839] up => >down
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 8 [10:A.unix/local        46.840] StopServer
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 5 [10:A.unix/local        46.840] >down => down
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 4 [10:A.unix/local        46.840] down
Oct 24 19:09:29 raspberrypi knxd[917]: Layer 4 [10:A.unix/local        46.840] is down
Oct 24 19:09:29 raspberrypi systemd[1]: Stopped KNX Daemon.
Oct 24 19:09:29 raspberrypi systemd[1]: Starting KNX Daemon...
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 0 [13:log/A.unix       0.000] State setup
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 3 [10:A.unix/local     0.002] registerLink: 10:A.unix
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 3 [10:A.unix/local      0.073] Start: cfg:A.unix
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 5 [10:A.unix/local      0.073] down => >up
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 8 [10:A.unix/local      0.073] OpenLocalSocket /tmp/eib
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 8 [10:A.unix/local      0.073] LocalSocket opened
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 5 [10:A.unix/local      0.073] >up => up
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 4 [10:A.unix/local      0.073] up
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 5 [10:A.unix/local      0.073] Started
Oct 24 19:09:29 raspberrypi knxd[942]: Layer 4 [10:A.unix/local      0.073] up
Oct 24 19:09:29 raspberrypi systemd[1]: Started KNX Daemon.
Oct 24 19:09:33 raspberrypi knxd[942]: F00000035: [22:B.usb] Send while buffer not empty
Oct 24 19:09:33 raspberrypi knxd[942]: F00000000: [19:B.usb] Link down, terminating
Oct 24 19:09:33 raspberrypi knxd[942]: Layer 4 [10:A.unix/local        3.957] Stopping
Oct 24 19:09:33 raspberrypi knxd[942]: Layer 5 [10:A.unix/local        3.957] up => >down
Oct 24 19:09:33 raspberrypi knxd[942]: Layer 8 [10:A.unix/local        3.958] StopServer
Oct 24 19:09:33 raspberrypi knxd[942]: Layer 5 [10:A.unix/local        3.958] >down => down
Oct 24 19:09:33 raspberrypi systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Oct 24 19:09:33 raspberrypi systemd[1]: knxd.service: Unit entered failed state.
Oct 24 19:09:33 raspberrypi systemd[1]: knxd.service: Failed with result 'exit-code'.

Meine Linux-Kenntnisse sind sehr begrenzt. Ich hoffe, dass mir jemand einen Tipp hat wie ich hier weiter komme. Alleine komme ich trotz sehr viel Googlen nicht weiter.

Viele Grüße
Julian

[makki]

Kurztipp: erspare dir die USB-Schnittstelle, die funktionieren nicht wirklich und haben es auch nie (meine Meinung seit Jahren!) und man kann kaputte HW nicht mit SW "reparieren".
Da kann man sich noch 100 Workarounds überlegen, das ist "broken by design".
Meine Empfehlung lautet immernoch TP-UART, so schlecht wie die USB-SS kann der schlechteste USB-Serial-Converter davor nie werden

Makki

[Smurf]

Äh, ja. Damit hast du im Prinzip recht. Trotzdem ist das so ein Bug im knxd, den leider bisher noch keiner gefunden hat, u.A: weil ich ihn nicht reproduzieren kann.

Wenn mich jemand via SSH auf einen Rechner drauflässt, bei dem das auftritt, könnte man was dagegen tun.

[Smurf]

Ich habe versucht, die in diesem Thread empfohlenen Parameter zum logging zu beachten.

Das ist dir nur teilweise gelungen.

Falsch, zumindest in diesem Fall:

-e 4.0.1 -E 4.0.2:8 -f9 -B log -t1023 -u /tmp/eib -DTRS -b usb:

Korrekt:

-e 4.0.1 -E 4.0.2:8 -f9 -u /tmp/eib -DTRS -B log -t1023 -b usb:

Die Idee dahinter ist, dass modifizierende Angaben wie Filter oder Debugflags entweder global sind (sie stehen vor dem '-e'), oder den Treiber beeinflussen vor dem sie stehen. (Ganz an den Schluss kann man sich die via systemd-Socket-Datei übergebenen Kanäle dazudenken.) In deinem Fall willst du beobachten, was auf USB passiert …

[JulianGloeckle]

Danke für die Erläuterung. Das werde ich morgen mal so bei mir ändern und nochmal versuchen.

Zu den vorherigen Beiträgen über die Wahl der Schnittstelle:
Ich hab bereits gelesen, dass die USB Schnittstellen wahrscheinlich so die schlechteste Alternative sind. Da mein Elektriker das aber so verbaut hatte, war es naheliegend, es so zu probieren.
Wenn das nicht erfolgsversprechend ist werde ich wohl die Harware ändern müssen. Da stellt sich dann die Frage ob TP Uart oder ne IP Schnittstelle die bessere Wahl ist.

Aber Smurf, wenn du dich bei mir mal draufschalten willst können wir das gerne machen. Der Fehler lässt sich zuverlässig reproduzieren.

Grüße
Julian

[makki]

Die "Lösung" hatten wir anno Schnuff - vor ca. 8-9J(!) schon gefunden: Limitierung der ausgehenden Telegramm-Rate, damit die unbrauchbare USB-SS nicht - weit unterhalb des zugesicherten Standards! - "überlastet" wird:
Ganz grob AFAIR: 50ms zwischen Telegrammen, also max. 12 tps (es sollte lt. Standard AFAIR 30-50 tps können)
Ich weiss nicht, ob das aktuell noch Bestandteil des knxd-Code ist, wars aber beim eibd mal, hartcodiert bei USB-SS.. Genau deswegen..

Das löst natürlich aber nur das senden, also nur 50% des Problems;
beim empfangen - wenn jemand "frecherweise" Standard-konform schneller sendet, ist die USB-SS wieder im Eimer.

Ich habe damals - aus gutem Grund! und nach monatelangen Tests, die Unterstützung für diese USB-SS aus eibd/knxd schlicht entfernt, weil es m.E. dem Ruf und ansehen von eibd/knxd mehr schadet als nützt, grundsätzlich fehlerhafte Schnittstellen mit 100 Workarounds trotzdem "irgendwie halbwegs" zu unterstützen. Wertstoffhof ist dafür leider die einzige Destination.

JulianGloeckle : eine *moderne* IP-Schnittstelle ist natürlich auch eine gute Option, aber auch da gibts jede Menge "Leichen im Keller" - sprich uralten Elektroschrott, entwickelt bevor jemand die erste RFC gelesen hatte - der dann nur eine oder gar vier Tunneling-Connectins bedienen kann;
dem würde ich bis heute sogar einen Raspi (von dem ich nichts halte, das ist Bastel-Schrott) mit TP-UART & knxd immernoch vorziehen (kann 65535 Connections)..
Präventiv: ja ich weiss sehr gut: KNXnet/IP Routing ist das egal, aber wer sich auf Multicast einlässt bewegt sich immernoch auf dünnem Eis und braucht Know-How..

Makki

Edit: Smurf ich habe noch 2-3 USB-SS hier rumliegen, damit kannste das nachvollziehen.. Ich glaube aber nicht das dabei etwas anderes rauskommt, als das sie unbrauchbar sind

[Sipple]

welche "moderne" IP Schnittstelle würdest du ihm denn empfehlen, makki?

[makki]

Ich möchte keine Produktempfehlung geben, da ich ziemlich "vorbelastet" bin.
Ich sag nur mal, was ich selbst im aktiven Einsatz habe:
(schon erwähnten) RasPI + TP-UART (als Bastelstunde)
Enertex IP-SS
WireGate (wie kommts nur..) + TP-UART1
Timberwolf + TP-UART2

Was ich mangels RFC-Konformität (Stand 2012!) zum Wertstoffhof aussortiert habe ist Siemens und ABB.

Mehr kann und will ich nicht sagen..

Makki

[jpkjpk]

Hi,
ich habe seit ein paar Jahren den Fhem mit eibd und einem USB Interface von Merten auf einem Raspi v2 unter Wheezy in Betrieb.
Ich wollte nun einen Raspi V3 mit Jessie dafür verwenden und nun auch den knxd einsetzen. Ich bekomme nun laufend den error "Send while buffer not empty"
Die Startparameter beim eibd waren: --daemon -u --eibaddr=1.1.126 -c -D -S -i -t 1023 --pid-file=/var/run/eibd.pid usb:1:4
beim knxd KNXD_OPTS="-e 1.1.140 -E 1.1.150:20 -D -T --send-delay=70 -R -S -b usb:"

Der Empfang der Buspakete funktioniert, beim Schalten im Sekundenabstand über den Fhem funktioniert es 2 - 3 und dann startet der KNX Daemon neu

Feb 16 02:02:23 raspberrypi systemd[1]: Started KNX Daemon.
Feb 16 02:02:34 raspberrypi knxd[889]: F00000108: [19:B.usb] Send while buffer not empty
Feb 16 02:02:34 raspberrypi knxd[889]: F00000105: [16:B.usb] Link down, terminating
Feb 16 02:02:34 raspberrypi knxd[889]: E00000035: [19:B.usb] SendError 12a9600 status 3
Feb 16 02:02:34 raspberrypi systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAIL
Feb 16 02:02:34 raspberrypi systemd[1]: knxd.service: Unit entered failed state.
Feb 16 02:02:34 raspberrypi systemd[1]: knxd.service: Failed with result 'exit-code'.
Feb 16 02:02:44 raspberrypi systemd[1]: knxd.service: Service hold-off time over, scheduling restart.
Feb 16 02:02:44 raspberrypi systemd[1]: Stopped KNX Daemon.

Das Problem ist einfach zu reproduzieren und einen Zugriff auf die Box über SSH und Web könnte ich einrichten - falls jemand sich das genauer anschauen möchte.

Sonst bleibt natürlich die Möglichkeit vom USB Interface umzusteigen.

MfG Peter

[Smurf]

[ nicht in dieses Thema passender Beitrag entfernt bzw. nach https://knx-user-forum.de/forum/proj...knxd-f00000105 verschoben ]