RTR: Wie Betriebsart umschalten?

[Elo]

Hallo,
ich frage mich, wie eine gute Lösung zur Umschaltung der RTR Betriebsarten (Komfort, Standby, Nacht, usw.) aussieht. Ich habe RTRs von Merten und könnte hier zur Umschaltung die interne Zeitschaltuhr benutzen, würde dann aber überall in den RTRs die Zeitschaltuhren einstellen müssen. Lagert man solch eine Funktion besser aus? Z.B. in das ebenfalls vorhandene WireGate, um die Zeiten zentral pflegen zu können?

Außerdem habe ich noch ein technisches Verständnisproblem. Wenn ich am RTR Komfort einschalten will, sende ich eine "1" an den Komfort-Eingang. Will ich auf Nacht umschalten, muss ich erst eine "0" an den Komfort-Eingang und dann eine "1" an den Nacht-Eingang senden ("0" auf alle Eingänge = Standby/Abwesend). Wie realisiere ich das in der Praxis? Mit zwei separaten Schaltzeiten? Und wie würde ich dann die Binäreingänge der Fensterkontakte einbinden?

Hoffe ihr könnt mir helfen,
Erik

[EPIX]

hast du schon mal versucht, die Doku zu lesen?

Da steht die Umschalt-Prioritäten beschrieben...

Wegen der generellen Vorgangsweise:
ich bevorzuge die Umschaltung mit Adressen, genau aus dem Grund den du auch angibst: es ist "mühsam" jeden RTR mit seinen eigenen Schaltuhren einzustellen...

Der Vorteil der Umschaltung per Adresse ist eben die zentrale Auslösung, leichte Anpassung je nach Wetter / Witterung / Nutzung / Feiertag vs. Arbeitstag usw

Der Fensterkontakt kannst du mit dem entsprechenden Objekt verknüpfen - der regelt dann die Betriebsart...

[Elo]

Hallo Epix,

aus dem Handbuch habe ich es ja:
Der Nachtbetrieb wird aktiv, wenn das Komfortobjekt auf „0“ gesetzt ist und
• das Objekt „Nachtabsenkung Eingang“ auf „1“ ge-
setzt wird oder.....

Mir ist halt nicht klar, wie ich das umsetzte (vielleicht ist es auch einfacher auf Byte umzustellen). Wie kann meine Zeitschaltuhr/Fensterkontakt von Komfort auf Nacht umstellen?

Was nutzt du zur zentralen Einstellung der Zeiten?

[Tessi]

Also generell gibt es zwei Möglichkeiten (die offenbar beide von deinen RTRs unterstützt werden?).

Die aktuell spezifizierte Methode sieht ein 1-Byte-Objekt vor, das auf vier verschiedene Werte gesetzt werden kann, entsprechend den verschiedenen Modi. Hier gilt einfach der zuletzt empfangene Wert.

Aus der Zeit, wo dieses 1-Byte-Objekt noch nicht spezifiziert war, stammt die Methode mit vier einzelnen 1-Bit-Objekten, die jeweils für einen Modus stehen und aktiv "1" sind.
Da hier alle gleichzeitig auf "1" gesetzt sein könnten, besitzen die einzelnen Modi unterschiedliche Prioritäten. Das bedeutet auch, wenn man einen höher priorisierten Modus setzt, kann der vorherige ruhig weiterhin auf "1" bleiben, und tritt automatisch wieder in Kraft, wenn der höher priorisierten Modus zurückgesetzt wird.
Umgekehrt aber muss ein höher priorisierten Modus zurückgesetzt werden, wenn ein niedriger priorisierter Modus aktiv werden soll, andernfalls hat es keinen Effekt, wenn der niedriger priorisierter Modus gesetzt wird.
Wenn also kurzfristig niedriger priorisierte Modi durch höher priorisierter Modi übersteuert werden sollen, ist diese Methode günstiger als die mit 1-Byte-Objekt, da letztere sich grundsätzlich nicht an den vorherigen Modus "erinnern" kann.
Will man aber per Fensterkontakt (o.ä.) vorübergehend von irgendeinem Modus auf Frostschutz schalten und dann wieder zurück geht das mit beiden Methoden nicht so ohne weiteres. Bei vier 1-Bit-Objekten hat der Frostschutz meist die niedrigste Priorität und kann nur durch Deaktivierung aller anderen Modi aktiviert werden, was mit einem einzigen Telegramm (und mehr sendet ein Binäreingang normalerweise nicht) nicht geht. Mit einem 1-Byte-Objekt geht es zwar einfach, aber man verliert den aktuellen Modus. Man wird also immer zusätzliche externe Logik brauchen. Dann aber ist es prinzipiell egal, welche Methode man wählt, die mit einem 1-Byte-Objekt ist dann aber einfacher zu verstehen, da man keine Prioritäten beachten muss und zum Umschalten immer nur genau ein Wert gesendet werden muss.

Viele Tasterschnittstelle können auch als Wertgeber konfiguriert werden und dann beim Schließen und Öffnen verschiedene (1-Byte-)Werte senden. So könnte man zwischen Komfort und Nacht umschalten.
Auch die meisten Schaltuhren können als Wertgeber arbeiten, oft kann dann nicht nur die Zeit im Betrieb verändert werden, sondern auch der zu sendende Wert. Dann ist die Methode mit einem 1-Byte-Wert auf jeden Fall die günstigere, denn nur wenige Schaltuhren können auch Szenen speichern und dann zu einer bestimmten Zeit mehrere Telegramme versenden...

[EPIX]

(vielleicht ist es auch einfacher auf Byte umzustellen).

nachdem du ja ein WG hast, würde ich diese Version bevorzugen....

mit der Bytemethode hast du jedenfalls eindeutige Schaltbefehle für den Zustand....

die Prio werden üblicherweise wie folgt definiert
https://knx-user-forum.de/218179-post7.html

[TRex]

RTFM

entweder Du wandelst einen 1Byte-Wert um oder Du musst die ganzen werte eben einzeln in Sequenzen packen...

Frostschutz geht immer vor.

[Gast]

Objekt 48 - 1 Byte stellt Betriebsart um


Entsprechend aber in der Applikation noch von Bit auf Byte umstellen , so dass steht 1 Byte 0:Komfort

Anschließend alle "Objekt 48 " der Tastern in eine GA kopieren, programmieren und mit einem VISU Server einer Sequenz diese Umschaltungen definieren.....

[Elo]

Tessi, danke für die ausführliche Erklärung.
Die RTR interne Zeitschaltuhr kann auch als Wertgeber konfiguriert werden, so dass hier die Umschaltung per Byte-Wert erfolgen könnte. Mein Binäreingang der Fensterkontakte kann nur "Ein/Aus/Toggle", somit bin ich, wie du schreibst, schon für eine so einfache Funktion wie die Umschaltung auf Frostschutz bei geöffnetem Fenster auf zusätzliche Logik angewiesen.

EPIX, ist dir ein Plugin für das Wiregate bekannt, das diese Funktion abdecken würde?

TRex, habe ich ja gelesen, daher bin ich doch so verwirrt. :-)
Ich frage mich, wie die anderen User das so gelöst haben. Um ehrlich zu sein, habe ich mir die Einbindung der Fensterkontakte einfacher vorgestellt.

[Elo]

Objekt 48 - 1 Byte stellt Betriebsart um


Entsprechend aber in der Applikation noch von Bit auf Byte umstellen , so dass steht 1 Byte 0:Komfort

Anschließend alle "Objekt 48 " der Tastern in eine GA kopieren, programmieren und mit einem VISU Server einer Sequenz diese Umschaltungen definieren.....

Den ersten Teil verstehe ich noch, aber wie mir dass dann mit den Fensterkontakten helfen kann, ist mir nicht ganz klar. Stehe auf dem Schlauch, kannst du mir das noch mal erklären? Auch, warum ich "1 Byte 0:Komfort" einstellen soll.

[TRex]

der Frostschutz ( Fensterkontakt wird darauf gelegt ) geht vor und ist das - ich glaub aus dem stegreif - letzte Byte.

guck Dir das mal bei den BJ Manuals an, da ist das schön beschrieben.
(Seite 5)

[EPIX]

EPIX, ist dir ein Plugin für das Wiregate bekannt, das diese Funktion abdecken würde?

Hab' kein WG (net amoi an Clone )

für den eibPC hätte ich was...

[Elo]

der Frostschutz ( Fensterkontakt wird darauf gelegt ) geht vor und ist das - ich glaub aus dem stegreif - letzte Byte.

guck Dir das mal bei den BJ Manuals an, da ist das schön beschrieben.
(Seite 5)

Danke, mit dem Frostschutz scheint es ja wirklich einfach umzusetzen sein. Ich war, warum auch immer, auf Nachtabsenkung versteift, aber damit wäre es ja unnötig schwer. Muss ich in den nächsten Tagen mal ausprobieren.

[Elo]

Hab' kein WG (net amoi an Clone )

für den eibPC hätte ich was...

Jetzt verfolge ich erst einmal die Konfiguration über die RTRs. Habe mir gedacht, dass sich die Zeiten ja nicht oft ändern werden, wenn sie erst einmal richtig eingestellt sind. Außerdem kann ja auch der Timer eines RTR die anderen RTRs mit steuern (wenn gleiche Schaltzeiten gewünscht), also ist es ja auch wieder eine zentrale Stelle zur Einstellung der Zeiten.