Hallo,
habe ein Dummy der bekommt per Tasker einen Status dieser wird alle 30 min gesetzt absend oder present.
Im Dummy habe ich event update auf .* für das log !
Ich möchte nun ( per Watchdog ?? ) den Dummy überwachen. Wenn der letzte state des Dummys länger als 40 minuten zurückliegt soll ein Befehlt ausgefügt werden. ( set alarmon on )
Wie kann ich das realisieren ?
Hintergrund. Ich will verhindern wenn das Handy aus geht ( akku leer ) das das gerät im present Status bleibt.
Hi,
schau mal nach ReadingsAge
ZitatReadingsAge(<devicename>,<reading>,<defaultvalue>)
gibt das Alter des Readings in Sekunden zurück.
Gruß Otto
Oder DOIF mit wait und do resetwait. Beispiel im CommandREF https://fhem.de/commandref_DE.html#DOIF_do_resetwait
hm doif finde ich noch zu kompliziert ;) Das ReadingsAge ist schon nicht schlecht kann ich das mit einem watchdog verbinden? Oder wie stelle ich das an das er erst etwas macht wenn es 40 Minuten zurückliegt ?
DOIF ist in dem Fall viiieeeel einfacher. Und über den Link, den ich gegeben habe, ist schon der richtige 3-Zeiler. Musst nur das Device, den Befehl und die Dauer anpassen. Einfacher gibt es nicht.
Hi,
ich finde den Vorschlag mit DOIF auch kurz und knackig.
watchdog (https://fhem.de/commandref_DE.html#watchdog)reagiert auf events, das könnte man dann ohne readingsage ähnlich machen, wenn der state für 40 min nicht gesetzt wurde:
define w watchdog device 00:40:00 SAME <mache was>
Schau Dir aber die Doku zu watchdog gut an.
Insofern war meine Überlegung mit readingsage vielleicht zu knapp gedacht.
Gruß Otto
define check_chris-status DOIF ([chris_status])(set chris_status absent)
attr check_chris-status wait 2400
attr check_chris-status do resetwait
Das komplizierte ist nun noch das ich ja den Status von present in absent ändern will. Also bei absent wenn sich nichts ändert soll nichts passieren. Nur wiederhohlt sich das ganze ja wieder? Kan das Probleme machen?
chris status:
present nach 40 minuten nicht geändert = chris_status absent
Wenn das Handy dann wieder gestartet wurde wird ja der richtige Status gesetzt :)
define check_chris-status DOIF ([chris_status] eq "present"])(set chris_status "absent")
attr check_chris-status wait 2400
attr check_chris-status do resetwait
Danke aber nu gekomme ich sowas nach dem Speichern :
check_chris_status DOIF: right bracket without left bracket: ]
Hab es mal so gemacht und es klappt wohl :
define check_chris_status DOIF ([chris_status] eq "present")(set chris_status absent)
attr check_chris_status do resetwait
attr check_chris_status room Anwesenheit
attr check_chris_status wait 30
Mein Schuld
define check_chris-status DOIF ([chris_status] eq "present") (set chris_status "absent")
und die attr
Damit es funktioniert, muss sich aber den STATE von chris_status regelmässig aktualisieren und entspr. ein Event generieren (gilt auch für Watchdog)
Danke hatte es schon hinbekomen.
Ja das Handy macht alle 30 Minuten einen WLAN check und setzt den Status neu. Taucht nur im log nicht auf wegen change_update .*.
Wenn ich nun alle 40 min Prüfe kann ich abfangen wenn das Handy mal leer ist und kein Status mehr schickt.
Du meinst event-on-update-reading?
ja genau sonst ist das Log zugemüllt :)
Zitat von: ChrisW am 14 August 2017, 23:07:26
Taucht nur im log nicht auf wegen change_update .*.
Zitat von: amenomade am 14 August 2017, 23:27:42
Du meinst event-on-update-reading?
Zitat von: ChrisW am 15 August 2017, 07:42:38
ja genau sonst ist das Log zugemüllt :)
oder doch eher event-on-change ::)
Eigentlich wird die Log mehr gemüllt mit event-on-update-reading als mit event-on-change-reading... Das event-on-update-reading brauchst aber hier doch.
Kann man ein "list chris_status" sehen?
Wozu braucht es event-on-update-reading?
Ich selbst arbeite bei presence generell mit event-on-change-reading. Ok hier in dem Fall wo der presencegeber nochmal überwacht wird (was ich nie so richtig verstanden habe) wäre das kontraproduktiv.
Also ohne event-on-change-reading würde das presence Geräte bei jedem update auch einen event triggern. Das wäre doch hier völlig ok!?
Gruß Otto
Das hat er beschrieben: sein Handy meldet "present" auf einem Dummy per Tasker. Und er will, dass wenn das Handy nix mehr meldet, das Dummy automatisch auf "absent" springt.
Zitat von: amenomade am 15 August 2017, 17:20:09
Das hat er beschrieben: sein Handy meldet "present" auf einem Dummy per Tasker. Und er will, dass wenn das Handy nix mehr meldet, das Dummy automatisch auf "absent" springt.
Ist das die Antwort auf meine Frage?
Zitat von: Otto123 am 15 August 2017, 15:13:15
Wozu braucht es event-on-update-reading?
Ich habe folgendes verstanden und nachgebaut
defmod check_chris_status DOIF ([chris_status] eq "present")(set chris_status absent)
attr check_chris_status do resetwait
attr check_chris_status room Test
attr check_chris_status wait 30
defmod chris_status dummy
attr chris_status room Test
set chris_status present
mache ich nicht innerhalb von 30 wieder ein set chris_status present dann geht chris_status auf absent. So soll es doch sein? Keine weiteren attr kein Müll im Log.
Gruß Otto
Zitatmache ich nicht innerhalb von 30 wieder ein set chris_status present dann geht chris_status auf absent.
Ja, aber machst Du doch innerhalb von 30 wieder ein set chris_status present, dann geht chris_status trotzdem auf absent, oder?
nein warum sollte es? Der wait timer wird zurück gesetzt, kann man im DOIF gut beobachten.
Ohne Event?
natürlich erzeugt set chris_status present einen event. Warum sollte er nicht? Ich habe kein event-on-change-reading gesetzt.
Ah ja ok, sorry. "Wenn nicht gesetzt, erzeugt jede Veränderung eines "readings" ein Ereignis".
Oha also hier mal ein list:
Internals:
CFGFN ./FHEM/anwesenheit.cfg
CHANGED
NAME chris_status
NR 180
STATE present
TYPE dummy
READINGS:
2017-08-15 20:40:15 state present
Attributes:
event-on-change-reading .*
room Anwesenheit
userattr Handys Handys_map structexclude
das event-on-change-reading .* habe ich da Tasker im Handy alle 30 Minuten den nochmal das aktuelle wifi checkt und immer wieder sonst alle 30 min ein "present" schreibt.
Ich will mein Dummy log aber aufgeräumt haben also nur absent und present ;)
Also bisher scheint es zu klappen in meinem Test.
Sorry aber das funktioniert nicht. Keine Hände keine Kekse - oder kein Event kein resetwait. Damit funktioniert das DOIF nicht.
Damit funktioniert aber gar nix. Dann musst Du eben noch einen Zwischenschritt ein legen, z.B. ein separates reading zum loggen, oder ein separates reading fürs DOIF. Egal wie rum.
Aber wenn Du anderer Meinung bist dann gut, sag später nicht ich hätte es Dir nicht gesagt ;D
Gruß Otto
hmm ich beobachte es mal bei meinem Test hat es geklappt.
Sonst schmeiß ich das event-on-change-reading . halt raus .. so oft guck ich auch nicht in das Log
Brauchte dies auch mal für ein Szenario bei meiner Alarmanlage, da die Bewegungsmelder keinen Zustand "auf/zu" oder "an/aus" haben. Dieser löst nur das Alarmevent aus und generiert über eine Action-URL ein Event nach Fhem.
Da nun die Alarmmeldung beim Dummy nicht auf in den normalen Zustand per Action-URL (Lupus XT1plus) zurücksetzen kann, habe ich das mit dieser DOIF Definition gelöst. Klappt perfekt. :) Nur eine kleine Anmerkung zum wait: Die hier genannten 30 Minuten wären dann mit 1800 zu setzen. Die wait-Angabe sind Sekunden nicht Minuten.
Da mein Bewegungsmelder nach Alarmauslösung 3 Minuten in den Ruhezustand wechselt, setze ich die das Event nach 180.
Hier noch meine Define: (falls es einer mal braucht)
defmod Reset_Zustand_d_Hauseingang_Bewegungsmelder DOIF ([d_Hauseingang_Bewegungsmelder] eq "aus")(set d_Hauseingang_Bewegungsmelder ein)
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder DbLogExclude .*
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder alias Bewegungsmelder Haustür zurücksetzen - No Alarm
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder devStateIcon cmd_1:10px-kreis-gruen cmd_2:10px-kreis-red
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder do resetwait
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder room 95-Alarmanlage
attr Reset_Zustand_d_Hauseingang_Bewegungsmelder wait 180