Erhöhung der Zuverlässigkeit

[MiWe58]

Hallo,

Nach ca. 6 Wochen intensiver Beschäftigung mit dem FHEM / Homematic System möchte ich einige meiner Beobachtungen zur Zuverlässigkeit des Systems schildern.

Meine typischen "Anfängererfahrungen" lasse ich hier bewusst weg. Die bisherige Lernkurve war steil und ist noch nicht am Abflachen. Um es vorweg zu nehmen: Weiterhin bin ich sicher, mit der Plattform des fhem-Servers die einzig richtige Entscheidung getroffen zu haben.

Nun aber zum eigentlichen Punkt:
Ich stelle fest, dass die Ausführung von Schaltbefehlen nicht immer zuverlässig ist. Das äußert sich in der Form, dass angelegte "structures" von Aktoren (hier meist Rolladen) entweder nicht vollständig (Alle Aktoren) oder auch gelegentlich eine structure gar nicht ausgeführt wird. Angestoßen werden die Schaltvorgänge durch eine Zeitsteuerung.

Um das Phänomen in das richtige Licht zu rücken, muss ich betonen, dass dieses nicht die Regel ist, aber eben gelegentlich vorkommt, was ich gar nicht schön finde 

Zunächst habe ich es mir damit erklärt, dass zu viele Rollos zum selben Zeitpunkt angesteuert werden und somit zu viel Funkverkehr auf einmal ausgelöst wird. Dann habe ich die einzelnen "structures" zeitversetzt angesteuert.

Dann habe ich es mir damit erklärt, dass die Funkreichweite zwischen Sender/Empfänger und Aktor kritisch ist. Das scheint jedoch nicht der Fall zu sein, da ich je Stockwerk in meinem Haus einen CUL bzw. einen HMLAN Adapter einsetze. Die protokollierten RSSI's aller Aktoren liegen im Bereich zwischen -45 und -68.

Weiterhin ist es denkbar, dass gelegentliche Einflüsse den Funkverkehr stören. Diese Fehlerquelle sollte aber, so mein Verständnis, durch ein bi-direktionales Funkprotokoll, wie von Homematic, abgefangen werden. Bei fehlender Rückmeldung sollte der Steuerbefehl eben nochmals gesendet werden.


Ein zweites, möglicherweise ähnlich gelagertes Phänomen wird durch die Beobachtung auffällig, dass die verschiedenen Schaltstati der Aktoren nicht immer aktuell und damit richtig im Web-Frontend angezeigt werden. Gelegentlich sind 2-3 manuelle "Refreshs" der Seite erforderlich, bis alle Aktoren richtig angezeigt werden.

Selbstverständlich habe ich über "getConfig" geprüft, ob alle Aktoren auch tatsächlich gepaired sind.
Gibt es im Forum ähnliche Erfahrungen bzw. Tipps zur Erhöhung der Zuverlässigkeit?


Zum Hintergrund:
Fhem läuft auf der Fritz-Box 7390
Es sind mittlerweile ca. 30 Aktoren verbaut

[det.]

Hallo MiWe58,
will mal versuchen etwas launig zu antworten... Nach weiteren 6 - 12 Monaten Beschäftigung mit FHEM wirst Du herausfinden, dass es neben der Fritzbox (mit der ich auch angefangen habe und die heute noch das Callmonitor Modul zu meinem gesamt FHEM Konzept beisteuert) noch einige andere leistungsfähigere Serverplattformen mit ähnlich geringem Stromverbrauch gibt. Es macht mMn durchaus Sinn, in der Einrichtungs- und Lernphase 2-3 FHEM Server per fhem2fhem zu koppeln bzw. einfach die zu schaltenden Sachen darauf aufzuteilen. Dann bekommst Du ein Gefühl für die Response Zeiten der einzelnen Aktoren / Module und kannst probieren, ohne Dir das Produktivsystem öfter zu zerschießen. Meine FB 7390 vergaß da früher schon mal gelegentlich Ihre Hauptaufgabe (VDSL Connect) - auch bei so etwa 30 Aktoren / Sensoren und langsam wurde sie auch im Web Interface. Das fühlte sich an wie Reiten auf einem toten Pferd....
Also Kopf hoch und weiter machen - das wird am Ende richtig gut!

[Puschel74]

Hallo,

naja, wie det. schon geschrieben hat (und betateilchen gerne erwähnt  )

Die FritzBox kann FHEM und DSL und Netzwerk und Telefon und W-LAN (je nach FB) und ... und ... und ... (je nach Freetz) aber ---
die FB ist eben "nur" mal ein Router.
Und das sollte sie auch bleiben, finde ich.
Die Rechenleistung (so man das so sagen kann) ist eben bescheiden wenn viele Anwendungen diese abrufen.

Ich hatte FHEM auch erst auf meiner 7390 und habe mir nach dem Umzug auf den RasPi nur gedacht - mann ist das genial.
Die FB soll sich um das Internet und um die Telefonie kümmern (und das kann sie gut finde ich) aber Hausautomation bekommt bei mir einen eigenen Server - eben den RasPi.

2, 3, 5 oder vielleicht auch 10 Aktoren mag die FB noch "vertragen" aber so wie beim Auto auch.
Willst du mehr als nur nen Kleiderschrank transportieren nimm einen Lieferwagen und keinen kleinen Skoda (nix gegen Skoda aber mir ist grad nix anderes eingefallen).

Grüße

[Dietmar63]

ich habe nur eine 7270.

Von Überlastung kann man bei meiner Box nicht mehr sprechen: Sie dreht den ganzen Tag Däumchen:
Ich protokolliere den ganzen Tag per top die Auslastung. Die Idletime liegt paraktisch immer über 90%.
Wenn mal jemand telefoniert oder surft, wird ein wenig mehr Rechenlast erzeugt.

Wenn bei dir mal nicht richtig geschaltet wird, liegt es bestimmt an Fehlern in der Software oder an der Funkverbindung.

Richtig Funklast erzeugen viele FHT, schon allein wg. des 1kb langsamen Protokolls. Ich hatte anfangs bedingt durch Fehlprogrammierung auch oft LOV.
Bei HM sollte das Problem erst bei höherer Anzahl an Geräten auftreten, weil mit 20kb gesendet wird.

Das einzige große Problem, das ich lange Zeit untersucht habe, bestand darin, dass irgendwelche Prozesse auf der Box sich langsam in der Rechenlast hochgeschaukelt haben, so dass die Box fast unter Vollast lief. Das Problem wurde in letzter Zeit schlimmer, als ich dann auch noch das neueste Firwarerelease(xx.53) eingespielt habe. Die Probleme waren dann so schlimm, dass ein Telefonieren  bzw. Surfen nicht mehr möglich war. Der Spuk war immer vorbei, nachdem ich fhem neu gestartet hatte. Ursache weiterhin unbekannt. Tipps hier im Forum: Fehlanzeige.

Jetzt bin ich dazu übergegangen, den Prozess ctlmgr zu killen. In irgendwelchen Foren habe ich dazu gelesen, dass dieser Prozess sowieso nicht lebensnotwenig sei. Dann ist zwar kein Zugriff auf die Standardoberfläche der box moglich, aber die Box hat jetzt Rechenleistung ohne Ende - vielleicht ist es Problem des Speichers. Ich weiß es immer nicht.

Der Prozess kann bei mir einfach per kleine fhem-Erweiterung an- und abgeschaltet werden. Wenn ich also in der FB etwas einschalten will, muss ich kurz in fhem anschalten. Wann benötigt man die Oberfläche schon?

Code Auswählen Erweitern

2013-11-20_12:24:46 ges 98 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  1 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_12:41:17 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  1 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_12:57:48 ges 97 --> voipd  0 smb  0 idle 93 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_13:14:19 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_13:30:50 ges 98 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_13:47:21 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_14:03:52 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_14:20:23 ges 86 --> voipd  0 smb  0 idle 82 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_14:36:54 ges 86 --> voipd  0 smb  0 idle 83 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_14:53:25 ges 88 --> voipd  0 smb  0 idle 84 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_15:09:56 ges 87 --> voipd  0 smb  0 idle 83 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_15:26:28 ges 95 --> voipd  0 smb  0 idle 92 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_15:42:58 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_15:59:29 ges 97 --> voipd  0 smb  0 idle 93 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  3 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_16:16:00 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_16:32:31 ges 97 --> voipd  0 smb  0 idle 93 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_16:49:02 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_17:05:33 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_17:22:04 ges 98 --> voipd  0 smb  0 idle 91 upnpd  0 dsld  0 perl  3 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_17:38:35 ges 96 --> voipd  0 smb  0 idle 92 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_17:55:06 ges 87 --> voipd  0 smb  0 idle 83 upnpd  0 dsld  1 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_18:11:38 ges 92 --> voipd  0 smb  0 idle 90 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  1 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_18:28:09 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_18:44:40 ges 98 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_19:01:11 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_19:17:42 ges 94 --> voipd  0 smb  0 idle 86 upnpd  0 dsld  0 perl  5 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_19:34:13 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_19:50:44 ges 97 --> voipd  0 smb  0 idle 92 upnpd  0 dsld  0 perl  1 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_20:07:15 ges 97 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  1 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_20:23:47 ges 98 --> voipd  0 smb  0 idle 94 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0
2013-11-20_20:40:18 ges 98 --> voipd  0 smb  0 idle 95 upnpd  0 dsld  0 perl  0 telefon  0 zip  0 top  2 ctlmgr  0 luacgi  0 nmbd  0


Code Auswählen Erweitern


sub ctlmgr($){
   my ($event) = @_;

   my $res = `ps | grep ctlmgr\$`;
   if ($res) {
     my $res1 = `killall ctlmgr`;
     $event .= " killed";
   } else {
     my $res1 = `ctlmgr`;
     $event .= " started";
   }
   return $event;
};


Code Auswählen Erweitern

2013.11.20 21:19:57 3: [Befehl] Befehl ctl killed done
2013.11.20 21:19:47 3: [Befehl] Befehl ctl started done


[Gerhard]

Hallo Dietmar,

ich habe sub ctlmgr($) in 99_myUtils.pm copiert, und aus fhem.cfg über ein notify aufgerufen.
alerdings funktioniert die Umschaltung nicht.
rufe ich killall ctlmgr & ctlmgr über telnet auf, dann funktioniert es korrekt.
wie muß der Aufruf von sub ctlmgr(?) in fhem.cfg aussehen?

Danke, Gerhard