Schreibzugriff auf DS2413 geht nicht mehr

[Josch]

Hallo,

Ich betreibe einen DS2413 seit etwa 1,5 Jahren an einem Raspi mit FHEM / OWSERVER / OWDEVICE. Es wird eine Lüftungsklappe über PIO.BYTE angesteuert und die aktuelle Stellung aus sensed.A und sensed.B gelesen. Funktionierte wunderbar. Anfangs unter Wheezy. Im letzten August habe ich auf Jessie geupgradet. Nachdem ich in der owfs.conf bei "server: port" das "localhost:" entfernt hatte (nur noch die Portnummer 4304 steht jetzt da), ging wieder alles einwandfrei. Bis etwa zum 15-20.Januar 2018. So genau weiß ich das nicht, wenn etwas funktioniert, schaut man nicht dauernd danach . Seitdem lässt sich der DS2413 von FHEM nur noch lesen, aber nicht mehr schreiben. Von owhttpd geht aber beides weiterhin ohne Probleme. Ich habe die verschiedenen Ratschläge wegen der angeblichen Probleme von owfs unter Jessie ausprobiert (neue OWNet.pm, Downgrade auf owfs2.8 ). Letztlich habe ich Raspbian auf Stretch geupgradet und bin damit bei owfs 3.1 gelandet.
Das Fehlerbild ist geblieben: Lesen geht immer, Schreiben geht nur mit owhttpd.
Ich habe den Fehler ein wenig eingegrenzt: Der Fehler tritt auch in einem Perl-Script auf, in dem ich die write-Funktion aus OWNet.pm direkt rufe.

Code Auswählen Erweitern

use OWNet ;
use strict;

my $owserver = OWNet->new("localhost:4304-v");
#print "dir=" . $owserver->dir( "/3A.C3EF1A000000") . "\n";
#print "present=" . $owserver->present( "/3A.C3EF1A000000/PIO.BYTE") . "\n";

print "ret=" . $owserver->write( "/3A.C3EF1A000000/PI.BYTE", "1") . "\n";

print "A=" . $owserver->read( "/3A.C3EF1A000000/sensed.A")
   . " B=" . $owserver->read( "/3A.C3EF1A000000/sensed.B")
   . " ALL=" . $owserver->read( "/3A.C3EF1A000000/sensed.ALL")
   . " BYTE=" . $owserver->read( "/3A.C3EF1A000000/sensed.BYTE") . "\n" ;

print "PIO.A=" . $owserver->read( "/3A.C3EF1A000000/PIO.A")
   . " PIO.B=" . $owserver->read( "/3A.C3EF1A000000/PIO.B")
   . " PIO.ALL=" . $owserver->read( "/3A.C3EF1A000000/PIO.ALL")
   . " PIO=" . $owserver->read( "/3A.C3EF1A000000/PIO.BYTE") . "\n" ;
write() liefert undef zurück, also einen Fehler. Die weitere Suche ergab, dass in write() _ToServer() mit plausiblen Parametern gerufen wird, aber das von _FromServer() gerufene _FromServerBinaryParse() liefert in $return_status -1 (bzw. 4294967295) zurück. Das führt dann zum undef als Rückgabewert von write(), was offenbar das Zeichen dafür ist, dass der Schreibvorgang fehlschlug. Verwunderlich ist auch, dass man die read-Funktion ohne Probleme schrittweise abarbeiten kann. Tut man das bei write(), bleibt der Perl-Interpreter in der Schleife in _FromServer hängen.
Hat jemand ähnliche Probleme oder eine Idee, woran der Fehler liegen könnte? Die im Thread https://forum.fhem.de/index.php/topic,81197.msg749516.html#msg749516 beschriebenen Probleme scheinen ähnlich.

Für Anregungen wäre ich sehr dankbar.
Gruß Jörg

[Dr. Boris Neubert]

Hallo Jörg,

ich denke, dass das bei Dir aufgetretene Problem und das im verlinkten Beitrag dasselbe ist. Vielen Dank auch für Deine Analyse, die klar darauf hindeutet, dass das Problem im Debian-Package owfs liegt. Benutzt Du OWNet.pm aus dem lib-Verzeichnis oder die aktuelle Fassung von CPAN? Ich würde es an Deiner Stelle noch mit dem neuesten OWNet.pm von CPAN probieren. Wenn es geht, könnten wir diese in FHEM einbauen. Ansonsten muss der Autor von owfs ran: ich denke, dass Du Dich dann mit Deinem Testprogramm und den bisherigen Ergebnissen an den Autor von owfs wenden könntest. Da hast Du ja schon einiges an Vorarbeit geleistet.

Viele Grüße
Boris

[Josch]

Hallo Boris,
ich war leider etwas auf dem Holzweg: Wenn man beim Schreiben nur "PI.BYTE" statt "PIO.BYTE" übergibt, muss es ja schiefgehen. Manchmal sieht man eben den Wald vor Bäumen nicht mehr... Das Schreiben aus dem Skript funktioniert doch. Damit sind alle Werte zwischen Skript-Benutzung und owhttpd konsistent. In FHEM kommen die richtigen sensed-Werte an. Nur für die PIO-Werte hakt es. Weder zeigt FHEM den richtigen PIO-Wert an, wenn ich ihn mit Skript oder owhttpd geändert habe, noch kann ich ihn mit FHEM stellen. Ich werde mir die Übergabe zwischen OWDevice und OWNet noch mal ansehen.

Gruß Jörg

[Josch]

Neue Erkenntnisse:

   
• FHEM verwendet eine eigene OWNet.pm (.../FHEM/lib/), nicht die mit perl mitgelieferte. Damit verhalten sich eigene Perl-Scripts anders als unter FHEM ausgeführte.
• mit der eigenen OWNet.pm funktioniert das Schreiben nicht
• mit der OWNet.pm aus dem perl5-Pfad funktioniert das Schreiben nicht
• mit der im Wiki für Jessie empfohlenen OWNet.pm funktioniert das Schreiben jetzt (wieder)

Ich habe also prinzipiell wieder den Stand wie vor dem 16.01., nur mit Stretch statt Jessie.
Daraufhin habe ich die Logfiles nochmal nach Fehlern durchgesehen. Tatsächlich gab es am 16.01. beim Neustart einen Fehler:

Code Auswählen Erweitern

2018.01.16 17:12:55 1: PERL WARNING: Use of uninitialized value $dir in pattern match (m//) at /usr/share/fhem/FHEM/11_OWDevice.pm line 743.
Ab dem dritten Neustart danach tauchte im Log bei jedem Neustart die folgende Zeile auf:

Code Auswählen Erweitern

2018.03.04 12:13:00 1: PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 2716.
Verwendete Version von FHEMWEB.pm war: # $Id: 01_FHEMWEB.pm 16153 2018-02-11 17:02:29Z rudolfkoenig $
Möglicherweise war in den Daten von meinem DS2413-Device irgend etwas zerschossen, was diesen Fehler erzeugte. Jedenfalls ist jetzt die Meldung weg und es funktioniert wieder. Das ist schön. Allerdings hätte ich schon gerne die Ursache gewusst.

Gruß Jörg

[Dr. Boris Neubert]

Hallo Jörg,

das hilft sehr viel weiter! Danke, dass Du Deine Erkenntnisse hier mitteilst.

Mir scheint es plausibel, dass die bei den Quellen von owfs mitgelieferte OWNet.pm von

https://sourceforge.net/p/owfs/code/ci/master/tree/module/ownet/perl5/OWNet/lib/OWNet.pm

mit owfs funktioniert. Es gibt wenige aber nicht immaterielle Abweichungen zur bei FHEM mitgelieferten Version von OWNet.pm.

Ich fasse zusammen: mit dem aktuellen owfs 3.1p5-1 unter Raspian Stretch und mit der o.g. OWNet.pm in FHEM/lib funktioniert es bei Dir. Kannst Du das bitte bestätigen?

Viele Grüße
Boris

[papa]

Ich hatte die Lösug auch schon mal hier beschrieben.

[Dr. Boris Neubert]

Ich hatte die Lösug auch schon mal hier beschrieben.

Hat es nicht zu mir geschafft. Ich lese aus Sparsamkeit keine OWX-Threads mit.

Nehme das als zusätzliche Bestätigung.

Viele Grüße
Boris

[Josch]

@Boris: Ja, kann ich so bestätigen.
@papa: Die (Nicht-)Verwendung dieser OWNet.pm war auch nicht mein Problem; die verwendete ich schon seit August letzten Jahres. Trotzdem lief die Sache plötzlich nicht mehr, wie oben bereits beschrieben.

Gruß Jörg

[Prof. Dr. Peter Henning]

aus Sparsamkeit keine OWX-Threads

Der ist gut...

LG

pah

[Dr. Boris Neubert]

@papa: Die (Nicht-)Verwendung dieser OWNet.pm war auch nicht mein Problem; die verwendete ich schon seit August letzten Jahres. Trotzdem lief die Sache plötzlich nicht mehr, wie oben bereits beschrieben.

Unter der Annahme, dass Du morgen auf dem aktuellen Stand aus dem Update bist (keine Datei vom Update ausgeschlossen): geht es damit oder bleibt das im Ausgangspost beschriebene Problem?

[1of16]

Moin Boris,

zufällig bin ich auf diesen Thread gestoßen, da heute morgen meine FHEM-Installation beim Start eine 100% CPU Last verursacht hat und dadurch "hing".
Scheinbar liegt es an der aktualisierten OWNet.pm Datei, die Vorversion (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/OWNet.pm?rev=2745&order=name) verursacht kein Problem.
Bei meiner Testinstallation konnte ich das Problem ebenfalls nachstellen.
Leider finde ich keine aussagekräftige Fehlermeldung, wenn beim Start meine beiden OWServer-Definitionen geladen werden, geht es einfach nicht weiter. Verbunden wird sich via IP/Port an zwei Raspberry PIs mit owserver-2.8p17. Auch wenn ich die Definition in der fhem.cfg auskommentiere und die Definition manuell nachhole tritt das Problem auf.
Auch das global log auf verbose 5 hat mir leider nichts zum Fehler verraten.
Würde natürlich gerne mehr Infos liefern, ich weiß nur nicht welche bzw wie

Hoffentlich hilft es dir schon.

Grüße
1of16

[Dr. Boris Neubert]

Hallo,

zufällig bin ich auf diesen Thread gestoßen, da heute morgen meine FHEM-Installation beim Start eine 100% CPU Last verursacht hat und dadurch "hing".

ich nehme an, Du bist auf Raspbian Jessie. Hast Du eine Möglichkeit, auf owserver 3.1 zu gehen, oder geht das nur bei Stretch?

Viele Grüße
Boris

[1of16]

Hallo,

ich nehme an, Du bist auf Raspbian Jessie. Hast Du eine Möglichkeit, auf owserver 3.1 zu gehen, oder geht das nur bei Stretch?

Viele Grüße
Boris

Hi,

owserver 3.1 geht wohl nur bei Stretch.
Aber ich wollte die beiden PIs ohnehin mal updaten....

Grüße
1of16

[Dr. Boris Neubert]

Hallo,

schau bitte mal, ob Dir diese Änderung hilft, die ich gerade gemacht habe:

https://forum.fhem.de/index.php/topic,85542.msg783045.html#msg783045

Viele Grüße
Boris

[Josch]

Hallo Boris,
ja mit Deiner Änderung geht es. So richtig gut fand ich die Verwaltung eigener OWNet-Versionen nicht und wollte vorschlagen, stattdessen immer die durch das Paket libownet-perl installierte zu verwenden. Sicherheitshalber habe ich das mal auf meinem Ubuntu 16.04 ausprobiert und musste feststellen, dass die dort installierbare libownet-perl.3p1 auch eine fehlerhafte OWNet.pm enthält. Verwendet man Deine 3p5-Version, dann geht es. Also gibt es offenbar z.Zt. keine Alternative zu Deiner Lösung.
Gruß Jörg