DoIF löst aus obwohl Reading sich nicht verändert

daheim · 03 Mai 2021, 16:39:59

Hallo zusammen,

ich habe folgendes Problem:

Ich habe div HomeMatic Aktoren mit mehreren Kanälen. Beispielhaft habe ich hier einen 2 Kanal Aktor der, wenn Kanal 1 sich der Status ändert, sich das DoIF (auch Statusüberwachung) im 2 Kanal auslöst.
Hört sich wuselig an aber ich hänge mal den Code ein:

Code Auswählen


Kanal 1:
NAME Aussen.Licht.Sitzplatz_Pool
Keine DoIFs hinterlegt

Kanal 2:
NAME Aussen.Poolpumpe
4 DoIFs
    1. (([08:00] or [13:00] or [18:00]) and ([Aussen.Poolpumpe.Automatik] eq "on")) (set Aussen.Poolpumpe on) 
       attr do always
    2. ([Aussen.Poolpumpe] eq "on") (set pushmsg msg "Pool" "Pumpe ist an!")
       attr do always
    3. ([Aussen.Poolpumpe] eq "off") (set pushmsg msg "Pool" "Pumpe ist aus!")
       attr do always
    4. (([08:00-08:01] or [13:00-13:01] or [18:00-18:01]) and [Aussen.Poolpumpe] eq "on") (set Aussen.Poolpumpe off) DOELSEIF ([Aussen.Poolpumpe] eq "on") (set Aussen.Poolpumpe off)
       attr do always
       attr wait 2700:900

Soweit so gut, wenn ich nun Kanal 1 ein oder ausschalte, bekomme ich das 3 DoIF (MSG Aus) auf dem 2 Kanal ausgelöst....

Warum?

Da ich mehrere Aktoren mit solchen DoIFs (PUSH Nachrichten) hinterlegt habe und in allen den Fehler (seit dem Update vom WE) habe, muss ich wohl was falsch gemacht haben, aber was?

Vlt kann mir einer von euch auf die Sprünge helfen

Grüße
Daniel

Otto123 · 03 Mai 2021, 19:10:34

Hallo Daniel,

diese Diskussion wird seit mind. 14 Tagen geführt:
DOIF triggert auf jeden Event des Gerätes, Du fragst ein Reading ab, das ändert sich zwar nicht, aber wenn der DOIF Zweig richtig ist (wahr wird) löst er aus.

Du musst Dir das im Event Monitor anschauen und entscheiden, dass Dein Auslöser nur ein treffender Event ist!

Verschärfend kommt hinzu: Du fragst kein Reading ab - Du fragst den STATE ab -> Die schlechteste aller Varianten.
Hauptgrund ist: Dein DOIF ist schlecht gebaut. Warum fällt es jetzt auf? Weil offenbar CUL_HM mit jeder Code Änderung die Events in die Höhe treibt.

Gute Lösung: DOIF besser bauen. Schlechte Lösung: CUL_HM auf alte Version zurück und vom update ausschließen. mit event-on-change-reading die Event Last senken.

Gruß Otto

Frank_Huber · 03 Mai 2021, 19:17:06

https://fhem.de/commandref_DE.html#DOIF_checkReadingEvent

daheim · 04 Mai 2021, 10:28:33

Hallo zusammen,

ich habe gerade einen Knoten im Kopf.
Was muss ich denn ändern, damit die DoIFs besser werden?
Wie kann ich denn alternative zum STATE die an aus abfrage machen? Reicht es wenn ich ein :state anhänge?

Grüße
Daniel

Damian · 04 Mai 2021, 10:37:28

Zitat von: daheim am 04 Mai 2021, 10:28:33
Hallo zusammen,

ich habe gerade einen Knoten im Kopf.
Was muss ich denn ändern, damit die DoIFs besser werden?
Wie kann ich denn alternative zum STATE die an aus abfrage machen? Reicht es wenn ich ein :state anhänge?

Grüße
Daniel

wenn du nur auf State reagieren willst, ja

Otto123 · 04 Mai 2021, 11:48:53

Ich liebe diesen Kauderwelsch

STATE ist ein Internal
state ist ein Reading
State wird wie Status gerne gesagt, genau genommen weiß damit keiner was gemeint ist.
STATE kann das Gleiche enthalten wie state - muss aber nicht! Stichwort stateFormat oder je nach Laune des Moduls.

Gerade auch bei CUL_HM Geräten wäre ich mir jetzt nicht sicher ob state sich nicht temporär ändert - obwohl der Zustand am Anfang und am Ende der Aktion gleich sind.
Deswegen: so richtig sicher geht man, wenn man exakt auf einen Event reagiert, oder wenn man ein anderes Reading als state abfragt (wenn man kann)
Beispiel triggert auf Event (Doku):

Code Auswählen

(["^Aussen.Poolpumpe$:^on$"]) (set pushmsg msg "Pool" "Pumpe ist an!")

Damian · 04 Mai 2021, 11:51:55

Zitat von: Otto123 am 04 Mai 2021, 11:48:53
Ich liebe diesen Kauderwelsch
STATE ist ein Internal
state ist ein Reading
State wird wie Status gerne gesagt, genau genommen weiß damit keiner was gemeint ist.
STATE kann das Gleiche enthalten wie state - muss aber nicht! Stichwort stateFormat oder je nach Laune des Moduls.

Gerade auch bei CUL_HM Geräten wäre ich mir jetzt nicht sicher ob state sich nicht temporär ändert - obwohl der Zustand am Anfang und am Ende der Aktion gleich sind.
Deswegen: so richtig sicher geht man, wenn man exakt auf einen Event reagiert, oder wenn man ein anderes Reading als state abfragt (wenn man kann)
Beispiel triggert auf Event:
Code Auswählen Erweitern
(["^Aussen.Poolpumpe$:^on$"]) (set pushmsg msg "Pool" "Pumpe ist an!")

er will offenbar Zustände abfragen:

([08:00] or [13:00] or [18:00]) and ([Aussen.Poolpumpe.Automatik] eq "on"))

da machen reine Eventabfragen keinen Sinn.

Otto123 · 04 Mai 2021, 11:53:10

Bei 2. und 3. nicht und 3. war sein Problemfall

aber Du bestätigt ja meine Aussage

Den Fall eins so umbauen:

Code Auswählen

(([08:00] or [13:00] or [18:00]) and ([?Aussen.Poolpumpe.Automatik] eq "on")) (set Aussen.Poolpumpe on)
Denn ein Trigger auf Aussen.Poolpumpe.Automatik ist bei der and Verknüpfung sowieso wirkungslos und verbraucht nur "Strom"

daheim · 04 Mai 2021, 13:17:38

Hallo Otto,
hallo Damian,

Diese Aussage:

Zitat von: Otto123 am 04 Mai 2021, 11:53:10
Denn ein Trigger auf Aussen.Poolpumpe.Automatik ist bei der and Verknüpfung sowieso wirkungslos und verbraucht nur "Strom"

verwirrt mich...
Aussen.Poolpumpe.Automatik ist ein Dummy den ich abfrage. Nach meinem Verständnis soll das DoIF zu den Uhrzeiten losrennen und zusätzlich soll der Dummy auch an sein und dann die Poolpumpe starten.

Ich habe mir jetzt alle Readings einmal angesehen und dort ist state vorhanden mit on bzw off. Daher habe ich an die DoIFs mal erst auf das Reading state angepasst, ich werde aber zeitnahe alles auf ein Event umbauen, das ist wohl sicherer...

Viele Grüße
Daniel

rabehd · 04 Mai 2021, 13:34:38

Zitatund zusätzlich soll der Dummy auch an sein

Das wäre dann kein Event(Ereignis), sondern ein Zustand.

Otto123 · 04 Mai 2021, 14:02:21

Hallo Daniel,

Zitat von: daheim am 04 Mai 2021, 13:17:38

verwirrt mich...

wollte ich nicht aber dann musst Du die Doku genauer lesen

? - nur Abfrage des Zustands. Du hast es ohne gemacht da wird auch getriggert. Den Trigger (auslöser) willst Du aber nur zu den festgelegten Zeiten.

Es gibt quasi drei Möglichkeiten warum ein Ausdruck wahr wird:
1. Die Abfrage stimmt
2. Das Modul wurde getriggert und die Abfrage stimmt
3. Ein bestimmter Event kam an, das Muster hat gestimmt.

Nr. 1 alleine macht aber auch keinen Sinn. Und es gibt viele Kombinationsmöglichkeiten einige werden funktionieren, einige können nicht funktionieren.

Gruß Otto