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.
Zitat([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)
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.
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
Es sind die Aussen-Melder, der Innenmelder verhält sich aber identisch.
Verändert tut sich natürlich
Zitatbattery:ok
brightness:197
cover:closed
recentStateType:info
"Motion" bleibt auf "on" wird nicht erneuert.
Aber das reicht anscheinend um das DOIF auszulösen.
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
Die WM-Taster liefern bei mir auch regelmässig ihre Helligkeit.
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.
Zitat von: martinp876 am 30 Dezember 2016, 06:38:36
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
ZitatDie 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.
Ist dein Melder gepeert?
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
Ich glaube martin hat mal gesagt das er gepeert sein muss, damit er zyklisch sendet.
Bei mir ist er mit einen virtuellen Channel gepeert.
Das Problem bei diesem DOIF ist:
Zitat([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.
ZitatIch 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
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.
"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?
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
ZitatDas 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
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.
Motion und state werden beide über das device gesetzt und von fhem über timer zurückgesetzt. Kann man mir schon glauben.
Es ist ferner sinnvoll nach einem restart einen neutralen Zustand einzunehmen.
Sind wir in "motion" nach dem Reboot läuft natürlich der timer nicht. Wir bleiben also in Motion bis wieder eine kommt. Und diese löst dann keinen Trigger aus. Andrerseits wird bei no Motion in Kürze auf Motion geschaltet, so sich was bewegt.
Wie sich ein doif nach reboot Verhält muss sich der Erfinder des selben überlegen.
Wenn der Bewegungsmelder nach dem Neustart auf Motion:on bleibt.
Geht bei jedem aktualisieren von Brightnes etc die Lampe über das DOIF wieder an.
Und das die ganze Nacht.
Hatte das schon zwei drei mal so.
Abhilfe schaft nur Readings am Bewegungsmelder löschen.
Kann natürlich auch was falsch an meinem DOIF sein.
Werde das mit state:sec mal versuchen, danke.
Meine Rede.
Nach Neustart wird das reading der letzten Speicherung wieder aktiviert.
Allerdings solltest du erst einmal einen Update machen und das verhalten prüfen. Motion bleibt jedenfalls nicht mehr erhalten.
Oh man, mir ist gerade das Herz in die Hose gerutscht.
Ich habe gerade bei Scharfschaltung des Gebäudes einen FHEM-Neustart durchgeführt.
In einer ReadingsGroup hebe ich während der Scharfschaltung alle Timestamp-Änderungen (nach Zeitpunkt Scharfschaltung) rot hervor.
Plötzlich waren alle BM rot. Bedeutet normalerweise: Da ist jemand eingebrochen.
Ich vermute mal, dass die - hier besprochene - Änderung unumgänglich ist, oder?
Ich hatte die Probleme vorher nicht. Nun muss ich höllisch aufpassen, dass ich während der Scharfschaltung keinen Neustart durchführe.
Schade.
Wenn Du Damus Problem verstehen kannst, musste da eigentlich schon eine Anpassung her. Dass ein Bewegungsmelder auf motion stehen bleibt, nur weil der interne Timer zum Setzen auf noMtion durch einen Neustart "vernichtet" wurde, ist das eigentlich nicht nett. Insofern ist der Ansatz, beim Neustart alle Melder auf "noMotion" zu setzen, schon besser.
Dein Problem ist, dass die Readings erneuert werden, obgleich es nichts zu erneuern gibt.
Martin, "motion" wurde doch bisher beim Neustart über das statefile gesetzt, oder? Heißt das jetzt aber doch, dass Du NACH dem Laden des Statefiles nochmal die Bewegungsmelder auf noMotion setzt? Könnte man das Setzen hier auf die Melder beschränken, die im statefile auf "motion" waren?
Dann würde das mit der readingsGroup auch wieder funktionieren.
Jm2c.
Kann man machen.
Das Problem ist, dass man nie weiß wie alt das statefile ist. Ich habe damit keine guten Erfahrungen
Hmm, aber viele andere Geräte machen das doch auch so, oder?
So stellt man exakt den Zustand wieder her wie vor dem Neustart. Und erzeugt keine neue Readings bzw. verursacht keine aktualisierten Timestamps.
Ich bin ja froh, dass es für "motion" nun eigene Readings gibt.
Es würde mich sehr freuen, wenn du hierzu eine schöne Lösung finden würdest.
Danke dir.
Zitat von: martinp876 am 09 Januar 2017, 21:48:32
Kann man machen.
Das Problem ist, dass man nie weiß wie alt das statefile ist. Ich habe damit keine guten Erfahrungen
Das ist eigentlich doch egal? Entscheidend ist doch nur sicherzustellen dass nach dem Neustart kein Melder in "motion" hängenbleibt.
via Tapatalk
A) mit der aktuellen Lösung sollte kein Melder in Motion hängen bleiben. Irre ich mich?
B) wer will kann sich auf das statefile verlassen. Ich nicht, oder nur bedingt.
B1) wenn fhem abstürzt wird das statefile nicht geschrieben und es bleiben alte Werte stehen.
B2) schaltet man eine Zeitlang aus, egal ob absichtlich oder nicht , können sich beliebigen Zustände verändert haben
Mir ist klar, es gibt andere Ansichten. Meine ist ganz klar: nach einem Start werden alle(!) Statuszustaende so sie abfragbar sind abgefragt. Macht autoreadreg für dich, wenn du willst. Auf das statefile verlassen ich mich nicht. Die 95% reichen mir sicher nicht - warum sollten sie?
Es bleiben Lücken, wobei die von Motion noch leicht zu schliessen ist, und es schon sein sollte.