Bewegungsmelder "schickt" nur on

[Kuehnhackel]

Hallo zusammen,
ich habe ein reading in der readinglist, welches die "Nachricht" von Bewegungsmelder aufnimmt

Code Auswählen Erweitern

tele/SonoffBridge/RESULT:.* { $EVENT =~ m,..RfReceived....Sync..([A-Za-z0-9]+)..Low..([\d]+)..High..([\d]+)..Data...D3D5DE...RfKey...([A-Za-z0-9]+)..., ? { state=>"motion"} : undef }

Gibt es eine Möglichkeit über das

Code Auswählen Erweitern

(time_str2num(ReadingsTimestamp($NAME,"motion","0"))
z.B. nach 30 sek "checken" es gibt keine Veränderungen und setze z.B. ein reading Bewegung auf nomotion?

Weil das würde auf jeden Fall das ein oder andere erleichtern.

Danke schon mal.

Ralf

[TomLee]

Hallo,

es ist nicht so das ich gleich eine Lösung präsentieren kann, müsst ich mich auch erstmal wieder einlesen und testen, aber ich bin der Meinung das Beta-User dazu schon zwei mögliche Lösungen vorgeschlagen hat:

Hmmm, hier würde ich einen anderen Weg gehen, nämlich dieses Ding immer triggern lassen, also kein "eocr .*" dafür setzen, aber das ganze dann auch wieder in einem separaten Device abhandeln. Da dieses Device nur dieses Reading hat, sollte das klappen, oder?
Man könnte es auch zurücksetzen, hier ggf. "am einfachsten" mit einem userReadings, das ein (benanntes) sleep anlegt und dann nach Zeitablauf state auf "nomotion" setzt. Benanntes sleep deswegen, weil das dann ein ggf. laufendes erneuern sollte, wenn nochmal motion gemeldet wird (trigger passend setzen)...

Mir gefällt der Vorschlag mit dem benannten sleep irgendwie besser.

Gruß

Thomas

[Kuehnhackel]

Mir gefällt der Vorschlag mit dem benannten sleep irgendwie besser.

Finde aber nichts dazu 

[TomLee]

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

Ich geb zu das ich auch noch etwas brauche bis ich es wirklich verstanden habe

[TomLee]

Hier zum Verständnis und nachvollziehen ein Beispiel an einem dummy.

Code Auswählen Erweitern

defmod du_test dummy
attr du_test readingList state
attr du_test room Test
attr du_test setList state:motion
attr du_test userReadings state {fhem("sleep 10 bla quiet;;set $name state nomotion")}

setstate du_test motion
setstate du_test 2021-01-06 14:02:51 state motion

[MadMax-FHEM]

Ich würde ja entweder einen Trigger (sollte man eh immer) beim userReadings angeben und "im" userReadings abfragen auf "motion" und nur dann nomotion setzen...

So würde doch alle 10s nomotion gesetzt werden?

Und müsste es nicht entweder set $name nomotio oder setreading $name state nomotion heißen?

Gruß, Joachim

[TomLee]

in dem dummy gibts nur ein Reading wozu sollt ich einen trigger setzen ?
Den trigger hab ich bewusst weggelassen

Das Beispiel soll zeigen wie das benannte sleep tickt mehr nicht.

So würde doch alle 10s nomotion gesetzt werden?

Dann hast du es auch noch nicht ganz verstanden, bzw. mein Beispiel nicht ausprobiert.

Benanntes sleep deswegen, weil das dann ein ggf. laufendes erneuern sollte, wenn nochmal motion gemeldet wird (trigger passend setzen)...

Code Auswählen Erweitern


Und müsste es nicht entweder set $name nomotio oder setreading $name state nomotion heißen?


mit der setList meines gezeigten dummy gibts ein Event darum gehts mit set.

Probiers doch aus.

[TomLee]

Dann hast du es auch noch nicht ganz verstanden, bzw. mein Beispiel nicht ausprobiert.

Nehm ich zurück, ich habs noch nicht verstanden.

Aus der Kommandozeile ein cancel bla löscht das sleep, im userReadings wirds nicht gelöscht.

state {fhem("sleep 10 bla quiet;cancel bla;set $name state nomotion")}

[MadMax-FHEM]

Naja weil ein Trigger nicht schadet und das userReadings triggert ja doch so nach 10s immer selbst...

setList ist mir schon klar.

Aber dann eben: set Device Wert
Und nicht: set Device Reading Wert

Weil dazu dann eben setreading...

Ich wollte nur Anmerken...

Bevor das hier in "Streit" ausartet bin ich lieber raus...

EDIT: ja ich hatte es nicht getestet, war nur mit dem Handy unterwegs... Aber jetzt Also scheint so bei setList / readingList geht auch das set-Kommando so. Es geht aber auch ohne state, also nur set du_test nomotion... Aber (wie ja angedeutet): es wird alle 10s neu nomotion "gesendet". Weil eben ohne Trigger im userReadings auch nomotion das userReadings triggert... Und "im" userReadings eben nicht gefragt wird, ob noch motion ist o.ä. Und ja: bei dem dummy und bei Tests kann man schon mal auf den Trigger verzichten (aber auch hier geht es "schief"   ). Ich wollte nur darauf hinweisen, dass man das (normalerweise) tun sollte! Nicht mehr nicht weniger... Und jetzt mache ich andere Sachen
EDIT: aber vorher muss ich das userReadings wieder rausschmeißen weil sonst kommt alle 10s der Event...

Gruß, Joachim

[TomLee]

- ich würde in einen "Pseudoreading-Namen" für das userReading vergeben und den trigger wirklich auf "state.motion" begrenzen. Pseudo-Namen deswegen, weil wir das nur brauchen, damit wir eine definierte Stelle haben, um "unseren" Perl-Code in die Eventverarbeitung einzuschleusen.
- Es handelt sich um eine Sache, die hart an der Grenze zum "Missbrauch" von userReadings liegt, von daher muss das nicht unbedingt so klappen, wie ich vermute; ich weiß auch nicht alles und muss es ggf. auch austesten...

Ich bekomms im dummy nur so hin:

Code Auswählen Erweitern


defmod du_test dummy
attr du_test readingList occupancy
attr du_test room Test
attr du_test setList occupancy:motion
attr du_test userReadings state:occupancy.* {if (ReadingsVal($name,"occupancy","") eq "motion"){fhem("sleep 10 bla quiet;;setreading $name occupancy nomotion")}}

setstate du_test 2021-01-06 18:39:12 occupancy nomotion
setstate du_test 2021-01-06 18:39:12 state

Andersrum wills nicht klappen:

Code Auswählen Erweitern

defmod du_test dummy
attr du_test readingList state
attr du_test room Test
attr du_test setList state:motion
attr du_test userReadings occupancy:state.* {if (ReadingsVal($name,"state","") eq "motion"){fhem("sleep 10 bla quiet;;setreading $name state nomotion")}}

setstate du_test motion
setstate du_test 2021-01-06 18:35:20 state motion





Im MQTT2_DEVICE Kontext könnt ich mir hier wieder vorstellen sowas über einen getter zu realisieren:

Code Auswählen Erweitern


nomotion:noArg state {if (ReadingsVal("bla","state","") eq "motion"){fhem("sleep 10 bla quiet;setreading bla state nomotion")}}

wenn es  in periodicCmd möglich wäre auf Events zu reagieren 

[Kuehnhackel]

Dake TomLee, muss aber erstmal um meine Hausaufgabe kümmern 

Querbeziehungen:
es gibt dafür ein "spezielles" Reading , nennt sich "associatedWith". Da muss man einfach die Namen des jeweils anderen Devices reischreiben.
Wie: siehe setreading in der commandref.

Für den Rest: bitte mal den "Haupt-" Workshop zum Thema jsonMap durchforsten und etwas mit event-on-change-reading und Co rumspielen...

Wir machen weiter, wenn du dazu ein RAW-listing lieferst, das die bisherigen Erkenntnisse am Hauptdevice vollständig wiederspiegelt und Ansätze von jsonMap und event-on-.* erkennen läßt?

[Beta-User]

Super Vorarbeit!

Kleine Änderung, große Wirkung :

Code Auswählen Erweitern

defmod du_test dummy
attr du_test readingList state
attr du_test room Test
attr du_test setList state:motion
attr du_test userReadings occupancy:motion {if (ReadingsVal($name,"state","") eq "motion"){fhem("sleep 10 bla quiet;;setreading $name state nomotion")}}

periodicCmd würde m.E. zu viele Timer für "nichts" erzeugen, wäre ineffizient.

Die Alternative wäre m.E. gewesen, einen "Perl-Setter" zu generieren, der dann nicht publisht, sondern einfach das setreading macht und den aus dem userReadings aufzurufen und/oder erst bei der Ausführung zu checken, ob noch "notion" oder schon "nomotion" in state steht.

[TomLee]

Super Vorarbeit!

Seh ich jetzt, mit dem scheinbar korrektem Trigger, genau andersrum, nämlich das ich bisher offensichtlich gar nichts korrekt verstanden habe.

periodicCmd würde m.E. zu viele Timer für "nichts" erzeugen, wäre ineffizient.

wenn ich dich richtig verstehe hast du mich falsch verstanden (und nein mit Sicherheit suche ich keinen Streit sondern Lösungen), ich sagte auf Events reagieren, nicht wie jetzt mit period eine integer-Zeitangabe.

Beispiel:

getter:

Code Auswählen Erweitern

nomotion:noArg state {fhem("sleep 10 bla quiet;setreading bla state nomotion")}

periodicCmd

Code Auswählen Erweitern

nomotion:{ReadingsVal("bla","state","") eq "motion")}

Ich kenn mich aber, mit Sicherheit zu kurz gedacht.

[Beta-User]

Hier nochmal nach nochmaligem  Nachdenken eine überarbeitete Fassung:

Code Auswählen Erweitern


defmod du_test dummy
attr du_test readingList state
attr du_test room Test
attr du_test setList state:motion
attr du_test userReadings occupancy:motion {fhem("sleep 30 nomotion_$name quiet;;setreading $name state nomotion")}
Das mit den "state-Events" (siehe cref zu addStateEvent bei notify) gilt auch hier, man darf bei state-triggern in userReadings eben nicht den Readingnamen vorneweg verwenden.

Da der Trigger (ausnahmweise!) eindeutig ist, kann man auch das if() weglassen, und eine dynamische und eindeutige "Id" für das benannte sleep ist vermutlich auch eine gute Idee, wenn man sowas öfter benötigt...

Ergo: es war alles da, was man braucht, und das mit den state-Events führt immer mal wieder zu Verwirrung, nur eben in der Regel an anderer Stelle...


Zu periodicCmd:
Das legt einen "Dauertimer" an, der jede Minute checkt, ob die Zeit für die einzelnen Einträge abgelaufen ist. Eine "kleine notify"-Funktionalität hat das nicht, und der Timer läuft auch "immer". Mit userReadings ist auch (nicht nur hier) eine "kleine notify"-Funktion integriert (bitte nicht allzusehr missbrauchen!), so dass es m.E. nicht erforderlich ist, an der heutigen Syntax zu periodicCmd was zu ändern (zumal die auch in den Fällen, in denen es Sinn machen würde - ebus, z.B. - nicht aktiv von den dortigen Usern propagiert wird ).

Aber da das mit dem benannten sleep in der Tat an sich schon eine wenig beachtete Funktionalität ist, an der Stelle auch der Hinweis, dass man das sehr gut kombinieren kann  mit der noch viel unbekannteren Variante eines sleep als "Einmal-notify" (das aber auch in der unbenannten Variante funktioniert).