ActionDetector und fhem.save

[volschin]

Hallo Martin,
an sich finde ich den ActionDetector ein sehr sinnvolles Device. Was mich für die Überwachung sehr stört ist, dass er sich über einen shutdown und restart nicht seine Daten merkt.

Wäre es nicht sinnvoll, da etwas zur Speicherung in der fhem.save zu ergänzen?

Gruß,
Veit 

[justme1968]

der action detector wertet nach dem start die readings der einzelnen devices aus die er überwacht. d.h. es kann zum teil auf alten werte zugreifen. da gab es mal eine längere Diskussion. mit martin drüber. bestimmt kann er sich erinnern und mehr sagen.

gruss
  andre

[martinp876]

Der Actiondetector wertet den Zeitstempel der letzten empfangenen message aus. Das steht in der gruppe "internals" und wird somit nicht gerettet.

fhem hat - wie sicher bekannt - 4 gruppen von daten
- attribute - werden von User explizit mit save gespeichert. sind "permanent". Nur in wenigen Fällen gibt es ein "autosave" - achtung bei Define.
- readings - werden in fhem.save gespeichert. fhem betreibt die Speicherung/Löschung automatisch
- internals - user-sichtbare Variablen die nicht gespeichert werden. Sie überleben keinen restart
- helper - unsichtbare variablen (also nicht im web-interface) - sonst wie internals

Man könnte das letzte Empfangsdatum also nach readings verschieben - dann würde es die meisten restarts überleben. Ich habe nicht vollständig nachvollzogen, wann das statefile geschrieben wird - bei den Registern, die dank readings Gruppe darin stehen, haben manchmal veraltete Werte.

Was Andre meint war sicher die Diskussion nach der ich den Status aufgeräumt habe.

hm - was ich machen könnte wäre, eine Kopie des Datums 'hidden' in Readings abzulegen. Sichtbar hat es dort eigentlich nichts verloren.
Ich werde noch einmal darüber nachdenken....

Gruss Martin

[justme1968]

hallo martin,

ich erinnere mich an die idee das der Actiondetector nach einem neustart alle readings des device durchgeht und sich den zeitstempel des neuesten readings als 'schätzung' für das letzte lebenszeichen nimmt. ohne extra etwas zu verschieben oder eine kopie anzulegen.

wenn der gefundene zeitstempel nicht älter ist als das konfigurierte intervall für das device kann man es glaube ich guten gewissens auf alive setzen, sonst wie bisher auf unknown.

gruss
  andre

[volschin]

Das hört sich für mich nach einem sehr validen Ansatz an.

[martinp876]

Andre,

das mit dem Zeitstempel geht so nicht, da es auch readings gibt, die nicht von einer message des Device abgeleitet sind sondern von einem assoziierten Device. Auch einige "set" beeinflussen Readings.

Gruss Martin

[justme1968]

es ist nicht perfekt. aber eine sehr gute erste näherung. auch die meisten readings die nicht direkt vom device kommen (wie z.b. durch average erzeugte) werden durch ein device reading getriggert und stehen fast immer in engen zeitlichen zusammenhang.

im schlimmsten fall kommt die dead meldung ein intervall zu spät. ich glaube das wäre sogar eine verbesserung gengenüber dem aktuellen zustand. wenn man fhem aus welchen gründen auch immer z.b. alle 24 stunden wieder neu startet würde glaube ich aktuell niemals ein dead erzeugt wenn das device ineravall > als 24 stunden ist weil fhem niemals ein komplettes intervall abwarten kann.

um das risiko noch weiter zu verkleinern könnte man das scannen auf eine liste mit definierten readings wie z.b. battery,cover,motion,alive und contact beschränken.

gruss
  andre

[volschin]

Hallo Martin, hallo Andre,
die Liste mit den definierten Readings wäre das schönste, wobei die relevanten Readings bei jedem Device etwas anders heißen.
Beim Thermostat habe ich z.B. festgestellt, dass er ein battery: ok nur mit der Änderung der desired temp schickt, im Winter eher kein Problem, in der Übergangszeit vielleicht schon.

Alle meine anderen Devices wären aber durch die kurze Liste von Andre schon erschlagen.

Gruß,
Veit 

[martinp876]

Hallo Andre,

das ist sogar aktuell drin (hatte es schon vergessen... werde alt)
es werden einige readings gezielt untersucht - und ggf der Zeittempel übernommen.
Dennoch werde ich es ändern - das mit dem ".protLastRec" reading ist noch präziser und obendrein einfacher.  Zu sehen ist es auch nicht - außer man schaltet showInternalValues an.

So gesehen ist die Frage, ob es eine merkliche Veränderung zum aktuellen Stand bringt. Der Code ist definitiv einfacher und etwas genauer.

Version 4377

Gruss Martin

[justme1968]

ich wusste doch das da was war

gruss
  andre

[LuckyDay]

bei einem shutdown restart die fhem.save einzulesen find ich ok,
was ist aber bei unkontrolierten absturz, bsp Stromausfall, kill fhem, aufhängen des kompleten systems?
da wird dann auch die fhem.save eingelesen und die ist uralt
da hätte ich lieber keine fhem.save

[justme1968]

selbst dann bist du niemals schlechter als ohne die start werte.

gruss
  andre

[volschin]

Warum ist die fhem.save dann uralt?

Bei mir wird sie anscheinend so alle paar Stunden aktualisiert. Das sagt zumindest der timestamp.

[martinp876]

Mal sammeln...

- mein fhem.save ist aktuell 13h alt. Ich denke fhem-hm-knecht hat recht, es wird "ereignis-getrieben" geschrieben. Falls es hier eine option gibt wäre ich interessiert.
- wenn fhem.save genutzt wird kann es also nur "zu alt" sein. Schlimmstenfalls wird also ein device als "dead" alarmiert, sollte aber 'unknown' sein.
- ich werde jetzt noch einbauen, dass ein device als unknown  signalisiert wird, wenn das reading im statefile zu alt ist und die Zeit seit "sys-start" noch in der Toleranz ist.  Dann sind wir wasserdicht - so lange keiner im statefile editiert.

Gruss Martin

[volschin]

Ja, es sieht so aus, als ob das durch bestimmte Ereignisse getriggert wird. Mein alter Timestamp war von gestern 20:02. Jetzt habe ich die Konfiguration eines Devices geändert gehabt und dann war der Timestamp 9:20 Uhr.

Gruß,
Veit