DOIF neue Features (Sleep-Alternative)

[Virsacer]

Eins meiner DOIFs hat heute morgen "Mist" gebaut:

Dabei handelt es sich um einen "Watchdog", der prüft, ob ein State bei set_x hängen bleibt und nach einer Minute den Befehl nochmal abschickt.
Allerdings hat er jetzt den Befehl für den vorherigen Zustand abgeschickt und jede Minute wiederholt
Hat sich da mit der neuen Version was geändert?

Ich konnte jetzt aber auch noch nicht prüfen, ob sich vielleicht am Device was geändert hat...

[Virsacer]

Also ich habs jetzt nochmal getestet:
Mit der vorherigen Version von DOIF funktionierts einwandfrei...

Ich hab jetzt eine zusätzliche if-Abfrage eingebaut, ob "set_" tatsächlich noch im Status enthalten ist
Damit sollte es auch in der neuen Version funktionieren - das seh ich dann morgen bzw. wenn der Status das nächste mal hängen bleibt

[Damian]

Also ich habs jetzt nochmal getestet:
Mit der vorherigen Version von DOIF funktionierts einwandfrei...

Ich hab jetzt eine zusätzliche if-Abfrage eingebaut, ob "set_" tatsächlich noch im Status enthalten ist
Damit sollte es auch in der neuen Version funktionieren - das seh ich dann morgen bzw. wenn der Status das nächste mal hängen bleibt

Was ist bei dir die vorherige Version von DOIF?

[Virsacer]

Vorherige Version ist

Code Auswählen Erweitern

trunk/fhem@8432

Und neue Version ist

Code Auswählen Erweitern

trunk/fhem@9184

[Damian]

Vorherige Version ist

Code Auswählen Erweitern

trunk/fhem@8432

Und neue Version ist

Code Auswählen Erweitern

trunk/fhem@9184

Bei einer Fehlerbeschreibung musst du am besten ein list des Moduls im Fehlerzustand hier posten, damit ich ein Fehlverhalten analysieren kann.

Gruß

Damian

[All-Ex]

Danke für das Update 

Alles läuft, nur ein DOIF, das sich selbst abschalten soll,  macht Probleme. Ich habe das nun auf diesen Einzeiler reduziert und erhalte den Fehler "error: Wrong timespec":

Code Auswählen Erweitern

define test3.doif DOIF ([+[1]:17])(attr test3.doif disable 1)

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ([+[1]:17])(attr test3.doif disable 1)
   NAME       test3.doif
   NR         642
   NTFY_ORDER 50-test3.doif
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2015-09-01 20:17:00   cmd_event       timer_1
     2015-09-01 20:17:00   cmd_nr          1
     2015-09-01 20:17:00   state           cmd_1
     2015-09-01 20:17:00   timer_1_c1      error: Wrong timespec : either HH:MM:SS or {perlcode}
   Devices:
   Do:
     0:
   Itimer:
   Realtime:
     0          00:00:00
   State:
   Time:
   Timecond:
   Timer:
     0          0
   Timerfunc:
Attributes:
   disable    1

Wenn ich disable 0 statt disable 1 setze, funktioniert es:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ([+[1]:24])(attr test3.doif disable 0)
   NAME       test3.doif
   NR         642
   NTFY_ORDER 50-test3.doif
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2015-09-01 20:24:00   cmd_event       timer_1
     2015-09-01 20:24:00   cmd_nr          1
     2015-09-01 20:24:00   state           cmd_1
     2015-09-01 20:24:00   timer_1_c1      01.09.2015 21:24:00
   Condition:
     0          DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0:
       0          attr test3.doif disable 0
   Helper:
     globalinit 1
     last_timer 1
     sleeptimer -1
   Itimer:
   Realtime:
     0          21:24:00
   State:
   Time:
     0          +[1]:24
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   disable    0

Getestet habe ich mit # $Id: 98_DOIF.pm 9184 2015-08-31 18:35:06Z damian-s $

Sollte das funktionieren oder soll ich das ganze ohne ein "Selbstabschaltungs-DOIF" lösen?

Grüße,
Alex

[Damian]

Danke für das Update 

Alles läuft, nur ein DOIF, das sich selbst abschalten soll,  macht Probleme. Ich habe das nun auf diesen Einzeiler reduziert und erhalte den Fehler "error: Wrong timespec":

Code Auswählen Erweitern

define test3.doif DOIF ([+[1]:17])(attr test3.doif disable 1)

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ([+[1]:17])(attr test3.doif disable 1)
   NAME       test3.doif
   NR         642
   NTFY_ORDER 50-test3.doif
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2015-09-01 20:17:00   cmd_event       timer_1
     2015-09-01 20:17:00   cmd_nr          1
     2015-09-01 20:17:00   state           cmd_1
     2015-09-01 20:17:00   timer_1_c1      error: Wrong timespec : either HH:MM:SS or {perlcode}
   Devices:
   Do:
     0:
   Itimer:
   Realtime:
     0          00:00:00
   State:
   Time:
   Timecond:
   Timer:
     0          0
   Timerfunc:
Attributes:
   disable    1

Wenn ich disable 0 statt disable 1 setze, funktioniert es:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ([+[1]:24])(attr test3.doif disable 0)
   NAME       test3.doif
   NR         642
   NTFY_ORDER 50-test3.doif
   STATE      cmd_1
   TYPE       DOIF
   Readings:
     2015-09-01 20:24:00   cmd_event       timer_1
     2015-09-01 20:24:00   cmd_nr          1
     2015-09-01 20:24:00   state           cmd_1
     2015-09-01 20:24:00   timer_1_c1      01.09.2015 21:24:00
   Condition:
     0          DOIF_time_once($hash,$hash->{timer}{0},$wday,"")
   Days:
   Devices:
   Do:
     0:
       0          attr test3.doif disable 0
   Helper:
     globalinit 1
     last_timer 1
     sleeptimer -1
   Itimer:
   Realtime:
     0          21:24:00
   State:
   Time:
     0          +[1]:24
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   disable    0

Getestet habe ich mit # $Id: 98_DOIF.pm 9184 2015-08-31 18:35:06Z damian-s $

Sollte das funktionieren oder soll ich das ganze ohne ein "Selbstabschaltungs-DOIF" lösen?

Grüße,
Alex

Bei mir läuft die Syntax ([+[1]:17]) mit der aktuellen Version ohne Probleme. Allerdings ist die Angabe nicht gerade sinnvoll, denn stündlich um 17 Minuten nach voller Stunde lässt sich einfacher definieren mit [:17]

Kurzfristig disablen kann man jetzt mit set <modulname> disable.  Mit attr <modulname> disable 1 wird das Modul jetzt komplett deaktiviert. EDIT: Das wird wohl hier das Problem sein.


Steht aber alles in der aktuellen Commandref des Moduls.

Gruß

Damian

[Damian]

Bei mir läuft die Syntax ([+[1]:17]) mit der aktuellen Version ohne Probleme. Allerdings ist die Angabe nicht gerade sinnvoll, denn stündlich um 17 Minuten nach voller Stunde lässt sich einfacher definieren mit [:17]

Kurzfristig disablen kann man jetzt mit set <modulname> disable.  Mit attr <modulname> disable 1 wird das Modul jetzt komplett deaktiviert. EDIT: Das wird wohl hier das Problem sein.


Steht aber alles in der aktuellen Commandref des Moduls.

Gruß

Damian

Ich habe das Problem gefixt. Dennoch sollte man aus dem Code heraus ein DOIF-Modul per set <DOIF-Modul> disable deaktivieren, dadurch ändert sich im Gegensatz zum Deaktivieren per Attribut nicht die Konfiguration (rotes Fragezeichen).

Ein dauerhaftes Deaktivieren eines DOIF-Moduls sollte man dagegen per Attribut disable vornehmen - das Modul reagiert dann auf keine Trigger und braucht weniger Performance.

Gruß

Damian

[Brockmann]

Ein dauerhaftes Deaktivieren eines DOIF-Moduls sollte man dagegen per Attribut disable vornehmen - das Modul reagiert dann auf keine Trigger und braucht weniger Performance.

Was sind dann die Schritte, um es wieder in Betrieb zu nehmen? Hatte das gerade (allerdings noch nicht mit der aktuelle DOIF-Version), dass ich ein rein zeitgesteuertes DOIF nach ein paar Monaten wieder mal verwenden wollte. Also das disable-Attribut gelöscht (nicht auf Null gesetzt, sondern direkt gelöscht). Danach waren aber immer noch die alten Timer von vor Monaten drin und aktualisierten sich auch nicht mehr. Erst das Erneuern der Definition (-> "initialized") brachte dann auch wieder aktuelle Timer.

Code Auswählen Erweitern


([07:30|1])(set ...)
DOELSEIF([12:30|1])(set ...)


[Damian]

Was sind dann die Schritte, um es wieder in Betrieb zu nehmen? Hatte das gerade (allerdings noch nicht mit der aktuelle DOIF-Version), dass ich ein rein zeitgesteuertes DOIF nach ein paar Monaten wieder mal verwenden wollte. Also das disable-Attribut gelöscht (nicht auf Null gesetzt, sondern direkt gelöscht). Danach waren aber immer noch die alten Timer von vor Monaten drin und aktualisierten sich auch nicht mehr. Erst das Erneuern der Definition (-> "initialized") brachte dann auch wieder aktuelle Timer.

Code Auswählen Erweitern


([07:30|1])(set ...)
DOELSEIF([12:30|1])(set ...)


Die Funktionalität des alten Moduls mit Attribut disable entspricht der neuen Funktionalität mit set ... disable.

Das Aktivieren des Moduls mit einem gesetzten disable-Attribut wird durch das Löschen des Attributs mit deleteattr erreicht - beim set ... disable mit set ... initialize.

Gruß

Damian

[Ralli]

Ein attr ... disable 0 funktioniert nicht mehr zum "Reaktivieren" bzw. Initialisieren nach einem attr ... disable 1 ?

[Damian]

Ein attr ... disable 0 funktioniert nicht mehr zum "Reaktivieren" bzw. Initialisieren nach einem attr ... disable 1 ?

Kann ich nicht bestätigen, wenn es eine Aussage ist.
Doch, wenn es eine Frage ist.

kurzum:

attr ... disable 0 bewirkt das Gleiche wie deleteattr ... disable.

Gruß

Damian

[moonsorrox]

Hallo Damian, könntest du mal hier drauf schauen und mir einen Tipp geben..?

[Virsacer]

Also irgendwas stimmt mit der neuen Version (also rev9184 bzw. rev9193) nicht:
Ich hab in meinem DOIF

Code Auswählen Erweitern

([Shutter] =~ /set_\d+/) als Bedingung. Attribute sind "do always" und "wait 60".
Der Timer wird korrekt gestartet, aber anscheinend nicht gestoppt, wenn die Bedingung nicht mehr erfüllt ist:

Device	Shutter	2015-09-03 17:43:59
cmd_event	Shutter	2015-09-03 16:36:12
cmd_nr	1	2015-09-03 16:36:12
e_Shutter_STATE	up	2015-09-03 17:43:59
state	cmd_1	2015-09-03 16:36:12
wait_timer	03.09.2015 17:44:24 cmd_1 Shutter	2015-09-03 17:43:24

Habs auch mal manuell gestartet und die Events geloggt:

Code Auswählen Erweitern


2015-09-03 17:52:53 CUL_HM Shutter level: set_90
2015-09-03 17:52:53 DOIF WatchdogShutter wait_timer: 03.09.2015 17:53:53 cmd_1 Shutter
2015-09-03 17:52:53 CUL_HM Shutter set_90
2015-09-03 17:52:54 CUL_HM Shutter deviceMsg: up (to VCCU)
2015-09-03 17:52:54 CUL_HM Shutter level: 100
2015-09-03 17:52:54 CUL_HM Shutter motor: down:up
2015-09-03 17:52:54 CUL_HM Shutter pct: 100
2015-09-03 17:52:54 CUL_HM Shutter up
2015-09-03 17:52:54 CUL_HM Shutter timedOn: down
...
2015-09-03 17:53:00 CUL_HM Shutter deviceMsg: 90 (to VCCU)
2015-09-03 17:53:00 CUL_HM Shutter level: 90
2015-09-03 17:53:00 CUL_HM Shutter motor: stop:90
2015-09-03 17:53:00 CUL_HM Shutter pct: 90
2015-09-03 17:53:00 CUL_HM Shutter 90
2015-09-03 17:53:00 CUL_HM Shutter timedOn: down
...
2015-09-03 17:53:53 DOIF WatchdogShutter wait_timer: no timer
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_nr: 1
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_event: Shutter
2015-09-03 17:53:53 DOIF WatchdogShutter cmd_1


[RoBra81]

Hallo,

hast du ein DOELSE? Ich habe mal festgestellt, dass dieses Verhalten dann auftritt, wenn wenn es nur einen einzigen Zweig ohne DOELSE gibt...

Ronny