OWServer/OWDevice nonblocking patch

sentinel1 · 27 April 2014, 16:35:42

Zitat von: justme1968 am 23 April 2014, 23:25:57
fehler gefunden und oben 10_OWServer.pm aktualisiert. (es war der . in den namen der readings)

gruss
andre

hallo,

habe die neuen OWServer/Device getestet mit einen DS2401, auch hier werden nicht mehr alle readings aktualisiert sobald bei OWDevice nonblocking auf 1 steht.
Einzig der id reading wird weiter aktualisiert.Mit nonblocking auf 0 bei OWDevice werden alle readings aktualisiert.
Attribut nonblocking muß schon bei Server und Device gesetzt werden,oder?

gruß
Claudiu

justme1968 · 27 April 2014, 16:41:10

ja. das hatte ich oben schon geschrieben.

ich kann gerade noch nicht unterscheiden ob ein device nur nicht da ist oder ob owfs nicht geantwortet hat.

die augenblickliche version unterstützt nur 'normale' readings. present, location und alarm kommt in der nächsten version.

gruss
andre

sentinel1 · 27 April 2014, 16:49:27

ok,Danke für die schnelle Antwort

gruss,
Claudiu

justme1968 · 29 April 2014, 12:02:41

ich schaue mir gerade die id/present/location und alarm readings an und mir fällt auf das zum einen für id&co pro device owfs mehrfach und zum teil mit den gleichen anfragen aufgerufen wird und das zum anderen bei jeder einzelnen anfrage eigentlich die informationen vorhanden sind alle id devices direkt zu aktualisieren.

aus meiner sicht wäre es sehr viel effizienter alles was id/present/location betrifft so umzubauen das von einer zentralen stelle das polling gemacht wird sobald es das erste device mit interface 'id' gepolt wird. von hier aus sollten dann auch alle in frage kommenden devices aktualisiert werden. das sollte z.b. die zahl der abfragen bei 3 'id' devices von 9 auf 1 oder 2 reduzieren. gerade in verbindung mit der echten nonblocking abfrage einiges bringen.

in einem nächsten schritt könnte man die id/present/location anfragen in einen eigenen tread/prozess auslagern und unabhängig von den 'normalen' readings bearbeiten. damit sollten für id sehr viel bessere antwortzeiten möglich sein als es jetzt der fall ist.

ich vermute für alert/alarm gilt ähnliches.

gibt es kommentare, einwände oder vorschläge?

gruss
andre

eldrik · 29 April 2014, 12:58:15

Hi,

klingt für mich erst einmal plausibel, dass man sich hierdurch Abfragen sparen könnte wenn die Infos bereits im ersten Run hierfür vorliegen, insofern sich die owfs Implementierung hierbei nichts gedacht hat?

Greetz
Eldrik

eldrik · 02 Mai 2014, 20:11:28

Hmm scheinbar funktioniert nonblocking unter OWDevice (bei mir bisher nur mit ds2408 3x im Einsatz) nicht 100%ig rund, heute bekam ich keine Regenmeldung und bei meinem per Luftfeuchte gesteuerten Badezimmer Veluxfenster keine Öffnungsbenachrichtigung daher entschied ich mich den nonblocking Parameter des betroffenen ds2408 zu entfernen, sogleich kam die Meldung, dass das Veluxfenster geöffnet wurde.

Ein anderer ds2408 an dem Fenster und Bewegungsmelder hängen meldete jedoch regelmäßig Bewegung über die Bewegungsmelder.

Greetz
Eldrik

justme1968 · 02 Mai 2014, 20:27:03

kannst du mal bitte von dem verhalten ein log mit verbose 5 auf dem device und auf dem zugehörigen owserver machen?

wenn es geht ein mal mit und ein mal ohne nonblocking.

gruss
andre

eldrik · 03 Mai 2014, 06:53:28

hi,

anbei der Auszug aus dem Log, was auffällt, trotz verbose5 konnte ich keine owdevice Nachrichten sehen.

6:19 -6:21 ist verbose5 aktiviert und nonblocking 1 beim device und server, danach ohne nonblocking bzw nonblocking 0

Edit: ich bin mir mittlerweile ziemlich sicher, dass das Problem, mit meinem Raspberry und einem Problem mit dem Filesystem zusammenhängt, scheinbar "vergisst" dieser nach einem Reboot die vorher gespeicherten bzw. zuletzt getauschten Dateien und es wurde wieder die OWServer.pm verwendet, welche noch ein Problem mit den readings hatte.

Greetz
eldrik

eldrik · 14 Mai 2014, 08:36:39

Hey Andre,

heute morgen ist mir aufgefallen, dass auf meiner Fhem Hauptinstanz von einer entfernten Pi fhem2fhem Instanz keine 1Wire Logdaten mehr übermittelt worden (seit 02:00 Uhr), bei Betrachtung der selbigen steht im Log

2014.05.14 06:47:36.032 1: OWServer: Cannot fork: Cannot allocate memory
2014.05.14 06:47:36.037 1: OWServer: Cannot fork: Cannot allocate memory
2014.05.14 06:47:37.007 1: OWServer: Cannot fork: Cannot allocate memory
2014.05.14 06:47:37.011 1: OWServer: Cannot fork: Cannot allocate memory

Der Raspberry war ca. 4 Tage online und der einzige 1Wire Baustein mit nonblocking 1 ist ein DS2408 über den RPi Monitor konnte ich sehen, dass ansich noch Memory zur Verfügung gestanden hätte, ein restart von fhem hat dann zu einem fortschreiben der Logdaten und Aufnahme des 1Wire betriebs geführt.

Wahrscheinlich fällt das unter Optimierung Memoryfreigabe etc?

Gruß
Jens

eldrik · 15 Mai 2014, 19:30:34

Hi,

beim DS2450 ist mir auch aufgefallen, das bei nonblocking 1 die Readings nicht mehr aktualisiert werden.

Greetz
Eldrik

justme1968 · 16 Mai 2014, 11:03:30

irgendwo wird noch etwas nicht richtig aufgeräumt oder geschlossen. eventuell überholen sich auch die abfragen. ich würde sage das ist mehr ein bug als nur optimierung

das mit dem DS2450 ist seltsam. zumindest alles was normale readings sind (volt.x) sollte normal funktionieren.

gruss
andre

eldrik · 18 Mai 2014, 14:51:33

Der Memory Verbrauch scheint wirklich mit der Version zusammenzuhängen, ich hab meine Fhem Instanzen zwischenzeitlich von meinen RPis auf meinen Mac Mini Server migriert und nach einigen Tagen hatten die beiden Instanzen jeweils um die 900MB allokiert, Tendenz steigend bis zu einem Restart

Greetz
Eldrik

justme1968 · 31 Mai 2014, 11:06:42

kurzer zwischenstand...

ich verfolge seit vorgestern noch einen zweiten und generelleren weg. das ist zwar mehr aufwand um das drum rum zum laufen zu bekommen funktioniert aber fast (oder sogar ganz) ohne änderungen am modul selber (keine umstellung auf parse/dispatch) und kann auch das blockieren beim fhem start abfangen.

die idee ist einzelne fhem module oder gruppen von zusammengehörigen modulen in einen eigenen fhem prozess auszulagern und zwischen dem parent und der sandbox in beide richtungen zu kommunizieren. vom konzept ist das so ähnlich wie von hand die kritischen module in eine zweite fhem instanz auszulagern und die kommunikation per fhem2fhem zu machen. im unterschied dazu geht es aber (fast) völlig automatisch und erfordert nur ein abgewandeltes define

Code Auswählen

define [sandbox] <name> <modul> <args...>und alles andere macht fhem im hintergrund automatisch. also z.b. umleiten von set/get/attr und forwarden von readingsUpdate.

ich werde versuchen diese version zuerst fertig zu stellen und erst wenn dieser generelle ansatz nicht ausreicht tatsächlich die OWServer/OWDevice module low level weiter auf dispatch/parse umstellen.

gruss
andre

justme1968 · 03 Juni 2014, 00:20:23

eine erste test version des sandbox konzeptes gibt es hier: http://forum.fhem.de/index.php/topic,18275.msg173732.html#msg173732.

es sind die normalen unveränderten OWServer/OWDevice module verwendbar. nonblocking sollte für das OWServer device gesetzt sein weil der aktuelle modul stand nur die asynchrone kommunikation implementiert hat und noch nicht das beenden und neustarten von hängengebliebenen sandboxen.

damit gibt es keinerlei perfmon meldungen mehr aus dem master fhem sondern nur noch aus dem jeweiligen sandbox fhem.

gruss
andre

eldrik · 03 Juni 2014, 09:38:26

Hey,

da ich nicht im Developerbereich posten kann:

Nach dem kopieren von fhem.pl und 93_sandbox.pm erhielt ich eine Fehlermeldung permission denied ./fhem.pl line 293 der 93_sandbox.pm ich musste im Anschluss ein chmod 777 auf die fhem.pl absetzen, FHEM läuft derzeit unter root und die Dateien sind auch owned bei root.

Danach konnte ich eine OWServer Instanz definieren, sehe jedoch in fhem die Sandbox und die OWServer Instanz nicht unter unsorted, in die OWServer Instanz kam ich folglich nur über ein erneutes define bei dem der OWServer Instanzname im Anschluss in der "already defined" Meldung per Links anklickbar ist, unter der OWServer Instanz habe ich nonblocking 1 gesetzt.

In der Terminalausgabe erhalte ich laufend die Meldungen:

Argument "19.0625 alarm: 1" isn't numeric in sprintf at (eval 1216) line 1.
Argument "19.0625 alarm: 1" isn't numeric in sprintf at (eval 1217) line 1.
Argument "19.0625 alarm: 1" isn't numeric in sprintf at (eval 1218) line 1.
Argument "19.0625 alarm: 1" isn't numeric in sprintf at (eval 1219) line 1.
Argument "19.0625 alarm: 1" isn't numeric in sprintf at (eval 1220) line 1.
Argument "19.5 alarm: 1" isn't numeric in sprintf at (eval 2229) line 1.
Use of uninitialized value in split at ./FHEM/01_FHEMWEB.pm line 1244.
Can't use an undefined value as an ARRAY reference at ./FHEM/11_OWDevice.pm line 577.

und nach der letzten Meldung schmiert fhem ab und muss erneut gestartet werden.

Weitere Tests hab ich mir an der Stelle dann gespart

Greetz
Eldrik