FHEM - Hausautomations-Systeme > KNX/EIB

mal wieder KNXD und TUL

<< < (3/4) > >>

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: ---DAEMON_ARGS="-e 1.1.250 -E 1.1.251:3 -D -T -R -S -b tpuarts:/dev/knx"

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

--- Ende Code ---

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


LG,
Matze

erwin:

--- Zitat ---das -d -p /var/run/knxd.pid stammt aus der ps -ef Ausgabe und nicht aus der Konf-Date
--- Ende Zitat ---
..sehr komisch, bei mir schaut ein ps -efw so aus:

--- Code: ---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.y
--- Ende Code ---
hilfreich 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: ---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
--- Ende Code ---

wolliballa73:
Hallo Erwin,

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

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

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

--- Ende Code ---

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: ---root@smarthome.local:smarthome# sudo netstat -anp | grep knx
udp        0      0 0.0.0.0:3671            0.0.0.0:*                           1079/knxd

--- Ende Code ---


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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln