commandline knx funktioniert, knxtool und FHEM TUL leider nicht

[Huntercover]

Hi @all,

ich versuche schon seit 2 Tagen (eher Nächsten) sowie intensiver Internet-Recherche knxd auf meinem Pi zum Laufen zu bekommen.

Mittlerweile bin ich so weit, dass sich mein MDT SCN IP Interface ansprechen lässt, wenn ich knxd wie folgt aufrufe:
knxd -e 1.1.241 -t1023 -c -DTRS -b ipt:192.168.178.20
Da sehe da alle Busdaten was mich wirklich schon froh macht :-)
Übertrage ich den Aufrufparameter in die KNX_OPTS dann lässt sich sowohl der KNX-Socket als auch der KNX-Service starten.

Trotzdem bekomme ich immer connection refused-Fehlermeldungen wenn ich danach per Hand knxtool Befehle wie zb vBusMonitor1 testen will.
knxtool vbusmonitor1 ip:192.168.178.20
- gehört das etwa nicht zusammen?
Eigentlich möchte ich ja FHEM oder smart.py nutzen. Letzteres habe ich noch nicht ausprobiert, aber bei FHEM zeigt die TUL immer "disconnected".

Hätte da wer ne Idee an was das liegen könnte?


Grüße
Andreas

[bmx]

Welche Version vom knxd hast Du denn eigentlich installiert? (knxd -V)

[Tru]

knxd -e 1.1.241 -t1023 -c -DTRS -b ipt:192.168.178.20

Deine Version ist scheinbar etwas älter, denn ohne den Parameter -E funktionieren die aktuellen Versionen nicht. Am besten aktualisierst du auf den neusten Master Stand.

knxtool vbusmonitor1 ip:192.168.178.20
- gehört das etwa nicht zusammen?

Nein. Die Commands sprechen mit dem Daemon, nicht mit deiner Schnittstelle. Richtig wäre "knxtool vbusmonitor1 ip:localhost" oder einfach "knxtool vbusmonitor1 ip:". Ein Schreibbefehl sähe etwa so aus: knxtool groupswrite ip: 1/2/2 1

[Huntercover]

@bmx: Ich bin der Meinung, dass ich die Version über

https://github.com/knxd/knxd

installiert habe. In version.h lese ich aus:

#define REAL_VERSION "0.12.16:bccf6f6"

@tru: Ja, das mit localhost dämmerte mir gestern auch noch, aber dann schaltet die Gruppenadresse leider auch nicht.

Der Service läuft und iwie scheint der Befehl einen Reset auszulösen:

Jun 09 04:51:22 raspberrypi knxd[1197]: knxd: Layer 8 [ 7:systemd 1476.951] New Connection
Jun 09 04:51:22 raspberrypi knxd[1197]: knxd: Layer 8 [ 7:systemd 1476.951] ClientConnection Init

Sofern das Normal ist wird der Befehl aber nicht versendet. Ab und an wirft knxtool auch einen Fehler:

Connect failed: Connection reset by peer

Ich dachte ich habe die neueste Version ...
Wo gibt es was neueres?

Bleibt der Befehl:

knxtool vbusmonitor1 ip:

denn aktiv und zeigt die Kommunikation an wie der manuelle Aufruf von knxd mit zb -t1022?

[Huntercover]

wo gibt es eine genaue Anleitung für den Update auf 0.14?

Wenn ich das ausführe:

# now build+install knxd cd knxd git checkout master dpkg-buildpackage -b -uc

kommt der Fehler mit der Abhängigkeit zu libfftw3-dev, für das ich leider kein Paket finden kann.

Mit

dpkg-buildpackage -b -uc -d

bin ich wieder da wie vor 2 Tagen. Build bricht ab mit:

configure: exit 1
dh_auto_configure: ./configure --build=arm-linux-gnueabihf --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=${prefix}/lib/arm-linux-gnueabihf --libexecdir=${prefix}/lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --enable-usb --enable-groupcache --enable-ft12 --enable-tpuart --enable-dummy --libexecdir=/usr/lib --enable-dependency-tracking --enable-silent-rules returned exit code 1
debian/rules:21: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory '/home/pi/knxd'
debian/rules:14: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2

Kann es sein, dass die Master-Version nicht auf Debian Jessie läuft?

[Tru]

Da hast du scheinbar die neuste Stable Version, womit es auch klappen sollten. Es gäbe aber auch die neuere Master Version. Ausserdem solltest du wie bmx gesagt hat, die Version vom benutzten Binary mit knxd -V auslesen, nicht von einem Source-File, das da herumliegt.

Aber auch bei dieser Version läuft der Daemon ohne das -E Argument nicht, z.B. -E 1.1.242:9.

Aber klar bleibt "knxtool vbusmonitor1 ip:" aktiv und zeigt die Kommunikation an, wenn alles richtig gestartet ist

[Huntercover]

knxd -V liefert

knxd 0.12.16:bccf6f6

Wow. Mit -E tut es überhaupt mal. Hab ich nirgends gelesen.
Danke !!!

Jetzt kann ich über die on/off Befehle Lichter aus/an machen. Aber folgender Befehl

sudo knxtool vbusmonitor1 ip:

wirft immer noch:

Read failed: Connection reset by peer

FHEM hängt auch auch auf bzw. läuft ganz langsam.Log:

2017.06.09 05:56:24 1: knxd:localhost disconnected, waiting to reappear
2017.06.09 05:56:29 1: TUL knxd:localhost reappeared (tul)
eibd communication failed
seems like eibd not connected

Mit Deinem Beispiel müsste der TUL Parameter ja so aussehen:

knxd:localhost 1.1.242

zu:

KNXD_OPTS="-t1022 -e 1.1.241 -E 1.1.242:9 -d --no-tunnel-client-queuing -b ipt:192.168.178.20"

Passt das? Ich nutze übrigens das MDT SCN IP Interface

[Tru]

Mit Deinem Beispiel müsste der TUL Parameter ja so aussehen, oder?

Mit FHEM kann ich dir leider nicht helfen. Weit weg vom Ziel kannst du nicht mehr sein, denn wenn Schalten geht, dann müsste auch vbusmonitor1 klappen. Gemäss deinen Angaben scheint der Daemon aber nicht stabil zu laufen. Den sudo Befehl solltest du übrigens nicht verwenden, denn knxtool ist ein User-Tool.
Kannst du nochmals angeben wie jetzt die Startparameter aussehen, mit welchem Befehl du schaltest und wie du den Busmonitor startest? Für eine weitere Analyse müsstest du wohl für den Spezialisten Smurf ein Logfile erstellen und zur Verfügung stellen.
Auf meinem Debian x86 kriege ich bei Master übrigens den Fehler mit Abhängigkeit von libfftw3-dev nicht und den Parameter -d solltest du bei dpkg-buildpackage nicht verwenden, wenn du es mit Smurf nicht verscherzen willst. Er schreibt extra in der Dok:

# To repeat: if this fails because of missing dependencies,
# fix them instead of using dpkg-buildpackage's "-d" option.

Ich weiss nicht, ob Smurf ein Pi besitzt, um darauf den Build zu verifizieren. Du könntest dafür einen Issue auf https://github.com/knxd/knxd erstellen.

[Huntercover]

also ich nutze immer zum testen:

knxtool groupswrite ip: 1/2/84 0

und

knxtool vbusmonitor1 ip:

Folgende Tests habe ich gemacht:
1/

KNXD_OPTS="-t1022 -d -e 1.1.241 -E 1.1.242:9 --no-tunnel-client-queuing -b ipt:192.168.178.20"

Dies führt dazu, dass schalten erst mal geht, bei mehrmaligem schnellen Schalten geht dann gar nix mehr:

pi@raspberrypi:~ $ knxtool groupswrite ip: 1/2/84 0
Send request
pi@raspberrypi:~ $ knxtool groupswrite ip: 1/2/84 0
Connect failed: Connection reset by peer
pi@raspberrypi:~ $ knxtool groupswrite ip: 1/2/84 0
Open failed: Connection refused
pi@raspberrypi:~ $ knxtool groupswrite ip: 1/2/84 0
Open failed: Connection refused

2/

KNXD_OPTS="-t1022 -d -e 1.1.241 -E 1.1.242:9 -b ipt:192.168.178.20"

Die ersten 1-2 Befehle werden nicht angenommen, ansonsten gleich

3/

KNXD_OPTS="-t1022 -d -e 1.1.241 -E 1.1.242:9 -DTRS -b ipt:192.168.178.20"

Scheint geringfügig stabiler zu sein, aber eigentlich alles gleich..

Ich würde gerne wissen, welche Parametern ich überhaupt nutzen muss. Bei meiner Recherche nutzt jeder was anderes - vermutlich auch wegen den unterschiedlichen Versionen und natürlich weil viele USB Geräte nutzen.

Und kann man mit wenig Befehlen auf die Master Version (0.14?) updaten?


PS: Das mit den -d ist mir klar, nur finde ich nirgends das gesuchte Package und zur Not alles neu aufsetzen ist jetzt kein Akt, hab ja noch nix laufen und weiß auch noch nicht ob ich FHEM überhaupt nutze.

[smai]

Ich würde gerne wissen, welche Parametern ich überhaupt nutzen muss.

Du musst dich ja auch nicht danach richten, was andere für ihren Anwendungsfall brauchen. Schau in der Dokumentation, was du für deinen brauchst.
(entweder knxd --help oder unter https://github.com/knxd/knxd/wiki/Co...ine-parameters )

Und kann man mit wenig Befehlen auf die Master Version (0.14?) updaten?

Unter https://github.com/knxd/knxd#building steht im letzten Abschnitt ein # … and if you'd like to update knxd:
Und auf derselben Seite gibt es noch Hinweise zur Migration: https://github.com/knxd/knxd#migrating-to-014

[Huntercover]

@smai: Ich hab halt das Problem das ich nicht weiß wozu ich was benötige, zb:

-R, --Routing enable EIBnet/IP Routing in the EIBnet/IP server
-T, --Tunnelling enable EIBnet/IP Tunneling in the EIBnet/IP server

Brauch ich das?

Oder Multicast?

Ich möchte nur alle Gruppenadressen lesen/schreiben können per Visu aufm Pi via FHEM o.ä.
Und als Hardware habe ich das MDT SCN IP Interface.

Aus der Update-Anleitung werde ich nicht schlau. Ich möchte nicht jedes einzelne File updaten. Vermutlich setze ich nochmal neu auf..

PS: Ja, ich arbeite seit 2 Tagen zum ersten mal mit Linux etc.

[Tru]

Ich hab halt das Problem das ich nicht weiß wozu ich was benötige

das -R oder -T (zusammen mit -S) brauchst du, wenn du knxd als KNX Gateway ansprechen können willst. Meine KNX IP-Schnittstelle lässt z.B. genau einen Tunnel zu. Da kann ich knxd mit -RTS sowohl als Router wie auch als Tunnel-Schnittstelle einsetzen und dieser leitet dann über seinen Tunnel alles von und zu der IP-Schnittstelle.

Arbeite mal damit weiter: KNXD_OPTS="-t1023 -e 1.1.241 -E 1.1.242:9 -DTRS -b ipt:192.168.178.20". Dabei müssen die Adressen 1.1.242 - 1.1.250 natürlich frei sein. Das -d aus deinem Befehl darfst du bei systemd nicht verwenden. Hast du systemd im Einsatz?

Bauen der Master Version: Damit solltest du eigentlich klar kommen:

git clone https://github.com/knxd/knxd.git
cd knxd
git checkout master
dpkg-buildpackage -b -uc

Wie gesagt, wenn du die Abhängigkeiten nicht auflösen kannst, solltest du einen Issue öffnen.

[smai]

Wie willst du denn updaten, ohne jedes File einzubeziehen?
git pull überträgt übrigens nur geänderte Dateien bzw. sogar nur geänderte Teile, aber das spielt ja eigentlich als Benutzer keine Rolle.

Wenn du knxd nicht für ETS nutzt, brauchst du wahrscheinlich kein Multicast. Routing brauchst du für eine einzelne Verbindung auch nicht. Also -D und -R kannst du weglassen.

[Huntercover]

@Tru: Cool, mit dem Parametersatz lagst Du genau richtig. Auf einmal geht alles.

Ich danke Dir vielmals !!!

Damit lass ich das Update erst einmal weg.
@sami: Das mit den Abhängigkeiten ist nervig. Wollte mal was auflösen, dann waren es 2 usw. Und zwischendurch was neues installieren geht nicht, weil ja was anderes zuvor noch ungeklärte Abhängigkeiten hat..

[smai]

Von welchen Abhängigkeiten sprichst du genau und was lässt sich nicht zwischendurch installieren?

Das -t 1023 solltest du IMHO weglassen. Wenn alles stabil läuft, sollte nicht unnötigt geloggt werden, vor allem nicht auf der SD-Card eines RasPi.