Vordefinierte Werte für "Dummy" (z.B. nach Stromausfall)

[Dracolein]

Hallo zusammen,

Elektriker war heute vor Ort und hat mehrfach den Strom im Haus abgestellt. Dadurch wurde auch mein FHEM Server mehrfach restartet und mir fiel auf, dass sämtliche meiner Dummy-Devices einen "undefined" Zustand hatten.

Lässt sich das irgendwie vordefinieren, welchen Zustand Dummy nach FHEM-Restart haben soll?

[Beta-User]

Eigentlich ergibt sich das aus der stateFile.

Wenn die aber "kaputt" oder unvollständig ist, klappt das halt nicht mehr...
Maßnahmen können sein
- USV installieren (ist für die SD-Karte eh' besser!)
- stateFile regelmäßig schreiben / wegsichern (das kann aber auch kontraproduktiv sein und verbraucht ggf. auch Schreibzyklen auf der SD-Karte)
- INITIALIZED-notify erstellen, das feste Initialwerte vergibt,
- checken, warum ggf. was anderes irgendwoher in den dummy geschrieben wird;
- auf dummy möglichst ganz verzichten (mein Favorit...)
(-there's more than...")

[enno]

Moin

bei mir geht es manchmal, aber wenn der Rechner mehrfach hintereinander startet sind die Werte oft weg. Daher habe ich wie Beta-User vorschlägt ein DOIF bei Neustart und eine USV (Gürtel und Hosenträger )

Code Auswählen Erweitern

defmod di_Set_Neustart DOIF ([global:"INITIALIZED"])(set KWL_Timer_Dummy off,set TYPE=CUL_HM:FILTER=NAME=.*_Rauchmelder statusRequest)


Gruss
  Enno

[Beta-User]

...das wäre was neues, DOIF kann ich nicht, daher hatte ich ein notify vorgeschlagen... (diese Klammern für einfachste Übungen sind doch grausam, oder...?)

Code Auswählen Erweitern

defmod n_Set_Neustart notify global:INITIALIZED set KWL_Timer_Dummy off,set TYPE=CUL_HM:FILTER=NAME=.*_Rauchmelder statusReques

(Wobei ich nicht sicher bin, ob das mit dem statusRequest sein müßte, v.a., wenn man HMinfo eingerichtet hat).

[Damian]

Ich sichere bei mir regelmäßig für solche Ausfälle die Zustände mit:

Code Auswählen Erweitern

defmod di_save DOIF {[:00];;fhem"save"}

Über den Ausfall der sd-Karte mache ich mir bei dieser Häufigkeit keine Gedanken.

[McShire]

Hallo,
kann man nicht die Initialwerte einfach mit set <dummy-name> <dummy-value> in die fhem.cfg schreiben?
das wäre aus meiner Sicht die einfachste und ressoucenschonende Lösung.
mfg
Werner

[Dracolein]

Moin

bei mir geht es manchmal, aber wenn der Rechner mehrfach hintereinander startet sind die Werte oft weg. Daher habe ich wie Beta-User vorschlägt ein DOIF bei Neustart und eine USV (Gürtel und Hosenträger )

Code Auswählen Erweitern

defmod di_Set_Neustart DOIF ([global:"INITIALIZED"])(set KWL_Timer_Dummy off,set TYPE=CUL_HM:FILTER=NAME=.*_Rauchmelder statusRequest)


Gruss
  Enno

Praxistaugliches Beispiel, das werde ich übernehmen, dankeschön.

[Beta-User]

...wobei das - möglicherweise ungewollt - etwas mehr "sichert"  ...
Jede Stunde statefile per at schaut auch nicht wild aus:

Code Auswählen Erweitern

define a7 at +*01:00 save statefile
Wer es "punktgenau" mag, muss dann halt zu einem Attribut greifen, siehe die ziemlich übersichtliche commandref zu at (wobei ich eher empfehlen würde, sowas nicht zwanghaft auf die genauen Uhrzeiten festzuzurren):

Code Auswählen Erweitern

define at2 at +*01:00 set Chime on-for-timer 1
attr at2 alignTime 00:00

Hallo,
kann man nicht die Initialwerte einfach mit set <dummy-name> <dummy-value> in die fhem.cfg schreiben?
das wäre aus meiner Sicht die einfachste und ressoucenschonende Lösung.
mfg
Werner

...mach das mal mit configDB...

Und NEIN: cfg-Editieren ist zwar möglich, aber eigentlich keine Option. Hände weg (für die, die nicht genau wissen, was sie tun)!

[Damian]

Es sind ja nicht nur Dummys, die falsche Zustände nach dem Neustart haben.

Es gibt z. B. auch HM-Komponenten, die nach einem Neustart falsche Zustände aufweisen können.

[Beta-User]

Deswegen auch der Hinweis auf HMinfo - was aber auch nichts hilft, wenn der Aktor seinen Zustand auch nicht mehr kennt...

[Damian]

Deswegen auch der Hinweis auf HMinfo - was aber auch nichts hilft, wenn der Aktor seinen Zustand auch nicht mehr kennt...

Das ist insb. beim batteriebetriebenen HM-MOD-EM-8 der Fall, dessen aktueller Zustand sich nicht abfragen lässt.

[Dracolein]

Wo ist mein Fehler?

Das notify funktioniert zuverlässig nach Systemstart und setzt die gesamte Befehlskette richtig um bis auf eine Ausnahme:
Der erste Befehl "set Badrolloautomatikschalter on" wird nicht ausgeführt, sondern statt dessen die gesamte Befehlskette als String auf dessen Reading "state" geschrieben.

Code Auswählen Erweitern


Internals:
   DEF        global:INITIALIZED set Badrolloautomatikschalter on, set Beschattungsautomatikschalter on, set Beschattungsstufe1 off, set Beschattungsstufe2 off, set Lauflichtschalter off, set Nachtlichtautomatikschalter on, set Rolloautomatikschalter on, set alleRollosAb off, set alleRollosAuf off, set alleRollosStop off, set dummy_Haustuerklingel off
   FUUID      61816e5a-f33f-4dec-1584-903ddac9a4efe83e
   NAME       notify_Set_Neustart
   NOTIFYDEV  global
   NR         152
   NTFY_ORDER 50-notify_Set_Neustart
   REGEXP     global:INITIALIZED
   STATE      2021-11-06 09:40:03
   TRIGGERTIME 1636188010.90023
   TYPE       notify
   READINGS:
     2021-11-06 09:40:02   state           active
     2021-11-06 09:40:03   triggeredByDev  global
     2021-11-06 09:40:03   triggeredByEvent INITIALIZED
Attributes:
   room       Befehle


[Beta-User]

Strichpunkt statt Komma...?

[MadMax-FHEM]

Strichpunkt statt Komma...?

Denke ich auch, siehe z.B.: https://wiki.fhem.de/wiki/Erste_Schritte_in_FHEM#Mehrere_Devices_schalten

Und je nachdem wo du eingibst (DEF oder RawDef) ein oder zwei Strichpunkte...

Gruß, Joachim

[Dracolein]

Vielen Dank, das war die Lösung.