Persistentes DEFMOD/AT [erledigt]

[Nobbynews]

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

Als workaround schmeiße ich mal die Möglichkeit in den Ring, ein at über set active/inactive zu beeinflussen.
Also im notify statt des defmod ein

Code: [Auswählen]

set atXYZ activeund im atXYZ dann wieder zum Schluß ein

Code: [Auswählen]

set atXYZ inactive
Aus der commandref:

inactive
Deaktiviert das entsprechende Gerät. Beachte den leichten semantischen Unterschied zum disable Attribut: "set inactive" wird bei einem shutdown automatisch in fhem.state gespeichert, es ist kein save notwendig.
Der Einsatzzweck sind Skripte, um das at temporär zu deaktivieren.
Das gleichzeitige Verwenden des disable Attributes wird nicht empfohlen.

[Gisbert]

Hallo Det20,

Es ist dein Thread, und du hast nach Hilfe gefragt. Es soll auch Lösungen geben, die nicht gleich in einem Feature request enden. Ich bin da Mal gespannt, welcher Programmierer sich deiner Sache annimmt.

Viele Grüße Gisbert

[Beta-User]

a) Einzelne Devices wegzuspeichern ist weder vorgesehen noch sinnvoll. Ich halte es auch (jedenfalls ohne eine komplett andere Datenbanklösung) für unmöglich.
b) "Einmal-at" kann man speichern, indem man nur die statefile wegsichert, ohne gleich die ganze Konfiguration abzuspeichern. Letzteres halte ich für problematisch, und bei configDB wird afaik auch bei einem "save statefile" immer die komplette Konfiguration gespeichert.
c) "set ... active" ändert ein Reading. Wird das wegen eines Absturzes nicht gespeichert, sind wir wieder am Anfang.

[OT @Gisbert] GGf. einen separaten Thread starten. Wenn vorher nichts auffälliges im Log steht, würde ich auf systemd als Verursacher tippen, was bedeutet, dass dein System hin und wieder hängt, warum auch immer; es gibt Tools dazu wie Freezemon.  Speicherprobleme halte ich für eher unwahrscheinlich, aber das zu monitoren kann auch nicht schaden.
Würde auf schlecht optimierte Eventverarbeitung iVm. sehr vielen Events tippen.

[Guybrush]

Also ich halte so ein Feature nicht für sinnvoll und auch für unnötig. Du musst dein FHEM stabil bekommen. Daran führt meiner Meinung nach kein Weg vorbei. Das was Beta-User schrieb ist auch eine Meinung. Wäre für mich inakzeptabel, wenn FHEM immer wieder abstürzen würde. Insofern sprechen wir hier nicht über die Heilung einer Krankheit sondern nur darüber, dass sich diese nicht so schlimm auswirkt. Das ist aber der falsche Weg...

Ansonsten sollte man kritische Sachen ohnehin über DOIFs prüfen.

Wenn FHEM abstürzt, weil nicht geforked werden kann, dann ist dein Speicher voll. Das sollest du dann beheben...

[Det20]

WriteStatFile macht was es soll, perfekt, vielen Dank für den Tipp.

[Beta-User]

WriteStatFile macht was es soll, perfekt, vielen Dank für den Tipp.

Ändert aber nichts daran, dass der Kopfschmerz per Tablette beseitigt ist...

Ansonsten sollte man kritische Sachen ohnehin über DOIFs prüfen.

[OT] Kritische Sachen vertraue ich keinem DOIF an, die Syntax von diesem Modul  verstehe ich nicht und habe es daher auch nicht mehr im Einsatz...

[Det20]

Ich gebe euch recht, aber aktuell kann ich die Hardware nicht ändern, muss also mit Fork leben. Ist blöd, ja, ist aber aktuell leider so. Also heiligt der Zweck die Mittel. Egal wie doof man das findet.

[Update]
Gestern die FB neu gestartet, hat FHEM in den Tot gerissen. Ohne Fork. Einfach weg. Ohne dass ich etwas dagegen tun konnte. Wie gut, dass es WriteStatFile gibt. Genau für sowas brauche ich das.