FHEM - Hausautomations-Systeme > KNX/EIB

mal wieder KNXD und TUL

<< < (2/4) > >>

wolliballa73:
Hallo,

in der knxd.conf steht jetzt

--- Code: ---# 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"

--- Ende Code ---

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

--- Ende Code ---


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: ---/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
--- Ende Code ---

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

--- Ende Code ---

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: ---sudo systemctl start knxd.socket
sudo systemctl start knxd
--- Ende Code ---
.. 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: ---sudo systemctl daemon-reload
sudo systemctl stop knxd.service
sudo systemctl stop knxd.socket
--- Ende Code ---

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: ---root@smarthome.local:smarthome# sudo systemctl start knxd.socket
System has not been booted with systemd as init system (PID 1). Can't operate.

--- Ende Code ---

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

--- Ende Code ---

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: ---root@smarthome.local:smarthome# knxtool vbusmonitor1 ip:localhost
Open failed: Connection refused

--- Ende Code ---

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

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

--- Code: ----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
--- Ende Code ---
-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: ---knxtool vbusmonitor1 local:/var/run/knxd
  oder
knxtool vbusmonitor1 ip:
  oder
knxtool vbusmonitor1 ip:localhost:6720
--- Ende Code ---
1. 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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln