DOIF und wait Problem doch nicht gelöst

Begonnen von antonwinden, 18 Mai 2016, 18:22:03

Vorheriges Thema - Nächstes Thema

antonwinden

Hab seit ein paar tagen das Problem das wait nicht mehr richtig funkioniert. folgendes ist definiert:
define regner3 DOIF (([[Beregnung3start]|[Beregnung1Tage:wtag]]) && [Beregnung3]eq"ein" && [heuteberegnet]<[Beregnungwieoft] && [Luftfeuchte:pulseTimePerDay] < 1800 &&  (ReadingsNum("WindstaerkeJT3","windkmh",3.5)<[BeregnungWindgrenze])&& ([NiederschlagJT3] eq "off")&&(ReadingsNum("AussentemperaturJT3","state",3.5) < [BeregnungTemeraturgrenzeoben]))(set PumpeBrunnenJT3 on)(set RasenToni on-for-timer [BeregnungDauer:dauer])(set RasenMitte on-for-timer [BeregnungDauer:dauer])(set RasenOtto on-for-timer [BeregnungDauer:dauer],set heuteberegnet {([heuteberegnet]+1)})(set PumpeBrunnenJT3 off)
attr regner3 wait 0,0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]

Die ersten 2 Befehle von wait werden ausgeführt - Nummer 3,4,5 werden nicht mehr ausgeführt.
Folgendes funktioniert aber fast ganz:
define regnesofort DOIF ([Beregnung_sofort]eq "beregne")(set PumpeBrunnenJT3 on)(set RasenToni on-for-timer [BeregnungDauer:dauer])\
(set RasenMitte on-for-timer [BeregnungDauer:dauer])(set RasenOtto on-for-timer [BeregnungDauer:dauer])(set Beregnung_sofort aus)(set PumpeBrunnenJT3 off)
attr regnesofort do always
attr regnesofort wait 0,0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer],0,0

Hier geht komischerweise alles bis auf das letzte (set PumpeBrunnenJT3 off) - das wird nicht ausgeführt.
Wo liegt mein Fehler?
danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Per

Wo der Fehler beim zweiten liegt, weiss ich nicht, denn selftrigger hast du ja nicht aktiviert.
Aber mit (set PumpeBrunnenJT3 off,set Beregnung_sofort aus) unterbindest du das sicher.
Was sagt denn das List? Werden zwischendurch Timer angezeigt? Gibt es Fehlermeldungen? Ändern sich die Eingangsbedingungen (weil der Rasensprenger den Regensenor trifft)?
Und allgemein: statt wait 0,0 und (BefehlA)(BefehlB) ist wait 0 und (BefehlA,BefehlB) besser. Erzeugt weniger Last.

antonwinden

#2
Anscheinend hab ich das Problem jetzt durch das zusammenfasse der befehle gelöst. damit hab ich nur noch
attr regnerx wait 0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]
und damit ist es dann fehlerfrei durchgelaufen. Bedingungen waren nicht der Grund da die sich außer Windstärke nicht geändert haben.
nachdem diese lösung auch die last vermindert...
danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

antonwinden

hab mich zu früh gefreut. ein list ergibt:
Internals:
   DEF        (([[Beregnung4start]|[Beregnung1Tage:wtag]]) && [Beregnung4]eq"ein" && [heuteberegnet]<[Beregnungwieoft] && [Luftfeuchte:pulseTimePerDay] < 1800 &&  ([WindstaerkeJT3:windkmh:d]<[BeregnungWindgrenze])&& ([NiederschlagJT3] eq "off")&&([AussentemperaturJT3:state:d] < [BeregnungTemeraturgrenzeoben]))(set PumpeBrunnenJT3 on, set RasenToni on-for-timer [BeregnungDauer:dauer])(set RasenMitte on-for-timer [BeregnungDauer:dauer])(set RasenOtto on-for-timer [BeregnungDauer:dauer],set heuteberegnet {([heuteberegnet]+1)})(set PumpeBrunnenJT3 off)
   NAME       regner4
   NR         116
   NTFY_ORDER 50-regner4
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2016-05-19 17:00:00   Device          Luftfeuchte
     2016-05-19 16:57:56   cmd             2
     2016-05-19 16:57:56   cmd_event       WindstaerkeJT3
     2016-05-19 16:57:56   cmd_nr          2
     2016-05-19 16:48:52   e_AussentemperaturJT3_state 24.00 &deg;C
     2016-05-19 16:50:40   e_BeregnungTemeraturgrenzeoben_STATE 32
     2016-05-19 16:50:36   e_BeregnungWindgrenze_STATE 9
     2016-05-19 16:50:46   e_Beregnungwieoft_STATE 2
     2016-05-19 17:00:00   e_Luftfeuchte_pulseTimePerDay 0
     2016-05-19 16:57:56   e_WindstaerkeJT3_windkmh 1.1 km/h
     2016-05-19 08:36:00   e_heuteberegnet_STATE 1
     2016-05-19 16:57:56   state           cmd_2
     2016-05-19 16:55:00   timer_1_c1      20.05.2016 16:55:00|[Beregnung1Tage:wtag]
     2016-05-19 16:57:56   wait_timer      no timer
   Condition:
     0          (DOIF_time_once($hash,$hash->{timer}{0},$wday,"[Beregnung1Tage:wtag]")) && InternalDoIf($hash,'Beregnung4','STATE','','',AttrVal($hash->{NAME},'notexist',undef))eq"ein" && InternalDoIf($hash,'heuteberegnet','STATE','','',AttrVal($hash->{NAME},'notexist',undef))<InternalDoIf($hash,'Beregnungwieoft','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) && ReadingValDoIf($hash,'Luftfeuchte','pulseTimePerDay','','',AttrVal($hash->{NAME},'notexist',undef)) < 1800 &&  (ReadingValDoIf($hash,'WindstaerkeJT3','windkmh','(-?\d+(\.\d+)?)','',AttrVal($hash->{NAME},'notexist',undef))<InternalDoIf($hash,'BeregnungWindgrenze','STATE','','',AttrVal($hash->{NAME},'notexist',undef)))&& (InternalDoIf($hash,'NiederschlagJT3','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "off")&&(ReadingValDoIf($hash,'AussentemperaturJT3','state','(-?\d+(\.\d+)?)','',AttrVal($hash->{NAME},'notexist',undef)) < InternalDoIf($hash,'BeregnungTemeraturgrenzeoben','STATE','','',AttrVal($hash->{NAME},'notexist',undef)))
   Days:
     0          [Beregnung1Tage:wtag]
   Devices:
     0           Beregnung4 heuteberegnet Beregnungwieoft Luftfeuchte WindstaerkeJT3 BeregnungWindgrenze NiederschlagJT3 AussentemperaturJT3 BeregnungTemeraturgrenzeoben
     all         Beregnung4 heuteberegnet Beregnungwieoft Luftfeuchte WindstaerkeJT3 BeregnungWindgrenze NiederschlagJT3 AussentemperaturJT3 BeregnungTemeraturgrenzeoben
   Do:
     0:
       0          set PumpeBrunnenJT3 on, set RasenToni on-for-timer [BeregnungDauer:dauer]
       1          set RasenMitte on-for-timer [BeregnungDauer:dauer]
       2          set RasenOtto on-for-timer [BeregnungDauer:dauer],set heuteberegnet {([heuteberegnet]+1)}
       3          set PumpeBrunnenJT3 off
     1:
   Helper:
     event      tickHour: 70
     globalinit 1
     last_timer 1
     sleepdevice timer_1
     sleepsubtimer 1
     sleeptimer -1
     timerdev   Luftfeuchte
     timerevent tickHour: 70
     triggerDev Luftfeuchte
     timerevents:
       tickHour: 70
     timereventsState:
       tickHour: 70
     triggerEvents:
       tickHour: 70
     triggerEventsState:
       tickHour: 70
   Internals:
     0           Beregnung4:STATE heuteberegnet:STATE Beregnungwieoft:STATE BeregnungWindgrenze:STATE NiederschlagJT3:STATE BeregnungTemeraturgrenzeoben:STATE
     all         Beregnung4:STATE heuteberegnet:STATE Beregnungwieoft:STATE BeregnungWindgrenze:STATE NiederschlagJT3:STATE BeregnungTemeraturgrenzeoben:STATE
   Interval:
   Itimer:
     all         Beregnung4start
   Localtime:
     0          1463756100
   Readings:
     0           Luftfeuchte:pulseTimePerDay WindstaerkeJT3:windkmh AussentemperaturJT3:state
     all         Luftfeuchte:pulseTimePerDay WindstaerkeJT3:windkmh AussentemperaturJT3:state
   Realtime:
     0          16:55:00
   Regexp:
     0:
     All:
   State:
   Time:
     0          [Beregnung4start]
   Timecond:
     0          0
   Timer:
     0          0
   Timers:
     0           0
   Trigger:
   Triggertime:
     1463756100:
       localtime  1463756100
       Hash:
Attributes:
   wait       0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]

ich lese das so das die Bedingungen alle erfüllt sind damit ein timer mit der Dauer von 900 (wert von BregnungDauer:dauer) gestartet werden soll aber er wird nicht gestartet.
Das einzige was ich geändert habe ist das umstellen von ReadingsNum("xy"....)  auf [xy:state:d]  damit es nicht so ewig lang ist.
Diese Version läuft:
Internals:
   DEF        (([[Beregnung3start]|[Beregnung1Tage:wtag]]) && [Beregnung3]eq"ein" && [heuteberegnet]<[Beregnungwieoft] && ReadingsNum("Luftfeuchte","pulseTimePerDay",12) < 1800 &&  (ReadingsNum("WindstaerkeJT3","windkmh",3.2) < [BeregnungWindgrenze])&& ([NiederschlagJT3] eq "off")&&(ReadingsNum("AussentemperaturJT3","state",3.2) < [BeregnungTemeraturgrenzeoben]))(set PumpeBrunnenJT3 on,set RasenToni on-for-timer [BeregnungDauer:dauer])(set RasenMitte on-for-timer [BeregnungDauer:dauer])(set RasenOtto on-for-timer [BeregnungDauer:dauer],set heuteberegnet {([heuteberegnet]+1)})(set PumpeBrunnenJT3 off)
   NAME       regner3
   NR         105
   NTFY_ORDER 50-regner3
   STATE      cmd_1_2
   TYPE       DOIF
   Readings:
     2016-05-19 17:14:07   Device          Beregnung3
     2016-05-19 17:17:00   cmd             1.2
     2016-05-19 17:17:00   cmd_event       timer_1
     2016-05-19 17:17:00   cmd_nr          1
     2016-05-19 17:17:00   cmd_seqnr       2
     2016-05-19 17:14:07   e_Beregnung3_STATE ein
     2016-05-19 17:17:00   state           cmd_1_2
     2016-05-19 17:15:00   timer_1_c1      20.05.2016 17:15:00|[Beregnung1Tage:wtag]
     2016-05-19 17:17:00   wait_timer      19.05.2016 17:19:00 cmd_1_3 timer_1
   Condition:
     0          (DOIF_time_once($hash,$hash->{timer}{0},$wday,"[Beregnung1Tage:wtag]")) && InternalDoIf($hash,'Beregnung3','STATE','','',AttrVal($hash->{NAME},'notexist',undef))eq"ein" && InternalDoIf($hash,'heuteberegnet','STATE','','',AttrVal($hash->{NAME},'notexist',undef))<InternalDoIf($hash,'Beregnungwieoft','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) && ReadingsNum("Luftfeuchte","pulseTimePerDay",12) < 1800 &&  (ReadingsNum("WindstaerkeJT3","windkmh",3.2) < InternalDoIf($hash,'BeregnungWindgrenze','STATE','','',AttrVal($hash->{NAME},'notexist',undef)))&& (InternalDoIf($hash,'NiederschlagJT3','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "off")&&(ReadingsNum("AussentemperaturJT3","state",3.2) < InternalDoIf($hash,'BeregnungTemeraturgrenzeoben','STATE','','',AttrVal($hash->{NAME},'notexist',undef)))
   Days:
     0          [Beregnung1Tage:wtag]
   Devices:
     0           Beregnung3 heuteberegnet Beregnungwieoft BeregnungWindgrenze NiederschlagJT3 BeregnungTemeraturgrenzeoben
     all         Beregnung3 heuteberegnet Beregnungwieoft BeregnungWindgrenze NiederschlagJT3 BeregnungTemeraturgrenzeoben
   Do:
     0:
       0          set PumpeBrunnenJT3 on,set RasenToni on-for-timer [BeregnungDauer:dauer]
       1          set RasenMitte on-for-timer [BeregnungDauer:dauer]
       2          set RasenOtto on-for-timer [BeregnungDauer:dauer],set heuteberegnet {([heuteberegnet]+1)}
       3          set PumpeBrunnenJT3 off
     1:
   Helper:
     event      timer_1
     globalinit 1
     last_timer 1
     sleepdevice timer_1
     sleepsubtimer 2
     sleeptimer 0
     timerdev
     timerevent timer_1
     triggerDev
     timerevents:
       timer_1
     timereventsState:
       state: ein
     triggerEvents:
       timer_1
     triggerEventsState:
       state: ein
   Internals:
     0           Beregnung3:STATE heuteberegnet:STATE Beregnungwieoft:STATE BeregnungWindgrenze:STATE NiederschlagJT3:STATE BeregnungTemeraturgrenzeoben:STATE
     all         Beregnung3:STATE heuteberegnet:STATE Beregnungwieoft:STATE BeregnungWindgrenze:STATE NiederschlagJT3:STATE BeregnungTemeraturgrenzeoben:STATE
   Interval:
   Itimer:
     all         Beregnung3start
   Localtime:
     0          1463757300
   Readings:
   Realtime:
     0          17:15:00
   Regexp:
     0:
     All:
   State:
   Time:
     0          [Beregnung3start]
   Timecond:
     0          0
   Timer:
     0          0
   Timers:
     0           0
   Trigger:
   Triggertime:
     1463757300:
       localtime  1463757300
       Hash:
Attributes:
   wait       0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]

Kann es sein das ich immer einen postfix für das format verwenden muß wenn ich einmal damit in einem DOIF damit angefangen habe? -> soll heißen wenn ich [xy:test:d] hernehme muß ich das auch so im wait angeben?
gruß anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Per

Der Unterschied zwischen ReadingsVal(Wert) und [Wert] ist der Auslösetrigger, wenn du [?Wert] statt [Wert] verwendest, reagierst du auf keinen.

antonwinden

es wird ja reagiert - soll heißen die aktion wird ausgelöst allerdings nur die 1. und die nachfolgenden die mit einem wait versehen sind werden nicht ausgelöst. es wird auch kein waittimer gesetzt.
und wenn ich ReadingsNum nehme werden alle aktionen mit den richtigen wait werten genommen.
also an der auslösung bzw abfrage der bedingungen liegt es nicht denn die finden ja richtig statt...
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Damian

Zitat von: antonwinden am 20 Mai 2016, 08:23:49
es wird ja reagiert - soll heißen die aktion wird ausgelöst allerdings nur die 1. und die nachfolgenden die mit einem wait versehen sind werden nicht ausgelöst. es wird auch kein waittimer gesetzt.
und wenn ich ReadingsNum nehme werden alle aktionen mit den richtigen wait werten genommen.
also an der auslösung bzw abfrage der bedingungen liegt es nicht denn die finden ja richtig statt...


[?mydevice:myreading:d] und ReadingsNum("mydevice","myreading"...) sollten sie gleich verhalten. Der Unterschied ist, dass man beim ReadingsNum einen Default-Wert angibt.

Wenn sich dein DOIF anders verhält, dann wahrscheinlich, weil die angegebenen Readings nicht existieren oder anders vorbelegt sind.

Du kannst pro DOIF einen Defaultwert mit dem Attribut notexist definieren.

Gruß

Damian


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

antonwinden

jetzt verstehe ich aber bahnhof...
das doif prüft die bedingungen und springt auch in die 1.Anweisung allerdings wird die 2., 3. und die restlichen die mit
attr xy wait 0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]

eben mit einer wartezeit verknüpft sind nur bei ReadingsNum ausgeführt aber bei der variante ohne ReadingsNum wird nur die 1. aber die restlichen eben nicht mehr.
egal ich bleib bei der variante die bei mir funktioniert und spiel mich nicht mehr herum.
danke anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Damian

Zitat von: antonwinden am 20 Mai 2016, 09:20:52
jetzt verstehe ich aber bahnhof...
das doif prüft die bedingungen und springt auch in die 1.Anweisung allerdings wird die 2., 3. und die restlichen die mit
attr xy wait 0,[BeregnungDauer:dauer],[BeregnungDauer:dauer],[BeregnungDauer:dauer]

eben mit einer wartezeit verknüpft sind nur bei ReadingsNum ausgeführt aber bei der variante ohne ReadingsNum wird nur die 1. aber die restlichen eben nicht mehr.
egal ich bleib bei der variante die bei mir funktioniert und spiel mich nicht mehr herum.
danke anton

Naja du hast zuerst angegeben:

[Luftfeuchte:pulseTimePerDay] < 1800

das ist aber nicht das Gleiche wie ReadingsNum - das haben wir versucht dir zu erklären. Das Gleiche wäre eben:

[?Luftfeuchte:pulseTimePerDay:d] < 1800





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

antonwinden

#9
muß ich also wenn ein reading sowieso nur zahlen enthält wie eben pulsetimerperday auch das :d anhängen? dachte das ist nicht notwendig nachdem beide korrekt ausgeführt werden und es ist mir auch nicht klar warum das eine auswirkung auf die wait funktion haben soll...
eigentlich hab ich das in diesem fall nur der vollständigkeit halber dran gehängt und um es noch einmal zu sagen:
beide versionen lösen aus also liegt es nicht am überprüfen der bedingungen denn das geht ja allerdings wird bei der einen nur das 1. kommando ausgeführt und die folgenden unterschlagen (sieht man auch daran das kein waittimervorhanden ist) und bei readingsnum werden alle kommandos mit dem korrekten wait timern ausgelöst...
aber wie geschrieben bleib ich dann einfach bei der readingsnum variante...

ich wollte eigentlich nur die ganzen warnungen aus dem log haben denn es funkt auch mit readingsval also hab ich readingsnum gesehen. danach hab ich auch die variante in doif mit [xy:xx:d] gesehen und hab mir gedacht es ergibt weniger text und sieht besser aus...
nur hat dann das eben nicht mehr funktioniert deswegen hab ich halt gefragt...
gruß anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Per

Zitat von: antonwinden am 20 Mai 2016, 12:32:40und es ist mir auch nicht klar warum das eine auswirkung auf die wait funktion haben soll...
Das :d nicht, aber das Fragezeichen. Steht aber alles auch in der mehrfach genannten commandref...

antonwinden

#11
dann hab ich die commandref falsch verstanden siehe folgendes beispiel auf der ref:
define di_heating DOIF ([adjusting:actuator:d] < 10) (set heating off) DOELSE (set heating on)
und:
Kombination von Ereignis- und Zeitsteuerung mit logischen Abfragen   back

Anwendungsbeispiel: Lampe soll ab 6:00 Uhr angehen, wenn es dunkel ist und wieder ausgehen, wenn es hell wird, spätestens aber um 9:00 Uhr:

define di_lamp DOIF ([06:00-09:00] and [sensor:brightness] < 40) (set lamp on) DOELSE (set lamp off)

ich frage mich warum "[Luftfeuchte:pulseTimePerDay] < 1800" dann nicht gehen soll wenn es in der "device specific help" auch so drinnen steht besonders da hier reine zahlen vorliegen.
ich gebs auf denn anscheinend bin ich zu blöd richtig zu fragen oder es richtig zu verstehen

mein doif frägt zu einer bestimmten Zeit bestimmte bedingungen ab und wenn die passen dann sind insgesamt 4 aktionen fällig die jeweils mit einer wartezeit versehen sind.
und warum da die "schreibweise" der bedingungen einen einfluß darauf hat das nur 1 oder eben alle ausgeführt werden ist mir gelinde gesagt rätselhaft denn in beiden varianten werden die bedingungen ja erfüllt sonst würde ja gar keine aktion stattfinden....
egal ich geb es auf denn es funktioniert ja
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

speedschmidt

Servus Anton,

ich hatte ein ähnliches Problem hier und bin bei der Forumsuche hier vorbeigekommen und denke vielleicht könnte dir das hier helfen (ist ja noch nicht so ewig her):


https://forum.fhem.de/index.php/topic,53347.0.html


Meine Abfragen funktionieren mit:

define BeschattungSZ DOIF ([08:00-14:00] and [SZHeizen] eq "off" and [Aussentemperatur:state:d] > 15 and [SZIstTemperatur:state:d] > 23 and [AussenhelligkeitOst:state:d] > 60000) (set SZSonnenschutzEin on) DOELSE (set SZSonnenschutzEin off)


Vorherige Versuche mit:

...[Aussentempoeratur] > 15....

oder

...[Aussentempoeratur:d] > 15....

schlugen fehl.

und es gibt im Logfile keine Fehlermeldungen wie diese hier:

2016.05.26 15:56:08 1: PERL WARNING: Argument "89456.64 lux" isn't numeric in numeric gt (>) at (eval 3927) line 1.
2016.05.26 15:56:08 1: PERL WARNING: Argument "30.20 &deg;C" isn't numeric in numeric gt (>) at (eval 3929) line 1.
2016.05.26 15:56:08 1: PERL WARNING: Argument "22.18 &deg;C" isn't numeric in numeric gt (>) at (eval 3929) line 1.
2016.05.26 15:56:57 1: PERL WARNING: Argument "30.40 &deg;C" isn't numeric in numeric gt (>) at (eval 3950) line 1.
2016.05.26 15:56:57 1: PERL WARNING: Argument "22.18 &deg;C" isn't numeric in numeric gt (>) at (eval 3950) line 1.
2016.05.26 15:57:08 1: PERL WARNING: Argument "30.40 &deg;C" isn't numeric in numeric gt (>) at (eval 3960) line 1.
2016.05.26 15:57:08 1: PERL WARNING: Argument "22.18 &deg;C" isn't numeric in numeric gt (>) at (eval 3960) line 1.


Dank Andi läuft das jetzt bei mir und ich hoffe ich konnte evtl. dir helfen

Schmitti

antonwinden

danke für die Antwort nur ist bzw war mein problem anders gelagert.
die fehlermeldungen hatte ich ja nicht da ich readingsnum verwendet habe. habe dann versucht auf die syntax von doif ([xy:state:d]) umzustellen und dann tauchte das problem auf das die mit wait verzögerten aktionen nicht mehr ausgeführt wurden.
die 1. wurde anstandslos ausgeführt (also waren die auslösungsbedingungen alle sauber abgefragt) nur wurde dann kein wait timer gestartet wie bei der variante mit readingsnum...
nachdem ich hier nur mit verweisen darauf das ich mit ? arbeiten soll (und das so wie ich es verstanden hab die bedingungen nur einmal abfragt und nicht auch während der laufzeit der geplanten aktion mit den wait timern -> das war aber nicht mein problem denn die bedingungen haben sich ja nicht so geändert das die aktionen hinfällig wären) bin ich wieder zu readingsnum zurück denn da funktioniert es ja ohne probleme...
gruß anton
KNX, Raspberry, Denon 3313, Philips TV, Xtrend9X00 und viel Optimismus...

Per

Zitat von: antonwinden am 27 Mai 2016, 07:30:53die bedingungen nur einmal abfragt und nicht auch während der laufzeit der geplanten aktion mit den wait timern
Ich glaube, dass du Ursache und Wirkung verwechselst. Auslöser der Abfragen sind die Events. Bedingungen mit Fragezeichen reagieren nicht auf Events. Damit sind sie gleich mit readingsnum. Alle anderen sind wie einzelne notify, welche bei Auftreten einer passenden Situation "zuschlagen" und das ganze DOIF starten (aber nur Zweige ausführen, in denen DIESES Event auch vorhanden ist).