Merkwürdiges Verhalten oder meine Dummheit? (and/or)

[M_I_B]

Hallo liebe Leute,

ich stehe mal wieder wie der Ochs vor'm Berge und/oder habe in der Sache einen bösen Denkfehler vergraben, den ich derzeit nicht erkennen kann. Daher bitte ich mal wieder um Hilfe resp. den passenden Gedankenstupser...

Problemkind ist die 3. Zeile des DOIF.
Erreicht weden soll, das entweder bei Erreichen der Tageszeit Morgens (0 oder 1) ODER aber bei Überschreiten der Helligkeitsschwelle (47) UND steigender Helligkeit (1) der Aktor abgeschaltet werden soll. Dabei ist der Teil vor- und hinter dem OR als eigenständig zu betrachten, also je nachdem, was zuerst eintritt. Das habe ich mit der Klammerung versucht anzudeuten, obwohl die m.E. hier gar nicht nötig ist...

Haut nicht hin (die restlichen Zeilen hingegen einwandfrei seit Monaten)... Mit den dargestellten Vorgaben wird der Aktor sofort abgeworfen... und ich verstehe ums Verrecken nicht warum

Code Auswählen Erweitern


Slider = 0 (Kann -1, 0, 1 oder 2 sein (-1=aus, 0=automatik, 1=manuell, 2=an))
TGZ = 2|3 (0=Früher Morgen (ab 02:00), 1=Morgen/Vormittag, 2=Nachmittag/Abend, 3=Später Abend/Nacht (bis 02:00))
LUM:state < 40 (Aktuelle Helligkeit draußen)
LUM:T = -1|0 (-1=Helligkeit abnehmend, 0=Konstant über Zeit x, 1=Helligkeit zunehmend)
LUM_Slider = 47 (Slider 0 bis 99, Schaltschwelle)
PTV = 1 (Präsenz TV. 1 = TV an)
PTV_time = 45 (Zeit in Minuten nach Abschalten des TV; Umrechnung im wait-attr)


define set_Terrasse DOIF ([Slider] < 0) (set IT1SW23 off) DOELSEIF ([Slider] == 2) (set IT1SW23 on) \
DOELSEIF ([Slider] == 0 and [TGZ] == 2 and [LUM:state] < [LUM_Slider] and [LUM:T] < 0) (set IT1SW23 on) \
DOELSEIF ([Slider] == 0 and [TGZ] <= 1 or ([LUM:state] > [LUM_Slider] and [LUM:T] > 0)) (set IT1SW23 off) \
DOELSEIF ([Slider] == 0 and [TGZ] >= 2 and [PTV] == 0 and [PTV_time] != 0) (set IT1SW23 off)
attr set_Terrasse do always
attr set_Terrasse wait 0:0:0:0:[PTV_time]*60



... also Hirnentknoter und Ochsenschubser voran

[Brockmann]

Mach in dem Moment, wo es nicht wie gewünscht funktioniert, ein list set_Terasse.
Dann kannst Du genau nachvollziehen, woran es liegt.

Alternativ kannst Du DOIFtools drauf ansetzen und alles rund um set_Terasse loggen lassen.
Vielleicht verhält sich einer der Werte doch nicht so, wie Du erwartest.

Ich sehe es auch so, dass in dem Fall die Klammern logisch nicht notwendig wären (and bindet stärker als or), würde sie aber trotzdem immer setzen - alleine schon wegen der Lesbarkeit.

[M_I_B]

... ja, ich versuche es mal mit dem LIST; mit den Tools habe ich mich noch nicht beschäftigt; sind die neu? Kenne ich noch nicht...
Gestern Abend passierte in dem Zusammenhang noch was interessantes: In dem Moment, als meine Holde den TV aus gemacht hat, ging zeitgleich auch auf der Terrasse das Licht aus und nicht erst nach 45 Minuten wie vorgegeben. Das aber hatte bis gestern vor Änderung einwandfrei funktioniert... Also scheint es nicht unbedingt was mit den Werten selbst zu tun zu haben, sondern eher mit der logischen Abfolge, die sich hier irgendwo selber ein Bein stellt ... So aus dem Bauch raus...

Was die Werte angeht bin ich mir aber sicher: Zum einen werden die Werte an fast allen anderen Stellen auch verwendet, zum anderen kann ich die jederzeit live mitlesen (TGZ, LUM und Readings daraus, Sliderwerte, PTV und Readings daraus). Mehr is ja nicht.

Das mit den Klammern sehe ich ebenso wie Du: Lieber mal ein Klammerpaar zu viel, um die Übersichtlichkeit zu wahren, als nach einem Jahr nicht mehr dahinter zu steigen, wie denn das mal gedacht war ...

[Per]

Das das erste DOELSIF mit in der ersten Zeile steht, hat mich erstmal verwirrt 

Mach dir doch einfach pro Fall ein DOIF-Reading mit den selben Bedingungen wie in der echten Abfrage. Evtl. sogar Teilabfragen.

[M_I_B]

Das das erste DOELSIF mit in der ersten Zeile steht, hat mich erstmal verwirrt 

... ja sorry Habe ich aber in allen Abfragen so, die sich auf den von mir s.g. Automatik- Slider beziehen; es werden alle nicht automatischen Stellungen des Sliders in einer Zeile abgefrühstückt, was m.E. (zumindest für mich) die (Über-) Sicht auf die entscheidenden Zeilen verbessert...

Mach dir doch einfach pro Fall ein DOIF-Reading mit den selben Bedingungen wie in der echten Abfrage. Evtl. sogar Teilabfragen.

Hmmm? Jetzt kann ich Dir nicht wirklich folgen...

[Otto123]

Hi,

ich versteh Dein Konstrukt so (ich bin da immer so und schreibe ne Logiktabelle)

Code Auswählen Erweitern


[Slider] == 0 and [TGZ] <= 1 or [LUM:state] > [LUM_Slider] and [LUM:T] > 0)
0 0 -> 0                      0 0 -> 0                        0 0 -> 0   
0 1 -> 0                      0 1 -> 1                        0 1 -> 0
1 0 -> 0                      1 0 -> 1                        1 0 -> 0
1 1 -> 1                      1 1 -> 1                        1 1 -> 1


Entspricht eigentlich Deiner Beschreibung? Es kann nur an den Werten liegen. Offenbar ist immer eine der beiden AND Teile erfüllt.
Siehst Du eigentlich im List vom DOIF.
Die Frage ist: Tritt den CMD2 überhaupt ein? Du solltest Dir die Logikfälle für CMD 1 und 3 auch in eine Tabelle schreiben.

Gruß Otto

[M_I_B]

... ok, war ein bisschen krank, konnte aber zwischenzeitlich die Sache mal genauer untersuchen ...

Also... Es ist immer nur ein Teil wahr. Der linke Teil ist immer dann wahr, wenn bestimmte Tageszeit(en) vorliegen. Der Rechte Teil ist immer dann wahr, wenn "Helligkeitsschwelle unterschritten UND Tendenz fallend" ODER "Helligkeitsschwelle überschritten UND Tendenz steigend". Das funktioniert in allen getesteten und provozierten Fällen als Einzelfunktion. Sinn dahinter ist, kurzzeitige Helligkeitsänderungen um den Schwellwert herum abzufangen; die Tendenz ist seeeehr träge und muss schon eine Weile anliegen und zudem kontinuierlich steigen (sinken), um einen Wert von 1 (-1) zu erhalten.

Komisch ist allerdings die Tatsache, das manchmal CMD2 (3) erreicht wird und manchmal nicht (und jetzt kommt's) und das jeweils in keinem (erkennbaren) Zusammenhang mit dem tatsächlichen Ereignis steht. Mal werden die zugehörenden Befehle bei Erreichen von CMD2(3) korrekt an den Aktor gesendet, mal nicht, mal das Gegenteil...

Das macht mich ganz kirre 

Ich denke, ich werden den ganzen Schlunz mal komplett neu überdenken...

BTW: Slider sind ja ganz nett, aber gibt es in zwischen eine einfache Möglichkeit, z.B. drei Buttons übereinander o.ä. mit einfachen Mitteln als eine Art Tastensatz zu definieren?
Siehe Anlache... Erster Satz steht auf AUTO, zweiter Satz auf ON, dritter Satz auf OFF... Irgendwie so was wäre einfacher als Slider für meine Zwecke...

[Otto123]

Hi Micha,

naja Gespenster gibt es bei FHEM keine 
Die set Befehle an den Aktor werden doch ins FHEM Log geschrieben!?
Die Werte müsstest Du mitloggen.
Du könntest auch einfach Logfunktion ins DOIF einbauen. Ich bin sicher da sieht man dann den Zusammenhang.

Wenn das DOIF richtige Befehle sendet und der Aktor was anderes macht, dann liegt es am IO oder am Aktor.

Gruß Otto

[M_I_B]

naja Gespenster gibt es bei FHEM keine 

HAH! Das wage ich zu bezweifeln 
Die Werte, die ins Log geschrieben werden, passen exakt mit dem zusammen, was der Aktor macht. Der Aktor scheidet also als Fehlerquelle aus; sind ja auch mehrere Pfade, die so komische Dinge machen... Diesen Codeabschnitt nutze ich bestimmt an 20 verschiedenen Stellen. Der liegt als s.g. Snippet vor und ist dann an den ganzen Stelle eingebaut worden, natürlich mit Eintragen des neuen Zieles. Die entsprechenden Felder im Snippet sind ausge***, so das keinesfalls aus versehen solch ein Codeblock die gleichen gültigen Quellen und Ziele enthalten kann (*** ist ja weder das Eine noch das Andere); nur um solchen Vermutungen vorzubeugen. Dagegen spricht ja auch, das die überwiegende Zahl dieser Blöcke vollkommen korrekt funktionieren; nur 2-3 Stück stressen...

Ich denke, ich werde die umschreiben, wie ich schon sagte. Sobald ich eine Möglichkeit gefunden habe solche Buttons zu nutzen, geht das los... Derweil habe ich die "Geisterblöcke" mit festen Zeiten/Zeitbereichen ausgestattet, was erst mal so funktioniert, bis ich eine Lösung habe...

Wenn Du oder wer anders also einen Tip bezgl. der Buttons hast... her damit (außer TabletUI o.ä.)

[pc1246]

Moin Micha
So wie ich das sehe, kann Dich eigentlich nur der Fernseher aergern! Womit bildest du denn [PTV]? Wenn das nochmal triggert, dann schaltet das DOIF, warum der waittimer dabei spinnt, musst Du mal checken!
So ganz nebenbei, danke fuer den Denkanstoss, das werde ich so aehnlich auch mal in Angriff nehmen!
Gruss Christoph

[M_I_B]

Moin Christoph,

dre Fernseher kann's eigentlich auch nicht sein. Der wird via Präsenz- Modul / LAN- Ping abgefragt und triggert damit einen retriggerbaren Timer. Abfrage läuft alle 60 Sekunden, der Timer steht auf 5 Minuten. Auch wenn mal 2-3 Ping's fehlen sollten, ist PTV dann immer noch 1...
Dennoch Dank für den Hinweis; wer weiß?!? Vielleicht stimmt da was mit dem Timer nicht (mehr) oder irgend was anderes killt den. Werde ich mir auf jeden Fall noch mal ansehen...

[M_I_B]

... Thema durch ...
Der Fehler hat sich von mir nicht eingrenzen lassen. Ich bin dann stumpf dabei gegangen und habe alle betreffenden DOIF umgeschrieben. Die triggernden Devices sind so geblieben. Nun funktioniert es wie erwartet... Keine Ahnung, wo da der Bock drin war  (... das zum Thema Geister ...)

Jetzt muss ich noch einen anderen Geist fangen, der sich im InterTechno- Bereich herum treibt (https://forum.fhem.de/index.php?topic=80720)