HMIP-SMO Programmierung Bewegungsmelder und Zeitsteuerung krieg ich nicht hin -- Wo ist der Fehler

[Xel66]

Du verwendest den BWM im Programm für die Erkennung von Bewegung und keiner Bewegung. Daher triggern beide Ereignisse das Programm. Trenne Die Programme sinnvoll auf. Die Ursache dafür liegt in der Art, wie die CCU die Programme abarbeitete. Sieh Handbuch zu WebUI. Das hat nicht unbedingt was mit dem menschlichen Verständnis von Logik zu tun. Es ist eine Eigenart der CCU und ihrer Logik.

Gruß Xel66

[Hugo Oberstein]

Hallo Xel66,
vielen Dank mal wieder für die schnelle Antwort. Verstanden habe ich deine Erklärung allerdings nicht.
Ich verwende ja im Alarmprogramm nur den Auslöser "Bewegung erkannt" eigentlich für das setzen einer Systemvariable, die dann wiederum die Sirene triggert. Jetzt macht sie nur die Lampe an, weil ich die Nachbarn nicht dauernd mit fehlalarmen nerven will.

Keine Bewegung erkannt triggert nichts bei mir, daher sollte das Programm auch eigentlich nicht ausgeführt werden.

Variante 1

und auch Variante2 habe ich ausprobiert ohne Unterschied

Variante 2

Wie gesagt, verstehen tue ich es nicht, aber vielleicht kannst du es mir noch mal verständlicher erläutern bitte, warum das Licht trotzdem angeht...

Vielen Dank

hugo

[Xel66]

Wenn einer Deiner BWM auf "keine Bewegung" geht, dann wird das Programm trotzdem getriggert, weil dieser Statuswechsel erst bei der Bedingungsprüfung geprüft wird. Du hast aber beide BWM verODERt und darum läuft die Prüfung wenn einer der beiden noch auf "bei Bewegung" steht, in ein WAHR und arbeitet das zugehörige DANN ab. Soll heißen, der Trigger wird nicht vor der Bedingungsprüfung eines
Programms auf Wahrheitsgehalt geprüft, sondern erst zur "Laufzeit" des Programms, also während der Bedingungsprüfung.

Ist eine Eigenheit der CCU und der ereignisgesteuerten Auslösung von Programmen geschuldet und hat schon oft zu Missverständnissen geführt. Im Handbuch steht es zwar anders, aber vermutlich weil bei einfachen Programmen das keinen Unterschied macht und dem beobachtbaren Verhalten entspricht. Dieses eigenartige Verhalten fällt einem erst bei solchen verODERten Triggern auf die Füße, weil es nicht der logischen menschlichen Denkweise entspricht. Ich habe darüber hier im Forum auch schon einige Diskussionen geführt. Dein Programm ist quasi ein Paradebeispiel für diese Arbeitsweise. Abhilfe schafft nur eine Aufteilung in ein Programm pro BWM.

Gruß Xel66

[Hugo Oberstein]

Hallo Xel66,
da habe ich wieder was gelernt. d. h. ich muss für jeden Bwm und jeden tfk ein separates Programm schreiben, richtig?
Die TFKs sind nämlich auch über verODERt mit Zustand offen.

Das doch würde bedeuten (wenn ich die Logik richtig verstanden habe),, dass im Sommer, wenn zwei Fenster noch offen sind wenn die Alarmanlage scharf geschaltet wurde , dass sie auch dann auslöst, wenn eins später geschlossen wird, weil das andere noch auf offen steht, richtig?


Also Ziel ist es, keine ODER Verknüpfung mehr in den Bedingungen zu haben.
Kann ich das der Übersicht halber in einem Programm mit "sonst wenn" machen oder müssen es immer separate Programme sein?

Dann hätte ich bei den ganzen TFK ne Menge simpler Programme, die die Übersichtlichkeit deutlich verringern.... Wenn das aber zu einem robusten Verhalten der Alarmanlage führt, würde ich es machen.

[Xel66]

... dass im Sommer, wenn zwei Fenster noch offen sind wenn die Alarmanlage scharf geschaltet wurde , dass sie auch dann auslöst, wenn eins später geschlossen wird, weil das andere noch auf offen steht, richtig?

Soweit richtig verstanden. Es ist auch sinnfrei, eine Alarmanlage scharfzuschalten, wenn noch Fenster geöffnet sind. Das würde ich gegeneinander verriegeln. Wir leben hier auf der Erde und nicht auf Vogon (Stichwort: Gartenzauntür - das ist ein Insider). Das kann Dir schon bei einer zyklischen Übermittlung der Status eines der verODERten TFK auf die Füße fallen. Da muss man nicht mal ein Fenster schließen.

Also Ziel ist es, keine ODER Verknüpfung mehr in den Bedingungen zu haben.

Das Ziel definierst Du. Zum Aufteilen in SONST WENNs verweise ich auf die Beschreibung der Abarbeitung und Triggerung von Porgrammen in der CCU-WebUI. Ich lege keine Inhalte von Handbüchern hier dar. Es ist zwingend notwendig, dass Anwender sich mit dieser Anleitung auseinandersetzen müssen, wenn sie erfolgreich eigene Programme erstellen wollen und nicht von den Aktionen ihrer Programme überrascht werden wollen. Kurzer Hinweis: SONST WENNs funktionieren nicht, sie agieren innerhalb von Programmen wie große ODER. Wenn TFK das Programm nicht triggern sollen, dann braucht man sie auch nicht in das Programm mit aufzunehmen.

Gruß Xel66

[MichaelN]

Und noch ein Tipp : vergiss die Handbücher. Deren Beschreibung zur Funktionsweise ist im günstigen Fall leicht missverständlich, meiner Meinung nach aber komplett falsch.

ich habe für mich inzwishcen folgende Regeln aufgestellt:

- Komplexe SONST-WENN-Regeln vermeiden, besser statt SONST-WENN eigenes Programm verwenden
- nicht „bei Aktualisierung“ und „bei Änderung“ mischen; kein Trigger im SONST-WENN, der nicht schon im WENN steht

[Hugo Oberstein]

Hallo Xel66,
hallo Michael,
danke für die Hinweise und Tipps. Ich habe die bereits einen großen Teil meiner Programme jetzt verändert bzw. umgestellt und werde testen, ob es funktioniert.

Gerade die Regeln:

- Komplexe SONST-WENN-Regeln vermeiden, besser statt SONST-WENN eigenes Programm verwenden
- nicht „bei Aktualisierung“ und „bei Änderung“ mischen; kein Trigger im SONST-WENN, der nicht schon im WENN steht

waren für mich sehr hilfreich.
Noch mal vielen Dank !

Wieder eine Menge gelernt!

Hugo.