OWServer mit DS2408 OWDevice nur lesend erreichbar in fhem

[FilliFairy]

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

[eldrik]

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

[FilliFairy]

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

[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

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

[FilliFairy]

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

[smurfix]

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

Code Auswählen Erweitern


$ 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


[FilliFairy]

Hallo smurfix,

danke für den Hinweis. Ich habe den Git account gerade eingerichtet. 

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[smurfix]

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

[FilliFairy]

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:

Code Auswählen Erweitern

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

[smurfix]

Hmm, in der armhf-chroot auf meinem Server lief es durch; ich lasse mal einen "richtigen" Pi darauf los.

[FilliFairy]

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

[My-FHEM]

Ich habe ebenfalls versuch nach obiger Anleitung eigene debian jessie pakete zu
bauen.

Bei mir läuft der build prozess bis:

Code Auswählen Erweitern


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ß

[smurfix]

@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.)

[smurfix]

@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?

[My-FHEM]

@smurfix

Ich habe  owfs_3.1p0+git1-ba7b185-3_armhf.build ausgecheckt.

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.