Autor Thema: RandomTimer - neues Modul  (Gelesen 144392 mal)

Offline cortmen

  • Full Member
  • ***
  • Beiträge: 111
Antw:RandomTimer - neues Modul
« Antwort #540 am: 28 November 2019, 10:48:41 »
 :)Der jetzige Name passt gut.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #541 am: 28 November 2019, 15:06:46 »
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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline cortmen

  • Full Member
  • ***
  • Beiträge: 111
Antw:RandomTimer - neues Modul
« Antwort #542 am: 28 November 2019, 17:04:51 »
 :) Danke für die Modulunterstützung und ja der Text ist verständlich für die Aktion die geschaltet wird.

Offline willib

  • Full Member
  • ***
  • Beiträge: 358
Antw:RandomTimer - neues Modul
« Antwort #543 am: 29 November 2019, 08:59:09 »
@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.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #544 am: 29 November 2019, 09:27:45 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline cortmen

  • Full Member
  • ***
  • Beiträge: 111
Antw:RandomTimer - neues Modul
« Antwort #545 am: 29 November 2019, 19:59:53 »
Zitat
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 habe zum jetzigen Zeitpunkt keinen direkten Einsatz dafür.
Ich habe das Modul manuell geladen und einfach beim "Testen" geholfen.


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #546 am: 12 Dezember 2019, 11:14:39 »
?
Ich denke, du bist hier falsch... Hier geht es um RandomTimer, also was tendenziell zufälliges ;) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline tfriedrich85

  • Full Member
  • ***
  • Beiträge: 102
Antw:RandomTimer - neues Modul
« Antwort #547 am: 12 Dezember 2019, 11:24:45 »
Danke für den Hinweis, mein Frage ist hier falsch und deswegen gelöscht.

Offline Wolle02

  • Full Member
  • ***
  • Beiträge: 286
Antw:RandomTimer - neues Modul
« Antwort #548 am: 12 Dezember 2019, 18:45:11 »
Danke für den Hinweis, mein Frage ist hier falsch und deswegen gelöscht.

.... und damit alles aus dem Zusammenhang gerissen. Toll.

Offline tfriedrich85

  • Full Member
  • ***
  • Beiträge: 102
Antw:RandomTimer - neues Modul
« Antwort #549 am: 18 Dezember 2019, 11:48:58 »
Hallo,

hat jemand schon Erfahrungen gesammelt wieich dem RadomTimer - Device eine Bedinung vom Modul Resients Modul (https://fhem.de/commandref_DE.html#RESIDENTS) mitgeben kann.
Ich möchte erreichen, dass Random Timer erst bei Residents = gone aktiv wird.

Vielen Dank

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #550 am: 18 Dezember 2019, 11:58:11 »
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Nestor

  • Developer
  • Jr. Member
  • ****
  • Beiträge: 74
Antw:RandomTimer - neues Modul
« Antwort #551 am: 21 Dezember 2019, 13:33:08 »
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);

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #552 am: 27 Dezember 2019, 15:58:51 »
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?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline diddle

  • New Member
  • *
  • Beiträge: 18
Antw:RandomTimer - neues Modul
« Antwort #553 am: 06 Februar 2020, 16:56:37 »
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9292
  • eigentlich eher "user" wie "developer"
Antw:RandomTimer - neues Modul
« Antwort #554 am: 06 Februar 2020, 17:24:31 »
...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...!)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

 

decade-submarginal