zuerst muss ich mich entschuldigen, da ich noch nicht einmal weiss ob meine Frage in diesem Unterforum richtig platziert ist.
Eigentlich ist sie auch total banal, aber anscheinend nutze ich die falschen Sucheingaben so dass ich keine Lösung finde.
Wie kann ich den Input eines binären Sensors über die Zeit glätten, so dass kurze Schwankungen nicht gleich relevant werden?
Mein Anwendungsbeispiel:
Ich habe mir aus einem Zigbee Wassersensor und einem Dünnfilm-Drucksensor einen Präsenzsensor für ein Bett gebaut. Der Sensor gibt nur „true“ oder „false“ aus und ich möchte nicht, dass jede kurzeÄnderung (z.B. beim Umdrehen usw.) gleich eine Aktion triggert. Dementsprechend möchte ich den Sensor über eine Zeit XY „glätten“. Nur wenn eine Bedingung über diese Zeit XY durchgehend erfüllt ist soll die Variable schalten. Die Zeit soll wie ein Fenster über den Input gleiten.
Analog dazu gibt es sicherlich jede Menge andere Anwendung bei denen man erst bei „anhaltender Auslösung über eine gewisse Zeit“ schalten möchte, aber ich bin zu blöd hier den richtigen Ansatz zu finden.
Die einfachste Idee. Auf Änderung Triggern. Wenn false (Bett frei) Script-Timer starten. Wenn true (Bett belegt) Script-Timer auf 0 setzen. Timer z.B. auf 1 Minuten setzen. Wenn der Timer abgelaufen bedeutet es das 1 Minute das Bett nicht belegt war und man kann machen was man in dem Fall machen möchte.
Und falls du kein Programmier-Profi bist, kannst du das auch via Ablaufplan umsetzen: Bei true starten, Deine Wunschzeit warten und wenn dann immer noch true, machst du weiter.
genau mein Gedanke, das Probleme habe ich auch mit Zigbee PIRs, eigentlich müsste das Archiv der letzten Minute oder so ausgewertet werden, dann weiß man, ob der Switch an war.
Gedanke zu einer Lösung ohne Archiv: Bei ON einen Timer starten, der nach Verzögerungszeit xx den Zeitpunkt der letzten Änderung überprüft. Damit findet man heraus ob sich die Variable zwischenzeitlich geändert hat.
Stimmt, wäre aber sicherlich die einfachste Implementation. Alternativ macht man ein „Warte auf Wert“ mit false und der gewünschten Wartezeit. Falls danach der Wert noch true ist, ist die Wartezeit abgelaufen und die Aktion wird durchgeführt. Dafür muss im Ablaufplan natürlich eingestellt werden, dass bei Fehlern fortgeführt wird. Das wäre die komplexere, aber auch umfassendere Variante.
Ich finde gute Idee. Wenn aktuell Bett nicht belegt angezeigt wird und letzte Änderung > X Minuten zurück liegt machen was auch immer man will. Noch einfacher als meine Timer-Lösung.
danke für die vielen Antworten! Dann gibt es zumindest keine ganz einfache Lösung aus der Dose für das Problem und ich habe mich beim Suchen nicht ganz doof angestellt.
Nein, PHP ist (leider) nicht meins - aber ich versuch mich mal in den Ablaufplan hereinzufuchsen… kann ich ja quasi aus dem Bett heraus machen
Okay, hier mein Versuch (inspiriert von Euren Ideen).
Ich habe für mich entschieden, dass ich für meinen Usecase vor allem ein falsches „false=unbelegt“ vermeiden möchte und den Ablaufplan entsprechend biased für „true=belegt“ angelegt. Begründung ist, dass der Präsenzmelder die Rollos heruntergefahren lassen soll; er ist als „Fensterkontakt“ für das Schließen der Rollos im Blind Control Modul eingebunden. Jegliche Änderung des Status würde ansonsten zum hoch- und runterfahren der Rollos führen und die Bettruhe wäre dahin.
Ausgelöst wird der Plan durch „true“ des Sensors, bei Fehlern soll er weiter ausgeführt werden und erneute Ausführungen sollen bei laufendem Plan abgelehnt werden (wobei ich nicht genau einschätzen kann ob das so sinnvoll ist).
Auch ob ich einmal oder mehrmalig bei wiederholt ausgelösten Bedingungen auslösen soll habe ich nicht ganz verstanden.
So sieht der Entwurf des Plans aus. Würde das funktionieren? Blöd wäre nur wenn der Sensor nach der Wartezeit zufällig „false“ liefern würde.
Im Endeffekt habe ich wahrscheinlich nicht dass was ich eigentlich will sondern ich verschaffe mir immer 5 Minuten ruhe und muss hoffen dass ich zum nächsten Prüfungszeitpunkt den richtigen Input habe… Verwirrend. Aber schon mal besser als vorher.
Edit 2: Tatsächlich nicht optimal: nach 5min würde der erste kurzfristige „false“ die Rollos zum Hochfahren bringen. Mist! Zurück auf start.
Anderer Ansatz:
Lese in regelmäßigen Intervallen die Daten der zb. letzten 10min aus dem Archiv. Berechne daraus daraus den Mittelwert.
Ist dieser exakt „1“ weißt du das der Wert über den ganzen Zeitraum „1“ war.
Gleiches gillt sinngemäß für „0“.
oder noch anders: Bei jedem Event liest du die Daten der letzten x Minuten aus. Darin suchst du nun ob es innerhalb der letzten y Minuten eine Änderung gab.
Wenn „ja“ → ignorieren
Wenn „nein“ → letzen Wert als Status für deine Steuerung übernehmen
Hast du mit dem Ablaufplan tatsächlich Probleme bekommen oder reden wir von hypothetischen Situationen? Ich gebe zu, ich habe zu Hause einige vergleichbare Ansätze genau so implementiert, da die Wahrscheinlichkeit, dass jetzt zwei kurze Impulse genau 5 Minuten auseinander liegen verschwindend gering ist und ich damit bisher keinen Ärger hatte. Das liegt aber natürlich am Anwendungsfall ob die Wahrscheinlichkeit tatsächlich so gering ist.
Alternativ würde ich dir vorschlagen das Warten durch ein „Warte auf Wert“ auf der entsprechenden Variablen ersetzen. Da wartest du dann auf false mit einer Wartezeit von 5 Minuten. Alles weitere lässt du genau so. Ist die Bedingung true danach noch erfüllt, sind die 5 Minuten abgelaufen und die Variable ist in der Zwischenzeit nie false gewesen. Da allerdings ein Ablaufen von „Warte auf Wert“ als Fehler gewertet wird, müsstest du bei Einstellungen angeben, dass bei einem Fehler einfach fortgeführt werden soll.
@Dr.Niels
Nein, real getestet habe ich noch nicht, allerdings hatte ich den Ablaufplan so verstanden dass er nach 5min Warten dann beim nächstbesten „False“ schaltet. Falls er sich nach der Wartezeit jedoch beendet und mit true neu startet wäre es tatsächlich eine pragmatisch Lösung (für meine Kenntnisse).
@bbernhard
Ja, das klingt nach einer Lösung für diese „fuzzy logic“ Problem. Ich hatte überlegt ob man die Variable zyklisch abfragt und einen Art Counter machen kann. Wenn eine gewisse Menge an „false“ in einer defininierten Zeit erreicht wird wird die Variable auf False gesetzt. Ein zwischenzeitliches „true“ setzt den Zähler wiederum zurück und er beginnt wieder bei Null. Also noch komplizierter als Dein Ansatz! Allerdings überschreitet diese und ich befürchte auch Deine Lösung mein Können und ich denke nicht dass sich so komplexe Abläufe ohne Programmierkenntnisse abbilden lassen…
Das erneute Auslösen bringt mich tatsächlich auf einen alternativen Ansatz. Du könntest das Ereignis anstatt bei einem bestimmten Wert bei jeder Änderung auslösen. Als erste Aktion machst du dann eine Bedingung, dass der Wert true sein muss, und wartest dann wie gewohnt deine 5 Minuten und setzt dann abwesend.
Damit das ganze funktioniert, musst du in den Einstellungen bei „Verhalten bei laufender Ausführung“ die Option „Bei neuer Ausführung laufende Ausführung abbrechen“. Wenn dann der Wert true wird, wird die Wartezeit gestartet, da die initiale Bedingung ja erfüllt ist. Sollte dann während der Wartezeit der Wert auf false wechseln, wird der Ablaufplan aufgrund der Einstellungen neu gestartet und direkt wieder abgebrochen und somit die Aktionen nach der Wartezeit nicht ausgeführt. Schließt die Wartezeit ab, gab es keine Änderungen in der Zwischenzeit und du hast sichergestellt, dass der Wert 5 Minuten auf true war.
Anmerkung dazu: In meinem KNX-Logikmodul gibt es dafür den Funktionsblock Ein/Ausschaltverzögerung. Der macht genau dieses, incl. der Auswertung auf zwischenzeitliche Änderung des Eingangssignals, dann wird das Schaltsignal ggf verworfen.
Vielleicht wäre das auch was für IPS, als einfach einsetzbares fertiges Element für den Ablaufplan?
@volkerm Ich würde seinen Vorschlag schon mal sehr unterstützen!
Ich ändere mal schnell den Ablaufplan nach @Dr.Niels, morgen füh werde ich dann wissen ob die Rollos nach Wochenplan hochfahren oder erst wenn wir uns aus dem Bett wälzen…
Danke nochmals!
Edit: @Dr.Niels
Ich nehme an ich muss dann auch bei Fehlern abbrechen lassen?
Wie sichergestellt wird das der Wert true bleibt habe ich verstanden - aber wie kann in Deinem Vorschlag ein „false“ entstehen? Also sprich wenn ich tatsächlich aus dem Bett bin? Weil jegliche Änderung des Inputs bricht den laufenden Plan doch ab und False erfüllt nicht die erste Bedingung so dass der neue PLan ebenfalls abgebrochen wird und damit alles auf „true“ stehen bleibt?
Oh, den false-Fall habe ich dann noch nicht verstanden. Aber wenn du bei beiden etwas machen möchtest, kannst du die initiale Bedingung auch einfach rausnehmen und nach der Wartezeit zwei „Wenn… dann…“ Blöcke nutzen um zu differenzieren, ob du jetzt 5 Minuten true oder 5 Minuten false hast.
Okay, ich weiss auch nicht wie ich es technisch korrekt wiedergeben soll um es korrekt in Maschinensprache zu übersetzten. Aber Ein- und Ausschaltverzögerung trifft es ganz gut.
Sensor gibt an ob ich noch im Bett liege (true) oder nicht (false) und steuert damit die Rollos.
Wenn ich mich kurz umdrehe/aufsetze möchte ich nicht dass die Rollos hochfahren um dann Sekunden später wieder runterzufahren weil der Sensor empfindlich ist und schnell reagiert. Oder wenn ich kurz auf Klo gehe soll mein „virtueller Sensor“ noch belegt (true) anzeigen obwohl ich tatsächlich nicht mehr im Bett bin (eigentlicher Sensor meldet natürlich false) und die Rollos erst mal geschlossen bleiben. Somit eine Art von Ausschaltverzögerung durch Überprüfung des Status über einen Zeitraum hinweg.
Wenn ich dann aber länger als XY min kontinuierlich aus dem Bett bin soll der virtuelle Sensor dann auch auf false gehen um die Rollos zu öffnen.(Die eigentlich Aktion ist dann noch mit anderen Bedingungen wie Zeit und Helligkeit bedingt).
Auf der anderen Seite das selbe mit Spiel beim Einschalten. Kurzes auf dem Bett sitzen soll noch nicht die Rollos runterfahren, längeres, kontinuierliches dann schon.
