Hallo zusammen, ich habe mein FHEM System schon seit mehreren Jahren.
Jetzt bin ich mal richtig an eine Grenze gestoßen und brauche eure Hilfe.
Dies ist mein erster Eintrag hier im Forum und ich hoffe, ich habe das Thema richtig platziert.
Was habe ich gemach:
Ich habe einen Nano Clone (CH340) per USB an meinem PI 1.
Der Nano sendet per serieller Schnittstelle die Daten per KeyValueProtocol.
Wenn ich es am PC in der Arduino IDE teste, kommen die einzelnen Daten sauber an.
Bei einem virtuellen FHEM auf dem PC funktioniert auch alles prima.
Neue Geräte werden automatisch angelegt und die Werte dargestellt.
Nun zu meinem Problem:
Auf meinem PI 1 kann ich nach mehr oder weniger kurzer Zeit die Weboberfläche nicht mehr aufrufen, wenn die ersten Daten vom Nano gesendet werden!
Der PI selbst ist über SSH und eine andere Web Oberfläche (PIHole) weiterhin erreichbar und läuft.
Nur das FHEM Web :8083 ist nicht mehr verfügbar.
Nach einem Neustart ohne den Nano sind jedoch die geschriebenen Werte des Nanos in den logs.
Somit funktioniert auch ein Teil von FHEM noch!
Folgendes habe ich schon probiert:
- neuer Nano → gleiches Problem
- anderer PI 1 mit neu installiertem FHEM → gleiches Problem
- andere Serielle Geschwindigkeit → gleiches Problem
- Zeit zwischen dem Senden der einzelnen Daten verlängert und verkürzt → gleiches Problem
Hat jemand eine Idee??
Auszug aus dem seriellen Monitor am PC:
OK VALUES VW_ARDUINO 0011 state=0.00
OK VALUES VW_ARDUINO 0012 state=0.00
OK VALUES VW_ARDUINO 0013 state=255.00
OK VALUES VW_ARDUINO 0014 state=12.43
OK VALUES VW_ARDUINO 0010 state=1.00
FHEM:
define ARDUINOserial JeeLink /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
setuuid ARDUINOserial 5c47408f-f33f-ec69-cd6a-53721ed31f97d667
attr ARDUINOserial flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr ARDUINOserial group Arduino_serial
attr ARDUINOserial room System
attr ARDUINOserial verbose 5
Willkommen im Forum!
Tummelt sich da sonst noch was an USB?
Es läuft noch ein nano CUL mit FTDI. Problemlos!
Ich hatte in der Vergangenheit auch schon den Nano mit ECDM am laufen. Bestimmt 2 Jahre. Das hat dann auf einmal nicht mehr funktioniert. Dann wollte ich auf KVP. Das lief dann auch einige Zeit. Jetzt hängt sich das WEB nach den ersten gesendeten Daten auf.
An meinem Test PI war der Nano und ein USB Wlan Adapter. Der funktioniert auch noch wenn das WEB nicht mehr geht. SSH oder NFS geht dann immer noch.
Wie genau definierst Du "FHEM Web :8083 ist nicht mehr verfügbar"?
Ich weiss nicht genau, was "attr ARDUINOserial verbose 5" macht, aber evtl. ueberlastet es die Festplatte.
Zum debuggen wuerde ich FHEM mit "perl fhem.pl -d fhem.cfg" in einer Konsole starten, und die Ausgaben beobachten.
Ggf. wäre noch ein list von dem anderen (FTDI-)Arduino hilfreich.
Und wenn FHEM nicht erreichbar ist:
Prozessor/Speicher Last etc.
So die Tests gingen weiter. Vielen Dank für die Rückmeldungen.
- mit "FHEM Web :8083" meinte ich das normale "Builtin web frontend" das über den Port 8083 erreichbar ist. Dieses kann ich dann nicht mehr aufrufen.
- "attr ARDUINOserial verbose 5" habe ich nur zum debuggen gesetzt. Das Problem war vorher schon da. Danke für den Tipp mit der Konsole, ist viel besser!
- Ich bin jetzt nochmal zurück auf 0 und habe mir mal einen minimalen Arduino Sketchs geschrieben. Hier werden einfach alle 20 Sekunden 10 Werte übertragen und bei jedem schreiben um 1 erhöht.
Dieser Sketch hat neue devices angelegt und es läuft jetzt tatsächlich! CPU bei 5 - 10 % mit Spitzen bis 40% und Mem bei 5,1%
Danach habe ich den Sketch geändert und auf die alten devices geschrieben.
Dann lief es nicht mehr!
Die alten devices hatten noch zusätzliche Attribute: event-on-change-reading, stateFormat, event-min-interval & logfile
Ich habe diese auch mit ,,rename" umbenannt.
Wenn ich alle Attribute lösche, läuft es wieder besser.
Wenn mehr Attribute dazu kommen, zeigen sich so langsam erste Timeout am Web Frontend.
Und eben hatte ich auch mal mehrere Reset des Arduino! CPU bei 95%
Somit vermutete ich jetzt ein performance Problem des TEST Pi1. Dort läuft aber sonst fast nichts anderes in FHEM.
Und zum Schluss habe ich nochmal alles neu angelegt und gerade läuft es mal wieder.
Ich bin etwas Ratlos. Den die Attribute sind jetzt wieder drin.
Jetzt läuft auch wieder große Sketch und nur beim senden hat die CPU >5% sonst 0%
So einen richtigen Grund habe ich jetzt nicht finden können.
ZitatDieses kann ich dann nicht mehr aufrufen.
Weil dir die Haende gebunden sind?
Will sagen: aufrufen kann man sicher, es kommt aber eine Fehlermeldung, und genau diese interessiert mich. Timeout, Connection refused, etc.
ZitatWenn mehr Attribute dazu kommen, zeigen sich so langsam erste Timeout am Web Frontend.
Es koennte an der "Festplatte" liegen:
- mit "iostat -x 2" in einem separaten Konsolenfenster kann man sehen, ob sie ausgelastet ist, und wieviel sie schreibt oder liest.
- "top" zeigt in der "%Cpu" Zeile (dritte von oben), ob der Prozessor belastet ist (us/sy/ni), ob auf etwas wie Platte gewartet wird (wa), oder die Interrupt-Last (hi/si) zu hoch ist.
Zitataufrufen kann man sicher, es kommt aber eine Fehlermeldung, und genau diese interessiert mich. Timeout, Connection refused, etc.
Wenn garnichts mehr geht erhalte ich im Browser "Diese Seite ist nicht erreichbar"
Wenn das Frontend schon offen war und es dann nicht mehr geht "Connection lost, trying a reconnect every 5 seconds".
Wenn es nicht so lange dauert, wird die Seite dann auch mal wider geladen.
Bei der CPU Last, Platte oder Interrupt konnte ich nichts besondere feststellen.
Das Bild zeigt den Moment an dem die Daten gesendet wurden. ( Heute funktionierte aber auch fast immer das Web Frontend)
Die Probleme sind irgendwie immer etwas unterschiedlich.
Heute hatte ich weniger Probleme mit dem Frontend aber dafür nach einiger Zeit immer wieder einen Reset des NANO.
In allen KVP Devices sind die Werte dann wieder weg und es steht dann wieder "Initialized"
Noch eine Frage:
Wie muss die Übertragung des KeyValueProtocol abgeschlossen werden?
Gibt es ein bestimmtes Steuerzeichen?
In meinem Fall verwende ich "serial.println(255.00)" und den zu übertragenden Wert.
OK VALUES VW_ARDUINO 0013 state=255.00
Gibt es einen Beispielsketch für den Arduino?
Hier auch mal mein Testsketch.
float Wert[10]={0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0};
void setup(){
Serial.begin(38400);
}
void send_serial(){
for(int d=0; d<10; d++){
Serial.print("OK VALUES VW_ARDUINO 0");
Serial.print(d);
Serial.print(" state=");
Serial.println(Wert[d]);
Wert[d]=Wert[d]+1;
delay(50);
}
}
void loop(){
send_serial();
delay(20000);
}
Habe mein Test FHEM jetzt komplett gelöscht und nur den NANO mit KeyValueProtocol neu angelegt.
Da läuft jetzt der Test Sketch und es läuft alles super.
Ich werde jetzt nach und nach wieder alles aufbauen und schauen ab wann Probleme auftreten.
Ich habe noch einige andere Sensoren (1-Wire, I2C, GPIO) am laufen.
Ich versteh die Welt nicht mehr. Nach zwei Wochen mit Problemen, geht es seit gestern einfach wieder!
Sowohl auf meinem Test FHEM als auch auf meinen großen FHEM.
An meinem großen habe ich keine Änderungen gemacht. Alle Attribute der KVP Devices sind unverändert.
Ich werde es weiter beobachten.
So und heute geht wieder gar nichts mehr! Kein FHEM Frontend erreichbar.
FHEM läuft aber im Hintergrund fleißig weiter.
Wenn ich den FHEM Service über das Terminal beende und wieder mit "perl fhem.pl -d fhem.cfg" starte, sehe ich dass es läuft.
Das Frontend ist weiterhin nicht erreichbar.
Prozessorlast, Platte und Interrupt alles minimal belastet.
Nur ein Neustart des Pi hilft für kurze Zeit.
ZitatWenn ich den FHEM Service über das Terminal beende und wieder mit "perl fhem.pl -d fhem.cfg" starte, sehe ich dass es läuft.
Das Frontend ist weiterhin nicht erreichbar.
Bin verwirrt: ist das FHEM Frontend in diesem Fall erreichbar, oder nicht?
Wenn nicht, dann wuerde weiterhelfen, wenn Du die Ausgaben vom "fhem.pl -d" hier angehaengen wuerdest.
Da es eine ältere Installation, ist die telnet-Schnittstelle noch aktiv und erreichbar?
ZitatBin verwirrt: ist das FHEM Frontend in diesem Fall erreichbar, oder nicht?
Das FHEM Frontend ist nicht erreichbar. Das Browser dreht so lang bis er irgendwann abbricht.
Nach mehrmaligen Neustarts geht es aktuell grad mal wieder.
Im Moment kann ich mich mit Telnet anmelden und Befehle eingeben.
Das Frontend läuft aber im Moment auch.
Die Frage währe, wenn das Frontend nicht läuft, wie es dann aussieht ...
Ja, schon klar. Im Moment läuft es halt wieder. Ich hab Telnet heut zum ersten mal probiert und wollte nur mitteilen dass es gerade funktioniert. Ich werde es testen wenn das Frontend mal wieder komplett hängt.
So eben hing das System mal wieder. Ich konnte das Frontend nicht erreichen und auch ein Telnet Verbindung war nicht möglich.
Nach ca. 2 Minuten warten ohne etwas zu tun ging dann sowohl das Frontend als auch die Telnet Verbindung wieder.
Das hört sich nach einem blockierenden Prozess an. In einer zeit, wo FHEM nicht erreichbar ist:
- wie sieht die Last aus? ps aux | grep fhem
- Wurde etwas besonderes geschaltet, gesucht?
- Was sagt das Log?
Zitat- Was sagt das Log?
Das wuerde mich auch interessieren, aber scheinbar wurde meine Bitte von vorgestern uebersehen.
ZitatDas hört sich nach einem blockierenden Prozess an. In einer zeit, wo FHEM nicht erreichbar ist:
- wie sieht die Last aus? ps aux | grep fhem
- Wurde etwas besonderes geschaltet, gesucht?
- Was sagt das Log?
Aktiv habe ich nichts geschaltet. Aber während der Störung konnte ich mit "ps aux | grep" sehen, dass mein ESPEasy Display angesteuert wurde.
Vielleicht blockiert das die Verbindung zum Frontend. Dieses habe ich jetzt mal deaktiviert.
pi@raspberrypi:~ $ ps aux | grep fhem
fhem 583 4.1 6.5 33716 29296 ? S 14:19 1:13 perl fhem.pl fhem.cfg
fhem 1791 1.0 0.2 1900 1084 ? S 14:48 0:00 sh -c wget -O /dev/null -q http://192.168.100.230/control?cmd=event,OUT_P=1004.0
fhem 1792 8.0 1.1 34360 4928 ? S 14:48 0:00 wget -O /dev/null -q http://192.168.100.230/control?cmd=event,OUT_P=1004.0
pi 1794 0.0 0.4 4768 2092 pts/0 S+ 14:48 0:00 grep --color=auto fhemLeider kann ich immer nur dann testen, wenn es sporadisch mal nicht geht.
Mein global Log war seit 2 Tagen weg. Warum auch immer. Habe ihn heute mal wieder angelegt.
2019.03.10 12:21:05 3: MyCntEvent return value: SCALAR(0x347b1b8)
2019.03.10 12:21:06 3: MyCntgpioEvent return value: SCALAR(0x3869340)
2019.03.10 12:21:07 3: MyCntEvent return value: SCALAR(0x36def50)
2019.03.10 12:21:07 3: MyCntgpioEvent return value: SCALAR(0x37cba98)
2019.03.10 12:21:27 3: BZ_Display return value: -1
2019.03.10 12:21:27 3: Func_Cnt_Solar_Pow: SCALAR(0x36800b8)
2019.03.10 12:58:31 1: Timeout for SYSMON_blockingCall reached, terminated process 1268
2019.03.10 12:59:38 1: Timeout for SYSMON_blockingCall reached, terminated process 1329
2019.03.10 13:03:57 1: Timeout for SYSMON_blockingCall reached, terminated process 1549
2019.03.10 13:11:05 1: Timeout for SYSMON_blockingCall reached, terminated process 1862
2019.03.10 13:18:44 1: Timeout for SYSMON_blockingCall reached, terminated process 2255
2019.03.10 13:19:51 1: Timeout for SYSMON_blockingCall reached, terminated process 2298
2019.03.10 13:21:33 1: Timeout for SYSMON_blockingCall reached, terminated process 2343
2019.03.10 13:22:44 1: Timeout for SYSMON_blockingCall reached, terminated process 2433
2019.03.10 13:26:02 1: Timeout for SYSMON_blockingCall reached, terminated process 2572
2019.03.10 13:29:08 1: Timeout for SYSMON_blockingCall reached, terminated process 2693
2019.03.10 13:31:48 1: Timeout for SYSMON_blockingCall reached, terminated process 2851
2019.03.10 13:35:27 1: Timeout for SYSMON_blockingCall reached, terminated process 2969
2019.03.10 13:36:34 1: Timeout for SYSMON_blockingCall reached, terminated process 3046
2019.03.10 13:42:32 1: Timeout for SYSMON_blockingCall reached, terminated process 3322
grep: Schreibfehler: Datenübergabe unterbrochen (broken pipe)
2019.03.10 13:44:03 1: Timeout for SYSMON_blockingCall reached, terminated process 3371
2019.03.10 13:47:54 1: Timeout for SYSMON_blockingCall reached, terminated process 3520
2019.03.10 13:53:48 1: Timeout for SYSMON_blockingCall reached, terminated process 3847
2019.03.10 14:16:54 1: Timeout for SYSMON_blockingCall reached, terminated process 4486
2019.03.10 14:18:53 1: reload: Error:Modul 99_myUtils deactivated:
2019.03.10 14:18:54 1: Including fhem.cfg
2019.03.10 14:19:29 2: eventTypes: loaded 362 events from ./log/eventTypes.txt
2019.03.10 14:19:54 1: Including ./log/fhem.save
2019.03.10 14:19:56 0: Featurelevel: 5.9
2019.03.10 14:19:56 0: Server started with 192 defined entities (fhem.pl:18343/2019-01-20 perl:5.020002 os:linux user:fhem pid:583)Währed der SYSMON Tioeouts hing das System die ganze Zeit.
@ rudolfkoenig
Ich habe es nicht übersehen, konnte es aber noch nicht testen.
Wenn das System läuft liefert mir "fhem.pl -d" fogendes:
pi@raspberrypi:/opt/fhem $ perl fhem.pl -d
Usage:
as server: fhem configfile
as client: fhem [host:]port cmd cmd cmd...
pi@raspberrypi:/opt/fhem $
VIELEN DANK FÜR EURE HILFE :D
SYSMON_blockingCall
Also ich würde denkn, das es daran liegt. Was hast Du im SYSMON eingestellt?
Bitte ein List ...
Der SYSMON läuft bei mir schon seit Ewigkeiten unverändert und problemlos. Ich denke der hängt eben auch wenn das Frontend nicht geht.
define sysmon SYSMON 10 10 10 10
setuuid sysmon 5c463dce-f33f-0037-803b-98dd5b825bc1e212
attr sysmon network-interfaces eth0:eth0:Ethernet
attr sysmon room System
ZitatWenn das System läuft liefert mir "fhem.pl -d" fogendes:
Ich meinte eigentlich, dass man FHEM im Terminal mit "perl fhem.pl -d fhem.cfg" startet.
ZitatIch meinte eigentlich, dass man FHEM im Terminal mit "perl fhem.pl -d fhem.cfg" startet.
Ja das hab ich schon gemacht. Da kommt so eine Masse von Zeilen. Ist das nicht zu viel, wenn ich die alle hier rein laden will?
Es ist halt immer schwierig den Moment zu erwischen an dem es mal länger wieder nicht geht.
Vielleicht war es ja wirklich mein "wget -O /dev/null -q http://192.168.100.230/..." zu meinem ESPEasy Display??!!
Ich bleib dran.
ZitatJa das hab ich schon gemacht. Da kommt so eine Masse von Zeilen. Ist das nicht zu viel, wenn ich die alle hier rein laden will?
Klar, aber es reichen die letzten paar (100?) Zeilen, wenn es klemmt.
Wie rufst Du denn das wget auf?
Und Du könntest es probieren, in dem Du einfach mal dem Display den Strom "klaust". Wenn fhem dann steht, liegt es daran ..
ZitatWie rufst Du denn das wget auf?
über folgendes notify
define BZ_Display notify BI_. {my $cnt = Value("BI_7");;system "wget -O /dev/null -q http://192.168.100.230/control?cmd=event,BZ_T=$cnt";;my $cntH = Value("BI_6");;system "wget -O /dev/null -q http://192.168.100.230/control?cmd=event,BZ_H=$cntH";; my $cntTO = ReadingsVal("DS18B20_S4_Aussentemp","temperature",0);;system "wget -O /dev/null -q http://192.168.100.230/control?cmd=event,OUT_T=$cntTO";; my $cntPO = ReadingsVal("BMP180","pressure-nn",0);;system "wget -O /dev/null -q http://192.168.100.230/control?cmd=event,OUT_P=$cntPO"}UND getriggert wird es von den Werten BI_. die vom
Nano Clone mit KeyValueProtocol kommen.
Da können auch mal bis zu 8 Werte innerhalb einer Sekunde kommen. Dann wird auch das notify entsprechend oft den wget ausführen!!
ZitatDu könntest es probieren, in dem Du einfach mal dem Display den Strom "klaust".
Ja, das Display ist schon einige Zeit nicht mehr in Betrieb. Also ist die Ziel-IP auch nicht erreichbar. Somit könnte auch das ein Problem sein. Aber eben auch nicht immer.
Das "notify BZ_Display" ist jetzt auf jeden Fall mal deaktiviert.
Vielleicht kommen wir der Sache jetzt ja schon mal näher! Seit heute Mittag nach dem Deaktivieren läuft es auf jeden Fall mal.
Das hat aber noch nichts zu heißen.
So wie Du es aufrufst, blockieren Deine wget-Aufrufe FHEM.
Es ist also kein Wunder, das dann FHEM nicht erreichbar ist.
Wie mache ich den wget Aufruf denn richtig?
Dein Problem ist, das FHEM solange blockiert, wie Dein wget Aufruf dauert. Wenn wget jetzt aber auf den TimeOut wartet, weil der Kommunikationspartner "weg" ist, wird solange FHEM blockiert.
Normalerweise würde man mit "&" den prozess in den Hintergrund schicken, da fhem dann weiterlaufen kann. bei Dir hier hast Du aber das Problem, das DU einige wget-Aufrufe hast. Wenn Du diese einfach in nden hintergrund schickst, kann es Dir passieren, das DU viele wget-Aufrufe auf das gleiche Device hast. Damit wirst Du den esp8266 überlasten.
Ich persönlich würde die Daten in eine Datei schreiben und in einem externen script per wget aufarbeiten.
(Order jemand nach einem Modul fragen ;o) )
Danke mal für die Rückmeldung. Bis jetzt läuft das fhem echt wieder gut. Hoffe es bleibt so. Bei dem Display werde ich auf jeden Fall mit dem PRESENCE Modul abfragen ob es da ist und nur dann den wget senden. Zukünftig dann auch mit AT und nicht mehr über notify. Dann habe ich den vielfachen Aufruf von wget auch nicht mehr. Ich lass es jetzt aber erst noch einige Tage ohne Display laufen um zu sehen ob es wirklich daran lag.
Fazit & Zusammenfassung
Nach ca. 1,5 Wochen ohne Probleme und sehr guter Performance von FHEM würde ich sagen, das Problem wurde erkannt und behoben!
Ursache der Störung:
Das KeyValueProtocol war nicht die Ursache der Störung. Der Nano Clone läuft im Monent echt sauber, so wie man es erwartet.
Die Störung wurde durch mehrere hintereinander folgende wget-Aufrufe über FHEM verursacht, bei denen das Ziel nicht erreichbar war! Somit wurde bis zum TimeOut gewartet was FHEM blockiert hat.
Zusätzlich wurden die wget-Aufrufe durch ein event ausgelößt. Das device des events war der Nano Clone mit KeyValueProtocol. Hier konnten auch mehre events innerhalb weniger Sekunden auftreten, die die wget-Aufrufe dann noch vervielfachten!
Lösung: - wget-Aufrufe nur wenn das Ziel verfügbar ist ( Optional automatische erkennung über "PRESENCE lan-ping [IP]" )
- Auslößung der wget-Aufrufe nicht mehr durch events "notify" sondern Zeitgesteuert über "at"
Vielen Dank an alle, die mich unterstützt und auf den Weg zur Lösung gebracht haben!!