OWServer/OWDevice nonblocking patch

[justme1968]

da OWDevice nicht wirklich auf echten nonblocking betrieb vorbereitet ist und das einbauen einer parseFn eine ziemliche fummelarbeit die sich noch etwas hin zieht habe ich als ad hoc lösung diese beiden patches angehängt.

damit blockiert OWServer nicht mehr unendlich wenn der owserver nicht mehr erreichbar ist sondern der mechanismus der mit nonblocking eigentlich vorgesehen war greift tatsächlich. es wird nur maximal 4 sekunden pro wert auf eine rückmeldung gewartet. im internal value READ_FAILED wird gezählt wie oft das lesen nicht geklappt hat.

der zweite patch verzögert das erste lesen aller OWDevice devices um einen zufälligen wert von bis zu 20 sekunden. damit wird verhindert das beim starten alle OWDevice ihre timer direkt hintereinander starten und so beim blockieren des OWServer devices fhem für ein mehrfaches der 4 sekunden am stück blockieren. mit der zufälligen verzögerung hat fhem zwischendurch immer mal wieder zeit zum reagieren. das wirkt sich auch im 'normalbetrieb' positiv aus da sich die auslese zeit der DS18B20 auch nicht mehr im block direkt nacheinander bemerkbar macht sondern verteilt wird.

dem timeout von 4 sekunden könnte man sogar noch weiter reduzieren selbst bei einer sekunde geht zwar ab und an ein temperatur wert verloren aber fhem bleibt nicht hängen.

gruss
  andre

[UweH]

Danke, ich werde es testen...nachdem ich vorhin irrtümlich das falsche Netzwerkkabel aus dem Switch gezogen und damit gleich 2 "Zuliefer"-Raspis stillgelegt habe. FHEM bleibt sofort hängen...nun hoffentlich nicht mehr 

[justme1968]

der patch oben hat noch zwei nachteile:

- wenn der owserver beim starten von fhem nicht erreichbar ist bleibt fhem trozdem hängen.
- wenn alert oder oder devices mit dem interface id gelesen werden auch

für letzteres habe ich jetzt auch einen workaround. der ist im patch unten angehängt. wenn die eigentlichen reading werte nicht gelesen werden können wird alert und id gar nicht erst versucht. das ist nicht perfekt well der aussetzer genau nach dem lesen der readings und vor dem lesen von alert und id passieren kann. aber es ist deutlich besser als nichts. man könnte das noch etwas optimieren in dem man das lesen aller readings abbricht und nicht mehr auf jeden einzelnen timeout wartet sobald das erste lesen schief gegangen ist. das kommt drauf an ob kurze aussetzer oder längere nicht erreichbarkeit wahrscheinlicher sind.

gruss
  andre

[justme1968]

ich hatte seit den hier vorgeschlagenen änderungen keinen einzigen hänger mehr in fhem. auch wenn der per wlan angebundene raspberry pi mit owfs wieder mal probleme hat sehe ich nur den READ_FAILED wert hoch gehen und spätestens nach dem timeout läuft fhem weiter.

es wäre schön wenn der patch (und der reload fix aus dem anderen thread) eingecheckt werden könnte.

gruss
  andre

[Dr. Boris Neubert]

Hallo,

steht schon eine Weile auf meiner Todo-Liste. Demnächst in diesem Theater...

Viele Grüße
Boris

[Dr. Boris Neubert]

Eingecheckt!
BN

[justme1968]

sehr schön danke.

es gibt zu dem patch noch eine ergänzung oben drauf damit rereadcfg auch wieder funktioniert. schau mal bitte hier: http://forum.fhem.de/index.php/topic,17328.msg113416.html#msg113416

gruss
  andre

[UweH]

Moin,

kurze Rückmeldung von mir: Funktioniert! Nach abkoppeln eines externen Raspis genehmigt sich FHEM eine kurze Bedenkzeit und werkelt dann weiter. Auf der Konsole werden zwar eine Menge Fehlermeldungen vom OWServer-Modul produziert, aber wenigstens friert FHEM nicht völlig ein.
Sehr gut, Danke.

[cwagner]

- auch auf einer Fritzbox kann ich den Erfolg bestätigen.

Christian

[Dr. Boris Neubert]

Ein dickes Dankeschön an Andre für seine Patches!

Viele Grüße
Boris

[ollir]

Hallo,

leider funktioniert es bei mir nicht. Trotz update hängt sich der "Haupt-FHEM", wenn der abgestetzte Raspberry mit owfs kurz nicht erreichbar ist.
Der "abgesetzte Raspberry" hängt sich nur kurz auf.

Der owfs läuft nicht unter "localhost" sondern unter 192.168.178.11 im Netz.

Funktioniert der OWDevice nonblocking Patch nur, wenn owfs auf dem selben Rechner läuft

VG
Olaf
 

[justme1968]

hast du das attribut nonblocking gesetzt ?

gruss
  andre

[ollir]

Hallo Andre,

attr nonblocking ist auf 1 gesetzt. Es funktioniert auch local auf dem Rechner, wo owfs läuft.
Jedoch nicht auf dem abgesetzten Raspberry.

VG
Olaf

[justme1968]

nur um ganz sicher zu gehen. beide fhem installationen sind auf dem gleichen neuen stand? und in beiden fhem installationen ist jeweils nonblocking auf 1 gesetzt?

gruss
  andre

edit: und auch noch wichtig: der patch hilft zur zeit nur wenn owfs zwischendurch nicht erreichbar ist. wenn owfs beim starten von fhem nicht erreichbar ist hilft er nicht und in dem seltenen fall das owfs genau zwischen dem auslesen eines sensors und dem nachfolgenen auslesen von alarm oder presence ausfällt hilft er auch nicht. sonst sollte es immer funktionieren. egal ob lokal oder remote.

[ollir]

Hallo Anre,

beide FHEM sind geupdatet und beide OWServer sind auf nonblocking auf 1 gesetzt und beide laufen auf 192.168.178.11:4304 und nicht auf localhost:4304.

VG
Olaf