Hallo "Heimautomatisierer",
ich habe vor 4 Wochen damit angefangen mein Haus mit Homematic Komponenten aufzurüsten und das ganze wird über FHEM (gehostet auf Raspberry PI mit COC Modul von Busware) angesteuert.
Alle nicht zeitkritischen Anwendungsfälle (Heizungssteuerung, Steuerung der Lüftungs- / Wärmerückgewinnungsanlage, Außenbeleuchtung) funktionieren zu meiner Zufriedenheit.
Nun kommt es aber leider bei einigen Notify-Schaltvorgängen des Öfteren zu Verzögerung von teilweise bis zu 2-4 Minuten. Mir ist klar, dass ein "zeitnahes" schalten von Aktoren nur über ein Peering der involvierten Komponenten gewährleistet werden kann, aber einige meiner Schaltlogiken benötigen halt simple IF-Abfragen und ich verlange auch keine Schaltzeiten in Millisekundenbereich.
Gestern Abend wollte ich zum Beispiel über ein Short-Press Notify eines HM-PB-2-WM55 (Funk-Wandtaster 2-fach) alle Lichter (gruppiert und geschaltet über eine Structur) im Haus ausschalten. Nach dem kurzen Drücken des richtigen Tasters passierte mal wieder nichts.
Auch ein weiterer Versuch über den Taster zu schalten brachte kein Erfolg. Ich wartet 2 Minuten und habe mich dann aus dem Bett "gequält", um unter höhnischen Blicken meiner Frau die Lichter im Haus einzeln und manuell auszuschalten. Auf dem Weg und mitten auf der Treppe zum Erdgeschoss dachte FHEM / Homematic dann wohl, dass es der richtige Zeitpunkt sei das vor 3 Minuten abgesetzte Kommando auszuführen. Das hätte ins Auge gehen können, aber wenigstes konnte ich in der Dunkelheit nicht mehr das Grinsen meiner Frau sehen :P
Aber auch weniger "komplexe" Schaltvorgänge wie zum Beispiel das Schalten der Außenfluter im Garten durch ein Notify vom HM-Sen-MDIR-O HomeMatic Funk-Bewegungsmelder werden teilweise mit einer so langen Verzögerung ausgeführt. Gefühlt würde ich sagen, dass bei meiner Installation einer von 10-15 Schaltvorgangen extrem verzögert abläuft.
Auf dem Raspberry läuft nur FHEM und außer bei der Erstellung von Plots und bei Seitenabrufen über die Web-UI langweilt sich die "Kiste" eigentlich den ganzen Tag.
Woher können also solche großen Verzögerungen beim Schalten der Homematic Komponenten kommen? Wie und wo sollte ich die Fehlersuche starten?
Vielen Dank für eure Hilfe und Grüße aus dem Norden,
Daniel
Hallo,
habe das selbe problem (mit HomeEasy bzw IT komponenten).
bsp. Bewegungsmelder im FLur ... bis da endlich der Schaltvorgang ausgelöst wird bin ich scho im schlafzimmer... Verzögerung zwischen 2 (Ist ok) bis 20 Sekunden (nicht akzeptabel)
Gesteuert über RFXTrx ...
Also falls jemand ne idee hat (für das ansich gleiche Problem) bitte melden..
Hi,
ich hab auch immer wieder delays - abllerdings eher im Bereich bis 20 Sekunden.
Habe logs im Verdacht - achte mal drauf, ob sich diese delays gegen Monatsende zunehmen (wenn die ganzen monatlichen logfiles eine teilwesie ansehnliche Größe erlangen).
Ist aber nur eine Idee, habs noch nicht verifiziert.
Letztendlich passieren ja:
- Senden Sensor -> HM-LAN (oder CUL)
- Übertragung HM-LAN an fhem
- event-Erzeugung in fhem
- Event-Prüfung in fhem (prüfen und Ausführen aller filelogs und notifies)
- Senden fhem -> HM-LAN
- senden HM-LAN -> Aktor
Es koennte also theoretisch auch liegen an
- Verarbeitungsverzögerung HM-LAN (disconnect/reappear)
- Übertragungsverzögerung HM-LAN (disconnect/reappear)
- Performance des Rechners, auf dem fhem läuft
- Sende-Wiederholungen HM-LAN -> Aktor (missing ack)
Ich nehme an, Du hast alle relevanten logfiles auf Auffälligkeiten geprüft?
Ich hab bei mir mal zB beobachtet: Sensor betätigt, bis Schalten des Aktors vergingen zB 10 Sekunden. Zeitstempel in den logfiles des Sesnors und Aktors geprüft - Zeitdifferenz unter 1 Sekunde. Das hilft dann zur Fehlereingrenzung leider nicht weiter. Vll laesst sich in Deinem Fall ja was eingrenzen.
=8-)
Hallo,
habe dasselbe Problem mit meiner FHEM-Installation auf einer FritzBox (einschließlich der höhnischen Blicke der Gattin). Bei mir kommt es auch zu Verzögerungen von bis zu 2 Minuten.
Hatte auch schon die Logs im Verdacht und die Anzahl der Logfiles stark reduziert - leider bislang ohne Erfolg. Die Idee, das Verhalten am Monatsende und -Anfang genauer zu beobachten, finde ich ganz gut. Im Moment (Monatsende) beobachte ich häufig große Verzögerungen. Mal sehen, wie es ab morgen (neuer Monat) aussieht.
Gruß,
thumu
An der Länge der Logfiles liegt es nicht, denn das habe ich schon ausprobiert.
In den Log-Files sind auch keine Auffälligkeiten zu finden und an der Kommunikation zwischen HM-FHEM-HM liegt es wohl auch nicht, da ich das Ganze auch bei Philips HUE Lampen beobachten kann. Also bei der FHEM-HUE Kommunikation und die findet ja über die HUE-Bridge / Zigbee statt.
Ich habe echt keine Idee wie ich der Sache auf den Grund gehen kann ...
Ich habe jetzt erst mal SysStat installiert und schau, ob da Auffälligkeiten beim der Systemload vom Raspberry PI auftreten – ab und zu hängt die WebUI auch mal für 30 Sekunden.
Danke und Gruß,
Daniel
Zitat von: mcbird am 31 Oktober 2013, 16:31:52An der Länge der Logfiles liegt es nicht, denn das habe ich schon ausprobiert.
Ich habe seit Ende letzten Jahres bis vor 1 Monat ein BeagleBoard-xM (etwas bessere Leistungsdaten als ein RPi) als Fhem-Server im Einsatz gehabt. Speicherung aller Daten erfolgte auf der SDHC-Karte, auf der auch das OpenSuse-ARM-OS lag. Meine Logs werden in Monatsdateien abgespeichert. Auf dem BBxM lief nur Fhem.
Die letzten Monate lief auch SysStat mit und gegen Ende jeden Monats bewegte sich die Systemlast sehr häufig im Bereich 0.6 bis > 1. Nach dem Monatswechsel sank dieser Wert auf 0.2 bis 0.4, bei Spitzenwerten von 0.8. Gegen Ende eines Monats "fühlte" sich die Web-Oberfläche auch *deutlich* zäher an.
Letzten Monat bin ich wegen eines Crashs der SDHC-Karte auf einen Mini-ITX mit Dual-Core-Celeron (TDP 17 W) mit 2,5"-S-ATA-HDD, 80 GByte gewechselt und seitdem bin ich all diese Probleme los (siehe Anhang).
Meine Erfahrungen sind also etwas andere.
Gruß
Thomas
Edit: Für die, die es interessiert habe ich im Anhang noch die SysStat-Log-Datei meines BBxM von August 2013 angehängt.
sysstat zu verwenden kann nur einen anhaltspunkt geben und es ist wichtig zu wissen das die load alleine nicht ausreicht um eine aussage zu machen woran es liegt bzw. nicht liegt. es ist wichtig zu wissen das die load nur etwas über die cpu auslastung sagt. ohne das in beziehung zu anderen möglichen engpässen wie z.b. netzwerk und vor allem platten io zu setzen.
d.h. es ist nicht zu unterscheiden ob einfach nur die cpu ausgelastet ist oder die cpu däumchen dreht und die platte/sd karte zu langsam ist und alles weitere blockiert. umgekehrt muss eine load von 10 auch noch nicht bedeuten das ein system nicht mehr ansprechbar wäre.
unter linux bietet sich für eine manuelle kontrolle top an. hier vorallem die %cpu zeile wo ein hoher waiting anteil auf einen i/o engpass hin deutet. ich muss mal schauen ob ich diese werte auch im sysstat modul verfügbar machenkann.
gruss
andre
Hi,
ich verallgemeinere jetzt mal etwas ;)
Beim Aufsetzen meines Mini-ITX-Systems habe ich auch daran gedacht, statt der S-ATA-Platte eine SSD einzusetzen. Davon habe ich aber ganz schnell Abstand genommen, als ich mich mit der Materie etwas näher befasst habe. SSDs sollten nach überwiegender Meinung (so auch ausführlichere Artikel in der c't) *nicht* z.B. für die Ablage des Linux-Verzeichnisses /var/log genommen werden, da auf SSDs vorteilhafterweise nur statische Dateien, also vor allem die Binärdateien des Betriebssystems und der Programme abgelegt werden sollten. Selbst für diese wird unter anderem empfohlen, in der /etc/fstab für die zu mountenden Partitionen der SSD zumindest das Attribut "noatime" zu setzen, weil sonst bereits bei jedem auch nur lesenden Zugriff auf Dateien auch ein Schreibzugriff für die Speicherung des letzten Zugriffszeitpunktes auf diese Datei erfolgt.
Und was das Erweitern einer bereits bestehenden Datei auf einer SSD und (jetzt meine Verallgemeinerung) SD(HC)-Karte bedeutet (grob: Schreiben der kompletten neuen vergrößerten Datei an einen neuen Ort, danach Löschen der bisherigen kleineren Datei) sollte jeder für sich bewerten und dabei auch berücksichtigen, wie die Lebensdauer der Speicherzellen (Anzahl der Überschreibvorgänge) auf diesen Medien zu sehen ist.
Die Dateien unter /var/log/ sind gleichbedeutend mit den Log-Dateien von Fhem. Also sind mM SSDs/SD(HC)-Karten dafür nicht der ideale Speicherort.
SD(HC)-Karten dürften also sowohl für die Lifetime des Systems als auch die Performance zumindest suboptimal sein. Letztlich sind das aber Entscheidungen, die jeder für sich trifft.
Und was ich durch den Crash meiner SDHC-Karte im BBxM schmerzlich erfahren habe: Wenn eine "normale" Festplatte crasht, kann ich meist noch mit Boardmitteln auf die einzelnen Sektoren zugreifen um irgendetwas zu restaurieren (gibt natürlich auch hier Totalausfälle). SD(HC)-Karten heißt meistens: Datei korrupt => nix mehr zu retten (auch nicht teilweise).
Und bitte nicht missverstehen: Das soll kein Plädoyer gegen Fhem-Installationen auf Fritzboxen oder RPis usw. sein!
Und ja, ich kenne (n)top, aber für eine systematische Vorgehensweise fehlt(e) mir einfach die Zeit.
Gruß
Thomas
P.S. Danke Andre, dass du dein Modul entsprechend zu erweitern suchst. Mit der Zeit wird man dem Grund bzw. den Gründen etwas näher kommen.
ich hab hier http://forum.fhem.de/index.php/topic,10573.msg103740.html#msg103740 (http://forum.fhem.de/index.php/topic,10573.msg103740.html#msg103740) in die aktuelle test version mal eingebaut das man bei linux systemem den user,system,idle und iowait anteil an der systemlast überwachen kann.
ob das bei den relativ grossen intervallen (mindestens 60 sekunden) die mit dem modul erlaubt sind sinnvoll funktioniert kann ich noch nicht sagen.
vielleicht mag es ja mal jemand probieren :)
gruss
andre
ps: diese version kann auch targets per snmp überwachen. ist also nicht mehr auf linux beschränkt. die lastverteilung aber erst mal schon.
Hallo zusammen,
da habe ich auch entsprechende Erfahrungen gemacht.
Früher hatte ich FHEM auf eine FB 7170 laufen. Weil diese auch so träge war, bin ich auf RaspBerry Pi umgestiegen. Oft gibt es sehr kurze Reaktionszeiten - Logfile angekickt und schups wird es angezeigt. Manchmal dauert es teilweise bis zu 1 min, bis es eine Reaktion gibt. Ich denke nicht, dass es mit der Länge von Logdateien zu tun hat, da die Reaktionszeiten sich innerhalb von Minuten ändern kann. Außerdem treten die Probleme auch heute, am Monats- und Wochenanfang auf. Bei mir gibt es bis auf fhem.cfg und fhem.save nur Wochenlogs.
Ich habe mir mittels Top die Belastung der CPU, Speicher usw. mal angesehen. Wenn diese langen Reaktionszeiten zu beobachten sind, ist die Auslastung der CPU durch FHEM bei 98/99 %. Alle anderen angezeigten Parameter (Speicherverbrauch usw.) ändern sich nur unwesentlich. Deshalb vermute ich, dass irgendwas in FHEM (Module?) die CPU so stark in Anspruch nimmt.
Kennt jemand eine Möglichkeit, FHEM in seiner Tätigkeit zu beobachten, um herauszufinden, was (evtl. Modul?) starke CPU-Belastung bewirkt und somit diese Verzögerungen verursacht?
Viele Grüße
Harald
moin,
ich habe habe heute mal während eines Hängers einen strace auf fhem angesetzt. Wie früher schon mal von Rudolf vermutet, hängt er im select(). Ich hatte aber noch keine Zeit, mir im code anzuschauen, was er da macht.
oh und bei mir war keine erhöhte CPU-Belastung zu sehen (auf einem alix 1d3), einfach ein blockierter select()
-Christian
die hänger die scheinbar etwas mit longpoll und select zu tun haben schlagen sich nicht in erhöhter cpu auslastung nieder. ein hängen im select verbraucht keine cpu.
es gibt noch diverse andere gründe für hänger wie z.b. nicht erreichbarer 1-wire server, eins der wetter module die daten per blockierendem http oder ftp laden. die sollten sich alle nicht in der cpu auslastung bemerkbar machen weil es sozusagen passives warten ist.
performance probleme wegen cpu auslastung oder durch io auf platten oder sd karten sollte man von den anderen hängern unterscheiden können weil die load nach oben geht. bei ersterem der user anteil bei letzterem system und/oder iowait.
gruss
andre
Moin Leute,
ich habe am Wochenende folgende Beobachtung machen können ...
Ich löste auf meiner Terrasse den HM-Sen-MDIR-O Bewegungsmelder aus und dabei sollte ein HM-LC-Sw1-FM das Terrassenlicht über ein Notify für 5 Minuten einschalten. Es passierte mal wieder gar nichts. Direkt 3 Minuten nach dem Auslösen saß ich am Notebook und rief die FHEM WebUI auf – genau in diesem Moment (also beim Aufruf der WebUI) schaltete der HM-LC-Sw1-FM das Außenlicht auf der Terrasse ein.
Im Log des HM-Sen-MDIR-O steht dann auch ein Motion-Eintrag mit dem Zeitpunkt des WebUI-Refreshs (also 3 Minuten später als eigentlich vom BWM erfasst).
Ich hatte 2 weitere Fehlschaltungen am Wochenende "provozieren" können und beide konnte ich mit einem Refresh der vorzeitig WebUI "auflösen".
Das sieht mir stark nach einem Bug in FHEM aus – hat da vielleicht jemand einen Ansatz für die Fehlersuche?
Danke und Gruß,
Daniel
Das könnte auch das schon ältere Longpoll-Problem sein (siehe u.a. hier (http://forum.fhem.de/index.php/topic,14893.0.html))
Probier einfach mal Longpoll komplett zu deaktivieren (in WEB, WEBPHONE, WEBTABLET, usw.). Vielleicht wird es dadurch besser... Muss natürlich nicht, wäre aber vielleicht einen Versuch wert.
LG
Jan
Hallo,
möglicherweise hat meine folgende Erfahrung wenig mit diesem Problem hier zu tun. Aber wer weiß.
Vor ein paar Wochen bin ich auf ein Wandboard/QUAD mit Fedora 19 umgezogen. OS und fhem mit logs und fhemdb auf einer partition. Die performance der GUI war grauenhaft, auch traten extrem viel disconnects mit HMLAN und CUNO auf. Im internet fand ich, dass der IO-Prozess ( mm...irgendetwas) zu einem bottleneck werden kann.
Ich hab nun zwei zusätzliche partitions eingerichtet - auf der einen befindet sich fhem mit logs auf der anderen fhemdb. Jetzt sind sowohl die performance als auch die diconnect Probleme weg.
Wie gesagt, vielleicht hilft diese Erfahrung.
Ciao walter
Hallo,
hier auch einen Hinweis von meiner Seite, bei dem ich auch nicht weiss ob er etwas mit der grundsätzlichen Problematik zu tun hat.
Ich initiiere vom Raspi einen Telefonanruf über die Fitzbox mit dem Aufruf {FBCallr(1,'0123456789',30,'192.168.0.1','Password')}") per remote Telnet. Der Anruf wird auch wie gewünscht eingeleitet und nach 30 Sekunden abgeschlossen. Nach diesem Aufruf steht fhem für die im Aufruf angegebene Zeit von 30 Sekunden komplett. Erst nach 30 Sekunden funktioniert wieder alles wie es soll.
Gruß Horst
****** Aktualisierung **********
Der vom mir geschilderte Fall hat doch nicht mit dem eigentlichen Problem zu tun. Die Perl Routine FBCallr beinhaltet einen Sleep als Perl Aufruf, die dieses Verhalten hervorruft.
Gruß Horst
Hallo zusammen,
ich hatte soeben wieder sehr lange Reaktionszeiten beim Bedienen von FHEM in der WEB-Oberflächen. Top zeigte mir eine sehr hohe CPU-Auslastung an. Mehr als 10 min war die Last bi ~98 %. Nachdem ich longpollSVG auf 0 gesetzt hatte, war die Belasung weiter so hoch. Auch ein Stopfhem und Neustart änderte nichts. Erst als ich longpoll auf 0 gesetzt hatte, war die extrem lange, hohe Last weg und die Reaktionszeiten wieder im Normalbereich.
Ich habe in der Vergangenheit schon ähnliche Beobachtungen gemacht, aber bisher noch nie so genau nachgeforscht.
Für mich jedenfalls sieht es so aus, als wenn longpoll einen Einfluss auf dieses Fehlverhalten hat.
Viele Grüße
Harald
Hallo zusammen,
Rudolf hat hier (http://forum.fhem.de/index.php/topic,14893.msg106077.html#msg106077) eine Änderung durchgeführt. Nach einem Update heute Morgen lässt sich fhem zügig und ohne fhem-Gedenkminuten bedienen. Bei Anwahl von Logfile, Edit fhem.cfg usw. hat man in kurzer Zeit das Ergebnis auf dem Bildschirm.
Besten Dank Rodolf für die tolle Arbeit und viele Grüße
Harald