KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor
KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum
Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki
[Beantwortet] Logiken für die Steuerung der Beleuchtung(z.B. Treppenbeleuchtung)
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 916
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 251 Mal
Logiken für die Steuerung der Beleuchtung(z.B. Treppenbeleuchtung)
Hallo zusammen,
ich will meine Beleuchtung und das Schaltverhalten in mehreren Räumen optimieren.
Dafür brauche ich 3 neue Logiken.
Bei dem zweiten und dritten Fall bin ich mir nicht sicher, ob es überhaupt möglich wäre sowas zu realisieren.
Was haltet ihr davon?
Wie kann ich am besten das Verhalten(Fall 2 und 3) mit der Logik im System abbilden?
Fall 1: Zeitgesteuert
Um eine bestimmte Zeit z.B. um 21:00 Uhr soll der Wert einer bestimmten GA X oder des Objekts X täglich auf 0 gesetzt werden.
Fall 2: Zeitgesteuert
Um eine bestimmte Zeit z.B. um 18:00 Uhr soll die Treppenbeleuchtung angehen und um 24:00 Uhr ausgehen.
In diesem Zeitraum, darf die Flur-Beleuchtung, die vom PM gesteuert wird, nicht automatisch angehen, wenn die Treppenbeleuchtung an ist.
Da muss man den PM irgendwie blockieren/sperren.
Es sollte aber möglich sein die Flur-Beleuchtung mit dem Taster ein- und auszuschalten.
Fall 3: Wenn eine Lichtquelle mehr als X Minuten/Stunden an ist, dann soll sie automatisch ausgeschaltet werden.
MfG Juri
ich will meine Beleuchtung und das Schaltverhalten in mehreren Räumen optimieren.
Dafür brauche ich 3 neue Logiken.
Bei dem zweiten und dritten Fall bin ich mir nicht sicher, ob es überhaupt möglich wäre sowas zu realisieren.
Was haltet ihr davon?
Wie kann ich am besten das Verhalten(Fall 2 und 3) mit der Logik im System abbilden?
Fall 1: Zeitgesteuert
Um eine bestimmte Zeit z.B. um 21:00 Uhr soll der Wert einer bestimmten GA X oder des Objekts X täglich auf 0 gesetzt werden.
Fall 2: Zeitgesteuert
Um eine bestimmte Zeit z.B. um 18:00 Uhr soll die Treppenbeleuchtung angehen und um 24:00 Uhr ausgehen.
In diesem Zeitraum, darf die Flur-Beleuchtung, die vom PM gesteuert wird, nicht automatisch angehen, wenn die Treppenbeleuchtung an ist.
Da muss man den PM irgendwie blockieren/sperren.
Es sollte aber möglich sein die Flur-Beleuchtung mit dem Taster ein- und auszuschalten.
Fall 3: Wenn eine Lichtquelle mehr als X Minuten/Stunden an ist, dann soll sie automatisch ausgeschaltet werden.
MfG Juri
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt
-
- Reactions:
- Beiträge: 385
- Registriert: So Okt 14, 2018 1:48 pm
- Hat sich bedankt: 242 Mal
- Danksagung erhalten: 298 Mal
Hallo Juri,
ist es zwingend für dich notwendig das mit Logik im TWS zu realisieren?
(Fall 2-3)
Bestimmte Funktionen bringt doch schon ein KNX-Schaltaktor mit sich, warum diese dann neu in Software erfunden werden sollen ...
... angenommen das der KNX-Schaltktor diese "zusätzlichen" Möglichkeiten bietet.
Ein Zusammenspiel KNX <-> TWS würde doch genauso gut funktionieren.
Somit wären Basisfunktionen auf den KNX und Komfortfunktionen auf dem TWS realisiert.
Der Logikeditor ist eine verdammt mächtige Waffe, dessen Möglichkeiten sich für mich sehr schwer einschätzen lassen.
Da müssen die Logikeditor-Profis mal ran.
Grüße
René
ist es zwingend für dich notwendig das mit Logik im TWS zu realisieren?
(Fall 2-3)
Bestimmte Funktionen bringt doch schon ein KNX-Schaltaktor mit sich, warum diese dann neu in Software erfunden werden sollen ...
... angenommen das der KNX-Schaltktor diese "zusätzlichen" Möglichkeiten bietet.
Ein Zusammenspiel KNX <-> TWS würde doch genauso gut funktionieren.
Somit wären Basisfunktionen auf den KNX und Komfortfunktionen auf dem TWS realisiert.
Der Logikeditor ist eine verdammt mächtige Waffe, dessen Möglichkeiten sich für mich sehr schwer einschätzen lassen.
Da müssen die Logikeditor-Profis mal ran.
Grüße
René
Zuletzt geändert von maggyver am Fr Nov 26, 2021 7:57 pm, insgesamt 3-mal geändert.
Grüße
René
_______________________________________________________________________________
TWS 2600LW ID:504
TWS 3500 ID:1306
VPN offen , Reboot erlaubt , Offline , Insider
René
_______________________________________________________________________________
TWS 2600LW ID:504
TWS 3500 ID:1306
VPN offen , Reboot erlaubt , Offline , Insider
-
- Reactions:
- Beiträge: 4088
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1415 Mal
- Danksagung erhalten: 1901 Mal
Fall1 sollte eine einfache Trigger-Logik im TWS sein.
Fall2 Das ist dann eine Logik als ZSU die den Zeitraum 18:00 - 23:59 als 1 alles andere als 0 definiert. Ergebnis ein Objekt im TWS
Das Objekt schickst einmal per GA an den Schaltaktor für das Treppenlicht
Und ein zweites mal an das Sperrobjekt vom PM oder je nach PM eine Umschaltung Tag/Nacht, letzteres hat den Vorteil das dann die manuelle Bedienung per Taster noch funktioniert.
Bevor das alles in eine zentrale Logik muss, würde ich da eher die Möglichkeiten des PM ausloten. Da gibt es viele Wege. Sperre + Zwangsführung aus dem Taster oder Tag/Nacht-Modus im PM (Was bei Gira z.B. indirekt auch über Sperre geht da werden zwei Kanäle gegeneinander gesperrt die sich dann eben unterschiedlich verhalten)
Fall3 Funktion des Treppenlichtautomaten im Aktor nutzen. Wenn es mit Logik sein soll, dann Status des Aktorkanals bei "AN" als Trigger auf einen Timer und dessen Ergebnis Sende 0 auf den bus und auf den Schalteingang des Aktors geben.
Egal ob Treppenlicht oder Logik, den Status auch immer ordentlich an Taster und PM übergeben, damit die nicht durcheinanderkommen.
Fall2 Das ist dann eine Logik als ZSU die den Zeitraum 18:00 - 23:59 als 1 alles andere als 0 definiert. Ergebnis ein Objekt im TWS
Das Objekt schickst einmal per GA an den Schaltaktor für das Treppenlicht
Und ein zweites mal an das Sperrobjekt vom PM oder je nach PM eine Umschaltung Tag/Nacht, letzteres hat den Vorteil das dann die manuelle Bedienung per Taster noch funktioniert.
Bevor das alles in eine zentrale Logik muss, würde ich da eher die Möglichkeiten des PM ausloten. Da gibt es viele Wege. Sperre + Zwangsführung aus dem Taster oder Tag/Nacht-Modus im PM (Was bei Gira z.B. indirekt auch über Sperre geht da werden zwei Kanäle gegeneinander gesperrt die sich dann eben unterschiedlich verhalten)
Fall3 Funktion des Treppenlichtautomaten im Aktor nutzen. Wenn es mit Logik sein soll, dann Status des Aktorkanals bei "AN" als Trigger auf einen Timer und dessen Ergebnis Sende 0 auf den bus und auf den Schalteingang des Aktors geben.
Egal ob Treppenlicht oder Logik, den Status auch immer ordentlich an Taster und PM übergeben, damit die nicht durcheinanderkommen.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
-
- Reactions:
- Beiträge: 1908
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 643 Mal
- Danksagung erhalten: 797 Mal
Fall 1
siehe KB
app.php/kb/viewarticle?a=95
Fall 2
Ginge auf jeden Fall im TWS Logikfunktionsmodul, aber sehe es auch so: Checke die Möglichkeiten des PM und wenn es Dir nicht klar ist posten sie hier (z.B Screenshot aus ETS Parametrierung)
Für die von Göran angesprochene ZSU nutzt Du hier vermutlich am Besten den Timer 1...
Aber am Ende ist das nur eine Einstiegsvariante...was Du eigentlich willst ist ja bestimmt, dass das Licht nicht um 18uhr, sondern bei Dämmerung angeht. oder?
Ich habe zwar eine Wetterstation, aber weil die Teile im Außenbeleuchtung nicht ewig halten, habe ich alle Dämmerungslogiken bei mir inzwischen auf den Stand der Sonne umgesetzt- Die Sonnenhöhe im genau zu sein. Dafür gibt es das Astro-Modul.
Der Sonnestand gibt mir das Einschalt Signal und eine AND Logik-Zelle wie in Fall 1 nur inertiert gibt mir z.B. um 23 Uhr das False.
Fall 3
Überlege Dir ,was genau Du willst und wie Deine Situation ist..wahrscheinlich reicht sogar eine AND-Logik wie in Fall 1, aber mit False als Eingang, Ausschaltverzögerung am Ausgang und triggern bei Objektereignis anstelle eines Zeitpunktes.
siehe KB
app.php/kb/viewarticle?a=95
Fall 2
Ginge auf jeden Fall im TWS Logikfunktionsmodul, aber sehe es auch so: Checke die Möglichkeiten des PM und wenn es Dir nicht klar ist posten sie hier (z.B Screenshot aus ETS Parametrierung)
Für die von Göran angesprochene ZSU nutzt Du hier vermutlich am Besten den Timer 1...
Aber am Ende ist das nur eine Einstiegsvariante...was Du eigentlich willst ist ja bestimmt, dass das Licht nicht um 18uhr, sondern bei Dämmerung angeht. oder?
Ich habe zwar eine Wetterstation, aber weil die Teile im Außenbeleuchtung nicht ewig halten, habe ich alle Dämmerungslogiken bei mir inzwischen auf den Stand der Sonne umgesetzt- Die Sonnenhöhe im genau zu sein. Dafür gibt es das Astro-Modul.
Der Sonnestand gibt mir das Einschalt Signal und eine AND Logik-Zelle wie in Fall 1 nur inertiert gibt mir z.B. um 23 Uhr das False.
Fall 3
Überlege Dir ,was genau Du willst und wie Deine Situation ist..wahrscheinlich reicht sogar eine AND-Logik wie in Fall 1, aber mit False als Eingang, Ausschaltverzögerung am Ausgang und triggern bei Objektereignis anstelle eines Zeitpunktes.
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 1908
- Registriert: Di Okt 09, 2018 9:26 am
- Hat sich bedankt: 643 Mal
- Danksagung erhalten: 797 Mal
Sorry, das war falsch...
Timer1 oder Timer2 wie von Göran vorgeschlagen.
Ausgang auf Verhalten T setzen
Starteingang z.B. mit Aktorstatus verknüpfen
VG, Sven - 3500 XL ID:1369 | 3500 L ID:1355, VPN offen, Reboot OK
-
- Reactions:
- Beiträge: 916
- Registriert: So Aug 12, 2018 9:12 am
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 251 Mal
ja, das will ich aber im nächsten Schritt machen

MfG Juri
Zuletzt geändert von Sensej am Sa Nov 27, 2021 7:15 pm, insgesamt 2-mal geändert.
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt