Bewegungsmelder ignorieren Einstellungen #1196
Replies: 9 comments 2 replies
-
|
Tut mir leider aber auf dieses Verhalten hat RaspberryMatic selbst keinerlei Einfluss, denn die Bewegungsmeldungen finden völlig autark im Bewegungsmelder selbst statt. RaspberryMatic kann hierbei nur die jeweiligen Parameter (Sendeabstand, Empfindlichkeit, etc.) im Bewegungsmelder einstellen. Die gesamte Bewegungserkennung und Meldelogik passiert im Gerät selber und darauf hat RaspberryMatic keinen Einfluss. D.h. es leitet die Eventmeldungen die vom Bewegungsmelder kommen einfach stumpf dann an die registrierten Schnittstellenprozesse (in deinem Fall ioBroker) weiter. Und da die Firmware der Bewegungsmelder closed source ist kat RaspberryMatic selbst auf das Auslöseverhalten keinerlei Einfluss. |
Beta Was this translation helpful? Give feedback.
-
|
Hm.... |
Beta Was this translation helpful? Give feedback.
-
|
Inwiefern? Also zumindest wüsste ich nicht wie? Aber vielleicht hat ja @jp112sdl eine Idee dazu oder ich hab das Problem noch nicht ganz durchschaut. Wie gesagt findet die gesamte Auswertung der Bewegung komplett autark im Gerät selbst statt und RM hat darauf (ausser mittels umstellen der Parameter) keinerlei direkten Einfluss. |
Beta Was this translation helpful? Give feedback.
-
|
Unabhängig von dem falschen/autarken Verhalten des Gerätes selbst, wäre es m.E.n. nicht verkehrt, wenn die Raspberrymatic sagt: "Wenn ich nach einer gemeldeten Bewegung |
Beta Was this translation helpful? Give feedback.
-
Das Problem ist meiner Meinung nach der Schnittstellenprozess. Dieser muss ja der ReGa das Event melden. So als Brainstorming Gedanke: Du könntest versuchen, es mit einem Skript zu lösen und das Event faken. Ich weiß aber nicht, ob es reicht, einfach aus BidCos-RF ein HmIP-RF zu machen. Dann prüfst du zyklisch mit |
Beta Was this translation helpful? Give feedback.
-
|
@theimo1221 Ich hoffe es ist ok das ich dein Issue jetzt in einen Diskussionsbeitrag umgewandelt habe, denn ich sehe hier weiterhin keinen wirklichen Ansatz hier inhaltlich in RaspberryMatic selbst etwas daran zu ändern. Wie gesagt funktioniert diese ganze Bewegungsmeldung/auswertung völlig autark im Gerät und die Bewegungsevents werden lediglich an RaspberryMatic gemeldet ohne das da eine Auswertung passiert. Und wenn dann müsste man das wie @jp112sdl eben im Nutzerkontext irgendwie umsetzen wenn man das verhalten anders haben will - oder eben das als Verbesserungsvorschlag an eQ3 melden. |
Beta Was this translation helpful? Give feedback.
-
|
Für mich ist das Eindeutig ein Fehler in der Firmware des Bewegungsmelders! Das es bei Dir nicht immer auftritt (sowie die "zwischengeschobenen" Meldungen) könnte mit den zykl. Statusmeldungen, oder mit den Sendungen bei Änderung des Helligkeitswertes zusammenhängen. Das kann man aber effektiv nur in einer Dunkelkammer testen. Edit: Nach rund 45 Minuten hat mein SMI55 eine zykl. Meldung gesendet und damit auch wieder den Status auf "keine Bewegung erkannt" gesetzt. Theoretisch könntest du also dein Problem umgehen indem du den Intervall der zykl. Meldungen verringerst. Was aber dann sicher auf die Batterielaufzeit und eventuell den Duty Cycle Auswirkungen hat. Letztlich kann aber nur eQ-3 das mit einem Firwareupdate wirklich fixen. So, lange genug stillgesessen... ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Das Problem mit den Bewegungsmeldern ist m. E. deutlich umfangreicher. Immerhin habe ich eQ3 nach mehreren Wochen davon überzeugen können, dass bei HmIP-SMO der Ch2 gar nicht gesteuert werden kann. Selbst in DVs. Das war ja leider schon schwer genug, da es erst wochenlang an CUxD gelegen haben soll^^ |
Beta Was this translation helpful? Give feedback.
-
|
Naja, wenn ich ein's weiß, dann das CUxD immer Schuld ist! ;-)
Das ist "Unterdrückung der Bewegungserkennung", oder? Der Kanal lässt sich doch eh nur mit DV verwenden und nicht in Programmen. Und DV geht da beim SMO auch nicht? |
Beta Was this translation helpful? Give feedback.
-
|
Genau so... das ist auch einfach nur peinlich... ich würde mich schämen, da im "Support" zu arbeiten... |
Beta Was this translation helpful? Give feedback.
-
|
22:58:55.959 Presence Update (true) for "1. OG Kueche Praesenzmelder" Ist übrigens beim Präsenzmelder auch fehlerhaft aber anders. Einstellung in dem Raum
Sprich er hätte das erste Mal frühestens um 23:01:24 auf false setzen dürfen und beim 2. Mal ist er auch 30s zu früh. Was man sagen kann ist, dass der Präsenzmelder seinen Timer nicht neustartet (bei erkannter Bewegung) aber zumindest seinen Timer seit der ersten erkannten Bewegung einhält. |
Beta Was this translation helpful? Give feedback.
-
Meine Bewegungsmelder legen Zeiten regelmäßig scheinbar so aus wie sie wollen.
Kontext:
Ich nutze die Bewegungsmelder mittels ioBroker (rpc) in meiner eigenen HomeAutomation (NodeJS über Socket.io an ioBroker).
Falls Bewegungsmelder 10 Minuten keinen neuen Wert melden, interpretiere ich es lokal, als hätten sie sich selber zurückgesetzt.
Dies war eine Vorsichtsmaßnahme, nachdem sich sporadisch Bewegungsmelder selber nicht mehr gemeldet haben, dass nun die Bewegung wieder zu Ende ist.
Vermehrt tritt dieses Verhalten auf, wenn ein Bewegungsmelder vor Ablauf der Zurücksetzzeit erneut auslöst.
Gegenbeispiel
I20210327-23:09:59.999(1)? Neuer Bewegunsstatus Wert für "Bewegungsmelder Treppenaufgang Oben": true...
I20210327-23:14:58.601(1)? Neuer Bewegunsstatus Wert für "Bewegungsmelder Treppenaufgang Oben": falseSteps to reproduce the behavior
Mindestsendeabstand = 2 Minuten; Zurücksetzen der Bewegung = 4 MinutenbetreibenExpected behavior
Bewegungsmelder hält sich exakt an die vorgegebenen Zeiten
Screenshots
Im Abschnitt oben, sind die Zeiten generell spooky, da die Zweite Meldung nicht mind. 2 Minuten alt ist.
Anschließend kommt erst nach 4,5 Minuten die erneute Meldung der erneuten Bewegung --> hier hätte ein "Keine Bewegung erkannt" nach 4 Minuten mit anschließendem "Neue Bewegung erkannt" erfolgen müssen
System information:
Beta Was this translation helpful? Give feedback.
All reactions