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

[Dr. Boris Neubert]

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.

So richtig gut finde ich es auch nicht, die OWNet.pm über FHEM einzuspielen. Aber die gleiche Beobachtung wie Du habe ich auch schon bei der Erstentwicklung des Moduls gemacht und deswegen die zweitschönste aber funktionierende Variante programmiert. 

[Reinerlein]

Hallo,

ich habe heute ein Update durchgeführt, und danach ein nahezu leeres Fhem gehabt. Ursache war die neue OWServer.pm, die wohl durch irgendwas zum Absturz gebracht wurde, und damit die Konfiguration beim Update bis auf wenige Komponenten gekürzt hatte.

Nachdem ich mit der Rücksicherung der alten 10_OWServer.pm-Version und der vorherigen Konfiguration mein System wieder laufen habe, möchte ich das gerne für die Zukunft lauffähig behalten

@Boris: Du hast die "alte" OWNet.pm im FHEM/lib-Verzeichnis gelöscht. Hatte das einen besonderen Grund? Denn nur diese funktioniert anscheinend bei mir.
Besteht nicht einfach die Möglichkeit, dass diese immer noch enthalten ist (z.B. unter einem eigenen Versions-Namens-Tag), und beim Define des Server angegeben werden könnte?

Danke schon mal...

Grüße
Reinerlein

[Dr. Boris Neubert]

Besteht nicht einfach die Möglichkeit, dass diese immer noch enthalten ist (z.B. unter einem eigenen Versions-Namens-Tag), und beim Define des Server angegeben werden könnte?

Die alte OWNet.pm ist  als OWNet-2.8pl17.pm weiterhin dabei. Hast Du die Anleitung in der commandref gesehen, wie Du die Auswahl selbst bestimmen kannst?

Viele Grüße
Boris

[Reinerlein]

Hi Boris,

ok, das hatte ich schon versucht, weil im Log stand, dass er standardmäßig die andere verwendet hatte (ich habe einen owserver der Version 2.9p8).

Dann ist das Problem ein anderes aus dem Modul
Wenn ich die neue Version verwende, wird mir für jede 1Wire-Komponente ein neues Device angelegt (ich habe nur Temperaturesensoren, sowie das eine ID-Device, welches im USB-Adapter steckt), da die Devices ja später in der Configdatei kommen, und die aktuelle OWServer-Version anscheinend nicht darauf wartet.

Des Weiteren werden *alle* Devices, die danach in der Config kommen übersprungen (von meinen 666 Devices, die fhem.pl sonst beim Start meldet, bleiben nur ca. 220 übrig).
Das ist allerdings ein sehr komisches Phänomen, was ich auch nicht weiter eingrenzen kann, da nichts dazu im Log vorkommt...
Das ist auf jeden Fall der störendere Part, da mein gesamtes Fhem so beeinflusst wird, und nicht nur die 20 1wire-Sensoren fehlen, bzw. nicht funktionieren...

Grüße
Reiner

[Josch]

Hallo Reinerlein,
hast du mal versucht, ohne eingeschaltetes autocreate zu starten und was passiert dann? Ich habe das standardmäßig deaktiviert, weil bei mir durch unvollständig empfangene FS20-Nachrichten immer irgendwelche absonderlichen neuen Geräte entstanden. Evtl. passiert hier etwas ähnliches. Und wie sieht es eigentlich in owhttpd aus? Siehst du dort deine Temperatursensoren vollständig und funktionierend?
Gruß Jörg

[Dr. Boris Neubert]

ok, das hatte ich schon versucht, weil im Log stand, dass er standardmäßig die andere verwendet hatte (ich habe einen owserver der Version 2.9p8).

Bitte relevante Log-Einträge zeigen.

Danke
Boris

[Reinerlein]

Hi Boris,

hier mal die Ausgabe ohne direkte Angabe der Version:

Code Auswählen Erweitern


2018.03.24 23:15:02 3: OWServer: OWNet version 3.1p5 loaded.
2018.03.24 23:15:02 3: OWServer: Opening connection to OWServer 192.168.0.11:4304...
2018.03.24 23:15:02 3: OWServer: Successfully connected to 192.168.0.11:4304.
2018.03.24 23:15:02 3: OWServer: owserver version 2.9p8 found.
2018.03.24 23:15:02 3: OWServer: No matching OWNet version found, using OWNet version 3.1p5.


hier mal nach der Einstellung, dass er die 2.8er-Version verwenden soll:

Code Auswählen Erweitern


2018.03.25 11:18:39 3: OWServer: OWNet version 2.8p17 loaded.
2018.03.25 11:18:39 3: OWServer: Opening connection to OWServer 192.168.0.11:4304...
2018.03.25 11:18:39 3: OWServer: Successfully connected to 192.168.0.11:4304.
2018.03.25 11:18:40 3: OWServer: owserver version 2.9p8 found.
2018.03.25 11:18:40 3: OWServer: No matching OWNet version found, using OWNet version 2.8p17.


etwas später im Log dann jeweils nochmal:

Code Auswählen Erweitern


2018.03.25 11:18:51 3: OWServer: Opening connection to OWServer 192.168.0.11:4304...
2018.03.25 11:18:51 3: OWServer: Successfully connected to 192.168.0.11:4304.


Käme denn auf einem höheren Level nähere Angaben?
Dann würde ich das nochmal versuchen, auch wenn es etwas Aufwand bedeutet, weil mein Haus währenddessen nicht gesteuert werden kann

@Jörg: Autocreate ist bei mir nur für FS20, Hörmann und Max gesperrt. Die Sensoren funktionen mit der alten OWServer.pm-Version ja hervorragend... und owhttpd habe ich deaktiviert...

Grüße
Reiner

[Dr. Boris Neubert]

Aus der Commandref:

Die OWServer-Instanz verwendet OWNet.pm von Sourceforge, um sich mit dem owserver zu verbinden. Gegenwärtig werden OWNet-Module für die Versionen 2.8p17 and 3.1p5 mit FHEM verteilt. Man kann manuell weitere Versionen hinzufügen, indem man OWNet.pm aus einer der verfügbaren Versionen extrahiert und als FHEM/lib/OWNet-<version>.pm in der FHEM-Verzeichnisstruktur speichert.

Die erste Verbindung mit dem owserver wird mit der Version 3.1p5 aufgebaut, es sei denn, dass man ausdrücklich eine andere Version mit dem optionalen Parameter <version> vorschlägt. Man sollte eine OWNet-Modulversion vorschlagen, die der tatsächlichen Version von owserver entspricht, falls FHEM nach dem Verbindungsaufbau zum owserver hängt.

Die OWServer-Instanz erkennt die Version von owserver automatisch und wählt das passende OWNet-Modul aus der Liste der verfügbaren OWNet-Module aus. Wenn kein passendes OWNet-Modul gefunden wird, wird die ursprünglich vorgeschlagene Version verwendet. Die alptraumhafte Situation mit zwei OWServer-Instanzen, die sich mit owserver-Instanzen in unterschiedlichen Versionen verbinden, wird nicht korrekt gehandhabt. Die Versionen von Server und Modul werden zum Nachschauen in den Internals der OWServer-Instanz gespeichert.

Die ow*-Pakete in der Version 3.1p5 bei Debian Stretch und die ow*-Pakete in der Version 2.8p17 bei Debian Jessie sind gut. Die ow*-Pakete in der Version 2.9 bei Debian Jessie in Kombination mit den OWNet-Modulen bei FHEM können Auffälligkeiten zeigen (Rückmeldung willkommen). Für Debian Jessie kann man owfs_2.8p17-1_all.zip auspacken und owserver, Abhängigkeiten und was man sonst so braucht mittels dpkg -i <package>.deb installieren.

Du hast 2.9p8. Entweder auf 2.8p17 umsteigen oder OWNet.pm zu 2.9p8 installieren.

[Reinerlein]

Hi Boris,

ich denke, die Version "2.8p17" ist die Datei, die vorher unter dem Namen "OWNet.pm" abgelegt war?

Ich habe die OWNet.pm ja noch da, da der Fhem-Update-Prozess die ja erstmal in Ruhe läßt. Wenn ich die (zusammen mit der alten 10_OWServer.pm) verwende, geht alles.

Wieso soll ich dann den im System installierten owserver aktualisieren?
Kann die neue 10_OWServer.pm nicht mit der alten Datei zusammenarbeiten?

Grüße
Reiner

[Dr. Boris Neubert]

Hallo,

hast Du das Zitat aus der Commandref gelesen? Ich meinte, dort genau beschrieben zu haben, was Du tun musst (in der originalen Commandref sind auch die Links, wo Du OWNet für 2.9p8 findest). Welcher Punkt davon ist nicht verständlich?

Viele Grüße
Boris

[Reinerlein]

Hi Boris,

hmm... unverständlich ist für mich der Grund, warum ich etwas in meinem Debian-System aktualisieren sollte, wenn es doch läuft.

Mit der neuen 10_OWServer.pm wurde etwas verändert, was nicht mehr mit der alten Version von 10_OWServer kompatibel ist.
Wozu sollte ich mir irgendwo eine neue OWNet.pm besorgen, wenn die früher ausgelieferte sauber funktioniert?

Ich habe mir mal die beiden neuen OWNet-Dateien gegenüber der alten Version mittels diff angeschaut. Die mit der Version "3.1p5" entspricht der ursprünglich mal ausgelieferten OWNet.pm.

Mit der läuft es aber jetzt nicht mehr!
Was mir hier nicht verständlich ist, ist wieso es mit irgendeiner anderen OWNet.pm-Version besser laufen soll? Oder wieso ich mein System da updaten sollte? Verwendest du jetzt Features, die vorher nicht verwendet wurden?

Ich sehe hier keine Problematik mit den OWNet.pm-Dateien, sondern mit der 10_OWServer.pm.
Das ist das, was ich seit Heute Mittag anmerke.
Wenn ich da auf dem Holzweg bin, dann muss ich noch rausfinden, warum.

Warum baut er zweimal hintereinander eine Verbindung zum owserver-Deamon auf?
Warum richtet er alle meine Sensoren nochmal ein (direkt nach dem ersten Verbindungsversuch)?
Irgendetwas beeinflusst die Weiterverarbeitung der Config-Dateien durch fhem.pl, da an dieser Stelle fhem.pl der Meinung ist, fertig geladen zu haben, und läuft normal weiter (dann ohne die ganzen Komponenten, die noch danach in der Konfiguration kämen...)
Ist das vielleicht wegen "autocreate" während des "init"-Zeitraums?

Edit:
Es wird direkt im Define "OWServer_loadOWNet" aufgerufen, welches wiederrum "OWServer_OpenDev" aufruft, was wiederrum "OWServer_DoInit" aufruft, was wiederrum "OWServer_Autocreate" aufruft, was am Ende wiederrum "CommandSave" aufruft (wenn autosave aktiv ist), und damit die halb geladene Konfiguration wegschreibt.
Das wiederrum zerhaut mir meine Konfiguration...

Das ganze OWServer_DoInit-Zeugs darf nicht aufgerufen werden, wenn "init_done" noch nicht gesetzt ist. Du musst die Verkettung deiner Versionsnummernsuche korrigieren...

Grüße
Reiner

[Dr. Boris Neubert]

Hallo Reiner,

hmm... unverständlich ist für mich der Grund, warum ich etwas in meinem Debian-System aktualisieren sollte, wenn es doch läuft.

Das ist ja nur eine Variante. Die andere ist die Verwendung einer passenden OWNet.pm

Ich habe mir mal die beiden neuen OWNet-Dateien gegenüber der alten Version mittels diff angeschaut. Die mit der Version "3.1p5" entspricht der ursprünglich mal ausgelieferten OWNet.pm.
Mit der läuft es aber jetzt nicht mehr!

Weder OWNet-3.1p5.pm noch OWNet-2.8p17 entsprechen der früheren OWNet.pm.

Bitte versuche einmal, OWNet.pm aus Version 2.9p8 als lib/OWNet-2.9p8.pm zu speichern. Diese Datei sollte dann geladen werden, nachdem er den owserver in der Version 2.9p8 erkennt. Wenn das funktioniert, werde ich künftig auch lib/OWNet-2.9p8.pm im Update ausliefern.

Warum baut er zweimal hintereinander eine Verbindung zum owserver-Deamon auf?

Beim ersten Mal erkennt er die Version. Dann lädt er ggf. eine passende OWNet.pm nach. Danach verbindet er sich mit der passenden OWNet.pm erneut.

Es wird direkt im Define "OWServer_loadOWNet" aufgerufen, welches wiederrum "OWServer_OpenDev" aufruft, was wiederrum "OWServer_DoInit" aufruft, was wiederrum "OWServer_Autocreate" aufruft, was am Ende wiederrum "CommandSave" aufruft (wenn autosave aktiv ist), und damit die halb geladene Konfiguration wegschreibt.
Das wiederrum zerhaut mir meine Konfiguration...

Das ganze OWServer_DoInit-Zeugs darf nicht aufgerufen werden, wenn "init_done" noch nicht gesetzt ist. Du musst die Verkettung deiner Versionsnummernsuche korrigieren...

Mist. Unglückliche Verkettung unglücklicher Umstände. Das muss ich reparieren. Update kommt in Kürze. Danke, dass Du das herausgefunden hast. Diese Situation habe ich nicht vorhergesehen und auch nicht testen können.

Viele Grüße
Boris

[Reinerlein]

Hi Boris,

Weder OWNet-3.1p5.pm noch OWNet-2.8p17 entsprechen der früheren OWNet.pm.

Ich habe gerade gesehen, dass du die Datei am 10.3. aktualisiert hast. Diese Version funktioniert bei mir also, da ich sie gerade mit der alten 10_OWServer.pm-Version verwende.
Es ist etwas verwirrend, da sie im SVN ja gelöscht ist, und beim Fhem-Update ja bleibt wo sie ist (aber aktualisiert wird).

Wenn ich also von einer früheren OWNet.pm-Version geredet habe, meinte ich die vom 10.3. und du die von davor

Grüße
Reiner

[Dr. Boris Neubert]

Mist. Unglückliche Verkettung unglücklicher Umstände. Das muss ich reparieren. Update kommt in Kürze. Danke, dass Du das herausgefunden hast. Diese Situation habe ich nicht vorhergesehen und auch nicht testen können.

gefixt und eingecheckt.

Nochmal Danke für den Hinweis.

Viele Grüße
Boris

[Meinhard99]

Vielen Dank für die Behebung.
Ich hatte gestern bei einem Update von FHEM (vermutlich) das gleiche Problem.
Nach einem Restore von FHEM und einen erneuten Update heute sieht alles wieder OK aus.