Mit OWCounter hängt Fhem vor Mitternacht

[theWizard]

Hatte das aus versehen an einen falschen Post gehängt der sich ähnlich anhörte.

Wenn der Counter bei mir in der fhem.cfg drin steht, hört Fhem kurz vor Mitternacht das Arbeiten auf.

Dann bleibt nur noch ein kill -9 perl und ich kann Fhem neu starten und es läuft wieder bis kurz vor Mitternacht.

Ich hab die midnight Werde auf 0.0000000000000000000000000001 hat aber leider nix gebracht.

Sobald ich den Counter aus der fhem.cfg werfe läuft alles auch über Mitternacht hinweg.


Jemand ein Idee?

Gruß
Basti

[Alexander Bauer]

Hallo,
wie ist der gesamte Aufbau?

[theWizard]

Debian Whezzy auf einer Qnap
Am USB Port einen DS9097 und daran 6x DS1820 und 1x DS2423
Das ganze ist über ein Cat Patchpannel verdratet und wird mit einem Externen Netzteil versorgt

Das ganze hat letzten Winter komplett funktioniert. Irgendwann muss ein Update im Frühjahr oder Sommer das ganze geändert haben. Ich hab es anfangs auf die Hardware geschoben (da war es noch keine Qnap, sondern ein Thinclient mit extra Festplatte)

Ohne den Counter läuft das System durch. Mit dem Counter läuft es immer bis kurz vor Mitternacht. Werte werden natürlich ausgegeben.

Schönen Gruß
Basti

[unclestefan]

Hallo, gibt es zu dem Problem schon was neues? Habe das selbe Problem! Kurz vor Mitternacht wird noch einmal abgerufen und dann ist es vorbei mit Fhem

Wäre eine super Sache wenn jemand helfen könnte.

Hier ein Auszug von meiner Fhem.log. (sind die letzten Lgeinträge danach ist schluß)

2013.11.16 23:57:49 5: OWServer child ID for reading '/1D.A2D989000002/counters.A' is 3491
2013.11.16 23:57:49 5: OWServer child read /1D.A2D989000002/counters.A: 608
2013.11.16 23:57:49 5: OWServer child ID for reading '/1D.A2D989000002/pages/page.14' is 3494
2013.11.16 23:57:49 5: OWServer child read /1D.A2D989000002/pages/page.14:
2013.11.16 23:57:49 5: OWServer child ID for reading '/1D.A2D989000002/counters.B' is 3497
2013.11.16 23:57:49 5: OWServer child read /1D.A2D989000002/counters.B: 5
2013.11.16 23:57:49 5: OWServer child ID for reading '/1D.A2D989000002/pages/page.15' is 3500
2013.11.16 23:57:49 5: OWServer child read /1D.A2D989000002/pages/page.15:

[Dr. Boris Neubert]

Wäre eine super Sache wenn jemand helfen könnte.

Welches Ergebnis erhältst Du, wenn Du statt OWCOUNTER  OWDevice verwendest?

Grüße
Boris

[dougie]

Hallo Herr Dr. B.


Mir ist aufgefallen, das ich immer noch das "alte Problem" habe, das sich sowohl fhem auf der fritzbox als auch auf dem RPi einfrieren, wenn einer meiner OWServer mal kurzfristig aus dem Netz verschwindet.

Sollte das nicht inzwischen gefixed gewesen sein, oder fehlt mir da noch was?

VG
Ralf

[Dr. Boris Neubert]

Hallo Ralf,

Mir ist aufgefallen, das ich immer noch das "alte Problem" habe, das sich sowohl fhem auf der fritzbox als auch auf dem RPi einfrieren, wenn einer meiner OWServer mal kurzfristig aus dem Netz verschwindet.

Sollte das nicht inzwischen gefixed gewesen sein, oder fehlt mir da noch was?

ich habe dazu mittlerweile alles vergessen... 

Ich meine, daß das eigentliche Problem in OWNet.pm lag. Dafür gibt es aber kein Update.

Läßt sich mit den Infos von Martin aus dem alten Topic dazu und Debugging-Kode herausfinden, an welcher Stelle das Ganze klemmt? Falls Du das selber angehen möchtest, bitte neuen Topic eröffnen. Ich komme derzeit nicht dazu, mich damit selbst zu befassen, stehe aber gerne als Sparringspartner zur Verfügung.

Grüße
Boris

[fiedel]

Mir ist aufgefallen, das ich immer noch das "alte Problem" habe, das sich sowohl fhem auf der fritzbox als auch auf dem RPi einfrieren, wenn einer meiner OWServer mal kurzfristig aus dem Netz verschwindet.

Sollte das nicht inzwischen gefixed gewesen sein, oder fehlt mir da noch was?

Hi Ralf,

das ist noch nicht vom Tisch. Betateilchen oder justme hat letztens einen Workaround dazu gepostet, wo er OWServer so eingereichtet hat, dass er quasi asynchron wird. Es werden die Werte beim Server vorab ausgelesen, zwischengespeichert und bei Anfrage vom Client sofort ausgeliefert. Das verhindert die Wartezeit auf dem Client. So habe ich das zumindest verstanden. Mir war so, als ob die Hänger damit auch behoben sind. Und dann gab es noch das Attribut "nonblocking", was auch in diese Richtung geht.
Martin Fischer steht wohl in Kontakt zu den OWFS- Developern um einen grundlegenden Fix zu erwirken. Soweit ich mich richtig erinnere...

Gruß

Frank

[UweH]

Man siehe hier:http://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html am Ende der Seite...

[justme1968]

es gibt eine ganze reihe dinge die hier mit rein spielen.

- das synchrone lesen: jedes lesen eines 1-wire temperatur sensors dauert etwa 1.5 sekunden. genau so lange blockiert fhem. hierzu gibt es keinen lösung. nur einen workaround mit einem script das den owfs cache befüllt hält so das fhem die werte sofort bekommt. das ist nicht elegeant und nur sinnvoll wenn ofws auf einem eigenen von fhem getrennten system läuft. nonblocking hilft hier leider nicht.

- nonblocking selber verschlimmert nach meinen erkenntnissen dieses problem sogar noch etwas da zu jedem lesen der overhead des forkens noch dazu kommt und danach dann trozdem blockierend gelesen wird.

- das blockieren wenn owfs nicht erreichbar ist: fhem blockiert komplett und für längere zeit bis unendlich wenn owfs nicht errichbar ist. auch hier hilft nonblocking leider nicht. ich vermute diese problem könnte man mit dem angesprochenen OWNet.pm fix beheben. dazu weiss ich aber nichts.

gruss
  andre

[dougie]

...nur um das Ganze noch mal zu rekapitulieren: das Problem lag seinerzeit bei der Implementierung von owserver (Dem Linux Paket owserer, NICHT dem FHEM Modul!)

Problem war, das wenn der OW-Server nicht antwortet (No Socket) , weil nicht da, hat OWNet.pm "nichts" an fhem zurück geliefert. Wir hatten seinerzeit bei den Entwicklern angefragt, und die hatten das so abgeändert, das in diesem Fall "undef" zurück geliefert wurde.

Ich meine mich zu erinnern, das Boris das in die OWNet.pm irgendwie eingebaut hatte, aber ich kann mich beim besten Willen auch nicht mehr an die Details erinnern.

@Andre: etweder ich verstehe es falsch, oder wir meinen etwas anderes: es ist doch gerde der Charme von owserver (dem Linux Paket) das es die Abfrage der 1W Devices im Hintergrund erledigt, und die Daten in einer lokalen Datenbank speichert und zur Abfrage vorhält. Das sollte völlig unanbhängig von fhem laufen. Nur die Grossbuchstaben-Module machen das so wie du beschreibst. Daher bin ich ja auch weg von denen.

VG
Ralf

[justme1968]

OWserver fragt zwar im normalfall die gecachete version von owfs an aber wenn der wert gerade nicht im cache ist muss er ja von sensor gelesen werden. und dann wartet fhem.

wie lange owfs braucht die daten vom sensor zu lesen hängt vom sensor ab. die temperatursensoren brauchen in der höchstem auflösung fast 1.5 sekunden. die neuen daten bleiben dann glaube ich normalerweise etwa 10 sekunden im owfs cache. das ist konfigurierbar.

der cache wird aber eben leider nicht automatisch gefüllt wenn ein wert zu alt wird sondern erst wieder bei der nächsten anfrage. mein etwas unschöner workaround aus dem alten thread sorgt dafür das der cache im hintergrund immer wieder aktualisiert wird.

du kannst das ganz einfach beobachten: das erste get temperature auf einen sensor der noch nicht abgefragt wurde dauert genau die 1.5 sekunden. dir nächsten kommen sofort zurück. bis das cache alter erreicht ist. dann dauert es genau ein mal wieder die 1.5 sekunden.

was auch etwas helfen würde ist eine der niedriger aufgelösten varianten abzufragen. die genauigkeit sollte für fast alle anwendungen locker reichen. das problem ist nur das das mit OWDevice nicht geht ohne das sich der Name des readings ändert. es wäre schön wenn das umabhängig voneinander wäre.

gruss
  andre

edit: das andere problem das fhem komplett hängt wenn owfs nicht erreichbar ist kann ich reproduzieren. bis hin zu einer reproduzierbaren endlosschleife die ich dann in strace sehe. was ich nicht versehe ist das es mit einer ip adresse zu tun hat mit der ich nichts anfangen kann.

[ntruchsess]

was auch etwas helfen würde ist eine der niedriger aufgelösten varianten abzufragen. die genauigkeit sollte für fast alle anwendungen locker reichen. das problem ist nur das das mit OWDevice nicht geht ohne das sich der Name des readings ändert. es wäre schön wenn das umabhängig voneinander wäre.

OWTherm kann das seit 8 Tagen
Atrribute 'resolution', erlaubte Werte: 9,10,11,12
geht auch mit OWServer
(muss ich noch in der commandref dokumentieren)

- Norbert

[justme1968]

mit dem angehängten patch kann OWDevice das auch

attribut resolution, erlaubte werte: 9,10,11,12

muss auch noch dokumentiert werden

die 12bit auflösung braucht bei mir zwischen 650 und 1600 milisekunden, die 9bit auflösung zwischen 160 und 650, beides auf die ungecacheten daten.

gruss
  andre

[unclestefan]

Habe gestern mal das gesetzte Attribut nonblocking auf 0 gesetzt und siehe da, heute Morgen ging noch alles Danke für die Denkanstöße!

[Dr. Boris Neubert]

Habe gestern mal das gesetzte Attribut nonblocking auf 0 gesetzt und siehe da, heute Morgen ging noch alles Danke für die Denkanstöße!

Habe einen Hinweis in die Doku vom OWServer eingefügt.
Boris

[Dr. Boris Neubert]

attribut resolution, erlaubte werte: 9,10,11,12

Danke André,

habe es dokumentiert und ansonsten unverändert eingecheckt.

Grüße
Boris