FHEM hängt sich auf, scheinbar wegen OWServer Problem

[ojb]

Hallo Leute,

ich habe zwei 1-Wire-Bussysteme an meinem FHEM laufen, einmal remote von einem Raspi (Wohnziimmer Luftgüte) und einmal direkt am FHEM-Rechner über USB durch einen 1-Wire Coupler.

Beide Systeme sind per OWServer verbunden. Heute hatte ich das Problem das FHEM hing und das letzte im Log war ein "Successfully connected".

Ich habe beide OWServer mit noblocking versehen? Warum hängt FHEM dann?

Jetzt habe ich mal verbose 5 auf den OWServer gegeben und schau mal was passiert.

Hat jemand eine Idee, was ich noch machen könnte?

Vielen lieben Dank im Voraus.
Oli

[ojb]

So, heute ist der Fall wieder aufgetreten. Hier das Log:

Code: [Auswählen]

2021.07.04 12:13:47 5: OWServer child ID for reading '/1D.0DCC0F000000/counters.A' is 9302
2021.07.04 12:13:47 5: OWServer child read /1D.0DCC0F000000/counters.A: 1007027
2021.07.04 12:13:47 5: OWServer child ID for reading '/1D.0DCC0F000000/counters.B' is 9304
2021.07.04 12:13:47 5: OWServer child read /1D.0DCC0F000000/counters.B: 670299
2021.07.04 12:14:42 5: OWServer child ID for reading '/28.CB4729050000/temperature' is 9332
2021.07.04 12:14:42 5: OWServer child read /28.CB4729050000/temperature: <undefined>
2021.07.04 12:14:42 5: OWServer: undefined response from child 9332
2021.07.04 12:14:42 3: OW_Temperatur_Dachgeschoss: reading temperature did not return a value
2021.07.04 12:14:44 5: OWServer child ID for reading '/28.F75EA7040000/temperature' is 9346
2021.07.04 12:14:48 1: OWServer: read timeout for child 9346
2021.07.04 12:14:48 3: OW_Temperatur_Einhausung: reading temperature did not return a value
Can't call method "read" on an undefined value at ./FHEM/10_OWServer.pm line 367.
2021.07.04 12:14:49 5: OWServer child ID for reading '/26.7C827C010000/HIH4000/humidity' is 9349
2021.07.04 12:14:50 5: OWServer: undefined response from child 9349
2021.07.04 12:14:50 3: OWServer_ojblxserver: Opening connection to OWServer ojblxserver:4304...
2021.07.04 12:14:50 3: OWServer_ojblxserver: Successfully connected to ojblxserver:4304.
Um jede Hilfe dankbar ...

[Dr. Boris Neubert]

Hi Oli,

schau Dir bitte mal die Informationen zu den Versionen gleich am Beginn des Commandref-Eintrags zum OWServer an.

Grüße
Boris

[ojb]

Hallo Boris,

alles klar mache ich. Meinst Du es kann daran liegen?

EDIT:
Mein Server und mein Raspi auf denen owserver läuft laufen beide mit 3.2p3. Ich hab jetzt die OWNet.pm gesucht, aber nur 3.2p2 gefunden. Die hab ich eingespielt und FHEM neugestartet. Mein OWServer sagt jetzt OWSERVER_VERSION = 3.2p3.
Ist das ein Problem wenn die p-Version nicht übereinstimmt?

Ich habe übrigens festgestellt, dass mein UBS 1-Wire Koppler sich x-mal ab- und angemeldet hat auf USB. Ich habe jetzt eine andere Leitung verlegt. Seitdem ist es vieeeeel besser.

Was ich auch festgestellt habe war, dass das ganze OWFS nicht mehr ging, also die Weboberfläche war nicht mehr erreichbar, also ist owhhtpd bzw. owserver gehangen oder abgestürzt.
Dennoch hätte ich jetzt erwartet dass soetwas nicht zu einem FHEM-Hänger führen darf.

Was meinst Du?

Danke und liebe Grüße
Oli

[Dr. Boris Neubert]

Mein Server und mein Raspi auf denen owserver läuft laufen beide mit 3.2p3. Ich hab jetzt die OWNet.pm gesucht, aber nur 3.2p2 gefunden. Die hab ich eingespielt und FHEM neugestartet. Mein OWServer sagt jetzt OWSERVER_VERSION = 3.2p3.
Ist das ein Problem wenn die p-Version nicht übereinstimmt?

Vielleicht, vielleicht auch nicht. Es hängt davon ab, ob der Patch von p2 auf p3 die Kommunikation verändert, aber das scheint mir unwahrscheinlich.

Was ich auch festgestellt habe war, dass das ganze OWFS nicht mehr ging, also die Weboberfläche war nicht mehr erreichbar, also ist owhhtpd bzw. owserver gehangen oder abgestürzt.
Dennoch hätte ich jetzt erwartet dass soetwas nicht zu einem FHEM-Hänger führen darf.

Nicht alle Kommunikation zwischen FHEM/OWSERVER und owserver ist asynchron. Es ist also durchaus normal, dass insbesondere nach dem Start FHEM hängt, wenn schon die erste Kontaktaufnahme mit dem owserver hängt.

[Schraubenzieher]

Hallo,
hatte auch Probleme mit OWFS und nicht erreichbaren Webinterface !

Meine Konstellation:

RaspberryPi 1 mit Fhem
RaspberryPi 2 mit OWServer und Sensoren

Hatte in fhem.cfg folgende configuration:

Code: [Auswählen]

define myOWS OWServer 192.168.0.104:4304
setuuid myOWS 615dfd51-f33f-6f16-291b-4e1b64d29ca6ad80
attr myOWS room OWDevice
define DS18S20_E037D6020800 OWDevice 10.E037D6020800 60
setuuid DS18S20_E037D6020800 615dfd51-f33f-6f16-cd49-b0fba18b336b14f6
attr DS18S20_E037D6020800 IODev myOWS
attr DS18S20_E037D6020800 alias DS1820_Bad
attr DS18S20_E037D6020800 model DS18S20
attr DS18S20_E037D6020800 room Bad,OWDevice
define DS18S20_AE8219010800 OWDevice 10.AE8219010800 60
setuuid DS18S20_AE8219010800 615dfd54-f33f-6f16-814e-2d68c6ba50405f58
attr DS18S20_AE8219010800 IODev myOWS
attr DS18S20_AE8219010800 alias DS1820_Arbeiten
attr DS18S20_AE8219010800 model DS18S20
welche die ersten Stunden unauffällig lief.
Am nächsten Morgen war das Webinterface nicht mehr erreichbar.
Erst nach löschen der OW-Devices per Konsole aus der fhem.cfg und Neustart war Fhem per Browser wieder erreichbar.

Für die einzelnen Sensoren gab es folgende Fehlermeldung im Log:

Code: [Auswählen]

DS18B20_FF0948841603: reading temperature did not return a value
Nur brachte mich das erst nicht auf die Idee den Fehler der Unerreichbarkeit dort zu suchen.
Auch im syslog gab es keine Anhaltspunkte.
Alle Komponenten Fhem und das System sind denke ich auf dem aktuellen Stand (Fhem-update,System-update).

Jetzt brauchte ich eine Alternative um meine Sensoren auswerten zu können, jemand eine Idee?

Dank und LG
Ralf

[Dr. Boris Neubert]

hatte auch Probleme mit OWFS und nicht erreichbaren Webinterface !

Zum einen solltest Du das nonblocking-Attribut setzen. Zum anderen herausfinden, warum der owserver auf dem Raspi 2 vom Raspi 1 aus nicht erreichbar ist. Dazu würde ich das Webinterface von owserver aktivieren und anschauen, ob dieses erreichbar ist und etwas über die Fehlerzustände des owserver zu sagen hat.

[Schraubenzieher]

Habe nun das OW-Device wieder angelegt und nonblocking gesetzt. Das Webinterface vom OWServer ist aktiviert. Ob der OWServer tatsächlich zu der Zeit nicht erreichbar war kann ich leider nicht mehr sagen. Vor dem Ausfall und jetzt ist er es jedenfalls. Hängen beide Raspberrys am Netzwerk-Kabel, von daher sollte es keine Verbindungsprobleme gegeben haben. Werde es erst mal so laufen lassen, mal sehen wie mit dem Attribut jetzt läuft.

Nachtrag:
Habe jetzt das OWServer-Device mit dem Attribut "nonblocking" seit gut 48 Stunden wieder am laufen und konnte bisher keine Hänger beim Webinterface von Fhem feststellen. Ohne dem Attribut ist das Webinterface nach kurzer Zeit nicht mehr erreichbar. Werte zur Zeit 18 Sensoren über einen 2ten Pi mit DS9490R und OWFS aus.

Gruß Ralf