Hallo zusammen,
ich habe ein Frage und zwar würde ich gerne in einem Bereich die Beleuchtung in zwei Zeitfenstern mit unterschichem Dimmwert schalten.
Konkret geht es darum Nachts Leuchten mit geringerem Dimmwert zu schalten als Tagsüber. Wie könnte man das am besten umsetzen?
Die Steuerung meiner Beleuchtung ist über Dali verwirklicht und als Sensor dient ein Bewegungsmelder.
Könnt Ihr mir bitte einen Tipp geben wie ich hier vorgehen könnte?
Gruß
Rookie
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
[Frage] [V4.1] Zeitfenster Dimmwert
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
Alles klar. Danke für den Hinweis.
Timberwolf ID: 1357 (3500)
Version 4.1 - Smashing Pumpkin - ULTRA
Version 4.1 - Smashing Pumpkin - ULTRA
-
- Reactions:
- Beiträge: 4088
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1415 Mal
- Danksagung erhalten: 1901 Mal
Wir meinen eher die Angabe des Softwarestandes des TWS.
Denn es gibt in der Backlog-Liste des TWS noch ein Beleuchtungsfeatures.
Da sind solche Szenarien über ein paar Parameter möglich zu realisieren. Um das aber mit IST-Mitteln des TWS genauer zu beschreiben für Dich, benötigt es den Stand Deiner Software auf dem TWS.
Wenn Du das im wesentlichen ohne TWS erledigen möchtest, rein aus KNX-HW und ETS, dann müsstest aber schon mal genauer sagen was dein KNX/DALI GW ist und welche PM/BWM du verwendets.
Denn eine Tag/Nacht Umschaltung ist bei einigen Herstellern Standardfunktionalität, da hilft dann einfach ins Handbuch des BWM/PM schauen.
Ansonsten Grobe-Kelle die immer geht, zwei Kanäle definieren, einen für Tag einen für Nacht und die gegeneinander sperren. Aber auch da gehen die Hersteller unterschiedlich vor das zu realisieren. Und solltest nur Melder mit einem Kanal haben, dann hast da was falsch geplant vor dem Kauf der Sensoren.
Wenn eigene Logiken Dir zu komplex sind, dann ggf eine ETS Applikation verwenden die solche Tagesphasen aktiv unterstützt. Ich nutze mittlerweile Open-KNX VPM da habe ich nicht nur Tag/Nacht sondern die Tagesphasen Morgens/Tag/Abends/Nacht. Denn in jeder soll hier für mich das Grundlicht abweichend reagieren.
Denn es gibt in der Backlog-Liste des TWS noch ein Beleuchtungsfeatures.
Da sind solche Szenarien über ein paar Parameter möglich zu realisieren. Um das aber mit IST-Mitteln des TWS genauer zu beschreiben für Dich, benötigt es den Stand Deiner Software auf dem TWS.
Wenn Du das im wesentlichen ohne TWS erledigen möchtest, rein aus KNX-HW und ETS, dann müsstest aber schon mal genauer sagen was dein KNX/DALI GW ist und welche PM/BWM du verwendets.
Denn eine Tag/Nacht Umschaltung ist bei einigen Herstellern Standardfunktionalität, da hilft dann einfach ins Handbuch des BWM/PM schauen.
Ansonsten Grobe-Kelle die immer geht, zwei Kanäle definieren, einen für Tag einen für Nacht und die gegeneinander sperren. Aber auch da gehen die Hersteller unterschiedlich vor das zu realisieren. Und solltest nur Melder mit einem Kanal haben, dann hast da was falsch geplant vor dem Kauf der Sensoren.
Wenn eigene Logiken Dir zu komplex sind, dann ggf eine ETS Applikation verwenden die solche Tagesphasen aktiv unterstützt. Ich nutze mittlerweile Open-KNX VPM da habe ich nicht nur Tag/Nacht sondern die Tagesphasen Morgens/Tag/Abends/Nacht. Denn in jeder soll hier für mich das Grundlicht abweichend reagieren.
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
Habe die Softwareversion mal in meiner Signatur ergänzt.gbglace hat geschrieben: ↑Sa Mär 01, 2025 1:47 pm Wir meinen eher die Angabe des Softwarestandes des TWS.
Denn es gibt in der Backlog-Liste des TWS noch ein Beleuchtungsfeatures.
Da sind solche Szenarien über ein paar Parameter möglich zu realisieren. Um das aber mit IST-Mitteln des TWS genauer zu beschreiben für Dich, benötigt es den Stand Deiner Software auf dem TWS.
Eine Tag-Nachtumschaltung bietet mein BWM leider nicht an, deswegen war die Idee das über den TWS zu erledigen. Als wir damals geplant hatten, hatte ich nicht bedacht, dass einem das helle Licht beim nächtlichen Toilettengang blendet...gbglace hat geschrieben: ↑Sa Mär 01, 2025 1:47 pm Wenn Du das im wesentlichen ohne TWS erledigen möchtest, rein aus KNX-HW und ETS, dann müsstest aber schon mal genauer sagen was dein KNX/DALI GW ist und welche PM/BWM du verwendets.
Denn eine Tag/Nacht Umschaltung ist bei einigen Herstellern Standardfunktionalität, da hilft dann einfach ins Handbuch des BWM/PM schauen.
Ansonsten Grobe-Kelle die immer geht, zwei Kanäle definieren, einen für Tag einen für Nacht und die gegeneinander sperren. Aber auch da gehen die Hersteller unterschiedlich vor das zu realisieren. Und solltest nur Melder mit einem Kanal haben, dann hast da was falsch geplant vor dem Kauf der Sensoren.
Ich habe mit den Logiken schon etwas herumgespielt bin aber noch nicht auf eine funktionierende Lösung gekommen.
Das hört sich natürlich nach der perfekten Lösung an. Leider bin ich das vom "Know how" noch etwas weit entfernt... Böhmsche Dörfer und sogbglace hat geschrieben: ↑Sa Mär 01, 2025 1:47 pm Wenn eigene Logiken Dir zu komplex sind, dann ggf eine ETS Applikation verwenden die solche Tagesphasen aktiv unterstützt. Ich nutze mittlerweile Open-KNX VPM da habe ich nicht nur Tag/Nacht sondern die Tagesphasen Morgens/Tag/Abends/Nacht. Denn in jeder soll hier für mich das Grundlicht abweichend reagieren.

Timberwolf ID: 1357 (3500)
Version 4.1 - Smashing Pumpkin - ULTRA
Version 4.1 - Smashing Pumpkin - ULTRA
-
- Reactions:
- Beiträge: 695
- Registriert: Sa Aug 11, 2018 11:16 pm
- Hat sich bedankt: 449 Mal
- Danksagung erhalten: 309 Mal
Genau da soll sie nicht hin. Bitte in den Threadtitel.Habe die Softwareversion mal in meiner Signatur ergänzt.

Grüße, Dominic
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Timberwolf 2400 #126, VPN offen, Reboot nach Absprache
Ich habe das Problem lösen können. Unerwarteterweise habe ich es über die ETS geschafft. Ich habe entdeckt, dass meine Taster eine Tag/Nacht-funktion haben die 1/0 zurückgeben. Dieses Siganl nutze ich nun für 2 Profile im BWM die sich gegeneinader sperren und so dann zwei Helligkeitswerte schalten können.
@gbglace Nochmal danke für den Tipp mit dem gegenseitigen Sperren. Manchmal sieht man die einfachste Lösung nicht.

Zuletzt geändert von Rookie am So Mär 02, 2025 8:24 am, insgesamt 1-mal geändert.
Timberwolf ID: 1357 (3500)
Version 4.1 - Smashing Pumpkin - ULTRA
Version 4.1 - Smashing Pumpkin - ULTRA
-
- Elaborated Networks
- Reactions:
- Beiträge: 10702
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 5303 Mal
- Danksagung erhalten: 8685 Mal
- Kontaktdaten:
Hallo,
ich möchte vorschlagen, dass die Angabe der Firmware Version einheitlich gestaltet wird von allen.
Das hier bislang verwendete Format ist [V4.1] für eine Hauptversion bzw. [V4.5 IP3] für eine Insider Version und dies zu Beginn eines Thread-Titels.
Warum und weswegen? Wenn jemand die Forensuche bemüht, dann erhält man eine lange Liste von Einträgen. Da wir sehr viel von Firmware zu Firmware verbessern bzw. erweitern ist es für jemanden, der in der Zukunft etwas sucht, durchaus relevant, welche Firmware Version der Thread betrifft. Man stelle sich vor, im Jahr 2028 sucht jemand nach etwas bestimmten. Dann möchte er vermutlich eher den Inhalt aus Threads zur dann aktuellen V 11.5 lesen anstatt alte Einträge zur V 4.1. Damit man mit den Augen leichter durch diese Liste von Dutzenden bis hunderten Suchergebnissen "scannen" kann, ist es sinnhaft, wenn die Firmware immer an der gleichen Stelle steht und gleich formatiert ist.
Wenn jeder das nun so schreibt, wie er gerade will, ok, ist ein freies Land, aber ihr zerstört Euch damit den Nutzen für die Suche.
In den vergangenen Jahren haben Mods und ich etwa 70% der Threads umbenannt und den Titel angepasst / formatiert. Damit Ihr aussagekräftige Suchergebnisse habt. Einer der Mods, der da immer sehr bemüht war, kann derzeit aus persönlichen Gründen nicht mehr helfen und ich habe eigentlich auch wichtigere Aufgaben. Ich werde mich darum nicht mehr kümmern können.
Ich möchte daher anregen, dass die Community selbst darauf achtet. Könnt es auch lassen, dann habt ihr halt schlechtere Suchergebnisse. Ist Eure Entscheidung.
Falls jemand sich dazu berufen fühlt, die Threadtitel künftig laufend so anzupassen, dass eine Suche auch Sinn ergibt, dann kann er sich gerne bei mir (hier ist PN ausnahmsweise ok) diesbezüglich melden. Wir brauchen frischen Nachwuchs bei den Mods.
Merci und schönen Sonntag noch.
Stefan
ich möchte vorschlagen, dass die Angabe der Firmware Version einheitlich gestaltet wird von allen.
Das hier bislang verwendete Format ist [V4.1] für eine Hauptversion bzw. [V4.5 IP3] für eine Insider Version und dies zu Beginn eines Thread-Titels.
Warum und weswegen? Wenn jemand die Forensuche bemüht, dann erhält man eine lange Liste von Einträgen. Da wir sehr viel von Firmware zu Firmware verbessern bzw. erweitern ist es für jemanden, der in der Zukunft etwas sucht, durchaus relevant, welche Firmware Version der Thread betrifft. Man stelle sich vor, im Jahr 2028 sucht jemand nach etwas bestimmten. Dann möchte er vermutlich eher den Inhalt aus Threads zur dann aktuellen V 11.5 lesen anstatt alte Einträge zur V 4.1. Damit man mit den Augen leichter durch diese Liste von Dutzenden bis hunderten Suchergebnissen "scannen" kann, ist es sinnhaft, wenn die Firmware immer an der gleichen Stelle steht und gleich formatiert ist.
Wenn jeder das nun so schreibt, wie er gerade will, ok, ist ein freies Land, aber ihr zerstört Euch damit den Nutzen für die Suche.
In den vergangenen Jahren haben Mods und ich etwa 70% der Threads umbenannt und den Titel angepasst / formatiert. Damit Ihr aussagekräftige Suchergebnisse habt. Einer der Mods, der da immer sehr bemüht war, kann derzeit aus persönlichen Gründen nicht mehr helfen und ich habe eigentlich auch wichtigere Aufgaben. Ich werde mich darum nicht mehr kümmern können.
Ich möchte daher anregen, dass die Community selbst darauf achtet. Könnt es auch lassen, dann habt ihr halt schlechtere Suchergebnisse. Ist Eure Entscheidung.
Falls jemand sich dazu berufen fühlt, die Threadtitel künftig laufend so anzupassen, dass eine Suche auch Sinn ergibt, dann kann er sich gerne bei mir (hier ist PN ausnahmsweise ok) diesbezüglich melden. Wir brauchen frischen Nachwuchs bei den Mods.
Merci und schönen Sonntag noch.
Stefan
Zuletzt geändert von StefanW am So Mär 02, 2025 12:40 pm, insgesamt 4-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.