OWServer blockiert u.U. FHEM

[Tobias]

Hi,
in der owfs.conf habe ich mein USB-Device als /dev/ttyUSB1 definiert. Alles bestens. owfshttpd, ow-server als auch die Kommunikation mit fhem funktionieren tadellos.

Jetzt hat sich aber das Device geändert (ttyUSB1 -> ttyUSB0). also habe ich die owfs.conf geändert, ow-server, owhttpd und owfs per "service <ow-xxx> restart" neu gestartet. Fhem ebenfalls neu gestartet.
Im owhttp Webfrontend funktioniert wieder alles supi, aber fhem bekommts nicht gebacken. Readings werden nicht mehr geupdatet und wenn ich das Intervall wieder auf die ursprünglichen 8sek stelle, ist fhem nicht mehr erreichbar. Der Prozess läuft, ist aber nicht mehr per webif ansprechbar. Da hilf nur noch ein kill -9

Ideen? Abgesehen von einer festen udev-regel....Warum friert sich fhem oder der owserver ein?

[Martin Fischer]

> Warum friert sich fhem oder der owserver ein?

Weil in der OWNet.pm von Paul H. Alfille (OWFS) ein Fehler ist. Genauer: OWNet.pm gibt keinen Rückgabewert, wenn die Verbindung zum owserver abreißt bzw. nicht vorhanden ist.

dougie war so nett und hat mit Paul Alfile Kontakt aufgenommen, nachdem Boris und ich dougie (der vom selben Problem betroffen war) den Grund nannten. Die Entwickler von OWFS haben es erkannt und am 03.02. bereits einen Fix dafür bereit gestellt. Nur kam weder Boris noch ich bisher dazu, das in OWServer (FHEM) zu übernehmen.

Gruß Martin

[Tobias]

danke für die info.
Aber gilt das Ganze auch wenn ich fhem neu starte??

[Martin Fischer]

> Aber gilt das Ganze auch wenn ich fhem neu starte??

wenn OWserver (FHEM) den owserver (OWFS) aus irgendwelchen Gründen (falsche IP oder Port in OWServer, owserver hört nur auf localhost, etc.) nicht erreichen kann, dann könnte das dazu führen.

Gruß Martin

[Tobias]

owserver und fhem laufen auf derselben Maschine.
fhem:

Code Auswählen Erweitern

define OWServer OWServer localhost:2125
owfs.conf:

Code Auswählen Erweitern

######################## SOURCES ########################
device = /dev/ttyUSB0
######################### OWFS ##########################

owfs: mountpoint = /mnt/1wire

######################### LOGS #########################

# use syslog
error_print = 1

####################### OWSERVER ########################

server: port = 2125

####################### OWHTTPD #########################

http: port = 2121

####################### OWFTPD ##########################

ftp: port = 3131

################ TIMEOUTS (in seconds) ##################
## Uncomment to activate.

# Cache for values that change on their own (like temperature, moisture, etc...)
#timeout_volatile = 60

# Cache for values that change on command (mostly the R/W data)
#timeout_stable = 60

# Cache for directory lists (when adding a new sensor for example)
#timeout_directory = 60

# Cache for 1-wire location
#timeout_presence = 60


[ntruchsess]

nur mal so als Anregung:
vieleicht sollte man die Zugriffe auf OWServer asynchron über Blocking.pm abwickeln, damit ein Fehler im owfs fhem nicht komplett blockieren kann. Muss mir mal ansehen, wie das sinnvoll einbindbar wäre.

- Norbert

[Martin Fischer]

> owserver und fhem laufen auf derselben Maschine.

Ich kann auf die Schnelle nicht außergewöhnliches sehen, außer das die Port nicht den Standardport entsprechen und bei device ein "/dev/ttyUSB0" steht.

Normalerweise müßte der "device = /dev/ttyUSB0" Eintrag raus und eine einfache Zeile mit

Code Auswählen Erweitern

usb in der Konfig stehen (ohne "device =" !), so wie es auch im manual steht.

Probier das mal und starte den Rechner komplett durch.

Gruß Martin

[Martin Fischer]

Hallo Norbert,

> vieleicht sollte man die Zugriffe auf OWServer asynchron über Blocking.pm abwickeln,
> damit ein Fehler im owfs fhem nicht komplett blockieren kann. Muss mir mal ansehen,
> wie das sinnvoll einbindbar wäre.

guckst Du commandref.html zu OWServer und dann findest Du das Attribute "nonblocking", das allerdings (bewußt) nicht über die Blocking.pm arbeitet aber das Gleiche macht. ;-)

Gruß Martin

[Martin Fischer]

> vieleicht sollte man die Zugriffe auf OWServer asynchron über Blocking.pm abwickeln,
> damit ein Fehler im owfs fhem nicht komplett blockieren kann. Muss mir mal ansehen,
> wie das sinnvoll einbindbar wäre.

P.S.: übrigens ist es egal ob das über "nonblocking" oder "Blocking.pm" gemacht wird. Der Fehler liegt wie beschrieben in "OWNet.pm" von Paul.

Da solch Fehler immer erst an der eigentlichen Ursache abgestellt werden sollte, haben Boris und ich noch nicht "Plan B" gezogen. "Plan A" (so wie aktuell umgesetzt) ist der objektorientierte Ansatz, der dauerhafte eine Verbindung zum owserver herstellt, die dann mit der erwähnten OWNet.pm beim Abriß der Verbindung diesen Effekt hervorbringt. "Plan B" stellt bei jeder Abfrage eine neue Verbindung her. Bei "Plan B" kann man dann das Ergebnis "abfangen" und es kommt eben nicht zu dem Effekt.

Da aber der Fehler (der übrigens schon seit min. 2008 als ich die initialen OW-Module für FHEM bereitstellte, ich ihn aber niemals auf richtig analysierte, sondern gleich auf "Plan B" wechselte) in OWNet.pm bestand, nun durch unseren Hinweis von Paul bzw. Tim bestätigt, gefixed und bereit gestellt wurde, fehlt halt "nur noch" ein nachziehen von uns in FHEM.

Gruß Martin

[Tobias]

kann man die geänderte ownet.pl schon mal testen? Oder sonstirgendwie im betastatus das Problem in den Griff bekommen?