Hallo, ich habe folgendes Problem: Ich sehe im Log naehzu minütlich folgende Meldungen:
2023.06.15 22:30:06 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:30:15 2: Sduino1: initialized. v3.4.15-dev_ralf_08.04.
2023.06.15 22:31:00 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:31:19 0: Server shutdown
2023.06.15 22:31:35 2: Sduino1: initialized. v3.4.15-dev_ralf_08.04.
2023.06.15 22:31:57 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:32:27 2: AttrTemplates: got 259 entries
2023.06.15 22:32:50 0: Server shutdown
Allein in der letzten Stunde ca. 40 mal.
Dadurch funktioinieren natürlich keinerlei Automatisierungen mehr, das der Server ja permanent mit shutdown und wieder hochfahren beschäftigt ist. Hat jemand eine gute Idee, wo die Ursache liegt?
Zitat von: Calivati am 15 Juni 2023, 22:50:34Hallo, ich habe folgendes Problem: Ich sehe im Log naehzu minütlich folgende Meldungen:
2023.06.15 22:30:06 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:30:15 2: Sduino1: initialized. v3.4.15-dev_ralf_08.04.
2023.06.15 22:31:00 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:31:19 0: Server shutdown
2023.06.15 22:31:35 2: Sduino1: initialized. v3.4.15-dev_ralf_08.04.
2023.06.15 22:31:57 1: Sduino1: UNDEFINED Sensor SD_WS07_TH detected, code SD_WS07_TH_1
2023.06.15 22:32:27 2: AttrTemplates: got 259 entries
2023.06.15 22:32:50 0: Server shutdown
Allein in der letzten Stunde ca. 40 mal.
Dadurch funktioinieren natürlich keinerlei Automatisierungen mehr, das der Server ja permanent mit shutdown und wieder hochfahren beschäftigt ist. Hat jemand eine gute Idee, wo die Ursache liegt?
Ich wollte die Frage löschen, habe aber nicht die nötige Berechtigung. Nach "shutdown/restart" und definition des "unknown device" mit anschließendem ignore SD_WS* ist erst mal Ruhe. Also bitte erst mal ignorieren, danke!
Trotzdem ist das nicht normal .. was ist es für ein System?
Hallo, mit System meinst du vermutlich die HW-Platform? Es ist ein Raspberry 3 und als CUL eben ein Sduino. Ich hatte gestern auch noch einen reset auf den Sduino gemacht, seitdem ist der Fehler in der Form weg. Jetzt stehen noch 15 Meldungen pro Stunde in der Form im Log, aber die shutdowns sind weg:
2023.06.16 08:00:57 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data BE8F0, code BE8
2023.06.16 08:02:48 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 52DD2, code 52D
2023.06.16 08:03:44 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 52DD2, code 52D
2023.06.16 08:12:05 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data E72D8, code E72
2023.06.16 08:12:06 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data BEE72, code BEE
2023.06.16 08:14:01 1: Sduino1: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data BEE72, code BEE
Gruß, Peter
Hast Du eventuell einen WatchDog definiert?
Bei der ersten Meldungg dachte ich, das Du Docker verwendest ...
Ich denke eher nicht, weiß gar nicht was ein watchdog in dem Zusammenhang ist.
Irgendetwas fährt FHEM runter. Ein "Problem" fährt normalerweise FHEM nicht runter, sondern es Crached ...
Kannte ich auch noch nicht aber möglicherweise -> lt. ComRef z.B.:
watchdog
Define
define <name> watchdog <regexp1> <timespec> <regexp2> <command>
Startet einen beliebigen FHEM Befehl wenn nach dem Empfang des Ereignisses <regexp1> nicht innerhalb von <timespec> ein <regexp2> Ereignis empfangen wird.
Der Syntax für <regexp1> und <regexp2> ist der gleiche wie regexp für notify.
<timespec> ist HH:MM[:SS]
<command> ist ein gewöhnlicher fhem Befehl wie z.B. in at oderr notify
Hallo, das Problem tritt nach langer Zeit wieder auf und diesmal massiv. Fhem macht ca. alle 2 Minuten einen Shutdown. Ich habe update versucht, aber die Instanz bleibt nicht lange genug am Leben. Ich habe auch die beiden CULs schon abgesteckt, so dass nur noch das Netzwerkabel am Pi angesteckt war, trotzdem alle zwei Minuten shutdown. Ich brauche dringend Hilfe.
2024.03.04 14:04:34 0: Server shutdown
2024.03.04 14:06:05 0: Server shutdown
2024.03.04 14:08:01 0: Server shutdown
2024.03.04 14:09:56 0: Server shutdown
....
Ich hänge eine file mit dem Log Verbose=5 an.
Wie immer für jede Hilfe dankbar ...
Peter
1. Könntest Du bitte Logfiles als TXT-File eintragen? Macht das Durchlesen einfacher ..
2. ".... Server shutdown": Irgendetwas fährt Dir mit Absicht immer wieder den FHEM-Server runter. Hast Du einen WatchDog installiert? Oder sonst etwas in der Richtung?
3. Passiert das Problem auch mit der Demo-Fhem.cfg?
Hallo Wernieman, klar, ich hänge den Log als Textfile an.
Ich habe nichts in Richtung Watchdog installiert. Was ich aktuell getan habe: Ich wollte Wettervorhersage integrieren und habe mit weather und openweather Versuche gemacht. Irgendwann gingen dann die FM, dass die Connection zum Server unterbrochen ist los. Ich habe alle definitionen mit Wetter mittlerweile gelöscht, der Fehler ist aber unverändert.
Wie gesagt, ich hatte ähnliches Verhalten schon in der Vergangenheit, aber nie so massiv.
Das mit der Demo-cfg versuche ich mal und gebe dann Bescheid.
Vielen Dank erst mal,
Peter
Mit der demo cfg kommen keine shutdowns. Aufgrund dieser Erkenntnis habe ich eine ältere config (die fehlerfrei funktioniert hat) verwendet, und auch damit passieren die shutdowns.
Und jetzt wird's merkwürdig: ich habe auf einem zweiten Pi einen neuen Server aufgesetzt und die aktuelle config des fehlerhaften systems eingespielt. Da funktionieren zwar jetzt viele Sachen erst mal nicht, aber shutdowns treten auch keine auf.
Scheint also an der HW (eher unwahrscheinlich) oder an der fhem installation (eher wahrscheinlich) zu liegen.
... oder am Betriebsystem oder an einer Zusatzsoftware ...
Jedenfalls fährt irgendetwas Deinen FHEM runter ...
Zitat von: Calivati am 04 März 2024, 19:51:53Scheint also an der HW (eher unwahrscheinlich) oder an der fhem installation (eher wahrscheinlich) zu liegen.
Hallo, sofern Deine fhem.cfg nicht den Code für Fort Knox beinhaltet, könntest Du sie ja einfach mal posten
Grüße Jörg
was steht im sylog vom os zu den zeiten?
Hi, also im Syslog finde ich zu den shutdownzeiten (z.B 14:04:34) folgendes:
Mar 3 14:04:27 raspberrypi evcc[613]: [lp-2 ] DEBUG 2024/03/03 14:04:27 charger status: B
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 ----
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:30 charge power: 3680W
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-2 ] DEBUG 2024/03/03 14:04:30 charge power: 0W
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 pv power: 8244W
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 battery soc: 66%
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 battery power: 0W
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 grid power: -3887W
Mar 3 14:04:30 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:30 site power: -3887W
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:30 charger status: C
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:30 vehicle soc: 49%
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:30 vehicle range: 143km
Mar 3 14:04:30 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:30 pv charge current: 32.9A = 16A + 16.9A (-3887W @ 1p)
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 ----
Mar 3 14:04:33 raspberrypi evcc[613]: [lp-1 ] DEBUG 2024/03/03 14:04:33 charge power: 3680W
Mar 3 14:04:33 raspberrypi evcc[613]: [lp-2 ] DEBUG 2024/03/03 14:04:33 charge power: 0W
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 pv power: 8067W
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 battery soc: 65%
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 battery power: 0W
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 grid power: -4051W
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 site power: -4051W
Mar 3 14:04:33 raspberrypi evcc[613]: [lp-2 ] DEBUG 2024/03/03 14:04:33 charger status: B
Mar 3 14:04:36 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:36 ----
Denke, daraus kann man nichts ableiten.
Die Fhem config hänge ich an.
Mar 3 14:04:33 raspberrypi evcc[613]: [site ] DEBUG 2024/03/03 14:04:33 battery power: 0W
Sag mal .. hast Du eine USV am PI hängen?
Nein, ich vermute das sind Meldungen meiner Haus-PV, ich habe das Senec-Modul aktiv
Zitatich habe das Senec-Modul aktiv
Finde ich momentan nicht in der Doku der Offiziellen Module ... oder habe ich etwas übersehen? Und warum postet es andauernd ins System-Log Debugmeldungen ...
[36_Senec.pm] FHEM module zur Integration eines SENEC Speicher und MeinSenec, Developer carlos
Das Modul bindet den Senec Wechselrichter und Speicher in FHEM ein. Dass das ständig Meldungen in den syslog schreibt, hab ich auch eben erst bemerkt.
Das ist dock separat installiert?
In der offiziellen Doku https://fhem.de/commandref.html#intro (https://fhem.de/commandref.html#intro) finde ich es nicht ...
Wir dabei noch ein externes Programm installiert?
Hinweis:
Es geht mir hier nicht darum, etwas doer ein Modul zu kritisieren, sondern möchte nur das System verstehen um Dir zu helfen, den fehler zu finden ..
P.S.
Findest Du in der kern.log oder syslog etwas bezüglich oom?
z.B. durch:
grep -i oom /var/log/kern.log
oder:
journalctl --list-boots | awk '{ print $1 }' | xargs -I{} journalctl --utc --no-pager -b {} -kqg 'killed process' -o verbose --output-fields=MESSAGE
Zu 1: ja, korrket, das ist separat installiert. Es wird dabei nichts weiter installiert.
Im kern.log finde ich nichts bzgl. oom
Die journalctl Abfrage ergibt: Data from the specified boot (-2) is not available: No such boot ID in journal
Ich hab eben nochmal im Syslog geblättert und finde vormittags alle 2-3 Minuten:
Mar 3 11:18:19 raspberrypi systemd[8597]: gpg-agent-browser.socket: Succeeded.
Mar 3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Mar 3 11:18:19 raspberrypi systemd[8597]: gpg-agent-extra.socket: Succeeded.
Mar 3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Mar 3 11:18:19 raspberrypi systemd[8597]: gpg-agent-ssh.socket: Succeeded.
Mar 3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Mar 3 11:18:19 raspberrypi systemd[8597]: gpg-agent.socket: Succeeded.
Mar 3 11:18:19 raspberrypi systemd[8597]: Closed GnuPG cryptographic agent and passphrase cache.
Mar 3 11:18:19 raspberrypi systemd[8597]: Removed slice User Application Slice.
Mar 3 11:18:19 raspberrypi systemd[8597]: Reached target Shutdown.
und ab 19:39 alle 2 Minuten:
Mar 4 19:39:39 raspberrypi systemd[1]: fhem.service: start operation timed out. Terminating.
Mar 4 19:39:39 raspberrypi perl[11361]: 2024.03.04 19:39:39.678 0: Server shutdown
Mar 4 19:39:39 raspberrypi systemd[1]: fhem.service: Failed with result 'timeout'.
Mar 4 19:39:39 raspberrypi systemd[1]: Failed to start FHEM Home Automation.
Mar 4 19:39:39 raspberrypi systemd[1]: fhem.service: Consumed 3.932s CPU time.
Mar 4 19:39:39 raspberrypi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 172.
Mar 4 19:39:39 raspberrypi systemd[1]: Stopped FHEM Home Automation.
Mar 4 19:39:39 raspberrypi systemd[1]: fhem.service: Consumed 3.932s CPU time.
Mar 4 19:39:39 raspberrypi systemd[1]: Starting FHEM Home Automation...
Hallo,
wir kommen der Sache näher.
Fhem wird als Service gestartet. Parametriert wird der Service über die Datei /etc/systemd/system/fhem.service.
Im Original nach der Installion wird Fhem als Type=forked, wenn ich mich richtig erinnere, gestartet. Das hat bei mir mit einer sehr umfangreichen fhem.cfg auch zu diesem Verhalten geführt. Ersetze doch bitte die mal die Zeile Type=forked durch Type=simple. Nach dem Editieren den Service mit sudo systemctl daemon-reload updaten.
Grüße Jörg
[Service]
Type=simple
Hallo Jörg,
super, vorab schon mal ganz herzlichen Dank! Ich habe den Parameter Type=forking in Type=simple geändert und seit ca. 30 Minuten wurde kein shutdown mehr gemacht. Ich beobachte das jetzt noch eine Weile und melde mich dann final noch einmal.
Nochmals danke und viele Grüße
Peter
Ich habe gerade in der systemd.service — Service unit configuration nachgelesen, da steht folgendes:
ZitatIf set to forking, the manager will consider the unit started immediately after the binary that forked off by the manager exits. The use of this type is discouraged, use notify, notify-reload, or dbus instead.
Zitatafter the binary that forked off by the manager exits
Was leider nicht 100% stimmt ... manchmal wird auch gestoppt/gestartet, wenn SystemD "denkt", das der Prozess nicht mehr läuft. Also eine WatchDog Funktionalität.
Laut der Beschreibung würde er es nur tuen, wenn der Prozess sich beendet ...
Hallo zusammen,
seit Stunden keine Abbrüche mehr ;D , ihr seid die Besten!
Vielen Dank an alle, die unterstützt haben!
Viele Grüße
Peter
Könntest Du bitte noch den Therad als [gelöst] markieren?
Dazu einfach Deinen ersten Post aufrufen, bearbeiten und dort im Subjekt ein [gelöst] eintragen ...
P.S.
Nur eine Info:
Wenn jetzt Dein FHEM mal abschmieren sollte, wird es nicht mehr automatisch gestartet ....
Zitat von: WerniemanP.S.
Nur eine Info:
Wenn jetzt Dein FHEM mal abschmieren sollte, wird es nicht mehr automatisch gestartet ....
Hallo,
dass kann ich so nicht bestätigen. In der fhem.service steht ja:
TimeoutStartSec=300
RestartSec=10
Restart=always
Grüße Jörg