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
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
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
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
Das hört sich für mich nach einem sehr validen Ansatz an.
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
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
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
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
ich wusste doch das da was war :)
gruss
andre
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
selbst dann bist du niemals schlechter als ohne die start werte.
gruss
andre
Warum ist die fhem.save dann uralt?
Bei mir wird sie anscheinend so alle paar Stunden aktualisiert. Das sagt zumindest der timestamp.
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
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
Das habe ich gerade in einer alten Diskussion gefunden, aber noch nicht getestet.
ZitatMit der Definition wird die fhem.save alle 60 Minuten automatisch gespeichert. Das sollte wohl reichen, um nicht wieder zwei Stunden manuell Variablen zu setzen. :-D
define AutoSave at +*01:00:00 { \
fhem (" { WriteStatefile() } ") ;; \
}
Gruß
Veit
Punkt 1: Der Code war etwas zu umständlich. Einfacher:
define AutoSave at +*01:00:00 { WriteStatefile() }
Tut bei mir, was es soll.
Punkt 2: Der ActionDetector greift jetzt den aktuellen Status ab, nutzt aber anscheinend für seine eigenen Daten als Basis nicht die fhem.save. Dort sind die Daten aber drin.
setstate ActionDetector alive:14 dead:0 unkn:5 off:0
setstate ActionDetector 2013-12-14 10:57:55 state alive:14 dead:0 unkn:5 off:0
setstate ActionDetector 2013-12-14 10:57:55 status_Fenster.Bad unknown
setstate ActionDetector 2013-12-14 10:57:55 status_Fenster.Kueche unknown
setstate ActionDetector 2013-12-14 10:57:55 status_Fenster.Schlafen.R unknown
setstate ActionDetector 2013-12-14 10:57:55 status_Fenster.Wohnen.R unknown
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Bad alive
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Kueche alive
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Schlafen.L alive
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Schlafen.R alive
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Wohnen.L alive
setstate ActionDetector 2013-12-14 10:57:55 status_HZ_Regler.Wohnen.R alive
setstate ActionDetector 2013-12-14 10:57:55 status_Rauchmelder.Flur alive
setstate ActionDetector 2013-12-14 10:57:55 status_Rauchmelder.Schlafen alive
setstate ActionDetector 2013-12-14 10:57:55 status_Rauchmelder.Wohnen alive
setstate ActionDetector 2013-12-14 10:57:55 status_Schuhtuer.Flur unknown
setstate ActionDetector 2013-12-14 10:57:55 status_Thermostat.Bad alive
setstate ActionDetector 2013-12-14 10:57:55 status_Thermostat.Kueche alive
setstate ActionDetector 2013-12-14 10:57:55 status_Thermostat.Schlafen alive
setstate ActionDetector 2013-12-14 10:57:55 status_Thermostat.Wohnen alive
setstate ActionDetector 2013-12-14 10:57:55 status_Tuer.Flur alive
Als Ergebnis schickt mir Prowl beim Neustart 39 Messages, obwohl sich der Status nicht geändert hat.
Das ist mein Notify:
define alive notify ActionDetector.* {myProwl('Alarm: Änderung im ActionDetector',"%",1)}
Lässt sich da was machen?
Gruß,
Veit
ok - ist ein 'händischer' Aufruf. Das geht sicher. Dauert auch nicht einmal so lange, ein paar Hundert ms. Hängt natürlich von der Systemgrösse. Man könnte es im batch schreiben lassen - wäre ideal für so einen Hintergrund job. das kostet kleiner 50ms "outage" für das System.
define AutoSave at +*01:00:00 { \
{BlockingCall("WriteStatefile", "","", 30,"", "")}\
}
Gruss Martin
Hallo Veit,
So, jetzt habe ich das Problem gefunden.... der action-detector räumt immer auf und löscht nicht eingetragene Readings.
werde ich ändern....
version 4380 steht bereit
das notify könntest du spezifischer machen
define alive notify ActionDetector:.status.* {myProwl('Alarm: Änderung im ActionDetector',"%",1)}
attr ActionDetector event-on-change-reading .*
hast du sicher schon
Gruss Martin
Hallo Martin,
großartig. Ich habe mir die Datei gleich zum Testen aus dem SVN gezogen und eingespielt. Shutdown & restart. Alle Daten sind da und keine Alarmmeldung ging raus.
Ich finde es immer wieder toll, was Du hier auf die Beine stellst.
Ganz herzlichen Dank.
Gruß
Veit
Hallo zusammen
mir ist bewusst, dass der Thread schon ein bisschen aelter ist, aber ich moechte auf Basis der ActionDetector - Dead Meldungen einem dummy setzen.
Hierzu habe ich folgenden Code ausgebruetet:
define DeadDeviceIndicatorNotify notify ActionDetector:.status.* {\
if (substr(Value("ActionDetector"), (index(Value("ActionDetector"), "dead:")+5), 1) > 0) {\
fhem "set DeadDeviceIndicator dead";;\
fhem "set PushoverWarning msg 'Deeke Home-ActionDetector' 'Dead device detected' '' 1 ''";;\
Log 3, "Dead Device warning sent via Pushover" ;;\
};;\
else {\
fhem "set DeadDeviceIndicator alive";;\
};;\
}
Doch irgendwie scheine ich den Trigger Befehl dafuer falsch zu verwenden. :-[
Habe die Befehle
trigger ActionDetector alive:4 dead:1 unkn:0 off:0
trigger ActionDetector state alive:4 dead:1 unkn:0 off:0
trigger ActionDetector STATE alive:4 dead:1 unkn:0 off:0
trigger ActionDetector status alive:4 dead:1 unkn:0 off:0
ohne Ergebnis durchprobiert.
Habt Ihr eine Idee, wie ich den Code testen kann oder ob er ueberhaupt funktionieren kann?
Gruss
Sailor
Das wundert mich nicht. Das Notify erwartet für ein Einzeldevice ein dead oder alive. Dafür ist das status.* So muss dann auch getriggert werden.
Gruß
Veit
Hallo Veit
OK Danke... So weit verstanden, aber selbst wenn ich
trigger BR_Window alive:dead
trigger BR_Window alive:no
versuche, steht im ActionDetector-2014.log nichts neues.
Ich meine gelesen zu haben, dass der Action Detector die Meldungen nur zyklisch abfragt, so dass der trigger auf Device-Ebene schlichtweg ueberlesen wird.
Folglich kommt der entsprechende Code daher auch nicht zum tragen:
define DeadDeviceIndicatorNotify notify ActionDetector:.status.* {\
fhem "set PushoverWarning msg 'ActionDetector' 'test message' '' 1 ''";;\
}
"Was tun" sprach Zeus
Sailor
Der Actiondetector fragt nicht ab, ob im Device dead/alive steht sondern schreibt es rein. Hierzu wird jeweils der Zeitstempel der letzten receivemessage geprueft.
Wenn du ein dead provizieren willst solltest du einfach actCycle auf einen kleinen wert setzen (00:01) . Die Pruefintervale des ActionDetector legst du in dessen Attribut actCycle fest.
das
if (substr(Value("ActionDetector"), (index(Value("ActionDetector"), "dead:")+5), 1) > 0) {\
wuerde ich so schreiben
if (Value("ActionDetector") !~ m/dead:0 /) {\
sollte schneller gehen und auch beruecksichtigen, dass 10 und mehr devices tot sind.
und den trigger
define DeadDeviceIndicatorNotify notify ActionDetector:.*alive:.* {\
Gruss Martin
Hallo Martin,
danke für Deiien Hilfe damals. :)
Habe Deinen Code verwendet und es hat über den letzten Zeitraum von 3 Monaten auch sehr gut geklappt.
Die Meldungen kommen durch, wenn auch manchmal etwas unbegründet. :o
Um herauszufinden welche(s) Gerät(e) eigentlich den DeadDevice-Trigger ausgelöst haben, wäre es wünschenswert, den entsprechenden Gerätenamen mit in der Message zu übertragen.
Wie komme ich also an dieses Array an Variablen. Im ActionDetector selbst stehen ja nur die Zahlen und der Befehl "list ActionDetector" gibt mir diese nicht im Einzelnen als Variable wieder.
Und mit dem Befehl "get ERRactNames" unter HMInfo komme ich nicht ganz klar.
Gruß
Sailor
das ist aktuell nicht wirklich eingebaut. Also habe ich ein neues Kommando eingebaut. Ab morgen also
get ActionDetector listDevice # returns all assigned entities
get ActionDetector listDevice notActive# returns entities which habe not status alive
get ActionDetector listDevice alive # returns entities with status alive
get ActionDetector listDevice unknown # returns entities with status unknown
get ActionDetector listDevice dead # returns entities with status dead
in HMInfo kannst du auch
InternalVal("hm","ERRactNames","")
nutzen.
Super ... Danke! :D
Bin schon gespannt!
Gruss
Sailor
Hallo Martin
habe gerade ein "update force" gefahren um das CUL_HM auf den neusten Stand zu bringen.
Aber irgendwie nimmt er die "get ActionDetector..." Befehle nicht an.
Habe ich einen Fehler gemacht? :o
Gruss
Sailor
der ActionDetector braucht das Attribut model ActionDetector. Das sollte eigentlich automatisch gesetzt werden. Passiert dies auch? Wenn nicht trage es ein.
Du hast einen update gemacht? Auch HMConfig ist sicher neu?
Hallo Martin
Folgender Versionsstand
# $Id: HMConfig.pm 6044 2014-06-03 18:18:26Z martinp876 $
# $Id: 10_CUL_HM.pm 6054 2014-06-04 07:43:35Z martinp876 $
attr ActionDetector model ActionDetector liess sich im Frontend nicht auswaehlen. Habe es daher manuell ind die fhem.cfg eingetragen.
Der gesamte Eintrag sieht jetzt wie folgt aus:
###START########## Initialize ActionDetector to process KeepAlive Signals ####################################START####
define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 600
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector
define FileLog_ActionDetector FileLog ./log/ActionDetector-%Y.log ActionDetector
attr FileLog_ActionDetector archivedir /var/media/ftp/SEAGATE-ST3500630A-01/fhemlog-archive
attr FileLog_ActionDetector logtype text
attr FileLog_ActionDetector nrarchive 1
attr FileLog_ActionDetector room Logs
####END########### Initialize ActionDetector to process KeepAlive Signals #####################################END#####
Dennoch ergibt der Befehl
get ActionDetector listDevice
die Meldung
Unknown argument listDevice, choose one of cmdList param saveConfig
"Was tun" sprach Zeus... ???
Gruss
Sailor
ZitatHabe es daher manuell ind die fhem.cfg eingetragen.
anschliessend sicherlich auch ein rereadcfg oder besser noch shutdown restart gemacht.
Aber natuerlich.... nicht :o
Danke Frank! Manchmal sieht man den Wald vor lauter Baeume nicht!
Jetzt gehts!
Mal schauen ob der Code funktioniert.
####START######### DeadDeviceIndicator on "dead" if ActionDetector shows at least 1 dead device ###############START####
define DeadDeviceIndicatorNotify notify ActionDetector:.*alive:.* {\
if (Value("ActionDetector") !~ m/dead:0 /) {\
my $InActiveDeviceList = fhem "get ActionDetector listDevice notAlive";;\
my $InActiveDeviceString = "Dead device(s) detected: " . $InActiveDeviceList;;\
fhem "set PushoverWarning msg 'Deeke Home-ActionDetector' '$InActiveDeviceString' '' 1 ''";;\
Log 3, "Dead Device warning sent via Pushover for " . $InActiveDeviceList;;\
}
#####END########## DeadDeviceIndicator on "dead" if ActionDetector shows at least 1 dead device ################END#####
Irgendwie muss man wohl allen Uebels auf ein totes Device warten.
Oder man provoziert eines, indem man einen Sensor aus dem Verkehr zieht! ;D
"Schau mer mal, dann seh ma scho" - Zitat aus aktuellem Anlass
Gruss
Sailor
get ActionDetector listDevice scheint jetzt zu funktionieren.
Zum Testen, baue ein Eigenes:
define td CUL_HM 554433
attr td actCycle 000:01
durch das setzen des Attributs actCycle kannst du jede entity dem ActionDetector zuweisen.
nach 1 min wird dieses Device auf dead gehen (berücksichtige den poll-zyklus des ActionDetector!)
Optionen des listDevice sind [alive|unknown|dead|notAlive]
notActive gibt es nicht
Hallo Martin
Danke fuer Deine Tipps!
Den Code musste ich nochmal um den fhem "" - Befehl ergaenzen. :o
Und dann hat es auch mit Deinem Test Device funktioniert!
Die Pushover Nachrichten kommen wie gewuenscht mit Namen des inaktiven Devices... Was will man mehr? ;D
Sind die "get"-Befehle eine Ergaenzung des Wikis fuer den ActionDetector wert? - Dann kuemmere ich mich drum.
Zusaetzlich kann ich ja noch einen Eintrag mit meinem Code in der Rubrik "Code Snipplets" machen.
Gruss
Sailor