15-01-2015, 06:48:14
(Dieser Beitrag wurde zuletzt bearbeitet: 15-01-2015, 06:56:09 von THellweg.)
Hallo zusammen,
der Lösungsvorschlag von Alfred ist technisch gesehen richtig.
Ich möchte aber gerne ein paar prinzipielle Bemerkungen zur Sinnhaftigkeit solcher Szenarien und den damit verbundenen Risiken anbringen und zu allererst an die goldene Regel "keep it simple" erinnern.
Gerade wenn der Spieltrieb groß ist und man daher versucht ist, jede eventuell auftretende Situation mit einem SmartHome Profil "zu regeln", läuft man Gefahr sich sein System langsam aber sicher mit minderwichtigen bis fast nutzlosen Profilen und den dafür erforderlichen Zustandsvariablen "zuzumüllen". Dass dabei die Übersichtlichkeit leidet ist nur ein Punkt. Viel schlimmer ist es wenn Logikprofile ohne Auslöse-Ereignis ständig Rechenleistung der Zentrale beanspruchen, obwohl der Usecase, für den man ein solches Profil irgendwann einmal angelegt hatte, nur alle paar Jahre tatsächlich eintritt. Dazu kommen weitere Auswirkungen, über die man sich nicht immer sofort im klaren ist.
Nehmen wir dazu das obige Beispiel:
Hier werden zwei ZV erstellt und die Auslösung der Beleuchtung der Einfahrt wird von Ereignis-Steuerung auf Logik-Steuerung umgebaut, nur um im Falle einer Party zu verhindern, dass die Beleuchtung in der Einfahrt immer eingeschaltet wird.
Ich frage zunächst nach dem Sinn, denn warum sollte die Beleuchtung den kommenden und gehenden Partygästen nicht den Weg erhellen? Dazu ist diese Beleuchtung, in Kombination mit dem Bewegungsmelder, doch eigentlich gedacht oder nicht?
Jetzt zur technischen Seite:
Das Logikprofil verwendet zwar zwei ZVen, hat aber ein auslösendes Ereignis und ist somit also kein Profil welches unnötige viel Rechenleistung der Zentrale absorbiert. So weit so gut!
Andererseits ist die Schaltung der Beleuchtung der Einfahrt von nun an unmöglich wenn die SmartHome Zentrale nicht erreichbar ist (z.B. bei einem "freeze"), denn Logikprofile müssen von der Zentrale berechnet werden und können daher ohne Zentrale nicht arbeiten.
Vorher war es ein Ereignisprofil bei dem das Gerät "Bewegungsmelder" direkt mit dem Gerät "Licht" interagieren konnte ohne dazu die Zentrale zu benötigen.
Dieser Umstand wäre für mich schon Grund genug, den Vorschlag nicht umzusetzen und das bisherige Ereignisprofil so zu belassen wie es ist.
Die Nachteile, die ich mir damit einhandeln würde, habe ich aufgezählt (Erhöhung der Komplexität durch zusätzliche ZVen, Profile und die Abhängigkeit von der Zentrale) und diese stehen in keinem guten Verhältnis zum Nutzen und dem eigentlichen Sinn einer bewegungsgesteuerten Beleuchtung.
Fazit: Wäre technisch möglich - wird aber nicht umgesetzt.
Viele Grüße,
Thomas
P.S. @oanser: Ich möchte dich damit sensibilisieren, damit Du nicht auch in zwei Jahren über ein kaum noch benutzbares weil krückenlahmes SmartHome-System klagen musst, nur weil Du 200 ZVen und 90 Logikprofile hast, von denen Du eigentlich nur ein Viertel tatsächlich benötigen würdest. Also, keep it simple!
Nicht so viele ZVen und Logikprofile wie möglich - nur so viele wie nötig!
der Lösungsvorschlag von Alfred ist technisch gesehen richtig.
Ich möchte aber gerne ein paar prinzipielle Bemerkungen zur Sinnhaftigkeit solcher Szenarien und den damit verbundenen Risiken anbringen und zu allererst an die goldene Regel "keep it simple" erinnern.
Gerade wenn der Spieltrieb groß ist und man daher versucht ist, jede eventuell auftretende Situation mit einem SmartHome Profil "zu regeln", läuft man Gefahr sich sein System langsam aber sicher mit minderwichtigen bis fast nutzlosen Profilen und den dafür erforderlichen Zustandsvariablen "zuzumüllen". Dass dabei die Übersichtlichkeit leidet ist nur ein Punkt. Viel schlimmer ist es wenn Logikprofile ohne Auslöse-Ereignis ständig Rechenleistung der Zentrale beanspruchen, obwohl der Usecase, für den man ein solches Profil irgendwann einmal angelegt hatte, nur alle paar Jahre tatsächlich eintritt. Dazu kommen weitere Auswirkungen, über die man sich nicht immer sofort im klaren ist.
Nehmen wir dazu das obige Beispiel:
Hier werden zwei ZV erstellt und die Auslösung der Beleuchtung der Einfahrt wird von Ereignis-Steuerung auf Logik-Steuerung umgebaut, nur um im Falle einer Party zu verhindern, dass die Beleuchtung in der Einfahrt immer eingeschaltet wird.
Ich frage zunächst nach dem Sinn, denn warum sollte die Beleuchtung den kommenden und gehenden Partygästen nicht den Weg erhellen? Dazu ist diese Beleuchtung, in Kombination mit dem Bewegungsmelder, doch eigentlich gedacht oder nicht?
Jetzt zur technischen Seite:
Das Logikprofil verwendet zwar zwei ZVen, hat aber ein auslösendes Ereignis und ist somit also kein Profil welches unnötige viel Rechenleistung der Zentrale absorbiert. So weit so gut!
Andererseits ist die Schaltung der Beleuchtung der Einfahrt von nun an unmöglich wenn die SmartHome Zentrale nicht erreichbar ist (z.B. bei einem "freeze"), denn Logikprofile müssen von der Zentrale berechnet werden und können daher ohne Zentrale nicht arbeiten.
Vorher war es ein Ereignisprofil bei dem das Gerät "Bewegungsmelder" direkt mit dem Gerät "Licht" interagieren konnte ohne dazu die Zentrale zu benötigen.
Dieser Umstand wäre für mich schon Grund genug, den Vorschlag nicht umzusetzen und das bisherige Ereignisprofil so zu belassen wie es ist.
Die Nachteile, die ich mir damit einhandeln würde, habe ich aufgezählt (Erhöhung der Komplexität durch zusätzliche ZVen, Profile und die Abhängigkeit von der Zentrale) und diese stehen in keinem guten Verhältnis zum Nutzen und dem eigentlichen Sinn einer bewegungsgesteuerten Beleuchtung.
Fazit: Wäre technisch möglich - wird aber nicht umgesetzt.
Viele Grüße,
Thomas
P.S. @oanser: Ich möchte dich damit sensibilisieren, damit Du nicht auch in zwei Jahren über ein kaum noch benutzbares weil krückenlahmes SmartHome-System klagen musst, nur weil Du 200 ZVen und 90 Logikprofile hast, von denen Du eigentlich nur ein Viertel tatsächlich benötigen würdest. Also, keep it simple!
Nicht so viele ZVen und Logikprofile wie möglich - nur so viele wie nötig!