RandomTimer - neues Modul

[det.]

Na ja, ich würde mal unterstellen, dass das schlicht an dem "on-for" liegt... dann gilt: bekommen, was bestellt war... (Mmn. macht on-for bei einem RT keinen allzugroßen Sinn, und 30 Sek. sind sowieso ein ziemlich "zackiger" Klo-Gang => daran erkennt ein potentieller Einbrecher ggf. erst recht, dass niemand zuhause ist und nur eine Automatik vor sich hin werkelt...).

Wenn es das nicht gäbe, würde ich behaupten, dass deine Anwesenheitserkennung "zu träge" ist bzw. kein "execNow" abgesetzt wird, wenn jemand nach Hause kommt. Du hast disableCondCmd auf offCmd gestellt. Damit wird ausgeschaltet, wenn rgr_atHome auf home geht, works as designed...

Danke, das on-for ist aus der commandref und ab sofort bei mir raus. Mit den 30s gebe ich Dir Recht, kaum sind wir fort, laufen die Prostatiker zur Höchstform auf 
Ich werde beobachten, ob das in Zukunft noch mal auftritt, aber Du hast es sicher richtig auf den Punkt gebracht.

[Beta-User]

Moin zusammen,

mit dem heutigen update kommt dann die Version mit dem offState-Attribut - das Testen wurde ja ausgiebig angenommen...

Achtung:
Ab featurelevel 6.1 wird dann bei allen nicht mehr auf STATE geschaut, sondern das Reading state ausgewertet. Wer also bisher stateFormat genutzt hatte, um das RandomTimer-konform zu bekommen, möge bitte beizeiten checken, ob er nicht Handlungsbedarf hat.
Wer nicht weiß ob, kann in global den featurelevel erhöhen und das so testen, oder eben das neue Attribut passend setzen - dann ändert sich später dazu nichts mehr...

Grüße, Beta-User

[Beta-User]

Hallo zusammen,

da derzeit der Zufall regiert, und gestern die Frage aufkam, inwieweit man die Zufälligkeiten im Randomtimer noch beeinflussen kann, anbei eine Testversion, das ein weiteres optionales Parameter-Paar einführt, "variations".

Damit kann man beeinflussen:
a) die zufällige Verlängerung der Zeitpunkte zwischen zwei Schaltungen (die schwankt sonst zufällig um den angegebenen Wert), der dann als Minimum-Wert interpretiert wird. Der Parameter wir als Zahl angegeben, beispielsweise eine Stunde Minimum, und dann irgendwas im Bereich bis 10 Minuten addieren:

Code Auswählen Erweitern

defmod Zufall1 RandomTimer *06:00 MYSENSOR_98 22:00:00 3600 600
b) Den ersten Einschaltzeitpunkt variieren (max. Verschiebedauer steht als Zahl steht hinter dem Poppelpunkt):

Code Auswählen Erweitern

defmod Zufall1 RandomTimer *06:00 MYSENSOR_98 22:00:00 3600 :1800

Das ganze kann man selbstredend auch kombinieren:

Code Auswählen Erweitern

defmod Zufall1 RandomTimer *06:00 MYSENSOR_98 22:00:00 3600 600:1800

Wäre nett, wenn ihr Rückmeldung gebt, v.a., wenn ich das nicht haben wollt oder irgendwas nicht so funktionieren sollte wie gewollt...

Gruß, Beta-User

[romakrau]

Hallo Beta-User,
da hast Du aber schnell reagiert. Ich werde es die nächsten Tage testen und berichten.
Danke und GRuß
Roman

[FunkOdyssey]

Ich wollte gerade mal wieder testen. Und jedesmal wenn ich RandomTimer anlegen möchte, frage ich mich wofür das * ist.
- Muss das wirklich beim Ein- und Ausschaltpunkt gesetzt werden?
- Ist das auch bei Uhrzeiten notwendig?
- Oder nur bei Perl-Befehlen?

Könntest du in der CommandRef vielleicht einen kurzen Erklärungssatz dazu aufnehmen. Vielleicht bin ich mit diesem Problem ja nicht alleine.

Danke dir, Beta-User. Gute Arbeit.

[romakrau]

Hallo Beta-User,
ahbe gerade getestet mit den Parametern:
RandomTimer  16:00 <Dummy> 23:00:00 60 30

Der Event-Monitor ergab folgendes Bild:

2020-03-16 20:58:47 RandomTimer ZufallTimer on
2020-03-16 20:59:50 RandomTimer ZufallTimer on
2020-03-16 21:01:00 RandomTimer ZufallTimer on
2020-03-16 21:01:00 RandomTimer ZufallTimer off
2020-03-16 21:02:03 RandomTimer ZufallTimer on
2020-03-16 21:03:12 RandomTimer ZufallTimer on
2020-03-16 21:04:17 RandomTimer ZufallTimer on
2020-03-16 21:05:34 RandomTimer ZufallTimer on
2020-03-16 21:06:56 RandomTimer ZufallTimer on

Ich hätte allerdings nach dem Einschalten ein Ausschalten erwartet. Das Ausschalten sollte auch mit einer Zeit 60 + rand(30) erfolgen. Den Parameter nach dem Doppelpunkt habe ich nicht verstanden.
Gruß
Roman

[Beta-User]

Ich wollte gerade mal wieder testen. Und jedesmal wenn ich RandomTimer anlegen möchte, frage ich mich [...]
Danke dir, Beta-User. Gute Arbeit.

Danke für die Rückmeldung.

Der Code ist allerdings in ganz überwiegenden Teilen nicht von mir, sondern vom leider verstorbenen User/Developer Dietmar. Im Zusammenhang mit der IsWe()-Sache hatte ich mich nur etwas in diese Codes (v.a. @WeekdayTimer) eingearbeitet, und dabei als "Nebeneffekt" eben auch den RandomTimer mit übernommen...

Will sagen: meine Modifikationen hatten sich auf notwendige Dinge beschränkt, die bestehenden Teile habe ich nur da angefaßt, wo es notwendig war (u.a., um die Abhängigkeiten von der "3. Schwester Twilight" zu eliminieren).

Was "+" und "*" angeht, ist die Sache einigermaßen klar: es ist ausdrücklich erwähnt, dass es dieselbe Syntax ist wie @at. Zumindest vorne bei der Startzeit ist das zwingend (egal, ob Perl oder "normale Uhrzeit"), ohne den * hat man einen einmaligen RT. Hinten scheint es egal zu sein, das wird zwar in der DefFn ausgewertet, aber dann passiert mit diesen Infos nichts mehr...



@romakrau:
Der RT funktioniert etwas anders, als du das unterstellst...
Zum 1. Einschaltzeitpunkt wird mit einer Wahrscheinlichkeit x (default: 80%) eingeschaltet.
Dann läuft ein Timer (entweder 60+-10%, mit der neuen Variante 60+rand(<weiterem Parameter>))
Ist bei Ablauf des Timers an, wird "gewürfelt", ob ausgeschaltet werden soll, was aber nur in 20% der Fälle (default) wirklich passiert. Danach geht es weiter.
Was du also siehst, sind die Ergebnisse der Überprüfung/des Würfelns und deren Zeitpunkte.

Wie geschrieben, ist normalerweise der 1. Schaltzeitpunkt fix. Nur das "Würfelergebnis" ist offen. Dafür ist  der weitere Parameter hinter dem ":" gedacht, damit kannst du auch diesen 1. Zeitpunkt noch weiter "randomizieren".

Gruß, Beta-User

[romakrau]

Danke, ich habe mit dem Event Monitor ein für mich akzeptables Verhalten erzielt. Gruß Roman

[Beta-User]

Danke für die Rückmeldung.

Habe das mit den "variations" eben eingecheckt, nachdem das hier ein paar Tage in meinem Echtsystem (mit den alten Definitionen) stressfrei gelaufen war, und auch diese Ergänzungen ja keine Raketenwissenschaften waren.
Sollten wider Erwarten doch Probleme auftauchen: Rechtzeitiges Mittesten wäre eine gute Idee, aber nur 1 Download in den paar Tagen trotz weit verbreitetem "corona-Homeoffice" samt Rückmeldung (die sich nicht mal ausdrücklich auf die neue Modulfassung bezog...), was soll mir das sagen...?

Wie auch immer: Das kommt ab morgen früh per update.

[det.]

Danke für Deine Mühen,
Da das Modul bei mir nur bei Abwesenheit zum Einsatz kommt, ist genau zur Zeit ein Test schlecht möglich...

[Beta-User]

Danke für Deine Mühen,
Da das Modul bei mir nur bei Abwesenheit zum Einsatz kommt, ist genau zur Zeit ein Test schlecht möglich...

Danke erst mal für die Rückmeldung.

Es geht bei sowas mMn. immer um zweierlei:
1. Das Verhalten von vorhandenen Geräten sollte sich nicht ändern. OK, das ist in vollem Umfang evtl. derzeit schlecht  zu testen, aber immerhin _möglich_ wäre die Rückmeldung: "keine unerwünschten Nebeneffekte erkennbar".
2. Die neuen features (und evtl. die alte Funktionsweise "bei Abwesenheit") zu testen. Das geht auch, erfordert aber ggf. die Anlage von Testdevices.

Ergo: Beides mit überschaubarem Aufwand möglich, so man testen _will_.
Das muß man selbstredend nicht, aber gerade die "corona-homeofficler" hätten die Möglichkeit, das nicht nur aus logs abzulesen, sondern live zu erleben, ob das gewünschte Ergebnis (hier jedenfalls der Spur nach, ist ja zufällig...) eigentlich den eigenen Erwartungen entpricht...

Da wir grade beim Nachsehen usw. sind und der eine oder andere evtl. etwas Zeit dafür findet: Es würde eventuell allgemein Sinn machen mal nachzusehen, ob eine Anpassung der eigenen Definitionen weg von stateFormat/STATE hin zu dem neuen Attribut anzeigt ist.

[Beta-User]

Hallo zusammen,

ihr habt es evtl. gemerkt, der RandomTimer hat eine kleine Renovierung erhalten, heute morgen gab's dazu ein update.

Was mir für das update nicht mehr gelungen war auszutesten war das "feature", das ich eigentlich auch noch mit einbauen wollte: disabledForIntervals. (Thx an Rudi für den Vorschlag!).

Das ganze funktioniert wie bei anderen Modulen auch, die das kennen, z.B. at und notify: In den jeweils angegebenen Zeiträumen wird der RT deaktiviert - ganz so, als käme man heim. Der Timer/die Intervallprüfung läuft aber weiter und wenn dann kein "disabled-Intervall" mehr ist, geht es ganz normal mit zufälligem ein/aus weiter.

Wie üblich darf testen, wer mag, und wenn es keine berechtigten Beschwerden gibt, kommt es dann irgendwann ins svn.

Grüße und viel Freude damit,

Beta-User

[Beta-User]

Hallo zusammen,

seit eben ist das angekündigte update im svn.

Neben disabledForIntervals bringt es auch zwei neue setter: "active" und "inactive". Damit kann man das Modul auch zur Laufzeit aktivieren/deaktivieren.

Viel Freude damit,

Beta-User

[Nestor]

Attached is a small patch which implements parseParams().
This allows quoted parameters in the DEF so we can use spaces in Perl timespec parameters.

Like so:

Code Auswählen Erweitern

defmod ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch "*{sunset_abs(3 * 3600)}" 480


Code Auswählen Erweitern

--- - 2020-09-25 20:13:46.000000000 +0200
+++ FHEM/98_RandomTimer.pm 2020-09-25 20:07:41.000000000 +0200
@@ -82,18 +82,18 @@
     $hash->{AttrList} = "onCmd offCmd switchmode disable:0,1 disableCond disableCondCmd:none,offCmd,onCmd offState "
       . "runonce:0,1 keepDeviceAlive:0,1 forceStoptimeSameDay:0,1 disabledForIntervals "
       . $readingFnAttributes;
+    $hash->{parseParams} = 1;
     return;
}

# regular Functions ##################################################################
sub Define {
-    my $hash = shift;
-    my $def = shift // return;
+    my ($hash, $a, $h) = @_;

     RemoveInternalTimer($hash);
     my ( $name, $type, $timespec_start, $device, $timespec_stop, $timeToSwitch,
         $variation )
-      = split m{\s+}xms, $def;
+      = @$a;

     return "wrong syntax: define <name> RandomTimer <timespec_start> <device> <timespec_stop> <timeToSwitch> [<variations>]"
       if ( !defined $timeToSwitch );
@@ -211,14 +211,14 @@
}

sub Set {
-    my ( $hash, @a ) = @_;
+    my ($hash, $a, $h) = @_;

-    return "no set value specified" if ( int(@a) < 2 );
-    return "Unknown argument $a[1], choose one of execNow:noArg active:noArg inactive:noArg"
-      if ( $a[1] eq "?" );
+    return "no set value specified" if ( int(@$a) < 2 );
+    return "Unknown argument @$a[1], choose one of execNow:noArg active:noArg inactive:noArg"
+      if ( @$a[1] eq "?" );

-    my $name = shift @a;
-    my $v = join( " ", @a );
+    my $name = shift @$a;
+    my $v = join( " ", @$a );

     if ( $v eq "execNow" ) {
         Log3( $hash, 3, "[$name] set $name $v" );


[Beta-User]

Thanks a lot, good suggestion.
Note: I slightly changed the patch and just did a small test with my classic definitions, so feedback is appreciated if everything still works as expected...