Hallo,
ich habe mir einen neuen Raspi 2 zugelegt und meine FHEM Installation von einem Raspi B+ dorthin umgezogen. Auf dem Raspi 2 läuft mittlerweile fast alles wieder. Nur ein DS2408 (der einzige dieser Art) ist von FHEM aus nur lesend zu erreichen.
Über OWHTTP kann ich die Ausgänge des DS2408 setzen und auch in FHEM die geänderten Werte sehen. Ein Setzen der Ausgänge von FHEM bleibt wirkungslos.
Nachdem über OWHTTP ja nachgewiesen ist, dass da Device erreichtbar ist, scheint bei der Verbindung zwischen owserver und FHEM ein Problem vorzuliegen, vermutlich nur bei schreibenden Zugriffen. Die lesenden Zugriffe bei mehreren Devices (DS1820, DS2413) gehen tadellos.
Mittlerweile habe ich keine Ideen mehr wie ich dem Problem auf die Spur kommen könnte.
Wie kann ich den Weg von schreibenden Zugriffen von einem OWDevice bis zum owserver verfolgen ?
Mit freundlichem Gruß
FillyFairy
Hi,
in der Vergangenheit ließ sich das beschriebene Verhalten, auf eine neuere OWFS/OWServer Version zurückverfolgen, welche scheinbar diese Probleme mit sich bringt, schau mal welche Versionen du auf dem Pi+ und welche auf dem Pi2 hast!
Greetz
Eldrik
Wow Eldrik,
Du hast ja mal den Überblick:
Raspi 2: owserver version: 2.9p8
Raspi B+: owserver version: 2.8p15
Danke für den Hinweis. Ich schau mal ob ich darüber weitergehende Infos finde.
Vielen Dank.
FillyFairy
Zitat von: FilliFairy am 03 Juni 2015, 20:57:45
Wow Eldrik,
Du hast ja mal den Überblick:
Raspi 2: owserver version: 2.9p8
Raspi B+: owserver version: 2.8p15
Danke für den Hinweis. Ich schau mal ob ich darüber weitergehende Infos finde.
Vielen Dank.
FillyFairy
Hi,
dann bestätigt sich meine Annahme, die 2.9 Version scheint in manchen Situationen "fehlerhaft" zu sein, weshalb du auf dem RPi2 auch die 2.8 installieren müsstest.
Greetz
Eldrik
Ich habe mir mal die Projektseite auf sourceforge angesehen, konnte jedoch keinen Hinweis darauf finden, ob es ein bekanntes Problem ist oder eventuell sogar schon behoben ist. Besser wird's ja natürlich nur, wenn das Problem klar beschrieben werden kann und ein Entwickler die Chance hat es zu beheben. FHEM wird dort vermutlich eher unbekannt sein.
Kann jemand Tips geben, wie man das Problem in einer für die OWFS Entwickler verständlichen Sprache zum Ausdruck bringen kann?
Gruß
Gerhard
Der erste Ansatz dürfte sein, die aktuelle Version via git herunterzuladen und auszuprobieren, ob der Fehler noch auftritt.
Wenn du owfs via Debian-Paketsystem installieren willst, dann kannst du die Paketierung aus meinem Archiv verwenden. Sowas wie ..:
$ git clone github.com:M-o-a-T/owfs.git
$ cd owfs
$ git checkout -b upstream origin/upstream
$ git checkout origin/smurf debian/
$ sh bootstrap
$ debuild -b -us -uc
$ cd ..
$ sudo dpkg -i *.deb
Hallo smurfix,
danke für den Hinweis. Ich habe den Git account gerade eingerichtet.
ssh -T git@github.com sagt:
Hi rhpsFan65! You've successfully authenticated, but GitHub does not provide shell access.
Leider hänge ich bereits beim git clone github.com:M-o-a-T/owfs.git hängen:
git clone github.com:M-o-a-T/owfs.git
Cloning into 'owfs'...
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Habe ich da etwas falsch gemacht?
Gruß
FillyFairy
Sorry – ohne im Projekt registrierten github-Account musst du das Archiv via git-Protokoll holen:
$ git clone git://github.com/M-o-a-T/owfs.git
Hallo smurfix,
nun glaube ich, dass ich alle Pakete nachinstalliert habe die fehlten. Bei dieser Fehlermeldung habe ich jetzt keine Idee mehr wie ich weiter komme:
configure: exit 2
dh_auto_configure: ./configure --build=arm-linux-gnueabihf --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --libdir=${prefix}/lib/arm-linux-gnueabihf --libexecdir=${prefix}/lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --enable-debian --disable-debug --disable-profiling --enable-owshell --enable-owlib --enable-ownetlib --enable-i2c --enable-owhttpd --enable-owftpd --enable-owserver --enable-owexternal --enable-ownet --enable-owtap --disable-owmalloc --disable-owtraffic --enable-owmon --enable-owcapi --enable-swig --disable-owperl --disable-owphp --enable-owpython --disable-owtcl --enable-owfs --enable-zero --enable-usb --enable-parport --enable-w1 returned exit code 2
debian/rules:60: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 255
make[1]: Leaving directory '/home/buchgerh/owfs'
debian/rules:56: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1376:
dpkg-buildpackage -rfakeroot -D -us -uc -b failed
Der verfügbare Puffer der Ausgabe habe ich als Datei angehängt. Möglicherweise ist der initiale Fehler aber schon oben rausgerutscht...
Kannst Du etwas entdecken?
Mit freundlichem Gruß
FillyFairy
Hmm, in der armhf-chroot auf meinem Server lief es durch; ich lasse mal einen "richtigen" Pi darauf los.
Hallo smurfix,
ich habe den Build nochmal gestartet, um vielleicht über die erste Fehlermeldung noch einen Hinweis zu bekommen. Anbei die Datei config.log, auf die ich gestossen bin.
Gruß
FillyFairy
Ich habe ebenfalls versuch nach obiger Anleitung eigene debian jessie pakete zu
bauen.
Bei mir läuft der build prozess bis:
cp: der Aufruf von stat für ,,debian/tmp/usr/share/man/man1/owexist.1" ist nicht möglich: Datei oder Verzeichnis nicht gefunden
owexist.1 gibt es nicht im ganzen source tree. Wie gehts dann weiter?
Gruß
@my-fhem: Findest du im Output davor einen Hinweis, was auf die Nase gefallen ist?
(Der Buildprozess von owfs prüft leider stellenweise nicht auf Fehler.)
@FillyFairy: lief bei mir anstandslos durch. Raspberry Pi mit Debian Jessie.
Seltsam.
Kannst du mir auf deinem Pi einen Login verpassen, damit ich da mal nachsehen kann?
@smurfix
Ich habe owfs_3.1p0+git1-ba7b185-3_armhf.build ausgecheckt.
dh_install --list-missing -X.la -Xperllocal.pod -Xowexist.1
dh_install: usr/share/man/mann/ow.n exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/man/mann/owtcl.n exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man3/owperl.3 exists in debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man3/OWNet.3 exists in debian/tmp but is not installed to anywhere
Mit obigen befehl habe ich die nicht zugeorneteten Datein aufgelistet. Neben owexist.1 waren es auch
die service Dateien für owserver, owhttpd, owftpd u. einige weitere man pages.
Diese habe in in den entsprechenden .install Dateien im debian Verzeichniss eigetragen.
owexist.1 war in ow-shell.install gewünscht, gibt es aber nicht im Source. also Eintrag entfernt.
Obige fehlen noch, da ich nicht weiß wohin damit.
Danach hats gebaut.
Gruß
PS:
owserver version:
3.1p0
libow version:
3.1p0
ich betreibe 1W an einer eigenen Hardware mit i2c ds2482-800 u. 5 Bussen. Nach Upgrade auf Jessie mit ow-2.9p8
von lenny mit 1W-2.8 welches jahrelang sauber lief, hatte ich auf meiner neuen Hardware (odroid-c1 vorher dockstar)
lauter i2c errors. mit 3.1p0 scheint es zu gehen.
PS:16.6.2015 die i2c Errors verschwanden erst mit dem neusten odroidc1 kernel selfbuild 3.10.80 welcher einen i2c-fix enthält.
Hallo,
ich habe das gleiche Problem auf Cubie2, nach Aktualisierung auf Debian Jessie.Über owhttpd:2121 kann ich schalten,über Fhem wird nur gelesen,schalten geht hier nicht.
Habe auch Version 3.1p0 probiert,nach der Anleitung von @smurfix,mit der geht es auch nicht.
Gruß,
Claudiu
Edit: nach Änderung in 10_OWServer.pm wie hier beschrieben http://forum.fhem.de/index.php/topic,32002.0.html ,funktioniert alles wieder
Hallo smurfix,
der Raspi hängt hintern Router und die Portfreigaben hatte ich bei früheren Versuchen schon nicht hingekriegt. Notfalls müßten wir uns mal versuchen über Teamviewer zu verbinden. Das ist ja doch alles recht aufwändig. Könnte es mit dem binary gehen, das Du auf Deinem Raspi gebaut hast? Kann ich das testweise bei mir installieren?
Gruß
FillyFairy
Wie kann ich die Version denn auslesen?
# dpkg -l owserver
Ansonsten bitte einmal mit wireshark einen erfolglosen Versuch zu schalten mitprotokollieren.