Autor Thema: Persistentes DEFMOD/AT [erledigt]  (Gelesen 2513 mal)

Offline Nobbynews

  • Sr. Member
  • ****
  • Beiträge: 523
Antw:Persistentes DEFMOD/AT
« Antwort #15 am: 10 September 2022, 13:18:39 »
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 activeund im atXYZ dann wieder zum Schluß ein
set atXYZ inactive
Aus der commandref:
Zitat
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.

Offline Gisbert

  • Hero Member
  • *****
  • Beiträge: 2805
  • Das Ziel ist das Ziel !
Antw:Persistentes DEFMOD/AT
« Antwort #16 am: 10 September 2022, 13:37:01 »
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 | HP ThinClient T610 | Debian11 | UniFi-Controller, AP, USG-3 | Homematic, VCCU, HMUART | ESP8266, Eigenbau | Gas-, Wasser-, Stromzähler | Sonoff | 1-Wire-Temperatursensoren | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF |  Heizungssteuerung komplett in FHEM

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19338
Antw:Persistentes DEFMOD/AT
« Antwort #17 am: 10 September 2022, 13:44:26 »
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-T620@Debian 11, 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

Offline Guybrush

  • Full Member
  • ***
  • Beiträge: 200
Antw:Persistentes DEFMOD/AT
« Antwort #18 am: 11 September 2022, 14:09:16 »
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...

Offline Det20

  • Sr. Member
  • ****
  • Beiträge: 915
Antw:Persistentes DEFMOD/AT
« Antwort #19 am: 11 September 2022, 14:12:53 »
WriteStatFile macht was es soll, perfekt, vielen Dank für den Tipp.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19338
Antw:Persistentes DEFMOD/AT
« Antwort #20 am: 11 September 2022, 14:13:43 »
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...
Server: HP-T620@Debian 11, 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

Offline Det20

  • Sr. Member
  • ****
  • Beiträge: 915
Antw:Persistentes DEFMOD/AT [erledigt]
« Antwort #21 am: 11 September 2022, 14:16:05 »
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.
« Letzte Änderung: 15 September 2022, 08:35:09 von Det20 »