Hallo zusammen,
mit dem aktuellen Wartungsstand funktioniert das Rücksetzen des Watchdogs via "trigger watchdog ." nicht mehr..
Der Watchdog löst nur noch einmal aus ! Der Watchdog bleibt im Status triggered.
Konkret:
Kellertuer:any_open 00:00:30 Kellertuer:all_closed {if
(ReadingsVal('Wetterstation','temperature','') < 12 &&
ReadingsVal('FL.UG.tk.timer','state','') eq "inactive" &&
ReadingsVal('FL.EG.gong.mp3.muteswitch','state','') eq "off" &&
ReadingsVal('GA.timer','state','') eq "inactive")
{fhem('set FL.UG.tk.timer active ; set FL.EG.gong.led led orangeS 255');}
fhem('trigger Kellertuer.watchdog .');}
Ist das schon bekannt ?
EDIT:
# $Id: 91_watchdog.pm 12534 2016-11-09 18:22:23Z rudolfkoenig $ ==> OK
# $Id: 91_watchdog.pm 13020 2017-01-09 10:37:13Z rudolfkoenig $==> NOT OK
VG
Klaus
Habe das selbe Problem...
Anstelle von
trigger NAME .
habe ich jetzt solange
setstate NAME defined
Es gibt ein attr autoRestart, was mir heute aufgefallen ist, das setzt den watchdog wieder nach dem er getriggert wurde auf defined zurück
Gesendet von iPhone mit Tapatalk
Zitat von: Ma_Bo am 21 Januar 2017, 23:22:00
Es gibt ein attr autoRestart, was mir heute aufgefallen ist, das setzt den watchdog wieder nach dem er getriggert wurde auf defined zurück
Gut zu Wissen, ist das jetzt usus ?
...ging an mir vorüber ...
Das Attribut finde ich IMHO sinnvoller als trigger xxx .
VG
Klaus
Mal schauen ob sich Rudolf zu dem Thema meldet, ob es weiterhin mit trigger funktionieren soll oder ob es nur noch über das attr bzw. setstate xxx defined gehen soll.
Laut commandref soll es aber auch immer noch mit trigger xxx . funktionieren.
Gesendet von iPhone mit Tapatalk
Das tut es auch. setstate ist im Übrigen kein wirklich guter Weg. Das wird zwar oft in irgendwelchen Blogs genannt, sollte aber nicht verwendet werden.
Das genannte Attribut tut jedoch auch genau das, was es soll.
Zitat von: marvin78 am 22 Januar 2017, 07:16:46
Das tut es auch.
Das genannte Attribut tut jedoch auch genau das, was es soll.
Soll heißen, bei Dir geht trigger xxx . ?
Meine watchdogs, die ich noch nicht auf das Attribut autoRestart (ggf. auch nicht immer sinnvoll) habe, funktionieren alle mit trigger. Ich wüsste auch nicht, warum nicht.
Dann haben Ma_Bo und ich ein Problem..
Habe mal das Attribut gesetzt, allerdings habe ich ein paar watchdogs, wo das nicht sinnvoll ist ..
Habe gerade eben nochmal getestet, nach einmaligem auslösen:
Internals:
CMD {if
(ReadingsVal('Wetterstation','temperature','') < 12 &&
ReadingsVal('FL.UG.tk.timer','state','') eq "inactive" &&
ReadingsVal('FL.EG.gong.mp3.muteswitch','state','') eq "off" &&
ReadingsVal('GA.timer','state','') eq "inactive")
# Sound über FL.UG.tk.timer nur dann ausgeben, wenn der GA.timer und er selbst (2 Türen) nicht activ ist
# Alarmstatus wird nicht geprüft, da der Watchdog sowieso erst in 10 Minuten startet
{fhem('set FL.UG.tk.timer active ; set FL.EG.gong.led led orangeS 255');}
fhem('trigger Kellertuer.watchdog .');}
DEF Kellertuer:any_open 00:00:30 Kellertuer:all_closed {if
(ReadingsVal('Wetterstation','temperature','') < 12 &&
ReadingsVal('FL.UG.tk.timer','state','') eq "inactive" &&
ReadingsVal('FL.EG.gong.mp3.muteswitch','state','') eq "off" &&
ReadingsVal('GA.timer','state','') eq "inactive")
# Sound über FL.UG.tk.timer nur dann ausgeben, wenn der GA.timer und er selbst (2 Türen) nicht activ ist
# Alarmstatus wird nicht geprüft, da der Watchdog sowieso erst in 10 Minuten startet
{fhem('set FL.UG.tk.timer active ; set FL.EG.gong.led led orangeS 255');}
fhem('trigger Kellertuer.watchdog .');}
NAME Kellertuer.watchdog
NOTIFYDEV Kellertuer
NR 177
NTFY_ORDER 50-Kellertuer.watchdog
RE1 Kellertuer:any_open
RE2 Kellertuer:all_closed
STATE triggered
TO 30
TYPE watchdog
Readings:
2017-01-22 08:50:30 Activated activated
2017-01-22 08:51:00 Triggered triggered
2017-01-21 22:04:54 state defined
Attributes:
alias Kellertuer Watchdog
icon hourglass
room Flur
verbose 2
Auch nach Eingabe von:
trigger Kellertuer.watchdog .
bleibt der Watchdog auf triggered
Mit der 91_watchdog.pm vom November 2016 funktioniert es einwandfrei..
Zitat von: marvin78 am 22 Januar 2017, 07:16:46
Das tut es auch. setstate ist im Übrigen kein wirklich guter Weg. Das wird zwar oft in irgendwelchen Blogs genannt, sollte aber nicht verwendet werden.
Das genannte Attribut tut jedoch auch genau das, was es soll.
Laut dem Beitrag von Rudolf, sollte es aber kein Problem sein, mit "setstate watchdog defined"
https://forum.fhem.de/index.php/topic,43957.msg563781.html#msg563781
Zitat von: Rampler am 22 Januar 2017, 08:55:15
Habe gerade eben nochmal getestet, nach einmaligem auslösen:
Internals:
CMD {if
(ReadingsVal('Wetterstation','temperature','') < 12 &&
ReadingsVal('FL.UG.tk.timer','state','') eq "inactive" &&
ReadingsVal('FL.EG.gong.mp3.muteswitch','state','') eq "off" &&
ReadingsVal('GA.timer','state','') eq "inactive")
# Sound über FL.UG.tk.timer nur dann ausgeben, wenn der GA.timer und er selbst (2 Türen) nicht activ ist
# Alarmstatus wird nicht geprüft, da der Watchdog sowieso erst in 10 Minuten startet
{fhem('set FL.UG.tk.timer active ; set FL.EG.gong.led led orangeS 255');}
fhem('trigger Kellertuer.watchdog .');}
DEF Kellertuer:any_open 00:00:30 Kellertuer:all_closed {if
(ReadingsVal('Wetterstation','temperature','') < 12 &&
ReadingsVal('FL.UG.tk.timer','state','') eq "inactive" &&
ReadingsVal('FL.EG.gong.mp3.muteswitch','state','') eq "off" &&
ReadingsVal('GA.timer','state','') eq "inactive")
# Sound über FL.UG.tk.timer nur dann ausgeben, wenn der GA.timer und er selbst (2 Türen) nicht activ ist
# Alarmstatus wird nicht geprüft, da der Watchdog sowieso erst in 10 Minuten startet
{fhem('set FL.UG.tk.timer active ; set FL.EG.gong.led led orangeS 255');}
fhem('trigger Kellertuer.watchdog .');}
NAME Kellertuer.watchdog
NOTIFYDEV Kellertuer
NR 177
NTFY_ORDER 50-Kellertuer.watchdog
RE1 Kellertuer:any_open
RE2 Kellertuer:all_closed
STATE triggered
TO 30
TYPE watchdog
Readings:
2017-01-22 08:50:30 Activated activated
2017-01-22 08:51:00 Triggered triggered
2017-01-21 22:04:54 state defined
Attributes:
alias Kellertuer Watchdog
icon hourglass
room Flur
verbose 2
Auch nach Eingabe von:
trigger Kellertuer.watchdog .
bleibt der Watchdog auf triggered
Mit der 91_watchdog.pm vom November 2016 funktioniert es einwandfrei..
Ganz genau so ist es bei mir auch.
Zitat von: marvin78 am 22 Januar 2017, 08:39:28
Meine watchdogs, die ich noch nicht auf das Attribut autoRestart (ggf. auch nicht immer sinnvoll) habe, funktionieren alle mit trigger. Ich wüsste auch nicht, warum nicht.
Das kann ich NICHT bestätigen!
Interessanterweise trifft das nicht auf alle watchdogs/trigger zu.
Ich habe 2, bei denen es seit dem update definitiv nicht mehr funktioniert, während es bei 2 anderen (scheinbar) noch geht.
Das "autoRestart 1" ist zwar eine gute (Zusatz-)Lösung, um den watchdog nach dem Auslösen wieder "scharf" zu schalten, aber einen aktivierten Watchdog kann ich damit ja nicht vorzeitig zurücksetzen.
Hier ist was los...
Das "trigger w ." Feature ist mir der NOTIFYDEV Optimierungen "ueber Bord gegangen", da der Watchdog seine eigenen Events nicht mehr mitgekriegt hat. Habs wieder aktiviert, update ab morgen oder SVN.
Rudolf, kannst du mir bitte jetzt auch ein mal sagen, ob es mit "setstate watchdog defined" Probleme gibt oder ob man das bedenkenlos nutzen kann..?
Man liest immer verschiedene Meinungen dazu.
Grüße Marcel
Gesendet von iPhone mit Tapatalk
Zitat von: Ma_Bo am 22 Januar 2017, 13:58:04
Man liest immer verschiedene Meinungen dazu.
Hier gibt es eine aus erster Hand: https://forum.fhem.de/index.php/topic,43957.msg389003.html#msg389003
Naja, da steht zuerst, dass das mit setstate nie wirklich von Rudolf implementiert wurde und durch Zufall klappen kann, später schreibt er dann selber, dass man mit setstate watchdog defined den watchdog zurücksetzen kann, das verwirrt mich jetzt wieder.
Gesendet von iPhone mit Tapatalk
Da ich nicht vorhabe watchdog umzubauen, bleibt baW das nicht dokumentierte Feature mit dem "setstate defined" bestehen.