RandomTimer - neues Modul

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

Vorheriges Thema - Nächstes Thema

Otto

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]
Gruss Otto

.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.

docker - homematic

det.

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
LG
det.

Otto

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
Gruss Otto

.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.

docker - homematic

jonas

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

astephanh

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

Beta-User

@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 ;) .
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

onistuebchen

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";
  }
}


Christoph Morrison

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

onistuebchen

Hallo,
das tut mir sehr leid.

Vielen Dank für den Tipp, ich werde das so umsetzen.




willib

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

Beta-User

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

Beta-User

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?
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

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

Beta-User

#524
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...).
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