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

[starwarsfan]

zumal dann ja jedes Buch seinen korrekten Platz bräuchte.

Ach komm jetzt, das bekommst doch auch automatisiert! Eine Variante wären dann Beacons in den Büchern, um deren Position zu erkennen oder gleich ein paar Cam's auf die Regale, welche dann die Bücher automatisch erkennen. Dann wär's sogar egal, wo welches Buch steht...

[Techi]

Ich hab mir nun nicht die gesamten 4 Seiten vorher durchgelesen deshalb hier eine für mich wichtige Frage welche die Hardware betrifft.

Ist die Hardware so ausgelegt, dass die Software die PWM Ausgaben aller Ausgängen einzeln frei definieren kann, also speziell die Phasenlage zueinander ebenso die Frequenz der einzelnen Kanäle ? Also ist da sowas wie ein Hardware PWM Sequenzer verbaut worden ( PCA9685 ... ) oder wurde hier rein auf die PWM des Prozessors gesetzt oder aber zumindest die GPIO so geschickt gewählt, das diese hierfür für alle Kanäle über PIO entsprechend geschickt angesteuert werden können ?

Das wäre so ziemlich der wichtigste Punkt wo sich heute noch Dimmersysteme wirklich unterschieden können und auf was ich noch wert legen würde.

[abtools]

Hallo Walter,

nein, es ist nicht geplant Dinge wie PWM-Frequenz auf Kanalebene einstellbar zu machen - lediglich die PWM-Frequenz des gesamten Dimmers (zwischen 200 und 1200 Hz).

Aber ich wäre trotzdem neugierig zu verstehen, was dein spezieller Anwendungsfall ist, sodass du gerne die PWM-Frequenz für jeden einzelnen Kanal separat einstellen können möchtest?

Viele Grüße
Andreas

[henfri]

so, jetzt mal vom PC.

Ich bin da sicher kein Experte.
Aber z.b.

• ob man mit dimmen anschalten kann fällt mir spontan ein
• Harmonisierte Schritte beim Dimmen.
• Einheitliche Farbumrechnung hsv2rgb

Man müsste mal beide Applikationen durchgehen

Wie gesagt, ich mag die Idee grundsätzlich aber verstehe nicht ganz was du meinst:
"ob man mit dimmen anschalten kann": du meinst ob eine Nachricht "Relativ Dimmen: Hoch" das Licht anschaltet? Das klingt ziemlich Basic und ist vermutlich schwierig rauslösbar.

Ja genau. Muss ja auch nicht rausgelöst sein, aber eben bei beiden vorhanden und gleich implementiert.
Konfigurierbar, ob es nur mit rel. oder auch mit abs dimmen anschaltbar ist.

Ist aber bei OpenKNX Modulen mit Logikmodul zumindest darüber einfach umsetzbar wenn es nicht bereits implementiert ist.

Klar, aber es sollte auch ohne LM gehen

"Harmonisierte Schritte beim Dimmen": Versteh ich leider auch nicht ganz. Geht es um relatives Dimmen, also das z.B. immer 10% oder 5% Heller wird? Ist das nicht im Schalter?

Da bin ich gerade überfragt, aber war es nicht so, dass es zwei arten von Dimmen gibt und bei der einen stellt man es im Taster und in der anderen im Dimmer ein?

"Einheitliche Farbumrechnung hsv2rgb": Muss ich passen, kannst du da nochmal genauer schreiben was du meinst?

Die Berechnung, um von hsv auf rgb zu kommen, sollte die exakt gleiche Formel verwenden. Gleiches gilt für die Mischung von Farbtemperaturen (auch wenn dies trivial scheint)

Weitere punkte:
Einschalten: Parametrierbarer Einschaltwert. Ggf. Zeitgesteuert (HCL). Wird Wert direkt übernommen oder angedimmt. Gleiche Auswahlmöglichkeiten für Andimmzeit (nicht der eine 1,3,5 und der andere 2,4,6s)
Dito für Ausschalten
Verhalten beim Abs-Dimmen: Sofort übernehmen oder andimmen --> zeiten s.o.
Max/Min Werte für dimmen: Gleiche Werte auswählbar. Funktion: die Werte gelten (a) immer (b) für relatives dimmen (c) für abs und rel dimmen
Farb-objekt: Gleiche DPT werden unterstützt. Andimmzeiten auswählbar und bei beiden Geräten gleich


Das sind alles Funktionen, die ich von anderen Geräten kenne.

Ich habe jetzt nicht überprüft, ob das Dali-GW udn ob der Dimmer das schon können. Es geht mir hier nur darum, dass es zw. den beiden Applikationen dahingehend Abstimmbedarf gibt.

Gruß,
Hendrik

[Techi]

...
nein, es ist nicht geplant Dinge wie PWM-Frequenz auf Kanalebene einstellbar zu machen - lediglich die PWM-Frequenz des gesamten Dimmers (zwischen 200 und 1200 Hz).
...

Primär wäre es mir wichtig die PWMs der Kanäle zueinander verschieben zu können, speziell bei HCL. Die Stromspitzen beim durchschalten der Fets können je nach Leuchtmittel wirklich hoch werden. Wenn diese dann auch noch von mehreren Kanälen aufeinandertreffen sollte man eine extreme Puffer zur Verfügung haben oder es halt vermeiden.
Besser wäre es aus allen Kanälen quasi ein Rauschen zu erzeugen. Am einfachsten wäre das mit unterschiedlichen PWM Frequenzen welche zueinander geschickt gewählt werden.
Eventuell wären auch 2 bis 4KHz PWM manchmal nicht ganz schlecht. Zum einem um eine passenden Frequenz zu finden welche die Stripes nicht pfeifen lässt, wie in meinen Fall wo die Stripes mit Magnetbändern in den Metallschienen befestigt sind (Lautsprecher gebaut ;-) ) oder wenn man z.B. Filmen möchte. (Flickereffekte)

[kikakeule]

Primär wäre es mir wichtig die PWMs der Kanäle zueinander verschieben zu können, speziell bei HCL.

Beim Umbau der PWM-Steuerung habe ich mir dazu einige Gedanken gemacht. Sobald das PWM nicht mehr synchron zwischen allen Kanälen ist, kommt es zu Lastspitzen mit Frequenzen deutlich kleiner als die PWM Frequenz (u.U. im Hz Bereich), das führt dann zu tatsächlich sichtbarem Flackern.

Die Stromspitzen beim durchschalten der Fets können je nach Leuchtmittel wirklich hoch werden. Wenn diese dann auch noch von mehreren Kanälen aufeinandertreffen sollte man eine extreme Puffer zur Verfügung haben oder es halt vermeiden.
Besser wäre es aus allen Kanälen quasi ein Rauschen zu erzeugen. Am einfachsten wäre das mit unterschiedlichen PWM Frequenzen welche zueinander geschickt gewählt werden.

Wir fahren jetzt jeden zweiten Kanal invers, so dass nur die Hälfte der Kanäle zur gleichen Zeit schaltet, das sollte schon ein bisschen helfen. Ansonsten ist der externe Puffer ja in Form von Kondensatoren in den 24V Netzteilen vorhanden. Das ganze ist ein tolles Argument dafür das Netzteil ausreichend zu dimensionieren und nicht zu sehr auf Kante auszusuchen.
Man könnte überlegen die PWM Kanäle zwar synchron aber mit noch unterschiedlicheren Startzeitpunkten zu betreiben (z.B. indem wir als dritte Variante das PWM Signal im Interval zentrieren) aber spätestens wenn der Duty Cycle gegen 100% geht ist der Effekt davon gegen null weil dann doch alles ziemlich gleichzeitig schaltet... Und das ist ja gerade der Bereich wo die Puffer im Netzteil u.U. recht belastet sind.

Eventuell wären auch 2 bis 4KHz PWM manchmal nicht ganz schlecht. Zum einem um eine passenden Frequenz zu finden welche die Stripes nicht pfeifen lässt, wie in meinen Fall wo die Stripes mit Magnetbändern in den Metallschienen befestigt sind (Lautsprecher gebaut ;-) ) oder wenn man z.B. Filmen möchte. (Flickereffekte)

Das ist programmatisch recht einfach umzusetzen, das einzige Problem was ich sehe, dass hier mehr nicht gleich besser ist - das aber den meisten Nutzern schlecht zu verkaufen ist.
Müsste man gut testen und dann mindestens eine deutlich sichtbare Warnung einbauen

[Techi]

Ich hab diesbezüglich genug getestet und auch bezüglich Design von Leistungselektronik (auch Antriebstechnik) genug Erfahrung.
Die Aussage mit den "tolles Argument dafür das Netzteil ausreichend zu dimensionieren" ist nur die halbe Wahrheit (so hab ich auch mal gedacht und fast alles extrem unterdimensioniert, ohne Erfolg) denn selbst wenn man Netzteile extrem überdimensioniert heißt das nicht, dass diese mit schnellen Lastspitzen gut zurecht kommen. (Beispiel Meanwell HLG Serie)
Ich habe bereits viel mit FET-Typen, Gateansteuerung, Pufferung und dem Ansteuertiming experimentiert und gerade das Ansteuertiming kann bei mehr als einem Kanal auf einem Netzteil sehr viel bringen.
Es geht dabei im wesentlich darum wie die Netzteilregelung auf Last reagiert. Netzteile können da ekelhaft zu schwingen anfangen, gerade Netzteile mit LED Zulassung sind bezüglich Lastregelung da anfällig). Hier kann man mit sehr gut angepassten Kapazitäten schon was gegensteuern das würde aber bedingen nochmal an den Netzteil Ausgängen zusätzlichen Aufwand zu betreiben welcher nicht unerheblich ist und außerdem üblicherweise noch mehr Elkos mit einbringt die leider bezüglich Lebensdauer auch keine Langläufer sind.

[abtools]

Guten Abend zusammen,

gerade habe ich das angekündigte, größere Update 0.11 auf GitHub hochgeladen. Das dieses Mal etwas längere Changelog findet ihr auch dort:
https://github.com/OpenKNX/OAM-LedDimmer-AB/releases

Damit sollten auch die allermeisten deiner Punkte, Alloc, erledigt sein - gerne nochmal testen.

Es sind eine Reihe neuer Features dabei, wir nähern uns also in großen Schritten einem ersten "richtigen" Release. :-)

Viele Grüße und danke für euer ganzes, konstruktives Feedback
Andreas

[LostWolf]

Hey danke dir
(GitHub hat es wohl diesmal versemmelt mir eine Update mail zu schicken...)

Jetzt muss (darf natürlich ) ich mich also entscheiden ob ich das Netzteils größer auslegen und den Boost nutzen kann oder nur auf die Hälfte der Leistung (50/50%).

Und echt vielen Dank für das relative KO

Werde mir das Mal am Sonntag ansehen

[Alloc]

Hi,

hatte jetzt auch mal Zeit mir die neue Version anzuschauen. Erstmal sehr schön, man merkt direkt dass da viele Fortschritte drin stecken

Ich gehe dann erstmal meine Liste von vorher durch:

• Wenn der Kanal eingeschaltet ist wird 1-2 mal pro Sekunde der aktuelle Dimmwert gesendet. Unabhängig davon, welcher Dimmwert aktuell eingestellt ist, also sowohl z.B. bei 9% als auch bei 100%, auch unabhängig von der Farbtemperatur. Ist der Kanal aus kommt das nur einmal wenn 0% erreicht werden.
• Einschalten geht immer auf die Voreingestellte Farbtemperatur + Helligkeit. Hier wäre mehr Flexibilität schön, insbesondere für mich obligatorisch wäre ein "nur Einschalten" (mit eingestellter Helligkeit natürlich), aber ohne dabei die Farbtemperatur zu ändern.
• Bisher ist mir nicht klar, woher die Dimmzeit bei absoluten Dimmwerten kommt, da es hier keine Einstellung gibt. PS: Gerade mal getestet ... das scheint *immer* 1 Sekunde zu sein? Da wäre eine entsprechende Option schön. Und wenn ich das richtig abschätzen konnte unabhängig von Start- und Zielwert, sprich gehe ich von 0% auf 100% dauert das 1 Sekunde, von 20% auf 40% dauert auch 1 Sekunde. Das wäre anders, als ich das von allen anderen Dimmaktoren kenne und auch aus der Praxis für mich nicht sauber.
• Ein KO "Farbtemperatur relativ" fehlt (also 0% = nur Warmweiß = minimale Farbtemperatur, 100% = nur Kaltweiß = maximale Farbtemperatur). PS: "Fehlt" immer noch. Es gibt zwar ein entsprechend bennantes KO, aber das ist ein "Dimm"-KO, kein Relativwert.
• Die Netzteilspannung wird aktuell wohl auch intern nur im eingestellten Sende-Intervall gemessen. Ich hatte das Netzteil nach einer Messung angeschaltet und dann das KO gelesen, da blieb aber bis zum Ablauf des regulären Intervalls immer die alte Spannung drin. Ich denke hier wäre eine regelmäßige Messung schön, dass man zum einen den "aktuellen" Wert jederzeit abfragen kann aber auch ...
• ... Eine Einstellung, dass die Netzteilspannung nicht nur zyklisch gesendet wird, sondern auch bei Änderung
• Insbesondere wäre eventuell auch ein einfaches Bool-KO "Versorgungsspannung liegt an", mit dem man dann z.B. auch Alarme auslösen könnte wenn das nicht der Fall ist. PS: Ist zwar nicht vorhanden, aber man hat ja auch das Logikmodul dabei, mit dem man natürlich einfach nach belieben einen Grenzwert definieren kann und passend Bool-Werte senden.
• Generell fehlt natürlich noch für die meisten Felder die Dokumentation in der ETS. Gibt es eigentlich sonst schon eine Beschreibung der Applikation? Im Git konnte ich keine finden.

Ich hab gesehen, dass die KO teils umbenannt wurden. Aus einer Sicht ungünstig ist hier der Term "relativ" für die KOs Helligkeit/Farbtemperatur dimmen. "Relativ" bedeutet in meinen Augen immer ein Prozentwert - bezogen auf einen bestimmten Kontext, also hier Helligkeit wäre das sowieso existierende KO relativ zur maximalen Helligkeit, bei Farbtemperatur relativ bezogen auf den Kaltweißanteil (0% = nur WW, 100% = nur KW). Letzteres fehlt noch.
Passender fand ich hier tatsächlich die Vorgängerversion mit "Dimmen relativ" oder einfach nur "Helligkeit dimmen" und "Farbtemperatur dimmen".

Richtig cool find ich das KO "Schalten Sofort". Hier würde ich mir ergänzend noch ein KO "Helligkeit Absolut Sofort" wünschen - also 70% senden -> sofort auf 70%.

Habe aber auch glaube ich Bugs gefunden in den Status-KO:
Ich habe da die Standardeinstellungen des Kanals - nur halt die Statusausgabe grundsätzlich aktiviert:
image.png
Ich bekomme nun zwar Ausgaben für den Helligkeitsstatus, aber nicht zuverlässig/immer.

• Beim "Schalten Sofort" kommt gar kein Statusupdate.
• Bei regulärem Schalten oder Dimmen Absolut kommen nicht alle Werte. "Schalten" Ein oder Dimmen auf 100%: Er geht hoch bis 62-64%, dann kommt nichts mehr. Lese ich danach das KO aus kommt 100% zurück.
• Schalten Aus (Ausschaltzeit 3s): Bis 11% kommt gar kein Wert, danach alle Werte bis einschließlich 0%.
• Dimmen auf 0% (wie gesagt wie ich das verstehe Dimmzeit 1s?): Bis irgendwo 35-40% kommt kein Wert, dann viele Werte bis einschließlich 0%.

Aus meiner Sicht müsste *immer* der Status am Ende eines Vorgangs gesendet werden. Sprich bei Schalten sofort, aber auch bei Zielwertvorgabe (Schalten, Helligkeit absolut), wenn der Zielwert erreicht ist, oder bei Dimmvorgängen wenn Dimmen "stopp" kommt oder halt in der aktuellen Dimmrichtung das Limit erreicht ist (0% / 100%).
Generell kommen während Dimmvorgängen aber auch einfach zuviele Werte aus meiner Sicht. Hier wäre eine Einstellung der folgenden Art praxisnäher glaube ich:

• Status nicht senden
• Status während Vorgängen senden (also bei Dimmen oder Schalten etc bevor das Ende erreicht ist).
• Status nur am Ende von Vorgängen senden

Im zweiten Fall bräuchte es entweder ein hardcodiertes maximum an Nachrichten pro Zeit (also z.B. sende 1 Nachricht pro Sekunde) oder sogar einstellbar per ETS. Aber wenn ich hier einen Vorgang habe, der über 1 Sekunde abläuft, braucht es dabei keine 13 Nachrichten mit den Zwischenwerten (plus die Nachricht am Ende mit Zielwert)


Das wäre erstmal mein Feedback zur 0.11 wie bisher getestet. Wenn ich Details zu irgendwas nachliefern soll bitte gerne melden. Freue mich echt über die Fortschritte und bin auf 0.12 gespannt

LG, Chris

[kikakeule]

Aus meiner Sicht müsste *immer* der Status am Ende eines Vorgangs gesendet werden. Sprich bei Schalten sofort, aber auch bei Zielwertvorgabe (Schalten, Helligkeit absolut), wenn der Zielwert erreicht ist, oder bei Dimmvorgängen wenn Dimmen "stopp" kommt oder halt in der aktuellen Dimmrichtung das Limit erreicht ist (0% / 100%).
Generell kommen während Dimmvorgängen aber auch einfach zuviele Werte aus meiner Sicht. Hier wäre eine Einstellung der folgenden Art praxisnäher glaube ich:

• Status nicht senden
• Status während Vorgängen senden (also bei Dimmen oder Schalten etc bevor das Ende erreicht ist).
• Status nur am Ende von Vorgängen senden

Im zweiten Fall bräuchte es entweder ein hardcodiertes maximum an Nachrichten pro Zeit (also z.B. sende 1 Nachricht pro Sekunde) oder sogar einstellbar per ETS. Aber wenn ich hier einen Vorgang habe, der über 1 Sekunde abläuft, braucht es dabei keine 13 Nachrichten mit den Zwischenwerten (plus die Nachricht am Ende mit Zielwert)

Das steht auch auf meiner Liste. Ist mir auch schon aufgefallen, dass das noch nicht rund ist.
Leider bin ich diese Woche noch voll im Sanierungsstress, ich schau mir das inkl. der weiteren Arbeit am HCL nächste Woche mal an.

[morpheus80]

Guten Abend

ich dachte mir, dass ich mich heute auch mal hier zu Wort melde.

[*]Einschalten geht immer auf die Voreingestellte Farbtemperatur + Helligkeit. Hier wäre mehr Flexibilität schön, insbesondere für mich obligatorisch wäre ein "nur Einschalten" (mit eingestellter Helligkeit natürlich), aber ohne dabei die Farbtemperatur zu ändern.

Zu finden unter "Einschaltwert">Letzer Wert. Dann merkt er sich halt den letzten Wert und fährt den beim nächsten Einschalten wieder an.

[*]Bisher ist mir nicht klar, woher die Dimmzeit bei absoluten Dimmwerten kommt, da es hier keine Einstellung gibt. PS: Gerade mal getestet ... das scheint *immer* 1 Sekunde zu sein? Da wäre eine entsprechende Option schön. Und wenn ich das richtig abschätzen konnte unabhängig von Start- und Zielwert, sprich gehe ich von 0% auf 100% dauert das 1 Sekunde, von 20% auf 40% dauert auch 1 Sekunde. Das wäre anders, als ich das von allen anderen Dimmaktoren kenne und auch aus der Praxis für mich nicht sauber.

Die Dimmzeit läßt sich auch einstellen. Für Tag und Nacht sogar unterschiedliche Werte, so wie für AN und AUS.

[*]Ein KO "Farbtemperatur relativ" fehlt (also 0% = nur Warmweiß = minimale Farbtemperatur, 100% = nur Kaltweiß = maximale Farbtemperatur). PS: "Fehlt" immer noch. Es gibt zwar ein entsprechend bennantes KO, aber das ist ein "Dimm"-KO, kein Relativwert.

Mit dem KO Farbtemperatur Relativwert kannst du aktuell von Kaltweiß nach Warmweiß dimmen. Oder umgekehrt. Also genau so wie bei der Helligkeit. Falls du damit meinst, dass man es in 10% oder 25% oder X% schritten hoch/runter nehmen kann, dann ist das aktuell nicht geplant. Würdest du so etwas wollen?

[*]Generell fehlt natürlich noch für die meisten Felder die Dokumentation in der ETS. Gibt es eigentlich sonst schon eine Beschreibung der Applikation? Im Git konnte ich keine finden.

Dokumentation fehlt logischerweise noch. Ist ja immer noch im Versuchslabor. Aber eigentlich (eigentlich heißt immer mit Einschränkung ;-) ) sind die Texte ausreichen, damit man weiß was gemeint ist.

[*]Richtig cool find ich das KO "Schalten Sofort". Hier würde ich mir ergänzend noch ein KO "Helligkeit Absolut Sofort" wünschen - also 70% senden -> sofort auf 70%.

Generell recht leicht um zu setzen, aber ... für was würdest du das benutzen wollen?

[*]Habe aber auch glaube ich Bugs gefunden in den Status-KO:
...

Bugs dürfen generell behalten werden, müssen aber gefüttern werden ;-)
Zu viele Nachrichten über den Bus sind allgemein nicht so gut.
Ist das nur im TW so oder auch im RGB/EK?


MFG