knxd (0.14) an sich läuft.. aber ETS will nicht

[Brick]

Hallo,

ich hab es mal wieder probiert den KNXD zu installieren, diesmal auf Debian 32bit.. installation laut Wiki, lief problemlos.
Hab dann mal Edomi und den EibPC dran gehängt, läuft.

Leider kann ich weder aus der ETS3 noch aus der ETS5 raus Geräte parametrieren oder am Gruppenmonitor etwas sehen.

Wenn ich dort auf den Button "Verbindung zum Bus aufbauen" drücke, macht er das auch. Leider bekommt ich beim parametrieren
immer einen Timeout und beim Gruppenmonitor bekomm ich die Meldung das ich keine "Rückmeldung vom Bus" hätte.

Zur Konfig:
Debian nach Installationsanleitung installiert,
KNXD nach Anleitung auf Git installiert (0.14)
Aufgerufen wird das ganze mit: knxd -e 1.1.124 -E 1.1.125:8 -u /tmp/eib -b ipt:192.168.178.25 -DTRS

Wie gesagt.. Edomi und Eibpc funktionieren perfekt.. kann senden, empfangen usw..
deswegen glaub ich das der KNXD an sich schon funktioniert. Nur die dusslige ETS will nicht..

hat da jemand einen Tipp ?

Gruß Martin

[makki]

Hmm, -DTRS sollte mehr als reichen;
Hast du geprüft ob der auch so läuft (das mit den Parametern ausm ini File kann verwirren)
ps ax | grep knxd
netstat -anp | grep knxd

Was sagt die ETS genau?
Mir wär ja am liebsten ein knxd -t 1023 > debug.log aber das geht ja so einfach nicht mehr, weil wir systemd und journalctl vom Poettering jetzt unbedingt brauchen

Makki

[Smurf]

Mir wär ja am liebsten ein knxd -t 1023 > debug.log aber das geht ja so einfach nicht mehr

Klar geht das. Einfach knxd.socket und knxd.service stoppen und den knxd manuell starten (-u und -i dazuklatschen).
Alternativ via systemd: "-t 1023" in die Optionen aufnehmen, knxd neustarten,

journalctl -S "10 min ago" -uknxd

.

[makki]

Klar geht das. Einfach knxd.socket und knxd.service stoppen und den knxd manuell starten (-u und -i dazuklatschen).

Hmm du sagst das so einfach, ich weiss zwar was du meinst aber wenn ich jetzt

markstaller@tux-mm-mint:~/devel/knxd/src/server$ ./knxd -i -u
E00000055: [ 1:main] There is no KNX addr= in section 'main'.
F00000000: [ 1:main] Error setting up the KNX router.

Wie erklärt man das, das man das jetzt erst mit einem Hilfprogramm in eine INI schreiben muss? Ich finds komplizierter.

Alternativ via systemd: "-t 1023" in die Optionen aufnehmen, knxd neustarten,

journalctl -S "10 min ago" -uknxd

.

Mit Verlaub:
Versteht aber auch keiner. Mir ist es nicht gelungen in unter 30 min das vernünftig und nachvollziehbar zu beschreiben - und zu was ich den "journalctl -Parameterunbekannt -komische-argumente" auf der Shell jetzt dazu brauche ist mir ebenso schleierhaft.
Eigentlich sollte es stdout und stderr immernoch tun, oder..
Wir reden hier darüber, das wir dem Anwender nichtmal eine Anleitung geben können, wie er einen Debug-Output produziert, zur eigentlichen Fehlersuche nicht hilfreich

Makki

[larsrosen]

Hallo,

bei mir verbindet sich die ETS zwar, aber beim programmieren stürzt der Prozess ab.

Brick
schau mal nach, ob die Prozess id vorher und nachher noch die selbe ist.

Ich bekomme es mit den neuen Versionen leider nicht hin von Hand mit debug zu starten. Bin deshalb wieder zur KNXD Version gewechselt die makki von eibd übernommen hat.

[Brick]

makki, ja knxd läuft auch mit den Parametern, das hab ich getestet.
netstat -anp | grep knxd geht nicht, Kommando nicht gefunden

Die ETS sagt:
unter Optionen Kommunikation:


Bereich1.png
OK.. hab auch mal die Problemanalyse gemacht.. alle drei Tests erfolgreich

wenn ich dann den Gruppenmonitor auf mache, passiert erst mal nix.. wenn ich dann eine GA Lesen/Schreiben will kommt folgendes:
Bereich2.png

und wenn ich einen Aktor parametrien will kommt folgendes:
Bereich3.png

Das Ding bekommt also keine Verbindung...


zum Rest eurer Unterhaltung... wenn ich "sudo journalctl -S "10 min ago" -uknxd" eintippe kommt:

-- No entries --

soll ich da jetzt noch mit anderen Parametern starten ??

Gruß Martin

[makki]

Brick Auf die Gefahr hin, das wir jetzt ganz verschiedene Probleme vermischen (der Hauptfehler für mich ist die abkehr von SysV und syslog, hier egal)

-> Schätze ich mal, das es sich eher um ein Multicast-Problem (welcher switch?) handelt!
Vermeide es wie die Pest, benutze KNXnet/IP Tunneling (unicast)
Und wenn netstat nicht geht muss man das halt wohl per "sudo apt-get install netstat" nachinstallieren, ich habe keine Ahnung was die im RasPI für eine sinnvolle Basis-Ausstatung halten (ist aber seit 10J in jedem Debian eigentlich)

Makki

[Brick]

Hatte ich schon probiert:

sudo apt-get install netstat
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
E: Paket netstat kann nicht gefunden werden.

schau ich mir aber später mal an, wie das zum installieren geht...

Was meinst du mit Switch ? .. an was für einem Switch mein PC bzw. die IP Schnittstelle hängt ?? .. wäre ein kleiner
einfacher Netgear Switch..

in der ETS hab ich KNXnet/IP ohne Routing...
Bereich4.png

[Brick]

so.. mit "apt-get install net-tools" wird das installiert ..

Ergebnis:

udp 0 0 192.168.178.75:54598 0.0.0.0:* 663/knxd
udp 0 0 0.0.0.0:3671 0.0.0.0:* 663/knxd
unix 2 [ ACC ] STREAM HÖRT 12935 663/knxd /tmp/eib
unix 3 [ ] STREAM VERBUNDEN 12928 663/knxd

[Brick]

wenn ich auf KNXnet/IP mit Routing stelle geht übrigens der Gruppenmonitor ..
Parametrieren geht aber immer noch nicht.. nur die Fehlermeldung ist eine andere:
Das Gerät mit der phys. Adresse 1.2.17 kann nicht gefunden werden.

[makki]

Dann suspekt..
Mit Switch meine ich: Defaultmässig nimmt die ETS gerne Multicast (KNXnet/IP Routing) und wenn der Switch auch nur ein bisschen (pseudo-) intelligent ist geht das oft schief.. Für den Rest braucht es Debug-Logs, um zu sehen was da schiefläuft.. Bitte auch die genaue ETS-Version!
Alternativ immer gerne ein Wireshark-Capture vom ETS-Rechner, der kann das mittlerweile - dank der Kollegen aus Wien - auch recht gut

Makki

[Smurf]

Wie erklärt man das, das man das jetzt erst mit einem Hilfprogramm in eine INI schreiben muss?

??? Musst du doch gar nicht. Du hast eine Latte von Optionen. Die stehen in der knxd.conf. Mit denen (und mit -t1023 vorne / -u -i hinten) startest du den knxd manuell.

Dass du den knxd nicht nur mit -u -i starten kannst, verwundert nun wirklich niemanden.

Wenn du das jemandem "in neu" (also mit ini-Dateiformat) erklären willst, ist das zwar 'n bisschen komplizierter, aber auch kein Problem:

$ /usr/lib/knxd_args  -e1.2.3 -E1.2.4:5 -b ip:
[A.ip]
driver = ip
[main]
addr = 1.2.3
client-addrs = 1.2.4:5
connections = A.ip
systemd = systemd

$ /usr/lib/knxd_args -t1023  -e1.2.3 -E1.2.4:5 -b ip: -u -i
[A.ip]
driver = ip
[B.unix]
server = knxd_unix
systemd-ignore = true
[C.tcp]
server = knxd_tcp
systemd-ignore = true
[debug-main]
trace-mask = 0x3ff
[main]
addr = 1.2.3
client-addrs = 1.2.4:5
connections = A.ip,B.unix,C.tcp
debug = debug-main
systemd = systemd

Die Änderungen sind offensichtlich. Abgesehen davon kann man die letztere Version auch mit systemd verwenden, dazu sind die "systemd-ignore"-Einträge da – dann reduziert sich das Ganze auf das Einfügen der "debug-main"-Sektion und -Zeile (die man im Übrigen nennen kann, wie man mag).

Was der journalctl-Befehl tut, ist ausreichend offensichtlich und in dessen manpage erklärt. Ich finde es um Einiges einfacher, den Leuten diesen Befehl zu nennen, statt ihnen zu sagen "sorry, aber welche Fehlermeldungen auch immer der knxd ausgegeben hat sind jetzt weg, du musst ihn erstmal im Terminal neu starten und das Problem reproduzieren" oder "naja, die Logs sind in einer der Dateien in /var/log zwischen dem Output aller anderen Prozesse versteckt, hier hast du nen kryptischen grep-Befehl zum Rausfiltern der aktuellen Einträge".

Dafür, dass du grep besser kennst als journalctl, kann ich nix – den meisten Anfängern die ich so kenne ist der Journal-Kram ehrlich gesagt einfacher zu vermitteln.

[makki]

Smurf : jetzt bitte nicht persönlich nehmen, aber ich mach jetzt mal einen auf Anwender:

./knxd_args -e1.2.3 -E1.2.4:5 -b ip:

Es läuft noch immer garnix, ausser einer Textausgabe.

Also richtiger wäre doch

 
 ./knxd_args  -e1.2.3 -E1.2.4:5 -b ip: > knxd.ini ./knxd knxd.test.ini

Dein Beispiel funktioniert aber nichtmal:

markstaller@tux-mm-mint:~/devel/knxd/src/server$ ./knxd knxd.test.ini 
E00000055: [ 1:main] Only one connection in section 'main'.
F00000000: [ 1:main] Error setting up the KNX router.

Für die Pest systemd&Co (m.E. die grösste Pest seit Windows Vista) können wir beide nichts, das diskutieren wir aber ein ander mal..

Also, wie bekomme ich knxd mit debug-output jetzt nun als "normaler Anwender" mit -t1023 ans laufen?
Wenn ich jetzt den output einfach nur lokal auf der (ssh)-Konsole sehen will ? ohne "journalctl -haste -nicht -gewusst"

Im Klartext.. Optional > meinlogfile.txt

Makki

[Smurf]

*Seufz* ich habe auch nicht gesagt, dass das so läuft. Ich habe gesagt, dass du mit diesem Beispiel rausfinden und somit erklären kannst, was du ändern musst, um ohne systemd zu starten und Debugging einzuschalten. Und dazu gehört halt -u -i.

Also, wie bekomme ich knxd mit debug-output jetzt nun als "normaler Anwender" mit -t1023 ans laufen?
Wenn ich jetzt den output einfach nur lokal auf der (ssh)-Konsole sehen will ? ohne "journalctl -haste -nicht -gewusst"

Äh … sorry, aber das habe ich geschrieben: Mit [den bestehenden Optionen in der knxd.conf] und mit -t1023 vorne / -u -i hinten startest du den knxd manuell.
Und wenn du "schon" eine .ini-Datei verwendest, dann musst du die Änderungen, die man an der Ausgabe zwischen den beiden knxd_args-Aufrufen sieht, in diese Datei übernehmen. (Mischbetrieb zwischen Optionen und .ini-Datei geht aktuell nicht, kann man sich aber überlegen einzubauen.)

War das jetzt wirklich so unverständlich formuliert???

[Tru]

Dein Beispiel funktioniert aber nichtmal:

Wenn du knxd von der Kommandozeile starten willst, musst du -i und/oder -u mitgeben. Bei Verwendung von systemd wird das von knxd.socket übernommen.

Für die Pest systemd&Co (m.E. die grösste Pest seit Windows Vista) können wir beide nichts, das diskutieren wir aber ein ander mal..

Nach bald 30 Jahren mit SysV habe ich mich mit der Umstellung auf systemd auch schwer getan. Aber statt mich wie der Lachs vor dem neuen Damm abzumühen und mich grün und blau und rot zu ärgern, habe ich einfach die Fischtreppe genommen - klappt ganz gut, man gewöhnt sich schnell daran.

Also, wie bekomme ich knxd mit debug-output jetzt nun als "normaler Anwender" mit -t1023 ans laufen?

Einfach eine korrekte und vollständige Befehlszeile eintippen. Noch musst du den Umweg über das INI-File gar nicht machen. Und gleich wie bei anderen Linux, welche kein systemd unterstützen. Wie wäre es denn mit

 
 knxd -t1023  -e1.2.3 -E1.2.4:5 -b ip: -u -i