tmr-OWDevice_UpdateValues apptime Delay

abc2006 · 06 April 2016, 13:19:21

Hallo,
ich habe Probleme mit Delay der HMW-Komponenten in meinem System: link
Dazu wollte ich fragen, ob die von Apptime angezeigten Delay-Zeiten normal sind:

Code Auswählen

 tmr-OWDevice_UpdateValues      HASH(0x356ffc8)   2930      4     7736  1934.00      1 HASH(DS18B20_TEST) 
           tmr-OWDevice_UpdateValues      HASH(0x3606878)    823      4     3007   751.75   1976 HASH(DS18B20_Ruecklauf_WT_EG) 
           tmr-OWDevice_UpdateValues      HASH(0x3519c90)    811      4     2990   747.50   2504 HASH(DS18B20_Mischer_oben) 
           tmr-OWDevice_UpdateValues      HASH(0x35924c8)    811      4     3026   756.50   2232 HASH(DS18B20_Ruecklauf_Zirkulation) 
           tmr-OWDevice_UpdateValues      HASH(0x355d2e8)    795      4     2971   742.75   2467 HASH(DS18B20_Schlafzimmer) 
           tmr-OWDevice_UpdateValues      HASH(0x3592558)    795      3     2249   749.67      1 HASH(DS18B20_Ruecklauf_HKGarage) 
           tmr-OWDevice_UpdateValues      HASH(0x35933c0)    795      4     2970   742.50   2667 HASH(DS18B20_Mischer_mitte) 
           tmr-OWDevice_UpdateValues      HASH(0x3607b78)    795      4     2975   743.75      1 HASH(DS18B20_WW_Ausgang_Speicher) 
           tmr-OWDevice_UpdateValues      HASH(0x3608118)    795      4     2991   747.75   2704 HASH(DS18B20_Vorlauf_EG_Boden) 
           tmr-OWDevice_UpdateValues      HASH(0x3592be0)    794      7     5183   740.43   1946 HASH(DS18B20_VorlaufHK) 
           tmr-OWDevice_UpdateValues      HASH(0x3519c18)    793      4     2993   748.25   2447 HASH(DS18B20_Mischer_unten) 
           tmr-OWDevice_UpdateValues      HASH(0x355d9d8)    793      4     2972   743.00   1674 HASH(DS18B20_RuecklaufHK) 
           tmr-OWDevice_UpdateValues      HASH(0x3592078)    793      4     2970   742.50      1 HASH(DS18B20_FlurOG) 
           tmr-OWDevice_UpdateValues      HASH(0x3593168)    793      4     3036   759.00   2401 HASH(DS18B20_Speicher_mitte) 
           tmr-OWDevice_UpdateValues      HASH(0x36013e0)    793      4     2970   742.50   2938 HASH(DS18B20_Ruecklauf_EG_Boden) 
           tmr-OWDevice_UpdateValues      HASH(0x2873660)    792      4     2988   747.00   2195 HASH(DS18B20_Vorlauf_WW) 
           tmr-OWDevice_UpdateValues      HASH(0x3676f48)    792      4     2968   742.00   2406 HASH(DS18B20_Ankleide) 
           tmr-OWDevice_UpdateValues      HASH(0x3592bf8)    791      2     1519   759.50      0 HASH(DS18B20_Speicher_oben)

Vergleichswerte von eurer Installation würden mich interessieren (einfach im Abstand von 60 sekunden zweimal "apptime" eingeben. Danke für eure Hilfe!
Stephan

PS: was ich vllt erwähnen sollte, ich habe "attr myowserver nonblocking 1" gesetzt.

Thorsten Pferdekaemper · 06 April 2016, 19:39:42

Hi,
etwas mehr als 700ms sieht irgendwie verdächtig nach einer blockierenden DS18B20-Abfrage aus. Ich kenne das owserver-Modul nicht, aber die 700ms kommen mir bekannt vor.
Gruß,
Thorsten

justme1968 · 06 April 2016, 20:17:29

das nonblocking attribut bezieht sich darauf das FHEM nicht komplett blockiert falls der owserver nicht antwortet.

es bedeutet nicht das das modul asynchron arbeitet.

die 700ms sind in etwas das was (je nach auflösung) für eine synchrone temperatur abfrage gebraucht wird. es gibt im forum diverse ansätze wie man FHEM davon entlasten kann. such mal danach. von fhem2fhem über das erzwungene füllen des owfs cache bis hin zu einer experimentellen OWServer version und den neuen versionen der 1wire module von pah.

gruss
andre

Thorsten Pferdekaemper · 06 April 2016, 20:28:56

Zitat von: justme1968 am 06 April 2016, 20:17:29es gibt im forum diverse ansätze wie man FHEM davon entlasten kann.

...oder auch das hier, wenn man etwas basteln kann/will und sowieso HM-Wired hat:
http://www.fhemwiki.de/wiki/HBW-1W-T10
Gruß,
Thorsten

abc2006 · 06 April 2016, 21:53:02

Hi,
Thorsten, das ist ein ziemlich cooler Ansatz, werde ich mir mal anschauen. Das mit den 750 ms ist wie folgt:

Code Auswählen

Die Konvertierung eines 12-bit Temperaturwertes benötigt etwa 750ms. Die Zeit halbiert sich mit jedem weiteren Bit weniger und beträgt bei 9-bit nur noch 93,75ms.

siehe z.B. https://wiki.arduino-hannover.de/index.php/DS1820_Temperatursensor_1-Wire
Bei 10 Bit (mit denen ich arbeite) dürfte die Abfrage somit nur noch weniger als 200 ms betragen. Also wird entweder das 10 Bit nicht richtig weitergegeben (oder ist das gar kein Parameter, der bis zum Bus kommt? ) oder es liegt woanders dran.

Whatever, ich schaue mir mal oben den HBW an

cool!

Danke
Stephan

Thorsten Pferdekaemper · 06 April 2016, 22:27:41

...auch ein "geplantes" Delay von 200ms finde ich schon zu viel.
Gruß,
Thorsten

abc2006 · 07 April 2016, 15:02:23

Aber irgendwie muss ichs doch noch mal aufgreifen: kann mir mal jemand, der OWServer benutzt, die Zeiten zeigen, die er fürs tmr-OWDevice_UpdateValues braucht? Eigentlich würde ich vom OWServer erwarten, dass dieser die Werte asynchron holt, cached und auf Nachfrage mit minimalem Delay ausliefert ...
PS: neuer spitzenreiter:
tmr-OWDevice_UpdateValues HASH(0x5d448b8) 4490 47 96099 2044.66 6238 HASH(DS18B20_TEST)

Grüße
Stephan

justme1968 · 07 April 2016, 15:33:56

wie oben geschrieben: OWServer arbeitet nicht asynchron. das cachen passiert auf owfs/owserver seite.

die neue version der module von pha können asynchron arbeiten.

gruss
andre

LuckyDay · 07 April 2016, 18:14:12

Code Auswählen

 tmr-OWDevice_UpdateValues      HASH(0x11681f0)    335      5     1589   317.80    720 HASH(a_DS18B20_BD2AE3040000)

mit resolution 9

soweit ich weiß kommen die maxDly zeiten hier z.B. 720 ms davon, das der timerAufruf selber schon 720 ms warten muß

die eigentliche wandlungszeit hier 335 ms.

Prof. Dr. Peter Henning · 07 April 2016, 22:17:52

Das Backend mit asynchronen Fähigkeiten gibt es aber erst nur als alpha-Version. Dauert noch ein paar Tage, weil ich wieder einmal alle Hände voll zu tun habe.

LG

pah

abc2006 · 08 April 2016, 16:17:26

Ich würde es gerne sobald es lauffähig ist, testen

Danke!

Grüße
Stephan

farion · 14 Januar 2017, 22:10:05

Will das Thema nochmal aufgreifen, da ich keine Lösung gefunden habe.

Code Auswählen


           tmr-OWDevice_UpdateValues      HASH(0x425c668)   5606      1     5606  5606.00   3781 HASH(HWR.SpeicherLadePumpeTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x425c188)   5102      1     5102  5102.00    179 HASH(HWR.RuecklaufHK2Temp) 
           tmr-OWDevice_UpdateValues      HASH(0x4272788)   4041      1     4041  4041.00    611 HASH(HWR.VorlaufHK2Temp) 
           tmr-OWDevice_UpdateValues      HASH(0x425b7a8)   4036      1     4036  4036.00     35 HASH(HWR.RuecklaufWeiche) 
           tmr-OWDevice_UpdateValues      HASH(0x4266568)   1291      1     1291  1291.00   6747 HASH(HWR.RuecklaufSpeicherObenTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x4272aa0)   1275      1     1275  1275.00   7443 HASH(HWR.WarmWasserTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x41e0090)   1262      1     1262  1262.00    905 HASH(HWR.RuecklaufHK1Temp) 
           tmr-OWDevice_UpdateValues      HASH(0x425ace0)   1256      1     1256  1256.00   7323 HASH(HWR.RuecklaufKessel) 
           tmr-OWDevice_UpdateValues      HASH(0x4265b78)   1250      1     1250  1250.00   6923 HASH(HWR.SolarVorlaufTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x4272680)   1245      1     1245  1245.00   7678 HASH(HWR.ZirkulationTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x4272188)   1243      1     1243  1243.00   4460 HASH(HWR.KaltwasserTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x41e0ae0)   1225      1     1225  1225.00   7218 HASH(HWR.SolarRuecklaufTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x4266070)   1208      1     1208  1208.00   3310 HASH(HWR.FWSSpeicherEinspeisungTemp) 
           tmr-OWDevice_UpdateValues      HASH(0x425bca8)   1195      1     1195  1195.00   7087 HASH(HWR.VorlaufHK1Temp) 
           tmr-OWDevice_UpdateValues      HASH(0x41d4bf8)    548      1      548   548.00   1880 HASH(HWR.OWBusTemp)

Ich habe 14 DS18B20 an einem DS2405 per USB . Mein System wird dadurch deutlich ausgebremst. nonblocking=1 habe ich gesetzt. Auf die Schnelle habe ich es nicht hinbekommen OWDevice_UpdateValues async zu machen. Gibt es da schon eine Lösung, die ich übersehe?

Gruss Frieder

eldrik · 16 Januar 2017, 08:43:16

Hi,

kurzfristige und erfolgversprechendste Lösung, auf dem gleichen Server, eine weitere FHEM Instanz aufsetzen, diese lediglich mit den 1Wire Aufgaben betreuen und die Daten per fhem2fhem an die Hauptinstanz übertragen.

Betreibe mit dieser Variante per owserver an einem raspberry zwei USB und ein i2c 1Wire Interfaces (drei eigene Busleitungen, KG, EG und OG) mit insgesamt 52 ds18b20, 6x ds2423, 1x ds2450, 2x ds2406 ohne das die zu erwartenden Delays einen Impact auf die Hauptinstanz ausüben.

In der Vergangenheit habe ich auch mit dem im Thread weiter oben erwähnten experimentellen Modul ca. 10x DS2408 im Sekundentakt zur Abfrage von Reed Kontakten und sonstigen Kontaktinterfaces genutzt, da dieses Modul jedoch nach einiger Laufzeit zu Memoryproblemen führte, frühstücke ich die ds2408 sowie die Spannungsabfrage (Luftfeuchtesensoren) ds2450 (waren auch mal insgesamt 8 Stück im Bus) nun über dedizierte Arduinos mit Eternetinterface und MQTT Anbindung ab.

Delay Auszug der 1W Fhem Instanz:

Code Auswählen

2017.01.16 08:32:23.605 1: Perfmon: possible freeze starting at 08:32:22, delay is 1.605
2017.01.16 08:32:25.375 1: Perfmon: possible freeze starting at 08:32:24, delay is 1.375
2017.01.16 08:32:28.472 1: Perfmon: possible freeze starting at 08:32:27, delay is 1.472
2017.01.16 08:32:32.370 1: Perfmon: possible freeze starting at 08:32:31, delay is 1.37
2017.01.16 08:32:38.787 1: Perfmon: possible freeze starting at 08:32:37, delay is 1.787
2017.01.16 08:32:42.734 1: Perfmon: possible freeze starting at 08:32:40, delay is 2.734
2017.01.16 08:32:46.370 1: Perfmon: possible freeze starting at 08:32:45, delay is 1.37
2017.01.16 08:33:01.394 1: Perfmon: possible freeze starting at 08:32:47, delay is 14.394
2017.01.16 08:33:15.370 1: Perfmon: possible freeze starting at 08:33:02, delay is 13.37
2017.01.16 08:33:17.007 1: Perfmon: possible freeze starting at 08:33:16, delay is 1.007
2017.01.16 08:33:35.509 1: Perfmon: possible freeze starting at 08:33:34, delay is 1.509
2017.01.16 08:33:38.726 1: Perfmon: possible freeze starting at 08:33:36, delay is 2.726

Greetz
Eldrik

farion · 17 Januar 2017, 18:35:21

Hi,

okay ... dann muss ich mich doch endlich mal mit fhem2fhem beschäftigen. Brauche das in Zukunft sowieso für einige andere Dinge.

Gruss farion

Edit: Okay, hat geklappt. Mit ner zweiten FHEM-Instanz klappt es und die Hauptinstanz blockiert nicht. Wie startest du das? FHEM-Ordner kopiert und das init.d-Script angepasst?

Jetzt habe ich nur festgestellt, dass zwei meiner Sensoren nix mehr liefern ... komisch am 14. gingen sie noch ... und ich habe nichts an der Hardware geändert ...

Edit2: Mhh irgendwie war mein ganzes 1-Wire-Interface nicht mehr da. Die Werte kamen aus dem fhem.save. 2x den Raspi neugestartet und jetzt sind alle Werte wieder da. Yiphiee.

eldrik · 18 Januar 2017, 07:58:02

Zitat von: farion am 17 Januar 2017, 18:35:21

Edit: Okay, hat geklappt. Mit ner zweiten FHEM-Instanz klappt es und die Hauptinstanz blockiert nicht. Wie startest du das? FHEM-Ordner kopiert und das init.d-Script angepasst?

Ja genau so habe ich bisher FHEM Instanzen, auf einem Host dupliziert.

Da ich aber meine Installationen virtuell auf einem esxi Cluster betreibe befindet sich die 1W Instanz alleine in einer eigenen VM.

Greetz
Eldrik