Hallo,
ich habe fhem auf einem Raspberry B+ am laufen; (raspbian und fhem-Paket). Das funktioniert grundsätzlich auch super, die Last des Systems ist überschaubar und testweise eingerichtete Wecker (Lichtwecker) funktionieren problemlos. Das Webinterface läuft mir allerdings ständig in einen Timeout und funktioniert meist erst beim 2., 3. oder 5. mal...
Momentan hängt nur ein Philips Hue-System dran; CUR und Jeebase-Sticks sind bestellt.
Frage: Ist das ein generelles Problem auf einem schwachbrüstigem System wie einem Raspi? Aktuell ist meiner noch per WLAN angebunden, nach der endgültigen Platzierung wartet ein LAN-Kabel und ich brauche das WLAN-Modul nicht mehr. Verspricht das Abhilfe? Oder sollte ich mir doch etwas leistungsfähigeres suchen als einen Raspi?
Vielen Dank
Zitat von: marc-willmann am 05 Januar 2015, 14:39:45
Frage: Ist das ein generelles Problem auf einem schwachbrüstigem System wie einem Raspi?
nö, ich tippe eher darauf, dass irgendein Prozess Dein fhem blockiert und es deshalb zu den timeouts kommt.
Zitat von: marc-willmann am 05 Januar 2015, 14:39:45
Frage: Ist das ein generelles Problem auf einem schwachbrüstigem System wie einem Raspi? Aktuell ist meiner noch per WLAN angebunden, nach der endgültigen Platzierung wartet ein LAN-Kabel und ich brauche das WLAN-Modul nicht mehr. Verspricht das Abhilfe? Oder sollte ich mir doch etwas leistungsfähigeres suchen als einen Raspi?
Ich hab auch RPi mit Wlan im Einsatz. Hab etliche Funksteckdosen, HomeMatic Heizthermostate und Wettersensoren damit angebunden. Timeout hab ich nie, nicht mal wenn ich remote aus dem Internet drauf geh. Nur bei manchen Plots (Grafiken) gönnt sich der kleine ein paar Sekunden Pause.
Du sagst CPU hält sich in Grenzen ... wie hoch ist das Grundrauschen (CPU im Idle) und wie hoch wird die CPU wenn du das Frontend aufrufen willst? Und welche Prozesse sind die "großen"? Kannst auf der Konsore per "top" kommand prüfen. Mit "c" sortiert es nach CPU. Bei mir ist Leerlauf so 2-5% und wenn ich am Frontend rummach dann bei 20% solgane keine Plots zu berechnen sind.
Hast du mal versucht ob du das Problem nur mit dem normalen Frontend hast das auf Port 8083 läuft, oder auch auf den anderen 8084, 8085. Teste auch mal mit einer App.
Hi,
vielen Dank für die Antworten. Zu den Fragen:
In der Tat gibt es Unterschiede auf den unterschiedlichen Ports; am ehesten läuft's noch auf 8083; per Smartphone und Tablet ist's schlechter - wobei das aber natürlich die "spannenderen" Oberflächen sind. Im Endausbaustand möchte ich eigentlich mit 1-2 Infodisplays und dem Tablet arbeiten.
CPU-"Grundrauschen":
Load Average: 0,05
CPU: 0,3 user space; 1% system auch bei kurzzeitigen "Spitzen" (wenn man's denn so nennen mag) > 97% idle
Unter "Last" (Zugriff auf Web-Interface von einem(!) Client):
Port 8083, sehr schnell (während des Tests): CPU ca. 5% User Space
Port 8084, Geschwindigkeit okay (während des Tests) ca. 10% User Space
Port 8085, Geschwindigkeit okay (während des Tests) ca. 10% User Space
Ich habe für den Test den Raspi vorher einmal durchgestartet. Auch mit viel Klicken habe ich den Load nicht über 0,15 bekommen. :-) Natürlich - Vorführeffekt - hab ich jetzt aber auch nicht die Verzögerungen. Ich lass das Ding wieder etwas laufen und wiederhole die Tests, wenn ich wieder langsame Rückmeldungen erhalte. Vielleicht haben sich auf dem Board auch nur ein paar Bits verlaufen... ;-)
Am komsumtivsten war übrigens der Perl-Prozess, allerdings während des Tests in völlig akzeptablem Rahmen.
Viele Grüße
Marc
AHHH, es wird hell.
Ich hatte eben wieder das Problem, dass der Raspi schlecht bis gar nicht reagiert hat. Die Last des Systems war weiterhin niedrig; ich glaube aber, die Ursache gefunden zu haben: Die WLAN-Karte hat in den Energiesparmodus geschaltet.
Ich habe selbigen abgeschaltet ("options 8192cu rtw_power_mgnt=0 rtw_enusbss=0" in /etc/modprobe.d/8192cu.conf) und hoffe, dass das Problem damit behoben ist. Vielen Dank an alle!
Marc