Befehl mit wait > Wegfall der Bedingung wärend wait aktiv: noch gültig?

[Per]

Korrigiere mich, wenn ich falsch liege, aber bitte so, das ich das auch verstehe

Gern, wobei ich für das Verstehen nicht garantieren kann . Bin aus gutem Grund kein Lehrer geworden...

Der ist nämlich so gemein und setzt den status "motion" nicht selber zurück.

Das machen viele Sensoren so. Entweder Event="Motion" oder gar nix. Für letzteres hast du ja den Timer.

Eine Prüfung auf "motion" würde also nur ein einziges mal funktionieren.

Status oder Event? Die Statusänderung erfolgt nur einmal, den Event gibt es andauernd (so jemand rumrennt, sonst nicht). Und DOIF reagiert nur auf Events, Stati sind nur zusätzliche Bedingungen. Evtl. fehlt ein do always (da muss ich auch immer probieren, wierum es richtig ist )?

[M_I_B]

... ja... nö... ähhh... oder...

Also... Bei den Sensoren, die ziemlich am Anfang meiner "Fhem- Laufbahn" gekommen sind, hatte ich mir seinerzeit echt einen Wolf probiert. Erst das setzen mit setreading brachte damals den Erfolg, unabhängig von do always (ich probiere auch immer...).
M.E. ist der Haken ja, das diese Sensoren nicht nur Events bei Bewegung generieren, sondern auch bei Helligkeitsänderungen, Batteriestatus und haste nicht gesehen. Gut, die kann man Wegfiltern, aber da ich die auch auswerte, wäre das doof... Ich muss also irgendwie eine Bedingung abfragen, wenn ich hier keine Outdoor Lichtorgel haben will...

Wie gesagt: Vielleicht bin ich hier auch nur seit Anbeginn auf dem Holzweg und finde den Ausgang nicht mehr... Da es aber bis dato schmerzfrei funktioniert hat, hatte ich daran keinen Gedanken mehr verschwendet. Ich bin nur darauf gekommen, weil ich FHEM z.Z. mal durchgehend aufräume, Viele Dummys zu einem zusammenfasse und mit Slidern versehe, Müll entsorge und die Raumstruktur neu durchdacht habe ... u.s.w.


OT: Ich habe mal den Lehrer in der s.g. Erwachsenenbildung gemacht... Schlimmer wie Kinder! Nach 2 Jahren hatte ich die Nase gestrichen voll Ich weiß also, wie schwer es manchmal ist, jemandem einen Sachverhalt so aufzutischen, das er es mit seiner individuellen Denke verarbeiten und umsetzen kann...

[Per]

M.E. ist der Haken ja, das diese Sensoren nicht nur Events bei Bewegung generieren, sondern auch bei Helligkeitsänderungen, Batteriestatus und haste nicht gesehen. Gut, die kann man Wegfiltern, aber da ich die auch auswerte, wäre das doof... Ich muss also irgendwie eine Bedingung abfragen, wenn ich hier keine Outdoor Lichtorgel haben will...

Du darfst natürlich nur das Reading Status abfragen, nicht alle Events. Und ja, früher ging das nicht ohne weiteres. Aber da du keinen DOELSE(IF)-Fall hast, ist es egal (zumindest in diesem Beispiel), ob andere Events dazwischenfunken.

FHEM z.Z. mal durchgehend aufräume

Das mache ich auch ab und zu, besonders wenn mal ein neues Device (wie damals DOIF) kommt oder mir eine neue Idee (aktuell: verkoppeltes Gerät als Userreading) kommt. Oder wenn ich mal wieder was Neues begriffen habe. Aber da gibt es eher ein neues Device

Und hier nochmal "meine" General-Variante:

Code Auswählen Erweitern

define LichtPIRga DOIF (["HM2BB?":"motion"] and [LUM] < 35) (set [$DEVICE:gekoppeltes_device] on-for-timer 180)

Wenn du willst, kannst du sogar verschiedene LUM-Werte hinterlegen und diese Abfragen:

Code Auswählen Erweitern

define LichtPIRga DOIF (["HM2BB?":"motion"] and [LUM] < [$DEVICE:LUM]) (set [$DEVICE:gekoppeltes_device] on-for-timer 180)

ABER: geht nur mit on-for-timer oder explizit angelegten Timern (defmod at), wait klappt hier nicht, wenn man nicht ausschließen kann, dass zwei oder mehr Melder gleichzeitig ansprechen können.

[Otto123]

Hi Jungs,

zwei Sachen zu motion. Bei den HM Bewegungsmeldern hat Martin vor geraumer Zeit das Problem behoben. Der meldet, nach Ablauf der Wartezeit des PIR jetzt nomotion.
Ich habe mein DOIF gestern noch geändert, da er nicht die Zeit die ich wollte sondern die doppelte das Licht angelassen hat. Genau wegen dem zweiten Event nach Ablauf der Wartezeit des PIR (u.a. motion off). Dabei habe ich den Trigger umgestellt, da DOIF sich ja auch ständig "ändert" - ähm weiter entwickelt 

Code Auswählen Erweitern

([PIR1:"motion:.on"] and ([?Tageslicht] eq "0" or [?PIRWg:brightness] < 150)) (set SW01_Sw01 on)(set SW01_Sw01 off)
Dazu do resetwait und wait 0,250. Jetzt funktioniert es sauber.

Ich glaube die 300:0 ist genau wie die 300 - aber ja lieber man schreibt es hin. Werde ich machen.

Gruß Otto

[Damian]

Hi Jungs,

zwei Sachen zu motion. Bei den HM Bewegungsmeldern hat Martin vor geraumer Zeit das Problem behoben. Der meldet, nach Ablauf der Wartezeit des PIR jetzt nomotion.
Ich habe mein DOIF gestern noch geändert, da er nicht die Zeit die ich wollte sondern die doppelte das Licht angelassen hat. Genau wegen dem zweiten Event nach Ablauf der Wartezeit des PIR (u.a. motion off). Dabei habe ich den Trigger umgestellt, da DOIF sich ja auch ständig "ändert" - ähm weiter entwickelt 

Code Auswählen Erweitern

([PIR1:"motion:.on"] and ([?Tageslicht] eq "0" or [?PIRWg:brightness] < 150)) (set SW01_Sw01 on)(set SW01_Sw01 off)
Dazu do resetwait und wait 0,250. Jetzt funktioniert es sauber.

Ich glaube die 300:0 ist genau wie die 300 - aber ja lieber man schreibt es hin. Werde ich machen.

Gruß Otto

Nur als Ergänzung: notify-User ersetzen in der Regex Leerzeichen immer durch einen Punkt für alle Buchstaben, weil es beim notify nicht anders geht. Beim DOIF dagegen kann man auch ruhig ein Leerzeichen innerhalb der Anführungszeichen nutzen:

Code Auswählen Erweitern


([PIR1:"motion: on"] ...

[Otto123]

Nur als Ergänzung: notify-User ersetzen in der Regex Leerzeichen immer durch einen Punkt für alle Buchstaben, weil es beim notify nicht anders geht. Beim DOIF dagegen kann man auch ruhig ein Leerzeichen innerhalb der Anführungszeichen nutzen:

Code Auswählen Erweitern


([PIR1:"motion: on"] ...

Danke für die Info. 

[Damian]

Danke für die Info. 

Und noch ein paar Vergleiche zwischen notify und DOIF

notify                        DOIF

Code Auswählen Erweitern

motion:.on        ^motion: on$
.*motion:.on      motion: on$
motion:.on.*      ^motion: on
.*motion:.on.*    motion: on

[M_I_B]

Und hier nochmal "meine" General-Variante:

Code Auswählen Erweitern

define LichtPIRga DOIF (["HM2BB?":"motion"] and [LUM] < 35) (set [$DEVICE:gekoppeltes_device] on-for-timer 180)

Wenn du willst, kannst du sogar verschiedene LUM-Werte hinterlegen und diese Abfragen:

Code Auswählen Erweitern

define LichtPIRga DOIF (["HM2BB?":"motion"] and [LUM] < [$DEVICE:LUM]) (set [$DEVICE:gekoppeltes_device] on-for-timer 180)

ABER: geht nur mit on-for-timer oder explizit angelegten Timern (defmod at), wait klappt hier nicht, wenn man nicht ausschließen kann, dass zwei oder mehr Melder gleichzeitig ansprechen können.

Ok... also Bahnhof Kofferklau'n?! Die Nummer "[$DEVICE:gekoppeltes_device]" verstehe ich gar nicht. Kannst du das einem DAU mal näher bringen?!?


Ansonsten finde ich es geil, das eine einfache Frage manchmal zu einem Fred führt, in dem so viele Dinge angesprochen und erklärt werden, so das man richtig was dabei lernt 

[Per]

Die Nummer "[$DEVICE:gekoppeltes_device]" verstehe ich gar nicht.

welches man durch geschickte Namenswahl sogar generalisieren könnte. Oder mittels Userreading...

Speziell für dich (bzw. deine Werte):
Erstell in HM2BB1 ein Userreading gekoppeltes_device mit dem Wert HM4SW2_1

Code Auswählen Erweitern

setreading HM2BB1 gekoppeltes_device HM4SW2_1
das gleiche fer HM2BB2

Code Auswählen Erweitern

setreading HM2BB2 gekoppeltes_device HM4SW1_1
Dieses Userreading kannst du wie oben gezeigt im DOIF direkt abfragen. User-Attrib wäre sauberer, würde aber AttrVal() ist aufwendiger als [] .

[M_I_B]

... ich habe jetzt mal einen ganzen Tag darüber nachgedacht ... hat nicht geholfen 

Zwei konkrete Fragen bekomme ich einfach nicht aus'm Kopf...

1.
"gekoppeltes_device" ist jetzt explizit ein Schlüsselwort resp. Befehl? Oder wie muss ich das verstehen?

2.
Ich sehe im derzeit nicht so wirklich einen Vorteil darin, zwei Geräte auf diese Art miteinander zu koppeln. Im Moment empfinde ich es sogar als komplizierter als die klassische Methode...


Ich brauch da wohl noch einen Schubs resp. ein konkretes Beispiel, um erkennen zu können, worin die Vorteile einer Koppelung liegen 

[Brockmann]

1.
"gekoppeltes_device" ist jetzt explizit ein Schlüsselwort resp. Befehl? Oder wie muss ich das verstehen?

Ich denke, die Idee ist, dass Du bei jedem Sensor in einem eigenen Reading hinterlegst, welches Device er schalten soll.
Dann brauchst Du nur ein einziges DOIF, das auf motion-Events von allen Sensoren reagiert und dann für den triggernden Sensor dessen gekoppeltes Device einschaltet. Und das geht eben nur, wenn das DOIF weiß, welches Gerät zu welchem Sensor gehört.

Wobei ich es sowas - wenn möglich - tatsächlich lieber gleich per Peering mache. Ist ausfallsicherer und etwas schneller. Aber wenn noch zusätzliche Bedingung mit reinspielen sollen, ist das sicher eine sinnvolle Alternative.