[OpenKNX-Ready] LED-Dimmer, Constant Voltage, 6-fach für UP, 12-fach für REG (6 TE)

[kikakeule]

kikakeule Ich muss zugeben, dass mir noch nicht ganz klar ist, wie die Zusammenhänge gemeint sind. Wofür sind die einzelnen KO jeweils gedacht? Was meinst du mit festlegen des Farbverlaufs aus einem Logikmodul heraus? Würden die Stützpunkte nicht in der Konfiguration selbst gesetzt? Wenn ja, woher kommen sie / wie werden sie übertragen?
Insgesamt klingt das gut, aber wie gesagt bin ich mir noch nicht ganz sicher, wie das alles funktionieren soll in dem Plan

Ja, ich muss das sicherlich noch weiter ausarbeiten. Die Idee war den HCL nicht im Dimmer zu verorten sondern nur per KOs die Möglichkeit zu geben die dafür notwendigen Funktionen zu steuern.
Naiv könnte man ja alle x Minuten Helligkeit und Farbtemperatur setzen, dazu braucht es dann aber viele Stützpunkte was dann komplexe Logik oder sowas wie nen X1, HA oder ähnliches voraussetzen würde. Daher die Idee ein KO zu erstellen um die Dimmzeit zu setzen um eine solche Änderung über eine definierte Zeit automatisch laufen zu lassen. So ähnlich setzt es ja intern auch MDT um indem sie zwischen den Stützpunkten interpolieren und man als Nutzer nur einige Wenige Punkte definieren muss.
Der Twist wäre jetzt, dass sich mit solchen KOs ein HCL recht einfach aus dem Zeitgeber im Logikmodul erstellen ließe.

Aber vermutlich ist das tatsächlich zu kompliziert und es macht mehr Sinn das klassisch (inkl. deiner Anregungen) zu implementieren und sowas wie eine Sonnenaufgangs-Simulation separat umzusetzen.

Edit: ich überlege ob man die HCL Temperatur tagsüber vielleicht anhand der Farbtemperatur der Umgebung regeln möchte. Es gibt von TI den OPT4048 und von Adafruit und Sparkfun günstige Eval-Boards (z.B. https://www.sparkfun.com/sparkfun-tr...tsr-qwiic.html)
Besteht an sowas Interesse?

[Alloc]

Ah, du meinst wenn man z.B. die Stützpunkte hat:
6 Uhr: 0% KW
8 Uhr: 45% KW
10 Uhr: 85% KW
11 Uhr: 100% KW

Dann würde man mit der Logik um 6 Uhr " 'Dimme' auf 45% KW über 2 Stunden " senden, analog um 8 nochmal auf 85% und um 11 Uhr auf 100% über 1 Stunde?
Ist sicher auch ein interessanter Ansatz und macht natürlich das synchronisieren über die ganze Wohnung einfach (man richtet es einmal ein und hängt alle Aktoren dran statt das in jedem Aktor einzustellen). Aber ich denke das wird spätestens problematisch, wenn man dann mal bei einzelnen Aktoren manuell übersteuert, somit die HCL abgeschaltet wird. Dann müsste man ja danach beim Wiedereinschalten den aktuell korrekten Wert senden und die Restlaufzeit bis zum nächsten Stützpunkt?

[kikakeule]

Ah, du meinst wenn man z.B. die Stützpunkte hat:
6 Uhr: 0% KW
8 Uhr: 45% KW
10 Uhr: 85% KW
11 Uhr: 100% KW

Dann würde man mit der Logik um 6 Uhr " 'Dimme' auf 45% KW über 2 Stunden " senden, analog um 8 nochmal auf 85% und um 11 Uhr auf 100% über 1 Stunde?
Ist sicher auch ein interessanter Ansatz und macht natürlich das synchronisieren über die ganze Wohnung einfach (man richtet es einmal ein und hängt alle Aktoren dran statt das in jedem Aktor einzustellen). Aber ich denke das wird spätestens problematisch, wenn man dann mal bei einzelnen Aktoren manuell übersteuert, somit die HCL abgeschaltet wird. Dann müsste man ja danach beim Wiedereinschalten den aktuell korrekten Wert senden und die Restlaufzeit bis zum nächsten Stützpunkt?

Ja genau, gerade den zentralen Aspekt fand ich interessant.

Man müsste halt auf einer Per-Kanal-Basis festlegen wie sich der Kanal bei manueller Überschreibung verhält. Durch die unterschiedlichen KOs kann der Aktor ja unterscheiden ob ein Schalter oder die zentrale Logik gerade einen Wert gesetzt hat.
Im einfachsten Fall sperrt ein manuelles Überschreiben bis zum nächsten Schaltvorgang einfach alle HCL KOs für einen manuell überschriebenen Kanal. Oder man fügt eine Zeitkomponente hinzu, nach der der Kanal dann langsam wieder auf die HCL-Werte zurück dimmt.

Für das Wiedereinschalten könnte man entweder direkt zum nächsten Punkt schalten (also wenn ich um 10:30 anschalte geht es direkt auf 100% KW) oder der Aktor simuliert die Dimmung im Hintergrund und nutzt den Wert.
Letzteres funktioniert natürlich bei Spannungsverlust nicht - aber das ist ja eigentlich kein üblicher Anwendungsfall.

Alternativ könnte man sich überlegen in die Logik eine extra HCL Option einzubauen die sich stark an der Zeitschaltuhr orientiert. Dann braucht es auch nur einen Logik-Kanal und man könnte alle Werte dort transparent setzen. Außerdem könnte der Aktor da auch die aktuellen Werte Abfragen für das Einschalten.

[LostWolf]

Da hat man ne Woche Urlaub (ist also den ganzen Tag auf der Hausbaustelle) und es passiert so viel hier 😅

Edit: ich überlege ob man die HCL Temperatur tagsüber vielleicht anhand der Farbtemperatur der Umgebung regeln möchte. Es gibt von TI den OPT4048 und von Adafruit und Sparkfun günstige Eval-Boards (z.B. https://www.sparkfun.com/sparkfun-tr...tsr-qwiic.html)
Besteht an sowas Interesse?

Du meinst das man solch einen Sensor irgendwo außen (neben der Wetterstation z.B.) installiert und die Beleuchtung sich dann automatisch (versucht) an den gemessenen Wert anzupassen?
-> klingt interessant, die Frage ist wie das in der Praxis funktional ist.

Für das Wiedereinschalten könnte man entweder direkt zum nächsten Punkt schalten (also wenn ich um 10:30 anschalte geht es direkt auf 100% KW) oder der Aktor simuliert die Dimmung im Hintergrund und nutzt den Wert.
Letzteres funktioniert natürlich bei Spannungsverlust nicht - aber das ist ja eigentlich kein üblicher Anwendungsfall.

Alternativ könnte man sich überlegen in die Logik eine extra HCL Option einzubauen die sich stark an der Zeitschaltuhr orientiert. Dann braucht es auch nur einen Logik-Kanal und man könnte alle Werte dort transparent setzen. Außerdem könnte der Aktor da auch die aktuellen Werte Abfragen für das Einschalten.

Eine Variante wäre sinnvoll die berücksichtigt das es in einem Raum auch mehrere Kanäle gibt, die auch einmal getrennt voneinander manuell übersteuert werden können. Dann aber auch wieder die gleiche Farbtemperatur bei der Rückkehr zum HCL Licht aufweisen sollten.

Der Zentrale Ansatz klingt interessant, sollte aber auch berücksichtigen das man in manchen Räumen davon abweichen möchte oder z.B. durch Szenen das im Haus gesamt verändern möchte (z.B. "schlafen" setzt immer auf den wärmsten Farbton.)

Bin gerade etwas übermüdet, schaue mir das also morgen nochmal an :P
Aber bis jetzt echt vielen Dank für deine Arbeit

[kikakeule]

Du meinst das man solch einen Sensor irgendwo außen (neben der Wetterstation z.B.) installiert und die Beleuchtung sich dann automatisch (versucht) an den gemessenen Wert anzupassen?
-> klingt interessant, die Frage ist wie das in der Praxis funktional ist.

Ich hatte sogar überlegt, dass er für die Lichtfarbe von Innen durch die Fensterscheibe nach draußen messen kann.

Das Konzept in meinem Kopf sieht etwa so aus: Sobald die Rolläden oben sind und die Lichtfarbe draußen Kühler als Drinne ist, hebe die Lichtfarbe innen an. Das vermeidet den in meine Augen unangenehmen Gelbstich in Räumen die auch tagsüber teilweise künstlich ausgeleuchtet werden müssen. Ähnlich im Sommerhalbjahr abends - solange die Fenster das blaue Licht von außen einlassen kann ich innen soviel gelbes Licht machen wie ich möchte, es wird nicht wirken (Achtung: nur ein educated Guess). Also kann ich auch gleich dafür sorgen, dass die Beleuchtung farblich passt. Und sobald die Rolläden unten sind dimmt man in das gelbe Licht, simuliert also für den Körper den Sonnenuntergang

Aber vermutlich ist das eher was für eine Version 2 (oder 3). Für den Moment ist es mir nur wichtig das Konzept bei der Planung zu berücksichtigen.

Eine Variante wäre sinnvoll die berücksichtigt das es in einem Raum auch mehrere Kanäle gibt, die auch einmal getrennt voneinander manuell übersteuert werden können. Dann aber auch wieder die gleiche Farbtemperatur bei der Rückkehr zum HCL Licht aufweisen sollten.

Das ist aber ein hochkomplexes Problem, insbesondere die Nutzerintension ist ja ziemlich unklar wenn in einem Raum mehrere Lichtfarben geschaltet sind.
Ich komme darauf gleich nochmal zurück...

Der Zentrale Ansatz klingt interessant, sollte aber auch berücksichtigen das man in manchen Räumen davon abweichen möchte oder z.B. durch Szenen das im Haus gesamt verändern möchte (z.B. "schlafen" setzt immer auf den wärmsten Farbton.)

Ok dazu muss ich kurz etwas ausholen.
Ich habe mir gestern einmal den Code vom Logikmodul angeschaut und für mich entschieden, dass ich den in nächster Zeit nicht anfasse. Das was ich damit vorhätte würde zu viele Änderungen verlangen und das Modul defokussieren.

Stattdessen sieht mein aktueller Plan vor, dass ich angefangen habe im Dimmer Modul einen klassischen HCL Zeitplan hinzuzufügen. Perspektivisch sollen davon mehrere pro Dimmer möglich sein. Dabei möchte ich die Zeitpläne am Ende so aufbauen, dass sie eine auswählbare Anzahl an Ausgängen haben (jeweils mind. ein KO für Farbe, Helligkeit).

Zusätzlich würde ich jedem TW Kanal die Möglichkeit verpassen HCL-Slave zu sein. Als HCL-Slave werden einige Kanal-spezifische Optionen aktiviert und 3 Eingänge: Helligkeit, Farbe und (mindestens) ein Sperrobjekt (TBD ob evtl. noch zusätzliche Sperrobjekte nur für Farbe/Helligkeit).
Diese Eingänge dimmen mit einer separat festgelegten Zeit (z.B. 5 Minuten) die mit der Zeit im Zeitplan übereinstimmt, mit der der Zeitplan die interpolierten Punkte der Farb- und Helligkeitskurve auf den Bus schickt.

So kann z.B. mit einem Zeitplan, das ganze Haus versorgt werden aber jeder Raum kann eigene Gruppenadressen und Sperrobjekte nutzen. Wenn man noch ein sehr einfaches Logikmodul dazwischen schaltet, kann man auch mehrere Zeitpläne laufen lassen und umschalten welcher gerade benutzt wird. Man hätte also die Möglichkeit im Urlaub oder Samstags und an Sonn-/Feiertage anders zu schalten als an Werktagen.

Bezogen auf deine Szenarien könnte der Ablauf dann wie folgt aussehen:
Mehrere manuell übersteuerte Kanäle in einem Raum: der übersteuerte TW Kanal ist konfiguriert wann (Zeit oder Ereignisbasiert (z.B. Sperrobjekt AUS empfangen)) er wieder auf HCL umschaltet, der letzte Wert vom Zeitplan wird gebuffert und jeder Kanal kann dann auf die passende Farbe schalten. Je nachdem wie granular das sein soll wird im Zweifel der Zeitplan so konfiguriert, dass er für jeden Bereich eines Raumes (oder sogar jeden Kanal) eigene Ausgang KOs hat.
Abweichende Räume: entweder durch eine Gruppe mit Sperobjekt pro Raum schon geklärt oder mehrere Zeitpläne
Szenen: Entweder Szenen Priorität über HCL geben oder per Szene das Sperrobjekt für die betreffenden Räume setzen.

P.S.: Danke für das Feedback

[Alloc]

Meines Erachtens ergibt das ganze nur Sinn, wenn einerseits die Stützpunkte sehr grob sein können (wie in meinem Beispiel oben in Post #92) damit der Bustraffic nicht zu extrem wird (sonst kann man es ja gleich komplett per externer Logik lösen ) und andrerseits der Wechsel zurück von Manuell auf HCL direkt zu dem gleichen Ergebnis führt, wie wenn die komplette Zeit bis dahin per HCL geregelt wurde. Daher müsste aus meiner Sicht jeder Aktor-Kanal selber vom letzten Stützpunkt zum nächsten laufen, unabhängig davon, ob die HCL nun gerade aktiv ist. So kann man dann jederzeit wieder beim aktuellen interpolierten Wert auf die HCL wechseln.

Und wenn man sich die Abhängigkeit zwischen zwei KOs sparen will (nächster Stützpunkt + wie lange in der Zukunft liegt dieser, also sowas wie "auf 85% über 2 Stunden") könnte man eventuell das ganze auf ein KO "nächste Farbtemperatur" begrenzen, und das gilt dann immer für z.B. 1 Stunde (oder ein im Aktor einstellbares Intervall). Zwei KOs für eine Aufgabe zu befüttern klingt für mich halt in KNX irgendwie falsch

Ansonsten generell immer wenn ich von KO für Farbtemperatur rede meine ich eigentlich zwei (oder einstellbar welche Variante): Kelvin und/oder Prozent KW Anteil. Beides hat Vor- und Nachteile, und ich denke es wäre schön beides zu unterstützen. Bei den regulären Aktor-KOs (also nicht HCL-Stützpunkt bezogen, sondern einfach aktuelle Farbtemperatur setzen / Statusausgabe) sollte es IMO *immer* beides parallel geben, denn da gehen ja potenziell verschiedenste Quellen drauf, also z.B. Taster die anders arbeiten als eine Logikengine / Visu.

[abtools]

Hallo zusammen,

finde die Diskussionen hier wirklich super und freue mich schon auf die HCL-Implementierung!

Ein kleiner Hinweis vielleicht, weil ich bzgl. Logik die Sorge über zu viel Bus-Traffic gelesen habe (so hab' ich's zumindest verstanden):
Wir liefern ja direkt mit der LED-Dimmer-Firmware 99 Logikkanäle mit aus und solange diese Logikkanäle verwendet werden, können alle KOs zwischen dem LED-Dimmer selbst und dem integrierten Logik-Modul auch intern verknüpft werden - in diesem Fall entsteht durch diese interne Kommunikation kein zusätzlicher Bus-Traffic.

Aber nichts desto trotz fände ich es persönlich auch besser, wenn die grundlegenden Funktionalität wie ein HCL-Zeitplan, wie von kikakeule geschrieben, direkt im LED-Modul integriert ist - das macht die Bedienung einfach deutlich leichter bzw. verständlicher für den Anwender.

Viele Grüße
Andreas

[scw2wi]

Um die Buslast gering zu halten und trotzdem ein ganzes Haus synchron halten zu können, könnte man den HCL-Plan auch in jedem Gerät als identische Kopie hinterlegen. Ist vielleicht nicht schön im Sinne von Dubletten-Vermeidung, aber hilfreich, wenn man die Buslast reduzieren möchte.

[henfri]

Wäre es nicht sinnvoll, solche Funktionen in einen Modul auszulagern? Welches dann aber nahtlos in die Firmware integriert werden kann?
Alles andere würde doch dazu führen, dass die HCl Implementierung bei unterschiedlicher Hardware unterschiedlich wäre

[abtools]

Hallo Hendrik,

Wäre es nicht sinnvoll, solche Funktionen in einen Modul auszulagern? Welches dann aber nahtlos in die Firmware integriert werden kann?
Alles andere würde doch dazu führen, dass die HCl Implementierung bei unterschiedlicher Hardware unterschiedlich wäre

Verstehe nicht, was du meinst:
In was für einem anderen Modul als dem "OFM-LedDimmer" könnte die HCL-Implementierung denn besser aufgehoben sein?
Und warum wäre die dann bei unterschiedlicher Hardware anders? Jede (Dimmer-)Hardware verwendet doch genau dieses Modul.

Viele Grüße
Andreas

[henfri]

Ich denke z.B an das Dali Gateway

[abtools]

Hallo Hendrik,

Ich denke z.B an das Dali Gateway

Tatsächlich kann ich zum Dali Gateway wenig sagen, ob da auch eine ähnliche HCL-Steuerung Sinn machen könnte - da müsste sich thewhobox dazu äußern.

Viele Grüße
Andreas

[thewhobox]

ob da auch eine ähnliche HCL-Steuerung Sinn machen könnte

Ich bin sogar schon weiter, ich hab das bei mir bereits implementiert.
Wenn auch nur per fest definierter Kurve und nicht als OFM.
Wenn da iwie Interesse dran besteht kann man das sicherlich mal als Basis verwenden.

Gruß Mike

[abtools]

Danke für deine schnelle Antwort, thewhobox!

Vielleicht tauscht ihr euch dazu einfach mal aus, kikakeule.
Den Code von Mike dazu findest du hier.

Viele Grüße
Andreas

[henfri]

Es ist ja nicht unbedingt nur HCL, sondern auch andere Dinge, bei denen Konsistenz wünschenswert wäre.