Hallo Zusammen,
nach ein paar Performanceproblemen mit 1-Wire und dem COC habe ich das gewechselt und mittlerweile läuft ein 1-Wire Adapter USB DS9490RAdapter auf dem Raspi2 mit OWServer.
Mit 5 DS18B20 und 2 DS2401 und unterschiedlich hohen Abfrageraten, teilweise auch sekündlich.
Die Temperatursensoren haben zusätzlich +5V
Aber der Effekt ist der gleiche wie damals.
2015.04.13 12:49:01 1: Perfmon: possible freeze starting at 12:49:00, delay is 1.171
2015.04.13 12:49:10 1: Perfmon: possible freeze starting at 12:49:09, delay is 1.007
2015.04.13 12:49:23 1: Perfmon: possible freeze starting at 12:49:22, delay is 1.024
2015.04.13 12:49:25 1: Perfmon: possible freeze starting at 12:49:24, delay is 1.776
2015.04.13 12:49:28 1: Perfmon: possible freeze starting at 12:49:27, delay is 1.013
2015.04.13 12:49:58 1: Perfmon: possible freeze starting at 12:49:57, delay is 1.011
2015.04.13 12:50:31 1: Perfmon: possible freeze starting at 12:50:30, delay is 1.015
2015.04.13 12:50:33 1: Perfmon: possible freeze starting at 12:50:32, delay is 1.068
2015.04.13 12:51:04 1: Perfmon: possible freeze starting at 12:51:03, delay is 1.616
Bei Verbose 5 sieht man das es meistens/immer an den 1-Wire Sensoren liegt.
Auch wenn ich alle Intervalle auf 60 oder weniger Sekunden stelle, der Freeze ist dann auch da, ausserdem benötige ich schon für die Reedkontakte(Tür/Fensterüberwachung) kurze Intervalle.
Zusätzlich sind ein paar Notify / Watchdog und Dummyeintragungen darüber initialisiert, aber nichts wildes.
Kann mir jemand einen Tipp geben? Läuft bei anderen soetwas ähnliches ohne Probleme?
MfG
Hi,
du könntest mit der folgenden Version arbeiten:
http://forum.fhem.de/index.php/topic,16945.msg161805.html#msg161805
Diese Version läuft bei mir produktiv u.a. für die Abfrage von Fenster, Türkontakten, Bewegungsmeldern usw. mittels DS2408 im Sekundentakt, ist jedoch mit dem Nachteil behaftet, dass sie sich über die Laufzeit unmengen von Memory einverleibt ohne diesen wieder freizugeben, weshalb ich alle zwei Tage die jeweilige Fhem Instanz automatisch neu starten lasse, um den Speicher wieder freizugeben.
Freezes von ca. 1 Sek. treten, bei dreien meiner vier 1Wire Installationen, damit nur noch alle 5 - 30 Minuten auf, bei meinem 1Wire Bus, für den Aussenbereich, der annährend deine Größe aufweist (4x DS18B20, 1x DS2450, 1x DS2408, 1x DS2423) kommt es z.B. zu überhaupt keinen Verzögerungen!
Mein Aufbau und die angeschlossenen Busteilnehmer scheinen jedoch auch etwas umfangreicher zu sein.
Ich betreibe eine Fhem Primary Instanz (Homematic, Intertechno und sonstige Helper Module), in einer Debian7 VM (esxi 6 auf mac mini Server), damit die von dir aufgezeichneten Fhem freezes, unter anderem das Homematic Timing nicht durcheinander bringen betreibe ich von dieser Primären Instanz entkoppelt, in einer zweiten Debian7 VM, vier per fhem2fhem erreichbare Fhem 1Wire Instanzen (Keller, Erdgeschoss, Obergeschoss, Aussenbereich), welche sich wiederum ihre 1Wire Busdaten per OWServer von einem ihnen zugeordneten Raspberry, mit Busadapter, holen.
Bei dir würde wahrscheinlich schon eine zweite Fhem Instanz auf deinem Pi reichen, welche die Daten per fhem2fhem an die Module clonedummy/readingsproxy (mehr zu diesen Modulen in der Fhem Commandref) überträgt.
Evtl. auch die asyncrone Version der OWX Module, zu diesen bin ich jedoch nicht auskunfsfähig.
Greetz
Eldrik
Danke schonmal, ich werde mich mal umfänglich damit beschäftigen.
Auf einem frischen Raspi1als Testsystem bekomme ich die selben Freeze laufend, also muss ich optimieren...
Ein erster Test der verlinkten Versionen scheint etwas zu helfen, allerdings bekomme ich im Logfile:
2015.04.13 14:18:11 1: PERL WARNING: Use of uninitialized value $ret in print at ./FHEM/10_OWServer.pm line 308.
2015.04.13 14:18:11 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at ./FHEM/10_OWServer.pm line 303.
2015.04.13 14:18:11 1: PERL WARNING: Use of uninitialized value $ret in print at ./FHEM/10_OWServer.pm line 308.
Eine Idee?
Edit: Hat sich erledigt erstmal. Sind die zwar definierten aber nicht vorhandenen DS2401
Zusatzfrage: Bei Verbose 3 zeigt er nun laufend
2015.04.13 16:12:05 3: OWDevice_Parse temperature 51.125
Kann ich dies unterdrücken?
beides sind kleine Randerscheinungen, die der Funktion keinen Abbruch tun, die "parse" Meldungen kannst du nur unterdrücken wenn du die owserver oder owdevice.pm anpasst, in der die log 3 Zeile eingefügt aber vom nonblocking Bearbeiter justme1968 nicht auf log 5 zurückgeschraubt wurde.
Die "ret" Meldungen sind zu vernachlässigen, aber auch diese lassen sich beenden, wenn man die entsprechenden Zeilen in der owserver.pm abändert, im fhem svn findet man die notwendigen Änderungen.
http://sourceforge.net/p/fhem/code/7213/
Greetz
Eldrik
Danke Eldrik.
Habe es soweit am Laufen, aber:
DS2401 kann ich nicht auf nonblocking1 stellen, sobald das attr. gesetzt ist, wird absent oder present dort nicht abgefragt/aktualisiert.
Allerdings zeigt er bei Anwesenheit die ID, auch als Event im Eventmonitor, wenn sie nicht vorhanden sind (Reedkontakt offen) fehlt die ID, damit könnte ich zur Not auch per Notify/Watchdog eine simple Abfrage machen. Dafür müllt mir bei fehlender ID das Logfile zu mit sekündlichen zu:
2015.04.13 20:33:24 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at ./FHEM/10_OWServer.pm line 306
Die DS18B20 funktionieren ganz gut so.
Sind die 2401 nicht unterstüzt?
die von dir geschilderte Unstimmigkeit mit dem ds2401 ist mir nur im Zusammenhang mit dem ds2450 bekannt, scheinbar gibt es hiermit aber auch ein Problem :/ justme1968 hatte leider nicht mehr an der nonblocking Variante weitergearbeitet, da meine ds2450 nur in 90 - 300 Sek. Intervallen abgefragt werden, fallen diese nicht ins Gewicht.
Greetz
Eldrik
Das ist fast entmutigend....
Die Version läuft sonst gut, aber ich benötige halt die Abfrage der DS2401 und hatte gehofft die Perfmon Probleme damit zu erledingen.
Was mich wundert: 1-Wire wird doch häufiger bei Fhme genutzt, sonst treten diese Probleme nicht auf? Oder liegt es an einer bestimmten Konstellation?
Der 1-Wire-Bus ist nun einmal nicht für eine Abfrage mehrerer Busteilnehmer im Sekundentakt gedacht. Das kann man sich ganz einfach an Hand des Adressierungsprotokolls ausrechnen.
LG
pah
pah trifft den Nagel auf den Kopf!
Trotz der Einschränkung lassen sich mit ihm jedoch kostengünstig entsprechende Szenarien realisieren.
Hier Mal der Auszug meines Logfiles für den Bus im Erdgeschoss, hier werden derzeit vier ds2408 im Sekundentakt abgefragt, desweiteren sind 8x DS18B20, 4x DS2423 und 3x DS2450 vorhanden:
2015.04.14 06:02:12.189 1: Perfmon: possible freeze starting at 06:02:11, delay is 1.189
2015.04.14 06:08:13.189 1: Perfmon: possible freeze starting at 06:08:12, delay is 1.189
2015.04.14 06:33:44.202 1: Perfmon: possible freeze starting at 06:33:43, delay is 1.202
2015.04.14 06:41:04.042 1: Perfmon: possible freeze starting at 06:41:03, delay is 1.042
2015.04.14 06:51:45.301 1: Perfmon: possible freeze starting at 06:51:44, delay is 1.301
2015.04.14 06:51:45.301 1: Perfmon: possible freeze starting at 06:51:44, delay is 1.301
2015.04.14 07:36:10.319 1: Perfmon: possible freeze starting at 07:36:09, delay is 1.319
Ich benutze den 1Wire Bus für die Erfassung und Visualisierung der Zustände von Fenstern, Türen, Toren, Briefkasten, Regensensor, Türklingel, Wassermeldern, Rauchmeldern, Bewegungsmeldern (in jedem Raum u.A. für gedimmtes Durchgangslicht bei Dämmerung oder Nacht), Luftfeuchte, Bodenfeuchte, Luftqualität, Temperatur, Helligkeits- und Sonnenstärke, schalten von Relais, LEDs und MP3 Soundmodulen sowie zur Erfassung der Verbrauchsdaten von Gas und Stromzählern und zur Füllstandsmessung meiner unterirdischen Regenwassertanks.
Als Abfallprodukt ist mittlerweile auch eine funktionstüchtige Alarmanlage entstanden und denjenigen möchte ich erst einmal sehen, der es schafft, in dem freeze von einer Sekunde das Fenster oder die Tür aufzubrechen, den Bewegungsmeldern aus dem Weg zu gehen, um bis zur zentralen Notstromversorgung vorzudringen, bevor es draußen und drinnen ordentlich auf die Ohren gibt ;D
Von daher nicht entmutigen lassen!
Greetz
Eldrik
Den Sekundentakt sehe ich aber hier nicht.
ich habe mit einem Arduino ein 1-Wire-Mikronetz realisiert, das meinen iButton reader alle 250 ms abfragt. Aber auch nur solange sich kein Teilnehmer auf dem Bu sbefindet...
LG
pah
Ich denke eldrik meint mit Sekundentakt die Abfragung der Sensoren, welches ich auch für 1 Tor und 2 Türen realisieren wollte.
Wenn man nicht die modifizierte OWServer Version nutzt, gibt es zu fast jeder Abfrage auch einen Freeze. Mit der non-blocking Variante und dem Testeinsatz von 5 DS18B20 (Intervall 1;1;1;2;5;10 Sek) und 2 DS2401 (jeweils sekündlich) bin ich bei 1 Freeze alle 5 Min.
Was ich nicht verstehe, auch wenn ich nur alle 3 Min jeweils Abfragen würde, bekomme ich die Freeze von 1 Sekunde. Die ganzen Nutzer von 1-Wire und einenm USB-Adapter/COC was auch immer haben nicht das Problem? Oder mache ich ein Problem wo keines ist?
Testweise habe ich das ganze nochmals über den COC und i2c laufen lassen, auch dort konnte ich die Freeze signifikant verringern, aber nicht so gut wie mit dem USB-Adapter.
Über COC ist allerdings die CPU Auslastung 20%Punkte höher.
Frage:
Würde es etwas nützen NICHT über OWServer (OWFS) sondern über OWX/OWX_Asynchron das zu realisieren?
LG
Joe
Zitat von: RitterSport am 14 April 2015, 12:22:30
Ich denke eldrik meint mit Sekundentakt die Abfragung der Sensoren, welches ich auch für 1 Tor und 2 Türen realisieren wollte.
Exakt, ich wollte hiermit nur auf die signifikant verringerten freezes hinweisen.
Also die freezes sind "normal" da fhem die Abfragen seriell ausführt und insofern das Modul kein nonblocking anbietet, sprich in einen weiteren Kindprozess auslagert, der Hauptprozess solange belegt wird bis die Aktion abgearbeitet wurde!
Bei mir rühren die verbliebenen "sichtbaren" freezes, im Log, mit großer Wahrscheinlichkeit von den DS2450 her, da diese bei aktivierten nonblocking leider keine Werte, mit dem nonblocking OWDevice Modul zurückliefern.
Zu den OWX Modulen kann ich nichts sinnvolles beisteuern, einfach Mal ausprobieren ;)
Greetz
Eldrik
Ich betreibe an ein und demselben Cubieboard 2 6 1-Wire Busse: 4x über USB, 1x über Ethernet und einer über WLAN. Mit Abfrageintervallen von 1 Minute bis zu 5 Minuten. Und es macht mir nichts aus, dass manchmal FHEM für eine Sekunde beschäftigt ist - das System ist stabil wie eine Eins. Und zwar mit OWX und meine sensorabhängigen Modulen - und ohne die asynchrone Erweiterung.
Dazu noch Mengen an HomeMatic, FS20, EBUS etc., eine Ankopplung an meine Fotovoltaikanlage und weitere Spielzeuge.
Warum bitte sollte das nicht performant genug sein ?
LG
pah
Zitat pah: Warum bitte sollte das nicht performant genug sein ?
Genau das ist meine Frage, ab wann sind Freeze schädlich für das System.
In meinen ertsen Versuch über i2c und dem COC konnte ich definitiv feststellen das während der Freeze ankommende Funksignale entweder nicht empfangen wurden oder nicht verarbeitet wurden. Somit wurde das System unproduktiv.
Freeze in der jetztigen Situation bedeutete das der Hauptprozesse steht? Aber Anstehend Eingaben/Abarbeitungen/Funkempfang nur hinten anstehen? Dann muss ich nur meinen Anspruch keine Freeze haben zu wollen,runterschrauben.
@eldrik
Ich frage DS2401 sekündlich ab, da sie anscheinen nicht implementiert sind lieferne sie keinen present/absent sondern nur die ID.
Sobald sie nicht am Wire hängen, da Reed offen kommen die Fehlermeldungen in den Logfile.
Ist das bei den 2405 auch so?
Zitat von: RitterSport am 15 April 2015, 09:13:03
Zitat pah: Warum bitte sollte das nicht performant genug sein ?
Genau das ist meine Frage, ab wann sind Freeze schädlich für das System.
In meinen ertsen Versuch über i2c und dem COC konnte ich definitiv feststellen das während der Freeze ankommende Funksignale entweder nicht empfangen wurden oder nicht verarbeitet wurden. Somit wurde das System unproduktiv.
Schädlich für das System wird es zum einen, wenn du für dich selber feststellst, dass das WebGui sich nur noch hakelig bedienen lässt und wenn du z.B. Produkte einsetzt, die auf ein bestimmtes Timing angewiesen sind, z.B. der Homematic LAN Adapter mag es garnicht, wenn man ihn nicht alle x Sek. betüdelt bzw. seine Anfragen direkt beantwortet!
Zitat von: RitterSport am 15 April 2015, 09:13:03
Freeze in der jetztigen Situation bedeutete das der Hauptprozesse steht? Aber Anstehend Eingaben/Abarbeitungen/Funkempfang nur hinten anstehen? Dann muss ich nur meinen Anspruch keine Freeze haben zu wollen,runterschrauben.
Aktionen von Fhem werden angereiht, Events, welche an Fhem gesendet werden, gehen unter und können nur bearbeitet werden, wenn das sendende Gerät z.B. ein Homematic Aktor selbständig erkennt, dass seine Nachricht nicht erfolgreich empfangen wurde und diese daraufhin erneut sendet, aber auch hier gibt es ein Limit von möglichen Wiederholungen.
Zitat von: RitterSport am 15 April 2015, 09:13:03
@eldrik
Ich frage DS2401 sekündlich ab, da sie anscheinen nicht implementiert sind lieferne sie keinen present/absent sondern nur die ID.
Sobald sie nicht am Wire hängen, da Reed offen kommen die Fehlermeldungen in den Logfile.
Ist das bei den 2405 auch so?
Beim DS2450 handelt es sich, um einen 4 Fach Spannungsmesser, welchen man z.B. für die Messung der Lufteuchte, Luftqualität etc. verwenden kann, dieser liefert mit der nonblocking Variante keine Spannungswerte mehr zurück, der Abfrageintervall liegt bei mir aber ausschließlich bei 300 Sek. bzw. 90 Sek. für meine Wassermelder, daher unkritisch.
Hast du dir schon einmal die 1Wire Schaltplatinen aus dem Wiki angeschaut? Diese laufen mit einem DS2408 und stellen 8 Abfrage- bzw. Schaltkontakte zur Verfügung.
Greetz
Eldrik