01-10-2013, 16:42:45
(Dieser Beitrag wurde zuletzt bearbeitet: 01-10-2013, 16:44:32 von THellweg.)
Hi Medaber,
Die Folge wäre eine deutlich messbare, bis nicht tolerierbare, Schaltverzögerung des Ereignisprofiles.
Es ist ja allgemein bekannt, das Logikprofile langsamer agieren, u.a. weil konditionale Operatoren geprüft werden müssen.
Wenn man deine Wunschpriorisierung "Konflikt mit Logikprofil vor Auslösung von Ereignis prüfen - Ereignis nur wenn kein Konflikt" so umsetzen würde, dann gäbe es sicherlich Hunderte von Gegenstimmen.
Hier mein Vorschlag zur Umgehung der vielen kurzzeitigen Einschaltungen:
1) Verwende das Bewegungsereignis des BM nicht zum unmittelbaren Einschalten der Lichter, sondern stelle damit eine ZV auf AN.
2) Das AN dieser ZV verwendest du in einem Logikprofil mit einer UND Verknüpfung deiner ZV "Öko" AUS um die Lampen zu schalten.
3) Somit hast du das Arbeitsprofil aus der Ereignisebene auf die Logikebene verlagert und dein Problem tritt nicht mehr auf.
Eine technisch pfiffigere Lösung anzuwenden und dabei auch einmal "um die Ecke zu denken" ist hier sicherlich auch einfacher, als die bewährte Verarbeitungsfolge der Profile zu ändern nur weil die Umsetzung des Usecases nicht optimal durchdacht war.
ZVs als Bindeglieder zwischen Sensoren und Aktoren eignen sich hervorragend zur Flexibilisierung der früher starren Sensor-Aktor Verbindungen. Man kann damit vielfältige Limitationen umgehen, wie z.B. die Tatsache, dass ein Zeitprofil nur acht Schaltpunkte pro Tag haben kann und dass ein Gerät nur in einem Zeitprofil, pro Tag, vorhanden sein darf. Mit ZVs kann ich theoretisch uneindlich viele Schaltpunkte pro Gerät/Tag definieren. Auch die Verknüpfung mit der aktuellen Uhrzeit, als Bedingung in Logikprofilen, ist über die Nutzung von ZVs möglich. Nebenbei macht das Arbeiten mit den Dingern auch noch Spass!
Viele Grüße,
Thomas
(01-10-2013, 13:31:02)medaber schrieb: Daher hier mal meine naive Frage, ob es nicht logischer Wäre, wenn VOR der Schaltung, Logikprofile geprüft würden...Die einhergehende logische Folge wäre, dass vor dem Ausführen der eigentlichen Schaltung alle vorhandenen Logikprofile durchsucht werden müssten, ob dieses Gerät darin vorkommt und ob der zur Ausführung anstehende Schaltvorgang durch eines dieser Profile wieder zurückgesetzt werden würde.
Die Folge wäre eine deutlich messbare, bis nicht tolerierbare, Schaltverzögerung des Ereignisprofiles.
Es ist ja allgemein bekannt, das Logikprofile langsamer agieren, u.a. weil konditionale Operatoren geprüft werden müssen.
Wenn man deine Wunschpriorisierung "Konflikt mit Logikprofil vor Auslösung von Ereignis prüfen - Ereignis nur wenn kein Konflikt" so umsetzen würde, dann gäbe es sicherlich Hunderte von Gegenstimmen.
Hier mein Vorschlag zur Umgehung der vielen kurzzeitigen Einschaltungen:
1) Verwende das Bewegungsereignis des BM nicht zum unmittelbaren Einschalten der Lichter, sondern stelle damit eine ZV auf AN.
2) Das AN dieser ZV verwendest du in einem Logikprofil mit einer UND Verknüpfung deiner ZV "Öko" AUS um die Lampen zu schalten.
3) Somit hast du das Arbeitsprofil aus der Ereignisebene auf die Logikebene verlagert und dein Problem tritt nicht mehr auf.
Eine technisch pfiffigere Lösung anzuwenden und dabei auch einmal "um die Ecke zu denken" ist hier sicherlich auch einfacher, als die bewährte Verarbeitungsfolge der Profile zu ändern nur weil die Umsetzung des Usecases nicht optimal durchdacht war.
ZVs als Bindeglieder zwischen Sensoren und Aktoren eignen sich hervorragend zur Flexibilisierung der früher starren Sensor-Aktor Verbindungen. Man kann damit vielfältige Limitationen umgehen, wie z.B. die Tatsache, dass ein Zeitprofil nur acht Schaltpunkte pro Tag haben kann und dass ein Gerät nur in einem Zeitprofil, pro Tag, vorhanden sein darf. Mit ZVs kann ich theoretisch uneindlich viele Schaltpunkte pro Gerät/Tag definieren. Auch die Verknüpfung mit der aktuellen Uhrzeit, als Bedingung in Logikprofilen, ist über die Nutzung von ZVs möglich. Nebenbei macht das Arbeiten mit den Dingern auch noch Spass!
Viele Grüße,
Thomas