mal wieder KNXD und TUL

[wolliballa73]

Hallo zusammen,

ich kämpfe schon seit Tagen damit, mein TPUART von meinem alten Wiregate auf den Raspi mit FHEM umzuziehen. Ich hab mich dabei an http://www.fhemwiki.de/wiki/Knxd gehalten, komme aber nicht so richtig weiter :-(
Ziel ist, dass sowohl FHEM auf den Bus zugreifen kann (logisch) als auch die ETS4 über's Netzwerk (wie das bisher über Wiregate lief)

knxd läuft anscheinend (/etc/init.d/knxd status), ich kann mit knxtool groupswrite aber trotzdem nix senden (war mein erster Test nach der Installation)

knxd.conf:

Code: [Auswählen]

KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"


Code: [Auswählen]

root@smarthome.local:smarthome# lsusb
Bus 001 Device 007: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 006: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 005: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Code: [Auswählen]

root@smarthome.local:smarthome# ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Jan  1  1970 ./
drwxr-xr-x 4 root root 80 Jan  1  1970 ../
lrwxrwxrwx 1 root root 13 Jan  1  1970 usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00 -> ../../ttyACM0

/etc/udev/rules.d/99-usb-serial.rules:

Code: [Auswählen]

SUBSYSTEM=="tty", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="204b", ATTRS{serial}=="74138303730351A0F1A0", SYMLINK+="knx", OWNER="knxd"
Und auf FHEM-Seite (die vermutlich erstmal nebensächlich ist, solange knxtool groupswrite nicht funktioniert):

Code: [Auswählen]

defmod tul2 TUL knxd:127.0.0.1 1.1.254

STATE: Initialized

Irgendwo bei der Fehlersuche bin ich noch über dieses da gestolpert, ohne jedoch die Funktion durchschaut zu haben - aber vielleicht hilft es hier ja jemandem weiter, mir die passenden Tips geben zu können:

Code: [Auswählen]

root@smarthome.local:smarthome# sudo knxd -t1023 -c -u /tmp/eib -u /var/run/knx -i -D -T -S -e 1.1.254 tpuarts:/dev/knx
Layer 4 [ 5:A.cache/G      0.000] GroupCacheInit
Layer 3 [ 4:A.cache/Conn   0.000] registerLink: 4:A.cache
E00000051: [ 1:main] You need a client-addrs=X.Y.Z:N option in your main section.
F00000109: [ 1:main] Error setting up the KNX router.

Vielen Dank schon mal für eure Zeit und Unterstützung ;-)

[erwin]

Ich würde folgendes versuchen:

Code: [Auswählen]

KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -f9 -t 1022  -D -T -R -S -b tpuarts:/dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00"Die optionen: -f9 -t 1022 sind debug optionen, wenn alles funkt, wieder wegmachen!
Evtl steht ja dann im debug output schon was erhellendes...

auf dem lsusb kann ich den Adapter nicht erkennen??? bist du sicher, dass es der Atmel Corp. LUFA USB to Serial Adapter Project ist ?

Einige Fragen:
-bist du auf Buster? da geht das install vom knxd mit: sudo apt-get install knxd - muß man nicht mehr kompilieren.... 
- output von: knxd -V
-output von ls -l /dev/knx ? Rechte für den knxd?
- output von ls -l /dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00
- Hat die ETS eine aktive Verbindung zu KNXD?

knxtool groupswrite .. ist nicht mein freund.. funkt. in manchen knxd versionen nicht (bei mir).
Ich verwende knxtool vbusmonitor1 - da siehst du alle pakete die zum KNXd- gehen - gut zum probieren mit dem ETS-Monitor, oder irgendeinen Taster drücken...
edit: c&p Fehler korrigiert!!!
PS: Die beste Beschreibung zu KNXD parameter gibts auf: https://github.com/knxd/knxd/blob/main/doc/inifile.rst (vom Author v. knxd)
l.g. erwin

[wolliballa73]

Hallo Erwin,

vielen Dank für die ausführliche Antwort - praktisch kann ich das erst heute Abend testen, da der TPUART jetzt wieder am Wiregate hängt (darüber hat meine ETS und auch FHEM seit Jahren eine stabile KNX-Anbindung). Aber ein paar Dinge kann ich schonmal beantworten:

auf dem lsusb kann ich den Adapter nicht erkennen??? bist du sicher, dass es der Atmel Corp. LUFA USB to Serial Adapter Project ist ?

Ziemlich sicher. Jetzt (Gerät ist nicht angestöpselt) fehlt es in der Liste; die ID (ID 03eb:204b) stimmt mit dem überein, was ich u.a. in http://www.fhemwiki.de/wiki/Knxd gefunden hab ("TUL einen dauerhaften Namen geben")

-bist du auf Buster? da geht das install vom knxd mit: sudo apt-get install knxd - muß man nicht mehr kompilieren....

Version ist 11.1 (Bullseye)
knxd hab ich mit apt-get installiert

Code: [Auswählen]

root@smarthome.local:smarthome# knxd -V
knxd 0.14.46

Die Rechte der beiden /dev-Einträge liefere ich dann heute Abend nach...


LG,
Matze

[wolliballa73]

... so - weiter geht's :-D

Code: [Auswählen]

root@smarthome.local:smarthome# ls -l /dev/knx
lrwxrwxrwx 1 root root 7 Oct 18 18:10 /dev/knx -> ttyACM0

root@smarthome.local:dev# ls -l /dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00
ls: cannot access '/dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00': No such file or directory

root@smarthome.local:dev# ls -l /dev/ttyACM0
crw-rw---- 1 knxd dialout 166, 0 Oct 18 18:10 /dev/ttyACM0


/dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00 gibt's also nicht, aber

Code: [Auswählen]

root@smarthome.local:by-id# ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Oct 18 18:10 usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00 -> ../../ttyACM0

Da es das /dev/usb-xxxxx nicht gibt, hab ich das in der knxd.conf geändert:

Code: [Auswählen]

KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -f9 -t 1022 -D -T -R -S -b tpuarts:/dev/ttyACM0"

Hab danach den Raspi neu gestartet, das Ergebnis ist aber noch dasselbe

Wo landen die Debug-Infos denn?

[erwin]

.. das device gibts sehr wohl (siehe dein 2.codeblock) !!
Es heisst nicht:

Code: [Auswählen]

/dev/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00
... sondern..
/dev/serial/by-id/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00
Rechte dürften passen, allerdings sehe ich den link nicht zu einem /dev/knx ?

debug log: debug logging geht auf die Konsole (stderr), lässt sich ändern.. Details siehe link in meinem vorigen post  Allerdings unter systemd gilt das:
Hilfe gibts hier: https://knx-user-forum.de/forum/projektforen/knxd/1362806-komplett-anderes-logfile-in-neuerer-version Konsole-cmd: journalctl -uknxd -n1 -f
Eine Frage ist natürlich auch noch: ob der USB Stick mit dem knxd kompatibel ist ?
Scheint aber einiges dafür zu sprechen, wenn mich die uralten posts im KNX_User Forum nicht in die Irre führen, läuft auf dem wiregate ja auch ein knxd (oder uralt eib...)
Erwin
 

[wolliballa73]

Hallo,

in der knxd.conf steht jetzt

Code: [Auswählen]

# KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx"
# KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -f9 -t 1022 -D -T -R -S -b tpuarts:/dev/ttyACM0"
KNXD_OPTS="-e 1.1.254 -E 0.0.2:8 -f9 -t 1022 -D -T -R -S -b tpuarts:/dev/serial/by-id/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00"

Die erste (auskommentierte) Variante war meine ursprüngliche Version, die beiden anderen die seit diesem Thread veränderten.

Alle drei Devices sind vorhanden, allerdings mit unterschiedlichen Eigentümern/Berechtigungen:

Code: [Auswählen]

root@smarthome.local:smarthome# ls -al /dev/knx
lrwxrwxrwx 1 root root 7 Jan  1  1970 /dev/knx -> ttyACM0

root@smarthome.local:smarthome# ls -al /dev/ttyACM0
crw-rw---- 1 knxd dialout 166, 0 Oct 19 13:42 /dev/ttyACM0

root@smarthome.local:smarthome# ls -al /dev/serial/by-id/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00
lrwxrwxrwx 1 root root 13 Jan  1  1970 /dev/serial/by-id/usb-wiregate.de_TPUART_for_WireGate_74138303730351A0F1A0-if00 -> ../../ttyACM0


Kompatibel sollte der Stick sein - wie du richtig erwähnt hast, läuft das auf dem Wiregate ebenfalls über eibd. Der Dienst-Status des Wiregate sagt:

Code: [Auswählen]

/usr/bin/eibd -e 1.1.254 -c -S -D -i -T -R --tpuarts-ack-all-group -d -u --pid-file=/var/run/eibd.pid -c tpuarts:/dev/tul
Ich bin ja nicht so der Linux-Spezialist - aber ist das gut so, dass /dev/ttyACM0 als Benutzer "knxd" hat, der knxd-Prozess aber als root läuft?
Und irgendwie kommt mir das komisch vor, wenn ich ps -ef mache und mir dann die Befehlszeile anschaue - die hat nicht viel mit dem zu tun, was in knxd.conf steht:

Code: [Auswählen]

root@smarthome.local:smarthome# ps -ef |grep knxd
root      1107     1  0 13:42 ?        00:00:00 /usr/bin/knxd -d -p /var/run/knxd.pid -e 0.0.1 -E 0.0.2:8 -u /tmp/eib -u /var/run/knx -i -b ip:
root      1108     1  0 13:42 ?        00:00:00 startpar -f -- knxd

Ratlose Grüße,
Matze

[erwin]

Ich denke wir kommen näher....
Wie startest du den knxd ? - dein knxd startet nicht mit deinen parametern!

Unter buster und neuer...  ist eigentlich systemd vorgesehen...

Code: [Auswählen]

sudo systemctl start knxd.socket
sudo systemctl start knxd.. und damit holt er sich die parameter aus /etc/knxd.conf und sollte unter user knxd laufen!

jedesmal wenn du etwas in /etc/knxd.conf änderst:

Code: [Auswählen]

sudo systemctl daemon-reload
sudo systemctl stop knxd.service
sudo systemctl stop knxd.socket
PS: deine /etc/knxd.conf schaut m.M. richtig aus!

erwin

[wolliballa73]

Hallo Erwin,

da bin ich dann wohl im WIKI-Artikel irgendwie ein bisschen durcheinander geraten mit den Konfigurationen :-(

So wie es aussieht, startet mein System nicht mit systemd, denn:

Code: [Auswählen]

root@smarthome.local:smarthome# sudo systemctl start knxd.socket
System has not been booted with systemd as init system (PID 1). Can't operate.

Im Wiki bin ich dann (wahrscheinlich) zum Bereich "Andere BCU's (BusCouplerUnit)" weitergesprungen und habe nicht realisiert, dass da dann nur noch der Weg über systemd angenommen wird.
Ich habe jetzt die Parameter aus /etc/knxd.conf zu /etc/default/knxd übernommen und teste das heute Abend nochmal (kann gerade nur remote auf die Kiste und der TUL steckt nicht am Gerät)

Sollte ich das generell auf systemd umstellen? Und wieso ist das bei mir anders als es sein sollte? Ist das historisch bedingt, weil die Grundinstallation irgendwann mal vor "Jessie" war?

LG,
Matze

[wolliballa73]

Hallo Erwin,

die Modifikation der /etc/default/knxd sieht schon mal gar nicht soooo schlecht aus:

Code: [Auswählen]

root@smarthome.local:smarthome# ps -ef |grep knxd
root      1968     1  0 18:02 ?        00:00:00 /usr/bin/knxd -d -p /var/run/knxd.pid -e 1.1.254 -E 1.1.254:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx

Ich kann damit mit der ETS auf den Bus zugreifen - soweit OK

Aaaber:
direkt mit FHEM schaltet nix und knxtool kann anscheinend nicht drauf zugreifen:

Code: [Auswählen]

root@smarthome.local:smarthome# knxtool vbusmonitor1 ip:localhost
Open failed: Connection refused

Ich glaube, die Lösung ist nah....

[erwin]

Hi,
irgendwo ist in deiner config noch der wurm drin!

Code: [Auswählen]

-d -p /var/run/knxd.pid -e 1.1.254 -E 1.1.254:8 -u /tmp/eib -D -T -R -S -b tpuarts:/dev/knx-d -p /var/run/knxd.pid -  weg damit!
-E 1.1.254:8 ist falsch! Würde heissen: adressen für den client, (z.b. fhem) werden von 254-261 reserviert... Der adressberreich geht aber nur bis 255 !! wobei 255 soll/darf nicht verwendet werden!
und dann noch die gleiche Addr wie für -e!
wenn jetzt die ETS auf der adresse 254 sitzt, kann kein weiterer Client zugreifen!
Vorschlag: -e 1.1.240 -E 1.1.241:8
Weiters: -u /tmp/eib ist unnötig!
Solange du mit knxtool vbusmonitor1 nicht zugreifen kannst, wirds mit fhem auch nicht gehen.
syntax vbusmonitor1:

Code: [Auswählen]

knxtool vbusmonitor1 local:/var/run/knxd
  oder
knxtool vbusmonitor1 ip:
  oder
knxtool vbusmonitor1 ip:localhost:67201. variante greift über socket zu ( = geht nicht in fhem)
2. variante über multicast  ( = wie fhem KNXTUL-modul)
3. variante über ip-adresse ( = wie fhem TUL-modul)

das korrelliert mit den knxd optionen: -T -R -S
l.g.erwin

[wolliballa73]

Hallo Erwin,

danke - das mit den -e und -E hab ich nun verstanden und hab die /etc/default/knxd angepasst - ich hab "hinten raus" keinen :8-Bereich mehr frei, aber so sollte es doch auch passen:

Code: [Auswählen]

DAEMON_ARGS="-e 1.1.250 -E 1.1.251:3 -D -T -R -S -b tpuarts:/dev/knx"
Meine ETS kriegt jetzt die 1.1.252, sagt sie; Zugriff über ETS funktioniert.

Der Zugriff mit knxtool haut aber immer noch nicht hin:

Code: [Auswählen]

root@smarthome.local:smarthome# knxtool vbusmonitor1 local:/var/run/knxd
Open failed: No such file or directory

root@smarthome.local:smarthome# knxtool vbusmonitor1 local:/var/run/knxd.pid
Open failed: Connection refused

root@smarthome.local:smarthome# knxtool vbusmonitor1 ip:
Open failed: Connection refused

root@smarthome.local:smarthome# knxtool vbusmonitor1 ip:localhost:6720
Open failed: Connection refused

PS:
das -d -p /var/run/knxd.pid stammt aus der ps -ef Ausgabe und nicht aus der Konf-Datei


LG,
Matze

[erwin]

das -d -p /var/run/knxd.pid stammt aus der ps -ef Ausgabe und nicht aus der Konf-Date

..sehr komisch, bei mir schaut ein ps -efw so aus:

Code: [Auswählen]

knxd       982     1  0 Oct20 ?        00:00:00 /usr/bin/knxd -e 0.0.50 -E 0.0.51:8 -D -T -R -S -b ipt:192.168.x.yhilfreich wär auch ein sudo netstat -anp | grep knx. da würde dann z.b. auch drinstehen welchen socket und ports der knxd angelegt hat!

Code: [Auswählen]

udp        0      0 0.0.0.0:3671            0.0.0.0:*                           982/knxd
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           982/knxd
unix  2      [ ACC ]     STREAM     LISTENING     8351     1/init              /var/run/knxd
unix  3      [ ]         STREAM     CONNECTED     9042     982/knxd

[wolliballa73]

Hallo Erwin,

muss dir recht geben - das ps sieht bei mir tatsächlich anders aus:

Code: [Auswählen]

root@smarthome.local:smarthome# ps -efw |grep knxd
root      1079     1  0 08:30 ?        00:00:00 /usr/bin/knxd -d -p /var/run/knxd.pid -e 1.1.250 -E 1.1.251:3 -D -T -R -S -b tpuarts:/dev/knx
Alles ab "-e" ist das, was in der /etc/default/knxd als DAEMON_ARGS steht.

Ich vermute jetzt mal, dass das -p aus dem /etc/init.d/knxd kommt:

Code: [Auswählen]

PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="knxd"
NAME=knxd
DAEMON=/usr/bin/knxd
DAEMON_ARGS=""
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

[...]

do_start()
{
# Return
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
-d -p $PIDFILE $DAEMON_ARGS \
|| return 2
}

In /var/run/knxd.pid steht einfach nur die PID (wer hätte das gedacht ), momentan also 1079


netstat liefert deutlich weniger als bei dir:

Code: [Auswählen]

root@smarthome.local:smarthome# sudo netstat -anp | grep knx
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           1079/knxd


LG und schönes Wochenende,
Matze

[erwin]

hi,
das netstat zeigt, dass der knxd am port 3671 lauscht, allerdings auch, dass er keinen socket aufgebaut hat (den brauchst du auch nicht....)
an den optionen, die durch init.d hinzugefügt wurden, wirds nicht liegen, siehe:
https://github.com/knxd/knxd/blob/debian/doc/inifile.rst

Falls jetzt noch immer nichts geht mit knxtool vbusmonitor1 ip:localhost:3671 ... hab ich eigentlich keine idee mehr!
2 Tips noch:
1) In knx user forum schauen: https://knx-user-forum.de/
2) Weil auch systemd nicht bei dir geht: einen neuen raspi mit neuer sd-Karte nehmen, aktuelle release drauf, vorerst nur knxd installieren - testen.
    geht vmtl. schneller als die Fehlersucherei!

Mein Konzept geht so: ich hab 2 raspi's im Verteilerkasten, auf beiden sind alle daemons installiert, z.b. OWServer, knxd, grafana, fhem,sql,...
Im Normalfall betreibe ich so was wie "load-sharing" - fhem läuft auf system1 - anderes auf system2. configs werden täglich syncronisiert.
Im backup fall kopiere ich die aktuelle config des daemons auf den andern raspi, und starte den daemon dort... Schlimmstenfalls muss ich USB-Geräte umstecken!

Im Fall eine release wechsels (oder auch Hardware) läuft alles auf einem system und ich fang auf dem anderen mit einer frischen distribution an -
das dauert im normalfall 1 Stunde bis alles wieder läuft!
l.g. erwin

[wolliballa73]

Hallo Erwin,

sieht so aus, als läuft das auf eine Neu-Installation raus. Wer weiß, was sich da im Laufe der Jahre so alles angesammelt hat, was jetzt zum Problem wird
Mal schauen, was das Wochenende bringt - vielleicht klappt es dann ja auch endlich mit meiner Alexa-Kopplung (s. anderer Thread)

Trotzdem vielen Dank für die Unterstützung bis hierher - again what learned !!!