Feature Requests: Colour Conversion and Sequencer

[henfri]

Hello,

I am looking for these functions in OpenKNX:

1. RGB <-> HSV
2. HSV Sequencer

I think that the FunctionBlocks Module could be the right place for it.

1. RGB <-> HSV
   The idea is to combine RGB LEDs to a more user-friendly HSV LED. This allows a more intuitive use than dimming the three color channels individually.
   each channel would require:

• Three Inputs for the HSV set-values
• Three Outputs for the HSV status-values
• Three Inputs for the RGB status-values
• Three Outputs for the RGB set-values

The equations are pretty straight forward and I could also implement them.
However, I have no clue how to implement the KOs and the KNX-Prod.

2. HSV Sequencer:
   This would seqence through the Hue-Value in an given interval.
   each channel would require:

• One output for H-Value
• One input for set-Active
• One output for status

Please let me know, what you think about these ideas.

Greetings,
Hendrik (henfri)

[cornelius-koepp]

Vielen Dank für Deine Vorschläge. Schon mal kurz als erstes Feedback:

1. RGB <-> HSV

Es gibt bereits in einem (unveröffentlichte) OpenKNX-Projekt entsprechende Implementierungen zur Umrechnungen. Eine Doppelte Implementierung wäre eher unschön, insbesondere wenn nicht sicher gestellt ist, dass die exakt selben Ergebnisse zurückgeliefert werden. Wenn diese Implementierung verfügbar ist, und ob diese Deinen Anforderungen genügen würde kann ich allerdings nicht sagen. Werde mal an entsprechender Stelle auf Deine Anfrage hinweisen.

Was sicher ist: Eine Umsetzung mit 12 KOs wird es nicht geben, weil die Funktionsblöcke nach dem Konzept von @mgeramb auf 10 KOs beschränkt sind. Eine Erhöhung würde im Konflikt zu einer hohen nutzbaren Block-Anzahl stehen.

Üblich für RGB-Werte wäre auch DPT232.600. Gibt es einen Grund warum Du davon abweichen willst?

Abgesehen davon ist es nicht so unwahrscheinlich, dass sich eine entsprechende Umrechnung auch mit dem Logik-Modul umsetzen lässt. Habe ich allerdings bislang nicht weiter geprüft. Ist tendenziell eine Frage der nötigen Kanal-Anzahl und könnte durch Einsatz von Benutzerformeln einfacher werden ;-)

2. HSV Sequencer

Auch hierzu gibt es schon Pläne an anderer Stelle.

-CK

[henfri]

Hallo Cornelius,

danke für deine Antwort.
Dann bin ich mal gespannt auf die Veröffentlichung. Ich sehe es auc hso, dass exakt die selben Ergebnisse zurückgeliefert werden müssen.
Um 12 KOs zu vermeiden könnte man auch auf eine Trennung von Set und Status KOs verzichten.

DPT 232.600/251: Ich muss gestehen, dass ich den noch nicht verwendet habe.
Ich bin auch nicht sicher, ob man mit 251 so flexibel ist, weil man dann W nicht unabhängig steuern kann. Bei 232 sollte es das Problem nicht geben.
Das wäre sicher auch eine Möglichkeit, die 12 KOs zu vermeiden. Und zur Not macht man noch einen DPT-Konverter-Funktionsmodul :-)

Umrechnung im Logikmodul: Man benötigt ja drei Inputs und die Benutzerformeln können nur zwei. Ich denke auch, dass es recht unübersichtlich wird, weil man mehrere Kanäle braucht.

Gruß,
Hendrik

[cornelius-koepp]

Ich bin auch nicht sicher, ob man mit 251 so flexibel ist, weil man dann W nicht unabhängig steuern kann. Bei 232 sollte es das Problem nicht geben.

DPT 251.600 besitzt laut Spezifikation (siehe Abschnitt 6.18 DPT Colour_RGBW) für jeden der 4 Kanäle einen Gültigkeits-Flag. Ohne spezifischere Informationen interpretiere ich das so, dass man auch nur einzelne Farbkanäle auf diesem Wege übermitteln kann (um dann z.B. auf Empfängerseite alle anderen Farbkanäle unverändert zu belassen). Bietet also eine höhere Flexibilität als DPT 232.600.

Ein Problem besteht eher in der praktischen Verbreitung von nicht zur Spezifikation konformen Implementierungen, siehe
DPT Colour_RGBW (251.600) - korrekte Kodierung und existierenden Implementierungen - im Zweifelsfall brauchen wir da beide Formate (was bei Konvertierung auf Stack-Ebene unschön werden kann).

-CK

[henfri]

Ah, ja. Das ist ja durchaus durchdacht in der Spezifikation.
Aber natürlich auch komplex.
Wenn man beide Formate anbietet, dann könnte man ja "nativ" mit 251 arbeiten und zusätzlich einen Konverter von RGBW und HCLW nach 251 erstellen. In letzterem könnte man dann sicher auch problematische Implementierungen umschiffen.

Ich habe gerade mal nachgeschaut:
Der MDT Glastaster unterstützt nur 232. Das Dali-GW (Ipas e64) bietet 232 und 251.
Wenn ich jetzt z.B. eine EVG mit RGB (für Effektbeleuchtung) und W für Alltagsbeleuchtung habe, dann stehe ich blöd da. 251 kann ich ja nicht nutzen. Mit DPT5 bin ich flexibel - muss aber viele Verknüpfungen machen.

[henfri]

Nachtrag:
Bei vielen meiner Dali-EVG kann ich kein DPT251 oder 232 nutzen, den sie sind nicht DT8. Das Gateway kann auch keine drei Einzelkanäle zu einem Farb-Kanal kombinieren.
Das ist auch ein Grund, weshalb DPT2xx ggf für einige nicht möglich ist.