Hallo zusammen,
ich weiß leider nicht mehr wie ich weiter testen kann und hoffe auf Mithilfe.
Seit ein paar Tagen verhält sich mein FHEM sehr merkwürdig. Nach einigem Suchen, weiß ich nun, dass FHEM komplett normal läuft bis ich zigbee2mqtt starte. Das ist komisch, da mein Zigbee schon sehr lange ohne Thema lief.
Ich habe vor ca. einem Monat von FileLog auf DBLog umgestellt. Das lief auch alles ohne Probleme durch. Ist aber leider die Einzige Änderung die überhaupt gewesen ist.
top sagt:
Nach starten von z2m 100% CPU fhem - perl
Nach viel hin und her testen, ist mir nun aufgefallen, dass wenn ich FHEM im Debug Modus laufen lasse "perl fhem.pl -d fhem.cfg", dann geht alles ohne Thema. Ich kann dann auch ganz normal schalten usw.
Ich brauche nun hier mal einen Rat, wie ich testen kann oder weiter machen kann?
Wenn der FHEM Debug läuft, starte ich diesen ohne sudo oder ähnlichem. Läuft also mit meinem normalem Benutzer und nicht über den FHEM Benutzer. Kann das ggf. einfach ein Berechtigungsthema sein? Ich habe zum testen schon wirklich viel ausgeweitet. 775 war aber das höchste meiner Gefühle.
Zuerst dachte ich das sich ggf. irgendein Event im Kreis dreht (notify/doif). Dem ist leider aber wohl nicht so, sonst müsste dies im Debug Modus ja auch so sein. Oder?
PS: Ich habe auch einfach mal ein Backup zurück gespielt von FHEM. Das hat leider nicht geholfen. Hier sollte ich erwähnen, dass ich meine Backups via Skript auf ein NAS schiebe. Diese werden wöchentlich erstellt und und in ein Archiv gepackt. Hier ist auch der komplette FHEM Ordner drin.
Was braucht Ihr um mir zu sagen, was ich nun tun kann?
Gruß und Danke für jede Hilfe!
Zusatz Infos:
Pi4 8GB
SSD
Direkt via Rj45 verbunden
DBLog via Maria/MySQL
z2m Version geupdatet ohne Erfolg (Aktuell auf 1.42.0)
Im FHEM Log ist nichts zu finden was hilft. Sieht aus wie ein normaler Start.
Hier habe ich natürlich auch geschaut:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Moin,
steht vlt. was dazu im z2m-Log (normal: cd/opt/zigbee2mqtt/data/log/...)?
Wird der Stick erkannt?
alles auf einer Maschine? initial Usb Check von FHEM aktiv -> deaktivieren?
attr initialUsbCheck disable
Zitat von: TomLee am 08 Dezember 2024, 10:25:11Moin,
steht vlt. was dazu im z2m-Log (normal: cd/opt/zigbee2mqtt/data/log/...)?
Wird der Stick erkannt?
Der Stick wird erkannt. Wie gesagt ist FHEM im Debug Modus ganz normal und funktioniert. Im LOG von z2m steht leider auch nichts.
Zitatalles auf einer Maschine? initial Usb Check von FHEM aktiv -> deaktivieren?
Ja, alles auf dem einen PI. Das geht auch sehr gut, wenn man die Events in FHEM ein wenig eingrenzt. Da läuft z.B. auch noch Grafana drauf.
Das attr ist disable. Mache ich bei jeder FHEM Installation.
Gibt es bis auf die eine Seite, die ich oben mit angehnagen habe, keine weiteren Test/Debug Wege für FHEM?
Naja, nur mal laut gedacht:
Was ist anders wenn FHEM im Debug Modus läuft? Er schreibt nicht ins fhem Log (jetzt Datenbank?) sondern in die Standardausgabe.
Was passiert wenn Du Z2M startest? die MQTT Devices senden Erfahrungsgemäß ziemlich viel, d.h. der MQTT2 Server von FHEM muss arbeiten.
Klingt irgendwie, als ob der Prozess von MQTT -> FHEM -> Datenbank klemmt/überlastet. Beißt sich da was zwischen der Z2M Installation und FHEM mit Datenbank?
Man könnte die Events im MQTT2 Server beobachten - mit und ohne debug Modus.
Gefühlt würde ich das Thema nicht im Anfängermodus belassen, sondern nach MQTT verschieben. ;)
Gruß Otto
Guter Ansatz!
Ich habe zwei z2m Instanzen. In der einen sind nur 3 Geräte. Diese kann ich mit hoch fahren und es geht.
In der zweiten Instanz sind ca. 40 Geräte. Die Meisten sind Lampen. Also dauer bestromt und senden dementsprechend einiges.
Nur das ganze lief ja auch seit ca. 4 Wochen. Daher macht mich das stutzig. Kann ich irgendwo sehen, was genau die DB macht? Ich sehe leider nur den FHEM-perl Prozess der auf 100% springt. Wenn man z.B. die z2m Instanz wieder stoppt, bleibt der Prozess weiterhin auf 100%.
Mit deiner Logik würde ich als erstes mal die DB ausschalten um zu sehen ob es damit zusammen hängt.
Innerhalb des Debug Modus kann ich zwar sehen das FHEM Dinge macht aber es ist unmöglich zu sehen was genau. Da passiert einfach zu viel.
Die DB lasse ich auch nur auf folgende Events laufen:
./db.conf .*:(t_humidity|t_temperature|s_state|occupancy|illuminance_lux|presence|Brenner_1_Modulation|HK1-Vorlauftemperatur|HK2-Vorlauftemperatur|WW-Isttemperatur|Aussentemperatur|relay_0_power|relay_0_kWh_total|kWh_kosten|apower|aenergy_total_kwh|c_own_state|desired-temp|loadState).*
Läuft denn das normale fhem log auch in die DB? Mein Gedanke war ja: da ist der Unterschied zwischen Debug und normal Modus.
Wenn der zweite Z2M Prozess das Problem triggert und es danach aktiv bleibt - dann kämpfen dort eventuell zwei Prozesse um die gleichen Ressourcen? Was ist wenn Du FHEM nach dem Z2M Prozess startest?
Ich habe leider keine konkrete Idee.
Hallo
hatte ein ähnliches Problem als von FileLog auf DB umgestellt hatte.
Habe alle Änderungen immer direkt in die DB geschrieben, dadurch wurde mein fhem stark blockiert.
Nachdem ich dann in der "/etc/mysql/my.cnf" (könnte auch wo anders liegen) den Eintrag "innodb_flush_log_at_trx_commit = 2" eingefügt hatte lief alles wieder normal.
Gruß rippi
Das FHEM.log ist weiterhin FileLog. Nur die Geräte Logs habe ich in die DB geschoben.
Ich habe nun mal alles mögliche in Richtung, wer startet zuerst probiert.
Der "kleinere" z2m macht nie Probleme. Der "größere" sorgt jedes mal dafür. Das war früher nicht so.
Ich habe in FHEM dblog disabled. Das scheint aber nicht zu reichen. Zudem habe ich das pm2 start skript deaktiviert (welches z2m startet).
z2m Kann nicht gestartet werden, wenn der mqtt Server nicht vorhanden ist.
Ich würde gerne in den einen Prozess der auf 100% geht, hineinschauen oder mehr über ihn erfahren. Hast du da ne Idee?
@rippi46:
Habe ich gerade Testweise mal in der /etc/alternatives/my.cnf gesetzt aber ohne Erfolg. Gleiches Verhalten :\
Ich tappe ein wenig im dunklen, da es ja alles mögliche sein kann. Ich kann nicht sagen woran es liegt. DB war ne gute Idee von Otto123. Aber wenn ich diese in FHEM disable, sollte das ja kein Thema mehr sein.
Was man sieht beim starten von z2m ist das sobald er gegen den MQTT Server verbunden ist, passiert das mit den 100% CPU. Auf Consolen Ebene kann ich alles noch ganz normal machen aber alles gegen z2m oder FHEM ist in dem Moment erstmal nicht möglich.
Noch ein Hinweis: Ich habe alle Geräte aus dieser z2m Instanz gelöscht (yaml Datei). Selbst dann geht perl auf 100%.
Zitat von: Otto123 am 09 Dezember 2024, 10:52:23Prozess von MQTT -> FHEM -> Datenbank klemmt/überlastet
Wenn die DB überlastet ist müsste sich das nicht durch seeehr viele Einträge in kurzer Zeit in der Datenbank bemerkbar machen.
Zitat von: 87insane am 09 Dezember 2024, 13:53:21Ich habe in FHEM dblog disabled
Zitat von: 87insane am 09 Dezember 2024, 11:14:35./db.conf .*:(t_humidity|t_temperature|s_state|occupancy|illuminance_lux|presence|Brenner_1_Modulation|HK1-Vorlauftemperatur|HK2-Vorlauftemperatur|WW-Isttemperatur|Aussentemperatur|relay_0_power|relay_0_kWh_total|kWh_kosten|apower|aenergy_total_kwh|c_own_state|desired-temp|loadState).*
Wäre es nicht geschickteer statt "disable" einfach die DEF massiv abzuspecken. Ggfs. einfach ein einzelnes Gerät:Reading:.* statt .*:... nehmen.
Es gibt ja auch noch das Attribut "asyncMode" für DBLog, um durch das Modul zunächst Daten zu puffern statt sofort zu schreiben.
...falls DBLog das Problem ist.
Gruß Ralf
asyncMode ist an, seit beginn der DB. Hatte das irgendwo gelesen, dass es Sinn macht wegen Blocking.
Wenn ich die DB disable sollte es doch den gleichen Effekt haben. Daher erstmal die Kanone für den Spatz. Mir ist nach wie vor nicht klar ob es wirklich daher kommt.
Zitat von: 87insane am 09 Dezember 2024, 13:53:21Ich habe alle Geräte aus dieser z2m Instanz gelöscht (yaml Datei). Selbst dann geht perl auf 100%.
Moment, also du hast jetzt alles in dieser z2m-Instanz gelöscht und die CPU-Last geht trotzdem hoch? Also obwohl da keine Zigbee-Devices mehr sind?
Kannst du mal mit MQTT-Explorer o.ä. loggen, was z2m denn (beim Start, aber nicht nur) für MQTT-Nachrichten an FHEM schickt? Das ist ja die einzige Stelle, wo z2m mit FHEM interagiert.
Zitat von: passibe am 09 Dezember 2024, 15:37:23Kannst du mal mit MQTT-Explorer o.ä. loggen,
Das geht doch auch mit MQTT2 Server ?
Hab das FHEM-interne logging noch nie gebraucht/benutzt, deshalb auch "o.ä." :D aber gut, dass du darauf hinweist!
Ich wollte übrigens überhaupt nicht sagen: die DB ist Schuld. Ich hab nur die Unterschiede aufgezählt.
Mit allen Zusatzantworten erhärtet sich mein Verdacht: es hat wahrscheinlich nichts mit Datenaufkommen zu tun, es sei denn es wird eine Schleife getriggert. Ich vermute immer auch noch: Z2M greift auf etwas zu und FHEM kämpft anschließend dagegen an. Welche Schnittstelle verwendet den die zweite Z2M Instanz? Oder welche Ports öffnet die zweite Z2M Instanz?
Guten Morgen zusammen,
nachdem ich nun x Dinge probiert habe, habe ich die Lösung hierfür.
Ich hatte wegen des 98_vitconnect Moduls in der letzten Woche auch schon ein Thema gehabt mit 100% CPU Last. Hierzu hatte ich Fhem im Debug Modus benutzt um zu schauen woran es liegt. Das Thema war schnell gefunden.
Nach einem letzten Neustart hatte ich dann aber ohne dieses Modul auch wieder 100% (siehe oben).
Nun durfte ich feststellen, dass der DEBUG Modus von FHEM das Gerät global auf verbose 5 stellt und das LogFile entfernt. Dies sollte der DEBUG Modus beim beenden auch wieder rückgängig machen. Hat er aber nicht.
Resume: Immer wenn ich z2m einschalte kommt dermaßen viel rein, was zum einen auch wieder notifys/doifs triggern soll aber eben an sich auch verarbeitet wird. Verbose 5 zurück auf 2 und das Logfile eingetragen und alles ist wieder wie es sein soll. Bin nun wieder bei max 20% CPU Last.
Das hat mich nun sehr viel Lebenszeit gekostet und vor allem gibt es nur eine sehr kurze Wiki, in der so Kleinigkeiten beschrieben sind. Ich finde dort sollte der Hinweis mit unter den DEBUG Modus. Hinzu würde ich mir eine Art Sammlung wünschen. Ich habe x Dinge gegoogelt, wie man in FHEM wieder zum Ziel kommt. Es gibt diverse Seiten, auch hier im Forum wo immer mal wieder irgendein Befehl steht, den man für die Suche bei Fehlern nutzen kann. Zum einen auf CMD Ebene aber auch auf FHEM Seite selber.
Ich persönlich kenne Linux ja zum Glück ein wenig. Was machen aber Personen die ggf. neu sind? Ich denke für jeden dieser Menschen wird das schnell zu Frust.
Gleiches gilt für Berechtigungen. Welche Brauch z.B. FHEM in welchem Ordner? Das ist an sich relativ einfach aber auch hier gibt es nicht einfach 755 auf alles. ../fhem/.ssh sollte mindestens auf der id_rsa 600 besitzen.
Ich bin gerne bereit hier mal aufzuschreiben, was ich so weiß bisher. Allerdings würde ich das nicht alleine machen wollen, bevor etwas davon nur die halbe Wahrheit ist und noch mehr Stress verursacht.
Mein Thema stelle ich nun auf gelöst und sage ein dickes DANKE an alle Helfer :)
Gruß,
87Insane
Schön dass Du es gelöst hast, aber mir klingt das irgendwie unlogisch. Zumal es nicht Deine Aussage von oben erklärt?
Zitat von: 87insane am 09 Dezember 2024, 11:14:35Ich sehe leider nur den FHEM-perl Prozess der auf 100% springt. Wenn man z.B. die z2m Instanz wieder stoppt, bleibt der Prozess weiterhin auf 100%.
Wieso bleibt die Last oben wenn die auslösende Datenquelle abgeschaltet wurde?
Verbose 5 in global schreibt doch lediglich alles ins LogFile, es ändert an der Belastung in der Verarbeitung nicht unbedingt etwas, es sei denn man verarbeitet das LogFile extra.
Für die Tatsache, dass die Einstellung vom Debug Modus anschließend in der fhem.cfg verewigt ist, gibt es mMn nur eine Erklärung: Man hat im Debug Modus save gedrückt bzw. es wurde (automatisch durch ein Device?) ausgeführt.
Ich fürchte es schlummert noch ein Problem im Verborgenen.
Ich denke ich habe einfach nicht lange genug gewartet, nach abschaltet der z2m Instanz. Meist habe ich dem ganzen beim testen ca. 3-4 Min gegeben.
Das ich in dieser Zeit Save gedrückt habe, kann ich nach den ganzem Testen nichtmal abstreiten. Wenn man FHEM im Debug startet, wird alles über die Konsole ausgegeben. Denke daher nimmt er das LogFile Temporär rauß und verbose auf 5. Was in dem Fall ja sogar Sinn macht.
Ich lasse es erstmal auf gelöst. Habe zum testen x mal neu gestartet und immer wieder z2m aus/an geschaltet. Ich denke das ist erstmal ok. In jedem Gerät, was ich besitze habe ich z.B. mindestens event-on-change an. Wenn ich das nicht machen würde, wäre der PI mit dem ganzen Zeugs drauf, sicher auch zum lahm. Daher kann ich mir schon vorstellen, dass die Verarbeitung der ganzen Ausgaben Probleme macht. Hinzu weiß ich nicht ob die Ausgaben, die über Verbose 5 in global kommen auch nochmal irgendein notify triggern. Könnte ja sein, dass dies auch als normales event gewertet wird?
Stellt der Debug Modus noch mehr um als global verbose 5 und Logfile auf -?
Zitat von: 87insane am 10 Dezember 2024, 12:25:08Stellt der Debug Modus noch mehr um als global verbose 5 und Logfile auf -?
Soweit ich den Code in fhem.pl verstehe ist es genau dies :)
3203 if($fhemdebug && $sdev eq "global") {
3204 $attrVal = "-" if($attrName eq "logfile");
3205 $attrVal = 5 if($attrName eq "verbose");
3206 }