RandomTimer module added - a module to simulate the random functionality of a timer clock like FS20ZSU.
Bei mir ist alles so definiert:
fhem.cfg
define Verreist dummy
attr Verreist webCmd ja:nein
...
define ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch 20:30:00 480
attr ZufallsTimerTisch disableCond (!isVerreist())
99_Utils
#
sub isUrlaub () { return(YesNo("Urlaub")); }
sub isVerreist () { return(YesNo("Verreist"));}
sub isUebergangszeit () { return(YesNo("Uebergangszeit"));}
#
#
#
sub YesNo ($) {
my ($dummy) = @_;
my $state = ReadingsVal($dummy, "state", "nein");
if ($state eq "nein") {
return 0;
}
return 1;
}
Mit diesem Modul läßt sich sehr einfach eine Anwesenheitssimulation erstellen.
Ich weiß, es es gibt schon einige Lösungen hier, aber diese ist aus meiner Sicht die Einfachste.
Sie läßt sich ohne shell-scripts betreiben, ist hoffentlich auf für Linux-Laien einzurichten.
Bitte mal probieren und feedback hier einstellen.
Das Modul und eine Dokumentation ist angehängt. Es wird aber auch per update bereitgestellt.
Ich habs wie oben beschrieben ausprobiert und bekomm folgende Fehlermeldungen:
2013.07.29 15:42:19 1: configfile: Wrong timespec Verreist: either HH:MM:SS or {perlcode}
Please define ZufallsTimerEG_GZ first
Please define ZufallsTimerEG_GZ first
Please define ZufallsTimerEG_GZ first
Please define ZufallsTimerEG_GZ first
Please define ZufallsTimerEG_GZ first
Hier meine Konfiguration:
define Verreist dummy
attr Verreist group Commands
attr Verreist room 99_System
attr Verreist webCmd ja:nein
define ZufallsTimerEG_GZ RandomTimer *{sunset_abs("HORIZON=5")} EG_GZ_Deckenlich
attr ZufallsTimerEG_GZ loglevel 3
attr ZufallsTimerEG_GZ offCmd set @ off
attr ZufallsTimerEG_GZ onCmd set @ pct 50
attr ZufallsTimerEG_GZ room EG_GZ
attr ZufallsTimerEG_GZ disableCond (!isVerreist())
Gruß
Luigi
define ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch 20:30:00 480
define ZufallsTimerEG_GZ RandomTimer *{sunset_abs("HORIZON=5")} EG_GZ_Deckenlich xxxxxxxx xxx
Es fehlt aus meiner Sicht der timespec_stop und der Parameter timeToSwitch.
Die Fehlermeldung Wrong timespec Verreist: either HH:MM:SS or {perlcode} deutet darauf hin, dass die aktuellste Version von RT nicht aktiv ist. Bitte die Datei einspielen und mit reload 98_RandomTimer nachladen.
Hallo Dietmar,
in Deinem Modul passt die Doku noch nicht richtig, wird immer wieder beim commandref_join angemeckert.
- am Ende muss es "end html" anstatt "end html_DE" heissen
- das letzte /ul ist zuviel
- nach dem cut kann ein Zeilenumbruch nicht schaden :)
Viele Grüße
Udo
Index: 98_RandomTimer.pm
===================================================================
--- 98_RandomTimer.pm (Revision 3542)
+++ 98_RandomTimer.pm (Arbeitskopie)
@@ -478,7 +478,6 @@
</pre>
</li>
</ul>
-</ul>
-=end html_DE
-=cut
\ No newline at end of file
+=end html
+=cut
passe ich an
funktioniert es jetzt?
jepp, die Fehlermeldung ist verschwunden :)
Danke & Grüße
Udo
Hallo Dietmar,
bei Einschaltzeiten zwischen 00 und 5:59 Uhr funktioniert das Modul bei mir nicht.
Die Anfangszeit wird dann immer auf 00:05:00 gesetzt.
Mache ich was falsch oder ist da noch ein Fehler drin?
Gruß
Schick mir mal deine Definition
Hallo Dietmar,
das geht ja fix.
Die Definition ist:
define ZufallsTimer1 RandomTimer *06:30:00 wz_sd_re Verreist 06:30 720 800/100
Ich habe auch noch einen Screenshot angehangen, dort kannst Du sehen das State auf 00:05:00 gesetzt wird.
Bei späteren Zeiten wird die richtige Zeit dort eingetraen.
Herzlichen Dank
Dieter
Deine Definition und vielleicht auch die Version des Moduls RT stimmen möglicherweise nicht:
Bitte RT von hier verwenden und so definieren wie hier beschrieben.
Link (http://forum.fhem.de/index.php?topic=14010.msg87704#msg87704)
Die Definition enthält neuerdings kein dummy mehr.
Man muss, wenn man den RT über dummy an-/abschalten will, eine disableCondition per attr setzen.
attr ZufallsTimerTisch disableCond (!isVerreist())
Hier wird der Wert der Funktion isVerreist() ausgewertet.
In isVerreist() kannst du dann alles Mögliche abfragen. Sie muss nur true/false zurückliefern.
Für die Definition siehe obigen Link. Neu ist, dass auch die stoptime im Format HH:MM:SS angegeben werden muss. Diese ist eine Folge des Wunsches von ??? auch dort Perlfunktionen angeben zu wollen.
Die Anzeige 00:05:00 im state kommt dadurch zustande, dass alle RT um 5 Minuten nach Mitternacht eine kleine Neuberechnung der Startzeit für den soeben angebrochenen Tag durchführen, und erst dann den richtigen Schaltzeitpunkt anzeigen - habe ich deshalb gemacht, weil Funktionen wie sunrise/sunset sonst den Wert vom Vortag verwenden würden.
Ich denke darüber nach, die Anzeige 00:05:00 verschwinden zu lassen - irritiert zu sehr.
Prüf mal nach, ob du mit den Hinweisen weiterkommst!
Herzlichen Dank!
Ich hatte noch eine ältere Version im Einsatz
und werden jetzt die neue mal testen.
Zitat von: Dietmar63 schrieb am Sa, 03 August 2013 15:43Neu ist, dass auch die stoptime im Format HH:MM:SS angegeben werden muss. Diese ist eine Folge des Wunsches von ??? auch dort Perlfunktionen angeben zu wollen.
Hallo Dietmar.
vielen Dank für die Arbeit. Ich war ja der mit den 3 Fragezeichen und habe das neue Modul eingearbeitet. Nun muss es erst einmal morgen früh zeigen, was es hergibt. Ich melde mich wieder.
Gruß
Reimer
Es scheint alles reibungslos zu klappen:
Perlfunktion als Stoppzeit und Aktivierung/Deaktivierung über die Variable in 99_Utils.pm.
Eine Merkwürdigkeit ist mir aufgefallen:
Bei aktivem RandomTimer wurde bei der Stoppzeit nicht das Datum in der Form YYYY:MM:DD, sondern der Tag des Jahres angezeigt: "2013:215 ..... "
Gruß
Reimer
ZitatEine Merkwürdigkeit ist mir aufgefallen:
Bei aktivem RandomTimer wurde bei der Stoppzeit nicht das Datum in der Form YYYY:MM:DD, sondern der Tag des Jahres angezeigt: "2013:215 ..... "
Das ist Absicht. Als ich die Einzelteile des Moduls erstellt habe, mußte ich mir eine Darstellung der Abschaltzeit einfallen lassen, die es mir ermöglichte einfach den Wechsel des Tages während der Aktivzeit einzubeziehen.
Die Darstellung mit dem Tag im lfd. Jahr war am Einfachsten.
Hallo,
ich würde gerne das Modul RandomTimer nutzen um Funksteckdosen zu schalten, dabei möchte ich aber für Wochenenden eine andere Abschaltzeit verwenden.
Wie muss ich denn die Abfrage if($we) mit dem RandomTimer-define verknüpfen, damit das klappt?
Für einen Stups in die richtige Richtung wäre ich dankbar
Gruß
Olly
fhem.cfg
define ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch {abschaltZeit($we)} 480
99_utils
sub abschaltZeit ($) {
my ($we) = @_;
if ($we) {
return "22:00:00";
} else {
return "23:00:00";
}
}
Hallo Dietmar,
vielen Dank für die schnelle Antwort.
Werde das mal in meine Config einfügen und dann dieses Wochenende ausprobieren.
Gruß
Olly
lüppt?
Ups, fast vergessen.
Ja, funktioniert prima. Werde jetzt mal ein paar Geräte "randomisieren".
Und dann kann der Urlaub kommen ;-)
nochmal Danke und Gruß
Olly
Nur zur Info: Es gibt auch ein HOL-Modul in Contrib (http://sourceforge.net/p/fhem/code/3706/tree/trunk/fhem/contrib/98_HOL.pm (//sourceforge.net/p/fhem/code/3706/tree/trunk/fhem/contrib/98_HOL.pm)), das Geräte zufällig schaltet.
Viele Grüße,
Matthias
Die Option switchmode scheint bei mir nicht zu funktionieren. Mit
attr random_timer_test switchmode 500/500
wird trotzdem bei Internals
SIGMAOFF 800
SIGMAON 200
SWITCHMODE 800/200
angezeigt.
Nachtrag: Die Werte scheinen erst nach Aktivierung der Routine gesetzt zu werden. Jedenfalls sind sie jetzt bei einer Routine in Ordnung, die augenblicklich aktiv ist.
ZitatNachtrag: Die Werte scheinen erst nach Aktivierung der Routine gesetzt zu werden. Jedenfalls sind sie jetzt bei einer Routine in Ordnung, die augenblicklich aktiv ist.
so ist es.
Immer erst dann, wenn die Entscheidung an/aus getroffen werden muss, wird das Attribut gelesen.
RandomTimer um disable erweitert - eingecheckt.
Hallo,
ich versuche den RandomTimer einzusetzen, habe aber ein paar Probleme mit der englischen Beschreibung.
1. Unter "Deskrition" steht: "Every (timeToSwitch seconds +-10%) it trys to switch device on/off."
Das habe ich für mich so übersetzt: "Die Dauer wird mit einer zufälligen Abweichung von +-10% eingehalten.
Wenn ich die Funktion richtig verstehe variiert doch das Attribut "switchmode" mit seinen beiden Parametern die EIN/AUS-Schaltdauer.
Was bedeutet die Angabe +-10% in diesem Zusammenhang?
2. Attribut "disableCond"
"In the disableCond-Attibute a condition can be specified, that must be true to have the Randomtimer work.
The Condition must be put into round brackets. The best way is to define a function in 99_utils."
Das klingt für mich widersprüchlich, wenn ich eine DisableCondition auf TRUE setze, um den Timer zu aktivieren.
Kann ich das Attribut nicht auch direkt setzen, z.B.: "attr disableCond true"?
Schnup
Melde mich nachher
Zitat1. Unter "Deskrition" steht: "Every (timeToSwitch seconds +-10%) it trys to switch device on/off."
Das habe ich für mich so übersetzt: "Die Dauer wird mit einer zufälligen Abweichung von +-10% eingehalten.
Wenn ich die Funktion richtig verstehe variiert doch das Attribut "switchmode" mit seinen beiden Parametern die EIN/AUS-Schaltdauer.
Was bedeutet die Angabe +-10% in diesem Zusammenhang?
timeToSwitch definiert die Zeit zwischen zwei Schaltvorgängen. Sie wird mit einer zufälligen Abweichung von 10% eingehalten.
switchmode verändert die Wahrscheinlichkeit mit der ein- bzw. ausgeschaltet wird. 800/200 bedeutet, dass mit 80%er Wahrscheinlichkeit eingeschaltet wird, wenn das Gerät ausgeschaltet ist, und dass mit 20%er Wahrscheinlichkeit ausgeschaltet wird, wenn das Gerät eingeschaltet ist. Dahinter steckt die Überlegung, dass ich nur selten auschalten will. Das Verhalten kann mit
switchmode angepasst werden.
Zitat2. Attribut "disableCond"
"In the disableCond-Attibute a condition can be specified, that must be true to have the Randomtimer work.
The Condition must be put into round brackets. The best way is to define a function in 99_utils."
Das klingt für mich widersprüchlich, wenn ich eine DisableCondition auf TRUE setze, um den Timer zu aktivieren.
Kann ich das Attribut nicht auch direkt setzen, z.B.: "attr disableCond true"?
Da ist in der Beschreibung wohl ein kleiner Fehler unterlaufen. Sollte wohl heißen: ... must be true to set the Randomtimer out of work. ...
disableCond muss ein gültiger Perlausdruck in () folgen. Wenn er zu true evaluiert, ist der Timer abgeschaltet.
http://www.perlmonks.org/?node=what%20is%20true%20and%20false%20in%20Perl%3F (http://www.perlmonks.org/?node=what%20is%20true%20and%20false%20in%20Perl%3F)
attr disableCond ("true")
attr disableCond (0)
attr disableCond (1)
sollte gehen
Hallo zusammen,
gibt es ein Wiki oder sonst etwas, wo ich genauere Infos über das Modul und dessen Verwendung (möglichst in Deutsch) finden kann?
Ich habe z.B. immer noch nicht verstanden, was "timeToSwitch" genau bewirkt. Außerdem verstehe ich die Beschreibung so, dass man ein "Dummy" verwenden soll. Hier steht aber in einem Beitrag, dass kein Dummy erforderlich ist.
ZitatDie Definition enthält neuerdings kein dummy mehr.
Man muss, wenn man den RT über dummy an-/abschalten will, eine disableCondition per attr setzen.
Viele Grüße und alles Gute für 2014
Harald
Es gibt kein wiki und keine Doku auf Deutsch.
timeToSwitch definiert die Zeit die wiederholt vergeht, bis eine neue Ein-/Ausschaltung durchgeführt wird. Wenn du 900 angibst, wird alle 15 Minuten (+-10%) geprüft, ob geschaltet werden muss.
RT hat eine längere Geschichte hinter sich. Ursprüglich konnte man in der Definition ein dummy angeben, das auf ja/nein geprüft wurde. Dieses Vorgehen ist aber nicht so flexibel wie die Definition einer Funktion, die true/false liefern muss. In der Funktion kannst du dann alles mögliche prüfen.
Probier einfach mal verschiedene timeToSwitch aus und setze für die RT das verbose Attribut auf 5, dann bekommst du im fhem-Log debug Informationen, die dir die Funktionsweise näherbringen.
Hallo Dietmar,
herzlichen Dank für Deine Antwort und alles Gute für 2014.
Den Zusammenhang zwischen der "zufälligen Abweichung" bei timeToSwitch und der "Wahrscheinlichkeit" bei switchmode habe ich allerdings noch nicht richtig verstanden.
Um das Licht im Treppenraum bei Abwesenheit zu steuern setze ich: timeToSwitch 20 Sek. und switchmode 100/800
Damit bleibt das Licht immer nur kurz eingeschaltet und sollte über einen wesentlich größeren Zeitraum ausgeschaltet bleiben.
Bisher habe das Attribut switchmode 100/800 so ausgelegt:
-> 100 bestimmt die zufällige Abweichung der Einschaltzeit, variiert also timeToSwitch um 10%
-> 800 bestimmt die zufällige Abweichung der Auszeit, variiert also timeToSwitch um 80%
Schnup
Hallo zusammen,
da muss ich Schnupp beipflichten. Über eine genauere Erläuterung würde ich mich auch freuen. Ich habe das so verstanden, dass 800/400 bedeutet, dass der Einschaltbefehl zu 80% und der Ausschaltbefehl zu 40% befolgt wird, weil die Lampe hin und wieder eben nicht geschaltet werden soll, um noch mehr Unregelmäßigkeit hinein zu bringen, oder?
Ist es möglich, das Modul so zu ändern, dass nicht nur ein sondern 2 oder 3 Schaltbefehle nacheinander gesendet werden? Meine Steckdosen folgen nämlich nicht immer dem Befehl, sondern bleiben nach der Abarbeitung manchmal ein- oder ausgeschaltet. Deshalb würde ich gerne zur Sicherheit die Schaltbefehle 2- oder 3-fach senden.
@Dietmar63: Wenn Du mir sagst, was ich wo ändern muss, würde ich das gerne probieren.
Viele Grüße und alles Gute für 2014
Harald
Zitatda muss ich Schnupp beipflichten. Über eine genauere Erläuterung würde ich mich auch freuen. Ich habe das so verstanden, dass 800/400 bedeutet, dass der Einschaltbefehl zu 80% und der Ausschaltbefehl zu 40% befolgt wird, weil die Lampe hin und wieder eben nicht geschaltet werden soll, um noch mehr Unregelmäßigkeit hinein zu bringen, oder?
stimmt.
ZitatIst es möglich, das Modul so zu ändern, dass nicht nur ein sondern 2 oder 3 Schaltbefehle nacheinander gesendet werden? Meine Steckdosen folgen nämlich nicht immer dem Befehl, sondern bleiben nach der Abarbeitung manchmal ein- oder ausgeschaltet. Deshalb würde ich gerne zur Sicherheit die Schaltbefehle 2- oder 3-fach senden.
Wenn du Empfangsprobleme hast, ist es bestimmt nicht sinnvoll allen Modulen beizubringen öfters zu schalten. Das senkt den credit und führt zu noch mehr Problemen.
Hallo Dietmar,
Danke für die Antwort. Hat aber nichts mit der Reichweite, sondern mit den Steckdosen zu tun. Dann werde ich mal sehen, wie ich das löse.
Viele Grüße
Harald
welche Marke?
Hallo Dietmar,
kann es sein, dass die variable Zeitverzögerung nicht beim Einschalten wirksam ist? Ich habe das mehrfach versucht und nur Verzögerungen von bis zu 5 sek, die vermutlich durch FHEM selbst verursacht werden, beobachtet. Außerdem werden die Dosen bereits nach 20min (timeToSwitch=1200) abgeschaltet und nicht bei timespec_stop +- RandomTime (=timeToSwitch?). Oder habe ich noch etwas falsch gemacht? Ich würde gerne die Ein- sowie Ausschaltzeit um ca. +- 0 bis 20 Minuten automatisch ändern lassen.
Hier meine fhem.cfg:##############################################################################
#
# ELRO-Steckdosen schalten
# funktionieren mit diesen Adressen auch mit der Fernbedienung
#
define Verreist dummy
attr Verreist room ELRO
attr Verreist webCmd ja:nein
#
define Urlaub dummy
attr Urlaub room ELRO
attr Urlaub webCmd ja:nein
#
define myTwilight Twilight 51.518056 6.342778 1 652005
attr myTwilight room ELRO
#
define Dose1 IT 0FF000FFFF FF F0
attr Dose1 IODev CUL_0
attr Dose1 model itswitch
attr Dose1 room ELRO
attr Dose1 verbose 5
define Dose1Wohn RandomTimer *{sunset("HORIZON=-3")} Dose1 23:45:00 1200
attr Dose1Wohn disableCond (!isVerreist())
attr Dose1Wohn room ELRO
attr Dose1Wohn switchmode 999/999
attr Dose1Wohn verbose 5
#
define Dose2 IT 0FF00F0FFF FF F0
attr Dose2 IODev CUL_0
attr Dose2 model itswitch
attr Dose2 room ELRO
attr Dose2 verbose 5
define Dose2Kue RandomTimer *{sunset("HORIZON=-2")} Dose2 23:10:00 1200
attr Dose2Kue disableCond (!isVerreist())
attr Dose2Kue room ELRO
attr Dose2Kue switchmode 999/999
attr Dose2Kue verbose 5
#
define Dose3 IT 0FF00FF0FF FF F0
attr Dose3 IODev CUL_0
attr Dose3 model itswitch
attr Dose3 room ELRO
attr Dose3 verbose 5
define Dose3PC RandomTimer *{sunset("HORIZON=-4")} Dose3 18:00:00 1200
attr Dose3PC disableCond (!isVerreist())
attr Dose3PC room ELRO
attr Dose3PC switchmode 999/999
attr Dose3PC verbose 5
#
und hier das Logfile:
2014.01.06 16:52:45 4: [Dose2Kue] Next timer 06.01.2014 16:52:46
2014.01.06 16:52:46 4: [Dose2Kue] Zustand:off sigma:999 random:33
2014.01.06 16:52:46 4: [Dose2Kue] command: set Dose2 on
2014.01.06 16:52:46 2: IT set Dose2 on
2014.01.06 17:00:29 4: [Dose1Wohn] Next timer 06.01.2014 17:00:30
2014.01.06 17:00:30 4: [Dose1Wohn] Zustand:off sigma:999 random:239
2014.01.06 17:00:30 4: [Dose1Wohn] command: set Dose1 on
2014.01.06 17:00:30 2: IT set Dose1 on
2014.01.06 17:08:06 4: [Dose3PC] Next timer 06.01.2014 17:08:07
2014.01.06 17:08:07 4: [Dose3PC] Zustand:off sigma:999 random:218
2014.01.06 17:08:07 4: [Dose3PC] command: set Dose3 on
2014.01.06 17:08:07 2: IT set Dose3 on
2014.01.06 17:12:52 4: [Dose2Kue] Zustand:on sigma:999 random:804
2014.01.06 17:12:52 4: [Dose2Kue] command: set Dose2 off
2014.01.06 17:12:52 2: IT set Dose2 off
Wäre schön, wenn Du mir ein wenig auf die Sprünge helfen würdest.
Viele Grüße
Harald
PS: Verreist steht übrigens auf "ja"
Zitatkann es sein, dass die variable Zeitverzögerung nicht beim Einschalten wirksam ist?
ja, das stimmt.
ZitatIch habe das mehrfach versucht und nur Verzögerungen von bis zu 5 sek, die vermutlich durch FHEM selbst verursacht werden, beobachtet.
nein, dieses Verhalten beruht auf Programmlogik.
ZitatAußerdem werden die Dosen bereits nach 20min (timeToSwitch=1200) abgeschaltet und nicht bei timespec_stop +- RandomTime (=timeToSwitch?). Oder habe ich noch etwas falsch gemacht? Ich würde gerne die Ein- sowie Ausschaltzeit um ca. +- 0 bis 20 Minuten automatisch ändern lassen
Du hast nichts falsch gemacht, aber immer noch nicht ganz verstanden wie ein RT funktioniert. Du hast
switchmode mit 999/999 definiert. Das bedeutet, dass alle 1200 Sekunden immer angeschaltet und nach weiteren 1200 Sekunden immer ausgeschaltet wird.
Folgende Zeile
2014.01.06 17:00:30 4: [Dose1Wohn] Zustand:off sigma:999 random:239 bedeutet:
Der Zustand des zu schaltenden Geräts ist
off, das heisst es wird mit 99,9%tiger(Wert 1 von
switchmode) Wahrscheinlichkeit eingeschaltet werden. Der Zufallswert
random(immer zwischen 0 und 999) ist mit 239 kleiner als 999, somit wird eingeschaltet.
Wenn du Wert1 von
switchmode mit 200 angegeben hättest, hätte RT das Gerät zum Zeitpunkt 17:00:30 nicht eingeschaltet. Dieses Spiel wiederholt sich alle 1200 Sekunden(+-10%) bis dass RT feststellt, dass
timespec_stop erreicht bzw. überschritten ist. Dann endet der Zyklus. Das Ende ist also immer nach
timespec_stop. Genau kann man den Endezeitpunkt nicht vorhersagen. Er hängt von mehrmaligen
timetoswitch(+-10%) ab.
ZitatIch würde gerne die Ein- sowie Ausschaltzeit um ca. +- 0 bis 20 Minuten automatisch ändern lassen
geht so:
fhem.cfg
define ZufallsTimerTisch RandomTimer *{sunrise_abs_rand(40)} StehlampeTisch *{sunset_abs_rand(40)} 48099_myUtils
sub sunset_abs_rand ($)
{
my ($zufall) = @_;
my $secs = 60*$zufall;
my $zuf = int(rand($secs));
my $mod = -$secs/2 + $zuf;
my $tim = sunset_abs("REAL",$mod);
return($tim);
}
und
sunset_abs_rand ($) ist Wrapperfunktionen, die ausgehend vom Sonnenaufgang/Sonnenuntergang n Minuten zufällige Verschiebung in den Start bzw. Endezeitpunkt einrechen.
ZitatPS: Verreist steht übrigens auf "ja"
So ist es auch gedacht. Wenn ich verreist bin, möchte ich dass per zufälligem Schalten von Licht Anwesenheit simuliert wird.
Hallo Dietmar,
herzlichen Dank für die ausführliche Erklärung. Jetzt verstehe ich die Funktion des Moduls etwas besser. Aber eine Frage habe ich noch:
Habe ich das richtig verstanden, dass nach timespec_start die Lampe (evtl. mit Einschaltverzögerung) im Takt von timeToSwitch immer ein- und ausgeschaltet wird, bis timespec_stop (etvl. wieder mit Verzögerung) erreicht ist? Danach passiert nichts mehr, bis das neue timespec_start erreicht ist?
Wenn das so ist, ist es nicht das, was ich möchte. Bei mir soll die Lampe bei sunset "Horizon=x" +- variabler Verzögerung (timeToSwitch) eingeschaltet werden und so bleiben, bis timespec_stop (vorgegebene Zeit z.B. 19:00:00, 23:30:00 o.ä.) +- variable Verzögerung (timeToSwitch) erreicht ist und abgeschaltet wird.
Kann Dein Modul das leisten und wie kann ich das ggf. realisieren?
Nochmals besten Dank und viele Grüße
Harald
ZitatHabe ich das richtig verstanden, dass nach timespec_start die Lampe (evtl. mit Einschaltverzögerung) im Takt von timeToSwitch immer ein- und ausgeschaltet wird, bis timespec_stop (etvl. wieder mit Verzögerung) erreicht ist? Danach passiert nichts mehr, bis das neue timespec_start erreicht ist?
jetzt hast du es verstanden - bildet die RandomTimerfunktion einer ZSU(Zeitschaltuhr) ab.
ZitatWenn das so ist, ist es nicht das, was ich möchte. Bei mir soll die Lampe bei sunset "Horizon=x" +- variabler Verzögerung (timeToSwitch) eingeschaltet werden und so bleiben, bis timespec_stop (vorgegebene Zeit z.B. 19:00:00, 23:30:00 o.ä.) +- variable Verzögerung (timeToSwitch) erreicht ist und abgeschaltet wird.
zwei at oder probier mal WeekdayTimer. Als Zeiten kann man auch Perlausdrücke verwenden.
Dake Dietmar für die Hilfe. Dann habe ich ja endlich die Funktion Deines Moduls verstanden. Es ist somit nicht ohne weiteres für meine Anwendung geeignet.
Mal sehen, ob mit WeekdayTimer oder TwiLight meine Anforderungen zu erfüllen sind.
Viele Grüße und nochmals besten Dank
Harald
Hallo Dietmar,
darf ich Dich nochmal um einen Tipp bitten? Mir gefällt Dein Modul mittlerweile recht gut. Es macht eigentlich fast alles, was ich brauche.
Ich habe mir gedacht, wenn man z.B. in der sub toggleDevice ($) eine Abfrage wie if (($zufall <= $sima) && ($jetzt < $StopZeit)) an passender Stelle einfügt, könnte man das Abschalten der Lampe bei jedem Zyklus überspringen, bis die Endzeit erreicht ist und danach abschalten. Die grundsätzliche Funktion bliebe erhalten und ich hätte die Funktion, die ich möchte.
Leider sind meine Perlkenntnisse nicht so gut, dass ich selbst die richtige Stelle finden könnte. Ich würde mich sehr freuen, wenn Du mir ein bisschen helfen könntest.
Viele Grüße
Harald
Das ist sicherlich möglich, aber wenn du jedes Modul selbst ein wenig verändern willst, weil es deinen zu Anforderungen nicht ganz passt, dann hast du bei updates viele Nachbesserungen einzupflegen.
Mit 999/000 als switchmode wird mit fast an Sicherheit grenzender Wahrscheinlichkeit auch nie abgeschaltet. Ich könnte das Modul sogar noch so ändern, dass die Schaltung nur dann durchgeführt wird, wenn sigma echt größer 999 ist. Das passiert dann nie und dein gewünschtes Verhalten wäre realisiert.
WeekdayTimer passt aber ehrlich gesagt besser. WD realisiert mehrere at in einer Definition. time_specs drüfen Perlfunktionen sein.
Hallo Dietmar,
das war ein toller Tipp, switchmode auf 999/000 zu setzen. Die ersten Tests (mit kurzen Zeiten) sind positiv verlaufen. Falls tatsächlich mal zwischendurch auf Aus geschaltet wird, habe ich keine Probleme damit. In aller Regel bin ih ja nicht zu Hause, wenn wir verreist sind 8) ;) Aber ständiges Aus- und Einschalten hätte mir nicht gefallen.
Jetzt werde ich die real gewünschten Einstellungen vornehmen. Wenn das auch klappt, schlage ich Dich für einen Orden vor.
Du hast natürlich recht, wenn man Module für den eigenen Bedarf abändert, hat man das Problem bez. des Updates. Entweder sind die eigenen Änderungen weg und man muss nacharbeiten, oder man benennt das Modul um, dann bekommt man keine Verbesserungen mit.
Nochmals Dankeschön für den Tipp und schönen Abend noch
Harald
Hallo Dietmar,
ich habe mit Deinem Modul ein wenig getestet. Ich muss sagen, den Orden hast Du Dir redlich verdient! Wenn man weiß, was man tun muss, klappt (fast) alles prima.
Hier noch eine Beobachtung:
Wählt man für timespec_start eine feste Zeit (z.B. 09:45:00) klappt alles einwandfrei. Auch ein Neustart von FHEM während der Laufzeit des RT bringt kein unerwünschtes Verhalten, d.h. es wirde zur vorgesehenen Zeit (timespec_stop) abgeschaltet.
Setzt man allerdings z.B. *{sunset("HORIZON=3",0,"17:00","21:00")} und nach dem Start des Timers wird FHEM neu gestartet (nach Spannungsausfall), wird beim Hochfahren timespec_start auf die Zeit des nächsten Tages gesetzt (weil das ehemalige Startereignis ja schon vorbei ist) und RT arbeitet bis dahin nicht mehr. Die Lampen werden erst am nächsten Tag wieder geschaltet.
Kann es sein, dass ich noch etwas falsch gemacht habe, dass das bei mir so abläuft?
Viele Grüße und besten Dank für das Modul
Harald
Zitat
sunrise()/sunset() returns the absolute time of the next sunrise/sunset, adding 24 hours if the next event is tomorrow, to use it in the timespec of an at device or for the on-till command for FS20 devices.
sunset_abs() sollte besser funktionieren.
Hallo. Dietmar,
das war's! Danke für Deine Hilfe. So lernt man Stück für Stück immer wieder dazu. Jetzt läuft RT weiter, auch wenn FHEM z.B. durch Abspeichern der .cfg o.ä. neu gestartet wird.
Viele Grüße und schönen Abend noch
Harald
Guten Tag,
ich habe mich mit folgender Konfiguration versucht:
define RandomTimerLamp1.1 RandomTimer 15:00:00 Lamp1.1 23:30:00 10
attr RandomTimerLamp1.1 disableCond ( ReadingsVal("PresenceSimulation", "state", "off") eq "off" )
define PresenceSimulation dummy
set PresenceSimulation on
attr PresenceSimulation webCmd on:off
Das funktioniert soweit auch ganz gut, zumindest solange ich den PresenceSimulation dummy aktiviere, bevor die Startzeit für den RandomTimer erreicht ist. Nun möchte ich den Timer aber auch im Intervall zwischen 15:00 und 23:30 mit Hilfe des dummies aktivieren können.
Das scheint nicht zu klappen, da die disableCond() nur zum Startzeitpunkt ausgelesen wird (bzw. später auch noch, aber nur solange bis sie zum ersten mal "True" wird).
Wie kann ich diese Prüfung später auch noch mal manuell triggern? Also mit sowas wie (funktioniert natürlich nicht)
define RandomTimerLampNotify notify PresenceSimulation:on { Random_timer_exec() }
Man könnte natürlich den Timer immer laufen lassen und dann einfach das onCmd() überschreiben, so dass es jeweils zuerst kurz in die dummy-Variable guckt...
MfG Peschmä
Um mir selber zu antworten - habe gerade im Nachbarthread (http://forum.fhem.de/index.php/topic,18336.0.html) gelesen, dass das nicht unterstützt wird, und mir daher was gebastelt mit:
attr RandomTimerLamp1.1 onCmd { if (ReadingsVal("PresenceSimulation", "state", "off") eq "on" ) { fhem("set @ on") } }
attr RandomTimerLamp1.1 offCmd { if (ReadingsVal("PresenceSimulation", "state", "off") eq "on" ) { fhem("set @ off") } }
Hässlich, aber funktioniert.
MfG Peschmä
ich baue folgende Funktion ein:
sub RandomTimer_Wakeup() { # {RandomTimer_Wakeup()}
foreach my $hc ( sort keys %{$modules{RandomTimer}{defptr}} ) {
my $hash = $modules{RandomTimer}{defptr}{$hc};
RandomTimer_ExecRepeater($hash);
Log3 undef, 3, "RandomTimer_Wakeup() for $hash->{NAME} done!";
}
Log3 undef, 3, "RandomTimer_Wakeup() done!";
}
Dann musst du nur noch mit einem notify die dummy abhorchen und diese Fuktion aufrufen. Etwa so:
define RTautomatOn notify dummy:.* {RandomTimer_Wakeup()}
Hallo,
Ich habe gestern verzweifelt an meinem Zufallsschalter eines Galerielichts gehangen.
Ich dachte ich hatte das mal hinbekommen, aber irgendwie passt du was nicht.
define ZufallsTimerGalerie RandomTimer *{sunset_abs("REAL")} FB1_03_SW_Gallerie Verreist 23:59 180 800/100
Kann mir jemand einen guten Tip geben.
Definition falsch - siehe reference
define ZufallsTimerGalerie RandomTimer *{sunset_abs("REAL")} FB1_03_SW_Gallerie Verreist 23:59 180 800/100
aber:
attr ZufallsTimerGalerie disableCond (!isVerreist())
isVerreist() ist dann ene Funktion in 99_myUtils
Danke,
hat sich da was bei dem Modul geändert?
ja, eine ganze Menge: reference oder konkrete Fragen
Hallo, ich versuche auch gerade, den RandomTimer für eine Anwesenheitssimulation zu nutzen. Ich habe die .pm-Datei gespeichert, per Update aktualisiert, den Code in die fhem.cfg eingefügt und auch den Code in die 99_Utils eingefügt.
fhem.cfg
# Anwesenheitssimulation Stehlampe Wohnzimmer
define Verreist dummy
attr Verreist webCmd ja:nein
...
define ZufallsTimerStehlampeWZ RandomTimer *{sunset_abs()}eg_wz_Stehlampe 23:00:00 1800
attr ZufallsTimerStehlampeWZ disableCond (!isVerreist())
99_Utils
#
sub isUrlaub () { return(YesNo("Urlaub")); }
sub isVerreist () { return(YesNo("Verreist"));}
sub isUebergangszeit () { return(YesNo("Uebergangszeit"));}
#
#
#
sub YesNo ($) {
my ($dummy) = @_;
my $state = ReadingsVal($dummy, "state", "nein");
if ($state eq "nein") {
return 0;
}
return 1;
}
Wenn ich aber die fhem.cfg speichern möchte, kommt die Fehlermeldung:
Unknown command ..., try help Cannot load module RandomTimer Please define ZufallsTimerStehlampeWZ first
Würde mich total freuen, wenn mir jemand meinen Fehler aufzeigen könnte, da ich nicht weiß, wo der Fehler liegt. Herzlichen Dank schon mal dafür!
Neue Module müssen erst bekannt gemacht werden. Dies geschieht durch einen Neustart oder durch die Eingabe von
Reload xx-RandomTimer in der Oberfläche von Fhem.
Prima, danke für die sehr schnelle Information - das wusste ich nicht. Habe jetzt den RandomTimer mit Reload bekannt gemacht, aber dann erscheint folgende Fehlermeldung:
syntax error at ./FHEM/98_RandomTimer.pm line 375, near "Log3 undef"
syntax error at ./FHEM/98_RandomTimer.pm line 401, near "Log3 undef"
syntax error at ./FHEM/98_RandomTimer.pm line 403, near "Log3 undef"
Muss ich an diesen Stellen noch etwas anpassen?
Du bist scheinbar auf einer alten FHEM Version unterwegs - kann das sein?
Für diese Version von RT benötigst du fhem 5.5
Entweder neu aufsetzen, oder mit dem update-kommando aktualisieren.
Mit Einführung von 5.5 wurde die Funktion Log3 eingeführt, die scheinst du nicht zu haben. Sie steckt normalerweise in fhem.pl.
Stimmt, ich hatte noch 5.4. Nachdem ich jetzt mal die Firmware der Fritzbox auf den neuesten Stand gebracht habe (wo ja schon FHEM 5.5 dabei sein soll) kann ich aber nicht mehr die FHEM Seite http://fhem-host:8083/fhem aufrufen. Dann kommt immer: Diese Seite kann nicht angezeigt werden. Habe jetzt schon den ganzen Tag herumgesucht, aber dafür noch keine Lösung gefunden. Ich melde mich nochmal, wenn ich das Update auf 5.5. hinbekommen habe - aber schon mal jetzt herzlichen Dank für die bisherige Unterstützung!
Vermutlich ist deine fhem.cfg durch das update überschrieben worden.
Wenn du sie nicht gesichert hast, must du folgendes in die fhem.cfg eingeben bzw. finden(per telnet anmelden und mit einem editor vi oder nano ansehen/editiern) - eigentlich müßte der Zugang standardmäßig verfügbar sein. Welche Fehlermeldung bekommst du? Ersetze mal fhem-host durch die IP deines fhem-Rechners.:
define WEB FHEMWEB 8083 global
Habe die Fritzbox nochmals neu gestartet und jetzt geht der Zugang auf die Seite wieder (habe laut fheminfo aber immer noch Version 5.4). Aber ich habe ein neues Problem: die CUL sendet nicht mehr. In der fhem.cfg steht define CUL_0 CUL /dev/ttyACM0@9600 1034, aber im Logfile steht dann 2014.01.26 19:38:10 1: usb create starting
2014.01.26 19:38:10 3: Opening CUL device /dev/ttyACM0
2014.01.26 19:38:11 3: Setting CUL baudrate to 9600
2014.01.26 19:38:11 3: CUL device opened
2014.01.26 19:38:11 1: define CUL_0 CUL /dev/ttyACM0@9600 1034
2014.01.26 19:38:11 1: reload: Error:Modul 00_CUL deactivated:
syntax error at ./FHEM/00_CUL.pm line 136, near "Log3 undef"
2014.01.26 19:38:11 0: syntax error at ./FHEM/00_CUL.pm line 136, near "Log3 undef"
2014.01.26 19:38:12 1: usb create end
Habe die CUL schon mehrmals von der Fritzbox abgezogen, wieder reingesteckt, Fritz box neu gestartet - aber ohne Erfolg. Kann man die CUL "zurücksetzen"?
So, nach "Update Force" ist jetzt lt. "fheminfo" 5.5 geladen - puh, eine Baustelle weniger :) Den Stick habe ich jetzt neu geflasht (beim einstecken Knopf gedrückt gehalten, "usb scan" gemacht, dann "CULflash none CUL_V3" ausgeführt, dann kam die Fehlermeldung "dfu-programmer: failed to release interface 0.", die aber angeblich normal sei. Und siehe da, der CUL ist jetzt unter "Everything" als "Initialized" markiert.
Ich konnte jetzt auch alle nötigen Schritte für den RandomTimer ohne jegliche Fehlermeldungen durchführen, d.h. du hattest recht mit deiner Aussage, dass es an der alten FHEM-Version lag.
Jetzt habe ich nur noch ein Problem: Der CUL sendet keine Signale mehr, d.h. ich kann momentan nichts mehr so wie vorher schalten. Habe die Fritzbox ein- und ausgeschaltet, aber ohne Erfolg. Hättest du eine Idee, wie ich dieses letzte (aber wichtigste) Problem gelöst bekommen könnte?
Hab im Logfile was entdeckt: bei allen zu steuernden Empfängern steht "No I/O device found for..." - aber über die Suchfunktion (hier und bei Google) habe ich noch nichts gefunden, was weiterhilft.
es höhrt sich an als wenn dein CUL nicht erkannt wird.
Hast du die FB neu gestartet? Nach einem flash ist das vielleicht notwendig.
eventuell mal in den CUL Unterforen suchen. Ich habe meine CUL vor einem Jahr geflascht - hatte auch so meine Schwierigkeiten.
Meine CUL-Definition sieht so aus:
define CUL_0 CUL /dev/ttyACM0@96 1234
define CUL_0 CUL /dev/ttyACM0@96 1234
Ok, danke, da werd ich mal nachsehen. Hier ist meine CUL-Def: /dev/ttyACM0@9600 1034
Hm, vielleicht hat das mit der "00" am Ende zu tun... Schaun mer mal.
Hi Dietmar,
bei meiner gestrigen Überprüfung von DbLog und Text2Speech mittels contrib/commandref_join.pl ist dein RandomTimer mit einer Fehlermeldung aufgefallen. Vor dem nächsten SVN-Checkin kannst das ja mal fixen ;)
welche Fehlermeldung?
habe es geändert und eingecheckt.
Kennst du eine einfache Möglichkeit unbalanced <li> zu finden?
Hi Dietmar,
so, nach Hilfe von Rudolf König funktioniert der CUL und der Random Timer jetzt perfekt! Nur noch eine Frage: ikann man auch einstellen, dass z. B. eine Lampe nicht zufällig an- und ausschaltet, sondern zu einer zufälligen Zeit zwischen xx:xx Uhr un xx:xx Uhr ausschalten soll?
Viele Grüße
eine fertige Möglichkeit kenne ich nicht. Wenn du Perl kannst kannst du alles bauen.
Hallo Dietmar63,
Dein RandomTimer funktioniert bei mir ganz prächtig. Nun würde ich ganz gerne statt CIVIL, REAL u.ä. einen Wert aus Twilight verwenden.
define Dose3PC_ss RandomTimer *{sunset_abs((ReadingsVal("myTwilight","sr_indoor",0)),"15:00","19:00")} Dose3 19:30:00 900
Damit erhalte ich auf der Konsole
Argument "17:57:03" isn't numeric in devision (/) at ./FHEM/99_SUNSET_EL.pm line 89
Dort steht
my $sst = ($rise ? $rt : $st) + ($seconds/3600);
Ist es überhaupt möglich, so ein Konstrukt für den RandomTimer zu verwenden und wenn ja, wie gehe ich da vor?
Besten Dank im Voraus und viele Grüße
Harald
sunset_abs verträgt als ersten Parameter die Konstante "REAL". "CIVIL" oder "HORIZON=3" ... aber keine Zeitangabe.
Wenn du "CIVIL" angibst rechnet sunset selbst den Sonnenuntergang aus.
mit
define Dose3PC_ss RandomTimer *{ReadingsVal("myTwilight","sr_indoor",0),"15:00","19:00")} Dose3 19:30:00 900
solltest du auf die ermittelten Werte von TW zugreifen können.
Hallo Dietmar,
gibt es eine Möglichkeit, den RandomTimer irgendwie nachträglich zu beenden, wenn er einmal läuft?
Ich habe nämlich schon mehrfach das Problem gehabt, dass der RandomTimer z.B. bei Sonnenuntergang startet und bis 23 Uhr läuft, man aber z.B. doch schon früher als geplant wieder heim kommt und dann läuft der RandomTimer halt und man kann ihn nur über Fhemweb wieder beenden, indem man ihn kurz auskommentiert und wieder neu einbindet.
Ich habe die Disable Conditions für die Anwesenheit drin, jedoch wird, wie du selber schon sagtest, dass lediglich einmal vor Beginn des RT geprüft. Ich habe mir jetzt einen zusätzlichen Dummy mit IF eingebaut, allerdings ist es da auch so, dass nur einmal vor Start des RT geprüft wird.
Hast du vllt irgendeine Idee, wie man das Problem lösen kann?
Besten Dank schonmal!
ZitatIch habe die Disable Conditions für die Anwesenheit drin, jedoch wird, wie du selber schon sagtest, dass lediglich einmal vor Beginn des RT geprüft.
Sowohl das Attribut disable und die disableCond werden vor jeder Schaltung abgefragt. Du mußt also nur dafür sorgen, dass sich eines der beiden Felder verändert, ob über die FhemOberfläche oder über einen Taster ist egal. Sollte die Lampe allerdings ausgeschaltet sein, wird sie natürlich nicht eingeschaltet.
Ich überprüfe das Verhalten nochmal.
Ja das geht ja gerade nicht:
VOR dem Aktivieren des RT wird die Disable Cond abgefragt, aber eben nur davor! Wenn der RT einmal läuft, dann gibts eben keine Möglichkeit ihn abzubrechen/auszuschalten! Darum geht es mir!!!!
Ich möchte den deaktivieren können, wenn er gerade läuft! Am besten über einen Dummy!
Und genau das funktioniert doch:
Wenn der RT läuft, kann er abgeschaltet werden, indem man disable oder DisableCond verändert.
Ich habe es mit disable ausprobiert.
Habs gerade nochmal genau getestet und du hast Recht und auch Unrecht! ;)
Mit der disableCond "isAbwesend" kann der RT deaktiviert/unterbrochen werden. Allerdings, was ich komisch finde, wird immer noch ein Ausschaltvorgang ausgelöst! Also RT schaltet Lampe ein, dann schalte ich Abwesend auf nein und dennoch wird die Lampe noch einmal ausgeschaltet.
ZitatMit der disableCond "isAbwesend" kann der RT deaktiviert/unterbrochen werden. Allerdings, was ich komisch finde, wird immer noch ein Ausschaltvorgang ausgelöst! Also RT schaltet Lampe ein, dann schalte ich Abwesend auf nein und dennoch wird die Lampe noch einmal ausgeschaltet.
Ja, das habe ich auch festgestellt.
Das Verhalten ist durchaus änderbar. Ich bin mir aber selbst unsicher was am besten ist. Ich habe selten das Problem, dass ein laufender RT unterbrochen werden muss - ich nutze die Funktion nur bei echter Abwesenheit am Wochendende.
Ich denke, so wie es ist, ist es eigentlich ok!
Man kommt heim, ändert den Status auf "Anwesend" und der RT wird nach dem Ausschalten wieder beendet! An sich ok! Wollte es nur erwähnt haben!
man kann sich darüber streiten ob es sinnvoll ist das Gerät dann auszuschalten, oder nicht.
Vielleicht ist es ja sinnvoll.
Ich denke mal darüber nach. Leider habe ich keine Möglichkeit es tatsächlich auszuprobieren, weil bei mir der Anwendungsfall nicht gegeben ist.
Hallo,
ich teste gerade auch das Modul.
define ZufallsTimerFlurLampeTest RandomTimer *12:00:00 FlurLampe +01:00:00 360
Der Timer ist aktiv, hat um 12:00.01 die FlurLampe eingeschaltet, und um 13:05:51 ausgeschaltet...
2014.04.17 12:00:01 3: FS20 set FlurLampe on
2014.04.17 13:05:51 3: [ZufallsTimerFlurTest] FlurLampe going down ...
Hab erst letzte Woche ein FHEM-Update gemacht, sollte also alles recht aktuell sein. Hat jemand ne Idee warum die Lampe sich nicht ein/ausschaltet so wie das Modul es vorsieht ?
was ist denn merkwürdig?
Setze mal verbose 5,und beobachtete das Protokoll!
Ggf hier Posten.
ich habe ein intern komplett überarbeitetes Modul eingecheckt.
Hi,
ich hatte gedacht, die 360 steht für alle 360s das Gerät +/-10% einzuschalten ?
Bei mir blieb es halt die ganze Zeit an.
LGLG
Es könnte der zugegebenermassen seltene Fall eingetreten sein, dass während der Stunde nie geschaltet wurde.
Mit verbose 5 bekommst du logging Informationen, die alle ca. 360 Sekunden output erzeugen müßten.
Nimm gleich das neueste Modul - ich habe heute eingecheckt.
Hallo,
ich habe im Moment bei mir ein Problem mit RandomTimer, bzw. v.a. mit RandomTimer_Wakeup.
Ich habe einen RandomTimer definiert, der von Sonnenuntergang (indoor) bis 23:00 Uhr jeden Tag zufällig das Flurlicht schalten soll, es sei denn es ist jemand zuhause. Um den RandomTimer zu aktivieren, wenn der letzte das Haus verlässt, wird per Notify auf das entsprechende RESIDENTS-Device (Reading presence) ein RandomTimer_Wakeup() aufgerufen.
So weit funktioniert das jetzt auch, der letzte verlässt das Haus, das Notify ruft auch das RandomTimer_Wakeup auf, aber dann fängt der RandomTimer auch direkt schon an zu arbeiten, obwohl das alles zunächst ausserhalb der definierten Start- und Endzeiten (Sonnenuntergang bis 23:00 Uhr ) des Timers stattgefunden hat.
Ich habe inzwischen mehrfach das commandref dazu konsultiert, finde aber nicht, dass ich da was falsch interpretiert habe.
Handelt es sich hier um einen Bug oder habe ich doch etwas misinterpretiert.
Im folgenden nun zunächst eine entsprechender Log-Auszug:
2014.04.29 07:40:07 2: ROOMMATE set Bine absent
2014.04.29 07:40:07 3: [EG.FL.RT.Flurlicht] starting RandomTimer on EG.FL.SW.Flurlicht: 20:07:56(29) - 23:00:00(29)
2014.04.29 07:40:07 3: RandomTimer_Wakeup() for EG.FL.RT.Flurlicht done!
2014.04.29 07:40:07 3: RandomTimer_Wakeup() done!
2014.04.29 07:40:07 3: RandomTimer_Wakeup triggered, because presence state changed to absent!
2014.04.29 08:01:06 3: CUL_HM set EG.FL.SW.Flurlicht on
2014.04.29 08:11:23 3: CUL_HM set EG.FL.SW.Flurlicht off
2014.04.29 08:41:16 3: CUL_HM set EG.FL.SW.Flurlicht on
2014.04.29 09:01:21 3: CUL_HM set EG.FL.SW.Flurlicht off
2014.04.29 09:11:42 3: CUL_HM set EG.FL.SW.Flurlicht on
2014.04.29 09:31:38 3: CUL_HM set EG.FL.SW.Flurlicht off
2014.04.29 09:41:56 3: CUL_HM set EG.FL.SW.Flurlicht on
2014.04.29 09:51:52 3: CUL_HM set EG.FL.SW.Flurlicht off
2014.04.29 10:02:15 3: CUL_HM set EG.FL.SW.Flurlicht on
2014.04.29 10:03:49 3: CUL_HM set EG.FL.SW.Flurlicht off
Dann noch ein list des RandomTimer:
list EG.FL.RT.Flurlicht
Internals:
CFGFN
COMMAND on
DEF *{sunset_abs("HORIZON=4")} EG.FL.SW.Flurlicht 23:00:00 600
DEVICE EG.FL.SW.Flurlicht
NAME EG.FL.RT.Flurlicht
NR 235
REL
REP *
SIGMAOFF 700
SIGMAON 850
STARTTIME 29.04.2014 20:07:56
STATE 20:07:56
STOPTIME 29.04.2014 23:00:00
SWITCHMODE 700/850
S_REL
S_REP
TIMESPEC_START *{sunset_abs("HORIZON=4")}
TIMESPEC_STOP 23:00:00
TIMETOSWITCH 600
TYPE RandomTimer
active 1
startTime 1398794876
stopTime 1398805200
Timer:
Eg.fl.rt.flurlicht_exec:
HASH EG.FL.RT.Flurlicht
MODIFIER Exec
NAME EG.FL.RT.Flurlicht_Exec
Eg.fl.rt.flurlicht_settimer:
HASH EG.FL.RT.Flurlicht
MODIFIER SetTimer
NAME EG.FL.RT.Flurlicht_SetTimer
Attributes:
disable 1
disableCond (BBPresent())
room 95.10_Simulation
switchmode 700/850
Und der Vollständigkeit halber noch die, zugegebenermaßen sehr simple Definition der, im List aufgeführten BBPresent() aus meiner 99_BBUtils.pm, die aber grundsätzlich funktioniert, denn der RandomTimer läuft ja korrekterweise, wenn keiner zuhause ist, nur die Start- und Endzeiten werden m.E. inkorrekterweise ignoriert (v.a. die Startzeit):
sub BBPresent()
{
return(ReadingsVal("EG.XX.RS.Bewohner","presence","absent") eq "present");
}
Leider komme ich hier selbst nicht weiter und hoffe, dass mir jemand weiterhelfen kann. Sollten noch irgendwelche Informationen fehlen, liefere ich die gerne nach.
Ach ja, FHEM ist auf dem aktuellen Stand, letztes update hat gestern erfolgreich stattgefunden. Das Problem besteht aber anscheinend schon länger. Entsprechende Einträge finden sich im gesamten fhem-Log des aktuellen Monats.
Gruß Benni.
Ich prüfe das heute oder morgen
Hallo Dietmar,
ich habe mich mal (bisher nur "theoretisch) mit dem RandomTimer beschäftigt (und gleichzeitig eine Wiki-Seite angelegt: http://www.fhemwiki.de/wiki/RandomTimer). Dabei sind mir in der commandref einige Dinge aufgefallen, die korrigiert / ergänzt werden müssten.
In welchem Format darf ich Dir meine Kommentare zukommen lassen (kann gern auch das Format sein, das als Input für die commandref dient - ich vermute, in dem Fall könnte ich mir das einfach aus der 98_RandomTimer.pl nehmen)?
Eine weitere Anmerkung: nachdem das Modul seit geraumer Zeit "offiziell" ist, wäre es gut, wenn Du es aus dem ersten Post dieses Threads entfernen würdest.
Gruß, Peter
Du kannst mir einfach die aktuelle ModulVersion angereichert mit deinen Verbesserungen geben. Dann mische ich die Änderungen hinein.
Ich habe mir das Verhalten von RandomTimer_Wakeup() angesehen und du hast Recht, ich muss sie verändern.
Nach dem umfangreichen Umbau vor 4 Wochen funktioniert die Zusammenarbeit zwischen RandomTimer_Wakeup und dem Rest des Moduls nicht mehr richtig. Da ich diese Funktion selbst nicht nutze, ist mir das nicht aufgefallen.
Ich habe die notwendige Änderung bei mir schon eingebaut und beobachte noch, ob auch wirklich alles funktioniert.
Bis zum Wochenende werde ich sie dann einchecken.
Hallo Dietmar,
danke für die prompte Bestätigung!
Man zweifelt eben doch immer erst mal an sich selbst :)
Problem mit RandomTimer_Wakeup():
eingecheckt!
Prüf' bitte, ob es jetzt auch bei dir wieder funktioniert.
Hallo Dietmar
Habe erst gestern Abend das Update durchgeführt und meinen RandomTimer wieder aktiviert.
Heute Morgen nach verlassen des Hauses wurde korrekterweise ein RandomTimer_Wakeup ausgeführt und seither gibt es im Log keine unerwarteten Schaltungen vom RandomTimer.
Werde das dann heute Abend nochmal nach eintreten der Startzeit prüfen, d.h. Ob dann korrekt geschaltet wird.
Das Ergebnis reiche ich dann noch nach, aber soweit sieht es erst mal gut aus!
Danke!
Gruß Benni
Hallo Dietmar,
ich konnte nun gestern Abend einige RT-Schaltungen "live" beobachten.
Es scheint wieder zu funktionieren, wie gehabt.
Ich bin zwar der Meinung, dass das disabledCond früher etwas schneller ausgewertet wurde, quasi prompt beim umschalten auf 1, aber da bin ich mir nicht mehr ganz so sicher und mag mich auch irren.
Für mich ist das Problem so gelöst.
Vielen Dank!
Gruß Benni.
ZitatIch bin zwar der Meinung, dass das disabledCond früher etwas schneller ausgewertet wurde, quasi prompt beim umschalten auf 1, aber da bin ich mir nicht mehr ganz so sicher und mag mich auch irren.
Dafür habe ich vielleicht eine Erklärung und kann auch das ändern.
Wenn es klappt checke ich es wieder ein.
Hallo!
Ich möchte eine Anwesenheitssimulation während unseres Urlaubs laufen lassen. Ich wollte mich an diesem Thread hier orientieren, jedoch wurde mein Vorhaben erschwert. Ich habe mir von https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/98_RandomTimer.pm (https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/98_RandomTimer.pm) die aktuelle Version von Random_Timer kopiert, in das /FHEM Verzeichnis kopiert und mit reload nachgeladen. Ich erhalte trotzdem immer noch diese Meldung:
Wrong timespec Verreist: either HH:MM:SS or {perlcode}
in der fhem.cfg habe ich folgendes eingetragen:
#
define Verreist dummy
attr Verreist group Commands
attr Verreist room Wohnzimmer
attr Verreist webCmd ja:nein
#
define ZufallsTimerTisch RandomTimer *{sunset_abs("REAL")} LampeTisch Verreist 22:00 480 800/100
#
Im Einsatz habe ich FHEM 5.5 auf Fritzbox 7390 in der Version von AVM
Was ist zu tun?
Definition ist falsch. Siehe Commandref.
etwa so:
define ZufallsTimerTisch RandomTimer *{sunset_abs_rand(40)} StehlampeTisch +02:30:00 480
attr ZufallsTimerTisch disableCond (!isVerreist())
Hallo,
heute habe ich mich ein wenig gewundert, als ich nach ein paar Tagen nach Hause kam.
Denn eine Beleuchtung war noch an, welche normalerweise durch einen RandomTimer geschaltet wird.
Die Config des RandomTimers sieht so aus:
Internals:
CFGFN
COMMAND off
DEF *{sunset("HORIZON=-1")} EG_ku_SD_IndirekteBeleuchtung 22:30:00 500
DEVICE EG_ku_SD_IndirekteBeleuchtung
NAME UrlaubTimer
NR 131
REL
REP *
SIGMAOFF 800
SIGMAON 200
STARTTIME 31.05.2014 21:35:31
STATE 21:35:31
STOPTIME 31.05.2014 22:30:00
SWITCHMODE 800/200
S_REL
S_REP
TIMESPEC_START *{sunset("HORIZON=-1")}
TIMESPEC_STOP 22:30:00
TIMETOSWITCH 500
TYPE RandomTimer
active 0
startTime 1401564931
stopTime 1401568200
Timer:
Urlaubtimer_exec:
HASH UrlaubTimer
MODIFIER Exec
NAME UrlaubTimer_Exec
Urlaubtimer_settimer:
HASH UrlaubTimer
MODIFIER SetTimer
NAME UrlaubTimer_SetTimer
Attributes:
group Urlaub
switchmode 400/600
verbose 5
Und das Log von gestern abend so:
2014.05.30 21:34:24 3: [UrlaubTimer] starting RandomTimer on EG_ku_SD_IndirekteBeleuchtung: 21:34:24(30) - 22:30:00(30)
2014.05.30 21:34:24 4: [UrlaubTimer] Zustand:on sigma:600 random:66
2014.05.30 21:34:24 4: [UrlaubTimer] command: set EG_ku_SD_IndirekteBeleuchtung off
2014.05.30 21:34:24 3: CUL_HM set EG_ku_SD_IndirekteBeleuchtung off
2014.05.30 21:34:24 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 21:34:24 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 21:42:28
2014.05.30 21:42:28 4: [UrlaubTimer] Zustand:off sigma:400 random:857
2014.05.30 21:42:28 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 21:42:28 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 21:51:04
2014.05.30 21:51:04 4: [UrlaubTimer] Zustand:off sigma:400 random:133
2014.05.30 21:51:04 4: [UrlaubTimer] command: set EG_ku_SD_IndirekteBeleuchtung on
2014.05.30 21:51:04 3: CUL_HM set EG_ku_SD_IndirekteBeleuchtung on
2014.05.30 21:51:04 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 21:51:04 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 21:59:11
2014.05.30 21:59:11 4: [UrlaubTimer] Zustand:on sigma:600 random:796
2014.05.30 21:59:11 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 21:59:11 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 22:07:38
2014.05.30 22:07:38 4: [UrlaubTimer] Zustand:on sigma:600 random:933
2014.05.30 22:07:38 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 22:07:38 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 22:16:00
2014.05.30 22:16:00 4: [UrlaubTimer] Zustand:on sigma:600 random:721
2014.05.30 22:16:00 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 22:16:00 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 22:24:37
2014.05.30 22:24:37 4: [UrlaubTimer] Zustand:on sigma:600 random:757
2014.05.30 22:24:37 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 22:24:37 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 30.05.2014 22:32:51
2014.05.30 22:31:00 4: [UrlaubTimer] timings for RandomTimer on EG_ku_SD_IndirekteBeleuchtung: 21:35:31(31) - 22:30:00(31)
2014.05.30 22:31:00 5: [UrlaubTimer] removing Timer: UrlaubTimer_Exec
2014.05.30 22:31:00 5: [UrlaubTimer] setting Timer: UrlaubTimer_Exec 31.05.2014 21:35:31
2014.05.30 22:31:00 5: [UrlaubTimer] removing Timer: UrlaubTimer_SetTimer
2014.05.30 22:31:00 5: [UrlaubTimer] setting Timer: UrlaubTimer_SetTimer 31.05.2014 22:31:00
Um 21:51:04 scheint das Licht vom RandomTimer noch eingeschaltet worden zu sein.
Nur warum ist das nicht mehr ausgegangen?
Ist die Config nicht so zu verstehen, dass zwischen sunset("HORIZON=-1") und 22:30:00 das Licht zufällig ein- und wieder ausgeschaltet wird?
Oder muss ich da zum Ende des RandomTimers immer mit einem at noch dafür sorgen, dass das Licht ausgeschaltet wird?
Zum Einsatz kommt im übrigen diese Version:
# $Id: 98_RandomTimer.pm 5879 2014-05-17 16:56:20Z dietmar63 $
Ich habe das leider auch festgestellt. Ich kann mich aber erst ab morgen abend wieder darum kümmern - Kurzurlaub in Dresden.
ich habe die Ursache eventuell gefunden - muss aber jetzt noch einige Tage testen.
Moin,
kein Problem. Derzeit habe ich auch keinen Urlaubsmodus mehr aktiv.
Leider >:(
Eingecheckt
probier' den RT nochmals aus - sollte nun funzen.
Es gab nach der großen Umstrukturierung von RT ein Probem mit dem Abschalten nach Mitternacht.
Was heisst denn "Abschalten nach Mitternacht"?
Denn nach Mitternacht ist ja irgendwie auch wieder vor Mitternacht :)
Bei mir war ja Abschaltung für 22:30 geplant.
Egal. Ich mache morgen mal ein Update und teste und berichte dann.
Kurz nach Mitternacht werden in RT die timings des frisch angebrochenen Tages ermittelt.
Damit soll erreicht werden, dass sunrise und ... immer die aktuellen ss/sr des Tages ermitteln.
Wenn ein Timer über den Tag hinaus läuft verschiebt sich die Zeit der Ermittlung auf
AbschaltzeitAktuellerTimer + 60 Sekunden. 60 Sekunden war falsch, weil das Setzen der timings so knapp nach der Abschlatzeit die noch laufenden Timer gelöscht hat. Der Abschaltbefehl wurde deshalb nicht mehr ausgeführt.
Jetzt erfolgt das Setzen der timings immer um AbschaltzeitAktuellerTimer+timeToSwitch+15Sekunden. Dann sollte der Abschaltbefehl tatsächlich erfolgt sein.
Probiers aus ob es funzt - bei mir hat es jedenfalls geklappt.
So, nach ein paar Tagen kann ich nun mein Feedback geben.
Es klappt. Licht geht nun brav an und aus.
Danke Dir und schöne Pfingsttage
Hallo,
ich kann mit:
# FunkSchalter mit Code 2
define Lampe_TV GenShellSwitch /usr/local/sbin/send433 10000 2 1 0
attr Lampe_TV group Licht
attr Lampe_TV room Wohnzimmer,Licht
#
define Verreist dummy
attr Verreist devStateIcon ja:status_away_1:nein nein:status_available:ja
attr Verreist group Commands
attr Verreist icon it_i-net
attr Verreist room Info
attr Verreist webCmd ja:nein
#
define ZufallsTimer2 RandomTimer *{sunset_abs('REAL')} Lampe_TV *{sunset_abs('REAL',2*3600)} 300
attr ZufallsTimer2 disableCond (!isVerreist())
attr ZufallsTimer2 switchmode 660/400
meine Funksteckdosen in der gegebenen Zeit schalten lassen. Funktioniert gut!
Nun möchte ich aber, wenn ich zuhause bin, die Lampe auch automatisch zum Sonnenuntergang einschalten und um 22:00 Uhr wieder ausschalten.
Dafür habe ich:
define ZufallsTimer4 RandomTimer *{sunset_abs('HORIZON=3')} Lampe_TV 22:00:00 999
attr ZufallsTimer4 switchmode 999/000
einprogrammiert.
Aber, wie muss ich disableCond setzen, dass eben gerade wenn ich nicht verreist bin funktioniert?
Danke für eure Hilfe
Bracew
P.S. Kann ich die Lampe auch automatisch in der oben genannten Zeit einschalten lassen, wenn der Fernseher läuft? und wenn ja, wie?
Die Fernbedienung des Fernsehers habe ich mit:
define SamsungTV7090 STV 192.168.0.102 55000
define SamsungRC remotecontrol
attr SamsungRC rc_iconpath icons/remotecontrol
attr SamsungRC rc_iconprefix black_btn_
attr SamsungRC room Wohnzimmer
attr SamsungRC row00 POWEROFF,TV,HDMI
attr SamsungRC row01 :blank,:blank,:blank
attr SamsungRC row02 1,2,3
attr SamsungRC row03 4,5,6
attr SamsungRC row04 7,8,9
attr SamsungRC row05 :blank,0,PRECH
attr SamsungRC row06 :blank,:blank,:blank
attr SamsungRC row07 VOLUP:UP,MUTE,CHUP
attr SamsungRC row08 :VOL,:blank,:PROG
attr SamsungRC row09 VOLDOWN:DOWN,CH_LIST,CHDOWN
attr SamsungRC row10 MENU,:blank,GUIDE
attr SamsungRC row11 :blank,:blank,:blank
attr SamsungRC row12 TOOLS,UP,INFO
attr SamsungRC row13 LEFT,ENTER,RIGHT
attr SamsungRC row14 RETURN,DOWN,EXIT
define notify_SamsungRC notify SamsungRC set SamsungTV7090 $EVENT
in FHEM drin und funktioniert auch.
Für einen Anfänger fühle ich mich schon ganz schön Stolz das alles so klappt.
Ich danke allen, bei denen ich habe den Code abgucken dürfen!
attr ZufallsTimer2 disableCond (isVerreist())
Ohne ! Bekommst du genau das gegenteilige Verhalten.
Danke für Deine schnelle Antwort Dietmar63,
habe gerade die Zeile mit disableCond gelöscht und werde heute abend die Lampe beobachten.
Ich hatte auch schon das Modul Twilight mal versucht, habe es aber nicht hinbekommen.
Wie müsste ich Twilight für die selbe Aufgabe programmieren, damit die Lampe abhängig von twilight_weather kleiner 60% zum Beispiel bis 22 Uhr eingeschaltet ist und danach wieder aus, aber nur wenn ich nicht verreist bin?
Gruß Bracew
Hallo Dietmar63,
ich habe da nochmal drüber nachgedacht und habe Fragen.
Ich vermute nun, dass wenn ich die Zeile mit disableCond lösche, der Zufallstimer4 immer geschaltet wird, also in beiden Fällen, ob ich nun verreist bin oder ob ich zuhause bin.
Ich würde aber gerne nur dann den Zufallstimer4 schalten lassen, wenn ich zuhause bin und den Zufallstimer 2 wenn ich weg bin.
Könnte ich irgendwie definieren, dass Zuhause das Gegenteil von Verreist ist,
und den Zufallstimer4 mit zum Beispiel:
attr ZufallsTimer4 disableCond (!isNOTVerreist())
oder
attr ZufallsTimer4 disableCond (!isZuhause())
irgendwie beeiflussen???
Oder, welche Möglichkeit gäbe es mit einem sinngemäßen
IF verreist THEN Zufallstimer2 ELSE Zufallstimer 4 ?
Mit lieben Grüßen Bracew
P.S. Frohe Pfingsten
Es reicht, wenn du das ! Vor dem isVerreist () weglässt. Das ! Ist das NOT in Perl.
Also timer2: !IsVerreist () und timer4: isVerreist ().
Es gibt mehrere Möglichkeiten mit TW eine Lampe anzuschalten.
1) mit zwei at. Das erste at nutzt per Perl Funktion ein Reading von Tw.
2) WeekdayTimer mit zwei Schaltzeiten. Auch mit WeekdayTimer ist es möglich eine Schaltzeit über eine Funktion zu ermitteln. In der Condition fragt man dann noch die Anwesenheit ab.
3) anschalten mit notify. Dann von TW das Reading aktEvent auf ss_weather abfragen und einschalten. Mit einem At dann um 22 Uhr abschalten.
Wenn du noch Beispiele benötigst, morgen Abend habe ich Zugriff auf mein fhem. Heute nur eine Kurze Antwort über das Handy.
Hallo Dietmar63,
danke! Hat sehr gut funktioniert mit NOT bzw. nicht NOT, also ohne !
Für Beispiele zu Twilight wäre ich auch sehr dankbar. Je mehr, desto besser.
Lass Dir aber Zeit, Pfingsten bei diesem Wetter zu geniesen ist wichtiger! <- Ausrufezeichen kein NOT
Bracew
define hc4 WeekdayTimer Lampe so-sa|{sunrise_abs(500)}|off so-sa|{sunset_abs(500)}|on (if (PerlFunktionAnwesend()))
define hc4 WeekdayTimer Lampe so-sa|{ReadingsVal("myTwilight","ss_weather","20:00:00")}|off so-sa|22:00|on
define TwilightMessage1 notify Twilight.*:aktEvent:.*ss_weather.* set StehlampeTisch on;; define yy at +00:00:05 set StehlampeTV on
define TwilightMessage2 notify Twilight.*:aktEvent:.* {Log 3, "Nachricht von @: %"}
Ich hoffe du verstehst die Beispiele auch ohne Erklärung.
Zum Test immer verbose 5 setzten
Ohhh, das würde ich auch gerne hoffen, dass ich die Beispiele auch ohne Erklärung verstehen würde!
Jedenfalls, einfach hast Du es mir nicht gemacht.
Nur, denk immer daran, nicht alle sind solche FHEM-Perl-Meister wie Du, und ich schon gar nicht.
In dieser Woche werde ich versuchen Deine Beispiele in meinem FHEM nachzubauen mit meinen Bezeichnungen.
Kann ich auch anstatt ss_weather auf twilight_weather abfragen, also einfach ersetzen aus deinem Beispiel?
Gruß Bracew
ZitatKann ich auch anstatt ss_weather auf twilight_weather
Kann ich nicht empfehlen. Der Wert twilight_weather wird alle 5 Minuten neuer ermittelt. Man kann aber nicht vorhersagen welchen Werte er dann hat. Somit ist es schwer ein notify darauf zu bauen. Du müßtest immer auch die Richtung des Wertes kennen um sagen zu können, ob du es mit einem Sonnenuntergang oder Sonnenaufgang zu tun hast.
Wenn du Fragen hast. Dafür ist das Forum da!
Ich habe da die letzten Tage mal twilight_weather im Event Monitor beobachtet.
Sobald es am Abend dunkler wird läuft er von 100% gegen 0%
und am Morgen wieder von 0% gegen 100%.
Dies liegt wohl am Sonnenstand korrigiert um die Verschattung durch Wolken aus dem großräumigen Wetterbericht.
So wie ich es verstehe, ist der Wert etwas geringer, wenn mehr Bewölkung vorhergesagt ist und etwas höher, wenn klarer Himmel.
Ich wollte gerne am Abend die Lampe bei Unterschreitung von 65% twilight_weather einschalten und um 22:00 Uhr wieder ausschalten lassen, alles aber nur wenn ich Zuhause bin.
Mit meiner jetzigen Definition:
define ZufallsTimer4 RandomTimer *{sunset_abs('HORIZON=1')} Lampe_TV 22:00:00 300
attr ZufallsTimer4 switchmode 999/000
attr ZufallsTimer4 disableCond (isVerreist())
komme ich dem Ziel schon recht nahe, habe aber leider den Verschattungsfaktor durch Wolken nicht mit drin, da, wenn es wolkig ist, es etwas früher dunkler wird. Mit meiner jetzigen Definition wird aber nur Abhängig vom Sonnenstand von FHEM die Lampe geschaltet.
Krönung wäre dann noch, wenn die Lampe nur schaltet, wenn ich zuhause und der Fernseher (TV) läuft, deshalb heißt es ja Lampe_TV.
Gruß Bracew
mit
define ZufallsTimer4 RandomTimer *{ReadingsVal("myTwilight","ss_weather",sunset_abs('HORIZON=1'))} Lampe_TV 22:00:00 300
hast du die Wetterkomponente drin.
Es gibt noch die Möglichkeit mit set ZufallsTimer4 disable oder set ZufallsTimer4 enable den timer bei Bedarf an- oder abzuschalten. Dies kannst du machen indem du die Ereignisse TV(an/aus) und du (anwesend oder nicht) per notify überwachst und das set Kommando ausführst.
Eine weitere Möglichkeit besteht darin, die disableCond so zu setzten, dass nur dann geschaltet wird, wenn TV an und du anwesend.
Hallo Dietmar63,
wiederum vielen Dank für Deine Hinweise.
Ich habe das mit dem Fernseher wie folgt umgesetzt:
define Lampe_TV_An notify SamsungTV7090 \
IF (([SamsungTV7090] eq "connected" \
or [SamsungTV7090] eq "opened")) \
(set Lampe_TV on) \
ELSE \
(set Lampe_TV off)
Das hat funktioniert. Mit einer kleinen zeitlich variablen Verzögerung ist die Lampe_TV angegangen, wenn ich den Fernseher mit der Fernbedienung eingeschaltet habe. Und auch wieder aus bei abschalten des Fernsehers. Alles natürlich unabhängig von der Dämmerung und unabhängig von An- oder Abwesendheit.
Nun habe ich die An-/Abwesendheitskomponente analog Deines Vorschlags vom Pfingstmontag abend wie folgt hinzugefügt:
define Lampe_TV_An notify SamsungTV7090 \
IF (([SamsungTV7090] eq "connected" \
or [SamsungTV7090] eq "opened")) \
(set Lampe_TV on) \
ELSE \
(set Lampe_TV off)
IF ([isVerreist()] eq "ja") \
(set Lampe_TV_An disable) \
ELSE \
(set Lampe_TV_An enable)
Dann bekomme ich jedoch beim speichern von fhem.cfg die Fehlermeldung:
ERROR:
No set implemented for Lampe_TV_An
Kannst Du mir noch mal helfen, wie ich zum einen die An-/Abwesendheitskomponente und zum anderen die Wetterkomponente mit ON bei Unterschreitung von 65% twilight_weather hinbekommen?
Übrigens, ist gestern bei unseren starken Gewittern der Himmel sehr schnell dunkel geworden. Das twilight_weather war zu dieser Zeit nach unten gerauscht auf 0% obwohl twilight selbst noch bei ca. 45% war.
Mit lieben Gruß Bracew
kann man eine notify disablen?
set Lampe_TV_An enable
Keine Ahnung, deshalb frage ich ja nach und will was lernen!
Aber wenn Du so fragst, scheinbar nicht! oder?
Also, wie dann?
Ich habe die Antwort nicht parat. Kannst du aber in der Oberfläche des Gerätes ausprobieren
Wenn ich:
set Lampe_TV_An enable
in das Eingabefeld oben eingebe kommt der gleiche Fehler:
No set implemented for Lampe_TV_An
Ich komme so nicht weiter.
In der Funktionsbeschreibung zu notify steht: "...per Web editieren und den DEF Knopf benutzen....". Meinst du das?
Leider habe ich diesen Satz halt auch nicht verstanden. Welchen DEF Knopf? Und wie per Web editieren?
Du hast mal geschrieben:
ZitatWenn du Fragen hast. Dafür ist das Forum da!
Meinst Du damit ich müsste hier im Forum an anderer Stelle fragen?
Und was meinst Du mit:
ZitatIch habe die Antwort nicht parat.
Soll es heißen, z.B. kann gerade nicht, helfe später gerne weiter und melde mich wieder
oder soll es heißen, z.B. ich mag nicht mehr, laß mich bitte zufrieden.
Beides kann ich verstehen und akzeptieren, möchte aber nicht gern interpretieren sondern eine klare Ansage bekommen.
Danke.
Bracew
Ich saß vorhin im Zug.
Dein Test besagt, dass ein notify nicht disabled werden kann.
Mit DEF ist gemeint, dass du in der Raumübersicht auf den Namen eines Gerätes clicken kannst. Dann kommt eine Detailinformationen zum Gerät. Dort gibt es dann ein def.
Bin jetzt leider unterwegs
Zitat von: Dietmar63 am 11 Juni 2014, 12:22:01
kann man eine notify disablen?
set Lampe_TV_An enable
Ja, per Attribut.
Hallo stromer-12
gibst Du mir ein Beispiel?
Ich möchte sinngemäß, die Lampe einschalten, wenn TV ein ist, ich nicht verreist bin und twilight_weather unter 65% rutscht. Dies hatte ich im Ansatz versucht mit:
define Lampe_TV_An notify SamsungTV7090 \
IF (([SamsungTV7090] eq "connected" \
or [SamsungTV7090] eq "opened")) \
(set Lampe_TV on) \
ELSE \
(set Lampe_TV off)
IF ([isVerreist()] eq "ja") \
(set Lampe_TV_An disable) \
ELSE \
(set Lampe_TV_An enable)
Wie würde das mit dem Attribut im IF funktionieren?
Gruß Bracew
Zitat von: Bracew am 12 Juni 2014, 06:45:57
Hallo Bracew,
IF ([isVerreist()] eq "ja") \
(set Lampe_TV_An disable) \
ELSE \
(set Lampe_TV_An enable)
Wie würde das mit dem Attribut im IF funktionieren?
Sollte so gehen:
IF ([isVerreist()] eq "ja") \
(attr Lampe_TV_An disable 1) \
ELSE \
(attr Lampe_TV_An disable 0)
so
define Lampe_TV_An notify SamsungTV7090 \
IF (([SamsungTV7090] eq "connected" \
or [SamsungTV7090] eq "opened")) \
(set Lampe_TV on) \
ELSE \
(set Lampe_TV off)
IF ([isVerreist()] eq "ja") \
(set Lampe_TV_An disable) \
ELSE \
(set Lampe_TV_An enable)
wird das nicht funktionieren.
Du benötigst die Überwachung zweier Ereignisse. Die Ereignisse überwachst du mit notify.
Ich liefere jetzt nur Beipspielcode. Er ist nicht vollständig, aber du kannst ihn hoffentlich auf deine Verhältnisse anpassen.
Ich bin kein Freund von IF, deshalb liefere ich nur Perlcode. Wenn du IF verwenden willst, musst du Damian ansprechen. Er hat das IF-Gerät gebaut.
zwei notify:
define Lampe_TV_An1 notify SamsungTV7090 {lampeAnFunktion()}
define Lampe_TV_An2 notify AnwesenheitsStauts {lampeAnFunktion()}
99_myUtils.pm
sub lampeAnFunktion() {
my $TVstatus = Value("SamsungTV7090"); # ReadingsVal(...) ist auch nutzbar.
my $anwesenHeit = Value("ichselbst");
if ( ($TVstatus eq "connected" || $TVstatus eq "opened") ) && anwesenheit eq "ja" && !isVerreist() ) {
fhem("set LampeTV on")
}
}
Der Code ist nur ein Beispiel, enthält möglicherweise noch Fehler, aber sollte gut darstellen wie du es machen kannst.
Wichtig ist, dass alle Ereignisse, die du berücksichtigen willst, die gleiche Perlfunktion rufen. Dann kannst du dort alles nocheinmal komplett abfragen, und schalten.
Zitat
Ich wollte gerne am Abend die Lampe bei Unterschreitung von 65% twilight_weather einschalten und um 22:00 Uhr wieder ausschalten lassen, alles aber nur wenn ich Zuhause bin.
auch hier musst du mit einem notify arbeiten:
define TwilightMessage1 notify myTwilight.*:twilight_weather:.* {lampeAnFunktion2()}sub lampeAnFunktion2() {
my $tww = ReadingsVal("myTwilight", "twilight_weather", "none");
my $anwesenHeit = Value("ichselbst");
if ($tww < 65 && $anwesenHeit = "ja" ) {
fhem("set LampeTV on");
}
}
Wenn du testest, dann bitte immer gleich die wichtigen Variablen loggen. Dann findet man die Fehler besonders schnell.
Hallo stromer-12
auch Dir danke , hat aber leider nicht funktioniert.
Gruß Bracew
Hallo Dittmar63,
ich habe Deinen Vorschlag und die "Funktionsbeschreibung zu notify" aus FHEM Wiki als Grundlage für folgendes genommen:
define irgendwas notify (myTwilight.*:twilight_weather:.*|SamsungTV7090|Verreist) { \
my $r1 == $value{"ReadingsVal("myTwilight", "twilight_weather", "none")"};; \
my $r2 == $value{"SamsungTV7090"};; \
my $r3 == $value{"Verreist"};; \
if ($r1 lt 80 && $r2 eq "opened" && $r3 eq "nein") { \
fhem "set Lampe_TV on" \
} else { \
fhem "set Lampe_TV off" \
} \
}
funktioniert aber auch nicht. Und ich war schon so hoffnungsvoll.
Wie kann ich den kleinen Codeschnippsel debugen?
Oder hast Du mir eine weitere Hilfe zur Lösung?
Gruß Bracew
lies dir bitte folgenden Beitrag durch:
http://forum.fhem.de/index.php/topic,24361.msg174783.html#msg174783 (http://forum.fhem.de/index.php/topic,24361.msg174783.html#msg174783)
wichtiger Satz:
ZitatAm Besten über einen externen Editor (aus Windows oder Linux) direkt bearbeiten und per reload in fhem nachladen
In einem exteren Editor wie notepad, pspad, padre oder ... bekommst Syntaxhighlighting. Dann sieht dein Code so aus wie im Anhang. Man sieht an den Farben schon wo etwas falsch sein könnte.
fhem.cfg
define irgendwas notify (myTwilight.*:twilight_weather:.*|SamsungTV7090|Verreist) {lampeAn()}
99_myUtils.pm
sub lampeAn() {
my $r1 = ReadingsVal("myTwilight", "twilight_weather", "none");
my $r2 = Value("SamsungTV7090");
my $r3 = Value("Verreist");
Log 3, "r1------------>$r1";
Log 3, "r2------------>$r2";
Log 3, "r3------------>$r3";
if ($r1 <= 80 && $r2 eq "opened" && $r3 eq "nein") {
fhem ("set Lampe_TV on")
} else {
fhem ("set Lampe_TV off")
}
}debuggen leider nur so:
Log 3, "r3------------>$r3";
nun noch etwas zu den von dir gemachten Fehlern:
$value ist eine Variable. Du musst aber die Funktion Value() aufrufen. Die Parameter einer Funktion werden in () angegeben. {} greifen in Perl auf hash zu. So etwas wie assoziative Arrays(falls dir das etwas sagt).
wenn du direkt in der 99_myUtils arbeitest, dann benötigst du am Ende keine ;;/ Man erstellt direkt Perlcode und kann direkt auf Dokumentation im Web zurückgreifen. Wenn ud in der fhem.cfg nach einem notify Code in geschweiften {} eingibst ist das nur syntaktisch ungeprüfter Text, der viele Fehler enthalten kann.
$r1 <= 80
Perl unterscheidet zwischen numerischem Vergleich: == <= >= und Stringvergleich: eq lt gt
Wenn man in fhem weit kommen will, muss man in Perl programmieren lernen. Das dauert ein wenig - lohnt aber sehr!!!
damit der Erfolg sich schnell einstellt kannst du den Code
sub lampeAn {...}
so wie er ist über die fhem-Oberfläche in die existierende 99_Utils vor ein sub kopieren und speichern.
Ich habe gerade FHEM aktualisiert. Jetzt ist mir aufgefallen, dass die Anzeige der RandomTimer geändert ist?! Vor dem Update wurde immer die Uhrzeit des nächsten Starts und nach Aktivierung der Zustand des Aktors angezeigt. Jetzt gibt es nur noch die Info, ob der RandomTimer aktiv ist oder nicht ...
Gibt es eine einfache Möglichkeit, auf die alte Anzeige des RandomTimer zu switchen - war in meinen Augen ganz praktisch?
Danke und Grüße.
kennst du
attr device stateFormat {InternalVal("device","STARTTIME","notFound")}
eventuell noch mit substr nachbearbeiten, wenn du das Datum nicht haben möchtest.
Danke für die schnelle Antwort! :)
Mit stateFormat habe ich bislang noch nicht gearbeitet, aber gleich mal getestet. Eingesetzt beim RandomTimer (siehe unten) ändert sich nichts, in abgewandelter Form bei einer Lampe angetestet, funktioniert eine solche Lösung dagegen?!
define ZufallsTimer_SZ RandomTimer *22:45 sz_Tischleuchte 23:43 550
attr ZufallsTimer_SZ disableCond (!AnwSim())
attr ZufallsTimer_SZ stateFormat {InternalVal("ZufallsTimer_SZ","STARTTIME","notFound")}
attr ZufallsTimer_SZ switchmode 800/200
Trotz des stateFormat-Eintrags wird immer noch der Status angezeigt. :(
das muss ich mir etwas genauer ansehn
Danke dir!
Ich hab auch noch etwas getestet - bei normalen Aktoren (bei mir HM) funktioniert stateFormat ohne Probleme, bei Dummys dagegen bleibt das Ganze ohne Wirkung.
bei meinem RT klappt es auf Anhieb:
Gibt's doch nicht ... dann muss ich nachher noch mal ran ... testen :-[
Was ist eigentlich der Hintergrund der Änderung? Ich fand die Anzeige von "Startzeit - an/aus - down" eigentlich ganz gut, da hatte man von "unterwegs" immer sofort die komplette Info, was daheim Licht-technisch passiert?!
so wie es jetzt ist, ist der timer on, wenn er aktiv ist. In der alten Version war der Zustand immer so wie das zu schaltende Gerät. Das fand ich nicht mehr richtig.
Mit stateFormat läßt sich dieses Verhalten verändern.
Sooo ... ich bin ein Stück weitergekommen:
Wenn ich stateFormat über Web-UI definiere, funktioniert die Anzeige von Datum und Zeit. Sobald ich aber die fhem.cfg editiere (egal an welcher Stelle) und sichere, springt die Anzeige wieder auf default zurück, obwohl der stateFormat-Eintrag noch vorhanden ist ... komisch.
Hallo Dietmar,
Vielen Dank erstmal für dieses sehr nützliche Tool.
Mir ist allerdings aufgefallen, dass die Attribute "onCmd" und "offCmd" nur während der Laufzeit des Timers ausgewertet werden, leider jedoch nicht wenn dieser sich abschaltet :(. Hier wird m.E. nach stets das Standardkommando "off" verwendet.
Ein Beispiel:
Ich habe folgende RandomTimer Definition
define og_RTimerLichtDiele RandomTimer 19:04:00 og_LichtDiele +00:01:00 010
attr og_RTimerLichtDiele switchmode 500/100
attr og_RTimerLichtDiele disableCond (Value("wz_LichtAutoDecke" eq "0"))
attr og_RTimerLichtDiele onCmd {fhem("set @ on g2")}
attr og_RTimerLichtDiele offCmd {fhem("set @ off g2")}
Während der Laufzeit werdeb die in den Attributen hinterlegten Kommandos verwendet, wie man aus dem Logfile entnehmen kann:
2014.08.27 19:04:18 4: [og_RTimerLichtDiele] command: {fhem("set og_LichtDiele on g2")}
2014.08.27 19:04:18 5: Cmd: >{fhem("set og_LichtDiele on g2")}<
2014.08.27 19:04:18 5: Cmd: >set og_LichtDiele on g2<
2014.08.27 19:04:18 2: EIB set og_LichtDiele on g2
Beim Terminieren des Timers findet die Ersetzung jedoch nicht statt:
2014.08.27 19:05:03 3: [og_RTimerLichtDiele] RandomTimer for og_LichtDiele going down
2014.08.27 19:05:03 5: Cmd: >set og_LichtDiele off<
2014.08.27 19:05:03 2: EIB set og_LichtDiele off
Ich meine dieses Verhalten auch in Deinem Code (Zeile 224-225) erkannt zu haben, bewege mich hier aber auf sehr dünnem Eis, da ich absoluter Perl Newbie bin:
sub RandomTimer_down($) {
my ($hash) = @_;
$hash->{COMMAND} = AttrVal($hash->{NAME}, "keepDeviceAlive", 0) ? "on" : "off";
fhem ("set $hash->{DEVICE} $hash->{COMMAND}");
}
M.E. ist hier "on" und "off" fest verdrahtet.
Meine Frage nun ist, ist dieses Verhalten so gewünscht? Falls nicht wäre es Klasse, wenn man die Down Subroutine in der Distribution auch dahingehend ändern könnte, dass die Attribut Kommandos verwendet werden.
Schon mal vielen Dank
basi
da hast du verdammt recht.
werde ich ändern - werde aber noch ein wenig über die Lösung nachdenken.
Hört sich super an ... dann freue ich mich schon auf das nächste Update, dass auch bei mir die Lichter ausgehen ;).
basi
dauert noch - Fehler
@basi:
ich habe eine neue Version eingecheckt.
Kannst du bitte prüfen, ob dein Problem damit gelöst ist.
Hallo Dietmar,
funzt jetzt super. Auch an dieser Stelle nochmals vielen Dank fürs superschnelle debuggen.
Gruß
basi
Hallo zusammen,
ich habe den Random Timer für das Schalten von 2 Zimmerlampen am Abend erfolgreich integriert. Vielen Dank für das Modul.
Dabei wird über das Attribut
attr Timer_WZ_Lampe_Sofa1_Abends disableCond (isAnybodyAtHome())
geprüft, ob jemand anwesend ist oder nicht.
Ich würde gerne morgens das gleiche tun, mit der Erweiterung, dass auf das Wochenende getestet wird.
Es soll der Timer also nicht starten, wenn jemand anwesend ist oder am Wochenende:
attr Timer_WZ_Lampe_Sofa1_Morgens disableCond (isAnybodyAtHome() || $we)
scheint bei mir allerdings ohne Wirkung.
Hat jemand eine Idee, wie ich beide kombinieren kann?
Besten Gruss,
Peer
Ich melde mich heute Abend dazu
im Kontext der Abarbeitung des Funktionsaufrufs isAnybodyAtHome() steht die Variable $we nicht zur Verfügung.
Perl erzeugt leider keine Fehlermeldung.
Du kannst $we selbst in isAnybodyAtHome() ermitteln und auswerten:
my ($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime;
my $we = (($wday==0 || $wday==6) ? 1 : 0);
if(!$we) {
my $h2we = $attr{global}{holiday2we};
$we = 1 if($h2we && $value{$h2we} && $value{$h2we} ne "none");
}
...
ich kann das Modul wahrscheinlich noch verbessern, dann würdest du folgende Fehlermeldung bekommen:
Global symbol "$we" requires explicit package name at (eval 114) line 1.
2014.09.05 18:26:19 3: syntax error at (eval 114) line 1, near ") !"
Bevor ich das freischalte wird es aber noch etwas dauern.
Hallo Dietmar,
Vielen Dank für dein Support. Ich werde es morgen testen.
Beste Grüße,
Peer
Hallo nochmal,
hat alles geklappt.
Vielen Dank,
Peer
Zitatich kann das Modul wahrscheinlich noch verbessern, dann würdest du folgende Fehlermeldung bekommen: ...
habe das Modul geändert und eingecheckt.
Jetzt sollte im Log eine Fehlermeldung erscheinen, wenn du so etwas codierst:
attr Timer_WZ_Lampe_Sofa1_Morgens disableCond (isAnybodyAtHome() || $we)
Ich würde gerne verschiedene Lichtszenarien im Wohnzimmer (Deckenlicht, Wandleuchten, Stehlampen) i.V.m. dem RandomTimer schalten.
D.h. aktuell habe ich drei separate RandomTimer für Deckenlicht, Wandleuchten und Stehlampen und über eine Random-Funktion würde ich nun täglich
zufällig dann jeweils EINE DIESER DREI Lichtquelle schalten wollen. Durch das abwechselnde Einschalten von unterschiedlichen Lichtquellen während meiner Abwesenheit erhoffe ich mir noch ein höheres Abschreckungspotential....
Pseudo-Code:
my $Zufallszahl =int(rand(3));
IF $Zufallszahl= 1 then set RandomTimerDecke disable = 1 else disable = 0
IF $Zufallszahl= 2 then set RandomTimerWand disable = 1 else disable = 0
IF $Zufallszahl= 3 then set RandomTimerStehlampen disable = 1 else disable = 0
Soll ich statt disable eher das spezfische Attribut disableCond verwenden?
Stellt sich mir auch die Frage, wann der RandomTimer (und die disableCond) initialisiert werden.
D.h. muß ich die RandomTimer und die jeweilige disableCond vor Mitternacht setzen?
Oder gibt es evtl. einen anderen Lösungsansatz?
Danke vorab.
Du könntest jeden Tag so gegen Mitternacht ein dummy mit der Zufallszahl füllen:
define xxx at *00:01:00 {fhem ("set dummy " . int(rand(3)) )}
Erzeugt im dummy die Werte 0,1,2. Drei wird nicht gesetzt werden, weil int() abschneidet.
Dann würde ich 3 RT mit disableCond setzen:
define ZufallsTimer0 RandomTimer *{sunset()} StehlampeTisch +02:30:00 480
attr ZufallsTimer0 disableCond (!(Value("dummy") == 0))
define ZufallsTimer1 RandomTimer *{sunset()} StehlampeTisch +02:30:00 480
attr ZufallsTimer1 disableCond (!(Value("dummy") == 1))
define ZufallsTimer2 RandomTimer *{sunset()} StehlampeTisch +02:30:00 480
attr ZufallsTimer2 disableCond (!(Value("dummy") == 2))
Beachte das ! vor der Valuefunktion.
Setze bei deinen Test bei allen RT das Attribut verbose auf 5. Dann bekommst du Infos angezeigt.
Die dummy-Abfragen werden zur Laufzeit/Schaltzeit berücksichtigt.
Der Code oben ist nicht getestet und muss auf deine Namen hin angepasst werden.
WUNDERBAR! Vielen Dank für den Denkanstoss bzgl. Dummy-Ansatz und disableCond.
Probiere ich aus!
Zitat von: Dietmar63 am 06 Oktober 2014, 20:46:14
Du könntest jeden Tag so gegen Mitternacht ein dummy mit der Zufallszahl füllen:
...
...
...
Hallo,
der Zufallstimer sollte bei Anwesenheit deaktiviert sein. Geprüft wird das über Presence Funktion eines Mobiltelefons.
Nur leider sitze ich immer wieder im Dunkeln, selbst wenn ich zu Hause bin.
Erkennt jemand, was an der Abfrage zur disableCond falsch ist? Die Erkennung an sich klappt.
define Samsung_S3 PRESENCE fritzbox SGS3 60 180
attr Samsung_S3 devStateIcon present:status_available absent:status_away_2
attr Samsung_S3 event-on-change-reading state
define ZufallsTimerKugellampen RandomTimer *{sunset_abs()} Kugellampen 23:00:00 480
attr ZufallsTimerKugellampen disableCond (Value("Samsung_S3" eq "present"))
Besten Dank und viele Grüße
Norbert
Rt schaltet automatisch an/aus wie die Zufallsfunktion einer Zeitschaltuhr.
Prüf bitte mal ob Presence bei dir die richtigen Anwesenheiten ermittelt. Richtig zuverlässig ist die Methode nicht bzw. P muss gut eingestellt sein.
Hallo Dietmar,
eben getestet, die PRESENCE Funktion gibt den richtigen Wert aus. Muss ich den den Umweg über einen dummy Parameter gehen?
was wird ausgegeben wenn du in der Oberfläche von fhem
{Value("Samsung_S3")}
eingibst?
der Wert wird mit "present" ausgegeben. Anwesenheit wird also richtig erkannt.
setze mal bitte den verbose Wert auf 5. Vielleicht verstehen wir dann besser was passiert.
das wird zum Thema Presence und RT gelogged:
2014.11.01 19:03:14 3: [ZufallsTimerKugellampen] starting RandomTimer on Kugellampen: 17:27:27(01) - 23:00:00(01)
2014.11.01 19:03:14 4: [ZufallsTimerKugellampen] Zustand:off sigma:800 random:821
2014.11.01 19:03:14 5: [ZufallsTimerKugellampen] removing Timer: ZufallsTimerKugellampen_Exec
2014.11.01 19:03:14 5: [ZufallsTimerKugellampen] setting Timer: ZufallsTimerKugellampen_Exec 01.11.2014 19:11:07
2014.11.01 19:03:17 5: PRESENCE (Samsung_S3) - executing ctlmgr_ctl: /usr/bin/ctlmgr_ctl r landevice settings/landevice/count
2014.11.01 19:03:17 5: PRESENCE (Samsung_S3) - ctlmgr_ctl (getting device count) returned: 25
2014.11.01 19:03:17 5: PRESENCE (Samsung_S3) - executing ctlmgr_ctl: /usr/bin/ctlmgr_ctl r landevice settings/landevice0/name
2014.11.01 19:03:23 5: PRESENCE (Samsung_S3) - checking device number 11 (SGS3)
2014.11.01 19:03:23 5: PRESENCE (Samsung_S3) - executing ctlmgr_ctl: /usr/bin/ctlmgr_ctl r landevice settings/landevice11/active
2014.11.01 19:03:24 5: PRESENCE (Samsung_S3) - state for device number SGS3 is 1
2014.11.01 19:03:24 5: Cmd: >{PRESENCE_ProcessLocalScan('Samsung_S3|0|present|11')}<
2014.11.01 19:03:24 5: PRESENCE (Samsung_S3) - blocking scan result: Samsung_S3|0|present|11
2014.11.01 19:03:24 4: PRESENCE (Samsung_S3) - rescheduling next check in 180 seconds
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - stopping timer
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - starting blocking call for mode fritzbox
2014.11.01 19:06:24 5: PRESENCE_DoLocalFritzBoxScan: Samsung_S3|SGS3|0|0
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - try checking Samsung_S3 as device SGS3 with cached number 11
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - executing ctlmgr_ctl: /usr/bin/ctlmgr_ctl r landevice settings/landevice11/name
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - checking state with cached number (11)
2014.11.01 19:06:24 5: PRESENCE (Samsung_S3) - executing ctlmgr_ctl: /usr/bin/ctlmgr_ctl r landevice settings/landevice11/active
2014.11.01 19:06:25 5: PRESENCE (Samsung_S3) - ctlmgr_ctl (cached: 11) returned: 1
2014.11.01 19:06:25 4: Connection accepted from telnet:127.0.0.1:46156
2014.11.01 19:06:25 5: Cmd: >{PRESENCE_ProcessLocalScan('Samsung_S3|0|present|11')}<
2014.11.01 19:06:25 5: PRESENCE (Samsung_S3) - blocking scan result: Samsung_S3|0|present|11
2014.11.01 19:06:25 4: PRESENCE (Samsung_S3) - rescheduling next check in 180 seconds
2014.11.01 19:11:07 4: [ZufallsTimerKugellampen] Zustand:off sigma:800 random:892
2014.11.01 19:11:07 5: [ZufallsTimerKugellampen] removing Timer: ZufallsTimerKugellampen_Exec
2014.11.01 19:11:07 5: [ZufallsTimerKugellampen] setting Timer: ZufallsTimerKugellampen_Exec 01.11.2014 19:18:51
Müsste es für den disableCond eine Statusmeldung geben?
jetzt habe ich den Fehler gefunden. so ist es richtig:
attr ZufallsTimerKugellampen disableCond (Value("Samsung_S3") eq "present")
Bei deiner Version wird false an die Funktion Value() übergeben, und das ist kein Gerät.
Hast du die Woche neue Variante schon ausprobiert?
Perfekt, da war der Syntaxfehler! Bekomme jetzt im log:
2014.11.03 17:33:39 3: [ZufallsTimerKugellampen] RandomTimer for Kugellampen going down
Ich hatte die Klammern aus der commandref abgekupfert:
http://fritz.box:8083/fhem/docs/commandref.html#RandomTimer (http://fritz.box:8083/fhem/docs/commandref.html#RandomTimer)
attr ZufallsTimerZ disableCond (Value("presenceDummy" eq "notPresent"))
Muss die Syntax da richtiggestellt werden?
Herzlichen Dank für die kompetente Unterstützung!
Ja, danke für den Tipp - habe ich mich wohl vertan.
Hallo Dietmar
Ich habe mir an drei Lampen die Zufallsfunktion wie in Deinem erste Post beschrieben "gebaut".
Grundsätzlich funktioniert das auch. Allerdings habe ich Probleme mit der dummy-Variable "Verreist".
Wenn ich sie über das Web-Interface auf "nein" setze, wird die Zufallsfunktion für alle drei Lampen disabled; so wie es sein soll.
Allerdings bekomme ich die Funktion über das Umschalten auf "ja" nicht wieder aktiviert. Erst ein "Anfassen" des Attributs "disableCond" führt dazu, dass das "ja" übernommen wird - die ZufallsFunktion als aktiv ist.
Beim Deaktivieren - also Verreist auf "nein" - wird ja u.a. STATE auf "disable" und activ auf "0" gesetzt. In der Zeit werden auch keinerlei Einträge in die Logdatei geschrieben.
Ich habe den Eindruck, dass die Funktion RandomTimer dann gar nicht aufgerufen wird.
Kannst Du mir einen Tipp geben, wie ich die Funktion in beide Richtungen so zum Laufen bekomme, dass ich nur über "Verreist" ja:nein die Funktion ein- bzw. ausschalten kann- so wie es ja sicher von Dir auch gedacht war. ;-)
Viele Grüße
Ralph
Ich sehe mir das an.
Es wird aber ein wenig dauern, weil ich im Moment nicht so viel Zeit habe.
ich habe mir ein Dummy "Zeitsteuerung" erstellt welches 3 Möglichkeiten des "state" hat Aus, Dämmerung und Zufall
Ich bekomme es aber nicht hin das bei "Zufall" der RandomTimer aktiviert wird und auch wieder abgeschaltet wird wenn der "state" sich ändert.
Diese habe ich probiert: funktioniert mit keinem, wo ist mein Fehler?
attr ZufallsTimerAussenlicht disableCond (!isZufall())
bei obigen Eintrag zusätzlicher Eintrag in der 99_myUtils
sub isZufall () { return(YesNo("Zufall"));}
Diese beiden probiert aber es geht nicht
attr ZufallsTimerAussenlicht disableCond (!Value("TestZeitsteuerung" eq "Zufall"))
attr ZufallsTimerAussenlicht disableCond (ReadingsVal("TestZeitsteuerung", "state", "Zufall") eq "on" )
EDITH:// ich habe heute noch mal etwas getestet und ein Dummy erstellt.
Dummy Code:
#### Zeitsteuerung Dummy ###
define TestZeitsteuerung dummy
attr TestZeitsteuerung alias TestZeitsteuerung aktivieren
attr TestZeitsteuerung devStateIcon Aus:general_aus@lightgreen Zufall:general_an_fuer_zeit@Crimson
attr TestZeitsteuerung eventMap Aus Zufall
attr TestZeitsteuerung group TestSteuerung
attr TestZeitsteuerung icon time_clock
attr TestZeitsteuerung room Automation
attr TestZeitsteuerung setList state:Aus,Zufall
attr TestZeitsteuerung sortby 01
attr TestZeitsteuerung webCmd state
Sollte ich nicht durch das Dummy den RT aktivieren/deaktivieren können..
gefunden das dies mit disable geht.
Aber was ich nicht hin bekomme das der RT nur dann aktiv ist wenn mein Dummy auf "Zufall" steht, der RT geht auch so auf aktiv.
Zitat von: wingfighter am 12 November 2014, 20:48:54
Allerdings bekomme ich die Funktion über das Umschalten auf "ja" nicht wieder aktiviert. Erst ein "Anfassen" des Attributs "disableCond" führt dazu, dass das "ja" übernommen wird - die ZufallsFunktion als aktiv ist.
das ist genau das selbe wie ich geschrieben habe, mittlerweile habe ich mich mit dem RT beschäftigt, aktivieren/deaktivieren nur mit disable 1/0
Der RT reagiert nur einmalig auf disableCond, aktivieren damit geht nicht weil er das in dem Zeitrahmen STARTTIME und STOPTIME allein macht.
Soll heißen soweit ich das verstanden habe nur wenn du ihn ganz ausschalten möchtest mußt du ihn mit disable 1 auf "off" schalten, ansonsten startet er den nächsten Tag wieder mit deiner STARTTIME
Wie gesagt die Funktion Verreist ist nicht zum Ein/Aus schalten gedacht
Ich melde mich nachher dazu
Ich bin nicht ganz sicher, ob folgendes stimmt. Aber seinerzeit als ich den RT erfunden habe, ging ich von folgender Situation aus:
Der RT beginnt seine Arbeit so in der Dämmerung und schaltet die Lampe nach Zufall an/aus.
Zu Beginn des RT-Zeitraums wird geprüft, ob er disabled ist. Wenn ja, wird erst wieder am Anfang des nächsten Zykluses geprüft, ob der RT geschaltet werden muss.
Diese Annahme könnte dafür verantwortlich sein, dass während des eigentlichen Zyklusses kein einfaches Einschalten möglich ist. Es sei denn man setzt das Attribut "disable" oder "disableCond". Dann sollte der Timer auf die Funktion "RandomTimer_SetTimer" neu gestartet werden.
Ich überlege mal, wie ich das ändern kann.
nach einem Hinweis dies mit notify zu machen, habe das jetzt mit zwei notify und mit disable 0/1 gelöst, somit brauche ich den Code in der 99_myUtils nicht und das Attribut disableCond nicht ;)
Hallo,
ich habe hier mehrere RTs, die ich mittels eines DOIF auf disabled 0 oder 1 setze. Das funktioniert auch prima. Nur leider schalten die Lampen sich nicht an, wenn ich den RT innerhalb der START- STOPTIME auf disabled 0 stelle. Die RTs zeigen zwar STATE on und active 1 an - die Lampen bleiben aber aus :-\
Ich möchte halt, dass das Licht angeht, wenn ich innerhalb er START-STOPTIME das Haus verlasse. Ich meine auch, dass das schon mal funktioniert hat - in letzter Zeit aber nicht mehr...
Ist da irgendwas geändert worden oder mache ich etwas falsch?
Gruß
oelidoc
Es gab vor längerer Zeit eine größere Änderung. Seit dem kann es natürlich sein, dass nicht jede Funktion ist wie vorher.
Euern Wunsch kann ich verstehen,und werde es überarbeiten. Dazu muss aber einiges nochmals verändert werden.
Meines Erachtens kannst du dir helfen indem du explicit bei Eintritt der Abwesenheit per notify das Attribut disable setzt. Dann werden die Zeiten neu berechnet und der RT neu gestartet. Probier es mal aus und wenn es nicht Funzt, dann veröffentliche hier deine Definitionen.
Zitat von: oelidoc am 19 Dezember 2014, 19:48:05
ich habe hier mehrere RTs, die ich mittels eines DOIF auf disabled 0 oder 1 setze. Das funktioniert auch prima. Nur leider schalten die Lampen sich nicht an, wenn ich den RT innerhalb der START- STOPTIME auf disabled 0 stelle. Die RTs zeigen zwar STATE on und active 1 an - die Lampen bleiben aber aus :-\
stell doch mal den vollständigen Code ein, ich hatte damit auch experimentiert und habe es nicht hinbekommen den RT zu starten
Hallo,
Zitat von: moonsorrox am 20 Dezember 2014, 13:58:34
stell doch mal den vollständigen Code ein, ich hatte damit auch experimentiert und habe es nicht hinbekommen den RT zu starten
mach ich gerne, wenn ich wieder zuhause bin.
Gruß
oelidoc
So, ich habe jetzt eine Version von RT erstellt, die so hoffe ich genau euren Wünschen entspricht.
Bei ihr ist es möglich während des aktiven Zeitraums des RT beliebig zu enablen/disablen.
Wenn der Disablestatus aufgehoben wird, startet der Timer wieder - vollautomatisch. Dabei werden auch Ereignisse von Presence oder so berücksichtigt.
Ich werde die Änderung noch ein wenig testen und dann einchecken.
Hallo Dietmar,
sehe ich das richtig, dass damit auch die explizite Verwendung von RandomTimer_Wakeup() überflüssig geworden ist?
Gruß Benni.
Hallo,
hier wie gewünscht meine Schnipsel:
ich habe einen Dummy "Anwesenheit", der über lan-ping per Presence Modul auf die Anwesenheit zweier Smartphones prüft.
Dann folgendes DOIF:
define licht_abwesenheit DOIF ([Anwesenheit] eq "Anwesend") (attr zufall_.* disable 1) DOELSEIF ([Anwesenheit] eq "Abwesend" and !$we) (attr zufall_.* disable 0) DOELSEIF ([Anwesenheit] eq "Abwesend") (attr zufall_.*_abends disable 0)
attr licht_abwesenheit disable 0
Und hier ein RT als Beispiel:
define zufall_wohnzimmer_abends RandomTimer *{sunset_abs(-1400)} Dimmer_Wohnzimmer *{sunset_abs(+3720,"21:32","23:32")} 700
attr zufall_wohnzimmer_abends disable 0
attr zufall_wohnzimmer_abends onCmd set Dimmer_Wohnzimmer pct 60
attr zufall_wohnzimmer_abends room Wohnzimmer
attr zufall_wohnzimmer_abends switchmode 900/100
Der RT sollte halt beim Verlassen der Wohnung innerhalb der start-stoptime die Lampen bis 2Minuten nach Runterfahren der Jalousien an (und aus) schalten, um Anwesenheit zu simulieren.
Gruß
oelidoc
Zitat von: Benni am 21 Dezember 2014, 17:39:29
Hallo Dietmar,
sehe ich das richtig, dass damit auch die explizite Verwendung von RandomTimer_Wakeup() überflüssig geworden ist?
Gruß Benni.
Ja, so sieht es aus!
Zitat von: Dietmar63 am 21 Dezember 2014, 16:37:33
So, ich habe jetzt eine Version von RT erstellt, die so hoffe ich genau euren Wünschen entspricht.
bevor ich update..!
ich habe in meinem DOIF den RT immer enabled/disabled mit diesem Code, kann das alles so bleiben..?
Das funktionierte sehr gut..
DOELSEIF([Zeitsteuerung] ~= "Dämmerung|Aus")(attr ZufallsTimerAussenlicht disable 1)
DOELSEIF([Zeitsteuerung] eq "Zufall")(attr ZufallsTimerAussenlicht disable 0)
Ja, das kannst du so lassen.
Ich teste für mich noch mindestens bis Sonntag. Vorher ist nicht mit dem Einchecken zu rechnen.
Ich habe damit 3 RTs am laufen :D
super Danke... ich habe keine Eile, teste in Ruhe is bald Weihnachten... ;)
ich wollte mich jetzt mal wieder melden da ich entweder etwas falsch mache oder etwas stimmt nicht mit meinem RT.
Ich hatte die Tage ein RT auf Zufall laufen welches hervorragend funktioniert hat...
Nun da ich wieder zuhause bin, springt jetzt den 3. Tag der RT an obwohl ich ihn auf "disabled" gesetzt habe mit folgenden Code in einem DOI/Dummy der Code sieht so aus
( [TestSteuerung] eq "Aus" and ([{sunset("CIVIL",6000,"22:15","22:30")}|01234] or [{sunset("CIVIL",6000,"22:15","22:50")}|56]))
(set Uhrzeit on)
DOELSEIF ([TestSteuerung] eq "Aus" and ([{sunrise("CIVIL",9000,"07:00","09:20")}|0123456]))
(set Uhrzeit off)
DOELSEIF([TestSteuerung] eq "Aus")(attr ZufallsTimerLichtOG disable 1)
DOELSEIF([TestSteuerung] eq "Zufall")(attr ZufallsTimerLichtOG disable 0)
Frage:
sollte der RT wenn er aus "disabled" eigentlich auch immer aus sein..?
sobald also das Dummy auf "Aus" gesetzt wird, sollte das DOIF den RT auf "disabled 1" setzen und ausschalten, aber der RT springt immer wieder an..!
(siehe Screenshot) kann hier grad keine Screenshots ran hängen, weil er mir sagt das Uploudverzeichnis ist voll
wo ist mein Fehler, oder denke ich falsch..?
EDIT:// noch ein Hinweis von mir dazu, heute steht dieser Timer der Probleme macht wieder auf "off" das heißt zu der Zeit wo er beginnen soll wird er auch starten..!
Ich habe noch solch einen RT am laufen und der steht heute immer noch auf "disabled" der wird nicht starten.
Ich habe schon alles verglichen die beiden DOIF die den Timer auschalten, aber alles ist gleich.
Wenn ich das Dummy wieder umschalte steht er auch wieder auf "disabled"
Warum ist das so..?
eingecheckt:
98_RandomTimer: it is now possible to change the attributes disable or disableCond during runtime or even any state computed in disableCond. If the RT ist enabled it starts now at once.
probiert es bitte aus.
Hallo Dietmar,
ich möchte mich zunächst recht herzlich für dein tolles Modul bedanken.
Ich habe leider ein Problem. Ich habe einen RT eingerichtet, der zwischen 16:00 Uhr und 22:00 Uhr schalten soll. Am ersten Tag hat er das auch gemacht. Am Tag danach kamen leider keine Schaltungen mehr zustande. Mein System ist auf dem aktuellen Stand. Die DEF sieht so aus:
16:00:00 Mess_03_Sw 22:00:00 100
Was mich wundert: In der STARTTIME und ENDTIME steht auch das Datum, von dem Tag, als ich den RT angelegt habe.
Frank
ich bin zwar nicht Dietmar ;), aber ich habe mich ausgiebig mit meinen RTs beschäftigt und evtl. kann ich dir weiter helfen
Es steht eigentlich immer bei beiden Zeiten der nächste Termin drin, ob der nun aktiv ist oder "disabled" so bei mir
ZitatSTARTTIME 07.01.2015 17:05:10
STOPTIME 08.01.2015 02:05:10
wie sieht dein Status aus..? bei mir so..!
STATE disabledbedeutet der RT ist nicht aktiv, sondern richtig "AUS" das heißt er zeigt zwar die aktuellen Events an aber führt sie nicht aus.
steht dort
ZitatSTATE on
ist er aktiv und arbeitet
steht dort
ZitatSTATE off
ist der er grad nicht aktiv
wie sehen diese Internals aus..?
ZitatSIGMAOFF 800
SIGMAON 200
SWITCHMODE 800/200
TIMESPEC_START *{sunset_abs("CIVIL",0,"16:45","22:20")}
TIMESPEC_STOP *{sunset_abs(9*3600)}
zeig mal etwas von deinen Internals, mach mal ein list Mess_03_Sw
Setze mal einen Stern davor und setze verbose 5
16:00:00 Mess_03_Sw 22:00:00 100
*16:00:00 Mess_03_Sw 22:00:00 100
Hallo ihr Zwei ;),
erstmal vielen Dank für Euren Support. Ich habe gestern "leider" ein update gemacht und fhem neu gestartet. Anschließend funktioniert der RT wieder. Ich warte mal heute ab, wie es dann gelaufen ist und werde berichten.
Frank
Ich habe den RT zu Testzwecken heute (um 13:19) auf 13:20h - 13h40 mit * gesetzt. Nach Abschluss des RT bleibt STARTTIME und STOPTIME auf dem heutigen Datum. Das nächste Zeitfenster wurde nicht gesetzt. Ich vermute daher, dass der RT morgen nicht laufen wird. STATE steht nach Ablauf des heuten RT dann auf OFF.
Das Log zeigt folgendes:
removing Timer: Mess_03_RT_SetTimer
2015.01.08 13:19:18 5: [Mess_03_RT] setting Timer: Mess_03_RT_SetTimer 08.01.2015 13:19:19
2015.01.08 13:19:19 4: [Mess_03_RT] timings RandomTimer on Mess_03_Sw: 13:20:00(08) - 13:40:00(08)
2015.01.08 13:19:19 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:19:19 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:20:00
2015.01.08 13:19:19 5: [Mess_03_RT] removing Timer: Mess_03_RT_SetTimer
2015.01.08 13:19:19 5: [Mess_03_RT] setting Timer: Mess_03_RT_SetTimer 09.01.2015 00:01:55
2015.01.08 13:20:00 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:20:00 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:21:35
2015.01.08 13:21:35 4: [Mess_03_RT] Zustand:off sigma:500 random:372->1
2015.01.08 13:21:35 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:21:35 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:21:35 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:21:35 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:23:13
2015.01.08 13:23:13 4: [Mess_03_RT] Zustand:on sigma:500 random:964->
2015.01.08 13:23:13 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:23:13 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:24:52
2015.01.08 13:24:52 4: [Mess_03_RT] Zustand:on sigma:500 random:267->1
2015.01.08 13:24:52 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:24:52 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:24:52 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:24:52 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:26:33
2015.01.08 13:26:33 4: [Mess_03_RT] Zustand:off sigma:500 random:874->
2015.01.08 13:26:33 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:26:33 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:28:11
2015.01.08 13:28:11 4: [Mess_03_RT] Zustand:off sigma:500 random:959->
2015.01.08 13:28:11 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:28:11 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:29:49
2015.01.08 13:29:49 4: [Mess_03_RT] Zustand:off sigma:500 random:216->1
2015.01.08 13:29:49 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:29:49 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:29:49 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:29:49 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:31:25
2015.01.08 13:31:25 4: [Mess_03_RT] Zustand:on sigma:500 random:261->1
2015.01.08 13:31:25 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:31:25 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:31:25 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:31:25 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:33:00
2015.01.08 13:33:00 4: [Mess_03_RT] Zustand:off sigma:500 random:209->1
2015.01.08 13:33:00 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:33:00 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:33:00 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:33:00 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:34:43
2015.01.08 13:34:43 4: [Mess_03_RT] Zustand:on sigma:500 random:335->1
2015.01.08 13:34:43 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:34:43 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:34:43 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:34:43 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:36:25
2015.01.08 13:36:25 4: [Mess_03_RT] Zustand:off sigma:500 random:945->
2015.01.08 13:36:25 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:36:25 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:38:05
2015.01.08 13:38:05 4: [Mess_03_RT] Zustand:off sigma:500 random:187->1
2015.01.08 13:38:05 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:38:05 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:38:05 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:38:05 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:39:46
2015.01.08 13:39:46 4: [Mess_03_RT] Zustand:on sigma:500 random:72->1
2015.01.08 13:39:46 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:39:46 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:39:46 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:39:46 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:41:22
2015.01.08 13:41:22 3: [Mess_03_RT] ending RandomTimer on Mess_03_Sw: 13:20:00(08) - 13:40:00(08)
2015.01.08 13:41:22 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:41:22 3: CUL_HM set Mess_03_Sw off
also meiner steht trotz das er disabled ist auf dem aktuellen Datum. Hier mal mein Auszug, kannst mal vergleichen
Internals:
CFGFN ./FHEM/automation.cfg
COMMAND off
DEF *{sunset_abs("CIVIL",0,"16:45","22:20")} WegLampe_Sw_02 *{sunset_abs(9*3600)} 720
DEVICE WegLampe_Sw_02
NAME ZufallsTimerAussenlicht
NR 2088
REL
REP *
SIGMAOFF 800
SIGMAON 200
STARTTIME 08.01.2015 17:06:24
STATE disabled
STOPTIME 09.01.2015 02:06:24
SWITCHMODE 800/200
S_REL
S_REP *
TIMESPEC_START *{sunset_abs("CIVIL",0,"16:45","22:20")}
TIMESPEC_STOP *{sunset_abs(9*3600)}
TIMETOSWITCH 720
TYPE RandomTimer
active 0
startTime 1420733184
stopTime 1420765584
Timer:
Zufallstimeraussenlicht_exec:
HASH ZufallsTimerAussenlicht
MODIFIER Exec
NAME ZufallsTimerAussenlicht_Exec
Zufallstimeraussenlicht_settimer:
HASH ZufallsTimerAussenlicht
MODIFIER SetTimer
NAME ZufallsTimerAussenlicht_SetTimer
Attributes:
alias Zufall Timer - Wegbeleuchtung
devStateIcon on:general_an_fuer_zeit@crimson off:general_aus@lightgreen disabled:general_aus@lightgreen
disable 1
group Aussen Beleuchtung
room Automation
Zitat von: Bastel-Frank am 08 Januar 2015, 14:49:38
Ich habe den RT zu Testzwecken heute (um 13:19) auf 13:20h - 13h40 mit * gesetzt. Nach Abschluss des RT bleibt STARTTIME und STOPTIME auf dem heutigen Datum. Das nächste Zeitfenster wurde nicht gesetzt. Ich vermute daher, dass der RT morgen nicht laufen wird. STATE steht nach Ablauf des heuten RT dann auf OFF.
Das Log zeigt folgendes:
removing Timer: Mess_03_RT_SetTimer
2015.01.08 13:19:18 5: [Mess_03_RT] setting Timer: Mess_03_RT_SetTimer 08.01.2015 13:19:19
2015.01.08 13:19:19 4: [Mess_03_RT] timings RandomTimer on Mess_03_Sw: 13:20:00(08) - 13:40:00(08)
2015.01.08 13:19:19 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:19:19 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:20:00
2015.01.08 13:19:19 5: [Mess_03_RT] removing Timer: Mess_03_RT_SetTimer
2015.01.08 13:19:19 5: [Mess_03_RT] setting Timer: Mess_03_RT_SetTimer 09.01.2015 00:01:55
2015.01.08 13:20:00 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:20:00 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:21:35
2015.01.08 13:21:35 4: [Mess_03_RT] Zustand:off sigma:500 random:372->1
2015.01.08 13:21:35 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:21:35 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:21:35 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:21:35 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:23:13
2015.01.08 13:23:13 4: [Mess_03_RT] Zustand:on sigma:500 random:964->
2015.01.08 13:23:13 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:23:13 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:24:52
2015.01.08 13:24:52 4: [Mess_03_RT] Zustand:on sigma:500 random:267->1
2015.01.08 13:24:52 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:24:52 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:24:52 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:24:52 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:26:33
2015.01.08 13:26:33 4: [Mess_03_RT] Zustand:off sigma:500 random:874->
2015.01.08 13:26:33 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:26:33 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:28:11
2015.01.08 13:28:11 4: [Mess_03_RT] Zustand:off sigma:500 random:959->
2015.01.08 13:28:11 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:28:11 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:29:49
2015.01.08 13:29:49 4: [Mess_03_RT] Zustand:off sigma:500 random:216->1
2015.01.08 13:29:49 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:29:49 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:29:49 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:29:49 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:31:25
2015.01.08 13:31:25 4: [Mess_03_RT] Zustand:on sigma:500 random:261->1
2015.01.08 13:31:25 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:31:25 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:31:25 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:31:25 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:33:00
2015.01.08 13:33:00 4: [Mess_03_RT] Zustand:off sigma:500 random:209->1
2015.01.08 13:33:00 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:33:00 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:33:00 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:33:00 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:34:43
2015.01.08 13:34:43 4: [Mess_03_RT] Zustand:on sigma:500 random:335->1
2015.01.08 13:34:43 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:34:43 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:34:43 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:34:43 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:36:25
2015.01.08 13:36:25 4: [Mess_03_RT] Zustand:off sigma:500 random:945->
2015.01.08 13:36:25 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:36:25 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:38:05
2015.01.08 13:38:05 4: [Mess_03_RT] Zustand:off sigma:500 random:187->1
2015.01.08 13:38:05 4: [Mess_03_RT] command: set Mess_03_Sw on
2015.01.08 13:38:05 3: CUL_HM set Mess_03_Sw on
2015.01.08 13:38:05 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:38:05 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:39:46
2015.01.08 13:39:46 4: [Mess_03_RT] Zustand:on sigma:500 random:72->1
2015.01.08 13:39:46 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:39:46 3: CUL_HM set Mess_03_Sw off
2015.01.08 13:39:46 5: [Mess_03_RT] removing Timer: Mess_03_RT_Exec
2015.01.08 13:39:46 5: [Mess_03_RT] setting Timer: Mess_03_RT_Exec 08.01.2015 13:41:22
2015.01.08 13:41:22 3: [Mess_03_RT] ending RandomTimer on Mess_03_Sw: 13:20:00(08) - 13:40:00(08)
2015.01.08 13:41:22 4: [Mess_03_RT] command: set Mess_03_Sw off
2015.01.08 13:41:22 3: CUL_HM set Mess_03_Sw off
Geh davon aus, dass er morgen starten wird. Die Zeiten werden kurz nach Mitternacht für den aktuellen Tag aktualisiert.
Die sunset-Module liefern leider die Zeiten immer für den aktuellen Tag, deshalb ist das so gebaut worden.
Heute ist der RT gelaufen. Ob dies mit dem "*" vor dem Startzeitpunkt zusammenhängt?
ja
Welche Funktion hat der "*"?
Wie im at
Sorry, no German (feel free to reply in German if you prefer, I'll try and make some sense of google translate)
I have been using this module for a few months, very useful and much better than my previous switched at commands.
I am getting odd messages in the logs. I have tried various modifications to the defines but cannot see why they are happening.
These are a few from January. I cannot find any similar reports from searches.
2015.01.10 08:18:25 1: PERL WARNING: Use of uninitialized value $@ in substitution (s///) at ./FHEM/98_RandomTimer.pm line 412.
2015.01.08 05:53:27 1: PERL WARNING: Use of uninitialized value $@ in substitution (s///) at ./FHEM/98_RandomTimer.pm line 412.
2015.01.07 17:05:31 1: PERL WARNING: Use of uninitialized value $@ in substitution (s///) at ./FHEM/98_RandomTimer.pm line 412.
2015.01.07 07:05:59 1: PERL WARNING: Use of uninitialized value $@ in substitution (s///) at ./FHEM/98_RandomTimer.pm line 412.
2015.01.06 08:09:51 1: PERL WARNING: Use of uninitialized value $@ in substitution (s///) at ./FHEM/98_RandomTimer.pm line 412.
I am puzzled as they don't appear at exactly the same time every day, but that could be 'sunset' related
I have
define RT_Socket_23_1 RandomTimer *{sunset_abs()} 0056ccfe03 00:30:00 480
attr RT_Socket_23_1 disable 1
attr RT_Socket_23_1 room TRX_LIGHT
attr RT_Socket_23_1 switchmode 800/200
define RT_Socket_23_2 RandomTimer *05:30:00 0056ccfe03 08:30:00 480
attr RT_Socket_23_2 disable 1
attr RT_Socket_23_2 room TRX_LIGHT
attr RT_Socket_23_2 switchmode 800/200
I have checked in a new version of RT.
Try with that version an let me know, if it works better.
sunset() ist not the problem.
Thanks, I'll update in the morning and see how it goes.
Sorry for the delay, I have been away both days since updating.
All is good, RandomTimer is working as expected with no more warnings in the logs.
Many thanks, and for this useful module.
May I suggest a few minor corrections to the commandref documentation for your next commit, I hope this is a suitable format..
/i'm able to switch/I'm able to switch/
/over the word./over the world./
/<h3>Deskrition/<h3>Description/
/trys/tries/
the timespec <a href="#at">at</a> .
would read better as
the <a href="#at">at</a> timespec .
@ Dietmar63
Der Parameter "switchmode" ist anscheinend fix auf 800/200 eingestellt, da andere Werte meiner Meinung nach keinen Einfluß auf das Schaltverhalten haben.
Ich wollte mein ToilettenLicht schalten -> ca. 30sec. ein und ca.1h aus. Ich wollte mich dabei dem Parameter switchmode 10/800 bedienen, aber leider ist das Verhalten eher 800/200.
Ist dieser Parameter für meinen Anwendungsfall überhaupt die richtige ?
LG
Yellow Pinky
Da hast du etwas falsch verstanden. Es wird bei 200/800 mit 20% Wahrscheinlichkeit eingeschaltet und mit 80% Wahrscheinlichkeit ausgeschaltet. Es hat nichts mit der Dauer zu tun.
Danke für die schnelle Antwort,
...aber ist es nicht so, dass wenn die Wahrscheinlichkeit sehr klein ist das ein Ein Befehl "durch geht", dann die Zeit wo die Lampe ausgeschaltet bleibt sich verlängert.
Anbei noch ein Screenshot wo der switchmode auf 800/200 ist obwohl auf 10/800 konfiguriert..
LG
@yellowpinky
schalte mal verbose 5 ein, dann kannst du sehen wann RT zu schalten versucht, und wie die Zufallsfunktion genutzt wird.
RT soll eher wie eine Zufallsfunktion einer Zeitschaltuhr ein Gerät schalten und eine Anwesenheit vortäuschen - hoffentlich.
ToilettenLicht schalten -> ca. 30sec. ein und ca.1h aus kann man eher nicht machen.
zu 10/800:
du musst ein wenig warten - dann schaltet RT um.
Hallo,
das mit dem 30 Sekunden AN habe ich ich bei mir über das Attribut onCmd des RandomTimer mit Schaltbefehl on-for-timer gelöst, nur dass es bei mir nicht nur einfach 30 Sekunden sind, sondern eine zufällige Zeit zwischen 30 und 120 Sekunden:
attr EG.TL.RT.Toilettenlicht onCmd {fhem("set @ on-for-timer ".int(rand(90)+30))}
Das zu schaltende device muss on-for-timer dazu natürlich unterstützen.
Gruß Benni.
Das geht, aber das hast du das Modul anders genutzt, als es gedacht war.
Hi;
Danke für die schnellen Antworten.
Der Parameter switchmode funktioniert anscheinend nur wenn er 3stellig eingegeben wird -> also 010/800 anstatt 10/800.
Diesen Zugang für das Lösunsproblem Toilette- oder auch Flurlicht finde ich nicht so schlecht, da die Auszeiten bei timetoswitch 60 bei mir zwischen 10min und 2Std. geschwankt haben.
Wirkt frinde ich sehr realistisch.
onCmd benötige ich leider für den dimm Befehle, also fällt das on-for-timer leider aus.
Hilfe - F1 - Hilfe - fhem hängt nach letztem Update
Seit dem Update vom 19.01.2015 hängt fhem bei mir, wenn RandomTimer den Schaltvorgang ausführt; die Definition funktioniert noch fehlerfrei ohne Meldung.
Auch mit verbose 5 habe ich Log keine Einträge, aber putty zeigt mir vom Raspberry folgende Meldung:
Undefined subroutine &main::get_switchmode called at ./FHEM/98_RandomTimer.pm line 373.
Bin für schnelle Hilfe dankbar,
mfG Achim
ich sehe heute Abend nach!
Hallo,
so ein Erlebnis hatte ich eben auch :o
Habe vorhin das Haus verlassen, was das Zeichen für den RT ist, aktiv zu werden. Kurze Zeit später erhalte ich die Meldung auf's Handy, dass FHEM neu gestartet wurde.
Ein kurzer Blick ins Log vom Watchdog sagt mir FHEM war abgeschmiert und musste neu gestartet werden.
2015-01-20_16:25:54 fhem_server V: 54 S: alive MSG: FHEM Server alive
2015-01-20_16:26:54 fhem_server MSG: no FHEM Server process found
2015-01-20_16:29:54 fhem_server V: 54 S: alive MSG: FHEM Server alive
Blick ins FHEM-Log sagt, letzte Aktion vor dem Reboot war die eines RT nach Aktivierung.
...
2015.01.20 16:26:17 3: [EG.FL.RT.Flurlicht] starting RandomTimer on EG.FL.SW.Flurlicht: 16:26:17(20) - 23:00:00(20)
2015.01.20 16:26:57 3: telnetPort: port 7072 opened
2015.01.20 16:26:57 3: WEB: port 8083 opened
2015.01.20 16:26:57 3: WEBphone: port 8084 opened
...
Nehme an, das ist das selbe Problem.
Gruß Benni.
Ich habe seit ein paar tagen auch das problem:
2015.01.21 16:58:00 3: [ZufallsTimerKueche] starting RandomTimer on Licht_Kueche: 16:58:00(21) - 22:11:00(21)
Gestern hat es leider nicht mehr geklappt - gleich kümmere ich mich darum.
eingecheckt:
http://forum.fhem.de/index.php/topic,32560.0/topicseen.html (http://forum.fhem.de/index.php/topic,32560.0/topicseen.html)
Hallo Zusammen,
ich versuche gerade bei meinen Randomtimer die DisableCond mit einem Dummy Attribut zu füllen. Wobei ich aber kläglich scheitere.
dummy:
Internals:
NAME AnwesenheitsSimulation
NR 181
STATE 0
TYPE dummy
Readings:
2015-02-02 21:29:08 state 0
Attributes:
comment 1 = ja und alles andere = nein.
room System
setList 1 0
webCmd 1:0
Internals:
DEF *{sunset()} OGGaestezimmerLicht_Sw +02:30:00 480
...
TYPE RandomTimer
...
Attributes:
disableCond !AnwesenheitsSimulation
...
Ist es nicht möglich, die disableCond mit einem not(Dummy-Wert) zu füllen?
Danke euch und liebe Grüsse
Jürgen
Ich teste gerade auch erstmals das Modul und habe auch Probleme mit den "disablecond". Ich arbeite an einer ähnlichen Idee, wie der User "moonsorrox" und will mit einem Dummy-Wert das Modul deaktivieren.
(Value("Zeitsteuerung" ne "Zufall"))
Leider ohne Erfolg.
FHEM ist up-to-date.
Zitat von: Funk.Odyssey am 02 Februar 2015, 22:52:22
will mit einem Dummy-Wert das Modul deaktivieren.
dann mach das doch mit disable 1 und disable 0 und setze das Attribut, das funktioniert bei mir jetzt schon eine ganze Weile. Siehe Post #181
Dieses hier "disablecond" funktionierte bei mir nicht, der RTimer startete jeden Tag aufs neue
Quatsch (entschuldigt bitte dieses harte Wort)
auch disableCond funktioniert!!! Ich melde mich heute Abend dazu. - bin noch unterwegs
Der Perl-Code ist nicht korrekt.
Schaltet bitte mal verbose auf 5-vielleicht hilft das schon weiter.
Hatte gestern leider keine Zeit und komme auch heute nicht mehr dazu - vielleicht morgen.
Ein verbose 5 bringt folgende Meldung:
2015.02.04 21:22:42 3: [TestRandom] Bareword "AnwesenheitsSimulation" not allowed while "strict subs" in use at (eval 94) line 1.
2015.02.04 21:22:42 4: [TestRandom] timings RandomTimer on OGGaestezimmerLicht_Sw: 21:22:50(04) - 23:52:50(04)
2015.02.04 21:22:42 5: [TestRandom] removing Timer: TestRandom_Exec
2015.02.04 21:22:42 5: [TestRandom] setting Timer: TestRandom_Exec 04.02.2015 21:22:50
2015.02.04 21:22:42 5: [TestRandom] removing Timer: TestRandom_SetTimer
2015.02.04 21:22:42 5: [TestRandom] setting Timer: TestRandom_SetTimer 05.02.2015 00:08:15
2015.02.04 21:22:50 3: [TestRandom] Bareword "AnwesenheitsSimulation" not allowed while "strict subs" in use at (eval 95) line 1.
2015.02.04 21:22:50 3: [TestRandom] starting RandomTimer on OGGaestezimmerLicht_Sw: 21:22:50(04) - 23:52:50(04)
2015.02.04 21:22:50 3: [TestRandom] Bareword "AnwesenheitsSimulation" not allowed while "strict subs" in use at (eval 96) line 1.
2015.02.04 21:22:50 4: [TestRandom] Zustand:off sigma:800 random:353->1
2015.02.04 21:22:50 4: [TestRandom] command: set OGGaestezimmerLicht_Sw on
im Log steht warum es nicht geht:
Bareword "AnwesenheitsSimulation" not allowed while "strict subs" in use at (eval 94) line 1.
ist eine Perl Fehlermeldung, die besagt, dass AnwesenheitsSimulation so nicht erlaubt ist. AnwesenheitsSimulation wird so wie du es genutzt hast als Variabel angesehen und Variablen müssen mit ein $ beginnen.
falsch:
disableCond !AnwesenheitsSimulation
richtig:
disableCond (conditionCode)
...
disableCond (Value("AnwesenheitsSimulation") ne "on")
oder
(Value("Zeitsteuerung" ne "Zufall")) # hier ist die Klammer falsch gesetzt.
(Value("Zeitsteuerung") ne "Zufall") # so ist es richtig
oder wie in der Referenz:
attr ZufallsTimerZ disableCond (Value("presenceDummy") ne "present"))
Hi Dietmar,
danke für die schnelle und gute Antwort.
Kriege es aber nicht hin.
mit
disableCond: (Value("AnwesenheitsSimulation") eq "")Zitathatte mich hier vertippt, sollte selbstverständlich
disableCond: (Value("AnwesenheitsSimulation") eq "1")
heissen * nachträglich geändert jude
da mein STATE des dummys 1 oder 0 ist.
Aber auf der Übersicht wird immer angezeigt, dass der randomtimer disabled ist.
Muss das morgen in Ruhe noch einmal anschauen.
Danke dir und liebe Grüsse
Jürgen
dann musst du korrekterweise auch
attr ZufallsTimerZ (Value("AnwesenheitsSimulation") eq "1")
oder
attr ZufallsTimerZ (Value("AnwesenheitsSimulation") eq "0")
schreiben.
Ausnahmsweise würde in diesem Fall auch eins von
attr ZufallsTimerZ (Value("AnwesenheitsSimulation"))
attr ZufallsTimerZ (!Value("AnwesenheitsSimulation"))
Value("AnwesenheitsSimulation") evaluiert zu 1 oder 0 also true oder false und das reicht dann schon.
hasst du AnwesenheitsSimulation richtig geschrieben?
Du kannst mit {Value("AnwesenheitsSimulation")} in der Oberfläche von fhem prüfen zu welchem Wert dieser Ausdruck evaluiert - muss 0 oder 1 sein.
verbose 5 nicht vergessen.
Hallo Dietmar,
habe gerade noch einmal ein update gemacht, dann ein TestRandomTimer erstellt und wie du es beschrieben hast den
attr ZufallsTimerZ (!Value("AnwesenheitsSimulation"))
verwendet. Und schwups hat es funktioniert.
D A N K E dir und liebe Grüsse
Jürgen
Hallo,
ich habe ein ähnliches Problem mit der disableCond.
fehlt da bei euch nicht noch was? - muss das nicht
attr ZufallsTimerZ disableCond (!Value("AnwesenheitsSimulation")) heisen?
anbei mein Testcode, bei dem ich über das Dummy den RT nicht disablen/enablen kann.
#******* Define Test_Verreist
define Test_Verreist dummy
attr Test_Verreist devStateIcon ja:home_gruen nein:home-red
attr Test_Verreist group Commands
attr Test_Verreist room 00-Abwesenheit
attr Test_Verreist webCmd ja:nein
##########################################################################
#****** Random Timer_Licht Galerie (Test_Verreist)
define ZufallsTimerGalerie_test RandomTimer *{sunset_abs(300)} FHEM_Licht_Galerie 23:59:00 60
attr ZufallsTimerGalerie_test disableCond (("Test_Verreist") ne "nein")
attr ZufallsTimerGalerie_test room 00-Abwesenheit
Irgendwie stehe ich da auf dem Schlauch.
ich mache das in meinen DOIFs mit dem Attribut... das funktioniert seit längere Zeit wunderbar
DOELSEIF([ZeitsteuerungWeg] =~ "Aus|Dämmerung")(attr ZufallsTimerWeglicht disable 1)
DOELSEIF([ZeitsteuerungWeg] eq "Zufall")(attr ZufallsTimerWeglicht disable 0)
attr ZufallsTimerGalerie_test disableCond (Value("Test_Verreist") ne "nein")
Hallo zusammen
Ich bin erst seit ein paar wenigen Tagen ein Jünger des FHEM Ordens :)
Es ist mir aber immerhin schon gelinge, diverse Module (Wetter, Sonos) einzubinden... Alles Dank diesem Forum ;D
Nun meine Frage zu diesem Timer. Ich habe den RandomTimer für meine Anwesenheitssimulation benutzt. Läuft wunderbar. Allerdings würde ich es noch hilfreich finden, wenn die Simulation gestoppt werden würde, sobald man Manuell auf eine der Vorhandenen Taster (Lichtschalter im Haus)drücken würde. Ich müsste dann nicht jedesmal bei meiner Rückkehr ins Haus mein IPad zur Hand nehmen und die Simulation stoppen. Kann das irgendwie realisiert werden?
Ich weiß, wahrscheinlich würde ich die Antwort hier im Forum finden. Mein Problem ist aber, dass ich nicht weiß wie die Funktion heißt und ich daher nicht danach suchen kann
Wenn du das Schalten der Lichtschalter per fhem mitbekommt, kannst du das Signal per notify nutzen um im RT das Attribut disable zu setzen.
Ok, und wie müsste das in etwa aussehen damit dieses nur passiert wenn die anwesenheitssimulation angeschaltet ist?
Zitatdamit dieses nur passiert wenn die anwesenheitssimulation angeschaltet ist
Du könntest vorher das disable Attibut auswerten.
Du müßtest alle Ereignisse, die die anwesenheitssimulation ein/aus schalten sollen auf eine Funktion in die 99_myUtils umlenken.
Diese Funktion muss dann entscheiden, ob etwas mit der Simulation gemacht werden soll. Dazu kann sie alle Attribute und Readings aus FHEM nutzen.
Im Grunde willst du deine Anwesenheit berücksichtigen. Dafür gibt es zum Beispiel das Presence Modul(was nur bedingt fehlerfrei funtikoniert), oder eben deine Schalter.
Irgendwie spuckt mein RandomTimer im Log sporadisch folgenden Fehler aus:
[rand_tischlampen] IO::Socket::INET: connect: No route to host
Das stört mich nicht, aber irgendwie sehe ich keinen Zusammenhang zwischen RandomTimer und der Fehlermeldung. Hat jemand ne Idee?
Netzwerk Problem
Aber was hat dein Modul damit zu tun?
Ich habe keine Ahnung.
SSuch mal das Forum hier ab. Die FM kommt mir bekannt vor.
Vielleicht hat jemand eine Lösung gefunden
Moin,
ich habe einen RandomTimer testweise eingerichtet. Funktioniert soweit ganz gut, jedoch wenn ich den Timer per "attr disable 1" deaktivieren will, läuft er dennoch munter weiter. Zu sehen im Logfile wo er nachts versucht meine Lampe zu schalten.
2015.06.23 00:15:40 3: [ZufallsTimerStehlampe] IO::Socket::INET: connect: No route to host
How come ?
IO::Socket::INET: connect: No route to host
Der RT läuft "rund um die Uhr" schaltet nur nicht, damit beim RT das disable herausgenommen werden kann und er sofort wieder aktiv ist.
Wie diese FM zustande kommt, ist zur Zeit ziemlich unklar:
Bei IO::Socket::INET: connect: No route to host handelt es sich um Netzwerkzugriffe, die aber RT selbst nicht durchführt.
Ich werde mal eine Version ausliefern, die die FMs des Moduls so markiert, dass man sehen kann an welcher Stelle die FM ausgegeben wird.
Danke für die Info. Warte ich mal auf die neue Version.
was für ein Gerät ist das? Wie ist es definiert?
ZufallsTimerStehlampe
Wie ist das zu schaltende Gerät definiert?
Ist eine IT-Steckdose.
DEF
0000FFF00F FF F0
Funktioniert sonst tadellos (At, DOIF ETC)
Homematic FS20???
Irgendwie über LAN angeschlossen?
Bitte die Definition angeben
Intertechno.
Gesendet wird via CUL868 /CUL_RFR.
Definition habe ich doch angegeben, oder war ich nicht gemeint ??
ehrlich gesagt bin ich ratlos!
Heute Nacht lief es tadellos. (attr disable = 0)
Ich habe mein RT-Device übrigens auch "disabled".
Ich habe verbose mal auf 5 gesetzt. Anbei das Log. Vielleicht hilft es ja.
2015.07.04 10:46:59 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 10:46:59 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 10:46:59 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 10:46:59 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 10:46:59 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 10:46:59 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 11:03:19
2015.07.04 11:03:19 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 11:03:19 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 11:03:19 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 11:03:19 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 11:03:19 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 11:03:19 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 11:19:56
2015.07.04 11:19:56 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 11:19:56 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 11:19:56 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 11:36:05
2015.07.04 11:21:17 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 11:36:05 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 11:36:05 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 11:36:05 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 11:52:05
2015.07.04 11:52:05 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 11:52:05 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 11:52:05 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 12:07:57
2015.07.04 12:07:57 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:07:57 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 12:07:57 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:07:57 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:07:57 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 12:07:57 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 12:25:26
2015.07.04 12:25:30 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:25:30 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 12:25:30 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:25:30 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:25:30 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 12:25:30 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 12:42:45
2015.07.04 12:42:51 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:42:51 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.04 12:42:51 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:42:51 3: [rand_tischlampen] IO::Socket::INET: connect: No route to host
2015.07.04 12:42:51 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.04 12:42:51 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-04 13:00:04
Ich behaupte weiterhin dass es mit dem zu schaltenden Gerät zu tun haben muss. Tausche das Gerät mal durch ein dummy aus,und protokolliere das Ergebnis.
Das sind Pilight-Switche, die ein Pilight_Ctrl-Device benötigen, welches über den Port 5000 mit dem Daemon lauscht.
Stimmt. Dann passt die Erklärung (habe ich wohl vorher überlesen). Nur hilft mir das nun leider nicht. Denn ich kann daran nichts ändern. Hmm, schade. Mal schauen, ob der Modulentwickler helfen kann.
Die Probleme sollten auch beim normalem Schalten über fhem auftreten.
Eventuell kann man den timeout verändern.
ich habe ein neu Version eingecheckt, die eine bessere Fehlermeldung bereitstellen sollte
Bei mir sieht es mit der neuen Version folgendermaßen aus:
2015.07.08 16:20:20 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING
2015.07.08 16:20:20 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING
2015.07.08 16:20:20 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING
Damit ist klar, dass es an disableCond liegt. Wenn Sie ausgeführt wird, wird irgendwie das LAN angesprochen.
Meinst du dein "disableCond" oder das Attribut "disable"?
disableCond habe ich gar nicht.
Dann versuche ich dem mal auf den Grund zu gehen.
Ich habe ein neue Version eingecheckt.
Probier mal, ob mit der Version der Fehler behoben ist.
Ich muss dich leider enttäuschen. Die Hinweise erscheinen immer noch.
Irgendwie meine ich aber eine Art ~15-Minuten-Takt erkennen zu können. Aber das geht afaik nicht über den ganzen Tag.
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:10:12 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 10:26:21
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:26:21 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 10:43:03
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:43:03 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:00:25
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:00:25 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:16:31
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:16:31 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:32:51
2015.07.09 11:32:51 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:32:51 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:32:51 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:50:01
ich werde das nicht herausfinden - es muss irgendwie mit der Installation zu tun haben.
Okay, dann muss ich damit leben.
Ich habe nochmal ein wenig mit den DEFs & Co. herumgespielt. Außerdem habe ich die Pilight-Geräte mal durch andere Zwischenstecker ersetzt. Die Fehlermeldungen bleiben identisch. @Risiko: Es liegt also nicht an deinem Pilight-Modul.
Hier nochmal mein RT:
Internals:
CFGFN ./FHEM/innenbeleuchtung.cfg
COMMAND off
DEF 08:00 switch_fb_1 23:00 1000
DEVICE switch_fb_1
NAME rand_tischlampen
NR 457
REL
REP
SIGMAOFF 800
SIGMAON 200
STARTTIME 09.07.2015 08:00:00
STATE disabled
STOPTIME 09.07.2015 23:00:00
SWITCHMODE 800/200
S_REL
S_REP
TIMESPEC_START 08:00
TIMESPEC_STOP 23:00
TIMETOSWITCH 1000
TYPE RandomTimer
active 0
startTime 1436421600
stopTime 1436475600
Timer:
Rand_tischlampen_exec:
HASH rand_tischlampen
MODIFIER Exec
NAME rand_tischlampen_Exec
Rand_tischlampen_settimer:
HASH rand_tischlampen
MODIFIER SetTimer
NAME rand_tischlampen_SetTimer
Attributes:
alias Zufallsautomatik Tischlampen
disable 1
group Tischlampen
icon light_toggle
room Automation
sortby 80
Wenn ich dem irgendwann mal auf die Spur gekommen bin, dann lasse ich es euch wissen. :-)
Zitat von: FunkOdyssey am 09 Juli 2015, 16:52:25
Okay, dann muss ich damit leben.
Ich habe nochmal ein wenig mit den DEFs & Co. herumgespielt. Außerdem habe ich die Pilight-Geräte mal durch andere Zwischenstecker ersetzt. Die Fehlermeldungen bleiben identisch. @Risiko: Es liegt also nicht an deinem Pilight-Modul.
Habe heute nochmals alles durchgesehen und nichts gefunden.
Bin deiner Meinung FunkOdyssey, da zudem Leute mit anderen Modulen z.B. IT mit RT Probleme haben.
Risiko
Hallo!
Ich habe seit einigen Tagen das Problem, dass meine per RandomTimer gesteuerten Lampe an bleiben, wenn ich die Timer per "disable 1" deaktiviere. Wurde etwas dahingehend am Modul geändert?
Ich aktiviere die Timer bei Abwesenheit zur Anwesenheitssimulation und deaktiviere diese per notify, wenn ich wieder anwesend bin.
Gruß Oli
Zitat von: FunkOdyssey am 09 Juli 2015, 11:41:01
Ich muss dich leider enttäuschen. Die Hinweise erscheinen immer noch.
Irgendwie meine ich aber eine Art ~15-Minuten-Takt erkennen zu können. Aber das geht afaik nicht über den ganzen Tag.
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:10:12 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:10:12 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 10:26:21
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:26:21 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:26:21 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 10:43:03
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 10:43:03 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 10:43:03 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:00:25
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:00:25 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:00:25 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:16:31
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 3: [rand_tischlampen] ERROR: IO::Socket::INET: connect: No route to host EVALUATING 0
2015.07.09 11:16:31 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:16:31 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:32:51
2015.07.09 11:32:51 4: [rand_tischlampen] RandomTimer on tischlampen_diele_kueche timer disabled - no switch
2015.07.09 11:32:51 5: [rand_tischlampen] removing Timer: rand_tischlampen_Exec
2015.07.09 11:32:51 5: [rand_tischlampen] setting Timer: rand_tischlampen_Exec 2015-07-09 11:50:01
@ FunkOdyssey, Bartimaus:
Kannst nocheinmal prüfen, ob mit der soeben freigegebenen Version dein Problem noch auftritt.
Ich habe intern ein wenig umgestellt.
Zitat von: OliS. am 13 Juli 2015, 19:07:06
Hallo!
Ich habe seit einigen Tagen das Problem, dass meine per RandomTimer gesteuerten Lampe an bleiben, wenn ich die Timer per "disable 1" deaktiviere. Wurde etwas dahingehend am Modul geändert?
Ich aktiviere die Timer bei Abwesenheit zur Anwesenheitssimulation und deaktiviere diese per notify, wenn ich wieder anwesend bin.
Gruß Oli
ja, das ist so weil ich es so richtig fand. Wenn ich während der Simulation nach Hause komme, möchte ich nach dem Abstellen des RT nicht dass die Lampen ausgeschaltet werden.
Zitat von: Dietmar63 am 13 Juli 2015, 22:50:03
ja, das ist so weil ich es so richtig fand. Wenn ich während der Simulation nach Hause komme, möchte ich nach dem Abstellen des RT nicht dass die Lampen ausgeschaltet werden.
Ah, gut zu wissen. Und was bewirkt das Attribut "keepDeviceAlive" jetzt?
ich meine das Attribut sollte das Geräte anlassen.
Zitat von: Dietmar63 am 14 Juli 2015, 11:10:54
ich meine das Attribut sollte das Geräte anlassen.
Aber genau das funktioniert ja nicht mehr. Ich hatte bei allen meinen RT das Attribut "keepDeviceAlive 0". Bei mir hat das bewirkt, dass, wenn ich während der Anwesenheitssimulation nach Hause kam, die Lampen nach und nach wieder ausgegangen sind. Jetzt bleiben sie an.
EDIT: Um es noch mal zu verdeutlichen. Das Attribut "keepDeviceAlive" scheint keine Funktion mehr zu haben. Egal ob ich "attr keepDeviceAlive 0" oder "attr keepDeviceAlive 1" setzte oder das Attribut komplett lösche. Die Lampen bleiben an. Ist das so gewollt?
Zitat von: Dietmar63 am 13 Juli 2015, 22:48:31
@ FunkOdyssey, Bartimaus:
Kannst nocheinmal prüfen, ob mit der soeben freigegebenen Version dein Problem noch auftritt.
Ich habe intern ein wenig umgestellt.
Ich habe die Änderung heute morgen aktiviert. Bisher (ca. 2,5 Stunden) sind noch keine Fehlermeldungen aufgetreten. Ich werde das weiter beobachten. Danke.
Zitat von: FunkOdyssey am 14 Juli 2015, 11:39:47
Ich habe die Änderung heute morgen aktiviert. Bisher (ca. 2,5 Stunden) sind noch keine Fehlermeldungen aufgetreten. Ich werde das weiter beobachten. Danke.
Die Ursache für das Problem ist nicht wirklich behoben. Der entscheidende Befehl wird nur nicht mehr ausgeführt.
Ja, ich hab es gesehen. Ich hatte mir gestern dein Commit angeschaut.
Zum keepDeviceAlive:
Ich habe den Abschnitt der commandref
ZitatdisableCond
The default behavior of a RandomTimer is, that it shuts down the device after stoptime is reached. The keepDeviceAlive attribute changes the behavior. If set, the device status is not changed when the stoptime is reached.
so interpretiert (und auch implementiert), dass nur zum Ende der Laufzeit des RandomTimers (<timespec_stop>) das Attribut keepDeviceAlive ausgewertet und entsprechend das offCmd (oder eben nicht) ausgeführt wird.
Finde ich persönlich auch OK so, ein reines disable des RandomTimers sollte mMn nicht dazu führen, dass das offCmd ausgeführt wird.
Ein disable ist mMn aus reiner Funktionssicht des RandomTimers eine "Ausnahme" und sollte keine weiteren "Folgen" haben.
Ich z.B. mache es so, dass, wenn Anwesenheit erkannt wird, der RandomTimer zwar im notify der Anwesenheitserkennung disabled wird und zusätzlich die zur Anwesenheitssimulation benötigten Lampen (falls an) ausgeschaltet werden.
Dietmar63, ist das auch so in Deinem Sinn oder verstehe ich hier etwas falsch?
Andreas
PS: Ob sich das Verhalten in letzter Zeit geändert hat, kann ich nicht beurteilen, da ich wie oben beschrieben die nicht mehr zur Anwesenheitssimulation benötigten Lampen bei Anwesenheit sowieso ausschalte.
ZitatAndreas
PS: Ob sich das Verhalten in letzter Zeit geändert hat, kann ich nicht beurteilen, da ich wie oben beschrieben die nicht mehr zur Anwesenheitssimulation benötigten Lampen bei Anwesenheit sowieso ausschalte.
es hat definitiv eine Änderung gegeben. Und zwar dann wenn während der aktiven Simulation die disable-Bedingung gesetzt wird, wird nicht geschaltet.
Hintergrund: Ich lasse die Simulation immer in der Dämmerung laufen. Wenn ich dann nach Hause komme, schalte ich den timer über disable 1 ab. Dann soll das Licht so bleiben wie es ist (in der Regel an).
Zitat von: Dietmar63 am 14 Juli 2015, 14:41:10
es hat definitiv eine Änderung gegeben. Und zwar dann wenn während der aktiven Simulation die disable-Bedingung gesetzt wird, wird nicht geschaltet.
Hintergrund: Ich lasse die Simulation immer in der Dämmerung laufen. Wenn ich dann nach Hause komme, schalte ich den timer über disable 1 ab. Dann soll das Licht so bleiben wie es ist (in der Regel an).
Schade! Na ja, ich habe jetzt erst mal eine alte Version des Moduls eingespielt und mit "exclude_from_update" geschützt. Ich fand die alte Funktionalität ganz gut. Ich möchte nämlich auch tagsüber nicht, dass bei mir eingebrochen wird... ;)
Ich denke langfristig werde ich die Lampen bei Bedarf und in Abhängigkeit von der Dämmerung per notify ausschalten, wenn ich nach Hause komme.
Danke für die Aufklärung.
Oli
Zitat von: FunkOdyssey am 14 Juli 2015, 13:23:52
Ja, ich hab es gesehen. Ich hatte mir gestern dein Commit angeschaut.
Und noch Fehlerfrei?
Man könnte dem Problem weiternachgehen, wenn man eine kleine Funktion in 99_myUtils.pm mit dem Fehlerhaften Codestück
"eval 0" baut, und es regelmäßig per at aufruft. Vielleicht lässt sich daraus ein Muster ableiten.
Das müsstest du dann bei dir machen, weil nur du das Problem hast.
Zitat von: OliS. am 14 Juli 2015, 15:23:52
Schade! Na ja, ich habe jetzt erst mal eine alte Version des Moduls eingespielt und mit "exclude_from_update" geschützt. Ich fand die alte Funktionalität ganz gut. Ich möchte nämlich auch tagsüber nicht, dass bei mir eingebrochen wird... ;)
Ich denke langfristig werde ich die Lampen bei Bedarf und in Abhängigkeit von der Dämmerung per notify ausschalten, wenn ich nach Hause komme.
Danke für die Aufklärung.
Oli
Ich denke da mal weiter drüber nach, ob bzw. wie man das noch besser lösen kann.
Zitat von: Dietmar63 am 14 Juli 2015, 19:36:44
Und noch Fehlerfrei?
Man könnte dem Problem weiternachgehen, wenn man eine kleine Funktion in 99_myUtils.pm mit dem Fehlerhaften Codestück "eval 0" baut, und es regelmäßig per at aufruft. Vielleicht lässt sich daraus ein Muster ableiten.
Das müsstest du dann bei dir machen, weil nur du das Problem hast.
Ich kann keine Fehler feststellen.
Zitat von: Dietmar63 am 14 Juli 2015, 19:43:08
Ich denke da mal weiter drüber nach, ob bzw. wie man das noch besser lösen kann.
Das ist nett. Aber nur meinetwegen musst Du das nicht tun. Anscheinend bin ich ja der Einzige, der das Modul auf diese Weise nutzt. Ich kann mir auch damit helfen, die Lampen bei Anwesenheit per notify auszuschalten.
Oli
Zitat von: Dietmar63 am 12 Januar 2014, 19:34:39
ich baue folgende Funktion ein:
sub RandomTimer_Wakeup() { # {RandomTimer_Wakeup()}
foreach my $hc ( sort keys %{$modules{RandomTimer}{defptr}} ) {
my $hash = $modules{RandomTimer}{defptr}{$hc};
RandomTimer_ExecRepeater($hash);
Log3 undef, 3, "RandomTimer_Wakeup() for $hash->{NAME} done!";
}
Log3 undef, 3, "RandomTimer_Wakeup() done!";
}
Dann musst du nur noch mit einem notify die dummy abhorchen und diese Fuktion aufrufen. Etwa so:
define RTautomatOn notify dummy:.* {RandomTimer_Wakeup()}
Erst mal: tolles Modul, DANKE !!!
Ich habe alles hin bekommen wie oben beschrieben. Aktivieren/Deaktivieren geht perfekt, auch während der Laufzeit des RandomTimers. Aber im UI bleibt die Anzeige unverändert, egal ob ich isVerreist auf "ja" oder "nein" stelle. Es steht immer statisch "disabled" oder das Glühbirnensymbol. Nach einem Refresh im Browser wird der Status richtig angezeigt. Mit update-on-change-reading .* habe ich es schon erfolglos versucht. Wie bekomme ich ein automatisches Update des UI beim Verändern des Status?
@Dietmar: Nichts wichtiges. Mir ist nur eine falsche Überschrift in der commandref aufgefallen. Vielleicht könntest du bei einer zukünftigen Änderung die zweite Überschrift "disableCond" in "keepDeviceAlive" ändern. Danke.
ZitatdisableCond
The default behavior of a RandomTimer is, that it works. To set the Randomtimer out of work, you can specify in the disableCond attibute a condition in perlcode that must evaluate to true. The Condition must be put into round brackets. The best way is to define a function in 99_utils.
Examples
attr ZufallsTimerZ disableCond (!isVerreist())
attr ZufallsTimerZ disableCond (Value("presenceDummy") ne "present"))
disableCond
The default behavior of a RandomTimer is, that it shuts down the device after stoptime is reached. The keepDeviceAlive attribute changes the behavior. If set, the device status is not changed when the stoptime is reached.
Example
attr ZufallsTimerZ keepDeviceAlive
Zitat von: FunkOdyssey am 23 September 2015, 10:48:10
@Dietmar: Nichts wichtiges. Mir ist nur eine falsche Überschrift in der commandref aufgefallen. Vielleicht könntest du bei einer zukünftigen Änderung die zweite Überschrift "disableCond" in "keepDeviceAlive" ändern. Danke.
geändert - checke ich demnächst ein
Ich habe direkt noch einmal ne Frage.
Ich schalte je nach Anwesenheit der Personen (RESIDENTS-Modul) meine RandomTimer-Definition über das "disable"-Attribut ein und aus. Also nicht über das Attribut "disableCond".
Mir ist nun aufgefallen, dass das Datum in STARTTIME und STOPTIME nicht aktualisiert wird. Die dahinter liegenden Lampen sind heute (25.09.2015) noch kein einziges mal eingeschaltet worden. Ich vermute, weil in STARTTIME & Co. noch der 24.09.2015 steht.
Mache ich irgendetwas falsch?
Internals:
COMMAND on
DEF 08:00 struct_lampen 23:00 1000
DEVICE struct_lampen
NAME rand_lampen
NR 485
REL
REP
SIGMAOFF 800
SIGMAON 200
STARTTIME 24.09.2015 08:00:00
STATE off
STOPTIME 24.09.2015 23:00:00
SWITCHMODE 800/200
S_REL
S_REP
TIMESPEC_START 08:00
TIMESPEC_STOP 23:00
TIMETOSWITCH 1000
TYPE RandomTimer
active 0
startTime 1443074400
stopTime 1443128400
Timer:
rand_lampen_exec:
HASH rand_lampen
MODIFIER Exec
NAME rand_lampen_Exec
rand_lampen_settimer:
HASH rand_lampen
MODIFIER SetTimer
NAME rand_lampen_SetTimer
Attributes:
alias Zufallsautomatik Tischlampen
disable 0
group Innenbeleuchtung
icon light_toggle
room Programmierung
sortby 80
switchmode 800/200
Am Rande: Könnte das Modul evtl. auch ein wenig mehr loggen? Das FileLog ist bei mir vollständig leer und ich muss mir immer die Logs der Geräte anschauen. Bedankt.
Ich glaube gerade im Quellcode erkannt zu haben, dass ich noch das Verbose-Level erhöhen muss. Das probieren ich erst einmal aus. Sorry.
Keiner ne Idee wegen der Nichtaktualisierung des Datums?
was steht denn jetzt in STARTTIME und STOPTIME ?
Das Datum des letzten FHEM-Neustarts.
Und hätte ich FHEM nicht neu gestartet, so würde dort immer noch der 24.09. stehen.
Ehrlich gesagt habe ich meine RandomTimer-Defines mittlerweile gelöscht, da ich dringend eine zuverlässigere Lösung benötigte. Aber ich kann es gerne wieder ausprobieren.
Sende mir bitte die Definition. Bitte auch die Version des Moduls und was du damit machen willst.
Ich glaube, ich habe deinen Fehler gefunden.
Meine Definition sieht so aus:
*{sunset_abs_rand(40)} StehlampeTisch +{zufallsTimerAbschaltzeit()} 480
das * vor dem timespec ist wichtig für eine wiederholte Ausführung(wie at)
Im Übrigen kann es auch immer an der Anwesenheits-/Abwesenheitserkennung liegen, wenn etwas nicht funktionert. Ich mag so etwas(IP Abfragen auf Handys ...) überhaupt nicht.
Also läuft zuverlässig, wenn man es richtig macht.
Oops. Das klingt logisch. Das hatte ich auch ursprünglich. Nur wusste ich nie wieso.
Danke für deine Hilfe.
Noch einmal ne Frage in die Runde:
Wenn ich mehrere Lampen einzeln zufallsgesteuert ein- und ausschalten möchte, muss man für jede Lampe einen eigenen RandomTimer anlegen? Oder gibt es da einen Trick, den ich übersehen habe?
Per DOIF habe ich das versucht, folgendermaßen zu lösen:
set stru_lampe_{(int(rand(3))+1)}:FILTER=state!=on on-for-timer {(int(rand(59))+1)*60}
Hinweis: Ich habe vier Structures (stru_lampe_1, stru_lampe_2, etc.) mit den dahinterliegenden Lampen angelegt.
Wenn du es über structure löst, sollten alle Lampen gleichzeitig geschaltet werden, das ist nicht der Sinn von RandomTimer.
Ich habe vier durchnummerierte Structures mit jeweils nur einer Lampe. Und diese werden per DOIF zufällig ausgewählt und ein- oder ausgeschaltet. Jedoch würde ich das lieber per RT lösen.
Ich hab jetzt einfach vier RT ausgewählt. Mit Perl-Code im DEF klappte es nicht.
Habe heute keine Zeit - versuche morgen mich damit zu beschäftigen.
Kein Problem. Ich habe ja ne Lösung und versuche nur, es eleganter zu lösen. Also keinen Streß.
ZitatIch hab jetzt einfach vier RT ausgewählt. Mit Perl-Code im DEF klappte es nicht.
wie hast du es versucht?
RT ist so gebaut, dass er genau ein Gerät über einen gewissen Zeitraum hinweg ein- bzw. auschaltet.
Er immitiert die ZeitschaltFunkuhr FS20ZSU, die man für ca 60€ kaufen kann.
Du musst also 4 RT anlegen.
Hallo zusammen.
Bis gestern hat mein eingesetzter RandomTimer perfekt funktioniert. Nachdem ich heute ein paar Anpassungen (zusätzliche RT) vorgenommen habe, funktioniert das Ein-/Ausschalten des RT bei mir nicht mehr ... und ich bin gerade am verzweifeln. Selbst nach einem Rückbau funktioniert es nicht :-(.
Vielleicht sieht einer von euch auf Anhieb, wo das Problem liegt. Hier meine Config:
99_myUtils.pm:
sub AnwSim () { return(YesNo("AnwSimulation")); }
#
sub YesNo ($) {
my ($dummy) = @_;
my $state = ReadingsVal($dummy, "state", "off");
if ($state eq "off") {
return 0;
fhem{"set wz_Leuchte off"};
}
return 1;
fhem{"set wz_Leuchte on"};
}
Verwendung:
define AnwSimulation dummy
attr AnwSimulation fm_type offbutton,onbutton
attr AnwSimulation group AlarmStatus
attr AnwSimulation room 00_AlarmStatus
attr AnwSimulation setList on off
attr AnwSimulation webCmd on:off
define ZufallsTimer_On notify AnwSimulation:.* {RandomTimer_Wakeup()}
define ZufallsTimer_BZ1 RandomTimer *{TimeRnd("06:30","07:30")} bz_Tischleuchte *{sunrise_abs("REAL",900+rand(800)-400)} 440
attr ZufallsTimer_BZ1 disableCond (!AnwSim())
attr ZufallsTimer_BZ1 room 99_RandomTimer
attr ZufallsTimer_BZ1 switchmode 500/700
Beim Ein-/Ausschalten über den Dummy "AnwSimulation" kommt die Meldung "RandomTimer_Wakeup() done!", der STATE der RT ändert sich aber nicht.
Komischerweise wird der STATE der RT aber korrekt gesetzt, wenn ich in die fhem.cfg reingehe und diese (auch ohne Änderung) speichere und FHEM neu startet.
Übersehe ich etwas?
Ist das Absicht mit der Reihenfolge?
return 0;
fhem{"set wz_Leuchte off"};
Nach einem Return wird der Rest nicht ausgeführt.
Setze mal verbose 5 auf dem RT[/code]
Danke für die schnelle Antwort! :-)
Der FHEM-Befehl im 99_myUtils.pm war mein verzweifelter Versuch, zu "debuggen", steht aber natürlich an der falschen Stelle (war schon spät ;-) ...).
Hier das Log mit verbose 5 auf dem RT (Ausgangssituation: AnwSimulation ausgeschlatet, RT disabled):
shutdown restart
2015.10.17 09:24:04 4: [ZufallsTimer_BZ1] timings RandomTimer on bz_Tischleuchte: 07:02:00(17) - 08:06:54(17)
2015.10.17 09:24:04 5: [ZufallsTimer_BZ1] setting Timer: ZufallsTimer_BZ1_Exec 2015-10-17 09:24:04
2015.10.17 09:24:04 5: [ZufallsTimer_BZ1] removing Timer: ZufallsTimer_BZ1_SetTimer
2015.10.17 09:24:04 5: [ZufallsTimer_BZ1] setting Timer: ZufallsTimer_BZ1_SetTimer 2015-10-18 00:07:35
2015.10.17 09:24:04 4: [ZufallsTimer_BZ1] RandomTimer on bz_Tischleuchte timer disabled - no switch
2015.10.17 09:24:04 4: [ZufallsTimer_BZ1] defintion RandomTimer on bz_Tischleuchte: 07:02:00(17) - 08:06:54(17)
AnwSimulation eingeschaltet
2015.10.17 09:26:10 3: RandomTimer_Wakeup() done!
Nach dem Einschalten gibt's nur diesen einen Eintrag im Log?!
Zur sicherheit hier noch mal meine komplette 99_myUtils.pm
package main;
use strict;
use warnings;
use POSIX;
sub
myUtils_Initialize($$)
{
my ($hash) = @_;
}
#################################################
# start with your own functions below this line #
#################################################
#
#
sub AnwSim () { return(YesNo("AnwSimulation")); }
#
#
sub YesNo ($) {
my ($dummy) = @_;
my $state = ReadingsVal($dummy, "state", "off");
if ($state eq "off") {
return 0;
}
return 1;
}
#
#
sub randtime24plus($$) {
use Time::Local 'timelocal';
my ($ts,$offset) = @_;
my ($h,$m,$s) = split(/:/,$ts);
my @now = localtime(time);
my $ts_fix = timelocal($s,$m,$h,$now[3],$now[4],$now[5]);
my $offset_rand = int(rand($offset * 60));
my $delta;
if (time < $ts_fix) { # nächster Zeitpunkt ist heute
$delta = $ts_fix - time + $offset_rand;
} else { # nächster Zeitpunkt ist morgen
$delta = $ts_fix - time + $offset_rand + 86400;
}
return sprintf("%02d:%02d:%02d", $delta/3600, ($delta/60)%60, $delta%60);
}
#
#
######## DebianMail Mail auf dem BBB versenden ############
#
sub DebianMail {
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "xxx\@xxx.com";
my $konto = "xxx\@xxx.com";
my $passwrd = "xxx";
my $provider = "smtp.xxx.com:587";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=yes -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}
#
#
######## TimeRnd Zeit Zufall von bis #############################
# Aufrufbeschreibung: TimeRnd("vzeit","bzeit")
# vzeit = Startzeitpunkt zB. "07:00:00" oder "07:00"
# bzeit = Endzeitpunkt zB. "07:10:00" oder "07:10"
# TimeRnd = keine 24 Stunden aufaddiert
#
sub TimeRnd($$) {
my ($h1,$m1,$s1) = split(":", shift);
my ($h2,$m2,$s2) = split(":", shift);
$s1 = 0 if(!$s1);
$s2 = 0 if(!$s2);
my $t1 = 3600*$h1+60*$m1+$s1;
my $t2 = 3600*$h2+60*$m2+$s2;
my $er = int(rand($t2-$t1)+$t1);
return sprintf("%02d:%02d:%02d", $er/3600, ($er/60)%60, $er%60) if($s1);
return sprintf("%02d:%02d", $er/3600, ($er/60)%60);
}
#
####################################################
# behind your last function, we need the following #
####################################################
1;
Die Sub TimeRnd ist gestern neu dazu gekommen, aber selbst ohne läuft's nicht mehr.
Vermulich passiert nichts, weil die aktive Zeit des RT um 9:24 für den Tag schon abgelaufen ist:
Zitattimings RandomTimer on bz_Tischleuchte: 07:02:00(17) - 08:06:54(17)
Eine etwas verspätete Rückmeldung (war länger unterwegs) - es funktionieren tatsächlich alle RandomTimer zuverlässig. Sobald ein Timer an der Reihe ist, schaltet der STATE von "disabled" auf "on" und läuft.
Ich hätte schwören können, dass (früher) nach Aktivierung der Timer der STATE sofort auf "off" und - wenn aktiv - auf "on" gewechselt ist.
Danke für die Hilfe!
Ich habe (mal wieder) eine Frage zu nem Problem.
Ich schalte meine RandomTimer-Defitinionen über die Anwesenheit und schalte die unterschiedlichen RT-Defs per "attribut xyz disable 1" aus.
Nun hatte ich das schon einmal, dass aus irgendeinem Grund (egal woher) der Zufallsmodus im Hintergrund noch an war oder die RT rund um den STOPTIME-Zeitpunkt die Lampen ausschalten.
Also habe ich mir gedacht, dass ich prophylaktisch alle RT-Geräte (immer) deaktiviere, sobald am Wandtaster eine Taste für die manuelle Ein- und Ausschaltung gedrückt wird.
([taster_btn_01] =~ "Short")
(
attr rand_lampe1 disable 1,
attr rand_lampe2 disable 1,
attr rand_lampe3 disable 1,
attr rand_lampe4 disable 1,
attr di_tischlampen disable 0,
set leuchte on
)
Ich wollte also die Sache benutzerfreundlicher machen und sämtliche Zufallsgeneratoren deaktivieren sobald man manuelle Aktionen auslöst.
Nun aber zum Problem:
Wenige Minuten nach dem "attribut xyz disable 1" gehen die Lampen wieder an. Und das wird wohl vom RandomTimer ausgelöst, der eigentlich aus ist.
Hier mal ein RT-Def:
Internals:
COMMAND on
DEF *08:00 leuchte 23:59 3500
DEVICE leuchte
NAME rand_lampe1
NR 772
REL
REP *
SIGMAOFF 500
SIGMAON 500
STARTTIME 10.11.2015 08:00:00
STATE disabled
STOPTIME 10.11.2015 23:59:00
SWITCHMODE 500/500
S_REL
S_REP
TIMESPEC_START *08:00
TIMESPEC_STOP 23:59
TIMETOSWITCH 3500
TYPE RandomTimer
active 0
startTime 1447138800
stopTime 1447196340
Timer:
Rand_lampe1_exec:
HASH rand_lampe1
MODIFIER Exec
NAME rand_lampe1_Exec
Rand_lampe1_settimer:
HASH rand_lampe1
MODIFIER SetTimer
NAME rand_lampe1_SetTimer
Attributes:
disable 1
switchmode 500/500
Frage also: Warum gehen die Leuchten wieder an, obwohl RZ disabled ist?
Hat jemand eine Idee? Danke.
Ich denke mal darüber nach
Ich habe gestern mal verbose auf 4 gesetzt. In der Hoffnung, etwas mehr zu sehen. Leider ohne Erfolg. Im fhem.log stand nichts von Interesse. (RandomTimer loggt übrigens nicht in Geräte-individuellen Logs.)
2015-11-10_17:53:57 leuchte on
2015-11-10_23:11:46 leuchte off # manuelle Ausschaltung über Wandtaster
2015-11-10_23:17:14 leuchte on # ging wieder an
2015-11-10_23:19:19 leuchte off # erneut manuelle Ausschaltung
2015-11-10_23:24:24 leuchte on # und wieder angegangen
2015-11-10_23:39:57 leuchte off # über WebGUI ausgeschaltet
Merkwürdig finde ich auch, dass von meinen vier RT-Geräten (mit jeweils eigenen Leuchten) immer nur zwei wieder eingeschaltet werden. Die anderen beiden bleiben aus. Und das obwohl der RT-Code und der disable-Code identisch ist.
NACHTRAG:
Stopp. Warte mal. Direkt nach dem Absenden ist mir eine Idee gekommen. Manchmal muss man es einfach mal runtertippen, um auf einen Lösungsansatz zu kommen. Ich prüfe noch einmal etwas nach. Ich glaube, dass es doch nicht am RandomTimer liegt, sondern an meinen DOIF "di_tischlampen", der exakt die zwei (von vier) Leuchten steuert.
Nachtrag 2:
Ich bin mir sicher, dass es nun nicht am RandomTimer liegt. Ich de-aktiviere ein DOIF, welches die zwei Leuchte über Helligkeitswerte triggert. Und alle x Minuten wird dieser Wert übertragen und dadurch die Lampen eingeschalten.
Es tut mir leid, dass ich den Thread hier zweckentfremdet habe. Meine Schuld. Sorry.
Kein Problem - ich hatte ja noch keine Zeit investiert.
Hallo,
seit einiger Zeit schalten meine RT nicht mehr. Ich habe hier eine Anwesenheitserkennung, die über ein DOIF insgesamt 6 RT auf disabled 0/1 setzt. Das funktioniert auch alles wunderbar, nur werden nach dem Starten der RT (disabled 0) die entsprechenden Schaltbefehle in letzter Zeit nicht mehr/nur vereinzelt ausgeführt.
Hier einmal ein Beispiel für einen RT:
define zufall_wohnzimmer_abends RandomTimer *{sunset_abs(-3100)} Dimmer_Wohnzimmer *{sunset_abs(+3720,"21:32","23:32")} 800
attr zufall_wohnzimmer_abends disable 0
attr zufall_wohnzimmer_abends onCmd set Dimmer_Wohnzimmer pct 60
attr zufall_wohnzimmer_abends room Wohnzimmer
attr zufall_wohnzimmer_abends switchmode 999/100
Hier ein kleiner Auszug aus dem LOG, die RT starten, schalten aber nicht:
2015.11.20 18:02:22 3: [zufall_arbeitszimmer_abends] starting RandomTimer on Licht_Arbeitszimmer: 16:18:54(20) - 21:32:00(20)
2015.11.20 18:05:51 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:22:14(20) - 21:33:00(20)
2015.11.20 18:06:07 3: [zufall_wohnzimmer_abends] starting RandomTimer on Dimmer_Wohnzimmer: 16:20:34(20) - 21:32:00(20)
Das Maximum ist, daß ein einziger RT schaltet:
2015.11.19 18:41:56 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:22:14(19) - 21:33:00(19)
2015.11.19 18:47:50 3: [zufall_arbeitszimmer_abends] starting RandomTimer on Licht_Arbeitszimmer: 16:19:54(19) - 21:32:00(19)
2015.11.19 18:48:33 3: [zufall_wohnzimmer_abends] starting RandomTimer on Dimmer_Wohnzimmer: 16:21:34(19) - 21:32:00(19)
2015.11.19 18:48:33 3: CUL_HM set Dimmer_Wohnzimmer pct 60
Die beiden anderen bleiben stumm, nur die eine Lampe wird im Verlauf weiter geschaltet.
Was läuft hier falsch oder was wurde am RT geändert, daß meine zugegebenermassen etwas komplizierten Konstrukte der Vergangenheit nicht mehr funktionieren?
Vielen Dank für eure Hilfe im voraus
oelidoc
Kann ich mir erst morgen Abend ansehen
Zitat von: Dietmar63 am 20 November 2015, 22:44:22
Kann ich mir erst morgen Abend ansehen
OK, dann warte ich mal.
Gruß
oelidoc
Also...
das Problem besteht immer noch: die RT starten, schalten aber nicht nicht.
Hier mal ein RT, der seit zwei Stunden kein einziges Mal das Licht eingeschaltet hat:
Internals:
COMMAND on
DEF *{sunset_abs(-3000)} Dimmer_Kueche *{sunset_abs(+3960,"21:36","23:36")} 300
DEVICE Dimmer_Kueche
NAME zufall_kueche_abends
NR 117
REL
REP *
SIGMAOFF 999
SIGMAON 050
STARTTIME 02.12.2015 16:13:28
STATE on
STOPTIME 02.12.2015 21:36:00
SWITCHMODE 999/050
S_REL
S_REP *
TIMESPEC_START *{sunset_abs(-3000)}
TIMESPEC_STOP *{sunset_abs(+3960,"21:36","23:36")}
TIMETOSWITCH 300
TYPE RandomTimer
active 1
startTime 1449069208
stopTime 1449088560
Timer:
Zufall_kueche_abends_exec:
HASH zufall_kueche_abends
MODIFIER Exec
NAME zufall_kueche_abends_Exec
Zufall_kueche_abends_settimer:
HASH zufall_kueche_abends
MODIFIER SetTimer
NAME zufall_kueche_abends_SetTimer
Attributes:
disable 0
room Kueche
switchmode 999/050
Was kann ich tun?
Kleiner Nachtrag: wenn ich in der Web Oberfläche bei der Def des RT auf modify drücke, ohne etwas geändert zu haben, geht das Licht sofort an.
Gruß
oelidoc
Hatte gestern Abend keine Zeit. Setze mal bei dem Timer verbose 5. Dann bekommst du besseres Logging.
Hab ich:
2015.12.02 18:39:39 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:13:02(02) - 21:36:00(02)
2015.12.02 18:39:39 4: [zufall_kueche_abends] Zustand:on sigma:050 random:726->
2015.12.02 18:39:39 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.02 18:39:39 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-02 18:44:30
2015.12.02 18:44:30 4: [zufall_kueche_abends] Zustand:on sigma:050 random:562->
2015.12.02 18:44:30 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.02 18:44:30 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-02 18:49:33
Irgendwie sieht es für mich so aus, als wenn der RT "denkt" Dimmer_Kueche sei schon an - ist aber beim Start des RT vorher von Hand ausgemacht worden.
Gruß
oelidoc
warum hast du die Werte
SWITCHMODE 999/050
so gewählt?
SIGMAOFF 999
SIGMAON 050
Es wird mit fast 99,9 prozentiger Sicherheit ausgeschaltet aber nur mit 5,0 prozentiger Wahrscheinlichkeit wieder eingeschaltet.
das kann man im Log an folgenden Zeilen genau erkennen:
2015.12.02 18:39:39 4: [zufall_kueche_abends] Zustand:on sigma:050 random:726->
2015.12.02 18:44:30 4: [zufall_kueche_abends] Zustand:on sigma:050 random:562->
Es wird nur dann geschaltet wenn random:726 < sigma:050.
random ist eine Zufallszahl zwischen 0 und 1000.
Es ist also sehr unwahrscheinlich, dass deine Lampe angeschaltet wird.
Standard ist übrigens 800/200
Hallo Dietmar63,
vielen Dank für deine Hilfe.
Ich möchte, dass das Licht die allermeiste Zeit eingeschaltet ist und nur ab und zu für wenige Minuten mal ausgeht. Die Commandref zum Switchmode ist m.M.n. etwas widersprüchlich...
Also Switchmode einfach umdrehen und es sollte wie gewünscht laufen? Wirklich so einfach?
Gruß
oelidoc
Hi,
hab die Switchmode Werte jetzt umgedreht und FHEM neu gestartet. Trotzdem steht im Log:
2015.12.02 21:10:40 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:13:02(02) - 21:36:00(02)
2015.12.02 21:10:40 4: [zufall_kueche_abends] Zustand:off sigma:050 random:854->
2015.12.02 21:10:40 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.02 21:10:40 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-02 21:15:39
2015.12.02 21:14:49 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_SetTimer
2015.12.02 21:14:49 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_SetTimer 2015-12-02 21:14:50
2015.12.02 21:14:50 4: [zufall_kueche_abends] timings RandomTimer on Dimmer_Kueche: 16:13:02(02) - 21:36:00(02)
2015.12.02 21:14:50 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.02 21:14:50 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-02 21:14:50
2015.12.02 21:14:50 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_SetTimer
2015.12.02 21:14:50 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_SetTimer 2015-12-03 00:05:15
2015.12.02 21:14:50 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:13:02(02) - 21:36:00(02)
2015.12.02 21:14:50 4: [zufall_kueche_abends] Zustand:off sigma:050 random:548->
2015.12.02 21:14:50 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.02 21:14:50 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-02 21:20:03
Einziger Unterschied: jetzt ist "Zustand:off"
aber das Licht ist immer noch aus...
Werden die neuen Werte erst um 00:05 Uhr übernommen?
Gruß
oelidoc
Hallo,
es klappt immer noch nicht so, wie geplant :'(
Hier mal das List des RT mit dem geänderten Switchmode:
Internals:
COMMAND off
DEF *{sunset_abs(-3000)} Dimmer_Kueche *{sunset_abs(+3960,"21:36","23:36")} 300
DEVICE Dimmer_Kueche
NAME zufall_kueche_abends
NR 117
REL
REP *
SIGMAOFF 050
SIGMAON 999
STARTTIME 03.12.2015 16:13:02
STATE on
STOPTIME 03.12.2015 21:36:00
SWITCHMODE 050/999
S_REL
S_REP *
TIMESPEC_START *{sunset_abs(-3000)}
TIMESPEC_STOP *{sunset_abs(+3960,"21:36","23:36")}
TIMETOSWITCH 300
TYPE RandomTimer
active 1
startTime 1449155582
stopTime 1449174960
Timer:
Zufall_kueche_abends_exec:
HASH zufall_kueche_abends
MODIFIER Exec
NAME zufall_kueche_abends_Exec
Zufall_kueche_abends_settimer:
HASH zufall_kueche_abends
MODIFIER SetTimer
NAME zufall_kueche_abends_SetTimer
Attributes:
disable 0
room Kueche
switchmode 050/999
verbose 5
Damit schaltet der RT nur ganz selten für 300 sek das Licht ein und danach gleich wieder aus:
2015.12.03 16:13:02 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:13:02(03) - 21:36:00(03)
2015.12.03 16:13:02 4: [zufall_kueche_abends] Zustand:off sigma:050 random:882->
2015.12.03 16:13:02 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:13:02 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:17:48
2015.12.03 16:17:48 4: [zufall_kueche_abends] Zustand:off sigma:050 random:308->
2015.12.03 16:17:48 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:17:48 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:22:36
2015.12.03 16:22:36 4: [zufall_kueche_abends] Zustand:off sigma:050 random:140->
2015.12.03 16:22:36 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:22:36 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:27:35
2015.12.03 16:27:35 4: [zufall_kueche_abends] Zustand:off sigma:050 random:322->
2015.12.03 16:27:35 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:27:35 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:32:21
2015.12.03 16:32:21 4: [zufall_kueche_abends] Zustand:off sigma:050 random:287->
2015.12.03 16:32:21 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:32:21 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:37:22
2015.12.03 16:37:22 4: [zufall_kueche_abends] Zustand:off sigma:050 random:272->
2015.12.03 16:37:22 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:37:22 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:42:36
2015.12.03 16:42:36 4: [zufall_kueche_abends] Zustand:off sigma:050 random:406->
2015.12.03 16:42:36 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:42:36 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:47:32
2015.12.03 16:47:32 4: [zufall_kueche_abends] Zustand:off sigma:050 random:432->
2015.12.03 16:47:32 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:47:32 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:52:34
2015.12.03 16:52:34 4: [zufall_kueche_abends] Zustand:off sigma:050 random:594->
2015.12.03 16:52:34 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:52:34 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 16:57:31
2015.12.03 16:57:31 4: [zufall_kueche_abends] Zustand:off sigma:050 random:269->
2015.12.03 16:57:31 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 16:57:31 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:02:39
2015.12.03 16:59:43 3: CUL_HM set Licht_Arbeitszimmer on
2015.12.03 17:02:39 4: [zufall_kueche_abends] Zustand:off sigma:050 random:111->
2015.12.03 17:02:39 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:02:39 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:07:43
2015.12.03 17:03:02 3: CUL_HM set Jalousie1 off
2015.12.03 17:04:53 3: CUL_HM set Licht_Arbeitszimmer off
2015.12.03 17:07:43 4: [zufall_kueche_abends] Zustand:off sigma:050 random:521->
2015.12.03 17:07:43 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:07:43 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:12:28
2015.12.03 17:12:28 4: [zufall_kueche_abends] Zustand:off sigma:050 random:814->
2015.12.03 17:12:28 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:12:28 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:17:41
2015.12.03 17:17:41 4: [zufall_kueche_abends] Zustand:off sigma:050 random:315->
2015.12.03 17:17:41 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:17:41 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:22:51
2015.12.03 17:22:51 4: [zufall_kueche_abends] Zustand:off sigma:050 random:16->1
2015.12.03 17:22:51 4: [zufall_kueche_abends] command: set Dimmer_Kueche on
2015.12.03 17:22:51 3: CUL_HM set Dimmer_Kueche on
2015.12.03 17:22:51 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:22:51 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:27:59
2015.12.03 17:27:59 4: [zufall_kueche_abends] Zustand:on sigma:999 random:140->1
2015.12.03 17:27:59 4: [zufall_kueche_abends] command: set Dimmer_Kueche off
2015.12.03 17:27:59 3: CUL_HM set Dimmer_Kueche off
2015.12.03 17:27:59 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:27:59 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:33:06
2015.12.03 17:33:06 4: [zufall_kueche_abends] Zustand:off sigma:050 random:376->
2015.12.03 17:33:06 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:33:06 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:37:56
2015.12.03 17:37:56 4: [zufall_kueche_abends] Zustand:off sigma:050 random:584->
2015.12.03 17:37:56 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:37:56 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:43:01
2015.12.03 17:43:01 4: [zufall_kueche_abends] Zustand:off sigma:050 random:733->
2015.12.03 17:43:01 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:43:01 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:47:55
2015.12.03 17:47:55 4: [zufall_kueche_abends] Zustand:off sigma:050 random:45->1
2015.12.03 17:47:55 4: [zufall_kueche_abends] command: set Dimmer_Kueche on
2015.12.03 17:47:55 3: CUL_HM set Dimmer_Kueche on
2015.12.03 17:47:55 5: [zufall_kueche_abends] removing Timer: zufall_kueche_abends_Exec
2015.12.03 17:47:55 5: [zufall_kueche_abends] setting Timer: zufall_kueche_abends_Exec 2015-12-03 17:52:43
2015.12.03 17:52:43 4: [zufall_kueche_abends] Zustand:on sigma:999 random:988->1
2015.12.03 17:52:43 4: [zufall_kueche_abends] command: set Dimmer_Kueche off
2015.12.03 17:52:43 3: CUL_HM set Dimmer_Kueche off
Was muss ich ändern, damit das Licht beim Start des RT eingeschaltet wird und die meiste Zeit an bleibt?
Zwei weitere RT mit den gleichen Einstellungen schalten übrigens noch seltener oder gar nicht das Licht ein...
Gruß
oelidoc
OK,
ich glaube ich habe den Fehler erkannt - kann ihn aber nicht abstellen.
Wie ich ja schon schrieb, aktiviere oder deaktiviere ich die RT durch das Attribut disable. Wenn ich einen laufenden RT disable, während die Lampe on ist, und den RT danach wieder enable, geht er laut Log davon aus, dass die Lampe on ist und berechnet die "Wahrscheinlichkeit" zum Ausschalten. Tatsächlich ist die Lampe aber aus, weil sie z.B. zwischenzeitlich jemand am Schalter ausgemacht hat. Der RT kriegt das aber nicht mit. Es müsste also nach dem disable 0 der Status des zu schaltenden Gerätes geprüft werden oder der RT schickt zu Beginn immer ein on command. Ich meine auch, dass das früher so war, denn meine RT funktionieren erst seit einiger Zeit nicht mehr mit dem attribut disable. Z.Zt. geht die Lampe erst an, wenn der RT einmal aus und dann wieder an geschaltet hat. Was natürlich bei entsprechendem switchmode und Schaltdauer ganz schön lange dauern kann...
Lieber Dietmar63, kannst du das nachvollziehen? Hab ich mich verständlich ausgedrückt?
Für Nachfragen stehe ich jederzeit zur Verfügung
Gruß
oelidoc
ja,
ich habe das grob verstanden.
Zitates müsste also nach dem disable 0 der Status des zu schaltenden Gerätes geprüft werden oder der RT schickt zu Beginn immer ein on command.
Und das ist bei der Vielzahl der Geräte und Variablen die bei den unterschiedlichen Geräten nicht möglich.
Vielleicht kannst du etwas mit den Attributen onCmd bzw. offCmd anfangen.
In Genzsituationen ist es leider immer schierig unter allen Umständen das Richtige zu machen.
Hallo Dietmar63,
die Attribute onCmd und offCmd ändern leider nix an dem Problem - hab ich schon probiert. Und ich nutze deine RT schon seit längerer Zeit und die Probleme haben erst vor ein paar Monaten angefangen.Vorher lief eigentlich alles wie gewünscht. In der Commandref steht, dass "Standard is: "set <device> on" Aber irgendwie wird dies Command beim Start des RT nicht mehr geschickt. Ist doch eigentlich unabhängig von den genutzten devices, oder? Kannst du nicht (wieder) dafür sorgen, dass das Standard command beim Start des RT einmal gesendet wird?
Vielen Dank für deine Hilfe
oelidoc
Also das Problem ist und bleibt, dass die RT zu Beginn ihrer Laufzeit nicht oder nicht zuverlässig die entsprechenden Geräte einschalten. Und wenn man den Switchmode so eingestellt hat, dass das Licht häufiger an bleibt als aus geht, so bleibt es so lange dunkel, bis der RT einmal aus und dann wieder eingeschaltet hat. Und das ist mir für einen Einbruchschutz meist zu spät....
Hat denn keiner eine Idee woran dies Verhalten liegt bzw. wie ich es abstellen könnte?
Gruß
oelidoc (langsam verzweifelt....)
Zitat von: oelidoc am 08 Dezember 2015, 18:32:57
Also das Problem ist und bleibt, dass die RT zu Beginn ihrer Laufzeit nicht oder nicht zuverlässig die entsprechenden Geräte einschalten. Und wenn man den Switchmode so eingestellt hat, dass das Licht häufiger an bleibt als aus geht, so bleibt es so lange dunkel, bis der RT einmal aus und dann wieder eingeschaltet hat. Und das ist mir für einen Einbruchschutz meist zu spät....
Hat denn keiner eine Idee woran dies Verhalten liegt bzw. wie ich es abstellen könnte?
Gruß
oelidoc (langsam verzweifelt....)
Das ist eigentlich sogar so Absicht. Ich will nicht, dass am Startzeit Punkt irgendjemand erkennen kann, dass eine Art Agent immer zur gleichen Zeit die Lampe ein/ausschaltet. Außerdem ist intern der Algorithmus verändert worden, dass ein RT auch on the fly(presence) gestartet werden kann. Die erste Schaltung erfolgt im DefinitionsZeitraum + (secondsToSwitch+-10%)/2.
Auch auf die Gefahr hin zu nerven:
Zitat von: Dietmar63 am 09 Dezember 2015, 01:42:23
Das ist eigentlich sogar so Absicht. Ich will nicht, dass am Startzeit Punkt irgendjemand erkennen kann, dass eine Art Agent immer zur gleichen Zeit die Lampe ein/ausschaltet. Außerdem ist intern der Algorithmus verändert worden, dass ein RT auch on the fly(presence) gestartet werden kann. Die erste Schaltung erfolgt im DefinitionsZeitraum + (secondsToSwitch+-10%)/2.
Das ist soweit alles verstanden und auch o.k.
Aber: meine RT starten und gehen fälschlicherweise von "Zustand:on" aus obwohl das Device "off" ist:
2015.12.09 16:09:44 3: [zufall_wohnzimmer_abends] starting RandomTimer on Dimmer_Wohnzimmer: 16:09:44(09) - 21:32:00(09)
2015.12.09 16:09:44 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:534->
2015.12.09 16:09:44 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:09:44 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:13:44
2015.12.09 16:11:24 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 16:11:24(09) - 21:36:00(09)
2015.12.09 16:13:44 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:779->
2015.12.09 16:13:44 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:13:44 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:17:53
2015.12.09 16:17:53 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:511->
2015.12.09 16:17:53 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:17:53 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:21:52
2015.12.09 16:21:52 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:452->
2015.12.09 16:21:52 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:21:52 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:26:10
2015.12.09 16:26:10 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:239->
2015.12.09 16:26:10 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:26:10 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:30:07
2015.12.09 16:30:07 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:775->
2015.12.09 16:30:07 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:30:07 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec Das Problem steht in der zweiten Zeile: Zustand:on aber Licht ist aus! Und es bleibt entsprechend meiner 250 secondsToSwitch und einem SwitchMode von 900/50 oder auch 800/200 teilweise über 30 Minuten bis Stunden aus. Bis zum ersten zufallsbedingtem Aus- und wieder Einschalten:
2015.12.09 16:34:26 4: [zufall_wohnzimmer_abends] Zustand:on sigma:50 random:31->1
2015.12.09 16:34:26 4: [zufall_wohnzimmer_abends] command: {fhem ("set Dimmer_Wohnzimmer off")}
2015.12.09 16:34:26 3: CUL_HM set Dimmer_Wohnzimmer off
2015.12.09 16:34:26 5: [zufall_wohnzimmer_abends] removing Timer: zufall_wohnzimmer_abends_Exec
2015.12.09 16:34:26 5: [zufall_wohnzimmer_abends] setting Timer: zufall_wohnzimmer_abends_Exec 2015-12-09 16:38:37
2015.12.09 16:38:37 4: [zufall_wohnzimmer_abends] Zustand:off sigma:900 random:367->1
2015.12.09 16:38:37 4: [zufall_wohnzimmer_abends] command: {fhem ("set Dimmer_Wohnzimmer pct 70")}
2015.12.09 16:38:37 3: CUL_HM set Dimmer_Wohnzimmer pct 70Um 16:38:37 ist das Licht heute zum ersten Mal angegangen, obwohl der RT schon um 16:09:44 gestartet wurde. Erstes Licht an also nach knapp 30 Minuten. Hätten aber zufallsbedingt auch 60 oder 90 Minuten sein können. Das ist doch nicht im Sinne des Erfinders, oder?
Wo liegt bei mir "in drei Gottes Namen" der Fehler?
Gruß
oelidoc
Ich habe eine Vermutung, warum der RT bei dir dieses Verhalten zeigt. Muss ich aber leider in Test noch genauer untersuchen.
Hallo Dietmar63,
vielen Dank, dass du dich weiter um mein Problem kümmerst - wirklich toller support von Dir!
Dann wart ich mal ab, was du rausfindest. Wenn du noch mehr Angaben brauchst, sag Bescheid.
Gruß
oelidoc
Meine Überlegungen gehen in folgende Richtung:
RTs prüfen nicht wirklich den Zustand des zu schaltenden Gerätes, sondern gehen davon aus, dass nur sie allein an/abschalten. In meinem Anwendungsszenario ist das auch so ok, weil ich die RTs nur nutze, wenn ich wirklich an Wochendenden verreise. Zum Start des RT ist der Zustand "off". Danach wird je nach Einstellung ein- oder ausgeschaltet.
Problematisch wird es dann wenn jemand von Hand schaltet. Dann stimmt der intern von den RTs protokollierte Zustandswert nicht mehr und es kommt besonders bei extemen Weren von switchmode zu merkwürdigem Verhalten.
Da ich mit 800/200 fahre, wirkt sich das nicht wirklich problematisch aus, weil der RT nach einiger Zeit in Tritt kommt und sich mit dem tatsächlichen Zustand synchronisiert. Bei dir passiert das erst sehr spät.
Wenn es stimmt, habe ich dafür noch keine Lösung.
Es könnte so gehen, dass ich versuche immer den echten Zustand des zu schaltenden Geräts zu ermitteln, und nicht nur intern Protokoll zu führen. Mal sehen was meine Tests ergeben.
Hallo Dietmar 63,
um das ganze noch etwas zu komplizieren, habe ich noch weitere RT überprüft, die das von mir beobachtete Verhalten überraschender Weise nicht zeigen. Sie schalten immer morgens, wenn wir das Haus verlassen haben. Einziger für mich erkennbarer Unterschied ist, daß die TimeSpec_Stop keine Perl-Funktion ist:
Internals:
COMMAND off
DEF *{sunrise_abs(+1140,"06:44","07:29")} Dimmer_Kueche +01:50:00 300
DEVICE Dimmer_Kueche
NAME zufall_kueche_morgens
NR 140
REL
REP *
SIGMAOFF 900
SIGMAON 50
STARTTIME 13.12.2015 07:29:00
STATE disabled
STOPTIME 13.12.2015 09:19:00
SWITCHMODE 900/50
S_REL +
S_REP
TIMESPEC_START *{sunrise_abs(+1140,"06:44","07:29")}
TIMESPEC_STOP +01:50:00
TIMETOSWITCH 300
TYPE RandomTimer
active 0
startTime 1449988140
stopTime 1449994740
Timer:
Zufall_kueche_morgens_exec:
HASH zufall_kueche_morgens
MODIFIER Exec
NAME zufall_kueche_morgens_Exec
Zufall_kueche_morgens_settimer:
HASH zufall_kueche_morgens
MODIFIER SetTimer
NAME zufall_kueche_morgens_SetTimer
Attributes:
disable 1
offCmd {fhem ("set Dimmer_Kueche off")}
onCmd {fhem ("set Dimmer_Kueche on")}
room Kueche
switchmode 900/50
Das Log zu diesen RTs sieht ganz anders aus - hier wird immer sofort eingeschaltet:
2015.12.11 07:49:01 3: [zufall_kueche_morgens] starting RandomTimer on Dimmer_Kueche: 07:29:00(11) - 09:19:00(11)
2015.12.11 07:49:01 3: CUL_HM set Dimmer_Kueche on
2015.12.11 07:49:12 3: [zufall_arbeitszimmer_morgens] starting RandomTimer on Licht_Arbeitszimmer: 07:29:00(11) - 09:14:00(11)
2015.12.11 07:49:12 3: CUL_HM set Licht_Arbeitszimmer on
2015.12.11 07:49:43 3: [zufall_wohnzimmer_morgens] starting RandomTimer on Dimmer_Wohnzimmer: 07:29:00(11) - 09:19:00(11)
2015.12.11 07:49:43 3: CUL_HM set Dimmer_Wohnzimmer pct 70
2015.12.11 08:08:46 3: CUL_HM set Dimmer_Kueche off
2015.12.11 08:13:49 3: CUL_HM set Dimmer_Kueche on
2015.12.11 08:18:35 3: CUL_HM set Dimmer_Kueche off
2015.12.11 08:23:39 3: CUL_HM set Dimmer_Kueche on
2015.12.11 08:24:25 3: CUL_HM set Licht_Arbeitszimmer off
2015.12.11 08:29:14 3: CUL_HM set Licht_Arbeitszimmer on
2015.12.11 08:34:01 3: CUL_HM set Licht_Arbeitszimmer off
2015.12.11 08:39:10 3: CUL_HM set Licht_Arbeitszimmer on
2015.12.11 09:09:33 3: CUL_HM set Licht_Arbeitszimmer off
2015.12.11 09:14:24 3: [zufall_arbeitszimmer_morgens] ending RandomTimer on Licht_Arbeitszimmer: 07:29:00(11) - 09:14:00(11)
2015.12.11 09:14:24 3: CUL_HM set Licht_Arbeitszimmer off
2015.12.11 09:20:39 3: [zufall_wohnzimmer_morgens] ending RandomTimer on Dimmer_Wohnzimmer: 07:29:00(11) - 09:19:00(11)
2015.12.11 09:20:39 3: CUL_HM set Dimmer_Wohnzimmer off
2015.12.11 09:22:32 3: [zufall_kueche_morgens] ending RandomTimer on Dimmer_Kueche: 07:29:00(11) - 09:19:00(11)
2015.12.11 09:22:32 3: CUL_HM set Dimmer_Kueche off
Hier scheint unabhängig vom Zustand des Devices immer erst mal eingeschaltet zu werden.
Vielleicht kannst du ja mit diesen Zusatzinformationen was anfangen...
Gruß und einen schönen III. Advent
oelidoc
Ich habe eine Version eingecheckt, die versucht den Status des zu schaltenden Gerätes zu berücksichtigen.
@oelidoc:
Prüf mal bitte, ob damit ein großer Teil deines Problems gelöst ist. Mit verose 4 bekommt du weiteres detailiertes logging:
2015.12.14 20:49:30 4: [ZufallsTimer999050] defintion RandomTimer on StehlampeTisch: 19:55:00(14) - 20:45:00(14)
2015.12.14 20:49:30 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
2015.12.14 20:44:36 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
2015.12.14 20:39:27 3: [ZufallsTimer999050] ending RandomTimer on StehlampeTisch: 19:55:00(14) - 20:45:00(14)
2015.12.14 20:34:33 3: FS20 set StehlampeTisch off
2015.12.14 20:34:33 4: [ZufallsTimer999050] command: set StehlampeTisch off
2015.12.14 20:34:33 3: [ZufallsTimer999050] SollZustand------------>off
2015.12.14 20:34:33 4: [ZufallsTimer999050] IstZustand:on sigma-on:500 random:31->true
2015.12.14 20:34:33 3: [ZufallsTimer999050] IstZustand------------>on
2015.12.14 20:29:30 3: FS20 set StehlampeTisch on
2015.12.14 20:29:30 4: [ZufallsTimer999050] command: set StehlampeTisch on
2015.12.14 20:29:30 3: [ZufallsTimer999050] SollZustand------------>on
2015.12.14 20:29:30 4: [ZufallsTimer999050] IstZustand:off sigma-off:500 random:31->true
2015.12.14 20:29:30 3: [ZufallsTimer999050] IstZustand------------>off
2015.12.14 20:24:30 4: [ZufallsTimer999050] IstZustand:off sigma-off:500 random:680->false
2015.12.14 20:24:30 3: [ZufallsTimer999050] IstZustand------------>off
2015.12.14 20:19:44 4: [ZufallsTimer999050] IstZustand:off sigma-off:500 random:547->false
2015.12.14 20:19:44 3: [ZufallsTimer999050] IstZustand------------>off
2015.12.14 20:14:48 3: FS20 set StehlampeTisch off
2015.12.14 20:14:48 4: [ZufallsTimer999050] command: set StehlampeTisch off
2015.12.14 20:14:48 3: [ZufallsTimer999050] SollZustand------------>off
2015.12.14 20:14:48 4: [ZufallsTimer999050] IstZustand:on sigma-on:500 random:46->true
2015.12.14 20:14:48 3: [ZufallsTimer999050] IstZustand------------>on
2015.12.14 20:14:48 3: [ZufallsTimer999050] starting RandomTimer on StehlampeTisch: 19:55:00(14) - 20:45:00(14)
2015.12.14 20:09:57 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
2015.12.14 20:05:07 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
2015.12.14 20:00:11 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
2015.12.14 19:55:00 4: [ZufallsTimer999050] RandomTimer on StehlampeTisch timer disabled - no switch
Hallo Dietmar63,
vielen Dank für die neue Version. Ich habe gerade ein update fhem gemacht, einen RT auf verbose 4 gesetzt und werde jetzt mal beobachten, was passiert. Bisher sieht es schon mal sehr gut aus...
Gruß
oelidoc
Oh oh,
jetzt geht es etwas drunter und drüber: Der RT schaltet jetzt jedes mal, auch wenn das device bereits an ist:
2015.12.15 17:39:20 4: [zufall_arbeitszimmer_abends] IstZustand------------>an
2015.12.15 17:39:20 4: [zufall_arbeitszimmer_abends] IstZustand:an sigma-an:900 random:393->true
2015.12.15 17:39:20 4: [zufall_arbeitszimmer_abends] SollZustand------------>on
2015.12.15 17:39:20 4: [zufall_arbeitszimmer_abends] command: {fhem ("set Licht_Arbeitszimmer on")}
2015.12.15 17:39:20 3: CUL_HM set Licht_Arbeitszimmer on
Dafür schaltet er nicht aus, wenn er es m.E. müsste:
2015.12.15 17:44:24 4: [zufall_arbeitszimmer_abends] IstZustand------------>an
2015.12.15 17:44:24 4: [zufall_arbeitszimmer_abends] IstZustand:an sigma-an:900 random:953->false
hier kam kein Schaltbefehl mehr...
Und ein missing ack kam auch schon:
2015.12.15 17:59:17 4: [zufall_arbeitszimmer_abends] IstZustand------------>MISSING ACK
2015.12.15 17:59:17 4: [zufall_arbeitszimmer_abends] IstZustand:MISSING ACK sigma-MISSING ACK:900 random:45->true
2015.12.15 17:59:17 4: [zufall_arbeitszimmer_abends] SollZustand------------>on
2015.12.15 17:59:17 4: [zufall_arbeitszimmer_abends] command: {fhem ("set Licht_Arbeitszimmer on")}
2015.12.15 17:59:17 3: CUL_HM set Licht_Arbeitszimmer on
Ich hoffe, die Logs reichen. Wenn du Fragen hast - immer her damit.
Gruß
oelidoc
Das liegt daran, dass du dein Gerät als Value() an/aus und nicht on/off liefert. on/off sind fest verdrahtet. Im Moment habe ich keine Lösung.
Das habe ich jetzt ehrlich gesagt nicht verstanden :-[
Hier mal das device:
Readings:
2015-12-15 18:39:20 CommandAccepted yes
2014-12-17 20:58:46 D-firmware 2.2
2014-12-17 20:58:46 D-serialNr KEQ0198884
2015-08-03 21:58:47 PairedTo 0xF10804
2014-12-17 21:11:10 R-pairCentral 0xF10804
2014-12-17 21:11:11 R-sign off
2015-08-03 21:58:47 RegL_00: 02:01 0A:F1 0B:08 0C:04 15:FF 18:00 00:00
2015-08-03 21:58:48 RegL_01: 08:00 30:06 57:24 00:00
2015-12-15 18:50:25 deviceMsg on (to virtualCCU)
2015-12-15 18:50:25 level 100
2015-09-11 22:56:47 levelMissed desired:0
2015-12-15 18:50:25 pct 100
2015-08-03 21:58:45 powerOn 2015-08-03 21:58:45
2015-12-15 18:50:25 recentStateType info
2015-12-15 18:50:25 state on
2015-12-15 18:50:25 timedOn off
Lediglich bei den Attributen habe ich
subType switch
webCmd an:aus:statusRequest
Gruß
oelidoc
Ggenau
Also Attribut löschen und gut ist?
Ja, das könntest du erst mal probieren.
Und sieht es damit besser aus?
ok, wenns nicht geht ändere ich es wieder zurück.
Sooo,
das sieht sehr gut aus 8)
Das Problem sind wirklich die Zustände "on" und "off" - die HM-Dimmer z.b. geben aber statt "on" "chn:off phys:100 %" aus, was mit dem RT nicht kompatibel ist.
Ich habe es jetzt für mich so gelöst, dass ich die HM-Dimmer durch den RT auf einen bestimmten Prozentwert schalten lasse:
offCmd set Dimmer_Kueche pct 0
onCmd set Dimmer_Kueche pct 100
Und dann im dem entsprechenden Kanal des Dimmers ein eventMap setze:
Attributes:
eventMap 100:on 0:off
Damit bekomme ich mit verbose 4 ein wunderschönes Log ;D
2015.12.16 17:42:09 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 17:42:09 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:730->false
2015.12.16 17:42:59 4: [zufall_arbeitszimmer_abends] IstZustand------------>off
2015.12.16 17:42:59 4: [zufall_arbeitszimmer_abends] IstZustand:off sigma-off:800 random:315->true
2015.12.16 17:42:59 4: [zufall_arbeitszimmer_abends] SollZustand------------>on
2015.12.16 17:42:59 4: [zufall_arbeitszimmer_abends] command: {fhem ("set Licht_Arbeitszimmer on")}
2015.12.16 17:42:59 3: CUL_HM set Licht_Arbeitszimmer on
2015.12.16 17:46:27 4: [zufall_kueche_abends] IstZustand------------>on
2015.12.16 17:46:27 4: [zufall_kueche_abends] IstZustand:on sigma-on:200 random:926->false
2015.12.16 17:46:27 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 17:46:27 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:907->false
2015.12.16 17:48:10 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 17:48:10 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:429->false
2015.12.16 17:50:32 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 17:50:32 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:614->false
2015.12.16 17:51:29 4: [zufall_kueche_abends] IstZustand------------>on
2015.12.16 17:51:29 4: [zufall_kueche_abends] IstZustand:on sigma-on:200 random:543->false
2015.12.16 17:53:21 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 17:53:21 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:733->false
2015.12.16 17:54:34 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 17:54:34 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:240->false
2015.12.16 17:56:33 4: [zufall_kueche_abends] IstZustand------------>on
2015.12.16 17:56:33 4: [zufall_kueche_abends] IstZustand:on sigma-on:200 random:849->false
2015.12.16 17:58:28 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 17:58:28 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:407->false
2015.12.16 17:58:36 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 17:58:36 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:224->false
2015.12.16 18:01:30 4: [zufall_kueche_abends] IstZustand------------>on
2015.12.16 18:01:30 4: [zufall_kueche_abends] IstZustand:on sigma-on:200 random:672->false
2015.12.16 18:02:36 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 18:02:36 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:550->false
2015.12.16 18:03:18 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 18:03:18 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:790->false
2015.12.16 18:06:19 4: [zufall_kueche_abends] IstZustand------------>on
2015.12.16 18:06:19 4: [zufall_kueche_abends] IstZustand:on sigma-on:200 random:139->true
2015.12.16 18:06:19 4: [zufall_kueche_abends] SollZustand------------>off
2015.12.16 18:06:19 4: [zufall_kueche_abends] command: set Dimmer_Kueche pct 0
2015.12.16 18:06:19 3: CUL_HM set Dimmer_Kueche pct 0
2015.12.16 18:06:42 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 18:06:42 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:141->true
2015.12.16 18:06:42 4: [zufall_wohnzimmer_abends] SollZustand------------>off
2015.12.16 18:06:42 4: [zufall_wohnzimmer_abends] command: set Dimmer_Wohnzimmer pct 0
2015.12.16 18:06:42 3: CUL_HM set Dimmer_Wohnzimmer pct 0
2015.12.16 18:08:16 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 18:08:16 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:572->false
2015.12.16 18:10:53 4: [zufall_wohnzimmer_abends] IstZustand------------>off
2015.12.16 18:10:53 4: [zufall_wohnzimmer_abends] IstZustand:off sigma-off:800 random:782->true
2015.12.16 18:10:53 4: [zufall_wohnzimmer_abends] SollZustand------------>on
2015.12.16 18:10:53 4: [zufall_wohnzimmer_abends] command: set Dimmer_Wohnzimmer pct 70
2015.12.16 18:10:53 3: CUL_HM set Dimmer_Wohnzimmer pct 70
2015.12.16 18:11:17 4: [zufall_kueche_abends] IstZustand------------>off
2015.12.16 18:11:17 4: [zufall_kueche_abends] IstZustand:off sigma-off:800 random:972->false
2015.12.16 18:13:05 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 18:13:05 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:843->false
2015.12.16 18:15:10 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 18:15:10 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:357->false
2015.12.16 18:16:09 4: [zufall_kueche_abends] IstZustand------------>off
2015.12.16 18:16:09 4: [zufall_kueche_abends] IstZustand:off sigma-off:800 random:940->false
2015.12.16 18:17:59 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 18:17:59 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:973->false
2015.12.16 18:19:29 4: [zufall_wohnzimmer_abends] IstZustand------------>on
2015.12.16 18:19:29 4: [zufall_wohnzimmer_abends] IstZustand:on sigma-on:200 random:613->false
2015.12.16 18:21:07 4: [zufall_kueche_abends] IstZustand------------>off
2015.12.16 18:21:07 4: [zufall_kueche_abends] IstZustand:off sigma-off:800 random:332->true
2015.12.16 18:21:07 4: [zufall_kueche_abends] SollZustand------------>on
2015.12.16 18:21:07 4: [zufall_kueche_abends] command: set Dimmer_Kueche pct 100
2015.12.16 18:21:07 3: CUL_HM set Dimmer_Kueche pct 100
2015.12.16 18:23:06 4: [zufall_arbeitszimmer_abends] IstZustand------------>on
2015.12.16 18:23:06 4: [zufall_arbeitszimmer_abends] IstZustand:on sigma-on:200 random:75->true
2015.12.16 18:23:06 4: [zufall_arbeitszimmer_abends] SollZustand------------>off
2015.12.16 18:23:06 4: [zufall_arbeitszimmer_abends] command: set Licht_Arbeitszimmer off
2015.12.16 18:23:06 3: CUL_HM set Licht_Arbeitszimmer off
Also ich glaube dank deiner Hilfe und der neuen Version läuft bei mir jetzt alles so wie gewünscht.
Vielen Dank
Gruß
oelidoc
PS: muss tagsüber auch mal arbeiten - deswegen konnte ich nicht früher antworten...
ja und jetzt wird es kompliziert, weil wir ein Lösung bauen müssen, die nicht nur manchal geht , sonder immer.
Vorschlag?
Hallo Dietmar63,
Zitat von: Dietmar63 am 16 Dezember 2015, 22:41:56
ja und jetzt wird es kompliziert, weil wir ein Lösung bauen müssen, die nicht nur manchal geht , sonder immer.
Vorschlag?
ich verstehe nicht so ganz, was du damit meinst. Bei mir funktioniert jetzt alles wie gewünscht. Meinst du, dass jetzt andere vielleicht Probleme mit dem Modul bekommen haben?
Ich habe leider überhaupt keine Ahnung von Programmierung oder gar Perl - ich fürchte, ich kann dir da keine große Hilfe sein....
Aber natürlich probiere ich gerne was für dich aus oder teste neue Versionen.
Gruß
oelidoc
Ja genau das ist jetzt das Problem.
Bei dir funktioniert es.
Ich weiß noch nicht was ich ändern muss, damit RT mit möglichst vielen Varianten an Geräten zusammen arbeitet.
Na ja, mein Problem war ja ganz offensichtlich, dass meine Geräte nicht nur "on" und "off" lieferten. Nachdem ich meine Geräte auf "on" und "off" als Schaltzustände umgebogen habe, kann der RT ja auch wieder korrekt schalten.
Vielleicht reicht ja auch ein Hinweis in der CommandRef, dass der RT nur korrekt auf diese beiden Zustände reagiert und daher die Geräte entsprechend angepasst werden müssen.
Gruß
oelidoc
ja, habe ich mir auch schon so gedacht.
Wahrscheinlich werde ich wenn Value() etwas anderes als on/off liefert, eine FM ins Log schreiben.
Wenn dann die Probleme Überhand nehmen sollten, muss ich mir was einfallen lassen.
Eine Idee wäre, eine Funktion defineren zu können, die dann on/off liefern muss, ähnlich onCmd offCmd, und dann als Perlfunktion.
Hi Dietmar.
Erstmal ein "Dankeschön" für den RandomTimer.
Konnte mir damit sehr einfach eine nette Anwesenheitssimulation mit etlichen Abhängigkeiten bauen.
Eine Sache habe ich allerdings vermisst. Nämlich das Auslösen von Aktionen wenn der RandomTimer startet bzw. endet.
Mit den internals geht das ja leider (aus meiner Sicht) nicht. Habe mir also Readings dafür eingebaut, (Zeile 165 off,175 off, 207 on):
fhem("setreading ".$hash->{NAME}." state on");
Mit "event-on-change-reading state" kann ich mich nun z.b. per pushover über das aktivieren/deaktivieren informieren lassen.
Eventuell ist das ja auch für andere Interessant und ein Gedanke für einen RFE (request for enhancement) wert ;)
Grüße
Mike
wolltest du den Code anhängen?
Hi Dietmar.
Wusste nicht dass es erwünscht ist 8)
Hier mal ein diff,
diff 98_RandomTimer.pm 98_RandomTimerChanged.pm
164a165
> fhem("setreading ".$hash->{NAME}." state off");
173a175
> fhem("setreading ".$hash->{NAME}." state off");
200a203
> fhem("setreading ".$hash->{NAME}." state off");
und das File ist attached.
Änderungen basieren auf dem RandomTimer der mit FHEM 5.7 geliefert wird:
# head 98_RandomTimer.pm
$Id: 98_RandomTimer.pm 9334 2015-09-30 18:51:19Z dietmar63 $
So tut es was ich möchte aber eventuell gibt es aber weitere Readings zu füttern bzw. anders umzusetzen.
Ist ja auch kein "muss", sondern nur Feedback :)
Grüße
Mike
ich versuche mal zu verstehen was es genau macht und nehme es dann ggf. auf.
Hallo Dietmar,
erstmal Danke für das tolle Modul. Genau nach soetwas habe ich gesucht um es mit meiner Alarmanlage zu koppeln.
Allerdings habe ich ebenfalls das Problem dass meine Aktoren nicht "on" und "off" zurückliefern. RT schaltet also zuverlässig ein, aber nicht wieder aus.
Hast du dafür mittlerweile eine Lösung gefunden bzw. kann ich etwas tun um das Modul bei mir anzupassen?
Da ich nur Aktoren mit "Ein" und "Aus" schalten möchte müsste das doch theoretisch änderbar sein oder?
Grüße :)
Hallo,
eine Verständnissfrage zu switchmode.
Aus der Beschreibung in der commandref würde ich lesen das 800/200 bedeuten würde, das 80% der on cmd gesendet wird und zu 20% der off cmd.
-> Die Lampe bleibt tendenziell länger an?
Mit dem beigefügten screenshot meiner Konfiguration sollte also fast immer der bei on cmd hinterlegt Befehl "set@on" gesendet werden?
Danke für Aufklärung :-)
RT berücksichtigt beim Schalten immer den aktuellen Zustand.
Mit der Einstellung 640/999 wird im Zustand aus mit 64% Wahrscheinlichkeit eingeschaltet und mit 99,9% Wahrscheinlichkeit der Zustand an ausgeschaltet.
Mit verbose 5 kannst du das Verhalten loggen.
@Dietmar
Danke für die schnelle Rückantwort.
Nochmals gefragt:
"Mit der Einstellung 640/999 wird im Zustand aus mit 64% Wahrscheinlichkeit eingeschaltet der on cmd und mit 99,9% Wahrscheinlichkeit der Zustand an off cmd ausgeschaltet " ???
Mich wundert der Hinweis sigmaoff/sigmaon. Damit hätte ich es genaus andersherum verstanden.
Ich möchte etwas anschalten(64%),in diesem Fall Rollläden ein Stückrunter alle 2h, aber sie sollen definitiv danach wieder hoch, bevor sie wieder irgendwann runter gehen.
Danke für das Modul und die Arbeit
Soll heißen sigmaWennOff . Verglichen wird dann mit einer ZufallsZahl zwischen 1 und 1000
Wie schaffe ich es entweder die nächste Startzeit oder "disabled" anzeigen zu lassen, im Moment wird "disabled" oder das Lampensymbol angezeigt.
Ich habe schon mit stateFormat experimentiert, aber dann sehe ich immer die nächste "Starttime" auch wenn der RandomTimer "disabled" ist.
Niemand hat eine Idee?
Urlaub
Zitat von: Fredi69 am 27 Januar 2016, 11:24:24
Wie schaffe ich es entweder die nächste Startzeit oder "disabled" anzeigen zu lassen, im Moment wird "disabled" oder das Lampensymbol angezeigt.
Ich habe schon mit stateFormat experimentiert, aber dann sehe ich immer die nächste "Starttime" auch wenn der RandomTimer "disabled" ist.
Veröffentliche bitte mal deine Versuche mit stateFormat.
Ich glaube ich muss ein wenig mehr umbauen - und passende Readings anbieten.
Ich habe die Internals in helper und in Readings verwandelt. Ein Beispiel der Readings im Anhang.
Die Readings kannst du mit ReadingsVal() dann in stateFormat nutzen, viele Beispiele dazu im Forum.
Ich teste die Änderungen noch ein wenig und gebe dann frei.
Vielen Dank, werde es bei Gelegenheit testen.
eingecheckt:
attr ZufallsTimerBuero stateFormat {if (Value("ZufallsTimerBuero") eq "disabled") { return "disabled"} else {return substr((ReadingsVal("ZufallsTimerBuero","Startzeit","nf"),-8,8))} } ;
Ich sehe keine neuen Readings, das update meldet "nothing to do" zurück.
Was zeigt der Befehl version als Rev# für RandomTimer an?
Wenn du 10725 angezeigt bekommt bist du auf dem neuesten Stand.
Du musst fhem neu starten, dann sollte es passen.
Ich benötige nochmals Hilfe beim Verständnis.
Folgendes ist definiert:
define ZufallsTimerWohnraumIndirektTags RandomTimer 09:10:00 SU2WZLichtIndirekt *{sunset_abs()} 8400
attr ZufallsTimerWohnraumIndirektTags alias Random Wohnraum Licht Tags
attr ZufallsTimerWohnraumIndirektTags devStateIcon disabled:message_ok@red on:general_an@green off:general_aus@yellow
attr ZufallsTimerWohnraumIndirektTags disable 1
attr ZufallsTimerWohnraumIndirektTags offCmd set @ on-for-timer 416
attr ZufallsTimerWohnraumIndirektTags onCmd set @ on-for-timer 832
attr ZufallsTimerWohnraumIndirektTags room Alarmanlage
attr ZufallsTimerWohnraumIndirektTags switchmode 500/700
Es passiert dann folgendes, obwohl ich in diesem Fall vor sunset schon den Zufallstimer disable 1 gestellt habe, weil ich nach Haus kam.
2016.02.07 20:13:18 3: [ZufallsTimerWohnraumIndirektTags] ending RandomTimer on SU2WZLichtIndirekt: 09:10:00(07) - 18:05:31(07)
2016.02.07 20:13:18 3: [ZufallsTimerWohnraumIndirektTags] ending RandomTimer on SU2WZLichtIndirekt: 09:10:00(07) - 18:05:31(07)
2016.02.07 20:13:18 3: FS20 set SU2WZLichtIndirekt on-for-timer 416
Kann es sein das er obwohl schon nicht mehr aktiv sein sollte, noch innerhalb der 8400 Sekunden als Abschluss den off-cmd sendet?
Wie kann ich das verhindern?
Grüße
ja, vermutlich passiert genau das, was du vermutest.
Das liegt aber an dem langen Intervall(8400) zwischen den potenziellen switches.
Es wird geschaltet, weil $stopTimeReached nach 2 Stunden true ist.
Im Normalfall soll es so laufen.
Wenn während der aktiven Zeit disabled verändert wird, reagiert RT passend darauf. Wenn natürlich $stopTimeReached true ist wird so ausgeschaltet als wäre die RT normal beendet worden.
folgende Definition verstehe ich nicht wirklich:
define ZufallsTimerWohnraumIndirektTags RandomTimer 09:10:00 SU2WZLichtIndirekt *{sunset_abs()} 8400
attr ZufallsTimerWohnraumIndirektTags switchmode 500/700
Von morgens bis Abends wird alle zwei Stunden+ entschieden, ob mit 50% Wahrscheinlichkeit an bzw. mit 70% ausgeschaltet wird. Was willst du damit erreichen?
Hallo Dietmar,
da ich tagsüber nur kurze Zeitschalten haben wollte, beispielsweise auch im Gästebad einfach für 1 oder 2 Minuten an, habe ich folgendes definiert:
beim oncmd on for timer 60
beim offcmd on for timer 120
somit sollte mal kurz, mal länger was eingeschaltet sein. 500/700 um zu varieren, das ist aber willkürlich.
Folgendes Problem habe ich auch: Es wird nicht off geschaltet.
Insbesondere habe ich eine Rollladensteuerung die bei oncmd die Rollläden für ein Stück runter fährt. Hierfür brauche ich off-for-timer 6, schalten lassen wollte ich zu 70%
Nun sollen sie wieder rauf zu 99% mit dem offcmd on (oder on-for-timer 20), aber eben nicht die Gefahr das sie andersherum immer weiter runterfahren.
Auch hier das Problem, sie fahren nicht hoch, er sendet offcmd anscheinend nie.
Lieg es daran das das Modul versucht den zustand zu berücksichtigen? Ich bräuchte eher ein "dummes" Modul, er sol einfach schalten ohne sich zu überlegen wie der gemeldete Zustand sein könnte.
Grüße und danke schonmal
Für solche Sachen ist RT nicht gebaut.
Er soll in erster Linie in der Dämmerung ein zufälliges ein- und ausschalten gewährleisten und ggf. Einbrecher eine Anwesenheit vortäuschen.
Nachvollziehbar, aber:
Heisst es er schaut wie der Zustand des angesprochenen Aktors ist? und schaltet nur off, wenn der auch auf on steht?
Lösung wäre dann doch ein Dummy per RT zuschalten, mit on/off, und dahinter ein notify der es zu on-for-timer etc übersetzt?
'n Abend!
Aus der Referenz, Beispiel für disableCond:
attr ZufallsTimerZ disableCond (Value("presenceDummy") ne "present"))
Ist da nicht eine schließende Klammer zu viel?
Viel Gruß!
Zitat
Heisst es er schaut wie der Zustand des angesprochenen Aktors ist? und schaltet nur off, wenn der auch auf on steht?
Ja
Hallo zusammen
Entschuldigt meine banale Frage aber ich bin seit 1 1/2 Tagen am versuchen, komme nicht weiter und bin langsam am verzweifeln.
Ich würde gerne mittels RandomTimer einen Aktor (UP_Schalter_18) steuern. Zuvor jedoch sollte abgefragt werden ob eine Lampe an ist oder aus. Dies erhalte ich mittels Sensor (Schalterinterface_11).
Der Grund ist dass ich eine Kreuzschaltung ansteuere bei der nicht unbedingt on Licht an bedeutet.
Funktionieren tut das ganze allerdings nur wenn Aktor und Sensor gleich geschaltet sind (Aktor --> on, Sensor --> on). Ich vermute dass ich irgendwie bei den if-Abfragen ein durcheinander habe.
Anbei die Definitionen (Versuchsschaltung daher die 30 Sekunden Wechsel):
define ZufallsTimer_06 RandomTimer *09:00:00 UP_Schalter_18 01:37 30
attr ZufallsTimer_06 disableCond (Value("var_Verreist") ne "on")
attr ZufallsTimer_06 switchmode 999/999
attr ZufallsTimer_06 offCmd {if (Value("Schalterinterface_11") eq "on" ) {if(Value("UP_Schalter_18") eq "off" ) {fhem("set UP_Schalter_18 on" )} else {fhem("set UP_Schalter_18 off" )} } }
attr ZufallsTimer_06 onCmd {if (Value("Schalterinterface_11") eq "off" ) {if(Value("UP_Schalter_18") eq "off" ) {fhem("set UP_Schalter_18 on" )} else {fhem("set UP_Schalter_18 off" )} } }
Vielen Dank für eure Unterstützung
Guten Tag zusammen
Der Leitsatz "Zuwarten ... es wird schon irgendwann klappen" hat funktioniert.
Habe den Fehler gefunden:
In der Definition ist anstatt UP_Schalter_18 der Sensor Schalterinterface_11 zu setzen.
Nun klappt es einwandfrei.
Anbei der funktionierende Code für die interessierte:
define ZufallsTimer_06 RandomTimer *01:00:00 Schalterinterface_11 01:37:00 30
attr ZufallsTimer_06 disableCond (Value("var_Verreist") ne "on")
attr ZufallsTimer_06 switchmode 999/999
attr ZufallsTimer_06 offCmd {if (Value("Schalterinterface_11") eq "on" ) {if(Value("UP_Schalter_18") eq "off" ) {fhem("set UP_Schalter_18 on" )} else {fhem("set UP_Schalter_18 off" )} } }
attr ZufallsTimer_06 onCmd {if (Value("Schalterinterface_11") eq "off" ) {if(Value("UP_Schalter_18") eq "off" ) {fhem("set UP_Schalter_18 on" )} else {fhem("set UP_Schalter_18 off" )} } }
Grüsse
Wenn ich dieses Modul richtig verstehe, kann ich hiermit nur Geräte schalten, die auf on/off reagieren, oder?
Ist es wohl auch möglich hiermit eine Lightscene zu schalten?
Ich müsste zu einer zufälligen Zeit abends einmal
set Beleuchtung scene TVsimulation
und ein paar stunden später dann
set Beleuchtung scene Standby
ausführen.
hat jemand eine Idee wie ich das hiermit umsetzen könnte?
Hallo LeoSum
Versuche mal diese Testschaltung.
# ****************** Testschaltungen ******************
define var_Alarmlampe_01 dummy
attr var_Alarmlampe_01 room AlarmStatus
attr var_Alarmlampe_01 webCmd on:off
attr var_Alarmlampe_01 group Testschaltung
define var_Alarmlampe_02 dummy
attr var_Alarmlampe_02 room AlarmStatus
attr var_Alarmlampe_02 webCmd on:off
attr var_Alarmlampe_02 group Testschaltung
# ------------------ Szene Treppenaufgang ------------------
define ZufallsTimer_xx RandomTimer *05:00:00 var_Alarmlampe_01 01:00:00 10
attr ZufallsTimer_xx switchmode 800/900
# onCmd --> Befehl, der als Einschaltbefehl verwendet werden soll
attr ZufallsTimer_xx onCmd {fhem("set var_Alarmlampe_01 on;; \
define delay_xx.1 at +00:00:03 set var_Alarmlampe_02 on")}
# offCmd --> Befehl, der als Ausschaltbefehl verwendet werden soll
attr ZufallsTimer_xx offCmd {fhem("set var_Alarmlampe_02 off;; \
define delay_xx.2 at +00:00:03 set var_Alarmlampe_01 off")}
In den Attributen onCmd und OffCmd solltest du deine Codierung einpacken können.
Zitat von: LeoSum am 06 März 2016, 20:15:11
Wenn ich dieses Modul richtig verstehe, kann ich hiermit nur Geräte schalten, die auf on/off reagieren, oder?
Ist es wohl auch möglich hiermit eine Lightscene zu schalten?
Ich müsste zu einer zufälligen Zeit abends einmal
set Beleuchtung scene TVsimulation
und ein paar stunden später dann
set Beleuchtung scene Standby
ausführen.
hat jemand eine Idee wie ich das hiermit umsetzen könnte?
Dafür ist das Modul nicht konstruiert. Es versucht je nach Einstellung ein- auszuschalten. Dazu muss der state des Geräts zu on/off evaluieren, weil der echte Zustand abgefragt wird.
Danke für eure Vorschläge, aber ich habe es nun anders gelöst. Mit der Funktion von hier http://carsten.familie-schumann.info/blog/2015/01/fhem-zufaellige-zeit-offsets/ (http://carsten.familie-schumann.info/blog/2015/01/fhem-zufaellige-zeit-offsets/) habe ich folgendes in FHEM definiert:
define AbwesenheitssimTV at *{time_random_offset(sunset(0,"18:00","21:00"),600)} { if (Value("Bewohner") eq "gone"||Value("Bewohner") eq "absent") { fhem("set Beleuchtung scene TVsimulation") }}
define AbwesenheitssimTVoff at *{time_random_offset("22:45:00",600)} { if (Value("Bewohner") eq "gone"||Value("Bewohner") eq "absent") { fhem("set Beleuchtung scene Standby") }}
Hallo Dietmar,
bekomme bei mir im Log:
Smartmatch is experimental at ./FHEM/98_RandomTimer.pm line 262, <$fh> line 1205.
das würde dafür Abhilfe schaffen:
no if $] >= 5.017011, warnings => 'experimental::smartmatch';
Grüße
Klaus
Ich verstehe nicht was du mir damit sagen willst.
Bin eh im Moment im Urlaub und kann nichts machen.
ist ja auch nicht dringend, die Funktion ist nicht beeinträchtigt
Die Smartmatch Funktion, die im Modul verwendet wird, verursacht bei neueren Perl Versionen eine Warnung im Log.
Ich bin da sicher nicht der Einzige. Bei mit kommt die Meldung auf dem Pi seit der Aktualisierung auf Debian Jessie.
Die Zeile, die ich dir geschickt habe würde die Warnung unterdrücken.
Ok, kümmere mich nach meinem Urlaub
habe ich eingebaut, gebe ich in bald frei.
Zitat von: Dietmar63 am 03 April 2016, 10:20:08
habe ich eingebaut, gebe ich in bald frei.
Daumen hoch :)
eingecheckt
Hallo Dietmar
Mensch was hab ich mich schwergetan mit der DisableCondition und dem Versuch die Variable $we zu nutzen.
Mit dem Holiday Kalender gehts, ohne groß Subs zu programmieren.
disableCond (Value("Ferien") eq "Urlaub")
Den halben Thread bis 154 habe ich gelesen. In der Command-Reference ist noch ein kleiner Fehler
attr ZufallsTimerZ disableCond (Value("presenceDummy") ne "present"))
Die letzte Klammer ist zuviel.
Tolles Modul!
Gruß Ralf
Hallo Dietmar63,
ich muss da noch mal nachhaken wegen der vom Device gelieferten States on/off oder Ein/AUS oder was auch immer. Wie du schreibst sind on/off fest verdrahtet, ansonsten funktioniert der RT nicht. Seit einiger Zeit wird ja auch eine Fehlermeldung generiert. Das war aber sicher nicht immer so denn meine RTs haben sehr lange auch mit anderen Schaltzuständen zuverlässig gearbeitet.
Was auch immer sich geändert hat, ist es evtl. möglich dem RT den abzufragenden Schaltzustand vorzugeben, meinetwegen als Attribut o.ä. das würde vieles vereinfachen denn ansonsten muss man sich immer irgendwelche Krücken bauen.
Gruss, Jo
Ich verwende RandomTimer für die Anwesenheitssimulation mit Licht. Die Lichter sollen natürlich erst dann angehen wenn es auch wirklich dämmert. Um den richtigen Zeitpunkt zu ermitteln habe ich mich das Modul twiligh entschieden. Ich erhoffe mir damit auch an sehr düsteren Tagen einen passenden Wert zu erhalten.
Wie habt ihr dies gelöst? Ich habe trotz ausgiebiger Suche kein passendes Beispiel gefunden.
Ich habe es mal so probiert.
define RT_LichWohnzimmer RandomTimer *{twilight("myTwilight","ss_weather","17:00","22:00")} LichWohnzimmer 22:40:00 400
Die Werte/Redings von twilight werden ja sporadisch nachgeführt (ist jemandem bekannt wann bzw. nach welchem Muster diese Updates erfolgen?)
Nun denke ich mal, dass der RandomTimer diese nachgefügten Wert nicht mitbekommt, und meine Definition ihren Zweck (Wetterabhängige Einschaltzeig) gar nicht erfüllt. Ich glaube aber kaum, dass ich der einzige mit dieser Idee bin. Doch wo kann ich ein entsprechendes Beispiel finden?
Ich habe einen RandomTimer wieder in Betrieb genommen, der im letzten Jahr noch problemlos lief.
Jetzt erhalte ich eine Fehlermeldung.
2016.08.09 20:05:04 3: [ZufallsTimer_1] result of function Value(HueDevice1) must be 'on' or 'off'
Was ist jetzt falsch?
definition? + device definition
Zitat von: Dietmar63 am 10 August 2016, 14:12:31
definition? + device definition
define ZufallsTimer_HUEDevice2 RandomTimer *{sunset_abs()} HUEDevice2 *{sunrise()} 30define HUEDevice2 HUEDevice 2 IODev=HUEBridge01
Vor längerer Zeit wurde die Funktion von RT so geändert, dass der Zustand des zu schaltenden device mit Value() abgefragt wird und dann on or off geschaltet wird. Die Änderung war deshalb sinnvoll, weil teilweise das Abschalten nicht vernünftig funktioniert hatte.
Bei Geräten wie HUEs passt das natürlich nicht wirklich. Du bist aber auch der erste, der eine weitere Verbesserung benötigt. Kannst du mal prüfen was die Funktion {Value("HueDevice1")} an Ergebnissen im Zustand an/aus liefert. Hast du onCmd/offCmd angegeben.
set hue on
set hue off
funktioniert vielleicht nicht.
im zustand off liefert Value normalerweise off. wenn die lampe an ist liefert Value die fs20 dim stufen dim06% bis dim93% oder on.
da das hue icon normalerweise nicht von STATE abhängt sondern intern berechnet wird kannst du STATE per stateFormat auf etwas passenderes undefinieren.
{ReadingsVal($name,'onoff',0)?'on':'off'}
sollte funktionieren.
gruss
andre
Zitat von: Dietmar63 am 11 August 2016, 21:08:56
Vor längerer Zeit wurde die Funktion von RT so geändert, dass der Zustand des zu schaltenden device mit Value() abgefragt wird und dann on or off geschaltet wird. Die Änderung war deshalb sinnvoll, weil teilweise das Abschalten nicht vernünftig funktioniert hatte.
Bei Geräten wie HUEs passt das natürlich nicht wirklich. Du bist aber auch der erste, der eine weitere Verbesserung benötigt. Kannst du mal prüfen was die Funktion {Value("HueDevice1")} an Ergebnissen im Zustand an/aus liefert. Hast du onCmd/offCmd angegeben.
set hue on
set hue off
funktioniert vielleicht nicht.
Danke, ich habe keine onCmd, offCmd gesetzt.
Sollte ich das tun?
Wenn ja, wie?
Mit onCmd offCmd kann man das Kommando, das RT sendet selbst bestimmen. Normalerweise wird Set device on/off gesendet. Wenn du es bisher nicht machst, kann das so bleiben.
Das was justme geschrieben hat sollte funktionieren.
Zitat von: Dietmar63 am 12 August 2016, 01:31:13
Mit onCmd offCmd kann man das Kommando, das RT sendet selbst bestimmen. Normalerweise wird Set device on/off gesendet. Wenn du es bisher nicht machst, kann das so bleiben.
Das was justme geschrieben hat sollte funktionieren.
Ich verstehe denn Beitrag von justme nicht, sorry.
Was sollte ich wo ändern?
Danke
Such mal In der comnandref nach
stateFormat
Und ergänze zum zu schaltenden device
Eine entsprechende Zeile mit dem perlCode von justme
Dann sollte es mit dem RT ohne fm funktionieren
Danke, scheint zu funktionieren.
Zwei kleine Fragen, z.Zt. nutze ich den randomtimer mit einem Zwischenstecker um eine Lampe ein und auszuschalten. Ist es möglich den so einzustellen, dass die on Phasen länger als die off Phasen sind oder macht der Randomtimer das jetzt schon?
Ich möchte jetzt noch an einem 2. Zwischenstecker einen TV Simulator hängen. Da ist es eher doof wenn der immer wieder an und aus geht. Ich möchte hier nur ein zufälliges einschalten innerhalb einer Zeitspanne A (vielleicht immer die Stunde vor Sonnenuntergang, aber nie vor 18h) und ein zufälliges ausschalten innerhalb einer Zeitspanne B (z. B. von 23 - 1h) haben, ist dies irgendwie möglich?
Du kannst mit dem Attribut switchmode versuchen dieses Verhalten nachzubilden
Mit den beiden Parametern bestimmst du die Wahrscheinlichkeit ob nach N Sekunden wirklich ein bzw. Ausgeschaltet wird
danke für die schnelle antwort, meine 2. Frage wird ja erst eine seite vorne dran beantwort, bei antwort 364-367, habe ich erst beim rückwärt lesen bemerkt :s
ich habe den switchmode so verstanden, dass z.B 800/200 nach frühstens 200 sekunden schaltet und spätestens nach 800 sekunden. was er aber dabei schaltet ist halt zufall. demnach könnte er z.b. nach 200 sek schon wieder ausschalten und erst nach 800 sekunden wieder einschalten, was eine länger ausphase als einphase bedeutet.
eventuell könnte man ein SwitchmodeOn (2000/1000) und ein SwitchmodeOff (700/300) einbauen oder verstehe ich das gerade falsch?
vielleicht reicht auch nur ein SwitchmodeOn und Switchmode. Ist nix eingestellt, gilt Switchmode für beides und ist standard auf 800/200 eingestellt. Ist SwitchmodeOn eingestellt, gilt Switchmode automatisch nur fürs ausschalten. sind nur als idee gemeint.....
ach ja, danke überhaupt für dieses tolle modul.
Zitat von: sasquuatch am 13 August 2016, 09:26:16
Zwei kleine Fragen, z.Zt. nutze ich den randomtimer mit einem Zwischenstecker um eine Lampe ein und auszuschalten. Ist es möglich den so einzustellen, dass die on Phasen länger als die off Phasen sind oder macht der Randomtimer das jetzt schon?
Ich möchte jetzt noch an einem 2. Zwischenstecker einen TV Simulator hängen. Da ist es eher doof wenn der immer wieder an und aus geht. Ich möchte hier nur ein zufälliges einschalten innerhalb einer Zeitspanne A (vielleicht immer die Stunde vor Sonnenuntergang, aber nie vor 18h) und ein zufälliges ausschalten innerhalb einer Zeitspanne B (z. B. von 23 - 1h) haben, ist dies irgendwie möglich?
Genau für diesen Anwendungsfall habe ich den Switchmode auf 950/100 eingestellt.
Zitat von: Fredi69 am 13 August 2016, 10:19:48
Genau für diesen Anwendungsfall habe ich den Switchmode auf 950/100 eingestellt.
demnach stehen die 950 sekunden für die Zeit innerhalb der das Device ausgeschaltet wird und die 100 sekunden innerhalb der das device eingeschaltet wird?
dann wäre ein SwitchmodeOn überflüssig....
Zitat von: sasquuatch am 13 August 2016, 12:07:47
demnach stehen die 950 sekunden für die Zeit innerhalb der das Device ausgeschaltet wird und die 100 sekunden innerhalb der das device eingeschaltet wird?
dann wäre ein SwitchmodeOn überflüssig....
Der Switchmode hat nichts mit Sekunden zu tun, es ist eine Wahrscheinlichkeit. Mit dem Parameter 950 ist die Wahrscheinlichkeit sehr hoch, dass das Gerät durch den RT eingeschaltet wird wenn es aus ist. Mit dem Parameter 100 ist die Wahrscheinlichkeit sehr gering, dass das Gerät durch den RT ausgeschaltet wird wenn es an ist.
Aus der Doku:
Setting the switchmode you can influence the behavior of switching on/off. The parameter has the Format 999/999 and the default ist 800/200. The values are in "per mill". The first parameter sets the value of the probability that the device will be switched on when the device is off. The second parameter sets the value of the probability that the device will be switched off when the device is off.
Genau
Warum erzeugt ein RandomTimer zwischen Start- und Stoppzeit dauernd Events, obwohl der RandomTimer State auf disabled steht?
Weil das ganze so gebaut ist, dass unabhängig von enable/disable der Zufallsgenerator läuft, aber bei disable das Gerät nicht geschaltet wird. Du kannst so durch Presence den enable/disable Status des RT verändern und RT regiert korrekt. Man hätte so etwas vielleicht noch durch notify lösen können, aber wäre vermutlich sehr fehleranfällig gewesen.
Welche Events stören? Vielleicht kann ich sie unterbinden.
Zitat von: Dietmar63 am 06 Oktober 2016, 06:58:36
Welche Events stören? Vielleicht kann ich sie unterbinden.
2016-10-06 21:32:55 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:32:55 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:32:55 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:32:57 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:32:57 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:32:57 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:14 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:33:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:16 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:16 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:33:16 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:34 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:34 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:33:34 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:37 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:37 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:33:37 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:54 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:54 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:33:54 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:33:57 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:33:57 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:33:57 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:14 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:34:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:17 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:17 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:34:17 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:34 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:35 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:34:35 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:36 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:36 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:34:36 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:54 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:54 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:34:54 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:34:56 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:34:56 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-06 21:34:56 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-06 21:35:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-06 21:35:14 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-06 21:35:14 RandomTimer ZufallsTimer_HUEDevice2 disabled
Hallo zusammen,
ich habe folgendes Problem: Ich möchte mithilfe eines Dummys (State: on/ off) den disableCond Schalten, nur hat dieser keine Auswirkungen. Hier mein Code:
# Anwesenheitssimulation Allgemein definieren
define anwesend_SIM dummy
attr anwesend_SIM room System
attr anwesend_SIM webCmd on:off
# Anwesenheitssimulation Draußen definieren
define Laterne_RND RandomTimer *{sunset_abs()} Laterne *{sunset_abs(2*3600)} 480
attr Laterne_RND disableCond (!anwesend_SIM())
Hat jemand eine Idee was falsch ist?
Wird schon besser.
Wenn es komplett klappt, checke ich es ein.
2016.10.07 22:21:12 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 22:12:52 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 22:04:31 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:56:01 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:47:31 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:39:27 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:31:01 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:22:39 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:14:32 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:05:50 3: Nachricht von ZufallsTimerTv: disabled
2016.10.07 21:05:50 3: Nachricht von ZufallsTimerTv: active: 0
2016.10.07 21:05:50 3: Nachricht von ZufallsTimerTv: disabled
Zitat von: stebar_ am 06 Oktober 2016, 22:09:38
Hallo zusammen,
ich habe folgendes Problem: Ich möchte mithilfe eines Dummys (State: on/ off) den disableCond Schalten, nur hat dieser keine Auswirkungen. Hier mein Code:
# Anwesenheitssimulation Allgemein definieren
define anwesend_SIM dummy
attr anwesend_SIM room System
attr anwesend_SIM webCmd on:off
# Anwesenheitssimulation Draußen definieren
define Laterne_RND RandomTimer *{sunset_abs()} Laterne *{sunset_abs(2*3600)} 480
attr Laterne_RND disableCond (!anwesend_SIM())
Hat jemand eine Idee was falsch ist?
schalte mal verbose 5, dann kommst du vielleicht schon sebst dahinter.
Zitat von: Dietmar63 am 07 Oktober 2016, 22:29:09
schalte mal verbose 5, dann kommst du vielleicht schon sebst dahinter.
Danke für den Tipp, was ich gesehen habe ist, dass der dummy sauber ein und aus schaltet, es aber keine Auswirkungen auf dem RND Timer hat. Noch einen Tipp?
Ich meine verbose auf Laterne_RND
Zitat von: Dietmar63 am 07 Oktober 2016, 23:55:02
Ich meine verbose auf Laterne_RND
Im log steht, Undefined subroutine und EVALUATING beim disableCond
Die Funktion anwesend_SIM() muss in 99_utils eingebaut sein.
99_utils mit reload neu laden oder einen shutdown restart ausführen.
reload ist der schnellere Weg.
Hi Dietmar.
Ich habe ein ähnliches Problem wie Fredi, nur andersrum :)
Mein RT zeigt in den Readings:
Startzeit 2016-10-12 16:00:44
Stoppzeit 2016-10-12 21:00:44
Was meiner definition nach völlig korrekt ist.
Trotzdem bekomme ich um 00:10 Uhr Events mit "state off".
Zu diesem Zeitpunkt wurde die disableCond Funktion aufgerufen (mit return 1), die schreibt mir aktuell selber ins Log.
Also hätte der RT geschaltet wenn die Uhrzeit zwischen Start und Stop gewesen wäre.
Er hat sich zwar prinzipiell Korrekt verhalten aber warum generiert er Events obwohl er per "Schedule" disabled sein sollte?
Gibt es einen Grund warum der STATE nicht auch "disabled" ist wenn die Uhrzeit nicht passt?
grüße
mike
Ich möchte nochmals fragen warum die RT's die disabeld sind alle 10s mehrere Events abschießen?
Ist es möglich das zu unterbinden?
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 disabled
Vielen Dank für die Unterstützung
Ich habe leider auch wieder ein kleines Problemchen:
Meine RandomTimer (rand_lampe1, rand_lampe2, rand_lampe3) schalten die Lampen nicht mehr aus. Das Attribut "keepDeviceAlive" ist nicht gesetzt.
2016-11-10_13:16:18
alle RandomTimer werden systemgesteuert "disabled"
Minuten später erscheint folgendes im FHEM-Log:
2016.11.10 13:26:47 3: [rand_lampe3] ending RandomTimer on stru_lampe_3: 08:00:00(10) - 23:59:00(10)
2016.11.10 13:27:36 3: [rand_lampe2] ending RandomTimer on stru_lampe_2: 08:00:00(10) - 23:59:00(10)
2016.11.10 13:28:19 3: [rand_lampe1] ending RandomTimer on stru_lampe_1: 08:00:00(10) - 23:59:00(10)
Die Lampen (hinten den Structures) bleiben aber leider an.
list rand_lampe1
Internals:
COMMAND on
DEF *08:00 stru_lampe_1 23:59 1800
DEVICE stru_lampe_1
NAME rand_lampe1
NR 277
STATE disabled
TYPE RandomTimer
Readings:
2016-11-10 00:30:30 Startzeit 2016-11-10 08:00:00
2016-11-10 00:30:30 Stoppzeit 2016-11-10 23:59:00
2016-11-09 09:57:06 TimeToSwitch 1800
2016-11-10 13:56:50 active 0
2016-11-10 13:56:50 state disabled
Timer:
Rand_lampe1_exec:
HASH rand_lampe1
MODIFIER Exec
NAME rand_lampe1_Exec
Rand_lampe1_settimer:
HASH rand_lampe1
MODIFIER SetTimer
NAME rand_lampe1_SetTimer
Helper:
REL
REP *
SIGMAWHENOFF 500
SIGMAWHENON 500
STARTTIME 10.11.2016 08:00:00
STOPTIME 10.11.2016 23:59:00
SWITCHMODE 500/500
S_REL
S_REP
TIMESPEC_START *08:00
TIMESPEC_STOP 23:59
TIMETOSWITCH 1800
active 0
startTime 1478761200
stopTime 1478818740
Attributes:
disable 1
switchmode 500/500
Kann mir jemand damit helfen? Danke.
Zitat von: Fredi69 am 26 Oktober 2016, 18:55:50
Ich möchte nochmals fragen warum die RT's die disabeld sind alle 10s mehrere Events abschießen?
Ist es möglich das zu unterbinden?
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:06 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:14 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:25 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:34 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:49:45 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:49:53 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 active: 0
2016-10-26 18:50:05 RandomTimer ZufallsTimer_HUEDevice2 disabled
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 disabled
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 active: 0
2016-10-26 18:50:13 RandomTimer ZufallsTimer_HUEDevice3 disabled
Vielen Dank für die Unterstützung
wie hast du sie definiert?
Zitat von: FunkOdyssey am 10 November 2016, 14:19:16
Ich habe leider auch wieder ein kleines Problemchen:
Meine RandomTimer (rand_lampe1, rand_lampe2, rand_lampe3) schalten die Lampen nicht mehr aus. Das Attribut "keepDeviceAlive" ist nicht gesetzt.
2016-11-10_13:16:18
alle RandomTimer werden systemgesteuert "disabled"
Minuten später erscheint folgendes im FHEM-Log:
2016.11.10 13:26:47 3: [rand_lampe3] ending RandomTimer on stru_lampe_3: 08:00:00(10) - 23:59:00(10)
2016.11.10 13:27:36 3: [rand_lampe2] ending RandomTimer on stru_lampe_2: 08:00:00(10) - 23:59:00(10)
2016.11.10 13:28:19 3: [rand_lampe1] ending RandomTimer on stru_lampe_1: 08:00:00(10) - 23:59:00(10)
Die Lampen (hinten den Structures) bleiben aber leider an.
list rand_lampe1
Internals:
COMMAND on
DEF *08:00 stru_lampe_1 23:59 1800
DEVICE stru_lampe_1
NAME rand_lampe1
NR 277
STATE disabled
TYPE RandomTimer
Readings:
2016-11-10 00:30:30 Startzeit 2016-11-10 08:00:00
2016-11-10 00:30:30 Stoppzeit 2016-11-10 23:59:00
2016-11-09 09:57:06 TimeToSwitch 1800
2016-11-10 13:56:50 active 0
2016-11-10 13:56:50 state disabled
Timer:
Rand_lampe1_exec:
HASH rand_lampe1
MODIFIER Exec
NAME rand_lampe1_Exec
Rand_lampe1_settimer:
HASH rand_lampe1
MODIFIER SetTimer
NAME rand_lampe1_SetTimer
Helper:
REL
REP *
SIGMAWHENOFF 500
SIGMAWHENON 500
STARTTIME 10.11.2016 08:00:00
STOPTIME 10.11.2016 23:59:00
SWITCHMODE 500/500
S_REL
S_REP
TIMESPEC_START *08:00
TIMESPEC_STOP 23:59
TIMETOSWITCH 1800
active 0
startTime 1478761200
stopTime 1478818740
Attributes:
disable 1
switchmode 500/500
Kann mir jemand damit helfen? Danke.
bitte mal die Definition veröffentlichen und den output posten, der mit verbose 5 herauskommt
Die Definition war im vorherigen Post bereits enthalten.
Bis zum Verbose5-Log muss ich noch ein wenig warten.
Bis dahin könnte ich dir ein Verbose3-Log anbieten:
2016-11-10_08:00:00 rand_lampe1 disabled
2016-11-10_08:00:00 rand_lampe1 active: 0
2016-11-10_08:00:00 rand_lampe1 disabled
2016-11-10_08:28:41 rand_lampe1 disabled
2016-11-10_08:28:41 rand_lampe1 active: 0
2016-11-10_08:28:41 rand_lampe1 disabled
2016-11-10_08:51:46 rand_lampe1 disabled
2016-11-10_08:56:57 rand_lampe1 off
2016-11-10_08:57:47 rand_lampe1 active: 1
2016-11-10_08:57:47 rand_lampe1 on
2016-11-10_09:27:47 rand_lampe1 on
2016-11-10_09:57:53 rand_lampe1 on
2016-11-10_10:26:35 rand_lampe1 on
2016-11-10_10:57:09 rand_lampe1 on
2016-11-10_11:28:09 rand_lampe1 on
2016-11-10_11:57:58 rand_lampe1 on
2016-11-10_12:28:02 rand_lampe1 on
2016-11-10_12:58:10 rand_lampe1 on
2016-11-10_13:16:19 rand_lampe1 disabled
2016-11-10_13:28:19 rand_lampe1 disabled
2016-11-10_13:28:19 rand_lampe1 active: 0
2016-11-10_13:28:19 rand_lampe1 disabled
2016-11-10_13:56:50 rand_lampe1 disabled
2016-11-10_13:56:50 rand_lampe1 active: 0
2016-11-10_13:56:50 rand_lampe1 disabled
2016-11-10_14:25:29 rand_lampe1 disabled
2016-11-10_14:25:29 rand_lampe1 active: 0
2016-11-10_14:25:29 rand_lampe1 disabled
2016-11-10_14:55:20 rand_lampe1 disabled
2016-11-10_14:55:20 rand_lampe1 active: 0
2016-11-10_14:55:21 rand_lampe1 disabled
2016-11-10_15:15:33 rand_lampe1 off
2016-11-10_15:24:40 rand_lampe1 active: 1
2016-11-10_15:24:40 rand_lampe1 on
Am Rande: Das Modul wird "ferngesteuert" disabled. Ein DOIF schaltet das RT ein, sobald es dunkel wird. Das ist in Wirklichkeit ein wenig komplexer, daher konnte ich nicht disabeCond nehmen.
Zitat von: Dietmar63 am 10 November 2016, 15:15:56
wie hast du sie definiert?
define ZufallsTimer_HUEDevice3 RandomTimer *{sunset_abs()} HUEDevice3 *{sunrise()} 20
Zitat von: Dietmar63 am 10 November 2016, 15:15:56
Ich möchte nochmals fragen warum die RT's die disabeld sind alle 10s mehrere Events abschießen?
Ist es möglich das zu unterbinden?
habe ein Version eingecheckt, die das Problem lösen sollten
Zitat von: Dietmar63 am 08 Oktober 2016, 14:06:27
Die Funktion anwesend_SIM() muss in 99_utils eingebaut sein.
99_utils mit reload neu laden oder einen shutdown restart ausführen.
reload ist der schnellere Weg.
Ich glaube wir meinen etwas anderes. Ich habe einen Dummy definiert, den ich per "Hand" ein und aus schalten kann. Es gibt keine Funktion, daher klappt es mit den 99_utils auch nicht. Noch weitere Ideen? :-)
Zitat von: Dietmar63 am 12 November 2016, 20:33:39
habe ein Version eingecheckt, die das Problem lösen sollten
Danke, die Events sind weg.
Zitat von: stebar_ am 13 November 2016, 19:24:53
Ich glaube wir meinen etwas anderes. Ich habe einen Dummy definiert, den ich per "Hand" ein und aus schalten kann. Es gibt keine Funktion, daher klappt es mit den 99_utils auch nicht. Noch weitere Ideen? :-)
Zitat
define anwesend_SIM dummy
attr anwesend_SIM room System
attr anwesend_SIM webCmd on:off
# Anwesenheitssimulation Draußen definieren
define Laterne_RND RandomTimer *{sunset_abs()} Laterne *{sunset_abs(2*3600)} 480
attr Laterne_RND disableCond (!anwesend_SIM())
was schreibst du denn in
anwesend_SIM hinein?
so könnte es klappen:
attr Laterne_RND disableCond (Value("anwesend_SIM") eq "anwesend")
So, Dietmar. Heute war wieder ein Tag, an dem meine RandomTimer wieder aktiviert wurden und "Verbose=5" gesetzt war.
Ich habe die ganze Zeit die Finger vom System gelassen. Keine manuelle Schaltung der Lampen, kein Update, kein Neustart.
fhem-2016-11.log
2016.11.16 09:29:14 3: [rand_lampe1] starting RandomTimer on stru_lampe_1: 08:00:00(16) - 23:59:00(16)
2016.11.16 09:29:14 4: [rand_lampe1] IstZustand:off sigmaWhen-off:500 random:366<500=>true
2016.11.16 09:29:14 4: [rand_lampe1] command: set stru_lampe_1 on
2016.11.16 09:29:14 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 09:29:14 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 09:57:53
2016.11.16 09:30:06 3: [rand_lampe3] starting RandomTimer on stru_lampe_3: 08:00:00(16) - 23:59:00(16)
2016.11.16 09:57:53 4: [rand_lampe1] IstZustand:on sigmaWhen-on:500 random:288<500=>true
2016.11.16 09:57:53 4: [rand_lampe1] command: set stru_lampe_1 off
2016.11.16 09:57:53 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 09:57:53 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 10:27:52
2016.11.16 10:27:52 4: [rand_lampe1] IstZustand:off sigmaWhen-off:500 random:154<500=>true
2016.11.16 10:27:52 4: [rand_lampe1] command: set stru_lampe_1 on
2016.11.16 10:27:53 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 10:27:53 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 10:56:57
2016.11.16 10:56:57 4: [rand_lampe1] IstZustand:on sigmaWhen-on:500 random:246<500=>true
2016.11.16 10:56:57 4: [rand_lampe1] command: set stru_lampe_1 off
2016.11.16 10:56:57 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 10:56:57 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 11:26:23
2016.11.16 11:26:23 4: [rand_lampe1] IstZustand:off sigmaWhen-off:500 random:52<500=>true
2016.11.16 11:26:23 4: [rand_lampe1] command: set stru_lampe_1 on
2016.11.16 11:26:23 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 11:26:23 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 11:56:52
2016.11.16 11:56:52 4: [rand_lampe1] IstZustand:on sigmaWhen-on:500 random:493<500=>true
2016.11.16 11:56:52 4: [rand_lampe1] command: set stru_lampe_1 off
2016.11.16 11:56:53 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 11:56:53 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 12:27:02
2016.11.16 12:27:02 4: [rand_lampe1] IstZustand:off sigmaWhen-off:500 random:936<500=>false
2016.11.16 12:27:02 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 12:27:02 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 12:55:47
2016.11.16 12:55:47 4: [rand_lampe1] IstZustand:off sigmaWhen-off:500 random:308<500=>true
2016.11.16 12:55:47 4: [rand_lampe1] command: set stru_lampe_1 on
2016.11.16 12:55:47 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 12:55:47 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 13:27:13
2016.11.16 13:27:13 3: [rand_lampe1] ending RandomTimer on stru_lampe_1: 08:00:00(16) - 23:59:00(16)
2016.11.16 13:27:13 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 13:27:13 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 13:57:36
2016.11.16 13:57:36 4: [rand_lampe1] RandomTimer on stru_lampe_1 timer disabled - no switch
2016.11.16 13:57:36 5: [rand_lampe1] removing Timer: rand_lampe1_Exec
2016.11.16 13:57:36 5: [rand_lampe1] setting Timer: rand_lampe1_Exec 2016-11-16 14:28:0
Fakt ist, dass die Lampen nicht ausgeschaltet wurden, als das RT-Device disabled wurde.
Ich habe mal einen Blick in den Code geworfen und ich denke, dass ich mir den Test heute hätte sparen können. :-)
Müsste hier nicht evtl. auch ein RandomTimer_down($hash); ergänzt werden?
...
if ($active) {
# wenn temporär ausgeschaltet
if ($disabled) {
Log3 $hash, 3, "[".$hash->{NAME}."]"." ending RandomTimer on $hash->{DEVICE}: "
. strftime("%H:%M:%S(%d)",localtime($hash->{helper}{startTime})) . " - "
. strftime("%H:%M:%S(%d)",localtime($hash->{helper}{stopTime}));
RandomTimer_setState ($hash);
RandomTimer_setActive($hash,0);
}
...
Wenn die Stoppzeit erreicht wurde, werden die Geräte (abhängig vom keepDeviceAlive-Attribut) ausgeschaltet.
Aber nicht, wenn das RT-Device "disabled" wurde.
Was mich auch wundert:
Das Gerät wurde um 13:04 Uhr deaktiviert.
Warum wird im RT-Log nicht festgehalten, dass das Modul "disabled" wurde?
Und fehlt hier nicht ein "active: 0"?
Nachtrag: Hmm, könnte das evtl. etwas mit deiner letzten Änderung (https://sourceforge.net/p/fhem/code/12554/) zu tun haben? Dann hat man nun im Log ja absolut keine Infos mehr über den Gerätstatus. Schade.
rand_lampe1-2016-11.log
2016-11-16_00:30:30 rand_lampe1 Startzeit: 2016-11-16 08:00:00
2016-11-16_00:30:30 rand_lampe1 Stoppzeit: 2016-11-16 23:59:00
2016-11-16_09:04:50 rand_lampe1 off
2016-11-16_09:29:14 rand_lampe1 active: 1
2016-11-16_09:29:14 rand_lampe1 on
2016-11-16_09:57:53 rand_lampe1 on
2016-11-16_10:27:52 rand_lampe1 on
2016-11-16_10:56:57 rand_lampe1 on
2016-11-16_11:26:23 rand_lampe1 on
2016-11-16_11:56:52 rand_lampe1 on
2016-11-16_12:27:02 rand_lampe1 on
2016-11-16_12:55:47 rand_lampe1 on
Zitat von: Dietmar63 am 13 November 2016, 22:59:26
was schreibst du denn in anwesend_SIM hinein?
so könnte es klappen:
attr Laterne_RND disableCond (Value("anwesend_SIM") eq "anwesend")
Das war der entscheidende Tip 8)
Funktioniert, vielen Dank!
@Dietmar: Bist du noch da? Oder schon im Vorweihnachtsstreß? :-)
Hallo Leute,
ich kapiere da was nicht...
Es geht um "disableCond"
in der Reference steht:
attr ZufallsTimerZ disableCond (Value("presenceDummy") ne "present")
Mein Ziel ist dass ich "RandomTimer" als Anwesenheitssimulation nutzen möchte wenn niemand der Familie anwesend, also "present" ist
Wenn ich "disableCond" ausschreibe wie ich es verstehe, dann heisst es doch "disable" "Condition", also "Deaktivieren" "Bedingung", also die Bedingung um Random Timer zu deaktivieren.
Soweit richtig?
Nach obigen Beispiel aus der Reference, sagt es doch aber:
"Die Ausschaltbedingung soll sein, dass der Dummy presenceDummy irgendwas ist aber definitiv nicht present ist."
Also soll der Random Timer nicht arbeiten wenn keiner daheim ist. Verstehe ich das richtig?
Wenn ich also jetzt will, dass die Anwesenheit simuliert wird, wenn ich nicht da bin, dann müsste mein attribute sein:
attr ZufallsTimerZ disableCond (Value(".*Presence") eq "present")
oder vertue ich mich da jetzt?
Und nochwas...
In der Reference steht, dass man sich was in die 99_MyUtils schreiben soll. Ist das denn überhaupt nötig wenn ich das so mache wie in meinem Beispiel beschrieben??
Und leider noch ne Frage...
Funktioniert das mit dem...
.*Presence
...RegEx so überhaupt?
Meine Geräte die ich zur Anwesenheit nutze heissen "Holger_Presence" oder "Frau_Presence"
Macht es evtl. mehr Sinn einen Dummy zu nehmen, und diesen auf einen Status zu setzen wenn alle Bewohner abwesend sind, und dann diesen Dummy in die "disableCond" zu schreiben?
Danke für Eure Hilfe
Gruß
Holger
Regexp funktionieren nicht
Standardmäßig ist ein RT immer eingeschaltet.
Wenn disableCond true ist, ist er ausgeschaltet.
@Dietmar: Kommtest du dir das hier bereits anschauen? Mir fehlt dazu noch ne Meinung: https://forum.fhem.de/index.php/topic,14010.msg522558.html#msg522558
Zitat von: FunkOdyssey am 20 Dezember 2016, 23:46:36
@Dietmar: Kommtest du dir das hier bereits anschauen? Mir fehlt dazu noch ne Meinung: https://forum.fhem.de/index.php/topic,14010.msg522558.html#msg522558
Nein, ich hatte noch keine Zeit mich so tiefgreifend mit dem Thema zu beschäftigen.
@FunkOdyssey
...ich hatte auch die Probleme, das beim deaktivieren des DisabledCond Dummy´s, der RandomTimer zwar aufhörte zu schalten, aber das Device letztendlich nicht ausgeschalten wurde. Hab mir auch mal den Code angesehen und bin zum selben Schluss wie du gekommen. Es fehlt diese eine Zeile, wie in deinem Post schon festgestellt. Habe jetzt mal ergänzt und es funktioniert nun wie gewolllt. Konnte auch keine Nebenwirkungen feststellen.
Danke, das macht Hoffnung.
wenn ihr mir das als patch schickt kann ich es einbauen und einchecken - bin im Moment sehr beschäftigt
Zitat von: Dietmar63 am 05 Januar 2017, 20:11:00
wenn ihr mir das als patch schickt kann ich es einbauen und einchecken - bin im Moment sehr beschäftigt
Das hier sollte es gewesen sein:
--- Y:/98_RandomTimer.pm Fri Jan 06 17:07:00 2017
+++ Y:/98_RandomTimer_new.pm Fri Jan 06 17:04:04 2017
@@ -168,7 +168,6 @@
Log3 $hash, 3, "[".$hash->{NAME}."]"." ending RandomTimer on $hash->{DEVICE}: "
. strftime("%H:%M:%S(%d)",localtime($hash->{helper}{startTime})) . " - "
. strftime("%H:%M:%S(%d)",localtime($hash->{helper}{stopTime}));
- RandomTimer_down($hash);
RandomTimer_setState ($hash);
RandomTimer_setActive($hash,0);
}
Stop. Bitte den Patch nicht einsetzen.
Bei meiner Ankunft habe ich alle Zufallstimer disabled. Die Lampen wurden von mir eingeschaltet. Nach einigen Minuten (TimeSwitch) wurden die RTs deaktiviert und meine Lampen ausgeschaltet. Das sollte nicht sein.
Ich denke noch einmal darüber nach. So langsam nervt mich das enorm.
Hier ist das gestern auch passiert: Die disableCond hat den RT deaktiviert und die Lampe blieb an. Ich habe kürzlich ein größeres update gefahren, also vorher eine uralte Version benutzt.
Gibt es Neuigkeiten? Ich werde als Behelf jetzt erstmal die alte Version von RT aus 2015 wieder einsetzen. Die funktionierte bisher einwandfrei. Hoffentlich geht das noch mit dem aktuellen FHEM.
Mein Konstrukt aus DOIFs und RandomTimer wurde mittlerweile so komplex, dass ich selbst mehr Einfluss auf das Verhalten haben wollte.
Aus diesem Grund habe ich die Basis-Funktion des RandomTimer per DOIF (https://forum.fhem.de/index.php/topic,64760.msg560301.html#msg560301) nachgebaut. So kann ich nun direkt bestimmen, wie sich die Leuchten verhalten sollen. Und nicht erst 30min (TimeToSwitch) später von einer Ausschaltung überrascht werden.
Mein Randomtimer wird beendet, das Device aber nicht ausgeschaltet, warum?
Im Log steht: [ZufallsTimer_HUEDevice1] ending RandomTimer on HUEDevice1: 17:54:40(05) - 23:30:00(05)
Das HUEDevice1 ist aber immer noch an.
Häh. Genau darum ging es doch hier in den letzten Posts bzw. den letzten Seiten.
Zitat von: Fredi69 am 06 Februar 2017, 16:48:29
Mein Randomtimer wird beendet, das Device aber nicht ausgeschaltet, warum?
Im Log steht: [ZufallsTimer_HUEDevice1] ending RandomTimer on HUEDevice1: 17:54:40(05) - 23:30:00(05)
Das HUEDevice1 ist aber immer noch an.
das kann an den Befehlen liegen mit denen man ein HUE schalten muss.
Bitte mal verbose 5 einschalten, und den Output posten.
Ggf. liegt es am Inhalt von state - wenn ich mir recht entsinne, muss state on oder off beinhalten - je nach Inhalte wird nochmals off geschaltet.
Ich persönlich besitze kein HUE, so dass ich kaum testen und ohne Hilfe nicht erkennen kann, was die Ursache sein könnte.
Aber ich hatte doch bereits hier (https://forum.fhem.de/index.php/topic,14010.msg518899.html#msg518899) im November geschrieben, dass der RandomTimer die Geräte nicht ausschaltet, wenn diese "disabled" werden. Kann es nicht damit etwas zu tun haben?
Der RandomTimer verhält sich unterschiedlich beim "disable" und beim Erreichen der Enduhrzeit.
Am Rande:
Wenn ein RandomTimer per "disable" (oder sonstiges) deaktiviert wird, so sollte, meiner Meinung nach, der RandomTimer unverzüglich seine Arbeit niederlegen. Leider wird 1800 Sekunden (bzw. den exakten Wert aus TimeToSwitch) erst das ausgeführt, was vorher schon längst passieren sollte. Ein zyklisches Zufallsprinzip ist ja eine feine Sache. Aber nicht, wenn die RT-Geräte weiterlaufen und/oder die anzusteuernden Geräte einfach anlassen.
Das wird nicht der gleiche Fall sein.
Bei Fredi69 läuft der timer normal ab.
Wenn ich dich richtig verstanden habe, dann setzt du explizit das disable-Attribut, möchtest während der normalen Laufzeit den timer abschalten, aber das Gerät bleibt an. Ich bin mir nicht sicher, aber das Verhalten war "nicht definiert": Ich nutze disable nicht. Die Erweiterung kommt von jemand anders hier aus dem Forum.
Ich probiere mal was.
Wie wird HUE geschaltet?
Bei mir scheint es nicht ganz so einfach zu sein.
Ich habe zwei identische RandomTimer laufen.
Eine FS20 Stekdose, eine HUE Lampe.
Beide werden gleichzeitig per disableCond beendet.
Die FS20 Steckdose wird ausgeschaltet, die HUE Lampe nicht.
ZitatDie FS20 Steckdose wird ausgeschaltet, die HUE Lampe nicht.
Genau so habe ich mir das gedacht.
Mit welchem Befehl schaltet man ein HUE denn so? Und was steht in state?
Zitat von: Dietmar63 am 06 Februar 2017, 21:01:19
Genau so habe ich mir das gedacht.
Mit welchem Befehl schaltet man ein HUE denn so? Und was steht in state?
set HUEDevice on/off
ZitatLeider wird 1800 Sekunden (bzw. den exakten Wert aus TimeToSwitch) erst das ausgeführt, was vorher schon längst passieren sollte.
Das war sogar Absicht. Der Zufallsgedanke stand im Vordergrund. Der Timer endet absichtlich nicht exakt zum Zeitpunkt der Start- bzw. Ende-Zeit.
Bei mir läuft der Timer nur wenn ich wirklich nicht anwesend(Kurzurlaub) bin.
Viele Leute hier im Forum haben aber teilweise die RT mit Anwesenheitsbedingungen verknüpft, so dass sie viel dynamischer und häufiger im laufenden Betrieb enabled/disabled werden. Da kann es natürlich sein, dass ein anderes Verhalten wünschenswert wäre.
Ich habe mir das Ganze mal angesehen und kann vielleicht Abhilfe schaffen, ohne dass die Logik im Timer sich komplett veränern würde - ich melde mich.
Zitat von: Fredi69 am 06 Februar 2017, 21:11:03
set HUEDevice on/off
und wie sieht jeweils der state aus?
kannst du mich auch ggf. mit logging aus verbose 5 versorgen.
Zitat von: Dietmar63 am 06 Februar 2017, 21:15:02
und wie sieht jeweils der state aus?
kannst du mich auch ggf. mit logging aus verbose 5 versorgen.
State vom Hue Device oder dem RT?
Hue
state on
Habe gefunden warum sich beide unterschiedlich verhalten. Das habe ich verursacht. Es ist leider auch so, dass bei beiden bei eintreten der disableCond, das Gerät nicht ausgeschalteter wird.
Ok,
Dann liegt es doch an der gleichen Ursache
Ich habe eine Version im Test, die beim Eintreten von disable, das Gerät abschaltet.
habe eine verbesserte Version eingecheckt - bitte mal probieren, ob sie so funktioniert wie ihr es erwartet.
Zitat von: Dietmar63 am 08 Februar 2017, 01:08:57
habe eine verbesserte Version eingecheckt - bitte mal probieren, ob sie so funktioniert wie ihr es erwartet.
Ich habe wohl ein damit zusammen hängendes Problemchen festgestellt (98_RandomTimer.pm 13356 2017-02-07 23:47:53Z orti-otto):
2017-02-16_00:35:30 Random_Licht_Esszimmer Startzeit: 2017-02-16 17:57:44
2017-02-16_00:35:30 Random_Licht_Esszimmer Stoppzeit: 2017-02-16 22:57:44
Kurz nach 18 Uhr - Licht ist noch keines angegangen - komme ich nach Hause, setze (automatisch durch Wert von "Anwesenheit" ) die disableCond-Bedingung auf true:
attr Random_Licht_Esszimmer_5h disableCond (Value("Anwesenheit") eq "anwesend")
Direkt (ca 18:02) Uhr schalte ich jenes Licht dann manuell ein und erwarte, dass RandomTimer nur auch nichts mehr mit diesem Licht macht.
Eine halbe Stunde später aber schlägt er zu und macht es aus, man sitzt im Dunkeln:
2017.02.16 18:33:32 3: [Random_Licht_Esszimmer] ending RandomTimer on HM_xxxxxx_Licht_Esszimmer: 17:57:44(16) - 22:57:44(16)
Ist das vielleicht genau das angesprochene Verhalten, allerdings wird nicht direkt bei Änderung von "Anwesenheit", sondern erst beim nächsten Schaltzeitpunkt geprüft und ggf. abgeschaltet? Ich habe timeToSwitch mit 2500 Sekunden definiert, könnte also passen.
Update: Sehe gerade genau das ist auch ab #428 (03 Februar 2017, 12:58:27) beschrieben/behandelt.
Guten Morgen,
ich leider habe auch ein Problem mit dem Modul.
Ich habe mehrere RT definiert um eine Anwesenheitssimulation mit mehreren Lampen zu simulieren. Dabei sollen die Lampen natürlich unabhängig von einander eingeschaltet werden.
Alle Lampen gehen aber zum Zeitpunkt der Startzeit exact gleichzeitig an. Hier die Definitionen:
defmod ZufallsTimerMorgensWz RandomTimer *{sunrise_abs(-3600)} du_Wz.Deckenlampe *{sunrise_abs(3600)} 600
attr ZufallsTimerMorgensWz switchmode 800/200
setstate ZufallsTimerMorgensWz 2017-02-27 00:10:30 Startzeit 2017-02-27 05:50:34
setstate ZufallsTimerMorgensWz 2017-02-27 00:10:30 Stoppzeit 2017-02-27 07:50:34
defmod ZufallsTimerMorgensSz RandomTimer *{sunrise_abs(-3600)} du_Sz.Deckenlampe *{sunrise_abs(3600)} 600
attr ZufallsTimerMorgensSz switchmode 800/200
setstate ZufallsTimerMorgensSz 2017-02-27 00:10:30 Startzeit 2017-02-27 05:50:34
setstate ZufallsTimerMorgensSz 2017-02-27 00:10:30 Stoppzeit 2017-02-27 07:50:34
defmod ZufallsTimerMorgensTr RandomTimer *{sunrise_abs(-3600)} du_Tr.Deckenlampe *{sunrise_abs(3600)} 600
attr ZufallsTimerMorgensTr switchmode 800/200
setstate ZufallsTimerMorgensTr 2017-02-27 00:10:30 Startzeit 2017-02-27 05:50:34
setstate ZufallsTimerMorgensTr 2017-02-27 00:10:30 Stoppzeit 2017-02-27 07:50:34
und die Logauszüge:
2017.02.27 05:50:34 3: [ZufallsTimerMorgensTr] starting RandomTimer on du_Tr.Deckenlampe: 05:50:34(27) - 07:50:34(27)
2017.02.27 05:50:34 3: CUL_HM set Tr.Deckenlampe on
2017.02.27 05:50:34 3: [ZufallsTimerMorgensWz] starting RandomTimer on du_Wz.Deckenlampe: 05:50:34(27) - 07:50:34(27)
2017.02.27 05:50:34 3: CUL_HM set Wz.Deckenlampe on
2017.02.27 05:50:34 3: [ZufallsTimerMorgensSz] starting RandomTimer on du_Sz.Deckenlampe: 05:50:34(27) - 07:50:34(27)
2017.02.27 05:50:34 3: CUL_HM set Sz.Deckenlampe on
Wie kann ich die Lampen untereinander variieren? Oder ist das ein Bug.
Vielen Dank für Eure Antwort.
Gruß
Christian
*{sunrise_abs(-3600)}
so bekommst du zufällige Anfangswerte +/- 10 Minuten: rand()/3 = 0,33333 h - 1/6 = +- 10 Minuten
*{h2hms_fmt(hms2h(sunrise_abs(-3600))-(rand()/3)-1/6))}
Bitte mit diesem String in der Oberfläche probieren, bis die Werte passen - ich kann gerade nicht testen:
{h2hms_fmt(hms2h(sunrise_abs(-3600))-(rand()/3)-1/6)}
so wären es +- 20 Minuten:
*{h2hms_fmt(hms2h(sunrise_abs(-3600))-(rand()*2/3)-1/3))}
Hallo Dietmar,
vielen Dank für die Formeln. Das hat erst einmal geklappt.
Allerdings sind die Werte statisch für einen Tag inkl. Datum.
defmod ZufallsTimerMorgensSz RandomTimer {h2hms_fmt(hms2h(sunrise_abs(-3600))-(rand()*2/3)-1/3)} du_Sz.Deckenlampe {h2hms_fmt(hms2h(sunrise_abs(3600))-(rand()*2/3)-1/3)} 600
attr ZufallsTimerMorgensSz room Zutritt
attr ZufallsTimerMorgensSz switchmode 800/200
setstate ZufallsTimerMorgensSz off
setstate ZufallsTimerMorgensSz 2017-02-28 21:21:38 Startzeit 2017-02-28 05:27:11
setstate ZufallsTimerMorgensSz 2017-02-28 21:21:38 Stoppzeit 2017-02-28 07:08:08
setstate ZufallsTimerMorgensSz 2017-02-28 21:21:37 TimeToSwitch 600
setstate ZufallsTimerMorgensSz 2017-02-28 21:26:34 active 0
setstate ZufallsTimerMorgensSz 2017-02-28 21:26:34 state off
Wann werden denn die sunrise_abs Werte neu berechnet und wann über nimmt das RT-Modul diese?
Ich hätte jetzt erwartet, dass die Werte heute morgen neu für den heutigen Tag auftauchen.
Des weiteren funktioniert die DisableCond nicht.
Ich habe eine einfache Bedingung (Value("Homestatus") eq "Home")
Wann wir diese denn ausgewertet? Ich hätte erwartet, dass "eventgesteuert" der RT aktiviert oder deaktiviert wird.
Allerdings gibt es keine Verändung, wenn sich der Status meines Dummy Homestatus ändert.
Könnt Ihr noch einmal helfen?
Gruß und Dank
Christian
sunrise() erzeugt keine Events.
RT ermittelt die Werte immer kurz nach Mitternacht. Dann werden die Werte zum aktuellen Tag in sunrise() ermittelt
Wann wir diese denn ausgewertet? Ich hätte erwartet, dass "eventgesteuert" der RT aktiviert oder deaktiviert wird.
Allerdings gibt es keine Verändung, wenn sich der Status meines Dummy Homestatus ändert.
Die Bedingung wird bei jedem Schalten neu ausgewertet.
Hallo Dietmar,
vielen Dank für die schnelle Antwort.
ZitatRT ermittelt die Werte immer kurz nach Mitternacht. Dann werden die Werte zum aktuellen Tag in sunrise() ermittelt
Aber dann hätte ich heute morgen (01.03.2017) doch aktuelle Werte haben müssen. Hier standen aber noch die Werte vom 28.02.2017 (gestern).
ZitatDie Bedingung wird bei jedem Schalten neu ausgewertet.
Nur für mich zum Verständnis: Dann "läuft" also das Modul "immer", ermittelt die potentiellen Schaltpunkte und prüft dann bei jedem Schaltpunkt, ob die DisableCond erfüllt ist. Das heißt zum Zeitpunkt eines Schaltpunkts müsste sich der Status des RT dann diesbezüglich ändern?
Gruß
Christian
Ich denke ja so ist es.
Du kannst bei einem konkreten RT verbose 5 setzen, dann bekommst du detaillierte Informationen.
Hallo Dietmar,
bezieht sich Deine Antwort:
ZitatIch denke ja so ist es.
Auf die Frage nach der Wertermittlung nach Mitternacht oder zu der DisableCond.
Die Wertermittlung nach Mitternacht hat ja nicht geklappt.
Gruß
Christian
Hier ein verbose 5 von einem RT. Wo ist hier das neue Setzen von sunset bzw. sunrise?
2017.03.02 17:07:46 4: [ZufallsTimerWz] timings RandomTimer on du_Wz.Deckenlampe: 18:05:15(02) - 00:14:34(03)
2017.03.02 17:07:46 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:05:15
2017.03.02 18:05:15 3: [ZufallsTimerWz] starting RandomTimer on du_Wz.Deckenlampe: 18:05:15(02) - 00:14:34(03)
2017.03.02 18:05:15 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:770<800=>true
2017.03.02 18:05:15 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 18:05:15 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:05:15 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:15:29
2017.03.02 18:15:29 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:391<200=>false
2017.03.02 18:15:29 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:15:29 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:25:31
2017.03.02 18:25:33 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:5<200=>true
2017.03.02 18:25:33 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
2017.03.02 18:25:33 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:25:33 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:35:56
2017.03.02 18:35:56 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:309<800=>true
2017.03.02 18:35:56 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 18:35:56 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:35:56 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:45:27
2017.03.02 18:45:30 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:49<200=>true
2017.03.02 18:45:30 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
2017.03.02 18:45:30 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:45:30 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 18:55:47
2017.03.02 18:55:47 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:111<800=>true
2017.03.02 18:55:47 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 18:55:47 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 18:55:47 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:06:01
2017.03.02 19:06:01 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:961<200=>false
2017.03.02 19:06:01 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:06:01 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:16:07
2017.03.02 19:16:07 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:964<200=>false
2017.03.02 19:16:07 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:16:07 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:25:55
2017.03.02 19:25:55 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:208<200=>false
2017.03.02 19:25:55 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:25:55 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:35:44
2017.03.02 19:35:44 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:72<200=>true
2017.03.02 19:35:44 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
2017.03.02 19:35:44 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:35:44 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:45:51
2017.03.02 19:45:51 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:91<800=>true
2017.03.02 19:45:51 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 19:45:51 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:45:51 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 19:56:12
2017.03.02 19:56:12 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:364<200=>false
2017.03.02 19:56:12 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 19:56:12 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:06:17
2017.03.02 20:06:17 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:760<200=>false
2017.03.02 20:06:17 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:06:17 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:16:00
2017.03.02 20:16:00 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:956<200=>false
2017.03.02 20:16:00 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:16:00 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:26:13
2017.03.02 20:26:13 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:172<200=>true
2017.03.02 20:26:13 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
2017.03.02 20:26:13 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:26:13 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:36:09
2017.03.02 20:36:09 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:462<800=>true
2017.03.02 20:36:09 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 20:36:09 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:36:09 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:46:09
2017.03.02 20:46:09 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:672<200=>false
2017.03.02 20:46:09 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:46:09 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 20:56:27
2017.03.02 20:56:27 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:323<200=>false
2017.03.02 20:56:27 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 20:56:27 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:06:14
2017.03.02 21:06:14 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:781<200=>false
2017.03.02 21:06:14 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:06:14 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:15:48
2017.03.02 21:15:48 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:815<200=>false
2017.03.02 21:15:48 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:15:48 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:25:45
2017.03.02 21:25:45 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:915<200=>false
2017.03.02 21:25:45 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:25:45 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:35:42
2017.03.02 21:35:42 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:358<200=>false
2017.03.02 21:35:42 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:35:42 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:45:39
2017.03.02 21:45:39 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:850<200=>false
2017.03.02 21:45:39 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:45:39 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 21:55:54
2017.03.02 21:55:54 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:295<200=>false
2017.03.02 21:55:54 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 21:55:54 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:06:21
2017.03.02 22:06:21 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:281<200=>false
2017.03.02 22:06:21 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:06:21 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:16:49
2017.03.02 22:16:49 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:630<200=>false
2017.03.02 22:16:49 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:16:49 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:26:22
2017.03.02 22:26:22 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:759<200=>false
2017.03.02 22:26:22 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:26:22 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:36:39
2017.03.02 22:36:39 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:677<200=>false
2017.03.02 22:36:39 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:36:39 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:46:49
2017.03.02 22:46:49 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:208<200=>false
2017.03.02 22:46:49 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:46:49 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 22:56:58
2017.03.02 22:56:58 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:342<200=>false
2017.03.02 22:56:58 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 22:56:58 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:07:12
2017.03.02 23:07:12 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:336<200=>false
2017.03.02 23:07:12 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:07:12 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:16:42
2017.03.02 23:16:42 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:45<200=>true
2017.03.02 23:16:42 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
2017.03.02 23:16:42 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:16:42 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:26:20
2017.03.02 23:26:20 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:817<800=>false
2017.03.02 23:26:20 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:26:20 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:36:44
2017.03.02 23:36:44 4: [ZufallsTimerWz] IstZustand:off sigmaWhen-off:800 random:356<800=>true
2017.03.02 23:36:44 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe on
2017.03.02 23:36:44 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:36:44 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:46:55
2017.03.02 23:46:58 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:528<200=>false
2017.03.02 23:46:58 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:46:58 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-02 23:57:07
2017.03.02 23:57:07 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:943<200=>false
2017.03.02 23:57:07 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.02 23:57:07 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-03 00:07:00
2017.03.03 00:07:00 4: [ZufallsTimerWz] IstZustand:on sigmaWhen-on:200 random:889<200=>false
2017.03.03 00:07:00 5: [ZufallsTimerWz] removing Timer: ZufallsTimerWz_Exec
2017.03.03 00:07:00 5: [ZufallsTimerWz] setting Timer: ZufallsTimerWz_Exec 2017-03-03 00:16:44
2017.03.03 00:16:44 3: [ZufallsTimerWz] ending RandomTimer on du_Wz.Deckenlampe: 18:05:15(02) - 00:14:34(03)
2017.03.03 00:16:44 4: [ZufallsTimerWz] command: set du_Wz.Deckenlampe off
Hier die Definiton:
defmod ZufallsTimerWz RandomTimer {h2hms_fmt(hms2h(sunset_abs())-(rand()*2/3)-1/3)} du_Wz.Deckenlampe {h2hms_fmt(hms2h(sunset_abs(6*3600))-(rand()*2/3)-1/3)} 600
attr ZufallsTimerWz room Zutritt
attr ZufallsTimerWz switchmode 800/200
attr ZufallsTimerWz verbose 5
setstate ZufallsTimerWz off
setstate ZufallsTimerWz 2017-03-02 17:07:46 Startzeit 2017-03-02 18:05:15
setstate ZufallsTimerWz 2017-03-02 17:07:46 Stoppzeit 2017-03-03 00:14:34
setstate ZufallsTimerWz 2017-03-02 17:07:31 TimeToSwitch 600
setstate ZufallsTimerWz 2017-03-03 00:16:44 active 0
setstate ZufallsTimerWz 2017-03-03 00:16:44 state off
passiert aber immer um Mitternacht oder wenn du die DEF modifys.
Hallo Dietmar,
danke für die Infos, in der Zwischenzeit habe ich glaube ich den Fehler gefunden.
In der Definition
defmod ZufallsTimerWz RandomTimer {h2hms_fmt(hms2h(sunset_abs())-(rand()*2/3)-1/3)} du_Wz.Deckenlampe {h2hms_fmt(hms2h(sunset_abs(6*3600))-(rand()*2/3)-1/3)} 600
fehlen die "*" vor {h2hms_fmt ...
Es muss ja defmod ZufallsTimerWz RandomTimer *{h2hms_fmt(hms2h(sunset_abs())-(rand()*2/3)-1/3)} du_Wz.Deckenlampe *{h2hms_fmt(hms2h(sunset_abs(6*3600))-(rand()*2/3)-1/3)} 600
heißen. Somit wurde die Zeit m.E. immer nur einmal berechnet und nicht jede Nacht neu.
Auch die Funktionsweise der DisableCond konnte ich nun korrekt nachvollziehen.
Ich hätte noch einen Wunsch: Kann man es einrichten, dass bei erreichen der DisableCond sofort das Device abgeschaltet wird und nicht erst beim nächsten Schaltvorgang?
Ich glaube, ich habe diesen Wunsch hier bereots einmal ebenfalls gesehen.
Schönes Wochenende und Gruß
Christian
Das ist absichtlich so eingebaut, damit soll verschleiert werden dass niemand zu Hause ist.
Hallo,
nach dem Update von gestern Abend habe ich beim Neustart gesehen, dass diese Meldung im logFile aufscheint:
2017.03.13 18:02:58 1: PERL WARNING: Use of uninitialized value in localtime at ./FHEM/98_RandomTimer.pm line 196.
2017.03.13 18:02:58 1: PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/98_RandomTimer.pm line 222.
Hab ich da was falsch gemacht, bzw. was kann ich tun um das wieder ins Lot zu bringen?
Hallo,
ich habe bisher meine RT immer in Abhängigkeit von einer Anwesenheitserkennung per disable 1 oder 0 geschaltet. Schließlich soll die Beleuchtung ja nur angehen, wenn ich nicht da bin.
define zufall_kueche_abends RandomTimer *{sunset_abs(-3000)} Dimmer_Kueche {sunset_abs(+3960,"21:36","23:36")} 300
Allerdings gehen seit ein paar Tagen die Lichter auch außerhalb der definierten Zeitspanne bei Abwesenheit sofort an:
2017.03.22 17:35:47 2: ROOMMATE set rr_XXXXX absent
2017.03.22 17:35:49 3: [zufall_kueche_abends] starting RandomTimer on Dimmer_Kueche: 18:23:13(22) - 21:36:00(22)
2017.03.22 17:35:49 3: CUL_HM set Dimmer_Kueche pct 100
Nach meinem Verständnis dürfte das Licht erst ab 18:23:13 an und ab 21:36:00 wieder ausgehen. Z.Zt. gehen die Lichter aber auch am hellichten Tag an, wenn der RT per disable 0 "scharf" geschaltet wird.
Was hat sich verändert? Hab ich was verpasst?
Gruß
oelidoc
Bitte mit verbose 5 Logging erzeugen
Gerne:
define zufall_arbeitszimmer_abends RandomTimer *{sunset_abs(-3200)} Licht_Arbeitszimmer {sunset_abs(+3720,"21:32","23:32")} 300
attr zufall_arbeitszimmer_abends disable 1
attr zufall_arbeitszimmer_abends offCmd set Licht_Arbeitszimmer off
attr zufall_arbeitszimmer_abends onCmd set Licht_Arbeitszimmer on
attr zufall_arbeitszimmer_abends room Arbeitszimmer
attr zufall_arbeitszimmer_abends switchmode 900/50
attr zufall_arbeitszimmer_abends verbose 5
2017.03.22 18:34:45 2: ROOMMATE set rr_Wolfgang absent
2017.03.22 18:34:45 5: [zufall_arbeitszimmer_abends] removing Timer: zufall_arbeitszimmer_abends_Exec
2017.03.22 18:34:45 5: [zufall_arbeitszimmer_abends] setting Timer: zufall_arbeitszimmer_abends_Exec 2017-03-22 18:34:46
2017.03.22 18:34:46 3: [zufall_arbeitszimmer_abends] starting RandomTimer on Licht_Arbeitszimmer: 18:19:53(22) - 21:32:00(22)
2017.03.22 18:34:46 4: [zufall_arbeitszimmer_abends] IstZustand:off sigmaWhen-off:900 random:980<900=>false
2017.03.22 18:34:46 5: [zufall_arbeitszimmer_abends] removing Timer: zufall_arbeitszimmer_abends_Exec
2017.03.22 18:34:46 5: [zufall_arbeitszimmer_abends] setting Timer: zufall_arbeitszimmer_abends_Exec 2017-03-22 18:39:48
2017.03.22 18:35:34 2: ROOMMATE set rr_Wolfgang home
2017.03.22 18:35:35 5: [zufall_arbeitszimmer_abends] removing Timer: zufall_arbeitszimmer_abends_Exec
2017.03.22 18:35:35 5: [zufall_arbeitszimmer_abends] setting Timer: zufall_arbeitszimmer_abends_Exec 2017-03-22 18:35:36
2017.03.22 18:35:36 3: [zufall_arbeitszimmer_abends] ending RandomTimer on Licht_Arbeitszimmer: 18:19:53(22) - 21:32:00(22)
2017.03.22 18:35:36 4: [zufall_arbeitszimmer_abends] command: set Licht_Arbeitszimmer off
2017.03.22 18:35:36 3: CUL_HM set Licht_Arbeitszimmer off
2017.03.22 18:35:36 5: [zufall_arbeitszimmer_abends] removing Timer: zufall_arbeitszimmer_abends_Exec
2017.03.22 18:35:36 5: [zufall_arbeitszimmer_abends] setting Timer: zufall_arbeitszimmer_abends_Exec 2017-03-22 18:40:25
So läuft alles gut - aber wir sind ja jetzt auch innerhalb der Time Spezifikation...Startzeit
2017-03-22 18:19:53
2017-03-22 17:33:17
Stoppzeit
2017-03-22 21:32:00
2017-03-22 17:33:17
TimeToSwitch
300
2017-03-22 17:33:16
Gruß
oelidoc
So hab jetzt mal einen RT für heute nacht erstellt:
define zufall_Testfall RandomTimer 21:00 Licht_Arbeitszimmer 23:50 300
attr zufall_Testfall disable 1
attr zufall_Testfall room Arbeitszimmer
attr zufall_Testfall switchmode 800/200
Und der schaltet jetzt schon das Licht ein:
2017.03.22 18:52:27 2: ROOMMATE set rr_Wolfgang absent
2017.03.22 18:52:27 5: [zufall_Testfall] removing Timer: zufall_Testfall_Exec
2017.03.22 18:52:27 5: [zufall_Testfall] setting Timer: zufall_Testfall_Exec 2017-03-22 18:52:28
2017.03.22 18:52:27 5: [zufall_arbeitszimmer_abends] removing Timer: zufall_arbeitszimmer_abends_Exec
2017.03.22 18:52:27 5: [zufall_arbeitszimmer_abends] setting Timer: zufall_arbeitszimmer_abends_Exec 2017-03-22 18:52:28
2017.03.22 18:52:28 3: [zufall_Testfall] starting RandomTimer on Licht_Arbeitszimmer: 21:00:00(22) - 23:50:00(22)
2017.03.22 18:52:28 4: [zufall_Testfall] IstZustand:off sigmaWhen-off:800 random:664<800=>true
2017.03.22 18:52:28 4: [zufall_Testfall] command: set Licht_Arbeitszimmer on
2017.03.22 18:52:28 3: CUL_HM set Licht_Arbeitszimmer on
2017.03.22 18:52:28 5: [zufall_Testfall] removing Timer: zufall_Testfall_Exec
2017.03.22 18:52:28 5: [zufall_Testfall] setting Timer: zufall_Testfall_Exec 2017-03-22 18:57:14
Und auch wieder aus:
2017.03.22 18:54:45 2: ROOMMATE set rr_Wolfgang home
2017.03.22 18:54:45 5: [zufall_Testfall] removing Timer: zufall_Testfall_Exec
2017.03.22 18:54:45 5: [zufall_Testfall] setting Timer: zufall_Testfall_Exec 2017-03-22 18:54:46
2017.03.22 18:54:46 3: [zufall_Testfall] ending RandomTimer on Licht_Arbeitszimmer: 21:00:00(22) - 23:50:00(22)
2017.03.22 18:54:46 4: [zufall_Testfall] command: set Licht_Arbeitszimmer off
2017.03.22 18:54:46 3: CUL_HM set Licht_Arbeitszimmer off
2017.03.22 18:54:46 5: [zufall_Testfall] removing Timer: zufall_Testfall_Exec
2017.03.22 18:54:46 5: [zufall_Testfall] setting Timer: zufall_Testfall_Exec 2017-03-22 18:59:31
Ich hoffe, du kannst damit was anfangen.
Gruß
oelidoc
Guten Morgen,
Kann mir irgendwer was zu den Perl Warnungen im Eintrag 457 was sagen. Bitte um Hilfe.
Beste Grüsse
Leo
Hallo zusammen,
ich habe seit kurzem ebenfalls das Problem dass der Einschaltvorgang der in der Definition vorgegebenen Zeit nicht mehr berücksichtigt wird.
Ich bin mir nicht ganz sicher, aber ich denke das Problem tritt seit dem Fhem Update vor ca. 2 Wochen auf.
Zitat von: nuart am 23 März 2017, 08:10:56
Guten Morgen,
Kann mir irgendwer was zu den Perl Warnungen im Eintrag 457 was sagen. Bitte um Hilfe.
Beste Grüsse
Leo
Hatte ich nicht gesehen - schaue ich mir nachher an
@oelidoc:
Versuche ich auch nachher zu untersuchen
Zitat von: nuart am 23 März 2017, 08:10:56
Guten Morgen,
Kann mir irgendwer was zu den Perl Warnungen im Eintrag 457 was sagen. Bitte um Hilfe.
Beste Grüsse
Leo
neue Version eingecheckt - die PERL WARINGS sollten jezt nicht mehr auftauchen
Hallo,
Nach update keine perl warnings mehr. Vielen Dank.
Leo
Hallo,
habe das Problem für mich jetzt mit einer disableCond (Value("rgr_Residents") eq "home") gelöst. Das funktioniert bis jetzt gut.
Vielen Dank
oelidoc
Das ist auch erste von mir implementierte Variante.
Disable ist irgendwann nachgerüstet worden.
Auf Wunsch hier aus dem Forum habe ich etwas ergänzt was jetzt zu diesem Problem führt.
Ich glaube ich habe dafür aber eine Lösung gefunden
Hey,
Bis vor zwei Wochen konnte ich meinen Randomtimer zuverlässig mit attr disable ganz gut steuern
Zufallsteuerung An/Aus
=> der änderte immer mein attr disable 0/1
--> nicht ganz schön aber funktionierte
jetzt klappt das nicht mehr weil sobald er disabled war er die Zeit nicht mehr weiß :-(
und somit auch tagsüber meine Random Lampen an gehen .....
Ich würde gerne mit dem disableCond arbeiten aber das klappt bei mir nicht
zB.: habe ich eine Stuktur => Familie_structure diese ist present oder absent aber mein
disableCond (Value("Familie_structure") eq "present")
reagiert nicht drauf ob jetzt absent oder present keine Änderung am Randomtimer
Was mach ich falsch?
ich teste gerade die schon umgesetzte Lösung - bald gebe ich frei
super!!
aber wieeso klappt das bei mir nicht mit
disableCond (Value("Familie_structure") eq "present")
??
brauch ich da noch ein myUtils ???
gib mal
{Value("Familie_structure") eq "present")}
in der FHEM-Oberfläche ein
einfach eingegeben
die ausgabe war:
syntax error at (eval 4646) line 1, near ""present")"
Die hintere Klammer weglassen
Aaaa OK :-)
der Randomtimer wird aber nicht deaktiviert keine reaktion auf änderungen ....
{Value("Familie_structure") eq "present"}
{Value("Familie_structure") eq "absent"}
am timer
disableCond (Value("Familie_structure") eq "present")
Hallo zusammen,
die disableCond wird erst beim nächsten anstehenden Schaltvorgang ausgewertet. Also nicht direkt, wenn sich die Bedingung ändert.
Damit soll die Abhängigkeit (z.B. zu Anwesenheit) verschleiert werden.
Gruß
Christian
Hi Dietmar,
habe auch das Problem mit der disable-Condition seit meinem Upgrade gestern.
Hast Du schon eine Ahnung, wann Du die Korrektur veröffentlichst?
Je nachdem würde ich mich ansonsten mit dem Workaround intensiver beschäftigen.
danke & VG
Obelix
Wird nicht mehr so lange dauern.
Ziehe gerade mit meinem Linux auf einen neuen Laptop um.
Danke für die Info...dann werde ich mich noch nicht mit einem Workaround beschäftigen. :D
eingecheckt probiert es mal aus
Moin,
hab bei meinem RandomTimer Start- sowie Endzeitpunkt fix gesetzt.
Einmalig funktioniert das auch, sobald der Timer allerdings einmal durchgelaufen ist, aktiviert er sich nicht mehr zum eingestellten timespec_start.
Nach einem FHEM-restart läuft er wieder zum angegebenen Zeitpunkt.
Hab ich irgendwas übersehen?
Internals:
COMMAND on
DEF 18:20:00 HUEDevice5 23:22:00 900
DEVICE HUEDevice5
NAME AnwesenheitsSimu_HueLamp2
NR 186
STATE on
TYPE RandomTimer
READINGS:
2017-08-02 18:58:58 Startzeit 2017-08-02 18:20:00
2017-08-02 18:58:58 Stoppzeit 2017-08-02 23:22:00
2017-08-02 18:58:52 TimeToSwitch 900
2017-08-02 18:58:59 active 1
2017-08-02 19:13:19 state on
TIMER:
AnwesenheitsSimu_HueLamp2_Exec:
HASH AnwesenheitsSimu_HueLamp2
MODIFIER Exec
NAME AnwesenheitsSimu_HueLamp2_Exec
AnwesenheitsSimu_HueLamp2_SetTimer:
HASH AnwesenheitsSimu_HueLamp2
MODIFIER SetTimer
NAME AnwesenheitsSimu_HueLamp2_SetTimer
helper:
REL
REP
SIGMAWHENOFF 800
SIGMAWHENON 200
STARTTIME 02.08.2017 18:20:00
STOPTIME 02.08.2017 23:22:00
SWITCHMODE 800/200
S_REL
S_REP
TIMESPEC_START 18:20:00
TIMESPEC_STOP 23:22:00
TIMETOSWITCH 900
active 1
startTime 1501690800
stopTime 1501708920
Attributes:
disableCond (Value("AnwesenheitsSimu_Status") eq "Inaktiv")
switchmode 800/200
Zitat von: pataya am 02 August 2017, 19:27:43
Moin,
hab bei meinem RandomTimer Start- sowie Endzeitpunkt fix gesetzt.
Einmalig funktioniert das auch, sobald der Timer allerdings einmal durchgelaufen ist, aktiviert er sich nicht mehr zum eingestellten timespec_start.
Nach einem FHEM-restart läuft er wieder zum angegebenen Zeitpunkt.
Hab ich irgendwas übersehen?
Same here....
Läuft einmal durch und dann ist der RandomTimer "tot".
Er geht ausserhalb der Timespec auch nicht auf disabled sondern bleibt einfach aus.
Erst ein "modify Def" belebt den Timer wieder.
Woran mag das liegen?
Bin dankbar für jeden Tip.
Grtz
CmdA
Zitat von: pataya am 02 August 2017, 19:27:43
Moin,
hab bei meinem RandomTimer Start- sowie Endzeitpunkt fix gesetzt.
Einmalig funktioniert das auch, sobald der Timer allerdings einmal durchgelaufen ist, aktiviert er sich nicht mehr zum eingestellten timespec_start.
Nach einem FHEM-restart läuft er wieder zum angegebenen Zeitpunkt.
+1, du bist nicht allein. Sitze aktuell in Griechenland und beobachte exakt die gleiche Problematik zuhause. Läuft einmal problemlos durch, anschließend funktionert es nur nach shutdown restart. Scheint wohl mit irgendeinem Update auseinandergebröselt zu sein, hat meiner Erinnerung nach vor ein paar Monaten noch reibungslos funktioniert.
Hallo,
ich steuere mittlerweile das komplette Haus mit RT.
Seit dem Update auf das attr "forceStoptimeSameDay" läuft alles 1A.
Trotzdem eine Frage:
-> Ich habe pro zu schaltendem Element zwei RTs, einen für Arbeitstag, einen für Wochenende
-> über die disabledCondition reagiere ich auf Anwesenheit und Arbeitstag / Wochenende
-> eine Realisierung mit ($we) funktioniert leider nicht, folgende Fehlermeldung kommt
2017.10.12 19:08:17 3: [RandomTimer.Zimmer.Abends.WochenTag] ERROR: Global symbol "$we" requires explicit package name (did you forget to declare "my $we"?) at (eval 134815) line 1. EVALUATING ((Value("Aktiv") eq "off") or ($we))
=> ist die Deklaration von ($we) im Modul nicht vorhanden oder mache ich etwas anderes falsch?
=> momentan umgehe ich das mit einem Dummy der sich täglich früh aus ($we) den Wert holt
=> ich würde aber gern sowenig wie möglich Zwischenschritte / Ballast mitführen
Danke und Gruß
Hallo zusammen,
ich habe auch das Problem, das der Timer nur einmal durchläuft und dann nicht wieder anspringt.
Gibt es dafür bereits eine Lösung?
Zur Nor auch eine Befehlslösung.
Danke
Gruß
Arminius
Ich wärme das Thema noch ein mal auf. Auch bei mir läuft der RandomTimer nur einmalig und wird dann nicht wieder aktiviert.
Einen Workaround scheint es noch nicht zu geben?!
Hallo zusammen,
bei mir läuft es nun.
Ich hatte mich gewundert, dass nicht sämtliche randomtimer funktioniert haben, sondern nur einige spezielle.
Diese habe ich mir nun angeschaut und festgestellt, dass jene funktioniert haben, die zb. sunset_abs als Startzeit hatten.
Alle die eine feste Startzeit hatten zb. 17:00 gingen nicht.
Nachdem ich nun sämtliche Startzeiten geändert habe und nur noch mit sunset_abs als Zeitangabe arbeite funktioniert nun jeder Timer.
Ich habe auch noch das attribute disableCond gesetzt und frage damit meine Anwesenheit ab.
Vielleicht hilft die Info dem einen oder anderen.
Gruß
Arminius
Guten Abend,
die Urlaubszeit naht 8), und ich wollte hier doch noch das Ding ans Laufen bringen.
Zum Testen habe ich alle 60 Sekunden schalten und maximale Wahrscheinlichkeit für's Einschalten gewählt.
Leider geht der "Ball" immer nur an und direkt wieder aus. :-(
Hat jemand eine Idee??
fhem> list BallRandom
Internals:
COMMAND on
DEF *21:00:00 Ball *{sunset_abs(2*3600)} 60
DEVICE Ball
NAME BallRandom
NR 365
STATE on
TYPE RandomTimer
READINGS:
2018-07-13 22:13:30 Startzeit 2018-07-13 21:00:00
2018-07-13 22:13:30 Stoppzeit 2018-07-14 00:25:48
2018-07-13 22:13:30 TimeToSwitch 60
2018-07-13 22:13:30 active 1
2018-07-13 22:30:23 state on
TIMER:
BallRandom_Exec:
HASH BallRandom
MODIFIER Exec
NAME BallRandom_Exec
BallRandom_SetTimer:
HASH BallRandom
MODIFIER SetTimer
NAME BallRandom_SetTimer
helper:
REL
REP *
SIGMAWHENOFF 999
SIGMAWHENON 100
STARTTIME 13.07.2018 21:00:00
STOPTIME 14.07.2018 00:25:48
SWITCHMODE 999/100
S_REL
S_REP *
TIMESPEC_START *21:00:00
TIMESPEC_STOP *{sunset_abs(2*3600)}
TIMETOSWITCH 60
active 1
startTime 1531508400
stopTime 1531520748
Attributes:
onCmd set Ball 40 pct
stateFormat {(ReadingsVal("Ball","state","nF") =~ m/(OFF|off)/i) ? "off" : "on" }
switchmode 999/100
Log-Beispiel:
fhem> RandomTimer BallRandom on
CUL_HM Ball level: set_40
CUL_HM Ball set_40
CUL_HM Ball deviceMsg: 0.5 (to VCCU)
CUL_HM Ball dim: up:0.5
CUL_HM Ball level: 0.5
CUL_HM Ball overheat: off
CUL_HM Ball overload: off
CUL_HM Ball pct: 0.5
CUL_HM Ball reduced: off
CUL_HM Ball 0.5
CUL_HM Ball timedOn: running
CUL_HM Ball deviceMsg: off (to VCCU)
CUL_HM Ball dim: stop:off
CUL_HM Ball level: 0
CUL_HM Ball overheat: off
CUL_HM Ball overload: off
CUL_HM Ball pct: 0
CUL_HM Ball reduced: off
CUL_HM Ball off
CUL_HM Ball timedOn: off
Auch, wenn ich ein separates offCmd definiere, ist der Effekt der gleiche.
OK, es scheint an den "40 pct" zu liegen – trotz der lt. Test funktionierenden stateFormat Anweisung. Wenn ich stumpf "on" wähle, geht es.
Aber dann wird der Einbrecher ja blind! ;D
Nu hab ich mal eine LightScene gebastelt, aber jetzt scheint er die stateFormat Anweisung nicht mehr zu erkennen.
Hallo zusammen,
zuallererst vielen Dank für dieses super Modul, funktioniert bisweilen tadellos. Einzig habe ich das Problem, dass durch das Modul mein FHEM Log File erheblich "zugemüllt" wird. Eine Veränderung des Attributs "verbose" bringt leider auch keine signifikante Änderung mit sich. Habe ich da vielleicht noch etwas übersehen bzw. kennt jmd. von euch eine Lösung hierfür?
Vielen Dank für die Unterstützung
Cheers
Marco
Zitat von: MarcoK am 18 Juli 2018, 12:00:30
zuallererst vielen Dank für dieses super Modul, funktioniert bisweilen tadellos. Einzig habe ich das Problem, dass durch das Modul mein FHEM Log File erheblich "zugemüllt" wird. Eine Veränderung des Attributs "verbose" bringt leider auch keine signifikante Änderung mit sich. Habe ich da vielleicht noch etwas übersehen bzw. kennt jmd. von euch eine Lösung hierfür?
Was für Einträge werden denn erzeugt?
Es handelt sich um folgende Einträge:
isAbsent - disableCondition for RandomTimer: 0
Bitte einmal die ganze Log Zeile Posten.
So, nun nochmal ein genauerer Auszug aus dem Logfile:
2018.07.19 00:47:01 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:01 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:01 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:01 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:20 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:20 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:20 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:20 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:20 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:45 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:47:45 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:55:18 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:55:18 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:55:18 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 00:55:18 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:04:10 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:04:10 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:04:10 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:04:10 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:10:06 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:10:06 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:10:06 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:10:06 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:10:06 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:16:37 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:16:37 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:28:38 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:28:38 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:28:38 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:28:38 1: isAbsent - disableCondition for RandomTimer: 0
2018.07.19 01:28:38 1: isAbsent - disableCondition for RandomTimer: 0
Ich habe insgesamt 4 RandomTimer (für 4 Räume) analog wie z.B. hier
*{h2hms_fmt(hms2h(sunset_abs())-(rand()*2/3)-1/3)} Livingroom_Lights *{h2hms_fmt(hms2h(sunset_abs(4*3600))-(rand()*2/3)-1/3)} 1500
definiert. Die TimetoSwitch ist jeweils auf eine unterschiedliche Länge gesetzt. Mittlerweile ist über das Attribut verbose 1 die Menge an Logmeldungen etwas reduziert. Die Meldungen wie im obigen Abschnitt zu sehen treten nun "nur noch" im Zeitraum zwischen "Beginn" und "Ende" der RandomTimer auf, jeweils in dem ungefähren Zeitintervall von einigen Minuten. Zuvor wurden die Meldungen alle 20 Sekunden generiert und ins Logfile geschrieben.
Besten Dank für die Unterstützung,
Marco
Hi Marco,
ich habe das Modul ja nur geerbt, deswegen brauchte ich die ganze Zeile.
Im Code von Randomtimer kann ich keine Zeile ausfindig machen die so einen Logeintrag erzeugt.
Ist die Version aktuell? Nutzt du noch andere Module die sowas erzeugen könnten (z.B. Module die den Status von Devices überwachen)?
Ah ja, okay, danke für den Hinweis! Schande über mich, aber die Meldungen stammen aus einer Funktion in meiner myUtils, oh man.
Danke für Deinen Support und insgesamt auch für Deine ganze Arbeit mit den Modulen :)
Grüße
Marco
Zitat von: MarcoK am 19 Juli 2018, 20:10:45
Ah ja, okay, danke für den Hinweis! Schande über mich, aber die Meldungen stammen aus einer Funktion in meiner myUtils, oh man.
Dann haben wir die Fehlerquelle ja schnell gefunden ;)
Zitat von: MarcoK am 19 Juli 2018, 20:10:45
Danke für Deinen Support und insgesamt auch für Deine ganze Arbeit mit den Modulen :)
Vielen Dank :)
Ich habe etwas den Faden verloren. Ich nutze das Modul zur Anwesenheitssimulation, wie viele Andere auch. Wenn ich zuhause bin wird die disableCond true. Das Funktioniert auch soweit. Wenn ich aber nach Hause komme und RandomTimer schon läuft schaltet er mir irgendwann das Licht aus. keepDeviceAlive wäre hier richtig. Wenn ich aber abwesend bin sollen die Lichter natürlich am Ende ausgehen.
Gibt es ein Attribut mit dem ich das Verhalten bei Abbruch vor timespec_stop steuern kann?
Zitat von: willib am 23 November 2018, 11:28:36
Ich habe etwas den Faden verloren. Ich nutze das Modul zur Anwesenheitssimulation, wie viele Andere auch. Wenn ich zuhause bin wird die disableCond true. Das Funktioniert auch soweit. Wenn ich aber nach Hause komme und RandomTimer schon läuft schaltet er mir irgendwann das Licht aus. keepDeviceAlive wäre hier richtig. Wenn ich aber abwesend bin sollen die Lichter natürlich am Ende ausgehen.
Gibt es ein Attribut mit dem ich das Verhalten bei Abbruch vor timespec_stop steuern kann?
Moin,
das kann ich bestätigen, und wollte deswegen auch schon fragen.
Es dauert gewühlt "Stunden" bis der RandonTimer erkennt, das die "disableCond = true" ist. Reagiert der RT nicht auf "Events" ?
Weil ich sehe, das der RT immer noch aktiv ist.
Soweit ich das in Erinnerung habe und das war auch der Grund wieso ich mich nach einer anderen Lösung (DOIFs) umgesehen habe, läuft der Timer im Hintergrund (einmalig) weiter. Betritt man also das Haus, so weiß es das Modul auch. Aber der bereits gestartete Timer wird zu Ende gelaufen. So kann es sein, dass erst nach 15-30min eine Ein-oder Ausschaltung durchgeführt wird. Und das obwohl man die Leuchte gerade wieder so eingestellt hat, wie man es denn gerne hätte.
AFAIK konnte man das ziemlich leicht fixen - hatte aber auch irgendwelche Nachteile: siehe https://forum.fhem.de/index.php/topic,14010.msg522558.html#msg522558
Nachtrag: "disableCond" und mein Vorgehen mit "disable" verhalten sich hier identisch.
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_RandomTimer.pm#L308
Danke für den Hinweis auf deine Alternative per DOIF. Gibt es da eventuell einen aktuellen codeschnipsel?
Wird denn das RT Modul noch weiter entwickelt?
Wenn ja, darf ich dann als Feature request vorschlagen, dass eine Unterscheidung zwischen Ende des RT Zeitintervalls und Abbruch des RT eingeführt wird? Sodass man per Attribut einstellen kann was bei Abbruch des Timers passiert. Oder zumindest dass ein Abbruch keine weiteren Schaltvorgänge auslöst.
Der ursprüngliche Entwickler ist verstorben.
igami betreut das Modul nun als Maintainer.
Mal schauen, was er sagt. Mir wäre eine ordentliche Lösung im RT-Modul auch lieber.
Zitat von: willib am 26 November 2018, 13:39:48
Danke für den Hinweis auf deine Alternative per DOIF. Gibt es da eventuell einen aktuellen codeschnipsel?
Wird denn das RT Modul noch weiter entwickelt?
Wenn ja, darf ich dann als Feature request vorschlagen, dass eine Unterscheidung zwischen Ende des RT Zeitintervalls und Abbruch des RT eingeführt wird? Sodass man per Attribut einstellen kann was bei Abbruch des Timers passiert. Oder zumindest dass ein Abbruch keine weiteren Schaltvorgänge auslöst.
Hätte gerne auch eine Fallunterscheidung zwischen Timer-Ablauf und Heimkehr bei aktivem Timer, habe daher mal selbst Hand angelegt. Sind meine ersten Schritte in Perl und fhem, bitte nicht schlagen wenn ich gegen irgendeine Etikette verstoße...
Im aktuellen Modul wird in beiden Fällen die gleiche Funktion durchlaufen, die abhängig vom Attribut "keepDeviceAlive" den Endzustand schaltet:
sub RandomTimer_down($) {
my ($hash) = @_;
$hash->{COMMAND} = AttrVal($hash->{NAME}, "keepDeviceAlive", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
}Ich habe daher ein neues Attribut und eine neue Funktion hinzugefügt:
sub RandomTimer_disableDown($) {
my ($hash) = @_;
my $disableState = AttrVal($hash->{NAME}, "disableState", 0);
if ($disableState != -1) {
Log3 $hash, 4, "[".$hash->{NAME}."]"." setting requested disableState on $hash->{DEVICE}: ";
$hash->{COMMAND} = AttrVal($hash->{NAME}, "disableState", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
} else {
Log3 $hash, 4, "[".$hash->{NAME}."]"." no action requested on $hash->{DEVICE}: ";
}
}Das Attribut heißt "disableState". Die Funktion wird nur in dem Fall durchlaufen, wenn bei aktivem Timer die DisableCondition eintritt. Ansonsten wird wie gehabt die alte Funktion ausgeführt, die das "keepDeviceActive" Attribut auswertet. So können beide Fälle unabhängig konfiguriert werden.
Logik ist wie derzeit bei "keepDeviceActive": 0 setzt das Device auf "off", 1 setzt das Device auf "on". Neu ist "-1", damit wird am Ende keine Aktion durchgeführt und das Device bleibt wie es gerade ist.
Funktioniert bei mir wie beschrieben und erfüllt meine Anforderung, vielleicht mag es ja noch jemand testen.
Huch, hier habe ich wohl ein paar Beiträge nicht mitbekommene, schaue ich mir nachher an.
Super! Das hat mir immer gefehlt. Wenn es keine Probleme damit gibt würde ich mich sehr freuen wenn das so eingecheckt wird. Ich habe es noch nicht getestet.
Mir ist bei der Gelegenheit noch aufgefallen, dass die Doku vom "keepDeviceAlive" Attribut nicht ganz passt.
ZitatThe keepDeviceAlive attribute changes the behavior. If set, the device status is not changed when the stoptime is reached.
Tatsächlich wird aber das Device immer aktiv auf den Zustand gesetzt, der per "keepDeviceAlive" vorgegeben ist wenn Stop-Time erreicht wird.
213 sub RandomTimer_down($) {
214 my ($hash) = @_;
215
216 $hash->{COMMAND} = AttrVal($hash->{NAME}, "keepDeviceAlive", 0) ? "on" : "off";
217 RandomTimer_device_switch($hash);
218 }Könnte man in der Dokumentation anpassen oder wie bei meinem Vorschlag oben die "-1" neu einführen und entsprechend dokumentieren.
Timer schaltet nicht aus, versteht nicht warum
List:
Internals:
COMMAND on
DEF *{sunset_abs()} Shelly2_OG_FL 22:30:00 300
DEVICE Shelly2_OG_FL
NAME ZufallsTimerFlur_OG
NR 1630
STATE on
TYPE RandomTimer
READINGS:
2018-12-14 00:05:30 Startzeit 2018-12-14 16:49:53
2018-12-14 00:05:30 Stoppzeit 2018-12-14 22:30:00
2018-12-11 06:41:30 TimeToSwitch 300
2018-12-14 19:05:35 active 1
2018-12-14 19:05:35 state on
TIMER:
ZufallsTimerFlur_OG_Exec:
HASH ZufallsTimerFlur_OG
MODIFIER Exec
NAME ZufallsTimerFlur_OG_Exec
ZufallsTimerFlur_OG_SetTimer:
HASH ZufallsTimerFlur_OG
MODIFIER SetTimer
NAME ZufallsTimerFlur_OG_SetTimer
helper:
REL
REP *
SIGMAWHENOFF 800
SIGMAWHENON 200
STARTTIME 14.12.2018 16:49:53
STOPTIME 14.12.2018 22:30:00
SWITCHMODE 800/200
S_REL
S_REP
TIMESPEC_START *{sunset_abs()}
TIMESPEC_STOP 22:30:00
TIMETOSWITCH 300
active 1
startTime 1544802593
stopTime 1544823000
Attributes:
offCmd set @ off 0
onCmd set @ on 0
room 10_Licht,60_Timer
switchmode 800/200
verbose 5
LOG:
2018.12.14 18:45:25.304 3: [ZufallsTimerFlur_OG] result of function Value(Shelly2_OG_FL) must be 'on' or 'off'
2018.12.14 18:45:25.304 4: [ZufallsTimerFlur_OG] IstZustand:OK sigmaWhen-OK:800 random:872<800=>false
2018.12.14 18:45:25.304 5: [ZufallsTimerFlur_OG] removing Timer: ZufallsTimerFlur_OG_Exec
2018.12.14 18:45:25.305 5: [ZufallsTimerFlur_OG] setting Timer: ZufallsTimerFlur_OG_Exec 2018-12-14 18:50:22
2018.12.14 18:50:22.310 3: [ZufallsTimerFlur_OG] result of function Value(Shelly2_OG_FL) must be 'on' or 'off'
2018.12.14 18:50:22.310 4: [ZufallsTimerFlur_OG] IstZustand:OK sigmaWhen-OK:800 random:469<800=>true
2018.12.14 18:50:22.310 4: [ZufallsTimerFlur_OG] command: set Shelly2_OG_FL on 0
2018.12.14 18:50:22.312 5: [ZufallsTimerFlur_OG] removing Timer: ZufallsTimerFlur_OG_Exec
2018.12.14 18:50:22.313 5: [ZufallsTimerFlur_OG] setting Timer: ZufallsTimerFlur_OG_Exec 2018-12-14 18:55:20
2018.12.14 18:55:20.316 3: [ZufallsTimerFlur_OG] result of function Value(Shelly2_OG_FL) must be 'on' or 'off'
2018.12.14 18:55:20.316 4: [ZufallsTimerFlur_OG] IstZustand:OK sigmaWhen-OK:800 random:632<800=>true
2018.12.14 18:55:20.316 4: [ZufallsTimerFlur_OG] command: set Shelly2_OG_FL on 0
2018.12.14 18:55:20.319 5: [ZufallsTimerFlur_OG] removing Timer: ZufallsTimerFlur_OG_Exec
2018.12.14 18:55:20.319 5: [ZufallsTimerFlur_OG] setting Timer: ZufallsTimerFlur_OG_Exec 2018-12-14 19:00:21
2018.12.14 19:00:21.322 3: [ZufallsTimerFlur_OG] result of function Value(Shelly2_OG_FL) must be 'on' or 'off'
2018.12.14 19:00:21.323 4: [ZufallsTimerFlur_OG] IstZustand:OK sigmaWhen-OK:800 random:367<800=>true
2018.12.14 19:00:21.323 4: [ZufallsTimerFlur_OG] command: set Shelly2_OG_FL on 0
2018.12.14 19:00:21.325 5: [ZufallsTimerFlur_OG] removing Timer: ZufallsTimerFlur_OG_Exec
2018.12.14 19:00:21.325 5: [ZufallsTimerFlur_OG] setting Timer: ZufallsTimerFlur_OG_Exec 2018-12-14 19:05:10
Was mache ich falsch
Schau mal in dein Log
2018.12.14 19:00:21.322 3: [ZufallsTimerFlur_OG] result of function Value(Shelly2_OG_FL) must be 'on' or 'off'Dazu die commandref:
ZitatValue() must evaluate one of the values "on" or "off". The behavior of devices that do not evaluate one of those values can be corrected by defining a stateFormat:
attr stateFormat EDIPlug_01 {(ReadingsVal("EDIPlug_01","state","nF") =~ m/(ON|on)/i) ? "on" : "off" }
if a devices Value() funktion does not evalute to on or off(like WLAN-Steckdose von Edimax) you get the message:
[EDIPlug] result of function Value(EDIPlug_01) must be 'on' or 'off'
Poste doch mal ein
list Shelly2_OG_FL
Hier
Internals:
DEF 192.168.15.79
DURATION 0
INTERVAL 60
MOVING stopped
NAME Shelly2_OG_FL
NR 1787
STATE OK
TCPIP 192.168.15.79:80
TYPE Shelly
Helper:
DBLOG:
relay_0:
DBLogging:
TIME 1544810978.64074
VALUE off
state:
DBLogging:
TIME 1544810988.55857
VALUE off 0
READINGS:
2018-11-24 15:46:22 cloud disabled
2018-12-11 06:41:33 config mode=relay=
2018-12-08 09:00:09 firmware v1.4.1
2018-12-14 08:55:39 network connected
2018-12-14 19:09:48 overpower_0 0
2018-11-24 15:46:22 overpower_1 0
2018-12-14 21:08:00 power 0
2018-12-14 19:09:48 relay_0 off
2018-11-24 15:46:22 relay_1 off
2018-12-14 19:09:48 state OK
Attributes:
DbLogInclude state,relay_0
comment shellyswitch-32B666
event-on-change-reading .*
mode relay
model shelly2
room 10_Licht,20_Obergeschoss,40_Schalter
webCmd on 0:off 0:on 1:off 1/code]
Hallo Otto,
Der Zufallstimer kommt offenbar mit dem mitgelieferten Kanal im Schaltbefehl "on 0" nicht zurecht. Abhilfe aus den 2 Kanälen mit readingsproxy 2 Device machen
Hi,
readingsproxy war das Stichwort! Damit geht es.
Hier für die Nachwelt wie es geht
defmod rP_shelly_OG_FL_0 readingsProxy Shelly2_OG_FL:relay_0
defmod ZufallsTimerFlur_OG RandomTimer *{sunset_abs()} rP_shelly_OG_FL_0 22:30:00 300
attr ZufallsTimerFlur_OG offCmd set Shelly2_OG_FL off 0
attr ZufallsTimerFlur_OG onCmd set Shelly2_OG_FL on 0
Hallo Zusammen
Zuerst einmal ein frohes neues Jahr ! ! !
Ich möchte mich auf diesem Weg auch mal herzlich für das aktiave Forum hier bedanken !
Nun zu meiner Frage :)
Ich möchte den RandomTimer einsetzen für eine Anwesenheitssimulation, dazu habe ich folgenden Code :
#Schlafzimmer
define ZufallsTimerSchlafzimmer RandomTimer *{sunset_abs()} Licht.Schlafzimmer *{sunset_abs(6*3600)} 600
attr ZufallsTimerSchlafzimmer room Anwesenheit
attr ZufallsTimerSchlafzimmer switchmode 800/200
#Kinderzimmer
define ZufallsTimerKinderzimmer RandomTimer *{sunset_abs()} Licht.Kinderzimmer *{sunset_abs(2*3600)} 600
attr ZufallsTimerKinderzimmer room Anwesenheit
attr ZufallsTimerKinderzimmer switchmode 800/200
Meine Fragen :
1) werden die beiden Lampen zur gleichen Zeit schalten oder nicht? Ich habe sämtliche Lampen so programiert und es wäre wohl eine nicht so tolle Simulation wenn alle Lichter zur gleichen Zeit schalten =)
2) Gibt es eine Möglichkeit mit einem "Knopf" (also ein State) in der Tablet UI Umgebeung die Simulation aktiv oder eben disable zu setzen? Ich habe diesbezüglich in diesem Beitrag einiges gefunden jedoch nichts übersichtliches. Danke für jeden Codeschnipsel =)
Besten Dank und nochmals ein frohes neues Jahr
Jonas
Hallo,
als Anfänger frag ich mich, ob ich nicht alle Timer irgendwie "neu starten" kann. Ein notify mit "shutdown restart" auf den Vacation Dummy scheint mir etwas übertrieben zu sein.
Wenn ich mittels notify die disableCond im Timer überschreibe, wird der Timer anscheinend neu geladen.
Gibt es alternativ das angepasste Modul mit dem zusätzlichen Attribut "disableState"? Einfach die Funktion ins Modul kopieren hat bei mir nichts bewirkt, obowhl ich das Attribute zu Liste hinzugefügt und auch gesetzt hatte.
LG
@astephan und jonas:
So ganz erschließen sich mir eure Frage nach dem disable nicht: Es gibt für jeden RandomTimer eine disableCond sowie ein disable-Attribut.
Wird das Attribut gesetzt, ist nichts aktiv, bis der RT wieder (vie Attribut) aktiviert wird, die disableCond wird immer zur Laufzeit ausgewertet (zu den angegebenen Schaltzeitpunkten). Man braucht also nichts neu zu laden, das passiert automatisch.
Man muß nur z.B. den Urlaubsdummy anders setzen.
Was die verschiedenen Zeiten angeht: Jedenfalls vom Start weg sind das erst mal dieselben Zeiten. Wie bei einem at sollte es aber möglich sein, einen Versatz mit rand() zu generieren.
Am besten mal austesten ;) .
Hallo Dietmar,
hast Du mir bitte nen Vorschlag wie ich realisieren kann dass die Random Schaltung z.B: nur Montags und Dienstags läuft?
Vielen Dank
Zitat von: Dietmar63 am 09 August 2013, 06:49:29
fhem.cfg
define ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch {abschaltZeit($we)} 480
99_utils
sub abschaltZeit ($) {
my ($we) = @_;
if ($we) {
return "22:00:00";
} else {
return "23:00:00";
}
}
Zitat von: onistuebchen am 30 Juli 2019, 22:31:01
Hallo Dietmar,
Dietmar wird dir leider nicht mehr antworten können, denn er ist vor einer Weile verstorben.
Zu deiner Frage: Die Wochentage finden sich in der Variable
$wday, beginnend mit 0 für Sonntag. Dort, wo in deinem bzw. Dietmars Beispiel auf
$we geprüft wird, solltest du auf
$wday 1 oder 2 prüfen.
Oder du nimmst ein DOIF.
Hallo,
das tut mir sehr leid.
Vielen Dank für den Tipp, ich werde das so umsetzen.
Hast du schon Zeit gehabt den Vorschlag von swenp zu prüfen?
Ich würde mich freuen wenn das so oder so ähnlich ins Modul aufgenommen würde.
Vielen Dank.
Zitat von: swenp am 13 Dezember 2018, 21:12:03
Hätte gerne auch eine Fallunterscheidung zwischen Timer-Ablauf und Heimkehr bei aktivem Timer, habe daher mal selbst Hand angelegt. Sind meine ersten Schritte in Perl und fhem, bitte nicht schlagen wenn ich gegen irgendeine Etikette verstoße...
Im aktuellen Modul wird in beiden Fällen die gleiche Funktion durchlaufen, die abhängig vom Attribut "keepDeviceAlive" den Endzustand schaltet:
sub RandomTimer_down($) {
my ($hash) = @_;
$hash->{COMMAND} = AttrVal($hash->{NAME}, "keepDeviceAlive", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
}
Ich habe daher ein neues Attribut und eine neue Funktion hinzugefügt:
sub RandomTimer_disableDown($) {
my ($hash) = @_;
my $disableState = AttrVal($hash->{NAME}, "disableState", 0);
if ($disableState != -1) {
Log3 $hash, 4, "[".$hash->{NAME}."]"." setting requested disableState on $hash->{DEVICE}: ";
$hash->{COMMAND} = AttrVal($hash->{NAME}, "disableState", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
} else {
Log3 $hash, 4, "[".$hash->{NAME}."]"." no action requested on $hash->{DEVICE}: ";
}
}
Das Attribut heißt "disableState". Die Funktion wird nur in dem Fall durchlaufen, wenn bei aktivem Timer die DisableCondition eintritt. Ansonsten wird wie gehabt die alte Funktion ausgeführt, die das "keepDeviceActive" Attribut auswertet. So können beide Fälle unabhängig konfiguriert werden.
Logik ist wie derzeit bei "keepDeviceActive": 0 setzt das Device auf "off", 1 setzt das Device auf "on". Neu ist "-1", damit wird am Ende keine Aktion durchgeführt und das Device bleibt wie es gerade ist.
Funktioniert bei mir wie beschrieben und erfüllt meine Anforderung, vielleicht mag es ja noch jemand testen.
Zitat von: willib am 15 August 2019, 13:48:05
Hast du schon Zeit gehabt den Vorschlag von swenp zu prüfen?
Ich würde mich freuen wenn das so oder so ähnlich ins Modul aufgenommen würde.
Vielen Dank.
...wer auch immer jetzt "du" ist...
Gerne schau' ich mir das mal vertretungsweise näher an, aber in dem Zusammenhang: ein kompletter Patch (optimal: einschl. cref) wäre nett, und ich habe auch noch nicht so ganz verstanden, warum man dann das Zusammenspiel beider Attribute benötigt. Wäre es nicht hinreichend, dort zwischen "nicht gesetzt" (=keepDeviceAlive verwenden wie bisher) und gesetzt (auf "on" oder "off") zu unterscheiden? Dabei kommt mit als Attributname aber eher sowas wie "leaveDisableCondCmd" in den Sinn.
Ich muß aber zugeben, dass ich im RandomTimer (Gründe: siehe u.A. oben) auch nur begrenzt drin bin und evtl. aus dem Grund den Text nicht ganz verstehe: einmal ist von Heimkehr die Rede (zu deuten wohl als Entfallen der disableCondition), unten steht dann, dass bei laufendem Timer die condition eintritt (was ich umgekehrt lesen würde).
Für eine kurze Klarstellung (der patch sollte das eigentlich schon hergeben...) wäre ich dankbar :) .
Hallo Beta-User,
ich meinte Igami der nach untem stehenden Post geschrieben hat er würde sich das anschauen.
Zitat von: swenp am 13 Dezember 2018, 21:12:03
Im aktuellen Modul wird in beiden Fällen die gleiche Funktion durchlaufen, die abhängig vom Attribut "keepDeviceAlive" den Endzustand schaltet:
sub RandomTimer_down($) {
my ($hash) = @_;
$hash->{COMMAND} = AttrVal($hash->{NAME}, "keepDeviceAlive", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
}
Ich habe daher ein neues Attribut und eine neue Funktion hinzugefügt:
sub RandomTimer_disableDown($) {
my ($hash) = @_;
my $disableState = AttrVal($hash->{NAME}, "disableState", 0);
if ($disableState != -1) {
Log3 $hash, 4, "[".$hash->{NAME}."]"." setting requested disableState on $hash->{DEVICE}: ";
$hash->{COMMAND} = AttrVal($hash->{NAME}, "disableState", 0) ? "on" : "off";
RandomTimer_device_switch($hash);
} else {
Log3 $hash, 4, "[".$hash->{NAME}."]"." no action requested on $hash->{DEVICE}: ";
}
}
Das Attribut heißt "disableState". Die Funktion wird nur in dem Fall durchlaufen, wenn bei aktivem Timer die DisableCondition eintritt. Ansonsten wird wie gehabt die alte Funktion ausgeführt, die das "keepDeviceActive" Attribut auswertet. So können beide Fälle unabhängig konfiguriert werden.
Logik ist wie derzeit bei "keepDeviceActive": 0 setzt das Device auf "off", 1 setzt das Device auf "on". Neu ist "-1", damit wird am Ende keine Aktion durchgeführt und das Device bleibt wie es gerade ist.
Funktioniert bei mir wie beschrieben und erfüllt meine Anforderung, vielleicht mag es ja noch jemand testen.
Es geht darum zwei Fälle zu unterscheiden:
1. die disable condition wird bei laufendem Timer wahr. (zb. Ich komme während der Anwesenheitssimulation nach hause) hier möchte ich unabhängig von keepdevicealive definieren was passieren soll. Ich möchte z.B. nicht dass bei erreichen von timespec_stop oder timeToSwitch dann noch Schaltvorgänge ausgeführt werden. Egal ob AN oder AUS.
2. die disable condition schaltet einfach wie ursprünglich geplant den Random Timer an und aus. (wenn ich zuhause bin soll die Anwesenheitsimulation nicht laufen) abweichend vom 1. Fall soll hier das attribut keepdevicealive greifen. In meinem Anwendungsfall wäre es allerdings nicht gesetzt, weil auch bei Anwesenheitssimulation nachts das licht aus sein soll.
Ich hoffe ich habe das einigermaßen verständlich beschrieben.
Ist das oben nicht schon ein patch? Ich kenne mich damit nicht aus, sorry.
Danke, dass du hier ein Auge drauf hast.
Ah, ok, ich hatte nicht weit genug zurückgeblättert, bei dem ursprünglichen Beitrag war auch die vollständige pm mit dabei....
igami scheint derzeit sehr beschäftigt zu sein, mal schauen, wann ich dazu komme, mir das mal näher zu vergegenwärtigen. Die Beschreibung (v.a. den 2. Fall) habe ich leider noch nicht ganz durchschaut, aber vielleicht wird das anhand des Codes klarer (Dietmar hatte manches aber in einer für mich manchmal sehr abstrakten Weise codiert).
Ich gehe davon aus, dass die Modulfassung, die swenp angehängt hatte, so funktioniert, wie du das haben willst?
Der 2. Fall ist einfach die Standardfunktionalität von Random timer.
Es sieht so aus als ob die Änderungen von Swenp bei mir funktioniert. Ob das aber an anderer Stelle Probleme machen könnte, kann ich nicht überblicken.
Danke.
So, anbei mal ein erster Wurf, das mit disableState (ich hadere immer noch mit dem Namen...) einzubauen in die aktuelle Modulfassung (war wegen der zwischenzeitlichen anderen Änderungen nicht ganz so übersichtlich, wie ich mir das gewünscht hätte).
So richtig geprüft auf Risiken, Nebenwirkungen und Stringenz ist das noch nicht, und auch eine cref war nicht bei dem Code dabei...
Vorab wäre es nett, wenn die beiden, die das derzeit nutzen, Rückmeldungen geben könnten, ob es so tut, wie sie sich das vorstellen; um den Rest würde ich mich dann später ggf. noch kümmern (Zuarbeit ist willkommen...).
Vielen Dank.
Ich hätte gedacht mit der neuen Funktion rennen Dir die Leute downloadmäßig die Bude ein. So kann man sich täuschen. Scheint wohl doch keiner zu benötigen.
Ich habe diene version installiert und teste.
Schönes Wochenende.
Scheint nicht sooo der Renner zu sein, aber trotzdem anbei nochmal eine überarbeitete Version samt commandref. In diesem Teil nicht intensiv getestet, sollte aber funktionieren.
Geändert habe ich jetzt: Attributname nach "disableCondCmd" geändert mit Wahlmöglichkeit für none, offCmd und onCmd. Das sollte m.E. "sprechender" sein.
Rückmeldung dazu samt der cref wären nett, sonst checke ich das irgendwann mal ein.
Gruß, Beta-User
Vielen Dank für deine Mühe. Das Modul habe ich noch nicht getestet.
Vieleicht kann man die Cref leichter verständlich machen indem man es etwas einkürzt:
In case the disable condition becomes true while a RandomTimer is already <b>running</b> it does the same as when stoptime is reached, by default (see corresponding attribute). The <b>disableCondCmd</b> attribute allows to change this behavior. Set to "none" will lead to no action, "offCmd" means "use off command", "onCmd" will lead to execution of the "on command". Delete the attribute to get back to default behaviour.<br>
Danke für die Rückmeldung, die cref war etwas auf die Schnelle entstanden. Hab's nochmal etwas geändert:
Zitat
<code>disableCondCmd</code><br>
In case the disable condition becomes true while a RandomTimer is already <b>running</b>, by default the same action is executed as when stoptime is reached (see keepDeviceAlive attribute). Setting the <b>disableCondCmd</b> attribute changes this as follows: "none" will lead to no action, "offCmd" means "use off command", "onCmd" will lead to execution of the "on command". Delete the attribute to get back to default behaviour.<br>
Viel Spaß+Erfolg beim testen.
Zur Info: Nachdem bisher keine Rückmeldung kam, dass das mit der disableCondCmd-Sache nicht ginge, habe ich das eben eingecheckt.
Grüße, Beta-User
Oh, das ist bei mir irgendwie untergegangen.
Und das ist auch das, was ich immer schon haben wollte.
Ich habe die RT-Logik per DOIF nachgebaut. Der Code ist jedoch wirklich unglücklich und schlecht zu warten. Daher freue ich mich nun über diese Lösung.
Ich probiere das gleich einmal aus.
Danke.
Nachtrag: Ich werde es leider doch nicht so schnell schaffen, denn ich habe jahrelang kein RZ mehr genutzt und muss nun erst einmal wieder eine Umgebung dafür schaffen. Insbesondere, wenn ich mit disableCond arbeiten möchte. Ich habe einfach zu viele Abhängigkeiten darin.
Ich muss feststellen, dass das neue Feature meine langjährigen Probleme mit dem RandomTimer leider nicht löst.
disableCondCmd kann zwar sehr praktisch sein, aber leider prüft der RandomTimer immer erst am Ende des Intervalls (aus dem DEF).
Mein Test-RT soll beim Unscharfschalten deaktiviert werden. Dies habe ich zu folgender Zeit gemacht:
2019-11-26_16:27:41
Im RT-Log ist jedoch erkennbar, dass noch das Intervall (300sec) abgewartet wurde mit dem Deaktivieren.
2019-11-26_16:27:07 testRandomTimer on
2019-11-26_16:31:52 testRandomTimer LastCommand: set testlampe off
disableCondCmd ist auf offCmd gesetzt.
@Beta-User: Wie war denn dein neues Feature ursprünglich geplant?
Hmm, ich habe an der Stelle auch nur ergänzt, was andere entwickelt und hier als sinnvolles feature vorgestellt hatten...
Grundsätzlich arbeitet RT timerbasiert, es wird also immer nur/erst zu den Umschaltzeitpunkten eine Auswertung gemacht.
Das könnte "man" vermutlich ändern, allerdings ist die disableCondition Perl, so dass ein "einfaches" Umstellen/Ergänzen mit/auf eine notifyfn nicht so einfach wäre bzw. nicht ohne ganz erheblichen Aufwand zu machen.
Würde es helfen, wenn man den RT anweisen könnte, die disableCondition - außerhalb der "normalen" (zufälligen) updates - neu zu prüfen und dann entsprechend zu schalten? Dann könnte man das über einen Event-Handler wie notify auslösen.
Habe aber noch nicht in den Code geschaut, ob das ein (für mich) lösbares Problem wäre.
(Aber ihr dürft gerne entsprechende patches liefern...)
Schuß ins Blaue (https://forum.fhem.de/Smileys/default/rolleyes.gif) (ich bin in dem RT-code auch nur bedingt drin...):
Wenn ich das richtig interpretiere, führt der RT zu jedem Schaltzeitpunkt immer denselben Code aus. Die beigefügte Modulvariante kennt einen Setter "execNow", mit dem man künstlich einen Schaltzeitpunkt "jetzt gleich" einfügen kann. Über Risiken und Nebenwirkungen, was sonst noch passiert, wenn man das macht, habe ich noch nicht intensiver nachgedacht, aber im Prinzip passiert dasselbe, wenn man ein "disable" aufhebt; das _sollte_ also gefahrlos sein.
Wer mag darf testen, wenn's funktioniert, checke ich das ein (cref fehlt noch; wenn man den setter nicht nutzt, sollte der jedenfalls keine Probleme mit vorhandenen Definitionen/Installationen machen...).
Rückmeldungen zur Benennung des setter sind auch willkommen, ich habe das spontan an "at" angelehnt, das könnte aber auch verwirrend sein.
Hallo FunkOdyssey
Für mich genügt das so. In meinem Szenario schaltet RT die Lampen für die Anwesenheitssimulation am Ende aus. Wird aber die Disable condition true wärend der Timer läuft, ich also nach Hause komme sollen die Lampen nicht mehr geschaltet werden. Wann RT die Lampen nicht schaltet ist in meinem Szenario egal. ;)
Du könntest disableCondCmd auf none stellen und die Lampe per notify ausschalten mit dem selben Event das deine disable condition auf true setzt.
Zitat von: Beta-User am 27 November 2019, 13:39:40
Schuß ins Blaue (https://forum.fhem.de/Smileys/default/rolleyes.gif) (ich bin in dem RT-code auch nur bedingt drin...):
Wenn ich das richtig interpretiere, führt der RT zu jedem Schaltzeitpunkt immer denselben Code aus. Die beigefügte Modulvariante kennt einen Setter "execNow", mit dem man künstlich einen Schaltzeitpunkt "jetzt gleich" einfügen kann. Über Risiken und Nebenwirkungen, was sonst noch passiert, wenn man das macht, habe ich noch nicht intensiver nachgedacht, aber im Prinzip passiert dasselbe, wenn man ein "disable" aufhebt; das _sollte_ also gefahrlos sein.
Wer mag darf testen, wenn's funktioniert, checke ich das ein (cref fehlt noch; wenn man den setter nicht nutzt, sollte der jedenfalls keine Probleme mit vorhandenen Definitionen/Installationen machen...).
Rückmeldungen zur Benennung des setter sind auch willkommen, ich habe das spontan an "at" angelehnt, das könnte aber auch verwirrend sein.
Direkt eingespielt. Danke für deine Mühe.
Das execNow führt zwar irgendetwas aus und ich sehe im Log "execNow" und "on". Aber es schaltet nicht aus.
Ich frage mich gerade, ob man dann nicht sogar besser ein "set RandomTimer disable" einführt und direkt den RT deaktiviert wie auch dann die disableCondCMD ausführt.
Irgendwie ist das Modul komisch. Vor allem, wenn man lange mit DOIF gearbeitet hat.
Patches würde ich gerne besteuern, aber das will keiner sehen. :-)
Zitat von: willib am 27 November 2019, 13:54:12
Hallo FunkOdyssey
Für mich genügt das so. In meinem Szenario schaltet RT die Lampen für die Anwesenheitssimulation am Ende aus. Wird aber die Disable condition true wärend der Timer läuft, ich also nach Hause komme sollen die Lampen nicht mehr geschaltet werden. Wann RT die Lampen nicht schaltet ist in meinem Szenario egal. ;)
Du könntest disableCondCmd auf none stellen und die Lampe per notify ausschalten mit dem selben Event das deine disable condition auf true setzt.
Wenn ich solche Abhängigkeiten wie Alarmzustände oder Residents habe, macht das vermutlich am meisten Sinn.
Ich denke aber, dass ich mit dem Zufallsgenerator beim DOIF bleibe. Mir ist das Ganze ein wenig zu instabil und unsicher.
Danke aber für deinen Tipp.
:)Hallo zusammen,
meine 7 Timer die während Abwesenheit laufen, werden durch ExecNow gezielt ausschalten.
Finde dieser Ergänzung sehr gut.
Internals:
COMMAND off
DEF {sunset(-1800,"16:30","23:59")} MiLight_Esszimmer {sunrise(600,"07:15","07:35")} 700
DEVICE MiLight_Esszimmer
FUUID 5dab68c6-f33f-0190-3ec2-c115df0c72b35bc9
FVERSION 98_RandomTimer.pm:0.205460/2019-11-20
NAME RND_Esszimmertisch
NR 327
STATE disabled
TYPE RandomTimer
READINGS:
2019-11-27 19:45:58 LastCommand set MiLight_Esszimmer off
2019-11-27 10:28:28 StartTime 2019-11-27 16:31:48
2019-11-27 10:28:28 StopTime 2019-11-28 07:34:59
2019-11-27 10:27:28 TimeToSwitch 700
2019-11-27 19:49:15 active 0
2019-11-27 19:49:15 state disabled
TIMER:
RND_Esszimmertisch_Exec:
HASH RND_Esszimmertisch
MODIFIER Exec
NAME RND_Esszimmertisch_Exec
RND_Esszimmertisch_SetTimer:
HASH RND_Esszimmertisch
MODIFIER SetTimer
NAME RND_Esszimmertisch_SetTimer
helper:
REL
REP
SIGMAWHENOFF 600
SIGMAWHENON 900
STARTTIME 27.11.2019 16:31:48
STOPTIME 28.11.2019 07:34:59
SWITCHMODE 600/900
S_REL
S_REP
TIMESPEC_START {sunset(-1800,"16:30","23:59")}
TIMESPEC_STOP {sunrise(600,"07:15","07:35")}
TIMETOSWITCH 700
active 0
startTime 1574868708
stopTime 1574922899
Attributes:
devStateIcon on:on-for-timer off:off
disableCond ( ReadingsVal("Home","modeAlarm","") eq "disarm")
disableCondCmd offCmd
offCmd set @ off
onCmd { fhem"set @ on;set @ command Weiss;set @ brightness 60";}
room Timer
switchmode 600/900
verbose 1
@cortmen:
Danke für's testen. Klingt danach, als könnte man das einchecken...
@FunkOdyssey:
Das Modul verstehen würde ich auch gerne, aber leider finde ich nirgends mehr das Handbuch zu der konkreten Hardware, die das Modul nachbildet (FS20 ZSU) ;D . Bisher habe ich das aber nur eher im Zusammenhang mit längerfristigen Abwesenheiten genutzt, da war das nicht sooo wichtig. (Und zum "Mit-Maintainer" bin ich nur geworden, weil ich die Abhängigkeiten von Twilight bei WDT und RT "in einem Rutsch" beseitigt hatte... ;D ;D ;D ).
Wie dem auch sei, wenn hier ein RT-eingearbeiteter User schreibt, dass das paßt, werde ich (vorerst) nicht über einen anderen Command nachdenken, der evtl. auch Sinn macht ::) .
@all: Wenn sich keiner mehr rechtzeitig wehrt, kommt das vermutlich (samt einer Ergänzung der cref) am WE ins svn.
Zitat von: Beta-User am 28 November 2019, 09:19:30
@cortmen:
Danke für's testen. Klingt danach, als könnte man das einchecken...
Kannst du dem Setter dann einen schöneren Namen geben? Danke dir.
Zitat von: FunkOdyssey am 28 November 2019, 09:21:22
Kannst du dem Setter dann einen schöneren Namen geben? Danke dir.
Vorschläge?
Der Name war nicht völlig willkürlich von at geborgt, auch die Funktion, die eigentlich ausgeführt wird, heißt (schon länger/im Prinzip afaik immer) RandomTimer_Exec($).
Der Effekt ist eben ein etwas anderer als (in der Regel) bei at, eben weil das Schaltergebnis - solange nicht die disable-Condition eingetreten ist - eben ein zufälliges ist (wie gewünscht). Erst bei wahrer cond. ist das Ergebnis eindeutig. (Im Prinzip wäre es bei at genauso, denn die Funktion, die von at aufgerufen wird, kann ja auch unterschiedliche Ergebnisse liefern, je nach Code eben. Allerdings dürften die meisten at eher klare (Ergebnis-) Anweisungen ausführen...
Wenn jemand was besseres einfällt: bin da leidenschaftslos...
:)Der jetzige Name passt gut.
Vorschlag für die cref zu ("execNow"):
This will force the RandomTimer device to immediately do the next switch and not wait untill timeToSwitch has passed. Use this in case you want immediate reaction on changes of reading values factored in disableCond. As RandomTimer itself will not be notified about any event at all, you'll need an additional event handler like notify that listens to relevant events and issues the "execNow" command towards your RandomTimer device(s).
:) Danke für die Modulunterstützung und ja der Text ist verständlich für die Aktion die geschaltet wird.
@cortman
Kannst du bitte mal an deinem Anwendungsfall erläutern wie du execNow verwendest. Mir ist die Funktion zusammen mit dem event handler nicht klar.
Würde mich übrigens auch interessieren.
Von der Anlage des Moduls her dürfte es in der Regel ein Presence-Indikator sein, der die Funktionalität An- und Abschaltet, und was dann gewollt sein dürfte, ist dass unmittelbar nach Eintritt der disable-Bedingung auch ein definierter Schaltzustand hergestellt wird.
Habe noch nie bewußt ein Eventhandler-Modul gabaut, aber evtl. ist es nicht soo schwierig, z.B. ein Presence-Device da als delayedExecutionDevice mit "ranzupappen".
Syntax wäre dann z.B. <device>:<readingname>:<disable-regex>:<enable-regex>.
Dann könnte man auf den externen Eventhandler verzichten, der dem RT sagt, er solle man die Bedingungen prüfen...
EDIT: Zur Info, die Änderung mit dem setter habe ich vorhin eingecheckt.
ZitatDirekt eingespielt. Danke für deine Mühe.
Das execNow führt zwar irgendetwas aus und ich sehe im Log "execNow" und "on". Aber es schaltet nicht aus.
Ich habe zum jetzigen Zeitpunkt keinen direkten Einsatz dafür.
Ich habe das Modul manuell geladen und einfach beim "Testen" geholfen.
?
Ich denke, du bist hier falsch... Hier geht es um RandomTimer, also was tendenziell zufälliges ;) .
Danke für den Hinweis, mein Frage ist hier falsch und deswegen gelöscht.
Zitat von: tfriedrich85 am 12 Dezember 2019, 11:24:45
Danke für den Hinweis, mein Frage ist hier falsch und deswegen gelöscht.
.... und damit alles aus dem Zusammenhang gerissen. Toll.
Hallo,
hat jemand schon Erfahrungen gesammelt wieich dem RadomTimer - Device eine Bedinung vom Modul Resients Modul (https://fhem.de/commandref_DE.html#RESIDENTS (https://fhem.de/commandref_DE.html#RESIDENTS)) mitgeben kann.
Ich möchte erreichen, dass Random Timer erst bei Residents = gone aktiv wird.
Vielen Dank
Schon mal mit disableCond versucht?
attr yourRandomTimer disableCond (ReadingsVal("Residents-Device","state","home") ne "gone")
Bitte auch sonst die cref mal lesen, v.a. dazu, was passieren soll, wenn du nach Hause kommst...
I use a notify to send push message when RandomTimer changes state. RandomTimer does not emit an event when the state changes directly to disabled, so it is not possible to detect disabled state.
Small patch with fix:
--- - 2019-12-16 10:26:46.488936657 +0100
+++ FHEM/98_RandomTimer.pm 2019-12-16 10:26:42.456856001 +0100
@@ -383,7 +383,7 @@
if (RandomTimer_isDisabled($hash)) {
#$hash->{STATE} = "disabled";
- readingsSingleUpdate ($hash, "state", "disabled", 0);
+ readingsSingleUpdate ($hash, "state", "disabled", 1);
} else {
my $state = $hash->{helper}{active} ? "on" : "off";
readingsSingleUpdate ($hash, "state", $state, 1);
Thanks for your suggestion.
Not sure about that, but imo, the trigger should only be issued once when state changes from "whateverelse" to "disabled". This would lead to something like
my $dotrigger = ReadingsVal($hash->{NAME},"state","none") ne "disabled" ? 1 : 0;
readingsSingleUpdate ($hash, "state", "disabled", $dotrigger);
Can you please provide some feedback on that?
Hallöchen,
zunächst mal Danke für das Modul. ;-)
Ich benutze es mit Dimmern, onCmd stellt auf einen pct-Wert... der STATE ist im dedimmten Zustand aber weder "on" noch "off", sondern auf dem pct-Wert. Alle diese Dimmer sagen aber "off", wenn sie aus sind.
Ich hab die Logik im Modul geändert, jeder STATE ungleich "off" wird als "on" gewertet. So muss ich nicht Hand an die Dimmer legen.
*** 98_RandomTimer.pm-org 2020-02-06 16:42:55.438935703 +0100
--- 98_RandomTimer.pm 2020-02-06 16:49:46.250435667 +0100
***************
*** 212,218 ****
my $status = Value($hash->{DEVICE});
if ($status ne "on" && $status ne "off" ) {
! Log3 $hash, 3, "[".$hash->{NAME}."]"." result of function Value($hash->{DEVICE}) must be 'on' or 'off'";
}
my $sigma = ($status eq "on")
--- 212,218 ----
my $status = Value($hash->{DEVICE});
if ($status ne "on" && $status ne "off" ) {
! Log3 $hash, 3, "[".$hash->{NAME}."]"." result of function Value($hash->{DEVICE}) neither 'on' nor 'off', assuming 'on'";
}
my $sigma = ($status eq "on")
***************
*** 223,229 ****
Log3 $hash, 4, "[".$hash->{NAME}."]"." IstZustand:$status sigmaWhen-$status:$sigma random:$zufall<$sigma=>" . (($zufall < $sigma)?"true":"false");
if ($zufall < $sigma ) {
! $hash->{COMMAND} = ($status eq "on") ? "off" : "on";
RandomTimer_device_switch($hash);
}
}
--- 223,229 ----
Log3 $hash, 4, "[".$hash->{NAME}."]"." IstZustand:$status sigmaWhen-$status:$sigma random:$zufall<$sigma=>" . (($zufall < $sigma)?"true":"false");
if ($zufall < $sigma ) {
! $hash->{COMMAND} = ($status ne "off") ? "off" : "on";
RandomTimer_device_switch($hash);
}
}
@Beta-User: Meines macht das generell Sinn?
Gruß
Diddle.
...auf die Schnelle würde ich sagen, dass man das heute insgesamt etwas anders lösen sollte...:
Konkret stört mich an dem Code die Value()-Abfrage, mAn. sollte man das gar nicht mehr nutzen, sondern auf ReadingsVal("...","state","off") abfragen, und dann eine case-insensitive regex nach "on" bzw. "off" machen. Ob man das dann wie vorgeschlagen dahin verstehen will, dass alles, was nicht "off" (bzw. off-for..., off-until...) ist, als "on" verstanden werden soll, sei mal dahingestellt.
Spontan würde ich dazu neigen, das so zu ergänzen, und dem RandomTimer dann noch ein Attribut zu spendieren, das _einen_ weiteren "Off"-Wert (als regex) zuläßt. Setzt man das, wird "off|OFF|off-till.." sowie regex-Matches als "off" akzeptiert, sonst nur "on"&Co.. Das Problem: "breaking change"...
Vielleicht gibt es weitere Meinungen dazu?
(Ein Schubs, wie man das ggf. "stressfrei im Übergang" hinbekäme, wäre auch nicht übel...!)
So, anbei eine Testversion...
Damit gibt es ein neue Attribut, das - sofern gesetzt - zwei Folgen hat: Es wird nicht mehr nach Value() geschaut, sondern nach ReadingsVal -> state, und man kann beliebige Werte einsetzen, so dass z.B. "dim0" auch als "off" verstanden wird, genauso wie "off", "off-for-timer ..." & Co, "Off" und "OFF". Alles andere ist dann "on".
Feedback ist willkommen, ich hab's bisher nur kurz angetestet.
Hi,
Zitat von: Beta-User am 11 Februar 2020, 15:11:30
Feedback ist willkommen, ich hab's bisher nur kurz angetestet.
vielen Dank... habs mal installiert und offState auf "off" gesetzt. Sollte damit genau das sein, was ich brauche. :-)
Ich melde mich.
Gruß
Diddle.
Zitat von: diddle am 06 Februar 2020, 16:56:37
der STATE ist im dedimmten Zustand aber weder "on" noch "off", sondern auf dem pct-Wert. Alle diese Dimmer sagen aber "off", wenn sie aus sind.
Kannst du ggf. auch mal posten, was das für Geräte sind (list/list -r im ausgeschalteten Zustand und gedimmt)? Würde mich interessieren, wie die mit dem Reading "state" umgehen...
@all: Die jetzige Implementierung sollte ohne "breaking change" auskommen, aber eigentlich halte ich den Rückgriff auf Value() für veraltet und würde das (für ab featurelevel 6.1 ?) gerne bei Gelegenheit auch so umbauen, dass generell das state-Reading der default wird.
Wäre also nett, wenn ihr nicht nur testet, ob es ggf. ohne das Attribut Probleme gibt, sondern auch mit checkt was passiert, wenn man keine Begleitmaßnahmen ergreift... Betrifft v.a. die User, die bisher stateFormat genutzt hatten, um einen "RandomTimer-konfirmen" STATE zu generieren.
Zitat von: Beta-User am 11 Februar 2020, 17:11:30
@all: Die jetzige Implementierung sollte ohne "breaking change" auskommen, aber eigentlich halte ich den Rückgriff auf Value() für veraltet und würde das (für ab featurelevel 6.1 ?) gerne bei Gelegenheit auch so umbauen, dass generell das state-Reading der default wird.
Da ich sowieso dabei war, anbei nochmal eine Testversion:
Stellt man global auf featurelevel 99.99, muß man nicht mal das Attribut setzen und es ist für alle RandomTimer direkt wirksam.
Falls bis dahin keine Probleme gemeldet werden, würde ich das in ca. 2 Wochen einchecken...
Zitat von: Beta-User am 11 Februar 2020, 17:11:30
Kannst du ggf. auch mal posten, was das für Geräte sind (list/list -r im ausgeschalteten Zustand und gedimmt)? Würde mich interessieren, wie die mit dem Reading "state" umgehen...
Gern.
Gedimmt
Internals:
DEF 1B51D201
FUUID 5cdae698-f33f-c16c-49a8-84225f8cc6fc3fa3
NAME sw_WzDeckenstrahler_Sw
NOTIFYDEV global
NR 173
NTFY_ORDER 50-sw_WzDeckenstrahler_Sw
STATE 18
TYPE CUL_HM
chanNo 01
device sw_WzDeckenstrahler
READINGS:
2020-02-12 17:29:37 CommandAccepted yes
2020-02-07 15:43:15 R-logicCombination or
2020-02-07 15:43:15 R-powerUpAction off
2020-02-07 15:43:15 RegL_01. 00:00 30:06 32:50 33:64 34:4B 35:50 56:00 57:24 59:01
2020-02-12 17:29:37 deviceMsg 18 (to cl_Wohnzimmer)
2020-02-12 17:29:37 dim stop:18
2020-02-12 17:29:37 level 18
2020-02-12 17:29:37 overheat off
2020-02-12 17:29:37 overload off
2020-02-12 17:29:37 pct 18
2020-02-12 17:29:37 phyLevel 18
2020-02-12 17:29:37 recentStateType info
2020-02-12 17:29:37 reduced off
2020-02-12 17:29:37 state 18
2020-02-12 17:29:37 timedOn off
2020-02-12 17:29:31 trigLast fhem:02
helper:
dlvlCmd ++A0110B117A1B51D20201240320FFFF
peerFriend peerSens,peerVirt
peerOpt 3:dimmer
regLst 1,3p
dir:
cur stop
rct up
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
vDim:
idPhy 1B51D201
idV2 1B51D202
idV3 1B51D203
Attributes:
alias Deckenstrahler
genericDeviceType light
group Licht
lightSceneParamsToSave pct
lightSceneRestoreOnlyIfChanged 1
model HM-LC-DIM1TPBU-FM
peerIDs 00000000,
realRoom Wohnzimmer
room Wohnzimmer,GoogleAssistant
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
webCmd on:off:pct
define sw_WzDeckenstrahler_Sw CUL_HM 1B51D201
attr sw_WzDeckenstrahler_Sw userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr sw_WzDeckenstrahler_Sw alias Deckenstrahler
attr sw_WzDeckenstrahler_Sw genericDeviceType light
attr sw_WzDeckenstrahler_Sw group Licht
attr sw_WzDeckenstrahler_Sw lightSceneParamsToSave pct
attr sw_WzDeckenstrahler_Sw lightSceneRestoreOnlyIfChanged 1
attr sw_WzDeckenstrahler_Sw model HM-LC-DIM1TPBU-FM
attr sw_WzDeckenstrahler_Sw peerIDs 00000000,
attr sw_WzDeckenstrahler_Sw realRoom Wohnzimmer
attr sw_WzDeckenstrahler_Sw room Wohnzimmer,GoogleAssistant
attr sw_WzDeckenstrahler_Sw webCmd on:off:pct
setstate sw_WzDeckenstrahler_Sw 18
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-fuseDelay 1 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-ovrTempLvl 80 C
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-redLvl 40 %
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-redTempLvl 75 C
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-statusInfoMinDly 2 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-statusInfoRandom 1 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-transmitTryMax 6
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .peerListRDate 2020-02-07 15:43:15
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 CommandAccepted yes
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 R-logicCombination or
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 R-powerUpAction off
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 RegL_01. 00:00 30:06 32:50 33:64 34:4B 35:50 56:00 57:24 59:01
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 deviceMsg 18 (to cl_Wohnzimmer)
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 dim stop:18
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 level 18
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 overheat off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 overload off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 pct 18
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 phyLevel 18
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 recentStateType info
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 reduced off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 state 18
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:37 timedOn off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 17:29:31 trigLast fhem:02
Und aus
Internals:
DEF 1B51D201
FUUID 5cdae698-f33f-c16c-49a8-84225f8cc6fc3fa3
NAME sw_WzDeckenstrahler_Sw
NOTIFYDEV global
NR 173
NTFY_ORDER 50-sw_WzDeckenstrahler_Sw
STATE off
TYPE CUL_HM
chanNo 01
device sw_WzDeckenstrahler
READINGS:
2020-02-12 22:40:43 CommandAccepted yes
2020-02-07 15:43:15 R-logicCombination or
2020-02-07 15:43:15 R-powerUpAction off
2020-02-07 15:43:15 RegL_01. 00:00 30:06 32:50 33:64 34:4B 35:50 56:00 57:24 59:01
2020-02-12 22:40:50 deviceMsg off (to cl_Wohnzimmer)
2020-02-12 22:40:50 dim stop:off
2020-02-12 22:40:50 level 0
2020-02-12 22:40:50 overheat off
2020-02-12 22:40:50 overload off
2020-02-12 22:40:50 pct 0
2020-02-12 22:40:50 phyLevel 0
2020-02-12 22:40:50 recentStateType info
2020-02-12 22:40:50 reduced off
2020-02-12 22:40:50 state off
2020-02-12 22:40:50 timedOn off
2020-02-12 22:40:43 trigLast fhem:02
helper:
dlvlCmd ++A0110B117A1B51D20201000000
peerFriend peerSens,peerVirt
peerOpt 3:dimmer
regLst 1,3p
dir:
cur stop
rct up
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
vDim:
idPhy 1B51D201
idV2 1B51D202
idV3 1B51D203
Attributes:
alias Deckenstrahler
genericDeviceType light
group Licht
lightSceneParamsToSave pct
lightSceneRestoreOnlyIfChanged 1
model HM-LC-DIM1TPBU-FM
peerIDs 00000000,
realRoom Wohnzimmer
room Wohnzimmer,GoogleAssistant
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
webCmd on:off:pct
define sw_WzDeckenstrahler_Sw CUL_HM 1B51D201
attr sw_WzDeckenstrahler_Sw userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr sw_WzDeckenstrahler_Sw alias Deckenstrahler
attr sw_WzDeckenstrahler_Sw genericDeviceType light
attr sw_WzDeckenstrahler_Sw group Licht
attr sw_WzDeckenstrahler_Sw lightSceneParamsToSave pct
attr sw_WzDeckenstrahler_Sw lightSceneRestoreOnlyIfChanged 1
attr sw_WzDeckenstrahler_Sw model HM-LC-DIM1TPBU-FM
attr sw_WzDeckenstrahler_Sw peerIDs 00000000,
attr sw_WzDeckenstrahler_Sw realRoom Wohnzimmer
attr sw_WzDeckenstrahler_Sw room Wohnzimmer,GoogleAssistant
attr sw_WzDeckenstrahler_Sw webCmd on:off:pct
setstate sw_WzDeckenstrahler_Sw off
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-fuseDelay 1 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-ovrTempLvl 80 C
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-redLvl 40 %
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-redTempLvl 75 C
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-statusInfoMinDly 2 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-statusInfoRandom 1 s
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .R-transmitTryMax 6
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 .peerListRDate 2020-02-07 15:43:15
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:43 CommandAccepted yes
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 R-logicCombination or
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 R-powerUpAction off
setstate sw_WzDeckenstrahler_Sw 2020-02-07 15:43:15 RegL_01. 00:00 30:06 32:50 33:64 34:4B 35:50 56:00 57:24 59:01
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 deviceMsg off (to cl_Wohnzimmer)
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 dim stop:off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 level 0
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 overheat off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 overload off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 pct 0
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 phyLevel 0
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 recentStateType info
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 reduced off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 state off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:50 timedOn off
setstate sw_WzDeckenstrahler_Sw 2020-02-12 22:40:43 trigLast fhem:02
Gruß
Diddle
Danke!
Also ganz normales CUL_HM-Verhalten...
Habe mir das grade mal angesehen, was eine HUE-Gruppe so macht. Scheint so, als würde es Sinn machen, das noch dahingehend zu erweitern, dass man statt state auch noch ein anderes Reading angeben können sollte, auf das sich die regex beziehen soll...
Konkret für HUEDevice (Gruppe@deCONZ) wäre das any_on. Muß wohl nochmal hirnen.
Guten Morgen,
danke, das Du Dich des Themas angenommen hast.
Ich nutze RandomTimer als Anwesenheitssimulation (Lichtsteuerung) während meiner Abwesenheit.
Dabei frage ich die Abwesenheit im Modul ab.
Wechselt nun der Status von Abwesend auf Anwesend, laufen die RandomTimer noch lange Zeit nach, d.h. die Lichtorgel im Haus bleibt an, was suboptimal ist. Ich behelfe mir damit, das ich von anderer Stelle die Abwesenheit überwache, und bei Statuswechsel auf Anwesend die RandomTimer "hart disable", das funktioniert, aber finde ich pers. "unschön"
Just my2cents
Hast du dir das Attribut disableCondCmd mal angesehen? Zusammen mit dem Attribut disableCond gibt es da keine Lichtorgel mehr.
Zitat von: willib am 13 Februar 2020, 08:53:23
Hast du dir das Attribut disableCondCmd mal angesehen? Zusammen mit dem Attribut disableCond gibt es da keine Lichtorgel mehr.
Yip, ist aktiv. Dennoch dauert es oft lange, bis der randomTimer beendet wird. Ich glaube, ich war/bin auch nicht der einzige hier im Forum mit diesem "Problem"
Hast du schon mal "execNow" getestet? Sollte die Lichtorgel eigentlich direkt beenden.
Habe zwar mal überlegt, ob man RT auch eine notify_fn spendieren sollte, aber je länger ich darüber nachdenke, desto weniger überzeugt bin ich... (unterstellt, dass execNow tut, was es soll ;) ).
Äh, nee, guter Hinweis. Danke. schaue ich mir an.
...dann viel Spaß beim ausprobieren...
Zum Rest:
Wer mag, kann auch gleich auf die aktuelle Testversion wechseln. Syntax für die HUE-Gruppe wäre:
attr ZufallUrlaubEZ2 offState 0 any_on
also: "<regex>[ <readingname>]" (Leerzeichen-separiert; die regex darf folglich kein Leerzeichen enthalten, <readingname> ist optional, wenn nicht angegeben: "state").
Bin noch unsicher, ob man zusätzlich "state" prüfen sollte, wenn <readingname> angegeben ist, denke aber tendenziell eher nicht.
Feedback ist willkommen, auch zur Attributbenennung. Das ist mir jetzt eigentlich zu "verkürzt" im Namen, aber auf die Schnelle habe ich grade auch nicht die durchschlagende Idee...
Zitat von: Bartimaus am 13 Februar 2020, 08:57:16
Yip, ist aktiv. Dennoch dauert es oft lange, bis der randomTimer beendet wird. Ich glaube, ich war/bin auch nicht der einzige hier im Forum mit diesem "Problem"
Darf ich nochmal fragen was da das Problem ist? Der Timer läuft ja nur bis zum nächsten Schaltzeitpunkt weiter, würde dann aber beendet und keinen Schaltvorgang mehr ausführen wenn disableCondCmd none gesetzt ist. Somit hört doch deine Lichtorgel in dem Moment auf wo disablecond true wird. Oder habe ich da was falsch verstanden?
muss hier auch mal eine Frage loswerden:defmod ZufallsTimerWC RandomTimer *{sunset_abs()} Shelly_1C 23:30:00 300
attr ZufallsTimerWC disableCond (Value("rgr_atHome") eq "home")
attr ZufallsTimerWC disableCondCmd offCmd
attr ZufallsTimerWC onCmd set @ on-for-timer 30
attr ZufallsTimerWC switchmode 300/300
setstate ZufallsTimerWC disabled
setstate ZufallsTimerWC 2020-02-16 20:16:07 LastCommand set Shelly_1C off
setstate ZufallsTimerWC 2020-02-21 12:28:18 StartTime 2020-02-21 18:05:19
setstate ZufallsTimerWC 2019-07-30 00:05:30 Startzeit 2019-07-30 21:36:06
setstate ZufallsTimerWC 2020-02-21 12:28:18 StopTime 2020-02-21 23:30:00
setstate ZufallsTimerWC 2019-07-30 00:05:30 Stoppzeit 2019-07-30 23:30:00
setstate ZufallsTimerWC 2020-02-21 12:27:32 TimeToSwitch 300
setstate ZufallsTimerWC 2020-02-21 12:28:18 active 0
setstate ZufallsTimerWC 2020-02-21 12:28:18 state disabled
Wir kommen mit Freunden heim, davon geht einer direkt auf das WC (indem offenbar das Licht noch brannte - plötzlich Geschrei, da das Licht von allein ausgegangen war).
Wie kann ich das abfangen?
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...
Zitat von: Beta-User am 21 Februar 2020, 16:13:38
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 ;D
Ich werde beobachten, ob das in Zukunft noch mal auftritt, aber Du hast es sicher richtig auf den Punkt gebracht.
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
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:
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):defmod Zufall1 RandomTimer *06:00 MYSENSOR_98 22:00:00 3600 :1800
Das ganze kann man selbstredend auch kombinieren:
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
Hallo Beta-User,
da hast Du aber schnell reagiert. Ich werde es die nächsten Tage testen und berichten.
Danke und GRuß
Roman
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.
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
Zitat von: FunkOdyssey am 16 März 2020, 20:54:01
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
Danke, ich habe mit dem Event Monitor ein für mich akzeptables Verhalten erzielt. Gruß Roman
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.
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...
Zitat von: det. am 19 März 2020, 21:07:29
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.
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
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
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:
defmod ZufallsTimerTisch RandomTimer *{sunset_abs()} StehlampeTisch "*{sunset_abs(3 * 3600)}" 480
--- - 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" );
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... ::)
Everything OK! Thanks.
...seems we generated a new problem by parseParams usage: https://forum.fhem.de/index.php/topic,114623.0.html
Will revert that back until we have found a backwards compatible solution.
Maybe parseparams() can be enhanced to allow timespec as a parameter?
This seems to fix the issue:
--- - 2020-09-29 20:22:43.000000000 +0200
+++ fhem.pl 2020-09-29 20:18:11.000000000 +0200
@@ -5824,7 +5824,7 @@
$key = undef;
# the key can not start with a { -> it must be a perl expression # vim:}
- } elsif( $key =~ m/^\s*{/ ) { # for vim: }
+ } elsif( $key =~ m/^\s*(\+|\*|\*\d+)?{/ ) { # for vim: }
$value = $param;
$key = undef;
}
Maybe, but imo this isn't the right place to suggest that kind of changes to Rudi (most likely dev corner should be the right place, so all the other maintainers could also give some feedback on possible side effects?).
In case if that's implemented in fhem.pl, we could reimplement your suggustion, but for the moment, the module code in svn is reverted more or less back to the previous version.
Zitatthis isn't the right place to suggest that kind of changes to Rudi
You probably should suggest this directly to justme1968, the author of the function.
I suspect that if I am "fixing" this function, it will break other things.
Tach zusammen, habe wahrscheinlich nur ein kl. Problem mit den RandomTimer.
Meine RandomTimer aktualisieren nicht die Starttime-/Stoptime im laufe der Nacht. (24Std)
Nach einen Neustart von fhem passt wieder alles für die nächsten 24 Std.
Siehe kurzes list:
Internals:
COMMAND
DEF {sunset("REAL",0,"16:22","16:30")} MiLight_Zone1 {sunrise("REAL",0,"07:55","08:10")} 600 180:240
DEVICE MiLight_Zone1
FUUID 5dab68c6-f33f-0190-3ec2-c115df0c72b35bc9
FVERSION 98_RandomTimer.pm:0.230300/2020-10-26
NAME RND_Esszimmertisch
NR 301
STATE disabled
TYPE RandomTimer
READINGS:
2021-01-15 08:10:05 LastCommand set MiLight_Zone1 off
2021-01-16 09:38:33 StartTime 2021-01-16 16:32:32
2021-01-16 09:38:33 StopTime 2021-01-17 08:09:59
2021-01-16 09:37:35 TimeToSwitch 600
2021-01-16 18:13:50 active 0
2021-01-16 18:13:50 state disabled
TIMER:
RND_Esszimmertisch_RT_Exec:
HASH RND_Esszimmertisch
MODIFIER RT_Exec
NAME RND_Esszimmertisch_RT_Exec
RND_Esszimmertisch_RT_SetTimer:
HASH RND_Esszimmertisch
MODIFIER RT_SetTimer
NAME RND_Esszimmertisch_RT_SetTimer
helper:
NEXT_CHECK 16.01.2021 18:24:07
REL
REP
SIGMAWHENOFF 750
SIGMAWHENON 900
STARTTIME 16.01.2021 16:32:32
STOPTIME 17.01.2021 08:09:59
SWITCHMODE 750/900
S_REL
TIMESPEC_START {sunset("REAL",0,"16:22","16:30")}
TIMESPEC_STOP {sunrise("REAL",0,"07:55","08:10")}
TIMETOSWITCH 600
VAR_DURATION 180
VAR_START 240
active 0
offReading state
offRegex .*off.*
startTime 1610811152
stopTime 1610867399
Attributes:
devStateIcon on:on-for-timer off:off
disableCond ( ReadingsVal("Home","modeAlarm","") eq "disarm")
disableCondCmd offCmd
offCmd set @ off
offState .*off.*
onCmd { fhem"set @ on;set @ command Weiss;set @ brightness 60";}
room Timer
switchmode 750/900
verbose 3
Für "wiederholend" braucht es einen Stern, oder?
:)Werde es mal testen, thnx
*{sunset("REAL",0,"16:22","16:30")} MiLight_Zone1 *{sunrise("REAL",0,"07:55","08:10")} 600 180:240
gibt es eine Möglichkeit, den Start bzw. die Ausführung noch von einer Bedingung abhängig zu machen?
*{sunset("REAL",1000,"16:00","23:00")} AnwSim 22:30:00 300
sprich der RandomTimer soll in meinem Fall nur starten, wenn ReadingsVal("Bewohner", "state", "absent") == "absent"
Das sollte über das Attribut "diableCond" zu lösen sein. Aber bitte möglichst mit "eq" statt "==" ;) .
gibts eigentlich das attribut switchmode noch? Ich hab den vor ewigen Zeiten mal damit aufgesetzt ?
Edit: Sorry, habs gesehen, gibts noch ;)
Na ja, ich habe zwar den kompletten Code renoviert und ein paar weitere Möglichkeiten vorgesehen, wie man den Zufall in geordnete Bahnen lenken kann, aber das Grundprinzip ist unverändert 8) .
Zumindest in der commandref ist daher auch switchmode noch zu finden, und es hat auch noch die ursprüngliche Funktion (hoffe ich jedenfalls ;D ).
Hallo,
ich habe bisher die RandomTimer bei Nichtverwendung per "attr disable 1" deaktiviert. disableCond verwende ich nicht. Nach dem Update hat das Attribut "disable" bei mir keine Wirkung mehr. Soll das so?
Danke! Gruß René
Sorry, da habe ich etwas zu viel weggeräumt ::) . Mit der jetzigen Version im svn sollte es wieder klappen.
Vielen Dank für die schnelle Hilfe !!! Geht wieder!