Persistentes DEFMOD/AT [erledigt]

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

Vorheriges Thema - Nächstes Thema

Nobbynews

Zitat von: Det20 am 10 September 2022, 09:05:41
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
set atXYZ active
und im atXYZ dann wieder zum Schluß ein
set atXYZ inactive

Aus der commandref:
Zitatinactive
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
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

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.
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

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

Zitat von: Det20 am 11 September 2022, 14:12:53
WriteStatFile macht was es soll, perfekt, vielen Dank für den Tipp.
Ändert aber nichts daran, dass der Kopfschmerz per Tablette beseitigt ist...

Zitat von: Guybrush am 11 September 2022, 14:09:16
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...
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

#21
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.