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

[justme1968]

bitte setz mal verbose für beide auf 5 und schaue ob und wie sich die logs unterscheiden wenn es passiert.

gruss
  andre

[ollir]

Hallo Andre,

habe gerade nochmal auf beide ein update gemacht.

Leider ohne Erfolg. Das Log zeigt:

2013.12.22 20:55:34 5: OWServer child read /28.E855E2040000/temperature: 28
2013.12.22 20:55:33 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2518
2013.12.22 20:55:23 5: OWServer child read /28.E855E2040000/temperature: 28
2013.12.22 20:55:23 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2517
2013.12.22 20:55:13 5: OWServer child read /28.E855E2040000/temperature: 28
2013.12.22 20:55:13 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2516
2013.12.22 20:55:10 3: Keller_Ist:18.5
2013.12.22 20:55:10 3: Keller_Soll:17.5
2013.12.22 20:55:09 3: FS20 set Rel5_Pumpe_HZK off
2013.12.22 20:55:07 3: FS20 set Rel5_Pumpe_HZK off
2013.12.22 20:55:03 5: OWServer child read /28.E855E2040000/temperature: 28
2013.12.22 20:55:03 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2515
2013.12.22 20:54:53 5: OWServer child read /28.E855E2040000/temperature: 28
2013.12.22 20:54:52 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2514
2013.12.22 20:54:42 5: OWServer child read /28.E855E2040000/temperature: 28.0625
2013.12.22 20:54:42 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2513

Sobald ich den Raspi, wo owfs läuft vom Netz trenne, hängt sich FHEM auf.

Meine Version ist laut version:
# $Id: 11_OWDevice.pm 4430 2013-12-20 16:42:26Z borisneubert $
# $Id: 10_OWServer.pm 4430 2013-12-20 16:42:26Z borisneubert $

Vilen Dank
Olaf

[justme1968]

fehler gefunden. boris hat ein teil des patches übersehen. das schlägt unter anderem genau bei den temperatur sensoren zu.

der angehängte patch sollte helfen.

gruss
  andre

[Dr. Boris Neubert]

fehler gefunden. boris hat ein teil des patches übersehen. das schlägt unter anderem genau bei den temperatur sensoren zu.

Wie konnte das passieren? Ich habe die 11_OWDevice.pm aus dem Post genommen, den Diff in Augenschein genommen, und eingecheckt. Hmmm...

der angehängte patch sollte helfen.

Tut nicht gehen.

Kannst Du bitte einfach die volle Version hier hochladen? Danke.

Boris

[ollir]

Hallo Andre,

vielen Dank für deine schnelle Hilfe.
Habe mir gerade beim Testen (vor dem Patch) das ganze Netzwerk lahm gelegt.
Bin wieder online muß jedoch jetzt schlafen (Früh-Schicht).

Werde dann morgen testen und berichten.

Vielen Dank

Olaf

[justme1968]

anbei noch mal das komplette file.

ich vermute du hattest nur den patch aus dem eingangspost gesehen. etwas darunter gab es noch mal eine zweite version mit dieser erweiterung.

OWServer forkt ja nur in OWServer_Read nicht in OWServer_Dir und OWServer_Find. das ist auch der grund warum beim starten immer noch ein hängen bleiben möglich ist. mit der änderung hier wird aber zumindest zur laufzeit beides nicht mehr aufgerufen wenn ein normales lesen blockiert hat.

man könnte noch die polls schleife komplett abbrechen sobald das erste read fehlgeschlagen ist. das hatte ich noch nicht eingebaut.


gruss
  andre

[Dr. Boris Neubert]

Danke.

Ich brauch 11_OWDevice.pm 

Viele Grüße
Boris

[justme1968]

jetzt aber...

ich hab es oben ausgetauscht.

gruss
  andre

[Dr. Boris Neubert]

Danke. Ist eingecheckt!

Viele Grüße
Boris

[justme1968]

danke
  andre

[ollir]

Hallo Andre,

ich habe die obere OWDevice gerade eingespielt. Leider hängt er immer noch.
Jedoch bemerkt er kurz, das das Device nicht angesprochen werden kann (siehe Log) und friert dann ein. In der Versionsanzeige ist immer noch

# $Id: 11_OWDevice.pm 4430 2013-12-20 16:42:26Z borisneubert $

Ist das richtig?

2013.12.23 06:47:09 3: Keller_Ist:17.7
2013.12.23 06:47:09 3: Keller_Soll:17.5
2013.12.23 06:47:08 3: FS20 set Rel5_Pumpe_HZK off
2013.12.23 06:47:05 1: OWServer: Terminated child 2317
2013.12.23 06:46:59 3: Temp_RPi2: reading temperature did not return a value
2013.12.23 06:46:59 1: OWServer: read timeout for child 2317
2013.12.23 06:46:55 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2317
2013.12.23 06:46:24 5: OWServer child read /28.E855E2040000/temperature: 25.875
2013.12.23 06:46:24 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2315
2013.12.23 06:45:53 5: OWServer child read /28.E855E2040000/temperature: 25.9375
2013.12.23 06:45:53 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2314
2013.12.23 06:45:23 5: OWServer child read /28.E855E2040000/temperature: 26
2013.12.23 06:45:23 5: OWServer child ID for reading '/28.E855E2040000/temperature' is 2313
2013.12.23 06:45:23 5: OWServer child read /28.E855E2040000/type: DS18B20
2013.12.23 06:45:23 5: OWServer child ID for reading '/28.E855E2040000/type' is 2312

VG
Olaf

[justme1968]

laut log schaut es ok aus. er merkt das kein wert kommt und läuft dann weiter. das nachfolgende set wird ja auch wieder augeführt.

kannst du bitte mal ein strace auf den hängenden fhem prozess machen?

gruss
  andre

[ollir]

Hallo Andre,

als Anlage die Ausgabe. Weis nich, was du brauchst. Ich hoffe sie ist nicht zu groß.

VG
Olaf

[justme1968]

nur um sicher zu gehen: owfs ist während des normalen betriebe plötzlich weg oder ist beim starten von fhem schon nicht erreichbar?

für letzteres helfen die paches noch nicht. nur für ausfälle im normalen betrieb.

ich hab aber gerade noch eine idee. es könnte auch ein fall sein der bis jetzt noch nicht abgefangen wird. ich muss mal testen.

gruss
  andre

[ollir]

Hallo Andre,

es passiert, wenn owfs während des Betriebes nicht mehr erreichbar ist.

VG
Olaf

[justme1968]

noch eine bitte: schau mal in 11_OWDevice.pm ob in zeile 484 ein if( !$read_failed ) ist.

wenn ich das strace log richtig interpretiere versucht er bei dir trotz fehlgeschlagenem sensor auslesen noch das alarm dir zu lesen. genau das sollte er aber mit dem patch nicht mehr.

gruss
  andre

[ollir]

Hi Andre,

scheint nicht so zu sein. Hier mal ein Print als Anlage

LG
Olaf

[justme1968]

du hast noch eine falsche version.

wenn du ein update machst sollte die richtige version kommen. Boris hat es gestern noch eingecheckt.

gruss
  andre

[ollir]

Hallo Andre,

das ist merkwürdig. Hatte die Datei von oben genommen und heute morgen ein update 11_OWDevice gemacht.

Jetzt nochmal und die Zeile 484 ist so, wie du sie geändert hast.

Teste jetzt nochmal.


Vielen Dank
Olaf

[ollir]

Hallo Andre,

leider keinen vollen Erfolg.
Zwar hängt FHEM nicht direkt, wenn owfs nicht erreichbar ist
Jedoch hängt FHEM anscheinend, wenn owfs wieder erreichbar ist, bzw.das zweite mal nicht erreichbar ist.

Als Anhang nochmal die Ausgabe von strace

Lieben Dank
Olaf

[justme1968]

ich versuche gerade dein problem  zu reproduzieren und schaffe es nicht.

mein test owserver hat inzwischen 190 reads failed und fhem läuft immer noch.

auch wenn es vielleicht nervt, bitte vergleich noch mal die versionen. du musst jetzt

# $Id: 10_OWServer.pm 4430 2013-12-20 16:42:26Z borisneubert $
# $Id: 11_OWDevice.pm 4444 2013-12-22 21:08:44Z borisneubert $

am laufen haben. am besten gib direkt in fhem mal 'version' ein.

die stelle im neuen log an der er hängen bleibt ist auch wieder die alert stelle an die er gar nicht kommen darf. bzw scheinbar wird die Temperatur noch gelesen und dann hängt er. das wäre genau das zeitfenster das der patch noch nicht abdeckt. war das dein einziger versuch mit dieser version ?

gruss
  andre

[ollir]

Hi Andre,

ich liste dir mal meine Versionen

# $Id: fhem.pl 4386 2013-12-15 17:09:05Z rudolfkoenig $
# $Id: 00_CUL.pm 4232 2013-11-16 14:00:26Z martinp876 $
# $Id: 09_CUL_FHTTK.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 4316 2013-12-03 07:05:50Z martinp876 $
# $Id: 14_CUL_TX.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 57_Calendar.pm 4194 2013-11-09 18:58:18Z borisneubert $
# $Id: 66_ECMD.pm 2356 2012-12-23 09:02:02Z borisneubert $
# $Id: 67_ECMDDevice.pm 3412 2013-07-13 11:21:18Z rudolfkoenig $
# $Id: 72_FB_CALLMONITOR.pm 4318 2013-12-03 17:04:49Z markusbloch $
# $Id: 93_FHEM2FHEM.pm 4020 2013-10-08 10:32:25Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 4292 2013-11-27 20:50:06Z rudolfkoenig $
# $Id: 11_FHT.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 3971 2013-09-29 08:16:39Z ulimaass $
# $Id: 10_FS20.pm 3764 2013-08-22 07:09:38Z rudolfkoenig $
# $Id: 92_FileLog.pm 3759 2013-08-21 08:13:08Z rudolfkoenig $
# $Id: 00_HMLAN.pm 4257 2013-11-21 18:17:30Z martinp876 $
# $Id: 98_PID.pm 3988 2013-11-01 09:20:26Z john $
# $Id: 36_JeeLink.pm 4268 2013-11-22 17:29:18Z justme1968 $
# $Id: 36_LaCrosse.pm 4365 2013-12-12 09:05:37Z justme1968 $
# $Id: 11_OWDevice.pm 4444 2013-12-22 21:08:44Z borisneubert $
# $Id: 10_OWServer.pm 4430 2013-12-20 16:42:26Z borisneubert $
# $Id: 99_RPiUtils.pm $ 05/30/2013
# $Id: 99_SUNRISE_EL.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_SVG.pm 4315 2013-12-02 22:07:27Z rudolfkoenig $
# $Id: 59_Twilight.pm 4302 2013-11-30 19:37:54Z dietmar63 $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 59_Weather.pm 4321 2013-12-03 20:13:08Z borisneubert $
# $Id: 90_at.pm 4246 2013-11-18 20:35:20Z rudolfkoenig $
# $Id: 98_autocreate.pm 4234 2013-11-17 10:19:41Z rudolfkoenig $
# $Id: 98_dummy.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 95_holiday.pm 3602 2013-08-07 13:06:49Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 4317 2013-12-03 09:55:20Z justme1968 $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 91_watchdog.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_weblink.pm 3770 2013-08-23 13:29:58Z rudolfkoenig $

Habe schon einige Versuche gemacht. Werde gleich mal auf beiden RPIs System Updates und über update force alle Versionen neu laden

Vielen Dank für deine Mühe
Olaf

[ollir]

Hallo Andre,

habe alles geupdated. Problem bleibt -konnte es aber weiter einschränken.

Wenn ich den über

service owserser stop

stoppe, dann läuft FHEM weiter.

Wenn ich den Raspi reboote, auf dem der owserver läuft, hängt sich der FHEM auf.

Es scheint mir so, als gäbe es ein Problem wenn die IP-Adresse gar nicht erreichbar ist.

Viele Grüße
Olaf

[justme1968]

ich teste heute abend noch weiter.

den tag über hab ich es mit einem owfs auf einem raspi der über von erreichbar ist versucht. ich kann das von so oft ich will abschalten und wieder einschalten und es geht problemlos.

nachher versuch ich mal kiabel ziehen und neu booten.

ich habe gerade eine ganz andere stelle im verdacht. eventuell bleibt bei dir nicht das owdevice hängen sondern die permanente verbindung die im owserver noch da ist hängt sich auf. das ist eine ganz andere baustelle die bis her noch nicht berücksichtigt wird. auf dem mac auf dem ich bis jetzt getestet habe scheint es auch kein problem zu machen.

eigentlich kann ich die aber auch still legen wenn beim nonblocking lesen ein problem festgestellt wurde und erst wieder verbinden wenn das nonblocking lesen wieder funktioniert. mal sehen ...

gruss
  andre

[ollir]

Hallo Andre,

sehr grossen Dank an Dich. Ich denke es ist erstmal Weihnachten!
Die Tage sollten der Familie gehören.

Nochmals vielen Dank und schöne Tage

Viele Grüsse
Olaf

[justme1968]

weihnachten ist morgen

gruss
  andre

[eppi]

Hallo André
Ich habe mit der neuen Version von OWDevice das Problem, dass bei einem abgezogenen (nicht auf dem Holder liegenden) iButton der state auf "read failed" steht, statt "present: 0".
Danke für deine Unterstützung.
Gruss Dani

[justme1968]

der status 'read failed' wird nur gesetzt wenn vorher ein reading (über polls) gelesen wird das ein undefined zurück gibt.

wie genau ist deine konfiguration des decice? was steht in polls? falls es nur id ist schreib mal bitte gar nichts oder etwas anderes da rein.

gruss
  andre

[eppi]

Hallo Andre
Meine Konfiguration sieht wie folgt aus.
OWServer:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/FHEM/fhem_1wire.cfg
   DEF        192.168.2.5:4304
   NAME       OWFS1
   NR         46
   STATE      Initialized
   TYPE       OWServer
   Readings:
     2013-12-23 19:22:31   /settings/timeout/directory           60
     2013-12-23 19:22:31   /settings/timeout/ftp          900
     2013-12-23 19:22:31   /settings/timeout/ha7           60
     2013-12-23 19:22:31   /settings/timeout/network            1
     2013-12-23 19:22:31   /settings/timeout/presence            3
     2013-12-23 19:22:31   /settings/timeout/serial            5
     2013-12-23 19:22:31   /settings/timeout/server           10
     2013-12-23 19:22:31   /settings/timeout/stable          300
     2013-12-23 19:22:31   /settings/timeout/uncached 0
     2013-12-23 19:22:31   /settings/timeout/usb            5
     2013-12-23 19:22:31   /settings/timeout/volatile           15
     2013-12-23 19:22:31   /settings/timeout/w1           30
     2013-12-23 19:22:31   /settings/units/pressure_scale mbar
     2013-12-23 19:22:31   /settings/units/temperature_scale C
     2013-12-23 19:22:31   state           Initialized
   Fhem:
     protocol   192.168.2.5:4304
Attributes:
   nonblocking 1
OWDevice:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/FHEM/fhem_1wire.cfg
   CHANGED   
   DEF        01.684A8A150000 4
   IODev      OWFS1
   NAME       ibutton_Dani
   NR         60
   NTFY_ORDER 50b-ibutton_Dani
   STATE      read failed
   TYPE       OWDevice
   Readings:
     2013-12-23 18:43:08   id              684A9A150000
     2013-12-23 19:22:13   location        absent
     2013-12-23 19:22:13   present         0
     2013-12-23 19:27:07   state           read failed
   Fhem:
     address    01.684A8A150000
     alerting   0
     bus       
     interfaces id
     interval   4
     rand       0
     getters:
       address
       crc8
       family
       id
       locator
       r_address
       r_id
       r_locator
       type
     polls:
       id
     setters:
     state:
Attributes:
   IODev      OWFS1
   comment    Owner_Dani
   event-on-change-reading present
   model     
   room       Presence

Das Attribut polls ist bei mir nicht gesetzt.
Gruss Dani

[justme1968]

die einzige idee die ich gerade habe ist das der timeout der verwendet wird kürzer ist als die zeit die owfs braucht um nach dem ibutton auf dem bus zu suchen. ich habe auf die schnelle kein dokument gefunden in dem das beschrieben ist. du kannst aber ganz einfach rausfinden ob es daran liegt.

in 10_OWServer.pm in zeile 285:

Code Auswählen Erweitern

my $nfound = select($rout=$rin, undef, $eout=$ein, 4);die 4 mal durch 9 ersetzen. wenn das noch nicht hilft kannst du den wert auch noch größer machen. dann musst du aber auch in Zeile 263:

Code Auswählen Erweitern

InternalTimer(gettimeofday()+10, "OWServer_TimeoutChild", $pid, 0);die 10 durch etwas grösseres ersetzen.

einen anhaltspunkt wie lange es dauert bekommst du wenn du nonblocking abschaltest und für den ibutton ein 'get <ibutton> id'  eingibst.

wenn es daran liegt würde ich vorschlagen den timeout konfiguierbar zu machen. allgemein höher gehen würde ich ungern weil scheinbar ausser dem ibutton alle anderen deivices mit den 4 sekunden reichlich zeit haben.

gruss
  andre

[eppi]

Hallo Andre
Ich habe verschiedene probiert, zuerst

Code Auswählen Erweitern

    my $nfound = select($rout=$rin, undef, $eout=$ein, 9);
    InternalTimer(gettimeofday()+15, "OWServer_TimeoutChild", $pid, 0);


dann:

Code Auswählen Erweitern

    my $nfound = select($rout=$rin, undef, $eout=$ein, 15);
    InternalTimer(gettimeofday()+20, "OWServer_TimeoutChild", $pid, 0);

gebracht hat es nichts - immer noch gleich.....

mit "get Ibutton_Dani id" sehe ich keine Auffälligkeiten, es liefert mir lediglich dir ID des iButton zurück.
Gruss Dani

[justme1968]

kommt die id auch zurück wenn der ibutton nicht angesteckt ist?

geht es wenn nonblocking deaktiviert wird?

was steht dann im status?

und was steht im log (bei verbose 5)?

gruss
  andre

[justme1968]

hast du das 'get <ibutton> id' gemacht wenn der ibutton nicht angesteckt ist? dann kommt trozdem die id zurück?

ich weiss nicht genau wie sich owfs verhält wenn ein nicht angestecker ibutton abgefragt wird. wenn für id ein undefined zurück kommt kann das modul zur zeit nicht unterscheiden ob das lesen fehlgeschlagen ist weil owfs nicht erreichbar ist oder weil der ibutton nicht steckt.

probiere mal die angehängte version. damit wird bei den devices die id unterstützen im 'read failed' fall ein 'present: 0' in state geschrieben. ich vermute das sollte da stehen wenn der ibutton nicht gesteckt ist.

die alternative wäre mit stateFormat das reading present für STATE zu verwenden.

gruss
  andre

[eppi]

probiere mal die angehängte version. damit wird bei den devices die id unterstützen im 'read failed' fall ein 'present: 0' in state geschrieben. ich vermute das sollte da stehen wenn der ibutton nicht gesteckt ist.

Hallo Andre
cool , funktioniert!!! Es wird present 0 geschrieben, wenn der iButton nicht steckt.
Kannst du das so einchecken?

Danke vielmals für deine wertvolle Unterstützung!
Gruss Dani

[eppi]

Hallo Andre
Ich war wohl etwas voreilig... Ich beobachte, dass zwar der State beim Abziehen des iButton auf "present: 0" wechselt, aber das Reading "present" bleibt weiterhin auf "1".
Ich habe einige notifys die das Reading present triggern, die jetzt nicht mehr funktionieren.

Danke und Gruss Dani

[justme1968]

ja. das war erst mal nur der test um zu sehen woran es liegt.

den fix muss ich weiter oben einbauen damit ich für die ibuttons unterscheiden kann ob nichts zurückgekommen ist weil der ibutton nicht da ist oder owfs hängt.

kommt nachher.

gruss
  anfre

[justme1968]

so... ich habe es jetzt so umgestellt das es auch mit den ibuttons wieder funktionieren sollte.

das problem war das das lesen von einem nicht eingesteckten ibutton ebenfalls ein undefined zurück liefert. genau so wie ein nicht erreichbares owfs.

• statt dem internal value READ_FAILED in OWServer gibt es jetzt jeweils in NR_READ_FAILED als zähler und ein LAST_READ_FAILED als flag das das letzte lesen schief gegangen ist.
• NR_READ_FAILED und LAST_READ_FAILED gibt es jetzt jeweils in OWServer und jedem OWDevice
• zusätzlich wird das LAST_READ_FAILED jetzt verwendet um beim ersten fehlgeschlagenen lesen ein disconnect vom owfs zu machen. sobald ein lesen per fork wieder geklappt hat wird wieder ein connect gemacht.

@ollir: mit dem letzen punkt sollte fhem jetzt auch ein reboot des owfs rechners überstehen. ich habe es gerade drei mal mit erfolgreich einem raspberry pi probiert. alle tests vorher waren auf einem mac da geht es seltsamer weise auch ohne diese änderung.

gruss
  andre

[eppi]

Hallo Andre
Vorab wünsche ich dir frohe Weihnachten. Ich habe heute deine neuste Version von OWServer & OWDevice getestet, jedoch reagieren meine iButton gar nicht mehr. Das heisst, es wird nicht erkannt, ob einer steckt oder entfernt wurde. Das Reading state und present bleiben immer gleich > keine Reaktion.
Wie kann ich dir helfen, dem Problem auf die Schliche zu kommen?
Viele Grüsse, Dani

[justme1968]

mein fehler. copy&paste feher von alarm nach id. hab es repariert und die version oben ausgetauscht.

bitte teste es noch mal.

gruss
  andre

[eppi]

Wauuuuu. GANZ GROSSES KINO!!! Funktioniert nun einwandfrei!
Herzlichen Dank!
Gruss Dani

[Dr. Boris Neubert]

Funktioniert nun einwandfrei!

Andre, soll ich die beiden Dateien aus Antwort #51 einchecken?

Grüße
Boris

[justme1968]

von meiner seite aus ja.

taptalk sagt mir es ist #52. aber ich glaube wir meinen den gleichen: http://forum.fhem.de/index.php/topic,16945.msg118253.html#msg118253.

gruss
  andre

[Dr. Boris Neubert]

eingecheckt!
bn

[justme1968]

danke
  andre

[ollir]

Hallo Andre,

OWDevice.pm und OWServer.pm 4458 funktionieren super.
Seit dem disconnect/connect des owfs hat es funktioniert.

Jetzt hängt kein FHEM wenn der owfs nicht mehr über Netzwerk erreichbar ist.

SUPER und vielen Dank.

VG
Olaf

[justme1968]

leider gab bis jetzt doch noch das problem das rereadcfg mit meinen änderungen nicht mehr funktioniert hat.

rudi hat inzwischen aber mit NOTIFYDEV die möglichkeit eingebaut rereadcfg ohne klimmzüge und ohne performance nachteile abzufangen.

die änderungen insgesamt sind:
- NOTIFYDEV verwenden
- NotifyFn vereinfacht
- random start etwas vereinfacht und schon beim ersten auslesen anwenden
- nach autocreate wird automatisch save aufgerufen wenn autosave für autocreate gesetzt ist

@boris: würdest du das bitte anschauen und einchecken

gruss
  andre

[Dr. Boris Neubert]

Herzlichen Dank für Deine Arbeit.

Die beiden Dateien sind eingecheckt.

Viele Grüße
Boris

[fiedel]

Hi Andre,

vielen Dank für die gute Arbeit! Ich hab in den letzten Tagen auch meine Temperatursensor- Kette vom CUNO auf das "richtige" Onewire  umgezogen und freue mich daher besonders, dass das jetzt auch perfekt läuft!

Viele Grüße

Frank

[UweH]

Hallo zusammen,

seit Tagen quält mich FHEM mit folgenden Einträgen im Log:

Code Auswählen Erweitern

Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/share/fhem/FHEM/10_OWServer.pm line 281.
Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/10_OWServer.pm line 262.
Use of uninitialized value $ret in print at /usr/share/fhem/FHEM/10_OWServer.pm line 264.
Use of uninitialized value $ret in chomp at /usr/share/fhem/FHEM/10_OWServer.pm line 281.
.
.
.
usw.
FHEM läuft dabei aber problemlos weiter. Welche Ursache könnte das haben? Ich stelle diese Frage mal hier, weil die angegebenen Zeilen aus dem nonblocking-Bereich des OWServer-Moduls stammen.

[justme1968]

die zeilen haben aber nichts mit dem patch zu tun sondern waren vorher schon genau so da.

aus irgend einem grund liefert OWNet/owfs keinen wert zurück.

gab es irgend ein update? vielleicht von owfs selber ?

gruss
  andre

[fiedel]

Hi Uwe,

suche mal im Forum nach der Meldung! Ich habe letztens ein paar Tipps zur Fehlersuche dazu gegeben. Vielleicht helfen die dir, das Prob. zu lösen.

Gruß

Frank

[UweH]

OK, Danke für die Hinweise. Ich geh dann mal auf Fehlersuche...

[justme1968]

anbei eine erste test version die beim pollen der readings asynchron arbeitet.

die idee ist nach dem forken im parent nicht mehr blockierend zu warten sondern per selectlist asynchron.

um das ganze zu testen muss wie bei nonblocking auch schon für das OWServer device nonblocking gesetzt sein und zusätzlich für jedes OWDevice das asynchron funktionieren soll.

wie bisher ist nonblocking nur für das pollen im betrieb implementiert. die initialisierung beim start von fhem ist auf jeden fall noch blockierend. ein manuelles get ebenso. wobei bei letzterem zumindest der 4 sekunden timeout greift und nicht alles hängen bleibt.

zur zeit ist das erst mal nur für 'normale' device readings implementiert. noch nicht für alarm und id. alarm ist im prinzip kein problem, id ist zur zeit noch eins weil client und server so weit entkoppelt sind das eine leere antwort für ein nicht vorhandenes device noch nicht von einer leeren antwort auf grund eines kommunikationsproblems unterschieden werden kann.

wenn der ansatz sich bewährt sollte nicht für jedes reading ein neuer child prozess gestartet werden sondern ein child sollte die ganze zeit laufen und bidirektional mit dem parent kommunizieren. dazu wäre dann noch ein mechanismus nötig um bei nicht erreichbarkeit von owfs nicht immer mehr readings aufzustauen sondern pro typ und device immer nur eins.

momentan gibt es auch noch einiges mehr an unnötigem overhead da noch nichts weiter optimiert ist. man kann aber deutlich sehen das perfmon nichts mehr meldet auch wenn man alle DS18B20 in höchster auflösung auf uncached laufen lässt.

gruss
  andre

[eldrik]

Hi,

habe die aktuellen Dateien eingespielt und kann keine Perfmon Meldungen mehr feststellen.

Abfrageintervalle 5x DS1820 á 60 Sek., 2x DS2408 á 1 Sek., 3x DS2413 á 60 Sek., 1x DS2450 á 120 Sek.

Edit: Nachtrag bei allen Devices =! DS1820 werden mit nonblocking 1 keine Daten mehr in fhem aktualisiert

Greetz
Eldrik

[justme1968]

fehler gefunden und oben 10_OWServer.pm aktualisiert. (es war der . in den namen der readings)

gruss
  andre

[eldrik]

jetzt werden die readings brav aktualisiert! 

Mir ist aufgefallen, das bei global verbose 3 jede Menge OWDevice parse "readings" Einträge ins Log geschrieben werden, ist dies beabsichtigt?

Ferner beträgt mit den oben aufgeführten Intervallen die CPU Last über top auf meinem raspberry ca 50% für den process Perl und 15% für den process owserver, ist hier noch Optimierungspotential vorhanden? 

Greetz
Eldrik

[justme1968]

die log nachricht hab ich vergessen raus zu nehmen.

bei deinen Intervallen kann es passieren das 4 oder 5 anfragen in eben so vielen prozessen gleichzeitig auf owfs losgelassen werden weil die alte zwangs serialisierung weg ist. das ist an sich noch nicht schlimm so lange das system noch schnell reagiert. das ist ja unser ziel: ein system das noch reagiert auch wenn es ausgelastet ist im gegensatz zu einem system das blockiert weil es auf eine einzige antwort wartet.

die load ist dafür nur bedingt ein guter indikator weil sie 'nur' aussagt wie viele prozesse auf io warten. und genau das wird genutzt. das warten auf mehr als einen prozess zu verteilen damit nicht blockiert wird.

perfmon ist dafür sehr viel besser geeignet. eventuell später auch mit ein intervall das deutlich unter einer sekunde liegt.

ansonsten gibt es noch sehr viel optimierungspotential :

- optimieren der reverse suche mit einem hash

- optimieren des parsens und teilweise verlagern in den geforkten prozess

- nicht für jedes reading neu forken sondern nur pro device oder sogar nur ein mal

- nur ein reading pro device ausstehen lassen

- abfragen unter dem owfs caching intervall sind nur auf uncached sinnvoll und da auch nur auf Intervalle dir größer als dir auslese zeit des sensors sind.

- noch eine ganze reihe mehr

die version oben ist wirklich nur ein aller erster test ob es so geht und ob es vor allem auch mit mehr als meinem 10 sensoren und anderen intervallen geht. wenn das so ist und perfmon sich nicht mehr beschwert dann kann man daran gehen das ganze weiter zu optimieren.

gruss
  andre

[eldrik]

Hey Andre,

jede Verbesserung begrüße ich

Ich bin derzeit noch im Hausumbau, daher könnte ich erst in ein paar Wochen/Monaten weitere Sensoren verteilt auf drei Raspberry 1Wire Netzwerke (UG, EG, OG) testweise zu einem großen 1Wire Netzwerk zusammenfassen, die Erweiterung wäre min. 13x Temp, 3xDS2408, 3x DS2450, 4x DS2413

Wie sieht denn die Möglichkeit aus, 1Wire conditional search zu implementieren?

http://techwww.in.tu-clausthal.de/site/Dokumentation/OneWire/ApplicationNotes/App187_1WSearch.pdf

Gruß
Jens

[justme1968]

ich habe noch nicht rausgefunden ob und wie owfs die conditional search implementiert. es gibt ein paar hinweise in verbindung mit dem alerting/alarm directory aber die doku ist ziemlich dünn.

wenn es auf owfs seite eine schnittstelle gibt kann man das natürlich auch in fhem nachziehen. wenn nicht ist ein fhem modul das dichter an der eigentlichen hardware sitzt vermutlich besser.

gruss
  andre

[eldrik]

Hey,

ja ich habe auch noch nicht "die" Anleitung gefunden, wie conditional search nun funktioniert, in diesem Thread wird das Vorgehen zwar beschrieben, es wird aber nicht explizit darauf eingegangen, ob das setzten über "set_alarm" alleine dafür sorgt, dass owfs bzw. owserver nunmehr den conditional search benutzt.

http://comments.gmane.org/gmane.comp.file-systems.owfs.devel/8422

Vl. kann man auch von anderen Projekten partizipieren?

http://www.openremote.org/display/forums/Extended+OneWire+support

https://github.com/pakerfeldt/jowfsclient/blob/master/src/test/java/org/owfs/jowfsclient/integration/OwfsClientDS2408InputTest.java

Gruß
Jens

[sentinel1]

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]

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]

ok,Danke für die schnelle Antwort

gruss,
Claudiu

[justme1968]

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]

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]

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]

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]

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]

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]

Hi,

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

Greetz
Eldrik

[justme1968]

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]

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]

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 Erweitern

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]

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]

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

[justme1968]

ja. das hatte ich vergessen zu schreiben. fhem.pl muss ausführbar sein.

hattest du im master noch andere/gleiche owserver/owdevice geräte wie in der sandbox?

wenn du testest am besten mit einem leeren fhem bzw. mindestens mit einem bei dem es noch keine anderen owserver/owdevice devices gibt. das problem ist hier das beim autocreate in der sandbox noch nicht geprüft wird ob es einen namenskonflikt mit einem device im master gibt. und dabei kann es dann passieren das im master das 'normale' owdevice läuft und in der sandbox auch noch mal. die beiden lassen sich dann nicht synchronisieren weil beide 'echte' devices sind.

ich hab im anderen thread die files noch mal aktualisiert so das der absturz nicht mehr passieren sollte.

wenn du noch nicht genug hast probiere es bitte noch mal.

gruss
  andre

[eldrik]

so schnell geb ich nicht auf

Also in meiner Master Fhem Instanz habe ich derzeit kein eigene OWServer/OWDevice Definition, diese werden über meine beiden lokalen fhem2fhem Instanzen (1x OG, 1x EG) via clonedummy und readingsproxy reingeholt und sind was den Namen anbelangt unterschiedlich zu den Devicenamen, die in den fhem2fhem Instanzen über das Autocreate angelegt werden.

Die fhem2fhem Instanz fürs EG hatte ich vorher auch für meine Tests und den exklusiven Zugriff auf den owserver Prozess auf dem entfernten raspberry entsprechend heruntergefahren.

Werde in Kürze erneut testen.

Greetz
Eldrik

[eldrik]

so auf ein neues

gleiches vorgehen wie beim ersten Test.

Ergebnis:

unter unsorted sind jetzt die OWServer Instanz sowie einige OWDevices durch das Autocreate angelegt worden, die meisten scheinen auch angelegt worden zu sein, werden mir jedoch nur über den Umweg über meine clonedummy Einträge angezeigt, sie tauchen danach im jeweiligen clonedummy unter "Probably associated with" auf jedoch nicht im Raum unsorted.

Mindestens zwei owdevices fehlen (DS2450, DS18B20) in Gänze.

Nun zum kuriosen, in der Hoffnung, die fehlenden Devices über ein reopen des OWServers zu erhalten, hatte ich danach nur noch "get" für die OWServer Instanz zur Verfügung und bei einem späteren Sprung in die OWServer Instanz war das "set" zwar wieder da, jedoch enthielt dieses nur noch 3 - 5 Optionen und einige davon waren Namenseinträge (soweit ich es gesehen habe auch keins der ursprünglich über set aufrufbaren Optionen) von OWDevice Geräten beim "get" waren die OWServer Einträge sowie das "reopen" vorhanden, das "devices" jedoch nicht als ob hier munter getauscht wurde 

Aktuell hängt die fhem Instanz wieder nachdem man bis zu 10 Minuten noch flüssig damit arbeiten konnte.

Ja ich habe weiterhin mit einer "vollen" fhem.cfg getestet 

Greetz
Eldrik

[justme1968]

warum es die probleme im fhemweb gibt weiss ich jetzt. da kommt eine antwort aus der sandbox aus dem tritt. da muss ich noch etwas am protokoll ändern damit das nicht passiert.

und ich muss einbauen das optional die get und set ? gecached werden. zur zeit werden die bei jedem seiten aufbau neu gesendet. das ist meist gar nicht nötig und wenn die sandboden so autonom wie möglich arbeiten sollen auch gar nicht sinnvoll.

kommt beides noch.


die fehlenden devices kann ich nicht reproduzieren. ich habe den verdacht das bei dir noch irgendetwas anderes in der installation dazwischen funkt.

aber das schaue ich mir auch mal an.

vielleicht kannst du mal mit einer 'nagten' fhem konfiguration nur das OWServer device in der sandbox anlegen und schauen ob es dann besser läuft.

bei mir läuft es stundenlang mit etwa 10 devices problemlos. aber nur mit wenig web und ganz ohne set.

gruss
  andre