HM Bewegungsmelder geht bein Neustart nicht in "noMotion"

[Damu]

Meine Bewegungsmelder gehen bei einen Neustart von FHEM nicht in "state: noMotion" und "motion: off".
Natürlich nur wenn "motion" vor dem Neustart auf "on" war.
Danach löst mein DOIF immer wieder von selbst aus.

([BM_Aussen_Eingang:motion] =~ "on" and [?BM_Aussen_Eingang:brightness] < 80 and [?Bewegung_Aussen_Du] eq "on" and [?Aussenlampe_Eingang] eq "off") (set Aussenlampe_Eingang on-for-timer 240)

[martinp876]

Werde ich korrigieren. Neustart des melders.
Neustart von fhem kann ich auch machen, verfälscht aber die Anzeige. Ich sollte im 2. Fall auf unknown gehen.

[Pfriemler]

Die Krux ist vielleicht  dass manche nicht zyklisch sendende BWM bei Bewegung regelmäßig motion senden, nach Ablauf eines Messzyklus ohne Bewegung aber nur einmal noMotion. Verpasst FHEM das, weil gerade off, bleibt der Status eben falsch. Betrifft aber alle Geräte.
Fragt sich was das DOIF dann retriggert ...
Welcher Typ BWM isses genau?

via Tapatalk

[Damu]

Es sind die Aussen-Melder, der Innenmelder verhält sich aber identisch.
Verändert tut sich natürlich

battery:ok
brightness:197
cover:closed
recentStateType:info

"Motion" bleibt auf "on" wird nicht erneuert.
Aber das reicht anscheinend um das DOIF auszulösen.

[Pfriemler]

Jo, die beiden senden regelmäßig - der kleine quadratische und der WM-Taster eben nicht. Ist eher doof, dass sie nicht noMotion dann mitmelden.
Es ist korrekt, dass die aktualisierten Readings einen Trigger für das DOIF machen. Das ließe sich mit einem event-on-update-reading state dann evtl  vermeiden, mit anderen Nebenwirkungen.

@Martin: könnte es ein Ansatz sein, bei aktualisierten Readings für den BWM immer motion off zu setzen, wenn dieser nicht explizit motion on meldet? Sonst bliebe ja unknown nach einem Neustart ebenfalls ewig stehen...
Allerdings nur, wenn die motion-Meldungen nicht losgelöst von den übrigen Meldungen kommen. Ich bin mir da gerade nicht sicher.

via Tapatalk

[stromer-12]

Die WM-Taster liefern bei mir auch regelmässig ihre Helligkeit.

[martinp876]

Nomotion sendet der aktor nicht. Das errechnet fhem weil der Sensor mitteilt, wann das nächste Event kommen muss.
Gut möglich, dass die Implementierung Lücken bei reset und restart hat. Werde ich prüfen.

[Pfriemler]

Nomotion sendet der aktor nicht.

Und wieder was (erneut) gelernt. Mann. Früher konnte man motion vernünftig nur zusammen mit dem Alter des Readings auswerten (eine Lösung, die sich auch jetzt noch anbietet). Weil der Status "motion" dann aber als Dauerzustand blieb, kam wohl irgendwann das freundlicher lesbare noMotion dazu.
Wenn jede eintreffende Motion-Message nur einen internen Watchdog anwirft, der nach Ausbleiben weiterer Messages den Status auf noMotion kippt, reicht das im vorliegenden Fall eben nicht.

Habe das eben mal am MDIR-O gelesen: der sendet battery, brightness und cover unbeirrt zyklisch, motion (zusammen mit brightness) nur bei Bewegung. Statt restart und reset extra zu behandeln, würde es aus meiner Sicht auch funktionieren, wenn man beim Eintreffen jeglicher Meldungen prüft ob das letzte motion länger als die definierte Zeitspanne minInterval zurückliegt. Auf das Vorhandensein von motion an sich zu prüfen reicht nicht - im Test kam die zyklische Meldung battery eine Minute nach dem Motion.

Jm2c.

Und

Die WM-Taster liefern bei mir auch regelmässig ihre Helligkeit.

Ich hatte eben den WM in Verdacht das nicht zu tun. Seit einem clear readings gestern kommt es bei jeder Bewegung auch mit. Sonst aber eben stundenlang auch nichts.

[stromer-12]

Ist dein Melder gepeert?

[Pfriemler]

Tschulljung. Verlesen. Nein, nicht direkt. Tut aber nichts zur Sache. Kriegt Acks von FHEM. Aber er sendet nicht selbst aktiv zyklisch wie etwa die MDIR(-O).

via Tapatalk

[stromer-12]

Ich glaube martin hat mal gesagt das er gepeert sein muss, damit er zyklisch sendet.
Bei mir ist er mit einen virtuellen Channel gepeert.

[Damu]

Das Problem bei diesem DOIF ist:

([BM_Aussen_Eingang:motion] =~ "on" and [?BM_Aussen_Eingang:brightness] < 80 and [?Bewegung_Aussen_Du] eq "on" and [?Aussenlampe_Eingang] eq "off") (set Aussenlampe_Eingang on-for-timer 240)

Ich gehe raus, es gibt Licht.
Ich schalte am Schalter das Licht aus und gehe rein.
Der Bewegungsmelder sendet einen neuen Brigtness etc.
Wenn das Reading von Motion noch auf on ist, geht das Licht wieder an.


Ich hätte das das Reading Motion am liebsten sofort wieder auf off.
Das Reading State würde ich so lassen.

[martinp876]

Ich hätte das das Reading Motion am liebsten sofort wieder auf off.

was auch immer du damit meinst.
Der MD hat einen Status. Der ist Motion on oder off. Das  soll wiedergegeben werden.
Wie lange der Status anliegt legst du in den Registern fest.

Wenn du mit sofort meinst "MotionOn - 1ms warten - MotionOff" ist das nicht FHEM/HM sondern deine Implementierung. Das kannst du mit einem Timer regeln. Es ist keine allgemeine Notwendigkeit und keine Darstellung des Device-Zustands.
Wenn du mit "sofort" meinst "nach dem Ausschalten des Lichts" hat es wieder nichts mit FHEM/HM zu tun. Hier gibt es keine Relation zwischen dem Schalten und dem MD. Auch das kannst du bauen - in deinem "correlation-layer" in welchem du auf Basis von FHEM Verknüpfungen zwischen FHEM entites herstellst. FHEM weiss nicht, wie viele Lichter du mit dem MD gepeert hast (und will es nicht verfolgen) und welche du ausschaltest - und was passiert, wenn du nur einen ausschaltest.

Wenn du eine funktionierende Implementierung eines MD mit dem Aktor willst löse es in den Registern der Aktoren.

https://wiki.fhem.de/wiki/HomeMatic_HmInfo_Templates_erstellen#both

Code Auswählen Erweitern

set hm templateDef SwMdir onTime:minBright "switch action when peered motionDetector" shOnDly:0 shSwJtOn:no shOffDly:p0 lgActionType:off shCtDlyOff:ltHi shOffTimeMode:minimal shCtValLo:p1 lgMultiExec:off shOnTime:0 shCtValHi:255 shOffTime:unused shMultiExec:off shOnTimeMode:minimal shSwJtOff:dlyOff shSwJtDlyOff:dlyOff shCtOff:ltLo shActionType:jmpToTarget shCtOn:ltLo shSwJtDlyOn:no shCtDlyOn:ltLo

set hm templateSet <MeinLicht> SwMdir <MotionPeer>:both 30 70
#30 sec on wenn Brightness unter 70
#"on" eines jeden Buttons oder des Web over-ruled den MD.
#off ist off - nächste Motion schaltet wieder an.


[Damu]

"State: noMotion" und
"Motion: off"
Wird bei mir zur selben Zeit zurückgesetzt.
Oben hast du doch geschrieben das "noMotion" nur von Fhem zurückgesetzt,
"Motion: off" dann nicht?

[Pfriemler]

Damu, ich glaube, a) korrekte Abbildung des Status des Bewegungsmelders und b) Retriggerung Deines DOIFs sind zwei getrennt zu behandelnde Probleme.

zu a) Da ist Martin schon unterwegs. Das Zurücksetzen von motion bei jedem neuen Reading des Gerätes halte ich für kontraproduktiv. Man kann dann gar nicht mehr vernünftig auf "noMotion" triggern, weil die Laufzeiten des Status "motion" dann unvorhersehbar sind.

zu b): Zitat commandref DOIF

Das Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt. Das geschieht, wenn irgendein Reading oder der Status von "remotecontrol" aktualisiert wird.

In diesem Fall wäre es hilfreich, das Erzeugen von Events ggf. auf motion zu beschränken, wenn Du bspw. die Brightness-Readings nicht anderweitig zum Triggern benutzt.
DOIF besitzt einen weiteren pfiffigen Mechanismus, den Du nutzen kannst. Wenn Du statt ausschließlich auf Motion auch auf das Alter des Readings testest

Code Auswählen Erweitern

define di_lamp DOIF ([BM:state:sec] < 240) (set lamp on-for-timer 300)


würde dein DOIF nicht mehr auslösen, wenn der State zwar "motion" ist, aber nicht innerhalb der letzten 4 Minuten aktualisiert wurde.
Der (hier nicht eingebaute) Check auf Motion ist erforderlich, weil das Codebeispiel auch auf "noMotion" triggern würde.