Hallo Zusammen,
Ich denke oft genommenes und diskutiertes Thema aber die Sachen die ich gefunden habe, wollen nicht so richtig funktionieren.
Was will ich?
Auf meinem Raspi2 läuft seit einigen Tagen Fleißarbeit die Visu Fhem. Als Schnittstelle habe ich ein KNX-Gateway von ABB als Verbindung Ethernet/IP <---> EIB/KNX. Damit programmiere ich auch via ETS4 und klappt auch soweit ganz gut. Wenn ich nach dem Start vom Raspi2 den EIBD mit:
/usr/local/bin/eibd -t 1023 -S -D -R -T -i --eibaddr=X.X.X --daemon=/var/log/eibd.log --no-tunnel-client-queuing ipt:192.168.XXX.XXX
manuell starte. Da ich mir ein "wenig" Automatisierung wünsche ;-) hätte ich gern den EIBD automatisch mit Booten des Raspi2 gestartet.
Was habe ich schon probiert:
1.
sudo nano /etc/crontab
und dann
@reboot root eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.188.XXX
eintragen.
Funktioniert wie erwähnt nicht. Frage was macht eigentlich der "root" dort? Ich bekomme bei Eingabe am Prompt die Meldung eibd benötigt keinen root?
2.
in /etc//init.d eine EIBD angelegt und den Script von http://redaktion.knx-user-forum.de/lexikon/eibd/ (angepasst an meine IP-Adresse)und sonst auch chmod und den Autostart über rcconf eingetragen --> funktioniert auch nicht.
Was gibt es denn noch für Möglichkeiten? Kann mir bitte jemand helfen?
Ingo
Der aktuelle knxd installiert bereits ein Initscript. Du musst noch /etc/default/knxd anpassen (Argumente eintragen, NO zu YES ändern) und dann einfach "/etc/init.d/knxd start" aufrufen.
Wenn du den nicht bauen magst (ich rate dazu, weil Bugs behoben und neue Features und überhaupt), kannst du dir die Dateien hier holen und ersetzt im Skript /usr/sbin/knxd durch .../eibd.
https://github.com/knxd/knxd/raw/master/debian/knxd.init
https://github.com/knxd/knxd/raw/master/debian/knxd.default
Hallo smurfix,
gibt es irgendwo eine Anleitung wie man den knxd installiert (wegt, apt-get install etc.)?
Ingo
Klar gibt es die: https://github.com/knxd/knxd/blob/master/README.md
NB: Ab Version 0.9.0-3 (die baue und teste ich gerade) gibt es auch nativen Support für systemd.
Korrektur: systemd-Unterstützung ist "nur" im neuen Master-Zweig; aktuelle Version: 0.10.1-2.
Ich habe eben die Socket-Aktivierung getestet, funktioniert wunderprächtig.
Hallo Smurfi,
erstmal besten dank für dein Unterstützung. Bin gerade am installieren und bekomme Fehlermeldungen:
(//)
Muss ich evtl. das alte bcusdk und pthsem erst entfernen?
Ingo
High,
habs gefunden. war beim Copy+Paste hinten abgeschnitten. Ich probiers gleich nochmal mit libsystemd-daemon-dev
Ingo
High nochmal,
hä, hattest du das libsystemd-daemon-dev gerade eingefügt im readme?
Ingo
high,
ja du hattest vor 28 min. Woher weiß ich ob ich wheezy nutze(Anfängerfrage ich weiß)?
aber auch mit
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
Komme ich nicht weiter: Auf das Archiv kann nicht zugegriffen werden. Datei o. VZ nicht gefunden. ich dacht das hole ich mir mit apt-get oder wget?
Ingo
Wenn du pthsem schon hast, dann brauchst du das natürlich nicht mehr bauen!
Wenn es keine knxd_*.deb-Datei gibt, dann ist beim Bauen was kaputtgegangen. Bitte Fehlermeldung hier einfügen -- aber bitte als Text und nicht als Screenshot.
copy+paste ist dein Freund, dasselbe gilt für die <code>-Markierung (natürlich mit eckigen Klammern -- klicke auf das #-Ding hier im Editor und füge ein).
high smurfi,
so ich bin ein stück weiter. Hier http://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/39972-eibd-war-bcusdk-fork-knxd/page15 (http://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/39972-eibd-war-bcusdk-fork-knxd/page15) bin ich über den gleichen fehler "fehlende bauabhängikeiten" gestolpert und habe bei
apt-get install build-essential libtool automake pkg-config cdbs libsystemd-daemon-dev
debhelper und libusb-1.0.0-dev ergänzt un von vorne begonnen.
Könntest du bitte die readme diesbezüglich ergänzen, wenn ich richtig liege. Oder habe ich was anderes verkehrt gemacht (copy+paste um wenigstens Schreibfehler zu vermeiden)? Ich mach weiter und melde mich bei Erfolg oder Auch Misserfolg.
Ingo
High Smurfi,
so ich denke ich habe fertig, jetzt wird's spannend. Habe noch No zu Yes geändert und meine IP-Adresse angepasst und habe EIBD noch aus dem rcconf rausgenommen und gesehen das knxd schon drinsteht.
Ingo
Hallo Smurfi,
ich habe alles nach readme installiert (und auch noch ein wenig mehr), aber der knxd starte nicht automatisch. Wenn ich diesen manuell mit
sudo /etc/init.d/knxd start
starte, dann bekomme ich folgende Fehlermeldung:
No listen-address given: Success
Bei eibd konnte ich mit
groupswrite ip:127.0.0.1 0/2/9 0
z.Bsp. das licht im az schalten. Das geht jetzt nicht mehr(weil wohl eibd nicht läuft und knxd auch nicht)?
Wie sieht es denn mit der
/etc/init.d/knxd
aus? Welche # muss ich dort zwangsläufig wegnehmen? Meine knxd sieht jetzt so aus:
# Defaults for knxd initscript
# sourced by /etc/init.d/knxd
# installed at /etc/default/knxd by the maintainer scripts
#
# This is a POSIX shell fragment
#
# start knxd when /etc/init.d/knxd start is run
# by default knxd does NOT start. set to YES to enable
START_KNXD=YES
# Additional options that are passed to the Daemon.
#
# for IP interface at 192.168.178.123;
# local Unix Domain Socket /tmp/eib _not_ enabled (-u)
DAEMON_ARGS="-c -S -D -R -T --no-tunnel-client-queuing -i ipt:192.168.XXX.YY"
DAEMON_ARGS=""
Wobei XXX.YY meine IP-Adresse vom Koppler ist. Sollte doch so funzen oder?
Ingo
Hallo zusammen nochmal,
so den einen Fehler habe ich gefunden (war ja sehr offensichtlich)
DAEMON_ARGS="-c -S -D -R -T --no-tunnel-client-queuing -i ipt:192.168.XXX.YY"
DAEMON_ARGS=""
geht ja nicht.
DAEMON_ARGS=""
entfernt und jetzt kann ich zumindest mal wieder manuell starten und mit groupswrite meinen eib-bus erreichen.
Aber der Autostart haut noch nicht hin. Kann mir bitte jemand helfen.
Ingo
Hallo zusammen,
manueller start geht, aber kein autostart. Was mache ich falsch?
Gibt es schon eine Anbindung an fhem? Das funktioniert bei mir auch noch nicht.
Das "eibd"
define tul TUL eibd:localhost 1.0.255
in der fhem.cgf durch "knxd" ersetzen führt zu folgendem Fehler im fhem.log:
2015.06.28 00:42:07 3: TUL opening tul device knxd:localhost
2015.06.28 00:42:07 1: knxd:localhost protocol is not supported
2015.06.28 00:42:07 3: TUL device opened
Was für mich so aussieht als könnte er die Schnittstelle öffnen aber nicht mit ihr kommunizieren.
Ingo
man update-rc.d
also bei dir: update-rc.d knxd defaults
(Hätte eigentilch automatisch ausgeführt werden sollen.) Danach siehst du jedenfalls in /etc/rc3.d einen Link S20knxd -> ../init.d/knxd (die 20 kann variieren) und statt der 3 in rc3.d ist die Zahl relevant, die bei dir in der /etc/inittab hinter :id: steht.
Einen Fehler hast du noch: -DRT beziehen sich auf das dahinter folgende -S. Damit das in der aktuellen Version so funktioniert, muss das -S weiter hinter.
Wie rufst du deinen "groupswrite" auf?
Zitat von: speedschmidt am 28 Juni 2015, 01:13:49
Gibt es schon eine Anbindung an fhem? Das funktioniert bei mir auch noch nicht.
Das "eibd"
define tul TUL eibd:localhost 1.0.255
in der fhem.cgf durch "knxd" ersetzen
Wieso willst du das tun? Extern ändert sich gar nichts, d.h. FHEM redet genauso mit dem knxd wie vorher mit dem eibd, d.h. du musst da "eibd" stehen lassen.
Ich gehe eher davon aus, dass du den eibd mit "-S -R -T" o.Ä. gestartet hast. Das geht jetzt nicht mehr und muss "-R -T -S" heißen, weil sich -DRT (und ein paar andere Optionen) auf die
danach folgende Interfacedefinition auswirken. (Wenn jemand einen .INI- oder YAML-Parser einbinden will ...)
High Smurfi
Also bei mir in der
/etc/inittab
steht:
id:2:initdefault:
Wohlbemerkt: "id:" und nicht ":id" also habe ich in /etc/rc2.d nach dem Link S20knxd gesucht und nichts gefunden. Einzig ein K01knxd-Link gibt es dort.
Ich habe auch die anderen rcx.d - Verzeichnisse durchsucht.
Ich hatte eigentlich beim bauen den Eindruck das alles ohne Fehler lief. Manchmal liefen die zeilen schon arg schnell durch, aber jeder befehl wurde ohne Fehlermeldung beendet.
Wie schon gesagt nachdem ich debhelper und libusb-1.0.0-dev mit runtergeladen und installiert hatte.
Aber ich habe das ganze mit libsystemd-daemon-dev durchgeführt. War das der Fehler?
Die Argumente habe ich so wie du meinst angepasst:
DAEMON_ARGS="-c -D -R -T --eibaddr=1.0.255 --no-tunnel-client-queuing -i -S ipt:192.168.100.34"
groupswrite rufe ich so auf:
groupswrite ip:localhost 1/1/1 0
oder
groupswrite ip:127.0.0.1 1/1/1 0
Beide Varianten funktionieren wenn eibd oder knxd manuell gestartet worden sind.
Nochmal zum letzten beitrag knxd und fhem:
Nur zum Verständniss: Ich war der Meinung, dass eibd durch knxd komplett ersetzt wird. Sow wie ich es von dir verstehe, ist es eher richtig, dass knxd
auf eibd aufsetzt und dieser nach wie vor benötigt wird? Muss dann nicht auch der eibd automatisch gestartet werden, oder macht das der automatisch gestartete knxd?
Ingo
Ach so hatte ich ganz am Anfang vergessen:
pi@raspberrypi ~ $ update-rc.d knxd defaults
update-rc.d: using dependency based boot sequencing
insserv: warning: script 'K01eibd' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (empty) of script `knxd' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `knxd' overrides LSB defaults (0 1 6).
insserv: warning: script 'eibd' missing LSB tags and overrides
insserv: fopen(.depend.stop): Permission denied
pi@raspberrypi ~ $
sind das Fehlermeldungen?
High
Neuigkeiten:
pi@raspberrypi ~ $ /etc/init.d/knxd start
pi@raspberrypi ~ $ /etc/init.d/knxd status
[ ok ] knxd is running.
pi@raspberrypi ~ $ groupswrite ip:localhost 0/2/9 0
Send request
pi@raspberrypi ~ $ groupswrite ip:localhost 0/2/9 1
Send request
pi@raspberrypi ~ $ groupswrite ip:localhost 0/2/9 0
Send request
pi@raspberrypi ~ $
funktioniert auch mit fhem zusammen. Allerdings noch kein autostart.
Ingo
ZitatNur zum Verständniss: Ich war der Meinung, dass eibd durch knxd komplett ersetzt wird. Sow wie ich es von dir verstehe, ist es eher richtig, dass knxd
auf eibd aufsetzt und dieser nach wie vor benötigt wird? Muss dann nicht auch der eibd automatisch gestartet werden, oder macht das der automatisch gestartete knxd?
Neenee, der eibd muss komplett raus. Nur in der Konfigdatei vom FHEM steht noch "eibd".
So. Ich verstehe nicht so ganz, wieso das mit den Runlevels nicht tut. Mach stattdessen diesen hier:
update-rc.d knxd enable 2 3 4 5
dann sollte er starten beim Booten. Ich schau mir das bei Gelegenheit ncoh näher an. :-/
Hallo Ingo,
im Anhang findest Du meine Initskript, welches Du mittels update-rc.d installieren kannst. Funktionieren für meinen PI hervorragend.
Eine Anpassung für knx dürfte leicht möglich sein.
P.S.: Nicht vergessen, das Interface in /etc/default/eibd einzustellen...
High Smurfi,
siehe hier meine Fehlermeldungen/Warnungen bzgl. missing LSB tags???:
pi@raspberrypi ~ $ sudo update-rc.d knxd enable 2 3 4 5
update-rc.d: using dependency based boot sequencing
insserv: warning: script 'K01eibd' missing LSB tags and overrides
insserv: warning: script 'eibd' missing LSB tags and overrides
Und immer noch kein Autostart, ansonsten siehts gut aus.
Ingo
@Andi291: dein Skript unterscheidet sich von dem, das knxd aktuell mitliefert, ziemlich wenig bis gar nicht ...
Mein aktuelles Problem ist: das funktioniert bei mir alles perfekt:
# dpkg -i knxd_0.10.2-2_i386.deb
Selecting previously unselected package knxd.
(Reading database ... 204769 files and directories currently installed.)
Preparing to unpack knxd_0.10.2-2_i386.deb ...
Unpacking knxd (0.10.2-2) ...
Setting up knxd (0.10.2-2) ...
Adding group `knxd' (GID 132) ...
Done.
Warning: The home dir /var/lib/knxd you specified can't be accessed: No such file or directory
Adding system user `knxd' (UID 122) ...
Adding new user `knxd' (UID 122) with group `knxd' ...
Not creating home directory `/var/lib/knxd'.
Processing triggers for systemd (215-17+deb8u1) ...
Processing triggers for readahead-fedora (2:1.5.6-5.2) ...
Processing triggers for libc-bin (2.21-0experimental0) ...
# ls -l /etc/*/*knxd*
-rw-r--r-- 1 root root 594 Jun 28 10:40 /etc/default/knxd
-rwxr-xr-x 1 root root 4585 Mai 29 03:49 /etc/init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc0.d/K01knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc1.d/K01knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc2.d/S21knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc3.d/S21knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc4.d/S21knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc5.d/S21knxd -> ../init.d/knxd
lrwxrwxrwx 1 root root 14 Jun 28 17:25 /etc/rc6.d/K01knxd -> ../init.d/knxd
#
Wenn niemand sonst das Problem eingrenzen kann, muss ich wohl mal eine wheezy-Testumgebung aufsetzen. Aber heute wird das nix mehr. :-/
@speedschmidt: diese Warnungen kommen vom alten eibd-Initskript. Nicht meine Schuld. :-P
Weg damit:
# rm /etc/init.d/eibd /etc/rc?.d/???eibd
Nabend,
so nun sind die Links in den rc2,3,4,5.d - Verzeichnissen da(S02knxd). Ich kann nicht sicher sagen, ob die schon immer da waren oder ob die irgendwann mit
sudo update-rc.d knxd 2 3 4 5
angelegt worden sind (wahrscheinlich). Über:
sudo sysv-rc-conf
Bekommt man das ganze auch nochmal grafisch angezeigt. Autostart geht deswegen aber noch immer nicht. Ich wollte euch nur mal auf dem Laufenden halten, weil ich auch mehr oder weniger mit ein paar wikis rumprobiere.
Mal was zum Thema Runlevel. In einigen wiki's sind ja die runlevel recht übersichtlich dargestellt. 0=Halt, 1= Wartung, only root, 2=Multiuser ohne Netzwerk, 3=Multiuser mit Netzwerk usw.. Bei mir in der inittab steht ja bei id:2, was bedeutet standarmäßig Runlevel2 = Multiuser ohne Netzwerk. Benötigt der knxd für den Zugriff auf die IP-Adresse des Kopplers und damit das Netzwerk und somit einen runlevel3? Aber wie gesagt in rc3.d steht auch ein Link S02knxd --> /etc/init.d/knxd
Ingo
Die Runlevels haben unter Debian schon seit einem Jahrzehnt keine wirkliche Bedeutung mehr, in so gut wie allen Initskripts steht 2345 drin.
(Und unter Jessie mit systemd gibt es sie so eh nicht mehr.)
Außerdem hast du doch ein Netzwerk ... und im knxd-Skript steht das auch als Abhängigkeit drin. Allerdings ist S02knxd seltsam, benenn den mal auf S25knxd um (im "richtigen" rcX.d-Verzeichnis), evtl. ist das das Problem.
Du kannst außerdem den is:-Eintrag auf 3 ändern und mal durchbooten ...
High zusammen,
So Linkdatei in rc2.d umbenannt von S02knxd auf S25knxd --> keine Autostart von knxd --> Änderung rückgängig gemacht
id: von 2 auf 3 geändert --> kein Autostart von knxd --> Änderung rückgängig gemacht
anbei nochmal zum drüberschauen meine dateien /etc/init.d/knxd
#!/bin/sh
### BEGIN INIT INFO
# Provides: knxd
# Required-Start: $local_fs $network $remote_fs $syslog
# Required-Stop: $local_fs $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: <knxd>
# Description: <Enter a long description of the software>
# <...>
# <...>
### END INIT INFO
# Author: Timo <knxd@timo-wingender.de>
# Do NOT "set -e"
# PATH should only include /usr/* if it runs after the mountnfs.sh script
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
# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0
# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
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
# The above code will not work for interpreted scripts, use the next
# six lines below instead (Ref: #643337, start-stop-daemon(8) )
#start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \
# --name $NAME --test > /dev/null \
# || return 1
#start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \
# --name $NAME -- $DAEMON_ARGS \
# || return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
#
# If the daemon can reload its configuration without
# restarting (for example, when it is sent a SIGHUP),
# then implement that here.
#
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
#reload|force-reload)
#
# If do_reload() is not implemented then leave this commented out
# and leave 'force-reload' as an alias for 'restart'.
#
#log_daemon_msg "Reloading $DESC" "$NAME"
#do_reload
#log_end_msg $?
#;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
log_end_msg 1
;;
esac
;;
*)
#echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
exit 3
;;
esac
:
# Short-Description: <knxd> im Header hatte ich in knxd geändert, zum Versuch.
und /etc/default/knxd
# Defaults for knxd initscript
# sourced by /etc/init.d/knxd
# installed at /etc/default/knxd by the maintainer scripts
#
# This is a POSIX shell fragment
#
# start knxd when /etc/init.d/knxd start is run
# by default knxd does NOT start. set to YES to enable
START_KNXD=YES
# Additional options that are passed to the Daemon.
#
# for IP interface at 192.168.178.123;
# local Unix Domain Socket /tmp/eib _not_ enabled (-u)
DAEMON_ARGS="-c -D -R -T --eibaddr=1.0.255 --no-tunnel-client-queuing -i -S ipt:192.168.XXX.YYY"
XXX und YYY entspricht meiner IP des kopplers.
Ingo
Was sagt er denn beim Booten -- steht da überhaupt was vom knxd-Skript?
Kannst du dem "-d"-Flag einen Dateinamen verpassen, auf dass er da hineinlogge (und die Log-Level erhöhen, also -d/tmp/knxd.log -f9 -t0xfffc)?
keine Erwähnung von knxd in:
/var/log/messages
Anbei mal meine /var/log/messages als Dateianhang. Vielleicht siehst du Auffälligkeiten.
ich hatte im do_start eingebaut:
echo "knxd wird gestartet"
Beim manuellen Start wird diese Meldung auch angezeigt.
Da sind jetzt leider nur die Kernelnachrichten drin. Die allein helfen mir nicht weiter. (Unter Jessie ist das einfacher, "journalctl -b" spuckt dir einfach alles seit dem letzten Boot aus.)
Meine Frage ist eher, ob das Skript überhaupt ausgeführt wird oder ob der knxd aus irgendwelchen besonderen Gründen auf die Nase fliegt. Daher mein Hinweis in #29.
ich habe den rpi2 ein paar mal booten lassen, aber nichts von knxd gesehen.
die argumente habe ich vorher eingetragen. die logdatei wird aber erst nach dem manuellen start angelegt.
der script scheint soweit in ordnung zu sein, da ich ja mit
/etc/init.d/knxd start
manuell starten kann. der script wird einfach beim booten nicht beachtet.
was mir noch auffält, das der dienst mit
/etc/init.d/knxd stop
nicht beendet wird. da bleibt er irgendwie hängen und der dienst läuft noch. sieht man mit
/etc/init.d/knxd status
muss aber nichts bedeuten, da wir den dienst ja erstmal starten wollen.
ich bin jetzt kurz davor, alles ganz von vorne anfzufangen. die fhem.cfg sicher ich mir aber vorher.
es sieht ja so aus als ob es was system-technisches ist.
Wenn du das eh neu aufsetzen magst, dann gleich mit Jessie ...
uff geschafft -- jessie ist drauf und läuft soweit ich das beurteilen kann "stable".
der knxd startet meiner Meinung nach auch:
pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Mi 2015-07-01 23:09:14 CEST; 11min ago
Process: 485 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
pi@raspberrypi ~ $
23:09Uhr war Systemstart nach upgrade auf jessie.
ABER: groupswrite geht nicht und damit kein zugriff auf eib/knx
pi@raspberrypi ~ $ groupswrite ip:127.0.0.1 0/2/9 0
Open failed: Connection refused
pi@raspberrypi ~ $
Noch Ideen???
Update:
wenn ich via:
/usr/local/bin/eibd -t 1023 -S -D -R -T -i --eibaddr=X.X.X --daemon=/var/log/eibd.log --no-tunnel-client-queuing ipt:192.168.XXX.XXX
den eibd starte, dann kann ich auch mit:
groupswrite ip:127.0.0.1 0/2/9 0
auf den eib zugreifen.
ABER das ganze nicht mit knxd oder per AUTOSTART.
Was mache ich denn bloß verkehrt? Kann ich denn noch irgendwelche logs o.ä. zur Fehlersuche beitragen?
Ingo
Das verstehe ich nicht wirklich; wenn ich den knxd (aktieller master-Branch) mit -i starte, dann macht er einen TCP-Socket auf Port 6720 auf und ein *write funktioniert.
Bitte vergiss nicht, dass du beim knxd das -DRT vor das -S stellen musst; dasselbe gilt für --eibaddr. An deinem aktuellen Problem sollte das aber nichts ändern. (Beim eibd ist die Reihenfolge egal. Ich baue da demnächst eine Warnung ein.)
Starte ihn bitte mal zusätzlich mit "-f 9" (Argument vorne angeben). Schicke mir den Inhalt von /var/log/eibd.log und den Output des Befehls "lsof -p PID-vom-KNXD".
PS: mal ne dumme Frage: Was bringt eigentlich der Obskurantismus bei lokalen IPs und der EIB-Adresse? Wenn sich wirklich jemand in dein lokales Netz einhacken kann, findet er beides sowieso sofort heraus ...
high smurfix
Zitat von: smurfix am 04 Juli 2015, 09:36:28
#Das verstehe ich nicht wirklich; wenn ich den knxd (aktieller master-Branch) mit -i starte, dann macht er einen TCP-Socket auf Port 6720 auf und ein #*write funktioniert.
Ich ehrlich gesagt auch nicht(aktieller master-Branch), aber dass hat nichts zu bedeuten. Ich google mal danach.
Zitat von: smurfix am 04 Juli 2015, 09:36:28
#Bitte vergiss nicht, dass du beim knxd das -DRT vor das -S stellen musst; dasselbe gilt für --eibaddr. An deinem aktuellen Problem sollte das #aber nichts ändern. (Beim eibd ist die Reihenfolge egal. Ich baue da demnächst eine Warnung ein.)
also hier mal die Args von
/etc/default/knxd
DAEMON_ARGS="-f9 -d -D -R -T --daemon=/tmp/knxd.log -t 1023 --eibaddr=1.0.255 --no-tunnel-client-queuing -i -S ipt:192.168.100.34"
Zitat von: smurfix am 04 Juli 2015, 09:36:28
#Starte ihn bitte mal zusätzlich mit "-f 9" (Argument vorne angeben). Schicke mir den Inhalt von /var/log/eibd.log und den Output des Befehls "lsof #-p PID-vom-KNXD".
folgt zeitnah.
Zitat von: smurfix am 04 Juli 2015, 09:36:28
PS: mal ne dumme Frage: Was bringt eigentlich der Obskurantismus bei lokalen IPs und der EIB-Adresse? Wenn sich wirklich jemand in dein lokales Netz einhacken kann, findet er beides sowieso sofort heraus ...
???
high smurfi,
Mein Eibd.log ist ca. 60MB groß - zu groß zum posten. ich zerlege die mal und poste hier die letzten 10.000 Zeilen. Mit dem Befehl
lsof -p 489
kann mein System nichts anfangen
pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-04 22:03:57 CEST; 14min ago
Process: 489 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
pi@raspberrypi ~ $ lsof -p 489
-bash: lsof: Kommando nicht gefunden.
pi@raspberrypi ~ $ Isof -p 489
-bash: Isof: Kommando nicht gefunden.
pi@raspberrypi ~ $ isof -p 489
-bash: isof: Kommando nicht gefunden.
ich hoffe ich stell mich nicht nur zu dumm an.
Ingo
high smurfi,
anbei der Auszug (letzten Zeilen) meiner eibd.log
Zitat von: speedschmidt am 04 Juli 2015, 22:51:35
Mein Eibd.log ist ca. 60MB groß - zu groß zum posten. ich zerlege die mal und poste hier die letzten 10.000 Zeilen.
Du sollst ja auch nicht alles posten, sondern nur den letzten Durchlauf ...
Zitat von: speedschmidt am 04 Juli 2015, 22:51:35Mit dem Befehl
lsof -p 489
kann mein System nichts anfangen
Dann installiere "lsof".
Moinsen!
Bin jetzt der Diskussion nicht bis ins letzte gefolgt, daher vielleicht eine ein wenig unqualifizierte, banale Idee: hast Du vielleicht ein User / Rechteproblem? Probier doch mal nach Autostart ein sudo *write aus...
Grüße, Andi...
Zitat von: Andi291 am 05 Juli 2015, 09:07:41
eine ein wenig unqualifizierte, banale Idee: hast Du vielleicht ein User / Rechteproblem? Probier doch mal nach Autostart ein sudo *write aus...
Wir reden hier von einem TCP-Socket mit Port>1023. Daher: Nö.
Abend!
Probier mal bitte die folgende variante:
1. Beim EIBD-Start von ip auf ipt ändern: eibd ... ipt:<ip_der_eibd_verbidnung>
2. Neu starten (Austostart)
3. route add 224.0.23.12 dev eth0
4. groupswrite ipt:224.0.23.12 0/2/9 0
Hatte mal ein ähnliches Phänoment, bei dem sich "unerlaubterweise" ein anderer Kommunikationspartner eingemischt hat. Der hat meinen Kanal belegt...
Grüße, Andi
Zitat von: Andi291 am 05 Juli 2015, 19:49:42
3. route add 224.0.23.12 dev eth0
das macht keinen Sinn. Multicastadressen gehören nicht in die Routingtabelle. Mal ganz abgesehen davon, dass deine Defaultroute im Zweifelsfall eh schon auf eth0 zeigt.
Zitat von: Andi291 am 05 Juli 2015, 19:49:42
4. groupswrite ipt:224.0.23.12 0/2/9 0
Das kann auch nicht funktionieren, groupswrite et al. verstehen nur local:/pfad/zum/socket und ip:adresse-oder-hostname.
Hallo smurfix,
dann lügen meine Erfahrung und diverse Foren:
http://wiki.linuxmce.org/index.php/EIB/KNX_with_eibd (http://wiki.linuxmce.org/index.php/EIB/KNX_with_eibd)
http://ekblad.org/knx/ (http://ekblad.org/knx/)
http://sourceforge.net/p/bcusdk/mailman/message/30506672/ (http://sourceforge.net/p/bcusdk/mailman/message/30506672/)
Ohne das route add hab ich meinen in multicast config laufenden PI nicht an den Start bekommen. Andere scheinbar auch nicht...
Wegen des groupswrite hast Du natürlich recht. Muss auf IP und 127.0.0.1 lauten...Also so: groupswrite ip:127.0.0.1 0/2/9 0
Hmm. Bei mir funktioniert das anstandslos ohne irgendwelche Routen.
Eine Konfiguration mit -i/-u und ipt: verwendet Multicast nicht einmal; die Daten kommen über TCP- oder Unixsocket rein und gehen über die Tunnel-Verbindung zum Gatway raus.
Mit dem aktuellen knxd sollte das funktionieren, d.h. man kann in der Konstellation das -DTS eigentlich weglassen.
Werde ich gleich mal testen.
@smurfi
Zitat von: smurfix am 05 Juli 2015, 08:46:34
Du sollst ja auch nicht alles posten, sondern nur den letzten Durchlauf ...
Woran erkenne ich den "letzten Durchlauf" (ohne Uhrzeit o.ä.)?
Zitat von: smurfix am 05 Juli 2015, 08:46:34
Dann installiere "lsof".
ich kann mit apt-get kein lsof installieren? gibt es alternative Quellen (wget etc.)? Sorry Linux-Anfänger aber ich bemühe mich.
@andi291
ich hatte dieses Thema in Anfängerfragen schon mal gepostet und inzwischen geschlossen (nach einer teilweise unqualifizierten Antwort eines anderen Users). Auch weil nicht wusste wie man einen Beitrag verschiebt. Aber ich hatte von dir hier schon einiges zu diesem Thema gelesen und ich meine auch größtenteils probiert - leider ohne Erfolg. Mein Problem besteht auch nicht darin den eibd oder knxd überhaupt zu starten. Manuell geht das alles wunderbar (siehe wieter vorn). Aber ich möchte das mein Raspi2 ohne weitere Eingaben wieder komplett zur bedienbaren fhem-Visu hochfährt.
Ingo
Zitat von: speedschmidt am 06 Juli 2015, 23:18:00
@smurfi
Woran erkenne ich den "letzten Durchlauf" (ohne Uhrzeit o.ä.)?
Indem du den Kram in eine neue Datei schreibst!
Zitat von: speedschmidt am 06 Juli 2015, 23:18:00
ich kann mit apt-get kein lsof installieren? gibt es alternative Quellen (wget etc.)? Sorry Linux-Anfänger aber ich bemühe mich.
Sorry, wenn's da bei mir aufhört, aber "lsof" ist ein Standardtool, das seit gefühlten Urzeiten bei Debian dabei ist.
"apt-get update && apt-get install lsof"
hat gefälligst zu funktionieren. Was steht in deiner /etc/apt/sources.list drin? Was genau kommt dabei hinten raus? "Kann ich nicht installieren" ist keine Fehlermeldung!
high
wie kann ich denn den kram in eine neue Datei schreiben. ich habe es versucht mit:
sudo touch /var/log/eibd2.log
/usr/local/bin/eibd -t 1023 -D -R -T -i --eibaddr=15.15.255 --daemon=/var/log/eibd2.log --no-tunnel-client-queuing -S ipt:192.168.100.34.
Can not open file /var/log/eibd2.log
Bitte nähere Hinweise - nochmal ich bin Linuxanfänger und da reicht
" .. in eine neue Datei schreiben ... " nur bedingt, aber ich bin gern bereit etwas neues zu lernen.
lsof habe ich natürlich installiert bekommen. Aber wie bekomme ich die PID vom knxd heraus? folgendes bleibt ohne ausgaben:
sudo service knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:14:48 CEST; 29min ago
Jul 11 13:14:46 raspberrypi knxd[587]: No listen-address given: Success
Jul 11 13:14:48 raspberrypi systemd[1]: Started LSB: <knxd>.
Jul 11 13:30:50 raspberrypi systemd[1]: Started LSB: <knxd>.
pi@raspberrypi /var/log $ lsof -p 587
pi@raspberrypi /var/log $
pi@raspberrypi /var/log $ sudo service knxd start
pi@raspberrypi /var/log $ sudo service knxd restart
pi@raspberrypi /var/log $ sudo service knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:48:19 CEST; 7s ago
Process: 1625 ExecStop=/etc/init.d/knxd stop (code=exited, status=0/SUCCESS)
Process: 1634 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
Jul 11 13:48:19 raspberrypi knxd[1634]: No listen-address given: Success
Jul 11 13:48:19 raspberrypi systemd[1]: Started LSB: <knxd>.
pi@raspberrypi /var/log $ lsof -p 1634
pi@raspberrypi /var/log $
nach eingabe von lsof ohne Optionen werden alle Prozesse angezeigt, aber knxd ist nicht dabei, sollte er nicht?
kworker/3 1508 root txt unknown /proc/1508/exe (readlink: Permission denied)
kworker/3 1508 root NOFD /proc/1508/fd (opendir: Permission denied)
kworker/2 1593 root cwd unknown /proc/1593/cwd (readlink: Permission denied)
kworker/2 1593 root rtd unknown /proc/1593/root (readlink: Permission denied)
kworker/2 1593 root txt unknown /proc/1593/exe (readlink: Permission denied)
kworker/2 1593 root NOFD /proc/1593/fd (opendir: Permission denied)
lsof 1742 pi cwd DIR 179,9 4096 266149 /var/log
lsof 1742 pi rtd DIR 179,9 4096 2 /
lsof 1742 pi txt REG 179,9 170124 24501 /usr/bin/lsof
lsof 1742 pi mem REG 179,9 1607808 4245 /usr/lib/locale/locale-archive
lsof 1742 pi mem REG 179,9 1226392 15722 /lib/arm-linux-gnueabihf/libc-2.19.so
lsof 1742 pi mem REG 179,9 134448 4164 /lib/arm-linux-gnueabihf/ld-2.19.so
lsof 1742 pi mem REG 179,9 10170 7098 /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so
lsof 1742 pi 0u CHR 136,0 0t0 3 /dev/pts/0
lsof 1742 pi 1u CHR 136,0 0t0 3 /dev/pts/0
lsof 1742 pi 2u CHR 136,0 0t0 3 /dev/pts/0
lsof 1742 pi 3r DIR 0,4 0 1 /proc
Aber vielleicht ist 1634 nicht PID von knxd? Oder vielleicht läuft er garnicht????
Ich hoffe diese ausgabe helfen ein bisschen zur fehlereingrenzung.
Ingo
high nochmal
ich hatte in der letzten Woche mal einen neuen Raspi aufgesetzt auf einer neuen SD-Karte. Hiermal die Abfolge in Kurzform:
1. SD-Karte formatiert
2. NOOBS_v1_4_1 auf die Karte kopiert (nach dem extrahieren)
3. SD-Karte in RPi2 und nur Rasbian gewählt
4. in der sourceslist wheezy auf jessie geändert und update und upgrade --> Upgrade auf Jessie erfolgreich
5. knxd nach smurfis readme installiert --> ohne Fehlermeldungen bis auf die Bauäbhängigkeiten und debhelper etc.(siehe mein früherer Beitrag in diesem Thread)
6. bcusdk nachinstalliert - sagt einem ja niemand das man das mit knxd auch noch benötigt.
Zwischendurch noch Firmwareupdate auf 4.irgendwas und zeitservice mit ntp eingestellt.
Ergebniss: kein EIB, kein groupswrite kein knxd und natürlich kein autostart von eibd oder knxd.
Kann mir jemand verraten an welchem Punkt der in der abfolge ich etwas verkehrt gemacht haben könnte.
apropos /etc/apt/source.list:
da steht drin:
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspbian.org/raspbian/ wheezy main contrib non-free rpi
Ingo
Zitatsudo touch /var/log/eibd2.log
/usr/local/bin/eibd -t 1023 -D -R -T -i --eibaddr=15.15.255 --daemon=/var/log/eibd2.log --no-tunnel-client-queuing -S ipt:192.168.100.34.
Can not open file /var/log/eibd2.log
Lass das "sudo touch" weg bzw. ersetze es durch ein "sudo rm", dann funktioniert das.
Wieso "eibd"? Das Ding heißt jetzt knxd ...
Die Adresse 15.15.255 willst du nicht für den knxd verwenden! die ist für ein zu programmierendes Gerät vorgesehen.
Ist der Punkt am Ende der Befehlszeile Absicht?
Zitatsudo service knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:14:48 CEST; 29min ago
Jul 11 13:14:46 raspberrypi knxd[587]: No listen-address given: Success
Du verwendest offenbar den 0.9-Zweig. Ich würde mich freuen, wenn du auch den aktuellen Master-Zweig testen würdest.
Da steht "(exited)". D.h. das Tier läuft nicht mehr und dann liefert dir "lsof" natürlich auch keine Infos. Angesichts der Fehlermeldung wundert mich das nicht. Was steht in deiner /etc/knxd.conf?
Die PID eines Prozesses findest du mit "systemctl status NAME.service" raus, da steht dann was von "Main PID".
Zitat von: speedschmidt am 11 Juli 2015, 14:14:26
6. bcusdk nachinstalliert - sagt einem ja niemand das man das mit knxd auch noch benötigt.
??? Also ich brauche das gar nicht ... was hat dich dazu gebracht und was genau hast du getan?
Zitat von: smurfix am 11 Juli 2015, 14:42:47
Lass das "sudo touch" weg bzw. ersetze es durch ein "sudo rm", dann funktioniert das.
Wieso "eibd"? Das Ding heißt jetzt knxd ...
1. funktioniert auch nicht mit sudo rm
pi@raspberrypi / $ sudo rm /var/log/eibd2.log
pi@raspberrypi / $ /usr/local/bin/eibd -t 1023 -D -R -T -i --eibaddr=15.15.255 --daemon=/var/log/eibd2.log --no-tunnel-client-queuing -S ipt:192.168.100.34
Can not open file /var/log/eibd2.log
pi@raspberrypi / $ /usr/local/bin/eibd -t 1023 -D -R -T -i --eibaddr=1.0.255 --daemon=/var/log/eibd2.log --no-tunnel-client-queuing -S ipt:192.168.100.34
Can not open file /var/log/eibd2.log
pi@raspberrypi / $
2. du hattest weiter oben nach dem inhalt der eibd.log gefragt, aber egal machen wir ab jetzt nur noch mit knxd weiter.
3. die Datei /tmp/knxd.log (steht in den Argumenten von /etc/Default/knxd) ist nicht vorhanden
Zitat von: smurfix am 11 Juli 2015, 14:42:47
Die Adresse 15.15.255 willst du nicht für den knxd verwenden! die ist für ein zu programmierendes Gerät vorgesehen.
Ist der Punkt am Ende der Befehlszeile Absicht?
1. ich hatte in meiner ets-schnittstelle nachgeschaut und da stand 15.15.255, habe es (ohne nachzuschauen) übernommen und jetzt steht da 1.0.255 (ich meine wie früher auch ???)
2. der punkt ist mit copy-paste mit reingerutscht.
Zitat von: smurfix am 11 Juli 2015, 14:42:47
Du verwendest offenbar den 0.9-Zweig. Ich würde mich freuen, wenn du auch den aktuellen Master-Zweig testen würdest.
Da steht "(exited)". D.h. das Tier läuft nicht mehr und dann liefert dir "lsof" natürlich auch keine Infos. Angesichts der Fehlermeldung wundert mich das nicht. Was steht in deiner /etc/knxd.conf?
Die PID eines Prozesses findest du mit "systemctl status NAME.service" raus, da steht dann was von "Main PID".
1. ich würde mich ebenso freuen, wenn ich den aktuellen masterzweig testen könnte, wenn ich nur wüsste wie genau das geht.
2. die Datei /etc/knxd.conf ist nicht vorhanden
3. nix von MAIN PID, aber schau mal selbst:
pi@raspberrypi / $ sudo systemctl status knxd.service
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:48:19 CEST; 1h 27min ago
Process: 1625 ExecStop=/etc/init.d/knxd stop (code=exited, status=0/SUCCESS)
Process: 1634 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
Jul 11 13:48:19 raspberrypi knxd[1634]: No listen-address given: Success
Jul 11 13:48:19 raspberrypi systemd[1]: Started LSB: <knxd>.
pi@raspberrypi / $
ingo
Zitat von: speedschmidt am 11 Juli 2015, 15:16:01
1. funktioniert auch nicht mit sudo rm
Immer diese seltsamen Berechtigungen. Dann schreib die Datei nach /tmp, das geht auf jeden Fall.
Zitat
3. die Datei /tmp/knxd.log (steht in den Argumenten von /etc/Default/knxd) ist nicht vorhanden
Zitat
1. ich hatte in meiner ets-schnittstelle nachgeschaut und da stand 15.15.255, habe es (ohne nachzuschauen) übernommen und jetzt steht da 1.0.255 (ich meine wie früher auch ???)
2. der punkt ist mit copy-paste mit reingerutscht.
1. ich würde mich ebenso freuen, wenn ich den aktuellen masterzweig testen könnte, wenn ich nur wüsste wie genau das geht.
2. die Datei /etc/knxd.conf ist nicht vorhanden
Sorry, da habe ich nicht genau genug hingesehen: natürlich /etc/default/knxd, nachdem du das Tier via /etc/init.d/knxd startest.
Zitat
3. nix von MAIN PID, aber schau mal selbst:
pi@raspberrypi / $ sudo systemctl status knxd.service
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:48:19 CEST; 1h 27min ago
Ja. Eben. "exited". Ein nicht mehr laufender Prozess kann auch offenen Dateien haben. :P
Zitat von: smurfix am 11 Juli 2015, 14:45:52
??? Also ich brauche das gar nicht ... was hat dich dazu gebracht und was genau hast du getan?
es war ein versuch es zum laufen zu bringen. mein ziel:
aus einer leeren SD-Karte ein Betriebssystem zu erstellen mit dem ich per groupswrite-Befehlen auf meinen eib senden kann, nur so als testumgebung, ohne fhem etc, als Basis quasi. mitgeloggt habe ich natürlich nichts detailiertes, aber das macht doch die bash-history, steht die bash-history eigentlich irgendwo in einer Datei, die ich dir dann schicken könnte?
ingo
Zitat von: speedschmidt am 11 Juli 2015, 16:16:00
es war ein versuch es zum laufen zu bringen. mein ziel:
aus einer leeren SD-Karte ein Betriebssystem zu erstellen mit dem ich per groupswrite-Befehlen auf meinen eib senden kann, nur so als testumgebung, ohne fhem etc, als Basis quasi. mitgeloggt habe ich natürlich nichts detailiertes, aber das macht doch die bash-history, steht die bash-history eigentlich irgendwo in einer Datei, die ich dir dann schicken könnte?
ingo
ja, schon, .bashrc, aber ich frage mich trotzdem wieso du überhaupt auf die Idee gekommen bist, das zu brauchen. Weil ich brauch's nicht.
Ich reproduzier das die Tage mal ...
Zitat von: smurfix am 11 Juli 2015, 15:56:07
Immer diese seltsamen Berechtigungen. Dann schreib die Datei nach /tmp, das geht auf jeden Fall.
hier die ersten und letzen zeilen der aktuellen /var/log/eibd.log, dazwischen liegen nur ein paar eib-befehle. vorher mit
pi@raspberrypi ~ $ sudo /usr/local/bin/eibd -t 1023 -D -R -T -i --eibaddr=1.0.255 --daemon=/var/log/eibd.log --no-tunnel-client-queuing -S ipt:192.168.100.34
gestartet
Layer 2(009E4988,55A104FC) Open
initialisation of the backend failed
Layer 2(01330988,55A127A6) Open
Layer 0(01330E50,55A127A6) Open
Layer 0(01330E50,55A127A6) Openend
Layer 2(01330988,55A127A6) Opened
Layer 3(013518B8,55A127A6) Open
Layer 8(01330F30,55A127A6) OpenInetSocket 6720
Layer 8(01330F30,55A127A6) InetSocket opened
Layer 8(013722C0,55A127A6) Open
Layer 0(01372330,55A127A6) Open
Layer 0(01372330,55A127A6) Openend
Layer 3(013518B8,55A127A6) registerBroadcast 013722C0
Layer 3(013518B8,55A127A6) registerBroadcast 013722C0 = 1
Layer 3(013518B8,55A127A6) registerGroup 013722C0
Layer 3(013518B8,55A127A6) registerGroup 013722C0 = 1
Layer 3(013518B8,55A127A6) registerIndividual 013722C0 0
Layer 3(013518B8,55A127A6) registerIndividual 013722C0 = 1
Layer 8(013722C0,55A127A6) Opened
Layer 4(01392DB0,55A127A6) GroupCacheInit
Layer 1(01330E50,55A127A6) Send(020): 08 01 C0 A8 64 1E 0E 58 08 01 C0 A8 64 1E 0E 58 04 04 02 00
Layer 0(01330E50,55A127A6) Send(026): 06 10 02 05 00 1A 08 01 C0 A8 64 1E 0E 58 08 01 C0 A8 64 1E 0E 58 04 04 02 00
Layer 0(01330E50,55A127A6) Recv(020): 06 10 02 06 00 14 4D 00 08 01 C0 A8 64 22 0E 57 04 04 10 FF
Layer 1(01330E50,55A127A6) Recv(014): 4D 00 08 01 C0 A8 64 22 0E 57 04 04 10 FF
Layer 0(01330E50,55A127A7) Recv(023): 06 10 04 20 00 17 04 4D 00 00 29 00 BC D0 13 01 59 03 03 00 80 54 9B
Layer 1(01330E50,55A127A7) Recv(017): 04 4D 00 00 29 00 BC D0 13 01 59 03 03 00 80 54 9B
Layer 1(01330E50,55A127A7) Send(004): 04 4D 00 00
Layer 0(01330E50,55A127A7) Send(010): 06 10 04 21 00 0A 04 4D 00 00
Layer 1(01330988,55A127A7) Recv L_Data low from 1.3.1 to 11/1/3 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 54 9B
Layer 2(01330988,55A127A7) Recv L_Data low from 1.3.1 to 11/1/3 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 54 9B
Layer 3(013518B8,55A127A7) Recv L_Data low from 1.3.1 to 11/1/3 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 54 9B
Layer 8(013722C0,55A127A7) Send_Route L_Data low from 1.3.1 to 11/1/3 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 54 9B
Layer 1(01372330,55A127A7) Send(013): 29 00 BC C0 13 01 59 03 03 00 80 54 9B
Layer 0(01372330,55A127A7) Send(019): 06 10 05 30 00 13 29 00 BC C0 13 01 59 03 03 00 80 54 9B
Layer 8(01330F30,55A127AA) New Connection
Layer 8(01394D38,55A127AA) ClientConnection Init
Layer 8(01394D38,55A127AA) RecvMessage(005): 00 26 00 00 00
Layer 7(013A5204,55A127AA) OpenGroupSocket
Layer 4(01394820,55A127AA) OpenGroupSocket RW
Layer 3(013518B8,55A127AA) registerGroup 01394820
Layer 3(013518B8,55A127AA) registerGroup 01394820 = 1
Layer 8(01394D38,55A127AA) SendMessage(002): 00 26
Layer 0(01330E50,55A127AD) Recv(023): 06 10 04 20 00 17 04 4D 01 00 29 00 BC D0 12 04 6B 00 03 00 80 02 BC
Layer 1(01330E50,55A127AD) Recv(017): 04 4D 01 00 29 00 BC D0 12 04 6B 00 03 00 80 02 BC
Layer 1(01330E50,55A127AD) Send(004): 04 4D 01 00
Layer 0(01330E50,55A127AD) Send(010): 06 10 04 21 00 0A 04 4D 01 00
Layer 1(01330988,55A127AD) Recv L_Data low from 1.2.4 to 13/3/0 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 02 BC
Layer 2(01330988,55A127AD) Recv L_Data low from 1.2.4 to 13/3/0 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 02 BC
Layer 3(013518B8,55A127AD) Recv L_Data low from 1.2.4 to 13/3/0 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 02 BC
Layer 8(013722C0,55A127AD) Send_Route L_Data low from 1.2.4 to 13/3/0 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 02 BC
Layer 1(01372330,55A127AD) Send(013): 29 00 BC C0 12 04 6B 00 03 00 80 02 BC
Layer 0(01372330,55A127AD) Send(019): 06 10 05 30 00 13 29 00 BC C0 12 04 6B 00 03 00 80 02 BC
Layer 4(01394820,55A127AD) Recv GroupSocket(004): 00 80 02 BC
Layer 7(013A5204,55A127AD) Recv(004): 00 80 02 BC
Layer 8(01394D38,55A127AD) SendMessage(010): 00 27 12 04 6B 00 00 80 02 BC
Layer 0(01330E50,55A127B2) Recv(023): 06 10 04 20 00 17 04 4D 02 00 29 00 BC D0 11 07 60 00 03 00 80 0D 2D
Layer 1(01330E50,55A127B2) Recv(017): 04 4D 02 00 29 00 BC D0 11 07 60 00 03 00 80 0D 2D
Layer 1(01330E50,55A127B2) Send(004): 04 4D 02 00
.
.
.
.
Layer 8(013722C0,55A12871) Send_Route L_Data low from 1.1.3 to 2/0/0 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
Layer 1(01372330,55A12871) Send(011): 29 00 BC C0 11 03 10 00 01 00 80
Layer 0(01372330,55A12871) Send(017): 06 10 05 30 00 11 29 00 BC C0 11 03 10 00 01 00 80
Layer 4(01394820,55A12871) Recv GroupSocket(002): 00 80
Layer 7(013A5204,55A12871) Recv(002): 00 80
Layer 8(01394D38,55A12871) SendMessage(008): 00 27 11 03 10 00 00 80
Layer 1(01330988,55A12878) Heartbeat
Layer 1(01330E50,55A12878) Send(010): 4D 00 08 01 C0 A8 64 1E 0E 58
Layer 0(01330E50,55A12878) Send(016): 06 10 02 07 00 10 4D 00 08 01 C0 A8 64 1E 0E 58
Layer 0(01330E50,55A12878) Recv(008): 06 10 02 08 00 08 4D 00
Layer 1(01330E50,55A12878) Recv(002): 4D 00
Layer 8(01330F30,55A12883) StopServer
Layer 7(013A5204,55A12883) CloseGroupSocket
Layer 4(01394820,55A12883) CloseGroupSocket
Layer 3(013518B8,55A12883) deregisterGroupCallBack 01394820 = 1
Layer 8(01394D38,55A12883) ClientConnection closed
Layer 8(01330F30,55A12883) Server ended
Layer 8(013722C0,55A12883) Close
Layer 3(013518B8,55A12883) deregisterBroadcast 013722C0 = 1
Layer 3(013518B8,55A12883) deregisterGroupCallBack 013722C0 = 1
Layer 3(013518B8,55A12883) deregisterIndividual 013722C0 = 1
Layer 0(01372330,55A12883) Close
Layer 4(01392DB0,55A12883) GroupCacheDestroy
Layer 4(01392DB0,55A12883) GroupCacheClear
Layer 3(013518B8,55A12883) Close
Layer 2(01330988,55A12883) Close
Layer 1(01330E50,55A12883) Send(010): 4D 00 08 01 C0 A8 64 1E 0E 58
Layer 0(01330E50,55A12883) Send(016): 06 10 02 09 00 10 4D 00 08 01 C0 A8 64 1E 0E 58
Layer 0(01330E50,55A12883) Close
Zitat von: smurfix am 11 Juli 2015, 15:56:07
Sorry, da habe ich nicht genau genug hingesehen: natürlich /etc/default/knxd, nachdem du das Tier via /etc/init.d/knxd startest.Ja. Eben. "exited". Ein nicht mehr laufender Prozess kann auch offenen Dateien haben. :P
es sind keine Dateien mehr offen:
pi@raspberrypi / $ sudo service knxd status
● knxd.service - LSB: <knxd>
Loaded: loaded (/etc/init.d/knxd)
Active: active (exited) since Sa 2015-07-11 13:48:19 CEST; 2h 31min ago
Process: 1625 ExecStop=/etc/init.d/knxd stop (code=exited, status=0/SUCCESS)
Process: 1634 ExecStart=/etc/init.d/knxd start (code=exited, status=0/SUCCESS)
Jul 11 13:48:19 raspberrypi knxd[1634]: No listen-address given: Success
Jul 11 13:48:19 raspberrypi systemd[1]: Started LSB: <knxd>.
pi@raspberrypi / $ lsof -p 1625
pi@raspberrypi / $ lsof -p 1634
pi@raspberrypi / $
Zitat von: smurfix am 11 Juli 2015, 15:56:07
Was steht in deiner /etc/knxd.conf
[/qoute]
das hier:
# configuration file for knxd.service
KNXD_OPTS=""
KNXD_URL="ip:224.0.23.12"
ingo
high
Zitat von: smurfix am 11 Juli 2015, 16:44:12
ja, schon, .bashrc, aber ich frage mich trotzdem wieso du überhaupt auf die Idee gekommen bist, das zu brauchen. Weil ich brauch's nicht.
Ich reproduzier das die Tage mal ...
1. die .bashrc sind scripts, da wird nichts reingeloggt, soweit ich das mit:
pi@raspberrypi ~ $ sudo locate bashrc
/etc/bash.bashrc
/etc/skel/.bashrc
/etc/skel/.bashrc.dpkg-old
/home/pi/.bashrc
/root/.bashrc
/usr/share/base-files/dot.bashrc
/usr/share/doc/adduser/examples/adduser.local.conf.examples/bash.bashrc
/usr/share/doc/adduser/examples/adduser.local.conf.examples/skel/dot.bashrc
pi@raspberrypi ~ $ sudo nano /home/pi/.bashrc
pi@raspberrypi ~ $ sudo nano /etc/bash.bashrc
pi@raspberrypi ~ $ sudo nano /usr/share/base-files/dot.bashrc
pi@raspberrypi ~ $
sehen konnten.
ich wechsel nochmal auf die "neue" SD und mache mal ein Recovery und fange mal neu an -- NEIN upgrade auf jessie dauert eine stunde.
Idee!
wie kann ich eibd, bcusdk, pthsem und knxd wieder sicher entfernen. etwa mit purge paketname?
ingo
high
Zitat von: smurfix am 11 Juli 2015, 14:45:52
.....und was genau hast du getan?
1. SD-Karte formatiert
2. NOOBS_v1_4_1 auf die Karte kopiert (nach dem extrahieren)
3. SD-Karte in RPi2 und nur Rasbian gewählt
4. in der sourceslist wheezy auf jessie geändert und update und upgrade --> Upgrade auf Jessie erfolgreich
5. knxd nach smurfis readme installiert ergänzt mit
pi@raspberrypi ~ $ sudo apt-get install build-essential libtool automake pkg-config cdbs libsystemd-daemon-dev debhelper libusb-1.0.0-dev
nachdem grouswrite eine Fehlermeldung auspukte dachte ich mir da fehlt wohl noch eibd und habe
6. bcusdk nachinstalliert nach dieser Anleitung:
http://blog.schwabl.net/2013/02/24/eibd-on-raspberry-pi/ (http://blog.schwabl.net/2013/02/24/eibd-on-raspberry-pi/)
ingo
Zitat von: speedschmidt am 11 Juli 2015, 16:53:51
high
1. die .bashrc sind scripts
Sorry, meinte natürlich .bash_history. :-\
Zitat
nachdem grouswrite eine Fehlermeldung auspukte dachte ich mir da fehlt wohl noch eibd und habe
6. bcusdk nachinstalliert nach dieser Anleitung:
A:
Welche Fehlermeldung??
B: knxd ist der Ersatz für / neue Version von eibd. Es kann nicht sein, dass "eibd fehlt" – du hast höchstens einen zuviel.
Ich dachte eigentlich, das wäre sowas von offensichtlich ...
high
mein vorschlag:
1. bcusdk mit make unisntall wieder deinsatllieren --> ist schon erledigt
2. deine install-anleitung nochmal durchführen (ohne runterladen von knxd, pthsem die habe ich ja schon).
3. Fehlermeldung notieren und hier posten
bis dann
ingo
Zitat von: speedschmidt am 11 Juli 2015, 22:01:34
high
mein vorschlag:
1. bcusdk mit make unisntall wieder deinsatllieren --> ist schon erledigt
2. deine install-anleitung nochmal durchführen (ohne runterladen von knxd, pthsem die habe ich ja schon).
3. Fehlermeldung notieren und hier posten
bis dann
ingo
so erledigt:
PTHSEM 2.0.8
cd pthsem-2.0.8 erfolgreich
sudo dpkg-buildpackage -b erfolgreich
cd .. erfolgreich
sudo dpkg -i libpthsem*.deb erfolgreich
knxd
git clone https://github.com/knxd/knxd.git erfolgreich ich hoffe so bekomme ich das neue master-teil
dpkg-buildpackage -b erfolgreich hat beim bauen was von 0.10.2-4 gesagt
sudo dpkg -i knxd_*.deb knxd-tools_*.deb erfolgreich
wenn ich schreibe "erfolgreich", dann hat es keinen programabruch gegeben, es kann aber sein das es fehlermeldungen gab, welche ich als solche nicht in der lage bin
zu interpretieren - klar?
/etc/default/knxd
# Defaults for knxd initscript
# sourced by /etc/init.d/knxd
# installed at /etc/default/knxd by the maintainer scripts
# This file is ignored when using systemd: edit /etc/knxd.conf instead
#
# This is a POSIX shell fragment
#
# start knxd when /etc/init.d/knxd start is run
# by default knxd does NOT start. set to YES to enable
START_KNXD=YES
# Additional options that are passed to the Daemon.
#
# for IP interface at 192.168.178.123;
# local Unix Domain Socket /tmp/eib _not_ enabled (-u)
DAEMON_ARGS="-c -D -R -T --no-tunnel-client-queuing -i -S ipt:192.168.100.34"
sudo reboot
wie geht es weiter?
pi@raspberrypi ~ $ groupswrite ip:127.0.0.1 0/2/9 0
-bash: groupswrite: Kommando nicht gefunden.
pi@raspberrypi ~ $
geht jedenfalls nicht. evtl. Verzeichnisse?
ingo
high
ergebniss
pi@raspberrypi ~ $ sudo service knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; disabled)
Active: inactive (dead)
pi@raspberrypi ~ $
ingo
high
manueller start geht schonmal
pi@raspberrypi ~ $ sudo service knxd start
pi@raspberrypi ~ $ sudo service knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; disabled)
Active: active (running) since Sa 2015-07-11 04:32:47 CEST; 4s ago
Main PID: 2494 (knxd)
CGroup: /system.slice/knxd.service
└─2494 /usr/bin/knxd -u -b ip:
Jul 11 04:32:47 raspberrypi systemd[1]: Started KNX Daemon.
pi@raspberrypi ~ $
aber kein autostart und kein groupswrite. wie sende ich denn mit knxd auf den eib?
ingo
Autostart: "systemctl knxd enable" sollte tun.
groupswrite: das liegt in /usr/share/knxd/examples/bin/groupswrite rum, wenn du knxd-examples*.deb installiert hast.
Ja, ich weiß dass das so Unsinn ist, aber das ist nicht auf meinem Mist gewachsen und ich bin noch nicht dazu gekommen, das auch noch aufzuräumen. :-\
Zitat von: smurfix am 11 Juli 2015, 23:54:33
Autostart: "systemctl knxd enable" sollte tun.
groupswrite: das liegt in /usr/share/knxd/examples/bin/groupswrite rum, wenn du knxd-examples*.deb installiert hast.
Ja, ich weiß dass das so Unsinn ist, aber das ist nicht auf meinem Mist gewachsen und ich bin noch nicht dazu gekommen, das auch noch aufzuräumen. :-\
OK, aufgeräumt. groupswrite etc. sind jetzt in /usr/lib/knxd, d.h. nach dem Installieren von knxd-tools kann man Folgendes tun:
PATH=/usr/lib/knxd:$PATH
groupswrite ip: 1/2/3 4oder
knxtool groupswrite ip: 1/2/3 4oder
cd /usr/local/bin; sudo ln -s /usr/lib/knxd/* .
groupswrite ip: 1/2/3 4Ich kann nicht sämtliche Tools/Symlinks in /usr/bin zu installieren, das sind einfach zu viele, das hauen mir die Debian-Leute um die Ohren. :-[
ip: ohne was hinter dem Doppelpunkt geht jetzt auf localhost, statt auf die Nase zu fliegen. (knxd mit -i starten.)
local: dito, verwendet /run/knxd (statt /tmp/eibd); wer aus Kompatibililtätsgründen Beides haben will, kann dem knxd problemlos zwei -u-Argumente verpassen. (Das geht aber nur im master-Zweig. Alternative: lege einen Symlink an.)
high smurfi
Zitat von: smurfix am 11 Juli 2015, 23:54:33
Autostart: "systemctl knxd enable" sollte tun.
nein tut nicht:
i@raspberrypi ~ $ sudo systemctl knxd enable
Unknown operation 'knxd'.
pi@raspberrypi ~ $ cd knxd
pi@raspberrypi ~/knxd $ sudo systemctl knxd enable
Unknown operation 'knxd'.
pi@raspberrypi ~/knxd $
Zitat von: smurfix am 11 Juli 2015, 23:54:33
groupswrite: das liegt in /usr/share/knxd/examples/bin/groupswrite rum, wenn du knxd-examples*.deb installiert hast.
Ja, ich weiß dass das so Unsinn ist, aber das ist nicht auf meinem Mist gewachsen und ich bin noch nicht dazu gekommen, das auch noch aufzuräumen. :-\
nein ich habe nicht knxd-examples*.deb installiert - höre bzw. lese ich zum ersten mal - sorry. soll ich 's selber mit apt-get probieren oder gibst du mir hinweise wo ich 's herbekomme (ich dachte ja das läuft halb-automatisch mit git get?)?
ingo
Dann eben "systemctl enable knxd". Sorry, bei all den verschiedenen Tools kommt man manchmal durcheinander.
Nein, das geht natürlich nicht mit apt-get. "sudo dpkg -i knxd-examples*.deb" installiert es dir aber. Oder du aktualisierst dein git-Repo ("git pull") und baust die Pakete neu, dann ist der ganze Kram in knxd-tools – wo er hingehört. Siehe mein letzter Beitrag.
high
halojulia ... es funzt wieder was:
autostart geht jetzt:
pi@raspberrypi ~ $ sudo service knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since So 2015-07-12 03:40:57 CEST; 1min 0s ago
Main PID: 536 (knxd)
CGroup: /system.slice/knxd.service
└─536 /usr/bin/knxd -u -b ip:
Jul 12 03:40:57 raspberrypi systemd[1]: Started KNX Daemon.
pi@raspberrypi ~ $ sudo git pull https://github.com/knxd/knxd.git
fatal: Not a git repository (or any of the parent directories): .git
pi@raspberrypi ~ $
dafür kein git pull, oder mache ich was falsch?
ingo
high,
ja ich mache was falsch - ich muss das natürlich in dem Verzeichnis ausführen wo es auch liegt.
ingo
he he jetzt nicht schlapp machen so kurz vorm ziel:
bitte kommentieren:
pi@raspberrypi ~ $ sudo dpkg -i knxd_*.deb knxd-tools_*.deb
dpkg: Warnung: Version 0.10.3-4 des Paketes knxd wird durch ältere Version 0.10.2-4 ersetzt
(Lese Datenbank ... 100991 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von knxd_0.10.2-4_armhf.deb ...
Warning: Stopping knxd.service, but it can still be activated by:
knxd.socket
Entpacken von knxd (0.10.2-4) über (0.10.3-4) ...
Vorbereitung zum Entpacken von knxd_0.10.3-4_armhf.deb ...
Entpacken von knxd (0.10.3-4) über (0.10.2-4) ...
Vorbereitung zum Entpacken von knxd-tools_0.10.2-4_armhf.deb ...
Entpacken von knxd-tools (0.10.2-4) über (0.10.2-4) ...
Vorbereitung zum Entpacken von knxd-tools_0.10.3-4_armhf.deb ...
Entpacken von knxd-tools (0.10.3-4) über (0.10.2-4) ...
dpkg: Fehler beim Bearbeiten des Archivs knxd-tools_0.10.3-4_armhf.deb (--install):
Versuch, »/usr/lib/libeibclient.so.0.0.0« zu überschreiben, welches auch in Paket knxd 0.10.3-4 ist
Mehr als eine Kopie des Paketes knxd wurde in diesem Durchlauf
entpackt! Es wird nur einmal konfiguriert.
knxd (0.10.3-4) wird eingerichtet ...
addgroup: Die Gruppe »knxd« existiert bereits als Systemgruppe. Programmende.
Warnung: Das von Ihnen angegebene Home-Verzeichnis /var/lib/knxd existiert bereits.
Der Systembenutzer »knxd« existiert bereits. Programmende.
knxd-tools (0.10.2-4) wird eingerichtet ...
Trigger für systemd (215-17+deb8u1) werden verarbeitet ...
Trigger für libc-bin (2.19-18) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
knxd-tools_0.10.3-4_armhf.deb
pi@raspberrypi ~ $
ingo
high,
oder habe ich schon wieder sche... gebaut - hä Wortwitz.
ingo
Nee, kein Thema, Bug im Packaging. Ist in der aktuellen Version behoben.
high smurfi
pi@raspberrypi ~ $ sudo dpkg -i knxd_*.deb knxd-tools_*.deb
dpkg: Warnung: Version 0.10.3-5 des Paketes knxd wird durch ältere Version 0.10.2-4 ersetzt
(Lese Datenbank ... 100986 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von knxd_0.10.2-4_armhf.deb ...
Warning: Stopping knxd.service, but it can still be activated by:
knxd.socket
Entpacken von knxd (0.10.2-4) über (0.10.3-5) ...
Vorbereitung zum Entpacken von knxd_0.10.3-4_armhf.deb ...
Entpacken von knxd (0.10.3-4) über (0.10.2-4) ...
Vorbereitung zum Entpacken von knxd_0.10.3-5_armhf.deb ...
Entpacken von knxd (0.10.3-5) über (0.10.3-4) ...
Vorbereitung zum Entpacken von knxd-tools_0.10.2-4_armhf.deb ...
Entpacken von knxd-tools (0.10.2-4) über (0.10.2-4) ...
Vorbereitung zum Entpacken von knxd-tools_0.10.3-4_armhf.deb ...
Entpacken von knxd-tools (0.10.3-4) über (0.10.2-4) ...
dpkg: Fehler beim Bearbeiten des Archivs knxd-tools_0.10.3-4_armhf.deb (--install):
Versuch, »/usr/lib/knxd/groupcachelastupdates« zu überschreiben, welches auch in Paket knxd 0.10.3-5 ist
Vorbereitung zum Entpacken von knxd-tools_0.10.3-5_armhf.deb ...
Entpacken von knxd-tools (0.10.3-5) über (0.10.2-4) ...
dpkg: Fehler beim Bearbeiten des Archivs knxd-tools_0.10.3-5_armhf.deb (--install):
Versuch, »/usr/lib/knxd/eibwrite-cgi« zu überschreiben, welches auch in Paket knxd 0.10.3-5 ist
Mehr als eine Kopie des Paketes knxd wurde in diesem Durchlauf
entpackt! Es wird nur einmal konfiguriert.
knxd-tools (0.10.2-4) wird eingerichtet ...
knxd (0.10.3-5) wird eingerichtet ...
addgroup: Die Gruppe »knxd« existiert bereits als Systemgruppe. Programmende.
Warnung: Das von Ihnen angegebene Home-Verzeichnis /var/lib/knxd existiert bereits.
Der Systembenutzer »knxd« existiert bereits. Programmende.
Trigger für systemd (215-17+deb8u1) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
knxd-tools_0.10.3-4_armhf.deb
knxd-tools_0.10.3-5_armhf.deb
pi@raspberrypi ~ $
???, kann ich dir noch irgendein log zur fehlereingrenzung schicken?
Ingo
Nö, aber du kannst die alten .deb-Dateien löschen² und die alten knx*-Pakete deinstallieren¹, bevor du die neuen installierst.
Die Anleitung geht halt davon aus, dass du keinen alten Kram rumliegen hast ...
¹: Alte Pakete zu deinstallieren ist normalerweise unnötig. Hier ist es sinnvoll wegen des Dateikonflikts.
²: oder nur die .deb-Dateien mit der aktuellen Versionsnummer installieren
high,
ich bin mir nicht ganz sicher,welche deb ich löschen darf. Alle *knxd* die älter als 10.3-5 sind? Oder anders herum gefragt welche muss ich zwingend behalten?
pi@raspberrypi ~ $ dir
$ knxd knxd-examples_0.10.2-4_armhf.deb Musik
bcusdk-0.0.5 knxd_0.10.2-4_armhf.changes knxd-examples_0.10.3-4_armhf.deb Öffentlich
bcusdk_0.0.5.tar.gz knxd_0.10.2-4_armhf.deb knxd-examples_0.10.3-5_armhf.deb pthsem-2.0.8
Bilder knxd_0.10.3-4_armhf.changes knxd-tools_0.10.2-4_armhf.deb pthsem_2.0.8_armhf.changes
Desktop knxd_0.10.3-4_armhf.deb knxd-tools_0.10.3-4_armhf.deb pthsem_2.0.8.tar.gz
Dokumente knxd_0.10.3-5_armhf.changes knxd-tools_0.10.3-5_armhf.deb pthsem_2.0.8.tar.gz.1
download knxd_0.10.3-5_armhf.deb libpthsem20_2.0.8_armhf.deb python_games
Downloads knxd-dev_0.10.2-4_all.deb libpthsem-compat_2.0.8_armhf.deb sudo
echo knxd-dev_0.10.3-4_all.deb libpthsem-dbg_2.0.8_armhf.deb Videos
indiecity knxd-dev_0.10.3-5_all.deb libpthsem-dev_2.0.8_armhf.deb Vorlagen
pi@raspberrypi ~ $
die die ich lösche muss ich auch (vorher/nachher) deinstallieren?
ingo
Offensichtlich kannst du alle mit alter Versionsnummer, also hier kleiner 0.10.3-5, löschen. Wozu solltest du die noch brauchen??
Deinstallieren und *.deb-Dateien löschen hat nichts miteinander zu tun!
high,
ich weiß ganz simple anfängerfrage:
Kann ich die Paketdatei löschen und anschließend noch deinstallieren? oder wird die Paketdatei zum deinstallieren noch benötigt?
ingo
high
die alten Pakete habe ich mit
sudo dpkg -r knxd-tools
sudo dpkg -r knxd
deinstalliert und anschliessend mit
sudo rm XXXX.deb
pi@raspberrypi ~ $ dir
$ indiecity libpthsem-compat_2.0.8_armhf.deb pthsem_2.0.8.tar.gz.1
bcusdk-0.0.5 knxd libpthsem-dbg_2.0.8_armhf.deb python_games
Bilder knxd_0.10.3-5_armhf.changes libpthsem-dev_2.0.8_armhf.deb sudo
Desktop knxd_0.10.3-5_armhf.deb Musik Videos
Dokumente knxd-dev_0.10.3-5_all.deb Öffentlich Vorlagen
download knxd-examples_0.10.3-5_armhf.deb pthsem-2.0.8
Downloads knxd-tools_0.10.3-5_armhf.deb pthsem_2.0.8_armhf.changes
echo libpthsem20_2.0.8_armhf.deb pthsem_2.0.8.tar.gz
pi@raspberrypi ~ $
die alten dateien gelöscht
wobei vorher mit
dpkg -l
ein paket knxd mit der Version 0.10.3-5 und ein weiteres paket knxd-tools in der Version 0.10.2-4 aufgelistet wurde.
ich habe dann erst das knxd-tools deinstalliert (knxd ist ja in der Version i.o) habe dann aber bei der Installation von knxd-tools Fehlermeldungen kassiert. also nochmal beides deinstalliert und immer noch Fehlermeldungen:
pi@raspberrypi ~ $ sudo dpkg -i knxd_*.deb knxd-tools_*.deb
(Lese Datenbank ... 100981 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von knxd_0.10.3-5_armhf.deb ...
Entpacken von knxd (0.10.3-5) über (0.10.3-5) ...
Vorbereitung zum Entpacken von knxd-tools_0.10.3-5_armhf.deb ...
Entpacken von knxd-tools (0.10.3-5) ...
dpkg: Fehler beim Bearbeiten des Archivs knxd-tools_0.10.3-5_armhf.deb (--install):
Versuch, »/usr/lib/knxd/eibwrite-cgi« zu überschreiben, welches auch in Paket knxd 0.10.3-5 ist
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von knxd:
knxd hängt ab von knxd-tools; aber:
Paket knxd-tools ist nicht installiert.
dpkg: Fehler beim Bearbeiten des Paketes knxd (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für systemd (215-17+deb8u1) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
knxd-tools_0.10.3-5_armhf.deb
knxd
pi@raspberrypi ~ $
mache ich noch irgendwas verkehrt - ihr wisst inzwischen kleine hinweise helfen mir schon arg
ingo
Nee, du machst nix falsch – ich war derjenige, der zu viel zu um die Ohren hat und vergaß, was einzuchecken.
Die aktuelle Version sollte besser funktionieren ...
high smurfi
sieht schon mal nicht schlecht aus, wieder ein stück weiter:
1. alles alte deinstalliert
2. alte Dateien gelöscht
3. mit git pull die neue Version runtergeladen und mit dpkg-buildpackage -b die Pakete neu gebaut
4. mit sudo dpkg -i knxd_*.deb knxd-tools_*.deb die Pakete neu installiert
5. in /etc/Default/knxd meine Parameter wieder eingetragen und das mit PATH und System und enable auch nochmal ausgeführt (sorry ich weiß nicht mehr alles auswendig)
6. reboot
7. autostart funzt
8. test mit groupswrite:
pi@raspberrypi / $ groupswrite ip:127.0.0.1 0/2/9 1
Send request
pi@raspberrypi / $
aber am eib passiert nichts (das licht im AZ müsste anschalten). Kann ich dir irgendwelche logs schicken zur Fehlersuche?
ingo
Jau, kannst du. Erstens kannst du eine neue Logdatei erstellen, wie gehabt. Zweitens kannst du mir sagen, was der knxd hin- und herschickt.
sudo tcpdump -s300 -w/tmp/knxd.ip.log port 3671
Das machst du bitte einmal mit dem eibd, wo es noch funktionierte, und einmal mit dem knxd. Starte das vor deinem knxd.
Die drei Dateien emailst du an matthias@urlichs.de.
So, ich habe mit Teamviewer gespielt und speedschmidts Probleme gefunden.
- In der /etc/default/knxd steht, dass sie ignoriert wird, sobald systemd läuft. Das muss ich wohl ein bisschen lauter schreiben.
- In der /etc/knxd.conf steht nicht, dass die Option "-i" nicht mehr verwendet werden darf, weil das inzwischen vom systemd und der knxd.socket-Datei erledigt wird. Wird behoben.
high
geschafft, autostart läuft und
sudo knxtool groupswrite ip: 0/2/9 0
funktioniert auch sofort nach dem Neustart wieder. Ja ich hätte ja auch etwas genauer (in der /etc/default/knxd) lesen können (Asche auf mein Haupt). Verstehe ich das richtig wheezy arbeitet noch nicht mit systemd? Also wer mit KNXD arbeiten möchte sollte zwingend auf jessie updaten?
So jetzt geht's mit fhem Installation weiter, nachdem die Basis (knxd) mal steht.
Momentan läuft das ganze noch auf meiner Test-Sd-Karte und ich werde das die Tage auf meine, mit fhem schon anfangs-konfigurierte, SD-Karte installieren und dabei diesen Thread als Anleitung verwenden.
Zitat von: speedschmidt am 20 Juli 2015, 23:10:04
Verstehe ich das richtig wheezy arbeitet noch nicht mit systemd? Also wer mit KNXD arbeiten möchte sollte zwingend auf jessie updaten?
Nö, das geht schon. Wheezy verwendet dann halt die /etc/default/knxd und keine Socketaktivierung.
Meiner Meinung nach ist Jessie aber aus einem ganz anderen Grund eine gute Idee: du kannst rsyslog komplett entfernen und dem Journald beibringen, dass die Logs nicht mehr auf die SD-Karte geschrieben werden, sondern im RAM landen. Wir wissen: nicht beschriebene SD-Karten halten länger ...
high smurfi,
ich wollte den knxd jetz auf meinem anderen System installieren bzw. aktualisieren mit :
pi@raspberrypi ~/knxd $ sudo git pull https://github.com/knxd/knxd.git
und bekomme folgende Fehlermeldung:
Von https://github.com/knxd/knxd
* branch HEAD -> FETCH_HEAD
automatischer Merge von debian/knxd.install.in
automatischer Merge von README.md
KONFLIKT (Inhalt): Merge-Konflikt in README.md
Automatischer Merge fehlgeschlagen; beheben Sie die Konflikte und committen Sie dann das Ergebnis.
Vorher war noch ein Abfrage der Emailadresse und Name, welche ich mal brav beantwortet habe. Und dann kam diese Meldung.
Mach ich schon wieder etwas verkehrt? Kannst du etwas dazu sagen?
Ingo
Zitat von: speedschmidt am 22 Juli 2015, 20:08:50
KONFLIKT (Inhalt): Merge-Konflikt in README.md
kA was da schiefliegt.
git reset --hard FETCH_HEADsollte das Problem nachhaltig beheben.
sieht jetzt besser aus:
pi@raspberrypi ~/knxd $ sudo git reset --hard FETCH_HEAD
HEAD ist jetzt bei 833d05a add comments to config files
pi@raspberrypi ~/knxd $ sudo git pull https://github.com/knxd/knxd.git
Von https://github.com/knxd/knxd
* branch HEAD -> FETCH_HEAD
Already up-to-date.
pi@raspberrypi ~/knxd $ cd..
-bash: cd..: Kommando nicht gefunden.
pi@raspberrypi ~/knxd $ cd ..
pi@raspberrypi ~ $ dir
bcusdk fhem-5.6.deb.1 knxd-tools_0.10.5-1_armhf.deb pthsem-2.0.8
Desktop indiecity libpthsem20_2.0.8_armhf.deb pthsem_2.0.8_armhf.changes
Downloads knxd libpthsem-compat_2.0.8_armhf.deb pthsem_2.0.8.tar.gz
fhem knxd_0.10.5-1_armhf.changes libpthsem-dbg_2.0.8_armhf.deb pthsem_2.0.8.tar.gz.1
fhem-5.5.deb knxd_0.10.5-1_armhf.deb libpthsem-dev_2.0.8_armhf.deb pthsem_2.0.8.tar.gz.2
fhem-5.6 knxd-dev_0.10.5-1_all.deb Manueller\ Start\ von\ EIBD.txt python_games
fhem-5.6.deb knxd-examples_0.10.5-1_armhf.deb pthsem
pi@raspberrypi ~ $
jetzt noch:
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
und dann sollte es auch auf dem Originalsystem funzen.
Ingo
high
schön das man jetzt die Argumente im Status sieht:
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 0
Open failed: Invalid argument
pi@raspberrypi ~ $ sudo service knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Mi 2015-07-22 20:37:26 CEST; 2min 15s ago
Main PID: 602 (knxd)
CGroup: /system.slice/knxd.service
└─602 /usr/bin/knxd -c -D -R -T -f9 --no-tunnel-client-queuing -S ipt:192.168.100.34
Jul 22 20:37:26 raspberrypi systemd[1]: Started KNX Daemon.
pi@raspberrypi ~ $
Nicht schön, dass groupswrite wieder nicht funzt? Habe ich was vergessen?
1. die alten paketdateien (knxd*.*) gelöscht
2. mit pull die neuen ins knxd Verzeichnis geladen (vorher git reset...))
3. das Verzeichnis bcusdk gibt es auf dieser SD-Karte nicht mehr (und somit auch kein eibd, wird ja nicht benötigt, oder habe ich das falsch verstanden)
4. mit dpkg-buildpackage -b die Pakete installiert
5. mit systemctl enable knxd den autostart aktiviert
6. reboot
7. Autostart läuft im Übrigen super.
Ingo
high,
mein fehler:
4. mit dpkg-buildpackage -b die Pakete installiert
habe ich eben nicht gemacht
ingo
Zitat von: speedschmidt am 22 Juli 2015, 20:51:58
high,
mein fehler:
4. mit dpkg-buildpackage -b die Pakete installiert
habe ich eben nicht gemacht
ingo
ich hatte das mal weiter vorne gemacht, vor git pull, und dachte das hätte ich nach git pull gemacht.
aber jetzt auch nach neuinstallation geht kein groupswrite mehr :'(
pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument
pi@raspberrypi ~ $
ich mache mir jetzt erstmal ein kaltes Bier auf - prost.
Ingo
high
nein (k)altes Bier hilft auch nicht ABER:
sudo apt-get update
sudo apt-get upgrade
knxtool groupswrite ip: 0/2/9 0
funzt zwar nicht, dafür läuft fhem aber wieder (das lief nämlich auch nicht mehr)und lässt sich bedienen und das
OHNE EIBD (sagt pstree)
Verstehe ich zwar überhaupt nicht, ich dachte immer die Grundlage für fhem wäre auch irgendwie groupswrite, aber BITTE KLÄRT MICH AUF.
Ingo (der - gefühlt - den ersten RPI2 ohne EIBD am Laufen hat - oder gibt's noch wen?)
Danke nochmal an die tatkräftige Unterstützung von smurfi, auch wenn ich glaube das wir noch nicht am ende sind, aber den anfang hätten wir. ich bleib dabei.
Kannst du mir mal verraten, wieso du immer noch einem "eibd" suchst? Der heißt jetzt knxd!
NB: Auch der knxd läuft nach dem Start des Rechners nicht, funktioniert aber trotzdem. Diese Automagie nennt sich "socket activation".
Was heißt "groupswrite funktioniert nicht"? Welche Befehlszeile liefert welches Resultat? Muss ich das auch nächstes Jahr noch jedes Mal fragen, oder lernst du irgendwann, solche Infos gleich dazuzuschreiben? ;D
high smurfi
Zitat von: smurfix am 22 Juli 2015, 23:14:15
Was heißt "groupswrite funktioniert nicht"? Welche Befehlszeile liefert welches Resultat? Muss ich das auch nächstes Jahr noch jedes Mal fragen, oder lernst du irgendwann, solche Infos gleich dazuzuschreiben? ;D
nein musst du nicht, habe ich schon (vor langer, langer Zeit ) kappiert und weiter oben geschrieben (eingegebener Befehl und die Ausgabe die daraus folgte):
Zitat von: speedschmidt am 22 Juli 2015, 21:19:20
pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument
pi@raspberrypi ~ $
vielleicht vergesse ich es das eine oder andere mal - ich gelobe diesbezüglich Besserung.
Zitat von: smurfix am 22 Juli 2015, 23:14:15
Kannst du mir mal verraten, wieso du immer noch einem "eibd" suchst? Der heißt jetzt knxd!
NB: Auch der knxd läuft nach dem Start des Rechners nicht, funktioniert aber trotzdem. Diese Automagie nennt sich "socket activation".
Nein ich suche/benötige nicht eibd, aber ich war mir nicht mehr bewusst, ob ich bei der Original-SD-Karte (auf der ich aktuell arbeite) eibd schon installiert oder nach einer Installation wieder deinstalliert hatte und hatte deswegen zu Beginn meiner Tätigkeiten auf der Original-SD-Karte (auf der ich schon zwei Wochen nicht mehr unterwegs bin) den eibd schon gesucht um diesen dann bedarfsweise zu deinstallieren. Es hat sich aber herausgestellt, dass dort der eibd noch nicht oder nicht mehr installiert war.
ergänzende Begriffserklärung:
Original-SD-Karte = SD-Karte mit der ich die fhem- und eibd - Installationen auf dem RPi2 begonnen hatte und fhem schon zu einem kleinen Teil konfiguriert ist, weil ja eibd dort mal lief (nur manueller Start und damit die Basis für diesen Threat).
Test-SD-Karte = eine "nackte" Betriebssystemumgebung die sich von der Original-SD-Karte nur dadurch unterscheidet, dass kein fhem installiert ist. Hier wollte ich knxd eigentlich nur soweit bringen, dass es nach einem Systemstart nicht manuell gestartet werden muss und man groupswrite ausführen kann, da ich der Meinung war (bin aktuell schlauer), dass dies die Basis für fhem ist.
Ingo
pi@raspberrypi ~ $ sudo knxtool groupswrite ip: 0/2/9 0
Open failed: Invalid argument
Lass das "sudo" weg, das braucht kein Mensch.
Mach mal "strace -s300 -o/tmp/gw.log knxtool groupswrite ..." und schick mir diese Datei.
voula, einmal Datei gw.log zur Fehlersuche
ingo
Zitatvoula
Das heißt "voilà". 8)
Ertappt:
execve("/usr/local/bin/knxtool" ...knxtool ist in /usr/bin. Du hast in /usr/local noch Reste deiner Altinstallation rumliegen.
Zitat von: smurfix am 23 Juli 2015, 18:30:52
Das heißt "voilà". 8)
Ertappt:
execve("/usr/local/bin/knxtool" ...
knxtool ist in /usr/bin. Du hast in /usr/local noch Reste deiner Altinstallation rumliegen.
wow wieder was gelernt (das man hier auch auf französische Rechtschreibung Wert legt). kann ich die Reste einfach löschen, oder gibt es einen richtigen weg um die Reste zu deinstallieren, den ich noch nicht kenne?
Wie ist denn grundsätzlich der richtige Weg, um eine über github gepflegte software zu aktualisieren? welche befehle muss ich eingeben, damit ich SAUBER aktualisiere. es ist ja nicht so, dass das hier so noch nicht geschafft habe(immerhin arbeite ich seit der Version 0.9.XX-X hier daran), aber wohl offensichtlich nicht RESTlos sauber. Ich kann mich auch noch gut an meine dort gemachten Fehler erinnern (alte Paketdateien nicht gelöscht etc.). War das grundsätzlich richtig angeleitet (von smurfi) und schlecht ausgeführt von mir?
Ingo
Grundsätzlich sagt dir
dpkg -S /usr/local/bin/knxtool
mit welchem debian-Paket diese Datei installiert wurde. Wenn du mir das mitteilst, nehme ich das auf und die Deinstallation geschieht automatisch, wenn du knxd-tools installierst.
Grundsätzlich² untersteht /usr/local aber der Ägide des lokalen Benutzers, d.h. die Daten da drin sind im Normalfall eben nicht mit dpkg installiert, sondern "irgendwie anders".
Dagegen hilft nicht viel, außer eben von Hand aufzuräumen. Alternativ kann man /usr/local/bin nach /usr/bin in den Pfad zu nehmen statt davor; das steht irgendwo in den Shell-Startupskripts ("man bash" sagt dir mehr über das Ding, als du dir jemals merken kannst).
high,
ich hätte dir gern mehr geschickt, aber mehr ist nicht :'(
pi@raspberrypi ~ $ sudo dpkg -S /usr/local/bin/knxtool
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/local/bin/knxtool passt
pi@raspberrypi ~ $
Zitat von: smurfix am 24 Juli 2015, 02:39:03
Grundsätzlich sagt dir
dpkg -S /usr/local/bin/knxtool
mit welchem debian-Paket diese Datei installiert wurde. Wenn du mir das mitteilst, nehme ich das auf und die Deinstallation geschieht automatisch, wenn du knxd-tools installierst.
Grundsätzlich² untersteht /usr/local aber der Ägide des lokalen Benutzers, d.h. die Daten da drin sind im Normalfall eben nicht mit dpkg installiert, sondern "irgendwie anders".
Dagegen hilft nicht viel, außer eben von Hand aufzuräumen. Alternativ kann man /usr/local/bin nach /usr/bin in den Pfad zu nehmen statt davor; das steht irgendwo in den Shell-Startupskripts ("man bash" sagt dir mehr über das Ding, als du dir jemals merken kannst).
ja hat das vielleicht make, make install von bcusdk da reininstalliert? nein knxtool wird nicht von bcusdk installiert, nicht von make oder dpkg oder sonstwie. hier mal der Inhalt des Ordners:
pi@raspberrypi /usr/local/bin $ dir
bcuaddrtab grouplisten mmaskver mwriteplain
bcuread groupread mpeitype progmodeoff
busmonitor1 groupreadresponse mprogmodeoff progmodeon
busmonitor2 groupresponse mprogmodeon progmodestatus
eibd groupsocketlisten mprogmodestatus progmodetoggle
eibnetdescribe groupsocketread mprogmodetoggle pthsem-config
eibnetsearch groupsocketswrite mpropdesc readindividual
findknxusb groupsocketwrite mpropread vbusmonitor1
groupcacheclear groupsresponse mpropscan vbusmonitor1poll
groupcachedisable groupswrite mpropscanpoll vbusmonitor2
groupcacheenable groupwrite mpropwrite writeaddress
groupcachelastupdates indiecity mread xpropread
groupcacheread knxtool mrestart xpropwrite
groupcachereadsync madcread msetkey
groupcacheremove maskver mwrite
pi@raspberrypi /usr/local/bin $
Moment mal mit:
dpkg -S /usr/local/bin/groupswrite
kriegen wir doch raus wer groupswrite da installiert hat:
pi@raspberrypi /usr/local/bin $ sudo dpkg -S /usr/local/bin/groupswrite
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/local/bin/groupswrite passt
pi@raspberrypi /usr/local/bin $
nein doch nicht :-(
weitere Ideen?
Ingo
Zitatja hat das vielleicht make, make install von bcusdk da reininstalliert?
Da kann ich dir leider auch nicht weiterhelfen. War auf jeden Fall irgendwas, das auch den eibd da hininstalliert hat.
Einfach weg damit und gut is':
$ cd /usr/local/bin
$ sudo rm [b-gk-oq-x]* pr*
high smurfi,
Befehl ausgeführt:
pi@raspberrypi ~ $ cd /usr/local/bin
pi@raspberrypi /usr/local/bin $ sudo rm [b-gk-oq-x]* pr*
pi@raspberrypi /usr/local/bin $ dir
indiecity pthsem-config
Ausgabe mit groupswrite:
pi@raspberrypi ~ $ knxtool grouswrite ip: 0/2/9 1
No such applet: grouswrite: No such file or directory
Sorry ich hätte gern bessere Nachrichten
Ingo
ZitatSorry ich hätte gern bessere Nachrichten
Dann schau mal genau hin.
Ich schenke dir ein "p".
High :D
Zitat von: smurfix am 25 Juli 2015, 21:29:59
Dann schau mal genau hin.
Ich schenke dir ein "p".
Danke , danke, danke hat auch sehr geholfen: :-[
pi@raspberrypi ~ $ knxtool groupswrite ip: 0/2/9 1
Open failed: Connection refused
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 1
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 0
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip:localhost 0/2/9 1
Send request
pi@raspberrypi ~ $
Licht geht an und aus und wieder an. Wobei ich dich weiter oben, so verstanden hatte, dass man localhost(127.0.0.1) weglassen kann. Habe ich das falsch verstanden?
Ingo
Nee, das hast du nicht falsch verstanden; ich seh mir gleich mal an, wieso das nicht mag.
high,
anbei mal zwei Logdateien:
gw1.log = ohne localhost
gw2.log = mit localhost
ich hoffe es hilft dir weiter.
Ingo
Du bist sicher, dass du die aktuelle Version von knxtool installiert hast??
Weil bei mir geht das ...
high
bei mir gibts im pfad /home/pi nur die knxd 0.10.5-1* pakete aus denen ich es dann auch installiert habe.
Kann ich die Version noch anders checken?
ingo
ls -l src/examples/.libs/knxtool debian/tmp/usr/bin/knxtool debian/knxd-tools/usr/bin/knxtool /usr/bin/knxtool
Die ersten beiden Dateien müssen gleiche Größe haben und die letzten beiden auch. Das Änderungsdatum muss auch (einigermaßen) übereinstimmen.
high,
ja ich glaube da ist bei mir noch was krum:
pi@raspberrypi ~ $ ls -l src/examples/.libs/knxtool debian/tmp/usr/bin/knxtool debian/knxd-tools/usr/bin/knxtool /usr/bin/knxtool
ls: Zugriff auf src/examples/.libs/knxtool nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf debian/tmp/usr/bin/knxtool nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf debian/knxd-tools/usr/bin/knxtool nicht möglich: Datei oder Verzeichnis nicht gefunden
-rwxr-xr-x 1 root root 27800 Jul 22 21:03 /usr/bin/knxtool
So wie ich es verstanden habe müsste die Dateien da sein? Aber ich kann nicht mal die Verzeichnisse bei mir finden (/Debian; /scr;). bis auf 's letzte.
Bedenke - !RaspBerryPi2! - kein normales Debian.
Ingo
Kannst du bitte ins knx-Source-Verzeichnis gehen, bevor du den Befehl ausführst??
Sorry, aber für mich war das irgendwie mehr als offensichtlich!
Sorry,
pi@raspberrypi ~/knxd $ ls -l src/examples/.libs/knxtool debian/tmp/usr/bin/knxtool debian/knxd-tools/usr/bin/knxt
-rwxr-xr-x 1 root root 27800 Jul 22 21:03 debian/knxd-tools/usr/bin/knxtool
-rwxr-xr-x 1 root root 81836 Jul 22 21:02 debian/tmp/usr/bin/knxtool
-rwxr-xr-x 1 root root 81836 Jul 22 21:02 src/examples/.libs/knxtool
-rwxr-xr-x 1 root root 27800 Jul 22 21:03 /usr/bin/knxtool
Sollte so ja passen, oder?
Ingo
Klar.
Keine Ahnung was da bei dir schiefgelaufen ist; bei mir sieht src/client/c/openurl.c jedenfalls so aus:
EIBConnection *
EIBSocketURL (const char *url)
{ [...]
if (!strncmp (url, "ip:", 3))
{
char *a, *b;
int port;
EIBConnection *c;
url += 3;
a = strdup (*url ? url : "localhost");
if (!a)
{
errno = ENOMEM;
return 0;
}
b = strchr (a,':');
if (b)
{
*b = 0;
port = atoi (b + 1);
}
else
port = 6720;
c = EIBSocketRemote (a, port);
free (a);
return c;
}
und damit hat "ip:" gefälligst zu funktionieren.
high,
und bei mir so:
/*
EIBD client library
Copyright (C) 2005-2011 Martin Koegler <mkoegler@auto.tuwien.ac.at>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
In addition to the permissions in the GNU General Public License,
you may link the compiled version of this file into combinations
with other programs, and distribute those combinations without any
restriction coming from the use of this file. (The General Public
License restrictions do apply in other respects; for example, they
cover modification of the file, and distribution when not linked into
a combine executable.)
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#include "eibclient-int.h"
EIBConnection *
EIBSocketURL (const char *url)
{
if (!url)
{
errno = EINVAL;
return 0;
}
if (!strncmp (url, "local:", 6))
{
url += 6;
return EIBSocketLocal (*url ? url : "/run/knxd");
}
if (!strncmp (url, "ip:", 3))
{
char *a, *b;
int port;
EIBConnection *c;
url += 3;
a = strdup (*url ? url : "localhost");
if (!a)
{
errno = ENOMEM;
return 0;
}
b = strchr (a,':');
if (b)
{
*b = 0;
port = atoi (b + 1);
}
else
port = 6720;
c = EIBSocketRemote (a, port);
free (a);
return c;
}
fprintf(stderr, "Unknown URL prefix, need 'local:' or 'ip:'\n");
errno = EINVAL;
return 0;
}
auf den ersten (meinen) blick anders (abgesehen von der Einleitung oder wie ihr das nennt? - die habe ich mal mitgeschickt - sicherheitshalber).
Ich bin jetzt mal wieder kurz davor "format C:\" einzugeben und neu anzufangen (ich weiß ist kein Windows-System ;) ) Wird wohl das Beste und einfachste an der stelle sein. Oder soll ich nur den Inhalt von deiner Datei übernehmen? Was meinst du? Auch nochmal die Möglichkeit deine Doku auf github ab zu checken ;)
WICHTIG vorher die fhem.cfg sichern. Ausserdem noch was?
Ingo
Deine Datei ist genau dieselbe wie meine, ich habe einfach den für das Probelm nicht relevanten Teil weggelassen.
Ich kann gerne mal mit Teamviewer o.Ä. draufschauen.
high
ja können wir machen heute gg. 21:00 Uhr?
ingo
High,
so geschafft, besten dank nochmal für make clean und make. Aber ist dieser alte Schrott nicht auch gerade zu erwarten, wenn ein anderer user (evtl. ein wenig versierter wie ich) von eibd auf knxd umsteigt. Aber ich muss schon sagen, mein System werde ich mit Sicherheit nochmal neu aufsetzen, nicht ohne, aber mit weniger Anfängerfehlern.
Ingo
PS: Jetzt steht der Verbreitung/Verwendung von knxd ja nichts mehr im weg, aus meiner Sicht (was war nochmal eibd??). Wie siehst du das?
Sagen wir mal so: Ich kenne aktuell keinen Grund, wieso man beim alten eibd bleiben sollte.
High smurfix,
ich hoffe du lauschst noch mit:
Ich habe aus verschiedenen Gründen ein neues System aufgesetzt (das alte läuft noch auf einer anderen Speicherkarte). Nun bin ich beim Installieren (nach deiner Anleitung auf Github) vom knxd auf diesem System auf folgende Fehlermeldungen gestoßen:
pi@raspberrypi ~/knxd $ sudo dpkg-buildpackage -b
dpkg-buildpackage: Quellpaket knxd
dpkg-buildpackage: Quellversion 0.10.7-1
dpkg-buildpackage: Quelldistribution unstable
dpkg-buildpackage: Quellen geändert durch Matthias Urlichs <matthias@urlichs.de>
dpkg-buildpackage: Host-Architektur armhf
dpkg-source --before-build knxd
debian/rules clean
dh clean
dh_testdir
dh_auto_clean
debian/rules override_dh_clean
make[1]: Entering directory '/home/pi/knxd'
dh_clean
rm -f debian/knxd.substvars
rm -f debian/knxd.*.debhelper
rm -rf debian/knxd/
rm -f debian/knxd-tools.substvars
rm -f debian/knxd-tools.*.debhelper
rm -rf debian/knxd-tools/
rm -f debian/knxd-dev.substvars
rm -f debian/knxd-dev.*.debhelper
rm -rf debian/knxd-dev/
rm -f debian/knxd-examples.substvars
rm -f debian/knxd-examples.*.debhelper
rm -rf debian/knxd-examples/
rm -f debian/*.debhelper.log
rm -f debian/files
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \)
rm -f *-stamp
rm -f debian/knxd.install
make[1]: Leaving directory '/home/pi/knxd'
debian/rules build
dh build
dh_testdir
debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/pi/knxd'
cp debian/knxd.install.in debian/knxd.install
grep -qs 'HAVE_SYSTEMD_TRUE.*#' config.status || cat debian/knxd.install.systemd >> debian/knxd.install
sh bootstrap.sh
bootstrap.sh: 2: bootstrap.sh: libtoolize: not found
debian/rules:24: recipe for target 'configure' failed
make[1]: *** [configure] Error 127
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
pi@raspberrypi ~/knxd $
Also kurz vorm Fertigstellen. Einige fehlende Pakete habe ich schon installiert (debhelper, ?cdbs?, libsystemd-daemon-dev und noch irgendein anderes?). Die fehlenden Bauabhängigkeiten habe ich damit beseitigt.
Nun aber die Fehlermeldung wie oben. Es ist ein "frisches" neues System, auf dem ich nur Raspbian Jessie und fhem installiert habe. Dies ist mein erster Versuch auf diesem System knxd zu installieren. Das heißt ältere Installation können hier nichts verursachen.
Ich hoffe du kannst hier nochmal helfen - oder wer auch immer.
Ingo
Hi,
bootstrap.sh: 2: bootstrap.sh: libtoolize: not found
Das sieht nach fehlendem
apt-get install autoconf automake libtool
aus; ich werde das gleich nachtragen.
PS: ich frage mich, wie so viele Leute auf die Idee kommen, "sudo dpkg-buildpackage -b" zu verwenden... das ist sinnfrei.
High smurfi,
nach:
sudo apt-get install autoconf automake libtool
lief
sudo dpkg-buildpackage -b
natürlich durch und auch
cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb
hat keine Fehlermeldungen mehr ausgeworfen.
ABER:
Autostart erst nach:
sudo systemctl enable knxd
Könnte das bitte mit in die Readme rein?
und dann ganz wichtig:
Die Argumente in der /etc/knxd.conf nicht vergessen einzutragen (bei systemd und Systembezogen und siehe weiter vorn).
Und ganz großen Dank nochmal
Ingo
PS: Merkwürdig fand ich folgende Reaktion:
Erst nach einem (oder mehreren) erfolgreichen groupswrite wurde der Dienst als gestartet gemeldet:
pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: failed (Result: exit-code) since So 2015-09-13 22:08:39 CEST; 1min 34s ago
Process: 526 ExecStart=/usr/bin/knxd $KNXD_OPTS (code=exited, status=1/FAILURE)
Main PID: 526 (code=exited, status=1/FAILURE)
pi@raspberrypi ~ $ knxtool groupswrite ip: 0/2/9 1
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip: 0/2/9 0
Send request
pi@raspberrypi ~ $ knxtool groupswrite ip: 0/2/9 1
Send request
pi@raspberrypi ~ $ /etc/init.d/knxd status
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since So 2015-09-13 22:10:30 CEST; 14s ago
Main PID: 809 (knxd)
CGroup: /system.slice/knxd.service
└─809 /usr/bin/knxd -c -D -R -T --no-tunnel-client-queuing -S ipt:...
Aber ich erinnere mich auch wie du schriebst, dass der Dienst erst startet wenn er benötigt wird (oder so ähnlich).
Also ich habe leider bei diesem Thread ein Problem. Titel heisst Autostart von EIBD auf Raspi2 und ich finde so gut wie keine klare Aussage was tut man wenn EIBD wunderbar funktioniert auch in FHEM nur man muss beim Neustart wieder händisch den EIBD starten.
' eibd -d -D -S -T -i ipt:192.168.xxx.xxx:3671 ' startet den eibd
Wo ist denn nur die Anleitung was muss ich tun damit ich diesen Start nicht immer selber machen muss sondern der Raspi das selbst macht
Eintragen in /etc/rc.local und fertig.
(Ans Ende der Zeile muss dann noch ein &-Zeichen.)
Es gibt noch diverse aufwändige Startskripte, an denen rumzubasteln sich aber allesamt nicht wirklich lohnt.
Hallo smurfix
wäre ja gut wenn das so einfach funktionieren würde tut es aber leider nicht
Die Zeile ' eibd -d -D -S -T -i ipt:192.168.xxx.xxx:3671 & ' eingefügt in /etc/rc.local
Wo liegt das Problem ?
Wo hast du die denn eigefügt, nach dem "exit 0" das da schon drinsteht, oder davor?
Evtl. /usr/local/bin/eibd statt nur eibd schreiben, je nachdem wo das Ding hininstalliert wurde
selbstverständlich vor dem ' exit 0 '
aber ohne Angabe vom Speicherort. Den muss ich dann mal noch suchen !
"which eibd" gibt den Dateipfad
Hallo an alle den Instalationspfad von EIBD gefunden den Eintrag entsprechend erweitert und es FUNKTIONIERT !!!
Ich danke smurfix als auch SvenJust für Ihre selbstlose Unterstützung
:) :) :) :)
Das aktuelle Installationsskript macht "systemctl enable" auf Socket und Service.
Mit dem Autostart via Socket ist das so eine Sache. Rein theoretisch sollte das sauber funktionieren; in der Praxis kann es vorkommen, dass der Code auf Interface A schon munter Daten liest, aber nicht an B weiterleitet, weil Interface B einfach noch nicht initialisiert ist. (Das zu beheben wäre im Rahmen des geplanten libpthsem-Rauswurfs sinnvoll.) Fazit: lieber gleich beim Booten starten.
Guten Tag zusammen,
ich möchte den Thread noch mal hochholen - bin am Verzweifeln mangels autostart von knxd.
Stand der Dinge ist: Ich habe wheezy komplett neu aufgesetzt und den knxd gemäß Wiki installiert. Ging problemlos. Da ich einen TUL am Raspberry angeschlossen habe und ETS über einen Windows-Rechner im Netzwerk, habe ich /etc/default/knxd wie folgt angepasst:
START_KNXD=YES
DAEMON_ARGS="-e 0.0.1 -i -D -T -R -S -b tpuarts:/dev/ttyACM0"
Manuelles Starten über service knxd start führt genau zum gewünschten Ergebnis.
Autostart nach reboot funktioniert nicht. Im Unterschied zu speedschmidt läuft bei mir ja, so wie ich es verstanden habe, kein systemd. Auch sehe ich überall in den /etc/rc2.d bis /etc/rc5.d den Link auf S02knxd.
Wenn ich den Aufruf um Parameter -f 9 ergänze, passiert nichts. Eine /var/log/eibd.log gibt es nicht. Jessie habe ich ebenfalls nicht.
Habt ihr Ideen was schief gelaufen sein könnte / wo ich hinschauen muss?
Grüße
Marcel