DOIF: Zeiten werden nicht nachvollziehbar getriggert

Begonnen von Ralli, 29 April 2015, 08:28:14

Vorheriges Thema - Nächstes Thema

Damian

Zitat von: flurin am 03 Mai 2015, 20:07:42
Ja, einfach ist das Problem nicht zu lösen. Einen Vorschlag habe ich noch:


define du_sunrise dummy



define GEN_RolloTimerHoch DOIF ([01:00])
  ({my $sr8 = sunrise_abs(int(780+rand(120)),"06:00","08:00");;
  fhem("setreading du_sunrise sr8 $sr8");;
  my $sr7 = sunrise_abs(int(780+rand(120)),"07:30","08:30");;
  fhem("setreading du_sunrise sr7 $sr7")})
DOELSEIF ([[du_sunrise:sr8]|8] or [[du_sunrise:sr7]|7])
  ({GenRolloSet("on")})
attr GEN_RolloTimerHoch do always


Gruss
flurin

Klar. Alles, was mehr ist als ein Einzeiler, ist schon zu viel für dieses simple Vorhaben.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

Zitat von: Damian am 03 Mai 2015, 20:39:35
Klar. Alles, was mehr ist als ein Einzeiler, ist schon zu viel für dieses simple Vorhaben.

Gruß

Damian

Ich finde diese Version gar nicht so schlimm:

define GEN_RolloTimerHoch DOIF ([+({sunrise_rel(+900,"06:00","08:00")}-int(rand(120)))|8] or [+({sunrise_rel(+900,"07:30","08:30")}-int(rand(120)))|7]) ({GenRolloSet("on")})

Es sind ja nur zwei (Plus-)Zeichen mehr gegenüber der ursprüngliche Version ;)

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ralli

Danke danke danke für Eure rege Beteiligung :).

Ich werde berichten.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

flurin

Zitat von: Damian am 03 Mai 2015, 20:47:06
Ich finde diese Version gar nicht so schlimm:

define GEN_RolloTimerHoch DOIF ([+({sunrise_rel(+900,"06:00","08:00")}-int(rand(120)))|8] or [+({sunrise_rel(+900,"07:30","08:30")}-int(rand(120)))|7]) ({GenRolloSet("on")})

Es sind ja nur zwei (Plus-)Zeichen mehr gegenüber der ursprüngliche Version ;)

Gruß

Damian

Ein echter Einzeiler ist für mich eine Zeile mit max 80-100 Zeichen  :)
Grundsätzlich versuche ich fhem.cfg zu "entlasten".

Der Perl-Code oberer Variante lässt sich einfach auslagern:


sub set_time($)
{
  my ($du_sunrise) = @_;
 
  my $offset = int(780+rand(120));
  my $sr_time;

  my @now = localtime;
 
  if ($now[6] == 0 or $now[6] == 6) {
    $sr_time = sunrise_abs($offset,"06:00","08:00");
  } else {
    $sr_time = sunrise_abs($offset,"07:30","08:30");
  }
  fhem("setreading $du_sunrise state $sr_time");
}


und dann kann man einen echten Einzeiler definieren:


define GEN_RolloTimerHoch DOIF ([01:00]) ({set_time("du_sunrise")}) DOELSEIF ([[du_sunrise]]) ({GenRolloSet("on")})


Gruss
flurin

Ralli

#19
Hallo,

jetzt ist ein anderes Problem aufgetreten: error: null is not allowed on a relative time bei timer2 - und das, obwohl das ganze jetzt schon zwei Tage lief. Und wenn ich die Definition ohne eine Änderung neu abspeichere, wird der Timer auch wieder korrekt berechnet.


Internals:
   DEF        ([+{sunrise_rel(+900)}]) ({FlRolloSet("on")}) DOELSEIF ([+({sunset_rel(-600,"18:00","22:00")}-int(rand(120)))]) ({FlRolloSet("off")})
   NAME       FL_RolloTimer
   NR         538
   NTFY_ORDER 50-FL_RolloTimer
   STATE      cmd_1
   TYPE       DOIF
   CHANGETIME:
   Helper:
     Dblog:
       Cmd_event:
         Eventlog:
           TIME       1430969517.38112
           VALUE      timer_1
       Cmd_nr:
         Eventlog:
           TIME       1430969517.38112
           VALUE      1
       State:
         Eventlog:
           TIME       1430969517.38112
           VALUE      cmd_1
   Readings:
     2015-05-07 05:31:57   cmd_event       timer_1
     2015-05-07 05:31:57   cmd_nr          1
     2015-05-07 05:31:57   state           cmd_1
     2015-05-07 05:31:57   timer_1_c1      08.05.2015 05:30:05
     2015-05-06 21:22:51   timer_2_c2      error: null is not allowed on a relative time
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
     1          DOIF_time_once($hash->{timer}{1},$wday,"")
   Days:
   Devices:
   Do:
     0          {FlRolloSet("on")}
     1          {FlRolloSet("off")}
   Helper:
     last_timer 2
     sleeptimer -1
   Internals:
   Itimer:
   Readings:
   Realtime:
     0          05:30:05
     1          00:00:00
   State:
   Time:
     0          +{sunrise_rel(+900)}
     1          +({sunset_rel(-600,"18:00","22:00")}-int(rand(120)))
   Timecond:
     0          0
     1          1
   Timer:
     0          0
     1          0
   Timerfunc:
   Timers:
     0           0
     1           1
Attributes:
   group      Timer
   room       System


Diese Fehlermeldung ist bei all meinen DOIF-Timern mit sunset_rel so aufgetreten und genau so nach Neu-Abspeichern auch nicht mehr da.

Edit:
Ich bin jetzt wieder von den relativen Timern zu absoluten Timern gewechselt und setze cmdpause 120 ein. Nach meinem Verständnis dürfte so vermieden werden, dass innerhalb von 2 Minuten das cmd mehr als einmal ausgeführt wird, wenn der Timer durch Neuberechnung erneut triggern sollte.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Damian

Zitat von: Ralli am 07 Mai 2015, 06:01:24
Hallo,

jetzt ist ein anderes Problem aufgetreten: error: null is not allowed on a relative time bei timer2 - und das, obwohl das ganze jetzt schon zwei Tage lief. Und wenn ich die Definition ohne eine Änderung neu abspeichere, wird der Timer auch wieder korrekt berechnet.


Internals:
   DEF        ([+{sunrise_rel(+900)}]) ({FlRolloSet("on")}) DOELSEIF ([+({sunset_rel(-600,"18:00","22:00")}-int(rand(120)))]) ({FlRolloSet("off")})
   NAME       FL_RolloTimer
   NR         538
   NTFY_ORDER 50-FL_RolloTimer
   STATE      cmd_1
   TYPE       DOIF
   CHANGETIME:
   Helper:
     Dblog:
       Cmd_event:
         Eventlog:
           TIME       1430969517.38112
           VALUE      timer_1
       Cmd_nr:
         Eventlog:
           TIME       1430969517.38112
           VALUE      1
       State:
         Eventlog:
           TIME       1430969517.38112
           VALUE      cmd_1
   Readings:
     2015-05-07 05:31:57   cmd_event       timer_1
     2015-05-07 05:31:57   cmd_nr          1
     2015-05-07 05:31:57   state           cmd_1
     2015-05-07 05:31:57   timer_1_c1      08.05.2015 05:30:05
     2015-05-06 21:22:51   timer_2_c2      error: null is not allowed on a relative time
   Condition:
     0          DOIF_time_once($hash->{timer}{0},$wday,"")
     1          DOIF_time_once($hash->{timer}{1},$wday,"")
   Days:
   Devices:
   Do:
     0          {FlRolloSet("on")}
     1          {FlRolloSet("off")}
   Helper:
     last_timer 2
     sleeptimer -1
   Internals:
   Itimer:
   Readings:
   Realtime:
     0          05:30:05
     1          00:00:00
   State:
   Time:
     0          +{sunrise_rel(+900)}
     1          +({sunset_rel(-600,"18:00","22:00")}-int(rand(120)))
   Timecond:
     0          0
     1          1
   Timer:
     0          0
     1          0
   Timerfunc:
   Timers:
     0           0
     1           1
Attributes:
   group      Timer
   room       System


Diese Fehlermeldung ist bei all meinen DOIF-Timern mit sunset_rel so aufgetreten und genau so nach Neu-Abspeichern auch nicht mehr da.

Edit:
Ich bin jetzt wieder von den relativen Timern zu absoluten Timern gewechselt und setze cmdpause 120 ein. Nach meinem Verständnis dürfte so vermieden werden, dass innerhalb von 2 Minuten das cmd mehr als einmal ausgeführt wird, wenn der Timer durch Neuberechnung erneut triggern sollte.
Ja, auch bei rel-Angaben gibt es das gleiche Problem. Jetzt werden die Tage länger, damit wird täglich der Sonnenuntergang einige Sekunden später berechnet. Bei rel-Angaben wird offenbar, wenn der nächste Zeitpunkt auch nur paar Sekunden später liegt nicht der nächste Tag (wie ich vermutet hatte) bestimmt, sondern offenbar wie bei abs der gleiche. Zusätzlich kann bei DOIF bei relativen Angaben 0 Sekunden durch die Berechnung herauskommen und das führt zur Meldung.

Da du jetzt aber sunrise und sunset in einem Modul hast, kannst du mit _abs-Funktionen arbeiten und do always, wie ich schon geschrieben habe, rausnehmen. Damit wird das doppelte Schalten automatisch vom DOIF-Modul unterbunden.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Ralli

Danke für Deine Rückmeldung.

Gibt es einen Unterschied zwischen sunset und sunset_abs bzw. sunrise und sunrise_abs?
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.83.6.20250705) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.4.1) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

Damian

Zitat von: Ralli am 07 Mai 2015, 12:09:45
Danke für Deine Rückmeldung.

Gibt es einen Unterschied zwischen sunset und sunset_abs bzw. sunrise und sunrise_abs?

Genaue Details zu den einzelnen Funktionen kenne ich auch nicht (nur das, was in der Commandref steht). Der Maintainer ist Rudolf König.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF