Persistentes DEFMOD/AT [erledigt]

Begonnen von Det20, 09 September 2022, 12:49:59

Vorheriges Thema - Nächstes Thema

Det20

Hallo,

ich nutze an einigen Stellen intensiv "DEFMOD". Stürzt FHEM zwischendurch mal ab und startet dann (bei mir automatisch) neu, dann sind die DEFMOD's natürlich verschwunden, obwohl vielleicht noch Zeit gewesen wäre oder die eingestellte Uhrzeit noch nicht erreicht ist. Ein großer Wunsch wäre deshalb ein DEFMOD, dass den Neustart überlebt.

Guybrush

wie oft stürzt denn dein FHEM ab? wenn es nur FHEM selbst ist, dann solltest du unbedingt mal deine Logs anschauen. Sowas kann eigentlich nur passieren, wenn du ein unsauber geschriebenes Modul nutzt. FHEM selbst ist stabil und ich hab auch mit meinen eingesetzten Modulen bislang kein Problem. Bei mir stürzte zwar auch FHEM schon mal ab, aber das ließ sich mit Updates der Module oder Änderungen an (falsch) gesetzten Attributen schnell beheben.

Ansonsten zu deiner Frage - Du müsstest deine Config speichern. Wenn es aber immer nur temporäre Defines sind, halte ich das aber nicht für opportun. Eine anderen Weg als diesen gibt es meines Erachtens nach nicht.

Du solltest also nicht nach einer Lösung für die Behebung deiner Symptome suchen, sondern besser die Ursache lösen.

Gisbert

Hallo Det20,

so eine  Vorgehensweise, wie du sie schilderst, hab ich noch nirgends gesehen. Brauchst du wirklich defmods, um etwas abzuspeichern? Gehen keine userReadings?
In lediglich einem Fall nutze ich defmods, und zwar da, wo ein Intervall in der Definition steht. Aber da will ich nicht ständig über ein rotes Fragezeichen stolpern, so dass ich die Änderung mit -silent abspeichere, also so:
defmod -silent ...
Ob das permament gespeichert ist, kann ich dir nicht sagen - ein Versuch kostet ja nichts.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

DetlefR

Hallo,

zuerst einmal solltest Du berücksichtigen was Gaybrush schreibt. FHEM allein zum Absturz zu bringen, ist gar nicht so einfach.

Ansonsten gehe ich mal davon aus, Du meinst das anlegen/ändern von temp. Timern wenn Du von DEFMOD schreibst. Da kann ein
ZitatWriteStatefile();
nach dem DEFMOD helfen.
Aber zuerst Punkt 1. beachten.

Det20

#4
Hallo,

Kleines Beispiel: jeden Tag gehen um 9 Uhr die Jalousin hoch. Außer es ist warm, dann sollen die erst in 30 Minuten hochgehen. Bevor ich nun um 9:30 prüfe, ob die nicht schon um 9 Uhr hochgegangen sind, mache ich die mit defmod in 30 Minuten hoch.

Fhem zum Absturz zu bringen ist ganz einfach: erstelle viele Plots (DB connections) , mach die alle in eine Gruppe und zeige die Gruppe an. Nach einigen Versuchen kommt 'cannot fork', irgendwann ist fhem dann tot. Passiert zb auch mit dem home connect Modul zusammen mit dem Google Modul. Habe ich wirklich mehrmals die Woche. Ok, sind systemeinschränkungen, aber Absturz ist Absturz

Gisbert

#5
ZitatKleines Beispiel: jeden Tag gehen um 9 Uhr die Jalousin hoch. Außer es ist warm, dann sollen die erst in 30 Minuten hochgehen. Bevor ich nun um 9:30 prüfe, ob die nicht schon um 9 Uhr hochgegangen sind, mache ich die mit defmod in 30 Minuten hoch.
Wofür brauchst du denn da ein defmod? Das was du da beschreibst, lässt.sich alles ohne defmods realisieren; ich würde es mit einem DOIF realisieren.

Bevor wir uns hier weiter im Kreis drehen, bitte die Definition deines Devices, welches deine Aktionen um 9.00 oder 9.30 durchführt, am liebsten im raw-Format.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Det20

#6
Beispiel: Wenn die Heizung für warmwasser anspringt, werden einige Verbraucher abgeschaltet, bis die Heizung fertig ist (dauert nur 5 Minuten), spätestens aber nach 30 Minuten (fallback). Damit nutze ich die pv optimaler.

fhem("defmod ResetOffHeizung at +00:30:00 { OptimizePowerUsage(0) }");

Stürzt fhem wegen einem  cannot Fork kurz vor abschalten der Heizung ab, dann wird darauf nicht reagiert, der fallback greift leider auch nicht mehr (er ist ja weg). Ich muss an anderer Stelle prüfen, ob die Heizung aus ist, die Geräte her nicht wieder abgeschaltet wurden.

Beta-User

Einmalige at werden in der stateFile gespeichert (falls ein save bzw. save stateFile kommt).

Wegen der reboots: Hast du zufällig viele PRESENCE-Devices mit LAN-Ping?
Dann schau mal nach der Cover-Version von martinp876.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Det20

#8
Du meinst, save state speichert die und stellt die beim start wieder her? Kann man das auf autosave stellen?
Lan-ping habe ich so um die 5, außerdem in diversen Modulen wie lg-webos. Die Cover-Version schaue ich mir mal an, interessanter Ansatz, vielen Dank für den Hinweis

Gisbert

Hallo Det20,

ich bin der Meinung, dass du mit den defmods gewaltig auf dem Holzweg bist. Ich steuere meine Heizung (ich meine damit den Brenner!), die Stellantriebe der FBH, die Warmwasserbereitung und -zirkulation und Verschattung von Fenstern temperatur- und witterungsabhängig, alles mit DOIFs und userReadings.
Bei mir stürzt Fhem auch gelegentlich bis regelmäßig ca. 1mal pro Woche ab. Ich hab jedoch noch nie bemerkt, dass dadurch irgendeine Steuerung aus dem Tritt gebracht wurde.

Ohne umfängliche, konkrete Darstellung deiner Definitionen bleibt es ein Rätselraten - es scheint, dass du dies bevorzugst.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Det20

Zitat von: Gisbert am 10 September 2022, 10:14:09
Ohne umfängliche, konkrete Darstellung deiner Definitionen bleibt es ein Rätselraten - es scheint, dass du dies bevorzugst.

Hallo Gisbert,

Ich habe doch ein Beispiel gegeben. Werde aber die saveState Methode versuchen.

Beta-User

Prinzipiell sollte man seine Installation so auslegen, dass auch bei einem ungeplanten Neustart keine komischen Dinge passieren können.

Ich würde es aber keinesfalls akzeptieren, dass FHEM "so alle Woche mal" abschmiert (und schon gar nicht noch häufiger!). Und auf dem Rechner von Gisbert sollten ausreichend Reserven da sein, um die cannot fork-Geschichte als Ursache eher unwahrscheinlich erscheinen zu lassen.

Abgesehen von "Experimenten" beim Testen von Modul-Änderungen schmiert mir jedenfalls FHEM NIE ab!

FHEM sollte in einer normalen Installation auch mal Monate laufen, ohne dass es zu Problemen kommt. Alles andere ist ein Bug und die Ursachen sollten behoben werden!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

@Det20, Gisbert:

ich weiß ja nicht, was ihr mit euren fhem-Systemen so treibt aber ich habe 4 Installationen laufen (3 davon seit Jahren) und die stürzen quasi nie ab...
...außer ich bastle grad wild rum, dann kann das schon mal sein ;)
(aber eher auch nicht wirklich Abstürze)

Bei einem System dachte ich mal, dass es ab und an abstürzt/neu gestartet wird (wurde es auch).
Aber da hatte ich (dummerweise) eine Abhängigkeit im Service-Script drin und die hat dafür gesorgt, dass fhem neu gestartet wurde (war ja dort auch so definiert ;) )...

Ich würde (auch wegen anderer Dinge) schon mal schauen, dass fhem durchläuft.
Wenn es Last/cannot fork (also Speicher) ist, dann evtl. die Anzeigen etc. etwas "minimieren"/"überdenken" oder auf einen weiteren Rechner "auslagern"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Gisbert

Hallo Jörg,

gestern hab ich im logfile stehen:
2022.09.09 01:01:32.403 1:  Including fhem.cfg
2022.09.09 01:01:32.860 3:  WEB: port 8083 opened
2022.09.09 01:01:32.942 3:  WEBphone: port 8084 opened
2022.09.09 01:01:32.952 3:  WEBtablet: port 8085 opened
2022.09.09 01:01:32.973 3:  httpWEB: port 8086 opened
2022.09.09 01:01:32.989 3:  telnetPort: port 7072 opened
2022.09.09 01:01:33.636 2:  eventTypes: loaded 14968 lines from ./log/eventTypes.txt
usw ...

Das sieht nach einem Fhem-Neustart aus; vor diesem Zeitpunkt gibt es keine auffälligen Einträge im logfile. Wie kann ich das Problem - eigentlich versuch ich es hartnäckig zu ignorieren - eingrenzen?

Hallo Det20,
ZitatIch habe doch ein Beispiel gegeben.
fhem("defmod ResetOffHeizung at +00:30:00 { OptimizePowerUsage(0) }");
Ich möchte nicht polemisch werden und deshalb lass ich das, was ich zunächst schreiben wollte, und versuche sachlich zu bleiben.
Ist diese Definition oben Teil eines Devices und damit einer Automation, oder tippst du das ein, wenn du es brauchst? Die obige Definition sagt, dass OptimizePowerUsage(0) in 30 Minuten ausgeführt werden soll. Was passiert denn anschließend? Nie mehr irgendwas oder tippst du es morgen wieder ein?

Kannst du nicht einfach die Definition eines kompletten Devices (in Code-Tags --> #) hier posten? Auch wenn du es für unnötig hälst, mach es einfach.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Det20

Ich denke wir schweifen vom Thema ab. Es geht nicht um das Beispiel und einer verbesserungsanfrage, sondern um ein Feature request. Es an einem Beispiel dingfest zu machen und das Beispiel auseinander zu rupfen, ändert nix am request.