RandomTimer - neues Modul

Begonnen von Dietmar63, 28 Juli 2013, 15:52:40

Vorheriges Thema - Nächstes Thema

willib

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.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Beta-User

#526
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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

willib

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>
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FunkOdyssey

#530
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.

FunkOdyssey

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?

Beta-User

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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#533
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

willib

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.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

FunkOdyssey

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.

cortmen

#536
 :)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

Beta-User

@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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FunkOdyssey

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.

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files