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:
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.
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
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
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 (http://www.fhemwiki.de/wiki/HBW-1W-T10)
Gruß,
Thorsten
Hi,
Thorsten, das ist ein ziemlich cooler Ansatz, werde ich mir mal anschauen. Das mit den 750 ms ist wie folgt:
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 (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
...auch ein "geplantes" Delay von 200ms finde ich schon zu viel.
Gruß,
Thorsten
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
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
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.
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
Ich würde es gerne sobald es lauffähig ist, testen ;-)
Danke!
Grüße
Stephan
Will das Thema nochmal aufgreifen, da ich keine Lösung gefunden habe.
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
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:
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
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.
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