ElabNET Technik Forum

Noch ein Nachtrag zu 251.600:

Es scheint da Verwirrung (auch bei der KNXA) gegeben zu haben, was die Kodierung der Werte angeht. Ältere Versionen der ETS senden für 100% 0x64, neuere 0xFF. Und zumindest bestimmte Produkte von MDT (und anderen Herstellern ?) erwarten auch als maximalen Wert 0x64. Das ist aber m.E. ganz klar falsch, weil die Spec als Auflösung 0.4% nennt, und das geht nur, wenn man 100% auf 0xFF mappt.

Ich wüsste spontan nicht, wie man da einen Workaround für basteln sollte (außer mit einem „erfundenen“ DPT wie bei HSV).

Der neue ColorChooser der CometVisu nutzt intern auch xyY, weil nur so die Farbe eindeutig festgelegt ist. Daher kann der auch den xyY-DPT Und den "verbogenen" HSV DPT.

Für das Umrechnen der Farben, gerade wenn auch noch ein Weiß-Kanal zusätzlich dabei ist, braucht es schon ein Farbmanagement. Daher lassen sich beim neuen ColorChooser auch die xy-Koordinaten der einzelnen Komponenten angeben (alternativ auch die Wellenlängen der drei Farben und die Farbtemperatur des weißen Kanals). Denn nur in xyY (bzw. im XYZ) lassen sich die Mischfarben korrekt berechnen.

Gepullt ist der noch nicht, da mir ausgerechnet das HSV momentan Ärger bereitet - gerade wegen der 4 Kanäle und einem Weiß dass eben nicht zwingend der 1:1:1 Mischung der Farbkanäle entspricht so wie der nötigen Bijektivität.
Das Lab bzw. v.a. LCh funktioniert dafür schon sehr gut und ist für eine exakte Farbwahl deutlich angenehmer als ein HSV, dass im Vergleich eigentlich nur für krachige Effekte taugt.

Hi Chris,

lass uns dann mal bitte abstimmen, wie wir ein verbundenes Datenformat für xyY hinbekommen, das über MQTT dann bei uns von der CV reinkäme.

Spontan würde ich sagen, wir nehmen einfach drei Zahlen die wir intern in dreimal 16 Bit bekommen, also jeweils Werte von 0...65535 für x, für y und für Y (ja, ich weiß dass es Abhängigkeiten gibt und die Fläche unter dem "Hufeisen" nicht jeweils den vollen Wertebereich erlaubt).

Ich fände es toll, wenn wir zwischen CV-via-MQTT und dem TWS-Dispatcher-Farb-Datenformat keine (oder keine aufwändige) Umrechnung bräuchten. Falls das KNX Format hier brauchbar ist, können wir auch das nehmen für die MQTT Variante.

lg

Stefan

Irgendwas läuft beim MDT mit den valid Flags auch falsch. Da scheint mir meinen letzten Tests zufolge die Bit-Reihenfolge verdreht zu sein:
Mit dem W-Flag wird bspw. der R-Kanal geschrieben und mit dem R-Flag der W-Kanal.

Ansonsten geht das bei mir von 0x00 bis 0xFF sowohl ETS seitig, als auch was der Dimmer erwartet/ausführt.

StefanW hat geschrieben: ↑Di Nov 09, 2021 7:11 pm lass uns dann mal bitte abstimmen, wie wir ein verbundenes Datenformat für xyY hinbekommen, das über MQTT dann bei uns von der CV reinkäme.

Da bin ich komplett offen. Sobald da etwas Sinn macht kann ich es implementieren.

StefanW hat geschrieben: ↑Di Nov 09, 2021 7:11 pm Spontan würde ich sagen, wir nehmen einfach drei Zahlen die wir intern in dreimal 16 Bit bekommen, also jeweils Werte von 0...65535 für x, für y und für Y (ja, ich weiß dass es Abhängigkeiten gibt und die Fläche unter dem "Hufeisen" nicht jeweils den vollen Wertebereich erlaubt).

Können wir gerne so machen. Bei xyY ist es ganz normal, dass es Werte für Farben gibt, die nicht existieren - und erst recht nicht physikalisch dargestellt werden können.

StefanW hat geschrieben: ↑Di Nov 09, 2021 7:11 pm Ich fände es toll, wenn wir zwischen CV-via-MQTT und dem TWS-Dispatcher-Farb-Datenformat keine (oder keine aufwändige) Umrechnung bräuchten. Falls das KNX Format hier brauchbar ist, können wir auch das nehmen für die MQTT Variante.

Das KNX Format ist halt immer ein Binär-Format. MQTT nutzt dagegen gerne Strings.

Bei der CometVisu hängt es vom konfigurierten Backend ab welche Umrechnungen sinnvoll sind. Daher muss die Umrechnung für KNX und MQTT (und OpenHAB) getrennt implementiert werden. Das sind aber nur ganz wenige Zeilen Code, also alles kein großer Aufwand.

Kurzes Update zum DPT 251.600 im Zusammenhang mit MDT LED-Aktor:
MDT hat die Bit-Reihenfolge der Valid-Flags gegenüber der offiziellen Spec verdreht, also MDT hat implementiert...
1=rot
2=grün
4=blau
8=weiß

Richtig wäre lt. Spec...
1=weiß
2=blau
4=grün
8=rot