Schreibzugriff auf DS2413 geht nicht mehr

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