UZSU Plugin Wunsch ;-)

[schuma]

Ich hätte da mal einen Wunsch für die UZSU!

Mir fehlt aktuell ein Item in der UZSU mit dem ich eine Gruppe schalten kann.
Also einzelne Schalter einer Gruppe zuweisen und dann mit dem Item die jeweilige Gruppe auswählen.
Benutzen würde ich das z.B. für eine abgewandelte UZSU Funktion für den Urlaub oder Sommer/Winter.
Im Urlaub würden dann z.B. die Rolladen morgens nicht mehr hochfahren.

Könnte man so etwas integrieren?

Grüße, Marc

[bmx]

Sorry, ich bin zu blöd den obigen Text zu verstehen sonst würde ich Dir gerne helfen ...

[wvhn]

Also Du willst im Urlaub andere Items schalten, als sonst und möchtest das über eine Bedingung (Urlaub=true) festlegen können? Ich könnte das auch gebrauchen, um z.B. in Abhängigkeit von der Anwesenheitserkennung das Ausschalten des Wohnzimmerlichts durch UZSU zu verhindern, das ziemlich schlecht für den WAF ist . Habe glaube ich mal gelesen, das UZSU das noch nicht kann.

Gruß Wolfram

[schuma]

Ja genau.
Jede Zeile (Schaltung) in der UZSU sollte einer Gruppe zugeordnet werden können.
Und diese Gruppe kann dann über ein ITEM umgeschaltet werden.
Es sollte allerdings auch möglich sein, einer Schaltung auch keine Gruppe zuzuweisen (Also in etwa 0, 1, 2).

Beispiel 1:
Wenn Gruppe eins aktiv ist (Ich bin nicht im Urlaub), fahren die Rolladen alle morgens hoch. Wenn Gruppe zwei aktiv ist (ich bin im Urlaub), bleiben die Rolladen unten oder werden erst gegen Mittag hoch gefahren oder eine Anwesenheit wird damit simuliert.

Beispiel 2:
Im Sommerbetrieb (Gruppe 1) wird das Licht nach Sonnenstand geschaltet. Im Winterbetrieb (Gruppe 2) soll aber nach festen Zeiten das Licht angehen.

Beispiel 3 (Wolfram):
Das Licht im Wohnzimmer (Dekobeleuchtung) wird normalerweise um 22:30 Uhr per UZSU ausgeschaltet. Ist jedoch noch jemand anwesend, wird durch den PM die Gruppe 2 gewählt und somit wird das Licht erst um 24:00 Uhr nochmals "AUS" getriggert.

Marc

[bmx]

Ich fürchte, ihr wollt aus einer Universal Zeitschaltuhr eine eierlegende Wollmilchsau mit State-Machine machen.
IMHO soll eine UZSU zu bestimmten Zeitpunkten ein Item auf einen Wert setzen, nichts anderes.
Wenn dieses Item dann den Wert geändert bekommt, kann man damit eine Logik triggern.
In dieser Logik kann ich abfragen wer den Wert geändert hat und ich kann auch andere Items abfragen. Also kann ich entscheiden ob ich im Urlaub bin und die Rolladen unten bleiben sollen oder ob ich daheim bin und ganz normal Rolladenöffnung haben will.
So kann ich Beispiel 1 erschlagen.

Bei Beispiel 2 kann ich mir auch eine Logik erstellen die von zwei Items getriggert wird: Das erste Item gibt den Sonnenstand und das zweite nur feste Zeiten. Da reicht eigentlich ein crontab und es muß nicht mal eine UZSU sein. Geht aber bei beiden auch mit UZSU.
Die Logik fragt nur ob wir Sommer oder Winter haben und läßt demnach nur das Signal von der ersten oder zweiten Itemtriggerung durch.

Beispiel 3 würde ich versuchen über KNX zu erschlagen.

[schuma]

Aber so hätten man alles was zur Zeitschaltuhr gehört an einem Platz. Und muss nicht erst gucken was in einer Logic weiter hinten passiert.
Ebenso könnte man halt auf Visu Ebene Zustände steuern und braucht nicht immer gleich an eine Logic ran gehen.
Übrigens ist das heute gang und gebe. Guckt Euch mal einen Gira PM Mini an. Der macht das genau so. Und damit lassen sich tolle Dinge einfach so umsetzen.
Bei mir z.B. die Tag / Nachtschaltung der Beleuchtung.
Es kann ja auch mal einfach sein. ;-)

Grüße, Marc

[dafra]

Theortetisch sollte das mit einem "Gruppen-Item" gehen, welches die USZU schaltet. Alle Items die auf dieses Gruppen-Item reagieren sollen, müssen dieses Item in ihre Eval und Eval-Trigger Bedingungen einbinden.

Gruß, Daniel

[schuma]

Hallo Daniel,
dass man das irgendwie alles mit Items und Logik hinbekommt ist nicht das Ding.
Vorrangig geht es mir darum, das später einfach am Tablet in der Wand zu ändern. Ohne einen Rechner - putty etc.
Benutzerfreundlich halt.

Marc

[wvhn]

Moin,

die einfachste Lösung ist ein Gruppen-item, in dem man mehrere GAs hinter knx_send hängt. Das hat aber zur Folge, dass alle GAs zum gleichen Zeitpunkt geschaltet werden. Für eine Anwesenheitssimulation ist das untauglich. Der Vorschlag mit eval auf das Gruppenitem zu reagieren bietet da mehr Möglichkeiten, wenn man mit Autotimer für zeitversetztes Schalten sorgt. Schade ist dabei, dass man das Schaltverhalten in den items fest verdrahten muss und damit kaum Nutzen aus der genial einfach und flexibel programmierbaren UZSU ziehen kann. Das gleiche gilt für die Logiken.

Ich denke auch wie Bernd, dass man keinen Zustandsautomat aus der Zeitschaltuhr machen sollte. Als kleine Lösung wären aber ein oder zwei zusätzliche child-items als Bedingungen in jedem UZSU-item denkbar, mit denen die Timer des UZSU-item akiviert werden. Diese items könnte man beliebig in der Visu schalten oder eval-Funktionen / Logiken auswerten lassen. Beim Update eines dieser items müsste dann dieselbe Funktion ausgeführt werden, die beim Aktivieren oder Deaktivieren des Timers via Visu-widget ausgeführt wird. Zusätzlich müsste per widget einstellbar sein, ob der jeweilige Timer auf die Bedingung "hört" und auf welche.
Beispiel: ich schalte mein Wohnzimmerlicht immer mit Sonnenuntergang ein, will es aber nur automatisch ausschalten, wenn niemand zu Hause ist. Die Anwesenheitserkennung würde dann den 2. Timer ausschalten, wenn jemand im Haus ist und wieder einschalten, wenn das Haus leer ist.

Vorteil der Lösung wäre, dass man nur die Bedingungen fest verdrahten muss, aber alles andere über die Visu konfigurieren kann.

Ich würde dies gerne noch einmal als Feature-Wunsch einspeisen.

Gruß Wolfram

[bmx]

Ich denke das es für zukünftige Dinge einfacher wäre, wenn man für "nicht Programmierer" das Blockly Plugin mal lauffähig macht, das items zur Laufzeit angelegt werden können, Plugin Instanzen zur Laufzeit gestartet oder beendet werden können und evtl. einen eigenen Editor für's Backend für alle UZSU. Damit könnten viele Dinge erschlagen werden und es wäre eine strikte Trennung zwischen Backend und Frontend möglich.
Aber das kann man nicht mal eben aus dem Hut ziehen sondern erfordert sorgfältige Planung und Abstimmung aller Beteiligten verbunden mit dem Willen vieler das auch zu testen.
Derzeit hakt es z.B. am Blockly Plugin, das ist zwar in 1.3 dev vorhanden aber es gibt eigentlich nur zwei Leute, die sich zeitweise damit beschäftigen. Ein wenig mehr Hilfe wäre schon gut...

[schuma]

Hallo Wolfram,
genau so habe ich es gemeint!
Ich drücke mich da evtl. immer etwas kompliziert aus! ;-)

Grüße, Marc